The go-live is done. Testing starts. Within ten minutes the front desk calls — they can hear the other party but the other party can’t hear them. Or the reverse. Either way, it’s the loudest ticket you’ll get all day because front desk and executive assistants make more calls than anyone else in the building and they know immediately when something is wrong.
One-way audio is the most common post-deployment VoIP complaint. It sounds like a complex problem. It almost never is. In the overwhelming majority of cases, the cause is the same: UDP is send-and-forget, and the return path is blocked somewhere.
Finding what’s blocking it is the job.
Why One-Way Audio Is Almost Always an RTP Problem
If you haven’t read SIP Fundamentals for Network Engineers, the short version is this: SIP handles call setup, RTP carries the audio. When a call connects — when both parties can see each other on screen or the call timer is running — SIP did its job. The session is established. What’s broken is the media path.
RTP is UDP. UDP is connectionless and stateless — there’s no handshake, no acknowledgment, no built-in mechanism to verify the return path exists before audio starts flowing. A SIP 200 OK can complete successfully with an SDP that contains an IP address or port the return RTP stream can never reach. The call connects. Audio flows one direction. The other direction is silently dropped somewhere on the path.
This is why one-way audio doesn’t trigger an obvious error. SIP completed normally. From the signaling layer’s perspective, the call is fine. The problem is invisible until someone picks up the phone.
The Return Path Is Blocked — Finding Where
The diagnostic question is simple: is RTP leaving the source correctly, and is RTP arriving at the destination from both directions?
If audio flows one way but not the other, one side’s RTP stream is being blocked before it arrives. The stream is being sent — UDP doesn’t know or care whether anyone receives it — but it’s not getting through.
The most common places the return path breaks, in order of likelihood:
Firewall blocking return UDP. The most common cause by a significant margin. A firewall rule permits outbound UDP on the required port ranges but the return traffic — inbound UDP from the remote endpoint back to the local client — isn’t explicitly permitted or isn’t being tracked as part of a stateful session. UDP is sessionless, so stateful firewalls need to see the outbound packet first to create a state entry for the return. If the outbound packet doesn’t match the right rule, or if the state table entry expires during a long call, the return traffic gets dropped silently.
For Teams, the UDP range is 50000–50059. For Webex, 5004 and 8000–8100. Both directions need to be permitted. Covered in detail in Firewall Rules for Teams and Webex.
NAT translating the wrong address into the SDP. When a SIP endpoint behind NAT sends an INVITE, the SDP body contains the IP address where it wants to receive audio. If the SDP contains the private IP address rather than the public NAT address, the remote end tries to send RTP to an unreachable private address. Audio flows outbound correctly — the sending side knows where to send it. Return audio never arrives — the remote end is sending to a dead address.
In Teams and Webex cloud deployments this is largely handled by the platform’s STUN/TURN infrastructure — the platform negotiates the correct reachable address during setup. Where it shows up is at the edge of the network when local NAT configuration is inconsistent, or in environments with hairpin NAT issues where internal clients trying to reach external addresses through NAT behave unexpectedly.
Asymmetric routing. Outbound RTP leaves on one network path, the response comes back on a different path. A stateful firewall that saw the outbound on WAN1 has no session entry for return traffic arriving on WAN2 and drops it. The call connects because SIP signaling made it through. Audio is one-way because the media return path is hitting a firewall with no matching state entry. Multi-WAN environments with policy-based routing are where this shows up most often.
ACL on a VLAN or routing boundary blocking return UDP. An access control list applied to a VLAN interface or a routing boundary that permits voice traffic outbound but doesn’t have a corresponding permit for return traffic inbound. Common when security hardening is applied to voice VLANs without fully accounting for the bidirectional nature of RTP. The voice VLAN ACL permits traffic from VLAN 20 to external destinations but doesn’t permit return UDP from external sources back to VLAN 20.
QoS policy remarking or dropping. A QoS policy that’s misconfigured drops or re-queues RTP packets on the return path. Less common than firewall issues but worth checking if you’ve ruled out ACLs and firewall rules. If DSCP EF (46) marked packets are being remarked to a lower priority class on the return path and the queue is congested, audio degrades or drops asymmetrically.
The SIP Footnote — Premature Call Drops
One-way audio is an RTP problem. But there’s a related failure mode worth knowing: calls that connect normally and then drop unexpectedly mid-conversation, or calls that don’t hang up cleanly and hold the line open until a timeout.
This is a SIP problem, specifically a BYE problem. When a user hangs up, a SIP BYE message is sent to terminate the session. If that BYE doesn’t reach the other end — or doesn’t get a 200 OK response — the session stays open on one side. The user thinks the call ended. The other side is still waiting. Eventually a SIP session timer fires and the call terminates by timeout, which can be 30 seconds to several minutes depending on configuration.
In Teams and Webex deployments this surfaces as calls that “stick” — the call timer keeps running after the user hangs up, or a phone remains “in call” state when it shouldn’t be. If you’re seeing this, check that TCP 443 is open and stable for SIP signaling — intermittent TCP drops on the signaling path cause BYE messages to get lost. Also check SBC logs if you have one in the environment — the BYE exchange is visible in the SIP trace and the response code tells you where it’s failing.
Diagnosing With Wireshark
Wireshark is the fastest way to confirm whether RTP is flowing in both directions and identify where the break is.
What to capture:
Capture on the interface closest to the voice endpoint — the uplink from the access switch, or directly on the machine running the softphone if it’s accessible. You want to see traffic as it enters and leaves the voice segment.
Filter for RTP:
rtp
Or filter by the specific UDP port range for Teams:
udp.port >= 50000 && udp.port <= 50059
For Webex:
udp.port == 5004 || (udp.port >= 8000 && udp.port <= 8100)
What you’re looking for:
With one-way audio, you should see RTP packets flowing in one direction only. If the local endpoint is sending but not receiving, you’ll see outbound RTP streams with source address matching your endpoint and destination matching the remote — but no corresponding inbound stream from the remote back to your endpoint.
That confirms the return path is blocked. The traffic is leaving correctly. Something between the remote endpoint and your local endpoint is dropping the return UDP.
Narrowing it down:
Move the capture point. Capture at the firewall perimeter — outside the firewall if possible. If inbound RTP is arriving at the firewall but not making it through, the firewall is the block. If inbound RTP isn’t arriving at the firewall at all, the block is upstream — either at the remote end, the carrier, or somewhere in the cloud infrastructure path.
For Teams, the Teams Call Analytics page in the Teams Admin Center shows media path data per call — you can see whether media was relayed through Microsoft’s TURN infrastructure or went peer-to-peer, and whether packet loss was asymmetric. This supplements Wireshark when you need call-level quality data without a packet capture.
For Webex, the Webex Control Hub diagnostics and analytics provide per-call quality metrics including packet loss, jitter, and latency broken out by direction. If packet loss is showing on one direction only, it confirms the return path problem and gives you a starting point before you open Wireshark.
Using the SIP Header Breakdown Tool:
If your Wireshark capture includes the SIP INVITE and 200 OK exchange, the SDP bodies in those messages tell you exactly what IP addresses and ports both sides negotiated for media. Paste the SIP message into the SIP Header Breakdown Tool and check the SDP section — the c= line is the connection address, m=audio is the port. If either address is a private IP that shouldn’t be in the SDP, you’ve found your NAT problem without reading raw headers.
The Fix — Working Backwards From the Block
Once Wireshark confirms the return path is blocked, the fix depends on where the block is:
Firewall: Add an explicit permit for inbound UDP on the Teams or Webex media port ranges from the platform’s IP ranges. Verify stateful inspection is enabled and the state table isn’t exhausting under load. Check that UDP timeout values on the firewall are longer than your longest expected call duration — some firewalls default UDP state timeouts to 30–60 seconds, which drops the state entry mid-call.
ACL on VLAN boundary: Add a return permit to the ACL. If the ACL permits outbound UDP from 10.10.20.0/24 to any destination, add a corresponding permit for inbound UDP from any source to 10.10.20.0/24 on the same port ranges. Or use reflexive ACLs if your platform supports them — they create dynamic return entries automatically based on outbound traffic.
Asymmetric routing: Ensure voice traffic takes a symmetric path through the same firewall on the way in and out. Policy-based routing that sends voice out WAN1 needs to ensure return traffic also enters on WAN1, or the firewall needs to handle asymmetric state. Most enterprise firewalls have an asymmetric routing mode — enable it if symmetric routing isn’t achievable.
NAT SDP mismatch: Verify the SDP in the INVITE contains a routable address. For Teams and Webex cloud deployments, the platform handles this via STUN/TURN — if you’re seeing private addresses in the SDP on a cloud deployment, check that the required STUN/TURN ports are open and the platform can complete ICE negotiation.
What Comes Next
With one-way audio solved, the final article in the Networking pillar is the pre-deployment validation checklist — everything to verify before a single user goes live. Network Readiness Assessment for UCaaS — What to Check Before You Deploy pulls together every topic in this pillar into a systematic go-live checklist.
For the SIP signaling layer that underpins the call setup covered in this article, SIP Fundamentals for Network Engineers covers the full INVITE/200 OK/ACK flow and how to read a SIP trace when calls fail at the signaling layer instead of the media layer.