RTP是由IETF的音频/视频传输工作组开发的，后来被国际电联作为其H.323系列建议的一部分而采用，并被其他各种标准组织采用。RTP的第一个版本是在1996年1月完成的，在完成之前需要对特定用途的RTP进行概要分析；RTP规范定义了一个初始概要，还有几个概要正在开发中。附带几个负载格式规范的配置文件描述了特定媒体格式的传输。
IP网络中音频/视频传输的关键标准是实时传输协议(RTP)及其相关的配置文件和有效负载格式。RTP 旨在通过IP网络提供对实时媒体传输有用的服务，如音频和视频。这些服务包括定时恢复、丢包检测和恢复、负载和源标识、接收质量反馈、媒体同步和会员管理。RTP最初设计用于多播会议，使用轻量级会话模型。从那时起，它已被证明对一系列其他应用有用：H.323视频会议、网络广播和电视分发；有线电话和移动电话都是如此。该协议已被证明可以从点对点使用扩展到具有数千用户的多播会话，从低带宽蜂窝电话应用程序扩展到以千兆比特速率传输未压缩的高清晰度电视(HDTV)信号。
RTP相关标准
除了RTP之外，完整的系统通常还需要使用各种其他协议和标准来进行会话通知、启动和控制、媒体压 缩和网络传输。
图1.1显示了根据IETF和国际电信联盟会议框架，协商和呼叫控制协议、媒体传输层(由RTP提供)、压缩解压算法(codecs)和底层网络之间的关系。这两套并行的呼叫控制和媒体协商标准使用相同的媒体传输框架。同样，不管会话是如何协商的，也不管底层网络传输是什么，媒体编解码器都是通用的。
RTP 实现的概述
如图1.1所示，任何通过IP传输实时音频/视频的系统的核心都是RTP，它提供公共的媒体传输层，独立于信令协议和应用程序。在我们更详细地研究RTP和使用RTP的系统设计之前，有必要了解一下系统中 RTP发送方和接收方的职责。 RTP发送方的行为 发送方负责采集和转换用于传输的视听数据，以及生成RTP包。它还可以通过调整传输的媒体流以响 应接收方的反馈来参与错误恢复和拥塞控制。发送过程的关系如图1.2所示。
未压缩的媒体数据—音频或视频—被采集到缓冲区中，从中产生压缩帧。帧可以根据使用的压缩算法以多种方式进行编码，编码后的帧可能同时依赖于之前和之后的数据。
压缩帧被装入RTP包中，准备发送。如果帧很大，它们可能被分成几个RTP包;如果它们很小，可以将几个帧绑定到一个RTP包中。根据使用中的错误恢复方案，可以使用信道编码器来生成错误恢复包或在传输之前重新对包进行排序。
发送RTP包之后，与这些包对应的缓冲媒体数据最终将被释放。发送方不得丢弃可能需要用于错误恢复或编码过程的数据。这个要求可能意味着发送方在发送了相应的数据包之后，必须将数据缓存一段时间，这取决于所使用的编解码器和错误恢复方案。
发送方负责生成它所生成的媒体流的定期状态报告，包括唇音同步所需的媒体流。它还从其他参与者那里收到接收质量反馈，并可能利用这些信息来调整其传输。
RTP接收方的行为
接收方负责从网络中收集RTP数据包，恢复丢失的数据，纠正时序，解压媒体，并将结果显示给用户。它还发送接收质量反馈，允许发送方调整到接收方的传输，并维护会话中参与者的数据库。接收过程可能的方框图如图1.3所示；然而具体实现有时根据需要以不同的顺序执行操作。
接收过程的第一步是收集来自网络的数据包，验证它们的正确性，并将它们插入到特定发送者的输入队列中。从输入队列中收集数据包，并将其传递给可选的信道编码例行程序以恢复丢失的数据。在通道编码器之后，数据包被插入到特定源的播放缓冲区中。播放缓冲区按时间戳排序，将数据包插入缓冲区的过程纠正了传输期间引起的排序错乱。数据包一直保留在播放缓冲区中，直到接收到完整的帧为止，另外还对它们进行额外的缓冲，以消除由网络引起的包间计时的任何变化。计算要添加的延迟量是RTP实现设计中最关键的方面之一。每个包都用相应帧所需的播放时间进行标记。
当它们的播放时间到达后，这些包形成完整的帧，任何损坏或丢失的帧都被修复。在进行任何必要的修复之后，帧将被解码(根据使用的编解码器，在修复丢失的帧之前可能需要解码媒体)。在这一点 上，发送方和接收方的名义时钟速率可能有明显的差异。这些差异表现为RTP媒体时钟相对于播放时钟的值的偏移。接收器必须补偿这个时钟偏差，以避免在播放中出现间隙。
从这篇简短的概述中可以明显看出，RTP接收方的操作很复杂，它比发送方的操作更加复杂。这种复杂性的增加主要是由于IP网络的可变性:大部分复杂性来自于补偿丢失的包的需要，以及恢复受抖动影响的流的时序。
以上内容来自：《RTP: Audio and Video for the Internet 中文版》，仅供分享参考学习。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/21858.html
