SIP DTMF troubleshooting starts with one distinction: working voice does not prove working keypad signaling. DTMF means dual-tone multifrequency, the signaling behind telephone keypad presses. A business call may sound clear while an automated menu ignores every digit. Other failures produce doubled digits, missed presses, or unreliable conference access.
This guide focuses on digit transport after a call connects, rather than menu routing or voicemail credentials. The goal is to find where a valid press disappears or changes. Compare the phone, phone system, and provider before changing settings across the business.
Identify Which Keypad Presses Fail
Start with a controlled call to a test menu you own or have permission to use. Avoid payment systems, emergency numbers, and repeated attempts against accounts with lockout rules. Never use real access codes during packet collection.
Record the failing direction and destination. An internal menu tests a different path from a provider-hosted conference bridge.
- Does one phone fail, or do all extensions fail?
- Do internal menus work while external menus ignore digits?
- Do outside callers reach your menu but cannot select options?
- Does the issue begin after hold, transfer, or a route change?
- Do presses disappear, repeat, or fail only when entered quickly?
Use a short, known digit sequence and record the expected response. Note the timestamp, time zone, extension, destination, and call identifier. Repeat from a known-working phone where possible.
A keypad beep from the handset only proves local feedback. It does not prove that the phone sent a usable digit.
Compare the Three DTMF Transport Methods
SIP, or Session Initiation Protocol, establishes and manages calls. Keypad signals can travel through SIP messages, through media packets, or within the voice audio itself.
RFC4733 Telephone Events
RFC4733 represents each digit as a named event within RTP, the Real-time Transport Protocol used for call media. The event travels separately from encoded speech, although both commonly share the same media transport.
Many interfaces still call this method RFC2833, referencing the older specification. Check the product documentation instead of assuming different labels mean incompatible methods.
Endpoints negotiate telephone-event support through SDP, the Session Description Protocol carried in SIP messages. They must agree on event capabilities and interpret the negotiated payload correctly.
This method avoids relying on audio tone detection. However, packet loss, incorrect negotiation, or faulty event handling can still break it.
SIP INFO
SIP INFO carries digit information in SIP requests within an established call. Unlike RFC4733, it follows the signaling path rather than the RTP media path.
Both peers must support the same INFO format and behavior. A phone offering an INFO option does not prove that the provider accepts it. A successful SIP response also does not prove that the destination application acted on the digit.
In-Band DTMF
In-band DTMF sends audible tones inside the voice stream. The receiver must recognize those tones and convert them into digits.
G.711 is generally the preferred codec when a service requires in-band tones. A codec converts voice into digital data and back. Speech-focused compression, audio processing, and packet loss can distort tones enough to prevent detection.
Even with G.711, in-band signaling is not automatically reliable. Confirm the full path, including gateways and any codec conversion.
Trace DTMF Across Each SIP Call Leg
A PBX, or private branch exchange, often creates separate call legs between the phone and provider. A trunk is the connection between the PBX and that provider. Each leg can negotiate different codecs and digit methods.
Map the actual route: phone, PBX, any session border controller, provider, and destination. A session border controller manages SIP connections at a network boundary.
Compare these settings at each boundary:
- The phone account’s DTMF mode.
- Accepted and transmitted methods on the PBX extension.
- The trunk’s configured method and provider requirements.
- The negotiated audio codec and telephone-event capabilities.
- Any gateway that converts between signaling methods.
Different methods on separate legs can work if the PBX supports conversion and handles the necessary traffic. Do not assume it translates every combination automatically.
Direct media lets endpoints exchange media without passing it through the PBX. That arrangement changes where you can observe or convert digits. If voice also disappears, use a separate media-path diagnostic sequence rather than treating everything as a keypad fault.
Inspect Negotiation Before Changing Codecs
For RFC4733, inspect the SDP offer and answer for the failing call leg. Look for telephone-event and its associated payload mapping.
An illustrative mapping is a=rtpmap:101 telephone-event/8000. Here, 101 identifies a payload type and 8000 identifies its clock rate. Payload 101 is not universal. Read the negotiated mapping rather than forcing that number everywhere.
Also examine any fmtp event range. Decimal digits use events 0 through 9; star and pound use 10 and 11. Confirm support for the keys your test requires.
Check these points:
- Did both peers negotiate telephone-event support?
- Does the outgoing event use the correct payload mapping for that leg?
- Do the event clock rate and duration interpretation match?
- Did a later offer and answer change the media details?
For SIP INFO, inspect the request body, content type, response, and peer documentation. For in-band tones, inspect the actual audio path and negotiated codec.
If negotiation prevents the call from connecting, consult the SIP 488 negotiation guide. That is a different failure stage.
Check Transcoding and Endpoint Behavior
Transcoding converts audio from one codec to another. It can damage in-band tones, especially across speech-compressed formats. RFC4733 events are not speech audio, but a media gateway must still preserve or correctly translate them.
Compare a working call with a failing call. A different provider route may introduce conversion that the working route avoids.
On phones and softphones, review the active account settings rather than only global defaults. Provisioning templates can overwrite a manual change after a reboot or scheduled update.
Avoid assuming that an automatic DTMF mode chooses the best method. Its behavior depends on the implementation and negotiated capabilities. Consult the official Asterisk documentation for the installed channel driver and its DTMF options.
Duplicate digits can occur when equipment sends both audible tones and separate events, and the receiver detects both. However, repeated RFC4733 packets can belong to one event. Redundant end packets help tolerate loss; they do not automatically indicate repeated keypad presses.
For intermittent misses, compare event duration, spacing, packet loss, and receiver requirements. Do not compensate with arbitrary timing changes before locating the failing boundary.
Capture One Call and Make One Controlled Change
Useful SIP DTMF troubleshooting compares evidence on both sides of a boundary. Capture one authorized test call near the PBX, then check its extension and trunk legs.
Packet captures and detailed logs can expose conversations, numbers, and entered digits. Restrict access, limit collection time, and follow your retention rules. Encryption may prevent ordinary captures from exposing signaling or media content. Prefer authorized endpoint diagnostics instead of disabling encryption.
- Save the current settings and define a rollback step.
- Run the known test sequence without changing anything.
- Find the digit leaving the phone or entering the PBX.
- Check whether the PBX emits the expected signal toward the provider.
- Change one setting only when evidence supports that change.
- Repeat the same test, then check a previously working route.
If the PBX receives the event but sends nothing onward, investigate its handling or conversion. If the correct event leaves the trunk, request provider-side evidence. Local transmission alone does not prove remote receipt.
Verify Provider Expectations and Document the Fix
Ask the provider which DTMF method it expects on the affected service. Confirm supported codecs, INFO formats where relevant, and any digit-duration requirements. Expectations may differ between services or routes.
Supply timestamps, call identifiers, the affected direction, negotiated details, and sanitized evidence. Explain whether the failure affects every destination or only one external menu.
Close the test with internal and external menus, repeated digits, star, and pound where supported. Include hold or transfer if either triggered the original issue. Confirm that provisioning preserves the intended settings.
SIP DTMF troubleshooting should finish with a documented failing boundary and a repeatable acceptance test. When encrypted paths, provider conversion, or production risks complicate the work, professional remote assistance may help. Tech Rescue Ops LLC offers VoIP and PBX support for controlled diagnosis and coordinated provider escalation.