FreeSWITCH + ProSBC: SIP Trunking Configuration

FreeSWITCH is one of the strongest open-source platforms in the voice ecosystem. It terminates SIP, anchors media, transcodes codecs, runs full dialplans, plays prompts, mixes conferences, records calls, and exposes the Event Socket Library (ESL) for external control of every live session. Teams who run FreeSWITCH at scale do so because no other open-source media engine matches what it can do once a call is on the box.

What FreeSWITCH is not, however, is a session border controller. It does not ship with the security posture, the per-leg encryption discipline, the multi-carrier routing intelligence, or the call-authentication tooling that a real SBC brings to the edge. Deployments that put FreeSWITCH directly on the public internet inherit a long list of jobs the platform was never designed to do, and operators eventually rebuild those jobs by stitching together iptables rules, fail2ban scripts, and Lua glue. The cleaner architecture is to put a Session Border Controller (SBC) in front of FreeSWITCH and let each layer do its own job.

This article covers what ProSBC adds in front of FreeSWITCH, when FreeSWITCH’s built-in mod_sofia is enough on its own, the FreeSWITCH-specific SIP behavior an SBC has to handle, and the high-level configuration approach for a production deployment.

FreeSWITCH at the Edge vs FreeSWITCH Behind an SBC

The most common reason teams reach for this configuration is that they started with FreeSWITCH directly on the public internet and ran into the limits of that pattern. FreeSWITCH on the edge is functional; thousands of small deployments run that way. The trouble starts at scale, in regulated jurisdictions, or anywhere the call-quality and security expectations match what carrier networks demand from their interconnect points.

A FreeSWITCH instance at the edge is the entire application server, the entire media engine, and the entire security boundary in one process. A registration scan, an INVITE flood, or malformed SIP traffic that generates parser errors or excessive processing load all hit the same kernel that is anchoring live calls and executing live dialplans. The platform was never designed to absorb hostile traffic gracefully; it was designed to serve calls that have already been accepted.

The same pattern appears on the interop side. FreeSWITCH’s mod_sofia negotiates SIP and SDP cleanly against carriers that behave well, and falls back to per-gateway parameters when they do not. The collection of those parameters grows over time as you add carriers, and each one becomes a load-bearing piece of operational knowledge. An SBC moves that complexity out of the application server into a device whose job is exactly to normalize between SIP dialects, and gives FreeSWITCH a single, consistent upstream to talk to.

The rest of this article is about deploying ProSBC as a true B2BUA SBC between FreeSWITCH and the PSTN. Where FreeSWITCH is the right tool (media anchoring, IVR, conferencing, recording, ESL-driven call control), it stays where it belongs, on the LAN side of the SBC, doing what it does best.

What ProSBC Adds in Front of FreeSWITCH

FreeSWITCH has its own SIP stack and its own media stack. Codec negotiation, NAT-aware Contact handling, basic registration management, and per-gateway parameters all live inside mod_sofia. For a single-carrier, low-volume deployment with a cooperative provider, that is enough. ProSBC becomes necessary when the requirements outside mod_sofia‘s comfort zone exceed what the FreeSWITCH platform was designed to absorb.

Multi-carrier routing and failover as a first-class concern

FreeSWITCH can dial out through multiple gateways, but routing logic, OPTIONS-driven liveness checks, and failover behavior end up scattered across dialplan, Lua scripts, and ESL event handlers. ProSBC consolidates routing into a rule-based engine with priority-ordered routes, SIP OPTIONS health checks per NAP, and reason-cause mapping that route-advances on the response codes that should retry and stops calls on the codes that should not. FreeSWITCH sees one upstream and offloads carrier diversity to the SBC entirely.

Security at the public-internet boundary

A FreeSWITCH server with a public IP and an open SIP port is one of the most heavily scanned classes of endpoint on the internet. SIP registration scanning, INVITE floods, and toll-fraud probes hit any internet-reachable SIP endpoint within hours of going live. ProSBC absorbs that traffic at the edge with SIP-aware rate limiting per source IP and per method, automatic SIP DoS and registration scan mitigation, dynamic blacklisting with greylisting for graduated response, and per-call fraud scoring before the call ever reaches FreeSWITCH.

SIP normalization across carriers and regions

Carriers vary in what they accept, what they expect, and what they silently rewrite. P-headers carry information one side requires and the other rejects; Contact and From formats differ; codec offer order varies; session timers behave differently between vendors. ProSBC’s SIP header manipulation engine normalizes the carrier-facing leg per NAP without changing how FreeSWITCH constructs its own outbound SIP. The dialplan stays clean; the per-carrier eccentricities live at the SBC.

STIR/SHAKEN, CNAM, and call authentication

For FreeSWITCH deployments terminating in North America, the FCC’s caller-ID authentication rules continue to tighten and the upstream carriers continue to push attestation decisions down to their wholesale customers. Attestation control, signing-service integration, and bypass policy for outages all belong at the SBC layer, not inside the application server. ProSBC integrates with STIR/SHAKEN signing services such as TransNexus ClearIP and Neustar over SIP, with redundancy handled through route ordering and response-based failover logic. CNAM dips and LNP lookups attach to the same routing engine.

When FreeSWITCH’s mod_sofia Is Enough vs When It Is Not

FreeSWITCH is a perfectly capable SIP endpoint inside its design assumptions. The split-thread architecture handles concurrency well, the codec engine is mature, and per-gateway parameters cover most carrier quirks one at a time. The deciding factor is whether your environment fits inside what mod_sofia was built for or has outgrown it.

Scenario	FreeSWITCH alone	FreeSWITCH with ProSBC
Single cooperative carrier, low call volume, internal users only	Sufficient	Optional
Multi-carrier failover or least-cost routing across regions	Dialplan-heavy	Recommended
Carrier with a non-standard SIP dialect or strict normalization rules	Per-gateway hacks	Recommended
STIR/SHAKEN attestation control, per-call signing	Not the right layer	Required
Public-internet exposure with high scan and fraud risk	DIY iptables + fail2ban	Required
Service provider running FreeSWITCH as a multi-tenant platform	Per-tenant instances	Per-tenant NAPs on one SBC

The pattern across the table is consistent. FreeSWITCH handles the inside of your voice platform; the SBC handles the boundary. As soon as the boundary develops requirements that exceed a single cooperative trunk, the SBC takes over those duties so FreeSWITCH can keep doing what it does well. For a broader discussion of where FreeSWITCH fits in the open-source landscape alongside Kamailio and OpenSIPS, see our companion article on choosing a SIP platform.

FreeSWITCH-Specific SIP Behavior the SBC Has to Handle

The integration logic for FreeSWITCH is the same as for any soft switch, with a handful of platform-specific behaviors worth calling out. Each of these lives in mod_sofia or the FreeSWITCH dialplan and shows up as something the SBC has to recognize on the FreeSWITCH-facing leg. Get these right and the rest of the configuration falls into place.

SIP profiles, gateways, and how they map to ProSBC NAPs

FreeSWITCH organizes its SIP world into profiles (an internal profile and an external profile by default), each listening on its own port with its own codec list, transport, and gateway entries. The cleanest pattern with ProSBC in front is to treat the SBC as a single gateway on the external profile, with the FreeSWITCH-side authentication choice (REGISTER vs IP-based) decided by what suits your operational model. On the ProSBC side, that same connection becomes a single NAP pointing at the FreeSWITCH server’s internal address, with carrier-facing NAPs handled independently. Every carrier-specific quirk lives on a carrier NAP, never on the FreeSWITCH NAP.

Codec preference and the transcoding question

