SIP协议通话转接：从REFER/Re-INVITE原理到STM32嵌入式实战-育师

1. 项目概述：从“呼叫保持”到“无缝转接”的跨越

在基于SIP协议构建的现代通信系统中，“通话转接”功能远不止是点击一个按钮那么简单。它背后是一套严谨的信令交互逻辑，涉及到主叫方、被叫方、转接方（也就是我们常说的操作员或秘书）以及最终的目标方，这四方之间状态与媒体的精确同步。很多开发者，尤其是刚接触SIP协议栈或正在嵌入式平台（比如STM32上跑SIP客户端）上实现功能的朋友，常常会在这里踩坑：转接后一方听不到声音、转接失败但原通话被意外挂断、或者信令流程看似通了但媒体流（RTP）却没跟上。今天，我们就来彻底拆解SIP协议中的通话转接，不仅讲清楚标准的REFER和Re-INVITE方法，更会结合实战，分享如何在资源受限的嵌入式环境中稳定实现它，并附上信令流程图的关键解读与避坑指南。

2. 核心概念与转接模式深度解析

在动手写代码之前，我们必须先厘清SIP转接的几种核心模式及其适用场景。这决定了你后续的信令设计和资源管理策略。

2.1 盲转与协商转接：流程与选择的本质区别

盲转，也称为无人值守转接。其核心特点是，转接方（Transferor）在发起转接动作后，立即退出会话，不再关心转接是否成功。它向被转接方（Transferee）发送一个REFER请求，指示其去呼叫第三方（Transfer Target），然后自己发送BYE挂断与原被转接方的通话。这个过程快速、直接，但用户体验粗糙，因为转接方无法知晓转接结果（是成功接通、忙线还是无人接听），原被转接方会经历一个明显的通话中断再重新振铃的过程。

注意：盲转的REFER请求中，Refer-To头字段是必须的，它包含了目标方的SIP URI。同时，Refer-Sub头字段可以设置为false，表明不要求订阅转接结果事件。

协商转接，也称为出席转接或咨询转接。这是更友好、更专业的模式。转接方先“咨询”一下目标方是否愿意并能够接听电话，通常是通过发起一个到目标方的新的呼叫，并与对方进行简短交流。在获得目标方同意后，转接方再执行转接操作，将原被转接方“介绍”给目标方，然后自己优雅退出。在这个过程中，原被转接方可能处于音乐保持状态，体验更平滑。

从协议实现角度看，协商转接通常涉及两个独立的对话（Dialog）：一个是转接方与被转接方的原始对话，另一个是转接方与目标方的咨询对话。最终的转接动作，本质上是将这两个对话“桥接”起来。

2.2 关键SIP方法：REFER、Re-INVITE与NOTIFY

REFER方法：这是实现转接的专用方法。它请求接收方（被转接方）使用Refer-To头字段中提供的请求URI，去向第三方发起一个请求（通常是INVITE）。REFER会创建一个订阅，接收方需要用NOTIFY来报告引用请求的结果状态。
Re-INVITE方法：这是SIP中用于修改现有会话参数的方法。在转接场景中，它常被用于实现“三方通话”后的一方退出，或者直接更改媒体连接地址。例如，转接方可以通过Re-INVITE，将原会话的媒体流从指向自己改为指向目标方。
NOTIFY方法：与REFER订阅配合使用。被转接方在尝试呼叫目标方后，必须向转接方发送NOTIFY消息，告知其转接状态（如100 Trying,180 Ringing,200 OK,486 Busy Here等）。

选择哪种方法组合，取决于你的业务逻辑。纯REFER适用于盲转。而协商转接则可能混合使用INVITE（建立咨询呼叫）、Re-INVITE（桥接媒体）和REFER。

3. 信令流程图解与状态机设计

理解信令序列最直观的方式就是看图。下面我们以“协商转接”为例，描述一个完整的信令交互过程，这对于用stm32 sip这类嵌入式设备进行调试至关重要。

场景：Alice（主叫）与Bob（被叫/转接方）正在通话。Bob需要将电话转接给Carol（目标方）。

