Subject: RE: [SIP] Proxy Routing Logic

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 1 Jan 2001 23:53:39 -0500

There is a lot going on in this thread, so let me attempt to summarize some
of the issues raised. The primary question, it seems, is the required
processing at proxy foo.com when it receives a request for
sip:user@host;maddr=foo.com. Does it pop the top Route header, if there is
one, and use that? Or, does it send it to user@host first? If there is no
route header, then what does it do? Does it send 404? Proxy to user@host? 

1. It was my proposal that the UA should remove the maddr parameter before
sending to foo.com, and then the foo.com proxy would pop the top route
header and send the request there. Billy strongly objected to this, as he
wanted the maddr to be there so that transparent proxies could know the
destination ip address of the request without needing to look at actual
destination IP address of the packet. 

2. Jacek was concerned about UAs that use local outbound proxies, and who
did not have DNS support. How would they know whether the maddr, if a domain
name, was pointing to their outbound proxy or not? In one case, the maddr
would need to be stripped, and in the other case, not.

To comment on the primary issue, ignoring the Route header if the request
URI domain is not your own, and sending it to that domain first, is
dangerous, IMHO. Thats because, nearly as I can tell, it completely breaks
the existing usage of record-routing. In the existing usage, a proxy copies
the request URI in the request into the record-route, and adds its own
maddr. Requests in the reverse direction will only get routed correctly
through that same set of proxies IFF each proxy uses the top route header no
matter what. If proxies start to only sometimes use them, we will end up
with incorrectly routed requests. 

So, I would modify my proposal to satisfy some of the other requirements:

1. If there is a Route header in a request, that ALWAYS takes priority for
routing the request.
2. If there is none, and the request URI has a domain NOT matching that of
the server, but the address/domain in the maddr does, the server forwards to
the domain in the userhost portion of the R-URI. If the neither the maddr or
userhost have an ipaddress/domain matching the proxy, the proxy sends the
request to the address in the maddr. Stripping of maddr is optional.

Billy had concerns about stripping of maddr to handle transparent proxies.
This is completley bogus, IMHO. These transparent proxies would already need
to handle the far more common case where there was never an maddr to begin
with. Furthermore, I see no burden whatsoever with obtaining the destination
IP address from the packet, remembering it, and resending the request there
once the transparent proxy has done its thing.

