Call Diversion Override

Danilo Kempf lilo at
Tue Sep 28 14:48:43 EDT 2004


thank you very much for your comments.  I think you're right pointing 
out that allowing or disallowing CDOR taking place for certain kinds of 
redirections (such as CFU) is a question of configuration/policy.

> 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.

That's a good idea, but I'm not too sure whether adding such an "intent" 
parameter would do the trick here.  With CDOR you have the possibility 
to specify "don't follow any redirection at all".  To stay with your 
example, your switch in this case would inhibit any re-routing due to 
the "Call Coverage" feature but still invoke any re-routings due to the 
"Call Forward" feature.

To alter this behaviour (in order to even inhibit the "Call Forward" 
re-routings), we certainly could add such an "intent" field.  I think, 
however, that combining CDOR with other services, such as H.460.14 
(MLPP), H.460.4 (Call Priority) or even H.450.11 (Call Intrusion) might 
be more useful here.  This would keep our CDOR document small and 
wouldn't duplicate any behaviour.

On the other hand, let's assume a calling endpoint invokes both "Call 
Priority Designation" (setting a high priority) and CDOR at the same 
time.  What should be the outcome?  When a call rerouting is attempted, 
we'd still have to decide whether it's okay to divert or not.  The 
elevated priority perhaps wouldn't be too helpful in making a decision.

So perhaps adding an intent-parameter ("call the person" or "call the 
endpoint") might be helpful anyway -- but still, this is already 
indicated by sending the request for "no re-routings at all".

I'm a bit undecided here and need to do some more reading regarding this 
issue.  If you have any ideas here, they are certainly welcome!

With best regards,

Danilo Kempf

More information about the sg16-avd mailing list