My FreeSWITCH Trunk Says REGED — Why Can I Still Not Make an Outbound Call?
A registered trunk is only one part of an outbound call. Check dialplan matching, gateway choice, number format, CLI permissions, SIP responses and RTP before blaming registration.
FreeSWITCH learning series · Part 8 of 30
A registered trunk is only one part of an outbound call. Check dialplan matching, gateway choice, number format, CLI permissions, SIP responses and RTP before blaming registration.
What this question really means in a working FreeSWITCH system
REGED answers only one narrow question: the registration transaction completed. An outbound call can still fail because no dialplan rule matched, the wrong gateway was used, the provider expects a different called-number format, the CLI is not authorised, the INVITE is rejected, or RTP later fails. Read the first final SIP response to the INVITE before changing gateway credentials that already work.
Start with the mental model
<code>REGED</code> proves that a REGISTER exchange succeeded. An outbound call still needs a matching dialplan rule, a valid bridge string, provider-accepted destination format, permitted caller identity, available capacity and a working media path.
| Symptom | Most useful evidence | Likely area |
|---|---|---|
| Immediate local hangup | Dialplan log | No match / bad bridge |
| Provider 403 | SIP response + account policy | Auth/CLI/destination policy |
| Provider 404/484 | Dialled URI/number | Number format/routing |
| Rings then answers | SIP success | Move to media if audio fails |
| Timeout | Packet path | DNS/routing/firewall/provider reachability |
Work through it from zero
Inspect the actual context and destination_number seen by the channel.
Verify the gateway name and transformed destination are exactly what you intend.
403, 404, 484, 486, 503 and timeouts mean different things; identify which system generated the response.
Provider-side rejection can be caused by unauthorised CLI even when registration is healthy.
If the call answers but audio fails, move to SDP/RTP evidence.
What beginners usually confuse
- Deleting and recreating a working gateway because an outbound route is wrong.
- Changing codecs to solve a SIP 403.
- Ignoring the exact number sent to the provider.
How to know you are actually finished
- Keep a known-good test destination.
- Log sanitized original and normalized destination.
- Confirm provider-required prefixes and CLI before enabling broad campaigns.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: a registered trunk is only one part of an outbound call. 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 Confirm the dialplan matched 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 a registered trunk is only one part of an outbound call. 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 confirm the dialplan matched 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 a registered trunk is only one part of an outbound call, 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 a registered trunk is only one part of an outbound call, 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 My FreeSWITCH Trunk Says Reged Why Can I Still Not Make An Outbound Call 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.