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

["Wyss, Felix" <[e-mail]>]

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