(As WG chair) As well as agreeing to charter the item, we actually agreed at IETF#67 that this draft was a suitable candidate to fulfil that charter item.
Therefore unless issues are raised with this, I would request the editor (as Jonathan is editor) to submit the next version of this document as draft-ietf-sip-ua-loose-route-00. Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 13, 2007 4:02 AM > To: IETF SIP List > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility > > 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-loo > se-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 > _______________________________________________ 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
