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

Ringback tone playing method, device, storage medium and chip system

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on December 29, 2023, with application number 202311864534.4 and invention name “Ringback tone playback method, device, storage medium and chip system”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] 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

[0003] IMS (IP Multimedia Subsystem), a concept proposed by 3GPP, is a universal network architecture for delivering multimedia services over IP-based networks. It provides converged multimedia services and internet applications to users using different access methods. VoLTE (Voice-over-LTE) and VoNR (Voice over New Radio) are currently common voice services that utilize IP data transmission technologies, i.e., IMS-based voice services.

[0004] Taking the VoLTE voice service scenario 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 indicating that the other party is ringing will be displayed on the calling terminal's user interface, and a ringback tone will be played.

[0005] 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, thus affecting the user experience.

[0006] Summary of the Invention

[0007] The present application provides a ringback tone playback method, device, storage medium, and chip system. In this method, in a scenario where the ringback tone is provided by the network side, the calling terminal monitors whether an audio packet provided by the network side is received within a specified time, and determines whether the data in the audio packet is entirely silent frames, and then decides whether to continue playing the network ringback tone or switch to playing the local ringback tone. This ensures that the calling terminal can play the ringback tone in a timely manner and provide a prompt to the user.

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

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

[0010] It should be understood that in actual applications, any terminal can serve as both a calling terminal and a called terminal, depending on whether the current call service is initiated by it. That is, if the call service is initiated by it, the terminal device will serve as the calling terminal, otherwise it will be the called terminal.

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

[0012] Optionally, the first duration, for example, 1 second or 2 seconds, can be set according to service needs, chip requirements used by the first terminal, and the like.

[0013] Optionally, the network ringback tone refers to the ringback tone whose audio data is provided by the network side. The audio data, that is, the audio data in the audio packet, is usually the ringback tone set by the called party when activating the ringback tone service.

[0014] Optionally, the local ringback tone refers to a ringback tone to be played whose audio data is provided by the first terminal itself.

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

[0016] Optionally, the audio data is, for example, a “beep” sound played in the calling terminal when the calling terminal is waiting for the called terminal to answer the call.

[0017] Optionally, the audio data corresponding to the local ringback tone may be stored in a local storage medium of the first terminal.

[0018] Optionally, the local storage medium of the first terminal may be, for example, an internal memory of the first terminal. In this way, when switching to a local ringback tone, audio data can be directly read from the local storage medium for playback.

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

[0020] 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; wherein, the first base station is used to send an 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.

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

[0022] 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 the first terminal to receive all silent packets within the first time, the ringback tone type is directly modified to a local ringback tone, and then the local ringback tone is played, thereby ensuring that the first terminal can play the ringback tone in time and prompt the user.

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

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

[0025] Optionally, the start timing is, for example, immediately after receiving a signaling indicating a network ringback tone.

[0026] Optionally, the timing may also be started a certain time after receiving the signaling indicating the network ringback tone.

[0027] Optionally, the preset length may be 15 to 25.

[0028] It is understandable that under normal circumstances, the length of the 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. In order to ensure that the first terminal can play the ringback tone, you can choose to play the local ringback tone.

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

[0030] According to the first aspect, or any implementation of the first aspect above, after receiving signaling indicating a network ringback tone, if all received audio packets are silent packets within a first time period, playing a local ringback tone, including: after receiving signaling indicating a network ringback tone, starting timing, the timing duration is the first time period; receiving audio packets sent from the network side within the first time period, and if the value of the frame type flag in all received audio packets is a preset silent value, playing the local ringback tone.

[0031] Therefore, by judging whether the value of the frame type flag in the audio packet is the preset silent value, it is possible to quickly determine whether the audio packet is a silent packet based on the value of the frame type flag, that is, to determine whether all the audio data in the audio packet are silent frames, and then promptly switch the ringback tone type to the local ringback tone and play the local ringback tone, so that the first terminal can play the ringback tone in time.

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

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

[0034] According to the first aspect, or any implementation of the first aspect above, after receiving signaling indicating a network ringback tone, if all received audio packets are silent packets within a first time period, playing a local ringback tone, including: after receiving signaling indicating a network ringback tone, starting timing, the timing duration is the first time period; receiving audio packets sent from the network side within the first time period, and if the packet type of all received audio packets is a preset packet type, playing the local ringback tone.

[0035] Therefore, whether the received audio packet is a silence packet can also be quickly determined according to the packet type of the audio packet.

[0036] According to the first aspect, or any implementation of the first aspect, the preset packet type is SID (COMFORT NOISE FRAME), that is, the audio packet includes the SID (COMFORT NOISE FRAME).

[0037] According to the first aspect, or any implementation of the first aspect above, if no audio packet sent by the network side is received within the first duration, a local ringback tone is played.

[0038] In this way, it can be ensured that the first terminal can always play the ringback tone with sound.

[0039] According to the first aspect, or any implementation method of the first aspect above, the signaling indicating the network ringback tone includes: a first signaling and / or a second signaling, the first signaling being the first signaling indicating the ringback tone type sent by the network side after initiating the INVITE signaling, and the second signaling being the last signaling indicating the ringback tone type sent by the network side.

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

[0041] Optionally, when the 183 signaling is not received, the first signaling may also be the Update signaling.

[0042] According to the first aspect, or any implementation of the first aspect above, when 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 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 a second value, the first signaling is signaling indicating a network ringback tone.

[0043] Therefore, during the media negotiation process, that is, before the second signaling is received indicating that the second terminal has started ringing, the current ringback tone type of the first terminal is determined based on the first signaling received during the media negotiation process that can indicate the ringback tone type, so that the ringback tone type 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.

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

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

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

[0047] For example, if the chip specification used does not include the PEM header field, the ringback tone type is a local ringback tone. For such a first terminal, the ringback tone type can be determined as a local ringback tone in this scenario, that is, the first signaling in this scenario is a signaling indicating a local ringback tone.

[0048] According to the first aspect, or any implementation of the first aspect above, when 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 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 a second value, the second signaling is signaling indicating a network ringback tone.

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

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

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

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

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

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

[0055] According to the first aspect, or any implementation manner of the first aspect above, when the value included in the first signaling 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.

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

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

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

[0059] Optionally, no audio packet sent by the network may be received within the first time period. Therefore, if the first signaling instructs network playback, but the second signaling instructs local playback before receiving the audio packet sent by the network, the audio data of the local ringback tone is played directly according to the ringback tone type indicated by the second signaling, thereby ensuring that the ringback tone played by the first terminal does not change midway, thereby ensuring user experience.

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

[0061] The second duration, such as 1 second or 2 seconds, can be set according to service needs, chip requirements used by the first terminal, and the like.

[0062] Therefore, when resource preview is not supported, that is, in the scenario where the first signaling is not received before the second signaling, the ringback tone type is determined directly based on the second signaling, and when the ringback tone type is determined to be a network ringback tone, the judgment conditions of whether the audio packets sent by the network side are received within the set monitoring time and whether the received audio packets are all silent packets are used to decide whether the ringback tone type needs to be changed to a local ringback tone to ensure that the first terminal can play the ringback tone in time.

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

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

[0065] According to the first aspect, or any implementation of the first aspect above, after receiving signaling indicating a network ringback tone, if a non-silent packet is included in the received audio packets within a first duration, the network ringback tone is played.

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

[0067] In this way, in the scenario where the network is instructed to play audio, as long as there is audio with sound (non-silent packet) in the audio packet received within the set time (the first time), the network ringback tone will be used as the basis, and the audio data in the received audio packet will be played first, ensuring that the ringback tone set by the called user can be heard by the calling user.

[0068] According to the first aspect, or any implementation of the first aspect above, during the process of playing the network ringback tone, a second signaling is received, and the second signaling is the last signaling indicating the ringback tone type sent by the network side; 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; within a third time period, if all received audio packets are silent packets, or if no audio packets are received, the local ringback tone is played; within the third time period, if there are non-silent packets among the received audio packets, the network ringback tone continues to be played.

[0069] The third duration, such as 1 second or 2 seconds, can be set according to business needs, chip requirements used by the first terminal, and the like.

[0070] Therefore, if the network ringback tone has already started playing before receiving the 180 signaling, but the received 180 signaling indicates a local ringback tone, the local ringback tone will not be played first, but the third time duration will be waited. If a non-silent audio packet is received within the third time duration, the network ringback tone will continue to play, without interrupting the network ringback tone and ensuring user experience.

[0071] Otherwise, the local ringback tone is played, thereby ensuring that the first terminal can always play the ringback tone with sound.

[0072] According to the first aspect, or any implementation of the first aspect above, 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; within a fourth time period, if all received audio packets are silent packets, or if no audio packets are received, a local ringback tone is played; within the fourth time period, if there are non-silent packets among the received audio packets, the network ringback tone continues to be played.

[0073] The fourth duration, such as 1 second or 2 seconds, can be set according to business needs, chip requirements used by the first terminal, and the like.

