Method for rapid response in VOIP call, electronic device, and communication system

Abstract

Embodiments of the present application disclose a method for rapid response in a VoIP call, an electronic device, and a communication system. In the method, when a calling device locally stores a network state of a called user, after the calling device initiates a call to the called user, the calling device can rapidly and accurately play a prompt tone when the called user is in an unreachable state. In such a prompt tone playback solution, low-latency and high-precision prompt tone playback at the second level can also be implemented when the network condition on the calling device side is poor, so that blind waiting of a calling user can be avoided, and user experience can be improved.

Description

Methods, electronic devices, and communication systems for rapid response in VoIP calls

[0001] This application claims priority to Chinese Patent Application No. 202510083984.2, filed on January 17, 2025, entitled “Method, Electronic Device, Communication System for Rapid Response in VoIP Calls”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to methods, electronic devices, and communication systems for rapid response in VoIP calls. Background Technology

[0003] Calls can be divided into carrier calls and Voice over Internet Protocol (VoIP) calls. Carrier calls are based on the carrier's network, commonly seen as calls over 4G networks (VoLTE). After the calling device initiates a VoLTE call to the called device through the carrier's server, the carrier server can determine if the called device is offline (e.g., switched off, airplane mode, etc.). If offline, it returns this status to the calling device, allowing the calling device to play a corresponding prompt, such as "The number you dialed is switched off" or "The number you dialed cannot be connected." If not offline, it returns the online status to the calling device, allowing it to play a ringback tone to indicate that the called device is currently reachable. This process is achieved by accessing the carrier's dedicated network. The calling device typically takes about 2 seconds to determine the network status of the called device, resulting in a short waiting time and a good user experience.

[0004] VoIP calling is a service provided by applications (APPs) in electronic devices that provide VoIP calling services. It is based on the application server corresponding to the APP, and common examples may include Changlian. TM Calls, WeChat TM Calls, FaceTime TM VoIP calls are becoming increasingly common, and if a system can provide accurate and rapid responses to callers during VoIP calls, it can significantly improve the user's VoIP call experience. Summary of the Invention

[0005] This application provides a method, electronic device, and communication system for rapid response in VoIP calls, which can quickly respond to the calling user in VoIP calls and improve the calling user's VoIP call experience.

[0006] Firstly, a method for rapid response in VoIP calls is provided. This method is applied to a communication system including a calling device and a server. The method may include: the server sending the network status of the called user to the calling device; the calling device recording the network status of the called user; the calling device, in response to initiating a VoIP call to the called user, querying the network status of the called user locally; if the calling device finds that the network status of the called user is unreachable, the calling device playing a prompt tone to indicate that the called user is in an unreachable state.

[0007] The first approach involves the calling device locally storing the called user's network status. After the calling device initiates a call to the called user, if the called user is in a state where calls cannot be made, the calling device can quickly and accurately play a prompt tone. This prompt tone playback scheme can achieve low-latency, high-precision prompt tone playback even when the calling device's network is poor, preventing the calling user from waiting blindly and improving the user experience.

[0008] Secondly, a method for rapid response in VoIP calls is provided. This method is applied to a communication system including a calling device and a server. The method may include: the server sending the network status of the called user to the calling device; the calling device recording the network status of the called user; the calling device querying the network status of the called user locally in response to initiating a VoIP call to the called user; if the calling device finds that the network status of the called user is unreachable, the calling device sending a message to the server querying the network status of the called user; if the calling device does not receive the network status of the called user returned by the server within a first time period after sending the message, the calling device playing a prompt tone to indicate that the called user is in an unreachable state.

[0009] The second method involves the calling device first querying the called user's network status from the server. If the query fails within a timeout period, the calling device uses the locally obtained network status to output a prompt tone. This ensures that even if the calling device's network is poor and fails to retrieve the result from the server, it can still use the locally obtained network status to deliver an accurate prompt tone, guaranteeing the real-time nature and accuracy of the prompt. This prevents the calling user from waiting blindly and ensures a better user experience in areas with poor network connectivity.

[0010] In conjunction with the first or second aspect, in some embodiments, the communication system further includes a called device, which is the device used by the called user to log in to the server. Before the server sends the called user's network status to the calling device, the method may further include: the called device receiving an operation to set a first permission, the first permission indicating that the calling user is allowed to obtain the called user's network status, the calling user being the user who logs in to the server through the calling device; in response to the operation to set the first permission, the called device sending the first permission information to the server. Thus, by allowing the calling user to obtain the called user's network status, the calling device can obtain the called user's network status from the server, ensuring the called user's privacy.

[0011] In conjunction with the first aspect, the second aspect, or any of the above embodiments, in some embodiments, before the server sends the network status of the called user to the calling device, the method may further include: the called device receiving an operation to set a second permission, the second permission indicating whether the calling user is allowed to initiate a VoIP call to the called user, the calling user being a user logged into the server through the calling device; in response to the operation to set the second permission, the called device sending the second permission information to the server; the server obtaining the network status of the called device; the server sending the network status of the called user to the calling device specifically includes: the server sending the network status of the called user to the calling device according to the second permission information, wherein, when the first permission indicates that the calling user is allowed to initiate a VoIP call to the called user, the network status of the called user is the network status of the called device; when the first permission indicates that the calling user is not allowed to initiate a VoIP call to the called user, the network status of the called user is an uncallable state.

[0012] In the previous implementation, when different second permissions are set on the called device, the network status of the called user sent by the server to the calling device varies. Thus, when a calling user is not allowed to initiate a VoIP call to the called user, the server does not distribute the actual network status of the called device to the calling device, but instead sends a "cannot be dialed" status to the calling device. This minimizes the possibility of the calling user initiating a VoIP call to the called user, thereby avoiding disturbing the called user.

[0013] In conjunction with the previous implementation method, in some implementation methods, the server may obtain the network status of the called device in the following two ways:

[0014] 1. In some implementations, the server includes an application server and a push server. The server obtains the network status of the called device, specifically including: the called device sending its network status to the push server; the push server sending the called device's network status to the application server; and the server sending the called user's network status to the calling device based on second-authorization information, specifically including: the application server sending the called user's network status to the calling device based on the second-authorization information. Essentially, the application server can obtain the called device's network status through the push server. A persistent connection is established between the push server and the called device, allowing for low-power acquisition of the called device's network status.

[0015] In some implementations, the called device sends its network status to the push server. Specifically, this includes: the called device detecting a network shutdown operation; and in response to the network shutdown operation, the called device first sending its network status after shutdown to the push server before shutting down the network. This ensures that the called device reports its network status to the push server.

[0016] In some implementations, before the push server sends the network status of the called device to the application server, the method further includes: the application server subscribing to the network status of the called device from the push server.

[0017] 2. The server obtains the network status of the called device, specifically including: the server receiving the network status of the called device sent by the called device.

[0018] In conjunction with the first aspect, the second aspect, or the first implementation method, the communication system further includes a first called device and a second called device. Both the first called device and the second called device are devices used by the called user to log in to the server. The first called device and the second called device are different. Before the server sends the network status of the called user to the calling device, the method further includes: the server obtaining the network status of the first called device and the second network status of the second called device; wherein, when there is a dialable status in either the first network status or the second network status, the network status of the called user is dialable; when both the first network status and the second network status are undialable, the network status of the called user is undialable.

[0019] In some embodiments, in conjunction with the first aspect, the second aspect, or any of the above implementations, the server includes an application server and a push server. The server sends the network status of the called user to the calling device, specifically including: the application server sending the network status of the called user to the calling device through the push server.

[0020] In conjunction with the first aspect, the second aspect, or any of the above embodiments, in some embodiments, before the server sends the network status of the called user to the calling device, the method further includes: the calling device receiving an operation to add the called user to the calling user's frequently used contacts, and sending a message to the server indicating that the called user has been added to the calling user's frequently used contacts; or, the calling device compiling a list of the calling user's frequently used contacts and sending the information of the frequently used contacts to the server, wherein the frequently used contacts include the called user; wherein the calling user is a user who logs into the server through the calling device. In this way, the server can send the network status of the called user to the calling device where the calling user, who is considered a frequently used contact, resides.

[0021] In conjunction with the previous implementation method, in some implementation methods, before the calling device queries the network status of the called user locally, the method further includes: the calling device determining the called user's frequently used contacts.

[0022] In conjunction with the first aspect, the second aspect, or any of the above embodiments, in some embodiments, the prompt tone is specifically used to indicate the network status of the called user as queried locally by the calling device.

[0023] In some embodiments, in conjunction with the first aspect, the second aspect, or any of the above implementation methods, the method may further include: if the calling device finds that the network status of the called user is available for dialing, then the calling device plays a ringback tone. In this way, the calling device locally stores the network status of the called user, and after the calling device initiates a call to the called user, the calling device can quickly and accurately play a ringback tone when the called user is in a dialable state.

[0024] In some embodiments, in conjunction with the first aspect, the second aspect, or any of the above implementations, the calling device has a first application installed, and the server is a server that provides services for the first application; the VoIP call to the called user specifically occurs in the first application.

[0025] Thirdly, a method for rapid response in VoIP calls is provided, characterized in that the method is applied to the calling device, and the method includes: the calling device receiving the network status of the called user sent by the server; the calling device recording the network status of the called user; the calling device, in response to initiating a VoIP call to the called user, querying the network status of the called user locally; if the network status of the called user queried by the calling device is an unreachable state, the calling device playing a prompt tone, the prompt tone being used to indicate that the called user is in an unreachable state.

[0026] The third approach involves the calling device locally storing the called user's network status. After the calling device initiates a call to the called user, if the called user is in a state where calls cannot be made, the calling device can quickly and accurately play a prompt tone. This prompt tone playback scheme can achieve low-latency, high-precision prompt tone playback even when the calling device's network is poor, preventing the calling user from waiting blindly and improving the user experience.

[0027] Fourthly, a method for rapid response in a VoIP call is provided. This method is applied to the calling device and may include: the calling device receiving the network status of the called user sent by the server; the calling device recording the network status of the called user; the calling device querying the network status of the called user locally in response to initiating a VoIP call to the called user; if the network status of the called user found by the calling device is unreachable, the calling device sending a message to the server querying the network status of the called user; if the calling device does not receive the network status of the called user returned by the server within a first time period after sending the message, the calling device playing a prompt tone to indicate that the called user is in an unreachable state.

[0028] The fourth method involves the calling device first querying the called user's network status from the server. If the query fails within a timeout period, the calling device uses the locally obtained network status to output a prompt tone. This ensures that even if the calling device's network is poor and fails to retrieve the result from the server, it can still use the locally obtained network status to deliver an accurate prompt tone, guaranteeing the real-time nature and accuracy of the prompt. This prevents the calling user from waiting blindly and ensures a better user experience in areas with poor network connectivity.

[0029] The optional implementation methods and corresponding technical effects of the third or fourth aspect can be referred to the steps performed by the calling device side in any of the first, second or above two aspects, and will not be repeated here.

[0030] Fifthly, a method for rapid response in VoIP calls is provided. This method is applied to a server and may include: the server receiving first permission information sent by the called device, the first permission indicating that the calling user is allowed to obtain the network status of the called user, the calling user being a user who logs into the server through the calling device, and the called user being a user who logs into the server through the called device; the server obtaining the network status of the called device; and the server sending the network status of the called user to the calling device according to the first permission information.

