Five myths about ATC voice monitoring that could be putting your operations at risk

Unlike legacy analog circuits, where a dedicated line either worked or it didn’t, IP networks are dynamic by nature. Routing changes, variable loads, jitter and packet loss can affect voice quality in ways that come and go without anyone noticing. Add in the distributed architecture of a modern ATC system, with controller working positions, remote radio sites, gateways and third-party network segments all in the chain, and the picture gets complex fast.

Time and again, we see the same assumptions being made about what “good enough” monitoring looks like in this environment. Some of these assumptions are understandable. Some are inherited from the analog era. And some are just wishful thinking.

Here are five of the most common myths and the effects of letting them go unchallenged.

Myth #1: “Our network monitoring tools already cover us”

This is probably the most widespread assumption we come across, and it’s easy to see why. ANSPs typically have IT monitoring tools in place: device health dashboards, network performance trackers and maybe even some packet analysis capabilities. It feels comprehensive.

The problem is that generic network monitoring tools were built for generic networks. They’ll tell you if a router is overheating or if bandwidth utilization is spiking. What they won’t tell you is whether a controller can clearly hear a pilot.

ATC voice communications have unique characteristics that standard tools simply weren’t designed to handle: push-to-talk (PTT) dynamics, squelch behavior, air-ground vs. ground-ground call flows, ED-137 protocol conformance and radio frequency signal health. These are invisible to conventional IT monitoring.

In a multi-vendor environment, which describes most ANSPs, the blind spots compound further. Each vendor’s device monitoring is typically scoped to their own hardware. The gaps between systems are exactly where problems like to hide.

Myth #2: “If the equipment is online, voice quality is fine”

Device monitoring is useful. Knowing that your radios are powered on, connected and within their normal operating temperature is a good baseline. But it tells you almost nothing about whether voice communications are actually working.

Consider a real case we encountered. During idle periods – when no one is actively transmitting – a monitoring system flagged an estimated mean opinion score ( MOS ) of 1.0 on a specific channel. That’s as bad as it gets. Yet the actual audio quality during live transmissions was completely fine. Every standard device check indicated that the hardware was healthy.

What was happening here? A gateway was violating RFC 3550 and ED-137 by failing to increment RTP sequence numbers correctly during idle times, increasing by 10 instead of 1 with every packet. Receiving systems interpreted this as roughly 90 % packet loss. The gateway was “online” the entire time.

This distinction matters enormously in ATC, where channels spend a lot of time in silence between transmissions. Idle periods aren’t dead air; they’re when keep-alive packets maintain the channel’s readiness for the next critical transmission.

Knowing a device is “up” only tells you it’s breathing. It doesn’t tell you if it’s healthy.

Myth #3: “We run active tests, so we’d catch any issues”

Active testing has real value. Injecting synthetic test calls across the network gives you a controlled, end-to-end view of its performance at a specific moment in time. This is particularly useful during system commissioning and scheduled maintenance windows as well as in lab environments.

But “at a specific moment in time” is the operative phrase. IP networks are dynamic by nature. Packet loss, jitter and routing conditions can fluctuate from one minute to the next. An active test run at 9 am tells you nothing about what happens at 9:47 am when a network provider’s link quietly degrades.

There’s also the question of what active testing doesn’t cover. Test calls traverse predefined paths between artificial endpoints. They don’t reflect the actual call paths that real controllers use, capture how end devices behave in practice or reveal problems that only emerge under specific operational conditions such as a codec mismatch that only causes one-way audio when certain systems negotiate a call.

In one case, an ANSP was experiencing repeated MOS drops below the ED-136 requirement of 4.0 on live channels. Periodic active tests hadn’t flagged anything. Continuous passive monitoring of actual traffic eventually revealed 3 % packet loss between a radio site and the central network – not on every call, but enough to consistently degrade real controller experience.

Armed with this data, the ANSP had a concrete, documented case to bring to their network provider. Without it, the conversation would have gone nowhere, because in the absence of evidence, the blame game has no referee.

Active testing is like a periodic health checkup – it’s useful, but it won’t catch issues that develops between appointments.

Myth #4: “Controllers will tell us if something sounds wrong”

Relying on controller complaints as your primary detection mechanism is, frankly, the most reactive approach possible. By the time a controller raises a voice quality issue, the problem has already affected live operations. In a safety-critical environment, that’s too late.

But there’s a more unsettling dimension to this myth: some failures are completely invisible to controllers until the worst possible moment.

