Brett Tate wrote:
>> Section 4 of rfc 3261 says -
>> "CSeq or Command Sequence contains an integer and a method
>> name. The
>> CSeq number is incremented for each new request within a dialog and
>> is a traditional sequence number."
>>
>> Section 12.2.1.1 says -
>> "Requests within a dialog MUST contain strictly monotonically
>> increasing and contiguous CSeq sequence numbers (increasing-by-one)
>> in each direction (excepting ACK and CANCEL of course,
>> whose numbers
>> equal the requests being acknowledged or cancelled)"
>>
>> So while sending re-invite , it has choosed running cseq number.
>
> The receiver typically should not try enforcing the "increase by exactly
> 1" rule. I mention this because prior hops might have rejected a prior
> request. Thus the cseq gap might subsequently be larger than 1 when it
> reaches subsequent destinations.
Brett isn't saying this strongly enough. From 12.2.2 of 3261:
If the remote sequence number was not empty, and
the sequence number of the request is greater than the remote
sequence number, the request is in order. It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one. This is not an error condition, and a UAS SHOULD be
prepared to receive and process requests with CSeq values more than
one higher than the previous received request.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
