A call method, a call system and an electronic device

Abstract

Embodiments of the present application apply to the field of communication technology, and provide a call method, a call system and an electronic device. The electronic device is a calling electronic device. In response to a call initiation operation of a user, the calling electronic device can initiate a call request to a calling side network device by using a first SIP message in a first mobile communication network. The first SIP message includes a plurality of media stream types, and the plurality of media stream types include a target media stream type. Then, in the case of call failure, the calling electronic device can re-initiate a call request to the calling side network device by using a second SIP message in the first mobile communication network. The second SIP message is not completely the same as the media stream types and / or call parameters of the media stream types included in the first SIP message. In the present application, the probability of call degradation or abnormal call interruption can be reduced, and the call experience of the user can be ensured.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a call method, a call system, and an electronic device. Background Technology

[0002] With the continuous development of communication technology, some electronic devices (such as mobile phones) have begun to support real-time text (RTT) calling. When RTT calling is enabled, the receiver can read the text instantly as the sender types it, without waiting for the sender to trigger a sending command, thus improving the real-time performance of text transmission.

[0003] However, RTT calling is not yet widespread, and there may be situations where electronic devices or network devices do not support RTT calling. This can lead to abnormal situations such as call degradation or call interruption when the calling and called electronic devices establish an RTT call, thus affecting the user's calling experience. Summary of the Invention

[0004] This application provides a call method, a call system, and an electronic device to reduce the probability of call degradation or abnormal call interruption when initiating a call of a target media stream type, such as an RTT call, thereby ensuring the user's call experience.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, a call method is provided, applied to a calling electronic device. In this method, in response to a user's call initiation operation, the calling electronic device can initiate a call request to a calling network device in a first mobile communication network using a first SIP message. The first SIP message includes multiple media stream types, including a target media stream type. Subsequently, in the event of a call failure, the calling electronic device can re-initiate a call request to the calling network device in the first mobile communication network using a second SIP message. The second SIP message contains media stream types and / or call parameters for the media stream types that are not entirely identical to those included in the first SIP message.

[0007] The target media stream type can be a media stream type in a call that is not widely supported by the current electronic device or mobile network device. For example, the target media stream type can be text, and the call initiation operation is an operation used to trigger the calling electronic device to initiate an RTT call to the called electronic device.

[0008] In this embodiment, if the call fails when the first SIP message used in the initial call includes a target media stream type, it may be due to the calling network device not supporting the target media stream type or its corresponding call parameters. Therefore, the calling electronic device can adjust the media stream type in the first SIP message and re-initiate a call request to the calling network device using the adjusted first SIP message. In other words, the calling electronic device can re-initiate a call request to the calling network device using a second SIP message that is not entirely identical to the media stream type and / or call parameters included in the first SIP message, thereby achieving call renegotiation. In this way, the media stream type and corresponding call parameters in the adjusted second SIP message may be supported by the calling network device, enabling the calling electronic device to conduct calls in the first mobile communication network without needing to achieve call connection through call degradation. In other words, by re-initiating a call request to the calling network device using the second SIP message, it is possible to ensure that the call can proceed under the first mobile communication network as much as possible, reducing the occurrence of call degradation or abnormal call interruption due to network device not supporting the media stream type, improving the success rate of device calls, and thus improving the user's call experience.

[0009] In one possible implementation of the first aspect, before the calling electronic device re-initiates a call request to the calling network device, the method further includes: the calling electronic device receiving a first response message sent by the calling network device. The first response message is used to indicate call failure.

[0010] In this embodiment of the application, the calling electronic device can determine that the call has failed based on the first response message sent by the calling side network device, thereby ensuring that the calling electronic device can know in a timely manner whether the call was successful and can re-negotiate according to the actual situation, thereby improving the success rate of the device's call and improving the user's call experience.

[0011] In another possible implementation of the first aspect, before the calling electronic device re-initiates a call request to the calling network device, the method further includes: the calling electronic device receiving a second response message sent by the calling network device. The second response message indicates that the calling network device does not support the call function corresponding to the target media stream type.

[0012] In this embodiment, the calling electronic device can determine, based on the second response message sent by the calling network device, that the call failure is due to the calling network device not supporting the call function corresponding to the target media stream type. This enables the calling electronic device to adjust the streaming media type and / or call parameters in the SIP message in a timely manner and re-initiate a call request to the calling network device, thereby realizing the renegotiation of the device call, improving the success rate of the device call, and thus improving the user's call experience.

[0013] In one possible implementation of the first aspect, the media stream type included in the second SIP message is a portion of the multiple media stream types included in the first SIP message.

[0014] In this embodiment, considering that call failure may be caused by the calling network device not supporting the target media stream type or corresponding call parameters, the calling electronic device can use a portion of the media stream type in the first SIP message as the media stream type in the second SIP message to ensure the call can proceed within the first mobile communication network as much as possible. This allows the media stream type and corresponding call parameters in the second SIP message to be supported by the calling network device, thereby reducing the occurrence of call degradation or abnormal call interruption due to network device incompatibility with certain media stream types, improving call quality, and enhancing the user's call experience.

[0015] In one possible implementation of the first aspect, the media stream type included in the second SIP message is obtained by deleting a portion of the media stream types from the multiple media stream types included in the first SIP message.

[0016] In this embodiment, considering that call failure may be caused by the calling network device not supporting the target media stream type or corresponding call parameters, the calling electronic device can delete some media stream types from the first SIP message and use the deleted first SIP message as the second SIP message to ensure that the call can proceed in the first mobile communication network as much as possible. This allows the media stream types and corresponding call parameters in the deleted first SIP message to be supported by the calling network device, thereby reducing the occurrence of call degradation or abnormal call interruption due to network device incompatibility with some media stream types, improving call quality, and enhancing the user's call experience.

[0017] In one possible implementation of the first aspect, the media stream type included in the second SIP message does not include the target media stream type. The media stream type included in the second SIP message is obtained by deleting the target media stream type from the multiple media stream types included in the first SIP message.

[0018] In this embodiment, considering that call failure may be due to the calling network device not supporting the target media stream type, the calling electronic device can delete the target media stream type from the first SIP message and use the first SIP message with the target media stream type deleted as the second SIP message. In this way, the first SIP message can be adjusted in a timely manner when a call fails, and a new call request can be initiated to the calling network device, thereby achieving device call renegotiation, improving the success rate of device calls, and ultimately improving the user's call experience.

[0019] In one possible implementation of the first aspect, among the multiple media stream types included in the first SIP message, the media stream types are deleted in the order of their arrangement from back to front.

[0020] In this embodiment, considering that the most basic media stream type (such as audio type) in the first SIP message is usually located in the first position of the first SIP message, the calling electronic device can delete a preset number of media stream types from back to front according to the deletion order of media stream types in the first SIP message in order to improve the efficiency of media stream type deletion. This reduces the need to execute a judgment process every time a media stream type is deleted, improving the efficiency of media stream type deletion and thus improving the call efficiency between the two devices (i.e., the calling electronic device and the called electronic device).

[0021] In one possible implementation of the first aspect, the media stream types included in the second SIP message are obtained by deleting a first preset number of media stream types other than preset media stream types from the multiple media stream types included in the first SIP message each time.

[0022] In this embodiment, after a call fails, the calling electronic device can delete a first preset number of media stream types from the first SIP message, excluding preset media stream types, and use the deleted first SIP message as the second SIP message. This reduces the likelihood of preset media stream types being mistakenly deleted, improves the accuracy of media stream type deletion, and lays the foundation for improving the call experience in the future.

[0023] In one possible implementation of the first aspect, among the multiple media stream types included in the first SIP message, the preset media stream type is positioned before the other media stream types.

[0024] In this embodiment, since the preset media stream type is arranged before the other media stream types, the calling electronic device can delete a preset number of media stream types from back to front, thereby reducing the need to perform a judgment process every time a media stream type is deleted, improving the deletion efficiency of media stream types, and thus improving the call efficiency of the two-end devices (i.e., the calling electronic device and the called electronic device).

[0025] In one possible implementation of the first aspect, after the calling electronic device re-initiates a call request to the calling network device, the method further includes: if the call fails, the calling electronic device may, in the first mobile communication network, use a new second SIP message to re-initiate a call request to the calling network device until the call is successful or until the recall stop condition is met.

[0026] In this embodiment, if the call fails again, it indicates that the second SIP message may still contain media stream types that the calling network device does not support, such as the target media stream type. Therefore, the calling electronic device can continue to adjust and obtain a new second SIP message to re-initiate a call request to the calling network device, thereby achieving device call renegotiation. This ensures that the call can proceed under the first mobile communication network as much as possible, reducing the occurrence of call degradation or abnormal call interruption due to the network device's inability to recognize the media stream, improving the success rate of device calls, and ultimately improving the user's call experience.

[0027] In one possible implementation of the first aspect, when the redialing stop condition is met, the calling electronic device sends a call request to the calling side network device in the second mobile communication network; wherein the network generation of the second mobile communication network is lower than that of the first mobile communication network.

[0028] The first mobile communication network is the Mth generation mobile communication network. The second mobile communication network is the Nth generation mobile communication network. M is greater than N.

[0029] The conditions for stopping a redial include the number of media stream types included in the new second SIP message being equal to the second preset number, or the number of times a redial request is initiated being greater than or equal to the preset number.

[0030] In this embodiment, if the redial stop condition is met, the calling electronic device can send a call request to the calling-side network device in the second mobile communication network, enabling the calling electronic device to establish a target call with the called electronic device in the second mobile communication network. This ensures the call can proceed normally, reduces the probability of abnormal call interruption, and thus improves the user's call experience.

[0031] In one possible implementation of the first aspect, the media stream type included in the second SIP message is the same as the media stream type included in the historical SIP message. The historical SIP message is the SIP message corresponding to a previous successful call in the first mobile communication network by the calling electronic device.

[0032] In some cases, the media stream types in a historical SIP message may be some of the media stream types included in the first SIP message. Alternatively, the media stream types in a historical SIP message may be the same as the multiple media stream types included in the first SIP message. Or, the media stream types in a historical SIP message may include a preset media stream type. Or, the media stream types in a historical SIP message may not include the target media stream type.

