Subject: [Sip] RE: Delivering request-URI and parameters to UAS via proxy

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 9 Jan 2008 17:31:39 +0100

A reminder of the deadline on the 11th January for submitting
alternative proposals on the way forward.

Regards

Keith 

> -----Original Message-----
> From: DRAGE, Keith (Keith) 
> Sent: Tuesday, December 04, 2007 3:27 PM
> To: [email-masked]
> Subject: Delivering request-URI and parameters to UAS via proxy
> 
> (As WG chair)
> 
> We have a couple of milestones that we generated as a result 
> of discussion of 
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo
> se-route-01.txt
> 
> Dec 2007    Delivering request-URI and parameters to UAS via 
> proxy to WGLC  
> Feb 2008    Delivering request-URI and parameters to UAS via 
> proxy to IESG (PS)  
> 
> This work is currently stalled and the editor needs input.
> 
> The document contains various example scenarios where a 
> solution is required, for which there appears to be no 
> dispute that a solution is needed.
> 
> The document proposes one solution to resolve these example 
> scenarios, but this solution is not gaining consensus. At 
> least one other solution has been talked about, but there is 
> no documentation on the table.
> 
> This mail is to identify a deadline for other solutions to 
> the example scenarios to be documented as internet drafts, 
> showing how the solution works for those scenarios. This deadline is:
> 
> 	January 11th 2008
> 
> It is appropriate fo these documents to identify any other 
> scenarios where such a solution is appropriate. Any other 
> input is also welcome in identifying other scenarios.
> 
> If we have no such internet-drafts by this deadline, we will 
> proceed with completing the solution we have.
> 
> 
> Regards
> 
> Keith
> 
> 

_______________________________________________
Sip mailing list  https://www1.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: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Jan 2008 14:54:17 +0100

Hi,

We have submitted a draft with an alternative proposal.

It can also be found at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-del
ivery-00.txt

Regards,

Christer

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 9. tammikuuta 2008 18:32
> To: [email-masked]
> Subject: [Sip] RE: Delivering request-URI and parameters to 
> UAS via proxy
> 
> > We have a couple of milestones that we generated as a result of 
> > discussion of
> > 
> > The document contains various example scenarios where a solution is 
> > required, for which there appears to be no dispute that a 
> solution is 
> > needed.
> > 
> scenarios, 
> > but this solution is not gaining consensus. At least one other 
> > solution has been talked about, but there is no 
> documentation on the 
> > table.
> > 
> the example 
> > scenarios to be documented as internet drafts, showing how the 
> > solution works for those scenarios. This deadline is:
> > 
> > 	January 11th 2008
> > 
> scenarios 
> > where such a solution is appropriate. Any other input is 
> also welcome 
> > in identifying other scenarios.
> > 
> > If we have no such internet-drafts by this deadline, we 
> will proceed 
> > with completing the solution we have.
> > 
> > 
> > Regards
> > 
> > Keith
> > 
> > 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2008 10:28:30 -0500

Christer,

I have some questions and comments:

- I don't understand your examples in section 3. They are a bit sketchy 
about the assumptions they are making, and in notation. I get lost about 
which referenced component has which address, etc. I am far from 
convinced that these are problems with appropriate use of the mechanism.

- It seems from your analysis of use cases that it is P-Called-Party 
that solves many of them, not Target. So both headers seem to be part of 
the solution. Its not entirely clear to me at the moment whether the 
R-URI in the loose-route approach aligns with Target or P-Called-Party. 
Since they are different, it can't align with both. So there must be 
some features it doesn't cover. I haven't fully grokked that yet.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Jan 2008 17:01:21 +0000

Christer,

In addition to Paul's concerns, I am having difficulty understanding why
the To header field is insufficient for the cases where the Target
header field is proposed. The initial source of this confusion was the
statement "the Target header field represents
   the initial target identity that was used to initiate a session to
   the target"

So we now have 4 fields (ignoring Route):
- To
- Target
- P-Called-ID
- Request-URI
I think it would benefit from a clearer exposition of the semantics and
relationship between these.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 11 January 2008 15:29
> To: Christer Holmberg
> Cc: [email-masked]; DRAGE, Keith (Keith)
> Subject: Re: [Sip] RE: Delivering request-URI and parameters 
> to UAS via proxy
> 
> Christer,
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 Jan 2008 12:58:04 -0600

I'm also totally confused now about what is being proposed.

The Target seems identical to the To header field.

I tought that what you (Christer) was arguing for is using the P-Called-Header
instead of the new loose route proposal, i.e., not for the "initial target", but for
the "current target".

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, January 11, 2008 09:01
> To: Paul Kyzivat; Christer Holmberg
> Subject: RE: [Sip] RE: Delivering request-URI and parameters 
> to UAS via proxy
> 
> Christer,
> 
> In addition to Paul's concerns, I am having difficulty 
> understanding why the To header field is insufficient for the 
> cases where the Target header field is proposed. The initial 
> source of this confusion was the statement "the Target header 
> field represents
> I think it would benefit from a clearer exposition of the 
> semantics and relationship between these.
> 
> John
> 
>  
> 
> > Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS 
> > via proxy
> > 
> > Christer,
> > 
> > - I don't understand your examples in section 3. They are a bit 
> > sketchy about the assumptions they are making, and in 
> notation. I get 
> > lost about which referenced component has which address, 
> etc. I am far 
> > from convinced that these are problems with appropriate use of the 
> > mechanism.
> > 
> > that solves many of them, not Target. So both headers seem 
> to be part 
> > of the solution. Its not entirely clear to me at the moment whether 
> > the R-URI in the loose-route approach aligns with Target or 
> > P-Called-Party.
> > >> Subject: [Sip] RE: Delivering request-URI and parameters 
> to UAS via 
> > >> proxy
> > >>
> > >> [email-masked] for questions on 
> current sip Use 
> > >> [email-masked] for new developments on the application of sip
> > >>
> > > 
> > > 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments on the application of sip
> > > 
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Jan 2008 20:20:22 +0100

Hi Paul, 

>- I don't understand your examples in section 3. They are a 
>bit sketchy about the assumptions they are making, and in 
>notation. I get lost about which referenced component has 
>which address, etc. I am far from convinced that these are 
>problems with appropriate use of the mechanism.

As indicated in chapter 3, one of the main issues/limitations with the
J'draft solution is that the entity wanting to use it must have
knowledge whether the next hop also supports it. My understanding from
off-line discussions I had with Jonathan in Vancouver is also that
Jonathan agrees to that issue/limitation.

The purpose of the examples is just to show what can go wrong if the
next hop does not understand the mechanism. But, if we all agree to the
limitation with the J'draft solution I don't know whether we need to
spend too much time on the examples.

>- It seems from your analysis of use cases that it is 
>P-Called-Party that solves many of them, not Target. So both 
>headers seem to be part of the solution.

No, as far as the alternative to the J'draft solution is concerned, the
alternative is Target. We believe it can be used for all listed
use-cases.

Since I myself have been talking about P-CPI as an alternative, we
wanted to show in which cases it could be used as an alternative, and
why we think that P-CPI still would have to be used in IMS. 

But, we have realized that P-CPI as defined and used today probably
would not solve all the use-cases, and that is the reason we came up
with the Target header.

>Its not entirely clear to me at the moment whether the R-URI in the 
>loose-route approach aligns with Target or P-Called-Party. 
>Since they are different, it can't align with both. So there 
>must be some features it doesn't cover. I haven't fully 
>grokked that yet.

I appologize if the P-CPI text causes confusion. Again, the alternative
to the J'draft solution we propose is Target.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Jan 2008 20:33:11 +0100

Hi,

I answer both John's and Francois' questions in this reply.

>The Target seems identical to the To header field.

I don't think they are identical. Jonathan's draft describes the issues
with using the To header.

>I tought that what you (Christer) was arguing for is using 
>the P-Called-Header instead of the new loose route proposal, 
>i.e., not for the "initial target", but for the "current target".

Yes, I have.

But, as the P-PCI header is currently defined and used (e.g. in 3GPP) we
are not sure it could be used for all use-cases.

Also, if you read the abstract it does say "current target". I guess the
same wording should be used elsewhere too.

>>In addition to Paul's concerns, I am having difficulty understanding 
>>why the To header field is insufficient for the cases where the Target

>>statement "the Target header field represents the initial target
identity that was used to initiate a 
>>session to the target"
>>I think it would benefit from a clearer exposition of the semantics 
>>and relationship between these.

That main purpose of the document was to define an alternative to the
solution in Jonathan's draft, and due to time issues that is what we
focused on.

But, I do agree that there are lots of things that could be clarified
and explained - no matter what solution we move forward with.

Regards,

Christer

> > P-Called-Party

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2008 14:37:15 -0500

> spend too much time on the examples.

The limitation is the limitation. It means that you don't use the 
mechanism if you don't know the next hop supports it. So its useless to 
speculate what would go wrong if you use the mechanism with a next hop 
that doesn't support it.

> alternative is Target. We believe it can be used for all listed

I don't understand. Several of them called for using P-CPI.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 Jan 2008 13:45:54 -0600

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Friday, January 11, 2008 11:33
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]; Elwell, John; Paul Kyzivat; DRAGE,Keith (Keith)
> I don't think they are identical. Jonathan's draft describes 
> the issues with using the To header.

Well, your description of "Target" in your draft is indentical to
the description of the "To" header.

