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

[Paul Kyzivat <[e-mail]>]

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

Elwell, John wrote:
> Paul,
> 
> Thanks for your comments. See below.
> 
> John
>  
> 
> 
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:[e-mail]] 
>>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:[e-mail]; \
>>          old-target=sip:[e-mail];user=phone; \
>>            old-target=sip:[e-mail];user=phone; \
>>              old-target=sip:[e-mail];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 [e-mail] for questions on current sip
>>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP