Call method and terminal equipment

Abstract

The invention discloses a call method and terminal equipment, and relates to the technical field of communication. The method comprises the steps that the terminal equipment receives a first invitation message, and the first invitation message is related to a first call; and the terminal equipment receives the answering operation. And in response to the answering operation, the terminal device sends a first answering message. And under the condition that the terminal equipment subscribes to the polyphonic ringtone service, the terminal equipment receives a second invitation message, wherein the second invitation message is related to the first call. And the terminal equipment sends a second answering message, the second answering message does not carry a protocol SDP describing the session, or the second answering message carries the first SDP, and the first SDP carries the first voice coding and decoding format. And the terminal equipment plays the call voice of the first call in a voice coding and decoding format negotiated with the network side equipment after receiving the first invitation message and before receiving the second invitation message. Therefore, the success rate of call answering can be improved.

Description

[0001] This application claims the priority of a Chinese patent application titled "A Call Method" with the application number 202410054709.3 filed with the National Intellectual Property Administration on January 12, 2024, the entire content of which is incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technologies, and in particular, to a call method and a terminal device. Background Art

[0003] Among terminal devices such as mobile phones and tablets, making and receiving calls is one of the most basic functions. Usually, a terminal device can actively make a call to another terminal device or receive a passive call from another terminal device.

[0004] In the scenario where a terminal device receives a fixed-line call (referred to as a landline for short, also known as a wired telephone, landline phone, etc.) or an Internet Protocol (IP) call (such as a call like 95030, hereinafter collectively referred to as the fixed-network call scenario), after the terminal device receives the user's answer operation, there may be a situation where there is no sound during the call and the call is automatically hung up after a period of time. Summary of the Invention

[0005] In view of this, embodiments of this application provide a call method and a terminal device, which can improve the success rate of call connection.

[0006] In a first aspect, an embodiment of this application provides a call method, including: the terminal sends a 200OK message to the network again, and the 200OK message does not carry SDP (in some implementations, not carrying SDP can be understood as not carrying codec); the terminal receives an ACK sent by the network after receiving the 200OK message. It can be understood that after receiving the 200OK message, the network will no longer verify the codec and will reply with a normal ACK, so the call can be connected normally.

[0007] In one implementation, before the terminal sends the 200OK message to the network again, the method further includes:

[0008] The terminal receives a first invite message sent by the network, and a first set is carried in the first invite message, and the first set is a codec set of voice encoding and decoding formats supported by the network;

[0009] After receiving the first INVITE message, the terminal sends a 183 message to the network, and a second set is carried in the 183 message, where the second set is a set of codecs supported by the terminal in the first set;

[0010] After receiving a first operation of the user on the terminal, the terminal sends a 200OK message to the network, and no SDP is carried in the 200OK message, where the first operation is used to instruct the terminal to answer an incoming call;

[0011] The terminal receives a second INVITE message sent by the network after receiving the 200OK message, and no SDP is carried in the second INVITE message;

[0012] Wherein, the terminal sending the 200OK message to the network again includes:

[0013] After receiving the second INVITE message, the terminal sends the 200OK message to the network again, and no SDP is carried in the 200OK message.

[0014] In a second aspect, an embodiment of the present application provides a call method, including: the terminal sends a 200OK to the network again, and a third set is carried in the 200OK message, where the third set is a set composed of some or all of the codecs in the set of voice codec formats supported by the terminal, and the codecs included in the third set are some or all of the codecs included in the set of codecs carried in the 183 message received by the terminal before sending the 200OK message; the terminal receives an ACK sent by the network after receiving the 200OK message. It can be understood that the network has verified the codecs in 183, so the network will reply with a normal ACK after receiving the 200OK message, and thus the call can be connected normally.

[0015] In some implementation manners, before the terminal sends the 200OK message to the network again, the method further includes:

[0016] The terminal receives a first INVITE message sent by the network, and a first set is carried in the first INVITE message, where the first set is a set of voice codec formats supported by the network;

[0017] After receiving the first INVITE message, the terminal sends a 183 message to the network, and a second set is carried in the 183 message, where the second set is a set of codecs supported by the terminal in the first set;

[0018] After the terminal receives a first operation by a user on the terminal, the terminal sends a 200OK message to the network, where the 200OK message does not carry an SDP, and the first operation is used to instruct the terminal to answer an incoming call;

[0019] The terminal receives a second invite message sent by the network after receiving the 200OK message, where the second invite message does not carry an SDP;

[0020] Among them, the terminal sending the 200OK message to the network again includes:

[0021] After receiving the second invite message, the terminal sends the 200OK message to the network again, and the 200OK message carries the third set;

[0022] Among them, the codecs included in the third set are some or all of the codecs included in the codec set carried in the 183 message received by the terminal before sending the 200OK message, including: the codecs included in the third set are some or all of the codecs included in the second set.

[0023] In some implementation manners, the first invite message is used to call the terminal.

[0024] In a third aspect, an embodiment of the present application provides a call method applied to a terminal device, where the terminal device is a called terminal device, such as the terminal device 200 in the following text.

[0025] Specifically, the terminal device receives a first invitation message (such as the call invitation in S702 below), the first invitation message is related to a first call (such as a call with the called number being the telephone number 1 below), and the first call is used to call the terminal device. The terminal device receives an answer operation, such as a click operation by the user on the answer button. In response to the answer operation, the terminal device sends a first answer message, such as the answer message 1 in the following text.

[0026] In the case where the terminal device subscribes to the CRBT service: After sending the first answer message, the terminal device receives a second invitation message (such as the repeated invitation in the following text), and the second invitation message is also related to the first call. That is to say, for the same call, two call invitations are initiated. After the terminal device receives the second invitation message, the terminal device sends a second answer message. The second answer message does not carry the protocol SDP describing the session, such as the answer message 3 in the following text. It can be understood that the voice codec format is usually carried by the SDP. If the second answer message does not carry the SDP, it means that the second answer message does not carry the voice codec format. Alternatively, the second answer message carries a first SDP, and the first SDP carries a first voice codec format, such as the answer message 3 in the following text. The first voice codec format is the voice codec format negotiated between the terminal device and the network-side device after the terminal device receives the first invitation message and before receiving the second invitation message. Among them, the network-side device can be the general term of the network device_3 and the CRBT server in the following text, or can refer to the network device_3 alone. This application does not make specific limitations on this. The terminal device plays the call voice of the first call using the first voice codec format.

[0027] In summary, by adopting this application, in the case where the terminal device subscribes to the CRBT service, after the terminal device receives a repeated invitation, that is, the second invitation message, the terminal device will not send an answer message carrying all the voice codec formats supported by the terminal device, such as the answer message 2 in the following text, but will send an answer message that does not carry the voice codec format or only carries the first voice codec format that has been negotiated with the network-side device. By adopting this solution, after receiving the second answer message, the network-side device will not verify that the voice codec format in the second answer message is inconsistent with the voice codec format supported by the network-side device, and thus will not feedback an indication message of call activation failure to the terminal device. In this way, the terminal device can use the first voice codec format that has been negotiated with the network-side device for voice calls, and the call answer will not fail because the voice codec formats supported by the network-side device and the terminal device are inconsistent, improving the success rate of call answering.

[0028] In a possible implementation manner of the third aspect, the second answer message does not carry the SDP, corresponding to the answer message 3 in the following text. After the terminal device sends the second answer message, the above method further includes: The terminal device receives a first confirmation message (such as the confirmation message 3 in the following text), and the first confirmation message does not carry the SDP. The first confirmation message is a confirmation message for the second answer message.

[0029] That is to say, in the implementation manner where the second answer message does not carry the voice codec format, the first confirmation message for the second answer message fed back by the network side device naturally does not carry the SDP either. Moreover, the indication information on whether the call is successfully activated is carried in the SDP. Therefore, the first confirmation message does not include the indication information on whether the call is successfully activated. In this case, the terminal device can default to using the first voice codec format that has been negotiated with the network side device for voice calls.

[0030] In a possible implementation manner of the third aspect, the second answer message carries the first SDP, and the first SDP carries the first voice codec format, corresponding to the answer message 4 in the following text. After the terminal device sends the second answer message, the method further includes: the terminal device receives a second confirmation message from the network side device (such as the confirmation message 4 in the following text), the second confirmation message carries the second SDP, the second SDP carries the first indication information (such as active in the following text), the first indication information indicates that the first call is successfully activated, the second SDP further carries the second voice codec format, and the second voice codec format is the voice codec format supported by the network side device among the first voice codec formats.

[0031] That is to say, in the implementation manner where the second answer message carries the first voice codec format that has been negotiated with the network side device, the second confirmation message for the second answer message fed back by the network side device will carry the second SDP. On the one hand, since the first voice codec format carried in the second answer message has been negotiated with the network side device, the first voice codec format is naturally the voice codec format supported by the network side device, and the network side device can carry the first indication information in the second SDP. On the other hand, since the first voice codec format is the voice codec format supported by the network side device, the voice codec format supported by the network side device among the first voice codec formats carried in the second SDP is the first voice codec format, that is, the second voice codec format is the first voice codec format. In this case, the terminal device can use the first voice codec format carried in the second confirmation message for voice calls.

[0032] In a possible implementation manner of the third aspect, the first call is a fixed network call. Among them, a fixed network call can refer to a call where the call initiation end (such as the terminal device 100 in the following text) is a dialing terminal of a fixed telephone or an IP telephone. In other words, a fixed network call can refer to a fixed telephone call or an IP telephone call. The first invitation message carries the third SDP, and the third SDP carries the third voice codec format, such as codec2 in the following text. Among them, the third voice codec format is the voice codec format supported by both the network side device and the call initiation end.

[0033] After the terminal device receives the first invitation message and before the terminal device receives the second invitation message, the above method further includes: the terminal device sends a session progress message, and the session progress message carries a fourth SDP, and the fourth SDP carries a fourth voice codec format (such as codec3 in the following text). The fourth voice codec format is a format supported by the terminal device among the third voice codec formats. Since the third voice codec format is a voice codec format supported by both the network-side device and the call initiator, the fourth voice codec format is a voice codec format supported by the network-side device, the call initiator, and the terminal device, and of course, it is also a voice codec format supported by the network-side device and the terminal device.

[0034] It can be seen that in a fixed network call, after the terminal device receives the first invitation message and before the terminal device receives the second invitation message, the terminal device can negotiate a fourth voice codec format with the network-side device through the session progress message. That is, in a fixed network call, the voice codec format negotiated by the above terminal device with the network-side device after receiving the first invitation message and before receiving the second invitation message can be the fourth voice codec format.

[0035] In a possible implementation manner of the third aspect, the first call is a non-fixed network call. Among them, a non-fixed network call may refer to a call in which the call initiator (such as the terminal device 100 in the following text) is not a dialing terminal of a landline phone and an IP phone. In other words, a non-fixed network call may refer to a call other than a landline phone call and an IP phone call. For example, the non-fixed network call is an ordinary call received from a mobile phone.

