What is a WebRTC to SIP gateway?

A WebRTC to SIP gateway is a server that bridges browser-based WebRTC connections (using DTLS-SRTP, ICE, and the JavaScript WebRTC API) with traditional SIP/RTP telephony infrastructure. It converts WebRTC media (DTLS-SRTP) to standard RTP, translates WebRTC signalling to SIP, and handles NAT traversal via STUN/TURN. Common open-source implementations include Janus Gateway, Kamailio with RTPEngine, OpenSIPS with rtpengine, FreeSWITCH, and Asterisk WebRTC.

How does WebRTC NAT traversal work with ICE, STUN, and TURN?

ICE (Interactive Connectivity Establishment) gathers candidate IP:port pairs from the local network, STUN server (public IP discovery), and TURN relay. Both endpoints exchange candidates, try direct UDP first, then TCP, then TURN relay. TURN is the fallback for restrictive firewalls — all media is relayed through the TURN server. A properly configured TURN server ensures WebRTC calls succeed in 100% of network environments.

Which media server is best for WebRTC to SIP bridging?

FreeSWITCH is the most popular choice for WebRTC-SIP bridging due to native DTLS-SRTP support, built-in TURN server, and high concurrency (2,000+ calls per server). Janus Gateway is preferred for WebRTC-specific features (SFU, data channels). Asterisk works well for lower call volumes with deep IVR and dialplan flexibility. Kamailio with rtpengine is ideal for carrier-grade SIP proxy with WebRTC transcoding.

Who should hire CelloIP for WebRTC SIP gateway development?

Businesses building click-to-call widgets, browser-based contact centres, WebRTC softphones, telemedicine platforms, or any application connecting browsers to PSTN/SIP should hire CelloIP Technologies. We have delivered 50+ WebRTC projects using Janus, FreeSWITCH, Asterisk, and Kamailio. Rates from $25/hr.

Back to Blog
WebRTCSIPPSTNGatewaysMedia ServersReal-Time

WebRTC to SIP GatewayArchitecture & Implementation

Complete guide to bridging browser-based WebRTC calls to SIP/PSTN networks. Learn SDP negotiation, ICE/STUN/TURN NAT traversal, signalling bridging, media transcoding, and how to deploy production-ready gateways.

25+

Live gateways deployed

<150ms

End-to-end latency

DTLS-SRTP

Encryption standard

ICE+TURN

NAT traversal

By Kaushik Parmar · Founder & VoIP Architect, CelloIP Technologies · April 15, 2026 · 18 min read

Table of Contents

  1. 1What Is a WebRTC SIP Gateway?
  2. 2Architecture & Network Layers
  3. 3SDP Offer/Answer Negotiation
  4. 4NAT Traversal: ICE, STUN, TURN
  5. 5Signalling Bridge (SIP ↔ WebRTC)
  6. 6Media Handling & Codec Translation
  7. 7Gateway Platforms & Solutions
  8. 8Real-World Implementation Patterns
  9. 9Latency & Performance Comparison
  10. 10Security & Encryption
  11. 11FAQ

What Is a WebRTC SIP Gateway?

A WebRTC SIP gateway is a server that bridges browser-based WebRTC connections with SIP signalling and RTP media, enabling browsers to make calls to traditional phone numbers via PSTN networks. It acts as a protocol translator, media transcoder, and security boundary between the modern WebRTC world and legacy telecom infrastructure.

CelloIP has deployed 25+ production gateways ranging from 50 to 10,000 concurrent calls, supporting startups, enterprises, and carriers worldwide.

Network Architecture & Protocol Layers

A typical gateway spans five protocol layers:

1.

Browser WebRTC Stack

getUserMedia(), RTCPeerConnection, DTLS-SRTP encryption, ICE NAT traversal

2.

Signalling Server

WebSocket or HTTP endpoint that exchanges SDP offers/answers between browser and gateway

3.

WebRTC Media Gateway

Core bridging logic: translates WebRTC to SIP, manages codec negotiation, handles DTLS

4.

SIP/RTP Transport

SIP signalling trunk, RTP media streams, TLS/SRTP or plain UDP depending on carrier

5.

PSTN/SIP Termination

Carrier endpoint accepting SIP INVITEs and routing to traditional phone networks

SDP Offer/Answer Negotiation

SDP (Session Description Protocol) is the language both WebRTC and SIP use to describe media capabilities. The gateway translates browser SDP offers into SIP INVITEs and vice versa:

  1. 1. Browser: Creates RTCPeerConnection, generates SDP offer
  2. 2. Signalling: Sends browser SDP to gateway
  3. 3. Gateway: Parses SDP, creates SIP INVITE to carrier
  4. 4. Carrier: Responds with 200 OK + SDP answer
  5. 5. Gateway: Translates SIP answer back to WebRTC answer
  6. 6. Browser: Receives answer, activates peer connection, media flows
javascriptBrowser SDP Offer (simplified)
v=0
o=- 123456 2 IN IP4 192.168.1.100
s=-
m=audio 54321 RTP/SAVPF 111
c=IN IP4 203.0.113.50
a=ice-ufrag:abcd1234
a=ice-pwd:secret+password
a=fingerprint:sha-256 12:34:56:78:...
a=rtpmap:111 opus/48000/2

NAT Traversal: ICE, STUN, TURN