-Jonathan R.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 29, 2000 6:44 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [SIP] Proxy Routing Logic
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> >> -----Original Message-----
> > >From: Billy Biggs [mailto:[email-masked]]
> > >Sent: Wednesday, December 20, 2000 12:54 PM
> > >To: Jo Hornsby
> > >Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; Keith
> > >Robinson; SIP
> > >List
> > >Subject: Re: [SIP] Proxy Routing Logic
> > >
> > >
> > >Jo Hornsby ([email-masked]):
> > >
> > >>>> [Of course there will be always be different routing behaviour
> > >>>> depending on whether the request has a Route or not. [...]
> > >>>
> > >>>   Right, but this decision should only occur after you've
> > >decided if
> > >>> the request is for you.  It's very important that proxies
> > >don't just
> > >>> assume the request is meant for them if it happens to 
> appear on one
> > >>> of their listening sockets. [...]
> > >>
> > > >Maybe I'm not following properly, since I'm jumping in
> > >mid-stream, as
> > >> it were, but if I get a request, I'm going to do my best to
> > >honour it.
> > >> Maybe I won't know anything about the domain in the 
> Request-URI, but
> > > >I'll SRV and A, and hopefully everything will still be okay.
> > >
> >  > By "honour it" you mean proxy it to the destination 
> indicated by the
> > >Request-URI (and maybe add a Record-Route), right?
> > .
> > >  I just want to make sure proxies don't replace the
> > >request-URI blindly
> > >with the next Route unless the request is destined for them.
> 
> >I believe they should do this, in fact.
> 
> >Note that Jo and Robert are correct; consensus was that if a 
> local outbound
> >proxy wants to stay on the path, it should record-route. 
> This results in the
> >most flexibility (enables outbound proxies who want to see 
> only the initial
> >request).
> 
> >The more interesting issue is when a local outbound proxy 
> record routes. As
> >you pointed out, the RR inserted might look like:
> 
> >sip:[email-masked];maddr=outbound.proxy.com
> 
> I'm inclined to agree with Billy: maybe we should revisit the 
> idea of including
> RURI of received requests in Record-Route. It was a good idea 
> to get around the
> problem of forwarding requests if no Contact was added by UA. 
> Even then the RURI
> 
> part was used in one direction only. Now, since all UA are 
> required to add
> Contact
> adding RURI to Record-route doesn't seem to be necessary 
> (obviously I may be
> missing
> something) and ditching it would simplify a lot, including 
> solving potential
> loop
> problems.
> 
> >However, as we pointed out before, if that proxy received 
> this exact URI
> >*without* the next Route header, this would result in a loop. Billy
> >indicated he didn't want different routing of the request 
> URI dependent on
> >the presence of Route. I agree completely, and have been 
> arguing for this
> >property in Route all along.
> 
> 
> 
> >A few solutions are possible:
> 
> >1. If you send a request to a URI that contains an maddr, 
> and you end up
> >sending it to the address in that maddr, strip the maddr out 
> before sending
> >the request.
> >2. THe proxy should never had inserted this RR in the first 
> place, since
> >using it directly will cause a loop. Rather, something like Robert's
> >suggestion would be used:
> >sip:outbound.proxy.com;uri=[email-masked].
> 
> >-Jonathan R.
> 
> regards, Jacek Grabiec
> sip:[email-masked]
> 
> 

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

---

From: Billy Biggs <[email-masked]>
Date: Tue, 2 Jan 2001 01:32:54 -0500

Jonathan Rosenberg ([email-masked]):

> To comment on the primary issue, ignoring the Route header if the
> request URI domain is not your own, and sending it to that domain
> first, is dangerous, IMHO. Thats because, nearly as I can tell, it
> completely breaks the existing usage of record-routing. In the
> existing usage, a proxy copies the request URI in the request into the
> record-route, and adds its own maddr. Requests in the reverse
> direction will only get routed correctly through that same set of
> proxies IFF each proxy uses the top route header no matter what. If
> proxies start to only sometimes use them, we will end up with
> incorrectly routed requests. 

  I want to understand you correctly.  Which of these is correct to you:

1.  If I am foo.com and I receive a request with RURI naming bar.com, I
    send it to bar.com REGARDLESS of whether there is a Route.

2.  If I am foo.com and I receive a request with RURI naming bar.com, I
    pop the top Route and send it there OR send to bar.com if there is
    no Route.

  I am STRONGLY for 1.  I can give many examples of where 2 will break.

> Billy had concerns about stripping of maddr to handle transparent
> proxies.  This is completley bogus, IMHO. These transparent proxies
> would already need to handle the far more common case where there was
> never an maddr to begin with. Furthermore, I see no burden whatsoever
> with obtaining the destination IP address from the packet, remembering
> it, and resending the request there once the transparent proxy has
> done its thing.

  More reasons not to ever strip the maddr:

1. The maddr may be a domain name, which means that stripping it will
   lose information.

2. In many transparent proxy situations, requests are IP'ly diverted to
   a special proxy by a non-SIP-aware router.  The SIP proxy has no way
   to know the original destination.  This works for HTTP, why not SIP?

3. Proxies on machines with many interfaces will appreciate being able
   to see which address the request was received on without opening a
   socket for each interface.

4. Routing decisions can be changed on proxies without changing the
   messages they generate.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Jan 2001 10:01:46 -0500

> 1. If there is a Route header in a request, that ALWAYS takes priority for

That still does not work for outbound proxies. If some distant proxy
inserts a record-route, you still have to send the request to the
outbound proxy (with the address from the Route inserted into the
R-URI). 

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 2 Jan 2001 15:56:29 -0000

> 4. Routing decisions can be changed on proxies without changing the

It's interesting that you came up with this point.

I am very much for the approach that a proxy -- well, any client
-- can send a request wherever it likes, regardless of what the
Request-URI says.  Not that I would recommend doing it lightly,
but I think this allows for incredible flexibility.

In a simple case, think of a proxy that handles tel: URLs.
It has two simple rules: if the Request-URI is a sip: URL,
do 1.4.2 magic, if the Request-URI is a tel: URL, send to
server X; in either case, do not modify the Request-URI.

If this proxy receives a request with a Request-URI beginning
tel:, then when it forwards the request, the Request-URI is
probably not helpful to the casual observer in determining
where the request is going _next_.  Does this really matter?
The Request-URI is supposed to describe the _destination_ of
the request -- as is often stated: this is one of the most
fundamental protocol invariants.

As an extension of this, I would consider it dangerous to start
second-guessing a proxy's routing decisions: what if a proxy
receives a request (Request-URI is SIP URL) with an maddr already
present, and this proxy has its own sort of "outbound proxy"?
It can't add another maddr.

The ability for a proxy to perform truly exotic routing is,
IMHO, one of the most beautiful aspects of SIP.  I would see
it as a shame to start mandating too much about what the
Request-URI should or should not look like.

Just my two.

Happy New Year. &:)

 - Jo.