Subject: Re: [Sip] Comparison of retargeting proposals

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Apr 2008 11:30:10 -0500

The biggest problems with History-Info (IMHO) are:

- It is written so that the UAC may generate the first History-Info
entry
  or (more typically), it's proxy will. Creates some confusion on who
does what.
- It's optional
- The number of entries can be pruned by proxies, making the content
unreliable.
- The last hop (i.e., replacing with contact) is not made obvious in the
list (the
  whole point of this discussion).
- People have used it as a replacement to diversion-header, i.e., to map
to 
  ISDN redirection number information. <--- This is the biggest problem

All of those could be solve by a -bis.

(There are also a few minor mistakes in some of the flows).

> -----Original Message-----
> From: Barnes, Mary (RICH2:AR00) 
> Sent: Tuesday, April 01, 2008 06:28
> To: Hans Erik van Elburg; Audet, Francois (SC100:3055); Juha 
> Heinanen; Christer Holmberg
> Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
> Subject: RE: [Sip] Comparison of retargeting proposals
> 
> The proper use of History-Info isn't rocket science, but it 
> does require careful reading of the spec and proper 
> implementation (i.e., I agree if you don't implement the spec 
> properly, then it is a mess but that can be the case for any 
> spec that isn't implemented properly). There are some 
> inaccuracies in one of Dale's examples on forking that makes 
> it look far more error prone and problematic than it should 
> be. I'll respond separately with details.  
> 
> Mary. 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hans Erik van Elburg
> Sent: Tuesday, April 01, 2008 3:07 AM
> To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg
> Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
> Subject: Re: [Sip] Comparison of retargeting proposals
> 
> The point is that History-Info does not solve the problem so 
> something new is needed anyway.
> 
> And proper use of History-Info is rocket science as Dale has shown.
> 
> /Hans Erik
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Francois Audet
> Sent: Tuesday, April 01, 2008 2:16 AM
> To: Juha Heinanen; Christer Holmberg
> Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
> Subject: Re: [Sip] Comparison of retargeting proposals
> 
> There are existing implementations of History-Info in the field.
> 
> It's not rocket science.
> 
> And I don't see why introducing something else will be 
> simpler. It will just be extra complexity. 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > Juha Heinanen
> > Sent: Saturday, March 29, 2008 05:48
> > To: Christer Holmberg
> > Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
> > Subject: Re: [Sip] Comparison of retargeting proposals
> > 
> > Christer Holmberg writes:
> > 
> >  > However, I still fail to understand how Target would be more 
> > "complex"
> >  > than e.g. History-Info. 
> > 
> > christer,
> > 
> > ANY solution for anything must be MUCH simpler than history-info, 
> > which is far too complex by itself.
> > 
> > i haven't seen anyone fully implement history-info and most likely 
> > that is because of its complexity.  if you are now going to invent 
> > some other mechanism that is as complex or even more 
> complex, it has 
> > no change in real world.
> > 
> > i therefore suggest that h-i is deprecated and a replaced 
> by a simpler
> 
> > mechanism.
> > 
> > -- juha
> > _______________________________________________
> > 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 _______________________________________________
> 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: "Hans Erik van Elburg" <[email-masked]>
Date: Wed, 2 Apr 2008 11:43:15 +0200

It is clearly not the same as History-Info header as has been explained
in the draft and in several previous threads. It has also been explained
why History-Info can not be used for this as is.

A simple new header with a clear semantics which provides a clean
solution to the problem is therefore not even challenged by the
History-Info header. Instead you should argue why History-Info is so
bloody good that we should use it for this. We just learned that it is
not even usable as a diagnostic tool.

Why carry a whole log of request URI rewrites around when you are only
interested in the current target???

/Hans Erik

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 6:18 PM
To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: RE: [Sip] Comparison of retargeting proposals

Any addition of a new header that nobody can explain properly why it's
not the same as History-Info IS rocket science.

It sounds like we are getting paid by the number of URI we add to SIP. 

> From: Hans Erik van Elburg [mailto:[email-masked]]
> Sent: Tuesday, April 01, 2008 01:07
> The point is that History-Info does not solve the problem so something

> new is needed anyway.
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Francois Audet
> And I don't see why introducing something else will be simpler. It 
> will just be extra complexity.
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 2 Apr 2008 06:52:11 -0500

We would prefer Target-URI as it is simpler and predictable. These are
high on the evaluation criteria for operators. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2008 5:43 AM
To: Francois Audet; Juha Heinanen; Christer Holmberg
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: RE: [Sip] Comparison of retargeting proposals

/Hans Erik

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 2 Apr 2008 17:38:28 +0200

Francois,

You have missed one vital issue relating to History-Info.

You cannot use a tel URI in History-Info as RFC3966 does not allow you
to use header parameters. H-I uses header parameters for Reason and
Privacy in H-I entries.

To use a tel URI in a H-I entry requires that you convert it to a sip
URI which requires that a suitable domain be found to create a valid
entry.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2008 11:19:21 -0500

The loose-route proposal is clear, but attempts to solve a much larger problem.

The new header proposal is very far from clear, as was demonstrated by the
mailing list discussion, where nobody seems to agree on what the header 
was supposed to mean. Most people didn't understand why it was different
than the P-Called-ID (or whatever that was). 

Furthermore, what would that header actually mean? Is is the original 
target as inserted by the first UAC? If so, why is it different than the 
To header? Is it the target as modified by the originating domain's proxy 
(for example, "fixing" the phone number to make it into a real E.164 number
in a Tel or SIP URI?)? Or is it the last retargeting address? Or any 
retargeting in between? And how do you define retargeting in the first place?

The answers that Christer provided actually confused people who tought they
understood the proposal (i.e., people who tought we were talking about the 
P-Called header).

And finally, somebody needs to demonstrate how this can not overlap with
History-Info. Saying its "simpler" is misleading. It's simpler until we 
analyse completely what we are actually shooting for.

> Sent: Wednesday, April 02, 2008 02:43
> It is clearly not the same as History-Info header as has been 
> explained in the draft and in several previous threads. It 
> has also been explained why History-Info can not be used for 
> this as is.
> 
> A simple new header with a clear semantics which provides a 
> clean solution to the problem is therefore not even 
> challenged by the History-Info header. Instead you should 
> argue why History-Info is so bloody good that we should use 
> it for this. We just learned that it is not even usable as a 
> diagnostic tool.
> 
> Why carry a whole log of request URI rewrites around when you 
> are only interested in the current target???
> 
> /Hans Erik
> 
> Any addition of a new header that nobody can explain properly 
> why it's not the same as History-Info IS rocket science.
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2008 11:34:34 -0500

That's not a problem with History-Info, it's a "problem" with Tel URIs.

Tel URIs doesn't allow to use "?Reason=302" or whatever, which makes sense
because Tel URIs are not necessarily used by SIP. It could be used by
PSTN, H.323, whatever you want. So allowing SIP parameters in there (like
embedded SIP headers) makes no sense. If you want to force
SIP, don't use a Tel URI.

Why are we talking about these types of parameters in the first place?

If we need to add something to History-Info to clarify the target parameter
(whatever that means), then it should be a History Info parameter, not
a URI parameter. 

> From: Ian Elz [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 08:38
> To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); 
> Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
> You cannot use a tel URI in History-Info as RFC3966 does not 
> allow you to use header parameters. H-I uses header 
> parameters for Reason and Privacy in H-I entries.
> 
> To use a tel URI in a H-I entry requires that you convert it 
> to a sip URI which requires that a suitable domain be found 
> to create a valid entry.
> 
> - It is written so that the UAC may generate the first 
> History-Info entry
>   or (more typically), it's proxy will. Creates some 
> confusion on who does what.
> - It's optional
> - The number of entries can be pruned by proxies, making the 
> content unreliable.
> - The last hop (i.e., replacing with contact) is not made 
> obvious in the list (the
> - People have used it as a replacement to diversion-header, 
> i.e., to map to
> > To: Hans Erik van Elburg; Audet, Francois (SC100:3055); 
> Juha Heinanen; 
> > Christer Holmberg
> > The proper use of History-Info isn't rocket science, but it does 
> > require careful reading of the spec and proper 
> implementation (i.e., I 
> > agree if you don't implement the spec properly, then it is 
> a mess but 
> > that can be the case for any spec that isn't implemented properly). 
> > There are some inaccuracies in one of Dale's examples on 
> forking that 
> > makes it look far more error prone and problematic than it 
> should be. 
> > I'll respond separately with details.
> > 
> > Mary. 
> > 
> > Hans Erik van Elburg

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2008 11:52:45 -0500

Again, the burden is on the proponent of the new header to prove that
a new header is needed when we apparently have headers that carries the
same information, and more.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 2 Apr 2008 19:19:20 +0200

Francois,

I believe the confusion you are talking about was related to the first
version of the draft, where we also talked about the P-Called-Party-ID
header etc.

I tried to clarify that, and make the second version of the draft more
clear. Based on the comments I have received the issues were
solved/clarified in the second version of the draft.

The only text left about P-Called-Party-ID is the paragraph where we DO
explain the difference between it and Target.

Regards,

Christer

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 2. huhtikuuta 2008 19:19
To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: RE: [Sip] Comparison of retargeting proposals

The loose-route proposal is clear, but attempts to solve a much larger
problem.

The new header proposal is very far from clear, as was demonstrated by
the mailing list discussion, where nobody seems to agree on what the
header was supposed to mean. Most people didn't understand why it was
different than the P-Called-ID (or whatever that was). 

Furthermore, what would that header actually mean? Is is the original
target as inserted by the first UAC? If so, why is it different than the
To header? Is it the target as modified by the originating domain's
proxy (for example, "fixing" the phone number to make it into a real
E.164 number in a Tel or SIP URI?)? Or is it the last retargeting
address? Or any retargeting in between? And how do you define
retargeting in the first place?

The answers that Christer provided actually confused people who tought
they understood the proposal (i.e., people who tought we were talking
about the P-Called header).

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2008 14:20:58 -0500

As much as I read this, I still can't figure an example where the P-Called-Header
and the Target header are different:

   As defined in RFC3455 [5], if a SIP entity, which acts as registrar/
   home proxy for the terminating user, re-writes the Request-URI with
   the contact address of the registered UA it may insert a P-Called-
   Party-ID header field with the previous value of the Request-URI.

   The Target header field and P-Called-Party-ID header field have
   different semantics.  The Target header field represents the current
   target identity, while the P-Called-Party-ID represents the last
   Request-URI value used to reach the user before the Request-URI value
   was re-written with the Contact address of the UAS.  In some cases
   the P-Called-Party-ID may be the same as the current target but, it
   may also be the last route taken (not equal to the current target) to
   deliver the request.  Therefore the P-Called-Party-ID can not be used
   in a generic SIP environment to represent the current target. 

Can you give one. It seems to me that in both cases, the headers will
include the last Request-URI "just before it's replaced by the Contact used
in Registration".

Moving to History-Info...

The current text in History-Info is not clear at all about recording 
both "current target" and recording the target that corresponds to
the "Contact that was used in Registration" for the last hop. In fact,
none of the example illustrate the process. The implication from the
examples is that the proxy retargetting would magically know the 
contact address.

My personal preference would be to up-issue History-Info to have
a clear indication (say a History-Info parameter) that identifies the Contact, plus
some rule mandating that the previous entry would be the last target.
I would also want to fix all the examples to illustrate it. I will note that
for that approach to work, History-Info only needs to be supported at the
terminating retargeting proxy (just like target header).

The alternative is to use the proposed Target header. If we decide to go that
route, I still think that we need to up-issue History-Info (if anything to 
illustrates how the Target header works in conjunction to it). 

In either case I think we need to update History-Info at the same time as we fix this
problem.

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 10:19
> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen
> I believe the confusion you are talking about was related to 
> the first version of the draft, where we also talked about 
> the P-Called-Party-ID header etc.
> 
> I tried to clarify that, and make the second version of the 
> draft more clear. Based on the comments I have received the 
> issues were solved/clarified in the second version of the draft.
> 
> The only text left about P-Called-Party-ID is the paragraph 
> where we DO explain the difference between it and Target.
> 
> Regards,
> 
> Christer
>  
> 
> The new header proposal is very far from clear, as was 
> demonstrated by the mailing list discussion, where nobody 
> seems to agree on what the header was supposed to mean. Most 
> people didn't understand why it was different than the 
> P-Called-ID (or whatever that was). 
> 
> Furthermore, what would that header actually mean? Is is the 
> original target as inserted by the first UAC? If so, why is 
> it different than the To header? Is it the target as modified 
> by the originating domain's proxy (for example, "fixing" the 
> phone number to make it into a real
> E.164 number in a Tel or SIP URI?)? Or is it the last 
> retargeting address? Or any retargeting in between? And how 
> do you define retargeting in the first place?
> 
> The answers that Christer provided actually confused people 
> who tought they understood the proposal (i.e., people who 
> tought we were talking about the P-Called header).
> 
> And finally, somebody needs to demonstrate how this can not 
> overlap with History-Info. Saying its "simpler" is 
> misleading. It's simpler until we analyse completely what we 
> are actually shooting for.
> 
> 
> > explained in the draft and in several previous threads. It has also 
> > been explained why History-Info can not be used for this as is.
> > 
> > > From: Hans Erik van Elburg 
> [mailto:[email-masked]]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 16:22:01 -0400

> include the last Request-URI "just before it's replaced by the Contact

From a previous email I sent a long time ago, given the following reasonably complex scenario, where "RTRG" means Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and the single letters represent connections:

                    RTRG                    RRT
                   +---+                   +---+
                   |R1 |                   |R2 |
                B /+---+\ C             E /+---+\ F
            RT   /       \  RT      RT   /       \  RT
           +---+/         \+---+ D +---+/         \+---+
           |P1 |           |P2 +---+P3 |           |P4 |
        A /+---+           +---+   +---+           +---+\ G
         /                                               \
   +---+/                                                 \+---+
   |UAC|                                                   |UAS|
   +---+                                                   +---+

Goal: to get the req-uri seen on "C" (right?).

UA-Loose-routing sets the req-uri to that seen on connection "C".
Target gives you C.
PCPID gives you E.
Hist-Info gives you A,B,C,D,E,F.
To header gives you A.

C != E, because P2 and P3 could be swapping req-uri's as they 3261 route.  UALR draft says "stop swapping when you route", but Target draft does not.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Apr 2008 16:58:34 -0500

Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a different one, outside of
normal routing.  That's ok. For example, [email-masked] to [email-masked].

What is the difference between RRT (Re-Routing) and Routing (Routing)? I don't get it.

And I don't see in here the place where the Request-URI is changed to the Contact
that was used in the REGISTER (i.e., where example.com changes [email-masked] to
[email-masked]). That is really the missing part, no?

Is that what you call RRT? And if so, why is there an extra leg between it and the
UAS? Is it because P4 is an outbound proxy?

And I still don't see why C != E. It would only be different if loose route was not
used by the proxies (e.g., RFC 2543 proxies). Is that what you mean? If so, doesn't this
mean P-Called-Party-ID is essentially useless and IMS can't use it anyways? So we should 
just fix P-Called-Party-ID spec instead?

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 13:22
> To: Audet, Francois (SC100:3055); Christer Holmberg; Hans 
> Erik van Elburg; Juha Heinanen
> > include the last Request-URI "just before it's replaced by 
> the Contact 
> > used in Registration".
> 
> From a previous email I sent a long time ago, given the 
> following reasonably complex scenario, where "RTRG" means 
> Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and 
> the single letters represent connections:
> 
>                     RTRG                    RRT
>                    +---+                   +---+
>                    |R1 |                   |R2 |
>                 B /+---+\ C             E /+---+\ F
>             RT   /       \  RT      RT   /       \  RT
> C != E, because P2 and P3 could be swapping req-uri's as they 
> 3261 route.  UALR draft says "stop swapping when you route", 
> but Target draft does not.
> 
> -hadriel
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 19:05:01 -0400

> What is the difference between RRT (Re-Routing) and Routing (Routing)? I

I believe, based on the email discussion back in January, that "Re-Targeting" is when a Proxy re-targets the request to a new entity, so yes for example from bob to charlie.  In that situation, I believe what both Jonathan and Christer want is the "target-info" (the stuff we're trying to preserve) to be replaced by the new set (charlie's set).

Re-Routing is when the proxy/registrar replaces the req-uri due to AoR->contact resolution.  In that case we want to preserve the pre-resolved target info.

Routing is when a proxy routes.  I believe the intention was that this mean the proxy does not touch the req-uri, but my guess is that's not agreed is reality. (more on that later)

> [email-masked]). That is really the missing part, no?

That is R2 in the diagram.

> UAS? Is it because P4 is an outbound proxy?

P4 is an outbound proxy.  But to be clear, what's going on here is call goes to [email-masked] at R1, gets re-targeted by R1 to [email-masked] at R2, and R2 resolves it to [email-masked] (assuming Charlie's UA is trs80).

