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、OpenSIPS 都是在讲"怎么接通一路电话"。往上走一层:电话接通之后,想让机器听懂人说话(ASR)、让机器开口说话(TTS),媒体流已经在 RTP 上跑了,可谁来告诉引擎"现在开始识别""用这个语法""合成这段 SSML"?这就是 MRCP 干的活。它是什么、v1 和 v2 差在哪、一次识别在协议上到底怎么流转、UniMRCP 是怎么落地的、有哪些典型场景和踩坑点,这里一并说清。

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

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

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

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

FreeSWITCH 那几篇讲的是"怎么接通一路电话",这篇换个角度:当你有成千上万路电话、要做注册、鉴权、路由、限流、防欺诈时,前面挡在最前线的往往是 OpenSIPS。它是什么、怎么编译、一次注册和一次呼叫在脚本里到底怎么流转、代码结构长什么样、有哪些best practice、又有哪些新手必踩的坑——一次讲清。

SIP 看起来像 HTTP，真正用起来却更像一套分布式状态机。本文系统回顾寻址注册、消息、事务、Dialog、SDP Offer/Answer 和重要扩展，再把它放进呼叫中心，拆解 SIP Trunk、SBC、IVR、ACD、转接、录音与典型排障案例。

电话没有消失，而是从呼叫中心唯一的入口变成了 Contact Center 众多渠道中的一个。本文从 SIP、VoIP 和 IVR 出发，拆解 Contact Center 的技术栈、生态、主要厂商、经典应用和公开案例，再讨论 AI 会怎样改造这套系统。