Subject: Re: [SIP] Overlap call setup

From: Christer Holmberg <[email-masked]>
Date: Tue, 06 Feb 2001 16:04:03 +0200

Hi,

>Certainly using explicit SIP responses minimises the need to use context
>to determine what ISUP message to generate. I am not opposed to the idea
>of using a new response to indicate that some form of routing is taking >place at the egress (or beyond).

Of course, the UAS GW could send a 186 when it receives the first
INVITE, no matter if more digits will come or not. The 186 would only be
a more "safe" (you can use PRACK etc) way then 100 to provide the UAC GW
with Contact and/or Record-Route headers, and the UAC GW would not map
it into any ISUP message. Then, IF the digits in the INVITE were enough
to route the call to the final PSTN user, and the UAS GW receives an
ACM, it would map it into a 180 and send it to the UAC GW, which then
can map it to an ISUP message.

Another issue: The case we have now been discussing is fine for
SIP-to-PSTN and PSTN-SIP-PSTN scenarios. However, if we have a
PSTN-to-SIP scenario, we would probably not send INFOs. A SIP proxy
COULD (I presented this solution in another thread), of course, send 18x
and wait for more digits, but since the call in this case is not
completely routed (the proxy is not the end user from a SIP point of
view) it would probably send 484 responses until an INVITE with enough
digits to find the SIP UAS is found.

  PSTN PHONE  GW           SIP PROXY       SIP UA
--------------------------------------------------

  -- IAM -->      -- INVITE -->  
                  <- 484 ------
                  -- ACK ----->
  -- SAM -->      -- INVITE -->
                  <- 484 ------
                  -- ACK ----->
  -- SAM -->      -- INVITE -->   -- INVITE -->
                  <- 200 ------   <- 200 ------
                  -- ACK ----->   -- ACK ----->

So, in this case we would still have to use the 484/re-INVITE mechanism,
UNLESS the proxy is allowed to only send a 18x to the first INVITE and
then wait for more digits sent in INFO messages (like I showed in the
other thread).

After all, I think that operlap dialing is going to be used almost only
in PSTN-to-SIP (and PSTN-SIP-PSTN) cases. At least I have never seen a
SIP Phone that would send digits in separate messages (you type the
whole B-number, press 'send' and everything is sent in a single INVITE)

Regards,

Christer Holmberg
Ericsson Finland

Regards,

Christer (lmfchh)

> 
> Regards,
> 
> K. Robinson
> 
> Christer Holmberg <[email-masked]> on 05/02/2001 14:20:25
> 
> 
> 
> 
> 
> 
> 
>  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,
> 
> Keith Robinson wrote:
> >
> >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.
> 
> 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
> 
> >
> > 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: "Keith Robinson" <[email-masked]>
Date: Tue, 6 Feb 2001 13:32:49 +0000

Certainly using explicit SIP responses minimises the need to use context
to determine what ISUP message to generate. I am not opposed to the idea
of using a new response to indicate that some form of routing is taking place at
the egress (or beyond).

Regards,

K. Robinson

                                                                                

                                                              

Hi,

Regards,

Christer Holmberg
Ericsson Finland