[0074] Therefore, in order to avoid a long wait for the audio packet from the network side or the played audio packet being a silent packet, which results in no sound in the first terminal and affects the user experience, in the case where the second signaling still instructs the first terminal to play the network sound, the judgment condition of whether the audio packet sent by the network side is received within the set monitoring time and whether the received audio packets are all silent packets is still used to decide whether the ringback tone type needs to be changed to a local ringback tone to ensure that the first terminal can play the ringback tone in time.

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

[0076] Therefore, for the scenario where resource reservation is supported, that is, 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 conditions for triggering playback are maintained, thereby ensuring that the first terminal can always have a ringback tone to play, ensuring user experience.

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

[0078] The third signaling is, for example, a call acceptance (200 OK) signaling for answering a call.

[0079] This scenario mainly applies to the case where the chip used by the first terminal does not include the PEM header field by default, and the ringback tone type is a local ringback tone, such as Case 2 in the following embodiment.

[0080] Therefore, before the 200OK signaling, the first terminal continuously monitors whether the network side sends a non-silent audio packet, and after receiving the non-silent audio packet, it gives priority to playing the network ringback tone, thereby ensuring the success rate of playing the customized ringback tone and improving the user experience.

[0081] According to the first aspect, or any implementation of the first aspect above, the third signaling is signaling for making a final response to the INVITE signaling.

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

[0083] It can be understood that the 200 OK signaling, i.e., the call acceptance signaling, is the final response to the call request (INVITE).

[0084] 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 storing program instructions, which, when executed by the processor, cause the terminal device to execute instructions of the method of the first aspect or any possible implementation of the first aspect.

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

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

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

[0088] FIG1 is a schematic diagram illustrating a communication environment in which a terminal device implements a call service;

[0089] FIG2 is a schematic diagram illustrating an exemplary call processing process;

[0090] FIG3 is a schematic diagram exemplarily illustrating a method of playing back a ring tone;

[0091] FIG4 is a schematic diagram showing an exemplary embodiment of a calling terminal playing a ringback tone when the called terminal is ringing;

[0092] FIG5 is a schematic diagram showing an exemplary hardware structure of a terminal device;

[0093] FIG6A is a schematic diagram illustrating a flow chart of a ringback tone playing method provided in an embodiment of the present application;

[0094] FIG6B is a flow chart illustrating another method for playing a ringback tone according to an embodiment of the present application;

[0095] FIG7A is a schematic diagram illustrating an exemplary scenario in which a ringback tone playing method is applicable;

[0096] FIG7B is a schematic diagram illustrating another scenario in which a ringback tone playing method is applicable;

[0097] FIG7C is a schematic diagram illustrating another scenario in which a ringback tone playing method is applicable;

[0098] FIG8A is a schematic diagram illustrating another scenario in which a ringback tone playing method is applicable;

[0099] FIG8B is a schematic diagram illustrating another scenario in which a ringback tone playing method is applicable;

[0100] FIG8C is a schematic diagram illustrating another scenario in which a ringback tone playing method is applicable;

[0101] FIG9 is a schematic diagram illustrating another scenario in which a ringback tone playing method is applicable;

[0102] FIG10 is a schematic structural diagram of an exemplary chip system;

[0103] FIG11 is a schematic diagram showing the structure of a system-on-chip (SoC) chip. DETAILED DESCRIPTION

[0104] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0105] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

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

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

[0108] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0109] In the description of the embodiments of the present application, the names of the various instructions and / or commands and / or instructions and / or information and / or signaling and / or messages are only examples. In the specific implementation process, they can also be replaced with other names according to the actual scenario. The glossary of names and terms in the actual implementation can also refer to the explanation in the third generation partnership project (3GPP) standard protocol. The capitalization and spaces in the embodiments of the present application are only examples, and the specific provisions in the standard protocol shall prevail.

[0110] In a communication system, a user equipment (UE) can make calls and receive calls by communicating with the current access network. The communication entities of the current access network may include radio access network (RAN) devices such as 3G base stations, 4G base stations, 5G base stations, and 6G base stations, as well as core network devices related to the radio access network devices. In the embodiment of the present application, the core network device may include a device in the core network, or the core network device may include multiple devices in the core network. The signaling transmission interaction process, voice bearer establishment process, etc. involved in the embodiment 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 ease of understanding, they will not be described in detail.

[0111] It should be noted that the core network equipment and the radio access network equipment can be independent and different physical devices, or the core network equipment functions and the radio access network equipment logical functions can be integrated into the same physical device, or a single physical device can integrate some core network equipment functions and some radio access network equipment functions. Terminal equipment can be fixed or mobile.

[0112] In order to better understand the technical solutions provided by the embodiments of the present application, the following describes the communication environments to which the technical solutions provided by the embodiments of the present application can be applied.

[0113] First, it should be noted that the embodiments of the present application can be applied to third-generation mobile communication technology (3G) networks, fourth-generation mobile communication technology (4G) networks, fifth-generation mobile communication technology (5G) networks, or future next-generation mobile communication technology networks. For ease of description, the following description uses the 4G network architecture as an example.

[0114] 1 , a first UE and a second UE establishing a media session need to access a radio access network through the base stations of their respective cells. For example, the first UE accesses the radio access network through a first base station, and the second UE accesses the radio access network through a second base station.

[0115] Continuing with Figure 1, illustratively, when the calling party's first UE calls the called party's second UE, that is, when the first UE initiates a call request to the second UE, the first UE transmits the call request to the calling IMS domain via the wireless access network accessed by the first base station. The calling IMS domain processes the call request initiated by the first UE and forwards the processed call request to the called IMS domain. The called IMS domain processes the call request processed by the calling IMS domain and sends the call request to the second UE via the wireless access network accessed by the second base station.

[0116] Continuing to refer to Figure 1, exemplarily, in 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, etc., will be transmitted to the called IMS domain through the wireless access network accessed by the second base station, and then transmitted to the calling IMS domain via the called IMS domain, and then sent to the wireless access network accessed by the first base station via the calling IMS domain, and finally sent to the first UE by the wireless access network accessed by the first base station.

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

[0118] Regarding the above-mentioned IMS, namely IP Multimedia Subsystem (IP Multimedia Subsystem), it is a concept proposed by 3GPP. It is a general network architecture that provides multimedia services on an IP-based network. It can provide integrated multimedia services and Internet applications for users using different access methods. Among them, VoLTE and VoNR are currently common voice services that use IP data transmission technology, that is, IMS-based voice services. For the sake of convenience, the call service initiated by the calling party to the called party in each embodiment of the present application takes the voice service scenario of VoLTE as an example.

[0119] In some implementations, IMS may be referred to as an IMS network. The IMS network may include a calling IMS domain (as shown in FIG1 ) and a called IMS domain (as shown in FIG1 ). Both the calling IMS domain and the called IMS domain may include an IMS domain core network and an evolved packet core network (EPC). The IMS domain core network may 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).

[0120] Since the above network elements are corresponding network elements in the wireless communication network in the prior art, this embodiment does not describe in detail the interactions and services processed between the above network elements. For specific implementation details, please refer to the standard protocol.

[0121] From the above description of the media session establishment between the first and second UEs in the communication environment shown in Figure 1 , it can be seen that during the process of establishing the media session between the first and second UEs, the radio access network (the first base station and the second base station) and the IMS network (the calling and called IMS domains) are primarily used to transmit requests, responses, signaling, etc. Ignoring the radio access network and the IMS network, the call service processing flow between the calling and called parties can be shown in Figure 2 .

[0122] 2 , illustratively, 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 invitation request to the second UE (called party), specifically through INVITE signaling (hereinafter referred to as: INVITE signaling).

[0123] Understandably, the ultimate goal of a call is for two users to have a conversation. The media generated by the conversation between users is generally referred to as regular media. However, in actual applications, after the first UE initiates a call to the second UE, the conversation between the two users does not begin immediately (or may not even begin at all because the call is unsuccessful). The waiting time is generally several seconds to tens of seconds, which depends entirely on when the second UE responds (answers the call). Before the second UE responds, media flows may also be generated between the first UE and the network. Different from regular media, the media generated during this period (before the second UE responds) can be called early media.

[0124] The most typical example of early media is the ringback tone (RBT) or callback tone (CBT). This ringback tone is played on the calling terminal when the calling terminal calls the called terminal. The rules for playing ringback tones vary across different mobile communications domains. For example, in the circuit switching (CS) domain, ringback tones are typically local to the calling terminal. In the packet switching (PS) domain, ringback tones can be provided by the network.

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

[0126] For ease of explanation, in this embodiment, the ringback tone provided by the network side is called the network ringback tone, and the playing of the network ringback tone is called network playback; the ringback tone provided locally (usually a "beep" sound) is called the local ringback tone, and the playing of the local ringback tone is called local playback.

