WebRTC One-Way Audio: A Field Guide for PBX Admins

One-way audio is the most annoying VoIP failure mode because it looks like success: calls connect, SIP signalling is clean, and users assume the “voice platform” is broken. In WebRTC-to-SIP environments, it’s usually not signalling at all — it’s media (RTP/SRTP) failing to reach one side due to NAT behaviour, firewall rules, candidate selection, or inconsistent media anchoring.

This guide is written for PBX admins who want a repeatable process that works across Asterisk/FreePBX, SBCs, SIP trunks and browser softphones.

1) Start with the direction (it tells you where the break is)

Before you change anything, identify which stream is missing. Wireshark can help you prove it quickly using its built-in telephony tools such as RTP Player (Playing VoIP Calls).

• Browser hears the SIP endpoint, but endpoint cannot hear browser: the WebRTC → PBX leg is failing (often NAT traversal or blocked UDP).
• Endpoint hears browser, but browser cannot hear endpoint: the PBX/SBC → WebRTC leg is failing (often wrong advertised address/port, or blocked inbound RTP).
• Works on home Wi-Fi but fails on corporate Wi-Fi/LTE: you likely lack a reliable relay path (TURN), or you’re not allowing the right transport fallback.

2) Remember what WebRTC changes: ICE decides the media path

Classic SIP endpoints are mostly “SDP-directed”: they send media to the IP/port they see in SDP. Browsers are “ICE-directed”: they gather candidates, test connectivity, and choose a working pair using STUN/TURN as needed. The WebRTC project’s own peer-connection guide is a solid refresher on candidates and ICE flow: Getting started with peer connections (ICE candidates, STUN, TURN).

If your bridge (PBX/SBC/proxy/B2BUA) doesn’t translate between these models cleanly, you get the classic symptom: calls connect, one side is silent.

3) Prove whether TURN is required (don’t guess)

In the real world, TURN is not “optional polish” — it’s what makes WebRTC reliable on restrictive networks. The WebRTC project’s own deployment note is blunt about this: TURN server (webrtc.org).

A quick operational method:

• Place a test call from a known hostile network (corporate Wi-Fi / hotel / LTE).
• Force relay candidates (TURN) for the test user if your client supports it.
• If one-way audio disappears, you have proven a NAT/firewall traversal problem — not codecs, not dialplan.

If you use a managed traversal service, Twilio documents how STUN/TURN improves connection success through NAT and firewalls: Twilio Network Traversal Service (STUN/TURN).

4) RTP port ranges: the most common “it connects but no audio” cause

Most one-way audio incidents still boil down to boring firewall reality: SIP signalling is allowed, but RTP isn’t. On FreePBX/Asterisk deployments, Sangoma explicitly flags NAT/firewall as the primary driver of one-way audio and provides a checklist: PBX GUI – SIP Audio Issues (FreePBX). :contentReference[oaicite:3]{index=3}

Also worth keeping bookmarked is Sangoma’s specific article on “no audio” scenarios, which often traces back to RTP port configuration and firewall state: Why do SIP extensions in FreePBX have no audio?.

What you are validating:

• Your PBX/SBC RTP range is known and consistent.
• UDP inbound/outbound for that range is allowed to the correct interface.
• No SIP ALG / “voice helpers” are rewriting ports unexpectedly.

5) PBX NAT settings must match reality (especially when endpoints roam)

If your PBX advertises a private address in SDP, the far end will send media into a black hole. This is why NAT configuration is not a nice-to-have. Sangoma’s NAT configuration guide is explicit that misconfigured NAT drives “one way audio” and related issues: NAT Configuration (FreePBX). :contentReference[oaicite:5]{index=5}

If you’re troubleshooting deeper PJSIP behaviour, use the official Asterisk troubleshooting workflow (logger/debug guidance, what to capture) rather than stabbing at random settings: Asterisk PJSIP Troubleshooting Guide. :contentReference[oaicite:6]{index=6}

6) When you need a media anchor (RTP proxying) to stop asymmetry

Some environments simply won’t behave predictably unless media is anchored/relayed through a known point (SBC, RTP engine, proxy, etc.). If you’re operating in that world, it helps to understand what “media proxying” actually entails. Kamailio’s documentation for its RTP engine integration explains the concept of proxying media streams via an RTP proxy: Kamailio rtpengine module (media proxying).

This matters because “half-bypass” designs are a common one-way-audio generator: signalling transits the proxy, but one leg’s media bypasses it and hits NAT/firewall reality directly.

7) TURN setup references that are genuinely practical

If you run your own conferencing/RTC stack, Jitsi’s handbook includes a current, ops-focused guide to enabling TURN support (useful even if you’re not a Jitsi shop, because it shows the moving parts clearly): Setting up TURN (Jitsi handbook).

For a concise but detailed explanation of STUN vs TURN mechanics, Stream’s WebRTC resource centre is also a strong reference: STUN vs TURN Servers (GetStream).

8) A modern, readable reference for NAT behaviour in WebRTC

If you want a well-written technical reference that explains NAT mapping types and why traversal fails in practice (in plain English, but with real engineering detail), “WebRTC for the Curious” is excellent: WebRTC for the Curious (PDF).

This is useful when you need to justify to a stakeholder why “it works on my Wi-Fi” proves nothing about corporate networks.

9) Where Siperb fits (without turning the article into an ad)

If you’re repeatedly dealing with users on hostile networks (or a mixed estate of PBX + SIP trunks + browser clients), the operational win is consistency: predictable ICE behaviour, correct anchoring, and reliable relay when required. That’s the gap a WebRTC-to-SIP proxy is designed to close. For an overview of that role, see Siperb’s WebRTC-to-SIP proxy explainer.

If you’re evaluating browser calling more broadly (client + proxy deployment model), start here: Siperb.

10) The “fix order” that resolves most incidents fastest

1. Prove direction with capture/telephony tools (don’t argue based on symptoms).
2. Validate ICE candidate behaviour and test whether TURN eliminates the failure.
3. Open and verify RTP ranges end-to-end (including return traffic and correct interface mapping).
4. Correct PBX NAT/external addressing so SDP never advertises unreachable addresses.
5. Anchor media consistently when the environment demands it (avoid half-bypass).

Once you run that sequence a few times, one-way audio stops being a mysterious “VoIP curse” and becomes a routine, evidence-driven diagnosis.

For more articles like this, visit SoftpageCMS.