What RTP/RTCP implementation details do explosion-proof telephones provide?

A SIP explosion-proof phone can pass Ex checks and still deliver bad calls. Most failures come from hidden RTP settings, weak reporting, and mismatched security options.

Explosion-proof SIP telephones usually follow standard RTP/RTCP behavior, but feature depth varies by VoIP module. The right approach is to specify ptime/maxptime, RTCP/XR metrics, DTMF event handling, and SRTP ciphers, then verify with packet captures in FAT.

RTP/RTCP capabilities that actually matter on hazardous-area SIP phones

First, confirm the product type

RTP/RTCP topics only apply to SIP/IP explosion-proof telephones. Analog Ex phones (FXS/POTS) do not use RTP. This sounds obvious, but many hybrid projects mix “Ex phone” models and assume the same media features.

The real-world baseline most Ex SIP phones provide

Most Ex SIP phones behave like standard SIP endpoints:

• RTP carries audio frames.

• RTCP provides periodic sender/receiver reports with loss and jitter metrics.

• DTMF can be in-band, RTP events (“RFC2833”), or SIP INFO depending on configuration.

• SRTP may be available, but cipher choices and keying methods differ by firmware.

The most important lesson is simple: “supports RTP” is not enough. A refinery dispatch room cares about predictable packetization, stable DTMF through loss, and measurable QoS.

A procurement checklist that avoids 80% of surprises

| Item | What to specify | Why it matters |

|—|—|—|

| Packetization | ptime values + maxptime cap | Controls delay, bandwidth, and PLC behavior |

| Reporting | RTCP interval + exported metrics | Enables QoS monitoring and troubleshooting |

| DTMF | RTP events + redundancy behavior | Keeps IVR/dispatch control reliable |

| Security | SRTP ciphers + keying method | Meets site cyber policy and audit expectations |

| Verification | Wireshark + PBX/SBC logs in FAT | Proves claims match real packets |

A phone that looks “industrial” can still use a basic SIP stack with minimal knobs. That is fine if the site is simple. It is risky when the network is lossy or security rules are strict.

The next sections answer your exact questions in a way that can be copied into a technical specification and then proven in a FAT.

Are ptime and maxptime configurable per codec?

Latency complaints usually come from one hidden knob: packetization. If ptime is wrong, the best codec still sounds bad.

ptime is commonly configurable on SIP phones, while maxptime is often supported as an SDP cap. Per-codec packetization is not always available because SDP usually applies ptime/maxptime to the whole audio m-line, not each codec.

What ptime and maxptime really control

ptime is the intended packetization time (for example 20 ms). It affects:

• one-way delay and mouth-to-ear feel

• packet rate and overhead

• PLC (packet loss concealment) behavior

• jitter buffer stability

maxptime is a ceiling that tells the other side “do not send packets larger than this,” which prevents a peer from forcing huge frames that increase delay.

Why “per codec” is harder than it sounds

In many implementations, ptime is negotiated at the SDP media level. A single call may offer multiple codecs, but the session only uses one codec at a time. That is why many endpoints offer:

• a global ptime for the call

• a maxptime cap for the call

• sometimes a “preferred ptime per codec” UI that is actually a preset applied when that codec is selected

Some stacks do not support different ptimes per codec cleanly. This matters when the site uses mixed codecs (G.711 locally, Opus/G.729 across WAN) and wants different ptime targets.

What to specify for harsh networks

For industrial networks, a safe default is:

• G.711: ptime 20 ms, maxptime 40 ms

• compressed codecs: ptime 20 ms or 30 ms depending on WAN and jitter

• avoid very large ptime unless bandwidth is extremely constrained

Larger ptime reduces packet overhead but increases latency and can make loss bursts more audible.

How to verify in FAT (fast and objective)

1) Place a call using each target codec.

2) Capture RTP in Wireshark.

3) Check RTP timestamp steps and packet spacing.

4) Confirm the peer respects maxptime when it is advertised.

| FAT check | What “pass” looks like | What “fail” looks like |

|—|—|—|

| ptime | packet spacing matches 20 ms | peer sends 60 ms frames |

| maxptime | peer never exceeds the cap | peer ignores cap, delay jumps |

| WAN profile | jitter buffer stays stable | audible gaps during jitter spikes |

If a vendor claims per-codec ptime, the FAT should prove it by switching codecs mid-test and showing different RTP spacing.

Does RTCP XR or RFC3550 reporting support QoS monitoring?

A site cannot fix what it cannot measure. Basic RTCP helps, but sometimes it is not enough for dispatch-grade monitoring.

Most SIP phones support standard RTCP ¹ (RFC3550) sender/receiver reports for loss and jitter. RTCP XR is optional and less common on endpoints, but it can add deeper QoE metrics when supported and collected by the SBC/PBX.

What standard RTCP gives you in practice

Standard RTCP reports commonly provide:

• packet counts

• packet loss fraction and cumulative loss

• interarrival jitter estimate

• timing data that can be used for round-trip calculations

This is enough for day-to-day troubleshooting if the PBX/SBC actually stores and exposes it.

What RTCP XR adds, and why many plants still want it

RTCP XR ² can carry “extra blocks” with metrics beyond basic RTCP, such as:

• burst/gap loss behavior

• delay and jitter details

• quality indicator style metrics (implementation-dependent)

• diagnostics that help identify where quality degraded

