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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bharrat,
Shaun
Sent: Thursday, December 09, 2004 3:17 PM
To: Bob Penfield; sip-ietf; Brett Tate
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number
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 PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bob
Penfield
Sent: Thursday, December 09, 2004 3:10 PM
To: sip-ietf; Brett Tate
Cc: [EMAIL PROTECTED]
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 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-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
