An mcptt service communication method, system and related device

Abstract

This application discloses an MCPTT service communication method, system, and related apparatus, relating to the field of wireless communication. The method includes: during any transceiver interaction in MCPTT service communication, a first device carries identification information indicating a boundary packet when sending a voice rights signaling message. This provides an effective reference benchmark for a second device receiving the voice rights signaling message and media data, enabling the second device to determine the boundary media packet of the current voice burst event. The second device compares the identification information of the first media packet with the identification information of cached media packets to detect the loss of the first media packet. Upon determining that the first media packet is lost, the second device requests the first device to at least retransmit the first media packet. This solves, to some extent, the problem of imperceptible packet loss in MCPTT service scenarios, providing a foundation for ensuring the quality of MCPTT services.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to an MCPTT service communication method, system and related apparatus. Background Technology

[0002] MCPTT (Mission Critical Push To Talk, MCPTT) is a 3GPP (The 3rd Generation Partnership Project) initiative. rd The Generation Partnership Project (3GPP) has developed a key communication standard based on LTE (Long Term Evolution) / 5G broadband networks, aiming to provide highly reliable, low-latency trunking intercom services.

[0003] However, due to factors such as network jitter and transmission delay, the order in which voice signaling and media packets arrive at the receiving end during MCPTT service communication is not fixed. Combined with the inherent packet loss problem in the network, this results in a serious media boundary packet loss problem in MCPTT intercom scenarios, affecting the quality of MCPTT service communication. Summary of the Invention

[0004] In view of the above problems, this application provides an MCPTT service communication method, system and related apparatus to solve the boundary packet loss problem in MCPTT intercom scenarios, thereby improving the quality of MCPTT service communication.

[0005] The specific plan is as follows:

[0006] The first aspect of this application provides an MCPTT service communication method, applied to a second device in an MCPTT service communication system, the method comprising:

[0007] Receive a first message, which is a voice right signaling sent from the first device to the second device in the MCPTT service communication system. The first message carries the identification information of a first media packet. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets to be transmitted by the first device in this voice burst transaction.

[0008] The identification information of the first media package and the identification information of the media package cached by the second device are compared and processed.

[0009] If the comparison result determines that the second device has lost the first media packet, then a second message is sent to the first device, the second message being used to request the first device to retransmit the first media packet;

[0010] Receive the media packets retransmitted by the first device.

[0011] A second aspect of this application provides an MCPTT service communication method, applied to a first device in an MCPTT service communication system, the method comprising:

[0012] Send a first message, which is a voice access signaling sent by the first device to the second device in the MCPTT service communication system. The first message carries the identification information of the first media packet, which is used by the second device to determine whether the first media packet has been lost. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets to be transmitted by the first device in this voice burst transaction.

[0013] Receive a second message, which is a message sent by the second device when it determines that the first media packet is lost. The second message is used to request the first device to at least retransmit the first media packet.

[0014] The media packet is retransmitted to the second device, and the media packet retransmitted by the first device includes at least the first media packet.

[0015] A third aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0016] The memory is used to store computer programs;

[0017] The processor is used to execute the computer program to implement the MCPTT service communication method described in the first aspect above, or to implement the MCPTT service communication method described in the second aspect above.

[0018] A fourth aspect of this application provides an MCPTT service communication system, including a first device and a second device;

[0019] The first device sends a first message, which is a voice access signaling sent to the second device. The first message carries the identification information of a first media packet. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets that the first device needs to transmit in this voice burst event.

[0020] In response to the first message, the second device compares the identification information of the first media packet with the identification information of the media packet cached by the second device; if it is determined from the comparison result that the second device has lost the first media packet, then the second device sends a second message to the first device; the second message is used to request the first device to at least retransmit the first media packet.

[0021] The first device retransmits the media packet to the second device based on the second message, and the media packet retransmitted by the first device includes at least the first media packet.

[0022] The fifth aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, enable the electronic device to implement the MCPTT service communication method described in the first aspect above, or to implement the MCPTT service communication method described in the second aspect above.

[0023] By employing the above technical solution, during any transceiver interaction in MCPTT service communication, the first device sends a talk right signaling message carrying the identification information of the first media packet to the second device. This allows the second device to determine the boundary media packet of the current voice burst, compare the identification information of the first media packet with the identification information of the cached media packets, and request the first device to retransmit the first media packet if it is determined that it has been lost. This application provides an effective reference benchmark for the second device receiving the talk right signaling message and media data by having the first device carry the identification information indicating the boundary packet when sending the talk right signaling message. The second device can use this benchmark to determine the boundary media packet, detect the loss of the boundary media packet, and then request the first device to retransmit the lost packet. This, to a certain extent, solves the problem of imperceptible packet loss in MCPTT service scenarios and provides a foundation for ensuring the quality of MCPTT services. Attached Figure Description

[0024] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0025] Figure 1 A flowchart illustrating an MCPTT service communication method provided in this application;

[0026] Figure 2 This example illustrates the MCPTT (Multi-Purpose Terminal) service communication signaling diagram between the first terminal and the server during the initial phase of a transaction.

[0027] Figure 3 This example illustrates the MCPTT (Multi-Purpose Terminal) communication signaling diagram between the server and the second terminal during the initial phase of a transaction.

[0028] Figure 4 This example illustrates the MCPTT service communication signaling diagram between the first terminal and the server during the transaction completion phase.

[0029] Figure 5This example illustrates the MCPTT (Multi-Purpose Test) communication signaling between the server and the second terminal during the transaction completion phase.

[0030] Figure 6 This is a schematic diagram of the hardware structure of a server according to an embodiment of this application. Detailed Implementation

[0031] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0032] First, let me explain the concepts involved in this application.

[0033] The Mission Critical Client (MCC), or simply the client, is client software or functional module that runs on a user terminal (or simply the terminal). It is used to initiate communication requests, receive signaling and media data from the mission critical server, and present communication content to the user.

[0034] A Mission Critical Server (MCS) is used to provide mission-critical services. It can be a single physical server, a server cluster, or a cloud server. In some application scenarios, mission-critical services can also be provided by other devices. This application refers to all devices used to provide mission-critical services as servers.

[0035] Based on the above, the equipment involved in this application may include a terminal and a server. Furthermore, depending on the different roles in the call, the terminal can be divided into a calling terminal and a called terminal. The calling terminal is the end that initiates the speech and is granted the right to speak, which is referred to as the first terminal in this application; the called terminal is the end that receives the speech, which is referred to as the second terminal in this application.

