Subject: RE: [SIP] Operlap dialing within a SIP network

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 5 Feb 2001 09:27:28 -0500

I think if we view the SIP Server as a B2BUA, the same reasoning does apply
as for the egress gateway to the PSTN: once the initial SIP call reaches the
SIP Server, the subsequent digits do not directly affect the state of that
initial call, and may therefore be carried in INFO messages.

I guess it's time to run through call flows and see whether the ingress
gateway can behave properly regardless of the signalling protocol beyond the
SIP Server.  I suspect Christer is right, and a 1xx response code indicating
that an onward call needs more digits is desirable.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, February 05, 2001 8:43 AM
> To: Keith Robinson
> Cc: [email-masked]
> Subject: Re: [SIP] Operlap dialing within a SIP network
> 
> 
> 
> 
> I meant 484. Sorry. :)
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> Keith Robinson wrote:
> > 
> > In your text  do you mean 484 and not 486 ?
> > 
> > If it is legal for a gateway interworking with the PSTN to gather
> > digits using the INFO message and responding with some 18X response
> > then I don't see why it can't be legal for the server you 
> have defined in this
> > scenario.
> > 
> > Such a server now has two choices for collecting digits; it 
> either issues a 18X
> > and
> > waits for further digits in the INFO message, or it issues 
> 484 and waits for the
> > subsequent INVITE.
> > 
> > The choice will probably be dictated by the 
> implementationof the digit decode.
> > If the implementation for
> > decoding digits is more efficiently used by starting it off 
> and then passing it
> > subsequent digits, the 484 method would be inefficient as 
> this would mean
> > clearing
> > down the algorithm state between INVITEs and starting it 
> off again on the
> > subsequent
> > initial INVITE (as otherwise there is a problem with the 
> subsequent initial
> > INVITEs
> > getting to the same server as I have previously highlighted); if the
> > implemtation is equally
> > efficient whether it decodes anew each time or on a digit 
> string  by digit
> > string basis, then the 484
> > method would be the best.
> > 
> > Regards,
> > 
> > K. Robinson.
> > 
> > Christer Holmberg <[email-masked]> on 
> 05/02/2001 12:14:21
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  To:      [email-masked]
> > 
> >  cc:      (bcc: Keith Robinson/MAIN/MC1)
> > 
> > 
> > 
> >  Subject: Re: [SIP] Operlap dialing within a SIP network
> > 
> > 
> > I would like to clarify the scenario a little.
> > 
> > The SIP server is NOT a normal proxy in the SIP network, 
> via which the
> > INVITE is routed to the UAS (if it was, we would use 486 
> responses until
> > the proxy can route the call to the UAS, like Tom proposed 
> earlier in
> > the Operlap Dialing thread).
> > 
> > Instead, the server could be some kind of automatic phone 
> switch, for
> > example connected to a VPN. The difference from a NAT would 
> be that it
> > is connected directly to a number of UAS, so it needs the 
> digits to be
> > able to find the correct UAS.
> > 
> > If the UAS would be, for example, a PSTN phone, the SIP 
> server would be
> > a PSTN GW, so then it would be allowed, but what is it 
> wants to use the
> > same logic to route a call to another network using SIP (or, maybe
> > another VoIP protocol).
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > > Hi,
> > >
> > > The discussion about overlap dialing has been pretty much 
> about calls
> > > from SIP to PSTN, or PSTN-SIP-PSTN.
> > >
> > > Consider the following scenario.
> > >
> > > PSTN PHONE             GW           SIP SERVER      SIP UAS
> > > -----------------------------------------------------------
> > >
> > > --- 1 --->    -- IAM -> | -- INVITE -->  |
> > >                         | <- 18x ------  |
> > > --- 2 --->    -- SAM -> | -- INFO ---->  |
> > >                         | <- 200 (INFO)  |
> > >                         | <- 18x ------  |
> > > --- 3 --->    -- SAM -> | -- INFO ---->  |
> > >                         | <- 200 (INFO)  |   -- INVITE
> > > -->
> > >                         | <- 200 (INVITE)|   <- 200 ------
> > >
> > > In this case, the SIP server (note that I am not using 
> the word 'proxy')
> > > must collect digits, sent from the PSTN side using 
> overlap dialing, to
> > > be able to find the SIP UAS, and INFO is used to provide 
> the digits
> > > after the INVITE has been sent.
> > >
> > > My question is, should a SIP server (proxy, if you like) 
> be allowed to
> > > behave like this, or MUST it send 486s, and receive new 
> INVITEs, until
> > > it is able to find the UAS?
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 5 Feb 2001 09:17:32 -0500

I see a few more messages in this thread, but I'll note now that your "SIP
Server" must be a back-to-back UA.  I'm not sure why it would send a 18x
response before it knew how to route the call to its final destination.

> Sent: Monday, February 05, 2001 6:47 AM
> Subject: [SIP] Operlap dialing within a SIP network
> 
> 
> 
> Hi,
> 
> The discussion about overlap dialing has been pretty much about calls
> In this case, the SIP server (note that I am not using the 
> word 'proxy')
> must collect digits, sent from the PSTN side using overlap dialing, to
> be able to find the SIP UAS, and INFO is used to provide the digits
> My question is, should a SIP server (proxy, if you like) be allowed to
> behave like this, or MUST it send 486s, and receive new INVITEs, until

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 8 Feb 2001 07:00:01 -0500

