Asterisk WebRTC: distinguish SIP, ARI and media WebSockets

Name the socket before configuring it

A WebSocket connection identifies a transport, not its application. For a browser SIP endpoint, RFC 7118 negotiates the sip subprotocol and carries SIP requests and responses. Check the requested URI and selected subprotocol before debugging endpoint credentials. A socket accepted for another application is not a successful SIP connection.

For this design, browser audio follows the separate WebRTC media path. WSS protects the signaling connection; it does not establish ICE, complete DTLS or prove intelligible media.

Keep ARI control and WebSocket media separate

The traditional ARI event socket at /ari/events sends JSON application events and connects with REST operations and Stasis dialplan ownership. ARI outbound WebSockets add persistent or per-call connections from Asterisk to an application, with their own reconnection lifecycle. Neither is the browser endpoint SIP transport.

chan_websocket is a different channel driver for application media. It sends media in binary frames and commands or events in text frames; it can serve ARI ExternalMedia or be used from Dial. Asterisk documents its introduction in 22.6.0, 23.0.0, 21.11.0 and 20.16.0. Its presence does not replace the PJSIP WebSocket transport used by a SIP.js client. Check the exact installed patch release and loaded module before adopting it.

Find the HTTPS certificate owner

Asterisk’s WebRTC tutorial assigns the HTTPS listener, key and certificate to the built-in HTTP service, and also defines a PJSIP transport with protocol=wss. Its WSS example explicitly says other transport parameters are ignored. Do not assume that editing a conventional PJSIP TLS certificate updates the browser-facing HTTP certificate.

Use http show status to inspect the listener and /ws URI, then verify the hostname and trust presented at the client boundary. A reverse proxy adds another certificate and upgrade owner. Restrict administrative services separately from the calling endpoint. The tutorial contains historical examples; its example port, open bind and self-signed setup are not a production security policy.

Inspect what webrtc=yes actually enables

The Asterisk 22 res_pjsip reference says webrtc=yes enables rtcp_mux, use_avpf, ice_support and use_received_transport. It also defaults media_encryption to dtls, dtls_verify to fingerprint and dtls_setup to actpass; certificate auto-generation is enabled if dtls_cert_file is unset. Record the effective endpoint configuration rather than treating that convenience option as the whole installation.

These defaults do not supply endpoint credentials, allowed dialplan access, a browser-trusted HTTPS certificate or a proven network path. Verify the actual endpoint, auth and AoR objects, allowed codecs and Contact independently. Standalone Asterisk examples must not overwrite FreePBX-generated configuration.

Keep branch documentation separate from installed capability

The branch-22 chan_websocket reference is generated from GIT, so its table can describe features newer than an installed package. For example, control_message_format lists introduction in 22.8.0, while write_timeout lists 22.12.0. Those entries are documentation boundaries, not a claim that the local host has that release or that upgrading is required for ordinary browser SIP calling.

Confirm available options against the installed release and its module help. Do not copy a new media-driver option into PJSIP to repair an unrelated WSS handshake.

Build an acceptance record for the intended path

For a browser SIP endpoint, preserve HTTPS identity and URI, sip subprotocol selection, SIP authentication, stored Contact, selected dialplan, negotiated SDP, ICE state, DTLS state, remote media attachment and audible conversation. Include an incoming call after the relevant idle interval and the intended fallback when the application disappears. Consult the browser webphone guide when capture or playback fails.

For an ARI or application-media design, retain a separate controller and media lifecycle record. Successful socket connection, an application event, an answered channel and received sound are different outcomes. These are proposed acceptance checks; no Asterisk host, module, browser, proxy, certificate, controller, media channel or live call was inspected or tested.

Follow an answered but silent browser call

When a browser registers and answers through PJSIP but audio is absent, use the Asterisk WebRTC media diagnostic. It correlates the final browser-facing SDP with the nominated ICE pair, DTLS association, SRTP counters, the other Asterisk leg and playback without treating WSS success as a media result.

Distinguish browser media from application media WebSockets

A browser WebRTC endpoint uses SIP-over-WebSocket plus ICE and DTLS-SRTP media. Asterisk application media over `chan_websocket` instead streams raw codec data in binary WebSocket frames. The sockets can participate in one call but do not share framing, security or reachability evidence.