Are FSK and DTMF signaling both supported by explosion-proof telephones?

Bad signaling support can turn a certified Ex telephone into a “dead” endpoint. The phone is safe, but calls fail, and the site loses trust fast.

Yes. Most explosion-proof telephones support DTMF dialing. FSK Caller ID support depends on the phone design and the local standard (ETSI or Bellcore), plus correct PBX/gateway settings.

What “supported” really means for Ex telephones: analog vs SIP, and what to specify

Two product families behave very differently

Explosion-proof telephones come in two common types:

• Analog (POTS/FXS): DTMF digits are generated as audio tones. Caller ID can be delivered by the network using FSK ¹ (Bell 202 / V.23) or DTMF-coded CLI, but the phone can only display/record CID if it has a CID decoder and UI.

• SIP (IP phone): Caller ID is carried in SIP signaling. DTMF can be carried in audio (in-band) or out-of-band (RTP events or SIP INFO), depending on configuration.

So “FSK supported” has two meanings:

1) The line can carry FSK caller ID from the exchange or PBX (almost always true on the network side).

2) The phone can decode FSK and present it (only true if the Ex phone includes a CID decoder and the feature is enabled).

ETSI defines on-hook caller ID protocols over the local loop (including FSK and DTMF-based options) for PSTN display services, so it is valid to specify ETSI compliance if the device is designed for it.

What to write in a procurement spec so there is no argument later

A clean spec separates “dialing” from “caller ID”:

• Dialing: DTMF transmitter compliance (levels, twist, timing)

• Caller ID: FSK standard (ETSI V.23 / Bellcore Bell 202), plus Type I (on-hook) and optional Type II (call waiting / off-hook) support

• PBX/gateway settings: required regional profile for CID generation/detection

| Feature line item | What to state | Why it prevents rework |

|—|—|—|

| DTMF dialing | Q.23/Q.24 or ETSI ES 201 235 transmitter requirements | Prevents keypad digits failing through gateways |

| Caller ID (Type I) | ETSI EN 300 659-1 or Bellcore/Telecordia profile | Avoids “CID never shows” disputes |

| Caller ID (Type II) | ETSI EN 300 659-2 and/or Bellcore Type II | Needed if CID during call waiting matters |

| SIP DTMF method | RFC 4733 (2833 compatible) and SIP INFO option | Avoids IVR failures in VoIP paths |

| Test plan | define pre-ring timing and cadence | Stops region-profile mismatches |

This framing keeps the Ex conversation clean. Ex certification is about ignition risk. Signaling support is about interoperability. Both must be correct, but they are validated in different ways.

The next sections answer each of your questions in a way that can be copied into a project spec and FAT checklist.

Is FSK Caller ID compatible with ETSI and Bellcore standards?

CID failures usually look like “sometimes it works.” That happens when the PBX sends one regional format and the phone expects another.

FSK Caller ID can be compatible with ETSI and Bellcore, but only if the PBX/gateway is set to the same standard and the Ex telephone has an FSK decoder (or you accept CID as “not displayed”). ETSI uses V.23-style FSK per EN 300 659-1, while North America commonly uses Bell 202 FSK tied to Telecordia/Bellcore profiles.

How ETSI FSK is delivered on the local loop

ETSI ² EN 300 659-1 describes subscriber line protocol for display services and defines how on-hook data transmission works, including the FSK-based protocol and also legacy DTMF-based options used in some networks.

In many ETSI deployments, the network may use alerting signals such as polarity reversal or a dual tone alert signal before data, then deliver the FSK payload, then ring. This is one reason “ETSI” is not just “FSK.” Timing and alerting behavior matter.

How Bellcore/Bell 202 Caller ID is typically delivered

In North America, Type I Caller ID is commonly transmitted using Bellcore ³ FSK between the first and second ring bursts. Many technical notes and implementations describe this delivery timing because the CPE is on-hook and the quiet window is predictable.

The real compatibility risks in industrial sites

The top failure modes seen on projects:

• PBX/gateway is set to Bellcore, but the local expectation is ETSI (or the opposite).

