Hi Team,

I have to develope an adjunct routing application that works with all Avaya supported versions of AES. At very high level the application will do the following tasks:

1- Calculate Expected Wait Time (EWT) from Established and Queued events by monitoring a number of VDN's for a specific skill
2- The adjunct route application should be able to receive adjunct-routed calls from Avaya CM for making routing decision based on certain metrices collected from a backend database via an HTTP API.
3- The adjunt routing application will route the call to an ACM VDN

Please guide me which SDK (TSAPI/JTAPI/DMCC) can do this job and what are the pros and cons of choosing one of these three SDK's?

What does it involve for developing an AES-based adjunct routing application using one of these three SDK's?

Also what licenses are involved both for SDK and AES platform (e.g. simple TSAPI license / advanced TSAPI license etc).

Also the application should work with most Avaya supported AES versions (say starting from AES 5.0 onwards).

Also from future continuity perspectvie which of the three SDK's is the most suitable option?

Thanks.

All three SDKs can do the job. The predominate driver will be which programming language do you wish to work with.

There is a TSAPI sample application that demonstrates adjunct routing. I suggest you look at it to answer your second question. Similar design principals apply to all three SDKs.

http://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/educational_resources/sample_applications/tsapi/call_routing/index.gsp

Adjunct routing requires an advanced TSAPI user license (this is a per Communication Manager, 'site' license). From what you have said you do not have a use for TSAPI basic user licenses (monitors on VDNs do not consume a license). Even if you use DMCC, that does not change the license profile that you need for this application.

Yes, all three APIs would support what is needed by such an application from release 5.2 onward (any 5.x customer really should be on the last 5.x release for maintenance support reasons already). AEServices 5.0-5.1 was focused on Microsoft Lync and IBM Sametime integrations and DMCC did not include support for call control integrations (adjunct-routing, and monitoring VDNs)

Since DMCC is the 'unified API' (has 95% of TSAPI AND supports first party call control), I have a personal preference to iDMCC as having more capabilities under the hood than TSAPI/JTAPI. But I think all three have equally long legs.

Hi John,

Thanks for your comprehensive reply.

May be I missed something in between the lines, can you please confirm if VDN Monitoring and receiving events (like Established and Queued) is supported using DMCC for Avaya supported AES versions prior to 6.1?

I tried the DMCC dashboard (version 6.3.3.14) application in my lab. The VDN monitoring and receiving events via monitor tab doesn't work with AES 5.2 where as it does work with AES 6.3.3. If I use AES 5.2 the "Monitor Call Start" button gets disabled.

Mastering DMCC ebook mentions:

"AE Services Release 6.1 introduced an extensive set of new and enhanced third-party call control capabilities into the DMCC Service".

Does it ring a bell? Am I missing something here?

is it DMCC SDK vs AES version compatibility issue?

I visited this link: https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/interfaces/dmcc/overview/index.gsp

and got the answer to my question. It says:

"Call control makes use of the Telephony Services API (TSAPI) service to provide basic (Release 5.2 and earlier) and advanced (Release 6.1 and later) third-party call control capabilities, such as the ability to place calls, create conferences, transfer calls, reconnect calls, and monitor call control events."

So VDN Monitoring is not supported even on AES version 5.2. It is supported starting from AES version 6.1.

This statement however contradicts to your statement above where you state that it is supported from version 5.2 onwards. Can you please clarify which one is correct?

Thanks for you help.

I believe I am incorrect in my statements about 5.x supporting the functionality you need.

The little bells you set off in my head are saying that the R&D team delivered in two phases.... 5.2 for basic monitoring of a station, and 6.1 for the 'completion' of the functionality. I have been digging through my documentation and I can find trace evidence of that but nothing that makes what was delivered when black and white. For example in the 5.2 AE Services overview document, only a TSAPI Basic User license is mentioned in conjunction with the DMCC Call Control Service (for full functionality Advanced TSAPI license would be needed). In the 6.1 Knowledge Transfer materials, 'completion of the unified API" is mentioned.

I've asked for help from another individual in locating specific documentation, but for now, like I said, I am pretty sure you are correct.

VDNs are monitored using the "Monitor Call Start" request. Make sure you have the CallsViaDevice radio button selected.

http://www.devconnectprogram.com/fileMedia/download/42b37140-1fce-4b3f-b395-fb3238f0a166

This makes it clear you are correct.

Thanks John for the clarification. I appreciate that.

I have a few moer questions regarding developing my application (mentioned under this thread) in any of the three SDK's. I am unable to visualize/find answers of a few things:

