C/C++ 服务线上偶发崩溃、跑几天内存涨上去、core dump 栈全是问号——这类内存问题最磨人，因为它"现在不报，等你忘了才报"。AddressSanitizer（ASan）是把这类 bug 从"偶发玄学"变成"当场报错并打出调用栈"的照妖镜：编译时加一个 flag，运行时越界、use-after-free、double-free、泄漏当场抛报告。这篇用 FreeSWITCH 这种大型 C 服务做例子，从加编译参数、跑出报告、到读懂报告，给一套能直接照抄的流程，也讲清楚它为什么不能带着上生产。

网络会出的岔子一长串——分区、脑裂、闪断、非对称路由、DNS 故障、丢包、抖动、拥塞、时钟漂移——它们全归结为 CAP 里那个躲不掉的 P，所以真正的选择题只在 C 和 A 之间。网络交易选 C，音视频会议和实时通信选 A。本文先按类把网络问题列全，再结合我最近踩的几次坑，重点讲 AP + 最终一致性在实时通信里怎么落地：媒体面为什么天生 AP、信令面的冲突怎么和解、以及什么东西绝对不能最终一致。

很多人以为异地双活的音视频服务，难在 FreeSWITCH 怎么集群。其实 FreeSWITCH 这层信令早有成熟的无状态做法，真正的坑在两处：一是跨机房的 MySQL 怎么同时写不打架，二是活跃通话的会话和媒体流钉死在单机房、切不过去。这篇讲清这三层各自的一致性模型，为什么信令可以 AP、计费必须 CP、媒体只能就近锚定，以及一套能落地的分层方案。

Lua 自己什么都不会——不会发网络请求，不会读数据库，连打开一个文件都得靠宿主给的库。它小得可怜，却长在魔兽世界、Nginx、Redis、FreeSWITCH 这些庞然大物里，靠的就是一件事：跟 C 无缝对接，借用整个 C/C++ 生态。这篇讲清楚 C 和 Lua 到底是怎么绑在一起的——从那个来回倒数据的栈，到注册 C 函数、包装 C 对象，再落到两种真实风格：FreeSWITCH 用 SWIG 预生成胶水，OpenResty 用 LuaJIT FFI 干脆不写胶水。代码引用来自 FreeSWITCH master 分支与 LuaJIT 官方文档。

AI 语音客服 demo 能跑,离敢上生产还隔着两道坎。一是延迟:用户对电话里的沉默极其敏感,超过一秒就觉得"卡了",得盯"首响应"而不是"总时长",靠流式和流水线把它压进一秒。二是可信度:LLM 会用完全自信的语气编造一个不存在的优惠、报错一个余额数字,在客服场景就是事故,得靠 RAG、工具调用、护栏这五道防线给它套缰绳。而且这两件事经常打架,工程上只有按场景权衡,没有免费的午餐。

FreeSWITCH + UniMRCP + LLM 的分工和架构有了,落到代码,XML dialplan 表达不了"调 HTTP、维护多轮上下文、按 LLM 结果分支"这种逻辑,得用 Lua。这里有一份能读懂的完整 voice_agent.lua 骨架——从接通、放欢迎语、开麦识别、调 LLM 网关、合成回复,到打断、超时、转人工、挂断的完整对话循环,关键处标清楚哪里要按你的环境改。顺带说清 mod_unimrcp 的 speak / play_and_detect_speech 怎么用,以及为什么 LLM 场景要用自由识别而不是固定语法。

MRCP 给通话加上了"听懂"和"会说"。再往下走一步:在 contact center 里,FreeSWITCH 管呼叫、UniMRCP 管 ASR/TTS,本来已经能做语音 IVR;但真正让它"活"起来的,是中间插进来的 LLM。传统 IVR 靠固定语法只能听懂预设的几句话,LLM 能听懂客户随口说的任何一句,还能带着上下文对答、调用工具查真实数据。三者怎么分工、一次对话在时序上怎么流转、延迟和打断这些工程难点怎么处理,连同一份能照着做的落地清单,都在这儿。

读 FreeSWITCH 的 C 源码，层层封装，又臭又长，看完就忘。与其在源码里硬熬，不如用 Jupyter Notebook 造一个可运行、可视化的最小模型，把线程、阻塞、时序这些"看不见"的东西画出来。本文讲这套方法背后的认知原理、Jupyter Lab 的安装与用法、可视化手段清单，并以一个 audio_bridge_thread 的交互式 Notebook 为例。