[0127] Understandably, in some implementations, upon receiving signaling indicating the ringback tone type, the first UE will update the call status to the ringback tone status and play the ringback tone according to the ringback tone type indicated by the signaling. For local ringback tones, the first UE needs to play the local ringback tone after receiving the 180Ringing signal. For network ringback tones, the 180Ringing signal is not required. Upon receiving the audio packet sent by the network, the first UE can begin playing the audio data in the audio packet, thereby performing network playback.

[0128] Therefore, in order for the first UE to play a ringback tone while waiting for the second UE to answer the call, the first UE needs to include information about supporting early media when sending INVITE signaling to the second UE. In this way, if the second UE has set a network ringback tone (color ring tone, such as music, songs, stories, character dialogues, etc.), the network side can send the audio package 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.

[0129] Regarding the information about 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 to supported, that is, configuring "P-Early-Media: supported".

[0130] 2 , illustratively, after the second UE receives the INVITE signaling transmitted by the first UE through the corresponding radio access network and IMS network, it may make a 100 Trying, ie, a trial call, to the first UE during the media negotiation process.

[0131] It should be noted that during the media negotiation process, the 100 Trying signal issued by the second UE is actually sent to the core network. After the call attempt between the second UE and the core network is successful, the core network then issues a 100 Trying signal to the first UE. Because Figure 2 omits the radio access network and IMS network, the 100 Trying signal shown in Figure 2 is directed directly from the second UE to the first UE.

[0132] Continuing to refer to FIG2 , illustratively, 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 a Quality of Service Class Identifier (QCI) value of 1, that is, the QCI of the created bearer is 1.

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

[0134] Since the radio access network and the IMS network are omitted in FIG2 , the established bearer shown in FIG2 is directly directed to the second UE and the first UE.

[0135] Understandably, a bearer refers to the network connection and underlying network resources established between two network nodes, such as between a first UE and the core network, or between a second UE and the core network, for the purpose of transmitting data or signaling. In other words, after a bearer is 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 exchange data and signaling based on their respective bearers.

[0136] 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 details, please refer to the standard protocol specifications and will not be repeated here. This embodiment takes the QCI value of 1 for the bearer to be established between the first UE and the second UE as an example.

[0137] Continuing with Figure 2 , illustratively, after a bearer is established between the first UE and the core network, the core network can send an audio packet corresponding to a network ringback tone to the first UE via the bearer. For core networks that support resource reservation, 183 signaling is typically issued after the bearer is established, and the resource reservation process is completed via the Session Description Protocol (SDP).

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

[0139] Specifically, when determining the ringback tone type based on 183 signaling, it is specifically related to the PEM header field (i.e., the P-Early-Media identifier mentioned above, which will be collectively referred to as the PEM header field in the following text). The relationship between the PEM header field and the ringback tone type in 183 signaling can be shown in Table 1 in Figure 2.

[0140] As can be seen from Table 1, in one 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 one possible implementation method, it can be determined that the ringback tone type is a local ringback tone, that is, the first UE needs to play the tone locally (the audio data corresponding to the ringback tone is provided by the first UE itself).

[0141] Continuing to refer to Table 1, in another possible situation, 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).

[0142] Continuing to refer to 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.

[0143] For example, if the adopted chip (such as the chip provided by the first chip platform shown in FIG2 ) does not include the PEM header field, the ringback tone type is a network ringback tone. For such a terminal, the ringback tone type can be determined as a network ringback tone in this scenario.

[0144] For example, if the chip used (such as the chip provided by the second chip platform shown in Figure 2) does not include the PEM header field, 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.

[0145] 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 on this embodiment.

[0146] Inactive, as used in the embodiments of this application, indicates that early media functionality is not supported. Understandably, when the PEM header field value in the signaling sent by the network is Inactive, it indicates that the network typically does not send or receive data streams, and therefore 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.

[0147] Regarding Sendrecv mentioned in the embodiment of the present application, it means that two-way transmission is allowed, that is, the calling terminal that receives the signaling including this value is allowed to send data streams to the core network, and the calling terminal can also be allowed to receive data streams sent by the network side, such as the audio packet corresponding to the network ringback tone.

[0148] Regarding the Recvonly mentioned in the embodiment of the present application, it means that data reception is allowed, such as receiving the audio packet corresponding to the network ringback tone.

[0149] For the direction of the media stream indicated by different values ​​of the PEM header field, please refer to the standard protocol and will not be repeated here.

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

[0151] 2 , illustratively, when the second UE can remind the called party that there is a call, ie, when the second UE is ringing, the second UE will send a ringing signaling, such as 180Ringing in FIG. 2 (hereinafter referred to as: 180 signaling).

[0152] Understandably, in addition to informing the first UE that the called terminal (second UE) has rung, the 180 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 to answer is a network ringback tone or a local ringback tone.

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

[0154] As can be seen from Table 2, regardless of whether the first UE has received 183 signaling, when the first UE receives 180 signaling including a PEM header field, and the value of the included PEM header field is Inactive ("P-Early-Media: Inactive" is configured in the 180 signaling), in a possible implementation, the ringback tone type can be determined as a local ringback tone, that is, the first UE needs to play the tone locally.

[0155] Continuing to refer to Table 2, regardless of whether the first UE has received the 183 signaling, when the first UE receives the 180 signaling including the 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 180 signaling), in a possible implementation, it can be determined that the ringback tone type is a network ringback tone, that is, the first UE needs to play the network tone.

[0156] Continuing to refer to Table 2, for the case where the first UE has received 183 signaling, when the first UE receives 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, the ringback tone type is not changed. When the ringback tone type determined according to the 183 signaling is a network ringback tone, the first UE still maintains the network ringback tone; when the ringback tone type determined according to the 183 signaling is a local ringback tone, the first UE still maintains the local ringback tone.

[0157] Continuing to refer to Table 2, if the first UE does not receive 183 signaling, and if the first UE receives 180 signaling that does not include the PEM header field, the ringback tone type can be a network ringback tone or a local ringback tone, depending on the chip used by the first UE.

[0158] For example, if the adopted chip (such as the chip provided by the first chip platform shown in FIG2 ) does not include the PEM header field, the ringback tone type is a network ringback tone. For such a terminal, the ringback tone type can be determined as a network ringback tone in this scenario.

[0159] For example, if the chip used (such as the chip provided by the second chip platform shown in Figure 2) does not include the PEM header field, 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.

[0160] 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 on this embodiment.

[0161] 2 , illustratively, if the call service continues to proceed normally, the second UE will make a 200 OK success response (the final response to the INVITE signaling) to the first UE. Accordingly, after receiving the 200 OK from the second UE, the first UE will make an ACK response to the second UE, informing the second UE that the first UE has received the second UE's final response to the INVITE signaling.

[0162] 2 , illustratively, after the first UE sends an ACK response to the second UE, a media session between the first UE and the second UE is successfully established. At this point, the first UE can talk to the second UE.

[0163] Continuing with Figure 2 , for example, if the second UE hangs up after a certain duration, the second UE will initiate a BYE command to the first UE to terminate the established call. Accordingly, upon receiving the BYE command, the first UE ends the call with the second UE and responds with a 200 OK message, informing the second UE that it has received the second UE's instruction to terminate the current session, thereby terminating the session.

[0164] It is understandable that the BYE instruction can 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 200 OK response confirming the end of the current session is made by the second UE.

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

[0166] As can be seen from the above description, 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 shown in Figure 3.

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

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

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

[0170] For example, the INVITE signaling may include "P-Early-Media: supported" information, that is, information that supports PEM. In a specific implementation, for example, "P-Early-Media: supported" may be configured in the SDP of the INVITE signaling to include information that supports PEM.

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

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

[0173] 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 signaling 183 or signaling 180. Signaling 183 is typically the first signaling that can indicate the type of ringback tone sent by the network after the first UE initiates a call request. Signaling 180 is the last signaling that can indicate the type of ringback tone sent by the network.

[0174] In addition, it should be understood that for local ringback tone, it is necessary to start playing after receiving the 180 signaling indicating local play. For network ringback tone, you can ignore the 180 signaling and just start playing after receiving the audio packet corresponding to the network ringback tone.

[0175] For details on determining whether the ringback tone type is a network ringback tone according to 183 signaling and 180 signaling, please refer to Table 1 and Table 2 shown in Figure 2, which will not be repeated here.

[0176] Furthermore, it should be noted that, in actual applications, the first UE may also determine the ringback tone type based on other signaling that can indicate the ringback tone type. For example, the first UE may determine the ringback tone type based on Update signaling (signaling by which the user sends an update message) received before the 180 signaling. Regarding the relationship between the PEM header field and the ringback tone type in the Update signaling, in one possible implementation, it may be the same as the relationship between the PEM header field and the ringback tone type in the 180 signaling. For details, see Table 2 shown in FIG. 2 , and no further description is given here.

[0177] 103. The first UE starts timing from the first moment, with the timing duration being the first duration, and monitors whether an audio packet sent by the network side is received within the first duration.

