Sangoma Phone: FreePBX and PBXact client boundaries

Keep the client attached to its supported phone system

Sangoma documents the desktop client for Switchvox, FreePBX and PBXact, and its current release page states FreePBX/PBXact 15 or later. This is a phone-system-bound client family, not evidence that an arbitrary SIP registrar can be entered as a portable account. For a FreePBX or PBXact assessment, record the PBX edition and release, operating-system baseline, Asterisk branch, Sangoma Phone build, access path and the user identity actually assigned.

Do not transfer a feature from Switchvox to FreePBX/PBXact or from a browser announcement to the desktop application by name alone. Sangoma's desktop administration guide also includes older SNG7 and FreePBX 15-plus requirements; treat those as the documented scope of that procedure, not as proof that the same commands or packages apply unchanged to FreePBX 17 on Debian 12.

Inventory licensing, modules and the PJSIP owner

The FreePBX/PBXact administration guide requires Sangoma Connect user licensing and identifies both commercial and open-source module dependencies, including Sangoma Connect, sangomartapi, System Admin, Phone Apps, Framework, User Management and WebRTC. It also says each Sangoma Phone user is based on an existing PJSIP extension. A client download therefore does not establish entitlement, server readiness or a usable extension.

Capture the active license count, module versions and maintenance status before changing the PBX. Confirm the installed Asterisk branch and the corresponding FreePBX Asterisk modules rather than copying an RPM name from a different host. The guide warns that an Asterisk restart used in this path drops active calls; schedule, approve and verify that change instead of treating it as a harmless client installation step.

Separate PBX address, service access and user login

Sangoma's desktop installation procedure uses a host value composed from the PBX address and the Sangoma Phone Desktop Client Service secure port, whose documented default is 6443. It recommends a fully qualified domain name for remote users, requires the per-user login setting, and uses the User Management username and password also used for UCP. Those are three separate controls: resolvable server identity, reachable service, and authorized user.

Prefer a PBX name that matches the HTTPS certificate and can be resolved from the intended client networks. Open only the required service to the required firewall zones, then test local and authorized remote paths separately. Treat UCP credentials, password-reset access and any copied host string as sensitive provisioning material; a reachable port or accepted certificate does not prove the user is licensed or permitted.

Preserve the TLS, WebSocket and media boundaries

The administration guide calls for a selected certificate, enabled PJSIP TLS and WebSocket transports, PJSIP assignment for the default TLS port, and the mini-HTTP server with TLS and PJSIP WebSocket mode. These settings establish dependencies, not a universal end-to-end encryption result. The browser or desktop client, PBX signaling transport, media negotiation, trunk and remote endpoint can each have a different protection state.

Record the effective listener, certificate name and chain, client connection, WebSocket transport, SDP, negotiated media and external call leg separately. Do not weaken certificate validation to make a hostname mismatch disappear, expose internal port ranges because the guide mentions them, or infer SRTP on every leg from an HTTPS or secure-service login.

Treat desktop and browser as separate access paths

Sangoma's July 15, 2025 announcement describes a browser-based Sangoma Phone with no local application installation and lists Chrome, Edge and Chromium on Windows, macOS and Linux. It also describes a UCP launch path that avoids re-entering host and user credentials. That does not make every desktop requirement, browser feature or session lifetime identical.

Record whether the user launches the installed desktop client, enters the browser client directly, or follows the UCP handoff. Test microphone permission, selected input and output, incoming alert, reconnect, sign-out and session revocation for each approved browser and operating system. A working UCP page is not proof that WebRTC signaling, media or incoming calls work, and a desktop result cannot accept browser autoplay or device-permission behavior.

Version optional features and their subscriptions

The browser announcement lists queue controls, voicemail, call history, contacts, optional chat and voicemail transcription, while stating that transcription on FreePBX/PBXact requires a Scribe monthly-minutes subscription. The desktop administration guide likewise gives features their own module versions and configuration, and some queue functions can require separate licensing. Preserve each feature's PBX module, user permission and subscription boundary instead of writing one capability row for the whole client family.

For a bounded pilot, test sign-in and revocation, inbound and outbound calls, selected caller identity, two-way audio, DTMF, hold, transfer, voicemail, contacts, presence, queues only when authorized, browser and desktop coexistence, certificate renewal, upgrade and rollback. Emergency routing, location and callback remain properties of the complete PBX, trunk, number and jurisdiction path. No client, browser, PBX, account, module, license, certificate, network, device, emergency route, compatibility, availability, price, audio result or live call was inspected or tested for this guide.

Diagnose sign-in before changing SIP or media

When the installed or browser client loops, rejects login or cannot reach the PBX, use the Sangoma Phone connection diagnostic to separate supported build, entitlement, PJSIP owner, user permission, RTAPI reachability, certificate, WSS and session creation.