点播是国标里最常被调用的流程：INVITE、200 OK、ACK 三趟走完，流才开始跑。 信令四千字节、一百四十毫秒，换六十秒的三十兆媒体—— 这个比例决定了排障顺序：先信令后媒体。
上一节的注册是「进门」，这一节是「要东西」。 点播流程把前面讲的所有东西串了起来：SIP 传信令、SDP 谈参数、RTP 送媒体。 它是验收时第一个要演示的功能，也是故障最多的一个。
一、三趟信令，缺一不可
第一趟 INVITE： 平台说「我要看 34020000001320000001 的实时流，请往我这发」，SDP 里带着自己的收流地址。 第二趟 200 OK：设备说「行，我从这个地址这个端口发」，SDP 里带着自己的发流地址。 第三趟 ACK：平台说「收到，开始吧」。 ACK 过去之后，设备才真正开始推流。 中间还有个 100 Trying，它是「我收到了，正在处理」，防止平台过早重发。 它不是必需的，但几乎每台设备都会发。 最容易漏的是 ACK：有些简易实现发完 INVITE 就等流，不发 ACK。 结果设备一直重发 200 OK，几秒后判定会话失败。 表现就是「能播几秒然后断」，很容易被误判成网络问题。
二、为什么要一百四十毫秒
这 140 毫秒不是网络慢，是协议本身要好几趟： INVITE 出去、Trying 回来是一趟；200 OK 回来是第二趟；ACK 出去之后设备才开始发。 所以理论上「点播启动时间」约等于两次往返加设备处理。 同城专线两次往返几十毫秒，跨城就是一百多毫秒。 这也解释了为什么「级联三层会明显变慢」：每一层都要重走这三趟， 三层的启动时间差不多是一层的三倍。 想快只有一个办法：提前建立会话。 很多平台做「预热」——用户点开之前就把流拉起来，点开时直接播缓存。 代价是「没人看的流也在占带宽」。
三、故障对照表
点播出问题，症状和病因的对应关系其实很固定：INVITE 有去无回，多半是编号不认或 5060 不通；
200 OK 了但没流，多半是 SDP 地址端口不对或防火墙挡了 UDP。
「有流但花屏」是另一类：信令全对，问题在封装或时钟频率上。
这时抓包能看到 RTP 包在来，但播放器解不出来。
「能播但十秒就断」几乎一定是 ACK 没发，或者 Expires／会话超时设得太短。
按这个顺序查，比盲目抓包快得多：先确认三趟信令齐不齐，再看媒体通不通，最后看媒体对不对。
四、动手 Demo：一次点播的报文和它花的时间
把一次完整点播的七个报文按时间线摆出来：各自的字节数、相对起点的毫秒数。 再算信令和媒体的比例，看谁才是大头。
steps = [("INVITE", 780, 0), ("100 Trying", 180, 20),
("200 OK", 820, 60), ("ACK", 320, 80),
("首个 RTP", 1412, 140), ("BYE", 300, 0),
("200 OK", 200, 20)]
total = sum(x[1] for x in steps)
media = 4000000 * 60 / 8
print("信令合计", total, "字节")
print("跑 60 秒媒体", "%.1f MB" % (media / 1e6))
print("信令占比 %.4f%%" % (100.0 * total / media))
实跑输出：
--------------------------------------------------------------------
一次点播的报文和它花的时间
--------------------------------------------------------------------
**点播是国标里最常被调用的流程**：**一次 INVITE、一次 200、一次 ACK，流就开始跑了。**
**结束的时候还得 BYE，不然会话一直挂着。**
报文 方向 字节 相对起点
--------------------------------------------------------------------
**INVITE（带 SDP）** 平台 → 设备 **780** **0 ms**
**100 Trying** 设备 → 平台 **180** **20 ms**
**200 OK（带 SDP）** 设备 → 平台 **820** **60 ms**
**ACK** 平台 → 设备 **320** **80 ms**
**首个 RTP 包** 设备 → 平台 **1412** **140 ms**
**BYE** 平台 → 设备 **300** **0 ms**
**200 OK（对 BYE）** 设备 → 平台 **200** **20 ms**
信令合计 4012 字节，从 INVITE 到首包 140 毫秒
一路 4 Mbps 的流跑 60 秒是 30.0 MB
信令占比 0.0134%
**四千字节的信令，换三十兆的媒体**——**这个比例说明排障顺序：先看信令通不通，再看媒体对不对。**
**信令不通，媒体一个字节都不会来；信令通了媒体不来，才是网络或端口的问题。**
**那 140 毫秒是怎么来的**：
**INVITE 到 200 OK 是两次往返（先 Trying 再 OK），ACK 过去之后设备才开始发流。**
**所以「点播要等一会儿」不是错觉，是协议本身要好几趟。**
**有两处最容易出错**：
症状 多半是
----------------------------------------------------------------------
**INVITE 有去无回** **设备不认这个编号，或 5060 不通**
**200 OK 了但没流** **SDP 里的地址端口不对，或防火墙挡了 UDP**
**有流但花屏** **PS 封装或时钟频率不对**
**能播但十秒就断** **没发 ACK，设备认为会话没建立**
**第四行值得单独说**：**ACK 不是「确认收到」，是「会话建立的第三步」**。
**少了它，设备会一直重发 200 OK，最后超时放弃。**
**表现就是「能播十秒然后断」，很多人以为是网络不稳。**
七个报文加起来四千字节，而六十秒的媒体是三十兆——差了三四个数量级。 但信令的位置在前：它不通，媒体一个字节都不会来。 这就是「先信令后媒体」这个排障顺序的由来。 最后一列的时间线值得看： INVITE 到首个 RTP 是 140 毫秒，其中 80 毫秒花在 ACK 之前的两趟往返上。 设备收到 ACK 之后还要启动编码器、填第一个 I 帧，这几十毫秒是省不掉的。 所以「点开就出画面」在国标里做不到， 能做到的是「一百多毫秒出画面」——这已经比人感知的「卡」要快了。 BYE 那两行的时间写的是相对起点，不是真实时刻，因为会话持续多久取决于用户看多久。
30 秒实验
- 算一下：INVITE 到首个 RTP 有几趟往返？（两次往返后 ACK）
- 想一下：为什么级联三层启动会慢三倍？
- 想一下：「能播十秒就断」最可能缺哪一步？（ACK）
常见误区
- 以为「发完 INVITE 就会来流」。 要等 200 OK 和 ACK，设备收到 ACK 才推。
- 以为「点播慢是网络慢」。 两三趟往返是协议本身的开销。
- 以为「有流就一定对」。 花屏是封装或时钟的问题，信令全对也可能花。
自测三问（点开对答案）
1. 点播的三趟信令分别是什么？ —— **INVITE、200 OK、ACK**（中间可能夹一个 100 Trying）。 2. 设备什么时候开始推流？ —— **收到 ACK 之后**。少了 ACK 会话就不算建立。 3. 为什么「先信令后媒体」？ —— **信令是开关**，不通则媒体一个字节都不会来。下一节讲控制：四种指令各多长，重发为什么会让云台转飞。
- ☐ （本节完，下一节 10.08.03 设备控制）