> just fix P-Called-Party-ID spec instead?

I don't know that part.  I am not taking any "side" on this issue.  I am merely trying to bring clarity through ascii art. :)

My personal experience is proxies replace req-uri during routing a LOT, even when they're not resolving AoR->contact nor "re-targeting".  And what they're changing the req-uri to does not usually affect the identity of the called party, because the username portion is not being changed, and it's an e.164.  So PCPID "works".  But for this target-info use-case you want parameters from the original req-uri, and those may not be there by the time it gets to R2 and a PCPID is created.  So that's my guess of why C != E. But it's just a guess.

---

From: Dean Willis <[email-masked]>
Date: Wed, 2 Apr 2008 20:45:44 -0500

On Apr 2, 2008, at 6:05 PM, Hadriel Kaplan wrote:
>> Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a  
>> different
>> one, outside of
>> What is the difference between RRT (Re-Routing) and Routing  
>> (Routing)? I
>> don't get it.
>
> I believe, based on the email discussion back in January, that "Re- 
> Targeting" is when a Proxy re-targets the request to a new entity,  
> so yes for example from bob to charlie.  In that situation, I  
> believe what both Jonathan and Christer want is the "target- 
> info" (the stuff we're trying to preserve) to be replaced by the new  
> set (charlie's set).
>
> Re-Routing is when the proxy/registrar replaces the req-uri due to  
> AoR->contact resolution.  In that case we want to preserve the pre- 
> resolved target info.
>

The difference between retargeting and rerouting is that rerouting  
preserves the expected response identity, and retargeting doesn't.

Assume connected-identity. In a "direct" call, one where no proxy  
routing is done, we'd expect to see that the identity sent by the  
target corresponds to the identity given for the target in the request  
URI.

That is, if Alice has invited Bob, she's expecting the connected- 
identity to be sourced from Bob.

This is preserved by typical "proxy contact routing",  to which I  
applied the term "rerouting". The request URI gets changed by the  
proxy, but the targeted identity doesn't.

So if Alice sends an INVITE for Bob's AOR to Bob's proxy, and Bob's  
proxy reroutes the INVITE to Bob's UA using a registered Contact, Bob  
still gets the call, and a connected-identity expressed by his UA will  
still be for "Bob".

However, if Bob's proxy retargeted the request to SpanishInquisition,  
the connected identity would no longer match with the request. I call  
this the "unanticipated respondent problem". After all, nobody expects  
the Spanish Inquisition to answer Bob's calls.

This could be a real problem is we were using security functions,  
since Alice might 1) not have keys for use with the Spanish  
Inquisition, and 2) Alice might reasonably wonder why they answered  
Bob's call.