[0033] In this embodiment, in the event of a call failure (e.g., the calling network device does not support the target media stream type), the calling electronic device can use the media stream type from the historical SIP messages recorded during a previous successful call as the media stream type in the second SIP message. This allows for timely adjustment of the SIP message and re-initiation of the call request to the calling network device when a call fails, thereby enabling device call renegotiation, improving the success rate of device calls, and ultimately enhancing the user's call experience.

[0034] In the second SIP message, the call parameters for the media stream type are the same as those for the media stream type in the historical SIP messages.

[0035] In one possible implementation of the first aspect, after the calling electronic device re-initiates a call request to the calling network device, the method further includes: if the call fails, the calling electronic device, in the first mobile communication network, uses a new second SIP message to re-initiate a call request to the calling network device until the call succeeds or until the recall termination condition is met. The media stream type included in the new second SIP message is the same as the media stream type included in another historical SIP message.

[0036] In this embodiment, if the call fails again, it indicates that the second SIP message may still contain a media stream type that the calling network device does not support. Therefore, the calling electronic device can continue to call historical SIP messages as new second SIP messages to re-initiate a call request to the calling network device, thereby achieving device call renegotiation. This ensures that the call can proceed under the first mobile communication network as much as possible, reducing the occurrence of call degradation or abnormal call interruption caused by the network device's inability to recognize the media stream, improving the success rate of device calls, and ultimately improving the user's call experience.

[0037] In one possible implementation of the first aspect, the method further includes: when the redialing stop condition is met, the calling electronic device sends a call request to the calling side network device in the second mobile communication network, wherein the network generation of the second mobile communication network is lower than that of the first mobile communication network.

[0038] The conditions for stopping a redial include the number of times a redial request is initiated is greater than or equal to the total number of different SIP messages recorded when a historical call was successful, or the number of times a redial request is initiated is greater than or equal to a preset number.

[0039] In this embodiment, if the redial stop condition is met, the calling electronic device can send a call request to the calling-side network device in the second mobile communication network, enabling the calling electronic device to establish a target call with the called electronic device in the second mobile communication network. This ensures the call can proceed normally, reduces the probability of abnormal call interruption, and thus improves the user's call experience.

[0040] Secondly, this application provides a call system, which includes a calling electronic device, a calling-side network device, a called electronic device, and a called-side network device. The calling-side network device is connected to both the calling electronic device and the called-side network device. The called electronic device is connected to the called-side network device. The calling electronic device performs the method described above.

[0041] Thirdly, this application provides an electronic device, the electronic device including a memory and one or more processors; the memory and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method described above.

[0042] Fourthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described above.

[0043] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described above.

[0044] In a sixth aspect, a chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, and the processor is used to execute code in the memory, wherein when the code is executed, the processor is used to execute the method described above.

[0045] The beneficial effects that the communication system described in the second aspect, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, the computer program product described in the fifth aspect, and the chip described in the sixth aspect can achieve can be referred to the beneficial effects of the first aspect and any of its possible design embodiments, and will not be repeated here. Attached Figure Description

[0046] Figure 1 A schematic diagram illustrating the process of establishing an RTT call between a calling electronic device and a called electronic device, provided in an embodiment of this application;

[0047] Figure 2 A schematic diagram illustrating the process of establishing a call between electronic devices using existing technology;

[0048] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0049] Figure 4 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0050] Figure 5 A schematic diagram illustrating the process of establishing a call between a calling electronic device and a called electronic device, provided by existing technology;

[0051] Figure 6 A flowchart illustrating a call method provided in an embodiment of this application;

[0052] Figure 7 A schematic diagram of an interface for making an RTT call on a mobile phone, provided as an embodiment of this application;

[0053] Figure 8 This application provides a schematic diagram of an interface for setting up RTT call functionality.

[0054] Figure 9 A schematic diagram of an interface for answering RTT calls provided in an embodiment of this application;

[0055] Figure 10 A schematic diagram illustrating the call establishment process between a calling electronic device and a called electronic device, provided as an embodiment of this application;

[0056] Figure 11 A flowchart illustrating another call method provided in an embodiment of this application;

[0057] Figure 12 This is a schematic diagram illustrating another call establishment process between a calling electronic device and a called electronic device, provided as an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0059] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0060] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0061] The following section will first introduce the relevant terms used in the embodiments of this application.

[0062] 1. Card-based scheme

[0063] The SIM-enabled solution refers to configuring the target functions of an electronic device based on the subscriber identity module (SIM card) information. In other words, when a SIM card is inserted, the electronic device can automatically load the target configuration file based on the SIM card information to achieve the target function. For example, the target function could be real-time text (RTT) calling.

[0064] In one implementation, the process of implementing the above-mentioned SIM card-as-you-go solution may specifically include: the electronic device constructing SIM card file information. This SIM card file information stores all information about the SIM card. For example, the SIM card file information may include the mobile country code (MCC), mobile network code (MNC), integrated circuit card identity (ICCID), service provider name (SPN), and identification parameters, etc. The identification parameters may include GID1 and / or GID2. Afterwards, the electronic device may check whether the SIM card file information is stored in the database. If the SIM card file information is stored in the database, the electronic device may return a carrier information object.

[0065] If the aforementioned database does not contain SIM card file information, the electronic device can query the SIM card matching rules for the MCC within the SIM card file information. Then, the electronic device can match the SIM card file information with the SIM card matching rules to obtain a matching result. This matching result indicates whether a mapping rule exists between the SIM card file information and the matching rules.

[0066] If the above information matching result indicates that the SIM card matching rules contain mapping rules for SIM card file information, the electronic device can return a carrier info object. This carrier info object includes opkey information. The electronic device can then save the opkey information included in the carrier info object to the persist property. The persist property is used to set and save configuration information at system startup. Next, the electronic device can parse the first configuration file and save the parsed file content to the target configuration file. Finally, the electronic device can send a broadcast notification to update the target configuration file.

[0067] It should be noted that while the aforementioned SIM-enabled solution boasts advantages such as wide applicability, strong SIM-enabled capabilities, high configurability, and unified SIM-enabled capabilities, it also suffers from drawbacks including complex architecture and high maintenance costs. Wide applicability means the solution can cover the operational needs of various network devices globally. Strong SIM-enabled capabilities mean it supports over 90% of customized capabilities, allowing for independent configuration for each SIM card. High configurability and unified SIM-enabled capabilities mean the solution can set different customized capabilities for different SIM cards. In other words, as long as the SIM card is configured with a configuration file for the target capability, electronic devices with the SIM card installed can support the target capability. For example, the target capability could be RTT (Round-Trip) calling capability. Complex architecture means the solution has a high learning curve, requiring developers to have in-depth knowledge of SIM card file information and SIM card matching rules. High maintenance costs mean the solution requires maintaining a large number of configuration files and databases. In short, the SIM-enabled solution is suitable for scenarios requiring high customization and flexible configuration, and can cover the operational needs of various network devices globally, but it suffers from complex architecture and high maintenance costs.

[0068] 2. Adapted to the regional plan

[0069] The region-specific approach refers to configuring the target functions of an electronic device based on its location. In other words, when the electronic device is used by a user, the target configuration file is automatically loaded based on the device's location information (i.e., its region) to achieve the desired functionality. For example, the region where the electronic device is located can be represented by a country or region code.

[0070] In one implementation, the process of implementing the aforementioned region-based solution may specifically include: The electronic device can generate a target region file based on the inheritance relationship of configuration files. For example, taking the configuration files as def_eu_def.xml and altice_fr_def.xml, the target region file can be an altice_fr_def file that inherits from the configuration files; that is, the altice_fr_def file inherits from both def_eu_def.xml and altice_fr_def.xml. The electronic device can then compile the target region file to obtain a binary file. The binary file is a file with the ".bin" extension. The electronic device can then push the binary file to its target directory using the adb push command. Afterward, when the electronic device is restarted, it can reload the configuration files and debug the target functionality according to the reloaded configuration files.

[0071] It should be noted that while the aforementioned region-specific solution can address the problems of the SIM card-specific solution (i.e., complex architecture and high maintenance costs), meaning it boasts advantages such as simple architecture and flexible configuration, it also suffers from drawbacks including limited applicability, weak SIM card-specific capabilities, poor configurability, and fragmented implementation. Specifically, "simple architecture" means the region-specific solution is easy to understand and implement. "Flexible configuration" means electronic devices can flexibly generate different region files through configuration file inheritance. "Limited applicability" means the solution can only support customized needs in specific regions, making it difficult to cover the entire globe and thus unable to be configured for all regions. "Weak SIM card-specific capabilities" means it can only support 10% of customization capabilities, meaning it cannot be configured independently for SIM cards. "Poor configurability" means developers need to develop additional capabilities based on actual needs. "Fragmented implementation" means new capabilities require development, leading to fragmented logic. In short, the region-specific solution is suitable for customized needs in specific regions, has a simple architecture, and is flexible in configuration, but its applicability is limited and its SIM card-specific capabilities are weak.

[0072] In some cases, to improve the real-time nature of calls, an increasing number of electronic devices are adopting RTT (Real-Time To-Talk) calling functionality. RTT is an instant messaging technology based on the RTT communication protocol. In a network environment that supports RTT calling, the calling electronic device can create a text message and send it to the called electronic device in real time, without the calling user needing to trigger a send command (such as clicking a send button). In other words, the text message transmission process differs from traditional SMS, chat, or other types of text communication, which require the sending command from the calling user to be detected before sending the text message to the called electronic device. This allows the recipient (the user of the called electronic device) to read the text instantly as the sender (the user of the calling electronic device) types it, without needing to monitor the sender's status or wait for a send command, thus improving the real-time nature of text transmission and enhancing the user's call experience.

[0073] The aforementioned RTT communication protocol is the Real-Time Transport Protocol (RTP), which stipulates that RTT real-time text communication needs to coexist with IP multimedia subsystem (IMS) voice. In other words, RTT calls require the use of network communication technology. Network communication technology refers to technologies that rely on a network for voice communication. For example, this network communication technology could be Voice over Long-Term Evolution (VoLTE), Voice over Wi-Fi (VoWiFi), or Voice over New Radio (VoNR) for 5G networks, etc., with no specific limitations.

[0074] The following will combine Figure 1 The RTT communication protocol stack shown illustrates how the calling electronic device establishes an RTT call with the called electronic device.

