RFC 2833 / RTP Events
RFC 2833, now superseded by RFC 4733, defines how DTMF digits are sent as dedicated RTP event packets rather than as audio tones. It is the default DTMF method for most SIP devices.
Published 8 November 2026 · 1 min read · By SpaGreen Creative
Short answer
RFC 2833, superseded by RFC 4733, defines the telephone-event RTP payload that carries DTMF digits as structured packets inside the media stream instead of as audible tones.
RFC 2833 was the original specification for sending keypad digits as RTP events. It has been replaced by RFC 4733, but the old number stuck and appears in most PBX configuration options, for example dtmfmode=rfc2833 in Asterisk. The two documents describe the same mechanism; RFC 4733 clarifies details and fixes ambiguities.
The idea is to define a special RTP payload type called telephone-event. When the user presses a key, the sender transmits a few small RTP packets stating which digit was pressed, how loud it would be and how long it lasted, instead of encoding the actual tones as audio. The receiver either regenerates the tone or passes the digit to its application directly.
This has two advantages. Compressed codecs cannot distort the digit because no tone is ever encoded. And a PBX can detect digits reliably without analysing audio, which saves processing and avoids false detections from speech or music.
The payload type number for telephone-event is dynamic, usually 101, and is announced in SDP with an a=rtpmap:101 telephone-event/8000 line. Both ends must advertise it. If the PBX expects RFC 2833 but the device sends in-band tones, or the reverse, menu navigation and feature codes fail.
SIPdia uses RFC 2833 RTP events for DTMF.
Sources and further reading
This article is published by SpaGreen Creative, the maker of SIPdia. Product names mentioned belong to their owners. Where it describes other software, treat the steps as general guidance and check the official documentation linked above.
