I am noticing some very strange behaviour with Avaya AES 5.2.1 and I am looking for someone to explain what might be happening.

If I listen to third party OnDeliveredEvents, the CallingDeviceId will usually contain valid device IDs. example: 4305:CM::0

Occasionally though, the CallingDeviceId will show up as something like: T11046#1:CM::0, where 11046 == the incrementing connection callID (ConnectionId.CallId).

What would cause this to happen? Is this a placeholder if no device ID exists?

Any ideas?

Specifically a call abandoned while queued in a group.

Right now I am detecting abandoned calls by checking if a call ever hits an Established (talking) state before the connection clears.

If a call does not have an answering device, I assume that the call is abandoned and flag it as such.

Is that the correct way to determine Abandoned calls?

Yeah that was the issue. This works great now.

Thanks Martin.

Hey guys. I opened a support ticket for this one.

Cheers all.

I am attempting to start a call monitor on a VDN using DMCC but am unable to. The AES server is returning <CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><operation>invalidDeviceID</operation></CSTAErrorCode>.

What I've tried
--------------------
I opened the SAT console and ran `list vdn`.
I wrote down all of the VDNs on the CM.
I requested and recieved a third party device ID (e.g. 7300005:cmsim::0) for each of the listed VDNs.
I attempted to start a call monitor using the device IDs on each VDN.
The OnStartMonitorResponse args.getError object contains <?xml version="1.0" encoding="UTF-8"?><CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><operation>invalidDeviceID</operation></CSTAErrorCode>.

Additional Info
--------------------
I can start monitors on stations and groups (acdSplit) with no issues. All events are properly firing for these devices.
I am using the cmsim system in BDE to test this, if it makes a difference.

Trace log:
--------------------
2013-07-31 02.28.25,717 com.avaya.cs.callcontrol.CallControlSnapshotImpl removeCallControlListener
INFO: CCS Remove Listener: listener not found for device: 7300005:cmsim::0 Possibly received CSTAMonitorEndedEvent or device wasunregistered on the switch. Monitor Stop request will not be sent.
2013-07-31 02.28.25,717 com.avaya.cmapi.monitor.MonitoringServicesImpl stopMonitor
FINE: removing CallControlListener: crossRef=762:[Holder]: [7300005:cmsim::0] ,com.avaya.cmapi.monitor.CallControlServicesListenerImpl@7c37de,session 8490529FE9A99EA43FCF72193BA82718-42
2013-07-31 02.28.25,717 com.avaya.cmapi.monitor.MonitoringServicesImpl cleanupSessionListener
FINE: removed sessionListener for crossRef=762
2013-07-31 02.28.25,717 com.avaya.cmapi.monitor.MonitoringServicesImpl releaseCrossRefId
FINE: released crossRefID=762: 48 are now in use, 79952 still available.
2013-07-31 02.28.25,717 com.avaya.cmapi.monitor.MonitoringServicesImpl stopMonitor
FINE: removed monitor=762
2013-07-31 02.28.25,717 com.avaya.async.impl.AsyncCallbackImpl handleException
WARNING: A service method threw an Exception when invoked!
ServiceMethod: com.avaya.platform.broker.impl.AsyncServiceMethodImpl@1cfb8d3[com.avaya.cmapi.monitor.MonitoringServicesImpl@1e4905a, public synchronized void com.avaya.cmapi.monitor.MonitoringServicesImpl.startMonitor(ch.ecma.csta.binding.MonitorStart,com.avaya.api.async.AsynchronousCallback) throws ch.ecma.csta.errors.InvalidParameterValueException,ch.ecma.csta.errors.InvalidMonitorObjectException,ch.ecma.csta.errors.OverallMonitorLimitExceededException,ch.ecma.csta.errors.OperationException,ch.ecma.csta.errors.InvalidConnectionIDForActiveCallException]
Exception: ch.ecma.csta.errors.InvalidDeviceIDException: The specified device ID was invalid: error code 12
Request: session[session 8490529FE9A99EA43FCF72193BA82718-42] ch.ecma.csta.binding.MonitorStart@4b8e8e
ch.ecma.csta.errors.InvalidDeviceIDException: The specified device ID was invalid: error code 12
at com.avaya.cs.callcontrol.handlers.CallControlConfHandler.getCstaException(CallControlConfHandler.java:191)
at com.avaya.cs.callcontrol.handlers.MonitorDeviceConfHandler.getCstaException(MonitorDeviceConfHandler.java:182)
at com.avaya.cs.callcontrol.handlers.CallControlConfHandler.handleConf(CallControlConfHandler.java:133)
at com.avaya.jtapi.tsapi.tsapiInterface.TSInvokeID.setConf(TSInvokeID.java:54)
at com.avaya.jtapi.tsapi.tsapiInterface.TsapiEventDistributor.handleEvent(TsapiEventDistributor.java:103)
at com.avaya.jtapi.tsapi.tsapiInterface.TsapiEventQueue.run(TsapiEventQueue.java:104)
2013-07-31 02.28.25,717 com.avaya.mvcs.proxy.CstaMarshallerNode$CstaMarshallerThread convertThrowable
FINE: Returning negative ack to client session (8490529FE9A99EA43FCF72193BA82718-42) : ch.ecma.csta.errors.InvalidDeviceIDException: The specified device ID was invalid: error code 12

