Subject: RE: [SIP] Proxy Routing Logic

From: [email-masked]
Date: Tue, 2 Jan 2001 09:07:13 -0600

Jonathan Rosenberg wrote;
>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'm not sure if 'ignoring the Route header if the request
URI domain is not your own, and sending it to that domain first' breaks
anything.
I can see it may add another proxy to the path, but at least all record-routed
Proxies are on the path as well. Doing otherwise will break routing (I gave an
example
in one of my previuos postings). I would argue that proxy cannot blindly follow
logic 'replace RURI with Route' no matter what just like it does not proxy
responses
downstream if top-via doesn't match the server - it checks if it matches first.

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

your 2 suggestion is really close what I would have in mind. There's also
another
scenario: where Proxy receives a request with maddr where neither maddr nor host
portion of RURI matches the server.

Let's say proxy at sip.company.com receives a requests like:

sip:[email-masked];maddr=proxy.com
.......
Route: <sip:[email-masked];maddr=yet-yet-someone-else.com>

As Billy pointed out you, being the proxy, don't really want to pop Route header
 blindly. I would rather
propose something along theses lines - it is really close to your 2 case (it
also takes care of scenario where
Proxy has it's own outbound Proxy which may have its own outbound Proxy etc - if
 you were to pop Route at
every hop the message would never get to the proper Proxies):
Investigate RURI first:
1)   if maddr exist and it doesn't match your domain send message to:
     - address indicated in maddr and strip maddr.
     - or, if outbound Proxy is used, to outbound Proxy and preserve maddr
     - or, return 488 if unwilling/unable to forward the request (I explained my
 reasoning for 488 in previous posting)
2)   if maddr exist and it matches your domain strip maddr and go to 3
3)   if host part of RURI doesn't match your domain send message to:
     - address indicated in host part of RURI and preserve existing RURI and
Route(s),
     - or, if outbound Proxy is used, to outbound Proxy and preserve existing
RURI and Route(s),
4)   if host part of RURI does match your domain pop first Route header and go
back to 1
     (now your RURI is whatever Route header contained).
5)   if there's no Route header do whatever you want (get contact from your
     location/registrar server most likely) and go back to 1 (now RURI is
whatever you got
     from location/registrar server)

regards, Jacek Grabiec
sip:[email-masked]

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

---

From: "Keith Robinson" <[email-masked]>
Date: Wed, 3 Jan 2001 16:41:42 +0000

The main conflict appears to be when a call stateful proxy, which is acting as
an outbound proxy for some UAs, record routes.
The question for subsequent requests is who does the popping of the first ROUTE
entry into the R-URI ?

For the UA, the two cases are :

a) The UA pops the first route entry into the R-URI and sends to its outbound
proxy

or

b) The UA sends the request directly to its outbound proxy without modifying the
Route header and using, say, the URI in TO field as the R-URI

For case (a) the proxy (serving sipnet.com)  will see something like the
following
(Assume the original request was addressed to [email-masked])

INVITE sip:[email-masked];maddr=proxy.sipnet.com

the Route header may or may not be empty dependant on whether further
downstream proxies have record routed.

For case (b) the proxy will receive something like

INVITE sip:[email-masked]
Route: <sip:[email-masked];maddr=proxy.sipnet.com>

Now,  for case (a), the request will be routed internally to the appropriate
call state machine
using the R-URI, To, From and Call-Id headers. The request will be processed and
routed to the next server
using information obtained from the original INVITE lookup, stored CONTACT or
the ROUTE header
if present.

For case (b) the request will be routed internally to the appropriate call state
machine as for
case (a). The request will be processed and routed to the next server using the
ROUTE header
which will send it back to the this proxy, identifying the same call state
machine as before; at best
this will cause the request to be processed twice, at worst it could cause
problems with state,
duplication of output etc,. The situation could be even worse if the proxy uses
rr-params to store state
information to be returned in the R-URI, perhaps for identifying spiralled call
state machines.
To stop this from happening, the proxy would have to perform some look ahead
processing on the
Route header before deciding whether or not to actually use the next Route
entry, or merely
remove it; this is special case processing on the usage of the Route header and
could become problematic if the proxy appears more than once in the Route list
due
to spiralling.

I therefore think that the UA should function as in case (a) to eliminate the
problems associated with
case (b).

Now, consider what happens when a UA operating as in case (a) sends a subsequent
request to
its outbound proxy BUT the outbound proxy has deliberately NOT record routed
because it is not
required to keep call state; however, two further downstream proxies, serving
nextsipnet.com and
furthersipnet.com, HAVE record routed.