1- How would my application handle simultaneous calls whereas each call will have its own session variables e.g. CLI, etc? Do I need multi-threading implemented? How does events fit? I just want to understand the mechansim of the application handling multiple simultaneous calls along with mulitple (asynchrounous) events happening. I'm more inclined to use DMCC with .Net (for AES 6.1 +).
2- Let's say I choose Windows, then would this application be deployed as a Windows Service?
3- Can this be a single application that will monitor events to calculate EWT after every x seconds and do the routing job at the same time?
4- If I go DMCC path, then as I understand I will only require Advanced TSAPI license on AES. So there is no need of any DMCC license on AES?
5- Would my DMCC based application require any TSAPI client software (libraries?) on the client? is there an DMCC client software? or does DMCC not require any client software on client machine?

Thanks.

1- How would my application handle simultaneous calls whereas each call will have its own session variables e.g. CLI, etc? Do I need multi-threading implemented? How does events fit? I just want to understand the mechansim of the application handling multiple simultaneous calls along with mulitple (asynchrounous) events happening. I'm more inclined to use DMCC with .Net (for AES 6.1 +).

I'll come back to this one when I have a bit more time.

2- Let's say I choose Windows, then would this application be deployed as a Windows Service?
Most people do deploy their app as a service.

3- Can this be a single application that will monitor events to calculate EWT after every x seconds and do the routing job at the same time?

yes

4- If I go DMCC path, then as I understand I will only require Advanced TSAPI license on AES. So there is no need of any DMCC license on AES?

Correct

5- Would my DMCC based application require any TSAPI client software (libraries?) on the client?

No

is there an DMCC client software?

Yes

or does DMCC not require any client software on client machine?

The DMCC .NET SDK has a library on the server that hosts the application. So does the JAVA version of DMCC. The XML version is a compile your own library type solution (would apply if you wanted to use a language other than Java or .NET), and thus also has a 'library' of the content you compiled.

Thanks again John.

I'll look forward to hear from you on question 1.

Re question 5, where you said "The DMCC .NET SDK has a library on the server that hosts the application". So do this library needs to be packaged within the application installer? So I don't have to take extra steps to make this library available on ther server machine that will host this application?

Thanks.

You can package either of the DMCC libraries with your application. The TSAPI client has a silent installer, JTAPI has libraries that can be packaged with the application (in the past there was a client that needed installed).

How would my application handle simultaneous calls whereas each call will have its own session variables e.g. CLI, etc? Do I need multi-threading implemented? How does events fit? I just want to understand the mechansim of the application handling multiple simultaneous calls along with mulitple (asynchrounous) events happening. I'm more inclined to use DMCC with .Net (for AES 6.1 +).

Multi threading is the right approach. While it is unlikely in this context, the application should dedicated a thread to servicing incoming traffic from DMCC and queuing it in the application to avoid filling the queue in the SDK. Another thread monitors the queue and allocates an appropriate thread to process each request in the queue. Each inbound adjunct route request would have a thread allocated/dedicated to it so the call data can be associated with the thread and made available till a response is returned to the adjunct route request (this is on the assumption that you are not sitting on the request for a long period of time (seconds) -- if the application is going to hold onto the requests for long periods of time you will either need to engineer the number of threads or get creative about storing context and resuming when conditions are appropriate to return a route for the call). If all adjunct route threads were busy, the dispatcher would need to leave additional inbound adjunct route requests in the main queue and continue dispatching EWT related events (so maybe the main thread is making some very simple decisions -- you need to engineer it not to block though) or be able to look ahead in the main queue to find the EWT events and process them. Another dedicated thread could be used to calculate EWT per skill based on the events it was given - you could have a thread per skill (probably wasteful), or one general purpose thread that was receiving the call events and updating the EWT calculations.

Thanks for the detailed reply. Appreciate your time.

Can you please give me some more details about the built in queue in SDK? For example, what is the size of this queue? and what is the mechanism of this queue in terms of receiving adjunct route requests etc.

As you mentioned, its unlikely that SDK queue will be filled in this application scenario thus thinking to keep my application really simple without multithreading. But even with relying on SDK, do I still have to implement at least a couple of threads: one for processing adjunct route requests and the other for EWT?

Now regarding EWT, if incoming calls are being queued in a particular skill in multiple VDN entry points then I assume that I will have to keep monitoring all such VDN's and receive queued and established events from these VDN to get over EWT of the skill?

Thanks again for your really helpful advice on this topic.