Subject: [Sipping] Loose Routing Proposal

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 6 Sep 2001 19:32:00 -0700

At the last IETF there was some discussion of Dave's idea of allowing both
strict and loose routes to be intermixed in a single route header. I think
this would address the "How to Get Outbound Services from A Non-Local Proxy"
discussion and end up being more flexible and general than the path header.

The basic ideas would be to add a route-type tag that can be set to loose or
strict on with each name-addr in the route header. This would be taken as a
hint by the proxy on how it could route the message. Strict routing would
happen like normal, loose routing would have the proxy attempt to loosely
route to the to the specified location in the same way it would attempt to
route a message with this URI to this location. A key item on loose routing
is that the sending proxy can not pop a loose route, the receiving proxy
must do this when the message finally reaches the correct proxy.

To make this a little more concrete, Imagine the case where a UA knows it
must first go to an edge proxy called edge.visitor.com then it is going to
get outbound services from a proxy called vamp1.visitor.com then another
called vamp2.home.com. It has no idea of the proxies in between edge, vamp1,
and vamp2. Just to pretend, lets say that vamp1 knows that to get to
vamp2.home.com it must send a message to the proxy nat.home.com. The initial
UA could specify a route header like

Route: edge.visitor.com vamp1.visitor.com;route-type=loose
vamp2.home.com;route-type=loose

Edge would receive this, do the normal thing and send a message to vamp1
with the Route changed to

Route: vamp1.visitor.com;route-type=loose vamp2.home.com;route-type=loose

vamp1 would notice it was the first thing on the route header and pop this.
It would than look at the next thing on the route list and see that it was a
loose route to vamp2. vamp1 knows it needs to send to nat.home.com and would
send a message to nat with the header of

Route: vamp2.home.com;route-type=loose

nat would notice this is a loose route and that it was not vamp2. It would
send this message to vamp2 with a header of

Route: vamp2.home.com;route-type=loose

vamp2 would pop this item and the route header would be empty and normal
processing would continue.

Specifically I am proposing the following changes to the ABNF

rr-tag = ( rr-type-tag | generic-tag ) rr-type-tag = "route-type" "=" (
"loose" | "strict" | token )

And adding some test to the behavior of proxies along the lines of

The route-type is a hint that the proxy may honor. If a proxy receives a
message and finds itself as the top most item on the route header, it must
pop this item. If the top item in the route header specifies a route-type of
loose, the proxy should look at the URI in the top name-addr on the route
header and route the message in the same way it would route a message that
had this URI and no route header. Furthermore, it should not pop the top
most item off of the route list. If no route-type is specified, the default
is strict.

I did try and think about this idea from the point of view of backwards
compatibility and I don’t think there is any situation where it will make
the situation worse. If a proxy that does not do loose routing attempts to
route a hop that is supposed to be loose, it will try a strict route. If
this works great, things carry on. If it does not work, the call will fail.
The mechanism does not require that every proxy must support loose routing,
only those that are going to be asked to do a loose route or receive a loose
routed item need to do it.

Thoughts? Thanks, Cullen

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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 7 Sep 2001 00:36:16 -0500

Oh, and just for reference, discussing a specific proposed extension should
probably be a SIP task -- discussing the requirements for it, or how to use
it, would be a SIPPING task.

Thanks.

--
Dean

----- Original Message -----
From: "Cullen Jennings" <[email-masked]>
To: <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>
Sent: Thursday, September 06, 2001 9:32 PM
Subject: [Sipping] Loose Routing Proposal

> compatibility and I don't think there is any situation where it will make

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 7 Sep 2001 00:34:54 -0500

I believe Jonathan R looked at the Route: header and determined that there
does not appear to be a reasonable way to do this and preserve backward
compatibility -- rather than ignoring the "loose" flag, older proxies would
probably choke the route.

This leaves us with a seperate Loose-Route header and the "exhaust Route
before using Loose-Route" model.

Jonathan?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 7 Sep 2001 08:55:57 +0300

> probably choke the route.

i would not consider backward compatibility problem an issue here.
considering how buggy the current products have been in my testing what
comes to processing record-route/route in general and then adding to
that all other bugs the proxies and UAs have, backwards compatibilitry
is not an issue at all, since everyone needs to keep on upgrading their
proxies and UAs constantly anyway.

as a concrete example, yesterday when i tried to make a call to
sip:[email-masked], i got back a 200 OK where the order of
the route headers had been reversed.  this week alone, the number of
bugs that i have found in various sip products has been five!

 > before using Loose-Route" model.

this would be a very bad thing: yet another header in an already too
complex protocol.  there should be some common sense here.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 7 Sep 2001 01:07:12 -0500

Perhaps a point, but I don't want to break the cool 3Com phone I use at
home, and I don't think there's going to be any new software for it . . .
;-)

Actually, that is a good "requirements" question -- what is the requirement
for backward compatibility here?

Would it be worth defining a WHOLE NEW Route mechanism that allows mixing
strict and loose routes and deprecating the existing route mechanism? I
didn't really like Route anyhow . . .

The existing Route mechanism could be kept in place as a "MUST implement"
but "SHOULD NOT initiate use of" . . .

So:
1) How strong is the requirement for mixed routing?
2) How strong is the requirement for backward compatibility?
3) Is there a requirement that the mixed routing capability "interleave"
with the old strict-only routing?

If #1 is a requirement and #3 is a requirement, then I think #2 can be only
partially achieved, the sort of "backward compatibility" that says "this new
feature won't break old systems, but this new feature may be BROKEN by old
systems"  can probably be achieved.

--
Dean

---

From: Henrik Gustafsson <[email-masked]>
Date: Fri, 07 Sep 2001 10:14:48 +0200

At the ad-hoc meeting we were mentioning that we had implemented a loose 
route mechanism and played around with the idea and got some experience. 
Now we finally have put that together as a draft and posted it.

We are using a new header, at this point called service-route, and 
proxy-require to guarantee backward compatibility. The main difference 
from the strict route is that the request uri is not changed by the 
loose route mechanism, but may be changed by the service. The 
service-route header is popped at the receiving end.

The draft is also available at 
http://www.hotsip.com/ietfcontrib/draft-bjorkner-sip-serviceroute-00.txt

/Henrik Gustafsson

Dean Willis wrote:

>> > I believe Jonathan R looked at the Route: header and determined that
>>
>there
>
>> > compatibility -- rather than ignoring the "loose" flag, older proxies
>>
>would
>
>> > This leaves us with a seperate Loose-Route header and the "exhaust
>>
>Route
>

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 7 Sep 2001 09:33:57 +0100

[Moved to SIP.  Hopefully this is the right thing todo.]

> there does not appear to be a reasonable way to do this and preserve
> backward compatibility -- rather than ignoring the "loose" flag,
> older proxies would probably choke the route.

I have to say that I'm still confused as to why we can't
just say that Route is loose.  Neil has pointed out that
the notion of DNS-incapable clients has already created
a sortof precedent for this.  The only problem I've heard
so far is that you lose the identity of the called party
(because the Request-URI gets clobbered by some Route pop
along the path); however, I fail to see why the proposal
of adding the called party as the last Route entry will
not work...?

 - Jo.