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

From: "Mark Watson" <[email-masked]>
Date: Thu, 15 Feb 2001 14:42:34 -0000

Gonzalo,

I don't understand your comment about the INFO Overlap proposals causing
problems for 'vanilla' SIP UAs. My suggestion was that the use of INFOs for
overlap digits be negotiated between UAC and UAS.

So, the UAC would include a 'Supported' tag if it could do overlap INFOs and
the mechanism would then only be used if both ends supported it. Otherwise
you would just kill session requests without enough digits with 484s.

Regarding Application Servers, the INFOs should certainly contain all the
digits so far (otherwise we get the problems with lost messages). I do not
believe any proxies exist which are being used today in overlap situations
and which need access to the whole called number, so we can add this
capability to the specification without hurting any existing
implementations.

Finally, there are many reasons other than simple load balancing why one
INVITE might be routed differently to a subsequent, apparently identical,
one. e.g. Time of day routing - which is certainly not 'random'. Stateful
proxies may also remember where they sent the INVITE so that subsequent
requests on the same call leg can be routed the same way.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 14 February 2001 14:31
> To: Keith Robinson
> Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; Christer
> Holmberg; [email-masked]
> Subject: Re: [SIP] Operlap dialing within a SIP network
> 
> 
> Hello Keith,
> 
> Keith Robinson wrote:
> > 
> > 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.
> > 
> 
> 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.
> 
> 
> > 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.
> > 
> 
> 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
> 
> 
> 
> > 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.
> 
> -- 
> 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]
> 
> _______________________________________________
> 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: Thu, 15 Feb 2001 23:42:14 +0200

Hi,

Again, I am Gonzalo, but I will also comment... :)

Mark Watson wrote:
> 
>Gonzalo,
> 
>I don't understand your comment about the INFO Overlap proposals
>causing problems for 'vanilla' SIP UAs. My suggestion was that the use
>of INFOs for overlap digits be negotiated between UAC and UAS.

My personal opinion is that, even if this overlap dialing thing seems
like a very difficult problem to solve, the functionality itself is
pretty minor, so I don't think that a UA should have to negotiate about
the method to use for this... Also, I don't think your negotiation
proposal would work. You should remember that you have to reach the UAS
before you can do this negotiation in the first place, which means you
may have to send a number of INVITEs, and receive 484 responses from
proxies. And, even when you reach the UAS (let's assume it's a PSTN
gateway), it may be able to forward the digits, so the only answer you
are going to get is 100 - which you will get from the first proxy, so
the UAS can't include the negotiation result there. 

This response-from-the-UAS thing is, however, related to another issue
which I will describe in another mail.
 
>So, the UAC would include a 'Supported' tag if it could do overlap
>INFOs and the mechanism would then only be used if both ends supported
>it. Otherwise you would just kill session requests without enough
>digits with 484s.

See my comment above why I don't this would work very well.
 
>Regarding Application Servers, the INFOs should certainly contain all
>the digits so far (otherwise we get the problems with lost messages).
>I do not believe any proxies exist which are being used today in
>overlap situations and which need access to the whole called number,
>so we can add this capability to the specification without hurting any
>existing implementations.

Well, well, well... Let's assume it's a proxy that sends the 484
response. Then, if you want to start using INFO, this proxy must
remember the INVITE, and collect the INFOs. Then, when the proxy has
enough digits, what shall it do then? Create an INVITE of it's own? What
will then happen when the UAC receive the response for an INVITE it
never created? Also, when the proxy sends the INVITE, it may receive 484
responses from the NEXT proxy in the network, asking for more digits.
Ie, your proxy would have to both collect digits from the UAC, and
handle the next entity (in this example, another proxy) in the SIP
nework. All this would DEFINITELY hurt existing implementations, so you
would also have to negotiate with the proxies if they are able to do
this...

In this case I think Keith's proposal, ie that the proxy is smart enough
to see that the only thing that has changed in the new INVITE is the
receiver digits, is MUCH easier to implement :)
 
>Finally, there are many reasons other than simple load balancing why
>one INVITE might be routed differently to a subsequent, apparently
>identical, one. e.g. Time of day routing - which is certainly not
>'random'. Stateful proxies may also remember where they sent the
>INVITE so that subsequent requests on the same call leg can be routed
>the same way.

I agree, routing is a problem, but there has been proposals to solve it,
ie the one Keith gave. Also, I think that routing, and forking, is the
reason for a number of SIP related problems, so I think it is better to
find a generic solution to that. Allowing ROUTE headers in specific
situations (again, see Keith's proposal) in initial requests is partly a
solution.

Regards,

Christer Holmberg
Ericsson Finland