A call processing method, terminal and storage medium

Abstract

The present application provides a call processing method and terminal, belonging to the field of terminal technology, the method includes receiving a call connection request from a calling terminal; when the called terminal fails to establish a call connection with the calling terminal within a preset time, receiving a Cancel message sent by the network, the Cancel message carrying a Reason header field; when the cause field and the text field in the Reason header field meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is the first interpretation; when the cause field and the text field in the Reason header field do not meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is the second interpretation. The method can correctly interpret different Cancel messages by judging whether the combination field of the cause field and the text field in the Cancel message meets the target field combination condition.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a call processing method, a terminal and a storage medium. Background Art

[0002] When the calling terminal calls the called terminal, a session initiation protocol (SIP) signaling message can be transmitted through the network to achieve interaction between the calling terminal and the called terminal. For example, if the called terminal does not answer the call, the network will send a Cancel message to the called terminal to indicate that the called terminal did not answer the call.

[0003] After receiving the Cancel message, the called terminal can determine the interpretation corresponding to the Cancel message based on the Reason header field carried by the Cancel message. For example, it can be interpreted as not answered or answered by another device. In this way, the called terminal can display the interpretation content corresponding to each call record on the call record interface.

[0004] However, the current Cancel interpretation regulations are incomplete, so that after the called terminal interprets the Cancel message, the call record displays unreasonable interpretation content, causing confusion to users and affecting user experience. Summary of the invention

[0005] The present application provides a call processing method, a terminal and a storage medium, which can correctly interpret the Cancel message and improve the user experience.

[0006] In a first aspect, the present application provides a call processing method, which is applied to a called terminal, and the method includes: receiving a call connection request from a calling terminal; when the called terminal fails to establish a call connection with the calling terminal within a preset time period, receiving a Cancel message sent by a network, wherein the Cancel message carries a Reason header field; when the cause field and the text field in the Reason header field meet a target field combination condition, determining that the interpretation corresponding to the Cancel message is a first interpretation; when the cause field and the text field in the Reason header field do not meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is a second interpretation; wherein the first interpretation is different from the second interpretation; and displaying the interpretation corresponding to the Cancel message on a call record interface of the called terminal.

[0007] In this way, the scheme can correctly interpret different Cancel messages by judging whether the combination of the cause field and the text field in the Cancel message meets the target field combination condition. For example, the target field combination condition is cause = 200, text = "Call completed elsewhere", where the text field does not distinguish between uppercase and lowercase English letters. In this way, for scenarios clearly specified in the protocol, such as Reason: SIP; cause = 200, text = "Call completed elsewhere", it can be correctly interpreted as other devices answering the call. For scenarios not clearly specified in the protocol, such as Reason: SIP; cause = 200; text = "Decline", it can also be correctly interpreted as not answering the call.

[0008] If the scenarios for other devices answering the call include new field combinations in the future, the target field combination condition may also include other newly added field combinations.

[0009] In an implementable manner, when the cause field and the text field in the Reason header field meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is the first interpretation includes: when the Reason header field is not a Reason header field specified by the target protocol, and the cause field and the text field in the Reason header field meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is the first interpretation.

[0010] In this way, by adding "the Reason header field is not a Reason header field specified by the target protocol" to the condition for determining that the interpretation corresponding to the Cancel message is the first interpretation, before determining the interpretation corresponding to the Cancel message, since it is first compared with the target protocol specification, even if new provisions are added in the future protocol for the scenario of other devices answering the call, the solution provided by this application is still applicable.

[0011] In an implementable manner, when the cause field and the text field in the Reason header field do not satisfy the target field combination condition, determining that the interpretation corresponding to the Cancel message is the second interpretation includes: when the Reason header field is not a Reason header field specified by the target protocol, and the cause field and the text field in the Reason header field do not satisfy the target field combination condition, determining that the interpretation corresponding to the Cancel message is the second interpretation.

[0012] In this way, by adding "the Reason header field is not a Reason header field specified by the target protocol" to the condition for determining that the interpretation corresponding to the Cancel message is the second interpretation, before determining the interpretation corresponding to the Cancel message, since it is first compared with the target protocol specification, even if new provisions are added in the future protocol for the scenario of other devices answering the call, the solution provided by this application is still applicable.

[0013] In one achievable manner, the target field combination condition includes the cause field being cause=200, and the text field being text=“Call completed elsewhere”, wherein the text field does not distinguish between uppercase English letters and lowercase English letters.

[0014] In this way, since the present application does not distinguish between uppercase and lowercase English letters in the text field, the present application can correctly interpret the scenario of cause=200, text=“Call Completed Elsewhere” which does not originally comply with the protocol.

[0015] In one possible implementation, the first interpretation is used to indicate that other called terminals answer the call, and the second interpretation is used to indicate that all called terminals do not answer the call; wherein the other called terminals refer to terminals that have applied for a one-number-multiple-terminals service with the called terminal.

[0016] Thus, the first interpretation can represent that other called terminals answer the call, for example, the first interpretation can be other devices answering, other devices have answered, other devices have answered, etc. The second interpretation can represent that all called terminals do not answer the call, for example, the first interpretation can be not answering, not answering, etc.

[0017] In an implementable manner, the first interpretation is that the call is answered by another device, and the second interpretation is that the call is not answered.

[0018] In an implementable manner, the Reason header field further includes a protocol field, and the method further includes: determining the target protocol corresponding to the Reason header field based on the protocol field; when the target protocol includes a field combination of the cause field and the text field in the Reason header field, determining that the Reason header field is a Reason header field specified in the target protocol; and when the target protocol does not include a field combination of the cause field and the text field in the Reason header field, determining that the Reason header field is not a Reason header field specified in the target protocol.

[0019] In this way, it is possible to determine whether the Reason header field is the Reason header field specified in the target protocol by directly comparing it with the target protocol.

[0020] In an implementable manner, the method further includes: acquiring a preset mapping relationship, the preset mapping relationship including a correspondence between a Reason header field and an interpretation specified in a protocol; when the preset mapping relationship includes a field combination of the cause field and the text field in the Reason header field, determining that the Reason header field is a Reason header field specified in the target protocol; and when the preset mapping relationship does not include a field combination of the cause field and the text field in the Reason header field, determining that the Reason header field is not a Reason header field specified in the target protocol.

[0021] In this way, it can be determined whether the Reason header field is the Reason header field specified in the target protocol through the preset mapping relationship.

[0022] In an implementable manner, the method further includes: when the Reason header field is a Reason header field specified by the target protocol, determining, based on the preset mapping relationship, an interpretation corresponding to the Reason header field.

[0023] For example, the preset mapping relationship may be a mapping table used to characterize the correspondence between the Reason header field and the interpretation.

[0024] In this way, after determining that the Reason header field is the Reason header field included in the mapping table, the interpretation corresponding to the Reason header field can be determined based on the mapping table.

[0025] In an implementable manner, the Reason header field specified by the target protocol includes: Reason: SIP; cause=200; text=“Call completed elsewhere”, and Reason: SIP; cause=603; text=“Declined”.

[0026] In a second aspect, the present application provides a terminal, comprising a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code comprises computer instructions, and when the processor executes the computer instructions, the terminal executes a method as described in any one of the first aspects.

[0027] In a third aspect, the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is executed on a computer, the computer executes the method as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A scene diagram of a call system provided in an embodiment of the present application;

[0029] Figure 2 A workflow diagram of call processing provided in an embodiment of the present application;

[0030] Figure 3 A workflow diagram of call processing in a one-number-multiple-terminal scenario provided in an embodiment of the present application;

[0031] Figure 4 An example diagram of a call record interface for a one-number-multiple-terminal scenario provided in an embodiment of the present application;

[0032] Figure 5 A workflow diagram of call processing in a non-one-number-multiple-terminal scenario provided in an embodiment of the present application;

[0033] Figure 6 An example diagram of a call record interface for a non-one-number-multiple-terminal scenario provided in an embodiment of the present application;