[0075] like Figure 1 As shown, the RTT communication protocol stack can include the protocol stacks of two user equipment (UE) devices and a communication network. The protocol stacks of the two UE devices are the protocol stack of the calling electronic device and the protocol stack of the called electronic device, respectively. The UE protocol stack can include a multimedia transport protocol based on the RTP protocol, a signaling control protocol, a media transport protocol, and transport layer protocols. The RTP-based multimedia transport protocol can include a multimedia text conversion protocol (T.140) for text calls, a voice codec protocol for audio calls, and a video codec protocol for video calls. The signaling control protocol can include a session initiation protocol (SIP) and a session description protocol (SDP). The media transport protocol can include the RTP protocol. The transport layer protocols can include a user datagram protocol (UDP), a transmission control protocol (TCP), and an internet protocol (IP).

[0076] The aforementioned communication network is used to perform capability checks on the signaling control plane and media bearer plane based on protocols in the protocol stack, and to complete capability switching during service processing. The signaling control plane is responsible for signaling interaction and SDP Offer / Answer negotiation (OA negotiation) within the communication network. OA negotiation is the core mechanism in the aforementioned network communication technology for dynamically negotiating media parameters. The media bearer plane is responsible for the data transmission of RTP media packets. These RTP media packets may include at least one of the following: text packets for RTT calls, voice packets for voice calls, and video packets for video calls.

[0077] In some cases, because the transmission burden of text content in RTT calls is lighter than that of voice content in voice calls (meaning the data size of text packets in RTT calls is smaller than that of voice packets in voice calls), the transmission speed of text packets in RTT calls is faster than that of voice packets in voice calls, and the network resource usage of text packets in RTT calls is lower than that of voice packets. To improve the efficiency of RTT calls, the packetization time required during the encoding and decoding process of RTT calls is longer than that required during the encoding and decoding process of voice calls. Packetization time refers to the time spent packaging and integrating information into a single RTT media packet during the encoding or decoding process of a call. For example, the packetization time required during the encoding and decoding process of an RTT call can be 300 milliseconds (ms), while the packetization time required during the encoding and decoding process of a voice call can be 20 ms.

[0078] It should be noted that since the aforementioned RTT (Real-Time To-Talk) calling function is used for transmitting real-time text messages, compared to traditional voice and video calls, RTT calls not only better cater to special groups (such as deaf or hard-of-hearing users) for instant communication, but also reduce the possibility of call content being intercepted or interfered with, thus improving the security of the call for both parties. Furthermore, communicating via RTT can reduce misunderstandings caused by differences in accents, speaking speed, etc., improving the user's call experience.

[0079] However, since RTT calls, like voice and video calls, rely on media streams to establish a call, both the electronic device (such as a mobile phone) and the network device (such as the core network) need to support RTT calling capabilities to enable real-time communication between the two devices (the calling and called devices). Since RTT calling is not yet widespread, some electronic or network devices may not support it. This can lead to call degradation or call failures during the establishment of an RTT call, negatively impacting the user's call experience.

[0080] For example, if an electronic device already supports RTT calling capabilities, but the network device does not yet support RTT calling capabilities, there will be a problem of incompatibility between the communication protocol of the electronic device and the communication protocol of the network device (i.e., the RTT protocol). This will lead to a degradation of the electronic device's call quality or abnormal interruption of the call, ultimately affecting the user's calling experience.

[0081] Call downgrading refers to downgrading the mobile communication network of the calling electronic device from a first mobile communication network to a second mobile communication network. For example, the first mobile communication network has a higher network generation than the second mobile communication network. For instance, the first mobile communication network could be a 5G network, while the second mobile communication network could be a 3G network. Alternatively, the communication capabilities / performance of the first mobile communication network could be superior to that of the second mobile communication network.

[0082] Specifically, such as Figure 2 As shown, the process of establishing a call between electronic devices can specifically include: in response to a user's call initiation operation, the calling electronic device initiates a call request to the calling-side network device within a first mobile communication network. If the call is successful, the calling electronic device establishes a target call with the called electronic device within the first mobile communication network. If the call fails, the calling electronic device determines whether the calling-side network device supports a downgraded second mobile communication network. The second mobile communication network is a network with a lower priority than the first mobile communication network. For example, the priority can be network generation, with the second mobile communication network having a lower network generation than the first mobile communication network. If the calling-side network device supports the second mobile communication network, the calling electronic device establishes a target call with the called electronic device within the second mobile communication network. If the calling-side network device does not support the second mobile communication network, the calling electronic device generates call failure information. This call failure information indicates that the call between the calling and called electronic devices has failed.

[0083] Furthermore, considering the aforementioned SIM card-based and region-based solutions, the RTT calling function configured in the SIM card-based solution is determined based on whether the SIM card has RTT calling service activated. In other words, if an electronic device uses the SIM card-based solution to implement RTT calling, and the electronic device has a SIM card with RTT calling service activated, then the electronic device can be confirmed to support RTT calling capability. If the electronic device does not have a SIM card with RTT calling service activated, it means the electronic device does not support RTT calling capability; that is, the electronic device can only use services provided by the existing network (such as voice call service, video call service, etc.).

[0084] In other words, while implementing RTT calling functionality via a SIM-based solution reduces the risk of protocol compatibility issues between electronic and network devices, this solution cannot provide RTT calling service to all electronic devices at once. Furthermore, the RTT calling capability configuration file in an electronic device is based on the SIM card installed, which affects the configuration efficiency of RTT calling capabilities. Therefore, to better implement RTT calling functionality, this embodiment chooses a region-based solution. However, even with a region-based solution for configuring RTT calling capabilities, if the network device does not support RTT calling functionality, network compatibility issues will still arise due to the inability of the electronic and network devices to negotiate RTT, leading to call degradation or abnormal call interruptions, ultimately affecting the user's calling experience.

[0085] Therefore, to ensure a good user experience and reduce call degradation or interruptions, this application provides a call method. In this method, in response to a user's call initiation, the calling electronic device can initiate a call request to the calling network device using a first SIP message within a first mobile communication network. The first SIP message includes multiple media stream types, including a target media stream type. Subsequently, in the event of a call failure, the calling electronic device can re-initiate a call request to the calling network device using a second SIP message within the first mobile communication network. The second SIP message contains media stream types and / or call parameters that are not entirely identical to those included in the first SIP message.

[0086] In some cases, the target media stream type can be text. The call initiation operation described above is used to trigger an RTT call from the calling electronic device to the called electronic device.

[0087] In other cases, the target media stream type may also be an application type, etc. The embodiments of this application do not limit the specific type of the target media stream.

[0088] In this embodiment, if the call fails when the first SIP message used in the initial call includes a target media stream type, it may be due to the calling network device not supporting the target media stream type or its corresponding call parameters. Therefore, the calling electronic device can adjust the media stream type in the first SIP message and re-initiate a call request to the calling network device using the adjusted first SIP message. In other words, the calling electronic device can re-initiate a call request to the calling network device using a second SIP message that is not entirely identical to the media stream type and / or call parameters included in the first SIP message, thereby achieving call renegotiation. In this way, the media stream type and corresponding call parameters in the adjusted second SIP message may be supported by the calling network device, enabling the calling electronic device to conduct calls in the first mobile communication network without needing to achieve call connection through call degradation. In other words, by re-initiating a call request to the calling network device using the second SIP message, it is possible to ensure that the call can proceed under the first mobile communication network as much as possible, reducing the occurrence of call degradation or abnormal call interruption due to network device not supporting the media stream type, improving the success rate of device calls, and thus improving the user's call experience.

[0089] The aforementioned network device's lack of support for media stream types can be due to several reasons. First, the network device may be unable to recognize the media stream type. Second, the network device may be able to recognize the media stream type but cannot support it. Third, the media stream type may not conform to SIP protocol requirements (e.g., the call parameters corresponding to the media stream type are incorrect). The specific reasons are not limited. The network device's inability to recognize the media stream type means that the network device cannot recognize the codec format corresponding to the media stream type, or that the network device cannot parse the codec format corresponding to the media stream type.

[0090] In some examples, the electronic device in this application embodiment may be a mobile phone, tablet computer, smartwatch, desktop, laptop, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, etc., which have RTT calling function. This application embodiment does not impose any special restrictions on the specific form of the electronic device.

[0091] For example, Figure 3 A schematic diagram of the structure of the electronic device 100 is shown. For example... Figure 3As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 111, a power management module 112, a battery 113, antenna 1, antenna 2, a mobile communication module 140, a wireless communication module 150, an audio module 170, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and SIM card interfaces 1-N 195, etc. The sensor module 180 may include pressure sensors and touch sensors, etc.

[0092] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 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.

[0093] 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, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0094] In some embodiments, the electronic device 100 may perform the RTT call method provided in this application through the processor 110.

[0095] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 140, wireless communication module 150, modem processor, and baseband processor.

[0096] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed 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.

[0097] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. 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 the 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.

[0098] 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 an audio signal through an audio device (not limited to a speaker, receiver, etc.) or displays RTT text content 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.

[0099] The wireless communication module 160 can provide solutions for wireless communication applications on electronic devices 100, including WLAN (such as Wi-Fi networks), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and other wireless communication technologies.

[0100] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with networks and other devices through wireless communication technology.

[0101] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0102] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0103] In some embodiments of this application, the internal memory 1021 can be used to store SIP messages. These SIP messages are SIP protocol data packets used to characterize multimedia communication in an IP network. The SIP message may include an SDP field, which includes at least one media stream type. The media stream type may include audio, video, application, data type, control, image, message, text, or other types. Other types are media stream types other than audio, video, application, data type, control, image, message, and text types.

[0104] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0105] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0106] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0107] The display screen (or screen) 194 is used to display text content received by the electronic device or entered by the user during an RTT call. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0108] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0109] Electronic device 100 can implement audio functions such as music playback and recording through audio module 170, speaker, receiver, microphone, headphone jack, and application processor.

[0110] A pressure sensor is used to sense pressure signals and convert them into electrical signals. In some embodiments, the pressure sensor may be located on the display screen 194. When a touch operation is applied to the display screen 194, the electronic device 100 detects the intensity of the touch operation based on the pressure sensor. The electronic device 100 may also calculate the touch location based on the detection signal from the pressure sensor. In some embodiments, touch operations applied to the same touch location but with different intensities may correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS message is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS message is executed.

