报文处理方法及装置与流程

本发明涉及通信领域，具体而言，涉及一种报文处理方法及装置。

背景技术：

在海上与陆地上的大部分区域是蜂窝式移动通讯系统的信号所不能覆盖，因此，作为一种有效的补充手段，卫星通讯被广泛地应用在上述的海上区域以及陆地上的大部分区域中，尤其是应用于远洋运输、钻探、勘测以及渔业等部门。卫星通信具有不受时间、地点、环境等多种因素的限制，开通时间短、传输距离远、网络部署快、通信成本与通信距离无关等诸多优点，可以实语音和数据的实时双向传输。

其中，卫星电话是现有实现卫星通信的一种，由于卫星信道具有与地面信道不同的一些特点，而传输控制协议(Transfer Control Protocol，简称为TCP)/互联网协议(Internet Protocol，简称为IP)协议当初是为地面网络设计的，所以TCP/IP协议在卫星信道上的传输性能比较差。存在以下问题：

1)一方面延迟大，卫星信道的延时很长，典型的卫星通信延时在540ms左右，这会造成TCP协议的不停的重传，引起通信链路的拥塞。另一方面实际的卫星通信中有很高的误码，而TCP协议不能区分出是网络阻塞造成的数据丢失或是误码造成的数据丢失，TCP协议会一律认为是网络阻塞造成的，从而降低TCP的发送窗口，引起传输的带宽下降；

2)卫星通信带宽低且租用费用昂贵，基于网络协议的语音传输(Voice over Internet Protocol，简称为VOIP)采用不同的编码格式时，需要不同的数据带宽，比如采用G729需要带宽8Kbps，而一个报文头(实时传输协议(Real-time Transport Protocol，简称为RTP)+用户数据协议(User Date Protocol，简称为UDP)+IP头)就占了16K bps，所以一路VOIP电话就需要占用24Kbps的带宽，这对于卫星通信来说是资源极大的浪费。

因此，在相关技术中，存在着语音通信在卫星通讯领域上的带宽利用率不足的问题，而针对该问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明提供了一种报文处理方法及装置，以至少解决相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题。

根据本发明的一个方面，提供了一种报文处理方法，包括：按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。

可选地，通过如下方式与所述接收端协商所述压缩方式：根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。

可选地，所述RTP报文的相关信息通过如下方式获取：判断接收到的待发送给所述接收端的报文是否是RTP报文；在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。

可选地，判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：判断待发送给所述接收端的所述报文是否是UDP报文；当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。

可选地，在将建立的所述压缩表发送给所述接收端之后，所述方法还包括：接收携带挂断指令的第一实时传输控制协议RTCP报文；向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；在接收到来自所述接收端的成功删除响应后，删除所述压缩表。

可选地，在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，所述方法还包括：在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值时，删除所述压缩表；向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。

可选地，在通过卫星将压缩后的RTP报文传输给所述接收端之后，所述方法还包括：接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；根据所述第三通知消息删除所述压缩表。

可选地，所述第三通知消息包括以下至少之一：所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二 阈值的情况下发送的通知消息；所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。

根据本发明的另一方面，提供了一种报文处理方法，包括：接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。

可选地，通过如下方式与所述发送端协商所述解压缩方式：接收来自所述发送端的压缩表；根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。

可选地，在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：接收来自所述发送端的第四通知消息；根据所述第四通知消息删除所述解压缩表。

可选地，所述第四通知消息包括以下至少之一：所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。

可选地，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，在根据所述第四通知消息删除所述解压缩表之后，所述方法还包括：向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。

可选地，在接收来自所述发送端的所述压缩表之后，所述方法还包括：接收携带挂断指令的第二实时传输控制协议RTCP报文；向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。

可选地，在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，所述方法还包括：当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。

根据本发明的另一方面，提供了一种报文处理装置，包括：压缩模块，用于按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；第一发送模块，用于在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。

可选地，所述装置还包括第一协商模块，用于通过如下方式与所述接收端协商所述压缩方式：根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选 择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。

可选地，在获取所述RTP报文的相关信息时，所述第一协商模块包括：判断单元，用于判断接收到的待发送给所述接收端的报文是否是RTP报文；提取单元，用于在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。

