技术领域technical field
本发明涉及通信领域，具体而言，涉及一种报文处理方法及装置。The present invention relates to the communication field, in particular to a method and device for processing a message.
背景技术Background technique
在海上与陆地上的大部分区域是蜂窝式移动通讯系统的信号所不能覆盖，因此，作为一种有效的补充手段，卫星通讯被广泛地应用在上述的海上区域以及陆地上的大部分区域中，尤其是应用于远洋运输、钻探、勘测以及渔业等部门。卫星通信具有不受时间、地点、环境等多种因素的限制，开通时间短、传输距离远、网络部署快、通信成本与通信距离无关等诸多优点，可以实语音和数据的实时双向传输。Most of the sea and land areas are not covered by the signal of the cellular mobile communication system. Therefore, as an effective supplementary means, satellite communication is widely used in the above-mentioned sea areas and most of the land areas. , especially in ocean transportation, drilling, surveying and fisheries. Satellite communication has many advantages such as not being limited by time, place, environment and other factors, short opening time, long transmission distance, fast network deployment, communication cost independent of communication distance, etc., and can realize real-time two-way transmission of voice and data.
其中，卫星电话是现有实现卫星通信的一种，由于卫星信道具有与地面信道不同的一些特点，而传输控制协议(Transfer Control Protocol，简称为TCP)/互联网协议(InternetProtocol，简称为IP)协议当初是为地面网络设计的，所以TCP/IP协议在卫星信道上的传输性能比较差。存在以下问题：Among them, the satellite phone is a kind of existing satellite communication, because the satellite channel has some characteristics different from the terrestrial channel, and the Transmission Control Protocol (Transfer Control Protocol, referred to as TCP)/Internet Protocol (Internet Protocol, referred to as IP) protocol It was originally designed for terrestrial networks, so the transmission performance of the TCP/IP protocol on satellite channels is relatively poor. The following problems exist:
1)一方面延迟大，卫星信道的延时很长，典型的卫星通信延时在540ms左右，这会造成TCP协议的不停的重传，引起通信链路的拥塞。另一方面实际的卫星通信中有很高的误码，而TCP协议不能区分出是网络阻塞造成的数据丢失或是误码造成的数据丢失，TCP协议会一律认为是网络阻塞造成的，从而降低TCP的发送窗口，引起传输的带宽下降；1) On the one hand, the delay is large, and the delay of the satellite channel is very long. The typical satellite communication delay is about 540ms, which will cause the non-stop retransmission of the TCP protocol and cause the congestion of the communication link. On the other hand, there are high bit errors in actual satellite communication, and the TCP protocol cannot distinguish between data loss caused by network congestion or data loss caused by bit errors. The TCP protocol will always consider it caused by network congestion, thereby reducing The sending window of TCP causes the bandwidth of transmission to drop;
2)卫星通信带宽低且租用费用昂贵，基于网络协议的语音传输(Voice over InternetProtocol，简称为VOIP)采用不同的编码格式时，需要不同的数据带宽，比如采用G729需要带宽8Kbps，而一个报文头(实时传输协议(Real-time Transport Protocol，简称为RTP)+用户数据协议(User Date Protocol，简称为UDP)+IP头)就占了16K bps，所以一路VOIP电话就需要占用24Kbps的带宽，这对于卫星通信来说是资源极大的浪费。2) The bandwidth of satellite communication is low and the rental fee is expensive. When the voice transmission based on network protocol (Voice over Internet Protocol, referred to as VOIP) adopts different encoding formats, different data bandwidths are required. For example, G729 requires a bandwidth of 8Kbps, and a message Header (Real-time Transport Protocol (Real-time Transport Protocol, referred to as RTP) + User Data Protocol (User Date Protocol, referred to as UDP) + IP header) occupies 16K bps, so a VOIP call needs to occupy 24Kbps of bandwidth, This is a huge waste of resources for satellite communications.
因此，在相关技术中，存在着语音通信在卫星通讯领域上的带宽利用率不足的问题，而针对该问题，目前尚未提出有效的解决方案。Therefore, in the related art, there is a problem of insufficient bandwidth utilization of voice communication in the field of satellite communication, and no effective solution has been proposed for this problem at present.
发明内容Contents of the invention
本发明提供了一种报文处理方法及装置，以至少解决相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题。The present invention provides a message processing method and device to at least solve the problem of insufficient bandwidth utilization of voice communication in the field of satellite communication in the related art.
根据本发明的一个方面，提供了一种报文处理方法，包括：按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。According to one aspect of the present invention, a message processing method is provided, including: compressing the real-time transport protocol RTP message to be sent to the receiving end according to the compression method negotiated with the receiving end; The compressed RTP message is sent to the receiving end.
可选地，通过如下方式与所述接收端协商所述压缩方式：根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。Optionally, the compression method is negotiated with the receiving end in the following manner: a compression table is established according to the relevant information of the RTP message to be sent to the receiving end, wherein the compression table carries the information of the currently selected compression method Identification and related information of the RTP message, when the currently selected compression method is reliable header compression ROCH or configuration compressed real-time protocol CRTP, the related information includes the source Internet Protocol IP address and destination of the RTP message IP address, user data protocol UDP source port, UDP destination port, and RTP header; or, when the compression method is configured to compress the user data protocol CUDP, the relevant information includes the source IP address of the RTP message, the destination IP Address, UDP source port and UDP destination port; sending the established compression table to the receiving end, wherein the compression table is used to instruct the receiving end to establish a decompression table corresponding to the compression table.
可选地，所述RTP报文的相关信息通过如下方式获取：判断接收到的待发送给所述接收端的报文是否是RTP报文；在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。Optionally, the relevant information of the RTP message is obtained by: judging whether the received message to be sent to the receiving end is an RTP message; Next, extract the relevant information of the message as the relevant information of the RTP message.
可选地，判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：判断待发送给所述接收端的所述报文是否是UDP报文；当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。Optionally, judging whether the received message to be sent to the receiving end is an RTP message includes: judging whether the message to be sent to the receiving end is a UDP message; After being a UDP message, judge whether the number of bytes of the UDP data frame of the message is greater than a predetermined quantity, if greater than the predetermined quantity, then judge whether the predetermined bit in the UDP load of the message is a predetermined value; when When determining that the predetermined bit in the UDP load of the message is a predetermined value, judge whether the encoding format of the payload PAYLOAD of the message is the encoding format of RTP; when determining that the PAYLOAD of the message is the encoding format of RTP , determining that the packet is an RTP packet.
可选地，在将建立的所述压缩表发送给所述接收端之后，所述方法还包括：接收携带挂断指令的第一实时传输控制协议RTCP报文；向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；在接收到来自所述接收端的成功删除响应后，删除所述压缩表。Optionally, after sending the established compressed table to the receiving end, the method further includes: receiving a first real-time transport control protocol RTCP message carrying a hangup instruction; sending the first real-time transport control protocol message to the receiving end A notification message, wherein the first notification message is used to notify the receiving end to delete the decompression table; after receiving a successful deletion response from the receiving end, delete the compression table.
可选地，在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，所述方法还包括：在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值时，删除所述压缩表；向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。Optionally, after compressing the RTP message to be sent to the receiving end according to the compression method pre-negotiated with the receiving end, the method further includes: when the number of failures to compress the RTP message exceeds the first threshold and/or Or when the time for continuously compressing RTP packets fails to exceed a second threshold, delete the compression table; send a second notification message to the receiving end, wherein the second notification message is used to notify the receiving end to delete the Unzip the table.
可选地，在通过卫星将压缩后的RTP报文传输给所述接收端之后，所述方法还包括：接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；根据所述第三通知消息删除所述压缩表。Optionally, after transmitting the compressed RTP message to the receiving end via the satellite, the method further includes: receiving a third notification message from the receiving end for notifying deletion of the compressed table; according to the The third notification message deletes the compressed table.
可选地，所述第三通知消息包括以下至少之一：所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。Optionally, the third notification message includes at least one of the following: the number of failures of the receiving end to decompress the compressed RTP packets exceeds the first threshold and/or the number of consecutive failures to decompress the compressed RTP packets A notification message sent when the time exceeds the second threshold; a notification message sent by the receiving end after receiving the second real-time transport control protocol RTCP message carrying a hangup instruction.
根据本发明的另一方面，提供了一种报文处理方法，包括：接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。According to another aspect of the present invention, a message processing method is provided, including: receiving the compressed real-time transport protocol RTP message sent by the sending end through the satellite; decompressing the RTP message according to the decompression method negotiated with the sending end Describe the compressed RTP packet.
可选地，通过如下方式与所述发送端协商所述解压缩方式：接收来自所述发送端的压缩表；根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。Optionally, negotiating the decompression method with the sending end in the following manner: receiving a compression table from the sending end; establishing a decompression table for decompressing the compressed RTP message according to the compression table .
可选地，在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：接收来自所述发送端的第四通知消息；根据所述第四通知消息删除所述解压缩表。Optionally, after establishing the decompression table for decompressing the compressed RTP message according to the compression table, the method further includes: receiving a fourth notification message from the sending end; The fourth notification message deletes the decompression table.
可选地，所述第四通知消息包括以下至少之一：所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。Optionally, the fourth notification message includes at least one of the following: the sending end fails to compress the RTP packets to be sent more than the first threshold and/or fails to continuously compress the RTP packets to be sent A notification message sent when the time exceeds the second threshold; a notification message sent by the sender after receiving the first real-time transport control protocol RTCP message carrying a hangup instruction.
可选地，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，在根据所述第四通知消息删除所述解压缩表之后，所述方法还包括：向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。Optionally, when the fourth notification message includes a notification message sent by the sender after receiving the first RTCP packet carrying a hangup instruction, after deleting the solution according to the fourth notification message, After the table is compressed, the method further includes: sending a successful deletion response to the sender, wherein the successful deletion response is used to instruct the sender to delete the compressed table.
可选地，在接收来自所述发送端的所述压缩表之后，所述方法还包括：接收携带挂断指令的第二实时传输控制协议RTCP报文；向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。Optionally, after receiving the compression table from the sending end, the method further includes: receiving a second real-time transport control protocol RTCP message carrying a hangup instruction; sending a fifth notification message to the sending end, Wherein, the fifth notification message is used to notify the sending end to delete the compression table; after receiving a successful deletion response from the sending end, delete the decompression table.
可选地，在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，所述方法还包括：当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。Optionally, after decompressing the compressed RTP message according to the decompression mode negotiated with the sending end, the method further includes: when the number of failures to decompress the compressed RTP message exceeds the first After a threshold and/or the failure time of continuous decompression of compressed RTP packets exceeds a second threshold, delete the decompression table, and send a sixth notification message to the sender, wherein the sixth notification message It is used to notify the sending end to delete the compression table.
根据本发明的另一方面，提供了一种报文处理装置，包括：压缩模块，用于按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；第一发送模块，用于在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。According to another aspect of the present invention, a message processing device is provided, including: a compression module, configured to compress the real-time transport protocol RTP message to be sent to the receiving end according to the compression mode negotiated with the receiving end; the first The sending module is configured to send the compressed RTP message to the receiving end through the satellite after the compression is successful.
可选地，所述装置还包括第一协商模块，用于通过如下方式与所述接收端协商所述压缩方式：根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。Optionally, the device further includes a first negotiation module, configured to negotiate the compression mode with the receiving end in the following manner: establish a compression table according to relevant information of the RTP message to be sent to the receiving end, wherein, The compression table carries the identifier of the currently selected compression method and the relevant information of the RTP message. When the currently selected compression method is reliable header compression ROCH or configuration compressed real-time protocol CRTP, the relevant information includes the The source Internet protocol IP address of the RTP message, the destination IP address, the user data protocol UDP source port, the UDP destination port and the RTP header; or, when the compression method is configured to compress the user data protocol CUDP, the relevant information includes The source IP address, destination IP address, UDP source port, and UDP destination port of the RTP message; sending the established compression table to the receiving end, wherein the compression table is used to instruct the receiving end to establish The decompression table corresponding to the compression table.
可选地，在获取所述RTP报文的相关信息时，所述第一协商模块包括：判断单元，用于判断接收到的待发送给所述接收端的报文是否是RTP报文；提取单元，用于在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。Optionally, when obtaining the relevant information of the RTP message, the first negotiation module includes: a judging unit, configured to judge whether the received message to be sent to the receiving end is an RTP message; an extracting unit is used for extracting the relevant information of the message as the relevant information of the RTP message when the judging result is that the message is an RTP message.
可选地，所述判断单元通过如下方式判断接收到的待发送给所述接收端的报文是否是RTP报文：判断待发送给所述接收端的所述报文是否是UDP报文；当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。Optionally, the judging unit judges whether the received message to be sent to the receiving end is an RTP message in the following manner: judging whether the message to be sent to the receiving end is a UDP message; After the message is a UDP message, judge whether the number of bytes of the UDP data frame of the message is greater than a predetermined number, if greater than the predetermined number, then judge whether the predetermined bit in the UDP load of the message is Predetermined value; when it is determined that the predetermined bit in the UDP load of the message is a predetermined value, judge whether the encoding format of the payload PAYLOAD of the message is the encoding format of RTP; when determining that the PAYLOAD of the message is RTP When the encoding format is used, it is determined that the packet is an RTP packet.
可选地，所述装置还包括：第一接收模块，用于在将建立的所述压缩表发送给所述接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；第二发送模块，用于向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；第一删除模块，用于在接收到来自所述接收端的成功删除响应后，删除所述压缩表。Optionally, the device further includes: a first receiving module, configured to receive a first real-time transport control protocol RTCP message carrying a hangup instruction after sending the established compressed table to the receiving end; Two sending modules, configured to send a first notification message to the receiving end, wherein the first notification message is used to notify the receiving end to delete the decompression table; the first deleting module is configured to receive the message from After the successful delete response of the receiving end, delete the compressed table.
可选地，所述装置还包括：第二删除模块，用于在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除所述压缩表；第三发送模块，用于向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。Optionally, the device further includes: a second deletion module, configured to compress the RTP message to be sent to the receiving end according to a compression method pre-negotiated with the receiving end, and fail to compress the RTP message After the number of times exceeds the first threshold and/or the time of continuous RTP message compression exceeds the second threshold, delete the compression table; the third sending module is configured to send a second notification message to the receiving end, wherein the The second notification message is used to notify the receiving end to delete the decompression table.
可选地，所述装置还包括：第二接收模块，用于在通过卫星将压缩后的RTP报文传输给所述接收端之后，接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；第三删除模块，用于根据所述第三通知消息删除所述压缩表。Optionally, the device further includes: a second receiving module, configured to receive a message from the receiving end for notifying to delete the compressed table after the compressed RTP message is transmitted to the receiving end through the satellite. A third notification message; a third deletion module, configured to delete the compression table according to the third notification message.
可选地，所述第三通知消息包括以下至少之一：所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。Optionally, the third notification message includes at least one of the following: the number of failures of the receiving end to decompress the compressed RTP packets exceeds the first threshold and/or the number of consecutive failures to decompress the compressed RTP packets A notification message sent when the time exceeds the second threshold; a notification message sent by the receiving end after receiving the second real-time transport control protocol RTCP message carrying a hangup instruction.
可选地，所述报文处理装置位于第一网关或终端中，所述接收端包括第二网关；或者，所述报文处理装置位于第二网关中，所述接收端包括第一网关或终端。Optionally, the message processing device is located in the first gateway or terminal, and the receiving end includes a second gateway; or, the message processing device is located in the second gateway, and the receiving end includes the first gateway or terminal.
根据本发明的另一方面，提供了一种报文处理装置，包括：第三接收模块，用于接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；解压缩模块，用于根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。According to another aspect of the present invention, a message processing device is provided, including: a third receiving module, used to receive the compressed real-time transport protocol RTP message sent by the sending end through the satellite; The compressed RTP packet is decompressed by the decompression mode negotiated with the sending end.
可选地，所述装置还包括第二协商模块，用于通过如下方式与所述发送端协商所述解压缩方式：接收来自所述发送端的压缩表；根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。Optionally, the device further includes a second negotiation module, configured to negotiate the decompression mode with the sending end in the following manner: receive a compression table from the sending end; establish a decompression method according to the compression table The decompression table of the compressed RTP message.
可选地，所述装置还包括：第四接收模块，用于在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，接收来自所述发送端的第四通知消息；第四删除模块，用于根据所述第四通知消息删除所述解压缩表。Optionally, the device further includes: a fourth receiving module, configured to, after establishing the decompression table for decompressing the compressed RTP message according to the compression table, receive the A fourth notification message; a fourth deletion module, configured to delete the decompression table according to the fourth notification message.
可选地，所述第四通知消息包括以下至少之一：所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。Optionally, the fourth notification message includes at least one of the following: the sending end fails to compress the RTP packets to be sent more than the first threshold and/or fails to continuously compress the RTP packets to be sent A notification message sent when the time exceeds the second threshold; a notification message sent by the sender after receiving the first real-time transport control protocol RTCP message carrying a hangup instruction.
可选地，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，所述装置还包括：第四发送模块，用于在根据所述第四通知消息删除所述解压缩表之后，向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。Optionally, when the fourth notification message includes a notification message sent by the sending end after receiving the first RTCP message carrying a hangup instruction, the device further includes: a fourth sending module configured to After deleting the decompression table according to the fourth notification message, send a successful deletion response to the sending end, where the successful deletion response is used to instruct the sending end to delete the compression table.
可选地，所述装置还包括：第五接收模块，用于在接收来自所述发送端的所述压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；第五发送模块，用于向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；第五删除模块，用于在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。Optionally, the device further includes: a fifth receiving module, configured to receive a second real-time transport control protocol RTCP message carrying a hangup instruction after receiving the compressed table from the sending end; the fifth sending module , used to send a fifth notification message to the sender, wherein the fifth notification message is used to notify the sender to delete the compression table; the fifth deletion module is configured to receive the message from the sender After successfully deleting the response, delete the unpacked table.
可选地，所述装置还包括：处理模块，用于在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。Optionally, the device further includes: a processing module, configured to decompress the compressed RTP message according to the decompression manner negotiated with the sending end, and decompress the compressed RTP message After the number of failures exceeds the first threshold and/or the failure time of continuous decompression of compressed RTP packets exceeds the second threshold, delete the decompression table, and send a sixth notification message to the sender, wherein the The sixth notification message is used to notify the sender to delete the compression table.
可选地，所述报文处理装置位于第二网关中，所述发送端包括第一网关或终端；或者，所述报文处理装置位于第一网关或终端中，所述发送端包括第二网关。Optionally, the message processing device is located in the second gateway, and the sending end includes the first gateway or terminal; or, the message processing device is located in the first gateway or terminal, and the sending end includes the second gateway.
通过本发明，采用按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。Through the present invention, the real-time transport protocol RTP message to be sent to the receiving end is compressed according to the compression mode negotiated with the receiving end; after the compression is successful, the compressed RTP message is sent to the receiving end through the satellite. The problem of insufficient bandwidth utilization of voice communication in the field of satellite communication existing in the related art is solved, thereby achieving the effect of improving the bandwidth utilization of voice communication in the field of satellite communication and saving bandwidth resources.
附图说明Description of drawings
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：The accompanying drawings described here are used to provide a further understanding of the present invention and constitute a part of the application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations to the present invention. In the attached picture:
图1是根据本发明实施例的报文处理方法的流程图；Fig. 1 is a flowchart of a message processing method according to an embodiment of the present invention;
图2是根据本发明实施例的报文处理方法的流程图；Fig. 2 is a flowchart of a message processing method according to an embodiment of the present invention;
图3是根据本发明实施例的语音呼叫以及挂断过程的交互流程图；FIG. 3 is an interactive flowchart of a voice call and a hang-up process according to an embodiment of the present invention;
图4是根据本发明实施例的卫星通信传输场景示意图；FIG. 4 is a schematic diagram of a satellite communication transmission scenario according to an embodiment of the present invention;
图5是根据本发明实施例的RTP报文的判断流程图；Fig. 5 is the judgment flowchart of the RTP message according to the embodiment of the present invention;
图6是根据本发明实施例的ROHC自定义协商报文封装格式示意图；FIG. 6 is a schematic diagram of an encapsulation format of an ROHC custom negotiation message according to an embodiment of the present invention;
图7是根据本发明实施例的UE直接接入卫星通信场景；FIG. 7 is a scenario where UE directly accesses satellite communication according to an embodiment of the present invention;
图8是根据本发明实施例的CUDP自定义协商报文封装格式示意图；8 is a schematic diagram of a CUDP custom negotiation message encapsulation format according to an embodiment of the present invention;
图9是根据本发明实施例的第一种报文处理装置的结构框图；FIG. 9 is a structural block diagram of a first packet processing device according to an embodiment of the present invention;
图10是根据本发明实施例的第一种报文处理装置的优选结构框图一；FIG. 10 is a preferred structural block diagram 1 of a first message processing device according to an embodiment of the present invention;
图11是根据本发明实施例的第一种报文处理装置中第一协商模块102的结构框图；FIG. 11 is a structural block diagram of the first negotiation module 102 in the first packet processing device according to an embodiment of the present invention;
图12是根据本发明实施例的第一种报文处理装置的优选结构框图二；FIG. 12 is a second preferred structural block diagram of the first packet processing device according to an embodiment of the present invention;
图13是根据本发明实施例的第一种报文处理装置的优选结构框图三；FIG. 13 is a third preferred structural block diagram of the first packet processing device according to an embodiment of the present invention;
图14是根据本发明实施例的第一种报文处理装置的优选结构框图四；FIG. 14 is a fourth preferred structural block diagram of the first packet processing device according to an embodiment of the present invention;
图15是根据本发明实施例的第二种报文处理装置的结构框图；Fig. 15 is a structural block diagram of a second packet processing device according to an embodiment of the present invention;
图16是根据本发明实施例的第二种报文处理装置的优选结构框图一；FIG. 16 is a preferred structural block diagram 1 of a second message processing device according to an embodiment of the present invention;
图17是根据本发明实施例的第二种报文处理装置的优选结构框图二；FIG. 17 is a second preferred structural block diagram of a second packet processing device according to an embodiment of the present invention;
图18是根据本发明实施例的第二种报文处理装置的优选结构框图三；FIG. 18 is a third preferred structural block diagram of a second packet processing device according to an embodiment of the present invention;
图19是根据本发明实施例的第二种报文处理装置的优选结构框图四；FIG. 19 is a fourth preferred structural block diagram of a second packet processing device according to an embodiment of the present invention;
图20是根据本发明实施例的第二种报文处理装置的优选结构框图五。Fig. 20 is a fifth preferred structural block diagram of a second packet processing apparatus according to an embodiment of the present invention.
具体实施方式detailed description
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。Hereinafter, the present invention will be described in detail with reference to the drawings and examples. It should be noted that, in the case of no conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。It should be noted that the terms "first" and "second" in the description and claims of the present invention and the above drawings are used to distinguish similar objects, but not necessarily used to describe a specific sequence or sequence.
在本实施例中提供了一种报文处理方法，图1是根据本发明实施例的报文处理方法的流程图，如图1所示，该流程包括如下步骤：A method for processing a message is provided in this embodiment. FIG. 1 is a flowchart of a method for processing a message according to an embodiment of the present invention. As shown in FIG. 1 , the process includes the following steps:
步骤S102，按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；Step S102, compressing the real-time transport protocol RTP message to be sent to the receiving end according to the compression method negotiated with the receiving end;
步骤S104，在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。Step S104, after the compression is successful, the compressed RTP message is sent to the receiving end through the satellite.
从上述步骤可知，在向接收端发送RTP报文时，是首先对该RTP报文进行了压缩(由于RTP报文的报文头会占用较大的带宽，对RTP报文进行压缩时，可以仅对RTP报文的IP头、UDP头和RTP头进行压缩)，然后将压缩后的RTP报文发送给了接收端，其中，压缩后的RTP报文的大小相对于原始的未压缩的RTP报文的而言，会小很多，这样，便可以减少带宽的占用，从而实现了在一定的带宽上发送更多的RTP报文的目的，提高了带宽的利用率，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。As can be seen from the above steps, when the RTP message is sent to the receiving end, the RTP message is first compressed (because the message header of the RTP message will occupy a large bandwidth, when the RTP message is compressed, it can Only the IP header, UDP header and RTP header of the RTP message are compressed), and then the compressed RTP message is sent to the receiving end, wherein the size of the compressed RTP message is relative to the original uncompressed RTP As far as the message is concerned, it will be much smaller. In this way, the occupation of bandwidth can be reduced, thereby realizing the purpose of sending more RTP messages on a certain bandwidth, improving the utilization rate of bandwidth, and solving the problems existing in related technologies. The problem of insufficient bandwidth utilization of voice communication in the field of satellite communication, and then achieve the effect of improving the bandwidth utilization of voice communication in the field of satellite communication and saving bandwidth resources.
在一个可选的实施例中，可以通过如下方式与接收端协商压缩方式：根据待发送给接收端的RTP报文的相关信息建立压缩表，其中，该压缩表中携带当前选择的压缩方式的标识和上述RTP报文的相关信息，当该当前选择的压缩方式为可靠头压缩(RobustHeader Compression，简称为ROCH)或配置压缩实时协议(Configuring CompressedReal-Time Protocol，简称为CRTP)时，上述相关信息包括RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当上述压缩方式为配置压缩用户数据协议(Configuring Compressed User Date Protocol，简称为CUDP)时，上述相关信息包括RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的上述压缩表发送给接收端，其中，该压缩表用于指示接收端建立与压缩表对应的解压缩表。其中，接收端在成功建立了解压缩表后，可以再返回一个建立OK的响应消息。需要说明的是，上述的几种压缩方式仅是示例，还可以采用其他的压缩方式，同样地，当采用其他的压缩方式时，需要建立与该其他的压缩方式对应的压缩表，不同的压缩方式对应的压缩表中的内容可以是不同的。在上述的协商方式完成之后，两端便可以采用协商的方式进行RTP报文的压缩、解压缩操作了。In an optional embodiment, the compression method may be negotiated with the receiving end in the following manner: a compression table is established according to the relevant information of the RTP message to be sent to the receiving end, wherein the compression table carries the identifier of the currently selected compression method And the related information of the above RTP message, when the currently selected compression method is Robust Header Compression (Robust Header Compression, referred to as ROCH) or configuration compressed real-time protocol (Configuring Compressed Real-Time Protocol, referred to as CRTP), the above related information includes The source IP address of the RTP message, the destination IP address, the user data protocol UDP source port, the UDP destination port and the RTP header; ), the above-mentioned relevant information includes the source IP address of the RTP message, the destination IP address, the UDP source port and the UDP destination port; The decompression table corresponding to the compressed table. Wherein, after successfully establishing the decompression table, the receiving end may return a establishment OK response message. It should be noted that the above-mentioned compression methods are only examples, and other compression methods can also be used. Similarly, when other compression methods are used, a compression table corresponding to the other compression methods needs to be established. Different compression methods The content in the compression table corresponding to the mode may be different. After the above negotiation method is completed, the two ends can use the negotiation method to compress and decompress the RTP message.
在一个可选的实施例中，上述RTP报文的相关信息可以通过如下方式获取：判断接收到的待发送给接收端的报文是否是RTP报文；在判断结果为该报文是RTP报文的情况下，提取上述报文的相关信息作为RTP报文的相关信息。其中，该待发送给接收端的报文可以是需要发送给接收端的第一个RTP报文，并且，为了避免延时过大，该第一个RTP报文可以不经过压缩直接发送给接收端。In an optional embodiment, the relevant information of the above-mentioned RTP message can be obtained in the following manner: judging whether the received message to be sent to the receiving end is an RTP message; In the case of , the relevant information of the above packet is extracted as the relevant information of the RTP packet. Wherein, the message to be sent to the receiving end may be the first RTP message to be sent to the receiving end, and, in order to avoid excessive delay, the first RTP message may be directly sent to the receiving end without compression.
其中，判断报文是否是RTP报文的方式可以有多种判断方式，下面对本发明实施例中提出的判断方法进行说明：判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：判断待发送给接收端的报文是否是UDP报文；当确定该报文是UDP报文后，判断该报文的UDP数据帧的字节数是否大于预定数量(例如，该预定数量为12个字节，即，是否大于RTP报文固定头的长度)，如果大于预定数量，则判断报文的UDP载荷中的预定位(例如，前两位)是否为预定值(例如，0x10，即，是否与现行的RTP版本号相同)；当确定该报文的UDP载荷中的预定位是预定值时，判断报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定该报文的PAYLOAD为RTP的编码格式时，确定该报文是RTP报文。采用本发明实施例中的判断方案，即通过判断编码格式是否是RTP的编码格式来确定报文是否是RTP报文，能够简化判断步骤，提高判断准确度。并且，在后续的过程中，当接收到需要发送给接收端的报文后，也可以按照上述方法判断接收到的报文是否是RTP报文，当确定是时，再对确定是RTP的报文按照上述的实施例中的方法进行压缩，然后，发送压缩后的RTP报文。Wherein, the mode of judging whether a message is an RTP message can have multiple judging methods, and the judging method proposed in the embodiment of the present invention is described below: judging whether the received message to be sent to the receiving end is RTP The message includes: judge whether the message to be sent to the receiving end is a UDP message; after determining that the message is a UDP message, judge whether the byte count of the UDP data frame of the message is greater than a predetermined number (for example, the predetermined Quantity is 12 bytes, that is, whether it is greater than the length of the RTP message fixed header), if greater than the predetermined quantity, then judge whether the predetermined position (for example, the first two bits) in the UDP load of the message is a predetermined value (for example, 0x10, that is, whether it is the same as the current RTP version number); when it is determined that the predetermined bit in the UDP load of the message is a predetermined value, judge whether the encoding format of the payload PAYLOAD of the message is the encoding format of RTP; when determining When the PAYLOAD of the message is an RTP encoding format, it is determined that the message is an RTP message. By adopting the judging scheme in the embodiment of the present invention, that is, determining whether the message is an RTP message by judging whether the encoding format is the RTP encoding format, the judging steps can be simplified and the judging accuracy can be improved. And, in the follow-up process, after receiving the message that needs to be sent to the receiving end, it is also possible to judge whether the received message is an RTP message according to the above method, and when it is determined to be an RTP message, then determine whether it is an RTP message Compress according to the method in the above embodiment, and then send the compressed RTP message.
执行上述操作的主体可以是发送端，压缩表和解压缩表在建立之后，发送端和接收端也可以对压缩表和解压缩表进行删除或更新操作，在一个可选的实施例中，在将建立的压缩表发送给接收端之后，上述方法还包括：接收携带挂断指令的第一实时传输控制协议RTCP报文；向接收端发送第一通知消息，其中，该第一通知消息用于通知接收端删除解压缩表；在接收到来自上述接收端的成功删除响应后，删除压缩表。其中，该RTCP报文中的特定字段可以被设置为BYE，该被设置为BYE的特定字段可以是上述的挂断指令。The subject that performs the above operations can be the sending end. After the compression table and the decompression table are established, the sending end and the receiving end can also delete or update the compression table and the decompression table. In an optional embodiment, after the establishment of After the compression table is sent to the receiving end, the above method also includes: receiving the first real-time transmission control protocol RTCP message carrying a hang-up instruction; sending a first notification message to the receiving end, wherein the first notification message is used to notify the receiving end The end deletes the decompression table; after receiving the successful deletion response from the above receiving end, deletes the compression table. Wherein, a specific field in the RTCP message may be set as BYE, and the specific field set as BYE may be the above-mentioned hangup instruction.
在一个可选的实施例中，在按照预先与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩之后，该方法还包括：在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除上述压缩表；向接收端发送第二通知消息，其中，该第二通知消息用于通知接收端删除解压缩表。其中，在该实施例中，可以在压缩RTP报文失败后即删除压缩表，也可以当压缩RTP报文失败的次数超过预定次数(该预定次数可以大于1)后再删除压缩表，或者，也可以在持续压缩RTP报文失败的时间超过一定值的时候删除压缩表，然后再通知接收端删除解压缩表。In an optional embodiment, after compressing the RTP message to be sent to the receiving end according to the compression method pre-negotiated with the receiving end, the method further includes: when the number of failures to compress the RTP message exceeds the first threshold and/or Or after the continuous failure time of compressing the RTP message exceeds the second threshold, delete the compression table; send a second notification message to the receiving end, wherein the second notification message is used to notify the receiving end to delete the decompression table. Wherein, in this embodiment, the compression table can be deleted after the compressed RTP message fails, or the compression table can be deleted after the number of times the compressed RTP message fails to exceed a predetermined number of times (the predetermined number of times can be greater than 1), or, It is also possible to delete the compression table when the continuous failure time of compressing the RTP message exceeds a certain value, and then notify the receiving end to delete the decompression table.
在上述实施例中描述了压缩表和解压缩表的删除是由发送端(即，执行上述操作的一端)触发的，当然，压缩表和解压缩表的删除也可以是由接收端触发的，在一个可选的实施例中，在通过卫星将压缩后的RTP报文传输给接收端之后，该方法还包括：接收来自接收端的用于通知删除压缩表的第三通知消息；根据该第三通知消息删除压缩表。In the above embodiment, it is described that the deletion of the compression table and the decompression table is triggered by the sending end (that is, the end that performs the above operations). Of course, the deletion of the compression table and the decompression table can also be triggered by the receiving end. In an optional embodiment, after the compressed RTP message is transmitted to the receiving end via the satellite, the method further includes: receiving a third notification message from the receiving end for notifying deletion of the compression table; according to the third notification message Delete the compressed table.
在一个可选的实施例中，上述第三通知消息可以包括以下至少之一：接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；上述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。同样的，接收端在解压缩压缩后的RTP报文失败的情况下发送的通知消息可以是在接收端解压一次失败后即发送的通知消息，也可以是接收端解压失败的次数超过预定次数后发送的通知消息，或者，也可以是接收端在持续解压缩失败的时间超过一定值后发送的通知消息，并且，接收端在发送通知消息之前，可以先删除接收端中的解压缩表。In an optional embodiment, the above-mentioned third notification message may include at least one of the following: the number of times the receiving end fails to decompress the compressed RTP packets exceeds the first threshold and/or continuously decompresses the compressed RTP packets A notification message sent when the message failure time exceeds the second threshold; a notification message sent by the receiving end after receiving the second real-time transmission control protocol RTCP message carrying a hangup instruction. Similarly, the notification message sent by the receiving end in the case of failure to decompress the compressed RTP message can be the notification message sent after the receiving end fails to decompress once, or the notification message sent after the receiving end fails to decompress the compressed RTP message for a predetermined number of times. The notification message sent may also be a notification message sent by the receiving end after the continuous decompression failure time exceeds a certain value, and the receiving end may delete the decompression table in the receiving end before sending the notification message.
在上述实施例中，当发送端删除了压缩表、接收端删除了解压缩表后，发送端和接收端可以重新发起协商建立压缩表解压缩表的流程。In the above embodiment, after the sending end deletes the compression table and the receiving end deletes the decompression table, the sending end and the receiving end can re-initiate the process of negotiating to establish the compression table and decompression table.
在本实施例中还提供了一种报文处理方法，图2是根据本发明实施例的报文处理方法的流程图，如图2所示，该流程包括如下步骤：In this embodiment, a message processing method is also provided. FIG. 2 is a flowchart of a message processing method according to an embodiment of the present invention. As shown in FIG. 2, the process includes the following steps:
步骤S202，接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；Step S202, receiving the compressed real-time transport protocol RTP message sent by the sending end through the satellite;
步骤S204，根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。Step S204, decompress the compressed RTP message according to the decompression mode negotiated with the sending end.
由上述步骤可知，接收的RTP报文是压缩后的RTP报文，即，发送端在发送RTP报文时，是首先对该RTP报文进行了压缩，然后再发送压缩后的RTP报文，其中，压缩后的RTP报文的大小相对于原始的未压缩的RTP报文的而言，会小很多，这样，便可以减少带宽的占用，从而实现了在一定的带宽上发送更多的RTP报文的目的，提高了带宽的利用率，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。It can be seen from the above steps that the received RTP message is a compressed RTP message, that is, when the sending end sends the RTP message, it first compresses the RTP message, and then sends the compressed RTP message. Among them, the size of the compressed RTP message will be much smaller than that of the original uncompressed RTP message, so that the bandwidth occupation can be reduced, so that more RTP messages can be sent on a certain bandwidth. The purpose of the message improves the utilization rate of bandwidth, solves the problem of insufficient bandwidth utilization rate of voice communication in the field of satellite communication in related technologies, and then achieves the improvement of bandwidth utilization rate of voice communication in the field of satellite communication, The effect of saving bandwidth resources.
在一个可选的实施例中，可以通过如下方式与发送端协商上述解压缩方式：接收来自发送端的压缩表；根据该压缩表建立用于解压缩上述压缩后的RTP报文的解压缩表。需要说明的是，上述的压缩表里可以标识采用的是何种压缩方式(例如，可以是ROCH压缩方式或者，CUDP压缩方式)，不同的压缩方式对应的压缩表中的内容可以是不同的。在上述的协商方式完成之后，两端便可以采用协商的方式进行RTP报文的压缩、解压缩操作了。In an optional embodiment, the decompression method may be negotiated with the sender in the following manner: receiving a compression table from the sender; and establishing a decompression table for decompressing the compressed RTP message according to the compression table. It should be noted that the above compression table may identify which compression method is used (for example, it may be ROCH compression method or CUDP compression method), and the contents in the compression table corresponding to different compression methods may be different. After the above negotiation method is completed, the two ends can use the negotiation method to compress and decompress the RTP message.
其中，执行上述操作的主体可以是接收端，压缩表和解压缩表在建立之后，发送端和接收端也可以对压缩表和解压缩表进行删除或更新操作，在一个可选的实施例中，在根据上述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：接收来自发送端的第四通知消息；根据该第四通知消息删除上述解压缩表。Wherein, the subject that performs the above operations can be the receiving end, after the compression table and the decompression table are established, the sending end and the receiving end can also delete or update the compression table and the decompression table, in an optional embodiment, in After establishing the decompression table for decompressing the compressed RTP message according to the above compression table, the method further includes: receiving a fourth notification message from the sender; deleting the above decompression message according to the fourth notification message surface.
在一个可选的实施例中，上述第四通知消息可以包括以下至少之一：发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。可选地，发送端在压缩RTP报文失败的情况下发送的通知消息可以是在发送端压缩一次失败后即发送的通知消息，也可以是发送端压缩失败的次数超过预定次数后发送的通知消息，或者，也可以是发送端在持续压缩失败的时间超过一定值后发送的通知消息，并且，发送端在发送通知消息之前，可以先删除发送端中的压缩表；从上述的描述中可知，RTCP报文中可以携带挂断指令，其携带方式可以是在RTCP中预定字段被设置为BYE。In an optional embodiment, the fourth notification message may include at least one of the following: the number of times the sender fails to compress the RTP packets to be sent exceeds the first threshold and/or continuously compresses the RTP packets to be sent A notification message sent when the message failure time exceeds the second threshold; a notification message sent by the sender after receiving the first real-time transport control protocol RTCP message carrying a hangup instruction. Optionally, the notification message sent by the sending end in the case of failure to compress the RTP message may be a notification message sent after the sending end fails to compress the RTP message once, or it may be a notification message sent after the number of compression failures by the sending end exceeds a predetermined number of times message, or it can also be a notification message sent by the sender after the continuous compression failure time exceeds a certain value, and the sender can delete the compression table in the sender before sending the notification message; from the above description, we can see that , the RTCP message may carry a hangup instruction, and the carrying method may be that the predetermined field in the RTCP is set to BYE.
在一个可选的实施例中，当上述第四通知消息包括发送端在接收到携带挂断指令的第一RTCP报文后发送的通知消息时，在根据上述第四通知消息删除解压缩表之后，上述方法还包括：向所述发送端发送成功删除响应，其中，该成功删除响应用于指示发送端删除压缩表。In an optional embodiment, when the fourth notification message includes a notification message sent by the sender after receiving the first RTCP message carrying a hangup instruction, after deleting the decompression table according to the fourth notification message , the above method further includes: sending a successful deletion response to the sending end, wherein the successful deletion response is used to instruct the sending end to delete the compression table.
在上述实施例中描述了压缩表和解压缩表的删除是由发送端触发的，当然，压缩表和解压缩表的删除也可以是由接收端触发的，在一个可选的实施例中，在接收来自发送端的压缩表之后，该方法还包括：接收携带挂断指令的第二实时传输控制协议RTCP报文；向发送端发送第五通知消息，其中，该第五通知消息用于通知发送端删除压缩表；在接收到来自发送端的成功删除响应后，删除上述解压缩表。其中，RTCP报文中携带挂断指令的携带方式可以是在RTCP中预定字段被设置为BYE。In the above embodiment, it is described that the deletion of the compression table and the decompression table is triggered by the sending end. Of course, the deletion of the compression table and the decompression table can also be triggered by the receiving end. In an optional embodiment, the receiving end After the compressed table from the sender, the method also includes: receiving a second real-time transmission control protocol RTCP message carrying a hangup instruction; sending a fifth notification message to the sender, wherein the fifth notification message is used to notify the sender to delete Compression table; after receiving a successful delete response from the sender, delete the above decompression table. Wherein, the hang-up instruction carried in the RTCP packet may be carried in a way that the predetermined field in the RTCP is set to BYE.
在一个可选的实施例中，在根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文之后，该方法还包括：当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除上述解压缩表，并向发送端发送第六通知消息，其中，该第六通知消息用于通知发送端删除压缩表。其中，在该实施例中，可以在解压缩RTP报文失败后即删除解压缩表，也可以当解压缩RTP报文失败的次数超过预定次数(该预定次数可以大于1)后再删除解压缩表，或者，也可以在持续解压缩RTP报文失败的时间超过一定值的时候删除解压缩表，然后再通知发送端删除压缩表。In an optional embodiment, after decompressing the compressed RTP message according to the decompression method negotiated with the sending end, the method further includes: when the number of failures to decompress the compressed RTP message exceeds the first After the threshold and/or the failure time of continuous decompression of compressed RTP packets exceeds the second threshold, delete the above-mentioned decompression table, and send a sixth notification message to the sender, where the sixth notification message is used to notify the sender Delete the compressed table. Wherein, in this embodiment, the decompression table can be deleted after the failure of decompressing the RTP message, or the decompression table can be deleted after the number of failures of the decompression RTP message exceeds a predetermined number of times (the predetermined number of times can be greater than 1). Alternatively, the decompression table can be deleted when the continuous failure time of decompressing the RTP message exceeds a certain value, and then the sending end is notified to delete the compression table.
在上述实施例中，当发送端删除了压缩表、接收端删除了解压缩表后，发送端和接收端可以重新发起协商建立压缩表解压缩表的流程。In the above embodiment, after the sending end deletes the compression table and the receiving end deletes the decompression table, the sending end and the receiving end can re-initiate the process of negotiating to establish the compression table and decompression table.
下面以上述的发送端为网关GW1，接收端为网关GW2为例，对本发明的整体流程进行说明：Taking the above-mentioned sending end as the gateway GW1 and the receiving end as the gateway GW2 as an example, the overall process of the present invention will be described below:
图3是根据本发明实施例的语音呼叫以及挂断过程的交互流程图，如图3所示，该流程包括如下步骤：Fig. 3 is the interactive flow chart of voice call and hang up process according to the embodiment of the present invention, as shown in Fig. 3, this process includes the following steps:
步骤S301，当主叫方的用户设备(User Equipment，简称为UE)(以下简称为UE)需要发起语音呼叫被叫方时，该UE向IP对媒体子系统(IP multimedia subsystem，简称为IMS)发起语音呼叫；Step S301, when the user equipment (User Equipment, referred to as UE) of the calling party (hereinafter referred to as UE) needs to initiate a voice call to the called party, the UE sends an IP media subsystem (IP multimedia subsystem, referred to as IMS) initiate a voice call;
步骤S302，当IMS确定允许UE进行语音呼叫时，向UE返回一个语音呼叫成功的响应；Step S302, when the IMS determines that the UE is allowed to make a voice call, return a voice call success response to the UE;
步骤S303，UE向UE侧的网关GW1发送语音报文(对应于上述的RTP报文)；Step S303, the UE sends a voice message (corresponding to the above RTP message) to the gateway GW1 on the UE side;
步骤S304，GW1确定压缩方式，并根据该语音报文建立该压缩方式下的压缩表，其建立过程如上述的实施例所述，在此不再陈述；并且，GW1将该语音报文和建立的压缩表发送给被叫侧UE的网关GW2，GW2根据压缩表建立于该压缩表对应的解压缩表；Step S304, GW1 determines the compression mode, and establishes a compression table under the compression mode according to the voice message, the establishment process is as described in the above-mentioned embodiment, and will not be described here; and, GW1 combines the voice message and the establishment The compressed table is sent to the gateway GW2 of the UE on the called side, and GW2 builds the decompressed table corresponding to the compressed table according to the compressed table;
步骤S305，GW1与GW2建立压缩会话；Step S305, GW1 establishes a compression session with GW2;
步骤S306，GW2向GW1返回建立压缩会话成功消息；Step S306, GW2 returns to GW1 a successful compression session establishment message;
步骤S307，GW2将GW1发送过来的语音报文发送给IMS；Step S307, GW2 sends the voice message sent by GW1 to the IMS;
步骤S308，UE向GW1发送语音报文；Step S308, the UE sends a voice message to GW1;
步骤S309，GW1对UE发送过来的语音报文按照上述确定的压缩方式进行压缩，并将压缩后的语音报文发送到GW2；Step S309, GW1 compresses the voice message sent by the UE according to the compression method determined above, and sends the compressed voice message to GW2;
步骤S310，GW2对接收到的压缩的语音报文进行解压缩，并将解压缩后的语音报文发送给IMS；Step S310, GW2 decompresses the received compressed voice message, and sends the decompressed voice message to the IMS;
步骤S311，GW2接收到被叫侧UE发送的语音报文，并且，GW2按照和上述相同的方式和GW1协商压缩解压缩方式；Step S311, GW2 receives the voice message sent by the UE on the called side, and GW2 negotiates with GW1 on the compression and decompression method in the same manner as above;
步骤S312，GW2按照协商的压缩方式压缩被叫侧UE发送的语音报文，并发送给GW1；Step S312, GW2 compresses the voice message sent by the UE on the called side according to the negotiated compression method, and sends it to GW1;
步骤S313，GW1对接收的压缩后的来自被叫侧UE的语音报文进行解压缩，并发送给主叫方的UE；Step S313, GW1 decompresses the received compressed voice message from the UE on the called side, and sends it to the UE on the calling side;
步骤S314，主叫方UE确定需要挂断此次语音通话，会向IMS发送挂断语音呼叫的通知；Step S314, the calling party UE determines that the voice call needs to be hung up, and will send a notification to the IMS to hang up the voice call;
步骤S315，GW1通知GW2删除压缩会话；Step S315, GW1 notifies GW2 to delete the compression session;
步骤S316，GW2向GW1返回删除压缩会话成功的消息；Step S316, GW2 returns to GW1 a message that the compression session is successfully deleted;
步骤S317，IMS向主叫方UE发送你语音呼叫响应消息，至此，语音通话结束。In step S317, the IMS sends your voice call response message to the calling party UE, so far, the voice call ends.
下面结合具体应用场景对本发明进行说明：The present invention is described below in combination with specific application scenarios:
实施实例1：Implementation example 1:
图4是根据本发明实施例的卫星通信传输场景示意图，如图4所示，在本实施方案中使用ROHC压缩(CRTP压缩和ROHC压缩是类似的，在此，以ROHC为例进行说明)的方法对语音报文进行压缩，ROHC通常用于无线通信的空中接口，在本例中用在卫星传输语音压缩的场景。Fig. 4 is a schematic diagram of a satellite communication transmission scenario according to an embodiment of the present invention. As shown in Fig. 4, in this embodiment, ROHC compression (CRTP compression and ROHC compression are similar, here, ROHC is used as an example for illustration) The method compresses the voice message. ROHC is usually used in the air interface of wireless communication. In this example, it is used in the voice compression scenario of satellite transmission.
流程部分的处理步骤如下：The processing steps of the process part are as follows:
建立连接：establish connection:
图5是根据本发明实施例的RTP报文的判断流程图，GW1在收到报文后，可以按照图5所示的流程判断是否为RTP报文，其判断流程包括如下步骤：Fig. 5 is the judging flowchart of the RTP message according to the embodiment of the present invention, after GW1 receives the message, can judge whether it is an RTP message according to the process shown in Fig. 5, and its judging process includes the following steps:
步骤S501，包过滤模块(该过滤模块可以是发送端或接收端中的一个模块)对所有收到的报文分析；Step S501, the packet filtering module (the filtering module can be a module in the sending end or the receiving end) analyzes all received messages;
步骤S502，包过滤模块判断是否是UDP报文，如果是UDP报文，转至步骤S503，否则，转至步骤S512；Step S502, the packet filtering module judges whether it is a UDP message, if it is a UDP message, go to step S503, otherwise, go to step S512;
步骤S503，判断报文的IP地址(包括源IP地址和目的IP地址)和端口号(包括UDP源端口和UDP目的端口)是否能在ROHC压缩解压缩实例中查找到，如果能查找到，则认为是已建立好的压缩会话，转至步骤S510，否则，转至步骤S504；Step S503, whether the IP address (including source IP address and destination IP address) and port number (including UDP source port and UDP destination port) of the judgment message can be found in the ROHC compression and decompression example, if it can be found, then If it is considered as an established compression session, go to step S510, otherwise, go to step S504;
步骤S504，判断UDP数据帧是否大于12个字节，如果判断结果为大于12个字节，则转至步骤S505，否则，转至步骤S512；Step S504, judging whether the UDP data frame is greater than 12 bytes, if the judgment result is greater than 12 bytes, then go to step S505, otherwise, go to step S512;
步骤S505，判断UDP载荷前两位是否为0x10(RTP/RTCP为2)，如果是转至步骤S506，否则，转至部署S512；Step S505, judge whether the first two digits of the UDP load are 0x10 (RTP/RTCP is 2), if it is, go to step S506, otherwise, go to deployment S512;
步骤S506，判断PAYLOAD载荷是否为RTP或RTCP的编码格式，判断结果为是，转至步骤S506，否则，转至步骤S512；Step S506, judging whether the PAYLOAD load is an encoding format of RTP or RTCP, if the judging result is yes, go to step S506, otherwise, go to step S512;
步骤S507，判断一个会话中同步信源标识符SSRC是否不变，判断结果为是，转至步骤S508，否则，转至步骤S512；Step S507, judging whether the synchronization source identifier SSRC in a session remains unchanged, if the judging result is yes, go to step S508, otherwise, go to step S512;
步骤S508，循环判断3次，判断SSRC是否一致，若为是，转至步骤S509，否则，转至步骤S512；Step S508, loop judgment 3 times, judge whether the SSRC is consistent, if yes, go to step S509, otherwise, go to step S512;
步骤S509，连续3次条件都满足，则判断认为是RTP或者RTCP报文，如果是RTP报文跳转到步骤S511；Step S509, if the conditions are met for three consecutive times, it is judged to be an RTP or RTCP message, and if it is an RTP message, jump to step S511;
步骤S510，压缩报文；Step S510, compressing the message;
步骤S511，记录IP地址UDP端口号RTP头中的SSRC标识，创建ROHC压缩解压缩实例，构造一个报文，将上面记录的信息按照图6所示的格式(当采用CRTP压缩时，格式与图6所示类似，区别在于标识需要采用CRTP标识)封装后发送到GW2，其中，图6是根据本发明实施例的ROHC自定义协商报文封装格式示意图，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图6的格式回复GW1，转步骤S513；Step S511, record the SSRC mark in the IP address UDP port number RTP header, create an ROHC compression and decompression instance, construct a message, and record the information above according to the format shown in Figure 6 (when using CRTP compression, the format is the same as that shown in Figure 6 6 is similar to that shown in 6, the difference is that the identification needs to be encapsulated with the CRTP identification) and then sent to GW2, wherein, Figure 6 is a schematic diagram of the encapsulation format of the ROHC custom negotiation message according to the embodiment of the present invention, and GW2 receives it according to the sent information , create an instance of compression and decompression, and reply GW1 according to the format of Figure 6 at the same time, go to step S513;
步骤S512，确定不是RTP和RTCP报文，继续对接收到的报文进行检测；Step S512, determine that it is not an RTP and RTCP message, and continue to detect the received message;
步骤S513，GW1收到后启用ROHC压缩，包过滤模块在收到RTP报文后在ROHC压缩实例表中查找是否有对应的表项，如果有，则开始对RTP报文开始压缩，基于ROHC实例创建压缩解压缩会话，压缩RTP报文，包括IP头+UDP头+RTP头，GW2处理类似GW1网关操作。Step S513, GW1 enables ROHC compression after receiving the RTP message. After receiving the RTP message, the packet filter module searches the ROHC compression instance table to see if there is a corresponding entry. If so, it starts to compress the RTP message, based on the ROHC instance Create a compression and decompression session, compress RTP packets, including IP header + UDP header + RTP header, and GW2 handles similar GW1 gateway operations.
其中，上述的步骤S507-S509是可选的，当针对单一的报文进行判断时，可以不用进行循环3次的判断。Wherein, the above-mentioned steps S507-S509 are optional, and when judging for a single message, it is not necessary to go through the judging cycle 3 times.
下面对连接关闭进行说明：The connection closure is explained below:
GW1或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的ROHC压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号、SSRC标识查找ROHC压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图6的格式通知对方删除对应的压缩解压缩会话。GW1 or GW2 receives the RTCP message, if it is a hangup message, that is, the corresponding field of the RTCP message is set to BYE, it is considered to delete the ROHC compression and decompression session corresponding to the RTP, according to the IP address in the RTCP header, The UDP port number and the SSRC mark search the ROHC compression and decompression table, if found, delete the corresponding RTP compression and decompression session, and notify the other party to delete the corresponding compression and decompression session according to the format in Figure 6.
下面对异常保护进行说明：The exception protection is explained below:
GW1或者GW2连续一段时间内ROHC解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。After GW1 or GW2 fails ROHC decompression for a period of time, delete the compression and decompression table at the local end, notify the peer end to delete it, and re-initiate the negotiation to establish the compression and decompression table.
实施实例2：Implementation example 2:
图7是根据本发明实施例的UE直接接入卫星通信场景。下面以上述UE为手机为例，对本发明进行说明。Fig. 7 is a scenario where a UE directly accesses satellite communication according to an embodiment of the present invention. The present invention will be described below by taking the above-mentioned UE as a mobile phone as an example.
在本实施方案中同样使用ROHC压缩(同样地，也可以采用CRTP压缩方式，在该实施例中，以ROHC压缩方式为例进行说明)的方法对语音报文进行压缩，手机和GW2上驻留压缩和包过滤模块。In this embodiment, ROHC compression is also used (similarly, the CRTP compression method can also be used, and in this embodiment, the ROHC compression method is used as an example for illustration) to compress the voice message, and the mobile phone and GW2 reside Compression and packet filtering modules.
下面对连接建立过程进行说明：The following describes the connection establishment process:
步骤S1，手机通过卫星接入后，通过网络发起语音呼叫后，包过滤模块监听到手机发送的报文是RTP语音报文；Step S1, after the mobile phone is connected through the satellite and initiates a voice call through the network, the packet filtering module detects that the message sent by the mobile phone is an RTP voice message;
步骤S2，压缩模块记录IP地址UDP端口号RTP头中的SSRC标识，创建ROHC压缩解压缩实例，构造一个报文，将上面记录的信息按照图5的格式封装后发送到GW2，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图6的格式回复给手机；Step S2, the compression module records the SSRC identifier in the RTP header of the IP address, UDP port number, creates an ROHC compression and decompression instance, constructs a message, encapsulates the information recorded above according to the format shown in Figure 5, and sends it to GW2, and GW2 receives it Then, according to the information sent, create a compression and decompression instance, and reply to the mobile phone according to the format in Figure 6;
步骤S3，手机收到来自GW2的创建压缩解压缩成功的消息后，启动ROHC压缩，转到S4；Step S3, after receiving the message from GW2 that the creation, compression and decompression is successful, the mobile phone starts ROHC compression, and turns to S4;
步骤S4，GW2或者手机上包过滤模块在监听到发送的RTP语音报文时，则在ROHC压缩实例表中查找是否有对应的表项，如果有则开始对RTP报文开始压缩，基于ROHC实例创建压缩解压缩会话，压缩RTP报文头，包括IP头+UDP头+RTP头。Step S4, when GW2 or the packet filtering module on the mobile phone monitors the sent RTP voice message, it searches the ROHC compression instance table to see if there is a corresponding entry, and if so, starts to compress the RTP message, based on the ROHC instance Create a compression and decompression session, compress the RTP packet header, including IP header + UDP header + RTP header.
下面对连接关闭进行说明：The connection closure is explained below:
手机或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的ROHC压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号、SSRC标识查找ROHC压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图6的格式通知对方删除对应的压缩解压缩会话。If the mobile phone or GW2 receives the RTCP message, if it is a hang-up message, that is, the corresponding field of the RTCP message is set to BYE, it is considered to delete the ROHC compression and decompression session corresponding to the RTP. According to the IP address in the RTCP header, The UDP port number and the SSRC mark search the ROHC compression and decompression table, if found, delete the corresponding RTP compression and decompression session, and notify the other party to delete the corresponding compression and decompression session according to the format in Figure 6.
下面对异常保护进行说明：The exception protection is explained below:
手机或者GW2连续一段时间内ROHC解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。After the mobile phone or GW2 fails ROHC decompression for a period of time, delete the compression and decompression table at the local end, notify the peer end to delete it, and initiate the negotiation to establish the compression and decompression table again.
实施实例3：Implementation example 3:
该实施例以图4所示的卫星通信场景为例进行说明：This embodiment is described by taking the satellite communication scenario shown in FIG. 4 as an example:
在本实施方案中使用CUDP压缩的方法对语音报文进行压缩，GW1和GW2上驻留压缩和包过滤模块。In this embodiment, the CUDP compression method is used to compress the voice message, and the compression and packet filtering modules reside on GW1 and GW2.
下面对建立连接过程进行说明：The following describes the process of establishing a connection:
步骤S1，GW1在收到报文后按照图5所示的流程判断是否为RTP报文，包过滤模块对所有收到的报文分析，先判断是否UDP报文，如果是UDP报文，判断IP地址和端口号是否能在CUDP压缩解压缩实例中查找到，如果能查找到，则认为是已建立好的压缩会话，如果查找不到则继续判断UDP数据帧是否大于12个字节，如果是判断UDP载荷前两位是否为0x10(RTP/RTCP为2)，如果是判断PAYLOAD载荷是否为RTP或RTCP的编码格式，循环判断3次，判断SSRC是否一致，连续3次条件都满足，则判断认为是RTP或者RTCP报文，如果是RTP报文跳转到第二步；Step S1, after receiving the message, GW1 judges whether it is an RTP message according to the process shown in Figure 5, and the packet filter module analyzes all received messages, first judges whether it is a UDP message, if it is a UDP message, judges Whether the IP address and port number can be found in the CUDP compression and decompression instance, if found, it is considered to be an established compression session, if not found, continue to judge whether the UDP data frame is larger than 12 bytes, if It is to judge whether the first two digits of the UDP payload are 0x10 (RTP/RTCP is 2). If it is to judge whether the PAYLOAD payload is in the encoding format of RTP or RTCP, it is judged 3 times in a loop to judge whether the SSRC is consistent. If the conditions are met for 3 consecutive times, then Judging that it is an RTP or RTCP message, if it is an RTP message, jump to the second step;
S2，记录IP地址UDP端口号，创建CUDP压缩解压缩通道表，构造一个报文，将上面记录的信息按照图8的格式封装后发送到GW2，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图8的格式回复GW1，其中，图8是根据本发明实施例的CUDP自定义协商报文封装格式示意图；S2, record the IP address UDP port number, create a CUDP compression and decompression channel table, construct a message, encapsulate the information recorded above according to the format of Figure 8, and send it to GW2. After receiving it, GW2 creates a Compression and decompression example, and reply GW1 according to the format of Figure 8 at the same time, wherein, Figure 8 is a schematic diagram of the encapsulation format of the CUDP custom negotiation message according to the embodiment of the present invention;
S3，GW1收到后启用CUDP压缩，包过滤模块在收到RTP报文后在CUDP压缩通道表中查找是否有对应的表项，如果有则开始对RTP报文开始压缩，压缩RTP报文，GW2处理类似GW1网关操作。S3, GW1 enables CUDP compression after receiving the RTP message, and the packet filter module searches the CUDP compression channel table after receiving the RTP message to see if there is a corresponding entry, and if there is, it starts to compress the RTP message, compressing the RTP message, GW2 handles gateway operations similar to GW1.
下面对连接关闭进行说明：The connection closure is explained below:
GW1或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的CUDP压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号查找CUDP压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图8的格式通知对方删除对应的压缩解压缩会话。GW1 or GW2 receives the RTCP message, if it is a hangup message, that is, the corresponding field of the RTCP message is set to BYE, it is considered to delete the CUDP compression and decompression session corresponding to the RTP, according to the IP address in the RTCP header, The UDP port number searches the CUDP compression and decompression table. If it can be found, delete the corresponding RTP compression and decompression session, and notify the other party to delete the corresponding compression and decompression session according to the format of Figure 8.
下面对异常保护进行说明：The exception protection is explained below:
GW1或者GW2连续一段时间内CUDP解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。After GW1 or GW2 fails to decompress with CUDP for a period of time, delete the compression and decompression table at the local end, notify the peer end to delete it, and re-initiate the negotiation to establish the compression and decompression table.
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general-purpose hardware platform, and of course also by hardware, but in many cases the former is better implementation. Based on such an understanding, the essence of the technical solution of the present invention or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products are stored in a storage medium (such as ROM/RAM, disk, CD) contains several instructions to enable a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in various embodiments of the present invention.
在本实施例中还提供了一种报文处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。This embodiment also provides a packet processing device, which is used to implement the above embodiments and preferred implementation manners, and what has been described will not be repeated here. As used below, the term "module" may be a combination of software and/or hardware that realizes a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementations in hardware, or a combination of software and hardware are also possible and contemplated.
图9是根据本发明实施例的第一种报文处理装置的结构框图，如图9所示，该装置包括压缩模块92和第一发送模块94，下面对该装置进行说明。Fig. 9 is a structural block diagram of a first packet processing device according to an embodiment of the present invention. As shown in Fig. 9, the device includes a compression module 92 and a first sending module 94, and the device will be described below.
压缩模块92，用于按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；第一发送模块94，连接至上述压缩模块92，用于在压缩成功后，通过卫星将压缩后的RTP报文发送给接收端。The compression module 92 is used to compress the real-time transport protocol RTP message to be sent to the receiving end according to the compression mode negotiated with the receiving end; the first sending module 94 is connected to the above-mentioned compression module 92, and is used to pass the satellite after the compression is successful. Send the compressed RTP message to the receiving end.
图10是根据本发明实施例的第一种报文处理装置的优选结构框图一，如图10所示，该装置除包括图9所示的所有模块外，还包括第一协商模块102，下面对该装置进行说明。Fig. 10 is a preferred structural block diagram 1 of a first message processing device according to an embodiment of the present invention. As shown in Fig. 10, the device includes not only all the modules shown in Fig. 9 but also a first negotiation module 102, the following Facing this device, a description will be given.
第一协商模块102，连接至上述压缩模块92，用于通过如下方式与接收端协商上述压缩方式：根据待发送给接收端的RTP报文的相关信息建立压缩表，其中，该压缩表中携带当前选择的压缩方式的标识和RTP报文的相关信息，当该当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，上述相关信息包括RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当上述压缩方式为配置压缩用户数据协议CUDP时，上述相关信息包括RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的上述压缩表发送给接收端，其中，该压缩表用于指示接收端建立与压缩表对应的解压缩表。The first negotiation module 102 is connected to the above-mentioned compression module 92, and is used for negotiating the above-mentioned compression method with the receiving end in the following manner: according to the relevant information of the RTP message to be sent to the receiving end, a compression table is established, wherein the compression table carries the current The identification of the selected compression method and the relevant information of the RTP message. When the currently selected compression method is reliable header compression ROCH or configured compressed real-time protocol CRTP, the above-mentioned relevant information includes the source Internet protocol IP address of the RTP message, the destination IP address address, user data protocol UDP source port, UDP destination port, and RTP header; or, when the above-mentioned compression method is configured to compress the user data protocol CUDP, the above-mentioned relevant information includes the source IP address, destination IP address, and UDP source port of the RTP message and the UDP destination port; sending the established compression table to the receiving end, wherein the compression table is used to instruct the receiving end to establish a decompression table corresponding to the compression table.
图11是根据本发明实施例的第一种报文处理装置中第一协商模块102的结构框图，如图11所示，在获取RTP报文的相关信息时，该第一协商模块102包括判断单元112和提取单元114，下面对该第一协商模块102进行说明。Fig. 11 is a structural block diagram of the first negotiation module 102 in the first packet processing device according to an embodiment of the present invention. The unit 112 and the extracting unit 114, the first negotiation module 102 will be described below.
判断单元112，用于判断接收到的待发送给接收端的报文是否是RTP报文；提取单元114，连接至上述判断单元112，用于在判断结果为报文是RTP报文的情况下，提取报文的相关信息作为RTP报文的相关信息。The judging unit 112 is used to judge whether the received message to be sent to the receiving end is an RTP message; the extracting unit 114 is connected to the above-mentioned judging unit 112, and is used to determine whether the message is an RTP message when the result of the judgment is that the message is an RTP message. The relevant information of the extracted packet is used as the relevant information of the RTP packet.
在一个可选的实施例中，上述判断单元112可以通过如下方式判断接收到的待发送给接收端的报文是否是RTP报文：判断待发送给接收端的报文是否是UDP报文；当确定上述报文是UDP报文后，判断报文的UDP数据帧的字节数是否大于预定数量，如果大于预定数量，则判断报文的UDP载荷中的预定位是否为预定值；当确定报文的UDP载荷中的预定位是预定值时，判断报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定该报文的PAYLOAD为RTP的编码格式时，确定该报文是RTP报文。In an optional embodiment, the above-mentioned judging unit 112 can judge whether the received message to be sent to the receiving end is an RTP message in the following manner: judge whether the message to be sent to the receiving end is a UDP message; After the above-mentioned message is a UDP message, judge whether the byte count of the UDP data frame of the message is greater than the predetermined quantity, if greater than the predetermined quantity, then judge whether the predetermined position in the UDP load of the message is a predetermined value; When the predetermined bit in the UDP load of the message is a predetermined value, judge whether the encoding format of the payload PAYLOAD of the message is the encoding format of RTP; When determining that the PAYLOAD of the message is the encoding format of RTP, determine that the message is an RTP message arts.
图12是根据本发明实施例的第一种报文处理装置的优选结构框图二，如图12所示，该装置除包括图10所示的所有模块外，还包括第一接收模块122、第二发送模块124和第一删除模块126，下面对该装置进行说明。图12仅是一种示例，第一接收模块122还可以连接至上述压缩模块92。Fig. 12 is a preferred structural block diagram 2 of the first message processing device according to an embodiment of the present invention. As shown in Fig. 12, the device includes not only all the modules shown in Fig. The second sending module 124 and the first deleting module 126 are described below. FIG. 12 is only an example, and the first receiving module 122 may also be connected to the above-mentioned compression module 92 .
第一接收模块122，连接至上述第一发送模块94，用于在将建立的压缩表发送给接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；第二发送模块124，连接至上述第一接收模块122，用于向接收端发送第一通知消息，其中，该第一通知消息用于通知接收端删除解压缩表；第一删除模块126，连接至上述第二发送模块124，用于在接收到来自接收端的成功删除响应后，删除上述压缩表。The first receiving module 122 is connected to the above-mentioned first sending module 94, and is used to receive the first real-time transmission control protocol RTCP message carrying a hangup instruction after the compressed table of establishment is sent to the receiving end; the second sending module 124 , connected to the above-mentioned first receiving module 122, for sending a first notification message to the receiving end, wherein, the first notification message is used to notify the receiving end to delete the decompression table; the first deleting module 126, connected to the above-mentioned second sending Module 124, configured to delete the compressed table after receiving a successful deletion response from the receiving end.
图13是根据本发明实施例的第一种报文处理装置的优选结构框图三，如图13所示，该装置除包括图10所示的所有模块外，还包括第二删除模块132和第三发送模块134，下面对该装置进行说明。图13仅是一种示例，第二删除模块132还可以连接至上述压缩模块92。Fig. 13 is a third preferred structural block diagram of the first message processing device according to an embodiment of the present invention. As shown in Fig. 13, the device includes not only all the modules shown in Fig. Three sending module 134, the device will be described below. FIG. 13 is only an example, and the second deletion module 132 may also be connected to the above-mentioned compression module 92 .
第二删除模块132，连接至上述第一发送模块94，用于在按照预先与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除上述压缩表；第三发送模块134，连接至上述第二删除模块132，用于向接收端发送第二通知消息，其中，该第二通知消息用于通知接收端删除上述解压缩表。The second deletion module 132 is connected to the above-mentioned first sending module 94, and is used for compressing the RTP message to be sent to the receiving end according to the compression mode negotiated with the receiving end in advance, and when the number of failures of the compressed RTP message exceeds the first After a threshold and/or the failure time of continuously compressing RTP messages exceeds the second threshold, delete the above-mentioned compression table; the third sending module 134 is connected to the above-mentioned second deleting module 132, and is used to send a second notification message to the receiving end, Wherein, the second notification message is used to notify the receiving end to delete the above-mentioned decompression table.
图14是根据本发明实施例的第一种报文处理装置的优选结构框图四，如图14所示，该装置除包括图10所示的所有模块外，还包括第二接收模块142和第三删除模块144，下面对该装置进行说明。图14仅是一种示例，第二接收模块142还可以连接至上述压缩模块92。Fig. 14 is a preferred structural block diagram 4 of the first message processing device according to an embodiment of the present invention. As shown in Fig. 14, the device includes a second receiving module 142 and a Three delete module 144, the device will be described below. FIG. 14 is only an example, and the second receiving module 142 may also be connected to the above-mentioned compression module 92 .
第二接收模块142，连接至上述第一发送模块94，用于在通过卫星将压缩后的RTP报文传输给接收端之后，接收来自上述接收端的用于通知删除压缩表的第三通知消息；第三删除模块144，连接至上述第二接收模块142，用于根据上述第三通知消息删除压缩表。The second receiving module 142 is connected to the above-mentioned first sending module 94, and is used to receive a third notification message from the above-mentioned receiving end for notifying the deletion of the compression table after the compressed RTP message is transmitted to the receiving end through the satellite; The third deleting module 144 is connected to the second receiving module 142 and configured to delete the compression table according to the third notification message.
在一个可选的实施例中，上述第三通知消息包括以下至少之一：接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。In an optional embodiment, the above-mentioned third notification message includes at least one of the following: the number of times the receiving end fails to decompress the compressed RTP packets exceeds the first threshold and/or continuously decompresses the compressed RTP packets A notification message sent when the failure time exceeds the second threshold; a notification message sent by the receiving end after receiving the second real-time transport control protocol RTCP message carrying a hangup instruction.
在一个可选的实施例中，上述报文处理装置位于第一网关或终端中，接收端包括第二网关；或者，上述报文处理装置位于第二网关中，接收端包括第一网关或终端。In an optional embodiment, the above message processing device is located in the first gateway or terminal, and the receiving end includes the second gateway; or, the above message processing device is located in the second gateway, and the receiving end includes the first gateway or terminal .
在本发明实施例中还提供了一种报文处理装置，图15是根据本发明实施例的第二种报文处理装置的结构框图，如图15所示，该装置包括第三接收模块152和解压缩模块154，下面对该装置进行说明。In the embodiment of the present invention, a message processing device is also provided. FIG. 15 is a structural block diagram of a second message processing device according to an embodiment of the present invention. As shown in FIG. 15 , the device includes a third receiving module 152 and decompression module 154, the device will be described below.
第三接收模块152，用于接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；解压缩模块154，连接至上述第三接收模块152，用于根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。The third receiving module 152 is used to receive the compressed real-time transport protocol RTP message sent by the sending end through the satellite; the decompression module 154 is connected to the third receiving module 152 for decompression according to the negotiation with the sending end Decompresses the compressed RTP packet in the decompressed mode.
图16是根据本发明实施例的第二种报文处理装置的优选结构框图一，如图16所示，该装置除包括图15所示的所有模块外，还包括第二协商模块162，下面对该装置进行说明。Fig. 16 is a preferred structural block diagram 1 of a second message processing device according to an embodiment of the present invention. As shown in Fig. 16, the device includes not only all the modules shown in Fig. 15, but also a second negotiation module 162, the following Facing this device, a description will be given.
第二协商模块162，连接至上述解压缩模块154，用于通过如下方式与发送端协商解压缩方式：接收来自发送端的压缩表；根据上述压缩表建立用于解压缩压缩后的RTP报文的解压缩表。The second negotiation module 162 is connected to the above-mentioned decompression module 154, and is used for negotiating the decompression mode with the sender in the following manner: receiving the compression table from the sender; establishing the RTP message for decompressing the compressed RTP message according to the above-mentioned compression table Unzip the table.
图17是根据本发明实施例的第二种报文处理装置的优选结构框图二，如图17所示，该装置除包括图16所示的所有模块外，还包括第四接收模块172和第四删除模块174，下面对该装置进行说明。图17仅是一种示例，第四接收模块172还可以连接至上述第二协商模块162。Fig. 17 is a preferred structural block diagram II of the second message processing device according to an embodiment of the present invention. As shown in Fig. 17, the device includes not only all the modules shown in Fig. Four deletion module 174, the device will be described below. FIG. 17 is only an example, and the fourth receiving module 172 may also be connected to the above-mentioned second negotiating module 162 .
第四接收模块172，连接至上述解压缩模块154，用于在根据上述压缩表建立用于解压缩压缩后的RTP报文的所述解压缩表之后，接收来自发送端的第四通知消息；第四删除模块174，连接至上述第四接收模块172，用于根据上述第四通知消息删除解压缩表。The fourth receiving module 172 is connected to the above-mentioned decompression module 154, and is used to receive the fourth notification message from the sending end after establishing the decompression table for decompressing the compressed RTP message according to the above-mentioned compression table; The fourth deletion module 174 is connected to the fourth receiving module 172 and configured to delete the decompression table according to the fourth notification message.
在一个可选的实施例中，上述第四通知消息包括以下至少之一：发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；上述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。In an optional embodiment, the fourth notification message includes at least one of the following: the number of times the sender fails to compress the RTP packets to be sent exceeds the first threshold and/or continuously compresses the RTP packets to be sent A notification message sent when the failure time exceeds the second threshold; a notification message sent by the sending end after receiving the first real-time transport control protocol RTCP message carrying a hangup instruction.
图18是根据本发明实施例的第二种报文处理装置的优选结构框图三，如图18所示，当上述第四通知消息包括发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，上述装置还包括第四发送模块182，下面对该装置进行说明。Fig. 18 is a preferred structural block diagram 3 of the second message processing device according to an embodiment of the present invention. As shown in Fig. 18, when the above-mentioned fourth notification message includes that the sending end receives the first RTCP message carrying the hang-up instruction When the notification message is sent after the message, the above device further includes a fourth sending module 182, and the device will be described below.
第四发送模块182，连接至上述第四删除模块174，用于在根据上述第四通知消息删除解压缩表之后，向发送端发送成功删除响应，其中，该成功删除响应用于指示发送端删除压缩表。The fourth sending module 182 is connected to the above-mentioned fourth deleting module 174, and is used to send a successful deletion response to the sending end after deleting the decompression table according to the above-mentioned fourth notification message, wherein the successful deletion response is used to instruct the sending end to delete Compression tables.
图19是根据本发明实施例的第二种报文处理装置的优选结构框图四，如图19所示，该装置除包括图16所示的模块外，还包括第五接收模块192、第五发送模块194和第五删除模块196，下面对该装置进行说明。图19仅是一种示例，第五接收模块192还可以连接至上述第二协商模块162。Fig. 19 is a preferred structural block diagram 4 of a second message processing device according to an embodiment of the present invention. As shown in Fig. 19, the device includes a fifth receiving module 192, a fifth The sending module 194 and the fifth deleting module 196 are described below. FIG. 19 is only an example, and the fifth receiving module 192 may also be connected to the above-mentioned second negotiating module 162 .
第五接收模块192，连接至上述解压缩模块154，用于在接收来自发送端的压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；第五发送模块194，连接至上述第五接收模块192，用于向发送端发送第五通知消息，其中，该第五通知消息用于通知发送端删除压缩表；第五删除模块196，连接至上述第五发送模块194，用于在接收到来自上述发送端的成功删除响应后，删除解压缩表。The fifth receiving module 192 is connected to the above-mentioned decompression module 154, and is used to receive the second real-time transmission control protocol RTCP message carrying a hangup instruction after receiving the compression table from the sending end; the fifth sending module 194 is connected to the above-mentioned The fifth receiving module 192 is configured to send a fifth notification message to the sending end, wherein the fifth notification message is used to notify the sending end to delete the compression table; the fifth deleting module 196 is connected to the fifth sending module 194 for After receiving a successful delete response from the above sender, delete the decompression table.
图20是根据本发明实施例的第二种报文处理装置的优选结构框图五，如图20所示，该装置除包括图16所示的模块外，还包括处理模块202，下面对该装置进行说明。图20仅是一种示例，处理模块202还可以连接至上述第二协商模块162。Fig. 20 is a preferred structural block diagram five of the second message processing device according to an embodiment of the present invention. As shown in Fig. 20, the device includes a processing module 202 in addition to the modules shown in Fig. 16, the following The device is described. FIG. 20 is only an example, and the processing module 202 may also be connected to the above-mentioned second negotiating module 162 .
处理模块202，连接至上述压缩模块154，用于在根据与发送端协商的解压缩方式解压缩压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除上述解压缩表，并向发送端发送第六通知消息，其中，该第六通知消息用于通知发送端删除压缩表。The processing module 202, connected to the above-mentioned compression module 154, is used to decompress the compressed RTP message according to the decompression method negotiated with the sending end, and the number of failures to decompress the compressed RTP message exceeds the first threshold and /or after the time of continuous decompression of the compressed RTP message exceeds the second threshold, delete the above-mentioned decompression table, and send a sixth notification message to the sender, where the sixth notification message is used to notify the sender to delete the compression surface.
在一个可选的实施例中，上述报文处理装置位于第二网关中，发送端包括第一网关或终端；或者，上述报文处理装置位于第一网关或终端中，发送端包括第二网关。In an optional embodiment, the above-mentioned message processing device is located in the second gateway, and the sending end includes the first gateway or terminal; or, the above-mentioned message processing device is located in the first gateway or terminal, and the sending end includes the second gateway .
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。It should be noted that each of the above-mentioned modules can be implemented by software or hardware. For the latter, it can be implemented in the following manner, but not limited to this: the above-mentioned modules are all located in the same processor; or, the above-mentioned modules are respectively located in multiple in the processor.
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：The embodiment of the invention also provides a storage medium. Optionally, in this embodiment, the above-mentioned storage medium may be configured to store program codes for performing the following steps:
S11，按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；S11, compressing the real-time transport protocol RTP message to be sent to the receiving end according to the compression method negotiated with the receiving end;
S12，在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。S12. After the compression is successful, send the compressed RTP message to the receiving end through the satellite.
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：Optionally, the storage medium is also configured to store program codes for performing the following steps:
S21，接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；S21, receiving the compressed real-time transport protocol RTP message sent by the sending end through the satellite;
S22，根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。S22. Decompress the compressed RTP packet according to the decompression mode negotiated with the sending end.
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(RandomAccess Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。Optionally, in this embodiment, the above-mentioned storage medium may include but not limited to: U disk, read-only memory (Read-Only Memory, ROM for short), random access memory (Random Access Memory, RAM for short), mobile Various media that can store program codes, such as hard disks, magnetic disks, or optical disks.
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述各实施例中的各个步骤。Optionally, in this embodiment, the processor executes the steps in the foregoing embodiments according to the program code stored in the storage medium.
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。Optionally, for specific examples in this embodiment, reference may be made to the examples described in the foregoing embodiments and optional implementation manners, and details are not repeated in this embodiment.
采用本发明实施例中的方法和装置，与现有技术相比，能够节省一半以上的语音占用带宽。By adopting the method and device in the embodiment of the present invention, compared with the prior art, more than half of the bandwidth occupied by voice can be saved.
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。Obviously, those skilled in the art should understand that each module or each step of the above-mentioned present invention can be realized by a general-purpose computing device, and they can be concentrated on a single computing device, or distributed in a network formed by multiple computing devices Alternatively, they may be implemented in program code executable by a computing device so that they may be stored in a storage device to be executed by a computing device, and in some cases, in an order different from that shown here The steps shown or described are carried out, or they are separately fabricated into individual integrated circuit modules, or multiple modules or steps among them are fabricated into a single integrated circuit module for implementation. As such, the present invention is not limited to any specific combination of hardware and software.
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510862787.7ACN106817350A (en) | 2015-11-30 | 2015-11-30 | Message processing method and device |
| PCT/CN2016/092367WO2017092389A1 (en) | 2015-11-30 | 2016-07-29 | Packet processing method and device |
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510862787.7ACN106817350A (en) | 2015-11-30 | 2015-11-30 | Message processing method and device |
| Publication Number | Publication Date |
|---|---|
| CN106817350Atrue CN106817350A (en) | 2017-06-09 |
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510862787.7APendingCN106817350A (en) | 2015-11-30 | 2015-11-30 | Message processing method and device |
| Country | Link |
|---|---|
| CN (1) | CN106817350A (en) |
| WO (1) | WO2017092389A1 (en) |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109257772A (en)* | 2017-07-13 | 2019-01-22 | 普天信息技术有限公司 | A kind of sending, receiving method and user equipment of RTP data |
| CN109347538A (en)* | 2018-09-27 | 2019-02-15 | 南京凯瑞得信息科技有限公司 | A method of VoIP communication is realized based on narrowband satellite channel |
| CN110290130A (en)* | 2019-06-21 | 2019-09-27 | 京信通信系统（中国）有限公司 | VOLTE data transmission method, device, access network equipment and storage medium |
| CN110830170A (en)* | 2019-11-12 | 2020-02-21 | 北京理工大学 | A Data Transmission Method Based on ROHC Compression in Satellite Communication |
| WO2022063058A1 (en)* | 2020-09-28 | 2022-03-31 | 中兴通讯股份有限公司 | Netconf protocol-based transmission method, device and storage medium |
| CN118869058A (en)* | 2024-09-25 | 2024-10-29 | 成都星联芯通科技有限公司 | Data compression method, device, satellite gateway station, system and storage medium |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109818901B (en)* | 2017-11-20 | 2021-04-20 | 华为技术有限公司 | Method, device and system for determining message header compression mechanism |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050041660A1 (en)* | 2003-07-08 | 2005-02-24 | Pennec Jean-Francois Le | Packet header compression system and method based upon a dynamic template creation |
| US20070002850A1 (en)* | 2005-06-29 | 2007-01-04 | Guichard James N | System and methods for compressing message headers |
| CN1977516A (en)* | 2004-05-13 | 2007-06-06 | 高通股份有限公司 | Header Compression of Multimedia Data Transmitted in Wireless Communication System |
| CN102882879A (en)* | 2012-10-08 | 2013-01-16 | 中国电子科技集团公司第五十四研究所 | Internet protocol (IP) data compression transmission method applicable to satellite channel |
| CN102938683A (en)* | 2012-09-24 | 2013-02-20 | 华为技术有限公司 | Data processing method and device |
| CN103825869A (en)* | 2012-11-19 | 2014-05-28 | 中兴通讯股份有限公司 | Compression and decompression method for Ethernet message header, and compression and decompression device thereof |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101848492A (en)* | 2010-06-10 | 2010-09-29 | 中兴通讯股份有限公司 | Message transmission method between media gateways, media gateway and wireless communication system |
| CN104283777B (en)* | 2013-07-03 | 2018-08-21 | 华为技术有限公司 | The method and apparatus of message compression |
| KR102192165B1 (en)* | 2013-11-25 | 2020-12-16 | 삼성전자주식회사 | Apparatus and method for processing header compressed packet in eletronic device |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050041660A1 (en)* | 2003-07-08 | 2005-02-24 | Pennec Jean-Francois Le | Packet header compression system and method based upon a dynamic template creation |
| CN1977516A (en)* | 2004-05-13 | 2007-06-06 | 高通股份有限公司 | Header Compression of Multimedia Data Transmitted in Wireless Communication System |
| US20070002850A1 (en)* | 2005-06-29 | 2007-01-04 | Guichard James N | System and methods for compressing message headers |
| CN102938683A (en)* | 2012-09-24 | 2013-02-20 | 华为技术有限公司 | Data processing method and device |
| CN102882879A (en)* | 2012-10-08 | 2013-01-16 | 中国电子科技集团公司第五十四研究所 | Internet protocol (IP) data compression transmission method applicable to satellite channel |
| CN103825869A (en)* | 2012-11-19 | 2014-05-28 | 中兴通讯股份有限公司 | Compression and decompression method for Ethernet message header, and compression and decompression device thereof |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109257772A (en)* | 2017-07-13 | 2019-01-22 | 普天信息技术有限公司 | A kind of sending, receiving method and user equipment of RTP data |
| CN109347538A (en)* | 2018-09-27 | 2019-02-15 | 南京凯瑞得信息科技有限公司 | A method of VoIP communication is realized based on narrowband satellite channel |
| CN109347538B (en)* | 2018-09-27 | 2020-11-24 | 南京凯瑞得信息科技有限公司 | Method for realizing VoIP communication based on narrow-band satellite channel |
| CN110290130A (en)* | 2019-06-21 | 2019-09-27 | 京信通信系统（中国）有限公司 | VOLTE data transmission method, device, access network equipment and storage medium |
| CN110830170A (en)* | 2019-11-12 | 2020-02-21 | 北京理工大学 | A Data Transmission Method Based on ROHC Compression in Satellite Communication |
| WO2022063058A1 (en)* | 2020-09-28 | 2022-03-31 | 中兴通讯股份有限公司 | Netconf protocol-based transmission method, device and storage medium |
| CN118869058A (en)* | 2024-09-25 | 2024-10-29 | 成都星联芯通科技有限公司 | Data compression method, device, satellite gateway station, system and storage medium |
| CN118869058B (en)* | 2024-09-25 | 2024-11-26 | 成都星联芯通科技有限公司 | Data compression method, device, satellite gateway station, system and storage medium |
| Publication number | Publication date |
|---|---|
| WO2017092389A1 (en) | 2017-06-08 |
| Publication | Publication Date | Title |
|---|---|---|
| CN106817350A (en) | Message processing method and device | |
| US10785680B2 (en) | Methods and apparatus for optimizing tunneled traffic | |
| CN106716951B (en) | Method and device for optimizing tunnel traffic | |
| CN111385221B (en) | Data processing method and communication equipment | |
| KR102192165B1 (en) | Apparatus and method for processing header compressed packet in eletronic device | |
| RU2645283C1 (en) | Protocol stack adaptation method and device | |
| CN107645746B (en) | A context update method, system and device | |
| WO2015168840A1 (en) | Data processing method and apparatus | |
| CN107172662A (en) | A kind of communication means and device | |
| WO2022083371A1 (en) | Data transmission method and device | |
| WO2015139324A1 (en) | Configuration indication method and communication device | |
| JP5920466B2 (en) | Communication system, method and program | |
| CN112887497B (en) | Communication method, apparatus and computer storage medium | |
| CN101197825B (en) | Method, system and device for compression message transmission | |
| CN107431965B (en) | A method and device for realizing transmission control protocol TCP transmission | |
| CN101179353A (en) | Method and system of monitoring multimedia service performance | |
| CN107517202B (en) | Binary sending and receiving method of SIP signaling | |
| WO2012155566A1 (en) | Context reuse method and system | |
| WO2017143538A1 (en) | Voice data transmission method and apparatus | |
| CN106941697A (en) | A kind of method and apparatus for sending, receiving timestamp information | |
| CN102469011B (en) | Data transmission method and device | |
| CN107172179B (en) | A kind of bilateral accelerated transmission method and system | |
| CN109219079B (en) | IR message transmission method and communication equipment | |
| CN113746755B (en) | Data processing method, device, equipment and computer readable storage medium | |
| KR101416901B1 (en) | Method and device restoring missed image packets |
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | Application publication date:20170609 | |
| RJ01 | Rejection of invention patent application after publication |