Browse Prior Art Database

RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (RFC2833)

IP.com Disclosure Number: IPCOM000003432D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 24 page(s) / 64K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

H. Schulzrinne: AUTHOR [+2]

Abstract

This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 4% of the total text.

Network Working Group H. Schulzrinne

Request for Comments: 2833 Columbia University

Category: Standards Track S. Petrack

MetaTel

May 2000

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 Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This memo describes how to carry dual-tone multifrequency (DTMF)

signaling, other tone signals and telephony events in RTP packets.

1 Introduction

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 [1]

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