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

["Elwell, John" <[e-mail]>]

Sebastien,

Personally I don't have a problem with using the Q.732.2 namespace. Whether
this is for the Reason header or a URI parameter should be determined based
on discussion of which is the preferred mechanism. The authors of the
service-retargeting draft had reasons for preferring the mechanism in that
draft (see section 13.1). Of these reasons, in my opinion the first is the
most important.

John
 

> -----Original Message-----
> From: GARCIN Sebastien RD-CORE-ISS 
> [mailto:[e-mail]] 
> Sent: 11 October 2005 12:22
> To: Paul Kyzivat; Elwell, John
> Cc: sipping
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> Hi Paul, John,
> 
> It seems from the discussion below that a possible agreable 
> way forwards is to define a new ITU-T Q.732.2 namespace for 
> the Reason header. I think it quite reasonable to do so.
> 
> Has anybody got any problem with that approach ?
> 
> Regards
> sebastien
> 
>  
> 
> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de Paul Kyzivat
> Envoyé : mardi 11 octobre 2005 00:07
> À : Elwell, John
> Cc : sipping
> Objet : 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