WebRTC Guide

WebRTC to SIP Gateway Issues

9 min read  ·  Updated April 2026

Bridging WebRTC to SIP is complex — the two protocols use different security models, NAT traversal methods, and codec sets. When a WebRTC-to-SIP gateway fails, the errors are cryptic. Here's a systematic guide to diagnosing and fixing every failure mode.

In this guide

1. WebRTC vs SIP — key differences that cause gateway failures

WebRTC and SIP were designed independently. Bridging them requires converting between several incompatible approaches:

FeatureWebRTCSIP
NAT traversalICE (STUN/TURN)NAT=yes, STUN, SBC
EncryptionDTLS-SRTP (mandatory)SDES-SRTP or plain RTP
MultiplexingBUNDLE (single port)Separate audio/video ports
CodecsOpus, VP8/VP9, H.264G.711, G.729, G.722
SDP formatComplex (ICE candidates, DTLS fingerprint)Simple (c= line, m= line)

The gateway must convert between all of these. Failures occur when the conversion is incomplete or misconfigured.

2. ICE negotiation failures

ICE (Interactive Connectivity Establishment) is how WebRTC discovers the best network path. When ICE fails, no media flows.

Failure 01
ICE candidates not being gathered
The WebRTC client can't reach the STUN server to discover its server-reflexive (public) address. Without server-reflexive candidates, ICE may fail when the client is behind NAT. Ensure your STUN server is reachable (stun.l.google.com:19302 for testing). Check for firewall rules blocking UDP to the STUN server.
Failure 02
No TURN relay — symmetric NAT
When both endpoints are behind symmetric NAT, STUN-derived candidates won't work. A TURN server is required as a relay. Symmetric NAT is common in enterprise environments. Configure a TURN server and ensure WebRTC clients use it as a fallback.
Failure 03
Gateway stripping ICE from SIP leg
The gateway must strip ICE candidates from the SDP before sending to the SIP leg — SIP endpoints don't understand ICE. If ICE candidates appear in the SDP going to the SIP side, the SIP endpoint may reject with 488 or ignore the SDP and use the c= line address (which may be the gateway's internal IP).

3. DTLS-SRTP to SRTP/RTP conversion

WebRTC requires DTLS-SRTP. SIP endpoints typically use SDES-SRTP or plain RTP. The gateway must convert between these.

Issue 01
Gateway not performing DTLS handshake
The gateway must complete the DTLS handshake with the WebRTC client before media can flow. If the gateway is configured as a plain SRTP (SDES) proxy and doesn't support DTLS, the WebRTC client will never get media. Check that your gateway has DTLS-SRTP support enabled.
Issue 02
a=setup direction mismatch
DTLS requires one side to be actpass and the other active or passive. If the gateway and WebRTC client both offer actpass and neither switches to active, the DTLS handshake never starts. The gateway should offer actpass to the WebRTC client and use active toward the SIP leg.
; Correct WebRTC side SDP (DTLS) a=fingerprint:sha-256 AA:BB:CC:... a=setup:actpass ; Correct SIP side SDP (SDES-SRTP) a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:key ; Or plain RTP for internal SIP m=audio 10000 RTP/AVP 0

4. Codec mismatches at the WebRTC/SIP boundary

WebRTC clients default to Opus for audio. Most SIP endpoints use G.711 or G.729. The gateway must transcode between them. For codec characteristics and quality trade-offs see VoIP codec comparison; for the cost of doing the conversion see transcoding in VoIP.

Common mismatch pattern: WebRTC offers only Opus. SIP PBX only accepts G.711. Gateway doesn't transcode. Call connects with no audio.

Configure your gateway to always offer G.711 (PCMU payload 0) on the SIP leg regardless of what the WebRTC side negotiated. The gateway transcodes Opus↔G.711 transparently.

; Kamailio + RTPEngine: force codec on SIP leg rtpengine_manage("transcode-PCMU transcode-PCMA ICE=remove DTLS=off SDES-off");

5. SDP interoperability issues

WebRTC SDPs are much more complex than traditional SIP SDPs. Common interoperability problems:

BUNDLE not supported by SIP: WebRTC uses a=BUNDLE to multiplex audio and video on a single port. SIP endpoints use separate ports. The gateway must un-bundle and present separate m= sections with individual ports to the SIP side.

rtcp-mux: WebRTC multiplexes RTP and RTCP on the same port (a=rtcp-mux). SIP traditionally uses separate ports (RTP port N, RTCP port N+1). The gateway must handle this translation.

Extmap headers: WebRTC SDPs include RTP header extension mappings (a=extmap:) that SIP endpoints don't understand. Strip these before forwarding to SIP.

6. Diagnosing WebRTC to SIP gateway failures

Step 1 — Capture SDP on both legs. Get the full SDP offer and answer on both the WebRTC side and the SIP side. Look for missing ICE removal, DTLS vs SDES mismatch, codec presence/absence, and BUNDLE handling.

Step 2 — Check ICE gathering in browser. Open Chrome DevTools → Application → WebRTC internals. Look at the ICE gathering state and candidate types. If only host candidates are gathered (no srflx or relay), STUN/TURN is failing.

Step 3 — Check for DTLS handshake. In a PCAP on the gateway, look for DTLS Client Hello / Server Hello after the SDP exchange. If no DTLS packets appear, the DTLS negotiation isn't starting — check a=setup direction.

Step 4 — Check codec transcoding. Verify the gateway is translating Opus to G.711 for the SIP leg. Run RTP debug and check payload type numbers — Opus is typically payload 111, G.711u is payload 0.

Frequently asked questions

Why does WebRTC to SIP have no audio?

No audio in WebRTC to SIP bridging is usually caused by ICE negotiation failure, DTLS-SRTP handshake not completing, or codec mismatch. Check that the gateway strips ICE candidates from the SIP-side SDP, performs the DTLS handshake with the WebRTC client, and transcodes Opus to G.711 for the SIP leg.

What is the difference between DTLS-SRTP and SDES-SRTP?

DTLS-SRTP exchanges encryption keys via a DTLS handshake on the media channel — used by WebRTC (mandatory). SDES-SRTP exchanges keys inline in the SDP a=crypto lines — used by traditional SIP. A WebRTC-to-SIP gateway must convert between these, completing a DTLS handshake on the WebRTC side and using SDES or plain RTP on the SIP side.

How do I fix ICE failures in WebRTC to SIP?

ICE failures are usually caused by missing STUN/TURN configuration or symmetric NAT. Ensure your WebRTC application has a working STUN server configured. For enterprise environments with symmetric NAT, configure a TURN relay server. On the SIP side, strip all ICE attributes from the SDP — SIP endpoints do not support ICE.

Having WebRTC to SIP gateway failures?

Paste your SIP trace or gateway logs into SIPSymposium. The analyzer identifies ICE stripping issues, DTLS negotiation failures, codec transcoding gaps, and SDP format incompatibilities.

Analyze my trace Create free account
Related guides