How Do I Send a FreeSWITCH Call to a SIP Provider, Another PBX or Several Destinations?
Compare user, Sofia and gateway dial strings, then build simultaneous, sequential and failover destinations without turning routing into duplicated dialplan blocks.
FreeSWITCH learning series · Part 12 of 30
Compare user, Sofia and gateway dial strings, then build simultaneous, sequential and failover destinations without turning routing into duplicated dialplan blocks.
What this question really means in a working FreeSWITCH system
FreeSWITCH dial strings express different destinations: a registered directory user, a raw Sofia URI, or a configured gateway. Parallel and sequential strategies then change failure semantics: ‘ring both’ is not the same problem as ‘try carrier A, then carrier B only on selected causes’. In production, decide which SIP failures should trigger failover and which should stop immediately; otherwise a rejected call can unexpectedly spill to another route.
Start with the mental model
FreeSWITCH dial strings describe where and how to create B-legs. <code>user/</code> resolves a directory user, <code>sofia/<profile>/</code> targets a SIP URI directly, and <code>sofia/gateway/<name>/</code> routes through a configured gateway.
| Destination style | Use when | Example concept |
|---|---|---|
user/1001 | Registered directory user | Office extension |
sofia/internal/... | Direct SIP URI via known profile | Peer PBX / explicit endpoint |
sofia/gateway/carrier/... | Configured provider gateway | PSTN destination |
| Multiple legs | Ring/failover policy | Agents, branches, carriers |
Work through it from zero
Use directory-aware user dialing for registered users; direct Sofia URIs for explicit peers; gateways for carrier trunks.
Variables can set caller ID, timeouts and behaviour for one leg without changing the whole call.
Comma-separated or grouped dial strings can create parallel legs; decide what happens when one answers.
Use ordered alternatives only when the business accepts the delay and failure semantics.
Failover logic should distinguish busy, rejection, timeout and network failure rather than blindly trying everything.
What beginners usually confuse
- Mixing provider number normalization into every dial string.
- Failing over on a deliberate 403 policy rejection.
- Sending private caller ID or arbitrary headers to external destinations.
How to know you are actually finished
- Keep destination normalization separate from route selection.
- Define which hangup causes qualify for failover.
- Measure post-dial delay introduced by sequential routes.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: compare user, sofia and gateway dial strings, then build simultaneous, sequential and failover destinations with…. Observe one state change at a time, save the evidence, and only then move to the next layer.
- Capture the exact runtime evidence related to Choose the endpoint type before changing the next layer.
- Keep a known-good test number/endpoint and repeat the same call after each configuration change.
- Record SIP response codes, context/destination decisions and media observations separately; they answer different questions.
- If you cannot explain which file/module owns the behavior, stop and locate that ownership before editing more configuration.
Continue from here
After this article: use the next link that matches the unresolved part of compare user, sofia and gateway dial strings, then build simultaneous, sequential and failover destinations with…. Start the FreeSWITCH learning series · Use the SIP → dialplan → RTP troubleshooting ladder · Continue into real-time AI media streaming
Questions a careful reader usually asks next
Should I change several FreeSWITCH files at once?
Not while learning or troubleshooting. Prove choose the endpoint type first, then change one layer and repeat the same test so you know what caused the new behavior.
Is a successful CLI command enough proof?
No. For compare user, sofia and gateway dial strings, then build simultaneous, sequential and failover destinations with…, confirm the live SIP, dialplan or media behavior that the command was intended to affect. A parser or CLI success only proves the command was accepted, not that the call path now behaves correctly.
Where should business logic live?
For compare user, sofia and gateway dial strings, then build simultaneous, sequential and failover destinations with…, keep low-level signaling/media truth in FreeSWITCH, while customer, campaign and business state stays in the application layer unless the telephony engine genuinely needs it for call execution.
References and further reading
Protocol and configuration facts for How Do I Send A FreeSWITCH Call To A Sip Provider Another Pbx Or Several Destinations are grounded in the current FreeSWITCH Users Manual and, where Asterisk is compared, Asterisk's official documentation. Community tutorials are included only as credited learning aids.
- FreeSWITCH Users Manual — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH Getting Started — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH — SIP Profiles with Sofia — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
Want to see API-driven CRM + Telecom workflows in action? Try the WhatsApp bot or explore the demos.
Comments (0)
Be the first to comment.