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

[Marc Petit-Huguenin <[e-mail]>]

On 04/02/2010 12:02 PM, Roman Shpount 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.

Why would you want to do that, when there is perfectly good *Internet* codecs
for telephony signals (RFC 4733, RFC 4734 and RFC 5244) and comfort noise (RFC
3389)?

> _____________________________
> 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

-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org