Subject: Re: [SIP] Overlap call setup

From: "Keith Robinson" <[email-masked]>
Date: Mon, 5 Feb 2001 14:08:19 +0000

Christer wrote ;

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

Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must be rules
to dictate
which SIP messages map to which ISUP messages and in what context. In fact,
aren't these the rules
we are debating ? The point being that even if a GW is ONLY performing
SIP/ISUP/SIP mapping
then it STILL MUST know when to genrate the ACM as part of the mapping function,
REGARDLESS of
transparency.

Regards,

K. Robinson.

Christer Holmberg <[email-masked]> on 05/02/2001 11:10:49

                                                              

 To:      Keith Robinson/MAIN/MC1@MCMAIN                      
                                                              
 cc:      Tom-PT Taylor <[email-masked]>,          
          [email-masked], Joshua Moloney             
          <[email-masked]>                       

 Subject: Re: [SIP] Overlap call setup                        

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:
>
> 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
> >
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 05 Feb 2001 16:20:25 +0200

Hi,

Keith Robinson wrote:
>Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must >be rules to dictate which SIP messages map to which ISUP messages and in >what context. In fact, aren't these the rules we are debating ? The point >being that even if a GW is ONLY performing SIP/ISUP/SIP mapping
>then it STILL MUST know when to genrate the ACM as part of the mapping >function, REGARDLESS of transparency.

Yes, and since it may not be possible to have rules when a 180 should
generate a ACM, and when it should not. So, in the case of overlap
dialing, when the 18x is only used to "ask" for more digits, my
suggestion was to use a specific provisional response code that would
not generate an ACM. 

Then, when we want an ACM to be generated, no matter if ISUP
transparency is supported or not, we would send a 180 Alerting.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 06 Feb 2001 09:51:34 +0200

Hi,

I had a look through the thread, and I still have one issue.

I do NOT think that we can assume that the PSTN GW will know how many
digits are needed to route a call to the PSTN end-user, so I don't think
we can use provisional responses to "ask" for more digits. Yes, the GW
may know how many digits it needs to route the call to the next PSTN
switch, but it doesn't know how many digits that switch needes, etc...

So, my proposal would be:

1. When the INVITE has been routed to the GW UAS, the only response sent
back is 100. That would, of course, assume that we have to add Contact
and/or Record-Route headers in the 100 response...

2. Then, the UAC would use INFO to send more digits to the UAC, which
would forward them as SAMs. No, the GW would not "ask" for more digits,
but does it really have to? If the UAC wants to send more digits, it can
do so anyway, so...

3. THEN, when the GW receives ACM from the PSTN side, it would send a
18x provisional response back to the UAC. The UAC would now know that no
more digits are needed to route the call. Of course, we can get a
"please enter your code"-message, and be asked to provide digits, but
that is another issue.

We should remember that the GW SIP UAS may not even know that the UAC is
sending more digits, because it may send them in encapsulated ISUP
messages. In that case, however, the GW SIP UAS will not know it's SAMs,
so it couldn't make a decission on if to send 186 "Gimme more digits" or
not...

Regards,

Christer Holmberg
Ericsson Finland