Call method and terminal device

Abstract

A call method and a terminal device, relating to the technical field of communications. The method comprises: a terminal device receives a first invite message, the first invite message being related to a first call; the terminal device receives an answering operation; in response to the answering operation, the terminal device sends a first answering message; when the terminal device subscribes to a color ring back tone service, the terminal device receives a second invite message, the second invite message being related to the first call; the terminal device sends a second answering message, the second answering message not carrying a protocol SDP describing a session, or the second answering message carrying a first SDP, and the first SDP carrying a first voice encoding / decoding format; and the terminal device plays back the call voice of the first call in the voice encoding / decoding format obtained by negotiating with a network side device after the terminal device receives the first invite message and before the terminal device receives the second invite message. In this way, the success rate of call answering can be improved.

Description

A calling method and terminal device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 12, 2024, with application number 202410054709.3 and invention name “A Method for Conversation”, the entire contents of which are incorporated by reference into this application.

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 15, 2024, with application number 202410306521.3 and invention name “A Call Method and Terminal Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a communication method and terminal equipment. Background Art

[0004] Making and receiving calls is one of the most basic functions of mobile phones, tablets and other terminal devices. Generally, a terminal device can actively make calls to other terminal devices, and can also receive passive calls from other terminal devices.

[0005] In scenarios where a terminal device receives a call from a fixed-line telephone (abbreviated as fixed-line telephone, also known as wired telephone, landline, etc.) or Internet Protocol (IP) telephone (such as 95030 telephone, etc.) (hereinafter collectively referred to as fixed-line call scenarios), after the terminal device receives the user's answering operation, the call may be silent and automatically disconnected after a period of time. Summary of the Invention

[0006] In view of this, an embodiment of the present application provides a calling method and a terminal device, which can improve the success rate of call connection.

[0007] In a first aspect, embodiments of the present application provide a call method, comprising: a terminal again sending a 200 OK message to a network, wherein the 200 OK message does not carry an SDP (in some implementations, the absence of an SDP message can be understood as the absence of a codec); and the terminal receiving an ACK sent by the network after receiving the 200 OK message. It is understood that after receiving the 200 OK message, the network does not further check the codec and instead responds with a normal ACK, thereby allowing the call to connect normally.

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

[0009] The terminal receives a first invite message sent by the network, where the first invite message carries a first set, where the first set is a codec set of voice codec formats supported by the network;

[0010] After receiving the first invite message, the terminal sends a 183 message to the network, where the 183 message carries a second set, where the second set is a codec set supported by the terminal in the first set;

[0011] After receiving the first operation of the user on the terminal, the terminal sends a 200 OK message to the network, where the 200 OK message does not carry SDP, wherein the first operation is used to instruct the terminal to answer the call;

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

[0013] The terminal sending the 200 OK message to the network again includes:

[0014] After receiving the second invite message, the terminal sends the 200 OK message to the network again, where the 200 OK message does not carry the SDP.

[0015] In a second aspect, an embodiment of the present application provides a call method, comprising: a terminal again sending a 200 OK message to a network, the 200 OK message carrying a third set, the third set being a set consisting of some or all codecs in a set of codecs for voice codec formats supported by the terminal, and the codecs included in the third set being some or all of the codecs included in the set of codecs carried in a 183 message received by the terminal before sending the 200 OK message; and the terminal receiving an ACK sent by the network after receiving the 200 OK message. It is understandable that the network has already verified the codec in the 183 message, and therefore, the network will respond with a normal ACK after receiving the 200 OK message, so the call can be connected normally.

[0016] In some implementations, before the terminal sends the 200 OK message to the network again, the method further includes:

[0017] The terminal receives a first invite message sent by the network, where the first invite message carries a first set, where the first set is a codec set of voice codec formats supported by the network;

[0018] After receiving the first invite message, the terminal sends a 183 message to the network, where the 183 message carries a second set, where the second set is a codec set supported by the terminal in the first set;

[0019] After receiving the first operation of the user on the terminal, the terminal sends a 200 OK message to the network, where the 200 OK message does not carry SDP, wherein the first operation is used to instruct the terminal to answer the call;

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

[0021] The terminal sending the 200 OK message to the network again includes:

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

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

[0024] In some implementations, the first invite message is used to call the terminal.

[0025] In a third aspect, an embodiment of the present application provides a calling method, which is applied to a terminal device, which is a called terminal device, such as the terminal device 200 mentioned below.

[0026] Specifically, the terminal device receives a first invitation message (such as the call invitation in S702 below), which is related to a first call (such as a call with the called number being Phone Number 1 below), and the first call is used to call the terminal device. The terminal device receives an answer operation, such as a user clicking an answer button. In response to the answer operation, the terminal device sends a first answer message, such as Answer Message 1 below.

[0027] When a terminal device subscribes to a ringback tone service: after sending a first answer message, the terminal device receives a second invitation message (such as the repeated invitation described below), and the second invitation message is also related to the first call. In other words, two call invitations are initiated for the same 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 SDP protocol describing the session, such as answer message 3 described below. It is understood that the voice codec format is usually carried by SDP. The fact that the second answer message does not carry SDP indicates that the second answer message does not carry the voice codec format. Alternatively, the second answer message carries the first SDP, and the first SDP carries the first voice codec format, such as answer message 3 described below. The first voice codec format is the voice codec format negotiated between the terminal device and the network device after receiving the first invitation message and before receiving the second invitation message. The network device can be a general term for network device_3 and ringback tone server below, or it can refer to network device_3 alone, and this application does not specifically limit this. The terminal device plays the call audio of the first call using the first voice codec format.

[0028] In summary, by adopting the present application, when a terminal device subscribes to a ringback tone service, after the terminal device receives a repeated invitation, i.e., a second invitation message, the terminal device will not send an answering message carrying all voice codec formats supported by the terminal device, such as the answering message 2 mentioned below, but will send a message that does not carry a 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 answering message, the network-side device will not verify that the voice codec format in the second answering message is inconsistent with the voice codec format supported by the network-side device, and thus will not feedback an indication 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 will not cause call answering failure due to inconsistency between the voice codec formats supported by the network-side device and the terminal device, thereby improving the success rate of call answering.

[0029] In one possible implementation of the third aspect, the second answer message does not carry the SDP, corresponding to answer message 3 below. After the terminal device sends the second answer message, the method further includes: the terminal device receives a first confirmation message (such as confirmation message 3 below), the first confirmation message does not carry the SDP, and the first confirmation message is a confirmation message of the second answer message.

[0030] In other words, in an implementation where the second answer message does not carry the voice codec format, the first confirmation message returned by the network device for the second answer message naturally does not carry the SDP. Furthermore, the call activation success indication is carried in the SDP, so the first confirmation message does not include this indication. In this case, the terminal device can default to the first voice codec format negotiated with the network device for the voice call.

[0031] In one possible implementation of the third aspect, the second answer message carries a first SDP, which carries a first voice codec format, corresponding to answer message 4 described below. 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 confirmation message 4 described below), the second confirmation message carries a second SDP, the second SDP carries first indication information (such as active described below), the first indication information indicates that the first call is successfully activated, and the second SDP further carries a second voice codec format, which is a voice codec format supported by the network-side device among the first voice codec formats.

[0032] That is to say, in the implementation method in which 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 by 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 in the first voice codec format 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 to make a voice call.

[0033] In one possible implementation of the third aspect, the first call is a fixed-line call. A fixed-line call may refer to a call in which the call initiator (e.g., terminal device 100, as described below) is a dial-up terminal for a fixed-line phone or an IP phone. In other words, a fixed-line call may refer to a fixed-line phone call or an IP phone call. The first invite message carries a third SDP, which carries a third voice codec format, such as codec2, as described below. The third voice codec format is a voice codec format supported by both the network-side device and the call initiator.