Had we instead used a 302 to redirect Alice to the Spanish  
Inquisition, she'd at least be forewarned.

So, routing and rerouting operations imply that the response identity  
is equivalent to the pre-operation target identity. Retargeting  
implies that the response identity is not equivalent to the pre- 
operation target identity.

> Routing is when a proxy routes.  I believe the intention was that  
> this mean the proxy does not touch the req-uri, but my guess is  
> that's not agreed is reality. (more on that later)

In RFC 2543, routing always required changing the ReqURI.  RFC 3261  
loose-routing changed this, and proxies only change the Request URI  
when changing the target. RFC 3261 does not distinguish between target  
changes that change the identity of the target and those that do not,  
hence the new terms "rerouting" and "retargeting".

much text deleted . . .

>
> My personal experience is proxies replace req-uri during routing a  
> LOT, even when they're not resolving AoR->contact nor "re- 
> targeting".  And what they're changing the req-uri to does not  
> usually affect the identity of the called party, because the  
> username portion is not being changed, and it's an e.164.  So PCPID  
> "works".  But for this target-info use-case you want parameters from  
> the original req-uri, and those may not be there by the time it gets  
> to R2 and a PCPID is created.  So that's my guess of why C != E. But  
> it's just a guess.

I'd call that operation rerouting, not routing. It is the functional  
equivalent of replacing the request-URI with a Contact -- it's just  
that the new request-URI is determined by some means other than  
registration against the AOR. This might be, for example, via static  
provisioning, or by matching against a TRIP routing table. The fact  
that the userparts encode phone numbers is essentially irrelevant to  
the question of what type of operation (routing, rerouting,  
retargeting) is used, although it might be very important to how the  
proxy might decide which operation to use and which destination to  
encode.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 3 Apr 2008 01:18:42 -0400

> From: Dean Willis [mailto:[email-masked]]
>

Sorry I should have been clearer.  I didn't mean it was in question what rfc3261 meant, I meant it was in question what "proxies" actually do.  Now the quick answer is, if they don't do what 3261 says, those ain't "proxies".  And I agree that I'm using a bad term here - I think the issue at hand is actually what real sip hops do in the real world, even those claiming to be a "proxy", not what rfc3261 Proxies (with a capital P) do.

> provisioning, or by matching against a TRIP routing table.

Or based on an ENUM response...

> The fact

Yes, exactly.  And yet that proxy has absolutely no idea if it's re-routed or re-targeted by changing the hostpart.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2008 14:08:36 -0500