At one ROMATSA site, controllers reported that the transmit radios were unavailable on a specific frequency. The team followed standard procedure: switched to backup radios, restarted the affected equipment and the immediate problem appeared resolved.

What nobody knew yet was that the network jitter causing the failure had affected 11 radios across multiple sites, including the main and standby transmit radios for the emergency frequency.

Controllers had no way of knowing this. The backup was compromised. The emergency channel was effectively silent. Had an emergency occurred during this window, there would have been no way to communicate with an aircraft in distress.

It was systemwide impact analysis, not a controller complaint, that uncovered the full scope of the problem. As Cristian Stan, Voice Communications Engineer at ROMATSA , put it: “AVQA practically saved the day.”

Controllers can only report what they experience. They can’t report what they don’t know is broken.

Myth #5: “Our new IP system is causing problems that didn’t exist before”

This one comes up frequently after a major technology upgrade, and it’s understandable. You invest in new IP-based equipment, and almost immediately controllers start complaining about strange audio disturbances. The logical conclusion is that the new system is at fault.

Sometimes, though, the new system isn’t creating the problem; it’s revealing one that was always there.

A European ANSP experienced this firsthand. After switching to modern IP-based radios, controllers began hearing constant “clack” sounds in their headsets – brief audio interruptions occurring up to 450 times per minute on some frequencies. The ANSP attributed it to the new equipment and refused to sign off on it.

Further investigation revealed the truth: the culprit was a defective component installed near the ATC receiving antennas that had been generating electromagnetic interference for years. The old analog radios simply weren’t sensitive enough to pick it up. The new IP radios, with their improved sensitivity and faster response times, were exposing an infrastructure problem that had been silently lurking the whole time.

We’ve seen a similar dynamic with other interference sources. In one case, an electric fence around a horse pasture near a remote radio site generated enough RF noise to elevate the noise floor. In another, a high-power radio system in the extended VHF range was raising background noise levels by 15 dB across the entire ATC band. Neither issue was visible until modern IP-native radios started monitoring RSSI levels continuously.

What makes this myth particularly costly is how it plays out commercially. The ANSP that switched to the new system was convinced it was defective and refused to pay for it. Engineering teams with measuring equipment were dispatched across the country to investigate. The resolution – that the pre-existing interference source was the problem, not the new radios – could only be proven by the monitoring data.

Higher sensitivity isn’t a bug. It’s one of the most valuable things a modern system provides – as long as you can interpret what it’s telling you.

What all five myths have in common

Each of these misconceptions points to the same underlying gap: monitoring tools that weren’t designed for the specific demands of IP-based ATC voice communications.

Standard IT tools don’t speak the language of ATC. They average metrics over long periods rather than analyzing five-second slices that match typical controller transmission lengths. They have polling gaps that miss transient events. They don’t monitor RF signal health, PTT behavior or squelch dynamics. And they have no concept of ED-136 compliance, let alone the ability to generate regulatory reports for civil aviation authorities.

What proactive ATC voice monitoring requires is continuous passive observation of live traffic, not periodic snapshots or artificial test conditions. It needs to analyze every call, every packet, every moment. It needs enough ATC-specific context to distinguish a standards violation from a network hiccup, or a genuine interference event from a misconfigured codec.

The real question isn’t whether your current tools are doing something; it’s whether they’re doing enough, and whether you’d know the difference if they weren’t.

Time to pressure-test your assumptions

The move to full IP voice systems is the right direction for ATC. It brings flexibility, scalability, resilience and the foundation for advanced operations such as virtual centers and remote towers. But it also introduces a class of dynamic, intermittent and sometimes invisible failure modes that analog systems never had.

The ANSPs that navigate this well aren’t necessarily the ones with the most sophisticated hardware. They’re the ones who ask the crucial questions about their monitoring: what are we actually seeing? What are we missing? And if something goes wrong with the emergency frequency at 2 am, will we know before a controller calls to complain?

There’s also a regulatory dimension that often gets overlooked. Civil aviation authorities can request evidence that ED-136 requirements are being met. Without continuous monitoring of live traffic, including the ability to produce historical MOS reports, that’s a very difficult question to answer on short notice. The data needs to exist before the evidence is requested.

If any of the five myths above sound familiar, they’re worth taking seriously. Not because failure is inevitable, but because in a domain where the stakes are this high, visibility isn’t a nice-to-have; it’s the whole point. That’s exactly what AVQA provides – continuous ATC-specific voice monitoring that gives you the evidence to act before a problem becomes a crisis.