[0034] 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, the session progress message carries a fourth SDP, and the fourth SDP carries a fourth voice codec format (such as codec3 below). The fourth voice codec format is a format in the third voice codec format that is supported by the terminal device. 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 both the network-side device and the call initiator, and of course, it is also a voice codec format supported by both the network-side device and the call initiator.

[0035] It can be seen that during a fixed-line 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 the fourth voice codec format with the network device through the session progress message. That is, during a fixed-line call, the voice codec format negotiated between the terminal device and the network device after receiving the first invitation message and before receiving the second invitation message can be the fourth voice codec format.

[0036] In one possible implementation of the third aspect, the first call is a non-fixed-line call. A non-fixed-line call may refer to a call in which the call initiator (such as terminal device 100 below) is not a dial-up terminal for a fixed-line phone or IP phone. In other words, a non-fixed-line call may refer to a call other than a fixed-line phone call or an IP phone call. For example, a non-fixed-line call is a regular call received from a mobile phone.

[0037] 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-line call, the voice codec format can also be negotiated through the session progress message. Afterwards, the terminal device and the network side device can further negotiate a new voice codec format through an update (i.e., UPDATE) message, that is, update the negotiated voice codec format. Specifically, the terminal device can receive an update message from the network side device, and the update message carries the fifth SDP (such as SDP5 below), and the fifth SDP carries the fifth voice codec format (such as codec4 below), 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.

[0038] It can be seen that in a non-fixed-line 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 the fifth voice codec format with the network device through an update message. That is, in a non-fixed-line call, the voice codec format negotiated between the terminal device and the network device after receiving the first invitation message and before receiving the second invitation message can be the fifth voice codec format.

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

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

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

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

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

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

[0045] In a fourth aspect, an embodiment of the present application provides a call method, which is applied to a network side device. Specifically, the network side device sends a first invitation message to the terminal device, and the first invitation message is related to the first call. The first call is used to call the terminal device, and the terminal device subscribes to a ringback tone service. The network side device receives a first answer message from 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 from the terminal device, and the second answer message does not carry the protocol SDP describing the session, or the second answer message carries the first SDP, and the first SDP carries the first voice codec format. The first voice codec format is the voice codec format negotiated between the network side device and the terminal device after sending the first invitation message and before sending the second invitation message.

[0046] In a possible implementation of the fourth aspect, after the network-side device receives a second answer message from the terminal device, the method further includes: if the second answer message does not include the SDP protocol describing the session, the network-side device sends a first confirmation message to the terminal device, the first confirmation message not carrying the SDP. If 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, the first indication information indicates that the first call activation was successful, the second SDP also carries a second voice codec format, the second voice codec format being a voice codec format supported by the network-side device in the first voice codec format.

[0047] In the fifth aspect, an embodiment of the present application provides a terminal device, 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 of the first aspect to the fourth aspect and any implementation method.

[0048] In the sixth aspect, an embodiment of the present application provides a network side device, comprising: a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, so that the network side device executes the method of the first aspect to the fourth aspect and any implementation method.

[0049] In the seventh aspect, an embodiment of the present application provides a chip system, comprising at least one processor and a communication interface, the communication interface and at least one processor being interconnected by lines, and the at least one processor being used to run computer programs or instructions to execute methods such as those in the first to fourth aspects and any implementation method.

[0050] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method according to the first to fourth aspects and any implementation manner.

[0051] In a ninth aspect, an embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is run, the computer executes the method of the first to fourth aspects and any implementation method.

[0052] In a tenth aspect, an embodiment of the present application provides a communication system, comprising a terminal device and a network-side device. The terminal device is configured to execute the method of the first to third aspects and any implementation thereof, and the network-side device is configured to execute the method of the fourth aspect and any implementation thereof.

[0053] It can be understood that the beneficial effects that can be achieved by the above-mentioned calling method of the fourth aspect, the terminal device of the fifth aspect, the network side device of the sixth aspect, the chip system of the seventh aspect, the computer-readable storage medium of the eighth aspect, the computer program product of the ninth aspect and the communication system of the tenth aspect can be referred to the beneficial effects of the first to third aspects and any possible design methods thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] FIG1 is a timing interaction diagram of a call method according to an embodiment of the present application;

[0055] FIG2 is a second sequential interaction diagram of the call method provided in an embodiment of the present application;

[0056] FIG3 is a third sequential interaction diagram of the call method provided in an embodiment of the present application;

[0057] FIG4 is a schematic diagram of a network architecture provided in an embodiment of the present application;

[0058] FIG5 is a schematic diagram of an architecture of a communication system according to an embodiment of the present application;

[0059] FIG6 is a second schematic diagram of the architecture of the communication system provided in an embodiment of the present application;

[0060] FIG7 is a fourth timing interaction diagram of the call method provided in an embodiment of the present application;

[0061] FIG8 is a schematic diagram showing changes in a mobile phone interface after receiving an incoming call according to an embodiment of the present application;

[0062] FIG9 is a fifth sequential interaction diagram of the call method provided in an embodiment of the present application;

[0063] FIG10 is a diagram illustrating a specific implementation of the calling method shown in FIG9 ;

[0064] FIG11 is a sixth sequential interaction diagram of the call method provided in an embodiment of the present application;

[0065] FIG12 is a hardware structure diagram of a terminal device provided in an embodiment of the present application;

[0066] FIG13 is a software architecture diagram of a terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0067] The technical solution in this application will be described below with reference to the accompanying drawings.

[0068] 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, Internet of Vehicles communication systems, 4th generation (4G) mobile communication systems, such as long term evolution (LTE) systems, world-wide interoperability for microwave access (WiMAX) communication systems, fifth generation (5G) mobile communication systems, such as new radio (NR) systems, and future communication systems, such as sixth generation (6G) mobile communication systems.

[0069] This application will present various aspects, embodiments, or features in the context of systems 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 of the devices, components, modules, etc. discussed in conjunction with the figures. Furthermore, combinations of these aspects may also be used.

[0070] Additionally, in the embodiments of this application, words such as "exemplarily" and "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as an "exemplary" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of the word "exemplary" is intended to present concepts in a concrete manner.

[0071] First, in this application, "used to indicate" can include being used for direct indication and being used for indirect indication. When describing a certain "information" as being used to indicate A, it can include whether the information directly indicates A or indirectly indicates A, but it does not necessarily mean that the information contains A.

[0072] The information indicated by a message is called information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as 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. The information to be indicated can also be indirectly indicated by indicating other information, where there is an association between the other information and the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can be achieved by means of the arrangement order of each piece of information agreed in advance (such as specified in the protocol), thereby reducing the indication overhead to a certain extent. At the same time, the common parts of each piece of information can be identified and indicated uniformly to reduce the indication overhead caused by indicating the same information separately.

[0073] In addition, the specific indication method can also be various existing indication methods, such as but not limited to the above-mentioned indication methods and various combinations thereof. The specific details of the various indication methods can be referred to the prior art and will not be repeated 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 for different information are different. In the specific implementation process, the required indication method can be selected according to specific needs. The embodiment of the present application does not limit the selected indication method. In this way, the indication method involved in the embodiment 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.

[0074] The information to be indicated can be sent as a whole, or divided into multiple sub-information and sent separately, and the sending period and / or sending time of these sub-information can be the same or different. The specific sending method is not limited in this application. Among them, the sending period and / or sending time of these sub-information can be predefined, for example, predefined according to the protocol, or 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 a combination of at least two of radio resource control (RRC) signaling, medium access control (MAC) layer signaling and physical layer signaling. Among them, MAC layer signaling, for example, includes MAC control element (CE); physical (PHY) layer signaling, for example, includes downlink control information (DCI).

[0075] Second, in the embodiments shown below, the first, second, and various numerical numbers are only used for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

[0076] Third, “pre-set”, or “pre-defined”, or “pre-configured” can be implemented by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in a device (for example, including a terminal and a network device), or can be pre-specified in a protocol, and this application does not limit its specific implementation method. Among them, “saving” can mean saving in one or more memories. The one or more memories can be set separately, or integrated in an encoder or decoder, a processor, or a communication device. The one or more memories can also be partially set separately, and partially integrated in a decoder, a processor, or a communication device. The type of memory can be any form of storage medium, and this application does not limit it.

[0077] Fourth, the “protocol” involved in the embodiments of the present application may refer to a standard protocol in the field of communications, for example, it may include 3GPP’s LTE protocol (such as technical specification (TS) 36, i.e., TS36 series technical specifications), NR protocol (such as TS38 series technical specifications) and related protocols used in future communication systems. This application does not limit this.

[0078] The network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field will know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0079] Project Background:

[0080] During a call, codec negotiation occurs during Session Initiation Protocol (SIP) signaling to determine a codec format supported by both parties. Codecs are voice codecs, and communication between the network and the terminal requires that both parties agree on a supported codec format.

[0081] During a call, codec negotiation occurs during SIP signaling to determine a codec format supported by both parties. Codecs are voice codecs, and communication between the network and endpoint requires that both parties agree on a supported codec format.

[0082] Problem scenario:

[0083] When a user receives an IP call from 95030, there is no sound and the call is automatically disconnected after 20 seconds.

[0084] Cause Analysis:

[0085] Please refer to Figure 1, which is a flow chart of a call method provided by an embodiment of the present application. The following is an analysis of the causes of the above problem scenario in conjunction with Figure 1:

[0086] 1) The network sends an initial 1.INVITE (the message shown in Figure 1 below, also referred to as the first invite message herein) 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 herein. It should be noted that the set described herein 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 a set of codecs supported by the network; the first set may be a set consisting of all codecs supported by the network, or a set consisting of some codecs among all codecs supported by the network;

[0087] 2) The terminal sends a 3.183 message (the 183 message shown in 3 in Figure 3 below) to the network, carrying codecs 98 to 105 (also referred to herein as the second set). 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 a codec supported by both the network and the terminal;

[0088] 3) After the user clicks on the call to answer, the terminal sends a 7.200 OK message (as shown in 7 in the figure below) to the network, without SDP.

[0089] 4) The network will send another invite message, such as 9.re-invite (the message shown in 9 in the figure below, also referred to as the second invite message in this document) to the terminal. The message does not carry SDP (re-invite is required in the case of ringback tone).

[0090] 5) The terminal sends 11.200 OK message again (as shown in 11 in the figure below), which carries SDP and contains all codecs 98 102 105 97 supported by the terminal (i.e., the full set of codecs supported by the terminal), including codec 97 which is not supported by the network;

[0091] 6) The network sends 12.ACK to the terminal, carrying SDP, which contains inactive;

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

[0093] 7) After receiving the inactive message, the terminal cannot send uplink messages, and the network will not send downlink messages. The call is dropped after 20 seconds of silence.

[0094] Option 1:

[0095] In the scenario shown in FIG1 , an embodiment provided by the present application is shown in FIG2 below. For the parts that are the same as FIG1 , reference can be made to the description of FIG1 . The main difference between FIG2 and FIG1 is that the messages corresponding to 11 and 12 shown in FIG2 carry different contents than the messages corresponding to 11 and 12 shown in FIG1 . 11 and 12 shown in FIG2 can be understood as:

[0096] 1) The terminal sends 11.200 OK again without SDP;

[0097] 2) The network will no longer check the codec and will return a normal ACK, and the call will be connected normally;

[0098] Option 2:

[0099] In the scenario shown in FIG1 , an embodiment provided by the present application is shown in FIG3 . For the parts that are the same as those in FIG1 , reference can be made to the description of FIG1 . The main difference between FIG3 and FIG1 is that the messages corresponding to 11 and 12 shown in FIG3 carry different contents than the messages corresponding to 11 and 12 shown in FIG1 . 11 and 12 shown in FIG3 can be understood as:

[0100] 1) The terminal sends 11.200 OK again, carrying the same SDP codecs 98 to 105 as those carried in the 183 message, or carrying a portion of the codecs carried in the 183 message, for example, codec 98. The codec set carried in the 200 OK message is also referred to herein as a third set. It will be understood that the codecs included in the third set are part or all of the codecs included in the second set.

[0101] 2) The network has verified the codec in 183 and will return a normal ACK, and the call is connected normally;

[0102] Some embodiments of the present invention provide benefits for answering calls.

[0103] Please refer to Figure 4, which is a schematic diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 4, the network architecture may include terminal devices, LTE, NR, core network, and IMS or the Internet. The following is a detailed description of it:

[0104] (1) Terminal: A terminal can be a terminal with transceiver functions, or a chip or chip system installed in the terminal. Terminals can also be called user equipment (UE), user terminal, mobile station (MS), mobile terminal (MT), etc. Terminals can be mobile phones, cellular phones, smart phones, tablet computers, or wearable devices (such as smart watches).

[0105] (2) LTE: This can be understood as the wireless access network of the 4G network. In the LTE network (commonly known as the 4G network), due to the evolutionary relationship, the access network part is called the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). In this application, the meaning of LTE is the same as that of E-UTRAN, both referring to the access network part of the 4G network. Terminal devices can access LTE through 4G base stations.

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

[0107] As you can understand, both LTE and NR are access networks. The access network uses wired or wireless connections and communication technologies to connect end users to the core network (also known as the backbone) at the first level, establishing connectivity. The access network is the edge of the network, the part closest to users and often referred to as the "last mile."

[0108] (4) Core Network: Its main functions are to provide user connections, user management, and service delivery. It serves as a bearer network and provides an interface to external networks. Establishing user connections includes functions such as mobility management (MM), call management (CM), switching / routing, and recording notifications (combined with intelligent network services to complete connections to intelligent network peripheral devices).

[0109] The core network of a 4G network is the Evolved Packet Core (EPC). The EPC is the core network of a 4G mobile communications network. It encompasses traditional mobile network capabilities, such as user subscription data storage, mobility management, and data exchange, and provides users with an ultra-high-speed Internet experience. The core network of a 5G network is the 5G Core (abbreviated as 5GC). 5GC uses general-purpose network function virtualization equipment to replace the dedicated communication equipment of 4G networks.

[0110] It should be noted that the core network in the network architecture shown in Figure 4 can be obtained by integrating EPC and 5GC. That is to say, the core network in the network architecture can include both network elements in EPC and network elements in 5GC. For example, the core network in the network architecture can include 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 function (UDM) network element and home subscriber server (HSS) network element, etc.

[0111] In some embodiments of the present application, the core network in the network architecture may include converged network elements 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.

[0112] In some embodiments of the present application, the core network in the network architecture shown in FIG4 may include a Proxy Session Border Control (PSBC) network element, which is a combined network element that integrates a Session Border Control (SBC), a Proxy-Call Session Control Function (P-CSCF), an Access Transfer Control Function (ATCF), and an Access Transfer Gateway (ATGW). As an SBC network element, it connects the IMS core network / softswitch network with the external user access area, provides service access for IMS / softswitch users, enables interoperability of user services in different network environments, ensures IMS / softswitch network security, and supports QoS management, CAC traffic control, media management, CDR media call detail records, and other functions.

[0113] Each network element in the core network can also be called a functional entity, which can be a network element implemented on dedicated hardware, a software instance running on dedicated hardware, or an instance of a virtualized function on an appropriate platform.

[0114] It should be understood that the names of all network elements in this application are only examples. In future communications, such as 6G, they may also be called other names, or, in future communications, such as 6G, the network elements involved in this application may also be replaced by other entities or devices with the same functions, etc., and this application does not limit this. A unified explanation is given here and will not be repeated later. Optionally, the 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, etc., and this embodiment of the present application does not limit this.

[0115] It is understood that the core network in the network architecture shown in Figure 4 may also include other devices, network elements, network entities, or network subsystems, such as a Policy Control Function (PCF) network element, and this application does not limit this. It should be noted that this application does not limit the distribution method of each network element in the core network. The specific distribution method can be referred to in relevant technical documents, and this application does not elaborate on this.

