Push to talk (PTT) is a half-duplex voice communications method where a user holds down a switch to transmit audio and releases it to listen. It is the defining characteristic of operational radio communications in air traffic control, governing every voice exchange between pilots and controllers, and between controllers themselves.
PTT is what keeps the ATC voice loop orderly. Because everyone shares the same VHF frequency, only one person can talk at a time, and the act of keying the microphone is what claims the channel. That simple mechanical gesture sits at the heart of every clearance, instruction, and read-back in controlled airspace, and any degradation of how the PTT event is captured, transmitted, or monitored can have direct safety consequences.
How push-to-talk works
A PTT system has two states: idle (receiving) and transmitting. When the user presses the PTT switch – a button on a pilot’s control yoke, a throttle-mounted trigger, a controller’s foot pedal, or a hand-held microphone – the radio transmitter is keyed and the user’s voice is broadcast on the assigned frequency. Releasing the switch returns the radio to listening mode.
This is fundamentally different from the full-duplex calls people make on a telephone or VoIP softphone, where both parties can speak and hear each other simultaneously. With PTT, the channel is a shared resource, and politeness is enforced by physics. If two people key at the same time, the radio receivers on the ground or in the cockpit pick up an interference pattern that often renders both transmissions unintelligible.
In legacy analog ATC voice systems, the PTT signal travelled as a simple electrical contact closure that drove the transmitter directly. In modern IP-based systems built around EUROCAE ED-137, the standard governing voice communications in IP-based ATC, PTT becomes a separate signalling event carried alongside the RTP audio stream. The audio packets convey the speech; a parallel signalling channel tells the receiving system that the talker is active and that the incoming audio is intentional transmission rather than ambient noise.
Push to talk in air traffic control
In ATC, PTT is woven into both sides of the voice infrastructure. On the air-ground side, every pilot transmission to a tower, approach, or en-route controller starts with a PTT keying. On the ground-ground side, controllers use PTT-style interphone and intercom systems to coordinate handoffs between sectors, request services from adjacent units, and run hotline circuits to military or airport operations.
The reasons PTT remains the standard in ATC after decades, even as the rest of voice communications moved to full-duplex, are operational. A single shared frequency is the most efficient way to broadcast instructions to every aircraft in a sector at once. The half-duplex constraint forces disciplined turn-taking and read-back, which is itself a safety mechanism. And the physical act of pressing a button gives the speaker a clear, unambiguous moment of intent. There is no confusion about whether you are on the air.
ATC voice systems are increasingly migrating from analog and TDM circuits to IP transport, driven by airspace modernization programs and the cost and flexibility advantages of converged networks. That migration changes the engineering picture entirely. PTT events that were once hardware contact closures are now signalling messages traversing routers and switches, and the audio they gate is encoded, packetised, and reassembled. Each of those steps is a potential source of latency, jitter, and loss, which is exactly why monitoring matters.
PTT and voice quality monitoring
The shift to IP-based ATC voice is what brings push-to-talk into the world of voice quality assurance, and it is where voice quality monitoring for air traffic control becomes directly relevant. In a TDM-era system, PTT either worked or it didn’t, and faults tended to be hard failures that operations staff noticed quickly. In an IP environment, PTT can degrade in subtle ways that don’t trigger an alarm but quietly erode the quality of every transmission.
A handful of measurements are particularly worth tracking on PTT in an IP-based ATC voice deployment. The first is PTT-to-audio latency, the interval between the PTT keying event and the first audible audio packet at the receiver. If that gap grows, the first syllable of every transmission gets clipped, and pilots and controllers learn (often without realizing it) to start every exchange with a throwaway “uh” to compensate. Tracking this latency over time exposes drift in network conditions or codec configuration long before it becomes operationally disruptive.
Stuck PTT detection is the second. A PTT signalling event that opens but never closes blocks the frequency for everyone else on it. Catching a stuck PTT in monitoring data, rather than waiting for a controller to call it in, shortens the time to resolution dramatically.
Simultaneous transmissions are the third. When two transmitters key at once, the audio is degraded by interference. Correlating PTT events across multiple endpoints lets a monitoring system flag step-on events and quantify how often they are happening on a given sector or frequency.
And finally, audio quality during keyed transmission. Once PTT is active, the usual voice quality metrics apply – packet loss, jitter, codec performance, mean opinion score, and so on. The PTT signalling provides the trigger that tells the monitoring system “this is the audio that mattered” and lets it filter quality measurements to only the speech that was actually transmitted, rather than averaging across silent listening periods.
For an ATC operator, voice is the operational interface, it is how separation gets maintained, how diversions get coordinated, how emergencies get worked. Monitoring PTT alongside the audio stream isn’t a nice-to-have; it is how you turn a voice network into something that can be measured, trended, and held to a service-level standard.
PTT challenges and pitfalls
Even with healthy infrastructure, PTT introduces voice quality issues that simply don’t exist in full-duplex telephony. The most common is clipping: speakers releasing the switch before the last word is fully transmitted, or starting to talk before the transmitter has fully keyed. This is partly a human factors issue and partly a system one; if there is a measurable delay between key-down and the audio path being live, even disciplined operators will lose syllables.
Step-on transmissions are another structural challenge. Because nobody on the frequency knows in advance who else is about to key, collisions are inevitable, and the resulting heterodyne can mask a critical instruction entirely. Controllers often have to repeat clearances when a step-on is suspected, which adds workload and frequency congestion.
Stuck microphones, where a PTT switch jams or a faulty headset causes a continuous transmission, are rarer but operationally serious. A stuck mic can render a frequency unusable until the offending transmitter is identified and shut down, which in busy airspace can mean rerouting traffic or deploying a backup frequency.
In IP-based deployments, the additional concerns are jitter buffer behavior during the ramp-up of a transmission, codec algorithmic delay, and the synchronization between the PTT signalling and the RTP media stream. ED-137 specifies how these elements should behave, but conformance and real-world performance aren’t always the same thing, and that gap is exactly what monitoring is built to close.