FusionPBX with an SBC: Setup and Best Practices

FusionPBX is the web GUI most service providers reach for when they want a FreeSWITCH-based multi-tenant PBX they can manage from a browser. One PostgreSQL database, one FreeSWITCH cluster, and a domain abstraction that lets a single deployment serve dozens or hundreds of tenants. That design is what makes FusionPBX popular with MSPs, ITSPs, ILECs, and CLECs running hosted PBX as a service. It is also what makes the SBC question different from every other PBX integration article on this site.

Most PBX-plus-SBC pieces start with “your PBX cannot terminate SIP dialogs cleanly on its own.” FusionPBX does not have that problem. FreeSWITCH already operates as a back-to-back user agent on every call, terminating the inbound dialog on one sofia profile and originating a new dialog on another. The question for FusionPBX operators is sharper: if FreeSWITCH already does what a Session Border Controller (SBC) does at the SIP-dialog level, why add another B2BUA at the edge?

This article answers that question, walks through the FusionPBX-specific SIP behaviors an SBC has to handle at the edge, covers the multi-tenant integration pattern that makes FusionPBX deployments interesting at scale, and lays out the configuration approach for putting an SBC in front of a production FusionPBX cluster.

FreeSWITCH Already Terminates SIP. Why Add an SBC?

This is the question that separates the FusionPBX integration story from the FreePBX or 3CX one, and it deserves a direct answer.

FreeSWITCH is a B2BUA. On every call, the sofia module accepts the inbound INVITE on one profile, runs the call through the dialplan, and originates a new INVITE to the bridged destination on another profile. The Call-ID, From-tag, and Contact on the outbound leg are independent from the inbound leg. Re-INVITEs, transfers, and media negotiation are handled per leg. At the SIP-dialog level, FreeSWITCH is doing what a B2BUA SBC does.

What FreeSWITCH does not do, by design, is carry the operational concerns that live at the boundary between a voice network and the public internet. Five concerns, specifically.

SIP-layer security at carrier-grade rate

Edge defense runs at a different layer than FreeSWITCH’s sofia parser is built for. The sofia stack will accept a SIP message, parse it, and run it against domain auth before rejecting it. At hundreds of malformed messages per second from a coordinated scanner, the parser becomes the bottleneck. An SBC’s SIP-aware DoS and DDoS protection drops malformed and out-of-policy traffic at the edge, with per-method, per-source, and per-trunk-group rate limits, before sofia ever sees the message.

STIR/SHAKEN signing service integration

Call signing does not exist in FreeSWITCH or FusionPBX natively. There is no module that calls TransNexus ClearIP or Neustar, builds a PASSporT, attaches the Identity header, and falls back through a reason-cause map when the signing service is unreachable. North American carriers terminating without a verified Identity header increasingly downgrade attestation, and the STIR/SHAKEN signing flow is an SBC-layer concern.

Per-carrier SIP normalization across many upstream providers

Carrier-specific quirks scale poorly inside FreeSWITCH gateways. A FusionPBX deployment routing to four carriers ends up with four gateway definitions, each with its own outbound dial-string overrides, ACL exceptions, header tweaks done through pre-call channel variables, and dialplan conditions that test the carrier branch. An SBC’s SIP header manipulation engine handles per-leg normalization in a single place with rules that can be edited without touching the dialplan.

Topology hiding and consistent identity policy

Edge presentation belongs at the edge. FreeSWITCH advertises its bind address in Contact and Via headers by default, and the standard workarounds (sip-ip, ext-sip-ip, and per-gateway extra-headers in sofia) work but distribute the policy across multiple XML fragments. An SBC enforces topology hiding consistently for every outbound call regardless of which tenant or which gateway originated it.

Fraud scoring before a call burns minutes

Per-call risk scoring is the FusionPBX MSP’s most expensive missing layer. A compromised extension in any tenant on the cluster can burn six figures of premium-rate minutes in a weekend. FreeSWITCH can apply per-domain limits and outbound rate caps, but real-time scoring against a provider like TransNexus, SecureLogix, or YouMail is API integration the SBC layer does, not the PBX layer.

