[发明专利]压缩实时协议的优化方法和装置

说明书

技术领域

本发明涉及一种信息处理方法，尤其涉及一种压缩实时协议的优化方法和装置。

背景技术

随着实时传输协议(RTP，Real-time Transport Protocol)成为正式的Internet标准(RFC，Request For Comments)发行，人们对于利用RTP实现不同的网络音视频应用程序间互操作的兴趣也日益增长。然而在使用低速链路如14.4Kb/s或28.8Kb/s拨号时，12字节的RTP头对于仅有20字节的负载而言开销实在太大。为了减少头占用的字节，一些应用通常使用自定义的协议，而这样削减了RTP相关的功能。

也可通过压缩技术来令IP/UDP/RTP包头变小，如压缩实时协议(CRTP(RFC2508))。如图1所示，压缩可以针对于在端到端应用中的RTP头(HEADER)，或者针对Link-by-Link应用中的IP，UDP，RTP的组合头。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果，因为两种情况下的结果大小均为约2-4字节。同时，由于延迟和丢失率都很低，对Link-by-Link应用进行压缩，性能也更好。CRTP在不发送用户数据报协议(UDP，User Datagram Protocol)校验和的情况下，将大多数包的IP/UDP/RTP头压缩到2个字节，在带校验和时则压缩到4个字节。

CRTP是在E1链路上常用的点到点压缩算法，CRTP算法可以把IP/UDP/RTP共36字节的报文头压缩到6-9字节，大大提高链路利用率。如图2A所示，压缩启动时压缩方构造FULL HEAD报文，该报文包含压缩标识(CID，Compressidentification)和完整的IP/UDP/RTP头部字段，传递给解压端以供解压端构造上下文(CONTEXT)表项。解压端建立起CID-IP/UDP/RTP的映射关系后，压缩端后续发送仅包含CID压缩头的报文来节省带宽。解压端根据压缩头的CID来查表恢复出IP/UDP/RTP头部字段。解压端同时检查CID的有效性和连续性，如果发现CID丢失，则表示线路上发生了传输错误，解压端会构造上下文状态(context state)报文发给压缩端，来要求压缩端重新发送完整头(FULLHEAD)报文以便重建CID-IP/UDP/RTP的映射表项。在链路正常的情况下，这种机制可以很好的做到错误重传。

但是如图2B所示，在网络拥塞下，如果解压端侧发现丢包，会向压缩端发起context state报文请求同步。压缩端收到context state报文后会在多条链路上并发发出多条完整头(FULL HEAD)报文。而FULL HEAD报文比通常传输的压缩头(Compress head)多出IP/UDP/RTP包头共计32字节，占用带宽较大，会造成一轮新的拥塞，产生传输恶化的雪崩效应，从而大大降低传输效率。

发明内容

本发明实施例的目的在于提供一种压缩实时协议的优化方法和装置，能够避免在网络拥塞下解压侧数据包丢失产生传输恶化的雪崩效应。

本发明实施例的目的在于提供一种压缩实时协议的优化方法，该方法包括：定时检测链路可用带宽；以及若可用带宽小于预先设定比例时，通知上层中央处理器，禁止响应上下文状态报文。

本发明实施例还提供一种压缩端装置，该装置包括：检测模块，用于定时检测链路可用带宽；比较模块，用于比较所述可用带宽是否小于预先设定比例；以及响应模块，若比较模块的比较结果为可用带宽小于所述预先设定比例时，通知上层中央处理器，所述上层中央处理器通知底层网络处理器，禁止响应上下文状态报文。

在应用CRTP压缩协议的窄带链路上，如果发生流量拥塞，应用本发明可以有效缓解原协议算法导致的拥塞加剧的雪崩效应，更充分的利用带宽，提高传输效率。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1为RTP数据包格式在压缩前后的示意图。

图2A为正常情况下CRPT的压缩端和被压缩端之间的操作示意图。

图2B为拥塞传输下CRPT的压缩端和被压缩端之间的操作示意图。

图3为根据本发明的压缩实时协议的优化方法一实施例的流程图。

图4为根据本发明的压缩实时协议的优化方法另一实施例的流程图。

图5为根据本发明的压缩端装置的一实施例的结构示意图。

具体实施方式