[0116] (5) IMS is a network architecture that provides voice and multimedia communication services (e.g., voice, video, and text messaging) over IP networks. IMS enables secure and reliable multimedia communication between different devices on different networks. The architectural model provides a unified infrastructure and common mechanisms for controlling, operating, routing, and managing sessions, as well as implementing authentication, authorization, and accounting controls. The IMS specifications include widely used Internet Engineering Task Force (IETF) recommendations. For example, the Session Initialization Protocol (SIP) is used for session control signaling.

[0117] The Internet, also known as the international network, generally refers to a vast network of interconnected networks, linked by a common set of protocols to form a single, logically vast international network. From a network communications perspective, the Internet is a data communications network that connects computer networks in countries, regions, and institutions around the world using the Transmission Control Protocol (TCP) and Internet Protocol (IP).

[0118] It should be noted that the network architecture shown in FIG4 is not limited to including only the devices and networks shown in the figure, but may also include other devices not shown in the figure, and this application will not illustrate this one by one.

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

[0120] Regarding the terminal equipment, please refer to the relevant description of the network architecture shown in Figure 4, which will not be repeated here.

[0121] The network device may be a device with wireless transceiver functions, or may be a chip or chip system provided in the device, located in the access network (AN) of the communication system, and used to provide access services to the terminal device. For example, the network device may be referred to as a radio access network (RAN) device, and may specifically be an access network device of the next generation mobile communication system, such as 6G, such as a 6G base station. In the next generation mobile communication system, the network device may also have other naming methods, all of which are included in the scope of protection of the embodiments of this application, and this application does not impose any limitation on this. Alternatively, the network device may include 5G, such as a gNB in ​​an NR system, or one or a group of antenna panels (including multiple antenna panels) of a base station in a 5G system, or a network node constituting a gNB, a transmission and reception point (TRP or 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), a radio unit (RU), an RSU with base station functions, a wired access gateway, or a 5G core network element. Alternatively, the network device may include an access point (AP) in a wireless fidelity (WiFi) system, a wireless relay node, a wireless backhaul node, various types of macro base stations, micro base stations (also known as small cells), relay stations, access points, wearable devices, vehicle-mounted devices, and the like.

[0122] Specifically, in a voice call scenario, terminal device 100 can transmit voice data with terminal device 200 through network device 1, IMS, and network device 2. Network device 1 is the network device corresponding to the cell where terminal device 100 is currently residing, and network device 2 is the network device corresponding to the cell where terminal device 200 is currently residing. In some embodiments of the present application, network device 1 and network device 2 can be the same network device, that is, the network devices corresponding to the cells where terminal device 100 and terminal device 200 are currently residing are the same. In some embodiments of the present application, terminal device 100 can be the party initiating a voice call to request a voice call with terminal device 200. In still other embodiments of the present application, terminal device 200 can be the party initiating a voice call to request a voice call with terminal device 100.

[0123] Further, please refer to Figure 6, which is a schematic diagram of the architecture of another communication system provided in an embodiment of the present application. The difference from the communication system shown in Figure 5 is that the communication system shown in Figure 6 also includes a ring back tone server, such as CAT-AS. Also, for the sake of convenience, the communication system shown in Figure 6 is described by taking network device _1 and network device _2 as the same network device _3 as an example. 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 in the embodiment of the present application is the same. Among them, the ring back tone server can interact with terminal device 100 and terminal device 200 through network device _3 to realize the playback control of the ring back tone in the voice call scenario.

[0124] Hereinafter, the embodiments of the present application will be described using terminal device 100 as the party initiating a voice call, i.e., the calling party, and terminal device 200 as the party receiving the voice call, i.e., the called party. In some embodiments of the present application, terminal device 100 is a dial-up terminal for a fixed-line telephone (referred to as a fixed-line telephone, also known as a wired telephone, landline, etc.) or an IP telephone (such as an Internet phone such as 95030). IP telephones are telephone services enabled according to the network technology specified by the IP protocol. For ease of explanation, calls from dial-up terminals of fixed-line telephones or IP telephones are referred to as fixed-line calls, and calls other than fixed-line calls are referred to as non-fixed-line calls.

[0125] The following is an introduction to the technical terms involved in the embodiments of this application:

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

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

[0128] Generally, the message mechanism provided by SIP includes message types such as INVITE, PRACK, UPDATE, ACK, etc. Each type further includes multiple messages.

[0129] Exemplarily, INVITE further includes: an informal response (INFORMAL RESPONSE) message, recorded as a SIP-INVITE / INFORMAL RESPONSE message; a trying (TRYING) message, recorded as a SIP-INVITE / TRYING message; a session progress (SESSION PROGRESS) message, recorded as a SIP-INVITE / SESSION PROGRESS message; a ringing (RINGING) message, recorded as a SIP-INVITE / RINGING message; and an answer (OK) message, recorded as a SIP-INVITE / OK message.

[0130] Exemplarily, PRACK further includes: an informal response (INFORMAL RESPONSE) message, recorded as a SIP-PRACK / INFORMAL RESPONSE message; an acknowledgement (OK) message, recorded as a SIP-PRACK / OK message, and the like.

[0131] Exemplarily, UPDATE further includes: an informal response (INFORMAL RESPONSE) message, recorded as a SIP-UPDATE / INFORMAL RESPONSE message; an acknowledgement (OK) message, recorded as a SIP-UPDATE / OK message, and the like.

[0132] Exemplarily, ACK further includes: an informal response (INFORMAL RESPONSE) message, recorded as a SIP-ACK / INFORMAL RESPONSE message; an acknowledgement (OK) message, recorded as a SIP-ACK / OK message, and the like.

[0133] It should be noted that the same message in different types, such as the informal response (INFORMAL RESPONSE) message and the confirmation (OK) message included in each type above, has different functions. For details about the functions of each message in each type, please refer to the description of the embodiments below, and will not be explained in detail here.

[0134] Each message has a fixed identifier. The identifier of the 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 called the 183 SESSION PROGRESS message, and the SIP-INVITE / OK message can also be called the 200 OK message.

[0135] In the embodiment of the present application, a voice conversation can be implemented based on SIP between two devices in the above communication system, such as between terminal device 100 and network device 3, between terminal device 200 and network device 3, and between network device 3 and a ring back tone server. For example, terminal device 100 can initiate a call invitation to terminal device 200 using INVITE.

[0136] 2. Session Description Protocol (SDP).

[0137] SDP provides a structured language primarily used for media negotiation between two devices, such as negotiating voice codecs, media (video / audio) ports, and call formats. Devices can include SDP in SIP messages to facilitate media negotiation. For example, SDP can be included in an UPDATE message to negotiate the media capabilities supported by both devices. Only after media negotiation is complete can the two devices communicate using compatible capabilities.

[0138] In the embodiment of the present application, SDP can be used to negotiate a codec between terminal device 100 and network device 3, and between terminal device 200 and network device 3 in the communication system to determine a codec for voice encoding and decoding. After the codec for voice encoding and decoding is negotiated, the communication system can use the negotiated codec to complete the voice encoding and decoding in the voice call scenario, thereby achieving normal playback of audio on terminal device 100 and terminal device 200. For example, terminal device 100 can normally play the ringback tone of terminal device 200, and terminal device 100 and terminal device 200 can normally play the call audio.

[0139] An embodiment of the present application provides a calling method, which can be applied to a scenario in which a terminal device 100 and a terminal device 200 conduct a voice call, and is mainly applied to a fixed-line call scenario, that is, a scenario in which the terminal device 200 receives a fixed-line call and an IP call from the terminal device 100.

[0140] Please refer to Figures 7 and 8. Figure 7 is a flow chart of a call method in a fixed-line call scenario, and Figure 8 is a schematic diagram of the interface response of the terminal device 200 in the process shown in Figure 7. As shown in Figure 7, the call method includes:

