WebRTC Guide

WebRTC SIP Interoperability

9 min read · Updated April 2026

WebRTC and SIP are both real-time communications protocols but they speak different dialects. Bridging them requires converting between ICE and NAT traversal methods, DTLS-SRTP and SDES-SRTP encryption, and Opus and G.711 codecs. Here is how to do it right.

In this guide

01WebRTC vs SIP — key protocol differences 02Gateway architecture patterns 03Signaling interoperability 04Media plane interoperability 05NAT and ICE handling 06Troubleshooting interoperability issues

1. WebRTC vs SIP — key protocol differences

WebRTC and SIP were developed independently for different environments. Understanding the differences explains why bridging them is non-trivial:

Feature	WebRTC	SIP
Transport signaling	WebSocket (WS/WSS)	UDP, TCP, TLS
NAT traversal	ICE (STUN/TURN) — mandatory	SBC, STUN — optional
Media encryption	DTLS-SRTP — mandatory	SDES-SRTP — optional, plain RTP common
Multiplexing	BUNDLE — single port for all media	Separate ports per stream
Default audio codec	Opus (mandatory in spec)	G.711 (most common)
RTCP	rtcp-mux (same port as RTP)	Separate port (N+1)
SDP complexity	High (ICE candidates, fingerprint, extmap)	Low (c= line, m= line)

A WebRTC-to-SIP gateway must handle all of these differences simultaneously. Missing any one conversion layer causes the call to fail or have no media.

2. Gateway architecture patterns

Pattern A

Media gateway with SIP B2BUA

A dedicated media server (FreeSWITCH, Asterisk, Janus, Mediasoup) acts as a B2BUA. It terminates the WebRTC leg (DTLS-SRTP, ICE, Opus) and originates a new SIP leg (SDES-SRTP or plain RTP, G.711). Transcodes media between Opus and G.711. Most common pattern for production deployments.

Pattern B

SBC with WebRTC support

Modern SBCs (AudioCodes, Ribbon) handle WebRTC-to-SIP bridging natively. They terminate WebRTC, convert DTLS-SRTP to SDES-SRTP, remove ICE candidates from SDP, and transcode Opus to G.711. Commercially supported and production-hardened. Best for enterprise deployments.

Pattern C

SIP over WebSocket (RFC 7118)

The SIP signaling is carried over WebSocket to the browser, but media still uses WebRTC. The SBC terminates the WebSocket SIP and converts to UDP/TCP SIP. Simpler signaling bridging but media bridging still required. Used by some SIP.js and JsSIP deployments.

3. Signaling interoperability

WebRTC browsers typically use SIP over WebSocket (RFC 7118) or a proprietary signaling protocol (like Janus API). The gateway must convert this to standard SIP over UDP/TCP/TLS.

SIP over WebSocket (RFC 7118)

The browser sends SIP messages over a WebSocket connection to the SIP proxy or SBC. The proxy terminates the WebSocket and converts to standard SIP transport. Kamailio supports WebSocket via the WebSocket module. Asterisk supports it via PJSIP WebSocket transport.

; Kamailio WebSocket support
loadmodule "websocket.so"
loadmodule "xhttp.so"

modparam("websocket", "keepalive_timeout", 180)

event_route[xhttp:request] {
    if ($hdr(Upgrade) =~ "websocket") {
        ws_handle_handshake();
        exit;
    }
}