What Jonathan describes as limitations of "To" is that it doesn't
reflect any "retargeting".

I think what you meant by Target was more the "Current" target as opposed
to the Initiatl Target.

And if that's the case, then I don't see why it is different from P-Called-ID
(although I might be missing something with what the P-Called_ID is supposed
to be).

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Jan 2008 21:02:14 +0100

Hi, 

>>>sketchy about the assumptions they are making, and in notation. I get

>>>lost about which referenced component has which address, etc. I am 
>>>far from convinced that these are problems with appropriate use of 
>>>the mechanism.
>> 

>>next hop does not understand the mechanism. But, if we all agree to 
>>the limitation with the J'draft solution I don't know whether we need 
>>to spend too much time on the examples.
> 
>The limitation is the limitation. It means that you don't use 
>the mechanism if you don't know the next hop supports it. So 
>its useless to speculate what would go wrong if you use the 
>mechanism with a next hop that doesn't support it.

We thought it would be good to show some examples, in case people don't
understand WHY the limitation is there.

>>>that solves many of them, not Target. So both headers seem to be part

>>>of the solution.
>> 
>>No, as far as the alternative to the J'draft solution is concerned, 
>>the alternative is Target. We believe it can be used for all listed 
>>use-cases.
> 

No, we say that there are certain use-case we belive the P-CPI was
defined to be used for, but we also say that the Target header can be
used for those use-cases.

Again, the Target header is our proposal for an alternative to the
J'draft solution.

Regards,

Christer

> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-
> >> d
> >>> el
> >>> ivery-00.txt
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>  
> >>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Jan 2008 21:07:17 +0100

Hi, 

>>I don't think they are identical. Jonathan's draft describes the 
>>issues with using the To header.
> 
>Well, your description of "Target" in your draft is 
>indentical to the description of the "To" header.
> 
>What Jonathan describes as limitations of "To" is that it 
>doesn't reflect any "retargeting".
> 
>I think what you meant by Target was more the "Current" 
>target as opposed to the Initiatl Target.

Yes, and I think I did say that futher down in my previous reply :)

>And if that's the case, then I don't see why it is different 
>from P-Called-ID (although I might be missing something with 
>what the P-Called_ID is supposed to be).

I will get back to you on this one. I am writing this e-mail from my
home machine, so I don't have all the documents etc.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 14 Jan 2008 12:56:15 +0100

Hi Francois, 

>target as opposed to the Initiatl Target.

Yes.
 
>what the P-Called_ID is supposed to be).

In the draft we try to explain the difference. But, we are working on
the text to make it more clear.

The P-CPI is inserted when the R-URI is rewritten by the Contact address
of the UAS. RFC3455 calls that operation "retargeting", but we don't
think that is the definition for retarget used in the ua-loose-route
draft, which says:

"When a home proxy receives a request and accesses a location
service, the resulting contact(s) obtained from the location
service are considered the last hop in the route towards the
entity addressed by the Request-URI.  Since that target, almost
by definition, can claim the identity of the URI prior to
translation, the operation is one of routing and not retargeting."

So, if we follow the definitions in the ua-loose-route draft, P-CPI
would be inserted due to a reroute - not retarget.

But, no matter whether we call it retarget or reroute, the point is that
the P-CPI is inserted when the R-URI is rewritten with the Contact
address of the UAS. The scope of Target is wider than that, and can be
used in any retargeting situation.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 Jan 2008 19:08:19 -0600

Hum. I guess then P-Called-ID would then be useful with Loose-route
as well (although now I'm thinking that History-Info covers it).

I think explaining all that in great and precise details, with a concrete 
example would be very useful.

And then we could compare P-Target with Loose-route. 

> Sent: Monday, January 14, 2008 03:56
> Cc: [email-masked]; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John
> >And if that's the case, then I don't see why it is different from 
> >P-Called-ID (although I might be missing something with what the 
> >P-Called_ID is supposed to be).
> 
> In the draft we try to explain the difference. But, we are 
> working on the text to make it more clear.
> 
> The P-CPI is inserted when the R-URI is rewritten by the 
> Contact address of the UAS. RFC3455 calls that operation 
> "retargeting", but we don't think that is the definition for 
> retarget used in the ua-loose-route draft, which says:
> 
> entity addressed by the Request-URI.  Since that target, 
> almost by definition, can claim the identity of the URI prior 
> to translation, the operation is one of routing and not retargeting."
> 
> So, if we follow the definitions in the ua-loose-route draft, 
> P-CPI would be inserted due to a reroute - not retarget.
> 
> But, no matter whether we call it retarget or reroute, the 
> point is that the P-CPI is inserted when the R-URI is 
> rewritten with the Contact address of the UAS. The scope of 
> Target is wider than that, and can be used in any retargeting 
> situation.
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 15 Jan 2008 09:48:10 +0100

Hi, 

P-CPI could probably be useful in some cases, in addition to Loose
Route/Target. And, as the draft says, P-CPI will still have to be used
in IMS, because there are procedures defined for it.

However, again, the purpose of the draft was to provide an alternative
to the Loose Route alternative, and that alternative is Target only. 

I am working on an updated version of the draft to make that more clear.

Regards,

Christer

>Hum. I guess then P-Called-ID would then be useful with 
>Loose-route as well (although now I'm thinking that 
>History-Info covers it).
> 
>I think explaining all that in great and precise details, 
>with a concrete example would be very useful.
> 

> > Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS 
> > via proxy
> > 
> > 
> > Hi Francois,
> > 
> > The P-CPI is inserted when the R-URI is rewritten by the Contact 
> > address of the UAS. RFC3455 calls that operation 
> "retargeting", but we 
> > don't think that is the definition for retarget used in the 
> > ua-loose-route draft, which says:
> > 
> > "When a home proxy receives a request and accesses a 
> location service, 
> > the resulting contact(s) obtained from the location service are 
> > considered the last hop in the route towards the entity 
> addressed by 
> > the Request-URI.  Since that target, almost by definition, 
> can claim 
> > the identity of the URI prior to translation, the operation 
> is one of 
> > routing and not retargeting."
> > 
> > But, no matter whether we call it retarget or reroute, the point is 
> > that the P-CPI is inserted when the R-URI is rewritten with the 
> > Contact address of the UAS. The scope of Target is wider than that, 
> > and can be used in any retargeting situation.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Jan 2008 09:20:01 +0000

Christer,

I guess what still confuses me is, when both Target and P-CPI are used,
which comes first, i.e., which represents the earlier target? When I
read the draft, I thought Target was earlier. From various clarifying
emails I now get the impression that Target is later. Can you confirm?

Picking up on Francois' point about History-Info, with the introduction
of Target and P-CPI we do indeed have a lot of URIs, and of course
History-Info can already convey all these URIs and any others. The
difference is that History-Info does not give particular semantics to
each of the URIs it conveys - they are simply a succession of targets.
With Target and P-CPI we are aiming to define specific semantics. I am
concerned whether we will be able to define these semantics tightly
enough to ensure consistent implementations. The more URIs we try to
define, the harder it will be to assign each one a clearly
distinguishable meaning. I hope the next draft will help.

John

> Sent: 15 January 2008 08:48
> To: Francois Audet

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 15 Jan 2008 11:41:15 +0100

Hi John,

>I guess what still confuses me is, when both Target and P-CPI 
>are used, which comes first, i.e., which represents the 
>earlier target? When I read the draft, I thought Target was 
>earlier. From various clarifying emails I now get the 
>impression that Target is later. Can you confirm?

I am not sure what you mean by "earlier" target. 

Target, if present, always represents the current target. A receiving
entity that receives a request without a Target header has to assume
that the Request-URI represents the current target. When no Target
header is available on the request then the Target is inserted when a
reroute is performed.

P-CPI is ONLY used to maintain the R-URI which is rewritten by the
contact of the UAS. I.e. by the home proxy which is usually at the end
of a chain of proxies.

When both Target and P-CPI are used: Target always represents the
current target. P-CPI always represents the AOR received by the home
proxy which may in some cases be the same as the current target but it
may also be the last route (not equal to the current target) taken to
deliver the request. 

>Picking up on Francois' point about History-Info, with the 
>introduction of Target and P-CPI we do indeed have a lot of 
>URIs, and of course History-Info can already convey all these 
>URIs and any others. The difference is that History-Info does 
>not give particular semantics to each of the URIs it conveys 
>- they are simply a succession of targets.

Yes, we agree with your analysis regarding History-Info. The
UA-loose-draft discusses further issues with using History-Info.

>With Target and P-CPI we are aiming to define specific 
>semantics. I am concerned whether we will be able to define 
>these semantics tightly enough to ensure consistent 
>implementations.

Target always represents the current target. See above.

P-CPI does not represent the current target in all cases. See above.

>The more URIs we try to define, the harder it will be to assign each
one a clearly distinguishable meaning. I hope the next draft will help.

In the next version of the draft I will remove as much as possible about
P-CPI, in order not to cause confusion. I will only keep some text where
I describe the semantical difference between Target and P-CPI.

I also do agree with one of your previous comments, that we should
clarify the meaning of all the URIs we're using - and that should be
done no matter if we adopt Target or not.

Regards.

Christer

> Loose-route 
> > >I think explaining all that in great and precise details, with a 
> > >concrete example would be very useful.
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Jan 2008 11:50:41 +0000

Christer, 

> Sent: 15 January 2008 10:41
> To: Elwell, John; Francois Audet
> Cc: [email-masked]; Paul Kyzivat; DRAGE, Keith (Keith)
[JRE]Assuming that the target changes as the request progresses
downstream, I meant the one that occurs first.

> may also be the last route (not equal to the current target) taken to
[JRE] I think I am getting there. So the target could be some sort of
call centre group, for example, and P-CPI could be the AoR of the
selected member of that group. Correct?
I am a little concerned about using the term "AoR" in the definition of
these AoRs. What about a request targeted at a GRUU? I would imagine the
Target and P-CPI would both contain the GRUU, which is not an AoR.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 15 Jan 2008 13:49:18 +0100

Hi John, 

>>contact of the UAS. I.e. by the home proxy which is usually 
>>at the end of a chain of proxies.
>> 

>[JRE] I think I am getting there. So the target could be some 
>sort of call centre group, for example, and P-CPI could be 
>the AoR of the selected member of that group. Correct?

Correct.

>I am a little concerned about using the term "AoR" in the 
>definition of these AoRs. What about a request targeted at a 
>GRUU? I would imagine the Target and P-CPI would both contain 
>the GRUU, which is not an AoR.

Good point. I guess we could simply say URI. We'll fix that in the next
version of the document.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2008 08:00:28 -0500

I am still confused by the distinction between Target and P-CPI.

I agree that you have described rules for updating Target that are 
different from those for updating P-CPI. But it seems to me that is a 
distinction without a significant difference. For the recipient of the 
request, the two are used the same way, toward the same end. If anything 
I would view the rules for Target to be just a bug fix on P-CPI.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 15 Jan 2008 11:04:09 -0600

I think we should charge customers per URI in the protocol.

We'd be rich. 

> Sent: Tuesday, January 15, 2008 01:20
> To: Christer Holmberg; Audet, Francois (SC100:3055)
> Cc: [email-masked]; DRAGE, Keith (Keith); Paul Kyzivat
> implementations. The more URIs we try to define, the harder 
> it will be to assign each one a clearly distinguishable 
> meaning. I hope the next draft will help.
> 
> John
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Tue, 15 Jan 2008 18:39:00 +0100

I think we'll also need a new response code: 4xx I'm confused, too many 
URIs in request

Seriously, a solution based on yet another header with an URI IMHO 
introduces more complexity/confusion than solving the issue is worth.

Better to limit the scope of the problem we're trying to solve and 
document the known limitations / use cases. If the problem is to deliver 
the request URI to a UAS which is registered with its home proxy, and 
there is a mechanism by which the proxy can detect support by the UAS, 
Jonathan's solution is fine. To other proxies being in the path not 
supporting this mechanism it would still appear as basic loose routing, 
so I don't see the issue there (if needed we could extend the Path 
mechanism with some flag as done for outbound)

