DTMF not working on a SIP trunk: methods and mismatches
A caller presses 1 and the menu does not respond. The call is fine; the digits are being sent in a form the far end is not listening for. There are several ways to carry DTMF over SIP, and both ends of every leg have to agree on one.
The methods
| Method | Where the digit travels | How to recognize it |
|---|---|---|
| RFC 4733 telephone events (often still called RFC 2833) | In the media stream, as special RTP packets | telephone-event in the SDP, usually payload type 101 |
| In-band audio | In the media stream, as the tone itself | Nothing in the SDP. Reliable only with G.711 |
| SIP INFO | In signaling, one message per digit | INFO requests during the call |
| KPML | In signaling, by subscription | SUBSCRIBE and NOTIFY with a kpml event |
| Unsolicited NOTIFY | In signaling | NOTIFY requests with a telephone-event body |
See what was negotiated
Read the SDP in the offer and the answer on each leg. Telephone events are in use only when both contain a line such as a=rtpmap:101 telephone-event/8000. If the offer has it and the answer does not, the far end declined it and the sender falls back to something else, or to nothing.
The common failures
- A different method on each leg. The phone side uses a signaling method and the trunk side expects telephone events. The gateway in the middle converts between them only if both methods are configured on the right dial-peers.
- The default dial-peer. A call that matched no inbound dial-peer on a Cisco gateway has no DTMF relay configured at all.
- Different payload numbers. One side uses 101 and the other 96 or 100. Most devices cope; some need to be told to accept a different number in each direction.
- In-band tones through a compressed codec. G.729 distorts the tone enough that it is not detected.
- Digits sent twice. The tone is sent in the audio and as an event, and the far end counts both.
- Digits that are too short. Some systems ignore an event shorter than a set duration.
Confirm with a capture
In a packet capture, telephone events appear as RTP packets with the event payload type, one burst per key press, with the digit and duration in each packet. If they leave your gateway and the menu still ignores them, take that capture to the far end.
Test every digit, including star and pound. A partial failure usually means a payload or duration problem, not a method mismatch.
Where Workbench helps
PCAP Analyzer detects telephone events in a capture and lists each digit with its timing against the call that carried it. Digits are masked by default, because callers type account numbers and PINs.