Subject: RE: [Sip] Question on REGISTER

From: "Brian Stucker" <[email-masked]>
Date: Wed, 18 Oct 2006 10:31:41 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, October 18, 2006 10:21 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Dean Willis; [email-masked]; [email-masked]
> 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.

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.

Regards,
Brian

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 13:02:25 -0400

> registering doesn't care which one is processed first, then it's at

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.

> 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

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 18 Oct 2006 12:10:10 -0500

> Sent: Wednesday, October 18, 2006 12:02 PM
> >> 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.
> >>
> > 
> > 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.

That's right.

> registrations that target different AORs or that have 
> different contact values and different Call-ID values, is broken.
> 

I'd agree that it's definitely very sub-optimal, but I don't see how it
breaks things. It is rather annoying though.

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

That definitely sounds like a bad implementation issue then. The TCP
connection reuse shouldn't have anything to do with sending a 491 back.