Subject: Re: [sipcore] Long reply to: Target URI and History Info bis

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 1 May 2009 17:08:21 +0200

It is not clear what you are disagreeing with. Because I agree that "the
goal is to make the information that was encoded into the requestURI (and
maybe as modified by intermediates, that use case is open) available to the
UAS.".

But this is a little imprecise as it doen't distinguish between the
Request-URI as it was crafted initially by the UAC and those that came about
due to request URI rewrites that happened because of routing and those that
happened due to the communication being redirected/forwarded to another user
then the one originally addressed.

If UA A sends an INVITE to URI of user B, but this call is forwarded on the
way to URI of user C. Then to C the Request URI value that was used by the
forwarding entity (URI of user C) is more relevant URI to decide how it will
render the call to the user then the URI of user B.

/Hans Erik van Elburg

On Fri, May 1, 2009 at 3:30 AM, Dean Willis <[email-masked]>wrote:

> Hans Erik van Elburg wrote:
> >
> >
> > Dean Willis wrote:
> >>
> >> On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote:
> >>
> >>> Overloading in general is not a good design strategy, why do you
> >>> think that trying to mold everything (diversion/history info) into
> >>> Request URI is a good idea??
> >>
> >> The reason that we're having this conversation is that we have
> >> proposals, History-Info being one, for 1) putting our parameters in to
> >> the original request-URI, and 2) recovering that original request-URI
> >> after it has been contact-routed (and otherwise mangled) so that the
> >> parameters can be used at the UAS.
> >>
> >> So the presumption exists that the original request URI is useful to
> >> the UAS. SIP did, and now SIPCORE has, a chartered item for making
> >> that happen.
> >>
> >> I'm trying to back up and make sure that we know WHY we're trying to
> >> deliver the original request URI to the UAS, and then asking if some
> >> other approach that meets the same requirements might actually be
> >> easier to do.
> >>
> > That is fine of course, but the point is that we are not talking about
> > delivering parameters to an application, but about recovering a complete
> > URI that has gone lost on the way.
>
> but why exactly do we need to recover the URI? What is it that is
> special about the URI or is likely to get used in some useful sort of
> way downstream? If it isn't the "Request URI-ness" that is important,
> maybe we can find some more convenient way to deliver that information.
>
>
> >>> The problem here is that this information has nothing to do with
> >>> application invocation, but tells something about how the signalling
> >>> reached the callee (target). And this information is only relevant to
> >>> the callee if that decides that it is.
> >>
> >>
> >> That's a profound philosophical assertion. HTTP, for example, makes no
> >> consideration for "how the signaling reaches the target" in
> >> determining how to process a request. The fact that some think SIP
> >> should take this into consideration indicates to me that we have a
> >> layering problem in our design.
> >>
> > I don't think SIP and HTTP are comparable at all in this respect. In
> > HTTP you directly address the server that you like to get (post, delete,
> > update) information from. In SIP you adress the URI of a user, that will
> > lead you to the home proxy in most cases and which is then forwarded to
> > the UAS by overwriting the Request URI.
>
> Well, HTTP has proxies too, and SIP were originally intended to be
> comparable.
>
> '> No layering problem, just a flaw in SIP's design that causes usefull
> > information to be destroyed for no good reason. We're just trying to fix
> > that, no more no less.
> >> From one perspective, this makes the application invocation implicit;
> >> the UAS has to guess what to do based on clues sprinkled throughout
> >> the communication and across several layers of the ISO stack. It's
> >> much better to have this sort of determination made based on explicit
> >> indicators at a single application layer.
> >>
> > No. The goal of the target-uri discussion is to have all the relevant
> > target-uri information readily available in the SIP request received by
> > the UAS. That is all on the same OSI layer, layer 7.
> >
>
> I disgaree -- the goal is to make the information that was encoded into
> the requestURI (and maybe as modified by intermediates, that use case is
> open) available to the UAS.
>
>
> --
> dean
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 May 2009 12:01:06 -0400

Actually, the redirect case (when not done via an error to the 
originating UAC and retry from there) seems to get at the problem.

The original user specified a URI they were trying to reach, and some 
parameters.
Some of those parameters would still apply after the redirect, but some 
probably don't.
But it appears likely that no one knows which parameters are which.

