Danilo and Mike -
If we agree that the use of Call Diversion Override is to maximize the
chance that the call is answered by the intended party, then we should
look at the situations in which this might (or might not) be the case.
I think this means we need to look at each vendor's system individually.
In other words, the vendor must implement the feature in the way that
makes sense for that vendor. For example, in our (Avaya's) switches,
we have two basic forms of call redirection:
Call Forwarding - this is usually means "I'm not here, try to reach
me at this other number."
Call Coverage - this usually means "I'm not here, this other persom
will take my calls in that case."
Unfortunately, this isn't always the case: Call Forward Busy/Don't Answer
is more like call coverage (and was used as such before the coverage
feature was implemented.) Call-Forward All is clearly in the first camp.
Now, for our switches, it would make sense, I'd think, for us to implement
CDOR in such a way that it overrode call coverage, but followed call
forwarding. That gives the user some flexibility to "inform" the system
about how CDOR should behave.
If, on the other hand, the vendor's switch has only Call Forward-All and
Call Forward-Busy/Don't-Answer, then the separation might be made between
the two: the former can be used to say "I'm over at this other number now",
while the latter is more like "if I'm not here, or I'm busy, send the call
to somebody/something else."
If, on the other hand, the idea of CDOR is to send the call to a "known"
location (e.g., to warn everyone in a particular building - a reverse 911),
then it would override every redirection feature. Maybe we need some
parameter to clarify the particular intent.
In any case, I think it is up to the vendor and the customer to decide
how the CDOR feature should interact with the vendor's features, based
on the customer's needs.
-Bob
----------------------------------------------------
Bob Gilman rrg(a)avaya.com +1 303 538 3868
Danilo Kempf wrote:
> Mike,
>
> thanks a lot (again!) for your comments. Please excuse that it took me
> so long to respond, I unexpectedly had to travel a little.
>
>
>>>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.
>
>
> Well, if the term "ACD" system applies here, it's certainly not a really
> sophisticated one. What I described should merely serve as a
> simplified example, but I know of several similar (somewhat more
> complicated, though) systems used in practice.
>
>
>>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.
>
>
> Certainly, in this case we'd like to prevent the call from going to a
> voicemail system. In my book however, I think that's what "Call
> Forwarding" really is: When I, as the intended recipient of the call,
> fail to pick up my phone in time, the call somehow is "diverted" or
> "forwarded" to my voicemail. This may happen by just about any
> mechanism -- be it H.450.3 or a routing GK playing tricks -- I still
> think we could call that "Call Forwarding".
>
> I think it's understandable that a calling party may want to (indicate
> preference to) impede this.
>
>
>>>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.
>
>
>>[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.
>
>
> You are right, it wouldn't work in cases where it's not known that the
> destination is a voicemail system. CDOR (in this case) is clearly
> intended as somewhat of a "niche"-service, but I think that'd be ok, as
> implementing a H.460.x-service isn't mandatory either.
>
> In practice, I don't really think there are too many systems not knowing
> that the destination is a voicemail.
>
> In general, CDOR wasn't only intended as a "prevent voicemail" service
> and we had/have some more applications in mind. There are some more
> legitimate reasons of preventing a call forwarding: (Now, this is the
> point where my English skills start to leave me, so I hope you'll
> understand what I'm trying to say.)
>
> The examples we had until now only addressed the cases where an
> endpoint/a phone was bound to a certain person. The assumption was,
> that when I'm dialling your number I'm trying to reach you as a person.
> The call diversions you've set up might certainly be helpful in this
> case. (Except, of course, for the CFNR/CFB to your voicemail...)
>
> This assumption, however, doesn't always hold true. Take an alarming
> system as an example. If this system is triggered, it might
> systematically call all endpoints in a building and play back an
> announcement. This system certainly wouldn't bother with following a
> call diversion to my cellphone.
>
> This, which might be considered an emergency service, plays a little bit
> into the MLPP-domain. I think it even goes as far as being able to
> supplement your specification in that point, as it might alter the
> behaviour of MLPP vs. CFU/CFB behaviour specified in H.460.14.
>
> Finally, CDOR might be used to inhibit a call forwarding to external
> (and thus possibly costly) numbers. This, of course, isn't specified
> in our document, as in general it's not known, whether a number is
> external or not. In the future, however, I think such an extension
> might be desirable.
>
>
>>>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.
>
>
> You are right with that interpretation, but I think you've missed
> something here: The called endpoint would have had the opportunity to
> release the call. The calling endpoint indicates preference to inhibit
> the call diversion. After matching that request with it's internal
> policy, the called endpoint decides, that the diversion shouldn't be
> invoked. It now has the opportunity to either continue to alert the
> called person or to clear the call. For the latter case, there's even
> a special notification message defined with CDOR.
>
> The bad part here is, that this wasn't really clear from the example.
> If nothing else, at least the example should be updated.
>
> From the meeting report it was clear, that in our draft there was too
> much control with the calling endpoint. In my previous e-mail I
> pointed out, that this will be changed to give the "final say" back to
> the called endpoint. I think, with these changes incorporated into the
> document this example should be a bit clearer.
>
>
>>>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".
>
>
> I'm not sure I understand you here. What else if not "prefer not to be
> answered by ..." is included in the SETUP with CDOR? Are we arguing
> whether it's an actual "call forwarding" or just "something similar to,
> but not quite, call forwarding"?
>
> What we want to achieve is giving the caller some preference over where
> the call finally terminates -- without removing any control from the
> called endpoint or any entity in between. I think, CDOR would be a
> right way to go here.
>
> Regarding the "voicemail" topic: Perhaps there really should be a
> simple service for a voicemail-system to identify itself during call
> set up. The calling party then could still decide to clear the call.
>
> The voicemail-system, in turn, could have taken a look at the
> CDORRequest message transmitted by the calling party. If this
> indicated that the calling party didn't wish to be forwarded to a
> voicemail system AND the call was diverted before, the call could be
> "proactively" cleared by the voicemail. This would basically achieve
> the same effect as described above, without any diverting entity
> knowing that it actually diverts to a voicemail systems.
>
>
>>(Reminds me of the "Caller Preferences" work in the IETF, which has
>>generally led to unending discussions.)
>
>
> I really do not want to stir up an endless discussion. If you don't
> think, a CDOR service is worth having or our CDOR document isn't
> well-received in general, there's always the option of withdrawing it.
>
> I just wanted to point out, why I still think it's a rather good idea.
> (But, of course, I don't have a really impartial opinion on that topic
> either...)
>
> Again, thank you very much for your comments.
>
> Best regards,
>
> Danilo Kempf
> (TE-SYSTEMS GmbH)
>
