[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2017092389A1 - 报文处理方法及装置 - Google Patents

报文处理方法及装置 Download PDF

Info

Publication number
WO2017092389A1
WO2017092389A1 PCT/CN2016/092367 CN2016092367W WO2017092389A1 WO 2017092389 A1 WO2017092389 A1 WO 2017092389A1 CN 2016092367 W CN2016092367 W CN 2016092367W WO 2017092389 A1 WO2017092389 A1 WO 2017092389A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
rtp
packet
compression
receiving
Prior art date
Application number
PCT/CN2016/092367
Other languages
English (en)
French (fr)
Inventor
常伟
晏文彬
唐雄
陈诚
刘亮
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2017092389A1 publication Critical patent/WO2017092389A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Definitions

  • the embodiments of the present invention relate to, but are not limited to, the field of communications, and in particular, to a packet processing method and apparatus.
  • Satellite communication is widely used in the above-mentioned offshore areas and most areas on land. Especially used in the fields of ocean transportation, drilling, surveying and fisheries. Satellite communication has many advantages such as short time, location, environment and other factors, such as short opening time, long transmission distance, fast network deployment, and communication cost and communication distance. It can realize real-time bidirectional transmission of voice and data.
  • the satellite phone is one of the existing satellite communication, because the satellite channel has some characteristics different from the terrestrial channel, and the Transmission Control Protocol (TCP)/Internet Protocol (IP)
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • the protocol was originally designed for terrestrial networks, so the TCP/IP protocol has poor transmission performance on satellite channels.
  • the delay is large, the delay of the satellite channel is very long, and the typical satellite communication delay is about 540ms, which causes the TCP protocol to retransmit continuously, causing congestion of the communication link.
  • the actual satellite communication has a very high bit error, and the TCP protocol cannot distinguish between data loss caused by network congestion or data loss caused by bit error.
  • the TCP protocol is always considered to be caused by network congestion, thereby reducing
  • the transmission window of TCP causes the bandwidth of the transmission to decrease;
  • the satellite communication bandwidth is low and the lease cost is high.
  • VOIP voice over Internet Protocol
  • different data bandwidths are required. For example, the bandwidth required by G729 is 8Kbps, and one report is used.
  • the header (Real-time Transport Protocol (RTP) + User Data Protocol (UDP) + IP header) accounts for 16 Kbps, so the VOIP phone needs to occupy 24 Kbps of bandwidth. This is a huge waste of resources for satellite communications.
  • the embodiment of the invention provides a message processing method and device, so as to at least solve the problem that the bandwidth utilization of the voice communication in the related art is insufficient in the field of satellite communication.
  • a packet processing method including: compressing a real-time transport protocol RTP packet to be sent to the receiving end according to a compression manner negotiated with a receiving end; The satellite sends the compressed RTP message to the receiving end.
  • the compression mode is negotiated with the receiving end by: establishing a compression table according to the related information of the RTP message to be sent to the receiving end, where the compression table carries the currently selected compression mode. Identifying information related to the RTP packet, when the currently selected compression mode is a reliable header compression ROCH or a compression real-time protocol CRTP, the related information includes a source Internet Protocol IP address and a destination of the RTP packet. The IP address, the user data protocol UDP source port, the UDP destination port, and the RTP header; or, when the compression mode is configured to compress the user data protocol CUDP, the related information includes the source IP address and the destination IP address of the RTP packet. The address, the UDP source port, and the UDP destination port are sent to the receiving end, where the compression table is used to instruct the receiving end to establish a decompression table corresponding to the compression table.
  • the related information of the RTP packet is obtained by: determining whether the received packet to be sent to the receiving end is an RTP packet; and determining that the packet is an RTP packet And extracting related information of the packet as related information of the RTP packet.
  • determining whether the received packet to be sent to the receiving end is an RTP packet includes: determining whether the packet to be sent to the receiving end is a UDP packet; and determining the packet After the UDP packet is sent, determine whether the number of bytes of the UDP data frame of the packet is greater than a predetermined number.
  • the predetermined bit in the UDP payload of the packet is a predetermined value; When it is determined that the predetermined bit in the UDP payload of the packet is a predetermined value, determining that the packet has Whether the encoding format of the payload PAYLOAD is the encoding format of the RTP; when it is determined that the PAYLOAD of the packet is the encoding format of the RTP, it is determined that the packet is an RTP packet.
  • the method further includes: receiving a first real-time transmission control protocol RTCP packet carrying a hangup command; and sending the first to the receiving end a notification message, wherein the first notification message is used to notify the receiving end to delete the decompression table; and after receiving a successful deletion response from the receiving end, deleting the compression table.
  • the method further includes: the number of times the compressed RTP packet fails exceeds the first threshold and/or When the time when the continuous compression of the RTP packet fails exceeds the second threshold, the compression table is deleted; and the second notification message is sent to the receiving end, where the second notification message is used to notify the receiving end to delete the Uncompress the table.
  • the method further includes: receiving, by the receiving end, a third notification message for notifying deletion of the compression table; The third notification message deletes the compression table.
  • the third notification message includes at least one of the following: the number of times the receiving end fails to decompress the compressed RTP message exceeds a first threshold, and/or the continuous decompressed compressed RTP message fails.
  • a packet processing method including: receiving a compressed real-time transport protocol RTP message sent by a sender through a satellite; and decompressing according to a decompression method negotiated with the sender Compressing the compressed RTP message.
  • the decompressing manner is negotiated with the sending end by: receiving a compression table from the sending end; and establishing, according to the compression table, a decompression table for decompressing the compressed RTP message. .
  • the method further includes: receiving a fourth notification message from the sending end; The fourth notification message deletes the decompression table.
  • the fourth notification message includes at least one of the following: the sending end is in compression The notification message sent when the number of failed RTP packets sent exceeds the first threshold and/or the time when the failure to continuously send the RTP packets to be sent exceeds the second threshold; the sender receives the hang up The first real-time transmission of the instruction controls the notification message sent after the protocol RTCP message.
  • the 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 compressed table.
  • the method further includes: receiving a second real-time transmission control protocol RTCP message carrying the hang-up instruction; and sending a fifth notification message to the sending end, The fifth notification message is used to notify the sending end to delete the compression table; after receiving the successful deletion response from the sending end, the decompression table is deleted.
  • the method further includes: when the decompressed compressed RTP packet fails, the number of times exceeds After the threshold and/or the continuous decompression of the compressed RTP packet exceeds the second threshold, the decompression table is deleted, and the sixth notification message is sent to the sending end, where the sixth notification message is sent. And configured to notify the sending end to delete the compressed table.
  • a message processing apparatus including: a compression module, configured to compress a real-time transport protocol RTP message to be sent to the receiving end according to a compression manner negotiated with a receiving end;
  • the first sending module is configured to send the compressed RTP message to the receiving end by using a satellite after the compression succeeds.
  • the device further includes a first negotiation module, configured to negotiate the compression mode with the receiving end by: establishing a compression table according to related information of the RTP message to be sent to the receiving end, where The compression table carries the identifier of the currently selected compression mode and the related information of the RTP packet.
  • a first negotiation module configured to negotiate the compression mode with the receiving end by: establishing a compression table according to related information of the RTP message to be sent to the receiving end, where The compression table carries the identifier of the currently selected compression mode and the related information of the RTP packet.
  • the related information includes the The source Internet Protocol IP address, the destination IP address, the UDP source port, the UDP destination port, and the RTP header of the RTP message; or, when the compression mode is configured to compress the user data protocol CUDP, the related information includes Source IP address, destination IP address, UDP source port, and UDP destination port of the RTP packet;
  • the compression table is sent 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.
  • the first negotiation module when acquiring the related information of the RTP packet, includes: a determining unit, configured to determine whether the received packet to be sent to the receiving end is an RTP packet; And in the case that the result of the judgment is that the packet is an RTP packet, the related information of the packet is extracted as related information of the RTP packet.
  • the determining unit determines whether the received packet to be sent to the receiving end is an RTP packet, and determines whether the packet to be sent to the receiving end is a UDP packet; After the packet is a UDP packet, it is determined whether the number of bytes of the UDP data frame of the packet is greater than a predetermined number.
  • the packet is greater than the predetermined number, determining whether the predetermined bit in the UDP payload of the packet is a predetermined value; when determining that the predetermined bit in the UDP payload of the message is a predetermined value, determining whether the encoding format of the payload PAYLOAD of the message is an encoding format of the RTP; determining that the PAYLOAD of the packet is RTP
  • the encoding format determines that the message is an RTP message.
  • the device further includes: a first receiving module, configured to: after sending the compressed table to be sent to the receiving end, receive a first real-time transmission control protocol RTCP packet carrying a hang up command; a 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 configured to receive the After the receiving end successfully deletes the response, the compressed table is deleted.
  • a first receiving module configured to: after sending the compressed table to be sent to the receiving end, receive a first real-time transmission control protocol RTCP packet carrying a hang up command
  • a 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
  • the first deleting module is configured to receive the After the receiving end successfully deletes the response, the compressed table is deleted.
  • the device further includes: a second deleting module, configured to: after compressing the RTP packet to be sent to the receiving end according to a compression manner negotiated in advance with the receiving end, and compressing the RTP packet fails After the number of times exceeds the first threshold and/or the time when the continuous compressed RTP packet fails exceeds the second threshold, the compression table is deleted; the third sending module is 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.
  • a second deleting module configured to: after compressing the RTP packet to be sent to the receiving end according to a compression manner negotiated in advance with the receiving end, and compressing the RTP packet fails After the number of times exceeds the first threshold and/or the time when the continuous compressed RTP packet fails exceeds the second threshold, the compression table is deleted; the third sending module is 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.
  • the device further includes: a second receiving module, configured to: after transmitting the compressed RTP message to the receiving end by using a satellite, receive, from the receiving end, a notification for deleting the compressed table a third notification message, configured to delete the compression table according to the third notification message.
  • a second receiving module configured to: after transmitting the compressed RTP message to the receiving end by using a satellite, receive, from the receiving end, a notification for deleting the compressed table a third notification message, configured to delete the compression table according to the third notification message.
  • the third notification message includes at least one of the following: the number of times the receiving end fails to decompress the compressed RTP message exceeds a first threshold, and/or the continuous decompressed compressed RTP message fails.
  • the packet processing device is located in the first gateway or the terminal, and the receiving end includes a second gateway; or the packet processing device is located in the second gateway, where the receiving end includes the first gateway or terminal.
  • a message processing apparatus including: a third receiving module, configured to receive a compressed real-time transport protocol RTP message sent by a transmitting end through a satellite; and a decompression module And decompressing the compressed RTP packet according to a decompression manner negotiated with the sending end.
  • the device further includes a second negotiation module, configured to negotiate the decompression mode with the sending end by: receiving a compression table from the sending end; establishing, according to the compression table, for decompressing a decompressed table of the compressed RTP message.
  • a second negotiation module configured to negotiate the decompression mode with the sending end by: receiving a compression table from the sending end; establishing, according to the compression table, for decompressing a decompressed table of the compressed RTP message.
  • the device further includes: a fourth receiving module, configured to receive, after decompressing the decompressed table of the compressed RTP message according to the compression table, from the sending end a fourth notification message, configured to delete the decompression table according to the fourth notification message.
  • a fourth receiving module configured to receive, after decompressing the decompressed table of the compressed RTP message according to the compression table, from the sending end a fourth notification message, configured to delete the decompression table according to the fourth notification message.
  • the fourth notification message includes at least one of the following: the number of failures of the RTP message to be sent by the sending end exceeds a first threshold, and/or the continuous compression of the RTP message to be sent fails.
  • the device when the fourth notification message includes the notification message sent by the sending end after receiving the first RTCP message carrying the hang up command, the device further includes: a fourth sending module, After the decompression table is deleted according to the fourth notification message, a successful deletion response is sent to the sending end, where the successful deletion response is used to instruct the sending end to delete the compression table.
  • the device further includes: a fifth receiving module, configured to receive from the sending end After the compression table, the second real-time transmission control protocol (RTCP) message carrying the hang-up command is received; the fifth sending module is configured to send a fifth notification message to the sending end, where the fifth notification message is used by And the fifth deletion module is configured to delete the decompression table after receiving the successful deletion response from the sending end.
  • a fifth receiving module configured to receive from the sending end After the compression table, the second real-time transmission control protocol (RTCP) message carrying the hang-up command is received
  • the fifth sending module is configured to send a fifth notification message to the sending end, where the fifth notification message is used by
  • the fifth deletion module is configured to delete the decompression table after receiving the successful deletion response from the sending end.
  • RTCP real-time transmission control protocol
  • the device further includes: a processing module, configured to: after decompressing the compressed RTP packet according to the decompressing manner negotiated with the sending end, and decompressing the compressed RTP packet After the number of failures exceeds the first threshold and/or the time after the continuous decompression and compression of the RTP packet fails exceeds the second threshold, the decompression table is deleted, and a sixth notification message is sent to the sender, where The sixth notification message is used to notify the sending end to delete the compressed table.
  • a processing module configured to: after decompressing the compressed RTP packet according to the decompressing manner negotiated with the sending end, and decompressing the compressed RTP packet After the number of failures exceeds the first threshold and/or the time after the continuous decompression and compression of the RTP packet fails exceeds the second threshold, the decompression table is deleted, and a sixth notification message is sent to the sender, where The sixth notification message is used to notify the sending end to delete the compressed table.
  • the message processing device is located in the second gateway, and the sending end includes a first gateway or a terminal; or the message processing device is located in the first gateway or the terminal, and the sending end includes the second Gateway.
  • the RTP message to be sent to the receiving end is compressed according to the compression method negotiated with the receiving end. After the compression is successful, the compressed RTP message is sent to the receiving end by the satellite. It can be seen that the present application solves the problem that the bandwidth utilization of the voice communication in the related art is insufficient in the field of satellite communication, thereby achieving the effect of improving the bandwidth utilization of the voice communication in the field of satellite communication and saving bandwidth resources.
  • FIG. 1 is a flowchart 1 of a message processing method according to an embodiment of the present invention.
  • FIG. 2 is a second flowchart of a message processing method according to an embodiment of the present invention.
  • FIG. 3 is an interaction flowchart of a voice call and an 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 present invention.
  • FIG. 5 is a flowchart of determining an RTP message according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a package format of a ROHC custom negotiation packet according to an embodiment of the present invention.
  • FIG. 7 is a scenario in which a UE directly accesses a satellite communication scenario according to an embodiment of the present invention
  • FIG. 8 is a schematic diagram of a CUDP custom negotiation packet encapsulation format according to an embodiment of the present invention.
  • FIG. 9 is a structural block diagram of a first message processing apparatus according to an embodiment of the present invention.
  • FIG. 10 is a block diagram 1 of an optional structure of a first message processing apparatus according to an embodiment of the present invention.
  • FIG. 11 is a structural 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 2 of an optional structure of a first message processing apparatus according to an embodiment of the present invention.
  • FIG. 13 is a block diagram 3 of an optional structure of a first message processing apparatus according to an embodiment of the present invention.
  • FIG. 14 is a block diagram 4 of an optional structure of a first message processing apparatus according to an embodiment of the present invention.
  • FIG. 15 is a structural block diagram of a second message processing apparatus according to an embodiment of the present invention.
  • 16 is a block diagram 1 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • 17 is a block diagram 2 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • FIG. 18 is a block diagram 3 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • FIG. 19 is a block diagram 4 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • FIG. 20 is a block diagram 5 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • FIG. 1 is a flowchart 1 of a packet processing method according to an embodiment of the present invention. As shown in FIG. 1, the process includes the following steps:
  • Step S102 Perform real-time transmission to the receiving end according to a compression manner negotiated with the receiving end.
  • the protocol RTP packet is compressed;
  • Step S104 After the compression is successful, the compressed RTP message is sent to the receiving end by using a satellite.
  • the RTP packet when the RTP packet is sent to the receiving end, the RTP packet is first compressed.
  • the RTP packet occupies a large bandwidth.
  • the RTP packet is compressed, only the RTP packet can be compressed.
  • the IP header, the UDP header, and the RTP header of the RTP packet are compressed, and then the compressed RTP packet is sent to the receiving end, where the size of the compressed RTP packet is relative to the original uncompressed RTP packet.
  • the problem of insufficient bandwidth utilization in the field of satellite communication has improved the bandwidth utilization of voice communication in the field of satellite communication and saved bandwidth resources.
  • the compression mode may be negotiated with the receiving end by: establishing a compression table according to the related information of the RTP message to be sent to the receiving end, where the compression table carries the identifier of the currently selected compression mode.
  • the above related information is related to the RTP packet, when the currently selected compression mode is Robust Header Compression (ROCH) or Configuring Compressed Real-Time Protocol (CRTP).
  • the information includes the source Internet Protocol IP address, the destination IP address, the user data protocol UDP source port, the UDP destination port, and the RTP header of the RTP message; or, when the compression mode is the Configuring Compressed User Date Protocol (referred to as the Compressed User Date Protocol)
  • the related information includes the source IP address, the destination IP address, the UDP source port, and the UDP destination port of the RTP packet.
  • the compressed table is sent to the receiving end, where the compression table is used to indicate the receiving end. Create a decompressed table corresponding to the compressed table. The receiving end may return a response message for establishing OK after successfully establishing the understanding compression table.
  • the foregoing compression methods are only examples, and other compression methods may be used. Similarly, when other compression methods are used, it is necessary to establish a compression table corresponding to the other compression modes, and different compressions. The content in the compressed table corresponding to the mode may be different. After the above negotiation mode is completed, the two ends can perform the compression and decompression operations of the RTP packet in a negotiated manner.
  • the information about the RTP packet is obtained by: determining whether the received packet to be sent to the receiving end is an RTP packet; and determining that the packet is an RTP packet In the case of the RTP message, the related information of the above packet is extracted.
  • the packet to be sent to the receiving end may be the first RTP packet to be sent to the receiving end, and the first RTP packet may be directly sent to the receiving end without being compressed, in order to avoid excessive delay.
  • the method for judging whether the packet is an RTP packet may have a plurality of judging manners.
  • the following is a description of the judging method in the embodiment of the present invention: determining whether the received packet to be sent to the receiving end is an RTP.
  • the packet includes: determining whether the packet to be sent to the receiving end is a UDP packet; and determining whether the packet is a UDP packet, determining whether the number of bytes of the UDP data frame of the packet is greater than a predetermined number (for example, the predetermined number)
  • the number is 12 bytes, that is, whether it is greater than the length of the fixed header of the RTP message.
  • the predetermined bit for example, the first two digits
  • the predetermined bit in the UDP payload 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 payload of the message is a predetermined value, it is determined whether the encoding format of the payload PAYLOAD of the message is the encoding format of the RTP; When the PAYLOAD of the packet is the encoding format of the RTP, it is determined that the packet is an RTP packet.
  • a predetermined value for example, 0x10, that is, whether it is the same as the current RTP version number
  • the determining method in the embodiment of the present invention determines whether the packet is an RTP packet by determining whether the encoding format is an encoding format of the RTP, which can simplify the determining step and improve the determining accuracy.
  • it may also determine whether the received packet is an RTP packet according to the above method, and when it is determined to be, the packet that is determined to be an RTP is determined.
  • the compression is performed according to the method in the above embodiment, and then the compressed RTP message is transmitted.
  • the main body performing the above operations may be the transmitting end.
  • the sending end and the receiving end may also delete or update the compressed table and the decompressed table.
  • the method further includes: receiving a first real-time transmission control protocol RTCP packet carrying the hang-up command; and sending a first notification message to the receiving end, where the first notification message is used for receiving the notification
  • the decompression table is deleted; after receiving the successful deletion response from the above receiving end, the compression table is deleted.
  • the specific field in the RTCP packet may be set to BYE, and the specific field set to the BYE may be the hangup instruction described above.
  • the method further includes: the number of times the compressed RTP packet fails exceeds the first threshold and/or After the failure of the continuous compression of the RTP packet exceeds the second threshold, the compression table is deleted; and the second notification message is sent to the receiving end, where the second notification message is used to notify the receiving end to delete the decompression table.
  • the compression table may be deleted after the failure of compressing the RTP message, or the compression table may be deleted after the number of times the compressed RTP message fails exceeds a predetermined number of times (the predetermined number of times may be greater than 1), or It is also possible to delete the compressed table when the time when the continuous compression of the RTP message fails exceeds a certain value, and then notify the receiving end to delete the decompressed table.
  • the deletion of the compressed table and the decompressed table is triggered by the sending end (ie, the end performing the above operation).
  • the deletion of the compressed table and the decompressed table may also be triggered by the receiving end, in one
  • the method further includes: receiving a third notification message from the receiving end for notifying the deletion of the compression table; according to the third notification message Delete the compressed table.
  • the foregoing third notification message may include at least one of the following: the number of times the receiving end fails to decompress and compress the RTP message exceeds a first threshold and/or continuously decompresses and compresses the RTP report.
  • the notification message sent by the receiving end in the case that the decompressed and compressed RTP packet fails may be a notification message that is sent after the receiving end fails to be decompressed once, or the number of times the receiving end decompression fails more than a predetermined number of times.
  • the notification message sent by the receiving end may be a notification message sent by the receiving end after the time when the continuous decompression fails exceeds a certain value, and the receiving end may delete the decompression table in the receiving end before sending the notification message.
  • the sender and the receiver may re-initiate the process of establishing the compression table and the decompression table.
  • FIG. 2 is a flowchart 2 of a packet processing method according to an embodiment of the present invention. As shown in FIG. 2, the process includes the following steps:
  • Step S202 receiving a compressed real-time transport protocol RTP message sent by the transmitting end through the satellite;
  • Step S204 decompressing the compressed RTP according to the decompression method negotiated with the foregoing sending end. Message.
  • the received RTP packet is a compressed RTP packet, that is, when the sending end sends the RTP packet, the transmitting end first compresses the RTP packet, and then sends the compressed RTP packet, where The size of the compressed RTP packet is much smaller than that of the original uncompressed RTP packet. Therefore, the bandwidth usage can be reduced, thereby enabling more RTP packets to be sent over a certain bandwidth.
  • the purpose is to improve the utilization of bandwidth, solve the problem of insufficient bandwidth utilization of voice communication in the field of satellite communication in related technologies, and thereby improve the bandwidth utilization of voice communication in the field of satellite communication, and save bandwidth. The effect of the resource.
  • the decompression mode may be negotiated 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.
  • the compression table may identify the compression mode (for example, the ROCH compression mode or the CUDP compression mode), and the content of the compression table corresponding to different compression modes may be different. After the above negotiation mode is completed, the two ends can perform the compression and decompression operations of the RTP packet in a negotiated manner.
  • the main body performing the foregoing operations may be a receiving end.
  • the sending end and the receiving end may also perform a delete or update operation on the compressed table and the decompressed table.
  • the method further includes: receiving a fourth notification message from the sending end; deleting the decompressing according to the fourth notification message. table.
  • the fourth notification message may include at least one of the following: the number of times the sender fails to compress the RTP message to be sent exceeds the first threshold, and/or continuously compresses the RTP report to be sent.
  • the notification message sent by the sending end in the case that the compressed RTP packet fails may be a notification message that is sent after the failure of the sending end is compressed once, or may be sent after the number of times the sending end fails to compress exceeds a predetermined number of times.
  • the RTCP packet may carry a hangup instruction, and the carrying manner may be that the predetermined field is set to BYE in RTCP.
  • the method further includes: sending a successful deletion response to the sending end, wherein the successful deleting response is used to instruct the sending end to delete the compressed table.
  • the deletion of the compressed table and the decompressed table is triggered by the transmitting end.
  • the deletion of the compressed table and the decompressed table may also be triggered by the receiving end.
  • the method further includes: receiving a second real-time transmission control protocol RTCP packet carrying the hangup command; and sending a fifth notification message to the sender, where the fifth notification message is used to notify the sender to delete The compressed table; after receiving the successful deletion response from the sender, delete the above decompressed table.
  • the carrying manner of carrying the hangup instruction in the RTCP packet may be that the predetermined field is set to BYE in the RTCP.
  • the method further includes: when the decompressed compressed RTP packet fails, the number of times exceeds the first After the threshold and/or the continuous decompression of the compressed RTP packet exceeds the second threshold, the decompression table is deleted, and the sixth notification message is sent to the sending end, where the sixth notification message is used to notify the sending end.
  • Delete the compressed table the decompression table may be deleted after the failure of decompressing the RTP message, or may be deleted after the number of times the decompressed RTP message fails exceeds a predetermined number of times (the predetermined number of times may be greater than 1).
  • the table, or the decompression table may be deleted when the time when the continuous decompression of the RTP packet fails exceeds a certain value, and then the sender is notified to delete the compression table.
  • the sender and the receiver may re-initiate the process of establishing the compression table and the decompression table.
  • the following takes the above-mentioned transmitting end as the gateway GW1 and the receiving end as the gateway GW2 as an example to describe the overall flow of the embodiment of the present invention:
  • FIG. 3 is a flow chart of interaction between a voice call and an hang up process according to an embodiment of the present invention. As shown in FIG. 3, the process includes the following steps:
  • step S301 when the user equipment (User Equipment, UE for short) (hereinafter referred to as UE) of the calling party needs to initiate a voice call to the called party, the UE goes to the IP multimedia subsystem (IMS). Initiate a voice call;
  • UE User Equipment
  • IMS IP multimedia subsystem
  • Step S302 when the IMS determines that the UE is allowed to make a voice call, returning a response to the successful voice call to the UE;
  • Step S303 the UE sends a voice message (corresponding to the above RTP message) to the gateway GW1 on the UE side;
  • step S304 GW1 determines a compression mode, and establishes a compression table in the compression mode according to the voice message, and the establishment process is as described in the foregoing embodiment, and is not described here; and GW1 establishes the voice message and establishes the voice message.
  • the compressed table is sent to the gateway GW2 of the called side UE, and the GW2 is established in the decompression table corresponding to the compressed table according to the compression table;
  • Step S305 GW1 establishes a compression session with GW2;
  • Step S306 GW2 returns a setup compressed session success message to GW1;
  • Step S307 GW2 sends the voice message sent by GW1 to the IMS;
  • Step S308 the UE sends a voice message to GW1.
  • 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;
  • Step S310 GW2 decompresses the received compressed voice message, and sends the decompressed voice message to the IMS;
  • Step S311 the GW2 receives the voice message sent by the called side UE, and the GW2 negotiates the compression and decompression mode with the GW1 in the same manner as described above;
  • Step S312 GW2 compresses the voice message sent by the called side UE according to the negotiated compression mode, and sends it to GW1;
  • Step S313, GW1 decompresses the received compressed voice message from the called side UE, and sends the voice message to the calling party's UE;
  • Step S314 the calling party UE determines that the voice call needs to be hung up, and sends a notification to the IMS to hang up the voice call;
  • Step S316 GW2 returns a message for deleting the successful compression session to GW1;
  • Step S317 the IMS sends a voice call response message to the calling party UE, and thus, the voice communication The words are over.
  • FIG. 4 is a schematic diagram of a satellite communication transmission scenario according to an embodiment of the present invention.
  • ROHC compression is used in the present embodiment (CRTP compression and ROHC compression are similar, and ROHC is taken as an example for explanation).
  • the method compresses a voice message, and the ROHC is usually used for an air interface of wireless communication, and in this example, a scenario in which a satellite transmits voice compression.
  • FIG. 5 is a flowchart of determining an RTP message according to an embodiment of the present invention. After receiving a message, GW1 may determine whether it is an RTP message according to the process shown in FIG. 5, and the determining process includes the following steps:
  • Step S501 the packet filtering module (which may be a module in the sending end or the receiving end) analyzes all received messages;
  • Step S502 the packet filtering module determines whether it is a UDP packet, if it is a UDP packet, the process goes to step S503, otherwise, the process goes to step S512;
  • Step S503 determining 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 packet can be found in the ROHC compression and decompression instance, and if found, Is considered to be a good compression session, go to step S510, otherwise, go to step S504;
  • Step S504 determining whether the UDP data frame is greater than 12 bytes, if the determination result is greater than 12 bytes, then go to step S505, otherwise, go to step S512;
  • Step S505 determining whether the first two digits of the UDP payload are 0x10 (ie, determining whether the RTP/RTCP version number is 2), if yes, go to step S506, otherwise, go to deployment S512;
  • Step S506 it is determined whether the payload (PAYLOAD) is the encoding format of RTP or RTCP, the determination result is yes, go to step S506, otherwise, go to step S512;
  • Step S507 determining whether the synchronization source identifier SSRC in a session is unchanged, the determination result is yes, go to step S508, otherwise, go to step S512;
  • Step S508 loop judgment 3 times (determine 3 or more messages), determine whether the SSRC is consistent, if yes, go to step S509, otherwise, go to step S512;
  • Step S509 if the conditions are satisfied for three consecutive times, it is determined that it is an RTP or RTCP message, and if it is an RTP message, the process proceeds to step S511;
  • Step S510 compressing the message
  • Step S511 recording the SSRC identifier in the RTP header of the IP address UDP port number, creating an ROHC compression decompression instance, constructing a message, and recording the information recorded in the format shown in FIG. 6 (when using CRTP compression, format and diagram) 6 is similar, except that the identifier needs to be encapsulated by the CRTP identifier and sent to the GW2.
  • FIG. 6 is a schematic diagram of the ROHC custom negotiation packet encapsulation format according to the embodiment of the present invention, and the GW2 receives the information according to the information received. , create a compressed decompression instance, and at the same time reply GW1 according to the format of Figure 6, go to step S513;
  • Step S512 determining that the RTP and the RTCP packet are not, and continuing to detect the received packet
  • Step S513 after the GW1 receives the ROHC compression, the packet filtering module searches for the corresponding entry in the ROHC compression instance table after receiving the RTP message, and if so, starts to compress the RTP packet, based on the ROHC instance. Create a compressed decompression session, compress RTP packets, including IP header + UDP header + RTP header, and GW2 handles GW1 gateway operations.
  • GW1 or GW2 receives the RTCP packet. If the hang-up packet, that is, the corresponding field of the RTCP packet 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 identifier are used to search for the ROHC compression decompression table. If it can be found, the corresponding RTP compression and decompression session is deleted, and the other party is notified to delete the corresponding compression and decompression session according to the format of FIG. 6.
  • FIG. 7 is a scenario in which a UE directly accesses a satellite communication scenario according to an embodiment of the present invention.
  • the following takes the UE as a mobile phone as an example to describe an embodiment of the present invention.
  • the ROHC compression is also used (again, the CRTP compression method can also be used.
  • the ROHC compression method is taken as an example)
  • the voice message is compressed
  • the mobile phone and the GW2 reside. Compression and packet filtering modules.
  • Step S1 After the mobile phone accesses the mobile phone and initiates a voice call through the network, the packet filtering module monitors that the packet sent by the mobile phone is an RTP voice message;
  • Step S2 The compression module records the SSRC identifier in the RTP header of the IP address UDP port number, creates an ROHC compression decompression instance, constructs a packet, and encapsulates the information recorded in the format of FIG. 5 and sends it to GW2, and GW2 receives the packet. Then, according to the information sent, create a compressed decompression instance, and at the same time reply to the mobile phone according to the format of FIG. 6;
  • Step S3 after receiving the message from GW2 that the compression and decompression is successful, the mobile phone starts ROHC compression, and goes to S4;
  • Step S4 When the GW2 or the packet filtering module of the mobile phone monitors the sent RTP voice packet, it searches for a corresponding entry in the ROHC compression instance table, and if so, starts to compress the RTP packet, based on the ROHC instance. Create a compressed decompression session and compress the RTP header, including the IP header + UDP header + RTP header.
  • the mobile phone or the GW2 receives the RTCP packet. If the hang-up packet, that is, the corresponding field of the RTCP packet 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 identifier are used to search for the ROHC compression decompression table. If it can be found, the corresponding RTP compression and decompression session is deleted, and the other party is notified to delete the corresponding compression and decompression session according to the format of FIG. 6.
  • the local compression decompression table is deleted, and the peer end is notified to delete, and the negotiation is started to establish a compression decompression table.
  • This embodiment is described by taking the satellite communication scenario shown in FIG. 4 as an example:
  • the voice message is compressed by using CUDP compression, and the compression and packet filtering modules are resident on GW1 and GW2.
  • step S1 after receiving the packet, GW1 determines whether it is an RTP packet according to the process shown in Figure 5.
  • the packet filtering module analyzes all the received packets, and first determines whether the UDP packet is a UDP packet. Whether the IP address and port number can be found in the CUDP compression and decompression instance. If it can be found, it is considered to be an established compression session. If it cannot be found, it continues to determine whether the UDP data frame is greater than 12 bytes. It is judged whether the first two digits of the UDP payload are 0x10 (whether RTP/RTCP is 2).
  • the loop judges 3 times, and it is judged whether the SSRC is consistent, and the conditions are satisfied for 3 consecutive times. Then it is determined that it is an RTP or RTCP message, and if it is an RTP message, the process jumps to the second step;
  • FIG. 8 is a schematic diagram of a CUDP custom negotiation packet encapsulation format according to an embodiment of the present invention.
  • the packet filtering module searches for the corresponding entry in the CUDP compressed channel table after receiving the RTP packet, and if so, starts to compress the RTP packet and compress the RTP packet.
  • GW2 handles operations similar to GW1 gateways.
  • GW1 or GW2 receives the RTCP packet. If the hang-up packet, that is, the corresponding field of the RTCP packet 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. UDP port number to find the CUDP compression decompression table, if It is found that the corresponding RTP compression and decompression session is deleted, and the other party is notified to delete the corresponding compression and decompression session according to the format of FIG. 8.
  • the GW1 or GW2 deletes the local compression and decompression table, and notifies the peer to delete, and re-initiates the negotiation to establish a compression and decompression table.
  • the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation.
  • the technical solution of the embodiments of the present invention may be embodied in the form of a software product in essence or in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic).
  • the disc, the optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.
  • a packet processing apparatus is further provided, which is used to implement the foregoing embodiments and optional implementation manners, and has not been described again.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • the devices described in the following embodiments are optionally implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 9 is a structural block diagram of a first message processing apparatus according to an embodiment of the present invention. As shown in FIG. 9, the apparatus includes a compression module 92 and a first transmission module 94, which will be described below.
  • the compression module 92 is configured to compress the real-time transport protocol (RTP) message to be sent to the receiving end in a compressed manner negotiated with the receiving end; the first sending module 94 is connected to the compressing module 92, and is configured to pass the satellite after the compression succeeds. The compressed RTP packet is sent to the receiving end.
  • RTP real-time transport protocol
  • FIG. 10 is a block diagram of an optional structure of a first packet processing apparatus according to an embodiment of the present invention. As shown in FIG. 10, the apparatus includes a first negotiation module 102, in addition to all the modules shown in FIG. The device will be described below.
  • the first negotiation module 102 is connected to the compression module 92 for receiving and receiving the following manners.
  • Negotiating the foregoing compression mode establishing a compression table according to the information about the RTP message to be sent to the receiving end, where the compression table carries the currently selected compression mode identifier and the RTP message related information, when the currently selected compression
  • the related information includes 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 When the compression mode is configured to compress the user data protocol CUDP, the related information includes the source IP address, the destination IP address, the UDP source port, and the UDP destination port of the RTP packet, and the compressed table is sent to the receiving end, where the compression is performed.
  • the table is used to instruct the receiving end to establish a decompression table corresponding to the compressed table.
  • FIG. 11 is a structural block diagram of a first negotiation module 102 in a first packet processing apparatus according to an embodiment of the present invention. As shown in FIG. 11, when acquiring related information of an RTP message, the first negotiation module 102 includes a judgment. Unit 112 and extraction unit 114, the first negotiation module 102 will be described below.
  • the determining unit 112 is configured to determine whether the received message to be sent to the receiving end is an RTP message, and the extracting unit 114 is connected to the determining unit 112, where the determining result is that the message is an RTP message, Extract the related information of the packet as the related information of the RTP packet.
  • the determining unit 112 may determine, by using the following manner, whether the received packet to be sent to the receiving end is an RTP packet: determining whether the packet to be sent to the receiving end is a UDP packet; After the UDP packet is received, it is determined whether the number of bytes of the UDP data frame of the packet is greater than a predetermined number. If the packet is greater than the predetermined number, it is determined whether the predetermined bit in the UDP payload of the packet is a predetermined value.
  • the encoding format of the payload PAYLOAD of the message is an encoding format of the RTP; when it is determined that the PAYLOAD of the packet is an encoding format of the RTP, it is determined that the packet is an RTP packet. Text.
  • FIG. 12 is a second block diagram of an optional structure of a packet processing apparatus according to an embodiment of the present invention. As shown in FIG. 12, the apparatus includes a first receiving module 122, in addition to all the modules shown in FIG. The second transmitting 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-described compression module 92.
  • the first receiving module 122 is connected to the first sending module 94, and configured to receive the first real-time transmission control protocol RTCP packet carrying the hang-up command after transmitting the established compression table to the receiving end; the second sending module 124 The first receiving module 122 is 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; The module 126 is coupled to the second sending module 124 for deleting the compressed table after receiving a successful deletion response from the receiving end.
  • FIG. 13 is a block diagram 3 of an optional structure of a first message processing apparatus according to an embodiment of the present invention. As shown in FIG. 13, the apparatus includes a second deletion module 132 and all but the modules shown in FIG. The third transmitting module 134 is 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.
  • the second deletion module 132 is connected to the first sending module 94, and is configured to compress the RTP packet to be sent to the receiving end according to the compression manner negotiated in advance with the receiving end, and the number of failed RTP packets exceeds the number of times. After the threshold and/or the continuous compression of the RTP packet fails to exceed the second threshold, the compression table is deleted; the third sending module 134 is connected to the second deletion module 132, and configured to send the second notification message to the receiving end. The second notification message is used to notify the receiving end to delete the decompression table.
  • FIG. 14 is a block diagram showing an optional structure of a first message processing apparatus according to an embodiment of the present invention. As shown in FIG. 14, the apparatus includes a second receiving module 142 in addition to all the modules shown in FIG. The third deletion module 144 is described below. FIG. 14 is only an example, and the second receiving module 142 may also be connected to the above-described compression module 92.
  • the second receiving module 142 is connected to the first sending module 94, and configured to receive a third notification message from the receiving end for notifying the deletion of the compressed table after transmitting the compressed RTP message to the receiving end by using the satellite;
  • the third deleting module 144 is connected to the second receiving module 142, and is configured to delete the compression table according to the third notification message.
  • the foregoing third notification message includes at least one of the following: the number of times the receiving end fails to decompress and compress the RTP message exceeds the first threshold and/or the continuously decompressed compressed RTP message The notification message sent when the time of failure exceeds the second threshold; the notification message sent by the receiving end after receiving the second real-time transmission control protocol RTCP message carrying the hang-up instruction.
  • the message processing device is located in the first gateway or the terminal, and the receiving end includes the second gateway; or the message processing device is located in the second gateway, and the receiving end includes the first gateway or the terminal. .
  • FIG. 15 is a structural block diagram of a second packet processing apparatus according to an embodiment of the present invention. As shown in FIG. 15, the apparatus includes a third receiving module 152. The decompression module 154 is described below.
  • the third receiving module 152 is configured to receive the compressed real-time transport protocol RTP message sent by the sending end by using the satellite, and the decompressing module 154 is connected to the third receiving module 152 for decompressing according to the sending end.
  • the method decompresses the compressed RTP packet.
  • FIG. 16 is a block diagram showing an optional structure of a second packet processing apparatus according to an embodiment of the present invention. As shown in FIG. 16, the apparatus includes a second negotiation module 162 in addition to all the modules shown in FIG. The device will be described below.
  • the second negotiation module 162 is connected to the decompression module 154, and is configured to negotiate a decompression manner with the sending end by: receiving a compression table from the sending end; and establishing, according to the compression table, a decompressing and compressing RTP message. Uncompress the table.
  • FIG. 17 is a second block diagram of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • the apparatus includes a fourth receiving module 172 in addition to all the modules shown in FIG.
  • the fourth deletion module 174 will be described below.
  • FIG. 17 is only an example, and the fourth receiving module 172 may also be connected to the second negotiation module 162 described above.
  • the fourth receiving module 172 is connected to the decompression module 154, and configured to receive a fourth notification message from the sending end after the decompressing table for decompressing the compressed RTP message is established according to the compression table.
  • the fourth deletion module 174 is connected to the fourth receiving module 172 for deleting the decompression table according to the fourth notification message.
  • the fourth notification message includes at least one of the following: the number of times the sender fails to compress the RTP message to be sent exceeds the first threshold, and/or continuously compresses the RTP message to be sent.
  • FIG. 18 is a block diagram 3 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • the device when the fourth notification message includes the first end of the receiving end that receives the hangup instruction, the device further includes a fourth sending module 182, The device will be described.
  • the fourth sending module 182 is connected to the fourth deleting module 174, and 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 Compress the table.
  • FIG. 19 is a block diagram showing an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • the apparatus includes a fifth receiving module 192, in addition to the module shown in FIG.
  • the fifth transmitting 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 second negotiating module 162 described above.
  • the fifth receiving module 192 is connected to the decompression module 154, and configured to receive a second real-time transmission control protocol RTCP packet carrying the hang-up command after receiving the compression table from the transmitting end, and the fifth sending module 194 is connected to the foregoing
  • the fifth receiving module 192 is 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 compressed table, and the fifth deleting module 196 is connected to the fifth sending module 194, where After receiving the successful deletion response from the above sender, the decompression table is deleted.
  • FIG. 20 is a block diagram 5 of an optional structure of a second packet processing apparatus according to an embodiment of the present invention.
  • the apparatus includes a processing module 202 in addition to the module shown in FIG. The device is described.
  • FIG. 20 is only an example, and the processing module 202 can also be coupled to the second negotiation module 162 described above.
  • the processing module 202 is connected to the compression module 154, and is configured to: after decompressing the compressed RTP packet according to a decompression manner negotiated with the sending end, and decompressing the compressed RTP packet, the number of failures exceeds a first threshold and And after the continuous decompression of the compressed RTP packet exceeds the second threshold, the decompression table is deleted, and the sixth notification message is sent to the sending end, where the sixth notification message is used to notify the sending end to delete the compression. table.
  • the message processing device is located in the second gateway, and the sending end includes the first gateway or the terminal; or the message processing device is located in the first gateway or the terminal, and the sending end includes the second gateway. .
  • each of the above modules can be implemented by software or hardware, and The foregoing may be implemented by, but not limited to, the above modules are all located in the same processor; or, the above modules are respectively located in multiple processors.
  • Embodiments of the present invention also provide a storage medium.
  • the foregoing storage medium may be configured to store program code for performing the following steps:
  • S11 compress the real-time transport protocol RTP packet to be sent to the receiving end according to a compression manner negotiated with the receiving end;
  • the compressed RTP packet is sent to the receiving end by using a satellite.
  • the storage medium is further arranged to store program code for performing the following steps:
  • the foregoing storage medium may include, but is not limited to, a USB flash drive, a Read-Only Memory (ROM), and a Random Access Memory (RAM).
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • the processor executes the steps in the foregoing embodiments according to the stored program code in the storage medium.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本文公布了一种报文处理方法及装置，其中，该方法包括：按照与接收端协商的压缩方式对待发送给接收端的实时传输协议(RTP)报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。