[0034] Figure 7 A schematic diagram of the hardware structure of a terminal provided in an embodiment of the present application;

[0035] Figure 8 A schematic diagram of the software structure of a terminal provided in an embodiment of the present application;

[0036] Fig. 9 A flowchart of a call processing method provided in an embodiment of the present application;

[0037] Fig.10 An example diagram of a call record interface for a non-one-number-multiple-terminal scenario provided in an embodiment of the present application;

[0038] Fig.11A A data flow diagram of a call processing provided in an embodiment of the present application;

[0039] Fig. 11B A data flow diagram of another call processing provided in an embodiment of the present application;

[0040] Fig. 11C A data flow diagram of another call processing provided in an embodiment of the present application;

[0041] Fig.12A flowchart of a call processing method provided in an embodiment of the present application;

[0042] Fig.13 A structural block diagram of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] To facilitate the understanding of the technical solution of the application, the application scenarios involved in this application are first introduced below.

[0044] Figure 1 A scene diagram of a call system provided in an embodiment of the present application. Figure 1 As shown, the calling system includes a calling terminal 10 , a called terminal 20 , a base station 30 , a base station 40 and a network 50 .

[0045] The calling terminal 10 is a terminal device that initiates a call request. For example, the calling terminal 10 can dial the number of the called terminal 20 and request to establish a communication connection with the called terminal 20. The calling terminal 10 can be an electronic device with a calling function, such as a mobile phone, a tablet computer, a smart watch, a smart bracelet, etc.

[0046] The called terminal 20 is a terminal device that receives a call request from the calling terminal 10. For example, after the calling terminal 10 dials the number of the called terminal 20, the called terminal 20 can answer or reject the call based on the call request of the calling terminal 10. The called terminal 20 can be an electronic device with a call function, such as a mobile phone, a tablet computer, a smart watch, a smart bracelet, etc.

[0047] The calling terminal 10 and the called terminal 20 establish a communication connection through the base station 30 , the base station 40 and the network 50 .

[0048] The base station 30 is a base station of a cell where the calling terminal 10 is located, and the base station 40 is a base station of a cell where the called terminal 20 is located.

[0049] The network 50 may include a calling IP multimedia subsystem (IMS) domain and a called IMS domain. IMS is a concept proposed by 3GPP. It is a general network architecture that provides multimedia services on an IP-based network. It can provide integrated multimedia services and Internet applications for users using different access methods. Among them, VoLTE and VoNR are currently common voice services that use IP data transmission technology, that is, IMS-based. In some embodiments, the calling IMS domain and the called IMS domain may both include an IMS domain core network and an evolved packet core network.

[0050] In this way, Figure 1As shown, in the process of the calling terminal 10 calling the called terminal 20, the session initiation protocol (SIP) signaling message can be transmitted through the base station 30, the base station 40 and the network 50 to realize the interaction between the calling terminal 10 and the called terminal 20. For example, when the calling terminal 10 calls the called terminal 20, the calling terminal 10 can transmit the initiated call request to the calling IMS domain through the base station 30. The calling IMS domain can process the received call request and send the processed call request to the called IMS domain. The called IMS domain can also further process the received call request and send the processed call request to the called terminal 20 through the base station 40.

[0051] SIP is a multimedia communication protocol widely used in IMS networks, which can support and be applied to multimedia services such as voice, video, and data. The following describes some SIP signaling messages involved in call processing.

[0052] Invite: indicates that the calling terminal 10 sends a call request to request to establish a call with the called terminal 20.

[0053] 100Trying: indicates that the called terminal 20 has received the call request from the calling terminal 10.

[0054] 180Ringing: indicates that the called terminal 20 is ringing.

[0055] 200OK: indicates a successful response.

[0056] ACK: Indicates that the client confirms to the server that it has received the final response to the Invite request.

[0057] BYE: Indicates that the call has ended.

[0058] Cancel: indicates that the called terminal 20 did not answer the call.

[0059] For example, Figure 2 A call processing flow chart provided in an embodiment of the present application. Figure 2 As shown, the call processing flow may include the following steps:

[0060] S101 , the calling terminal 10 sends a call request signaling Invite to the called terminal 20 through the network 50 .

[0061] S102 , the called terminal 20 sends a SIP signaling 100 Trying to the calling terminal 10 through the network 50 .

[0062] The SIP signaling 100Trying is used to indicate that the called terminal 20 has received the call request.

[0063] S103 , the called terminal 20 sends a SIP signaling 180 Ringing to the calling terminal 10 through the network 50 .

[0064] The SIP signaling 180Ringing is used to indicate that the called terminal 20 has been ringing.

[0065] It should be noted that other SIP signaling interactions may be included between steps S102 and S103, for example, SIP signaling for negotiating media capabilities and resource reservation processes, for details of which please refer to related technologies and will not be described in detail here.

[0066] After the ringing, the called terminal 20 can answer the call or not. The processing flow of the called terminal 20 answering the call can refer to the description of steps S104 to S109, and the processing flow of the called terminal 20 not answering the call can refer to the description of steps S110 to S111.

[0067] S104, the called terminal 20 answers the call.

[0068] S105 , the called terminal 20 sends a SIP signaling 200 OK to the calling terminal 10 through the network 50 .

[0069] The SIP signaling 200OK is used to inform the calling terminal 10 that the called terminal 20 has answered the call, that is, the called terminal 20 has successfully responded to the call request of the calling terminal 10.

[0070] S106 , the calling terminal 10 sends a SIP signaling ACK to the called terminal 20 through the network 50 .

[0071] The SIP signaling ACK is used to inform the called terminal 20 that the calling terminal 10 has received the final response of the called terminal 20 to the call request.

[0072] S107: A media session is established between the calling terminal 10 and the called terminal 20.

[0073] After the media session between the calling terminal 10 and the called terminal 20 is successfully established, the calling terminal user and the called terminal user can communicate through the calling terminal 10 and the called terminal 20 .

[0074] S108, the called terminal 20 sends a SIP signaling BYE to the calling terminal 10 through the network 50, wherein the SIP signaling BYE is used to indicate the termination of the established call.

[0075] Exemplarily, after the calling terminal 10 and the called terminal 20 talk for a certain period of time, the called terminal 20 hangs up first, and then the called terminal 20 sends a SIP signaling BYE to the calling terminal 10 through the network 50 to terminate the call.

[0076] S109 , the calling terminal 10 sends a SIP signaling 200 OK to the called terminal 20 through the network 50 .

[0077] The SIP signaling 200OK is used to inform the called terminal 20 that the calling terminal 10 has received the instruction from the called terminal 20 to end the call.

[0078] It can be seen that steps S101 to S109 complete the processing flow of a successful call between the calling terminal 10 and the called terminal 20.

[0079] It should be understood that the embodiment of the present application is only exemplified by taking the called terminal 20 hanging up first as an example. If the calling terminal 10 hangs up first after the calling terminal 10 and the called terminal 20 have been talking for a certain period of time, the calling terminal 10 sends a SIP signaling BYE to the called terminal 00 through the network 50 to terminate the call. Correspondingly, in step S09, the called terminal 20 sends a SIP signaling 200OK to the calling terminal 10 through the network 50.

[0080] S110, the called terminal 20 does not answer the call within a preset time period.

[0081] S111 , the network 50 sends a SIP signaling Cancel to the called terminal 20 .

[0082] The SIP signaling Cancel indicates that the called terminal 20 does not answer the call due to timeout, and the network actively hangs up the call.

[0083] In the case that the called terminal 20 times out and does not answer the call, the network 50 sends a Cancel message (also called a hang-up message) to the called terminal 20 through the base station 40. The Cancel message may carry a Reason header field. Exemplarily, the format of the Reason header field may be: Reason: SIP; cause = 200; text = "Call completed elsewhere". The SIP field indicates the protocol name, the cause field indicates the response code, and the text field indicates an explanation of the response. For example, a Cancel message with a Reason header field in the above format indicates that the protocol is SIP, the response code is 200, and the explanation is that the call was answered by another device.

