如果你做过 FreeSWITCH 和业务系统集成，大概率会遇到一个绕不开的问题：ESL 很强大，但业务系统真正接入时，工程复杂度并不低。你需要维护 ESL 长连接，需要处理断线重连，需要从大量底层事件里还原通话状态，还要把 `uuid_kill`、`uuid_transfer`、`uuid_record`、`originate` 等命令再封装成业务接口。等到项目进入 AI 外呼、智能客服、语音机器人这类实时语音场景时，事情会更复杂：呼叫控制、通话状态、音频推流、播放打断、PCM 回灌，往往会分散在多个服务和多层逻辑里。所以我做了一个 FreeSWITCH 原生模块：`mod_fcc`。 它想解决的问题很明确：让业务系统不用直接面对 ESL，而是像调用普通服务接口一样使用 FreeSWITCH 的呼叫能力。
The Core Logic of High-Quality Fine-Tuning Data Engineering: Why Data Quality Defines a Model's Ceiling Chinese version: 中文版 This is the first article
从微调是否必要、SFT/RL/GRPO 的学习方式，到高质量样本为什么比单纯堆数据量更关键.
70B模型配了4张80G卡，长文本一推就爆。查了一圈发现不是显存容量问题，是max_length设太大，kv cache按最坏情况预分配显存。上线前没做profiling，差点多花20万买卡。
设了gradient_accumulation_steps=8，理论有效batch=32，结果每个step的loss降得像火箭一样快，还以为学习率太高。排查了两天才发现DeepSpeed的配置覆盖问题，实际有效batch只有1。
吐槽向复盘：对接新运营商SIP中继时，认证机制、头域格式、号码转换轮流坑了我一遍。记录一下当时的排查思路和最终方案，给后来人避坑。
FreeSWITCH部署在华为防火墙后，公网对端能收到INVITE但ACK总丢，BYE之后通话还不释放。抓包一看，NAT已经改了Contact头，但Via和Record-Route里的IP却和实际出口对不上——防火墙的SIP ALG在改写时序和改写范围上各有一套自己逻辑，禁用它又怕影响对端NAT穿越。最后靠抓包定位ALG的改写盲区，手动在SIP配置里对齐NAT行为，解决问题。
FreeSWITCH对接传统PBX时，一方在NAT后出现单向通话或无声音。排查过程从STUN绑定响应入手，发现对端是对称型NAT导致的非对称路径拒绝。这篇文章复盘完整的排查链：SDP解析→ICE候选交换→STUN Binding→对称型NAT判定→TURN中继回退，重点剖析为什么最终选了TURN而不是其他方案。
容器网络场景下iptables NAT表加载失败的根因不在iptables本身，而在于内核模块依赖链未打通。本文从问题发现到根因定位完整还原排查路径，对比三种方案的生产环境适用条件，并给出具体实施步骤与边界case处理。
