Every time we place a call we instinctively perform call-progress analysis (CPA). We listen for dial tone before dialing, detect ring back, busy, answer, and so on, without giving it much thought. But duplicating the nearly unfailing precision of human-based CPA in a multiline communications system requires considerable care in its implementation.

Telephony applications with outbound calling that use the public switched telephone network require the ability to accurately and rapidly interpret the call-progress tones, such as ring back and busy, that are delivered by the network to the calling entity. This call-progress analysis is complicated by the lack of the worldwide use of standard tone frequencies and patterns. The design of CPA signal-processing DSP software must, therefore, address the tradeoff between speed of analysis and generality. Commetrex’ 60080 CPA is designed to minimize the vendor’s support requirements by providing an analysis resource that does not require tuning for over 99% of applications, even for global deployments, while providing accurate responses within 1.5 seconds (for busy) to 5.0 seconds (for ring back-off-hook-no-voice) when using the default parameters.

60080 CPA uses a low- and high-pass frequency discriminator together with energy measurements over time to qualify in-band signaling tones. Three signal characteristics are used for tone detection: the tone frequency, timing (Tone_On, Tone_Off) and period and consistency (the number of times a tone cycle repeats before being qualified).

The design of Commetrex’ CPA is based on these characteristics of call-progress (CP) tones: Nearly all CP tones are comprised of one or two frequencies between 200 and 500 Hz. Although the timing of call-progress tones varies between manufacturers and PTT administrations, there is a nearly universal signal-timing hierarchy that can be relied upon for discrimination between the various signals.

In addition to discerning all the usual call-progress tones and modem-answer tone, this product has a voice-detect capability that enables the using application to determine whether the call has been answered by a residential user, an answering machine, or a business.



‘C6000 Resource Utilization

MCPS single-sample: 2.93
Program Memory (full duplex): 19.8K bytes
Constants/tables: 4.2K
Per-Instance Memory: 456 bytes

C5400 Resource Utilization

MCPS (single-sample only): 3.6
Program Memory: 4.4K words
Constants/tables: 3.4K
Instance Memory: 590 bytes

License Options

Limited-Use Paid-Up Source Code
Object Code with Runtime Licenses

System Design

The figure below shows a general block diagram of the partitioning of the CPA system. It is divided into two Media Stream Transforms (MSTs): the feature detection (FD) MST and the CPA Finite State Machine (CPA-FSM) MST. This partitioning allows the two entities to be assigned to different processors for execution. For example, an embedded system with both DSP and a scalar (or co-processor) might benefit from the FD executing on the DSP and the FSM on the scalar.

The FD MST processes the incoming signal samples to detect/extract features like CPA tone start/stop, voice start/stop, SIT tone pattern, and fax-modem answer tone. The FD MST sends time-stamped events to the CPA-FSM MST whenever a feature is detected or a change is observed. Time stamps are based on the rate of the incoming samples (8000 samples/second).

CPA System

Above: CPA System

The following two sections provide an overview of each of the above components.

Feature Detection

The FD component of the CPA system is an MST that typically runs on the task processor. Its operation is based on partitioning the telephone channel into two bands as shown in the next figure. The FD MST implements two FIR (band and high pass) filters to compute the energy portion of the incoming signal in each band. Also, the FD MST runs four IIR-based notch filters to detect specific tones of the CED and SIT signals. All filters operate at 8000 Hz sampling rate and have a unity gain.


CPA System
Above: Partitioning of the telephone channel

The FD MST keeps track of the raw energy of the signal and does not consider the relative energies of different features before the raw energy passes a parameter-controlled threshold level. Once the raw energy exceeds the threshold, the output of each filter (the energy of each feature) is compared with the raw energy and with other filter outputs to make a decision on the signal.

Finite State Machine

The CPA-FSM component of the CPA system is an MST that can execute on the DSP, embedded-scalar, or host processor. It is driven by events from the Event Preprocessor. The CPA-FSM implements all required states for call-progress analysis. It makes use of other supporting routines to implement the processing required by each event transition. The CPA-FSM MST consists of four major components: the event pre-processor, the state machine, and the supporting (edge) routines of the state machine and the timer package.

Voice Detection

The voice-begin event is the first voice event generated when the remote party begins speaking. Note that the voice must be above the SilenceLevel for VoiceOnTime milliseconds. The voice-end event is reported after an absence of voice for SilenceLong milliseconds. If voice is detected again after an absence of voice for SilenceShort milliseconds, the voice-end-short event is reported. The voice-end-short event is not generated if voice restarted after a silence less than SilenceShort milliseconds.

CPA System

This capability allows the application to infer whether the called party answered with a “Hello”, which is 0.4 seconds, or “Hello, thank you for calling Commetrex”, or “Hi, this is Pete and Alice. We’re not here right now…”