[0036] After the terminal device receives the first invitation message and before the terminal device receives the second invitation message, the above method further includes: the terminal device sends a session progress message. That is to say, in a non-fixed network call, the voice codec format can also be negotiated through the session progress message. After that, the terminal device and the network-side device can further negotiate to obtain a new voice codec format through an update (i.e., UPDATE) message, that is, the updated negotiated voice codec format. Specifically, the terminal device can receive an update message from the network-side device, and the update message carries a fifth SDP (such as SDP5 in the following text), and the fifth SDP carries a fifth voice codec format (such as codec4 in the following text), and the fifth voice codec format is a voice codec format supported by both the network-side device and the terminal device. In this way, through the update message, the voice codec format negotiated from the session progress message can be updated to the fifth voice codec format.

[0037] It can be seen that in a non-fixed network call, after the terminal device receives the first invitation message and before it receives the second invitation message, the terminal device can negotiate with the network-side device to obtain the fifth voice codec format through an update message. That is, in a non-fixed network call, the voice codec format negotiated by the above terminal device with the network-side device after receiving the first invitation message and before receiving the second invitation message can be the fifth voice codec format.

[0038] In a possible implementation manner of the third aspect, the first invitation message and the second invitation message are INVITE / INFORMAL RESPONSE messages.

[0039] In a possible implementation manner of the third aspect, the first answer message and the second answer message are INVITE / OK messages.

[0040] In a possible implementation manner of the third aspect, the first confirmation message is an ACK / INFORMAL RESPONSE message.

[0041] In a possible implementation manner of the third aspect, the second confirmation message is an ACK / INFORMAL RESPONSE message.

[0042] In a possible implementation manner of the third aspect, the session progress message is an INVITE / SESSION PROGRESS message.

[0043] In a possible implementation manner of the third aspect, the update message is an UPDATE / INFORMAL RESPONSE message.

[0044] In the fourth aspect, an embodiment of the present application provides a call method applied to a network-side device. Specifically, the network-side device sends a first invitation message to the terminal device. The first invitation message is related to a first call for calling the terminal device, and the terminal device subscribes to a ringback tone service. The network-side device receives the first answer message of the terminal device, and the first answer message is sent by the terminal device in response to the user's answer operation. After receiving the first answer message, the network-side device sends a second invitation message to the terminal device. The network-side device receives the second answer message of the terminal device. The second answer message does not carry the Session Description Protocol (SDP) describing the session, or the second answer message carries a first SDP, and the first SDP carries a first voice codec format, and the first voice codec format is the voice codec format negotiated by the network-side device with the terminal device after sending the first invitation message and before sending the second invitation message.

[0045] In a possible implementation of the fourth aspect, after the network - side device receives the second answer message of the terminal device, the above - mentioned method further includes: when the second answer message does not include the Session Description Protocol (SDP) describing the session, the network - side device sends a first confirmation message to the terminal device, and the first confirmation message does not carry the SDP. When the second answer message carries a first SDP and the first SDP carries a first voice codec format, the network - side device sends a second confirmation message to the terminal device, the second confirmation message carries a second SDP, the second SDP carries a first indication information, the first indication information indicates that the first call activation is successful, the second SDP also carries a second voice codec format, and the second voice codec format is the voice codec format supported by the network - side device among the first voice codec formats.

[0046] In a fifth aspect, an embodiment of the present application provides a terminal device, including: a processor and a memory; the memory stores computer - executable instructions; the processor executes the computer - executable instructions stored in the memory, so that the terminal device executes the methods in the first aspect to the fourth aspect and any implementation manner.

[0047] In a sixth aspect, an embodiment of the present application provides a network - side device, including: a processor and a memory; the memory stores computer - executable instructions; the processor executes the computer - executable instructions stored in the memory, so that the network - side device executes the methods in the first aspect to the fourth aspect and any implementation manner.

[0048] In a seventh aspect, an embodiment of the present application provides a chip system, including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected by a line. The at least one processor is used to run a computer program or instruction to execute the methods in the first aspect to the fourth aspect and any implementation manner.

[0049] In an eighth aspect, an embodiment of the present application provides a computer - readable storage medium, and the computer - readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the methods in the first aspect to the fourth aspect and any implementation manner.

[0050] In a ninth aspect, an embodiment of the present application provides a computer program product, and the computer program product includes a computer program. When the computer program is run, it causes a computer to execute the methods in the first aspect to the fourth aspect and any implementation manner.

[0051] In a tenth aspect, an embodiment of the present application provides a communication system, including a terminal device and a network - side device. Among them, the terminal device is configured to execute the methods in the first aspect to the third aspect and any implementation manner, and the network - side device is configured to execute the methods in the fourth aspect and any implementation manner.

[0052] Understandably, for the beneficial effects that can be achieved by the call method in the fourth aspect, the terminal device in the fifth aspect, the network-side device in the sixth aspect, the chip system in the seventh aspect, the computer-readable storage medium in the eighth aspect, the computer program product in the ninth aspect, and the communication system in the tenth aspect provided above, reference can be made to the beneficial effects in the first aspect to the third aspect and any possible design thereof, which will not be elaborated here. Description of the Drawings

[0053] Figure 1 One of the timing interaction diagrams of the call method provided by the embodiment of the present application;

[0054] Figure 2 Two of the timing interaction diagrams of the call method provided by the embodiment of the present application;

[0055] Figure 3 Three of the timing interaction diagrams of the call method provided by the embodiment of the present application;

[0056] Figure 4 A schematic diagram of a network architecture provided by the embodiment of the present application;

[0057] Figure 5 One of the architecture schematic diagrams of the communication system provided by the embodiment of the present application;

[0058] Figure 6 Two of the architecture schematic diagrams of the communication system provided by the embodiment of the present application;

[0059] Figure 7 Four of the timing interaction diagrams of the call method provided by the embodiment of the present application;

[0060] Figure 8 A schematic diagram of the change of the mobile phone interface after receiving an incoming call provided by the embodiment of the present application;

[0061] Figure 9 Five of the timing interaction diagrams of the call method provided by the embodiment of the present application;

[0062] Figure 10 For Figure 9 The specific implementation diagram of the call method shown;

[0063] Figure 11 Six of the timing interaction diagrams of the call method provided by the embodiment of the present application;

[0064] Figure 12 The hardware structure diagram of the terminal device provided by the embodiment of the present application;

[0065] Figure 13 The software architecture diagram of the terminal device provided by the embodiment of the present application. Detailed Implementation Manner

[0066] The technical solutions in the present application will be described below in conjunction with the accompanying drawings.

[0067] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as wireless fidelity (WiFi) systems, vehicle to everything (V2X) communication systems, device-to-device (D2D) communication systems, vehicle networking communication systems, 4th generation (4G) mobile communication systems, such as long term evolution (LTE) systems, worldwide interoperability for microwave access (WiMAX) communication systems, 5th generation (5G) mobile communication systems, such as new radio (NR) systems, and future communication systems, such as 6th generation (6G) mobile communication systems, etc.

[0068] The present application will present various aspects, embodiments or features around a system that may include multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. In addition, combinations of these solutions can also be used.

[0069] In addition, in the embodiments of the present application, words such as "exemplarily" and "for example" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as an "example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of the word "example" is intended to present concepts in a specific manner.

[0070] First, in the present application, "for indicating" may include for direct indication and for indirect indication. When describing that a certain "information" is used to indicate A, it may include that the information directly indicates A or indirectly indicates A, and does not mean that A must be carried in the information.

[0071] The information indicated by an information is referred to as the information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated. For example, but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated, etc. It is also possible to indirectly indicate the information to be indicated by indicating other information, where there is an association relationship between the other information and the information to be indicated. It is also possible to only indicate a part of the information to be indicated, while the other parts of the information to be indicated are known or pre-agreed. For example, it is also possible to use the arrangement order of each information pre-agreed (such as protocol regulations) to implement the indication of specific information, thereby reducing the indication overhead to a certain extent. At the same time, it is also possible to identify the common part of each information and indicate it uniformly to reduce the indication overhead caused by separately indicating the same information.

[0072] In addition, the specific indication method can also be various existing indication methods. For example, but not limited to, the above indication methods and their various combinations, etc. The specific details of various indication methods can refer to the prior art and will not be elaborated herein. As can be seen from the above, for example, when it is necessary to indicate multiple information of the same type, there may be a situation where the indication methods of different information are different. In the specific implementation process, the required indication method can be selected according to specific needs. The indication method selected in the embodiments of the present application is not limited. In this way, the indication methods involved in the embodiments of the present application should be understood to cover various methods that can enable the party to be indicated to obtain the information to be indicated.

[0073] The information to be indicated can be sent as a whole, or can be divided into multiple sub-informations and sent separately. Moreover, the sending periods and / or sending opportunities of these sub-informations can be the same or different. The specific sending method is not limited in the present application. Among them, the sending periods and / or sending opportunities of these sub-informations can be pre-defined, such as pre-defined according to the protocol, or can be configured by the transmitting device by sending configuration information to the receiving device. Among them, the configuration information can, for example, but not limited to, include one or at least two combinations of radio resource control (RRC) signaling, medium access control (MAC) layer signaling, and physical layer signaling. Among them, the MAC layer signaling, for example, includes MAC control element (CE); the physical (PHY) layer signaling, for example, includes downlink control information (DCI).

[0074] Second, in the embodiments shown below, the first, second, and various numerical numbers are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. For example, to distinguish different indication information.

[0075] Third, "preset", or "predefined", or "preconfigured" can be implemented by pre-saving corresponding codes, tables, or other means that can be used to indicate relevant information in a device (for example, including a terminal and a network device), or can also be specified in advance in a protocol. This application does not limit its specific implementation manner. Among them, "saving" can refer to saving in one or more memories. The one or more memories can be separately provided, or can be integrated in an encoder or a decoder, a processor, or a communication device. The one or more memories can also be partially separately provided and partially integrated in a decoder, a processor, or a communication device. The type of the memory can be any form of storage medium, and this application does not limit this.

[0076] Fourth, the "protocol" involved in the embodiments of this application can refer to standard protocols in the communication field. For example, it can include the LTE protocol of 3GPP (such as the technical specification (TS) 36, that is, the technical specifications of the TS36 series), the NR protocol (such as the technical specifications of the TS38 series), and related protocols applied to future communication systems. This application does not limit this.

[0077] The network architecture and service scenarios described in the embodiments of this application are for more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art know that with the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided by the embodiments of this application are equally applicable to similar technical problems.

[0078] Scenario background:

[0079] During a call, codec negotiation is performed during the Session Initiation Protocol (SIP) signaling interaction to negotiate the codec formats supported by both sides. Codec is a voice codec format, and the network and the terminal need to negotiate a codec format supported by both sides before they can communicate with each other.

[0080] During a call, codec negotiation is performed during the SIP signaling interaction to negotiate the codec formats supported by both sides. Codec is a voice codec format, and the network and the terminal need to negotiate a codec format supported by both sides before they can communicate with each other.

