第2章 SIP协议基础

第1章：SIP协议基础

SIP，全称Session Initiation Protocol，中文叫会话初始协议。说白了，它就是IMS网络里的"信令交通警察"。

我刚开始接触SIP时，总觉得它跟HTTP长得太像了。后来才发现，这其实是设计者有意为之——让通信工程师能快速上手。SIP负责的事情很简单：建立会话、修改会话、终止会话。至于媒体流怎么传，那是RTP的事，SIP不管。

为什么IMS要用SIP？因为它是纯文本协议，调试起来特别方便。我记得有一次在现网排查问题，直接用tcpdump抓包，然后用Wireshark打开，一眼就看出某个头域拼写错了。要是换成二进制协议，光解码就得折腾半天。

核心要点：SIP是应用层控制协议，用于创建、修改和终止多媒体会话。它不传输媒体数据，只负责信令控制。

SIP消息分两种：请求和响应。结构上跟HTTP几乎一样，分为起始行、头域、空行、消息体四部分。

请求消息的起始行叫"请求行"，格式是：

方法 SIP-URI SIP版本
例：INVITE sip:user@ims.com SIP/2.0

常用的SIP方法有这些：

响应消息的起始行叫"状态行"，格式是：

SIP版本 状态码 原因短语
例：SIP/2.0 200 OK

状态码分6类，我整理了个速查表：

我的小技巧：逆向分析时，重点关注4xx和5xx响应。这些往往是配置错误或协议实现不规范的直接体现。我曾经靠一个404响应，顺藤摸瓜找到了一个路由表配置错误。

SIP头域是消息的"身份证"。每个头域都携带特定信息。我挑几个最常用的说说：

Via：记录消息经过的路径。用于响应路由和环路检测。嗯，这个头域在调试时特别有用，能看出消息走了哪些节点。
From/To：标识发起方和接收方。格式是"显示名 "。注意，To头域不一定代表最终目的地，可能被重定向。
Call-ID：全局唯一标识一个会话。同一个会话的所有消息，Call-ID必须相同。我见过有人把Call-ID写错，结果会话建立不起来。
CSeq：命令序列号。用于匹配请求和响应。每次新请求，CSeq递增1。方法名也要带上，比如"1 INVITE"。
Contact：直接联系地址。后续请求可以直接发到这个地址，不用再经过代理。这个头域在注册和重定向时特别重要。
Content-Type/Content-Length：描述消息体。SDP通常用"application/sdp"。Content-Length是消息体的字节数，别算错了。

避坑指南：我曾经遇到过一个案例，某个头域的值里包含了非法字符（比如换行符），导致下游设备解析失败。SIP协议对头域格式要求很严格，多一个空格都可能出问题。逆向分析时，建议先用Wireshark的"Follow SIP Stream"功能看看原始报文。

一个典型的SIP会话流程，就像打电话一样：先拨号（INVITE），对方振铃（180 Ringing），接听（200 OK），然后开始通话，最后挂断（BYE）。

下面我用SVG画个流程图，把核心交互展示出来：

这个流程看起来简单，但实际项目中会遇到各种变体。比如代理服务器可能返回3xx重定向，或者用户B设置了呼叫转移。我记得有一次排查一个"呼叫建立失败"的问题，发现是代理服务器在转发INVITE时，把Route头域给丢了，导致后续请求路由不到正确位置。

我的建议：刚开始做SIP逆向分析时，先抓一个完整的呼叫流程，对照RFC 3261逐条分析。重点关注Via、Route、Record-Route这几个头域的变化，它们能告诉你消息在网元间是怎么流转的。

嗯，SIP协议基础就讲到这里。记住一句话：SIP是文本协议，可读性强，但格式要求严格。逆向分析时，先看结构，再看头域，最后分析流程。这样一步步来，不会乱。

公众号:蓝海资料掘金营，微信deep3321