[0141] S701 : The terminal device 100 receives a dialing event, where the dialing event is used to dial the telephone number 1 of the terminal device 200 .

[0142] Exemplarily, the dialing event may be an event in which the user clicks on the contact corresponding to the telephone number 1 in the terminal device 100, or the dialing event may be an event in which the user clicks the dial button after dialing the telephone number 1 in the terminal device 100, or the dialing event may be an event in which the time for dialing the telephone number 1 has arrived.

[0143] 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.

[0144] The call invitation may be a SIP-INVITE / INFORMAL RESPONSE message.

[0145] Exemplarily, the terminal device 100 carries the telephone number 1 in the call invitation. The network device _3 can determine that the called end is the terminal device 200 based on the telephone number 1 in the call invitation, and can further initiate a call invitation to the terminal device 200.

[0146] S703. Terminal device 200 and terminal device 100 respond to the invitation through network device_3.

[0147] The invitation response includes the process where the terminal device 200 feeds back to the terminal device 100 that the invitation has been received, and the terminal devices 100 and 200 complete resource reservation. For the specific process included in the invitation response, please refer to the description of S1006-S1011 in Figure 10 below, which will not be described in detail here.

[0148] During the above-mentioned process of S701-S702, the terminal device 200 will not display information about the call invitation. For example, the terminal device 200 can display the user interface normally, without displaying the call prompt or the call interface. As a result, the user of the terminal device 200 will not be aware of the call invitation. As shown in Figure 8, during the above-mentioned process of S701-S703, the terminal device 200 can display interface 801. There is no call prompt in interface 801, and interface 801 is the desktop of the terminal device 200, not the call interface.

[0149] S704: The terminal device 200 rings.

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

[0151] 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 through the network device 3 to control the playing of the CRBT.

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

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

[0154] After the above steps S705 - S707 , after the terminal device 200 rings, the terminal device 100 can play the ringback tone of the terminal device 200 .

[0155] It is understandable that during the process of S704 to S707, the terminal device 200 is always ringing.

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

[0157] The answer message 1 indicates that the terminal device 200 has answered the call. Exemplarily, the answer message 1 may be a SIP-INVITE / OK message.

[0158] The answering operation may be a click operation on a call button, such as a click operation on the answer button 8021 in the interface 802 shown in Figure 8. Of course, the answering operation may also be an input of an answering voice by the user, such as an operation of "answering the call".

[0159] In response to receiving the user's answer operation, the terminal device 200 can start the call timer. As shown in Figure 8, 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, which includes "00:00" to indicate the start of the call timer.

[0160] It is understandable that after the terminal device 200 answers the call, the terminal device 100 can stop playing the ringback ring of the terminal device 100 and prepare to start the call. Specifically, the following S709-S712 can be used to control the terminal device 100 to stop playing the ringback ring.

[0161] S709: In response to receiving the answer message 1, the network device_3 notifies the CRBT server to stop playing the CRBT.

[0162] S710: The CRBT server stops transmitting CRBT data.

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

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

[0165] As can be seen from the above steps S709-S712, after receiving the answer message 1, network device 3 stops playing the ringback tone and does not continue to notify terminal device 100 that terminal device 200 has answered the call. Therefore, if terminal device 200 subscribes to the scenario service, it is necessary to repeat the invitation (i.e., reinvite) through the following steps S713-S71.

[0166] S713: The CRBT server sends a repeated invitation to the terminal device 200 through the network device_3.

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

[0168] 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.

[0169] Furthermore, answer message 2 carries the full set of codecs supported by terminal device 200. For example, if terminal device 200 supports codecs 97, 98, 102, and 105, answer message 2 carries these four codecs. This allows terminal device 200 and network device 3 to negotiate the optimal codec from the full set of codecs supported by terminal device 200.

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

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

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

[0173] S716. Network device 3 verifies the codec based on answer 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 answer is successful.

[0174] The confirmation message 2 is used to indicate that the answering message 2 has been received. Exemplarily, the confirmation message 2 is a SIP-ACK / INFORMAL RESPONSE.

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

[0176] In some cases, the codec in Answer Message 2 is consistent with the codec supported by Network Device 3, for example, they are identical, or the codecs supported by Network Device 3 include the codec in Answer Message 2. In this case, Network Device 3 can verify that the codec in Answer Message 2 is consistent with the codec supported by Network Device 3. Network Device 3 can then add the codec supported by Terminal Device 3 and an indication of successful call in Confirmation Message 2. Exemplarily, the indication of successful call is "active," indicating that the call was successfully activated.

[0177] For example, if answer message 2 includes three codecs, 97, 102, and 105, and network device 3 also supports three codecs, 97, 102, and 105, network device 3 can verify that the codec in answer message 2 is consistent with the codec supported by network device 3, and then add three codecs, 97, 102, and 105, as well as active, to confirmation message 2.

[0178] In other cases, the codec in Answer Message 2 may be inconsistent with the codecs supported by Network Device 3, for example, if Answer Message 2 includes a codec that Network Device 3 does not support. If the codecs supported by Terminal Device 200 and Network Device 3 are inconsistent, voice encoding and decoding cannot be completed during the voice call, and the call activation fails, i.e., the call fails. To address this situation, Network Device 3 can include the codec in Answer Message 2, the codec supported by Terminal Device 3, and an indication of the call failure in Confirmation Message 2. Exemplarily, the indication of the call failure is inactive, indicating that the call activation failed.

[0179] For example, if answer message 2 includes four codecs, 97, 98, 102, and 105, and network device 3 supports three codecs, 98, 102, and 105, network device 3 can verify that the codec in answer message 2 is inconsistent with the codecs supported by network device 3, and thus add three codecs, 98, 102, and 105, as well as inactive, to confirmation message 2.

[0180] At this point, it's important to note that after receiving Answer Message 2, Network Device 3 can also perform other checks, such as verifying the video / audio ports. S716 above only describes codec verification. In practice, if all information verifies consistently, the call activation is successful, and Network Device 3 will include a successful answer indication in Confirmation Message 2. If any information fails to verify consistently, the call activation fails, and Network Device 3 will include a failed answer indication in Confirmation Message 2.

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

[0182] After receiving the confirmation message 2, the terminal device 200 can confirm that the call has failed to be answered based on the indication information of the failed answer in the confirmation message 2, and thus automatically hang up the call. 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.

[0183] 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.

[0184] Taking the preset duration of 20s as an example, as shown in Figure 8, after the call timer reaches 20s, the terminal device 200 can display interface 804, which 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.

[0185] S718. In response to receiving the confirmation message 2, which includes the indication information of successful answering, the terminal device 200 and the terminal device 100 use the codec in the confirmation message 2 to conduct a voice call.

[0186] The confirmation message 2 includes the indication information of successful answering, which 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 the call can be carried out normally.

[0187] 7, in the fixed-line call scenario, during repeated invitations, because the terminal device 200 and the network device _3 support inconsistent codecs, the terminal device 200 will automatically hang up the call, resulting in a call failure.

[0188] Based on the above-mentioned problems in the fixed-line call scenario, an embodiment of the present application provides a call method.

[0189] This call method can be applied to the aforementioned fixed-line call scenario, resolving the issue of call answering failures during repeated invitations in fixed-line call scenarios. It should be noted that the repeated invitation process in non-fixed-line call scenarios is similar to that in fixed-line call scenarios, so the possibility of call answering failures during repeated invitations is not ruled out. Based on this, this call method can also be applied to non-fixed-line call scenarios to prevent call answering failures during repeated invitations. Below, the fixed-line call scenario is used as an example to illustrate this application solution.

[0190] In some embodiments, the method includes: after receiving the repeated invitation, terminal device 200 may send an answer message 3 to network device 3, where answer message 3 does not carry an SDP. In this way, after receiving answer message 3, network device 3 does not verify that the codec in answer message 3 is inconsistent with the codec supported by network device 3 because answer message 3 does not carry an SDP.

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

