When staff report one-way audio after a router change, start with the network changes, not a phone-system reset. A replacement firewall can preserve call setup while sending voice packets to the wrong address. It can also block one direction or move return traffic onto another connection.
This guide focuses on failures that begin immediately after a router replacement, firewall migration, or related VPN change. The goal is to compare intended behavior with packet evidence, then correct one specific difference. Avoid broad port openings or several simultaneous fixes.
Record the Router Change and the Missing Audio Direction
Write down exactly who cannot hear whom. If the outside caller cannot hear the employee, trace voice traffic leaving the employee’s phone. However, remember that the phone system may relay that traffic through a separate connection.
A PBX, or private branch exchange, manages business calls. Establish whether yours sits onsite, in a hosted environment, or across a VPN. Record the following before changing anything:
- Old and new public addresses, internal subnets, and default gateways.
- Changes to address translation, firewall rules, and SIP inspection.
- Internet failover settings and VPN route changes.
- One affected extension, call direction, and exact test time.
- Whether internal calls, external calls, and transferred calls behave differently.
Export the current configuration and preserve the previous backup. Confirm an approved recovery path before touching the device carrying your remote support session. Use a noncritical test extension where possible.
Separate SIP Call Setup From RTP Voice Traffic
SIP, the Session Initiation Protocol, handles call setup and control. RTP, the Real-time Transport Protocol, carries voice media in many business phone systems. Successful ringing and answering do not prove that voice packets can travel both ways.
SIP messages often carry SDP, the Session Description Protocol. SDP describes media addresses, ports, and supported audio formats. For ordinary audio streams, inspect the connection address in c= and the port in m=audio. Check media-level connection fields too, because they can override a session-level address.
The IETF RTP specification explains the media transport protocol. It does not define a universal firewall port range.
Draw the expected route: phone → PBX → provider, or phone → provider if media bypasses the PBX. Treat each media connection separately. For silence unrelated to a recent change, see the broader connected-call media path guide.
Check RTP Address Translation After the Router Change
Network address translation, or NAT, maps internal addresses and ports to external ones. After a router change, the PBX may still advertise the former public address. A new upstream modem can also introduce a second NAT layer.
Compare three pieces of evidence for the same call:
- The media destination advertised through SDP.
- Source and destination addresses visible at the PBX.
- Translated addresses and ports visible outside the firewall.
An unreachable private address in provider-facing SDP deserves investigation. Private addresses can be correct for calls across a routed VPN, however. Judge the address against the actual peer’s reachability.
For one-way audio after a router change, verify the PBX’s external media address and local-network definitions against the new layout. These settings influence when the PBX advertises internal or external addresses. In FreePBX, use supported administration controls rather than editing generated files.
Some systems learn media destinations from received packets. Confirm that behavior from configuration and captures; do not assume every provider supports the same NAT workaround.
Test SIP ALG Behavior With a Controlled Comparison
A SIP application layer gateway, or SIP ALG, inspects SIP and may rewrite addresses or create temporary firewall openings. A replacement router may enable this feature by default, even if the previous device did not.
Compare the same SIP message on both sides of the router. Unexpected changes to SDP addresses or media ports can identify interference. A SIP ALG cannot normally inspect encrypted SIP unless the device terminates that encryption.
If evidence points to the helper, schedule a controlled test with it disabled. First confirm whether existing rules rely on its temporary openings. Then place a fresh call and compare the captures. Preserve the original setting and a rollback plan.
Existing sessions or NAT mappings can outlast a configuration change. Follow the platform’s documented process for affected sessions; avoid clearing every firewall state during business hours. Disabling SIP ALG is a testable remedy, not a universal first step.
Match Firewall Rules to the Actual Media Port Ranges
Opening the SIP signaling port does not open the voice path. RTP commonly uses UDP, a transport protocol without a connection handshake. Stateful firewalls still track UDP flows and apply timeout rules.
Read the configured media range on the PBX. Compare it with the replacement firewall’s rules and any destination NAT entries. Check the provider’s current media-network requirements through its approved documentation or support channel.
- Confirm the internal destination address after any subnet changes.
- Check protocol, interface, rule order, and source restrictions.
- Distinguish the PBX’s local ports from the provider’s remote ports.
- Look for narrower ranges copied from an outdated configuration.
- Check separate control traffic if the deployment uses it.
A single successful call does not validate the entire configured range. Later calls may select different ports.
Do not place the PBX in an unrestricted exposed-host configuration. Prefer rules limited to verified sources and required destinations. For Asterisk-specific behavior, consult the official Asterisk documentation for the installed configuration.
Trace Asymmetric Routing and VPN Changes
Asymmetric routing means outbound and return packets follow different network paths. A new dual-internet policy can send RTP through one firewall while replies reach another. The receiving firewall may lack the matching state or translation entry.
Check the PBX’s default gateway, firewall policy routes, and provider-specific routes. Verify which public address each media flow actually uses. A successful ping does not prove that RTP follows the same policy.
VPN changes require similar checks. A full-tunnel policy may move external media into the VPN. A split-tunnel policy may leave some destinations outside it. Inspect routes for both signaling and media networks, since providers can use different addresses for each.
Also compare tunnel subnet permissions, overlapping private networks, and NAT exemptions. A migrated rule can translate traffic that previously crossed the tunnel unchanged.
Use the stateful return-traffic checklist when replies reach the wrong interface or fail state checks. Fix the path rather than opening unrelated ports.
Use Paired Packet Captures to Locate the Break
Capture one short, authorized test call at the PBX and the firewall’s inside and outside interfaces. Synchronize clocks first. Record the SIP Call-ID, a call identifier, alongside the test time and audio direction.
Limit capture scope and duration. SIP can expose phone numbers and account details; unencrypted RTP can contain recoverable conversations. Store captures securely and share them only through approved channels.
Follow the missing direction across each checkpoint:
- Nothing leaves the phone: investigate the endpoint or its negotiated destination.
- Traffic reaches the PBX but never leaves: inspect the PBX’s separate outbound media connection.
- Packets reach the inside interface only: check routing, filtering, and NAT decisions.
- Replies arrive outside but not inside: inspect destination translation and state matching.
- Packets reach the phone despite silence: inspect format negotiation, encryption, and endpoint audio handling.
Trace sequence numbers and timing within each RTP connection. A PBX may generate a separate stream, so identifiers need not match across it. Hardware offloading can hide traffic from some captures; confirm capture visibility before concluding that packets disappeared.
Validate the Repair and Preserve the Evidence
Change one confirmed mismatch, then repeat the same test. Compare the new addresses, ports, and packet directions with the failed capture. For one-way audio after a router change, hearing both parties once is only the first validation step.
Test inbound and outbound calls, several calls in sequence, hold and resume, transfers, and an approved longer call. Include VPN phones and each internet path that normally carries calls. Avoid uncoordinated emergency-number testing.
Document the root cause, exact setting changed, test results, and rollback location. Remove temporary diagnostic rules and stop packet collection. Retain only the evidence your organization needs under its data-handling policy.
Professional remote assistance may help when captures span several devices or routing changes threaten support access. Tech Rescue Ops LLC can provide remote VoIP and PBX support to compare media paths and plan a controlled correction.