Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Oct 2005 10:24:52 +0100

Paul,

Thanks for your comments. See below.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 07 October 2005 23:41
> To: sipping
> Subject: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
> 
> John,
> 
> I was commenting on the draft, and when I got to the end I was then 
> ready to make an observation. But I think it makes more sense 
> to put the 
> observation first, and then let the specific comments follow. The 
> observation in not solely in response to *this* draft. It is 
> in response 
> to the whole series of things that preceded it as well - Diversion, 
> History-Info, and others whose names escape me.
> 
> 	Paul
> 
> I think we are discussing requirements at the wrong level. I suspect 
> there are in reality only a few reasons why anybody cares about 
> retargetting. (E.g. the message played by a voicemail 
> server.) It would 
> perhaps be more fruitful to discuss those things rather that 
> to assume 
> that the solution for those is to have access to retargetting info.
[JRE] Good point. I have only hinted at this in the Introduction section,
e.g., "When a  request is service retargeted to a voice mail server the
voice mail server is likely to need to know the identity of the original
target in order to access the correct mailbox and the reason for service
retargeting in order to behave appropriately, e.g., play an appropriate
announcement." A next version could have a little more text on this.

> 
> Now more specific comments on this draft:
> 
> >    Retargeting is a normal part of routing a request in SIP. For 
> >    example, an outbound proxy might convert the initial 
> Request-URI from 
> >    a telephone URI (perhaps in the form of a dial string) 
> to a SIP URI. 
> >    As another example, the final proxy typically replaces 
> an Address of 
> >    Record with the URI of a registered contact. 
> 
> I continue to struggle with the distinction between "normal" 
> (uninteresting) retargetting, and the kind of retargetting 
> you find of 
> interest.
> 
> I suspect that what is interesting depends on who is asking, 
> not who is 
> telling. The implication here is that the translation from an 
> AOR to a 
> registered contact is "normal" and uninteresting. But a 
> voicemail server 
> could be registered. In that case is the translation no longer normal?
[JRE] In this case the proxy is translating an AoR into a contact URI
registered against that AoR, and hopefully the UAS will know, when receiving
a request to that contact URI, that has indeed been retargeted from the AoR
concerned.

> 
> >    As a further example, service retargeting information 
> can be of use 
> >    to a voice mail server. When a  request is service 
> retargeted to a 
> >    voice mail server the voice mail server is likely to 
> need to know the 
> >    identity of the original target in order to access the correct 
> >    mailbox and the reason for service retargeting in order 
> to behave 
> >    appropriately, e.g., play an appropriate announcement. 
> 
> The implication that the vm server would have to look at 
> anything other 
> than the R-URI to figure out what mailbox to use is 
> distressing to me. 
> It implies that the entity doing the retargetting wasn't precise in 
> specifying the target. If not, this server might not have 
> access to the 
> right mailbox.
[JRE] Consider the case where an original request to A gets service
retargeted to B for some reason, perhaps still within the context of the
same enterprise. If B is also not available, it needs to retarget to the
enterprise voice mail server. It might be the original destination A that
should determine the particular mailbox, but proxy B does not have the means
to insert this information. It would be good if the voice mail server could
deduce, from history-info within the request, that the original target was A
and the reason for retargeting was (whatever).

> 
> I am somewhat more sympathetic to using huristics applied to known 
> attributes of the call in order to decide how to respond. However, I 
> still think in general it makes better sense for the element 
> doing the 
> retargetting to the VM server to explicitly decide what kind of 
> treatment is required, and inform the VM server of that, rather than 
> having it guess.
> 
> >    - [HIST] reports all retargets, not just service 
> retargets. This puts 
> >    the burden on the UAS or UAC to pick out which retargets are for 
> >    service reasons and which are for normal SIP routing reasons. 
> 
> I agree with this criticism of H-I. But paring down the amount of 
> history info to just what you think is needed doesn't seem 
> better to me, 
> it might even be worse. It assumes that you know what information is 
> important to others, without even knowing who those others 
> are. It also 
> constrains you to information about what has happened, not your 
> inferences about that that implies.
[JRE] The draft does not propose that we suppress some of the history-info.
It merely proposes that we be able to augment it in certain circumstances.

> 
> >    REQ-4. It must be possible to indicate that the reason for 
> >    retargeting is because there are no registered contacts 
> for the URI. 
> 
> None registered? Or none registered that the callee is 
> willing to offer 
> the call to? Or is that a different reason?
[JRE] I think the latter. For example, if caller prefs indicated a
preference for video and there are no video-capable contacts registered, it
would treat it as no registered contacts.

