Subject: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 16 Jan 2001 02:36:41 -0800

Trying to revive a stale unresolved thread ...

Keith Robinson wrote a very good synopsis of the problems but I disagree
with the conclusions drawn.

I would also like to reiterate Jonathan's design goals for a solutions: that
a proxy should not need to know whether it is being used as an outbound
proxy or have to take special action when being used as a outbound proxy.
The UA should be responsible for taking any action required (given that the
UA is the only entity that knows whether it using a proxy as an "outbound
proxy").

We seem to have two cases on the UA side:
1)	Does not have "Outbound Proxy" configured _or_ only needs to use
outbound proxy for SIP routing of initial request in a Call Leg.
2)	Needs to use outbound proxy for all SIP messages because it lacks
some ability. Eg DNS.

And we seem to have three cases on the proxy side. The proxy is
(unknowlingly) acting as a
1)	Normal proxy for UA, may or may not Record-Route.
2)	Outbound proxy for UA, no Record-Route needed [eg outbound proxy
only used for routing initial request]
3)	Outbound proxy for UA, needs to Record-route [eg. Firewall-like
proxy that must be used for all requests]

I am a proponent of Keith second course of action, that is, the UA does
_not_ strip the Route if it cannot use it (ie, UA case 2). [And Jonathan's
original suggestion]. However, I have a slight key modification! If the UA
sends a message without using the first Route header (assuming one exists),
then the request-URI is set to the outbound proxy's address !! eg
sip:proxy_address

Let me first say that I am not in favor of using Record-Routes of the form
Record-Route: original_request_uri;maddr=proxy_address. 
Under the new record-route rules this should not be required. The "problem"
that Keith poses is a good example of why this form of record route is bad.
Whenever a Route header of this form is used, the maddr is often dropped. A
proxy that sees the request has no way of knowing whether the Request-URI is
due to a Route header that the proxy added itself (or not). In the first
case proxy should use the next route; otherwise I believe it should merely
forward the request to the Request-URI as written.

In my mind, it is this problem that causes the difficulties that are being
experienced. 

The only problematic situation of all the above outbound proxy UA/proxy
permutations is when the proxy record routes _and_ the UA does not remove
the record route. (Proxy case 3 & UA case 2). So the first Route entry is
actually the Route header added by the outbound proxy- but now the
Request-URI will be equal to the proxy's address.

A proxy should not gobble/use the next Route header unless the Request-URI
specifies the proxy itself, right?  So it makes sense that when the proxy is
(unknowingly) acting as an outbound proxy _and_ the first record-routed
proxy that you might have to route/process a message twice (logically). The
UA inserted request-uri ensures that the message is routed to the outbound
proxy and that the proxy is able to use the next Route entry.

I don't see it as a problem that the proxy receives a request (to which it
is the target) and also finds itself in the first Route - it shouldn't break
things. Spiral routes included. The proxies need to differentiate multiple
Record-Routes for spiral routes in any case !! The first proxy should see
itself as the target of the Request-URI (due to UA's actions) which allows
the proxy to process the next Route header. Finding yourself as the next
recipient should not break things - its possible for this to occur with
spiral routes in any case, right?
 
This topic brings many of the currently contentious SIP issues out into the
open: Record-Route mechanism, maddr problems, transparent proxies and of
course outbound proxies. I'm sure many people will disagree but I thought I
would at least throw another cat among the pigeons.

Regards,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

		-----Original Message-----
		From:	Keith Robinson [mailto:[email-masked]]
		Sent:	Thursday, January 04, 2001 3:42 AM
		To:	[email-masked]
		Cc:	[email-masked]; [email-masked];
[email-masked]; Jonathan Rosenberg; [email-masked];
[email-masked]; [email-masked]
		Subject:	RE: [SIP] Proxy Routing Logic

		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

		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: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 16 Jan 2001 20:20:32 -0500

> "Fairlie-Cuninghame, Robert" wrote:
> 

> I would also like to reiterate Jonathan's design goals for a
> solutions: that a proxy should not need to know whether it is being
> used as an outbound proxy or have to take special action when being
> used as a outbound proxy. The UA should be responsible for taking any
> action required (given that the UA is the only entity that knows
> whether it using a proxy as an "outbound proxy").

Before we get into details, I want to make sure we don't forget that
proxy servers can also use outbound proxies, not just UAs. 

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

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