可选地，所述判断单元通过如下方式判断接收到的待发送给所述接收端的报文是否是RTP报文：判断待发送给所述接收端的所述报文是否是UDP报文；当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。

可选地，所述装置还包括：第一接收模块，用于在将建立的所述压缩表发送给所述接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；第二发送模块，用于向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；第一删除模块，用于在接收到来自所述接收端的成功删除响应后，删除所述压缩表。

可选地，所述装置还包括：第二删除模块，用于在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除所述压缩表；第三发送模块，用于向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。

可选地，所述装置还包括：第二接收模块，用于在通过卫星将压缩后的RTP报文传输给所述接收端之后，接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；第三删除模块，用于根据所述第三通知消息删除所述压缩表。

可选地，所述第三通知消息包括以下至少之一：所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。

可选地，所述报文处理装置位于第一网关或终端中，所述接收端包括第二网关；或者，所述报文处理装置位于第二网关中，所述接收端包括第一网关或终端。

根据本发明的另一方面，提供了一种报文处理装置，包括：第三接收模块，用于接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；解压缩模块，用于根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。

可选地，所述装置还包括第二协商模块，用于通过如下方式与所述发送端协商所述解压缩方式：接收来自所述发送端的压缩表；根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。

可选地，所述装置还包括：第四接收模块，用于在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，接收来自所述发送端的第四通知消息；第四删除模块，用于根据所述第四通知消息删除所述解压缩表。

可选地，所述第四通知消息包括以下至少之一：所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。

可选地，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，所述装置还包括：第四发送模块，用于在根据所述第四通知消息删除所述解压缩表之后，向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。

可选地，所述装置还包括：第五接收模块，用于在接收来自所述发送端的所述压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；第五发送模块，用于向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；第五删除模块，用于在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。

可选地，所述装置还包括：处理模块，用于在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。

可选地，所述报文处理装置位于第二网关中，所述发送端包括第一网关或终端；或者，所述报文处理装置位于第一网关或终端中，所述发送端包括第二网关。

通过本发明，采用按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接 收端。解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的报文处理方法的流程图；

图2是根据本发明实施例的报文处理方法的流程图；

图3是根据本发明实施例的语音呼叫以及挂断过程的交互流程图；

图4是根据本发明实施例的卫星通信传输场景示意图；

图5是根据本发明实施例的RTP报文的判断流程图；

图6是根据本发明实施例的ROHC自定义协商报文封装格式示意图；

图7是根据本发明实施例的UE直接接入卫星通信场景；

图8是根据本发明实施例的CUDP自定义协商报文封装格式示意图；

图9是根据本发明实施例的第一种报文处理装置的结构框图；

图10是根据本发明实施例的第一种报文处理装置的优选结构框图一；

图11是根据本发明实施例的第一种报文处理装置中第一协商模块102的结构框图；

图12是根据本发明实施例的第一种报文处理装置的优选结构框图二；

图13是根据本发明实施例的第一种报文处理装置的优选结构框图三；

图14是根据本发明实施例的第一种报文处理装置的优选结构框图四；

图15是根据本发明实施例的第二种报文处理装置的结构框图；

图16是根据本发明实施例的第二种报文处理装置的优选结构框图一；

图17是根据本发明实施例的第二种报文处理装置的优选结构框图二；

图18是根据本发明实施例的第二种报文处理装置的优选结构框图三；

图19是根据本发明实施例的第二种报文处理装置的优选结构框图四；

图20是根据本发明实施例的第二种报文处理装置的优选结构框图五。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

在本实施例中提供了一种报文处理方法，图1是根据本发明实施例的报文处理方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；

步骤S104，在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。

从上述步骤可知，在向接收端发送RTP报文时，是首先对该RTP报文进行了压缩(由于RTP报文的报文头会占用较大的带宽，对RTP报文进行压缩时，可以仅对RTP报文的IP头、UDP头和RTP头进行压缩)，然后将压缩后的RTP报文发送给了接收端，其中，压缩后的RTP报文的大小相对于原始的未压缩的RTP报文的而言，会小很多，这样，便可以减少带宽的占用，从而实现了在一定的带宽上发送更多的RTP报文的目的，提高了带宽的利用率，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。

