RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (RFC2833)
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
H. Schulzrinne: AUTHOR [+2]
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
Network Working Group H. Schulzrinne
Request for Comments: 2833 Columbia University
Category: Standards Track S. Petrack
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This memo describes how to carry dual-tone multifrequency (DTMF)
signaling, other tone signals and telephony events in RTP packets.
This memo defines two payload formats, one for carrying dual-tone
multifrequency (DTMF) digits, other line and trunk signals (Section
3), and a second one for general multi-frequency tones in RTP 
packets (Section 4). 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.
In the "RTP trunk" application, RTP is used to replace a normal
circuit-switched trunk between two nodes. This is particularly of
interest in a telephone network that is still mostly circuit-
switched. In this case, each end of the RTP trunk encodes audio
channels into the appropriate encoding, such as G.723.1 or G.729.
However, this encoding process destroys in-band signaling information
which is carried using the least-significant bit ("robbed bit
signaling") and may also interfere with in-band signaling tones, such
as the M...