Sign in

username:

password:



Not a member?

Search compdsp



Search tips

comp.dsp by Keywords

Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

Ads

Discussion Groups

Free Online Books

See Also

Embedded SystemsFPGAElectronics

Discussion Groups | Comp.DSP | Call progress tone detection

There are 2 messages in this thread.

You are currently looking at messages 0 to 2.


Call progress tone detection - L Hao - 2003-12-23 23:17:00

Hello all,

I need to develop a tone detection algorithm to detect call progress tones,
specifically busy tone, congestion tone, and error tone(howler tone) sent
from CO through subscriber loop so that we can be more intelligent about
some of the problematic hangups. Additionally, I only need this to work in
north America i.e. United States and Canada. Somewhere I read that the
frequencies for those tones vary so dramatically that I need to use cadences
instead of frequencies for accurate detections.

Can anyone with experience please share some thoughts? I'd very appreciate.
Thanks.

Lee


______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Re: Call progress tone detection - Jim Thomas - 2003-12-24 10:18:00



L Hao wrote:
> Hello all,
> 
> I need to develop a tone detection algorithm to detect call progress tones,
> specifically busy tone, congestion tone, and error tone(howler tone) sent
> from CO through subscriber loop so that we can be more intelligent about
> some of the problematic hangups. Additionally, I only need this to work in
> north America i.e. United States and Canada. Somewhere I read that the
> frequencies for those tones vary so dramatically that I need to use cadences
> instead of frequencies for accurate detections.
> 
> Can anyone with experience please share some thoughts? I'd very appreciate.
> Thanks.
> 
> Lee
> 
> 

Restricting it to North America will make your life a LOT easier (and 
made easier again by only requiring the detection of the three you 
listed).

I've not heard that the frequency varies all that much.  I'm sure it's 
spec'd out by the ITU, but I can't remember the spec number.  The main 
problem there is that the tones were spec'd to communicate an event to a 
human rather than to a machine.  But it's still pretty stable.

You need to look at both frequency and cadence.  For busy and 
congestion, the only way to tell them apart is by their cadence.  But 
you'll really want to check frequency too to eliminate false alarms.

The standard call progress tracking technique is to use a Goertzel 
transform to detect the frequencies of interest.  Google for "DTMF 
Goertzel" and you'll find gobs of info on implementation.  You didn't 
say you were looking for DTMF, but it uses the same technique.

Another part of the standard approach is to check for the absense of 
second harmonics to protect against false alarms triggered by speech.  I 
prefer to check that the frequency of interest is not a second harmonic 
instead - for instance, one of the DTMF frequencies is 1209 Hz.  The 
standard approach would have you check for the presense of 1209 and the 
absense of 2418.  I prefer to check for the absense of 604.5, because 
604.5+1209 seems more "speechy" to me than 1209+2418.

You might also want to put a time limit on the detector.  For example, 
you shouldn't look for congestion two minutes into a call.  But where 
you draw the line is up for debate.

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
j...@bittware.com  http://www.bittware.com          (703) 779-7770
Build a man a fire and he is warm for a day.
Set a man on fire and he is warm for the rest of his life!

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.