现在的位置: 首页 > 综合 > 正文

RTP协议分析

2013年08月26日 ⁄ 综合 ⁄ 共 3863字 ⁄ 字号 评论关闭

RTP协议分析

一,         背景

二.       RTP协议原理及工作机制

21 RTP协议原理

211 RTP协议原理

212 RTCP协议原理

22 RTP数据包格式

221 RTP数据包格式

222 RTCP数据包格式

23 RTP工作机制

231 RTP工作机制

232 RTCP工作机制

三.       RTP协议关键技术指标

3时间戳

32时延

3抖动

34丢包率

3会话和流两级分用

3多种流同步控制

四.       RTP协议应用方案

41 RTP协议应用方案之单播

42 RTP协议应用方案之广播

43 RTP协议应用方案之组播

43.1 RTP协议组播方案总体概述

43.2 RTP协议组播方案服务器端实现

43. 3RTP协议组播方案客户端实现

43. 4RTP协议视频帧率和质量调整策略

五.       RTP协议移植计划

六.       RTP协议安全方面考虑

 一.       RTP协议背景

流(Streaming)是近年在Internet上出现的新概念,其定义非常广泛,主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵:广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称,即流媒体技术;狭义上的流媒体是相对于传统的下载-回放方式而言的,指的是一种从Internet上获取音频和视频等多媒体数据的新方法,它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术,服务器能够向客户机发送稳定和连续的多媒体数据流,客户机在接收数据的同时以一个稳定的速率回放,而不用等数据全部下载完之后再进行回放。

流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送,特别适合现场事件,实时流式传输必须匹配连接带宽,这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系,这需要相应的协议支持,这样RTPRTCP就相应的出现了。

实时传输协议RTPRealtime Transport Protocol):是针对Internet上多媒体数据流的一个传输协议IETF作为RFC1889发布,现在最新的为RFC3550RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上,但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。

实时传输控制协议RTCPRealtime Transport Control Protocol):负责管理传输质量,在当前应用进程之间交换控制信息,提供流量控制和拥塞控制服务。在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTPRTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。

二.       RTP协议原理及工作机制

  让我们先看一下RTPRTCP在网络层次中的位置,以便我们更加清楚的了解该协议,如下图1-1所示:

 1-1 RTP&RTCP网络层次关系图

 下面我们就从RTP以及RTCP的协议原理,数据包格式,工作机制三个方面来对该协议做一个基本的认识和了解:

21 RTP协议原理

211 RTP协议原理

RTP协议原理比较简单,负责对流媒体数据进行封包并实现媒体流的实时传输,即它按照RPT数据包格式来封装流媒体数据,并利用与它绑定的协议进行数据包的传输,具体见本文2.2.1RTP数据格式RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务.

 212 RTCP协议原理

 RTCP原理是向会话中的所有成员周期性地发送控制包来实现的,应用程序通过接收这些控制数据包,从中获取会话参与者的相关资料,以及网络状况、分组丢失概率等反馈信息,从而能够对服务质量进行控制或者对网络状况进行诊断.

RTCP协议的功能是通过不同的RTCP数据报文(具体描述的见2.2.2RTCP数据包格式)来实现的,主要有如下几种类型:

  • SR(Sender Report) 发送端报告,所谓发送端是指发出RTP数据报的应用程序或者终端,发送端同时也可以是接收端。
  • RR(Receiver Report) 接收端报告,所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
  • SDES 源描述,主要功能是作为会话成员有关标识信息的载体,如用户名、邮件地址、电话号码等,此外还具有向会话成员传达会话控制信息的功能。
  • BYE 通知离开,主要功能是指示某一个或者几个源不再有效,即通知会话中的其他成员自己将退出会话。
  • APP 由应用程序自己定义,解决了RTCP的扩展性问题,并且为协议的实现者提供了很大的灵活性。

RTCP数据报携带有服务质量监控的必要信息,能够对服务质量进行动态的调整,并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是组播方式,因此会话中的所有成员都可以通过RTCP数据报返回的控制信息,来了解其他参与者的当前情况。

例如在流媒体应用场合下,发送媒体流的应用程序将周期性地产生发送端报告SR,该RTCP数据报含有不同媒体流间的同步信息,以及已经发送的数据报和字节的计数,接收端根据这些信息可以估计出实际的数据传输速率。另一方面,接收端会向所有已知的发送端发送接收端报告RR,该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息,发送端应用根据这些信息可以估计出往返时延,并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率,以改善网络拥塞状况,或者根据网络状况平滑地调整应用程序的服务质量。

RTCP具有以下四个功能: 
1
基本功能是提供数据传输质量的反馈.这是RTP作为一种传输协议的主要作用,它与其他协议的流量和阻塞控制相关.反馈可能对自适应编码有直接作用,但是IP组播的实验表明它对于从接收机得到反馈信息以诊断传输故障也有决定性作用.向所有成员发送接收反馈可以使"观察员"评估这些问题是局部的还是全局的.利用类似多点广播的传输机制,可以使某些实体,诸如没有加入会议的网络网络业务观察员,接收到反馈信息并作为第三类监视员来诊断网络故障.反馈功能通过RTCP发射机和接收机报告实现
2
RTCP为每个RTP源传输一个固定的识别符,称为标称名或CNAME.由于当发生冲突或程序重启时SSRC可能改变,接收机要用CNAME来跟踪每个成员.接收机还要用CNAME来关联一系列相关RTP会话期中来自同一个成员的多个数据流,例如同步语音和图象
3
前两个功能要求所有成员都发送RTCP,因此必须控制速率以使RTP成员数可以逐级增长.通过让每个成员向所有成员发送控制包,各个成员都可以独立地观察会议中所有成员的数目
4
可选的功能是传输最少的会议控制信息,例如在用户接口中显示的成员识别.这最可能在"松散控制"的会议中起作用,"松散控制"会议里,成员可以不经过资格控制和参数协商而加入或退出会议.RTCP作为一个延伸到所有成员的方便通路,必须要支持具体应用所需的所有控制信息通信.

22 RTP数据包格式

221 RTP数据包格式

RTP报文头格式(见RFC3550 Page12):

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

抱歉!评论已关闭.