[0084] For different scenarios, the Reason header field carried in the Cancel message sent by the network 50 to the called terminal 20 through the base station 40 is different.

[0085] For example, Figure 3As shown, the protocol clearly stipulates the following two scenarios: the Reason header field carried in the Cancel message sent by the network 50 to the called terminal 20.

[0086] Scenario 1:

[0087] In a one-number-multiple-terminals scenario, if one of the called terminals answers the call, the network 50 sends a Cancel message to the other called terminals, and carries the following Reason header field: Reason: SIP; cause = 200; text = "Call completed else where".

[0088] Scenario 2:

[0089] In a one-number-multiple-terminals scenario, if one of the called terminals rejects the call, the network 50 sends a Cancel message to the other called terminals, and carries the following Reason header field: Reason: SIP; cause=603; text=“Declined”.

[0090] Among them, the one-number-multiple-terminal scenario refers to that multiple terminals can share a phone number and the package of the phone number. Take the one-number-dual-terminal scenario where two terminals share a phone number and the package of the phone number as an example. Figure 3 As shown, the mobile phone 20A and the watch 20B apply for a one-number dual-terminal service, the mobile phone 20A is the terminal device corresponding to the primary card (also called the primary device), and the watch 20B is the terminal device corresponding to the secondary card (also called the secondary device). When the user uses the watch 20B to make an outgoing call, the phone number corresponding to the watch 20B is the phone number of the primary card. When other users dial the phone number of the primary card, the mobile phone 20A and the watch 20B ring at the same time, and the user can use the mobile phone 20A or the watch 20B to answer the call.

[0091] For example, Figure 3 As shown, a mobile phone 20A and a watch 20B that have applied for a one-number dual-terminal service are taken as an example as the called terminal 20. When the calling terminal 10 dials the phone number of the mobile phone 20A, the mobile phone 20A and the watch 20B ring at the same time.

[0092] Corresponding to scenario 1, if the watch 20B answers the call from the calling terminal 10, the network 50 will send a Cancel to the mobile phone 20A based on the protocol, and the Reason header field is as follows: Reason: SIP; cause = 200; text = "Call completed elsewhere", which means that the other device has answered the call.

[0093] Corresponding to scenario 2, if the watch 20B rejects the call from the calling terminal 10, the network 50 will send a Cancel to the mobile phone 20A based on the protocol, and the Reason header field is as follows: Reason: SIP; cause = 603; text = "Declined", which means that the call was not answered.

[0094] After receiving the Cancel sent by the network, mobile phone 20A parses the Reason header field carried by Cancel. If the Reason header field carried by Cancel is Cancel clearly specified in the protocol, mobile phone 20A interprets the corresponding Cancel based on the protocol. For example, for the Cancel corresponding to scenario 1, mobile phone 20A can interpret it as other devices answering the call. For the Cancel corresponding to scenario 2, mobile phone 20A can interpret it as not answering the call.

[0095] Furthermore, to improve user experience, the terminal may display an explanation corresponding to Cancel on the call record interface.

[0096] For example, Figure 4 This is an example diagram of a call record interface provided in an embodiment of the present application. Figure 4 As shown, for scenario 1, mobile phone 20A interprets the received Reason header field: Reason: SIP; cause = 200; text = "Call completed elsewhere" as the call was answered by another device. Correspondingly, it is marked as answered by another device after the call record. In this way, the user can understand that watch 20B answered the call of calling terminal 10 based on the content displayed on the call record interface. For scenario 2, mobile phone 20A interprets the received Reason header field: Reason: SIP; cause = 603; text = "Declined" as not answered. Correspondingly, it is marked as not answered after the call record. In this way, the user can understand that watch 20B rejected the call of calling terminal 10 based on the content displayed on the call record interface.

[0097] The above describes the scheme in which the network 50 sends a Cancel message to the called terminal in the scenario clearly defined in the protocol. The following describes the scheme in which the network 50 sends a Cancel message to the called terminal in the scenario not clearly defined in the protocol.

[0098] For example, for a non-one-number-multiple-terminal scenario (a non-one-number-multiple-terminal scenario means that the called terminal 20 has only one terminal device, and the called terminal 20 does not share a phone number with other terminals), if the called terminal 20 does not answer the call of the calling terminal 10, the network 50 sends a Cancel to the called terminal 20. However, for this scenario, the protocol does not clearly define the Reason header field carried by the Cancel.

[0099] In this way, the Cancel message sent by the network 50 to the called terminal 20 may include the following situations:

[0100] Case A, for a non-one-number-multiple-terminals scenario, if the called terminal 20 does not answer the call from the calling terminal 10, the network 50 may send a Cancel to the called terminal 20, but the sent Cancel does not carry a Reason header field.

[0101] In this case, the called terminal 20 interprets the Cancel message without the Reason header field sent by the network 50 as not answering the call.

[0102] Case B, for non-one-number-multiple-terminal scenarios, if the called terminal 20 does not answer the call of the calling terminal 10, the network 50 can send a Cancel to the called terminal 20, and the Reason header field carried by the Cancel is not any Reason header field specified in the protocol. For example, Figure 5 As shown, the Reason header field carried by Cancel is as follows: Reason: SIP; cause = 200; text = "Declined".

[0103] In this case, in the related art, the called terminal 20 interprets the Cancel sent by the network 50 based on the response code corresponding to the cause field in the Reason header field. For example, in the case of cause=200, since the protocol interprets cause=200 as other devices answering the call, the called terminal 20 will interpret the Cancel including cause=200 as other devices answering the call.

[0104] In this way, Figure 6 As shown, if in a non-one-number-multiple-terminal scenario, the Reason header field carried in the Cancel sent by the network 50 to the called terminal 20 is as follows: Reason: SIP; cause = 200; text = "Declined". Based on cause = 200 in the Reason header field, the called terminal 20 determines that the corresponding interpretation of the Cancel is answered by other devices. Correspondingly, in the call record interface of the called terminal 20, the call record is marked as answered by other devices.

[0105] However, in a non-one-number-multiple-terminal scenario, the call record interface of the called terminal 20 displays "Answered by other devices". This interpretation is obviously wrong, which will cause trouble to the user and affect the user experience.

[0106] To solve the above problems, an embodiment of the present application provides a call processing method. After the called terminal receives the Cancel, the method only interprets the situation where the Reason header field includes cause=200 and text="Call completed elsewhere" (wherein the Text content is not case-sensitive) as being answered by other devices. For Cancel in other situations, the called terminal interprets it as not being answered. In this way, if in a non-one-number-multiple-terminal scenario, the Reason header field carried by the Cancel sent by the network 50 to the called terminal 20 is as follows: Reason: SIP; cause=200; text="Declined". The called terminal 20 determines that the Reason header field does not belong to the situation where cause=200 and text="Call completed elsewhere", then interprets the Cancel as not being answered. In this way, for scenarios that are not clearly specified in the protocol, the terminal can also correctly interpret Cancel, thereby improving the user experience.

[0107] The call processing method provided in the embodiment of the present application can be applied to the called terminal 20. The specific structures of the called terminal 20 and the calling terminal 10 can be found in Figure 7 The structural diagram of the terminal 200 is shown.

[0108] The terminal 200 may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an earphone interface 270D, a sensor module 280, a button 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc. The sensor module 280 may include a pressure sensor 280A, a gyroscope sensor 280B, an air pressure sensor 280C, a magnetic sensor 280D, an acceleration sensor 280E, a distance sensor 280F, a proximity light sensor 280G, a fingerprint sensor 280H, a temperature sensor 280J, a touch sensor 280K, an ambient light sensor 280L, a bone conduction sensor 280M, etc.

[0109] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the terminal 200. In other embodiments of the present application, the terminal 200 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0110] The processor 210 may include one or more processing units, for example, the processor 210 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0111] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0112] The processor 210 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. The memory may store instructions or data that the processor 210 has just used or cyclically used. If the processor 210 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 210, and thus improves the efficiency of the system.