And the redirector may have some parameter information to add.

And depending upon how everything was understood, and why it was being 
redirected, the destination of the redirect may or may not care about 
the original URI (may even care about the user part of the original URI) 
in full, in order to decide what to do (the voicemail examples.)

All of which leads to ???
 From where I sit, it leads back to H-I since in theory at least with 
History-Info you can reconstruct any of the information you want.  Maybe 
not easily.  But given that we have completely unspecified behaviors 
with regard to parameters and their preservation, and given that even 
the user part from the original request URI may be useful to the target, 
and any parameters that were added in the middle may be useful, ...

If we could be sure that all we wanted was original and final, then 
maybe there would be something we could do, but I am quite sure we can 
make more complicated realistic cases where that will not suffice.

Joel

Hans Erik van Elburg wrote:
> goal is to make the information that was encoded into the requestURI 
> (and maybe as modified by intermediates, that use case is open) 
> available to the UAS.".
> 
> Request-URI as it was crafted initially by the UAC and those that came 
> about due to request URI rewrites that happened because of routing and 
> those that  happened due to the communication being redirected/forwarded 
> to another user then the one originally addressed. 
> 
> If UA A sends an INVITE to URI of user B, but this call is forwarded on 
> the way to URI of user C. Then to C the Request URI value that was used 
> by the forwarding entity (URI of user C) is more relevant URI to decide 
> how it will render the call to the user then the URI of user B.
> 
> /Hans Erik van Elburg
> 
> On Fri, May 1, 2009 at 3:30 AM, Dean Willis <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 May 2009 14:37:19 -0400

Joel M. Halpern wrote:

[snip]

> in full, in order to decide what to do (the voicemail examples.)

I suspect that the voicemail example is a subtext to many of the 
arguments on this subject.

And that troubles me. The arguments I think I hear for and about this are:
- Alice calls Bob
- Bob forwards to Carol
- its forwarded again to Voicemail
- the desire is for it to be Bob's voicemail, not Carol's.
- And so *the* voicemail server needs to figure out whether
   to use Bob's voicemailbox or Carol's.

The trouble with this is that it presumes that Bob and Carol share a 
common VM server, or at least VM servers that collude with one another. 
While this is frequently the case, IMO it is a terrible assumption upon 
which to base a mechanism. For instance, Bob may have been called at 
work, which has its own VM system, and Carol may be Bob's wife with a VM 
system provided by her cellphone SP. In that case, even if Carol's VM 
server is able to discern that the call was intended for Bob, it won't 
have access to Bob's voicemailbox.

Solving this problem is really a matter of arranging when forwarding to 
Carol that the call will fail rather than go to Carol's VM. Then Bob's 
proxy will have the opportunity to forward the call to Bob's VM server. 
And in that case there won't be any complex issues about what mailbox it is.

So, what *other* problems are there where knowing the original R-URI is 
important?

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 1 May 2009 17:40:51 -0500

On May 1, 2009, at 1:37 PM, Paul Kyzivat wrote:

> common VM server, or at least VM servers that collude with one  
> another. While this is frequently the case, IMO it is a terrible  
> assumption upon which to base a mechanism. For instance, Bob may  
> have been called at work, which has its own VM system, and Carol may  
> be Bob's wife with a VM system provided by her cellphone SP. In that  
> case, even if Carol's VM server is able to discern that the call was  
> intended for Bob, it won't have access to Bob's voicemailbox.

That's just broken. The easiest solution is for Carol's node to return  
a "no answer" to Bob's forwarding server, which then needs to route  
the call to Bob's VM.

The question is "How does Carol's node know whether to send a no- 
answer instead of sending the call to Carol's VM?"

The only answer that works for me is that Bob's forwarding server  
needs to tag the request in some way that gives Carol's node this  
information. I suspect that caller-preferences (sip.automata)=FALSE)   
gives us this capability, and that the solution here is proper  
configuration of Bob's forwarding server (and support for caller- 
preferences in Carol's node, which Bob's server can test with Require:).

Others might argue that an extension to Diversion is required that  
would allow detection of this state. I'd argue that this is bogus;  
Carol's node should not have to guess what is wanted based on what has  
already happened (an implicit preference). Instead, it should be told  
explicitly what outcome is desired (an explicit preference).

