On 06/03/2012 12:01 PM, Paul Kyzivat wrote:
> OTOH, if you have no established registration state and so are doing an
> initial registration, you should be randomly be choosing a new Call-ID
> and CSeq. If*that*  request fails with a 407, IMO you have some options:
> - do just as above for a retry with registration state - same Call-ID
>     and incremented CSeq.
> - start over from scratch, with a new Call-ID and new CSeq, but with
>     Proxy-Authorize based on Proxy-Authenticate from the 407.

Interesting; as you say, REGISTER doesn't create a dialog, but I suspect 
that many UAs treat the state management similarly to a dialog (I know 
that Asterisk certainly does). Because of that, if the REGISTER retry 
doesn't use the same Call-ID, then it won't be accepted, because the 
nonce and other authorization related details are stored in that 
'dialog' structure, which won't be present when a new one is created for 
the new Call-ID.

> AFAIK these are equally acceptable.
>
> In this case, if you were to reuse the Call-ID but with a CSeq that is
> incremented by more than one, I would expect it to work. And even if you
> were to use a CSeq that was less it should probably work, because there
> should be nothing holding state with the prior value. But in these cases
> it can be argued that you aren't compliant.

I'm pretty sure that Asterisk will respond with an error if the retried 
request does not have a higher CSeq value than the original request, 
even for REGISTER and other non-dialog-forming requests. Essentially, 
the sequence of requests is treated as a 'dialog' during the 407/retry 
cycle. I don't remember this ever causing an interoperability problem.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email protected] | SIP: [email protected] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to