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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Feb 2001 20:43:52 -0500

This happens naturally: the VOIP PBX knows its dialling plan and can tell if
not enough digits have been received.  By hypothesis, the outgoing gateway
to the PSTN is unable to tell if all needed digits have been received, but
knows how to route the call onward.

Christer raised the issue of how to handle the case where an entity beyond
the gateway determines that more digits are needed.  I would suggest that it
works the same as a pure PSTN call: either the caller voluntarily provides
more digits or the call eventually times out and fails.

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2001 12:04 PM
> To: Watson, Mark [MAIFP:EP11-M:EXCH]; Gonzalo Camarillo
> Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; Christer Holmberg; sip
> Subject: RE: [SIP] Operlap dialing within a SIP network
> 
> 
> The question is, how do we differentiate between a PSTN gateway and an
> VoIP PBX. Both can take advantage of additional digits; only 
> one of them
> is capable of receiving ISUP. In the VoIP PBX case, you would want the
> additional digits to be sent the "pure SIP" way, i.e. through a
> re-invite.
> 
> -- Christian Huitema
> 
> -----Original Message-----
> From: Mark Watson [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2001 6:00 AM
> To: 'Gonzalo Camarillo'; Mark Watson
> Cc: Tom-PT Taylor; Christer Holmberg; [email-masked]
> Subject: RE: [SIP] Operlap dialing within a SIP network
> 
> 
> Gonzalo, 
> I'm not sure were completely understanding each other here. 
> I think we do agree that there is value in the SIP-T concept, so that
> the PSTN can interwork with services provided in the 'pure 
> SIP' network
> by SIP proxy servers.
> I think that the path we're on of including ISUP messages inside SIP
> messages is as good as any other for this, so I don't see any value in
> pursuing alternatives, such as setting up a SIGTRAN session 
> for the ISUP
> signalling.
> I do not see the problem, though, with allowing PSTN gateways 
> to switch
> to a more efficient mode of overlap signalling once the gateway out of
> the SIP network has been identified. Sure, whilst the call is still
> progressing through the SIP network, and we want to make use of the
> routing capabilities in the SIP network, we use normal SIP procedures,
> but once we have hit the PSTN gateway, why not optimise things ?
> <snip> 
> > > 2) The UAC must use source routing to ensure that all 
> these INVITES 
> > > make it to the same UAS 
> > 
> > What is the problem here? This is done in order to address 
> the problem
> 
> > of proxies performing load balancing. Some folks have 
> pointed out that
> 
> > maybe the betwork wants to route the second INVITE in a 
> > different way... 
> > why the network would like to do that? The policy that is 
> > applicable to 
> > the fist INVITE (that contained a prefix of the number) 
> should be the 
> > same that applies to the subsequent ones. 
> Why ? How can you possibly know that all services in all networks will
> work this way ? There are a host of reasons why routing of the INVITE
> might vary due to factors other than the digits. INVITES for the *same
> digits* might route differently, and not just due to load balancing.
> <snip> 
> > > The price we pay for this is that intermediate proxies 
> may not have 
> > > access to the full Called Party Number - but a proxy that 
> > needs this, 
> > > that wants to offer service on overlap calls, can always 
> sniff the 
> > > overlap digits as they go past. 
> > 
> > Let me get this straight. Are you are proposing to change 
> the logic in
> 
> > all the already existing proxies because you want to 
> provide services 
> > when you use INFO for carrying SAMs? This is just impossible. 
> > 
> All proxies which want to provide services: 
> a) which operate *after* the INVITE has been routed and the 
> terminating
> point in the SIP network found, 
> b) which require access to the full PSTN number, 
> c) on PSTN -> SIP-T -> PSTN calls, 
> d) which are delivered on overlap calls, and 
> e) which do not know the dial-plan well enough to identity
> end-of-dialling themselves. 
> I think right now this is the empty set, so, yes, I can upgrade all
> these :-) 
> Regards, 
> Mark Watson 
> Nortel Networks 
> > I still prefer a mechanism that do not require changes in 
> the existing
> 
> > proxies (multiple call-legs). 
> > 
> > Best regards, 
> > 
> > Gonzalo 
> > 
> > > 
> > > Regards, 
> > > 
> > > Mark Watson 
> > > Nortel Networks 
> > > 
> > > > -----Original Message----- 
> > > > From: Gonzalo Camarillo 
> [mailto:[email-masked]]
> 
> > > > Sent: 07 February 2001 02:52 
> > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] 
> > > > Cc: Christer Holmberg; [email-masked] 
> > > > Subject: Re: [SIP] Operlap dialing within a SIP network 
> > > > 
> > > > 
> > > > 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.
> 
> > > > > 
> > > > > > -----Original Message----- 
> > > > > > 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] 
> > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network 
> > > > > > 
> > > > > > 
> > > > > > 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 
> > > > > > 
> > > > > > 
> > > > > > > > -----Original Message----- 
> > > > > > > > From: Christer Holmberg 
> > > > > [mailto:[email-masked]] 
> > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM 
> > > > > > > > To: Gonzalo Camarillo 
> > > > > > > > Cc: [email-masked] 
> > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 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, 
> > > > > > > > > > 
> > > > > > > > > > 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 
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > 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 
> > > > 
> > > > _______________________________________________ 
> > > > This list is for continuing development of the SIP protocol. 
> > > > The sip-implementer's list is the place to discuss 
> implementation,
> 
> > > > and to receive advice on understanding existing sip. 
> > > > To subscribe to it, send mail to [email-masked] with 
> > > > "subscribe sip-implementors" in the body. 
> > > > 
> > 
> > -- 
> > 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 
> > 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Feb 2001 08:11:43 +0200

Hi,

>This happens naturally: the VOIP PBX knows its dialling plan and can
>tell if not enough digits have been received.  By hypothesis, the
>outgoing gateway to the PSTN is unable to tell if all needed digits
>have been received, but knows how to route the call onward.
> 
>Christer raised the issue of how to handle the case where an entity
>beyond the gateway determines that more digits are needed.  I would
>suggest that it works the same as a pure PSTN call: either the caller
>voluntarily provides more digits or the call eventually times out and
>fails.

That is the way it must work, because the entity beyond the gateway can
not tell the gateway to send a 484 response to ask for more digits. 

And, at the end, what I mentioned before, if the sending gateway
receives more digits, nothing stops it from sending re-INVITES - no
matter if a 484 has been received for the previous INVITE or not.

Regards,

Christer Holmberg
Ericsson Finland 

> > > > > > > > > > >                         | <- 200 (INVITE)|   <-
> 200