[0081] Problem scenario:

[0082] After the user answers an IP call such as 95030, there is no sound, and the call is automatically hung up after 20S.

[0083] Cause analysis:

[0084] Please refer to Figure 1 , Figure 1 which is a schematic flowchart of a call method provided by an embodiment of this application. The following analyzes the reasons for the above problem scenarios in combination with Figure 1 as follows:

[0085] 1) The network sends an initial 1.INVITE (the message shown as 1 in the following figure, also referred to as the first invite message in this article) to the terminal. The message carries codec 98 110 96 108 8 0 105 100 111 106 18 (also referred to as the first set in this article. It should be noted that the set described in this article may include one or more pieces of information, such as one or more codecs). It can be understood that the codec carried in the invite message is the set of codecs supported by the network; the first set may be the set composed of all codecs supported by the network, or a set composed of some codecs among all codecs supported by the network;

[0086] 2) The terminal sends a 3.183 message (the 183 message shown as 3 in the following figure) to the network. The message carries codec 98105 (also referred to as the second set in this article). It can be understood that the codec carried in the 183 message is the codec supported by the terminal among the codecs carried in the invite message (i.e., the first invite message), that is, the codec carried in the 183 message is the codec supported by both the network and the terminal;

[0087] 3) After the user clicks to answer the call, the terminal sends a 7.200OK message (the message shown as 7 in the following figure) to the network, and the message does not carry SDP;

[0088] 4) The network will send another invite message such as 9.re-invite (the message shown as 9 in the following figure, also referred to as the second invite message in this article) to the terminal, and the message does not carry SDP (in the ringback tone scenario, re-inivte needs to be sent);

[0089] 5) The terminal sends another 11.200OK message (the message shown as 11 in the following figure). The message carries SDP and the SDP carries all codecs supported by the terminal 98 102 105 97 (i.e., the complete set of codecs supported by the terminal), which includes the codec 97 not supported by the network;

[0090] 6) The network sends 12.ACK to the terminal, carrying SDP, and the SDP is inactive;

[0091] The codecs supported by the network carried in the SDP are 98, 102, and 105.

[0092] 7) After the terminal receives the inactive, it cannot send an uplink message, and the network will not send a downlink message either. The call drops after 20S (i.e., 20 seconds) of silence.

[0093] Solution 1:

[0094] In Figure 1 the scenario shown below, an embodiment provided by the embodiment of the present application is as follows Figure 2 shown, Figure 2 The Figure 1 same parts can refer to the description of Figure 1 . Figure 2 The Figure 1 differences mainly include the messages corresponding to 11 and 12 as shown in Figure 2 and the content carried by the messages corresponding to 11 and 12 as shown in Figure 1 . As shown in Figure 2 , 11 and 12 can be understood as:

[0095] 1) The terminal sends 11.200OK again without carrying the SDP;

[0096] 2) The network will no longer verify the codec and will return a normal ACK, and the call is connected normally;

[0097] Solution 2:

[0098] In Figure 1 the scenario shown below, an embodiment provided by the embodiment of the present application is as follows Figure 3 shown, Figure 3 The Figure 1 same parts can refer to the description of Figure 1 . Figure 3 The Figure 1 differences mainly include the messages corresponding to 11 and 12 as shown in Figure 3 and the content carried by the messages corresponding to 11 and 12 as shown in Figure 1 . As shown in Figure 3 , 11 and 12 can be understood as:

[0099] 1) The terminal sends 11.200OK again, carrying the same SDP codec 98, 105 as carried in the 183 message, or carrying a part of the codec carried in the 183, such as carrying codec 98; the codec set carried in the 200OK message is also referred to as the third set in this article; it can be understood that the codec included in the third set is part or all of the codec included in the second set.

[0100] 2) The network has verified the codec in 183, so it will return a normal ACK and the call is successfully connected.

[0101] Some embodiments provided by the present invention are beneficial to call answering.

[0102] Please refer to Figure 4 , Figure 4 which is a schematic diagram of a network architecture exemplarily provided by an embodiment of the present application. As Figure 4 shown, the network architecture may include a terminal device, LTE, NR, a core network, and IMS or the Internet. The following is a specific introduction thereto:

[0103] (1) Terminal device: The terminal device may be a terminal with transceiver functions, or may also be a chip or a chip system disposed in the terminal. The terminal device may also be referred to as a User Equipment (UE), a user terminal, a Mobile Station (MS), a Mobile Terminal (MT), etc. The terminal device may be a mobile phone, a cellular phone, a smart phone, a tablet computer (Pad), or a wearable device (such as a smart watch), etc.

[0104] (2) LTE: It can be understood as the radio access network of a 4G network. In an LTE network (i.e., the so-called 4G network), due to the evolution relationship, the access network part is called the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). In the present application, the meaning of LTE is the same as that of E-UTRAN, both referring to the access network part of a 4G network. The terminal device can access LTE through a 4G base station.

[0105] (3) NR: It can be understood as the radio access network of a 5G network. In a 5G network, the access network part is called the Next Generation Radio Access Network (NG-RAN or NG RAN). In the present application, the meaning of NR is the same as that of NG-RAN (or NG RAN), both referring to the access network part of a 5G network.

[0106] It is understandable that both LTE and NR are access networks. The access network is responsible for connecting a large number of end users to the core network (also known as the backbone network) using a certain wired or wireless connection and communication technology to achieve network connection. The access network is the edge part of the entire network and the part closest to the user, usually also called the "last mile".

[0107] (4) Core network: Its main functions are to provide user connection, user management, and bearer for services, and to provide an interface to external networks as a bearer network. The establishment of user connection includes functions such as mobility management (MM), call management (CM), switching / routing, and announcement recording (combining intelligent network services to complete the connection relationship to intelligent network peripheral devices).

[0108] It is understandable that the core network of the 4G network is the Evolved Packet Core (EPC) network. The EPC network is the core network of the 4G mobile communication network. It belongs to the category of core networks, has traditional capabilities of mobile networks such as user subscription data storage, mobility management, and data exchange, and can provide users with an ultra-high-speed Internet experience. The core network of the 5G network is 5G Core (which can be abbreviated as 5GC for short). 5GC will use general network function virtualization devices to replace the dedicated communication devices of the 4G network.

[0109] It should be noted that Figure 4 the core network in the shown network architecture can be obtained by fusing EPC and 5GC. That is to say, the core network in this network architecture can include both network elements in EPC and network elements in 5GC. For example, the core network in this network architecture can include network elements such as Access and Mobility Management Function (AMF) network element, Mobility Management Entity (MME) network element, Serving GateWay (SGW) network element, Packet Data Network GateWay (PGW) network element, Session Management Function (SMF) network element, User Plane Function (UPF) network element, Unified Data Management (UDM) network element, and Home Subscriber Server (HSS) network element, etc.

[0110] In some embodiments of the present application, the core network in the network architecture may include a converged network element obtained from network elements in the EPC and network elements in the 5GC. For example, SMF+PGW-C, UPF+PGW-U, UDM+HSS, etc. Among them, PGW-C is the control plane node of the PGW network element, and PGW-U is the user plane node of the PGW network element.

[0111] In some embodiments of the present application, Figure 4 The core network in the network architecture shown may include a Proxy Session Border Control (PSBC) network element, which is a co-located network element integrating Session Border Control (SBC), Proxy-Call Session Control Function (Proxy-CSCF, P-CSCF), Access Transfer Control Function (ATCF), and Access Transfer Gateway (ATGW). As an SBC network element, it connects the IMS core network / softswitch network to the external user access area, completes the service access of IMS / softswitch users, realizes the interworking of user services in different network environments, ensures the security of the IMS / softswitch network, supports QoS management, CAC traffic control, media management, CDR media call detail list, and other functions.

[0112] Each network element in the core network can also be referred to as a functional entity, which can be either a network element implemented on dedicated hardware, a software instance running on dedicated hardware, or an instance of virtualized functions on an appropriate platform.

[0113] It should be understood that the names of all network elements in the present application are only examples. In future communications, such as in 6G, they may also be referred to by other names, or in future communications, such as in 6G, the network elements involved in the present application may also be replaced by other entities or devices with the same functions, and the present application makes no limitation in this regard. A unified description is made here and will not be repeated hereinafter. Optionally, various network elements in the embodiments of the present application may be communication devices, or chips or chip systems that can be used in the communication devices, and the embodiments of the present application make no limitation in this regard.

[0114] It can be understood that Figure 4 The core network in the network architecture shown may also include other devices, network elements, network entities, or network subsystems, such as a Policy Control function (PCF) network element, and the present application makes no limitation in this regard. It should be noted that the present application makes no limitation on the distribution method of each network element in the core network, and the specific distribution method can refer to relevant technical documents, and the present application will not elaborate here.

[0115] (5) IMS is a network architecture that provides voice and multimedia communication services (such as voice, video, and text messages, etc.) based on an IP network. IMS can achieve secure and reliable multimedia communication between different devices on different networks. The architecture model provides a unified infrastructure and common mechanisms for controlling, operating, routing, and managing sessions, as well as implementing authentication, authorization, and accounting control. The IMS specification includes recommendations widely used by the Internet Engineering Task Force (IETF). For example, the Session Initialization Protocol (SIP) for session control signaling.

[0116] The Internet generally refers to the Internet, also known as the international network, which refers to the huge network formed by connecting networks with each other. These networks are connected by a set of common protocols to form a logically single huge international network. From the perspective of network communication, the Internet is a data communication network that connects computer networks in various countries, regions, and institutions around the world with the Transmission Control Protocol (TCP) / Internet Protocol (IP).

[0117] It should be noted that Figure 4 The network architecture shown is not limited to only including the devices and networks shown in the figure, and may also include other devices not shown in the figure. This application will not list them one by one here.

[0118] Please refer to Figure 5 , Figure 5 which is a schematic diagram of the architecture of a communication system provided by an embodiment of this application. This communication system is applicable to the voice call scenario of the embodiment of this application. As Figure 5 shown, the communication system includes terminal devices, such as Figure 5 the terminal device 100 and the terminal device 200 in Figure 5 , and the communication system also includes network devices, such as

[0119] Regarding the terminal device, reference can be made to Figure 4 the relevant description of the network architecture shown, which will not be elaborated here.

[0120] The network device can be a device with wireless transceiver functions, or can also be a chip or chip system disposed in the device, located in the access network (AN) of the communication system, and used to provide access services for the terminal device. For example, the network device can be referred to as a radio access network (RAN) device. Specifically, it can be an access network device for the next-generation mobile communication system, such as a 6G base station. Or, in the next-generation mobile communication system, the network device can also have other naming methods, all of which are covered by the protection scope of the embodiments of this application, and this application does not make any limitation thereto. Or, the network device can also include a gNB in 5G, such as the NR system, or one or a group (including multiple antenna panels) of antenna panels of a base station in 5G. Or, it can also be a network node constituting a gNB, a transmission and reception point (TRP) or a transmission point (TP), or a transmission measurement function (TMF), such as a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), an RSU with base station functions, or a wired access gateway, or a core network element of 5G. Or, the network device can also include: an access point (AP) in a wireless fidelity (WiFi) system, a wireless relay node, a wireless backhaul node, various forms of macro base stations, micro base stations (also called small stations), relay stations, access points, wearable devices, in-vehicle devices, and so on.