在一个可选的实施例中，可以通过如下方式与接收端协商压缩方式：根据待发送给接收端的RTP报文的相关信息建立压缩表，其中，该压缩表中携带当前选择的压缩方式的标识和上述RTP报文的相关信息，当该当前选择的压缩方式为可靠头压缩(Robust Header Compression，简称为ROCH)或配置压缩实时协议(Configuring Compressed Real-Time Protocol，简称为CRTP)时，上述相关信息包括RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当上述压缩方式为配置压缩用户数据协议(Configuring Compressed User Date Protocol，简称为CUDP)时，上述相关信息包括RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的上述压缩表发送给接收端，其中，该压缩表用于指示接收端建立与压缩表对应的解压缩表。其中，接收端在成功建立了解压缩表后，可以再返回一个建立OK的响应消息。需要说明的是，上述的几种压缩方式仅是示例，还可以采用其他的压缩方式，同样地，当采用其他的压缩方式时，需要建立与该其他的压缩方式对应的压缩表，不同的压缩方式对应的压缩表中的内容可以是不同的。在上述的协商方式完成之后，两端便可以采用协商的方式进行RTP报文的压缩、解压缩操作了。

在一个可选的实施例中，上述RTP报文的相关信息可以通过如下方式获取：判断接收到的待发送给接收端的报文是否是RTP报文；在判断结果为该报文是RTP报文的情况下，提取上述报文的相关信息作为RTP报文的相关信息。其中，该待发送给接收 端的报文可以是需要发送给接收端的第一个RTP报文，并且，为了避免延时过大，该第一个RTP报文可以不经过压缩直接发送给接收端。

其中，判断报文是否是RTP报文的方式可以有多种判断方式，下面对本发明实施例中提出的判断方法进行说明：判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：判断待发送给接收端的报文是否是UDP报文；当确定该报文是UDP报文后，判断该报文的UDP数据帧的字节数是否大于预定数量(例如，该预定数量为12个字节，即，是否大于RTP报文固定头的长度)，如果大于预定数量，则判断报文的UDP载荷中的预定位(例如，前两位)是否为预定值(例如，0x10，即，是否与现行的RTP版本号相同)；当确定该报文的UDP载荷中的预定位是预定值时，判断报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定该报文的PAYLOAD为RTP的编码格式时，确定该报文是RTP报文。采用本发明实施例中的判断方案，即通过判断编码格式是否是RTP的编码格式来确定报文是否是RTP报文，能够简化判断步骤，提高判断准确度。并且，在后续的过程中，当接收到需要发送给接收端的报文后，也可以按照上述方法判断接收到的报文是否是RTP报文，当确定是时，再对确定是RTP的报文按照上述的实施例中的方法进行压缩，然后，发送压缩后的RTP报文。

执行上述操作的主体可以是发送端，压缩表和解压缩表在建立之后，发送端和接收端也可以对压缩表和解压缩表进行删除或更新操作，在一个可选的实施例中，在将建立的压缩表发送给接收端之后，上述方法还包括：接收携带挂断指令的第一实时传输控制协议RTCP报文；向接收端发送第一通知消息，其中，该第一通知消息用于通知接收端删除解压缩表；在接收到来自上述接收端的成功删除响应后，删除压缩表。其中，该RTCP报文中的特定字段可以被设置为BYE，该被设置为BYE的特定字段可以是上述的挂断指令。

在一个可选的实施例中，在按照预先与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩之后，该方法还包括：在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除上述压缩表；向接收端发送第二通知消息，其中，该第二通知消息用于通知接收端删除解压缩表。其中，在该实施例中，可以在压缩RTP报文失败后即删除压缩表，也可以当压缩RTP报文失败的次数超过预定次数(该预定次数可以大于1)后再删除压缩表，或者，也可以在持续压缩RTP报文失败的时间超过一定值的时候删除压缩表，然后再通知接收端删除解压缩表。

在上述实施例中描述了压缩表和解压缩表的删除是由发送端(即，执行上述操作的一端)触发的，当然，压缩表和解压缩表的删除也可以是由接收端触发的，在一个可选的实施例中，在通过卫星将压缩后的RTP报文传输给接收端之后，该方法还包括：接收来自接收端的用于通知删除压缩表的第三通知消息；根据该第三通知消息删除压缩表。

