What travels over the socket
RFC 7118 defines a WebSocket subprotocol for SIP. The browser opens a connection and uses the sip subprotocol to exchange SIP messages. WSS protects that WebSocket connection with TLS. Audio is normally carried separately by WebRTC media transport, not inserted into the SIP WebSocket as ordinary voice packets. A working WSS handshake therefore establishes only the signaling transport. Registration, call authorization and media negotiation still need to succeed.
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.
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.
Watch the explanation
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.