[0121] Specifically, in a voice call scenario, the terminal device 100 can transmit voice data to the terminal device 200 through the network device_1, the IMS, and the network device_2. Among them, the network device_1 is the network device corresponding to the cell where the terminal device 100 currently camps, and the network device_2 is the network device corresponding to the cell where the terminal device 200 currently camps. In some embodiments of this application, the network device_1 and the network device_2 can be the same network device, that is, the network devices corresponding to the cells where the terminal device 100 and the terminal device 200 currently camp are the same. In some embodiments of this application, the terminal device 100 can be the party initiating the voice call to request a voice call with the terminal device 200. In still some other embodiments of this application, the terminal device 200 can be the party initiating the voice call to request a voice call with the terminal device 100.

[0122] Further, please refer to Figure 6 , Figure 6 , which is a schematic diagram of the architecture of another communication system provided by the embodiment of the present application. Different from the Figure 5 communication system shown above: Figure 6 The communication system shown above further includes a ringback tone server, such as CAT-AS. And, for the sake of convenience of description, Figure 6 in the communication system shown above, taking network device_1 and network device_2 as the same network device_3 as an example for illustration. It can be understood that when network device_1 and network device_2 are different network devices, the implementation principle of the call method provided by the embodiment of the present application is the same. Among them, the ringback tone server can interact with terminal device 100 and terminal device 200 through network device_3 to implement the playback control of the ringback tone in the voice call scenario.

[0123] In the following, taking terminal device 100 as the party initiating the voice call, that is, the calling end, and terminal device 200 as the party receiving the voice call, that is, the called end, as an example, the embodiment of the present application will be described. In some embodiments of the present application, terminal device 100 is a dialing terminal of a fixed telephone (abbreviated as a landline, also called a wired telephone, a landline phone, etc.), an IP phone (such as a network phone like 95030). Among them, an IP phone is a telephone service opened according to the network technology content specified by the IP protocol. For the sake of convenience of description, a call from a dialing terminal of a landline or an IP phone is called a fixed network call, and a call other than a fixed network call is called a non-fixed network call.

[0124] The following first introduces the technical terms involved in the embodiment of the present application:

[0125] 1. Session Initiation Protocol (SIP).

[0126] SIP is a signaling protocol used to initiate, manage, and terminate media (such as voice, video) sessions in a network. Specifically, it is used to generate, modify, and terminate a session between one or more participants. In short, SIP provides a message mechanism for establishing a media session.

[0127] Generally, the message types included in the message mechanism provided by SIP are invitation (INVITE), provisional response confirmation (PRACK), update (UPDATE), confirmation (ACK), etc. Among them, each type further includes multiple messages.

[0128] Exemplarily, INVITE further includes: an INFORMAL RESPONSE message, denoted as a SIP-INVITE / INFORMAL RESPONSE message; a TRYING message, denoted as a SIP-INVITE / TRYING message; a SESSION PROGRESS message, denoted as a SIP-INVITE / SESSION PROGRESS message; a RINGING message, denoted as a SIP-INVITE / RINGING message; an OK message, denoted as a SIP-INVITE / OK message.

[0129] Exemplarily, PRACK further includes: an INFORMAL RESPONSE message, denoted as a SIP-PRACK / INFORMAL RESPONSE message; an OK message, denoted as a SIP-PRACK / OK message, etc.

[0130] Exemplarily, UPDATE further includes: an INFORMAL RESPONSE message, denoted as a SIP-UPDATE / INFORMAL RESPONSE message; an OK message, denoted as a SIP-UPDATE / OK message, etc.

[0131] Exemplarily, ACK further includes: an INFORMAL RESPONSE message, denoted as a SIP-ACK / INFORMAL RESPONSE message; an OK message, denoted as a SIP-ACK / OK message, etc.

[0132] It should be noted that the same messages in different types, such as the INFORMAL RESPONSE message and the OK message included in each of the above types, have different functions. Regarding the functions of each message under each type, please refer to the introduction of the embodiments below for details, and no further description will be given here for the time being.

[0133] Moreover, each message has a fixed identifier. The identifier of the above SIP-INVITE / SESSION PROGRESS message is 183, and the identifier of the SIP-INVITE / OK message is 200. Therefore, the SIP-INVITE / SESSION PROGRESS message can also be referred to as the 183 SESSION PROGRESS message, and the SIP-INVITE / OK message can also be referred to as the 200 OK message.

[0134] In the embodiments of the present application, between two devices in the above communication system, such as between the terminal device 100 and the network device_3, between the terminal device 200 and the network device_3, between the network device_3 and the ringback tone server, etc., a voice session can be implemented based on SIP. For example, the terminal device 100 can initiate a call invitation to the terminal device 200 through INVITE.

[0135] 2. Describe the Session Description Protocol (SDP) for sessions.

[0136] SDP provides a structured language mainly used for media negotiation between two devices, such as negotiating the voice codec format (codec), media (video / audio) ports, call formats, etc. Among them, a device can carry SDP in the message provided by the above SIP to achieve media negotiation. For example, carry SDP in UPDATE to negotiate the media capabilities supported by both devices. After completing the media negotiation, the two devices can make a call using the capabilities that are compatible with both of them.

[0137] In the embodiments of the present application, between the terminal device 100 and the network device_3 in the above communication system, and between the terminal device 200 and the network device_3, SDP can be used to negotiate the codec to negotiate the codec for voice encoding and decoding. After negotiating the codec for voice encoding and decoding, the above communication system can use the negotiated codec to complete the voice encoding and decoding in the voice call scenario, so as to realize the normal voice playback of the terminal device 100 and the terminal device 200. For example, the terminal device 100 normally plays the ringback tone of the terminal device 200, and the terminal device 100 and the terminal device 200 normally play the call voice.

[0138] The embodiments of the present application provide a call method, which can be applied to the scenario where the terminal device 100 and the terminal device 200 make a voice call, and is mainly applied to the fixed network call scenario, that is, the scenario where the terminal device 200 receives a fixed-line call and an IP call from the terminal device 100.

[0139] Please refer to Figure 7 and Figure 8 , Figure 7 which is a flowchart of a call method in the fixed network call scenario, Figure 8 and Figure 7 is a schematic diagram of the interface response of the terminal device 200 in the Figure 7 shown process. As

[0140] S701. The terminal device 100 receives a dialing event, and the dialing event is used to dial the phone number 1 of the terminal device 200.

[0141] Exemplarily, the dialing event may be an event of a user clicking on the contact corresponding to the phone number 1 in the terminal device 100. Or, the dialing event may be an event that the user clicks the dial button after dialing the phone number 1 in the terminal device 100. Or, the dialing event may be an event when it reaches the time to call the phone number 1.

[0142] S702. In response to receiving the dialing event, the terminal device 100 initiates a call invitation to the terminal device 200 through the network device_3.

[0143] Among them, the call invitation may be a SIP-INVITE / INFORMAL RESPONSE message.

[0144] Exemplarily, the terminal device 100 carries the phone number 1 in the call invitation. Based on the phone number 1 in the call invitation, the network device_3 can determine that the called party is the terminal device 200, and thus can further initiate a call invitation to the terminal device 200.

[0145] S703. The terminal device 200 and the terminal device 100 perform an invitation response through the network device_3.

[0146] Among them, the invitation response includes that the terminal device 200 feeds back to the terminal device 100 that it has received the invitation, and the terminal device 100 and the terminal device 200 complete processes such as resource reservation. For the specific processes included in the invitation response, reference can be made to the description of S1006 - S1011 below. Here, no further introduction will be made for the time being. Figure 10 in the description of S1006 - S1011, and no more introduction will be made here for the time being.

[0147] In the process of the above S701 - S702, the terminal device 200 will not display information about the call invitation. Exemplarily, the terminal device 200 can normally display the user interface, without displaying a call prompt, nor a call interface. Thus, the user of the terminal device 200 will not perceive the call invitation. As Figure 8 shown, in the process of the above S701 - S703, the terminal device 200 can display the interface 801, and there is no call prompt in the interface 801, and the interface 801 is the desktop of the terminal device 200, not a call interface.

[0148] S704. The terminal device 200 rings.

[0149] After completing the above invitation response, the terminal device 200 will ring. As Figure 8 shown, after completing the invitation response, the terminal device 200 can display the interface 802, the interface 802 is a call interface, and at this time the terminal device 200 is playing the incoming call ringtone, that is, ringing.

[0150] S705. When the terminal device 200 subscribes to the CRBT service, in response to the start of ringing, the terminal device 200 notifies the CRBT server to control the CRBT playback through the network device_3.

[0151] S706. The CRBT server transmits the CRBT data of the terminal device 200 to the terminal device 100 through the network device_3.

[0152] S707. In response to receiving the CRBT data, the terminal device 100 plays the CRBT of the terminal device 200.

[0153] After the above S705 - S707, after the terminal device 200 rings, the terminal device 100 can play the CRBT of the terminal device 200.

[0154] It can be understood that during the process of S704 - S707, the terminal device 200 has been ringing.

[0155] S708. In response to receiving the user's answering operation, the terminal device 200 sends an answering message 1 to the network device_3.

[0156] Among them, the answering message 1 indicates that the terminal device 200 has answered. Exemplarily, the answering message 1 can be a SIP - INVITE / OK message.

[0157] Among them, the answering operation can be a click operation on the answer button, such as the click operation on the answer button 8021 in the Figure 8 shown interface 802. Of course, the answering operation can also be that the user inputs an answering voice, such as the operation of "answer the call".

[0158] In response to receiving the user's answering operation, the terminal device 200 can start call timing. As Figure 8 shown, in response to receiving the user's click operation on the answer button 8021 in the interface 802, the terminal device 200 can display the interface 803, and the interface 803 includes "00:00", indicating the start of call timing.

[0159] It can be understood that after the terminal device 200 answers, the terminal device 100 can stop playing the CRBT of the terminal device 100 and prepare to start a call. Specifically, the following S709 - S712 can be adopted to control the terminal device 100 to stop playing the CRBT.

[0160] S709. In response to receiving the answering message 1, the network device_3 notifies the CRBT server to control the stop of CRBT playback.

[0161] S710. The CRBT server stops transmitting the CRBT data.

[0162] S711. The CRBT server notifies the terminal device 100 to stop playing the CRBT through the network device 3.

[0163] S712: The terminal device 100 stops playing the ringback tone.

[0164] It can be seen from the above S709-S712 that after receiving the answering message 1, the network device 3 then stops playing the ringback tone, but does not continue to notify the terminal device 100 that the terminal device 200 has answered the call. Therefore, in the case where the terminal device 200 subscribes to the scene service, it is necessary to repeat the invitation again through the following S713-S71, that is, reinvite.