[0031] Implementing the fifth method, where the server only sends the network status of the called user to the calling device on the premise that the calling user is allowed to obtain the network status of the called user, can guarantee the privacy of the called user.

[0032] In conjunction with the fifth aspect, in some implementations, the server is an application server.

[0033] The optional implementation methods and corresponding technical effects of the fifth aspect can be referred to the steps executed on the server side in any of the first aspect, the second aspect, or both of the above aspects, and will not be repeated here.

[0034] A sixth aspect provides an electronic device comprising: a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method provided in any of the third or fourth aspects or both of the foregoing embodiments.

[0035] A seventh aspect provides a server including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the method provided as in the fifth aspect or any embodiment of the fifth aspect.

[0036] Eighthly, a communication system is provided, the communication system including a calling device and a server, the calling device being the electronic device of the sixth aspect, and the server being used to send the network status of the called user to the calling device.

[0037] In conjunction with aspect eight, in some implementations, the server is the same as the server in aspect seven.

[0038] In conjunction with the eighth aspect or any implementation thereof, in some embodiments, the communication system further includes a called device, which is a device used by a called user to log in to the server. The called device is configured to: receive an operation to set a first permission, and in response to the operation to set the first permission, send information about the first permission to the server. The first permission indicates that the calling user is allowed to obtain the network status of the called user. The calling user is a user who logs in to the server through the calling device.

[0039] In conjunction with the eighth aspect or any implementation thereof, in some embodiments, the communication system further includes a called device, the called device being configured to: receive an operation to set a second permission, and in response to the operation to set the second permission, send information about the second permission to a server, the second permission indicating whether the calling user is allowed to obtain the network status of the called user.

[0040] Combining the two implementation methods above, in some implementations, the server may obtain the network status of the called device in the following two ways:

[0041] 1. In some implementations, the server is specifically an application server, and the communication system also includes a push server. The called device is also used to send the network status of the called device to the push server, and the push server is used to send the network status of the called device to the application server.

[0042] In some implementations, the called device is specifically configured to detect the network shutdown operation, and in response to the network shutdown operation, first send the network status after network shutdown to the push server, and then shut down the network.

[0043] In some implementations, the push server is also used to receive messages from the application server regarding the network status of the subscribed called device.

[0044] 2. In some implementations, the called device is specifically used to send the network status of the called device to the server.

[0045] Ninth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method provided in the third, fourth, or fifth aspect or any of the embodiments described above.

[0046] In a tenth aspect, a computer program product is provided, the computer program product including a computer program, which, when executed by a processor, implements the method provided in the third, fourth, or fifth aspect or any of the above three aspects.

[0047] Eleventhly, a chip system is provided, the chip system including a processing circuit and an interface circuit, the interface circuit being used to receive computer instructions and transmit them to the processing circuit, the processing circuit being used to execute the computer instructions to implement the method provided in the third, fourth, or fifth aspect or any of the above three aspects. Attached Figure Description

[0048] Figure 1 is a schematic diagram of the structure of the communication system 10 provided in an embodiment of this application;

[0049] Figure 2 is a flowchart of a method for rapid response in a VoIP call provided in an embodiment of this application;

[0050] Figure 3 is a hardware structure diagram of the electronic device provided in an embodiment of this application;

[0051] Figure 4 is a software structure diagram of the electronic device provided in an embodiment of this application;

[0052] Figure 5 is a hardware structure diagram of the server provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings.

[0054] VoIP is a voice transmission technology based on IP networks that allows users to make calls over the internet, rather than traditional carrier networks. During a VoIP call, one device first converts the voice signal into data packets, which are then transmitted over the internet (such as to an application server providing VoIP services) to another device, which converts the data packets back into a voice signal. VoIP calls can include voice calls, video calls, and more.

[0055] After the calling device initiates a VoIP call to the called device, it may play a ringback tone or a prompt tone, depending on the actual situation of the called device. The ringback tone is used to inform the calling user that the called user is currently available for communication, making the calling user psychologically aware that the called user's electronic device is ringing. The ringback tone can be, for example, a broken ringing tone, such as ringing for one second and then stopping for four seconds, with a five-second cycle. Alternatively, the ringback tone can be a preset audio, such as an audio that the called user has set so that the calling user can only hear it when called. The prompt tone is used to inform the calling user that the called user is currently unavailable for communication. The prompt tone can be, for example, a voice message such as "The user you dialed cannot be connected," "The user you dialed is temporarily unavailable," or "The user you dialed is switched off," etc. Alternatively, the prompt tone may not be a voice message, but rather a busy tone containing intermittent low bass, or preset music or audio.

[0056] Some VoIP applications such as WeChat TM Currently, playing notification tones is not supported. Specifically, after the calling device initiates a VoIP call to the called device using this type of VoIP application, the calling device will continuously play a ringing tone (such as intermittent ringing, preset music, etc.) until the call times out, at which point it will symbolically play a notification tone indicating that the called user is currently offline. Thus, even if the called device is actually in a powered-off, airplane mode, do not disturb mode, or sleep mode, the calling user cannot know the specific status of the called device, resulting in a poor user experience.

