Subject: RE: [SIP] Overlap call setup

From: "Keith Robinson" <[email-masked]>
Date: Thu, 1 Feb 2001 16:11:38 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 01 Feb 2001 18:21:37 +0200

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

>question is what informational response to send back to the ingress when an egress has
>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
> 
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML