Subject: [Sip] Proposed solution for UA loose/target/History-Info problem

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Jul 2008 19:34:51 -0400

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-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 28 Jul 2008 06:28:11 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Rosenberg
>
> For a proxy:

I'm confused.  Why is it removing any existing HI values?  Doesn't that break its compatibility with legacy HI usage?

-hadriel

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 28 Jul 2008 07:36:50 -0500

I don't think it needs to remove them, although the policy of some
proxies might do that. The algorithm for backing up through the
History-Info is not that complex. I think it would be useful to show an
example that has the required entries to support "target", but also
contains "complete" (as possible) HI. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, July 28, 2008 5:28 AM
To: Jonathan Rosenberg; IETF SIP List
Subject: Re: [Sip] Proposed solution for UA loose/target/History-Info
problem

>    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
> and thats it. So really easy for a proxy.

I'm confused.  Why is it removing any existing HI values?  Doesn't that
break its compatibility with legacy HI usage?

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 28 Jul 2008 07:46:40 -0500

Yeah, that was exactly my concern. 

It should ADD the entries to the existing History-Info if
present. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: Monday, July 28, 2008 03:28
> Subject: Re: [Sip] Proposed solution for UA 
> loose/target/History-Info problem
> 
> 
> 
> > removes any existing H-I values. It then adds two H-I 
> values that look like this:
> >
> I'm confused.  Why is it removing any existing HI values?  
> Doesn't that break its compatibility with legacy HI usage?
> 
> -hadriel
> [email-masked] for questions on current sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Jul 2008 13:21:03 -0400

Agree here.

I was just trying to say, "hey, if you don't care or don't want anything 
but this basic usage of HI, this is what you'd do". A spec would say 
something like MAY remove or MAY append. Main thing is, if you append, 
you do need to check to make sure the incoming RURI is not already 
there, and if it is, add the target attribute. So its simpler if you 
just remove everything and re-add, but destroys other usages of HI.

-Jonathan R.

Francois Audet wrote:
>> Behalf Of

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 29 Jul 2008 03:49:49 -0500

Ok. I think it should be a SHOULD append. 

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, July 28, 2008 10:21
> To: Audet, Francois (SC100:3055)
> Cc: Hadriel Kaplan; IETF SIP List
> I was just trying to say, "hey, if you don't care or don't 
> want anything but this basic usage of HI, this is what you'd 
> do". A spec would say something like MAY remove or MAY 
> append. Main thing is, if you append, you do need to check to 
> make sure the incoming RURI is not already there, and if it 
> is, add the target attribute. So its simpler if you just 
> remove everything and re-add, but destroys other usages of HI.
> 
> -Jonathan R.
> 
> Francois Audet wrote:
> > It should ADD the entries to the existing History-Info if present.
> >