Well, this just proves that it ain't that clear. Looks like Dean's 
definition of "re-routing" is broader than Hadriel's since it includes
strict routing in "the middle" not just "the end". Whatever we do, we should
get clear terms for "re-routing".

Jonathan's draft had the merit to make all this clearer.

Anyways, thanks Hadriel for confirming my understanding of your diagram.

I still don't see the difference between P-Called-ID and Target, i.e.,
"what are the cases where C != E", unless there is 2543-style strict routing.
And if there is, then I fail to see how P-Called-ID would be used: seems to 
me if P-Called-ID points to C instead of E, it is broken and should be fixed.

Of course maybe it's my non-existent knowledge of IMS. My question to Christer
would be "Is P-Called-ID as defined today, pointing to C, broken???".

> Sent: Wednesday, April 02, 2008 18:46
> To: Hadriel Kaplan
> Cc: Audet, Francois (SC100:3055); Christer Holmberg; Hans 
> Erik van Elburg; Juha Heinanen; [email-masked]; DOLLY, MARTIN C, ATTLABS
> >> different one, outside of normal routing.  That's ok. For example, 
> >> [email-masked] to [email-masked].
> >> (Routing)? I don't get it.
> >
> > Targeting" is when a Proxy re-targets the request to a new 
> entity, so 
> > yes for example from bob to charlie.  In that situation, I believe 
> > what both Jonathan and Christer want is the "target- info" 
> (the stuff 
> > we're trying to preserve) to be replaced by the new set (charlie's 
> > set).
> >
> The difference between retargeting and rerouting is that 
> rerouting preserves the expected response identity, and 
> retargeting doesn't.
> 
> Assume connected-identity. In a "direct" call, one where no 
> proxy routing is done, we'd expect to see that the identity 
> sent by the target corresponds to the identity given for the 
> target in the request URI.
> 
> That is, if Alice has invited Bob, she's expecting the 
> connected- identity to be sourced from Bob.
> 
> This is preserved by typical "proxy contact routing",  to 
> which I applied the term "rerouting". The request URI gets 
> changed by the proxy, but the targeted identity doesn't.
> 
> So if Alice sends an INVITE for Bob's AOR to Bob's proxy, and 
> Bob's proxy reroutes the INVITE to Bob's UA using a 
> registered Contact, Bob still gets the call, and a 
> connected-identity expressed by his UA will still be for "Bob".
> 
> However, if Bob's proxy retargeted the request to 
> SpanishInquisition, the connected identity would no longer 
> match with the request. I call this the "unanticipated 
> respondent problem". After all, nobody expects the Spanish 
> Inquisition to answer Bob's calls.
> 
> This could be a real problem is we were using security 
> functions, since Alice might 1) not have keys for use with 
> the Spanish Inquisition, and 2) Alice might reasonably wonder 
> why they answered Bob's call.
> 
> So, routing and rerouting operations imply that the response 
> identity is equivalent to the pre-operation target identity. 
> Retargeting implies that the response identity is not 
> equivalent to the pre- operation target identity.
> 
> 
> > Routing is when a proxy routes.  I believe the intention 
> was that this 
> > mean the proxy does not touch the req-uri, but my guess is 
> that's not 
> In RFC 2543, routing always required changing the ReqURI.  
> RFC 3261 loose-routing changed this, and proxies only change 
> the Request URI when changing the target. RFC 3261 does not 
> distinguish between target changes that change the identity 
> of the target and those that do not, hence the new terms 
> "rerouting" and "retargeting".
> 
> much text deleted . . .
> 
> >
> targeting".  
> > And what they're changing the req-uri to does not usually 
> affect the 
> > identity of the called party, because the username portion is not 
> > being changed, and it's an e.164.  So PCPID "works".  But for this 
> > target-info use-case you want parameters from the original req-uri, 
> > and those may not be there by the time it gets to R2 and a PCPID is 
> > created.  So that's my guess of why C != E. But it's just a guess.
> 
> I'd call that operation rerouting, not routing. It is the 
> functional equivalent of replacing the request-URI with a 
> Contact -- it's just that the new request-URI is determined 
> by some means other than registration against the AOR. This 
> might be, for example, via static provisioning, or by 
> matching against a TRIP routing table. The fact that the 
> userparts encode phone numbers is essentially irrelevant to 
> retargeting) is used, although it might be very important to 
> how the proxy might decide which operation to use and which 
> destination to encode.
> 
> --
> Dean
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 3 Apr 2008 22:48:26 +0200

Hi,

The P-Called-Party-ID is only inserted by the registrar of the UAS,
while the Target can be inserted also by other entities.

Regards,

Christer

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 2. huhtikuuta 2008 22:21
To: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: RE: [Sip] Comparison of retargeting proposals

As much as I read this, I still can't figure an example where the
P-Called-Header and the Target header are different:

Can you give one. It seems to me that in both cases, the headers will
include the last Request-URI "just before it's replaced by the Contact
used in Registration".

The current text in History-Info is not clear at all about recording
both "current target" and recording the target that corresponds to the
"Contact that was used in Registration" for the last hop. In fact, none
of the example illustrate the process. The implication from the examples
is that the proxy retargetting would magically know the contact address.

My personal preference would be to up-issue History-Info to have a clear
indication (say a History-Info parameter) that identifies the Contact,
plus some rule mandating that the previous entry would be the last
target.
I would also want to fix all the examples to illustrate it. I will note
that for that approach to work, History-Info only needs to be supported
at the terminating retargeting proxy (just like target header).

The alternative is to use the proposed Target header. If we decide to go
that route, I still think that we need to up-issue History-Info (if
anything to illustrates how the Target header works in conjunction to
it). 

In either case I think we need to update History-Info at the same time
as we fix this problem.

> The only text left about P-Called-Party-ID is the paragraph where we 
> DO explain the difference between it and Target.
> 
> Regards,
> 
> Christer
>  
> 

> target as inserted by the first UAC? If so, why is it different than 
> the To header? Is it the target as modified by the originating 
> domain's proxy (for example, "fixing" the phone number to make it into

> a real

> And finally, somebody needs to demonstrate how this can not overlap 
> with History-Info. Saying its "simpler" is misleading. It's simpler 
> until we analyse completely what we are actually shooting for.
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2008 16:02:58 -0500

So what is the P-Called-Party-ID used for?

I'm trying to figure out the different use cases for P-Called-Party-ID versus
Target. 

> Sent: Thursday, April 03, 2008 13:48
> The P-Called-Party-ID is only inserted by the registrar of 
> the UAS, while the Target can be inserted also by other entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2008 17:45:56 -0400

Francois,

IMS has the notion of implicit registration, so when you register for 
AOR1 you may implicitly be registered for AOR2 and AOR3 as well. (Using 
the same Contact URI.)

So, when you subsequently receive an incoming request at your Contact 
URI, you can't tell from the Contact address which of the AORs was the 
target of the request. The P-Called-Party-ID allows you to figure that 
out, and therefore light up the proper line, or whatever, on your phone.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2008 16:53:03 -0500

What a mess.... I pitty the poor implementors who will have to implement this.

In any case, my preference is:

- An history-info-bis, with EXPLICIT history-info parameters that identify
  which entry is a Target and which one is the contact (from re-route). 
  That way you wouldn't need artificial intelligence to parse the history-info.
  Also, we would sort-out all the bugs in history info.

