Re: [codec] #5: Mention DTMF in requirements

"Raymond (Juin-Hwey) Chen" <rchen@broadcom.com> Fri, 02 April 2010 21:45 UTC

Return-Path: <rchen@broadcom.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E9B3A6989 for <codec@core3.amsl.com>; Fri, 2 Apr 2010 14:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.132
X-Spam-Level: *
X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvQZbXUKv+DP for <codec@core3.amsl.com>; Fri, 2 Apr 2010 14:45:16 -0700 (PDT)
Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 4A8593A6957 for <codec@ietf.org>; Fri, 2 Apr 2010 14:43:09 -0700 (PDT)
Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 Apr 2010 14:43:32 -0700
X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201
Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 2 Apr 2010 14:44:57 -0700
From: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>
To: Brian West <brian@freeswitch.org>
Date: Fri, 02 Apr 2010 14:43:32 -0700
Thread-Topic: [codec] #5: Mention DTMF in requirements
Thread-Index: AcrSqYdxY73oTd9iQ+2CNB1fP0OR2QAACmcA
Message-ID: <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86E0A@IRVEXCHCCR01.corp.ad.broadcom.com>
References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <h2i6e9223711004020749u48c533eaq720b89f374cfbe9f@mail.gmail.com> <000301cad28a$ca0c6450$5e252cf0$@de> <n2j28bf2c661004021202s507c675ek50a1a216da540f8f@mail.gmail.com> <m2u6e9223711004021312ve393a0e5t46bffa286bd37758@mail.gmail.com> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86DCB@IRVEXCHCCR01.corp.ad.broadcom.com> <C95B9890-7FDC-4818-9C8B-CE139E51F3D6@freeswitch.org>
In-Reply-To: <C95B9890-7FDC-4818-9C8B-CE139E51F3D6@freeswitch.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67A8BA8E31G79145304-01-01
Content-Type: multipart/alternative; boundary="_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86E0AIRVEXCHCCR01c_"
Cc: "codec@ietf.org" <codec@ietf.org>, stephen botzko <stephen.botzko@gmail.com>
Subject: Re: [codec] #5: Mention DTMF in requirements
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Apr 2010 21:45:22 -0000

Hi Brian,

You probably misunderstood me.  I am not suggesting relaxing the DTMF detector, which may increase the probability of detecting speech as DTMF.  I was just talking about relaxing the corner-case conditions imposed on the DTMF signal itself.  The DTMF detector remains the same.  For example, G.720 specify 50 ms on, 40 ms off tone duration, but all the automatic DTMF dialers we recorded has significantly longer on durations than 50 ms, and even when I deliberately tried to press the button for as short a duration as possible, I was never able to produce a DTMF tone duration shorter than about 60 ms. As I said in my last email, most recorded DTMF signals we collected have on durations of 90 to 160 ms. Therefore, if we want to get a better idea of how a codec would perform in passing real-world DTMF signals, we may want to use a tone duration longer than 50 ms, perhaps in the 75 to 105 ms range like we did in our BroadVoice16 paper.

Of course, if necessary, we can still use exactly the corner conditions listed in G.720 and measure the DTMF detection error rate of a codec for each condition.  That will tell us the worst-case DTMF pass-through performance of a codec (versus the "typical-case" performance for real-world DTMF signals described above).

In reality, DTMF tones were carefully chosen so that there is no harmonic relationship between any pair of the 8 possible frequencies.  This makes the probability of falsely detecting speech as a valid DTMF tone extremely low since high-energy voiced signal have harmonically spaced spectral peaks.  Just to give an idea, we passed the 2.5 hours of speech in the Bellcore DTMF test tapes through a codec then a commercial DTMF detector.  When there was no codec (i.e. 16-bit linear PCM was used), only 40 isolated DTMF digits were detected out of 2.5 hours of speech.  When the codec was 64 kb/s mu-law PCM, 39 digits were detected.  When the codec was BV16, only 31 digits were detected. These numbers are much lower than what's specified in the requirement R15-21 of the Bellcore General Requirements GR-506-CORE, which states that a DTMF receiver shall not register the 16 possible DTMF symbols more than 670 times when decoding the 2.5 hours of signals contained in the three Bellcore cassette tapes.

Raymond

From: Brian West [mailto:brian@freeswitch.org]
Sent: Friday, April 02, 2010 2:15 PM
To: Raymond (Juin-Hwey) Chen
Cc: stephen botzko; Roman Shpount; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

The biggest issue with relaxed DTMF is screaming kids can trigger stray DTMF detection as can some people's voices.

/b

On Apr 2, 2010, at 3:54 PM, Raymond (Juin-Hwey) Chen wrote:


Actually, ITU-T Recommendation G.720 gives some guidelines about how to test a codec's performance when passing DTMF signals through in-band.  (It also talks about other non-voice signals.)

In practice, however, we found that some of the test conditions specified in G.720 are fairly extreme corner cases which you normally don't see in real-world recorded DTMF signals.  Real-world DTMF signals are usually easier to pass through a codec without degradation in the DTMF detection error rate than those extreme DTMF conditions specified in G.720.

In our BroadVoice16 paper that I mentioned previously, we described a method for testing DTMF pass-through performance for a codec.  The method is based on G.720 but with some relaxation of the extreme conditions to better reflect the DTMF conditions we observed in a large amount of real-world record DTMF signals.  This is because we are more interested in how a codec would perform when passing typical real-world DTMF signals through.

Raymond