[0178] It should be noted that, typically, after the first UE receives signaling instructing the network to play a tone, the network side will deliver the audio package corresponding to the network ringback tone to the first UE. To ensure user experience and avoid a long wait for the audio package corresponding to the network ringback tone, which may result in the first UE being unable to play the ringback tone, in one possible implementation, the first UE can be set to start timing from the moment it first receives the message instructing the network ringback tone.

[0179] Optionally, the timing duration may be the first duration, such as 2s.

[0180] In this way, the first UE can monitor whether the audio packet corresponding to the network ringback tone sent by the network side is received within the first time period, such as 2 seconds.

[0181] Optionally, it can be configured that when the first UE receives an audio packet sent by the network within the first time, network playback is performed to play the audio data in the audio packet, i.e., step 104 is executed. Otherwise, when the first UE does not receive an audio packet sent by the network within the first time, local playback is performed to play the audio data stored in the local storage medium of the first UE, i.e., step 105 is executed.

[0182] Optionally, in one implementation, the first UE may be configured to start a 2-second timer after receiving a signaling instructing the network to play audio. If an audio packet sent by the network is received within the timer, step 104 is executed; otherwise, step 105 is executed.

[0183] 104. The first UE plays a network ringback tone.

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

[0185] 105. The first UE plays a local ringback tone.

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

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

[0188] However, in the scenario where the ringback tone type is a network ringback tone, the ringback tone played by the first UE may be silent because the audio data in the audio packet sent by the network side are all silent frames (i.e., audio frames without sound). As shown in (2) in Figure 4, only the prompt information that the other party is ringing is displayed on the user interface of the first UE, but there is no sound in the receiver or speaker, causing the user to mistakenly believe that the call failed, affecting the user experience.

[0189] In view of this, an embodiment of the present application provides a ringback tone playback method. In this method, in a scenario where the ringback tone is provided by the network side, the calling terminal monitors whether it has received an audio packet provided by the network side within a specified time, and determines whether the data in the audio packet is a silence frame, and then decides whether to continue playing the network ringback tone or switch to playing the local ringback tone. This ensures that the calling terminal can play the ringback tone in a timely manner and provide a prompt to the user.

[0190] In order to better understand the ringback tone playing method provided in the embodiment of the present application, the hardware structure of the terminal device to which the method is applicable is described below with reference to FIG5 .

[0191] 5 , which is a schematic diagram illustrating the hardware structure of a terminal device 100 for implementing the ringback tone playing method provided in an embodiment of the present application.

[0192] It should be noted that the terminal device may also be expressed as User Equipment (UE). Specifically in this embodiment, it refers to a user registered with the IMS network, and may include a mobile terminal, a fixed terminal, a SIP soft terminal, and the like.

[0193] SIP stands for Session Initiation 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 between one or more participants.

[0194] 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 on this embodiment.

[0195] For ease of description, this embodiment takes a mobile terminal, such as a mobile phone, as an example to illustrate the hardware structure of the terminal device 100.

[0196] 5 , illustratively, 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 button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0197] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals.

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

[0199] 5 , illustratively, 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 (WLAN) (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.

[0200] Exemplarily, in some implementations, 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 technology.

[0201] 5 , illustratively, the audio module 170 of the terminal device 100 includes a speaker 170A, a receiver 170B, a microphone 170C, an earphone jack 170D, and the like.

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

[0203] In addition, regarding the sensor module 180 in the terminal device 100, in some embodiments, it may include a pressure sensor, a gyroscope sensor, an air 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., which are not listed one by one here and this application does not impose any restrictions on this.

[0204] In addition, it should be noted that, in some implementations, 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 processor (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.

[0205] It is understandable that, in a specific implementation, different processing units may be independent devices or integrated into one or more processors.

[0206] Furthermore, it should be noted that, in some implementations, the controller may be the nerve center and command center of the terminal device 100. In practical applications, the controller may generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0207] Furthermore, it should be noted that, in some implementations, processor 110 may also include a memory for storing instructions and data. In some implementations, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0208] In addition, it should be noted that, in some implementations, 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.

[0209] 5 , illustratively, the charging management module 140 is configured to receive charging input from a charger. While the charging management module 140 is charging the battery 142 , it can also power the terminal device through the power management module 141 .

[0210] Continuing to refer to Figure 5, illustratively, 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 input from the battery 142 and / or the charging management module 140, and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, battery health status (leakage, impedance), etc. In some other implementations, the power management module 141 can also be set in the processor 110. In other implementations, the power management module 141 and the charging management module 140 can also be set in the same device.

[0211] Continuing with FIG5 , illustratively, the wireless communication function of the terminal device 100 can be implemented by antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem 110A, etc. Specifically, in the technical solution provided in the embodiment of the present application, the processing logic for playing the ringback tone after initiating a call service can be implemented by these modules.

[0212] In addition, the terminal device 100 shown in FIG5 can implement display functions through a GPU, a display screen 194, and an application processor, such as displaying the user interface in (1) or (2) in FIG4.

[0213] In addition, the terminal device 100 can realize the shooting function through the ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0214] 5 shows that the external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage.

[0215] 5 shows that the internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes the instructions stored in the internal memory 121 to execute various functional applications and data processing of the terminal device 100.

[0216] Specifically in the technical solution provided in the embodiments of the present application, the audio data corresponding to the local ringback tone and the relevant instructions for implementing the ringback tone playback method can be pre-stored in the internal memory 121. The processor 110 executes the instructions stored in the internal memory 121, thereby enabling the terminal device 100 to execute the ringback tone playback method provided in each embodiment of the present application.

[0217] Continuing with FIG5 , buttons 190 illustratively include a power button, a volume button, and the like. Buttons 190 may be mechanical or touch-sensitive. Motor 191 may generate vibrations. Indicator 192 may be an indicator light that can indicate charging status, battery level changes, and messages such as missed calls and notifications.

[0218] Continuing with Figure 5, illustratively, the SIM card interface 195 is used to connect a SIM card or a USIM card. The SIM card can be connected to and disconnected from the terminal device 100 by inserting or removing the SIM card interface 195. The terminal device 100 can support 1 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 in this embodiment, VoLTE is implemented based on a SIM card or a USIM card.

[0219] This concludes the introduction to the hardware structure of the terminal device 100. It should be understood that the terminal device 100 shown in FIG5 is merely an example. In a specific implementation, the terminal device 100 may have more or fewer components than shown in the figure, may combine two or more components, or may have a different component configuration. The various components shown in FIG5 may be implemented in hardware, including one or more signal processing and / or application-specific integrated circuits, software, or a combination of hardware and software.

[0220] Taking the terminal device with the hardware structure shown in Figure 5 as an example, for the communication environment shown in Figure 1, still taking the 4G network architecture as an example, the process of implementing the ringback tone playing method provided by this application on the terminal device is specifically described.

[0221] It should be noted that the implementation of call services requires processing based on the modem protocol stack. Therefore, when implementing the ringback tone playback method provided in each embodiment of this application, the policy and processing logic followed by the terminal device can be set in the modem protocol stack. That is, in the ringback tone playback method provided in each embodiment below, the operations performed by the calling terminal (such as the first UE) are all completed in the modem protocol stack.

[0222] 6A , the ringback tone playing method provided in an embodiment of the present application specifically includes:

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

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

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

[0226] For example, the INVITE signaling may include "P-Early-Media: supported" information, that is, information that supports PEM. In a specific implementation, for example, "P-Early-Media: supported" may be configured in the SDP of the INVITE signaling to include information that supports PEM.

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

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

[0229] It can be understood that the first UE is in the process of waiting for the second UE to answer the call corresponding to the INVITE signaling initiated in step 201.

[0230] 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 signaling 183 or signaling 180. Signaling 183 is typically the first signaling that can indicate the type of ringback tone sent by the network after the first UE initiates a call request. Signaling 180 is the last signaling that can indicate the type of ringback tone sent by the network.

[0231] In addition, it should be understood that for local ringback tone, it is necessary to start playing after receiving the 180 signaling indicating local play. For network ringback tone, you can ignore the 180 signaling and just start playing after receiving the audio packet corresponding to the network ringback tone.

[0232] For details on determining whether the ringback tone type is a network ringback tone according to 183 signaling and 180 signaling, please refer to Table 1 and Table 2 shown in Figure 2, which will not be repeated here.

[0233] Furthermore, it should be noted that, in actual applications, the first UE may also determine the ringback tone type based on other signaling that can indicate the ringback tone type. For example, the first UE may determine the ringback tone type based on Update signaling (signaling by which the user sends an update message) received before the 180 signaling. Regarding the relationship between the PEM header field and the ringback tone type in the Update signaling, in one possible implementation, it may be the same as the relationship between the PEM header field and the ringback tone type in the 180 signaling. For details, see Table 2 shown in FIG. 2 , and no further description is given here.

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