[0057] Other VoIP applications, such as Changlian TMWhile it supports playing alert tones, it heavily relies on the calling device's network status. Specifically, when the calling device uses this type of VoIP application and initiates a VoIP call to the called device through the application server, it obtains the called device's network status (e.g., whether it's powered off, in airplane mode, or has its network turned off) from the application server. When the calling device detects that the called device is in an unreachable network state (e.g., powered off, in airplane mode, or with its network turned off), it will play a corresponding alert tone to inform the calling user of the called device's network status. In this process, if the calling device's network status is good, the alert tone can be played accurately within about 3 seconds after the call; if the calling device's network status is poor, it may take a long time (e.g., more than 5 or even 10 seconds) to find the called device's network status and play the alert tone, or even fail to find the called device's network status due to network packet loss, thus failing to play the alert tone and resulting in a poor user experience.

[0058] To improve the VoIP call experience for users, this application provides a method for rapid response during VoIP calls. In this method, after calling the called device, the calling device can quickly obtain the network status of the called device. If the called device is in a network unreachable state, a prompt tone can be played promptly to inform the user of the called device's network status, preventing the calling user from waiting blindly and affecting the user experience. This method provides a prompt tone playback scheme that combines real-time performance and accuracy, ensuring the reliability of the prompt tone. Even when the calling device's network is poor, it can ensure that the calling device promptly obtains the network status of the called device and quickly plays the prompt tone.

[0059] Before introducing the methods provided in the embodiments of this application, the communication system provided in the embodiments of this application will be introduced first.

[0060] Figure 1 illustrates a communication system 10 provided in an embodiment of this application.

[0061] As shown in Figure 1, the communication system 10 may include: electronic device 100, application server 200, message push server 300, and electronic device 400.

[0062] Among them, electronic devices 100 and electronic devices 400 are both smart terminal devices, such as mobile phones, tablets, desktop computers, desktop computers with touch-sensitive surfaces or touch panels, laptops, smart screens, wearable devices (such as smartwatches, smart bracelets, etc.), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, in-vehicle systems, smart headphones, game consoles, and can also be Internet of Things (IoT) devices, etc.

[0063] In this embodiment of the application, electronic device 100 initiates a VoIP call to electronic device 400. Therefore, electronic device 100 can also be referred to as calling device 100, and electronic device 400 can also be referred to as called device 400.

[0064] Both the calling device 100 and the called device 400 have the same app installed that provides VoIP calling services, such as Changlian. TM ,WeChat TM FaceTime TM Since the calling device 100 and the called device 400 may be of different brands or models, the VoIP applications installed on each may be compatible with their respective brands or models, but the functions of the VoIP applications in both are the same or similar. The calling device 100 and the called device 400 may belong to the same manufacturer or different manufacturers. The VoIP application in the calling device 100 can be a system application or a third-party application. Similarly, the VoIP application in the called device 400 can be a system application or a third-party application. Users who log in to the application server 200 through the VoIP application in the calling device 100 can be called calling users, and users who log in to the application server 200 through the VoIP application in the called device 400 can be called called users. The called users are the contacts of the calling users in the VoIP applications.

[0065] Application server 200 is a server that provides services for VoIP applications. These services may include registration, login, and further services after login (such as VoIP calling, messaging, push notifications, and money transfers). Application server 200 can associate and record the identity of each account that logs into the application server 200 through a VoIP application with the identifier of the device used for login. Application server 200 can also maintain the contacts added by each registered user, as well as the network status of some electronic devices. Application server 200 is provided and operated by the developer of the VoIP application, for example, if the VoIP application is Changlian...TM Then the application server 200 is a seamless connection. TM Provided by the developer (such as Huawei). Application server 200 can be considered a server, while the VoIP applications in calling device 100 and called device 400 can both be considered clients. Application server 200 provides the necessary services to the VoIP applications in both devices. Different VoIP applications can be configured with different application servers to provide services. A VoIP application can have a corresponding application server, and the number of these application servers can be one or more; for example, the application servers can be implemented as a server cluster.

[0066] Push Server 300 is a message push platform used to provide a message push channel for logged-in devices, delivering the latest information to various electronic devices in the form of notifications or transparent messages. These electronic devices are all devices that have integrated specific installation files or services provided by the provider of Push Server 300. For example, if Push Server 300 is provided by Huawei, it can push messages to electronic devices that have integrated Huawei Mobile Services (HMS).

[0067] In this embodiment, the calling device 100 and the called device 400 are equipped with the same VoIP application. Both VoIP applications integrate the specific installation files or services mentioned earlier. The VoIP applications on both devices can be applications developed and provided by the provider of the push server 300, or applications developed and provided by other vendors. The provider of the push server 300 provides specific mobile services, such as Huawei's HMS, which provides application program interfaces (APIs) or software development kits (SDKs) for system applications or third-party applications to integrate, allowing these applications to interact with the push server 300 through the API or SDK. The specific installation files or services integrated into the electronic devices mentioned earlier can be understood as the APIs or SDKs provided by HMS here.

[0068] Since both the calling device 100 and the called device 400 integrate the specific installation files or services mentioned earlier in their VoIP applications, the push server 300 can push messages to both devices. Specifically, the calling user can use their account in the VoIP application to log in to the application server 200 (the server) through the VoIP application (client) on the calling device 100. This process can also be referred to as the calling user logging into the application server 200. After logging into the application server 200, the application server 200 can obtain the push token from the calling device 100. Based on this push token, the application server 200 can push messages to the calling device 100 through the push server 300. The principle of the application server 200 pushing messages to the called device 400 through the push server 300 is similar and will not be elaborated here.

[0069] The push server 300 can establish persistent connections with electronic devices that have the specific installation files or services mentioned above installed, and interact with these electronic devices through these persistent connections. The persistent connection can be a Transmission Control Protocol (TCP) connection or a Fast UDP (Web Socket over QUIC) internet connection based on the Web Socket protocol. After the push server 300 establishes a persistent connection with the electronic device, the persistent connection will persist as long as the electronic device is powered on, enabling fast and low-latency communication. In this embodiment, the push server 300 can establish persistent connections with both the calling device 100 and the called device 400, and interact with them through these persistent connections. Specifically, the push server 300 can receive the network status synchronized by the called device 400 through the persistent connection with the called device 400, and can also synchronize the network status of the called device 400 to the calling device through the persistent connection with the calling device. For example, the called device 400 synchronizes its device status with the push server 300 via a long-lived connection in just 0.5 round-trip times (RTTs), and the push server 300 synchronizes its network status with the calling device 100 in just 0.5 RTTs. Furthermore, by using a long-lived connection between the push server 300 and both the calling device 100 and the called device 400 to achieve network status synchronization, there is no need to establish additional channels for network status synchronization, and no additional power consumption is required for either the calling device 100 or the called device 400.

[0070] The push server 300 also provides a push interface for interacting with the application server 200. In this embodiment, the application server 200 can obtain the real-time status of the called device 400 from the push server 300 through the push interface, and send push messages to the electronic devices (such as the calling device 100) of the users who have subscribed to the network status of the called users in the VoIP application.

[0071] In this embodiment, if the calling user has subscribed to the network status of the called user, the calling device 100 can obtain the network status of the called device 400 through the long connection described above. When the calling user initiates a VoIP call to the called user from the calling device 100, the calling device 100 plays the corresponding prompt tone based on the locally stored network status of the called device 400, without needing to interact with the application server 200 to obtain the network status of the called device 400, thus saving the calling user waiting time. In other embodiments, after the calling device 100 initiates a VoIP call, it can query the application server 200 for the network status of the called device 400. If it cannot find the network status within a certain period of time, it will then use the locally stored network status of the called device 400 to play the corresponding prompt tone. This ensures that the prompt tone can be played accurately and promptly even when the network on the calling device 100 side is poor.

[0072] The communication system 10 shown in Figure 1 is merely an example. In a specific implementation, the communication system 10 may include devices with more or fewer functions, and may also combine or split some devices. For example, the communication system 10 may not include the push server 300. The VoIP application in the called device 400 can directly obtain the network status and synchronize the network status to the application server 200. The application server 200 can also directly synchronize the network status of the called device 400 to the VoIP application in the calling device 100 without going through the push server 300. As another example, the calling user can use the same account to log in to the application server 200 through the VoIP application on multiple devices, so the number of calling devices 100 can be multiple. Similarly, the called user can use the same account to log in to the application server 200 through the VoIP application on multiple devices, so the number of called devices 400 can also be multiple.

[0073] For details regarding the specific functions of each device in the communication system 10 and the specific implementation of the operations performed by each device, please refer to the relevant descriptions in the subsequent method embodiments; these will not be elaborated upon here.

[0074] Figure 2 is a flowchart of a method for fast response in VoIP calls provided in an embodiment of this application.

[0075] The method shown in Figure 2 is implemented based on the communication system 10 of Figure 1. As shown in Figure 2, the method may include the following steps:

[0076] Phase 1: S101-S105, State Subscription

[0077] S101, the calling device 100 receives an operation from the calling user in the VoIP application to add the called user as a frequently used contact.

[0078] The called user is a contact of the calling user in the VoIP application. S101 can be that the calling user further adds the called user, who has already been added as a contact, to their frequently used contacts, or the calling user adds the newly added contact to their frequently used contacts when adding contacts. The calling user can be a contact of the called user in the VoIP application, or they can not be a contact of the called user in the VoIP application, for example, the calling user may have been deleted by the called user. This application embodiment does not impose any restrictions on this.

[0079] The calling user can log in to the application server 200 using their account in the VoIP application on the calling device 100. This establishes a corresponding relationship between the calling user and the calling device 100. After the calling user logs in to the application server 200 on the calling device 100, and the called user is already a contact of the calling user, the calling user can add the called user as a frequently used contact in the VoIP application on the calling device 100. The calling device 100 can respond to this operation by executing steps S102-S103, thereby adding the called user as a frequently used contact of the calling user in the VoIP application.

[0080] The VoIP application mentioned in S101 and subsequent steps in Figure 2 can also be referred to as the first application.

[0081] S102, the calling device 100 records the called user as a frequently used contact in the VoIP application.

[0082] The calling device 100 can record the called user as a frequently used contact in the local VoIP application, which is equivalent to tagging the called user as a frequently used contact.

[0083] S103, the calling device 100 sends a message to the application server 200 to add the called user as a frequently used contact of the calling user.

[0084] S104, Application server 200 records the called user's frequently used contacts as the calling user's information.

[0085] Application server 200 can add the called user as a frequently used contact to the locally recorded information of the calling user, which is equivalent to tagging the called user as a frequently used contact.

[0086] In some implementations, S103-S104 can be executed first. After the application server 200 records the called user as the caller's frequently used contact, the application server 200 notifies the calling device that the recording is successful. Then the calling device 100 executes S102. This ensures that the information on the terminal side and the server side remains consistent.

[0087] S105, Application server 200 subscribes to push server 300 for the network status of the called user's device.

[0088] Specifically, application server 200 subscribes to push server 300 the network status of all devices used by users recorded as frequent contacts. This is not limited to the calling user; whenever any other user adds frequent contacts in the VoIP application, application server 200 subscribes to push server 300 for the network status of the devices used by these frequent contacts. This allows application server 200 to subsequently obtain the network status of these frequent contacts' devices from push server 300. The device used by a frequent contact refers to the electronic device used by the frequent contact when logging into application server 200. This device may change depending on the frequent contact's usage habits, and the number of devices used by a frequent contact may be multiple when they log into application server 200 simultaneously through multiple devices.

[0089] Application server 200 can subscribe to the network status of the called user's device by sending a subscription message to push server 300. This subscription message may carry the called user's account or other identifier in the VoIP application, or it may carry an identifier of the electronic device the called user has logged into.

[0090] The above-described S101-S105 are merely one implementation method for subscribing to the network status of the called user. In this application embodiment, this objective can also be achieved in other ways. Several alternative implementation methods to S101-S105 are given below:

[0091] In some implementations, the VoIP application in the calling device 100 can automatically count the calling user's frequently used contacts, record the counted contacts locally, and send the information to the application server 200. The application server 200 then subscribes to the push server 300 for the network status of the devices containing these frequently used contacts. This eliminates the need for the calling user to manually add frequently used contacts via S101. The calling user's frequently used contacts can be the contacts the calling user contacts most frequently, or contacts whose contact frequency exceeds a preset value. Over time, the calling user's frequently used contacts in the VoIP application may change. The calling device 100 can count the calling user's frequently used contacts periodically, or update the frequently used contacts when a change is detected. In other implementations, the step of counting the calling user's frequently used contacts can also be performed by the application server 200. After counting the frequently used contacts, the application server 200 can also notify the calling device 100 of the results. This application does not impose any limitations on this.

[0092] In some implementations, the application server 200 can also subscribe to the network status of all the devices of the calling user's contacts from the push server 300, so that the calling user does not need to manually add frequently used contacts, nor does it need to count frequently used contacts based on the frequency of contact.

[0093] In some implementations, unlike S101-S104 where the called user is added to the calling user's frequently used contacts to subscribe to the network status of the called user's device, the calling user can directly subscribe to the network status of the called user's device without adding the called user as a frequently used contact. For example, in S101, the calling device 100 can receive a user operation from the calling user to subscribe to the network status of the called user's device, and then execute the relevant operations for subscribing to the network status of the called user's device in S102-S104. Of course, subsequent embodiments of this application will exemplify this solution by using the method of adding the called user to the calling user's frequently used contacts in S101-S104 to subscribe to the network status of the called user's device.

[0094] In some implementations, S101-S103 can also be executed by other electronic devices logged in by the calling user. In this way, after receiving the notification message sent by the other electronic device, the application server 200 can know that the called user has added the calling user as a frequently used contact. When the calling user logs in on the calling device 100, the application server 200 will synchronize this message to the calling device 100.

[0095] Phase Two: S106-S119, State Synchronization

[0096] S106, The called device 400 receives the operation from the called user in the VoIP application to set the permissions for each contact to obtain the network status of the called user.

[0097] The called user can use their VoIP application account to log in to the application server 200 through the VoIP application in the called device 400. This establishes a corresponding relationship between the called user and the called device 400.

[0098] First, the called device 400 needs to obtain permission granted by the called user to access the network status and upload it to the push server 300. In some implementations, the called device 400 may display an application-level privacy statement when the called user first logs into the application server 200 through a VoIP application on the device, prompting the called user to agree to the called device 400 accessing and uploading the network status to the network device. In other implementations, the called device 400 may display a system-level privacy statement upon first power-on, prompting the user to agree to the called device 400 accessing and uploading the network status to the network device. Regardless of the implementation, if the user agrees, the called device 400 will have the permission to access and upload the network status to the push server 300.

[0099] After the called device 400 obtains the aforementioned permissions, in some embodiments, the called device 400 can further receive permission from the called user, set in the VoIP application, for each contact to access the called user's network status. In some embodiments, the called user can set the permission for each contact to access the called user's network status through the settings entry of the VoIP application in the called device 400. For example, the called user can set a whitelist in the called device 400, which may include one or more of the called user's contacts. Contacts in the whitelist are those with permissions, while other contacts are those without permissions. In other embodiments, the called user can also access the information page of each contact and set the permission for that contact to access the called user's network status individually. For example, the called user can choose whether to allow that contact to access the called user's network status on a contact's information page; if the called user selects "yes," then that contact does not have permission to access the called user's network status; if the called user selects "no," then that contact has permission to access the called user's network status. In this embodiment, the permissions set by the called user may allow the calling user to obtain its network status or may not allow the calling user to obtain its status, depending on the called user's choice, and this application does not limit this. After receiving the user's permission setting operation in S106, the called device 400 can store the permission information corresponding to the operation locally.

[0100] In this embodiment of the application, the permission set by the called user for the calling user in S106 can be referred to as the first permission. This first permission indicates whether the calling user is allowed to obtain the network status of the called user.

[0101] S107, the called device 400 sends the permission information set by the called user in S106 to the application server 200.

[0102] After receiving the permission information, the application server 200 can store it locally. This permission information indicates which contacts of the called user have permission to obtain their network status, and / or which contacts do not have permission to obtain their network status.

[0103] In some other implementations, steps S106-S107 may not be executed. For example, after the called device 400 obtains the permission granted by the called user to obtain the network status and upload the network status to the push server 300, it can default to all contacts of the called user in the VoIP application having the permission to obtain the called user's network status. In this way, the called user does not need to make any further settings in the VoIP application; the application server 200 can also default to all contacts of the called user having the permission to obtain the called user's network status.

[0104] S108, The called device 400 receives the permission set by the called user in the VoIP application for each contact to initiate VoIP calls to the called user.

[0105] If the called user is willing to respond to a VoIP call initiated by a contact, that contact can be configured to have permission to initiate VoIP calls to the called user; if the called user is not willing to respond to a VoIP call initiated by a contact, that contact can be configured not to have permission to initiate VoIP calls to the called user.

[0106] In some implementations, the called user can configure the permissions for each contact to initiate VoIP calls through the settings entry of the VoIP application in the called device 400. For example, the called user can set a "Do Not Disturb" list in the called device 400. The "Do Not Disturb" list can include one or more of the called user's contacts. Contacts on the "Do Not Disturb" list are those without permissions, while other contacts are those with permissions. In other implementations, the called user can also access the information page of each contact and individually configure the permissions for each contact to initiate VoIP calls. For example, the user can enable "Do Not Disturb" for some contacts, or block or delete some contacts. Blocked or deleted contacts will not have the permission to initiate VoIP calls to the called user.

[0107] In this embodiment, the permissions set by the called user can either allow the calling user to initiate VoIP calls to the called user, or disallow the calling user to initiate VoIP calls to the called user, depending on the called user's choice. This application does not limit this. After receiving the user's permission setting operation in S108, the called device 400 can store the permission information corresponding to the operation locally.

[0108] In this embodiment of the application, the permissions set by the called user for the calling user in S108 can be referred to as second permissions. These first permissions indicate whether the calling user is allowed to initiate a VoIP call to the called user.

[0109] S109, the called device 400 sends the permission information set by the called user in S108 to the application server 200.

[0110] After receiving the permission information, the application server 200 can store it locally. This permission information indicates which contacts of the called user have the permission to initiate VoIP calls to the called user, and / or which contacts do not have the permission to initiate VoIP calls to the called user.

[0111] In some other implementations, S108-S109 may not be executed. For example, the called device 400 may default to all contacts of the called user in the VoIP application having the permission to initiate VoIP calls to the called user, so that the called user does not need to set permissions in the VoIP application; the application server 200 may also default to all contacts of the called user having the permission to initiate VoIP calls to them.

[0112] The order of S106-S107 and S108-S109 mentioned above is not restricted.

[0113] The order of steps S106-S109 in phase one and phase two (the optional steps can be executed or not) is not restricted.

[0114] S110, the called device 400 obtains its own network status and reports the network status to the push server 300.

[0115] In this embodiment, after the called user allows some or all contacts on the called device 400 to obtain their network status, the called device 400 can obtain its own network status and report the network status to the push server 300 based on the long connection established with the push server 300. In S110, the process of the called device 400 obtaining and reporting its network status can be executed by the system, without needing to be executed through the VoIP application.

[0116] In this embodiment, the network status refers to the state of the network affecting the VoIP call of the device, mainly including the network status affecting the device's network. The network status is specifically determined by the hardware status and / or software settings of the electronic device. For example, the network status may indicate one or more of the following: whether the device is powered off, whether it is in airplane mode, whether it is in do-not-disturb mode, whether it is in sleep mode, whether the network is turned off, whether it is connected to a network, whether a network is found, etc. All of the above network states can be detected by the called device 400. Among these, airplane mode, do-not-disturb mode, and sleep mode mentioned above refer to the system modes of the electronic device. When powered off, in airplane mode, with the network turned off, not connected to a network, or not finding a network, the electronic device cannot communicate with other devices through the network. When in do-not-disturb mode or sleep mode, the electronic device can communicate with other devices through the network, but will not display notification messages (such as VoIP call notifications) to disturb the user.

[0117] In this embodiment, the called device 400 can report its current network status or the network status it is about to change to to the push server 300 after detecting a change or impending change in its own status. In some embodiments, the called device 400 can report the impending network status to the push server 300 when it detects that the network status is about to deteriorate. For example, after receiving an operation that triggers shutdown, airplane mode, do-not-disturb mode, sleep mode, or network shutdown, the called device 400 can reserve several hundred milliseconds before responding to the operation by reporting the network status of shutdown, airplane mode, or network shutdown to the push server 300, so that the push server 300 can promptly know the network status of the called device 400 before performing the operation such as shutdown, airplane mode, do-not-disturb mode, sleep mode, or network shutdown.

[0118] In other implementations, the called device 400 may also periodically detect its own network status and report the detected network status to the push server 300.

[0119] The called device 400 also has a network status indicating whether it is online or whether it has been online for an extended period (e.g., exceeding a preset duration). This network status is detected by the push server 300 and does not require the called device 400 to report it. Here, "online" refers to the online connection between the called device 400 and the push server 300. Specifically, the push server 300 can determine whether the called device 400 is online by whether a connection has been established with it. Alternatively, the called device 400 can periodically send heartbeat packets to the push server 300 based on a long-lived connection, and the push server 300 can determine whether the called device 400 has been online for an extended period based on these heartbeat packets.

[0120] S111, after the push server 300 learns the network status of the called device 400, it determines whether the network status of the called device 400 has been subscribed to.

[0121] Steps S110-S111 and S105 are implemented in combination.

[0122] In some implementations, if the subscription message sent by the application server 200 to the push server 300 in S105 carries the identifier (e.g., account) of the called user in the VoIP application, then in S110, the called device 400 will report the network status to the push server 300 and also report the identifier of the called user in the VoIP application. In this way, in S111, the push server 300 can determine whether the network status of the called device 400 has been subscribed by comparing the identifier of the called user.

[0123] In some other implementations, if the subscription message sent by the application server 200 to the push server 300 in S105 carries the identifier of the electronic device that the called user has logged into, then in S110, the called device 400 will report its network status to the push server 300 and also report its own identifier. In this way, in S111, the push server 300 can determine whether the network status of the called device 400 has been subscribed by comparing the identifier of the called device 400.

[0124] If the result of S111 is yes, then proceed with the next steps; if the result of S111 is no, then end the process.

[0125] S112, push server 300 sends the network status of called device 400 to application server 200.

[0126] In some implementations, push server 300 can synchronize the network status of called device 400 to application server 200 via a callback push interface. When sending the network status of called device 400, push server 300 can simultaneously send the identifier of called device 400 or the identifier of called user to application server 200.

[0127] After receiving the network status of the called device 400, the application server 200 can also record the network status of the called device 400 locally.

[0128] S113, Application server 200 determines the user whose called user is recorded as a frequently used contact.

[0129] After receiving the network status of the called device 400, application server 200 first determines that the user who logged into application server 200 using the called device 400 is the called user. Then, based on the frequently added contacts that one or more users have locally recorded, application server 200 can find out which users have added the called user as a contact. Alternatively, based on the contacts that one or more users have locally recorded and subscribed to regarding the network status, application server 200 can find out which users have subscribed to the network status. As mentioned in S104 above, application server 200 records the called user as a frequently added contact of the calling user; therefore, in S113, application server 200 determines that the users who record the called user as a frequently added contact include the calling user.

[0130] S114, Application server 200 determines whether each user who has added the called user as a frequently used contact has the permission to obtain the network status of the called user.

[0131] This step can refer to the permission information stored in S107 by application server 200.

[0132] If the result of S114 is yes, then proceed to the next steps S115-S119; if the result of S114 is no, then proceed to the next steps S115-S119.

[0133] Let's take the example of adding the called user as a frequently used contact, including the caller:

[0134] If the calling user has permission to obtain the network status of the called user, the application server 200 can send the network status of the called user to the calling device 100 where the calling user is located through the push server 300.

[0135] If the calling user does not have permission to obtain the network status of the called user, the application server 200 will not send the network status of the called user to the calling device 100 where the calling user is located through the push server 300.

[0136] Of course, if the called user is recorded as a frequently used contact, other users will also be included, and the judgment steps in the above two paragraphs will also be performed on other users.

[0137] S115, the application server 200 determines whether each user who has added the called user as a frequently used contact and has the permission to obtain the network status of the called user has the permission to initiate a VoIP call to the called user.

[0138] This step can refer to the permission information stored in S109 by application server 200.

[0139] S116, Application server 200 determines the network status of the called user based on the judgment result in S115.

[0140] The following example illustrates the situation using users who have added the called user as a frequently used contact and have permission to access the called user's network status, including the calling user:

[0141] If the calling user has the authority to initiate a VoIP call to the called user, the application server 200 can use the network status of the called device 400 received in S112 as the network status of the called user, and send the network status of the called user to the calling device 100 where the calling user is located through the push server 300.

[0142] If the calling user does not have the permission to initiate a VoIP call to the called user—for example, if the calling user adds the called user to a do-not-disturb list, blocks, or deletes them—then the application server 200 will treat the "unreachable state" as the called user's network state and send this network state (i.e., "unreachable state") to the calling device 100 where the calling user is located via the push server 300. Instead of sending the network state of the called device 400 as the called user's network state to the calling device 100 via the push server 300, the application server 200 will not send it to the calling device 100. This is because when the called user does not grant the calling user permission to initiate VoIP calls to them, it means the called user does not want to receive VoIP calls initiated by the calling user. The application server 200 will not distribute the actual network state of the called device 400 to the calling device 100, but instead transmits the "unreachable state" to the calling device 100, thus minimizing the possibility of the calling user initiating a VoIP call to the called user. The "unreachable status" here is transmitted to the calling device 100 because the called user does not allow the calling user to initiate a VoIP call to them (e.g., the called user has enabled Do Not Disturb for the calling user, or the called user has blocked or deleted the calling user). This indicates that the called user does not want to be disturbed by the calling user.

[0143] As can be seen from the above two paragraphs, when the calling user has the permission to obtain the network status of the called user, the application server 200 will also determine the specific network status of the called user sent to the calling device 100 based on whether the calling user has the permission to initiate a VoIP call to the called user. If other users have added the called user as a frequently used contact and have the permission to obtain the called user's network status, the judgment steps in the above two paragraphs will also be executed for these other users.

[0144] For example, in S114-S116, suppose users A, B, C, D, and E have all added user F as a frequently contacted person. User F does not allow user A to access their network status, but allows users B and E to access their network status. However, user F has enabled "Do Not Disturb" for user B, blocked user C, and deleted user D. Then, after receiving the network status of user F's electronic device, application server 200 will not send user F's network status to user A's device. Instead, it will send a "Cannot Call" status to user B, user C, and user D's respective devices, and send the network status of user E's electronic device. The process of application server 200 sending network status to each device can be implemented using push server 300.

[0145] The following steps will be described using the example of application server 200 sending the network status of the called user to the calling device 100 where the calling user is located. Of course, if the user that application server 200 has determined to have recorded the called user as a frequently used contact and has the permission to obtain the network status of the called user also includes other users, then the subsequent operations performed on the calling device (such as subsequent steps S116-S118) will also be performed on the devices where other users are located.

[0146] S117, application server 200 sends a push background message to push server 300. This push background message is used to send the network status of the called user to the device where the calling user is located.

[0147] After the application server 200 determines in S114 that the called user has been added as a frequently used contact and has the permission to obtain the called user's network status (e.g., the calling user), it can query the identifier of the electronic device currently logged into by the calling user (i.e., the calling device 100) locally, and then send a push background message to the push server 300. This push background message carries the identifier of the calling device 100, the identifier of the called user, and the network status of the called user. The specific network status of the called user can be found in the descriptions in S115-S116.

[0148] S118, push server 300 sends a push background message to the VoIP application in calling device 100. This push background message is used to notify the calling device 100 of the network status of the called user.

[0149] After receiving the push background message sent by the application server 200, the push server 300 locates the calling device 100 based on the identifier of the calling device 100 in the message, and sends a push background message carrying the identifier of the called user and the network status of the called user to the calling device 100 through a long connection.

[0150] The push server 300 can also carry the identifier of the VoIP application in the push background message sent by the application server 200. This allows the push server 300 to identify the VoIP application corresponding to the application server 200. In this way, even if the calling device 100 has multiple VoIP applications installed, the push server 300 can still send push background messages to the corresponding VoIP applications.

[0151] In S117-S118, the application server 200 synchronizes the network status of the called user to the calling device 100 through the push server 300. In this way, regardless of whether the calling device 100 is running a VoIP application, the calling device 100 can start the VoIP application and obtain the network status of the called user.

[0152] If there are multiple calling devices 100, in S117 the application server 200 can send multiple background push messages to the push server 300 to send the network status of the called user to multiple devices where the calling user is located. Of course, the application server 200 can also send only one background message carrying the identifiers of multiple calling devices 100, and in S118 the push server 300 can also send push background messages to multiple calling devices 100.

[0153] In some implementations, if the application server 200 sends the "unreachable status" as the network status of the called user to the device where the user does not have the permission to initiate a VoIP call to the called user via the push server 300, and if it receives the network status of the called device 400 sent by the push server 300 multiple times, it is not necessary to send the "unreachable status" of the called user to these devices every time. Instead, the application server 200 can send the network status of the called device as the network status of the called user to these devices only after these devices have the aforementioned permissions. This avoids the application server 200 frequently sending the "unreachable status" of the called user to these devices when they do not have the aforementioned permissions.

[0154] S119, The calling device 100 records the network status of the called user through a VoIP application.

[0155] The calling device 100 can associate and record the called user's identifier and the corresponding network status of the called user. After receiving a new network status of the called user, the calling device 100 can overwrite the previously recorded network status of the called user, or it can choose not to overwrite the previously recorded network status, but only delete the network status that exceeds a preset time, or delete the oldest network status while storing a maximum of a preset number of network statuses of the called user.

[0156] In Phase 1 and Phase 2 described above, the called device 400 reports its network status to the push server 300 through a long connection, and the calling device 100 learns about the called user's network status through the long connection with the push server 300. The long connection enables fast and low-latency network status synchronization.

[0157] Phase Three: S120-S129, VoIP Calls

[0158] S120, the calling device 100 receives an operation to initiate a VoIP call to the called user in a VoIP application.

[0159] The VoIP call can be either a VoIP voice call or a VoIP video call; there are no restrictions. The calling device 100 can receive an order to initiate a VoIP call to the called user while displaying the chat page between the calling and called users in a VoIP application.

[0160] S121, the calling device 100 determines whether the called user is a frequently contacted user.

[0161] If, in Phase 1 above, the calling device 100 directly subscribes to the network status of other users without adding frequently used contacts, then S121 can be replaced by the calling device 100 determining whether it has subscribed to the network status of the called user. Of course, if, in Phase 1, the application server 200 directly subscribes to the network status of all contacts of the calling user, then S121 can be skipped, and subsequent steps can be executed directly.

[0162] If the judgment result of S121 is negative, the calling device 100 can respond to the operation received in S120 by querying the network status of the called user from the application server 200, and performing further operations based on the queried network status. For example, it can play a ringback tone if the called user's network status is found to be dialable, or play a prompt tone if the called user's network status is found to be undialable. The definitions of dialable and undialable states can be found in the relevant explanation under S122 below. The actions of the calling device 100 querying the application server 200 for the called user's network status and performing further operations based on the queried network status can be found in subsequent steps S126-S129.

[0163] If the determination result of S121 is yes, that is, if the called user is a frequent contact of the calling user, or if the calling user has subscribed to the network status of the called user, the calling device 100 may execute subsequent steps S122-S128 in response to the operation received in S120. In some other embodiments, S121 may not be executed, and S122 may be executed directly after S120.

[0164] S122, the calling device 100 queries the network status of the called user locally through a VoIP application.

[0165] In some implementations, if the network status of the called user recorded locally is only one, the calling device 100 can query the network status of that single called user. If the network status of the called user recorded locally is multiple, the calling device 100 can find the latest (e.g., within ten minutes) network status of the called user, or find the latest preset number (e.g., 5) network statuses of the called user, and then aggregate the network statuses of these multiple called users, using the resulting comprehensive network status as the network status of the queried called user. The definition of aggregation can be found later and will not be elaborated here. Based on the introduction of S114-S119 in stage two above, the information stored in the calling device 100 may have the following situations:

[0166] 1. When the calling user does not have the authority to obtain the network status of the called user, the calling device 100 does not store the network status of the called user.

[0167] 2. When the calling user has the authority to obtain the network status of the called user, but does not have the authority to initiate a VoIP call to the called user, the calling device 100 stores the called user's "uncallable status".

[0168] 3. When the calling user has the authority to obtain the network status of the called user and also has the authority to initiate a VoIP call to the called user, the calling device 100 stores the specific network status of the called user, such as whether it is powered off, whether it is in airplane mode, whether it is in do-not-disturb mode, whether it is in sleep mode, whether it is in network off, whether it is connected to the network, whether it has found the network, etc.

[0169] If the information stored by the calling device 100 is as described in the first scenario above, then the calling device 100 cannot find the called user's network status locally. In this case, the calling device 100 queries the application server 200 for the called user's network status and performs further operations based on the retrieved network status. For example, it may play a ringback tone if the called user's network status is found to be dialable, or play a prompt tone if the called user's network status is found to be undialable. The definitions of dialable and undialable status can be found in the relevant explanations in the following paragraphs.

[0170] If the information stored by the calling device 100 is as described in the second or third case above, the calling device 100 can query the network status of the called user locally. In this case, the calling device 100 can execute S123.

[0171] S123, if the calling device 100 finds the network status of the called user locally, it determines whether the network status of the called user is available for dialing.

[0172] If the information stored locally by the calling device 100 is as described in the second scenario above, then the calling device 100 can query the called user's "unreachable status" locally and consider the called user to be in an unreachable status. This unreachable status is due to the called user's subjective disallowance of the calling user from initiating a VoIP call (e.g., the called user has enabled Do Not Disturb for the calling user, or the called user has blocked or deleted the calling user).

[0173] If the calling device 100 stores information locally as described in scenario 3 above, then the calling device 100 can query the specific network status of the called user locally. In this case, the calling device can further determine whether the queried network status of the called user is a dialable state. Here, dialable state refers to the state where the called device 400 objectively (e.g., hardware conditions and / or software settings) can respond to VoIP calls initiated by other devices. Undialable state refers to the state where the called device 400 objectively (e.g., hardware conditions and / or software settings) cannot respond to VoIP calls initiated by other devices. When the calling device 100 queries the network status of the called user, the called user is considered dialable if the network status is one of the following specific network statuses: powered on, not in airplane mode, not in do-not-disturb mode, not in sleep mode, network enabled, connected to the network, network found, online, or online for an extended period. When the calling device 100 queries the network status of the called user and finds that the network status is one of the following specific network statuses, the called user is considered unreachable: phone off, in airplane mode, in do-not-disturb mode, in sleep mode, network off, not connected to network, no network found, offline, or offline for an extended period of time.

[0174] In this embodiment of the application, the unreachable state can also be referred to as unreachable, unanswerable, or uncallable, and no limitation is made to the state name here.

[0175] If the calling device 100 finds that the called user's network status is available for dialing, then it can execute S124. If the called user's network status is unavailable, the calling device 100 has two strategies to achieve fast and accurate prompt tone playback. Strategy one is S125, and strategy two is S126-S129. In practice, either S125 or S126-S129 can be implemented.

[0176] S124, if the network status of the called user is found to be available for dialing, the calling device 100 sends a VoIP call request to the called user to the application server 200 and plays a ringback tone to indicate that the calling user is in a call.

[0177] In this embodiment of the application, after the calling device 100 finds that the network status of the called user is available for dialing locally, it can play the ringback tone. Compared with querying the application server 200 to find the callable status of the called user before playing the ringback tone, the ringback tone can be played faster, making the VoIP call experience of the calling user better.

[0178] The VoIP call request sent by the calling device 100 to the called user can carry the called user's identifier, which is used by the application server 200 to locate the called user's device and initiate a call to that device after receiving the VoIP call request. If the called user logs into the application server 200 through a VoIP application on the called device 400, that is, if a VoIP application process exists on the called device 400 and the called device 400 establishes a VoIP application connection with the application server 200 through this process, then the application server 200 can initiate a call to the called device 400 through this connection. If the called user does not log in to the application server 200 through the VoIP application on the called device 400 (e.g., the VoIP application process on the called device 400 is terminated, the user logs out on the called device 400, or the VoIP application on the called device 400 is not running in the foreground or background), that is, there is no VoIP application connection between the application server 200 and the called device 400, the application server 200 can first send a VoIP call message to the push server 300. Then, the push server 300 instructs the called device 400 to start the VoIP application through a long connection with the called device 400 and sends a VoIP call to it. After receiving the instruction from the push server 300, the called device 400 can start the VoIP application without waiting for the user.

[0179] In the case where the called user is not logged into the application server 200, after receiving the VoIP call message sent by the application server 200, the push server 300 can identify the target device and target application of the VoIP call message, but does not need to parse the specific data in the message.

[0180] In the latter case where the called user is not logged into the application server 200, when the called user sees the VoIP call notification on the called device 400, since the VoIP application in the called device 400 has been instructed to be started by the push server 300, the called device 400 can save the time of starting the VoIP application and directly enter the details page of the VoIP call after the called user clicks on the call notification. This can speed up the process of the called user answering the VoIP call.

[0181] S125, if the calling device 100 finds that the network status of the called user is unreachable, the calling device 100 will play a corresponding prompt tone to inform the user that the called user is currently in an unreachable network status.

[0182] In some implementations, the prompt tone played by the calling device 100 may be a voice message, which may include a somewhat vague prompt such as "The user you dialed cannot be reached" or "The user you dialed is temporarily unavailable." If the calling device 100 can determine the specific network status of the called user, the voice message may also include the specific network status of the called user, such as "The user you dialed is switched off," "The user you dialed is in airplane mode," "The user you dialed is in do-not-disturb mode," "The user you dialed is in sleep mode," "The user you dialed has disconnected from the network," or "The user you dialed has a poor network connection," etc. The voice message may also include suggestions for the calling user, such as "Please try again later."

[0183] In other embodiments, the prompt tone played by the calling device 100 may not be voice, but rather a preset piece of music or audio, or a busy tone containing intermittent bass, to inform the calling user that the called user cannot be dialed. If the calling device 100 obtains the specific network status of the called user, the calling device 100 may also play different music or audio according to the specific network status of the called user to inform the calling user of the specific network status of the called user.

[0184] In some implementations, after S120 but before the calling device 100 detects that the called user's network status is unreachable, the calling device 100 may play a ringback tone. After detecting that the called user's network status is unreachable, it may play a corresponding prompt tone. In other implementations, after S120, the calling device 100 can quickly detect that the called user's network status is unreachable, and the time in between is negligible. Therefore, the calling device 100 can directly play the corresponding prompt tone without playing a ringback tone.

[0185] In some implementations, after S120, the calling device 100 may also display a VoIP call page provided by the VoIP application to indicate that the calling user is currently calling the called user. After the prompt tone is played in S125, the display of the VoIP call page may be stopped, thereby indicating that the calling user is no longer calling the called user.

[0186] In this embodiment, if the calling device 100 finds the called user's network status locally to be "unreachable," the calling device 100 can also send a VoIP call request to the called device 400 through the application server 200. The called device 400 can then receive and display the VoIP call request when objective conditions permit, allowing the called user to know which contacts have initiated VoIP calls to them. In some implementations, if the calling device 100 finds the called user's network status locally to be "unreachable" due to the called user's subjective disallowance of VoIP calls (e.g., the called user has enabled "Do Not Disturb" for the caller, or has blocked or deleted the caller), the called device 400 can block the VoIP call request, or the application server 200 can block the VoIP call request, or the calling device 100 can directly send a VoIP call request to the called device 400 without going through the application server 200.

[0187] As shown in S125, in Strategy 1, when the calling device 100 finds that the called user's network status is unreachable, it can broadcast a precise prompt tone to inform the calling user that the called user is currently unreachable without interacting with the application server 200, thus preventing the calling user from waiting blindly. This strategy can achieve low-latency, precise prompt tone broadcasting, ensuring the real-time nature and accuracy of the prompt tone.

[0188] S126, if the network status of the called user is found to be unreachable, the calling device 100 sends a message to the application server 200 to query the network status of the called user.

[0189] The message sent by the calling device 100 to the application server 200 can carry the called user's identifier, used to query the network status of the called user from the application server 200. After receiving the message, the application server 200 can query the network status of the called user. The query methods can include the following two: 1. Referring to S112, the application server 200 has local records of the network status of the called device 400. Therefore, the application server 200 can first query the device logged in by the called user (i.e., called device 400) from the locally recorded information, and then query the network status of called device 400. 2. The application server 200 can first query the device logged in by the called user (i.e., called device 400), and then query its network status through the VoIP application connection with called device 400. In both of the above cases, the network status of called device 400 queried by the application server 200 is the network status of the called user, and the application server 200 can send the query result to the calling device 100.

[0190] The network status of the called user queried by the application server 200 is a series of specific network statuses, such as whether the device is powered off, whether it is in airplane mode, whether it is in do-not-disturb mode, whether it is in sleep mode, whether the network is turned off, whether it is connected to the network, and whether the network is found.

[0191] The network status of the called user returned by the application server 200 to the calling device 100 is more up-to-date and accurate than the network status stored locally by the calling device 100.

[0192] S127, after sending the message in S126, the calling device 100 determines whether it has received the network status of the called user returned by the application server 200 within a certain period of time.

[0193] This duration can be set as needed, such as 3 seconds, 5 seconds, etc., and there is no limitation here. This duration can be referred to as the first duration.

[0194] S128, if the judgment result of S127 is yes, then the calling device 100 performs the corresponding action according to the network status of the called user returned by the application server 200.

[0195] The network status of the called user returned by the application server 200 may be either dialable or undialable.

[0196] After receiving the network status of the called user returned by the application server 200, the calling device 100 first determines whether the network status of the called user is dialable. This action can be referred to the third case in S123. If the network status of the called user is dialable, the calling device 100 sends a VoIP call request to the called user to the application server 200 and plays a ringback tone to indicate that the calling user is in a call. This action can be referred to S124. If the network status of the called user returned by the application server 200 is not dialable, the calling device 100 plays a corresponding prompt tone to indicate that the called user is currently in a dialable network state. This action can be referred to S125.

[0197] S129, If the judgment result of S127 is negative, the calling device 100 uses the uncallable status of the called user found locally in S122 to perform the corresponding action.

[0198] If the judgment result of S127 is negative, the calling device 100 will play a corresponding prompt tone to inform the user that the called user is currently in a network state where calls cannot be made. This action can be referred to as S125.

[0199] As shown in S126-S129, in Strategy Two, the calling device 100 first queries the application server 200 for the called user's network status. If the query is successful, the latest network status of the called user is guaranteed. If the query fails within a timeout period, the locally obtained network status of the called user is used to output the prompt tone. In this way, even if the calling device 100's network is poor and cannot obtain a result from the application server 200, the locally obtained network status of the called user can still be used to broadcast an accurate prompt tone, ensuring the real-time nature and accuracy of the prompt tone, preventing the calling user from waiting blindly, and guaranteeing a better user experience under poor network conditions.

[0200] Other embodiments of the method for rapid response during a VoIP call provided in this application

[0201] In some implementations, in S122, if the calling device 100 finds the network status of the called user locally and the record time of the network status of the called user has not been too long, that is, the network status of the called user is still valid, then the subsequent steps of S122 can be executed; if the record time of the network status of the called user found by the calling device 100 locally has been too long, that is, the network status of the called user has expired, then the current network status of the called user can be directly determined to be uncallable, or the calling device 100 can also query the network status of the called user from the application server 200.

[0202] In this embodiment, there can be multiple called devices 400. If there are multiple called devices 400, each called device 400 can execute S106-S110, and the permissions and network status of each called device 400 can be different. If there are multiple called devices 400, the push server 300 can obtain the network status of multiple called devices 400, and in S112, send the network status of all multiple called devices 400 to the application server 200.

[0203] In some implementations, the application server 200 can aggregate the network states of the multiple called devices 400 to obtain a comprehensive network state, and send the comprehensive network state as the network state of the called user to the calling device 100 through S117-S118. In this way, the network state of the called user queried locally by the calling device 100 in S122 is the comprehensive network state.

[0204] In other implementations, the application server 200 may not aggregate the network states of multiple called devices 400, but instead send the network state of each called device 400 received as the network state of the called user through S117-S118 to the calling device 100. In this way, the calling device 100 can record the network states of multiple called users in S119, and aggregate the network states of the multiple called users in S122, and use the resulting comprehensive network state as the network state of the queried called user.

[0205] Specifically, the principle for aggregating multiple network states can be as follows: if one or more of the network states of multiple called devices 400 are in a dialable state, then the overall network state of the called user is dialable; if all the network states of multiple called devices 400 are in a non-dialable state, then the overall network state of the called user is non-dialable. In a specific example, if there are two called devices 400 in the communication system, these two called devices 400 can be a first called device and a second called device.

[0206] When there are multiple called devices 400, after the calling device 100 receives the operation to initiate a VoIP call to the called user in S120, it can initiate VoIP calls to these multiple called devices 400 through the application server 200. After receiving the VoIP call, the multiple called devices 400 can perform corresponding operations according to their own settings; different called devices 400 can have different settings. For example, suppose device A initiates a VoIP call to devices B and C where the called user is located. Device B has its system Do Not Disturb mode enabled, while device C does not. Then, after receiving the operation to initiate a VoIP call to the called user, device A will play a ringback tone to indicate that the called user is currently available for dialing, and then initiate VoIP calls to devices B and C. After receiving a VoIP call, device B does not output any notification messages (such as no notification tone or vibration information), and only outputs a VoIP call notification after exiting Do Not Disturb mode; after receiving a VoIP call, device C will immediately respond to the VoIP call and output a VoIP call notification.

[0207] In this embodiment of the application, the number of calling devices 100 can also be multiple. If the number of calling devices 100 is multiple, each calling device 100 can execute stage three.

[0208] In some implementations, when the application server 200 determines the network status of the called user in S116, if the calling user has the authority to initiate a VoIP call to the called user, the application server 200 can analyze the network status of the called device 400 received in S112, determine whether the network status of the called device 400 is dialable or not, and determine the result as the network status of the called user. Here, the implementation of the application server 200's determination of whether the network status of the called device 400 is dialable or not can be referred to in the description of case 3 in S123. This is equivalent to advancing the steps performed by the calling device 100 in S123 to the application server 200, thereby reducing the workload of the calling device 100 and reducing the amount of information exchanged between the application server 200 and the calling device 100.

[0209] In some implementations, the communication system 10 may not include a push server 300. The calling device 100 and the called device 400 can achieve rapid response during VoIP calls through the application server 200. For example, the called device 400 can grant network status access permissions to the VoIP application. This allows the VoIP application in the called device 400 to report its network status to the application server 200 via the application connection between the VoIP application and the application server 200 after detecting a change or impending change in its own status, without needing to go through the push server 300. Alternatively, the application server 200 can directly send the called user's network status to the VoIP application in the calling device 100 via the application connection with the VoIP application in the calling device 100, without needing to go through the push server 300. Thus, the steps performed by the push server 300 in the aforementioned embodiments can all be performed by the application server 200; the interaction between the push server 300 and the application server 200 in the aforementioned embodiments can all be replaced by interaction between different modules within the application server 200, or even eliminated altogether.

[0210] The method for rapid response during a VoIP call provided in this application embodiment allows the calling device 100 to quickly and accurately play a prompt tone when the called user is in an unreachable state after initiating a call to the called user, provided that the calling device 100 has locally stored the network status of the called user. This prompt tone playback scheme achieves low latency and high accuracy even when the network on the calling device 100 side is poor. Compared to the scheme where the VoIP application queries the application server 200 for the called user's network status before playing the prompt tone, this method has lower latency, and it also has lower latency than the operator's VoLTE scheme.

[0211] The method provided in this application can be applied to VoIP applications, including but not limited to Changlian. TM ,WeChat TM FaceTime TM Furthermore, this method can be applied not only to VoIP calls but also to carrier calls (such as VoLTE calls). For example, by replacing the application server 200 in the method shown in Figure 2 with a carrier server, and replacing the VoIP application installed on the calling device 100 with a calling application, the calling device 100 can quickly and accurately play a prompt tone if the called user's network status is unreachable after initiating a VoLTE call to the carrier server.

[0212] Figure 3 is a hardware structure diagram of the electronic device provided in an embodiment of this application.

[0213] The electronic device can be either the calling device 100 mentioned above, or the called device 400 mentioned above.

[0214] As shown in Figure 3, the electronic device may include: a processor 110, an external memory interface 120, an internal memory 121, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, a camera 193, a display screen 194, etc. The sensor module 180 may include a touch sensor 180K, etc.

[0215] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0216] Processor 110 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0217] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0218] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0219] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via a USB interface. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0220] 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 to power the processor 110, internal memory 121, display 194, camera 193, and wireless communication module 160, etc.