Another model is to add yet another extension that says "If you can't  
answer, please route this call to this alternate URI". Bob's  
forwarding server would then add this extension, attaching the URI for  
Bob's VM. Carol's node would then dispatch the request appropriately.  
This approach just seems a little fudgy to me, with lots of  
undesirable security properties.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 May 2009 19:25:24 -0400

Yes, I did have in mind that callerprefs can cause the right thing to 
happen if inserted properly and honored. (Big ifs, but alternatives that 
do the right thing are also big ifs.)

I would like to know if people have this case in mind when worrying 
about Diversion/H-I/Target URI issues.

	Thanks,
	Paul

P.S. Dean - you cut off my text that said pretty much what you added.

Dean Willis wrote:
>> assumption upon which to base a mechanism. For instance, Bob may have 
>> been called at work, which has its own VM system, and Carol may be 
>> Bob's wife with a VM system provided by her cellphone SP. In that 
> That's just broken. The easiest solution is for Carol's node to return a 
> "no answer" to Bob's forwarding server, which then needs to route the 
> call to Bob's VM.
> 
> The question is "How does Carol's node know whether to send a no-answer 
> instead of sending the call to Carol's VM?"
> 
> The only answer that works for me is that Bob's forwarding server needs 
> to tag the request in some way that gives Carol's node this information. 
> I suspect that caller-preferences (sip.automata)=FALSE)  gives us this 
> capability, and that the solution here is proper configuration of Bob's 
> forwarding server (and support for caller-preferences in Carol's node, 
> which Bob's server can test with Require:).
> 
> Others might argue that an extension to Diversion is required that would 
> allow detection of this state. I'd argue that this is bogus; Carol's 
> node should not have to guess what is wanted based on what has already 
> happened (an implicit preference). Instead, it should be told explicitly 
> what outcome is desired (an explicit preference).
> 
> answer, please route this call to this alternate URI". Bob's forwarding 
> server would then add this extension, attaching the URI for Bob's VM. 
> Carol's node would then dispatch the request appropriately. This 
> approach just seems a little fudgy to me, with lots of undesirable 
> security properties.
> 
> -- 
> Dean
> 
> 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 3 May 2009 20:00:28 +0200

Hi,

I think the why-is-this-needed questions should have been asked when we
decided to start working on this in the first place. And, again, the
different drafts that have been produced on this topic DO describe
different use-cases.

Regarding the solution, again, we had a long discussion about it, argued
about different alternatives, and finally decided to go for a H-I based
solution.

I am sure there are other ways to do this than using H-I, but everybody
had his/her chance to participate in the beauty contest on which
solution to choose, so at this point I don't think we should revise our
decission - unless it can be shown that the H-I based solution doesn't
work. 

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Friday, May 01, 2009 4:31 AM
To: Hans Erik van Elburg
Cc: SIPCORE
Subject: Re: [sipcore] Long reply to: Target URI and History Info bis

Hans Erik van Elburg wrote:
>> proposals, History-Info being one, for 1) putting our parameters in 
>> to the original request-URI, and 2) recovering that original 
>> request-URI after it has been contact-routed (and otherwise mangled) 
>> so that the parameters can be used at the UAS.
>>

> delivering parameters to an application, but about recovering a 
> complete URI that has gone lost on the way.

>>> reached the callee (target). And this information is only relevant 
>>> to the callee if that decides that it is.
>>
>>
>> That's a profound philosophical assertion. HTTP, for example, makes 
>> no consideration for "how the signaling reaches the target" in 
> update) information from. In SIP you adress the URI of a user, that 
> will lead you to the home proxy in most cases and which is then 
> forwarded to the UAS by overwriting the Request URI.

> information to be destroyed for no good reason. We're just trying to 
> fix that, no more no less.

> target-uri information readily available in the SIP request received 
> by the UAS. That is all on the same OSI layer, layer 7.
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 4 May 2009 00:54:31 -0500

> different drafts that have been produced on this topic DO describe

I asked it then. I  asked them as part of the process that lead to us  
chartering a deliverable of solving the problem. The reason I ask it  
again is that we seem to have forgotten the goal of the exercise, and  
be caught up in a solution without remembering the problem we were  
trying to solve.