The pattern is consistent across all five concerns. FusionPBX and FreeSWITCH are excellent at being a multi-tenant call-control engine. The SBC takes responsibility for the edge concerns the call-control engine was never built to own.

Multi-Tenant by Design: FusionPBX Domains and the SBC Boundary

The FusionPBX domain model is what makes the SBC integration genuinely different from a single-tenant PBX deployment. Every tenant in FusionPBX is a domain (for example, customer-a.pbx.msp.example, customer-b.pbx.msp.example, and so on), and every extension, gateway, dialplan, IVR, and voicemail box lives inside one of those domains. The same FreeSWITCH process serves all of them, with domain context applied per call through mod_xml_curl lookups against PostgreSQL.

That model creates two SBC integration patterns, depending on how the MSP wants to handle carrier relationships.

Per-tenant carrier mapping suits MSPs where each tenant brings its own carrier, its own DIDs, and sometimes its own STIR/SHAKEN attestation policy. The SBC has one NAP per tenant on the internal side and one NAP per tenant carrier on the upstream side. Routing rules on the SBC map the tenant’s DID range to its specific upstream carrier. Tenant isolation is enforced at the SBC layer, not only inside FusionPBX, which matters when a tenant’s carrier credentials must never reach another tenant’s traffic.

Shared-wholesale carrier mapping covers MSPs aggregating traffic onto one or two wholesale carriers with their own DID inventory. The SBC has one NAP per tenant on the internal side, but only one or two NAPs on the upstream side regardless of tenant count. Routing rules map any tenant’s outbound to the wholesale carrier, with tenant identity carried through P-Asserted-Identity or a custom header for billing reconciliation. STIR/SHAKEN attestation is applied uniformly by the MSP as the originating service provider.

Both patterns work, and large MSPs typically run a mix of both. What both depend on is per-tenant NAP isolation at the SBC. A single SBC at the edge with hundreds of NAPs (one per tenant on the FusionPBX side, plus carrier NAPs) collapses what would otherwise be hundreds of individually exposed FusionPBX endpoints into one controlled boundary. The SBC for MSPs reference covers the multi-tenant architecture in depth.

FusionPBX-Specific SIP Behaviors the SBC Has to Handle

FusionPBX is the GUI. FreeSWITCH is the SIP engine. The SBC peers with FreeSWITCH’s sofia module, and a handful of sofia behaviors shape what the integration looks like in practice.

Sofia profile binding and the internal/external split

FusionPBX defaults to two sofia profiles. The internal profile handles extension registrations (typically on UDP/5060 of an internal address). The external profile handles trunks (typically on UDP/5080 of the same address, or on a separate interface). The SBC connects to the external profile, not the internal one. This is the first place new integrations get tripped up: the SBC sends INVITEs at the FusionPBX server’s IP on port 5060, FusionPBX expects them on 5080 on the external profile, and the call fails before any dialplan logic runs. Confirm the external profile bind port and configure the SBC’s FusionPBX-facing NAP to match.

Gateway authentication and contact-in-ping

For outbound calls, FusionPBX routes through a gateway defined in the external profile. The gateway tells sofia where to send the INVITE, what credentials (if any) to authenticate with, and which transport to use. When the SBC is the upstream peer instead of a carrier, the gateway points at the SBC and authentication is usually IP-based on the SBC side. The sofia option contact-in-ping controls whether the gateway’s Contact header is included in OPTIONS pings; some SBC configurations want it, others reject it as malformed. Set the value to match what the SBC expects.

mod_xml_curl, dialplan latency, and SBC failover behavior

mod_xml_curl is what makes FusionPBX’s GUI changes go live without a FreeSWITCH reload. Every inbound call triggers an HTTP lookup back to the FusionPBX web server to resolve dialplan, directory, and configuration. Under normal load this is invisible. Under PostgreSQL pressure or web server contention, the lookup latency rises, and inbound INVITEs to FreeSWITCH start arriving faster than the dialplan can be resolved. The SBC’s role here is to enforce session timers and call setup deadlines on its side independently of FreeSWITCH, so a slow dialplan lookup does not propagate as a carrier-visible timeout. Per-NAP outbound retry policy on the SBC absorbs the variance.

