Voice call processing method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application provide a voice call processing method and device, electronic equipment and storage medium. The voice call processing method comprises: a first terminal receives a call request initiated by a third terminal in the process of a first call with a second terminal; in response to the call request, initiating a key negotiation with the third terminal, determining the call type of the call request based on the key negotiation result, and obtaining the call type of the first call; based on the call type and the call type, the first call is controlled to enter a call hold state, and a second call is established with the third terminal. In the embodiments of the present application, after receiving the call request initiated by the third terminal, no matter what the call type of the first call is, the first terminal can control the first call to enter the call hold state and establish the second call with the third terminal, so it is not limited to the call type of the first call to realize the access of the third terminal, and the applicability is stronger, which can improve the user experience.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and in particular to a voice call processing method and device, electronic equipment and storage medium. BACKGROUND

[0002] VoLTE (Voice over Long Term Evolution) is a voice service based on IMS (IP Multimedia Subsystem), which is an IP data transmission technology. VoLTE does not require 2G / 3G network, and the service is carried on the 4G network, which can realize shorter call waiting time, and higher quality and more natural voice and video call effect.

[0003] The IMS itself provides a complex and relatively secure authentication and authorization mechanism, but as malicious listening becomes more and more common, VoLTE needs special encryption mechanism to ensure the security of the call.

[0004] In the prior art, when two terminals are in a call, if another terminal makes a voice call to one of the terminals in the call, the voice call of the other terminal will be rejected when the ongoing call is an encrypted call, resulting in a large limitation of voice call. SUMMARY

[0005] In view of the above problems, the embodiments of the present application provide a voice call processing method and device, electronic equipment and storage medium, to solve the above problems.

[0006] According to an aspect of an embodiment of the present application, a voice call processing method is provided, the method being applied to a first terminal, and the method comprises:

[0007] In the process that the first terminal and a second terminal are in a first call, receiving a call request initiated by a third terminal;

[0008] In response to the call request, initiating a key negotiation with the third terminal, determining a call type of the call request based on a key negotiation result, and obtaining a call type of the first call;

[0009] Based on the call type and the call type, controlling the first call to enter a call hold state, and establishing a second call with the third terminal.

[0010] Optionally, the determining the call type of the call request based on the key agreement result comprises: determining the call type of the call request as an encrypted call when the key agreement result indicates that the key agreement is successful; and determining the call type of the call request as a plaintext call when the key agreement result indicates that the key agreement fails and the failure reason is that no key is needed.

[0011] Optionally, the controlling the first call to enter a call hold state and establishing a second call with the third terminal based on the call type and the call type comprises: saving a first key corresponding to the first call, controlling the first call to enter a call hold state, obtaining a second key based on the key agreement result, and establishing a second call with the third terminal, when the call type is an encrypted call and the call type is an encrypted call, the second key being used as a key corresponding to the second call; and / or saving a first key corresponding to the first call, and establishing a second call with the third terminal when the call type is a plaintext call and the call type is an encrypted call; and / or controlling the first call to enter a call hold state, obtaining a second key based on the key agreement result, and establishing a second call with the third terminal when the call type is an encrypted call and the call type is a plaintext call, the second key being used as a key corresponding to the second call; and / or controlling the first call to enter a call hold state and establishing a second call with the third terminal when the call type is a plaintext call and the call type is a plaintext call.

[0012] Optionally, the controlling the first call to enter a call hold state comprises: initiating a first instruction to the second terminal, the first instruction being used to instruct the second terminal to enter a send-only state, and completing the call hold state of the first call.

[0013] Optionally, the method further comprises: based on the call type and the call type, controlling the first call to enter a call hold recovery state after the second call ends.

[0014] Optionally, controlling the first call to enter a call hold recovery state based on the call type and the call type includes: when the call type is an encrypted call and the call type is an encrypted call, restoring the first key corresponding to the first call, controlling the first call to enter a call hold recovery state, and releasing the second key corresponding to the second call; and / or, when the call type is a plaintext call and the call type is an encrypted call, restoring the first key corresponding to the first call and controlling the first call to enter a call hold recovery state; and / or, when the call type is an encrypted call and the call type is a plaintext call, controlling the first call to enter a call hold recovery state and releasing the second key corresponding to the second call; and / or, when the call type is a plaintext call and the call type is a plaintext call, controlling the first call to enter a call hold recovery state.

[0015] Optionally, controlling the first call to enter the call hold recovery state includes: sending a second instruction to the second terminal, the second instruction being used to instruct the second terminal to enter the transmit / receive state, thereby completing the call hold recovery state of the first call.

[0016] According to another aspect of the embodiments of this application, a voice call processing apparatus is provided, the apparatus being applied to a first terminal, the apparatus comprising:

[0017] The receiving module is used to receive a call request initiated by a third terminal during the first call between the first terminal and the second terminal.

[0018] The acquisition module is used to respond to the call request, initiate key negotiation with the third terminal, determine the call type of the call request based on the key negotiation result, and acquire the call type of the first call;

