If you are on the registrar side of things, then by being sufficiently
liberal in what you accept you can make this work. If you examine the
specified procedures that a registrar is to follow, then the only real
dependence on callid and cseq is at the level of the binding of
individual contacts to an AOR. Hence the use of the same callid with
different AORs shouldn't cause any difficulty.
However if you look at the specifications for what the sender of a
REGISTER should do about the callid and cseq, then the expected behavior
depends greatly on what you consider to be one UA vs several.
If I understand what you are saying, then IMO the device sending the
register requests is at least violating the spirit and intent of the
spec, but it may not be violating the letter of the spec.
The *point* of using the same callid is to indicate that subsequent
register requests are revisions to what was sent in prior register
requests for the same callid. In the example you give, that is not the
intent, so using the same callid is at best deceptive.
To be fair, I can see how an implementor could decide on the behavior
you are seeing, based on just reading the portions of 3261 that seem to
be needed to get the job done.
Thanks,
Paul
Vadim Berezniker wrote:
> Thanks Paul,
>
> I'm actually on the other end of the deal. A customer is using a PBX that
> registers multiple AORs.
> It uses the same Call-ID for all the registrations which doesn't work
> out-of-the-box with our PBX.
> I'm just trying to get a grasp on what, if anything, their PBX is not doing
> incorrectly.
>
> Is sending the distinct AORs under one UA incorrect? From what you pointed
> out, that seems to be the case.
> And if it's acceptable, it must wait until a final response for a
> registration before sending the next one. Am I interpreting it correctly?
>
>
> On Mon, Oct 20, 2008 at 10:13 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>>
>> Vadim Berezniker wrote:
>>
>>> Paul,
>>>
>>> Sorry, I still haven't got my hands around the proper terminology for SIP.
>>> It's sending out registrations for distinct AORs. Each registration has a
>>> distinct user in the To URI.
>>>
>>> Hope that clears it up.
>>>
>> Section 8.1.1.4 of 3261 says:
>>
>> 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.
>>
>> In a new request created by a UAC outside of any dialog, the Call-ID
>> header field MUST be selected by the UAC as a globally unique
>> identifier over space and time unless overridden by method-specific
>> behavior.
>>
>> Section 10.2 says:
>>
>> Call-ID: All registrations from a UAC SHOULD use the same Call-ID
>> header field value for registrations sent to a particular
>> registrar.
>>
>> If the same client were to use different Call-ID values, a
>> registrar could not detect whether a delayed REGISTER request
>> might have arrived out of order.
>>
>> When applying the above to your case the problem is determining if what you
>> have is one UA or several. IMO it makes much more sense to think of what you
>> have as multiple UAs that run in the same server. Otherwise, the rationales
>> above for when to use a single Call-ID make no sense. Getting specific about
>> which UA is involved in each request may depend a bit on the detailed
>> architecture of your server. Roughly, I would probably associate a UA with a
>> From-URI or a Contact address.
>>
>> I assume that you are using first party registration, where the From- and
>> To- URIs of the REGISTER are the same.
>>
>> That first paragraph of 10.2 above is also probably not as precise as it
>> should be. Rather than "particular registrar", it probably ought to say
>> "particular To-URI", since if the same UA is registering to multiple To-URIs
>> at the same registrar then they ought to be considered distinct.
>>
>> BUT, having said all that, a lot of registrars will probably work ok with
>> what you are currently doing.
>>
>> Thanks,
>> Paul
>>
>>
>>
>>
>> On Mon, Oct 20, 2008 at 9:29 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>>>
>>>> Vadim Berezniker wrote:
>>>>
>>>> Hi,
>>>>> We have a client that sends multiple registrations.
>>>>> All of the registrations have the same Call-ID and and incremented CSeq.
>>>>> So far, I believe the behavior is correct. (Although in practice, every
>>>>> other device I've seen uses a unique Call-ID for each unique
>>>>> registration).
>>>>> It does not however wait for one registration to complete before sending
>>>>> out
>>>>> the next one.
>>>>>
>>>>> UAs MUST NOT send a new registration (that is, containing new Contact
>>>>> header field values, as opposed to a retransmission) until they have
>>>>> received a final response from the registrar for the previous one or
>>>>> the previous REGISTER request has timed out.
>>>>>
>>>>>
>>>>> I'm not quite clear on the 'UA' terminology. In this case, is the UA the
>>>>> client with multiple registrations or is it supposed to act as a
>>>>> separate
>>>>> UA
>>>>> for each user it's registering?
>>>>> Thanks for your help.
>>>>>
>>>>> I don't understand what sort of multiple registrations are being sent.
>>>> Are
>>>> these being sent to a single target (R-URI and To-URI in this case)? Or
>>>> are
>>>> these registrations for distinct AORs?
>>>>
>>>> I'm just guessing that this is either a UA trying to create multiple
>>>> registrations for sip-outbound, or else it is something like a sip-pbx
>>>> that
>>>> is trying to create separate registrations for each phone it manages.
>>>>
>>>> Without knowing more it is hard to give you a specific answer.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
