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

From: "Keith Robinson" <[email-masked]>
Date: Wed, 14 Feb 2001 10:00:24 +0000

Gonzalo,

     It seems you have two main reasons against the use of the INFO
method for the conveyance of subsequent ISUP information:

1) Lack of ordered delivery of the INFO messages

Ordered delivery could be maintained by the UAC not sending the next INFO
until a 200 OK response for the previous one had been received.

2) Lack of state carried in the INFO messge

The digits received so far could be carried in a header within the
INFO message. Each INFO message would then carry the same information
as a re-INVITE.

My reason for exploring the use of INFO is not to save on messages. It is
to do with the issue of source routing. Again, my concern of source
routing is not one of a technical nature. What if an administration has a
security policy that states source routing (a ROUTE header in
an initial INVITE) will not take place in its SIP network but it also requires
that
the same network interworks with the PSTN; if any part of the PSTN interworking
mechanism
relies on source routing then there is a conflict of requirements. It is this
conflict
I wish to address.

Regards,

K. Robinson.

Gonzalo Camarillo <[email-masked]> on 01/01/88 00:39:14

                                                              

 To:      Jonathan Rosenberg <[email-masked]>        
                                                              
 cc:      "'Tom-PT Taylor'" <[email-masked]>,      
          Christer Holmberg                                   
          <[email-masked]>,                
          [email-masked](bcc: Keith                  
          Robinson/MAIN/MC1)                                  

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

Hello,

Jonathan Rosenberg wrote:
>
> 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.

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

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

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Wed, 14 Feb 2001 12:53:31 +0200

Hi,

I am not Gonzalo, but I will comment anyway... :)

>until a 200 OK response for the previous one had been received.

I am strongly against that. We would have to start buffering incoming
SAMs, and by having to wait for the response before sending the next
INVITE it would slow down the setup time between the nodes.

This is also related with the PRACK issue, where we also may have to do
buffering becuase we have to wait for messages (which means we may have
to do buffering), but that is another issue...
 
>an initial INVITE) will not take place in its SIP network but it also >requires that the same network interworks with the PSTN; if any part of >the PSTN interworking mechanism relies on source routing then there is a >conflict of requirements. It is this conflict
>I wish to address.

I am not sure I understood this correctly. But, in either case the UAC
will have to send an initial INVITE, so it can choose to insert a ROUTE
header. I think that the administrator proxies in the network should be
able to handle that, e.g. either by refusing the message (a proxy should
have the last say about if a message is allowed to be routed in a
specific way or not), sending a 3xx response (to re-route the call), or
simply by removing the ROUTE header (I know that is not allowed, but the
there is also an issue of allowing ROUTE in the initial INVITE in the
first place, so...). In another mail I pointed out that the network
operator administrator most likely wants to have good control of the
network, so I think it should be allowed for proxies to do these kind of
things. Otherwise one can send anything in the requests, and soon we
will have a bunch of "SIP Viruses" out there... 

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Feb 2001 16:31:20 +0200

Hello Keith,

> INFO message. Each INFO message would then carry the same information

Actually my main reason against the use of INFO is that it does not work
with vanilla SIP UAs and vanilla SIP Application Servers. How you
resolve the technical issues related to INFO does not really matter to
me. It is not "vanilla" SIP, and I am against this kind of non-standard
mechanisms.

> relies on source routing then there is a conflict of requirements. It is this

OK, let's address this. Source routing is proposed in the draft to
address load balancing. This is, a proxy that sends INVITEs to different
egrees gateways.

So, if an IAM and one SAM are received, the second INVITE might end up
in another gateway than the fist INVITE. This would trigger 2 IAMs
instead of 1 IAM and 1 SAM.

OK, this is the problem that has to be solved. What I wanted to say in
the draft (I did not have lot of time and it has to be rephrased), was
the following:

It is strongly RECOMMENDED that proxies route requests that are
basically identical and just differ in the to field (more digits) in the
same way. So, if such as proxy performs load balancing, all the
subsequent INVITEs will reach the same egrees gateway.

This is not difficult to do, because most likely a call to +1234 has to
be routed in the same way as a call to +12345. So, the only real
requirement in that proxies do not make routing decisions based on
random variables (such as internal clocks).

Then, just in case folks did not feel comfortable with this solution
(which I believe is the good one), I outlined the source routing
solution.

And what about load balancing? You can still have load balancing. Your
proxy makes the routing decision based on to, from, and what ever fields
it wants. Then, it can calculate a digest of some fields, and make a
"random" routing decision based on that hash. This provides load
balancing but still routes INVITEs carrying SAMs in the proper way.

Does this resolve your issue?

Best regards,

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]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2001 13:26:25 +0200

Hi,

>me. It is not "vanilla" SIP, and I am against this kind of non-standard

Like I wrote in another mail on the thread, we have a problem using
INVITEs too. They all represent different call-legs, and since ROUTE is
per call-leg only, every INVITE will be processed as an initial INVITE,
and having ROUTE headers in an initial INVITE is still a problem and
open issue, so I would not say it is "vanilla" SIP...
 
>>that the same network interworks with the PSTN; if any part of the PSTN interworking
>>mechanism relies on source routing then there is a conflict of requirements. It is this
>>conflict I wish to address.
>>
> 

The problem is that you recommend this in the ISUP-SIP draft, which most
of the
proxy vendors may not even have read... If this is something to be
recommended for
proxies, I think it must be in the bis draft. Otherwise I think we must
add some kind of
Proxy-Require option-tag in your draft, but then it's not "vanlilla" SIP
anymore, so...

Another recommendation could be that proxies that DO change the routing
shall send a CANCEL to where the previous INVITE was sent, unless a 484
response was received for that INVITE. That way we would not have
multiple "pending" call setups on the PSTN side.

Actually, if we would make all this as a Proxy-Require option-tag
("Proxy-Require: overlap", or something...), compliant proxies MUST to
all this. Then, if you don't want to get the routing-, and multiple
IAM-, problems in your network, you just buy these kind of proxies.
Simple :)
 
>random variables (such as internal clocks).

Well, now you assume that the "load balance" stuff in the proxy is done
depending on the user part, ie. the phone number, which I don't think is
always going to be the case.

A proxy may not even look at the phone number. It may send the INVITEs
to different gateways anyway, for example if the DNS lookup for the next
INVITE will return different IP addresses, IP addresses in different
order, or whatever... There may also be other reasons, load balance
reasons, why you would send your INVITEs to IP addresses, without even
looking at the user part (in this case, the phone number). We should
also remember that a proxy will not always send the request to the
gateway. It may go to another proxy, etc etc.
 
>(which I believe is the good one), I outlined the source routing

That is one, unfortunately very common, way to "solve" problems... :)

>balancing but still routes INVITEs carrying SAMs in the proper way.

This is what I said, but this is all stuff you assume...

I think we have two options here:

1. Add the overlap routing stuff to the bis document. It would still
only be a recommendation (a SHALL, I guess..), but that's better than
nothing.

2. Define an "overlap" option-tag, for example in the ISUP-SIP draft.
Now compliant proxies would have to do the routing as you assume, and we
could even add my CANCEL proposal, and have a MUST to accept ROUTE
headers in new INVITEs at least if the phone number is different. Of
course, this would not be "vanilla" SIP, but... And, you could still use
"normal" proxies, but have to be aware of the issues that may occur.

Regards,

Christer Holmberg
Ericsson Finland