XR is most valuable when a collector exists. Many deployments use the SBC or monitoring platform as the collector and do not rely on the phone UI.

What to specify if QoS monitoring is a contract requirement

| Monitoring goal | Minimum requirement | Better requirement |

|—|—|—|

| Basic health | RTCP SR/RR enabled | RTCP + exported stats via syslog/API |

| WAN troubleshooting | RTCP interval control | RTCP XR + collector support |

| SLA reporting | CDR + RTCP stats | RTCP XR + MOS/QoE analytics |

How to verify support in FAT

1) Capture RTCP packets during a call.

2) Confirm SR/RR frequency and fields are present.

3) If XR is claimed, confirm XR packet type and blocks appear.

4) Confirm the PBX/SBC can ingest and display the metrics.

A common reality is that the phone sends standard RTCP only, and XR is generated by SBCs or analytics agents instead. That is still acceptable if the monitoring architecture is designed around it. The key is to align expectations early.

Are RFC2833 events prioritized under packet loss?

DTMF is usually the first thing to break on a bad network. Operators notice it fast because IVRs and dispatch control stop working.

RTP “RFC2833” telephone events (RFC4733 ³) are usually more reliable than in-band DTMF, but they are not magically “prioritized” at the RTP layer. Reliability under loss comes from event redundancy (repeated packets, duration fields) and from network QoS marking, not from the RFC itself.

What “RFC2833” really means today

Most systems say “RFC2833,” but the current standard behavior is described in RFC4733. The core idea is the same: send DTMF digits as RTP events instead of audio tones. That avoids codec distortion and VAD issues.

What helps under packet loss

Three practical mechanisms improve success:

1) Repetition: the sender transmits the same event multiple times.

2) Duration field: the receiver can reconstruct the event length even if some packets are lost.

3) End-of-event repeats: the sender repeats the final packet to increase the chance the receiver sees the “event ended” marker.

Some SIP stacks expose this as “DTMF redundancy,” “DTMF payload repeats,” or “event duration packets.”

Where true “priority” should be implemented

If the network is the problem, the best priority control is:

• VLAN/QoS policy

• DSCP marking for RTP/RTCP

• scheduler priority on switches

• WAN shaping that protects RTP event packets

RTP itself does not define hard packet priority. Priority is a network policy decision.

What to test in FAT

| Test | How to run it | Pass criteria |

|—|—|—|

| Loss tolerance | add 1–5% loss in test network | IVR receives 100% digits |

| Burst loss | add short loss bursts | digits still decode reliably |

| Jitter spikes | add jitter to WAN profile | no digit duplication |

| Interop | test with site SBC/PBX | payload type and clock rate match |

For high-stakes dispatch sites, I prefer RTP events by default, then keep SIP INFO as a controlled fallback. In-band DTMF is the last choice unless the whole path is G.711 and clean.

Is SRTP with AES-128/256 available for media?

Security teams often ask for “AES-256 SRTP” by policy. Many phones support SRTP, but not every firmware supports every cipher or every keying method.

SRTP is defined in RFC3711 and commonly uses AES-128. AES-192/256 are defined for SRTP in RFC6188 ⁴, but support is optional and must be confirmed on the exact phone firmware and PBX/SBC stack.

What to confirm before promising SRTP in a hazardous-area project

SRTP support has four separate decisions:

1) Cipher suite: AES-128 vs AES-256 (or other profiles).

2) Authentication: tag length and method (commonly HMAC-SHA1 variants).

3) Keying: SDES-SRTP (crypto lines in SDP) or DTLS-SRTP.

4) Interoperability: PBX, SBC, recorder, and dispatcher must all agree.

A phone can “support SRTP” but only with SDES, while the enterprise standard requires DTLS-SRTP. Or the phone supports AES-128 only, while policy asks for AES-256. These mismatches are common.

Practical guidance on AES-256 requests

AES-256 is a valid SRTP option. It is just not guaranteed in every embedded SIP stack. If AES-256 is mandatory, the safest approach is:

• require the exact SRTP crypto suite in the procurement spec

• require proof via SDP and packet capture in FAT

• confirm the SBC/PBX also supports the same suite

How to verify SRTP objectively in FAT

1) Place a call with SRTP enabled.

2) Capture packets on the LAN.

3) Confirm RTP payload is encrypted (no decodable audio).

4) Check SDP: SDES crypto attributes or DTLS fingerprint/handshake behavior.

5) Confirm RTCP is also protected (SRTCP), if required.

| Evidence | What it proves | Who cares |

|—|—|—|

| Wireshark capture | media is actually encrypted | cybersecurity + QA |

| SDP snippets | cipher suite + keying method | integration engineer |

| PBX/SBC logs | negotiation success/fallback | operations team |

| Recorder test | recording still works | compliance team |

Balance security with reliability

SRTP adds CPU and negotiation steps. Most modern SIP stacks handle it well, but in harsh networks, negotiation timeouts can appear if TLS/DTLS policies are tight. The best plan is to test:

• busy-hour call setup time

• re-registration after link flap

• SRTP renegotiation behavior during failover

Security is not only “supported.” It must be stable under the site’s network reality.

Conclusion

RTP/RTCP features vary by SIP module, so I specify ptime/maxptime, RTCP/XR metrics, RTP-event DTMF behavior, and SRTP ciphers, then prove them with FAT packet captures.

Footnotes