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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 1 Jun 2001 04:08:03 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Sunday, May 20, 2001 9:17 PM
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt
> 
> 
> 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.

There are two things:

1. where to send pre-call-completion requests when you decide to send them,
2. when should a UAS include Contact/tags in a provisional

Item (1) does belong in bis, I think, since it currently allows for
provisionals with Contacts/tags (although I think it is still silent on
sending requests before the call completes, and that needs to change). 

Item (2) depends on the extension. SIP-T needs to say that all SIP-T
gateways have to send a provisional response with tags/Contacts in order to
get pre-call-completion requests.

-Jonathan R.

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

> Christer Holmberg wrote:
> > 
> > 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
> > 
> > Gonzalo Camarillo wrote:
> > >
> > > 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
> > >
> > > Christer Holmberg wrote:
> > > >
> > > > 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.
> > > >
> > > > >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?
> > > >
> > > > 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
> > > >
> > > > > Hello,
> > > > >
> > > >
> > > > >
> > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Gonzalo
> > > > >
> > > > > Christer Holmberg wrote:
> > > > > >
> > > > > > 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
> > > > >
> > > > > --
> > > > > 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]
> >
> > --
> > 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.

-- 
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.

_______________________________________________
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.