Dale,
What problem are you trying to solve that Jonathan's proposal didn't solve?
As proposed by him, the proxy wouldn't use loose routing in this case
unless it knew that the UA supported it. (It learns based on the ;lr in
the contact supplied with REGISTER.)
The functional difference between that and P-Called-Party is that when
the proxy uses P-Called-Party it supplies the information even to UAs
that don't support it. While that doesn't cause any harm, it also
doesn't provide any benefit.
Paul
[EMAIL PROTECTED] wrote:
This is delayed, but I haven't heard of this point being addressed:
From: Jonathan Rosenberg <[EMAIL PROTECTED]>
> On a more practical level, it only deals with one level of address
> mapping, and it's not usable by a UA that doesn't implement the change
> -- whereas I would expect that the optimal mechanism is one that
> tweaks the behavior of the proxy doing the mapping, and requires no
> change from any other system.
If the purpose of this is to communicate the targeted URI from the
terminating proxy to the UA, I don't see how any mechanism can work
unless it is supported by that proxy and that UA. Any of the mechanisms
mentioned or discussed (P-Called-Party-ID, To, History-Info) have this
property.
The property I'm looking for is "If the proxy applies the mechanism,
but the UA doesn't understand it, the UA automatically processes the
request as if the mechanism was not employed." If we carry the
"retargeted AOR" in a URI parameter or header and modify the
request-URI as now, we obtain this property. If we don't modify the
request-URI, the proxy has to have accurate knowledge of which targets
support UA Loose Routing and which don't.
Dale
_______________________________________________
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
