A two-way radio normally communicates with another radio on a channel or talk group. A telephone works differently: the user enters a destination number, the switching system interprets that number, and the network establishes a point-to-point call. Connecting these two communication methods therefore requires more than simply linking their audio interfaces.
A radio can call a phone number only when the deployed system supports destination selection, an authorized telephone route and coordinated talk control. Some networks provide a telephone interconnect within their radio infrastructure; others need a compatible radio gateway and telephone platform. DTMF-to-SIP is one possible integration workflow, not a built-in capability of every radio or RoIP gateway.
Dialing Begins with Signaling
Before considering gateways or IP networks, it is useful to understand what telephone dialing actually does. Dialing does not directly create a voice path. Its first purpose is to tell the communication system which destination the caller wants to reach.
Early telephone networks depended on operators who manually connected calls. Rotary telephones later introduced pulse dialing, where each digit was represented by a specific number of electrical interruptions. Dialing the number 5, for example, generated five pulses that the exchange counted and interpreted.
Dual-Tone Multi-Frequency signaling, commonly known as DTMF, represents each key with two simultaneous frequencies: one from a low-frequency group and one from a high-frequency group.
For example, the digit 5 uses 770 Hz and 1336 Hz, as shown in ITU-T Q.23 (11/1988), section 6 and Figure 1/Q.23. This defines the tone pair; reliable detection over a particular radio path still depends on audio levels, distortion, timing and the receiving implementation.
Modern IP telephony uses SIP for call establishment, but DTMF remains important in many communication systems. In a radio-to-phone application, DTMF can provide the bridge between a radio keypad and the telephone numbering environment. The radio generates the digits, the integration system detects them, and those digits are then used to create the required SIP call.
Two Radio Environments Require Different Approaches
Not every radio system needs the same architecture. The first design decision is to identify whether telephone interconnection is already supported by the radio infrastructure or must be introduced externally.
Trunked Radio Networks
Some digital trunked networks support telephone interconnection through their switching infrastructure. Availability depends on the network interface, enabled service, terminal functions and operator permissions. A technology name such as TETRA or DMR does not by itself establish that telephone calling is available on a particular installation.
Where that service is implemented, the terminal can send destination information using the radio network’s supported signaling, and the infrastructure handles the telephone connection. It need not use audible DTMF on the radio link. Confirm the actual network and terminal documentation before deciding whether an additional gateway is required.
Conventional Radio Systems
A conventional radio channel usually has no telephone switching service by itself. A connected base or mobile radio can supply audio and control to an integration system, or a suitably equipped repeater may provide its own telephone interface. Neither a keypad nor an audio connection alone establishes telephone access.
Where an external radio-to-SIP gateway is used, it must match the radio’s documented audio and control interface. The deployed gateway or application must also support the required dialing logic, SIP call handling and PTT behavior. Some gateways only transport audio or call a fixed destination; generic RoIP capability does not guarantee arbitrary number dialing.
A compatible integration can preserve existing radio frequencies and much of the field workflow. It still requires a review of shared-channel loading, permissions and user procedures; telephone access may introduce longer conversations and new ways to occupy the radio resource.
What the Radio Terminal Must Support
The ability to connect radio audio with a telephone platform does not automatically mean that every radio can dial arbitrary numbers. The terminal itself must provide a practical way for the user to send destination information.
For the conventional in-band DTMF example below, two capabilities are needed at the radio user interface:
Number entry: the user needs a keypad or another interface that allows a destination number to be entered.
DTMF transmission: the radio must be capable of generating DTMF tones that can be detected by the integration system.
Even with both capabilities, variable number dialing is possible only if the receiving integration system can collect and validate those digits, recognize the dialing procedure and initiate a permitted call. For a native digital interconnect, check its destination-entry and signaling requirements instead.
A radio without a numeric keypad may still participate through a supported preset destination, hotline or dispatcher-established patch. A programmed key can initiate a call only when the terminal and receiving system implement that trigger. An ordinary PTT press must not be assumed to start a telephone call.
This distinction is important during system design. A project should not specify unrestricted radio-to-phone dialing unless the actual field terminals are capable of supporting the required user interaction.
From DTMF Digits to a SIP Call
The following is an example design for calling an office extension from a conventional radio through a gateway that explicitly supports DTMF digit collection. The SIP stages follow RFC 3261, sections 13 and 15; the radio dialing grammar, permissions and PTT mapping are implementation responsibilities.
Request access and enter the destination. The user follows the configured access procedure and sends digits on the permitted radio resource. Any prefix, completion key or interdigit timeout must match the deployed design.
Collect and authorize the number. The gateway or application detects the sequence, rejects incomplete or disallowed requests and maps the accepted destination to the telephone dial plan.
Initiate the telephone call. A SIP user agent sends an INVITE to the configured platform. Routing and trunk permissions determine whether the number can be reached.
Present call progress. Ringing, busy, denied and no-answer outcomes need usable feedback on the radio side; SIP response codes alone are not an audible user interface.
Establish media and take turns. On acceptance, the SIP exchange completes and negotiated media carries speech. The integration controls radio transmit/receive direction while users follow the agreed PTT procedure.
Release the call. A defined radio hang-up command, telephone hang-up or configured timeout clears the session and releases the channel. Releasing PTT ends a transmission; it does not necessarily end the telephone call.
To the operator, the process can resemble a normal telephone call: enter a number, wait for connection and begin speaking. Technically, however, several different signaling and media processes are being coordinated in the background.
Why Talk Control Is More Complex Than Dialing
Establishing the SIP call is only part of the problem. Radio and telephone users do not normally communicate in the same way.
A telephone conversation is generally full duplex. Both parties can transmit and receive audio at the same time. A conventional two-way radio channel is normally half duplex. One side transmits while the other side listens, and the direction changes according to PTT operation.
The integration layer must therefore control when telephone audio is transmitted onto the radio channel and when the radio side is allowed to transmit back toward the telephone user.
The gateway needs an explicit method to key the radio transmitter and to determine when radio reception is active. A physical PTT output controls transmission; COR/COS or a supported digital interface can report receive activity. VOX or voice activity detection may infer activity from audio where the design supports it, but noise, pauses and clipped syllables must be tested. These are different input and control functions, not interchangeable guarantees of correct turn-taking.
Correct timing matters. Continuously keying the radio for the whole telephone call can prevent field users from replying. Slow key-up or release can clip speech, while simultaneous radio and telephone speech needs a defined arbitration rule. Standard SIP call establishment does not provide universal radio floor control. Test any mute, phone-side PTT, VOX or dispatcher control mechanism actually used, including a safe release when the IP connection fails.
For this reason, audio quality alone should not be used to judge whether a radio-to-phone integration is successful. Talk-control behavior, switching delay and user operating procedures are equally important.
Call Direction Can Be Designed Around the Workflow
Technically allowing a field radio to enter arbitrary telephone numbers does not always mean it is the best operating method. In many industrial and command environments, field personnel use radios because communication must remain fast and simple.
Asking an operator to activate the correct radio function, enter several digits, wait for call establishment and then manage PTT may introduce unnecessary steps. The required call direction should therefore be selected according to the real operating workflow.
A maintenance team, for example, may only need to reach one control-room extension. In that case, a predefined hotline can be more efficient than unrestricted dialing. A dispatcher, by contrast, may need telephone access to multiple radio channels and therefore benefit from channel extensions defined in the IP PBX.
Telephone-to-radio access is often particularly practical. An office user can dial an extension assigned to a radio resource. The communication system then establishes the connection to the required channel without asking the field radio user to dial anything.
Depending on verified terminal, gateway and platform support, a project can select among these workflows:
radio keypad dialing to authorized telephone destinations;
one-key hotline calling from selected radio terminals;
telephone extensions mapped to individual radio channels;
dispatcher-controlled radio and telephone interconnection;
predefined emergency routes for critical operating scenarios.
The objective is not to make a radio behave exactly like a telephone. It is to give users the shortest practical path to the person or communication resource they need.
Shared Channels Change the Meaning of a Phone Call
Another important consideration is privacy. A telephone call is normally understood as communication between two endpoints. A conventional radio channel is a shared communication resource.
If telephone audio is transmitted onto a conventional radio channel, other radios monitoring that channel may also receive the conversation. Likewise, other transmissions received on the channel may enter the connected telephone call.
This behavior is not necessarily a fault. In operational environments such as maintenance, security or emergency response, group awareness can be useful. However, it must be considered when telephone conversations contain sensitive or personal information.
Digital individual-call functions may limit which users are addressed, but they do not by themselves establish encrypted or private end-to-end telephone communication. An audio gateway can also lose unit identity, emergency flags, location, encryption context or priority information at the boundary. Confirm each required feature separately; a successful voice call demonstrates only that voice path.
Numbering permissions should be designed with radio-channel access. The field radio communication plan should identify which operational resources may be bridged. A PBX may see only the gateway account, not the individual radio user. Do not treat an audible DTMF access sequence as strong authentication. Restrict telephone destinations, incoming access and available radio resources using controls supported by the actual system, and verify both allowed and denied calls.
Planning the Solution Before Deployment
A radio-to-phone project should begin with the communication workflow rather than with individual devices. The engineering team first needs to understand what users are expected to accomplish.
Important questions include:
Which radio users need to initiate telephone calls?
Do their radios contain numeric keypads?
Can the terminals generate usable DTMF signaling?
Should users dial arbitrary numbers or only predefined destinations?
Which radio channels need telephone access?
Does the existing radio system already support telephone interconnection?
Will calls remain internal to the IP PBX or reach external telephone networks?
How should PTT control and radio activity detection operate?
Should telephone audio be available to an entire radio channel or only selected users?
Network conditions should also be evaluated. SIP signaling and RTP media depend on the IP path between the integration point and the communication platform. Excessive latency, packet loss or unstable connectivity can affect call setup, voice quality and talk-control timing.
Before commissioning, test both directions of communication with the actual terminals and software versions. Include incomplete or repeated digits, denied numbers, busy and no-answer outcomes, PTT switching, first-word clipping, simultaneous speech, call release, occupied channels and network interruption. A failed or abandoned call must not leave the radio transmitter keyed or the telephone route indefinitely occupied. Record which digital features cross the interface and which are unavailable.
The result should be an operating method that feels natural to both field and office users. A technically connected system is not sufficient if the call procedure remains too complicated for everyday use.
FAQs
Can a radio call an external mobile phone?
Only if the radio calling workflow works and the connected telephone platform has an authorized route to that number. Public emergency-number access, caller location and callback behavior require separate validation with the applicable service and authority; an ordinary outbound call is not proof of emergency-calling suitability.
Can a radio channel have a SIP extension shared by several radios?
Where the gateway and dial plan support it, an extension can represent a channel or selected talk resource. Radios receiving that resource may hear the same telephone audio. This is not a separate private extension for every radio, and one shared RF resource cannot provide independent simultaneous conversations merely by adding more telephone numbers.
Can radio-to-phone calls be recorded?
Only where a compatible recording resource receives the required media and is authorized to do so. Test capture in both directions and the available channel, caller and timestamp information. A recording system may identify the gateway rather than the individual radio speaker; retention and access controls follow the applicable policy.
Does DTMF always travel as audible tones?
No. On an established IP media leg, RFC 4733, sections 2 and 3, defines RTP telephone-event payloads for digit events. This is distinct from SIP call signaling and requires compatible negotiation and handling. A gateway collecting initial radio digits to create an INVITE performs a different task from relaying keypad events during an existing call.
Does releasing PTT hang up the telephone call?
Usually it only ends the current radio transmission. The user needs the release action defined for that implementation, while phone hang-up, no-answer handling and configured timeouts must also be mapped correctly. Include an abandoned-call test so a lost user or failed connection does not block the resource.
