Re: [Sip] Comparison of retargeting proposals

["Francois Audet" <audet at nortel.com>]

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.


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com] 
> Sent: Wednesday, April 02, 2008 10:19
> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen
> Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> Subject: RE: [Sip] Comparison of retargeting proposals
> 
> 
> 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:audet at nortel.com]
> Sent: 2. huhtikuuta 2008 19:19
> To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
> Cc: sip at ietf.org; 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).
> 
> 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.
> 
> 
> > -----Original Message-----
> > From: Hans Erik van Elburg [mailto:hanserik.van.elburg at ericsson.com]
> > Sent: Wednesday, April 02, 2008 02:43
> > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg
> > Cc: sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> > Subject: RE: [Sip] Comparison of retargeting proposals
> > 
> > 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:audet at nortel.com]
> > Sent: Tuesday, April 01, 2008 6:18 PM
> > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg
> > Cc: sip at ietf.org; 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.
> > 
> > > -----Original Message-----
> > > From: Hans Erik van Elburg 
> [mailto:hanserik.van.elburg at ericsson.com]
> > > Sent: Tuesday, April 01, 2008 01:07
> > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg
> > > Cc: sip at ietf.org; 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> > Behalf Of
> > > Francois Audet
> > > Sent: Tuesday, April 01, 2008 2:16 AM
> > > To: Juha Heinanen; Christer Holmberg
> > > Cc: sip at ietf.org; 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> > > Behalf Of
> > > > Juha Heinanen
> > > > Sent: Saturday, March 29, 2008 05:48
> > > > To: Christer Holmberg
> > > > Cc: sip at ietf.org; 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 
> > > > sip-implementors at cs.columbia.edu for questions on 
> current sip Use 
> > > > sipping at ietf.org 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 
> > > sip-implementors at cs.columbia.edu for questions on current sip Use 
> > > sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip