What DTMF methods do explosion-proof telephones support?

DTMF seems simple until a gate does not open or an Interactive Voice Response (IVR) ¹ misses digits during an emergency. In hazardous sites, that small failure becomes a real delay.

Most explosion-proof SIP telephones support at least one reliable DTMF method: RFC 2833/4733 RTP events (the default in many PBXs), SIP INFO (common in some enterprise setups), and in-band tones (mainly for G.711). The best choice depends on codecs, SBCs, and gateways.

How to choose a DTMF method that stays reliable across PBX, SBC, and gateways

DTMF is a signaling problem, not a keypad problem

The keypad can be perfect and the DTMF can still fail. The weak points are usually in the media path:

• codec compression that distorts tones

• transcoding in SBCs or gateways

• early media announcements that change the audio path

• SRTP/TLS settings that change what the PBX expects

So the goal is to pick one method that fits your call path and keep it consistent.

A simple selection rule that works in industrial deployments

In most industrial networks, the most stable approach is:

• Use RFC 4733 ² (RFC 2833 legacy name) RTP events for normal SIP calls and IVRs.

• Use SIP INFO only when the PBX requires it and you can keep the signaling path consistent.

• Use in-band only when the G.711 codec ³ is used end-to-end and no transcoding happens.

Why “it works in the lab” often fails on site

Industrial calls often pass through:

• carrier SBCs

• inter-site SBCs

• paging gateways

• analog FXO/FS gateways for legacy systems

Each hop can change how DTMF is treated. The safest plan is to define DTMF method per trunk or per line, then prove it with a call matrix that includes the worst-case path.

A quick comparison table

Method	Where digits travel	Best with	Main risk	Most common use
RFC 4733 RTP events	RTP (out-of-band events)	any voice codec	wrong payload type or SBC handling	PBX/IVR, carrier trunks
SIP INFO	SIP signaling messages	stable SIP signaling path	not passed by all SBCs, timing issues	some enterprise PBXs
In-band audio	audible tones in RTP audio	G.711 end-to-end	fails with compression/transcoding	legacy gateways, simple paths

A short personal note from projects: the fastest fix is often not “change the phone.” It is aligning PBX trunk settings so the SBC does not translate DTMF twice.

Now the next sections answer the four tender-level questions: supported methods, interoperability, tuning parameters, and secure workflows.

This is also where door release and paging features become predictable.

Are RFC 2833/4733 RTP events, SIP INFO, and in-band audio tones all available and selectable per line?

DTMF that cannot be switched per line causes problems in mixed networks. One site may require SIP INFO. Another site may require RFC 4733. A single global mode becomes a trap.

Yes in most modern SIP designs. Many explosion-proof SIP telephones let you select DTMF mode per SIP account or per line profile: RTP events (RFC 4733/2833), SIP INFO, or in-band. Some models also support “auto” behavior, but fixed per-line settings are safer for industrial fleets.

What “selectable” should look like on the phone

A procurement-ready phone should provide:

• DTMF mode per SIP account (Line 1, Line 2)

• payload type setting or “dynamic negotiated” support for RTP events

• INFO content type selection if needed

• in-band enable only when using G.711 and compatible call paths

• logging that shows which DTMF method was used during a call

When a phone hides these controls, troubleshooting becomes slow.

RFC 2833 vs RFC 4733 wording

In practice, many UIs still say “RFC 2833,” even though RFC 4733 is the updated specification name used today. The behavior is the same in most deployments: DTMF digits are sent as RTP events, not as audio.

When “Auto” mode is risky

Auto can sound convenient. It can also cause inconsistent behavior if:

• one trunk prefers INFO and another prefers RTP events

• the call crosses SBCs that strip INFO

• a paging gateway only accepts one method

In industrial operations, consistency is worth more than convenience. A stable per-line mode avoids surprise behavior during maintenance windows.

A per-line configuration pattern that scales

Line type	Recommended DTMF mode	Why it stays stable
PBX internal line	RFC 4733 RTP events	works across most codecs
Carrier/SBC trunk line	RFC 4733 RTP events	common expectation on trunks
Enterprise PBX that mandates INFO	SIP INFO	matches PBX policy
Legacy analog gateway path	in-band (G.711 only)	tones survive only with G.711

