[OpenSIPS-Users] registrations and RFC 3261

[Iñaki Baz Castillo]

El Martes, 12 de Enero de 2010, Jan D. escribió:
> I have a issue with an Alcatel PaBX-voip client on our opensips server
>  bases on RFC 3261. The PaBX is behind NAT.
> 
> On our opensips 1.6.1 i have set modparam("usrloc", "matching_mode", 1),
> CONTACT and CALLID based matching algorithm.
> 
> All clients Call-ID in a Register request, so if a register comes early
> (expire time 60, request comes in 50) there still is one binding.
> 
> The Alcalel uses a new Call-ID in every new register. This results in a OK
> with 2 bindings. Of cause the thirst binding is almost expired. All other
> clients (X-Lite, asterisk etc) keep sending the same Call-ID, I think this
> is what RFC 3261 wants.
> 
> I had contact with the developers of Alcatel but they say the CALL-ID
> 'SHOULD' be the same. SHOULD is not MUST so the don't do it this way and
> sent a new Call-ID every time. (if I sent a 401 Unauthorized they do
>  respond with the same Call-ID).
> 
> 8.1.1.4 Call-ID
> 
>    The Call-ID header field acts as a unique identifier to group
>    together a series of messages.  It MUST be the same for all requests
>    and responses sent by either UA in a dialog.  It SHOULD be the same
>    in each registration from a UA.
> 
> My question is if this is a good interpretation of RFC 3261, so if the
> CALL-ID MUST stay the same during the registration (so for days of weeks).
> 
> If I switch back to matching_mode = 0 (default) i get problems with some
> clients behind NAT.


Alcatel is wrong:

"MUST" means that it's totally required to behave aas specified in the RFC 
(for sure Call-ID must not change within a dialog).

"SHOULD" means that it should be done as the specification states but in case 
of doing in other way the protocol is not broken.

This is: if you change the Call-ID in an in-dialog request you are breaking 
the dialog rules. However if you change the Call-ID in a refresh REGISTER then 
you are performing a new (and probably parallel) registration. Nothing has 
been "broken".

Anyhow, sending a different Call-ID in a refresh REGISTER creates two parallel 
registrations which, for sure, it's not what Alcatel desires. If Alcate 
expects that such problem in their implementation must be "rescued" in the 
registrar they are totally wrong.

Alcatel is wrong, for sure.


-- 
Iñaki Baz Castillo <ibc at aliax.net>