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库