9. RTSP 考虑 (RTSP Considerations)
实时流协议 (RTSP, Real Time Streaming Protocol), RFC 2326 [7], 是一种应用层协议, 用于控制具有实时特性的数据的交付. 本节讨论使用重传的 RTP 会话的控制问题.
9.1. SSRC 复用下的 RTSP 控制 (RTSP Control with SSRC-Multiplexing)
在 SSRC 复用情况下, "m" 行同时包含原始与重传载荷类型, 并具有单一 RTSP "control" 属性. 接收端使用该 "m" 行请求对整个媒体会话执行 SETUP 与 TEARDOWN. Transport 首部中的 RTP 概要 MUST 为 AVPF 概要或其他允许扩展反馈的合适概要. 若在 SETUP 响应的 Transport 首部中包含 SSRC 值, MUST 为原始流的 SSRC.
为控制会话原始媒体流的发送, 接收端照常向发送端发送该会话的 PLAY 与 PAUSE 请求. 用于在 PLAY 响应中设置 RTP 专用参数的 RTP-info 首部 MUST 按原始流的 RTP 信息设置.
当接收端开始接收原始流后, 即可通过 RTCP NACK 请求重传, 无需额外 RTSP 信令.
9.2. 会话复用下的 RTSP 控制 (RTSP Control with Session-Multiplexing)
在会话复用情况下, 每条 SDP "m" 行具有 RTSP "control" 属性. 因此使用重传时, 原始会话与重传会话各有其 "control" 属性. 接收端可按第 8 节的 FID 语义将原始会话与重传会话关联.
原始流与重传流分别通过各自的媒体 "control" 属性完成建立与拆除. Transport 首部中的 RTP 概要 MUST 对原始会话与重传会话均为 AVPF 概要或其他允许扩展反馈的合适概要.
RTSP 演示 SHOULD 支持聚合控制, SHOULD 包含会话级 RTSP URL. 接收端 SHOULD 对原始会话及其关联的重传会话使用聚合控制. 否则将需要两个不同的 'session-id' 值, 即原始会话与重传会话各一, 发送端将无法知晓如何关联它们.
然后照常使用会话级 "control" 属性控制原始流的播放. 当接收端开始接收原始流后, 即可通过 RTCP 请求重传, 无需额外 RTSP 信令.
9.3. 重传流的 RTSP 控制 (RTSP Control of the Retransmission Stream)
由于重传的性质, SHOULD NOT 通过 RTSP PLAY 与 PAUSE 请求控制重传分组的发送. PLAY 与 PAUSE 请求 SHOULD NOT 影响重传流. 重传分组在原始 RTCP 流中根据接收端请求发送, 与状态无关.
9.4. 缓存控制 (Cache Control)
SHOULD NOT 缓存重传流.
在会话复用情况下, 对重传流 SHOULD 将 "Cache-Control" 首部设为 "no-cache".
在 SSRC 复用情况下, RTSP 无法为重传流指定独立缓存, 因为 SDP 中只有一条 "m" 行. 因此, 在决定是否缓存 SSRC 复用会话时, 实现者应考虑这一事实.