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

[stephen botzko <[e-mail]>]

We are getting closer to agreement, but maybe aren't all the way there yet.

For me, requirements need to be solidly anchored in use cases.  So if we
identify reasonably common use cases, then the functionality that is needed
for use cases has to be reflected in the requirements (either as SHOULDs or
MUSTs).  If the requirements are not clearly articulated and documented,
then some will get lost as we move through the development / seleciton /
testing process.

We certainly agree that the developers will need to keep all the
requirements in mind.  After we have the full list of requirements, we will
then need to figure out the test plan.

I think we also agree that we won't succeed if we have a very long list of
requirements.  One way to try to prevent that is to narrow our application
focus.  At the moment that seems a bit vague, and perhaps to broad.

As an aside, I would prioritize tandeming well above DTMF.  We are not
seeing any trend towards client side mixing (either with SIP phones or video
systems).  Also conference bridges are typically deployed for a very long
time, so the existing server-side mixing will be with us for the foreseeable
future..

Stephen Botzko





On Wed, Apr 7, 2010 at 1:28 PM, Koen Vos <[e-mail]> wrote:

> The distinction between use case and testing makes sense to me.
>
> DTMF is a real use case. For example some PSTN gateways still don't support
> out-of-band DTMF.
>
> It's unclear what to test about DTMF though. The Codec will support a range
> of sample rates and bitrates. The requirements specify coding of music at
> near-transparent quality. I don't see how a such a codec could not provide
> sufficient quality for in-band DTMF. At the same time, the requirements talk
> about bitrates down to 8 kbps, where it may be quite tricky to get DTMF to
> work well. Therefore, specifying that the codec SHOULD or MUST encode DTMF
> with sufficient quality is meaningless. If anything, the bitrate settings
> that allow in-band DTMF could be characterized after the Codec is formed.
>
> Nevertheless it's good to be aware of these use cases during development.
> For instance, with SILK we included DTMF signals in the LSF quantizer
> training database.
>
> Similarly, I see tandem coding as a use case to keep in mind during
> development, but again don't see a need for testing or MUST/SHOULD
> requirements.
>
> koen.
>
>
>
>
> Quoting stephen botzko:
>
>  I agree that there is a pretty strong consensus that carriage of "analog"
>> fax and modem signals is a non-requirement.  If by "payload switching" we
>> are talking about switching codecs, then that is beyond the charter scope.
>>
>> I am thinking that we are getting a bit too focused on testing methods.
>>  In
>> my view it would be more efficient to capture use cases, and derive MUST
>> and
>> SHOULD requirements from them first.  Then go back and figure out what we
>> will test and how we will test it.
>>
>> Stephen Botzko
>>
>>
>>
>> On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming <[e-mail]
>> >wrote:
>>
>>  Raymond (Juin-Hwey) Chen wrote:
>>>
>>> > 2. Did you ever test your CODEC for other telephony signals, such as
>>> > /ANSam, ANS, CED, and CI tones? These tones are needed in order to
>>> > detect modems and fax machines and switch to an appropriate payload.
>>> > What about progress tones?
>>> > [Raymond]: No, we didn't.  However, if these are single-frequency
>>> tones,
>>> > I would expect that it should be easier for a typical codec to pass
>>> > these tones than to pass the dual-frequency DTMF signals without
>>> causing
>>> > significant degradation in the subsequent processing of these tones.
>>>
>>> This is pretty much a dead-end based on the other comments on this list,
>>> but in general, no, most of these tones are *not* single-frequency
>>> simple tones. ANSam, for example, is a single frequency, but is
>>> amplitude modulated. There are also variants that have phase reversals,
>>> and these must be preserved for them to be discriminated from the
>>> non-phase-reversal versions.
>>>
>>> --
>>> Kevin P. Fleming
>>> Digium, Inc. | Director of Software Technologies
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> skype: kpfleming | jabber: [e-mail]
>>> Check us out at www.digium.com & www.asterisk.org
>>>
>>> _______________________________________________
>>> codec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/codec
>>>
>>>
>>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>