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

"codec issue tracker" <> Fri, 26 March 2010 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 548393A69AA for <>; Fri, 26 Mar 2010 14:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.677
X-Spam-Status: No, score=-99.677 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HBUG0YDx1h1D for <>; Fri, 26 Mar 2010 14:39:16 -0700 (PDT)
Received: from (unknown [IPv6:2001:1890:1112:1::2a]) by (Postfix) with ESMTP id 1AC0D3A6A92 for <>; Fri, 26 Mar 2010 14:39:16 -0700 (PDT)
Received: from localhost ([::1] by with esmtp (Exim 4.69) (envelope-from <>) id 1NvHFk-0000fI-5w; Fri, 26 Mar 2010 14:39:40 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
X-Trac-Project: codec
Date: Fri, 26 Mar 2010 21:39:40 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 5
In-Reply-To: <>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [codec] #5: Mention DTMF in requirements
X-Mailman-Version: 2.1.9
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Mar 2010 21:39:17 -0000

#5: Mention DTMF in requirements
 Reporter:  hoene@…                 |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     

Comment(by kpfleming@…):

 RFC 2833 has been superseded by RFC 4733, but in any case, I think it's
 preferable in nearly all instances to have the tone detection be done at
 the conversion point into the proposed codec, not after. There are many
 other tones besides DTMF that can be carried via these out-of-band payload
 types, and we'd have to identify which ones should survive. For example,
 for Super G3 FAX machines, the answering endpoint will generate an ANSam
 signal, which is both amplitude modulated and has periodic phase
 reversals. This signal must be transported to the calling endpoint to
 begin the V.8 negotiation process.. which is fairly easy to do if the
 IP/TDM gateway at the answering endpoint's end does the detection and
 transmission using RFC 4733... but could be much harder (and maybe not
 possible) at the calling gateway's end. In addition, there are 'pure IP'
 endpoints that would prefer not to have to have DSP-type tone detectors
 running on the incoming audio stream at all.

 If the point of this issue to allow this codec to be used to successfully
 transit an IP network between two TDM networks, 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

Ticket URL: <>
codec <>