Regards,
Jeroen

Francois Audet wrote:
>>> Route/Target. And, as the draft says, P-CPI will still have 
>>>       
>> to be used 
>>     
>>> However, again, the purpose of the draft was to provide an 
>>>       
>> alternative 
>>     
>>>>> Cc: [email-masked]; DRAGE, Keith (Keith); Paul Kyzivat; 
>>>>>           
>> Elwell, John
>>     
>>>>> Subject: RE: [Sip] RE: Delivering request-URI and
>>>>>           
>>> parameters to UAS
>>>       
>>>>> via proxy
>>>>>
>>>>>
>>>>> Hi Francois,
>>>>>
>>>>>           
>>>>>> And if that's the case, then I don't see why it is
>>>>>>             
>>> different from
>>>       
>>>>>> P-Called-ID (although I might be missing something 
>>>>>>             
>> with what the 
>>     
>>>> working on
>>>>> The P-CPI is inserted when the R-URI is rewritten by 
>>>>>           
>> the Contact 
>>     
>>>>> So, if we follow the definitions in the ua-loose-route
>>>>>           
>>> draft, P-CPI
>>>       
>>>>> But, no matter whether we call it retarget or reroute,
>>>>>           
>>> the point is
>>>       
>>>>> Contact address of the UAS. The scope of Target is wider
>>>>>           
>>> than that,
>>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 09:09:07 +0100

Hi, 

>I agree that you have described rules for updating Target 
>that are different from those for updating P-CPI. But it 
>seems to me that is a distinction without a significant 
>difference. For the recipient of the request, the two are 
>used the same way, toward the same end. If anything I would 
>view the rules for Target to be just a bug fix on P-CPI.

You don't update P-CPI. It's inserted by the home proxy, and nothing
else.

The headers have differenct semantics. I don't see that as a bug.

Maybe we could try to change the semantics of P-CPI, and re-define the
header, but that was never my intention when I proposed to use P-CPI.

Regards,

Christer 

> 	Paul
> 
> Christer Holmberg wrote:
> > Hi John,
> > 
> >> I guess what still confuses me is, when both Target and P-CPI are 
> >> used, which comes first, i.e., which represents the 
> earlier target? 
> >> When I read the draft, I thought Target was earlier. From various 
> >> clarifying emails I now get the impression that Target is 
> later. Can 
> >> you confirm?
> > 
> >> introduction of Target and P-CPI we do indeed have a lot 
> of URIs, and 
> >> of course History-Info can already convey all these URIs and any 
> >> others. The difference is that History-Info does not give 
> particular 
> >> semantics to each of the URIs it conveys
> semantics. I 
> >> am concerned whether we will be able to define these semantics 
> >> tightly enough to ensure consistent implementations.
> > 
> > In the next version of the draft I will remove as much as possible 
> > about P-CPI, in order not to cause confusion. I will only keep some 
> > text where I describe the semantical difference between 
> Target and P-CPI.
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 09:12:11 +0100

Hi Jeroen, 

URIs in request
>Seriously, a solution based on yet another header with an URI IMHO
introduces more complexity/confusion than solving the 
>issue is worth.
> 
>Better to limit the scope of the problem we're trying to 
>solve and document the known limitations / use cases. If the 
>problem is to deliver the request URI to a UAS which is 
>registered with its home proxy, and there is a mechanism by 
>which the proxy can detect support by the UAS, Jonathan's 
>solution is fine. 

I don't think that is the whole problem (if it was, P-Called-Party-ID
would probably work just fine). To my understanding it is not
necessarily the home proxy of the UAS which rewrites the Request-URI in
the use-cases presented in the drafts. It can be another entity in the
path - an entity which havs no clue about what the UAS supports or not.

Regards,

Christer

> >> tightly enough to ensure consistent implementations. The 
> more URIs we 
> >> try to define, the harder it will be to assign each one a clearly

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 09:40:47 +0100

Hi,

We've uploaded a new version (-01) of the Target draft.

We've tried to make things more clear. I've also removed all text about
P-Called-Party-ID, except from one chapter where we try to explain the
semantical difference between Target and P-CPI.

You can also find the draft from:
http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-del
ivery-01.txt

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Jan 2008 09:25:39 +0000

Christer,

Thanks for this revision, which makes things somewhat clearer. I do have
a couple of comments:

1. I am not sure I agree with the assertions in section 4 concerning
issues with the mechanisms in loose-route. Taking example 1, the Route
header field should contain enough entries to get you to the registered
contact, not just to an intermediate proxy. Therefore this situation
should not arise with a correctly implemented home proxy. It is not
clear to me how example 2 could arise either, for similar reasons. The
MGC case can be resolved by taking into account the option tag in the
REGISTER request, or if it is permanently registered, through
provisioning.

2. Comparing the mechanism proposed with the loose-route mechanism, my
understanding is:
a)When retargeting occurs, the loose-route mechanism places the new
target in the Request URI. Your proposal places the new target in both
the Request-URI and the Target header field.
b) When rerouting, the loose-route mechanism places the new route (i.e.,
the registered contact) in the Route header field. Your proposal places
the new route in the Request-URI (the latter as per RFC 3261).
So the two mechanisms solve exactly the same problems using a slightly
different mechanism. Correct?

3. How P-Called-Party-ID fits into this is not really relevant from an
IETF perspective - it seems there are some 3GPP-specific situations
where the contents of P-Called-Party-ID will not equal the contents of
Target. Correct?

4. If my suggestion in point 1 above that the loose-route mechanism does
not suffer from the problems suggested, then each mechanism will work
and each addresses the same problem. So it is just down to a beauty
contest between the two. Correct?

John

> Sent: 16 January 2008 08:41
> To: [email-masked]
> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; Jeroen 
> van Bemmel; Francois Audet
> Subject: Delivering request-URI and parameters to UAS via 
> proxy - new version of the 
> draft-holmberg-sip-target-uri-delivery draft
> 
> 
> Hi,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 12:05:48 +0100

Hi John, 

>Thanks for this revision, which makes things somewhat 
>clearer. I do have a couple of comments:
> 
>1. I am not sure I agree with the assertions in section 4 
>concerning issues with the mechanisms in loose-route. Taking 
>example 1, the Route header field should contain enough 
>entries to get you to the registered contact, not just to an 
>intermediate proxy. Therefore this situation should not arise 
>with a correctly implemented home proxy. It is not clear to 
>me how example 2 could arise either, for similar reasons. The 
>MGC case can be resolved by taking into account the option 
>tag in the REGISTER request, or if it is permanently 
>registered, through provisioning.

