做VoIP的同学或者刚接触SIP协议的朋友应该都有过这种经历明明照着网上教程配置好了软电话和服务器注册状态却总在401和200之间来回拉扯呼叫对方时屏幕上永远转圈最后收到一个408抓包看到一堆信令却分不清哪条有用。如果你也想把SIP核心信令彻底搞明白这篇分享就是为你准备的。SIP不是那种看完一篇教程就能完全吃透的协议它和HTTP一样是文本协议但你真正上手调试时才会发现注册、呼叫、挂断、转接、补缺每一步都有对应的信令组合顺序错一个、头域少一个通话就可能起不来。这篇文章我会从消息结构讲起把最常见的注册流程和呼叫流程拆成一行一行来讲再把手头排查过的坑和常用工具一起整理出来希望能帮你少走点弯路。1. 项目概述为什么说SIP核心信令是所有VoIP应用的“地基”1.1 先来认人两个完全不一样的“SIP”先说一个容易让人懵的点。很多人搜“SIP”会搜到“M2 Mac关闭SIP方法”这类热搜词那个SIP是macOS的System Integrity Protection系统完整性保护机制跟通信协议八竿子打不着。具体来说它是苹果系统用于防止恶意代码修改系统文件的安全机制开发者为了调试或安装某些驱动偶尔需要临时关闭它。而那和今天要讲的通信SIP完全不同。我们说的SIP全称是Session Initiation Protocol会话初始协议由RFC 3261定义。它是VoIPVoice over IP世界里最核心的信令协议之一负责两件事找到对方并协商好怎么通话。打电话时你听到的拨号音、对方手机的振铃、接通后的语音流背后都离不开SIP信令在调度。你可以把它理解为通信双方之间的“前台接待”——谁打给谁、什么时候接、用什么编码、怎么断开都由它传递。所以当你再看到“Mac SIP”这个词时先区分清楚上下文。在通信技术交流里SIP基本都指向协议本身在苹果电脑的讨论里SIP多半是指系统保护机制。这篇博文全部围绕通信领域的SIP展开。1.2 掌握SIP核心信令后能做什么搞懂SIP核心信令最直接的好处是你能独立排查一大类VoIP问题。比如软电话注册不上服务器明明在线却一直提示Unauthorized或Timeout比如电话能打通但接通后只有单向语音比如通话到一半突然掉线抓包发现没有BYE消息——这些都是典型信令层面就能定位的问题。再往上走一层做通信系统集成、运维呼叫中心、对接运营商线路甚至研究WebRTC网关几乎都要懂一些SIP。很多IOT设备、门禁对讲、视频会议系统也都在用SIP只是外面包了一层自己的App。可以说只要设备之间要建立“会话”就绕不开这套信令语言。这篇文章不是教科书式的翻译RFC而是把实际调试中最常用的信令流程挑出来带上完整报文示例覆盖消息结构、注册、呼叫、鉴权、SDP协商、抓包排查这几个方向。读完后你可以拿着Wireshark自己抓包比对着报文看那种“看得懂每一行”的感觉比背十遍协议都要管用。1.3 学习前的装备清单准备动手实验之前先列一个工具清单都是我在实际调试中反复用到的Wireshark抓包分析必备过滤sip就能看到信令过滤rtp就能看到媒体流。一个SIP软电话Windows用MicroSIP很方便安卓上推荐Zoiper或Linphone。一个可用的SIP服务端如果只是练手用FreeSWITCH或Asterisk自建就行本地局域网就够跑通全流程。简单的信令生成工具sipsak或SIPp可以手工构造报文适合针对某个流程做压力测或功能验证。一台能跑命令行的机器Linux或macOS都行Windows下装WSL也很顺手。没有现成服务器也没关系很多在线SIP服务器提供免费注册测试账号你只需要一个软电话和一个公共网络就能看到真实的REGISTER与INVITE交互。真实环境抓到的报文比任何模拟器都更有说服力。2. SIP消息结构看懂信令先看懂文本格式2.1 一条SIP消息由什么组成SIP是文本协议报文长得很像HTTP。你打开抓包文件看到的消息基本分两部分起始行和头域空行之后是可选的报文体。起始行有两种请求消息用请求行响应消息用状态行。一个典型的注册请求长这样REGISTER sip:voip.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-abc123;rport Max-Forwards: 70 From: sip:1001voip.example.com;tagabc To: sip:1001voip.example.com Call-ID: 123456192.168.1.100 CSeq: 1 REGISTER Contact: sip:1001192.168.1.100:5060;expires600 Content-Length: 0请求行的三段分别是方法名REGISTER、请求URI sip:voip.example.com:5060、协议版本SIP/2.0。响应消息的状态行则是SIP/2.0、状态码、原因短语例如SIP/2.0 200 OK。头域承担了绝大部分信息。Via记录请求经过的路径和分支标识From和To表示主被叫逻辑地址Call-ID是整个会话的身份证CSeq是命令序号Contact告诉对方“后续消息往哪里发”。这些头域必须全部理解到位缺一个流程都可能断。报文体通常用来携带SDPSession Description Protocol也就是媒体描述信息。注册消息一般没有SDP但INVITE消息几乎必有因为你要告诉对方“我能用什么编码、我的IP和端口是多少”。所以消息结构可以概括成起始行说明动作头域提供路由和身份报文体协商媒体。2.2 核心请求方法注册、呼叫、释放、查询、消息SIP协议定义了好几个请求方法但日常遇到频率最高的是这几个REGISTER注册把“我是谁、我在哪、我能活多久”告诉服务器。INVITE邀请对方加入会话是发起呼叫的核心方法。ACK确认配合INVITE的最终响应使用尤其在2xx应答后必须发送。BYE挂断结束已经建立的会话。CANCEL取消还没有最终应答的呼叫可以用来取消比如对方还在振铃时你按了挂断。OPTIONS查询能力常用于探测服务器或终端是否在线、支持什么编码。SUBSCRIBE/NOTIFY订阅和通知常用于呈现状态Presence比如对方是否在线。INFO传输带内信息比如按键的DTMF有时用INFO传递。UPDATE更新会话参数在呼叫建立过程中可以提前修改媒体信息。REFER转移呼叫比如把正在通话的对方转给第三方。从这些方法能看出SIP的设计思路一个协议只负责“会话的创建、修改和终止”不负责音频数据的搬运。音频走RTP信令只做调度。这也是为什么SIP经常和RTP、RTCP、SDP组合在一起讨论。2.3 响应码速查从1xx到6xx到底在说什么SIP响应码分类和HTTP很像见到数字基本能猜个大概状态码段含义常见例子1xx临时响应表示请求正在处理中100 Trying、180 Ringing、183 Session Progress2xx成功200 OK3xx重定向需要到别处继续302 Moved Temporarily4xx客户端错误请求本身有问题401 Unauthorized、403 Forbidden、404 Not Found、408 Request Timeout、486 Busy Here5xx服务器错误500 Server Internal Error、503 Service Unavailable6xx全局失败600 Busy Everywhere、603 Decline你只要记住一条1xx是过程提醒2xx是成功4xx是客户端搞错了5xx是服务器不行。真正做排查时4xx最常见其中401和408又是重灾区。401不是故障它就是正常的鉴权挑战下面注册流程会展开讲。3. 三个最核心的流程注册、呼叫、挂断3.1 注册流程与摘要鉴权为什么401不是错误很多人第一次抓注册包看到401就以为注册失败了实际恰恰相反。SIP的注册经常是先不带密码请求一次服务器返回401带一个挑战challenge客户端再带着摘要信息重发REGISTER最后服务器返回200。这有点像进小区门禁你先按一下门铃门禁问你“密码是多少”你再输入密码门才开。先看第一段请求REGISTER sip:voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-74bf9c;rport Max-Forwards: 70 From: sip:1001voip.example.com;tagabc123 To: sip:1001voip.example.com Call-ID: 5a1c2b3d192.168.1.100 CSeq: 1 REGISTER Contact: sip:1001192.168.1.100:5060;expires600 Content-Length: 0服务器回应的401SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-74bf9c;rport5060 From: sip:1001voip.example.com;tagabc123 To: sip:1001voip.example.com;tagserver-tag-99 Call-ID: 5a1c2b3d192.168.1.100 CSeq: 1 REGISTER WWW-Authenticate: Digest realmvoip.example.com, nonceaB3dEfGhIjK, algorithmMD5 Content-Length: 0注意这里WWW-Authenticate头域里的realm和nonce这就是服务器发来的挑战。客户端拿到后根据用户名、密码、nonce、URI算出一个response再重发REGISTERREGISTER sip:voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-8821aa;rport Max-Forwards: 70 From: sip:1001voip.example.com;tagabc123 To: sip:1001voip.example.com Call-ID: 5a1c2b3d192.168.1.100 CSeq: 2 REGISTER Contact: sip:1001192.168.1.100:5060;expires600 Authorization: Digest username1001, realmvoip.example.com, nonceaB3dEfGhIjK, urisip:voip.example.com, responsefedcba9876543210abcdef0123456789, algorithmMD5 Content-Length: 0然后服务器回复200 OK注册完成。要点Call-ID没变但CSeq从1变成了2。Via里的branch变了这是每一条新消息都要重新生成的分支标识。Contact里的IP和端口就是服务器后续联系你的地址很多NAT环境下这里填错会导致后续呼叫收不到INVITE。响应值的计算后面我会单独讲它是摘要鉴权的核心。现在你只需要理解流程是“无凭证请求-挑战-带凭证再请求-成功”的循环。3.2 呼叫建立流程INVITE、100、180、200、ACK的顺序注册完成后最常用的就是呼叫流程。主叫A呼叫被叫B典型的信令序列是A发送INVITE服务器返回100 Trying被叫终端振铃时返回180 Ringing被叫接起时返回200 OK主叫收到200后立即回ACK然后双方开始走RTP语音流。如果哪一步断了呼叫就建立不起来。先看主叫发出的INVITEINVITE sip:1002voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport Max-Forwards: 70 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Contact: sip:1001192.168.1.100:5060 Content-Type: application/sdp Content-Length: 155 v0 oalice 2890844526 2890844526 IN IP4 192.168.1.100 s- cIN IP4 192.168.1.100 t0 0 maudio 49170 RTP/AVP 0 8 101 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000 artpmap:101 telephone-event/8000 afmtp:101 0-16这里的关键信息请求行的方法是INVITETo头域填的是被叫号码SDP里列出主叫能接收音频的IP是192.168.1.100、RTP端口是49170支持的编码有PCMUG.711μ律、PCMAG.711a律和DTMF事件。这些就是媒体协商的基础。服务器收到INVITE后的响应通常是SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport5060 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Content-Length: 0100 Trying可能由代理服务器发也可能由下一跳发作用是告诉主叫“消息我已经收到正在处理中你别着急重发”。被叫终端振铃时会经过服务器返回180 RingingSIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport5060 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com;tagbob-tag-77 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Contact: sip:1002192.168.1.200:5060 Content-Length: 0被叫接起返回200 OK并且会带上被叫侧的SDP。注意这里SDP的IP和端口已经变成了被叫的地址SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport5060 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com;tagbob-tag-77 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Contact: sip:1002192.168.1.200:5060 Content-Type: application/sdp Content-Length: 148 v0 obob 2890844526 2890844526 IN IP4 192.168.1.200 s- cIN IP4 192.168.1.200 t0 0 maudio 51922 RTP/AVP 0 101 artpmap:0 PCMU/8000 artpmap:101 telephone-event/8000 afmtp:101 0-16主叫收到200 OK后必须立刻发送ACK。对于2xx响应ACK是端到端逐跳发送的这个细节特别关键。如果ACK丢了或没发服务器会认为主叫没收到200可能重发200导致呼叫状态卡在半路ACK sip:1002192.168.1.200:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-11aa22;rport Max-Forwards: 70 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com;tagbob-tag-77 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 ACK Content-Length: 0注意CSeq还是1方法变成了ACK。到这里会话建立完成双方开始走RTP。所以核心信令的发音顺序是INVITE挖井100/180报进度200 OK表示水来了ACK是“我收到了开始喝”。3.3 呼叫释放BYE和CANCEL分别什么场景用通话结束挂断电话最常见的方式是发起方发送BYE。BYE是已经建立的会话里的动作由主叫或被叫任意一侧发起。比如被叫先挂断BYE sip:1001192.168.1.100:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.200:5060;branchz9hG4bK-55fe77;rport Max-Forwards: 70 From: Bob sip:1002voip.example.com;tagbob-tag-77 To: Alice sip:1001voip.example.com;tagalice-tag-001 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 BYE Content-Length: 0这里From/To里的tag和INVITE阶段一模一样Call-ID也一模一样CSeq重新从1开始计数。对方收到后返回200 OK通话正式结束。CANCEL则完全不一样。它用在呼叫还没最终应答前比如对方还在振铃你按了挂断这时发的是CANCEL而不是BYE。CANCEL请求针对的是之前发出的INVITE需要把CSeq标成和INVITE一样的方法序号例如CANCEL sip:1002voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-77aa11;rport Max-Forwards: 70 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 CANCEL Content-Length: 0服务器会对CANCEL返回200 OK同时对之前的INVITE返回487 Request Terminated。收到487后主叫还需要对这个非2xx最终响应发ACK流程才干净。很多人在这里漏了ACK导致调试日志里出现一堆重传。我实际调试中经常遇到有人把BYE和CANCEL搞混会话还没建起来就发BYE被叫还没应答就发CANCEL却得不到200。记住一句口诀建立后的通话挂断用BYE建立过程中的取消用CANCEL。4. 核心头域与媒体协商藏在细节里的坑4.1 头域逐个拆解Via、Contact、Route、Record-RouteSIP头域非常多但核心排障只需要吃透这几个。Via头域记录信令路径。每经过一个代理就会增加一个Via条目响应消息会沿着Via列表原路返回。它里面的branch参数是事务标识必须全局唯一RFC 3261建议以z9hG4bK开头。rport参数的意义很大尤其在NAT场景下它让接收方知道请求的真实来源端口。如果你的Via里没有rport排查NAT问题时往往两眼一抹黑。Contact头域告诉对方“我以后在哪里收消息”。注册时Contact填的是终端自己的地址并带expires表示注册有效期INVITE时Contact填的是终端接收后续请求的地址200 OK里的Contact则是被叫希望后续请求发往的地址。很多单向注册问题就是Contact里填了内网IP服务器按这个IP发消息根本到不了终端。From和To相对好理解一个标识主叫逻辑身份一个标识被叫逻辑身份。注意里面可以带tag参数tag是对话标识同一个通话里双方用自己的tag区分不同的会话。Call-ID是整个对话的唯一标识加上From tag和To tag三件套一起确定一个对话。CSeq是命令序号“方法名序号”组合起来防止重复和乱序。Route和Record-Route是代理路由相关。Record-Route是代理服务器为了“留在信令路径上”而加的头域常见于呼叫中心或计费场景。如果代理想看到BYE消息它就需要在INVITE的200 OK里加上Record-Route让后续BYE也经过自己。反之如果不想让BYE经过代理可以用拓扑隐藏等手段让代理不出现在Record-Route里。实际调试时看到BYE直接端到端而代理完全不知情多半是Record-Route没生效。4.2 SDP协商通话用什么编码、传到哪里SIP的报文体通常是SDP媒体协商就靠它。SDP不是协议它是一套描述媒体会话的文本格式核心字段就那么几个v版本号一般就是0。o会话发起者信息包含用户名、会话ID、网络类型、地址类型和地址。s会话名称很多实现填“-”。c连接信息媒体流的IP地址。m媒体描述比如音频、端口号、传输协议、载荷类型列表。a属性行用来补充rtpmap、fmtp等编码信息。看一个实际例子v0 oalice 2890844526 2890844526 IN IP4 192.168.1.100 s- cIN IP4 192.168.1.100 t0 0 maudio 49170 RTP/AVP 0 8 101 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000 artpmap:101 telephone-event/8000 afmtp:101 0-16maudio 49170 RTP/AVP 0 8 101意思是这条媒体流是音频接收端口49170使用RTP/AVP协议支持的动态/静态载荷类型是0、8、101。载荷类型0对应PCMU8对应PCMA101需要看rtpmap才能知道是telephone-event。协商规则是Offer/Answer模型主叫在INVITE里给出一个SDP Offer被叫在200 OK里给出一个SDP Answer。Answer可以缩小选项但不能增加Offer里没出现的编码。如果被叫只支持PCMA而Offer只有PCMU协商就会失败或者被叫返回不支持的编码组合导致使用默认值。这也是为什么音质排查第一步就是看双方SDP里最终选定的载荷类型。媒体流地址和信令地址经常不同。很多网关有两个网口一个走信令一个走媒体或者信令经代理转发而媒体直连。你要是看到信令正常但没声音赶紧检查c行的IP和RTP端口是否可达再用抓包看UDP上的RTP流量。4.3 摘要鉴权算法MD5如何计算response前面注册流程提到了401和response这里展开讲一下摘要鉴权。SIP摘要鉴权基于HTTP DigestRFC 2617和RFC 3261都有描述。计算response需要四个输入用户名、密码、realm、nonce以及请求方法和请求URI。标准的MD5摘要算法分两步。第一步计算HA1HA1 MD5(username : realm : password)第二步计算HA2根据方法是REGISTER还是INVITE等不同HA2 MD5(method : uri)最后response MD5(HA1 : nonce : HA2)举个例子。假设username 1001realm voip.example.compassword secretnonce aB3dEfGhIjKmethod REGISTERuri sip:voip.example.com那么HA1就是MD5(1001:voip.example.com:secret)HA2就是MD5(REGISTER:sip:voip.example.com)再用这两个值拼上nonce算出最终response。这里有个容易出错的地方URI必须和请求行里的Request-URI一致不能随便填注册服务器的域名就完事。很多自己实现注册器的开发者在这里栽过跟头response算出来不对服务器一直401。另外一个常见坑是密码里的特殊字符冒号在摘要算法里是分隔符如果密码本身就含冒号标准上有专门的处理方式但大多数客户端实现并不完美最好避免使用冒号类特殊字符。有些服务器还会要求qop参数这时计算会更复杂需要加入cnonce和qop公式变成response MD5(HA1 : nonce : nc : cnonce : qop : HA2)如果你看到服务器WWW-Authenticate里有qopauth客户端重发的Authorization里就必须带nc、cnonce和qop否则服务器可能继续401。调试时先用普通密码、不带特殊字符的账号环境能少掉很多头发。5. 实战排查从抓包到定位问题的完整路径5.1 Wireshark抓包只看SIP和RTP信令排查离不开Wireshark。打开抓包文件后最常用的过滤表达式是sip这会把所有SIP消息过滤出来。如果信令太多可以加上IP或端口过滤sip ip.addr 192.168.1.100 sip udp.port 5060想看媒体流过滤RTPrtp单纯过滤rtp可能看不到RTP包的内容因为Wireshark需要知道它是音频流。你可以让Wireshark从SIP的SDP里解析RTP信息或者用Telephony菜单里的VoIP Calls视图它会按通话把信令和媒体整理成时序图非常直观。抓包时有几个细节本机环回抓包可能抓不到因为流量不经过物理网卡抓取远程服务器流量可以用SSH远程抓包再回传或者直接在服务器上用tcpdump抓tcpdump -i any -s 0 -w sip.pcap port 5060 or port 10000这里的10000是RTP端口范围示例实际按你的环境替换。抓包时间不要过长保持少量流量文件太大反而难分析。我自己的习惯是先看信令时序有没有重传再看关键消息的Via和Contact字段最后看SDP里的媒体地址。这三个点能覆盖八成问题。5.2 高频报错与解决办法把实际踩过的坑整理成表你可以对照着用现象可能原因解决办法REGISTER持续401密码错误、摘要计算错误、时间不同步导致nonce失效检查账号密码核对realm和nonce校正系统时间注册成功但收不到INVITENAT环境下Contact是内网地址或注册有效期过短开启NAT穿透检查Contact里填的地址修改expires时长INVITE发出后一直100 Trying直到408被叫地址不可达, 或中间代理转发失败检查被叫注册状态确认代理路由表用抓包定位消息卡在哪一跳493/403 Registration Not Allowed服务器禁止该IP注册或白名单限制检查服务器访问控制配置确认IP是否在白名单486 Busy Here被叫正在通话中或开启呼叫等待失败被叫挂断其他通话或服务器配置呼叫转接/等待振铃正常但接通后单通SDP协商选错了编码或RTP端口/防火墙不通抓包看协商结果检查RTP双向流排查防火墙对UDP端口的限制通话中途掉线没有BYE消息网络抖动导致注册过期或NAT映射失效开启NAT keepalive缩短注册周期检查路由器和会话超时策略408 Request Timeout是特别常见的。当INVITE发出后服务器在规定时间内没收到最终响应就认为对端不可达。抓包时你会看到INVITE被重传了好几次最后仍是失败。这时候按时间线把信令排出来看看INVITE到底送到了哪里是代理没转发还是被叫终端没响应。单通问题的排查思路也是固定套路先看SDP确定双方协商出的编码和RTP地址端口再从主被叫两侧分别抓包确认RTP包是否到达对端如果RTP到了但没声音大概率是编码不匹配或payload type映射错误如果根本没到查防火墙和NAT。5.3 NAT和局域网外的信令难题在家用网络或者企业分机场景终端都在NAT后面SIP信令就特别容易出问题。原因在于SIP报文里写的是你的内网IP比如192.168.1.100但服务器看到的实际来源IP是公网IP加映射端口。如果服务器只按报文里的Contact发消息当然找不到你。解决思路有三类。第一类是客户端侧发送NAT keepalive定时往服务器发OPTIONS或空包让NAT映射保持不被回收。第二类是服务器或网关使用rport机制通过Via头域里的rport感知真实来源端口回包时不盲目按Contact发。第三类是用STUN/TURN服务器做媒体地址探测和转发把Contact里的IP换成公网映射地址。很多软电话都有“通过NAT穿透”选项勾上之后会自动使用STUN发现公网地址写进Contact。但这不是万能的企业防火墙封端口、对称型NAT、运营商对大端口UDP限速都会让STUN失效。真实环境里见过太多公网IP端口被运营商封掉的情况最后只能改用TCP SIP或媒体走TURN甚至直接换专线。我自己调试时的体会是NAT问题不能只看信令必须结合媒体流一起看。信令通了但RTP不通往往就是RTP端口映射没有保持。这时候在路由器上配置端口映射或者使用服务器侧的媒体中继比折腾几百个信令参数更有效。6. 工具选择与调试环境软电话和服务端怎么搭6.1 安卓/桌面软电话推荐搜“SIP软电话安卓版”的朋友大概率是在找一个能绑定SIP账号、直接拨打电话的App。常用的安卓端客户有Zoiper、Linphone、Groundwire、Sipdroid。Zoiper的注册向导比较友好支持账号、密码、服务器地址一步步配也内置了编解码选择适合新手。Linphone是开源项目功能完整而且它自带的测试服务器可以用来练手。如果你要测试更多高级功能比如BLF按键、多线路Groundwire做得更细但收费。桌面端我更习惯MicroSIP和Zoiper。MicroSIP是Windows平台的小程序体积小配置简单适合快速验证。Linphone桌面版跨平台附带SIP账号演示服务器学习环境搭建起来非常快。另外还有Bria功能全面但偏向企业用户。选软电话的时候重点关注三点协议支持是否完整SIP over UDP/TCP/TLS、编解码是否可调至少能关掉不想要的编码、日志和抓包是否方便能导出日志最好。很多所谓“免费版”软电话不支持TLS这在生产环境里是个隐患。6.2 测试环境搭建想深入学习核心信令强烈建议自己搭一套测试环境。最简方案是装一个Asterisk或FreeSWITCH局域网内跑通注册和呼叫。以FreeSWITCH为例默认带了一堆内置分机比如1000-1019密码和分机号相同。只需把软电话注册到服务器IP就能立即体验完整的INVITE流程。如果想看更细的信令可以安装Kamailio做纯SIP代理。它本身不带媒体处理适合观察信令转发路径。配合sngrep工具终端下的SIP抓包器可以按呼叫来查看所有报文比Wireshark更聚焦在信令时序上。我建议的学习路径是先用软电话注册FreeSWITCH跑通注册和呼叫再用Wireshark抓包把注册流程和呼叫流程的报文逐行看一遍然后自己用SIPp或sipsak手工构造INVITE尝试在非标准环境下制造故障最后再回到抓包去验证你的判断。这个循环走一遍核心信令基本就内化了。7. 个人心得SIP排障的几条血泪经验踩了那么多次坑之后有几条经验我觉得比背报文更值钱。第一永远先确认时间同步。SIP鉴权里的nonce很多带时效终端和服务器时间差太大会导致401刷屏。我遇到过一次客户反复说注册不上排查半天最后发现是电话机系统时间慢了两年。先同步时间能省一大半事。第二抓包之前先明确“你是要看信令还是看媒体”。信令就看5060端口媒体就看RTP端口范围混在一起看特别容易懵。用Wireshark的VoIP Calls视图做整体时间线再用过滤器钻到具体消息里效率最高。第三别迷信软电话界面上的“已注册”绿点。它可能只是用OPTIONS探测通的不代表INVITE能到。真正确认注册有效要看服务器上有没有这个分机的AOR记录以及Contact里填的是不是可路由地址。第四调试时尽量关掉TLS先用明文UDP拉通全流程。信令加密后抓包看不到明文学习阶段会走很多弯路。生产环境再启用TLS这是学习和排查的顺序问题。第五遇到奇怪的“偶发”掉线多半跟NAT映射超时有关。终端注册周期不要太长很多服务器默认3600秒但家用路由器UDP映射可能30秒就回收了。在路由器和服务器之间找个折中的keepalive策略比如60到120秒发一次OPTIONS稳定程度明显不一样。SIP核心信令不复杂但它绕。绕在流程里有鉴权、有多跳转发、有媒体协商、有NAT每一层都可能出幺蛾子。你只要把注册、呼叫、挂断这三条链路反复抓包研读几遍把Via、Contact、CSeq、SDP这几个核心字段吃透再碰到VoIP报错基本不会慌。真要说还有什么秘笈那就是多抓包、多看时序、多拿自己的终端和服务端做实验——纸上谈兵永远不如亲手拉通一个呼叫。
做VoIP的同学或者刚接触SIP协议的朋友应该都有过这种经历明明照着网上教程配置好了软电话和服务器注册状态却总在401和200之间来回拉扯呼叫对方时屏幕上永远转圈最后收到一个408抓包看到一堆信令却分不清哪条有用。如果你也想把SIP核心信令彻底搞明白这篇分享就是为你准备的。SIP不是那种看完一篇教程就能完全吃透的协议它和HTTP一样是文本协议但你真正上手调试时才会发现注册、呼叫、挂断、转接、补缺每一步都有对应的信令组合顺序错一个、头域少一个通话就可能起不来。这篇文章我会从消息结构讲起把最常见的注册流程和呼叫流程拆成一行一行来讲再把手头排查过的坑和常用工具一起整理出来希望能帮你少走点弯路。1. 项目概述为什么说SIP核心信令是所有VoIP应用的“地基”1.1 先来认人两个完全不一样的“SIP”先说一个容易让人懵的点。很多人搜“SIP”会搜到“M2 Mac关闭SIP方法”这类热搜词那个SIP是macOS的System Integrity Protection系统完整性保护机制跟通信协议八竿子打不着。具体来说它是苹果系统用于防止恶意代码修改系统文件的安全机制开发者为了调试或安装某些驱动偶尔需要临时关闭它。而那和今天要讲的通信SIP完全不同。我们说的SIP全称是Session Initiation Protocol会话初始协议由RFC 3261定义。它是VoIPVoice over IP世界里最核心的信令协议之一负责两件事找到对方并协商好怎么通话。打电话时你听到的拨号音、对方手机的振铃、接通后的语音流背后都离不开SIP信令在调度。你可以把它理解为通信双方之间的“前台接待”——谁打给谁、什么时候接、用什么编码、怎么断开都由它传递。所以当你再看到“Mac SIP”这个词时先区分清楚上下文。在通信技术交流里SIP基本都指向协议本身在苹果电脑的讨论里SIP多半是指系统保护机制。这篇博文全部围绕通信领域的SIP展开。1.2 掌握SIP核心信令后能做什么搞懂SIP核心信令最直接的好处是你能独立排查一大类VoIP问题。比如软电话注册不上服务器明明在线却一直提示Unauthorized或Timeout比如电话能打通但接通后只有单向语音比如通话到一半突然掉线抓包发现没有BYE消息——这些都是典型信令层面就能定位的问题。再往上走一层做通信系统集成、运维呼叫中心、对接运营商线路甚至研究WebRTC网关几乎都要懂一些SIP。很多IOT设备、门禁对讲、视频会议系统也都在用SIP只是外面包了一层自己的App。可以说只要设备之间要建立“会话”就绕不开这套信令语言。这篇文章不是教科书式的翻译RFC而是把实际调试中最常用的信令流程挑出来带上完整报文示例覆盖消息结构、注册、呼叫、鉴权、SDP协商、抓包排查这几个方向。读完后你可以拿着Wireshark自己抓包比对着报文看那种“看得懂每一行”的感觉比背十遍协议都要管用。1.3 学习前的装备清单准备动手实验之前先列一个工具清单都是我在实际调试中反复用到的Wireshark抓包分析必备过滤sip就能看到信令过滤rtp就能看到媒体流。一个SIP软电话Windows用MicroSIP很方便安卓上推荐Zoiper或Linphone。一个可用的SIP服务端如果只是练手用FreeSWITCH或Asterisk自建就行本地局域网就够跑通全流程。简单的信令生成工具sipsak或SIPp可以手工构造报文适合针对某个流程做压力测或功能验证。一台能跑命令行的机器Linux或macOS都行Windows下装WSL也很顺手。没有现成服务器也没关系很多在线SIP服务器提供免费注册测试账号你只需要一个软电话和一个公共网络就能看到真实的REGISTER与INVITE交互。真实环境抓到的报文比任何模拟器都更有说服力。2. SIP消息结构看懂信令先看懂文本格式2.1 一条SIP消息由什么组成SIP是文本协议报文长得很像HTTP。你打开抓包文件看到的消息基本分两部分起始行和头域空行之后是可选的报文体。起始行有两种请求消息用请求行响应消息用状态行。一个典型的注册请求长这样REGISTER sip:voip.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-abc123;rport Max-Forwards: 70 From: sip:1001voip.example.com;tagabc To: sip:1001voip.example.com Call-ID: 123456192.168.1.100 CSeq: 1 REGISTER Contact: sip:1001192.168.1.100:5060;expires600 Content-Length: 0请求行的三段分别是方法名REGISTER、请求URI sip:voip.example.com:5060、协议版本SIP/2.0。响应消息的状态行则是SIP/2.0、状态码、原因短语例如SIP/2.0 200 OK。头域承担了绝大部分信息。Via记录请求经过的路径和分支标识From和To表示主被叫逻辑地址Call-ID是整个会话的身份证CSeq是命令序号Contact告诉对方“后续消息往哪里发”。这些头域必须全部理解到位缺一个流程都可能断。报文体通常用来携带SDPSession Description Protocol也就是媒体描述信息。注册消息一般没有SDP但INVITE消息几乎必有因为你要告诉对方“我能用什么编码、我的IP和端口是多少”。所以消息结构可以概括成起始行说明动作头域提供路由和身份报文体协商媒体。2.2 核心请求方法注册、呼叫、释放、查询、消息SIP协议定义了好几个请求方法但日常遇到频率最高的是这几个REGISTER注册把“我是谁、我在哪、我能活多久”告诉服务器。INVITE邀请对方加入会话是发起呼叫的核心方法。ACK确认配合INVITE的最终响应使用尤其在2xx应答后必须发送。BYE挂断结束已经建立的会话。CANCEL取消还没有最终应答的呼叫可以用来取消比如对方还在振铃时你按了挂断。OPTIONS查询能力常用于探测服务器或终端是否在线、支持什么编码。SUBSCRIBE/NOTIFY订阅和通知常用于呈现状态Presence比如对方是否在线。INFO传输带内信息比如按键的DTMF有时用INFO传递。UPDATE更新会话参数在呼叫建立过程中可以提前修改媒体信息。REFER转移呼叫比如把正在通话的对方转给第三方。从这些方法能看出SIP的设计思路一个协议只负责“会话的创建、修改和终止”不负责音频数据的搬运。音频走RTP信令只做调度。这也是为什么SIP经常和RTP、RTCP、SDP组合在一起讨论。2.3 响应码速查从1xx到6xx到底在说什么SIP响应码分类和HTTP很像见到数字基本能猜个大概状态码段含义常见例子1xx临时响应表示请求正在处理中100 Trying、180 Ringing、183 Session Progress2xx成功200 OK3xx重定向需要到别处继续302 Moved Temporarily4xx客户端错误请求本身有问题401 Unauthorized、403 Forbidden、404 Not Found、408 Request Timeout、486 Busy Here5xx服务器错误500 Server Internal Error、503 Service Unavailable6xx全局失败600 Busy Everywhere、603 Decline你只要记住一条1xx是过程提醒2xx是成功4xx是客户端搞错了5xx是服务器不行。真正做排查时4xx最常见其中401和408又是重灾区。401不是故障它就是正常的鉴权挑战下面注册流程会展开讲。3. 三个最核心的流程注册、呼叫、挂断3.1 注册流程与摘要鉴权为什么401不是错误很多人第一次抓注册包看到401就以为注册失败了实际恰恰相反。SIP的注册经常是先不带密码请求一次服务器返回401带一个挑战challenge客户端再带着摘要信息重发REGISTER最后服务器返回200。这有点像进小区门禁你先按一下门铃门禁问你“密码是多少”你再输入密码门才开。先看第一段请求REGISTER sip:voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-74bf9c;rport Max-Forwards: 70 From: sip:1001voip.example.com;tagabc123 To: sip:1001voip.example.com Call-ID: 5a1c2b3d192.168.1.100 CSeq: 1 REGISTER Contact: sip:1001192.168.1.100:5060;expires600 Content-Length: 0服务器回应的401SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-74bf9c;rport5060 From: sip:1001voip.example.com;tagabc123 To: sip:1001voip.example.com;tagserver-tag-99 Call-ID: 5a1c2b3d192.168.1.100 CSeq: 1 REGISTER WWW-Authenticate: Digest realmvoip.example.com, nonceaB3dEfGhIjK, algorithmMD5 Content-Length: 0注意这里WWW-Authenticate头域里的realm和nonce这就是服务器发来的挑战。客户端拿到后根据用户名、密码、nonce、URI算出一个response再重发REGISTERREGISTER sip:voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-8821aa;rport Max-Forwards: 70 From: sip:1001voip.example.com;tagabc123 To: sip:1001voip.example.com Call-ID: 5a1c2b3d192.168.1.100 CSeq: 2 REGISTER Contact: sip:1001192.168.1.100:5060;expires600 Authorization: Digest username1001, realmvoip.example.com, nonceaB3dEfGhIjK, urisip:voip.example.com, responsefedcba9876543210abcdef0123456789, algorithmMD5 Content-Length: 0然后服务器回复200 OK注册完成。要点Call-ID没变但CSeq从1变成了2。Via里的branch变了这是每一条新消息都要重新生成的分支标识。Contact里的IP和端口就是服务器后续联系你的地址很多NAT环境下这里填错会导致后续呼叫收不到INVITE。响应值的计算后面我会单独讲它是摘要鉴权的核心。现在你只需要理解流程是“无凭证请求-挑战-带凭证再请求-成功”的循环。3.2 呼叫建立流程INVITE、100、180、200、ACK的顺序注册完成后最常用的就是呼叫流程。主叫A呼叫被叫B典型的信令序列是A发送INVITE服务器返回100 Trying被叫终端振铃时返回180 Ringing被叫接起时返回200 OK主叫收到200后立即回ACK然后双方开始走RTP语音流。如果哪一步断了呼叫就建立不起来。先看主叫发出的INVITEINVITE sip:1002voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport Max-Forwards: 70 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Contact: sip:1001192.168.1.100:5060 Content-Type: application/sdp Content-Length: 155 v0 oalice 2890844526 2890844526 IN IP4 192.168.1.100 s- cIN IP4 192.168.1.100 t0 0 maudio 49170 RTP/AVP 0 8 101 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000 artpmap:101 telephone-event/8000 afmtp:101 0-16这里的关键信息请求行的方法是INVITETo头域填的是被叫号码SDP里列出主叫能接收音频的IP是192.168.1.100、RTP端口是49170支持的编码有PCMUG.711μ律、PCMAG.711a律和DTMF事件。这些就是媒体协商的基础。服务器收到INVITE后的响应通常是SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport5060 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Content-Length: 0100 Trying可能由代理服务器发也可能由下一跳发作用是告诉主叫“消息我已经收到正在处理中你别着急重发”。被叫终端振铃时会经过服务器返回180 RingingSIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport5060 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com;tagbob-tag-77 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Contact: sip:1002192.168.1.200:5060 Content-Length: 0被叫接起返回200 OK并且会带上被叫侧的SDP。注意这里SDP的IP和端口已经变成了被叫的地址SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-98c0f1;rport5060 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com;tagbob-tag-77 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 INVITE Contact: sip:1002192.168.1.200:5060 Content-Type: application/sdp Content-Length: 148 v0 obob 2890844526 2890844526 IN IP4 192.168.1.200 s- cIN IP4 192.168.1.200 t0 0 maudio 51922 RTP/AVP 0 101 artpmap:0 PCMU/8000 artpmap:101 telephone-event/8000 afmtp:101 0-16主叫收到200 OK后必须立刻发送ACK。对于2xx响应ACK是端到端逐跳发送的这个细节特别关键。如果ACK丢了或没发服务器会认为主叫没收到200可能重发200导致呼叫状态卡在半路ACK sip:1002192.168.1.200:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-11aa22;rport Max-Forwards: 70 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com;tagbob-tag-77 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 ACK Content-Length: 0注意CSeq还是1方法变成了ACK。到这里会话建立完成双方开始走RTP。所以核心信令的发音顺序是INVITE挖井100/180报进度200 OK表示水来了ACK是“我收到了开始喝”。3.3 呼叫释放BYE和CANCEL分别什么场景用通话结束挂断电话最常见的方式是发起方发送BYE。BYE是已经建立的会话里的动作由主叫或被叫任意一侧发起。比如被叫先挂断BYE sip:1001192.168.1.100:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.200:5060;branchz9hG4bK-55fe77;rport Max-Forwards: 70 From: Bob sip:1002voip.example.com;tagbob-tag-77 To: Alice sip:1001voip.example.com;tagalice-tag-001 Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 BYE Content-Length: 0这里From/To里的tag和INVITE阶段一模一样Call-ID也一模一样CSeq重新从1开始计数。对方收到后返回200 OK通话正式结束。CANCEL则完全不一样。它用在呼叫还没最终应答前比如对方还在振铃你按了挂断这时发的是CANCEL而不是BYE。CANCEL请求针对的是之前发出的INVITE需要把CSeq标成和INVITE一样的方法序号例如CANCEL sip:1002voip.example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branchz9hG4bK-77aa11;rport Max-Forwards: 70 From: Alice sip:1001voip.example.com;tagalice-tag-001 To: Bob sip:1002voip.example.com Call-ID: d3b2a1c4192.168.1.100 CSeq: 1 CANCEL Content-Length: 0服务器会对CANCEL返回200 OK同时对之前的INVITE返回487 Request Terminated。收到487后主叫还需要对这个非2xx最终响应发ACK流程才干净。很多人在这里漏了ACK导致调试日志里出现一堆重传。我实际调试中经常遇到有人把BYE和CANCEL搞混会话还没建起来就发BYE被叫还没应答就发CANCEL却得不到200。记住一句口诀建立后的通话挂断用BYE建立过程中的取消用CANCEL。4. 核心头域与媒体协商藏在细节里的坑4.1 头域逐个拆解Via、Contact、Route、Record-RouteSIP头域非常多但核心排障只需要吃透这几个。Via头域记录信令路径。每经过一个代理就会增加一个Via条目响应消息会沿着Via列表原路返回。它里面的branch参数是事务标识必须全局唯一RFC 3261建议以z9hG4bK开头。rport参数的意义很大尤其在NAT场景下它让接收方知道请求的真实来源端口。如果你的Via里没有rport排查NAT问题时往往两眼一抹黑。Contact头域告诉对方“我以后在哪里收消息”。注册时Contact填的是终端自己的地址并带expires表示注册有效期INVITE时Contact填的是终端接收后续请求的地址200 OK里的Contact则是被叫希望后续请求发往的地址。很多单向注册问题就是Contact里填了内网IP服务器按这个IP发消息根本到不了终端。From和To相对好理解一个标识主叫逻辑身份一个标识被叫逻辑身份。注意里面可以带tag参数tag是对话标识同一个通话里双方用自己的tag区分不同的会话。Call-ID是整个对话的唯一标识加上From tag和To tag三件套一起确定一个对话。CSeq是命令序号“方法名序号”组合起来防止重复和乱序。Route和Record-Route是代理路由相关。Record-Route是代理服务器为了“留在信令路径上”而加的头域常见于呼叫中心或计费场景。如果代理想看到BYE消息它就需要在INVITE的200 OK里加上Record-Route让后续BYE也经过自己。反之如果不想让BYE经过代理可以用拓扑隐藏等手段让代理不出现在Record-Route里。实际调试时看到BYE直接端到端而代理完全不知情多半是Record-Route没生效。4.2 SDP协商通话用什么编码、传到哪里SIP的报文体通常是SDP媒体协商就靠它。SDP不是协议它是一套描述媒体会话的文本格式核心字段就那么几个v版本号一般就是0。o会话发起者信息包含用户名、会话ID、网络类型、地址类型和地址。s会话名称很多实现填“-”。c连接信息媒体流的IP地址。m媒体描述比如音频、端口号、传输协议、载荷类型列表。a属性行用来补充rtpmap、fmtp等编码信息。看一个实际例子v0 oalice 2890844526 2890844526 IN IP4 192.168.1.100 s- cIN IP4 192.168.1.100 t0 0 maudio 49170 RTP/AVP 0 8 101 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000 artpmap:101 telephone-event/8000 afmtp:101 0-16maudio 49170 RTP/AVP 0 8 101意思是这条媒体流是音频接收端口49170使用RTP/AVP协议支持的动态/静态载荷类型是0、8、101。载荷类型0对应PCMU8对应PCMA101需要看rtpmap才能知道是telephone-event。协商规则是Offer/Answer模型主叫在INVITE里给出一个SDP Offer被叫在200 OK里给出一个SDP Answer。Answer可以缩小选项但不能增加Offer里没出现的编码。如果被叫只支持PCMA而Offer只有PCMU协商就会失败或者被叫返回不支持的编码组合导致使用默认值。这也是为什么音质排查第一步就是看双方SDP里最终选定的载荷类型。媒体流地址和信令地址经常不同。很多网关有两个网口一个走信令一个走媒体或者信令经代理转发而媒体直连。你要是看到信令正常但没声音赶紧检查c行的IP和RTP端口是否可达再用抓包看UDP上的RTP流量。4.3 摘要鉴权算法MD5如何计算response前面注册流程提到了401和response这里展开讲一下摘要鉴权。SIP摘要鉴权基于HTTP DigestRFC 2617和RFC 3261都有描述。计算response需要四个输入用户名、密码、realm、nonce以及请求方法和请求URI。标准的MD5摘要算法分两步。第一步计算HA1HA1 MD5(username : realm : password)第二步计算HA2根据方法是REGISTER还是INVITE等不同HA2 MD5(method : uri)最后response MD5(HA1 : nonce : HA2)举个例子。假设username 1001realm voip.example.compassword secretnonce aB3dEfGhIjKmethod REGISTERuri sip:voip.example.com那么HA1就是MD5(1001:voip.example.com:secret)HA2就是MD5(REGISTER:sip:voip.example.com)再用这两个值拼上nonce算出最终response。这里有个容易出错的地方URI必须和请求行里的Request-URI一致不能随便填注册服务器的域名就完事。很多自己实现注册器的开发者在这里栽过跟头response算出来不对服务器一直401。另外一个常见坑是密码里的特殊字符冒号在摘要算法里是分隔符如果密码本身就含冒号标准上有专门的处理方式但大多数客户端实现并不完美最好避免使用冒号类特殊字符。有些服务器还会要求qop参数这时计算会更复杂需要加入cnonce和qop公式变成response MD5(HA1 : nonce : nc : cnonce : qop : HA2)如果你看到服务器WWW-Authenticate里有qopauth客户端重发的Authorization里就必须带nc、cnonce和qop否则服务器可能继续401。调试时先用普通密码、不带特殊字符的账号环境能少掉很多头发。5. 实战排查从抓包到定位问题的完整路径5.1 Wireshark抓包只看SIP和RTP信令排查离不开Wireshark。打开抓包文件后最常用的过滤表达式是sip这会把所有SIP消息过滤出来。如果信令太多可以加上IP或端口过滤sip ip.addr 192.168.1.100 sip udp.port 5060想看媒体流过滤RTPrtp单纯过滤rtp可能看不到RTP包的内容因为Wireshark需要知道它是音频流。你可以让Wireshark从SIP的SDP里解析RTP信息或者用Telephony菜单里的VoIP Calls视图它会按通话把信令和媒体整理成时序图非常直观。抓包时有几个细节本机环回抓包可能抓不到因为流量不经过物理网卡抓取远程服务器流量可以用SSH远程抓包再回传或者直接在服务器上用tcpdump抓tcpdump -i any -s 0 -w sip.pcap port 5060 or port 10000这里的10000是RTP端口范围示例实际按你的环境替换。抓包时间不要过长保持少量流量文件太大反而难分析。我自己的习惯是先看信令时序有没有重传再看关键消息的Via和Contact字段最后看SDP里的媒体地址。这三个点能覆盖八成问题。5.2 高频报错与解决办法把实际踩过的坑整理成表你可以对照着用现象可能原因解决办法REGISTER持续401密码错误、摘要计算错误、时间不同步导致nonce失效检查账号密码核对realm和nonce校正系统时间注册成功但收不到INVITENAT环境下Contact是内网地址或注册有效期过短开启NAT穿透检查Contact里填的地址修改expires时长INVITE发出后一直100 Trying直到408被叫地址不可达, 或中间代理转发失败检查被叫注册状态确认代理路由表用抓包定位消息卡在哪一跳493/403 Registration Not Allowed服务器禁止该IP注册或白名单限制检查服务器访问控制配置确认IP是否在白名单486 Busy Here被叫正在通话中或开启呼叫等待失败被叫挂断其他通话或服务器配置呼叫转接/等待振铃正常但接通后单通SDP协商选错了编码或RTP端口/防火墙不通抓包看协商结果检查RTP双向流排查防火墙对UDP端口的限制通话中途掉线没有BYE消息网络抖动导致注册过期或NAT映射失效开启NAT keepalive缩短注册周期检查路由器和会话超时策略408 Request Timeout是特别常见的。当INVITE发出后服务器在规定时间内没收到最终响应就认为对端不可达。抓包时你会看到INVITE被重传了好几次最后仍是失败。这时候按时间线把信令排出来看看INVITE到底送到了哪里是代理没转发还是被叫终端没响应。单通问题的排查思路也是固定套路先看SDP确定双方协商出的编码和RTP地址端口再从主被叫两侧分别抓包确认RTP包是否到达对端如果RTP到了但没声音大概率是编码不匹配或payload type映射错误如果根本没到查防火墙和NAT。5.3 NAT和局域网外的信令难题在家用网络或者企业分机场景终端都在NAT后面SIP信令就特别容易出问题。原因在于SIP报文里写的是你的内网IP比如192.168.1.100但服务器看到的实际来源IP是公网IP加映射端口。如果服务器只按报文里的Contact发消息当然找不到你。解决思路有三类。第一类是客户端侧发送NAT keepalive定时往服务器发OPTIONS或空包让NAT映射保持不被回收。第二类是服务器或网关使用rport机制通过Via头域里的rport感知真实来源端口回包时不盲目按Contact发。第三类是用STUN/TURN服务器做媒体地址探测和转发把Contact里的IP换成公网映射地址。很多软电话都有“通过NAT穿透”选项勾上之后会自动使用STUN发现公网地址写进Contact。但这不是万能的企业防火墙封端口、对称型NAT、运营商对大端口UDP限速都会让STUN失效。真实环境里见过太多公网IP端口被运营商封掉的情况最后只能改用TCP SIP或媒体走TURN甚至直接换专线。我自己调试时的体会是NAT问题不能只看信令必须结合媒体流一起看。信令通了但RTP不通往往就是RTP端口映射没有保持。这时候在路由器上配置端口映射或者使用服务器侧的媒体中继比折腾几百个信令参数更有效。6. 工具选择与调试环境软电话和服务端怎么搭6.1 安卓/桌面软电话推荐搜“SIP软电话安卓版”的朋友大概率是在找一个能绑定SIP账号、直接拨打电话的App。常用的安卓端客户有Zoiper、Linphone、Groundwire、Sipdroid。Zoiper的注册向导比较友好支持账号、密码、服务器地址一步步配也内置了编解码选择适合新手。Linphone是开源项目功能完整而且它自带的测试服务器可以用来练手。如果你要测试更多高级功能比如BLF按键、多线路Groundwire做得更细但收费。桌面端我更习惯MicroSIP和Zoiper。MicroSIP是Windows平台的小程序体积小配置简单适合快速验证。Linphone桌面版跨平台附带SIP账号演示服务器学习环境搭建起来非常快。另外还有Bria功能全面但偏向企业用户。选软电话的时候重点关注三点协议支持是否完整SIP over UDP/TCP/TLS、编解码是否可调至少能关掉不想要的编码、日志和抓包是否方便能导出日志最好。很多所谓“免费版”软电话不支持TLS这在生产环境里是个隐患。6.2 测试环境搭建想深入学习核心信令强烈建议自己搭一套测试环境。最简方案是装一个Asterisk或FreeSWITCH局域网内跑通注册和呼叫。以FreeSWITCH为例默认带了一堆内置分机比如1000-1019密码和分机号相同。只需把软电话注册到服务器IP就能立即体验完整的INVITE流程。如果想看更细的信令可以安装Kamailio做纯SIP代理。它本身不带媒体处理适合观察信令转发路径。配合sngrep工具终端下的SIP抓包器可以按呼叫来查看所有报文比Wireshark更聚焦在信令时序上。我建议的学习路径是先用软电话注册FreeSWITCH跑通注册和呼叫再用Wireshark抓包把注册流程和呼叫流程的报文逐行看一遍然后自己用SIPp或sipsak手工构造INVITE尝试在非标准环境下制造故障最后再回到抓包去验证你的判断。这个循环走一遍核心信令基本就内化了。7. 个人心得SIP排障的几条血泪经验踩了那么多次坑之后有几条经验我觉得比背报文更值钱。第一永远先确认时间同步。SIP鉴权里的nonce很多带时效终端和服务器时间差太大会导致401刷屏。我遇到过一次客户反复说注册不上排查半天最后发现是电话机系统时间慢了两年。先同步时间能省一大半事。第二抓包之前先明确“你是要看信令还是看媒体”。信令就看5060端口媒体就看RTP端口范围混在一起看特别容易懵。用Wireshark的VoIP Calls视图做整体时间线再用过滤器钻到具体消息里效率最高。第三别迷信软电话界面上的“已注册”绿点。它可能只是用OPTIONS探测通的不代表INVITE能到。真正确认注册有效要看服务器上有没有这个分机的AOR记录以及Contact里填的是不是可路由地址。第四调试时尽量关掉TLS先用明文UDP拉通全流程。信令加密后抓包看不到明文学习阶段会走很多弯路。生产环境再启用TLS这是学习和排查的顺序问题。第五遇到奇怪的“偶发”掉线多半跟NAT映射超时有关。终端注册周期不要太长很多服务器默认3600秒但家用路由器UDP映射可能30秒就回收了。在路由器和服务器之间找个折中的keepalive策略比如60到120秒发一次OPTIONS稳定程度明显不一样。SIP核心信令不复杂但它绕。绕在流程里有鉴权、有多跳转发、有媒体协商、有NAT每一层都可能出幺蛾子。你只要把注册、呼叫、挂断这三条链路反复抓包研读几遍把Via、Contact、CSeq、SDP这几个核心字段吃透再碰到VoIP报错基本不会慌。真要说还有什么秘笈那就是多抓包、多看时序、多拿自己的终端和服务端做实验——纸上谈兵永远不如亲手拉通一个呼叫。
