RTP协议分析
计算机网络 2009-09-11 19:37:17 阅读1807 评论0字号：大中小订阅一．RTP协议背景
二．RTP协议原理及工作机制
2．1 RTP协议原理
2．1．1 RTP协议原理
2．1．2 RTCP协议原理
2．2 RTP数据包格式
2．2．1 RTP数据包格式
2．2．2 RTCP数据包格式
2．3 RTP工作机制
2．3．1 RTP工作机制
2．3．2 RTCP工作机制
三．RTP协议关键技术指标
3．1 时间戳
3．2时延
3．3 抖动
3．4丢包率
3．5 会话和流两级分用
3．6 多种流同步控制
四．RTP协议应用方案
4．1 RTP协议应用方案之单播
4．2 RTP协议应用方案之广播
4．3 RTP协议应用方案之组播
4．3.1 RTP协议组播方案总体概述
4．3.2 RTP协议组播方案服务器端实现
4．3. 3RTP协议组播方案客户端实现
4．3. 4RTP协议视频帧率和质量调整策略
五．RTP协议移植计划
六．RTP协议安全方面考虑
一．RTP协议背景
流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。
流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)
两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，这样RTP和RTCP就相应的出现了。
实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量,
在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
二．RTP协议原理及工作机制
让我们先看一下RTP和RTCP在网络层次中的位置，以便我们更加清楚的了解该协议，如下图1-1所示：
图1-1 RTP&RTCP网络层次关系图
下面我们就从RTP以及RTCP的协议原理，数据包格式，工作机制三个方面来对该协议做一个基本的认识和了解：
2．1 RTP协议原理
2．1．1 RTP协议原理
RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT 数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输，具体见本文2.2.1RTP数据格式；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务.
2．1．2 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作为一个延伸到所有成员的方便通路,必须要支持具体应用所需的所有控制信息通信.
2．2 RTP数据包格式
2．2．1 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 |
| ....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
以上域具体意义如下：
版本(V):2比特此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中.)
填料(P):1比特若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包.
扩展(X):1比特若设置扩展比特,固定头(仅)后面跟随一个头扩展.
CSRC计数(CC):4比特CSRC计数包含了跟在固定头后面CSRC识别符的数目.
标志(M):1比特标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.
负载类型(PT):7比特此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流.
序列号（sequence number）:16比特每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难.
时间标志（timestamp）:32比特时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量.时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩.
时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的
顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧.
同步源（SSRC）:32比特SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP 会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源.
有贡献源（CSRC）列表:0到15项,每项32比特CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者.
注意：前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表. RTP报文扩展头格式（见RFC3550 Page18）：
0 1 2
3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by
profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header
extension |
| ....
|
若RTP头中的扩展比特位X置1,则一个长度可变的头扩展部分被加到RTP固定头之后,.头扩展包含16比特的长度域,指示扩展项中32比特字的个数,不包括4个字节扩展头(因此零是有效值).RTP固定头之后只允许有一个头扩展.为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前16比特用以识别标识符或参数.这16比特的格式由具体实现的上层协议定义.基本的RTP说明并不定义任何头扩展本身。
2．2．2 RTCP数据包格式
RTCP包括五种数据包类型（RFC3550 Page69）：
abbrev. name value(该值RTCP头格式中的PT类型字段)
SR sender report 200
RR receiver report 201
SDES source description 202
BYE goodbye 203
APP application-defined 204
现在我们就SR报文为例详细描述一下RTCP报文格式（RFC3550 Page35）：
0 1
2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header
|V=2|P| RC | PT=SR=200 | length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant
word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant
word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet
count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first
source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets
lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number
received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival
jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR
(LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR
(DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second
source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ...
:
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific
extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
每个RTCP包的开始部分是与RTP数据包相类似的固定部分,随后是一块结构化单元,它随负载类型不同长度发生变化,但是总以32比特终止.
发射机报告包由3部分组成,若定义,可能跟随第4个面向协议的扩展部分.
第一部分：
8字节长.该域有以下意义:
版本(V):2比特RTP版本识别符,在RTCP包内的意义与RTP包中的相同.此协议中定义的版本号为2.
填料(P):1比特若设置填料比特,该RTCP包在末端包含一些附加填料比特,并不是控制信息的基本部分.填料的最后一个比特统计了多少个字节必须被忽略.某些有固定块大小的加密算法可能需要填料比特.在复合RTCP包中,复合包作为一个整体加密,填料比特只能加在最后一个单包的后面.
接收报告块计数(RC):5比特该包中所含接收报告块的数目.零值有效.
包类型(PT):8比特包含常数200,用以识别这个为RTCP SR包.
长度:16比特以32比特字为单位,该RTCP包的长度减一,包括头和任何填料.(偏移量1保证零值有效,避免了在扫描RTCP包长度时可能发生的无限循环,同时以32比特为单位避免了对以4为倍数的有效性检测.)
SSRC:32比特SR包发起者的同步源标识符.
第二部分：
发射机信息,20比特长,在每个发射机报告包中出现.它概括了从此发射机发出的数据传输情况.此域有以下意义:
NTP时间标志:64比特指示了此报告发送时的壁钟时刻,它可以与从其它接收机返回的接收报告块中的时间标志结合起来,测量到这些接收机的环路时沿.接收机必须期望此时间标志的准确度远低于NTP时间标志的分辨率.测量的不确定度不可知,因此也无需指示.某个发射机,能够跟踪逝去时间但是无法跟踪壁钟时间,可以用加入会议后的逝去时间代替.假定该值小于68年,则最高比特为零.允许用抽样时钟估计逝去壁钟时间.无法用壁钟时间或逝去时间的可以设置此项为零.
RTP时间标志:32比特与以上的NTP时间标志对应同一时刻,但是与数据包中的RTP时间标志具有相同的单位和偏移量.这个一致性可以用来让NTP时间标志已经同步的源间进行媒体内/间同步,还可以让与媒体无关的接收机估计标称RTP时钟频率.注意在大多数情况下此时间标志不等于任何临近的RTP包中的时间标志.然而,通过"RTP时间标志计数器"和"由在抽样点上周期性检测壁钟时间得到的实际时间"两者之间的关系,可以通过相应的NTP时间标志计算得到此RTP时间标志.
发送的报文数:32比特从开始传输到此SR包产生时该发射机发送的RTP数据包总数.若发射机改变SSRC识别符,该计数器重设.
发送的字节文数:32比特从开始传输到此SR包产生时该发射机在RTP数据包发送的字节总数(不包括头和填料).若发射机改变SSRC识别符,该计数器重设.此域可以用来估计平均负载类型数据速率.
第三部分：
零到多个接收报告块,块数等于从上一个报告以来该发射机收听到的其它源的数目.每个接收报告块传输关于从某个同步源来的数据包的接收统计信息.若某个源因冲突而改变其SSRC识别符,接收机并不延续统计数字.这些统计数字是:
SSRC_n(源识别符):32比特在此接收报告块中信息所属源的SSRC识别符.
丢包率:8比特自从前一SR包或RR包发射以来,从SSRC_n传来的RTP数据包的损失比例,以固定点小数的形式表示,小数点在此域的左侧,等于将损失比例乘256后取整数部分.该值定义为损失包数被期望接收的包数除,在下一段中定义.若由于复制而导致包损为负值,损失比例值设为零.注意在收到上一个包后,接收机无法告之以后的包是否丢失,若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此源发送接收报告块.
累计包丢失数:24比特从开始接收到现在,从源SSRC_n发到本源的RTP数据包的丢包总数.该值定义为期望接收的包数减去实际接收的包数,接收的包括复制的或迟到的.由于迟到的包不算作损失,在发生复制时包损可能为负值.期望接收的包数定义为扩展的上一接收序号(随后定义)减去最初接收序号.
接收到的扩展的最高序列号:32比特低16比特包含从源SSRC_n来的最高接收序列号,高16
比特用相应的序列号周期计数器扩展该序列号.注意在同一会议中的不同接收机,若启动时间明显不同,将产生不同的扩展项.
到达间隔抖动:32比特RTP数据包到达时刻统计方差的估计值,以时间标志为单位测量,用无符号整数表达.到达时刻抖动J定义为一对包中接收机相对发射机的时间跨度差值的平均偏差(平滑后的绝对值).如以下等式所示,该值等于两个包相对传输时间的差值,相对传输时间是指包的RTP时间标志和到达时刻接收机时钟,以同一单位的差值.若Si是包i的RTP时间标志,Ri是包i以RTP时间标志单位的到达时刻值,对于两个包i和j,D可以表达为
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算,利用该包和前一包i-1的偏差D(按到达顺序,而非序号顺序),根据公式J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
计算.无论何时发送接收报告,都用当前的J值.
此处描述的抖动计算允许与协议独立的监视器对来自不同实现的报告进行有效的解释.
上一SR报文(LSR):32比特接收到的来自源SSRC_n的最新RTCP发射机报告(SR)的64位NTP时间标志的中间32位.若还没有接收到SR,该域值为零.
自上一SR的时间延时(DLSR):32比特是从收到来自SSRC_n的SR包到发送此接收报告块之间的延时,以1/65536秒为单位.若还未收到来自SSRC_n的SR包,该域值为零.
假设SSRC_r为发出此接收报告块的接收机.源SSRC_n可以通过记录收到此接收报告块的时刻A来计算到SSRC_r的环路传输时延.可以利用最新的SR时间标志(LSR)域计算整个环路时间A-LSR,然后减去此DLSR域得到环路传播时延.
可以用此来近似测量到一族接收机的距离,尽管有些连接可能有非常不对称的时延.
接收机报告包(RR)与发射机报告包基本相同,除了包类型域包含常数201和没有发射机信息的5个字(NTP和RTP时间标志和发射机包和字节计数).余下区域与SR包意义相同.若没有发送和接收据报告,在RTCP复合包头部加入空的RR包(RC=0)。
其它三种报文的格式由于比较简单，不再具体描述；
2．3 RTP工作机制
2．3．1 RTP工作机制
RTP根据应用程序的要求将流媒体数据包封装成RTP数据包并进行发送；它靠上层的调用以及依赖网络层发送来实现；
工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。
2．3．2 RTCP工作机制
RTCP报文不封装音视频数据，而是封装发送端或者接收端的统计报表信息；
在RTP会话期间，每个参与者周期性的向其它参与者发送RTCP控制信息包，如下图1-2所示：
图1-2 RTCP工作示意图
因为网络的情况很不稳定，如果网络情况好我们可以减少语音的延迟时间，也可以增大视频的发送帧率或质量。若网络状况不好我们可以增大语音延迟时间以保证语音连续，也可减少视频的发送帧率或质量，以减少网络的阻塞。
RTCP包的发送率根据与会者的数量来调整.
三．RTP协议关键技术指标
3．1 时间戳
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值，如多个分组属于同一画像。
RTCP中的SR（Sender Report发送端报告）控制分组包含NTP（网络时间，是以1900-1-1零时为起点的系统绝对时间）时间戳和RTP时间戳（封装数据时候打上的时间戳与媒体帧上打上的时间戳不同）可用于同步音视频媒体流。其实现机制如下：
RTP时间戳是依据邻近的RTP数据包中的时间戳结合NTP时间差得到的，用公式表达为：RTP_tsi = tsi + NTPi-NTP'i
其中：
RTP_tsi表示RTCP中的RTP时间戳；tsi表示邻近的RTP包中的时间戳；NTPi表示RTCP 的网络时间戳；NTP'i表示邻近的RTP包对应的网络时间戳；下标表示第i个源。
RTP_tsj=tsj+NTPj—NTP'j 表示第j个源的RTP时间戳；
因此，i和源j之间的相对时差可以表示为：
（RTP_tsi – tsi） -( RTP_tsj - tsj) = (NTPi –NTP'i) - （NTPj—NTP'j）；
由于NTP同步，差值可以反映出两个源的相对时差。因为要同步不同来源的媒体流，必须使得同步他们的绝对时间基准，而NTP时间戳正是这样的绝对时间基准[4]。而对于同一来源的媒体流，应用RTP的时间戳来保证其同步。
3．2时延
影响时延的因素有多个方面：编解码、网络、防抖动缓冲、报文队列等都影响时延，其中有些是固定时延，如编解码网络速率等；有些是变化的，如防抖动缓冲和队列调度等，固定的时延可以通过改变编解码方式和提高网络速率来改变，而变化的时延通常采用提高转发效率来提高；
假设SSRC_r为发出一个接收报告块的接收机.源SSRC_n可以通过记录收到接收报告块的时刻A来计算到SSRC_r的环路传输时延.可以利用最新的SR时间标志(LSR)域计算整个环路时间A-LSR,然后减去此DLSR域得到环路传播时延.
3．3 抖动
在视频电话中，语音、视频数据都是使用UDP协议传送的，但这种协议传输的数据包在网络层不能保证其发送顺序，需要应用层进行排序。在网络的传输中都会有延时，且随着网络负载的变化，延时的长短也不相同，对于语音数据，如果接收方收到后立即播放，很容易造成语音的抖动。
RTP数据包到达时刻统计方差的估计值,以时间标志为单位测量,用无符号整数表达
到达时刻抖动J定义为一对包中接收机相对发射机的时间跨度差值的平均偏差(平滑后的绝对值).如以下等式所示,该值等于两个包相对传输时间的差值,相对传输时间是指包的RTP 时间标志和到达时刻接收机时钟,以同一单位的差值.若Si是包i的RTP时间标志,Ri是包i 以RTP时间标志单位的到达时刻值,对于两个包i和j,D可以表达为
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算,利用该包和前一包i-1的偏差D(按到达顺序,而非序号顺序),根据公式
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
计算.无论何时发送接收报告,都用当前的J值.
为了更好的解决抖动的问题，最好能实现抖动缓存（原理比较简单，在此不做详细描述），一是保证语通道读取数据包的顺序正确，二是控制接收方按照采集的时间顺序播放语音，减少语音的抖动；另外提供QoS和资源预留使语音数据获得优先发送和获得固定的带宽也是解决抖动问题的主要手段。
3．4丢包率
丢包率是通过计算接收包数量和发送包数量的比率得到的，丢包率获得的整个流程是：发送方每间隔一定时间读取每个发送通道的发包数量和数据长度，组成一个此通道的RTCP
报文发送给接收方，同时将发送数据包计数清零；接收方收到RTCP包后，读取接收通道接收到的包数量，并计算出丢包率，通过一个RTCP接收汇报包发送给发送方，同时对接收数据包计数清零。
自从前一SR包或RR包发射以来,从SSRC_n传来的RTP数据包的损失比例,以固定点小数的形式表示,定义为损失包数被期望接收的包数除,在下一段中定义.若由于复制而导致包损为负值,损失比例值设为零.注意在收到上一个包后,接收机无法告之以后的包是否丢失,若在
上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此源发送接收报告块.
3．5 会话和流两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)
和时间戳(Timestamp)对分组进行排序和正确回放。
3．6 多种流同步控制
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp 字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。
四．RTP协议应用方案
4．1 RTP协议应用方案之单播
在客户端与媒体服务器之间建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户端，这种传送方式称为单播。
优点：便于控制和管理；
缺点：每个用户必须分别对媒体服务器发送单独的查询，而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余造成服务器负担沉重，响应需要很长时间.
4．2 RTP协议应用方案之广播
广播指的是用户被动地接收流。在广播过程中，数据包的单独一个拷贝将发送给网络上的
所有用户，客户端接收流，但不能控制流; 广播方式中资料包的单独一个拷贝将发送给网络上的所有用户, 而不管用户是否需要，会非常浪费网络带宽。
优点：简单
缺点：浪费网络带宽
4．3 RTP协议应用方案之组播
组播技术构建的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，媒体
服务器只需要发送一个信息包，所有发出请求的客户端即可同时收到连续数据流而无延时。这就大大减少了网络上传输的信息包的总量, 组播吸收了单播和广播两种发送方式的长处，克服了上述两种发送方式的弱点，将资料包的单独一个拷贝发送给需要的那些客户。组播不会复制资料包的多个拷贝传输到网络上，也不会将资料包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。
优点：减少网络上传输的信息包的总量。网络利用效率大大提高，成本大为下降；
缺点：当不同的用户同时点播同一个节目时，由于点播总有先后顺序，后点播的用户并不是从开始播放，而是依照网络中同时点播此节目的其它用户的播放进度，这就造成当前用户极有可能从节目的中间开始看起,很难做到个性化。
下面我们就组播方案进行详细的分析：
4．3.1 RTP协议组播方案总体概述
组播方案中包括由服务器端、客户端和组播网络载体三部分组成，由于组播网络对于客
户端和服务器来说可以是屏蔽的，因此本文仅对服务器和客户端做详细描述，组播整体方案示意图如下图1-3所示：
图1-3 组播整体方案示意图
如图1-3所示：
RTPSender为服务器端；
RTPReceiver为客户端；
Multicast为组播网络；
流数据包由RTPSender发送，经过Multicast网络，到达RTPReceiver客户端；
4．3.2 RTP协议组播方案服务器端实现
服务器端的算法为：
１、打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程，端口的选择是RTP数据在偶数UDP端口传输，RTCP包在下一个高奇数端口传输；
２、创建一个UDP套接字并将其绑定到所提供服务的地址之上。
３、反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。
服务器端将音视频流封装成RTP数据包通过组播网络发送，如图1-4：
图1-4服务器发送示意图
4．3. 3RTP协议组播方案客户端实现
客户端加入组播群组后，就可以接收音视频流，如图1-5所示：
如图1-5客户端接收示意图
4．3. 4RTP协议视频帧率和质量调整策略
视频帧率和质量的动态调整的目的是在保证语音质量的情况下，不需要用户干预，而尽网络带宽的可能提高视频的帧率和质量；同时，在网络可用带宽下降时，自适应网络的带宽动态调整视频的帧率和质量，尽可能不出现马赛克，不影响音视频的传输。
判断网络带宽一般有两种方法：一是通过丢包率；二是通过RTCP包循环一圈的时间。
丢包率的计算流程见本文3.4丢包率中的描述，但丢包率由于以下原因往往不能正确反映实现带宽的情况：
一是由于UDP包的接收顺序不能保证，接收到的数据包可能多于发送的数据包例如复制数据包，造成计算的丢包率不能正确反映网络带宽；另一个问题是RTCP的数据包可能丢失，如果发送方RTCP发送汇报包丢失，则接收方接收数据包计数不能正确清零，如接收方RTCP 接收汇报包丢失，则发送方不能得到丢包率，因此也不能正确反映网络带宽。
因此一般采用RTCP包循环一圈的时间来判断网络带宽。但是RTCP包循环一圈的时间不能准确反映网络带宽，我们通过一些措施使之尽量准确：一是使用多个RTCP包的循环时间的平均值判断网络带宽，尽量避免网络的抖动情况；二是设置最大循环时间为400ms，解决丢失RTCP包或网络突然发生抖动时对计算循环时间的平均值造成的影响。
视频调整的频率：首先使用一个比较低的帧率和质量的动态调整，然后根据网络带宽的情况逐步调整帧率和质量。一般在开始阶段（如1分钟以内）调整的频繁一些（比如10秒钟调
整一次），这样调整的目的是使视频的质量和帧率尽快的适应带宽；然后保持一个固定的间隔调整一次（比如1分钟），使视频帧率和质量随着网络的变化不断调整。
RTP现在还没有一个标准的视频帧率和质量调整算法，服务器根据自身的情况进行相应的调整，一般来说根据RTCP包循环时间的平均值计算出一个加权值，然后根据这个值所在的区间，并经过一定的处理后，对视频的帧率和质量分别进行相应的调整以满足需要。要得到一个明确的算法，需要我们做相应的测试实验来验证我们的算法；
五．RTP协议移植计划
代码Jrtplib-3.3.0基本上实现了RTP协议的一个封装，我们后续要做的是第一对该代码进行一次全面的验证，以确保该代码的质量；
第二通过做测试实验来得到一个稳定可用的视频帧率和质量调整算法以满足网络实时传输的要求；
计划是先在PC上完成代码和算法的验证，然后再移植到DVR上；
六．RTP协议安全方面考虑
RTP安全方面的考虑: 攻击者可能通过伪造源地址,目的地址,修改报头等方式来攻击RTP,如果RTP是通过组播方式发送,那么发送者无法控制接收者的行为,即无法对接收者进行管理以达到安全上的要求,目前也有一些策略如加密方法来解决安全方面的问题,但还没有完全解决该问题,这里不再详细描述;
RTP协议分析 第1章. RTP概述 1.1. RTP是什么 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用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。 简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（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上）。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进行预处理（降低质量和高效压缩）。在接收端为了恢复时序，采用了接收缓冲；而为了实现媒体的流畅播放，则采用了播放缓冲。
RTP协议全解（H264码流和PS流） 写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析， 其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。 互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。 原创不易，转载请附上链接，谢谢https://www.doczj.com/doc/a49638781.html,/chen495810242/article/details/39207305 1、RTP Header解析 图1 1) V：RTP协议的版本号，占2位，当前协议版本号为2 2) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头
4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数 5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。 7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。 8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理 取一段码流如下： 80 e0 00 1e 00 00 d2 f0 00 00 00 0041 9b 6b 49 €?....??....A?kI e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P. cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|? f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q?? cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ???? 其中，
Southwest university of science and technology 视频信息处理与传输 实验报告 报告名称RTP-RTCP协议 专业班级电子1002班 学生姓名 学号 指导教师
实验四RTP-RTCP协议 一、实验目的 1、了解实时传输协议RTP和实时传输控制协议RTCP的基本原理； 2、学习使用RTP数据报发送实时数据，并接收重组； 3、学会使用Wireshark进行抓包，并分析数据。 二、实验内容 1、RTP协议报文段的说明语句 RTP（Real-time Transport Protocol，实时传输协议）是一个网络传输协议。RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图1所示，其中： 图1 RTP报头格式 V：RTP协议的版本号，占2位，当前协议版本号为2。 P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。 CC：CSRC计数器，占4位，指示CSRC 标识符的个数。 M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM 音频、JPEM图像等。 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 2、RTCP协议报文段的说明语句 RTCP（RTP Control Protocol,控制协议）——监控服务质量并传送正在进行的会话参与者的相关信息。RTCP包括五种数据包类型（RFC3550 Page69）：
即時傳輸協議RTP（Realtime Transport Protocol）：是針對Internet上多媒體資料 流程的一個傳輸協定, 由IETF(Internet工程任務組)作為RFC1889發佈。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間資訊和實現流同步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證即時資料的傳輸，並不能為按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。 即時傳輸控制協議RTCP（Realtime Transport Control Protocol）：負責管理傳輸品 質在當前應用進程之間交換控制資訊。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的資料包的數量、丟失的資料包的數量等統計資料， 因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的回饋和最小的開銷使傳輸效率最佳化，故特 別適合傳送網上的即時資料。 RTCP主要有4個功能: （1）用回饋資訊的方法來提供分配資料的傳送品質，這種回饋可以用來進行流量的擁塞控制，也可以用來監視網路和用來診斷網路中的問題； （2）為RTP源提供一個永久性的CNAME（規範性名字）的傳送層標誌，因為在發現衝突或者程式更新重啟時SSRC(同步源標識)會變，需要一個運作痕跡，在一組相關的會話中接收方也要用CNAME來從一個指定的與會者得到相聯繫的資料流程（如音頻和視頻）； （3）根據與會者的數量來調整RTCP包的發送率； （4）傳送會話控制資訊，如可在用戶介面顯示與會者的標識，這是可選功能。 4.2 RTP/RTCP工作過程 工作時，RTP協議從上層接收流媒體資訊碼流（如H.263），裝配成RTP資料包發送給下層，下層協定提供RTP和RTCP的分流。如在UDP中，RTP使用一個偶 數號埠，則相應的RTCP使用其後的奇數號埠。RTP資料包沒有長度限制，它的 最大包長只受下層協議的限制。 4.3 伺服器的演算法 伺服器軟體模型主要有兩種，即併發伺服器和迴圈伺服器。迴圈伺服器(Iterative
3.1. RTP协议分析 3.1.1. RTP是什么 RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP 来提供。 3.1.2. RTP的协议层次 ——传输层的子层 RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。
3.1.3. RTP协议原理 RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输，具体见本文2.2.1RTP数据格式；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 3.1.3.1. RTP的封装 版本号（V）：2比特，用来标志使用的RTP版本。 填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。 扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩
信令与协议分册目录 目录 第2章RTP与RTCP协议...................................................................................................... 2-1 2.1 概述................................................................................................................................... 2-1 2.2 RTP/RTCP协议应用.......................................................................................................... 2-1 2.3 报文格式和含义................................................................................................................. 2-2 2.3.1 RTP报头的格式 ...................................................................................................... 2-2 2.3.2 RTCP包格式........................................................................................................... 2-3 2.3.3 RTCP的主要功能.................................................................................................... 2-3 2.3.4 RTCP发送间隔 ....................................................................................................... 2-4
实时传输协议RTP 1.RTP协议： RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分 成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在 1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议. RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重 的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。 2．RTP协议的工作原理： 如上所说明的，影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及 其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了 简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层 完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保 证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。 RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。最常用的协议是RTMP(Real Time Messaging Protocol，实时消息传送协议)，RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。还有RTSP,HLS等。 实时传输控制协议RTCP协议 1. RTCP协议： RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。 2. RTCP协议如何工作： 当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利 用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数
RTP协议分析 一．RTP协议背景 (2) 二．RTP协议原理及工作机制 (2) 2．1 RTP协议原理 (3) 2．1．1 RTP协议原理 (3) 2．1．2 RTCP协议原理 (3) 2．2 RTP数据包格式 (4) 2．2．1 RTP数据包格式 (4) 2．2．2 RTCP数据包格式 (6) 2．3 RTP工作机制 (9) 2．3．1 RTP工作机制 (9) 2．3．2 RTCP工作机制 (9) 三．RTP协议关键技术指标 (10) 3．1 时间戳 (10) 3．2时延 (10) 3．3 抖动 (11) 3．4丢包率 (11) 3．5 会话和流两级分用 (11) 3．6 多种流同步控制 (12) 四．RTP协议应用方案 (12) 4．1 RTP协议应用方案之单播 (12) 4．2 RTP协议应用方案之广播 (12) 4．3 RTP协议应用方案之组播 (13) 4．3.1 RTP协议组播方案总体概述 (13) 4．3.2 RTP协议组播方案服务器端实现 (14) 4．3. 3RTP协议组播方案客户端实现 (14) 4．3. 4RTP协议视频帧率和质量调整策略 (15) 五．RTP协议移植计划 (16) 六．RTP协议安全方面考虑 (16)
一．RTP协议背景 流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。 流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，这样RTP和RTCP就相应的出现了。 实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量,在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。 二．RTP协议原理及工作机制 让我们先看一下RTP和RTCP在网络层次中的位置，以便我们更加清楚的了解该协议，如下图1-1所示：
RFC3550 RTP：实时应用程序传输协议 摘要 本文描述RTP（real-time transport protocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。 本文的大多数内容和旧版的RFC1889相同。在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。 目录（Table of Contents） 1. 引言（Introduction） 1 1 术语（Terminology） 2 RTP使用场景（RTP Use Scenarios） 2 1 简单多播音频会议（Simple Multicast Audio Conference） 2 2 音频和视频会议（Audio and Video Conference） 2 3 混频器和转换器（Mixers and Translators） 2 4 分层编码（Layered Encodings） 3 定义（Definitions） 4 字节序，校正和时间格式（Byte Order, Alignment, and Time Format） 5 RTP数据传输协议（RTP Data Transfer Protocol） 5 1 RTP固定头域（RTP Fixed Header Fields） 5 2 多路复用RTP会话（Multiplexing RTP Sessions） 5 3 RTP头的配置文件详细变更（Profile-Specific Modifications to the RTP Header） 5 3 1 RTP报头扩展（RTP Header Extension） 6 RTP控制协议（RTP Control Protocol）-- RTCP 6 1 RTCP包格式（RTCP Packet Format） 6 2 RTCP传输间隔（RTCP Transmission Interval） 6 2 1 维护会话成员数目（Maintaining the number of session members） 6 3 RTCP包的发送与接收规则（RTCP Packet Send and Receive Rules） 6 3 1 计算RTCP传输间隔（Computing the RTCP Transmission Interval） 6 3 2 初始化（Initialization） 6 3 3 接收RTP或RTCP（非BYE)包（Receiving an RTP or Non-BYE RTCP Packet） 6 3 4 接收RTCP（BYE）包（Receiving an RTCP BYE Packet） 6 3 5 SSRC计时失效（Timing Out an SSRC）
RTSPRTP 媒体传输和控制协议 1 前言 本文档主要描述了NewStream Vision 系统中前端视频服务器(DVR, 网络摄像机), 中心转发服务器以及客户端之间的多媒体通信以及控制协议. 本协议主要基于标准的IETE 的RTSP/RTP 以及相关协议, 并针对具体应用定义了部分扩展. 本协议只是当前实现的总结和整理, 具体的协议细节以实际实现为准 2 定义 RTSP实现流协议SDP会话描述协议RTP实时传输协议 H.264H.264 视频编码标准 3 RTSP 命令 3.1 Request 语法 语法: RTSP 的语法和HTTP 的语法基本相同, 具体如下。COMMAND rtsp_URL RTSP/1.0<CRLF> Headerfield1: val1<CRLF> Headerfield2: val2<CRLF> ... <CRLF>
[Body] RTSP 消息行之间用回车换行(CRLF) 分隔. 一个空行表示消息头部分的结束。 3.1.1 RTSP 方法 COMMAND 表示RTSP 命令名称, 是DESCRIBE, SETUP, OPTIONS, PLAY, PAUSE, TEARDOWN 或 SET_PARAMETER 等的任意一个. 3.1.2 RTSP URL 完整语法如下: rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ] host = (A legal Internet host domain name of IP address (in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}) port = *DIGIT 如: rtsp://<servername>/live.mp4[?<param>=<valu e>[&<param>=<value>...]]
H.264视频在android手机端的解码与播放 文／南京邮电大学张永芹龚建荣摘要：本文实现了手机终端通过移动无线网络与媒体服务器进行通信，并就开发过程中的几个技术难点的解决方法进行了说明。首先详细分析说明了rtp 打包，解包的流程，这是视频传输的基础；然后在RTP传输过程中，针对发送数据快而处理速度慢的问题，采用多线程并发机制予以解决；面对大量，而且不稳定的数据包，本文针对各个环节自己的特点，设计了多级缓冲处理机制，使得视频播放更加流畅、平稳。接着，对于分析和解码的先后次序的问题，则采用线程协作的思想，利用消费者，生产者模式，保证了视频数据的时序性。最后对于视频解码部分，则利用现有解码方法进行平台移植，深度简化代码，合理处理c 层和java层的分工。最后实践证明，采用本文提供的方法，视频传输、播放成功，而且android手机端视频播放延时短，流畅，平稳。 关键词：H.264 RTP 多级缓冲线程协作 android 随着无线网络和智能手机的发展，智能手机与人们日常生活联系越来越紧密，娱乐、商务应用、金融应用、交通出行各种功能的软件大批涌现，使得人们的生活丰富多彩、快捷便利，也让它成为人们生活中不可取代的一部分。其中，多媒体由于其直观性和实时性，应用范围越来越广，视频的解码与播放也就成为研究的热点。 H.264标准技术日渐成熟，采用了统一的VLC符号编码，高精度、多模式的位移估计，基于4×4块的整数变换、分层的编码语法等。这些措施使得H.264算法具有很高的编码效率，在相同的重建图像质量下，能够比H.263节约50％左右的码率。而且H.264的码流结构网络适应性强，增加了差错恢复能力。正好适用于带宽受限，差错率高的无线网络。 本文结合ffmpeg开源代码中的解码方法，采用多线程接收数据包，多级缓冲数据，接收和解码并行双线程操作等方法，缓解了由于传输的数据量大、速度快而导致的数据堵塞、解码出错、视频画面迟钝、延迟等问题。使得h.264视频的传输速度快，稳定性好。最终实现了pc端到android手机端的视频传输，以及在android手机端的解码播放。 该技术可以应用于视频会议、视频监控等应用中。 一、 H.264视频传输播放系统的总体结构 H.264视频传输播放系统分为服务器端和客户端2个部分，服务器端负责读取H.264的视频数据，并且以RTP/RTCP格式打包发送给客户端，并且接受客户端的反馈，对传输速度等作相应的控制。Android手机客户端主要完成从服务器端接收实时码流数据，经过缓冲，进行视频数据解析，然后送去解码，最后在手机上显示播放。服务器端采用c语言实现，客户端主要用java语言实现。 二、关键技术及其实现 1.基于RTP协议的打包及解包 （1）单个NAL打包 H.264NALU单元常由[start code][NALU header][NALU payload]三部分组成，其中start code 用于标志一个NALU单元的开始，必须是“00000001”或者是“000001”，打包时去掉开始码，把其他数据打包到RTP包就可以了。（2）分片打包 由于1500个字节是IP数据报的长度的上限，去除20个字节的数据报首部，1480字节是用来存放UDP数据报的。所以当一帧中的字节数超过这个数值时，
资源下载： https://www.doczj.com/doc/a49638781.html,/source/444512 实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP(实时传输）和RTCP（实时控制）之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。 实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。 RTSP是应用级的协议，完成多媒体服务器的远程控制，控制信息的传输可以使用TCP，控制指令包括如：Setup、Play、Record、Pause、Teardwon等等。 对于流媒体应用，用户和服务器都可以发出请求，请求包括几种连接方法：持久、每个请求/响应传输一个连接、无连接。 常见的URL流媒体地址如： rtsp://https://www.doczj.com/doc/a49638781.html,:554 RTP 数据报组成：Header + Payload RTCP：应用程序启动RTP会话时将同时占用两个端口，供RTP和RTCP使用。 如果有必要，RTP使用时可以有两个伴随文档：1）配置文档，定义负载的编码类型和格式。2）负载格式的规范文档。 在流传输过程中，有两类服务完成对流的转发处理： 1）译流服务器Translator，进入的流在流出时发生变化，作用之一是更好地穿越防火墙。 2）混流服务器Mixer，多个流进入，合并后变成一个流流出。 由于进入的流可能有多个源，比如视频会议，会有多个话筒和视频头等等情况，对于RTP来说，就有一个同步化源的问题，因此，RTP协议中用SSRC（Synchronization Source）字段来供Mixer实现同步功能。 Translator的一个作用是多播变成多个单播。 为了提供播放和回放功能，RTP提供时间标签+序列号，在流动的概念中，时间标签是最重要的信息。 RTP报文不提供长度和报文边界的描述。 RTP虽然是传输层协议，但没有在OSI体系中作为单独的层来使用。 RTP是目前解决流媒体实时传输问题的最好办法，如果要开发，可以选择JRTPLIB库。JRTPLIB是一个面向对象的RTP库，它完全遵循RFC 1889设计。JRTPLIB是一个用C++语言实现的RTP库，目前已经可以运行在Windows、Linux、FreeBSD、Solaris、Unix和VxWorks等多种操作系统上。 了解更多RTP参考： https://www.doczj.com/doc/a49638781.html,/zouzheng/archive/2008/01/04/38449.html 下面的例子参考jrtplib的example1,加了解析负载的部分。 // RTPClient.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "rtpsession.h"
16.6.1 RTP简介 RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的是为了使用UDP的端口号和检查和。如图16-12所示，RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，然后再封装在IP数据包中。 1889中。信息包的结构包含广泛用于多媒体的若干个域，包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准，它可以被用来传输普通格式的文件。例如，WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视，也可以用来传输专有格式存储的声音和电视文件。 TCP/IP模型 应用层(application) 传输层 RTP UDP IP 数据链路层(data link) 物理层(physical) 图16-12 RTP是传输层上的协议 从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP 信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)，如图16-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。 TCP/IP模型 应用层(application) RTP 套接接口 UDP
HUAWEI MSOFTX3000 移动软交换中心技术手册 信令与协议分册目录 目录 第2章RTP与RTCP协议...................................................................................................... 2-1 2.1 概述................................................................................................................................... 2-1 2.2 RTP/RTCP协议应用.......................................................................................................... 2-1 2.3 报文格式和含义................................................................................................................. 2-2 2.3.1 RTP报头的格式 ...................................................................................................... 2-2 2.3.2 RTCP包格式........................................................................................................... 2-3 2.3.3 RTCP的主要功能.................................................................................................... 2-3 2.3.4 RTCP发送间隔 ....................................................................................................... 2-4 i
RTP 参考文档 RFC3550/RFC3551 Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成： RTP ―传送具有实时属性的数据；RTP 控制协议（RTCP）―监控服务质量并传送正在进行的会话参与者的相关信息。 RTCP 实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP 所提供的服务质量（Quality of Service）提供反馈。 RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。 SRTP & SRTCP 参考文档 RFC3711 安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3 月作为RFC3711发布。
RTP协议分析 计算机网络 2009-09-11 19:37:17 阅读1807 评论0字号：大中小订阅一．RTP协议背景 二．RTP协议原理及工作机制 2．1 RTP协议原理 2．1．1 RTP协议原理 2．1．2 RTCP协议原理 2．2 RTP数据包格式 2．2．1 RTP数据包格式 2．2．2 RTCP数据包格式 2．3 RTP工作机制 2．3．1 RTP工作机制 2．3．2 RTCP工作机制 三．RTP协议关键技术指标 3．1 时间戳 3．2时延 3．3 抖动 3．4丢包率 3．5 会话和流两级分用 3．6 多种流同步控制 四．RTP协议应用方案 4．1 RTP协议应用方案之单播 4．2 RTP协议应用方案之广播 4．3 RTP协议应用方案之组播 4．3.1 RTP协议组播方案总体概述 4．3.2 RTP协议组播方案服务器端实现 4．3. 3RTP协议组播方案客户端实现
4．3. 4RTP协议视频帧率和质量调整策略 五．RTP协议移植计划 六．RTP协议安全方面考虑 一．RTP协议背景 流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。 流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming) 两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，这样RTP和RTCP就相应的出现了。 实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量, 在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。 二．RTP协议原理及工作机制 让我们先看一下RTP和RTCP在网络层次中的位置，以便我们更加清楚的了解该协议，如下图1-1所示： 图1-1 RTP&RTCP网络层次关系图 下面我们就从RTP以及RTCP的协议原理，数据包格式，工作机制三个方面来对该协议做一个基本的认识和了解：