Comments
Separate RTP payload formats are desirable since
low-rate voice codecs cannot be guaranteed to reproduce these tone
signals accurately enough for automatic recognition. Defining
separate payload formats also permits higher redundancy while
maintaining a low bit rate.
The payload formats described here may be useful in at least three
applications: DTMF handling for gateways and end systems, as well as
"RTP trunks". In the first application, the Internet telephony
gateway detects DTMF on the incoming circuits and sends the RTP
payload described here instead of regular audio packets. The gateway
likely has the necessary digital signal processors and algorithms, as
it often needs to detect DTMF, e.g., for two-stage dialing. Having
the gateway detect tones relieves the receiving Internet end system
from having to do this work and also avoids that low bit-rate codecs
like G.723.1 render DTMF tones unintelligible. Secondly, an Internet
end system such as an "Internet phone" can emulate DTMF functionality
without concerning itself with generating precise tone pairs and
without imposing the burden of tone recognition on the receiver.
Posted by sagitraz
Posted by ravi_195
DTMF digits, telephony tones, and telephony signals
– Two payload formats
– 8 kHz clock by default
– Audio redundancy coding for reliability
Format 1: reference pre-defined events
– 0 - 9 * # A - D Flash [17]
– Modem and fax tones [18]
– Telephony signals and line events [43]
dial tones, busy, ringing, congestion, on/off hook …
– Trunk events [44]
– Specified through identifier (8-bit value), volume, duration
Format 2: specify tones by frequency
– One, two, or three frequencies
– Addition, modulation
– On/off periods, duration
– specified through modulation
Posted by george99
DTMF over RTP: once media is established if u want to convay some info SIP uses RFC2833 where u can send some digits to other party using RTP Packets...
Posted by SIP
-