[0113] In some embodiments, the processor 210 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0114] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 210 may include multiple groups of I2C buses. The processor 210 may be coupled to the touch sensor 280K, the charger, the flash, the camera 293, etc. through different I2C bus interfaces. For example, the processor 210 may be coupled to the touch sensor 280K through the I2C interface, so that the processor 210 communicates with the touch sensor 280K through the I2C bus interface to realize the touch function of the terminal 200.

[0115] The I2S interface can be used for audio communication. In some embodiments, the processor 210 can include multiple groups of I2S buses. The processor 210 can be coupled to the audio module 270 via the I2S bus to achieve communication between the processor 210 and the audio module 270. In some embodiments, the audio module 270 can transmit an audio signal to the wireless communication module 260 via the I2S interface to achieve the function of answering a call through a Bluetooth headset.

[0116] The PCM interface can also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 270 and the wireless communication module 260 can be coupled via a PCM bus interface. In some embodiments, the audio module 270 can also transmit audio signals to the wireless communication module 260 via the PCM interface to realize the function of answering calls via a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0117] The UART interface is a universal serial data bus for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is generally used to connect the processor 210 and the wireless communication module 260. For example, the processor 210 communicates with the Bluetooth module in the wireless communication module 260 through the UART interface to implement the Bluetooth function. In some embodiments, the audio module 270 can transmit an audio signal to the wireless communication module 260 through the UART interface to implement the function of playing music through a Bluetooth headset.

[0118] The MIPI interface can be used to connect the processor 210 with peripheral devices such as the display screen 294 and the camera 293. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 210 and the camera 293 communicate via the CSI interface to implement the shooting function of the terminal 200. The processor 210 and the display screen 294 communicate via the DSI interface to implement the display function of the terminal 200.

[0119] The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 210 with the camera 293, the display screen 294, the wireless communication module 260, the audio module 270, the sensor module 280, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0120] The USB interface 230 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 230 can be used to connect a charger to charge the terminal 200, and can also be used to transmit data between the terminal 200 and peripheral devices. It can also be used to connect headphones to play audio through the headphones. The interface can also be used to connect other electronic devices, such as AR devices, etc.

[0121] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the terminal 200. In other embodiments of the present application, the terminal 200 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0122] The charging management module 240 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 240 may receive charging input from a wired charger through the USB interface 230. In some wireless charging embodiments, the charging management module 240 may receive wireless charging input through a wireless charging coil of the terminal 200. While the charging management module 240 is charging the battery 242, it may also power the terminal through the power management module 241.

[0123] The power management module 241 is used to connect the battery 242, the charging management module 240 and the processor 210. The power management module 241 receives input from the battery 242 and / or the charging management module 240, and supplies power to the processor 210, the internal memory 221, the display screen 294, the camera 293, and the wireless communication module 260. The power management module 241 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 241 can also be set in the processor 210. In other embodiments, the power management module 241 and the charging management module 240 can also be set in the same device.

[0124] The wireless communication function of the terminal 200 can be implemented through the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, the modem processor and the baseband processor.

[0125] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal 200 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0126] The mobile communication module 250 can provide solutions for wireless communications including 2G / 3G / 4G / 5G applied to the terminal 200. The mobile communication module 250 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 250 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 250 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 250 can be set in the processor 210. In some embodiments, at least some of the functional modules of the mobile communication module 250 can be set in the same device as at least some of the modules of the processor 210.

[0127] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 270A, a receiver 270B, etc.), or displays an image or video through a display screen 294. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 210 and be set in the same device as the mobile communication module 250 or other functional modules.

[0128] The wireless communication module 260 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the terminal 200. The wireless communication module 260 can be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and filters it, and sends the processed signal to the processor 210. The wireless communication module 260 can also receive the signal to be sent from the processor 210, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0129] In some embodiments, the antenna 1 of the terminal 200 is coupled to the mobile communication module 250, and the antenna 2 is coupled to the wireless communication module 260, so that the terminal 200 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0130] The terminal 200 implements the display function through a GPU, a display screen 294, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 210 may include one or more GPUs, which execute program instructions to generate or change display information.

[0131] The display screen 294 is used to display images, videos, etc. The display screen 294 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal 200 may include 1 or N display screens 294, where N is a positive integer greater than 1.

[0132] The terminal 200 can realize the shooting function through the ISP, the camera 293, the video codec, the GPU, the display screen 294 and the application processor.

[0133] The ISP is used to process the data fed back by the camera 293. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye. The ISP can also perform algorithm optimization on the noise and brightness of the image. The ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, the ISP can be set in the camera 293.

[0134] The camera 293 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the terminal 200 may include 1 or N cameras 293, where N is a positive integer greater than 1.

[0135] The digital signal processor is used to process digital signals, and can process not only digital image signals but also other digital signals. For example, when the terminal 200 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.

[0136] Video codecs are used to compress or decompress digital videos. Terminal 200 may support one or more video codecs. Thus, terminal 200 may play or record videos in various coding formats, such as moving picture experts group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0137] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of the terminal 200 can be realized, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0138] The external memory interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal 200. The external memory card communicates with the processor 210 through the external memory interface 220 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0139] The internal memory 221 can be used to store computer executable program codes, which include instructions. The internal memory 221 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the terminal 200 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 221 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 210 executes various functional applications and data processing of the terminal 200 by running instructions stored in the internal memory 221 and / or instructions stored in a memory provided in the processor.

[0140] The terminal 200 can implement audio functions such as music playing and recording through the audio module 270, the speaker 270A, the receiver 270B, the microphone 270C, the earphone interface 270D, and the application processor.

[0141] The audio module 270 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signal. The audio module 270 can also be used to encode and decode audio signals. In some embodiments, the audio module 270 can be arranged in the processor 210, or some functional modules of the audio module 270 can be arranged in the processor 210.

[0142] The speaker 270A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The terminal 200 can listen to music or listen to a hands-free call through the speaker 270A. A plurality of speakers 270A can be provided in the terminal 200, for example, a speaker 270A can be provided at the top of the terminal 200, a speaker 270A can be provided at the bottom, and so on.

[0143] The receiver 270B, also called a "receiver", is used to convert audio electrical signals into sound signals. When the terminal 200 receives a call or voice message, the voice can be received by placing the receiver 270B close to the human ear. In some embodiments, the speaker 270A and the receiver 270B can also be set as one component, which is not limited in this application.

[0144] Microphone 270C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can make a sound by approaching the microphone 270C with his mouth to input the sound signal into the microphone 270C. The terminal 200 can be provided with at least one microphone 270C. In other embodiments, the terminal 200 can be provided with two microphones 270C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the terminal 200 can also be provided with three, four or more microphones 270C to realize the collection of sound signals, noise reduction, identification of sound sources, realization of directional recording function, etc.

[0145] The earphone interface 270D is used to connect a wired earphone and can be a USB interface 230 or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0146] The pressure sensor 280A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 280A can be set on the display screen 294. There are many types of pressure sensors 280A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. The capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 280A, the capacitance between the electrodes changes. The terminal 200 determines the intensity of the pressure according to the change in capacitance. When a touch operation acts on the display screen 294, the terminal 200 detects the touch operation intensity according to the pressure sensor 280A. The terminal 200 can also calculate the touch position according to the detection signal of the pressure sensor 280A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, an instruction to create a new short message is executed.

[0147] The gyro sensor 280B can be used to determine the motion posture of the terminal 200. In some embodiments, the angular velocity of the terminal 200 around three axes (i.e., x, y, and z axes) can be determined by the gyro sensor 280B. The gyro sensor 280B can be used for anti-shake shooting. Exemplarily, when the shutter is pressed, the gyro sensor 280B detects the angle of the terminal 200 shaking, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to offset the shaking of the terminal 200 through reverse movement to achieve anti-shake. The gyro sensor 280B can also be used for navigation and somatosensory game scenes.