[0111] A touch sensor, also known as a "touch panel," can be located on the display screen 194. The touch sensor and display screen 194 together form a touchscreen, also called a "touch screen." The touch sensor 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 the display screen 194. In other embodiments, the touch sensor may also be located on the surface of the electronic device 100, in a different position than the display screen 194.

[0112] Figure 4 This is a schematic diagram of the structure of a call system according to an embodiment of this application. Figure 4 As shown, the call system may include a calling electronic device 110 on the calling side, a calling network device (or calling network device) 210 on the calling side, a called electronic device 120 on the called side, and a called network device 220 on the called side. The calling electronic device 110 can establish a communication connection with the calling network device 210, the calling network device 210 can establish a communication connection with the called network device 220, and the called network device 220 can establish a communication connection with the called electronic device, facilitating a call connection between the calling electronic device 110 and the called electronic device 120. It can be understood that the calling electronic device 110, the calling network device 210, the called electronic device 120, and the called network device 220 together constitute an IMS network. This IMS network is used to enable two-way communication between the calling electronic device 110 and the called electronic device 120.

[0113] In this embodiment, the calling electronic device 110 and the called electronic device 120 are the two ends of the target call. The target call can be an RTT call, voice call, video call, etc., and is not specifically limited. The calling electronic device 110 can be referred to as the first electronic device, and the called electronic device 120 can be referred to as the second electronic device. That is, the calling electronic device 110 and the called electronic device 120 can be collectively referred to as electronic devices. Correspondingly, the calling network device 210 can be referred to as the first network device, and the called network device 220 can be referred to as the second network device. That is, the calling network device 210 and the called network device 220 can be collectively referred to as network devices. For example, network devices can be core network, access network devices, or other network-side devices.

[0114] In one implementation, when both the calling and called electronic devices support both audio and text types, the calling electronic device can negotiate a call with the called electronic device through both the calling and called network devices, thereby establishing the target call. The following will combine... Figure 4 The communication system shown and Figure 5The call setup process shown details how the calling electronic device establishes a call with the called electronic device.

[0115] The calling electronic device receives the call initiation operation from the calling user. Then, the calling electronic device can send an invitation message to the calling network device. The invitation (INVITE) message requests the called electronic device to establish a session, which is equivalent to SDP-Offer negotiation. This invitation message carries SIP messages, including audio and text types. Subsequently, upon receiving the invitation message from the calling electronic device, the calling network device sends an invitation message to the called network device. Then, upon receiving the invitation message from the calling network device, the called network device sends an invitation message to the called electronic device. Finally, upon receiving the invitation message from the called network device, the called electronic device sends an answer message. The answer (ANSWER) message can be a 183 message, indicating that the session is in progress, but the called electronic device has not answered. This answer message is equivalent to SDP-Answer negotiation. This answer message carries SIP messages, including audio and text types. Subsequently, upon receiving the response message from the called electronic device, the called network device sends a response message to the calling network device. Then, upon receiving the response message from the called network device, the calling network device sends a response message to the calling electronic device.

[0116] Subsequently, upon receiving the response message from the calling network device, the calling electronic device sends an acknowledgment request message to the calling network device. This acknowledgment request message can be a PRACK message, used to verify the reliability of the response message, thus ensuring that the session request is not interrupted or lost during the establishment of the RTT call. Following this, upon receiving the acknowledgment request message from the calling electronic device, the calling network device sends an acknowledgment request message to the called network device. Then, upon receiving the acknowledgment request message from the calling network device, the called network device sends an acknowledgment request message to the called electronic device. Finally, upon receiving the acknowledgment request message from the called network device, the called electronic device sends a transmission response message to the called network device. This transmission response message can be a 200 OK response message to the acknowledgment request message, indicating that the transmission of the response message was reliable. Finally, upon receiving the transmission response message from the called electronic device, the called network device sends a transmission response message to the calling network device. Subsequently, upon receiving the transmission response message from the called network device, the calling network device sends a transmission response message to the calling electronic device, so that the calling electronic device can know whether the transmission process of the aforementioned response message is reliable.

[0117] In some cases, upon receiving an invitation message from the called network device, the called electronic device can also send a ringing response message to the called network device. This ringing response message can be a 180 Ringing message, used to notify the calling electronic device that the called electronic device is ringing. Subsequently, upon receiving the ringing response message from the called electronic device, the called network device sends a ringing response message to the calling network device. Then, upon receiving the ringing response message from the called network device, the calling network device sends a ringing response message to the calling electronic device.

[0118] In other cases, when the called electronic device receives an invitation message from the called-side network device, if it also receives a call connection operation from the called user for the calling electronic device, it can send an answer response message to the called-side network device. This answer response message can be a 200 OK response to the invitation message, indicating that the called electronic device has accepted the calling electronic device's RTT call request. Subsequently, upon receiving the answer response message from the called electronic device, the called-side network device sends an answer response message to the calling-side network device. Then, upon receiving the answer response message from the called-side network device, the calling-side network device sends an answer response message to the calling electronic device.

[0119] Subsequently, upon receiving the response message from the calling network device, the calling electronic device sends an acknowledgment message to the calling network device. The acknowledgment (ACK) message indicates that the calling electronic device has received the response message from the called electronic device. This response message may include at least one of a transmission response message, a ringing response message, and an answer response message. Then, upon receiving the acknowledgment message from the calling electronic device, the calling network device sends an acknowledgment message to the called network device. Finally, upon receiving the acknowledgment message from the calling network device, the called network device sends an acknowledgment message to the called electronic device.

[0120] It's understandable that if the called electronic device receives a response message from the called network device, it means that an RTT (Read-To-Talk) call has been established between the called and called electronic devices. Therefore, the called electronic device can use the RTT protocol to conduct audio and text communication with the called electronic device.

[0121] Based on the call system described above, this application provides a call method. This method can be applied to call scenarios corresponding to the target media stream type. For example, if the target media stream type is text, the call scenario corresponding to the target media stream type can be an RTT call scenario.

[0122] Specifically, in response to a user's call initiation operation, the calling electronic device can initiate a call request to the calling-side network device using a first SIP message within the first mobile communication network. This call initiation operation triggers the calling electronic device to initiate an RTT call to the called electronic device. The first SIP message includes multiple media stream types (or codec types), including text. Subsequently, in the event of a call failure, the calling electronic device can re-initiate a call request to the calling-side network device using a second SIP message within the first mobile communication network, thereby achieving call renegotiation. In this way, the media stream type and corresponding call parameters in the adjusted second SIP message may be supported by the calling-side network device, enabling the calling electronic device to conduct the call within the first mobile communication network without resorting to call degradation. In other words, by re-initiating a call request to the calling-side network device using a second SIP message, the success rate of the call can be maximized within the first mobile communication network, reducing the likelihood of call degradation or abnormal call interruption due to network device incompatibility with media stream types, thus improving the call success rate and ultimately enhancing the user's call experience.

[0123] This application provides a call method. In this embodiment, upon detecting a user's call initiation operation, if the call fails, the calling electronic device can process the media stream type in the first SIP message to obtain a second SIP message. Then, the calling electronic device can use the second SIP message to negotiate a call with the calling network device, thereby enabling the calling electronic device to establish a target call with the called electronic device. Specifically, as shown... Figure 6 As shown, the call method provided in this application embodiment may include S601 to S612:

[0124] S601, the calling electronic device receives the user's call initiation operation.

[0125] The aforementioned call initiation operation is used to trigger an RTT call from the calling electronic device to the called electronic device. For example, this call initiation operation can be a user manually triggering the RTT call control, or a user voice-outputting the RTT call control, etc., and is not specifically limited. For instance, the call initiation operation could be a triggering operation for the RTT call control of the number belonging to the called electronic device.

[0126] For example, taking a mobile phone as the calling electronic device, such as... Figure 7 As shown, the phone is displaying... Figure 7 The main interface is shown in (a). The main interface may include multiple application icons. For example, these application icons could be the phone application icon 710, the SMS application icon, the camera application icon, etc. Then, in response to the user's click on the phone application icon 710, the phone can enter the phone application to display... Figure 7 The initial phone interface of the telephone application is shown in (b). The initial phone interface may include a dial pad 7A, a number to be called (i.e., 132****7788), an "RTT Call" control, and a "Make a Call" control. The dial pad 7A is used for the user to enter the number they wish to call, i.e., to enter the number to be called.

[0127] Subsequently, in response to the user's click on the "RTT Call" control in the initial phone interface, the phone can display... Figure 7 The pending call interface is shown in (c). This interface may include a hang-up control 720, the number to be called, and a waiting message (i.e., waiting for 132****7788 to join the RTT call…). It can be seen that the user's click on the “RTT call” control is equivalent to responding to the user's call initiation action. That is to say, the called phone is the phone belonging to the number “132****7788”.

[0128] It's important to note that the call initiation operation described above can only be performed if the RTT (Round-Trip) calling function is enabled on the calling electronic device. In other words, if the calling electronic device does not have RTT calling enabled or does not possess RTT calling functionality, the "RTT Call" control will not appear on the initial phone interface, and an RTT call cannot be initiated. Therefore, before entering the phone application, the calling electronic device needs to ensure that the RTT calling function is enabled. Only when the RTT calling function is enabled can the calling electronic device perform a call operation targeting RTT calling (or RTT call operation). The RTT calling function in the phone application can be enabled by default on the calling electronic device or manually enabled by the user according to their needs.

[0129] For example, taking a mobile phone as the calling electronic device, such as... Figure 8 As shown, the phone is displaying... Figure 8 The settings interface shown in (a) is an example. This settings interface can be the settings interface within the phone app or the interface of the phone's settings app. This settings interface can include settings for Live Text (RTT), Assisted Dialing, Quick Reply, notification sounds, and vibration. Subsequently, in response to the user's click on a Live Text (RTT) setting, the phone can display... Figure 8 The call settings interface is shown in (b). This interface may include options to hide the "RTT Call" control, show it during a call, and always show it. The "Hide" option hides the "RTT Call" control, meaning it is not displayed in the phone interface. The "Show During a Call" option displays the "RTT Call" control in the call interface, only after a user taps the "Make a Call" control. The "Always Show" option always displays the "RTT Call" control, showing it upon detecting the user opening the phone application and simultaneously displaying it when receiving any incoming call from the phone.

