Subject: [Sip] Strict routing/Loose routing/Outbound proxies

From: William Marshall <[email-masked]>
Date: Wed, 19 Sep 2001 10:56:48 -0400 (EDT)

The SIP spec allows a UA to ignore the rules for request-URI and
Route headers, and just send all requests to an outbound proxy.
The outbound proxy then deals with the routing of the request.
Unfortunately the outbound proxy doesn't follow the procedures of
2543bis section 16.5.

I believe this is a specific case of loose routing, and it doesn't
have or require anything special in the headers to enable it.

It would be unfortunate if the outbound proxy needed some type
of configuration information in order to do this correctly;
especially since the proxy may be an outbound proxy for some
requests, a tandem proxy for some requests, and a destination
proxy for other requests.

I propose the following algorithm for combining all of these
cases:
	the proxy examines the Request-URI, and determines if
	the Request-URI identifies itself.

	if so, move the first entry from the Route header
	to the Request-URI, and go back to first step

	if not, send the request toward the host
	identified in the Request-URI, leaving Request-URI
	and Route header unchanged.

In the third step above, "toward" means either directly to
the identified host, or to another (possibly pre-configured) 
proxy that is by some measure "closer" to the identified host.

One other important case that this algorithm covers is a SIP proxy
that is controlling a firewall (when firewall control is done separately
from outbound services).  When the Request-URI identifies
a host outside the firewall, the outbound proxy needs to send
the request to the firewall controller rather than directly to
the intended destination.

Note this algorithm can also be applied to the UA initiating
the request - the outbound proxy is the pre-configured destination
that is "toward" all other destinations.

This algorithm also covers the routing of the initial INVITE request
that does not contain any Route headers, allowing the request to
be routed through intermediate proxy(ies) to perform termination services.

This algorithm also covers the "pre-loaded" route headers of 16.6,
when the pre-loaded portion is incomplete -- the final route header
in the pre-loaded set would be set to the destination URL (To: header
value).

So by generalizing the procedures to cover the case of the outbound
proxy, we have achieved loose source routing without any syntactic
changes to the headers, and also covered routing of initial requests.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Neil Deason" <[email-masked]>
Date: Wed, 19 Sep 2001 16:58:12 +0100

This is pretty much what I have been saying since
IETF 51.

> Unfortunately the outbound proxy doesn't follow the procedures of

I think the problem is that if the proxy _does_ follow 
16.5 as it is written in bis-04 the path followed is 
mandated.

"When a proxy receives a request, it MUST check for the 
existence of a Route header. If one exists, it MUST pop 
that Route header, and place it (including all URI 
parameters) into the Request-URI."

If we changed the MUSTs to SHOULDs the proxy can ignore
a Route header if that is the right thing. The basic rule
being simply if you do not use the Route do not touch it.

(The text containing confusing references to Route processing 
being like strict IP source routing that appeared in bis-04 
16 and 16.6 should be cut too.)

> 	and Route header unchanged.

I don't think we actually need to specify to this level
just provide enough freedom to operate. For example a
Proxy may get a request that does identify itself in
the Request-URI but not want to be forced to follow
the Route to the next hop. Or in the third step a 
proxy may still want to re-write the Request-URI, 
but not touch the Route, and then send on 'loosely'
towards the destination.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net