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

[Paul Kyzivat <[e-mail]>]

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.

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?

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

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.

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

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

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.

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

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

(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