Ring-back tone playing method and device, storage medium and chip system

Abstract

The invention provides a ring-back tone playing method and device, a storage medium and a chip system. According to the method, for a scene in which the ring-back tone type is a network ring-back tone, that is, the audio data of the ring-back tone to be played is provided by a network side, the ring-back tone type is directly modified to be the local ring-back tone under the condition that the audio packets received by the first terminal in the first time are all mute packets, and then the local ring-back tone is played; therefore, it can be ensured that the first terminal can play the ring-back tone in time and give a prompt to a user.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a ringback tone playing method, device, storage medium and chip system. Background Art

[0002] IMS (IP Multimedia Subsystem) is a concept proposed by 3GPP. It is a universal network architecture that provides multimedia services on IP-based networks. It can provide integrated multimedia services and Internet applications for users using different access methods. VoLTE (Voice-over-LTE) and VoNR (Voice over New Radio) are currently common IP data transmission technologies, that is, IMS-based voice services.

[0003] Taking the voice service scenario of VoLTE as an example, after the calling terminal initiates a call request to the called terminal on the IMS network, before the called terminal answers the call, in order to inform the user of the progress of the call service, a prompt that the other party is ringing will be displayed on the user interface of the calling terminal, and a ringback tone will be played.

[0004] However, in some implementations, such as a scenario where a network ringback tone is played, there may be a problem that the ringback tone played by the calling terminal has no sound, causing the user to mistakenly believe that the call has failed, affecting the user experience. Summary of the invention

[0005] The present application provides a ringback tone playing method, device, storage medium and chip system. In the method, for the scenario where the ringback tone is provided by the network side, the calling terminal monitors whether the audio package provided by the network side is received within the specified time, and determines whether the data in the audio package is all silent frames, and then decides whether to continue playing the network ringback tone or change to playing the local ringback tone, so as to ensure that the calling terminal can play the ringback tone in time and prompt the user.

[0006] In a first aspect, the present application provides a ringback tone playing method, which is applied to a first terminal. The method comprises: sending a call request INVITE signaling, the INVITE signaling includes early media P-Early-Media information; after receiving a signaling indicating a network ringback tone, within a first time length, if all received audio packets are silent packets, playing a local ringback tone.

[0007] Optionally, the first terminal is generally referred to as a calling terminal. Exemplarily, the first terminal may be, for example, the first UE referred to below.

[0008] It should be understood that in actual applications, any terminal can be either a calling terminal or a called terminal, which is specifically determined according to whether the current call service is initiated by it. That is, for the scenario where the call service is initiated by it, the terminal device will be the calling terminal, and vice versa for the called terminal.

[0009] Optionally, the call request (INVITE) signaling, that is, the INVITE signaling.

[0010] Optionally, the first duration is, for example, 1s or 2s, which can be specifically set according to service requirements, chip requirements of the first terminal, etc.

[0011] Optionally, the network ringback tone means that the audio data of the ringback tone to be played is provided by the network side. This audio data, that is, the audio data in the audio packet, is usually the ringback tone set when the called party subscribes to the ringback tone service.

[0012] Optionally, the local ringback tone means that the audio data of the ringback tone to be played is provided by the first terminal itself.

[0013] Optionally, playing the local ringback tone is, for example, playing the local ringback tone. That is, the audio data of the ringback tone to be played is provided by the calling party.

[0014] Optionally, this audio data is, for example, usually the "beep" sound played in the calling terminal when waiting for the called terminal to answer the call.

[0015] Optionally, the audio data corresponding to the local ringback tone can be stored in the storage medium local to the first terminal.

[0016] Optionally, the storage medium local to the first terminal can be, for example, the internal memory of the first terminal. In this way, in the scenario of switching to the local ringback tone, the audio data can be directly read from the local storage medium for playback.

[0017] Optionally, the first terminal sends an INVITE signaling, including: the first terminal sends an INVITE signaling to the network side.

[0018] Optionally, the first terminal sends an INVITE signaling to the network side, including: the first terminal sends an INVITE signaling to the first base station; where the first base station is used to send the INVITE signaling to the first core network device, the first base station is the base station accessed by the first terminal device, and the first core network device is the core network device corresponding to the first base station.

[0019] Optionally, the first base station is a base station corresponding to a 3G network architecture, or a 4G network architecture, or a 5G network architecture, or a 6G network architecture.

[0020] Therefore, for the scenario where the ringback tone type is a network ringback tone, that is, the audio data of the ringback tone to be played is provided by the network side, by setting that all the audio packets received by the first terminal within the first time are silent packets, the ringback tone type is directly modified to a local ringback tone, and then the local ringback tone is played, so as to ensure that the first terminal can play the ringback tone in time and give a prompt to the user.

[0021] According to the first aspect, the P-Early-Media information included in the INVITE signaling is P-Early-Media: supported.

[0022] According to the first aspect, or any one of the implementation manners of the above first aspect, after receiving the signaling indicating the network ringback tone, within the first duration, when all the received audio packets are silent packets, playing the local ringback tone includes: after receiving the signaling indicating the network ringback tone, starting to time, and the timing duration is the first duration; when the audio packets sent by the network side are received within the first duration and the length of all the received audio packets is less than or equal to the preset length, playing the local ringback tone.

[0023] Optionally, starting to time is, for example, immediately after receiving the signaling indicating the network ringback tone.

[0024] Optionally, starting to time can also be starting to time after a certain time after receiving the signaling indicating the network ringback tone.

[0025] Optionally, the preset length can be 15 - 25.

[0026] It can be understood that, under normal circumstances, the length of a non-silent packet is usually greater than the preset length. Therefore, when the length of the audio packet is less than or equal to the preset length, it can be determined that the received audio packet is a silent packet. Furthermore, in order to ensure that the first terminal can play out the ringback tone with sound, the local ringback tone can be selected to play.

[0027] According to the first aspect, or any one of the implementation manners of the above first aspect, the preset length is 19.

[0028] According to the first aspect, or any one of the implementation manners of the above first aspect, after receiving the signaling indicating the network ringback tone, within the first duration, when all the received audio packets are silent packets, playing the local ringback tone includes: after receiving the signaling indicating the network ringback tone, starting to time, and the timing duration is the first duration; when the audio packets sent by the network side are received within the first duration and the value of the frame type flag bit in all the received audio packets is the preset silent value, playing the local ringback tone.

[0029] Thus, by determining whether the value of the frame type flag bit in the audio packet is a preset mute value, it is possible to quickly determine whether the audio packet is a mute packet according to the value of the frame type flag bit, that is, to determine whether all the audio data in the audio packet are mute frames, and then timely perform the operation of switching back the ringtone type to the local ringtone and playing the local ringtone, so that the first terminal can play the ringtone in time.

[0030] According to the first aspect, or any one of the above implementation manners of the first aspect, when the audio coding format adopted by the audio packet is the Adaptive Multi-Rate AMR-NB format, the preset mute value is 8.

[0031] According to the first aspect, or any one of the above implementation manners of the first aspect, when the audio coding format adopted by the audio packet is the Adaptive Multi-Rate Wideband Coding AMR-WB format, the preset mute value is 9.

[0032] According to the first aspect, or any one of the above implementation manners of the first aspect, after receiving the signaling indicating the network ringtone, when all the received audio packets are mute packets within the first duration, playing the local ringtone includes: after receiving the signaling indicating the network ringtone, starting to time, and the timing duration is the first duration; when receiving the audio packets sent by the network side within the first duration and the packet types of all the received audio packets are the preset packet types, playing the local ringtone.

[0033] Thus, it is also possible to quickly determine whether the received audio packet is a mute packet according to the packet type of the audio packet.

[0034] According to the first aspect, or any one of the above implementation manners of the first aspect, the preset packet type is SID (COMFORT NOISE FRAME). That is, SID (COMFORT NOISE FRAME) is included in the audio packet.

[0035] According to the first aspect, or any one of the above implementation manners of the first aspect, when no audio packet sent by the network side is received within the first duration, play the local ringtone.

[0036] Thus, it can be ensured that the first terminal can always play a ringtone with sound.

[0037] According to the first aspect, or any one of the above implementation manners of the first aspect, the signaling indicating the network ringtone includes: the first signaling and / or the second signaling, the first signaling is the first signaling indicating the ringtone type sent by the network side after the INVITE signaling is initiated, and the second signaling is the last signaling indicating the ringtone type sent by the network side.

[0038] According to the first aspect, or any implementation of the above first aspect, the first signaling is 183 signaling, and the second signaling is 180 signaling.

[0039] Optionally, in the case where the 183 signaling is not received, the first signaling may also be Update signaling.

[0040] According to the first aspect, or any implementation of the above first aspect, when the first signaling includes a PEM header field and the value included in the PEM header field is the first value, the first signaling is a signaling indicating a local ringback tone; when the first signaling includes a PEM header field and the value included in the PEM header field is the second value, the first signaling is a signaling indicating a network ringback tone.

[0041] Thus, during the media negotiation process, that is, before receiving the signaling indicating that the second terminal has started ringing, such as the second signaling, the type of the current ringback tone of the first terminal is determined according to the first signaling that can indicate the type of the ringback tone received during the media negotiation process, so that the type of the ringback tone can be determined in advance, and then the ringback tone is played according to the corresponding strategy, ensuring that the first terminal can play the ringback tone normally before the second terminal answers the call.

[0042] According to the first aspect, or any implementation of the above first aspect, the method further includes: when the first signaling does not include a PEM header field, the first signaling is a signaling indicating a network ringback tone; or, when the first signaling does not include a PEM header field, the first signaling is a signaling indicating a local ringback tone.

[0043] It should be noted that when the first signaling does not include a PEM header field, whether the type of the ringback tone is determined as a network ringback tone or a local ringback tone can be determined according to the chip adopted by the first terminal.

[0044] For example, for a chip that is specified not to include a PEM header field, the type of the ringback tone is a network ringback tone. For such a first terminal, in this scenario, the type of the ringback tone can be determined as a network ringback tone, that is, the first signaling in this scenario is a signaling indicating a network ringback tone.

[0045] Also for example, for a chip that is specified not to include a PEM header field, the type of the ringback tone is a local ringback tone. For such a first terminal, in this scenario, the type of the ringback tone can be determined as a local ringback tone, that is, the first signaling in this scenario is a signaling indicating a local ringback tone.

[0046] According to the first aspect, or any implementation manner of the above first aspect, when the second signaling includes a PEM header field and the value included in the PEM header field is the first value, the second signaling is a signaling indicating a local ringback tone; when the second signaling includes a PEM header field and the value included in the PEM header field is the second value, the second signaling is a signaling indicating a network ringback tone.

[0047] According to the first aspect, or any implementation manner of the above first aspect, the method further includes: when the second signaling does not include a PEM header field, the second signaling is a signaling indicating a network ringback tone; or, when the second signaling does not include a PEM header field, the second signaling is a signaling indicating a local ringback tone.

[0048] It should be noted that when the second signaling does not include a PEM header field, whether to determine the ringback tone type as a network ringback tone or a local ringback tone can be determined according to the chip adopted by the first terminal.

[0049] For example, when the chip adopted does not include a PEM header field, the ringback tone type is a network ringback tone. For such a first terminal, in this scenario, the ringback tone type can be determined as a network ringback tone, that is, the second signaling in this scenario is a signaling indicating a network ringback tone.

[0050] For another example, when the chip adopted does not include a PEM header field, the ringback tone type is a local ringback tone. For such a first terminal, in this scenario, the ringback tone type can be determined as a local ringback tone, that is, the second signaling in this scenario is a signaling indicating a local ringback tone.

[0051] According to the first aspect, or any implementation manner of the above first aspect, the first value indicates that early media function is not supported, and the second value indicates that audio packets are allowed to be received.

[0052] According to the first aspect, or any implementation manner of the above first aspect, the first value is Inactive, and the second value is Sendrecv, or Recvonly.

[0053] According to the first aspect, or any implementation manner of the above first aspect, when the first signaling includes a value that is the first value, the PEM header field is P-Early-Media: Inactive; when the value included in the first signaling is the second value, the PEM header field is P-Early-Media: Sendrecv, or P-Early-Media: Recvonly.

[0054] Optionally, the case where the PEM header field includes the information of P-Early-Media: Inactive also belongs to the case where the value included in the first signaling is the first value.

[0055] Optionally, the PEM header field includes information of P-Early-Media: Sendrecv, or the PEM header field includes information of P-Early-Media: Recvonly, which also belongs to the case where the value included in the first signaling is the second value.