[0148] The air pressure sensor 280C is used to measure air pressure. In some embodiments, the terminal 200 calculates the altitude through the air pressure value measured by the air pressure sensor 280C to assist positioning and navigation.

[0149] The magnetic sensor 280D includes a Hall sensor. The terminal 200 can use the magnetic sensor 280D to detect the opening and closing of the flip leather case. In some embodiments, when the terminal 200 is a flip phone, the terminal 200 can detect the opening and closing of the flip cover according to the magnetic sensor 280D. Then, according to the detected opening and closing state of the leather case or the opening and closing state of the flip cover, the flip cover automatic unlocking and other features are set.

[0150] The acceleration sensor 280E can detect the magnitude of the acceleration of the terminal 200 in various directions (generally three axes). When the terminal 200 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the terminal posture and is applied to applications such as horizontal and vertical screen switching and pedometers.

[0151] The distance sensor 280F is used to measure the distance. The terminal 200 can measure the distance by infrared or laser. In some embodiments, when shooting a scene, the terminal 200 can use the distance sensor 280F to measure the distance to achieve fast focusing.

[0152] The proximity light sensor 280G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The terminal 200 emits infrared light outward through the light emitting diode. The terminal 200 uses a photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that there is an object near the terminal 200. When insufficient reflected light is detected, the terminal 200 can determine that there is no object near the terminal 200. The terminal 200 can use the proximity light sensor 280G to detect that the user holds the terminal 200 close to the ear to talk, so as to automatically turn off the screen to save power. The proximity light sensor 280G can also be used in leather case mode and pocket mode to automatically unlock and lock the screen.

[0153] The ambient light sensor 280L is used to sense the ambient light brightness. The terminal 200 can adaptively adjust the brightness of the display screen 294 according to the perceived ambient light brightness. The ambient light sensor 280L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 280L can also cooperate with the proximity light sensor 280G to detect whether the terminal 200 is in a pocket to prevent accidental touch.

[0154] The fingerprint sensor 280H is used to collect fingerprints. The terminal 200 can use the collected fingerprint characteristics to achieve fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

[0155] The temperature sensor 280J is used to detect temperature. In some embodiments, the terminal 200 uses the temperature detected by the temperature sensor 280J to execute a temperature processing strategy. For example, when the temperature reported by the temperature sensor 280J exceeds a threshold, the terminal 200 performs a reduction in the performance of a processor located near the temperature sensor 280J to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is lower than another threshold, the terminal 200 heats the battery 242 to avoid abnormal shutdown of the terminal 200 due to low temperature. In other embodiments, when the temperature is lower than another threshold, the terminal 200 performs a boost on the output voltage of the battery 242 to avoid abnormal shutdown caused by low temperature.

[0156] The touch sensor 280K is also called a "touch control device". The touch sensor 280K can be set on the display screen 294. The touch sensor 280K and the display screen 294 form a touch screen, also called a "touch control screen". The touch sensor 280K is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 294. In other embodiments, the touch sensor 280K can also be set on the surface of the terminal 200, which is different from the position of the display screen 294.

[0157] The bone conduction sensor 280M can obtain a vibration signal. In some embodiments, the bone conduction sensor 280M can obtain a vibration signal of a vibrating bone block of the vocal part of the human body. The bone conduction sensor 280M can also contact the human pulse to receive a blood pressure beat signal. In some embodiments, the bone conduction sensor 280M can also be set in an earphone and combined into a bone conduction earphone. The audio module 270 can parse out a voice signal based on the vibration signal of the vibrating bone block of the vocal part obtained by the bone conduction sensor 280M to realize a voice function. The application processor can parse the heart rate information based on the blood pressure beat signal obtained by the bone conduction sensor 280M to realize a heart rate detection function.

[0158] The key 290 includes a power key, a volume key, etc. The key 290 may be a mechanical key or a touch key. The terminal 200 may receive key input and generate key signal input related to user settings and function control of the terminal 200.

[0159] Motor 291 can generate vibration prompts. Motor 291 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. For touch operations acting on different areas of the display screen 294, motor 291 can also correspond to different vibration feedback effects. Different application scenarios (for example: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0160] Indicator 292 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0161] The SIM card interface 295 is used to connect the SIM card. The SIM card can be connected to and separated from the terminal 200 by inserting it into the SIM card interface 295 or pulling it out from the SIM card interface 295. The terminal 200 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 295 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 295 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 295 can also be compatible with different types of SIM cards. The SIM card interface 295 can also be compatible with external memory cards. The terminal 200 interacts with the network through the SIM card to realize functions such as calls and data communications. In some embodiments, the terminal 200 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the terminal 200 and cannot be separated from the terminal 200.

[0162] The software system of the terminal 200 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention takes the Android system of the layered architecture as an example to exemplify the software structure of the terminal 200.

[0163] Figure 8 It is a communication architecture diagram of a terminal 200 according to an embodiment of the present application.

[0164] like Figure 8 As shown, to support the communication function of the terminal, the terminal 200 at least includes an application layer, an application framework layer, a radio interface layer (RIL) and a modem processor layer.

[0165] The application layer can include a series of application packages.

[0166] like Figure 8 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc.

[0167] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0168] like Figure 8 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0169] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0170] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0171] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0172] The phone manager is used to provide communication functions of the terminal 200, such as management of call status (including connection, disconnection, etc.).

[0173] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0174] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, the terminal vibrates, the indicator light flashes, etc.

[0175] The RIL layer may include a SIM card module, a data module, a call module, and the like.

[0176] The modem processing layer may include an IMS protocol stack, an IP layer, a link layer, and a physical layer. The modem processing layer may use a modem processor or a cellular processor (CP).

[0177] Among them, the modem processing layer is mainly used to realize the interaction between the terminal and the network 50. For example, the IMS protocol stack in the modem processor layer realizes the sending and receiving of SIP signaling through the IP layer, link layer, physical layer and antenna, and then performs signaling interaction at the IMS protocol level with the IMS core network in the network 50.

[0178] The call processing method provided in the embodiment of the present application is described in detail below with reference to the accompanying drawings.

[0179] Fig. 9A flowchart of a call processing method provided in an embodiment of the present application. Fig. 9 As shown, the method may include the following steps:

[0180] S301 , the calling terminal 10 sends a call request signaling Invite to the called terminal 20 through the network 50 .

[0181] S302 , the called terminal 20 sends a SIP signaling 100 Trying to the calling terminal 10 through the network 50 .

[0182] S303 , the called terminal 20 sends a SIP signaling 180 Ringing to the calling terminal 10 through the network 50 .

[0183] The above steps S301-S303 can refer to the description of steps S101-S103, which will not be repeated here.

[0184] It should be noted that other SIP signaling interactions may be included between steps S302 and S303, for example, SIP signaling for negotiating media capabilities and resource reservation processes, for details of which please refer to related technologies and will not be described in detail here.

[0185] S304, the network 50 determines whether the called terminal 20 has timed out and has not answered the call.

[0186] After the called terminal 20 sends the SIP signaling 180Ringing, the network 50 waits for the called terminal 20 to answer the call. Usually, the network 50 does not wait for the terminal 20 to answer the call indefinitely, but sets a waiting time. If the called terminal 20 does not answer the call within the waiting time, the network 50 sends a Cancel message to the called terminal 20.

[0187] It should be noted that if the network 50 determines that the called terminal 20 has answered the call, it can refer to Figure 2 The process of answering the call is not described here.

[0188] If the network 50 determines that the called terminal 20 does not answer the call after the timeout, the network 50 sends a Cancel message to the called terminal 20. The Cancel message sent by the network 50 to the called terminal 20 may include the following three situations. These three situations are introduced below.

[0189] Case 1: The Cancel message does not carry the Reason header field.

[0190] S305: The Cancel message sent by the network 50 to the called terminal 20 does not carry a Reason header field.

[0191] First, it should be noted that the network 50 has the ability to identify whether the called terminal 20 meets the one-number-multiple-terminals scenario. Specifically, the method for the network 50 to identify whether the called terminal 20 meets the one-number-multiple-terminals scenario can be found in the relevant technology and will not be repeated here.