在一个可选的实施例中，上述第三通知消息可以包括以下至少之一：接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败 的时间超过第二阈值的情况下发送的通知消息；上述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。同样的，接收端在解压缩压缩后的RTP报文失败的情况下发送的通知消息可以是在接收端解压一次失败后即发送的通知消息，也可以是接收端解压失败的次数超过预定次数后发送的通知消息，或者，也可以是接收端在持续解压缩失败的时间超过一定值后发送的通知消息，并且，接收端在发送通知消息之前，可以先删除接收端中的解压缩表。

在上述实施例中，当发送端删除了压缩表、接收端删除了解压缩表后，发送端和接收端可以重新发起协商建立压缩表解压缩表的流程。

在本实施例中还提供了一种报文处理方法，图2是根据本发明实施例的报文处理方法的流程图，如图2所示，该流程包括如下步骤：

步骤S202，接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；

步骤S204，根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。

由上述步骤可知，接收的RTP报文是压缩后的RTP报文，即，发送端在发送RTP报文时，是首先对该RTP报文进行了压缩，然后再发送压缩后的RTP报文，其中，压缩后的RTP报文的大小相对于原始的未压缩的RTP报文的而言，会小很多，这样，便可以减少带宽的占用，从而实现了在一定的带宽上发送更多的RTP报文的目的，提高了带宽的利用率，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。

在一个可选的实施例中，可以通过如下方式与发送端协商上述解压缩方式：接收来自发送端的压缩表；根据该压缩表建立用于解压缩上述压缩后的RTP报文的解压缩表。需要说明的是，上述的压缩表里可以标识采用的是何种压缩方式(例如，可以是ROCH压缩方式或者，CUDP压缩方式)，不同的压缩方式对应的压缩表中的内容可以是不同的。在上述的协商方式完成之后，两端便可以采用协商的方式进行RTP报文的压缩、解压缩操作了。

其中，执行上述操作的主体可以是接收端，压缩表和解压缩表在建立之后，发送端和接收端也可以对压缩表和解压缩表进行删除或更新操作，在一个可选的实施例中，在根据上述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：接收来自发送端的第四通知消息；根据该第四通知消息删除上述解压缩表。

在一个可选的实施例中，上述第四通知消息可以包括以下至少之一：发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。可选地，发送端在压缩RTP报文失 败的情况下发送的通知消息可以是在发送端压缩一次失败后即发送的通知消息，也可以是发送端压缩失败的次数超过预定次数后发送的通知消息，或者，也可以是发送端在持续压缩失败的时间超过一定值后发送的通知消息，并且，发送端在发送通知消息之前，可以先删除发送端中的压缩表；从上述的描述中可知，RTCP报文中可以携带挂断指令，其携带方式可以是在RTCP中预定字段被设置为BYE。

在一个可选的实施例中，当上述第四通知消息包括发送端在接收到携带挂断指令的第一RTCP报文后发送的通知消息时，在根据上述第四通知消息删除解压缩表之后，上述方法还包括：向所述发送端发送成功删除响应，其中，该成功删除响应用于指示发送端删除压缩表。

在上述实施例中描述了压缩表和解压缩表的删除是由发送端触发的，当然，压缩表和解压缩表的删除也可以是由接收端触发的，在一个可选的实施例中，在接收来自发送端的压缩表之后，该方法还包括：接收携带挂断指令的第二实时传输控制协议RTCP报文；向发送端发送第五通知消息，其中，该第五通知消息用于通知发送端删除压缩表；在接收到来自发送端的成功删除响应后，删除上述解压缩表。其中，RTCP报文中携带挂断指令的携带方式可以是在RTCP中预定字段被设置为BYE。

在一个可选的实施例中，在根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文之后，该方法还包括：当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除上述解压缩表，并向发送端发送第六通知消息，其中，该第六通知消息用于通知发送端删除压缩表。其中，在该实施例中，可以在解压缩RTP报文失败后即删除解压缩表，也可以当解压缩RTP报文失败的次数超过预定次数(该预定次数可以大于1)后再删除解压缩表，或者，也可以在持续解压缩RTP报文失败的时间超过一定值的时候删除解压缩表，然后再通知发送端删除压缩表。

