Explosion-proof telephones and professional radio systems are two important communication pillars in hazardous industrial environments. Fixed explosion-proof telephones provide dependable communications from known locations inside hazardous areas, while portable and mobile radios follow field personnel during inspection, maintenance and operational coordination. In many existing plants, however, the two systems have evolved independently: the telephone network operates through PBX or SIP infrastructure, while the radio network uses dedicated channels or talk groups, with no direct communication path between them.
Interoperability between explosion-proof telephones and radio systems is intended to remove that separation. It does not turn a SIP telephone into a two-way radio. Instead, RoIP gateways, SIP communications and dispatch control connect fixed telephone audio with radio-channel audio, PTT control and receive-status signaling, allowing fixed-location users, dispatchers and mobile radio users to participate in the same controlled communication workflow.
Communication Differences Between Explosion-Proof Telephones and Radio Systems
Explosion-proof telephones and professional radio systems both carry voice, but they operate according to very different communication models.
A SIP explosion-proof telephone behaves much like a conventional telephone endpoint. The user goes off-hook or presses a call key to establish a SIP call. Both parties can normally speak at the same time, while call routing is determined by extension numbers, SIP URIs, PBX routing rules or a dispatch server. Media is typically carried continuously over RTP.
Radio systems are usually organized around a Channel or Talk Group. Analog radio, DMR, P25, TETRA and other professional mobile radio systems use different air-interface technologies, but field operation commonly relies on PTT: press to transmit and release to receive. A single physical radio channel therefore usually operates in a clearly half-duplex manner.
This creates two fundamental differences. Telephone users think in terms of "who do I want to call?", while radio users think in terms of "which channel or group should I use?". Control is also different. Once a SIP call is established, the telephone can send media immediately, whereas a radio must first be keyed through PTT before RF transmission begins. On the receive side, signals such as COR, COS, Squelch or Channel Busy are also useful so that the IP system can determine whether valid radio traffic is currently being received.
RoIP does not eliminate these differences. It creates a defined mapping between them. The telephone side continues to use SIP and RTP, while the radio side continues using its existing radio equipment and channels. The RoIP Gateway carries audio together with PTT and receive-detection control across the IP network.
Access Architectures for Fixed Call Stations and Radio Systems
There is no single architecture for connecting telephones to radio systems. The main design choice is whether a SIP telephone call should be mapped directly to a radio resource or first enter a dispatch platform, where an operator decides when and which radio channel should be used.
Direct Mapping of Radio Channels as SIP Resources
One relatively direct approach is to make the RoIP Gateway appear as a SIP endpoint, SIP resource or other communication object recognized by the platform. A radio channel can then be assigned an extension number or resource name. When an explosion-proof telephone calls that destination, the voice is sent to the RoIP Gateway, which keys the connected control radio and transmits the audio over the radio channel.
This architecture is suitable for clearly defined point-to-point requirements. For example, an explosion-proof call station in a compressor room may only need to reach the maintenance radio group. The telephone number can be permanently mapped to that radio resource, so field users do not need to select complex radio channels themselves.
Direct integration does not mean that the telephone can communicate exactly like a normal full-duplex call. The radio side still follows half-duplex PTT rules, so the system must define when telephone audio triggers radio PTT and how the telephone behaves when radio audio is being received.
Dispatch Platform as the Control Layer
A second architecture is better suited to control rooms and emergency communications. The explosion-proof telephone first calls the dispatcher, while individual radio channels are presented as separate resources on the dispatch platform. After receiving the field report, the dispatcher can select a Maintenance Radio, Security Radio or Emergency Channel and transmit over that resource through the RoIP connection.
This introduces an additional operator-control layer but provides clearer operational boundaries. A field telephone report does not necessarily need to be transmitted to every radio user. The dispatcher can verify the information first and then decide which group should be contacted. Where necessary, the telephone user and radio resource can also be temporarily bridged into the same voice session.
In hazardous industrial environments, this architecture often matches real operating procedures more closely: the fixed call station reports the incident, radio users coordinate mobile response, and the dispatch position determines when the two communication domains should be connected.
Full-Duplex Voice and PTT Half-Duplex Adaptation
Consider a SIP explosion-proof telephone installed in a tank farm. The telephone is registered to an IP PBX or dispatch communication server. The maintenance team uses analog or digital radios, while the control room has a compatible Control Radio connected to a RoIP Gateway.
When the explosion-proof telephone places a call, the first part of the path is no different from an ordinary SIP call:
Explosion-Proof Telephone → IP Network → SIP Server / Dispatch Platform
Once the system determines that the destination is a Radio Resource, RTP audio is delivered to the RoIP Gateway. The gateway converts the IP-side audio into a format suitable for the audio input of the control radio and asserts PTT when transmission is required. The control radio performs the actual RF transmission, which is then received by portable or mobile radios in the field.
The reverse path works in a similar way. A radio user presses PTT and speaks. The control radio receives the RF signal and passes the audio to the RoIP Gateway. The gateway uses COR, COS, Squelch Status or another Receive Detect signal to determine that valid radio traffic is present, then converts that audio into IP media and returns it to the dispatch platform or telephone side.
In this architecture, the RoIP Gateway is not necessarily decoding the DMR, P25 or TETRA air-interface protocol itself. Many deployments use a compatible control radio, mobile radio or base station that provides audio and PTT interfaces, while the RoIP Gateway controls that Radio Endpoint. As long as the radio equipment provides suitable audio, PTT and receive-detection interfaces, the same basic RoIP architecture can be applied across different radio technologies.
This is why the radio interface must be confirmed before selecting a RoIP device. Knowing only that "the system uses DMR" is not enough. The project also needs to identify the actual control-radio model, whether the audio interface is 2-wire or 4-wire, what electrical PTT interface is available, whether COR/COS is provided, and how the audio level and impedance should be matched.
Voice and Control Conversion Between SIP and RoIP
Connecting the audio paths is only the first step. In many interoperability projects, the more difficult issue is controlling who is allowed to transmit.
SIP telephone users are accustomed to lifting the handset and speaking without pressing PTT before every sentence. Radio users work differently: without PTT, the radio does not transmit. The system therefore needs a defined method for determining when telephone-side audio causes the RoIP Gateway to assert radio PTT.
Explicit control is often the most predictable method. A dispatcher may have a dedicated PTT key and only key the selected Radio Resource while the button is pressed. For dedicated industrial call stations, programmable keys, DTMF or system-defined control commands can also be used to enter transmit mode.
Some systems use Voice Activity Detection to trigger PTT automatically from speech. This can be convenient for the user but must be applied cautiously in high-noise industrial environments. Pumps, compressors, ventilation systems and alarms can all enter the microphone path. If the VAD threshold is poorly configured, background noise may repeatedly key the radio and occupy the channel.
Radio channel occupancy is another consideration. If a radio user is already transmitting and the telephone side asserts PTT at the same time, voice collisions may occur. Where the RoIP Gateway can monitor COR/COS or Channel Busy status, the dispatch system can identify that the radio resource is currently receiving and delay or block another transmission.
Telephone-to-radio interoperability is therefore more than a simple Voice Bridge. A usable system should define at least three things:
When the telephone side is allowed to transmit;
Whether the IP side can interrupt while the radio resource is receiving;
How quickly PTT is released and the channel returns to receive mode after speech ends.
If the PTT tail delay is too short, the final word or syllable may be clipped. If it is too long, the radio channel remains occupied unnecessarily. These values should be tested with the actual radio equipment rather than copied from another project.
Role of the Dispatch Platform in Fixed and Mobile Communications
If the requirement is limited to connecting one telephone to one radio channel, the RoIP Gateway itself can solve much of the interface problem. Industrial sites, however, rarely remain at a one-to-one scale.
A refinery may have numerous explosion-proof telephones distributed across tank farms, loading areas, pump stations and compressor buildings. Radio resources may include maintenance, security, fire-response and production groups. At this point, the dispatch system becomes more than an audio path; it becomes the layer that establishes operational relationships between different communication resources.
A fixed explosion-proof telephone can appear on the dispatch interface as "Tank Farm T-03 Telephone" instead of an unfamiliar SIP extension. A RoIP resource can be displayed as "Maintenance DMR Channel" or "Emergency Radio". The dispatcher sees operational locations and service names rather than SIP URIs, gateway ports or radio models.
When a tank-farm telephone calls in, the dispatch position immediately identifies the fixed location. After confirming the incident, the operator can select the Maintenance Radio to contact technicians. If the situation escalates, the fire-response and security radio groups can also be added. Where required, a temporary Voice Bridge can allow the person at the explosion-proof telephone to hear and respond directly to the radio group.
This type of bridge is better controlled by the dispatcher than permanently connecting every telephone and radio group. A permanent bridge ties two independent communication domains together continuously, allowing routine telephone traffic to enter the radio channel and internal radio traffic to occupy telephone-side resources unnecessarily.
The purpose of dispatch control is therefore to connect communication domains when the operational event requires it, rather than keeping them permanently connected.
Integration of Existing Analog Communication Systems
Many operating plants are Brownfield environments rather than new-build projects. A site may already have analog explosion-proof telephones that have been in service for a decade, together with conventional UHF or VHF radio equipment in the control room. Replacing every device with SIP terminals and new radio systems whenever interoperability is required would increase both project cost and shutdown risk.
These environments can be integrated in layers.
Existing analog telephones can connect to an IP PBX or dispatch platform through an FXS Voice Gateway. From the perspective of the dispatch system, each telephone becomes an identifiable and callable resource. The fact that the final field connection remains an analog copper pair does not prevent it from entering a unified call workflow.
On the radio side, the existing control radio can remain in service. The RoIP Gateway connects to its Audio, PTT and COR/COS interfaces and extends the local radio resource onto the IP network.
A resulting architecture may look like this:
Analog Explosion-Proof Telephone → FXS Gateway → SIP / Dispatch
SIP Explosion-Proof Telephone → IP Network → SIP / Dispatch
↓
Dispatch Platform → RoIP Gateway → Existing Control Radio → Portable / Mobile Radios
The modernization objective shifts from standardizing every field device to standardizing how upper-layer communication resources are presented and operated. This is particularly useful in large existing plants because telephone and radio systems can be upgraded in phases rather than requiring all field devices to be replaced during one maintenance window.
Latency and Audio Quality Control in RoIP Links
Hearing a sentence come through a radio during laboratory testing only proves that the basic interface is connected. In production, voice must remain usable after passing through multiple processing stages.
A transmission from an explosion-proof telephone to a radio user may pass through SIP endpoint encoding, IP-network transport, dispatch-server processing, RoIP Gateway decoding, PTT setup, control-radio transmission and RF reception. The return path repeats the process in reverse. If unnecessary transcoding occurs between these stages, end-to-end latency increases further.
Several additional milliseconds may be insignificant in an ordinary telephone call, but PTT radio operation is sensitive to delay. If the telephone user begins speaking before radio PTT has fully established the transmission path, the first word or first few syllables may be lost. RoIP systems therefore often require a suitable PTT Lead Delay or audio buffering period.
The IP network must also control Jitter, Packet Loss and QoS. Voice may share the industrial network with video surveillance, office traffic and equipment-monitoring data. If RTP traffic does not receive appropriate QoS during periods of congestion, users may experience broken audio, delayed speech or poor intelligibility even though the IP connection itself remains available.
Codec selection should be evaluated across the complete path. G.711 provides low processing delay and broad compatibility but uses more bandwidth. Compressed codecs reduce bandwidth consumption but can introduce additional encoding delay. The objective should not be to select the codec with the most attractive specification, but to minimize unnecessary transcoding and create a stable, predictable media path between the telephone, server and RoIP Gateway.
Audio Level also needs to be calibrated during commissioning. A normal RTP level on the telephone side does not guarantee that the control-radio input level is correct. A level that is too low produces weak radio audio, while excessive levels can cause clipping and distortion. Receive and Transmit directions should be adjusted separately.
System Redundancy and Emergency Communication Resilience
Interoperability between explosion-proof telephones and radio systems is often used for equipment failures, leaks, personnel injuries and emergency response rather than ordinary office calling. Once two independent systems are connected, shared failure points are introduced as well.
If all radio resources depend on one RoIP Gateway and that gateway loses power, telephone users can no longer reach the radio system. If the gateway remains operational but the only Control Radio fails, the IP platform no longer has a working RF path. If a remote site has only one IP connection to the control center, loss of that link also removes the remote Radio Resource.
Whether the project requires redundant RoIP gateways, backup radios, dual network paths, VPN backup or a secondary dispatch center depends on the criticality of the system. Not every project needs every form of redundancy, but the design team should identify each single point of failure in the critical communication path.
Access control also matters. A routine production call station may not need direct access to an Emergency Radio Channel. Emergency keys can be assigned shorter routing paths and higher priority, while ordinary users should be prevented from accidentally occupying critical radio resources.
Recording design should capture the complete conversation between the telephone and radio sides. If the recorder captures only the SIP telephone audio but not the radio audio returned through RoIP, incident playback will contain only half of the conversation. Once multiple systems are integrated, time synchronization also becomes important. Telephone call records, Radio PTT events, dispatch actions and recordings should preferably share a consistent NTP time reference.
Fixed explosion-proof call stations also provide one important operational advantage: their physical locations are already known. If the dispatch platform maintains a reliable mapping between extension identity and installation point, an incoming call can immediately display the equipment location. The dispatcher can then carry that location information into radio coordination without requiring the caller to spend valuable time explaining where the incident occurred.
Testing and Commissioning of the Interoperability System
One of the most common acceptance methods for telephone–RoIP–radio integration is simply to dial a number from an explosion-proof telephone and confirm that a nearby portable radio produces audio.
That test proves only that one basic one-way path exists.
Formal commissioning should test the different communication actions separately. Start with an explosion-proof telephone calling a radio resource and verify whether PTT is asserted, whether the first word is clipped and whether the radio group receives clear audio. Then let a radio user transmit back and confirm that COR/COS detection and RTP return audio operate correctly. Rapid turn-taking should also be tested to determine whether PTT release and re-key timing introduces noticeable delays.
Dispatch-oriented systems should additionally verify:
Whether the correct device name and location are displayed when a fixed call station calls in;
Whether the dispatcher can select the intended Radio Resource accurately;
Whether Radio Busy status is clearly indicated and prevents unwanted channel override;
Whether telephone and radio users can take turns correctly after a voice bridge is established;
Whether recordings contain audio from both sides of the conversation;
Whether PTT and voice remain functional after network, SIP-server or RoIP-node failover;
Whether a predefined backup path exists if the Control Radio fails.
Final testing should also move beyond the control room and into the real hazardous area. Compressor-room noise, the microphone characteristics of the field telephone, fringe radio coverage and VPN-link latency are difficult to reproduce fully on a laboratory bench.
A practical interoperability system is not one where the telephone and radio can occasionally hear each other. It is one where fixed-location communications and mobile radio resources can be reliably connected, controlled, recorded and separated again by the dispatcher whenever operational conditions require it.
FAQ
Can a SIP Explosion-Proof Telephone Register Directly to a RoIP Gateway?
It depends on the RoIP Gateway and the overall system architecture. Some gateways can operate as SIP resources connected to a PBX or dispatch server and may support specific point-to-point SIP arrangements. However, it should not be assumed that every RoIP device can manage large numbers of SIP telephones like a conventional IP PBX. In larger systems, the SIP server or dispatch platform normally manages the telephones, while the RoIP Gateway provides access to radio resources.
Can One RoIP Gateway Connect Telephone Users to Multiple Radio Groups?
This depends on the number of gateway channels, the number of connected radios and the capabilities of the dispatch platform. A multi-channel RoIP Gateway can connect separate Control Radios on different channels, with each channel presented as an independent radio resource. The destination radio group can then be selected through number routing, programmable keys, dispatcher selection or business rules.
Can a RoIP Gateway Directly Convert DMR to P25 or TETRA?
Not in the simple sense of directly translating one radio air-interface protocol into another. Many RoIP systems connect compatible control radios from different radio systems and create interoperability at the audio and PTT-control layer. If the project requires deeper interoperability involving talk-group IDs, messaging, encryption or native digital signaling, dedicated system interfaces and specialized interoperability functions are required. A standard audio-based RoIP Gateway alone is not sufficient.
Can an Analog Explosion-Proof Telephone Be Integrated into a RoIP Radio Dispatch System?
Yes. A layered architecture can be used. The analog explosion-proof telephone first connects through an FXS Voice Gateway to the SIP or dispatch platform, which then connects to the RoIP radio resources. This allows existing analog field telephone wiring to remain in service while fixed telephones and radio users are brought into a unified dispatch workflow.
Does Connecting an Explosion-Proof Telephone to a Radio System Affect Its Existing Ex Certification?
Adding a SIP server, dispatch platform or RoIP Gateway on the central-system side does not automatically change the certification of the field explosion-proof telephone. However, the field device, power supply, cable entries, installation method and accessories must remain within the approved certification and project requirements. Any modification involving the certified explosion-protection structure should be reviewed separately.