[0192] For example, the network 50 identifies that the called terminal 20 does not meet the one-number-multiple-terminal scenario, that is, the called terminal 20 is not a one-number-multiple-terminal. Fig. 9 As shown in situation 1, the Cancel message sent by the network 50 to the called terminal 20 may not carry the Reason header field.

[0193] S306: Based on the Cancel message sent in step S305, the called terminal 20 interprets the Cancel message as a missed call.

[0194] In some embodiments, after receiving the Cancel message, the called terminal 20 may first determine whether the Cancel message carries a Reason header field. If the called terminal 20 determines that the Cancel message does not carry a Reason header field, the called terminal 20 interprets the Cancel message as a missed call.

[0195] Case 2: The Cancel message carries the Reason header field.

[0196] In the embodiment of the present application, the Reason header field carried in the Cancel message may or may not conform to the Reason header field explicitly specified in the protocol.

[0197] Exemplarily, the Reason header field carried in the Cancel message may include the following three situations:

[0198] S307a (the first case), the Cancel message sent by the network 50 to the called terminal 20 carries a Reason header field, and the Reason header field may be: Reason: SIP; cause=200; text=“Decline”.

[0199] S307b (second case), the Cancel message sent by the network 50 to the called terminal 20 carries a Reason header field, and the Reason header field may be: Reason: SIP; cause = 200, text = "Call Completed Elsewhere".

[0200] S307c (the third case), the Cancel message sent by the network 50 to the called terminal 20 carries a Reason header field, and the Reason header field may be: Reason: SIP; cause = 200, text = "Call completed elsewhere".

[0201] It can be seen that the Reason header field does not conform to the Reason header field specified in the protocol, which can include the following two situations:

[0202] In the first case, the combination of the cause field and the text field is not explicitly specified in the protocol.

[0203] Exemplarily, the Reason header field is carried in the Cancel message sent by the network 50 to the called terminal 20 in step S307a.

[0204] In the second case, the combination of the cause field and the text field is as specified in the protocol. However, the capitalization of the English description in the text field is different from that specified in the protocol.

[0205] Exemplarily, the Reason header field is carried in the Cancel message sent by the network 50 to the called terminal 20 in step S307b.

[0206] By comparing the "Reason: SIP; cause = 200, text = Call completed elsewhere" clearly specified in the protocol and "Reason: SIP; cause = 200, text = Call Completed Elsewhere", it can be seen that the meanings explained in the text fields of the two are the same, but the uppercase and lowercase letters used in the text fields of the two are different. In this case, the embodiment of the present application can determine that Reason: SIP; cause = 200, text = "Call Completed Elsewhere" does not comply with the protocol regulations.

[0207] It should be noted that the above embodiment only uses the Reason header field: Reason: SIP; cause = 200; text = "Decline" as an example of the first case, and does not limit this. For example, the first case may also include Reason: SIP; cause = 200; text = "Deject", etc., which are not listed here one by one.

[0208] It should also be noted that the above embodiment only uses the Reason header field: Reason: SIP; cause = 200, text = "Call Completed Elsewhere" as an example of the second case, and does not limit this. For example, the second case may also include: Reason: SIP; cause = 200; text = "Call Completed elsewhere", etc., which are not listed here one by one.

[0209] It should also be noted that the above embodiment only uses the Reason header field: Reason: SIP; cause = 200, text = "Call completed elsewhere" as an example of the third case, and does not limit this. For example, the third case may also include: Reason: SIP; cause = 603; text = "Declined", etc., which are not listed here one by one.

[0210] S308: The called terminal 20 determines whether the Reason header field complies with the protocol specification.

[0211] After receiving the Cancel message, the called terminal 20 can determine the Reason header field carried in the Cancel message, and then further determine whether the Reason header field carried in the Cancel message complies with the protocol specification.

[0212] In one achievable manner, determining whether the Reason header field carried by the Cancel message complies with the protocol provisions can be implemented in the following manner: first, based on the protocol field, determine the target protocol corresponding to the Reason header field (for example, the target protocol is the SIP protocol). Then, determine whether the target protocol includes a field combination of the cause field and the text field in the Reason header field. In the case where the target protocol includes a field combination of the cause field and the text field in the Reason header field, determine that the Reason header field is the Reason header field specified in the target protocol; in the case where the target protocol does not include a field combination of the cause field and the text field in the Reason header field, determine that the Reason header field is not the Reason header field specified in the target protocol.

[0213] In one possible implementation, determining whether the Reason header field carried by the Cancel message complies with the protocol provisions can also be implemented in the following manner: the called terminal 20 can pre-establish the correspondence between various Reason header fields and interpretations that are clearly specified in the protocol. Exemplarily, the correspondence between the Reason header field and the interpretation can be recorded in a table. As shown in Table 1, the called terminal 20 can pre-establish the correspondence shown in Table 1, and Table 1 can record all Reason header fields that are clearly specified in the protocol.

[0214] In this way, after the called terminal 20 determines the Reason header field carried by the Cancel message, it can determine whether the Reason header field carried by the Cancel message belongs to the Reason header field in Table 1 by looking up Table 1. If the Reason header field carried by the Cancel message belongs to the Reason header field in Table 1, the called terminal 20 determines that the Reason header field complies with the protocol provisions. If the Reason header field carried by the Cancel message does not belong to the Reason header field in Table 1, the called terminal 20 determines that the Reason header field does not comply with the protocol provisions.

[0215] Table 1 Correspondence between Reason header field and interpretation

[0216] Reason header field specified in the protocol Interpretation Reason: SIP; cause=200; text="Call completed elsewhere" Other devices answer Reason: SIP; cause=603; text="Declinated" Missed

[0217] It should be noted that, to determine whether the Reason header field carried by the Cancel message meets the standards specified by the protocol, reference can be made to the description of steps S307a, S307b, and S307c, which will not be repeated here. For example, the Reason header fields carried by S307a and S307b do not meet the protocol requirements, while the Reason header field carried by S307c meets the protocol requirements.

[0218] S309, if the Reason header field does not comply with the protocol specification, the called terminal 20 determines whether the Reason header field satisfies cause = 200; and text = "Call completed elsewhere", wherein the content in the text field is not case sensitive.

[0219] In some embodiments, the Reason header field is the first case corresponding to step S307a. For example, the Reason header field carried by the Cancel message is as follows: Reason: SIP; cause = 200, text = "Decline".

[0220] In this case, the Reason header field carried by the Cancel message also does not satisfy cause = 200; and text = "Call completed elsewhere".

[0221] In some embodiments, the Reason header field is the second case corresponding to step S307b. For example, the Reason header field carried by the Cancel message is as follows: Reason: SIP; cause = 200, text = "Call Completed Elsewhere".

[0222] It can be understood that the explanation of the response in the Reason header field is that the call was answered by another device. The embodiment of the present application is to avoid interpreting the second situation as not answering the call, which affects the user experience. When it is determined that the Reason header field does not comply with the protocol, the called terminal 20 further determines whether the Reason header field satisfies cause = 200; and text = "Call completed else where", where the content in the text field is not case sensitive.

[0223] Thus, in the embodiment of the present application, the Reason header field is as follows: Reason: SIP; cause = 200, text = "CallCompleted Elsewhere", which does not comply with the protocol requirements, but satisfies the judgment condition: cause = 200; and text = "Callcompleted elsewhere", wherein the content in the text field is not case sensitive.

[0224] S310, if the Reason header field does not satisfy cause = 200; and text = "Call completed else where", where the content in the text field is not case sensitive, the called terminal 20 interprets the Cancel as a missed call.

[0225] For example, Fig. 9 As shown, corresponding to the first case, if the Reason header field carried in the Cancel received by the called terminal is Reason: SIP; cause = 200; text = "Decline". The Reason header field does not comply with the protocol requirements, nor does it satisfy cause = 200; and text = "Call completed elsewhere". Therefore, in the embodiment of the present application, the called terminal interprets this Cancel as a missed call.