[0036] The Talk Burst Transaction described in this application refers to a complete talk right (also known as speaking right) and voice transmission transaction in the MCPTT service. Specifically, it includes: when a first terminal needs to initiate a speech, it requests talk right by sending a Floor Request message to the server. The server controls talk right based on the received request message. When it determines to grant talk right to the first terminal, it sends a Floor Granted message to the first terminal and a Floor Taken message to the second terminal to achieve consensus on the speaking status among all participants. After being authorized, the first terminal begins sending media streams to the server, i.e., the various media packets to be transmitted in this Talk Burst Transaction, such as RTP media packets. The server forwards the received media packets to the second terminal. Finally, when the first terminal ends its speech, it sends a Floor Release message to the server to release the talk right. The server then sends a Floor Idle message to the second terminal.

[0037] It should be noted that for the device that needs to receive and respond to the voice rights signaling and media packets from the terminal, i.e., the server, the current voice burst transaction, i.e. the ongoing voice burst transaction, refers to the transaction initiated by the terminal that has been granted voice rights (i.e., the calling terminal). If a terminal sends a voice rights request message but does not obtain voice rights, the current transaction does not belong to that terminal, and the server does not need to respond to the voice rights request message of that terminal to execute the MCPTT service communication scheme described in this application.

[0038] Furthermore, a single voice burst transaction involves an interaction process between two sets of transceivers, specifically the interaction between the first terminal and the server, and the interaction between the server and the second terminal. During either interaction, packet loss may occur due to out-of-order arrival of voice right signaling and media packets, i.e., boundary packet loss. This can specifically be the loss of media packets at the beginning of the transaction (also known as the voice right request phase) or at the end of the transaction (also known as the voice right release phase).

[0039] The applicant discovered through research that, at the beginning of a transaction, media packets sent by the first terminal may be lost due to network packet loss, or may be discarded directly because their arrival time at the server is earlier than the right-of-way signaling. Similarly, media packets forwarded by the server may be lost due to network packet loss, or may be discarded directly because their arrival time at the second terminal is earlier than the right-of-way signaling. Likewise, at the end of a transaction, media packets sent by the first terminal may be lost due to network packet loss, or may be discarded directly because their arrival time at the server is later than the right-of-way signaling. Media packets forwarded by the server may be lost due to network packet loss, or may be discarded directly because their arrival time at the second terminal is later than the right-of-way signaling. Because the receiving end (including the server and the called terminal) lacks an effective reference point for receiving audio media streams at the beginning or end of a transaction, it cannot perceive the aforementioned packet loss situations and therefore cannot trigger packet loss compensation strategies. This ultimately leads to the loss of the first or last voice message, severely impacting the communication quality of MCPTT services.

[0040] To address the aforementioned issues, this application provides an MCPTT service communication method, system, and related apparatus. By carrying boundary packet identification information in the call right signaling, the receiving end can compare this identification with the identification information of cached media packets to determine whether packet loss has occurred. In the event of packet loss, the receiving end can request the sending end to retransmit the media packet, thereby resolving the boundary packet loss problem in MCPTT intercom scenarios and improving the communication quality of MCPTT services. It should be noted that the MCPTT service communication scheme provided in this application can be applied to any of the aforementioned interaction processes, namely, the interaction process between the first terminal and the server, and / or the interaction process between the server and the second terminal. The following describes the scheme for any interaction process to solve the boundary packet loss problem in that interaction process.

[0041] Figure 1 This is a flowchart illustrating an MCPTT service communication method according to an embodiment of this application. The method is applied to an MCPTT service communication system, which may include: a first device and a second device, wherein the first device is a transmitter of voice rights signaling and media packets, and the second device is a receiver of voice rights signaling and media packets.

[0042] In one possible implementation, the first device can be a first terminal integrated with a mission-critical client, i.e., the calling terminal for this voice interruption. In this case, the second device is a server providing mission-critical services. The MCPTT service communication system may also include a second terminal integrated with a mission-critical client (which can be represented as a third device), i.e., the called terminal for this voice interruption. Optionally, the third device can be an existing terminal or an improved terminal; this application does not limit this. In this case, the improved calling terminal and server can solve the uplink boundary packet loss problem, thereby reducing the possibility of downlink boundary packet loss.

[0043] In another possible implementation, the first device can be a server providing mission-critical services. In this case, the second device is a second terminal integrated with a mission-critical client, i.e., the called terminal in this voice interruption. The MCPTT service communication system may also include a first terminal integrated with a mission-critical client, i.e., the calling terminal in this voice interruption. Optionally, this terminal can be an existing terminal or an improved terminal; this application does not limit this. In this case, the downlink boundary packet loss problem can be solved by using an improved server and called terminal.

[0044] Combination Figure 1 As shown, the method may include the following steps:

[0045] S101, the first device sends a first message, and the corresponding second device receives the first message.

[0046] The first message is a voice right signaling sent from the first device to the second device. The first message carries the identification information of the first media packet. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets that the first device needs to transmit in this voice burst event.

[0047] Based on the above description, at the beginning of a transaction, the first device sends a voice authorization signaling message before sending the media stream. At the end of a transaction, the first device sends the voice authorization signaling message again after sending the media stream. Therefore, when the first message is a voice authorization signaling message at the beginning of a transaction, the first media packet is the first media packet that the first device will transmit within this voice burst transaction; when the first message is a voice authorization signaling message at the end of a transaction, the first media packet is the last media packet that the first device will transmit within this voice burst transaction. In other words, the aforementioned first media packet is a boundary packet transmitted between the first device and the second device and belongs to this voice burst transaction. Therefore, the identification information of the first media packet can also be called a boundary packet identifier, used to uniquely locate the corresponding media packet in the media stream of this voice burst transaction.

[0048] Optionally, the identification information of the first media packet can be carried in the extended fields of the talk rights signaling (including talk rights request messages and talk rights status indication messages).

[0049] After receiving the first message, the second device executes S102 while receiving and caching the media packets transmitted by the first device during this voice burst transaction.

[0050] Specifically, it should be noted that when the server receives a call right request message from a terminal, it may refuse to grant the call right to that terminal due to the existence of an existing calling terminal or other reasons. In this case, the server does not respond to the message by executing S102, nor does it perform a comparison operation based on the identification information in the message. In other words, at the beginning of the transaction, after sending the call right grant message, the server can execute S102 and subsequent steps provided in this application based on the call right request message of the first device that has been granted call right. For the first device that has not been granted call right, the server does not execute subsequent steps based on the call right signaling of that device.

[0051] S102, the second device compares the identification information of the first media package with the identification information of the media package cached by the second device, and determines whether the second device has lost the first media package based on the comparison result.

[0052] If the comparison results determine that the second device has lost the first media package, then execute S103.

[0053] The media packets cached by the second device refer to the media packets received and cached by the second device during this voice burst transaction.

