Call Diversion Override

Mpierce1 at AOL.COM Mpierce1 at AOL.COM
Wed Sep 22 09:14:45 EDT 2004


In a message dated 9/19/2004 2:16:17 PM Eastern Standard Time, 
lilo at nullpointer.de writes:


> Take an ACD system as an example: Someone calls the system, which in 
> turn alerts a group of users.  As soon as one of those users picks up 
> the phone, the other calls that were generated are disconnected 
> automatically. 
> 
> Something as simple as a CFNR to a voicemail system might disrupt 
> operation of this service, as now the voicemail system will pick up the 
> call.
> 
[MAP] I'm confused by your example. This is not what I think of as an "ACD" 
system. I think it goes by a different name. I understand such a service might 
be used for emergency notification, where the desire is to reach the first 
person who will answer.

Anyway, here again, the desire is to prevent an answering machine/voicemail 
system from answering, which I understand. It is not to prevent forwarding. If 
I am one of the intended recipients of such as service, I may activate Call 
Forwarding Unconditional or Busy because I want such calls forwarded to where I 
am or to another phone on my desk. If I know that my number is on such a 
calling list (maybe for emergency notification), then it is my responsibility to 
ensure that calls to it will not be answered by a machine.

------------------------------------------------------------------------------
------------------------------

> By using CDOR, the call distribution system could indicate to the called 
> group of endpoints, that no diversion to a voicemail system would be 
> allowed for this call.  Still, it could indicate, that it wishes 
> diversions to other users to take place.  So, this would not impede any 
> normal operations.
> 
[MAP] If the desire is to prevent answering by a voicemail system, then lets 
work on that specific problem. In general, systems do not know whether they 
are forwarding to another person or to an answering service.

------------------------------------------------------------------------------
---------------------------------------------

> It's clear that a diverting entity doesn't always know if the call is 
> forwarded to another subscriber or to a voicemail system.  Certainly, 
> CDOR wouldn't be too useful in such an environment.  But there are 
> highly integrated telephony systems, where this is known in advance -- 
> and CDOR would provide users with means to utilize this information to 
> their advantage.
> 

[MAP] My argument is that it doesn't work in a system that doesn't know that 
a call is being forwarded to voicemail, and a system that does know this 
probably isn't really doing "Call Forwarding". So it's not a "Diversion Override" 
service. It's a "prevent voicemail" service.

------------------------------------------------------------------------------
---------------------------------------------

> CDOR doesn't state what happens, if a diversion is inhibited.  It's 
> possible to either continue to alert the user or to clear the call.  
> (There's a special message defined for the latter case.)
> 
[MAP] Part of the objection was based on specific operation described in 
Section 9.2.1 which says "the called endpoint ... instead alerts the called 
subscriber" (instead of invoking Call Forwarding or releasing the call). It then 
says the call is cleared by the calling endpoint "due to the callled subscriber 
not responding". I presume this means the calling person hangs up when the 
called person does not answer. That is, the called person who turned on Call 
Forwarding Unconditional still gets rung.

------------------------------------------------------------------------------
-------------------------------------------------

> So, as it was before, the full control still lies with the called 
> endpoint (or the Gatekeeper working on behalf of it), there's just an 
> option for the caller to indicate preference.
> 
[MAP] Then I suggest that the only data to include in the SETUP is things 
like:

Prefer not to be answered by voicemail
Prefer not to be answered by someone else
etc

which would then require that indication of these conditions be added to 
other services in order for this to work. It's just not "diversion override". It's 
not "override" in any sense if the "full control still lies with the called 
endpoint".

(Reminds me of the "Caller Preferences" work in the IETF, which has generally 
led to unending discussions.)


Mike Pierce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20040922/dad7ea43/attachment-0004.html>


More information about the sg16-avd mailing list