Description

报文处理方法及装置 技术领域
本发明实施例涉及但不限于通信领域，具体而言，涉及一种报文处理方法及装置。
背景技术
在海上与陆地上的大部分区域是蜂窝式移动通讯系统的信号所不能覆盖的，因此，作为一种有效的补充手段，卫星通讯被广泛地应用在上述的海上区域以及陆地上的大部分区域中，尤其应用于远洋运输、钻探、勘测以及渔业等部门。卫星通信具有不受时间、地点、环境等多种因素的限制，开通时间短、传输距离远、网络部署快、通信成本与通信距离无关等诸多优点，可以实语音和数据的实时双向传输。
其中，卫星电话是现有实现卫星通信的一种，由于卫星信道具有与地面信道不同的一些特点，而传输控制协议(Transfer Control Protocol，简称为TCP)/互联网协议(Internet Protocol，简称为IP)协议当初是为地面网络设计的，所以TCP/IP协议在卫星信道上的传输性能比较差。存在以下问题：
1)一方面延迟大，卫星信道的延时很长，典型的卫星通信延时在540ms左右，这会造成TCP协议不停的重传，引起通信链路的拥塞。另一方面实际的卫星通信中有很高的误码，而TCP协议不能区分出是网络阻塞造成的数据丢失或是误码造成的数据丢失，TCP协议会一律认为是网络阻塞造成的，从而降低TCP的发送窗口，引起传输的带宽下降；
2)卫星通信带宽低且租用费用昂贵，基于网络协议的语音传输(Voice over Internet Protocol，简称为VOIP)采用不同的编码格式时，需要不同的数据带宽，比如采用G729需要带宽8Kbps，而一个报文头(实时传输协议(Real-time Transport Protocol，简称为RTP)+用户数据协议(User Date Protocol，简称为UDP)+IP头)就占了16Kbps，所以一路VOIP电话就需要占用24Kbps的带宽，这对于卫星通信来说是资源极大的浪费。
因此，在相关技术中，存在着语音通信在卫星通讯领域上的带宽利用率不足的问题，而针对该问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种报文处理方法及装置，以至少解决相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题。
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
根据本发明实施例的一个方面，提供了一种报文处理方法，包括：按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。
可选地，通过如下方式与所述接收端协商所述压缩方式：根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。
可选地，所述RTP报文的相关信息通过如下方式获取：判断接收到的待发送给所述接收端的报文是否是RTP报文；在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。
可选地，判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：判断待发送给所述接收端的所述报文是否是UDP报文；当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有 效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。
可选地，在将建立的所述压缩表发送给所述接收端之后，所述方法还包括：接收携带挂断指令的第一实时传输控制协议RTCP报文；向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；在接收到来自所述接收端的成功删除响应后，删除所述压缩表。
可选地，在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，所述方法还包括：在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值时，删除所述压缩表；向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。
可选地，在通过卫星将压缩后的RTP报文传输给所述接收端之后，所述方法还包括：接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；根据所述第三通知消息删除所述压缩表。
可选地，所述第三通知消息包括以下至少之一：所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。
根据本发明实施例的另一方面，提供了一种报文处理方法，包括：接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。
可选地，通过如下方式与所述发送端协商所述解压缩方式：接收来自所述发送端的压缩表；根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。
可选地，在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：接收来自所述发送端的第四通知消息；根据所述第四通知消息删除所述解压缩表。
可选地，所述第四通知消息包括以下至少之一：所述发送端在压缩待发 送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。
可选地，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，在根据所述第四通知消息删除所述解压缩表之后，所述方法还包括：向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。
可选地，在接收来自所述发送端的所述压缩表之后，所述方法还包括：接收携带挂断指令的第二实时传输控制协议RTCP报文；向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。
可选地，在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，所述方法还包括：当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。
根据本发明实施例的另一方面，提供了一种报文处理装置，包括：压缩模块，用于按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；第一发送模块，用于在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。
可选地，所述装置还包括第一协商模块，用于通过如下方式与所述接收端协商所述压缩方式：根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立 的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。
可选地，在获取所述RTP报文的相关信息时，所述第一协商模块包括：判断单元，用于判断接收到的待发送给所述接收端的报文是否是RTP报文；提取单元，用于在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。
可选地，所述判断单元通过如下方式判断接收到的待发送给所述接收端的报文是否是RTP报文：判断待发送给所述接收端的所述报文是否是UDP报文；当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。
可选地，所述装置还包括：第一接收模块，用于在将建立的所述压缩表发送给所述接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；第二发送模块，用于向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；第一删除模块，用于在接收到来自所述接收端的成功删除响应后，删除所述压缩表。
可选地，所述装置还包括：第二删除模块，用于在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除所述压缩表；第三发送模块，用于向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。
可选地，所述装置还包括：第二接收模块，用于在通过卫星将压缩后的RTP报文传输给所述接收端之后，接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；第三删除模块，用于根据所述第三通知消息删除所述压缩表。
可选地，所述第三通知消息包括以下至少之一：所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。
可选地，所述报文处理装置位于第一网关或终端中，所述接收端包括第二网关；或者，所述报文处理装置位于第二网关中，所述接收端包括第一网关或终端。
根据本发明实施例的另一方面，提供了一种报文处理装置，包括：第三接收模块，用于接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；解压缩模块，用于根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。
可选地，所述装置还包括第二协商模块，用于通过如下方式与所述发送端协商所述解压缩方式：接收来自所述发送端的压缩表；根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。
可选地，所述装置还包括：第四接收模块，用于在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，接收来自所述发送端的第四通知消息；第四删除模块，用于根据所述第四通知消息删除所述解压缩表。
可选地，所述第四通知消息包括以下至少之一：所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。
可选地，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，所述装置还包括：第四发送模块，用于在根据所述第四通知消息删除所述解压缩表之后，向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。
可选地，所述装置还包括：第五接收模块，用于在接收来自所述发送端 的所述压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；第五发送模块，用于向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；第五删除模块，用于在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。
可选地，所述装置还包括：处理模块，用于在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。
可选地，所述报文处理装置位于第二网关中，所述发送端包括第一网关或终端；或者，所述报文处理装置位于第一网关或终端中，所述发送端包括第二网关。
通过本申请，采用按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。可见，本申请解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。
在阅读并理解了附图和详细描述后，可以明白其他方面。
附图概述
此处所说明的附图用来提供对本发明实施例的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本发明实施例的报文处理方法的流程图一；
图2是根据本发明实施例的报文处理方法的流程图二；
图3是根据本发明实施例的语音呼叫以及挂断过程的交互流程图；
图4是根据本发明实施例的卫星通信传输场景示意图；
图5是根据本发明实施例的RTP报文的判断流程图；
图6是根据本发明实施例的ROHC自定义协商报文封装格式示意图；
图7是根据本发明实施例的UE直接接入卫星通信场景；
图8是根据本发明实施例的CUDP自定义协商报文封装格式示意图；
图9是根据本发明实施例的第一种报文处理装置的结构框图；
图10是根据本发明实施例的第一种报文处理装置的可选结构框图一；
图11是根据本发明实施例的第一种报文处理装置中第一协商模块102的结构框图；
图12是根据本发明实施例的第一种报文处理装置的可选结构框图二；
图13是根据本发明实施例的第一种报文处理装置的可选结构框图三；
图14是根据本发明实施例的第一种报文处理装置的可选结构框图四；
图15是根据本发明实施例的第二种报文处理装置的结构框图；
图16是根据本发明实施例的第二种报文处理装置的可选结构框图一；
图17是根据本发明实施例的第二种报文处理装置的可选结构框图二；
图18是根据本发明实施例的第二种报文处理装置的可选结构框图三；
图19是根据本发明实施例的第二种报文处理装置的可选结构框图四；
图20是根据本发明实施例的第二种报文处理装置的可选结构框图五。
本发明的实施方式
下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
在本实施例中提供了一种报文处理方法，图1是根据本发明实施例的报文处理方法的流程图一，如图1所示，该流程包括如下步骤：
步骤S102，按照与接收端协商的压缩方式对待发送给接收端的实时传输 协议RTP报文进行压缩；
步骤S104，在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。
从上述步骤可知，在向接收端发送RTP报文时，首先对该RTP报文进行了压缩(由于RTP报文的报文头会占用较大的带宽，对RTP报文进行压缩时，可以仅对RTP报文的IP头、UDP头和RTP头进行压缩)，然后将压缩后的RTP报文发送给了接收端，其中，压缩后的RTP报文的大小相对于原始的未压缩的RTP报文而言，会小很多，这样，便可以减少带宽的占用，从而实现了在一定的带宽上发送更多的RTP报文的目的，提高了带宽的利用率，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。
在一个可选的实施例中，可以通过如下方式与接收端协商压缩方式：根据待发送给接收端的RTP报文的相关信息建立压缩表，其中，该压缩表中携带当前选择的压缩方式的标识和上述RTP报文的相关信息，当该当前选择的压缩方式为可靠头压缩(Robust Header Compression，简称为ROCH)或配置压缩实时协议(Configuring Compressed Real-Time Protocol，简称为CRTP)时，上述相关信息包括RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当上述压缩方式为配置压缩用户数据协议(Configuring Compressed User Date Protocol，简称为CUDP)时，上述相关信息包括RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的上述压缩表发送给接收端，其中，该压缩表用于指示接收端建立与压缩表对应的解压缩表。其中，接收端在成功建立了解压缩表后，可以再返回一个建立OK的响应消息。
需要说明的是，上述的几种压缩方式仅是示例，还可以采用其他的压缩方式，同样地，当采用其他的压缩方式时，需要建立与该其他的压缩方式对应的压缩表，不同的压缩方式对应的压缩表中的内容可以是不同的。在上述的协商方式完成之后，两端便可以采用协商的方式进行RTP报文的压缩、解压缩操作了。
在一个可选的实施例中，上述RTP报文的相关信息可以通过如下方式获取：判断接收到的待发送给接收端的报文是否是RTP报文；在判断结果为该报文是RTP报文的情况下，提取上述报文的相关信息作为RTP报文的相关信息。其中，该待发送给接收端的报文可以是需要发送给接收端的第一个RTP报文，并且，为了避免延时过大，该第一个RTP报文可以不经过压缩直接发送给接收端。
其中，判断报文是否是RTP报文的方式可以有多种判断方式，下面对本发明实施例中提出的判断方法进行说明：判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：判断待发送给接收端的报文是否是UDP报文；当确定该报文是UDP报文后，判断该报文的UDP数据帧的字节数是否大于预定数量(例如，该预定数量为12个字节，即，是否大于RTP报文固定头的长度)，如果大于预定数量，则判断报文的UDP载荷中的预定位(例如，前两位)是否为预定值(例如，0x10，即，是否与现行的RTP版本号相同)；当确定该报文的UDP载荷中的预定位是预定值时，判断报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定该报文的PAYLOAD为RTP的编码格式时，确定该报文是RTP报文。采用本发明实施例中的判断方案，即通过判断编码格式是否是RTP的编码格式来确定报文是否是RTP报文，能够简化判断步骤，提高判断准确度。并且，在后续的过程中，当接收到需要发送给接收端的报文后，也可以按照上述方法判断接收到的报文是否是RTP报文，当确定是时，再对确定是RTP的报文按照上述的实施例中的方法进行压缩，然后，发送压缩后的RTP报文。
执行上述操作的主体可以是发送端，压缩表和解压缩表在建立之后，发送端和接收端也可以对压缩表和解压缩表进行删除或更新操作，在一个可选的实施例中，在将建立的压缩表发送给接收端之后，上述方法还包括：接收携带挂断指令的第一实时传输控制协议RTCP报文；向接收端发送第一通知消息，其中，该第一通知消息用于通知接收端删除解压缩表；在接收到来自上述接收端的成功删除响应后，删除压缩表。其中，该RTCP报文中的特定字段可以被设置为BYE，该被设置为BYE的特定字段可以是上述的挂断指令。
在一个可选的实施例中，在按照预先与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩之后，该方法还包括：在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除上述压缩表；向接收端发送第二通知消息，其中，该第二通知消息用于通知接收端删除解压缩表。其中，在该实施例中，可以在压缩RTP报文失败后即删除压缩表，也可以当压缩RTP报文失败的次数超过预定次数(该预定次数可以大于1)后再删除压缩表，或者，也可以在持续压缩RTP报文失败的时间超过一定值的时候删除压缩表，然后再通知接收端删除解压缩表。
在上述实施例中描述了压缩表和解压缩表的删除是由发送端(即，执行上述操作的一端)触发的，当然，压缩表和解压缩表的删除也可以是由接收端触发的，在一个可选的实施例中，在通过卫星将压缩后的RTP报文传输给接收端之后，该方法还包括：接收来自接收端的用于通知删除压缩表的第三通知消息；根据该第三通知消息删除压缩表。
在一个可选的实施例中，上述第三通知消息可以包括以下至少之一：接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；上述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。同样的，接收端在解压缩压缩后的RTP报文失败的情况下发送的通知消息可以是在接收端解压一次失败后即发送的通知消息，也可以是接收端解压失败的次数超过预定次数后发送的通知消息，或者，也可以是接收端在持续解压缩失败的时间超过一定值后发送的通知消息，并且，接收端在发送通知消息之前，可以先删除接收端中的解压缩表。
在上述实施例中，当发送端删除了压缩表、接收端删除了解压缩表后，发送端和接收端可以重新发起协商建立压缩表和解压缩表的流程。
在本实施例中还提供了一种报文处理方法，图2是根据本发明实施例的报文处理方法的流程图二，如图2所示，该流程包括如下步骤：
步骤S202，接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；
步骤S204，根据与上述发送端协商的解压缩方式解压缩压缩后的RTP 报文。
由上述步骤可知，接收的RTP报文是压缩后的RTP报文，即，发送端在发送RTP报文时，首先对该RTP报文进行了压缩，然后再发送压缩后的RTP报文，其中，压缩后的RTP报文的大小相对于原始的未压缩的RTP报文而言，会小很多，这样，便可以减少带宽的占用，从而实现了在一定的带宽上发送更多的RTP报文的目的，提高了带宽的利用率，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。
在一个可选的实施例中，可以通过如下方式与发送端协商上述解压缩方式：接收来自发送端的压缩表；根据该压缩表建立用于解压缩上述压缩后的RTP报文的解压缩表。需要说明的是，上述的压缩表里可以标识采用的是何种压缩方式(例如，可以是ROCH压缩方式或者，CUDP压缩方式)，不同的压缩方式对应的压缩表中的内容可以是不同的。在上述的协商方式完成之后，两端便可以采用协商的方式进行RTP报文的压缩、解压缩操作了。
其中，执行上述操作的主体可以是接收端，压缩表和解压缩表在建立之后，发送端和接收端也可以对压缩表和解压缩表进行删除或更新操作，在一个可选的实施例中，在根据上述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：接收来自发送端的第四通知消息；根据该第四通知消息删除上述解压缩表。
在一个可选的实施例中，上述第四通知消息可以包括以下至少之一：发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。可选地，发送端在压缩RTP报文失败的情况下发送的通知消息可以是在发送端压缩一次失败后即发送的通知消息，也可以是发送端压缩失败的次数超过预定次数后发送的通知消息，或者，也可以是发送端在持续压缩失败的时间超过一定值后发送的通知消息，并且，发送端在发送通知消息之前，可以先删除发送端中的压缩表；从上述的描述中可知，RTCP报文中可以携带挂断指令，其携带方式可以是在RTCP中预定字段被设置为BYE。
在一个可选的实施例中，当上述第四通知消息包括发送端在接收到携带挂断指令的第一RTCP报文后发送的通知消息时，在根据上述第四通知消息删除解压缩表之后，上述方法还包括：向所述发送端发送成功删除响应，其中，该成功删除响应用于指示发送端删除压缩表。
在上述实施例中描述了压缩表和解压缩表的删除是由发送端触发的，当然，压缩表和解压缩表的删除也可以是由接收端触发的，在一个可选的实施例中，在接收来自发送端的压缩表之后，该方法还包括：接收携带挂断指令的第二实时传输控制协议RTCP报文；向发送端发送第五通知消息，其中，该第五通知消息用于通知发送端删除压缩表；在接收到来自发送端的成功删除响应后，删除上述解压缩表。其中，RTCP报文中携带挂断指令的携带方式可以是在RTCP中预定字段被设置为BYE。
在一个可选的实施例中，在根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文之后，该方法还包括：当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除上述解压缩表，并向发送端发送第六通知消息，其中，该第六通知消息用于通知发送端删除压缩表。其中，在该实施例中，可以在解压缩RTP报文失败后即删除解压缩表，也可以当解压缩RTP报文失败的次数超过预定次数(该预定次数可以大于1)后再删除解压缩表，或者，也可以在持续解压缩RTP报文失败的时间超过一定值的时候删除解压缩表，然后再通知发送端删除压缩表。
在上述实施例中，当发送端删除了压缩表、接收端删除了解压缩表后，发送端和接收端可以重新发起协商建立压缩表和解压缩表的流程。
下面以上述的发送端为网关GW1，接收端为网关GW2为例，对本发明实施例的整体流程进行说明：
图3是根据本发明实施例的语音呼叫以及挂断过程的交互流程图，如图3所示，该流程包括如下步骤：
步骤S301，当主叫方的用户设备(User Equipment，简称为UE)(以下简称为UE)需要发起语音呼叫被叫方时，该UE向IP对媒体子系统(IP multimedia subsystem，简称为IMS)发起语音呼叫；
步骤S302，当IMS确定允许UE进行语音呼叫时，向UE返回一个语音呼叫成功的响应；
步骤S303，UE向UE侧的网关GW1发送语音报文(对应于上述的RTP报文)；
步骤S304，GW1确定压缩方式，并根据该语音报文建立该压缩方式下的压缩表，其建立过程如上述的实施例所述，在此不再陈述；并且，GW1将该语音报文和建立的压缩表发送给被叫侧UE的网关GW2，GW2根据压缩表建立于该压缩表对应的解压缩表；
步骤S305，GW1与GW2建立压缩会话；
步骤S306，GW2向GW1返回建立压缩会话成功消息；
步骤S307，GW2将GW1发送过来的语音报文发送给IMS；
步骤S308，UE向GW1发送语音报文；
步骤S309，GW1对UE发送过来的语音报文按照上述确定的压缩方式进行压缩，并将压缩后的语音报文发送到GW2；
步骤S310，GW2对接收到的压缩的语音报文进行解压缩，并将解压缩后的语音报文发送给IMS；
步骤S311，GW2接收到被叫侧UE发送的语音报文，并且，GW2按照和上述相同的方式和GW1协商压缩解压缩方式；
步骤S312，GW2按照协商的压缩方式压缩被叫侧UE发送的语音报文，并发送给GW1；
步骤S313，GW1对接收的压缩后的来自被叫侧UE的语音报文进行解压缩，并发送给主叫方的UE；
步骤S314，主叫方UE确定需要挂断此次语音通话，会向IMS发送挂断语音呼叫的通知；
步骤S315，GW1通知GW2删除压缩会话；
步骤S316，GW2向GW1返回删除压缩会话成功的消息；
步骤S317，IMS向主叫方UE发送你语音呼叫响应消息，至此，语音通 话结束。
下面结合具体应用场景对本申请进行说明：
实施实例1：
图4是根据本发明实施例的卫星通信传输场景示意图，如图4所示，在本实施方案中使用ROHC压缩(CRTP压缩和ROHC压缩是类似的，在此，以ROHC为例进行说明)的方法对语音报文进行压缩，ROHC通常用于无线通信的空中接口，在本例中用在卫星传输语音压缩的场景。
流程部分的处理步骤如下：
建立连接：
图5是根据本发明实施例的RTP报文的判断流程图，GW1在收到报文后，可以按照图5所示的流程判断是否为RTP报文，其判断流程包括如下步骤：
步骤S501，包过滤模块(该过滤模块可以是发送端或接收端中的一个模块)对所有收到的报文分析；
步骤S502，包过滤模块判断是否是UDP报文，如果是UDP报文，转至步骤S503，否则，转至步骤S512；
步骤S503，判断报文的IP地址(包括源IP地址和目的IP地址)和端口号(包括UDP源端口和UDP目的端口)是否能在ROHC压缩解压缩实例中查找到，如果能查找到，则认为是已建立好的压缩会话，转至步骤S510，否则，转至步骤S504；
步骤S504，判断UDP数据帧是否大于12个字节，如果判断结果为大于12个字节，则转至步骤S505，否则，转至步骤S512；
步骤S505，判断UDP载荷前两位是否为0x10(即判断RTP/RTCP版本号是否为2)，如果是转至步骤S506，否则，转至部署S512；
步骤S506，判断有效载荷(PAYLOAD)是否为RTP或RTCP的编码格式，判断结果为是，转至步骤S506，否则，转至步骤S512；
步骤S507，判断一个会话中同步信源标识符SSRC是否不变，判断结果为是，转至步骤S508，否则，转至步骤S512；
步骤S508，循环判断3次(判断3个以上报文)，判断SSRC是否一致，若为是，转至步骤S509，否则，转至步骤S512；
步骤S509，连续3次条件都满足，则判断认为是RTP或者RTCP报文，如果是RTP报文跳转到步骤S511；
步骤S510，压缩报文；
步骤S511，记录IP地址UDP端口号RTP头中的SSRC标识，创建ROHC压缩解压缩实例，构造一个报文，将上面记录的信息按照图6所示的格式(当采用CRTP压缩时，格式与图6所示类似，区别在于标识需要采用CRTP标识)封装后发送到GW2，其中，图6是根据本发明实施例的ROHC自定义协商报文封装格式示意图，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图6的格式回复GW1，转步骤S513；
步骤S512，确定不是RTP和RTCP报文，继续对接收到的报文进行检测；
步骤S513，GW1收到后启用ROHC压缩，包过滤模块在收到RTP报文后在ROHC压缩实例表中查找是否有对应的表项，如果有，则开始对RTP报文开始压缩，基于ROHC实例创建压缩解压缩会话，压缩RTP报文，包括IP头+UDP头+RTP头，GW2处理类似GW1网关操作。
其中，上述的步骤S507-S509是可选的，当针对单一的报文进行判断时，可以不用进行循环3次的判断。
下面对连接关闭进行说明：
GW1或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的ROHC压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号、SSRC标识查找ROHC压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图6的格式通知对方删除对应的压缩解压缩会话。
下面对异常保护进行说明：
GW1或者GW2连续一段时间内ROHC解压缩失败后，删除本端压缩解 压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。
实施实例2：
图7是根据本发明实施例的UE直接接入卫星通信场景。下面以上述UE为手机为例，对本发明实施例进行说明。
在本实施方案中同样使用ROHC压缩(同样地，也可以采用CRTP压缩方式，在该实施例中，以ROHC压缩方式为例进行说明)的方法对语音报文进行压缩，手机和GW2上驻留压缩和包过滤模块。
下面对连接建立过程进行说明：
步骤S1，手机通过卫星接入后，通过网络发起语音呼叫后，包过滤模块监听到手机发送的报文是RTP语音报文；
步骤S2，压缩模块记录IP地址UDP端口号RTP头中的SSRC标识，创建ROHC压缩解压缩实例，构造一个报文，将上面记录的信息按照图5的格式封装后发送到GW2，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图6的格式回复给手机；
步骤S3，手机收到来自GW2的创建压缩解压缩成功的消息后，启动ROHC压缩，转到S4；
步骤S4，GW2或者手机上包过滤模块在监听到发送的RTP语音报文时，则在ROHC压缩实例表中查找是否有对应的表项，如果有则开始对RTP报文开始压缩，基于ROHC实例创建压缩解压缩会话，压缩RTP报文头，包括IP头+UDP头+RTP头。
下面对连接关闭进行说明：
手机或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的ROHC压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号、SSRC标识查找ROHC压缩解压缩表，如果能查到，删除对应的RTP压缩解压缩会话，同时按照图6的格式通知对方删除对应的压缩解压缩会话。
下面对异常保护进行说明：
手机或者GW2连续一段时间内ROHC解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。
实施实例3：
该实施例以图4所示的卫星通信场景为例进行说明：
在本实施方案中使用CUDP压缩的方法对语音报文进行压缩，GW1和GW2上驻留压缩和包过滤模块。
下面对建立连接过程进行说明：
步骤S1，GW1在收到报文后按照图5所示的流程判断是否为RTP报文，包过滤模块对所有收到的报文分析，先判断是否UDP报文，如果是UDP报文，判断IP地址和端口号是否能在CUDP压缩解压缩实例中查找到，如果能查找到，则认为是已建立好的压缩会话，如果查找不到则继续判断UDP数据帧是否大于12个字节，如果是判断UDP载荷前两位是否为0x10(RTP/RTCP是否为2)，如果是判断PAYLOAD载荷是否为RTP或RTCP的编码格式，循环判断3次，判断SSRC是否一致，连续3次条件都满足，则判断认为是RTP或者RTCP报文，如果是RTP报文跳转到第二步；
S2，记录IP地址UDP端口号，创建CUDP压缩解压缩通道表，构造一个报文，将上面记录的信息按照图8的格式封装后发送到GW2，GW2在收到后根据发过来的信息，创建压缩解压缩实例，同时按照图8的格式回复GW1，其中，图8是根据本发明实施例的CUDP自定义协商报文封装格式示意图；
S3，GW1收到后启用CUDP压缩，包过滤模块在收到RTP报文后在CUDP压缩通道表中查找是否有对应的表项，如果有则开始对RTP报文开始压缩，压缩RTP报文，GW2处理类似GW1网关操作。
下面对连接关闭进行说明：
GW1或者GW2收到RTCP报文，如果是挂断报文，即RTCP报文的相应的字段被设置为BYE，则认为是删除RTP对应的CUDP压缩解压缩会话，根据RTCP头中的IP地址、UDP端口号查找CUDP压缩解压缩表，如果能 查到，删除对应的RTP压缩解压缩会话，同时按照图8的格式通知对方删除对应的压缩解压缩会话。
下面对异常保护进行说明：
GW1或者GW2连续一段时间内CUDP解压缩失败后，删除本端压缩解压缩表，同时通知对端删除，重新发起协商建立压缩解压缩表。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
在本实施例中还提供了一种报文处理装置，该装置用于实现上述实施例及可选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置可选地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图9是根据本发明实施例的第一种报文处理装置的结构框图，如图9所示，该装置包括压缩模块92和第一发送模块94，下面对该装置进行说明。
压缩模块92，用于按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；第一发送模块94，连接至上述压缩模块92，用于在压缩成功后，通过卫星将压缩后的RTP报文发送给接收端。
图10是根据本发明实施例的第一种报文处理装置的可选结构框图一，如图10所示，该装置除包括图9所示的所有模块外，还包括第一协商模块102，下面对该装置进行说明。
第一协商模块102，连接至上述压缩模块92，用于通过如下方式与接收 端协商上述压缩方式：根据待发送给接收端的RTP报文的相关信息建立压缩表，其中，该压缩表中携带当前选择的压缩方式的标识和RTP报文的相关信息，当该当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，上述相关信息包括RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当上述压缩方式为配置压缩用户数据协议CUDP时，上述相关信息包括RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；将建立的上述压缩表发送给接收端，其中，该压缩表用于指示接收端建立与压缩表对应的解压缩表。
图11是根据本发明实施例的第一种报文处理装置中第一协商模块102的结构框图，如图11所示，在获取RTP报文的相关信息时，该第一协商模块102包括判断单元112和提取单元114，下面对该第一协商模块102进行说明。
判断单元112，用于判断接收到的待发送给接收端的报文是否是RTP报文；提取单元114，连接至上述判断单元112，用于在判断结果为报文是RTP报文的情况下，提取报文的相关信息作为RTP报文的相关信息。
在一个可选的实施例中，上述判断单元112可以通过如下方式判断接收到的待发送给接收端的报文是否是RTP报文：判断待发送给接收端的报文是否是UDP报文；当确定上述报文是UDP报文后，判断报文的UDP数据帧的字节数是否大于预定数量，如果大于预定数量，则判断报文的UDP载荷中的预定位是否为预定值；当确定报文的UDP载荷中的预定位是预定值时，判断报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；当确定该报文的PAYLOAD为RTP的编码格式时，确定该报文是RTP报文。
图12是根据本发明实施例的第一种报文处理装置的可选结构框图二，如图12所示，该装置除包括图10所示的所有模块外，还包括第一接收模块122、第二发送模块124和第一删除模块126，下面对该装置进行说明。图12仅是一种示例，第一接收模块122还可以连接至上述压缩模块92。
第一接收模块122，连接至上述第一发送模块94，用于在将建立的压缩表发送给接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；第二发送模块124，连接至上述第一接收模块122，用于向接收端发送第一通知消息，其中，该第一通知消息用于通知接收端删除解压缩表；第一删 除模块126，连接至上述第二发送模块124，用于在接收到来自接收端的成功删除响应后，删除上述压缩表。
图13是根据本发明实施例的第一种报文处理装置的可选结构框图三，如图13所示，该装置除包括图10所示的所有模块外，还包括第二删除模块132和第三发送模块134，下面对该装置进行说明。图13仅是一种示例，第二删除模块132还可以连接至上述压缩模块92。
第二删除模块132，连接至上述第一发送模块94，用于在按照预先与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除上述压缩表；第三发送模块134，连接至上述第二删除模块132，用于向接收端发送第二通知消息，其中，该第二通知消息用于通知接收端删除上述解压缩表。
图14是根据本发明实施例的第一种报文处理装置的可选结构框图四，如图14所示，该装置除包括图10所示的所有模块外，还包括第二接收模块142和第三删除模块144，下面对该装置进行说明。图14仅是一种示例，第二接收模块142还可以连接至上述压缩模块92。
第二接收模块142，连接至上述第一发送模块94，用于在通过卫星将压缩后的RTP报文传输给接收端之后，接收来自上述接收端的用于通知删除压缩表的第三通知消息；第三删除模块144，连接至上述第二接收模块142，用于根据上述第三通知消息删除压缩表。
在一个可选的实施例中，上述第三通知消息包括以下至少之一：接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。
在一个可选的实施例中，上述报文处理装置位于第一网关或终端中，接收端包括第二网关；或者，上述报文处理装置位于第二网关中，接收端包括第一网关或终端。
在本发明实施例中还提供了一种报文处理装置，图15是根据本发明实施例的第二种报文处理装置的结构框图，如图15所示，该装置包括第三接收模块152和解压缩模块154，下面对该装置进行说明。
第三接收模块152，用于接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；解压缩模块154，连接至上述第三接收模块152，用于根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。
图16是根据本发明实施例的第二种报文处理装置的可选结构框图一，如图16所示，该装置除包括图15所示的所有模块外，还包括第二协商模块162，下面对该装置进行说明。
第二协商模块162，连接至上述解压缩模块154，用于通过如下方式与发送端协商解压缩方式：接收来自发送端的压缩表；根据上述压缩表建立用于解压缩压缩后的RTP报文的解压缩表。
图17是根据本发明实施例的第二种报文处理装置的可选结构框图二，如图17所示，该装置除包括图16所示的所有模块外，还包括第四接收模块172和第四删除模块174，下面对该装置进行说明。图17仅是一种示例，第四接收模块172还可以连接至上述第二协商模块162。
第四接收模块172，连接至上述解压缩模块154，用于在根据上述压缩表建立用于解压缩压缩后的RTP报文的所述解压缩表之后，接收来自发送端的第四通知消息；第四删除模块174，连接至上述第四接收模块172，用于根据上述第四通知消息删除解压缩表。
在一个可选的实施例中，上述第四通知消息包括以下至少之一：发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；上述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。
图18是根据本发明实施例的第二种报文处理装置的可选结构框图三，如图18所示，当上述第四通知消息包括发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，上述装置还包括第四发送模块182，下 面对该装置进行说明。
第四发送模块182，连接至上述第四删除模块174，用于在根据上述第四通知消息删除解压缩表之后，向发送端发送成功删除响应，其中，该成功删除响应用于指示发送端删除压缩表。
图19是根据本发明实施例的第二种报文处理装置的可选结构框图四，如图19所示，该装置除包括图16所示的模块外，还包括第五接收模块192、第五发送模块194和第五删除模块196，下面对该装置进行说明。图19仅是一种示例，第五接收模块192还可以连接至上述第二协商模块162。
第五接收模块192，连接至上述解压缩模块154，用于在接收来自发送端的压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；第五发送模块194，连接至上述第五接收模块192，用于向发送端发送第五通知消息，其中，该第五通知消息用于通知发送端删除压缩表；第五删除模块196，连接至上述第五发送模块194，用于在接收到来自上述发送端的成功删除响应后，删除解压缩表。
图20是根据本发明实施例的第二种报文处理装置的可选结构框图五，如图20所示，该装置除包括图16所示的模块外，还包括处理模块202，下面对该装置进行说明。图20仅是一种示例，处理模块202还可以连接至上述第二协商模块162。
处理模块202，连接至上述压缩模块154，用于在根据与发送端协商的解压缩方式解压缩压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除上述解压缩表，并向发送端发送第六通知消息，其中，该第六通知消息用于通知发送端删除压缩表。
在一个可选的实施例中，上述报文处理装置位于第二网关中，发送端包括第一网关或终端；或者，上述报文处理装置位于第一网关或终端中，发送端包括第二网关。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后 者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：
S11，按照与接收端协商的压缩方式对待发送给接收端的实时传输协议RTP报文进行压缩；
S12，在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
S21，接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；
S22，根据与上述发送端协商的解压缩方式解压缩压缩后的RTP报文。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述各实施例中的各个步骤。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
采用本发明实施例中的方法和装置，与现有技术相比，能够节省一半以上的语音占用带宽。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
工业实用性
本申请中，按照与接收端协商的压缩方式对待发送给接收端的RTP报文进行压缩；在压缩成功后，通过卫星将压缩后的RTP报文发送给上述接收端。通过本申请，解决了相关技术中存在的语音通信在卫星通讯领域上的带宽利用率不足的问题，进而达到了提高语音通信在卫星通讯领域上的带宽利用率，节省带宽资源的效果。

