Hi, >My concern with P-Called-Party-ID is similar to my concern on >History-Info. On History-Info, the draft states: > > Firstly, it would cause the Request-URI to be relegated to nothing > more than an indicator of the next hop for the request, identical > exactly to the purpose of the Route header field. This results in > two things in the SIP specification which do exactly the same thing. > Worse still, this is not just for some small feature of SIP (where > such duplication might not be a big deal), but rather, it would be a > duplication of SIP's primary function - routing of a call towards a > target. > > This concern applies exactly to P-Called-Party-ID. Indeed, > its even worse, since now we would have, in a request: > > Request-URI > To > P-Called-Party-ID > History-Info > Route > >and I challenge you to explain to implementors what the >differences are. >What would happen when they are inconsistent? > >My objective was to reduce this count. Indeed I was hopeful >that UA-loose-route would allow us to deprecate >P-Called-Party-ID, not the other way around. WIth >UA-loose-route, we end up with: > >Request-URI: identifies the target >Route: tells you how to get to the target >To: tells you the original target >History info: sequence of identities of targets
If people can't explain to their implementors the meaning of different SIP headers maybe THAT is something we should concentrate on, and if needed write a draft about. >which is much cleaner. If we would re-do SIP I am sure lots of things could be done cleaner. P-Called-Party-ID does not change the current routing mechanism, and it does not have the potential issue with proxies (and possible also SBCs) that you have mentioned. And the proxy re-writing the R-URI can use the mechanism no matter if the UA supports it or not. (And, naturally the mechanism would of course be backward compatible with entities and networks that already support P-Called-Party-ID.) >So, functionally, P-Called-Party-ID could work. Any number of things *can* >work. Yes, but P-Called-Party-ID is a standardized mechanism, made for this purpose, which most likely does work. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > 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 > > > > -- > 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