在上述实施例中，当发送端删除了压缩表、接收端删除了解压缩表后，发送端和接收端可以重新发起协商建立压缩表解压缩表的流程。

下面以上述的发送端为网关GW1，接收端为网关GW2为例，对本发明的整体流程进行说明：

图3是根据本发明实施例的语音呼叫以及挂断过程的交互流程图，如图3所示，该流程包括如下步骤：

步骤S301，当主叫方的用户设备(User Equipment，简称为UE)(以下简称为UE)需要发起语音呼叫被叫方时，该UE向IP对媒体子系统(IP multimedia subsystem，简称为IMS)发起语音呼叫；

步骤S302，当IMS确定允许UE进行语音呼叫时，向UE返回一个语音呼叫成功的 响应；

步骤S303，UE向UE侧的网关GW1发送语音报文(对应于上述的RTP报文)；

步骤S304，GW1确定压缩方式，并根据该语音报文建立该压缩方式下的压缩表，其建立过程如上述的实施例所述，在此不再陈述；并且，GW1将该语音报文和建立的压缩表发送给被叫侧UE的网关GW2，GW2根据压缩表建立于该压缩表对应的解压缩表；

步骤S305，GW1与GW2建立压缩会话；

步骤S306，GW2向GW1返回建立压缩会话成功消息；

步骤S307，GW2将GW1发送过来的语音报文发送给IMS；

步骤S308，UE向GW1发送语音报文；

步骤S309，GW1对UE发送过来的语音报文按照上述确定的压缩方式进行压缩，并将压缩后的语音报文发送到GW2；

步骤S310，GW2对接收到的压缩的语音报文进行解压缩，并将解压缩后的语音报文发送给IMS；

步骤S311，GW2接收到被叫侧UE发送的语音报文，并且，GW2按照和上述相同的方式和GW1协商压缩解压缩方式；

步骤S312，GW2按照协商的压缩方式压缩被叫侧UE发送的语音报文，并发送给GW1；

步骤S313，GW1对接收的压缩后的来自被叫侧UE的语音报文进行解压缩，并发送给主叫方的UE；

步骤S314，主叫方UE确定需要挂断此次语音通话，会向IMS发送挂断语音呼叫的通知；

步骤S315，GW1通知GW2删除压缩会话；

步骤S316，GW2向GW1返回删除压缩会话成功的消息；

步骤S317，IMS向主叫方UE发送你语音呼叫响应消息，至此，语音通话结束。

下面结合具体应用场景对本发明进行说明：

实施实例1：

图4是根据本发明实施例的卫星通信传输场景示意图，如图4所示，在本实施方案 中使用ROHC压缩(CRTP压缩和ROHC压缩是类似的，在此，以ROHC为例进行说明)的方法对语音报文进行压缩，ROHC通常用于无线通信的空中接口，在本例中用在卫星传输语音压缩的场景。

流程部分的处理步骤如下：

建立连接：

图5是根据本发明实施例的RTP报文的判断流程图，GW1在收到报文后，可以按照图5所示的流程判断是否为RTP报文，其判断流程包括如下步骤：

步骤S501，包过滤模块(该过滤模块可以是发送端或接收端中的一个模块)对所有收到的报文分析；

步骤S502，包过滤模块判断是否是UDP报文，如果是UDP报文，转至步骤S503，否则，转至步骤S512；

步骤S503，判断报文的IP地址(包括源IP地址和目的IP地址)和端口号(包括UDP源端口和UDP目的端口)是否能在ROHC压缩解压缩实例中查找到，如果能查找到，则认为是已建立好的压缩会话，转至步骤S510，否则，转至步骤S504；

步骤S504，判断UDP数据帧是否大于12个字节，如果判断结果为大于12个字节，则转至步骤S505，否则，转至步骤S512；

步骤S505，判断UDP载荷前两位是否为0x10(RTP/RTCP为2)，如果是转至步骤S506，否则，转至部署S512；

步骤S506，判断PAYLOAD载荷是否为RTP或RTCP的编码格式，判断结果为是，转至步骤S506，否则，转至步骤S512；

