想搭一套 FreeSWITCH 做开发、联调，或者放到一台内网服务器上，往往要先准备依赖、下载源码、编译模块，再处理声音文件和配置目录。业务还没开始接，环境准备就有不少工作。
我把已经编译好的 FreeSWITCH 做成了 Docker 离线部署包，放到了 GitHub 仓库。目的很直接：大家拿到完整包以后，不用在目标服务器从头编译，可以直接进入配置和通话验证。
这篇面向呼叫中心开发、实施和运维人员。按下面的步骤，可以完成镜像导入、容器启动和基础检查。
包里已经放了什么
当前发布包包含 FreeSWITCH 1.10.12-release、mod_fcc 1.2.1-open 和商业授权模块 mod_taering_stream 0.54。常用的 mod_sofia、mod_event_socket、mod_callcenter、mod_conference 等模块，以及提示音和 MOH 等待音乐，也已包含在镜像中。
仓库还列出了 PostgreSQL、MariaDB/MySQL、SQLite、ODBC、Redis 支持，以及用于 MP3 播放等场景的 mod_shout。这些是镜像中的支持能力；Compose 没有替你部署一套外部数据库服务，也没有预先配置你的队列、座席和运营商网关。
做测试环境、交付联调环境，或者给不方便联网编译的服务器部署 FreeSWITCH，可以从这个包开始。需要调整编译选项或加入自己的模块时，仍要另外准备对应镜像。
下载要选对附件
打开 Release 下载页，下载这两个附件：
freeswitch-1.10.12-fcc1.2.1-offline-bundle.tar.gz- 同名的
.tar.gz.sha256校验文件
GitHub 自动生成的 Source code 压缩包不包含镜像。直接克隆仓库也拿不到完整离线镜像，部署时要下载上面的 bundle 附件。
目标机器需要原生 Linux、x86_64/amd64 架构、Docker Engine 和 Docker Compose V2。先检查：
# 确认 CPU 架构，应返回 x86_64。
uname -m
# 检查 Docker 服务与 Compose V2 是否可用。
docker version
docker compose version
当前包不支持 ARM64；start.sh 也会检查 Linux 和 x86_64。Mac 用户应把包传到符合要求的 Linux 服务器上操作。Docker Desktop 某些版本虽然支持可选的 host 网络功能，本项目的启动脚本和交付要求仍以原生 Linux 为准。
Docker 和 Compose 要提前装好。完全离线的服务器需要另外准备 Docker 安装包及依赖，FreeSWITCH 离线包不包含它们。
解压，然后启动
把离线包和校验文件传到 Linux 服务器的 /opt，以下命令使用有 Docker 和目录操作权限的账号执行。先校验，结果应为 OK，校验失败就停止，不继续解压部署。
# 进入存放两个下载附件的目录。
cd /opt
# 按 Release 提供的校验文件核对包内容。
sha256sum -c freeswitch-1.10.12-fcc1.2.1-offline-bundle.tar.gz.sha256
校验通过后执行：
# 解压完整部署包，并进入部署目录。
tar -xzf freeswitch-1.10.12-fcc1.2.1-offline-bundle.tar.gz
cd freeswitch-1.10.12-fcc1.2.1
# 导入包内镜像并创建容器，不在目标机编译。
bash start.sh
脚本会检查运行条件，执行 docker load 导入镜像，在缺少时创建 .env，再通过 Compose 启动服务。镜像名为 local/freeswitch:1.10.12-fcc1.2.1，不需要去 Docker Hub 找同名镜像执行 docker pull。
有一点要特别说明：当前仓库的 start.sh 每次执行都会重新导入包内镜像，并使用 --force-recreate 强制重建容器。已有业务时，这个动作会中断通话，不能把它当成日常查看状态或无影响重启的命令。
怎样确认启动成功
在部署目录执行下面的命令：
# 查看容器状态，以及 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'
按仓库说明，正常时应看到 1.10.12-release，两个模块检查返回 true，初始化完成后容器为 healthy。这是预期检查结果，并非本文在你的服务器上的实测输出。
如果没有达到预期，先看日志：
# 获取最近启动日志，排查权限、端口或 XML 配置错误。
docker compose logs --tail=200 freeswitch
# 查看 SIP profile 是否按预期启动。
docker compose exec -T freeswitch fs_cli -x 'sofia status'
容器运行正常以后，还要通过实际呼入、呼出、双向语音、DTMF 按键、转接、排队和录音检查。healthy 只能作为基础检查，不能替代通话验收。
配置放在哪里，数据怎样保留
首次启动时，缺少 conf/freeswitch.xml 才会从镜像释放完整默认配置。宿主机的 ./conf 映射到容器内 /usr/local/freeswitch/etc/freeswitch。这里的 ./ 相对于 compose.yaml 所在目录，不是固定指向 /opt/conf。
用户、网关、拨号计划、SIP profile 和模块配置都在这个目录中修改。一般 XML 修改后可执行 reloadxml；网关、队列或模块已经加载的配置，可能还需要对应的 rescan/reload。改了监听地址、端口或 TLS 启动参数，应安排维护窗口再重启。
# 重新读取 XML；是否还需模块级重载，取决于改了什么。
docker compose exec -T freeswitch fs_cli -x reloadxml
# 需要重启时使用 Compose；执行前确认现有通话的处理安排。
docker compose restart freeswitch
后续启动会保留已有配置，但仓库说明也列出了对旧默认配置的定向迁移，所以升级前仍应备份并比较配置变化。
数据库目录、日志和录音分别使用 Docker 命名卷保存，容器重建后可以继续使用。docker compose down 通常保留这些卷；不要随手加上 -v，它会删除本项目声明的命名卷。 备份至少覆盖 conf/、.env、数据库卷和需要保留的录音。持久化只能解决容器生命周期问题，仍需要单独做备份。
上线前把网络、密码和授权处理好
项目使用 network_mode: host，直接占用宿主机端口。默认 SIP 为 5060、5080，RTP 为 UDP 16384–32768；Event Socket 为本机 8021，FCC API 为本机 18080。应核对实际配置、防火墙和安全组，不需要再额外添加 Docker 端口映射。
初始化完成后，修改默认分机密码、Event Socket 密码及 ACL，替换 FCC 的默认 API token，清理不用的示例用户和路由，再按实际网络设置 SIP/NAT/RTP。host 网络省去了容器端口映射步骤，公网地址通告和双向媒体仍需要正确配置。
“离线部署”说的是镜像导入与 FreeSWITCH 部署环节。包内 mod_taering_stream 是商业授权模块，仓库说明其首次启动会联网检查授权；pending 表示待授权，不能写成已经可用。Compose 还会只读挂载宿主机 /etc/machine-id，按项目说明用其 SHA-256 作为稳定宿主机标识。完全隔离网络时，应先确认该模块的授权安排。
默认 Compose 没有设置 CPU 和内存上限，需要共享服务器的读者可以通过 .env 调整资源限制，再重建容器应用。具体值按通话、转码和录音测试确定，不拿一个固定配置承诺并发量。
完整安装、迁移和运维命令放在 项目 README。使用时遇到问题，可以在仓库提 Issue，附上宿主机架构、Docker/Compose 版本、操作步骤和脱敏日志；密码、token、号码和录音不要直接贴进去。