You are correct about using some other means of transport if ISUP
trans-shipment is all your network is doing.  If the call destination (to a
SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call
basis, however, using SIP to establish your call routing leads to using SIP
to carry the ISUP.

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 9:52 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Christer Holmberg; [email-masked]
> Hi Tom,
> Still I want to have full state in every SIP message. If the call is
> addresed to the phone number 1234, I want to have a to field that says
> 1234. I do not care if there is a leg routed thru the PSTN and another
> thru SIP.
> 
> Carrying full state is one of the beauties of SIP. If we begin using
> INFO for this, it would be the same as using SAMs. Differen names, the
> same thing... I do not want to re-create ISUP using SIP. I 
> believe that
> if the session has a destination, it should be present in the 
> to field.
> 
> Again, if a proxy is providing services for this particular call, it
> will want to see the called party number in order to trigger 
> the proper
> service. This is a very good reason for updating the to field 
> every time
> we have more digits.
> 
> I like to use SIP between two gateways because it is possible 
> to provide
> SIP services for a PSTN to PSTN call. If all we want to do is 
> finding a
> egrees gateway, we would probably want to use other protocols (TRIP &
> SIGTRAN for instance).
> 
> Regards,
> 
> Gonzalo
> 
> Tom-PT Taylor wrote:
> > 
> > Sorry, we're talking past each other.  The premise of my 
> statements is
> > that an INVITE has reached a UAS which has accepted it.  It follows
> > that the UAS did not send back a 484, but rather an interim 
> response.
> > IF more digits come along, the INFO method is there to carry them.
> > They do not affect the SIP call state; they are used beyond the UAS,
> > either in a PSTN call or in another SIP call as the case may be.
> > 
> > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > Sent: Tuesday, February 06, 2001 9:10 PM
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > Cc: Christer Holmberg; [email-masked]
> > > Hello Tom,
> > > Tom-PT Taylor wrote:
> > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call
> > signalling
> > > > has reached an egress gateway, SIP has done its job -- 
> additional
> > > > digits will not change call state.  It is therefore
> > > reasonable to use
> > > > INFO to carry the additional digits.  If we are talking
> > > ISUP-SIP, once
> > > > the destination UAS or a UAS in a B2BUA has been 
> reached, the same
> > 
> > > > consideration applies.
> > > >
> > >
> > > I do not agree with these two statements:
> > >
> > > The 1st INVITE (with just some digits) arrives to a 
> vanilla SIP UA.
> > I
> > > will return a Not Found or a 484 Address incomplete. The
> > > subsequent INFO
> > > carrying more digits will be discarded. Thus, the PSTN to SIP
> > gateway
> > > will have to re issue a new INVITE with all the digits.
> > > Therefore, it is
> > > better to begin directly using er-INVITEs rather than INFO.
> > >
> > > Besides, I do not think that SIP is just a transport protocol that
> > > carries ISUP messages between two gateways. For that, we have
> > already
> > > SIGTRAN. SIP might be used to provide services, even when the
> > > call is a
> > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete
> > > state. And a
> > > SIP message with an incomplete to field does not carry complete
> > state.
> > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call
> > based
> > > on the to field (called party number). That proxy would 
> like to see
> > an
> > > updated to field, not just a to field that contains just some
> > digits.
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > >
> > >
> > > > > From: Christer Holmberg
> > [mailto:[email-masked]]
> > > > > Sent: Tuesday, February 06, 2001 1:15 AM
> > > > > To: Gonzalo Camarillo
> > > > > Hi Gonzalo,
> > > > > I didn't say I am going to use INFO, but that is what has
> > > > > been proposed
> > > > > earlier in this thread, so I assumed INFO would be used. The
> > > > > reason for
> > > > > the discussion from the beginning was that the overlap
> > signalling,
> > > > > according to the SIP-ISUP mapping draft, may not work
> > > very well, and
> > > > a
> > > > > solution using 18x responses and INFO messages, instead of 484
> > and
> > > > > re-INVITEs, was proposed.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > >
> > > > >
> > > > > Gonzalo Camarillo wrote:
> > > > > >
> > > > > > Hello Christer,
> > > > > >
> > > > > > Why are you using INFO for sending extra digits?
> > > > > >
> > > > > > Please, check the SIP-ISUP mapping draft, overlap
> > > > > signalling section.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > > Christer Holmberg wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > --
> > > > > > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > > > > > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > > > > > Telecom R&D               Fax   :  +358  9 299 30 52
> > > > > > FIN-02420 Jorvas          Email :
> > > [email-masked]
> > > > > > Finland                   http://www.hut.fi/~gonzalo
> > > > >
> > >
> > > --
> > > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > > Telecom R&D               Fax   :  +358  9 299 30 52
> > > FIN-02420 Jorvas          Email :  [email-masked]
> > > Finland                   http://www.hut.fi/~gonzalo
> > >
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
>