[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Question on REGISTER



Brian Stucker wrote:


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Wednesday, October 18, 2006 10:21 AM
To: Stucker, Brian (RICH1:AR00)
Cc: Dean Willis; sip at ietf.org; CLHaft at aol.com
Subject: Re: [Sip] Question on REGISTER
This doesn't mean that the registrar has to send a 491 back to overlapping registrations from two different sources trying to register for the same target resource in parallel as long
as their SIP
transactions aren't overlapping.
overlapping how?
Standard SIP overlapping transactions... Two transactions with the same SIP context information (callid, tags, etc) but the CSEQs are different and a final response hasn't been sent for the transaction with the lower CSEQ value when the transaction with the
higher CSEQ is received.
That'll earn you a 491 from the SIP transaction layer in most cases. 
I don't interpret this the same way that you do.

AFAIK that isn't a transaction layer issue at all. This is in fact ok in some cases. For instance it is legal to send a 2nd NOTIFY before the response has been received for an earlier one. (Often not wise, but
legal.) And if you have two dialog usages sharing a dialog, you might have a NOTIFY and a reINVITE overlap.


You shouldn't allow overlapping REGISTER transactions on the same
'dialog' using UDP (and typically an end device shouldn't try to
circumvent this by sending them on different 'dialogs') because you have
no idea which one will arrive at the registrar first. If the application
registering doesn't care which one is processed first, then it's at
least safe.

Note that there is only a conflict when the AOR and the Contact being registered are the same. When different contacts are being registered (which is usually the case for registers from different sources) the only race condition is about which contacts that weren't in the register will be returned in the response.

However, if the registrar doesn't wish to provide internal queueing of
requests, a 491 isn't the worst return code you could come up with to
push the work to the clients.

IMO a registrar which returns a 491 as a result of concurrent registrations that target different AORs or that have different contact values and different Call-ID values, is broken.

In the case that initiated this, I believe the registers were to different AORs, but came over the same TCP connection.

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip