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

[stephen botzko <[e-mail]>]

On this thread I see 6 posters who see at least a SHOULD requirement, 4
posters who see a NON requirement and 3 posters for which I can't tell.

There seems to be general agreement that the use case is real, the
disagreement is whether RFC 2833 eliminates the need for DTMF transparency
(or not).

I suggest a hum in July might be the best way to see where the community as
a whole is.

Stephen Botzko



On Thu, Apr 8, 2010 at 9:27 AM, Wyss, Felix <[e-mail]> wrote:

> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > Koen Vos
> > Sent: Wednesday, April 07, 2010 13:28
> > To: [e-mail]
> > 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
> > <[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
>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>