After further study, I now agree with Brett's and Adam's interpretation that the CSeq within a dialog may be any 32-bit number (0 thru (2**32-1)). I also agree that clarification is in order since coming to that conclusion required studying text from at least 3 different locations in 3261.
I apologize for adding to the confusion. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] ----- Original Message ----- From: "Adam Roach" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]> Cc: "sip-ietf" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Brett Tate" <[EMAIL PROTECTED]> Sent: Thursday, December 09, 2004 3:59 PM Subject: Re: [Sip] RFC 3261: 32 bit CSeq number > Okay, so here's an existence proof of at least one person who has been > participating in SIP-related standardization for at least 3.5 years > being confused about the intention of the CSeq range. If we can't even > agree amongst ourselves, there's no hope that implementors will come > away with a consistent view. That's a powerful argument that > clarification is in order. > > (I'm not necessarily saying that the party in error is Bob or Brett, > simply that both have been at this for a while, and have read 3261 to > mean different things. That said, I'm pretty sure that the intention is > that CSeq values can go all the way to 2**32 inside a dialog.) > > /a > > Bob Penfield wrote: > > >Section 8.1.1.5 says: > > > > The CSeq header field serves as a way to identify and order > > transactions. It consists of a sequence number and a method. The > > method MUST match that of the request. For non-REGISTER requests > > outside of a dialog, the sequence number value is arbitrary. The > > sequence number value MUST be expressible as a 32-bit unsigned > > integer and MUST be less than 2**31. As long as it follows the above > > guidelines, a client may use any mechanism it would like to select > > CSeq header field values. > > > >The maximum value stated applies to ALL requests. The phrase "For > >non-REGISTER requests outside of a dialog, the sequence number value is > >arbitrary" refers to the requirement that REGISTER requests (for the same > >Call-ID) and in-dialog requests must always have increasing CSeq numbers. > >This phrase does not mean that in-dialog and REGISTER requests may exceed > >the stated limit of less than 2**31. > > > >In section 12.2.1.1, there is text that implies that the CSeq may be any > >32-bit value, but this is non-normative illustrative text. The restriction > >in 8.1.1.5 still applies. > > > >cheers, > >(-:bob > > > >Robert F. Penfield > >Chief Software Architect > >Acme Packet, Inc. > >130 New Boston Street > >Woburn, MA 01801 > >[EMAIL PROTECTED] > > > > > >----- Original Message ----- > >From: "Brett Tate" <[EMAIL PROTECTED]> > >To: "sip-ietf" <[EMAIL PROTECTED]> > >Sent: Thursday, December 09, 2004 12:53 PM > >Subject: [Sip] RFC 3261: 32 bit CSeq number > > > > > > > >I have recently observed that some vendors are reading RFC 3261 section > >8.1.1.5's CSeq maximum value comments out of context. They are interpreting > >the statement to also apply to requests within dialogs. They are not > >noticing the text within sections 8 and 8.1 which indicate that these > >subsections apply to requests outside of a dialog. Is it possible to get > >the sentence reworded for clarity within errata and/or a future bis? > > > >RFC 3261 section 8.1.1.5: > >"The sequence number value MUST be expressible as a 32-bit unsigned integer > >and MUST be less than 2**31." > > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use [EMAIL PROTECTED] for questions on current sip > >Use [EMAIL PROTECTED] for new developments on the application of sip > > > > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use [EMAIL PROTECTED] for questions on current sip > >Use [EMAIL PROTECTED] for new developments on the application of sip > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
