I'm having an issue where my application registers multiple DMCC extensions and each DMCC extension places a call to another extension. The issue is when the far end picks up, I get the established event for the DMCC extension, but not for the other extension even though I'm monitoring it. Also the called device ID that I get in the established event for the DMCC extension does not match the extension that was called. In this one scenario, the application placed 4 calls to 4 different extensions and only received an established event for one of the far end extensions even though all 4 answered and were being monitored. Interestingly, for the three calls that did not receive an established event for the far end extension, the called device ID in the established event for the DMCC extensions are all the same, despite the calls being placed to different numbers.

To illustrate:

1. DMCC extension 2960002 calls 2225754. I get an established event for both extensions. Called device ID for DMCC extension is 2225754.

2. DMCC extension 2960001 calls 2225711. I get an established event only for DMCC extensions Called device ID for DMCC extension is 2166444.

3. DMCC extension 2960003 calls 2225744. I get an established event only for DMCC extension. Called device ID for DMCC extension is 2166444.

4. DMCC extension 2960004 calls 2225722. I get an established event only for DMCC extension. Called device ID for DMCC extension is 2166444.

Why am I not getting established events for the called extensions? What is that 2166444 device ID?

Thanks,
Ben

what type of device monitor are you creating? Call Control I presume, but please confirm.
Are all your monitorDevice requests being positively responded to?
Are your calling and called devices on the same CM?
Are the extensions that are being called stations or is this call flow more complex?

Please enable the tracing in AE Services for XML events using the DMCC FAQ that describes how or through the web interface to AE Services.

Then use the XML events in the /opt/mvap/logs/mvap-trace.log.0 to see what AE Services is sending your application in the Establish events.

From what I understand of your description it appears to be a problem with the logic in handling the establish events.

Further an establish event is not sent for the calling party, other events are used to describe its activity. A party joining a call that has been successfully originated triggers established events (e.g. answer, unpark, bridge on), so if you are receiving establish events they indicate the called party has answered, the mystery is why you keep getting 2166444 as the called number (which I will point out is not the same as the answering party information... which is probably what you are looking for in reality), but start with the XML information AEServices is sending and work from there.

I should have been a little more clear. I'm actually using TSAPI to do the monitoring and DMCC to do the make calls. I do see other events for the called extensions. All devices are on the same CM and the called extensions are stations.

-Ben

I still think the problem you are seeing is not with the TSAPI events, but properly accessing the data in them. There is another FAQ on enabling TSAPI tracing.

On this page
http://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp

See the FAQ titled "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?"

Please follow those instructions and then observe the csta_trace file which captures the TSAPI events sent to/from your application. Hopefully you will not see the funny extensions 2166444 in those messages which will help us focus on a logic flaw in getting at the data in the messages.

And I told you a white lie... you can get an establish event for the calling party if it goes on and off hold once the call has been established.

I think I figured it out. That 2166444 number appears to be the number that agents at this location dial to retrieve their voice mail. So these outgoing calls are not being answered by the intended extension but are being forwarded on to a voice mail box.

-Ben

that will do it... the establish events would identify the device that answers the call. I was assuming in each case you knew the called phone answered the call.