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

["Dolly, Martin C, ALABS" <[e-mail]>]

Hello,

The use of the URI parameter allows for backward compatiblity with existing devices/UAs. They will take what is in the contact header of the 3xx message and just use it the the R-URI of the outgoing INVITE.

I see compliant devices/UAs using both the URI parameter and History-Info moving forward.

I agree that either the Reason header or URI parameter could work, but prefer the URI parameter because of the backward compatibility with existing devices.

Cheers,

Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Elwell, John
> Sent: Tuesday, October 11, 2005 7:54 AM
> To: GARCIN Sebastien RD-CORE-ISS; Paul Kyzivat
> Cc: sipping
> Subject: RE: [Sipping] Re:
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 
> 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
> 

_______________________________________________
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