实时传输协议--rtp协议详解/rtcp协议详解

1、简介

　　目前，在IP网络中实现实时语音、视频通信和应用已经成为网络应用的一个主流技术和发展方向，本文详细介绍IP协议族中用于实时语音、视频数据传输的标准协议RTP（ Real-time Transport Protocol）和RTCP（RTP Control Ptotocol）的主要功能。

　　2、RTP/RTCP协议简介

　　RTP 由 IETF（http://www.ietf.org/）定义在 RFC 3550和3551中。

　　RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议，与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性，此协议提供的服务包括数据顺序号、时间标记、传输控制等。

　　RTP通常与辅助控制协议RTCP一起工作，RTP只负责实时数据的传输，RTCP负责对RTP的通信和会话进行带外管理（如流量控制、拥塞控制、会话源管理等）。

　　3、RTP/RTCP协议层次和封装

　　RTP位于传输层（通常是UDP）之上，应用程序之下，实时语音、视频数据经过模数转换和压缩编码处理后，先送给RTP封装成为RTP数据单元，RTP数据单元被封装为UDP数据报，然后再向下递交给IP封装为IP数据包。

　　RTP分组只包含RTP数据，而控制是由另一个配套协议RTCP提供。RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个奇数UDP端口号。

　　RTP通常和RTCP一起工作，在RTP会话期间，各参与者周期的发送RTCP消息。RTCP消息含有已发送数据的丢包统计和网络拥塞等信息，服务器可以利用这些信息动态的改变传输速率，甚至改变净荷的类型。RTCP消息也被封装为UDP数据报进行传输。

　　4、RTP/RTCP协议头信息

　　version (V): 2 bits

　　标明RTP版本号。协议初始版本为0，RFC3550中规定的版本号为2。

　　padding (P): 1 bit

　　如果该位被设置，则在该packet末尾包含了额外的附加信息，附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因为一些加密机制需要固定长度的数据块，或者为了在一个底层协议数据单元中传输多个RTP packets。

　　extension (X): 1 bit

　　如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。

　　CSRC count (CC): 4 bits

　　在固定头部后存在多少个CSRC标记。

　　marker (M): 1 bit

　　该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。

　　payload type (PT): 7 bits

　　标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。

　　sequence number: 16 bits

　　序列号，每个RTP packet发送后该序列号加1，接收方可以根据该序列号重新排列数据包顺序。

　　timestamp: 32 bits

　　时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。

　　SSRC: 32 bits

　　数据源标识。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。

　　CSRC list: 0 to 15 items, 每个源标识32 bits

　　贡献数据源标识。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。

 

　　5、RTCP协议

　　RTCP协议处理机根据定义了五种类型的报文：

　　RR: receiver report

　　SR: sender report

　　SDES: source description items.

　　BYE: indicates end of participation.

　　APP: application specific functions

　　它们完成接收、分析、产生和发送控制报文的功能。

　　RTCP可以说是控制交通的协议，它提供了：

　　1）SR发送者报告分组：用来使发送端周期的向所有接收端用多播方式进行报告。内容包括：

　　该RTP流的SSRC；该RTP流中最新产生的RTP分组的时间戳和绝对时钟时间（或称墙上时间：wall clock time);该RTP流包含的分组数；该RTP流包含的字节数。

　　绝对时钟时间是必要的。因为RTP要求每一种媒体使用一个流。有了绝对时钟时间就可以进行图形和声音的同步。

　　2）RR接收者报告分组：用来使接收端周期性的向所有的点用多播方式进行报告。内容包括

　　所接收到的RTP流的SSRC；该RTP流的分组丢失率；在该RTP流中的最后一个RTP分组的序号；分组到达时间间隔的抖动等。

　　发送RR分组有两个目的。第一，可以使所有的接收端和发送端了解当前网络的状态。

　　第二，可以使所有发送RTCP分组的站点自适应的调整自己发送RTCP分组的速率，RTCP分组的通信量不超过网络中的数据分组的通信量的5%，而接收端分组报告分组的通信量又应小于所有RTCP分组的通信量的75%。

　　3）SDES源描述分组：给出会话中参加者的描述，包括参加者的规范名（CNAME）