[0165] S713. The ring back tone server initiates a repeated invitation to the terminal device 200 through the network device_3.

[0166] S714. In response to receiving the repeated invitation, the terminal device 200 sends a listening message 2 to the network device 3. The listening message 2 carries SDP1. The SDP1 carries the full set of codecs supported by the terminal device 200.

[0167] The answering message 2 also indicates that the terminal device 200 has answered the call. Exemplarily, the answering message 2 may also be an INVITE / OK message.

[0168] And, the answer message 2 carries the full set of codecs supported by the terminal device 200. For example, the full set of codecs supported by the terminal device 200 includes 97, 98, 102 and 105, a total of 4 types, and the answer message 2 carries the above 4 types of codecs. In this way, the terminal device 200 and the network device_3 can negotiate the best codec from the full set of codecs supported by the terminal device 200.

[0169] It should be noted that, different from the above S708, in S714, the terminal device 200 automatically sends the answer message 2 in response to receiving the repeated invitation. In the above S708, the terminal device 200 passively sends the answer message 1 in response to receiving the user's answer operation.

[0170] S715. In response to receiving the answer message 2, the network device _3 forwards the answer message 2 to the terminal device 100.

[0171] At this time, the information that the terminal device 200 has answered the call is notified to the terminal device 100.

[0172] S716. Network device 3 verifies the codec based on answering message 2, and sends a confirmation message 2 to terminal device 200. Confirmation message 2 carries SDP2. SDP2 includes codecs supported by network device 3 and indication information of whether the answering is successful.

[0173] Among them, the confirmation message 2 is used to indicate that the answer message 2 has been received. Exemplarily, the confirmation message 2 is SIP-ACK / INFORMAL RESPONSE.

[0174] Specifically, the network device_3 verifies the codec based on the answer message 2, including: the network device_3 can verify whether the codec in the answer message 2 is consistent with the codec supported by the network device_3.

[0175] In some cases, the codec in the answer message 2 is consistent with the codec supported by the network device_3, such as being exactly the same, or the codec supported by the network device_3 includes the codec in the answer message 2. For this case, the network device_3 can verify that the codec in the answer message 2 is consistent with the codec supported by the network device_3, and the network device_3 can add the codec supported by the terminal device_3 and the indication information of successful answer in the confirmation message 2. Exemplarily, the indication information of successful answer is active, and active means that the current call is successfully activated.

[0176] Taking the example that the answer message 2 includes 3 codecs, namely 97, 102, and 105, and the network device_3 also supports 3 codecs, namely 97, 102, and 105, the network device_3 can verify that the codec in the answer message 2 is consistent with the codec supported by the network device_3, and thus add 3 codecs, namely 97, 102, and 105, and active in the confirmation message 2.

[0177] In other cases, the codec in the answer message 2 is inconsistent with the codec supported by the network device_3, such as the answer message 2 includes a codec not supported by the network device_3. If the terminal device 200 is inconsistent with the codec supported by the network device_3, the voice encoding and decoding cannot be completed during the voice call, and the current call will be activated failed, that is, the answer fails. For this case, the network device_3 can add the codec in the answer message 2, the codec supported by the terminal device_3, and the indication information of answer failure in the confirmation message 2. Exemplarily, the indication information of answer failure is inactive, and inactive means that the current call is activated failed.

[0178] Taking the answering message 2 including 4 codecs, 97, 98, 102 and 105, and the network device 3 supporting 3 codecs, 98, 102 and 105 as an example, the network device 3 can verify that the codec in the answering message 2 is inconsistent with the codec supported by the network device 3, and thus add 3 codecs, 98, 102 and 105, and inactive, to the confirmation message 2.

[0179] At this point, it should be noted that after receiving the answering message 2, the network device 3 can also perform other information, such as the verification of the video / audio port. The previous S716 only describes the verification of the codec. In practice, if all the information is verified to be consistent, the call activation is successful, and the network device 3 will add the indication information of the successful answering in the confirmation message 2. If any of the information is inconsistent, the call activation fails, and the network device 3 will add the indication information of the failed answering in the confirmation message 2.

[0180] S717: In response to receiving the confirmation message 2, and the confirmation message 2 includes the indication information of the failed call, the call between the terminal device 100 and the terminal device 200 fails to be answered, and the call is hung up.

[0181] After receiving the confirmation message 2, the terminal device 200 can confirm that the call has failed to be answered, and automatically hang up the call based on the indication information of the failed answering in the confirmation message 2. In a specific implementation, the terminal device 200 can automatically hang up the call after a preset time interval, such as 10s or 20s, after answering the call.

[0182] It is understandable that after the terminal device 200 automatically hangs up the call, it will exit the call and restore the interface before the call.

[0183] Take the preset duration of 20 seconds as an example. Figure 8 As shown, after the call timer reaches 20s, the terminal device 200 can display interface 804, and interface 804 includes "00:20", indicating that the call has been answered for 20s. At this time, the terminal device 200 automatically hangs up the call, and can display interface 805 at the moment of hanging up, indicating that the call is over. After displaying interface 805, the terminal device 200 can restore the display interface 801, that is, return to the interface before the call. It should be noted that in the process of the terminal device 200 displaying interface 803 to interface 804, although the call interface has been timing, such as from the timing "00:00" in interface 803 to the timing "00:20" in interface 804, the call is not actually connected, and the terminal device 200 will not play the call tone.

[0184] S718. In response to receiving the confirmation message 2 and confirming that the confirmation message 2 includes the indication information of successful answering, the terminal device 200 and the terminal device 100 perform a voice call using the codec in the confirmation message 2.

[0185] If the confirmation message 2 includes the indication information of successful answering, it indicates that the call is successfully answered. Subsequently, the terminal device 200 and the terminal device 100 can use the codec in the confirmation message 2 to encode and decode the call voice, so that a normal call can be made.

[0186] After the introduction of the above Figure 7 As can be seen from the introduction of the above process, in the fixed network call scenario, during the repeated invitation process, because the codecs supported by the terminal device 200 and the network device _3 are inconsistent, the terminal device 200 will automatically hang up the current call, resulting in the problem of failed call answering.

[0187] Based on the above problems in the fixed network call scenario, the embodiment of the present application provides a call method.

[0188] This call method can be applied to the above fixed network call scenario to solve the problem of failed call answering during the repeated invitation process in the fixed network call scenario. It should be noted that: the repeated invitation process in the non-fixed network call scenario is similar to the repeated invitation process in the fixed network call scenario. Therefore, it is not excluded that there may be a problem of failed call answering during the repeated invitation process. Based on this, this call method can also be applied to the non-fixed network call scenario to prevent the problem of failed call answering during the repeated invitation process. In the following text, the fixed network call scenario is mainly used as an example to illustrate the solution of the present application.

[0189] In some embodiments, the method includes: after receiving the repeated invitation, the terminal device 200 can send an answering message 3 to the network device _3, and the answering message 3 does not carry SDP. In this way, after receiving the answering message 3, since the answering message 3 does not carry SDP, the network device _3 will not verify that the codec in the answering message 3 is inconsistent with the codec supported by the network device _3.

[0190] In other embodiments, the method includes: after receiving the repeated invitation, the terminal device 200 can send an answering message 4 to the network device _3, and the answering message 4 carries SDP3, and SDP3 carries the codec negotiated between the terminal device 200 and the network device _3 before the repeated invitation. In this way, after receiving the answering message 4, the network device _3 can verify that the codec in the answering message 4 is consistent with the codec supported by the network device _3.

[0191] In summary, by adopting the embodiments of the present application, during the process of repeated invitation, the problem of call failure will not occur due to the inconsistency of the codecs supported by the terminal device 200 and the network device_3. Therefore, the call answering success rate can be improved.

[0192] In some embodiments, please refer to Figure 9 , Figure 9 which is a flowchart of a call method provided by an embodiment of the present application. As Figure 9 shown, in the fixed network call scenario, step S703 (step of invitation response) in the above Figure 7 further includes:

[0193] S900. The terminal device 200 sends a session progress message to the network device_3, and the session progress message includes codec3 supported by the terminal device 200, the network device_3, and the terminal device 100.

[0194] Among them, the session progress message indicates that preparations are being made for this call. Specifically, the session progress message can be a SIP-INVITE / SESSION PROGRESS message.

[0195] Exemplarily, the codecs supported by the terminal device 100 include a, b, c, d, the codecs supported by the network device_3 include b, c, e, and the codecs supported by the terminal device 200 include c, f. Then, the codec3 carried in the session progress message can be c.

[0196] Regarding the specific implementation of the session progress message carrying the codecs supported by the terminal device 200, the network device_3, and the terminal device 100, reference can be made to the descriptions of S1002, S1004, and S1006 below Figure 10 , and no further description will be given here.

[0197] In addition, S714 - S718 after the terminal device 200 receives the repeated invitation message in the above Figure 7 can be replaced by the following S901 - S904.

[0198] S901. In response to receiving the repeated invitation, the terminal device 200 sends an answer message 3 to the network device_3, and the answer message 3 does not carry SDP.

[0199] Similar to S714 above, S901 is also actively triggered, rather than being passively triggered by the user's answer operation.

[0200] Among them, the answer message 3 also indicates that the terminal device 200 has answered. Exemplarily, the answer message 3 can also be an INVITE / OK message.

[0201] The codec is usually carried in the SDP. Then, if the answer message 3 does not carry the SDP, the codec is not included.

[0202] S902. In response to receiving the answer message 3, the network device_3 forwards the answer message 3 to the terminal device 100. For details, see S715.

[0203] S903. The network device_3 sends an acknowledgement message 3 to the terminal device 200, and the acknowledgement message 3 does not carry the SDP.

[0204] Among them, the acknowledgement message 3 is used to indicate that the answer message 3 has been received. Exemplarily, the acknowledgement message 3 is a SIP-ACK / INFORMAL RESPONSE message.

[0205] Since the answer message 3 does not carry the SDP, the network device_3 does not need to perform related processing for media negotiation, such as verifying the codec. And the network device_3 also does not need to feedback the negotiated data to the terminal device 200 through the SDP, such as the indication information of whether the answer is successful, that is, the answer message 3 does not carry the SDP.

[0206] S904. In response to receiving the acknowledgement message 3, the terminal device 200 and the terminal device 100 start a voice call using the codec3 in the session progress message.

[0207] Since the answer message 3 does not carry the SDP, it naturally does not include the indication information of answer failure, such as inactive. In this case, the call will not fail to answer. And, the session progress message in the foregoing S900 carries the codec supported by both the terminal device 200, the network device_3, and the terminal device 100, which indicates that the codec in the session progress message can be used for the encoding and decoding of the call voice. Therefore, the terminal device 100 and the terminal device 200 can start a voice call using the codec in the session progress message.

[0208] Exemplarily, if the codec3 carried in the session progress message is 98, the terminal device 100 and the terminal device 200 can use 98 for the encoding and decoding of the session call voice and start a voice call.