[0130] Subsequently, in response to the user's tapping action on the option to always display in the aforementioned call settings interface, it indicates that the user wants the RTT calling function and wants the "RTT calling" control to be displayed continuously. Therefore, upon detecting the user's access to the phone application, that is, detecting the user's tapping action on the phone application icon, the phone can... Figure 7 The initial phone interface of the phone application shown in (b) displays the "RTT Call" control.

[0131] It is understandable that the above Figure 8The interface shown for setting up RTT calling in the phone app is just an example; users can also control RTT calling on or off in other ways. For instance, the phone can directly display a toggle switch for the RTT calling settings, allowing users to directly control whether RTT calling is enabled or disabled. In other words, if the toggle switch for the RTT calling settings is turned on, it means the user wants to use RTT for calls. Therefore, the phone can enable RTT calling, meaning the phone can directly display the "RTT calling" control in the phone interface.

[0132] S602, the calling electronic device initiates a call request to the calling network device using a first SIP message in the first mobile communication network.

[0133] Specifically, after receiving a call initiation from a user, the calling electronic device can initiate a call request to the calling network device using a first SIP message within the first mobile communication network. The first mobile communication network is the largest communication network supported by the calling electronic device. This first mobile communication network can be an M-generation mobile communication network. For example, M can be 5 or 4. That is, the first mobile communication network can be a 5G network or a 4G network.

[0134] The aforementioned first SIP message may include multiple media stream types. These media stream types can be audio, video, application, data, control, image, message, text, or other types. "Other types" refers to media stream types other than audio, video, application, data, control, image, message, and text. In some embodiments of this application, the multiple media stream types may include a text type.

[0135] The following will illustrate the first SIP message, including audio and text types, with reference to the RFC3261 protocol.

[0136] v = 0

[0137] o=-4 1000IN IP6******************************

[0138] s = QC VOIP

[0139] c=IN IP6****************************

[0140] b=AS:53

[0141] b=RS:1200

[0142] b=RR:4000

[0143] t=0 0

[0144] m=audio 50058RTP / AVP 126 127 104 102 96 97

[0145] b=AS:50

[0146] b=RS:600

[0147] b=RR:2000

[0148] a=rtpmap:126EVS / 16000 / 1

[0149] a=fmtp:126br=5.9-24.4;bw=nb-swb;max-red=0

[0150] a=rtpmap:127EVS / 16000 / 1

[0151] a=fmtp:127br=9.6-24.4;bw=swb;max-red=0

[0152] a=rtpmap:104AMR-WB / 16000 / 1

[0153] a=fmtp:104mode-change-capability=2;max-red=0

[0154] a=rtpmap:102AMR / 8000 / 1

[0155] a=fmtp:102mode-change-capability=2;max-red=0

[0156] a=rtpmap:96telephone-event / 16000

[0157] a=fmtp:96 0-15

[0158] a=rtpmap:97telephone-event / 8000

[0159] a=fmtp:97 0-15

[0160] a=curr:qos local none

[0161] a=curr:qos remote none

[0162] a=des:qos mandatory local sendrecv

[0163] a=des:qos optional remote sendrecv

[0164] a=sendrecv

[0165] a=maxptime:240

[0166] a=ptime:20

[0167] m=text 50044RTP / AVP 112 111

[0168] b=AS:3

[0169] b=RS:600

[0170] b=RR:2000

[0171] a=rtpmap:112red / 1000

[0172] a=fmtp:112 111 / 111 / 111

[0173] a=rtpmap:111t140 / 1000

[0174] a=fmtp:111cps=30

[0175] a=curr:qos local none

[0176] a=curr:qos remote none

[0177] a=des:qos mandatory local sendrecv

[0178] a=des:qos optional remote sendrecv

[0179] a=sendrecv

[0180] In the first SIP message, line b represents bandwidth information indicating the media stream type. Line m represents descriptive information indicating the media stream type. This descriptive information may include the media stream type, the port number of the media stream, the transmission type of the media stream, and the payload type (PT). For example, in the first SIP message “m = audio50058RTP / AVP 126 127 104 102 96 97”, the media stream type is audio, the port number of the media stream is 50058, the transmission type of the media stream is RTP / AVP, and the payload types include 126, 127, 104, 102, 96, and 97. For example, in the first SIP message above, “m=text 50044RTP / AVP 112 111”, the media stream type is text, the media stream port number is 50044, the media stream transmission type is RTP / AVP, and the payload type includes 112 and 111.

[0181] It should be noted that payload types can include static payload types and dynamic payload types. Static payload types are predefined in the SDP protocol, meaning they have fixed meanings, and their values ​​range from 0 to 95. Dynamic payload types are temporarily assigned during session establishment, and their values ​​range from 96 to 127. In other words, the value range for payload types is 0 to 127. It should be noted that static payload types with values ​​between 0 and 95 do not need to be interpreted through line 'a' in the first SIP message, while dynamic payload types with values ​​between 96 and 127 do need to be interpreted through line 'a' in the first SIP message. That is, line 'a' in the first SIP message is used to characterize the specific codec or transport format of the dynamic payload type.

[0182] In one implementation, the calling electronic device initiating a call request to the calling network device can be achieved by the calling electronic device sending an INVITE message to the calling network device. This INVITE message carries the aforementioned first SIP message.

[0183] S603, the calling electronic device determines whether the call was successful.

[0184] In some cases, to achieve two-way communication (i.e., communication between the calling electronic device and the called electronic device), both the calling electronic device and the calling network device need to support RTT (Round-Trip) calling functionality. If the calling electronic device supports RTT calling functionality but the calling network device does not, protocol compatibility issues may arise between them, leading to call degradation or abnormal call interruption, affecting the user's call experience. Therefore, to reduce the probability of call degradation or abnormal call interruption, the calling electronic device can determine whether the call was successful after initiating a call request to the calling network device, thereby determining whether the calling network device may not support RTT calling functionality.

[0185] In one implementation, the calling electronic device determines whether the call was successful based on receiving an ANSWER message from the calling network device. Specifically, if the calling electronic device receives a first response message from the calling network device, and this first response message indicates a call failure, the calling electronic device can directly determine that the call failed. If the calling electronic device receives a second response message from the calling network device, and this second response message indicates that the calling network device does not support the call function corresponding to the target media stream type (i.e., text type), the call fails. For example, the first or second response message may include "Response Code = SERVICE_UNAVAILABLE (503)". It can be understood that 503 is equivalent to an example of an OXX error code. If the calling electronic device receives a third response message from the calling network device, and this third response message indicates a successful call, the calling electronic device can directly determine that the call was successful.

[0186] In some embodiments, if the call is successful, the calling electronic device can execute step S604 to achieve efficient establishment of the RTT call, reduce the possibility of downgrading or abnormal interruption of the RTT call, and improve the user's call experience.

[0187] In other embodiments, if the call fails, the calling network device may not support all media stream types or call parameters in the first SIP message. For example, the calling network device may not support RTT call functionality. Or, if the calling electronic device receives a second response message, it may determine that the calling network device does not support the target media stream type, such as the text type corresponding to the RTT call function. Therefore, the calling electronic device can execute step S605, adjusting the media stream type of the first SIP message so that the adjusted second SIP message is different from the first SIP message. The media stream types included in the adjusted second SIP message may be supported by the calling network device. Thus, by further negotiating the call with the calling network device through the second SIP message, it can ensure that the call can be conducted in the first mobile communication network as much as possible, reducing the probability of call degradation or abnormal call interruption, thereby improving the user's call experience.

[0188] S604, In the event of a successful call, the calling electronic device establishes an RTT call with the called electronic device in the first mobile communication network.

[0189] Specifically, after confirming the success of the call, the calling electronic device can directly establish an RTT (Round-Trip) call with the called electronic device within the first mobile communication network. This enables efficient RTT call establishment, reduces the likelihood of call degradation or abnormal interruption, and improves the user's call experience.

[0190] In some cases, after a successful call, the called electronic device can receive an RTT (Real-Time To Call) request from the calling electronic device, meaning the called electronic device can display the incoming call interface. Subsequently, in response to the called user's answering action on the calling electronic device, both the called and calling electronic devices can simultaneously display a real-time text interface. This real-time text interface displays real-time information entered by both users. This allows the receiver to view the text information entered by the sender in real time, improving call efficiency and convenience, and ultimately enhancing the user's call experience.

[0191] For example, let's take a mobile phone as an example. Figure 9 As shown, when the called mobile phone receives an RTT call request from the calling mobile phone, it can display... Figure 9 The incoming call interface shown in (a) includes the caller's phone number (i.e., 189****4444), a "Answer as RTT" control, an accept control, and a reject control. Subsequently, in response to the called user's click on the "Answer as RTT" control, it indicates that the RTT call between the caller and the called phone has been successfully answered. Therefore, the called phone can display... Figure 9The real-time text interface shown in (b) and the caller's mobile phone can also display Figure 7 The real-time text interface shown in (d) can include real-time text messages sent by the calling mobile phone (e.g., "Are you going out to play today?" or "Go") and real-time text messages sent by the called mobile phone (e.g., "Sure!").

[0192] S605: In the event of a failed call, the calling electronic device determines whether the conditions for stopping the redial are met.

[0193] Specifically, after receiving the first SIP message, the calling electronic device can determine whether the redial stop condition is met. The redial stop condition may include the number of media stream types included in the new second SIP message being equal to a second preset number, or the number of times a call request is re-initiated being greater than a preset number. The second preset number is the total number of the aforementioned preset media stream types.

[0194] Understandably, to ensure the call proceeds smoothly and reduce the probability of interruption, the calling electronic device needs to retain the most basic media stream type (i.e., audio type) in the first SIP message. Therefore, the calling electronic device can set the preset media stream type to audio. However, in other cases, the calling electronic device can also pre-set the preset media stream type according to the actual situation. For example, the calling electronic device can set the preset media stream type to application, video, etc., without specific limitations.

