RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals

Publisher

IETF / RFC Editor

URL

https://www.rfc-editor.org/rfc/rfc4733.html

Published

2006-12-01

Updated

unknown

Accessed

2026-09-24

HTTP status

200

License

IETF Trust legal provisions (BCP 78); no-redistribution; short excerpts and locators only

Source notes citing this source

• The default RTP clock rate for the telephone-event payload is 8000 Hz, which can be redefined when the dynamic payload type is assigned. in context
• RFC 4733 maps DTMF digits 0-9 to event codes 0-9, star to 10, pound to 11, and A-D to 12-15. in context
• The telephone-event payload format has no static RTP payload type number; the payload type is assigned dynamically and signalled out-of-band (for example in SDP). in context
• The final (E-bit) packet for each telephone event and each segment SHOULD be sent a total of three times at the source's update interval. in context
• If no 'events' fmtp parameter is received, an RFC 4733 sender SHOULD assume the peer supports DTMF events 0-15 and no other events. in context
• The first RTP packet for a telephone event MUST have the marker (M) bit set. in context
• RFC 4733 recommends that a gateway render only the telephone-event payload once it is received, because the concurrent audio may contain spurious tones introduced by compression. in context
• If an event lasts beyond the maximum duration field value 0xFFFF, the sender MUST send a packet reporting that maximum without the E bit and continue the event in a new segment. in context
• Payload type 101 for telephone-event is a common vendor default rather than a value fixed by the standard, so a far end may legitimately negotiate a different dynamic value. inferred in context
• RFC 4733 places the duty to avoid double detection mainly on the receiving gateway; the checked sections contain no requirement that a sender mute in-band tones while sending events, so duplicate-digit protection cannot be assumed from the sender. inferred in context
• RFC 4733, published December 2006 on the Standards Track, obsoletes RFC 2833. in context
• The RFC 4733 payload format for named telephone events is designated 'telephone-event' with media type audio/telephone-event. in context
• RFC 4733 allows a source to choose its own spacing for event update packets and recommends 50 ms. in context
• The RFC 4733 volume field expresses power level for tone events from 0 to -63 dBm0. in context
• Because RFC 4733 DTMF support is negotiated per call in SDP, a DTMF acceptance test is only meaningful if it covers both inbound and outbound calls and every codec the trunk may negotiate. inferred in context
• RFC 4733 says DTMF digits 0-9, * and # are commonly supported and that digits A through D are less frequently encountered. in context
• In RFC 4733 the DTMF digits 0-9 are event codes 0-9, * is event code 10, # is event code 11 and A-D are event codes 12-15. in context
• In the RFC 4733 payload, the E (end) bit set to one marks the packet that contains the end of the event. in context
• RFC 4733 says the sender SHOULD send the final packet of each event three times, at the interval it uses for updates. in context
• RFC 4733, published December 2006, obsoletes RFC 2833 as the specification for the RTP telephone-event payload used to carry DTMF. in context
• Under RFC 4733, the events an endpoint supports are declared in SDP with an fmtp line on the telephone-event payload type, for example a range 0-15 covering the DTMF events. in context

Cite this source record

APA

WarmTransfer. (2006, December 1). RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-4733-telephone-events

BibTeX

@misc{warmtransfer-rfc-4733-telephone-events,
  title  = {RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals},
  author = {{WarmTransfer}},
  year   = {2006},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-4733-telephone-events},
  note   = {IETF / RFC Editor, accessed 2026-09-24}
}