The examples are not meant to show bugs in the loose-route mechanism.
They are meant to help people understand the limitations with the
loose-route mechanism.
 
>2. Comparing the mechanism proposed with the loose-route 
>mechanism, my understanding is:
>a)When retargeting occurs, the loose-route mechanism places 
>the new target in the Request URI. Your proposal places the 
>new target in both the Request-URI and the Target header field.
>b) When rerouting, the loose-route mechanism places the new 
>route (i.e., the registered contact) in the Route header 
>field. Your proposal places the new route in the Request-URI 
>(the latter as per RFC 3261).
>So the two mechanisms solve exactly the same problems using a 
>slightly different mechanism. Correct?

Yes. The two solutions intend to solve the same problem.
 
>3. How P-Called-Party-ID fits into this is not really 
>relevant from an IETF perspective - it seems there are some 
>3GPP-specific situations where the contents of 
>P-Called-Party-ID will not equal the contents of Target. Correct?

Correct.

>4. If my suggestion in point 1 above that the loose-route 
>mechanism does not suffer from the problems suggested, then 
>each mechanism will work and each addresses the same problem. 
>So it is just down to a beauty contest between the two. Correct?

See question 1.

We believe that our solution does not have the same limitations as the
loose-route solution. But, again, both solutions intend to solve the
same problem.

Regards,

Christer

> > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; Jeroen van 
> > Bemmel; Francois Audet
> proxy - new 
> > version of the draft-holmberg-sip-target-uri-delivery draft
> > 
> > 
> > Hi,
> > 
> > We've tried to make things more clear. I've also removed all text 
> > about P-Called-Party-ID, except from one chapter where we try to 
> > explain the semantical difference between Target and P-CPI.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Jan 2008 11:19:25 +0000

Christer,

I hear what you are saying, but I don't really see that the points you
raised in section 4 are real limitations of the loose route mechanism.

John 

> Sent: 16 January 2008 11:06
> To: Elwell, John; [email-masked]
> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet
> UAS via proxy - new version of the

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 12:50:54 +0100

Hi, 

I think it is a limitation that an entity using the mechanism has to
know whether the the next hop supports it or not, and that the mechanism
can only be used if the subsequent hops support it.

Regards,

Christer

> > Subject: [Sip] RE: Delivering request-URI and parameters to UAS via 
> > proxy - new version of the draft-holmberg-sip-target-uri-delivery 
> > draft
> > 
> > 
> > Hi John,
> > 
> concerning 
> > >issues with the mechanisms in loose-route. Taking example 1, the 
> > >Route header field should contain enough entries to get you to the 
> > >registered contact, not just to an intermediate proxy. 
> Therefore this 
> > >situation should not arise with a correctly implemented 
> home proxy. 
> > >It is not clear to me how example 2 could arise either, 
> for similar 
> > >reasons. The MGC case can be resolved by taking into account the 
> > >option tag in the REGISTER request, or if it is permanently 
> > >target in the Request URI. Your proposal places the new target in 
> > >both the Request-URI and the Target header field.
> > >b) When rerouting, the loose-route mechanism places the new route 
> > >(i.e., the registered contact) in the Route header field. Your 
> > >proposal places the new route in the Request-URI (the 
> latter as per 
> > >RFC 3261).
> relevant from 
> > >an IETF perspective - it seems there are some 3GPP-specific 
> > >situations where the contents of P-Called-Party-ID will 
> not equal the 
> > >contents of Target. Correct?
> > 
> > Correct.
> > 
> mechanism 
> > >does not suffer from the problems suggested, then each 
> mechanism will 
> > >work and each addresses the same problem.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2008 07:59:05 -0500

> can only be used if the subsequent hops support it.

In theory it is a problem. Its not at all clear that it is a problem in 
practice. That depends on whether this *will* be known in the places 
where the mechanism is used.

AFAIK the loose route draft requires that the behavior of the next hop 
*be* known before the mechanism is used. So raising issues based on 
problems if it is used inappropriately are not valid. What *would* be 
valid are places where the mechanism is not used because support it not 
known, resulting is less functionality. I remain to be convinced there 
are any such cases.

So I think these two mechanisms are getting close to be just being in a 
beauty contest.

I think the crucial point in both of these is deciding when you are 
retargeting vs rerouting.

	Paul

---

From: <[email-masked]>
Date: Wed, 16 Jan 2008 18:30:43 +0530

Hi there,
Can some one suggest me info on SIP Routers.
Are there any SIP Routers available in the market today?
 
Regards
Kamal

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Jan 2008 13:52:32 +0000

Christer,

I don't think the entity using the mechanism needs to know about next
hop support for the loose route mechanism - only whether the UAS
supports it. If the UA registers, then the loose route draft provides an
automatic mechanism. If the UA does not register, support would need to
be indicated by provisioning. I am not sure this ranks as a significant
limitation, since a certain amount of provisioning needs to be done
anyway for UAs such as gateways that do not register.

John 

> Sent: 16 January 2008 11:51
> Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet
> to UAS via proxy -new version of the

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 15:32:10 +0100

John,

According to the UA-loose-route draft, every proxy in the path need to
support the mechanism in order for the "current target" to be retained
in the R-URI. A good example is the "Service Invocation" use case in the
UA loose route draft.

Maybe the "loose route" wording is confusing (I think it is also
mentioned in the UA-loose-route draft that a better naming may be
needed)?

Also, maybe one can assume that a home proxy knows what entities not
registering (MGCs etc) support. But, again, we are not only talking
about home proxies.

Regards,

Christer 

> Sent: 16. tammikuuta 2008 15:53
> To: Christer Holmberg; [email-masked]
> I don't think the entity using the mechanism needs to know 
> about next hop support for the loose route mechanism - only 
> whether the UAS supports it. If the UA registers, then the 
> loose route draft provides an automatic mechanism. If the UA 
> does not register, support would need to be indicated by 
> provisioning. I am not sure this ranks as a significant 
> limitation, since a certain amount of provisioning needs to 
> be done anyway for UAs such as gateways that do not register.
> 
> John 
> 
> > via proxy -new version of the 
> > know whether the the next hop supports it or not, and that the 
> > mechanism can only be used if the subsequent hops support it.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 16 Jan 2008 15:44:18 +0100

Hi Paul, 

>In theory it is a problem. Its not at all clear that it is a 
>problem in practice. That depends on whether this *will* be 
>known in the places where the mechanism is used.

I don't think it's a theoretical problem.

You may have next hop entities in different domains, belonging to
different operators, assigned dynamically for each call (using DNS, load
sharing etc), being updated with more/less capabilities very frequencly
etc etc etc. So, I think there are lots of scenarios where it will
simply be impossible for an entity to know what the next physical hop
will support.

Yes, an UA can indicate to its home proxy what it supports, but again I
think it is important that we are not only talking about home proxies.

And, if we are going to start making protocol design based on the fact
that entities know what other entities support, why do we need
option-tags, why do we need Require, why do we need SDP? Why don't we
just assume everything is provisioned...

I thought the idea behind SIP, and the whole internet model, was to NOT
rely on provisioning.

>*be* known before the mechanism is used.
>
>So raising issues based on problems if it is used inappropriately are
not valid.

Again, the examples are just there to explain the limitation.

Also, the issue about possible services that may break is not related to
inappropriately use of the mechanism. The entity that does trigger the
service relying on the mechanism may very well know that the next hop
supports it. But, the hop after the next hop, and/or the hop after the
hop of the next hop, may not support it. So, somewhere in the chain the
service relying on the mechanism will be "broken" - even if the hop that
doesn't support the mechanism has nothing to do with the service as
such.

We think that limits the usability of the mechanism (again it has
nothing to do with inappropriately use of the mechanism).

>What *would* be valid are places where the mechanism is not used
because support it not known, resulting is less 
>functionality. I remain to be convinced there are any such cases.
> 
beauty contest.

Yes, I agree. We should get a clear defintion, once and for all.

Regards,

Christer

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Jan 2008 09:45:43 -0500

Maybe I am missing something simple.
But, as I said at the meeting when Jonathan's draft was discussed, the 
main problem I have with the proposed solution(s) relates to the 
distinction between retargeting and routing.  This distinction seems to 
be central to both proposals.
The description of the distinction looks clear enough in the abstract.
But when I try to analyze how a proxy would actually know which 
operation it is performing, it is not clear.  Sometimes I am sure it 
will "just work."  But the description, and thinking about the wide 
range of actual things proxies do, leaves me very uncertain as to the 
clarity.

So I would at least like to ask if other folks find the distinction 
sufficiently clear to be reliable for meeting the need.  My own hope had 
been that this process would either clarify the distinction or provide a 
different distinction which was clearer.

Again, I may be off in left field, but after reviewing the drafts again 
I felt I had to ask.

Joel

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 16 Jan 2008 18:43:50 +0100

> semantical difference between Target and P-CPI.

Thanks Christer, the new version is pretty clear about the difference
between Target and P-Called-Party-ID.  However, other than the semantic
difference, I'd also add that the Target header could be used in a
cross-domain registration case, when the registered contact for a
specific URI is an AOR itself targeting a different domain.  As far as I
know, such a case is uncommon in current SIP deployments, but it could
appear more frequently with P2PSIP overlays, e.g. when peers with
limited connectivity make themselves globally reachable using P2P URIs
(maybe temporary ones).

-- 
Ciao,
Enrico

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jan 2008 12:14:46 -0600