A good vendor answer should confirm “per line” selection, not only “supported.” That single detail is what makes multi-site deployments smooth.

Will DTMF work with PBXs and IVRs—Asterisk/FreePBX, 3CX, CUCM, Avaya, and carrier SBCs?

DTMF compatibility is not only brand-to-brand. It is the full call path. Asterisk can accept RTP events, but the carrier trunk may convert them. CUCM can accept DTMF, but a gateway may translate it again.

Yes, DTMF works well with major PBXs and IVRs when you align one method end-to-end. RFC 4733 RTP events is the most widely interoperable choice across Asterisk/FreePBX, 3CX, CUCM, Avaya, and many carrier SBCs. SIP INFO works when explicitly required and when SBCs pass INFO reliably.

What typically works best by platform

In mixed industrial deployments, the following patterns are common:

• Asterisk/FreePBX: RFC 4733 is the usual stable choice. INFO can work but needs clear policy.

• 3CX: RTP events are common and reliable when trunks are aligned.

• CUCM: RTP events are widely used. INFO is used in some enterprise interop cases.

• Avaya: RTP events are common, and INFO can appear in some integrations.

• Carrier SBCs: RTP events are the default expectation in many SIP trunk deployments.

The main point is not the brand. The main point is avoiding mixed methods across a single call path.

The top three interop failure patterns

1) Transcoding plus in-band

A compressed codec or transcoding step can distort in-band DTMF. This is why in-band is usually reserved for G.711 end-to-end.

2) SBC stripping SIP INFO

Some Session Border Controllers (SBCs) ⁴ normalize or block INFO messages. If a phone uses INFO and the SBC drops it, digits vanish.

3) Double conversion

A PBX converts the SIP INFO method ⁵ to RTP events, then an SBC converts again, causing timing issues.

A simple test matrix that prevents surprises

Before rollout, run these call tests:

• Phone → PBX IVR menu (digits 0–9, *, #)

• Phone → trunk → carrier IVR (if used)

• Phone → gateway → analog IVR (if any legacy exists)

• DTMF during SRTP calls and during early media announcements

A practical interoperability table

Environment	Recommended DTMF	Why
Pure SIP inside plant	RFC 4733	simplest and most consistent
SIP trunk with carrier	RFC 4733	matches trunk expectations
Enterprise policy mandates INFO	SIP INFO	avoids PBX mismatch
Legacy analog path	in-band on G.711	gateway-friendly
Paging gateways	usually G.711 + RFC 4733	many paging devices stay basic

A small on-site habit helps: capture one RTP stream during a failing case and verify if DTMF events are present. That tells you whether the issue is the phone, the PBX, or the SBC.

How to configure payload type, event duration, and level to avoid clipping across codecs, transcoders, and gateways?

DTMF failures often look random. In reality, they come from a few predictable tuning mismatches. A short event duration, a wrong payload type, or aggressive audio processing can break digit detection.

Use negotiated dynamic payload types for RFC 4733 when possible, keep event duration long enough for IVR detection, avoid extreme DTMF levels, and disable audio processing that clips tones. In-band DTMF should be limited to G.711 and should avoid noise suppression that distorts tones.

Payload type (PT) for RFC 4733

RTP events use a dynamic payload type negotiated in SDP. Many systems use 101 by habit, but it is not a universal fixed value. The safest approach is:

• allow the PBX to negotiate the payload type

• avoid hard-coding PT unless a gateway requires a specific number

If hard-coding is needed, keep it consistent on both ends of the trunk.

Event duration and digit reliability

IVRs need enough time to detect a digit. If the phone sends very short events, some systems miss them. Practical rules that usually work:

• do not use ultra-short digit durations

• allow a short inter-digit gap

• for door release or safety codes, favor reliability over speed

DTMF level and audio processing

DTMF “level” is tricky because:

• too low can be missed by detectors

• too high can clip and create harmonics that confuse detectors

• AGC, noise suppression, and echo cancellation can change the tone shape

For industrial phones, the clean approach is:

• keep DTMF level near the phone’s default

• avoid “boosting” unless a specific gateway proves it is needed

• if in-band is required, reduce aggressive noise suppression and avoid heavy audio enhancement modes

Codec and transcoder interaction

• RFC 4733 is codec-independent because digits are events, not audio.

• In-band is codec-sensitive, and compressed codecs can break it.

So if your environment uses Opus or G.729 or any transcoding, RTP events are usually safer.

A tuning checklist table

Setting	Safe baseline	When to change it	Risk if wrong
RFC 4733 payload type	negotiated	only for special gateways	digits not recognized
Digit duration	moderate, not short	only if IVR demands it	missed digits
Inter-digit gap	small gap	only for high-speed dialing	merged digits
DTMF level	default	only after measured failures	clipping or low detect
In-band mode	G.711 only	legacy analog needs	digits fail on compression

A field story placeholder fits here: a tunnel project had “random” door release failures. The real cause was a transcoding hop plus in-band DTMF. Switching that trunk to RFC 4733 made it stable on day one.

Can DTMF actions drive door release, IVR menus, and paging while keeping TLS/SRTP security, audit logs, and compliance?

DTMF is often tied to physical actions. That means it becomes a security control. If the DTMF path is weak, door release becomes a risk, and audit trails become incomplete.

Yes. DTMF can control IVR menus, trigger door release via PBX logic or phone relay mapping, and activate paging workflows. You can keep TLS/SRTP security by using SIP over TLS and SRTP for media, and you can keep audit trails by logging DTMF-triggered actions at the PBX or controller rather than relying only on the endpoint.

Door release: three safe patterns

1) PBX/Access controller driven

