This is a good question for Robert Sparks, who has seen most every known
behavior at SipIt.
Thanks,
Paul
On 6/4/12 7:21 AM, Kevin P. Fleming wrote:
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.
--- Begin Message ---
On 6/3/12 7:48 AM, Brez Borland wrote:
> Hi Manoj,
>
> On Sun, Jun 3, 2012 at 3:14 AM, Manoj Priyankara<[email protected]>wrote:
>
>> Good day Folks,
>>
>> I have a doubt in the use of CSeq in the registration process that involve
>> 407. Call flow is as follows
>>
>> UAC
>> UAS/Proxy
>> |-------F1 (REGISTER)------------------------------------------> |
>>
>> |<-----F2 (407 With proxy-authenticate)--------------------- |
>>
>> |-------F3 (REGISTER with proxy-autorization)-----------> |
>>
>> |<-----F4 (200 OK)------------------------------------------------>|
>>
>> Must the UAC use the same CSeq value throughout the complete registration
>> process? (That is both F1 and F3 have the same CSeq)
>>
>> Or
>>
>> Can the UAC increase the CSeq by one in F3 ?( That is, if CSeq of F1 is 1
>> and CSeq of F3 is 2)
>>
>
>
> UAC MUST increase the CSeq number. For full answer to your question refer
> to RFC3261, Section 8.1.3.5 Processing 4xx Responses, last paragraph on the
> Page 45.
That section, by itself, doesn't justify your conclusion.
Section 10.2 - about constructing REGISTER requests, says:
CSeq: The CSeq value guarantees proper ordering of REGISTER
requests. A UA MUST increment the CSeq value by one for each
REGISTER request with the same Call-ID.
The part of 8.1.3.5 referenced above says:
In all of the above cases, the request is retried by creating a new
request with the appropriate modifications. This new request
constitutes a new transaction and SHOULD have the same value of the
Call-ID, To, and From of the previous request, but the CSeq should
contain a new sequence number that is one higher than the previous.
The "above cases" include 407, so this paragraph does apply. It says
that a new transaction *SHOULD* (not MUST) have the same Call-ID. If the
same Call-ID is used, then 10.2 says CSeq *MUST* be incremented by one.
(8.1.3.5 is itself not so strong on the CSeq - it only says "should"
which isn't at all normative.)
Of course 8.1.3.5 is generic to all messages. The primary use for
Call-ID and CSeq is within dialogs. And the incrementing of CSeq is
important to the functioning of dialogs. OTOH, CSeq isn't of much
significance at all for messages outside of dialogs.
REGISTER is something of a special case. It doesn't form dialogs, and
isn't used in dialogs. But it does establish registration state that may
then be maintained via registration refresh. It reuses the Call-ID and
CSeq machinery even though it has a different state machine.
So, when a REGISTER is successful, with a non-zero expiration time, it
is somewhat important that refreshes use the same Call-ID and
incremented CSeq values. (You can in fact refresh the registration of a
contact without this, but doing so has some less than desirable
consequences.)
If you have an active registration that you are trying to refresh, and
you are using the same Call-ID as before for the refreshing REGISTER,
then you will be using an incremented CSeq value. If that attempt fails
with a 407, and you retry it, then you use the Call-ID again, and a
further incremented CSeq for the retry.
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.
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.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
--- End Message ---
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
