I've recently revised my draft on UA loose routing. You can pick it up here:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-01.txt
This draft is meant to fulfill one of our charter items:
Feb 2008 Delivering request-URI and parameters to UAS via proxy to
IESG (PS)
As folks may recall, the GRUU spec used to have these things called
grids, which allowed a UA to add its own parameters to the GRUU before
handing it out. Several GRUU revisions back, this function got yanked
because it was recognized that the problem was more general than GRUU,
and would be useful for AOR as well.
Two IETFs back I presented this draft briefly during a SIP session.
There was a lot of interest and people liked it architecturally, however
there were two open issues that needed to get resolved. This mail is
meant to start discussion on one of them - backwards compatibility.
THe mechanism basically changes the way proxies handle requests. Instead
of rewriting the request URI for out-of-dialog requests, they'll push a
route header and leave the r-uri alone. This allows the original R-URI
and any parameters it contains to get delivered to the UAS.
So, the main issue is, what kinds of backwards compatibility problems
will this cause. The draft provides a basic mechanism whereby a UA
includes an option tag in the REGISTER, and the registrar indicates that
it is using this mechanism or not. So we can negotiate this between a UA
and registrar easily. Now, the problem is with intermediate proxies. If
there is an edge proxy between the UA and its registrar, it will now see
requests targeted to the UA, which contain a Route header beyond itself,
even though it thinks its the edge proxy and the last point of contact
before the UA. Technically, if this edge proxy is compliant to rfc3261
it would work. However, the question is whether proxies in the wild
would properly work in this case.
If folks can comment based on their own products, or their experiences,
on whether they think this would work, or concerns they have, that would
be great. THere are solutions that would allow us to disable the
mechanism when intermediate proxies don't support it, but they are more
complex and I'd rather avoid it.
THanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
