跳到主要内容

4. SDP 定义 (SDP Definitions)

本节定义若干用于描述会话的附加 SDP 参数, 均为媒体级属性.

4.1. 配置文件标识​

[4] 定义的 AV 配置文件在 SDP [3] 等上下文中称为 "AVP". 本文档规定的配置文件称为 "AVPF".

除非会话描述表明使用 "AVPF" 配置文件 (单独或与其他 AV 配置文件联合), 否则 MUST NOT 按本文档的修改时序规则为某媒体会话发送反馈信息.

4.2. RTCP 反馈能力属性​

定义新的载荷格式专用 SDP 属性, 表示可按本文档使用 RTCP 反馈: a=rtcp-fb. rtcp-fb MUST 仅作 SDP 媒体属性, MUST NOT 出现在会话级. rtcp-fb MUST 仅用于指定了 "AVPF" 的媒体会话.

rtcp-fb SHOULD 用于指明该媒体会话对所示载荷类型 MAY 使用哪些 RTCP FB 消息. 载荷类型通配符 ("*") MAY 表示属性适用于所有载荷类型. 若支持多种反馈或需为载荷子集分别指定, MUST 使用多行 a=rtcp-fb.

若未指定 rtcp-fb, RTP 接收端 MAY 按相应媒体类型定义发送其他合适 RTCP 反馈分组. RTP 接收端 MUST NOT 指望 RTP 发送端对任意 FB 消息作出反应. RTP 发送端 MAY 忽略部分反馈消息.

若媒体会话描述中含一个或多个 rtcp-fb, 对含 rtcp-fb 的媒体会话的 RTCP 接收端:

  • MUST 忽略其无法完全理解语义的 rtcp-fb (即不理解该行 a=rtcp-fb 中全部取值含义者);

  • SHOULD 按本文档, 使用该媒体会话某一 rtcp-fb 属性所列 RTCP 反馈分组之一提供反馈;

  • MUST NOT 使用未出现在任一 rtcp-fb 行中的其他 FB 消息.

与 offer/answer 模型 [8] 联用时, offer 端 MAY 向对端提供一组此类 AVPF 属性. answer 端 MUST 删除其不理解以及一般不支持或本媒体会话不愿使用的属性. answer 端 MUST NOT 向媒体描述增添反馈参数, MUST NOT 改动已有参数取值. answer 对媒体会话有约束力, 双方 MUST 仅使用如此协商的反馈机制. offer 与 answer 端 MAY 各自只发送已协商机制的子集, 但收到已协商类型时 SHOULD 正确处理.

RTP 发送端 MUST 能接收任意 RTCP FB, MUST 静默丢弃无法理解的 FB.

rtcp-fb 属性语法如下 (反馈类型与可选参数均区分大小写):

(以下 ABNF 中 fmt, SP, CRLF 定义见 [3].)

     rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

     rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
                        / fmt   ; as defined in SDP spec

     rtcp-fb-val        = "ack" rtcp-fb-ack-param
                        / "nack" rtcp-fb-nack-param
                        / "trr-int" SP 1*DIGIT
                        / rtcp-fb-id rtcp-fb-param

     rtcp-fb-id         = 1*(alpha-numeric / "-" / "_")

     rtcp-fb-param      = SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-ack-param  = SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-nack-param = SP "pli"
                        / SP "sli"
                        / SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

字面量语义如下:

反馈类型 "ack":

表示支持肯定确认类反馈.

"ack" MUST 仅在允许按第 3.6.1 节处于 ACK 模式的媒体会话中使用.

MUST 提供参数以区分不同肯定确认类型.

参数 "rpsi" 表示使用第 6.3.3 节定义的 Reference Picture Selection Indication 反馈.

若指定参数 "app", 表示使用应用层反馈; "app" 后可跟附加参数以区分不同应用层反馈. 本文档不为 "app" 定义专用参数.

"ack" 的更多参数 MAY 在其他文档定义.

反馈类型 "nack":

