Subject: RE: [SIP] INFO before 200

From: "Mark Watson" <[email-masked]>
Date: Thu, 8 Mar 2001 12:57:55 -0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 08 Mar 2001 15:35:15 +0200

Hi Mark,

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

Yes, and if we agree that the UAS GW always sends a provisonal response
(we noticed in the overlap discussion that it is needed) when the first
INVITE is received, this will not be a problem. 
 
>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.

If the UAS GW includes a Contact header in the provisional response all
messages will be sent to the same UAS GW. The problem, which I mentioned
earlier, is if the initial INVITE is forked and we receive provisional
responses from more than one UAS GW. Of course, we can then choose one
and send a CANCEL to the others.

However, my proposal is that we now concentrate on how to transport the
ISUP messages in the first place.
 
>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 think that is a gateway implementation issue. A good point, though,
and this is an issue that could be described in a "SIP gateway node"
description.
 
>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.

Personally I don't have any problems to allow INFOs in the forward
direction before the call is setup and the final response is received. 

My question is to the proxy people how proxies would handle this.

Regards,

Christer Holmberg
Ericsson Finland