AMD - Urgently need help

[Stinney]

We have our own "home-grown" dialer and we are sending predictive make call requests to the t-server (v 8.0.101.05). We have an Avaya PBX CM 5.1.2 and AES v4.1.2

We have set the AMD in the PBX to answered and when an answering machine is detected we were getting the event back to our dialer as Answering Machine and disconnected. We found out that the T-Server option "use-am-detection" needed to be changed to connect. We did this and now answering machine calls are being returned as human.

Any thoughts as to what is wrong here and why answering machine detection is coming back to us as answering machine if set to false, but human if set to connect?

[cavagnaro]

What is doing the AM detection? I think you have to adjust those settings so timers go ok, it will not work out of the box, you have to make some adjustments.

[Stinney]

So even more confusing to us, we got it to work (I'll have to ask the developer more about what he did in the dialer code to resolve), but if I change the AMD in the PBX to dropped, or answered, it doesn't change the call classifications, so it doesn't look like the PBX AMD setting effects it at all.

The Genesys CTI doesn't have call classifier boards and the only thing involved in the outbound call is the PBX. So we believe that somehow the Genesys CTI is getting back call classification from the PBX through the AES, but we don't know how.

[cavagnaro]

Well the it is not PAM/AMD just only reading ISDN signals. CONNECT, BUSY, DISCONNECT, DIAL ERROR, etc.

[minuteman]

If you use TLib, please let me see your RequestMakePredictiveCall (piece of TServer's log will be OK)

[fnunezsa]

From the T-Server for Avaya Communication Manager Deployment Guide:

use-am-detection
Default Value: true
Valid Values:
true Enables this feature.
false Disables this feature.
connect Enables this feature, but a connection occurs even though the
answering machine has been detected (the key-value pair
AnswerClass=AM is added to user data for calls with Answering
Machine Detection).

So I believe the scenario you're describing belongs to the expected behavior when "use-am-detection" is set to "connect": the call is connected but the key-value pair AnswerClass=AM.

[genesysguru]

Hi,

There is some information on my blog: http://genesysguru.com/blog/blog/2010/11/19/avaya-call-classification/

Craig