I can also deal with a new header, IF AND ONLY IF we also have a document that
described the accurately and without any ambivalence the different between
P-Called-Header and Target, AND if we still up-issue History-info to describe
how it works with this new header (and how history-info tracks everything).

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 14:46
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen; 
> [email-masked]; DOLLY, MARTIN C, ATTLABS
> AOR1 you may implicitly be registered for AOR2 and AOR3 as 
> well. (Using the same Contact URI.)
> 
> So, when you subsequently receive an incoming request at your 
> Contact URI, you can't tell from the Contact address which of 
> the AORs was the target of the request. The P-Called-Party-ID 
> allows you to figure that out, and therefore light up the 
> proper line, or whatever, on your phone.
> 
> 	Paul
> 
> Francois Audet wrote:
> > I'm trying to figure out the different use cases for 
> P-Called-Party-ID 
> > versus Target.
> > 
> the UAS,

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 4 Apr 2008 08:12:41 +0300

> What a mess.... I pitty the poor implementors who will have to

paul's explanation about p-called-party-id was clear to me and it is
extremely easy to implement in openser proxy.

 > described the accurately and without any ambivalence the different
 > between P-Called-Header and Target, AND if we still up-issue
 > History-info to describe how it works with this new header (and how
 > history-info tracks everything).

i don't know about Target, but history-info is easy to deal with: we
simply deprecate it as a too complex thing that no popular sip proxies
or user agents have implemented.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 02:06:48 -0500

Sorry about the HTML formating. I'm too lazy to wrap my lines. And  
yes, this should probably be in an ID, but I'm too lazy for that too.

Here's why the answers seem to be confusing -- the question is  
confused. I'd like to try and rein it in a bit, and make a proposal.

We have a couple of things we want:

1) Delivery of application-specific info (aka "parameters") from the  
originating UA to the terminating UA

2) Delivery of parameters from proxies to the terminating UA

3) Information to allow the terminating UA to know which application,  
function, or identity (or something else) at that UA is being targeted  
by the request, over and above the mundane aspects of the request such  
as ordinary headers and bodies. Presumably this information is  
inserted somehow along the way, either at the source UA or some  
intermediate (proxy or the like) node. This information may, or may  
not, be the same as #1 and #2 above.

4) We think we have a need for the terminating UA to figure out who  
inserted each bit of information. I find this compelling.

5) We think we have a need for the terminating UA to understand the  
entire decision tree that resulted in the call arriving at it. I don't  
find this compelling at all (which is why I opposed  Diversion and  
History-Info), as I think that every application people THINK they  
need this for is more readily addressed by 1-3.

These "needs" have been getting tangled up in the most perniciously  
confusing sorts of ways I can imagine. We have History-Info,  
Diversion, P-This-That-And-the-Other-Thing, and probably a couple of  
dozen other hackneyed ways to work around this problem.  Quite  
probably a large number of the SIP extension headers we've documented  
have been narrow application-specific functions that really didn't  
need an RFC, but since an RFC is required to get a header, we've had  
to do a lot of work.

Why don't we have an easy answer?

The problem starts with SIP's take-off from HTTP. If we were using  
HTTP, we could use request-URI parameters to talk to the application.  
This works very well in HTTP land, since outside of very specialized  
cases, HTTP proxies don't change the request URI, and when they do  
it's an additive thing ; they add parameters as needed. Note that  
neither IETF nor W3C has found it needful to standardize HTTP request  
parameters. Any fool can code up a CGI script that uses new ones, and  
the neat thing is, they're always scoped to the application in use.

Let's look at the request for my Google home page:

http://www.google.com/ig?hl=en&source=iglk

This conveys the location of the target node, an application  
identifier, and two parameters delivered to that application. The  
target node is www.google.com, the application is "ig", and the  
parameters are "hl", which has a value of "en", and "source", which  
has a value of "iglk".

RFC 2543 just didn't work this way. Every proxy mangled the request  
URI to the best of its ability, such that there was absolutely no way  
to use the request URI to pass any useful information between UAs. I'm  
not sure why we went down this path. I argued against it at the time,  
but obviously I lost that argument. We partially fixed this with loose  
routing in RFC 3261, but we didn't fix it well enough, and we still  
have the problem. Jonathan's UA Loose Routing draft has tried to get  
us closer to the HTTP model (but do so with full backward  
compatibility), and lots of people have complained about the apparent  
resulting complexity. It shouldn't be complex -- it's so easy with  
HTTP, but SIP just isn't HTTP anymore.

We've tried putting stuff into body parts, and the ongoing war over  
proxy manipulation of body parts and requirements for multi-part MIME  
has been running for years now. Besides, we don't really have a way of  
indicating which body part does what, as the MIME syntax just doesn't  
give us a handle on it.

We have P-Called-Party-ID, which satisfies a subset of problem #3 by  
letting the terminating UA know which identity at that UA the request  
is targeting (and this COULD be used to indicate an application as  
opposed to a user, I suppose).

We also have Target, a header that as proposed provides a sort of  
partial combination of 3, 4, and 5 by basically stacking up another  
header instance every time a proxy changes the request URI. As I  
understand the author's intentions (which is not what I get from the  
draft), the idea is that every URI seen on the path from UAC to UAS is  
recorded in an instance of the Target header, One can then read the  
list backwards, and sort of guess which one was inserted by various  
proxies and maybe figure out which one was inserted by the originating  
UA. I mostly like what I think I understand of the author's  
intentions, but it's not QUITE what I want.

And I have a head ache from trying to sort this stuff out.

So here's a suggestion for a Radically Different Approach.

Let's define a new SIP extension header field. I call it "Params" for  
now.

Eachs Params header field contains one or more parameter=value pairs.  
The only mandatory of these pairs encodes the role (UA, proxy) and  
identity of the node inserting the Params field. Another pair might  
encode the URI targeted by the request as it leaves that node (which  
is probably only useful for debugging). Another pair might encode the  
identity targeted by the request, which as we know is not the same as  
the URI of the request. Still more pairs would encode any parameters  
being delivered to the UAS terminating the request. We also need a  
rule: only insert a Params if you expect it to be useful to the  
terminating UAS.  If you aren't changing something , DON'T PUT ONE IN!

So, here's an example (with many fields left out)

Alice-1-->AliceOutboundProxy--2-->BobHomeProxy--3-- 
 >BobOutboundProxy--4-->Bob

Message 1: (note that the param MyAppID=23 is encoded by Alice)

INVITE sisp:[email-masked] SIP/2.0
From: sips:[email-masked]
To: sips:[email-masked]
Call-ID: [email-masked]
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:[email-masked],MyAppID=23

Message 2: (note no new Params)

INVITE sips:[email-masked] SIP/2.0
From: sips:[email-masked]
To: sips:[email-masked]
Call-ID: [email-masked]
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:[email-masked],MyAppID=23

Message 3: (retargeting occurs)

INVITE sips:[email-masked] SIP/2.0
From: sips:[email-masked]
To: sips:[email-masked]
Call-ID: [email-masked]
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:[email-masked],MyAppID=23
Params: role=proxy,src=bproxy.example.com,target=<sips:[email-masked]>

Message 4: (note no new Params)

INVITE sips:[email-masked] SIP/2.0
From: sips:[email-masked]
To: sips:[email-masked]
Call-ID: [email-masked]
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS boproxy.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:[email-masked],MyAppID=23
Params: role=proxy,src=bproxy.example.com,target=<sips:[email-masked]>

