Hi John, >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.
I believe it does work with retargeting. In fact, chapter 4.2 of RFC3455 pretty much describes the same retargeting problem when using the To header as Jonathan does in his draft. Regards, Christer > > -----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
