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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 13 Feb 2001 09:03:39 -0800

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 
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Feb 2001 00:21:46 +0200

Hi,

I agree 100%. Let's do things in the "pure SIP" way, and let us forget
about optimizations  that are "almost" compatible with SIP.

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]