FreeSWITCH Is Running — How Do I Create My First Extension and Register a Softphone?
Create a first FreeSWITCH user, configure a softphone, reload XML, confirm registration in fs_cli, and test a simple extension-to-extension call.
FreeSWITCH learning series · Part 4 of 30
Create a first FreeSWITCH user, configure a softphone, reload XML, confirm registration in fs_cli, and test a simple extension-to-extension call.
What this question really means in a working FreeSWITCH system
A successful REGISTER proves authentication and reachability, not that extension-to-extension calling is correct. FreeSWITCH still has to place the authenticated call into the expected context, match a destination in the dialplan, create a B-leg, negotiate media and keep RTP flowing. That is why the first useful test is not the green registration icon in a softphone: it is a two-way call between two known endpoints with audio in both directions.
Start with the mental model
A SIP extension needs an identity in the FreeSWITCH directory, a profile that can receive its REGISTER, a domain/realm that matches the authentication exchange, and a dialplan context that allows the calls you expect after registration.
| Softphone field | FreeSWITCH concept | Typical symptom if wrong |
|---|---|---|
| Username | Directory user ID | 401/403 or repeated auth challenge |
| Password | Directory password param | Authentication failure |
| Domain/realm | Configured SIP domain | User not found / auth mismatch |
| Server/port | Sofia profile listener | No response / timeout |
| Transport | UDP/TCP/TLS supported by profile | Connection or handshake failure |
Work through it from zero
Start with one directory user such as 1001 and a strong test password. Avoid copying the default shared demo password into production.
Make the softphone realm/domain match the FreeSWITCH domain used for authentication.
The user_context determines where authenticated calls enter the dialplan.
Use reloadxml, then confirm the new directory data is visible to the running switch.
Configure server, username, password and transport; then verify the contact in FreeSWITCH.
Registration is not the finish line. A call proves directory lookup, dialplan, bridge and media together.
What beginners usually confuse
- Confusing “user exists in XML” with “phone is registered”.
- Testing only from localhost and assuming NAT is solved.
- Giving the user a public dialplan context with overly broad routes.
How to know you are actually finished
- Use unique credentials per extension.
- Verify contact address and expiry.
- Place a test call in both directions.
- Record the exact context reached by the call.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: create a first freeswitch user, configure a softphone, reload xml, confirm registration in fs_cli, and test a si…. 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 Create one user 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 create a first freeswitch user, configure a softphone, reload xml, confirm registration in fs_cli, and test a si…. 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 create one user 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 create a first freeswitch user, configure a softphone, reload xml, confirm registration in fs_cli, and test a si…, 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 create a first freeswitch user, configure a softphone, reload xml, confirm registration in fs_cli, and test a si…, 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 FreeSWITCH Is Running How Do I Create My First Extension And Register A Softphone 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.
- Omid Mohajerani — FreeSWITCH learning notes — 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.