[0221] The wireless communication function of electronic devices can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0222] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0223] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in electronic devices. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0224] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0225] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, frequency modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0226] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the electronic device to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

[0227] Electronic devices achieve display functions through GPUs, displays (194), and application processors.

[0228] Electronic devices can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0229] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0230] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the electronic device. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0231] Electronic devices can implement audio functions such as music playback and recording through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors.

[0232] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0233] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. Electronic devices can listen to music or make hands-free calls through the speaker 170A.

[0234] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When an electronic device answers a phone call or voice message, the receiver 170B can be brought close to the ear to hear the voice.

[0235] The microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0236] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0237] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of the electronic device, in a different position than display screen 194.

[0238] When the calling device 100 is implemented as shown in Figure 3, the internal memory 121 stores a computer program that implements the steps of the VoIP call-response method provided in this embodiment of the present application, executed on the calling device 100 side. The processor 110 can be used to execute the computer program to implement the method provided in this embodiment of the present application on the calling device 100 side. Antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, and other modules can be used to realize communication between the calling device 100 and the application server 200 and push server 300. Speaker 170A, receiver 170B, etc., can be used to play prompt tones, and headphone jack 170D, etc., can be used to transmit prompt tones to the headset.

[0239] When the called device 400 is implemented as shown in Figure 3, the internal memory 121 stores a computer program on the called device 400 side that implements the method for fast VoIP call response provided in the embodiments of this application. The processor 110 can be used to execute the computer program to implement the method provided in the embodiments of this application on the called device 400 side. Antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, and other modules can be used to realize communication between the called device 400 and the application server 200 and push server 300.

