Subject: RE: [SIP] Overlap call setup

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 1 Feb 2001 15:04:51 -0500

I've had another thought.  If the UAS returns Accept-Content:
application/isup, it could be a signal to the ingress gateway to hold its
ACM until it receives one encapsulated from the egress gateway.  In the
absence of that signal, the ingress gateway would assume that call routing
was complete upon receipt of the first 1xx response.

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH] 
Sent: Thursday, February 01, 2001 11:37 AM
To: Christer Holmberg; Keith Robinson
Cc: [email-masked]; Moloney, Joshua [MDN05:CT07:EXCH]
Subject: RE: [SIP] Overlap call setup

A new response code would obviously be unambiguous, and may be necessary.
The problem doesn't arise in the tandem case, since you could have a rule
that ACM is sent back at the ingress side only when an encapsulated ACM is
received from the egress side.  The problem is to figure out appropriate
rules for generating ACM when the termination is to the SIP network.

> -----Original Message----- 
> From: Christer Holmberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, February 01, 2001 11:22 AM 
> To: Keith Robinson 
> Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; 
> [email-masked]; Moloney, 
> Joshua [MDN05:CT07:EXCH] 
> Subject: Re: [SIP] Overlap call setup 
> 
> 
> 
> Hi, 
> 
> In this case I still think we could use another provisional response 
> (eg. 186, or whatever available...), which would not generate an ISUP 
> message, to inform the ingress GW that the call leg has been routed to 
> the egress GW, but that additional digits are needed. 
> 
> Then, when all the digits are sent, and the call has reached its 
> destination on the PSTN side, 183 messages etc can be generated. I am 
> not sure a GW would generate 183 messages by itself anyway, unless it 
> "triggered" by an ISUP message, but 186 could be triggered by the GW. 
> 
> Regards, 
> 
> Christer Holmberg 
> Ericsson Finland 
> 
> 
> >I think there is a general consensus of opinion here (for 
> case (2)); the 
> >question is what informational response to send back to the 
> ingress when an egress has 
> >been selected. The problem I have with 183 is that following 
> the text in 7.2.3 
> >of sip-isup-00.txt would cause an ACM to be generated at the 
> ingress which I don't think is what we 
> >want o do at this point. 
> > 
> > Regards, 
> > 
> > K. Robinson 
> > 
> > "Tom-PT Taylor" <[email-masked]> on 01/02/2001 15:36:08 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  To:      Christer Holmberg 
> >           <[email-masked]> 
> > 
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, 
> >           [email-masked], "Joshua Moloney" 
> >           <[email-masked]> 
> > 
> > 
> > 
> >  Subject: RE: [SIP] Overlap call setup 
> > 
> > 
> > Your flow is not what I had in mind.  I'll try to make 
> myself clearer by 
> > commenting on your flow. 
> > 
> > > -----Original Message----- 
> > > From: Christer Holmberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > Sent: Thursday, February 01, 2001 10:10 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 the disconnect here.  You are assuming that the 
> first IAM gets 
> > > >propagated through the egress gateway, so an ISUP state 
> > > machine is set 
> > > >into play.  I think the synthesis of our thinking is this: 
> > > > 
> > > >(1) The first problem is to receive enough digits so an 
> > > egress gateway 
> > > >can be selected.  Until that happens, the digits have to be 
> > > >accumulated into successive initial INVITE messages. 
> > > > 
> > > >(2) Once an egress gateway has been selected, call routing 
> > > is complete 
> > > >as far as the SIP domain is concerned.  Hence it is 
> legitimate to use 
> > > >the INFO method to carry subsequent digits. 
> > > 
> > > Let's assume the following case (hopefully I understood you 
> > > correctly): 
> > > 
> > > You want to call 12345 on the PSTN side, and in the first 
> INVITE you 
> > > only send the first digit, ie. 
> > > 
> > > INVITE [email-masked] 
> > > 
> > > The GW returns 484, which you ACK. 
> > 
> > [PTT] 
> > No.  The GW NEVER sends 484 because as far as SIP is 
> concerned, call routing 
> > was successful if the call got as far as the GW.  Instead, 
> a proxy returns 
> > 484. 
> > 
> > > Then you start sending digits with INFO, ie. 
> > > 
> > > INFO [email-masked] 
> > > more-digit: 23 
> > 
> > [PTT] 
> > Assuming it was a proxy that returned the 484, instead I 
> send another 
> > initial INVITE: 
> > 
> >   INVITE [email-masked] 
> > > 
> > > The GW returns 200, and we may send more INFOs with the 
> rest of the 
> > > digits. 
> > 
> > [PTT] 
> > Assume this time there were enough digits to route the call 
> successfully to 
> > a UAS at the GW.  It would return something like a 183 
> Session Progress to 
> > provide a Contact and establish the call state machine.  
> The ingress GW 
> > would send additional digits (and possibly encapsulated SAM 
> messages) via 
> > INFO.  The egress GW would start propagating the SAM 
> messages once it had 
> > enough digits to select next hop, but this process would be 
> invisible to the 
> > ingress GW.  The ACM would be sent back in a 180 or 183 
> interim response as 
> > appropriate, and ANM would come back in the 200 OK. 
> > 
> > > 
> > > Now: 
> > > 
> > > 1. How do we know when the call is established? Since we 
> have sent a 
> > > final response to the INVITE, we can't send a 200 OK to it. 
> > > 
> > > 2. When all the digits have reached the PSTN network, there 
> > > may be some 
> > > early media/alerting messages etc. to be sent, but again - 
> > > since the GW 
> > > has sent a final response to the INVITE, 18x provisional 
> > > responses can't 
> > > be sent. 
> > > 
> > > What do you think about the following: Instead of sending 
> 484, the GW 
> > > sends some provisional response (ie. 186 More digits 
> needed). Then we 
> > > use INFO messages(s) to provide the rest of the digits, 
> and when all 
> > > digits have reached the PSTN side, and the call can be 
> established, we 
> > > receive the 200 OK to the INVITE. 
> > > 
> > > 
> > > Regards, 
> > > 
> > > Christer Holmberg 
> > > Ericsson Finland 
> > > 
> > > 
> > 
> >   
> -------------------------------------------------------------- 
> ---------- 
> >                   Name: att1.htm 
> >    att1.htm       Type: Hypertext Markup Language (text/html) 
> >               Encoding: base64 
> >            Description: Internet HTML 
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 02 Feb 2001 08:16:43 +0200

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.

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.

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