Your crash phone system is the backbone of your airport's emergency response capability. When the tower initiates an alert, the system has to work — every time, without fail. But many airports are running on aging analog infrastructure that introduces risks they may not fully appreciate until something goes wrong. Here are five signs that it's time to evaluate a modern replacement.
If your crash phone notification relies on a dedicated copper or fiber line running between the tower and your ARFF station, you have a single point of failure. That line can be severed by construction activity, damaged by weather, or degrade over time without anyone knowing. Many airports have inherited infrastructure that predates current staff — buried lines whose exact routes aren't fully documented.
A regional airport recently discovered this vulnerability when a parking lot expansion project ran into their buried crash phone line. The line that connects their tower beacon alarm to their ARFF building was in the path of heavy equipment, and the airport had no backup notification method if it was severed.
Modern IP-based systems eliminate this dependency by using the airport's existing network infrastructure, which typically already has built-in redundancy — multiple paths, managed switches, and generator-backed power.
If your current crash phone system triggers an alarm — and that's all it does — your firefighters are rolling without critical information. The typical follow-up: get in the truck, drive out to the apron, and call the tower on the radio to ask what the emergency is. That radio exchange costs precious seconds and introduces the risk of miscommunication.
Modern systems deliver the alert details simultaneously with the alarm. The tower controller selects an alert type, speaks the details, and that audio plays on speakers in the ARFF station along with visual indicators showing the alert type. Advanced systems can even transcribe the audio and extract data points like runway, aircraft type, and ETA for display on screens — giving responders complete situational awareness before they leave the building.
A single alarm tone for every situation — crash alert, medical emergency, fuel spill, daily test — means your entire team responds at full readiness for every activation, including routine tests. This isn't just inefficient; it creates alarm fatigue that can slow response when it matters most.
IP-based crash phone systems support multiple configurable alert types. Each type can trigger different devices, different strobe colors, different alert tones, and different pre-recorded announcements. A red strobe means crash alert. Blue means medical. Green means test. Your ARFF team knows what they're dealing with the instant the alarm activates — by sight and sound, before anyone speaks a word.
Analog crash phone systems are essentially passive circuits. If a component fails — a speaker burns out, a line develops a fault, a contact closure corrodes — nothing alerts you. You find out when the system doesn't work during an actual emergency or, if you're lucky, during a scheduled test.
Modern systems actively monitor every endpoint — phones, speakers, strobes, contact closures — checking their status automatically every 30 seconds. If any device stops responding, the system immediately notifies both the airport and the vendor's support team. Visual dashboards display the real-time status of every device, with color-coded indicators showing which endpoints are online, in use, or experiencing problems.
Need to add an alarm in a new building? With analog systems, that means running new cabling — potentially across runways, under taxiways, or through areas where trenching isn't practical. Want to notify mutual aid agencies off airport property? That's a whole different set of infrastructure challenges.
IP-based systems scale by adding endpoints to the existing network. If a building has network connectivity, it can have crash phone notification — speakers, strobes, phones, or all three. Off-property locations can be reached via wireless connectivity, FirstNet, or outbound phone calls to cell phones and landlines. The system scales from two endpoints to two thousand without changing the core architecture.
If any of these signs apply to your airport, the risk isn't hypothetical — it's a matter of when, not if, your current system will fail to perform when you need it most. The good news is that migrating to an IP-based system doesn't have to be disruptive. Many airports start with a direct replacement of their existing setup — same functionality, better reliability — and add capabilities over time as budget and operational needs dictate.
Not sure if your crash phone system is due for an upgrade? Contact KOVA Corp for a no-obligation assessment of your current emergency notification infrastructure. Want to know more about KEANS? Click here.
In March 2024, the FAA released a significant update to Advisory Circular 150/5210-7E, Aircraft Rescue and Fire Fighting Communications. If you’re responsible for ARFF communications at your airport, this document is worth a close read. It replaces the previous version (7D, dated 2008) and reflects how much the landscape has changed in the last sixteen years — particularly when it comes to crash phone systems.
The updated AC doesn’t mandate a specific technology. But the guidance it provides paints a pretty clear picture of where the FAA expects airport emergency communications to be heading. And if your airport is still running analog crash phone lines, some of these recommendations may be hard to meet without a modern alternative.
The AC identifies the crash phone — a dedicated landline between the control tower and ARFF station — as one of the primary methods for initial emergency notification (Section 3.2). That part hasn’t changed. What has changed is the level of detail the FAA now provides around system reliability and performance expectations.
Section 3.1.1 lays out several enhanced recommendations for crash phone systems. Among them: the emergency direct-line telephone should not transmit through any system that could introduce delays or diminish clarity. The FAA specifically recommends avoiding the use of your administrative phone system (PBX or conference bridge) for crash phone functions. Central components should be fully redundant and fault-tolerant, with geographically diverse communications paths encouraged for fault tolerance.
There’s also a new emphasis on network monitoring. Section 3.1.1.8 encourages monitoring all devices in the crash phone network using protocols like SNMP. And Section 3.1.1.7 recommends a visual indication of which stations have picked up the call — something legacy analog systems simply can’t provide.
Traditional analog crash phone setups typically consist of a button in the tower that triggers an alarm connected to the ARFF station via a dedicated physical copper line. That single line is the entire notification path. If a construction project severs it, if the wiring degrades over time, or if the connection simply fails, your emergency notification capability goes with it — and you might not know until someone actually needs it.
The updated AC’s guidance around redundancy, fault tolerance, network monitoring, and visual call status all point toward capabilities that analog infrastructure was never designed to deliver. It’s not that the FAA is saying your analog system is non-compliant. The AC is advisory, not regulatory (though it is mandatory for airports receiving AIP or PFC funding). But the direction of the guidance is clear: airports should be moving toward systems that offer more reliability, more visibility, and more flexibility than a single copper pair.
KEANS is an IP-based emergency alert notification system built specifically for airports. It rides on your existing airport network infrastructure — the same network that supports your computers, phones, and security systems — rather than relying on dedicated analog cabling. Here’s how that maps to the AC’s updated recommendations:
Redundancy and fault tolerance. Your airport has already invested in making its network redundant. KEANS leverages that investment. The system runs on your internal LAN, typically on a dedicated VLAN, and doesn’t depend on public internet connectivity. If your ISP goes down, KEANS keeps working.
No delays or diminished clarity. KEANS doesn’t route through your administrative PBX or conference bridge. It’s a dedicated crash phone platform that prioritizes emergency traffic. When a crash phone is picked up off-hook, it instantly bridges all connected stations with no dialing required.
Device monitoring. Every endpoint on the KEANS network — phones, speakers, strobes — is automatically monitored every 30 seconds. If a device goes offline, both the airport and KOVA are notified immediately. Compare that to an analog line where a severed cable might go undetected until an actual emergency.
Visual call status. KEANS provides real-time visual indication of which stations have joined the conference call — exactly the kind of capability the AC recommends in Section 3.1.1.7.
The AC also discusses multifunction notification (Section 3.5) — the ability to simultaneously notify ARFF, airport police, airport management, military units, and other authorities using a conference circuit. KEANS handles this natively. When the tower activates an alert, KEANS can notify police, fire, Homeland Security, Coast Guard, maintenance, and other stakeholders both on and off the airport property, all at once.
The system also supports multiple alert categories — crash alerts, medical emergencies, fuel spills, wildlife incidents, daily tests — each with different notification groups, different strobe colors, and different pre-recorded announcements. Your ARFF team gets specific, actionable information immediately rather than a generic siren that requires a follow-up radio call.
And because KEANS integrates with platforms like Everbridge, airports can extend emergency notifications well beyond the crash phone circuit to include mass notification via text, email, and mobile app — reaching personnel who aren’t sitting next to a crash phone handset.
Airports don’t have to rip and replace everything overnight. A practical migration starts with the core: a server (physical or virtual), a phone in the tower, and contact closure adapters that can trigger your existing alarms and sirens. If the tower already has a button that energizes a circuit to set off an alarm, KEANS can replicate that exact behavior — the only thing that changes is what the controller presses in the tower.
If your airport already has a virtual server environment, turnaround can be as fast as two weeks from purchase order. The endpoints are powered over Ethernet (PoE), so a single Cat 6 cable provides both data and power — no separate electrical runs needed.
The first step is understanding your current setup. What does your existing alarm circuit look like? Is your airport network present in the tower and ARFF areas? Do you have a virtual server environment? With those answers, we can scope a solution that replaces your aging analog infrastructure, aligns with the updated AC guidance, and gives you a growth path for enhanced capabilities as your needs evolve.
The airports that have made this transition aren’t looking back. If you’d like to learn more about how KEANS can help your airport meet the intent of AC 150/5210-7E, reach out to us at kovacorp.com. We’re happy to walk through your current setup and show you what a modern crash phone system looks like.
Note: FAA Advisory Circular 150/5210-7E is guidance material, not regulation. It is mandatory for airports receiving Federal grant assistance (AIP) or Passenger Facility Charge (PFC) funding. Consult the full AC and your regulatory contacts for compliance-specific questions.
When a tower controller initiates a crash phone alert, every second counts. But critical details — runway, aircraft type, fuel load, souls on board — are delivered verbally, often at a pace that's difficult to catch in the chaos of an emergency response. What if those details were automatically extracted from the audio, transcribed, and displayed on screens throughout the airport before the first ARFF truck even leaves the station?
In a conventional crash phone scenario, the tower controller picks up the phone, presses a button, and speaks. The alert audio broadcasts to ARFF stations, operations, and other connected locations. Firefighters hear the message, gear up, and roll. But if they miss the first few seconds — or if the audio quality isn't perfect — they may head out without key details. The follow-up comes over radio, eating into response time.
The problem compounds when airports need to notify external agencies. Someone has to call mutual aids one by one and manually log into an operations management system like Everbridge or Veoci, type in the event details, and trigger a secondary notification. At many airports, the plane is already on the ground for five minutes or more before that secondary alert goes out.
Modern emergency notification systems now incorporate AI-powered speech-to-text capabilities that process the tower controller's spoken alert in real time. The audio is automatically transcribed, and an intelligent extraction engine pulls key data points from the transcript: alert type, runway ID, flight number, aircraft type, ETA, fuel amount, souls on board, and wind conditions.
This extracted data populates digital displays in the ARFF station, operations center, vehicles, and mobile devices within seconds of the alert being initiated. Responders get structured, at-a-glance information — not just replayed audio — before they even leave the building.
The system goes further by cross-referencing the flight number with FlightAware data. If the tower controller says the aircraft is an A320, but the actual transponder data shows an A333, the system pulls the correct aircraft information. It also retrieves real-time wind data and, for active flights, can display the aircraft's current position on a map.
The extracted data doesn't just display on screens — it can be automatically forwarded to external platforms. Through integrations, the system can push structured alert data to Everbridge, Veoci, INDMEX, or similar operations management tools. The integration triggers the alert process within those platforms automatically, populating event parameters without anyone touching a keyboard.
This eliminates the manual data entry bottleneck entirely. The moment the tower controller hangs up the phone, the alert is being broadcast across every connected system. One action in the tower initiates a cascade of notifications — audio to ARFF stations, visual displays with extracted data, push notifications to mobile devices, and automated entries in incident management platforms.
Companion mobile apps for iOS and Android extend the system's reach beyond fixed installations. When an alert is triggered, authorized users receive push notifications on their phones or tablets. The app displays the full transcription, extracted key information in easy-to-read cards, a FlightAware map showing the aircraft's position, and the ability to play back the original alert audio.
This is particularly valuable for personnel who aren't stationed at a fixed location — airport management, mutual aid agencies, or off-duty responders who may need to be recalled. The information reaches them without relying on radio communications or word-of-mouth relay.
The speech-to-text processing can run on-premise, using a physical server installed at the airport, or through a hosted cloud solution.
Both options process the audio with the same speed and accuracy. The choice comes down to your airport's IT infrastructure, security policies, and preference for on-site versus cloud-based processing.
Airports that have deployed these capabilities report measurable improvements. Pre- and post-installation testing at major international airports has documented response time improvements of seventeen seconds or more — a significant margin when FAA guidelines call for ARFF equipment to reach any point on the operational runway within three minutes.
Seventeen seconds might not sound like much, but in emergency response, it can mean the difference between a contained incident and a catastrophic outcome. Automated transcription and data extraction eliminate the gaps where information gets lost, delayed, or miscommunicated.
See more about KEANS speech-to-text crash phone technology or schedule a live demonstration of the KEANS system with KOVA Corp.
If your airport still relies on analog crash phone circuits — physical copper lines running between your tower and ARFF station — you already know the risks. Those lines age, get damaged during construction projects, and offer no redundancy when they fail. A growing number of airports are making the switch to IP-based crash phone systems, and the results speak for themselves.
Traditional crash phone setups typically consist of a button in the tower that triggers an alarm — a siren or beacon — connected to the ARFF station via a dedicated physical line. The system works until it doesn't. Construction projects can sever buried cables. Aging wiring degrades over time. And when that single point of failure goes down, your emergency notification capability goes with it.
Many airports discover this vulnerability the hard way. A recent conversation with a regional airport in Pennsylvania revealed a common scenario: a parking lot expansion project ran into their buried crash phone line, threatening to sever the only notification path between the tower and their maintenance shop. Their response? Searching for an IP-based alternative that eliminates the dependency on dedicated physical cabling entirely.
Modern crash phone solutions ride on your airport's existing IP network — the same network infrastructure that supports your computers, phones, and security systems. Instead of running separate copper lines between buildings, the crash phone system uses the airport's LAN to connect endpoints like phones, speakers, strobe lights, and notification devices.
This approach offers significant advantages. Your airport has already invested in making its network redundant and secure. An IP crash phone system leverages that investment rather than duplicating infrastructure. Most IT departments simply create a VLAN — a logical carve-out on the existing network — to keep crash phone traffic isolated and secure.
The endpoints themselves are powered over Ethernet (PoE), meaning a single Cat 6 cable provides both data connectivity and electrical power. No separate power runs, no additional electrical work — just plug into a PoE switch and the device is online.
The benefits go well beyond eliminating vulnerable analog lines. IP-based systems enable capabilities that simply aren't possible with legacy technology:
Multiple alert types: Instead of a single alarm tone, the tower can select from different alert categories — crash alerts, medical emergencies, fuel spills, wildlife incidents, or daily tests. Each alert type can trigger different notification groups, different strobe colors, and different pre-recorded announcements. Your ARFF team gets the right information immediately, not a generic siren that requires a follow-up radio call.
Scalability from simple to sophisticated: A small regional airport might start with a phone in the tower and a contact closure at the ARFF station — functionally identical to what they have now, but running over the network. Over time, they can add speakers, strobes, mobile app notifications, and integration with platforms like Everbridge or operations management systems, all without replacing the core system.
24/7 endpoint monitoring: Every device on the system is checked automatically every 30 seconds. If a phone, speaker, or strobe goes offline, both the airport and the vendor are notified immediately. Compare that to analog systems where a severed line might go undetected until someone actually needs it in an emergency.
No dependency on public Internet: The system runs on your internal airport network. If your ISP goes down, your crash phone keeps working. The only external connectivity requirement is for optional features like remote vendor support or speech-to-text processing.
Airports don't have to rip and replace everything overnight. A practical migration starts with the core: a server (physical or virtual), a phone in the tower, and contact closure adapters that can trigger your existing alarms and sirens. If the tower already has a button that energizes a circuit to set off an alarm, the IP system can mimic that exact behavior — the only thing that changes is what they press in the tower.
If your airport already has a virtual server environment, the turnaround can be as fast as two weeks from purchase order. The contact closure devices and IP phones are standard stock items. The server software installs on a virtual machine on your existing hardware, so there's no waiting on specialized equipment.
One of the most compelling aspects of an IP-based emergency notification system is its versatility. Airports using these systems have deployed them for scenarios well beyond traditional crash alerts:
Lightning detection warnings with multi-color strobe lights around the terminal. Snow removal notifications pushed to tenant phones. Human trafficking awareness phones in terminal restrooms that auto-dial airport police. TSA checkpoint plunger buttons that simultaneously call law enforcement and play pre-recorded passenger rerouting announcements over the terminal PA.
These use cases don't require separate systems. They're additional configurations on the same platform, using the same network infrastructure, managed from the same interface.
The first step is understanding your current setup: What does your existing alarm circuit look like? Is your airport network present in the tower and ARFF areas? Do you have a virtual server environment? With those answers, a vendor can scope a solution that replaces your aging analog infrastructure, provides immediate reliability improvements, and gives you a growth path for enhanced capabilities down the road.
The airports that have made this transition aren't looking back. Improved response times, eliminated single points of failure, and the ability to scale notification capabilities as needs evolve — that's what a modern crash phone system delivers.
Ready to modernize your airport's crash phone system? Click here to see more about KEANS Airport Crash Phone solutions or contact KOVA Corp to schedule a live demonstration.