[0192] In summary, with the embodiment of the present application, during repeated invitations, the call answering failure problem will not occur due to inconsistent codecs supported by the terminal device 200 and the network device 3, thereby improving the call answering success rate.

[0193] In some embodiments, please refer to FIG9 , which is a flow chart of a call method provided in an embodiment of the present application. As shown in FIG9 , in a fixed-line call scenario, S703 (the invitation response step) in FIG7 further includes:

[0194] S900: Terminal device 200 sends a session progress message to network device 3. The session progress message includes codec 3 supported by terminal device 200, network device 3, and terminal device 100.

[0195] The session progress message indicates that preparations are being made for the call. Specifically, the session progress message may be a SIP-INVITE / SESSION PROGRESS message.

[0196] For example, the codecs supported by terminal device 100 include a, b, c, and d, the codecs supported by network device 3 include b, c, and e, and the codecs supported by terminal device 200 include c and f. Then, the codec3 carried in the session progress message may be c.

[0197] Regarding the specific implementation of the session progress message carrying the codec supported by the terminal device 200, the network device 3 and the terminal device 100, please refer to the description of S1002, S1004 and S1006 in Figure 10 below, which will not be further explained here.

[0198] Furthermore, S714-S718 after the terminal device 200 receives the repeated invitation message in FIG7 can be replaced by the following S901-S904.

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

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

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

[0202] The codec is usually carried in the SDP. Therefore, if the answer message 3 does not carry the SDP, it does not include the codec.

[0203] 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.

[0204] S903. Network device_3 sends confirmation message 3 to terminal device 200. Confirmation message 3 does not carry SDP.

[0205] The confirmation message 3 is used to indicate that the answer message 3 has been received. Exemplarily, the confirmation message 3 is a SIP-ACK / INFORMAL RESPONSE message.

[0206] Since the answer message 3 does not carry SDP, the network device 3 does not need to perform media negotiation related processing, such as codec verification. In addition, the network device 3 does not need to feedback negotiation data, such as the indication of whether the answer is successful, to the terminal device 200 via SDP. That is, the answer message 3 does not carry SDP.

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

[0208] Since answer message 3 does not carry SDP, it naturally does not include an indication of failed call, such as "inactive." In this case, the call will not fail. Furthermore, the session progress message in S900 carries a codec supported by terminal device 200, network device 3, and terminal device 100. This indicates that the codec in the session progress message is compatible with the voice codec used in the call. Therefore, terminal devices 100 and 200 can initiate the voice call using the codec in the session progress message.

[0209] For example, if codec3 carried in the session progress message is 98, the terminal device 100 and the terminal device 200 can use 98 for the codec of the session call voice to start the voice call.

[0210] It should be noted that the session progress message may carry multiple codecs 3. In this case, the terminal device 100 and the terminal device 200 can select one from the multiple codecs for the voice call.

[0211] It can be seen that by adopting this embodiment, in the fixed-line call scenario, after receiving repeated invitations, the terminal device 200 can improve the answering success rate in the fixed-line call scenario by sending an answering message 3 without SDP to the network device _3.

[0212] Please refer to Figure 10, which is a flow chart of a specific implementation of the calling method shown in Figure 9. As shown in Figure 10, the calling method includes the following steps:

[0213] S1001: The terminal device 100 receives a dialing event, where the dialing event is used to dial the telephone number 1 of the terminal device 200. For details, see S701.

[0214] By adopting the following S1002-S1005, S702 mentioned above can be implemented, that is, the terminal device 100 initiates an invitation to the terminal device 200 through the network device_3.

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

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

[0217] S1003. Network device_3 sends back SIP-INVITE / TRYING to terminal device 100.

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

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

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

[0221] 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) in the codec1 supported by the terminal device 100 in the SIP-INVITE / INFORMAL RESPONSE sent to the terminal device 200.

[0222] For example, the codec1 supported by the terminal device 100 includes 97, 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, and 18, and the codec supported by the network device _3 includes 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, and 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, and 18.

[0223] S1005. The terminal device 200 sends a SIP-INVITE / TRYING signal to the network device 3.

[0224] By adopting the following S1006-S1011, the above S703 can be implemented, that is, the invitation response is performed through the network device_3.

[0225] S1006: Terminal device 200 sends a SIP-INVITE / SESSION PROGRESS to network device 3. The SIP-INVITE / SESSION PROGRESS includes codec3, which is supported by terminal device 100, network device 3, and terminal device 200. S1006 specifically corresponds to the aforementioned S900.

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

[0227] Upon receiving the SIP-INVITE / INFORMAL RESPONSE from network device 3, terminal device 200 can obtain the codecs supported by both terminal device 100 and network device 3 from the SIP-INVITE / INFORMAL RESPONSE. Terminal device 200 then includes the codec supported by itself (i.e., terminal device 200) in the SIP-INVITE / SESSION PROGRESS message sent to network device 3. This ensures that the SIP-INVITE / SESSION PROGRESS message sent by terminal device 200 to network device 3 includes the codecs supported by both terminal device 100, network device 3, and terminal device 200.

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

[0229] S1007. Network device_3 sends a SIP-INVITE / SESSION PROGRESS to terminal device 100. The SIP-INVITE / SESSION PROGRESS includes codec3.

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

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

[0232] SIP-PRACK / INFORMAL RESPONSE is used to perform resource reservation operations.

[0233] S1009. Network device_3 sends back SIP-PRACK / OK to terminal device 100.

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

[0235] S1010. Network device_3 sends a SIP-PRACK / INFORMAL RESPONSE to terminal device 200.

[0236] S1011. The terminal device 200 sends a SIP-PRACK / OK feedback to the network device 3.

[0237] After completing the invitation response, the terminal device 200 can then implement the above S704, that is, the following S1012.

[0238] S1012: The terminal device 200 rings. For details, see S705 above.

[0239] S1013. Terminal device 200 sends SIP-INVITE / RINGING to network device_3.

[0240] SIP-INVITE / RINGING instructs the terminal device 200 to start ringing.

[0241] S1014. Network device_3 notifies the ringback tone server to play the ringback tone.

[0242] After receiving the SIP-INVITE / RINGING, the network device_3 may also notify the terminal device 200 that the terminal device 100 starts ringing through the following S1015.

[0243] S1015. Network device_3 sends SIP-INVITE / RINGING to terminal device 200.

[0244] It should be noted that both S1014 and S1015 can be triggered by network device_3 receiving a SIP-INVITE / RINGING, and the actual execution order of the two is not limited to that shown in Figure 10. For example, network device_3 can also execute S1015 first and then execute S1014.

[0245] The following S1016 - S1017 may be used to implement S706 mentioned above, ie, transmitting the ringback tone data of the terminal device 200 to the terminal device 100 .

[0246] S1016. In response to receiving the notification of playing the CRBT, the CRBT server sends a CRBT data stream to network device_3.

[0247] The CRBT data stream refers to a data stream corresponding to the CRBT of the terminal device 200. For example, the CRBT data stream may be a real-time transport protocol (RTP) stream.

[0248] S1017. Network device_3 sends a ring back tone data stream to terminal device 100.

[0249] The network device_3 transmits the CRBT data stream from the CRBT server to the terminal device 100, so that the terminal device 100 obtains the CRBT data stream.

[0250] S1018: The terminal device 200 plays the ringback tone. For details, please refer to S707 above.

[0251] S1019: In response to receiving the user's answering operation, the terminal device 200 sends a SIP-INVITE / OK to the network device 3. For details, please refer to S708 above.

[0252] Among them, SIP-INVITE / OK can instruct the terminal device 200 to answer the call.

[0253] In response to receiving the SIP-INVITE / OK, the network device_3 may implement S709 and notify the CRBT server to stop playing the CRBT, as described in S1020.

