Subject: [Sip] loose routing/service-route/DOP fix combination

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Dec 2001 18:57:01 -0500

There are several outstanding open issues related
to the route/record-route mechanism. Most of them
are affected by the loose-routing concept, so I'ld
like to start there.
 
With the help of many, I've consolodated the various
proposals into one that I believe brings us 
loose-routing, satisfys the needs expressed in the 
service-route draft, and cleans up the problems we've 
been seeing with the default outbound proxy concept.

The scope of change in this proposal from whats
currently in the specification is limited to
processing requests that contain Route headers.
Furthermore, it is backwards-compatible.
 
Here is the idea:
 
  When an element is processing a message containing
  a Route header field, it MAY observe local policy in
  determining rewriting the Request-URI, where to send
  the request and whether to remove the topmost Route
  header field value. 
 
That local policy may be to behave just as currently
specified - moving the topmost Route header field
value to the request URI and removing it from the
Route header field. Alteratively, the policy 
could be to rewrite the Request-URI (possibly
retargeting the request, possibly just modifing the
maddr parameter, even possibly making no change)
and leave the Route header field alone. Call any
element that has a policy different from the
Route processing rules to date a "loose-routing"
element.
 
Consider these examples:
 
A default outbound proxy (DOP) that is not on the
route set could simply rewrite the maddr parameter
on the request-URI, add its Via and forward the
request.

A service element on the path of an initial request
in a dialog with a preloaded Route could choose to
retarget the request (fully rewriting the request URI)
or simply rewrite the maddr parameter and leave the
Route header field alone - moving the request towards
the resource identified in the topmost Route header
field value. If can also choose whether it wishes to
Record-Route or not.
 
A UAC that can't make its own routing decisions and
is configured to use a default outbound proxy has
local policy to build the request normally, but
not remove the topmost Route header. Thus, we
_already have_ an element that operating under
this proposal.

There are only two restrictions on what the local
policy can be. The first makes sure we still
have the Route behaviour we've come to expect:
 
  If the resource in the topmost Route header field value
  belongs to this element the local policy MUST include
  removing the topmost header field value.  
 
"Belongs" here means it is the element that the Route
targeted. In operations to date, that URI would have
been moved from the Route header field to the 
Request-URI by the previous hop, and depending on
the previous hop policy, that may still be the case.
If, however the previous hop is a loose-routing
element that didn't remove the topmost Route header
field value, it must get removed here so that the
request will move on towards the _next_ thing in
the Route set.
 
Suprisingly, existing elements satisfy this
requirement - as strange as it looks, it is
backwards compatible as long as the "loose-routing"
elements are careful to construct their Request-URIs
so that they don't induce loops in unsuspecting
current implementations. This care is captured
in the second restriction on local policy:
 
  The Request-URI created by a loose-routing element
  MUST differ from the URI in the topmost Route
  header.
 
One simple way to achieve this is through ensuring
the maddr parameter is different (added or removed
if necessary). Whether or not we accept this
loose-routing proposal, this restriction needs to 
be kept for UACs configured to use DOPs to avoid
inducing a loop at the DOP.
 
RjS

_______________________________________________
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