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

[Paul Kyzivat <[e-mail]>]

Michael Hammer (mhammer) wrote:
> Paul, John,
> 
> We like to say that SIP can be feature agnostic, but if we can't do a
> feature that is widely used, then that is a problem.  So, I think the
> real question is not what must be supported, but how it is to be
> supported.
> 
> Although the features in the PSTN are fairly well understood, in many
> cases they are just describing desired behaviors of the call
> (forwarding) based on the state of users at the time the call arrives
> (not registered, no answer, busy).  I don't think those are unique to
> the PSTN as SIP users can be in the same basic states.  It only gets
> complicated when SIP can produce more possible states.  So, I think the
> issue here is not so much defining features as it is reacting to state
> in the SIP network and documenting that state in the signaling.

I think that describes at least part of the problem. The sip network can 
have MANY more states - too many to enumerate. For instance:

- one UA is set to DND and will refuse all calls
- one UA is on a voice call and will refuse all other calls
   until that is over. Then it will accept calls that include
   voice, accepting the voice and refusing other media
- one UA is in an IM session and a voice session. It will
   accept other incoming sessions involving IM. If an offer
   is for IM and voice it will accept the IM and refuse the
   voice. If it is for voice only it will refuse it. When
   the voice call is over the situation will change.

Now, an incoming voice call arrives. It is refused by all the available 
UAs and then is diverted to voicemail. What is the reason for the 
diversion? If you have an answer, then how would the system arrive at 
that answer.

One answer is that you report each of these attempts in H-I as a 
separate retargetting attempt with its own reason for failing.

Its much harder, and I have no answer, if you are trying to come up with 
one reason why you went to voicemail. This is where sip is unavoidably 
more complex.

> It is a backward compatibility issue to be able to interoperate with the
> PSTN.  If we ever expect SIP to become dominant we need to overcome that
> entropy.  I think that is a burden we will just have to bear.  It is
> also a backward compatibility issue to work with various generations of
> SIP devices.  that is another fact of life we have to deal with.

I can accept the need to interop, as long as that also has provision to 
evolve to encompass the new possibilities as well. Any scheme that 
assumes there are a small number of states, and the reason for the 
retargetting was because one of those small number of states prevented 
presenting the call, just isn't going to hack it. For one thing, it sort 
of implies that calls aren't attempted when the state is wrong, rather 
than that they are attempted and fail.

I think there may be more promise to an approach that describes what was 
tried and failed. That is what H-I and the sip reasons do. But maybe not 
with a sufficiently rich vocabulary. Probably no one vocabulary will do, 
but extra Reason namespaces provide a way out of that.

	Paul

> I personally like the idea of keeping the redirection reason tied to the
> redirecting URI added to the History-Info stack, but that doesn't help
> those UACs that don't understand History-Info.  In the end, the perfect
> may be the enemy of the good.  Hopefully, we can converge quickly on an
> answer.
> 
> Mike
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Paul Kyzivat (pkyzivat)
>>Sent: Monday, October 10, 2005 6:07 PM
>>To: Elwell, John
>>Cc: sipping
>>Subject: Re: [Sipping] Re: 
>>draft-elwell-sipping-service-retargeting-00.txt
>>
>>John,
>>
>>Thanks for hearing me out. More inline.
>>
>>	Paul
>>
>>Elwell, John wrote:
>>
>>>Paul,
>>>
>>>In-line,
>>>
>>>John
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Paul Kyzivat [mailto:[e-mail]]
>>>>Sent: 10 October 2005 15:27
>>>>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.)
>>>
>>>[JRE] That would be another approach, but I got the impression from 
>>>some people that they would prefer to see a SIP solution - 
>>
>>something 
>>
>>>that could also be used outside the context of PSTN 
>>
>>interworking - and 
>>
>>>hence the attempt to try to define SIP service reasons.
>>
>>I think in general people something general over something 
>>less general.
>>
>>But we need to determine if the wish is well defined and 
>>achievable within what is considered to be the scope of IETF.
>>
>>In particular the key requirement is to define the *reason* 
>>for retargetting, and if (as I conjecture) the kinds of 
>>reasons being sought can only be expressed in terms of 
>>features, and if ietf doesn't want to define features, then I 
>>don't think this is achievable generically.
>>
>>Possibly there is a compromise position - where certain 
>>reasons are defined that are well defined in terms of basic 
>>sip routing concepts, and other reasons can be defined 
>>independently, as different namespaces, by other groups. And 
>>then reasons from any such namespace can be used. 
>>(Note we already have essentially that with the Reason header.)
>>
>>The problem with this is, of course, that there is plenty of 
>>opportunity to receive reasons that are not understood. This 
>>is not a good state of affairs. But maybe it is the best that 
>>can be achieved.
>>
>>
>>>I guess what this thread needs
>>>to solve is:
>>>1. Is there a problem that needs solving? A number of 
>>
>>people believe 
>>
>>>there is, but not everybody.
>>
>>I for one agree that there is *some* problem, or perhaps 
>>several problems. At the least there are:
>>- getting to the "proper" VM server and mailbox
>>- getting the VM server to take the "proper" action
>>- a PSTN interop problem
>>(I suspect there are others but can't name them right now.)
>>
>>Whether something like H-I and redirection reason is the best 
>>way to solve those problems is a whole different question.
>>
>>I do get the impression that I am in the distinct minority, 
>>and that many people do feel that redirection reason is an ok 
>>way to solve these problems.
>>
>>My feeling is that if it can't address the scenario with two 
>>VM servers then it is a bad solution *for IETF*. If may still 
>>be an acceptable solution for a controlled environment.
>>
>>
>>>2. Should it be solved by a new namespace within SIP or by 
>>
>>referencing 
>>
>>>an existing PSTN-related namespace (e.g., ITU-T recommendation 
>>>Q.732.2, which I believe is what the Telcordia 
>>
>>specification is based on)?
>>
>>I'm trying to keep an open mind here, but I'm not seeing how 
>>we can define a namespace within sip that meaningfully and 
>>adequately defines reasons, but doesn't require a sip 
>>specification of features, and that covers the cases desired 
>>by the proponents so far.
>>
>>So I think we are stuck with either the defining sip reasons 
>>in terms of basic sip routing behavior and error codes, or 
>>referencing namespaces defined elsewhere. In the latter case 
>>there is then the need to define when these codes apply in 
>>terms of a sip implementation, which probably means 
>>specifying part of a sip implementation.
>>
>>
>>>3. The mechanism - that described in the earlier redirection-reason 
>>>(still
>>>current) or that described in the present draft, which was 
>>
>>written to 
>>
>>>get around some criticisms of the redirection reason draft.
>>
>>>I think there is also a body of opinion - I am not sure how large - 
>>>that we need to solve the problem, but the namespace used 
>>
>>(as long as 
>>
>>>it has a repertoire suitable for PSTN mapping as a minimum) and the 
>>>mechanism are secondary.
>>>
>>>
>>>
>>>>This would not however facilitate the interoperation between 
>>>>environments that have differing notions of features.
>>>
>>>JRE] No, perhaps not, but it would at least permit 
>>
>>interoperation in 
>>
>>>some cases where interoperation is less than satisfactory 
>>
>>at present.
>>
>>Sadly, perhaps it is the best that can be hoped for.
>>
>>	Paul
>>
>>
>>
>>>>	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