Hi, >>>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. > >Its not a question of documentation. Its that we would in >fact have multiple headers which mean the same thing. So, for my clarification, which headers would mean the same thing using P-Called-Party-ID? >>>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. > >Sure, but its useless unless the UA supports it. So my point >is, in all cases, we are talking about changes to UA and to >proxy to do something useful here. The UA-loose-route >mechanism doesn't require any changes beyond those two. The P-Called-Party-ID solution doesn't require any changes to proxies at all. And, even if a proxy wouldn't have a problem with the loose routing solution as such, in some environments the proxies processes the P-Called-Party-ID header. So, you would still need to update those proxies, if you want to replace the P- header mechanism with something else. >>>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. > >We have lots of P-headers that already exist. That doesn't mean we shouldn't bother to provide an architecturally better >solution. I don't think a solution based on a P- header automatically is a "bad" solution. In this case the main purpose is to provide a URI, and a header (whether it's a P- header or not is not relevant) is perfectly ok for that I think. And, in general I think we give the market the wrong picture if we make changes that may affect existing deployments and systems (the P-Called-Party header has been part of IMS for a realtively long time) - especailly when nothing is broken with the current systems. Yes, maybe there are things we think could have been done cleaner, but in some cases we just have to accept the fact that things have been defined in a specific way. Regards, Christer _______________________________________________ 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
