[发明专利]IP报文的发送、接收的方法及装置

说明书

技术领域

本发明涉及通信技术领域，具体涉及IP报文的发送、接收的方法及装置。

背景技术

在互联网协议(IP)网络中使用报文封装技术来携带真正有用的数据信息，一般情况下每份报文的格式是：链路层协议头+IP头+高层协议头(可以有几层)+有效数据。如在链路层为PPP时，传输有效信息为语音信息的报文封装格式一般如图1所示。

参考图1中可以看出，相对于有效信息仅为15～30字节(bytes)等小报文来说，如果每份报文都携带40字节的IP+UDP+RTP报文头，传输效率是非常低下的。为此标准化组织规定了一系列的IP头压缩(IPHC)协议，来解决这个问题，目前使用最广泛的头压缩协议是压缩实时传输协议(CompressedReal-time Transport Protocol，cRTP)和增强压缩实时传输协议(EnhancedCompressed Real-time Transport Protocol，EcRTP)，由于EcRTP是cRTP协议的增强，所以在实际应用中，启用EcRTP协议的一方一般都能够兼容cRTP协议。这两种协议能够将IP头以后(包括IP头)，有效数据之前的各级协议头总共压缩为2～4个字节。这样可以极大的降低报文的冗余度，提高链路的带宽利用率。

图2是以PPP链路上采用cRTP协议压缩为例，列出了压缩后的报文封装格式：

各种IP头压缩协议技术的原理是这样的：IP/TCP/UDP/RTP头部有一半的字节在一条流的传输期间是保持不变的(源目的IP地址、源目的端口号等)，尽管每个包中总有几个字节要发生变化(IP报文的ID，RTP报文的TimeStamp等)，但包与包之间的区别通常却是恒定的，因此二次差分为0。压缩端可以在发送一次或N+1次未压缩头(FULL_HEADER)之后，将未变化的字段从其后的压缩头中剔除，其余的压缩来自于对变化字段进行区分编码以减少长度，此外，IP头部以及UDP头部中的长度字段可以由链路层长度计算得到，因此也可以压缩掉。通过维护压缩端与解压端共享的未压缩头与一次差分序列，所需通信的便只有二次差分为0的信息了。在这种情况下，如果不考虑任何信息丢失，解压端在收到一个压缩包后可以通过将一次差分结果叠加到未压缩头来重建原始报文头部。

IP头压缩协议为每条流维护一个上下文会话状态，用来标识压缩端和解压缩端共享的未压缩头与一次差分序列。压缩包携带一个简称为CID(表示会话上下文标识符)的小整数(根据通信双方需要建立的压缩会话数来定义CID的范围，如双方只需要同时进行256条压缩会话的通信，则CID只需要8bit。)来指示该压缩包属于哪个上下文，解压端使用CID就可以直接找到先前通过收到的FULL_HEADER报文所记录下来的未压缩头和差分序列了。

EcRTP和cRTP的原理基本相同，而EcRTP对于cRTP的一个增强是：由于FULL_HEADER报文负责在通信双方间建立一条共享的会话，所以如果由于传输质量的原因造成FULL_HEADER的丢失会引起通信质量的严重下降，为此EcRTP规定每条流在建立会话的过程中，需要多次(N+1次，N值压缩参数之一)发送FULL_HEADER报文，以防止FULL_HEADER报文的丢失。

在使用cRTP协议或EcRTP协议进行头压缩时，通信的双方(压缩端和解压缩端)应该保持一致的压缩参数，以便于对于每种压缩类型的报文都能够保证解释的一致。

压缩参数的一致可以通过底层协议(PPP、MPLS等)的协商完成，也可以通过在通信的双方手工配置的一致来保证。EcRTP是对cRTP的增强，一般在cRTP的基础上增强实现EcRTP，所以在实际应用中，启用EcRTP协议的一方一般都能够兼容cRTP协议。

在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：

EcRTP和cRTP两种协议定义的压缩报文类型值基本相同，但是某些报文的格式(如COMPRESSED_UDP类型报文)差异很大。而如果不是通过底层协议的协商来完成压缩参数的一致，则在配置人员出现错误的情况下，两端手工配置的压缩参数有可能出现不一致(如一端配置cRTP、一端配置EcRTP)的情况，而协议无法检测出这种异常情况。这样引起通信的中断。

发明内容

本发明实施例解决的技术问题是提供IP报文的发送、接收的方法及装置，可以避免由于通信双方采用的压缩实时传输协议不一致引起的通信中断。

本发明实施例提供一种IP报文的接收方法，包括：