FreeSWITCH offers codecs according to outbound-codec-prefs, then negotiates the final media set based on the answer received from the far side. When the carrier supports a different codec set, or prefers a different order, the SBC normalizes the offer per the carrier’s expectation. For PSTN-bound traffic that is usually G.711 µ-law or A-law in first position, with the SBC stripping non-PSTN offers like G.722 or Opus that the carrier will not negotiate. If a call actually needs codec conversion at the edge (Opus on the FreeSWITCH side, G.711 on the carrier side, or AMR-WB inbound from a mobile carrier), hardware transcoding moves that load off the FreeSWITCH server, where it would otherwise compete with media anchoring and conference mixing on the same CPU.

Contact, Via, and Record-Route rewriting

FreeSWITCH places its own external IP or hostname in Contact and Via headers, with NDLB-force-rport and related NDLB-* (No Default Loopback Behavior) flags adjusting how strictly mod_sofia honors the source port and address on responses. The SBC commonly rewrites Contact, Via, and routing-related headers according to topology-hiding policy before forwarding outbound, and reverse the rewrite on the way back in so FreeSWITCH sees an address it can route to. Topology hiding at the SBC handles this transparently, keeping the carrier from ever seeing FreeSWITCH’s internal addressing and preventing route failures caused by private addresses leaking out.

T.38 fax handover and the mid-call re-INVITE

FreeSWITCH supports T.38 through mod_spandsp, with T.38 gateway mode bridging T.38 on one leg to G.711 passthrough on the other. The whole pattern depends on a mid-call re-INVITE that swaps the audio stream for a T.38 stream once fax tones are detected. Some carriers accept the re-INVITE cleanly; others reject it, time out, or strip the SDP attributes that make T.38 work. The SBC handles per-NAP behavior here: T.38 relay where the carrier accepts T.38, G.711 passthrough with a fax-safe profile (echo cancellation off, static jitter buffer, VAD disabled) where it does not, and clean SDP rewriting in either direction. The full mechanics of how T.38 negotiates and where it commonly fails are covered in our Fax over IP (T.38) reference.

REFER, attended transfer, and the bridge alternative

FreeSWITCH implements call transfers either through SIP REFER (when initiated by an endpoint that sends one) or through the dialplan’s bridge mechanism, which keeps the call leg on FreeSWITCH and originates a new one. Carriers vary on whether they honor REFER. The SBC has two correct behaviors: pass REFER through if the carrier supports it, or replace REFER with a re-INVITE inside the SBC so the carrier never sees REFER at all. Configure this per NAP based on what each upstream carrier accepts, and FreeSWITCH never has to know which carrier is on the other side.

Session timers and silent call drops

FreeSWITCH uses SIP session timers (RFC 4028) when configured to (enable-timer, session-timeout), and ignores them otherwise. The SBC has to negotiate compatible timer values on each leg, refreshing toward FreeSWITCH on its expected cadence and toward the carrier on whatever the carrier requires. Mismatched timers cause silent call drops mid-conversation, which read as random and intermittent in FreeSWITCH logs because the failure is happening one hop away. Setting timers consistently on the SBC removes that class of bug entirely.

Configuration Approach: FreeSWITCH, SBC, Carrier

Specific menus differ between SBC vendors, but the integration logic is the same on any B2BUA SBC. The goal is two clean trunk groups (one toward FreeSWITCH, one toward each carrier) with the SBC bridging them and handling every transformation in between. The FreeSWITCH side of the configuration is intentionally simple; the SBC absorbs everything that would otherwise live in per-gateway parameters across mod_sofia.

