Asterisk WebRTC is the combination of the Asterisk PBX with WebRTC signaling and media, letting browsers place and receive calls directly against an Asterisk server. It requires secure WebSocket (WSS) transport, DTLS-SRTP media encryption, ICE support, and an Opus-capable codec setup on a PJSIP endpoint. VideoSDK offers an alternative path: a managed video and audio calling SDK that removes the certificate, NAT, and media-server plumbing entirely, while Asterisk remains the right choice when you need full PBX control. This guide walks through the complete Asterisk WebRTC setup, from TLS certificates to one-way audio troubleshooting.
Introduction
Every developer who has tried to put a phone into a web page eventually meets Asterisk. The open-source PBX has powered SIP trunks, IVRs, and call centers for over two decades, and the pull toward browser-based calling keeps getting stronger. Support desks want a click-to-call button. Telehealth platforms want patients to join from a URL with no downloads. Sales teams want dialers embedded in the CRM.
WebRTC is the technology that makes this possible, and browsers enforce its rules strictly: encrypted media, secure signaling, and mandatory NAT traversal. That enforcement collides head-on with how Asterisk was traditionally configured. Plain SIP over UDP, unencrypted RTP, and relaxed endpoint settings all fail silently the moment a browser joins the party.
The good news is that modern Asterisk (version 18 and later, including Asterisk 23) handles WebRTC natively through PJSIP and the built-in WebSocket transport. The bad news is that the configuration has a dozen places to get it wrong, and most of them produce the same symptom: a call that rings but carries no audio. This guide covers the full path, including the parts most tutorials skip, like external media addressing, TURN fallback, and the actual browser-side verification steps.
What is WebRTC and How It Differs from Traditional SIP
WebRTC is defined as a browser-native real-time communication framework that establishes peer-to-peer audio, video, and data channels between two endpoints. Unlike traditional SIP, which negotiates media details through server-relayed signaling and often sends RTP in the clear, WebRTC mandates encryption at every layer.
Three requirements separate WebRTC from a classic SIP desk phone registration. First, signaling must travel over a secure transport, which in the browser world means WebSocket Secure (WSS) rather than raw TCP or UDP. Second, media must be encrypted with DTLS-SRTP, meaning the DTLS handshake exchanges certificates before a single audio packet flows. Third, connectivity must be established through ICE (Interactive Connectivity Establishment), a framework that gathers candidate addresses, including STUN- and TURN-derived relay candidates, to punch through NATs and firewalls.
Browsers enforce all three. Chrome, Firefox, and Safari will refuse to negotiate media with a peer that skips the DTLS handshake or offers an insecure WebSocket endpoint. This is why an Asterisk server that works fine with hardware SIP phones suddenly produces dead air when a browser connects: the browser is simply declining to proceed with an insecure setup, and it usually reports the refusal only in the console.
The mental model to hold onto: SIP-over-WebSocket replaces the SIP transport, ICE replaces naive RTP addressing, and DTLS-SRTP replaces plain RTP. Asterisk supports all three, but each must be explicitly enabled.
Core Asterisk Requirements for WebRTC
Before touching endpoint configuration, confirm the server itself is WebRTC-capable. You need Asterisk 18 or newer; Asterisk 23 is the current certified series in 2026 and is the recommended baseline for new deployments. Older branches lack the polished WebRTC defaults and the Opus passthrough behavior that modern browsers expect.
On the network side, plan for three groups of ports. The HTTP server needs its TLS port (typically 8089) reachable for the WSS signaling channel. The RTP engine needs its media port range open, typically a contiguous block of UDP ports allocated in the RTP configuration. Finally, if you deploy a TURN server, it needs its own listening ports, including the relay port range, reachable from client networks.
Required Asterisk Modules
Four modules form the WebRTC stack. The PJSIP channel driver and its SIP-over-WebSocket companion provide the signaling path. The built-in HTTP server module hosts the WebSocket endpoint. The Opus codec translator module is essential because browsers negotiate Opus for audio by default, and without the codec installed, calls fail codec negotiation before media ever flows. Verify all four are loaded at startup; a missing codec module is the single most common cause of immediate call failure.
TLS Certificate Options
The certificate must be trusted by the browser, full stop. A self-signed certificate works for lab testing only if you manually accept it in the browser first, by visiting the WebSocket port over HTTPS and approving the warning. In production, use a certificate from a public CA. Let's Encrypt remains the practical default: issue a certificate for the hostname clients will connect to, and make sure the Asterisk HTTP server's TLS settings point at the full chain file, not just the leaf certificate. A missing intermediate certificate produces a confusing failure where the WebSocket connection opens in some browsers and fails in others.
One subtlety: the certificate's common name or SAN must match the hostname in the WebSocket URL the client dials. A perfectly valid certificate for the internal server name will still be rejected if the browser connects to a different public hostname.
Configuring Secure WebSocket (WSS) Transport
The WSS transport is the foundation everything else sits on, and it is where most first attempts fail. The configuration lives in two places that must agree with each other: the HTTP server section, which owns the TLS certificate and private key, and the transport definition in the PJSIP configuration, which declares a WebSocket transport bound to that TLS-enabled HTTP server.
The sequence matters. The HTTP server must be configured for TLS with the certificate and key paths, and enabled, before Asterisk will accept secure WebSocket connections. The PJSIP transport then references WebSocket as its type with TLS enabled, effectively telling Asterisk that SIP messages arriving over that WebSocket are PJSIP traffic. Because browsers cannot use plain WebSocket for signaling from HTTPS pages, a non-TLS WebSocket transport is not an option; the browser will block the connection attempt before it reaches Asterisk.
A common mistake is enabling TLS on the transport while leaving the HTTP server unencrypted. The transport's TLS setting and the HTTP server's TLS settings interact: the HTTP server performs the actual TLS termination for the WebSocket upgrade, so the certificate configuration belongs there. If the WebSocket handshake completes but SIP registration never arrives, check that the transport is actually bound to the WebSocket-capable HTTP server rather than a plain HTTP listener.
The flow from browser to Asterisk looks like this:
Once the transport accepts connections, the Asterisk command-line interface will show the WebSocket transport as bound and ready. Test the TLS layer independently by loading the WebSocket URL in the browser as a plain page visit: if the browser shows a certificate warning, fix the certificate before debugging anything else.
Setting Up a PJSIP Endpoint for WebRTC
Here is where Asterisk earns its reputation for configurability, because a WebRTC endpoint differs from a normal SIP endpoint in five specific ways. The good news is a single shortcut handles all of them.
Setting the endpoint's WebRTC option to enabled applies the full set of WebRTC-required defaults in one move. It enables ICE support, turns on DTLS-SRTP media encryption, activates AVPF feedback (the RTP profile browsers use for congestion control), enables RTCP multiplexing so signaling and media share a single port pair, and forces the use of the WebSocket transport. Without this shortcut, you would need to set each of those five parameters individually, and forgetting any one of them produces the classic symptom: registration succeeds, the call is answered, and there is no audio in one or both directions.
Beyond the shortcut, three endpoint parameters deserve explicit attention. The media encryption setting must be DTLS, which the shortcut handles, but if you override it, calls break. The ICE support setting must remain enabled, because browsers will not send media to an endpoint that refuses ICE. The DTLS certificate fingerprint configuration, which the shortcut populates automatically from the HTTP server certificate, must be present; if you supply your own, it must match the certificate the HTTP server presents.
Codec selection is the next decision point. Browsers negotiate Opus for audio, and Asterisk's Opus codec module handles it natively. If your Asterisk build lacks the Opus translator, the endpoint should at minimum allow passthrough, though transcoding to ulaw or alaw for trunk-side calls is the normal production pattern. For video, VP8 and H.264 are the realistic browser-compatible choices, with VP8 being the safest cross-browser default.
Authentication follows standard PJSIP patterns: the endpoint needs a matching authentication section with a username and secret, and the browser client registers with those credentials over the WebSocket. Because the WebSocket transport is shared, per-endpoint identification relies on SIP registration rather than connection identity, so each browser user should map to a distinct endpoint.
Common Pitfalls and How to Spot Them
Four failures account for nearly all broken setups. A missing Opus module shows up as an immediate codec negotiation failure in the Asterisk logs. A certificate hostname mismatch appears as a browser console TLS error before any SIP traffic flows. Forgetting the WebRTC shortcut produces one-way or no-way audio with successful registration. And pointing the endpoint at a non-WebSocket transport yields registration attempts that never complete. Read the logs in this order: browser console first, then Asterisk's SIP message trace, then the RTP debug output.
Integrating with FreePBX or a Stand-Alone Asterisk
FreePBX, the most widely deployed Asterisk management layer, handles WebRTC through its GUI rather than hand-edited configuration files. The key settings live in the extension (Advanced) configuration, where a transport dropdown lets you assign the WebSocket transport to a specific extension, and a WebRTC toggle switches the endpoint into browser-compatible mode. FreePBX generates the underlying PJSIP endpoint with the same five WebRTC defaults the manual shortcut applies, so the end result is equivalent; the difference is discoverability.
In stand-alone Asterisk, everything lives in the PJSIP configuration files and the HTTP server configuration, edited directly and reloaded. In FreePBX, those same files are generated, and manual edits can be overwritten on the next apply operation. The practical rule: in FreePBX, make WebRTC changes through the UI, and use the Asterisk CLI only for verification.
The FreePBX WebSocket transport itself is created in the SIP settings area, where you enable the built-in WebSocket transport and attach the TLS certificate. FreePBX also ships a built-in WebRTC phone client per extension, which is genuinely useful for testing: if the built-in client works but your custom page does not, the problem is in your client code, not the server.
The mapping between UI and underlying configuration looks like this:
Media Handling: RTP, ICE, and NAT Traversal
Signaling over WSS is the easy half. Media is where network reality intervenes, because RTP packets travel directly between the browser and Asterisk over UDP, and NAT plus firewalls conspire against that direct path.
Start with the RTP port range. Asterisk allocates media ports from a configured UDP range, and every port in that range must be open on the firewall between the browser and the server. A partially open range produces intermittent one-way audio, which is maddening to diagnose because some calls work and others do not depending on which port was allocated.
Next, the external media address. When Asterisk sits behind NAT or in a cloud environment like Amazon EC2, it advertises its local address in ICE candidates unless told otherwise. The external media address setting tells Asterisk to substitute its public address in the candidates it offers. Getting this wrong is the top cause of one-way audio in cloud deployments: the browser receives a candidate pointing at a private IP, cannot route to it, and falls back to no media path at all.
Finally, STUN and TURN. Asterisk can be configured to use an external ICE server for candidate gathering. A STUN server helps endpoints discover their public address; a TURN server relays media when direct paths fail, at the cost of bandwidth and latency. For deployments where corporate firewalls block UDP aggressively, a TURN server with TCP relay capability is the difference between working calls and support tickets. TURN servers are stateful and bandwidth-hungry, so size them for peak concurrent relayed calls, not total calls.
Testing the Setup: From Browser to Asterisk
Test in layers, from cheapest to most expensive. The classic test client is sipML5, the long-standing open-source JavaScript SIP-over-WebSocket demo, though any WebRTC softphone that supports SIP over WSS works, including the FreePBX built-in client.
Layer one is TLS. Load the WebSocket URL directly in the browser. A clean page load with no certificate warning means the TLS layer is sound. A warning means fix the certificate chain before anything else.
Layer two is registration. Connect the client and watch the Asterisk CLI for the registration arriving on the WebSocket transport. If the browser console shows the WebSocket opening but no SIP traffic, the transport binding is wrong. If SIP traffic arrives but registration is rejected, check the endpoint's authentication credentials.
Layer three is the call itself. Place a test call to an echo or playback extension. In the browser console, verify that ICE gathering completes with at least one usable candidate pair, and that the DTLS handshake finishes, which appears as a connected peer connection state. On the Asterisk side, enable RTP debugging to confirm packets are flowing in both directions. The DTLS fingerprint exchange is visible in the logs: the fingerprint Asterisk presents must match what the browser's peer connection reports, and a mismatch here means the certificate configuration diverged between the HTTP server and the endpoint.
Troubleshooting One-Wway Audio and Connectivity Issues
One-way audio in an Asterisk WebRTC deployment almost always traces to one of four causes, and you can check them in order of likelihood.
Codec mismatch comes first: confirm the Opus module is loaded and the endpoint allows it. Second is ICE failure: if the browser reports no usable candidate pair, the external media address is wrong or the RTP port range is blocked. Third is firewall asymmetry: the signaling port is open but the RTP range is not, so the call connects and immediately goes silent. Fourth is media direction: an endpoint configured for send-only or recv-only media, sometimes inherited from a template, produces audio in exactly one direction.
A fast diagnostic sequence: check the browser's peer connection state, then Asterisk's RTP statistics for the active channel. If Asterisk sees incoming packets but sends none, suspect media direction or codec. If Asterisk sees nothing at all, suspect ICE and the firewall. If both sides see packets but the browser plays silence, suspect a codec negotiation mismatch that passed signaling but failed media.
Advanced Topics: The WebSocket Channel Driver and ARI externalMedia
For developers building custom media applications rather than plain calling, Asterisk offers a second WebRTC path: the WebSocket channel driver used with the ARI externalMedia interface. Instead of terminating media inside Asterisk, externalMedia instructs Asterisk to fork the RTP stream to an external address, where your application, a speech-to-text engine, or an AI pipeline processes it directly.
This architecture suits recording bots, real-time transcription, and AI voice agents. Your application connects to Asterisk over ARI (a REST and WebSocket control interface), creates a bridge, and receives raw RTP that it decodes itself. The trade-off is complexity: you own the RTP handling, the Opus decoding, and the timing. For teams building AI voice features, managed alternatives like VideoSDK's AI agent infrastructure handle the STT, LLM, and TTS pipeline and the media plumbing, which is worth considering before committing to a custom externalMedia stack.
Summary and Next Steps
The complete Asterisk WebRTC recipe: a TLS certificate the browser trusts, a WSS transport bound to the TLS-enabled HTTP server, a PJSIP endpoint with the WebRTC defaults enabled, the Opus codec loaded, an open RTP port range, a correct external media address, and a TURN server for hostile networks. Test in layers, from TLS to registration to media, and the failure points reveal themselves in order.
Definitions Glossary
WSS (WebSocket Secure): The TLS-encrypted WebSocket transport that browsers require for SIP signaling from HTTPS pages. Asterisk hosts it on its built-in HTTP server, typically on port 8089.
DTLS-SRTP: The mandatory WebRTC media encryption scheme, where a DTLS handshake exchanges certificates and derives keys for SRTP-encrypted audio and video. Asterisk enables it automatically on WebRTC endpoints.
ICE (Interactive Connectivity Establishment): The NAT traversal framework that gathers candidate addresses, including STUN- and TURN-derived relays, so two endpoints can find a working media path.
PJSIP Endpoint: The Asterisk configuration object defining how a SIP client registers, authenticates, negotiates codecs, and exchanges media. WebRTC endpoints require ICE, AVPF, RTCP multiplexing, and DTLS encryption.
TURN Server: A relay that forwards media when direct browser-to-server paths fail, typically deployed alongside STUN for firewall-heavy enterprise networks.
Key Takeaways
- Asterisk WebRTC requires five coordinated settings on the PJSIP endpoint: ICE support, DTLS-SRTP encryption, AVPF, RTCP multiplexing, and the WebSocket transport, all applied at once by enabling the WebRTC option.
- The TLS certificate lives on the Asterisk HTTP server, must be trusted by the browser, and must match the hostname clients dial, or the WebSocket connection never opens.
- One-way audio in cloud deployments most often comes from a wrong external media address or a partially blocked RTP port range, not from signaling problems.
- FreePBX exposes the same WebRTC configuration through its GUI, including a built-in browser phone that is ideal for isolating server-side from client-side bugs.
- For custom media applications, the ARI externalMedia interface lets you fork RTP to your own pipeline, while managed platforms like VideoSDK handle the media, STT, and TTS plumbing for AI voice use cases.
Conclusion
Asterisk WebRTC is entirely achievable in 2026, but it rewards methodical setup: secure the transport, enable the WebRTC endpoint defaults, open the media path, and test each layer before moving to the next. The payoff is a browser that becomes a full softphone with nothing more than a URL. If you would rather skip the certificate, NAT, and media-server maintenance entirely, VideoSDK's video and audio calling SDKs provide managed real-time communication across ten platforms, with a free tier to start. What are you building with Asterisk WebRTC? Drop a comment, I'd love to hear whether you're wiring up a click-to-call support desk or a full browser softphone.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