SIP work has a history of doing this; it is a large part of why we  
have a fragmented and difficult to manage family of protocol  
specifications.

It bears asking again before we make things even worse.

Do we understand the implications of always delivering  multiple H-I  
items, and do we understand how a UAS can figure out which H-I item or  
items represents the "correct" parameter set?

Because if we do NOT understand these things, then we have failed to  
meet our actual requirements. I'm not saying H-I doesn't meet the  
requirements; I'm asking the WG to 1) understand the requirements, and  
2) verify that our proposed solution REALLY meets them.

Otherwise, we run the risk of producing yet another pointless  
mechanism that does not solve a problem that we failed to understand.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 4 May 2009 12:21:24 +0200

Hi,

4244 in general is kinda messy, and one of the purposes of the proposed
4244bis work is to try to make it more clear.

But, as far as the target delivery work is concerned, in my opinion the
"goal" is clear: to be able to provide the original target to the UAS
(again, the draft explains some cases where it can be useful to be able
to do so).

Regards,

Christer

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 4. toukokuuta 2009 8:55
> To: Christer Holmberg
> Cc: Hans Erik van Elburg; SIPCORE
> > I think the why-is-this-needed questions should have been 
> asked when 
> > we decided to start working on this in the first place. And, again, 
> > the different drafts that have been produced on this topic 
> DO describe 
> > different use-cases.
> 
> I asked it then. I  asked them as part of the process that 
> lead to us chartering a deliverable of solving the problem. 
> The reason I ask it again is that we seem to have forgotten 
> the goal of the exercise, and be caught up in a solution 
> without remembering the problem we were trying to solve.
> 
> SIP work has a history of doing this; it is a large part of 
> why we have a fragmented and difficult to manage family of 
> protocol specifications.
> 
> Do we understand the implications of always delivering  
> multiple H-I items, and do we understand how a UAS can figure 
> out which H-I item or items represents the "correct" parameter set?
> 
> Because if we do NOT understand these things, then we have 
> failed to meet our actual requirements. I'm not saying H-I 
> doesn't meet the requirements; I'm asking the WG to 1) 
> understand the requirements, and

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 May 2009 15:08:26 +0100

Dean,

I tend to agree with the use case that yourself and Paul articulated so
well. Why did I agree to the H-I solution a few months back? Well,
perhaps the use case was not properly articulated at the time, and it
was difficult to see the wood for the trees. I seem to recall some
freephone use case that some people wanted. I was quite happy with the
Rosenberg loose route solution as a means of providing the last target
AoR URI on the last hop, but when JDR stopped pursuing that approach, I
accepted that H-I could do that too. However, when we start talking
about H-I providing reliable information about earlier targets and
expecting special behaviour to take place at the UAS based on this
information (e.g., selecting a different mailbox) I get VERY nervous.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 04 May 2009 06:55
> To: Christer Holmberg
> Cc: SIPCORE
> > we
> lead to us

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 05 May 2009 16:59:20 +0200

The following observation then must be comforting: There are no 
requirements to deliver "earlier targets". The target-uri work only 
requires the current target's uri information to be delivered.

If the consequences of using H-I has some unnerving side-effects, 
well... its a little late to realise that.
I am somewhat puzzled as to what proposal is being brought forward here.

/Hans Erik

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 11:47:58 -0500

> I am somewhat puzzled as to what proposal is being brought forward  

It's not too late. We haven't died yet. We haven't even published an  
RFC, and that's far less final as we often revise RFCs by publishing  
new ones.

--
Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 05 May 2009 22:20:22 +0200

Dean,

Again, considering that the requirements in the target-uri draft is what 
we want to solve, what IS your proposed solution?

BR,
/Hans Erik

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 May 2009 19:01:55 -0500

On May 5, 2009, at 3:20 PM, Hans Erik van Elburg wrote:

> Dean,
>
> Again, considering that the requirements in the target-uri draft is  
> what we want to solve, what IS your proposed solution?
>>

I'm not proposing one at this time. What I AM proposing is that we  
thoroughly analyze the proposal to make sure that it a) meets the  
given requirements (as stated in the draft), and b)  that the given  
requirements address both the chartered milestone requirements as  
written and the requirements as intended when we adopted that milestone.