Dialplan-driven header manipulation vs. SBC-driven normalization

FusionPBX dialplans can set channel variables and add headers to outbound calls (sip_h_X-Custom, effective_caller_id_name, and so on). Done carefully, this works. Done across many tenants and many carriers, it becomes a maintenance problem: every new carrier integration requires dialplan edits in multiple places, and every change requires regression testing across tenants. Moving the normalization to the SBC layer through per-NAP header manipulation rules consolidates the work in one place and keeps the FusionPBX dialplan focused on tenant-specific call logic. The SBC does the carrier-specific work uniformly across tenants.

REGISTER forwarding and the SBC’s edge role for hosted phones

Some MSP deployments terminate SIP phone registrations directly on FusionPBX over the public internet. That works, and FreeSWITCH handles registration well, but it places the FusionPBX server on the public internet exposed to registration scanning. The cleaner pattern is to have the SBC accept registrations at the edge, forward them to FusionPBX via its registration-forwarding feature, and apply SIP registration scanning protection before any scanning traffic ever reaches FusionPBX. The trade-off is that the SBC needs to scale registration forwarding to the full phone count, not only the active-call count.

Codec negotiation and transcoding

FreeSWITCH transcodes between G.711 µ-law, A-law, GSM, G.722, and L16 natively. Opus is supported natively in modern builds. G.729 and AMR are licensed codecs that require additional modules in FreeSWITCH and, depending on call volume, may exceed CPU capacity on the same host as FusionPBX. The SBC’s per-leg codec policy decides what the carrier sees and what the FusionPBX side sees independently. When the carrier wants G.711 only and the tenant uses Opus for WebRTC clients, transcoding can run on the SBC’s hardware transcoding option instead of consuming FusionPBX CPU.

Configuration Approach: FusionPBX, SBC, Carrier

Specific menus differ between SBC vendors and between FusionPBX versions, but the integration logic is the same on any B2BUA SBC fronting a multi-tenant FusionPBX cluster.

1. Plan the topology and tenant model before touching configuration. Decide whether each tenant brings its own carrier or whether the MSP aggregates onto wholesale carriers. The tenant model determines how many NAPs you need on the SBC and how routing rules will look. FusionPBX moves to a private interface (or a private cloud subnet); the SBC takes the public role.
2. Configure the FusionPBX-facing NAP(s) on the SBC. Create one NAP per FusionPBX tenant, or one NAP for the whole FusionPBX cluster if all tenants share a wholesale carrier. Point each NAP at FusionPBX’s external sofia profile (typically UDP/5080 or TLS/5081), not the internal profile. Confirm the bind port matches.
3. Configure each carrier-facing NAP on the SBC. Create one NAP per upstream carrier with the transport, codec list, header rules, and authentication mode the carrier’s integration guide specifies. Use the carrier-published values, not FreeSWITCH defaults.
4. Add header manipulation rules per leg. Strip P-headers the carrier rejects, rewrite Contact and Via for topology hiding, normalize From and PAI for STIR/SHAKEN attestation compatibility on outbound, and enforce SIP message size limits where the carrier requires them.
5. Configure routing rules between NAPs. Inbound from each carrier to the right FusionPBX tenant NAP based on DID range. Outbound from each FusionPBX tenant NAP to the appropriate carrier with priority and fallback so the SBC moves traffic when a carrier stops responding.
6. Add tenant identity preservation. When the SBC aggregates many tenants onto one wholesale carrier, the tenant identity (for billing, attestation, recording) is carried through P-Asserted-Identity, a custom header, or the From header. Configure the SBC to populate it from the tenant NAP context.
7. Layer in security and call authentication. Enable DoS and DDoS protection, registration scanning protection if the SBC is forwarding registrations to FusionPBX, dynamic blacklisting, toll-fraud scoring, and STIR/SHAKEN signing on the carrier leg.
8. Reconfigure FusionPBX gateways to point at the SBC. In the FusionPBX GUI under Advanced → Gateways, edit each carrier-facing gateway so the proxy and registrar (if used) point at the SBC’s internal address instead of the carrier’s public address. Extensions, dialplans, IVRs, and voicemail are unaffected. Reload mod_sofia for the external profile.
9. Test inbound, outbound, and tenant isolation under failover. Place test calls from each tenant. Verify caller ID, DTMF, codec negotiation, transfer handling, and voicemail. Break the primary carrier’s signaling and confirm the SBC fails over without dropping live calls. Confirm a call placed from tenant A never lands in tenant B’s domain context on the FusionPBX side.

