跳到主要内容

10. 实现示例 (Implementation Examples)

本文档仅规定互操作性所必需的发送端与接收端行为. 此外, 某些算法 (例如针对特定环境的速率控制或缓冲区管理) 可提高重传效率.

本节概述本规范允许的不同实现选项.

第一个示例描述一种最小接收端实现. 借助该实现, 可重传丢失的 RTP 分组, 有效检测重传丢失, 并在需要时执行多次重传. 大部分必要处理在服务器端完成.

第二个示例展示如何在 (小型) 多播组中将重传与分层编码结合使用. 说明重传与分层编码可以是互补技术.

10.1. 最小接收端实现示例 (A Minimal Receiver Implementation Example)​

本节给出支持多次重传的实现示例. 发送端使用 MPEG-4 视频 RTP 载荷格式在 RTP 分组中传输原始数据. 假定按 [1] 使用 NACK 反馈消息. 下面给出采用 SSRC 复用的 SDP 描述示例:

v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000

格式专用参数 "rtx-time" 表示服务器将把已发送分组保存在重传缓冲区中 3.0 秒, 之后从缓冲区删除且不再发送.

在该实现示例中, 处理重传所需的 RTP 接收端处理保持最小. 接收端根据所收序列号中的间隙检测丢包. 按 AVPF 概要 [1] 通过 NACK 向发送端报告丢失分组. 接收端应考虑信令的发送端重传缓冲区长度以确定自身接收缓冲区规模. 还应根据缓冲区长度推导可对某分组请求重传的最大次数.

发送端应有选择地重传分组; 即, 应根据分组重要性, 观测到的服务质量 (QoS) 以及与接收端的网络连接的拥塞状态决定是否重传被请求的分组. 显然, 随着接收端数量增加, 发送端处理也会增加, 因为必须为每个接收端分配状态信息与处理负载.

10.2. 多播中分层编码媒体的重传 (Retransmission of Layered Encoded Media in Multicast)​

本节展示如何在多播会话中将重传与分层编码结合. 注意, 重传框架仅面向小型多播应用. 大型组可靠多播应用中 NACK 内爆与反馈流量导致的严重拥塞等问题见 RFC 2887 [10].

不同重要性的分组在不同 RTP 会话中发送. 对应不同层的重传流本身可视为不同的重传层. 不同重传流的相对重要性应反映不同原始流的相对重要性.

按本文档第 5.3 节, 多播中不允许对原始流与重传流进行 SSRC 复用. 因此, 重传流 MUST 使用会话复用在不同的 RTP 会话中发送.

下列为分层编码媒体多播重传的 SDP 描述示例:

m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000

服务器与接收端可实现前述示例中的重传方法. 此外, 可根据丢失分组所属层决定是否请求与重传.

最后于 更新