低速串行链路下IP/UDP/RTP数据包头的压缩

【低速串行链路下IP/UDP/RTP数据包头的压缩】本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建议以
得到改进 。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度
和状态 。本备忘录的发布不受任何限制 。
版权声明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
摘要
本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法,它可以降低在低速串行链路上
的网络开销 。多数情况下,三个头可压缩到2-4字节 。
请赐教并将您的建议发送到工作组邮件列表rem-conf@es.net或直接给作者 。
本文中的要害字“必须”,“必须不”,“要求的”,“应该”,“不应该”,“会”,“不会”,
“建议”,“或许”,“可选的”在RFC2119中解释 。
目录
本备忘录的状态 1
版权声明 1
摘要 1
1.介绍 2
2.设想和折中 2
2.1.单工与全双工 3
2.2.分片与分层 3
3.压缩算法 3
3.1.基本概念 3
3.2RTP数据包头压缩 4
3.3协议 5
3.4.RTCP控制包压缩 12
3.5.非RTPUDP包压缩 13
4.与分片的交互 13
5.压缩协商 13
6.致谢 14
7.参考文献 14
8.安全性考虑 14
9.作者地址 15
10.版权声明 15
1.介绍
随着实时传输协议(RTP)成为正式的RFC[1]发行,人们对于利用RTP实现不同的网络音视
频应用程序间互操作的爱好也日益增长 。然而,我们也注重到,当使用低速链路如14.4Kb/s
或28.8Kb/s拨号时,12字节的RTP头对于仅有20字节的负载而言开销实在太大 。(为了减少
头占用的字节,一些已经在类似环境下存在的应用通常使用自定义的协议,而这样做的代价
就是削减了RTP相关的功能 。)
事实上,正如在TCP中已经取得巨大成功,也可通过压缩技术来令IP/UDP/RTP包头变小 。
这时,压缩可以针对于RTP头(在端到端应用中),或者IP,UDP,RTP的组合头(在Link-by-Link
应用中) 。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果,因为两
种情况下的结果大小均为约2-4字节 。同时,由于延迟和丢失率都很低,对Link-by-Link应
用进行压缩性能上也更好 。因此我们在这里定义的方法就是针对Link-by-link应用下
IP/UDP/RTP头进行组合压缩 。
本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包 。为了能同时在IPv6
和IPv4下使用,这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架 。该框架把TCP
和非TCP定义为IP之上的两个传输类 。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三
类 。
2.设想和折中
本压缩方案的目标是,在不发送UDP校验和的情况下,将大多数包的IP/UDP/RTP头压缩到
2个字节,在带校验和时则压缩到4个字节 。这一方案的提出主要是受使用14.4kb/s和
28.8kb/s拨号调制解调器发送音视频时碰到的相关问题所引起 。这些链路提供全双工通信,
所以协议利用了这点,尽管协议在用于单工链路时可能性能会有所下降 。该方案在本地链路
上往返时间(RTT)很低,从而实现性能最高 。
为了降低低速链路下的延迟,除了在第四节中确定了分片和压缩中可能使用的一些交互
外,本规范并未提出大型数据包的分片和占先策略 。分片方案可能会单独定义并与本压缩方
案配合使用 。
应该注重到,实现的简单性是评价压缩方案的一个重要因素 。通信服务器可能要用一个
处理器支持多达100个拨号调制解调器的数据压缩 。因此,如下的考虑都是比较恰当的,即

推荐阅读