[0209] It should be noted that there may be multiple codec3s carried in the session progress message. In this case, the terminal device 100 and the terminal device 200 can select one from multiple codecs for the voice call.

[0210] It can be seen that by adopting this embodiment, in the fixed network call scenario, after receiving a repeated invitation, the terminal device 200 can send an answer message 3 without carrying the SDP to the network device_3, thereby improving the answer success rate in the fixed network call scenario.

[0211] Please refer to Figure 10 , Figure 10 a flowchart of a specific implementation manner of the call method shown in Figure 9 . As shown in Figure 10 , the call method includes the following steps:

[0212] S1001. The terminal device 100 receives a dialing event, and the dialing event is used to dial the phone number 1 of the terminal device 200. For details, please refer to S701.

[0213] By using the following S1002 - S1005, S702 in the foregoing can be implemented, that is, the terminal device 100 initiates an invitation to the terminal device 200 through the network device_3.

[0214] S1002. In response to receiving the dialing event, the terminal device 100 sends a SIP-INVITE / INFORMAL RESPONSE to the network device_3, and the SIP-INVITE / INFORMAL RESPONSE includes codec1 supported by the terminal device 100.

[0215] In S1002, the SIP-INVITE / INFORMAL RESPONSE can be used to initiate a call invitation. The SIP-INVITE / INFORMAL RESPONSE may also include the phone number 1 of the terminal device 200 to indicate the called party.

[0216] S1003. The network device_3 feeds back a SIP-INVITE / TRYING to the terminal device 100.

[0217] The SIP-INVITE / TRYING can indicate that a call invitation has been received.

[0218] S1004. The network device_3 sends a SIP-INVITE / INFORMAL RESPONSE to the terminal device 200, and the SIP-INVITE / INFORMAL RESPONSE includes codec2 supported by the terminal device 100 and the network device_3.

[0219] In S1004, the SIP-INVITE / INFORMAL RESPONSE can be used to further initiate an invitation to the terminal device 200. The SIP-INVITE / INFORMAL RESPONSE may include the phone number 1 of the terminal device 100 to indicate the calling party.

[0220] In addition, after receiving the SIP-INVITE / INFORMAL RESPONSE from the terminal device 100, the network device_3 can obtain the codec1 supported by the terminal device 100 from the SIP-INVITE / INFORMAL RESPONSE, and carry the codec2 supported by itself (i.e., the network device_3) among the codec1 supported by the terminal device 100 in the SIP-INVITE / INFORMAL RESPONSE sent to the terminal device 200.

[0221] Exemplarily, the codec1 supported by the terminal device 100 includes 97, 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, 18, and the codec supported by the network device_3 includes 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, 18. Then, the codec2 supported by both the terminal device 100 and the network device_3 is the intersection of the two: 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, 18.

[0222] S1005. The terminal device 200 feeds back SIP-INVITE / TRYING to the network device_3.

[0223] By using the following S1006-S1011, S703 in the previous text can be implemented, that is, the invitation response is carried out through the network device_3.

[0224] S1006. The terminal device 200 sends SIP-INVITE / SESSION PROGRESS to the network device_3. The SIP-INVITE / SESSION PROGRESS includes the codec3 supported by all of the terminal device 100, the network device_3, and the terminal device 200. S1006 specifically corresponds to the aforementioned S900.

[0225] Among them, the SIP-INVITE / SESSION PROGRESS indicates that preparations are being made for this call.

[0226] When the terminal device 200 receives a SIP-INVITE / INFORMAL RESPONSE from the network device_3, it can obtain the codecs supported by both the terminal device 100 and the network device_3 from the SIP-INVITE / INFORMAL RESPONSE, and carry the codecs supported by itself (i.e., the terminal device 200) among the codecs supported by both the terminal device 100 and the network device_3 in the SIP-INVITE / SESSION PROGRESS sent to the network device_3. Thus, the codecs supported by the terminal device 100, the network device_3, and the terminal device 200 are carried in the SIP-INVITE / SESSION PROGRESS sent by the terminal device 200 to the network device_3.

[0227] Exemplarily, the codecs (i.e., codec2) supported by both the terminal device 100 and the network device_3 include 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, 18, and the codecs supported by the terminal device 200 include 98, 102, 105, 97. Then, the codec3 supported by both the terminal device 100, the network device_3, and the terminal device 200 is the intersection of the two: 98, 105.

[0228] S1007. The network device_3 sends a SIP-INVITE / SESSION PROGRESS to the terminal device 100, and the SIP-INVITE / SESSION PROGRESS includes codec3.

[0229] Through the above S1006 - S1007, the terminal device 100, the network device_3, and the terminal device 200 can all obtain the codec3 supported by all three parties, that is, the codec3 supported by all three parties is negotiated.

[0230] S1008. The terminal device 100 sends a SIP-PRACK / INFORMAL RESPONSE to the network device_3.

[0231] The SIP-PRACK / INFORMAL RESPONSE is used to perform the operation of resource reservation.

[0232] S1009. The network device_3 sends a SIP-PRACK / OK to the terminal device 100.

[0233] The SIP-PRACK / OK is used to indicate that the SIP-PRACK / INFORMAL RESPONSE has been received.

[0234] S1010. The network device_3 sends a SIP-PRACK / INFORMAL RESPONSE to the terminal device 200.

[0235] S1011. The terminal device 200 sends a SIP-PRACK / OK back to the network device_3.

[0236] After completing the invitation response, the terminal device 200 can then implement S704 described above, namely S1012 below.

[0237] S1012. The terminal device 200 rings. For details, refer to S705 above.

[0238] S1013. The terminal device 200 sends a SIP-INVITE / RINGING to the network device_3.

[0239] SIP-INVITE / RINGING indicates that the terminal device 200 starts to ring.

[0240] S1014. The network device_3 notifies the ringback tone server to play the ringback tone.

[0241] After receiving the SIP-INVITE / RINGING, the network device_3 can also, through S1015 below, notify the terminal device 200 that the terminal device 100 starts to ring.

[0242] S1015. The network device_3 sends a SIP-INVITE / RINGING to the terminal device 200.

[0243] It should be noted that both S1014 and S1015 can be triggered when the network device_3 receives the SIP-INVITE / RINGING. In practice, the execution order of the two is not limited to Figure 10 as shown. For example, the network device_3 can also execute S1015 first and then S1014.

[0244] The following S1016 - S1017 can be used to implement S706 above, that is, to transmit the ringback tone data of the terminal device 200 to the terminal device 100.

[0245] S1016. In response to receiving the notification to play the ringback tone, the ringback tone server sends a ringback tone data stream to the network device_3.

[0246] Among them, the ringback tone data stream refers to the data stream corresponding to the ringback tone of the terminal device 200. Exemplarily, the ringback tone data stream can be a real-time transport protocol (RTP) stream.

[0247] S1017. The network device_3 sends the ringback tone data stream to the terminal device 100.

[0248] The network device_3 transmits the ringback tone data stream from the ringback tone server to the terminal device 100 so that the terminal device 100 can obtain the ringback tone data stream.

[0249] S1018. The terminal device 200 plays the ringback tone. For details, refer to S707 in the previous text.

[0250] S1019. In response to receiving the user's answer operation, the terminal device 200 sends SIP-INVITE / OK to the network device_3. For details, refer to S708 in the previous text.

[0251] Among them, SIP-INVITE / OK can indicate that the terminal device 200 answers the call.

[0252] In response to receiving SIP-INVITE / OK, the network device_3 can implement S709 to notify the ringback tone server to control the stop of playing the ringback tone, as follows in S1020.

[0253] S1020. The network device_3 sends SIP-INVITE / OK to the ringback tone server.

[0254] After receiving SIP-INVITE / OK, the ringback tone server can determine that the terminal device 200 has answered the call. At this time, S710 can be implemented to control the terminal device 100 to stop playing the ringback tone, as follows in S1021.

[0255] S1021. The ringback tone server stops transmitting the ringback tone data stream.

[0256] After receiving SIP-INVITE / OK, the ringback tone server can implement S711 by using the following S1022 - S1023, that is, notify the terminal device 100 to stop playing the ringback tone.

[0257] S1022. The ringback tone server feeds back SIP-ACK / INFORMAL RESPONSE to the network device_3.

[0258] Among them, SIP-ACK / INFORMAL RESPONSE indicates the receipt of SIP-INVITE / OK.

[0259] It should be noted that both S1021 and S1022 can be triggered by the ringback tone server receiving SIP-INVITE / OK. In practice, the execution order of the two is not limited to Figure 10 as shown. For example, the ringback tone server can also execute S1022 first and then S1021.

[0260] S1023. The network device_3 sends a SIP-UPDATE / INFORMAL RESPONSE to the terminal device 100.

[0261] Among them, the SIP-UPDATE / INFORMAL RESPONSE indicates to stop playing the ringback tone. Exemplarily, the video 0 parameter is carried in the SIP-UPDATE / INFORMAL RESPONSE to indicate stopping the play of the ringback tone.

[0262] After receiving the SIP-UPDATE / INFORMAL RESPONSE, the terminal device 100 can implement S712, specifically as follows in S1024.

[0263] S1024. The terminal device 100 stops playing the ringback tone.

[0264] After receiving the SIP-UPDATE / INFORMAL RESPONSE, the terminal device 100 can also, through the following S1025, notify the network device_3 that the terminal device 100 has received the SIP-UPDATE / INFORMAL RESPONSE.

[0265] S1025. The terminal device 100 sends a SIP-UPDATE / OK to the network device_3.

[0266] Among them, the SIP-UPDATE / OK indicates that the terminal device 100 has received the SIP-UPDATE / INFORMAL RESPONSE.

[0267] After receiving the SIP-INVITE / OK (such as received in the above S1019), the network device_3 can further feedback to the terminal device 200 that it has received the SIP-INVITE / OK, specifically as shown in S1026 below.

[0268] S1026. The network device_3 sends a SIP-ACK / INFORMAL RESPONSE to the terminal device 200.

[0269] Among them, the SIP-ACK / INFORMAL RESPONSE indicates receiving the SIP-INVITE / OK.

[0270] It should be noted that both S1020 and S1026 are triggered by the network device_3 receiving the SIP-INVITE / OK. In practice, the execution order of the two is not limited to Figure 10 as shown. For example, the network device_3 can execute S1026 at any time between S1019 - S1025, rather than being limited to between S1023 - S1025.

[0271] After receiving the SIP-INVITE / OK, the ringback tone server can also adopt the following S1027 - S1029 to implement S714, that is, initiate a repeated invitation.

[0272] S1027. The ringback tone server sends a SIP-INVITE / INFORMAL RESPONSE to network device _3.

[0273] In S1027, the SIP-INVITE / INFORMAL RESPONSE can be used to initiate a repeated invitation.

[0274] It should be noted that both S1021 and S1027 are triggered by the ringback tone server receiving the SIP-INVITE / OK. In practice, the execution order of the two is not limited to Figure 10 as shown. For example, the ringback tone server can also execute S1027 between S1020 - S1023.

