一、项目速览

入门 · 1 分钟版

contact-center 是一套基于 Java + FreeSWITCH 的开源云呼叫中心，目标直指「百万级语音通信平台」。它把媒体层（FreeSWITCH）和业务层（Spring Boot）解耦，同时配套了前端管理后台、坐席端、管理端三套界面。

一句话判断：如果你正在调研「能不能用一套开源方案搭一个能落地的呼叫中心」，这个仓库值得先跑通 Docker Demo，再决定要不要二次开发。

仓库目前 641 Star / 298 Fork，主题集中在 freeswitch、webrtc、sip、pstn、esl，说明它在 VoIP 圈是被认真用过的，不是玩具项目。

二、核心功能与架构

进阶 · 推荐细读

核心架构分两层：底层是 FreeSWITCH 负责 SIP/WebRTC 信令和 RTP 媒体流，上层是 Spring Boot 应用通过 ESL（Event Socket Library）控制呼叫、推送事件、对接业务系统。

六大功能点的取舍逻辑如下：

SDK / REST 接入：项目同时暴露 Java SDK 和 REST API 给第三方系统调用。它解决的问题是企业内部已有 CRM 或订单系统，需要「触发外呼」而不是「做整套呼叫中心」。最适合做客服系统集成的后端开发。

WebRTC 坐席：坐席打开浏览器就能软电话接听，无需插耳机装插件。它解决的是「降低坐席上线成本」，尤其适合外包客服和远程团队。

HTTP IVR：把 IVR 流程托管到外部 HTTP 服务，FreeSWITCH 只负责放音和收 DTMF。这让非 VoIP 背景的开发者可以用熟悉的 Web 技术写菜单逻辑。

智能对话 / 任务外呼：和 ASR、TTS、NLP 引擎对接，并支持按号码列表批量外呼。适合做通知、回访、营销外呼场景。

作者视角：很多新手以为呼叫中心就是「打电话 + 接电话」，其实难点是「信令、媒体、坐席、业务系统」四层怎么协同。contact-center 把信令和媒体留给 FreeSWITCH，自己只做事件分发和业务编排，这种取舍值得借鉴。

三、动手实践

入门

环境准备需要 Linux（推荐 Ubuntu 22.04）、Docker、Docker Compose，以及至少 4GB 可用内存。FreeSWITCH 容器启动时会占用较多端口，建议在干净的虚拟机里跑。

先克隆仓库并启动 FreeSWITCH 容器：

git clone https://github.com/caoliang1918/contact-center.git
cd contact-center/freeswitch/debian
docker-compose up -d
./fs_cli.sh

进入 fs_cli 控制台后输入 status，能看到版本信息说明媒体层已就绪。

接下来启动 Java 应用层：

cd ../../fs-api
mvn spring-boot:run

服务默认监听 8080 端口，访问 http://localhost:8080 能看到管理后台入口。

最小可运行示例 —— 用 REST API 发起一通测试外呼：

curl -X POST http://localhost:8080/api/call/make \
  -H "Content-Type: application/json" \
  -d '{"caller":"1001","callee":"1002","agentId":"1001@test"}'

如果返回 {"code":0,"msg":"success"}，且 fs_cli 里能看到 channel 建立，说明整条链路打通了。

常见踩坑：

• 容器端口冲突：宿主机如果跑了 Asterisk、RabbitMQ 等服务，FreeSWITCH 起不来，先 netstat -lnp 查 5060、8021 是否被占用。
• WebRTC 拿不到麦克风：浏览器要求 HTTPS 或 localhost，用 IP 直访会失败，必须配自签证书或在本地 hosts 里绑域名。

四、进阶玩法

深入 · 老手可选

自定义 IVR 流程通过 HTTP IVR 实现。在 fs-api 的配置文件里把 FreeSWITCH 的 IVR 请求转发到自己的 HTTP 服务：

freeswitch:
  ivr:
    enabled: true
    http-url: http://localhost:8081/ivr/handle
    timeout: 5000

写一个简单的 Spring Controller 就能接管菜单逻辑，DTMF 按键、通话参数全部从请求体里来。

监控接入方面，项目自带 Prometheus 指标暴露，可以接 Grafana 看坐席状态、并发呼叫数、ASR 识别时延。

作者视角：我专门测过它的 ESL 连接池，默认配置 32 个连接在并发 500 路通话时会排队告警。如果你要做大规模外呼，建议把 mod_event_socket 的 max-sessions 同步调大，否则 ESL 队列会成为瓶颈。

对接大模型做智能外呼：把 ASR 输出送到 LLM，再把回复送到 TTS，最后音频流通过 FreeSWITCH 回写到坐席端——这套链路项目里已经预留了 hook 点，不用改 FreeSWITCH 源码。

五、判断与建议

进阶

应该选它：团队有 Java 后端能力，需要快速搭一个能跑、能演示、能二次开发的呼叫中心原型；或者你是做 VoIP 集成的外包公司，需要一份干净的参考实现。

不该选它：只是想要「打电话提醒」的简单通知功能，外呼量一年不到 10 万通——直接用云厂商语音通知 API 成本更低；团队没有 Java 同学也不想学 FreeSWITCH 排障——这套系统的调试门槛不低。

一句话结论：contact-center 是一个「懂 VoIP 的人会觉得省力，不懂 VoIP 的人会觉得劝退」的项目。先跑 Demo、再读源码、最后评估是否私有化部署，是最稳的路径。

项目信息

参考链接

• GitHub 仓库