[0019] The first control module is used to control the first call to enter a call hold state based on the call type and the call type, and to establish a second call with the third terminal.

[0020] Optionally, the acquisition module includes: a first determining submodule, configured to determine that the call type of the call request is an encrypted call after the key negotiation result indicates that the key negotiation was successful; and a second determining submodule, configured to determine that the call type of the call request is a plaintext call when the key negotiation result indicates that the key negotiation failed and the reason for the failure is that no key is required.

[0021] Optionally, the first control module includes: a first control submodule, configured to, when the call type is an encrypted call and the call type is an encrypted call, save a first key corresponding to the first call, control the first call to enter a call hold state, obtain a second key based on the key negotiation result, establish a second call with the third terminal with a call type of encrypted call, and use the second key as the key corresponding to the second call; and / or, a second control submodule, configured to, when the call type is a plaintext call and the call type is an encrypted call, save a first key corresponding to the first call, control the first call to enter a call hold state, and establish a second call with the third terminal with a call type of plaintext call; and / or, a third control submodule, configured to, when the call type is an encrypted call and the call type is a plaintext call, control the first call to enter a call hold state, obtain a second key based on the key negotiation result, establish a second call with the third terminal with a call type of encrypted call, and use the second key as the key corresponding to the second call; and / or, a fourth control submodule, configured to, when the call type is a plaintext call and the call type is a plaintext call, control the first call to enter a call hold state, and establish a second call with the third terminal with a call type of plaintext call.

[0022] Optionally, the first control module is specifically used to send a first instruction to the second terminal, the first instruction being used to instruct the second terminal to enter a send-only state and complete the call hold state of the first call.

[0023] Optionally, the device further includes: a second control module, configured to control the first call to enter a call hold recovery state based on the call type and the call type after the second call ends.

[0024] Optionally, the second control module includes: a fifth control submodule, configured to, when the call type is an encrypted call and the call type is an encrypted call, restore the first key corresponding to the first call, control the first call to enter a call hold-up recovery state, and release the second key corresponding to the second call; and / or, a sixth control submodule, configured to, when the call type is a plaintext call and the call type is an encrypted call, restore the first key corresponding to the first call and control the first call to enter a call hold-up recovery state; and / or, a seventh control submodule, configured to, when the call type is an encrypted call and the call type is a plaintext call, control the first call to enter a call hold-up recovery state and release the second key corresponding to the second call; and / or, an eighth control submodule, configured to, when the call type is a plaintext call and the call type is a plaintext call, control the first call to enter a call hold-up recovery state.

[0025] Optionally, the second control module is specifically used to send a second instruction to the second terminal, the second instruction being used to instruct the second terminal to enter the transmit / receive state and complete the call hold recovery state of the first call.

[0026] According to another aspect of the embodiments of this application, an electronic device is provided, comprising: one or more processors; and one or more computer-readable storage media having instructions stored thereon; wherein, when the instructions are executed by the one or more processors, the processors cause the processors to perform the voice call processing method as described in any of the preceding claims.

[0027] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to perform the voice call processing method as described in any of the preceding claims.

[0028] In this embodiment, while a first terminal is engaged in a first call with a second terminal, it receives a call request initiated by a third terminal. In response to the call request, the first terminal initiates key negotiation with the third terminal, determines the call type of the call request based on the key negotiation result, and obtains the call type of the first call. Based on the call type and the call type, the first terminal controls the first call to enter a call hold state and establishes a second call with the third terminal. Therefore, in this embodiment, after receiving a call request from a third terminal, the first terminal can control the first call to enter a call hold state and establish a second call with the third terminal regardless of the call type of the first call. Thus, it is not limited to the call type of the first call to enable access to the third terminal, making it more applicable and improving user experience. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some drawings of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a flowchart illustrating the steps of a voice call processing method according to an embodiment of this application.

[0031] Figure 2 This is a flowchart illustrating the steps of another voice call processing method according to an embodiment of this application.

[0032] Figure 3 This is a schematic diagram of a transceiver device according to an embodiment of this application.

[0033] Figure 4 This is a schematic diagram of a voice call processing flow according to an embodiment of this application.

[0034] Figure 5 This is a schematic diagram of another voice call processing flow according to an embodiment of this application.

[0035] Figure 6 This is a schematic diagram of another voice call processing flow according to an embodiment of this application.

[0036] Figure 7 This is a schematic diagram of another voice call processing flow according to an embodiment of this application.

[0037] Figure 8 This is a structural block diagram of a voice call processing device according to an embodiment of this application.

[0038] Figure 9 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0039] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0040] The following is a detailed explanation of some of the contents involved in the embodiments of this application:

[0041] 1. VoLTE encrypted phone

[0042] To enhance the security of user voice calls and prevent attackers from eavesdropping on conversations between callers and recipients, VoLTE encrypted phones have been developed based on 4G network VoLTE technology. VoLTE encrypted phones, building upon standard VoLTE phones, employ cryptographic techniques to encrypt and protect voice content. Even if unauthorized personnel intercept the encrypted voice information from both parties, they will be unable to understand the true content of the call.

