嵌入式 RTP协议详解以及其他相关协议
![此博文包含图片](https://i-blog.csdnimg.cn/blog_migrate/a4c26d1e5885305701be709a3d33442f.gif)
RTP协议 1 RTP报文格式 2 基于RTP的带宽控制方法 2.1.接收端的控制策略 2.2.发送端的控制策略 RTP与RTCP协议介绍
1.流媒体( Streaming Media)
1.1流媒体概念
流媒体技术是网络技术和多媒体技术发展到一定阶段的产物。术语流媒体既可以指在网上传输连续时基媒体的流式技术,也可以指使用流式技术的连续时基媒体本身。在网上传输音频、视频等多媒体信息目前主要有两种方式:下载和流式传输。采用下载方式,用户需要先下载整个媒体文件,然后才能进行播放。由于网络带宽的限制,下载常常要花很长时间,所以这种处理方式延迟很大。而流媒体实现的关键技术是流式传输。传输之前首先对多媒体进行预处理(降低质量和高效压缩) ,然后使用缓存系统来保证数据连续正确地进行传输。使用流式传输方式,用户不必像采用下载方式那样要等到整个文件全部下载完毕,而是只需经过几秒到几十秒的启动延时即可在客户端进行播放和观看。此时媒体文件的剩余部分将在后台继续下载。与单纯的下载方式相比,这种对多媒体文件边下载边播放的流式传输方式不仅使启动延时大幅度地缩短,而且对系统缓存容量的需求也大大降低。使用流式传输的另一个好处是使传输那些事先不知道或无法知道大小的媒体数据(如网上直播、视频会议等)
到目前为止,Internet
1.2支持流媒体的协议
多媒体应用的一个显著特点是数据量大,并且许多应用对实时性要求比较高。传统的TCP
图1
2.实时传输协议RTP(Real-Time Transport Protocol):
RTP是针对Internet上多媒体数据流的一个传输协议,
2.1 RTP工作机制
威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是rtp本身并不负责同步,rtp只是传输层协议,为了简化运输层处理,提高该层的效率。将部分运输层协议功能(比如流量控制)上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能,不提供任何机制来保证实时地传输数据,不支持资源预留,也不保证服务质量。rtp报文甚至不包括长度和报文边界的描述。同时rtp协议的数据报文和控制报文的使用相邻的不同端口,这样大大提高了协议的灵活性和处理的简单性。
rtp协议和udp二者共同完成运输层协议功能。udp协议只是传输数据包,不管数据包传输的时间顺序。
rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现。rtp协议通常根据一个具体的应用来提供服务,rtp只提供协议框架,开发者可以根据应用的具体要求对协议进行充分的扩展。
2.2
RTP头格式如图2所示:
开始12个八进制出现在每个RTP包中,而CSRC标识列表仅出现在混合器插入时。各段含义如下:
①版本(V)
2位,标识RTP版本。
②填充标识(P)
1位,如设置填充位,在包尾将包含附加填充字,它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字,或为在底层协议数据单元中携带几个RTP包。
③扩展(X)
1位,如设置扩展位,固定头后跟一个头扩展。
④CSRC计数(CC)
4位,CSRC计数包括紧接在固定头后CSRC标识符个数。
⑤标记(M)
1位,标记解释由设置定义,目的在于允许重要事件在包流中标记出来。设置可定义其他标示位,或通过改变位数量来指定没有标记位。
⑥载荷类型(PT)
7位,记录后面资料使用哪种
常用
⑦系列号
16位,系列号随每个RTP数据包而增加1,由接收者用来探测包损失。系列号初值是随机的,使对加密的文本攻击更加困难。
⑧时标
32位,时标反映RTP数据包中第一个八进制数的采样时刻,采样时刻必须从单调、线性增加的时钟导出,以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。
由上图可知,如果只有系列号,并不能完整按照顺序的将data播放出来,因为如果data中间有一段是没有资料的,只有系列号的话会造成错误,需搭配上让它知道在哪个时间将data正确播放出来,如此我们才能播放出正确无误的信息。
⑨SSRC
32位,SSRC段标识同步源。此标识不是随机选择的,目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低,所有RTP实现都必须探测并解决冲突。如源改变源传输地址,也必须选择一个新SSRC标识以避免插入成环行源。
⑩CSRC列表
0到15项,每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源,也仅标识15个。CSRC标识由混合器插入,采用作用源的SSRC标识。
3.实时传输控制协议RTCP(Real-Time Transport Control Protocol)
RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。
3.1 RTCP工作机制
当应用程序开始一个rtp会话时将使用两个端口:一个给rtp,一个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠rtcp提供这些服务。在rtp的会话之间周期的发放一些rtcp包以用来传监听服务质量和交换会话用户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。rtp和rtcp配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息,可以制定流量控制的策略,而会话用户信息的交互,可以制定会话控制的策略。
3.2 RTCP数据报
在RTCP通信控制中,RTCP协议的功能是通过不同的RTCP数据报来实现的,主要有如下几种类型:
①SR:发送端报告,所谓发送端是指发出RTP数据报的应用程序或者终端,发送端同时也可以是接收端。
②RR:接收端报告,所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
③SDES:源描述,主要功能是作为会话成员有关标识信息的载体,如用户名、邮件地址、电话号码等,此外还具有向会话成员传达会话控制信息的功能。
④BYE:通知离开,主要功能是指示某一个或者几个源不再有效,即通知会话中的其他成员自己将退出会话。
⑤APP:由应用程序自己定义,解决了RTCP的扩展性问题,并且为协议的实现者提供了很大的灵活性。
4.资源预订协议RSVP (Resorce
由于音频和视频数据流比传统数据对网络的延时更敏感,要在网络中传输高质量的音频、视频信息,除带宽要求之外,还需其他更多的条件。RSVP是Internet上的资源预订协议,使用RSVP预留部分网络资源(即带宽),能在一定程度上为流媒体的传输提供QoS。
RTP协议分析 第1章. 1.1. RTP全名是Real-time Transport Protocol(实时传输协议)。它是IETF提出的一个标准,对应的RFC文档为RFC3550(RFC1889为其过期版本)。RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议)。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步,但并不保证服务质量,服务质量由RTCP来提供。 1.2. RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。 简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据(RTP),另一个用于控制包(RTCP)。 音频和视频会议。如果在一次会议中同时使用了音频和视频会议,这两种媒体将分别在不同的RTP会话中传送,每一个会话使用不同的传输地址(IP地址+端口)。如果一个用户同时使用了两个会话,则每个会话对应的RTCP包都使用规范化名字CNAME(Canonical Name)。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频,然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。 翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多 播不能直接到达的用户区,例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样,比如有一个与会者通过一条低速链路接入到高速会议,这 时就要使用混合器。在进入音频数据格式需要变化的网络前,混合器将来自一个源或多个源的音频包进行重构,并把重构后的多个音频合并,采用另一种音频编码进 行编码后,再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源(SSRC,见RTP的封装)来识别,可以通过贡献源列表(CSRC表,见RTP的封装)可以确认谈话者。 1.3. 1.3.1. 流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式:下载和流式传输两种方式。 下载情况下,用户需要先下载整个媒体文件到本地,然后才能播放媒体文件。在视频直播等应用场合,由于生成整个媒体文件要等直播结束,也就是用户至少要在直播结束后才能看到直播节目,所以用下载方式不能实现直播。 流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的,所以接收端收到的数据包往往有延迟和乱序(流式传输构建在UDP上)。要实现流式传输,就是要从降低延迟和恢复数据包时序入手。在发送端,为降低延迟,往往对传输数据进行预处理(降低质量和高效压缩)。在接收端为了恢复时序,采用了接收缓冲;而为了实现媒体的流畅播放,则采用了播放缓冲。 使用接收缓冲,可以将接收到的数据包缓存起来,然后根据数据包的封装信息(如包序号和时戳等),将乱序的包重新排序,最后将重新排序了的数据包放入播放缓冲播放。 为什么需要播放缓冲呢?容易想到,由于网络不可能很理想,并且对数据包排序需要处理时耗,我们得到排序好的数据包的时间间隔是不等的。如果不用播放缓冲,那么播放节目会很卡,这叫时延抖动。相反,使用播放缓冲,在开始播放时,花费几十秒钟先将播放缓冲填满(例如PPLIVE),可以有效地消除时延抖动,从而在不太损失实时性的前提下实现流媒体的顺畅播放。 到目前为止,Internet 上面在谈接收缓冲时,说到了流媒体数据包的封装信息(包序号和时戳等),这在后面的RTP封装中会有体现。另外,RealMedia这些流式媒体格式只是编解码有不同,但对于RTP来说,它们都是待封装传输的流媒体数据而没有什么不同。 第2章. 2.1. 2.1.1. RTP(实时传输协议),顾名思义它是用来提供实时传输的,因而可以看成是传输层的一个子层。图 图 从图中可以看出,RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。这些特点,在第4章可以看到。 2.1.2. 不少人也把RTP归为应用层的一部分,这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务,而RTP的实现还是要靠开发者自己。因此从开发的角度来说,RTP的实现和应用层协议的实现没不同,所以可将RTP看成应用层协议。 RTP实现者在发送RTP数据时,需先将数据封装成RTP包,而在接收到RTP数据包,需要将数据从RTP包中提取出来。 2.2. 一个协议的封装是为了满足协议的功能需求的。从前面提出的功能需求,可以推测出RTP封装中应该有同步源和时戳等字段,但更为完整的封装是什么样子呢?请看图2。 图 版本号(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值。该标识符是随机选取的 贡献源列表(CSRC List):0~15项,每项32比特,用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。 2.3. RTP需要RTCP为其服务质量提供保证,因此下面介绍一下RTCP的相关知识。 RTCP的主要功能是:服务质量的监视与反馈、媒体间的同步,以及多播组中成员的标识。在RTP会话期 从图
表 上述五种分组的封装大同小异,下面只讲述SR类型,而其它类型请参考RFC3550。 发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如图3所示。 图 版本(V):同RTP包头域。 填充(P):同RTP包头域。 接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。 包类型(PT):8比特,SR包是200。 长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。 同步源(SSRC):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。 NTP Timestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。 RTP Timestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。 Sender’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。 Sender`s octet 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包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 1) 2) 第3章. 3.1. 实时流协议RTSP(Real-Time Streaming Protocol)是IETF提出的协议,对应的RFC文档为RFC2362。 从图 3.2. 资源预定协议RSVP(Resource Reservation Protocol)是IETF提出的协议,对应的RFC文档为RFC2208。 从图 第4章. 4.1. 可以根据RTP包的序列号来排序。 4.2. 可以根据RTP包的时间戳来获得数据包的时序。 4.3. 根据声音流和图像流的相对时间(即RTP包的时间戳),以及它们的绝对时间(即对应的RTCP包中的RTCP),可以实现声音和图像的同步。 4.4. 如1.3.1所述,接收缓冲用来排序乱序了的数据包;播放缓冲用来消除播放的抖动,实现等时播放。 第5章.
表 表 第6章. [1] [2] [3] RTP传输中的时间戳 为什么要使用RTP 一提到流媒体传输、一谈到什么视频监控、视频会议、语音电话(VOIP),都离不开RTP协议的应用,但当大家都根据经验或者别人的应用而选择RTP协议的时候,你可曾想过,为什么我们要使用RTP来进行流媒体的传输呢?为什么我们一定要用RTP?难道TCP、UDP或者其他的网络协议不能达到我们的要求么? 本文就是根据我在RTP协议的学习和应用过程中整理出来的思考,希望对大家有所启发,同时,也欢迎大家留言探讨,提出自己的想法和思考。 Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of each bit in the media stream. However, they accomplish this with a system of timeouts and retries, which makes them more complex to implement. It also means that when there is data loss on the network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing data. Clients can minimize this effect by buffering data for display. While delay due to buffering is acceptable in video on demand scenarios, users of interactive applications such as video conferencing will experience a loss of fidelity if the delay that buffering contributes to exceeds 200 ms. 像TCP这样的可靠传输协议,通过超时和重传机制来保证传输数据流中的每一个bit的正确性,但这样会使得无论从协议的实现还是传输的过程都变得非常的复杂。而且,当传输过程中有数据丢失的时候,由于对数据丢失的检测(超时检测)和重传,会数据流的传输被迫暂停和延时。 或许你会说,我们可以利用客户端构造一个足够大的缓冲区来保证显示的正常,这种方法对于从网络播放音视频来说是可以接受的,但是对于一些需要实时交互的场合(如视频聊天、视频会议等),如果这种缓冲超过了200ms,将会产生难以接受的实时性体验。 2. RTP协议是一种基于UDP的传输协议,RTP本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。这样,对于那些丢失的数据包,不存在由于超时检测而带来的延时,同时,对于那些丢弃的包,也可以由上层根据其重要性来选择性的重传。比如,对于I帧、P帧、B帧数据,由于其重要性依次降低,故在网络状况不好的情况下,可以考虑在B帧丢失甚至P帧丢失的情况下不进行重传,这样,在客户端方面,虽然可能会有短暂的不清晰画面,但却保证了实时性的体验和要求。 3. 多播在网络视频会议方面有着很广泛的应用,它主要应用于这样一种环境,即: 假 设红色的圆为存放有视频数据的流媒体服务器,其他的圆为连接到该服务器的各个客户端,当所有的绿色的客户端要求同时观看红色服务器上的某一个视频时,如果 服务器为每一路客户端单独建立连接进行数据的传输,这样明显不太合理浪费带宽,因此,多播技术可以很好地解决这种问题,即同一份数据,由服务器发送到公共 的多播地址,各个客户端均监听同一个多播地址来获取数据,这样,既节省了带宽,同时也保证了各个客户端所观看的视频的同步。 这样的多播应用TCP协议是不支持的,而RTP协议在最初就是为了实现类似的视频会议的应用而诞生的,对其有非常好的支持。 4. 首先,我们看看RTP的包头。 V P Payload Type Sequence Number Timestamp SSRC CSRC 从RTP包头的规定中,我们可以非常清晰地看出,在RTP协议中,添加了非常多专为流媒体传输所使用的特性,更加有助于应用于流媒体的传输。 比如用于帧边界标记的M标志位,方便接收端快速定位帧边界;比如负载类型字段,用来告诉接收端(或者播放器)传输的是哪种类型的媒体(例如G.729,H.264,MPEG-4等),这样接收端(或者播放器)就知道数据流是什么格式,然后使用对应的解码器去解码或者播放;比如时间戳字段,标识了数据流的时间戳,接收端可以利用这个时间戳来去除由网络引起的信息包的抖动,并且在接收端为播放提供同步功能,等等。 因此,相比于直接使用TCP或者UDP来进行流媒体传输,这样一个专门为传输音视频而诞生的网络协议更加合适。 5. RTP的profile机制 RTP为具体的应用提供了非常大的灵活性,它将传输协议与具体的应用环境、具体的控制策略分开,传输协议本身只提供完成实时传输的机制,开发者可以根据不同的应用环境,自主选择合适的配置环境、以及合适的控制策略。 这里所说的控制策略指的是你可以根据自己特定的应用需求,来实现特定的一些RTCP控制算法,比如前面提到的丢包的检测算法、丢包的重传策略、一些视频会议应用中的控制方案等等(这些策略我可能将在后续的文章中进行描述)。 对于上面说的合适的配置环境,主要是指RTP的相关配置和负载格式的定义。RTP协议为了广泛地支持各种多媒体格式(如 《RTP Profile for Audio and Video Conferences with Minimal Control》(RFC3551) 《RTP Payload Format for H.264 Video》(RFC3984) 《RTP Payload Format for MPEG-4 Audio/Visual Streams》(RFC3016) 等等,想了解更多可以点击这里:http://en.wikipedia.org/wiki/RTP_audio_video_profile 说明,如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳,而是使用标准的RTP协议,应用程序就更容易与其他的网络应用程序配合运行,这是大家都希望的事情。例如,如果有两个不同的公司都在开发因特网电话软件,他们都把RTP合并到他们的产品中,这样就有希望:使用不同公司电话软件的用户之间能够进行通信。 6. RTP其他的一些良好特性 (1)RTP协议在设计上考虑到安全功能,支持加密数据和身份验证功能。 (2)有较少的首部开销 (3)……(等待补充) 7. 这里有些相关的RTP资源,希望对大家有所帮助。 (1)维基百科对RTP的介绍: (2)维基百科对流媒体的介绍: (3)stackoverflows论坛关于RTP vs TCP的讨论 (4)关于RTP的负载类型和时间戳的讲解 IP/TCP/UDP/RTP/RTCP包结构图 IP 包头结构: TCP UDP RTCP 包头结构: |