1. Plan the topology before touching configurationDecide where ProSBC sits: in the same cloud VPC as FreeSWITCH, on a separate VM in the same data center, or in a dedicated cloud region in front of an on-prem FreeSWITCH cluster. Confirm public-IP addressing, DNS, and TLS certificate provisioning for ProSBC. The FreeSWITCH server keeps its existing LAN addressing; ProSBC takes the public role and ESL traffic continues to terminate on the LAN side of FreeSWITCH where it has always lived.
2. Configure the FreeSWITCH-facing NAP on ProSBCCreate one NAP pointing at the FreeSWITCH server’s internal address. Match the transport mod_sofia is configured for on its external profile (UDP, TCP, or TLS) on the agreed port. Decide whether FreeSWITCH authenticates by IP or by REGISTER credentials, and configure the NAP accordingly. Keep this NAP simple — header rules, codec policies, and security tweaks belong on the carrier-side NAPs.
3. Configure each carrier-facing NAP on ProSBCCreate one NAP per upstream carrier. Set transport, codec list, header rules, and authentication mode to whatever the carrier’s integration guide specifies. If the carrier provides redundant signaling IPs, group them under one NAP with primary and secondary route ordering and a SIP OPTIONS heartbeat configured for liveness detection.
4. Add header manipulation rules per legStrip P-headers and proprietary fields the carrier will not accept on outbound traffic from FreeSWITCH. Rewrite Contact and Via with ProSBC’s public address. Normalize From and PAI to match the carrier’s expected format for STIR/SHAKEN attestation. None of this requires changing FreeSWITCH’s own configuration.
5. Configure routing rules between NAPsDefine inbound rules from each carrier to the FreeSWITCH NAP, and outbound rules from the FreeSWITCH NAP to the appropriate carrier based on destination prefix, time of day, or any other criterion. Add fallback rules for carrier outages, so a call denied on the primary route advances to the secondary. Reason-cause mapping handles which response codes should retry and which should stop the call.
6. Layer in security and call authenticationEnable DoS/DDoS protection and SIP registration scanning protection on the carrier-facing trunks. Configure dynamic blacklisting and toll-fraud scoring. For US-bound traffic, wire up STIR/SHAKEN signing through your chosen STI-AS provider, with primary and secondary routes for the signing service itself and a reason-cause map that route-advances on 404 and stops calls on 603 per the production SIP integration pattern.
7. Reconfigure FreeSWITCH to talk to ProSBC instead of carriers directlyIn FreeSWITCH, edit the relevant gateway entries in conf/sip_profiles/external/ so each one points at ProSBC instead of the carrier. The gateway-level codec preferences and proxy settings simplify substantially because the SBC absorbs everything carrier-specific. Reload mod_sofia or rescan the affected profile rather than restarting FreeSWITCH if you can avoid the disruption.
8. Test in both directions and under failoverPlace inbound and outbound test calls. Verify caller ID presentation, codec negotiation, DTMF (RFC 2833 / RFC 4733), transfer handling, and fax delivery if used. Then deliberately break the primary carrier’s signaling reachability and confirm ProSBC moves traffic to the secondary route on the schedule SIP OPTIONS dictates. Watch FreeSWITCH’s sofia.status and sofia.profile.external.status output during the failover to confirm the FreeSWITCH side stays steady throughout.

What to Look for in an SBC for FreeSWITCH

The qualifying features for a FreeSWITCH-friendly SBC are the features that make any SBC good at multi-vendor interop, with a few additional considerations specific to running in front of an open-source application server. Treat the following as a checklist when evaluating options.

B2BUA architecture, not a SIP proxy

A SIP proxy cannot do this job. Rewriting Contact and Via, replacing REFER with re-INVITE, converting RTP to SRTP, and signing outbound calls with STIR/SHAKEN all require the SBC to terminate and re-originate each dialog independently. A B2BUA architecture is the baseline requirement.

Programmable routing that meets FreeSWITCH on its own terms

FreeSWITCH operators tend to expect programmability, because that is what the platform itself offers through ESL, Lua, and the dialplan. An SBC paired with FreeSWITCH should offer a comparable level of control on its own side. ProSBC’s Ruby routing API exposes the full call context to external scripts at three filter stages (before_filter, after_filter, after_remap_filter), with pre-built modules for STIR/SHAKEN signing, TransNexus ClearIP, SecureLogix, YouMail, and Neustar. The integration model is designed for the same kind of operator who already manages dialplan and ESL code on the FreeSWITCH side.

Per-NAP TLS, SRTP, and header rules