[0043] VoLTE encrypted calling is a packet-segment encrypted call implemented using an end-to-end, in-band key negotiation mechanism, based on standard VoLTE calling. After a user dials an encrypted call, the terminal and network first establish a connection at the signaling layer according to the standard VoLTE call procedure. After the called user answers the call, the calling and called VoLTE encrypted terminals negotiate a session key for this call between the two ends using the media plane voice channel, which is used to encrypt the user's voice information. After successful key negotiation, the user can begin the encrypted call.

[0044] VoLTE encrypted calls use the same phone numbers as regular phones (i.e., unencrypted standard phones), and the call signaling processing is exactly the same as for standard VoLTE calls. The network does not differentiate between them; therefore, VoLTE encrypted calls do not support independent supplementary services. Their supplementary services are dependent on those of standard VoLTE calls. For VoLTE encrypted calls, the activation / deactivation status of various supplementary services is exactly the same as for standard VoLTE calls; users cannot individually activate / deactivate a supplementary service for an encrypted call. For example, if a user has activated call waiting for a standard VoLTE call, the network will handle it in the same way for the encrypted call, meaning that a new call notification will be received while the user is in an encrypted call.

[0045] Users can make encrypted calls using a customized VoLTE encrypted terminal. Encrypted calls can be made between two VoLTE encrypted terminals. However, only ordinary calls can be made between a VoLTE encrypted terminal and a regular terminal (which does not support VoLTE encrypted calls, such as 2G / 3G / 4G terminals, standard VoLTE terminals, and landlines). Encrypted calls cannot be made between them.

[0046] 2. Supplementary services

[0047] Supplementary services are services that modify or supplement basic telecommunications services. They are services that are provided to users specifically to meet special application scenarios and are attached to basic call services. They cannot be provided to users independently of basic call services.

[0048] Call waiting and call hold are two commonly used supplementary VoLTE phone services. Call waiting means that when a user receives a new call request while in an existing call, the user will hear a call waiting tone, indicating that another user is waiting to speak with them. Simultaneously, the new caller is notified to wait and a call waiting tone is played to them. Call hold means that users can maintain communication on an existing call and subsequently resume established communication. A call hold tone is played to the user whose call is being held during the call hold period.

[0049] By enabling the "call waiting" and "call hold" services, users can answer another call while keeping the current call going, and resume the previously held call after it ends, greatly facilitating the use of their phones.

[0050] 3. Standard call waiting process

[0051] User UE-B and user UE-C are in a call, and user UE-B has subscribed to call waiting service;

[0052] Calling user UE-A calls called user UE-B;

[0053] When the called user UE-B receives a call from the calling user UE-A, its terminal plays a call waiting tone (usually a "beep beep" tone) to UE-B and returns a 180 message to the core network, indicating that the calling user UE-A is in a call waiting state.

[0054] After receiving the 180 message, the called party VoLTE AS determines whether the called user UE-B has activated the call waiting service. If not, the 180 message is transmitted. If the called user UE-B has activated the call waiting service, the VoLTE AS (MRF) plays a call waiting prompt tone to the calling user UE-A.

[0055] After hearing the call waiting tone, calling user UE-A decides not to hang up temporarily. At this time, called user UE-B can answer the call from calling user UE-A. First, UE-B's terminal will send a re-INVITE (SendOnly) message to user UE-C to keep the call on hold. Then, it will reply to calling user UE-A with a 200 OK to connect the call. It will request the called side VoLTE AS to update the media information received by calling user UE-A from user UE-B according to the offer / answer model in RFC3264. After the media handover is completed, users UE-A and UE-B will enter the call, and user UE-C will be in a held state.

[0056] In this embodiment, during a VoLTE encrypted call, if another terminal sends an INVITE call request to establish a new call, the VoLTE encrypted terminal does not need to include the call type in the call request. It can immediately initiate a key negotiation process. If the key negotiation result indicates an encrypted call, the VoLTE encrypted terminal processes it according to the normal encrypted call procedure, supports call waiting, and allows the terminal to accept new calls, using the newly negotiated key as the encryption key. If the negotiation result indicates a plaintext call, the VoLTE encrypted terminal should process the new call request normally, supporting call waiting. Therefore, VoLTE encrypted calls do not affect the use of standard VoLTE call waiting services, improving the user's service application experience. Furthermore, it does not require modification of the IMS network, achieving decoupling between the encrypted call function and the IMS network.

[0057] The voice call processing method of this application will be described in detail below through the following embodiments.

[0058] Reference Figure 1 The diagram shows a flowchart of the steps of a voice call processing method according to an embodiment of this application.

[0059] likeFigure 1 As shown, the voice call processing method may include the following steps:

[0060] Step 101: During the first call between the first terminal and the second terminal, the first terminal receives a call request initiated by the third terminal.

[0061] The call request initiated by the third terminal can carry the phone number of the third terminal, the phone number of the first terminal, etc. In this embodiment, the call request initiated by the third terminal does not need to carry the call type, thus eliminating the need to modify the IMS network and achieving decoupling between the encrypted call function and the IMS network.

