Dear Experts,
reading the report of the meeting in San Jose, it has come to my
attention that some concerns were raised regarding our draft H.460.cdor
"Call Diversion Override" document.
I think that all of those concerns are warranted and I'd like to take
the time to address them here. Excerpts from the meeting report are
quoted.
> This specification is intended to work around unconditional call
> forwarding, for instance. But, why should a calling device be able
> to work around unconditional call forward?
[ ... ]
> Why does the endpoint not
> contain the policy for what calls get forwarded and which do not?
> People felt like there was a real danger in simply allowing any
> calling endpoint to override call diversion.
There seems to be some confusion whether there's an actual justification
for having a service for overriding call forwarding.
First, this is not meant as some sort of "poor man's MLPP" or similar.
It's not an emergency service per se, it's only a mechanism for an
endpoint to indicate that it doesn't wish a call to be subject of
any/some call diversions.
Being able to indicate this might actually be useful for the user to
inhibit being connected to a voice-mail system after a CFB has taken
place. It might also be useful for an Operator and of course it might
be helpful with emergency services.
Primarily, however, this service is intended to be an aid for automated
systems, such as call-distribution systems, voicemail- and alarming
systems -- in short any automated system that does a "call back" to an
actual user.
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.
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.
There are a lot of other examples, where CDOR could be useful. If you
feel that you need more justification for such a service, I'd be happy
to provide some more.
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.
Please note, that we intended to define a mechanism for overriding call
forwarding and that there's no policy in there. Personally, I can't
see a good reason for overriding CFU as well, but we certainly should
provide users with the means to do so, if they desire (and the called
endpoints policy agrees).
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.)
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.
> There was some concern that this feature would open the door to
> "spamming".
Making spamming easier certainly wasn't the intent of the document.
While I'm sure one may conceivably come up with with a scenario where
CDOR may indeed be used in such a way, I don't think that this is in
any way specific to CDOR only.
I firmly believe that almost all services may be used in such a way, as
long as there is neither authentication nor authorization taking place.
Thus, the same concern might apply also to already established
services, such as "Call Intrusion" or "Call Priority Designation".
There are established mechanisms for both authentication and
authorization in H.323, so these would apply to CDOR as well.
> There should be an option in these procedures to allow the called
> device to reject the diversion override service. So, the calling
> device must have permission from the called device before invoking
> this service.
I agree. Maybe too much emphasis was laid on "overriding" diversions in
the document. Currently there'd be no way for a called endpoint to
reject the service.
I think, a proper fix for this would be swapping the capability and
protection levels. Currently, there are 4 protection levels and only 3
capability levels, allowing the calling endpoint to "always override".
If this would be exchanged, it would allow the called endpoint to
"always divert".
I will change this in the document.
> In 7.4, it was noted that behavior in H.460.1 was changed. Perhaps
> this should be "should" rather than "shall". What is the exact
> wording in H.460.1 that conflicts with this?
I assume, that this point applies to the following clause from our draft
document:
> Intermediate entities shall, in contrast to the procedures specified
> by the base H.460.1 specification, not remove the CDORRequest message
> from the GenericData element of the Setup message before passing it on
> to the next intermediate entity or the called endpoint, as this would
> effectively disable the CDOR Service.
In fact, I think there's some bad wording in our document. No part of
H.460.1 is changed here. This paragraph was just addressing the GEF
section of H.323, where it's declared that intermediate entities may
remove parts of the GenericData element and not pass it through to the
destination endpoint, if the intermediate entity can/will handle the
described feature by itself.
Removing a CDORRequest could be counter-productive, as the destination
endpoint wouldn't even know that the CDOR service was to be invoked, so
this sentence merely was meant as an "encouragement" to not remove the
message from the GenericData element.
I agree, that it should say "should not ... if policy allows" or
similar. I'll update the document accordingly.
> However, we should describe how this interacts with other things, such
> as MLPP (H.460.14).
My stance on this is, that there's no interaction with MLPP and MLPP
takes precedence, as it's clearly an emergency service.
I will add this to the document.
I hope that I could address all of your concerns here. I'm very much
interested in comments our further discussion.
And, of course, I still hope, that you might find the CDOR service
useful.
With best regards,
Danilo Kempf
(TE-SYSTEMS GmbH)
