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

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

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

From: [e-mail] [mailto:[e-mail]] On Behalf Of stephen botzko
Sent: Friday, April 02, 2010 1:13 PM
To: Roman Shpount
Cc: [e-mail]
Subject: Re: [codec] #5: Mention DTMF in requirements

We don't have agreed-upon tests for anything.  I've been assuming (possibly incorrectly) that after the requirements are understood the group will need to develop a test plan that indicates how we will test against the various requirements.

Stephen Botzko
On Fri, Apr 2, 2010 at 3:02 PM, Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
This is all wonderful, but what seems to be missing here is any type of standard test for DTMF tone detection. We have a number of tests for things that should not be detected as DTMF (various talk-off tapes), but there is no test with samples of valid DTMF signals. In real world you get quite a variety of tones that different handsets or telephone devices generate when a digit is pressed. Some of those tones are almost at border line conditions for a valid DTMF tone.

Second issue, which was already mentioned here, would be performance of DTMF tone detector in the presence of packet loss or time stretching caused by jitter buffer. Those things, even if they do not prevent DTMF detection, are almost guaranteed to split a single long tone in two.

Finally, we seemed to concentrate on DTMF tones only, but in reality all the signaling/special tones are quite important. Fax Send/Receive tones come to mind almost immediately as tones that are typically detected inband (very few gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone but in terms of accuracy of reproduction of  periodic signals in specified frequency ranges. To be honest, the most robust solution would be to incorporate RFC4733/4744 as a part of the codec in a manner similar to comfort noise frames.
_____________________________
Roman Shpount - www.telurix.com<http://www.telurix.com>

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <[e-mail]<mailto:[e-mail]>> wrote:
Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone [phone]
http://www.net.uni-tuebingen.de/
From: stephen botzko [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [codec] #5: Mention DTMF in requirements
(a) "MUST NOT" means that it must fail.  Perhaps you meant "need not" or "might not"?
CH: Yes, I meant need not (or the German "muss nicht")

(b) SHOULD is commonly used in establishing requirements, and it certainly was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.
CH: Better? "The codec SHOULD support the transmission DTMF at most transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.  Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.
CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of scope.
CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

 Christian


_______________________________________________
codec mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/codec


_______________________________________________
codec mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/codec