Sanjay Sinha (sanjsinh) wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul
> Kyzivat (pkyzivat)
> Sent: Friday, August 11, 2006 12:18 PM
> To: [EMAIL PROTECTED]
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Incrementation of Cseq inside dialogs
>
>
>
> [EMAIL PROTECTED] wrote:
>> From: sudhagar NAGARAJAN <[EMAIL PROTECTED]>
>>
>> Can anyone clarify whether Cseq is always incremented by 1 inside a
>
>> dialog? for all new requests inside the dialog.
>>
>> At some place in the RFC, it says that the CSeq should be incremented
>> by 1.
>>
>> But -- if the UA incremented the CSeq by more than 1, the other UA
>> would behave the same way, as it is required to presume that an
>> intermediate request had been lost by the network.
>>
>> But -- incrementing the CSeq by more than 1 would not be useful, and
>> would tend to consume the available CSeq space. Admittedly, a dialog
>> has a minimum of 2^31 (IIRC) CSeq numbers available, but if the UA
>> decides to increment by 2^28, it might run out of numbers.
>
> The received CSeq can increase by more than one due to lost messages.
>
> Will the lost messages not create a problem for the dialog? If client is
> using UDP, it will keep retransmitting that request and the transaction
> layer will return a 408 response which will create the dialog to be
> terminated. So how does UAC send another request on that dialog with
> higher cseq?
Yeah, I think you are right about that.
> Cases where I have seen received Cseq at UAS increasing by 1 is when a
> proxy in route list, authenticates that request.
And you seem to be right about that too.
Paul
> Sanjay.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