DTMF is detected by the PBX or an access control application. The controller then triggers the door relay. This is the most auditable method, because the system can log who pressed what and when.

2) Phone local relay mapping

Some industrial phones have relay outputs. They can map a DTMF code to a relay pulse. This is fast and simple for local control. It must be protected by permissions so random callers cannot open a door.

3) SIP/HTTP API workflow

DTMF triggers an IVR or application that calls an API to activate a relay module. This is flexible and works well in integrated sites with SCADA or VMS.

Paging and PAGA triggers

DTMF can be used to:

• join a paging group

• select a paging zone through an IVR

• trigger a PAGA workflow through a controller

For paging, it is important to keep codec policy simple. Many paging chains are happiest on G.711. So the safest approach is DTMF by RFC 4733 and paging audio by G.711 when gateways are involved.

Keeping TLS/SRTP and compliance strong

Security and compliance usually require:

• SIP over TLS for signaling

• SRTP (Secure Real-time Transport Protocol) ⁶ for media

• strict ACLs so phones can only reach PBX, provisioning, and time servers

• role-based permissions on who can trigger door release or priority pages

• Transport Layer Security (TLS) ⁷ for encrypting communications

DTMF events sent as RTP events can still be protected by SRTP when SRTP is enabled. SIP INFO digits can be protected by TLS. The key is that the policy must be consistent across the call path, including SBCs.

Audit logging: log actions, not just digits

A good audit record should show:

• caller identity (extension or certificate identity)

• target system (door A, zone B, IVR menu)

• action timestamp

• success or failure result

Logging only “DTMF digit received” is not enough for many industrial compliance programs. Logging the outcome is what matters.

Use case	Best DTMF method	Best security posture	Best audit point
IVR navigation	RFC 4733	TLS + SRTP + QoS	PBX/IVR logs
Door release	RFC 4733 or INFO	strict permission + whitelist	access controller logs
Paging zone select	RFC 4733	role-based paging rights	PBX paging logs
Emergency workflows	RFC 4733	priority queues + whitelists	centralized incident log

A simple policy improves safety: never allow a door release action from an unknown caller ID. Use whitelists and require authenticated lines. That aligns well with industrial change control and reduces risk.

Conclusion

Most Ex SIP phones support RFC 4733, often SIP INFO, and sometimes in-band. Use RTP events as the default, keep paging on G.711, and log actions centrally for audit.

---

Footnotes