[0062] Step 102: In response to the call request, the first terminal initiates a key negotiation with the third terminal, determines the call type of the call request based on the key negotiation result, and obtains the call type of the first call.

[0063] When a third terminal initiates a call request to a first terminal, it can also send a verification request to the cloud-based secure call service management platform to obtain the call identifier returned by the platform. If the third terminal initiates an encrypted call, the call identifier will be the secure call identifier.

[0064] In response to a call request initiated by a third terminal, the first terminal initiates a key negotiation with the third terminal through the cloud-based secure call service management platform, and may carry the phone numbers of both the first terminal and the third terminal.

[0065] The cloud-based secure call service management platform obtains the call identifier of the third terminal based on its phone number. If the call identifier indicates an encrypted call, it generates a key negotiation result indicating successful key negotiation, which may include the second key assigned to both the first and third terminals. If the call identifier indicates an encrypted call, it generates a key negotiation result indicating failed key negotiation, which may include the reason for failure: no key required. The cloud-based secure call service management platform then returns the key negotiation result to the first terminal.

[0066] The first terminal determines the call type of the call request based on the key negotiation result. For example, if the key negotiation result indicates that the key negotiation was successful, the call type of the call request is determined to be an encrypted call; if the key negotiation result indicates that the key negotiation failed and the reason for the failure is that no key is required, the call type of the call request is determined to be a plaintext call.

[0067] The first terminal can also obtain the call type of the currently ongoing second call, which can be obtained and stored when the second call is established.

[0068] Step 103: Based on the call type and the call type, the first terminal controls the first call to enter a call hold state and establishes a second call with the third terminal.

[0069] When the call type is an encrypted call and the conversation type is an encrypted conversation, the first terminal saves the first key corresponding to the first conversation and controls the first conversation to enter a call hold state. For example, the first terminal sends a first instruction to the second terminal, which instructs the second terminal to enter a send-only state, thus completing the call hold state for the first conversation. The first instruction can be a re-INVITE (SendOnly) instruction.

[0070] When the call type is encrypted and the call type is encrypted, the first terminal also establishes a second call with the third terminal, with the call type being encrypted, and uses the second key carried in the key negotiation result as the key corresponding to the second call. For example, the first terminal places the second key in the cryptographic operation area, and the first terminal and the third terminal conduct an encrypted call (i.e., the second call) based on this second key.

[0071] When the call type is a plaintext call and the call type is an encrypted call, the first terminal saves the first key corresponding to the first call and controls the first call to enter a call hold state. For example, the first terminal sends a first instruction to the second terminal, which instructs the second terminal to enter a send-only state, thus completing the call hold state for the first call. The first instruction can be a re-INVITE (SendOnly) instruction.

[0072] When the call type is a plaintext call and the call type is an encrypted call, the first terminal also establishes a second call with the third terminal, with the call type being a plaintext call.

[0073] When the call type is encrypted and the call type is plaintext, the first terminal controls the first call to enter a call hold state. For example, the first terminal sends a first instruction to the second terminal, which instructs the second terminal to enter a send-only state, thus completing the call hold state for the first call. The first instruction can be a re-INVITE (SendOnly) instruction.

[0074] When the call type is an encrypted call and the call type is a plaintext call, the first terminal also obtains a second key based on the key negotiation result, and establishes a second call with the third terminal with the call type being an encrypted call, using the second key as the key corresponding to the second call. For example, the first terminal places the second key in the cryptographic operation area, and the first terminal and the third terminal conduct an encrypted call (i.e., the second call) based on this second key.

[0075] When the call type is a plaintext call and the conversation type is a plaintext conversation, the first terminal controls the first conversation to enter a call hold state. The first terminal also establishes a second conversation with the third terminal, with the conversation type being a plaintext conversation. For example, the first terminal sends a first instruction to the second terminal, which instructs the second terminal to enter a send-only state, completing the call hold state of the first conversation. The first instruction can be a re-INVITE (SendOnly) instruction.

[0076] In this embodiment, after receiving a call request initiated by a third terminal, the first terminal can control the first call to enter a call hold state and establish a second call with the third terminal, regardless of the call type of the first call. Therefore, the access of the third terminal can be achieved without being limited to the call type of the first call, making it more applicable and improving the user experience.

[0077] Reference Figure 2 The diagram illustrates a flowchart of another voice call processing method according to an embodiment of this application.

[0078] like Figure 2 As shown, the voice call processing method may include the following steps:

[0079] Step 201: During the first call between the first terminal and the second terminal, the first terminal receives a call request initiated by the third terminal.

[0080] Step 202: In response to the call request, the first terminal initiates a key negotiation with the third terminal, determines the call type of the call request based on the key negotiation result, and obtains the call type of the first call.

[0081] Step 203: Based on the call type and the conversation type, the first terminal controls the first conversation to enter a call hold state and establishes a second conversation with the third terminal.

