inline.
Christer Holmberg (JO/LMF) wrote:
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.
Its not a question of documentation. Its that we would in fact have
multiple headers which mean the same thing.
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.
I do agree, that UA-loose-route requires a discovery mechanism, so the
proxy knows whether to do this or not. But that is not difficult.
(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.
We have lots of P-headers that already exist. That doesn't mean we
shouldn't bother to provide an architecturally better solution.
-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