[0054] The process of the server and the called terminal receiving and caching media packets is described below. After sending a talk rights grant message to the first terminal, the server begins receiving and caching media packets. Upon receiving a talk rights release message from the first terminal, it immediately or after a short delay stops receiving and caching media packets. After receiving a talk rights occupancy message from the server, the second terminal begins receiving and caching media packets. Upon receiving a talk rights idle message from the server, it immediately or after a short delay stops receiving and caching media packets.

[0055] For example, the aforementioned comparison process may include: comparing the identification information of the first media packet with the identification information of each media packet cached by the second device one by one. In other words, the comparison process may include: searching the buffer of the second device for a media packet whose identification information matches that of the first media packet. If the buffer of the second device contains a media packet whose identification information matches that of the first media packet, it indicates that the second device has received the first media packet and there is no need to request the first device to retransmit the media packet. Otherwise, it indicates that the second device has not received the first media packet, that is, the second device has lost the first media packet, and the second device executes S103 to request the first device to retransmit the media packet.

[0056] S103, the second device sends a second message to the first device, and the first device receives the second message accordingly.

[0057] The second message is sent by the second device when it determines that the first media packet has been lost. The second message is used to request the first device to retransmit the first media packet. Optionally, the second message can be a retransmission request, such as a NACK retransmission request, or other messages.

[0058] S104. The first device retransmits the media packet to the second device, and correspondingly, the second device receives the media packet retransmitted by the first device.

[0059] The media packet retransmitted by the first device includes at least the first media packet.

[0060] In one possible implementation, the second message can be a general retransmission request, meaning it may not carry identification information for missing packets. In this case, the first device, upon receiving the second message, can retransmit all media packets of the current call, or retransmit some or a specific set of media packets. For example, at the beginning of the transaction, retransmit the first media packet, or retransmit the first media packet and a predetermined number of adjacent media packets; at the end of the transaction, retransmit the last media packet, or retransmit the last media packet and a predetermined number of adjacent media packets. In scenarios where the first device only retransmits a portion of the media packets in response to the second message, such as only retransmitting the first media packet, the second device can determine the identification information of the remaining lost media packets based on the received first media packet, thereby triggering a NACK retransmission mechanism to resolve the loss of the remaining packets.

[0061] In another possible implementation, the second message may carry second identification information. This second identification information is used to indicate media packets that the second device did not receive during the current voice burst, or media packets that the second device did receive during the current voice burst, so that the first device can determine which media packets to retransmit.

[0062] Based on this, the second message can be used to instruct the first device to determine the lost media packet based on the second identification information therein and to retransmit the lost media packet. In other words, S104, where the first device retransmits the media packet to the second device, may include:

[0063] S201. The first device determines the media packet lost by the second device based on the second identification information in the second message;

[0064] S202, The first device sends the media packet lost by the second device to the second device.

[0065] This embodiment achieves the purpose of targeted packet loss retransmission by sending a missing packet indication message when requesting retransmission of media packets, and the sending end uses this to perform packet loss retransmission.

[0066] This application does not specify the specific form of the second message.

[0067] Based on the above, during any interaction in MCPTT service communication, the first device carries the identification information of the first media packet in the voice right signaling sent to the second device. This allows the second device to determine the boundary media packet of the current voice burst, compare the identification information of the first media packet with the identification information of the cached media packets, and request the first device to retransmit the first media packet if it is determined that it is lost. This application provides an effective reference benchmark for the second device receiving the voice right signaling and media data by having the first device carry the identification information of the boundary packet when sending the voice right signaling. The second device can use this to determine the boundary media packet, detect the loss of the boundary media packet, and then request the first device to retransmit the lost packet. This solves the problem of imperceptible packet loss in MCPTT service scenarios to a certain extent and provides a foundation for ensuring the quality of MCPTT services.

[0068] In one or more embodiments provided in this application, the identification information may include a timestamp and a serial number.

[0069] In other words, the voice right signaling carries the timestamp and sequence number of the first media packet / last media packet that the first device needs to transmit in this voice burst service.

[0070] Optionally, after receiving the media packet, the second device can sort the media packet according to its timestamp and sequence number, and then forward or play the media packet in sequence.

[0071] It should be noted that, since the order in which messages arrive at the second device is uncertain, the buffer of the second device may contain media packets corresponding to different transactions.

[0072] Based on this, in one possible implementation, the comparison process described in S102 may include:

[0073] S301, Take the first target media package from the media packages cached by the second device.

[0074] Specifically, S301 may include:

[0075] If the first message is a signaling message indicating the start of a transaction (such as a right-of-way request message or a right-of-way occupancy message), the media packet with the smallest sequence number and the smallest timestamp (i.e., the earliest corresponding time) is determined from the media packets cached by the second device and used as the first target media packet; or,

[0076] If the first message is a signaling message indicating the end of a transaction (such as a signaling message to release a signaling right or a signaling message to be idle), the media packet with the largest sequence number and the largest timestamp (i.e. the latest corresponding time) is determined from the media packets cached by the second device and used as the first target media packet.

[0077] S302. Compare the serial number and timestamp of the first media packet with those of the first target media packet.

[0078] The comparison described in S302 can refer to comparing whether the sequence number and timestamp of the first media packet and the first target media packet are the same. If they are the same, it is determined that the second device has not lost the first media packet; otherwise, it is determined that the second device has lost the first media packet. In other possible implementations, the comparison described in S302 can also be a comparison of sizes. For example, when the first message is a voice-right signaling at the beginning of a transaction, it can be determined whether the timestamp of the first media packet is less than the timestamp of the first target media packet, and whether the sequence number of the first media packet is less than the sequence number of the first target media packet. If either is true, it is determined that the second device has lost the first media packet; otherwise, it is determined that the second device has not lost the first media packet. When the first message is a voice-right signaling at the end of a transaction, it can be determined whether the timestamp of the first media packet is greater than the timestamp of the first target media packet, and whether the sequence number of the first media packet is greater than the sequence number of the first target media packet. If either is true, it is determined that the second device has lost the first media packet; otherwise, it is determined that the second device has not lost the first media packet.

[0079] This embodiment compares the identification information of the first media packet with the identification information of the specified media packet in the second device buffer to determine whether a boundary packet loss has occurred. This can improve the packet loss detection speed and processing speed, providing a basis for the called terminal to play audio earlier.

[0080] Specifically, since the buffer may contain media packets corresponding to different transactions, if the identification information of the first media packet and the first target media packet are inconsistent, the identification information of the first media packet can be compared with the identification information of other media packets in the buffer. In another possible implementation, multiple media packets with the smallest or largest timestamp and sequence number can be used as the first target media packet. The identification information of the first media packet can be compared with the identification information of each first target media packet. If there is consistent identification information, it is determined that the first media packet has not been lost; otherwise, it is determined that the first media packet has been lost.