• The CID is sent before the first ring in some countries. Some gateways expect “between ring 1 and ring 2,” so CID is missed unless settings are changed.

• The Ex phone has no display, so the user expects CID but the product cannot decode it. The line may still carry CID correctly.

A CID selection table that works for procurement

| Site region behavior | What to require on the phone | What to set on PBX/gateway |

|—|—|—|

| Bell 202 between rings | Bellcore/Bell 202 FSK decoder (if CID needed) | Bellcore profile, correct ring timing |

| ETSI V.23 after alert signal | ETSI EN 300 659-1 compatible decoder | ETSI profile, polarity/DT-AS behavior |

| CID before first ring | CID timing support in gateway + phone | enable pre-ring CID handling |

| No display needed | “CID not required” | still set profile for logs if needed |

For Ex projects, the simplest rule is: treat CID as an explicit requirement. If it is required, lock the standard, timing, and test method. If it is not required, do not assume “it will show anyway.”

Are DTMF levels and twist within ITU-T tolerance?

DTMF that “sounds correct” to a human can still fail IVR detection. Small level and twist errors create big failures in low-bitrate paths and noisy plants.

Yes, DTMF can be made fully compliant. ITU-T Q.23 sets core tone requirements such as frequency tolerance and distortion limits, while ETSI ES 201 235 tightens practical transmitter levels and defines twist targets that many European networks and PBXs expect.

What ITU-T Q.23 guarantees at a minimum

Q.23 defines the DTMF ⁴ frequency set and key technical tolerances, such as:

• each transmitted frequency must be within a defined tolerance band

• unwanted components (harmonics/intermodulation) must be sufficiently below the fundamentals

This is the baseline that makes a keypad “DTMF compatible” in the general sense.

What ETSI adds that matters for real interoperability

ETSI ES 201 235-2 gives transmitter requirements that include explicit level targets and twist guidance. For analogue transmitters, it sets nominal sending levels for high group and low group, and it also states that the high frequency component should be 1–4 dB higher than the low frequency component (twist direction).

That twist rule is not academic. Many receivers are tuned to reject speech and noise. Correct twist improves detection under real line conditions.

What can go wrong on Ex phones specifically

Explosion-proof phones are often used in places with:

• high ambient noise

• long cable runs

• surge protectors and terminal blocks that add loss

• gateways that compress audio if DTMF is sent in-band

Those factors can reduce effective DTMF level, change relative levels (twist), or distort the tone pair.

A practical DTMF acceptance table for FAT

Use a receiver test (IVR, test set, or PBX diagnostics) and confirm 100% recognition:

| Test item | Target behavior | Why it matters |

|—|—|—|

| Frequency tolerance | within standard tolerance | prevents “near miss” digits |

| Twist | high group slightly higher than low group | improves detection in noise |

| Digit duration | stable tone on/off timing | avoids double digits |

| In-band vs out-of-band | choose one and validate | low-rate codecs can break in-band |

| Worst-case line loss | test with long loop simulation | prevents remote site failures |

If the Ex phone is SIP-based, the best practice is to prefer RTP event DTMF (RFC 4733) instead of in-band audio when IVRs are critical.

Can DTMF be sent via RFC2833 and SIP INFO?

DTMF over SIP can “work in the lab” and fail in production when a carrier SBC or recorder sits in the middle and changes signaling.

Yes. SIP explosion-proof telephones commonly support out-of-band DTMF either as RTP events (RFC 4733, compatible with older RFC 2833 expectations) or via SIP INFO. The network must be configured so all hops agree on the same method.

RFC 2833 vs RFC 4733 in plain terms

RTP “telephone-event” packets are the most common reliable DTMF method in VoIP ⁵. RFC 4733 explicitly obsoletes RFC 2833, but many systems still use the phrase “RFC2833” as a UI label. It usually means telephone-event in RTP.

SIP INFO is real, but it is a signaling-path feature

RFC 2976 defines the SIP INFO ⁶ method and lists carrying DTMF digits during a SIP session as a typical use.

SIP INFO can work well inside a controlled enterprise, but it can fail if:

