1. 引言

Real-time Transport Protocol 及其关联的 RTP Control Protocol (RTP/RTCP, RFC 3550) [1], 以及用于最小控制的视听通信 profile (RFC 3551) [2], 定义了在 IP 网络上传输基于时间的媒体的机制. RTP 提供了保持定时和检测数据包丢失等能力, RTP payload format 则在基于数据包的环境中为 (连续) 媒体提供适当成帧. RTCP 使接收方能够提供接收质量反馈, 并允许 RTP session 的所有成员相互了解.

RTP 规范只为 RTP 和 RTCP 数据包加密提供了初步支持. Secure RTP (RFC 3711) [4] 为安全 RTP 媒体会话定义了一个 RTP profile ("SAVP"), 规定了适当的 RTP 和 RTCP 数据包加密, 完整性保护和重放保护方法. SRTP 及其安全参数的初始协商需要通过带外方式完成, 例如使用 Session Description Protocol (SDP, RFC 4566) [6] 以及用于传递密钥材料的扩展 (RFC 4567 [7], RFC 4568 [8]).

RTP 规范还为接收方向发送方提供及时反馈提供了有限支持, 通常方式是按某种规则间隔报告接收统计信息, 该间隔取决于组大小, 平均 RTCP 数据包大小以及可用 RTCP 带宽. 用于基于 RTCP 反馈的扩展 RTP profile ("AVPF") (RFC 4585, [3]) 允许会话参与者在统计意义上提供即时反馈, 同时维持所有发送方的平均 RTCP 数据速率. 与 SAVP 一样, AVPF 及其参数的使用需要通过 SDP (RFC 4566, [6]) 和 RFC 4585 [3] 中定义的扩展进行带外协商.

SRTP 和 AVPF 都是 RTP profile, 且都需要协商. 这意味着可以使用其中之一, 但不能为同一个 RTP session (使用一个 SDP session 级描述) 同时协商这两个 profile. 然而, 同时使用安全通信和及时反馈是有价值的. 因此, 本文档规定了一个新的 RTP profile ("SAVPF"), 它结合了 SAVP 和 AVPF 的特性.

由于 SAVP 和 AVPF 在很大程度上相互正交, 二者的组合大多是直接的. 本文档不需要规定复杂算法. 相反, 本文档引用这两个既有 profile, 只描述二者组合带来的影响, 可能偏离既有 profile 规则的地方, 以及协商过程.

1.1. 定义

RFC 3550 [1], RFC 3551 [2], RFC 4585 [3] 和 RFC 3711 [4] 中的定义适用.

本文档中特别使用以下定义:

RTP session: 如 RFC 3550 [1] 所定义, 一组使用 RTP 通信的参与者之间的关联.
(SDP) media description: 此术语指 SDP 消息中单个 m= 行给出的规范. 一个 SDP media description 只能定义一个 RTP session.
Media session: media session 指一组按语义分组的 SDP media description, 用于表示同一种通信方式的多个替代项. 在这样的组中, 会为某个通信关系协商或选择其中一个替代项, 并实例化相应的 RTP session. 如果找不到适合相关端点的公共会话参数, 该 media session 将被拒绝. 在最简单的情况下, media session 等同于 SDP media description, 也等同于 RTP session.

1.2. 术语

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 RFC 2119 [5] 中的描述解释.