SIP测试-01-SIP协议基础：测试开发需要掌握什么

发表于 分类于 本文字数： 3k 阅读时长 ≈ 11 分钟

第一次接触语音项目时，门槛常常会被放在：

  • SIP 协议太复杂
  • 电话系统太偏门
  • 这应该是开发或者网关同学的事情

但真进项目以后很快就会发现，如果测试开发完全不懂 SIP，很多事情根本做不动：

  • SIPp 脚本写不稳
  • 注册和呼叫失败时看不懂报文
  • 401、403、407、408、480、486 这些失败码分不清
  • 压测里明明是信令问题，却一直在查媒体或应用服务
  • FreeSWITCH、外部网关、语音机器人之间到底是谁先出问题，判断不出来

所以这篇文章不打算把 SIP 写成协议百科。
更想讲清楚一件事：

测试开发到底要掌握 SIP 的哪些部分，掌握到什么程度，才能在真实项目里写脚本、做压测、做排障、做复盘。

一、测试开发学 SIP，不是为了背定义，而是为了看懂一条呼叫链路

在测试视角下，SIP 最重要的价值不是“知道这是一个会话发起协议”，而是你要能把一条呼叫链路拆开看。

一条最常见的呼叫路径，通常至少包括这些动作：

  1. 终端注册到 SIP 服务器
  2. 主叫发起 INVITE
  3. 被叫侧返回 180 Ringing 或 183 Session Progress
  4. 被叫接通后返回 200 OK
  5. 主叫发送 ACK
  6. 通话建立
  7. 任意一方发送 BYE
  8. 对端返回 200 OK

不需要先把所有 RFC 细节都吃透，但至少要能回答：

  • 这通电话现在处在哪个阶段
  • 当前失败发生在注册、鉴权、振铃、接通还是挂断
  • 哪条报文是正常下一步，哪条报文说明已经跑偏

如果这一层看不明白，后面的压测脚本、异常归因、全链路排障都会很虚。

二、测试开发最该先掌握的，不是所有字段，而是 5 组高频概念

1. 注册和呼叫是两件事

很多新人会把“注册成功”和“能打通电话”混在一起。
这在语音项目里是一个很常见的误区。

注册阶段更关注：

  • REGISTER
  • 账号是否存在
  • 鉴权是否通过
  • Contact 是否正确
  • 注册信息是否真的落到服务器侧

呼叫阶段更关注：

  • INVITE
  • 路由是否命中
  • 被叫是否在线
  • 是否进入振铃和接通
  • 是否能正常挂断

实践里很常见的一种误判是：

  • 注册都过了
  • 所以现场很容易默认呼叫问题一定在媒体层

但真实情况往往是：

  • 注册没问题
  • 拨号计划错了
  • 或者路由到了错误网关

2. INVITE、ACK、BYE 是最基本的通话骨架

测试开发不需要先背所有方法名，但下面这组至少要熟：

  • REGISTER
  • INVITE
  • ACK
  • BYE
  • CANCEL
  • OPTIONS

其中最关键的是：

  • INVITE 代表呼叫发起
  • ACK 代表对 200 OK 的确认
  • BYE 代表正常挂断
  • CANCEL 更偏向“还没接通就取消”

如果连这组动作的先后关系都不清楚，很多脚本失败你都没法第一时间判断是脚本写错，还是系统真的没走通。

3. 常见响应码要按测试语义理解

测试开发最不该做的，就是把 SIP 响应码当成纯协议知识点记忆。
更有价值的理解方式是按排障语义来记。

例如：

响应码 更接近的测试语义
401 / 407 鉴权挑战，未必是失败，可能是正常认证流程的一部分
403 有请求，但服务器明确拒绝
404 路由不到、号码不存在或目标未配置
408 超时，先看网络、路由和对端响应
480 对端暂不可达，常见于未注册或目标不可用
486 忙线或被占用
500 / 503 服务端异常或过载，需要继续看服务器状态

这种记法的好处是，看到报文时你脑子里先出来的是“下一步查哪里”，不是“这条定义叫什么”。

4. From、To、Call-ID、CSeq 至少要能看懂

测试开发不需要把每个 header 都背下来，但下面几个至少要会看：

  • From：谁发起的
  • To：发给谁
  • Call-ID：这一通呼叫的唯一标识
  • CSeq：当前事务序号和动作
  • Via：报文经过的链路
  • Contact：后续联系地址

实践里最重要的是 Call-ID。
一旦需要对日志、SIP 报文和服务器日志做串联，它经常是第一根主线。

5. 信令成功不等于媒体成功

这是语音测试里最容易踩的坑之一。

你完全可能遇到这种情况：

  • INVITE 正常
  • 180 正常
  • 200 OK 正常
  • ACK 也正常
  • 但实际没有声音，或者单通

这说明：

  • 信令链路走通了
  • 但媒体协商、RTP 端口、编解码或网络策略可能还有问题

所以测试开发学 SIP 的一个关键边界是：

至少要先把“信令建立成功”和“媒体真正可用”区分开。

三、如果要给测试开发划一条学习边界，可以这样定

不是所有做测试的人都要成为语音协议专家。
但如果你要做下面这些事情：

  • 用 SIPp 写注册和呼叫脚本
  • 对 FreeSWITCH 做信令压测
  • 跑信令加媒体的全链路压测
  • 排查语音机器人、网关、语音平台的呼叫失败

那更关键的是至少要掌握到下面这个层级：

必须掌握

  • 注册和呼叫的基本消息流
  • 鉴权挑战和真正失败的区别
  • 常见响应码的排障语义
  • 怎么从一份报文里看出这次呼叫大概走到哪里
  • Call-ID、CSeq、From、To、Via 的基本作用

