Do explosion-proof telephones support SRTP encryption?

Plain RTP is still a hidden risk in hazardous plants. One mirror port or a tapped cabinet can expose emergency audio and create painful incident reviews.

Yes. Many explosion-proof SIP telephones support SRTP for media encryption, most often using SDES, and sometimes DTLS-SRTP. The right choice depends on your PBX/SBC support, cipher list, and how you provision and enforce “SRTP-only” at scale.

How SRTP fits into an Ex telephone security architecture?

SRTP protects media, not ignition safety

Secure Real-time Transport Protocol (SRTP) ¹ is a media security tool. It encrypts RTP and RTCP so people cannot listen in or tamper with audio easily. It does not change the explosion protection concept. Ex d, Ex e, and Ex i are still about ignition control. So SRTP should be treated as part of the network and cybersecurity design, while Ex marking remains part of the mechanical and electrical safety design.

The “secure call chain” needs two locks

A secure VoIP call usually needs two layers:

• SIP over TLS to protect signaling (registration, call setup, and the SRTP negotiation data).
• SRTP to protect the actual audio packets.

If only TLS is used, the audio can still be captured on the network. If only SRTP is used and keys are exposed in signaling, the protection can be weak in real deployments. The chain needs both locks.

What to specify so SRTP is real, not marketing

A lot of datasheets say “SRTP supported” without saying how it is negotiated and what ciphers it can use. A tender should require four things:
1) SRTP keying method list (SDES and/or DTLS-SRTP)
2) SRTP crypto suite list (what the phone offers in SDP)
3) “SRTP required” mode (no RTP fallback)
4) Proof: interop test with your PBX/SBC and a packet capture showing RTP/SAVP or RTP/SAVPF

A simple SRTP requirement matrix

The rest of this page breaks SRTP into four procurement questions. Each one should end with a clear line you can paste into specs.

If SRTP is being added for compliance, the keying method decision comes first. It affects provisioning, troubleshooting, and how you explain security to the client.

Which SRTP keying methods are supported—SDES or DTLS-SRTP—and how are keys provisioned at scale?

SRTP can be “enabled” and still be weak. The key method decides whether keys stay private or travel inside SIP messages.

Most enterprise SIP environments still use SDES for SRTP keying. DTLS-SRTP is also common in WebRTC and some modern endpoints, but it needs more interop work. At scale, keys are not provisioned as static secrets; they are negotiated per call, while certificates and policies are provisioned.

SDES in plain language

SDP Security Descriptions (SDES) for SRTP ³ uses an SDP attribute (often the “a=crypto” line) to carry SRTP parameters and keying material during call setup. It is simple, and it is widely supported by SBCs and PBXs. In large deployments, SDES scaling looks like this:

• Provision a policy: “SRTP enabled/required” and allowed crypto suites.
• Use TLS for SIP so the SDP with keys is not exposed on the wire.
• Let keys rotate per call. No per-device SRTP key storage is needed.

This is why SDES can be practical for harsh sites. The device config stays stable. The keys change each call.

DTLS-SRTP in plain language

DTLS-SRTP key agreement ⁴ uses a DTLS handshake on the media path to derive SRTP keys. It keeps SRTP keys out of SIP messages. It can be a stronger design, but it needs clean interop between endpoints and SBCs. It also needs certificate handling:

• Devices may use self-signed certs with fingerprints carried in SDP.
• Or devices may use CA-signed certs if your policy demands it.
• The key point is still the same: keys are negotiated per call, while cert identity is managed at scale.

Provisioning at scale: what “good” looks like

A clean mass rollout normally provisions:

• SRTP mode (disabled / optional / required)
• keying priority (prefer DTLS-SRTP, allow SDES, or SDES only)
• allowed crypto suite list
• TLS and certificate settings for SIP and provisioning
• logging level for SRTP negotiation failures

It should not provision “fixed SRTP keys” per phone. That is fragile and not needed in standard SIP/SRTP designs.

A scale-ready checklist

Once the keying method is chosen, the next gate is cipher compatibility. This is where Cisco, BroadSoft/BroadWorks, and Asterisk projects often differ.

Are SRTP cipher suites configurable—AES-128-GCM/CTR, HMAC-SHA1—and compatible with Cisco/BroadSoft/Asterisk?

A phone can support SRTP and still fail interop. That happens when cipher suites do not match, or when the PBX only accepts one profile.

In most SIP deployments, the safest baseline cipher is AES_CM_128_HMAC_SHA1_80. AES-GCM SRTP is available in some stacks, but it is not universal in classic SIP PBXs. So the tender should require a configurable crypto suite list and a proven interop matrix with your target platform.

The reality: one cipher still dominates SIP trunks

Many enterprise and carrier environments still standardize on AES_CM_128_HMAC_SHA1_80 because it is widely implemented and defined clearly in the SDES ecosystem. BroadWorks media server SRTP support is commonly described with SDES keying. Asterisk deployments often default to offering AES_CM_128_HMAC_SHA1_80 in SDP in many real-world configurations.