[0056] According to the first aspect, or any implementation manner of the above first aspect, the method further includes: receiving a first signaling, where the first signaling is a signaling indicating a network ringback tone; receiving a second signaling within a first duration, and when the second signaling includes a PEM header field and the value included in the PEM header field is the first value, the second signaling is a signaling indicating a local ringback tone; playing the local ringback tone.

[0057] Optionally, no audio packet is received from the network side within the first duration. Thus, when the first signaling indicates that the network plays sound and the second signaling indicating local sound playback is received before the audio packet is received from the network side, the audio data of the local ringback tone is directly played according to the ringback tone type indicated by the second signaling, so as to ensure that the ringback tone played by the first terminal does not change midway and ensure the user experience.

[0058] According to the first aspect, or any implementation manner of the above first aspect, the method further includes: receiving a second signaling within a first duration, and when the second signaling includes a PEM header field and the value included in the PEM header field is the second value, the second signaling is a signaling indicating a network ringback tone; playing the local ringback tone when all the received audio packets are silent packets within a second duration.

[0059] The second duration, for example, 1 s or 2 s, can be specifically set according to service requirements, chip requirements of the first terminal, etc.

[0060] Thus, in the scenario where resource preview is not supported, that is, the first signaling is not received before the second signaling, the ringback tone type is directly determined according to the second signaling, and when the determined ringback tone type is the network ringback tone, the judgment condition of monitoring whether an audio packet is received from the network side within a set time and whether all the received audio packets are silent packets is used to decide whether to change the ringback tone type to the local ringback tone, so as to ensure that the first terminal can play the ringback tone in time.

[0061] According to the first aspect, or any implementation manner of the above first aspect, the method further includes: playing the network ringback tone when there is a non-silent packet among the received audio packets within a second duration.

[0062] Optionally, playing the network ringback tone is to play the audio data in the non-silent packets received within the second duration.

[0063] According to the first aspect, or any implementation manner of the above first aspect, after receiving the signaling indicating the network ringback tone, within the first duration, when there are non-silent packets among the received audio packets, play the network ringback tone.

[0064] Optionally, playing the network ringback tone is playing the audio data in the non-silent packets received within the first duration.

[0065] In this way, in the scenario of indicating network audio playback, as long as there is audible audio (non-silent packets) among the audio packets received within the set time (the first time), take the network ringback tone as the standard and preferentially play the audio data in the received audio packets, ensuring that the ringback tone set by the called user can be heard by the calling user.

[0066] According to the first aspect, or any implementation manner of the above first aspect, during the process of playing the network ringback tone, receive a second signaling, where the second signaling is the last signaling sent by the network side indicating the ringback tone type; when the second signaling includes a PEM header field and the value included in the PEM header field is the first value, the second signaling is a signaling indicating the local ringback tone; within the third duration, when all the received audio packets are silent packets or no audio packets are received, play the local ringback tone; within the third duration, when there are non-silent packets among the received audio packets, continue to play the network ringback tone.

[0067] Among them, the third duration, such as 1 s or 2 s, can be specifically set according to service requirements, chip requirements of the first terminal, etc.

[0068] Thus, in the case where the network ringback tone has started to be played before receiving the 180 signaling but the received 180 signaling indicates the local ringback tone, do not play the local ringback tone first, but wait for the third duration. If non-silent audio packets are received within the third duration, continue to play the network ringback tone, which can avoid interrupting the network ringback tone and ensure the user experience.

[0069] Otherwise, play the local ringback tone, thereby ensuring that the first terminal can always play an audible ringback tone.

[0070] According to the first aspect, or any implementation manner of the above first aspect, when the second signaling includes a PEM header field and the value included in the PEM header field is the second value, the second signaling is a signaling indicating the network ringback tone; within the fourth duration, when all the received audio packets are silent packets or no audio packets are received, play the local ringback tone; within the fourth duration, when there are non-silent packets among the received audio packets, continue to play the network ringback tone.

[0071] Among them, the fourth duration, such as 1 s or 2 s, can be specifically set according to service requirements, chip requirements of the first terminal, etc.

[0072] Therefore, in order to avoid a long wait for an audio packet from the network side or the played audio packet being a silent packet, which may cause the first terminal to have no sound and affect the user experience, for the case where the second signaling still instructs the first terminal to perform network ringback tone playback, the determination conditions of whether an audio packet sent by the network side is received within a set time and whether the received audio packets are all silent packets are still used to decide whether to change the ringback tone type to the local ringback tone to ensure that the first terminal can play the ringback tone in time.

[0073] According to the first aspect, or any implementation manner of the above first aspect, when the second signaling does not include the PEM header field, the ringback tone is played according to the ringback tone type indicated by the first signaling.

[0074] Therefore, for the scenario that supports resource reservation, that is, the scenario where the first signaling is received before the second signaling, when the second signaling does not include the PEM header field, the ringback tone type determined according to the first signaling and the condition for triggering playback are maintained, so as to ensure that the first terminal can always play a ringback tone and guarantee the user experience.

[0075] According to the first aspect, or any implementation manner of the above first aspect, the method further includes: before receiving the third signaling, the first terminal device continuously monitors the audio packets sent by the network side; when an audio packet sent by the network side is received and there is a non-silent packet among the received audio packets, the network ringback tone is played.

[0076] Among them, the third signaling is, for example, the accept call (200OK) signaling for answering a call.

[0077] This scenario mainly aims at the case where the chip adopted by the first terminal does not include the PEM header field by default and the ringback tone type is the local ringback tone, such as the situation 2 described in the following embodiments.

[0078] Therefore, before the 200OK signaling, the first terminal continuously monitors whether the network side sends non-silent audio packets. After receiving non-silent audio packets, the network ringback tone is preferentially played, which ensures the playback success rate of the customized ringback tone and improves the user experience.

[0079] According to the first aspect, or any implementation manner of the above first aspect, the third signaling is a signaling that makes a final response to the INVITE signaling.

[0080] According to the first aspect, or any implementation manner of the above first aspect, the third signaling is the 200OK signaling.

[0081] It can be understood that the 200OK signaling, that is, the accept call signaling, is a final response to the call request (INVITE).

[0082] In a second aspect, the present application provides a terminal device. The terminal device includes: a memory and a processor, the memory and the processor being coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the terminal device is caused to execute the instructions of the method in the first aspect or any possible implementation manner of the first aspect.

[0083] In a third aspect, the present application provides a computer-readable medium for storing a computer program, the computer program including instructions for executing the method in the first aspect or any possible implementation manner of the first aspect.

[0084] In a fourth aspect, the present application provides a computer program, the computer program including instructions for executing the method in the first aspect or any possible implementation manner of the first aspect.

[0085] In a fifth aspect, the present application provides a chip system, the chip system including a processor for calling and running a computer program from a memory, such that a terminal device installed with the chip system executes the method in the first aspect or any possible implementation manner of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] Figure 1 Schematic diagram of a communication environment for a terminal device to implement a call service shown by way of example;

[0087] Figure 2 Schematic diagram of a call processing procedure shown by way of example;

[0088] Figure 3 Schematic diagram of a return ringtone shown by way of example;

[0089] Figure 4 Schematic diagram of a calling terminal playing a return ringtone when the called terminal is ringing shown by way of example;

[0090] Figure 5 Schematic diagram of the hardware structure of a terminal device shown by way of example;

[0091] Figure 6A Schematic diagram of a flowchart of a return ringtone playing method provided by an embodiment of the present application shown by way of example;

[0092] Figure 6B Schematic diagram of a flowchart of another return ringtone playing method provided by an embodiment of the present application shown by way of example;

[0093] Figure 7A Schematic diagram of a scenario to which a return ringtone playing method is applicable shown by way of example;

[0094] Figure 7BSchematic diagram of another ringback tone playing method applicable to an exemplary scenario;

[0095] Figure 7C Schematic diagram of another ringback tone playing method applicable to an exemplary scenario;

[0096] Figure 8A Schematic diagram of another ringback tone playing method applicable to an exemplary scenario;

[0097] Figure 8B Schematic diagram of another ringback tone playing method applicable to an exemplary scenario;

[0098] Figure 8C Schematic diagram of another ringback tone playing method applicable to an exemplary scenario;

[0099] Figure 9 Schematic diagram of another ringback tone playing method applicable to an exemplary scenario;

[0100] Figure 10 Schematic diagram of the structure of a chip system shown by way of example;

[0101] Figure 11 Schematic diagram of the structure of a system-on-chip shown by way of example. Detailed implementation manners

[0102] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without making creative efforts belong to the scope of protection of the present application.

[0103] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone.

[0104] The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order of objects. For example, the first target object and the second target object are used to distinguish different target objects, rather than to describe a specific order of target objects.

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

[0106] In the description of the embodiments of the present application, unless otherwise specified, "a plurality of" means two or more. For example, a plurality of processing units means two or more processing units; a plurality of systems means two or more systems.

[0107] In the description of the embodiments of the present application, the names of each indication and / or command and / or instruction and / or information and / or signaling and / or message are only examples. In the specific implementation process, they can also be replaced with other names according to the actual scenario. The noun explanations of the names and terms in the actual implementation can also refer to the explanations in the 3rd generation partnership project (3GPP) standard protocol. The capitalization and spaces of the letters in the embodiments of the present application are only examples, and shall be subject to the regulations in the standard protocol.

[0108] In a communication system, a user equipment (UE) can communicate with the current access network to implement outgoing calls and incoming calls. Among them, the communication entities of the current access network can include radio access network (RAN) devices such as 3G base stations, 4G base stations, 5G base stations, 6G base stations, etc., and core network devices related to the radio access network devices. In the embodiments of the present application, the core network device can include one device in the core network, or the core network device can include multiple devices in the core network. The signaling transmission and interaction process, voice bearer establishment process, etc. involved in the embodiments of the present application are not limited to the interaction between the UE and the base station device, and the interaction between the base station devices, but should also include other network devices in the mobile communication system. For the sake of simplicity and easy understanding, they will not be elaborated here.

[0109] It should be noted that the core network device and the radio access network device can be independent different physical devices, or the functions of the core network device and the logical functions of the radio access network device can be integrated on the same physical device, or the functions of part of the core network device and part of the radio access network device can be integrated on one physical device. The terminal device can be fixed in position or movable.

[0110] To better understand the technical solutions provided by the embodiments of the present application, the following describes the communication environments applicable to the technical solutions provided by the embodiments of the present application.

[0111] First, it should be noted that each embodiment of the present application is applicable to a 3rd-Generation (3G) network, a 4th-Generation Mobile Communication Technology (4G) network, a 5th-Generation Mobile Communication Technology network, or a future next-generation mobile communication technology network. For ease of description, the 4G network architecture is used as an example for illustration below.

[0112] See Figure 1 , for the first UE and the second UE that want to establish a media session, they need to access the radio access network through the base stations in their respective cells. For example, the first UE accesses the radio access network through the first base station, and the second UE accesses the radio access network through the second base station.

[0113] Continue to see Figure 1 , exemplarily, when the first UE of the calling party calls the second UE of the called party, that is, when the first UE initiates a call request to the second UE, the first UE will transmit the call request to the calling IMS domain through the radio access network accessed by the first base station. The calling IMS domain will perform corresponding processing on the call request initiated by the first UE and forward the processed call request to the called IMS domain. The called IMS domain will perform corresponding processing on the call request processed by the calling IMS domain and send the call request to the second UE through the radio access network accessed by the second base station.

[0114] Continue to see Figure 1 , exemplarily, during the process of establishing a media session, the response made by the second UE to the call request initiated by the first UE, or the signaling sent down, etc., will be transmitted to the called IMS domain through the radio access network accessed by the second base station, then transmitted to the calling IMS domain through the called IMS domain, then sent down to the radio access network accessed by the first base station through the calling IMS domain, and finally sent down to the first UE by the radio access network accessed by the first base station.

[0115] Thus, through Figure 1 the network architecture shown, the interaction between the calling party and the called party in the call service is realized.

[0116] Regarding the above-mentioned IMS, i.e., the IP Multimedia Subsystem, which is a concept proposed by 3GPP and is a general network architecture for providing multimedia services over an IP-based network. It can provide converged multimedia services and Internet applications for users using different access means. Among them, VoLTE and VoNR are currently common voice services that adopt IP data transmission technology, i.e., voice services based on IMS. For the sake of convenience, in the embodiments of the present application, the call service initiated by the calling party to the called party takes the voice service scenario of VoLTE as an example.

