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

From: "Keith Robinson" <[email-masked]>
Date: Thu, 15 Feb 2001 11:12:15 +0000

Hello,

>I don't see this as a protocol issue, but more how the operator has
>built and configured his network. Also, you have the same problem in
>other cases too, eg with the session-timer. If a server reboots, when it
>is going to receive the refresh re-INVITE it is going to process it as
>an INVITE for a new call, and there may be ROUTE headers in that INVITE,
>so...

A proxy can be intelligent enough to distinguish between an initial INVITE
with a ROUTE header (source routing) and a re-INVITE received after
a reboot; in the case of the initial INVITE, the TO tag field MUST be empty;
in the case of the re-INVITE after a reboot the TO tag field MUST NOT  be
empty. So a proxy can be configured to disallow source routing, while
still able to support the session-timer re-INVITE after a reboot, thereby
remaining robust.

>And, I don't see how you solve this issue by using INFO. You still have
>to send at least one initial INVITE, in which your UA, for some reason,
>may insert ROUTE headers. Again, in this case I don't see it as a
>problem if a proxy will reject that, because I think the proxies should
>decide about the routing, not the UA. However, like I mentioned earlier,
>it IS a problem with the session-timer...

Of course, clients may attempt to source route, and such requests
may well be rejected if they traverse a network with a security policy
tha disallows it. Its an interoperability issue when going between
administrative domains.

Regards,

K. Robinson

Christer Holmberg <[email-masked]> on 15/02/2001 09:51:47

                                                              

 To:      Keith Robinson/MAIN/MC1@MCMAIN                      
                                                              
 cc:      [email-masked], Gonzalo Camarillo          
          <[email-masked]>, Jonathan       
          Rosenberg <[email-masked]>, "'Tom-PT       
          Taylor'" <[email-masked]>                

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

Hi,

Keith Robinson wrote:
>
>Hi,
>
>Christer wrote :
>
><snip>
>
>>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.
>
>This is exactly my concern. What if proxies are configured to reject or
>ignore the ROUTE header of requests which are attempting to source route.
>The initial INVITEs sending subsequent digits may not reach the (correct) >UAS
if they had to traverse such networks and so the mechanism would >fail.

I don't see this as a protocol issue, but more how the operator has
built and configured his network. Also, you have the same problem in
other cases too, eg with the session-timer. If a server reboots, when it
is going to receive the refresh re-INVITE it is going to process it as
an INVITE for a new call, and there may be ROUTE headers in that INVITE,
so...

And, I don't see how you solve this issue by using INFO. You still have
to send at least one initial INVITE, in which your UA, for some reason,
may insert ROUTE headers. Again, in this case I don't see it as a
problem if a proxy will reject that, because I think the proxies should
decide about the routing, not the UA. However, like I mentioned earlier,
it IS a problem with the session-timer...

Regards,

Christer Holmberg
Ericsson Finland

>
> Regards,
>
> K. Robinson.
>
> Christer Holmberg <[email-masked]> on 14/02/2001 10:53:31
>
>
>
>
>
>
>
>  To:      [email-masked]
>
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Gonzalo Camarillo
>           <[email-masked]>, Jonathan
>           Rosenberg <[email-masked]>, "'Tom-PT
>           Taylor'" <[email-masked]>
>
>
>
>  Subject: Re: [SIP] Operlap dialing within a SIP network
>
>
> Hi,
>
> I am not Gonzalo, but I will comment anyway... :)
>
> >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.
>
> 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...
>
> >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.
>
> 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
>
> >
> > 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: Thu, 15 Feb 2001 15:34:04 +0200

Hi,

Keith Robinson wrote:
>a reboot;

Yes, a proxy can do this, and we can assume that it do that... But, like
I said earlier,
it should be written down then, either in the bis as a SHOULD, or in the
ISUP-SIP as an
option-tag extension, ie a MUST.

>in the case of the initial INVITE, the TO tag field MUST be empty;
>empty.
>So a proxy can be configured to disallow source routing, while still able to support the session-timer >re-INVITE after a reboot, thereby remaining robust.

I guess that could work. But again, how many proxy implementations work
that way? Since we can't make it a MUST for proxy (for backward
compability), the question is, again, if it should be a SHOULD in the
bis, or an Proxy-Require option tag extension.

Regards,

Christer Holmberg
Ericsson Finland