Subject: RE: [SIP] INFO before 200

From: "Holland, Peter Michael (Peter)" <[email-masked]>
Date: Thu, 8 Mar 2001 13:25:16 -0000

Mark,
In your first line I think you mean:
> With the exception of overlap digits and the Continuity message, 
> transport of information in ISUP in the forward direction before a
first backward message is not guaranteed.....

Pete Holland

> ----------
> From: 	Mark Watson[SMTP:[email-masked]]
> Sent: 	08 March 2001 12:57
> To: 	'Christer Holmberg'; Billy Biggs
> Cc: 	SIP List
> Subject: 	RE: [SIP] INFO before 200
> 
> All, 
> 
> With the exception of overlap digits, transport of information in ISUP
> before ACM is not guaranteed, as there are scenarios in the PSTN/ISDN
> which can cause this information to be lost. So we needn't worry about
> information before the first response from a PSTN gateway.
> 
> After this, basically an originating PSTN gateway is being asked to
> interwork between one incoming PSTN call and multiple outgoing SIP call
> legs. This is not a new situation, services exist in the PSTN which 'fork'
> a call to multiple destinations.
> 
> The action taken at the gateway in response to information before answer
> has to be addressed at the service level. For some services, it might be
> appropriate to forward such information on all the outgoing call legs, for
> others, the service may be terminated at the gateway. You can't provide a
> generic answer, you just need to provide the capability to send the
> information between gateways, for the gateways to use as necessary.
> 
> In the INR/INF example, an INR received from one call leg in the backwards
> direction will need to be passed backwards into the PSTN. The gateway must
> remember that this request has been sent so that when the INF arrives back
> it can be forwarded along the correct call leg only.
> 
> I agree with the comment below that Gateways should identify themselves to
> each other. I don't believe that any additional behaviour should be
> required of standard SIP UAC/UASs, but when the session is between two
> gateways, there will be additional behaviour required, such as exchanging
> these INFOs before answer.
> 
> Regards, 
> 
> Mark Watson 
> Nortel Networks 
> 
> > -----Original Message----- 
> > From: Christer Holmberg [ mailto:[email-masked]] 
> > Sent: 08 March 2001 09:14 
> > To: Billy Biggs 
> > Cc: SIP List 
> > Subject: Re: [SIP] INFO before 200 
> > 
> > 
> > 
> > Hi Billy, 
> > 
> > >   Christer, 
> > > 
> > >   Based on the discussions on early media, overlap dialing, and 
> > > ISUP-SIP-ISUP tunnelling, I see these general requirements 
> > for gateways: 
> > > 
> > >   1. The caller needs to send additional information to the 
> > called party 
> > >      before the gatewayed call is established (digits?  random ISUP 
> > >      messages?  who knows what else). 
> > 
> > I agree. 
> > 
> >  
> > >   2. The called party needs to send required additional 
> > information to 
> > >      the caller before the gatewayed call is established 
> > (all the stuff 
> > >      you need PRACK for). 
> > 
> > I agree (even if I am not sure you really need PRACK for all that, but 
> > that's another issue...). 
> > 
> >  
> > >   3. Media must be allowed to flow before the gatewayed call is 
> > >      established (this is clear from implementations out there). 
> > 
> > I agree. 
> > 
> > So, I do agree on all these requirements. The issue is how it will be 
> > done. 
> > 
> >  
> > >Each of these requirements implies the establishment of a 
> > >point-to-point connection.  Otherwise, the called party may have 
> > >incomplete information (one INF message sent to one gateway, 
> > another INF 
> > >message to a separate gateway). 
> > 
> > I am not sure that is the biggest problem, because it can be solved 
> > using Route headers in provisional responses. During the 
> > overlap dialing 
> > discussion we agreed (I hope) that a gateway should ALWAYS 
> > send some 18x 
> > provisional response when the INVITE is received. 
> >  
> > >I think that it is ridiculous to define extensions each of these 
> > >requirements. 
> > 
> > I agree, because then we would end up with a ISUP-on-IP protocol... 
> > 
> > >I strongly believe that if a gateway wishes to handle an 
> > >incoming call, it should establish a point-to-point 
> > connection first and 
> > >then worry about call setup on the gatewayed side.  Then we can worry 
> > >about defining extensions to convey state about the 
> > gatewayed call, and 
> > >all of the ISUP proxying can be happily done using INFO. 
> > 
> > If our gateway always talks to another gateway (ie we only use if for 
> > ISUP trunking) I guess we could send a 200 when the SIP connection is 
> > established, even if the PSTN side still needs information before the 
> > end-to-end connection can be established. 
> > 
> > The issue is that a gateway can also speak to a SIP phone. In 
> > this case, 
> > the gateway still would have to send a 200 when the connection is 
> > established, because it doesn't know if more information is needed to 
> > establish the call. It may not even know if the sender is a gateway in 
> > the first place... Of course, we can indicate in the INVITE if the UAC 
> > is a gateway or a SIP phone, and the UAS will then behave different 
> > depending on that. 
> > 
> > This again shows something I have mentioned before. I think that a 
> > gateway should be defined as a separate SIP node, not as a UA as it is 
> > now. This would make it possible to define specific behaviour, and 
> > possible a number of extensions, which have to be supported. 
> > 
> > >I'm scared about the alternative (which seems to be the current 
> > >direction).  It seems evident that the eventual requirements are: 
> > > 
> > >   1.  All gateways MUST support sending and receiving PRACK. 
> > 
> > I am not sure if that is a MUST, unless we will start sending ISUP 
> > information in the PRACKs - which I hope we will not. 
> >  
> > >   2.  All gateways MUST support extension X for sending 
> > INFO messages to 
> > >       some address received in some 18x response. 
> > 
> > It is still to be defined if any extensions are needed. 
> > 
> > It depends on how this whole issue will be solved. In 
> > general, however, 
> > I don't see it as a huge problem that a gateway would have to 
> > support a 
> > specific extension. It would simply be a MUST for a "Gateway 
> > SIP Node". 
> >  
> > >   3.  All phones calling a gateway MUST send SDP and be prepared to 
> > >       receive early media (difficult when you try to 
> > transfer a phone 
> > >       which is on hold!) 
> > 
> > I don't see this as a problem for the gateway. Instead I would use a 
> > typical answer for this: If a phone can't handle it, don't buy that 
> > phone... :) 
> >  
> > >   4.  All proxies must be configured to never fork or 
> > cancel a call to a 
> > >       gateway. 
> > 
> > This is a question of how the operator configure his network. 
> > If a call 
> > is supposed to go to a specific gateway, and since that gateway most 
> > often is located on a statical place, I see no need to fork 
> > the request 
> > - at least not to do a parallell fork. 
> >  
> > >   I just think it's too complicated. 
> > > 
> > >>I agree that we could solve a number of things be having a 
> > gw-status. 
> > >>But, how would intermedite proxies handle the CINFO? 
> > > 
> > >If a SIP call is established, transactions can happily be sent along 
> > >the established call leg in both directions. 
> > 
> > When I think about it, I'm not sure it's needed. I mean, if 
> > proxies will 
> > accept the PRACK, which is also sent before the call leg is 
> > established, 
> > they should also accept CINFO, INFO, or whatever method we will use. 
> > Right? 
> > 
> > Regards, 
> > 
> > Christer Holmberg 
> > Ericsson Finland 
> > 
> > > 
> > > -- 
> > > Billy Biggs                     [email-masked] 
> > > http://www.billybiggs.com/      [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.