表示支持否定确认类反馈.

单独 "nack" (无参数) 表示使用第 6.2.1 节的 Generic NACK 格式.

本文档为与媒体类型 "video" 联用的 "nack" 定义下列三个参数:

  • "pli": 第 6.3.1 节的 Picture Loss Indication.

  • "sli": 第 6.3.2 节的 Slice Loss Indication.

  • "rpsi": 第 6.3.3 节的 Reference Picture Selection Indication.

"app" 表示应用层反馈; "app" 后可跟参数区分类型. 本文档不为 "app" 定义专用参数.

"nack" 的更多参数 MAY 在其他文档定义.

其他反馈类型 <rtcp-fb-id>:

其他文档 MAY 定义更多类型; 为保持语法可扩展引入 rtcp-fb-id 占位. 新反馈方案名 MUST 唯一 (并 MUST 向 IANA 注册), 且须规定语义, 分组格式 (若需要) 与运行规则.

Regular RTCP 最小间隔 "trr-int":

属性 "trr-int" 指定本会话两个 Regular (完整复合) RTCP 分组之间的最小间隔 T_rr_interval, 单位为毫秒. 未指定时默认 0.

更具体的应用层反馈信息 (第 6.4 节) 假定由别处定义的反馈类型与参数传达, 故本文档不再另行规定.

更多反馈类型与参数 MAY 在其他文档定义.

是否发送反馈由接收方决定, 发送方 (如何) 利用反馈亦由其决定.

4.3. RTCP 带宽修饰符​

[1] 与 [2] 的标准 RTCP 带宽分配 MAY 被显式上限的带宽修饰符覆盖. 对 SDP, [4] 规定: MAY 使用 b=RS:<bw> 与 b=RR:<bw> 分别为 RTP 发送端与接收端指定比特每秒带宽. 实际带宽按 [4] 的优先规则确定.

在高度非对称链路 (如卫星) 上运行的应用 SHOULD 用此机制降低高带宽流的反馈速率, 避免反馈路径确定性拥塞.

4.4. 示例​

示例 1: 下列会话描述为点对点音频加 DTMF [18], DTMF 流使用 Generic NACK. 可出现在 SIP INVITE, 200 OK 或 ACK 中, 表示发送方能够并愿意就其发送的 DTMF 流接收反馈.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Media with feedback
     t=0 0
     c=IN IP4 host.example.com
     m=audio 49170 RTP/AVPF 0 96
     a=rtpmap:0 PCMU/8000
     a=rtpmap:96 telephone-event/8000
     a=fmtp:96 0-16
     a=rtcp-fb:96 nack

使收发双方可在音频会话中可靠传送 DTMF 事件. 假定 64 kbit/s 音频且单接收端, 接收端有 2.5% RTCP 带宽用于 NACK, 即每秒约 250 字节或约每秒 2 条 RTCP 反馈, 故每秒单独通告最多约两个缺失 DTMF 音频包.

示例 2: 下列为组播纯视频 (H.261 或 H.263+), 视频源对两种编解码接受 Generic NACK, 对 H.263 还接受 Reference Picture Selection. 可能经 SAP 传达.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

发送端可将收到的 Generic NACK 作为尽快发送新帧内图像的提示 (在拥塞控制允许时). 收到 RPSI 可避免发送大型帧内图像; 可继续发帧间图像, 但选用所指帧作为新参考.

示例 3: 下列描述与示例 2 相同媒体, 但允许 AVP 与 AVPF RTP 实体混用 (见下一节). 两媒体描述地址相同; 需两条 m= 以表达两种配置文件.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVP 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

两条 m= 行 SHOULD 通过适当机制成组, 表明二者为传达相同内容的备选. [10] 定义了示例框架.

此例中, 启用 RTCP 反馈的接收端可偶尔更早向发送端报告事件 (可能惠及全组). 但平均而言所有 RTP 接收端提供的反馈量相同. AVP 与 AVPF 互通见下一节.

最后于 更新