[0226] Thus, compared with the related art, based on cause=200, such Cancel is interpreted as other devices answering the call. The solution provided by the embodiment of the present application can correctly interpret Cancel in the first case, thereby improving user experience.

[0227] S311, if the Reason header field satisfies cause = 200; and text = "Call completed elsewhere", the called terminal 20 interprets the Cancel as being answered by another device.

[0228] For example, Fig. 9 As shown, corresponding to the second case, if the Reason header field carried in the Cancel received by the called terminal is Reason: SIP; cause = 200, text = "Call Completed Elsewhere". Although the Reason header field does not comply with the protocol, it satisfies cause = 200; and text = "Call completed elsewhere", where the content in the text field is case insensitive. Therefore, in the embodiment of the present application, the called terminal interprets this Cancel as being answered by another device.

[0229] In this way, the solution provided in the embodiment of the present application can also correctly interpret Cancel in the second case and improve user experience.

[0230] S312: If the Reason header field complies with the protocol requirements, the Cancel clause is interpreted based on the protocol requirements.

[0231] For example, Fig. 9 As shown, corresponding to the third case, if the Reason header field carried in the Cancel received by the called terminal is Reason: SIP; cause = 200, text = "Call completed elsewhere", the Reason header field complies with the protocol regulations. Therefore, in the embodiment of the present application, the called terminal interprets this Cancel based on the provisions of the protocol.

[0232] For example, for the Reason header field Reason: SIP; cause = 200, text = "Call completed elsewhere" specified in the protocol, the called terminal interprets it as the call is answered by another device based on the provisions in the protocol.

[0233] For another example, for the Reason header field Reason: SIP; cause = 603; text = "Declined" specified in the protocol, the called terminal interprets it as not answering the call based on the provisions in the protocol.

[0234] In this way, the solution provided in the embodiment of the present application can also correctly interpret Cancel in the third case and improve user experience.

[0235] S313, the called terminal 20 displays the corresponding interpretation content on the call record interface.

[0236] For example, in a non-one-number-multiple-terminal scenario, if the called terminal 20 does not answer the call of the calling terminal 10, the Cancel message sent by the network 50 to the called terminal 20 may be Fig. 9 In the first case (S307a), based on the method provided in the embodiment of the present application, it is interpreted as not answering the call. Fig.10 As shown, the corresponding interpretation content "Missed" is displayed in the call record interface.

[0237] So, by contrast Figure 6 and Fig.10 It can be seen that by adopting the method provided in the embodiment of the present application, the correct interpretation content can be displayed on the call record interface of the called terminal, which will not cause trouble to the user and improve the user experience.

[0238] It should be noted that the above embodiment is only an example of executing step S308 before step S309, and does not limit the call processing method provided in the embodiment of the present application. Considering that only cause = 200, text = "Call completed elsewhere" is currently included, it conforms to the interpretation of other devices answering. Therefore, the call processing method provided in the embodiment of the present application may not include step S308 and step S312.

[0239] Considering that if new regulations are added to the protocol in the future regarding the scenario in which his device answers the call, the solution including step S308 and step S312 provided in the embodiment of the present application will still be applicable.

[0240] In summary, in the call processing method provided in the embodiment of the present application, after the called terminal receives the Cancel message sent by the network, if the Reason header field carried in the Cancel message meets the conditions specified in the protocol, it is interpreted based on the protocol provisions. If the Reason header field carried in the Cancel message does not meet the conditions specified in the protocol, only the Reason header field that satisfies cause = 200; and text = "Call completed elsewhere", where the case-insensitive content in the text field is interpreted as other devices answering the call; other conditions that do not meet the conditions specified in the protocol are interpreted as not answering the call. In this way, the interpretation method provided in the embodiment of the present application can correctly interpret the Cancel message in any situation, thereby improving the user experience.

[0241] The embodiment of the present application does not limit the module that specifically performs the interpretation operation in the called terminal.

[0242] In a feasible way, please combine Fig. 9 and Fig.11A After the IMS protocol stack of the called terminal receives the Cancel message, the IMS protocol stack can execute steps S306 to S312 to parse and interpret the Cancel message. After the IMS protocol stack interprets the message, it obtains the interpretation content and transmits the interpretation content to be displayed to the call application of the application layer through the RIL layer and the application framework layer. Specifically, the display of the interpretation content can be realized by the call record submodule in the call application. The interpretation content can be that the other device answered or did not answer the call.

[0243] In one possible implementation, please combine Fig. 9 and Fig. 11B After the IMS protocol stack of the called terminal receives the Cancel message, it can parse the Cancel message to obtain the Reason header field carried by the Cancel message. Then, the IMS protocol stack transmits the cause value and text content in the Reason header field to the call module of the RIL layer. The call module can interpret the received cause value and text content, obtain the interpretation content, and transmit the interpretation content to the call application of the application layer through the application framework layer. Specifically, the display of the interpretation content can be realized by the call record submodule in the call application. Alternatively, the IMS protocol stack can also transmit the cause value and text content in the Reason header field to the telephone manager of the application framework layer through the RIL layer. Then, the telephone manager interprets based on the received cause value and text content, obtains the interpretation content, and transmits the interpretation content to the call application of the application layer. Specifically, the display of the interpretation content can be realized by the call record submodule in the call application.

[0244] In one possible implementation, please combine Fig. 9 and Fig. 11C After receiving the Cancel message, the IMS protocol stack of the called terminal can parse the Cancel message to obtain the Reason header field carried by the Cancel message. Then, the IMS protocol stack transmits the cause value and text content in the Reason header field to the call application of the application layer through the RIL layer and the application framework layer. Specifically, the call record submodule in the call application can interpret the received cause value and text content, obtain the interpretation content, and display the interpretation content.

[0245] Fig.12 A flowchart of a call processing method provided in an embodiment of the present application is shown in FIG. Fig.12 As shown, the method may include the following steps:

[0246] S401: Receive a call connection request from a calling terminal.

[0247] S402: When the called terminal fails to establish a call connection with the calling terminal within a preset time period, a Cancel message sent by the network is received, and the Cancel message carries a Reason header field.

[0248] S403: When the cause field and the text field in the Reason header field meet the target field combination condition, determine that the interpretation corresponding to the Cancel message is the first interpretation.

[0249] S404: When the cause field and the text field in the Reason header field do not satisfy the target field combination condition, determine that the interpretation corresponding to the Cancel message is the second interpretation; wherein the first interpretation is different from the second interpretation.

[0250] S405: Displaying the definition of the Cancel message on the call record interface of the called terminal.

[0251] In an implementable manner, when the Reason header field is not the Reason header field specified by the target protocol and the cause field and the text field in the Reason header field meet the target field combination condition, it is determined that the interpretation corresponding to the Cancel message is the first interpretation.

[0252] In an implementable manner, when the Reason header field is not the Reason header field specified by the target protocol and the cause field and the text field in the Reason header field do not meet the target field combination condition, it is determined that the interpretation corresponding to the Cancel message is the second interpretation.

[0253] In one achievable manner, the target field combination condition includes a cause field of cause=200 and a text field of text=“Call completed elsewhere”, wherein the text field does not distinguish between uppercase English letters and lowercase English letters.

[0254] In an implementable manner, the first interpretation is used to indicate that other called terminals answer the call, and the second interpretation is used to indicate that none of the called terminals answer the call; wherein the other called terminals refer to terminals that have applied for a one-number-multiple-terminals service with the called terminal.

[0255] In an implementable manner, the first interpretation is that the call is answered by another device, and the second interpretation is that the call is not answered.

[0256] In an implementable manner, the Reason header field also includes a protocol field, and the method further includes: determining a target protocol corresponding to the Reason header field based on the protocol field; when the target protocol includes a field combination of a cause field and a text field in the Reason header field, determining that the Reason header field is a Reason header field specified in the target protocol; when the target protocol does not include a field combination of a cause field and a text field in the Reason header field, determining that the Reason header field is not a Reason header field specified in the target protocol.

