Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jan 2010 09:52:23 -0500

Shida Schubert wrote:
>  If the focus is about which target (AoR) is to be considered for 
> any special call handling such as voicemail (use of RFC4458?)
> , so when call is forwarded the receiving end knows there is a 
> preferred identity which is to be honored, then we may have 
> some work to do with History-Info but otherwise I don't think 
> there is much more to do beside elaborating the voicemail section.  
> 
>  Any thoughts? 

I don't understand how RFC4458 applies here.
That applies in the case where you have some node (perhaps a proxy) that 
*knows* it wants to send a call to VM, and *knows* which mailbox it 
wants to target. In that case the only goal is to find a way to encode 
that info into an AOR.

AFAIK, the question under discussion here is different. We are passing 
the call through a number of different intermediaries. More than one of 
them may have a policy of sending the call to VM under certain 
circumstances. The goal here is to harmonize the policies such that the 
call gets to the *right* VM server and mailbox.

In fact, the situation is more general than that, since the desired 
policy may not involve sending the call to VM at all.

The solutions that involve H-I all assume various things about the 
nature of the policies that might be in place along the path. E.g.:

- a node that just sends an unanswered call to its own VM server and
   VM-mailbox is assuming that the policy of prior nodes on the path is
   irrelevant, or that the desired policy of prior nodes is for later
   ones to prefer their own VM.

- a node that sends an unanswered call to its own VM server, with the
   selection of VM-mailbox based on the first AOR in H-I is assuming:
   that the first AOR shares a VM server with it; that the mapping from
   AOR to VM-mailbox is consistent with its own; and that the caller
   and/or server for that first AOR intended an unanswered call to go
   to its VM-mailbox.

IMO these are unreasonable assumptions.

	Thanks,
	Paul

>  Regards
>   Shida
> 
> On Dec 7, 2009, at 2:52 AM, Paul Kyzivat wrote:
> 
>> The main tactic I know of that is currently deployed to address this need is to cancel the forwarded call after a few "rings", hopefully before it is transferred to voicemail there. But of course that doesn't work if you guess wrong about the number of rings, and especially if the call goes direct to voicemail.
>>
>> While there is no way, once I have forwarded a call to you, for me to *prevent* you from handling the call as voicemail, it is typically in the best interests of both of us. Specifically, if I am forwarding the call to you, but asked you *not* to send the call to your voicemail, then honoring that saves you the trouble handling the voicemail, and also keeps you in my good graces.
>>
>> So the key here is to communicate preferences for how the call should be handed, and define the recommended handling of calls in the presence of such a recommendation.
>>
>> The basics to do this have been in callerprefs for a long time. But I don't think they have been considered seriously in this context. I'm not *certain* that is sufficient to address the problem, but it seems like the right starting point.
>>
>> Note that this sort of approach *does not* require looking back in the History-Info to decide which voice mailbox to use.
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> Gonzalo Camarillo wrote:
>>> Hi,
>>>> When you think about it, it makes sense.
>>>>
>>>> If you call me, you would expect to get my voicemail, not somebody else's.
>>> yes, Paul's example has been discussed *many* times. So, addressing it in some way would be a good thing.
>>> Cheers,
>>> Gonzalo
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
>