[0275] S1028. Network device _3 sends a SIP-INVITE / INFORMAL RESPONSE to the terminal device 200.

[0276] In S1028, the SIP-INVITE / INFORMAL RESPONSE can be used to further initiate a repeated invitation to the terminal device 200.

[0277] S1029. The terminal device 200 sends a SIP-INVITE / TRYING back to network device _3.

[0278] Similarly, the SIP-INVITE / TRYING can indicate that a call invitation has been received.

[0279] S1030. The terminal device 200 sends a SIP-INVITE / OK to network device _3, and the SIP-INVITE / OK does not carry SDP. For details, please refer to S901 above.

[0280] Similarly, the SIP-INVITE / OK can indicate that the terminal device 200 answers the call. And the SIP-INVITE / OK does not carry SDP, so it will not carry the codec. That is, the SIP-INVITE / OK in S1030 is the answer message 3.

[0281] S1031. Network device _3 sends a SIP-INVITE / OK to the terminal device 100. For details, please refer to S902 above.

[0282] S1032. The terminal device 100 feeds back a SIP-ACK / INFORMAL RESPONSE to the network device_3.

[0283] Similarly, the SIP-ACK / INFORMAL RESPONSE indicates that the SIP-INVITE / OK has been received.

[0284] S1033. The network device_3 sends a SIP-ACK / INFORMAL RESPONSE to the terminal device 200. The SIP-ACK / INFORMAL RESPONSE does not carry the SDP. For details, refer to S903 above.

[0285] The SIP-ACK / INFORMAL RESPONSE does not carry the SDP, so it will not carry the codec either, and it will not carry the indication information indicating whether the call is answered successfully. The call can be answered successfully. That is, the SIP-ACK / INFORMAL RESPONSE in S1033 is the confirmation message 3.

[0286] S1034. In response to receiving the SIP-ACK / INFORMAL RESPONSE, the terminal device 200 and the terminal device 100 start a voice call using codec3. For details, refer to S904 above.

[0287] The above Figure 9 and Figure 10In the embodiments, the fixed network call scenario is mainly taken as an example to illustrate the solution for improving the call answering success rate by means of the answering message 3. It should be noted that in a non-fixed network call scenario, between S900 and S704, the terminal device 100, the network side device (including Network_3 and the ringback tone server), and the terminal device 200 can further update the codec3 negotiated in the session progress message (such as by UPDATE) to negotiate a new codec supported by all three parties (denoted as codec4). In a typical scenario, between S900 and S704, the terminal device 100 and the network side device can negotiate the codec for ringback tone playback. During the negotiation process, the Network_3 in the network side device also interacts with the terminal device 200 to negotiate a codec4 supported by all three parties. Exemplarily, the process of the Network_3 interacting with the terminal device 200 includes: the terminal device 200 sends a SIP-UPDATE / INFORMAL RESPONSE message to the Network_3, and the SIP-UPDATE / INFORMAL RESPONSE sent by the terminal device 100 to the Network_3 carries SDP5, and SDP5 carries the codec supported by the terminal device 100. After receiving the SIP-UPDATE / INFORMAL RESPONSE message, the Network_3 can send a SIP-UPDATE / INFORMAL RESPONSE message to the terminal device 100, and the SIP-UPDATE / INFORMAL RESPONSE message sent by the Network_3 to the terminal device 100 carries SDP6, and SDP6 carries the code4 supported by both the SDP5, the network side device, and the terminal device 200. Since SDP5 carries the codec supported by the terminal device 100, the code4 supported by both the SDP5, the network side device, and the terminal device 200 is the codec supported by the terminal device 100, the network side device, and the terminal device 200.

[0288] That is to say, in a non-fixed network call scenario, the codec supported by all three parties may be updated from codec3 to codec4. Based on this, in a non-fixed network call scenario, the above S904 can be replaced with: in response to receiving the confirmation message 3, a voice call is started between the terminal device 200 and the terminal device 100 using codec4.

[0289] In other embodiments, please refer to Figure 11 , Figure 11 which is a flowchart of another call method provided by the embodiments of the present application. As Figure 11 shown, in the fixed network call scenario, the above Figure 7 S703 (the step of invitation response) further includes:

[0290] S1100. The terminal device 200 sends a session progress message to the network device _3. The session progress message includes codec3 that is supported by all of the terminal device 200, the network device _3, and the terminal device 100. For specific details, refer to the description of S900.

[0291] And, Figure 7 S714 - S718 after the terminal device 200 in the above receives a duplicate invitation message can be replaced with the following S1101 - S1105.

[0292] S1101. In response to receiving a duplicate invitation, the terminal device 200 sends an answer message 4 to the network device _3. The answer message 4 carries SDP3, and SDP3 includes codec3.

[0293] That is: In this embodiment, the codec negotiated between the terminal device 200 and the network device _3 before the duplicate invitation included in SDP3 is codec3.

[0294] Similar to S714 in the previous text, S1101 is also actively triggered, rather than being passively triggered by the user's answer operation.

[0295] Among them, the answer message 4 also indicates that the terminal device 200 has answered. Exemplarily, the answer message 3 can also be an INVITE / OK message.

[0296] S1102. The network device _3 forwards the answer message 4 to the terminal device 100. For specific details, refer to S715.

[0297] Furthermore, after the terminal device 100 receives the answer message 4, it can also feedback an answer confirmation message (SIP - ACK / INFORMAL RESPONSE) to the network device _3, as shown in S1032 in the previous text. Figure 10 as shown in

[0298] S1103. The network device _3 verifies codec3 in the answer message 4 and obtains a verification - consistent result.

[0299] codec3 is supported by all of the terminal device 100, the network device _3, and the terminal device 200. Therefore, when the network device _3 verifies codec3 in the answer message 4, by comparing codec3 with the codec it (i.e., the network device _3) supports, it can determine that codec3 is the codec it (i.e., the network device _3) supports, thus obtaining a verification - consistent result.

[0300] Exemplarily, codec3 includes 98 and 105, indicating that terminal device 100, network device_3, and terminal device 200 all support 98 and 105. The codecs supported by network device_3 include 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, 18, indicating that network device_3 also supports 98 and 105. When network device_3 verifies codec3, it can obtain a consistent verification result.

[0301] S1104. Network device_3 sends confirmation message 4 to terminal device 200 based on the verification result. Confirmation message 4 carries SDP4, and SDP4 includes the codecs supported by network device_3 in codec3 carried in SDP3 and the indication information of successful answering.

[0302] Among them, confirmation message 4 is used to indicate that answering message 4 has been received. Exemplarily, confirmation message 4 is a SIP-ACK / INFORMAL RESPONSE message.

[0303] Since the verification result is consistent, network device_3 can add the indication information of successful answering, such as acitive, in confirmation message 4. Also, network device_3 can add the codecs supported by network device_3 in codec3 in answering message 4. Since all codecs in codec3 are supported by network device_3, the codecs supported by network device_3 in codec3 are still codec3. That is, what is carried in confirmation message 4 is still codec3. Exemplarily, if codec3 includes 98 and 105, then 98 and 105 are still carried in confirmation message 4.

[0304] S1105. In response to receiving confirmation message 4, terminal device 200 and terminal device 100 start a voice call using the codec carried in confirmation message 4.

[0305] Since answering message 4 includes the indication information of successful answering, the call can be answered successfully. In this case, terminal device 200 can use the codec carried in answering message 4, that is, codec3, to conduct a voice call with terminal device 100.

[0306] Similar to the previous Figure 9 embodiment, if there are multiple codecs carried in confirmation message 4, terminal device 100 and terminal device 200 can select one from the multiple codecs for the voice call.

[0307] It can be seen that by adopting this embodiment, in the fixed network call scenario, after receiving a repeated invitation, terminal device 200 can improve the answering success rate in the fixed network call scenario by sending the verified codec to network device_3.

[0308] Further, Figure 11 For the specific implementation of the call method shown, reference can be made to the relevant description in the foregoing Figure 10 . Specifically, only Figure 10 S1030 - S1034 in Figure 11 needs to be replaced with the corresponding steps in

[0309] The above Figure 11 In the embodiment above, taking the fixed network call scenario as an example, a solution for improving the call answering success rate by means of the answering message 4 is described. Based on the foregoing description, it can be known that in a non-fixed network call scenario, the codec supported by all three may be updated from codec3 to codec4. That is: in a non-fixed network call scenario, the codec negotiated between the terminal device 200 and the network device_3 before the repeated invitation included in SDP3 is codec4.

[0310] Based on this, in a non-fixed network call scenario, codec3 in the above S1101 - S1105 can also be replaced with codec4. For the specific implementation principle, reference can be made to the description of S1101 - S1105, which will not be elaborated here.

[0311] Please refer to Figure 12 , Figure 12 which is a hardware structure diagram of a terminal device (such as terminal device 100, terminal device 200) provided in an embodiment of the present application. As Figure 12 shown, taking the terminal device as a mobile phone as an example, the terminal device may include: a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a SIM card interface 195, etc. Among them, the audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, a headphone interface 170D, etc., and the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0312] It can be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the terminal device. In other embodiments, the terminal device may include more or fewer components than those illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0313] Among them, the processor 110 may include one or more processing units. For example, the processor may include an Application Processor (AP), a Modem (which may also be referred to as a baseband processor), a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a video codec, a Digital Signal Processor (DSP), and / or a Neural-network Processing Unit (NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors. The processor is the nerve center and command center of the terminal device. The controller can generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching instructions and executing instructions.

[0314] In some embodiments of the present application, the terminal device 200 may execute the steps performed by the terminal device 200 in the call method shown above through the AP and Modem in the above-mentioned processor 110. Figure 7 、 Figures 9 to 11 For example, it may execute S901 in the above-mentioned Figure 9 to improve the call answering success rate by sending an answer message 3 without carrying SDP; or, it may execute S1101 in the above-mentioned Figure 11 to improve the call answering success rate by sending an answer message 4 carrying codec3 in the session progress message.

[0315] The wireless communication function of the terminal device can be implemented through Antenna 1, Antenna 2, Mobile Communication Module 150, Wireless Communication Module 160, and Modem, etc. Among them, Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. The Mobile Communication Module 150 can provide solutions for wireless communications such as 2G / 3G / 4G / 5G / 6G applied to the terminal device. The Wireless Communication Module 160 can provide solutions for wireless communications including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), etc. applied to the terminal device.

[0316] In some embodiments, Antenna 1 of the terminal device is coupled to the Mobile Communication Module 150, and Antenna 2 is coupled to the Wireless Communication Module 160, enabling the terminal device to communicate with network-side devices and other terminal devices through wireless communication technologies. Exemplarily, the terminal device 200 can communicate with Network Device_3 through Antenna 1 and the Mobile Communication Module 160.

[0317] The terminal device can implement the display function through the display screen 194, as well as the GPU, AP, etc. in the above-mentioned processor 110. Exemplarily, the terminal device 200 can display the above-mentioned Figure 8 each interface through the display screen 194, as well as the GPU, AP, etc. in the above-mentioned processor 110.

