100029825Π2001Π12(07)1042208○c2001Journal of Software 软件学报Vol.12,No.7基于实时传输协议的丢包实时修复Ξ
张 钶, 谢忠诚, 鞠九滨
(吉林大学计算机科学系,吉林长春 130023)
E2mail:jjb@http://biz.doczj.com/doc/9f3481205.html,
http:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,
摘要:在诸如IP电话和远程会议系统等实时应用中,使用实时传输协议R TP(real2time transport protocol)在因特网上传输的数据包不可避免地会丢失,极大地影响了传输服务质量.在R TP上增加丢包修复功能可以解决这个问题.介绍了在R TP上采用FEC(forward error correction)修复丢包的方法,基于这个方法设计并实现了一个支持丢包修复功能的R TP库,说明了丢包修复功能的测试方法和结果.
关键词:R TP(real2time transport protocol);丢包;修复;FEC(forward error correction)
中图法分类号:TP393 文献标识码:A
话音包与数据包在因特网上传输时可能有较大的延迟和丢包概率.丢包将严重地影响IP电话的话音质量[1],因此采取丢包修复方法是很有必要的.造成媒体包丢失的原因有这样几个:路由器和网关发生拥塞,某些包可能被丢弃;包传输过程中的延迟过大,因到达接收端太晚而无法回放;在多任务操作系统中,工作站超载运行时可能因调度困难而不能及时处理传输.
目前有4种常见的丢包修复方法[2].重发法是修复TCP丢包常用的方法,但语音数据对时延敏感,只有当重发延迟满足实时应用的要求时,重发法才是适用的[3].冗余法(媒体相关的F EC (forward error correction)法)[1]是把第n个数据包的副本重新用更低位码率的压缩算法,如GSM (global system mobile)语音压缩,附加到第n+1个数据包中一起发送,如果第n个包丢失了,可以从第n+1个包中所附带的副本来恢复;如果附带多个副本,还可以修复连续丢包.这种方法需要额外的CPU及带宽开销,并且只有大致的修复能力.媒体无关的F EC[2]法有精确的修复能力,发送端对连续多个数据包作异或运算求出F EC数据包,并以奇偶包的形式发送,丢失的数据包可以用接收到的数据包和F EC包作异或运算再生出来.此方法的缺点是与冗余法相比有较大的延迟(缓存多个包以作F EC运算),增加了带宽需求.交叠法[2]和差错分散法(error sp read)[4]降低或分散了丢包的影响,它们的优点是不增加带宽需求,但在传输两端中增加缓冲延迟开销.几类修复方法的性能对比见表1.由此可见,媒体无关F EC法和冗余法适合实时传输应用.
对丢包现象的大量研究发现,丢失单包的概率最大,因此丢包修复主要解决丢失单包的修复问题.
IP电话和远程会议系统,从早期的Vat,NeVo T,到后来基于H.323[5]协议的Net Meeting和IP电话,都把实时传输协议R TP(real2time t ransport p rotocol)[6]作为传送实时媒体的工具.R TP
Ξ收稿日期:1999212223;修改日期:2000203223
基金项目:高等学校博士学科点专项科研基金资助项目(1999018319)
作者简介:张钶(1971-),男,山东泰安人,博士,主要研究领域为计算机网络,分布式系统;谢忠诚(1972-),男,辽宁阜新人,硕士,主要研究领域为计算机网络,分布式系统;鞠九滨(1935-),男,黑龙江哈尔滨人,教授,博士生导师,主要研究领域为计算机网络,分布式系统.
已经成为实时媒体传输的通用标准,被H.323系列标准定义在H.225.0[7]的附录中.R TP 还包括一个实时控制协议R TCP (R TP cont rol protocol ),用于进行松散的对话控制,提供服务质量QoS (qualit y of service )报告和支持媒体同步等.
T able 1 Overheads of different lost repair schemes
表1 不同修复策略开销的对比
Delay ①
Bandwidt h overhead ②Processing overhead ③Retransmission ④
Medium ⑤Variable ⑥High ⑦Interleaving ⑧
High None ⑨Low λυMedia 2Independent F EC λ
?High High Low Redundancy λωSmall λξVariable Variable ,may be large λ
ψ①延迟,②带宽开销,③处理开销,④重发法,⑤中,⑥变化,⑦高,⑧交叠法,
⑨不变, λυ低, λ?媒体无关F
EC 法, λω冗余法, λξ小, λψ变化,可能很大.
实时媒体传输中的丢包检测和修复需要R TP 的支持,例如通过包序列号监测丢包,把R TP 的传输实时媒体的功能和丢包修复能力结合在一起,将是实时媒体传输中解决丢包问题的一个较好的方法.实现R TP 协议以及基于该协议的工具最早有R TP Tools [8]和R TPmon [9]
,用于处理
R TP 数据包和监控R TCP 报告.R TP Library [10]提供了基本的R TP 协议功能.但支持丢包修复的
R TP 工具还处于研究阶段,目前还未见报道.
本文介绍了我们设计和实现的一个具有丢包修复功能的R TP 库.它采用与媒体无关的F EC 法实时修复所有丢失的单包和部分丢失的多包.同时,并在我们设计和实现的测试平台上验证了这项功能.1 实时传输协议(RTP)
为了说明在R TP 上利用F EC 法对丢失的包进行修复的原理,有必要先来介绍R TP 的有关细节.
R TP 传送音频和视频等连续的媒体数据.R TP 数据包由一个12字节的包头(如图1所示)和传送的净载数据组成.在包头中:净载类型域标识出R TP 净载数据格式,以便接收端确定相应的处理程序;时间戳反映出在R TP 数据包的净载中第1个字节的采样时刻,该域使媒体数据在接收方能够按时间序列重新组装;序列号代表发送方发出的包序列,它可以使接收者监测丢包和重建包序列;指示器位使一些重大的事件(如对音频数据标识出一个“交谈迸发”的开始)能在数据包流中被突出地标记出来;同步源标识符用于唯一地标识出R TP 对话中的一个同步源.
R TCP 包定期地在与数据包相同的多点传送组中传送,即使在没有媒体数据传送的情况下,它们也可以作为对话成员的活跃指示器.R TCP 的下述功能与本文的工作直接有关:
3401张钶等:基于实时传输协议的丢包实时修复
4401Jou rnal of S of t w are 软件学报 2001,12(7)
(1)QoS监控和拥挤控制.R TP对话参与者使用发送报告SR(sender report)和接收报告RR (receiver report)提供接收质量反馈,使所有的对话成员都能够大致了解其他参与者的进展情况.
(2)媒体同步.R TCP发送报告中包含了实际时间和相应的R TP时间戳的指示器.这两个值允许不同媒体,如音频和视频之间实现“唇同步”.
(3)标识.R TCP的SD ES包中为每一个对话成员提供一个全局唯一的标识符,称为教名或CNAM E.SD ES的其他项提供发送者的其他描述信息,如姓名、电子邮件地址、地理位置等.
(4)会话大小的估计和规划.每个对话成员定期发送R TCP包,当对话包含数百个与会者时,必须限制控制流量只占对话带宽的一小部分,通常建议分配给R TCP的带宽占总对话带宽的5%.
发送者可以基于该反馈修改它的传输策略,接收者可以确定出现的问题是局部的还是全局的,网络管理员也可以使用只接收R TCP包的监控器来评价它的网络性能.SR包含媒体同步所需的信息以及累计发送包数和字节数,这样,接收者可以估计出实际的数据流量.RR包括接收到的最大序列号、丢包数、平均延迟抖动和用于计算往复延迟的时间戳.通常情况下,R TP在UDP协议上运行,但这是以不能保证数据完整性为代价的.
2 用媒体无关前向误差校正法(FEC)修复丢包
2.1 校验编码
定义f(x,y,...)是应用在数据块x,y,...的按位异或操作.假定每个数据块是长度为L的一组简单比特流,则函数对所有数据块做异或运算后输出长度为L的校验块,特别地,f(x)=x.校验块一般由一组线性无关的数据块的组合来产生,这种组合称为校验编码.修复数据的方法一般是对k个媒体数据块产生1个或多个校验块,共有n个数据块和n-k个校验块,接收方只要接收到其中任意k个块就可以再生出原来的k个媒体数据包.对于给定的n和k,有以下多种检验编码(左面的字母代表输入的数据块流,右面的字母代表数据块和校验块流):
方式0.不能修复丢包,定义为a,b,c,d,...→a,b,c,d,...
方式1.能修复单个丢包,如果b和f(a,b)交换位置,允许连续丢失两包(媒体+F EC包)的修复.定义为a,b,c,d,e,f→a,f(a,b),b,f(b,c),c,f(c,d),d,...
方式2.修复所有单包丢失和若干连续丢失的包,但它比方式1的代价要小:a,b,c,d,e,f,g →f(a,b),f(a,c),f(a,b,c),f(c,d),f(c,e),f(c,d,e),...
方式3.能修复连续丢失的1、2、3个包,但需要4个包的延迟:a,b,c,d,e,f→f(a),f(b), f(a,b,c),f(c),f(a,c,d),f(a,b,d),f(d),...
2.2 实现媒体无关FEC的RTP净载格式
校验块要在单独的F EC包中传送.图2是一种封装在R TP数据包中实现媒体无关F EC的净载格式[11].F EC包由在R TP净载部分的一个F EC包头和F EC净载组成.该格式可以传送任意长度和校验方式的数据块,可以对R TP净载和重要的R TP包头域如长度、净载类型等进行修复.校验包头(如图3所示)有96比特,其中定义了一个24比特的偏移屏蔽码域.如果第i个比特被置位1,则表明序列号为N+i的媒体包和本F EC包相关联,其中N是F EC包头中的序列号基域.
F EC包头中的其他域有:
?长度修复域:决定修复后的媒体包的长度.例如,当两个长度为3(0b011)和5(0b101)个字的
媒体包进行异或操作形成F EC 包,那么长度修复域应当置为0b011xor 0b101=0b110.
?净载类型修复域:同本F EC 包相关联的媒体包的净载类型值应用保护操作过程得到.
?序列号基域:本F EC 包保护的那些媒体包中最小的序列号值.
?时间戳修复域:同本F EC 包相关联的媒体包的时间戳值应用保护操作过程得到.
?E 位:用来指示F EC 头部扩展.
F EC 包的净载部分是对本F EC 包相关联的媒体包的CSRC 列表、净载、填充部分和扩展部分应用保护操作得到的.所谓保护操作,是为了修复丢包发送端对媒体包执行的一种操作,其过程如下:第1步,从不同的媒体包头中取得各种域值、净载和填充部分(如果存在)附加在一起形成一个二进制数据块,如果这些数据块的长度不等,用0填充至与最长的数据块等长;第2步,对这些数据块做校验运算得出F EC 数据块;最后把F EC 结果数据放入F EC 包中.其具体操作是把F EC 数据块的第1个比特写入F EC 包的填充标志位,把第2个比特写入F EC 包的扩展标志位,将下面4个比特写入F EC 包的CC 域,再将下面1个比特写进F EC 包的指示器位,将下面7个比特写入F EC 包头的净载类型修复域,然后将下面32个比特写入F EC 包头的时间戳修复域,将下面16个比特写进F EC 包的长度修复域,剩下的比特都作为F EC 包的净载.
2.3 丢包修复
接收端检测到丢包后要启动修复过程,重建丢失的媒体包.修复过程分两部分:第1步根据实现者选择的算法,确定为修复丢失的媒体包必须具有哪些包(媒体包和F EC 包);第2步重建丢失数据.假设T 是修复媒体包X i 所需的媒体包和F EC 包列表.丢包重建过程如下:(1)对T 中媒体包和F EC 包执行保护操作的步骤1;(2)对所有的二进制数组执行异或操作,产生修复数组;(3)产生一个新的具有12字节长标准R TP 包头的无净载R TP 包;(4)修复数组中的比特值依次填入新包中的相应域(第1个比特填充到标志位,第2个比特填充到扩展标志位,接下来的4个比特填充到CC 域,...);(5)新包序列号设置为X i 的序列号;(6)把新包的SSRC 值设置为其保护的媒体流的SSRC.以上过程将完全修复一个R TP 数据包的包头和净载.
5401张钶等:基于实时传输协议的丢包实时修复
3 支持丢包修复功能的RTP 库
H.225.0中对R TP 的原始定义做了少量修改,
使用中一般遵从H.225.0中的规定而不是它的原始定义.参考上述二者的定义,我们开发了一个通用的R TP 库.这个库在提供R TP 基本功能的基础上支持基于媒体无关F EC 功能的丢包修复机制.
3.1 RTP 的实现
在一个R TP 对话中,以相应的对话结构为中心实现对R TP 数据流和R TCP 控制流的产生和解析.“对话结构(见下文中R TPSession Info 的结构)”记录了对话中的重要信息,在对话进行过程中,结构中的许多信息不断被动态地更新,程序也根据各种信息的变化而采取相应的措施.对话的处理流程如图4所示.在新建对话过程中,调用者指定对话所需的基本元素(如净载类型、采样信息、CNAM E 等),并得到一个对应本对话结构的对话句柄.此后,调用者可以根据应用的需要使用R TP ΠR TCP 过程生成和解析媒体及控制包.在执行过程中,程序内部会通过调用者提供的对话句柄自动更新相应对话结构中的时间戳、序列号等信息,并且整理发送总包数、总净载字节数等统计数字.对话终止后,调用者必须关闭对话过程,释放对话所占用的句柄、内存等资源,保证程序的正常运行.R TP 协议库程序由Session 模块、R TP 模块和R TCP 模块这3部分组成(如图5所示).Session 模块的功能是建立、管理、更新R TP 对话、信息获取和关闭R TP 对话.R TP 模块执行R TP 数据包和F EC 包的打包、拆包、丢包检测与修复等工作.R TCP 模块的功能是R TCP 包的打包和解析、获取各种统计信息.协议库运行在UDP 协议上,数据包和R TCP 包使用两个连续的端口,数据端口使用较低的偶数端口.在协议实现中遇到的一些问题,如SSRC 冲突处理、随机数产生方法、指示器位定义、CNAM E 确定等,均可参考协议的规定来解决.R TP 数据包中不包含长度域.由UDP 包提供包长度标识.
struct R TPSession Info
{
unsigned int SSRC ;
ΠΠ本地参与者的SSRC unsigned char CName[STR IN G L EN GTH ];
ΠΠCNAM E unsigned int Timestamp ;
ΠΠ时间戳unsigned short SequenceNumber ;
ΠΠ序列号unsigned short FECSequenceNumber ;
ΠΠFEC 序列号unsigned char Payload Type ;
ΠΠ净载类型short SampleRate ;
ΠΠ采样率...
unsigned char FECPayload Type ;
ΠΠFEC 净载类型unsigned short R TPVersion ;
ΠΠR TP 版本号unsigned char RealName[STR IN G L EN GTH ];
ΠΠ真实姓名unsigned char EMail[STR IN G L EN GTH ];ΠΠ电子邮件地址
6401Jou rnal of S of t w are 软件学报 2001,12(7)
...
unsigned short ParticipantNum ;ΠΠ与会者数
struct R TPEndpoint StatsEx 3ParticipantList ; ΠΠ与会者信息列表
unsigned int PacketsSent ;ΠΠ本用户发送的总包数
unsigned int OctetsSent ;ΠΠ本用户曾发送的总净载字节数
...
BU FFER R TPPacketBuffer ;ΠΠ将要发送的R TP 媒体包缓冲区
BU FFER R TPFECBuffer ;ΠΠ将要发送的R TP FEC 包缓冲区
BU FFER R TCPPacketBuffer ;ΠΠ将要发送的R TCP 包缓冲区
struct ParsedR TPPacket 3ParsedR TP ;ΠΠ解析后的R TP 包
...
}3.2 丢包修复机制的实现
协议库中选择第2节中的方式1作为丢包修复的校验编码,使用图2中的净载格式传输F EC 校验数据.方式1对于所有单包丢失及某些连续两包丢失的情况均可修复,而且计算复杂度低、延迟小.它唯一的缺点是需要增加1倍的带宽,但与其他方式相比,其性能价格比是比较好的.在R TP 数据包的打包过程中采用上述校验编码和保护操作过程生成F EC 包,每两个序列号连续的媒体包就有一个与之相关联的F EC 包.接收方把所有接收到的F EC 包都放到相应参与者的一个F EC 队列中.由R TP 媒体包的拆包过程维护该队列.当拆包过程发现当前收到的数据包的序列号同上一次收到的数据包的序列号之间的差值大于1时,则可断定发生了丢包现象.然后,启动丢包修复操作:
(1)如果本参与者保存了前一个到来的媒体包,则转步骤(4);
(2)新到的或新修复的包与上一次收到的包的序列号之差如果不大于1,则转步骤(8);
(3)利用F EC 队列和该媒体包修复丢包.如果成功修复,则转步骤(2),否则转步骤(8);
(4)新到的或新修复的包与上一次缓存的包的序列号之差如果不大于1,则转步骤(6);
(5)利用F EC 队列和该媒体包修复丢包.如果修复成功,则转步骤(4),否则转步骤(6);
(6)缓存的或新修复的包与上面刚修复的最小序列号之差如果不大于1,则转步骤(8);
(7)利用F EC 队列和该媒体包修复丢包.如果修复成功,则转步骤(6),否则转步骤(8);
(8)将新到的媒体包缓存,并从F EC 队列中将无用的F EC 包清理掉;
(9)结束.
经修复操作后,已丢失的媒体包被尽可能多地恢复出来.在有些情况下,这种方法还能修复多个连续丢失的媒体包.F EC 包在紧接R TCP 的下一个端口中作为独立的媒体流传输,它们具有自己的序列号空间,但时间戳仍来源于媒体包.传输F EC 格式的R TP 数据包采用动态净载类型标识,没有实现F EC 方式的接收者可以忽略接收到的F EC 包,从而实现后兼容性.4 功能测试
为了测试协议库的功能,我们设计了一个协议测试系统.通过界面可以设置本地和远端的主机名和R TP ΠR TCP 口号,从而建立一个R TP 对话;指定丢包率,使得测试平台按给定的比率丢弃数据包;手动使能或禁用F EC 丢包修复机制;关闭指定的R TP 对话.协议库测试的主要内容是R TP 数据包和R TCP 控制包的收Π发功能、F EC 法丢包修复功能.
采用一种定量的测试策略.发送端发送的数据文件格式如下:
7
401张钶等:基于实时传输协议的丢包实时修复
8401Jou rnal of S of t w are 软件学报 2001,12(7)
1 1 1 1
...
4000400040004000
每一行的内容由发送端的一个媒体包发送,接收端将每个R TP对话接收到的R TPΠR TCP数据分别存储到两个文件中,从收到的数据序列来观察丢包和丢包修复的效果.
在测试R TPΠR TCP包的收发时,先在局部网络连接的两台PC机A和B上分别运行测试系统.建立连接后,定时发送R TP数据包和R TCP控制包.对话关闭后,观察该对话接收到的R TP 数据序列和R TCP报告信息.可以发现,接收到的R TP数据序列段是连续的,没有丢包;从R TCP 报告包也可以看到积聚丢包数为0,这就证明实现的R TP的正确性.
在测试F EC丢包修复功能时先按无丢包修复方式,按一定的丢包(包括R TP媒体包和F EC 冗余包)率发送数据;之后运行一段时间,并启动丢包修复方式;在对话结束后查看收到的R TPΠR TCP数据.从相应的数据文件可见,在丢包比率是30%的情况下,R TP数据文件中的前半部分数据序列有许多跳跃间隔,表示发生了丢包现象,对应的R TCP报告也显示积聚丢包比率大约是30%.在R TP数据文件的后半部分基本没有跳跃间隔,证明F EC方式的修复能力.多次测试选择不同的丢包率(见表2)均可得到同样的结论.
T able2 Results of lost repair testing(%)
表2 修复功能测试结果(%) Test sequence①Lost rate selected②Lost rate after repairing③
130<3
220<1
310<0
①测试序列,②选择丢包率,③修复后的丢包率.
协议库目前只实现了一种校验编码方式,还没有使用一些适合在较低带宽情况下采用的校验编码.今后工作中要进一步拓展协议库的灵活性,使它能根据网络当前的性能动态地改变校验编码方式,以适应应用环境的变化.
References:
[1] Hardman,V.,Sasse,M.A.,Handley,M.,et al.Reliable audio for use over t he Internet.1995.http:ΠΠwww2mice.cs.
http://biz.doczj.com/doc/9f3481205.html,ΠmultimediaΠpublicationsΠRA TΠinet952rat.ps.
[2] Perkins,C.,Hodson,O.Options for repair of streaming media.draft2ietf2avt2info2repair203.Work in Progress.1998.ht2
tp:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,Πinternet2draftsΠdraft2ietf2avt2info2repair203.txt.
[3] Dempsey,B.J.,Weaver,A.C.On retransmission2based error control for continuous media traffic in packet2switching net2
http://biz.doczj.com/doc/9f3481205.html,puter Networks and ISDN Systems,1996,28(5):719～736.
[4] Hung Q.Ngo,Srivatsan,Varadarajan,J aideep,Srivastavas.On achieving lower consecutive losses for continuous media
streams.http:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,Πtr1999Π992005.ps.
[5] I TU2T Recommendation H.323.Packet based multimedia communications systems.1998.http:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,Π
StandardsΠH.323ΠH323-Primer.ht ml.
[6] Shulzrinne,H.,Casner,S.,Frederick,R.,et al.R TP:a transport protocol for real2time applications.Technical Re2
port,RFC1889.1996.http:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,ΠrfcΠrfc1889.txt.
[7] I TU2T Recommendation H.225.0.Media stream packetization and synchronization for visual telep hone systems on non2
guaranteed quality of service LANs.1998.http:ΠΠwww.databeam.omΠStandardsΠH.323ΠH3232Primer.ht ml.
[8] Schulzrinne,H.GMD fokus,R TP tools.1998.ftp:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,ΠpubΠschulzrinneΠrtptoolsΠ.
[9] Swan,A.,Berkeley,B.D.R TPmon.1998.ftp:ΠΠhttp://biz.doczj.com/doc/9f3481205.html,ΠpubΠrtp monΠrtp mon.tar.gz.
[10] Mastromartino ,E.A.R TP library.1998.ftp :ΠΠhttp://biz.doczj.com/doc/9f3481205.html,r.it Πpub ΠR TP Π.[11] Rosenberg ,J.,Schulzrinne ,H.An R TP payload format for generic forward error correction.Internet Draft ,Work in
Progress.1998.http :ΠΠhttp://biz.doczj.com/doc/9f3481205.html, Πinternet 2drafts Πdraft 2ietf 2avt 2fec 204.txt.
Real 2Time Repa iring Lost Packets B ased on Real 2Time Transport Protocol
3
ZHAN G Ke , XIE Zhong 2cheng , J U Jiu 2bin
(Depart ment of Com p uter Science ,Jili n U ni versity ,Changchu n 130023,Chi na )
E 2mail :jjb @http://biz.doczj.com/doc/9f3481205.html,
http :ΠΠhttp://biz.doczj.com/doc/9f3481205.html, Abstract : In real 2time applications ,such as IP phones and remote conference systems utilizing R TP (real 2time transport protocol )for transmitting continuous media data over Internet ,packet loss t hat impairs quality of trans 2mitting severely is inevitable.It is a better way to solve t his problem by adding a f unction of lost repairing to R TP.In t his paper ,a met hod of lost repairing wit h FEC (forward error correction )based on R TP and an R TP library ,which was designed and implemented based on t his met hod are introduced.Then a testing met hod of lost repairing f unction and t he results are illustrated.
K ey words : R TP (real 2time transport protocol );packet loss ;lost repairing ;FEC (forward error correction )3Received December 23,1999;accepted March 23,2000
Supported by t he National Research Foundation for t he Doctoral Program of Higher Education of China under Grant No.1999018319
敬告作者
《软件学报》创刊以来,蒙国内外学术界厚爱,收到许多高质量的稿件,其中不少在发表后读者反映良好,认为本刊保持了较高的学术水平.但也有一些稿件因不符合本刊的要求而未能通过审稿.为了帮助广大作者尽快地把他们的优秀研究成果发表在我刊上,下面特列举一些审稿过程中经常遇到的问题,请作者投稿时尽量予以避免,以利大作的发表.
1.读书偶有所得,即匆忙成文,未曾注意该领域或该研究课题国内外近年来的发展情况,不引用和不比较最近文献中的同类结果,有的甚至完全不列参考文献.
2.做了一个软件系统,详尽描述该系统的各个方面,如像工作报告,但采用的基本上是成熟技术,未与国内外同类系统比较,没有指出该系统在技术上哪几点比别人先进,为什么先进?一般来说,技术上没有创新的软件系统是没有发表价值的.
3.提出一个新的算法,认为该算法优越,但既未从数学上证明比现有的其他算法好(例如降低复杂性),也没有用实验数据来进行对比,难以令人信服.
4.提出一个大型软件系统的总体设想,但很粗糙,而且还没有(哪怕是部分的)实现,很难证明该设想是现实、可行、先进.
5.介绍一个现有的软件开发方法,或一个现有软件产品的结构(非作者本人开发,往往是引进的,或公司产品),甚至某一软件的使用方法.本刊不登载高级科普文章,不支持在论文中引进广告色彩.
6.提出对软件开发或软件产业的某种观点,泛泛而论,技术含量少.本刊目前暂不开办软件论坛,只发表学术文章,但也欢迎材料丰富,反映现代软件理论或技术发展,并含有作者精辟见解的某一领域的综述文章.
7.介绍作者做的把软件技术应用于某个领域的工作,但其中软件技术含量太少,甚至微不足道,大部分内容是其他专业领域的技术细节,这类文章宜改投其他专业杂志.
8.其主要内容已经在其他正式学术刊物上或在正式出版物中发表过的文章,一稿多投的文章,经退稿后未作本质修改换名重投的文章.
本刊热情欢迎国内外科技界对《软件学报》踊跃投稿.为了和大家一起办好本刊,特提出以上各点敬告作者.并且欢迎广大作者和读者对本刊的各个方面,尤其是论文的质量多多提出批评建议.9
401张钶等:基于实时传输协议的丢包实时修复
RCTP实时控制/传输通讯协议 RCTP协议(RealTime Control and Translate Protocol)为自定义实时控制/传输通讯协议。 1、基本帧格式 1.1帧结构 typedef struct { uchar head; //帧头 uchar length; //帧长度 uchar length_rep; //帧长度重复 uchar head_rep; //帧头重复 uchar source_id; //发送设备号 uchar directory_id; //接收设备号 uchar handle; //帧与操作类型 uchar parameter[frame_data_size]; //帧参数域buf uchar AccVal; //累加和校验 uchar stop; //结束符 } struct_frame; 1.2开始符的判断 条件：if(struct_frame.head == struct_frame.head_rep) && (struct_frame.length == struct_frame.length_rep)成立。 1.3帧与操作类型 1.3.1 数据帧的操作类型定义 1.3.2 命令帧的操作类型定义
1.4 校验和 校验和为：0-N的累加值，1字节。 2、基于RCTP的LED数码管数据采集通讯协议: RCTP-Ⅰ协议 RCTP-Ⅰ协议是基于RCTP的LED数码管数据采集通讯协议，物理上基于RS-485口，通过屏蔽双绞线实现通讯。RCTP-Ⅰ协议是一种主-从协议。主站设备发送要求到从站设备，从站设备响应，从站不能主动发出信息。 波特率代码表： 在默认状态下通信的设置速率一般是9600、无效验、8数据位、1个停止位。
实时传输协议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所示：
一.UDP和Socket通信步骤 1.UDP Server程序 1、编写UDP Server程序的步骤 (1)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。 (2)初始化sockaddr_in结构的变量，并赋值。sockaddr_in结构定义： struct sockaddr_in { uint8_t sin_len; sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; char sin_zero[8]; }; 这里使用“08”作为服务程序的端口，使用“INADDR_ANY”作为绑定的IP地址即任何主机上的地址。 (3)使用bind()把上面的socket和定义的IP地址和端口绑定。这里检查bind()是否执行成功，如果有错误就退出。这样可以防止服务程序重复运行的问题。(4)进入无限循环程序，使用recvfrom()进入等待状态，直到接收到客户程序发送的数据，就处理收到的数据，并向客户程序发送反馈。这里是直接把收到的数据发回给客户程序。 2、udpserv.c程序内容： #include
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）
基于TCP协议的网络通信系统的设计与实现 摘要:网络通信，由于其具有实时性、跨平台性、成本低、效率高等优点而受到广泛的使用。设计并实现一个能够处理多用户进行实时、安全的即时通信系统具有较强的现实意义。即时通信的底层通信是通过SOCKET套接字接口实现的。当前的主流UNIX系统和微软的WINDOWS系统都在内核提供了对SOCKET字接口的支持。使用这个统一的接口，可以编写一个可移植的TCP/IP通信程序。使信息能够在INTERNET上可靠的传输。 本文设计并实现了基于局域网内的简单即时通信系统，系统采用C/S模式，底层通信通过SOCKET套接字接口实现，服务器负责客户端的登录验证，好友信息的保存和心跳报文的发送。客户端采用P2P方式实现消息传递，并能实现文件的传输。本文首先讨论了同步套接字，异步套接字，多线程并发执行任务等；然后阐述了客户端、服务器如何使用XML序列化的消息进行通信。 关键词：即时通信；文件传输；套接字；TCP协议 Abstract :Instant messages have several advantages such as real-time, cross-platform, cheap and efficient. To design a Multi-user IM (instant message) architecture is very i mportant in both theory and realism. Instant message based on TCP/IP protocol that is realized by socket interface. Almost all UNIX operation systems and Microsoft's win dows operation systems provide support of socket in the kernel. Using the uniform int erface, we can develop a portable program of TCP/IP, which help us transfer informati on in Internet safely and credibly. The system uses the client/server(C/S) mode. The server takes the responsibility of th e login message of client, the saving of friend message and Message heartbeat. The tra nsmission of the basic messages of the customer end will be designed on P2P architec ture. This thesis explains how the client and server communicate via serializing XML message. Key words: Instant Message; File Transfer; Socket; TCP protocol
全球眼 实时视频传输和控制协议v2 修改历史 复审人
一、说明 这份协议描述了视频服务器与流媒体分发服务器、视频服务器与企业客户端之间传输实时视频的方法。文档中没有针对媒体分发服务器与企业客户端（第三方播放器）之间的通信方法，但是媒体分发服务器与企业客户端（第三方播放器）之间的通信方法尊守RTC1889和RPC2326定义的规范。 在这篇文档里我们把象视频服务器这样能够给观看者提供视频数据的设备称为逻辑上的服务端角色（也就是视频源），象企业客户端这样播放视频的终端设备称为逻辑上的客户端角色（也就是接收者或观看者）。流媒体分发服务器同时具有两种角色。 交互流程中列出了两种模式，我们当前要先实现接模式。推模式是为了视频服务器在私网环境时也可以通过流媒体发服务器向用户提供视频服务。推模式暂不实现。 协议中没有提及RTCP协议，但并不影响视频通信质量，而且目前很难实现有效的编解码之间返馈的处理方法，所以现在，以及将来的一段时间都不会考虑RTCP协议，除非出现有效的视频质量控制机制。 本文参考RFC 1889、1890、2326、3550完成，如有不符合标准的、或者不完善的陈述，请提出来，发电子邮件到piaoxichuang@。如果您有更好的想法也可以通过邮件进行交流。 二、协议 通信方式使用RTP over TCP方式。（RTC1889、RFC2326） 1、一个完整的包 网络字节顺序
2、RTP包的封装（RTP over TCP） 网络字节顺序 Channel Identifier：取值0。因为只有一个流在一个TCP连接中传递，同时不使用RTCP协议。参见RFC 2326 [10.12]节。 Lenth：取值为RTP包的大小，包括RTP头部，但不包含本身的4个字节，以BYTE为单位。 3、RTP 12字节头部 网络字节顺序 V：版本，取值2。[可能会使用0值，还没想清楚，可能的使用情况是为了实现防火墙穿透] P：附加数据，取值为0。 X：扩展头，取值为1。 CC：CSRC列表数量，取值为0。 M：记号，取值0或1。关于M字段的取值：如果扩展头中T字段为1，则当一个包（RTP Packet）是一个帧（Sample）的最后一个包时取值1，否则取值0；扩展头中T字段为1时，由于指令长度较小，一个RTP就可以传输完成，所以取值为1。除非要使用多个RTP包传输，最后一个RTP包取值为1，前面的包取值为0。 PT：负载类型，动态，取值96。参见RFC 1890 [7]节。 Sequence Number：RTP包的序号，初始值是随机的，不是0。 Timestamp：以视频编码算法提供者的需要填写或单调增长的时间戳。[将来可能把这个值也传递给视频解码算法中去。] SSRC：随机数，用于在同一个会话中区分不同的流。建议使用MD32。 UINT Y[4] If Y = MD5(X) Then MD32(X) = Y[1] ^ Y[2] ^ Y[3] ^ Y[4] 注：RTP包大小最大值为2048。（因为DSS支持的最大包为2048Bytes）
几种安全的网络传输协议 ·从URL谈起（可以直接跳到第4页看FTPS，HTTPS） 当我们想浏览一个网站的时候，只要在浏览器的地址栏里输入网站的地址就可以了，这个网站地址，术语叫做URL（Uniform Resource Locator)，译成中文即“统一资源定位符”。就像每家每户都有一个门牌地址一样，每个网页也都有一个互联网地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。 ·超文本传输协议HTTP 大家一定注意到，在输入网站地址时，http://这一部分通常不用输入，系统软件会自动补上，所有网页地址都少不了它。那么，http 究竟是个什么含义呢？ HTTP 是“超文本传输协议（Hypertext Transfer Protocol）”的意思。 简单地讲，HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。 它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。这就是你为什么在浏览器中看到的网页地址都是以http://开头的原因。 基于HTTP协议的通讯的基本工作过程如下： 由于HTTP协议是基于请求/响应范式的（相当于客户机/服务器）。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息，包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 在互联网上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80，但其它的端口也是可用的。HTTP只预示着一个可靠的传输。它并不特别指明网络传输媒介，HTTP传输可以在互联网上完成，也可以在其它网络的其它协议之上完成。 在WWW中，“客户机”与”服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户机在另一个连接中可能作为服务器。基于HTTP协议的客户机/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。 任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户机，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。服务器的驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，根据TCP/IP协议的规定，在网络上发送和接收的数据被分成一个或多个数据包（packet），每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP协议决定了每个数据包的格式。传输完成后的这些数据包再重新组合，还原为数据信息。从网络层次模型的角度讲，HTTP协议以及下面将要讲述的几种互联网传输协议都属于TCP/IP模型最上层的应用层协议。
公告：2010年SD2.0大会即将在上海召开了～历届参会网友精彩心得集锦[意见反馈][官方博客] 实时传输协议（RTP）和实时控制协议（RTCP）收藏 RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的 、
从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)，如图16-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。 图16-13 RTP和UDP之间的接口
现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP 信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码和播放声音。 如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳，而是使用标准的RTP协议，应用程序就更容易与其他的网络应用程序配合运行，这是大家都
RTP: A Transport Protocol for Real-Time Applications 1 Introduction This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, times tamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 10). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network. Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence. While RTP is primarily designed to satisfy the needs of multi- participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.
网络摄像机传输协议概述 1、传输协议 网络摄像机提供很多基于IP网络的传输协议，以尽可能地保证音视频数据，PTZ控制数据网络传输质量。实时视频流经过IP网络传输，通过多种协议组合，适应各种复杂的网络传输环境。 RTP(Realtime Transport Protocol),实时传输协议，其专门针对实时流媒体而设计， RTP 的基本功能是将几个实时数据流复用到一个UDP分组流中，这个UDP流可以被发送给一台主机（单播模式），也可以被传送给多台目标主机（多播模式）。因为RTP仅仅封装成常规的UDP，理论上路由器不会对分组有任何特殊对待，但现在高级的路由设备都有针对RTP协议优化选项。RTP协议的时间戳机制，不仅减少了抖动的影响，而且也允许多个数据流相互之间的同步，这样可以很方便地基于I/O事件对视频图像进行字幕添加，网络摄像机往往将音视频编码数据封装成RTP分组。 RTCP(Realtime Transport Control Protocol)实时传输控制协议，其是RTP的姊妹协议，它处理反馈、同步和用户界面等，但是不传输任何数据。它的主要功能是用来向源端提供有关延迟、抖动、带宽、拥塞和其它网络特性的反馈信息，编码进程可以充分利用这些信息。因此当网络状况较好时，可以提高数据速率（从而达到更好的质量），而当网络状况不好时，它可以减少数据速率。通过连续的反馈信息，编码算法可以持续地作相应的调整，从而在当前条件下尽可能地提供最佳的质量。 RTSP(Real Time Streaming Protocol)实时流协议，RTSP协议利用推式服务器 (push server)方法，让音视频浏览端，发出一个请求，网络摄像机只是不停地向浏览端推送封装成RTP分组的音视频编码数据，网络摄像机可以用很小的系统开销实现流媒体传
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的协议原理，数据包格式，工作机制三个方面来对该协议做一个基本的认识和了解：
常用聊天/传输工具/下载软件的协议及端口,记录并封堵的协议列表如下，一般有固定的通讯协议端口的软件、工具都是比较容易用网路岗封掉的，如果不是固定的端口或是服务器地址的话，也可以用网路岗7新增的专业的IP包分析模块工具进行抓包分析，再设置相应的规则进行封堵。 序号协议名称协议类别协议简介 1 腾讯QQ 聊天工具 QQ默认使用UDP通讯方式，默认端口为UDP 8000和8001。QQ 默认采用UDP 通讯方式，端口8000，8001。如果UDP 的两个端口不通，会自动转换到TCP 80端口或者TCP 443端口进行通讯。QQ 同时也支持HTTP 代理模式及SOCK5 代理模式。 2 雅虎通 聊天工具 雅虎通Yahoo!使用TCP通讯方式，默认端口为TCP 5050。Yahoo! 采用TCP 通讯方式，默认端口5050，当5050 端口不通时会自动转换为23、21、25、110 等十几个端口。Yahoo! 支持代理服务器模式。 3 MSN 聊天工具 MSN使用TCP通讯，支持TCP 1863端口和http 80端口。MSN（Live）messenger 采用TCP 通讯方式，支持1863 端口和80 端口，并在登录过程中使用HTTPS，端口443。MSN 支持代理服务器（HTTP 代理，SOCK4/SOCK5 代理）。 4 AIM/ICQ 聊天工具 ICQ和AIM是AOL的即时通讯软件，都采用OSCAR通讯协议。ICQ 和AIM 采用TCP 通讯方式，默认端口5190，也会自动转换到80，443 等其他端口，并且支持代理模式。从AIM6.5版起，开始采用TLS加密协议。 5 HTTP 网页浏览 HTTP协议使用TCP通讯，默认端口是80（可以自定义）。 6 FTP 文件传输 TCP方式，常见为21端口。连接分为控制端口和数据端口。 7 QQFTP_TCP 文件传输 TCP方式，通讯端口443（HTTPS）。FTP 服务一般运行在20 和21 两个端口。端口20 用于在客户端和服务器之间传输数据流，而端口21 用于传输控制流，并且是命令通向FTP 服务器的进口。QQ 文件传输TCP 方式，通讯端口443（HTTPS）。QQ 文件传输UDP 方式，一般是在TCP 方式受阻时，容易出现。具体端口由通讯时协商确定。
RTP-----实时软件传输协议外文翻译(一) 附录 英文原文资料 RTP: A Transport Protocol for Real-Time Applications 1 Introduction This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, times tamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 10). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network. Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to
100029825Π2001Π12(07)1042208○c2001Journal of Software 软件学报Vol.12,No.7基于实时传输协议的丢包实时修复Ξ 张 钶, 谢忠诚, 鞠九滨 (吉林大学计算机科学系,吉林长春 130023) E2mail:jjb@http://biz.doczj.com/doc/9f3481205.html, http:ΠΠhttp://biz.doczj.com/doc/9f3481205.html, 摘要:在诸如IP电话和远程会议系统等实时应用中,使用实时传输协议R TP(real2time transport protocol)在因特网上传输的数据包不可避免地会丢失,极大地影响了传输服务质量.在R TP上增加丢包修复功能可以解决这个问题.介绍了在R TP上采用FEC(forward error correction)修复丢包的方法,基于这个方法设计并实现了一个支持丢包修复功能的R TP库,说明了丢包修复功能的测试方法和结果. 关键词:R TP(real2time transport protocol);丢包;修复;FEC(forward error correction) 中图法分类号:TP393 文献标识码:A 话音包与数据包在因特网上传输时可能有较大的延迟和丢包概率.丢包将严重地影响IP电话的话音质量[1],因此采取丢包修复方法是很有必要的.造成媒体包丢失的原因有这样几个:路由器和网关发生拥塞,某些包可能被丢弃;包传输过程中的延迟过大,因到达接收端太晚而无法回放;在多任务操作系统中,工作站超载运行时可能因调度困难而不能及时处理传输. 目前有4种常见的丢包修复方法[2].重发法是修复TCP丢包常用的方法,但语音数据对时延敏感,只有当重发延迟满足实时应用的要求时,重发法才是适用的[3].冗余法(媒体相关的F EC (forward error correction)法)[1]是把第n个数据包的副本重新用更低位码率的压缩算法,如GSM (global system mobile)语音压缩,附加到第n+1个数据包中一起发送,如果第n个包丢失了,可以从第n+1个包中所附带的副本来恢复;如果附带多个副本,还可以修复连续丢包.这种方法需要额外的CPU及带宽开销,并且只有大致的修复能力.媒体无关的F EC[2]法有精确的修复能力,发送端对连续多个数据包作异或运算求出F EC数据包,并以奇偶包的形式发送,丢失的数据包可以用接收到的数据包和F EC包作异或运算再生出来.此方法的缺点是与冗余法相比有较大的延迟(缓存多个包以作F EC运算),增加了带宽需求.交叠法[2]和差错分散法(error sp read)[4]降低或分散了丢包的影响,它们的优点是不增加带宽需求,但在传输两端中增加缓冲延迟开销.几类修复方法的性能对比见表1.由此可见,媒体无关F EC法和冗余法适合实时传输应用. 对丢包现象的大量研究发现,丢失单包的概率最大,因此丢包修复主要解决丢失单包的修复问题. IP电话和远程会议系统,从早期的Vat,NeVo T,到后来基于H.323[5]协议的Net Meeting和IP电话,都把实时传输协议R TP(real2time t ransport p rotocol)[6]作为传送实时媒体的工具.R TP Ξ收稿日期:1999212223;修改日期:2000203223 基金项目:高等学校博士学科点专项科研基金资助项目(1999018319) 作者简介:张钶(1971-),男,山东泰安人,博士,主要研究领域为计算机网络,分布式系统;谢忠诚(1972-),男,辽宁阜新人,硕士,主要研究领域为计算机网络,分布式系统;鞠九滨(1935-),男,黑龙江哈尔滨人,教授,博士生导师,主要研究领域为计算机网络,分布式系统.