前段时间我整理了一个从零搭建智能呼叫平台的课程列表。课程会从 FreeSWITCH 打通第一通电话开始，后面继续做 FCC 呼叫控制、管理后台、实时音频、ASR、LLM、TTS 和企业知识库。
这里有个问题：如果每个人都从下载源码和编译 FreeSWITCH 开始，课程可能还没进入第一通电话，大家遇到的环境就已经不一样了。
有人卡在 GitHub 下载，有人缺开发库，有人的系统版本不一样，还有人编译完成后才发现课程需要的模块没有带上。逐个问题都能解决，但它们会把学习重点从呼叫流程带到编译排错上。
我已经把后续课程需要的 FreeSWITCH 环境做成了一套 Docker 离线包。后面的教学会统一基于这个镜像继续，先把电话打通，再处理真正与呼叫平台有关的问题。
为什么课程不再从源码编译开始
从源码编译 FreeSWITCH 当然有价值。需要修改核心代码、开发模块或者维护自己的发行版本时，编译过程迟早要掌握。
但这套课程的第一个目标不是培养 FreeSWITCH 编译工程师，而是让有开发基础、暂时不熟悉通信系统的人先得到一套能运行的环境。只要底座一致，后面出现问题时，我们才能更快判断是 SIP 配置、网络、FCC 接口还是业务代码出了问题。
如果每位学员使用不同发行版、不同依赖和不同编译参数，同一个现象很可能对应完全不同的原因。教程里的命令在我的环境里能运行，不代表在所有人的自编译环境中都有相同结果。
Docker 镜像在这里解决的是课程环境一致性。
这套镜像里有什么
当前课程基线包括：
- FreeSWITCH
1.10.12-release - FCC 模块：
mod_fcc 1.2.1-open - 呼叫中心模块：
mod_callcenter mod_sofia、mod_event_socket、mod_conference、mod_fifo、mod_distributor和mod_limit等常用模块- MariaDB/MySQL、PostgreSQL、SQLite、ODBC 和 Redis 支持
mod_shout、CD 音质提示音和 MOH 等待音乐
FreeSWITCH 1.10.12 是上游的正式发布版本，我这里说的是“课程版本”，不是说它是最新版本。课程先固定版本，是为了保证前后章节使用同一套模块、配置和命令。版本需要升级时，我会单独说明变化和迁移方法。
离线包中的镜像已经编译完成。目标服务器不需要重新下载 FreeSWITCH 源码，也不需要安装 Git、CMake、编译器和各类 FreeSWITCH 开发库。
为什么没有上传 Docker Hub
把镜像放到公共仓库，使用者执行一次 docker pull 就能开始，这种方式确实方便。
问题是，课程本来就是为了绕开源码下载和依赖安装造成的网络干扰。如果再把启动条件放到 Docker Hub 的访问速度上，还是可能有人在第一步卡住。
所以当前采用完整离线包交付。包里包含镜像 tar、compose.yaml、.env.example、start.sh 和配置说明。镜像通过 Docker 官方支持的 docker load 导入本机，再由 Compose 启动，不需要从 Docker Hub 拉取 FreeSWITCH 镜像。
离线包仍要通过下载、SCP、SFTP、移动硬盘或内网文件服务器送到目标机器。这样做的区别是：拿到完整文件并核对校验值后，安装过程不再依赖外部镜像仓库是否稳定。
拿到离线包前还要准备什么
当前镜像只支持 Linux x86_64/amd64。建议在原生 Linux 服务器和普通 rootful Docker Engine 上运行。课程部署不以 macOS、Windows Docker Desktop 或 WSL2 作为生产环境。
服务器需要提前具备：
- Docker Engine
- Docker Compose V2，命令形式为
docker compose tar和gzip- 能够执行 Docker 命令的 root 用户或受信任的管理员账号
可以先检查：
uname -m
docker version
docker compose version
tar --version
uname -m 应返回 x86_64。
这里需要说清楚：FreeSWITCH 镜像离线，不等于 Docker Engine 也包含在离线包中。目标服务器还没有 Docker 时，需要按照对应 Linux 发行版安装。如果服务器完全不能联网，就要在同版本的联网机器上提前下载 Docker 的 RPM/DEB 和依赖，或者让系统管理员预装。Docker 官方也将 Compose V2 作为 Linux 上的命令行插件提供。
启动后怎么判断环境可用
离线包解压后，进入目录执行：
./start.sh
脚本会检查 Docker 和 Compose V2。第一次运行时，它会导入包内镜像，创建本地环境文件和配置目录，再执行 docker compose up -d --no-build。镜像已经存在时会跳过重复导入。
容器启动只是第一层检查。还要确认 FreeSWITCH 和课程需要的模块确实已经加载：
docker compose ps
docker compose exec -T freeswitch fs_cli -x status
docker compose exec -T freeswitch fs_cli -x 'module_exists mod_fcc'
docker compose exec -T freeswitch fs_cli -x 'module_exists mod_callcenter'
完成时应该看到容器状态为 healthy，FreeSWITCH 显示 1.10.12-release，两个模块查询都返回 true。这才是后续课程能够继续的基本条件。
第一次启动还会把与镜像版本匹配的默认配置释放到宿主机 conf/ 目录。以后修改 SIP profile、拨号计划、用户、网关、FCC 或 callcenter 配置，内容都会保留在宿主机，不会因为容器重建就自动丢失。
这套镜像没有解决哪些问题
统一镜像可以减少编译和依赖差异，但电话系统还有不少工作不可能被一个容器包掉。
SIP 线路、NAT、公网 IP、RTP 端口和防火墙仍然要按照实际网络设置。Compose 默认使用 network_mode: host，容器会直接使用宿主机网络。Docker 的官方说明也明确指出，host 模式不会给容器分配独立 IP，端口映射参数不会生效。
默认配置只适合初始化和课程验证。准备接入真实线路或部署到生产环境时，至少还要处理这些事情：
- 修改默认用户密码
- 修改 Event Socket 密码并限制 ACL，不向公网开放 8021
- 修改 FCC Token，限制 API 访问来源
- 根据公网、内网和运营商线路设置 SIP、NAT 与 RTP
- 删除不需要的示例用户、网关和拨号计划
- 配置日志、录音、数据库和配置目录备份
- 完成呼入、呼出、转接、排队、录音、MOH、DTMF 和异常恢复测试
- 根据实际并发、CPS、录音和转码压力确定 CPU 与内存配置
能看到容器运行，说明软件进程启动了。它和“呼叫平台可以上线”之间还有一段距离，课程后面会继续把这部分补上。
后面的课程怎么衔接
统一 FreeSWITCH 镜像后，课程会从同一个起点继续：
- 创建测试分机，完成注册和互拨
- 接入测试 SIP 线路，验证真实呼入或外呼
- 通过 FCC 的 HTTP 和 WebSocket 接口控制电话
- 使用 Vue 3 制作最小呼叫管理后台
- 接收电话 PCM，并把后端音频送回通话
- 串起 ASR、LLM 和 TTS，处理打断、超时和异常
- 加入知识库、通话摘要、监控、压测与上线检查
大家后面看到的命令、目录和模块版本都会以这套镜像为准。这样遇到故障时，我们可以先排除“是不是编译少了模块”“是不是依赖版本不同”，把时间放在真正需要理解的呼叫和 AI 语音链路上。
下载和版本更新
关注微信公众号并发送"镜像包"后获取下载地址，以后的教学内容和素材我会持续更新在网盘中，有需要的同学请收藏。
拿到文件后，建议先核对 SHA-256，再解压和导入。以后课程镜像升级时，不要直接覆盖生产配置。应先备份 conf/、数据库和录音，再导入新镜像、切换镜像标签，重新验证版本、模块、SIP profile、FCC 和实际通话。
如果你准备跟着课程搭建 AI 外呼、智能客服、语音机器人或者普通呼叫平台，可以先准备一台 Linux x86_64 服务器，并安装 Docker Engine 与 Compose V2。等离线包下载好后，我们就从打通第一通电话开始。