咨询呼叫建立：
- Bob 向 Carol 发送INVITE，建立一个新的呼叫对话。此时Bob和Alice的通话可能被置于保持状态（发送带a=sendonly的Re-INVITE）。
- Carol 振铃并接听，Bob与Carol建立媒体连接，进行简短咨询。
执行转接：
- Bob 决定转接。他向Alice发送REFER请求，其中Refer-To头字段为Carol的联系URI（如sip:carol@192.168.1.103）。同时，Bob 订阅此转接事件。
- Alice 的UA收到REFER后，自动向Carol发起一个新的INVITE呼叫。
- Alice 同时向Bob发送202 Accepted响应REFER，并开始发送NOTIFY报告进度。
会话桥接与退出：
- Carol 收到Alice的INVITE后振铃、接听。Alice与Carol建立媒体连接。
- Alice 向Bob发送NOTIFY，告知呼叫成功（SIP 200 OK）。
- Bob 收到成功通知后，向Alice和Carol分别发送BYE，结束自己与双方的对话，完成退出。

在这个过程中，Bob（转接方）的SIP状态机需要维护至少两个对话的状态，并能正确处理REFER的发起、NOTIFY的接收以及后续的会话拆除。一个常见的错误是状态机混乱，在转接未完成时就匆忙发送BYE，导致通话中断。

实操心得：在嵌入式设备上实现时，由于内存和CPU资源有限，建议为每个对话（Dialog）设计清晰的状态枚举。使用一个定时器来管理转接超时（例如，发送REFER后10秒内未收到最终NOTIFY则视为失败并恢复原通话），防止资源被死锁。

4. 嵌入式环境下的实现要点与避坑指南

在STM32这类MCU上实现SIP客户端，资源约束是首要挑战。以下是几个关键点的深入分析。

4.1 协议栈选择与内存管理

你不太可能从头实现一个完整的SIP协议栈。通常的选择是移植一个轻量级的开源栈，如pjsip（经过大量裁剪）、eXosip或oSIP。选择时需权衡：

代码尺寸与功能：pjsip功能强大但体积大，需要大量裁剪。oSIP更轻量，但可能需要自己处理更多底层细节（如事务状态机、消息解析）。
内存池设计：SIP消息（尤其是带SDP的INVITE）可能较大。必须实现一个高效的内存池，避免频繁的malloc/free造成内存碎片。可以为每个对话分配固定大小的消息缓冲区。
网络IO与解析：SIP over UDP是常见选择，但需处理重传。TCP则更可靠但连接管理更复杂。建议在资源允许下优先使用UDP，并实现简单的重传机制（基于事务层）。消息解析器应能流式处理，避免一次性加载整个报文。

4.2 SDP协商与媒体流处理

转接成功的关键在于SDP的重新协商。当Alice呼叫Carol时，双方会交换新的SDP，协商出新的媒体端口和编解码。这里有两个大坑：

NAT穿越与媒体地址：在局域网内测试一切正常，一到公网就单向无声。这是因为SDP中的c=和m=行包含了私网IP和端口。你必须集成STUN、TURN或ICE机制来获取公网可达的地址。对于STM32，可以依赖外部的STUN服务器，在生成SDP前先进行STUN绑定发现。
编解码匹配与转码：如果Alice支持G.711和G.722，而Carol只支持G.729，那么直接转接可能因编解码不匹配而失败。作为转接方Bob，如果设备性能允许，可以充当一次媒体代理（Media Proxy），进行编解码转码。但这会极大消耗MCU的DSP资源。更常见的做法是，在REFER或INVITE的SDP offer中，列出双方交集内的编解码，或遵循“最小公分母”原则（如只放G.711）。

4.3 错误处理与恢复机制

健壮性体现在错误处理上。以下场景必须考虑：

REFER被拒绝：Alice的UA可能不支持REFER，回复405 Method Not Allowed或501 Not Implemented。此时，Bob应能回退到另一种转接方式（例如，通过会议桥接实现），或者向用户播放提示音。
转接目标无响应：Carol不应答。Alice的UA会发送NOTIFY报告408 Request Timeout或480 Temporarily Unavailable。Bob应能取消转接，并重新与Alice建立媒体连接（发送Re-INVITE取消保持）。
网络中断：在转接过程中网络闪断。你的状态机需要有超时机制，并将所有对话状态持久化到非易失性存储器（如Flash）中，上电后能尝试恢复或清理。

5. 实战：一个简化的STM32 SIP转接代码框架

假设我们使用一个裁剪后的oSIP栈。以下是核心逻辑的伪代码框架，重点展示状态管理和信令发送。

