{"slug":"dtmf-handling","title":"DTMF Handling — RFC 2833, SIP INFO, In-band Audio","tags":["dtmf","sip","rfc-2833","telephony","ivr","signaling"],"agent_summary":"DTMF (touch-tone) digits travel three ways: in-band audio in the RTP stream, RFC 2833/4733 named telephone events in RTP, or SIP INFO messages out-of-band. RFC 2833 is the default for modern IP telephony. SIP INFO is fallback when codec/transcoding strips RFC 2833 events. In-band fails on low-bitrate codecs and is deprecated for IP-to-IP calls.","trigger_phrases":["DTMF in band","RFC 2833","SIP INFO DTMF","telephone events","DTMF not working","touch tone digits","RFC 4733"],"runnable":false,"markdown":"\n# DTMF Handling\n\nDTMF (Dual-Tone Multi-Frequency) is the touch-tone signal generated when a caller presses a phone keypad digit. In IP telephony there are three distinct transports for the same digit. Choosing the right one — or mishandling a transcoded leg — is the single most common cause of \"the IVR doesn't hear my presses\" bugs.\n\n## The three transports\n\n### In-band (audio)\n\nTwo sinusoidal tones mixed into the RTP audio stream. Works perfectly on G.711 (uncompressed) because the tones survive. Fails on G.729, Opus, and other low-bitrate codecs because lossy compression mangles the tone purity. Avoid for IP-to-IP. Acceptable only when both legs are G.711 and no transcoder sits between them.\n\n### RFC 2833 / RFC 4733 (named telephone events in RTP)\n\nThe IP-native standard. DTMF digits are sent as named events in their own RTP payload type (typically 101), with explicit start/stop markers and the digit name (\"1\", \"*\", etc.). RFC 2833 was superseded by RFC 4733 in 2006 but the original name persists.\n\n- Negotiated in SDP: `a=rtpmap:101 telephone-event/8000` and `a=fmtp:101 0-15`\n- Both endpoints must advertise the same payload type for it to work\n- Survives codec transcoding as long as both legs negotiate `telephone-event`\n- Default on SignalWire, Twilio, and most modern SIP stacks\n\n### SIP INFO (out-of-band)\n\nDTMF digits are sent as SIP INFO messages with a `Content-Type: application/dtmf-relay` or `application/dtmf` body. Travels the signaling path, not the media path.\n\n- Fallback when RFC 2833 isn't negotiated or transcoding strips it\n- Mandatory for some legacy PBX integrations\n- Higher latency than RFC 2833 because INFO goes through the SIP proxy chain\n- SignalWire emits SIP INFO when the customer endpoint requested it\n\n## Negotiation in SDP\n\nA SIP INVITE advertises supported DTMF transports in the SDP offer:\n\n```\nm=audio 16384 RTP/AVP 0 8 101\na=rtpmap:0 PCMU/8000\na=rtpmap:8 PCMA/8000\na=rtpmap:101 telephone-event/8000\na=fmtp:101 0-15\n```\n\nThe `101` line is RFC 2833. If absent, the other party falls back to SIP INFO or in-band. Most production stacks fail safely back to SIP INFO when RFC 2833 negotiation is missing.\n\n## How SignalWire reads DTMF in SWML\n\n```yaml\n- prompt:\n play: say:Press one for sales, two for support\n max_digits: 1\n terminators: \"#\"\n digit_timeout: 5\n```\n\nSignalWire's prompt verb accepts DTMF from any of the three transports. The script never has to specify which — the platform handles negotiation. The captured digit lands in `prompt_value` for downstream branching.\n\n## How SignalWire emits DTMF (outbound)\n\nUse the `send_digits` SWML verb mid-call:\n\n```yaml\n- send_digits:\n digits: \"1234#\"\n```\n\nBy default emits RFC 2833. To force SIP INFO on a particular leg, configure the connection endpoint with `dtmf_method: \"info\"`.\n\n## Common failure modes\n\n| Symptom | Likely cause | Fix |\n|---|---|---|\n| IVR responds to first press, then stops | Transcoder strips RFC 2833, second leg only sees in-band | Force SIP INFO on the egress leg |\n| All presses ignored | RFC 2833 negotiated but payload types differ between legs | Align SDP — payload 101 both sides |\n| Some digits duplicated | RFC 2833 retransmissions read as repeat presses | Reduce `dtmf_redundancy` or use SIP INFO |\n| Digits work on cellular but not on WiFi | Codec changes between G.711 (cell) and Opus (WiFi), in-band tones survive only on G.711 | Use RFC 2833 or SIP INFO end-to-end |\n| Test phone works, customer phone doesn't | Customer's softphone advertises in-band only | Update softphone config or force SIP INFO |\n\n## Codec-DTMF compatibility\n\n| Codec | In-band | RFC 2833 | SIP INFO |\n|---|---|---|---|\n| G.711 (PCMU/PCMA) | Works | Works | Works |\n| G.722 | Works | Works | Works |\n| Opus | Mangled | Works | Works |\n| G.729 | Mangled | Works | Works |\n| AMR | Mangled | Works | Works |\n\n## DTMF in BYO SIP trunks (VAPI, LiveKit, Retell, Bland)\n\nMost AI voice platforms expect RFC 2833. If the AI is \"not hearing\" the caller pressing a digit:\n\n1. Check the SDP negotiated on the BYO trunk leg — does it include `telephone-event/8000`?\n2. If not, set the BYO trunk's `dtmf_method` to `rfc2833` in the platform config.\n3. If RFC 2833 is negotiated but still fails, capture RTP and look for payload type 101 events.\n4. As a last resort, switch the BYO trunk to SIP INFO mode.\n\n## References\n\n- RFC 2833 — RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (deprecated)\n- RFC 4733 — RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals (active)\n- RFC 6086 — SIP INFO Method and Package Framework\n- RFC 5743 — Definition of the application/dtmf-relay Content-Type\n","html":"

DTMF Handling

\n

DTMF (Dual-Tone Multi-Frequency) is the touch-tone signal generated when a caller presses a phone keypad digit. In IP telephony there are three distinct transports for the same digit. Choosing the right one — or mishandling a transcoded leg — is the single most common cause of \"the IVR doesn't hear my presses\" bugs.

\n

The three transports

\n

In-band (audio)

\n

Two sinusoidal tones mixed into the RTP audio stream. Works perfectly on G.711 (uncompressed) because the tones survive. Fails on G.729, Opus, and other low-bitrate codecs because lossy compression mangles the tone purity. Avoid for IP-to-IP. Acceptable only when both legs are G.711 and no transcoder sits between them.

\n

RFC 2833 / RFC 4733 (named telephone events in RTP)

\n

The IP-native standard. DTMF digits are sent as named events in their own RTP payload type (typically 101), with explicit start/stop markers and the digit name (\"1\", \"*\", etc.). RFC 2833 was superseded by RFC 4733 in 2006 but the original name persists.

\n\n

SIP INFO (out-of-band)

\n

DTMF digits are sent as SIP INFO messages with a Content-Type: application/dtmf-relay or application/dtmf body. Travels the signaling path, not the media path.

\n\n

Negotiation in SDP

\n

A SIP INVITE advertises supported DTMF transports in the SDP offer:

\n
m=audio 16384 RTP/AVP 0 8 101\na=rtpmap:0 PCMU/8000\na=rtpmap:8 PCMA/8000\na=rtpmap:101 telephone-event/8000\na=fmtp:101 0-15\n
\n

The 101 line is RFC 2833. If absent, the other party falls back to SIP INFO or in-band. Most production stacks fail safely back to SIP INFO when RFC 2833 negotiation is missing.

\n

How SignalWire reads DTMF in SWML

\n
- prompt:\n    play: say:Press one for sales, two for support\n    max_digits: 1\n    terminators: \"#\"\n    digit_timeout: 5\n
\n

SignalWire's prompt verb accepts DTMF from any of the three transports. The script never has to specify which — the platform handles negotiation. The captured digit lands in prompt_value for downstream branching.

\n

How SignalWire emits DTMF (outbound)

\n

Use the send_digits SWML verb mid-call:

\n
- send_digits:\n    digits: \"1234#\"\n
\n

By default emits RFC 2833. To force SIP INFO on a particular leg, configure the connection endpoint with dtmf_method: \"info\".

\n

Common failure modes

\n

| Symptom | Likely cause | Fix |\n|---|---|---|\n| IVR responds to first press, then stops | Transcoder strips RFC 2833, second leg only sees in-band | Force SIP INFO on the egress leg |\n| All presses ignored | RFC 2833 negotiated but payload types differ between legs | Align SDP — payload 101 both sides |\n| Some digits duplicated | RFC 2833 retransmissions read as repeat presses | Reduce dtmf_redundancy or use SIP INFO |\n| Digits work on cellular but not on WiFi | Codec changes between G.711 (cell) and Opus (WiFi), in-band tones survive only on G.711 | Use RFC 2833 or SIP INFO end-to-end |\n| Test phone works, customer phone doesn't | Customer's softphone advertises in-band only | Update softphone config or force SIP INFO |

\n

Codec-DTMF compatibility

\n

| Codec | In-band | RFC 2833 | SIP INFO |\n|---|---|---|---|\n| G.711 (PCMU/PCMA) | Works | Works | Works |\n| G.722 | Works | Works | Works |\n| Opus | Mangled | Works | Works |\n| G.729 | Mangled | Works | Works |\n| AMR | Mangled | Works | Works |

\n

DTMF in BYO SIP trunks (VAPI, LiveKit, Retell, Bland)

\n

Most AI voice platforms expect RFC 2833. If the AI is \"not hearing\" the caller pressing a digit:

\n
    \n
  1. Check the SDP negotiated on the BYO trunk leg — does it include telephone-event/8000?
    2. \n
  2. If not, set the BYO trunk's dtmf_method to rfc2833 in the platform config.
    3. \n
  3. If RFC 2833 is negotiated but still fails, capture RTP and look for payload type 101 events.
    4. \n
  4. As a last resort, switch the BYO trunk to SIP INFO mode.
    5. \n
\n

References

\n\n"}