[0082] Step 204: After the second call ends, the first terminal controls the first call to enter a call hold recovery state based on the call type and the call type.

[0083] When the call type is an encrypted call and the conversation type is an encrypted conversation, the first terminal recovers the first key corresponding to the first conversation and controls the first conversation to enter a call hold recovery state. For example, the first terminal sends a second instruction to the second terminal, which instructs the second terminal to enter a transmit / receive state, completing the call hold recovery state of the first conversation. The second instruction can be a re-INVITE (SendRecv) instruction. For example, the first terminal places the first key in the cryptographic operation area, and the first terminal and the second terminal continue the encrypted conversation (i.e., the first conversation) based on this first key.

[0084] When the call type is an encrypted call and the call type is an encrypted call, since the second call between the first terminal and the third terminal has ended, the first terminal can also release the second key corresponding to the second call.

[0085] When the call type is a plaintext call and the call type is an encrypted call, the first terminal recovers the first key corresponding to the first call and controls the first call to enter a call hold recovery state. For example, the first terminal sends a second instruction to the second terminal, which instructs the second terminal to enter a transmit / receive state, completing the call hold recovery state of the first call. The second instruction can be a re-INVITE (SendRecv) instruction. For example, the first terminal places the first key in the cryptographic operation area, and the first terminal and the second terminal continue the encrypted call (i.e., the first call) based on this first key.

[0086] When the call type is encrypted and the call type is plaintext, the first terminal controls the first call to enter a call hold recovery state. For example, the first terminal sends a second instruction to the second terminal, which instructs the second terminal to enter a transmit / receive state, completing the call hold recovery state of the first call. The second instruction can be a re-INVITE (SendRecv) instruction.

[0087] When the call type is an encrypted call and the call type is a plaintext call, since the second call between the first terminal and the third terminal has ended, the first terminal can also release the second key corresponding to the second call.

[0088] When the call type is a plaintext call and the conversation type is a plaintext conversation, the first terminal controls the first conversation to enter a call hold recovery state. For example, the first terminal sends a second instruction to the second terminal, which instructs the second terminal to enter a transmit / receive state, completing the call hold recovery state of the first conversation. The second instruction can be a re-INVITE (SendRecv) instruction.

[0089] In this embodiment, call hold and call resumption functions can be implemented, and different operations can be performed based on different call types and call types, making the operation process simple.

[0090] The voice call processing method in this application embodiment can be executed by a transceiver device.

[0091] Reference Figure 3 The diagram illustrates a transceiver device according to an embodiment of this application. Figure 3 As shown, the transceiver device includes a processing unit 301 and a transceiver unit 302. The processing unit 301 can perform key storage, key negotiation, and set up a key operation area.

[0092] The processing unit 301 is configured to, if the transceiver unit 302 receives a call request sent by a third terminal to the first terminal while the first terminal and the second terminal are in the middle of a first call, initiate a key negotiation process based on the information carried in the call request. This information is normal call request information and no additional requirements are made. The call type of the call request is identified through the key negotiation result, and the corresponding processing method is selected based on the call type of the first call.

[0093] When the call type of the call request is an encrypted call and the call type of the first call is an encrypted call, the processing unit 301 saves the first key corresponding to the first call and puts it into the cryptographic operation area using the second key negotiated by the call request.

[0094] When the call type of the call request is a plaintext call and the call type of the first call is an encrypted call, the processing unit 301 saves the first key corresponding to the first call type and establishes a plaintext call corresponding to the call request.

[0095] When the call type of the call request is an encrypted call and the call type of the first call is a plaintext call, the processing unit 301 puts the second key negotiated in the call request into the cryptographic operation area.

[0096] When the call type of the call request is a plaintext call and the call type of the first call is a plaintext call, the processing unit 301 does not perform any other operations and supports the call hold function under plaintext call.

[0097] The transceiver unit 302 may be the first terminal or an application server that communicates with the first terminal, and is not limited here.

[0098] The transceiver device provided in this application embodiment, if it receives a call request sent by a third terminal to the first terminal while the first terminal is in the middleware call, directly uses the middleware negotiation method to determine the call type of the call request, and uses key negotiation, key storage, key recovery, and cryptographic operation structure to realize the call waiting switching function, so as to ensure that the user has the same experience when using encrypted and plaintext calls.

[0099] Assuming that the first call has been established between VoLTE encrypted terminal (terminal with encrypted call function) B (equivalent to the first terminal mentioned above) and terminal C (equivalent to the second terminal mentioned above), and terminal B has activated the call waiting service, if the calling terminal A (equivalent to the third terminal mentioned above) calls the called terminal B in an attempt to establish a second call with the called terminal B, then regardless of whether the calling terminal A initiates a plaintext call request or an encrypted call request, the called terminal B can accept the call request from terminal A.

[0100] Reference Figure 4 The diagram illustrates a voice call processing flow according to an embodiment of this application.

[0101] like Figure 4 As shown, when terminal B and terminal C are making a VoLTE encrypted call, terminal B has activated the call waiting service.