• an SBC blocks INFO messages

• a carrier does not pass them end-to-end

• mid-call signaling policies differ between vendors

Why explosion-proof SIP phones still need a clear DTMF policy

An Ex SIP phone is still a SIP phone. In hazardous-area projects, the common integration points are:

• IP PBX (Asterisk-based, BroadSoft-style, Teams/Zoom SIP gateways, etc.)

• SBC in the DMZ

• recording or dispatch platforms

Each one may handle DTMF differently. So the phone spec should state:

• supported methods: RTP events (RFC 4733 ⁷) + SIP INFO

• default method and fallback

• payload type and redundancy settings for RTP events

A simple “choose one” table

| Method | Strength | Typical risk | When it is the best choice |

|—|—|—|—|

| RTP events (RFC 4733 / “2833”) | reliable through codecs | payload mismatch if mis-set | IVR-heavy sites, multi-hop VoIP |

| SIP INFO | clear signaling | blocked by SBC/carrier | controlled enterprise domains |

| In-band audio | simplest concept | breaks with compression/noise | only on G.711 clean paths |

The safest recommendation is: use RTP events by default, keep SIP INFO as a controlled fallback, and avoid in-band unless the path is proven clean.

Is pre-ring and mid-call Caller ID decoded correctly?

This is where projects get surprised. The PBX sends CID, the gateway logs show CID, but the phone display stays blank.

Pre-ring and mid-call Caller ID can be decoded correctly only if the telephone explicitly supports those delivery modes. Bellcore Type I is commonly between ring bursts, ETSI can be before ring with alerting signals, and mid-call Caller ID requires Type II (call waiting CID) support plus the correct alerting procedure.

Pre-ring CID: timing matters more than the modulation

Bellcore-style on-hook CID is widely described as FSK sent in the quiet window between ring bursts.

ETSI deployments can send CID after polarity reversal or DT-AS and even before the first ring in some country profiles. If the gateway expects “between first and second ring,” it can miss pre-ring CID unless configured.

This is why a FAT should test the exact carrier or PBX behavior used on site, not a default lab profile.

Mid-call CID: ETSI EN 300 659-2 and Bellcore Type II are not the same flow

ETSI defines off-hook data transmission procedures for “CLIP on Call Waiting,” including alerting signals and timing considerations.

Bellcore Type II (CID on Call Waiting) uses a known approach where an alerting signal sequence is used and the CPE can respond with a DTMF acknowledgment before receiving the CID payload in some implementations. A typical description of the alerting tones is 2130 Hz and 2750 Hz.

So “supports Type II” must be tested. Many industrial Ex phones do not implement call-waiting CID decode, even if they can decode Type I on-hook CID.

How to write a FAT that proves it

A FAT for CID should include both timing and display behavior:

• Type I: inbound call, verify CID shows correctly (number, date/time if required)

• Pre-ring: simulate or configure PBX to send CID before first ring if the region requires it

• Type II: place a call, then inject call waiting CID and confirm the phone behavior

• Verify gateway settings used (FSK standard selection)

Cisco-style regional settings pages illustrate why this matters: gateways often expose separate choices for Caller ID ⁸ standards and delivery behavior.

A field-proof CID checklist

| CID mode | What must be true | What fails most often |

|—|—|—|

| Type I (on-hook) | correct standard + correct timing | wrong ETSI/Bellcore profile |

| Pre-ring CID | gateway supports local timing | gateway only listens between rings |

| Type II (call waiting) | phone supports off-hook CID decode | phone only supports Type I |

| SIP phones | CID in SIP headers | not a CID issue, it is PBX ⁹ policy |

If CID is mission-critical, the safest path is often SIP in the core and CID handled in SIP signaling. If analog CID is required, then Type I/II support and timing must be locked as a contractual requirement.

Conclusion

DTMF dialing is almost universal, while FSK/DTMF Caller ID depends on local standards, timing, and phone features. Lock the method, configure the gateway, and prove it in FAT with Type I and Type II tests. ITU-T ¹⁰ standards provide the baseline, but regional profiles dictate the reality.

Footnotes