步骤S507，判断一个会话中同步信源标识符SSRC是否不变，判断结果为是，转至步骤S508，否则，转至步骤S512；

步骤S508，循环判断3次，判断SSRC是否一致，若为是，转至步骤S509，否则，转至步骤S512；

步骤S509，连续3次条件都满足，则判断认为是RTP或者RTCP报文，如果是RTP报文跳转到步骤S511；

步骤S510，压缩报文；

步骤S511，记录IP地址UDP端口号RTP头中的SSRC标识，创建ROHC压缩解压缩实例，构造一个报文，将上面记录的信息按照图6所示的格式(当采用CRTP压缩时，格式与图6所示类似，区别在于标识需要采用CRTP标识)封装后发送到GW2，其中，图6是根据本发明实施例的ROHC自定义协商报文封装格式示意图，GW2在收 到后根据发过来的信息，创建压缩解压缩实例，同时按照图6的格式回复GW1，转步骤S513；

步骤S512，确定不是RTP和RTCP报文，继续对接收到的报文进行检测；

步骤S513，GW1收到后启用ROHC压缩，包过滤模块在收到RTP报文后在ROHC压缩实例表中查找是否有对应的表项，如果有，则开始对RTP报文开始压缩，基于ROHC实例创建压缩解压缩会话，压缩RTP报文，包括IP头+UDP头+RTP头，GW2处理类似GW1网关操作。

其中，上述的步骤S507-S509是可选的，当针对单一的报文进行判断时，可以不用进行循环3次的判断。

下面对连接关闭进行说明：

GW1或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的ROHC压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号、SSRC标识查找ROHC压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图6的格式通知对方删除对应的压缩解压缩会话。

下面对异常保护进行说明：

GW1或者GW2连续一段时间内ROHC解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。

实施实例2：

图7是根据本发明实施例的UE直接接入卫星通信场景。下面以上述UE为手机为例，对本发明进行说明。

在本实施方案中同样使用ROHC压缩(同样地，也可以采用CRTP压缩方式，在该实施例中，以ROHC压缩方式为例进行说明)的方法对语音报文进行压缩，手机和GW2上驻留压缩和包过滤模块。

下面对连接建立过程进行说明：

步骤S1，手机通过卫星接入后，通过网络发起语音呼叫后，包过滤模块监听到手机发送的报文是RTP语音报文；

步骤S2，压缩模块记录IP地址UDP端口号RTP头中的SSRC标识，创建ROHC压缩解压缩实例，构造一个报文，将上面记录的信息按照图5的格式封装后发送到GW2，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图6的格式回复给手机；

步骤S3，手机收到来自GW2的创建压缩解压缩成功的消息后，启动ROHC压缩，转到S4；

步骤S4，GW2或者手机上包过滤模块在监听到发送的RTP语音报文时，则在ROHC压缩实例表中查找是否有对应的表项，如果有则开始对RTP报文开始压缩，基于ROHC实例创建压缩解压缩会话，压缩RTP报文头，包括IP头+UDP头+RTP头。

下面对连接关闭进行说明：

手机或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的ROHC压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号、SSRC标识查找ROHC压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图6的格式通知对方删除对应的压缩解压缩会话。

下面对异常保护进行说明：

手机或者GW2连续一段时间内ROHC解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。

实施实例3：

该实施例以图4所示的卫星通信场景为例进行说明：

在本实施方案中使用CUDP压缩的方法对语音报文进行压缩，GW1和GW2上驻留压缩和包过滤模块。

下面对建立连接过程进行说明：

步骤S1，GW1在收到报文后按照图5所示的流程判断是否为RTP报文，包过滤模块对所有收到的报文分析，先判断是否UDP报文，如果是UDP报文，判断IP地址和端口号是否能在CUDP压缩解压缩实例中查找到，如果能查找到，则认为是已建立好的压缩会话，如果查找不到则继续判断UDP数据帧是否大于12个字节，如果是判断UDP载荷前两位是否为0x10(RTP/RTCP为2)，如果是判断PAYLOAD载荷是否为RTP或RTCP的编码格式，循环判断3次，判断SSRC是否一致，连续3次条件都满足，则判断认为是RTP或者RTCP报文，如果是RTP报文跳转到第二步；