[0240] The electronic device provided in this application embodiment can run an operating system (OS). This operating system can be various operating systems used in industry, such as operating systems developed based on OpenHarmony, like HarmonyOS; or other operating systems such as Android™, iOS mobile operating systems; it can also be various open-source operating systems or their derivatives, such as Linux OS, and other embedded operating systems; or it can be a future new operating system, such as an AI operating system based on artificial intelligence. An operating system is a set of interconnected system software programs that manage and control the operation of electronic devices, utilize and run hardware and software resources, and provide public services to organize user interaction. In electronic devices, the operating system connects downwards to the physical devices at the hardware layer and provides a runtime environment for application software upwards.

[0241] An operating system typically includes a kernel layer, a middleware layer, and an application layer. The application layer includes applications, which can include system applications and third-party applications. The middleware layer includes a suite of software providing various services to application developers, or frameworks providing services such as databases, multimedia, and graphics, or capabilities such as distributed scheduling and system scaling. For example, the middleware layer may include a framework layer and / or a system service layer. The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The system service layer includes the system's core capabilities, providing services to applications through the framework layer. The kernel layer is the layer between hardware and software. The kernel layer may include hardware drivers and the operating system kernel. In addition to providing hardware drivers, the kernel layer also supports functions such as memory management and system process management.

