Hi, Another thing to keep in mind is that when the Path header is used, the generated Route (used from the home proxy towards the UE) will not be identical to the Path.
Route = Path + pushed Route Now, I don't know whether RFC3327 says that the Route MUST be identical to the Path it's based on, or whether it's allowed to add Route(s) in addition to those based on the Path, but there could be intermediates that do some kind of checking. Regards, Christer > -----Original Message----- > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] > Sent: 13. kesäkuuta 2007 6:02 > 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
