Call-Progress Analysis

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).

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.

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.

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…”

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.

http://dspvillage.ti.com/docs/express_dsp/expressdsphome.jhtml.

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.