We've had a few threads over the last few months on the above topic. To
refresh everyone's memory, the problem is how to deliver the original
request-URI for a target to the UAS. Currently, a proxy will replace the
R-URI with the registered contact, thus losing the original URI and any
parameters. A bunch of use cases where this is needed have been identified:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-02.txt
The debate has been around whether to use the mechanism proposed in my
draft above, which makes an architectural change to SIP to use loose
routing to solve this. Alternative solutions are to use History-Info and
to use a mechanism proposed by Christer:
http://www.watersprings.org/pub/id/draft-holmberg-sip-target-uri-delivery-01.txt
The threads seemed to general favor not doing my proposed UA loose
route, and the issue was whether H-I is up to the job or whether to use
the new thing proposed by Christer. The conclusion was that some kind of
H-I extension was probably needed, but the debate was whether it was too
complex and a more basic solution, like Christer has proposed, is better.
So, here is my compromise proposal on this:
1. we do NOT to UA loose route. Though I still think this is
architecturally the best thing, I am convinced that its just too late
for a change like this. Wish we had done this in 3261, but oh well.
2. We use H-I. However, remember that H-I can be used for many
applications and those applications can define policies and usage rules
to fit their needs. So, we can define a really, really simple usage such
that, if all your proxy cares about is this problem, its basically no
harder to implement than what Christer has proposed.
In particular, here would be the suggested algorithm:
For a proxy:
If the proxy is rewriting the r-uri as a consequence of looking it up
in a registration database, it looks at the incoming request. It removes
any existing H-I values. It then adds two H-I values that look like this:
History-Info: <sip:incoming-ruri>;target;index=1
<sip:outgoing-ruri>;target;index=1.1
and thats it. So really easy for a proxy.
For a UAS:
The UAS looks through the H-I header field values in reverse order.
There is no need to reorder them by index. It finds the first value with
a target parameter. The corresponding URI will be the most recent target.
This algorithm in the UAS is compatible with a full HI implementation in
a proxy as well; so this way, a proxy that just cares about target-uri
delivery can do the simple thing above. One that wants everything
ignores the policy above and implements the full spec. UA works in
either case.
Of course this also requires us to extend HI with this new target URI
param. It indicates that the URI is a request target. The above
algorithm tries to provide an implementable way to at least positively
assert that: that this URI is look-up-able in a registration database.
It therefore is most likely a target for the request.
Thoughts?
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www.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