Security at the FusionPBX Edge

FreeSWITCH includes IP-based ACLs, per-domain auth, and rate limiting on the sofia stack. Those work, and most production FusionPBX deployments run them. The SBC complements them with layered defenses that operate before traffic reaches FreeSWITCH at all, which is the right architectural position for SIP-layer protection across many tenants on one cluster.

• SIP registration scanning protection detects scan patterns at the edge, blocks the source automatically, and never forwards the probe to FreeSWITCH. This matters most when the SBC is the registration forwarder for hosted phones.
• DoS and DDoS mitigation applies SIP-aware rate limiting per source IP, per tenant NAP, and per SIP method. Sofia’s parser does not see the attack at all when the SBC is in front.
• Toll fraud detection scores each call against destination prefix, call rate, time of day, and pattern history. In a multi-tenant FusionPBX deployment, one compromised extension in any tenant is enough to burn premium-rate minutes overnight; per-call risk scoring catches the pattern before FreeSWITCH allocates a channel.
• Topology hiding keeps the SBC’s public IP as the only address the carrier ever sees, regardless of which FreeSWITCH host or which domain originated the call.
• Dynamic blacklisting and greylisting automate the response to detected abuse without manual intervention.

The full SBC security model covers the layered defense pattern in depth.

STIR/SHAKEN for FusionPBX MSPs

For FusionPBX deployments terminating in North America, the STIR/SHAKEN question shapes how the MSP is positioned with its upstream carriers and, increasingly, what answer rates each tenant sees on outbound calls.

FreeSWITCH and FusionPBX do not sign calls. There is no native module for PASSporT construction, no STI-AS query path, and no Identity header injection in the sofia stack. Signing happens at the SBC layer or upstream at the carrier.

For MSPs that hold their own SPC token and want full attestation control, the SBC handles signing per call. Attestation level is decided per call, not per tenant, because a single FusionPBX cluster typically carries mixed traffic: A-level for direct retail tenants where KYC is verified, B-level for resold numbers, and C-level for any tenant whose calling party cannot be authenticated. The STIR/SHAKEN A-level attestation reference covers what is required to maintain A-level as the upstream policy environment tightens.

For MSPs that let an upstream wholesale carrier sign on their behalf, the SBC’s job is to populate the SIP identity headers accurately so the carrier has correct information to base attestation on. Stripping or rewriting P-Asserted-Identity at the SBC will silently degrade attestation outcomes.

In either pattern, the SBC integrates with signing services like TransNexus ClearIP and Neustar through the SBC’s routing engine, not through anything inside FusionPBX. Implementation specifics are in the STIR/SHAKEN SBC implementation guide.

Frequently Asked Questions

Conclusion

FusionPBX is one of the better choices on the market for a multi-tenant, FreeSWITCH-based hosted PBX. Its strengths are the domain model, the GUI on top of FreeSWITCH’s call-control engine, and the operational economics of running many tenants on one infrastructure footprint. Its limitations show up at the boundary between that infrastructure and the public internet: signaling-layer security, STIR/SHAKEN signing, per-carrier normalization at scale, and per-call fraud scoring all live at a layer FusionPBX was not designed to own. The SBC is what takes responsibility for those concerns without changing how FusionPBX handles tenants and calls internally.

The decisive features when evaluating an SBC for a FusionPBX deployment are B2BUA architecture for full header and encryption control on each leg, per-NAP transport and codec policy so each tenant and each carrier gets the right profile, an open STIR/SHAKEN partner model so the signing-service choice stays the MSP’s, tenant-scale NAP capacity so one SBC can front the whole FusionPBX cluster, and self-serve evaluation so you can confirm the integration against your actual deployment before signing anything.