One of the requirements of designing an outbound application is planning how to handle situations where the recipient of the call is not a human, for example, a fax or answering machine. How to handle these situations depends on your application. For example, an appointment reminder service may wish to leave a slighty different message than a live-speaker version. On the other hand, an outbound conference connect service would only want a live-speaker, and could hang up the call if answered by a machine.
The feature where Aculab Cloud can determine the recipient of a call is called Live Speaker Detection (LSD) in the UAS API and Far-end classification (FEC) in the REST API. Despite different names, they are the same thing. These technologies are commonly called Answering Machine Detection (AMD).
Enabling classification depends on the API being used.
All languages of the UAS API have the ability to enable classification in the Call function along with a maximum duration for which this classification takes place. When set, the Details/CallDetails object of UASCallChannel will have a call far end type specifying the recipient type.
When dealing with an answering machine, a separate function, Wait For Answer Machine, needs to be called independently. This customisable function will block execution of the application until such time as the answering machine is ready to take the message or a time out has occured.
Outbound services, and the Connect action, both have the ability to enable FEC.
In outbound services, the option to enable classification is under the Advanced settings tab. After selecting the Enable far-end classification check box, the user is given the option of how to handle situations where a machine has answered the call. By default the call will be hung up. To enable your application to process the callee type, un-check the "Hang up..." options.
For the Connect action, the "classify callee" object needs to be filled in with the appropriate settings.
When an action request is made to your application, the "call info" structure provides a "far end type" string that determines the type.
There are several settings that can be used to modify the behaviour of the wait for answering machine algorithm. The defaults will not need to be altered in the vast majority of destination numbers called. However, due to the inherent nature of the telephone network, some answering machines will take messages in a non-standard way. These include, but are not limited to, playing no beep, playing a beep in a different tone or long length, or expecting a message in a shorter or longer period of time than the default.
Call recordings must be made in order to diagnose misclassification issues. Listening to the timings of the problematic machine can yield the appropriate values for the answering machine detection algorithm. For example, if a beep on a problematic answering machine is shorter than the default, say 80ms, the min beep duration value can be changed. There are two ways to get a recording. The first is to do a whole call recording. For REST applications the classification algorithm will need to be switched off for testing, as the whole call recording will only start after classification has taken place. Alternatively, you can request monitoring on your account, which records the inbound audio of each call made. Once enabled, the monitor recordings API will be available for you to download recordings of your calls.
Handling the response
How to handle the classification response depends on your application. REST applications can automatically hang up on fax and answering machines, but UAS applications will need to deal with these types of responses separately. If the classification algorithm is unable to determine the callee in the set time out period, a timeout response will be given with an unknown type. For example, you may have reached an answering machine with a very long message. How to handle situations like this depends on the application and region. An appointment reminder service may ask for a keypad digit to determine if the person on the line is the correct recipient of the message, in which case no response would be given if a machine. However, a general announcement service may wish to play the message regardless of the type, or even repeat several times to ensure someone heard the complete message if the first few seconds of the message has not been recorded.