Subject: RE: [SIP] Incorrect behaviour when using a local outbound proxy

From: "Keith Robinson" <[email-masked]>
Date: Tue, 17 Oct 2000 16:48:25 +0100

I think the SIP spec (bis-02) is ambiguous on the contents of the Request-URI
which has (will) lead to different implementations; in section 2, the following
is written :

"SIP URLs are used within SIP messages to indicate the originator (From),
current destination (Request-URI) .............."

and in section 4.3 the following is written :

"It  [Request-URI] indicates the user or service to which this request is being
addressed"

From the point of view of a UA, the current destination may be a very different
thing from the user or service being addressed. Using the current destination
definition, a UA may well put the address of the local outbound proxy into the
Request-URI, using the definition as per 4.3 would lead them to putting in the
logical identity of the user (or service).

When refering to current destination, does it mean the next hop destination or
the current logical destination ?

Thanks,

Keith Robinson.

Jonathan Rosenberg <[email-masked]> on 13/10/2000 22:17:46

                                                              

 To:      "'Brett Tate'" <[email-masked]>, "'Neil        
          Deason'" <[email-masked]>                     
                                                              
 cc:      "[email-masked]'"                
          <[email-masked]>,                 
          "[email-masked]'"                         
          <[email-masked]>(bcc: Keith                
          Robinson/MAIN/MC1)                                  

 Subject: RE: [SIP] Incorrect behaviour when using a local    
          outbound proxy                                      

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 12:32 PM
> To: Neil Deason
> Cc: [email-masked]; [email-masked]
> Subject: Re: [SIP] Incorrect behaviour when using a local
> outbound proxy
>
>
> > > > In testing labs I am seeing a worrying number of UA
> > > > implementations making the same mistake of sending requests
> > > > to a Proxy where the Request-URI is in the form
> > > > sip:user@<proxy-address>. I think some of the confusion may
> > > > be traced back to early SIP message flows which showed this
> > > > behaviour. I urge implementers to rectify this situation as
> > > > we are seeing this cause a great deal of confusion to
> > > > the first commercial adopters of SIP technology. These people
> > > > are not SIP protocol experts and just expect this technology
> > > > to work.
> > > >
> > > > It is often seen when using a local out bound proxy. The
> > > > situation is that the UA takes a configuration parameter
> > > > for the local proxy. You can then dial by keying in just the
> > > > user part of a SIP URL. The UA then builds a complete URL by
> > > > adding the Proxy's address and sends the message to the proxy.
> > > > The Proxy then receives an INVITE of the form
> > > > sip:user@proxy-ip - according to the protocol spec the Proxy
> > > > will route this request to the server at the given IP address.
> > > > This is obviously itself so an illegal loop is created. A
> > >
> > > An outbound proxy for userA can be configured
> > > to translate upon a received outgoing message
> > > from known userA however it wishes.  UserA
> > > dialing *69 on a phone can be sent to outbound
> > > proxy with Request-URI of *69@outboundProxy-Ip.
> > > Assuming the outbound proxy knows userA, it can
> > > change the Request-URI into the last "known"
> > > user@host that called userA.
> >
> > According to the SIP spec sip:*69@outboundProxy-Ip
> > does not map onto the last incoming caller's sip URL
> > this is specialised logic. It may exist but a truly
> > interoperable UA must still be able to work if it
> > doesn't.
> >
> > The point I was really trying to make is that a UA
> > should not write Request-URIs out to be the destination
> > of where they are being sent in the hostport when using
> > a local outbound proxy.
> >
> > Say I want to dial sip:[email-masked] but
> > the UA configured with a local outbound proxy setting
> > of proxy.this-domain.com actually sends the INVITE
> > out as:-
> >
> >         INVITE sip:[email-masked] SIP/2.0
> >         To: sip:[email-masked]
> >         From: sip:[email-masked]
> >         ....
> >
>
> A proxy receiving the above request assumes
> that the user is trying to reach the Request-URI.
> By becoming aware the need to act as an
> outbound proxy, the Request-URI can be changed
> by the outbound proxy.  When any proxy or user
> agent receives the initial INVITE, the user@hostport
> of "To" should only really mean what was supposedly
> dialed/entered to reach you (and call-leg identification).
>
> If the user agent was trying to reach
> sip:[email-masked],
> it should be in the Request-URI.  And the
>  message should be sent to
> proxy.this-domain.com if it wants to use it
> as an outbound proxy.

There are two cases here that are being intermixed.

In case one, the originating UA wants to reach a user with a specific
username AND domain name, and that domain name is totally outside the
network of the originating UA. For example, if I want to reach [email-masked],
and I'm within bar.com. In case two, I'm on a gateway and I dial a number.
There is not really a destination domain associated with this number. What
should it be?

In case one, it is absolutely INCORRECT to modify the request URI to be my
local domain. When sending the request to my local proxy, it would look
like:

INVITE sip:[email-masked] SIP/2.0

and then be sent NOT to foo.com, but to my local proxy. Changing the request
URI to bar.com to reach the local proxy is an error; user joe is not within
that namespace.

However, in case two, the destination number can rightly be considered to be
within the domain of the orginating caller. Thats because it knows how to
reach phone numbers. Remember, just because a proxy for bar.com gets a
request with a URI thats [email-masked], does not mean a user some-name
must have registered with a REGISTER. It means that the proxy for bar.com
knows what to do with the user some-name. Its perfectly fine for this proxy
to treat numbers in the user part of its domain as telephone numbers,
especially if they are indicated as such with user=phone, and then route
them to a gateway with some phone routing database.

So, in that case, if I'm in bar.com, and I dial a number - 5551212, its
reasonable to send that to my own proxy with the URI [email-masked]. In
this case its not even really a local-outbound proxy anymore. Using the IP
address of the proxy is also OK IFF the proxy is configured to know that
requests with that given IP address represent "its domain of ownership".
Using the domain name is better for lots of reasons, though, including SRV
usage. Whether this is allowed is a matter of configuration.

-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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Oct 2000 20:34:51 -0400

> the current logical destination ?

Current SIP destination. The outbound proxy is by definition not a SIP
destination (with its own SIP URL). Thus, putting its address in the
request URI makes no sense. I would prefer not to introduce yet another
term ("logical destination"), as this increases complexity. The
definition of the outbound proxy is that it differs from the Request-URI
address, so I'm not sure how much confusion there can be. (If you stick
the address of the proxy in the request-URI, it's no longer an outbound
proxy.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs