rfc3550-中文版
RTP：实时应用程序的传输协议
这份备忘录的状态
本文件规定了一个Internet标准跟踪协议 互联网社区，请求讨论和建议 改进。请参阅当前版本的“Internet” 官方协议标准“（STD 1）的标准化状态 和这个协议的状态。这份备忘录的分发是无限的。
版权声明
版权全部（C）互联网协会（2003）。版权全部。
抽象
这个备忘录描述了实时传输协议RTP。RTP 提供适合的端到端网络传输功能 应用程序传输实时数据，如音频，视频或 模拟数据，经过多播或单播网络服务。RTP 不解决资源保留，不保证 实时服务的服务质量。数据传输是 由控制协议（RTCP）加强以容许监视 以可扩展到大型多播网络的方式进行数据传送， 提供最小的控制和识别功能。RTP和 RTCP被设计成独立于底层传输和 网络层。该协议支持使用RTP级别 和各类级别的混合翻译。
大多数在这个备忘录的文本是相同的RFC 1889，它 淘汰了。线路上的数据包格式没有变化， 只改变了管理协议的规则和算法 用来。最大的变化是对可扩展定时器的加强 计算什么时候发送RTCP数据包的算法 尽可能减小超过预期速率的传输 参与者同时加入会议。
Schulzrinne等人 标准跟踪[页1]
RFC 3550 RTP 2003年7月 目录 1。简介................................................ 4 1.1 术语............................................ 5 2。RTP使用场景.................................................. 5 2.1 简单组播音频会议.................................. 6 2.2 音视频会议.................... ......... 7 2.3 混音器和翻译器................................. 7 2.4 分层编码...................................... 8 3。定义................................................. 8 4。字节顺序，对齐方式和时间格式...................... 12 5。RTP数据传输协议.................................... 13 5.1 RTP固定标题字段...... ........................... 13 5.2 复用RTP会话................... ........... 16 5.3 对RTP头的特定文件修改............ 18 5.3.1 RTP头扩展............... ............. 18 6。RTP控制协议 - RTCP .................................. 19 6.1 RTCP数据包格式....... .............................. 21 6.2 RTCP传输间隔............................. 24 6.2.1 维护会话成员的人数....... 28 6.3 RTCP数据包发送和接收规则............................................................ 28 6.3.1 计算RTCP发送间隔.............................. 29 6.3.2 初始化.................................. 30 6.3.3 接收RTP或非BYE RTCP数据包... ...... 31 6.3.4 接收RTCP BYE包................................... 31 6.3.5 SSRC定时....... ....................... 32 6.3.6 发送定时器到期.................................. 32 6.3.7 发送BYE包...................... 。 33 6.3.8 更新we_sent ................................ 34 6.3.9 分配源说明带宽的.. ... 34 6.4 发送者和接收者报告........................... 35 6.4.1 SR：发送者报告RTCP分组.. ................. 36 6.4.2 RR：接收报告RTCP包.................................. 42 6.4.3 扩展发送者和接收者报告....... 42 6.4.4 分析发送者和接收者报告............ 43 6.5 SDES：源描述RTCP数据包................ 45 6.5.1 CNAME：规范的终点标识符SDES项目。46 6.5.2 名称：用户名称SDES项目........................................ 48 6.5.3 电子邮件：电子邮件地址SDES项目....... 。 48 6.5.4 电话：手机号码SDES项目................... 49 6.5.5 LOC：地理用户位置SDES项目......... 49 6.5.6 工具：应用程序或工具名称SDES项目........................................ 49 6.5.7 注意：通知/状态SDES项目................... 50 6.5.8 PRIV：专用扩展SDES项目........................................ 50 6.6 BYE：再见RTCP数据包................... ............ 51 6.7 APP：应用程序定义的RTCP数据包................... 52 7。RTP翻译器和混音器.................................. 53 7.1 概述........ ........................... 53 Schulzrinne等人 标准跟踪[第2页]
RFC 3550 RTP 2003年7月 7.2 翻译 器中的RTCP处理............................................................ 55 7.3混音器中的RTCP处理.................................... ................ 57 7.4 级联搅拌器.............................. .......... 58 8。SSRC标识符的分配和使用........................... 59 8.1 碰撞几率.............. .................................... 59 8.2 碰撞分辨率和回路检测................................... 60 8.3 使用分层编码.... ......................... 64 9。安全................................................. ... 65 9.1 保密........................................ 65 9.2 身份验证和消息完整性... ................ 67 10。拥塞控制.......................................... 67 11。网络和传输协议上的RTP .................... 68 12。协议常量摘要.............................. 69 12.1 RTCP包类型.......... ............................ 70 12.2 SDES类型.................. ........................... 70 13。RTP配置文件和有效负载格式规范.................................... 71 14。安全考虑.................................................. 73 15。IANA考虑............................................. 73 16。知识产权声明.............................. 74 17。致谢............................................. 74 附录A。算法........................................ 75 附录A.1 RTP数据头有效性检查.................. 78 附录A.2 RTCP报头有效性检查..................... .. 82 附录A.3 预期和失落......包容量的肯定 83 附录A.4 生成RTCP SDES数据包................................................ 84 附录A.5 解析RTCP SDES数据包......... .............. 85 附录A.6 生成随机的32位标识符............. 85 附录A.7 计算的RTCP发送间隔。 ......... 87 附录A.8 估算间隔抖动................ 94 附录B。RFC 1889的变化............................. 95 参考文献............... ....................................... 100 规范性引用........ ....................................100 信息性参考.......................................... 100 做者的地址。 ............................................. 103 完整的版权声明。 ....................................... 104 Schulzrinne等人 标准跟踪[第3页]
RFC 3550 RTP 2003年7月 。 本备忘录规定了实时传输协议（RTP）， 为实时数据提供端到端的交付服务 特色，如交互式音频和视频。那些服务 包括有效载荷类型标识，顺序编号，时间戳 和交付监控。应用程序一般在其上运行RTP UDP来利用其复用和校验和服务; 都 协议提供了传输协议功能的一部分。 可是，RTP能够与其余合适的底层网络一块儿使用 运输协议（见第11节）。RTP支持数据传输 多个目的地使用多播分发，若是提供的 底层网络。 请注意，RTP自己不提供任何机制来确保及时 交付或提供其余服务质量保证，但依赖 在较低层的服务上这样作。它不保证交付或 防止无序交付，也不假定其基础 网络是可靠的，并按顺序发送数据包。序列 包含在RTP中的号码容许接收机重建 发送者的数据包序列，可是也能够使用序列号 肯定数据包的正确位置，例如在视频中 解码，而没必要按顺序解码分组。 虽然RTP主要是为了知足多用户的需求而设计的， 参与者多媒体会议，但不限于此 特定的应用。连续数据存储，交互式 分布式仿真，主动式徽章以及控制和测量 应用程序也可能会发现RTP适用。 本文件定义了RTP，由两个紧密相连的部分组成： o实时传输协议（RTP），用于传输具备的数据 实时属性。 o RTP控制协议（RTCP），监视服务质量 并在进行中传达有关参与者的信息 会话。RTCP的后一方面可能足以“松散” 控制“会议，即没有明确的成员资格 控制和设置，但不必定打算支持 全部的应用程序的控制通讯要求。这个 功能可能彻底或部分纳入单独的 会话控制协议，这是超出了这个范围 文件。 RTP表明遵循原则的新型协议 提出了应用级构架和集成层处理 Clark和Tennenhouse [ 10 ]。也就是说，RTP旨在具备延展性 Schulzrinne等人 标准跟踪[第4页]
RFC 3550 RTP 2003年7月 提供特定应用程序所需的信息 一般会被整合到应用程序处理中而不是 做为一个单独的层实现。RTP是一个协议框架 这是故意不完整的。这个文件指定了那些 预期在全部的应用程序中都有相同的功能 RTP将是适当的。不一样于传统的协议 经过制定协议可能会提供更多的功能 更通常的仍是经过增长一个须要的选择机制 解析，RTP旨在经过修改和/或定制 根据须要添加标题。示例在章节中给出 5.3和6.4.3。 因此除了这个文件外，还有一个完整的规范 对于特定应用程序的RTP将须要一个或多个同伴 文件（见第13节）： o配置文件规范文件，它定义了一组有效载荷 类型代码及其到有效载荷格式的映射（例如，媒体 编码）。配置文件也能够定义扩展或修改 到特定于特定类别的应用程序的RTP。 一般一个应用程序只能在一个配置文件下运行 一个 音频和视频数据的配置文件能够在RFC 3551中找到 [ 1 ]。 o有效载荷格式规范文件，它定义了一个 特定的有效载荷，例如音频或视频编码将是 在RTP中进行。 为他们的实时服务和算法的讨论 实施以及一些RTP的背景讨论 设计决策能够在[ 11 ]中找到。 术语 关键词“必须”，“不得”，“须要”，“应该”，“不该该”， “应该”，“不该该”，“推荐”，“可能”和“可选” 文件要按照BCP 14，RFC 2119 [ 2 ] 并指出符合RTP实施的要求级别。 。 如下部分描述了RTP使用的一些方面。该 例子被选来讲明的基本操做 使用RTP的应用程序，而不是限制可能使用的RTP。在 这些例子，RTP是在IP和UDP之上进行的，并遵循 由指定的音频和视频配置文件创建的约定 在伴侣RFC 3551中。 Schulzrinne等人 标准跟踪[第5页]
RFC 3550 RTP 2003年7月 简单的多播音频会议 IETF的一个工做组开会讨论最新的协议 文件，使用互联网的IP多播服务进行语音 通讯。经过一些分配机制的工做组 主席得到一个组播组地址和一对端口。一个端口 用于音频数据，另外一个用于控制（RTCP） 数据包。这个地址和端口信息被分配给 有意参加者。若是须要隐私，数据和控制在这种状况下， 数据包能够按9.1节的规定进行加密 还必须生成和分发加密密钥。最正确 这些分配和分配机制的细节已经超出了 RTP的范围。 每一个会议使用的音频会议应用程序 参与者以例如20ms持续时间的小块发送音频数据。 每一个音频数据块以前都有一个RTP头，RTP头和 数据又被包含在UDP数据包中。RTP头部表示 包含什么类型的音频编码（如PCM，ADPCM或LPC） 在每一个数据包中，以便发件人能够在一个过程当中更改编码 会议，例如，以适应新的参与者 经过一个低带宽的链路链接或反应的指示 网络拥塞。 像其余分组网络同样，互联网偶尔也会失去 从新排序数据包并将其延迟不一样的时间。至 应付这些损伤，RTP头包含时间 信息和容许接收者的序列号 重建来源所产生的时间，以便在此 例如，大量的音频是连续播放的扬声器 每20毫秒。这个时间重建是分开进行的 会议中每一个RTP数据包的来源。序列号 也能够被接收器用来估计有多少分组 正在失去。 因为工做组成员在加入和离开期间 会议，知道谁在任什么时候候参与是有用的 以及他们如何收到音频数据。为了这个目的， 会议中音频应用程序的每一个实例周期性地 在RTCP上多播一个接收报告加上它的用户名 （控制）端口。接待报告显示目前状况如何 扬声器正在被接收，并可能被用来控制自适应 编码。除了用户名，其余标识 信息也可能被包括在控制带宽限制以内。 站点在离开时发送RTCP BYE数据包（第6.6节） 会议。 Schulzrinne等人 标准跟踪[第6页]
RFC 3550 RTP 2003年7月 音频和视频会议 若是音频和视频媒体在会议中使用，则是 做为单独的RTP会话传输。就是说，单独的RTP和RTCP 使用两个不一样的UDP端口为每一个介质传输数据包 配对和/或多播地址。在这里没有直接的联结 音频和视频会话之间的RTP级别，除了用户 参加这两个会议应该使用相同的区分 （canonical）名称在RTCP数据包中，以便进行会话 能够关联。 这种分离的一个动机是容许一些参与者 会议只收到一个媒体，若是他们选择。进一步第5.2节 给出了解释。尽管分离， 能够实现源音视频的同步播放 使用RTCP分组中携带的定时信息 会话。 混音器和翻译器 到目前为止，咱们已经假设全部网站都但愿接收媒体数据 相同的格式。可是，这可能并不老是适当的。 考虑一个地区的参与者链接的状况 经过低速连接到大部分会议 享受高速网络接入的参与者。而不是强迫 每一个人都使用较低带宽，质量较差的音频编码 称为混频器的RTP级别的中继器能够放置在低带宽附近 区。该混音器将传入的音频数据包从新同步到 重构发送器产生的恒定的20ms间隔，混合 这些重建的音频流成一个单一的流，翻译 将音频编码转换为较低带宽的音频， 经过低速链路的带宽分组流。这些包 多是单播到单个接收者或多播在不一样的 地址给多个收件人。RTP头包含一个方法 混合器来识别形成混合数据包的来源 能够在接收机处提供正确的讲话者指示。 音频会议中的一些预期参与者多是 链接高带宽的连接，但可能不会直接 经过IP组播可达 例如，他们可能在一个后面 应用程序级防火墙不会让任何IP数据包经过。 对于这些网站，混合可能不是必要的，在这种状况下，另外一个 能够使用称为翻译器的RTP级中继类型。二 翻译器安装在防火墙的两侧，一个 外部的一个经过a接收全部组播包 安全地链接到防火墙内的翻译器。该 防火墙内部的转换器将以组播数据包的形式再次发送 到一个限于该站点内部网络的多播组。 Schulzrinne等人 标准跟踪[第7页]
RFC 3550 RTP 2003年7月 混音器和翻译器能够设计用于各类目的。一个 例如是一个缩放我的图像的视频混合器 在单独的视频流中，并将它们合成为一个视频流 模拟一个组景。其余翻译的例子包括 链接一组主机只说IP / UDP的一组主机 只理解ST-II的主机，或者逐包编码 翻译来自个别来源的视频流 从新同步或混合。搅拌机的操做细节 译文在第7部分给出。 分层编码 多媒体应用程序应该可以调整传输 速率匹配接收器的容量或适应网络 拥塞。许多实现都将速率 - 来源的适应性。这对多播不起做用 因为带宽需求的冲突传输 异构接收器。结果每每是最不常见的 分母场景，网络中最小的管道网格 决定了整个现场多媒体的质量和保真度 “广播”。 相反，速率适应的责任能够放在这里 接收器经过将分层编码与分层传输相结合 系统。在RTP over IP组播的状况下，源能够 对分层表示的信号的渐进层进行条带化 跨多个RTP会话，每一个会话都承载在本身的多播组上。 接收者能够适应网络异质性并控制它们 接收带宽只经过加入适当的子集 多播组。 在分层编码中使用RTP的细节在附录中给出 第6.3.9，8.3和11。 。 RTP有效载荷：RTP在数据包中传输的数据 示例音频样本或压缩视频数据。有效载荷 格式和解释超出了本文的范围。 RTP包：由固定的RTP头部组成的数据包， 多是空的清单的贡献来源（见下文），和 净荷数据。一些底层协议可能须要一个 封装待定义的RTP包。一般是一个 底层协议的数据包包含单个RTP数据包， 可是若是容许，能够包含几个RTP包 封装方法（见第11节）。 Schulzrinne等人 标准跟踪[第8页]
RFC 3550 RTP 2003年7月 RTCP数据包：一个由固定标题部分组成的控制数据包 相似于RTP数据包，其次是结构化的 元素根据RTCP数据包类型而变化。该 格式在第6节中定义。一般，多个RTCP 数据包做为复合RTCP数据包一块儿发送 底层协议的数据包; 这是由长度启用 在每一个RTCP分组的固定报头中。 端口：“传输协议使用的抽象 区分给定主机内的多个目的地 电脑。TCP / IP协议使用小正值来标识端口 整数“。[ 12 ] OSI使用的传输选择器（TSEL） 传输层至关于端口。RTP取决于 下层协议提供一些机制如端口来 复用会话的RTP和RTCP数据包。 传输地址：网络地址和端口的组合 标识传输级端点，例如IP 地址和一个UDP端口。数据包从源传输 传输地址到目的地传输地址。 RTP媒体类型：RTP媒体类型是有效载荷的集合 能够在单个RTP会话中携带的类型。RTP 配置文件将RTP媒体类型分配给RTP有效内容类型。 多媒体会话：一组并发的RTP会话 共同参与者的小组。例如，一个视频会议 （这是一个多媒体会话）可能包含一个音频RTP会话 和一个视频RTP会话。 RTP会话：一组参与者之间的关联 与RTP进行通讯。参与者可能涉及多个 RTP会话。在多媒体会议中，每一个会议 媒体一般是在一个单独的RTP会话中进行的 RTCP包，除非编码自己多路复用 媒体转换成单一的数据流。参与者区分 经过接收不一样的会话使用多个RTP会话 不一样的目标传输地址对，其中一对 的传输地址包括一个网络地址加一对 用于RTP和RTCP的端口。RTP会话中的全部参与者均可以 共享一个共同的目的地传输地址对，如在这种状况下 的IP组播，或者每对的配对可能不一样 参与者，就像我的单播网络同样 地址和端口对。在单播状况下，参与者能够 从会议中的全部其余参与者使用相同的方式接收 一对端口，或者能够为每一个端口使用一对不一样的端口。 Schulzrinne等人 标准跟踪[第9页]
RFC 3550 RTP 2003年7月 RTP会话的显着特色是每一个会话 保持SSRC标识符的完整，独立空间（定义 下一个）。包括在一个RTP会话中的一组参与者 由那些能够接收SSRC标识符传输的组成 由RTP中的任何一个参与者做为SSRC或CSRC （也在下面定义）或RTCP。例如， 使用单播UDP实现第三方会议 参与者从另外两个端口对分别接收。 若是每一个参与者发送有关从中接收的数据的RTCP反馈 另一个参与者只能回到那个参与者那里 会议由三个独立的点对点RTP组成 会话。若是每一个参与者提供有关RTCP的反馈 接收另外一个参与者给另外一个参与者 参与者，那么这个会议就是由一个多方组成的 RTP会话。后一种状况模拟了这种行为 与三者之间的IP组播通讯发生 参与者。 RTP框架容许这里定义的变化，可是a 一般特定的控制协议或应用程序设计 对这些变化施加限制。 同步源（SSRC）：RTP流的源 数据包，由一个32位数字SSRC标识符进行标识 RTP头，以便不依赖于网络地址。 全部来自同步源的数据包都是同一个数据包的一部分 定时和序列号空间，因此一个接收者按组来分组 用于播放的同步源。同步的例子 源包括从a派生的数据包流的发送者 信号源如麦克风或照相机，或RTP混频器 （见下文）。同步源可能会更改其数据格式， 例如，音频编码，随着时间的推移。SSRC标识符是 随机选择的价值意味着在全球范围内独一无二的 特定的RTP会话（参见第8节）。参与者不须要 对于a中的全部RTP会话使用相同的SSRC标识符 多媒体会议; SSRC标识符的绑定是 经过RTCP提供（见第6.5.1节）。若是是参与者 在一个RTP会话中产生多个流，例如来自 单独的摄像机，每一个摄像机都必须被识别为不一样的摄像机 SSRC。 贡献源（CSRC）：RTP数据包流的来源 这对RTP产生的合并流有贡献 搅拌机（见下文）。混频器插入一个SSRC列表 有助于生成a的源的标识符 特定的数据包放入该数据包的RTP头中。这个清单 被称为中国证监会名单。一个示例应用程序是音频 会议在哪里混频器指示全部讲话者的讲话 Schulzrinne等人 标准跟踪[第10页]
RFC 3550 RTP 2003年7月 被组合起来产生传出包，容许接收者 表示当前的讲话者，即便全部的音频数据包 包含相同的SSRC标识符（混频器的标识符）。 结束系统：生成要发送的内容的应用程序 在RTP分组中和/或消耗接收到的RTP的内容 数据包。终端系统能够充当一个或多个同步 来源在特定的RTP会话中，但一般只有一个。 混音器：从中接收RTP数据包的中间系统 或更多的来源，可能会改变数据格式，结合起来 数据包，而后转发一个新的RTP数据包。以来 多个输入源之间的时间一般不会 同步，调音台之间会进行定时调节 并为合并的流生成本身的时间。 所以，来自混频器的全部数据分组将被识别 做为混音器做为他们的同步源。 转换器：转发RTP数据包的中间系统 同步源标识符保持不变。示例 翻译器包括转换编码而不混合的设备， 从多播到单播的复制器以及应用程序级别 过滤器在防火墙。 监视器：接收发送的RTCP数据包的应用程序 RTP会议的参与者，特别是接待 报告和估计目前的服务质量 分布式监测，故障诊断和长期统计。 监视器功能可能被构建到应用程序中， 参加会议，但也多是单独的 应用程序不参与，不发送 或接收RTP数据包（由于它们是分开的 港口）。这些被称为第三方监视器。也是 能够接受第三方监视器接收RTP数据 数据包但不发送RTCP数据包或以其余方式计入 会话。 非RTP意味着：可能须要的协议和机制 除了RTP提供可用的服务。特别是对于 多媒体会议，控制协议可能会分发 组播地址和密钥进行加密，协商 要使用的加密算法，并定义动态映射 在RTP有效载荷类型值和它们的有效载荷格式之间 表明没有预约义有效载荷类型的格式 值。这样的协议的例子包括会话启动 协议（SIP）（RFC 3261 [ 13 ]），ITU建议H.323 [ 14 ]和 应用程序使用SDP（RFC 2327 [ 15 ]），如RTSP（RFC 2326 [ 16 ]）。为了简单 Schulzrinne等人 标准跟踪[第11页]
RFC 3550 RTP 2003年7月 应用程序，电子邮件或会议数据库也可能 用过的。这样的协议和机制的规范是 超出了本文的范围。 。 全部的整数字段都以网络字节顺序进行传输，也就是大部分 重要的字节（八位字节）首先。这个字节顺序一般被称为 大端。传输顺序在[ 3 ] 中详细描述。 除非另有说明，不然数字常量以十进制表示（以10为底）。 全部标题数据都对齐到其天然长度，即16位字段 在偶数偏移量上对齐，32位字段在偏移量上对齐 能够被四整除等。指定为填充的八位字节具备值 零。 Wallclock时间（绝对日期和时间）使用 网络时间协议（NTP）的时间戳格式 秒，相对于1900年1月1日0时UTC [ 4 ]。完整的 分辨率NTP时间戳是一个64位无符号定点数字 在前32位的整数部分和小数部分 最后32位。在一些更紧凑的表明性领域 合适的，只使用中间的32位; 也就是最低的16 整数部分的位和小数部分的高16位。 必须肯定整数部分的高16位 独立。 执行不须要运行网络时间协议 为了使用RTP。能够使用其余时间源，或根本没有 （请参阅第6.4.1节中关于NTP时间戳字段的描述）。 可是，运行NTP可能对同步流有用 从不一样的主机传输。 NTP时间戳将在一年中的某个时间回到零 2036，可是对于RTP的目的，只有NTP对之间的差别 时间戳被使用。只要时间戳对能够 假定在68年以内，使用模块化算术 对于减法和比较使得环绕无关。 Schulzrinne等人 标准跟踪[第12页]
RFC 3550 RTP 2003年7月 。 RTP固定标题字段 RTP头有如下格式： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | X | CC | M | PT | 序号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 时间戳| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 同步源（SSRC）标识符| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | 来源（CSRC）标识符| | .... | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 前十二个八位字节出如今每一个RTP数据包中 CSRC标识符列表仅在由调音台插入时出现。 这些字段具备如下含义： 版本（V）：2比特 该字段标识RTP的版本。版本定义 这个规范是两个（2）。（值1被第一个使用 草案版本的RTP和值0被协议使用 最初是在“大桶”音频工具中实现的。） 填充（P）：1位 若是填充位已设置，则数据包包含一个或多个 附加填充八位字节在不是的一部分 有效载荷。填充的最后八位字节包含如何计数 包括它自己在内的许多填充八位字节应该被忽略。填充 可能须要一些固定块大小的加密算法 或者用于在较低层协议数据中携带多个RTP分组 单元。 扩展名（X）：1位 若是扩展位被设置，则固定的头部必须跟在后面 正好有一个头扩展，具备5.3.1 节 定义的格式。 CSRC计数（CC）：4位 CSRC计数包含后面的CSRC标识符的数量 固定的标题。 Schulzrinne等人 标准跟踪[第13页]
RFC 3550 RTP 2003年7月 标记（M）：1位 标记的解释由配置文件定义。它是 旨在容许重要的事件，如框架边界 在数据包流中被标记。配置文件能够定义额外的 标记位或经过改变指定没有标记位 有效载荷类型字段中的位数（见5.3节）。 有效载荷类型（PT）：7比特 该字段标识RTP有效载荷的格式并肯定 其应用程序的解释。配置文件能够指定一个 有效载荷类型码到有效载荷格式的默认静态映射。 额外的有效载荷类型代码能够经过动态定义 非RTP手段（见第3节）。一组默认映射 音频和视频在伴随RFC 3551 [ 1 ]中指定。一个 RTP源能够在会话期间改变有效载荷类型，可是这个 字段不该该用于复用单独的媒体流 （见第5.2节）。 接收者必须忽略包含有效载荷类型的数据包 理解。 序列号：16位 每一个RTP数据包的序列号增长1 发送，并可能被接收方用来检测丢包和 恢复数据包序列。序号的初始值 应该是随机的（不可预知的）进行已知的明文攻击 在加密上比较困难，即便源码自己没有 根据9.1节的方法加密，由于 数据包可能会流经一个翻译器。技巧 在[ 17 ] 中讨论选择不可预测的数字。 时间戳：32位 时间戳反映了第一个八位字节的采样时刻 RTP数据包。采样瞬间必须来自a 时钟的增量单调和线性的时间容许 同步和抖动计算（见第6.4.1节）。该 时钟分辨率必须足够知足所须要的 同步精度和测量分组到达抖动 （每一个视频帧一个tick一般是不够的）。时钟 频率取决于做为有效载荷携带的数据的格式 并在配置文件或有效负载格式中被静态指定 规范定义格式，或者能够指定 动态地为经过非RTP手段定义的有效载荷格式。若是 RTP包是周期性生成的标称采样 即时从采样时钟肯定要使用，而不是一个 读取系统时钟。例如，固定速率音频 时间戳时钟可能会每增长一个 采样周期。若是音频应用程序读取块覆盖 Schulzrinne等人 标准跟踪[第14页]
RFC 3550 RTP 2003年7月 来自输入设备的160个采样周期，时间戳将是 每一个这样的街区增长了160个，无论是否 块在数据包中传输或者静音。 时间戳的初始值应该是随机的，至于 序列号。几个连续的RTP数据包将会相等 时间戳，若是他们（逻辑）当即生成，例如属于 到相同的视频帧。连续的RTP包可能包含 若是数据未被传输，则时间戳不是单调的 按照它被采样的顺序，如MPEG插值的状况 视频帧。（发送的数据包的序列号 仍然是单调的。） 来自不一样媒体流的RTP时间戳可能会提早 不一样的费率，一般有独立的，随机的抵消。 所以，虽然这些时间戳足以重建 单个流的时间，直接比较RTP时间戳 来自不一样媒体的同步效果不佳。 相反，对于每一个媒体的RTP时间戳是相关的 经过将其与来自参考的时间戳配对来当即采样 时钟（wallclock）表明数据的时间 对应于RTP时间戳被采样。参考资料 时钟由全部媒体共享以进行同步。时间戳 对不是在每一个数据包中传输，而是在较低的 RTCP SR数据包中的速率，如6.4节所述。 采样时刻被选择做为参考点 RTP时间戳，由于它是发送端点所知道的 对于全部媒体都有一个通用的定义，与编码无关 延误或其余处理。目的是容许同步 介绍全部同时采样的媒体。 应用程序传输存储的数据而不是数据采样 实时一般使用派生的虚拟演示时间线 从挂钟时间肯定什么时候下一帧或其余单位 存储的数据中的每种介质都应该被呈现。在这 的状况下，RTP时间戳将反映的演示时间 每一个单位。也就是说，每一个单元的RTP时间戳将是 与单元当前的挂钟时间有关 虚拟展现时间线。实际的演示发生 一段时间后由接收器肯定。 描述预录制视频的实况音频叙述的例子 说明了选择抽样时刻的意义 参考点。在这种状况下，视频将是 在当地呈现给叙述者查看并将是 同时使用RTP进行传输。a的“采样时刻” 在RTP中传输的视频帧将经过参考创建 Schulzrinne等人 标准跟踪[第15页]
RFC 3550 RTP 2003年7月 它的时间戳到了那个视频帧的时间 提交给解说员。音频RTP的采样时刻 包含叙述者言语的分组将由...创建 在音频采样时参考相同的挂钟时间。 音频和视频甚至能够由不一样的主机传输 两台主机的参考时钟是同步的 意味着如NTP。接收者而后能够同步呈现 的音频和视频数据包的RTP时间戳 使用RTCP SR数据包中的时间戳对。 SSRC：32位 SSRC字段标识同步源。这个 标识符应该随机选择，意图是没有两个 在同一个RTP会话中的同步源将有 相同的SSRC标识符。一个算法生成一个例子 随机标识符见附录A.6。虽然 多个来源选择相同标识符的几率是 低，全部的RTP实现必须准备好检测和 解决冲突。 第8节描述的几率 碰撞和解决冲突的机制 检测RTP级别转发循环的惟一性 SSRC标识符。若是来源改变其来源运输 地址，它也必须选择一个新的SSRC标识符来避免 解释为一个循环的来源（见第8.2节）。 证监会名单：0-15项，每项32位 中国证监会的名单肯定了有效载荷的贡献来源 包含在这个包里。标识符的数量由下式给出 CC领域。若是有超过15个来源， 只有15个能够被识别。CSRC标识符被插入 混频器（见第7.1节），使用SSRC标识符 来源。例如，对于SSRC的音频数据包 全部来源的标识符混合在一块儿建立一个 数据包被列出，容许正确的说话者指示 接收器。 复用RTP会话 为了有效协议处理，多路复用点的数量 应该最小化，如集成层处理中所述 设计原则[ 10 ]。在RTP中，复用是由... ...提供的 目的地传输地址（网络地址和端口号）哪一个 对于每一个RTP会话是不一样的。例如，在电话会议中 由分别编码的音频和视频媒体组成，每一个媒体 应该在一个单独的RTP会话中进行 运输地址。 Schulzrinne等人 标准跟踪[第16页]
RFC 3550 RTP 2003年7月 独立的音频和视频流不该该单独携带 RTP会话并基于有效载荷类型或SSRC进行解复用 领域。使用不一样的RTP媒体类型交错数据包 使用相同的SSRC会带来几个问题： 若是两个音频流共享相同的RTP会话， 相同的SSRC值，一个是改变编码，从而得到 一个不一样的RTP负载类型，不会有通常的方法 识别哪一个流已经改变了编码。 2. SSRC被定义为识别单个时间和序列号 空间。交错多种有效载荷类型将须要 不一样的时间空间，若是媒体时钟速度不一样并且会 须要不一样的序列号空间来告诉哪一个有效载荷 类型遭受丢包。 3. RTCP发送者和接收者报告（见第6.4节）只能 描述每一个SSRC的一个时序和序列号空间，而不是 携带有效载荷类型字段。 4.一个RTP混音器将不能组合交错流 不兼容的媒体合并成一个流。 在一个RTP会话中携带多个媒体排除：使用 不一样的网络路径或网络资源分配 适当; 若是须要，接收媒体的一个子集 例如，若是视频超过可用带宽，则只是音频; 和接收器实现使用单独的进程的 不一样的媒体，而使用单独的RTP会话许可 不管是单进程仍是多进程实现。 每一个媒体使用不一样的SSRC，但发送相同的 RTP会话将避免前三个问题，但不是最后一个 二。 另外一方面，复用多个相同的来源 在一个RTP会话中使用不一样的SSRC值是正常的 多播会话。上面列出的问题不适用：RTP 调音台能够结合多个音源，例如和同样 全部的治疗都是适用的。这也多是适当的 使用不一样的SSRC值复用相同介质的流 在最后两个问题不适用的其余状况下。 Schulzrinne等人 标准跟踪[第17页]
RFC 3550 RTP 2003年7月 RTP头的特定于配置文件的修改 现有的RTP数据包头被认为是完整的 在全部应用程序中共同须要的一组功能 RTP可能支持的类。可是，与ALF保持一致 设计原则，标题能够经过修改或定制 在配置文件规范中定义的添加，同时仍然容许 独立于配置文件的监视和录制工具来运行。 标记位和有效载荷类型字段携带配置文件特定的 信息，可是因为许多信息被分配在固定标题中 应用程序预计须要他们，不然可能不得不 添加另外一个32位字来保存它们。包含八位字节 这些字段可能会被一个配置文件从新定义，以适应不一样的状况 要求，例如具备更多或更少的标记位。若是 有任何标记位，应该位于最多的位置 自配置文件独立监视器以来的八位字节的显着位 可能可以观察到分组丢失模式之间的相关性 和标记位。 o特定有效载荷所需的附加信息 格式，好比视频编码，应该在有效载荷中携带 包的一部分。这可能在老是一个头 出如今有效载荷部分的开始处，或者可能被指示 经过数据模式中的保留值。 o若是特定类别的应用程序须要额外的 独立于有效载荷格式的功能，下面的配置文件 这些应用程序运行应该定义额外的固定 在现有的SSRC领域以后当即跟随领域 固定标题。这些应用程序将可以快速和 在配置文件无关的状况下直接访问其余字段 监视器或录像机仍然能够处理RTP数据包 只解释前十二个八位字节。 若是事实证实，共同须要额外的功能 跨全部配置文件，那么应该定义一个新版本的RTP 对固定标题进行永久更改。 RTP头扩展 提供了一个扩展机制来容许我的 实现实验新的有效载荷格式无关 功能，须要额外的信息进行 RTP数据包头。这个机制是这样设计的 扩展头可能会被其余互操做忽略 还没有扩展的实现。 Schulzrinne等人 标准跟踪[第18页]
RFC 3550 RTP 2003年7月 请注意，这个扩展头仅用于有限的使用。 这个机制的大多数潜在用途会更好地作另外一个 方式，使用上一节中描述的方法。对于 例如，固定标题的特定于配置文件的扩展名较少 处理起来很昂贵，由于它不是有条件的，也不是一个变量 位置。特定有效载荷所需的附加信息 格式不该该使用这个头扩展名，但应该进入 分组的有效载荷部分。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 由配置文件|定义 长度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 标题扩展| | .... | 若是RTP头中的X位是一个可变长度的头 在CSRC列表以后，扩展名必须附加到RTP头 若是有的话。标题扩展名包含一个16位长度的字段 计算扩展名中32位字的数量，不包括 四个字节的扩展头（所以零是有效的长度）。只要 一个扩展名能够附加到RTP数据头。容许 多个互操做实现到每一个实验 独立使用不一样的头扩展，或容许一个 特殊的实现来试验多种类型的 头扩展，头扩展的前16位留下 打开区分标识符或参数。的格式 这16位是由profile配置文件定义的 这些实现正在运行。这个RTP规范呢 没有定义任何头扩展自己。 。 RTP控制协议（RTCP）基于周期性传输 的控制包给会话中的全部参与者，使用相同的方式 分配机制做为数据包。底层协议 必须提供数据和控制数据包的复用 例如使用与UDP分开的端口号。RTCP执行四个 功能： 主要功能是提供关于质量的反馈 数据分配。这是RTP做用的组成部分 传输协议，并与流量和拥塞有关 其余传输协议的控制功能（参见第10节） 拥塞控制的要求）。反馈多是 用于自适应编码[控制直接有用18，19 ]，但 IP多播实验代表，它也是 Schulzrinne等人 标准跟踪[第19页]
RFC 3550 RTP 2003年7月 相当重要的是从接收器得到反馈来诊断故障 分布。向全部人发送接收反馈报告 参与者容许正在观察问题的人进行评估 不管这些问题是本地仍是全球。随着分配 像IP组播这样的机制，对一个实体也是可能的 如没有涉及的网络服务提供商 在会议期间接收反馈信息并做为一个 第三方监视器来诊断网络问题。这个反馈 功能是由RTCP发送者和接收者报告执行的， 如6.4节所述。 2. RTCP为RTP携带一个持久的传输级标识符 来源称为规范名称或CNAME，第6.5.1节。以来 若是发现冲突，则SSRC标识符可能会更改 程序从新启动，接收器须要CNAME跟踪 每一个参与者。接收者也可能须要CNAME 未来自集合中给定参与者的多个数据流相关联 相关的RTP会话，例如同步音频和 视频。媒体间同步也须要NTP和RTP 数据发送方包含在RTCP数据包中的时间戳。 3.前两个功能要求全部参与者发送RTCP 数据包，所以速率必须被控制以使RTP到达 扩大到大量的参与者。经过每一个 参与者将其控制包发送给全部其余人，每一个人均可以 独立观察参与者人数。这个数字是 用来计算数据包发送的速率，如 在6.2节中解释。 4.第四，可选功能是传达最小的会话控制 信息，例如参与者身份 显示在用户界面中。这极可能是有用的 在参与者进入的“松散控制的”会议中 离开没有会员控制或参数协商。RTCP 做为到达全部参与者的便利渠道，可是 不必定指望支持全部的控制 通讯要求的应用程序。更高一级 会话控制协议，这是超出了这个范围 文件，多是须要的。 功能1-3应该在全部环境中使用，特别是在 IP组播环境。RTP应用程序设计者应该避免 机制只能在单播模式下工做，不能扩展到 更大的数字。RTCP的传输能够单独控制 对于发送者和接收者，如在第6.2节中，例 例如来自接收器的反馈不是单向链路 可能。 Schulzrinne等人 标准跟踪[第20页]
RFC 3550 RTP 2003年7月 非规范性说明：在组播路由方法中 称为源特定多播（SSM），只有一个发送者 每一个“通道”（源地址，组地址对），和 接收者（频道源除外）不能使用多播 与其余渠道成员直接沟通。该 这里建议适应SSM只能经过第6.2节的 彻底关闭接收者的RTCP选项。将来的工做将会 指定适用于SSM的RTCP，以便从接收方反馈 能够维持。 RTCP数据包格式 这个规范定义了几个RTCP分组类型来携带一个 各类控制信息： SR：发件人报告，用于发送和接收统计 参与者是主动发件人 RR：接收者报告，用于接收参与者的接收统计 那些不是主动的发送者，而是与SR的组合 主动发送者报告超过31个来源 SDES：来源说明项目，包括CNAME BYE：表示参与结束 APP：应用程序特定的功能 每一个RTCP数据包以与RTP数据相似的固定部分开始 数据包，而后是结构化元素，多是可变的 长度根据数据包类型，但必须在32位结束 边界。对齐要求和固定长度字段 包含每一个数据包的一部分以使RTCP数据包“可堆叠”。 多个RTCP数据包能够链接而不须要任何干预 分隔符来造成一个复合RTCP数据包，它是在一个单一的发送 下层协议的数据包，例如UDP。没有 显式计数复合包中的单个RTCP包 由于低层协议有望提供一个总体 肯定复合包的结束长度。 能够处理复合分组中的每一个单独的RTCP分组 独立，对订单或组合没有要求 数据包。可是，为了执行协议的功能， 下面的限制是强加的： Schulzrinne等人 标准跟踪[第21页]
RFC 3550 RTP 2003年7月 o接收统计（在SR或RR中）应该常常发送 带宽限制将容许最大化的分辨率 统计，因此每一个周期性地发送复合RTCP 分组必须包含一个报告分组。 o新接收者须要尽快接收源的CNAME 可能肯定来源并开始关联媒体 目的如唇同步，因此每一个复合RTCP数据包也必须 包括SDES CNAME，除了复合RTCP数据包时 按9.1节所述进行部分加密分割。 o化合物中可能首先出现的数据包类型的数量 数据包须要被限制以增长固定位的数量 在第一个字和成功验证的可能性 RTCP数据包针对错误的RTP数据包或其余数据包 无关的数据包。 所以，全部RTCP分组至少必须在一个复合分组中发送 两个单独的数据包，格式以下： 加密前缀：当且仅当复合数据包是 根据9.1节的方法加密，它必须是 以每一个化合物的随机32位数量做为前缀 数据包传输。若是填充须要进行加密，则为 务必添加到复合包的最后一个包中。 SR或RR：复合包中的第一个RTCP包必须 始终是一个报告数据包，以方便标题验证 如附录A.2所述。即便没有数据，状况也是如此 发送或接收，在这种状况下，必须发送一个空的RR，甚至是 若是复合报文中惟一的其余RTCP报文是BYE。 额外的RR：若是接收的来源的数量 统计报告超过31个，将适合的数量 到一个SR或RR数据包中，那么附加的RR数据包应该遵循 最初的报告包。 SDES：必须包含一个包含CNAME项目的SDES数据包 在每一个复合RTCP分组中，除了在9.1节中提到的之外。 其余来源的描述项目能够选择包括，若是 须要一个特定的应用程序，受带宽限制 约束条件（见6.3.9节）。 BYE或APP：其余RTCP数据包类型，包括那些还没有被使用的数据包 定义，能够按照任何顺序，除了BYE应该是 与SSRC / CSRC给定的最后一个数据包。数据包类型可能会出现 不止一次。 Schulzrinne等人 标准跟踪[第22页]
RFC 3550 RTP 2003年7月 我的RTP参与者应该只发送一个复合RTCP 数据包每报告间隔为了每一个RTCP带宽 参与者被正确地估计（见第6.2节），除了何时 如上所述，复合RTCP分组被分割以进行部分加密 在9.1节。若是有太多的来源来适应全部的 必要的RR数据包合并为一个复合RTCP数据包而不超过 网络路径的最大传输单位（MTU） 将适合一个MTU的子集应该包含在每一个中 间隔。子集应该跨多个循环选择 以便报告全部来源。 建议翻译人员和混音人员合并我的RTCP 来自多个来源的数据包被转发到一个 复合数据包在任何可行的状况下，以分摊数据包 开销（见第7节）。一个示例RTCP复合包可能 由混合器生产的如图1所示 一个复合包将超过网络路径的MTU，应该是这样的 被分割成多个较短的复合包进行传输 在底层协议的单独数据包中。这不会损害 因为每一个复合分组表示RTCP带宽估计 至少有一个不一样的参与者。请注意，每一个化合物 分组必须以SR或RR分组开始。 一个实现应该忽略带有类型的传入RTCP数据包 它不知道。额外的RTCP数据包类型能够注册 互联网号码分配机构（IANA）的描述 第15节。 若是加密：随机的32位整数 | | [---------数据包--------] [----------数据包----------] [ - 数据包] | | 接收器块大块 V报告项目项目项目项目 -------------------------------------------------- ------------------ R [SR #sendinfo＃site1＃site2] [SDES #CNAME PHONE #CNAME LOC] [BYE ## why] -------------------------------------------------- ------------------ | | | <-----------------------复合包----------------------- > | | <-------------------------- UDP packet -------------------- -----> | ＃：SSRC / CSRC标识符 图1：一个RTCP复合包的例子 Schulzrinne等人 标准跟踪[第23页]
RFC 3550 RTP 2003年7月 RTCP传输间隔 RTP旨在容许应用程序自动缩放 会议规模从几个参与者到数千人不等。对于 例如，在音频会议中，数据业务本质上是自组织的， 限制，由于一次只有一两我的会说话，因此 多播分配，任何给定链路上的数据速率仍然保持 与参与者的数量无关。 可是，控制流量不是自我限制的。若是接待 每一个参与者的报告都是以恒定的速度发送的 控制流量将随着参与者的数量呈线性增加。 所以，速率必须经过动态计算来缩小 RTCP数据包传输之间的时间间隔。 对于每一个会话，都假定数据流量受到影响 一个称为“会话带宽”的聚合限制被分配 参与者们。这个带宽可能被保留，而且是有限的 由网络执行。若是没有保留，可能会有 其余限制，取决于环境，创建的 会议使用的“合理的”最大限度，这将是 会话带宽。会话带宽能够根据一些选择 成本或对可用网络带宽的先验知识 会话。它有些独立于媒体编码，可是 编码选择可能会受到会话带宽的限制。一般状况下， 会话带宽是发送者的标称带宽的总和 预计将同时活跃。对于电话会议音频，这个 数字一般是一个发送者的带宽。对于分层 编码，每一层都是一个单独的RTP会话与本身的会话 带宽参数。 会话带宽参数预计由a提供 会话管理应用程序在调用媒体应用程序时， 但媒体应用程序可能会根据单一发件人设置默认值 为会话选择的编码的数据带宽。该 应用程序也能够强制基于多播的带宽限制 范围规则或其余标准。全部参与者必须使用相同的 会话带宽的值，以便相同的RTCP时间间隔 被计算。 控制和数据流量的带宽计算包括： 层传输和网络协议（例如，UDP和IP） 是资源预留系统须要知道的。该 应用程序也能够被指望知道这些协议是哪个 正在使用。连接级别标题不包含在计算中 该数据包将被封装为不一样的链路层头 它旅行。 Schulzrinne等人 标准跟踪[第24页]
RFC 3550 RTP 2003年7月 控制流量应该限制在一个小的已知分数 的会话带宽：小，这样的主要功能 传输协议携带数据不受损害; 已知因此 控制流量能够包含在给定的带宽规范中 到资源预留协议，以便每一个参与者均可以 独立计算其份额。控制流量带宽是 除了数据流量的会话带宽。它是 建议为RTCP添加会话带宽的一小部分 固定在5％。也建议使用RTCP的1/4 带宽专用于正在发送数据的参与者 在与大量的接收器，但少数的会议 发件人，新加入的参与者将更快收到 发送网站的CNAME。当发件人的比例是 超过1/4的参与者，发件人获得他们的 完整的RTCP带宽的比例。而这些和价值 区间计算中的其余常量并不重要 会话中的参与者必须使用相同的值 间隔将被计算。所以，这些常数应该是 固定为特定的配置文件。 配置文件能够指定控制流量带宽多是a 会话的单独参数而不是严格的百分比 会话带宽。使用单独的参数， 自适应应用程序来设置RTCP带宽与a一致 “典型”数据带宽低于最大带宽 由会话带宽参数指定。 配置文件能够进一步指定控制流量带宽 能够分为两个单独的会话参数 参与者是活跃的数据发送者而不是那些; 让咱们调用参数S和R.按照推荐 那RTCP带宽的四分之一专用于数据发送者 对于这两个参数，推荐的默认值是1.25％ 和3.75％。发件人比例较大时 比参与者的S /（S + R），发件人获得他们的比例 这些参数的总和。使用两个参数容许RTCP 接待报告将彻底关闭一个特定的会议 经过将非数据发送者的RTCP带宽设置为零 保持数据发送者的RTCP带宽不为零，以便发送者 报告仍然能够发送用于媒体间同步。车削 关闭RTCP接收报告是不推荐的，由于它们是须要的 对于第6节开头列出的功能，尤为如此 接收质量反馈和拥塞控制。可是，这样作 可能适用于在单向链路上运行的系统 对于不须要接收质量反馈的会话 或接收者的活泼，并有其余方法来避免 拥塞。 Schulzrinne等人 标准跟踪[第25页]
RFC 3550 RTP 2003年7月 计算复合RTCP的传输间隔 数据包还应该有一个下界，以免有突发 当参与者数量超过容许的带宽时 规模小，交通不平顺，规模大 数字。它也保持报告间隔变得过小 在像网络分区这样的暂时中断期间 当分区愈合时适应被延迟。在应用程序 启动时，应在第一个复合RTCP以前施加一个延迟 分组被发送以容许从RTCP分组接收时间 其余参与者如此报告的时间间隔将会收敛到 正确的价值更快。这个延迟可能会被设置为一半 最小间隔容许更快通知新的 参加者在场。推荐值为固定的最小值 间隔是5秒。 实现能够将最小RTCP间隔缩小到更小 值与会话带宽参数成反比 有如下限制： o对于多播会话，只有活动的数据发送者能够使用 减少最小值来计算传输间隔 复合RTCP数据包。 o对于单播会话，能够使用缩小的值 那些不是主动数据发送者的参与者，以及 在发送初始化合物RTCP包以前延迟可能为零。 ○对于全部的会话，固定的最小值应该在何时使用 计算参与者超时间隔（参见第6.3.5节） 因此那些不使用减小值的实现 其余参与者不会超时发送RTCP数据包 过早。 o以秒为单位的最小值的推荐值为360 会话带宽除以千比特/秒。这最低限度 对于大于72kb / s的带宽，小于5秒。 设计了6.3节和附录A.7中 描述的算法 以达到本节所述的目标。它计算出 发送复合RTCP数据包之间的间隔来划分容许的 控制参与者之间的流量带宽。这容许一个 应用程序提供快速响应的小型会议，为 例如，全部参与者的身份是重要的，但 自动适应大型会议。算法合并 如下特色： Schulzrinne等人 标准跟踪[第26页]
RFC 3550 RTP 2003年7月 计算的RTCP数据包之间的时间间隔线性变化 组中的成员数量。这是线性因素 在总结时容许控制流量不变 跨全部成员。 o RTCP数据包之间的间隔随机变化 范围[0.5,1.5]乘以计算的时间间隔以免意外 同步全部参与者[ 20 ]。第一个RTCP数据包 加入会议后发送的也是随机变化的延迟 是最小RTCP间隔的一半。 ○对平均复合RTCP分组大小的动态估计是 计算，包括全部收到和发送的数据包 自动适应控制量的变化 信息进行。 o因为计算的时间间隔取决于数量 观察组员，可能会有不良的启动效应 当一个新用户加入一个现有的会议，或许多用户 同时加入新的会议。这些新用户将在最初 有不正确的团体成员的估计，所以他们的 RTCP传输间隔过短。这个问题能够 若是许多用户同时加入会话，这是很重要 至 处理这个，一个叫作“定时器从新考虑”的算法是 采用。这个算法实现了一个简单的退避机制 这会致使用户阻止RTCP数据包的传输 团体人数正在增长。 o当用户离开会议时，或者用BYE或者超时， 组成员减小，从而计算出的间隔 应该减小。使用“反向从新考虑”算法 容许成员更快地缩短回应的时间间隔 组员的减小。 BYE数据包的处理方式与其余RTCP数据包不一样。 当用户离开一个组，并但愿发送一个BYE包时， 能够在其下一个调度的RTCP分组以前这样作。然而， BYE的传输遵循避免的退避算法 BYE包的洪水应该是大量的成员 同时离开会议。 这个算法能够用于全部参与者的会话 容许发送。在这种状况下，会话带宽参数是 我的发送者的带宽乘以数量的乘积 参与者，而RTCP的带宽是5％。 该算法的操做细节在如下部分给出 跟随。 附录A.7给出了一个示例实现。 Schulzrinne等人 标准跟踪[第27页]
RFC 3550 RTP 2003年7月 维护会话成员的数量 RTCP数据包间隔的计算取决于一个估计值 参加会议的网站数量。新的网站是 当他们被听到时被添加到计数中，而且每一个都应该输入 在由SSRC或CSRC标识符索引的表格中建立 8.2节）跟踪他们。能够考虑新的条目 直到有多个携带新的SSRC的数据包才有效 接收（见附录A.1），或直到一个SDES RTCP包包含 该SSRC的CNAME已收到。条目能够从中删除 当一个RTCP表与一个相应的SSRC的BYE包对照表时 标识符被接收，除了一些零散的数据包可能 在BYE以后到达而且致使条目被再造。代替， 该条目应该被标记为已经收到BYE，而后被删除 通过适当的延迟。 参与者能够标记另外一个网站处于非活动状态，或者若是还没有删除 若是没有收到少许的RTP或RTCP数据包，则为有效 的RTCP报告间隔（推荐5）。这提供了一些 对数据包丢失的鲁棒性。全部网站必须具备相同的价值 对于这个乘数，必须计算大体相同的值 RTCP报告间隔，以便此超时正常工做。 所以，这个乘数应该是固定的一个特定的配置文件。 对于有大量参与者的会议，可能会是 维护一个表来存储SSRC标识符是不切实际的 全部这些状态信息。一个实现能够使用SSRC 采样，如[ 21 ]中所述，以减小存储要求。 一个实现能够使用任何其余相似的算法 性能。一个关键的要求是考虑任何算法 虽然它不该该大大低估组的大小 可能高估了。 RTCP数据包发送和接收规则 如何发送的规则，以及接收RTCP时的操做规则 数据包在这里列出。一个容许在其中运行的实现 多播环境或多点单播环境必须知足6.2节 的要求。这样的实现能够使用 算法在本节中定义，以知足这些要求，或者能够 只要提供等价的或更好的，就能够使用其余一些算法 性能。一个限于双方的实施 单播操做应该仍然使用RTCP的随机化 传输间隔能够避免多重意外同步 在相同环境中运行的实例，但能够省略“计时器” 从新考虑“和”反向从新考虑“算法 6.3.3，6.3.6和6.3.7。 Schulzrinne等人 标准跟踪[第28页]
RFC 3550 RTP 2003年7月 为了执行这些规则，会话参与者必须维护几个 件状态： tp：RTCP数据包最后一次传输的时间; tc：当前时间; tn：RTCP分组的下一个调度传输时间; 会员：在时间tn会议成员的估计数量 最后从新计算; 成员：会议次数的最新估计 成员; 发件人：最新的发件人数量估计 会议; rtcp_bw：目标RTCP带宽，即总带宽 该会话的全部成员将用于RTCP数据包， 以每秒八位字节为单位。这将是一个指定的分数 提供给应用程序的“会话带宽”参数 启动。 we_sent：若是应用程序发送了数据，则为true 自从第二个之前的RTCP报告被传送。 avg_rtcp_size：平均复合RTCP数据包大小，以八位组为单位， 经过此参与者发送和接收的全部RTCP数据包。该 大小包括低层传输和网络协议头 （如UDP和IP），如第6.2节所述。 initial：若是应用程序还没有发送，则为true的标志 一个RTCP数据包。 这些规则中的不少都利用了二者之间的“计算间隔” 数据包传输。这个时间间隔以下所述 部分。 计算RTCP传输间隔 为了保持可伸缩性，数据包之间的平均间隔由一个 会话参与者应按照组大小进行缩放。这个间隔 被称为计算间隔。它是经过组合一个 上述状态的数量。计算 间隔T而后以下肯定： Schulzrinne等人 标准跟踪[第29页]
RFC 3550 RTP 2003年7月 1.若是发件人的数量少于或等于25％ 会员（会员）的间隔取决因而否 参与者是否为发件人（基于we_sent的值）。 若是参与者是发件人（we_sent为true），则常量C为 设置为平均RTCP数据包大小（avg_rtcp_size）除以25％ 的RTCP带宽（rtcp_bw），常数n被设置为 发件人数量。若是we_sent不正确，则设置常量C. 到平均RTCP数据包大小除以RTCP的75％ 带宽。常数n被设置为接收器的数量 （成员 - 发件人）。若是发件人的数量大于 25％，发件人和收件人一块儿处理。常数C 被设置为平均RTCP分组大小除以总RTCP 带宽和n被设置为成员总数。就像声明的那样 在6.2节中，RTP配置文件能够指定RTCP带宽 能够由两个独立的参数明肯定义（称它们为S 和R）为发件人和那些参与者 不是。在这种状况下，25％的分数变成S /（S + R） 75％部分变成R /（S + R）。请注意，若是R是零， 发件人的百分比从不大于S /（S + R），而且 执行必须避免被零除。 2.若是参与者还没有发送RTCP数据包（变量 初始值为真），常数Tmin设置为2.5秒，不然 设置为5秒。 3.肯定性计算间隔Td被设置为max（Tmin，n * C）。 4.计算出的间隔T被设定为均匀分布的数字 在肯定性计算间隔的0.5和1.5倍之间。 5. T的结果值除以e-3/2 = 1.21828来补偿 定时器复议算法收敛到的事实 RTCP带宽的值低于预期的平均值。 这个过程致使了一个随机的间隔，可是这个间隔是 平均而言，RTCP带宽至少为发送方和服务器提供了25％的带宽 休息给接收者。若是发件人构成四分之一以上 的程序，这个程序之间平分带宽 全部的参与者，平均。 初始化 加入会话后，参与者将tp初始化为0，tc为 0，发件人为0，发件人为1，发件人为1，发件人为假， rtcp_bw到会话带宽的指定分数，初始值 为true，avg_rtcp_size为第一个RTCP的可能大小 应用程序稍后将构建的数据包。计算 而后计算间隔T，而且计划第一个分组 Schulzrinne等人 标准跟踪[第30页]
RFC 3550 RTP 2003年7月 时间tn = T。这意味着发送定时器被设置 在时间T到期。请注意，应用程序能够使用任何须要的 实现这个计时器的方法。 参与者将其本身的SSRC添加到成员表中。 接收RTP或非BYE RTCP包 从SSRC的参与者收到RTP或RTCP数据包时 不在成员表中，SSRC被添加到表中，而 一旦参与者被验证，成员的价值就会被更新 如第6.2.1节所述。每一个处理都发生相同的处理 证监会在一个通过验证的RTP数据包。 从SSRC不参与者收到RTP包时 在发件人表中，SSRC被添加到表中，而且值 发件人更新。 对于收到的每一个复合RTCP数据包，avg_rtcp_size的值是 更新： avg_rtcp_size =（1/16）* packet_size +（15/16）* avg_rtcp_size 其中packet_size是刚收到的RTCP包的大小。 接收RTCP BYE包 除了6.3.7节中描述的状况，当一个RTCP BYE是 若是收到的数据包是一个RTCP BYE数据包，则发送 SSRC是检查成员表。若是有的话，那就是 从表中删除，并更新成员的值。该 SSRC而后检查发件人表。若是存在，输入 将从表中删除，并更新发件人的值。 此外，为了使RTCP分组的传输速率更高 适应组员身份的变化，下面的“反向” 从新考虑“算法应该在BYE数据包执行时执行 收到，减小会员的价值低于pmembers： o tn的值根据如下公式进行更新： tn = tc +（会员/会员）*（tn - tc） o tp的值根据如下公式进行更新： tp = tc - （members / pmembers）*（tc - tp）。 Schulzrinne等人 标准跟踪[第31页]
RFC 3550 RTP 2003年7月 o下一个RTCP分组在tn时间从新调度传输， 如今是更早。 o pmembers的值等于成员。 该算法不会阻止来自组的大小估计 因为过早而不正确地降到零 当一个大会议的大多数参与者同时离开时超时 一些保持。该算法确实使估计返回到 正确的价值更迅速。这种状况是不寻常的， 后果是充分无害的，认为这个问题 只是次要的关注。 定时SSRC 偶尔间隔，参与者必须检查是否有任何 其余参与者超时。要作到这一点，参与者 计算肯定性（没有随机因素） 计算出接收者的时间间隔Td，即we_sent为false。 任何其余会议成员，由于没有发送RTP或RTCP数据包 时间tc - MTd（M是超时乘数，默认为5） 时间到。这意味着其SSRC从成员列表中删除， 并更新成员。对发件人执行相似的检查 名单。发件人列表中还没有发送RTP数据包的任何成员 由于时间tc - 2T（在最后两个RTCP报告间隔内）是 从发件人列表中删除，并更新发件人。 若是有任何成员超时，则反向从新考虑算法 在6.3.4节中描述应该被执行。 参与者必须至少每一个RTCP进行一次检查 传输间隔。 发送计时器到期 当分组传输定时器到期时，参与者执行 如下操做： 传输间隔T按6.3.1 节 所述计算，包括随机因子。 o若是tp + T小于或等于tc，则一个RTCP包是 传输。tp设置为tc，那么T的另外一个值是 按上一步计算，tn设为tc + T 传输定时器被设置为在时间tn再次到期。若是tp + T 大于tc，则tn被设置为tp + T。没有RTCP分组 传输。传输定时器设置为在时间tn过时。 Schulzrinne等人 标准跟踪[第32页]
RFC 3550 RTP 2003年7月 会员设置为会员。 若是发送RTCP分组，则初始值设置为 假。此外，更新avg_rtcp_size的值： avg_rtcp_size =（1/16）* packet_size +（15/16）* avg_rtcp_size 其中packet_size是刚传输的RTCP数据包的大小。 传输BYE包 当一个参与者但愿离开一个会话时，一个BYE包是 传送给该事件的其余参与者。为了 当许多参与者离开时，避免BYE数据包的泛滥 系统，参与者必须执行如下算法 参与者选择的会员人数超过50人 离开。这个算法篡夺了成员变量的正常角色 要计算BYE数据包，而不是： o当参与者决定离开系统时，tp被重置为 tc，目前的时间，会员和会员都初始化为1， 初始设置为1，we_sent设置为false，发件人设置为0， avg_rtcp_size设置为复合BYE报文的大小。 计算出的间隔T。BYE包是 预约时间tn = tc + T o每当收到来自其余与会者的BYE数据包时， 不管是否参加者，成员都会加1 是否存在于成员表中，以及SSRC采样是否存在 无论BYE SSRC是否包括在内，均可以使用 在样本中。其余RTCP数据包时，成员不增长 或收到RTP数据包，但仅用于BYE数据包。一样的， avg_rtcp_size仅针对收到的BYE数据包进行更新。发件人 当RTP包到达时不更新; 它仍然是0。 o BYE包的传输遵循规则 如上所述发送常规的RTCP分组。 这容许BYE数据包当即被发送，可是控制它们 总带宽使用。在最坏的状况下，这可能会致使RTCP 控制数据包使用正常的两倍带宽（10％） - 5％ 非BYE RTCP包和BYE的5％。 一个不想等待上述机制的参与者 容许BYE包的传输能够离开组 发送一个BYE。该参与者最终将被超时 由其余小组成员。 Schulzrinne等人 标准跟踪[页33]
RFC 3550 RTP 2003年7月 若是团体规模估算的成员小于50的时候 参与者决定离开，参与者能够发送BYE包 当即。或者，参与者能够选择执行 上面的BYE退避算法。 在任何状况下，都不会发送RTP或RTCP数据包的参与者 当他们离开组时，毫不能发送BYE包。 更新we_sent 若是参与者发送了RTP，则变量we_sent包含true 数据包最近，不然为false。这个决心是由 使用相同的机制来管理其余的一套 发件人列表中列出的参与者。若是参与者发送 一个RTP包，当we_sent为false时，它将本身添加到发件人 表并将we_sent设置为true。反向从新考虑 在6.3.4节中描述的算法应该可能被执行 减小发送SR包以前的延迟。每次都有另外一个RTP 分组被发送，该分组的传输时间被保持 在桌子里。正常的发送者超时算法而后被应用于 参与者 - 若是一个RTP包没有被传送 时间tc - 2T，参与者从发件人表中删除本身， 递减发件人计数，并将we_sent设置为false。 源描述带宽的分配 本规范定义了几个源描述（SDES）项 除了必须的CNAME项目，如NAME（我的名称） 和EMAIL（电子邮件地址）。它也提供了一种定义新的方法 特定于应用程序的RTCP数据包类型。应用程序应该运行 谨慎分配控制带宽到这个额外的 信息，由于它会减慢接收的速度 报告和CNAME被发送，从而削弱了CNAME的性能 协议。建议不要超过20％的RTCP 分配给单个参与者的带宽用于承载 附加信息。并且，它并非所有 SDES项目将被包括在每一个应用程序中。那些是 包括应该被分配一部分带宽根据 他们的效用。它不是动态地估计这些分数 建议将百分比静态转换为 根据项目的典型长度报告间隔计数。 例如，应用程序可能被设计为仅发送CNAME，名称 和EMAIL，而不是其余任何人。NAME可能会更高 优先级高于EMAIL，由于NAME会连续显示 在应用程序的用户界面中，而EMAIL将被显示 只有在要求时。在每一个RTCP时间间隔，一个RR数据包和一个 带有CNAME项目的SDES数据包将被发送。对于一个小会议 Schulzrinne等人 标准跟踪[页34]
RFC 3550 RTP 2003年7月 以最小时间间隔运行，即每5秒开启一次 平均。每隔三秒（15秒），一个额外的项目会 包含在SDES包中。八次中有七次会这样 成为名称的项目，每八（2分钟）它将是 电子邮件项目。 当多个应用程序使用交叉应用程序一致操做时 绑定经过一个共同的CNAME为每一个参与者，例如在一个 由每一个媒体的RTP会话组成的多媒体会议 额外的SDES信息只能在一个RTP会话中发送。该 其余会话将只携带CNAME项目。特别是这个 方法应该适用于分层的多个会话 编码方案（见第2.4节）。 发件人和收件人报告 RTP接收器使用RTCP报告提供接收质量反馈 根据是否能够采起两种形式之一的分组 接收者也是发件人。惟一的区别 发送者报告（SR）和接收者报告（RR）形式 类型代码，是发件人报告包含一个20字节的发件人 信息部分供主动发信人使用。若是一个 网站自发布以来已经发送了任何数据包 上次报告或上一次报告，不然发布“无线电规则”。 SR和RR格式都包含零个或多个接收报告 块，每一个同步源一个这个 接收方自上次报告以来收到了RTP数据包。 报告不是针对中国证监会上市的来源 名单。每一个接收报告块提供有关数据的统计信息 从该区块中指出的特定来源收到。因为a 最多31个接收报告块将适合SR或RR数据包， 额外的RR数据包应该在最初的SR或RR以后堆叠 数据包，以包含全部来源的接收报告 在上次报告以来的时间间隔内听到。若是也有 许多来源将全部必要的RR数据包合并到一个化合物中 RTCP数据包，不超过网络路径的MTU，那么只有 将适合一个MTU的子集应该包含在每一个中 间隔。子集应该跨多个循环选择 以便报告全部来源。 接下来的部分将定义这两个报告的格式，它们可能如何 若是应用程序须要，能够以特定于配置文件的方式扩展 额外的反馈信息，以及如何使用这些报告。 译文和混音器的接收报告详情请参阅 第7节。 Schulzrinne等人 标准跟踪[第35页]
RFC 3550 RTP 2003年7月 SR：发送者报告RTCP分组 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 头| V = 2 | P | RC | PT = SR = 200 | 长度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 发件人SSRC | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 发件人| NTP时间戳，最重要的单词| info + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | NTP时间戳，最低有效字| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | RTP时间戳| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 发件人的数据包数| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 发件人的八位字节计数| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 报告| SSRC_1（SSRC第一来源）| 块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 1 | 分数损失| 累积的丢包数| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 扩展的最高序列号收到| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 到达间隔抖动| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 最后一个SR（LSR）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 自上次SR（DLSR）|以后的延迟 + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 报告| SSRC_2（第二来源SSRC）| 块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 2：...： + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | 特定于文件的扩展| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 发送者报告包可能由三部分组成 若是定义了第四个特定于文件的扩展部分。 第一部分，标题长度是8个八位字节。田野有 如下含义： 版本（V）：2比特 标识RTP的版本，在RTCP数据包中是相同的 如在RTP数据包中同样。本规范定义的版本 是两（2）。 Schulzrinne等人 标准跟踪[第36页]
RFC 3550 RTP 2003年7月 填充（P）：1位 若是填充位被设置，则这个单独的RTCP分组包含 一些额外的填充八位字节在不是的一部分 控制信息但包含在长度字段中。该 填充的最后八位字节是多少个填充字节的计数 应该被忽略，包括它自己（这将是一个倍数 四）。某些加密算法可能须要填充 固定块大小。在一个复合RTCP数据包中，填充是惟一的 由于复合包是一个单独的包所须要的 加密做为一个总体的方法在9.1节。所以，填充 只能添加到最后一个单独的数据包，若是填充 被添加到该数据包中，填充位必须仅在该数据包上设置 包。这个约定有助于描述的头部有效性检查 在附录A.2中，容许从一些早期检测数据包 在第一个错误地设置填充位的实现 单独的数据包和添加填充到最后一个单独的数据包。 接收报告计数（RC）：5位 包中包含的接收报告块的数量。一个 零值是有效的。 分组类型（PT）：8比特 包含常量200以将其标识为RTCP SR数据包。 长度：16位 这个32位字的RTCP数据包的长度减1， 包括头和任何填充。（一个的偏移量 零有效长度并避免可能的无限循环 扫描复合RTCP数据包，同时计数32位字 避免了4的倍数的有效性检查。 SSRC：32位 这个发起者的同步源标识符 SR数据包。 第二部分，发件人信息，长度为20个八位字节 存在于每一个发件人报告包中。它总结了这些数据 来自此发件人的传输。这些字段具备如下内容 含义： NTP时间戳：64位本报告显示时 的时钟时间（请参阅第4节） 发送，以便它能够与时间戳结合使用 在接收报告中返回来自其余接收者的测量 往返传播给那些接收者。接收者应该 指望时间戳的测量准确性多是 限于远低于NTP时间戳的分辨率。该 时间戳的测量不肯定度不会被指示出来 Schulzrinne等人 标准跟踪[第37页]
RFC 3550 RTP 2003年7月 可能不知道。在一个没有wallclock概念的系统上 时间，但确实有一些系统特定的时钟，如“系统” 正常运行时间“，发件人能够使用该时钟做为参考来计算 相对NTP时间戳。通常选择一个是很重要的 使用时钟，以便若是使用单独的实现来生产 多媒体会话的各个流，所有 实现将使用相同的时钟。直到2036年， 相对和绝对时间戳会在高位有所不一样 （无效）比较会显示出很大的差别; 那么一个 但愿再也不须要相对时间戳。发件人 没有挂钟或通过时间的概念能够设置NTP 时间戳为零。 RTP时间戳：32位 与上面的NTP时间戳同时对应，可是以 相同的单位和与RTP相同的随机偏移量 数据包中的时间戳。这个对应关系能够用于 媒体内和媒体间同步的NTP源 时间戳是同步的，而且能够由媒体独立使用 接收器来估计标称的RTP时钟频率。注意 在大多数状况下，这个时间戳不会等于RTP 时间戳在任何相邻的数据包中。相反，它必须是 从相应的NTP时间戳使用计算 RTP时间戳计数器和实时时间之间的关系 经过按期检查wallclock时间来维护 抽样即时。 发送者的包计数：32位 发送方发送的RTP数据包总数 由于直到这个SR数据包开始传输 产生。若是发件人更改其计数，计数应该被重置 SSRC标识符。 发送者的八位组数：32比特 有效载荷字节的总数（即不包括标题或 填充）由发送方自RTP发送的数据包 直到这个SR数据包开始传输 产生。若是发件人更改其计数，计数应该被重置 SSRC标识符。这个字段能够用来估计平均值 净荷数据速率。 第三部分包含零个或多个接收报告块 这取决于此发件人从其余来源收到的其余来源的数量 最后的报告。每一个接收报告块传送统计信息 从单个同步源接收RTP数据包。 接收者不该该在源发生变化时进行统计 SSRC标识符因为碰撞。这些统计是： Schulzrinne等人 标准跟踪[第38页]
RFC 3550 RTP 2003年7月 SSRC_n（源标识符）：32位 信息来源的SSRC标识符 接待报告块属于。 分数丢失：8位 自SSRC_n以来，RTP数据包的一部分丢失 先前的SR或RR包被发送，表示为固定点 编号与字段的左边缘的二进制点。（那 至关于乘之后的整数部分 损失分数除以256）。这个分数被定义为数字 丢失的数据包除以预期的数据包数量 在下一段定义。一个实现如图所示 附录A.3。若是因为重复形成的损失是负面的，那么 分数丢失被设置为零。请注意，一个接收器不能告诉 最后一个收到的包是否丢失 没有接收报告块的来源 若是来自该源的全部分组在上次报告期间发送 间隔已经丢失。 累计丢包数：24位 来自源SSRC_n的RTP数据包的总数 自接待开始以来已经失去。这个数字是 定义为数据包的数量少于预期的数量 实际收到的数据包，接收数据包的数量 包括任何迟到或重复。所以，数据包 迟到不计算在内，损失多是负数 若是有重复。预期的数据包数量是 定义为收到的扩展的最后序列号，如 接下来定义，少于收到的初始序列号。这可能 按附录A.3所示进行计算。 扩展的最高序列号收到：32位 低16位包含在一个接收到的最高序列号 来自SSRC_n的RTP数据包，最重要的16个 位以相应的计数扩展该序列号 序列号周期，能够根据这个维护 算法见附录A.1。请注意，不一样的接收器内 同一个会话将生成不一样的扩展名 序列号，若是他们的开始时间差别显着。 到达间隔抖动：32位 RTP数据包统计方差的估计 到达间隔时间，以时间戳单位测量并表示为 无符号整数。间隔抖动J被定义为 差值D in的平均误差（平滑的绝对值） 在接收端的数据包间隔与一对的发送端相比 的数据包。以下面的公式所示，这至关于 两个数据包的“相对传输时间”的差别; Schulzrinne等人 标准跟踪[第39页]
RFC 3550 RTP 2003年7月 相对传输时间是数据包的RTP之间的差别 时间戳和到达时间的接收机时钟， 在相同的单位测量。 若是Si是数据包i的RTP时间戳，而且Ri是时间戳 到达分组i的RTP时间戳单元，而后是两个分组 我和j，D能够表示为 D（i，j）=（Rj-Ri） - （Sj-Si）=（Rj-Sj） - （Ri-Si） 到达间隔抖动应该连续计算 数据包i是从源SSRC_n接收的，使用它 该分组与前一个分组i-1的差值D 到达（不必定按顺序），根据公式 J（i）= J（i-1）+（| D（i-1，i）| - J（i-1））/ 16 每当接收报告发出时，J的当前值是 采样。 抖动计算必须符合这里指定的公式 以容许配置文件无关的监视器生效 对来自不一样实施的报告的解释。 该算法是最优的一阶估计器和增益 参数1/16给出了一个很好的降噪比 保持合理的收敛速度[ 22 ]。一个样品 实现显示在附录A.8。参见6.4.4节的 讨论不一样的数据包持续时间和延迟的影响 在传输以前。 最后一个SR时间戳（LSR）：32位 NTP时间戳中的64位中的中间32位（如中所述） 第4节）做为最新的RTCP发送者报告的一部分收到 （SR）数据包从源SSRC_n。若是还没有收到SR， 该字段设置为零。 自上次SR（DLSR）以来的延迟：32位 延迟时间以1/65536秒为单位表示 从源SSRC_n接收最后一个SR包并发送 接待报告块。若是尚未收到SR数据包 从SSRC_n，DLSR字段被设置为零。 让SSRC_r表示发送这个接收者报告的接收者。 源SSRC_n能够计算往返传播延迟 SSRC_r经过记录该接收报告块时的时间A. 接收。它使用的是计算总往返时间A-LSR 最后一个SR时间戳（LSR）字段，而后将该字段减去 （A-LSR-DLSR），将往返传播延迟留下。这个 Schulzrinne等人 标准跟踪[第40页]
RFC 3550 RTP 2003年7月 如图2所示。时间以十六进制显示 32位字段的表示和等效的浮点数 点十进制表示。冒号表示一个32位字段 分为16位整数部分和16位小数部分。 这能够用做距离群集的近似度量 接收器，尽管一些链路有很是不对称的延迟。 [1995年11月10日11：33：25.125 UTC] [1995年11月10日11：33：36.5 UTC] n SR（n）A = b710：8000（46864.500 s） -------------------------------------------------- --------------> v ^ ntp_sec = 0xb44db705 v ^ dlsr = 0x0005：4000（5.250s） ntp_frac = 0x20000000 v ^ lsr = 0xb705：2000（46853.125s） （3024992005.125 s）v ^ rv ^ RR（n） -------------------------------------------------- --------------> | <-DLSR-> | （5.250秒） A 0xb710：8000（46864.500 s） DLSR -0x0005：4000（5.250 s） LSR -0xb705：2000（46853.125 s） ------------------------------- 延迟0x0006：2000（6.125秒） 图2：往返时间计算示例 Schulzrinne等人 标准跟踪[第41页]
RFC 3550 RTP 2003年7月 RR：接收者报告RTCP分组 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 头| V = 2 | P | RC | PT = RR = 201 | 长度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 包发件人SSRC | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 报告| SSRC_1（SSRC第一来源）| 块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 1 | 分数损失| 累积的丢包数| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 扩展的最高序列号收到| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 到达间隔抖动| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 最后一个SR（LSR）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 自上次SR（DLSR）|以后的延迟 + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 报告| SSRC_2（第二来源SSRC）| 块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 2：...： + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | 特定于文件的扩展| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 接收方报告（RR）报文的格式与 除了分组类型字段包含常量以外的SR分组 201和发件人信息的五个字被省略（这些是 NTP和RTP时间戳以及发送者的包和八位字节计数）。 其他字段与SR数据包的含义相同。 一个空的RR包（RC = 0）务必放在一个复合的头部 RTCP包没有数据传输或接收时 报告。 扩展发件人和收件人报告 配置文件应该为发件人定义配置文件特定的扩展名 报告和接收者报告，若是有额外的信息 须要按期报告发件人或收件人。这个 方法应该优先用于定义另外一个RTCP数据包 键入，由于它须要较少的开销： o数据包中较少的八位字节（没有RTCP头或SSRC字段）; Schulzrinne等人 标准跟踪[第42页]
RFC 3550 RTP 2003年7月 更简单和更快速的解析，由于应用程序正在运行 配置文件将被编程为老是指望扩展字段 在接待报告后的直接访问地点。 分机是发信人或收信人报告中的第四部分 在接收报告阻塞以后到来的分组，若是 任何。若是须要额外的发件人信息，则发件人 报告它将首先包含在扩展部分，可是 接收者报告它不会出现。若是信息 接收者将被包括在内，那么数据应该被构造为一个 与现有接收报告阵列平行的块阵列 块; 即区块数目会由区域市政总署指明 领域。 分析发送者和接收者报告 预计接收质量反馈将不会有用 只适用于发件人，也适用于其余收件人和第三方 显示器。发件人能够根据其修改传输 反馈; 接收者能够肯定问题是不是本地的， 区域或全球; 网络管理员能够使用配置文件无关 监视器只接收RTCP数据包，而不是相应的 RTP数据包来评估其网络的性能 组播分发。 累积计数用于发件人信息和 接收器报告块，以即可以计算差别 任何两份报告均可以在短时间和长期内进行测量 期间，并提供抵御损失的报告。该 最近两次收到的报告之间的差别能够用来 估计最近的分配质量。NTP时间戳 被包括在内，以即可以从这些差别计算费率 在两个报告之间的间隔。因为时间戳是 独立于数据编码的时钟速率，这是可能的 实现编码和配置文件无关的质量监视器。 一个计算示例就是间隔内的丢包率 在两个接待报告之间。累积的差别 丢失的数据包数量会致使在该时间间隔内丢失的数字。 所收到的最后一个序列号的差别给出了 间隔期间预期的分组数量。的比例 这两个是间隔内的丢包率。这个比例 若是这两个报告是应该等于分数丢失的领域 连续的，但不然可能不会。每秒的损失率能够 经过将损失分数除以NTP的差值来得到 时间戳，以秒表示。收到的数据包的数量是 预期的分组数目减去丢失的数目。的数量 Schulzrinne等人 标准跟踪[第43页]
RFC 3550 RTP 2003年7月 预期的分组也能够用来判断统计有效性 的任何损失估计。例如，丢失的五个数据包中有一个有一个 比1000中的200低。 从发件人信息，第三方监视器能够计算出 平均有效载荷数据速率和平均数据包速率 间隔没有收到数据。以二者的比例 给出平均有效载荷大小。若是能够假设的话 丢失与数据包大小无关，而后是数据包数量 由特定接收机接收的平均有效负载大小（或 相应的分组大小）给出了表观吞吐量 可用于该接收器。 除了容许长期数据包的累积计数以外 使用报告之间的差别进行损失测量，分数 失去的领域提供一个单一报告的短时间测量。 随着会议规模的扩大，这变得更加剧要 接收状态信息可能不会保留给全部的接收者 或报告之间的时间间隔变得足够长，只有一个 报告多是从一个特定的接收器收到的。 到达间隔抖动字段提供了第二个短时间测量 网络拥塞。数据包丢失跟踪持续拥塞 抖动测量跟踪瞬态拥塞。抖动测量 可能会致使拥塞，致使数据包丢失。该 到达间隔抖动场只是抖动的一个快照 报告的时间，而不是定量的。 相反，它是用来比较来自多个报告的 一个接收器随着时间的推移或从多个接收器，例如，在一个 单一的网络，在同一时间。容许比较 接收机，重要的是抖动按照计算 全部接收器都使用相同的公式。 由于抖动计算是基于RTP时间戳的 表示分组中的第一个数据被采样的瞬间， 在采样时刻和时间之间的任何延迟的变化 数据包的传输将会影响抖动 计算。音频数据包会出现这种延迟的变化 持续时间不一样 视频编码也会出现这种状况，由于 对于一个帧的全部分组，时间戳是相同的 数据包并非所有同时传输。中的变化 延迟直到传输确实下降了抖动的准确度 计算做为网络自己的行为的度量， 可是考虑到接收缓冲区是合适的 必须适应它。当抖动计算被用做a 比较测量，因为变化的（恒定）份量 延迟，直到传输消失，使一个变化 Schulzrinne等人 标准跟踪[第44页]
RFC 3550 RTP 2003年7月 而后能够观察网络抖动份量，除非它是相对的 小。若是变化很小，那极可能是 可有可无的。 SDES：源描述RTCP包 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 头| V = 2 | P | SC | PT = SDES = 202 | 长度| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 大块| SSRC / CSRC_1 | 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | SDES项目| | ... | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 大块| SSRC / CSRC_2 | 2 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | SDES项目| | ... | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + SDES包是一个三层结构，由一个头部和一个头部组成 零或多个块，每一个块都由描述的项目组成 在该块中标识的来源。这些项目被描述 分别在随后的部分。 版本（V），填充（P），长度： 如SR数据包所述（见第6.4.1节）。 分组类型（PT）：8比特 包含常量202以将其标识为RTCP SDES数据包。 源数（SC）：5位 包含在这个SDES包中的SSRC / CSRC块的数量。一个 零值是有效的，可是没用。 每一个块由一个SSRC / CSRC标识符组成，后跟一个列表 零或多个项目，其中载有关于SSRC / CSRC的信息。 每一个块在32位边界上开始。每一个项目包括一个8- 位类型字段，一个8位八位字节计数描述的长度 文本（所以不包括这个双字节标题）和文本 自己。请注意，文本不能超过255个八位字节，可是 这与限制RTCP带宽消耗的须要是一致的。 Schulzrinne等人 标准跟踪[第45页]
RFC 3550 RTP 2003年7月 文本根据RFC 2279 [ 5 ]中规定的UTF-8编码进行编码。US-ASCII是这种编码的一个子集，不须要 额外的编码。多字节编码的存在是 经过设置一个字符的最重要的位来表示 价值之一。 项目是连续的，即项目不是单独填充到a 32位边界。文本不是空终止的， 八位字节编码包括空字节。每一个块中的项目列表 必须由一个或多个空字节终止，其中第一个是 解释为零的项目类型以表示列表的结尾。 空项目类型八位字节以后没有长度字节，可是额外的空值 必须包括八位字节，直到下一个32位为止 边界。请注意，此填充与表示的填充是分开的 RTCP头中的P位。一个有零项的块（四个空值 八位字节）是有效的，可是没用。 终端系统发送一个包含本身的源的SDES数据包 标识符（与固定RTP报头中的SSRC相同）。搅拌机 发送包含每一个贡献源的块的一个SDES包 从中收到SDES信息，或多个完整的 上述格式的SDES包若是有31个以上的话 来源（见第7节）。 目前定义的SDES项目将在下一节中介绍。 只有CNAME项是强制性的。这里显示的一些项目多是 只对特定配置文件有用，可是项目类型是所有的 从一个共同的空间分配，以促进共享使用和简化 简介独立的应用程序。其余项目可能被定义在 经过在IANA中注册类型号码来进行配置文件的描述 第15节。 CNAME：规范的终点标识符SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | CNAME = 1 | 长度| 用户和域名... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + CNAME标识符具备如下属性： o由于随机分配的SSRC标识符可能会改变，若是一个 发现冲突或者程序从新启动时，CNAME 必须包括项目以提供来自SSRC的绑定 标识符与源（发送者或接收者）的标识符 保持不变。 Schulzrinne等人 标准跟踪[第46页]
RFC 3550 RTP 2003年7月 o与SSRC标识符同样，CNAME标识符也应该是 在一个RTP会话中的全部参与者中是惟一的。 o提供跨多个媒体工具的绑定 参与一组相关的RTP会话，CNAME应该是 为该参与者固定。 o为了方便第三方监控，CNAME应该是合适的 不管是一个程序或一我的来定位来源。 所以，CNAME应该算法导出而不是 尽量手动输入。为了知足这些要求， 应使用如下格式，除非配置文件指定了 备用语法或语义。CNAME项目应该有格式 若是用户名不可用，则为“user @ host”或“host” 用户系统。对于这两种格式，“主机”是彻底合格的 实时数据来源主机的域名， 根据RFC 1034 [ 6 ]，RFC 1035 [ 7 ]和RFC 1123的第2.1节 [ 8 ]中规定的规则进行格式化; 或标准的ASCII 在所使用的接口上表示主机的数字地址 用于RTP通讯。例如，标准的ASCII IP版本4地址的表示也是“点分十进制” 称为虚线四，IP版本6，地址是文本 以冒号分隔的十六进制数字组（以 如RFC 3513 [ 23 ]中详述的变化）。其余地址类型是 但愿具备相互独特的ASCII表示。该 彻底合格的域名对于观察者来讲更为方便 而且能够避免另外发送名称项目的须要，可是多是这样 在一些操做中难以或不可能得到可靠的 环境。可能在这样的环境中运行的应用程序 应该使用地址的ASCII表示。 例子是“doe@sleepy.example.com”，“doe@192.0.2.89”或者 对于多用户系统，“doe @ 2201：056D :: 112E：144A：1E24”。在一个系统上 没有用户名，例子就是“sleepy.example.com”， “192.0.2.89”或“2201：056D :: 112E：144A：1E24”。 用户名应当以“finger”之类的程序的形式存在 “谈话”能够使用，即它一般是登陆名而不是 我的的名字。主机名不必定彻底相同 一个在参与者的电子邮件地址中。 若是是，则此语法将不会为每一个源提供惟一的标识符 应用程序容许用户从一个生成多个来源 主办。这样的申请将不得不依靠SSRC进一步 识别来源，或该应用程序的配置文件将具备 指定CNAME标识符的附加语法。 Schulzrinne等人 标准跟踪[第47页]
RFC 3550 RTP 2003年7月 若是每一个应用程序独立建立其CNAME，则生成 CNAME可能与提供绑定所需的内容不一样 跨多个属于一个参与者的媒体工具 相关的RTP会话。若是须要跨媒体绑定，则多是 每一个工具的CNAME须要外部配置 协调工具的价值是相同的。 应用程序编写者应该知道专用网络地址 例如RFC 1918 [ 24 ]中提出的Net-10分配， 可能会建立不是全球惟一的网络地址。这个 会致使非惟一的CNAME若是主机与私人地址和 没有直接的IP链接到公共互联网的RTP 数据包经过RTP级别转发到公共Internet 翻译。（另见RFC 1627 [ 25 ]。）为了处理这种状况， 应用程序能够提供一种手段来配置一个惟一的CNAME，可是 翻译人员将CNAME翻译成私人文件的负担 地址公共地址，若是有必要保持私人地址 从被暴露。 名称：用户名称SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | NAME = 2 | 长度| 通用名称的来源... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 这是用来形容来源的真实名称，例如“John Doe， 位再循环器“，它能够是用户想要的任何形式 会议等应用，这种形式的名称多是最多的 但愿在参与者列表中显示，所以多是 最常发送CNAME之外的项目。配置文件可能 肯定这样的重点。NAME值预计将保持不变 至少在会议期间不变。它不该该 依靠在本届会议的全部与会者中都是独一无二的。 电子邮件：电子邮件地址SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | EMAIL = 3 | 长度| 来源的电子邮件地址... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 电子邮件地址根据RFC 2822 [ 9 ] 格式化 例如，“John.Doe@example.com”。预计EMAIL值 在会议期间保持不变。 Schulzrinne等人 标准跟踪[第48页]
RFC 3550 RTP 2003年7月 PHONE：电话号码SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | PHONE = 4 | 长度| 电话号码的来源... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 电话号码应该用加号来代替格式 国际接入码。例如，“+1 908 555 1212”为一个 在美国的数字。 LOC：地理用户位置SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | LOC = 5 | 长度| 网站的地理位置... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 取决于应用程序，不一样程度的细节 适合这个项目。对于会议应用程序，字符串 像“新泽西州美利山”可能就足够了，而对于一个 积极的徽章系统，像“房间2A244，AT＆T BL MH”多是字符串 适当。细节的程度留给实施 和/或用户，但格式和内容能够由配置文件规定。 LOC值预计在a的持续时间内保持不变 会话，除了移动主机。 工具：应用程序或工具名称SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TOOL = 6 | 源程序的长度|名称/版本。... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 一个字符串，提供应用程序的名称和可能的版本 生成流，例如“录像工具1.2”。这个信息可能 对于调试目的是有用的，而且相似于邮件程序或 邮件系统版本SMTP头。预计TOOL值 在会议期间保持不变。 Schulzrinne等人 标准跟踪[第49页]
RFC 3550 RTP 2003年7月 注意：通知/状态SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 注= 7 | 长度| 请注意有关来源... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 为这个项目建议如下语义，但这些或 其余语义能够由配置文件显式定义。笔记 项目用于描述当前状态的瞬态消息 的来源，例如“在电话中，不能说话”。或者，在一个 研讨会，这个项目可能被用来表达对话的标题。它 应该只用来携带特殊的信息，不该该 被全部参与者按期包括在内，由于这会慢 下降接收报告和CNAME发送的速率 损害协议的性能。特别是，它应该 不做为一个项目包含在用户的配置文件也不包括在内 自动生成，现在天的报价。 因为NOTE项目在激活时可能很重要， 其余非CNAME项目（如NAME）的传输速率 可能会减小，因此NOTE项能够占用RTCP的那部分 带宽。当瞬态消息变为无效时，注意 项目应该继续传送几回相同 重复率但用一串长度为零的信号来表示 接收器。可是，接收者也应该考虑注意项目 若是没有收到一小部分重复，则无效 速率，或者20-30 RTCP间隔。 PRIV：私有扩展SDES项目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | PRIV = 8 | 长度| 前缀长度|前缀字符串... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ... | 值字符串... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 此项目用于定义实验或特定于应用程序的SDES 扩展。该项目包含由长度字符串组成的前缀 随后是填充项目其他部分的值字符串 并携带所需的信息。前缀长度字段是8 位长。前缀字符串是由人员定义的名称 该PRIV项目是独一无二的其余PRIV项目 应用可能会收到。应用程序建立者可能会选择 使用应用程序名称加上附加的子类型标识 Schulzrinne等人 标准跟踪[第50页]
RFC 3550 RTP 2003年7月 须要。或者，建议其余人选择一个名字 基于它们所表明的实体，而后协调使用 该实体内的名称。 请注意，前缀会消耗项目总数中的一些空间 长度为255个八位字节，因此前缀应该保持为短 可能。这个设施和受约束的RTCP带宽应该 不要超载; 并非要知足全部的控制 全部应用程序的通讯要求。 SDES PRIV前缀不会由IANA注册。若是某种形式的 PRIV项目被证实是通用的，它应该是 指定了一个按期的SDES项目类型在IANA注册，因此没有 前缀是必需的。这简化了使用并增长了传输 效率。 BYE：再见RTCP分组 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | SC | PT = BYE = 203 | 长度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | SSRC / CSRC | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ：...： + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + （opt）| 长度| 离开的缘由 ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + BYE数据包表示一个或多个源再也不 活性。 版本（V），填充（P），长度： 如SR数据包所述（见第6.4.1节）。 分组类型（PT）：8比特 包含常量203以将其标识为RTCP BYE分组。 源数（SC）：5位 此BYE包中包含的SSRC / CSRC标识符的数量。 计数值为零是有效的，可是没用。 应该发送BYE包的规则在中指定6.3.7和8.2 节。 Schulzrinne等人 标准跟踪[第51页]
RFC 3550 RTP 2003年7月 若是BYE包被混频器接收到，混频器应该转发 具备SSRC / CSRC标识符的BYE分组不变。若是一台搅拌机 关闭，它应该发送一个BYE数据包列出全部的贡献 它处理的来源，以及它本身的SSRC标识符。（可选） BYE包可能包含一个8位八位字节计数，而后是许多 指示离开缘由的文本的八位字节，例如“相机” 故障“或”检测到RTP回路“，字符串相同 如SDES所描述的编码。若是字符串填充数据包 到下一个32位的边界，字符串不是空终止的。若是 不是，BYE包必须用空的八位字节填充到下一个32位字节， 位边界。该填充与P所示的填充是分开的 位在RTCP头。 APP：应用程序定义的RTCP数据包 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | 子类型| PT = APP = 204 | 长度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | SSRC / CSRC | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 名称（ASCII）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 应用程序依赖的数据... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + APP数据包旨在做为新的应用程序的实验使用 而且开发了新的功能，而不须要包类型值 注册。具备没法识别名称的APP数据包应该被忽略。 通过测试，若是更普遍的使用是合理的，建议 每一个APP包都被从新定义，而没有子类型和名称字段 使用RTCP数据包类型向IANA注册。 版本（V），填充（P），长度： 如SR数据包所述（见第6.4.1节）。 子类型：5位 能够用做子类型来容许一组APP数据包 在一个惟一的名称下定义，或者用于任何依赖于应用程序 数据。 分组类型（PT）：8比特 包含常量204以将其标识为RTCP APP分组。 Schulzrinne等人 标准跟踪[页52]
RFC 3550 RTP 2003年7月 名称：4个八位字节 定义一组APP数据包的人选择的名字 对于这个应用程序可能的其余APP数据包是惟一的 接收。应用程序建立者可能会选择使用 应用程序名称，而后协调子类型的分配 值给其余想要定义新数据包类型的人 应用。或者，建议其余人选择 基于它们所表明的实体的名称，而后协调使用 该实体内的名称。名字被解释为a 四个ASCII字符序列，大写和小写 被视为不一样的字符。 应用程序相关数据：可变长度 应用程序相关的数据可能会或可能不会出如今APP数据包中。 它由应用程序解释，而不是RTP自己。它必须 是32位长的倍数。 。 除了终端系统以外，RTP还支持“翻译员”的概念， 和“搅拌机”，能够被视为“中间系统” RTP级别。虽然这种支持增长了一些复杂性 议定书，对这些职能的需求已经明确肯定 经过在多播音频和视频应用中的实验 互联网。第 2.3 节中给出的翻译器和混音器的使用例子来自防火墙和低带宽 链接，这二者均可能保持。 概述 RTP转换器/混频器链接两个或更多的传输级别 “云”。一般，每一个云由一个公共网络定义 传输协议（如IP / UDP）加上一个多播地址和 传输级别目标端口或一对单播地址和 端口。（网络级协议翻译器，如IP版本4到 IP版本6，可能没法在RTP中呈如今云中） 系统能够做为多个RTP的翻译器或混音器 会议，但每一个会议都被视为一个逻辑上独立的实体。 为了不在翻译器或混音器时产生循环 安装，必须遵照如下规则： o由翻译器和混音器链接的每一个云 参与一个RTP会话必须与全部的不一样 至少其中一个参数（协议，地址， 端口），或者必须与其余网络隔离。 Schulzrinne等人 标准跟踪[第53页]
RFC 3550 RTP 2003年7月 o第一条规则的衍生物不能是多重的 翻译器或混音器并联，除非有一些 他们安排他们划分要转发的来源的集合。 一样，全部能够经过一个或多个通讯进行通讯的RTP终端系统 更多的RTP转换器或混音器共享相同的SSRC空间，也就是说， 全部这些终端系统中的SSRC标识符必须是惟一的。 8.2节描述了由哪一个碰撞解决算法 SSRC标识符保持惟一，并检测到循环。 可能有许多品种的翻译和搅拌机设计 不一样的目的和应用。一些例子是添加或 删除加密，更改数据或底层的编码 协议，或在多播地址和一个或多个地址之间复制 单播地址。译员和混音师之间的区别是 翻译者经过不一样的数据流 分别来源，而混音器结合起来，造成一个新的 流： 转换器：使用SSRC标识符转发RTP数据包 完整; 这使接收机可以识别 即便来自全部来源的数据包经过 经过同一位译者并携带翻译者的网络 源地址。有些翻译会经过翻译 数据不变，但其余人可能会改变数据的编码 所以RTP数据净荷类型和时间戳。若是有多个数据 数据包被从新编码为一个，反之亦然，一个翻译器必须 分配新的序列号到传出的数据包。损失 传入的分组流可能引发相应的间隙 传出序号。接收器没法检测到存在 除非他们经过其余手段知道什么有效载荷 类型或传输地址被原始源使用。 混音器：接收来自一个或多个RTP数据包的流 来源，可能会改变数据格式，合并流入 以某种方式，而后转发组合的流。自从 多个输入源之间的时序一般不会 同步，调音台之间会进行定时调节 并为合并流生成本身的时间，因此它 是同步源。所以，全部的数据包转发 由混频器必须标记混频器本身的SSRC标识符。 为了保留原始来源的身份 有助于混合包，搅拌机应该插入他们的 SSRC标识符进入CSRC标识符列表后的固定 数据包的RTP头。搅拌机也是本身的 某些数据包的贡献源应该明确地包含它 在该CSRC列表中拥有SSRC标识符。 Schulzrinne等人 标准跟踪[第54页]
RFC 3550 RTP 2003年7月 对于某些应用来讲，混音器可能不被接受 肯定中国证监会名单上的来源。不过，这个介绍了 涉及这些来源的循环的危险没法被发现。 一个混音器的优势，而不是翻译器的应用程序 音频是输出带宽被限制到一个源的输出带宽 即便在输入端有多个源是活动的。这多是 对于低带宽链路很重要。缺点是这样的 输出端的接收器不能控制哪一个接收器 来源是经过或静音，除非有一些机制 实施用于调音台的远程控制。再生的 混音器的同步信息也意味着接收器不能 作原始流的媒体间同步。多层次 媒体混音器能够作到。 [ E1 ] [E6] | | E1：17 | E6：15 | | | E6：15 V M1：48（1,17）M1：48（1,17）V M1：48（1,17） （M1）-------------> <T1> -----------------> <T2> --------- -----> [E7] ^ ^ E4：47 ^ E4：47 E2：1 | E4：47 | | M3：89（64,45） | | | [E2] [E4] M3：89（64,45）| | 传说： [E3] --------->（M2）----------->（M3）------------ | [结束系统] E3：64M2:12（64）^（混合器） | E5：45 <译者> | [E5]来源：SSRC（中国证监会） -------------------> 图3：带终端系统，混音器和转换器的示例RTP网络 混合器和翻译器的集合如图3所示 说明它们对SSRC和CSRC标识符的影响。在图中， 最终系统显示为矩形（名为E），译者为 三角形（名为T）和混合器（椭圆形）（名为M）。符号“M1： 48（1,17）“表示发起混频器M1的数据包，由标识 M1的（随机）SSRC值48和两个CSRC标识符1和17， 从E1和E2的分组的SSRC标识符中复制。 翻译器中的RTCP处理 除了转发数据包，也许是修改过的翻译 混音器也必须处理RTCP数据包。在不少状况下，他们会 把从终端系统接收到的复合RTCP分组拆开 Schulzrinne等人 标准跟踪[第55页]
RFC 3550 RTP 2003年7月 聚合SDES信息并修改SR或RR数据包。 该信息的重传能够由分组触发 到达或经过翻译器或混音器的RTCP间隔定时器 自己。 不修改数据包的翻译器，例如一个 只是在多播地址和单播之间进行复制 地址，也能够简单地转发RTCP数据包。一个 翻译器以某种方式转换有效载荷必须作出 在SR和RR信息中进行相应的转换使之成为可能 仍然反映了数据和接待的特色 质量。这些转换器不能简单地转发RTCP数据包。在 通常来讲，翻译者不该该从中聚合SR和RR数据包 不一样的来源到一个数据包，由于这会减小 基于LSR和LSR的传播时延测量精度 DLSR字段。 SR发件人信息：译员不会自行生成 发送者信息，但转发从一个接收到的SR数据包 云对其余人。SSRC保持不变，但发件人 若是翻译须要，信息必须修改。若是一个 翻译者改变数据编码，它必须改变“发件人的 字节计数“字段，若是它也将几个数据包合并成的话 一个输出包，它必须改变“发送者的包计数” 领域。若是它改变时间戳频率，它必须改变 SR包中的“RTP时间戳”字段。 SR / RR接收报告块：转换器转发接收 从一个云收到的报告给其余人。请注意这些 流向与数据相反的方向。SSRC离开了 完整。若是一个翻译器将多个数据包合并为一个 输出数据包，所以改变序列号，它必须 对数据包丢失字段进行逆操做 “扩展的最后序号”字段。这多是复杂的。在 极端的状况下，可能没有有意义的翻译方式了 接待报告，因此翻译可能没有接收 根据本身的接待报告或综合报告。 通常的规则是作一些有意义的事情 翻译。 翻译者不须要本身的SSRC标识符，可是 能够选择分配一个用于发送报告 关于它收到了什么。这些将被发送到全部的 链接云，每一个对应的翻译 数据流发送到该云，由于接收报告 一般多播给全部参与者。 Schulzrinne等人 标准跟踪[第56页]
RFC 3550 RTP 2003年7月 SDES：翻译者一般在不改变SDES的状况下转发 他们收到的信息从一个云到另外一个，但可能， 例如，若是决定过滤非CNAME SDES信息 带宽有限。CNAME必须被转发以容许SSRC 标识符碰撞检测工做。一位翻译 生成本身的RR数据包必须发送SDES CNAME信息 关于它本身到相同的云发送那些RR数据包。 BYE：转换器转发BYE数据包不变。翻译者 即将中止转发数据包应发送BYE数据包 到包含全部SSRC标识符的每一个链接的云 之前被转发到那个云，包括 翻译者本身的SSRC标识符，若是它发送本身的报告。 APP：翻译器转发APP数据包不变。 混音器中的RTCP处理 因为混音器本身产生一个新的数据流，因此没有 经过SR或RR数据包，而不是产生新的 双方信息。 SR发送者信息：调音台不经过发送者 来自它所混合的来源的信息，由于这些特征 的源流在混合中丢失。做为同步 源，混频器应该与发送者生成本身的SR数据包 有关混合数据流的信息并将其发送到相同的位置 方向做为混合流。 SR / RR接收报告块：一个混频器产生它本身的 接收每一个云中源的报告并将其发送出去 只对同一个云。它不能发送这些接收报告 到其余云端，不得转发接收报告 一个云，由于来源不会是SSRC 那里（只有中国证监会）。 SDES：搅拌机一般在没有改变SDES的状况下前进 他们收到的信息从一个云到另外一个，但可能， 例如，若是决定过滤非CNAME SDES信息 带宽有限。CNAME必须被转发以容许SSRC 标识符碰撞检测工做。（中国证监会的一个标识符 由混频器生成的列表可能与SSRC标识符冲突 由一个终端系统生成）。混音器必须发送SDES CNAME 关于它本身的信息到它发送SR或RR的相同的云 数据包。 Schulzrinne等人 标准跟踪[第57页]
RFC 3550 RTP 2003年7月 因为混频器不转发SR或RR数据包，它们一般会 从复合RTCP数据包中提取SDES数据包。至 尽可能减小开销，能够聚合来自SDES分组的块 转换成单个SDES分组，而后将其堆叠在SR或RR上 来自混音器的数据包。一个混合器，聚合SDES 数据包将使用比单个源更多的RTCP带宽 由于复合包将会更长，可是 由于混合器表明多个来源。 相似地，一个混合器按原样穿过SDES包 收到的将会传输高于RTCP的数据包 单一来源的速率，可是这也是正确的，由于数据包 来自多个来源。RTCP数据包速率可能不一样 在搅拌机的每一边。 不插入CSRC标识符的混音器也能够不作 从转发SDES CNAMEs。在这种状况下，SSRC标识符 两个云中的空间是独立的。如前面提到的， 这种操做模式会产生循环不能的危险 检测。 BYE：混音器必须转发BYE数据包。一个即将到来的混音器 中止转发数据包应该向每一个发送一个BYE数据包 所链接的云包含全部的SSRC标识符 之前被转发到该云，包括混音器 若是它发送本身的报告，则拥有SSRC标识符。 APP：经过混音器处理APP数据包是特定于应用程序的。 级联搅拌机 RTP会话可能涉及一系列混音器和翻译器 如图3所示。若是两个混频器级联，如M2和M3中 这个数字，混音器收到的数据包可能已经混合在一块儿了 而且能够包括具备多个标识符的CSRC列表。第二 调音台应该创建传出的数据包使用CSRC列表 来自已经混合的输入数据包和SSRC的CSRC标识符 标识符来自未混合的输入数据包。这在输出中显示 来自M3中标记为M3：89（64,45）的混频器M3。正如在这种状况下 若是由此产生的CSRC清单有更多，则不会级联 超过15个标识符，其他不能包含在内。 Schulzrinne等人 标准跟踪[页码58]
RFC 3550 RTP 2003年7月 。 在RTP头和各个字段中携带的SSRC标识符 的RTCP数据包是一个随机的32位数字是必需的 在RTP会话中是全球惟一的。这个数字是相当重要的 请慎重选择，以便参与者在同一个网络上 同时开始不可能选择相同的号码。 这是不足以使用本地网络地址（如一个 IPv4地址）做为标识符，由于地址可能不是 独特。因为RTP转换器和混音器可以实现互操做 具备不一样地址空间的多个网络，分配 在两个空间内的地址模式可能会致使不少 与随机分配相比，更高的碰撞率。 在一台主机上运行的多个源也会发生冲突。 简单地经过得到SSRC标识符也是不够的 调用random（）而不仔细初始化状态。一个 介绍如何生成一个随机标识符的例子 附录A.6。 碰撞的可能性 因为标识符是随机选择的，因此有多是两个或者两个 更多的来源将选择相同的号码。碰撞发生了 全部来源同时开始的最高几率 例如某些会话管理自动触发 事件。若是N是来源的数量和L的长度 标识符（这里是32位），两个来源的几率 独立选取相同的值能够近似为大N [ 26 ]如1 - EXP（-N **2分之2**（L + 1））。对于N = 1000，几率是 大约10 ** - 4。 典型的碰撞几率远低于最坏的状况 以上。当一个新的源加入一个RTP会话时， 其余来源已经有惟一的标识符的几率 碰撞只是空间中使用的数字的一小部分。 再次，若是N是来源的数量和L的长度 标识符，碰撞的几率是N / 2 ** L。对于N = 1000， 几率大概是2 * 10 ** - 7。 机会进一步减小了碰撞的可能性 用于接收来自其余参与者的数据包的新来源 发送它的第一个数据包（数据或控制）。若是新来源 跟踪其余参与者（经过SSRC标识符），而后 Schulzrinne等人 标准跟踪[第59页]
RFC 3550 RTP 2003年7月 在发送第一个数据包以前，新的源能够验证 它的标识符不会与任何已经收到的相冲突，或者 不然再选择。 碰撞分辨率和回路检测 尽管SSRC标识符冲突的几率很低，但全部的RTP 实现必须准备好检测碰撞并采起行动 采起适当的行动来解决它们 若是一个来源发现任何 另外一个来源正在使用与其相同的SSRC标识符 本身，它必须发送一个RTCP BYE包的旧标识符和 选择另外一个随机的。（以下所述，这一步是采起的 只有一次，若是一个循环。）若是一个接收器发现了另外两个 来源正在冲突，它能够保持来自一个和丢弃的数据包 来自其余的数据包时，这能够被检测到不一样的 源传输地址或CNAME。预计这两个来源 解决冲突，使状况不会持续下去。 由于随机的SSRC标识符是全局惟一的 RTP会话，它们也能够用来检测可能的循环 由混音师或翻译员介绍。循环致使重复 数据和控制信息，不管是未修改的仍是可能的混合的 在下面的例子中： o转换器可能会错误地将数据包转发到相同的地方 从中接收到数据包的多播组 直接或经过一连串的翻译。在这种状况下， 相同的数据包出现几回，源自不一样 网络来源。 o两名译员错误地并行设置，即与 两边相同的组播组都会转发报文 从一个多播组到另外一个多播组。单向翻译器 会产生两份; 双向翻译将造成一个 循环。 o调音台能够经过发送到相同的传输器来关闭一个循环 直接或间接接收数据包的目的地 经过另外一个混音器或翻译器。在这种状况下，一个来源可能 在一个数据包和一个混合的CSRC中都显示SSRC 数据包。 源可能会发现它本身的数据包正在循环，或者 来自另外一个来源的数据包正在循环（第三方循环）。 循环和碰撞在随机选择一个源 标识符致使分组以相同的SSRC标识符到达 可是一个不一样的源码传输地址，多是这个地址的 终端系统始发数据包或中间系统。 Schulzrinne等人 标准跟踪[页码60]
RFC 3550 RTP 2003年7月 所以，若是源更改其源传输地址，则可能 也选择一个新的SSRC标识符，以免被解释为一个 循环的来源。（这不是必须的，由于在RTP的一些应用中 来源可能会在会议期间改变地址。）注意 若是翻译者从新启动并所以改变源 传输地址（例如，更改UDP源端口号） 它转发数据包，而后全部这些数据包将出如今接收者 因为SSRC标识符是由原始的应用而被循环的 来源并不会改变。保持这个问题是能够避免的 在从新启动时固定的源传输地址，但不管如何 将在接收器超时后解决。 在翻译者或者翻译者的另外一边出现循环或者碰撞 若是所有使用源传输地址，则不能检测到混频器 数据包的副本经过翻译器或混音器，可是， 当来自两个RTCP SDES的块时仍可能检测到冲突 数据包包含相同的SSRC标识符但不一样的CNAME。 为了检测和解决这些冲突，一个RTP实现必须 包括一个相似于下面描述的算法，虽然 实现能够选择一个不一样的包来自哪一个策略 相冲突的第三方来源保存。所描述的算法 下面忽略来自与源相冲突的新源或循环的数据包 肯定来源。它解决了与参与者的冲突 经过为旧的标识符发送一个RTCP BYE来拥有SSRC标识符 选择一个新的。可是，当碰撞被诱导时 循环参与者本身的数据包，算法将选择一个 新的标识符只有一次，而后忽略数据包 循环源传输地址。这是为了不洪水 的BYE数据包。 这个算法须要保留一个由源索引的表 标识符并包含源传输地址 第一RTP分组和用该标识符接收的第一RTCP分组， 连同其余国家的来源。两源运输 由于例如UDP源端口，因此须要地址 RTP和RTCP数据包的号码可能不一样。可是，它多是 假定两个源传输中的网络地址是相同的 地址。 在RTP或RTCP包中收到的每一个SSRC或CSRC标识符是 在源标识符表中查找，以便处理它 数据或控制信息。源传输地址 数据包与中对应的源传输地址进行比较 该表检测循环或碰撞，若是他们不匹配。对于 控制数据包，每一个元素都有本身的SSRC标识符 例如SDES块，须要单独的查找。（SSRC 接收报告块中的标识符是一个例外，由于它 Schulzrinne等人 标准跟踪[页码61]
RFC 3550 RTP 2003年7月 肯定了记者听到的来源，以及SSRC标识符 与发送的RTCP数据包的源传输地址无关 由记者。）若是SSRC或证监会没有找到，一个新的条目是 建立。这些表项在RTCP BYE包被删除时被删除 接收到相应的SSRC标识符并通过验证 匹配源传输地址，或在没有数据包到达以后 相对较长时间（见第6.2.1节）。 请注意，若是同一主机上的两个信号源正在传输 在接收机开始操做时，它是相同的源标识符 将有可能收到的第一个RTP包来自其中一个 第一个RTCP数据包收到来自另外一个来源。 这会致使错误的RTCP信息与 RTP数据，可是这种状况应该足够罕见和无害 这可能会被忽视。 为了跟踪参与者本身的数据包的循环， 实现也必须保留一个单独的源码传输列表 地址（而不是标识符）已经被发现有冲突。 如源标识符表中那样，有两个源传输地址 务必保持分开跟踪冲突的RTP和RTCP数据包。 请注意，冲突的地址列表一般应该很短 空。此列表中的每一个元素都存储源地址加 接收到最近冲突的数据包的时间。一个 元素能够在没有冲突的分组时从列表中移除 10 RTCP报告的顺序来自该来源一段时间 间隔（见第6.2节）。 对于所示的算法，假定参与者本身的 源标识符和状态被包括在源标识符中 表。该算法能够重构，首先作一个单独的 与参与者本身的源标识符进行比较。 若是（SSRC或CSRC标识符未在源中找到 标识符表）{ 建立一个存储数据或控制源的新条目 运输地址，SSRC或者CSRC等国家; } / *标识符在表格中找到* / 不然若是（表项是在收到控制包时建立的 这是第一个数据包，反之亦然）{ 从这个包中存储源传输地址; } 不然若是（来自数据包的源传输地址不匹配 保存在这个标识符的表项中的那个）{ Schulzrinne等人 标准跟踪[第62页]
RFC 3550 RTP 2003年7月 / *标识符冲突或循环被指示* / 若是（源标识符不是参与者本身的）{ / *可选的错误计数器步骤* / 若是（源标识符来自RTCP SDES块 包含与CNAME不一样的CNAME项目 在表格中）{ 计算第三方碰撞; } else { 统计第三方循环; } 停止数据包或控制元素的处理; / *能够选择不一样的政策来保持新的来源* / } / *参与者本身的数据包的冲突或循环* / 不然若是（源传输地址在列表中找到 冲突的数据或控制源传输 地址）{ / *可选的错误计数器步骤* / 若是（源标识符不是来自RTCP SDES块 包含一个CNAME项目或CNAME是 参与者本身的）{ 统计本身的交通事件的发生; } 在冲突的地址列表条目中标记当前时间; 停止数据包或控制元素的处理; } / *新的碰撞，更改SSRC标识符* / else { 日志发生碰撞; 在冲突的数据或控件中建立一个新条目 源传输地址列表并标记当前时间; 用旧的SSRC标识符发送一个RTCP BYE包; 选择一个新的SSRC标识符; 在源标识符表中建立一个新条目 旧的SSRC加上源传输地址 正在处理的数据或控制分组; } } 在这个算法中，来自新冲突的源地址的数据包 将被忽略，而且来自原始源地址的分组将被忽略 保持。若是没有数据包从原始源到达扩展 期间，表格条目将被超时而且新的来源将是 Schulzrinne等人 标准跟踪[页63]
RFC 3550 RTP 2003年7月 可以接管。若是原始来源检测到这可能会发生 碰撞和移动到一个新的源标识符，但在平时 若是一个RTCP BYE包将从原始源接收到 删除状态而没必要等待超时。 若是经过混音器接收到原始源地址（即， 做为中国证监会学习），后来直接收到同一来源， 建议接收方切换到新的源地址 除非混合中的其余来源将会丢失。并且，由于 诸如移动电话之类的应用，诸如电话 实体可能会在RTP会话过程当中更改地址， RTP实现应该修改碰撞检测 算法来接受来自新源传输地址的分组。 为了防止地址之间的翻转若是真的 碰撞确实发生，算法应该包括一些手段 检测到这种状况并避免切换。 当因为碰撞而选择新的SSRC标识符时， 候选人标识符应首先在源代码中查找 标识符表来查看它是否已经被其余人使用 资源。若是是这样，则必须生成另外一个候选者和过程 重复。 数据包到组播目的地的循环会致使严重 网络泛滥。全部的混音器和转换器必须执行一个循环 像这样的检测算法，以便它们能够打破循环。 这应该限制多余的流量不超过一个重复 原始流量的副本，这可能会让会话继续 这样能够找到并修复循环的缘由。可是，在 极端的状况下，混音器或翻译不能正确地打破 循环和高流量水平的结果，多是必要的 系统彻底中止传输数据或控制数据包。这个 决定可能取决于应用程序。一个错误条件应该 应适当代表。传输可能会再次尝试 按期在一个漫长的随机时间以后（大约几分钟）。 使用分层编码 对于在单独的RTP会话中传输的分层编码（请参阅 第2.4节），一个单一的SSRC标识符空间应该被使用 应该使用全部图层和核心（基础）层的会话 用于SSRC标识符分配和冲突解决。当一个 源发现它已经发生了冲突，它发送一个RTCP BYE 数据包仅在基本层上，但将SSRC标识符更改成 全部层面的新价值。 Schulzrinne等人 标准跟踪[页码64]
RFC 3550 RTP 2003年7月 。 低层协议可能最终提供全部的安全性 包括RTP应用程序可能须要的服务 认证，完整性和机密性。这些服务有 在[ 27 ]中被指定为IP 。自从最初的音频和视频 在此以前，使用RTP的应用程序须要保密服务 服务可用于IP层，保密服务 在下一节中描述的被定义为与RTP和RTCP一块儿使用。 这里的描述包含在现有的实践中。新 RTP的应用能够实现这个RTP特有的机密性 为了向后兼容服务，和/或他们能够实现 替代安全服务。在RTP协议上的开销 这个保密服务是低的，因此罚款将是最小的 若是这个服务未来被其余服务所淘汰。 或者，其余服务，服务的其余实现 其余算法可能在将来为RTP定义。在 特别是一个名为安全实时传输协议的RTP配置文件 （SRTP）[ 28 ]正在开发中，以提供RTP的机密性 有效载荷，同时使RTP头部保持清晰，以便链路级别 头压缩算法仍然能够运行。预计 SRTP将是许多应用程序的正确选择。SRTP是基于的 在高级加密标准（AES）和提供更强大的 安全性比这里描述的服务。没有人声称是 这里介绍的方法适用于特定的安全性 须要。配置文件能够指定哪些服务和算法应该是 由应用程序提供，并可能为其提供指导 适当的使用。 密钥分发和证书不在此范围以内 文件。 保密 机密性意味着只有预期的接收机才能解码 接收到的数据包; 对于其余人来讲，数据包没有用处 信息。内容的保密性是经过 加密。 当须要根据该方法对RTP或RTCP进行加密时 在本节中指定，将被封装的全部八位字节 在一个单一的低层数据包传输做为一个加密 单元。对于RTCP，必须为每一个单元从新绘制一个32位的随机数 在加密以前添加到本机。对于RTP，没有前缀 前置; 而是序列号和时间戳字段 用随机偏移初始化。这被认为是一个弱点 Schulzrinne等人 标准跟踪[第65页]
RFC 3550 RTP 2003年7月 初始化矢量（IV）因为随机性较差。在 此外，若是后来的领域，SSRC，能够被操纵 敌人，加密方法还有进一步的弱点。 对于RTCP，一个实现能够分离单独的RTCP数据包 在一个复合RTCP包中分红两个独立的复合RTCP包， 一个要加密，一个要明文发送。例如， 接收报告发送时，SDES信息可能会被加密 明确地容纳不知道的第三方监视器 到加密密钥。在这个例子中，如图4所示，SDES 信息必须附加到没有报告的RR数据包（和 随机数）来知足全部复合RTCP的要求 数据包以SR或RR数据包开始。SDES CNAME项目是 须要在加密或未加密的数据包中，但不能同时使用。 相同的SDES信息不该该被携带在两个数据包中 这可能会危及加密。 UDP数据包UDP数据包 ----------------------------- --------------------- --------- [random] [RR] [SDES #CNAME ...] [SR #senderinfo＃site1＃site2] ----------------------------- --------------------- --------- 加密不加密 ＃：SSRC标识符 图4：加密和未加密的RTCP数据包 加密的存在和使用正确的密钥是 由接收器经过报头或有效载荷有效性检查来确认。 给出了RTP和RTCP头的这种有效性检查的例子 在附录A.1和A.2中。 与现有的初始实现一致 在RFC 1889中规定了RTP ，默认的加密算法是 数据加密标准（DES）算法在密码块链中 （CBC）模式，如RFC 1423 [ 29 ] 第1.1节所述，除了 填充到8个八位字节的倍数如P所述 位于5.1节。初始化矢量由于随机而为零 值在RTP头部或由随机前缀提供 复合RTCP分组。有关使用CBC初始化的详细信息 载体，参见[ 30 ]。 支持这里指定的加密方法的实现 应该始终支持CBC模式下的DES算法做为默认值 密码为这个方法最大化互操做性。这个方法是 由于它已被证实是简单实用的 用于实验音频和视频工具的操做上 互联网。然而，从那之后，DES被发现太容易被破坏。 Schulzrinne等人 标准跟踪[页码66]
RFC 3550 RTP 2003年7月 推荐使用更强的加密算法，如 使用Triple-DES代替默认算法。此外， 安全的CBC模式要求每一个数据包的第一个块被异或 与密码块大小相同的随机独立IV 尺寸。对于RTCP，这是（部分）经过预先分配来实现的 数据包与一个32位随机数，每一个独立选择 包。对于RTP，时间戳和序列号从随机开始 值，但连续的数据包不会被独立随机化。 应该指出，在这两种状况下的随机性（RTP和RTCP） 是有限的。高安全性的应用程序应该考虑其余，更多 常规，保护手段。其余加密算法能够 经过非RTP方式为会话动态指定。尤为是，基于AES 的SRTP协议[ 28 ]正在开发中 账户已知的明文和CBC明文操做的担心，和 将是将来的正确选择。 做为IP级别或RTP级别加密的替代方案 如上所述，配置文件能够定义额外的有效载荷类型 加密的编码。这些编码必须指定如何填充和 加密的其余方面将被处理。这种方法 容许只加密数据，同时保留头文件 在须要的地方清除应用程序。这多是特别的 有用的硬件设备，将处理解密和 解码。这对连接级别的应用程序也颇有价值 RTP和下层头部的压缩是指望的 有效载荷的机密性（但不是地址）就足够了 由于标题的加密排除了压缩。 身份验证和消息完整性 身份验证和消息完整性服务没有定义在 RTP级别，由于这些服务没有没有直接的可行性 关键的管理基础设施 预计认证 完整性服务将由低层协议提供。 。 Internet上使用的全部传输协议都须要解决 拥塞控制在某种程度上[ 31 ]。RTP不是例外，可是 由于经过RTP传输的数据一般是非弹性的（生成的 以固定或控制的速度），控制拥堵的手段 RTP可能与其余传输协议的RTP很不相同 如TCP。从某种意义上说，非弹性下降了风险 拥塞，由于RTP流不会扩展到消耗所有 可用带宽做为TCP流能够。可是，也是非弹性的 意味着RTP流不能任意减小其负载 网络在发生拥塞时消除。 Schulzrinne等人 标准跟踪[第67页]
RFC 3550 RTP 2003年7月 因为RTP可能在许多应用中被普遍使用 不一样的上下文，没有单一的拥塞控制机制 这将为全部人工做。因此拥塞控制应该是 在每一个RTP配置文件中定义。对于一些配置文件，它 可能足以包含适用性声明的限制 将该配置文件用于避免拥塞的环境 经过工程。对于其余配置文件，具体方法如数据 可能须要基于RTCP反馈的速率适配。 。 本部分描述了在内部携带RTP数据包的具体问题 特定的网络和传输协议。如下规则 除非在此以外被特定于协议的定义取代 规范。 RTP依赖底层协议来提供多路分解 RTP数据和RTCP控制流。对于UDP和相似的协议， RTP应该使用一个偶数目的端口号和相应的 RTCP流应该使用下一个更高（奇数）的目的端口号。 对于将单个端口号做为参数的应用程序和 若是是奇数，则从该数字派生RTP和RTCP端口对 被提供，那么应用程序应该用该替换该数字 下一个较低（偶数）做为端口对的基础。对于 RTP和RTCP目标端口号的应用程序 经过明确的，单独的参数指定（使用信令 协议或其余方式），应用程序可能会忽略 限制端口号是偶数/连续的 尽管使用偶数/奇数端口对仍然受到鼓励。该 RTP和RTCP端口号不能相同，由于RTP依赖 用于解复用RTP数据和RTCP控制的端口号 流。 在单播会话中，两个参与者都须要识别一个端口对 用于接收RTP和RTCP数据包。两位参与者均可以使用 相同的端口对。参与者不得假定源端口 传入的RTP或RTCP数据包能够用做目的地 端口用于传出RTP或RTCP数据包。当RTP数据包是 在两个方向发送，每一个参与者的RTCP SR数据包 必须发送到其余参与者指定的端口 接收RTCP。RTCP SR数据包组合了发送者信息 为传出数据加接收报告信息 传入数据。若是一方不主动发送数据（见第 6.4 节），则发送一个RTCP RR数据包。 建议分层编码应用程序（见第 2.4 节）使用一组连续的端口号。端口号必须是 因为现有经营中广泛存在的缺陷而显着 Schulzrinne等人 标准跟踪[页码68]
RFC 3550 RTP 2003年7月 阻止使用同一个端口与多个多播的系统 地址，而对于单播，只有一个容许的地址。 所以，对于层n，数据端口是P + 2n，控制端口是P + 2n + 1。当使用IP多播时，地址必须也是 因组播路由和组成员资格被管理而不一样 在地址粒度。可是，分配连续的IP 多播地址不能被假定，由于一些组可能须要 不一样的范围，所以能够从不一样的分配 地址范围。 前一段与SDP规范（RFC 2327 [ 15 ]）冲突，该规范说明多个地址和多个地址都是非法的 在同一会话描述中指定多个端口 由于地址与端口的关联多是模糊的。 这个限制的目的是在修改版本时放宽 RFC 2327容许相同数量的地址和端口 隐含的一对一映射指定。 RTP数据包不包含长度字段或其余描述， 所以RTP依赖底层协议来提供一个 长度指示。RTP包的最大长度是有限的 由底层协议。 若是RTP数据包将被携带在一个底层协议中 提供了连续八位字节流的抽象，而不是 消息（数据包），RTP数据包的封装必须是 定义为提供一个框架机制。若是还须要构筑 底层的协议可能会包含填充以便扩展的范围 RTP负载没法肯定。框架机制不是 这里定义。 配置文件能够指定即便在RTP时也使用的成帧方法 进行协议，提供框架，以便容许 在一个低层协议数据单元中携带几个RTP分组， 如UDP数据包。在一个网络或者一个网络中携带几个RTP数据包 传输分组减小了头部开销而且能够简化 不一样流之间的同步。 。 本部分包含在中定义的常量的总结列表 这个规范。 RTP负载类型（PT）常量在配置文件中定义 比这个文件。可是，RTP头的八位字节是哪一个 包含标记位和有效载荷类型务必避免保留 值200和201（十进制）来区分来自RTCP的RTP数据包 用于所描述的头部验证过程的SR和RR分组类型 Schulzrinne等人 标准跟踪[页码69]
RFC 3550 RTP 2003年7月 在附录A.1。对于一个标记位和a的标准定义 7位有效载荷类型字段，如本规范所示 限制意味着有效载荷类型72和73被保留。 RTCP分组类型 缩写。名称值 SR发件人报告200 RR接收器报告201 SDES源描述202 BYE再见203 APP应用程序定义204 这些类型值被选择在200-204范围内进行改进 RTCP包的报头有效性检查与RTP包相比较 其余不相关的数据包。当比较RTCP分组类型字段时 到RTP头的相应字节，这个范围对应 标记位为1（一般不在数据包中） 而且标准有效载荷类型字段的高位是1（由于 静态有效载荷类型一般定义在低一半）。 这个范围也被选为从0和数字的一些距离 255，由于全零和全是通用的数据模式。 因为全部复合RTCP分组必须以SR或RR开始，这些代码 被选为偶数/奇数对以容许RTCP有效性检查 用掩码和值测试最大位数。 额外的RTCP数据包类型可能经过IANA注册（见 第15节）。 SDES类型 缩写。名称值 SDES列表0的END结束 CNAME规范名称1 NAME用户名2 EMAIL用户的电子邮件地址3 PHONE用户的电话号码4 LOC地理用户位置5 工具名称的应用程序或工具6 注意有关来源的通知7 PRIV专用扩展8 其余SDES类型能够经过IANA注册（参见第 15 节）。 Schulzrinne等人 标准跟踪[页70]
RFC 3550 RTP 2003年7月 。 一个完整的规范RTP为特定的应用程序将 须要一个或多个这里描述的两种类型的伴随文件： 配置文件和有效负载格式规范。 RTP能够用于多种应用，但有些不一样 要求。适应这些要求的灵活性是 经过在主协议中容许多种选择来提供 规范，而后选择适当的选择或定义 在特定环境和应用程序类别的扩展 一个单独的配置文件。一般应用程序将运行 在一个特定的RTP会话中只有一个配置文件，因此没有 在RTP协议自己内部明确指示哪一个 我的资料正在使用中。音频和视频应用程序的配置文件多是 在伴侣RFC 3551中找到。配置文件一般标题为“RTP” 我的资料...“。 第二种伴随文档是有效载荷格式 规范，它定义了一种特定类型的有效载荷数据， 如H.261编码的视频，应该在RTP中携带。这些 文件一般标题为“XYZ的RTP有效载荷格式” 音频/视频编码“。有效载荷格式可能在多个下有用 配置文件，所以能够独立于任何特定来定义 我的资料。配置文件而后负责分配一个 若是须要，将该格式的默认映射到有效载荷类型值。 在本规范中，下列项目已被肯定 在配置文件中可能的定义，但这个列表并不意味着 详尽： RTP数据头：RTP数据头中包含的八位字节 标记位和有效载荷类型字段能够由a从新定义 配置文件，以适应不一样的要求，例如与更多或 更少的标记位（5.3节，第18页）。 有效载荷类型：假设包含有效载荷类型字段， 该配置文件一般会定义一组有效载荷格式（例如， 媒体编码）以及这些格式的默认静态映射 有效载荷类型值。一些有效载荷格式可能被定义 经过参考单独的有效载荷格式规范。每一个 有效载荷类型定义，配置文件必须指定RTP时间戳 时钟频率（第5.1节，第14页）。 RTP数据头添加：附加字段能够附加到 固定的RTP数据头，若是一些额外的功能是 跨越我的资料的独立的应用程序类别 有效载荷类型（5.3节，第18页）。 Schulzrinne等人 标准跟踪[页码71]
RFC 3550 RTP 2003年7月 RTP数据头扩展名：前16位的内容 RTP数据头扩展结构必须定义若是使用 这个机制是容许的 特定于实现的扩展（第5.3.1节，第18页）。 RTCP数据包类型：新的特定于应用程序类的RTCP数据包 类型能够被定义并向IANA注册。 RTCP报告间隔：一个配置文件应该指定的值 在第6.2节中提到的常量用于 将使用RTCP报告间隔的计算。那些是 会话带宽的RTCP部分，最小报告 间隔以及发送者和接收者之间的带宽分配。 一个配置文件能够指定替代值，若是他们已经 表现出可扩展的工做方式。 SR / RR扩展：能够为扩展部分定义扩展部分 RTCP SR和RR数据包，若是有附加信息的话 应按期报告发件人或收件人 （第6.4.3节，第42和43页）。 SDES使用：配置文件能够指定相对优先级 RTCP SDES项目彻底传输或排除（第 6.3.9 节）; CNAME项目的替代语法或语义 （6.5.1节）; LOC项目的格式（第6.5.5节）; 该 注释项的语义和使用（6.5.7节）; 或新的SDES 要向IANA注册的项目类型。 安全：配置文件能够指定哪些安全服务和 算法应该由应用程序提供，而且能够提供 指导其适当使用（第9节，第65页）。 字符串到键映射：配置文件能够指定用户提供的方式 密码或密码短语被映射到加密密钥。 拥塞：配置文件应该指定拥塞控制 适合该配置文件的行为。 底层协议：使用特定的底层网络或 传输层协议可能须要携带RTP包。 传输映射：RTP和RTCP到传输级别的映射 地址，例如UDP端口，而不是标准映射 在第11节中定义。68可能被指定。 Schulzrinne等人 标准跟踪[页码72]
RFC 3550 RTP 2003年7月 封装：能够定义RTP封装的封装 容许在一个较低层携带多个RTP数据包 数据包或提供不支持的底层协议的帧 已经这样作了（第11节，第69页）。 预计每一个人都不须要一个新的配置文件 应用。在一个应用程序类中，最好是 扩展示有的配置文件，而不是作一个新的 促进应用程序之间的互操做 一般只在一个配置文件下运行。简单的扩展，如 附加有效载荷类型值或RTCP分组类型的定义能够 经过IANA注册并发布它们来完成 描述在配置文件的附录或有效负载格式中 规范。 。 RTP遭受与底层相同的安全责任 协议。例如，冒名顶替者能够伪造来源或目的地 网络地址，或更改标头或有效负载。在RTCP中， CNAME和NAME信息可能被用来冒充另外一个 参与者。另外，RTP能够经过IP多播发送， 没有提供发送者知道全部接收者的直接手段 数据发送，所以没有措施的隐私。没错， 用户可能对音频和视频的隐私问题更为敏感 沟通比以往更传统的形式 网络通讯[ 33 ]。因此使用安全 RTP机制很重要。这些机制在讨论中 第9节。 能够使用RTP级别的转换器或混合器来容许RTP流量 到达防火墙后面的主机。适当的防火墙安全 原则和作法，这超出了这个范围 文件，在设计和安装这些应该遵循 设备和在RTP应用程序的入场许可以后使用 防火墙。 。 额外的RTCP数据包类型和SDES项目类型能够被注册 经过互联网号码分配机构（IANA）。因为这些 号码空间很小，容许不受限制地注册新的 价值观不会审慎。方便审查请求和 促进多种应用程序，请求中的新类型的共享使用 新值的注册必须在RFC或其余文件中记录 永久的和现成的参考，如产品 另外一个合做标准组织（如ITU-T）。其余请求可能 也能够在“指定专家”的建议下被接受。 Schulzrinne等人 标准跟踪[页码73]
RFC 3550 RTP 2003年7月 （请联系IANA获取当前专家的联系信息。） RTP配置文件规范应该向IANA注册一个名称 以“RTP / xxx”的形式表示，其中xxx是简短的缩写 我的资料标题。这些名称供上级控制使用 协议，如会话描述协议（SDP），RFC 2327 [ 15 ]，来引用传输方法。 。 IETF对任何的有效性或范围不做任何表态 知识产权或其余可能要求的权利 属于实施或使用所述的技术 本文件或在此权利下的任何许可证的程度 可能或可能不可用; 它也不表明它 已经努力肯定任何这样的权利。有关的信息 IETF关于标准跟踪权的程序 标准相关的文件能够在BCP-11中找到。副本 权利主张能够发表和任何保证 可用的许可证，或尝试的结果 得到通常许可或使用许可 本规范的实现者或使用者的专有权利能够 从IETF秘书处得到。 IETF邀请任何有关方面提请其注意 版权，专利或专利申请或其余专有权利 权利可能涵盖可能须要实践的技术 这个标准。请向IETF执行官提供信息 导向器。 。 本备忘录基于IETF音频/视频内的讨论 运输工做组由Stephen Casner和Colin Perkins主持。 目前的协议起源于网络语音协议 和分组视频协议（Danny Cohen和Randy Cole）等 协议实施的增值税申请（范雅各布森和史蒂夫 McCanne）。Christian Huitema提供了随机标识符的想法 发电机。定时器的普遍的分析和模拟 Jonathan Rosenberg完成了复议算法。该 Michael Speer和Michael指定了分层编码的补充 史蒂夫·麦凯恩 Schulzrinne等人 标准跟踪[页码74]
RFC 3550 RTP 2003年7月 附录A - 算法 咱们提供了RTP发送方和接收方的C代码示例 算法。可能有其余的实现方法 在特定的操做环境下更快或具备其余优势。 这些实现说明仅供参考 是为了澄清RTP规范。 如下定义用于全部示例; 为了清晰和 简洁，结构定义只适用于32位big- endian（最重要的八位字节第一）体系结构。位字段是 假定以大端位顺序牢牢包装，没有 额外的填充。修改将须要构建一个 便携式实施。 / * * rtp.h - RTP头文件 * / #include <sys / types.h> / * *下面的类型定义适用于32位体系结构和 *可能须要调整为16位或64位体系结构。 * / typedef unsigned char u_int8; typedef unsigned short u_int16; typedef unsigned int u_int32; typedef short int16; / * *当前的协议版本。 * / #define RTP_VERSION 2 #define RTP_SEQ_MOD（1 << 16） #define RTP_MAX_SDES 255 / * SDES的最大文本长度* / typedef enum { RTCP_SR = 200， RTCP_RR = 201， RTCP_SDES = 202， RTCP_BYE = 203， RTCP_APP = 204 } rtcp_type_t; typedef enum { RTCP_SDES_END = 0， RTCP_SDES_CNAME = 1， Schulzrinne等人 标准跟踪[页码75]
RFC 3550 RTP 2003年7月 RTCP_SDES_NAME = 2， RTCP_SDES_EMAIL = 3， RTCP_SDES_PHONE = 4， RTCP_SDES_LOC = 5， RTCP_SDES_TOOL = 6， RTCP_SDES_NOTE = 7， RTCP_SDES_PRIV = 8 } rtcp_sdes_type_t; / * * RTP数据头 * / typedef struct { 无符号整数版本：2; / *协议版本* / unsigned int p：1; / *填充标志* / unsigned int x：1; / *标题扩展标志* / unsigned int cc：4; / *证监会统计* / 无符号整数m：1; / *标记位* / unsigned int pt：7; / *有效载荷类型* / unsigned int seq：16; /* 序列号 */ u_int32 ts; / *时间戳* / u_int32 ssrc; / *同步源* / u_int32 csrc [1]; / *可选的CSRC名单* / } rtp_hdr_t; / * * RTCP公共标题字 * / typedef struct { 无符号整数版本：2; / *协议版本* / unsigned int p：1; / *填充标志* / 无符号整数计数：5; / *因数据包类型而异* / unsigned int pt：8; / * RTCP数据包类型* / u_int16长度; / * pkt len在文字中，没有这个词* / } rtcp_common_t; / * *版本，填充位和分组类型对的大端掩码 * / #define RTCP_VALID_MASK（0xc000 | 0x2000 | 0xfe） #define RTCP_VALID_VALUE（（RTP_VERSION << 14）| RTCP_SR） / * *接待报告块 * / typedef struct { u_int32 ssrc; / *正在报告数据源* / 无符号整数分数：8; / *自上次SR / RR丢失的分数* / Schulzrinne等人 标准跟踪[页码76]
RFC 3550 RTP 2003年7月 诠释失落：24; / * cumul。没有。丢失（签名！）* / u_int32 last_seq; / *延长最后一个seq。没有。收到* / u_int32抖动; / *到达间隔抖动* / u_int32 lsr; / *来自此源的最后一个SR数据包* / u_int32 dlsr; / *自上次SR数据包以来的延迟* / } rtcp_rr_t; / * * SDES项目 * / typedef struct { u_int8类型; / *项目类型（rtcp_sdes_type_t）* / u_int8长度; / *项目的长度（以字节为单位）* / char数据[1]; / *文本，不以null结尾* / } rtcp_sdes_item_t; / * *一个RTCP数据包 * / typedef struct { rtcp_common_t common; / *公共标题* / 联合{ / *发件人报告（SR）* / struct { u_int32 ssrc; / *发件人生成这个报告* / u_int32 ntp_sec; / * NTP时间戳* / u_int32 ntp_frac; u_int32 rtp_ts; / * RTP时间戳* / u_int32 psent; / *发送的数据包* / u_int32 osent; / *八位组发送* / rtcp_rr_t rr [1]; / *可变长度列表* / } sr; / *接待报告（RR）* / struct { u_int32 ssrc; / *接收器产生这个报告* / rtcp_rr_t rr [1]; / *可变长度列表* / } rr; / *源描述（SDES）* / struct rtcp_sdes { u_int32 src; / *第一次SSRC / CSRC * / rtcp_sdes_item_t item [1]; / * SDES项目清单* / } sdes; / * BYE * / struct { u_int32 src [1]; / *来源清单* / Schulzrinne等人 标准跟踪[页码77]
RFC 3550 RTP 2003年7月 / *因为缘由，不能表达结尾的文本* / 再见; } r; } rtcp_t; typedef struct rtcp_sdes rtcp_sdes_t; / * *每一个源的状态信息 * / typedef struct { u_int16 max_seq; / *最高seq。看到的数字* / u_int32个周期; / *移位的seq计数。数字周期* / u_int32 base_seq; / *基地序号* / u_int32 bad_seq; / *最后'坏'seq号码+ 1 * / u_int32缓刑; / * sequ。包到源有效* / u_int32收到; / *收到的数据包* / u_int32 expected_prior; / *预计在最后的时间间隔* / u_int32 received_prior; / *最近一次收到的数据包* / u_int32过境 / * prev pkt的相对传输时间* / u_int32抖动; / *估计的抖动* / / * ... * / } 资源; RTP数据报头有效性检查 RTP接收机应该检查RTP报头的有效性 传入的数据包，由于它们可能被加密或可能来自一个 不一样的应用程序碰巧是错误的。一样，若是 根据章节9中描述的方法进行加密， 头部有效性检查是须要验证传入的数据包 已被正确解密，尽管头部失败 有效性检查（例如，未知的有效载荷类型）可能不必定 指示解密失败。 只有对来自某个RTP数据包的弱有效性检查是可能的 之前没有听过的来源： o RTP版本字段必须等于2。 o有效载荷类型必须是已知的，特别是不能 等于SR或RR。 o若是P位置位，那么数据包的最后一个八位组必须 包含有效的八位字节计数，特别是小于总数 数据包长度减去头部大小。 Schulzrinne等人 标准跟踪[页码78]
RFC 3550 RTP 2003年7月 若是配置文件没有指定，则X位必须为零 能够使用头扩展机制。不然，扩展名 长度字段必须小于总包大小减去 固定的头部长度和填充。 o数据包的长度必须与CC和有效载荷一致 类型（若是有效载荷具备已知的长度）。 最后三项检查有些复杂，并不老是可能的， 只留下前两个总共只有几位。若是SSRC 而后，数据包中的标识符是以前已经接收到的标识符 该数据包多是有效的，并检查序列号是不是 在预期的范围内提供进一步的验证。若是SSRC 标识符以前没有被看见，而后数据包承载 标识符可能被认为是无效的，直到其中的一小部分 以连续的序号到达。那些无效的数据包可能 被丢弃，或者一旦验证，它们能够被存储和交付 若是由此形成的延误是能够接受的 下面显示的例程update_seq确保声明一个源 只有在收到MIN_SEQUENTIAL包后才有效 序列。它也验证了一个新的序列号seq 接收到的数据包并更新数据包的序列状态 来源于s点的结构。 当第一次听到新的来源，即SSRC 标识符不在表格中（见第8.2节）和每一个来源 状态被分配给它，s->缓刑被设置为数量 在声明源有效以前须要顺序数据包 （参数MIN_SEQUENTIAL）和其余变量被初始化： init_seq（s，seq）; s-> max_seq = seq-1; s->缓刑= MIN_SEQUENTIAL; 一个非零的s->缓刑标志着来源还没有有效，因此 状态可能会在短暂超时而不是长时间以后被丢弃， 如6.2.1节所述。 在源被认为有效以后，序列号被考虑 若是在s-> max_seq以前不超过MAX_DROPOUT，则为有效 比MAX_MISORDER落后。若是新的序列号超前 max_seq取模RTP序号范围（16位），可是 小于max_seq，它已经绕过和（移位）的计数 序号循环的次数递增。值为1返回 以指示有效的序列号。 Schulzrinne等人 标准跟踪[第79页]
RFC 3550 RTP 2003年7月 不然，返回零值以指示验证 失败，而且存储了错误的序号加1。若是下一个 接收到的数据包携带下一个更高的序列号 考虑了推测可能致使的新分组序列的有效开始 经过延长丢失或从新启动。因为多个完整 丢失的序列号周期可能已经丢失 统计被重置。 显示参数的典型值，基于最大值 以50包/秒和最大值2秒的无序次数 辍学1分钟。丢失参数MAX_DROPOUT应该是a 给出一个16位序列号空间的小部分 从新启动后的新序列号的合理可能性 不在可接受的范围以内 从新开始。 void init_seq（source * s，u_int16 seq） { s-> base_seq = seq; s-> max_seq = seq; s-> bad_seq = RTP_SEQ_MOD + 1; / * so seq == bad_seq为false * / s-> cycles = 0; s-> received = 0; s-> received_prior = 0; s-> expected_prior = 0; / *其余初始化* / } int update_seq（source * s，u_int16 seq） { u_int16 udelta = seq - s-> max_seq; const int MAX_DROPOUT = 3000; const int MAX_MISORDER = 100; const int MIN_SEQUENTIAL = 2; / * *直到MIN_SEQUENTIAL包与源无效 *已经收到序列号。 * / 若是（s->缓刑）{ / *包是按顺序* / if（seq == s-> max_seq + 1）{ S-> probation--; s-> max_seq = seq; if（s-> probation == 0）{ init_seq（s，seq）; S->接收++; 返回1; Schulzrinne等人 标准跟踪[第80页]
RFC 3550 RTP 2003年7月 } } else { s->缓刑= MIN_SEQUENTIAL - 1; s-> max_seq = seq; } 返回0; } else if（udelta <MAX_DROPOUT）{ / *为了容许差距* / if（seq <s-> max_seq）{ / * *包装的序列号 - 计算另外一个64K周期。 * / s-> cycles + = RTP_SEQ_MOD; } s-> max_seq = seq; } else if（udelta <= RTP_SEQ_MOD - MAX_MISORDER）{ / *序列号跳转很是大* / if（seq == s-> bad_seq）{ / * *两个连续的数据包 - 假设对方 *从新启动而不告诉咱们只是从新同步 *（即伪装这是第一个数据包）。 * / init_seq（s，seq）; } else { s-> bad_seq =（seq + 1）＆（RTP_SEQ_MOD-1）; 返回0; } } else { / *重复或从新排序的数据包* / } S->接收++; 返回1; } 有效性检查能够作得更强，须要两个以上 数据包顺序。缺点是数量较多 初始数据包将被丢弃（或在队列中被延迟） 高包丢失率可能会阻止验证。可是，由于 若是一个RTCP数据包是RTCP头验证相对较强 从数据包以前收到一个数据包，计数就能够了 调整，以便只有两个数据包是必需的顺序。若是 初始数据丢失几秒钟是能够容忍的，一个应用程序 能够选择丢弃来自源的全部数据包直到有效 已经从该源收到RTCP数据包。 Schulzrinne等人 标准跟踪[页码81]
RFC 3550 RTP 2003年7月 根据应用和编码，算法可能会被利用 关于有效载荷格式的额外知识以进一步验证。 对于全部时间戳增量相同的有效内容类型 数据包，时间戳值能够从以前的预测 数据包使用序列号从同一个源接收 差别（假设有效载荷类型没有变化）。 因为可能性很高，所以能够进行强有力的“快速路径”检查 新收到的RTP数据的头部中的前四个八比特组 数据包将与以前数据包的数据包相同 相同的SSRC，但序列号将增长1。 相似地，单条目缓存能够用于更快的SSRC查找 在一般从一个来源接收数据的应用程序中 时间。 RTCP报头有效性检查 如下检查应该应用于RTCP数据包。 o RTP版本字段必须等于2。 o化合物中第一个RTCP数据包的有效载荷类型字段 数据包必须等于SR或RR。 o填充位（P）应该为0的第一个数据包 复合RTCP数据包，由于填充只能应用，若是它 是须要的，到最后一个数据包。 o单个RTCP数据包的长度字段必须加起来 接收到的复合RTCP分组的总长度。这个 是一个至关强大的检查。 下面的代码段执行全部这些检查。包 类型不会检查后来的数据包，由于未知的数据包类型 可能存在，应该被忽略。 u_int32 len; / *以字为单位的复合RTCP分组的长度* / rtcp_t * r; / * RTCP标头* / rtcp_t * end; / *复合RTCP数据包的结尾* / 若是（（*（u_int16 *）r＆RTCP_VALID_MASK）！= RTCP_VALID_VALUE）{ / *数据包格式错误* / } end =（rtcp_t *）（（u_int32 *）r + len）; do r =（rtcp_t *）（（u_int32 *）r + r-> common.length + 1）; while（r <end && r-> common.version == 2）; Schulzrinne等人 标准跟踪[第82页]
RFC 3550 RTP 2003年7月 if（r！= end）{ / *数据包格式错误* / } 肯定预期和丢失的数据包数量 为了计算丢包率，RTP数据包的数量 预期和实际上从每一个来源接收须要知道， 使用struct source中定义的每一个源的状态信息 在下面的代码中经过指针s引用。数据包的数量 收到的数据包就是数据包的数量，包括任何数据 延迟或重复的数据包。数据包的数量能够是 由接收机计算出最高的差值 接收的序列号（s-> max_seq）和第一个序列号 收到（s-> base_seq）。因为序列号只有16位 并将环绕，有必要延长最高的顺序 编号与（移位的）序列号重叠计数 （S->个循环）。接收到的数据包数和周期数 维护附录A.1中的RTP头部有效性检查程序。 extended_max = s-> cycles + s-> max_seq; expected = extended_max - s-> base_seq + 1; 丢包的数量被定义为包的数量 预计实际收到的数据包数量减小： 丢失=预期 - s->收到; 因为这个有符号的数字是在24位进行的，因此应该被钳位 在0x7fffff为正面损失或0x800000为负面损失 比包裹。 在上一个报告间隔期间丢失的数据包部分 （自从以前的SR或RR分组被发送）是从中计算的 在预期的和收到的数据包计数的差别 间隔，其中expected_prior和received_prior是值 之前的接收报告生成时保存： expected_interval =预期 - s-> expected_prior; s-> expected_prior =预期; received_interval = s-> received - s-> received_prior; s-> received_prior = s->收到; lost_interval = expected_interval - received_interval; if（expected_interval == 0 || lost_interval <= 0）fraction = 0; else fraction =（lost_interval << 8）/ expected_interval; 获得的分数是二进制的8位定点数 指向左边缘。 Schulzrinne等人 标准跟踪[页码83]
RFC 3550 RTP 2003年7月 生成RTCP SDES包 这个函数将一个SDES块创建到由argc组成的缓冲区b中 以数组类型，值和长度提供的项目。它返回一个 指向b中下一个可用位置的指针。 char * rtp_write_sdes（char * b，u_int32 src，int argc， rtcp_sdes_type_t类型[]，char *值[]， int length []） { rtcp_sdes_t * s =（rtcp_sdes_t *）b; rtcp_sdes_item_t * rsp; int i; int len; int pad; / * SSRC标头* / s-> src = src; rsp =＆s-> item [0]; / * SDES项目* / for（i = 0; i <argc; i ++）{ rsp-> type = type [i]; len = length [i]; if（len> RTP_MAX_SDES）{ / *长度无效，可能要采起其余行动* / len = RTP_MAX_SDES; } rsp-> length = len; memcpy（rsp-> data，value [i]，len）; rsp =（rtcp_sdes_item_t *）＆rsp-> data [len]; } / *以结束标记结束并填充到下一个4字节边界* / len =（（char *）rsp） - b; pad = 4 - （len＆0x3）; b =（char *）rsp; while（pad--）* b ++ = RTCP_SDES_END; 回报b; } Schulzrinne等人 标准跟踪[页码84]
RFC 3550 RTP 2003年7月 解析RTCP SDES数据包 这个函数解析一个SDES包，调用函数find_member（） 找到给会员的信息指针 SSRC标识符和member_sdes（）来存储新的SDES信息 为那个成员。这个函数须要一个指向头部的指针 RTCP数据包。 void rtp_read_sdes（rtcp_t * r） { int count = r-> common.count; rtcp_sdes_t * sd =＆r-> r.sdes; rtcp_sdes_item_t * rsp，* rspn; rtcp_sdes_item_t * end =（rtcp_sdes_item_t *） （（u_int32 *）r + r-> common.length + 1）; 源* s; while（--count> = 0）{ rsp =＆sd-> item [0]; if（rsp> = end）break; s = find_member（sd-> src）; for（; rsp-> type; rsp = rspn）{ rspn =（rtcp_sdes_item_t *）（（char *）rsp + rsp-> length + 2）; if（rspn> = end）{ rsp = rspn; 打破; } member_sdes（s，rsp-> type，rsp-> data，rsp-> length）; } sd =（rtcp_sdes_t *） （（u_int32 *）sd +（（（char *）rsp - （char *）sd）>> 2）+1）; } if（count> = 0）{ / *无效的数据包格式* / } } 生成一个随机的32位标识符 如下子程序使用随机生成一个32位标识符 在RFC 1321 [ 32 ]中发布的MD5例程。系统例程可能 不是在全部的操做系统上都存在，而是应该做为 提示能够使用什么样的信息。其余系统 可能适当的呼叫包括 Schulzrinne等人 标准跟踪[页85]
RFC 3550 RTP 2003年7月 o getdomainname（）， getwd（）或者 o getrusage（）。 “现场”视频或音频样本也是随机的一个很好的来源 数字，但必须当心避免使用关闭 麦克风或盲目相机做为来源[ 17 ]。 建议使用这个或相似的程序来生成 产生RTCP的随机数发生器的初始种子 期间（如附录A.7所示）），以生成初始值 序列号和时间戳，并生成SSRC值。 因为这个例程极可能是CPU密集型的，因此它的直接使用 生成RTCP时段是不合适的，由于可预测性不是 一个问题。请注意，此例程产生相同的结果 重复的呼叫，直到系统时钟的值改变，除非 为类型参数提供了不一样的值。 / * *生成一个随机的32位数量。 * / #include <sys / types.h> / * u_long * / #include <sys / time.h> / * gettimeofday（）* / #include <unistd.h> / * get ..（）* / #include <stdio.h> / * printf（）* / #include <time.h> / * clock（）* / #include <sys / utsname.h> / * uname（）* / 从RFC 1321 #include“global.h”/ * * / #include“md5.h”/ * RFC 1321 * / #define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final 静态u_long md_32（char *字符串，int长度） { MD_CTX上下文; 联合{ char c [16]; u_long x [4]; } 消化; u_long r; int i; MDInit（＆context）; Schulzrinne等人 标准跟踪[页86]
RFC 3550 RTP 2003年7月 MDUpdate（＆context，string，length）; MDFinal（（unsigned char *）＆digest，＆context）; r = 0; for（i = 0; i <3; i ++）{ r ^ = digest.x [i]; } 返回r; } / * md_32 * / / * *返回随机无符号的32位数量。若是使用'type'参数 *您须要紧密连续生成几个不一样的值。 * / u_int32 random32（int型） { struct { int类型; 结构timeval电视; clock_t cpu; pid_t pid; u_long hid; uid_t uid; gid_t gid; struct utsname name; } s; gettimeofday（＆s.tv，0）; UNAME（＆s.name）; s.type = type; s.cpu = clock（）; s.pid = getpid（）; s.hid = gethostid（）; s.uid = getuid（）; s.gid = getgid（）; / *还有：系统正常运行时间* / 返回md_32（（char *）＆s，sizeof（s））; } / * random32 * / 计算RTCP传输间隔 如下功能实现了RTCP的发送和接收6.2节中 描述的规则。这些规则被编码在几个 功能： rtcp_interval（）计算肯定性的计算间隔， 以秒为单位。参数在6.3节中定义。 Schulzrinne等人 标准跟踪[页码87]
RFC 3550 RTP 2003年7月 OnExpire（）在RTCP传输定时器到期时被调用。 OnReceive（）在接收到RTCP数据包时被调用。 OnExpire（）和OnReceive（）都有事件e做为参数。这是 该参与者的下一个计划事件，即RTCP报告 或BYE包。假定如下功能是 可供选择： o时间表（时间t，事件e）安排事件e在时间t发生。 当时间t到达时，函数OnExpire被称为e 论据。 o从新计划（时间t，事件e）从新计划先前的计划 事件e的时间t。 SendRTCPReport（事件e）发送一个RTCP报告。 SendBYEPacket（事件e）发送一个BYE包。 TypeOfEvent（event e）若是事件正在返回EVENT_BYE 处理的是一个BYE包发送，不然返回 EVENT_REPORT。 PacketType（p）返回PACKET_RTCP_REPORT，若是数据包p是一个RTCP 报告（不是BYE），PACKET_BYE若是是BYE RTCP包， PACKET_RTP，若是它是一个常规的RTP数据包。 ReceivedPacketSize（）和SentPacketSize（）返回的大小 以八比特组为单位的引用分组。 o若是发送数据包p的参与者是，则NewMember（p）返回1 目前不在成员列表中，不然为0。注意这个功能 由于每一个中国证监会都是不够的 RTP包中的标识符和BYE包中的每一个SSRC 被处理。 o若是发送数据包p的参与者是，则NewSender（p）返回1 目前不在成员列表的发件人子列表中，0 除此之外。 AddMember（）和RemoveMember（）添加和删除参与者 成员列表。 AddSender（）和RemoveSender（）添加和删除参与者 成员列表的发件人子列表。 Schulzrinne等人 标准跟踪[第88页]
RFC 3550 RTP 2003年7月 这些功能将不得不延长执行 容许发送者和非发送者的RTCP带宽分数是 指定为显式参数而不是25％的固定值 75％。rtcp_interval（）的扩展实现将须要 若是其中一个参数为零，则避免被零除。 双rtcp_interval（int成员， int发件人， 双rtcp_bw， int we_sent， 双avg_rtcp_size， int初始） { / * *来自本站点的RTCP数据包之间的最短平均时间（in *秒）。这个时候能够防止“汇集”报告 *会议规模小，大量的法律没有帮助 *消除流量。它也保持报告间隔 *在短暂的停电期间变得好笑的小 *网络分区。 * / double const RTCP_MIN_TIME = 5。 / * *活跃的RTCP带宽共享部分 *发件人。（这个分数被选中，以便在一个典型的 *与一个或两个主动发送者的会话，计算的报告 *时间大体等于最小报告时间 *咱们不会没必要要地拖慢收件人的报告 *接收器分数必须是1 - 发件人分数。 * / double const RTCP_SENDER_BW_FRACTION = 0.25; double const RTCP_RCVR_BW_FRACTION =（1-RTCP_SENDER_BW_FRACTION）; / * / *为了弥补“定时器从新考虑”收敛到一个 *值低于预期的平均值。 * / double const COMPENSATION = 2.71828 - 1.5; 成对的东西; / *间隔* / double rtcp_min_time = RTCP_MIN_TIME; int n; / *不。成员计算* / / * *应用程序启动时的第一个通话使用半分钟 *延迟更快的通知，同时仍然容许一段时间 *报告随机前和了解其余 *来源，因此报告间隔会收敛到正确的 *间隔更快。 Schulzrinne等人 标准跟踪[第89页]
RFC 3550 RTP 2003年7月 * / 若是（初始）{ rtcp_min_time / = 2; } / * *将RTCP带宽的一小部分分配给发送者，除非 *发件人的数量足够大，他们的份额是 *超过这个分数。 * / n =成员; 若是（发件人<=成员* RTCP_SENDER_BW_FRACTION）{ if（we_sent）{ rtcp_bw * = RTCP_SENDER_BW_FRACTION; n =发件人; } else { rtcp_bw * = RTCP_RCVR_BW_FRACTION; n - =发件人; } } / * *站点的有效数量乘以平均数据包大小 *每一个站点发送报告时发送的八位字节总数。 *除以有效带宽给出的时间 *必须发送这些数据包的时间间隔 *知足带宽目标，最低强制执行。在那里面 *咱们发送一份报告的时间间隔，因此此次也是咱们的 *报告之间的平均时间。 * / t = avg_rtcp_size * n / rtcp_bw; 若是（t <rtcp_min_time）t = rtcp_min_time; / * *避免流量忽然意外同步 *其余网站，咱们而后选择咱们的实际下一个报告间隔做为一个 *随机数均匀分布在0.5 * t和1.5 * t之间。 * / t = t *（drand48（）+ 0.5）; t = t /补偿; 返回t; } void OnExpire（event e， int成员， int发件人， 双rtcp_bw， int we_sent， double * avg_rtcp_size， Schulzrinne等人 标准跟踪[第90页]
RFC 3550 RTP 2003年7月 int *初始， time_tp tc， time_tp * tp， int * pmembers） { / *这个函数负责决定是否发送一个 *如今RTCP报告或BYE包，或从新安排传输。 *它也负责更新pmembers，initial，tp， *和avg_rtcp_size状态变量。这个功能应该是 调用Schedule（）使用的事件计时器到期。 * / 成对的东西; / *间隔* / 双tn; / *下一次传输时间* / / *在BYE的状况下，使用“定时器从新考虑” *必要时从新安排BYE的传输* / if（TypeOfEvent（e）== EVENT_BYE）{ t = rtcp_interval（成员， 发件人， rtcp_bw， 咱们发送， * avg_rtcp_size， *初始）; tn = * tp + t; 若是（tn <= tc）{ SendBYEPacket（E）; 出口（1）; } else { 附表（tn，e）; } （else）if（TypeOfEvent（e）== EVENT_REPORT）{ t = rtcp_interval（成员， 发件人， rtcp_bw， 咱们发送， * avg_rtcp_size， *初始）; tn = * tp + t; 若是（tn <= tc）{ SendRTCPReport（E）; * avg_rtcp_size =（1./16.)*SentPacketSize（e）+ （15./16.)*(*avg_rtcp_size）; * tp = tc; / *咱们必须重画间隔。不要重复使用 Schulzrinne等人 标准跟踪[第91页]
RFC 3550 RTP 2003年7月 一个以上计算，由于它不是实际 分发同样，由于咱们是有条件的 它是足够小，致使一个数据包 被发送* / t = rtcp_interval（成员， 发件人， rtcp_bw， 咱们发送， * avg_rtcp_size， *初始）; 附表（T + TC，E）; * initial = 0; } else { 附表（tn，e）; } * pmembers =成员; } } void OnReceive（packet p， 事件e， int *成员， int * pmembers， int *发送者， double * avg_rtcp_size， 双* tp， 双tc， 双tn） { / *咱们作什么取决于咱们是否已经离开了这个组织 *等待发送一个BYE（TypeOfEvent（e）== EVENT_BYE）或一个RTCP *报告。p表示刚收到的数据包。* / if（PacketType（p）== PACKET_RTCP_REPORT）{ if（NewMember（p）&&（TypeOfEvent（e）== EVENT_REPORT））{ 使用addMember（P）; *会员+ = 1; } * avg_rtcp_size =（1./16.)*ReceivedPacketSize（p）+ （15./16.)*(*avg_rtcp_size）; } else if（PacketType（p）== PACKET_RTP）{ if（NewMember（p）&&（TypeOfEvent（e）== EVENT_REPORT））{ 使用addMember（P）; *会员+ = 1; } if（NewSender（p）&&（TypeOfEvent（e）== EVENT_REPORT））{ Schulzrinne等人 标准跟踪[第92页]
RFC 3550 RTP 2003年7月 AddSender（P）; *发件人+ = 1; } } else if（PacketType（p）== PACKET_BYE）{ * avg_rtcp_size =（1./16.)*ReceivedPacketSize（p）+ （15./16.)*(*avg_rtcp_size）; if（TypeOfEvent（e）== EVENT_REPORT）{ if（NewSender（p）== FALSE）{ RemoveSender（P）; *发件人 - = 1; } if（NewMember（p）== FALSE）{ RemoveMember（P）; *会员 - = 1; } if（* members <* pmembers）{ tn = tc + （（（double）* members）/（* pmembers））*（tn - tc）; * tp = tc - （（（double）* members）/（* pmembers））*（tc - * tp）; / *从新安排时间tn的下一个报告* / 从新安排（tn，e）; * pmembers = *会员; } （else）if（TypeOfEvent（e）== EVENT_BYE）{ *会员+ = 1; } } } Schulzrinne等人 标准跟踪[第93页]
RFC 3550 RTP 2003年7月 估计到达间隔抖动 下面的代码段实现了6.4.1 节 给出的算法用于计算的统计方差的估计 RTP数据到达间隔时间被插入到间隔抖动中 接待领域的报道。输入是r-> ts，来自的时间戳 传入的数据包和到达，当前时间在相同的单位。 这里要指出来源; s->中转持有亲属 前一个数据包的传输时间，以及s-> jitter保存 估计抖动。接收报告的抖动字段是 以时间戳单位测量并表示为无符号整数，可是 抖动估计保持在浮点。做为每一个数据包 到达时，抖动估计值被更新： int transit = arrival - r-> ts; int d = transit - s-> transit; s-> transit = transit; 若是（d <0）d = -d; s-> jitter + =（1./16。）*（（double）d - s-> jitter）; 接收报告块（rr点数）生成时 这个成员，当前的抖动估计被返回： rr-> jitter =（u_int32）s-> jitter; 或者，抖动估计能够保持为整数，可是 缩小以减小舍入偏差。除了计算是相同的 最后一行： s-> jitter + = d - （（s-> jitter + 8）>> 4）; 在这种状况下，接收报告的估计值被采样为： rr-> jitter = s-> jitter >> 4; Schulzrinne等人 标准跟踪[第94页]
RFC 3550 RTP 2003年7月 附录B - RFC 1889的变化 这个RFC的大部分与RFC 1889相同。有没有变化 线上的数据包格式，只改变规则和 管理如何使用协议的算法。最大的变化是 对可扩展定时器算法进行加强以计算什么时候 发送RTCP数据包： 计算RTCP传输间隔的算法 在6.2节和6.3节中有规定，并在附录A.7中说明 被增长以包括“从新考虑”以最小化传输 当许多参与者加入时，超过预期的费率 会议同时进行，“逆向从新考虑”减小 虚假参与者超时的发生率和持续时间 参与者人数迅速降低。反向重审是 也用于在发送RTCP SR以前可能缩短延迟 当从被动接收器转换到主动发送器模式时。 o 第6.3.7节指定新的规则控制RTCP BYE时 应该发送数据包，以免数据包泛滥 许多参与者同时离开会议。 o要求为非活动的参与者保留状态 足够长的时间跨越典型的网络分区被删除 来自第6.2.1节。在许多参与者加入的会议中 短暂的时间和不能发送BYE，这个要求会致使一个 显着高估了参与者的人数。该 本修订中增长的复议算法能够补偿 当大量的新参与者同时加入时 分区治愈。 应该指出，这些加强只有一个重要的 当会议参与者数量很大时（千） 大部分参与者同时参加或离开。这个 使现场网络测试困难。可是，算法 进行了完全的分析和模拟验证 性能。此外，加强算法的设计 与RFC 1889中的算法互操做， 在一个步骤中减小过多的RTCP带宽是成比例的 到实施加强的参与者的一小部分 算法。两种算法的互操做性已获得验证 在实时网络上进行实验。 其余功能变化是： o 第6.2.1节指定实现可能只存储一个 对参与者的SSRC标识符进行抽样以容许缩放 很是大的会议。算法在RFC 2762 [ 21 ] 中指定。 Schulzrinne等人 标准跟踪[第95页]
RFC 3550 RTP 2003年7月 o在6.2节，规定了RTCP发送者和非发送者 带宽能够被设置为会话的单独参数 比会话带宽的严格百分比，而且能够被设置 归零。RTP会话必须使用RTCP 使用IP多播被放宽。然而，澄清也是 补充说，关闭RTCP不推荐。 ○在第6.2，6.3.1和附录A.7，它是指定的 参与者的分数低于发送者的专用RTCP 带宽从固定1/4变化到基于RTCP的比率 发送者和非发送者带宽参数。 在那里没有带宽专用于发件人的条件 没有发件人被删除，由于这是预期的 过渡状态。它也让非发件人使用发件人 RTCP带宽时，这是否是打算。 o也在第6.2节也规定了最小的RTCP时间间隔 对于高带宽会话能够缩放到更小的值，而且 对于单播，初始RTCP延迟可能被设置为零 会话。 o指定参与者的时间应以不活动为基础 的使用接收方RTCP计算的RTCP报告间隔 即便对于主动发送者也是如此。 o 7.2和7.3节规定了译员和混音师应该这样作 发送BYE数据包为他们再也不转发的来源。 o分层编码的规则更改在2.4节中定义， 6.3.9,8.3和11.在最后这些，注意到 地址和端口分配规则与SDP冲突 规范，RFC 2327 [ 15 ]，但它的目的是这样的 在RFC 2327的修订中将会放宽限制。 o在RTP和RTCP中使用偶数/奇数端口对的惯例 第11条澄清了指的是目的港。该 若是使用偶数/奇数端口对的要求被删除 端口是明确指定的。对于单播RTP会话， 可用于两个端部不一样的端口对（第3，7.1 和11）。 o增长了新的第10节来解释要求 使用RTP的应用程序拥塞控制。 o在8.2节中，新SSRC标识符必须是的要求 每当源传输地址被改变时被选择 轻松地说能够选择一个新的SSRC标识符。 相应地，澄清了一个实现可能 Schulzrinne等人 标准跟踪[第96页]
RFC 3550 RTP 2003年7月 选择保留新的源地址而不是数据包 现有的源地址在两个SSRC冲突发生之间 其余参与者，并应该这样作的应用程序，如 电话，其中一些来源，如移动实体可能会改变 RTP会话过程当中的地址。 o 在伪造代码的RFC 1889打印中的缩进错误8.2节中 的碰撞检测和解决算法 已经经过将语法翻译成伪C语言来纠正， 并修改了算法以消除这个限制 RTP和RTCP必须从相同的源端口号发送。 o对RTCP数据包的填充机制的描述是 澄清，并指定填充必须只适用于 复合RTCP分组的最后一个分组。 o在A.1节中，base_seq的初始化被纠正为seq 而不是seq - 1，文字纠正说很差 序号加1存储。max_seq的初始化 和其余变量的算法是从文本中分离出来的 要明确这个初始化必须除了作 调用init_seq（）函数（并在RFC 1889中丢失了一些单词 当处理文件从源文件到输出文件时 恢复）。 o在A.3节中丢失的数据包数量被纠正为 使用正面和负面的限制。 o RTCP SR中“相对”NTP时间戳的规范 如今将这些时间戳定义为基于最多的时间戳 常见的系统专用时钟，好比系统正常运行时间，而不是 在会议上经历的时间将不会是相同的多个 应用程序在不一样的时间在同一台机器上启动。 非功能性更改： o指定接收者必须忽略有效载荷的数据包 类型它不明白。 o在图2中，浮点NTP时间戳值被校订， 一些丢失的前导零被添加在一个十六进制数和UTC 时区被指定。 o NTP时间戳在一年中的不合时宜 2036解释。 Schulzrinne等人 标准跟踪[第97页]
RFC 3550 RTP 2003年7月 o RTCP分组类型和SDES类型的注册策略 在新的第15条中获得澄清 IANA考虑事项。该 建议实验者注册他们须要的数字 那么取消注册那些证实不须要的东西已被删除 同意使用APP和PRIV。配置文件名称的注册是 也指定了。 o UTF-8字符集的引用从 X / Open初步规范是RFC 2279。 o RFC 1597的参考更新为RFC 1918和RFC 2543的 参考更新为RFC 3261。 RFC 1889中 引入的最后一段， 警告实施者限制在互联网上的部署 被删除，由于它被认为再也不相关。 o关于使用与特定源相关的RTP的非规范性说明 组播（SSM）在第6节中添加。 o 第3节中“RTP会话”的定义扩展到了 认可单个会话可能会使用多个目标 运输地址（翻译者老是如此） 混音器），并解释一个RTP的显着特色 会话是每一个对应于一个单独的SSRC标识符 空间。增长了“多媒体会议”的新定义 减小对“会话”一词的混淆。 o“采样即时”的含义已经详细解释为 部分RTP头部的时间戳字段的定义 第5.1节。 o在几个地方对文本做了小的澄清， 有的回答了读者的提问。尤为是： - 在RFC 1889中，第2.2节第二句的前五个单词 在处理源文件到文档时丢失了 输出形式，但如今恢复。 -在溶液中加入一种“RTP媒体类型”的定义第3节至 容许在5.2 节中 解释复用RTP会话方面更加清楚 媒体。这部分如今也解释了复用 基于SSRC标识符的相同介质的多个来源 多是适当的，而且是组播会话的标准。 - “非RTP手段”的定义扩大到包括 构成非RTP手段的其余协议的例子。 Schulzrinne等人 标准跟踪[页98]
RFC 3550 RTP 2003年7月 - 扩展了会话带宽参数的描述 在第6.2节，包括说明控制权 流量带宽是除了会话带宽以外的 数据流量。 - 不一样的数据包持续时间对抖动计算的影响 在第6.4.4节中有解释。 - 终止和填充一系列SDES项目的方法 在第6.5节中获得澄清。 - 在SDES的描述中添加了IPv6地址示例第6.5.1节中的 CNAME 代替了“example.com” 其余示例域名。 - 安所有分如今增长了对IPSEC的正式引用 它是可用的，并说保密的方法 在本规范中定义的主要是编纂现有的 实践。建议更强的加密 诸如Triple-DES之类的算法可用于代替默认值 算法，并指出基于AES的SRTP配置文件将是 将来的正确选择。对弱点谨慎 添加了做为初始化向量的RTP头。它 还注意到有效载荷加密是必要的 容许标题压缩。 - 明确了RTCP的部分加密方法; 在 特别是，SDES CNAME只在一个部分被携带 复合RTCP分组被拆分。 - 明确只有一个复合RTCP数据包应该是 发送每一个报告间隔，若是有太多 报告的主动来源适合MTU，而后是一个子集 的来源应该选择多轮循环 间隔。 - 附录A.1中增长了一个说明，能够保存数据包 在RTP头部验证期间，并在成功后交付。 - 7.3节如今解释一个混合器聚合SDES数据包 因为更长的数据包和混频器，使用更多的RTCP带宽 经过RTCP天然发送的数据包高于 单一的来源率，但这两种行为是有效的。 - 第13节澄清了一个RTP应用程序可能使用多个 配置文件，但一般只有一个给定的会话。 Schulzrinne等人 标准跟踪[页99]
RFC 3550 RTP 2003年7月 - 术语必须，应该，能够等，如RFC 2119中所定义。 - 参考书目分为规范和信息 引用。
相关文章
- 1. RFC3550
- 2. python中文版-python有中文版吗
- 3. CorelDraw2020中文版
- 4. Matlab2018a中文版
- 5. Mastercam2021中文版
- 6. mastercam2020中文版
- 7. ANSYS2019中文版
- 8. Fiddler中文版
- 9. ECMAScript5.1中文版
- 10. UEStudio20中文版
- 更多相关文章...
- • R 绘图 - 中文支持 - R 语言教程
- • MySQL的版本以及版本号 - MySQL教程
- • Scala 中文乱码解决
- • SpringBoot中properties文件不能自动提示解决方法
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. RFC3550
- 2. python中文版-python有中文版吗
- 3. CorelDraw2020中文版
- 4. Matlab2018a中文版
- 5. Mastercam2021中文版
- 6. mastercam2020中文版
- 7. ANSYS2019中文版
- 8. Fiddler中文版
- 9. ECMAScript5.1中文版
- 10. UEStudio20中文版