[0117] In some implementation manners, IMS can be referred to as the IMS network. Among them, the IMS network may include a calling IMS domain (as Figure 1 shown) and a called IMS domain (as Figure 1 shown). Both the calling IMS domain and the called IMS domain may include an IMS domain core network and an Evolved Packet Core (EPC). Among them, the IMS domain core network may further include a serving-call session control function (S-CSCF), an interrogating-call session control function (I-CSCF), a Proxy-call session control function (P-CSCF), a home subscriber server (HSS), a session border controller (SBC), and several dedicated servers, such as a multimedia telephony application server (MMTel AS).

[0118] Since the above network elements are the corresponding network elements in the wireless communication network in the prior art, the present embodiment does not describe in detail the interaction and processed services among the above network elements. For specific implementation details, reference can be made to the standard protocol.

[0119] Through the above description of Figure 1 establishing a media session between the first UE and the second UE in the shown communication environment, it can be seen that during the process of establishing a media session between the first UE and the second UE, the radio access network (the first base station and the second base station) and the IMS network (the calling IMS domain and the called IMS domain) are mainly used for the transmission of requests, responses, signaling, etc. Ignoring the two network-side objects of the radio access network and the IMS network, the processing flow of the call service between the calling party and the called party can be asFigure 2 as shown

[0120] See Figure 2 Exemplarily, when the first UE (calling party) needs to establish a media session with the second UE, the first UE will initiate a call request or an invitation request to the second UE (called party), which is specifically implemented through an INVITE signaling (hereinafter referred to as: INVITE signaling).

[0121] Understandably, the ultimate purpose of a call is to enable two users to communicate. Generally, the media generated by the communication between users can be referred to as regular media. However, in practical applications, after the first UE initiates a call to the second UE, the communication between the two users does not start immediately (or may not start at all if the call fails), and the waiting time is generally from a few seconds to dozens of seconds, which entirely depends on when the second UE answers (answers the call). Before the second UE answers, there may also be a media stream between the first UE and the network. Different from regular media, the media generated during this period (before the second UE answers) can be referred to as early media.

[0122] For early media, the most typical one is the ring back tone (RING BACK TONE, RBT; or CALL BACK TONE, CBT). The so-called ring back tone is the ringtone played on the calling terminal when the calling terminal calls the called terminal. In different mobile communication fields, the playing rules of the ring back tone are different. For example, in the circuit switch (CS) domain, the ring back tone is generally local to the calling terminal. In the packet switch (PS) domain, the ring back tone can be provided by the network side.

[0123] In addition, the ring back tone package (local ring back tone package and network ring back tone package) may include: vibration, color ring tone, beep sound, personalized music, songs, recordings, videos, etc., which are not limited here.

[0124] For the sake of convenience of description, in this embodiment, the ring back tone provided by the network side is referred to as the network ring back tone, and the playing of the network ring back tone is referred to as network ring back tone playing; the ring back tone provided locally (usually a "beep" sound) is referred to as the local ring back tone, and the playing of the local ring back tone is referred to as local ring back tone playing.

[0125] Understandably, in some implementations, after receiving the signaling indicating the type of ringback tone, the first UE updates the call state to the ringback tone state and plays the ringback tone according to the type of ringback tone indicated by the signaling. Among them, for the local ringback tone, the first UE needs to play the local ringback tone after receiving 180 Ringing. For the network ringback tone, there is no need to pay attention to 180 Ringing. In the case of receiving the audio packet sent by the network side, the audio data in the audio packet can be played to perform network ringback tone playback.

[0126] Therefore, in order to enable the first UE to play the ringback tone during the process of waiting for the second UE to answer the call, when the first UE sends an INVITE signaling to the second UE, it is necessary to include information supporting early media. In this way, when the second UE sets a network ringback tone (color ringtone, such as music, song, story, character dialogue, etc.), the network side can send the audio packet of the network ringback tone set by the second UE to the first UE so that the first UE can play the network ringback tone set by the second UE.

[0127] Regarding the information supporting early media included in the INVITE signaling, it can be achieved by configuring the early media (P-Early-Media, PEM) identifier in the INVITE signaling and configuring the attribute of the identifier as supported, that is, configuring "P-Early-Media: supported".

[0128] Continue to refer to Figure 2 , exemplarily, after receiving the INVITE signaling transmitted by the first UE through the corresponding radio access network and IMS network, during the media negotiation process, the second UE can make a 100 Trying to the first UE, that is, a trial call.

[0129] It should be noted that during the media negotiation process, the 100 Trying made by the second UE is actually made to the core network. After the trial call between the second UE and the core network is successful, the core network makes a 100 Trying to the first UE. Since Figure 2 the radio access network and IMS network are omitted, therefore Figure 2 the 100 Trying shown in

[0130] Continue to refer to Figure 2 , exemplarily, after the trial call is successful, the second UE can establish the bearer required for this call service with the first UE, such as establishing a bearer with the Quality of Service Class Identifier (QCI) value of 1, that is, the QCI of the created bearer = 1.

[0131] It should be noted that after the trial call is successful, the first UE and the second UE will establish the bearers required for this call with their respective core networks.

[0132] Since Figure 2 the radio access network and the IMS network are omitted, Figure 2 the established bearers shown in [Figure] are directly directed to the second UE and the first UE.

[0133] Understandably, a bearer refers to a network connection established between two nodes of a network, such as between the first UE and the core network, or between the second UE and the core network, for transmitting data or signaling, as well as the underlying network resources. That is to say, after the bearers are established between the first UE and the core network, and between the second UE and the core network, the first UE and the second UE can perform data and signaling interactions based on their respective corresponding bearers.

[0134] Understandably, QCI is a parameter used by the system to identify the transmission characteristics of service data packets. Different bearer services correspond to different QCI values. For specific details, reference can be made to the standard protocol regulations, which will not be elaborated here. In this embodiment, the QCI value of the bearer to be created between the first UE and the second UE is taken as 1.

[0135] Continuing to refer to Figure 2 , for example, after the bearer between the first UE and the core network is established, the core network can send the audio packet corresponding to the network ringback tone to the first UE through this bearer. For a core network that supports resource reservation, usually an 183 signaling is sent after the bearer is established, and the resource reservation process is completed through the Session Description Protocol (SDP).

[0136] In order to enable the first UE to play the ringback tone as soon as possible, in addition to sending an SDP Answer, the 183 signaling can also be used to inform the first UE whether the ringback tone type that can be played before waiting for the second UE's response is the network ringback tone or the local ringback tone.

[0137] Specifically, when determining the ringback tone type according to the 183 signaling, it is specifically related to the PEM header field (that is, the P-Early-Media identifier mentioned above, which will be uniformly described as the PEM header field hereinafter). Regarding the relationship between the PEM header field in the 183 signaling and the ringback tone type, it can be as shown in Figure 2 Table 1 shown in [Figure].

[0138] Through Figure 2It can be seen from Table 1 shown in that in a possible case, such as when the 183 signaling includes a PEM header field and the value of the PEM header field is Inactive ("P-Early-Media: Inactive" is configured in the 183 signaling), in a possible implementation method, it can be determined that the ringback tone type is a local ringback tone, that is, the first UE needs to perform local playback (the audio data corresponding to the ringback tone is provided by the first UE itself).

[0139] Continue to see Figure 2 As shown in Table 1, in another possible case, such as when the 183 signaling includes a PEM header field, but the value of the PEM header field is not Inactive, but Sendrecv, or Recvonly ("P-Early-Media: Sendrecv" or "P-Early-Media: Recvonly" is configured in the 183 signaling), in a possible implementation method, it can be determined that the ringback tone type is a network ringback tone, that is, the first UE needs to perform network playback (the audio data corresponding to the ringback tone is provided by the network side).

[0140] Continue to see Figure 2 As shown in Table 1, in another possible case, such as when the 183 signaling does not include the PEM header field, affected by the chip used by the first UE, the ringback tone type can be a network ringback tone or a local ringback tone.

[0141] For example, for the chips used (such as Figure 2 The chip provided by the first chip platform shown in the figure) stipulates that when the PEM header field is not included, the ringback tone type is a network ringback tone. For such terminals, the ringback tone type can be determined as a network ringback tone in this scenario.

[0142] For example, for the chip used (such as Figure 2 The chip provided by the second chip platform shown in the figure) stipulates that when the PEM header field is not included, the ringback tone type is a local ringback tone. For such terminals, the ringback tone type can be determined as a local ringback tone in this scenario.

[0143] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation to this embodiment.

[0144] The Inactive mentioned in the embodiment of the present application indicates that the early media function is not supported. Understandably, when the value of the PEM header field of the signaling sent by the network side is Inactive, it means that the network side usually does not send and receive data streams, so the calling terminal should not receive audio packets. In this case, the calling terminal will determine the ringback tone type as a local ringback tone.

[0145] Regarding the Sendrecv mentioned in the embodiments of the present application, it means allowing bidirectional transmission, that is, allowing the calling terminal that receives the signaling including this value to send a data stream to the core network, and also allowing the calling terminal to receive the data stream sent by the network side, such as the audio packet corresponding to the network ringback tone.

[0146] Regarding the Recvonly mentioned in the embodiments of the present application, it means allowing data reception, such as receiving the audio packet corresponding to the network ringback tone.

[0147] Regarding the direction of the media stream indicated by different values of the PEM header field, reference can be made to the standard protocol, which will not be elaborated here.

[0148] In addition, it should be noted that for the network ringback tone, the audio packet provided by the network side is essentially a network transport protocol packet, which can be an RTP (Real-time Transport Protocol) packet.

[0149] Continue to refer to Figure 2 , for example, when the second UE can remind the called party of a call, that is, when the second UE rings, the second UE will send a ringing signaling, such as Figure 2 180Ringing in

[0150] It can be understood that in addition to informing the first UE that the called terminal (the second UE) has rung, the 180 signaling can also be used to inform the first UE which type of ringback tone can be played before waiting for the second UE to answer, whether it is a network ringback tone or a local ringback tone.

[0151] Specifically, when determining the ringback tone type according to the 180 signaling, it is not only related to the PEM header field, but also related to whether network resource reservation is currently supported (that is, whether the 183 signaling is received). Regarding the relationship between the PEM header field in the 180 signaling and the ringback tone type, it can be as shown in Figure 2 Table 2 shown in

[0152] Through Figure 2 Table 2 shown in

[0153] Continue to refer to Figure 2Table 2 shown in [document], regardless of whether the first UE has received the 183 signaling, when the first UE has received the 180 signaling including the PEM header field, but the value of the PEM header field is not Inactive, but Sendrecv or Recvonly (the "P-Early-Media: Sendrecv" or "P-Early-Media: Recvonly" is configured in the 180 signaling), in one possible implementation, the ringback tone type can be determined as the network ringback tone, that is, the first UE needs to perform network playback of the ringback tone.

[0154] Continue to refer to Figure 2 Table 2 shown in [document], for the case where the first UE has received the 183 signaling, when the first UE has received the 180 signaling that does not include the PEM header field, in one possible implementation, the first UE can maintain the ringback tone type determined according to the 183 signaling, that is, does not change the ringback tone type. When the ringback tone type determined according to the 183 signaling is the network ringback tone, the first UE still maintains the network ringback tone; when the ringback tone type determined according to the 183 signaling is the local ringback tone, the first UE still maintains the local ringback tone.

[0155] Continue to refer to Figure 2 Table 2 shown in [document], for the case where the first UE has not received the 183 signaling, when the first UE has received the 180 signaling that does not include the PEM header field, affected by the chip used by the first UE, the ringback tone type can be the network ringback tone or the local ringback tone.

[0156] For example, for the chip adopted (such as Figure 2 the chip provided by the first chip platform shown in [document]) where it is specified that when there is no PEM header field, the ringback tone type is the network ringback tone. For such terminals, in this scenario, the ringback tone type can be determined as the network ringback tone.

[0157] Also for example, for the chip adopted (such as Figure 2 the chip provided by the second chip platform shown in [document]) where it is specified that when there is no PEM header field, the ringback tone type is the local ringback tone. For such terminals, in this scenario, the ringback tone type can be determined as the local ringback tone.

[0158] It should be understood that the above descriptions are only examples listed for better understanding of the technical solution of this embodiment and do not serve as the sole limitation of this embodiment.

[0159] Continue to refer to Figure 2For example, if the call service continues to proceed normally, the second UE will make a 200OK success response (the final response to the INVITE signaling) to the first UE. Accordingly, after receiving the 200OK from the second UE, the first UE will make an ACK response to the second UE, that is, inform the second UE that the first UE has received the final response of the second UE to the INVITE signaling.

