Dear Experts,

We have limited number of DMCC licenses e.g only 10, whereas we wish to monitor e.g 200 analog and IP extensions for some specific dialing action such as “*21*”

as soon as some extension make this dialing action our app will do the required actions by taking over the extension via DMCC.

Is that possible? And how.

Please advice

As we have observed Avaya recorder do the same, it can monitor range of extensions and wait for call to be established and do the concurrent recordings as per available licensed resources.


additionally, can we read extensions password from somewhere? required to login extension with DMCC and perform dialing, or if we can login DMCC extension without password?

Regards,
ADDY

Monitoring for call activity is typically done via TSAPI or JTAPI, (or DMCC) and requires a TSAPI Basic User license.
Monitoring for RTP (in the case of the recorder), is strictly a DMCC licensed service.
This is the behavior you probably see in the recorder you cite.

You can not monitor for call activity without leveraging a TSAPI basic user license unless you want to wait till the call has ended and then leverage the Call Detail Reporting report.

There are ways to login a DMCC application to an extension without knowing the passord for that extension. This is described in the DMCC Programmer's Guide. Search for this text and read the information there in:

"For AE Services with Communication Manager 5.1 or later, the client application does not have to know the extension password to register a device, provided the following is true"

You can also use it by leveraging the following FAQ:
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/sms_web_services/index.gsp#180


Both techniques have their security risks though.

Hello, we managed to achieve all via DMCC, now we monitor we intervene in call, place calling extension on hold to dial required feature code and it works till here.

But when after above we pull back “retrieve” the call it fails somehow.

And note that if we hold and retrieve the call without making call in between while on hold it works fine.

please guide what and how can we share to get your suggestion.

If there is already an active call at the device (ringing or talking state, or listening to an announcement or tone) you can not retrieve a second call. Is the call you placed still active? Try putting it on hold or disconnecting it before retrieving the first call.

If the second call you placed has been cleared, make sure you are using the proper call identifier for the first call in your retrieve request.

Perform the actions your application is making manually at a physical phone. are you able to retrieve the first call? If so what is different about your manual actions as compared to those that the application has made?

we will try the suggested and share the results.

meanwhile, note its analog extension and manually from phone we can take back first call by simple flash-hook.

I wasn't considering the analog station case, I will have to ask someone operationally how that is expected to be managed.

please do it... meanwhile i will check what happens with call as you suggested

If you snapshot the device just prior to attempting to retrieve the first call, what are the results of the snapshot?

Is it possible to monitor multiple extensions simultaneously using DMCC APIs? If yes. Which API specifically facilitates this operation?

The explanation in the Dashboard document is mainly focused on a single extension. Can someone provide precise steps to handle many extension at once?


Thanks!

Monitoring two stations would go something like this:

1. Start the application session
2. GetDeviceID for station1
3. Start monitors for station1
4. Register Terminal for station1 (if necessary)
5. GetDeviceID for station2
6. Start monitors for station2
7. Register Terminal for station2 (if necessary)

Note, it is possible to perform steps 5-7 in parallel with steps 2-4.

Martin

note further, that an application should have no more than 10 outstanding requests to AE Services at any one moment in time. So while it is possible to establish thousands of monitors on thousands of devices in parallel, the application must pace itself in sending the requests to set up these monitors to avoid causing issues with itself, and other applications using AE Services, and Communication Manager in general.

Many thanks Martin & John for your support.

What's a reasonable approach to start monitoring multiple extensions (for instance, 10.000 extensions) at a time pro-grammatically within an application.

As I indicated, that the application should limit itself to 10 out standing requests (startMonitor() is one such type of request) at a time. When a response is received another request can be dispatched. AES doesn't really care what the request is (startMonitor(), TOD query(), getAgentStatus(), etc), it is just that each request puts some iota of work into the system and an application shouldn't, make endless requests without taking pause to at a minimum handle the responses, but also to allow AES and Communication Manager to do 'other' work. This is particularly true during initialization/link recovery where there is a large amount of work that needs done.

Thanks John.

I have two questions.

1. DMCC conference call merges the first call segment and the second conference call segment in to a single call.

Is there a way to catch the first call segment and the second conference call segment separately.

For instance,

First segment: start time , end time, CallID, duration,...
Second conference call segment: start time, end time, CallID, duration...


2. DMCC ThirdPartyCallController.ConferencedEventArgs type gets called and executed when the event occurs.

How and When ThirdPartyCallController.ConferenceCallResponseArgs type gets executed?

Does ThirdPartyCallController.ConferenceCallResponseArgs type require some extra steps to get called and executed like EventArgs?

Thanks in advance

ThomsOloho, your questions do not seem to be related to this thread. Please start a new thread for them.

Mixing different questions in a single thread makes it difficult for future readers to find information from these forums.

Martin