更新时间：2023-12-24 14:41
RTP（real-time transport protocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。
旧版的RFC1889在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。
RTP协议的报文格式如图1：
前12个字节出现在每个RTP包中，仅仅在被混合器插入时，才出现CSRC识别符列表。这些域有以下意义：
当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口+1），这样就构成一个UDP端口对。 RTP的发送过程如下，接收过程则相反。
1) RTP协议从上层接收流媒体信息码流（如H.263），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
2)RTP将RTP数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
RTP以一个控制协议（RTCP）结合它的数据传送,使监测大型的多点网络数据递送成为可能。 监测允许接收器发现是否有任何的信息包丢失和为任何的延迟跳动补偿。两个协议独立地在底部传送层和网络层协议工作。RTP 报头的信息告诉接收器该如何重建数据而且描述 codec比特流是如何被打包的。通常，RTP在用户数据包协议（UDP）的顶端运行,虽然它能使用其他的传送协议。会议开始协议（SIP）和 H.323 都使用 RTP。
协议包括如下几个特点：
RTP协议相对来说比较简单，比如说它的报头固定部分只包含12字节（Byte），所以开销很小，有利于提高传输效率。灵活性体现在把协议机制和控制策略的具体算法分开。协议本身只提供完成实时传输的机制，对控制策略的有效算法实现不做具体规定。开发者可以根据不同的应用环境，选择实现效率较高的算法和合适的控制策略。
RTP最初设计的目的是Internet，但它更倾向于发展成为独立于底层协议的传输协议。RTP一般建立在UDP协议之上，充分利用了UDP协议的的多路复用服务，它也可以建立在其他协议之上，像ATM、IPV6,、AAL5等，所以RTP协议具有很好的独立性。
RTP协议采用时间戳（Timestamp）来控制单一媒体数据流的同步，但它本身并不能控制不同媒体数据流间的同步。如要实现不同数据流之间的同步，必须由应用程序参与完成。
由于RTP协议设计的目的是传输实时数据，而不是可靠的数据，因此它不能提供有关错误检测和报文顺序检测的机制。
RTP组成包括：一个序列数字，用来发现丢失的信息包；负载量确认, 描述特定的媒体编码以便如果它必须适应带宽的变化的时候，它能被改变；帧指示，为每个帧的开始和结束作标记；来源确认，识别帧的发送者；还有媒体本身同步，使用时间戳在单个流里面发现不同的延迟跳动并且为它补偿。
RTPC组成包括: 服务质量（QoS）反馈，包括丢失信息包的数量，来回旅程时间和跳动，所以来源能适当地调整他们的数据速率；会议控制，使用 RTCP BYE（再见）信息包允许叁加者显示他们正在离开会议；确认，为其他参加者提供信息包括参加者的名字，电子邮件账号和电话号码；还有媒介物同步，使分离的声音和视频流能够同步。
在RFC 2509中被指定的被压缩的 RTP（CRTP），被发展用来减少 IP、UDP 和RTP 报头的大小。 然而，它被设计成以可靠和快速的点对点链接工作。在不是最佳的环境中，可能有长的延迟,信息包丢失和无序信息包，CRTP 在 通过IP网络传送话音（VoIP）应用上表现不佳。另外的一个改进，增强 CRPT（ECRPT），被定义在一个后来的英特网草案中以克服这个问题。
协议主要使用在如下几个场景：
IETF的一个工作组开会讨论最新协议草案时，使用Internet的IP多播服务来进行语音通讯。工作组中心分配到一个多播的组地址和一对端口。一个端口用于音频数据，另一个端口用于控制（RTCP）数据包。该地址和端口信息发布给预定的参与者。如果有私密性要求，对数据和控制包进行加密，这时就需要生成和发布加密密钥。分配和发布机制的精确细节不在RTP的讨论范围之内。
每个与会者所使用的音频会议应用程序，都以小块形式（比方说持续20秒时间）来发送音频数据。每个音频数据块都前导RTP报头；RTP报头和数据依次包含在UDP包里。RTP报头指明了各个包里音频编码的类型（如PCM,ADPCM,LPC），这样发送方可以在会议过程中改变编码方式，以适应状况的变化，例如，要加进一个低带宽接入的参与者，或是要应付网络拥塞。
Internet，像其他的报文分组网络一样，偶而会丢失和重排包，造成时长不等的延迟。为弥补这个不足，RTP报头里包含计时信息和一个序列号，允许接收方重建来自源的计时信息，比如前文例子中音频块以20s的间隔在扬声器中连续播放。会议中，对每个RTP包的源,单独地实施计时重建。序列号还被接收方用来评估丢失包数目。
由于会议期间不断有工作组成员加入或离开，因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。出于这个目的，会议中每个音频应用程序的实例，都在RTCP（控制）端口上周期性地多播一个附加用户名的接收报告。接收报告指明了当前说话者被收听到的状况，可用于控制自适应性编码。除了用户名外，通过控制带宽限度，可以包含其他标识信息。一个站点在离开会议时发送RTCP BYE包。
一个会议如果同时使用音频和视频媒体，则二者传输时使用不同的RTP会话。也就是说，两种媒体中RTP包和RTCP包的传输，是使用两个不同的UDP端口对和（或）多播地址。在RTP层次，音频和视频会话没有直接的耦合，下面这种情况除外：一个同时参加两个会话的参与者，在两个会话的RTCP包中，使用了相同的规范名，这样两个会话就发生关联（耦合）了。这样区隔开来的目的之一，是允许一些会议参与者只接受自己选择的单一媒体（或者音频，或者视频）。尽管两种媒体区分开来了，但通过两个会话RTCP包内载有的计时信息，同源的音频与视频还是能够同步回放。
到目前为止，我们皆假设所有站点都收到相同格式的媒体数据。然而这并不总是行得通。考虑一下这种情况，一个地方的参与者只能低速接入会议，而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽，不如在只能低速接入的地方，放置一个减质量音频编码的RTP层次的中继（称作混频器）。混频器将重新同步输入的音频包，重建发送方产生的20ms固定间隔，混频已重建过的音频流为单一的流，转换音频编码为低带宽格式，最后通过低带宽连接转发数据包流（package stream）。这些包可能被单播到一个接收方，也可能多播到另一个的地址而发给多个接收方。RTP报头为混频器提供了一种方法，使其能辨识出对混频后的包有用的源，从而保证提供给接收方正确的说话者指示。
在音频会议中，一些预定参与者尽管有高带宽连接，但不能通过IP多播直接接入会议。例如，他们可能位于一个不允许任何IP包通过的应用层防火墙后面。对这些站点，可能就不需要混频，而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器，外侧转换器将所有多播包通过安全连接转入内侧转换器，内侧转换器再转发给内部网的一个多播组（multicast group）。
混频器和转换器可以设计成用于各种目的。比如，一个视频混频器在测量多个不同视频流中各人的单独影像后，将它们组合成一个单一视频流来模拟群组场景。又如，在只用IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如，在没有重新同步或混频时，用packet-by-packet编码转换来自各个独立源的视频流。
为了匹配接收方的能力（容量）以及适应网络拥塞，多媒体应用程序应当能够调整其传输速率。许多应用实现把调适传输速率的责任放在源端。这种做法在多播传输中并不好，因为不同接收方对带宽存在着冲突性需求。这经常导致最小公分母的场景，网格中最小的管道支配了全部实况多媒体“广播”的质量和保真度。
相反地，可以把分层编码和分层传输系统组合起来，从而把调适速率的责任放在接收端。在IP多播之上的RTP上下文中，对一个横跨多个RTP会话（每个会话在独自多播组上开展）的分级表示信号(hierarchically represented signal)，源能够把它的分层（layers）分割成条。 接收方仅需合并适当的多播组子集，就能适应异种网络和控制接收带宽。