我自己经手过好几套呼叫中心智能语音项目，对FreeSWITCH接ASR/TTS这件事算是有比较完整的落地经验。经常有同行问我：项目里用的FreeSWITCH到底怎么才能跟讯飞的语音能力打通？标题这串东西看着长，拆开其实是一条固定的技术链路——FreeSWITCH负责呼叫控制和媒体转发，MRCP协议负责让FreeSWITCH跟语音引擎说话，讯飞ASR负责把用户语音转成文字，讯飞TTS负责把机器人的回复变成语音，最后再加一个对话系统来承接业务逻辑。这套东西组合起来，就是一个完整的智能外呼/语音机器人/智能IVR项目。
这篇文章我就拿我近期的一个实际项目为背景，把整套对接过程从方案选型、环境部署、配置实现到问题排查全部过一遍。内容偏向工程实操，不会去扯太多理论，但每个关键选择我都会说清楚为什么这么干。正好在搭这套系统，或者准备接讯飞语音能力但还没理清思路的同学，可以直接照这篇文章当参考。
1. 项目需求与整体方案设计
1.1 这个标题背后到底要解决什么问题
“FreeSwitch采用mrcp协议对接科大讯飞asr和tts以及对话系统”，这句话看着就是一个技术组合，但实际产品需求通常是这样的：用户打进来一个电话，FreeSWITCH接起来之后播放一段欢迎语，然后用户说话，系统把语音转成文字，再交给对话系统理解用户意图，生成应答文本，最后再由语音合成播报给用户。整个流程还要支持多轮对话，要能随时打断，要能识别静音超时。
在这个流程里，FreeSWITCH的角色不是那个最聪明的部分，但是最核心的“水管工”。它要把通话双方的媒体流管理好，把音频从一个端口转到另一个端口，同时又要把MRCP客户端和RTP媒体流的对接做好。讯飞ASR/TTS的能力再强，如果FreeSWITCH这一层没有把媒体流转发对，后面全部白搭。
所以项目实际要解决三件事：一是通话媒体链路怎么建立，二是语音识别和合成的请求怎么发出去，三是识别结果怎么送到对话系统、对话系统的回复怎么拿回来。MRCP协议解决的是第二件事，FreeSWITCH的diplan和API解决的是第一和第三件事。
1.2 为什么选择MRCP而不是直接调讯飞SDK
我最早接触这个需求的时候，第一反应也是能不能直接调讯飞开放平台的SDK，毕竟讯飞MSC SDK在移动端和嵌入式项目里用得非常多，大多数开发者对它也更熟悉。但放在FreeSWITCH这个场景里，直接调SDK是很别扭的，原因有三个。
第一，FreeSWITCH的媒体流是RTP包，SDK接收的是PCM音频流，中间必须有人把RTP解出来、去抖动、做回声消除、做VAD静音检测，这些工作全部自己做一遍成本太高。第二，FreeSWITCH本身是事件驱动的并发模型，一个呼叫处理涉及很多回调，如果在主流程里直接嵌入闭源SDK，遇到性能瓶颈或者连接卡死，定位问题会非常痛苦。第三，MRCP是一个标准协议，讯飞、阿里、腾讯甚至自研引擎都能接入，换引擎不用改FreeSWITCH的diplan逻辑。
MRCP解决的问题就是把“录音转写”这件麻烦事标准化。FreeSWITCH通过mod_unimrcp模块作为MRCP客户端，把RTP音频流送到MRCP服务器，MRCP服务器内部再跟讯飞语音引擎交互。FreeSWITCH只关心MRCP协议层面的请求和响应，不用关心讯飞SDK内部怎么实现。这个对工程维护来说非常重要。
1.3 其他可行方案的对比
除了MRCP这条主流路线，我也见过有人用别的方式把FreeSWITCH和语音识别服务对接起来，各有各的适用范围。
一种是直接用FreeSWITCH的mod_tts_command模块，调外部TTS命令行工具，比如espeak或者讯飞离线命令行的工具。这种方式配置简单，但是只能做TTS，不能做ASR，解决不了语音识别的问题，而且每次合成都要起一个外部进程，效率很低，并发一大就直接打满CPU。
还有一种是通过ESL（Event Socket Library）在FreeSWITCH外部监听呼叫事件，收到用户语音后录音存文件，再异步调用讯飞的文件转写API。这种方案的好处是完全不用改FreeSWITCH，识别逻辑全在外部平台控制，缺点是交互时延很大，做不到实时打断，只适合离线质检这类场景，不适合做实时语音对话机器人。
相比之下，MRCP方案能支持流式识别、支持barge-in打断、支持识别过程中动态控制媒体流，这些能力对语音交互项目来说是刚需。所以只要做实时对话型产品，MRCP基本是唯一靠谱的选择。这里要特别提醒一句：如果只是做几路并发的小规模试验，直接调SDK也不算大问题，一旦要支撑几十路甚至上百路并发，老老实实走MRCP。
2. 核心组件部署与准备工作
2.1 整套系统到底由哪些组件组成
这个标题里的几个技术词，对应到实际部署环境里是这些组件：
| 组件 | 作用 | 版本建议 |
|---|---|---|
| FreeSWITCH | 呼叫控制、媒体转发、MRCP客户端 | 1.10.x 或 1.8.x |
| uniMRCP Server | 真正的MRCP服务器，对接语音引擎 | 1.6.0及以上 |
| 讯飞语音引擎插件 | 让uniMRCP可以调用讯飞ASR/TTS能力 | 讯飞官方提供 |
| 对话系统 | 接收ASR识别文本，返回应答文本 | 自建或第三方平台 |
FreeSWITCH对外提供SIP接口，对内部通过mod_unimrcp跟uniMRCP Server走MRCP协议。uniMRCP Server再通过讯飞提供的插件库向讯飞语音服务发请求。对话系统不直接跟讯飞打交道，它是通过FreeSWITCH的diplan或者外部ESL拿识别结果，再返回回复文本给FreeSWITCH进行TTS播放。
这里容易有一个误解：有人觉得uniMRCP就是讯飞的东西。其实uniMRCP是开源社区的项目，由各大语音引擎厂商或开发者各自写插件，才能把特定引擎接进去。讯飞一般会提供适配uniMRCP的插件包，也可能要求通过MSC/独立SDK的接口自带开发，具体要看商务合作时拿到的交付物。
2.2 FreeSWITCH安装与mod_unimrcp编译要点
我这次的实验环境是Ubuntu 20.04，FreeSWITCH版本用的1.10.7。如果是生产环境，我建议优先用系统自带包管理安装官方发布的稳定版本，避免自己从源码编译踩一堆依赖坑。但mod_unimrcp比较特殊，很多发行版的默认编译开关里没有把它编进安装包，得确认一下。
用源码编译的话，需要保证系统已经安装了libtool、automake、autoconf、libssl-dev、libtool 等基础依赖。FreeSWITCH源码目录里进入src/mod/applications/mod_unimrcp，单独编译这个模块，再把生成的mod_unimrcp.so拷贝到modules目录下。编译完成后在modules.conf.xml里确认下面两行没有被注释：
<load module="mod_unimrcp"/> <load module="mod_sofia"/>如果是Windows环境，也有已经编译好的FreeSWITCH发行包可以下载，Windows下做功能验证和开发调试完全够用，但生产环境我强烈建议放Linux上。Windows版FreeSWITCH自带的模块相对全一些，反而省去自己编译的麻烦。
加载mod_unimrcp之后，用fs_cli执行“show modules”应该能看到unimrcp模块已经加载。如果加载失败，绝大多数原因是缺库或者配置文件里的路径不对。查看FreeSWITCH启动日志，里面有明确的模块加载错误信息。
2.3 uniMRCP Server部署和讯飞插件安装
uniMRCP Server是整个MRCP链路里的核心中转站。它的安装方式通常是把官方源码包解压后执行configure和make。安装完成后，核心的可执行文件是unimrcpserver，配置目录里有unimrcpserver.xml和plugin配置文件。
讯飞的插件安装一般会提供两个部分：一个是讯飞MSC核心库，另一个是适配uniMRCP的插件动态库。插件库里会包含ASR识别引擎和TTS合成引擎的资源适配层。安装完成后，插件动态库要放到uniMRCP Server的plugin目录下，并确保运行用户对库文件有读取权限。
我碰到过的最常见问题，就是直接把讯飞SDK的库拷贝到系统目录，但忘了在unimrcpserver.xml里声明插件资源映射。结果就是ASR请求发过去，uniMRCP Server完全不认识对应的resource。正确做法是确认unimrcpserver.xml中的resource-map配置，把MRCP标准资源名映射到实际的插件模块上。
另外要确认讯飞SDK所需的动态库路径已经写到LD_LIBRARY_PATH，或者把so文件放到系统库目录。讯飞SDK的库经常依赖一堆小动态库，缺任何一个，插件加载就会静默失败，这个排查起来非常恶心，只能靠ldd命令一个一个查。
3. 配置实现与核心流程串联
3.1 配置MRCP Profile文件
FreeSWITCH的mod_unimrcp通过conf/mrcp_profiles目录下的XML文件管理MRCP服务器的连接信息。每台MRCP服务器对应一个profile，name属性就是diplan里引用时的名字。
我通常会在mrcp_profiles目录下建一个xunfei.xml，内容类似这样：
<include> <mrcp_profile name="xunfei" version="2"> <param name="server-ip" value="127.0.0.1"/> <param name="server-port" value="5090"/> <param name="transport" value="tcp"/> <param name="rtp-ip" value="127.0.0.1"/> <param name="rtp-port-min" value="40000"/> <param name="rtp-port-max" value="41000"/> <param name="sip-ip" value="127.0.0.1"/> <param name="media-sync" value="true"/> <param name="ignore-rc" value="false"/> </mrcp_profile> </include>server-ip和server-port是uniMRCP Server的监听地址。默认情况下unimrcpserver监听5090端口，MRCP v1走UDP，MRCP v2走TCP或SIP。我推荐使用MRCP v2，正式环境基本都是TCP，稳定性和调试体验都更好，出问题还能抓包看SIP/MRCP消息，定位效率完全不一样。
rtp-ip和sip-ip这两个参数非常关键，它们决定了FreeSWITCH在跟MRCP服务器建立SIP会话时通告的IP地址。如果FreeSWITCH和uniMRCP Server在同一台机器上，可以都填127.0.0.1。如果是分布式部署，必须填服务器实际网卡上的可路由IP，尤其注意不要填成公网IP或内网不通的地址，否则媒体流会出现RTP单向通的情况。
media-sync参数决定是否做媒体同步。如果后面发现ASR识别到的内容有杂音、丢字、识别准确率低，可以试着把media-sync设为true。这个参数的作用是让FreeSWITCH对发送给MRCP服务器的RTP包做缓冲补偿，抵消网络抖动带来的影响，实测对识别效果提升比较明显。
3.2 uniMRCP Server端配置讯飞引擎参数
uniMRCP Server侧的配置比FreeSWITCH一侧稍微复杂。核心要改两类内容：一是资源映射，二是讯飞引擎参数。资源映射把MRCP标准资源speechrecog和speechsynthesizer映射到讯飞插件，引擎参数则设置appid、密钥、采样率、识别语言等。
在unimrcpserver.xml中，关键配置段类似下面：
<mrcp-server> <profile name="xunfei" version="2"> <resource-map> <resource map="speechrecog" name="XunfeiASR"/> <resource map="speechsynthesizer" name="XunfeiTTS"/> </resource-map> <param name="log-prefix" value="Xunfei"/> </profile> </mrcp-server>讯飞引擎插件自身的配置在不同版本里叫法不太一样，但核心参数基本是这几类：app_id、api_key、api_secret三个鉴权信息，sample_rate采样率，language语言模型。生产环境建议把音频采样率统一设置为8000，因为电话语音本身就是8K采样率，讯飞模型对此优化最成熟，边的16K反而可能因为频段不匹配导致识别率下降。
我踩过一次很深的坑，就是忘记同步采样率。FreeSWITCH侧的L16协商成了16K，但讯飞插件配置的是8K，结果uniMRCP Server转出来的音频全是畸形数据，识别结果完全不可用。后来统一在FreeSWITCH侧设置8K采样率，并且在讯飞插件里也固定8K，问题立刻消失。
3.3 FreeSWITCH dialplan中的ASR/TTS调用方式
配置好profile之后，真正在业务里调用就是用dialplan应用。先从一个最简单的例子看起，这个分机号码是6000，演示了从应答、播报、识别到再次播报的完整流程：
<extension name="mrcp_demo"> <condition field="destination_number" expression="^6000$"> <action application="answer"/> <action application="set" data="tts_engine=xunfei"/> <action application="set" data="tts_voice=xiaoyan"/> <action application="speak" data="text:您好，我是智能客服，请问有什么可以帮您？"/> <action application="play_and_detect_speech" data="silence_stream://1000 xunfei max_time=8000"/> <action application="log" data="ERR 识别结果：${detect_speech_result}"/> </condition> </extension>第一行answer是接通电话，这没问题。接着set两个变量，tts_engine=xunfei是让speak应用走xunfei这个MRCP profile，tts_voice=xiaoyan是设置发音人，比如xiaoyan是女声，xiaofeng是男声。然后speak应用就会把文本交给讯飞TTS合成并播放。
播放完之后，play_and_detect_speech这个应用开启识别。它有两个关键参数：第一个参数silence_stream://1000是一段静音提示音，作用是让FreeSWITCH在开始识别前先播放1秒钟的静音，给用户一个短暂的停顿，同时把麦克风打开；第二个参数xunfei指定MRCP profile；max_time=8000表示最大识别时长8秒。
识别完成后，结果会存在通道变量detect_speech_result里。日志里打出来能看到识别文本，实际项目里这一步就是接对话系统的入口。
关于speak应用，不同FreeSWITCH版本的写法略有差别，但核心逻辑是一样的。有的版本支持在speak里直接指定引擎和文本，比如：
<action application="speak" data="xunfei|text:您好，请问有什么可以帮您？"/>如果发现语音合成不生效，优先检查tts_engine变量是否设置正确，以及uniMRCP Server日志里有没有收到synthesize请求。
3.4 把对话系统接入完整流程
到这里，FreeSWITCH和讯飞的ASR/TTS已经通了，但离标题里说的“对话系统”还差一步。最简单粗暴的方式，是在dialplan里用curl应用把识别结果POST到对话系统接口，再拿返回文本播放。
比如对话系统接口地址是http://127.0.0.1:9900/api/chat，接收一个text字段，返回json里有reply字段，dialplan可以这样改写：
<extension name="mrcp_bot"> <condition field="destination_number" expression="^6001$"> <action application="answer"/> <action application="set" data="tts_engine=xunfei"/> <action application="speak" data="text:您好，请问有什么可以帮您？"/> <action application="play_and_detect_speech" data="silence_stream://1000 xunfei max_time=8000"/> <action application="curl" data="http://127.0.0.1:9900/api/chat content_type=text/plain http_method=POST data=${detect_speech_result} result_to_var=chat_answer"/> <action application="set" data="answer=${parse_json(${chat_answer}, reply)}"/> <action application="speak" data="text:${answer}"/> </condition> </extension>curl应用会把detect_speech_result作为POST请求的body发出去，响应内容存到chat_answer变量里，再用parse_json函数取出reply字段，最后通过speak播报出来。
这段配置看起来很简单，但生产环境要注意一个很现实的问题：curl是同步阻塞的，如果对话系统接口响应慢，用户会在电话里沉默很久。所以对话系统接口的响应时间必须尽量控制在500毫秒以内，而且FreeSWITCH侧要加超时控制。
更工程化的做法是把对外集成放到FS外部，用ESL监听呼叫事件。FreeSWITCH这边只负责识别和放音，识别完成后触发一个自定义事件交给外部服务，外部服务异步调用对话系统，然后通过ESL命令控制FreeSWITCH播放TTS结果。这样做的好处是业务逻辑完全跟呼叫控制解耦。一旦对话系统升级或者接口变化，不需要动FreeSWITCH的dialplan，只要改外部服务。
4. 常见问题排查与工程化优化
4.1 ASR识别结果为空或者忽然断掉
这个是我被问得最多的一个问题。用户明明说话，但程序走到play_and_detect_speech这里之后一直等到max_time耗尽，detect_speech_result里还是空的。细查之后发现主要分两类原因。
第一类是媒体流没有到达uniMRCP Server。FreeSWITCH的RTP流没有正常转发，或者uniMRCP Server收不到音频包。这种问题可以用tcpdump在uniMRCP Server所在网卡抓包，看有没有往8000/40000端口发的RTP包。如果只有信令没有媒体，再回查rtp-ip参数是不是填了一个不可达的地址。
第二类是语音引擎识别到了内容，但FreeSWITCH侧没取到结果。这种时候要去翻uniMRCP Server日志，看有没有把recognition event返回给客户端。如果unimrcp那边有识别结果，而FreeSWITCH的日志里没有detect_speech_result，很可能是MRCP协议交互中途出了问题，可以在FreeSWITCH里打开unimrcp模块的调试日志，看具体的请求和响应。
还有一个容易被忽略的点是barge-in错误。用户在TTS播报还没结束的时候就开始说话，按正常逻辑应该打断播报并开始识别，但如果打断事件处理不对，识别会被直接终止且不返回结果。FreeSWITCH里可以用play_and_detect_speech的no_bargein参数控制打断模式，或者提前在TTS播放前加一段静音，先处理掉用户习惯性的“抢话”行为。
4.2 TTS播报声音卡顿或不完整
TTS播报卡顿，很多时候不是讯飞引擎的问题，而是FreeSWITCH侧RTP发送节奏不对。MRCP v2的TTS合成流式返回，但FreeSWITCH播放音频的时候如果RTP时间戳和实际发送间隔对不上，就会出现声音忽快忽慢或者偶尔断掉。
这种问题我习惯先从uniMRCP Server日志看合成返回的音频参数。如果合成音频是16kHz，而通道里协商的是8kHz，先做音频重采样。如果采样率一致仍有问题，再排查FreeSWITCH的媒体bug开关，有时候要设置enable-rtp-bugs参数。
我遇到过一种很隐蔽的情况：TTS播报偶尔会漏掉最后几个字，听起来像是“您好，请问有什么可以帮”然后就停了。查了半天发现是FreeSWITCH侧在MRCP的speak返回完成事件之后立刻拆掉了RTP会话，导致最后一小段RTP包还在缓冲区里没发出去。解决办法是在播报结束后加一个极短的静音播放，给RTP缓冲区留出清空时间。
4.3 早媒体场景下的识别问题
如果你做的是外呼机器人，大概率会遇到早媒体识别场景，就是FreeSWITCH还没answer之前就需要识别用户语音，来判断是否有人接听。这个场景下电信运营商会把被叫的彩铃或者提示音混在媒体流里，直接开启ASR往往会识别到一堆乱七八糟的内容。
FreeSWITCH处理早媒体的思路是用ring_ready配合p-early-media-support变量控制，把早期媒体交给MRCP引擎做实时检测。具体配置是在dialplan里设置：
<action application="set" data="p-early-media-support=true"/> <action application="ring_ready"/> <action application="detect_speech" data="xunfei start"/>但这里的关键坑在于，早媒体识别一旦开启，用户还没摘机的静默音频也会被当成真实语音送过去，有些噪声还会误触发“有人说话”事件。解决思路是先放一段预识别，把纯静音的音频能量基线测出来，再结合VAD阈值过滤，只有能量超过阈值的音频才真正交给ASR。这部分逻辑讯飞引擎自身可以配置，但工程上我更建议在FreeSWITCH侧做一层前置判决。
4.4 并发性能优化与参数调优
语音机器人的并发能力最终取决于ASR和TTS引擎的处理能力，而FreeSWITCH和uniMRCP Server在中间决定能转发多少媒体流。我实测下来，单台4核8G的服务器跑FreeSWITCH加uniMRCP Server，做8K采样率的ASR和TTS，大概能支撑30到50路并发，但前提是dialplan里没有明显阻塞操作，而且讯飞接口响应要快。
要提升并发，有几个关键参数值得调。第一是uniMRCP Server的线程池和会话并发数，很多版本默认并发数很小，在unimrcpserver.xml里找到session相关配置调大。第二是FreeSWITCH的media线程配置，如果每个呼叫都启用了太多媒体处理功能，CPU很快就耗尽，尽量减少不必要的录音和转码。第三是TTS缓存，对于固定话术，可以把合成好的音频文件缓存下来，下次直接播放文件，不经过MRCP引擎，能大幅降低引擎压力。
我有一套验证过的处理方式：把高频话术的TTS结果在项目初始化时预生成好，存成一个audio目录，dialplan里先用文件判断是否存在，如果存在直接play，如果不存在才走speak。这个优化对降低TTS引擎负载效果非常明显，尤其是在外呼场景里，开场白和结束语几乎都是重复的。
对话系统那边的响应速度也直接决定并发上限，如果对话接口平均响应时间从300毫秒涨到1秒，每路呼叫占用的FreeSWITCH线程就会明显拉长，通路上更容易堆积呼叫。所以对话系统单接口的TPS必须提前压测，别等上线了才发现接口扛不住。
4.5 一套值得养成的调试习惯
最后聊几个我长期踩坑总结出来的调试习惯，适合所有正在接MRCP这套方案的人参考。
第一，永远先查日志，而且要看全。FreeSWITCH日志、uniMRCP Server日志、讯飞SDK日志各看各的不要混在一起，最好把时间戳对齐，一条调用链能串起来看，排查效率会高很多。UNI MRCP Server日志里如果能看到synthesize和recognize的请求响应，说明MRCP协议层面是通的，问题大概率在音频质量或引擎配置。
第二，用抓包工具确认关键信息。MRCP基于SIP和RTP，用Wireshark抓包能直接看到SDP里的媒体参数。很多诡异的问题，比如识别不出来、播报卡顿，抓包一看就知道是SDP协商成了错误的编码格式，比盲猜日志快得多。
第三，不要小看网络延迟。FreeSWITCH和uniMRCP Server跨机房部署的场景下，RTP单向延迟超过几十毫秒就会明显影响识别实时性。如果对话系统还要跨公网访问，延迟更高。生产环境尽量把FreeSWITCH、uniMRCP Server、对话系统放同一个内网，而且最好同一个可用区，这是成本最低但收益最高的性能优化。
我之前有一次线上问题，用户说前几个字总是识别不到，排查到最后发现是FreeSWITCH和uniMRCP Server分别在两个云可用区，RTP包绕了外网走，识别引擎收前100毫秒音频的时候数据还没全部到达。把uniMRCP Server迁到跟FreeSWITCH同一个可用区之后，问题再没出现。
4.6 关于对话系统状态衔接的一些补充
如果你做的项目需要多轮对话，比如“请问您要办理什么业务”“好的，请提供您的手机号”“请确认您需要查询的是本机号码吗”，这里还藏着一个对话系统状态管理的问题。ASR每次识别出来的是单轮文本，但对话系统需要知道当前处在哪个状态，才能正确解析意图。
MRCP协议本身不管状态，FreeSWITCH的dialplan变量可以用来存全局状态，但更推荐把状态放到对话系统侧维护。每次ASR识别完，FreeSWITCH把识别文本和当前session_id发给对话系统，对话系统根据session_id拉取历史状态，生成应答文本后返回。这个session_id可以是FreeSWITCH的通道变量uuid，也可以自己生成一个业务流水号。我习惯直接用${uuid}变量，因为它天然唯一，还能关联到通话记录。
多轮对话场景还有一个容易踩的坑：用户不按套路回答。比如问到“请提供手机号”，用户来一句“我不记得了”，对话系统如果没有兜底话术，就会卡住。工程上要在对话系统侧设计好“未识别意图”和“澄清确认”两条分支，同时FreeSWITCH侧要控制最大误识别次数，超过三次转人工，避免用户体验崩掉。
把ASR、TTS、对话系统通过MRCP这条链路串起来，其实只是智能语音项目的第一步。真正的复杂度在业务状态管理、异常兜底和并发性能上，这些都要靠实战去填坑。上面这些配置和调试方法都是我实际项目里验证过的，可以直接拿去做参考。如果你是第一次搭这套环境，建议先在一台机器上把FreeSWITCH、uniMRCP Server全部装好，用6000分机把最简单的识别放音流程跑通，再逐步加上对话系统和多轮逻辑，整个排查过程会轻松很多。
