Hi, We can call it loose route if we want, but I think the initial focus should be the problem we are going to solve (I don't think we agreed on a specific solution at #67), and we should look into alternative solutions (the draft does that in some extent, but other possible alternatives have also been mentioned).
Or, do you prefer to have separate drafts describing alternative solutions for the problem? Regards, Christer > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > Sent: 13. kesäkuuta 2007 22:25 > To: Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing > > (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 > _______________________________________________ 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
