CN106817350A

CN106817350A - Message processing method and device

Info

Publication number: CN106817350A
Application number: CN201510862787.7A
Authority: CN
Inventors: 常伟; 晏文彬; 唐雄; 陈诚; 刘亮
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2015-11-30
Filing date: 2015-11-30
Publication date: 2017-06-09
Also published as: WO2017092389A1

Abstract

The invention provides a kind of message processing method and device, wherein, the method includes：The realtime transmission protocol RTP message for being sent to receiving terminal is compressed according to the compress mode consulted with receiving terminal；After compressing successfully, the RTP messages after compression are sent to by above-mentioned receiving terminal by satellite.By the present invention, solve the problems, such as that bandwidth availability ratio of the voice communication present in correlation technique on satellite communication field is not enough, and then reached the bandwidth availability ratio for improving voice communication on satellite communication field, save the effect of bandwidth resources.

Description

Message processing method and device

Technical Field

The present invention relates to the field of communications, and in particular, to a method and an apparatus for processing a packet.

Background

Since most of the offshore and onshore areas are not covered by the cellular mobile communication system, satellite communication is widely used as an effective supplementary means in the offshore area and the onshore areas, especially in the ocean transportation, drilling, surveying and fishery sectors. The satellite communication is not limited by various factors such as time, place, environment and the like, has the advantages of short opening time, long transmission distance, quick network deployment, irrelevant communication cost and communication distance and the like, and can realize real-time bidirectional transmission of voice and data.

The satellite telephone is one of existing satellite communications, and because the satellite channel has some characteristics different from those of the ground channel, and a Transmission Control Protocol (TCP)/Internet Protocol (IP) Protocol is originally designed for the ground network, the transmission performance of the TCP/IP Protocol on the satellite channel is poor. There are the following problems:

1) on one hand, the delay is large, the delay of a satellite channel is long, and the typical satellite communication delay is about 540ms, which causes continuous retransmission of a TCP protocol and causes congestion of a communication link. On the other hand, the actual satellite communication has high error codes, and the TCP protocol cannot distinguish data loss caused by network blockage or data loss caused by error codes, and the TCP protocol can be uniformly considered as caused by network blockage, so that the sending window of the TCP is reduced, and the transmission bandwidth is reduced;

