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

From: "codec issue tracker" <[email-masked]>
Date: Thu, 25 Mar 2010 22:44:36 -0000

#5: Mention DTMF in requirements
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------
 >> - mention DTMF in requirements
 > [MEK] some simple talk-off tests should be done to determine if
 > in-band DTMF (and potentially other call progress tones) are carried
 > in-band without sufficient degradation as to cause a DTMF detector
 misread.
 Valin:
 Definitely agree here; that was an omission from the current draft. More
 precisely, we should probably select a minimum bit-rate after which DTMF
 should be handled. I'm not sure we want to mandate that DTMF work down to
 6 kb/s, but at 20 kb/s it should definitely work. Where we put the bar is
 an open question.

 Hoene:
 Below that boundary, it might be needed to use DTMF payload format.
 http://tools.ietf.org/html/rfc2833

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/5>
codec <http://tools.ietf.org/codec/>

---

From: "codec issue tracker" <[email-masked]>
Date: Fri, 26 Mar 2010 21:39:40 -0000

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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/5#comment:1>
codec <http://tools.ietf.org/codec/>

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 26 Mar 2010 15:04:39 -0700

Hi,

> transit an IP network between two TDM networks, 

which is not the primary use-case.

> I'd suggest that out-of-

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

---

From: stephen botzko <[email-masked]>
Date: Fri, 26 Mar 2010 15:10:31 -0700

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 <[email-masked]>wrote:

> Sorry for my radical view but I believe that analog DTMF is an old and
> obsolete technology not worth considering anymore.
>
> Christian
>
>
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>