Directory structure of avc-site

OKUBO Sakae okubo at MXZ.MESH.NE.JP
Mon Sep 20 07:42:39 EDT 2004


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)



More information about the sg16-avd mailing list