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

stephen botzko <stephen.botzko@gmail.com> Fri, 02 April 2010 20:56 UTC

Return-Path: <stephen.botzko@gmail.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422D23A698A for <codec@core3.amsl.com>; Fri, 2 Apr 2010 13:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.273
X-Spam-Level:
X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbajn2h7X-3X for <codec@core3.amsl.com>; Fri, 2 Apr 2010 13:56:05 -0700 (PDT)
Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 03A6F3A6989 for <codec@ietf.org>; Fri, 2 Apr 2010 13:40:42 -0700 (PDT)
Received: by ywh38 with SMTP id 38so94146ywh.29 for <codec@ietf.org>; Fri, 02 Apr 2010 13:41:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Y4IgQGcizJrbRQOMLa2SAhs7xGtKx/5PYJ3RUA/bVOk=; b=EQL+jkVaN8pUzZgCZ9hCoYBEieA58RtnyHV20RKkIkDpCbLvDzoEm1ZPMKuXMdNJFd wFsMxRBSnQViNyywdkpAdl0JPkJV2ryjo456ReuVrTPI+mJd9MRsRNL7Y9feXcIbiUYp IO47tR4xvpNDRnfxME+f6aVZR2ZdK7eN8eifY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XnsP7YXW4GMu/rO/yxAblL0uY+5Ns/hxfuO+6mrr8KEiGS8QjjYLWZJIHwdYF3HTvw DSIjBhFY6GbRdCc+h193u1677e3XC1d3o32/6R6dJR9S2QG30CX73saJh9Is+JhjMY66 8ezJGvwKoGaClC0wOu5fCjwyJHBWWdZvk6hxA=
MIME-Version: 1.0
Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 13:41:13 -0700 (PDT)
In-Reply-To: <h2m28bf2c661004021332pcba95535y95afe696fbe61e68@mail.gmail.com>
References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <h2i6e9223711004020749u48c533eaq720b89f374cfbe9f@mail.gmail.com> <000301cad28a$ca0c6450$5e252cf0$@de> <n2j28bf2c661004021202s507c675ek50a1a216da540f8f@mail.gmail.com> <m2u6e9223711004021312ve393a0e5t46bffa286bd37758@mail.gmail.com> <h2m28bf2c661004021332pcba95535y95afe696fbe61e68@mail.gmail.com>
Date: Fri, 02 Apr 2010 16:41:13 -0400
Received: by 10.151.92.11 with SMTP id u11mr3049490ybl.205.1270240873848; Fri, 02 Apr 2010 13:41:13 -0700 (PDT)
Message-ID: <l2m6e9223711004021341ib0f1e500w6e564b63c0307d71@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: multipart/alternative; boundary="000e0cd2578e109f9e0483470070"
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Apr 2010 20:56:07 -0000

Its my understanding that several other standardized codecs have had
requirements like this one (and have somehow been tested).  I agree that we
will need a more precise and testable statement, and a corresponding test
method.

Though that will be true for *every* requirement we agree upon in this
phase.

Stephen Botzko




On Fri, Apr 2, 2010 at 4:32 PM, Roman Shpount <roman@telurix.com> wrote:

> I have a feeling that this requirement as it stands right now is
> non-enforceable since there is no industry accepted test on DTMF pass
> through.  Creating such test will not be trivial since it will require
> collection of the large amount of real life DTMF and other telephony signal
> recordings. So, we cannot make this a requirement for a new codec unless we
> define this in a form of some minimum frequency fidelity or some other
> independently verifiable quality requirement.
> _____________
> Roman Shpount
>
>
>
> On Fri, Apr 2, 2010 at 4:12 PM, stephen botzko <stephen.botzko@gmail.com>wrote:
>
>> 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 <roman@telurix.com> 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 <hoene@uni-tuebingen.de>wrote:
>>>
>>>> Hi Stephan,
>>>>
>>>> Comments inline:
>>>>
>>>>
>>>> ---------------------------------------------------------------
>>>> Dr.-Ing. Christian Hoene
>>>> Interactive Communication Systems (ICS), University of Tübingen
>>>> Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
>>>> http://www.net.uni-tuebingen.de/
>>>>
>>>> From: stephen botzko [mailto:stephen.botzko@gmail.com]
>>>> Sent: Friday, April 02, 2010 4:50 PM
>>>> To: Christian Hoene
>>>> Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org
>>>>
>>>> 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
>>>> codec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/codec
>>>>
>>>
>>>
>>> _______________________________________________
>>> codec mailing list
>>> codec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/codec
>>>
>>>
>>
>