[0195] In some embodiments, if the redial stop condition is met, it means that the calling electronic device does not need to initiate a call request to the calling network device again. Therefore, to ensure that the call can proceed normally, the calling electronic device can execute step S609 to determine whether the call can be conducted in the second mobile communication network, thereby maximizing the probability of call success and ensuring the user experience. If the redial stop condition is not met, it means that the calling electronic device still has the possibility of a successful call. Therefore, to reduce the probability of call degradation or abnormal call interruption, the calling electronic device can execute step S606 to delete a portion of the media stream type in the first SIP message, thereby ensuring that the call can be conducted in a high-speed communication network and improving the user's call experience.

[0196] In some cases, to reduce unnecessary resource waste, the calling electronic device may not determine whether the redial stop condition is met when the initial call fails. This can improve resource utilization while ensuring the calling efficiency of the electronic device.

[0197] S606, if the redial stop condition is not met, the calling electronic device deletes the media stream type in the first SIP message according to a preset strategy to obtain the second SIP message.

[0198] Specifically, after determining that the redial stop condition is not met, the calling electronic device can delete the media stream types in the first SIP message and use the deleted first SIP message as the second SIP message. In other words, the media stream types included in the second SIP message are obtained by deleting a portion of the media stream types included in the first SIP message.

[0199] In one implementation, the calling electronic device can delete the target media stream type (i.e., text type) from the first SIP message and use the deleted first SIP message as the second SIP message. That is, the media stream type in the second SIP message does not include the target media stream type, and the media stream type included in the second SIP message is obtained by deleting the target media stream type from the multiple media stream types included in the first SIP message.

[0200] In another implementation, the calling electronic device can delete media stream types from the first SIP message according to a preset strategy, and then use the deleted first SIP message as the second SIP message. The preset strategy can be to delete a first preset number of media stream types from the first SIP message, excluding preset media stream types. The first preset number can be set according to actual needs. For example, the first preset number can be one, two, etc., without specific limitation. In other words, the media stream types included in the second SIP message are obtained by deleting a first preset number of media stream types, excluding the preset media stream types, from the multiple media stream types included in the first SIP message each time.

[0201] For example, taking the first preset quantity as 1 and the first SIP message as the SIP message listed in step S603 above as an example, the calling electronic device can delete m lines corresponding to the text type, as well as all text lines located after the m lines. The specific content to be deleted will be shown below:

[0202] m = text 50044 RTP / AVP 112 111

[0203] b = AS:3

[0204] b = RS:600

[0205] b = RR:2000

[0206] a = rtpmap:112red / 1000

[0207] a = fmtp:112 111 / 111 / 111

[0208] a = rtpmap:111t140 / 1000

[0209] a = fmtp:111cps = 30

[0210] a = curr: qos local none

[0211] a = curr: qos remote none

[0212] a=des:qos mandatory local sendrecv

[0213] a=des:qos optional remote sendrecv

[0214] a = sendrecv

[0215] It can be seen that when the calling electronic device deletes the media stream type in the first SIP message, it means deleting all messages belonging to the media stream type in the first SIP message, which is to say, deleting the call parameters of the media stream type in the first SIP message.

[0216] In some embodiments, the calling electronic device can select a first preset number of media stream types from a first SIP message, and determine whether the first preset number of media stream types includes a preset media stream type. If the first preset number of media stream types includes the preset media stream type, the calling electronic device can choose not to select the preset media stream type and select a new media stream type to obtain the first preset number of media stream types. Then, the calling electronic device can delete the first preset number of media stream types. If the first preset number of media stream types does not include the preset media stream type, the calling electronic device can directly delete the first preset number of media stream types. This reduces the occurrence of incorrect deletion of preset media stream types, improves the processing accuracy of media stream types, and provides a foundation for improving the call experience.

[0217] For example, taking the first SIP message as including audio, text, and image types, with a first preset quantity of 2 and a preset media stream type of audio, if the calling electronic device selects audio and text as the two media stream types, then the calling electronic device needs to select a new media stream type from the first SIP message, that is, select the image type from the first SIP message. Afterwards, the calling electronic device can delete the selected text and image types, meaning the audio type that was not deleted from the first SIP message becomes the target media stream type. However, if the calling electronic device selects text and image as the two media stream types, then the calling electronic device can directly delete the selected text and image types.

[0218] In other embodiments, considering that the preset media stream type is usually the first media stream type in the first SIP message, to improve the efficiency of media stream type deletion, the calling electronic device can delete a preset number of media stream types from back to front according to the arrangement order of the media stream types in the first SIP message, until only one media stream type (i.e., the preset media stream type) remains in the first SIP message, at which point the deletion process stops. That is, among the multiple media stream types included in the first SIP message, the deletion order is from back to front according to their arrangement position, and the preset media stream type is positioned before the other media stream types. This reduces the need to execute a judgment process for each media stream type deletion, improving the efficiency of media stream type deletion and thus improving the call efficiency between the two devices (i.e., the calling electronic device and the called electronic device).

[0219] In another implementation, the calling electronic device can directly extract a portion of the media stream types from the multiple media stream types included in the first SIP message, and use the extracted portion of the media stream types as the media stream types included in the second SIP message. That is, the calling electronic device may also choose not to delete the media stream types from the first SIP message. This portion of the media stream types may include the aforementioned preset media stream types.

[0220] S607, the calling electronic device, in the first mobile communication network, uses a second SIP message to re-initiate a call request to the calling network device.

[0221] Specifically, after receiving the second SIP message, the calling electronic device can use the second SIP message in the first mobile communication network to re-initiate a call request to the calling network device, thereby determining whether the call was successful, that is, whether the calling electronic device has established a call connection with the called electronic device.

[0222] S608, if the call is successful, the calling electronic device establishes a target call with the called electronic device in the first mobile communication network.

[0223] The real-time communication type of the target call corresponds to the media stream type included in the second SIP message.

[0224] Specifically, after confirming the success of the call, the calling electronic device can establish a target call with the called electronic device under the first mobile communication network. This ensures call quality for both devices, reduces the likelihood of call degradation or abnormal interruption, and ultimately improves the user's call experience.

[0225] It is understood that the real-time communication type of the target call corresponds to the media stream type included in the second SIP message. For example, if the second SIP message only includes the audio type, it indicates that the target media stream type is audio, meaning the calling electronic device can only encode and decode audio data. Therefore, the calling electronic device can establish a voice call with the called electronic device. As another example, if the second SIP message includes both audio and text types, it indicates that the target media stream type is both audio and text, meaning the calling electronic device can encode and decode both audio and text data simultaneously. Therefore, considering that RTT calls are based on audio and text data, the calling electronic device can establish an RTT call with the called electronic device.

[0226] S609, in the event of a call failure, the calling electronic device treats the second SIP message as the first SIP message.

[0227] Specifically, after confirming the call failure, the calling electronic device can use the second SIP message as the first SIP message and return to step S605 above to reuse the deleted first SIP message and re-initiate a call request to the calling network device. In other words, the calling electronic device can use the new second SIP message within the first mobile communication network to re-initiate a call request to the calling network device until the call is successful or until the redial stop condition is met. This ensures that the call can proceed under a high-speed communication network as much as possible, thereby reducing the probability of call degradation or abnormal call interruption and improving the user's call experience.

[0228] S610, if the redial stop condition is met, the calling electronic device determines whether the calling side network device supports the second mobile communication network.

[0229] The second mobile communication network is of a lower generation than the first mobile communication network. In other words, the second mobile communication network is a downgraded version of the first mobile communication network. This can be understood as the first mobile communication network being an Nth generation network, where N is less than M. For example, if the first mobile communication network is 5G, the second mobile communication network could be a 4G, 3G, or 2G network. Similarly, if the first mobile communication network is 4G, the second mobile communication network could be a 3G or 2G network.

[0230] In some embodiments, after determining that the redial stop condition is met, the calling electronic device can determine whether the calling-side network device supports the second mobile communication network. If the calling-side network device supports the second mobile communication network, it means that the call can be conducted on the second mobile communication network. Therefore, the calling electronic device can execute step S611 to ensure that the call can proceed normally, thereby reducing the probability of abnormal call interruption. If the calling-side network device does not support the second mobile communication network, it means that the call cannot be conducted on the second mobile communication network. Therefore, the calling electronic device can execute step S612 to generate a prompt message indicating that the call has failed, so that the user can be informed of the call failure in a timely manner.

[0231] S611, when the calling side network equipment supports a second mobile communication network, the calling electronic device establishes a target call with the called electronic device in the second mobile communication network.

[0232] Specifically, after confirming that the calling network device supports the second mobile communication network, the calling electronic device can send a call request to the second calling network device within the second mobile communication network. This allows the calling electronic device to establish a target call with the called electronic device within the second mobile communication network. This ensures the call can proceed normally, reduces the probability of abnormal call interruptions, and thus improves the user's call experience.

[0233] S612, the calling electronic device fails to make a call if the calling network device does not support the second mobile communication network.

[0234] Specifically, after determining that the calling network device does not support the second mobile communication network, the calling electronic device's call fails. In some possible implementations, the calling electronic device can display a call failure message indicating that the call failed. This allows the user to be promptly informed of the call failure, enabling them to retry the call as needed.

[0235] The above describes how the calling electronic device uses the first SIP message to initiate a call request to the calling network device, ensuring the call establishment process can take place over a high-speed communication network. The following example will illustrate this using a first SIP message that includes both text and audio types, with the preset media stream type being audio, and will be combined with the above... Figure 4 The communication system shown and Figure 10 The call process shown illustrates, for example, how a calling electronic device establishes a call connection with a called electronic device.

[0236] The calling electronic device receives the call initiation operation from the calling user. Then, the calling electronic device can send an invitation message to the calling network device. The invitation (INVITE) message is used to request the called electronic device to establish a session, which is equivalent to SDP-Offer negotiation. This invitation message carries a first SIP message, which includes audio and text types. Upon receiving the invitation message from the calling electronic device, if the calling network device does not support the text type, it indicates that the calling network device does not support RTT (Round-Trip) calling functionality. Therefore, the calling network device can return a second response message to the calling electronic device. This second response message can be a 503 message, which informs the calling electronic device that it does not support the RTT calling functionality corresponding to the text type. Upon receiving the second response message from the calling network device, the calling electronic device can delete the text type from the first SIP message and use the deleted first SIP message as the second SIP message.