[0081] In one or more embodiments provided in this application, the identification information may include a timestamp, a sequence number, and a synchronization source identifier (SSRC).

[0082] SSRC can be used to distinguish different speakers, i.e., the calling terminals of different transactions. Based on this, the comparison process described in S102 may include:

[0083] S401. If the first message is a signaling message indicating the start of a transaction, determine the media packet with the smallest sequence number and the smallest timestamp from the media packets carrying the specified SSRC cached by the second device, and use it as the first target media packet; or, if the first message is a signaling message indicating the end of a transaction, determine the media packet with the largest sequence number and the largest timestamp from the media packets carrying the specified SSRC cached by the second device, and use it as the first target media packet.

[0084] The SSRC is specified as the SSRC of the first media package.

[0085] S402. Compare the serial number and timestamp of the first media packet with those of the first target media packet.

[0086] Based on the above, the use of timestamps, serial numbers, and SSRC as identification information provides a foundation for accurately identifying boundary packet loss.

[0087] In one possible implementation, the right-of-way signaling at different stages can carry different types of identification information. For example, the right-of-way signaling at the beginning of a transaction, such as a right-of-way request message and a right-of-way occupancy message, can carry identification information for the first media packet, which may include the timestamp (firststamptime), sequence number (firstseqno), and SSRC of the first media packet that the first device will transmit in this voice burst transaction. The right-of-way signaling at the end of a transaction, such as a right-of-way release message and a right-of-way idle message, can carry identification information for the first media packet, which may include the timestamp (laststamptime) and sequence number (lastseqno) of the last media packet that the first device will transmit in this voice burst transaction.

[0088] The business communication solutions provided in this application are described below for different interaction scenarios and different transaction stages.

[0089] In one or more embodiments provided in this application, the first device is a first terminal integrated with a mission-critical client, and the second device is a server for providing mission-critical services. In this case, the system may further include a third device, namely a second terminal integrated with a mission-critical client.

[0090] Figure 2 This example illustrates the MCPTT (Multi-Client Pitch To Telephone) service communication signaling diagram between the first terminal and the server during the initial phase of a transaction. Combined with... Figure 2 As shown, the MCPTT service communication process between the first terminal and the server may include:

[0091] S501, the first terminal sends a talk rights request message, and the corresponding server receives the talk rights request message from the first terminal.

[0092] The voice rights request message carries the identification information of the first media packet. The first media packet is the first uplink media packet of this voice emergency, that is, the voice rights request message carries the identification information of the first uplink media packet, which is referred to as the uplink first packet identifier.

[0093] S502. When the server determines that the first terminal is the calling terminal, it sends a talk rights grant message to the first terminal, and the first terminal receives the talk rights grant message accordingly.

[0094] While sending the talk right grant message, the server also sends a talk right occupancy message to the second terminal. This message may or may not carry the identification information of the first media package, and this embodiment does not limit it.

[0095] After sending a talk rights grant message, the server begins caching received media packets in a buffer. Furthermore, while caching media packets, the server can sort them according to the identification information carried by the media packets, such as arranging them in ascending order of sequence number or in ascending order of timestamp, allowing the server to forward the sorted media packets to the called terminal.

[0096] S503, the first terminal responds to the voice authorization message and begins sending the media packets to be transmitted in this voice break to the server, and the server receives the media packets accordingly.

[0097] After receiving a media packet, the server buffers the received media packet and begins forwarding the buffered media packet after sending a talk time acquisition message.

[0098] S504. The server compares the identifier of the first uplink packet with the identifier information of the media packets cached by the server, and determines whether the first uplink media packet has been lost based on the comparison result.

[0099] If the comparison results indicate that the first packet of the uplink media was lost, then execute S505.

[0100] S505, the server sends a second message to the first terminal to request the first terminal to retransmit at least the first uplink media packet; correspondingly, the first terminal receives the second message.

[0101] S506. The first terminal retransmits the media packet to the server, and the corresponding server receives the retransmitted media packet from the first terminal.

[0102] In one or more embodiments provided in this application, when the first message is a voice right request message, the first media packet is the first uplink media packet, and the server is configured to: if it is determined that the server has lost the first uplink media packet, then after a first preset time after determining that the server has lost the first uplink media packet, start forwarding the media packets cached by the server to the third device for the third device to play voice.

[0103] The third device is the called terminal in this sudden voice incident, namely the aforementioned second terminal.

[0104] Based on this, after executing S504, the server can perform media packet forwarding operations based on the comparison results. Specifically, if the comparison results determine that the first uplink media packet has been lost, the server will start forwarding the cached media packets to the second terminal after waiting for a first preset time. If the comparison results determine that the first uplink media packet has not been lost, the server will directly start forwarding the cached media packets to the second terminal.

[0105] In one possible implementation, the first preset duration can be a pre-set fixed duration; in another possible implementation, the first preset duration may not be a fixed duration. For example, the first preset duration may be positively correlated with the number of uplink packet losses at the beginning of the transaction, wherein the number of uplink packet losses at the beginning of the transaction is determined by comparing the identification information of the first uplink media packet with the identification information of the media packets cached by the server.

[0106] For example, the first preset duration can be expressed as: (Sequence number of the first target media packet at the start of the transaction - Sequence number of the first uplink media packet) × unit duration, where the unit duration can be set based on the transmission time of a single media packet, for example, it can be set to 20 milliseconds (ms). That is to say, the more packets are lost, the longer the waiting time will be.

[0107] This embodiment increases the likelihood that the called terminal will receive the actual first media packet by delaying the forwarding of media packets, which helps to alleviate the problem of lost audio sounds caused by the loss of the first uplink media packet.

[0108] It should be noted that the server defaults to using the earliest message received when it starts forwarding media packets as the first uplink media packet. If this message is not the actual first packet, the server cannot detect the loss of the first uplink media packet and will not actively trigger the packet loss recovery mechanism (Negative Acknowledgement Retransmission, NACK retransmission mechanism), resulting in the loss of audio data at the beginning of the transaction and making it unrecoverable. This application, by carrying a speech right request message with the uplink first packet identifier, allows the server to clearly identify the sequence number (assumed to be seq_1) of the first uplink media packet (i.e., the actual first packet of the audio stream) in this transaction. In this case, if the earliest message in the server's buffer is a message carrying the sequence number seq_3, it can be directly determined that the server has lost the messages corresponding to seq_1~2, and then accurately send a second message (such as a NACK retransmission request) for that sequence number range to solve the problem of unrecoverable uplink first packet loss, which helps to ensure the integrity of the beginning of the voice.

