RTP协议分析
第2章. RTP详解
2.1. RTP的协议层次
2.1.1. 传输层的子层
RTP(实时传输协议),顾名思义它是用来提供实时传输的,因而可以看成是传输层的一个子层。图 1给出了流媒体应用中的一个典型的协议体系结构。
图1流媒体体系结构
从图中可以看出,RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。这些特点,在第4章可以看到。
2.1.2. 应用层的一部分
不少人也把RTP归为应用层的一部分,这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务,而RTP的实现还是要靠开发者自己。因此从开发的角度来说,RTP的实现和应用层协议的实现没不同,所以可将RTP看成应用层协议。
RTP实现者在发送RTP数据时,需先将数据封装成RTP包,而在接收到RTP数据包,需要将数据从RTP包中提取出来。
2.2. RTP的封装
一个协议的封装是为了满足协议的功能需求的。从前面提出的功能需求,可以推测出RTP封装中应该有同步源和时戳等字段,但更为完整的封装是什么样子呢?请看图2。
图 2 RTP的头部格式
版本号(V):2比特,用来标志使用的RTP版本。
填充位(P):1比特,如果该位置位,则该RTP包的尾部就包含附加的填充字节。
扩展位(X):1比特,如果该位置位的话,RTP固定头部后面就跟有一个扩展头部。
CSRC计数器(CC):4比特,含有固定头部后面跟着的CSRC的数目。
标记位(M):1比特,该位的解释由配置文档(Profile)来承担.
载荷类型(PT):7比特,标识了RTP载荷的类型。
序列号(SN):16比特,发送方在每发送完一个RTP包后就将该域的值增加1,接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。
时间戳:32比特,记录了该包中数据的第一个字节的采样时刻。在一次会话开始时,时间戳初始化成一个初始值。即使在没有信号发送时,时间戳的数值也要随时间而不断地增加(时间在流逝嘛)。时间戳是去除抖动和实现同步不可缺少的。
同步源标识符(SSRC):32比特,同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。
贡献源列表(CSRC List):0~15项,每项32比特,用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。
2.3. RTCP的封装
RTP需要RTCP为其服务质量提供保证,因此下面介绍一下RTCP的相关知识。
RTCP的主要功能是:服务质量的监视与反馈、媒体间的同步,以及多播组中成员的标识。在RTP会话期间,各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,各参与者可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。
从图 1可以看到,RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。
类型 | 缩写表示 | 用途 |
200 | SR(Sender Report) | 发送端报告 |
201 | RR(Receiver Report) | 接收端报告 |
202 | SDES(Source Description Items) | 源点描述 |
203 | BYE | 结束传输 |
204 | APP | 特定应用 |
表 1 RTCP的5种分组类型
上述五种分组的封装大同小异,下面只讲述SR类型,而其它类型请参考RFC3550。
发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如图3所示。
图 3 RTCP头部的格式
版本(V):同RTP包头域。
填充(P):同RTP包头域。
接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。
包类型(PT):8比特,SR包是200。
长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。
同步源(SSRC):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
NTPTimestamp(Network timeprotocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。
RTPTimestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。
Sender’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。
Sender`soctet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。
同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。
丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。
累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,
接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计
上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。
上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。
2.4. RTP的会话过程
当应用程序建立一个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端口对中的接收端口。
第3章. 相关的协议
3.1. 实时流协议RTSP
实时流协议RTSP(Real-Time Streaming Protocol)是IETF提出的协议,对应的RFC文档为RFC2362。
从图 1可以看出,RTSP是一个应用层协议(TCP/IP网络体系中)。它以C/S模式工作,它是一个多媒体播放控制协议,主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制,即可以对流媒体进行暂停/继续、后退和前进等控制。
3.2. 资源预定协议RSVP
资源预定协议RSVP(Resource Reservation Protocol)是IETF提出的协议,对应的RFC文档为RFC2208。
从图 1可以看出,RSVP工作在IP层之上传输层之下,是一个网络控制协议。RSVP通过在路由器上预留一定的带宽,能在一定程度上为流媒体的传输提供服务质量。在某些试验性的系统如网络视频会议工具vic中就集成了RSVP。
第4章. 常见的疑问
4.1. 怎样重组乱序的数据包
可以根据RTP包的序列号来排序。
4.2. 怎样获得数据包的时序
可以根据RTP包的时间戳来获得数据包的时序。
4.3. 声音和图像怎么同步
根据声音流和图像流的相对时间(即RTP包的时间戳),以及它们的绝对时间(即对应的RTCP包中的RTCP),可以实现声音和图像的同步。
4.4. 接收缓冲和播放缓冲的作用
如1.3.1所述,接收缓冲用来排序乱序了的数据包;播放缓冲用来消除播放的抖动,实现等时播放。
第5章. 实现方案
ID | Protocol | Captured contents | ||||||
Account | password | Local telephone number | Opponents Telephone Number | audio | login | logout | ||
36 | Rtp |
|
|
|
| √ |
|
|
表2协议分析要求
表 2给出了协议分析要求。容易看出要获取RTP音频包中的音频信息很容易,直接将RTP包的包头去掉即可。当然,要成功地播放解码获取到的音频流,需要知道其编码,这可从RTP包包头的有效载荷类型字段(PT)获得。
第6章. 参考资料
[1] RFC文档:RFC3550对应RTP/RTCP,RFC2362对应RTSP,RFC2208对应RSVP
[2] http://www.faqs.org/rfcs/,上面有全面的英文RFC文档
[3] http://www.cnpaf.net/,有不少协议分析文档,也有中文RFC文档,但质量不是特别高。
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 ofparticipation.
APP: application specificfunctions
它们完成接收、分析、产生和发送控制报文的功能。
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 reSerVationProtocol) 资源预留协议并不是一个路由协议,而是一种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的重发和滑动窗口等都是