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

(a) "MUST NOT" means that it must fail.  Perhaps you meant "need not" or
"might not"?

(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.

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.

I also agree to the obvious comment that DTMF detection methods are out of
scope.

But there is no point in testing DTMF at all unless there is a MUST or
SHOULD requirement.  The fact that folks suggested that it be tested
indicates that they believe there *is* a requirement.  And some others are
saying that explicitly.

Perhaps they are wrong.  But I see no justification for making the
discussion off limits to this list, it is clearly in scope.

Stephen Botzko

On Fri, Apr 2, 2010 at 10:26 AM, Christian Hoene <hoene@uni-tuebingen.de>wrote:

>  I would vote for a
>
>
>
> The DTMF transmission performance MUST be tested and characterized (via an
> automatic open source testing tool)
>
> but it MUST NOT work well under all operational conditions.  Especially at
> low coding rates under the presence of packet losses it might not work
> reliable.
>
>
>
> Christian
>
>
>
> ---------------------------------------------------------------
>
> 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**:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On
> Behalf Of *Michael Knappe
> *Sent:* Friday, April 02, 2010 4:20 PM
> *To:* stephen.botzko@gmail.com; stpeter@stpeter.im
> *Cc:* codec@ietf.org
>
> *Subject:* Re: [codec] #5: Mention DTMF in requirements
>
>
>
> Agreed.
>
> Mike
>  ------------------------------
>
> *From*: codec-bounces@ietf.org <codec-bounces@ietf.org>
> *To*: Peter Saint-Andre <stpeter@stpeter.im>
> *Cc*: codec@ietf.org <codec@ietf.org>
> *Sent*: Fri Apr 02 10:01:42 2010
> *Subject*: Re: [codec] #5: Mention DTMF in requirements
>
> I heard no decision as to DTMF tone encoding.
>
> As far as I am concerned, the question of whether the codec MUST encode
> DTMF tones accurately enough to be detected at the decoder output (or SHOULD
> or non-requirement) is still open.
>
> That question clearly is in-scope, and has nothing to do with signaling.
>
> Stephen Botzko
>
> On Fri, Apr 2, 2010 at 9:57 AM, Peter Saint-Andre <stpeter@stpeter.im>
> wrote:
>
> How is the never-ending debate among DTMF signalling *methods* in-scope
> for the Codec WG? I think that Henning brought this up in Anaheim only
> to make sure that we test some DTMF tones. The signalling method is out
> of scope for the codec itself.
>
>
> On 4/2/10 7:53 AM, stephen botzko wrote:
> > Are you two suggesting that in-band DTMF is a MUST?  Or alternatively a
> > SHOULD?
> >
> > Stephen Botzko
> >
> > On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty
>
> > <James.Rafferty@dialogic.com <mailto:James.Rafferty@dialogic.com>>
> wrote:
> >
> >     I'd agree with Steve that are still many deployments which do not
> >     use RFC 2833 or RFC 4733. In our gateways, we've had to support
> >     interworking variations of tone support such as INFO and in-band, in
> >     addition to the RFC 2833 / RFC 4733.
> >
> >     James
> >     -----Original Message-----
> >     From: codec-bounces@ietf.org <mailto:codec-bounces@ietf.org>
>
> >     [mailto:codec-bounces@ietf.org <mailto:codec-bounces@ietf.org>] On
> >     Behalf Of Steve Underwood
> >     Sent: Friday, April 02, 2010 2:27 AM
>
> >     To: codec@ietf.org <mailto:codec@ietf.org>
> >     Subject: Re: [codec] #5: Mention DTMF in requirements
> >
> >     On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote:
> >     > On 03/28/2010 11:00 AM, stephen botzko wrote:
> >     >
> >     >> I would agree with this if I saw reasonable evidence that a
> >     >> preponderance of gateways and sending systems provide the
> >     signaling in
> >     >> these RFCs.
> >     >>
> >     >> Since I am not sure that this is the case, I am unconvinced that
> >     we can
> >     >> totally remove the requirement.
> >     >>
> >     >> I'd also say that an encoder that detects the DTMF tones and
> >     outputs the
> >     >> RFC 4733/34 events would fully meet the requirement.
> >     >>
> >     > As former CTO of a VoIP provider, I never saw a PSTN provider not
> >     supporting at
> >     > least RFC 2833 (even if one of them did not declare it in its SDP)
> >     >
> >     > Perhaps the question can be asked at the next SIPit event.
> >     >
> >     Its true that RFC2833 is widely deployed. Its even true that many
> >     systems have updated to RFC4733. Sadly, its also true that there are
> >     still many quirky implementations widely deployed, and a lot of
> people
> >     still need to interwork with audio DTMF.
> >
> >     Steve
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>
>