[0242] The electronic devices we use in our daily lives come in various types and forms, and are applied in a wide range of scenarios. Therefore, based on the different forms and functions of electronic devices, different application scenarios, and different user needs, the operating systems used in these devices may also differ. The basic functions implemented by the electronic device provided in this application can be implemented using a general-purpose operating system or a dedicated operating system. To more clearly illustrate the implementation of the embodiments of this application under a specific operating system, Figure 4 shows the architecture of HarmonyOS. Those skilled in the art can deduce the implementation of the embodiments of this application under other specific operating systems, such as Android™.

[0243] As shown in Figure 4, the software architecture of an electronic device can be divided into several layers. In some embodiments, from bottom to top, these layers are: kernel layer, system service layer, framework layer, and application layer. Layers communicate with each other through software interfaces. System functions can be tailored, added, or combined at the subsystem level in different device deployment scenarios, and each subsystem can also be tailored, added, or combined at the functional level.

[0244] The kernel layer includes the following modules:

[0245] The Kernel Abstraction Layer (KAL) provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including but not limited to process / thread management, memory management, file system, network management, and peripheral device management.

[0246] Kernel Subsystem: Supports the selection of a suitable OS kernel for different resource-constrained devices, including but not limited to Linux kernel, HarmonyOS kernel, LiteOS (Lite Operating System), etc.

