1.1. Applicability (适用性)

1.1. Applicability (适用性)

XR 数据包在多个应用程序中都很有用, 因此不将其定义为 RTCP 发送方或接收方报告的配置文件特定扩展 [9, 第 6.4.3 节]。尽管如此, 它们并非在所有上下文中都有用。特别是, VoIP 指标报告块 (第 4.7 节) 特定于语音应用程序, 尽管它可以在各种此类应用程序中使用。

VoIP 指标报告块可以应用于任何指定使用 RTP 和 RTCP 的一对一或一对多语音应用程序。对话指标 (第 4.7.5 节) 的使用, 包括 R 因子 (由 [3] 中定义的 E 模型描述) 和对话质量的平均意见分数 (MOS-CQ), 在简单的双方通话以外的应用程序中没有定义; 因此, 这些指标在组播会议应用程序中应被标识为不可用。

逐包报告块类型, 丢包 RLE (第 4.1 节)、重复 RLE (第 4.2 节) 和数据包接收时间 (第 4.3 节), 在定义时考虑了网络层析成像应用程序, 例如网络特性的组播推断 (MINC) [11]。MINC 需要来自组播会话接收方的详细数据包接收轨迹, 以便推断组播分发树的粗略结构以及应用于该树分支点之间路径的参数, 例如丢包率和延迟。

任何实时组播多媒体应用程序都可以使用逐包报告块类型。此类应用程序可以使用 MINC 推断子系统, 该子系统将为其提供组播树拓扑信息。此类子系统的一个潜在用途是识别组播树中的高丢包区域, 以及识别位置良好的组播会话参与者以提供丢失数据包的重传。

相对于其他 RTCP 数据包, 详细的逐包报告不一定要消耗不成比例的带宽。应用程序可以限制这些块的大小。为这些报告块提供了一种称为"稀疏化"的机制, 可以通过限制在任何序列号间隔内报告的数据包数量来确保它们遵守大小限制。[13] 中描述了此机制的基本原理和使用。此外, 应用程序可能不需要来自所有接收方的报告块, 就能回答诸如组播树中哪些路径超过定义的丢包率阈值等重要问题。关于哪些接收方发送这些报告块的明智决策可以进一步限制它们消耗的 RTCP 带宽部分。

逐包报告块也可以由专用网络监控应用程序使用。对于此类应用程序, 允许使用超过 5% 的 RTP 数据带宽用于 RTCP 数据包可能是合适的, 从而允许比例更大、更详细的报告块。

逐包块类型中的任何内容都不限制它们仅用于组播应用程序。特别是, 它们可以用于类似于 MINC 的网络层析成像, 但使用条纹单播数据包代替。此外, 如果发现有用, 它们可以用于仅限于两个参与者的应用程序。

逐包报告不能立即适用的一种用途是作为数据包重传机制的一部分进行数据包确认。原因是为这些块建议的数据包计数技术与 RTP 通常采用的数据包计数不同。为了有利于测量应用程序, 努力在数据接收方进行尽可能少的解释, 并将解释尽可能多地留给接收报告块的参与者。因此, 例如, 具有异常 SSRC ID 或异常序列号的数据包可能会被正常的 RTP 计数排除, 但会出于网络监控目的进行报告。

统计摘要报告块 (第 4.6 节) 也是在考虑网络监控的情况下定义的。此块类型可以同样很好地用于报告单播和组播数据包接收。

与参考时间相关的块类型是为基于接收方的 TCP 友好组播拥塞控制 [18] 而设计的。通过允许数据接收方计算它们到发送方的往返时间, 它们帮助接收方估计应该请求的下游带宽。请注意, 如果每个接收方都要发送接收方参考时间报告块 (第 4.4 节), 发送方可能会发送多个 DLRR 报告块 (第 4.5 节), 其数量等于在其报告间隔内到达发送方的 RTCP 数据包的接收方数量。随着组播会话中参与者数量的增加, 应用程序应谨慎决定哪些参与者发送这些块以及发送频率。

XR 数据包补充现有的 RTCP 数据包, 并且可以与其他 RTCP 数据包堆叠以形成复合 RTCP 数据包 [9, 第 6 节]。将 XR 数据包引入会话绝不会改变管理 RTCP 报告间隔计算的规则 [9, 第 6.2 节]。由于 XR 数据包是 RTCP 数据包, 它们在带宽计算中被如此计数。因此, 添加扩展报告信息可能会增加平均 RTCP 数据包大小, 从而增加平均报告间隔。可以通过限制 XR 数据包的大小来限制这种增加。

本文档中为 XR 数据包定义的 SDP 信令 (第 5 节) 是在考虑三种使用场景的情况下完成的: 实时流协议 (RTSP) 控制的流应用程序、一对多组播多媒体应用程序 (例如具有增强反馈的课程讲座) 以及涉及双方的会话发起协议 (SIP) 控制的对话会话。采用 SDP 的应用程序可以自由使用额外的 SDP 信令来处理此处未涵盖的情况。此外, 应用程序可以自由使用 SDP 以外的信令机制。