> 
> >    REQ-5. It must be possible to indicate that the reason for 
> >    retargeting is because contacts for the URI are busy. 
> 
> Busy is a difficult concept to nail down. If a user has call waiting, 
> but decides not to pick up a 2nd call because he is too occupied with 
> the first call, is that a Busy, or a No Answer?
[JRE] If is up to the proxy or redirect to determine when it reports busy,
but I agree we could have some more words discussing these cases.

> 
> If there are two contacts to try, and one is Busy, and the 
> other can't 
> support the requested call type, is the reason for 
> retargetting because 
> of Busy?
> 
> In general, multiple of these reasons could hold for a given 
> retargetting.
JRE] In theory, but in practice there is normally one condition that
triggers the retargeting. So if there is only one contact that can accept
the requested call type and that is busy, I imagine the reason for
retargeting would be busy - there is a compatible contact, it is just that
it is busy. It might be possible to give multiple reasons, but I am not
convinced there are compelling reasons to do so.

> 
> >    REQ-6. It must be possible to indicate that the reason for 
> >    retargeting is because the request was not answered during the 
> >    alerting period. 
> 
> Suppose there are several registered contacts, but routing is 
> via serial 
> forking. Then is the second a retargetting because the first contact 
> didn't answer during the alerting period?
> 
> >    The solution here adopts the principles of [SRVCTRL] and defines 
> >    parameter names and values for indicating retargeting 
> details to a 
> >    service or application.  
> 
> I find a significant difference. In RFC3087, when URIs are populated 
> with parameters, the use of those parameters is by 
> prearrangement with 
> the targetted resource - it is expecting the parameters.
[JRE] That wasn't my understanding of RFC3087 - I don't think it is explicit
on this.

> 
> Here, it seems that you are popping parameters on to any old URI, 
> regardless of whether the owner/creator of that URI 
> wanted/expected that 
> to happen or not.
> 
> I foresee this potentially breaking lots of things. While I 
> don't have 
> anything specific in mind, in general it is a bad idea to 
> mess with URIs 
> that don't belong to you.
> 
> >    When a request is service retargeted (for a reason 
> meaningful to a 
> >    retargeted-to user or application), two parameters are 
> added to the 
> >    retargeted-to URI: the old-target parameter contains the 
> previous 
> >    target URI and the retargeting-reason parameter contains 
> the reason 
> >    for service retargeting. Provided this is the last 
> retarget, these 
> >    parameters will reach the UAS and can be provided to the user or 
> >    application. 
> 
> And if the request is redirected multiple times, these 
> parameters keep 
> getting nested deeper and deeper?
> 
> E.g. Alice calls Bob who forwards to Carol who forwards to Ted.
> 
>        sip:[email-masked]; \
>           old-target=sip:[email-masked];user=phone; \
>             old-target=sip:[email-masked];user=phone; \
>               old-target=sip:[email-masked];user=phone; \
>               retargeting-reason=busy; \
>             retargeting-reason=busy; \
>           retargeting-reason=busy
[JRE] No, but each URI that gets added to History-Info would potentially
have its own old-target and retargeting-reason parameters.

> 
> (which has some escaping problems to be dealt with too.)
> 
> 	Paul
> 
> 
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Oct 2005 10:27:05 -0400