--------------------
Thanks for the continued assistance all!

Some History:
----------------
We are attempting to recover from the scenario where an Avaya CM that is connected to the AES server we have a session on goes down abruptly.

We've discovered that in the event of a CM reboot, the AES server will recover it's connection to the CM.

In the trace logs we are able to see when this re-connection actually takes place. We also noticed that when this reboot happens, the AES server will actually release all of it's device monitors. I assume this is intended behavior due to the fact that the phone system is re-initializing all of it's devices on boot.

I am pretty sure the session we've established to AES though DMCC though stays up though.

Question:
----------------
Does DMCC provide any standard way of determining the status of the link between the AES server and the phone system it's connected to and communicating with?

We've got all kinds of creative ideas on how to deal with this situation, but having something like OnConnectionDownEvent for the CM would be even better.

Thanks all!

I have a monitor set up on the hunt group that agents are logging into. I am able to run GetAgentState() and get a response detailing the agent state.

I can't figure out how to find the agent ID though.

Is there a way to simply query the agent ID from DMCC?

Maybe a better way to phrase it would be "tell the difference between hunt groups designated as queues and those that are not".

I've been pouring over the docs and I can'd seem to find a way to be able to tell the difference between skill based hunt groups and split based hunt groups using DMCC.

Basically I am trying to monitor hunt groups that agents will log into, and ignore the ones they won't.

Any assistance would be much appreciated.

Alright. I think I figured this one out. I am able to see delivered events on the hunt group ext. This should enable me to get the information I need. Thanks for the assistance.

Calls abandoned while waiting in queue is one of the biggest pieces of information I am trying to get.

Example: I place a call to hunt group ext 49000. There are no agents available to take the call, so the call gets queued. I then release the call. It never actually rang on any stations that agents are logged in to. My difficulty is in trying to indentify this individual call as abandoned.

If I could somehow get events to fire when a call is established/cleared/delivered to ext 49000 that would be ideal, so any assistance here would be much appreciated.

I am trying to figure out how to jury rig DMCC to allow me to figure out if a specific call that has cleared was abandoned or properly handled by an agent.

I know you can request vu-stats details from a phone, and then tab though the screens and capture the text on it to get a rough version of abandoned calls; but I don't think this functionality is built into DMCC for individual connections.

Please correct me if I am wrong.

I was thinking of something along the lines of looking at the device history list, and determining, based on the details that the list may or may not contain, if the call was abandoned.

Any information would be of considerable help.

Ok, I think I may have figured out what is happening.

I believe need to set up monitors on the devices that DADS is using to generate the calls.

A note: this is using the .NET DMCC API, although testing in the Dashboard reveals that this issue is language agnostic.