Why does it happen in one direction only — and always the same one?

Because the two directions fail independently and the network treats them differently: outbound RTP creates a NAT mapping that inbound replies should reuse; when the SDP advertises a wrong address or port, exactly one direction is sent into a void. The consistency is the clue that it is addressing, not congestion.

It works for the first seconds, then one side goes silent. Same fault?

Related family, different cause: media starts, then a NAT/firewall state entry expires or a re-INVITE changes the media address. Capture across the failure moment and compare the RTP destination before and after; also see the timed-drops guide.

Does rebooting the router fix one-way audio?

Temporarily, sometimes — it clears NAT state and ALG confusion, which is diagnostic information, not a fix. If the fault returns, work the sequence above; reboot-driven 'fixes' always come back during a busier day.

Troubleshooting · Symptoms

One-Way Audio: Causes and Fixes

By the VoIP Cost Guide Editorial Team | Last updated: October 2026

The call connects. You can hear the other party clearly — and they hear silence, or the reverse. One-way audio is the most reported VoIP fault in existence, and also one of the most diagnosable: voice travels as RTP packets in each direction independently, so exactly one direction of one stream is being blocked, misaddressed, or sent somewhere wrong. The call signaling (SIP) worked — that is why the call exists at all — so this is a media-path problem, not a setup problem.

Work it in the order below. In small-business networks the first two causes account for the overwhelming majority of cases.

What the capture shows

Take a packet capture at the phone or the network edge and look at the RTP streams (in Wireshark: Telephony → RTP Streams). One-way audio has a signature you can see:

# RTP streams for one call — note the asymmetry
Src 192.168.1.50:12000 -> Dst 203.0.113.10:31000   packets: 1,842  (flowing)
Src 203.0.113.10:31000 -> Dst 198.51.100.7:12000   packets: 1,790  (wrong destination!)
# The return stream is addressed to the phone's PUBLIC NAT address
# as seen in the SDP c= line — but to the wrong port, or the phone's
# private address appears in SDP and the far end sends into a void.

Causes, most likely first

NAT rewriting gone wrong. The phone puts its private IP address (192.168.x.x) in the SIP SDP body. The far end faithfully sends voice to that unroutable address. Fix at the SBC/provider edge (most hosted providers rewrite this automatically — 'symmetric RTP' / media anchoring) or enable the phone's NAT/STUN settings.
Firewall blocks the return RTP range. SIP (5060/5061) is open so calls set up, but the provider's RTP UDP range (often something like 10000–20000 or 16384–32768 — ask yours) is not permitted inbound, or a stateful rule expires. One direction gets through because it was initiated from inside.
SIP ALG corruption. The router's SIP helper rewrites addresses inconsistently — signaling survives, media addresses get mangled. Disable SIP ALG and retest; see the dedicated guide.
Asymmetric routing / double NAT. Two NAT layers (ISP gateway + your router) or dual-WAN failover sending return traffic out the wrong interface. Common after 'we added a second router' changes.
Codec or ptime mismatch (rarer). Produces garbled or silent audio rather than clean one-way silence; the capture shows RTP flowing both ways. Check the negotiated codec in the SDP answer.

Diagnosis and fix sequence

Confirm the pattern: is it every call, one direction consistently, internal calls too, or only external? Internal-only-working points outside your LAN; both-directions-broken on one phone points at that phone.
Capture at the network edge during a failing call. In the RTP stream list, check whether return packets arrive at your WAN interface at all, and what destination address/port they carry.
If return RTP never reaches the WAN: the problem is upstream addressing (SDP contains a private/wrong address) or provider-side. Compare the SDP c= and m= lines in the INVITE/200 OK with your public IP and the RTP range the provider documents.
If return RTP reaches the WAN but not the phone: your firewall/NAT is dropping or mis-forwarding it. Verify the provider's full RTP range is permitted and that no SIP ALG is enabled on the path.
Fix one variable at a time — disable SIP ALG, or correct the NAT setting — and re-run the same test call and capture to verify both streams flow symmetrically.
Still one-way with a clean local capture? Escalate to the provider with the capture attached: streams arriving at your edge addressed wrong is their SBC configuration to fix.

Frequently asked questions

Why does it happen in one direction only — and always the same one?: Because the two directions fail independently and the network treats them differently: outbound RTP creates a NAT mapping that inbound replies should reuse; when the SDP advertises a wrong address or port, exactly one direction is sent into a void. The consistency is the clue that it is addressing, not congestion.
It works for the first seconds, then one side goes silent. Same fault?: Related family, different cause: media starts, then a NAT/firewall state entry expires or a re-INVITE changes the media address. Capture across the failure moment and compare the RTP destination before and after; also see the timed-drops guide.
Does rebooting the router fix one-way audio?: Temporarily, sometimes — it clears NAT state and ALG confusion, which is diagnostic information, not a fix. If the fault returns, work the sequence above; reboot-driven 'fixes' always come back during a busier day.

Sources and further reading

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.