So with this request, Bob's UA can look at it and say "Ok, this  
requested is targeted to sips:[email-masked], so I'd best respond  
appropriately.  And oh look, the originating UA wants me to know that  
MyAppID=23." Diagnostically, we can also look at it and see that there  
was a retargeting at the proxy bproxy.example.com, since said proxy  
was kind enough to insert the Params telling us so.

Ok, now I can hear people screaming "But this is what History-Info  
does!"

That might be. I'm not sure I actually understood History-Info. But  
this seems a bunch simpler, AND it allows for inclusion of "forward  
knowledge" (i.e., parameters inserted under application control)  
rather than only "backward knowledge" (a record of the decisions that  
got us here). Hence RFC 3087 / RFC 4458 type control mechanisms can be  
used effectively. Hint: If you have a voice mail application that is  
dependent on knowing that a retargeting decision resulted from a  busy  
condition, it's easy to put a "cause=busy" into the relevant Params.  
Note also that this doesn't seem to capture the full range of History- 
Info cases. I think it is a simpler replacement that gives the  
required functionality. And since it's just new extension header  
fields, it is 100% backwards compatible.

There are also some interesting anonymization interactions. For  
example, if you don't want to reveal a source, use anonymous or a temp- 
gruu in the "src=" Params. Or better yet, don't insert a Params at  
all! They're optional except when rerouting or retargeting.

--
Dean

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 09:49:07 +0200

Of course that is why we are having these discussions.

- P-Called-Party-ID does not carry this information. As has been
explained. It might sometimes carry the same URI, but it has a different
meaning.
- History-Information does not carry this information. As has been
explained. It might somewhere carry the same URI, but if that is not
extractable as being the one we need, then what good is it. You may not
like it but that is how it is.

Otherwise WE would not have proposed a new header.

/Hans Erik 

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2008 6:53 PM
To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: RE: [Sip] Comparison of retargeting proposals

Again, the burden is on the proponent of the new header to prove that a
new header is needed when we apparently have headers that carries the
same information, and more.

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 4 Apr 2008 14:36:59 +0300

Dean Willis writes:

 > got us here). 

i fully agree with dean here.  dean's proposal is easy understand and
implement.  h-i is far too complex because of all the indexing stuff,
hassle with uri params vs. h-i params, etc.

 > fields, it is 100% backwards compatible.

again i fully agree.  whatever h-i tried to accomplish was clearly to
too much, because it resulted into complexity that never got implemented
by popular UAs or proxies.

-- juha

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 13:49:32 +0200

I think that in a closed environment like IMS where all proxies can be
guaranteed to support loose routing, there is effectively almost no
difference between P-Called-Party-ID and Target header. 

One case where also in IMS the Target and the P-Called-Party-ID would
contain different values is for example when you call a freephone
address of a certain user, where the freephone uri is a service identity
on an AS. The freephone service would reroute the request to the actual
user [email-masked]. The user may want to know that he was called
through a freephone number in this case:
P-Called-Party-ID:  [email-masked]
Target: [email-masked]

/Hans Erik
 
-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Thursday, April 03, 2008 11:03 PM
To: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: RE: [Sip] Comparison of retargeting proposals

I'm trying to figure out the different use cases for P-Called-Party-ID
versus Target.

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 4 Apr 2008 15:03:43 +0300

> Target: [email-masked]

based on the explanation yesterday on this mailing list, i got the
impression that P-Called-Party-ID would in this case contain the actual
called uri, i.e., the freephone uri, and r-uri would contain the contact
of the answering phone.

-- juha

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 14:09:03 +0200

No, because I assumed that the freephone number is not a registered AOR
of the user. 

The P-Called-Party-ID is effectively populated by the registrar when it
replaces the AOR in the Request URI with the Contact address.  

So we get:
Request URI = Contact address
P-Called-Party-ID:  [email-masked] 
Target: [email-masked]

/Hans Erik

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, April 04, 2008 2:04 PM
To: Hans Erik van Elburg
Cc: Francois Audet; Christer Holmberg; [email-masked]; DOLLY, MARTIN C,
ATTLABS

Hans Erik van Elburg writes:

 > P-Called-Party-ID:  [email-masked]  > Target:
[email-masked]

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 4 Apr 2008 15:19:42 +0300

> No, because I assumed that the freephone number is not a registered AOR

ok, so in your example proxy was forwarding the call to the freephone
uri to the user, i.e., freephone number was not an alias of the user's
aor.

-- juha

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 14:24:11 +0200

There seems to be a misunderstanding here, there is no intention for
stacking Target headers at all. There will always have to be zero or one
target header field with one clear meaning: "current target".

As soon as a retarget (using the definition from UALR draft) occurs an
existing target header will have to be removed, as it no longer
represents the current target.

Params only seems to tackle the parameter loss issue, and it seems
further to solve a different problem alltogether i.e. how to get
parameters from the caller to the callee. There is a risk that
parameters that where only intended to be received by user B end up at
user C.

/Hans Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Friday, April 04, 2008 9:07 AM
To: [email-masked] List
Subject: [Sip] Long: Thoughts on "retargeting proposals"

Sorry about the HTML formating. I'm too lazy to wrap my lines. And yes,
this should probably be in an ID, but I'm too lazy for that too.

Here's why the answers seem to be confusing -- the question is confused.
I'd like to try and rein it in a bit, and make a proposal.

3) Information to allow the terminating UA to know which application,
function, or identity (or something else) at that UA is being targeted
by the request, over and above the mundane aspects of the request such
as ordinary headers and bodies. Presumably this information is inserted
somehow along the way, either at the source UA or some intermediate
(proxy or the like) node. This information may, or may not, be the same
as #1 and #2 above.

5) We think we have a need for the terminating UA to understand the
entire decision tree that resulted in the call arriving at it. I don't
find this compelling at all (which is why I opposed  Diversion and
History-Info), as I think that every application people THINK they need
this for is more readily addressed by 1-3.

These "needs" have been getting tangled up in the most perniciously
confusing sorts of ways I can imagine. We have History-Info, Diversion,
P-This-That-And-the-Other-Thing, and probably a couple of dozen other
hackneyed ways to work around this problem.  Quite probably a large
number of the SIP extension headers we've documented have been narrow
application-specific functions that really didn't need an RFC, but since
an RFC is required to get a header, we've had to do a lot of work.

The problem starts with SIP's take-off from HTTP. If we were using HTTP,
we could use request-URI parameters to talk to the application.  
This works very well in HTTP land, since outside of very specialized
cases, HTTP proxies don't change the request URI, and when they do it's
an additive thing ; they add parameters as needed. Note that neither
IETF nor W3C has found it needful to standardize HTTP request
parameters. Any fool can code up a CGI script that uses new ones, and
the neat thing is, they're always scoped to the application in use.

This conveys the location of the target node, an application identifier,
and two parameters delivered to that application. The target node is
www.google.com, the application is "ig", and the parameters are "hl",
which has a value of "en", and "source", which has a value of "iglk".

RFC 2543 just didn't work this way. Every proxy mangled the request URI
to the best of its ability, such that there was absolutely no way to use
the request URI to pass any useful information between UAs. I'm not sure
why we went down this path. I argued against it at the time, but
obviously I lost that argument. We partially fixed this with loose
routing in RFC 3261, but we didn't fix it well enough, and we still have
the problem. Jonathan's UA Loose Routing draft has tried to get us
closer to the HTTP model (but do so with full backward compatibility),
and lots of people have complained about the apparent resulting
complexity. It shouldn't be complex -- it's so easy with HTTP, but SIP
just isn't HTTP anymore.

