不想再写 ESL 网关？我做了一个 FreeSWITCH 原生呼叫控制模块：mod_fcc

如果你做过 FreeSWITCH 和业务系统集成，大概率会遇到一个绕不开的问题：ESL 很强大，但业务系统真正接入时，工程复杂度并不低。

你需要维护 ESL 长连接，需要处理断线重连，需要从大量底层事件里还原通话状态，还要把 uuid_kill、uuid_transfer、uuid_record、originate 等命令再封装成业务接口。等到项目进入 AI 外呼、智能客服、语音机器人这类实时语音场景时，事情会更复杂：呼叫控制、通话状态、音频推流、播放打断、PCM 回灌，往往会分散在多个服务和多层逻辑里。

所以我做了一个 FreeSWITCH 原生模块：mod_fcc。

它想解决的问题很明确：让业务系统不用直接面对 ESL，而是像调用普通服务接口一样使用 FreeSWITCH 的呼叫能力。

mod_fcc 是什么

mod_fcc 是一个面向 FreeSWITCH 的原生呼叫控制与实时音频流模块，交付形态是 mod_fcc.so。

它直接运行在 FreeSWITCH 内部，并向业务系统暴露 HTTP / WebSocket API。业务后端可以通过这些接口完成外呼、挂断、保持、转接、桥接、录音、DTMF、状态事件接收、电话音频推流和 PCM 音频回灌。

传统链路通常是：

业务系统 -> ESL 客户端/网关 -> ESL 事件/命令 -> FreeSWITCH

使用 mod_fcc 后，链路可以变成：

业务系统 -> HTTP/WebSocket API -> mod_fcc -> FreeSWITCH

这不是否定 ESL。ESL 依然是 FreeSWITCH 非常强大的底层控制方式。mod_fcc 的定位，是为常见呼叫中心和 AI 语音场景提供一个更高层、更稳定、更容易接入的 API 边界。

它的优势在哪里

1. 业务系统不再直接维护 ESL 长连接

在很多项目里，业务团队真正想做的是外呼、接听状态、挂断、录音、转接、播放和语音交互，而不是维护 ESL 连接池、事件解析器和命令封装层。

mod_fcc 把这些通用控制能力收敛到 FreeSWITCH 模块内部，业务系统只需要调用 HTTP 或 WebSocket API。

这对团队协作很重要。电话底层能力归电话模块，业务系统专注业务流程。

2. 更适合 AI 外呼和实时语音场景

AI 外呼、语音机器人、智能 IVR 这类系统，核心不是简单打一通电话，而是要实时拿到电话音频，把音频送给后端做 VAD、ASR、LLM、TTS，再把合成后的 PCM 音频注入当前通话。

mod_fcc 支持实时双向 PCM 音频流：

电话用户 -> mod_fcc -> 客户音频/智能后端
客户音频/智能后端 -> mod_fcc -> 电话用户

也就是说，mod_fcc 负责电话侧的呼叫控制和媒体传输，客户后端负责智能对话、业务策略、质检、合规和数据分析。

这个分层会更清晰，也更容易扩展。

3. 呼叫控制、状态事件、音频链路统一在一个模块里

传统集成里，经常会出现几个模块各管一部分：

• ESL 服务负责呼叫控制。
• 业务服务维护通话状态。
• 另一个音频服务处理媒体流。
• 播放、打断、录音、DTMF 又分散在不同逻辑里。

mod_fcc 希望把常见呼叫中心能力统一成一组清晰接口：

• 创建外呼
• 挂断
• 保持 / 取消保持
• 转接
• 桥接
• 录音开始 / 停止
• 发送 DTMF
• 文件播放
• 清空播放队列
• 播放打断
• 通话状态查询
• 通话事件推送
• PCM 音频注入
• WebSocket 双向音频流

业务系统面对的是业务 API，而不是底层 FreeSWITCH 命令组合。

4. 保留 FreeSWITCH 原有路由能力

mod_fcc 并不强行替代 FreeSWITCH 原有的 dialplan 和 gateway 体系。

它支持 dialplan 路由，也支持 direct gateway 路由。你可以继续让 FreeSWITCH dialplan 负责运营商路由，也可以让应用层通过接口指定更直接的呼叫方式。

这对已有 FreeSWITCH 系统迁移比较友好，不需要一上来推翻原有配置。

为什么要用它

如果你的系统只是偶尔调用 FreeSWITCH，直接用 ESL 当然可以。

但如果你的项目已经进入这些场景，就会很适合考虑 mod_fcc：

• 你在做 AI 外呼。
• 你在做语音机器人。
• 你在做智能客服或智能 IVR。
• 你需要实时获取电话音频。
• 你需要把 TTS/合成音频实时回灌到通话里。
• 你不想在业务系统里维护一整套 ESL 网关。
• 你希望呼叫控制接口更接近普通 HTTP/WebSocket 服务。
• 你希望电话能力和 AI 后端解耦。

一句话总结：mod_fcc 是为了减少 FreeSWITCH 和业务系统之间的工程复杂度。

推荐架构

我更推荐这样的架构：

客户业务后端 | 创建呼叫、控制呼叫、接收状态事件
  v
mod_fcc inside FreeSWITCH | 发起外呼、管理通话、推送电话 PCM
  v
客户音频/智能后端 | VAD / ASR / LLM / TTS / 业务逻辑
  v
mod_fcc | 将返回的 PCM 注入实时通话
  v
电话用户

这样拆分后，各层职责会比较清楚：

mod_fcc 负责 FreeSWITCH、呼叫控制、通话事件、音频推流和 PCM 回灌。

客户后端负责 ASR、LLM、TTS、话术策略、业务流程、质检、合规和数据分析。

电话能力和智能能力分开，系统边界更清楚，后续替换 ASR、TTS 或 LLM 供应商也更容易。

当前状态

目前 mod_fcc 已经接近第一个公开版本的功能完成状态，适合作为 FreeSWITCH 呼叫中心和 AI 语音集成方案的基础模块继续验证。

项目地址

GitHub：

https://github.com/Taering365/mod_fcc

如果你正在做 FreeSWITCH、呼叫中心、AI 外呼、语音机器人、智能 IVR，或者正在维护一套越来越复杂的 ESL 网关，可以关注一下这个项目。

也欢迎交流实际场景，我会根据真实使用反馈继续完善模块能力和文档。