Christer, For clarification, does the P-Called-party header field URI get overwritten when retargeting (as opposed to routing) occurs? If not, I fear it suffers from the same problem as the To header field URI, as described in Jonathan's draft.
John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 14 June 2007 12:03 > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing > > > Hi, > > >It is entirely appropriate at this stage to put forward > >alternatives. It is even more appropriate to do it now rather > >than in 6 months time. > > > >However please do not expect the editor to elaborate them. If > >the WG has ideas, send text, either by individual author > >drafts, or by the mailing list. > > Regarding the P-Called-Party header, there already IS an RFC > describing the header, and what it is used for. So, IF it > already solves the problem (RFC3455 does say that the header > is used to convey the AOR to the UAS), why would we need a > separate draft? The only additional information that a draft > could contain are the use-cases where receiving the AOR is > important - but those use-cases are solution independent and > already described in Jonathan's draft. > > Of course, if we want to define a NEW header, or a NEW URI > parameter, that may be done in a separate draft. > > But, no matter how we do it, I think the author should at > least indicate whether he has already thought about the > alternatives that have been presented, and why he thinks that > they don't work. > > Regards, > > Christer > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, June 14, 2007 10:51 AM > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > Subject: RE: [Sip] UA Loose Routing > > > > > > > > > Hi Keith, > > > > > > The text you sent says: > > > > > > "Consensus noted that we do need some sort of solution for > > the general > > > problem of delivery of URI parameters across contact-routing > > > operations." > > > > > > I have no problems with that. > > > > > > I also have no problem with using Jonathan's draft as base line, > > > because the draft discusses the problem in a good way. > > > > > > But, still: as the text says, the agreement was to come up > > with SOME > > > SORT OF SOLUTION, which to me does not mean that we have > agreed to > > > adopt the specific solution in Jonathan's draft. We > should also be > > > "allowed" to discuss alternative solutions, whether they > > are based on > > > P-Called-Party, some other header, some URI parameter, or > > whatever... > > > Maybe those alternative solutions do not work, and then we should > > > describe that (as Jonathan has done for the To header- > and History > > > header alternatives). > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > > > > Sent: 14. kesäkuuta 2007 12:40 > > > > To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; > IETF SIP List > > > > Subject: RE: [Sip] UA Loose Routing > > > > > > > > You appear to be questioning whether the solution was > > adopted. The > > > > minutes state: > > > > > > > > > > ------------------------------------------------------------------- > > > > Topic: GRUU and Supporting Drafts > > > > Led by Jonathan Rosenberg > > > > Slides included in proceedings > > > > Read: > draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 > > > > > > > > Change since last version reviewed. > > > > > > > > Issue: GRUU subtype names. The room demonstrated a slight > > > preference > > > > for the names used in -11 over known alternatives, but > > nobody seems > > > > particularly enamored with these names and the floor > > > remains open to > > > > suggestions. > > > > > > > > Discussion on ua-loose-route draft deferred to next session. > > > > > > > > > > > > Session 2: Friday 0900-1130 Grand Ballroom C > > > > > > > > > > > > Topic: UA-loose-route, continued from previous session. > > > > > > > > Consensus noted that we do need some sort of solution for > > > the general > > > > problem of delivery of URI parameters across contact-routing > > > > operations. > > > > > > > > Issue: Concerns raised about backward compatibility. Noted that > > > > compliant P-CSCF should be OK. Suggested that we have a > > > design team > > > > revisit call-flows and analyze for backward > compatibility issues. > > > > > > > > Issue: Does GRUU normatively depend on this work? Resolved: > > > > GRUU does not reference this document. However, some > > > participants feel > > > > it should, as the benefit of GRUU cannot be fully > > recognized in the > > > > absence of this specification. The chairs asked for a > > hum, and the > > > > consensus of the room is that GRUU and ua-loose-route > can proceed > > > > independently. > > > > > > > > Question: Adopt this draft as baseline text for a WG > > effort, should > > > > the ADs approve the milestone? Consensus to adopt noted > by chairs. > > > > To-do: Chairs to work with AD to set new milestone. > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > The minutes quite clearly say "Adopt this draft as baseline > > > text for a > > > > WG effort" and given that the charter item now exists, then > > > I believe > > > > that we are entitled to call for the editor (Jonathan) to > > > submit the > > > > current text as draft-ietf-sip-ua-loose-route. > > > > > > > > I agree the file name says loose-route, but I don'y think > > we should > > > > change that. After all, we lose that filename when it gets > > > published > > > > as an RFC anyway. > > > > > > > > The charter item states > > > > > > > > Dec 2007 Delivering request-URI and parameters to UAS via > > > > proxy to WGLC > > > > Feb 2008 Delivering request-URI and parameters to UAS via > > > > proxy to IESG (PS) > > > > > > > > I assume that you are OK with this. > > > > > > > > What I would suggest is that you address specific > comments to the > > > > title of the deliverable: > > > > > > > > Applying Loose Routing to Session Initiation Protocol > > > > (SIP) User Agents (UA) > > > > > > > > And to the abstract: > > > > > > > > Abstract > > > > > > > > A key part of the behavior of the Session Initiation > > > Protocol (SIP) > > > > is that SIP proxies rewrite the Request-URI as a > request moves > > > > throughout the network. Over the years, experience has > > > shown this > > > > to > > > > be problematic. It makes it difficult to use > Request URI for > > > > service > > > > invocation, complicates emergency services, makes it > > > more complex > > > > to > > > > support aliases, and so on. Architecturally, it > confounds the > > > > concepts of address and route. This document proposes > > to change > > > > this > > > > through a new mechanism called UA loose routing. > > > > > > > > As you think appropriate to your concerns. > > > > > > > > Alternatively, if you (or indeed any other SIP WG member) > > do have a > > > > completely different solution, then there is still time > > to post an > > > > individual draft or post a skeleton of a mechanism to the list. > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF) > > > > > [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, June 13, 2007 8:52 PM > > > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > > > Subject: RE: [Sip] UA Loose Routing > > > > > > > > > > > > > > > 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 > _______________________________________________ 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
