> The wording of the specification is > arguably a bit fuzzy, but the intent > seems clear: prevent CSeq wrapping by > forcing each UA in a dialog to choose > sane initial values.
I agree that a UA should choose a sane initial value. Should a UAS return a 400 response, when it thinks that the UAC provided a cseq value between 2**31 and (2**32 - 1) when it should not have done so? Shaun's example of choosing a cseq with (2**31 - 1) produces an interesting situation. Because of the MUST wording, does incrementing the cseq to 2**31 and resubmitting the request because 401, 407, 422, etcetera produce a protocol violation? The UAC was aware of the prior cseq. Because the UAS might not have observed/remembered the prior request, I assume that the UAS should not reject this request with a 400 response when the cseq becomes between 2**31 and (2**32 - 1). I think that situations like the above example, dialog recovery, etcetera should be considered within the reasoning as to why it might not be wise for a UAS to return a 400 response when it thinks that the cseq value incorrectly started with a cseq between 2**31 and (2**32-1). If re-submitting a request because of 401, 407, etcetera violates the protocol, should RFC 3261 errata/bis be updated to enlighten the implementers to leave a little cseq room for resubmissions to ensure that the cseq 2**31 rule is not violated? _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
