VoIP.info Guide

SIP over WebSocket and WSS

Separate the browser signaling transport from the media transport when connecting a web softphone.

Reviewed 2026-10-16RFC 7118 and Asterisk documentation reviewed October 5, 2026; no browser, proxy, PBX or call laboratory validationIntermediateDocumentation based · not lab tested

What travels over the socket

RFC 7118 defines the sip WebSocket subprotocol for SIP requests and responses. The client handshake requests sip in Sec-WebSocket-Protocol and the server’s successful 101 response selects it. One SIP message occupies one WebSocket message; SIP can use text or binary frames, so a binary frame alone is not evidence of audio.

This SIP socket does not carry ordinary voice packets. Browser WebRTC media has a separate path. Other WebSocket applications can carry media: Asterisk’s chan_websocket is a separate application-media driver, rather than a SIP endpoint transport. Use the Asterisk integration guide to distinguish SIP, ARI control and application-media sockets.

A successful handshake proves the selected transport and subprotocol, not registration, route authorization, negotiated media or audible conversation.

WebRTC signaling and media take different paths
The browser exchanges signaling with an application or SIP service. Its media peer is a PBX or other endpoint. ICE can select a direct media path or a path through a TURN relay.

Logical connections, shown in one direction for clarity. Media and signaling are bidirectional. TURN relays encrypted packets; the negotiated media peer terminates DTLS-SRTP.

Check the web boundary

Confirm the expected hostname, path, certificate chain and WebSocket upgrade behavior. A reverse proxy must pass the upgrade correctly and keep long-lived connections usable. Its idle timeout can cause apparently random registration or incoming-call failures even when a short HTTP request works. Avoid embedding a shared administrator or trunk credential in downloaded JavaScript. The application needs an endpoint identity with limited permissions and a deliberate session-expiry strategy. Browser application authentication and SIP digest authentication may be separate exchanges.

Retain the selected subprotocol and response headers alongside the requested URL. A generic WebSocket tester connecting without the intended sip negotiation is not a complete SIP client acceptance test.

Isolate a failed call

  • WSS never opens: inspect DNS, certificate validation, upgrade response and proxy policy.
  • WSS opens but REGISTER fails: inspect SIP challenge handling and endpoint authorization.
  • Registration works but calls fail: inspect INVITE responses, routing and SDP.
  • Call answers without sound: inspect ICE, DTLS and media statistics.
  • Keep those results in one timeline. Reloading the page may recover a socket while erasing the evidence of why it failed. Capture the state before reconnecting, then verify an incoming call after the connection has been idle for the period that previously triggered the problem.

A SIP WebSocket is not a chan_websocket media pipe

SIP over WSS carries SIP messages with the sip subprotocol. The Asterisk media WebSocket guide covers a different WebSocket/... channel whose binary frames carry application media and whose text frames carry driver control events.

Place the Asterisk HTTP listener before SIP-over-WebSocket evidence

The built-in HTTP service guide keeps HTTPS identity and WebSocket route registration separate from SIP authentication, SDP and media.

Watch the explanation

Can I use SIP for WebRTC signaling?Tsahi Levent-Levi · 1:03 · Conceptual

Answers one common question quickly: WebRTC does not choose your application signaling, and browser-based SIP uses a browser-compatible transport such as WebSocket.

Read applicability and editorial notes →
Watch this video here

A conceptual explanation published in 2025; pair it with the SIP-over-WebSocket reference. Review used the available transcript and primary references; audio and screen readability remain unverified.

The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.