[0102] Terminal A initiates another call request to Terminal B. Terminal A sends a call request INVITE to Terminal B (specifically, the call request is initiated through devices such as the Proxy Call Session Control Function / Session Border Controller (P-CSCF / SBC) and the VoLTE Application Server (VoLTE AS)).

[0103] After receiving the INVITE call request, Terminal B initiates a key negotiation process to determine the call type. If the call request is determined to be an encrypted call, Terminal B sends a re-INVITE (SendOnly) command to Terminal C. Terminal C then becomes a receive-only terminal. Simultaneously, Terminal B initiates a key saving process with the key middleware to save the BC key of the current call. The negotiated AB key is then used as the encryption key for the call between Terminal A and Terminal B, establishing an encrypted call between them.

[0104] After the encrypted call between terminal A and terminal B is completed, terminal B initiates a key recovery process between terminal B and terminal C, sending a re-INVITE (SendRecv) command to terminal C to restore the BC key between terminal B and terminal C, thus restoring the encrypted call between terminal B and terminal C.

[0105] Reference Figure 5 The diagram illustrates another voice call processing flow according to an embodiment of this application.

[0106] like Figure 5 As shown, when terminal B and terminal C are making a VoLTE encrypted call, terminal B has activated the call waiting service.

[0107] Terminal A initiates another call request to Terminal B. Terminal A sends a call request INVITE to Terminal B (specifically, the call request is initiated through devices such as the Proxy Call Session Control Function / Session Border Controller (P-CSCF / SBC) and the VoLTE Application Server (VoLTE AS)).

[0108] After receiving the INVITE call request, Terminal B initiates a key negotiation process to determine the call type. If the call request is determined to be a plaintext call, Terminal B sends a re-INVITE (SendOnly) command to Terminal C. Terminal C then changes its state to receive-only. Simultaneously, Terminal B initiates a key saving process with the key middleware to save the BC key for the current call and establishes a plaintext call between Terminal A and Terminal B.

[0109] After the plaintext call between terminal A and terminal B is completed, terminal B initiates a key recovery process between terminal B and terminal C, sending a re-INVITE (SendRecv) command to terminal C to restore the BC key between terminal B and terminal C, thus restoring the encrypted call between terminal B and terminal C.

[0110] Reference Figure 6 The diagram illustrates another voice call processing flow according to an embodiment of this application.

[0111] like Figure 6 As shown, when terminal B and terminal C are making a VoLTE plaintext call, terminal B has activated the call waiting service.

[0112] Terminal A initiates another call request to Terminal B. Terminal A sends a call request INVITE to Terminal B (specifically, the call request is initiated through devices such as the Proxy Call Session Control Function / Session Border Controller (P-CSCF / SBC) and the VoLTE Application Server (VoLTE AS)).

[0113] After receiving the INVITE call request, terminal B initiates a key negotiation process to determine the call type of the request. If the call request is determined to be a plaintext call, terminal B sends a re-INVITE (SendOnly) command to terminal C, and terminal C's state changes to receive-only, while a plaintext call is established between terminal A and terminal B.

[0114] After the plaintext call between terminal A and terminal B is completed, terminal B initiates the call recovery process between terminal B and terminal C, sending a re-INVITE (SendRecv) command to terminal C to resume the plaintext call between terminal B and terminal C.

[0115] Reference Figure 7 The diagram illustrates another voice call processing flow according to an embodiment of this application.

[0116] like Figure 7 As shown, when terminal B and terminal C are making a VoLTE plaintext call, terminal B has activated the call waiting service.

[0117] Terminal A initiates another call request to Terminal B. Terminal A sends a call request INVITE to Terminal B (specifically, the call request is initiated through devices such as the Proxy Call Session Control Function / Session Border Controller (P-CSCF / SBC) and the VoLTE Application Server (VoLTE AS)).

[0118] After receiving the INVITE call request, Terminal B initiates a key negotiation process to determine the call type. If the call request is determined to be an encrypted call, Terminal B sends a re-INVITE (SendOnly) command to Terminal C. Terminal C then becomes a receive-only terminal and uses the negotiated AB key as the encryption key for communication between Terminal A and Terminal B, establishing an encrypted call between them.

[0119] After the encrypted call between terminal A and terminal B is completed, terminal B initiates the call recovery process between terminal B and terminal C, sending a re-INVITE (SendRecv) command to terminal C to restore the plaintext call between terminal B and terminal C.

[0120] In this embodiment, if a call request is received from a third terminal to the first terminal while the first terminal and the second terminal are in the middle of a first call, a key negotiation process is directly initiated based on the call request. The call type of the call request is determined based on the result of the key negotiation. Then, based on the call type of the call request, the call type of the first call, and the key negotiation, key storage, and cryptographic operation capabilities provided by the transceiver device, call hold and call waiting are implemented. This solves the problem in the prior art that the call request must carry the call type and that call hold must be rejected, achieving the same user experience for VoLTE encrypted calls during call waiting as for ordinary calls.