We have P-Called-Party-ID, which satisfies a subset of problem #3 by
letting the terminating UA know which identity at that UA the request is
targeting (and this COULD be used to indicate an application as opposed
to a user, I suppose).

We also have Target, a header that as proposed provides a sort of
partial combination of 3, 4, and 5 by basically stacking up another
header instance every time a proxy changes the request URI. As I
understand the author's intentions (which is not what I get from the
draft), the idea is that every URI seen on the path from UAC to UAS is
recorded in an instance of the Target header, One can then read the list
backwards, and sort of guess which one was inserted by various proxies
and maybe figure out which one was inserted by the originating UA. I
mostly like what I think I understand of the author's intentions, but
it's not QUITE what I want.

encode the URI targeted by the request as it leaves that node (which is
probably only useful for debugging). Another pair might encode the

--
Dean

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 14:22:21 +0200

Correct.

/Hans Erik 

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, April 04, 2008 2:20 PM
To: Hans Erik van Elburg
Cc: Francois Audet; Christer Holmberg; [email-masked]; DOLLY, MARTIN C,
ATTLABS

Hans Erik van Elburg writes:

 > No, because I assumed that the freephone number is not a registered
AOR  > of the user. 

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 13:15:21 +0100

Hans Erik,

This is a good example. For comparison purposes, can anyone say how we
would achieve this with:
i) ua-loose-route
ii) history-info
iii) Dean's proposal?

John

> Sent: 04 April 2008 12:50
> To: Francois Audet; Christer Holmberg; Juha Heinanen

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Apr 2008 11:56:02 -0500

This is so simple, that the people who say it's simple don't even agree on the
meaning.

> Sent: Friday, April 04, 2008 05:20
> To: Hans Erik van Elburg
> Cc: Audet, Francois (SC100:3055); Christer Holmberg; 
>  > No, because I assumed that the freephone number is not a 
> registered AOR  > of the user. 
> 
> ok, so in your example proxy was forwarding the call to the 
> freephone uri to the user, i.e., freephone number was not an 
> alias of the user's aor.
> 
> -- juha
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 13:35:06 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans
> Erik van Elburg
>

I beg to differ - even in IMS all "proxies" cannot be guaranteed to be doing loose-routing, if by that you mean not changing the req-uri as they forward. What's written in IMS specs and what's getting deployed/configured in the field are not identical all of the time, nor in all scenarios for the same IMS network... much like IETF SIP.
(this is not to say that this has any impact on the gist of your comment or the proposals - just noting that "IMS specs" and IMS reality are not one and the same, as you're probably aware)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 13:09:25 -0500

> target header field with one clear meaning: "current target".

I believe you. But like others, I found the draft unclear, and it made  
more sense if I assumed a stack of Target headers.

> represents the current target.

Then it doesn't help Charlie knows that he's answering a call meant  
for Bob when Bob forwards his phone to Charlie and Alice calls Bob.

> parameters from the caller to the callee.

Well, that WAS the original goal of US-Loose-Route, and is the thing  
we have a chartered milestone for:

 From our charter:
Feb 2008
Delivering request-URI and parameters to UAS via proxy to IESG (PS)

> There is a risk that

Well, that can certainly happen with any header. The workaround if it  
worries you is to use a 302.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 7 Apr 2008 16:06:10 +0200

Hi Dean, 

>Well, that WAS the original goal of US-Loose-Route, and is the thing we
>Delivering request-URI and parameters to UAS via proxy to IESG (PS)

I believe the UA loose mechanism works in the same way as the Target
mechanism in that sense: if a retarget occurs, the Request-URI is
overwritten, and the R-URI carries the current target.

Regards,

Christer

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Tue, 8 Apr 2008 11:09:17 +0200

Well... for some strange reason IMS uses IETF SIP.
I agree with you that reality is often just not right.

;-)
/Hans Erik

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, April 04, 2008 7:35 PM
To: Hans Erik van Elburg; Francois Audet; Christer Holmberg; Juha
Heinanen

> difference between P-Called-Party-ID and Target header.

I beg to differ - even in IMS all "proxies" cannot be guaranteed to be
doing loose-routing, if by that you mean not changing the req-uri as
they forward. What's written in IMS specs and what's getting
deployed/configured in the field are not identical all of the time, nor
in all scenarios for the same IMS network... much like IETF SIP.
(this is not to say that this has any impact on the gist of your comment
or the proposals - just noting that "IMS specs" and IMS reality are not
one and the same, as you're probably aware)

-hadriel

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Tue, 8 Apr 2008 11:29:26 +0200

The Target header proposal clearly ties the parameters destined for the
target with the current target, this means that if the current target
changes these parameters will no longer be. 

/Hans Erik 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, April 04, 2008 8:09 PM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sip] Long: Thoughts on "retargeting proposals"

On Apr 4, 2008, at 7:24 AM, Hans Erik van Elburg wrote:
> stacking Target headers at all. There will always have to be zero or 
> one target header field with one clear meaning: "current target".
>

> represents the current target.

Then it doesn't help Charlie knows that he's answering a call meant for
Bob when Bob forwards his phone to Charlie and Alice calls Bob.

 From our charter:
Feb 2008

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Apr 2008 12:34:32 -0500

> changes these parameters will no longer be.

Well then while it might be useful, it doesn't solve the chartered  
problem. It doesn't even attempt to solve the chartered problem.

And that makes the draft itself very useful by helping to explain what  
the problem isn't, which we've apparently become somewhat confused  
about.

--
Dean

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Tue, 8 Apr 2008 19:47:26 +0200

It solves the chartered problem that you quoted.
And it solves all the use cases listed in the UALR draft.

If you go and redefine the problem, then yes the Target header may not
longer solve the redefined problem. 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2008 7:35 PM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sip] Long: Thoughts on "retargeting proposals"

On Apr 8, 2008, at 4:29 AM, Hans Erik van Elburg wrote:
> The Target header proposal clearly ties the parameters destined for 
> the target with the current target, this means that if the current 
> target changes these parameters will no longer be.
>

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Apr 2008 15:20:57 -0500

On Apr 8, 2008, at 12:47 PM, Hans Erik van Elburg wrote:
> Dean wrote:

Ok, I'm probably confused.

