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

Marc Petit-Huguenin <petithug@acm.org> Sun, 28 March 2010 15:35 UTC

Return-Path: <petithug@acm.org>
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 D94013A659C for <codec@core3.amsl.com>; Sun, 28 Mar 2010 08:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.091
X-Spam-Level:
X-Spam-Status: No, score=-99.091 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 2p1+ONfyue-i for <codec@core3.amsl.com>; Sun, 28 Mar 2010 08:35:49 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id D9E103A63EB for <codec@ietf.org>; Sun, 28 Mar 2010 08:35:49 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id 8374D6C984E6; Sun, 28 Mar 2010 15:36:16 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 1E4E86C984E0; Sun, 28 Mar 2010 15:36:14 +0000 (UTC)
Message-ID: <4BAF776D.20904@acm.org>
Date: Sun, 28 Mar 2010 08:36:13 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Iceowl/1.0b1 Icedove/3.0.3
MIME-Version: 1.0
To: Michael Knappe <mknappe@juniper.net>
References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net>
In-Reply-To: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "codec@ietf.org" <codec@ietf.org>, "stephen.botzko@gmail.com" <stephen.botzko@gmail.com>
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: Sun, 28 Mar 2010 15:35:51 -0000

I disagree with the "SHOULD".  RFC 4733 and RFC 4734 takes care of DTMF and much
more, so this must be an explicit non-goal.  This is an *Internet* codec that we
are talking about so it should reuse as much as possible of the existing
Internet framework.

And BTW, RFC 473[34] is not out of band, it's codec switching.  RFC 47[34] is an
audio codec, simply very good at compressing a very specific set of
frequencies/phases, and replacing everything else by silence.  RFC 4730 and RFC
2676 are out of band.

On 03/26/2010 03:37 PM, Michael Knappe wrote:
>  I would agree with 'should'. Lot's of dtmf out there still, but also
> out of band options (rfc 2833 / 4733) that make in-band carriage less a
> concern for SIP telephony applications.
> 
> Mik
> 
> *From*: codec-bounces@ietf.org <codec-bounces@ietf.org>
> *To*: Christian Hoene <hoene@uni-tuebingen.de>
> *Cc*: codec@ietf.org <codec@ietf.org>
> *Sent*: Fri Mar 26 18:10:31 2010
> *Subject*: Re: [codec] #5: Mention DTMF in requirements
> 
> Perhaps analog DTMF carriage is a SHOULD?
> 
> I agree that out-of-band is preferable, however, there still are
> scenarios where coded DTMF tones will be sent.  It would be nice (though
> IMHO not essential) for this carriage to work.
> 
> Stephen Botzko
> 
> On Fri, Mar 26, 2010 at 3:04 PM, Christian Hoene <hoene@uni-tuebingen.de
> <mailto:hoene@uni-tuebingen.de>> wrote:
> 
>     Hi,
> 
>     > If the point of this issue to allow this codec to be used to
>     successfully
>     > transit an IP network between two TDM networks,
> 
>     which is not the primary use-case.
> 
>     > I'd suggest that out-of-
>     > band tone transport is far preferable to trying to ensure that the
>     codec
>     > will carry the tones adequately to allow them to be detected after
>     > regeneration.
> 
>     I totally agree. Out-of-band is much better than inband.
> 
>     Sorry for my radical view but I believe that analog DTMF is an old
>     and obsolete technology not worth considering anymore.
> 
>     Christian


-- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org