[0121] Reference Figure 8 The diagram shows a structural block diagram of a voice call processing device according to an embodiment of this application. Figure 8 The voice call processing device shown is applied to the first terminal.

[0122] like Figure 8 As shown, the voice call processing device may include the following modules:

[0123] The receiving module 801 is used to receive a call request initiated by a third terminal during the first call between the first terminal and the second terminal.

[0124] The acquisition module 802 is used to respond to the call request, initiate key negotiation with the third terminal, determine the call type of the call request based on the key negotiation result, and acquire the call type of the first call;

[0125] The first control module 803 is used to control the first call to enter a call hold state based on the call type and the call type, and to establish a second call with the third terminal.

[0126] Optionally, the acquisition module 802 includes: a first determining submodule, configured to determine that the call type of the call request is an encrypted call after the key negotiation result indicates that the key negotiation was successful; and a second determining submodule, configured to determine that the call type of the call request is a plaintext call when the key negotiation result indicates that the key negotiation failed and the reason for the failure is that no key is required.

[0127] Optionally, the first control module 803 includes: a first control submodule, configured to, when the call type is an encrypted call and the call type is an encrypted call, save a first key corresponding to the first call, control the first call to enter a call hold state, obtain a second key based on the key negotiation result, establish a second call with the third terminal with a call type of encrypted call, and use the second key as the key corresponding to the second call; and / or, a second control submodule, configured to, when the call type is a plaintext call and the call type is an encrypted call, save a first key corresponding to the first call, control the first call to enter a call hold state, and ... The third terminal establishes a second call with a plaintext call type; and / or, the third control submodule is configured to, when the call type is an encrypted call and the call type is a plaintext call, control the first call to enter a call hold state, obtain a second key based on the key negotiation result, establish a second call with the third terminal with a call type of encrypted call, and use the second key as the key corresponding to the second call; and / or, the fourth control submodule is configured to, when the call type is a plaintext call and the call type is a plaintext call, control the first call to enter a call hold state, and establish a second call with the third terminal with a call type of plaintext call.

[0128] Optionally, the first control module 803 is specifically used to send a first instruction to the second terminal, the first instruction being used to instruct the second terminal to enter a send-only state and complete the call hold state of the first call.

[0129] Optionally, the device further includes: a second control module, configured to control the first call to enter a call hold recovery state based on the call type and the call type after the second call ends.

[0130] Optionally, the second control module includes: a fifth control submodule, configured to, when the call type is an encrypted call and the call type is an encrypted call, restore the first key corresponding to the first call, control the first call to enter a call hold-up recovery state, and release the second key corresponding to the second call; and / or, a sixth control submodule, configured to, when the call type is a plaintext call and the call type is an encrypted call, restore the first key corresponding to the first call and control the first call to enter a call hold-up recovery state; and / or, a seventh control submodule, configured to, when the call type is an encrypted call and the call type is a plaintext call, control the first call to enter a call hold-up recovery state and release the second key corresponding to the second call; and / or, an eighth control submodule, configured to, when the call type is a plaintext call and the call type is a plaintext call, control the first call to enter a call hold-up recovery state.

[0131] Optionally, the second control module is specifically used to send a second instruction to the second terminal, the second instruction being used to instruct the second terminal to enter the transmit / receive state and complete the call hold recovery state of the first call.

[0132] In this embodiment, after receiving a call request initiated by a third terminal, the first terminal can control the first call to enter a call hold state and establish a second call with the third terminal, regardless of the call type of the first call. Therefore, the access of the third terminal can be achieved without being limited to the call type of the first call, making it more applicable and improving the user experience.

[0133] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0134] In embodiments of this application, an electronic device is also provided. This electronic device may include one or more processors and one or more computer-readable storage media storing instructions thereon, such as application programs. When the instructions are executed by the one or more processors, the processors cause the processors to perform the voice call processing method of any of the above embodiments.

[0135] Reference Figure 9 The diagram illustrates a schematic representation of an electronic device structure according to an embodiment of this application. Figure 9 As shown, the electronic device includes a processor 901, a communication interface 902, a memory 903, and a communication bus 904. The processor 901, communication interface 902, and memory 903 communicate with each other via the communication bus 904.

[0136] Memory 903 is used to store computer programs.

[0137] When the processor 901 executes the program stored in the memory 903, it implements the voice call processing method of any of the above embodiments.

[0138] The communication interface 902 is used for communication between the above-mentioned electronic device and other devices.

[0139] The aforementioned communication bus 904 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, it is represented by only one thick line in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0140] The processor 901 mentioned above may include, but is not limited to: a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0141] The aforementioned memory 903 may include, but is not limited to: Read Only Memory (ROM), Random Access Memory (RAM), Compact Disc Read Only Memory (CD-ROM), Electronic Erasable Programmable Read Only Memory (EEPROM), Hard Disk, Floppy Disk, Flash Memory, etc.

[0142] In embodiments of this application, a computer-readable storage medium is also provided, on which a computer program is stored, which can be executed by a processor of an electronic device, and when the computer program is executed by the processor, the processor performs the voice call processing method as described in any of the above embodiments.

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