[0257] In an implementable manner, the method further includes: obtaining a preset mapping relationship, the preset mapping relationship including a correspondence between a Reason header field and an interpretation specified in a protocol; in the case where the preset mapping relationship includes a field combination of a cause field and a text field in the Reason header field, determining that the Reason header field is a Reason header field specified in a target protocol; in the case where the preset mapping relationship does not include a field combination of a cause field and a text field in the Reason header field, determining that the Reason header field is not a Reason header field specified in a target protocol. The preset mapping relationship may be a correspondence relationship table as shown in Table 1, and the specifics may refer to the description of Table 1 in the above embodiment, which will not be repeated here.

[0258] In an implementable manner, the method further includes: when the Reason header field is a Reason header field specified by the target protocol, determining a corresponding interpretation of the Reason header field based on a preset mapping relationship.

[0259] In one possible implementation, the Reason header field specified by the target protocol includes: Reason: SIP; cause=200; text=“Call completed elsewhere”, and Reason: SIP; cause=603; text=“Declined”.

[0260] It should be noted that the above Fig.12 The call processing method shown can be referred to above Figure 1 to Figure 1 1 The description of the corresponding embodiment will not be repeated here.

[0261] The various method embodiments described in this document may be independent solutions or may be combined according to internal logic, and these solutions all fall within the protection scope of this application.

[0262] It can be understood that, in the above-mentioned various method embodiments, the methods and operations implemented by the terminal can also be implemented by components (such as chips or circuits) that can be used in the terminal.

[0263] The above embodiments introduce the call processing method provided by the present application. It is understandable that, in order to implement the above functions, the terminal includes a hardware structure and / or software module corresponding to each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0264] The embodiment of the present application further provides a processing device, which includes at least one processor and a communication interface. The communication interface is used to provide information input and / or output to the at least one processor, and the at least one processor is used to execute the method in the above method embodiment.

[0265] It should be understood that the above-mentioned processing device can be a chip. Fig.13 , Fig.13 A structural block diagram of a chip provided in an embodiment of the present application. Fig.13 The chip shown may be a general-purpose processor or a dedicated processor. The chip 500 may include at least one processor 501. The at least one processor 501 may be used to support execution Figures 1 to 12 The technical solution shown in any one of the embodiments.

[0266] Optionally, the chip 500 may further include a transceiver 502, which is used to accept the control of the processor 501 and to support the execution Figures 1 to 12 The technical solution shown in any one of the embodiments. Optionally, Figure 5 The chip 500 shown may further include a storage medium 503. Specifically, the transceiver 502 may be replaced by a communication interface, and the communication interface provides information input and / or output for the at least one processor 501.

[0267] It should be noted that Fig.13 The chip 500 shown can be implemented using the following circuits or devices: one or more field programmable gate arrays (FPGA), programmable logic devices (PLD), application specific integrated circuits (ASIC), system on chip (SoC), central processor unit (CPU), network processor (NP), digital signal processor (DSP), micro controller unit (MCU), controller, state machine, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described throughout this application.

[0268] In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in a processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it is not described in detail here.

[0269] It can be understood that the memory in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0270] According to the method provided in the embodiments of the present application, the embodiments of the present application also provide a computer program product, which includes: a computer program or instructions, when the computer program or instructions are run on a computer, the computer executes the method of any one of the embodiments of the method.

[0271] According to the method provided by the embodiments of the present application, the embodiments of the present application also provide a computer storage medium, which stores a computer program or instructions. When the computer program or instructions are run on a computer, the computer executes the method of any one of the embodiments of the method.

[0272] According to the method provided by the embodiment of the present application, the embodiment of the present application also provides a terminal, including a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code includes computer instructions, and when the processor executes the computer instructions, the terminal executes the method of any one of the embodiments of the method embodiment.

[0273] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems, device modules and electronic devices can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0274] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative, for example, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0275] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0276] The above-mentioned embodiments of the present application provide a call processing device, a chip, a computer storage medium, a computer program product, and a terminal, all of which are used to execute the method provided above. Therefore, the beneficial effects that can be achieved can refer to the corresponding beneficial effects of the method provided above, and will not be repeated here.

[0277] It should be understood that in each embodiment of the present application, the execution order of each step should be determined by its function and internal logic, and the size of the sequence number of each step does not mean the order of execution and does not limit the implementation process of the embodiment.

[0278] Each part of this specification is described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the call processing device, system, chip, computer storage medium, computer program product, and terminal, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0279] Although the preferred embodiments of the present application have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0280] The above-described embodiments of the present application do not constitute a limitation on the protection scope of the present application.

Claims

1. A call processing method, characterized in that: The method is applied to the called terminal, and the method comprises: Receiving a call connection request from a calling terminal; If the called terminal fails to establish a call connection with the calling terminal within a preset time period, receiving a Cancel message sent by the network, wherein the Cancel message carries a Reason header field; In the case where the cause field and the text field in the Reason header field meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is the first interpretation; wherein the target field combination condition includes that the cause field is cause=200, the text field is text="Call completed elsewhere", the text field does not distinguish between uppercase English letters and lowercase English letters, and the first interpretation is used to indicate that the call is answered by other called terminals, and the other called terminals refer to terminals that have applied for a one-number-multiple-terminals service with the called terminal; When the cause field and the text field in the Reason header field do not satisfy the target field combination condition, determining that the interpretation corresponding to the Cancel message is the second interpretation; wherein the second interpretation is used to indicate that all called terminals have not answered the call; and the first interpretation is different from the second interpretation; The definition corresponding to the Cancel message is displayed on the call record interface of the called terminal.

2. The method according to claim 1, characterized in that When the cause field and the text field in the Reason header field meet the target field combination condition, determining that the interpretation corresponding to the Cancel message is the first interpretation includes: When the Reason header field is not a Reason header field specified by the target protocol, and the cause field and the text field in the Reason header field meet the target field combination condition, it is determined that the interpretation corresponding to the Cancel message is the first interpretation.

3. The method according to claim 1, characterized in that: When the cause field and the text field in the Reason header field do not satisfy the target field combination condition, determining that the interpretation corresponding to the Cancel message is the second interpretation includes: When the Reason header field is not a Reason header field specified by the target protocol, and the cause field and the text field in the Reason header field do not meet the target field combination condition, it is determined that the interpretation corresponding to the Cancel message is the second interpretation.

4. The method according to claim 2 or 3, characterized in that: The Reason header field also includes a protocol field, and the method further includes: Determine the target protocol corresponding to the Reason header field based on the protocol field; In a case where the target protocol includes a field combination of the cause field and the text field in the Reason header field, determining that the Reason header field is a Reason header field specified in the target protocol; In a case where the target protocol does not include a field combination of the cause field and the text field in the Reason header field, it is determined that the Reason header field is not a Reason header field specified in the target protocol.

5. The method according to claim 2 or 3, characterized in that: The method further comprises: Obtaining a preset mapping relationship, where the preset mapping relationship includes a correspondence between a Reason header field and an interpretation specified in the protocol; In a case where the preset mapping relationship includes a field combination of the cause field and the text field in the Reason header field, determining that the Reason header field is a Reason header field specified in the target protocol; When the preset mapping relationship does not include a field combination of the cause field and the text field in the Reason header field, it is determined that the Reason header field is not a Reason header field specified in the target protocol.

6. The method according to claim 5, characterized in that The method further comprises: In a case where the Reason header field is a Reason header field specified by the target protocol, a definition corresponding to the Reason header field is determined based on the preset mapping relationship.

7. The method according to claim 2 or 3, characterized in that: The Reason header field specified by the target protocol includes: Reason: SIP; cause = 200; text = "Call completed elsewhere", and Reason: SIP; cause = 603; text = "Declined".

8. A terminal, characterized in that: The terminal includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the terminal executes the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program or instruction. When the computer program or instruction is executed on a computer, the computer executes the method according to any one of claims 1 to 7.

Images