RTP, RTCP, RTSP 协议介绍

流媒体是边下载边播放的方式, 是视频会议、IP电话等应用场合的技术基础。

         

为什么TCP/IP协议就不能满足多媒体通信的要求呢？
因为TCP有以下4个特点:
1.TCP重传机制
2.TCP拥塞控制机制
3.TCP报文头比UDP报文头要大
4.TCP的启动速度慢
对比：
IP:数据传输 RTP:多媒体数据实时传输
TCP:保证数据传输可靠 RTCP:保证多媒体数据传输的可靠

RTP提供时间标志,序列号以及其他能够保证在实时数据传输时处理时间的方法
RTCP是RTP的控制部分,是用来保证服务质量和成员管理的
RTSP具体数据传输交给RTP,提供对流的远程控制
RSVP预留带宽,提高QoS(Quality of Sever)

RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：
一个给RTP，一个给RTCP(RTP port + 1). RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，
它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。

RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。
RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。
RTSP 默认使用554端口, 非常类似 HTTP 协议的流控制协议, rtsp 的命令总是按照顺序来发送.

RTP/RTCP -------------------------RFC3550/RFC3551
RTSP --------------------------RFC2326

2.1 RTP数据协议 

RTP 为实时应用提供端到端的运输，但不提供任何服务质量的保证，服务质量由RTCP来提供。多媒体数据块经压缩编码处理后，先送给 RTP 封装成为 RTP 分组，再装入运输层的 UDP 用户数据报，然后再交给 IP 层。

RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示：

 

其中比较重要的几个域及其意义如下： 
      CSRC记数（CC）　　表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。 
      负载类型（PT）　　标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。 
      序列号　　用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。 
      时间戳　　记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。 从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的，如图2所示：

 

 

 

 

 

在RTP分组的首部中，前12个字节是必须的，12字节以后的是可选的。完整的RTP数据包格式如下：

RTP是目前解决流媒体实时传输问题的最好办法，存在一些开放源代码的RTP库，如LIBRTP、JRTPLIB等。JRTPLIB是一个面向对象的RTP库，它完全遵循RFC 3550（RFC 1889已过时）设计，是一个用C++语言实现的RTP库。