[0109] In one or more embodiments provided in this application, the second device is a second terminal integrated with a mission-critical client, and the first device is a server for providing mission-critical services. In this case, the system may further include a first terminal integrated with a mission-critical client, i.e., a calling terminal.

[0110] Figure 3 This example illustrates the MCPTT (Multi-Client Pitch To Telephone) service communication signaling diagram between the server and the second terminal during the initial phase of a transaction. The second terminal can be one terminal or multiple terminals. Figure 3 Let's take a terminal as an example for illustration. (Combined with...) Figure 3 As shown, the MCPTT service communication process between the server and the second terminal may include:

[0111] S507. The server sends a talk right occupancy message to the second terminal, and the second terminal receives the talk right occupancy message accordingly.

[0112] Among them, the right-of-way occupancy message carries the identification information of the first media packet. The first media packet is the downlink media first packet of this voice emergency, that is, the right-of-way occupancy message carries the identification information of the downlink media first packet, which is referred to as the downlink first packet identifier.

[0113] It should be noted that if the first terminal is an improved terminal, meaning the voice right request message sent by the first terminal carries the identifier information of the uplink media first packet, then the server can directly use the identifier information of the uplink media first packet as the identifier information of the downlink media first packet and send it to the second terminal through the voice right occupancy message. In other words, the server can be configured to: in response to the voice right request message carrying the uplink first packet identifier, send a voice right occupancy message carrying the downlink first packet identifier (i.e., the aforementioned uplink first packet identifier) ​​to the called terminal of this voice interruption.

[0114] If the first terminal is an existing terminal, that is, the voice request message sent by the first terminal does not carry the identification information of the first uplink media packet, the server can configure the downlink first packet identifier based on the media packet with the smallest sequence number / earliest timestamp that the server will forward in this transaction (i.e. the first target media packet at the beginning of the transaction).

[0115] S508: The server forwards the media packets cached by the server to the second terminal, and the second terminal receives the media packets accordingly.

[0116] It should be noted that the current second terminal defaults to using the earliest message received at the start of broadcast as the first packet. If this message is not the actual downlink media first packet, the called terminal cannot perceive the loss of the downlink first packet and will not actively trigger the packet loss recovery mechanism, resulting in the loss of audio data at the beginning of the transaction and its irrecoverability. This application, by carrying a right-of-sale message with the downlink first packet identifier, allows the second terminal to clearly identify the sequence number of the first downlink media packet of this transaction (assuming it is seq_2). In this case, if the earliest message in the second terminal's buffer is a message carrying the sequence number seq_3, it can be directly determined that the second terminal has lost the message corresponding to seq_2, and then accurately send a second message (such as a NACK retransmission request) for that sequence number to solve the problem of downlink first packet loss and irrecoverability.

[0117] S509. The second terminal compares the downlink first packet identifier with the identifier information of the media packet cached by the second terminal, and determines whether the downlink media first packet is lost based on the comparison result.

[0118] If the comparison results indicate that the first packet of the downlink media is lost, then execute S510.

[0119] Optionally, if the comparison result determines that the second terminal has lost the first downlink media packet, the second terminal may wait for a third preset time before starting to play the media packet cached by the second terminal; if the comparison result determines that the first downlink media packet has not been lost, the second terminal may directly play the media packet cached by the second terminal.

[0120] In other words, if the first message is a talk right occupancy message, the first media packet is the downlink media first packet, and the second terminal can be configured to: if it is determined that the second terminal has lost the downlink media first packet, then after a third preset time after the second terminal has lost the downlink media first packet, start playing the media packet cached by the second terminal.

[0121] In one possible implementation, the third preset duration can be a fixed preset duration or a non-fixed duration. For example, the third preset duration can be positively correlated with the number of downlink packet losses at the beginning of the transaction. The number of downlink packet losses at the beginning of the transaction can be determined by comparing the identification information of the first downlink media packet with the identification information of the media packets cached by the second terminal.

[0122] Based on the above, by delaying the playback of voice messages while requesting retransmission from the server, the problem of lost initial sounds in the called terminal's audio is addressed to some extent. Furthermore, compared to a fixed-length third preset duration, a third preset duration that is positively correlated with the number of packet losses can further reduce the likelihood of lost initial sounds in the called terminal.

[0123] In another possible implementation, the second terminal can also be configured to start playing audio after determining that the downlink media first packet has been received based on the downlink first packet identifier.

[0124] S510, the second terminal sends a second message to the server to request the server to at least retransmit the first packet of the downlink media; correspondingly, the server receives the second message.

[0125] S511, the server retransmits the media packet to the second terminal, and the second terminal receives the retransmitted media packet from the server.

[0126] By using the media first packet identifier, the receiving server / called terminal can determine the media first packet of the current transaction, judge whether the first packet has been lost, and request the corresponding sending end to retransmit the first packet if it is determined to be lost. Based on this, even if the media data is directly discarded by the server / called terminal because it arrives before the right-of-way signaling, or if the media first packet is lost due to network reasons, the receiving end can accurately identify the first packet loss based on an effective reference benchmark and trigger the corresponding packet loss compensation strategy to alleviate the MCPTT service quality problems caused by the loss of the audio stream first packet.

[0127] Figure 4 This example illustrates the MCPTT (Multi-Client Pitch To Telephone) service communication signaling diagram between the first terminal and the server during the transaction completion phase. Figure 4 In the scenario shown, the first message is the talk time release message, and the first media packet is the uplink media tail packet, that is, the last media packet sent by the first terminal in this transaction before sending the talk time release message. Combined with... Figure 4 As shown, the MCPTT service communication process between the first terminal and the server may include:

[0128] S601, the first terminal sends a talk right release message, and the corresponding server receives the talk right release message from the first terminal.

[0129] The right-of-sale release message carries the identification information of the first media packet. At this time, the first media packet is the uplink media tail packet of this sudden voice event. The identification information of the uplink media tail packet carried by the right-of-sale release message can be simply referred to as the uplink tail packet identifier.

[0130] S602. The server compares the uplink tail packet identifier with the identifier information of the media packet cached by the server, and determines whether the uplink media tail packet is lost based on the comparison result.

[0131] If the comparison result determines that the server has lost the uplink media tail packet, then S603 is executed. Optionally, if the comparison result determines that the server has lost the uplink media tail packet, the server may wait for a second preset time period before sending a talk time idle message to the second terminal; if the comparison result determines that the uplink media tail packet has not been lost, the server may directly send a talk time idle message to the second terminal.