[0160] Continue to see Figure 2 For example, after the first UE makes an ACK response to the second UE, the media session between the first UE and the second UE is successfully established. At this time, the first UE can talk with the second UE.

[0161] Continue to see Figure 2 For example, if the second UE hangs up after a certain length of time, the second UE will send a BYE instruction to the first UE to terminate the established call. Accordingly, after receiving the BYE instruction, the first UE ends the call with the second UE and responds with 200OK, informing the second UE that the first UE has received the second UE's instruction to end the current session, thus terminating the session.

[0162] It is understandable that the BYE instruction may also be initiated by the first UE to the second UE, that is, the calling user first performs an on-hook operation using the first UE. Accordingly, the 200OK response confirming the end of the current session is made by the second UE.

[0163] Thus, a normal call service processing between the first UE and the second UE is completed.

[0164] From the above description, it can be seen that the processing logic of playing the ringback tone is mainly completed by the calling terminal that initiates the call request. Therefore, in a possible implementation, the processing logic of the calling terminal in the call service can be as follows: Figure 3 shown.

[0165] 101. The first UE sends a call request (INVITE) signaling.

[0166] Specifically, the first UE sends the INVITE signaling to the network side.

[0167] Optionally, the first UE sends the INVITE signaling to the first base station, and then the first base station sends the INVITE signaling to the corresponding core network device.

[0168] Exemplarily, the INVITE signaling may include the information "P-Early-Media: supported", that is, it may include the information supporting PEM. In a specific implementation, for example, "P-Early-Media: supported" can be configured in the SDP of the INVITE signaling, so as to include the information supporting PEM.

[0169] 102. The first UE receives a signaling indicating the network ringback tone.

[0170] Optionally, while waiting for the second UE to answer the call, the first UE receives a message indicating the network ringback tone.

[0171] Understandably, while waiting for the second UE to answer the call, the first UE receives signaling that can indicate the type of ringback tone, such as 183 signaling, 180 signaling, etc. Among them, the 183 signaling is usually the first signaling that can indicate the type of ringback tone sent by the network side after the first UE initiates a call request. The 180 signaling is the last signaling that can indicate the type of ringback tone sent by the network side.

[0172] In addition, it should also be understood that for the local ringback tone, it needs to start playing after receiving the 180 signaling indicating local tone playback. For the network ringback tone, the 180 signaling can be ignored, and it can start when receiving the audio packet corresponding to the network ringback tone.

[0173] Regarding the details of determining whether the ringback tone type is the network ringback tone according to the 183 signaling and 180 signaling, reference can be made to Figure 2 Table 1 and Table 2 shown in

[0174] In addition, it should be noted that in actual applications, the first UE can also determine the ringback tone type according to other signaling that can indicate the ringback tone type. For example, it can be determined according to the Update signaling (signaling for the user to send an update message) received before the 180 signaling. Regarding the relationship between the PEM header field in the Update signaling and the ringback tone type, in a possible implementation, it can be the same as the relationship between the PEM header field in the 180 signaling and the ringback tone type. Specifically, reference can be made to Figure 2 Table 2 shown in

[0175] 103. The first UE starts timing from the first moment, and the timing duration is the first duration. It monitors whether it receives an audio packet sent by the network side within the first duration.

[0176] It should be noted that, usually, after the first UE receives the signaling indicating network ringback tone, the network side will send the audio packet corresponding to the network ringback tone to the first UE. To ensure the user experience and avoid waiting for a long time for the audio packet corresponding to the network ringback tone, resulting in the first UE being unable to play the ringback tone all the time. In a possible implementation, the first UE can be set to start timing from the first moment when it receives the message indicating the network ringback tone.

[0177] Optionally, the timing duration can be the first duration, such as 2s.

[0178] In this way, the first UE can monitor whether it receives the audio packet corresponding to the network ringback tone sent by the network side within the first duration, such as 2s.

[0179] Optionally, it can be set that when the first UE receives the audio packet sent by the network within this first time, it performs network ringback tone playback and plays the audio data in the audio packet, that is, step 104 is executed. Otherwise, when the first UE does not receive the audio packet sent by the network within this first time, it performs local ringback tone playback and plays the audio data stored in the local storage medium of the first UE, that is, step 105 is executed.

[0180] Optionally, in one implementation, it can be set that after the first UE receives the signaling indicating network ringback tone, it starts a 2s timer. When it receives the audio packet sent by the network side within the timing duration of this timer, step 104 is executed; otherwise, step 105 is executed.

[0181] 104, The first UE plays the network ringback tone.

[0182] Optionally, when the first UE plays the network ringback tone, the field in the obtained log information that identifies the ringback tone type, such as the value of CID is 1. That is, when CID = 1, it indicates that the ringback tone played by the first UE is the network ringback tone.

[0183] 105, The first UE plays the local ringback tone.

[0184] Optionally, when the first UE plays the local ringback tone, the field in the obtained log information that identifies the ringback tone type, such as the value of CID is -1. That is, when CID = -1, it indicates that the ringback tone played by the first UE is the local ringback tone.

[0185] In addition, it should be noted that in the scenario where the first UE calls the second UE, when the first UE determines the ringback tone type according to the signaling indicating the ringback tone type fed back by the core network and starts to play the ringback tone, a prompt that the other party is ringing can also be displayed in the user interface of the first UE, such as Figure 4As shown in (1). That is, the user interface of the first UE can display a prompt message indicating that the other party is ringing, and the receiver or speaker of the first UE will play the ringback tone.

[0186] However, in the scenario where the ringback tone type is a network ringback tone, it may be that all the audio data in the audio packet sent by the network side are silent frames (i.e., audio frames without sound), resulting in no sound when the first UE plays the ringback tone. As Figure 4 shown in (2), only the user interface of the first UE displays a prompt message indicating that the other party is ringing, but there is no sound in the receiver or speaker, causing the user to mistakenly think that the call has failed and affecting the user experience.

[0187] In view of this, the embodiments of the present application provide a method for playing a ringback tone. In this method, for the scenario where the ringback tone is provided by the network side, the calling terminal monitors whether it receives an audio packet provided by the network side within a specified time, and determines whether the data in the audio packet is a silent frame, and then decides whether to continue playing the network ringback tone or change to play a local ringback tone, so as to ensure that the calling terminal can play the ringback tone in time to give a prompt to the user.

[0188] To better understand the method for playing a ringback tone provided by the embodiments of the present application, the following first combines Figure 5 to describe the hardware structure of the terminal device to which this method is applicable.

[0189] See Figure 5 , which is a schematic diagram of the hardware structure of the terminal device 100 for exemplarily showing the implementation of the method for playing a ringback tone provided by the embodiments of the present application.

[0190] It should be noted that the terminal device can also be expressed as a user equipment (UE). Specifically in this embodiment, it refers to a user registered to the IMS network, which can include a mobile terminal, a fixed terminal, a SIP soft terminal, etc.

[0191] The so-called SIP refers to the Session Initialization Protocol. SIP is a multimedia communication protocol developed by the Internet Engineering Task Force (IETF). It is a text-based application layer control protocol used to create, modify, and release sessions of one or more participants.

[0192] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment and does not serve as the only limitation to this embodiment.

[0193] For the sake of convenience of description, in this embodiment, a mobile terminal, such as a mobile phone, is taken as an example to illustrate the hardware structure of the terminal device 100.

[0194] Referring to Figure 5 , by way of example, the terminal device 100 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 key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0195] Among them, the antenna 1 and the antenna 2 are used for transmitting and receiving electromagnetic wave signals.

[0196] Specifically, in the embodiments of the present application, INVITE signaling, 100Trying, 183Session Progress, 180Ringing, 200OK, ACK, BYE, audio packets, etc. sent or received by the terminal device 100 can be implemented through the antenna 1 or the antenna 2.

[0197] Continuing to refer to Figure 5 , by way of example, the mobile communication module 150 may provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc. applied to the terminal device 100. The wireless communication module 160 may provide solutions for wireless communications including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc. applied to the terminal device 100.

[0198] By way of example, in some implementation manners, the antenna 1 of the terminal device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the terminal device 100 can communicate with the network and other devices through wireless communication technologies.

[0199] Continue to refer to Figure 5 Exemplarily, the audio module 170 of the terminal device 100 includes a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, etc.

[0200] Exemplarily, the terminal device 100 can implement audio functions through the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D in the audio module 170, and the application processor, etc., such as playing the audio data of the network ringback tone or the local ringback tone described in the embodiments of the present application.

[0201] In addition, regarding the sensor module 180 in the terminal device 100, in some embodiments, it may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc. Details are not listed here one by one, and the present application does not limit this.

[0202] In addition, it should be noted that in some implementation manners, the processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor (Modem), a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc.

[0203] Understandably, in specific implementations, different processing units may be independent devices or integrated in one or more processors.

[0204] In addition, it should also be noted that in some implementation manners, the controller may be the nerve center and command center of the terminal device 100. In practical applications, the controller can generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching instructions and executing instructions.

[0205] In addition, it should be noted that in some implementation manners, a memory may also be provided in the processor 110 for storing instructions and data. In some implementation manners, the memory in the processor 110 is a cache memory. This memory can save the instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0206] In addition, it should be noted that in some implementation manners, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0207] Continue to refer to Figure 5 Exemplarily, the charging management module 140 is configured to receive a charging input from a charger. Among them, while the charging management module 140 charges the battery 142, it can also supply power to the terminal device through the power management module 141.

[0208] Continue to refer to Figure 5, Exemplarily, the power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives inputs from the battery 142 and / or the charging management module 140 and supplies power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, the wireless communication module 160, etc. The power management module 141 can also be used to monitor parameters such as the battery capacity, the number of battery charge cycles, and the battery health status (leakage, impedance). In some other implementation manners, the power management module 141 can also be disposed in the processor 110. In some other implementation manners, the power management module 141 and the charging management module 140 can also be disposed in the same device.

[0209] Continue to refer to Figure 5 , Exemplarily, the wireless communication function of the terminal device 100 can be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the Modem 110A, etc. Specifically, in the technical solution provided by the embodiments of the present application, after a call service is initiated, the processing logic for playing the ringback tone can be implemented by these modules.

[0210] In addition, Figure 5 The terminal device 100 shown in Figure 4 can implement the display function through the GPU, the display screen 194, and the application processor, such as displaying Figure 4 the user interface in (1) or

[0211] in (2) in

[0212] In addition, Figure 5 The external memory interface 120 shown in

[0213] can be used to connect an external memory card, such as a Micro SD card, to implement the storage capacity expansion of the terminal device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement the data storage function. Figure 5 In addition,

[0214] Specifically, in the technical solution provided by the embodiments of the present application, the audio data corresponding to the local ringback tone and the related instructions for implementing the ringback tone playing method can be pre-stored in the internal memory 121, and the processor 110 can execute the instructions stored in the internal memory 121, so that the terminal device 100 can execute the ringback tone playing method provided by the embodiments of the present application.

[0215] Continuing to refer to Figure 5 , by way of example, the button 190 includes a power-on button, a volume button, etc. The button 190 can be a mechanical button or a touch button. The motor 191 can generate a vibration prompt. The indicator 192 can be an indicator light, which can be used to indicate the charging state, the change of battery power, etc., or can also be used to indicate messages, such as missed calls, notifications, etc.

[0216] Continuing to refer to Figure 5 , by way of example, the SIM card interface 195 is used to connect a SIM card or a USIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the terminal device 100. The terminal device 100 can support one or N (N is an integer greater than 1) SIM card interfaces 195. That is, multiple SIM cards or USIM cards can be inserted into the terminal. Specifically, in the technical solution provided by this embodiment, VoLTE is implemented based on the SIM card or USIM card.

[0217] The introduction to the hardware structure of the terminal device 100 ends here. It should be understood that Figure 5 the illustrated terminal device 100 is only an example. In specific implementations, the terminal device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 5 The various components shown in

[0218] can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits. Figure 5 Taking the terminal device with the hardware structure shown in Figure 1 as an example, and still taking the 4G network architecture as an example for the illustrated communication environment, the process of the terminal device implementing the ringback tone playing method provided by the present application will be specifically described.

[0219] It should be noted that the implementation of the call service needs to be based on the processing of the Modem protocol stack. Therefore, when implementing the ringback tone playing method provided by the embodiments of the present application, the strategies, processing logics, etc. followed by the terminal device can be set in the Modem protocol stack. That is, for the operations performed by the calling terminal (such as the first UE) in the ringback tone playing methods provided in the following embodiments, they are all completed in the Modem protocol stack.

