Re: CSeq in Registration process with 407
Kevin P. Fleming <kpfleming <at> digium.com>
2012-06-04 11:21:48 GMT
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.