[0132] In other words, the server can be configured to send a talk time idle message to the second terminal after a second preset time period following the determination of uplink media tail packet loss, if it is determined that the uplink media tail packet has been lost. The sent talk time idle message may carry a downlink tail packet identifier (such as the aforementioned uplink tail packet identifier, or an identifier based on the first target media packet configured by the server during the transaction end phase), or it may not carry a downlink tail packet identifier; this embodiment does not impose any limitations on this.

[0133] Optionally, the aforementioned second preset duration can be a fixed duration or a non-fixed duration. For example, the second preset duration can be positively correlated with the number of uplink packet losses during the transaction end phase. The number of uplink packet losses during the transaction end phase can be determined by comparing the identification information of the uplink media tail packet carried in the talk release message with the identification information of the media packets cached by the server. For example, the second preset duration can be expressed as: (Sequence number of the uplink media tail packet - Sequence number of the first target media packet during the transaction end phase) × unit duration, where the unit duration can be 20ms.

[0134] Based on the above, by delaying the transmission of the talk right idle message when the uplink media tail packet is lost, the possibility of the talk right signaling arriving before the media tail packet can be reduced, thereby reducing the possibility of the called terminal losing the tail packet and requesting retransmission, thus saving unnecessary overhead.

[0135] In another possible implementation, the server may send a talk-right-free message after completing the tail packet retransmission and receiving the missing media tail packet, in order to inform the called terminal that the talk right has been released.

[0136] In addition, in one possible implementation, the server can be configured to send downlink media tail packet identification information (i.e., the aforementioned uplink tail packet identification) to the called terminal of this transaction in response to a talk right release message carrying an uplink tail packet identifier. This information may include talk right signaling (i.e., talk right idle message) sent by the server to the called terminal.

[0137] S603, the server sends a second message to the first terminal to request the first terminal to at least retransmit the uplink media tail packet; correspondingly, the first terminal receives the second message.

[0138] S604. The first terminal retransmits the media packet to the server, and the corresponding server receives the media packet retransmitted by the first terminal.

[0139] It should be noted that during the server's comparison and request for retransmission from the first terminal, the server continues to forward incomplete media packets to the second terminal. The server can wait a preset time after sending the downlink media tail packet before clearing the media packets from the first terminal from its buffer.

[0140] Figure 5This example illustrates the MCPTT (Multi-Client Pitch To Telephone) service communication signaling diagram between the server and the second terminal during the transaction completion phase. Figure 5 In the scenario shown, the first message is a talk time idle message, and the identification information of the first media packet it carries is the identification information of the downlink media tail packet, which can be simply referred to as the downlink tail packet identifier. Combined with... Figure 5 As shown, the MCPTT service communication process between the server and the second terminal may include:

[0141] S605. The server sends a talk time idle message to the second terminal, and the second terminal receives the talk time idle message accordingly.

[0142] The talk time idle message carries a downlink tail packet identifier, which indicates the last media packet actually sent by the server in this transaction.

[0143] In one possible implementation, the talk time idle message can be a message sent by the server in response to a talk time release message carrying an uplink tail packet identifier. In this case, the downlink tail packet identifier carried in the talk time idle message can be the same as the uplink tail packet identifier carried in the talk time release message. Alternatively, the talk time idle message can be a message sent by the server a second preset time after determining that an uplink media tail packet has been lost.

[0144] Even if the message releasing the right of speech does not carry identification information, the server can still configure the downlink tail packet identifier based on the media packet with the largest sequence number / latest timestamp in its own buffer.

[0145] S606. The second terminal compares the downlink tail packet identifier with the identifier information of the media packet cached by the second terminal, and determines whether the downlink media tail packet is lost based on the comparison result.

[0146] If the comparison results indicate that the downstream media tail packet is missing, then execute S607.

[0147] S607, the second terminal sends a second message to the server to request the server to at least retransmit the downlink media tail packet; correspondingly, the server receives the second message.

[0148] S608, the server retransmits the media packet to the second terminal, and the second terminal receives the retransmitted media packet from the server.

[0149] It should be noted that the NACK retransmission mechanism currently configured in the terminal is only triggered when packet loss is explicitly detected. This means that even if a large segment of packets is lost at the end of the call, the terminal cannot recognize the abnormal continuity of the audio data packets and will not actively request retransmission, ultimately resulting in the loss of audio data at the end of the call. Based on the talk right idle message carrying the downlink tail packet identifier in this application, the called terminal can clearly identify the sequence number of the last media packet in this transaction and compare it with the media packets in the current buffer. If the audio data corresponding to the tail packet is not received within the timeout period, it is determined that the downlink tail packet is lost, and a request is made to the server to retransmit it, thus resolving the problem of audio data loss at the end of the call. Furthermore, the second terminal can also request the server to perform targeted retransmissions, such as sending a second message carrying the sequence number of the missing packet (e.g., a NACK retransmission request) to the server.

[0150] By using the media tail packet identifier, the receiving server / called terminal can determine the uplink / downlink media tail packets of the current transaction, judge whether uplink / downlink tail packet loss has occurred, and request the corresponding sending end to retransmit when tail packet loss is confirmed. Based on this, even if the media data is discarded by the server / called terminal because it arrives later than the right-of-way signaling, or if the media tail packet is lost due to network reasons, the receiving end can accurately identify the tail packet loss based on an effective reference benchmark and trigger the corresponding packet loss compensation strategy, thereby solving the MCPTT service quality problem caused by audio stream tail packet loss.

[0151] To balance the requirements of smooth playback and efficient use of talk time, in one or more embodiments provided in this application, when the first message is a talk time idle message, the first media packet is a downlink media tail packet, and the second terminal can be configured as follows:

[0152] If it is determined that the second terminal has lost the downlink media tail packet, a slow playback mechanism is activated to reduce the audio playback speed; and / or,

[0153] If it is determined that the second terminal has not lost the downlink media tail packet, the fast playback mechanism is enabled to improve the voice playback speed.

[0154] In other words, the process of the second terminal playing audio based on cached media packages can include:

[0155] When it is determined that the downstream media tail packet is lost, the cached media packet is played in slow speed.

[0156] This embodiment slows down audio playback when the downlink media tail packet is lost, allowing sufficient time for media packet retransmission and avoiding audio playback stuttering caused by the late arrival of the tail packet, thereby improving the user experience.

[0157] Optionally, the process of the second terminal playing audio based on the cached media package may also include:

[0158] When the conditions for fast playback are met, the cached media package is played quickly.

[0159] The conditions for fast playback may include: confirming that the downlink media tail packet has not been lost. This embodiment, by fast-playing the remaining audio when the tail packet is not lost, can end the current call quickly and avoid affecting subsequent calls.