[0220] See Figure 6A , the ringback tone playing method provided by the embodiment of the present application specifically includes:

[0221] 201. The first UE sends a call request (INVITE) signaling.

[0222] Specifically, the first UE sends the INVITE signaling to the network side.

[0223] Optionally, the first UE sends the INVITE signaling to the first base station, and then the first base station sends the INVITE signaling to the corresponding core network device.

[0224] Exemplarily, the INVITE signaling may include "P-Early-Media: supported" information, that is, it may include information supporting PEM. In a specific implementation, for example, "P-Early-Media: supported" can be configured in the SDP of the INVITE signaling to implement including information supporting PEM.

[0225] 202. The first UE receives a signaling indicating a network ringback tone.

[0226] Optionally, the first UE receives a message indicating a network ringback tone during the process of waiting for the second UE to answer the call.

[0227] Understandably, the first UE is during the process of waiting for the second UE to answer the call corresponding to the INVITE signaling initiated in step 201.

[0228] Understandably, during the process of waiting for the second UE to answer the call, the first UE receives signaling that can indicate the type of ringback tone, such as 183 signaling, 180 signaling, etc. Among them, the 183 signaling is usually the first signaling that can indicate the type of ringback tone sent by the network side after the first UE initiates a call request. The 180 signaling is the last signaling that can indicate the type of ringback tone sent by the network side.

[0229] In addition, it should also be understood that for the local ringback tone, it needs to start playing after receiving the 180 signaling indicating local playback. For the network ringback tone, the 180 signaling can be ignored, and it can start when receiving the audio packet corresponding to the network ringback tone.

[0230] Regarding the details of determining whether the type of ringback tone is a network ringback tone according to the 183 signaling and 180 signaling, reference can be made to Figure 2 Table 1 and Table 2 shown therein, which will not be elaborated here.

[0231] In addition, it should be noted that in actual applications, the first UE can also determine the ringback tone type according to other signaling that can indicate the ringback tone type. For example, it can be determined according to the Update signaling (signaling for the user to send an update message) received before the 180 signaling. Regarding the relationship between the PEM header field in the Update signaling and the ringback tone type, in a possible implementation, it can be the same as the relationship between the PEM header field in the 180 signaling and the ringback tone type. Specifically, reference can be made to Figure 2 Table 2 shown in

[0232] 203, the first UE starts timing from the first moment, and the timing duration is the first duration, and monitors whether an audio packet sent by the network side is received within the first duration.

[0233] From the above description, it can be seen that in the scenario where the ringback tone type is the network ringback tone, due to certain abnormalities, the audio packet corresponding to the network ringback tone may not reach the first UE in time. To avoid affecting the user experience, a reasonable time, such as 1 s or 2 s, can be set according to service requirements, chip requirements adopted by the first UE, etc. And it is stipulated that when the audio packet corresponding to the network ringback tone is not received within the set time (the first time), the ringback tone type is changed from the network ringback tone to the local ringback tone in time. Since the audio data corresponding to the local ringback tone is pre-stored in the storage medium of the first UE locally, such as the internal memory 121 mentioned above, the first UE can directly play it. Therefore, after receiving the signaling indicating the network ringback tone, a timer with a timing duration of 1 s or 2 s can be directly started, and then it is set that when the audio packet sent by the network is not received within the timing duration corresponding to the timer, step 205 is executed. On the contrary, when the audio packet sent by the network is received within the timing duration corresponding to the timer, step 204 is executed to detect whether the received audio packet is a silent packet, so as to avoid the situation that the audio packet is received within the set time, but since all the received audio packets are silent packets, the first UE still cannot play the ringback tone sound.

[0234] It should be noted that for the signaling indicating the network ringback tone type received before the 180 signaling, such as the 183 signaling, the Update signaling, etc., affected by the chip, when receiving the 183 signaling or the Update signaling that does not include the PEM header field, it may be default that the ringback tone type is indicated as the network ringback tone (Situation 1), or it may be default that the ringback tone type is indicated as the local ringback tone (Situation 2). Therefore, for these two situations, the processing logic for playing the ringback tone provided in the embodiments of the present application can be different.

[0235] Specifically, for Situation 1, it can be directly carried out according to the Figure 6A shown judgment logic. For Situation 2, it can be directly carried out according to the Figure 6BThe judgment logic shown is carried out and will not be elaborated here for the time being.

[0236] 204, whether all the audio packets received by the first UE within the first time are silent packets.

[0237] In Figure 3 In the embodiment shown, since only the audio packets corresponding to the network ringback tone received within the timing time corresponding to the started timer are concerned, if an audio packet is received within the timing time (the first time), network playback is directly performed without concerning whether the data in the audio packet are all silent frames, thus causing the situation that when all the audio packets are silent packets, the first UE cannot play the ringback tone, affecting the user experience. Therefore, in the embodiment of the present application, not only whether an audio packet is received within the timing time is concerned, but also whether all the audio packets received within the timing time are silent packets, that is, whether no sound can be played.

[0238] Specifically, in this embodiment, when the first UE receives an audio packet within the timing time and all the received audio packets are silent packets, the ringback tone type is directly changed to the local ringback tone, so that the first UE can directly read the audio data corresponding to the local ringback tone from the local storage medium for playback, that is, step 205 is executed. Otherwise, if there is a non-silent packet among the audio packets received within the timing time, that is, as long as an audible audio packet is received within the timing time, regardless of whether the audio is continuous, the network ringback tone is played, that is, step 206 is executed.

[0239] Regarding the operation of determining whether the audio packet received from the network side is a silent packet, in some implementation manners, it can be determined whether the entire audio packet is a silent packet by determining whether the frame type (FT) flag bit included in the received audio packet is a predetermined silent value.

[0240] Taking the audio packet using the voice coding file format of Adaptive Multi-Rate (AMR; it can also be referred to as: AMR-NB) or Adaptive Multi-Rate Wideband (AMR-WB) as an example, both of these two formats of audio packets include the FT flag bit, and the specific value of the FT flag bit corresponding to the silent packet is defined. For example, for the AMR-NB format audio packet, the defined silent value is 8. For the AMR-WB format audio packet, the defined silent value is 9. Specifically, the corresponding standard protocols of these two voice coding file formats can be referred to and will not be elaborated here.

[0241] That is to say, for an audio packet in AMR-NB format, when the value of the FT flag bit included is 8, it indicates that the audio packet is a silent packet; otherwise, it can be considered that there is an audio frame in the audio packet that can play sound. For an audio packet in AMR-WB format, when the value of the FT flag bit included is 9, it indicates that the audio packet is a silent packet; otherwise, it can be considered that there is an audio frame in the audio packet that can play sound.

[0242] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment, and does not serve as the only limitation to this embodiment. In practical applications, if the received audio packet is in other voice coding formats, such as Enhance Voice Services (EVS), the flag bit that can identify whether the audio packet is a silent packet can be determined according to the standard protocol of the EVS format, and then whether the audio packet is a silent packet can be determined according to the value of this flag bit.

[0243] In addition, it should be noted that in some possible implementation manners, the audio packet of the network ringback tone sent by the network side is sent to the first UE based on the Real-time Transport Protocol (RTP). Therefore, the audio packet can also be called an RTP packet.

[0244] Optionally, in some possible implementation manners, RTP includes, for example, an audio packet named "NALDBG" (subsequently referred to as: NALDBG audio packet).

[0245] Optionally, in one possible implementation manner, when determining whether an audio packet is a silent packet, it can also be determined whether the audio packet is a silent packet according to the length of the NALDBG audio packet.

[0246] Optionally, when the length of the NALDBG audio packet is in the range of 15 to 25 (including the endpoint values), it can be confirmed that it is a silent packet.

[0247] Optionally, in one possible implementation manner, the length can be, for example, 17, or 18, or 19, or 21, that is, any value in the range of 15 to 25.

[0248] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment, and does not serve as the only limitation to this embodiment.

[0249] In addition, it should also be noted that in some other possible implementation manners, the name of the audio packet can be ignored, and when a data packet sent by the network side based on the real-time transport protocol is received, this data packet can be regarded as the audio packet of the network ringback tone.

[0250] In addition, it should be noted that in a possible implementation manner, when determining whether an audio packet is a silent packet, it can also be determined according to the packet type of the audio packet.

[0251] Optionally, when the packet type of the audio packet is a preset packet type, it is determined that the audio packet is a silent packet. In this case, the first UE can play the local ringback tone.

[0252] Optionally, in a possible implementation manner, the preset packet type is SID (COMFORT NOISE FRAME).

[0253] 205, the first UE plays the local ringback tone.

[0254] It should be noted that for the local ringback tone, it is necessary to receive the 180 signaling before starting to play the local tone. Therefore, in the scenario where the signaling indicating the network ringback tone received previously is the 180 signaling, when no audio packet is received within the set time, or all the received audio packets are silent packets, the first UE can directly play the local tone.

[0255] Exemplarily, for the scenario where the signaling indicating the network ringback tone received previously is other signaling, such as the 183 signaling, or the Update signaling, or other signaling that can indicate the ringback tone type, when no audio packet is received within the set time, or all the received audio packets are silent packets, after the first UE changes the ringback tone type to local play, it needs to wait for the 180 signaling.

[0256] It can be understood that when the 180 signaling is received and the network type indicated by the 180 signaling is also the local ringback tone, the first UE can play the local tone. When the network type indicated by the 180 signaling is the network ringback tone, the ringback tone type needs to be changed back to the network ringback tone again, and further monitor whether an audio packet that is not a silent packet is received within the set time, that is, it is necessary to re - execute the judgment in steps 203 and 204, and when it is determined that no audio packet is received within the set time, or all the received audio packets are silent packets, the first UE changes the ringback tone type back to the local ringback tone again, and then plays the local tone.

[0257] 206, the first UE plays the network ringback tone.

[0258] It should be noted that in order to avoid getting into an endless loop of judgment, it can be set that after the calling terminal receives the 180 signaling, it only executes the Figure 6A judgment logic of steps 203 to 204 as shown.

[0259] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment, and is not the only limitation of this embodiment. In practical applications, the number of judgment times can also be set according to business needs.

[0260] Thus, for the scenario where the ringback tone type of the first UE is the network ringback tone, that is, the audio data of the ringback tone to be played is provided by the network side, by monitoring whether an audio packet provided by the network side is received within a specified time, and determining whether each received audio packet is a silent packet, it is further decided whether to continue playing the network ringback tone or change to playing the local ringback tone, so as to ensure that the first UE can play the ringback tone in time and give a prompt to the user.

[0261] See Figure 6B , the embodiment of the present application provides a ringback tone playing method for the above-mentioned situation 2, which specifically includes:

[0262] 301. The first UE sends a call request (INVITE) signaling.

[0263] Step 301 in this embodiment is similar to steps 101 and 102 in the above embodiment. For specific details, please refer to the above embodiment and will not be elaborated here.

[0264] 302. The first UE receives a 183 signaling.

[0265] Optionally, the first UE receives a 183 signaling sent by the network side.

[0266] 303. The first UE determines whether the ringback tone type indicated by the 183 signaling is the local ringback tone or the network ringback tone.

[0267] Regarding the details of determining whether the ringback tone type is the network ringback tone according to the 183 signaling, reference can be made to Figure 2 Table 1 shown in, and in this embodiment, taking the chip of the second chip platform used by the first UE as an example (that is, when the 183 signaling does not include the PEM header field, it indicates local playback), it will not be elaborated here.

[0268] 304. The first UE sets the ringback tone type to the network ringback tone.

[0269] Optionally, when the 183 signaling indicates that the ringback tone type is the network ringback tone, that is, PEM header field = Sendrecv / Revonly, the first UE sets the ringback tone type to the network ringback tone.

[0270] 305. The first UE monitors whether a non-silent packet sent by the network side is received within the first time period.

[0271] That is, execute Figure 6AThe logics of step 203, step 204 and step 205 will not be elaborated here.

[0272] 306, the first UE plays the network ringback tone.

[0273] Optionally, when the first UE receives a non-silent packet sent by the network side within the first duration, it plays the network ringback tone, that is, plays the audio data in the non-silent packet.

[0274] 307, the first UE sets the ringback tone type to the local ringback tone.