Claims (32)

  1. 一种报文处理方法，该方法包括：
    按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；
    在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。
  2. 根据权利要求1所述的方法，其中，通过如下方式与所述接收端协商所述压缩方式：
    根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；
    将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。
  3. 根据权利要求2所述的方法，其中，所述RTP报文的相关信息通过如下方式获取：
    判断接收到的待发送给所述接收端的报文是否是RTP报文；
    在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。
  4. 根据权利要求3所述的方法，其中，所述判断接收到的待发送给所述接收端的所述报文是否是RTP报文包括：
    判断待发送给所述接收端的所述报文是否是UDP报文；
    当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；
    当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；
    当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。
  5. 根据权利要求2所述的方法，在将建立的所述压缩表发送给所述接收端之后，所述方法还包括：
    接收携带挂断指令的第一实时传输控制协议RTCP报文；
    向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；
    在接收到来自所述接收端的成功删除响应后，删除所述压缩表。
  6. 根据权利要求2所述的方法，在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，所述方法还包括：
    在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除所述压缩表；
    向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。
  7. 根据权利要求2所述的方法，在通过卫星将压缩后的RTP报文传输给所述接收端之后，所述方法还包括：
    接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；
    根据所述第三通知消息删除所述压缩表。
  8. 根据权利要求7所述的方法，其中，所述第三通知消息包括以下至少之一：
    所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；
    所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。
  9. 一种报文处理方法，该方法包括：
    接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；
    根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。
  10. 根据权利要求9所述的方法，其中，通过如下方式与所述发送端协商所述解压缩方式：
    接收来自所述发送端的压缩表；
    根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。
  11. 根据权利要求10所述的方法，在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，所述方法还包括：
    接收来自所述发送端的第四通知消息；
    根据所述第四通知消息删除所述解压缩表。
  12. 根据权利要求11所述的方法，其中，所述第四通知消息包括以下至少之一：
    所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；
    所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。
  13. 根据权利要求12所述的方法，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，在根据所述第四通知消息删除所述解压缩表之后，所述方法还包括：
    向所述发送端发送成功删除响应，其中，所述成功删除响应用于指示所述发送端删除所述压缩表。
  14. 根据权利要求10所述的方法，在接收来自所述发送端的所述压缩表之后，所述方法还包括：
    接收携带挂断指令的第二实时传输控制协议RTCP报文；
    向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；
    在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。
  15. 根据权利要求10所述的方法，在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，所述方法还包括：
    当解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。
  16. 一种报文处理装置，该装置包括：
    压缩模块，设置为按照与接收端协商的压缩方式对待发送给所述接收端的实时传输协议RTP报文进行压缩；
    第一发送模块，设置为在压缩成功后，通过卫星将压缩后的RTP报文发送给所述接收端。
  17. 根据权利要求16所述的装置，其中，所述装置还包括第一协商模块，设置为通过如下方式与所述接收端协商所述压缩方式：
    根据待发送给所述接收端的RTP报文的相关信息建立压缩表，其中，所述压缩表中携带当前选择的压缩方式的标识和所述RTP报文的相关信息，当所述当前选择的压缩方式为可靠头压缩ROCH或配置压缩实时协议CRTP时，所述相关信息包括所述RTP报文的源互联网协议IP地址、目的IP地址、用户数据协议UDP源端口、UDP目的端口和RTP头；或者，当所述压缩方式为配置压缩用户数据协议CUDP时，所述相关信息包括所述RTP报文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；
    将建立的所述压缩表发送给所述接收端，其中，所述压缩表用于指示所述接收端建立与所述压缩表对应的解压缩表。
  18. 根据权利要求17所述的装置，其中，在获取所述RTP报文的相关信息时，所述第一协商模块包括：
    判断单元，设置为判断接收到的待发送给所述接收端的报文是否是RTP 报文；
    提取单元，设置为在判断结果为所述报文是RTP报文的情况下，提取所述报文的相关信息作为所述RTP报文的相关信息。
  19. 根据权利要求18所述的装置，其中，所述判断单元通过如下方式判断接收到的待发送给所述接收端的报文是否是RTP报文：
    判断待发送给所述接收端的所述报文是否是UDP报文；
    当确定所述报文是UDP报文后，判断所述报文的UDP数据帧的字节数是否大于预定数量，如果大于所述预定数量，则判断所述报文的UDP载荷中的预定位是否为预定值；
    当确定所述报文的UDP载荷中的预定位是预定值时，判断所述报文的有效载荷PAYLOAD的编码格式是否为RTP的编码格式；
    当确定所述报文的PAYLOAD为RTP的编码格式时，确定所述报文是RTP报文。
  20. 根据权利要求17所述的装置，所述装置还包括：
    第一接收模块，设置为在将建立的所述压缩表发送给所述接收端之后，接收携带挂断指令的第一实时传输控制协议RTCP报文；
    第二发送模块，设置为向所述接收端发送第一通知消息，其中，所述第一通知消息用于通知所述接收端删除所述解压缩表；
    第一删除模块，设置为在接收到来自所述接收端的成功删除响应后，删除所述压缩表。
  21. 根据权利要求17所述的装置，所述装置还包括：
    第二删除模块，设置为在按照预先与接收端协商的压缩方式对待发送给所述接收端的所述RTP报文进行压缩之后，并且在压缩RTP报文失败的次数超过第一阈值和/或连续压缩RTP报文失败的时间超过第二阈值后，删除所述压缩表；
    第三发送模块，设置为向所述接收端发送第二通知消息，其中，所述第二通知消息用于通知所述接收端删除所述解压缩表。
  22. 根据权利要求17所述的装置，所述装置还包括：
    第二接收模块，设置为在通过卫星将压缩后的RTP报文传输给所述接收端之后，接收来自所述接收端的用于通知删除所述压缩表的第三通知消息；
    第三删除模块，设置为根据所述第三通知消息删除所述压缩表。
  23. 根据权利要求22所述的装置，其中，所述第三通知消息包括以下至少之一：
    所述接收端在解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；
    所述接收端在接收到携带挂断指令的第二实时传输控制协议RTCP报文后发送的通知消息。
  24. 根据权利要求16至23中任一项所述的装置，其中，
    所述报文处理装置位于第一网关或终端中，所述接收端包括第二网关；或者，
    所述报文处理装置位于第二网关中，所述接收端包括第一网关或终端。
  25. 一种报文处理装置，该装置包括：
    第三接收模块，设置为接收发送端通过卫星发送的压缩后的实时传输协议RTP报文；
    解压缩模块，设置为根据与所述发送端协商的解压缩方式解压缩所述压缩后的RTP报文。
  26. 根据权利要求25所述的装置，所述装置还包括：
    第二协商模块，设置为通过如下方式与所述发送端协商所述解压缩方式：
    接收来自所述发送端的压缩表；
    根据所述压缩表建立用于解压缩所述压缩后的RTP报文的解压缩表。
  27. 根据权利要求26所述的装置，所述装置还包括：
    第四接收模块，设置为在根据所述压缩表建立用于解压缩所述压缩后的RTP报文的所述解压缩表之后，接收来自所述发送端的第四通知消息；
    第四删除模块，设置为根据所述第四通知消息删除所述解压缩表。
  28. 根据权利要求27所述的装置，其中，所述第四通知消息包括以下至少之一：
    所述发送端在压缩待发送过来的RTP报文失败的次数超过第一阈值和/或连续压缩待发送过来的RTP报文失败的时间超过第二阈值的情况下发送的通知消息；
    所述发送端在接收到携带挂断指令的第一实时传输控制协议RTCP报文后发送的通知消息。
  29. 根据权利要求28所述的装置，当所述第四通知消息包括所述发送端在接收到携带挂断指令的所述第一RTCP报文后发送的通知消息时，所述装置还包括：
    第四发送模块，设置为在根据所述第四通知消息删除所述解压缩表之后，向所述发送端发送成功删除响应；
    其中，所述成功删除响应用于指示所述发送端删除所述压缩表。
  30. 根据权利要求26所述的装置，所述装置还包括：
    第五接收模块，设置为在接收来自所述发送端的所述压缩表之后，接收携带挂断指令的第二实时传输控制协议RTCP报文；
    第五发送模块，设置为向所述发送端发送第五通知消息，其中，所述第五通知消息用于通知所述发送端删除所述压缩表；
    第五删除模块，设置为在接收到来自所述发送端的成功删除响应后，删除所述解压缩表。
  31. 根据权利要求26所述的装置，所述装置还包括：
    处理模块，设置为在根据与所述发送端协商的所述解压缩方式解压缩所述压缩后的RTP报文之后，并且解压缩压缩后的RTP报文失败的次数超过第一阈值和/或连续解压缩压缩后的RTP报文失败的时间超过第二阈值后，删除 所述解压缩表，并向所述发送端发送第六通知消息，其中，所述第六通知消息用于通知所述发送端删除所述压缩表。
  32. 根据权利要求25至31中任一项所述的装置，其中，
    所述报文处理装置位于第二网关中，所述发送端包括第一网关或终端；或者，
    所述报文处理装置位于第一网关或终端中，所述发送端包括第二网关。