At 07:00 AM 1/16/2008, [email-masked] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C85840.19ECE0A2"
>
>Hi there,

Kamal

which OSI layer are you wanting these SIP Routers to be operating at 
(layer 3 or layer 7 or another layer)?

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jan 2008 07:58:54 +0000

Christer,

We still seem to have a disconnect in our understanding. See below.

John 

> Sent: 16 January 2008 14:32
> to UAS via proxy-new version of the 
[JRE] The Service Invocation section in loose-route tells me nothing
about proxies on the path. It simply talks about invocation of a service
at the UAS.

> registering (MGCs etc) support. But, again, we are not only talking
[JRE] Surely it is only the home proxy that takes an AoR and determines
a contact URI to route to. Maybe my understanding of home proxy is
different.

> > > > > > > version of the

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 17 Jan 2008 11:54:34 +0100

>>in the R-URI. A good example is the "Service Invocation" use case in 
>>the UA loose route draft.
>[JRE] The Service Invocation section in loose-route tells me 
>nothing about proxies on the path. It simply talks about 
>invocation of a service at the UAS.

This is what the loose draft says:

"5. Proposed Solution

   The proposed solution is simple.  When handling a request, a proxy
   only rewrites the Request-URI when performing a retargeting
   operation.  If, instead, the proxy is trying to route the request via
   some entity (whether its a proxy or UA) to reach the target, the
   Request-URI is retained, and Route header fields are pushed into the
   request to reach the target.

etc."

This applies to ALL proxies on the path, otherwise one will not always
find the current target (service invocation uri) in the Request-URI. 

So, what is your understanding?

Regards,

Christer

> > > I don't think the entity using the mechanism needs to know about 
> > > next hop support for the loose route mechanism - only whether the 
> > > UAS supports it. If the UA registers, then the loose route draft 
> > > provides an automatic mechanism. If the UA does not register, 
> > > support would need to be indicated by provisioning. I am not sure 
> > > this ranks as a significant limitation, since a certain amount of 
> > > provisioning needs to be done anyway for UAs such as 
> gateways that 
> > > do not register.
> > > 
> > > John
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jan 2008 11:11:12 +0000

> Sent: 17 January 2008 10:55
[JRE] Yes, but it doesn suggest to me that the proxies you need to route
through are going to perform service invocation, so the fact that the
information needed for service invocation is in the Request-URI should
not be a concern for those proxies - they will do what any good proxy
will do - route on the contents of the Route header field. Service
information in the Request-URI is for the UAS.

John

> > > > > > > Sip mailing list  
> https://www1.ietf.org/mailman/listinfo/sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jan 2008 13:13:08 -0600

The ongoing discussion around parameter passing mechanisms is getting  
wrapped up in some concepts that we really haven't yet described well  
enough to be communicating clearly. This message is an attempt to  
develop a better understanding of the basic problem.

Even given something as simple as a "SIP proxy", we have three  
fundamentally different modes of operation, and one of those modes  
has two sub-cases that require different thinking.

In the first fundamental mode, the destination of the request is not  
changed by the proxy. The proxy gets the request, looks at it, and  
makes a best guess as to where the request should be sent so as to  
get the request closer to the destination encoded in that request.  
This is roughly analogous to IP routing, where the router does not  
change any of the addresses encoded in the packet. I call this  
fundamental mode "request routing".

In the second fundamental mode, the proxy alters the target of the  
request. Under RFC 3261 as-is, this means that the request-URI is  
changed by the action of the proxy. In general, I call this  
fundamental mode "request retargeting", except that our vocabulary  
isn't completely consistent here. Incidentally, while the first  
fundamental mode is roughly analogous to IP level routing, this  
second fundamental mode is more similar to IP-level network address  
translation. Yes, we've re-invented NAT. For the purpose of future  
clarity, I propose we start calling this fundamental mode "request  
translation".

There are two sub-cases of the second fundamental mode -- that is,  
two kinds of request translation.

In the first sub-case, the proxy transforms the request-URI in a way  
that preserves the identity of the target. That is, the request is  
still going to the same distinct entity, it's just using a different  
request URI to get there. This is what happens when a "home proxy"  
does what I have in the past called "contact routing" and the  
original request URI is transformed from an AOR into a contact URI  
registered against that AOR. The important thing here is that it is  
reasonable for the message sender to expect the message recipient to  
be able to authenticate using the identities expressed in the To:  
header field, which is in general the same as the identity expressed  
in the original Request URI -- that is, as the AOR. So for example:  
sip:[email-masked] registers from sip:[email-masked]. Alice calls  
sip:[email-masked]. Bob's proxy transforms this to  
sip:[email-masked]. Bob gets the request, extracts the To" header  
field, and could reasonably insert an Identity header into the  
response claiming to be "sip:[email-masked]".

As I said, I've previously called this first sub-case "contact  
routing". We probably shouldn't, since properly it is a translation  
(the request URI changes), not routing. I suggest that we call this  
"translation with preservation of target identity" until somebody  
comes up with a catchier name. The most common example of translation  
with preservation of identity is probably the "home proxy" applying a  
Contact:, which we might call "contact translation". Perhaps we could  
use "rerouting" as a short name, and use "contact rerouting" for the  
thing that a home proxy does.

In the second sub-case of the second fundamental mode, the proxy  
transforms the request URI in a way that does NOT preserve the  
identity of the target. That is, the request is going to a distinctly  
different entity from that indicated by the original request URI and  
the To: header field. Such a case arises if Bob forwards his calls to  
Charlie. Alice sends a request to "sip:[email-masked]" and gets back  
a response can only be authenticated as being from  
"sip:[email-masked]". It is this second case that gives rise to  
the unanticipated response problem and has lead people to propose  
that all retargeting be replaced with redirection. We might call this  
sub-case "translation without preservation of target identity". We've  
often called this sub-case "retargeting" in the past.

We also have a third fundamental mode, "redirection". In this mode,  
the proxy sends a response that encodes a new target for subsequent  
requests. The identity of this new target is independent from the  
identity of the original target -- it may or may not be the same, and  
the act of redirection says nothing about this relationship. As an  
example, Alice calls sip:[email-masked]. The proxy at example.com  
sends Alice a response redirecting her to "sip:[email-masked]".  
Alice then calls "sip:[email-masked]".

So to recap, we have three basic proxy operations in RFC 3261:

1) Request routing, which preserves the request URI.

2) Request rerouting, which changes the request URI but preserves the  
identity of the request's target.

3) Request retargeting, which changes the request URI and changes the  
identity of the request's target.

We also have a related operation:

4) Request redirection, which informs an upstream node about a new  
identity to target instead of the original.

As a further layer of complexity. note that these proxy operations  
can be stacked. That is, we might, in the process of dealing with one  
request, see multiple applications of the first three, followed by an  
application of the fourth.

Leaving the unanticipated response problem aside, we have two  
fundamental problems with both rerouting and retargeting. The various  
Called-Party-ID, Target, UA-Loose-Route,and other such mechanisms are  
attempting to solve these problems. History-Info provides a related  
set of solution that also encompasses request redirection.

Problem 1: Expressing the identity that was originally the target of  
the request.

Problem 2: Delivering any end-to-end parameters that might have been  
encoded in the original request URI. Note that this is complicated by  
the possibility of end-to-middle parameters that need to be stripped  
by a mid-path node.

We also have a related problem that, AFAIK, neither CPID, nor Target  
nor UA-Loose-Route attempt to solve, but that History-Info does  
attempt, which is:

Problem 3: Expressing what operations have occurred, and WHY they  
have occurred, in such a way that the target, mid-path boxes, and/or  
the requester can do something useful with this knowledge.

I've always held that this last problem is infinitely complex and  
that we should not try to solve it in the general case, which  
explains my reluctance to attack the History-Info problem (or indeed  
the old Diversion header, which also tickled part of this problem  
space). Building applications that require Ultimate Understanding  
seems to me to be a Bad Idea. Much as the invention of time travel  
will have made the concept of future-perfect tense untenable (the  
future will have been found not to have been perfect after all), so  
too is the concept of Ultimate Understanding untenable -- if you know  
everything, you can't possibly understand it since understanding  
requires knowledge outside the subject being considered, and if you  
understand everything you know, you'll understand you don't know  
everything. And that sums up the way I currently feel about the whole  
US-Loose-Route/CPID/Target discussion.

Conclusion:

New proposed vocabulary for proxy operations: request routing,  
rerouting, retargeting, and redirection.

Call for clarity on exactly which problems we're solving with UA- 
Loose-Routing, target, CPID, etc. Proposed: target identity, end-to- 
end parameters.

--
Dean Willis

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 17 Jan 2008 20:35:23 +0100

So out of interest which group would you slot the subdomain to domain
translation in, e.g.

[email-masked] to [email-masked] 

And vice versa.

And I agree, we do need some vocabulary in this area.

There was a definition of some terms at a higher level in 

http://tools.ietf.org/id/draft-rosenberg-rai-phone-names-numbers-00.txt

Which we may want to reuse as well.

Regards

