SIP Trunk DTMF Issues Jamaica: Why Your IVR Isn't Recognising Caller Key Presses

When Pressing 1 Does Absolutely Nothing

A caller rings your office. Your auto-attendant answers and says "Press 1 for accounts, press 2 for support." The caller presses a key. Nothing happens. The IVR repeats itself. They press again. Still nothing. After two or three attempts they hang up, and you have no idea the call failed — it appeared to answer fine on your end.

This is a DTMF problem. Dual-Tone Multi-Frequency (DTMF) signalling is how telephone keypads communicate with phone systems. Every key press generates a pair of audio tones that your PBX decodes and acts on. On traditional analogue lines this worked without thinking about it, because the tones were always embedded in the same audio path the voice used. On SIP trunks, those tones can be intercepted, mangled, or quietly discarded before they ever reach your IVR — and the fix depends on which failure mode you're dealing with.

The Three DTMF Methods on a SIP Trunk

SIP trunks can carry DTMF in three fundamentally different ways. Almost every DTMF outage starts because your PBX and your carrier are configured for different methods and neither side tells you.

In-Band Audio
The tones are encoded as raw audio inside the G.711 or G.729 voice stream — the same way an analogue line works. This is simple, but it fails the moment any device in the path re-compresses, re-samples, or transcodes the audio. On a modern SIP trunk with media traversing Jamaica's mixed fibre-and-LTE last mile, in-band is the least reliable choice and should only be used as a last resort.

RFC 2833 / RTP Events (Payload Type 101)
The key press is extracted from the voice stream and transmitted as a dedicated RTP packet with payload type 101. Voice and tone travel separately, so transcoding the voice audio has zero effect on the digit. This is the safest method on SIP trunks and the correct default for most modern cloud PBX platforms including WOCOM's infrastructure.

SIP INFO
The digit is sent inside a SIP INFO message — a signalling-layer event that is completely independent of the media path. It is immune to transcoding but requires both your PBX and carrier to negotiate it correctly, and not all carriers support it. It also adds a small round-trip signalling delay that can cause problems with rapid multi-digit entry on payment or PIN collection flows.

Most Jamaican businesses should be running RFC 2833. If your SIP trunk is configured for RFC 2833 and your PBX is configured for SIP INFO — or vice versa — the PBX receives an event type it does not recognise and silently discards every digit. The call stays connected. The IVR keeps prompting. Nothing ever moves.

Why DTMF Breaks Even When Both Sides Agree

Configuration mismatch is the most common cause, but it is not the only one. Several network conditions can break DTMF even after you have confirmed that both endpoints agree on RFC 2833.

SIP ALG on your router. SIP Application Layer Gateway is a feature on many routers and firewall appliances — including models supplied by Jamaican ISPs — that inspects and rewrites SIP packets as they pass through NAT. It frequently corrupts the DTMF payload type in the SDP negotiation, causing the two endpoints to believe they have agreed on a method when the rewritten packet says something different. The solution is to disable SIP ALG completely. We covered SIP ALG in a dedicated post; the short version is that it almost always causes more problems than it solves on a modern SIP trunk.

Codec transcoding. If your PBX negotiates G.729 with the carrier but your trunk arrives as G.711, an intermediate transcoder steps in. That transcoder may handle in-band tones or it may strip them. RFC 2833 packets are immune to this — but only if the codec negotiation does not accidentally trigger an in-band fallback. Check that your PBX does not list in-band as a DTMF fallback option.

Network congestion and jitter. DTMF RTP events are short packet bursts. On a congested last-mile connection — common during peak hours in Kingston and Montego Bay commercial districts — those packets can arrive out of order or exceed the PBX's jitter buffer threshold. The PBX sees a late or incomplete event and discards it. Setting your jitter buffer to 60–80 ms and applying QoS priority to RTP traffic reduces this significantly.

Payment gateways and PIN collection. IVRs that collect card numbers or account PINs are the highest-stakes DTMF flows in any business. A payment processor's voice gateway expecting RFC 2833 but receiving in-band audio will fail silently on every transaction, making it look like customers are abandoning the IVR when the system is simply not decoding their input. If your payment IVR has an unusually high abandonment rate, start here.

How to Diagnose the Problem Yourself

Before calling your SIP trunk provider, collect the following. It will cut your support call from an hour to ten minutes.

• Capture a SIP trace for a failing call. Your PBX or WOCOM's portal can export a SIP ladder diagram or pcap file. Look at the SDP offer and SDP answer. Both sides should show a=rtpmap:101 telephone-event/8000. If one side shows a different payload type, you have found the mismatch.
• Test with a software phone. Install Zoiper or Linphone on a laptop, configure it manually for RFC 2833, and call your IVR. If DTMF now works, the fault is in your desk phone provisioning template, not the trunk.
• Check the router for SIP ALG. On Mikrotik devices look under IP → SIP Helpers. On Ubiquiti EdgeRouters check the firewall ALG section. Disable and reboot.
• Call the DTMF echo extension. Most PBX platforms include a built-in DTMF test extension — often *43 — that reads back every digit it receives. Dial it and press keys. This tells you immediately whether the problem is on the inbound trunk path or inside the PBX itself.

Configuring DTMF on Common PBX Platforms

On FreePBX / Asterisk, DTMF mode is set per trunk. For a chan_sip trunk set dtmfmode=rfc2833. For a PJSIP trunk, set dtmf_mode=rfc2833 in the endpoint configuration. Avoid setting it to auto — auto can negotiate down to in-band during a re-INVITE.

On 3CX, go to the SIP Trunk → Advanced tab → DTMF Mode and select RFC 2833. If your deployment uses the built-in SBC, ensure the SBC-side DTMF mode matches; a mismatch between the SBC and the trunk leg is a common source of intermittent failures that appears only on specific call flows.

On WOCOM's hosted Cloud PBX, DTMF mode is managed at the platform level to match our SIP infrastructure. If you are experiencing DTMF failures on a WOCOM Cloud PBX line, the cause is almost always SIP ALG on the customer-side router or a misconfigured third-party device — such as an analogue gateway or on-premise legacy PBX — sitting between your handsets and the cloud.

For analogue phones connected through an ATA, remember that the ATA itself must convert the in-band tones from the analogue phone into RFC 2833 before sending them to the SIP trunk. If the ATA is underpowered or misconfigured, digit-dropping is common during multi-digit sequences such as extension numbers and account PINs. Each ATA model has its own DTMF sensitivity setting — the correct value is usually in the range of –10 to –15 dBm.

Get Your IVR Working Correctly — and Keep It That Way

DTMF problems are usually a one-time configuration fix, but they can silently reappear after a router firmware update re-enables SIP ALG, or after a carrier network change alters the media path. Include a DTMF test call — dial the echo extension and press every digit — in your standard change-management checklist whenever you update your router, PBX, or trunk configuration.

If your IVR has stopped collecting key presses, your payment gateway is dropping callers at the PIN entry stage, or you are seeing unexplained IVR abandonment, WOCOM's technical team can run a live SIP trace and isolate the exact failure point quickly. We support SIP trunks and Cloud PBX deployments across Kingston, Montego Bay, and every parish in Jamaica.

Call us at 876-275-0431 or visit wocomenterprise.com/contact to book a technical review. Bring the SDP from one failing call and we can usually identify the root cause in the first five minutes.