[0275] Optionally, when the 183 signaling indicates that the ringback tone type is the local ringback tone, that is, PEM = Inactive, or when the PEM header field is not included, the first UE sets the ringback tone type to the local ringback tone.

[0276] 308, the first UE receives the 180 signaling.

[0277] Understandably, according to Figure 2 Table 2 in [reference], when the 183 signaling is received before the 180 signaling, the 180 signaling has three cases of indicating the ringback tone type. Specifically, these three cases include: the 180 signaling indicates that the ringback tone type is the network ringback tone, that is, the case where the PEM header field = Sendrecv / Revonly (subsequently referred to as case 2.1); the 180 signaling indicates that the ringback tone type is the local ringback tone, that is, the case where PEM = Inactive (subsequently referred to as case 2.2); the 180 signaling does not indicate the ringback tone type, that is, the case where the PEM header field is not included (subsequently referred to as case 2.3).

[0278] Among them, in the scenario of case 2.1, the first UE will execute step 309. In the scenario of case 2.2, the first UE will execute step 310. In the scenario of case 2.3, the first UE will execute step 311.

[0279] Understandably, case 2.1, case 2.2 and case 2.3 are three separately occurring cases.

[0280] 309, the first UE sets the ringback tone type to the network ringback tone.

[0281] 310, the first UE continues to use the previously set ringback tone type.

[0282] 311, the first UE sets the ringback tone type to the local ringback tone.

[0283] 312, the first UE monitors whether it receives a non-silent packet sent by the network side within the third duration.

[0284] That is, execute Figure 6AThe logics of step 203, step 204 and step 205 are not elaborated here.

[0285] 313. The first UE plays the network ringback tone.

[0286] 314. The first UE plays the local ringback tone.

[0287] In addition, it should be noted that for the scenario of case 2 (the first UE uses the chip of the second chip platform), even if the 180 signaling is received and the local ringback tone starts to be played, before the call acceptance (200OK) signaling is received, as long as the audio packet corresponding to the network ringback tone sent by the network side is received, the ringback tone type will be changed to the network ringback tone, and then the network ringback tone will be played. Therefore, during the process of the first UE executing step 302 to step 314, the first UE will also execute step 315.

[0288] 315. The first UE continuously monitors whether it receives the audio packet sent by the network side and detects whether the received audio packet is a non - silent packet.

[0289] Optionally, after the first UE receives the 183 signaling and before receiving the 200OK signaling, it can continuously monitor whether it receives the audio packet sent by the network side and detect whether the received audio packet is a non - silent packet.

[0290] Specifically, in the case of detecting a non - silent packet sent by the network side, the first UE can execute step 316. Otherwise, the first UE can continue to monitor whether it receives the audio packet sent by the network side and detect whether the received audio packet is a non - silent packet until the 200OK signaling is received.

[0291] 316. The first UE sets the ringback tone type to the network ringback tone, starts to play the network ringback tone, and terminates the monitoring.

[0292] That is, after the first UE receives the non - silent packet sent by the network side in step 315, it will terminate this monitoring. That is, the logic from step 315 to step 316 is only executed once, and subsequently, the ringback tone type is set according to the signaling that can indicate the ringback tone type, and the corresponding ringback tone is played.

[0293] Thus, for the scenario where the signaling received by the first UE before the 200OK signaling indicates the local ringback tone, by monitoring whether an audio packet is received before the 200OK signaling, and timely changing the ringback tone type to the network ringback tone when the audio packet is received, and determining whether each audio packet received within the specified time is a silent packet, and then deciding whether to continue playing the network ringback tone or change to play the local ringback tone, it can ensure that the first UE can play the ringback tone in time to prompt the user.

[0294] To better understand the ringback tone playing method provided in the embodiments of the present application, still taking the 4G network architecture as an example, the following will be described through several specific scenarios.

[0295] Before describing the ringback tone playing method provided in the embodiments of the present application, first, the specific object performing this operation in the calling terminal will be described. From the above description, it can be seen that the implementation of the call service needs to be based on the processing of the Modem protocol stack, specifically implemented in the Session Initiation Protocol module (SIP) in the Modem protocol stack. Understandably, in the Modem protocol stack, the SIP module is specifically located in the IMS protocol layer (which can also be called the IMS module). This embodiment takes the IMS module as an example.

[0296] In addition, according to the above description of the hardware structure of the terminal device, the ringback tone is specifically played through the audio module.

[0297] In addition, it should also be noted that for the network ringback tone, since the audio packet comes from the network side, after the calling terminal receives the audio packet, it needs to parse the audio packet so that the audio module can play the network sound according to the parsed audio data. Therefore, in the ringback tone playing method provided in the embodiments of the present application, a data processing module (which can be called: Data module) for processing the audio packet is also required.

[0298] Based on this, in the following scenario description, the functional modules included in the calling terminal mainly include the audio module, the data processing module, and the IMS module.

[0299] In addition, it should also be noted that in practical applications, the functions implemented by the data processing module can be integrated into the IMS module for implementation. This embodiment takes the functions of the data processing module being integrated into the IMS module as an example.

[0300] In addition, since the operations of the ringback tone playing process are mainly performed after the calling terminal receives the signaling indicating the ringback tone type sent by the network side, the object interacting with the calling terminal shown in the accompanying drawings takes the base station as an example, and other objects involved in the call service, such as the core network and the called terminal, are not shown.

[0301] Regarding the specific structure of the Modem protocol stack and the functions that can be implemented by each layer, specific reference can be made to the standard file of the Modem protocol stack, which will not be elaborated here.

[0302] In addition, it should also be noted that from the above description, in practical applications, due to the differences in the chips used by the terminals, there may be two specific situations, namely situation 1 and situation 2. For the convenience of description, the following scenarios all take situation 1 as an example.

[0303] In addition, it should be noted that in actual applications, before the calling terminal receives the 180 signaling, it may receive other signaling indicating the ringback tone type, such as receiving the 183 signaling. For the local ringback tone, the prerequisite for local playback is to receive the 180 signaling. For the convenience of description, this embodiment will be described from two major scenarios.

[0304] Scenario 1: Receive the 183 signaling first and then receive the 180 signaling

[0305] See Figures 7A to 7C , and Figures 8A to 8C , exemplarily, in some implementation manners, when the calling terminal needs to perform a call service with the called terminal, the IMS module in the calling terminal will initiate an INVITE signaling including the PEM information support. After the INVITE signaling is transmitted to the base station, the base station will forward it to the called terminal to be called.

[0306] For the specific description of including the information supporting PEM in the INVITE signaling, reference can be made to Figure 2 the embodiment shown for the INVITE signaling initiated by the first UE to the second UE, which will not be elaborated here.

[0307] Continue to refer to Figures 7A to 7C , and Figures 8A to 8C , exemplarily, after the calling terminal initiates the INVITE signaling and waits for the establishment of the media session with the called terminal, the base station will, according to the actual call service progress, feedback the session progress response of this call service to the IMS module of the calling terminal and give a ringback tone indication. In this way, the calling terminal will make a corresponding feedback according to the 183 signaling. For example, play the corresponding ringback tone to let the user know the current session progress, thereby improving the user experience.

[0308] From the above description of the signaling for determining the ringback tone played by the calling terminal, it can be seen that the 183 signaling can be used to indicate the ringback tone type. Therefore, after the IMS module of the calling terminal receives the 183 signaling sent by the base station, it can follow as Figure 7A , or Figure 7B , or Figure 7C , or Figure 8A , or Figure 8B , or Figure 8C shown ringback tone decision logic to determine the ringback tone type, and then play the ringback tone according to the determined ringback tone type.

[0309] It should be noted that for the case where the 183 signaling indicates that the ringback tone type is the local ringback tone, it is necessary to receive the 180 signaling to actually perform local playback. Therefore, in this embodiment, taking the ringback tone type indicated by the 183 signaling as the network ringback tone as an example, the processing flow of playing the ringback tone in this scenario will be described.

[0310] Through Figure 2 As can be seen from Table 1 shown in Figure 2 , when the 183 signaling does not include the PEM header field or includes the PEM header field with the value of Sendrecv / Recvonly, the indicated ringback tone type is the network ringback tone. In the scenario where the 183 signaling indicates the network ringback tone, it can be further divided into the scenario where the calling terminal starts playing the ringback tone before receiving the 180 signaling, and the scenario where the ringback tone is not played before receiving the 180 signaling.

[0311] Exemplarily, for the scenario where the calling terminal starts playing the ringback tone before receiving the 180 signaling, it can be as Figures 7A to 7C shown.

[0312] Refer to Figures 7A to 7C , exemplarily, after the calling terminal determines that the ringback tone type is network playback according to the 183 signaling, it can start a timer, such as T1 (the timing duration is 2 s). Then, within the timing duration corresponding to T1, it monitors whether it receives the audio packet corresponding to the network ringback tone (subsequently referred to as: RTP packet).

[0313] Continue to refer to Figures 7A to 7C , exemplarily, when the IMS module of the calling terminal receives the RTP packet (such as RTP packet 0) sent by the network side within the timing duration corresponding to T1, it will parse the RTP packet 0 to determine the audio coding file format of the RTP packet 0 from the parsed content, and then, according to the determined audio coding file format, obtain the value of the FT flag bit used to indicate whether the RTP packet 0 is a silent packet from the RTP packet 0.

[0314] Exemplarily, when the value of the FT flag bit obtained from the RTP packet 0 is the silent value set in the standard protocol of the audio coding file format, it is determined that the RTP packet 0 is a silent packet, otherwise it is determined that the RTP packet 0 is not a silent packet, that is, there is audio data that can play sound.

[0315] Continue to refer to Figures 7A to 7C , exemplarily, in this embodiment, it is taken that the RTP packet 0 received within the timing duration corresponding to T1 is not a silent packet as an example. For this situation, the IMS module can transmit the audio data parsed from the RTP packet 0 to the audio module, so that the audio module can perform network playback, that is, play the audio data corresponding to the network ringback tone.

[0316] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment, and does not serve as the only limitation to this embodiment.

[0317] For the scenario where the calling terminal starts playing the ringback tone before receiving the 180 signaling, it can be further divided intoFigures 7A to 7C Scenarios 1.1a, 1.1b, and 1.1c shown separately.

[0318] Scenario 1.1a:

[0319] Refer to Figure 7A , for example, after the calling terminal plays the network ringback tone, it receives a 180 signaling indicating that the ringback tone type is the local ringback tone, such as including a PEM header field with a value of Inactive. For this scenario, since the network ringback tone has already started playing before the 180 signaling and the sound has been played. To avoid affecting the user experience and prevent the ringback tone from suddenly switching from the called user's set ringtone to a "beep" sound, the IMS module can start another timer, such as T2 (with a timing duration of 2 s). Then, within the timing duration corresponding to T2, it monitors whether it receives the RTP packet corresponding to the network ringback tone.

[0320] Continue to refer to Figure 7A , for example, when the IMS module receives an RTP packet (such as RTP packet 1) sent by the network side within the timing duration corresponding to T2, it will parse RTP packet 1 to determine the audio coding file format of this RTP packet 1 from the parsed content, and then, based on the determined audio coding file format, obtain the value of the FT flag bit used to indicate whether RTP packet 1 is a silent packet from RTP packet 1.

[0321] For example, when the value of the FT flag bit obtained from RTP packet 1 is the silent value set in the standard protocol of this audio coding file format, it is determined that RTP packet 1 is a silent packet; otherwise, it is determined that RTP packet 1 is not a silent packet, that is, there is audio data that can play sound.

[0322] Continue to refer to Figure 7A , for example, in this embodiment, it is assumed that RTP packet 1 received within the timing duration corresponding to T2 is not a silent packet. For this case, the IMS module can transmit the audio data parsed from this RTP packet 1 to the audio module, so that the audio module can continue to play the network sound, that is, play the audio data corresponding to the network ringback tone.

[0323] Thus, in the process of waiting for the called terminal to answer the call, when the calling terminal first receives the 183 signaling indicating that the network plays a tone, and in the scenario where the audio packet sent by the network side has been received before receiving the 180 signaling, when the 180 signaling indicating local tone playback is received during the playback of the network ringback tone, the local ringback tone is not played first. Instead, within a set time, it is monitored whether the audio packet sent by the network side is still received. If the audio packet sent by the network side is received within the set time and the received audio packet is not a silent packet, the network ringback tone continues to be played, thus avoiding the sudden switch from playing the network ringback tone (the ringback tone set by the called party) to playing the local ringback tone ("beep" sound), which affects the user experience.

