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

[Paul Kyzivat <[e-mail]>]

Michael Hammer (mhammer) wrote:
> Paul,
> 
> Are you saying that a SIP device that does a different feature that uses
> retargetting won't interoperate well with another device (SIP or PSTN)
> that does retargeting feature modeled on the PSTN service?

I'm suggesting that the meaning of the retargetting reasons is rooted in 
the definition of the services that do the retargetting. If such a 
service does the retargetting, then it will know when/if to include the 
corresponding reason. Then some other service, that depends on the 
reasons to do its job, will work correctly.

But, if retargetting is done within an environment that doesn't utilize 
the same feature defintions for retargetting, then in similar 
circumstances the reason may not be present at all, or may have a 
different value. Then, some other service that depends on the tispan 
reasons may not work correctly.

As an example, a voicemail service that depends on these tispan reason 
codes to decide which mailbox to use, may pick the wrong mailbox if 
forwarding was done in a server that doesn't follow the tispan services.

This is intrinsic to any scheme that depends on the definition of 
particular services to characterize what has been done.

This is possibly a reason to prefer reasons that are independent of 
features, or avoiding the use of reasons at all. But I'm inclined to 
believe it is impossible to have feature independent descriptions of 
*why* something happened.

> Or, are you saying that two SIP devices that do retargetting for
> identical features modeled on the PSTN can't work because of some
> deficiency in SIP?

Well, there may be a deficiency now that limits that. But it isn't what 
I was saying.

> In the first case, two different features is a feature interaction
> problem, or interoperability because my new-fangled Call Forwarding Talk
> to the Hand (CFTH) feature reason won't map to CFNA, CFB, or other PSTN
> variants.  So, if a node expects to do something based on receipt of
> this reason doesn't understand it, it will have to have a CF
> Miscellaneous behavior where any unknown reason gets mapped to.

That is one approach.

> In the second case, there may be two devices that understand the same
> feature, but there is a lack of data known to the network that the
> feature relies upon for that feature to work.  That is a protocol issue,
> no?

Yes.

> Ultimately, though I think the disconnect here is that there could be an
> unlimited number of permutations that could exist simultaneously (both
> busy and not answering) and choosing one reason for retargetting is
> problematic for SIP.

There can be many independent reasons, and then also permutations among 
them.

> Some related questions:
> 
> If a series of redirections are done, and that is captured in the
> History-Info header, would the H-I include all these parameters in the
> R-URI?  Seems like a roundabout way of adding something into the H-I
> header.
> 
> Would this retargetting be better positioned in the Via header?  It
> seems like the received URI is the one that the action was taken upon,
> not the outgoing URI.  Just thinking aloud as to who's service is taking
> the action and to which URI that action should be associated.

I think the Via header doesn't work when the retargetting is done via 3xx.

I understand why John suggests doing it this way. In theory, through 
combinations of forwarding, redirection, and recursion, you could end up 
with a 3xx containing multiple contacts, each of which has a different 
reason for having been chosen, and perhaps a different original target 
that it replaced. Putting the parameters in the URI allows that to be 
expressed. (But I have no idea how anything could make sense of that and 
decide on a corresponding "best" course of action as a result.

	Paul

> I need to study the draft more.
> 
> Mike 
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Paul Kyzivat (pkyzivat)
>>Sent: Monday, October 10, 2005 10:27 AM
>>To: Elwell, John
>>Cc: sipping
>>Subject: Re: [Sipping] Re: 
>>draft-elwell-sipping-service-retargeting-00.txt
>>
>>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
>>
> 
> 

_______________________________________________
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