Before commenting further, I've had some offline feedback that my 
earlier comments were bonkers or out-of-line in some way. If anybody 
feels that way, feel free to yell at me here. (You won't hurt my feelings.)

In any case, I have been thinking about this further. My most major 
problem with this, and all the similar proposals that have predated it, 
is that I don't find the formulation of the reasons to be well motivated 
or defined. They just seem to be a selection of a few arbitrary reasons 
among many other possibilities. And even then there is insufficient 
definition to allow me to decide, in particular routing cases, which 
reason, if any, applies.

It finally struck me that these reasons can be understood as simply 
being specified by traditional telephony *features*, as defined by 
Telcordia. In that context, everything makes sense - there is a clear 
and precise definition of each reason - the definition of the 
corresponding feature.

If viewed in that light, this exercise becomes somewhat different. IETF 
doesn't define features, so it shouldn't be defining retargetting 
reasons either. It might provide a mechanism to transport reasons, but 
the mechanism would need to reference reasons in an externally defined 
namespace. (Note we already have that with the Reason header.)

This would not however facilitate the interoperation between 
environments that have differing notions of features.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Oct 2005 15:04:03 -0400

John,

I made a general comment earlier. Here are more specific comments.

	Paul

> Thanks for your comments. See below.

[snip]

> a request to that contact URI, that has indeed been retargeted from the AoR

So you assume that if a UA registers a contact then it is to assume any 
time it receives a request addressed to that contact the request was 
originally targetted to the AOR?

That definitely need not be the case. A call to the AOR may lead to that 
contact and establish a dialog. Then the caller may REFER someone else 
to that Contact, in which case the request will not go through the AOR. 
While a little harder, it could find its way into a 3xx as well.

> and the reason for retargeting was (whatever).

This scenario is exactly what I object to.

Suppose B is *not* part of the same enterprise, and has a different VM 
server than does A.

When A forwards to B, there should be some expectation of the intended 
feature interaction with voicemail if B cannot take the call. Either it 
should go to B's VM, or else it should go to A's VM. If the expectation 
is that it should go to A's VM then it ought to do so even when A and B 
have different providers and VM servers. The approach based on H-I 
doesn't work for this.

One way to make this work is to have A, when forwarding, insert a 
callerpref indicating "no voicemail". Then, if B cannot take the call 
live, it will fail rather than going to its VM. This will then give A 
the option to send the call to its VM.

A feature that only works when all the interested parties share the same 
VM server isn't a very good service.

> It merely proposes that we be able to augment it in certain circumstances.

OK. Maybe I misunderstand. I was interpretting what you are proposing as 
something that is in a way a subset of what H-I has, but is lighter 
weight and easier to use when it applies. So while it might not replace 
H-I, it might replace the *use* of H-I in some of these cases.

If it is to be used to make decisions, like the ones VM servers make, 
then they are depending on it having chosen the right information to 
include - the information that is required for the decision they are making.

> would treat it as no registered contacts.

Hmm. In your example, there are registered contacts, but none that the 
caller expressed a preference for. I guess you consider that part of the 
same reason.

But what if the proxy just decided, based on callee policy rather than 
caller prefs, not to offer this request to some of the registered contacts?

I don't really need an answer. My point is that there are different ways 
to define this "reason". The particular definition can affect how it 
should be interpreted and responded to elsewhere. So its not like the 
definition is clear and intuitive.

> convinced there are compelling reasons to do so.

I'm not convinced there are compelling reasons either. Neither am I 
convinced that any one choice of reason will be the right one. I think 
it depends on the observer what is important. Yes, you can prescreen 
based on what you think *should* be important to observers, but you are 
then making a value judgement about what services are important.

If I understand how IMS would do this sort of thing, I think there would 
be an App Server that is responsible for forwarding. It gets the 
request, sets a timer, and then forwards the request on. Then the S-CSCF 
may fork the request to multiple candidate destinations and it may also 
set a timer. Some of those forks may return 486, while others continue 
to ring.

If the S-CSCF timer expires first, it will cancel the remaining 
branches, and then choose to return either 486, or maybe 480. There 
isn't any way for it to indicate that both occurred. The AS then must 
make its forwarding decision based on the response it got, which will 
not reflect that the reason was in fact ambiguous.

If the AP timer goes off first, then it will cancel its outgoing call, 
which will result in all the remaining forks being cancelled. Then it 
will probably return a 487 response. The AP will then forward on the 
assumption that the call went unanswered. It will not be able to reflect 
that there had also been busy responses.

This isn't sounding so well defined and useful to me.

> [JRE] That wasn't my understanding of RFC3087 - I don't think it is explicit

I guess a clarification is needed.

There are some precedents for adding and removing parameters from 
unowned URIs - but they are pretty constrained:

- draft-burger-sipping-netann-11. Here the caller is manipulating agreed 
upon parameters in URIs that are known to target "media servers". This 
is an implied contract around certain URIs.

- RFC 3087. I agree this isn't so clear. It seems to say that the 
"ownder of the system" provisions the URIs, both for the proxy that does 
the forwarding and for the VM server. Apparently neither one is truly 
responsible for the URI, though the VM server obviously answers requests 
addressed to the provisioned addresses.

- GRUU allows this with the grid parameter. But it is contractually 
constrained to cases where the party doing the addition and the party 
that owns the modified URI are in explicit agreement about it.

- GRUU now allows the opaque parameter to be removed to derive an AOR 
from a GRUU. This is pretty loose, in that apparently anyone who finds a 
URI with an opaque parameter may remove it. *Perhaps* this provides 
precedent for other specific parameters defined to be added or removed 
at will. But this itself may need clarification.

This last GRUU case is the strongest endorsement for what you have 
proposed, though it is itself a quite recent proposal. So I'm going to 
keep an open mind about this part of the approach, as long as it is 
clear that this involves specific parameters that are defined to be used 
in this way.

> have its own old-target and retargeting-reason parameters.

If the above isn't what you had in mind, what do you propose would be 
the final R-URI in the above scenario?

	Paul