跳到主要内容

2. RTP 与 RTCP 分组格式及协议行为 (RTP and RTCP Packet Formats and Protocol Behavior)

2.1. RTP

除下文所述规则外, [2] 中定义的规则也适用于本概要.

RTCP 分组类型 (RTCP packet types):

登记了两种额外的 RTCP 分组类型, 用于承载反馈信息的相应 FB 消息定义于本文档第 6 节.

RTCP 报告间隔 (RTCP report intervals):

本文档描述三种影响 RTCP 报告间隔的工作模式 (见本文档第 3.2 节). 在 Regular RTCP 模式下, 除同一 RTP 实体发出的两份 RTCP 报告之间建议的最小 5 秒间隔外, [1] 中的全部规则均适用. 在 Immediate Feedback 与 Early RTCP 两种模式下, 取消两份 RTCP 报告之间 5 秒的最小间隔; 此外, 若要发送包含 FB 消息 (定义于本文档第 4 节) 的 RTCP 分组, 还须适用本文档第 3 节规定的规则.

[1] 中的规则可被会话描述中指定的不同参数覆盖 (例如分别为发送端与接收端分配给 RTCP 的带宽份额). 对使用会话描述协议 (SDP, Session Description Protocol) [3] 定义的会话, 适用 [4] 的规则.

拥塞控制 (Congestion control):

适用 [2] 中详述的相同基本规则. 除此之外, 第 7 节进一步讨论反馈的影响以及发送端对 FB 消息的反应.

2.2. 底层传输协议 (Underlying Transport Protocols)

RTP 旨在运行于不可靠传输协议之上, 包括 UDP 与数据报拥塞控制协议 (DCCP, Datagram Congestion Control Protocol). 本节简要说明相对普通 RTP 运行, 本文档规定的基于 RTCP 的反馈所引入的要点.

UDP: UDP 为点到点以及多播通信提供尽力而为的数据报交付. UDP 不支持拥塞控制或差错修复. 本文档定义的基于 RTCP 的反馈能够为有限的差错修复提供最低限度的支持. 由于 RTCP 反馈并不能保证在足够小的时间尺度 (与 RTT 同量级) 上运作, RTCP 反馈不适合用于支持拥塞控制. 本文档同时涵盖单播与多播运行.

DCCP: DCCP [19] 为单播通信提供受拥塞控制但不可靠的数据报流. 在使用基于 TCP 友好速率控制 (TFRC, TCP Friendly Rate Control) [20] 的拥塞控制 (CCID 3) 时, DCCP 特别适合音视频通信. DCCP 的确认消息可以提供关于已收与未收数据报的详细反馈报告 (从而反映拥塞状况).

在 DCCP 上运行 RTP 时, 拥塞控制在 DCCP 层完成, RTP 层无需额外机制. 此外, 具备 RTCP 反馈能力的发送端可以利用更频繁的基于 DCCP 的反馈, 因而接收端在适当时可以不使用 (额外的) Generic Feedback 消息.