S2，记录IP地址UDP端口号，创建CUDP压缩解压缩通道表，构造一个报文，将上面记录的信息按照图8的格式封装后发送到GW2，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图8的格式回复GW1，其中，图8是根据本发明实施例的CUDP自定义协商报文封装格式示意图；

S3，GW1收到后启用CUDP压缩，包过滤模块在收到RTP报文后在CUDP压缩通 道表中查找是否有对应的表项，如果有则开始对RTP报文开始压缩，压缩RTP报文，GW2处理类似GW1网关操作。

下面对连接关闭进行说明：

GW1或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的CUDP压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号查找CUDP压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图8的格式通知对方删除对应的压缩解压缩会话。

下面对异常保护进行说明：

GW1或者GW2连续一段时间内CUDP解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

在本实施例中还提供了一种报文处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图9是根据本发明实施例的第一种报文处理装置的结构框图，如图9所示，该装置包括压缩模块92和第一发送模块94，下面对该装置进行说明。

压缩模块92，用于按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；第一发送模块94，连接至上述压缩模块92，用于在压缩成功后，通过卫星将压缩后的RTP报文发送给接收端。

图10是根据本发明实施例的第一种报文处理装置的优选结构框图一，如图10所示，该装置除包括图9所示的所有模块外，还包括第一协商模块102，下面对该装置进行说明。

第一协商模块102，连接至上述压缩模块92，用于通过如下方式与接收端协商上述压缩方式：根据待发送给接收端的RTP报文的相关信息建立压缩表，其中，该压缩表中携带当前选择的压缩方式的标识和RTP报文的相关信息，当该当前选择的压缩方式 为可靠头压缩ROCH或配置压缩实时协议CRTP时，上述相关信息包括RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当上述压缩方式为配置压缩用户数据协议CUDP时，上述相关信息包括RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的上述压缩表发送给接收端，其中，该压缩表用于指示接收端建立与压缩表对应的解压缩表。

图11是根据本发明实施例的第一种报文处理装置中第一协商模块102的结构框图，如图11所示，在获取RTP报文的相关信息时，该第一协商模块102包括判断单元112和提取单元114，下面对该第一协商模块102进行说明。

判断单元112，用于判断接收到的待发送给接收端的报文是否是RTP报文；提取单元114，连接至上述判断单元112，用于在判断结果为报文是RTP报文的情况下，提取报文的相关信息作为RTP报文的相关信息。

在一个可选的实施例中，上述判断单元112可以通过如下方式判断接收到的待发送给接收端的报文是否是RTP报文：判断待发送给接收端的报文是否是UDP报文；当确定上述报文是UDP报文后，判断报文的UDP数据帧的字节数是否大于预定数量，如果大于预定数量，则判断报文的UDP载荷中的预定位是否为预定值；当确定报文的UDP载荷中的预定位是预定值时，判断报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定该报文的PAYLOAD为RTP的编码格式时，确定该报文是RTP报文。

图12是根据本发明实施例的第一种报文处理装置的优选结构框图二，如图12所示，该装置除包括图10所示的所有模块外，还包括第一接收模块122、第二发送模块124和第一删除模块126，下面对该装置进行说明。图12仅是一种示例，第一接收模块122还可以连接至上述压缩模块92。

第一接收模块122，连接至上述第一发送模块94，用于在将建立的压缩表发送给接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；第二发送模块124，连接至上述第一接收模块122，用于向接收端发送第一通知消息，其中，该第一通知消息用于通知接收端删除解压缩表；第一删除模块126，连接至上述第二发送模块124，用于在接收到来自接收端的成功删除响应后，删除上述压缩表。

图13是根据本发明实施例的第一种报文处理装置的优选结构框图三，如图13所示，该装置除包括图10所示的所有模块外，还包括第二删除模块132和第三发送模块134，下面对该装置进行说明。图13仅是一种示例，第二删除模块132还可以连接至上述压缩模块92。

第二删除模块132，连接至上述第一发送模块94，用于在按照预先与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除上述压缩表； 第三发送模块134，连接至上述第二删除模块132，用于向接收端发送第二通知消息，其中，该第二通知消息用于通知接收端删除上述解压缩表。

