I have released the complete mod_fcc 1.2.1-open project on GitHub, including the source, installer, configuration, API reference, and tests. Because it exposes HTTP and WebSocket interfaces, one question comes up quickly: is FCC supposed to replace ESL?
No. It cannot replace ESL, either.
ESL is one of the important ways to understand and control FreeSWITCH. Its event coverage, commands, and flexibility go far beyond the small interface layer FCC provides. I built FCC to address an earlier problem: can someone who is still new to FreeSWITCH see a business idea work before learning every underlying concept?
My goal is to offer a shorter validation path. Can a number be called? Can an inbound call be captured? Can the application observe an answer, receive DTMF, and complete a hangup or transfer? Once there is a visible result, the person can decide whether the idea deserves more time and deeper FreeSWITCH knowledge.
Many People Get Stuck Before the First Call
Someone may want to test voice notifications, customer callbacks, a small agent tool, or a basic call workflow. Opening the FreeSWITCH documentation immediately introduces channel UUIDs, event subscriptions, command syntax, dialplans, gateways, user registration, and ESL connections.
Those subjects are worth learning. The timing is the problem.
When the business idea has not been validated, asking a newcomer to learn the whole control model makes failures hard to separate. Is the route wrong? Is the endpoint unregistered? Is the gateway unavailable? Did the application miss an event? Or does the proposed workflow simply not make sense?
The learning problem and the business problem become one large obstacle. Some ideas will never deserve a production system, yet they still incur production-level learning costs before showing any result.
FCC temporarily separates the two questions. It lets an application use a small set of JSON interfaces to validate common actions while FreeSWITCH remains underneath. Complexity has not disappeared. It arrives later, after there is evidence that the work should continue.
What FCC Lets You Validate
FCC packages common call actions as HTTP and WebSocket interfaces. An application can begin with a stable call_id instead of constructing FreeSWITCH commands from the first day.
The current release can be used to validate:
- outbound calls, inbound registration, and call-state queries;
- answer, pre-answer, hangup, DTMF, hold, and unhold;
- file playback, stopping media, transfer, and bridge actions;
- concurrent call-state updates over one WebSocket connection;
- basic agent creation, sign-in, sign-out, pause, resume, and queue queries;
- health checks, active-call counts, and basic operational metrics.
The technical list is less important than the questions behind it. Did the call connect? Did the application learn that it was answered? Was the keypad input received? Does pausing an agent change the expected workflow? Can a reconnecting application continue from recent events?
FCC helps answer these questions earlier.
It does not implement audio streaming, recording, conferencing, or a complete PBX. Queues still belong to FreeSWITCH mod_callcenter, and routing still depends on the dialplan, registered users, or gateways in the target environment. A JSON interface does not make those responsibilities disappear.
What You Gain by Completing One Working Flow
The immediate benefit is a visible result.
A small application that starts a call, displays its state, and hangs it up gives product, development, and operations people something concrete to discuss. The meaning of “connected,” “failed,” or “finished” can be checked against a real flow. Missing states, retry rules, and permission requirements become easier to identify.
The prototype also reveals where the real difficulty sits. The blocker may be SIP registration, number routing, trunk behavior, or an application assumption. That is more useful than treating every failure as a programming problem.
A negative result is useful too. Validation is not meant to prove the original idea correct. It is meant to produce feedback before a team commits to a full system. FCC can lower this early threshold. It does not remove the production work around security, monitoring, capacity, recovery, and maintenance.
Who Should Try FCC First
FCC may be a good starting point for a developer who is new to FreeSWITCH and wants to complete one call-control loop. It can also help:
- a developer testing a voice-product idea;
- a product or technical lead checking whether a call workflow is feasible;
- a small project that already has FreeSWITCH but little ESL experience in the application team;
- someone with limited programming experience who can use AI tools, inspect results, and learn basic deployment.
FCC should not be the main control layer when the project requires the full FreeSWITCH event surface, real-time media processing, cross-node state, or extensive customization. It is a limited set of common controls, not a second implementation of FreeSWITCH.
There is also an operational requirement. FCC is a native C module, so the environment must allow third-party modules to be built and loaded. A user still needs an isolated FreeSWITCH system, a test extension or gateway, and basic Linux skills. This is not currently a product that works by opening a hosted web page.
You Can Ask AI to Build the First Small Application
There is a practical option for people who do not want to begin by writing code. Give an AI coding tool the FCC README, API reference, or GitHub repository and ask it to generate a very small starter application.
Do not ask for “a complete call center platform.” A large request encourages the tool to fill missing details with plausible-looking code. Start with one screen that checks health, starts one test call, displays state, and hangs up.
This prompt is a useful starting point:
Read the README and docs/API.md in https://github.com/Taering365/mod_fcc.
Build a Vue 3 starter application for an isolated test environment only.
The application must:
- configure the FCC API address and Bearer Token locally without hard-coding the token;
- call the health endpoint and show connection status;
- accept caller and callee values and create one test call;
- display the returned call_id and update call state over WebSocket;
- provide a hangup button;
- wrap critical operations in try/catch and log errors and state transitions locally;
- install all frontend dependencies locally and load no external CDN resources;
- show the directory structure, startup commands, and manual verification steps before generating code;
- use only interfaces that are documented by FCC.
Label the result as a validation build that must not be deployed to production.
AI can help with the empty project, the first connection, and the first UI. It does not know the trunk, dialplan, network policy, or authorization model in your environment. Every generated interface and state must be checked against the FCC documentation.
Never send production tokens, SIP passwords, customer numbers, recordings, or internal addresses to an external AI service. Use isolated test values. Code review, security testing, and real call regression are still required before any deployment.
Learn ESL After the Business Flow Works
If the starter application proves that the workflow is useful, I recommend pausing and learning ESL from the beginning.
At that point, there is a reason to learn it. Instead of browsing unfamiliar commands without context, you can study the FreeSWITCH event model, command execution, channel relationships, and failure handling with a real problem in mind.
A production system will eventually need capabilities that FCC does not expose. It may require more events, recovery across module reloads and service restarts, stronger authorization, capacity planning, richer observability, or a control action that is better executed through ESL. Understanding ESL is what allows a team to decide when the FCC layer is sufficient, when to extend it, and when to bypass it.
FCC is not a shortcut that removes the need to learn FreeSWITCH. It moves the first feedback earlier so deeper learning and engineering effort can be spent on a direction that has already shown value.
Code, Documentation, and Feedback
mod_fcc 1.2.1-open is available with bilingual READMEs, a complete API reference, an integration guide, installer, sample configuration, and tests:
- GitHub: Taering365/mod_fcc
- API reference: docs/API.md
- Integration guide: docs/FUNCTION_GUIDE.md
If you find a problem, open an Issue with a reproducible description. Include the FreeSWITCH version, installation prefix, route mode, the call flow being tested, and sanitized logs. Do not post tokens, SIP passwords, real customer numbers, or internal addresses in a public repository.
If you are still deciding whether FCC fits the idea, write down the call flow before discussing a complete platform. One question is enough to begin: what is the smallest business loop that must work?