[0237] Subsequently, the calling electronic device can send an invitation message to the calling network device again. This invitation message is equivalent to SDP-Offer negotiation. This invitation message carries the audio type included in the second SIP message mentioned above. Then, upon receiving the invitation message from the calling electronic device, the calling network device sends an invitation message to the called network device. Then, upon receiving the invitation message from the calling network device, the called network device sends an invitation message to the called electronic device. Then, upon receiving the invitation message from the called network device, the called electronic device sends a third response message to the called network device. This third response message can be a 183 message, indicating that the session is in progress, but the called electronic device has not answered. This third response message is equivalent to SDP-Answer negotiation. This third response message carries the audio type. Then, upon receiving the third response message from the called electronic device, the called network device sends a third response message to the calling network device. Subsequently, upon receiving the third response message from the called network device, the calling network device sends a third response message to the calling electronic device.

[0238] Subsequently, upon receiving the third response message from the calling network device, the calling electronic device sends an acknowledgment request message to the calling network device. This acknowledgment request message can be a PRACK message, used to verify the reliability of the response message, thus ensuring that the session request is not interrupted or lost during the establishment of the voice call. Following this, upon receiving the acknowledgment request message from the calling electronic device, the calling network device sends an acknowledgment request message to the called network device. Subsequently, upon receiving the acknowledgment request message from the calling network device, the called network device sends an acknowledgment request message to the called electronic device. Following this, upon receiving the acknowledgment request message from the called network device, the called electronic device sends a transmission response message to the called network device. This transmission response message can be a 200 OK response message to the acknowledgment request message, used to indicate that the transmission of the response message was reliable. Finally, upon receiving the transmission response message from the called electronic device, the called network device sends a transmission response message to the calling network device. Subsequently, upon receiving the transmission response message from the called network device, the calling network device sends a transmission response message to the calling electronic device, so that the calling electronic device can know whether the transmission process of the aforementioned third response message is reliable.

[0239] In some cases, upon receiving an invitation message from the called network device, the called electronic device can also send a ringing response message to the called network device. This ringing response message can be a 180 Ringing message, used to notify the calling electronic device that the called electronic device is ringing. Subsequently, upon receiving the ringing response message from the called electronic device, the called network device sends a ringing response message to the calling network device. Then, upon receiving the ringing response message from the called network device, the calling network device sends a ringing response message to the calling electronic device.

[0240] In other cases, when the called electronic device receives an invitation message from the called-side network device, if it also receives a call connection operation from the called user for the calling electronic device, it can send an answer response message to the called-side network device. This answer response message can be a 200 OK response to the invitation message, indicating that the called electronic device has accepted the calling electronic device's RTT call request. Subsequently, upon receiving the answer response message from the called electronic device, the called-side network device sends an answer response message to the calling-side network device. Then, upon receiving the answer response message from the called-side network device, the calling-side network device sends an answer response message to the calling electronic device.

[0241] Subsequently, upon receiving the response message from the calling network device, the calling electronic device sends an acknowledgment message to the calling network device. The acknowledgment (ACK) message indicates that the calling electronic device has received the response message from the called electronic device. This response message may include at least one of a transmission response message, a ringing response message, and an answer response message. Then, upon receiving the acknowledgment message from the calling electronic device, the calling network device sends an acknowledgment message to the called network device. Finally, upon receiving the acknowledgment message from the calling network device, the called network device sends an acknowledgment message to the called electronic device.

[0242] It's understandable that if the called electronic device receives a response message from the called network device, it means that a voice call has been established between the called and called electronic devices. Therefore, the calling electronic device can communicate with the called electronic device via the RTP protocol.

[0243] This application provides another call method. In this embodiment, if a user's call initiation operation is detected and the call fails, the calling electronic device can use the media stream type from a historical SIP message as the media stream type in a second SIP message. The historical SIP message corresponds to the SIP message from a previous successful call made by the calling electronic device in the first mobile communication network. Subsequently, the calling electronic device can use the second SIP message to negotiate a call with the calling network device, thereby enabling the calling electronic device to establish a target call with the called electronic device. Specifically, as shown... Figure 11 As shown, the call method provided in this application embodiment may include S1101 to S1111:

[0244] S1101, The calling electronic device receives the user's call initiation operation.

[0245] S1102, the calling electronic device initiates a call request to the calling network device in the first mobile communication network using a first SIP message.

[0246] S1103, the calling electronic device determines whether the call was successful.

[0247] In some embodiments, after initiating a call request to the calling network device, the calling electronic device can determine whether the call is successful. If the call is successful, the calling electronic device can execute step S1104 to achieve efficient establishment of the RTT call, reduce the possibility of downgraded or abnormally interrupted RTT call, and improve the user's call experience.

[0248] In some embodiments, if the call fails, the calling network device may not support all media stream types or call parameters in the first SIP message. For example, the calling network device may not support RTT call functionality. Alternatively, if the calling electronic device receives a second response message, it may determine that the calling network device does not support the target media stream type, such as the text type corresponding to the RTT call function. Therefore, the calling electronic device can execute step S1105, using the media stream type in the historical SIP message as the media stream type in the second SIP message, making the adjusted second SIP message different from the first SIP message. The media stream type included in the adjusted second SIP message may be supported by the calling network device. Thus, by further negotiating the call with the calling network device through the second SIP message, it can ensure that the call can be conducted in the first mobile communication network as much as possible, reducing the probability of call degradation or abnormal call interruption, thereby improving the user's call experience.

[0249] S1104, In the event of a successful call, the calling electronic device establishes an RTT call with the called electronic device in the first mobile communication network.

[0250] It should be noted that steps S1101 to S1104 are similar to steps S601 to S604 in the above embodiment 1, and will not be described again here.

[0251] S1105, In the event of a failed call, the calling electronic device determines whether the redial stop condition is met.

[0252] Specifically, after receiving the first SIP message, the calling electronic device can determine whether the redial stop condition is met. The redial stop condition may include the number of times the call request is re-initiated being greater than or equal to the total number of SIP messages recorded during successful calls in the calling electronic device's history, or the number of times the call request is re-initiated being greater than a preset number.

[0253] In some embodiments, if the redial stop condition is met, it means that the calling electronic device does not need to initiate a call request to the calling network device again. Therefore, to ensure that the call can proceed normally, the calling electronic device can execute step S1109 to determine whether the call can be conducted in the second mobile communication network, thereby maximizing the probability of call success and ensuring the user experience. If the redial stop condition is not met, it means that the calling electronic device still has the possibility of a successful call. Therefore, to reduce the probability of call degradation or abnormal call interruption, the calling electronic device can execute step S1106 to use the media stream type in the historical SIP message as the media stream type in the second SIP message, thereby ensuring that the call can be conducted in a high-speed communication network and improving the user's call experience.

[0254] S1106, if the redial stop condition is not met, the calling electronic device obtains the historical SIP messages and uses the media stream type in the historical SIP messages as the media stream type in the second SIP message.

[0255] Specifically, after determining that the redial termination conditions are not met, the calling electronic device can retrieve historical SIP messages. These historical SIP messages correspond to the SIP messages from the calling electronic device's previous successful call within the first mobile communication network. The calling electronic device can then use the media stream type from the historical SIP messages as the media stream type in the second SIP message. In other words, the call parameters for the media stream type in the second SIP message can be the same as the call parameters for the media stream type in the historical SIP messages.

[0256] In some cases, the media stream types in the aforementioned historical SIP messages may be only a subset of the multiple media stream types included in the first SIP message. For example, if the first SIP message includes both text and audio types, the historical SIP message may include the audio type.

[0257] In other cases, the media stream types in the aforementioned historical SIP messages are consistent with the multiple media stream types included in the first SIP message. For example, if the first SIP message includes text and audio types, the historical SIP messages may include text and audio types.

[0258] In some cases, the media stream type in historical SIP messages may include only the preset media stream type (such as audio type).

[0259] In some cases, call failure may be due to the calling network device not supporting the target media stream type. Therefore, to ensure successful re-calls, the media stream type in historical SIP messages may not include the target media stream type (such as text).

[0260] It is understood that the aforementioned historical SIP messages can be the most recent SIP message recorded by the calling electronic device, any SIP message from the preset number of SIP messages recorded by the calling electronic device that are most recent to the current call, or any SIP message from all SIP messages recorded by the calling electronic device when a previous call was successfully completed, etc., and there are no specific limitations.

[0261] For example, taking the historical SIP messages recorded by the calling electronic device as the most recent SIP message for this call, if the media stream type included in the historical SIP message is audio and text, it indicates that the calling electronic device successfully conducted an RTT call last time. Therefore, the calling electronic device can use audio and text as the media stream type in the second SIP message to ensure that this RTT call can also proceed normally in RTT call mode. If the media stream type included in the historical SIP message is audio, it indicates that the calling electronic device successfully conducted a voice call last time. Therefore, the calling electronic device can use audio as the media stream type in the second SIP message to ensure that this call can proceed in voice call mode.

[0262] S1107, the calling electronic device, in the first mobile communication network, uses a second SIP message to re-initiate a call request to the calling network device.

[0263] Specifically, after receiving the second SIP message, the calling electronic device can use the second SIP message in the first mobile communication network to re-initiate a call request to the calling network device, thereby determining whether the call was successful, that is, whether the calling electronic device can establish a call connection with the called electronic device.

[0264] In some embodiments, after the calling electronic device re-initiates a call request to the calling network device, it can again determine whether the call was successful. If the call is successful, the calling electronic device can execute step S1108 to establish a two-way call, thereby ensuring the call quality of both devices, reducing the possibility of call degradation or abnormal interruption, and improving the user's call experience. If the call fails, the calling electronic device can further determine whether the calling network device supports a second mobile communication network, that is, the calling electronic device can execute step S1109 to ensure that the call can proceed normally as much as possible.

[0265] S1108, if the call is successful, the calling electronic device establishes a target call with the called electronic device in the first mobile communication network.

[0266] S1109, if the redial stop condition is met, the calling electronic device determines whether the calling side network device supports the second mobile communication network.

