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)