[0254] S1020. Network device 3 sends a SIP-INVITE / OK to the ringback tone server.

[0255] When the CRBT server receives SIP-INVITE / OK, it can be determined 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 CRBT, as shown in S1021.

[0256] S1021: The CRBT server stops transmitting the CRBT data stream.

[0257] After receiving the SIP-INVITE / OK, the CRBT server may implement S711 using the following S1022-S1023, ie, notify the terminal device 100 to stop playing the CRBT.

[0258] S1022: The CRBT server sends a SIP-ACK / INFORMAL RESPONSE response back to the network device 3.

[0259] Among them, SIP-ACK / INFORMAL RESPONSE indicates that SIP-INVITE / OK is received.

[0260] It should be noted that both S1021 and S1022 can be triggered by the CRBT server receiving a SIP-INVITE / OK, and the actual execution order of the two is not limited to that shown in Figure 10. For example, the CRBT server may execute S1022 first and then execute S1021.

[0261] S1023. Network device_3 sends a SIP-UPDATE / INFORMAL RESPONSE to terminal device 100.

[0262] The SIP-UPDATE / INFORMAL RESPONSE message indicates to stop playing the ringback tone. For example, the SIP-UPDATE / INFORMAL RESPONSE message carries a video 0 parameter, indicating to stop playing the ringback tone.

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

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

[0265] After receiving the SIP-UPDATE / INFORMAL RESPONSE, the terminal device 100 may further notify the network device 3 of the receipt of the SIP-UPDATE / INFORMAL RESPONSE through the following S1025.

[0266] S1025. The terminal device 100 sends SIP-UPDATE / OK to the network device 3.

[0267] The SIP-UPDATE / OK indicates that the terminal device 100 has received the SIP-UPDATE / INFORMAL RESPONSE.

[0268] After receiving the SIP-INVITE / OK (as received in the above S1019), the network device_3 may further feedback the receipt of the SIP-INVITE / OK to the terminal device 200, as shown in the following S1026.

[0269] S1026. Network device_3 sends a SIP-ACK / INFORMAL RESPONSE to terminal device 200.

[0270] Among them, SIP-ACK / INFORMAL RESPONSE indicates that SIP-INVITE / OK is received.

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

[0272] After receiving the SIP-INVITE / OK, the CRBT server may further use the following S1027-S1029 to implement S714, ie, initiate a repeated invitation.

[0273] S1027: The CRBT server sends a SIP-INVITE / INFORMAL RESPONSE to network device 3.

[0274] In S1027 , SIP-INVITE / INFORMAL RESPONSE may be used to initiate a repeated invitation.

[0275] It should be noted that both S1021 and S1027 are triggered by the CRBT server receiving SIP-INVITE / OK, and the actual execution order of the two is not limited to that shown in Figure 10. For example, the CRBT server may also execute S1027 between S1020 and S1023.

[0276] S1028. Network device_3 sends a SIP-INVITE / INFORMAL RESPONSE to terminal device 200.

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

[0278] S1029. The terminal device 200 sends a SIP-INVITE / TRYING signal to the network device 3.

[0279] Similarly, SIP-INVITE / TRYING can indicate the receipt of a call invitation.

[0280] S1030: Terminal device 200 sends a SIP-INVITE / OK to network device 3. The SIP-INVITE / OK does not carry an SDP. For details, see S901 above.

[0281] Similarly, SIP-INVITE / OK can instruct terminal device 200 to answer the call. In addition, SIP-INVITE / OK does not carry SDP and thus does not carry codec. That is, SIP-INVITE / OK in S1030 is answer message 3.

[0282] S1031. Network device 3 sends SIP-INVITE / OK to terminal device 100. For details, see S902 above.

[0283] S1032. The terminal device 100 sends a SIP-ACK / INFORMAL RESPONSE feedback to the network device 3.

[0284] Similarly, SIP-ACK / INFORMAL RESPONSE indicates receipt of SIP-INVITE / OK.

[0285] S1033: Network device 3 sends a SIP-ACK / INFORMAL RESPONSE to terminal device 200. The SIP-ACK / INFORMAL RESPONSE does not carry an SDP. For details, see S903 above.

[0286] The SIP-ACK / INFORMAL RESPONSE does not carry SDP, and thus does not carry codec, nor does it carry information indicating whether the call was successfully answered. Therefore, the call can be successfully answered. That is, the SIP-ACK / INFORMAL RESPONSE in S1033 is confirmation message 3.

[0287] S1034: In response to receiving the SIP-ACK / INFORMAL RESPONSE, the terminal device 200 and the terminal device 100 start a voice call using codec 3. For details, see S904 above.

[0288] In the embodiments of Figures 9 and 10 above, a fixed-line call scenario is mainly used as an example to illustrate a solution for improving the call answering success rate by answering message 3. It should be noted that in a non-fixed-line 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 (e.g., through an UPDATE update) to negotiate a new codec supported by all three (e.g., 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, Network_3 in the network-side device will also interact with the terminal device 200 to negotiate a codec4 supported by all three. Exemplarily, the process of interaction between network device 3 and terminal device 200 includes: terminal device 200 sending a SIP-UPDATE / INFORMAL RESPONSE message to network device 3; the SIP-UPDATE / INFORMAL RESPONSE message sent by terminal device 100 to network device 3 carries SDP5, where SDP5 carries a codec supported by terminal device 100. After receiving the SIP-UPDATE / INFORMAL RESPONSE message, network device 3 may send a SIP-UPDATE / INFORMAL RESPONSE message to terminal device 100; the SIP-UPDATE / INFORMAL RESPONSE message sent by network device 3 to terminal device 100 carries SDP6, where SDP6 carries code4 supported by both SDP5, the network-side device, and terminal device 200. Since SDP5 carries the codec supported by the terminal device 100 , code4 in SDP5 that is supported by both the network side device and the terminal device 200 is the codec supported by both the terminal device 100 , the network side device and the terminal device 200 .

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

[0290] In other embodiments, please refer to FIG11, which is a flow chart of another call method provided by an embodiment of the present application. As shown in FIG11, in the fixed-line call scenario, S703 (the invitation response step) in FIG7 further includes:

[0291] S1100: Terminal device 200 sends a session progress message to network device 3. The session progress message includes codec 3, which is supported by terminal device 200, network device 3, and terminal device 100. For details, see the description of S900.

[0292] Furthermore, S714-S718 after the terminal device 200 receives the repeated invitation message in FIG7 can be replaced by the following S1101-S1105.

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

[0294] That is, in this embodiment, the codec negotiated between the terminal device 200 and the network device 3 before the repeated invitation included in SDP3 is codec3.

[0295] Similar to the above S714, S1101 is also actively triggered, rather than passively triggered by the user's answering operation.

[0296] The answering message 4 also indicates that the terminal device 200 has answered the call. For example, the answering message 3 may also be an INVITE / OK message.

[0297] S1102: Network device_3 forwards answer message 4 to terminal device 100. For details, see S715.

[0298] Furthermore, after receiving the answer message 4, the terminal device 100 may also feed back an answer confirmation message (SIP-ACK / INFORMAL RESPONSE) to the network device 3, as shown in S1032 in FIG. 10 .

[0299] S1103. Network device 3 verifies codec3 in received message 4 and obtains a verification result that is consistent.

[0300] Codec3 is supported by terminal device 100, network device 3, and terminal device 200. Therefore, when verifying codec3 in received message 4, network device 3 compares codec3 with the codecs supported by itself (i.e., network device 3) and determines that codec3 is supported by itself (i.e., network device 3), thereby obtaining a consistent verification result.

[0301] For example, codec3 includes 98 and 105, indicating that terminal device 100, network device 3, and terminal device 200 all support 98 and 105. Network device 3 supports codecs 98, 110, 96, 108, 8, 0, 105, 100, 111, 106, and 18, indicating that network device 3 also supports 98 and 105. When network device 3 verifies codec3, it can obtain a consistent verification result.

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

[0303] The confirmation message 4 is used to indicate that the answer message 4 has been received. Exemplarily, the confirmation message 4 is a SIP-ACK / INFORMAL RESPONSE message.

[0304] Since the verification result is consistent, network device 3 can add a successful answer indication, such as "acitive," to confirmation message 4. Furthermore, network device 3 can also include the codecs supported by network device 3 in codec3 in answer message 4. Since codec3 is supported by network device 3, the codec supported by network device 3 in codec3 remains codec3. That is, confirmation message 4 still carries codec3. For example, if codec3 includes 98 and 105, confirmation message 4 still carries 98 and 105.

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

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

[0307] Similar to the embodiment of FIG. 9 , if the confirmation message 4 carries multiple codecs, the terminal device 100 and the terminal device 200 may select one codec from the multiple codecs for the voice call.

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

[0309] Furthermore, for the specific implementation of the calling method shown in FIG11 , please refer to the relevant description of FIG10 above. Specifically, it is only necessary to replace S1030-S1034 in FIG10 with the corresponding steps in FIG11 , which will not be repeated here.

[0310] The embodiment of Figure 11 above primarily uses a fixed-line call scenario as an example to illustrate a solution for improving call answering success rates by answering message 4. As previously explained, in a non-fixed-line call scenario, the codec supported by all three parties may be updated from codec3 to codec4. That is, in a non-fixed-line call scenario, the codec negotiated between terminal device 200 and network device 3 prior to the repeated INVITE included in SDP3 is codec4.

[0311] Based on this, in a non-fixed network call scenario, codec3 in the above S1101-S1105 can also be replaced with code4. The specific implementation principle can be found in the description of S1101-S1105 and will not be repeated here.

[0312] Please refer to 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 shown in Figure 12, 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 194, and a SIM card interface 195, etc. The audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, an earphone jack 170D, etc., and the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air 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.

[0313] It is understood that the structures illustrated in the embodiments of this application do not constitute specific limitations on the terminal device. In other embodiments, the terminal device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0314] The processor 110 may include one or more processing units, for example, the processor may include an application processor (AP), a modem processor (also known as a baseband processor), a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), and / or a neural network processor (NPU). Different processing units may be independent devices or integrated into one or more processors. The processor is the nerve center and command center of the terminal device. The controller may generate operation control signals based on instruction opcodes and timing signals to complete the control of instruction fetching and execution.

