Fixing One-Way Audio in SIP–WebRTC Calls (Fast Guide)

One-way audio is the most common (and most frustrating) issue when you connect browsers to a SIP PBX. The call rings, you answer, and only one party can hear the other. The good news: it’s almost always solvable with a methodical checklist that targets signalling, NAT traversal, and media paths.

This guide explains the root causes and gives you a fast, repeatable sequence to fix one-way audio in SIP–WebRTC setups — whether you’re using Asterisk/FreePBX, FusionPBX, or a custom SIP stack — plus where a WebRTC–SIP proxy like Siperb helps you sidestep entire classes of failure.

---

What “one-way audio” really means

In SIP–WebRTC scenarios, the signalling (SIP over WSS) can succeed while the media (SRTP/RTP) fails to flow in one direction. Typical culprits are:

• Incorrect or unroutable SDP candidates (wrong IPs/ports in offers/answers).
• NAT traversal gaps (missing/blocked STUN/TURN or ICE failures).
• Firewalls/ALGs rewriting or blocking RTP/DTLS.
• Codec or SRTP profile mismatches.
• PBX “direct media” or re-INVITEs exposing private endpoints.

If signalling is fine but audio is missing one way, look at ICE, SDP, and RTP paths first.

---

A 10-minute triage sequence

Follow this quick order. Each step removes a common failure mode.

1. Confirm browser capture + device
   • In the browser, verify the mic is active and levels are moving.
   • Use your app’s “test call” or a simple loopback.
   • MDN’s overview is useful for sanity-checking WebRTC basics: MDN WebRTC API.
2. Force a clean ICE restart
   • Re-place the call or trigger an ICE restart to refresh candidates.
   • Ensure your app presents at least one public STUN server; see guidance on ICE servers at webrtc.org.
3. Temporarily disable ‘direct media’ at the PBX
   • On Asterisk/FreePBX, disable direct media (a.k.a. direct RTP) so media stays anchored at the PBX or proxy instead of endpoint-to-endpoint.
   • This prevents private addresses from leaking into SDP.
4. Lock codecs to a safe baseline for WebRTC
   • Prefer Opus for audio. Remove exotic codecs for the test.
   • Confirm SRTP is required on the WebRTC leg and supported on the PBX leg.
5. Open the firewall for SRTP/DTLS
   • Allow the PBX/proxy’s UDP RTP range (both directions) and ensure DTLS handshake packets aren’t dropped.
   • Turn off any SIP ALG on edge routers; these often break WebRTC media.
6. Add or enforce a TURN relay for tough NATs
   • If one side sits behind symmetric NAT/CGNAT, TURN is non-negotiable.
   • Configure credentials and confirm the TURN host is reachable from both parties.
7. Re-test and capture diagnostics
   • In the browser, export getStats(); on the PBX, grab SIP/SDP traces.
   • Check for ICE state (= “connected”), valid selected candidates, SRTP packet counts increasing both ways.

---

Why ICE/STUN/TURN dictate success

WebRTC gathers multiple candidate paths (ICE): host (private), reflexive (public via STUN), and relayed (via TURN). One-way audio often appears when:

• The selected pair is asymmetric (one side can reach, the other cannot).
• A firewall blocks return SRTP flow.
• The PBX advertises private IPs in SDP, and the browser can’t route to them.

Providing reliable ICE servers and a reachable TURN dramatically reduces one-way scenarios, especially for remote agents and mobile users. See the official ICE server primer at webrtc.org.

---

PBX-side pitfalls (Asterisk/FreePBX examples)

You don’t need to rebuild your dialplan — just avoid the classics:

• Direct media = off while testing
  Keeps RTP anchored to a routable, known host.
• Externaddr / localnet set correctly
  Make sure Asterisk knows its public IP and local subnets, so it writes the right addresses into SDP.
• SRTP/DTLS profiles aligned
  Browser → SRTP mandatory; PBX leg → must support SRTP or you’ll need a proxy that can transcode/bridge.
• RTP port range open
  Match the PBX’s configured RTP port range on the firewall, both directions.
• SIP re-INVITE caution
  Avoid mid-call re-INVITEs that switch media paths unless you’re certain both legs can route directly.

For more Asterisk-specific background, see the Asterisk Wiki article on one-way audio: Asterisk: One Way Audio.

---

App-side checks (browser/WebRTC)

• Stats tell the truth
  Look for iceConnectionState: connected, rising outbound-rtp and inbound-rtp packets.
• SDP candidates
  Ensure the chosen pair includes at least one public or TURN-relayed address that both sides can reach.
• Bandwidth and priority
  If media stalls but doesn’t fail, consider temporary bitrate caps while debugging (e.g., 24–32 kbps Opus) to rule out congestion.

---

Where a WebRTC–SIP proxy helps (and saves hours)

If your PBX wasn’t designed for browsers, a dedicated bridge layer removes most of the NAT and encryption burden:

• Anchored media: Keeps RTP on a public, stable address; no private IPs leak into SDP.
• TURN fallback built-in: Ensures relays exist for hard NAT cases.
• Certificate + DTLS sanity: Handles SRTP handshakes and cipher alignment without PBX surgery.
• Codec mediation: Locks in Opus on the browser side, negotiates what your SIP trunk expects on the other.

Platforms like Siperb act as this WebRTC–SIP proxy, registering browsers as PBX extensions and bridging SRTP safely. For teams rolling out remote agents or CRM-embedded softphones, it’s the fastest route to eliminating one-way audio at scale.

---

A practical, repeatable checklist

Use this list each time the issue pops up:

1. Browser works locally? Mic levels + loopback ok.
2. ICE restart + STUN ok? Fresh candidates appear.
3. TURN available? Especially for symmetric NAT/CGNAT users.
4. PBX not exposing private IPs? Disable direct media; set externaddr/localnet.
5. SRTP/DTLS aligned? No mismatched profiles.
6. Firewalls open? RTP/DTLS bidirectional; SIP ALG off.
7. Stats prove both directions? Inbound and outbound SRTP increasing.

If you can tick these off and still have one-way audio, anchor the call through a WebRTC–SIP proxy (e.g., Siperb) and retest; if it clears, you’ve confirmed a NAT/routing issue that the proxy neutralises.

---

Further reading (authority links)

• WebRTC fundamentals and APIs (browser side): MDN WebRTC API
• ICE/STUN/TURN server guidance and examples: WebRTC.org — ICE servers
• PBX specifics and classic pitfalls: Asterisk Wiki — One Way Audio

---

For more articles like this, visit SoftpageCMS.