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

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 30 Oct 2000 21:46:11 -0800

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.  
If the 2 UAs happen to communicate directly, the sip transaction would be
different from any previous transaction established with the proxy,
therefore the CSeq number could be whatever the UAC decides.
While I would agree with you that this does not bring much, I believe it is
valid.  

Jean-Francois.
PS: As for the Record-Route, it was omitted (while it is key to proxy
functions, isn't it optional after all? -- 6.34.1).  I'll add the
Record-route to the next I-D revision - thanks.

-----Original Message-----
From: [email-masked]
To: Jean-Francois Mule; [email-masked]
Sent: 10/30/00 7:43 PM
Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft

Jean,
in your call flows, why does the proxy change CSeq numbers ? This does
not
seem warranted. Infact,
this would throw the endpoints into total confusion if a message
happened
to reach each other directly.
(I dont even see the Proxy adding a Record Route) (see 4.3 for an
example )

Any reason why the proxy must re-write CSeq ? I dont see any in the
first
read.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Jean-Francois Mule wrote:
>
> A new Internet-Draft has been submitted, dealing with real time fax
calls
> and SIP: call flows and BCP.
>
> Comments and suggestions are very much appreciated.
> Regards,
> Jean-Francois Mule
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 3:47 AM
> Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : SIP T.38 Call Flow Examples And Best Current
> Practice
>         Author(s)       : J. Mule
>         Filename        : draft-mule-sip-t38callflows-00.txt
>         Pages           : 19
>         Date            : 16-Oct-00
>
> This document gives examples of SIP call flows for T.38 Internet fax
> communications (SIP, the Session Initiation Protocol is defined in
> RFC2543 [2] and T.38 is an ITU-T Recommendation [3]).  Elements in
> these call flows include SIP User Agents, SIP Proxy Servers, and
> Gateways to the PSTN (Public Switch Telephone Network).
> This document introduces best current practices for T.38 fax calls:
> a call starts with audio capabilities, and, upon fax tone detection,
> T.38 fax capabilities are negotiated.  The T.38 fax call scenarios
> include the detection of T.38 fax transmission by the receiving
> side, or the emitting side, or both (in the latter case, a 'glare'
> effect may appear).  The current version of this document only
> covers the case when the fax tone is detected by the receiving side
> (other cases were left for discussion and may be included in the
> future).  Call flow diagrams and message details are shown.  A list
> of IANA defined SDP attribute names for T.38 is summarized in
> section 5.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-mule-sip-t38callflows-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
<snip>

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

---

From: [email-masked]
Date: Tue, 31 Oct 2000 11:36:04 +0530

Jean,
Consider this situation:

A sends an INVITE which goes through your Proxy to B. B sends a 200 OK with
Contact as [email-masked].
This is routed through your proxy and goes to A.
Now since A has a direct path to B (and the proxy did not do a
Record-Route),
A now sends the next request (ACK) directly to B ( protocol behaviour)

The ACK must have the same CSeq as the INVITE although is a transaction of
its own. But in this case,
the ACK will have the CSeq of A - P which is different from the CSeq space
of P-B. Since ACK went directly
B would think this ACK is not valid.
The same problems will arise in any future requests within the same call
which is forwarded directly.

This , as you would notice induces incorrect behaviour.

jean> PS: As for the Record-Route, it was omitted (while it is key to proxy
jean> functions, isn't it optional after all? -- 6.34.1).  I'll add the
jean> Record-route to the next I-D revision - thanks.

Yes, its not mandatory. However in your scenario, if you do not do
Record-Route
future request can skip your proxy who then cannot change CSeq (if thats
needed in
the first place)

Regds
Arjun

Jean-Francois Mule <[email-masked]> on 10/31/2000 11:16:11 AM

To:   archow, "[email-masked] '" <[email-masked]>
cc:

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

Arjun:
there is no particular reason to propagate the CSeq number from one call
leg

Jean-Francois.

-----Original Message-----
From: [email-masked]
To: Jean-Francois Mule; [email-masked]
Sent: 10/30/00 7:43 PM
Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft

Jean,

Regds
Arjun

calls
<snip>