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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 9 Feb 2001 07:21:21 -0500

I think the correct answer about which approach to use (INFO vs. multiple
call legs) depends on your view of the scope of the address within the sip
cloud. If you believe that the sip role has ended once you have enough
digits to select an egress gateway (which may be as few as one, i.e., +1
selects a US gateway), then the sip address of that gateway can be viewed as
sip:[email-masked], and all subsequent digits are PSTN issues, outside the
scope of SIP. If you believe that the sip role encompasses functions that
might apply to the PSTN subscribers, then you need to have the entire
number, and the multiple call leg approach is the right way to go.

The multiple call leg approach is clearly ugly and inelegant, but it has the
nice property of completely masking the existence of overlap from proxies
and app servers within the network, allowing them to provide services in the
normal way.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Thursday, February 08, 2001 7:00 AM
To: Gonzalo Camarillo
Cc: Christer Holmberg; [email-masked]
Subject: RE: [SIP] Operlap dialing within a SIP network

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.
> -----Original Message----- 
> 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] 
> 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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Jan 1988 02:39:14 +0200

Hello,

Jonathan Rosenberg wrote:
> scope of SIP.

I definitively agree that this is the view that INFO fans have of a SIP
cloud. What I am saying is that this view is wrong. This usage of SIP
falls outside the scope of SIP.

If they want to use SIP for locating a gateway,  it is fine. But after
the gateway has been located, let's use another method for transporting
ISUP signalling.

Let's assume that I get an IAM with "+1", as Jonathan says in his
example. Then the INVITE generated by the gateway will reach the US
gateway. Now, the mission of SIP has finished, since the gateway has
been located. Why don't we put in the body of this INVITE a session
description that comprises a media session and a SIGTRAN session? This
way we would have established these two sessions between the gateways
and all the subsequent ISUP messages would be sent over the SIGTRAN
session.

I find that the usage of SIP that I have just described would be OK.
What I do not understand is why folks want to use SIP for transporting
subsequent ISUP messages. SIP does not have good transport properties
(big overhead, it can run over UDP...). Besides, it does not provide
ordered delivery.

If the INVITE has Cseq=1 and the next message that the egrees gateway
receives is a INFO with Cseq=7... what should the gateway do? Maybe
there were several proxies in the middle asking for credentials for the
INFO, so the ingrees gateway had to add authentication stuff and resend
the INFO. If this was the case, the SAM contained in the INFO would be
the second digit of the called party number... However, maybe 5 INFO
messages got lost, and the SAM that we have received in the body of the
INFO makes no sense without the previous ones because is the 7th digit
of the number... 

This is not usually a problem in SIP, since all messages have full
state. However, using INFO for sending SAMs breaks this rule, and
therefore it breaks the SIP model.

I believe that considering that the session is established after the
first INVITE and sending the following SAMs using INFO is making one of
the mistakes described in the guidelines for SIP authors: "We need to
transport ISUP signalling over IP between two gateways. Both gateways
already implement SIP... why do we have to implement another protocol?
Let's use SIP to transport ISUP signalling". We are just trying to use
SIP for this just because it would save implementing yet another
protocol in the gateways.

I strongly disagree with this usage of SIP. SIP-T is good as long as the
SIP cloud provides services. If not, SIP-T is not a good protocol for
transporting ISUP signalling.

Best regards,

Gonzalo

 If you believe that the sip role encompasses functions that

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Feb 2001 13:56:51 +0200

Sorry, but I still have some issues with this thread :) I mentioned it
earlier, but it was never discussed.

First, to comment the previous discusion, I do NOT want to "use SIP just
to transport ISUP". I never even assumed that ISUP transparency was used
(it has nothing to do with the ISUP-SIP draft) in the first place. For
the INFO proposal I assumed a specific header could be used...

However, let us leave the INFO proposal for a minute, and instead
discuss the problem with the current proposal (according to the ISUP-SIP
draft).

So, here is one issue:

Let's assume that GW B receives an INVITE, from GW A, with enough digits
to route (so, no 484 will be sent back). An IAM will be generated, and
the call setup will be routed to the next PSTN switch, switch C. Switch
C, however, DOES need more digits to be able to route the call. Switch
C, however, can not inform GW B about that, so no response, provisional
or final, other than a 100 automatically generated by GW B will be sent
back to GW A.

Now, we can assume that GW A, when it receives more digits, will
generate a new INVITE anyway, even if it didn't receive 484. So...

Issue 1: Since GW B already has established a call setup for the first
INVITE, and has also probably reserved PSTN resources etc for it.

Issue 2: Can we now require that GW B will be smart enough to compare
the digits in new INVITE with the ones in the old one, and generate the
SAMs needed?

Issue 3: To prevent issue 1 and 2, GW A could send a CANCEL for the
previous INVITE everytime it sends a new INVITE (if a 484 hasn't been
received before that). That would, however:

- Generate lots of extra SIP traffic, which is not good.

- Make the GW B process every new INVITE as a new call. That would make
the GW B first reserve PSTN resources, then unreserve them when the
CANCEL comes, reserve them again when the new INVITE comes etc etc etc.
That solution doesn't sound very good either, I think...

I also agree that operlap dialing will not be very widely used, but it
may be used in PSTN-SIP-PSTN cases, so...

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 12 Feb 2001 15:58:40 +0200

Hello Christer,

Comments inline:

> generate a new INVITE anyway, even if it didn't receive 484. So...

Yes, so far this is correct.

> INVITE, and has also probably reserved PSTN resources etc for it.

Yes. In the normal case it has reserved a timeslot in a E1. This does
not have to change, since the arrival of more digits will not require
more resorces. The resources needed for the call are defined in the IAM.
The SAMs just add more digits to the called number. Nothing more.

> the digits in new INVITE with the ones in the old one, and generate the

The new INVITE has the same call-ID as the first one. Thus, everything
that the gateway has do to is sending a SAM with the new digits.

I do not think this is a complicated operation. Just parsing a SIP
message involves more complicated operations than this one.

> received before that). That would, however:

Besides your points, this is a bad idea because if the CANCEL arrives
before the new INVITE, the result is that the egrees gateway sends a REL
and then a new IAM. This is what we want to avoid.

Actually this one was one of the first proposals for overlap signalling
(long time ago...).

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Feb 2001 16:32:17 +0200

Hola!

>message involves more complicated operations than this one.

It may not be complicated, but maybe it should be pointed out somewhere.
However, a request may be forked, and a proxy may for some strange
reason change the whole Request-URI, so that two different INVITEs for
the same Call-ID is received, but I think it is an implementation issue
how the GW handles those kind of situations.

>and then a new IAM.

That is what I meant would happend, and it is not a good idea.

>This is what we want to avoid.

I couldn't agree more on that :)

Regards,

Christer Holmberg
Ericsson Finland