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

I still fail to see a reason to include support for DTMF transparency as a requirement.  It simply does not seem worth the cost to even test (DTMF) tones other than to ensure the codec doesn't produce overly unpleasant audio artifacts.

Your statement that some PSTN gateways currently don't support RFC#2833 seems immaterial to me as they also do not support this yet to be designed codec.

--Felix

> -----Original Message-----
> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of
> Koen Vos
> Sent: Wednesday, April 07, 2010 13:28
> To: codec@ietf.org
> Subject: Re: [codec] #5: Mention DTMF in requirements
>
> 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
> <kpfleming@digium.com>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: kfleming@digium.com
> >> Check us out at www.digium.com & www.asterisk.org
> >>
> >> _______________________________________________
> >> 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