【SIP&MRCP】freeswitch中transfer与bridge的实战应用场景解析

1. 别再傻傻分不清：transfer和bridge到底在干嘛？

刚接触FreeSWITCH那会儿，我也被transfer和bridge这两个词搞得晕头转向。文档里说得挺清楚，但一到实际写拨号计划（Dialplan）的时候，就总犯嘀咕：我这儿到底该用transfer还是bridge？用错了会怎么样？后来踩过几次坑，做了好几个项目，我才算真正摸透了它们的脾气。今天我就用大白话，结合SIP和MRCP语音识别这些实战场景，跟你好好唠唠，保证你听完就能用上。

你可以把FreeSWITCH想象成一个超级智能的电话交换机。transfer和bridge就是它手里两个功能不同的“连接器”。transfer的核心是“换人接电话”。比如你打给客服A，A觉得问题该由B处理，他就用transfer把你的电话“转交给”B。对你来说，感觉像是通话短暂中断了一下，然后换了个声音跟你说话。bridge的核心则是“拉个群聊”。它直接把两个（或更多）独立的通话通道（Channel）接在一起，让双方能直接对话。比如你从外线打进来，FreeSWITCH用bridge把你和坐席的电话连起来，你们俩就能开聊了。

那SIP和MRCP又是啥？SIP就是互联网上打电话、发视频的那套通用协议，FreeSWITCH靠它和手机、软电话、其他交换机“说话”。MRCP则是FreeSWITCH和语音识别（ASR）、语音合成（TTS）引擎“说话”的专用协议。当你需要实现智能IVR（比如“说出您要办理的业务”）、语音质检这些高级功能时，MRCP就派上用场了。

所以，我们今天聊的，就是在FreeSWITCH这个舞台上，如何根据剧情（业务场景），正确指挥transfer（换演员）和bridge（搭戏台）这两个角色，尤其是当剧情里还需要SIP和MRCP这两个“特效团队”配合的时候。搞明白这个，你设计的语音系统才会既流畅又聪明。

2. 深入骨髓：transfer的两种面孔与实战配置

光知道transfer是转接还不够，它还有两张关键面孔：** attended transfer（代接/协商转移）** 和 blind transfer（盲转）。这俩的区别，直接决定了用户体验和系统流程的复杂度。

Blind Transfer（盲转），顾名思义，就是“盲目的转接”。发起转接的一方（比如客服A）在电话机上按个转移键，输入同事B的分机号，然后就直接挂机开溜了。FreeSWITCH会先挂断和A的通话，然后尝试去呼叫B。如果B接了，那么你和B就直接通话；如果B忙或者无人接听，那这次通话可能就失败了。这个操作简单粗暴，在内部转接或者明确知道对方一定能接听的场景下很快捷。在Dialplan里，实现盲转通常就用一个transfer动作，后面跟上目标号码或Dialplan的上下文（Context）和分机号（Extension）。

Attended Transfer（代接转移），就更讲究、更人性化一些。还是那个场景，客服A觉得问题该由B处理。但他不会直接把你扔过去，而是先“咨询”一下B。流程是这样的：1. A先把你“保持”住；2. A单独呼叫B，和B先通个话，说明情况：“我这有个客户问XX问题，你方便接吗？”；3. B说“可以”，A再操作电话机（通常是按个DTMF键如*3），把你和B桥接起来，然后A自己功成身退。这个过程中，你作为客户，大部分时间在听音乐等待，最后无缝衔接到了B，体验更好。FreeSWITCH对代接转移有非常好的原生支持，涉及到uuid_bridge、att_xfer等底层应用。