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

stephen botzko <stephen.botzko@gmail.com> Sun, 28 March 2010 18:00 UTC

Return-Path: <stephen.botzko@gmail.com>
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 52D883A684B for <codec@core3.amsl.com>; Sun, 28 Mar 2010 11:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.253
X-Spam-Level:
X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
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 MhIqE3WQJwPY for <codec@core3.amsl.com>; Sun, 28 Mar 2010 11:00:28 -0700 (PDT)
Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 6B9EC3A6826 for <codec@ietf.org>; Sun, 28 Mar 2010 11:00:27 -0700 (PDT)
Received: by iwn29 with SMTP id 29so6038729iwn.17 for <codec@ietf.org>; Sun, 28 Mar 2010 11:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=J9A57TZ01ave7pg+UD46y56L0LHxaNGmYcoakDLfZdI=; b=JHuSRhhz3DJ+40V33+NtblNrXKgKS6QwHGvUkIaMuatso7zRGoL7xnNXBg7aN6mwNR iITlFoK++ElgX8wu3ZTmfcy8VBgzPskEuxdlW3M638yghf9P/uLTJn7R8kfejNp5ANIs Gnw39hjS1lBAa/bzw7BsyHk/c+L7uETYB2Ssc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uryNm09L5k05Ddv2bYuY9bXZ19Se/GVwDWORfI8ZNZv+ZERDR+dOlrrKmtpPuytD6x hYw/Wmhkc7s+dydHbkW0gBg1OAXaLNbg/m/X6GyLcWOigygVCBBtD07T/V5iHWDJZwX9 eG37xJSivb7MvqdcQIPiXODd/U4elD33Zz6lM=
MIME-Version: 1.0
Received: by 10.231.79.202 with HTTP; Sun, 28 Mar 2010 11:00:50 -0700 (PDT)
In-Reply-To: <4BAF776D.20904@acm.org>
References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org>
Date: Sun, 28 Mar 2010 14:00:50 -0400
Received: by 10.231.145.5 with SMTP id b5mr1985259ibv.70.1269799251057; Sun, 28 Mar 2010 11:00:51 -0700 (PDT)
Message-ID: <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Marc Petit-Huguenin <petithug@acm.org>
Content-Type: multipart/alternative; boundary="0016e6481a504b9ec10482e02d5f"
Cc: "codec@ietf.org" <codec@ietf.org>
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 18:00:29 -0000

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.

Stephen Botzko

On Sun, Mar 28, 2010 at 11:36 AM, Marc Petit-Huguenin <petithug@acm.org>wrote:

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