The chartered problem (this part I'm sure of, I wrote the charter) is  
for delivery of URI parameters from UAC to UAS, despite speed-dial  
routing and contact routing (aka "retargeting" or "rerouting",  
depending on your definition) in a proxy or proxies between those UAs.

But you said that the current draft discards the parameters when the  
target changes, so by definition it wouldn't address that problem.

Then you said again that it DOES solve the chartered problem.

This makes me strongly suspect we're not all talking about the same  
problem, which seems like a real problem to me.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Apr 2008 17:16:34 -0400

I believe the mechanism people are looking for is to get the params from UAC to UAS, UNLESS the UAS identity changes (ie, it is retargeted), in which case it should NOT deliver the UAC's original but rather the ones of the retargeter.
In other words, there is a logical boundary/scope for the params, which is defined by a re-targeting operation.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Apr 2008 19:31:50 -0500

On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote:
>
> I believe the mechanism people are looking for is to get the params  
> from UAC to UAS, UNLESS the UAS identity changes (ie, it is  
> retargeted), in which case it should NOT deliver the UAC's original  
> but rather the ones of the retargeter.

Ok, in this scenario, is "contact routing" at the proxy a   
retargeting? I'm guessing not.

What about originating side operations, like a speed-dial application?

What about parameters inserted by a proxy?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Apr 2008 22:15:57 -0400

> retargeting? I'm guessing not.

Nope, if it is simply sending it to the same UA "identity" (such as the case when it contact-routes to a registered contact of the AoR identified by the req-uri) then it's not retargeting.  Under Christer's proposal, the Target header remains unchanged from whatever it was before that proxy, but req-uri still gets swapped to registered contact; under Jonathan's the req-uri is left alone and a Route header inserted for the registered contact-uri.

I think both of them generally assume the same model for what makes up retargeting vs. not.  Though it's not clear to me exactly how the proxies can know it.  For example if a proxy receives a req-uri for "sip:[email-masked]", would routing it to "sip:[email-masked]" based on an ACD list be a retarget or not?  What about sending it to "sip:acme.com" and it being routed to a receptionist?

> What about originating side operations, like a speed-dial application?

I'm not sure I understand why that's different than slow-dialing?  I personally don't know what applications need this req-uri param stuff in particular. (I assume so things like Refers and 3xx can expect the params they use to reach the new target)

> What about parameters inserted by a proxy?

Inserted into the req-uri?  Good question... for the authors. :)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Apr 2008 04:24:56 +0200

Hi, 

>>Ok, in this scenario, is "contact routing" at the proxy a retargeting?

>>I'm guessing not.
>
>Nope, if it is simply sending it to the same UA "identity" (such as the
case when it contact-routes to a registered 
>contact of the AoR identified by the req-uri) then it's not
retargeting.  Under Christer's proposal, the Target header 
>remains unchanged from whatever it was before that proxy, but req-uri
still gets swapped to registered contact; under 
>Jonathan's the req-uri is left alone and a Route header inserted for
the registered contact-uri.
>
>I think both of them generally assume the same model for what makes up
retargeting vs. not.

Correct.

Subclause 3.1 of the Target draft also says:

"The terms reroute, translate/translation and retarget are understood as
defined in draft-rosenberg-sip-ua-loose-route-01 [8]."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 00:07:17 -0400

One thing is troubling me in this discussion:

What are these parameters? Who is inserting them, and why?

In my world view clients don't *generate* URIs. Rather they use URIs 
that have been given to them, or that they have looked up in some public 
registry. URIs are *created* by the recipient.

In this regard they are much like postal addresses. Part of a postal 
address is routing, like the domain name in a URI. But the rest is like 
the user part of a URI. If you start sticking extra stuff into a postal 
address, the post office might get it to the right mailbox, but its 
likely to be tossed in the trash, or the extra stuff ignored.

By that logic, parameters on a URI should not be passed along when a 
request is retargeted. The parameters are meaningful, if at all, to the 
retargeter. It may in fact use them to decide where to retarget. But by 
the same logic it shouldn't be attaching them to the retargeted URI 
because that amounts to constructing a URI for someone else. It should 
only be selecting among URIs its been given as new targets.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Apr 2008 07:24:03 +0200

Hi,

IF the problem was to provide URI parameters "end-to-end", independent
of re-targets etc, I think that could be solved using the To header.

The ua-loose-route draft says:

"When a SIP call is forwarded (also known as retargeting), the actual
target of the address changes completely,
but the To field does not."

In addition, the draft says:

"When a retargeting operation happens, the URI that needs to be
delivered to the UAS is the SIP address or name
after the most recent retargeting operation."

...and I think that is what Paul is also saying.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: 9. huhtikuuta 2008 7:07
To: Dean Willis
Cc: [email-masked]
Subject: Re: [Sip] Long: Thoughts on "retargeting proposals"

	Paul

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Wed, 9 Apr 2008 12:37:48 +0200

This is also my understanding.

/Hans Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Wednesday, April 09, 2008 6:07 AM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [Sip] Long: Thoughts on "retargeting proposals"

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 09:20:05 -0400

> of re-targets etc, I think that could be solved using the To header.

Of course SBCs are inclined to change To headers also, so even they 
aren't safe. In fact, *nothing* is safe from an SBC.
(They are lurking behind every door and corner, waiting to mess up your 
message under the guise of "fixing" it.)

	Paul

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 9 Apr 2008 08:52:21 -0500

Paul,

I do not think the question is where SBCs are, but rather where they are
not. The reality is a solution needs to address that, either that or the
forum developing a solution is not in touch with reality.

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Wednesday, April 09, 2008 9:20 AM
To: Christer Holmberg
Cc: [email-masked]; Dean Willis
Subject: Re: [Sip] Long: Thoughts on "retargeting proposals"

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 9 Apr 2008 10:42:08 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
>
> Christer Holmberg wrote:
> > Hi,
> >

Yes, what we're actually trying to do is secretly replace your URI's with Folger's crystals, to see if anyone can tell the difference.  Detecting it is pretty easy though - just look for "AYBABTU" in the URI.

-hadriel

---

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Apr 2008 10:34:31 -0500

Call-Info: <http://preview.tinyurl.com/69rzz>

On Apr 9, 2008, at 9:42 AM, Hadriel Kaplan wrote:

> Yes, what we're actually trying to do is secretly replace your URI's  
> with Folger's crystals, to see if anyone can tell the difference.   
> Detecting it is pretty easy though - just look for "AYBABTU" in the  
> URI.
>
> -hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Apr 2008 10:58:46 -0500

Well, SBCs wouldn't replace the To headers if people actually populated them
properly with valid URIs (for phone numbers).

The vast majority of implementations that I've seen do NOT use useful To and
From headers for phone numbers. They don't use real Tel URIs (or Tel URIs embedded
in sip headers).

As a consequence, if somebody didn't fix them, you'd get all sorts of problems.
Including address books and call logs with wrong entries, which have the unfortunate
effect that trying to dial these numbers automatically often doesn't work. 

> Behalf Of Paul Kyzivat
> Sent: Wednesday, April 09, 2008 06:20
> To: Christer Holmberg
> Of course SBCs are inclined to change To headers also, so 
> even they aren't safe. In fact, *nothing* is safe from an SBC.
> (They are lurking behind every door and corner, waiting to 
> mess up your message under the guise of "fixing" it.)
> 
> 	Paul
> 
> > target of the address changes completely, but the To field 
> does not."
> > 
> > delivered to the UAS is the SIP address or name after the 
> most recent 
> > retargeting operation."
> > 
> > that have been given to them, or that they have looked up in some 
> > public registry. URIs are *created* by the recipient.
> > 
> > address is routing, like the domain name in a URI. But the rest is 
> > like the user part of a URI. If you start sticking extra 
> stuff into a 
> > postal address, the post office might get it to the right 
> mailbox, but 
> > its likely to be tossed in the trash, or the extra stuff ignored.
> > 
> > request is retargeted. The parameters are meaningful, if at all, to 
> > the retargeter. It may in fact use them to decide where to 
> retarget. 
> > But by the same logic it shouldn't be attaching them to the 
> retargeted 
> > URI because that amounts to constructing a URI for someone else. It 
> > should only be selecting among URIs its been given as new targets.
> > 
> > 	Paul
> > 
> > Dean Willis wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 12:16:31 -0400

Well, there is no incentive to put in the right thing if it will be 
changed anyway. And I have no confidence that it wouldn't be changed 
even if it was fine.

But I agree with your sentiment. IMO the proper To when "dialing" digits 
is a TEL URI. Unless of course you want a secure call, since there is no 
TELS.

	Paul