Keith

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, January 17, 2008 7:13 PM
> To: IETF SIP List
> Subject: [Sip] Vocabulary and problem statement for 
> Request-URI, retargeting,and SIP routing (long, but read it!)
> 
> 
> The ongoing discussion around parameter passing mechanisms is 
> getting wrapped up in some concepts that we really haven't 
> yet described well enough to be communicating clearly. This 
> message is an attempt to develop a better understanding of 
> the basic problem.
> 
> Even given something as simple as a "SIP proxy", we have 
> three fundamentally different modes of operation, and one of 
> those modes has two sub-cases that require different thinking.
> 
> In the first fundamental mode, the destination of the request 
> is not changed by the proxy. The proxy gets the request, 
> looks at it, and makes a best guess as to where the request 
> should be sent so as to get the request closer to the 
> destination encoded in that request.  
> This is roughly analogous to IP routing, where the router 
> does not change any of the addresses encoded in the packet. I 
> call this fundamental mode "request routing".
> 
> In the second fundamental mode, the proxy alters the target 
> of the request. Under RFC 3261 as-is, this means that the 
> request-URI is changed by the action of the proxy. In 
> general, I call this fundamental mode "request retargeting", 
> except that our vocabulary isn't completely consistent here. 
> Incidentally, while the first fundamental mode is roughly 
> analogous to IP level routing, this second fundamental mode 
> is more similar to IP-level network address translation. Yes, 
> we've re-invented NAT. For the purpose of future clarity, I 
> propose we start calling this fundamental mode "request translation".
> 
> There are two sub-cases of the second fundamental mode -- 
> that is, two kinds of request translation.
> 
> In the first sub-case, the proxy transforms the request-URI 
> in a way that preserves the identity of the target. That is, 
> the request is still going to the same distinct entity, it's 
> just using a different request URI to get there. This is what 
> happens when a "home proxy"  
> original request URI is transformed from an AOR into a 
> contact URI registered against that AOR. The important thing 
> here is that it is reasonable for the message sender to 
> expect the message recipient to be able to authenticate using 
> the identities expressed in the To:  
> header field, which is in general the same as the identity 
> expressed in the original Request URI -- that is, as the AOR. 
> So for example:  
> sip:[email-masked] registers from sip:[email-masked]. Alice 
> calls sip:[email-masked]. Bob's proxy transforms this to 
> sip:[email-masked]. Bob gets the request, extracts the To" 
> header field, and could reasonably insert an Identity header 
> into the response claiming to be "sip:[email-masked]".
> 
> As I said, I've previously called this first sub-case 
> "contact routing". We probably shouldn't, since properly it 
> is a translation (the request URI changes), not routing. I 
> suggest that we call this "translation with preservation of 
> target identity" until somebody comes up with a catchier 
> name. The most common example of translation with 
> preservation of identity is probably the "home proxy" 
> applying a Contact:, which we might call "contact 
> translation". Perhaps we could use "rerouting" as a short 
> name, and use "contact rerouting" for the thing that a home 
> proxy does.
> 
> In the second sub-case of the second fundamental mode, the 
> proxy transforms the request URI in a way that does NOT 
> preserve the identity of the target. That is, the request is 
> going to a distinctly different entity from that indicated by 
> the original request URI and the To: header field. Such a 
> case arises if Bob forwards his calls to Charlie. Alice sends 
> a request to "sip:[email-masked]" and gets back a response 
> can only be authenticated as being from 
> "sip:[email-masked]". It is this second case that gives 
> rise to the unanticipated response problem and has lead 
> people to propose that all retargeting be replaced with 
> redirection. We might call this sub-case "translation without 
> preservation of target identity". We've often called this 
> sub-case "retargeting" in the past.
> 
> We also have a third fundamental mode, "redirection". In this 
> mode, the proxy sends a response that encodes a new target 
> for subsequent requests. The identity of this new target is 
> independent from the identity of the original target -- it 
> may or may not be the same, and the act of redirection says 
> nothing about this relationship. As an example, Alice calls 
> sip:[email-masked]. The proxy at example.com sends Alice a 
> response redirecting her to "sip:[email-masked]".  
> 2) Request rerouting, which changes the request URI but 
> preserves the identity of the request's target.
> 
> 3) Request retargeting, which changes the request URI and 
> changes the identity of the request's target.
> 
> 4) Request redirection, which informs an upstream node about 
> a new identity to target instead of the original.
> 
> 
> As a further layer of complexity. note that these proxy 
> operations can be stacked. That is, we might, in the process 
> of dealing with one request, see multiple applications of the 
> first three, followed by an application of the fourth.
> 
> 
> fundamental problems with both rerouting and retargeting. The 
> various Called-Party-ID, Target, UA-Loose-Route,and other 
> such mechanisms are attempting to solve these problems. 
> History-Info provides a related set of solution that also 
> encompasses request redirection.
> 
> Problem 1: Expressing the identity that was originally the 
> target of the request.
> 
> Problem 2: Delivering any end-to-end parameters that might 
> have been encoded in the original request URI. Note that this 
> is complicated by the possibility of end-to-middle parameters 
> that need to be stripped by a mid-path node.
> 
> We also have a related problem that, AFAIK, neither CPID, nor 
> Target nor UA-Loose-Route attempt to solve, but that 
> History-Info does attempt, which is:
> 
> Problem 3: Expressing what operations have occurred, and WHY 
> they have occurred, in such a way that the target, mid-path 
> boxes, and/or the requester can do something useful with this 
> knowledge.
> 
> I've always held that this last problem is infinitely complex 
> and that we should not try to solve it in the general case, 
> which explains my reluctance to attack the History-Info 
> problem (or indeed the old Diversion header, which also 
> tickled part of this problem space). Building applications 
> that require Ultimate Understanding seems to me to be a Bad 
> Idea. Much as the invention of time travel will have made the 
> concept of future-perfect tense untenable (the future will 
> have been found not to have been perfect after all), so too 
> is the concept of Ultimate Understanding untenable -- if you 
> know everything, you can't possibly understand it since 
> understanding requires knowledge outside the subject being 
> considered, and if you understand everything you know, you'll 
> understand you don't know everything. And that sums up the 
> way I currently feel about the whole 
> New proposed vocabulary for proxy operations: request 
> routing, rerouting, retargeting, and redirection.
> 
> Call for clarity on exactly which problems we're solving with 
> UA- Loose-Routing, target, CPID, etc. Proposed: target 
> identity, end-to- end parameters.
> 
> 
> --
> Dean Willis
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Jan 2008 16:08:48 -0500

> Sent: Thursday, January 17, 2008 2:13 PM
> To: IETF SIP List
> Subject: [Sip] Vocabulary and problem statement for Request-URI,
> retargeting, and SIP routing (long, but read it!)
>

This is described from the aspect of the downstream node sending the 3xx, right?  Vs. what it is for the upstream node recursing on the 3xx? (which has no idea if it's performing (2) or (3) when this occurs, but I guess could be added to the 3xx contact as a param such as described in JR's draft)

So if a proxy is doing "redirection" it is sending a 3xx, whereas the upstream proxy or UAC getting that 3xx is not doing redirection, but in fact "recursing".

> rerouting, retargeting, and redirection.

Sure.  Except I'm with Joel in that I don't know how a system knows when it's doing rerouting vs. retargeting in all cases, even if we stick to the 4474-type litmus test.  And unfortunately a lot of systems in the path have user-configured rules for what they do with the req-uri.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Jan 2008 16:10:05 -0500

> Loose-Routing, target, CPID, etc. Proposed: target identity, end-to-

Not exactly.  I believe the idea in the UALR draft is to get the target identity/params created by the nearest re-targeting event relative to the UAS, where those created by the UAC is the default such event (and thus the logical "farthest").  In other words, what you say is true, except if the request got retargeted, the identity and params will be those of the new target, and thus not end-to-end and not always what the UAC sent.  Right?

For example, given the following, where "RTRG" means Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and the single letters represent connections:

                    RRT
                   +---+
                   |R1 |
                B /+---+\ C
            RT   /       \  RT
           +---+/         \+---+
           |P1 |           |P1 |
        A /+---+           +---+\ D
         /                       \
   +---+/                         \+---+
   |UAC|                           |UAS|
   +---+                           +---+

UA-Loose-routing wants the req-uri seen on connection "A" I think.
To header gives you A.
PCPID gives you B.
Hist-Info gives you A,B,C.

But in the re-targeting scenario such as:
                    RTRG                    RRT
                   +---+                   +---+
                   |R1 |                   |R2 |
                B /+---+\ C             E /+---+\ F
            RT   /       \  RT      RT   /       \  RT
           +---+/         \+---+ D +---+/         \+---+
           |P1 |           |P2 +---+P3 |           |P4 |
        A /+---+           +---+   +---+           +---+\ G
         /                                               \
   +---+/                                                 \+---+
   |UAC|                                                   |UAS|
   +---+                                                   +---+

UA-Loose-routing wants the req-uri seen on connection "C" I think.
To header gives you A.
PCPID gives you E.
Hist-Info gives you A,B,C,D,E,F.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jan 2008 17:33:43 -0600