This does not mean “strong ciphers are impossible.” It means interop is the first constraint.

AES-GCM SRTP: good, but verify before you demand it

AES-GCM for SRTP ⁵ exists and is defined in standards. Some products support it, especially in conferencing and WebRTC-aligned stacks. In classic SIP endpoints and PBX stacks, support can be uneven. If AES-GCM is required by a policy team, the safest path is:

• terminate SRTP on an SBC that supports the required suite set
• interwork to the endpoint cipher set if needed
• keep the “secure domain” inside your controlled network

What “configurable cipher suites” should mean in a tender

• Ability to select which suites the phone offers (and in what order).
• Ability to disable weak or unwanted suites.
• Clear visibility: the phone should show the active negotiated suite per call.

A compatibility-first cipher table

The simple client message is: pick the cipher set your platform actually negotiates today, then upgrade only when the whole chain can do it.

Now, even when cipher support is correct, buyers worry about performance. That is fair on PoE-powered hazardous-area endpoints that may already run hot.

How does SRTP affect latency, MOS, and CPU in PoE-powered hazardous-area phones?

If SRTP causes resets or audio delay, the security feature becomes a reliability problem. Plants care about uptime more than slogans.

In most modern systems, SRTP adds very small overhead and usually has no visible impact on MOS when the network is designed correctly. The bigger risks are CPU headroom on low-end hardware, and thermal margin inside sealed Ex enclosures at high ambient.

Latency and MOS: where the real impact usually comes from

Voice quality is driven by jitter, packet loss, codec choice, and buffering. SRTP adds cryptographic work per packet, but the total effect is usually modest on capable hardware.

So the best way to protect MOS is still basic network design:

• enable QoS for RTP (DSCP EF and proper switch queues)
• keep paging and video out of the voice queue
• avoid oversubscription on uplinks
• keep jitter buffers sane

CPU and PoE budget: what changes with SRTP

SRTP increases CPU cycles, and that can increase power draw a bit. On a typical PoE phone, the delta is small. But on an Ex phone, two extra factors matter:

• sealed enclosure reduces heat escape
• high ambient and solar load can already push thermal limits

So SRTP performance risk is not “latency” first. It is “thermal and stability margin” first.

A practical test plan that fits industrial acceptance

For a harsh project, the test plan should be written as an acceptance method:
1) Run a worst-case feature load (max volume paging, beacon duty, relays, normal SIP traffic).
2) Enable SRTP and TLS.
3) Heat soak near maximum ambient rating if possible.
4) Measure: call setup time, one-way audio delay, jitter, packet loss, and re-registration events.
5) Confirm no reboots and no SIP registration loss.

A simple performance table for tender and FAT

If the phone passes this test, SRTP is not a practical risk to MOS. If it fails, the fix is usually in hardware headroom, PoE budget, or network QoS. It is rarely “SRTP is slow.”

Once performance is settled, the final compliance question is enforcement. Many systems allow fallback to RTP, and that quietly breaks the policy.

Can SRTP be enforced with TLS/SIPS, 802.1X, and certificate management to meet compliance?

Optional encryption is not compliance. If the phone can fall back to RTP during outages, it will do it at 2 a.m. and nobody will notice until an audit.

Yes. SRTP can be enforced by combining “SRTP required” on endpoints, TLS-required signaling on PBX/SBC, and network admission controls like 802.1X. Certificates and HTTPS provisioning make enforcement scalable and auditable.

Enforce at three layers, not one

1) Endpoint layer

• Set SRTP mode to “required” (no RTP fallback).
• Set TLS mode to “required” for SIP.
• Limit cipher suites to the approved list.

2) SBC/PBX layer

• Reject calls that offer RTP only.
• Reject weak ciphers or unknown profiles.
• Log every downgrade attempt and alert on failures.

3) Network layer

• Use 802.1X port-based network access control ⁶ so only approved phones enter the voice VLAN.
• Use VLAN segmentation so phones do not share the same broadcast domain as heavy OT traffic.
• Use DHCP and provisioning policies that do not expose management services on the voice VLAN.

Certificates: what should be manageable at scale

A compliance-ready rollout should support:

• device certificate or at least CA trust store handling
• HTTPS provisioning with a controlled trust chain
• secure storage of private keys on the device
• a clear renewal plan (shorter lifetimes are easier than perfect revocation support)

Even when DTLS-SRTP is not used, certificates still matter because TLS for SIP and HTTPS for provisioning both rely on them. Your PBX/SBC policy also needs to be explicit about Session Initiation Protocol (SIP) ⁷ security requirements so endpoints cannot “negotiate down” in the field.

An enforcement table you can paste into a security spec

The simplest explanation to clients is: SRTP protects audio, TLS protects setup and keys, and 802.1X keeps unknown devices out. Together they meet most compliance needs without turning field work into a daily fight.

Conclusion

Explosion-proof SIP phones often support SRTP, but success depends on keying method, cipher interop, and strong enforcement with TLS and network controls.

Footnotes