[0315] In some embodiments of the present application, the terminal device 200 can execute the steps performed by the terminal device 200 in the call method shown in Figures 7, 9 to 11 above through the AP and Modem in the above-mentioned processor 110, such as executing S901 in Figure 9 above, and improving the call answering success rate by sending an answering message 3 that does not carry SDP; or executing S1101 in Figure 11 above, and improving the call answering success rate by sending an answering message 4 that carries codec3 in the session progress message.

[0316] 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. Among them, antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G / 6G applied to the terminal device. Wireless communication module 160 can provide solutions for wireless communications including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks) and Bluetooth (BT) applied to the terminal device.

[0317] In some embodiments, antenna 1 of a terminal device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that the terminal device can communicate with network-side devices and other terminal devices via wireless communication technologies. For example, terminal device 200 can communicate with network device 3 via antenna 1 and mobile communication module 160.

[0318] The terminal device can realize the display function through the display screen 194 and the GPU, AP, etc. in the processor 110. For example, the terminal device 200 can realize the display of each interface in FIG8 through the display screen 194 and the GPU, AP, etc. in the processor 110.

[0319] The terminal device can implement audio functions through the audio module 170 and the AP, etc. For example, the terminal device 200 can answer calls through the receiver 170B in the audio module 170 and can collect user input voice through the microphone 170C in the audio module 170.

[0320] In addition, the operating system of the terminal device is also running on the hardware structure shown in Figure 12. For example, iOS developed by Apple TM Operating system, Android developed by Google TM Open source operating system, Windows developed by Microsoft TMOperating system, etc.

[0321] The operating system of the terminal device can adopt a layered architecture, event-driven architecture, micro-kernel architecture, micro-service architecture, or cloud architecture. TM The system is used as an example to illustrate the hardware and software structure of the terminal device. TM The system is used as an example, but the basic principles are also applicable to iOS-based TM or Windows TM Terminal devices with other operating systems.

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

[0323] The application layer includes a series of application packages. Application packages may include camera, gallery, calendar, call, map, WLAN, Bluetooth, music, video, short message and other applications (application, APP). Call APP is used to make calls.

[0324] The application layer may also include a system user interface (system UI), which 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.

[0325] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example, the application framework layer may include a window manager, content provider, view system, telephony manager, resource manager, notification manager, etc.

[0326] The telephone manager is used to provide call functions of the terminal device, such as management of call status (including answering, hanging up, etc.). The telephone manager is represented by telephony in Figure 13.

[0327] The application framework layer may also include a radio interface layer (RIL). The modem in the aforementioned hardware structure can exchange information with the telephony through the RIL to implement a call.

[0328] System libraries may include a surface manager, a 3D graphics processor, a 2D graphics engine, a media library, and more.

[0329] The hardware abstraction layer runs in user space, encapsulates kernel layer drivers, and provides a calling interface to the upper layer. Exemplary hardware abstraction layers may include display HAL, camera HAL, audio HAL, sensor HAL, etc.

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

[0331] 13 , the software structure of the terminal device also includes the software components of the modem. The software components of the modem include the communication protocol stack and the physical (PHY) layer, which are used to implement communication between the terminal device and the network side device or other terminal devices.

[0332] A modem can include the Non-Access Stratum (NAS) layer, the Radio Resource Control (RRC) layer, the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, the Medium Access Control (MAC) layer, and the Physical Hybrid (PHY) layer. Each of these layers can be a software module. The NAS, RRC, PDCP, RLC, and MAC layers constitute the communication protocol stack.

[0333] Continuing to refer to FIG13 , the modem can interact with a network-side device (such as a base station) through an antenna.

[0334] 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 one or more processors execute the computer instructions, the terminal device executes the above-mentioned call method.

[0335] Some embodiments of the present application provide a chip system for use in a terminal device. The chip system includes at least one processor and an interface, wherein the interface is configured to receive instructions and transmit them to the at least one processor; the at least one processor executes the instructions, causing the terminal device to execute the aforementioned call method. The chip system may be a modem, or a system on a chip (SoC) including a modem, and the aforementioned method may be implemented by a modem.

[0336] This embodiment further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a terminal device, the terminal device executes each function or step in the above method embodiment.

[0337] This embodiment further provides a computer program product. When the computer program product is run on a computer, it enables the computer to execute each function or step in the above method embodiment.

[0338] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the chip to perform the various functions or steps in the above-mentioned method embodiments.

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

[0340] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0341] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0342] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0343] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0344] 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 this understanding, the technical solution of the embodiment of the present application is essentially 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, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, 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 disk.

[0345] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit the present application. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions 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, the first invitation message 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, the second invitation message 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, the first SDP carries a first voice codec format, and the first voice codec format is the voice codec format negotiated between the terminal device and the network-side device after receiving 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, characterized in that, 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, the first confirmation message 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, the second SDP carries a first indication information indicating that the activation of the first call is successful, and the second SDP further 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.

4. The method according to any one of claims 1-3, characterized in that The first call is a fixed network call, the fixed network call includes a fixed telephone call or an Internet Protocol (IP) telephone call, and 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, the session progress message carries a fourth SDP, and the fourth SDP carries a fourth voice codec format, and the fourth voice codec format is the format supported by the terminal device among the third voice codec formats; Wherein, the voice codec format negotiated between the terminal device and the network-side device after receiving 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, and the non-fixed network call 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 the terminal device 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 receiving 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 / INFORMAL RESPONSE 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 a 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 sending 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 where the second answer message does not include a 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 a 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 the 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