Look for an SBC where every NAP carries its own transport setting, its own codec list, and its own header manipulation profile. That is what lets one carrier sit on UDP/5060 with G.711 while another sits on TLS/5061 with SRTP, while FreeSWITCH behind both gets a consistent presentation regardless of which carrier handled the call.

Open STIR/SHAKEN partner integration

STIR/SHAKEN at the SBC should not lock you to one signing service. ProSBC integrates with TransNexus ClearIP and Neustar over SIP today, and with any STI-AS provider that exposes an HTTPS API where required. Attestation is decided per call inside the routing engine rather than per trunk as a static setting, which is what the FCC’s own-certificate rule assumes when a single platform handles mixed-tenant traffic.

Deployment flexibility that matches FreeSWITCH’s flexibility

FreeSWITCH runs on Linux on essentially anything. The SBC should run wherever your topology actually puts the edge: AWS, Azure, VMware, KVM/Proxmox, or bare metal. A cloud-native SBC co-located with a cloud-hosted FreeSWITCH minimizes latency between the two; a virtualized SBC on the same hypervisor as an on-prem FreeSWITCH keeps the entire voice stack on customer-owned infrastructure.

Self-serve evaluation

The single best way to confirm an SBC handles FreeSWITCH cleanly is to put traffic through it. A free, self-serve evaluation license lets you stand the SBC up next to a test FreeSWITCH instance and validate every behavior listed above before committing.

Security at the FreeSWITCH Edge

FreeSWITCH has its own protections, including ACL-based filtering and mod_sofia-level rate limits. The SBC complements those with layered defenses operating before traffic reaches FreeSWITCH at all, which is the correct architectural position for SIP-layer protection. Anything FreeSWITCH never has to look at is CPU it does not have to spend deciding what to do with it.

SIP registration scanning protection

The most common attack against a public-internet FreeSWITCH server is a slow REGISTER flood probing for valid extensions or weak passwords. ProSBC detects scan patterns by frequency and source distribution, blocks the source automatically, and never forwards the probe to FreeSWITCH. Greylisting with percentage-based response lets the SBC investigate suspicious sources gradually instead of blocking and unblocking them in alternating cycles.

DoS and DDoS mitigation

Volumetric INVITE floods and OPTIONS floods that would consume FreeSWITCH’s connection pool are throttled at the SBC layer first. SIP-aware rate limiting per source IP, per trunk group, and per SIP method drops bad traffic before it consumes FreeSWITCH’s call-handling capacity.

Toll fraud detection on the carrier-facing leg

International premium-rate dialing is the single largest billing-exposure risk on any SIP endpoint. ProSBC applies a per-call risk score considering destination prefix, call rate, time of day, and pattern history, and either blocks the call or routes it for review before it leaves the carrier-facing trunk. Integration with validated fraud-detection partners like TransNexus and YouMail attaches to the same routing engine.

Topology hiding for the FreeSWITCH server itself

ProSBC’s public IP is the only address the carrier ever sees. FreeSWITCH’s internal hostname, its private address, the structure of the LAN behind it, and any ESL-connected back-end systems all stay invisible from the carrier side. That reduces the attack surface to one well-defended boundary instead of the application server itself.

Frequently Asked Questions

Conclusion

FreeSWITCH is a capable open-source platform inside its design assumptions. With a single cooperative carrier and a contained environment, it does not need anything in front of it. Past that point, the integration questions stack up: carrier diversity, custom SIP profiles, regulated-industry attestation, public-internet exposure, multi-tenant service delivery. Every one of those questions answers cleanly with an SBC at the edge.

The decisive features when evaluating an SBC for FreeSWITCH are B2BUA architecture for full header control, per-NAP transport and codec policy, programmable routing that meets FreeSWITCH operators on their own terms, an open STIR/SHAKEN partner model, and self-serve evaluation so you can confirm the integration works before signing anything. Get those right and the SBC quietly does its job for years while FreeSWITCH continues to do what it does well.