[0324] It should be understood that the above description is only an example listed for better understanding of the technical solution of this embodiment and does not serve as the sole limitation to this embodiment.

[0325] Scenario 1.1b:

[0326] Continue to refer to Figure 7B , exemplarily, in the case where the IMS module receives the RTP packet (such as RTP packet 2) sent by the network side within the timing duration corresponding to T2, the RTP packet 2 will be parsed to determine the audio coding file format of the RTP packet 2 from the parsed content. Then, according to the determined audio coding file format, the value of the FT flag bit used to indicate whether the RTP packet 2 is a silent packet is obtained from the RTP packet 2.

[0327] Continue to refer to Figure 7B , exemplarily, this embodiment takes the RTP packet 2 received within the timing duration corresponding to T2 as a silent packet. For this case, before the timing duration of T2 is reached, the IMS module can continue to monitor whether a new RTP packet is received.

[0328] Continue to refer to Figure 7B , exemplarily, in the case where the IMS module receives a new RTP packet (such as RTP packet 3) sent by the network side within the timing duration corresponding to T2, the RTP packet 3 will be parsed to determine the audio coding file format of the RTP packet 3 from the parsed content. Then, according to the determined audio coding file format, the value of the FT flag bit used to indicate whether the RTP packet 3 is a silent packet is obtained from the RTP packet 3.

[0329] Continue to refer to Figure 7B, Exemplarily, in this embodiment, it is assumed that the RTP packet 3 received within the timing duration corresponding to T2 is a silent packet. For this situation, before the timing duration of T2 is reached, the IMS module can continue to monitor whether new RTP packets are received. If the current timing duration corresponding to T2 is reached, the IMS module can change the ringback tone type from network playback to local playback. This embodiment takes the current reaching of the timing duration corresponding to T2 as an example.

[0330] Continue to refer to Figure 7B , Exemplarily, when the current reaches the timing duration corresponding to T2 and the IMS module does not receive an RTP packet that is not a silent packet, the IMS module can change the ringback tone type from the network ringback tone to the local ringback tone and instruct the audio module to perform local playback, that is, play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0331] Thus, it is possible to avoid the calling terminal entering the silent state (i.e., not playing sound) after briefly playing the network ringback tone during the process of waiting for the called terminal to answer the call. By changing to playing the local ringback tone after not receiving the RTP packet corresponding to the network ringback tone within the set time, the calling user can be informed that the current call is still waiting for the called party to answer instead of being interrupted.

[0332] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment and does not serve as the sole limitation of this embodiment.

[0333] Scenario 1.1c:

[0334] Continue to refer to Figure 7C , Exemplarily, as a possible scenario, after the calling terminal receives the 180 signaling indicating the local ringback tone and starts T2, it may not receive any RTP packets within the timing duration corresponding to T2. For this situation, after T2 times out, the IMS module of the calling terminal can change the ringback tone type from the network ringback tone to the local ringback tone and instruct the audio module to perform local playback, that is, play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0335] Thus, for this scenario, it is also possible to avoid the calling terminal entering the silent state (i.e., not playing sound) after briefly playing the network ringback tone during the process of waiting for the called terminal to answer the call. By changing to playing the local ringback tone after not receiving the RTP packet corresponding to the network ringback tone within the set time, the calling user can be informed that the current call is still waiting for the called party to answer instead of being interrupted.

[0336] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment and does not serve as the sole limitation of this embodiment.

[0337] In addition, it should be noted that Figures 8A to 8C The scenarios 1.1a, 1.1b, and 1.1c shown in Figures 8A to 8C are three mutually exclusive and independent scenarios. That is, only one of these three scenarios can occur at the same time.

[0338] Exemplarily, for the scenario where the calling terminal does not play the ringback tone before receiving the 180 signaling, it can be divided into Figures 8A to 8C The scenarios 1.2a, 1.2b, and 1.2c shown respectively.

[0339] Scenario 1.2a:

[0340] Refer to Figure 8A , exemplarily, after the calling terminal determines that the ringback tone type is network playback according to the 183 signaling, it can start a timer, such as T1 (the timing duration is 2 s). Then, within the corresponding timing duration of T1, it monitors whether it receives the RTP packet corresponding to the network ringback tone.

[0341] Continue to refer to Figure 8A , exemplarily, in the case where the IMS module of the calling terminal receives the RTP packet (such as RTP packet 4) sent by the network side within the corresponding timing duration of T1, it will parse RTP packet 4 to determine the audio coding file format of this RTP packet 4 from the parsed content, and then obtain the value of the FT flag bit used to indicate whether RTP packet 4 is a silent packet from RTP packet 4 according to the determined audio coding file format.

[0342] Continue to refer to Figure 8A , exemplarily, this embodiment takes the RTP packet 4 received within the corresponding timing duration of T1 as a silent packet as an example. For this case, if the timing duration of T1 has not been reached, the IMS module can continue to monitor whether it receives a new RTP packet.

[0343] Continue to refer to Figure 8A , exemplarily, in the case where the IMS module receives a new RTP packet (such as RTP packet 5) sent by the network side within the corresponding timing duration of T1, it will parse RTP packet 5 to determine the audio coding file format of this RTP packet 5 from the parsed content, and then obtain the value of the FT flag bit used to indicate whether RTP packet 5 is a silent packet from RTP packet 5 according to the determined audio coding file format.

[0344] Continue to refer to Figure 8A, Exemplarily, in this embodiment, it is assumed that the RTP packet 5 received within the timing duration corresponding to T1 is a silent packet. For this situation, before the timing duration of T1 is reached, the IMS module can continue to monitor whether new RTP packets are received. If the current timing duration corresponding to T1 is reached, the IMS module can change the ringback tone type from network playback to local playback. This embodiment takes the current reaching of the timing duration corresponding to T1 as an example.

[0345] Since local playback can only be performed after receiving the 180 signaling, the IMS module of the calling terminal needs to wait for the 180 signaling sent by the network side.

[0346] Continue to refer to Figure 8A , Exemplarily, when the IMS module receives the 180 signaling and the ringback tone type indicated by the 180 signaling is the local ringback tone, the IMS module can instruct the audio module to perform local playback, that is, play the audio data of the locally stored ringback tone, such as the "beep" sound.

[0347] It should be understood that the above description is only an example listed for better understanding of the technical solution of this embodiment and does not serve as the sole limitation of this embodiment.

[0348] Scenario 1.2b:

[0349] Continue to refer to Figure 8B , Exemplarily, as a possible scenario, after the calling terminal receives the 183 signaling indicating network playback and starts T1, it may not receive a single RTP packet within the timing duration corresponding to T1. For this situation, the ringback tone type can be changed to the local ringback tone, and after receiving the 180 signaling indicating the local ringback tone, directly trigger the audio module to perform local playback.

[0350] It should be understood that the above description is only an example listed for better understanding of the technical solution of this embodiment and does not serve as the sole limitation of this embodiment.

[0351] Scenario 1.2c:

[0352] Continue to refer to Figure 8C , Exemplarily, as another possible scenario, after the calling terminal receives the 183 signaling indicating network playback and starts T1, it may not receive a single RTP packet within the timing duration corresponding to T1. It is also possible that all the RTP packets received within the T1 timing duration are silent packets, such as Figure 8CBoth RTP packet 6 and RTP packet 7 received within the timing duration corresponding to T1 are silent packets. However, if the ringback tone type is changed to the local ringback tone and the received 180 signaling indicates that the ringback tone type is the network ringback tone, the IMS module can change the ringback tone type back to the network ringback tone again, start timer T2, and then, within the timing duration corresponding to T2, play the ringback tone using the processing logic of steps 203 to 204 as shown in Figure 6A The processing logic of steps 203 to 204 shown in

[0353] It should be noted that, in order to avoid getting into an endless loop of judgment, the calling terminal can be set to execute only once the judgment logic of steps 203 to 204 shown in Figure 6A after receiving the 180 signaling.

[0354] It should be understood that the above description is only an example listed for better understanding of the technical solution of this embodiment and does not serve as the sole limitation of this embodiment. In actual applications, the number of judgments can also be set according to service requirements.

[0355] In addition, it should also be noted that Figures 8A to 8C Scenario 1.2a, Scenario 1.2b, and Scenario 1.2c shown in

[0356] are three mutually exclusive and independent scenarios. That is, only one of these three scenarios can occur at the same moment.

[0357] Referring to Figure 9 , for example, the specific details of the calling terminal initiating the INVITE signaling and establishing a bearer with the base station can be referred to Figure 2 , or Figures 7A to 7C , or Figures 8A to 8C The corresponding parts of the embodiments shown, which will not be elaborated here.

[0358] Continuing to refer to Figure 9 , for example, after the calling terminal establishes a bearer with the base station and does not receive the 183 signaling but directly receives the 180 signaling. For this situation, the IMS module of the calling terminal can determine the ringback tone type according to the 180 signaling. The specific determination method can be referred to Figure 2 The corresponding parts of the embodiments shown in Table 2 in

[0359] Continuing to refer to Figure 9 , for example, taking the 180 signaling indicating the network ringback tone as an example, for this situation, in one possible implementation, it can be divided into Scenario 2a, Scenario 2b, and Scenario 2c. The following will explain from these 3 scenarios respectively.

[0360] Scenario 2a:

[0361] See Figure 9 , exemplarily, the IMS module starts a timer, such as T3 (with a timing duration of 2 s). Then, within the corresponding timing duration of T3, it monitors whether it receives the RTP packet corresponding to the network ringback tone.

[0362] Continue to see Figure 9 , exemplarily, when the IMS module of the calling terminal receives the RTP packet (such as RTP packet 8) sent by the network side within the corresponding timing duration of T3, it will parse RTP packet 8 to determine the audio coding file format of the RTP packet 8 from the parsed content. Furthermore, according to the determined audio coding file format, it obtains the value of the FT flag bit used to indicate whether RTP packet 8 is a silent packet from RTP packet 8.

[0363] Continue to see Figure 9 , exemplarily, this embodiment takes the case where the RTP packet 8 received within the corresponding timing duration of T3 is a silent packet as an example. For this situation, before the timing duration of T3 is reached, the IMS module can continue to monitor whether it receives a new RTP packet.

[0364] Continue to see Figure 9 , exemplarily, when the IMS module receives a new RTP packet (such as RTP packet 9) sent by the network side within the corresponding timing duration of T3, it will parse RTP packet 9 to determine the audio coding file format of the RTP packet 9 from the parsed content. Furthermore, according to the determined audio coding file format, it obtains the value of the FT flag bit used to indicate whether RTP packet 9 is a silent packet from RTP packet 9.

[0365] Continue to see Figure 9 , exemplarily, this embodiment takes the case where the RTP packet 9 received within the corresponding timing duration of T3 is a silent packet as an example. For this situation, before the timing duration of T3 is reached, the IMS module can continue to monitor whether it receives a new RTP packet. If the current timing duration of T3 is reached, the IMS module can change the ringback tone type from network playback to local playback. This embodiment takes the current reaching the corresponding timing duration of T3 as an example.

[0366] Continue to see Figure 9 , exemplarily, when the current reaches the corresponding timing duration of T3 and the IMS module does not receive an RTP packet that is not a silent packet, the IMS module can change the ringback tone type from network ringback tone to local ringback tone and instruct the audio module to perform local playback, that is, play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0367] Thus, when the ringback tone type determined by the 180 signaling at the calling terminal is the network ringback tone, the calling terminal can be prevented from blindly waiting for the RTP packet on the network side, which may cause the calling terminal to be in a mute state during the process of the called terminal answering the call, that is, there is no sound of the ringback tone. By playing the local ringback tone after the RTP packet corresponding to the network ringback tone is not received within the set time, the calling user can be informed that the current call is still waiting for the called party to answer instead of being interrupted.

[0368] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment and does not serve as the sole limitation of this embodiment.

[0369] Scenario 2b:

[0370] Continue to refer to Figure 9 Exemplarily, as a possible scenario, after the calling terminal receives the 180 signaling indicating the network ringback tone and starts T3, it may not receive a single RTP packet within the timing duration corresponding to T3. For this situation, after T3 times out, the IMS module of the calling terminal can change the ringback tone type from the network ringback tone to the local ringback tone and instruct the audio module to play the local tone, that is, play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0371] Thus, for this scenario, it can also prevent the calling terminal from blindly waiting for the RTP packet on the network side when the ringback tone type determined by the 180 signaling is the network ringback tone, which may cause the calling terminal to be in a mute state during the process of the called terminal answering the call, that is, there is no sound of the ringback tone. By playing the local ringback tone after the RTP packet corresponding to the network ringback tone is not received within the set time, the calling user can be informed that the current call is still waiting for the called party to answer instead of being interrupted.