[0160] In another possible implementation, the fast-play condition may include: the number of unplayed media packets is greater than a preset threshold, for example, the threshold could be 10. Here, the number of unplayed media packets is equal to the difference between the sequence number of the downlink media tail packet in the downlink tail packet identifier and the sequence number of the second target media packet. The aforementioned second target media packet is the media packet with the smallest sequence number in the second terminal's buffer at the end of the transaction, i.e., the media packet that the second terminal is currently playing or is about to play. This situation indicates that the current buffer is too large, and fast-play can be performed to achieve precise control of voice playback duration, reduce invalid usage, and improve the efficiency of channel and voice rights resources.

[0161] It should be noted that the aforementioned fast playback and slow playback mechanisms can be implemented using the NetEQ network equalizer configured within the second terminal. If the second terminal does not have a NetEQ network equalizer configured, the same can be achieved by directly adjusting the audio playback speed.

[0162] It should be noted that when the terminal is configured with a NetEQ network equalizer, since there is no dedicated signaling to inform the called terminal that the stream has ended, the called terminal will continuously request data packets from NetEQ even if it has not received RTP packets. Because NetEQ cannot recognize that the audio stream has terminated, it misjudges the current lack of media packets as network jitter, thus triggering a packet loss compensation mechanism. This includes copying and smoothing the previous valid data packet before outputting it for playback, resulting in a prolonged trailing tone during the talk time release phase. To solve this problem, in one or more embodiments provided in this application, when the second terminal is configured with a NetEQ network equalizer, the second terminal is configured to play a mute packet after playing the media packet corresponding to the boundary packet identifier.

[0163] The mute packet is a mute audio packet pushed by NetEQ after the downlink media tail packet is pushed.

[0164] Based on the above, using the talk right idle message carrying the downlink tail packet identifier described in this application, the NetEQ built into the called terminal can clearly identify the sequence number of the last media packet of this transaction. Based on this, if a data packet request is received after NetEQ has output the last data packet, a mute packet can be directly pushed without performing packet loss compensation, so as to solve the problem of tail tone prolongation and noise caused by NetEQ miscompensation during the talk right release stage.

[0165] This application also provides an MCPTT service communication system, which may include: a first device and a second device; wherein the first device is a transmitter of voice right signaling and media packets, and the second device is a receiver of voice right signaling and media packets. Specifically:

[0166] The first device sends a first message, which is a voice access signaling sent to the second device. The first message carries the identification information of a first media packet. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets transmitted by the first device in this voice burst event.

[0167] In response to the first message, the second device compares the identification information of the first media packet with the identification information of the media packet cached by the second device; if it is determined from the comparison result that the second device has lost the first media packet, then the second device sends a second message to the first device; the second message is used to request the first device to at least retransmit the first media packet.

[0168] The first device retransmits the media packet to the second device based on the second message, and the media packet retransmitted by the first device includes at least the first media packet.

[0169] Optionally, further descriptions of the first and second devices can be found above and will not be repeated here.

[0170] This application embodiment also provides another MCPTT service communication system, including: a first terminal, a server and a second terminal, wherein the first terminal, the server and the second terminal perform the above steps S501~S511 to implement the service communication scheme provided in this application, and / or, the first terminal, the server and the second terminal perform the above steps S601~S608 to implement the service communication scheme provided in this application.

[0171] Optionally, further descriptions of the first terminal, server, and second terminal can be found above and will not be repeated here.

[0172] The equipment provided in this application will now be described.

[0173] This application provides an electronic device, optionally, Figure 6 A hardware block diagram of the electronic device is shown, with reference to... Figure 6 The electronic device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0174] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0175] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0176] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0177] The memory 3 is used to store computer programs, and the processor 1 is used to execute the computer programs so that the electronic device can implement any of the above-mentioned MCPTT service communication methods.

[0178] It needs to be explained that, Figure 6 The device structure shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0179] Optionally, the aforementioned electronic device may be a server for providing mission-critical services. For example, the server may specifically be a mission-critical server or other electronic devices for providing mission-critical services. The server may include at least one processor and a memory connected to the processor, wherein: the memory stores a computer program; and the processor executes the computer program to enable the terminal to implement any of the aforementioned MCPTT service communication methods applied to the server.

[0180] Optionally, the aforementioned electronic device can also be a terminal, specifically referring to an electronic device integrating an MCC. The terminal may include at least one processor and a memory connected to the processor, wherein: the memory is used to store a computer program; the processor is used to execute the computer program to enable the terminal to implement the aforementioned MCPTT service communication method applied to the first terminal, or to implement the aforementioned MCPTT service communication method applied to the second terminal.

[0181] This application also provides a storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the MCPTT service communication methods provided in this application.

[0182] This application also provides a computer program product, including computer-readable instructions, which, when executed on an electronic device, enable the electronic device to implement any of the MCPTT service communication methods provided in this application.

[0183] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0184] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0185] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for communication in MCPTT services, characterized in that, A second device applied in an MCPTT service communication system, the method comprising: Receive a first message, which is a voice right signaling sent from the first device to the second device in the MCPTT service communication system. The first message carries the identification information of a first media packet. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets to be transmitted by the first device in this voice burst transaction. The identification information of the first media package and the identification information of the media package cached by the second device are compared and processed. If the comparison result determines that the second device has lost the first media packet, then a second message is sent to the first device, the second message being used to request the first device to retransmit the first media packet; Receive the media packets retransmitted by the first device.

2. The MCPTT service communication method according to claim 1, characterized in that, The second message carries second identification information, which is used to indicate media packets that the second device did not receive in this voice burst transaction, or media packets that the second device has received in this voice burst transaction, so that the first device can determine the media packets to be retransmitted.

3. The MCPTT service communication method according to claim 1 or 2, characterized in that, The identification information includes a timestamp and a serial number.

4. The MCPTT service communication method according to claim 3, characterized in that, The comparison process includes: If the first message is a signaling message indicating the start of a transaction, the media packet with the smallest sequence number and the smallest timestamp is determined from the media packets cached by the second device and used as the first target media packet; or, if the first message is a signaling message indicating the end of a transaction, the media packet with the largest sequence number and the largest timestamp is determined from the media packets cached by the second device and used as the first target media packet. Compare the serial number and timestamp of the first media package with those of the first target media package.

5. The MCPTT service communication method according to claim 1 or 2, characterized in that, When the identification information includes a timestamp, sequence number, and synchronization source identifier SSRC, the comparison process includes: If the first message is a signaling message indicating the start of a transaction, the media packet with the smallest sequence number and the smallest timestamp is determined from the media packets carrying a specified SSRC cached by the second device and used as the first target media packet; or, if the first message is a signaling message indicating the end of a transaction, the media packet with the largest sequence number and the largest timestamp is determined from the media packets carrying a specified SSRC cached by the second device and used as the first target media packet; wherein, the specified SSRC is the SSRC of the first media packet; Compare the serial number and timestamp of the first media package with those of the first target media package.