[0235] As can be seen from the above description, in the scenario where the ringback tone type is a network ringback tone, the audio packet corresponding to the network ringback tone may not reach the first UE in time due to certain abnormalities. In order not to affect the user experience, a reasonable time, such as 1s or 2s, can be set according to business needs, chip requirements used by the first UE, etc. It is also stipulated that if the audio packet corresponding to the network ringback tone is not received within the set time (first time), the ringback tone type is promptly changed from network ringback tone to local ringback tone. Since the audio data corresponding to the local ringback tone is pre-stored in the local storage medium of the first UE, such as the internal memory 121 mentioned above, the first UE can play it directly. Therefore, after receiving the signaling indicating the network ringback tone, a timer with a timing duration of 1s or 2s 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 an 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, thereby avoiding the situation where the audio packet is received within the set time, but since the received audio packets are all silent packets, the first UE still cannot play the ringback tone sound.

[0236] It should be noted that for signaling indicating the type of network ringback tone received before the 180 signaling, such as the 183 signaling and the Update signaling, due to chip influence, when the 183 signaling or Update signaling is received without the PEM header field, the default ringback tone type may be the network ringback tone (case 1), or the default ringback tone type may be the local ringback tone (case 2). Therefore, the processing logic for playing the ringback tone provided in the embodiments of the present application can be different for these two cases.

[0237] Specifically, for situation 1, the judgment logic shown in Figure 6A can be directly followed. For situation 2, the judgment logic shown in Figure 6B can be directly followed, which will not be described in detail here.

[0238] 204 : Whether all audio packets received by the first UE within the first time are mute packets.

[0239] In the embodiment shown in FIG3 , since only attention is paid to whether an audio packet corresponding to a network ringback tone is received within the timed period corresponding to the started timer, if an audio packet is received within the timed period (first time), the network tone is played directly without paying attention to whether the data in the audio packet are all silent frames. As a result, if 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, attention is paid not only to whether an audio packet is received within the timed period, but also to whether all the audio packets received within the timed period are silent packets, that is, whether no sound can be played.

[0240] Specifically, in this embodiment, if the first UE receives an audio packet within the timer, and all received audio packets are silent packets, the ringback tone type is directly changed to a local ringback tone. In this way, the first UE can directly read the audio data corresponding to the local ringback tone from the local storage medium and play it, that is, executing step 205. Otherwise, if the audio packets received within the timer are non-silent packets, that is, as long as an audio packet with sound is received within the timer, the network ringback tone is played regardless of whether the audio is continuous, that is, executing step 206.

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

[0242] For example, if the audio packet uses the Adaptive Multi-Rate (AMR) or Adaptive Multi-Rate Wideband (AMR-WB) audio coding file format, both audio packets include an FT flag and define specific values ​​for the FT flag corresponding to silent packets. For example, the AMR-NB audio packet defines a silent value of 8. The AMR-WB audio packet defines a silent value of 9. For details, please refer to the standard protocols corresponding to these two audio coding file formats and will not be repeated here.

[0243] That is, for an audio packet in the AMR-NB format, if the FT flag bit is set to 8, it indicates that the audio packet is a silent packet. Otherwise, it is considered that the audio packet contains audio frames that can be played. For an audio packet in the AMR-WB format, if the FT flag bit is set to 9, it indicates that the audio packet is a silent packet. Otherwise, it is considered that the audio packet contains audio frames that can be played.

[0244] It should be understood that the above description is only an example listed for a better understanding of the technical solution of the present embodiment and is not intended to be the sole limitation of the present embodiment. In actual applications, if the received audio packet is in other sound coding formats, such as Enhanced Voice Services (EVS), a 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 the value of the flag bit can be used to determine whether the audio packet is a silent packet.

[0245] In addition, it should be noted that in some possible implementations, 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.

[0246] Optionally, in some possible implementations, the RTP includes an audio package which may be named, for example, “NALDBG” (hereinafter referred to as: NALDBG audio package).

[0247] Optionally, in a possible implementation, when determining whether an audio packet is a silent packet, it is also possible to determine whether the audio packet is a silent packet based on the length of the NALDBG audio packet.

[0248] Optionally, when the length of the NALDBG audio packet is between 15 and 25 (including the endpoint value), it can be confirmed that it is a silence packet.

[0249] Optionally, in a possible implementation, the length may be, for example, 17, or 18, or 19, or 21, that is, any value between 15 and 25.

[0250] 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 on this embodiment.

[0251] In addition, it should be noted that in some other possible implementations, the name of the audio packet may not be important. When a data packet sent by the network side based on the real-time transport protocol is received, the data packet may be regarded as an audio packet of the network ringback tone.

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

[0253] 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 a local ringback tone.

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

[0255] 205. The first UE plays a local ringback tone.

[0256] It should be noted that for local ringback tones, local playback can only begin after receiving the 180 signaling. Therefore, in the scenario where the previously received signaling indicating the network ringback tone is the 180 signaling, if no audio packets are received within the set time, or if all received audio packets are silent packets, the first UE can directly play the local tone.

[0257] For example, in the scenario where the previously received signaling indicating the network ringback tone is other signaling, such as 183 signaling, or Update signaling, or other signaling that can indicate the type of ringback tone, when no audio packet is received within the set time, or the received audio packets are all silent packets, the first UE needs to wait for 180 signaling after changing the ringback tone type to local playback.

[0258] Understandably, the first UE can only play the sound locally when 180 signaling is received and the network type indicated by the 180 signaling is also a local ringback tone. If the network type indicated by the 180 signaling is a network ringback tone, the ringback tone type needs to be changed back to the network ringback tone, and further monitoring needs to be performed to determine whether an audio packet other than a silent packet is received within the set time. In other words, the judgment of steps 203 and 204 needs to be re-executed. If it is determined that no audio packet is received within the set time, or if all received audio packets are silent packets, the first UE will change the ringback tone type back to the local ringback tone and then play the sound locally.

[0259] 206. The first UE plays a network ringback tone.

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

[0261] It should be understood that the above description is merely an example for better understanding the technical solution of this embodiment and is not intended to be the sole limitation of this embodiment. In actual applications, the number of determinations may also be set according to business needs.

[0262] 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, the first UE monitors whether the audio package provided by the network side is received within the specified time, and determines whether each received audio package is a silent package, and then decides whether to continue playing the network ringback tone or change to playing the local ringback tone, thereby ensuring that the first UE can play the ringback tone in time and prompt the user.

[0263] 6B , an embodiment of the present application provides a method for playing a ringback tone for the above-mentioned situation 2, specifically comprising:

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

[0265] Step 301 in this embodiment is similar to step 101 and step 102 in the above embodiment. Please refer to the above embodiment for details, which will not be repeated here.

[0266] 302. The first UE receives the 183 signaling.

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

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

[0269] For details on determining whether the ringback tone type is a network ringback tone based on 183 signaling, please refer to Table 1 shown in Figure 2. In this embodiment, the chip used by the first UE is a chip of the second chip platform as an example (that is, when the 183 signaling does not include the PEM header field, it indicates local playback), and no further details are given here.

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

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

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

[0273] That is, the logic of step 203, step 204 and step 205 in FIG6A is executed, and details thereof will not be repeated here.

[0274] 306. The first UE plays a network ringback tone.

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

[0276] 307. The first UE sets the ringback tone type to a local ringback tone.

[0277] Optionally, when the 183 signaling indicates that the ringback tone type is a 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 a local ringback tone.

[0278] 308. The first UE receives the 180 signaling.

[0279] As can be understood from Table 2 in Figure 2, when 183 signaling is received before 180 signaling, there are three situations in which 180 signaling indicates the ringback tone type. Specifically, these three situations include the situation in which 180 signaling indicates the ringback tone type is a network ringback tone, i.e., the PEM header field = Sendrecv / Revonly (hereinafter referred to as situation 2.1); the situation in which 180 signaling indicates the ringback tone type is a local ringback tone, i.e., the PEM header field = Inactive (hereinafter referred to as situation 2.2); and the situation in which 180 signaling does not indicate the ringback tone type, i.e., does not include a PEM header field (hereinafter referred to as situation 2.3).

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

[0281] It can be understood that Case 2.1, Case 2.2 and Case 2.3 are three separate cases.

[0282] 309. The first UE sets the ringback tone type to a network ringback tone.

[0283] 310. The first UE continues to use the previously set ringback tone type.

[0284] 311. The first UE sets the ringback tone type to local ringback tone.

[0285] 312. The first UE monitors whether a non-mute packet sent by the network side is received within a third time period.

[0286] That is, the logic of step 203, step 204 and step 205 in FIG6A is executed, and details thereof will not be repeated here.

[0287] 313. The first UE plays a network ringback tone.

[0288] 314. The first UE plays a local ringback tone.

