Causes of One-Way Audio and Video in WebRTC

This article explores the primary technical reasons why users experience isolated one-way audio or video during WebRTC sessions. We will examine how network configurations, firewall restrictions, NAT traversal failures, media negotiation mismatches, and browser permission policies contribute to this common streaming issue, providing clear explanations for each cause.

NAT Traversal and ICE Failures

The most common culprit behind one-way media in WebRTC is a failure in the Interactive Connectivity Establishment (ICE) process, particularly when traversing symmetric NATs (Network Address Translators). WebRTC uses STUN and TURN servers to discover public IP addresses and establish direct peer-to-peer connections.

If one peer is behind a strict symmetric NAT and no TURN (Traversal Using Relays around NAT) server is configured—or if the TURN server is blocked—the connection may only establish partially. In this scenario, one peer can successfully send packets to the other, but the return path is blocked, resulting in unidirectional media flow.

Asymmetric Firewall Policies

Firewalls and security appliances often employ deep packet inspection or strict stateful rules that affect incoming and outgoing UDP traffic differently. A local firewall might allow outgoing UDP traffic on random ports (enabling one peer to send media) but block incoming UDP packets on those same ports. Because WebRTC media streams (RTP/RTCP) travel over dynamic UDP port ranges, any asymmetry in firewall rules will immediately result in one-way audio or video.

SDP Direction Attribute Misconfigurations

During the WebRTC signaling phase, peers exchange Session Description Protocol (SDP) offers and answers to negotiate media capabilities. SDP contains specific direction attributes: * a=sendrecv (send and receive) * a=sendonly (send only) * a=recvonly (receive only) * a=inactive (neither)

If the application logic misconfigures these attributes during the offer/answer exchange, or if there is a parsing error in the signaling state machine, one peer may transition to a state where it only transmits media while the other peer transitions to a state where it only listens.

DTLS-SRTP Handshake Failures

WebRTC encrypts all media streams using Datagram Transport Layer Security (DTLS) and Secure Real-time Transport Protocol (SRTP). After the ICE path is established, the peers must complete a DTLS handshake to exchange encryption keys.

If the DTLS handshake fails in one direction—often due to fragmented packets being dropped by intermediary routers or firewalls—one peer will fail to decrypt the incoming SRTP packets. The receiving peer will discard these packets as unreadable, manifesting to the user as a complete loss of incoming audio or video while their outgoing stream remains functional.

Browser Media Permissions and Hardware State

Sometimes the issue is not network-related but stems from the client device or browser API environment. If a user revokes microphone or camera permissions mid-call, or if the browser’s autoplay restrictions block incoming media, one-way communication occurs. Additionally, if a device’s hardware driver fails to initialize the microphone or camera, the local browser cannot capture input to send, while still being perfectly capable of rendering the incoming stream from the remote peer.