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

[stephen botzko <[e-mail]>]

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]> 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
>
>
> On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <[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]]
>> Sent: Friday, April 02, 2010 4:50 PM
>> To: Christian Hoene
>> Cc: Michael Knappe; [e-mail]; [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]
>> https://www.ietf.org/mailman/listinfo/codec
>>
>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>
>