; In request_route
if (proto == WS || proto == WSS) {
    # Handle WebSocket SIP the same as standard SIP
    xlog("L_INFO", "WebSocket SIP from $si
");
}

4. Media plane interoperability

DTLS-SRTP to SDES-SRTP conversion

WebRTC mandates DTLS-SRTP. Most SIP endpoints use SDES-SRTP (keys in SDP) or plain RTP. The gateway must:

Complete DTLS handshake with the WebRTC client
Decrypt incoming SRTP from WebRTC using DTLS-derived keys
Re-encrypt as SDES-SRTP for the SIP side (or send as plain RTP for internal calls)
Reverse the process for media flowing back to WebRTC

Codec transcoding: Opus to G.711

WebRTC clients default to Opus. Most PSTN-connected SIP endpoints use G.711. Transcoding is required unless the SIP endpoint also supports Opus.

; FreeSWITCH — force G.711 on SIP leg, Opus on WebRTC leg
<action application="set" data="absolute_codec_string=PCMU@8000h,1i"/>

; Asterisk PJSIP — transcode endpoint
[webrtc-endpoint]
type=endpoint
allow=opus
allow=ulaw

[sip-endpoint]
type=endpoint
allow=ulaw
allow=alaw

BUNDLE and rtcp-mux handling

WebRTC uses BUNDLE to multiplex all media streams on a single port and rtcp-mux to share RTP and RTCP on the same port. SIP endpoints use separate ports. The gateway must un-bundle for the SIP side and handle separate RTCP ports.

5. NAT and ICE handling

ICE (Interactive Connectivity Establishment) is mandatory in WebRTC but unknown to SIP. The gateway's role in NAT/ICE:

Act as the ICE endpoint for the WebRTC client — complete STUN checks and connectivity tests
Strip all ICE-related SDP attributes before forwarding to SIP (a=candidate, a=ice-ufrag, a=ice-pwd, a=ice-options)
Replace the WebRTC client's ICE-derived address with the gateway's own address in the SDP c= line
Handle TURN relay if needed for WebRTC clients behind symmetric NAT

; Kamailio + RTPEngine — strip ICE for SIP leg
; WebRTC side: full ICE negotiation
; SIP side: classic c= line addressing

rtpengine_manage("ICE=remove DTLS=off SDES-off replace-origin replace-session-connection");

; For WebRTC to SRTP SIP (not plain RTP):
rtpengine_manage("ICE=remove DTLS=off SRTP replace-origin replace-session-connection");

6. Troubleshooting WebRTC SIP interoperability

Issue 01

No audio after call connects

ICE not stripped from SIP-side SDP, or DTLS handshake not completing on the WebRTC side. Check the SDP on the SIP leg — should have a simple c= line IP, no a=candidate lines. Check DTLS Client Hello / Server Hello in PCAP on the gateway side of the WebRTC connection.

Issue 02

488 Not Acceptable Here from SIP endpoint

ICE attributes or DTLS fingerprint lines reaching the SIP endpoint in the SDP. SIP endpoints don't understand these and reject the offer. Ensure the gateway strips all WebRTC-specific SDP attributes before forwarding to SIP: a=candidate, a=ice-ufrag, a=ice-pwd, a=fingerprint, a=setup, a=extmap.

Issue 03

Choppy or robotic audio

Codec transcoding quality issue or packet timing mismatch between Opus and G.711. Opus at 20ms ptime should match G.711 at 20ms ptime. Check that the gateway isn't changing ptime between legs — mismatched ptime causes audio artifacts during transcoding.

Issue 04

Call connects then audio stops after 30 seconds

ICE consent refresh failing. WebRTC requires periodic STUN binding requests to maintain ICE consent. If the gateway stops responding to these, the browser considers the connection failed and mutes audio. Ensure the gateway correctly handles STUN consent refresh after the call is established.

Frequently asked questions

What is the difference between WebRTC and SIP?

WebRTC uses WebSocket for signaling, mandatory ICE for NAT traversal, mandatory DTLS-SRTP for media encryption, BUNDLE for multiplexing, and Opus as the default codec. SIP uses UDP/TCP/TLS for signaling, optional SBC or STUN for NAT, optional SRTP or plain RTP, separate media ports, and G.711 as the most common codec. Bridging them requires converting between all these differences simultaneously.

How do you bridge WebRTC to SIP?

Bridge WebRTC to SIP using a media gateway (FreeSWITCH, Asterisk, or a certified SBC). The gateway terminates the WebRTC leg with DTLS-SRTP and ICE, then originates a new SIP leg with SDES-SRTP or plain RTP and a standard c= line address. It transcodes Opus to G.711 and strips ICE candidates from the SDP before forwarding to SIP endpoints.

Why does WebRTC to SIP have no audio?

No audio in WebRTC to SIP bridging is usually caused by ICE candidates not being stripped from the SIP-side SDP (488 or silent failure), DTLS handshake not completing on the WebRTC side, or the gateway not performing codec transcoding between Opus and G.711. Check the SDP on the SIP leg — it should contain only a simple c= line with no ICE attributes.

Having WebRTC to SIP interoperability issues?

Paste your SIP trace into SIPSymposium. The analyzer checks for ICE stripping, DTLS negotiation, codec compatibility between WebRTC and SIP legs, and SDP format issues.

Analyze my trace Create free account

Related guides