Introduction to CPA
On an outbound campaign, the moment a call connects is the moment money is made or lost. Connect an agent to a live person and the campaign works. Connect them to a voicemail greeting instead and you have burned paid agent time, lowering agent utilization and right-party-contact (RPC) rates. Worse, drop a live person because the dialer misjudged the answer and you have an abandoned call — a poor customer experience that also carries regulatory exposure under the US TCPA and Ofcom's abandoned-call rules. Add the numbers that can never become conversations — fax lines, busy signals, and disconnected numbers — and an unguided dialer wastes a real share of every campaign.
Call Progress Analysis (CPA) makes that connect-time decision automatically, in the first seconds of the call. A module of the Capacity Private Cloud Automatic Speech Recognizer (ASR), it classifies whether the called party is a live person or a machine — voicemail, a fax line, or a recorded announcement — so the platform can route each outcome correctly: live answers to agents, a voicemail drop for machines, and an early hang-up on fax, busy, and dead numbers. CPA works with any application that can drive the ASR, including those built on the gRPC API or on MRCP, and pairs especially well with VoiceXML/CCXML applications.
CPA & AMD integration guides
This article introduces the core concepts behind Call Progress Analysis. For implementation guidance, see the companion guides: CPA & AMD Integration Overview, MRCP Integration, and gRPC Integration.
How CPA classifies a call
CPA reads two signals. The shape of the speech after answer tells it whether a person or a recording is talking. Telephony tones before and during the call catch the connections that never had a person behind them — fax, busy, and disconnected numbers.
Speech-shape analysis with VAD
CPA's first signal is behavioral, not linguistic: it does not transcribe the greeting, it measures how long the answer speaks. The Voice Activity Detection (VAD) in the ASR — the same component that separates speech from silence during recognition — times that opening speech burst. The pattern is consistent: people answering a personal line say very little (“Hello?”) before pausing; business agents say a little more; voicemail greetings run on for several seconds without a pause. CPA times the burst against a set of thresholds and returns one of four classifications.
Those thresholds are the campaign's main tuning lever, and they balance two opposing risks. Set them loose to catch more humans, and a slow voicemail intro is occasionally read as a person — a false positive that wastes agent time. Set them tight, and a talkative live answer can be clipped into the “machine” bucket — a false negative that becomes an abandoned call. Read the four classifications as instructions to the dialer, not just labels:
| Classification | Initial speech | What it is | Dialer action |
| HUMAN RESIDENCE | < 1800 ms | Live person, personal line | Connect to agent |
| HUMAN BUSINESS | 1800–3000 ms | Live person, business greeting | Connect to agent |
| UNKNOWN SPEECH | > 3000 ms | Almost certainly a machine | Release agent; voicemail drop |
| UNKNOWN SILENCE | No speech in 5000 ms | Dead air or silent pickup | Prompt once, or release |
Human Residence
A live person on a personal line — the outcome a campaign wants. People answering a personal line open with a short greeting, then stop and wait for the caller:
"Hello? <silence>"
The burst falls well within 1800 ms (CPA_HUMAN_RESIDENCE_TIME):
At only a few hundred milliseconds — comfortably under the 1.8-second threshold — CPA returns HUMAN RESIDENCE: a live right-party contact, routed straight to an agent.
Human Business
A live person too, but with a longer business greeting. It is still a contact worth an agent; the separate label simply lets a campaign treat businesses differently — a different script or pacing, say. Commercial answers run a little longer than a personal “Hello?”:
"Thanks for calling XYZ company, how may I help you? <pause>."
At around 2 seconds — past CPA_HUMAN_RESIDENCE_TIME (1.8 s) but under CPA_HUMAN_BUSINESS_TIME (3 s) — CPA returns HUMAN BUSINESS. Connect it to an agent.
Unknown Speech
The far end is talking, but too long to be a live greeting — almost certainly a machine. Release the agent and, if configured, queue a voicemail drop. Voicemail greetings run on without the pause a live person leaves for a reply:
"Hi, this is John Smith with XYZ Company. I'm away from my desk right now, so please leave me a message after the beep. <pause>."
Past 3 seconds, beyond the CPA_HUMAN_BUSINESS maximum, CPA returns UNKNOWN SPEECH — the opening of an answering-machine message or other recording. Importantly, CPA returns the moment it has heard enough to cross the threshold; it does not wait for the greeting to finish. In a real-time dialer working against a latency budget, that early return frees the agent sooner and starts the message sooner, shrinking the awkward silence a live caller would otherwise hear.
Unknown Silence
Nobody spoke. The call connected but no speech arrived within the listening window — dead air, a silent pickup, or a line that never produced a greeting.
CPA returns UNKNOWN SILENCE when no speech is detected before CPA_UNKNOWN_SILENCE_TIMEOUT — here the default 5 seconds (5000 ms). Any speech before the timeout yields one of the other classifications instead.
The right response depends on the campaign. Prompting once recovers a silent live answer — it becomes Human Residence as soon as the person speaks — while hanging up risks abandoning one. This is the ambiguous bucket: tune the response toward whichever error your campaign can least afford.
Tone Detection
Speech-shape analysis only applies once something starts talking. Many failed connections never get that far — the number is a fax line, the line is busy, or the carrier returns a special information tone for a disconnected number. Detecting these tones is what stops a campaign spending dial attempts, and pacing capacity, on numbers that can never become a conversation.
Using digital signal processing (DSP), CPA recognizes four telephony tones. Three occur before connect and mean the call will never reach a person; the fourth is the in-call answering-machine beep that signals exactly when to start a voicemail drop. Each is enabled independently in the grammar, so a campaign turns on only the detection it intends to act on.
| Tone | What it signals | Dialer action | Grammar setting |
| SIT | Disconnected, changed, or invalid number | Abandon; flag record for scrubbing | SIT_CUSTOM_ENABLE |
| Fax | Fax machine — no voice conversation possible | Abandon; candidate for scrubbing | FAX_CUSTOM_ENABLE |
| Busy | Line engaged — a valid number | Abandon, retry later | BUSY_CUSTOM_ENABLE |
| Answering-machine beep | Machine ready to record | Begin voicemail drop | AMD_CUSTOM_ENABLE |
Special Information Tones (SIT)
The carrier is signalling that the call cannot complete — usually a disconnected, changed, or invalid number. There is no party to reach: abandon the attempt and flag the record, which is often worth scrubbing from the list. The tone is three rising tones of differing frequencies, followed by a recorded message:
"<three rising tones> We're sorry, your call cannot be completed as dialed. Please check the number and try again"
Seven standardized SIT patterns exist, as described in the Grammars in CPA and AMD article; each encodes a different failure reason, and the spoken message that follows is generally customized to the provider. Capacity Private Cloud tone detection classifies all of them and returns the SIT response. Enable it with:
<meta name="SIT_CUSTOM_ENABLE" content="true"/>
Fax Tones
The number is a fax machine — it will never hold a voice conversation. Abandon the attempt immediately and, as with a SIT, treat the record as a candidate for scrubbing. Catching the fax tone early, rather than waiting out a silence or speech timeout, returns the dial slot quickly — where pacing efficiency is won or lost on a large list. Enable it with:
<meta name="FAX_CUSTOM_ENABLE" content="true"/>
Busy Tones
The line is engaged. Unlike a fax or disconnected number, this is a valid number worth retrying, so abandon the current attempt but keep the record in the campaign for a later pass. Busy detection lets applications with pre-connect audio recognize an engaged line and release early rather than holding the slot through a timeout. Enable it with:
<meta name="BUSY_CUSTOM_ENABLE" content="true"/>
Busy tones vary by country but fall in the 400–680 Hz range and appear within the first couple of seconds (again, given access to pre-connect audio).
One interaction is worth planning for: with AMD and busy detection both enabled, some answering-machine tones share the 400–680 Hz range and can be confused with a busy signal. Timing is the discriminator — busy detection is active only in the first 7.5 seconds, by which point a real busy signal has already appeared, whereas an answering-machine beep typically arrives later.
Answering Machine Beep
The greeting has finished and the machine is ready to record — the cue to begin a voicemail drop. Starting on the beep is what separates a clean message from one that talks over the greeting or opens into dead air. Because the beep follows the greeting, it arrives later than the pre-connect tones, and its exact position depends on the greeting's length; the algorithm catches a beep anywhere in the stream when enabled. Enable it with:
<meta name="AMD_CUSTOM_ENABLE" content="true"/>
Implementing CPA
Deploying CPA means installing the module, licensing it, and choosing where its behavior is configured. Install it with the Kubernetes stack guides — see Installing CPA. If you are new to Capacity Private Cloud, review the Licensing overview first.
For using and deploying CPA, see the CPA & AMD integration guides: the functional overview, MRCP integration, and gRPC integration.
For MRCP, we recommend grammar-based settings: they let you change behavior from one call to the next, and apply different settings per application or per tenant in a multi-tenant environment — all managed in one place. See Grammars in CPA and AMD. For gRPC clients, CPA behavior is set directly in the protobuf request fields rather than in grammars — see the gRPC integration guide.
Developer reference: full API documentation is published on the developer portal — the CPA functional overview, the gRPC API definition (cpa-lumenvox.proto), and CPA configuration.
