CPA - Functional Overview

An outbound dialing campaign lives or dies on what happens in the first few seconds after a call connects. Roughly half of the numbers a campaign dials will be answered by something other than the live human the application is trying to reach: voicemail and answering-machine greetings, fax machines, and operator-intercept recordings on disconnected or reassigned numbers. If the platform cannot tell those apart from a real "Hello?", the consequences compound quickly. Agents get connected to voicemail and burn handle time on dead air. Live people get dropped or hear silence while the dialer hesitates, producing abandoned calls—a customer-experience failure and, under regulations such as the US TCPA and the UK's Ofcom abandoned-call rules, a compliance exposure. Recorded messages get left on the wrong kind of endpoint, and dial attempts are wasted on fax and out-of-service numbers that will never yield a right-party contact.

The naive approach—treat any audio after answer supervision as a person, or wait a fixed interval before connecting—fails in both directions. A short timeout clips long human greetings and misroutes them as machines; a long timeout strands live callers in silence and inflates abandonment. The real problem is classification under a tight latency budget: decide what answered the call, accurately, fast enough that a human is never left waiting.

Call Progress Analysis (CPA) is the platform's answer to that problem. It combines two discrete detection technologies into a single software module that classifies the far end of a connected call: 

1. Voice activity classification: CPA reuses the voice activity detection (VAD) algorithms—the same signal processing that decides when speech starts and stops—already proven in the Capacity Private Cloud Automatic Speech Recognizer (ASR). The discriminating signal is greeting length. People answer with short greetings ("Hello?" or "Hello, this is John Smith speaking"); answering machines deliver long ones ("Hi, this is John Smith and I'm unable to come to the phone right now…"). VAD measures where the greeting ends, and CPA classifies the called party as a live person or a machine from that duration. The outcome that matters: agents stay on live conversations instead of voicemail, and the system knows when to deliver a message versus when to start an interaction.
    
2. Tone detection: CPA also listens for DSP-detected telephony tones that carry call-status information VAD cannot. At connect time, a Special Information Tone (SIT—the rising three-tone reorder/intercept sequence) or a fax calling tone marks a number that will never reach a person, so the campaign can stop spending attempts on it. Later in the call, the answering-machine or voicemail beep marks the moment to begin a recorded message, so a notification lands cleanly rather than over the greeting. 

CPA is built for outbound systems, where the cost of misclassification runs in both directions: dropping a live human is an abandoned call and a compliance problem, while treating a machine as a human wastes agent time and corrupts dialer pacing. The use cases below sit squarely in that envelope.

• Outbound Interactive Voice Response (IVR): The application places outbound calls; on a live-person classification it drops the called party straight into an IVR to complete a task, such as paying an overdue bill, with no agent and no wait. On a machine classification it holds, waits for the voicemail tone, and leaves the message at the right moment instead of recording over the greeting.
   
• Outbound Messaging: Notification systems—emergency alerts, appointment reminders, balance notices—use CPA to decide how to deliver. A live person hears the message in real time; a machine gets the same message dropped after the voicemail tone. Either way the contact is completed on the first attempt, which is what keeps right-party-contact rates up and re-dial volume down.

Where CPA does not apply

CPA classifies the far end after the call is connected; it operates on answered media, not on call-setup signaling. It is therefore not a substitute for the answer-supervision and call-progress functions your dialer or telephony platform provides before connect. Specifically, CPA does not perform the following: 

• Detection of different ring types.
• Detection of busy signals (including "fast busy").
• Detection of ringback music or color ring tones.
• Detection of DTMF key-presses.

How CPA classifies a connected call

CPA is engineered to behave like a standard ASR interaction rather than a bespoke call-progress API. That is a deliberate integration choice: any voice platform that can already speak to the platform's ASR can drive CPA with the same message flow, even if it was never designed with answer detection in mind—no new protocol, no separate media path. The classification arrives the same way a recognition result would, as soon as the decision is made. The flow is as follows: 

1. A connection between the voice platform and the ASR is established:  
   • This may be over the Media Resource Control Protocol (MRCP) by making an RTSP SETUP request (MRCPv1) or by sending a SIP INVITE (MRCPv2) with the appropriate session information. 
   • It may also be by an application making a CreateClient call into the platform API. 
   • VoiceXML developers can generally just allow their voice platform to handle this piece. 
2. Grammars are loaded and activated, as is normally the case with speech recognition. However, special meta tags in the grammar indicate that this session should use CPA (CPA can be used in conjunction with ASR). 
   • Over MRCP, this would generally take the form of a DEFINE-GRAMMAR message. 
   • Using our API, the grammar must first be registered using RegisterGrammarForPendingStream, then loaded with LoadGrammar, then activated with ActivateGrammar. 
   • VXML developers simply load the grammar as they would any speech grammar, generally as part of a form that performs CPA. 
3. The ASR is directed to begin processing audio: 
   • Over MRCP, this is a RECOGNIZE message. 
   • Using our API, StreamStartListening must be called. 
   • In VXML this is implied by the existence of forms and/or fields that use ASR. 
4. Once the ASR/CPA has finished analyzing the audio, it will make a determination (e.g. "human residence" or "fax machine" or "No input") and return that result to the voice platform as a normal speech result. 
   1. a. The possible returns can be customized in the grammar; for more on that see below. 
5. The application evaluates the result and acts accordingly.