Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal ls - Internet Draft)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 03:29:22 -0500

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2000 12:46 AM
> To: [email-masked] '; [email-masked] '
> Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax
> cal ls - Internet Draft)
> 
> 
> Arjun:
> Thanks for your comments.  
> For the proxy, the 2 call legs constitute 2 distinct SIP 
> transactions so
> there is no particular reason to propagate the CSeq number 
> from one call leg
> to the other.  

No.

The call flow is a very standard re-INVITE type of thing. There is no reason
why this proxy should behave any differently from any other proxy. Proxies
do not modify CSeq. Period. There is no reason why this cannot be a standard
flow, and for purposes of interoperability, it should be. The flow you have
in the document is not compliant to the spec.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jean-Francois Mule <[email-masked]>
Date: Wed, 8 Nov 2000 21:00:34 -0800

If No, then No.
For my own records, can you quote the part of the current specification(s)
stating that proxies MUST NOT modify the Cseq?  I've screened rfc2543bis-02
again and I cannot find any statement that would flag the proposed call flow
as "not compliant" (the call flow in question illustrated a proxy modifying
Cseq on 2 call legs).  Any time the usage of Cseq is explained, it is in
reference to a particular call leg or SIP transaction.

It understand it is one thing to implement a profile of the spec that
follows the common sense to encourage interoperability(why would you ever
purposely increment Cseq in a proxy?), however, the spec should
unambiguously clarify this.  And this was the intent of this separate
thread.

Jean-Francois Mule
PS: I'll modify the call flow to reflect the same Cseq on both sides because
this is not the intent of the SIP-T.38 ID.  So, yes.

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 09 Nov 2000 10:54:53 +0100

Jean-Francois Mule wrote:
> stating that proxies MUST NOT modify the Cseq?

It's a definitional thing, so to speak. If the CSeq is changed the
request doesn't belong to the same transaction and is simply a different
request. A proxy modifies requests in transit but by definition relayed
requests are equivalent to the original request in some sense, and
certainly must belong to the same transaction.

Anders

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 9 Nov 2000 12:13:07 +0200

Section 12.1.3 of the bis states:

"The To, From, Call-ID, and Contact tags are copied exactly from the
original request. The proxy SHOULD change the Request-URI to indicate the
server where it intends to send the request."

So I guess it says nothing about the Cseq.  Frankly, I think it should state
all the headers that may not be copied and indicate that the rest MUST be
copied.

Regards,
Hisham Khartabil
Hotsip Finland

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jean-Francois Mule
Sent: Thursday, 9 November 2000 7:01 AM
To: 'Jonathan Rosenberg'; [email-masked]; [email-masked]
Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax cal
ls - Internet Draft)

If No, then No.

Jean-Francois Mule

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 09 Nov 2000 09:27:43 -0500

Suggested wording change that reflects the fact that proxies should copy
the whole request, not just the minimal header fields:

The proxy server {\MUST} copy all request header fields to the outgoing
request. It {\MAY} add other header fields.