6. The MCPTT service communication method according to claim 1 or 2, characterized in that, The second device is a server for providing mission-critical services, and the first device is a first terminal integrated with a mission-critical client.

7. The MCPTT service communication method according to claim 6, characterized in that, In the case that the first message is a voice rights request message, the first media packet is the first uplink media packet, and the server is configured as follows: If it is determined that the server has lost the first uplink media packet, then after a first preset time period following the determination that the server has lost the first uplink media packet, the server will begin forwarding the media packets cached by the server to the third device for voice playback. The third device is the called terminal in this sudden voice event.

8. The MCPTT service communication method according to claim 7, characterized in that, The first preset duration is positively correlated with the number of uplink packet losses at the beginning of the transaction. The number of uplink packet losses at the beginning of the transaction is determined by comparing the identification information of the first uplink media packet with the identification information of the media packets cached by the server.

9. The MCPTT service communication method according to claim 6, characterized in that, In the case that the first message is a talk time release message, the first media packet is an uplink media tail packet, and the server is configured as follows: If it is determined that the server has lost the uplink media tail packet, then after a second preset time period following the determination that the server has lost the uplink media tail packet, a talk time idle message is sent to a third device, which is the called terminal of this voice burst transaction.

10. The MCPTT service communication method according to claim 9, characterized in that, The second preset duration is positively correlated with the number of uplink packet losses during the transaction end phase. The number of uplink packet losses during the transaction end phase is determined by comparing the identification information of the uplink media tail packet with the identification information of the media packet cached by the server.

11. The MCPTT service communication method according to claim 6, characterized in that, The server is configured to: in response to the first message, send the identification information of the first media packet to the third device, wherein the identification information of the first media packet sent by the server to the third device includes the voice access signaling sent by the server to the third device in this voice burst transaction; the third device is the called terminal in this voice burst transaction.

12. The MCPTT service communication method according to claim 1 or 2, characterized in that, The second device is a second terminal that integrates a mission-critical client, and the first device is a server for providing mission-critical services.

13. The MCPTT service communication method according to claim 12, characterized in that, In the case that the first message is a talk time occupancy message, the first media packet is the first downlink media packet, and the second terminal is configured as follows: If it is determined that the second terminal has lost the first downlink media packet, then after a third preset time period following the determination that the second terminal has lost the first downlink media packet, the media packet cached by the second terminal will begin to play.

14. The MCPTT service communication method according to claim 13, characterized in that, The third preset duration is positively correlated with the number of downlink packet losses at the beginning of the transaction. The number of downlink packet losses at the beginning of the transaction is determined by comparing the identification information of the first downlink media packet with the identification information of the media packets cached by the second terminal.

15. The MCPTT service communication method according to claim 12, characterized in that, When the first message is a talk time idle message, the first media packet is a downlink media tail packet, and the second terminal is configured as follows: If it is determined that the second terminal has lost the downlink media tail packet, a slow playback mechanism is activated to reduce the audio playback speed; And / or, If it is determined that the second terminal has not lost the downlink media tail packet, a fast playback mechanism is enabled to improve the audio playback speed.

16. The MCPTT service communication method according to claim 12, characterized in that, When the second terminal is equipped with a NetEQ network equalizer, the second terminal is configured as follows: After the downlink media tail packet is played, a mute packet is played; the mute packet is the mute audio packet pushed by NetEQ after the downlink media tail packet is pushed.

17. A method for communication in MCPTT services, characterized in that, A first device applied in an MCPTT service communication system, the method comprising: Send a first message, which is a voice access signaling sent by the first device to the second device in the MCPTT service communication system. The first message carries the identification information of the first media packet, which is used by the second device to determine whether the first media packet has been lost. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets transmitted by the first device in this voice burst transaction. Receive a second message, which is a message sent by the second device when it determines that the first media packet is lost. The second message is used to request the first device to at least retransmit the first media packet. The media packet is retransmitted to the second device, and the media packet retransmitted by the first device includes at least the first media packet.

18. The MCPTT service communication method according to claim 17, characterized in that, If the second message carries the second identification information, retransmit the media packet to the second device, including: Based on the second identification information in the second message, the media package lost by the second device is determined; Send the media packets lost by the second device to the second device; The second identification information is used to indicate media packets that the second device did not receive during the current voice burst transaction, or media packets that the second device received during the current voice burst transaction.

19. The MCPTT service communication method according to claim 17 or 18, characterized in that, The first device is a first terminal that integrates a mission-critical client, and the second device is a server for providing mission-critical services.

20. The MCPTT service communication method according to claim 17 or 18, characterized in that, The first device is a server for providing mission-critical services, and the second device is a second terminal integrated with an MCPTT client.

21. The MCPTT service communication method according to claim 20, characterized in that, When the first message is a talk time idle message, the process of the server sending the talk time idle message includes: In response to the caller terminal sending a voice right release message in response to this sudden voice event, if it is determined that the first device has lost the uplink media tail packet based on the identification information of the uplink media tail packet carried in the voice right release message, the voice right idle message is sent after waiting for a second preset time.

22. The MCPTT service communication method according to claim 21, characterized in that, The second preset duration is positively correlated with the number of uplink packet losses during the transaction end phase. The number of uplink packet losses during the transaction end phase is determined by comparing the identification information of the uplink media tail packet with the identification information of the media packet cached by the server.

23. An electronic device, characterized in that, include: At least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to enable the electronic device to implement the MCPTT service communication method as described in any one of claims 1 to 16, or to implement the MCPTT service communication method as described in any one of claims 17 to 22.

24. An MCPTT service communication system, characterized in that, Including the first device and the second device; The first device sends a first message, which is a voice access signaling sent to the second device. The first message carries the identification information of a first media packet. The first media packet is the media packet whose transmission time is closest to the transmission time of the first message among the media packets transmitted by the first device in this voice burst event. In response to the first message, the second device compares the identification information of the first media package with the identification information of the media package cached by the second device. If the comparison results determine that the second device has lost the first media package, then a second message is sent to the first device; The second message is used to request the first device to at least retransmit the first media packet; The first device retransmits the media packet to the second device based on the second message, and the media packet retransmitted by the first device includes at least the first media packet.

25. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, enable the electronic device to implement the MCPTT service communication method as described in any one of claims 1 to 16, or to implement the MCPTT service communication method as described in any one of claims 17 to 22.

Images