PCT/CN2016/092367 2015-11-30 2016-07-29 报文处理方法及装置 WO2017092389A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510862787.7A CN106817350A (zh) 2015-11-30 2015-11-30 报文处理方法及装置
CN201510862787.7 2015-11-30

Publications (1)

Publication Number Publication Date
WO2017092389A1 true WO2017092389A1 (zh) 2017-06-08

Family

ID=58796186

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/092367 WO2017092389A1 (zh) 2015-11-30 2016-07-29 报文处理方法及装置

Country Status (2)

Country Link
CN (1) CN106817350A (zh)
WO (1) WO2017092389A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019096332A1 (zh) * 2017-11-20 2019-05-23 华为技术有限公司 报文头压缩机制确定方法、设备及系统

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257772A (zh) * 2017-07-13 2019-01-22 普天信息技术有限公司 一种rtp数据的发送、接收方法及用户设备
CN109347538B (zh) * 2018-09-27 2020-11-24 南京凯瑞得信息科技有限公司 一种基于窄带卫星信道实现VoIP通信的方法
CN110290130B (zh) * 2019-06-21 2020-09-01 京信通信系统（中国）有限公司 Volte数据的传输方法、装置、接入网设备以及存储介质
CN110830170A (zh) * 2019-11-12 2020-02-21 北京理工大学 一种卫星通信中基于rohc压缩的数据传输方法
CN114363419A (zh) * 2020-09-28 2022-04-15 中兴通讯股份有限公司 基于netconf协议的传输方法、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101848492A (zh) * 2010-06-10 2010-09-29 中兴通讯股份有限公司 媒体网关间的报文传输方法、媒体网关和无线通信系统
CN102882879A (zh) * 2012-10-08 2013-01-16 中国电子科技集团公司第五十四研究所 一种适用于卫星信道的ip数据压缩传输方法
WO2015000361A1 (zh) * 2013-07-03 2015-01-08 华为技术有限公司 报文压缩的方法和装置
WO2015076643A1 (en) * 2013-11-25 2015-05-28 Samsung Electronics Co., Ltd. Apparatus and method for processing header compressed packet in electronic device

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2857538B1 (fr) * 2003-07-08 2006-10-06 At & T Corp Systeme et methode de compression d'en-tete de paquets bases sur la creation dynamique d'un gabarit
CN1985477B (zh) * 2004-05-13 2012-11-07 高通股份有限公司 用于分配信息到通信系统的信道的方法和设备
US7602778B2 (en) * 2005-06-29 2009-10-13 Cisco Technology, Inc. System and methods for compressing message headers
CN102938683B (zh) * 2012-09-24 2015-07-29 华为技术有限公司 一种数据处理的方法和装置
CN103825869A (zh) * 2012-11-19 2014-05-28 中兴通讯股份有限公司 以太网报文头的压缩及解压缩方法、压缩及解压缩设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101848492A (zh) * 2010-06-10 2010-09-29 中兴通讯股份有限公司 媒体网关间的报文传输方法、媒体网关和无线通信系统
CN102882879A (zh) * 2012-10-08 2013-01-16 中国电子科技集团公司第五十四研究所 一种适用于卫星信道的ip数据压缩传输方法
WO2015000361A1 (zh) * 2013-07-03 2015-01-08 华为技术有限公司 报文压缩的方法和装置
WO2015076643A1 (en) * 2013-11-25 2015-05-28 Samsung Electronics Co., Ltd. Apparatus and method for processing header compressed packet in electronic device

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019096332A1 (zh) * 2017-11-20 2019-05-23 华为技术有限公司 报文头压缩机制确定方法、设备及系统