　　4）BYE分组：关闭一个数据流。

　　5）APP分组：应用程序能够定义新的分组类型。

　　6、实时流协议RTSP协议

　　1） RTSP协议

　　RTSP（Real Time Streaming Protocol）协议定义了如何有效地通过IP网络传送多媒体数据，是一种客户端到服务器端的多媒体描述协议，详见RFC2326。

　　RTSP是一个非常类似于HTTP的应用层协议。每个发布和媒体文件也被定义为RTSP UPL。而媒体文件的发布信息被书写进一个被称为媒体发布文件里，这个文件在后面会说明。在这个文件说明的包括编码器，语言，RTSP ULS，地址，端口号以几其它参数。这个发布文件可以在客户端通过EMAIL形式或者HTTP形式获得。

　　2） RTSP协议的特点：

　　RTSP是应用层协议,与RTP、RSVP一起设计来完全流式服务。

　　RTSP有很大的灵活性，可被用在多种操作系统上,它允许客户端和不同厂商的服务平台交互。

　　RTSP在体系结构上位于RTP和RTCP之上，它使用RTP完成数据传输。它将流式媒体数据可控制的通过网络传输到客户端。

　　RTSP可以保持用户计算机与传输流业务服务器之间的固定连接，用于观看者与单播（Unicast）服务器通信并且还允许双向通信，观看者可以同流媒体服务器通信.

　　提供类似“VCR”形式的例如暂停、快进、倒转、跳转等操作。操作的资源对象可以是直播流也可以是存储片段。

　　RTSP是设还提供了选择传输通道，如使用UDP还是多点UDP或是TCP。

　　7、资源预留协议RSVP

　　1） RSVP协议：

　　RSVP (Resorce reSerVation Protocol) 资源预留协议并不是一个路由协议，而是一种IP网络中的信令协议，它与路由协议相结合来实现对网络传输服务质量（QoS）的控制。RSVP是为支持因特网综合业务而提出的。这是解决IP通信中QoS（服务质量）问题的一种技术，用来保证点端到端的传输带宽。

　　2） RSVP协议是如何工作：

　　RSVP使用控制数据报，这些数据报在向特定地址传输时包括了需要由路由器检查（有些时候需要更新）的信息,如果路由器需要决定是不是要检查数据报的内容的时候对上层数据内容进行语法分析。这种分析的代价可不小。现在的情况是，网络终端利用它向网络申请资源，在这种表明“申请” 的信号中，包含着如下的信息：业务的种类？ 使用者类型？ 什么时间？ 需要多大带宽？ 其他参考信息？ 网络在接收到上类信息后，会根据实际情况为此次连接分配一个优先代码，用户利用优先代码进行信息传递时，网络不需重新对业务进行分析与判别，从另外一个角度来说，利用RSVP 能从一定程度上减少网络对信息处理的时延，提高网络节点的工作效率，改善信息传输的服务质量（QoS）。实时应用用RSVP是为了在传输路径中保持必要的资源以保证请求能确保到达。

　　RSVP是IP路由器为提供更好的服务质量向前迈进的具有深刻意义的一步。传统上IP路由器只负责分组转发，通过路由协议知道邻近路由器的地址。而RSVP则类似于电路交换系统的信令协议一样，为一个数据流通知其所经过的每个节点（IP路由器），与端点协商为此数据流提供质量保证。

　　8、结束语

　　在前面我们讨论了一些与实时数据传输相关的四个协议：

　　1）RTP是实时数据传输协议。它提供时间标志，序列号以及其它能够保证在实时数据传输时处理时间的方法；它是依靠RVSP保证服务质量标准的。

　　2）RTCP是RTP的控制部分,是用来保证服务质量和成员管理的。

　　3）RTSP是开始和指引流媒体数据从流媒体服务器。它又可叫做"网上录像机控制协议".它是提供远程的控制，具体的数据传输是交给RTP的。

　　4）RSVP是Internet上的资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。就像TCP的重发和滑动窗口等都是

 

转自：http://www.cnblogs.com/li0803/archive/2010/11/20/1882792.html?login=1#commentform