[0247] Driver Subsystem: The driver framework is the foundation for the open system hardware ecosystem, providing unified peripheral access capabilities and a framework for driver development and management. The driver framework includes: display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, etc.

[0248] The system service layer comprises the core capabilities of the system, providing services to applications through the framework layer. This layer includes, but is not limited to, the following subsystems:

[0249] The system's basic capability subsystem set provides fundamental capabilities for the operation, scheduling, and migration of distributed applications across multiple devices. This set may include distributed soft bus, distributed data management, distributed task scheduling, and Ark multi-language runtime; it may also include multi-modal input subsystem, graphics subsystem, security subsystem, and AI business subsystem.

[0250] Basic software service subsystem set: provides public and general software services; the basic software service subsystem set may include event notification subsystem, telephone service subsystem, multimedia subsystem, etc.

[0251] Enhanced software service subsystem suite: Provides differentiated enhanced software services for different devices; the enhanced software service subsystem suite may include smart screen proprietary business subsystem, wearable proprietary business subsystem, IoT proprietary business subsystem, etc.

[0252] Hardware service subsystem set: Provides hardware services; the hardware service subsystem set may include location service subsystem, user IAM (Identity and Access Management) subsystem, wearable proprietary hardware service subsystem, biometric identification, IoT proprietary hardware service subsystem, etc.

[0253] Distributed task scheduling enables distributed service management (discovery, synchronization, registration, and invocation), supporting remote startup, remote invocation, remote connection, and migration of applications across devices.

[0254] Distributed data management enables data synchronization, data storage, data sharing, and data access across all scenarios and devices.

[0255] The distributed soft bus provides communication-related capabilities for seamless interconnection between multiple devices, including: WLAN service capabilities, Bluetooth service capabilities, soft bus, inter-process communication RPC (Remote Procedure Call), and StarFlash communication capabilities.

[0256] Ark Multilingual Runtime is a unified compilation runtime platform designed to support the joint compilation and execution of multiple programming languages ​​and multiple chip platforms.

[0257] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The framework layer includes: the ArkUI framework (which provides a complete infrastructure for UI development of system applications, including UI functions such as components, layouts, animations, and interactive events, as well as a real-time interface preview tool), the user application framework, and the Ability framework (an Ability is a lightweight application; the Ability framework schedules and manages the operation and lifecycle of Abilities). Different devices may have different operating systems, and the APIs they support may also differ.

[0258] The HarmonyOS API is a series of open capabilities provided to support HarmonyOS application development. The HarmonyOS API can be set at the framework layer or independently of the framework layer. The HarmonyOS API includes the Audio API (audio service), Push API (push service), and Account API (account service), among others.

[0259] Applications can include system apps and extended / third-party apps. System apps can include the desktop, control bar, settings, contacts, phone, camera, etc., while extended / third-party apps can include social apps, travel apps, etc.

[0260] The input management module manages system input, such as touchscreen input. After receiving input events from input devices like displays, it distributes these events to appropriate target modules, such as application windows. In one embodiment, the input management module can be a multi-modal input subsystem in HarmonyOS. This subsystem integrates input from multiple dimensions. Specifically, it receives device input events, such as those from keyboards, mice, touchscreens, and touchpads, based on the kernel subsystem and driver framework. After normalizing and standardizing the input events, it distributes them to the ArkUI framework. The ArkUI framework then encapsulates the events and forwards them to the application, or distributes the events to the application through other interfaces.

[0261] The graphics subsystem mainly includes UI components, layout, animation, fonts, input events, window management, rendering, and drawing modules. The graphics service provides graphics rendering and display output functions, and internally, through the rational utilization of system hardware resources, it provides a smooth and efficient display experience.

[0262] Figure 5 is a hardware structure diagram of the server provided in an embodiment of this application.

[0263] The server can be the application server 200 in the communication system 10 shown in Figure 1, or the push server 300 in the communication system 10 shown in Figure 1.

[0264] As shown in Figure 5, the server may include: one or more processors 510, memory 520, communication interface 530, transmitter 550, receiver 560, coupler 570, and antenna 580. These components can be connected via bus 540 or other means; Figure 5 illustrates a bus connection as an example.

[0265] Communication interface 530 can be used for communication between the server and other communication devices. Specifically, communication interface 530 can be a 3G communication interface, a Long Term Evolution (LTE) (4G) communication interface, a 5G communication interface, a WLAN communication interface, a WAN communication interface, etc. Not limited to wireless communication interfaces, the server can also be configured with a wired communication interface 530 to support wired communication; for example, the backhaul link between the server and other servers can be a wired communication connection.

[0266] In some embodiments of this application, transmitter 550 and receiver 560 can be considered as a wireless modem. Transmitter 550 can be used to transmit signals output by processor 510. Receiver 560 can be used to receive signals. In the server, the number of transmitters 550 and receivers 560 can be one or more. Antenna 580 can be used to convert electromagnetic energy in a transmission line into electromagnetic waves in free space, or to convert electromagnetic waves in free space into electromagnetic energy in a transmission line. Coupler 570 can be used to split mobile communication signals into multiple paths and distribute them to multiple receivers 560. Understandably, the antenna 580 of the server can be implemented as a large-scale antenna array.

[0267] The memory 520 is coupled to the processor 510 and is used to store various software programs and / or multiple sets of instructions. Specifically, the memory 520 may include high-speed random access memory and may also include non-volatile memory, such as one or more disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

[0268] The memory 520 can store an operating system (hereinafter referred to as the system), such as uCOS, VxWorks, RTLinux, or other embedded operating systems. The memory 520 can also store a network communication program, which can be used to communicate with one or more other devices.

[0269] It should be noted that the server shown in Figure 5 is only one implementation of the embodiment of this application. In actual applications, the server may include more or fewer components, which is not limited here.

[0270] When the application server 200 is implemented as shown in Figure 5, the memory 520 stores a computer program on the application server 200 side that implements the steps of the method for fast response during a VoIP call provided in the embodiments of this application. The processor 510 can be used to execute the computer program to implement the method provided in the embodiments of this application on the application server 200 side. The communication interface 530, transmitter 550, receiver 560, coupler 570, and antenna 580, etc., can be used to realize communication between the application server 200 and the push server 300, the calling device 100, and the called device 400.

[0271] When the push server 300 is implemented as shown in Figure 5, the memory 520 stores a computer program that implements the steps of the method for fast response during a VoIP call provided in this embodiment of the present application, executed on the push server 300 side. The processor 510 can be used to execute the computer program to implement the method provided in this embodiment of the present application on the push server 300 side. The communication interface 530, transmitter 550, receiver 560, coupler 570, and antenna 580, etc., can be used to realize communication between the push server 300 and the application server 200, the calling device 100, and the called device 400.

[0272] It should be understood that each step in the above method embodiments can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0273] This application also provides an electronic device that may include a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the method performed by the calling device 100 or the called device 400 as described in any of the above embodiments.

[0274] This application also provides a server, which may include a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method executed on the application server 200 or push server 300 side as in any of the above embodiments.

[0275] This application also provides a chip system, which includes a processing circuit and an interface circuit. The interface circuit is used to receive computer instructions and transmit them to the processing circuit. The processing circuit is used to run the computer instructions to implement the method executed by the calling device 100, the called device 400, the application server 200, or the push server 300 in any of the above embodiments.

[0276] This application also provides a chip system including at least one processor for implementing the methods executed by the calling device 100, the called device 400, the application server 200, or the push server 300 in any of the above embodiments. In one possible design, the chip system further includes a memory for storing program instructions and data, the memory being located within or outside the processor.

[0277] A chip system can consist of chips or include chips and other discrete components.

[0278] Optionally, there may be one or more processors in the chip system. The processor can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0279] Optionally, the chip system may contain one or more memories. These memories may be integrated with the processor or disposed separately; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0280] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0281] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method executed by the calling device 100, the called device 400, the application server 200, or the push server 300 in any of the above embodiments.

[0282] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method executed by the calling device 100, the called device 400, the application server 200, or the push server 300 as described in any of the above embodiments.

[0283] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0284] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0285] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0286] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0287] The terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0288] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.

Claims

1. A method for rapid response in VoIP calls, characterized in that, The method is applied to a communication system including a calling device and a server, and the method includes: The server sends the network status of the called user to the calling device. The calling device records the network status of the called user; The calling device responds to initiating a VoIP call to the called user by querying the network status of the called user locally on the calling device. If the calling device finds that the network status of the called user is unreachable, the calling device will play a prompt tone to indicate that the called user is in an unreachable state.

