Connecting a VoIP gateway to FreeSWITCH is a two-side configuration: the gateway owns the trunks and SIMs, and FreeSWITCH owns the dialplan, with a SIP profile pointing at the gateway as the external trunk. The pairing gives a FreeSWITCH deployment mobile or fixed trunks through a dedicated VoIP gateway, which scales better than direct module attachments and keeps the media path stable.
This guide covers the integration model, the setup steps, the gateway-specific settings, and the troubleshooting path for the FreeSWITCH and gateway pairing.
The Integration Model
The model mirrors the Asterisk case with FreeSWITCH-specific details: FreeSWITCH runs the dialplan and features, the gateway terminates the trunks, and the two connect through a SIP gateway definition in FreeSWITCH's configuration. The gateway appears to FreeSWITCH as one more trunk, and FreeSWITCH appears to the gateway as the phone system.
The separation is the value: gateway SIM and trunk management happen on the gateway, FreeSWITCH upgrades do not touch the trunks, and a gateway reboot does not reset the FreeSWITCH dialplan. Each side is maintained on its own schedule.
The media path benefits too: the gateway negotiates one consistent codec with FreeSWITCH and handles the conversion to the mobile network, so FreeSWITCH's codec configuration stays simple and the audio path is predictable.
The pairing also simplifies scaling: adding a second gateway is a new SIP gateway definition in FreeSWITCH and a dialplan route, not a rebuild, and each gateway carries its own trunks and SIMs. The model that works for one gateway extends to a fleet.
Logging is part of the model: FreeSWITCH logs the dialplan and call setup, the gateway logs trunk and SIM usage, and the two views together diagnose any failure. The operator who reads both logs finds the layer of a problem in minutes.
The Setup Steps
Step 1 prepares the gateway: configure the network, insert the SIMs or connect the trunks, confirm registration, and create the SIP user or trunk that FreeSWITCH will register against. The gateway must be stable before FreeSWITCH is pointed at it.
Step 2 creates the gateway definition in FreeSWITCH: add a SIP gateway with the gateway's address, the credentials, and the codec settings, then reload the configuration so FreeSWITCH registers the trunk.
Step 3 verifies registration: the FreeSWITCH CLI command sofia status shows the registered gateway, and a profile restart or reload confirms the connection. The status view is the first evidence the pairing works.
Step 4 builds the dialplan entries: an outbound rule sends matched destinations to the gateway, and an inbound rule receives calls from it and routes them to extensions or applications. The dialplan is where FreeSWITCH decides what the trunk can do.
Step 5 tests with a call: place an outbound call through the gateway and receive an inbound call, checking audio in both directions. The test call proves registration, routing, and media together.
The setup should include a naming convention: the gateway definition, the trunk label, and the dialplan contexts named by site or market, so a multi-gateway deployment reads clearly. Naming is cheap at setup and saves the diagnosis time later.
Document the versions and the configuration files in the setup record: the FreeSWITCH version, the gateway firmware, and the changed files, because the pairing can break on an upgrade. The record turns a future upgrade failure into a known compatibility question.
FreeSWITCH's failover capabilities complement the gateway: a dialplan that tries a second gateway when the first is unavailable turns a single gateway into a resilient design. The failover rule is a few lines in the dialplan and a real test in the setup sequence.
Gateway-Specific Settings
The codec list is the first setting to align: FreeSWITCH and the gateway should share a common codec at the top of the list, and the negotiated codec should be confirmed on a real call rather than assumed. A mismatch produces failed calls or poor audio while registration looks healthy.
NAT and firewall settings are the second: FreeSWITCH and the gateway need the media path open between them, and one-way audio almost always traces to a NAT or firewall rule on that path. Confirm the RTP ports and the NAT traversal settings on both sides.
The third setting is the registration behavior: how often the gateway and FreeSWITCH refresh registration, what happens on a missed refresh, and how failover to a second trunk is configured. The registration and failover behavior decides how the pairing survives network hiccups.
The registration expiry is a setting worth tuning: a shorter expiry recovers faster from a network hiccup but adds signaling load, while a longer one reduces load and recovers slower. Match the expiry to the network stability, and test the recovery after a reboot.
The codec list should also account for the mobile side: the gateway converts between the SIP codec and the carrier's voice path, so the choice affects what callers hear on mobile destinations. A wide-band codec where supported improves the experience, and a mismatch explains poor audio.
| Setting | Where | What it controls |
|---|---|---|
| Codec list | Both sides | Audio format and quality |
| NAT and ports | Router and firewall | Media path |
| Registration | Gateway and FreeSWITCH | Trunk availability |
| Failover | Dialplan or gateway | Recovery during outages |
The table maps the settings to their effect: each one is a layer of the pairing, and each is verified in the test call sequence.
Troubleshooting
Start with registration: sofia status should show the gateway registered, and if it does not, check the gateway's address, the credentials, and the network path in that order. Registration is the first layer and the first suspect.
Registration is fine but calls fail: check the dialplan route and the gateway's trunk selection, then confirm the codec list matches. The call logs and the gateway's call records show where the failure happens.
Audio problems point to the media path: one-way audio is usually NAT or firewall, and poor audio is usually codec or signal on the gateway's SIM side. The two symptoms lead to different fixes, which is why the diagnosis precedes the change.
The gateway's own call records are the second log: they show which trunk or SIM carried each call and the outcome, which answers whether the failure is in FreeSWITCH or the trunk. Read both logs together, because each side sees half of the call.
After-hours changes are the common silent breaker: a firewall update, a new gateway firmware, or a FreeSWITCH package upgrade can break the pairing while everything looks configured. Re-run the test call after any change, and keep the baseline results to compare.
Telarvo Expert Views
The FreeSWITCH and gateway pairing fails on the same three things as any SIP integration: a codec list that does not match, a firewall that blocks the media path, or a gateway configured after FreeSWITCH instead of before. Prepare the gateway to a known-good state, then point FreeSWITCH at it, and the pairing becomes routine.
— Voice Solutions Engineer, Telarvo Store
Validation note: FreeSWITCH syntax and gateway menus vary by version and model; use the documentation for your versions.
Conclusion
The FreeSWITCH and gateway pairing is a clean separation: FreeSWITCH owns the dialplan, the gateway owns the trunks, and the codec, NAT, registration, and failover settings are aligned and verified with a test call.
Key Takeaways for B2B Buyers
Prepare and verify the gateway first, create the SIP gateway in FreeSWITCH, align the codec list, open the media path, and test outbound and inbound audio with failover.
Questions to Ask Before Committing
Ask which FreeSWITCH versions are tested with the gateway, what the SIP gateway configuration options are, which codecs are supported, and how the supplier documents the integration.
Ask Telarvo Store which VoIP gateway is verified with FreeSWITCH before you build the integration.
FAQs
Do I need a module driver with FreeSWITCH?
No; the gateway appears as a SIP trunk, which is simpler and more stable than direct module handling for production.
Why is my gateway not registered in sofia status?
Check the gateway's address, the credentials, and the network path in that order, then reload the profile.
Which codec should FreeSWITCH use?
Use a codec both sides support, commonly G.711 with a fallback; confirm the negotiated codec on a real call.
What causes one-way audio?
Usually a NAT or firewall rule on the media path between FreeSWITCH and the gateway; check the RTP ports and NAT settings.
Can FreeSWITCH use multiple gateways?
Yes; each gateway is a separate SIP gateway definition, and the dialplan can route by destination or priority across them.
What is the quickest check when calls fail?
Confirm the gateway registers in sofia status, then check the dialplan route and the codec list; registration first, routing second, audio third.