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

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

If I remember it correctly, at least for our BV16 codec, modifying it to improve DTMF pass-through performance did not really hurt the codec's performance in coding speech.  Obviously I can't guarantee that the same will be true for all other codecs.

I can imagine that if a codec has a frame size of 20 or 30 ms, it will probably be more difficult than lower-delay codecs to pass DTMF signals without affecting DTMF detection performance. This is especially true for the G.720-specified 50 ms on, 40 ms off DTMF tone duration, because generally the codec frame boundaries do not coincide with the DTMF on/off time instants, so for the beginning frame and the ending frame of the codec where the DTMF signal only occupies part of the frame, the codec usually cannot reproduce the DTMF signal well.  That makes the remaining middle portion of the DTMF pulse (which can be coded better) too short for the DTMF detector downstream to decode the DTMF digits reliably.  This is especially true for the corner case of 50 ms on duration specified in G.720.  In our BroadVoice16 paper, we observed that most real-world DTMF signals we captured have an on duration between 90 and 160 ms, so longer codec frame size will be less of a problem there.  

In any case, low-delay codecs with a small frame size definitely have an advantage over longer-delay codecs for passing DTMF signals.  If you start with a low-delay codec anyway (like what we did with BV16), then tuning the codec to reduce DTMF detection error rate does not necessarily mean you have to take a hit in speech quality, bit-rate, etc.

Raymond

-----Original Message-----
From: Wyss, Felix [mailto:[e-mail]] 
Sent: Friday, April 02, 2010 1:01 PM
To: Raymond (Juin-Hwey) Chen; Brian West; stephen botzko
Cc: [e-mail]
Subject: RE: [codec] #5: Mention DTMF in requirements

I agree with those who question the value of catering to in-band DTMF for this codec.  Doing so will invariably require compromises somewhere else (quality/birate, CPU cost, coding delay, development/testing effort, code complexity, etc.)  Do we really expect that by the time this codec will be standardized and in wide use there will still be VoIP providers or devices that do not support RFC#2833 -- yet who do support this new codec? 

--Felix

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Raymond (Juin-Hwey) Chen
> Sent: Friday, April 02, 2010 14:54
> To: Brian West; stephen botzko
> Cc: [e-mail]
> Subject: Re: [codec] #5: Mention DTMF in requirements
> 
> (Responding to an earlier email on this topic...)
> 
> I think the issue here is not for a codec to detect DTMF, but for a codec
> to encode and decode the DTMF waveform with sufficient fidelity so it will
> not cause DTMF detection problems later in a DTMF detector.
> 
> Although most codecs do not explicitly make use of DTMF properties to
> improve their coding fidelity with DTMF waveforms, a codec developer can
> indeed test a codec by passing DTMF tones through the codec followed by a
> DTMF detector and try to tune or otherwise improve the codec so that it
> minimizes the DTMF detection error rate as seen by the DTMF detector.  In
> fact, this is exactly what we have done when we developed the BV16 codec,
> and as a result of such testing and tuning, we were indeed able to modify
> the BV16 codec algorithm to improve the DTMF detection error rate after
> DTMF tones were passed through BV16 and then detected by a commercial DTMF
> detector.  Such DTMF pass-through test results of BV16, G.711, G.728,
> G.729E, and G.729 are described in our BroadVoice16 paper in the
> Proceedings of the 40th Asilomar Conference on Signals, Systems and
> Computers, 2006, available at our BroadVoice website
> www.broadcom.com/broadvoice.  That's why I could answer with confidence
> the
>  DTMF pass-through question raised right after my BroadVoice codec
> presentation at our IETF 77 codec WG meeting on March 22.
> 
> I think in those conditions where out-of-band DTMF signaling is not
> available or is not implemented properly, it is crucial for the codec to
> pass DTMF tones through without causing significant increase of the DMTF
> detection error rate in a DTMF detector downstream, otherwise you may not
> even be able to get the correct telephone number through, or a credit card
> number or key press responses to a voice response system (press 1 for
> this, press 2 for that,...) may not go through correctly. That's why we
> went through the trouble of testing BV16 with DTMF tones and modifying
> BV16 to minimize the DTMF detection error rate, and that's why I agree
> with Stephen's comments below.
> 
> Raymond
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Brian West
> Sent: Friday, April 02, 2010 7:10 AM
> To: stephen botzko
> Cc: [e-mail]
> Subject: Re: [codec] #5: Mention DTMF in requirements
> 
> But Codecs themselves do not detect DTMF.  Thats the job of the DTMF
> detector.  NOT the codec.  In all my work with codecs I have not once seen
> one that knows anything about DTMF.  And if the codec is too lossy inband
> is out of the question.
> 
> /b
> 
> On Apr 2, 2010, at 9:01 AM, stephen botzko wrote:
> 
> > I heard no decision as to DTMF tone encoding.
> >
> > As far as I am concerned, the question of whether the codec MUST encode
> DTMF tones accurately enough to be detected at the decoder output (or
> SHOULD or non-requirement) is still open.
> >
> > That question clearly is in-scope, and has nothing to do with signaling.
> >
> > Stephen Botzko
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
> 
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec