I000顺序号
--- --- --- --- --- --- --- ---
00generation
--- --- --- --- --- --- --- ---
在标志为无效,要发送COMPRESSED_NON_TCP包或FULL_HEADER的环境中,"I"位应设置为1 。
假如I为0,则环境处于咨询状态 。I位设为0表示、在链路错误指示后要发送环境咨询状态 。
由于CONTEXT_STATE包本身也可能丢失,所以答应对一个或多个块重传输 。但希望只有在接
收到另一个包时才触发重传输,假如链路几乎空闲时,可用一个相对较长的计时器来触发重
传输(如定为1秒) 。假如给定环境的块被重传输,它可能与用来刷新环境的FULL_HEADER或
COMPRESSED_NON_TCP错过 。这时压缩器可以忽略错误指示 。
在需要传输UDP校验和的情况下,解压器可以尝试使用[3]的10.1节描述的"twice"算法 。
在该算法中,假设delta值与丢失包和随后接收的一个包相同则delta要多次应用 。校验和匹
配表示成功 。对于这里定义的方案,顺序号的区别说明了delta必须要应用的次数 。注重,
一个不正确的正指示可能会带来一些小风险 。即便这里"twice"算法应用成功,也建议发送
一个FULL_HEADER或COMPRESSED_NON_TCP包 。
有些错误可能无法检测出来,比如一排丢失了16个包且链路层没有提供错误指示 。在这
种情况下解压器将产生无效的包 。假如UDP校验和正在传输,接收方可能会检测到无效包并
且丢弃他们,但是接收方无法通知解压器 。因此,建议解压器周期性地验证UDP校验和,如
每16个包验证一次 。假如发现错误,它应将环境置为无效并且用一个CONTEXT_STATE包来通
知压缩器 。
3.4.RTCP控制包压缩
按照RTP协议规定,数据通过偶数端口发送,而RTCP包通过下一个奇数号端口进行发送,
因此可以为RTP和RTCP包分别制定压缩方案 。对于RTCP,压缩同时针对包头和数据本身,即
不同包类型的内容 。SR和RRRTCP包中的数字内容不好压缩,但SDES包中的文本信息可以压
缩到一个屏蔽位表示每个存在并已压缩的项(用于对SDESNOTE项进行计时并答应端系统为
计算间隔而测量平均RTCP包大小) 。
然而由于一些原因(尽管压缩应该应用于IP和UDP头),在本压缩方案中并不对RTCP头和
数据进行压缩 。RTP协议规范建议应该按比例决定RTCP包间隙,以便所有会话中参与者占用
的RTCP总带宽不超过5%的会话总带宽,所以压缩RTCP并没有太多的好处 。压缩SDES项会造成
每个环境ID要存储的共享状态明显增加 。并且,当通过一个RTP混合器发送多个源的SDES信
息时,为了答应压缩就必须为每个SSRC标识符维护一个单独的RTCP会话环境 。在一个超过255
个参与者的会话中,即使只有一个参与者发送数据也会造成环境缓存中大量的垃圾数据 。假
设RTCP包作为COMPRESSED_UDP形式发送,即使不对其进行压缩,多数情况下它所占压缩链路
的比重也不超过5% 。鉴于非压缩RTCP包消耗的带宽不超过会话总带宽的5%,对于一个长度为
90字节的典型RTCP包,只要RTP数据包负载长度至少为108字节,则RTCP所占用的压缩带宽比
率也会不超过5% 。假如RTP负载长度比较小,该比率会有所提高,但对于负载大小为37字节
的RTP包而言,该比例仍不会超过7% 。假如RTP负载数据包很大,则压缩RTCP所占的比例小于
非压缩RTCP(如对1000字节的包该比例为4%) 。
3.5.非RTPUDP包压缩
如前所述,COMPRESSED_UDP包可用来压缩未携带RTP信息的UDP包 。UDP之头后的任何数据
都不太可能象在RTP头中相应字段一样有恒定不变的值 。非凡地,SSRC字段就很可能发生改
推荐阅读
- PPP协议:关于在点到点链路上进行多协议包传送的建议
- PPP会话终结
- PPP链路工作过程
- PPP链路操作
- 2 低速串行链路上的TCPIP头部压缩
- 2 TCP/IP详解学习笔记-数据链路层(编写中)
- PPP 链路质量监控
- BGP协议建立连接及使用ISDN备份卫星链路
- 在串行线路上传输IP数据报的非标准协议
- 串行线路IP 尾部封装和SLIP
