Subject: RE: [SIP] Overlap call setup

From: "Keith Robinson" <[email-masked]>
Date: Mon, 5 Feb 2001 09:41:31 +0000

In the absence of receiving an encapsulated ACM, the ingress
gateway could generate its own ACM when it receives a 180 Alerting; this
response must mean it is safe to assume call routing is complete
and caters for terminations within a SIP network. Thought needs to be
given to scenarios where a non-200 final response is received, say 486
Busy, as in these cases 180 Alerting, probably, wouldn't be generated.

Regards,

Keith.

"Tom-PT Taylor" <[email-masked]> on 02/02/2001 14:12:39

                                                              

 To:      Christer Holmberg                                   
          <[email-masked]>                 
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN,                     
          [email-masked], "Joshua Moloney"           
          <[email-masked]>                       

 Subject: RE: [SIP] Overlap call setup                        

Replies below.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, February 02, 2001 1:17 AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Keith Robinson; [email-masked]; Moloney, Joshua
> [MDN05:CT07:EXCH]
> Subject: Re: [SIP] Overlap call setup
>
>
>
> Hi,
>
> I see a couple of issues here.
>
> 1. Even if the UAS returns Accept-Encoding: application/isup,
> it doesn't
> mean that it is going to send an encapsulated ACM.

[PTT]
Agreed, and that is a nasty point.  It's related to the next one.

>
> 2. Even if it the UAS GW would send an encapsulated ACM, it
> is not sure
> that the UAC GW supports ISUP transparency in the first place. It may
> support only ISUP/SIP mapping, for example.

[PTT]
That one is easily solved, in two ways.  First, by hypothesis the UAC GW has
encapsulated the IAM in the initial INVITE.  It can also include an
Accept-Content: header.  In fact, this is essential so that the two ends can
negotiate stuff like ISUP version or the fact that one of them really wants
to propagate Q.931.

So, given that the UAS GW has received an encapsulated IAM, the
Accept-Content: header indicates that it did or did not find the
encapsulated content acceptable.  If it did find it acceptable, how do we
oblige it to keep up its end of the conversation?  I expect the behaviour
has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway
products have to indicate their conformity to that document.

>
> I think that part of the problem, which is not related only to overlap
> dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA,
> and from a SIP point of view should act like an SIP UA. Maybe
> it should
> be considered as a SIP node of its own, with GW specific functional
> requirements. The only thing we have now is how to map
> between ISUP and
> SIP, but that is obviously not enough. ???
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 05 Feb 2001 13:10:49 +0200

Hi,

Again, we assume that the GWs support ISUP transparency, because if the
GW only supports ISUP/SIP mapping it will not be able to know if to
generate an ACM when the 18x is received - even if the GW would be smart
enough to notice that there is SOME ISUP message in the 180 response.

Personally, I still think that a separate provisional response code
(I've been using 186 as an example) should be used, and any UAC (SIP
phone or PSTN GW) supporting overlap dialing must understand the
response. And, if the UAC knows it has already sent all digits,
receiving a 186 could, for example, cause it to send a CANCEL to the
INVITE, instead of waiting for the ISUP digit timers to expire and
receive a 486 final response.

Regards,

Christer Holmberg
Ericsson Finland

Keith Robinson wrote:
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML