Resolving One-Way Audio ICE Candidate Failures in WebRTC

How-To-Articles
1

Resolving One-Way Audio ICE Candidate Failures in WebRTC

Executive Summary & Architectural Context

The most frustrating, insidious issue in a cloud contact center is “One-Way Audio.” The agent answers the call, they can hear the customer perfectly, but the customer hears nothing (or vice versa). Because it is intermittent, IT teams often blame the agent’s home Wi-Fi or restart the browser, which temporarily masks the architectural failure.

In Genesys Cloud, browser-based softphones use WebRTC. WebRTC does not stream audio through a standard HTTP proxy. It uses a complex peer-to-peer negotiation protocol called ICE (Interactive Connectivity Establishment) to find the shortest UDP path between the agent’s browser and the Genesys Cloud media edge.

If a corporate firewall, VPN tunnel, or local NAT router blocks the UDP ports required for the ICE candidates to connect, the audio stream breaks. This masterclass details how to trace ICE candidate negotiation, identify asymmetric RTP flows, and configure firewalls to guarantee bidirectional WebRTC audio.

Prerequisites, Roles & Licensing

  • Licensing: Available on all Genesys Cloud CX tiers.
  • Roles & Permissions: None required in Genesys Cloud, but requires deep access to corporate Firewalls/VPNs.
  • Platform Dependencies:
    • Google Chrome WebRTC Internals (chrome://webrtc-internals).

The Implementation Deep-Dive

1. Understanding the ICE Negotiation Flow

When a call connects, the agent’s browser and the Genesys Cloud Edge exchange an SDP (Session Description Protocol) payload. This SDP contains a list of IP addresses and ports where they are willing to receive audio (these are the ICE Candidates).

  1. Host Candidate: The browser’s local private IP (e.g., 192.168.1.50).
  2. Server Reflexive Candidate (STUN): The browser’s public IP as seen by the internet (e.g., 203.0.113.10).
  3. Relay Candidate (TURN): A fallback server on port 443 TCP if UDP is totally blocked.

The browser and the Edge test these candidates against each other. The moment one pair successfully connects, bidirectional audio begins.

2. Diagnosing the Failure (Chrome Internals)

If an agent reports one-way audio, you must capture the ICE state during an active test call.

  1. Ask the agent to open a new tab and navigate to chrome://webrtc-internals.
  2. Place a test call to the agent.
  3. In the WebRTC Internals tab, look for the active RTCPeerConnection.
  4. Expand the Stats graphs. Look for two specific graphs: bytesSent and bytesReceived on the RTCOutboundRtpVideoStream / AudioStream.
    • Diagnosis: If bytesReceived is climbing, but bytesSent is flatlined at 0, the browser is receiving the customer’s audio, but the firewall is blocking the agent’s microphone UDP packets from leaving the network.

3. The Root Cause: Asymmetric UDP Blocking

Standard stateful firewalls allow outbound traffic and permit the return traffic automatically. However, WebRTC RTP streams are often asymmetric.

  • The Genesys Cloud Edge might send audio to the agent’s Public IP on port 16384.
  • The agent’s browser might try to send audio back to the Genesys Cloud Edge on port 16385.
  • The Failure: If the corporate firewall has a strict rule saying “Only allow outbound UDP on port 5060,” the browser’s attempt to send audio out on port 16385 is silently dropped by the firewall. The customer hears dead air.

4. The Architectural Fix (Firewall Whitelisting)

To guarantee WebRTC functionality, you must configure the corporate firewall or VPN tunnel (e.g., Cisco AnyConnect, Palo Alto GlobalProtect) to explicitly whitelist the Genesys Cloud media ranges.

  1. Protocols: UDP is mandatory. TCP is only for TURN fallback (which causes severe latency).
  2. Destination Ports: Allow outbound UDP on ports 16384 - 32768.
  3. Destination IPs: You must whitelist the entire AWS IP subnet for your specific Genesys Cloud region. (e.g., for us-east-1, you must whitelist the published AWS CIDR blocks used by Genesys Cloud Media Services).
  4. VPN Split Tunneling: Critical Best Practice. If agents are working from home on a corporate VPN, route all Genesys Cloud WebRTC UDP traffic outside the VPN tunnel directly to the local ISP. Forcing real-time audio through a VPN concentrator adds massive jitter and frequently causes one-way audio due to MTU (Maximum Transmission Unit) fragmentation.

Validation, Edge Cases & Troubleshooting

Edge Case 1: SIP ALG (Application Layer Gateway)

Many consumer home routers (Netgear, Linksys) and some enterprise firewalls have a feature called SIP ALG enabled by default. SIP ALG attempts to “help” by rewriting IP addresses inside SIP packets.

  • The Trap: WebRTC uses WebSockets (WSS), not raw SIP, but some aggressive ALGs will still attempt to rewrite the SDP payloads, corrupting the ICE candidates.
  • Solution: If an agent working from home consistently experiences one-way audio while agents in the office do not, the agent must log into their home router and explicitly disable SIP ALG.

Edge Case 2: Endpoint Antivirus and Microphone Permissions

If the firewall is completely open, but bytesSent is still 0, the issue is local hardware access.

  • Troubleshooting: Check the Windows/macOS privacy settings. The OS might be blocking Chrome from accessing the microphone. Furthermore, strict endpoint security agents (like CrowdStrike or SentinelOne) might be injecting code into Chrome that blocks WebRTC memory allocation. Add mypurecloud.com to the endpoint security exclusions.

Official References