// 定义对话状态 typedef enum { DIALOG_IDLE, DIALOG_CONNECTED, // 与Alice的通话 DIALOG_CONSULTING, // 与Carol的咨询通话 DIALOG_REFER_SENT, DIALOG_WAIT_NOTIFY, DIALOG_TRANSFERED } dialog_state_t; // 主处理循环中的片段 void handle_sip_event(osip_event_t *evt) { switch(evt->type) { case OSIP_MSG_INVITE: { // 处理来电，建立与Alice的对话 create_dialog(evt, &dialog_alice); dialog_alice.state = DIALOG_CONNECTED; // 发送200 OK和SDP send_ok_with_sdp(dialog_alice); // 启动RTP流 start_rtp_session(dialog_alice.remote_audio_port); } break; case USER_REQUEST_TRANSFER: { // 用户按下转接键 if(dialog_alice.state == DIALOG_CONNECTED) { // 1. 先保持与Alice的通话 send_reinvite_to_hold(dialog_alice); // 2. 发起咨询呼叫到Carol dialog_carol.state = DIALOG_CONSULTING; send_invite_to_carol(dialog_carol); } } break; case OSIP_MSG_200_OK: { // 处理对咨询呼叫的200 OK if(来自Carol && dialog_carol.state == DIALOG_CONSULTING) { dialog_carol.state = DIALOG_CONNECTED; // 3. 向Alice发送REFER send_refer_to_alice(dialog_alice, carol_uri); dialog_alice.state = DIALOG_REFER_SENT; // 订阅转接事件 start_refer_subscription(dialog_alice); } } break; case OSIP_MSG_NOTIFY: { // 处理来自Alice的NOTIFY if(来自Alice && dialog_alice.state == DIALOG_REFER_SENT) { int status = parse_notify_body(evt); if(status == 200) { // 转接成功 // 4. 向Alice和Carol发送BYE，自己退出 send_bye(dialog_alice); send_bye(dialog_carol); dialog_alice.state = DIALOG_TRANSFERED; dialog_carol.state = DIALOG_IDLE; // 释放RTP资源 stop_all_rtp_sessions(); } else { // 转接失败，恢复与Alice的通话 send_reinvite_to_unhold(dialog_alice); dialog_alice.state = DIALOG_CONNECTED; // 挂断与Carol的咨询通话 send_bye(dialog_carol); } } } break; } }

这个框架清晰地勾勒出了状态迁移的路径。在实际编码中，你需要填充每个send_xxx函数的具体报文构造和发送逻辑，并完善错误分支的处理。

6. 调试技巧与常见问题排查

调试SIP信令，尤其是嵌入式设备上的，离不开抓包和分析。

必备工具：Wireshark：在PC端或网关设备上抓取SIP流量（端口5060/5061）。使用Wireshark的“Telephony -> VoIP Calls”功能，可以自动重组整个呼叫流程，一目了然。
典型问题排查清单：

问题现象	可能原因	排查步骤与解决方案
转接后双方无声	1. SDP媒体地址错误（NAT问题） 2. 防火墙/路由器未开放RTP端口范围 3. 编解码不匹配	1. 检查SDP中`c=`和`m=`行的IP和端口是否为公网可达。引入STUN。 2. 确认RTP端口（通常在SDP的`m=`行指定）已在网络设备上做UDP转发。 3. 对比双方INVITE/200 OK中的SDP，确认有共同的编解码（如`a=rtpmap`）。
转接失败，原通话被挂断	1. 状态机错误，过早发送BYE 2. REFER请求格式错误，被UA拒绝	1. 检查代码逻辑，确保只在收到转接成功的NOTIFY后才发送BYE。添加更多状态日志。 2. 用Wireshark检查发出的REFER报文，确保`Refer-To`头格式正确，且Request-URI是原对话的Remote Tag。
嵌入式设备在转接时重启或死机	1. 内存泄漏或溢出 2. 协议栈处理超时或重传时陷入死循环	1. 使用内存分析工具（如`malloc`钩子）检查每次事务处理后的内存分配情况。确保响应和事务结构体被正确释放。 2. 检查定时器回调函数，避免阻塞操作。确保网络读写的超时设置合理。
收到 “488 Not Acceptable Here”	对方不支持SDP中提议的媒体类型或属性	检查自己发出的SDP offer，尝试只包含最基础的编解码（如PCMU/PCMA），并移除不必要的扩展属性（如`a=rtcp-fb`）。