11. RTP 在各类网络与传输协议之上 (RTP over Network and Transport Protocols)

本节描述在特定的网络与传输协议内承载 RTP 包时所涉及的问题。除非被本规范之外的协议特定定义所取代, 否则下列规则适用。

RTP 依赖下层协议来提供对 RTP 数据和 RTCP 控制流的分解多路复用 (demultiplexing)。对于 UDP 及类似协议, RTP SHOULD 使用偶数目的 (even) 目的端口号, 而相应的 RTCP 流 SHOULD 使用下一个较高的 (奇数, odd) 目的端口号。对于那些以单个端口号作为参数、并由此端口号派生出 RTP 与 RTCP 端口对的应用, 如果提供的是奇数, 则该应用 SHOULD 用下一个较低的 (偶数) 数字替换它, 用作该端口对的基值。对于那些通过显式、独立的参数 (使用信令协议或其他手段) 来指定 RTP 和 RTCP 目的端口号的应用, 该应用 MAY 忽略端口号为偶数/奇数且连续的限制, 尽管仍鼓励使用偶数/奇数端口对。RTP 和 RTCP 的端口号 MUST NOT 相同, 因为 RTP 依赖端口号来分解多路复用 RTP 数据和 RTCP 控制流。

在单播会话中, 两个参与者都需要标识一个端口对, 用于接收 RTP 和 RTCP 包。两个参与者 MAY 使用相同的端口对。一个参与者 MUST NOT 假定入站 RTP 或 RTCP 包的源端口可以用作出站 RTP 或 RTCP 包的目的端口。当 RTP 数据报在两个方向上同时发送时, 每个参与者的 RTCP SR 包 MUST 被发送到另一个参与者所指定的、用于接收 RTCP 的端口。RTCP SR 包结合了针对出站数据的发送方信息, 以及针对入站数据的接收报告信息。如果某一端并未主动发送数据 (见第 6.4 节), 则代之以发送一个 RTCP RR 包。

建议 (RECOMMENDED) 分层编码应用 (见第 2.4 节) 使用一组连续的端口号。端口号 MUST 是各不相同的, 因为现有操作系统普遍存在一处缺陷, 阻止在同一个端口上配合多个多播地址使用; 而对于单播, 只有一个可允许的地址。因此, 对于第 n 层, 数据端口为 P + 2n, 控制端口为 P + 2n + 1。当使用 IP 多播时, 地址也 MUST 各不相同, 因为多播路由和组成员关系是在地址粒度上管理的。然而, 不能假定能分配到连续的 IP 多播地址, 因为某些组可能需要不同的作用域 (scope), 因而可能从不同地址范围分配。

前一段与 SDP 规范 RFC 2327 [15] 相冲突, 后者称在同一个会话描述中同时指定多个地址和多个端口是非法的, 因为地址与端口的关联可能会有歧义。其意图是在 RFC 2327 的修订版中放宽此限制, 允许指定数量相等的地址和端口, 并隐含一对一映射。

RTP 数据报不包含长度字段或其他定界符, 因此 RTP 依赖下层协议来提供长度指示。RTP 包的最大长度仅受下层协议限制。

如果 RTP 包要在某个提供连续字节流抽象而非消息 (包) 抽象的下层协议中承载, 则 MUST 定义 RTP 包的某种封装以提供成帧 (framing) 机制。如果下层协议可能包含填充 (padding), 以至于无法确定 RTP 负载的范围, 则同样需要成帧。此成帧机制此处未做定义。

一个配置文件 MAY 规定一种要使用的成帧方法, 即使 RTP 承载于本身提供成帧的协议中, 以便允许在一个下层协议数据单元 (如一个 UDP 包) 中承载多个 RTP 包。在一个网络或传输包中承载多个 RTP 包, 可以减少头部开销, 并可简化不同流之间的同步。