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
