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

["codec issue tracker" <[e-mail]>]

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

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