01
Legacy dependencies
Analog interfaces, PBXs, recorders and operational systems may still be required even when the target architecture is SIP/IP.
ATC Voice Modernization Use Case
Modernize ATC voice without disrupting operations.
Use Sentinel SBCs and Mediatrix gateways to connect legacy ATC voice, SIP networks, recording systems and distributed sites through a controlled migration path—without forcing an immediate rip-and-replace.
Preserve operationsKeep critical voice paths available during migration.
Control the SIP edgeApply SBC policy, normalization and topology hiding.
Bridge legacy systemsConnect analog, PBX and selected recorder-adjacent interfaces.
Modernize in phasesPilot, validate and scale without a forced cutover.
How the use case is resolved
Current systems → M5 secure interworking → modernized services
Conceptual architecture
Current ATC environment
Tower voice
Legacy PBX
Analog interfaces
Recording paths
Remote sites
↓
M5 secure interworking layer
Mediatrix gateways
Sentinel SBC
SIP policy
Routing control
TLS/SRTP where supported
↓
Modernized ATC voice services
Secure SIP core
Operations center
Remote tower
Controlled inter-site voice
Centralized policy
ContinuityExisting workflows remain available.
SecuritySIP exposure is controlled.
MigrationChange is phased and validated.
Civil & military environmentsArchitecture patterns for towers, airfields, operations centers and distributed sites.
Legacy coexistencePreserve selected analog, PBX and gateway-connected services during modernization.
SIP-aware protectionUse SBC controls instead of relying only on generic network security.
Engineering validationAssess latency, recording, redundancy, security and operational requirements before deployment.
The operational problem
ATC voice modernization is difficult because the old and new environments must coexist.
The customer is not simply replacing phones. The project must preserve operational voice, reduce SIP risk, maintain recording and continuity paths, and introduce IP communications without an uncontrolled cutover.
02
Exposed SIP boundaries
Carrier, inter-site or remote-tower SIP connections require protocol-aware control, normalization and topology protection.
03
Continuity requirements
Maintenance, migration or network failure cannot be allowed to remove every voice path at once.
04
Recording and audit paths
Existing monitoring and recording workflows must be mapped and validated as signaling and media paths change.
Customer impact: without a controlled interworking layer, an ATC modernization project can create fragmented call flows, new SIP exposure, difficult troubleshooting and a high-risk migration event.
How M5 resolves the use case
Separate the migration into three controllable layers.
The M5 approach keeps legacy access, SIP security and modern voice services distinct so each layer can be designed, tested and introduced without changing everything at once.
1. Preserve and translate
Mediatrix gateways connect selected analog, PBX or digital interfaces to SIP while existing operational services remain in place.
- Legacy-to-IP interworking
- Phased endpoint migration
- Interface and call-flow preservation
2. Secure and control
Sentinel SBCs create a policy-controlled SIP boundary between trusted ATC systems and external, remote or shared IP networks.
- SIP normalization and routing policy
- Topology hiding and access control
- TLS/SRTP where supported and approved
3. Validate and scale
The architecture is piloted against call flows, latency, recording, failover and operational procedures before broader rollout.
- Site-by-site implementation
- Redundancy and survivability tests
- Operational acceptance before scale
ATC users & systemsTower, operations, PBX, analog and recording interfaces
→
Mediatrix gatewayLegacy access and protocol interworking
→
Sentinel SBCSecure SIP edge, policy and routing control
→
Modern ATC voice coreOn-premise, virtual, hybrid or distributed services
Use-case scenarios
Match the architecture to the customer’s operational scenario.
Each scenario starts with a different constraint, but the same principle applies: preserve what must remain, control the SIP boundary and validate the new path before scale.
Civil control tower modernization
ProblemLegacy tower voice and airport systems must coexist with new SIP infrastructure.
M5 approachGateway interworking plus SBC-controlled carrier or IP connectivity.
ObjectiveModernize signaling and routing while preserving operational voice paths.
Military airfield interworking
ProblemMultiple trusted and external voice domains require controlled interconnection.
M5 approachSegmented SIP boundaries, policy control and selected legacy gateway support.
ObjectiveReduce voice-edge exposure and improve migration flexibility.
Remote or distributed tower
ProblemVoice paths cross shared or long-distance IP networks between sites.
M5 approachSBC-controlled inter-site SIP, local gateway options and survivability planning.
ObjectiveImprove control over distributed voice paths and site-level continuity.
Airport operations center
ProblemTower, ground, facilities, emergency and airline voice systems are fragmented.
M5 approachCentralized SIP policy with gateway interworking for retained legacy systems.
ObjectiveCreate a more manageable communications fabric across stakeholders.
Recording-path modernization
ProblemRecording and monitoring depend on existing signaling or media paths.
M5 approachMap recorder-adjacent interfaces and controlled media paths during design.
ObjectivePreserve required recording workflows as the voice core changes.
Phased legacy-to-IP migration
ProblemA single cutover would create unacceptable operational and troubleshooting risk.
M5 approachIntroduce gateways and SBCs by site, service or interface group.
ObjectiveMove to IP voice through controlled, reversible migration stages.
Technical design considerations
Validate the complete operational path—not only the SIP connection.
The final architecture depends on customer requirements, applicable authority standards, system interfaces and approved operational procedures.
SIP security and network boundaries
Define trusted and untrusted domains, allowed peers, routing policies, normalization rules, topology hiding and encryption support. Generic firewalls alone do not provide the same SIP-aware control as an SBC.
Latency, jitter and quality of service
Build an end-to-end latency budget, validate WAN and LAN behavior, apply appropriate QoS and test voice quality under normal and degraded conditions.
Redundancy and survivability
Evaluate redundant SBCs, gateways, links, power, carriers and local survivability. Failover must be tested against actual call flows and operating procedures.
Recording and monitoring integration
Document current recording paths, signaling dependencies and media capture requirements before changing the voice architecture.
Legacy interface mapping
Inventory analog, PBX, digital, SIP and recorder-adjacent interfaces so each dependency has an explicit migration or coexistence plan.
Operations and lifecycle management
Include firmware governance, configuration backup, monitoring, logs, change control, support ownership and recovery procedures in the design.
Migration roadmap
Move from assessment to operational acceptance in controlled stages.
1
Assess
Inventory users, systems, sites, interfaces, carriers, recording and continuity requirements.
2
Map
Define gateway roles, SBC boundaries, routing, security, QoS and failover assumptions.
3
Pilot
Introduce the architecture on a limited path, service or site before broader deployment.
4
Validate
Test call flows, latency, recording, interoperability, security, recovery and operational procedures.
5
Scale
Expand by site or service with documented change control and rollback procedures.
Important: This page describes a conceptual communications-infrastructure use case. Any ATC deployment must be engineered, tested and approved under the applicable aviation, defense, safety, cybersecurity, recording and authority requirements. M5 components do not, by themselves, constitute a complete certified ATC system.
Expected architecture outcomes
What a successful use-case implementation is designed to achieve.
Outcomes depend on the final engineering design, validation results and operating environment.
Operational continuityCritical voice paths remain available through a phased modernization program.
Controlled SIP exposureSIP peers, routes and policies are managed at a defined voice boundary.
Reduced migration riskLegacy and modern systems coexist while each stage is tested and accepted.
Clearer operationsRouting, configuration, monitoring and support responsibilities are easier to document.
ATC voice FAQ
Questions engineering and procurement teams commonly ask.
Can VoIP be used for air traffic control voice?
VoIP may be used when the complete solution is engineered and approved for the required performance, safety, security, recording, redundancy and operational conditions.
Why use an SBC in an ATC voice architecture?
An SBC provides SIP-aware policy, routing, normalization, topology hiding and controlled interconnection between voice domains.
Can legacy ATC systems remain during migration?
Selected analog, PBX and digital interfaces may coexist through Mediatrix gateways while the target SIP/IP environment is introduced in stages.
How are recording systems handled?
Recording dependencies should be inventoried and validated as part of the architecture. The correct integration method depends on the current recorder and media-path requirements.
Does M5 provide a complete certified ATC system?
M5 provides communications-infrastructure components such as SBCs and gateways. The complete ATC solution, certification and operational approval depend on the system integrator, customer environment and applicable authorities.
What is the first step?
Begin with an engineering assessment covering current systems, call flows, interfaces, recording, latency, redundancy, SIP exposure and migration priorities.
ATC architecture review
Map the safest path from the current voice environment to secure IP communications.
Provide a high-level description of the existing environment. M5 can help identify the gateway, SBC, interoperability and migration questions that should be resolved before detailed design.
- Current voice systems and interfaces
- SIP exposure and network boundaries
- Recording and monitoring dependencies
- Site redundancy and survivability
- Phased legacy-to-IP migration priorities