FreeSWITCH 是一台优秀的媒体/B2BUA 引擎，但它没有原生集群能力，信令和媒体又和业务逻辑挤在同一个进程里。想把它扩到上万路，硬堆 FreeSWITCH 是最贵的一条路。这篇讲清 FreeSWITCH 架构的精华与包袱各在哪，为什么 OpenSIPS 和 rtpengine 恰好补在它最薄的两个地方——信令边缘和媒体传输——以及三件套怎么分工、容量能提到什么量级。

FreeSWITCH 的 session 是整个系统最核心的抽象——它是一路呼叫的容器，也是它的边界。这篇顺着源码，把一次呼叫从 SIP INVITE 进来、到 session 创建、媒体协商、桥接、挂断销毁的完整生命周期讲清楚：哪些数据是线程私有、哪些是共享，session 为什么和内存池、线程死死绑在一起，以及为什么"把会话从服务器 A 迁到服务器 B"这条路基本走不通——真要做会话漂移，让客户端 endpoint 重连新服务器，比在服务端桥接靠谱得多。

FreeSWITCH 用 switch_core 内核加模块插件的方式把一整套电话系统塞进一个进程，既不拆成微服务，也不是简单的单进程多线程。这篇从源码层面讲清它的状态边界划在哪、这种结构为什么快、又为什么脆，以及为什么这套二十年前为语音打磨的架构，做不成今天意义上的高性能 SFU。

十几年前我做过一个《A Glance of Lua》的分享，如今大半忘光了。这篇先用老程序员重拾旧语言的角度，把 Lua 最该记住的那几样东西——表即一切、元表、闭包、协程、C API——快速过一遍；再落到 FreeSWITCH：mod_lua 到底把脚本挂在哪几个位置（dialplan、XML handler、event hook、startup script），配一组能看懂的例子、几条最佳实践和最容易栽的坑。Lua 语法基于 5.x，FreeSWITCH 部分引用官方 scripting 文档。

很多人把 FreeSWITCH 的拨号计划当成一个"路由配置文件"，改完 reloadxml 就完事。可它其实是一台按呼叫上下文运行的状态机：一通电话进来，它一条条判断条件、往 channel 上贴变量、排一串要执行的动作，最后决定这通电话走哪条路。理解了这一点，IVR、排队、转接、录音这些呼叫中心功能才不再是黑盒。本文以 XML 拨号计划为主，配少量 Lua，讲清它是什么、能干什么、怎么写、有哪些最佳实践和常见坑，最后用几个真实呼叫中心场景演示排障技巧。

上一篇讲清了 SIP.js 怎么打进 FreeSWITCH,这次把它做成了一个完整项目——webrtc-to-freeswitch。这篇从整体架构、信令与媒体的完整流程、协议分层三个层面把它讲透:它是什么、有什么用、怎么用;浏览器到 FreeSWITCH 之间一次通话到底发生了什么;以及最容易被忽略、却最容易踩坑的 FreeSWITCH 侧配置——WSS binding、candidate ACL、ext-rtp-ip。

SIP.js 官方 demo 一键就能打通电话，但那是因为对端是一台匿名公共服务器。想让浏览器真正打进自己的 FreeSWITCH，绕不开三件 demo 帮你藏起来的事：注册、鉴权、还有一座 WSS 到 SIP 的桥。这篇拆掉 demo-1，把这三件事补齐。

给 FreeSWITCH 写测试有两条路：一条是自带的 FST 框架，起一个真 core、真 session，在进程内测 switch_* 函数；另一条是拉起整个服务、用 SIPp 打真呼叫、看 ESL 事件的集成测试。本文用我修的一个 mod_dialplan_xml use-after-free bug（PR #3151）串起前者，再讲清后者什么时候非用不可、怎么搭、坑在哪，最后给一张"这个 bug 该写哪种测试"的决策表和检查清单。

C 没有反射，凭什么能用字符串 "answer" 找到一个函数？把 FreeSWITCH 的模块系统从 dlopen 拆到函数指针派发，四层结构讲透：动态加载、依赖注入、服务注册、运行时查找。所有结论都在 FreeSWITCH 1.11.3-dev 上实测过，包括亲手写一个 50 行模块热加载进跑着的进程，以及三个实测出来的坑。

APR（Apache Portable Runtime）是 C 语言事实上的"缺失标准库"，它的核心是内存池——不追踪每个对象的释放，而是按生命周期批量丢弃。这篇讲清 APR 的设计理念、常用模块、快速上手路径、以及 FreeSWITCH 为什么要把它 fork 出来改名。所有代码在 APR 1.7.6 上实测。