图14是根据本发明实施例的第一种报文处理装置的优选结构框图四，如图14所示，该装置除包括图10所示的所有模块外，还包括第二接收模块142和第三删除模块144，下面对该装置进行说明。图14仅是一种示例，第二接收模块142还可以连接至上述压缩模块92。

第二接收模块142，连接至上述第一发送模块94，用于在通过卫星将压缩后的RTP报文传输给接收端之后，接收来自上述接收端的用于通知删除压缩表的第三通知消息；第三删除模块144，连接至上述第二接收模块142，用于根据上述第三通知消息删除压缩表。

在一个可选的实施例中，上述第三通知消息包括以下至少之一：接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。

在一个可选的实施例中，上述报文处理装置位于第一网关或终端中，接收端包括第二网关；或者，上述报文处理装置位于第二网关中，接收端包括第一网关或终端。

在本发明实施例中还提供了一种报文处理装置，图15是根据本发明实施例的第二种报文处理装置的结构框图，如图15所示，该装置包括第三接收模块152和解压缩模块154，下面对该装置进行说明。

第三接收模块152，用于接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；解压缩模块154，连接至上述第三接收模块152，用于根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。

图16是根据本发明实施例的第二种报文处理装置的优选结构框图一，如图16所示，该装置除包括图15所示的所有模块外，还包括第二协商模块162，下面对该装置进行说明。

第二协商模块162，连接至上述解压缩模块154，用于通过如下方式与发送端协商解压缩方式：接收来自发送端的压缩表；根据上述压缩表建立用于解压缩压缩后的RTP报文的解压缩表。

图17是根据本发明实施例的第二种报文处理装置的优选结构框图二，如图17所示，该装置除包括图16所示的所有模块外，还包括第四接收模块172和第四删除模块174，下面对该装置进行说明。图17仅是一种示例，第四接收模块172还可以连接至上述第二协商模块162。

第四接收模块172，连接至上述解压缩模块154，用于在根据上述压缩表建立用于 解压缩压缩后的RTP报文的所述解压缩表之后，接收来自发送端的第四通知消息；第四删除模块174，连接至上述第四接收模块172，用于根据上述第四通知消息删除解压缩表。

在一个可选的实施例中，上述第四通知消息包括以下至少之一：发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；上述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。

图18是根据本发明实施例的第二种报文处理装置的优选结构框图三，如图18所示，当上述第四通知消息包括发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，上述装置还包括第四发送模块182，下面对该装置进行说明。

第四发送模块182，连接至上述第四删除模块174，用于在根据上述第四通知消息删除解压缩表之后，向发送端发送成功删除响应，其中，该成功删除响应用于指示发送端删除压缩表。

图19是根据本发明实施例的第二种报文处理装置的优选结构框图四，如图19所示，该装置除包括图16所示的模块外，还包括第五接收模块192、第五发送模块194和第五删除模块196，下面对该装置进行说明。图19仅是一种示例，第五接收模块192还可以连接至上述第二协商模块162。

第五接收模块192，连接至上述解压缩模块154，用于在接收来自发送端的压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；第五发送模块194，连接至上述第五接收模块192，用于向发送端发送第五通知消息，其中，该第五通知消息用于通知发送端删除压缩表；第五删除模块196，连接至上述第五发送模块194，用于在接收到来自上述发送端的成功删除响应后，删除解压缩表。

图20是根据本发明实施例的第二种报文处理装置的优选结构框图五，如图20所示，该装置除包括图16所示的模块外，还包括处理模块202，下面对该装置进行说明。图20仅是一种示例，处理模块202还可以连接至上述第二协商模块162。

处理模块202，连接至上述压缩模块154，用于在根据与发送端协商的解压缩方式解压缩压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除上述解压缩表，并向发送端发送第六通知消息，其中，该第六通知消息用于通知发送端删除压缩表。

在一个可选的实施例中，上述报文处理装置位于第二网关中，发送端包括第一网关或终端；或者，上述报文处理装置位于第一网关或终端中，发送端包括第二网关。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通 过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

S11，按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；

S12，在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S21，接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；

S22，根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(RandomAccess Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述各实施例中的各个步骤。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

采用本发明实施例中的方法和装置，与现有技术相比，能够节省一半以上的语音占用带宽。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。