Hadriel Kaplan wrote:
> This is described from the aspect of the downstream node sending the
> 3xx, right?  Vs. what it is for the upstream node recursing on the
> 3xx? (which has no idea if it's performing (2) or (3) when this
> occurs, but I guess could be added to the 3xx contact as a param such
> as described in JR's draft)

right.

> So if a proxy is doing "redirection" it is sending a 3xx,

Right.

> whereas the
> upstream proxy or UAC getting that 3xx is not doing redirection, but
> in fact "recursing".
> 

The upstream node is just generating a new request. It really
doesn't know where that request is going, except that the new request
URI was obtained during an attempt to reach the old one. We'd actually
have more information from a REFER request.

We've already seen all sorts of hideous problems related to an upstream
proxy recursing on a 3xx. My take is that we should never do this in a
proxy.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jan 2008 17:45:15 -0600

Hadriel Kaplan wrote:
> Not exactly.  I believe the idea in the UALR draft is to get the
> target identity/params created by the nearest re-targeting event
> relative to the UAS, where those created by the UAC is the default
> such event (and thus the logical "farthest").  In other words, what
> you say is true, except if the request got retargeted, the identity
> and params will be those of the new target, and thus not end-to-end
> and not always what the UAC sent.  Right?

AFAIK, the original goal of UALR was to get parameters to applications. 
The last time I thought I understood the draft, these were preserved 
back somewhere on teh route stack so that the application could get them.

The other thing UALR does, and this is kind of neat, is allow different 
sets of parameters to be stuffed in at different places, and for the UAS 
to be able to differentiate where those parameters were inserted (at 
least a little bit -- "original", "middle", and "last hop" being easy to 
parse.).

> 
> For example, given the following, where "RTRG" means Re-Targeting,
"RRT" means Re-Routing, "RT" means Routing, and the single letters
>             RT   /       \  RT

I think so too.

> Hist-Info gives you A,B,C.

and D is directly visible to UAS, should RT have inserted any.

> But in the re-targeting scenario such as:

As I thought I understood it, UALR gives us the stack of A and C.

But I may well not understand.

However, this does illustrate that there's another axis of proxy 
operations that can be happening.

In addition to affecting the route, the target, and the identity of the 
target, proxies may also affect parameters.

But "repararametering" is such an ugly word. And it's an ugly concept, 
when you think about the consequences. I'm tempted to think of all 
reparametering as retargeting.

--
Dean

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Jan 2008 18:40:35 -0500

Inline ...

>Sent: Thursday, January 17, 2008 6:34 PM
>To: Hadriel Kaplan
>Cc: IETF SIP List
>Subject: Re: [Sip] Vocabulary and problem statement for 
>Request-URI,retargeting, and SIP routing (long, but read it!)
>
>Hadriel Kaplan wrote:
>> 
>doesn't know where that request is going, except that the new 
>request URI was obtained during an attempt to reach the old 
>one. 
Not sure what you mean here? The next request-uri is taken from Contact
of the redirect response. So it knows where the request is going.

> We'd actually have more information from a REFER request.
How is the Refer-To header different that Contacts in redirect response?

Sanjay

>
>We've already seen all sorts of hideous problems related to an 
>upstream proxy recursing on a 3xx. My take is that we should 
>never do this in a proxy.
>
>--
>Dean
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Jan 2008 23:30:44 -0500

> Sent: Thursday, January 17, 2008 6:45 PM
>

That may have been the intent, but as I read draft-rosenberg-sip-ua-loose-route-01.txt, it doesn't do that if a retarget occurs.  In a retargeting case the req-uri is replaced with the new target.  In the rerouting case, the req-uri is left alone, and the newly resolved destination URI (for lack of a better term) would be pushed as a Route header.

It does, though, say the previous req-uri would be pushed into the History-Info header.  It would have been before this draft too, if people implemented it, except with this new draft ONLY retarget cases would push a History-Info.  So I guess in that sense you're right, the pre-retargeting data could be there in that.

> As I thought I understood it, UALR gives us the stack of A and C.

If R1 and R2 did UALR, the UAS would get the req-uri from C, a History-Info with B, and there'd be a Route header with UAS' contact.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jan 2008 23:33:56 -0600

> of the redirect response. So it knows where the request is going.

It knows the URI that the request is going to. It doesn't know "who" 
that URI will reach, or what their relationship to the original URI is 
(unless perhaps "History-Info" explains it). However, this is at least 
enough knowledge to be able to prevent the unanticipated response 
problem sometimes, because we can at least check that the identity 
expressed in the eventual response matches that received in the 302. 
Assuming, of course, that the new URI doesn't go through some sort of 
retargeting operation that does not preserve the request identity.

> How is the Refer-To header different that Contacts in redirect response?
We're not really sure where the 3xx response came from. All we know is 
that it was generated somewhere along the path towards the original 
request-URI. REFER, however, is a request instead of a response, so we 
can use the various request-authentication techniques to figure out who 
sent it.

--
Dean

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 18 Jan 2008 08:44:36 +0100

Dean,

Regarding
> identity to target instead of the original.
Redirection does not always imply a new identity, it could be an 
alternative Contact for the same identity. The thing is that we cannot 
easily distinguish between these, since both use the same response code 
(302). So it can be either rerouting or retargeting. For the problem at 
hand this makes no difference though, in any case the request URI is 
replaced.

BTW what happened to the 'opaque' parameter solution that was part of a 
GRUU draft some versions ago? A special URI parameter that survives 
rerouting/retargeting would avoid introducing yet another identity 
header, and also detection-of-support issues.

Regards,
Jeroen

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jan 2008 07:48:18 +0000

Hadriel,

Comment at the end.

John 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 17 January 2008 21:10
> To: Dean Willis; IETF SIP List
> Subject: RE: [Sip] Vocabulary and problem statement for 
> Not exactly.  I believe the idea in the UALR draft is to get 
> the target identity/params created by the nearest 
> re-targeting event relative to the UAS, where those created 
> by the UAC is the default such event (and thus the logical 
> "farthest").  In other words, what you say is true, except if 
> the request got retargeted, the identity and params will be 
> those of the new target, and thus not end-to-end and not 
> always what the UAC sent.  Right?
> 
> For example, given the following, where "RTRG" means 
> Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and 
> the single letters represent connections:
> 
>                     RRT
>                    +---+
>                    |R1 |
>                 B /+---+\ C
>             RT   /       \  RT
>            +---+/         \+---+
>            |P1 |           |P1 |
>         A /+---+           +---+\ D
>          /                       \
>    +---+/                         \+---+
>    |UAC|                           |UAS|
>    +---+                           +---+
> 
[JRE] According to Dean's definition of RT, it does not change the
Request-URI (only the Route header field presumably, or maybe not even
that).
So C, D and E are the same. Also A and B are the same, and F and G are
the same.
So I think:
- UA-Loose-routing gives you C/D/E
- To gives you A/B
- PCPID gives you C/D/E
- Target gives you C/D/E
- Hist-info gives you A/B, C/D/E and F/G.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jan 2008 09:57:09 -0500

> header, and also detection-of-support issues.

It was judged to be a hack and rejected. That was one of the motivations 
for the current proposal, which (at the time) was thought to be cleaner. 
In hindsight maybe it wasn't so much cleaner. :-)

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Jan 2008 10:15:00 -0500

Hey John,
Inline...

> Sent: Friday, January 18, 2008 2:48 AM
> >

Yes, I agree that is the *theory*.  :)
I drew it that way though so we could argue about what the UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2 or P3 are not purely RT's and didn't support a new draft. (Since it seemed the conversation was going that way previously on this list, for example when Christer pointed out the difference between Target and PCPID)

For example, I think there is more than just a syntax difference between Christer's sip-target-uri-delivery draft (STUD?) and Jonathan's UALR approach.  Though I have no idea which one is better.

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jan 2008 15:28:12 +0000

Hadriel,

Well, I have been having a side thread with Christer and Hans Erik, and
the only difference other than syntax that they could convince me of was
support for UAs that do not register, in that with loose-route you would
need additional provisioning in the domain proxy to say that the UA
(gateway or whatever) supports loose-route. Given that you would need
provisioning in the proxy anyway for such UAs, I didn't see this as a
big deal, but it is a difference.

John 

> Sent: 18 January 2008 15:15
> To: Elwell, John; Dean Willis; IETF SIP List
> Subject: RE: [Sip] Vocabulary and problem statement 
> forRequest-URI,retargeting, and SIP routing (long, but read it!)
> 
> Hey John,
> Inline...
> 
> I drew it that way though so we could argue about what the 
> UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2 
> or P3 are not purely RT's and didn't support a new draft. 
> (Since it seemed the conversation was going that way 
> previously on this list, for example when Christer pointed 
> out the difference between Target and PCPID)
> 
> For example, I think there is more than just a syntax 
> difference between Christer's sip-target-uri-delivery draft 
> (STUD?) and Jonathan's UALR approach.  Though I have no idea 
> which one is better.
> 
> -hadriel
> 
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Jan 2008 10:52:02 -0500

Yeah I like STUD because it's explicit.
But the big difference I see is what happens if R1 supports STUD but P2, or more likely a domain between P2 and P3, Retarget but don't support STUD.  Then R2 gets a Target which is wrong - it's the URI of C vs. D (or something between D).  In other words it could be the target uri of a completely different user/domain.

With UALR, since retargeting proxies already replace the req-uri today, you'd get a req-uri which isn't wrong.  Even if P2 did Rerouting and not UALR (ie, still replaced the req-uri but was not really retargeting), the req-uri received by R2 wouldn't be totally wrong.  It would lose the parameters and info that could have been useful, but it's less likely to cause harm. (maybe?)

The counter-argument is what happens if P3 doesn't do UALR, but I would think it's far more likely that an operator of a domain has control over the equipment in their domain.

Though I'm probably thinking in circles - this whole topic makes my head hurt.  :)

-hadriel

