Subject: AW: [Sip] CSeq question?

From: Brazier Lachlan <[email-masked]>
Date: Sun, 17 Feb 2002 14:31:47 +0100

Hello,

I used to be the opinion, that the Method name in the CSeq header was needed
to say: "This request XXX is the request with number Y"
Example:

MYREQUEST ...
CSeq: 2 MYREQUEST

would mean this is my second request of the kind MYREQUEST.

I haven't read all of bis07 (bis05 - 05 either), but I so far I didn't find
a reason for the method name in the CSeq Header. It looks pretty redundant
to the method name in the request line.

If there is a reason, could you point me there.

Concerning the paragraph you mention below (12.2.1.1), maybe the phrase

_All_ Requests within a dialog _(except of ACK)_ MUST
contain strictly monotonically increasing and contiguous CSeq sequence
numbers (increasing-by-one) in
each direction. 

would be better. ( I assume, when you are allowed to send a CANCEL, you are
not in a dialog ?!, is this right? )

Thanks for the confirmation
Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg
An: Brazier Lachlan
Cc: [email-masked]'
Gesendet: 15.02.02 22:10
Betreff: Re: [Sip] CSeq question?

Brazier Lachlan wrote:
> 
> Hello,
> 
> probably awnsered long ago, but I couldn't find it :-(
> 
> The reason I ask is, that it wasn't clear to me, if the increasing of
> the
> CSeq value in a dialog is bound to a request class (INVITE, BYE,
> MYREQUEST,
> etc.) or to requests in general.

All requests sent from A to B within a dialog, independent of the
method, have increasing CSeq, by value of 1, with two exceptions:

  1. ACK for an INVITE has the same cseq as the invite
  2. cancel for a request has the same cseq as request

So:

INVITE (cseq: 1) ---->
200 (1)<--------
ACK (1)--------->

INFO (2)--------->
200 OK (2)<-------

BYE (3) --------->
200 OK (3)<------

Can you point me to text in bis that would lead you to believe it was
per method? I think the text is pretty clear:

From 12.2.1.1:

The Call-ID of the request MUST be set to the Call-ID of the dialog.
Requests within a dialog MUST 1872
contain strictly monotonically increasing and contiguous CSeq sequence
numbers (increasing-by-one) in 1873
each direction. Therefore, if the local sequence number is not empty,
the value of the local sequence number 1874
MUST be incremented by one, and this value MUST placed into the Cseq
header. If the local sequence 1875
number is empty, an initial value MUST be chosen using the guidelines of
Section 8.1.1.5. The method field 1876
in the Cseq header MUST match the method of the request. 1877

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Feb 2002 10:09:47 -0500

Brazier Lachlan wrote:
> 
> Hello,
> 
> I used to be the opinion, that the Method name in the CSeq header was
> needed to say: "This request XXX is the request with number Y"
> 
> Example:
> 
> MYREQUEST ...
> CSeq: 2 MYREQUEST
> 

No. Nothing in the spec says that.

> 
> I haven't read all of bis07 (bis05 - 05 either), but I so far I didn't
> find a reason for the method name in the CSeq Header. It looks pretty
> redundant to the method name in the request line.

The reason is to handle the exceptions to the rule, CANCEL and ACK. As
they have the same cseq, the method name is needed to disambiguate the
responses to those requests.

> numbers (increasing-by-one) in

I will add text excepting CANCEL and ACK.

> 
> would be better. ( I assume, when you are allowed to send a CANCEL, you
> are not in a dialog ?!, is this right? )

No. Its not useful, really, but CANCEL is allowed for INVITE, either
inside or outside of a dialog.

-Jonathan R.

_______________________________________________
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