Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt

From: [email-masked]
Date: Tue, 15 May 2001 07:02:09 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: ISUP to SIP Mapping
	Author(s)	: G. Camarillo, A. Roach et al.
	Filename	: draft-ietf-sip-isup-01.txt
	Pages		: 52
	Date		: 14-May-01
	
This document describes a way to perform the mapping between two
signaling protocols: the Session Initiation Protocol (SIP) and the
ISDN User Part (ISUP) of SS7.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-01.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-ietf-sip-isup-01.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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-isup-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 May 2001 14:51:51 +0300

Hi,

I have a comment about the ISUP-SIP draft, related to SIP-T.

When PRACK is used, the UAS MUST include a Contact header and a To tag
in the 18x provisional responses. 

I think it should also be a MUST for an UAS supporting SIP-T, since the
UAC may send an INFO before it has received a final response for the
INVITE. This would ensure that the INFO reaches the same node from where
the 18x provisional response came, if the INVITE was forked.

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 May 2001 15:08:39 +0300

Hi again,

I forgot a few lines from the previous mail :)

In the call flows in the ISUP-SIP draft, PRACK is used, which means the
Contact header MUST be in the provisional response. So, to ensure that
the Contact header and To tag are in the provisional response there are
two options:

1. To add the MUST, which I wrote in the first mail.

2. To add a MUST (I looked in the draft, but couldn't find it) for the
use of PRACK in SIP-T. 

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 18 May 2001 00:23:07 +0300

Hello,

I believe that this behavior is vanilla SIP, isn't it?

We use the Contact/Route in provisional responses for an INVITE to send
requests (typically PRACK, COMET and/or INFO) until we get the 200 OK
for the INVITE with the definitive Route/Contact for the session. Why
would you think we should add this in the ISUP-SIP draft?

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 May 2001 08:27:30 +0300

Hi,

>I believe that this behavior is vanilla SIP, isn't it?

I don't think it is mandatory (I appologise if I'm wrong) to include a
Contact header in a 18x provisional responses, and to include a To-tag
in a 18x provisional response. From a basic SIP standard point of view
it's optional, but different extension functionalities (eg PRACK and
SIP-T) can then make it mandatory.

>would you think we should add this in the ISUP-SIP draft?

It is nowhere said that we use Contact/Route in provisional responses
for these kind of requests - no matter what request it is. Yes, the
100rel draft says it for PRACK, and the manyfolks draft may say it for
COMET, but I haven't seen it anywhere for INFO.

My point was that I wanted to make it a MUST, or at least a SHOULD, for
nodes supporting SIP-T, to make sure that any possible INFO sent by the
UAC before the 200 is received reaches the same UAS, and that is why I
wanted to add it to the ISUP-SIP draft.

...or, it should be added to the bis draft that this is a MUST always
when the UAC may send a new request (PRACK, COMET, INFO, whatever...)
before the final response is received.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 18 May 2001 19:07:25 +0300

Hello,

As I said in my previous mail, this is a general SIP question. It has
nothing to do with the fact that you use SIP-T or that you are a
gateway.

The general question you are after is: "Where do I send requests if the
INVITE transaction is not complete yet?". 

I believe that bis should say that typically no requests are sent before
the INVITE terminates, but that there are a few exceptions, namely:
PRACK, COMET and INFO.

Then, it can be explained in bis or in the RFCs defining the extensions
where to send the requests (Route/Contact of provisional responses).

So, answering this question is up to bis and the drafts/RFCs defining
the extensions themself, but never up to the isup-sip mapping draft. We
do not explain how to locate a SIP server either, because bis deals with
it already. Let's not try to make the scope of the mapping draft wider.
Its scope is good as it is right now.

Best regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 May 2001 19:51:20 +0300

Hi,

I agree with what you say. 

So, one could argue that it should be said in the INFO RFC instead of
the ISUP-SIP draft.

HOWEVER, the INFO RFC says (unfortunately, I think...) that INFO is used
for mid-session (ie AFTER the INVITE transaction is finished) only, so
one could say it is not an issue there. Then, since the ISUP-SIP draft
is the first (and currently only) SIP extension that may also use INFO
BEFORE the INVITE transaction is finished, one could argue that it
should be said there. The third option is, like you mentioned, to put it
as a general rule in the bis draft, for ANY request that may be sent
before the INVITE transaction is finished. 

My point is, that since it may cause problems for SIP-T, I want it
mentioned SOMEWHERE :) 

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 21 May 2001 04:17:04 +0300

Hello,

The purpose of INFO (before everybody began thinking that INFO can be
used for everything in the world) was to transport PSTN signalling.
However, since the INFO RFC was issued before we were ready with the
mapping draft, some minor changes will have to be added when INFO
advances to draft standard.

About a general comment in the bis draft (about where to send requests
before the 200 OK), as I said, I think it is necessary.

Regards,

Gonzalo