[0267] In some embodiments, after a call fails, or after the redial stop condition is met, the calling electronic device can determine whether the calling-side network device supports the second mobile communication network. If the calling-side network device supports the second mobile communication network, it means that the call can proceed under the second mobile communication network. Therefore, the calling electronic device can execute step S1110 to ensure that the call can proceed normally, thereby reducing the probability of abnormal call interruption. If the calling-side network device does not support the second mobile communication network, it means that the call cannot proceed under the second mobile communication network. Therefore, the calling electronic device can execute step S1111 to generate a prompt message indicating that the call has failed, so that the user can be informed of the call failure in a timely manner.

[0268] S1110, when the calling network device supports the second mobile communication network, the calling electronic device establishes a target call with the called electronic device in the second mobile communication network.

[0269] S1111, the calling electronic device fails to make a call if the calling network device does not support the second mobile communication network.

[0270] It should be noted that the steps S1110 to S1111 are similar to the steps S611 to S612 in the above embodiment 1, and will not be described again here.

[0271] The above describes how the calling electronic device uses historical SIP messages recorded from previous successful calls to negotiate a call with the called electronic device, ensuring the call can be established over a high-speed communication network. The following will use examples of historical SIP messages including audio types, combined with the above... Figure 4 The communication system shown and Figure 12 The call process shown illustrates, for example, how a calling electronic device establishes a call connection with a called electronic device.

[0272] The calling electronic device receives the call initiation operation from the calling user. Then, the calling electronic device can send an invitation message to the calling network device. The invitation (INVITE) message is used to request the called electronic device to establish a session, which is equivalent to SDP-Offer negotiation. This invitation message carries a first SIP message, which includes audio and text types. After receiving the invitation message from the calling electronic device, if the calling network device does not support the text type, it means that the calling network device does not support RTT (Round-Trip) calling functionality. Therefore, the calling network device can return a second response message to the calling electronic device. This second response message can be a 503 message, which informs the calling electronic device that it does not support RTT calling functionality corresponding to the text type. After receiving the second response message from the calling network device, the calling electronic device retrieves historical SIP messages, which include audio types.

[0273] Subsequently, the calling electronic device can send an invitation message to the calling network device again. This invitation message is equivalent to SDP-Offer negotiation and carries the audio type included in the aforementioned historical SIP messages. Then, upon receiving the invitation message from the calling electronic device, the calling network device sends an invitation message to the called network device. Next, upon receiving the invitation message from the calling network device, the called network device sends an invitation message to the called electronic device. Then, upon receiving the invitation message from the called network device, the called electronic device sends a third response message to the called network device. This third response (ANSWER) message can be a 183 message, indicating that the session is in progress, but the called electronic device has not answered. This third response message is equivalent to SDP-Answer negotiation and carries the audio type. Finally, upon receiving the third response message from the called electronic device, the called network device sends a third response message to the calling network device. Subsequently, upon receiving the third response message from the called network device, the calling network device sends a third response message to the calling electronic device.

[0274] Subsequently, upon receiving the third response message from the calling network device, the calling electronic device sends an acknowledgment request message to the calling network device. This acknowledgment request message can be a PRACK message, used to verify the reliability of the response message, thus ensuring that the session request is not interrupted or lost during the establishment of the voice call. Following this, upon receiving the acknowledgment request message from the calling electronic device, the calling network device sends an acknowledgment request message to the called network device. Subsequently, upon receiving the acknowledgment request message from the calling network device, the called network device sends an acknowledgment request message to the called electronic device. Following this, upon receiving the acknowledgment request message from the called network device, the called electronic device sends a transmission response message to the called network device. This transmission response message can be a 200 OK response message to the acknowledgment request message, used to indicate that the transmission of the response message was reliable. Finally, upon receiving the transmission response message from the called electronic device, the called network device sends a transmission response message to the calling network device. Subsequently, upon receiving the transmission response message from the called network device, the calling network device sends a transmission response message to the calling electronic device, so that the calling electronic device can know whether the transmission process of the aforementioned third response message is reliable.

[0275] In some cases, upon receiving an invitation message from the called network device, the called electronic device can also send a ringing response message to the called network device. This ringing response message can be a 180 Ringing message, used to notify the calling electronic device that the called electronic device is ringing. Subsequently, upon receiving the ringing response message from the called electronic device, the called network device sends a ringing response message to the calling network device. Then, upon receiving the ringing response message from the called network device, the calling network device sends a ringing response message to the calling electronic device.

[0276] In other cases, when the called electronic device receives an invitation message from the called-side network device, if it also receives a call connection operation from the called user for the calling electronic device, it can send an answer response message to the called-side network device. This answer response message can be a 200 OK response to the invitation message, indicating that the called electronic device has accepted the calling electronic device's RTT call request. Subsequently, upon receiving the answer response message from the called electronic device, the called-side network device sends an answer response message to the calling-side network device. Then, upon receiving the answer response message from the called-side network device, the calling-side network device sends an answer response message to the calling electronic device.

[0277] Subsequently, upon receiving the response message from the calling network device, the calling electronic device sends an acknowledgment message to the calling network device. The acknowledgment (ACK) message indicates that the calling electronic device has received the response message from the called electronic device. This response message may include at least one of a transmission response message, a ringing response message, and an answer response message. Then, upon receiving the acknowledgment message from the calling electronic device, the calling network device sends an acknowledgment message to the called network device. Finally, upon receiving the acknowledgment message from the calling network device, the called network device sends an acknowledgment message to the called electronic device.

[0278] It's understandable that if the called electronic device receives a response message from the called network device, it means that a voice call has been established between the called and called electronic devices. Therefore, the calling electronic device can transmit audio to the called electronic device via the RTP protocol.

[0279] In some embodiments, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described above.

[0280] In some embodiments, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described above.

[0281] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0282] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0283] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0284] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0285] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0286] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for making a call, characterized in that, Applied to a calling electronic device, the method includes: In response to a user's call initiation operation, the calling electronic device initiates a call request to the calling network device in the first mobile communication network using a first session initiation protocol (SIP) message; wherein the first SIP message includes multiple media stream types, and the multiple media stream types include a target media stream type; In the event of a failed call, the calling electronic device, within the first mobile communication network, uses a second SIP message to re-initiate a call request to the calling network device; wherein the second SIP message is not entirely the same as the media stream type and / or the call parameters of the media stream type included in the first SIP message.

2. The method according to claim 1, characterized in that, Before the calling electronic device re-initiates a call request to the calling-side network device, the method further includes: The calling electronic device receives a first response message sent by the calling side network device; wherein the first response message is used to indicate that the call failed.

3. The method according to claim 1, characterized in that, Before the calling electronic device re-initiates a call request to the calling-side network device, the method further includes: The calling electronic device receives a second response message sent by the calling-side network device; wherein the second response message is used to indicate that the calling-side network device does not support the call function corresponding to the target media stream type.

4. The method according to any one of claims 1-3, characterized in that, The media stream types included in the second SIP message are some of the media stream types included in the first SIP message.

5. The method according to any one of claims 1-4, characterized in that, The media stream types included in the second SIP message are obtained by deleting a portion of the media stream types from the plurality of media stream types included in the first SIP message.

6. The method according to claim 4 or 5, characterized in that, The media stream type in the second SIP message does not include the target media stream type; the media stream type included in the second SIP message is obtained by deleting the target media stream type from the plurality of media stream types included in the first SIP message.

7. The method according to claim 6, characterized in that, Among the multiple media stream types included in the first SIP message, the media stream types are deleted in the order of their arrangement from back to front.

8. The method according to any one of claims 4-7, characterized in that, The media stream types included in the second SIP message are obtained by deleting a first preset number of media stream types other than the preset media stream types from the plurality of media stream types included in the first SIP message each time.

9. The method according to claim 7, characterized in that, In the first SIP message, among the multiple media stream types, the preset media stream type is positioned before the other media stream types.

10. The method according to any one of claims 1-9, characterized in that, After the calling electronic device re-initiates a call request to the calling-side network device, the method further includes: If the call fails, the calling electronic device in the first mobile communication network will use a new second SIP message to re-initiate the call request to the calling network device until the call is successful or until the redial stop condition is met.

11. The method according to claim 10, characterized in that, The method further includes: When the redialing stop condition is met, the calling electronic device sends a call request to the calling side network device in the second mobile communication network; wherein the network generation of the second mobile communication network is lower than that of the first mobile communication network.

12. The method according to claim 10 or 11, characterized in that, The conditions for stopping the redial include: The number of media stream types included in the new second SIP message is equal to the second preset number; or, The number of times a call request is re-initiated is greater than or equal to the preset number.

13. The method according to any one of claims 1-3, characterized in that, The media stream type included in the second SIP message is the same as the media stream type included in the historical SIP message. The historical SIP message is the SIP message corresponding to the previous successful call made by the calling electronic device in the first mobile communication network.

14. The method according to claim 13, characterized in that, The call parameters for the media stream type in the second SIP message are the same as the call parameters for the media stream type in the historical SIP messages.

15. The method according to claim 13 or 14, characterized in that, The media stream types in the historical SIP messages are a subset of the media stream types included in the first SIP message; or, The media stream types in the historical SIP messages are consistent with the multiple media stream types included in the first SIP message; or, The media stream types in the historical SIP messages include preset media stream types.

16. The method according to any one of claims 13-15, characterized in that, After the calling electronic device re-initiates a call request to the calling-side network device, the method further includes: If the call fails, the calling electronic device in the first mobile communication network will use a new second SIP message to re-initiate the call request to the calling network device until the call is successful or until the redial stop condition is met. The media stream type included in the new second SIP message is the same as the media stream type included in another historical SIP message.

17. The method according to any one of claims 13-16, characterized in that, The method further includes: When the redial stop condition is met, the calling electronic device sends a call request to the calling side network device in the second mobile communication network, where the network generation of the second mobile communication network is lower than that of the first mobile communication network. The call-back stopping conditions include: The number of times a call request is re-initiated is greater than or equal to the total number of different SIP messages recorded when a historical call was successful; or, The number of times a call request is re-initiated is greater than or equal to the preset number.

18. A communication system, characterized in that, The call system includes a calling electronic device, a calling-side network device, a called electronic device, and a called-side network device. The calling-side network device is communicatively connected to the calling electronic device and the called-side network device, respectively. The called electronic device is communicatively connected to the called-side network device. The calling electronic device is used to execute the call method as described in any one of claims 1-17.

19. An electronic device, characterized in that, The device includes a memory and one or more processors; the memory and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 17.

21. A computer program product, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 17.

Images