2) the satellite communication bandwidth is low and the rental cost is high, when Voice over internet Protocol (VOIP for short) based on the network Protocol adopts different coding formats, different data bandwidths are required, for example, the bandwidth required by G729 is 8Kbps, and a message header (Real-time Transport Protocol (RTP for short) plus a User data Protocol (User Date Protocol, UDP plus IP header) occupies 16 Kbps, so that one path of VOIP telephone needs to occupy the bandwidth of 24Kbps, which is a great waste of resources for satellite communication.

Therefore, in the related art, there is a problem of insufficient bandwidth utilization rate of voice communication in the satellite communication field, and no effective solution has been proposed for the problem.

Disclosure of Invention

The invention provides a message processing method and a message processing device, which are used for at least solving the problem of insufficient bandwidth utilization rate of voice communication in the satellite communication field in the related technology.

According to an aspect of the present invention, there is provided a packet processing method, including: compressing a real-time transport protocol (RTP) message to be sent to a receiving end according to a compression mode negotiated with the receiving end; and after the compression is successful, sending the compressed RTP message to the receiving end through a satellite.

Optionally, the compression method is negotiated with the receiving end by the following method: establishing a compression table according to related information of an RTP message to be sent to the receiving end, wherein the compression table carries an identifier of a currently selected compression mode and related information of the RTP message, and when the currently selected compression mode is reliable header compression ROCH or configuration compression real-time protocol CRTP, the related information comprises a source Internet Protocol (IP) address, a destination IP address, a User Data Protocol (UDP) source port, a UDP destination port and an RTP header of the RTP message; or, when the compression mode is configuring a compressed user data protocol CUDP, the related information includes a source IP address, a destination IP address, a UDP source port and a UDP destination port of the RTP packet; and sending the established compression table to the receiving end, wherein the compression table is used for indicating the receiving end to establish a decompression table corresponding to the compression table.

Optionally, the related information of the RTP packet is obtained by: judging whether the received message to be sent to the receiving end is an RTP message or not; and extracting the relevant information of the message as the relevant information of the RTP message under the condition that the message is the RTP message according to the judgment result.

Optionally, the determining whether the received packet to be sent to the receiving end is an RTP packet includes: judging whether the message to be sent to the receiving end is a UDP message or not; after the message is determined to be a UDP message, judging whether the byte number of a UDP data frame of the message is larger than a preset number, and if so, judging whether a predetermined bit in the UDP load of the message is a preset value; when the predetermined bit in the UDP load of the message is determined to be a predetermined value, judging whether the coding format of the PAYLOAD PAYLOAD of the message is the coding format of RTP; and when determining that the PAYLOAD of the message is the RTP coding format, determining that the message is the RTP message.

Optionally, after sending the created compression table to the receiving end, the method further includes: receiving a first real-time transport 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 for notifying the receiving end to delete the decompression table; and deleting the compression table after receiving a successful deletion response from the receiving end.

Optionally, after compressing the RTP packet to be sent to the receiving end according to a compression method negotiated with the receiving end in advance, the method further includes: deleting the compression table when the failure times of compressing the RTP message exceed a first threshold value and/or the failure time of continuously compressing the RTP message exceed a second threshold value; and sending a second notification message to the receiving end, wherein the second notification message is used for notifying the receiving end to delete the decompression table.

Optionally, after transmitting the compressed RTP packet to the receiving end through a satellite, the method further includes: receiving a third notification message for notifying deletion of the compression table from the receiving end; deleting the compression table according to the third notification message.

Optionally, the third notification message comprises at least one of: the receiving end sends the notification message under the condition that the failure times of the RTP message after decompression and compression exceed a first threshold value and/or the failure time of the RTP message after continuous decompression and compression exceeds a second threshold value; and the receiving end receives the notification message sent after receiving the second real-time transport control protocol RTCP message carrying the hang-up instruction.

According to another aspect of the present invention, a method for processing a packet is provided, including: receiving a compressed real-time transport protocol (RTP) message sent by a sending end through a satellite; and decompressing the compressed RTP message according to a decompression mode negotiated with the sending end.

Optionally, negotiating the decompression method with the sending end by: receiving a compression table from the sending end; and establishing a decompression table for decompressing the compressed RTP message according to the compression table.

Optionally, after the decompressing table for decompressing the compressed RTP packet is established according to the compression table, the method further includes: receiving a fourth notification message from the sending end; and deleting the decompression table according to the fourth notification message.

Optionally, the fourth notification message includes at least one of: the sending end sends the notification message under the condition that the failure times of compressing the RTP message to be sent exceed a first threshold value and/or the failure time of continuously compressing the RTP message to be sent exceeds a second threshold value; and the sending end sends a notification message after receiving a first real-time transport control protocol (RTCP) message carrying a hangup instruction.

Optionally, when the fourth notification message includes a notification message sent by the sending end after receiving the first RTCP packet carrying a hang-up instruction, after deleting the decompression table according to the fourth notification message, the method further includes: and sending a successful deletion response to the sending end, wherein the successful deletion response is used for indicating the sending end to delete the compression table.

Optionally, after receiving the compression table from the transmitting end, the method further includes: receiving a second real-time transport control protocol (RTCP) message carrying a hang-up instruction; sending a fifth notification message to the sending end, wherein the fifth notification message is used for notifying the sending end to delete the compression table; and deleting the decompression table after receiving a successful deletion response from the sending end.

Optionally, after decompressing the compressed RTP packet according to the decompression method negotiated with the sending end, the method further includes: and deleting the decompression table and sending a sixth notification message to the sending end when the failure times of decompressing and compressing the compressed RTP message exceed a first threshold value and/or the failure time of continuously decompressing and compressing the compressed RTP message exceed a second threshold value, wherein the sixth notification message is used for notifying the sending end to delete the compression table.

According to another aspect of the present invention, there is provided a message processing apparatus, including: the compression module is used for compressing the real-time transport protocol RTP message to be sent to the receiving end according to a compression mode negotiated with the receiving end; and the first sending module is used for sending the compressed RTP message to the receiving end through a satellite after the compression is successful.

Optionally, the apparatus further includes a first negotiation module, configured to negotiate the compression method with the receiving end in the following manner: establishing a compression table according to related information of an RTP message to be sent to the receiving end, wherein the compression table carries an identifier of a currently selected compression mode and related information of the RTP message, and when the currently selected compression mode is reliable header compression ROCH or configuration compression real-time protocol CRTP, the related information comprises a source Internet Protocol (IP) address, a destination IP address, a User Data Protocol (UDP) source port, a UDP destination port and an RTP header of the RTP message; or, when the compression mode is configuring a compressed user data protocol CUDP, the related information includes a source IP address, a destination IP address, a UDP source port and a UDP destination port of the RTP packet; and sending the established compression table to the receiving end, wherein the compression table is used for indicating the receiving end to establish a decompression table corresponding to the compression table.

Optionally, when acquiring the relevant information of the RTP packet, the first negotiation module includes: a judging unit, configured to judge whether a received packet to be sent to the receiving end is an RTP packet; and the extracting unit is used for extracting the relevant information of the message as the relevant information of the RTP message under the condition that the message is the RTP message according to the judgment result.

Optionally, the determining unit determines whether the received packet to be sent to the receiving end is an RTP packet by: judging whether the message to be sent to the receiving end is a UDP message or not; after the message is determined to be a UDP message, judging whether the byte number of a UDP data frame of the message is larger than a preset number, and if so, judging whether a predetermined bit in the UDP load of the message is a preset value; when the predetermined bit in the UDP load of the message is determined to be a predetermined value, judging whether the coding format of the PAYLOAD PAYLOAD of the message is the coding format of RTP; and when determining that the PAYLOAD of the message is the RTP coding format, determining that the message is the RTP message.

Optionally, the apparatus further comprises: the first receiving module is used for receiving a first real-time transport control protocol (RTCP) message carrying a hang-up instruction after the established compression table is sent to the receiving end; a second sending module, configured to send a first notification message to the receiving end, where the first notification message is used to notify the receiving end to delete the decompression table; and the first deleting module is used for deleting the compression table after receiving a successful deleting response from the receiving end.

Optionally, the apparatus further comprises: a second deleting module, configured to delete the compression table after compressing the RTP packet to be sent to the receiving end according to a compression manner negotiated with the receiving end in advance, and after the number of times of RTP packet compression failures exceeds a first threshold and/or the time of RTP packet continuous compression failures exceeds a second threshold; a third sending module, configured to send a second notification message to the receiving end, where the second notification message is used to notify the receiving end to delete the decompression table.

Optionally, the apparatus further comprises: a second receiving module, configured to receive a third notification message from the receiving end for notifying deletion of the compression table after the compressed RTP packet is transmitted to the receiving end through a satellite; and the third deleting module is used for deleting the compression table according to the third notification message.

Optionally, the message processing apparatus is located in a first gateway or a terminal, and the receiving end includes a second gateway; or, the message processing apparatus is located in a second gateway, and the receiving end includes a first gateway or a terminal.

According to another aspect of the present invention, there is provided a message processing apparatus, including: the third receiving module is used for receiving the compressed real-time transport protocol RTP message sent by the sending end through the satellite; and the decompression module is used for decompressing the compressed RTP message according to a decompression mode negotiated with the sending end.

Optionally, the apparatus further includes a second negotiation module, configured to negotiate the decompression method with the sending end in the following manner: receiving a compression table from the sending end; and establishing a decompression table for decompressing the compressed RTP message according to the compression table.

Optionally, the apparatus further comprises: a fourth receiving module, configured to receive a fourth notification message from the sending end after the decompression table for decompressing the compressed RTP packet is established according to the compression table; and the fourth deleting module is used for deleting the decompression table according to the fourth notification message.

Optionally, when the fourth notification message includes a notification message sent by the sending end after receiving the first RTCP packet carrying a hang-up instruction, the apparatus further includes: and a fourth sending module, configured to send a successful deletion response to the sending end after deleting the decompression table according to the fourth notification message, where the successful deletion response is used to instruct the sending end to delete the compression table.

Optionally, the apparatus further comprises: a fifth receiving module, configured to receive a second real-time transport control protocol RTCP packet carrying a hang-up instruction after receiving the compression table from the sending end; a fifth sending module, configured to send a fifth notification message to the sending end, where the fifth notification message is used to notify the sending end to delete the compression table; and the fifth deleting module is used for deleting the decompression table after receiving a successful deleting response from the sending end.

Optionally, the apparatus further comprises: and the processing module is configured to delete the decompression table and send a sixth notification message to the sending end after the compressed RTP packet is decompressed according to the decompression manner negotiated with the sending end and the number of times of failure in decompressing the compressed RTP packet exceeds a first threshold and/or the time of failure in continuously decompressing the compressed RTP packet exceeds a second threshold, where the sixth notification message is used to notify the sending end to delete the compression table.

Optionally, the message processing apparatus is located in a second gateway, and the sending end includes a first gateway or a terminal; or, the message processing apparatus is located in a first gateway or a terminal, and the sending end includes a second gateway.

According to the invention, the real-time transport protocol RTP message to be sent to the receiving end is compressed by adopting a compression mode negotiated with the receiving end; and after the compression is successful, sending the compressed RTP message to the receiving end through a satellite. The problem that the bandwidth utilization rate of voice communication in the satellite communication field is insufficient in the related technology is solved, and the effects of improving the bandwidth utilization rate of the voice communication in the satellite communication field and saving bandwidth resources are achieved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

FIG. 1 is a flow diagram of a message processing method according to an embodiment of the invention;

FIG. 2 is a flow chart of a message processing method according to an embodiment of the invention;

FIG. 3 is an interactive flow diagram of a voice call and hang-up process according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of a satellite communication transmission scenario according to an embodiment of the invention;

fig. 5 is a flowchart of determining an RTP packet according to an embodiment of the present invention;

fig. 6 is a schematic diagram of an ROHC custom negotiation packet encapsulation format according to an embodiment of the present invention;

FIG. 7 is a UE direct access satellite communication scenario according to an embodiment of the present invention;

fig. 8 is a schematic diagram of a custom negotiation packet encapsulation format according to an embodiment of the present invention;

fig. 9 is a block diagram of a first message processing apparatus according to an embodiment of the present invention;

fig. 10 is a block diagram of a preferred structure of a first message processing apparatus according to an embodiment of the present invention;

fig. 11 is a block diagram of a first negotiation module 102 in a first message processing apparatus according to an embodiment of the present invention;

fig. 12 is a block diagram of a preferred structure of a first message processing apparatus according to an embodiment of the present invention;

fig. 13 is a block diagram of a preferred structure of a first message processing apparatus according to the embodiment of the present invention;

fig. 14 is a block diagram of a preferred structure of a first message processing apparatus according to the embodiment of the present invention;

fig. 15 is a block diagram of a second message processing apparatus according to an embodiment of the present invention;

fig. 16 is a block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention;

fig. 17 is a block diagram of a preferred structure of a second message processing apparatus according to the embodiment of the present invention;

fig. 18 is a block diagram of a preferred structure of a second message processing apparatus according to the embodiment of the present invention;

fig. 19 is a block diagram of a preferred structure of a second message processing apparatus according to the embodiment of the present invention;

fig. 20 is a block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention.

Detailed Description

The invention will be described in detail hereinafter with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

In this embodiment, a message processing method is provided, and fig. 1 is a flowchart of a message processing method according to an embodiment of the present invention, as shown in fig. 1, the flowchart includes the following steps:

step S102, compressing the RTP message to be sent to the receiving end according to the compression mode negotiated with the receiving end;

and step S104, after the compression is successful, the compressed RTP message is sent to the receiving end through the satellite.

It can be known from the above steps that, when sending the RTP packet to the receiving end, the RTP packet is first compressed (since the packet header of the RTP packet occupies a large bandwidth, when compressing the RTP packet, only the IP header, the UDP header, and the RTP header of the RTP packet may be compressed), and then the compressed RTP packet is sent to the receiving end, wherein, the size of the compressed RTP message is much smaller than that of the original uncompressed RTP message, thus reducing the occupation of bandwidth, thereby realizing the purpose of sending more RTP messages on a certain bandwidth, improving the utilization rate of the bandwidth, solving the problem of insufficient bandwidth utilization rate of voice communication in the satellite communication field in the related technology, therefore, the effects of improving the bandwidth utilization rate of voice communication in the satellite communication field and saving bandwidth resources are achieved.

In an alternative embodiment, the compression mode may be negotiated with the receiving end as follows: establishing a Compression table according to related information of an RTP message to be sent to a receiving end, wherein the Compression table carries an identifier of a currently selected Compression mode and related information of the RTP message, and when the currently selected Compression mode is reliable header Compression (ROCH for short) or configuration compressed real-Time Protocol (CRTP for short), the related information comprises a source Internet Protocol (IP) address, a destination IP address, a User Data Protocol (UDP) source port, a UDP destination port and an RTP header of the RTP message; or, when the compression mode is a configuration Compressed User Data Protocol (CUDP), the related information includes a source IP address, a destination IP address, a UDP source port, and a UDP destination port of the RTP packet; and sending the established compression table to a receiving end, wherein the compression table is used for indicating the receiving end to establish a decompression table corresponding to the compression table. After the receiving end successfully establishes the decompression table, a response message for establishing the OK can be returned. It should be noted that the above compression methods are merely examples, and other compression methods may be adopted, and similarly, when other compression methods are adopted, a compression table corresponding to the other compression methods needs to be established, and the contents in the compression tables corresponding to the different compression methods may be different. After the negotiation is completed, both ends can use the negotiation to perform the compression and decompression operations of the RTP packet.

In an optional embodiment, the relevant information of the RTP packet may be obtained by: judging whether the received message to be sent to a receiving end is an RTP message or not; and under the condition that the message is the RTP message according to the judgment result, extracting the related information of the message as the related information of the RTP message. The message to be sent to the receiving end may be a first RTP message that needs to be sent to the receiving end, and in order to avoid an excessive delay, the first RTP message may be directly sent to the receiving end without being compressed.

The manner of determining whether the packet is an RTP packet may be a plurality of manners, and the determination method provided in the embodiment of the present invention is described below: judging whether the received message to be sent to the receiving end is an RTP message comprises the following steps: judging whether a message to be sent to a receiving end is a UDP message or not; after determining that the packet is a UDP packet, determining whether the number of bytes of a UDP data frame of the packet is greater than a predetermined number (for example, the predetermined number is 12 bytes, that is, whether the predetermined number is greater than the length of a fixed header of an RTP packet), and if the predetermined number is greater than the predetermined number, determining whether a predetermined bit (for example, the first two bits) in a UDP payload of the packet is a predetermined value (for example, 0x10, that is, whether the predetermined bit is the same as the current RTP version number); when the predetermined bit in the UDP load of the message is determined to be a predetermined value, judging whether the coding format of the PAYLOAD PAYLOAD of the message is the coding format of RTP; and when determining that the PAYLOAD of the message is the RTP coding format, determining that the message is the RTP message. By adopting the judgment scheme in the embodiment of the invention, whether the message is the RTP message is determined by judging whether the coding format is the RTP coding format, the judgment steps can be simplified, and the judgment accuracy is improved. In the subsequent process, after receiving the message to be sent to the receiving end, it may also be determined whether the received message is an RTP message according to the above method, and when it is determined that the received message is the RTP message, the message determined to be the RTP message is compressed according to the method in the above embodiment, and then the compressed RTP message is sent.

The main body for executing the above operation may be a sending end, and after the compression table and the decompression table are established, the sending end and the receiving end may also delete or update the compression table and the decompression table, in an optional embodiment, after the established compression table is sent to the receiving end, the method further includes: receiving a first real-time transport control protocol (RTCP) message carrying a hang-up instruction; sending a first notification message to a receiving end, wherein the first notification message is used for notifying the receiving end to delete a decompression table; and deleting the compression table after receiving the successful deletion response from the receiving end. Wherein, a specific field in the RTCP message may be set to BYE, and the specific field set to BYE may be the hang-up command.

In an optional embodiment, after compressing the RTP packet to be sent to the receiving end according to a compression method negotiated with the receiving end in advance, the method further includes: deleting the compression table after the failure times of compressing the RTP message exceed a first threshold value and/or the failure time of continuously compressing the RTP message exceed a second threshold value; and sending a second notification message to the receiving end, wherein the second notification message is used for notifying the receiving end to delete the decompression table. In this embodiment, the compression table may be deleted after the RTP packet compression fails, or the compression table may be deleted after the number of times of the RTP packet compression failure exceeds the predetermined number (the predetermined number may be greater than 1), or the compression table may be deleted when the time of the RTP packet compression failure exceeds a certain value, and then the receiving end is notified to delete the decompression table.

In the above embodiment, it is described that the deletion of the compression table and the decompression table is triggered by the sending end (i.e., the end performing the above operation), of course, the deletion of the compression table and the decompression table may also be triggered by the receiving end, in an alternative embodiment, after the compressed RTP packet is transmitted to the receiving end through the satellite, the method further includes: receiving a third notification message for notifying the deletion of the compression table from the receiving end; deleting the compression table according to the third notification message.

In an optional embodiment, the third notification message may include at least one of: the receiving end sends the notification message under the condition that the failure times of the RTP message after decompression and compression exceed a first threshold value and/or the failure time of the RTP message after continuous decompression and compression exceeds a second threshold value; and the receiving end receives the notification message sent after receiving the second real-time transport control protocol RTCP message carrying the hang-up instruction. Similarly, the notification message sent by the receiving end when the RTP packet after decompression and compression fails may be a notification message sent after the receiving end fails to decompress once, or may be a notification message sent after the number of times of decompression failure of the receiving end exceeds a predetermined number of times, or may be a notification message sent after the time of continuous decompression failure of the receiving end 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 may initiate a process of negotiating and establishing the decompression table of the compression table again.

Fig. 2 is a flowchart of a message processing method according to an embodiment of the present invention, and as shown in fig. 2, the flowchart includes the following steps:

step S202, receiving a compressed real-time transport protocol (RTP) message sent by a sending end through a satellite;

step S204, decompressing the compressed RTP message according to the decompression mode negotiated with the sending end.

It can be known from the above steps that the received RTP packet is a compressed RTP packet, that is, when the sending end sends the RTP packet, the sending end first compresses the RTP packet, and then sends the compressed RTP packet, wherein the size of the compressed RTP packet is much smaller than that of the original uncompressed RTP packet, so that the occupation of the bandwidth can be reduced, thereby achieving the purpose of sending more RTP packets in a certain bandwidth, improving the utilization rate of the bandwidth, solving the problem of insufficient bandwidth utilization rate of the voice communication in the satellite communication field in the related art, and further achieving the effects of improving the bandwidth utilization rate of the voice communication in the satellite communication field and saving the bandwidth resources.

In an optional embodiment, the foregoing decompression manner may be negotiated with the sending end in the following manner: receiving a compression table from a sending end; and establishing a decompression table for decompressing the compressed RTP message according to the compression table. It should be noted that what compression method is used can be identified in the compression table (for example, ROCH compression method or CUDP compression method is used), and the contents in the compression table corresponding to different compression methods may be different. After the negotiation is completed, both ends can use the negotiation to perform the compression and decompression operations of the RTP packet.

In an optional embodiment, after the decompression table used for decompressing the compressed RTP packet is established according to the compression table, the method further includes: receiving a fourth notification message from the sending end; and deleting the decompression table according to the fourth notification message.

In an optional embodiment, the fourth notification message may include at least one of: the method comprises the steps that a sending end sends a notification message under the condition that the failure times of compressing an RTP message to be sent exceed a first threshold value and/or the failure time of continuously compressing the RTP message to be sent exceeds a second threshold value; and the sending end sends the notification message after receiving the first real-time transport control protocol RTCP message carrying the hang-up instruction. Optionally, the notification message sent by the sending end when the RTP packet compression fails may be a notification message sent after the sending end fails to compress once, or may be a notification message sent after the number of times of the sending end compression failure exceeds a predetermined number of times, or may be a notification message sent after the time of the sending end continuing the compression failure exceeds a certain value, and before the sending end sends the notification message, the sending end may delete the compression table in the sending end first; as can be seen from the above description, the RTCP message may carry a hangup command in such a manner that a predetermined field in RTCP is set to BYE.

In an optional embodiment, when the fourth notification message includes a notification message sent by the sending end after receiving the first RTCP packet carrying the hangup instruction, after deleting the decompression table according to the fourth notification message, the method further includes: and sending a successful deletion response to the sending end, wherein the successful deletion response is used for indicating the sending end to delete the compression table.

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 may also be triggered by the receiving end, and in an alternative embodiment, 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 hang-up instruction; sending a fifth notification message to the sending end, wherein the fifth notification message is used for notifying the sending end to delete the compression table; and deleting the decompression table after receiving a successful deletion response from the sending end. The RTCP message may carry the hang-up instruction in a manner that a predetermined field in the RTCP message is set to BYE.

In an optional embodiment, after decompressing the compressed RTP packet according to the decompression method negotiated with the sending end, the method further includes: and deleting the decompression table and sending a sixth notification message to the sending end when the failure times of decompressing and compressing the compressed RTP message exceed a first threshold value and/or the failure time of continuously decompressing and compressing the compressed RTP message exceed a second threshold value, wherein the sixth notification message is used for notifying the sending end to delete the compression table. In this embodiment, the decompression table may be deleted after the RTP packet fails to be decompressed, or the decompression table may be deleted after the number of times of the RTP packet decompression failure exceeds the predetermined number (the predetermined number may be greater than 1), or the decompression table may be deleted when the time of the RTP packet decompression failure exceeds a certain value, and then the sending end is notified to delete the compression table.

The following describes the overall process of the present invention, taking the above-mentioned sending end as gateway GW1 and the receiving end as gateway GW2 as an example:

fig. 3 is an interactive flow chart of a voice call and hang-up procedure according to an embodiment of the present invention, as shown in fig. 3, the flow chart includes the following steps:

step S301, when a User Equipment (UE) of a calling party (hereinafter, UE) needs to initiate a voice call to a called party, the UE initiates a voice call to an IP-to-media subsystem (IMS);

step S302, when IMS confirms that UE is allowed to carry out voice call, a response of successful voice call is returned to UE;

step S303, UE sends voice message (corresponding to the RTP message) to gateway GW1 on UE side;

step S304, the GW1 determines the compression mode, and establishes the compression table in the compression mode according to the voice message, the establishment process is as described in the above embodiments, and is not described here; and GW1 sends the voice message and the established compression table to gateway GW2 of the called side UE, GW2 establishes the decompression table corresponding to the compression table according to the compression table;

step S305, GW1 establishes a compression session with GW 2;

step S306, GW2 returns message of successful establishment of compressed session to GW 1;

step S307, GW2 sends the voice message sent by GW1 to IMS;

step S308, the UE sends a voice message to GW 1;

step S309, GW1 compresses the voice message sent by UE according to the determined compression mode, and sends the compressed voice message to GW 2;

step S310, GW2 decompresses the received compressed voice message and sends the decompressed voice message to IMS;

step S311, the GW2 receives the voice packet sent by the UE on the called side, and the GW2 negotiates with the GW1 a compression/decompression manner in the same manner as described above;

step S312, GW2 compresses the voice message sent by the UE on the called side according to the compression mode negotiated, and sends it to GW 1;

step S313, GW1 decompresses the received compressed voice message from the called UE and sends it to the calling UE;

step S314, the calling party UE determines that the voice call needs to be hung up, and sends a notice of hanging up the voice call to the IMS;

step S315, GW1 notifies GW2 to delete the compression session;

step S316, GW2 returns the successful message of deleting compressed session to GW 1;

step S317, the IMS sends a call response message to the calling UE, and the voice call is ended.

The invention is described below with reference to specific application scenarios:

example 1 was carried out:

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, a voice message is compressed by using a ROHC compression method (CRTP compression and ROHC compression are similar, and here, ROHC is taken as an example for description), where ROHC is generally used for an air interface of wireless communication, and in this example, is used in a scenario of satellite transmission voice compression.

The processing steps of the flow section are as follows:

establishing connection:

fig. 5 is a flowchart of determining an RTP packet according to an embodiment of the present invention, after receiving a packet, GW1 may determine whether the packet is an RTP packet according to the flowchart shown in fig. 5, where the determining process includes the following steps:

step S501, a packet filtering module (the filtering module can be one of a sending end or a receiving end) analyzes all received messages;

step S502, the packet filtering module judges whether the message is a UDP message, if the message is the UDP message, the step S503 is carried out, otherwise, the step S512 is carried out;

step S503, judging whether the IP address (including the source IP address and the destination IP address) and the port number (including the UDP source port and the UDP destination port) of the message can be found in the ROHC compression and decompression example, if the IP address and the port number can be found, determining that the established compression session is established, and turning to step S510, otherwise, turning to step S504;

step S504, judge whether UDP data frame is greater than 12 bytes, if judge result for greater than 12 bytes, turn to step S505, otherwise, turn to step S512;

step S505, judging whether the first two digits of the UDP load are 0x10(RTP/RTCP is 2), if so, turning to step S506, otherwise, turning to deployment S512;

step S506, judging whether the PAYLOAD load is in an RTP or RTCP coding format, if so, turning to the step S506, otherwise, turning to the step S512;

step S507, judging whether a synchronous information source identifier SSRC in one session is unchanged, if so, turning to step S508, otherwise, turning to step S512;

step S508, loop judgment is carried out for 3 times, whether the SSRCs are consistent or not is judged, if yes, the step S509 is carried out, and if not, the step S512 is carried out;

step S509, if the conditions are met for 3 times continuously, the RTP message or the RTCP message is judged, and if the RTP message is the RTP message, the step S511 is skipped;

step S510, compressing the message;

step S511, recording the SSRC identifier in the RTP header of the UDP port number in the IP address, creating an ROHC compression/decompression instance, constructing a message, encapsulating the recorded information according to the format shown in fig. 6 (when CRTP compression is used, the format is similar to that shown in fig. 6, except that the identifier needs to use the CRTP identifier), and then sending the encapsulated information to the GW2, where fig. 6 is a schematic diagram of an ROHC custom negotiation message encapsulation format according to the embodiment of the present invention, the GW2 creates a compression/decompression instance according to the received information, and replies to the GW1 according to the format of fig. 6, and step S513 is performed;

step S512, determining that the message is not RTP or RTCP message, and continuously detecting the received message;

step S513, after receiving the RTP packet, the GW1 starts ROHC compression, and the packet filtering module searches whether there is a corresponding entry in the ROHC compression instance table after receiving the RTP packet, and if there is an entry, starts to compress the RTP packet, creates a compression/decompression session based on the ROHC instance, compresses the RTP packet, including an IP header + a UDP header + an RTP header, and the GW2 processes gateway operations similar to the GW 1.

The steps S507 to S509 are optional, and when the determination is performed on a single message, the determination may not be performed for 3 times in a loop.

The connection closure is explained below:

GW1 or GW2 receives the RTCP message, if the RTCP message is a hangup message, that is, the corresponding field of the RTCP message is set to BYE, then it is considered to delete the ROHC compression/decompression session corresponding to RTP, and searches the ROHC compression/decompression table according to the IP address, UDP port number, and SSRC identifier in the RTCP header, if it can be found, delete the corresponding RTP compression/decompression session, and simultaneously notify the other party to delete the corresponding compression/decompression session according to the format of fig. 6.

The following explains the exception protection:

after GW1 or GW2 fails in ROHC decompression in a continuous period of time, delete the compression and decompression table of the home terminal, simultaneously notify the opposite terminal to delete, and reinitiate negotiation to establish the compression and decompression table.

Example 2 was carried out:

fig. 7 is a UE direct access satellite communication scenario according to an embodiment of the present invention. The present invention will be described below by taking the UE as a mobile phone.

In this embodiment, the voice message is compressed by using an ROHC compression method (similarly, a CRTP compression method may also be used, in this embodiment, the ROHC compression method is taken as an example for description), and the mobile phone and the GW2 reside in a compression and packet filtering module.

The connection establishment procedure is explained as follows:

step S1, after the mobile phone is accessed through satellite and voice call is initiated through network, the packet filtering module monitors that the message sent by the mobile phone is RTP voice message;

step S2, the compression module records the SSRC identification in the IP address UDP port number RTP header, creates an ROHC compression and decompression example, constructs a message, encapsulates the recorded information according to the format of figure 5 and then sends the encapsulated information to GW2, the GW2 creates a compression and decompression example according to the sent information after receiving the encapsulated information, and replies to the mobile phone according to the format of figure 6;

step S3, after the mobile phone receives the message of successful creation of compression and decompression from GW2, ROHC compression is started, and S4 is switched to;

step S4, when monitoring the RTP voice message sent, GW2 or the mobile phone packet filtering module searches whether there is a corresponding entry in the ROHC compression instance table, if there is a corresponding entry, starts to compress the RTP voice message, creates a compression/decompression session based on the ROHC instance, and compresses the RTP packet header, including the IP header + UDP header + RTP header.

The connection closure is explained below:

the mobile phone or GW2 receives the RTCP message, if the RTCP message 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/decompression session corresponding to RTP, and searches the ROHC compression/decompression table according to the IP address, UDP port number, and SSRC identifier in the RTCP header, if it can be found, delete the corresponding RTP compression/decompression session, and simultaneously notify the other party to delete the corresponding compression/decompression session according to the format of fig. 6.

The following explains the exception protection:

after the ROHC decompression fails in a continuous period of time, the mobile phone or GW2 deletes the local compression/decompression table, and simultaneously notifies the opposite terminal to delete the ROHC, and initiates negotiation again to establish the compression/decompression table.

Example 3 of implementation:

this embodiment is described by taking the satellite communication scenario shown in fig. 4 as an example:

in this embodiment, a CUDP compression method is used to compress the voice message, and GW1 and GW2 reside compression and packet filtering modules.

The following describes the connection establishment procedure:

step S1, after receiving the message, GW1 determines whether the message is an RTP message according to the flow shown in fig. 5, the packet filtering module analyzes all the received messages, first determines whether the message is a UDP message, if the message is a UDP message, determines whether the IP address and the port number can be found in the CUDP compression/decompression instance, if the message can be found, it is considered as an established compression session, if the message cannot be found, it continues to determine whether the UDP data frame is larger than 12 bytes, if the UDP load is first two bits are 0x10(RTP/RTCP is 2), if the UDP load is determined as an RTP or RTCP encoding format, it is determined that the PAYLOAD is an RTP or RTCP encoding format, 3 times of cyclic determination are performed, it is determined whether the SSRC is consistent, if the conditions for 3 times are satisfied, it is determined that the PAYLOAD is an RTP or RTCP message, and if the RTP message is an RTP message;

s2, recording the UDP port number of the IP address, creating a CUDP compression/decompression channel table, constructing a packet, encapsulating the recorded information according to the format of fig. 8, and sending the encapsulated information to the GW2, and after receiving the information, the GW2 creates a compression/decompression instance according to the sent information, and replies to the GW1 according to the format of fig. 8, where fig. 8 is a schematic diagram of an encapsulated format of a CUDP custom negotiation packet according to the embodiment of the present invention;

s3, GW1 starts CUDP compression after receiving, packet filter module searches whether there is corresponding table item in CUDP compression channel table after receiving RTP message, if there is, starts to compress RTP message, compresses RTP message, GW2 processes similar GW1 gateway operation.

The connection closure is explained below:

GW1 or GW2 receives the RTCP message, if the RTCP message is a hangup message, that is, the corresponding field of the RTCP message is set to BYE, then it is considered to delete the CUDP compression/decompression session corresponding to RTP, search the CUDP compression/decompression table according to the IP address and UDP port number in the RTCP header, if it can be found, delete the corresponding RTP compression/decompression session, and simultaneously notify the other party to delete the corresponding compression/decompression session according to the format of fig. 8.

The following explains the exception protection:

after CUDP decompression fails in GW1 or GW2 for a period of time, delete the compression and decompression table of the home terminal, notify the opposite terminal to delete at the same time, and initiate negotiation again to establish the compression and decompression table.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present invention.

In this embodiment, a message processing apparatus is further provided, and the apparatus is used to implement the foregoing embodiments and preferred embodiments, and details of which have been already described are omitted. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Fig. 9 is a block diagram of a first message processing apparatus according to an embodiment of the present invention, and as shown in fig. 9, the apparatus includes a compression module 92 and a first sending module 94, which will be described below.

A compressing module 92, configured to compress a real-time transport protocol RTP packet to be sent to a receiving end according to a compression method negotiated with the receiving end; a first sending module 94, connected to the compressing module 92, for sending the compressed RTP packet to the receiving end through the satellite after the compression is successful.

Fig. 10 is a first block diagram of a preferred structure of a first message processing apparatus according to an embodiment of the present invention, and as shown in fig. 10, the apparatus includes a first negotiation module 102 in addition to all modules shown in fig. 9, which will be described below.

A first negotiation module 102, connected to the compression module 92, configured to negotiate the compression method with a receiving end by: establishing a compression table according to related information of an RTP message to be sent to a receiving end, wherein the compression table carries an identifier of a currently selected compression mode and related information of the RTP message, and when the currently selected compression mode is reliable header compression ROCH or configuration compression real-time protocol CRTP, the related information comprises a source Internet Protocol (IP) address, a destination IP address, a User Data Protocol (UDP) source port, a UDP destination port and an RTP header of the RTP message; or, when the compression mode is to configure a compressed user data protocol CUDP, the related information includes a source IP address, a destination IP address, a UDP source port, and a UDP destination port of the RTP packet; and sending the established compression table to a receiving end, wherein the compression table is used for indicating the receiving end to establish a decompression table corresponding to the compression table.

Fig. 11 is a block diagram of a first negotiation module 102 in a first message processing apparatus according to an embodiment of the present invention, and as shown in fig. 11, when acquiring relevant information of an RTP message, the first negotiation module 102 includes a determining unit 112 and an extracting unit 114, and the first negotiation module 102 is described below.

A determining unit 112, configured to determine whether a received packet to be sent to a receiving end is an RTP packet; and an extracting unit 114, connected to the determining unit 112, for extracting relevant information of the message as relevant information of the RTP message when the message is determined to be an RTP message as a result of the determination.

In an optional embodiment, the determining unit 112 may determine whether the received packet to be sent to the receiving end is an RTP packet by: judging whether a message to be sent to a receiving end is a UDP message or not; after the message is determined to be a UDP message, judging whether the byte number of the UDP data frame of the message is larger than a preset number, and if so, judging whether a preset bit in the UDP load of the message is a preset value; when the predetermined bit in the UDP load of the message is determined to be a predetermined value, judging whether the coding format of the PAYLOAD PAYLOAD of the message is the coding format of RTP; and when determining that the PAYLOAD of the message is the RTP coding format, determining that the message is the RTP message.

Fig. 12 is a block diagram of a preferred structure of a first message processing apparatus according to an embodiment of the present invention, and as shown in fig. 12, the apparatus includes, in addition to all modules shown in fig. 10, a first receiving module 122, a second sending module 124, and a first deleting module 126, which will be described below. Fig. 12 is only an example, and the first receiving module 122 may be further connected to the compressing module 92.

A first receiving module 122, connected to the first sending module 94, configured to receive a first real-time transport control protocol RTCP packet carrying a hang-up instruction after sending the established compression table to a receiving end; a second sending module 124, connected to the first receiving module 122, configured to send a first notification message to a receiving end, where the first notification message is used to notify the receiving end to delete the decompression table; a first deleting module 126, connected to the second sending module 124, configured to delete the compression table after receiving a successful deletion response from a receiving end.

Fig. 13 is a block diagram of a preferred structure of a first message processing apparatus according to an embodiment of the present invention, and as shown in fig. 13, the apparatus includes, in addition to all modules shown in fig. 10, a second deleting module 132 and a third sending module 134, which will be described below. Fig. 13 is only an example, and the second deletion module 132 may also be connected to the compression module 92 described above.

A second deleting module 132, connected to the first sending module 94, configured to delete the compression table after compressing the RTP packet to be sent to the receiving end according to a compression manner negotiated with the receiving end in advance, and after the number of times of failure in compressing the RTP packet exceeds a first threshold and/or the time of failure in continuously compressing the RTP packet exceeds a second threshold; a third sending module 134, connected to the second deleting module 132, configured to send a second notification message to the receiving end, where the second notification message is used to notify the receiving end to delete the decompression table.

Fig. 14 is a block diagram of a preferred structure of a first message processing apparatus according to an embodiment of the present invention, and as shown in fig. 14, the apparatus includes, in addition to all modules shown in fig. 10, a second receiving module 142 and a third deleting module 144, which will be described below. Fig. 14 is only an example, and the second receiving module 142 may be further connected to the compressing module 92.

A second receiving module 142, connected to the first sending module 94, for receiving a third notification message for notifying deletion of the compression table from a receiving end after transmitting the compressed RTP packet to the receiving end through a satellite; a third deleting module 144, connected to the second receiving module 142, for deleting the compression table according to the third notification message.

In an optional embodiment, the third notification message includes at least one of: the receiving end sends the notification message under the condition that the failure times of the RTP message after decompression and compression exceed a first threshold value and/or the failure time of the RTP message after continuous decompression and compression exceeds a second threshold value; and the receiving end receives the notification message sent after receiving the second real-time transport control protocol RTCP message carrying the hang-up instruction.

In an optional embodiment, the message processing apparatus is located in a first gateway or a terminal, and the receiving end includes a second gateway; or, the message processing apparatus is located in a second gateway, and the receiving end includes a first gateway or a terminal.

Fig. 15 is a block diagram of a second message processing apparatus according to an embodiment of the present invention, and as shown in fig. 15, the apparatus includes a third receiving module 152 and a decompression module 154, which will be described below.

A third receiving module 152, configured to receive a compressed real-time transport protocol RTP packet sent by a sending end through a satellite; a decompression module 154, connected to the third receiving module 152, for decompressing the compressed RTP packet according to the decompression manner negotiated with the sending end.

Fig. 16 is a first block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention, and as shown in fig. 16, the apparatus includes a second negotiation module 162 in addition to all modules shown in fig. 15, which will be described below.

A second negotiation module 162, connected to the decompression module 154, configured to negotiate a decompression mode with the sending end by: receiving a compression table from a sending end; and establishing a decompression table for decompressing the compressed RTP message according to the compression table.

Fig. 17 is a block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention, and as shown in fig. 17, the apparatus includes, in addition to all modules shown in fig. 16, a fourth receiving module 172 and a fourth deleting module 174, which will be described below. Fig. 17 is only an example, and the fourth receiving module 172 may also be connected to the second negotiating module 162 described above.

A fourth receiving module 172, connected to the decompressing module 154, for receiving a fourth notification message from the sending end after the decompressing table for decompressing the compressed RTP packet is established according to the compression table; a fourth deleting module 174, connected to the fourth receiving module 172, is configured to delete the decompression table according to the fourth notification message.

In an optional embodiment, the fourth notification message includes at least one of: the method comprises the steps that a sending end sends a notification message under the condition that the failure times of compressing an RTP message to be sent exceed a first threshold value and/or the failure time of continuously compressing the RTP message to be sent exceeds a second threshold value; and the sending end sends the notification message after receiving the first real-time transport control protocol RTCP message carrying the hang-up instruction.

Fig. 18 is a block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention, and as shown in fig. 18, when the fourth notification message includes a notification message that is sent by a sending end after receiving the first RTCP message carrying a hang-up instruction, the apparatus further includes a fourth sending module 182, which will be described below.

A fourth sending module 182, connected to the fourth deleting module 174, configured to send a successful deleting response to the sender after deleting the decompression table according to the fourth notification message, where the successful deleting response is used to instruct the sender to delete the compression table.

Fig. 19 is a block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention, and as shown in fig. 19, the apparatus includes, in addition to the modules shown in fig. 16, a fifth receiving module 192, a fifth sending module 194, and a fifth deleting module 196, which will be described below. Fig. 19 is only an example, and the fifth receiving module 192 may also be connected to the second negotiation module 162 described above.

A fifth receiving module 192, connected to the decompressing module 154, for receiving a second real-time transport control protocol RTCP packet carrying a hang-up instruction after receiving the compression table from the sending end; a fifth sending module 194, connected to the fifth receiving module 192, configured to send a fifth notification message to the sending end, where the fifth notification message is used to notify the sending end to delete the compression table; a fifth deleting module 196, connected to the fifth sending module 194, configured to delete the decompression table after receiving a successful delete response from the sending end.

Fig. 20 is a block diagram of a preferred structure of a second message processing apparatus according to an embodiment of the present invention, and as shown in fig. 20, the apparatus includes a processing module 202 in addition to the modules shown in fig. 16, and the apparatus is described below. Fig. 20 is only an example, and the processing module 202 may also be connected to the second negotiation module 162 described above.

A processing module 202, connected to the compressing module 154, configured to delete the decompression table and send a sixth notification message to the sending end after the compressed RTP packet is decompressed according to the decompression manner negotiated with the sending end, and the number of times of failure in decompressing the compressed RTP packet exceeds a first threshold and/or the time of failure in continuously decompressing the compressed RTP packet exceeds a second threshold, where the sixth notification message is used to notify the sending end to delete the compression table.

In an optional embodiment, the message processing apparatus is located in a second gateway, and the sending end includes a first gateway or a terminal; or, the message processing apparatus is located in a first gateway or a terminal, and the sending end includes a second gateway.

It should be noted that, the above modules may be implemented by software or hardware, and for the latter, the following may be implemented, but not limited to: the modules are all positioned in the same processor; alternatively, the modules are respectively located in a plurality of processors.

The embodiment of the invention also provides a storage medium. Alternatively, in the present embodiment, the storage medium may be configured to store program codes for performing the following steps:

s11, compressing the RTP message to be sent to the receiving end according to the compression mode negotiated with the receiving end;

and S12, after the compression is successful, the compressed RTP message is sent to the receiving end through the satellite.

Optionally, the storage medium is further arranged to store program code for performing the steps of:

s21, receiving a compressed real-time transport protocol (RTP) message sent by a sending end through a satellite;

and S22, decompressing the compressed RTP message according to the decompression mode negotiated with the sending end.

Optionally, in this embodiment, the storage medium may include, but is not limited to: various media capable of storing program codes, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Optionally, in this embodiment, the processor executes each step in the above embodiments according to the program code stored in the storage medium.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and this embodiment is not described herein again.

Compared with the prior art, the method and the device in the embodiment of the invention can save more than half of the occupied bandwidth of the voice.

It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A message processing method is characterized by comprising the following steps:

compressing a real-time transport protocol (RTP) message to be sent to a receiving end according to a compression mode negotiated with the receiving end;

and after the compression is successful, sending the compressed RTP message to the receiving end through a satellite.

2. The method of claim 1, wherein the compression mode is negotiated with the receiving end by:

establishing a compression table according to related information of an RTP message to be sent to the receiving end, wherein the compression table carries an identifier of a currently selected compression mode and related information of the RTP message, and when the currently selected compression mode is reliable header compression ROCH or configuration compression real-time protocol CRTP, the related information comprises a source Internet Protocol (IP) address, a destination IP address, a User Data Protocol (UDP) source port, a UDP destination port and an RTP header of the RTP message; or, when the compression mode is configuring a compressed user data protocol CUDP, the related information includes a source IP address, a destination IP address, a UDP source port and a UDP destination port of the RTP packet;

and sending the established compression table to the receiving end, wherein the compression table is used for indicating the receiving end to establish a decompression table corresponding to the compression table.

3. The method according to claim 2, wherein the information related to the RTP packet is obtained by:

judging whether the received message to be sent to the receiving end is an RTP message or not;

and extracting the relevant information of the message as the relevant information of the RTP message under the condition that the message is the RTP message according to the judgment result.

4. The method of claim 3, wherein determining whether the received packet to be sent to the receiving end is an RTP packet comprises:

judging whether the message to be sent to the receiving end is a UDP message or not;

after the message is determined to be a UDP message, judging whether the byte number of a UDP data frame of the message is larger than a preset number, and if so, judging whether a predetermined bit in the UDP load of the message is a preset value;

when the predetermined bit in the UDP load of the message is determined to be a predetermined value, judging whether the coding format of the PAYLOAD PAYLOAD of the message is the coding format of RTP;

and when determining that the PAYLOAD of the message is the RTP coding format, determining that the message is the RTP message.

5. The method of claim 2, wherein after sending the established compression table to the receiving end, the method further comprises:

receiving a first real-time transport 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 for notifying the receiving end to delete the decompression table;

and deleting the compression table after receiving a successful deletion response from the receiving end.

6. The method according to claim 2, wherein after compressing the RTP packet to be sent to the receiving end according to a compression method negotiated with the receiving end in advance, the method further comprises:

deleting the compression table after the failure times of compressing the RTP message exceed a first threshold value and/or the failure time of continuously compressing the RTP message exceed a second threshold value;

and sending a second notification message to the receiving end, wherein the second notification message is used for notifying the receiving end to delete the decompression table.

7. The method of claim 2, wherein after transmitting the compressed RTP packet to the receiving end via a satellite, the method further comprises:

receiving a third notification message for notifying deletion of the compression table from the receiving end;

deleting the compression table according to the third notification message.

8. The method of claim 7, wherein the third notification message comprises at least one of:

the receiving end sends the notification message under the condition that the failure times of the RTP message after decompression and compression exceed a first threshold value and/or the failure time of the RTP message after continuous decompression and compression exceeds a second threshold value;

and the receiving end receives the notification message sent after receiving the second real-time transport control protocol RTCP message carrying the hang-up instruction.

9. A message processing method is characterized by comprising the following steps:

receiving a compressed real-time transport protocol (RTP) message sent by a sending end through a satellite;

and decompressing the compressed RTP message according to a decompression mode negotiated with the sending end.

10. The method of claim 9, wherein the decompression mode is negotiated with the sender by:

receiving a compression table from the sending end;

and establishing a decompression table for decompressing the compressed RTP message according to the compression table.

11. The method of claim 10, wherein after establishing the decompression table for decompressing the compressed RTP packet according to the compression table, the method further comprises:

receiving a fourth notification message from the sending end;

and deleting the decompression table according to the fourth notification message.

12. The method of claim 11, wherein the fourth notification message comprises at least one of:

the sending end sends the notification message under the condition that the failure times of compressing the RTP message to be sent exceed a first threshold value and/or the failure time of continuously compressing the RTP message to be sent exceeds a second threshold value;

and the sending end sends a notification message after receiving a first real-time transport control protocol (RTCP) message carrying a hangup instruction.

13. The method according to claim 12, wherein when the fourth notification message includes a notification message sent by the sender after receiving the first RTCP packet carrying a hang-up instruction, after deleting the decompression table according to the fourth notification message, the method further comprises:

and sending a successful deletion response to the sending end, wherein the successful deletion response is used for indicating the sending end to delete the compression table.

14. The method of claim 10, wherein after receiving the compression table from the sender, the method further comprises:

receiving a second real-time transport control protocol (RTCP) message carrying a hang-up instruction;

sending a fifth notification message to the sending end, wherein the fifth notification message is used for notifying the sending end to delete the compression table;

and deleting the decompression table after receiving a successful deletion response from the sending end.

15. The method according to claim 10, wherein after decompressing the compressed RTP packet according to the decompression method negotiated with the transmitting end, the method further comprises:

and deleting the decompression table and sending a sixth notification message to the sending end when the failure times of decompressing and compressing the compressed RTP message exceed a first threshold value and/or the failure time of continuously decompressing and compressing the compressed RTP message exceed a second threshold value, wherein the sixth notification message is used for notifying the sending end to delete the compression table.

16. A message processing apparatus, comprising:

the compression module is used for compressing the real-time transport protocol RTP message to be sent to the receiving end according to a compression mode negotiated with the receiving end;

and the first sending module is used for sending the compressed RTP message to the receiving end through a satellite after the compression is successful.

17. The apparatus of claim 16, further comprising a first negotiation module configured to negotiate the compression mode with the receiving end by:

18. The apparatus of claim 17, wherein when acquiring the information related to the RTP packet, the first negotiation module comprises:

a judging unit, configured to judge whether a received packet to be sent to the receiving end is an RTP packet;

and the extracting unit is used for extracting the relevant information of the message as the relevant information of the RTP message under the condition that the message is the RTP message according to the judgment result.

19. The apparatus according to claim 18, wherein the determining unit determines whether the received packet to be sent to the receiving end is an RTP packet by:

20. The apparatus of claim 17, further comprising:

the first receiving module is used for receiving a first real-time transport control protocol (RTCP) message carrying a hang-up instruction after the established compression table is sent to the receiving end;

a second sending module, configured to send a first notification message to the receiving end, where the first notification message is used to notify the receiving end to delete the decompression table;

and the first deleting module is used for deleting the compression table after receiving a successful deleting response from the receiving end.

21. The apparatus of claim 17, further comprising:

a second deleting module, configured to delete the compression table after compressing the RTP packet to be sent to the receiving end according to a compression manner negotiated with the receiving end in advance, and after the number of times of RTP packet compression failures exceeds a first threshold and/or the time of RTP packet continuous compression failures exceeds a second threshold;

a third sending module, configured to send a second notification message to the receiving end, where the second notification message is used to notify the receiving end to delete the decompression table.

22. The apparatus of claim 17, further comprising:

a second receiving module, configured to receive a third notification message from the receiving end for notifying deletion of the compression table after the compressed RTP packet is transmitted to the receiving end through a satellite;

and the third deleting module is used for deleting the compression table according to the third notification message.

23. The apparatus of claim 22, wherein the third notification message comprises at least one of:

24. The apparatus of any one of claims 16 to 23,

the message processing device is positioned in a first gateway or a terminal, and the receiving end comprises a second gateway; or,

the message processing device is located in a second gateway, and the receiving end comprises a first gateway or a terminal.

25. A message processing apparatus, comprising:

the third receiving module is used for receiving the compressed real-time transport protocol RTP message sent by the sending end through the satellite;

and the decompression module is used for decompressing the compressed RTP message according to a decompression mode negotiated with the sending end.

26. The apparatus of claim 25, further comprising a second negotiation module configured to negotiate the decompression mode with the sender by:

receiving a compression table from the sending end;

27. The apparatus of claim 26, further comprising:

a fourth receiving module, configured to receive a fourth notification message from the sending end after the decompression table for decompressing the compressed RTP packet is established according to the compression table;

and the fourth deleting module is used for deleting the decompression table according to the fourth notification message.

28. The apparatus of claim 27, wherein the fourth notification message comprises at least one of:

29. The apparatus of claim 28, wherein when the fourth notification message includes a notification message sent by the sender after receiving the first RTCP packet carrying a hang-up instruction, the apparatus further comprises:

and a fourth sending module, configured to send a successful deletion response to the sending end after deleting the decompression table according to the fourth notification message, where the successful deletion response is used to instruct the sending end to delete the compression table.

30. The apparatus of claim 26, further comprising:

a fifth receiving module, configured to receive a second real-time transport control protocol RTCP packet carrying a hang-up instruction after receiving the compression table from the sending end;

a fifth sending module, configured to send a fifth notification message to the sending end, where the fifth notification message is used to notify the sending end to delete the compression table;

and the fifth deleting module is used for deleting the decompression table after receiving a successful deleting response from the sending end.

31. The apparatus of claim 26, further comprising:

and the processing module is configured to delete the decompression table and send a sixth notification message to the sending end after the compressed RTP packet is decompressed according to the decompression manner negotiated with the sending end and the number of times of failure in decompressing the compressed RTP packet exceeds a first threshold and/or the time of failure in continuously decompressing the compressed RTP packet exceeds a second threshold, where the sixth notification message is used to notify the sending end to delete the compression table.

32. The apparatus of any one of claims 25 to 31,

the message processing device is positioned in a second gateway, and the sending end comprises a first gateway or a terminal; or,

the message processing device is located in a first gateway or a terminal, and the sending end comprises a second gateway.