RE: [Sip] Question on REGISTER

["Brian Stucker" <bstucker at nortel.com>]

> -----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.

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip