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

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

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 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.
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)?
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.

> 
> 	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