波仔
📹 第十章 GB／T 28181协议原理
📄 一句话概括

这是国标里唯一「上行也要媒体」的流程：平时都是设备往平台发，这两个是平台往设备发。 码率只有 64 kbps，可它比视频更挑网络——人对声音的断续极其敏感。

📝 本节和前面几节的关系

前面十一个流程，媒体全是「设备到平台」。这一节第一次反过来：平台要说给设备听。 它是整章的收尾，也是唯一「人直接感知延迟」的流程。

一、广播和对讲差在哪

广播是单向的：平台说，设备放。对讲是双向的：平台说、设备也说，两路媒体同时跑。 这个区别决定了延迟要求不一样：广播延迟大点只是听着慢；对讲延迟大了两个人会同时开口。 所以工程上常见这样的取舍：广播走 PS 封装（省事），对讲走裸 RTP（省延迟）。 这也是为什么对讲的报文比广播「短」：少一层封装就少几十毫秒的攒包时间。

二、64 kbps 为什么也挑网络

G.711 一路音频 64 kbps，视频 4 Mbps，差六十四倍。 可对讲反而更容易「听起来卡」。 原因是包太小：20 毫秒一个包，每包只有 160 字节负载。 RTP 头 12 字节就是 8%；再加 PS 封装的二十来字节，就是两成。 所以对讲的实际码率不是 64 kbps，是八十多。 更要紧的是「打包间隔」这个参数：20 毫秒放到 40 毫秒，开销减半，但延迟加 20 毫秒。 这是一个必须自己拿捏的旋钮，没有标准答案： 对延迟敏感的取 20 毫秒，对带宽敏感的取 40 毫秒。

三、回声：协议解决不了的那部分

对讲最常见的现场问题是啸叫：设备的喇叭声音被麦克风收回去，再放大再收，形成正反馈。 这不是协议能解决的，必须设备端做回声消除（AEC）。 所以验收对讲最直接的办法是「站在设备旁边说话」：能听清、不啸叫，就算过。 在办公室里测不出来，因为办公室没有那个 acoustics。 还有一条经验：对讲失败八成不是协议问题，是「设备没接喇叭」或「音量被关了」。 先确认物理层，再怀疑协议。

四、动手 Demo：对讲只占 64 kbps，可它比视频更挑网络

先比码率，再算一个音频包的账，看头占了多少。 最后列三种场景的延迟容忍度。

g711, video, pkt = 64, 4096, 20
print("差", video // g711, "倍")

payload = int(g711 * 1000 / 8 * pkt / 1000)
print("每包", payload, "字节")
print("RTP 头开销 %.0f%%" % (100.0 * 12 / payload))
print("PS 封装开销 %.0f%%" % (100.0 * 32 / payload))

实跑输出：

--------------------------------------------------------------------
对讲只占 64 kbps，可它比视频更挑网络
--------------------------------------------------------------------
**语音对讲和语音广播是国标里唯一「上行也要媒体」的流程**：
**平时都是设备往平台发，这两个是平台往设备发。**
**码率只有 64 kbps，但延迟要求比视频高得多。**

  G.711 一路音频 64 kbps，视频 4096 kbps，差 64 倍

**差六十四倍，可对讲反而更容易「听起来卡」**：
**因为人对声音的断续极其敏感，几十毫秒的断就能听出来；而画面丢几帧，眼睛往往察觉不到。**

**先算一个包的账**：
  每 20 毫秒一个包，每包 160 字节负载
  RTP 头 12 字节 → 开销 8%
  PS 封装再加约 20 字节 → 开销 20%

**这个比例很扎眼**：**音频包太小，头就占了两成。**
**所以对讲的实际码率不是 64 kbps，是八十多。**
**这也解释了为什么「打包间隔」在对讲里是个重要参数**：
**间隔从 20 毫秒放到 40 毫秒，开销减半，但延迟加 20 毫秒。**

**延迟预算对比**：
  场景             可容忍延迟         为什么
  ----------------------------------------------------------------
  **视频监控**     **几百毫秒**       **看的是「发生了什么」**
  **语音对讲**     **一两百毫秒**     **超了就像打电话有回声**
  **双向对讲**     **一百毫秒内**     **超了两个人会抢话**

**第二行和第三行的差别容易被忽略**：
**「广播」是单向的，延迟大点只是听着慢；「对讲」是双向的，延迟大了两个人会同时开口。**
**所以广播可以走 PS 封装，对讲往往直接走裸 RTP。**

**最后一个工程上的坑**：**对讲要「回声消除」**——**设备的喇叭声音被麦克风收回去，会形成啸叫。**
**这不是协议能解决的，必须设备端做 AEC。**
**所以验收对讲时，站在设备旁边说话，是最直接的测试方法。**

差六十四倍，但最后两行的百分比说明问题在别处： 12 字节的头压在 160 字节负载上就是 8%，再加 PS 封装就到 20%。 视频包是 1400 字节，同样的头只占 1% 不到。 所以「小包」这件事本身就是代价——这也解释了为什么第八章讲语音时反复提「打包间隔」。 「20 毫秒放到 40 毫秒」这个取舍值得记住：开销减半、延迟加 20 毫秒。 广播可以这么干，对讲不行——20 毫秒的延迟在双向通话里是能听出来的。 最后那句「八成不是协议问题」是经验：现场排查先看喇叭、音量、接线，再去看 SIP 报文。

30 秒实验

  1. 算一下：64 kbps、20 毫秒一个包，每包多少字节？（160 字节）
  2. 想一下：为什么对讲比广播更在意延迟？
  3. 想一下：啸叫是协议问题吗？（不是，是声学问题）

常见误区

  1. 以为「码率小就不会卡」。 包小、头占比高，反而更容易受抖动影响。
  2. 以为「广播和对讲是一回事」。 一个单向一个双向，延迟要求差一倍。
  3. 以为「对讲不通就是协议问题」。 先查喇叭和音量。
自测三问（点开对答案） 1. 广播和对讲的本质区别是什么？ —— **广播单向、对讲双向**；对讲有两路媒体同时跑，延迟要求更高。 2. 为什么 64 kbps 的音频包开销比 4 Mbps 的视频大？ —— **负载小**：160 字节负载配 12 字节头，占比 8%；视频 1400 字节负载才不到 1%。 3. 打包间隔从 20 毫秒放到 40 毫秒，代价是什么？ —— **开销减半，但延迟增加 20 毫秒**。

第十章到这里就完了。下一章看真实的国标平台：LiveGBS 和 EasyGBS 怎么搭、怎么接。

相关笔记