2. A method for rapid response in VoIP calls, characterized in that, The method is applied to a communication system including a calling device and a server, and the method includes: The server sends the network status of the called user to the calling device; The calling device records the network status of the called user; The calling device responds to initiating a VoIP call to the called user by querying the network status of the called user locally on the calling device. If the calling device finds that the network status of the called user is unreachable, the calling device sends a message to the server to query the network status of the called user. If the calling device does not receive the network status of the called user from the server within a first time period after sending the message, the calling device will play a prompt tone to indicate that the called user is in an unreachable state.

3. The method according to claim 1 or 2, characterized in that, The communication system further includes a called device, which is the device used by the called user to log in to the server. Before the server sends the network status of the called user to the calling device, the method further includes: The called device receives an operation to set a first permission, the first permission indicating that the calling user is allowed to obtain the network status of the called user, the calling user being a user who logs into the server through the calling device; In response to the operation of setting the first permission, the called device sends the information of the first permission to the server.

4. The method according to any one of claims 1-3, characterized in that, Before the server sends the called user's network status to the calling device, the method further includes: The called device receives an operation to set a second permission, which indicates whether the calling user is allowed to initiate a VoIP call to the called user. The calling user is a user who logs into the server through the calling device. In response to the operation of setting the second permission, the called device sends the second permission information to the server; The server obtains the network status of the called device; The server sends the called user's network status to the calling device, specifically including: The server sends the network status of the called user to the calling device based on the information of the second permission. When the second permission indicates that the calling user is allowed to initiate a VoIP call to the called user, the network status of the called user is the network status of the called device. When the second permission indicates that the calling user is not allowed to initiate a VoIP call to the called user, the network status of the called user is an uncallable state.

5. The method according to claim 4, characterized in that, The server includes an application server and a push server. The server obtains the network status of the called device, specifically including: the called device sending its network status to the push server; and the push server sending the network status of the called device to the application server. The server sends the network status of the called user to the calling device according to the information of the second permission, specifically including: the application server sending the network status of the called user to the calling device according to the information of the second permission.

6. The method according to claim 5, characterized in that, The called device sends its network status to the push server, specifically including: The called device detected the operation of turning off the network; In response to the network shutdown operation, the called device first sends the network status after network shutdown to the push server, and then shuts down the network.

7. The method according to claim 5 or 6, characterized in that, Before the push server sends the network status of the called device to the application server, the method further includes: The application server subscribes to the network status of the called device from the push server.

8. The method according to claim 4, characterized in that, The server obtains the network status of the called device, specifically including: the server receiving the network status of the called device sent by the called device.

9. The method according to any one of claims 1-3, characterized in that, The communication system further includes a first called device and a second called device, both of which are devices used by the called user to log in to the server. The first called device and the second called device are different. Before the server sends the network status of the called user to the calling device, the method further includes: The server obtains the network status of the first called device and the second network status of the second called device. Specifically, when either the first network state or the second network state is in a dialable state, the called user's network state is dialable; when both the first network state and the second network state are in a non-dialable state, the called user's network state is non-dialable.

10. The method according to any one of claims 1-9, characterized in that, The server includes an application server and a push server. The server sends the network status of the called user to the calling device, specifically including: The application server sends the network status of the called user to the calling device through the push server.

11. The method according to any one of claims 1-10, characterized in that, Before the server sends the called user's network status to the calling device, the method further includes: The calling device receives the operation of adding the called user to the calling user's frequently used contacts, and sends a message to the server to add the called user to the calling user's frequently used contacts; or, The calling device counts the calling user's frequently used contacts and sends the information of the frequently used contacts to the server. The frequently used contacts include the called user. The calling user is the user who logs into the server through the calling device.

12. The method according to claim 11, characterized in that, Before the calling device locally queries the network status of the called user, the method further includes: The calling device determines that the called user is a frequently contacted user of the calling user.

13. The method according to any one of claims 1-12, characterized in that, The prompt tone is specifically used to indicate the network status of the called user as queried locally by the calling device.

14. The method according to any one of claims 1-13, characterized in that, The method further includes: If the calling device finds that the network status of the called user is available for dialing, the calling device will play a ringback tone.

15. The method according to any one of claims 1-14, characterized in that, The network status indicates one or more of the following: whether the device is powered off, whether it is in airplane mode, whether it is in do-not-disturb mode, whether it is in sleep mode, whether the network is turned off, whether it is connected to a network, and whether a network has been found.

16. The method according to any one of claims 1-15, characterized in that, The calling device has a first application installed, and the server is a server that provides services to the first application; The VoIP call to the called user specifically occurs in the first application.

17. A method for rapid response in a VoIP call, characterized in that, The method is applied to a calling device, and the method includes: The calling device receives the network status of the called user sent by the server; The calling device records the network status of the called user; The calling device responds to initiating a VoIP call to the called user by querying the network status of the called user locally on the calling device. If the calling device finds that the network status of the called user is unreachable, the calling device will play a prompt tone to indicate that the called user is in an unreachable state.

18. A method for rapid response in a VoIP call, characterized in that, The method is applied to a calling device, and the method includes: The calling device receives the network status of the called user sent by the server; The calling device records the network status of the called user; The calling device responds to initiating a VoIP call to the called user by querying the network status of the called user locally on the calling device. If the calling device finds that the network status of the called user is unreachable, the calling device sends a message to the server to query the network status of the called user. If the calling device does not receive the network status of the called user from the server within a first time period after sending the message, the calling device will play a prompt tone to indicate that the called user is in an unreachable state.

19. The method according to claim 17 or 18, characterized in that, The server is an application server, and the calling device receives the network status of the called user, specifically including: The calling device receives the network status of the called user sent by the application server through the push server.

20. The method according to any one of claims 17-19, characterized in that, Before the calling device receives the network status of the called user, the method further includes: The calling device receives the operation of adding the called user to the calling user's frequently used contacts, and sends a message to the server to add the called user to the calling user's frequently used contacts; or, The calling device counts the calling user's frequently contacted contacts and sends the information of the frequently contacted contacts to the server. The frequently contacted contacts are a preset number of contacts with the highest contact frequency, or contacts with a contact frequency exceeding a preset number of times, and the frequently contacted contacts include the called user. The calling user is the user who logs into the server through the calling device.

21. The method according to claim 20, characterized in that, In response to the first operation, before the calling device locally queries the network status of the called user, the method further includes: The calling device determines that the called user is a frequently contacted user of the calling user.

22. The method according to any one of claims 17-21, characterized in that, The prompt tone is specifically used to indicate the network status of the called user as queried locally by the calling device.

23. The method according to any one of claims 17-22, characterized in that, The method further includes: If the calling device finds that the network status of the called user is available for dialing, the calling device will play a ringback tone.

24. The method according to any one of claims 17-23, characterized in that, The network status indicates one or more of the following: whether the device is powered off, whether it is in airplane mode, whether it is in do-not-disturb mode, whether it is in sleep mode, whether the network is turned off, whether it is connected to a network, and whether a network has been found.

25. The method according to any one of claims 17-24, characterized in that, The calling device has a first application installed, and the server is a server that provides services to the first application; The VoIP call to the called user specifically occurs in the first application.

26. A method for rapid response in a VoIP call, characterized in that, The method is applied to a server, and the method includes: The server receives information about the first permission sent by the called device. The first permission indicates that the calling user is allowed to obtain the network status of the called user. The calling user is a user who logs into the server through the calling device, and the called user is a user who logs into the server through the called device. The server obtains the network status of the called device; The server sends the network status of the called user to the calling device based on the information of the first permission.

27. The method according to claim 26, characterized in that, Before the server sends the network status of the called user to the calling device, the method further includes: The server receives second permission information sent by the called device, the second permission indicating whether the calling user is allowed to initiate a VoIP call to the called user; The server sends the network status of the called user to the calling device, specifically including: The server sends the network status of the called user to the calling device according to the information of the second permission. When the second permission indicates that the calling user is allowed to initiate a VoIP call to the called user, the network status of the called user is the network status of the called user; when the second permission indicates that the calling user is not allowed to initiate a VoIP call to the called user, the network status of the called user is an uncallable state.

28. The method according to claim 27, characterized in that, The server is an application server, and the server obtains the network status of the called device, specifically including: The application server receives the network status of the called device through the push server.

29. The method according to claim 28, characterized in that, Before the application server receives the network status of the called device through the push server, the method further includes: The application server subscribes to the network status of the called device from the push server.

30. The method according to claim 27, characterized in that, The server obtains the network status of the called device, specifically including: the server receiving the network status of the called device sent by the called device.

31. The method according to any one of claims 26-30, characterized in that, The server is an application server. The server sends the network status of the called user to the calling device according to the first permission information. Specifically, the application server sends the network status of the called user to the calling device through a push server according to the first permission information.

32. The method according to any one of claims 26-31, characterized in that, Before the server sends the network status of the called user to the calling device based on the information of the first permission, the method further includes: The server receives a message from the calling device indicating that the called user has been added as a frequently used contact of the calling user. or, The server receives information on frequently used contacts compiled by the calling device, including the called user.

33. The method according to any one of claims 26-32, characterized in that, The network status indicates one or more of the following: whether the device is powered off, whether it is in airplane mode, whether it is in do-not-disturb mode, whether it is in sleep mode, whether the network is turned off, whether it is connected to a network, and whether a network has been found.

34. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored on the memory, wherein the processor executes the computer program to implement the method as described in any one of claims 17-25.

35. A server, characterized in that, include: A memory, a processor, and a computer program stored on the memory, wherein the processor executes the computer program to implement the method as described in any one of claims 26-33.

36. A communication system, characterized in that, The communication system includes a calling device and a server. The calling device is the electronic device as described in claim 31, and the server is used to send the network status of the called user to the calling device.

37. The communication system according to claim 36, characterized in that, The server is the server described in claim 35.

38. The communication system according to claim 36 or 37, characterized in that, The communication system further includes a called device, which is the device used by the called user to log in to the server. The called device is used to: receive an operation to set a first permission, and in response to the operation to set the first permission, send the information of the first permission to the server. The first permission indicates that the calling user is allowed to obtain the network status of the called user. The calling user is a user who logs in to the server through the calling device.

39. The communication system according to any one of claims 36-38, characterized in that, The communication system further includes a called device, which is configured to: receive an operation to set a second permission, and in response to the operation to set the second permission, send information about the second permission to the server, wherein the second permission indicates whether the calling user is allowed to obtain the network status of the called user.

40. The communication system according to claim 38 or 39, characterized in that, The server is specifically an application server, and the communication system also includes a push server. The called device is further configured to send its network status to the push server, and the push server is configured to send the network status of the called device to the application server.

41. The communication system according to claim 40, characterized in that, The called device is specifically used to detect the operation of shutting down the network, and in response to the operation of shutting down the network, first sends the network status after shutting down the network to the push server, and then shuts down the network.

42. The communication system according to claim 40 or 41, characterized in that, The push server is also used to receive messages from the application server subscribing to the network status of the called device.

43. The communication system according to claim 38 or 39, characterized in that, The called device is specifically used to send its network status to the server.

44. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the method as described in any one of claims 17-33.

45. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 17-33.

46. ​​A chip system comprising a processing circuit and an interface circuit, the interface circuit being configured to receive computer instructions and transmit them to the processing circuit, the processing circuit being configured to execute the computer instructions to implement the method as described in any one of claims 17-33.

Images