Also Published As

Publication number Publication date
CN106817350A (zh) 2017-06-09

Similar Documents

Publication Publication Date Title
WO2017092389A1 (zh) 报文处理方法及装置
US9762533B2 (en) Method of IMS (SIP network) webRTC optimized P2P communication
KR102192165B1 (ko) 전자 장치에서 헤더 압축된 패킷을 처리하기 위한 장치 및 방법
US20150304459A1 (en) Method and system of transmitting data over a network using a communication protocol
JP2004096717A (ja) 無線通信システムにおけるプロトコル・メッセージの圧縮
RU2645283C1 (ru) Способ и устройство адаптации стека протоколов
US20150071307A1 (en) Communication interface and method for robust header compression of data flows
WO2015168840A1 (zh) 一种数据处理方法及装置
KR101709244B1 (ko) 통신 시스템과 방법과 프로그램
WO2015139324A1 (zh) 配置指示方法和通信设备
WO2022083371A1 (zh) 一种数据传输方法和装置
TWI551090B (zh) 通訊主機裝置、數據機與在一系統中設定一通訊事件的方法
US20060146805A1 (en) Systems and methods of providing voice communications over packet networks
CN106817318B (zh) 鲁棒包头压缩状态协商方法、发送端以及系统
CN107431965B (zh) 一种实现传输控制协议tcp传输的方法及装置
CN101179353A (zh) 一种多媒体服务性能监测的方法和系统
CN107517202B (zh) 一种sip信令的二进制化发送和接收方法
WO2012155566A1 (zh) 上下文重用的方法及系统
WO2017067224A1 (zh) 一种报文处理方法及装置
CN103906140B (zh) 一种数据传输动态调整方法及设备
CN112887497B (zh) 通信方法、装置和计算机存储介质
CN111585962A (zh) 一种rtp数据包的处理方法、系统及存储介质
CN107172179B (zh) 一种双边加速传输方法和系统
CN107046673B (zh) 无线呼叫的方法和系统
KR101416901B1 (ko) 손실된 영상 패킷을 복구하는 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16869700

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16869700

Country of ref document: EP

Kind code of ref document: A1