一、编码层的对立

| 项 | SIP | H.323 | |---|---|---|---| | 编码 | 纯文本 | ASN.1 PER（二进制） | | 可读性 | 抓包直接看 | 要专用工具解 | | 体积 | 大 | 小 | | 扩展 | 加个头就行 | 要改 ASN.1 定义 |

第一行那个 PER 的全称是 Packed Encoding Rules， 它把定长字段压到最少位数、号码按 BCD 两两一位。 这就是为什么「同样一份信息」它能小一半以上——代价是它不像文本那样能一眼看懂。 第四行那个「扩展」在实际项目里影响很大： SIP 加一个私有头只要在报文里多写一行，对端不认识就忽略； 而 ASN.1 加字段要重新编解码，双方版本必须对得上。 这条差别决定了「谁能快速迭代」，也是 SIP 在互联网领域胜出的技术原因之一。

二、能力协商放在哪

这是两者架构上最大的分叉：

第一行那个「捎带」是关键：INVITE 的正文就是 SDP， 主叫把自己会什么一次说完，被叫在 200 OK 里回「我会什么」。 一次来回，能力就谈完了。 第二行那个 H.245 是一条独立通道， 它要在 Q.931 建好连接之后再开，然后一条一条地谈（终端能力、主从决定、打开逻辑通道）。 所以「首包延迟」H.323 明显更长——这对「点开就要看」的监控场景是硬伤。

三、报文条数的实测与估算

这一段要分清「算出来的」和「估的」：

SIP 那两列是真数出来的（Demo 一次跑八条报文）， H.323 那列标了「估算」——本机没有 H.323 栈，跑不出来就不编数字。 第三行才是分水岭：SIP 是 0 轮、H.323 是多轮，所以「总条数」上 SIP 明显少。 但要注意：条数少不等于总字节少——SIP 每条都大，H.323 每条都小， 最终谁省取决于号码长度和头部的占比。

四、为什么 SIP 赢了

技术原因只是一半，另一半是生态：

第一行那个「调试成本」在实际项目里是决定性的： SIP 出了问题，运维拿 Wireshark 就能看出是哪一步；H.323 得先装解码器。 第二行也真的重要：一个能拼字符串的语言就能写 SIP 客户端，而 ASN.1 要专门的编解码库。 国标选 SIP 不选 H.323，很大程度上是这四条—— 不是因为 H.323 技术上不行，而是因为它「用起来贵」。

五、H.323 还在哪些地方用

说 SIP 赢了，不等于 H.323 消失了：

第一行那个「存量」是关键：很多 2000 年代建的会议室系统还在跑，换掉要动整套终端， 所以一直留着。 第三行是结论：新建项目不用考虑 H.323，但做「对接老系统」时可能要面对它。 所以这一节的价值不是「记住谁好」， 而是「知道遇到 H.323 时它大概长什么样」——二进制、要专用工具、能力协商多轮。

六、动手 Demo：同一份呼叫信息，文本编码与二进制编码差多少

Demo 只算四个字段：主叫号码、被叫号码、呼叫参考值、消息类型。 文本那列是真的 len()，二进制那列是按 BCD 与定长规则算的——两边都是算出来的，没有估。

info = [("主叫号码", S.sid(2), "BCD"),
        ("被叫号码", S.sid(1), "BCD"),
        ("呼叫参考值", "0x1A2B", "定长"),
        ("消息类型", "SETUP", "定长")]

text_total = bin_total = 0
for name, val, kind in info:
    k = (len(val) + 1) // 2 if kind == "BCD" else (2 if "参考" in name else 1)
    text_total += len(val)
    bin_total += k
print(text_total, bin_total, text_total / bin_total)

实跑输出：

--------------------------------------------------------------------
同一份呼叫信息，文本编码与二进制编码差多少
--------------------------------------------------------------------
**H.323 与 SIP 最大的差别在编码层**：**一个用 ASN.1 PER（二进制）、一个用纯文本。**
**这一节不比「谁更好」，只比「同样一份信息要多少字节」。**

  字段           值                       文本字节     二进制字节
  ----------------------------------------------------------------
  主叫号码       34020000001320000002     20           10
  被叫号码       34020000001320000001     20           10
  呼叫参考值     0x1A2B                   6            2
  消息类型       SETUP                    5            1

**四行相加：文本 51 字节、二进制 23 字节**，**省掉 28 字节、比例 2.22 倍。**
**这里只比这四个字段**，**真实 PER 编码还要带协议判别符、长度指示等内容**，
**所以上面那个倍数只用于说明量级，不当验收指标。**

**这就是 PER 的优势**：**定长字段压到最少位数、号码按 BCD 两两一位**，**不看人眼、只看字节。**

**但报文条数上 SIP 更省**：

  阶段         SIP 条数               H.323 条数
  ----------------------------------------------------
  注册         2                      2（RRQ／RCF）
  呼叫建立     4~5                    **4~6**（估算）
  能力交换     **0**（在 SDP 里）     **多轮 H.245**
  挂断         2                      2

**第三行是分水岭**：**SIP 把能力协商塞进 SDP 的 `m=` 与 `a=` 行**，**一次来回解决**；
**H.323 要开一条 H.245 通道，来回谈好几轮。**
**所以同样一次呼叫，SIP 的首包延迟更短**——**代价是每条报文更大。**
**「文本大、条数少」对「二进制小、条数多」**，**这就是两个协议三十年来一直并存的原因。**
**工程上选 SIP 的另一个原因很实在**：**抓包能直接看懂**，**而 PER 编出来的东西要用专用工具解。**

输出里那四行逐项对比最有用： 20 位号码文本占 20 字节、BCD 只占 10——正好一半，因为两位数字挤进一个字节。 0x1A2B 文本 6 字节、定长 2 字节：Q.931 的呼叫参考值本来就是 2 字节字段， 写成 0x1A2B 只是为了人眼看。 合计 51 对 23、比例 2.22 倍——这个倍数只说明「量级」， 因为真实 PER 编码还要带判别符和长度指示。 所以正文里明确写了「不当验收指标」： 这类「半算半估」的对比，必须把边界说清，否则读者会拿它当结论。

30 秒实验

1. 把号码改成 6 位短号再算一次，看倍数变成多少。
2. 查一下你手上设备的信令抓包，看一条 INVITE 的头部占多少比例。
3. 找一个 H.323 的抓包样本，试着不用解码器读它的 Q.931 部分。

常见误区

1. 以为 SIP 全面优于 H.323。 编码效率上 H.323 更好，SIP 赢在可读性与扩展性，不是赢在体积。
2. 以为报文条数少就等于总字节少。 SIP 每条都大，最终谁省取决于号码长度和头部占比。
3. 把「估算」当成实测写进文档。 H.323 那一列本机跑不出来，所以标了估算； 不标就会误导别人做带宽预算。

下一节细看 SDP——那几行文本决定了媒体怎么走。

• ☐ （本节完，下一节 09.01.07 SIP与SDP）

相关笔记

• SIP的功能
• SIP通信流程及消息
• SIP与SDP
• 📹 视频监控与国标 · 索引