[0289] Furthermore, it should be noted that in scenario 2 (where the first UE uses a chip from the second chip platform), even if the 180 signaling is received and the local ringback tone begins playing, before the call acceptance (200 OK) signaling is received, as long as an audio packet corresponding to the network ringback tone sent by the network is received, the ringback tone type will be changed to the network ringback tone, and the network ringback tone will be played. Therefore, while the first UE executes steps 302 to 314, it also executes step 315.

[0290] 315 , the first UE continuously monitors whether an audio packet sent by the network side is received, and detects whether the received audio packet is a non-mute packet.

[0291] Optionally, after receiving the 183 signaling and before receiving the 200OK signaling, the first UE may continue to monitor whether an audio packet sent by the network side is received, and detect whether the received audio packet is a non-mute packet.

[0292] Specifically, if a non-mute packet sent by the network is monitored, the first UE may execute step 316. Otherwise, the first UE may continue to monitor whether an audio packet sent by the network is received and detect whether the received audio packet is a non-mute packet until a 200OK signaling is received.

[0293] 316. The first UE sets the ringback tone type to a network ringback tone, starts playing the network ringback tone, and terminates monitoring.

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

[0295] Therefore, for the scenario where the signaling received before the 200OK signaling indicates a local ringback tone, the first UE monitors whether an audio packet is received before the 200OK signaling, and promptly changes the ringback tone type to a network ringback tone when an audio packet is received, and determines whether each audio packet received within the specified time is a silent packet, and then decides whether to continue playing the network ringback tone or change to playing the local ringback tone, thereby ensuring that the first UE can play the ringback tone in time and prompt the user.

[0296] In order to better understand the ringback tone playing method provided in the embodiment of the present application, still taking the 4G network architecture as an example, several specific scenarios are described below.

[0297] Before describing the ringback tone playback method provided in the embodiments of this application, we first describe the specific objects within the calling terminal that perform this operation. As can be seen from the above description, the implementation of call services requires processing based on the modem protocol stack, specifically within the Session Initiation Protocol (SIP) module within the modem protocol stack. As will be appreciated, within the modem protocol stack, the SIP module is located within the IMS protocol layer (also referred to as the IMS module). This embodiment uses the IMS module as an example.

[0298] In addition, according to the above description of the hardware structure of the terminal device, it can be known that the ringback tone is specifically played through the audio module.

[0299] Furthermore, it should be noted that for network ringback tones, since the audio packets come from the network, the calling terminal needs to parse the audio packets after receiving them so that the audio module can play the tone over the network based on the parsed audio data. Therefore, the ringback tone playback method provided in the present embodiment also requires a data processing module (referred to as a "Data module") to process the audio packets.

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

[0301] In addition, it should be noted that, in actual applications, the functions implemented by the data processing module can be integrated into the IMS module. This embodiment takes the integration of the functions of the data processing module into the IMS module as an example.

[0302] In addition, since the operation of the ringback tone playback process is mainly performed after the calling terminal receives the signaling indicating the ringback tone type sent by the network side, the object that interacts with the calling terminal shown in the accompanying drawings is 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.

[0303] For the specific structure of the Modem protocol stack and the functions that each layer can implement, please refer to the standard document of the Modem protocol stack, which will not be repeated here.

[0304] In addition, it should be noted that, from the above description, it can be seen that in actual applications, due to the different chips used in the terminal, there may be two specific situations, namely, situation 1 and situation 2. For the sake of convenience, the following scenarios all take situation 1 as an example.

[0305] Furthermore, it should be noted that in actual applications, the calling terminal may receive other signaling indicating the type of ringback tone, such as signaling 183, before receiving signaling 180. For local ringback tone, local playback must be performed only after receiving signaling 180. For ease of explanation, this embodiment will be described from two broad scenarios.

[0306] Scenario 1: 183 signaling is received first, then 180 signaling is received

[0307] 7A to 7C , and 8A to 8C , exemplarily, in some implementations, when a calling terminal needs to conduct a call service with a called terminal, the IMS module in the calling terminal initiates an INVITE signaling including supported PEM information. After the INVITE signaling is transmitted to the base station, the base station forwards it to the called terminal to be called.

[0308] For detailed description of including the information supporting PEM in the INVITE signaling, please refer to the INVITE signaling initiated by the first UE to the second UE in the embodiment shown in FIG2 , which will not be described again here.

[0309] Continuing with Figures 7A-7C and 8A-8C, illustratively, after the calling terminal initiates INVITE signaling and waits to establish a media session with the called terminal, the base station will provide feedback to the calling terminal's IMS module regarding the call progress, along with a ringback tone indication, based on the actual call progress. The calling terminal then responds accordingly based on the 183 signaling, for example, by playing a corresponding ringback tone to inform the user of the current session progress, thereby improving the user experience.

[0310] As can be seen from the above description of the signaling used to determine whether the calling terminal plays a ringback tone, 183 signaling can be used to indicate the type of ringback tone. Therefore, upon receiving the 183 signaling sent by the base station, the IMS module of the calling terminal can determine the type of ringback tone according to the ringback tone decision logic shown in Figures 7A, 7B, 7C, 8A, 8B, or 8C, and then play the ringback tone based on the determined ringback tone type.

[0311] It should be noted that, if the 183 signaling indicates that the ringback tone type is local, the local ringback tone can only be played after receiving the 180 signaling. Therefore, this embodiment takes the ringback tone type indicated by the 183 signaling as network ringback tone as an example to illustrate the processing flow of playing the ringback tone in this scenario.

[0312] Table 1 shows that when the 183 signaling does not include a PEM header field or includes a PEM header field with the value "Sendrecv / Recvonly," the ringback tone type indicated is a network ringback tone. Scenarios where the 183 signaling indicates a network ringback tone can be further categorized as either the case where the calling terminal starts playing the ringback tone before receiving the 180 signaling or the case where the ringback tone is not played before receiving the 180 signaling.

[0313] For example, for a scenario in which the calling terminal starts playing the ringback tone before receiving the 180 signaling, as shown in FIG. 7A to FIG. 7C .

[0314] 7A to 7C , illustratively, after the calling terminal determines the ringback tone type as network playback according to the 183 signaling, it can start a timer, such as T1 (with a timing duration of 2 seconds). Then, within the timing duration corresponding to T1, it monitors whether the audio packet corresponding to the network ringback tone (hereinafter referred to as: RTP packet) is received.

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

[0316] Exemplarily, when the value of the FT flag obtained from RTP packet 0 is the mute value set in the standard protocol of the sound coding file format, RTP packet 0 is determined to be a mute packet; otherwise, RTP packet 0 is determined not to be a mute packet, that is, there is audio data that can be played.

[0317] Continuing with Figures 7A to 7C , this embodiment uses the example of RTP packet 0 received within the timer duration corresponding to T1 as an example, and not being a silent packet. In this case, the IMS module can transmit the audio data parsed from RTP packet 0 to the audio module, so that the audio module can play the audio data corresponding to the network ringback tone.

[0318] 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 on this embodiment.

[0319] The scenario in which the calling terminal starts playing the ringback tone before receiving the 180 signaling can be further divided into scenario 1.1a, scenario 1.1b and scenario 1.1c shown in FIG. 7A to FIG. 7C respectively.

[0320] Scenario 1.1a:

[0321] Referring to Figure 7A , in an exemplary embodiment, after playing a network ringback tone, the calling terminal receives a 180 signaling message indicating that the ringback tone type is a local ringback tone, such as one including a PEM header field with a value of Inactive. In this scenario, since the network ringback tone had already begun playing and sounded before the 180 signaling message was received, to avoid affecting the user experience and preventing the ringback tone from suddenly switching from the ringback tone set by the called user to a "beep" sound, the IMS module can start another timer, such as T2 (with a timer duration of 2 seconds). Then, within the timer duration corresponding to T2, it monitors whether the RTP packet corresponding to the network ringback tone is received.

[0322] Continuing with FIG. 7A , illustratively, when the IMS module receives an RTP packet (such as RTP packet 1) sent from the network side within the timed duration corresponding to T2, the IMS module parses the RTP packet 1 to determine the sound coding file format of the RTP packet 1 from the parsed content. Furthermore, based on the determined sound coding file format, the module obtains from the RTP packet 1 the value of the FT flag indicating whether the RTP packet 1 is a silent packet.

[0323] Exemplarily, when the value of the FT flag obtained from RTP packet 1 is the mute value set in the standard protocol of the sound coding file format, RTP packet 1 is determined to be a mute packet; otherwise, RTP packet 1 is determined not to be a mute packet, that is, there is audio data that can be played.

[0324] Continuing with Figure 7A , this embodiment uses the example of an RTP packet 1 received within the timer duration corresponding to T2 being a non-silent packet. In this case, the IMS module can transmit the audio data parsed from RTP packet 1 to the audio module, allowing the audio module to continue playing the network sound, namely, the audio data corresponding to the network ringback tone.