[0144] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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 terminal device 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 terminal device. 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 terminal device that includes said element.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0146] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0147] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0148] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0149] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0150] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0151] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0152] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0153] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. In summary, the content of this specification should not be construed as a limitation of this application.

Claims

1. A voice call processing method, characterized in that, The method is applied to a first terminal, and the method includes: While the first terminal and the second terminal are in the process of making a first call, a call request initiated by the third terminal is received; In response to the call request, a key negotiation is initiated with the third terminal, the call type of the call request is determined based on the key negotiation result, and the call type of the first call is obtained; Based on the call type and the conversation type, the first conversation is controlled to enter a call hold state, and a second conversation is established with the third terminal; The step of controlling the first call to enter a call hold state and establishing a second call with the third terminal based on the call type and the call type includes: When the call type is encrypted call and the call type is encrypted call, the first key corresponding to the first call is saved, the first call is controlled to enter a call hold state, a second key is obtained based on the key negotiation result, a second call of the encrypted call type is established with the third terminal, and the second key is used as the key corresponding to the second call; and / or When the call type is a plaintext call and the call type is an encrypted call, the first key corresponding to the first call is saved, the first call is controlled to enter a call hold state, and a second call with the third terminal is established with a plaintext call type; and / or When the call type is encrypted and the call type is plaintext, the first call is controlled to enter a call hold state. A second key is obtained based on the key negotiation result. A second call with the third terminal, characterized as an encrypted call, is established, and the second key is used as the key corresponding to the second call; and / or... When the call type is plaintext call and the call type is plaintext call, the first call is controlled to enter a call hold state, and a second call with the third terminal is established with a call type of plaintext call.

2. The method according to claim 1, characterized in that, Determining the call type of the call request based on the key negotiation result includes: After the key negotiation result indicates that the key negotiation was successful, the call type of the call request is determined to be an encrypted call; When the key negotiation result indicates that the key negotiation failed and the reason for the failure is that no key is required, the call type of the call request is determined to be a plaintext call.

3. The method according to claim 1, characterized in that, The control of the first call to enter call hold state includes: A first instruction is sent to the second terminal, which instructs the second terminal to enter a send-only state and complete the call hold state of the first call.

4. The method according to claim 1, characterized in that, The method further includes: After the second call ends, based on the call type and the call type, the first call is controlled to enter a call hold recovery state.

5. The method according to claim 4, characterized in that, The step of controlling the first call to enter a call hold recovery state based on the call type and the conversation type includes: When the call type is an encrypted call and the call type is an encrypted call, restore the first key corresponding to the first call, control the first call to enter a call hold recovery state, and release the second key corresponding to the second call; and / or, When the call type is a plaintext call and the call type is an encrypted call, restore the first key corresponding to the first call, and control the first call to enter a call hold recovery state; and / or, When the call type is an encrypted call and the call type is a plaintext call, control the first call to enter a call hold recovery state and release the second key corresponding to the second call; and / or, When the call type is a plaintext call and the call type is a plaintext call, the first call is controlled to enter a call hold recovery state.

6. The method according to claim 4, characterized in that, The control of the first call to enter the call hold recovery state includes: A second instruction is sent to the second terminal, which instructs the second terminal to enter the transmit / receive state and complete the call hold recovery state of the first call.

7. A voice call processing device, characterized in that, The device is applied to a first terminal, and the device includes: The receiving module is used to receive a call request initiated by a third terminal during the first call between the first terminal and the second terminal. The acquisition module is used to respond to the call request, initiate key negotiation with the third terminal, determine the call type of the call request based on the key negotiation result, and acquire the call type of the first call; The first control module is used to control the first call to enter a call hold state based on the call type and the conversation type, and to establish a second call with the third terminal; The first control module includes: A first control submodule is configured to, when the call type is an encrypted call and the call type is an encrypted call, save a first key corresponding to the first call, control the first call to enter a call hold state, obtain a second key based on the key negotiation result, establish a second call with the third terminal with a call type of encrypted call, and use the second key as the key corresponding to the second call; and / or The second control submodule is configured to, when the call type is a plaintext call and the call type is an encrypted call, save the first key corresponding to the first call, control the first call to enter a call hold state, and establish a second call with the third terminal with a call type of plaintext call; and / or The third control submodule is configured to, when the call type is an encrypted call and the call type is a plaintext call, control the first call to enter a call hold state, obtain a second key based on the key negotiation result, establish a second call with the third terminal with a call type of encrypted call, and use the second key as the key corresponding to the second call; and / or The fourth control submodule is used to control the first call to enter a call hold state and establish a second call with the third terminal when the call type is a plaintext call and the call type is a plaintext call.

8. An electronic device, characterized in that, include: One or more processors; and One or more computer-readable storage media on which instructions are stored; When the instruction is executed by the one or more processors, the processors perform the voice call processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, causes the processor to perform the voice call processing method as described in any one of claims 1 to 6.

Images