Wireshark抓包分析SIP REFER呼叫转移全流程与排错指南 1. 项目概述从抓包视角透视SIP呼叫转移在VoIP和实时通信系统的日常运维与开发中SIPSession Initiation Protocol协议栈的调试是个绕不开的坎。其中呼叫转移Call Transfer作为一项基础且核心的业务功能其实现流程是否标准、信令交互是否完整直接关系到用户体验。很多开发者或运维工程师在面对“呼叫转移失败”这类问题时往往感到无从下手只能凭经验猜测是服务器配置问题还是客户端兼容性问题。这时一款强大的网络协议分析工具——Wireshark就成了我们手中的“听诊器”和“X光机”。今天我们就聚焦于使用SIP协议中的REFER方法来实现的呼叫转移。与大家熟悉的INVITE直接发起呼叫不同REFER实现的是一种“间接”的转移它涉及到发起方Transferor、被转移方Transferee和转移目标Transfer Target三方信令交互更为复杂。而NOTIFY消息则是这个流程中传递状态反馈的关键环节理解它对于定位“转移是否成功”、“卡在哪一步”至关重要。本文的目标非常明确手把手地带你走一遍用Wireshark抓包、分析一个完整SIP REFER呼叫转移流程的全过程。我们将不仅仅停留在“看到有这些包”而是要深入每个关键字段特别是REFER请求的构造、202 Accepted响应的含义以及后续一连串NOTIFY消息中message/sipfrag实体内容所传达的精确状态。无论你是在调试FreeSWITCH、Asterisk、Kamailio等开源PBX还是在开发自己的SIP客户端这套方法都能为你提供清晰的排错思路和扎实的理论依据。2. 核心概念与抓包环境准备2.1 SIP REFER与NOTIFY呼叫转移的“信使”与“回执”在深入抓包之前我们必须先理清几个核心概念否则面对一屏幕的数据包只会一头雾水。SIP REFER方法它的作用类似于我们日常说的“请呼叫某某”。当用户ATransferor与用户BTransferee正在通话时A想把B转给CTransfer TargetA的客户端或服务器就会向B发送一个REFER请求。这个请求的核心在于其Refer-To头域里面包含了C的SIP URI如sip:alice192.168.1.100。REFER本身并不建立A与C或B与C的对话它只是下达一个“指令”。SIP SUBSCRIBE/NOTIFY机制这是SIP事件通知框架的核心。当B收到REFER请求并接受回复202 Accepted后B的客户端User Agent会自动向A发起一个SUBSCRIBE订阅订阅的事件Event头域是refer。这个订阅关系建立后B在尝试联系C的整个过程中如发送INVITE、收到响应等都会通过NOTIFY消息将每一步的状态“回执”发送给A。这些状态就封装在NOTIFY消息体的message/sipfrag部分。message/sipfrag内容这是解读转移进度的密码本。它本质上是一个SIP消息的片段。例如当B开始呼叫C时发给A的NOTIFY消息体里可能就包含SIP/2.0 100 Trying表示“正在尝试”如果C振铃消息体里就是SIP/2.0 180 Ringing如果C接听就是SIP/2.0 200 OK。通过解析这一连串的sipfragA就能像看直播一样实时掌握B呼叫C的进展。2.2 Wireshark抓包环境搭建与关键配置工欲善其事必先利其器。一次成功的抓包分析始于正确的环境配置。1. 网络接口选择与混杂模式 这是新手最容易出错的地方。打开Wireshark在初始界面你会看到所有网络接口的列表如“以太网”、“WLAN”、“本地连接*”。关键点在于你必须选择SIP流量实际流经的那个接口。场景一单机调试如果你在本地电脑上同时运行SIP客户端如Zoiper, MicroSIP和软电话服务器如FreeSWITCH in localhost流量可能走的是环回接口“Adapter for loopback traffic”或本地虚拟网卡。你需要确认你的SIP客户端配置的服务器地址如127.0.0.1或本机IP。场景二跨设备如果你的SIP服务器如IP-PBX和客户端在不同设备上你需要在你分析的那台设备的物理网卡上抓包。例如想分析客户端发出的包就在客户端的网卡上抓。务必勾选“在所有接口上使用混杂模式”。混杂模式允许网卡捕获所有流经该网段的包而不仅仅是发给本机的包。这对于捕获服务器与客户端之间、或两个客户端之间的对话至关重要。2. 捕获过滤器Capture Filter的妙用 如果网络环境嘈杂直接抓所有包会产生海量无关数据。我们可以使用捕获过滤器进行初步筛选。针对SIP分析最常用的过滤器是端口过滤port 5060捕获标准SIP端口UDP/TCP的流量。port 5060 or port 5061同时捕获SIP和SIPS加密SIP流量。host 192.168.1.100仅捕获与特定IP地址相关的所有流量包括SIP和RTP媒体流。 一个更精确的过滤器可以是host 192.168.1.50 and (port 5060 or portrange 10000-20000)这表示只抓来自/发往IP为192.168.1.50的设备且端口是5060信令或10000-20000可能是RTP媒体端口范围的包。3. 显示过滤器Display Filter的准备 抓包完成后我们主要依靠显示过滤器在“海洋”中快速定位“珍珠”。针对本次REFER流程我们会高频使用以下过滤器sip显示所有SIP协议包。sip.Method REFER或sip.CSeq.method “REFER”快速定位到REFER请求。sip.Method NOTIFY筛选出所有NOTIFY消息。sip.Call-ID “abcdefg192.168.1.50”通过Call-ID追踪一个完整的SIP对话Dialog。这是最强大的分析手段因为一次呼叫转移涉及多个对话A-B的原始对话B-C的新对话它们通过Refer-To和Replaces等头域关联但拥有不同的Call-ID。注意在开始抓包前最好清空一下Wireshark的临时缓存点击“捕获”-“重新开始捕获”并确保你的SIP客户端和服务器已经准备就绪处于待机状态。开始抓包后再进行呼叫转移操作。3. 完整SIP REFER呼叫转移流程逐步解析现在让我们进入实战环节。假设一个典型场景分机1001Alice与分机1002Bob正在通话Alice要将Bob转移给分机1003Carol。我们将用Wireshark记录下全过程。3.1 阶段一原始通话的建立与REFER请求的发起首先我们需要捕获Alice1001呼叫Bob1002并建立通话的初始流程。这通常是一个标准的SIPINVITE-200 OK-ACK三次握手随后通过RTP流传输语音。在Wireshark中你可以使用过滤器sip contains “1001”或通过Call-ID找到这个初始对话。记下这个初始对话的Call-ID例如call-id-1234pbx.domain.com它非常重要。当Alice决定执行“盲转”Blind Transfer即不咨询Bob直接转或“咨询转”Attended Transfer先咨询Carol再转时她的客户端或服务器会发起REFER请求。关键抓包点定位REFER请求应用过滤器sip.Method REFER。你应该能看到一个从Alice或代表Alice的服务器发往Bob的SIP请求。让我们详细拆解这个REFER请求的关键部分Request-Line:REFER sip:1002192.168.1.10:5060 SIP/2.0From/To: 通常与原始通话的From/To一致标识这个REFER属于哪个已有的对话Dialog。From标签tag和To标签必须与原始对话匹配SIP核心依靠这个来将REFER关联到正确的会话上。Call-ID: 这个Call-ID必须与Alice和Bob原始通话的Call-ID相同。这是Wireshark能将会话关联起来的最重要依据。CSeq: 序列号会增加例如原始通话最后一个CSeq是 20 INVITE那么REFER可能就是 21 REFER。Refer-To头域核心:Refer-To: sip:1003192.168.1.10;methodINVITE?Replacescall-id-1234%3Bto-tag%3Dxyz%3Bfrom-tag%3Dabc。这是REFER的灵魂。sip:1003192.168.1.10指明了转移目标Carol的地址。methodINVITE指示被转移方Bob应该使用INVITE方法去联系Carol。Replaces参数在咨询转中常见这是一个高级特性用于实现“替换”式转移。它的值包含了原始通话Alice-Bob的Call-ID、to-tag和from-tag。如果Bob在呼叫Carol的INVITE中带上这个Replaces头Carol的客户端接听后可以尝试“替换”掉Alice直接与Bob建立媒体连接从而实现更平滑的转移。在盲转中可能没有Replaces参数。Refer-Sub头域: 常见值为false。如果为false表示Bob必须在尝试联系Carol后向Alice发送NOTIFY消息报告状态。这是RFC标准行为。如果为true则表示Bob不需要发送NOTIFY非标准较少见。3.2 阶段二被转移方的响应与订阅建立Bob的客户端User Agent收到REFER请求后会进行处理。1. 202 Accepted响应 如果Bob的客户端接受这个转移指令它会立即回复一个SIP/2.0 202 Accepted。这个响应只表示REFER请求本身被接受了并不代表转移动作成功。它的To头域会添加一个标签tag这个标签将用于后续SUBSCRIBE/NOTIFY对话的标识。2. 自动发起SUBSCRIBE订阅 紧接着几乎是瞬间Bob的客户端会作为订阅者Subscriber向Alice通知者Notifier发起一个SUBSCRIBE请求。这个请求开启了另一个新的SIP对话拥有新的Call-ID。Request-Line:SUBSCRIBE sip:1001192.168.1.10 SIP/2.0Event头域:Event: refer。明确订阅的是refer事件。Expires头域: 通常为36001小时表示订阅有效期。Contact头域: 包含了Bob客户端用于接收NOTIFY的地址。Alice的客户端或服务器收到SUBSCRIBE后会回复200 OK并在响应中携带一个Subscription-State头域如Subscription-State: active;expires3600表示订阅已激活。至此Alice和Bob之间建立了一个关于refer事件的订阅关系。这个关系是单向的Bob有义务向Alice通知转移的进展。3.3 阶段三NOTIFY消息流与状态实时反馈订阅关系建立后Bob开始执行转移动作——呼叫Carol。这个过程的每一步都会触发Bob向Alice发送一条NOTIFY消息。这是我们分析转移进度、诊断问题的核心环节。在Wireshark中使用过滤器sip.Method NOTIFY可以快速定位到这一系列消息。我们需要重点关注每条NOTIFY的消息体Body其Content-Type通常是message/sipfrag。让我们按顺序解读典型的NOTIFY消息流NOTIFY 1: 尝试发起呼叫消息头:Event: referSubscription-State: active。消息体 (message/sipfrag):SIP/2.0 100 Trying解读: Bob的客户端或代理服务器已经收到REFER指令并开始尝试向Carol1003发起INVITE请求。100 Trying是一个临时响应表示“已收到请求正在处理”。NOTIFY 2: 目标振铃消息体:SIP/2.0 180 Ringing解读: Carol的客户端已经收到INVITE并开始振铃。这说明网络可达Carol的SIP UA在线且正常响应。对于发起转移的Alice来说这是一个积极的信号。NOTIFY 3: 目标接听转移成功消息体:SIP/2.0 200 OK解读:这是转移成功的关键标志Carol接听了电话。Bob和Carol之间的媒体通道RTP应该已经建立。此时原始的Alice-Bob通话可能会被释放BYE也可能保持取决于实现但业务逻辑上转移已完成。NOTIFY 4: 订阅终止在最后一个状态通知后Bob会发送一条NOTIFY其Subscription-State头域变为terminated原因可能是timeout或noresource。这表示关于此次refer事件的订阅已经结束不会再发送新的状态更新。异常状态NOTIFY示例 如果转移失败NOTIFY消息体将包含错误信息。SIP/2.0 404 Not Found: 表示找不到Carol目标分机不存在或离线。SIP/2.0 486 Busy Here: 表示Carol忙。SIP/2.0 408 Request Timeout: 表示Bob尝试INVITE Carol但超时无响应。SIP/2.0 603 Declined: 表示Carol拒绝了呼叫。通过查看这些sipfrag内容你可以精准定位转移失败的原因而无需去分析Bob呼叫Carol的完整SIP流程当然如果需要深入排查可以基于Bob-Carl对话的Call-ID去过滤查看。3.4 阶段四媒体流切换与原始会话终结在成功的转移特别是带Replaces的咨询转后媒体流会发生切换。Bob-Carol媒体建立Bob向Carol发送INVITE协商媒体SDP Offer/Answer成功后双方建立RTP/RTCP流传输语音。你可以在Wireshark中使用rtp过滤器并查看流的分析Telephony - RTP - Stream Analysis来确认。Alice-Bob媒体释放转移成功后Alice和Bob之间的通话通常需要结束。Alice或Bob会向对方发送BYE请求结束原始会话。在Wireshark中你可以用原始通话的Call-ID过滤看到BYE和200 OK的交换。媒体路径最终语音路径从最初的 Alice - Bob变为 Bob - Carol。Alice完全退出通话。4. Wireshark高级分析技巧与问题排查实战掌握了基本流程我们来看看如何利用Wireshark的高级功能像侦探一样解决实际问题。4.1 使用对话追踪与流图进行可视化分析面对错综复杂的多个SIP对话Alice-Bob原始对话、REFER触发的SUBSCRIBE/NOTIFY对话、Bob-Carol新对话手动过滤Call-ID很麻烦。Wireshark提供了强大的可视化工具。1. SIP对话列表 点击菜单栏的“电话”Telephony - “VoIP呼叫”VoIP Calls。在弹出的窗口中你会看到所有检测到的SIP呼叫对话。每个对话都列出了主叫、被叫、初始INVITE时间、状态等。找到你关心的呼叫点击“准备过滤器”Prepare Filter或“图形化”GraphWireshark会自动应用对应的Call-ID过滤器并高亮显示该对话的所有包。2. 流图Flow Graph 在过滤出特定对话的包之后点击“统计”Statistics - “流图”Flow Graph。选择“显示为一个图”Display as a graph。这个时序图能极其清晰地展示出所有SIP消息的来往方向、顺序和时间间隔。对于分析REFER流程你可以一目了然地看到INVITE(A-B)REFER(A-B)SUBSCRIBE(B-A)一系列NOTIFY(B-A)INVITE(B-C 可能不在同一图里需单独过滤)BYE(A-B 或 B-A)通过流图很容易发现消息序列错乱、响应缺失或超时等问题。4.2 典型呼叫转移失败场景排查指南当你遇到“呼叫转移失败”时可以按照以下步骤结合Wireshark抓包进行排查场景一根本收不到REFER请求现象Alice操作转移但Wireshark中过滤不到sip.Method REFER的包。排查思路检查客户端确认Alice的客户端是否支持并正确配置了呼叫转移REFER功能。有些基础客户端可能不支持。检查服务器如果转移由服务器如PBX发起检查PBX的拨号计划Dialplan中关于转移的配置是否正确触发。在FreeSWITCH中检查transfer或deflect动作是否被正确执行。检查网络路径确认抓包点是否在REFER请求的必经之路上。如果Alice和Bob通过服务器通信确保在服务器端或客户端抓包。场景二收到REFER但无202响应或后续NOTIFY现象能看到REFER请求但没有来自Bob的202 Accepted响应。排查思路解析REFER请求仔细检查REFER包的Refer-To头域格式是否正确SIP URI是否合法。检查From/To的tag是否与原始通话匹配。检查Bob的UA能力Bob的SIP用户代理电话或软客户端必须支持并启用REFER方法。检查其SIP注册消息REGISTER或OPTIONS响应的Allow头域是否包含REFER。防火墙/ACL检查Bob端的防火墙或访问控制列表是否屏蔽了来自Alice或服务器的SIP消息端口5060。场景三有202和SUBSCRIBE但NOTIFY状态卡住或报错现象收到了202 Accepted和SUBSCRIBE但NOTIFY消息停止在某个状态如一直100 Trying或sipfrag里是4xx/5xx/6xx错误。排查思路分析NOTIFY消息体这是最关键的一步。如果sipfrag是404 Not Found问题出在Bob寻找Carol的阶段。检查Carol的分机是否已注册SIP地址是否正确。检查Bob呼叫Carol的独立流程使用Wireshark过滤出Bob1002与Carol1003之间的SIP流量例如(ip.src 192.168.1.10 and ip.dst 192.168.1.11) or (ip.src 192.168.1.11 and ip.dst 192.168.1.10) and sip。单独分析这个INVITE流程看问题出在哪个环节INVITE未发出、无响应、对方拒绝等。检查Replaces头如果使用了Replaces确保Bob发出的INVITE中正确携带了该头域且其包含的Call-ID和tag与原始通话完全匹配。Carol的UA也必须支持Replaces头域否则可能拒绝该INVITE回复603 Decline。场景四转移后媒体不通单通/双不通现象信令显示转移成功NOTIFY收到200 OK但Bob和Carol听不到对方声音。排查思路分析SDP在Bob发给Carol的INVITEOffer和Carol回复的200 OKAnswer中检查SDPSession Description Protocol部分。重点关注c连接地址和m媒体行。确认c行中的IP地址是公网可达地址还是私网地址如192.168.x.x。如果是私网地址且Bob和Carol不在同一局域网则需要NAT/防火墙穿越如STUN、ICE、TURN支持。检查RTP流在Wireshark中应用rtp过滤器查看是否有在Bob和Carol的IP地址之间传输的RTP包。使用“电话”-“RTP”-“流分析”功能查看是否有丢包、抖动或延迟过高的情况。检查编码协商确认SDP中m行里双方协商出的公共音频编码如PCMA/8000,PCMU/8000,G.729等。如果双方没有共同的编码媒体无法建立。4.3 实操心得让Wireshark分析更高效的几个习惯保存过滤表达式将常用的显示过滤器如sip.Method REFER or sip.Method NOTIFY保存起来。在Wireshark过滤器输入框输入后点击右侧的书签图标即可保存下次一键调用。使用着色规则为不同类型的SIP消息设置不同的颜色可以快速在包列表中进行模式识别。例如将REFER设为亮黄色NOTIFY设为浅蓝色错误响应4xx, 5xx, 6xx设为红色。规则在“视图”-“着色规则”中设置。关注时间差在包列表的“Time”列可以设置为“自从上一个捕获包的时间差”关注关键消息之间的间隔。例如从REFER发出到收到202 Accepted的时间从NOTIFY 100 Trying到NOTIFY 180 Ringing的时间。异常长的延迟可能指向网络或服务器处理性能问题。导出特定数据可以将过滤后的数据包如某个完整呼叫转移流程的所有包导出为一个新的pcap文件便于存档或与同事分享分析。右键点击任意一个过滤后的包选择“标记/取消标记所有显示的数据包”然后“文件”-“导出特定分组”-“标记的分组”。结合日志分析Wireshark抓取的是网络层面的信令。当遇到复杂问题时一定要结合SIP服务器如FreeSWITCH的console/log和客户端的日志进行交叉分析。网络包告诉你“发生了什么”服务器日志可能告诉你“为什么这么做”。通过以上系统性的抓包、过滤、解码和分析步骤你就能将黑盒般的SIP呼叫转移流程彻底透明化。无论是排查偶发性故障还是验证新功能上线后的协议合规性这套基于Wireshark的实战方法都是通信工程师和开发者工具箱里不可或缺的利器。记住协议分析的核心在于对比将实际抓到的包与RFC标准以及你预期的正常流程进行对比差异点往往就是问题的根源。