[0325] Therefore, while waiting for the called terminal to answer the call, in the scenario where the calling terminal first receives the 183 signaling instructing the network to play the audio, and has received the audio package sent by the network side before receiving the 180 signaling, when the 180 signaling instructing the local to play the audio is received during the playing of the network ringback tone, the local ringback tone is not played first, but the audio package sent by the network side is monitored within the set time to see whether it is still received within the set time. If the audio package sent by the network side is received within the set time and the received audio package is not a silent package, the network ringback tone is continued to be played, thereby avoiding the sudden switching 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.

[0326] 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 on this embodiment.

[0327] Scenario 1.1b:

[0328] Continuing with FIG. 7B , illustratively, when the IMS module receives an RTP packet (such as RTP packet 2) sent from the network side within the timed duration corresponding to T2, the IMS module parses the RTP packet 2 to determine the sound coding file format of the RTP packet 2 from the parsed content, and then obtains the value of the FT flag from the RTP packet 2, which indicates whether the RTP packet 2 is a silent packet, based on the determined sound coding file format.

[0329] 7B , for example, this embodiment takes the case where RTP packet 2 received within the timer duration corresponding to T2 is a silence packet. In this case, if the timer duration T2 has not yet arrived, the IMS module can continue to monitor whether a new RTP packet is received.

[0330] Continuing with FIG. 7B , illustratively, when the IMS module receives a new RTP packet (such as RTP packet 3) sent from the network side within the timed duration corresponding to T2, the IMS module parses RTP packet 3 to determine the sound coding file format of RTP packet 3 from the parsed content, and then obtains the value of the FT flag bit from RTP packet 3, which indicates whether RTP packet 3 is a silent packet, based on the determined sound coding file format.

[0331] Continuing with Figure 7B , this embodiment uses the example of RTP packet 3 being a silence packet received within the timer duration corresponding to T2. In this case, if the timer duration corresponding to T2 has not yet expired, the IMS module can continue to monitor for new RTP packets. If the timer duration corresponding to T2 has now expired, the IMS module can change the ringback tone type from network playback to local playback. This embodiment uses the example of the timer duration corresponding to T2 having now expired.

[0332] Continuing to refer to FIG. 7B , illustratively, when the timing duration corresponding to T2 is currently reached and the IMS module does not receive an RTP packet that is not a silent packet, the IMS module may change the ringback tone type from a network ringback tone to a local ringback tone and instruct the audio module to play the tone locally, i.e., play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0333] This prevents the calling terminal from briefly playing a network ringback tone and then going silent while waiting for the called terminal to answer the call. By playing the local ringback tone instead after not receiving the RTP packet corresponding to the network ringback tone within the set time, the calling user is informed that the current call is still waiting for the called party to answer, rather than being disconnected.

[0334] 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 on this embodiment.

[0335] Scenario 1.1c:

[0336] Continuing with Figure 7C , as an example, a possible scenario is that after receiving the 180 signaling indicating a local ringback tone and starting T2, the calling terminal may not receive a single RTP packet within the timer corresponding to T2. In this case, after T2 times out, the calling terminal's IMS module can change the ringback tone type from a network ringback tone to a local ringback tone and instruct the audio module to play the locally stored ringback tone audio data, such as a "beep" sound.

[0337] This can also prevent the calling terminal from briefly playing a network ringback tone and then going silent while waiting for the called terminal to answer the call. By playing the local ringback tone instead 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, rather than being disconnected.

[0338] 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 on this embodiment.

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

[0340] For example, the scenario in which the calling terminal does not play the ringback tone before receiving the 180 signaling can be divided into scenario 1.2a, scenario 1.2b, and scenario 1.2c shown in FIG. 8A to FIG. 8C , respectively.

[0341] Scenario 1.2a:

[0342] 8A , illustratively, 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 (timing duration is 2s) and then monitor whether the RTP packet corresponding to the network ringback tone is received within the timing duration corresponding to T1.

[0343] Continuing with FIG8A , illustratively, when the IMS module of the calling terminal receives an RTP packet (such as RTP packet 4) sent from the network side within the timing duration corresponding to T1, the IMS module of the calling terminal parses the RTP packet 4 to determine the sound coding file format of the RTP packet 4 from the parsed content, and then obtains the value of the FT flag bit from the RTP packet 4, which is used to indicate whether the RTP packet 4 is a silent packet, based on the determined sound coding file format.

[0344] 8A , for example, this embodiment takes the case where the RTP packet 4 received within the timer duration corresponding to T1 is a silence packet. In this case, if the timer duration T1 has not yet arrived, the IMS module can continue to monitor whether a new RTP packet is received.

[0345] Continuing with FIG8A , illustratively, when the IMS module receives a new RTP packet (such as RTP packet 5) sent from the network side within the timed duration corresponding to T1, it parses RTP packet 5 to determine the sound coding file format of RTP packet 5 from the parsed content. Furthermore, based on the determined sound coding file format, it obtains from RTP packet 5 the value of the FT flag indicating whether RTP packet 5 is a silent packet.

[0346] Continuing with Figure 8A , this embodiment uses the example of RTP packet 5 being a silence packet received within the timer duration corresponding to T1. In this case, if the timer duration corresponding to T1 has not yet expired, the IMS module can continue to monitor for new RTP packets. If the timer duration corresponding to T1 has now expired, the IMS module can change the ringback tone type from network playback to local playback. This embodiment uses the example of the timer duration corresponding to T1 having now expired.

[0347] Since local announcement 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.

[0348] 8A , illustratively, when the IMS module receives 180 signaling and the ringback tone type indicated by the 180 signaling is a local ringback tone, the IMS module may instruct the audio module to play the tone locally, i.e., play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0349] 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 on this embodiment.

[0350] Scenario 1.2b:

[0351] Continuing with Figure 8B , as an example, a possible scenario is that after receiving signaling 183 instructing network tone playback and starting T1, the calling terminal may not receive a single RTP packet within the timer corresponding to T1. In this case, the ringback tone type can be changed to a local ringback tone. Upon receiving signaling 180 instructing local ringback tone, the audio module is directly triggered to play the tone locally.

[0352] 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 on this embodiment.

[0353] Scenario 1.2c:

[0354] Continuing with FIG8C , as another possible scenario, after receiving signaling 183 indicating network tone playback and starting time T1, the calling terminal may not receive a single RTP packet within the timed duration corresponding to T1. Alternatively, all RTP packets received within the timed duration of T1 may be silent packets, as shown in FIG8C , where both RTP packets 6 and 7 received within the timed duration corresponding to T1 are silent packets. However, if the ringback tone type is changed to a local ringback tone and the received signaling 180 indicates that the ringback tone type is a network ringback tone, the IMS module may change the ringback tone type back to a network ringback tone and start timer T2. Then, within the timed duration corresponding to T2, the ringback tone may be played using the processing logic from steps 203 to 204, as shown in FIG6A .

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

[0356] It should be understood that the above description is merely an example for better understanding the technical solution of this embodiment and is not intended to be the sole limitation of this embodiment. In actual applications, the number of determinations may also be set according to business needs.

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

[0358] Scenario 2: 180 signaling is received directly instead of 183 signaling

[0359] 9 , illustratively, the specific details of the calling terminal initiating INVITE signaling and establishing a bearer with the base station can be found in FIG. 2 , or in FIG. 7A to FIG. 7C , or in the embodiment shown in FIG. 8A to FIG. 8C , which will not be repeated here.

[0360] Continuing with Figure 9, an exemplary case occurs where, after establishing a bearer with a base station, the calling terminal receives 180 signaling directly, rather than 183 signaling. In this case, the calling terminal's IMS module can determine the ringback tone type based on the 180 signaling. The specific method for determining this type of ringback tone can be found in the example section shown in Table 2 and will not be further detailed here.

[0361] 9 , for example, taking the 180 signaling indicating a network ringback tone as an example, in one possible implementation, this situation can be divided into scenario 2a, scenario 2b, and scenario 2c. The following describes these three scenarios respectively.

[0362] Scenario 2a:

[0363] 9 , illustratively, the IMS module starts a timer, such as T3 (the timing duration is 2 seconds), and then monitors whether the RTP packet corresponding to the network ringback tone is received within the timing duration corresponding to T3.

[0364] Continuing with FIG9 , illustratively, when the IMS module of the calling terminal receives an RTP packet (such as RTP packet 8) sent from the network side within the timing duration corresponding to T3, the IMS module of the calling terminal parses the RTP packet 8 to determine the sound coding file format of the RTP packet 8 from the parsed content, and then obtains the value of the FT flag bit indicating whether the RTP packet 8 is a silent packet from the RTP packet 8 according to the determined sound coding file format.

[0365] 9, for example, this embodiment takes the case where the RTP packet 8 received within the timer duration corresponding to T3 is a silence packet. In this case, if the timer duration T3 has not yet arrived, the IMS module can continue to monitor whether a new RTP packet is received.

