The CalledParty on the DeliveredEvent always has the DNIS (our toll free or local number). Is there a way of knowing the actual device they dialed from the auto attendant? With our setup we have line appearances on multiple devices so the AlertingDeviceID isn't necessarily the DeviceID the caller hit from the auto attendant.

Hi Brett,

I am finding it difficult to understand your problem description. Can you give a clearer description of what you need? What do you mean by "auto attendant"? When you say "Line appearances", do you mean that you are using Bridged Call ppearances?

Martin

Yes we have bridged call appearances.

For example, extensions 1001, 1002, 1003, 1004 and 1005 might all have line appearances for extension 1000. If someone calls us and hits extension 1000 at the auto attendant when the delivered event fires in DMCC it says the value in getCalledDeviceID is our local or toll free number depending on which they dialed (800xxxxxxx:SWLINK1::0). The getAlertingDeviceId might say 1001 even though the caller actually hit extension 1000 at the auto attendant. Is there any way of knowing the caller dialed extension 1000?

What do you mean by "auto attendant"?

our automated message that answers the call saying if you know your parties extension dial it now, otherwise press 1 for XX, press 2 for XX, etc

Is that a vector or an application or what?

Vectors and VDN's within the CM

I can see the same issue you are having using a vector that simply routes the call to 1000.

Any phone with an appearance of 1000 (which is monitored) will get a Delivered event. Normally this event would have a Called number of 1000 and Alerting number equal to the phones number. In this case, the Called number is taken up with the VDN. Therefore there is nowhere in the event to hold the Bridged number.

The only indication that the call was destined for 1000 is the Event Cause (DeliveredEventEventArgs.getEventCause). For 1000's monitor this has a value of "newCall". For the others, it is "KeyOperation". If you have a single application monitoring all the phones, you may be able to use this to figure out which phone is being called. If you have separate applications running for each phone, this may not be possible.

Martin

Martin,
I did some quick testing and believe this will work. Its giving me a "redirected" event clause for the phone dialed and "keyoperation" on all the others. I do get the "newCall" value on internal calls. Would you be able to provide all the possible event clauses so I can handle them all in our code?

Thanks!

CALLFORWARD: The call has been redirected via one of the following features:
Send All Calls
Cover All Calls
Go to Cover active
DeflectCall
CALLFORWARDIMMEDIATE: The call has been redirected via the Call Forwarding feature.
CALLFORWARDBUSY: The call has been redirected for one of the following reasons:
Cover - principal busy
Cover - all call appearance busy
CALLFORWARDNOANSWER: The call has been redirected because no answer from cover.
KEYOPERATION: Indicates that the event report occurred at a bridged device. This cause has higher precedence than the following two causes. Note this is added for completeness but bridging is not supported.
NEWCALL: The call has not yet been redirected
REDIRECTED: The call has been redirected.