90% of WebRTC call failures are NAT/firewall related. Without proper ICE, STUN, and TURN configuration, calls fail silently.

ICE

Gathers all candidate addresses and tests until one works

STUN

Discovers public IP. Works for most NATs; fails for symmetric

TURN

Relays media through server. Guaranteed; higher latency

javascriptConfigure STUN + TURN servers
const peerConnection = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" },
    {
      urls: "turn:turn.celloip.com:3478?transport=udp",
      username: "user_token",
      credential: "password_base64"
    }
  ],
  iceTransportPolicy: "relay" // TURN-only for privacy
});

Signalling Bridge: WebRTC ↔ SIP

The gateway must translate between two entirely different call state machines. Key mappings:

EventWebRTCSIP
InitiatingcreateOffer()INVITE
Remote acceptedsetRemoteDescription()200 OK
Ending callpeerConnection.close()BYE
DTMF (keypad)insertDTMF()RFC 2833 RTP events

Media Handling & Codec Translation

WebRTC prefers Opus (low latency), but carriers typically only support G.711 or G.729. rtpengine handles real-time transcoding, DTLS-SRTP bridging, and ICE rewriting:

  • Transcode Opus ↔ G.711, G.729, AMR
  • Decrypt WebRTC DTLS-SRTP, encrypt for SIP
  • Rewrite ICE candidates for NAT
  • Control bitrate (Opus VBR → fixed G.711)

Gateway Platforms & Solutions

Four dominant open-source platforms:

Janus

Lightweight, modular. Best for startups

Asterisk

PBX + gateway. Native SIP, IVR, call recording

FreeSWITCH

Modular, high-performance. Carriers & service providers

Kamailio + rtpengine

SIP B2BUA. Enterprise SBC, carrier-grade scale

Real-World Implementation Patterns

SaaS Calling (100-1000 concurrent)

Stack: Node.js + Janus + Twilio trunk

Benefit: Fast deployment, simple

Enterprise PBX (100-5000 extensions)

Stack: Asterisk WebRTC + rtpengine

Benefit: IVR, recording, queues

Carrier-Grade (5000+ concurrent)

Stack: Kamailio + rtpengine cluster + HAProxy

Benefit: Scales horizontally, topology hiding

Latency & Performance

Where latency hides in a WebRTC to PSTN call:

Browser media init50-150ms
ICE candidate gathering100-500ms
SDP exchange100-300ms
DTLS handshake500-1000ms
SIP INVITE to answer500-2000ms
Total P2P (browser-browser)<150ms
Total (browser-PSTN)1-3 seconds

Security & Encryption

WebRTC gateways handle sensitive voice data. Enforce encryption at every layer:

  • DTLS-SRTP: All WebRTC media encrypted end-to-end
  • TLS signalling: Protects SDP and call state from eavesdropping
  • CORS: Restrict cross-origin requests to trusted domains
  • ICE filtering: Block private IPs, prevent topology leakage
  • Certificate pinning: DTLS and TLS cert validation
  • Rate limiting: SIP gateway level (Kamailio pike module)

Frequently Asked Questions

QWhat's the difference between a WebRTC gateway and a SIP trunk?

A WebRTC gateway bridges two protocols: it accepts WebRTC connections (DTLS-SRTP, ICE, JavaScript API) from browsers and translates them into SIP signalling and RTP media to send to a SIP trunk (carrier). A SIP trunk alone just connects two SIP systems. The gateway does the protocol translation.

QWhy do we need TURN servers if we have STUN?

STUN helps endpoints discover their public IP and punch through many firewalls. TURN is fallback: when direct UDP is blocked (some corporate networks, NAT type symmetric), TURN relays the media through its server, guaranteeing connectivity at the cost of bandwidth and latency.

QCan a single codec work for WebRTC and PSTN calls?

Not always. WebRTC clients prefer Opus (low latency), while PSTN carriers may only support G.711 or G.729. The gateway's RTP engine (rtpengine, Asterisk) handles real-time transcoding. This adds CPU load but ensures compatibility.

QWhat latency can I expect from browser to PSTN?

Best-case is 1-1.5 seconds (local gateway, direct carrier). Typical range is 1.5-3 seconds accounting for SDP exchange, DTLS handshake, gateway processing, and carrier routing. WebRTC P2P calls (browser-to-browser) are <150ms.

QIs Janus or Asterisk better for WebRTC SIP gateways?

Janus is lightweight and modular — ideal for startups and single-purpose gateways. Asterisk is heavier but feature-rich: native SIP, IVR, call recording, presence. For a PBX replacement, Asterisk; for a simple gateway, Janus. FreeSWITCH and Kamailio suit high-scale carrier deployments.

QHow do I avoid exposing browser private IPs in ICE candidates?

Use mDNS (mdns:// candidates) and filter private IPs client-side with RTCIceTransportPolicy set to relay. On the gateway, restrict ICE candidates to public IPs only. This prevents information leakage about your internal network topology.

Related Articles

SIP

Kamailio SBC Configuration

Comparison

Asterisk vs FreeSWITCH

Carriers

OpenSIPS Load Balancing

Build Production WebRTC Gateways

CelloIP Technologies designs and deploys WebRTC SIP gateways for startups, enterprises, and carriers. 25+ live gateways connecting 100,000+ monthly browser-based calls to PSTN networks.

Request ConsultationView ServicesHire WebRTC Developers — From $25/hr