[0366] Continuing with FIG9 , illustratively, when the IMS module receives a new RTP packet (such as RTP packet 9) sent from the network side within the timer duration corresponding to T3, the IMS module parses the RTP packet 9 to determine the sound coding file format of the RTP packet 9 from the parsed content, and then obtains the value of the FT flag bit from the RTP packet 9, which indicates whether the RTP packet 9 is a silent packet, based on the determined sound coding file format.

[0367] Continuing with Figure 9, this embodiment uses the example of RTP packet 9 being a silence packet received within the timer corresponding to T3. In this case, if the timer corresponding to T3 has not yet expired, the IMS module can continue to monitor for new RTP packets. If the timer corresponding to T3 has expired, the IMS module can change the ringback tone type from network playback to local playback. This embodiment uses the example of the timer corresponding to T3 having expired.

[0368] Continuing to refer to FIG9 , illustratively, when the timing duration corresponding to T3 is currently reached and the IMS module does not receive an RTP packet that is not a silent packet, the IMS module may change the ringback tone type from a network ringback tone to a local ringback tone and instruct the audio module to play the tone locally, i.e., play the audio data of the locally stored ringback tone, such as a "beep" sound.

[0369] This can prevent the calling terminal from blindly waiting for the RTP packet from the network side when the ringback tone type determined by 180 signaling is a network ringback tone, resulting in the calling terminal being in a silent state (no ringback tone) while the called terminal is answering the call. By playing the local ringback tone instead after no RTP packet corresponding to the network ringback tone is received within the set time, the calling user can be informed that the current call is still waiting for the called party to answer, rather than being disconnected.

[0370] 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 on this embodiment.

[0371] Scenario 2b:

[0372] Continuing with Figure 9, as an example, a possible scenario is that after receiving the 180 signaling indicating a network ringback tone and starting T3, the calling terminal may not receive a single RTP packet within the timer corresponding to T3. In this case, after T3 times out, the calling terminal's IMS module can change the ringback tone type from a network ringback tone to a local ringback tone and instruct the audio module to play the locally stored ringback tone audio data, such as a "beep" sound.

[0373] Therefore, in this scenario, it can also avoid the calling terminal blindly waiting for the RTP packet from the network side when the ringback tone type determined by 180 signaling is the network ringback tone, resulting in the calling terminal being in a silent state (no ringback tone) while the called terminal is answering the call. By playing the local ringback tone instead 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, rather than being disconnected.

[0374] 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 on this embodiment.

[0375] Scenario 2c:

[0376] Continuing to refer to FIG. 9 , illustratively, in another possible implementation, when the IMS module of the calling terminal receives an RTP packet (such as RTP packet 10) sent from the network side within the timing duration corresponding to T3, the IMS module of the calling terminal parses the RTP packet 10 to determine the sound coding file format of the RTP packet 10 from the parsed content, and then obtains the value of the FT flag bit indicating whether the RTP packet 10 is a silent packet from the RTP packet 10 according to the determined sound coding file format.

[0377] Continuing with Figure 9, this embodiment uses the example of an RTP packet 10 received within the timer duration corresponding to T3 being a non-silent packet. In this case, 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 playing the network sound, namely, the audio data corresponding to the network ringback tone.

[0378] 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 on this embodiment.

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

[0380] In addition, it should be noted that the scenes 2a, 2b, and 2c shown in FIG9 are three mutually exclusive and independent scenes. That is, only one of the three scenes can appear at the same time.

[0381] In addition, it should be understood that in order to implement the above functions, the terminal device includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. 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 be beyond the scope of this application.

[0382] Furthermore, it should be noted that the ringback tone playback methods provided in the above embodiments, implemented by a terminal device in actual application scenarios, can also be executed by a chip system included in the terminal device. As shown in Figure 10, the chip system 1000 may include at least one processor (such as an application processor AP and a modem) 1001 and at least one interface circuit 1002. Processor 1001 and interface circuit 1002 may be interconnected via a line. For example, interface circuit 1002 may be configured to receive signals from another device (such as a memory in the terminal device). In another example, interface circuit 1002 may be configured to send signals to another device (such as processor 1001). For example, interface circuit 1002 may read instructions stored in the memory and send the instructions to processor 1001. When the instructions are executed by processor 1001, the terminal device may execute the steps in the above embodiments. Of course, the chip system may also include other discrete components, which are not specifically limited in this embodiment of the present application.

[0383] In addition, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a terminal device, the terminal device executes the above-mentioned related method steps to implement the ringback tone playing method in the above-mentioned embodiment.

[0384] 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 executes the above-mentioned related steps to implement the ringback tone playing method in the above-mentioned embodiment.

[0385] In addition, an embodiment of the present application further provides a system on chip (SoC), which may also be referred to as a system on chip (SoC).

[0386] For example, Figure 11 shows a schematic diagram of the SoC structure. As shown in Figure 11, the SoC includes both AP and modem capabilities. The AP processes internal data in the terminal device and does not include external communication. The modem handles external communication, including making phone calls, sending text messages, and surfing the Internet.

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

[0388] 11 , illustratively, a physical channel such as a shared memory or bus is established between the AP and the Modem to implement data transmission between the AP and the Modem, such as transmission of call content, text message content, and other data.

[0389] In the example of Figure 11 , a modem is integrated into the SoC. However, in actual implementation, the modem can also exist as a separate chip and be soldered together with the SoC on the terminal device's motherboard. The following description mainly uses the embodiment shown in Figure 11 , i.e., integrating the modem into the SoC, as an example.

[0390] 11 , illustratively, a modem may include a cellular protocol stack and a cellular physical layer, wherein the cellular physical layer in the modem may communicate with a radio frequency (RF) component.

[0391] It can be understood that RF components are mainly used for processing received and transmitted signals during wireless communication.

[0392] For example, referring to FIG11 , the RF component communicates with the cellular physical layer in the modem, and can be used to receive cellular baseband digital signals, perform digital-to-analog conversion on them, and then transmit them through the antenna, as well as perform analog-to-digital conversion on the radio electromagnetic wave signals received by the antenna and then send them to the cellular baseband.

[0393] 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 on this embodiment.

[0394] In addition, it can be seen from the above description that the terminal device, computer-readable storage medium, computer program product or chip provided in 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 repeated here.

[0395] To illustrate the beneficial effects of the ringback tone playing method provided in the embodiment of the present application in detail, the following is explained by comparing it with related technologies.

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

[0397] Furthermore, according to the white paper, for a normal IMS call, when receiving a remote network media stream, i.e., an audio packet corresponding to a network ringback tone, if an 18* signaling message with the P-Early-Media message value of "Inactive" is received, the calling terminal initiates playback of the local ringback tone. However, in the ringback tone playback method provided in the embodiments of the present application, when receiving the remote network media stream, a determination is made as to whether all audio packets received within a set time are silent packets. If all are silent packets, playback of the local ringback tone is switched to the local ringback tone. Conversely, if any audio packets received within the set time are non-silent packets (i.e., audio packets capable of playing sound), the network ringback tone is prioritized, rather than immediately switching to playback of the local ringback tone upon receiving a signaling indicating a local ringback tone, as specified in the white paper.

[0398] Furthermore, it should be noted that the ringback tone playback method provided in the embodiments of this application is particularly applicable to scenarios where the calling terminal is porting its number. That is, all of the technical issues addressed by this application primarily arise in the specific network environment of number portability. Furthermore, in this scenario, the probability of all received network ringback tone audio packets being silent packets is low. The ringback tone playback method provided in the embodiments of this application can effectively resolve the aforementioned occasional issues in this specific scenario, resulting in more stable ringback tone playback and a better user experience.

[0399] 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 above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, 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, within a first duration, when all received audio packets are silence packets, 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 the signaling indicating the network ringback tone and when all received audio packets are silence packets within the first duration includes: After receiving the signaling indicating the network ringback tone, starting to count time, and the counting duration is the first duration; When receiving an audio packet sent by the network side within the first duration and the length of all 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: When not receiving an audio packet sent by the network side within the first duration, playing the local ringback tone.

5. The method according to claim 3, wherein The preset length is 19.

6. The method according to claim 1, wherein The playing the local ringback tone after receiving the signaling indicating the network ringback tone and when all received audio packets are silence packets within the first duration includes: After receiving the signaling indicating the network ringback tone, starting to count time, and the counting duration is the first duration; When receiving an audio packet sent by the network side within the first duration and the packet type of all received audio packets is a preset packet type, playing the local ringback tone.

7. The method according to claim 6, characterized in that The preset packet type is SID (COMFORT NOISE FRAME).

8. The method according to claim 1, wherein 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 initiating the INVITE signaling, 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, wherein When 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; When 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, wherein When 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; When 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 receiving the audio packet is allowed.

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

14. The method according to claim 13, characterized in that, 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, characterized in that, The method further includes: Receiving the first signaling, which 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, characterized in that, 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, characterized in that, 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 process of playing the network ringback tone, where the second signaling is the last signaling sent by 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, characterized in that, 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, wherein 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 being coupled to the processor; 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