The UA will have constructed a ROUTE header that looks something like:

Route: <sip:[email-masked];maddr=proxy.nextsipnet.com>
Route: <sip:[email-masked];maddr=proxy.furthersipnet.com>

When the UA sends a subsequent INVITE, because it functions as in case (a)
it will pop the first Route entry into the R-URI, and send this to its outbound
proxy
as it can't resolve proxy.nextsipnet.com because it has no DNS capability.

The proxy will receive the following :

INVITE sip:[email-masked];maddr=proxy.nextsipnet.com
Route: <sip:[email-masked];maddr=proxy.furthersipnet.com>

And this is the central point of the debate; should the proxy route the above
request by popping the first route entry into the R-URI, or should it use
the maddr in the R-URI received. In this case, the proxy should clearly
route the request using the maddr in the received R-URI, otherwise
proxy.nextsipnet.com will be bypassed even though it asked to be kept
in the path; this does, however, represent special case processing dependant
on the contents of the maddr.

If the UA had functioned as in case (b) for the above situation, then the proxy
would need to route using the Route header.

So, special case processing at the proxy appears unavoidable no matter
whether the UA functions as in case (a) or case (b), and whether a proxy that is
being used as an outbound proxy has record routed or not. I think the question
has
to be is what special case processing is preferable and what are  UA mandated to
do with the Route header if they wish to use an outbound proxy for subsequent
requests.

IMO, UAs using an outbound proxy should function as in case (a) and proxies
should look at the value of the received maddr before deciding whether or not
to route using the Route header if available. This provides for the simplest
rules; requiring the proxy to look at the entries in the Route header before
deciding
if it can use the first entry (situation arising through case (b) ) seems much
more complex
and prone to error.

The text in 6.34.3 is unclear as to what a UA must do if it is using an outbound
proxy; I think
it will lead to some UA functioning as in case (a) and some as in case (b) which
is the
worst scenario as it becomes almost impossible for proxies to know which
processing
to apply.

Also, considering the above and continuing my previous point on this thread
about
a roaming UA wishing to route through the context of its home domain proxy I
have the following in mind.

A UA at visitednet.com has been given proxy.visited.net as its local outbound
proxy.
The UA wishes to set up a call through its home domain proxy to
[email-masked].
The UA may well construct a Route header to get to proxy.homenet.com which looks
like:

Route <sip:[email-masked];maddr=proxy.homenet.com>

Now, a UA that functions as in case (a) will send the following to
proxy.visitednet.com

INVITE sip:[email-masked];maddr=proxy.homenet.com

The Route header will be empty, as the UA has already popped the entry
into the R-URI.

Upon receiving this request, proxy.visitednet.com (which assumes all UA do case
(a) )
will see that the maddr refererences a domain not served by itself and so
forward the
request to proxy.homenet.com, which will see the request:

INVITE sip:[email-masked];maddr=proxy.homenet.com

which is Billy's very first example on this thread.

In this case I would want proxy.homenet.com to now route using the URI
[email-masked], which was my original point.

If the UA functions as in case (b) then proxy.visitednet.com (which assumes all
UA do case (b) )
receives

INVITE sip:[email-masked]
Route: <sip:[email-masked];maddr=proxy.homenet.com>

proxy.visitednet.com then pops the first Route entry into the R-URI and forwards
to proxy.homenet.com
which receives the following

INVITE sip:[email-masked];maddr=proxy.homenet.com

which is exactly the same as if the UA/proxy were functioning as in case (a).

So, to summarise, assuming UAs function as in case (a), if a proxy receives a
R-URI
with an maddr that does not reference the domain the proxy serves then the proxy
sends the request to that maddr, regardless of the Route headers; if a proxy
receives
a R-URI with an maddr that does reference the domain it serves then it strips
the maddr
and goes through the normal routing procedures. The only special case processing
is
the result of checking the maddr.

Regards,

K. Robinson.

[email-masked] on 02/01/2001 15:07:13

                                                              

 To:      [email-masked]                             
                                                              
 cc:      [email-masked], [email-masked], Jonathan 
          Rosenberg <[email-masked]>,                
          [email-masked], [email-masked],          
          [email-masked](bcc: Keith Robinson/MAIN/MC1)        

 Subject: RE: [SIP] Proxy Routing Logic                       

regards, Jacek Grabiec