I Want “Dial 1000 and Ring Extension 1001” — How Do I Write My First FreeSWITCH Dialplan?
Build the smallest useful FreeSWITCH dialplan, match a destination, bridge to a registered user, reload safely, and verify the call from fs_cli.
FreeSWITCH learning series · Part 10 of 30
Build the smallest useful FreeSWITCH dialplan, match a destination, bridge to a registered user, reload safely, and verify the call from fs_cli.
What this question really means in a working FreeSWITCH system
Start with one exact destination and one bridge. Avoid regex, time conditions, databases and carrier trunks until the call works. Once the minimal route is proven, introduce one variable at a time. This gives a known-good baseline: if replacing 1001 with a gateway dial string breaks the call, the failure is now isolated to the trunk side instead of the entire dialplan.
Start with the mental model
Your first dialplan should prove one thing only: a known destination matches one condition and bridges to one known endpoint. Complexity should be earned after that baseline call works.
| Test stage | Expected result | If it fails |
|---|---|---|
| XML reload | No parse error | Fix syntax first |
| Dial 1000 | Rule is evaluated | Check context/destination |
| Bridge | B-leg created | Check user/contact/dial string |
| Answer | Both legs connected | Check signaling/hangup cause |
| Audio | Both directions heard | Check RTP/codec/NAT |
Work through it from zero
Use the same context assigned to the registered user you will test from.
Match ^1000$ or another exact test destination before introducing ranges.
Use a directory-aware user dial string when calling a registered user.
Run reloadxml, call the number, and watch the console.
A ringing phone is not yet a successful end-to-end test.
Once local calling works, bridge through a gateway and compare what changes.
What beginners usually confuse
- Starting with a generic <code>.*</code> expression.
- Testing against a carrier before local extension-to-extension calling works.
- Adding transfer, recording and API calls before proving the basic bridge.
How to know you are actually finished
- Keep the minimal rule as a diagnostic reference.
- Comment business intent near non-obvious regex.
- Use controlled reloads and validate before production changes.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: build the smallest useful freeswitch dialplan, match a destination, bridge to a registered user, reload safely,…. 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 source context 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 build the smallest useful freeswitch dialplan, match a destination, bridge to a registered user, reload safely,…. 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 source context 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 build the smallest useful freeswitch dialplan, match a destination, bridge to a registered user, reload safely,…, 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 build the smallest useful freeswitch dialplan, match a destination, bridge to a registered user, reload safely,…, 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 I Want Dial 1000 And Ring Extension 1001 How Do I Write My First FreeSWITCH Dialplan 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 — CLI and API command reference — additional primary/official reference for context and verification.
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.