[0372] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment and does not serve as the sole limitation of this embodiment.

[0373] Scenario 2c:

[0374] Continue to refer to Figure 9 Exemplarily, in another possible implementation, when the IMS module of the calling terminal receives the RTP packet (such as RTP packet 10) sent by the network side within the timing duration corresponding to T3, it will parse the RTP packet 10 to determine the audio coding file format of the RTP packet 10 from the parsed content, and then obtain the value of the FT flag bit indicating whether the RTP packet 10 is a mute packet from the RTP packet 10 according to the determined audio coding file format.

[0375] Continue to refer to Figure 9, Exemplarily, in this embodiment, it is taken as an example that the RTP packet 10 received within the timing duration corresponding to T3 is not a silent packet. For this situation, the IMS module can transmit the audio data parsed from the RTP packet 10 to the audio module, so that the audio module can continue to play the network sound, that is, play the audio data corresponding to the network ringback tone.

[0376] It should be understood that the above description is only an example listed for better understanding the technical solution of this embodiment, and does not serve as the sole limitation of this embodiment.

[0377] In addition, it should be noted that the timing durations corresponding to the above-mentioned timers can be the same or different, and this application does not make any restrictions on this.

[0378] In addition, it should also be noted that Figure 9 The scenarios 2a, 2b, and 2c shown in are three mutually exclusive and independent scenarios. That is, only one of these three scenarios can occur at the same moment.

[0379] In addition, it should be understood that in order for the terminal device to implement the above functions, it includes the corresponding hardware and / or software modules for executing each function. Combining the algorithm steps of each example described in the embodiments disclosed in this article, this application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to exceed the scope of this application.

[0380] In addition, it should be noted that in the actual application scenarios, the above-mentioned ringback tone playing methods provided by each of the above embodiments implemented by the terminal device can also be executed by a chip system included in the terminal device. As Figure 10 shown, the chip system 1000 may include at least one processor (such as an application processor AP and a modem Modem) 1001 and at least one interface circuit 1002. The processor 1001 and the interface circuit 1002 can be interconnected by lines. For example, the interface circuit 1002 can be used to receive signals from other devices (such as the memory of the terminal device). For another example, the interface circuit 1002 can be used to send signals to other devices (such as the processor 1001). Exemplarily, the interface circuit 1002 can read the instructions stored in the memory and send the instructions to the processor 1001. When the instructions are executed by the processor 1001, the terminal device can execute each step in the above embodiments. Of course, the chip system can also include other discrete devices, and this application embodiment does not make specific limitations on this.

[0381] In addition, an embodiment of the present application further provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are run on a terminal device, the terminal device is caused to execute the above-related method steps to implement the ringback tone playing method in the above embodiment.

[0382] In addition, an embodiment of the present application further provides a computer program product. When the computer program product is run on a terminal device, the terminal device is caused to execute the above-related steps to implement the ringback tone playing method in the above embodiment.

[0383] In addition, an embodiment of the present application further provides a system-on-chip (SoC), which can also be referred to as a system-on-chip (System on Chip, SoC).

[0384] Exemplarily, Figure 11 shows a schematic structural diagram of an SoC. As Figure 11 shown, the SoC includes the capabilities of an AP and a Modem. Among them, the AP is used to process the internal data of the terminal device and does not include the part for external communication. The Modem is used to process the part for external communication, including handling services such as making calls, sending text messages, and accessing the Internet.

[0385] Specifically in the embodiment of the present application, the method of playing the ringback tone is processed by the Modem.

[0386] Continuing to refer to Figure 11 , exemplarily, a physical channel such as a shared memory or a bus is established between the AP and the Modem to implement data transmission between the AP and the Modem, such as the transmission of data such as call content and text message content.

[0387] In Figure 11 's example, a Modem is integrated in the SoC. However, in actual implementation, the Modem can also exist in the form of an independent chip and be soldered to the main board of the terminal device together with the SoC. In the following text, mainly in the form shown in Figure 11 , that is, taking the integration of the Modem in the SoC as an example for illustration.

[0388] Continuing to refer to Figure 11 , exemplarily, the Modem may include a cellular protocol stack and a cellular physical layer. Among them, the cellular physical layer in the Modem can communicate with a radio frequency (RF) component.

[0389] Understandably, the RF component is mainly used for processing the received signal and the transmitted signal in the wireless communication process.

[0390] Exemplarily, referring to Figure 11, the RF component communicates with the cellular physical layer in the Modem, and can be used to receive the cellular baseband digital signal, perform digital-to-analog conversion processing on it and transmit it through the antenna, and perform analog-to-digital conversion processing on the radio electromagnetic wave signal received by the antenna and send it to the cellular baseband.

[0391] It should be understood that the above description is only an example listed for better understanding of the technical solution of this embodiment, and does not serve as the sole limitation of this embodiment.

[0392] In addition, through the above description, it can be seen that the terminal device, computer-readable storage medium, computer program product or chip provided by the embodiments of the present application 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 elaborated here.

[0393] To illustrate the beneficial effects of the ringback tone playing method provided by the embodiments of the present application in detail, the following is a comparison with the related art.

[0394] Specifically, according to the regulations of the China Telecom White Paper (hereinafter referred to as: White Paper), for an ordinary normal IMS domain call, when the called-side network element returns an 18* signaling (such as 183 signaling, 180 signaling, etc.) and the returned 18* signaling does not carry a PEM header field, specifically, the calling-side terminal provides the ringback tone, that is, plays the local ringback tone; when the called-side network element returns an 18* signaling and the returned 18* signaling includes a PEM header and SDP, the backward network element provides the ringback tone, that is, plays the network ringback tone.

[0395] In addition, according to the regulations of the White Paper, for an ordinary normal IMS domain call, during the process of receiving the remote network media stream, that is, the audio packet corresponding to the network ringback tone, if an 18* signaling with a P-Early-Media information with a value of "Inactive" is received, the calling terminal starts to play the local ringback tone. However, in the ringback tone playing method provided by the embodiments of the present application, during the process of receiving the remote network media stream, it will be judged whether the audio packets received within the set time are all silent packets. If they are all silent packets, the local ringback tone will be switched to play. On the contrary, if there are non-silent packets, that is, audio packets that can play sounds, among the audio packets received within the set time, the network ringback tone will be preferentially played, rather than immediately switching to play the local ringback tone according to the regulations of the White Paper when receiving a signaling indicating the local ringback tone.

[0396] In addition, it should be noted that the ringback tone playing method provided by the embodiments of the present application is particularly applicable to the scenario where the calling terminal has carried out number portability. That is, all the technical problems solved by the present application mainly occur in the specific network environment of number portability. And, in this scenario, the probability that the received audio packets of the network ringback tone are all silent packets is relatively small. The ringback tone playing method provided by the embodiments of the present application can effectively solve the above-mentioned problems that occur occasionally in this specific scenario, making the playing of the ringback tone more stable and the user experience better.

[0397] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for playing a ringback tone, characterized in that Applied to a first terminal, the method includes: Sending an INVITE signaling for a call request, where the INVITE signaling includes P-Early-Media information; After receiving a signaling indicating a network ringback tone, if all the received audio packets are silent packets within a first duration, playing a local ringback tone.

2. The method according to claim 1, wherein The P-Early-Media information included in the INVITE signaling is P-Early-Media: supported.

3. The method according to claim 1, wherein The playing the local ringback tone after receiving a signaling indicating a network ringback tone, if all the received audio packets are silent packets within a first duration, includes: After receiving a signaling indicating a network ringback tone, starting to count time, and the counted time duration is the first duration; If an audio packet sent by the network side is received within the first duration and the length of all the received audio packets is less than or equal to a preset length, playing the local ringback tone.

4. The method according to claim 3, characterized in that, The method further includes: If no audio packet sent by the network side is received within the first duration, playing the local ringback tone.

5. The method according to claim 3, characterized in that, The preset length is 19.

6. The method according to claim 1, characterized in that The playing the local ringback tone after receiving a signaling indicating a network ringback tone, if all the received audio packets are silent packets within a first duration, includes: After receiving a signaling indicating a network ringback tone, starting to count time, and the counted time duration is the first duration; If an audio packet sent by the network side is received within the first duration and the packet type of all the received audio packets is a preset packet type, playing the local ringback tone.

7. The method according to claim 6, wherein The preset packet type is SID (COMFORT NOISEFRAME).

8. The method according to claim 1, characterized in that The signaling indicating the network ringback tone includes: a first signaling and / or a second signaling. The first signaling is the first signaling sent by the network side indicating the ringback tone type after the INVITE signaling is initiated, and the second signaling is the last signaling sent by the network side indicating the ringback tone type.

9. The method according to claim 8, wherein The first signaling is a 183 signaling, and the second signaling is a 180 signaling.

10. The method according to claim 8, characterized in that If the first signaling includes a PEM header field and the value included in the PEM header field is a first value, the first signaling is a signaling indicating the local ringback tone; If the first signaling includes the PEM header field and the value included in the PEM header field is a second value, the first signaling is a signaling indicating the network ringback tone.

11. The method according to claim 8, characterized in that If the second signaling includes a PEM header field and the value included in the PEM header field is a first value, the second signaling is a signaling indicating the local ringback tone; If the second signaling includes the PEM header field and the value included in the PEM header field is a second value, the second signaling is a signaling indicating the network ringback tone.

12. The method according to claim 10 or 11, characterized in that, The first value indicates that the early media function is not supported, and the second value indicates that the audio packet is allowed to be received.

13. The method according to claim 12, characterized in that, The first value is Inactive, and the second value is Sendrecv or Recvonly.

14. The method according to claim 13, wherein When the first signaling includes a value that is the first value, the PEM header field is P-Early-Media: Inactive; when the value included in the first signaling is the second value, the PEM header field is P-Early-Media: Sendrecv or P-Early-Media: Recvonly.

15. The method according to claim 8, wherein The method further includes: Receiving the first signaling, where the first signaling is a signaling indicating the network ringback tone; Receiving the second signaling within the first duration, and when the second signaling includes a PEM header field and the value included in the PEM header field is the first value, the second signaling is a signaling indicating the local ringback tone; Playing the local ringback tone.

16. The method according to claim 15, wherein The method further includes: Receiving the second signaling within the first duration, and when the second signaling includes the PEM header field and the value included in the PEM header field is the second value, the second signaling is a signaling indicating the network ringback tone; Playing the local ringback tone when all the audio packets received within the second duration are silent packets.

17. The method according to claim 16, wherein The method further includes: Playing the network ringback tone when there are non-silent packets among the audio packets received within the second duration.

18. The method according to claim 1, wherein The method further includes: After receiving the signaling indicating the network ringback tone, playing the network ringback tone when there are non-silent packets among the audio packets received within the first duration.

19. The method according to claim 18, wherein The method further includes: Receiving a second signaling during the playing of the network ringback tone, where the second signaling is the last signaling sent from the network side indicating the type of ringback tone; When the second signaling includes a PEM header field and the value included in the PEM header field is the first value, the second signaling is a signaling indicating the local ringback tone; Playing the local ringback tone when all the audio packets received within the third duration are silent packets or no audio packets are received; Continuing to play the network ringback tone when there are non-silent packets among the audio packets received within the third duration.

20. The method according to claim 19, wherein The method further includes: When the second signaling includes the PEM header field and the value included in the PEM header field is the second value, the second signaling is a signaling indicating the network ringback tone; Playing the local ringback tone when all the audio packets received within the fourth duration are silent packets or no audio packets are received; Continuing to play the network ringback tone when there are non-silent packets among the audio packets received within the fourth duration.

21. The method according to claim 19, characterized in that, The method further includes: When the second signaling does not include the PEM header field, playing the ringback tone according to the type of ringback tone indicated by the first signaling.

22. A terminal device, characterized in that, The terminal device includes: a memory and a processor, the memory and the processor being coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the terminal device is caused to execute the ringback tone playing method according to any one of claims 1 to 21.

23. A computer-readable storage medium, characterized in that, It includes a computer program, and when the computer program runs on the terminal device, the terminal device is caused to execute the ringback tone playing method according to any one of claims 1 to 21.

24. A chip system, characterized in that, It includes: A processor, configured to call and run a computer program from a memory, so that the terminal device installed with the chip system executes the ringback tone playing method according to any one of claims 1 to 21.

Images