The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Browser calling in an Asterisk-based CRM works when the browser can speak SIP over a secure WebSocket to the PBX and can send audio over WebRTC media. In the open-source FARA CRM (built with FastAPI and React), Artem of Eurodoo describes a design where the application backend carries only SIP signaling, while the voice audio goes directly between the browser and Asterisk whenever the network allows it. The goal is familiar to any sales or support team: click a phone number in a contact record and talk from the browser, with inbound calls answered in the same tool.
How the pieces fit together
The most important decision in this design is what the CRM server is allowed to touch. The author’s answer is that the server handles signaling and nothing else. As Artem puts it: “The key idea: only SIP signaling goes through the backend.” Splitting the two traffic types keeps the web application out of the audio path and makes it easier to reason about load, firewalls and failure modes.
| Traffic | Path described by the author | When it is used |
|---|---|---|
| SIP signaling (registration, call setup, teardown) | Browser (JsSIP) → secure WebSocket (WSS) → FastAPI /ws/sip → WebSocket → Asterisk |
Always; the backend proxies these frames |
| Audio (RTP with DTLS-SRTP encryption) | Browser ↔ Asterisk directly | Whenever a direct media path exists |
| Audio via relay | Browser ↔ coturn TURN server ↔ Asterisk | When NAT or a blocked UDP path prevents direct media |
PBX prerequisites in Asterisk or FreePBX
A conventional SIP extension is not enough for a browser. The author recommends enabling WebRTC on a PJSIP endpoint. Their configuration uses webrtc=yes, which they describe as switching on the DTLS, ICE and AVPF behavior that browsers require. Before building anything on top, confirm the following on the PBX:
- A PJSIP extension with WebRTC enabled for each user who will place calls from the browser.
- A separate extension for the browser if that same employee also uses a desk phone, because the media settings differ between the two.
- WSS listening on TCP 8089. This is the default port in the author’s setup.
- UDP 10000–20000 open for RTP. This is also the author’s default range.
These values are the author’s defaults, not universal settings. Match them to your own Asterisk or FreePBX configuration and to the firewall rules between the PBX, the CRM server and the internet.
#1 Best Overall
- Mid-level phone, ideal for professionals and managers with moderate call load
- Ergonomic design with adjustable display
- Built-in Bluetooth, Wi-Fi
HTTPS and microphone access
Browsers only grant microphone access in a secure context, so the CRM page itself must be served over HTTPS. The WSS connection to the PBX must also use a certificate the browser trusts. If either requirement fails, the softphone may appear to load while calls never start, so check the certificate chain and the page origin before debugging SIP.
The FastAPI signaling proxy
The backend endpoint at /ws/sip does the work that a direct browser-to-PBX connection would otherwise do. In the author’s implementation it runs these steps for each connection:
- Reads the token sent with the WebSocket request and authenticates the CRM user.
- Resolves the PBX connector the user has selected.
- Checks that the user owns a line on that PBX, so one employee cannot register another employee’s extension.
- Obtains the PBX WebSocket endpoint for that connector.
- Forwards frames in both directions between the browser and Asterisk.
The proxy must also accept and echo the sip WebSocket subprotocol. The author reports that when this handshake is omitted, the browser closes the connection, so it is one of the first things to verify if registration fails immediately.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
- Supports 4 SIP accounts and 4 multi-purpose line keys
- Swappable faceplate to allow for easy logo customization
- GRP2612W includes built-in dual-band Wi-Fi support. Ethernet cord must be disconnected to enable Wi-Fi capability
- HD audio supporting all major codecs, including wideband codecs G.722 and Opus Up to 16 digital BLF Keys
- Enterprise-level protection including secure boot, dual firmware images, and encrypted data storage
The author gives three reasons for routing signaling through the backend rather than letting browsers connect straight to the PBX. The PBX endpoint stays behind the CRM domain, the connection can follow the CRM’s own policy settings, and access control is enforced in one place.
The browser softphone
The frontend uses JsSIP, a JavaScript SIP library that runs over WebSocket and WebRTC. The author’s sequence is:
- Create a JsSIP WebSocket interface that points at the CRM proxy rather than at Asterisk.
- Construct a JsSIP user agent (UA) with the employee’s SIP URI and credentials, then register and start it.
- For outbound calls, request audio only with video disabled, and pass the ICE server configuration so the browser can find a media path.
- For inbound calls, listen for the
newRTCSessionevent and answer through the session’sanswer()method. - When an employee answers, the CRM opens the matching client card, so the caller’s record is on screen before the conversation starts.
Click-to-call uses the same user agent. A click on a number in the CRM places the outbound call through this softphone, which is why registration and ICE configuration have to be right before the click-to-call feature can work.
Rank #3
- Make more natural and life-like calls with Polycom HD Voice
- 2. 8” color display: an engaging experience offering visual information at a glance
- Two Gigabit Ethernet ports offer cost savings and performance benefits
- USB port enables users to move data around more quickly
- Integrates with more than 60 industry leading call control platforms
TURN fallback and relay protection
Some networks never allow a direct media path. Restrictive NAT, mobile networks and corporate firewalls that block UDP all cause this. For these cases the author runs coturn, a TURN server, alongside the CRM in Docker Compose. TURN relays the audio when a direct path fails.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe CRM generates short-lived TURN credentials from a shared secret and returns both UDP and TCP relay endpoints to the browser. TCP matters where UDP is blocked entirely. Because a relay that accepts arbitrary destinations can be abused to reach internal hosts, the author’s sample configuration applies these protections:
- Shared-secret authentication is enabled, so only the CRM can issue relay credentials.
- The coturn command-line interface is disabled.
- Private and loopback address ranges are blocked as relay destinations.
- If Asterisk sits on the same private network as the relay, its address is allowed explicitly, since the private-range block would otherwise stop it.
Treat this sample as a starting point. The right ranges and credential lifetimes depend on your network.
Rank #4
- NOT LANDLINE PHONE: PROFESSIONAL VOIP PHONE ONLY! This device is a Voice over IP (VoIP) Phone and is NOT compatible with standard home landline/PSTN connections (RJ11). It REQUIRES a subscription to a SIP Service Provider (e.g., VoIP.ms, RingCentral, ) or an Active PBX System (e.g., 3CX, Asterisk, FreePBX) and network configuration to function.
- CRYSTAL CLEAR HD AUDIO & NOISE REDUCTION: Featuring advanced noise reduction technology and wideband codecs like G.722 and Opus, this VoIP phone ensures high-definition voice transmission. The HD handset and speaker provide stable, professional-grade communication even in busy or noisy office environments.
- ENHANCED 6-PARTY CONFERENCING: Boost team collaboration with built-in 6-party conference support, allowing real-time multi-party communication without external bridges. Designed for busy professionals, it streamlines workflows and provides an efficient collaboration experience.
- VIBRANT COLOR DISPLAY & ERGONOMIC DESIGN: Equipped with a 2.4-inch 320x240px color display with an adjustable backlight for high-resolution graphics. The versatile stand adjusts to 60° and 45° for desk use or a 15° wall-mount angle to suit any workspace layout.
- SEAMLESS CONNECTIVITY & POE SUPPORT: This T52P model supports 2 SIP accounts and features dual 100M Ethernet ports. It is powered via Power over Ethernet (PoE) for a clean setup, and unlike many competitors, it includes a dedicated 5V/1A power adapter for flexible installation.
Design trade-offs and the alternatives
The author’s implementation makes three choices. Each one has a plausible alternative, and the table shows what was chosen and why.
| Decision | Alternative | Author’s choice | Reason given |
|---|---|---|---|
| Media path | Relay all audio through TURN | Direct media first, TURN only as fallback | Keeps the server out of the audio path and reduces relay load |
| Signaling path | Browser connects straight to the PBX WebSocket | Backend proxy | Keeps the PBX behind the CRM domain, follows CRM policy, enforces access control |
| Extension | Reuse the employee’s desk-phone extension | Separate browser extension | Desk-phone and browser media settings differ |
What this account does and does not establish
This is a first-person technical walkthrough by Artem of Eurodoo, published on DEV Community and accessed on 7 October 2026. It describes one working system in detail, and it is the author’s account rather than independent verification.
The write-up does not state the software versions it was built against, provide a browser compatibility matrix, describe a test method, or report measured call quality or reliability. It also does not provide independent confirmation of the production use it describes. Anyone adapting the design should verify the PBX settings, ports, certificates and relay rules against their own environment before relying on them.
The design is still useful as a map. It shows where each piece belongs, which failure modes are most likely (certificates, the subprotocol handshake, blocked UDP), and why keeping signaling in the backend while audio flows directly is a sound starting point for a browser-calling feature.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
