Hi Scott,

It sounds as though you may ineed have found a bug in CM or AES. We'll attempt to reproduce this and get back to you on a resolution to the issue.

One thing you should be aware of is that CSTA Call Control Services would work around this issue for you. If you issued a Make Call request rather than going off-hook and dialing digits, this issue would not surface. Call Control Services is unofficially available in AES 4.0, and will officially be available in AES 4.1. It does require a TSAPI basic user license in addition to a DMCC license, however.

Thanks for reporting this issue and look for a response soon.

Hi Scott,

This forum is specific to AES, and this question is really related to CDR and our simulator. Unfortunately, we don't have a forum for such topics. I'd recommend that you use the "Request Tech Support" link on the left hand side of the portal for this issue.

Joel

Hi Ganesh, unfortunately we're not currently handling TSAPI issues through the forums. I'd recommend that you use the "Request Tech Support" link on the left hand side of the portal for this issue.

Joel

Hi Ganesh, we are looking into the issue and will get back to you soon.

Joel

After some investigation, it appears that Communication Manager does not send out of band DTMF digits to an endpoint registered in shared control mode. Only DMCC client media mode or server media mode applications would therefore be capable of detecting DTMF digits. That in turn means that you would require additional med-pro resources in the cases that I laid out in my previous posting.

There's a chance that CM could be enhanced to send out of band DTMF digits in shared control mode. If that is an enhancement that you'd like to see, please make this request through product management.

Hi David, we're looking into this and will get back to you ASAP.

The number of DSP resources required depends on the type of DMCC station registration, the type of calls that will be made, and the administration on CM.

If you're using shared control registrations, then you will never require additional DSP resources. If you're doing client media or server media mode, then CM will set things up such that your app will be receiving an RTP stream. The rest of this post refers to client or server media mode.

If you're involved in a point to point call and CM is administered to allow direct IP-IP communications (aka shuffling), and additionally your application will typically be involved in only point to point calls with one endpoint at any given time, then you would not be using additional medpro resources.

If either CM is not administered to allow direct IP-IP communications or if your app will often be involved in calls with 2 or more real parties at the same time, then additional medpro resources would be required.

Is that clear enough for you? ;-) An Avaya solutions engineer should be able to work through this with you.

While it is not strictly required, it is recommended to have one or more dedicated CLANs for AES. Much of this depends on the usage. For instance, if your application will be registering many DMCC softphones, you may be approaching the limit of 400 registered stations per CLAN in which case you would need a dedicated board. Or if you have a heavy message rate with one of the ASAI based languages (TSAPI, JTAPI, CVLAN, DLG) you may be approaching the lmiit of 200 messages per second to a CLAN, which is the limit. Again, in that case you would require a dedicated CLAN. If you have much lower usage rates, you may be able to get away with using existing CLANs.

Hi Tom,

Agent state events are exposed to Avaya applications but not to third party applications. This was an explicit decision made by product management. You would have to speak with AES product management if you would like to give them feedback regarding this policy.

In the mean time, you can use the less attractive option of polling for agent state changes. This strategy is currently in use by several of our partners.

Joel

Hi David,

Crossfire should only be necessary if using DMCC (aka CMAPI) for a large number of endpoints (e.g. call recording).

If you're using DMCC in shared control or telecommuter mode, or if you're using any of the other APIs, a Crossfire board should not be necessary. Please give this feedback to the Avaya SE.

Joel

I assume you mean our bundled configuration? The intended use of such a configuration is that only Avaya personnel have root access, and it would not therefore be possible for a partner to deploy an application on a bundled AES server.

We definitely understand your concern regarding the number of servers, but have previously decided that this restriction was necessary in order to be able to maintain our product quality and robustness.

Hi David,

It's good to hear from you again! I hope you're well.

We do not officially support third party applications running on the same machine as AES. Our concern is that there could be unforeseen consequences of such a coresident deployment that would make it difficult for us to debug issues in the field.

As always, if you feel strongly that we should change our policy in this areay, feel free to suggest that to AES product management.

Joel

Hi Jigar,

Are you familiar with the AES Security Database (SDB)?  This SDB governs authorization for user control of devices (including ACD).  In general, when developing an application, it is easiest to disable the SDB (under TSAPI Configuration in the OAM pages) or to create a user with unrestricted access.  In these cases, it's not required to administer any devices in the SDB.

We believe that there is a bug in our AES server software that requires the use of the SDB for ACD, VDN and user agent objects.  You'll have to add your huntgroup and agent logins as devices to the SDB, and use a user that is NOT unrestricted access, and this should then work.  We'll be resolving this problem as soon as is possible.

Sorry for the dupliate reply!  I didn't see Tony's response because it came after I had navigated to this page.

Hi Nadim,

There are currently no firm plans to add this model to SMS, but I will relay your request on to Product Management for potential inclusion in a future release.  Thanks for indicating that this is a need for you.

Joel