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

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

Paul,

In-line,

John

> >>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.
> 
> So you assume that if a UA registers a contact then it is to 
> assume any 
> time it receives a request addressed to that contact the request was 
> originally targetted to the AOR?
> 
> That definitely need not be the case. A call to the AOR may 
> lead to that 
> contact and establish a dialog. Then the caller may REFER 
> someone else 
> to that Contact, in which case the request will not go 
> through the AOR. 
> While a little harder, it could find its way into a 3xx as well.
[JRE] Well, I guess my previous response wasn't too well thought out.
Certainly something like retargeting from a GRUU to a local contact is
unlikely to be of interest, or simply retargeting from an AoR to the first
contact to be tried is unlikely to be of interest, but retargeting to a
voice mail where the first contact tried failed might well be of interest.
It is something that needs to be embedded with the rules for retargeting at
the proxy. If I want requests to my AoR that get retargeted to my voice mail
under certain circumstances (e.g., any other suitable contacts are busy) to
be flagged as service retargeting with a reason, then I build this into my
rules or script at the proxy.

> 
> >>>   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).
> 
> This scenario is exactly what I object to.
> 
> Suppose B is *not* part of the same enterprise, and has a 
> different VM 
> server than does A.
> 
> When A forwards to B, there should be some expectation of the 
> intended 
> feature interaction with voicemail if B cannot take the call. 
> Either it 
> should go to B's VM, or else it should go to A's VM. If the 
> expectation 
> is that it should go to A's VM then it ought to do so even 
> when A and B 
> have different providers and VM servers. The approach based on H-I 
> doesn't work for this.
JRE] But I think this will be quite a common case. Once a request gets to
the original target domain, in many cases any retargets from there are going
to stay within that domain and it is the first target in that domain that is
most likely of interest to the voicemail server.

> 
> One way to make this work is to have A, when forwarding, insert a 
> callerpref indicating "no voicemail". Then, if B cannot take the call 
> live, it will fail rather than going to its VM. This will then give A 
> the option to send the call to its VM.
> 
> A feature that only works when all the interested parties 
> share the same 
> VM server isn't a very good service.
[JRE] That would be a useful thing to do. I had not picked up on the fact
that RFC 3841 allows a proxy to add preferences. However, I don't see how
this would work if a redirect server is used rather than a proxy.

> 
> >>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.
> 
> OK. Maybe I misunderstand. I was interpretting what you are 
> proposing as 
> something that is in a way a subset of what H-I has, but is lighter 
> weight and easier to use when it applies. So while it might 
> not replace 
> H-I, it might replace the *use* of H-I in some of these cases.
> 
> If it is to be used to make decisions, like the ones VM servers make, 
> then they are depending on it having chosen the right information to 
> include - the information that is required for the decision 
> they are making.
[JRE] Yes.

> 
> >>>   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.
> 
> Hmm. In your example, there are registered contacts, but none 
> that the 
> caller expressed a preference for. I guess you consider that 
> part of the 
> same reason.
> 
> But what if the proxy just decided, based on callee policy 
> rather than 
> caller prefs, not to offer this request to some of the 
> registered contacts?
> 
> I don't really need an answer. My point is that there are 
> different ways 
> to define this "reason". The particular definition can affect how it 
> should be interpreted and responded to elsewhere. So its not like the 
> definition is clear and intuitive.
> 
> >>>   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.
> 
> I'm not convinced there are compelling reasons either. Neither am I 
> convinced that any one choice of reason will be the right 
> one. I think 
> it depends on the observer what is important. Yes, you can prescreen 
> based on what you think *should* be important to observers, 
> but you are 
> then making a value judgement about what services are important.
> 
> If I understand how IMS would do this sort of thing, I think 
> there would 
> be an App Server that is responsible for forwarding. It gets the 
> request, sets a timer, and then forwards the request on. Then 
> the S-CSCF 
> may fork the request to multiple candidate destinations and 
> it may also 
> set a timer. Some of those forks may return 486, while others 
> continue 
> to ring.
> 
> If the S-CSCF timer expires first, it will cancel the remaining 
> branches, and then choose to return either 486, or maybe 480. There 
> isn't any way for it to indicate that both occurred. The AS then must 
> make its forwarding decision based on the response it got, which will 
> not reflect that the reason was in fact ambiguous.
> 
> If the AP timer goes off first, then it will cancel its 
> outgoing call, 
> which will result in all the remaining forks being cancelled. Then it 
> will probably return a 487 response. The AP will then forward on the 
> assumption that the call went unanswered. It will not be able 
> to reflect 
> that there had also been busy responses.
> 
> This isn't sounding so well defined and useful to me.
[JRE] Nevertheless I believe the TISPAN people have a requirement for some
form of redirection reason, so perhaps a TISPAN expert can explain.

> 
> >>>   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.
> 
> I guess a clarification is needed.
> 
> There are some precedents for adding and removing parameters from 
> unowned URIs - but they are pretty constrained:
> 
> - draft-burger-sipping-netann-11. Here the caller is 
> manipulating agreed 
> upon parameters in URIs that are known to target "media 
> servers". This 
> is an implied contract around certain URIs.
> 
> - RFC 3087. I agree this isn't so clear. It seems to say that the 
> "ownder of the system" provisions the URIs, both for the 
> proxy that does 
> the forwarding and for the VM server. Apparently neither one is truly 
> responsible for the URI, though the VM server obviously 
> answers requests 
> addressed to the provisioned addresses.
> 
> - GRUU allows this with the grid parameter. But it is contractually 
> constrained to cases where the party doing the addition and the party 
> that owns the modified URI are in explicit agreement about it.
> 
> - GRUU now allows the opaque parameter to be removed to derive an AOR 
> from a GRUU. This is pretty loose, in that apparently anyone 
> who finds a 
> URI with an opaque parameter may remove it. *Perhaps* this provides 
> precedent for other specific parameters defined to be added 
> or removed 
> at will. But this itself may need clarification.
> 
> This last GRUU case is the strongest endorsement for what you have 
> proposed, though it is itself a quite recent proposal. So I'm 
> going to 
> keep an open mind about this part of the approach, as long as it is 
> clear that this involves specific parameters that are defined 
> to be used 
> in this way.
> 
> >>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.
> 
> If the above isn't what you had in mind, what do you propose would be 
> the final R-URI in the above scenario?
[JRE] The final R-URI would be:
    sip:[e-mail]; oldtarget=[e-mail]
and there would also be a History-Info header field of the form:
    History-Info: <sip: [e-mail]?Reason=SIP...;text="....">;
index=1,\
 
<sip:[e-mail];old-target=[e-mail];retarget-reason=xxx?\
        Reason=SIP...; text="....">; index=2,\
 
<sip:[e-mail];old-target=[e-mail];retarget-reason=xxx?\
        Reason=SIP...; text="....">index=3
This assumes each retarget (Bob to Carol, Carol to Ted) is deemed to be a
service retarget.

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