Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number

From: "Bharrat, Shaun" <[email-masked]>
Date: Thu, 9 Dec 2004 15:17:09 -0500

Bob:

Sorry, I'm confused. The initial CSEQ # for a dialog can be any
random number less than 2**31. Suppose that one picks 2**31 - 1
as the initial CSEQ. How can you send more than one packet on
the dialog without violating CSEQ < 2**31 ?

Cheers,
Shaun Bharrat
Sonus Networks

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bob
Penfield
Sent: Thursday, December 09, 2004 3:10 PM
To: sip-ietf; Brett Tate
Cc: [email-masked]
Subject: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number

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]

----- Original Message ----- 
From: "Brett Tate" <[email-masked]>
To: "sip-ietf" <[email-masked]>
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
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: "Patrick Timmons" <[email-masked]>
Date: Fri, 10 Dec 2004 08:33:14 -0500

Below is my interpretation; please feel free to correct me where I am in
error.

Each UA in a dialog has its own locally generated CSeq number.  These
initial, locally generated CSeq numbers MUST be less than 2**31.  Each
subsequent transaction within a dialog will increment the CSeq value by
one.  By choosing a starting value less than 2**31, but allowing all
values up to 32 bits (2**32), this affords each UA over two billion
(2**32 - 2**31) unique, legal values.  This is the rationale behind the
illustrative text in section 12.2.1.1 ("one request a second for about
136 years before needing to wrap around").

My own illustrative example:
A UA (the "subscriber") sends a SUBSCRIBE to a subscription server.  The
SUBSCRIBE is not inside an existing dialog, so the subscriber constructs
the CSeq in this request in accordance with the requirements of 8.1.1.5
-- that is, this value MUST be less than 2**31.  The subscription server
sends a 2xx response, and a dialog is established.  The subscription
server, in accord with RFC 3265, immediately sends a NOTIFY to the
subscriber.  This being the first in-dialog request generated by the
subscription server, it has no locally generated CSeq value.  Following
the requirement set forth in 12.2.1.1 ("If the local sequence number is
empty, an initial value MUST be chosen using the guidelines of Section
8.1.1.5"), it also MUST choose an initial CSeq less than 2**31.  With
these values established, the subscriber and subscription server will
send in-dialog requests, incrementing the CSeq values with each new
transaction.  Thus both the subscriber and the subscription server have
the luxury of over two billion valid CSeq values to use going forward --
mitigating the possibility of wrapping the 32 bit range of legal values.

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.

Pat Timmons
Acme Packet, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bharrat,
Shaun
Sent: Thursday, December 09, 2004 3:17 PM
To: Bob Penfield; sip-ietf; Brett Tate
Cc: [email-masked]
Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number

Bob:

Cheers,
Shaun Bharrat
Sonus Networks

-----Original Message-----

Section 8.1.1.5 says:

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]

----- Original Message ----- 
From: "Brett Tate" <[email-masked]>
To: "sip-ietf" <[email-masked]>
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."

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 10 Dec 2004 13:06:54 -0500

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