CPA & AMD Settings Reference (gRPC)

An outbound dialer has to make three decisions the moment a call is answered: what answered (a person at home, a business, or a machine), how long to wait before deciding, and which non-conversational outcomes are worth acting on, such as a fax line, a disconnected number, or a voicemail beep. Call Progress Analysis (CPA) and Answering Machine Detection (AMD) settings are how you set those trade-offs. Set them too tight and you abandon live people; set them too loose and you connect agents to machines. This reference lists every CPA and AMD setting in the gRPC API, with its type, default, and effect, so you can tune them directly in protobuf fields without grammars.

Using MRCP instead? MRCP integrations configure the same behavior with <meta> tags in CPA and AMD grammars. See Grammars in CPA & AMD, and use the mapping table at the end of this article to translate between the two. For how settings are inherited from the deployment, session, and interaction levels, see Speech Settings: Hierarchy, Inheritance and Value Types.

Where CPA and AMD settings go

CPA and AMD run as two separate interactions on the same session, and both process the same audio stream. Each interaction has its own create request with its own settings group, and both accept the audio consume, VAD, and general interaction settings. See CPA & AMD Integration - gRPC for the call flow.

CPA settings

CPA classifies the answer by measuring how long the called party speaks before going silent. A person at home typically gives one short burst, a business answer is longer, and a recorded greeting runs longer still. The settings below place the boundaries between those cases.

How the thresholds produce a result

Setting human_business_time_ms equal to human_residence_time_ms removes the HUMAN BUSINESS result entirely. Setting both to a very small value, such as 10, leaves only UNKNOWN SPEECH and UNKNOWN SILENCE, which suits applications that only need to know whether anyone is speaking. That is not a typical configuration.

The costs are asymmetric. Lowering the boundary for machine-length speech classifies machines sooner, but it begins clipping long-winded humans into the machine bucket, which in an outbound campaign means abandoning live people. Raising it protects those people but lets more machines through as humans, wasting agent time. The defaults sit at a balance point for typical North American greeting patterns. Tune from observed results, and keep your abandoned-call obligations in view. For the reasoning behind the thresholds, see CPA Technical Specifications and CPA Tuning.

Limiting the time to a result

The classification model is designed around at least 5 seconds of audio. If your dialer needs a decision sooner, max_time_from_connect_ms lets you state that deadline once instead of tuning three timers by hand. When it is set, it overrides human_residence_time_ms, human_business_time_ms, and unknown_silence_timeout_ms, and the platform scales them to fit:

• Values below 1000 ms are treated as 1000 ms, the shortest period in which the algorithm can reliably decide.
• With less than 1.8 seconds of audio available, HUMAN RESIDENCE and HUMAN BUSINESS cannot be told apart.
• If the person is still speaking when the time limit is reached, the only valid answer is UNKNOWN SPEECH, which applications usually treat as a machine.

For the full scaling rules, see CPA_MAX_TIME_FROM_CONNECT.

Prompt end detection

Prompt end detection finds the moment a recorded or automated announcement stops, such as a call screening announcement, so your application can deliver its message without talking over it. A typical flow runs a normal CPA interaction first. If it returns UNKNOWN SPEECH, the application creates a new CPA interaction with prompt_end_detect set to true and waits for PROMPT END, or for PROMPT_END_TIMEOUT if prompt_end_timeout_ms expires.

Use prompt end detection on its own. When prompt_end_detect is true, all other CPA modes are ignored. Create a dedicated interaction for it rather than combining it with the residence, business, and silence timing settings.

AMD (tone detection) settings

AMD is a signal-processing analysis of tone frequencies, not speech. Each tone class you enable is one more dead path your dialer can abandon, for example a fax line, a disconnected number, or a busy signal, and one more chance to time a voicemail message to the beep instead of the start of a greeting. Each class you leave disabled costs no detection effort.

SIT result strings

When SIT detection is enabled, the platform returns one of seven strings. SIT tones are standardized by the International Telecommunication Union (ITU) and signal that a call could not be completed as dialed. You can change any string to match what your application expects.

Busy tone detection is off by default. Set busy_enable to true if you need it. Busy tones are also only detected in the first 7.5 seconds of the audio stream, and many applications only receive audio after the call has connected, so ring and busy tones may never reach the platform. Depending on your telephony platform, you may need to change its settings to pass pre-connection audio.

Audio consume and VAD settings that matter for CPA and AMD

CPA measures speech duration from the boundaries that voice activity detection (VAD) finds, so VAD timing directly shapes classification speed and accuracy. The full definitions of these groups, including the settings not shown here, are in the ASR & Transcription Settings Reference.

Tuning eos_delay_ms for CPA

Some silence after speech is natural, so the end-of-speech delay separates the pauses between words from a person who has finished speaking. Too short, and the end-of-speech event fires early, which shortens the measured speech and can push a machine message into a human classification. Too long, and the person who answered waits in silence before your application responds.

• The CPA guidance and the MRCP grammars use 1200 ms for CPA, and the grammars apply it automatically when it is not set. The API reference default is 800 ms, so set eos_delay_ms to 1200 on CPA interactions if you want the recommended behavior.
• If misclassifying a machine as a person is costly, as in many call centers, a value such as 1500 ms can improve accuracy at the cost of about 300 ms of added delay for the person answering.
• If you only need to know whether anyone is speaking (UNKNOWN SPEECH or UNKNOWN SILENCE), a value of 100 to 400 ms returns faster.
• For AMD, the delay is not used in a meaningful way, because tone detection does not look for human speech.

Mapping to MRCP grammar settings

MRCP grammars configure the same behavior with <meta> tags. In MRCP, the CPA timing defaults come from the client_property.conf file, and values in the grammar override them. Use the table to translate between the two interfaces. In gRPC, CPA and AMD are separate interactions rather than a DETECTION_MODE setting.

For CPA grammars, the platform forces the barge-in timeout and end-of-speech timeout to a value 10,000 ms greater than the largest CPA timing setting, so they never interfere with a CPA classification. On a gRPC CPA interaction, leave barge_in_timeout_ms and end_of_speech_timeout_ms at their default of -1 unless you have a reason to bound them. If you do set them, keep them larger than every CPA timing value so they cannot cut a classification short.

Troubleshooting

Related Articles

• CPA & AMD Integration - gRPC
• Grammars in CPA & AMD
• Customizing CPA and Tone Detection
• CPA_MAX_TIME_FROM_CONNECT
• CPA Technical Specifications
• CPA Tuning
• CPA & AMD Functional Overview & API Integration