[0318] The terminal device can implement the audio function through the audio module 170 and the AP, etc. Exemplarily, the terminal device 200 can answer calls through the receiver 170B in the audio module 170, and can collect the voice input by the user through the microphone 170C in the audio module 170.

[0319] In addition, on top of the above-mentioned Figure 12 shown hardware structure, the operating system of the terminal device also runs. For example, the iOS TM operating system developed by Apple Inc., the Android TM open-source operating system developed by Google Inc., the Windows TM operating system developed by Microsoft Corporation, etc.

[0320] The operating system of the terminal device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservices architecture, or cloud architecture. In this application embodiment, the Android TM system with a layered architecture is taken as an example to exemplarily illustrate the software and hardware structure of the terminal device. It should be noted that although this application embodiment takes Android TMTake the [system] as an example for illustration, but its basic principle also applies to terminal devices based on iOS TM or Windows TM and other operating system-based terminal devices.

[0321] Please refer to Figure 13 , Figure 13 which is a software structure block diagram of a terminal device provided by an embodiment of the present application. The software structure adopts a layered architecture. The layered architecture divides the software into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. As Figure 13 shown, taking the Android TM system running on the AP as an example, in some embodiments, the Android TM system is divided into five layers, from top to bottom are the application layer, the application framework layer (Framework), the Android runtime, the system libraries, the hardware abstraction layer (HAL), and the kernel layer (Kernel).

[0322] Among them, the application layer may include a series of application packages. The application packages may include applications (application, APP) such as the camera, gallery, calendar, call, map, WLAN, Bluetooth, music, video, short message, etc. The call APP is used to make calls.

[0323] The application layer may also include a system user interface (system user interface, systemUI), and the systemUI is used to display the interface of the terminal device, such as displaying the signal icon corresponding to the SIM card, displaying the call interface, etc.

[0324] The application framework layer provides application programming interfaces (Application Programming Interface, API) and programming frameworks for the applications in the application layer. The application framework layer includes some predefined functions. For example, the application framework layer may include a window manager, a content provider, a view system, a telephone manager, a resource manager, a notification manager, etc.

[0325] The telephone manager is used to provide the call function of the terminal device. For example, the management of the call state (including connection, hangup, etc.), and the telephone manager is represented by telephony in Figure 13 .

[0326] The application framework layer may also include a Radio Interface Layer (RIL). The Modem in the aforementioned hardware structure can interact with telephony through the RIL to achieve calls.

[0327] The system library may include a surface manager, a 3D graphics processor, a 2D graphics engine, a media library, etc.

[0328] The hardware abstraction layer runs in the user space, encapsulates the kernel layer drivers, and provides call interfaces to the upper layer. Exemplarily, the hardware abstraction layer may include a display HAL, a camera HAL, an audio HAL, a sensor HAL, etc.

[0329] The kernel layer is the layer between hardware and software. The kernel layer at least includes a display driver, a camera driver, an audio driver, a sensor driver, etc.

[0330] Continue to refer to Figure 13 , the software structure of the terminal device further includes the software composition of the Modem. The software composition of the Modem includes a communication protocol stack and a physical (PHY) layer, which are used to implement the communication between the terminal device and the network-side device or other terminal devices.

[0331] The Modem may include a Non-Access Stratum (NAS) layer, a radio resource control (RRC) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control Layer (MAC) layer, and a PHY layer. The foregoing layers may be software modules. Among them, the NAS layer, the RRC layer, the PDCP layer, the RLC layer, and the MAC layer constitute the communication protocol stack.

[0332] Continue to refer to Figure 13 , the Modem can interact with the network-side device (such as a base station) through an antenna.

[0333] In addition, some embodiments of the present application provide a terminal device, which includes: one or more processors and a memory; the memory is used to store computer program code, and the computer program code includes computer instructions. When the one or more processors execute the computer instructions, the terminal device executes the above call method.

[0334] Some embodiments of the present application provide a chip system, which is applied to a terminal device. The chip system includes at least one processor and an interface. The interface is configured to receive instructions and transmit them to at least one processor. The at least one processor runs the instructions to cause the terminal device to execute the above-mentioned call method. Among them, the chip system may be a Modem or a System on Chip (Soc) including a Modem, and the above method may be implemented by a single Modem.

[0335] This embodiment also provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions run on the terminal device, the terminal device is caused to execute each function or step in the above method embodiment.

[0336] This embodiment also provides a computer program product. When the computer program product runs on a computer, the computer is caused to execute each function or step in the above method embodiment.

[0337] In addition, an embodiment of the present application also provides a device, which may specifically be a chip, a component or a module. The device may include a processor and a memory connected to each other. Among them, the memory is configured to store computer execution instructions. When the device runs, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute each function or step in the above method embodiment.

[0338] Among them, the chip system, the computer-readable storage medium, the computer program product or the device provided in this embodiment are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be elaborated here.

[0339] Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above division of each functional module is used as an example. In actual applications, the above functions may be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0340] In several embodiments provided in the present 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 merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling, direct coupling, or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the devices or units can be in electrical, mechanical, or other forms.

[0341] The unit described as a separated component may or may not be physically separated. The component displayed as a unit may be a physical unit or multiple physical units, that is, it can be located in one place, or it can be distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0342] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0343] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on such an understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods in various embodiments of the present application. The foregoing storage medium includes: various media such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc that can store program codes.

[0344] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present application and are not limiting. Although the present application has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that the technical solution of the present application can be modified or equivalently replaced without departing from the spirit and scope of the technical solution of the present application.

Claims

1. A call method, characterized in that, Applied to a terminal device, the method includes: The terminal device receives a first invitation message, which is related to a first call for calling the terminal device; The terminal device receives an answer operation; In response to the answer operation, the terminal device sends a first answer message; When the terminal device subscribes to a ringback tone service: After sending the first answer message, the terminal device receives a second invitation message, which is related to the first call; After the terminal device receives the second invitation message, the terminal device sends a second answer message. The second answer message does not carry the Session Description Protocol (SDP) describing the session, or the second answer message carries a first SDP, and the first SDP carries a first voice codec format, which is the voice codec format negotiated between the terminal device and the network-side device after the terminal device receives the first invitation message and before receiving the second invitation message; The terminal device plays the call voice of the first call using the first voice codec format.

2. The method according to claim 1, wherein The second answer message does not carry an SDP; After the terminal device sends the second answer message, the method further includes: The terminal device receives a first confirmation message, which does not carry the SDP, and the first confirmation message is a confirmation message for the second answer message.

3. The method according to claim 1 or 2, characterized in that, The second answer message carries a first SDP, and the first SDP carries the first voice codec format; After the terminal device sends the second answer message, the method further includes: The terminal device receives a second confirmation message from the network-side device. The second confirmation message carries a second SDP, and the second SDP carries first indication information indicating that the first call is successfully activated. The second SDP also carries a second voice codec format, which is the voice codec format supported by the network-side device among the first voice codec formats.

4. The method according to any one of claims 1 to 3, characterized in that The first call is a fixed network call, which includes a fixed telephone call or an Internet Protocol (IP) telephone call. The first invitation message carries a third SDP, and the third SDP carries a third voice codec format; After the terminal device receives the first invitation message and before receiving the second invitation message, the method further includes: The terminal device sends a session progress message, which carries a fourth SDP, and the fourth SDP carries a fourth voice codec format, which is the format supported by the terminal device among the third voice codec formats; Among them, the voice codec format negotiated between the terminal device and the network-side device after the terminal device receives the first invitation message and before receiving the second invitation message includes: the fourth voice codec format carried by the fourth SDP.

5. The method according to any one of claims 1 to 3, characterized in that The first call is a non-fixed network call, which is a call other than a fixed telephone call and an Internet Protocol (IP) telephone call; After the terminal device receives the first invitation message and before it receives the second invitation message, the method further includes: The terminal device sends a session progress message, the session progress message carries a fourth SDP, the fourth SDP carries a fourth voice codec format, and the fourth voice codec format is a format supported by both the terminal device and the network side device; The terminal device receives an update message, the update message carries a fifth SDP, the fifth SDP carries a fifth voice codec format, and the fifth voice codec format is a voice codec format supported by both the network side device and the terminal device; Wherein, the voice codec format negotiated between the terminal device and the network side device after the terminal device receives the first invitation message and before it receives the second invitation message includes the fifth voice codec format.

6. The method according to any one of claims 1-5, characterized in that The method further includes at least one of the following: The first invitation message and the second invitation message are INVITE / INFORMAL RESPONSE messages; or, the first answer message and the second answer message are INVITE / OK messages; or, the first confirmation message is an ACK / INFORMAL RESPONSE message; or, the second confirmation message is an ACK / INFORMAL RESPONSE message; or, the session progress message is an INVITE / SESSION PROGRESS message; The update message is an UPDATE / INFORMALRESPONSE message.

7. A call method, characterized in that, Applied to the network side device, the method includes: The network side device sends a first invitation message to the terminal device, the first invitation message is related to a first call for calling the terminal device, and the terminal device subscribes to a ringback tone service; The network side device receives the first answer message of the terminal device, and the first answer message is sent by the terminal device in response to a user's answer operation; After receiving the first answer message, the network side device sends a second invitation message to the terminal device; The network side device receives the second answer message of the terminal device, the second answer message does not carry the protocol SDP describing the session, or the second answer message carries a first SDP, the first SDP carries a first voice codec format, and the first voice codec format is the voice codec format negotiated between the network side device and the terminal device after the network side device sends the first invitation message and before it sends the second invitation message.

8. The method according to claim 7, wherein After the network side device receives the second answer message of the terminal device, the method further includes: In the case that the second answer message does not include the protocol SDP describing the session, the network side device sends a first confirmation message to the terminal device, and the first confirmation message does not carry an SDP; When the second answer message carries the first SDP and the first SDP carries the first voice codec format, the network-side device sends a second confirmation message to the terminal device. The second confirmation message carries a second SDP. The second SDP carries first indication information indicating that the activation of the first call is successful. The second SDP also carries a second voice codec format, and the second voice codec format is a voice codec format supported by the network-side device among the first voice codec formats.

9. A terminal device, characterized in that, Comprising: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the terminal device executes the method according to any one of claims 1-6.

10. A network-side device, characterized in that, Comprising: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the network-side device executes the method according to claim 7 or 8.

11. A chip system, characterized in that, Comprising at least one processor and a communication interface. The communication interface and the at least one processor are interconnected by a line. The at least one processor is configured to run a computer program or instructions to execute the method according to any one of claims 1-6, or the method according to claim 7 or 8.

12. A computer-readable storage medium having computer instructions stored thereon, characterized in that, When the computer instructions run on the terminal device, the terminal device is caused to execute the method according to any one of claims 1-6; or when the computer instructions run on the network-side device, the network-side device is caused to execute the method according to claim 7 or 8.

Images