CPA Events
Event Name(ID)Description
CP_BUSYBusy tone detected
CP_CEDModem tone detected
CP_DIALTONEDial tone detected
CP_ENDCall progress has completed
CP_NOANSWERNo answer (after ringing) detected
CP_RBTONERing back tone detected
CP_ROTONEReorder (fast busy) tone detected
CP_SITSIT detected
CP_VOICEVoice detected
CP_VOICE_END_ SHORTSilence longer than SilenceShort has been detected after detection of voice
CP_VOICE_ENDSilence longer than SilenceLong has been detected after detection of voice
CP_RBQUITRing back quit

Interfacing With the 60080 CPA

The MSP Consortium has published its M.100 recommendation for a stream-processing environment that supports multi-line multi-media stream processing. Commetrex’ implementation of M.100 is OpenMedia™, which supports the 60080 CPA as a “drop-in” resource. The native algorithm “wrapper” used by M.100 is specified by Texas Instruments (TI). TI has promulgated an algorithm-packaging standard that is designed to standardize the interface between media technologies and the controlling subsystem. The 60080 CPA conforms to this standard.


The TMS320DSP Algorithm Standard API Reference (TI document number SPRU360) is an API specification intended to reduce the cost of interfacing with licensed media technologies. All compliant algorithms must implement the IALG interface, which defines a framework-independent interface for the creation of algorithm instance objects. The interface functions fall into the following three categories:

  1. Instance object creation, initialization, and deletion
  2. Algorithmic processing
  3. Instance object control and relocation

The CPA module uses the functions listed below to implement the above interface. For a more detailed description of the proper function refer to pages 1-7 to 1-11 in the 60080 API Reference Manual.

  1. CPA_create( ): Creates a CPA algorithm object instance and performs the necessary initialization of the commands and parameters.
  2. CPA_detect( ): Processes the input data.
  3. CPA_delete( ): Deletes the algorithm object instance when the input data are processed.
  4. CPA_control( ): Defines a standard method to control the algorithm instance in real time by, for example, changing the command and parameter values. It can also be used to receive status information.
CPA Parameters
SilenceLevel-40DBmThe average value of the input stream below which the signal is considered to be silence (noise). Valid range is –46 to –34.
SilenceTime500MsecThe minimum length if a silence period after voice is detected to qualify VOICE_OFF. Signal Detection circuit responds to loss of carrier within 4 –5 ms, so minimum value for parameter is 5 ms.
SilenceShort1000MsecThe time voice must be OFF before sending VOICE_END_SHORT event. This parameter must be greater than SilenceTime. Note that the MSP App must take into account that voice had been off for a duration SilenceTime.
SilenceLong1500MsecThe time voice must be OFF before sending VOICE_END event. This parameter must be greater than SilenceShort. Note that the MSP App. must take into account that voice had been off for a duration SilenceTime.
VoiceOnTime50MsecThe minimum length of time voice must be detected before call progress reports a voice begin event.
RB_Max3000MsecThe maximum duration of a Ring-Back (RB) tone to distinguish it from dial tone. Most RB tones are between 1-2 seconds in duration. The default should be at least 2.5 Sec. The longer it is the longer it takes to qualify dial tone. The shorter it is the more likely it will have to be tuned in the field.
RB_Count5CountThe number of RB tones to report “No Answer”
RB_StopPeriod5000MsecThe time from the end of the last RB tone before declaring RB stopped, meaning the called terminal is off-hook without voice, CED or SIT. Few RB tone-off times are greater than 4 seconds; CED period is 3.5 sec
BZ_Max1500MsecThe maximum period (on time plus off time) to differentiate between slow busy and RB. Busy typically has a period of one second and a 50% duty cycle. A value of 1.5 seconds for this parameter will yield excellent worldwide results
RO_Max700MsecThe maximum period (on time plus off time) to differentiate between Slow Busy and Fast Busy (reorder). A default value of 700 – 750 msec. will yield acceptable results.
BZ_Count4CountThe number of Busy tones to qualify “Busy” or “Fast Busy”.
TimeOut10000MsecThe maximum time that can elapse with no response from the network before call progress stops with a reason of timeout.
StopMask0×21MaskMask to control which events cause call progress to stop. A value may be formed by Oring any of the following:
0×0001 voice begin
0×0002 voice end short
0×0004 voice end
0×0008 modem tone (CED)
0×0010 SIT tone
CPA always terminates if the following are detected: dial tone, busy, and no answer.
PrecMask3MaskMask to control which precise detector to run. A value may be formed by ORing any of the following:
0×0001 CED tone (modem)
0×0002 SIT