Subject: [Sip] RFC 3261: 32 bit CSeq number

From: "Brett Tate" <[email-masked]>
Date: Thu, 9 Dec 2004 12:53:42 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 9 Dec 2004 15:09:46 -0500

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-masked]

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 9 Dec 2004 15:39:39 -0500

> 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.

RFC 3261 Section 8 clearly indicates the context of its subsections: "In
this section, we discuss the method-independent rules for UAC and UAS
behavior when processing requests that are outside of a dialog. This
includes, of course, the requests which themselves establish a dialog."

And section 8.1 only contains the following text: "This section covers UAC
behavior outside of a dialog."  This clearly indicates its subsections
(including 8.1.1.5) do not specifically apply to requests within a dialog.

Section 20.16 defines the normative text for max CSeq: "A CSeq header field
in a request contains a single decimal sequence number and the request
method.  The sequence number MUST be expressible as a 32-bit unsigned
integer."  The normative text within section 8.1.1.5 only reduces it 31 bits
for requests outside of a dialog.  The reason requests that create a dialog
have a max of 31 bits is to allow another 2 million requests within the
dialog before exceeding the 32 bit maximum.

Section 12.2.1.1 discusses how the full 32 bits can used:

"With a length of 32 bits, a client could generate, within a single call,
one request a second for about 136 years before needing to wrap around.  The
initial value of the sequence number is chosen so that subsequent requests
within the same call will not wrap around.  A non-zero initial value allows
clients to use a time-based initial sequence number.  A client could, for
example, choose the 31 most significant bits of a 32-bit second clock as an
initial sequence number."

---

From: Adam Roach <[email-masked]>
Date: Thu, 09 Dec 2004 14:59:39 -0600

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 10 Dec 2004 08:47:10 -0500

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-masked]

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Cc: "sip-ietf" <[email-masked]>; <[email-masked]>; "Brett
Tate" <[email-masked]>
Sent: Thursday, December 09, 2004 3:59 PM
Subject: Re: [Sip] RFC 3261: 32 bit CSeq number

---

From: "Shan Lu" <[email-masked]>
Date: Thu, 23 Dec 2004 15:12:17 -0500

Brett,

But Section 8.1.1.5 does apply to in-dialog request -- for the side that
acted as UAS in dialog creation. 

12.2.1.1/RFC2161

"If the local sequence number is empty, an initial value MUST be chosen
using the guidelines of Section 8.1.1.5."

Did I miss something?

Thanks, Shan Lu 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Brett Tate
>Sent: Thursday, December 09, 2004 12:54 PM
>To: sip-ietf