> Sent: Friday, January 18, 2008 10:28 AM
> To: Hadriel Kaplan; Dean Willis; IETF SIP List
> Subject: RE: [Sip] Vocabulary and problem statement forRequest-
> URI,retargeting, and SIP routing (long, but read it!)
>
> Hadriel,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jan 2008 10:59:36 -0500

> big deal, but it is a difference.

In the case of registration, it is indicated by the ;lr param on the 
contact. In the case of provisioning, you need to provision a contact, 
so its just a matter of provisioning it with ;lr. That is *still* just 
provisioning a uri, so its not really a difference.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jan 2008 16:06:12 +0000

> Sent: 18 January 2008 15:52
> But the big difference I see is what happens if R1 supports 
> STUD but P2, or more likely a domain between P2 and P3, 
> Retarget but don't support STUD.  Then R2 gets a Target which 
> is wrong - it's the URI of C vs. D (or something between D).  
> In other words it could be the target uri of a completely 
> different user/domain.
> 
> With UALR, since retargeting proxies already replace the 
> req-uri today, you'd get a req-uri which isn't wrong.  Even 
> if P2 did Rerouting and not UALR (ie, still replaced the 
> req-uri but was not really retargeting), the req-uri received 
> by R2 wouldn't be totally wrong.  It would lose the 
> parameters and info that could have been useful, but it's 
> less likely to cause harm. (maybe?)
> 
> The counter-argument is what happens if P3 doesn't do UALR, 
> but I would think it's far more likely that an operator of a 
> domain has control over the equipment in their domain.
[JRE] And also, P2 should be just routing on the Route header field,
because there is still something in the stack. So it would have to be a
misbehaving proxy to get it wrong.
But in any case, I thought UALR was meant to be applied only on the last
hop (or the last set of hops) from the domain proxy to the UAS, so once
you invoke it there should not be any more retargeting or rerouting
proxies on the path. Maybe the domain proxy is never able to be certain
of this.

John

> > > > >    +---+/                                             
>     \+---+
> > > > >    |UAC|                                              
>      |UAS|

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jan 2008 16:06:56 +0000

Paul,

Yes, that was my feeling.

John 

> Sent: 18 January 2008 16:00
> To: Elwell, John
> Cc: Hadriel Kaplan; Dean Willis; IETF SIP List
> Subject: Re: [Sip] Vocabulary and problem 
> statementforRequest-URI,retargeting, and SIP routing (long, 
> but read it!)
> 
> 
> 
> Elwell, John wrote:
> > Hadriel,
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jan 2008 11:46:40 -0500

> misbehaving proxy to get it wrong.

I had always assumed that as long as there was something in the Route 
stack the R-URI would be left alone.

But if you read 3261 carefully it nowhere says that. The rules for doing 
translations on the R-URI (if you are responsible for it) are 
independent of the routing rules. So it seems valid (maybe mandatory, 
though that isn't clear to me) that you might translate the R-URI even 
though there is a Route header, and *then* route based on the Route header.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 21 Jan 2008 15:03:02 +0100

Hi,

>Well, I have been having a side thread with Christer and Hans 
>Erik, and the only difference other than syntax that they 
>could convince me of was support for UAs that do not 
>register, in that with loose-route you would need additional 
>provisioning in the domain proxy to say that the UA (gateway 
>or whatever) supports loose-route. Given that you would need 
>provisioning in the proxy anyway for such UAs, I didn't see 
>this as a big deal, but it is a difference.

It's strange that we have convinced you about that, since it not the
use-case we have been talking about...  :)

Regards,

Christer

> > Yes, I agree that is the *theory*.  :) I drew it that way 
> though so we 
> > could argue about what the UAS/UALR-draft _wants_ to happen 
> vs. what 
> > _will_ happen if P2 or P3 are not purely RT's and didn't 
> support a new 
> > draft.
> > (Since it seemed the conversation was going that way previously on 
> > this list, for example when Christer pointed out the difference 
> > between Target and PCPID)
> > 
> > For example, I think there is more than just a syntax difference 
> > between Christer's sip-target-uri-delivery draft
> > (STUD?) and Jonathan's UALR approach.  Though I have no 
> idea which one 
> > is better.
> > 
> > -hadriel
> > 
> > 
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Jan 2008 15:49:17 -0500

Sorry for jumping in late here. Trying to clarify some points here and 
there.

The UA-loose mechanism needs to know that the entity which would have 
previously been reached by the DNS/IP forwarding based on the R-URI, is 
now prepared for a request which reaches it with that target in the 
Route header field.

In the case of a UA registering through a chain of Path-inserting 
proxies, it means that only the *UA* has to support UA-loose route. 
Thats because of the assumption that the intermediate path-inserting 
proxies weren't being targeted based on the R-URI previously; they were 
(and still will) forward the request based on Route.

The 'next hop' use case that Christer is referring to are cases where we 
would have done a R-URI translation without a registration. For example, 
lets say a proxy receives an INVITE with sip:[email-masked], and its 
using some number-prefix based routing rules, which have been CONFIGURED 
into the proxy, to determine a next-hop gateway. The UA loose route 
rules would say that, since this is a routing operation and not a 
retargeting, the request looks like:

INVITE sip:[email-masked]
Route: sip:ip-of-gateway

whereas current rules would require:

INVITE sip:12345@ip-of-gateway

in this use case, the entity which was previously being reached by the 
R-URI *is* the next hop.

And so, the main limitation that I see of the UA loose route mechanism 
is, in cases where the next-hop is being reached via a configured 
routing rule, or by some other non-registration means, and said 
operation is a re-route and not retarget, the UA_loose-route requires 
that this configured routing rule include information about whether the 
next hop uses UA loose routing, and if so, what URI to use in the Route 
header.

This is a limitation, I agree. Whether its significant or not is debatable.

I will note that, it is possible to separate these concerns. We could 
define UA loose route to strictly be used for the registration cases, 
since that is the specific problem at hand.

I agree CHrister's mechanism does not have this configuration 
limitation, and that this aspect of it is better. My main beef, as 
others have commented, is that it leaves us with nearly half-dozen 
header fields which are all awfully similar (To, P-C-ID, Route, 
History-Info, and now Target). I was hoping to reduce the set and 
include only the minimum. In that way, I think UA loose route is 
architecturally better since it gives some clarity to this.

-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

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 29 Jan 2008 22:57:45 +0100

Hi Jonathan,

>Sorry for jumping in late here. Trying to clarify some points 
>here and there.
> 
>The UA-loose mechanism needs to know that the entity which 
>would have previously been reached by the DNS/IP forwarding 
>based on the R-URI, is now prepared for a request which 
>reaches it with that target in the Route header field.
> 
>In the case of a UA registering through a chain of 
>Path-inserting proxies, it means that only the *UA* has to 
>support UA-loose route. 
>Thats because of the assumption that the intermediate 
>path-inserting proxies weren't being targeted based on the 
>R-URI previously; they were (and still will) forward the 
>request based on Route.
>
>The 'next hop' use case that Christer is referring to are 
>cases where we would have done a R-URI translation without a 
>registration. For example, lets say a proxy receives an 
>INVITE with sip:[email-masked], and its using some 
>number-prefix based routing rules, which have been CONFIGURED 
>into the proxy, to determine a next-hop gateway. The UA loose 
>route rules would say that, since this is a routing operation 
>and not a retargeting, the request looks like:
> 
>in this use case, the entity which was previously being 
>reached by the R-URI *is* the next hop.
> 
>And so, the main limitation that I see of the UA loose route 
>mechanism is, in cases where the next-hop is being reached 
>via a configured routing rule, or by some other 
>non-registration means, and said operation is a re-route and 
>not retarget, the UA_loose-route requires that this 
>configured routing rule include information about whether the 
>next hop uses UA loose routing, and if so, what URI to use in 
>the Route header.
> 
>I will note that, it is possible to separate these concerns. 
>We could define UA loose route to strictly be used for the 
>registration cases, since that is the specific problem at hand.
> 
>limitation, and that this aspect of it is better. My main 
>beef, as others have commented, is that it leaves us with 
>nearly half-dozen header fields which are all awfully similar 
>(To, P-C-ID, Route, History-Info, and now Target). I was 
>hoping to reduce the set and include only the minimum. In 
>that way, I think UA loose route is architecturally better 
>since it gives some clarity to this.

I don't think a solution with the configuration limitation is
architecturally better.  

However, there is also a possibility to merge both solution proposals:
UA-loose-route would be used from the home proxy towards the UE (giving
Request-URI the same semantics as P-Called-Party-ID has today), and
Target to convey the current target. Yes, we would have another header.
But, the new header would have clear semantics, and we would get rid of
the configuration limitation. (Another possibility that does not require
a new header is to fix the semantics of the To header and allow it to be
modified, but that may have unwanted backward compatibility issues.)

The merged solution would probably also solve the issues raised by
Youssef - eventhough the "intermediate entity" (being a B2BUA) he is
talking about could as well map the Target header into a R-URI. However
we think it would be good to additionally cover the use case that is
behind this in the UALR work to justify such a combined solution.

Regards,

Christer

> about next 
> > supports it. If the UA registers, then the loose route 
> draft provides 
> > an automatic mechanism. If the UA does not register, support would 
> > need to be indicated by provisioning. I am not sure this ranks as a 
> > significant limitation, since a certain amount of 
> provisioning needs 
> > to be done anyway for UAs such as gateways that do not register.
> > 
> > John
> >