Let's see if I can formulate what I think the problem with draft- 
rosenberg-sip-target-uri-delivery-01 is:

I'm suspecting that somewhere in the interaction between service- 
invocation and retargeting, we're losing the parameters.

Example A:

Let's say [email-masked] is calling [email-masked]. Alice wishes  
to include some parameters for Bob's UA application that are  
understood by all the user agents at example.org. Bob, however, has  
forwarded his calls to [email-masked].

Alice's parameters go in the original request-URI.

1) Bob's proxy retargets to Carol, pushing the original request-URI  
into History-Info with an istarget parameter, because Identity in the  
reverse direction would now be expected to show Carol.

2) The request reaches Carol's proxy, which adds yet another history  
info (without istarget) containing Carol's contact-uri.

3) The request reaches Carol's phone, which works back the stack to  
retrieve the first "istarget", which now contains Carol's AOR and no  
parameters. It accepts the call, but it has no parameters for the  
application, so the application fails.  Also, since Carol is the  
"target" she thinks the call is for her, not for Bob (although  
ostensibly the To: still shows [email-masked])

One might argue that Carol's UA can backtrack and know that the "first  
target" was Bob, and could potentially retrieve the parameters for  
Bob.  How would it know to do this?

And if it did, consider:

  Example B:

[email-masked] is calling [email-masked]. Alice wishes to include  
some parameters for Bob's UA application that are understood by all  
the user agents at example.org. Bob, however, has forwarded his calls  
to [email-masked], and Bob's proxy is engaging "service invocation  
as per 4.5 of  raft-rosenberg-sip-target-uri-delivery-01. Carol,  
however, has also forwarded her calls to [email-masked]

Alice's parameters go in the original request-URI.

1) Bob's proxy retargets to Carol, pushing the original request-URI  
into History-Info with an istarget parameter, because Identity in the  
reverse direction would now be expected to show Carol. I'm not sure  
whether Bob's proxy pushes the new service-invocation parameters into  
the "original" R-URI or not; I think it likely that it adds a second H- 
I "istarget" that has the modifed parameters.

2) The request reaches Carol's proxy, which adds yet another history  
info (with istarget) containing David's  AOR.

3) The request reaches David's proxy, which contact-routes to David's  
phone and adds  yet another H-I (without istarget) for  
david@davidscontact.

4) The request reaches David's phone, which works back the stack to  
retrieve the first "istarget", which now contains David's AOR and no  
parameters. It accepts the call, but it has no parameters for the  
application, so the application fails.   So which H-I should David's  
UA backtrack to to collect the parameters? It isn't the first one ([email-masked] 
), since Bob's proxy added some parameters. It's not the last one ([email-masked] 
) either. So what does it do?

--
Dean Willis

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 06 May 2009 08:17:09 +0200

Analyzing requirements is always a good thing to do.

Note that the parameters are only part of the problem. The loss of the 
URI is the actual problem, if the URI contains parameters then they are 
lost together with the URI. That is why I do not agree with rephrasing 
this to a URI parameter loss problem. The whole URI is lost. The 
parameters only do carry their intended meaning within the context of 
this URI.

The problem I have with example A & B is that they assume that 
parameters which are intended for B, are also relevant for C or D. This 
requirement is not expressed in the target-uri draft, nor do i think 
that it is a valid requirement.

The service invocation use case explicitly considers: "use of complex 
URIs to address services within the network rather than subscribers. " 
This shows that the scenario that you are testing the solution against 
is not the intended use case.

Note that the solution currently outlined in the target-uri draft is not 
sufficient, as it does not  solve the freephone use case. So yes it 
still needs some work.

Best Regards,
/Hans Erik

Dean Willis wrote:
> Let's see if I can formulate what I think the problem with 
> draft-rosenberg-sip-target-uri-delivery-01 is:
>
> I'm suspecting that somewhere in the interaction between 
> service-invocation and retargeting, we're losing the parameters.
>
> Example A:
>
> the "original" R-URI or not; I think it likely that it adds a second 
> H-I "istarget" that has the modifed parameters.
>
> UA backtrack to to collect the parameters? It isn't the first one 
> ([email-masked]), since Bob's proxy added some parameters. It's not 
> the last one ([email-masked]) either. So what does it do?
>
> -- 
> Dean Willis
>
>