最好掌握

  • SDP 里媒体端口和编解码的基本含义
  • 振铃、早媒体、接通这几个阶段对测试的影响
  • CANCEL 和 BYE 在问题定位里的区别
  • FreeSWITCH 或网关路由的基本思路

可以先不深挖

  • 完整 RFC 细节
  • 所有不常见的 SIP 扩展头
  • 过深的网络设备实现差异

这条边界很重要。
因为测试开发学 SIP 的目标不是“学术完整”，而是“能支持脚本、压测和排障”。

四、测试里最常用的一套最小执行骨架

如果要从零开始做一次最小 SIP 测试，通常会先按这个顺序准备：

  1. 确认注册账号、密码、域和目标端口
  2. 先跑单账号注册，确认 REGISTER 正常
  3. 再跑最小呼叫链路，只验证 INVITE -> 200 -> ACK -> BYE
  4. 然后再补并发、媒体流和更复杂的业务侧动作

不建议一上来就：

  • 上大量并发
  • 上复杂认证
  • 上音频播放
  • 上全链路服务调用

因为那样一旦失败，你根本不知道问题是出在：

  • 账号
  • 脚本
  • 鉴权
  • 路由
  • FreeSWITCH
  • 外部服务

一个更稳的最小执行表通常像这样：

阶段 目标 产物
阶段 1 单账号注册成功 注册日志、服务器注册状态
阶段 2 单呼叫成功建立和挂断 基础呼叫日志、失败码记录
阶段 3 加入并发和批量账号 TPS/CPS、错误码分布
阶段 4 加入媒体或下游服务 全链路成功率、时延和失败链路

这套顺序的核心不是“步骤漂亮”，而是每一步都在收窄问题范围。

五、真实案例型段落：一次“注册都成功，但电话还是打不通”的排查

场景

一次电话系统压测前，主叫和被叫批量注册都已经成功。
团队最开始的判断是：

  • 账号没问题
  • FreeSWITCH 也在线
  • 那接下来如果电话打不通，大概率是媒体层或者语音服务的问题

执行

现场按最小链路先跑一轮单呼叫：

  1. 主叫账号注册
  2. 被叫账号注册
  3. 被叫脚本进入监听
  4. 主叫发 INVITE

结果脚本很快失败，日志里高频出现的是：

  • 404
  • 个别 480

现象

这类现象很容易把人带偏。

因为团队已经先入为主地认为“注册成功了”，所以现场排查往往不会先去查路由，而是：

  • 怀疑脚本参数有问题
  • 怀疑被叫监听没起来
  • 怀疑媒体没协商成功

但这里有个关键点：

媒体协商都还没开始，先出现 404/480，问题更可能还在信令和路由阶段。

排查

我现场通常按下面顺序排：

  1. 先看 INVITE 里的 To 和目标号码是不是预期值
  2. 再看 FreeSWITCH 拨号计划有没有命中对应 expression
  3. 再看被叫侧号码是否真在当前域和当前路由范围里
  4. 最后才回头查脚本和被叫监听

这一轮排下来，真正的问题不是注册，也不是媒体，而是：

  • 拨号计划里允许的号码范围和压测 CSV 里的被叫号码范围没有对齐
  • 注册成功的用户并不代表当前 INVITE 一定能被当前拨号计划正确路由

修复

修复动作很直接：

  1. 调整 FreeSWITCH 拨号计划里的号码匹配范围
  2. 对齐主叫脚本里的目标号码和服务器侧允许范围
  3. 再跑单呼叫验证
  4. 单呼叫稳定后再恢复并发压测

修复后，链路很快恢复成：

  • INVITE
  • 180 Ringing
  • 200 OK
  • ACK
  • BYE

这个案例对我来说很典型，因为它说明：

做语音测试时，注册成功从来不等于呼叫链路一定没问题。

六、做 SIP 测试时，更常用的一套判断顺序

如果现场出现呼叫失败，通常不会一上来就抓所有东西。
更常用的顺序是：

  1. 先判断失败是在注册阶段还是呼叫阶段
  2. 呼叫阶段先看失败码，再判断是鉴权、路由、超时还是服务异常
  3. 如果 200 OK 都没出现，就先别急着查媒体
  4. 如果信令已经接通但体验异常，再去看 SDP、RTP 和媒体质量

这个顺序很实用，因为它能快速避免两种常见浪费：

  • 还没接通就一直查音频
  • 明明是路由问题，却一直改脚本参数

七、测试开发真正该从 SIP 学到的，不只是协议，而是链路思维

需要强调的是，SIP 项目最有价值的地方，不只是学到一个偏门协议，而是逼着测试开发形成更强的链路思维。

因为在这类系统里，你必须同时面对：

  • 协议动作
  • 路由规则
  • 服务状态
  • 媒体协商
  • 并发压测
  • 线上排障

这会让你比做纯接口测试时更早形成一种习惯：

  • 先拆阶段
  • 再判边界
  • 再对齐证据
  • 最后才下结论

这也是为什么更关键的是，测试开发掌握 SIP，不只是为了做语音项目，更是为了提升处理复杂链路问题的能力。

结语

测试开发学 SIP，真正需要的不是“把协议全部学完”，而是先掌握一套足够支持项目落地的最小知识面：

  • 看得懂注册和呼叫骨架
  • 认得出常见失败码的测试语义
  • 知道信令和媒体是两层问题
  • 出问题时知道先查哪一跳

只要这一层打牢了，后面的 SIPp 脚本、FreeSWITCH 压测、全链路排障，才会真正开始变得可控。