Video call processing method, device and equipment and computer program product

Abstract

Disclosed are a video call processing method, apparatus and device, and a computer program product, the method comprising: receiving a first video call update message sent by a network side, the message indicating that the network side has successfully updated session parameters and the current session only supports audio transmission; in response to the first video call update message, sending a second video call update message to the network side, the message indicating that the transmission mode of the current session is ready to be degraded into audio transmission; and receiving a response result of the network side to the second video call update message, and processing the current session by adopting a corresponding call processing strategy according to the response result, the call processing strategy comprising a degraded call strategy. According to the method and the device, a dynamic degradation mechanism in an abnormal scene is introduced, so that the robustness and the user experience of the video call are improved, call failure caused by network abnormity is avoided, the characteristic that audio transmission has relatively low network requirements is fully utilized, and the call success rate and the user experience are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of call processing, and in particular to a video call processing method, device and equipment, and a computer program product. BACKGROUND

[0002] With the rapid development of mobile communication technology, the video call function has become one of the important functions of mobile terminal devices such as smart phones, which breaks the geographical restrictions and enables people to communicate more intuitively and conveniently. However, in the actual video call process, due to the complexity and uncertainty of the network environment, various problems often occur, which seriously affect the call quality and user experience.

[0003] During the establishment and process of the video call, a series of signaling interactions and resource reservation operations need to be performed between the network side (NW) and the user equipment (UE) to ensure the smooth progress of the call. Among them, the network side will send an Update message to the UE to update the related parameters and state information of the call. In normal cases, the Update message will contain complete parameters, for example, for video calls, the mainline=video item will be explicitly identified to inform the UE that the main service type of the current call is video, and the modem of the UE will perform corresponding processing and resource allocation according to these information, thereby maintaining the normal progress of the video call.

[0004] However, in the actual network environment, due to the influence of various factors such as network congestion, signal interference, base station failure and other network side reasons, the Update message sent by the network to the UE may be abnormal. One of the more common and serious abnormal conditions that affect the call is the absence of the mainline=video item in the Update message. When the phone receives such an abnormal Update message with missing, since the modem design is usually based on normal message format programming and processing, it lacks an effective response mechanism for such abnormal conditions, resulting in the modem being unable to correctly parse and process the message. In this case, the modem will trigger a local release operation, which will cause the ongoing video call to fail.

[0005] This call failure problem caused by the missing of the key item of the Update message due to the network anomaly is universal and persistent in the current network coverage. Once such a network anomaly occurs, all video calls under this network coverage may face the same risk, and since the solution to the network problem often requires a certain amount of time and complex technical means, the anomaly cannot be automatically restored during this period. For users, this means that when making a video call in a specific network environment, they frequently encounter call failures, which seriously affects the user's experience and reduces the user's trust and dependence on the video call function.

[0006] Currently, there is no effective technical solution to specifically address this particular network anomaly to ensure that the video call can maintain a certain call quality when facing such problems and reduce the call failure rate. Therefore, it is of great practical significance and urgent market demand to develop a technical solution that can effectively handle the abnormal Update message received by the UE and ensure the call success rate. SUMMARY

[0007] The embodiments of the present application provide a video call processing method, device and equipment, and a computer program product to improve the call success rate and enhance the user experience.

[0008] The embodiments of the present application adopt the following technical solutions:

[0009] In a first aspect, the embodiments of the present application provide a video call processing method, which comprises:

[0010] receiving a first video call update message sent by a network side, the first video call update message indicating that the network side has successfully updated the session parameters and that the current session only supports audio transmission;

[0011] in response to the first video call update message, sending a second video call update message to the network side, the second video call update message indicating that the transmission mode of the current session is ready to be downgraded to audio transmission;

[0012] receiving a response result of the network side to the second video call update message, and according to the response result, taking a corresponding call processing strategy to process the current session, the call processing strategy including a downgrade call strategy.

[0013] Optionally, the response to the first video call update message and sending a second video call update message to the network side comprises:

[0014] in response to the first video call update message, suspending the video transmission process and sending the second video call update message to the network side.

[0015] Optionally, the processing of the current session according to the response result comprises:

[0016] determining whether a transmission mode downgrade confirmation message sent by the network side is received according to the response result;

[0017] downgrading the current session according to a corresponding downgrade session strategy in the case that the transmission mode downgrade confirmation message sent by the network side is received.

[0018] Optionally, the downgrading of the current session according to a corresponding downgrade session strategy in the case that the transmission mode downgrade confirmation message sent by the network side is received comprises:

[0019] determining whether a ring message sent by the network side is received in the case that the transmission mode downgrade confirmation message sent by the network side is received, the ring message indicating that the session request is received by the opposite end device and the ring is started;

[0020] downgrading the current session according to a corresponding downgrade session strategy in the case that the ring message sent by the network side is received.

[0021] Optionally, the downgrading of the current session according to a corresponding downgrade session strategy in the case that the ring message sent by the network side is received comprises:

[0022] determining whether a wireless resource reconfiguration and specific resource release message sent by the network side is received according to the response result;

[0023] downgrading the transmission mode of the current session to audio transmission according to a corresponding downgrade session strategy in the case that the wireless resource reconfiguration and specific resource release message sent by the network side is received and the ring message sent by the network side is received.

[0024] downgrading the transmission mode of the current session to audio transmission according to a corresponding downgrade session strategy in the case that the wireless resource reconfiguration and specific resource release message sent by the network side is not received but the ring message sent by the network side is received, and determining whether the specific resource is released by the network side after the session is ended.

[0025] Optionally, the video session processing method further comprises:

[0026] processing the current session according to a protocol session processing strategy in the case that the transmission mode downgrade confirmation message sent by the network side or other indication message is not received, the protocol session processing strategy comprising an end session strategy.

[0027] Optionally, the method further comprises:

[0028] determining whether the network side releases the specific resource after the call ends;

[0029] actively releasing the RRC link through a Local Release procedure in a case that the network side does not release the specific resource.

[0030] In a second aspect, the embodiments of the present application further provide a video call processing apparatus, comprising:

[0031] a receiving unit configured to receive a first video call update message sent by a network side, the first video call update message indicating that the network side has successfully updated session parameters and that the current session only supports audio transmission;

[0032] a sending unit configured to send a second video call update message to the network side in response to the first video call update message, the second video call update message indicating that the transmission mode of the current session is ready to be degraded to audio transmission;

[0033] a call processing unit configured to receive a response result of the network side to the second video call update message, and to process the current session according to a corresponding call processing strategy based on the response result, the call processing strategy including a degradation call strategy.

[0034] In a third aspect, the embodiments of the present application further provide an apparatus, comprising:

[0035] a processor; and a memory arranged to store computer executable instructions that, when executed, cause the processor to perform any of the aforementioned video call processing methods.

[0036] In a fourth aspect, the embodiments of the present application further provide a computer program product comprising computer programs / instructions, which, when executed by a processor, implement any of the aforementioned video call processing methods.

[0037] The at least one technical solution adopted by the embodiments of the present application can achieve the following beneficial effects: The video call processing method of the embodiments of the present application first receives a first video call update message sent by a network side, the first video call update message indicating that the network side has successfully updated session parameters and that the current session only supports audio transmission; then, in response to the first video call update message, a second video call update message is sent to the network side, the second video call update message indicating that the transmission mode of the current session is ready to be degraded to audio transmission; finally, a response result of the network side to the second video call update message is received, and according to the response result, a corresponding call processing strategy is adopted to process the current session, the call processing strategy including a degradation call strategy. The video call processing method of the embodiments of the present application introduces a dynamic degradation mechanism in an abnormal scenario, which significantly improves the robustness and user experience of video calls. When the network side causes the SIP Update message to lack video parameters due to resource limitations or protocol errors, etc., the UE no longer directly releases the call due to the inability to analyze the abnormality, but actively identifies the "audio only" identifier and sends a degradation confirmation message, so that the session can be seamlessly switched to a pure audio mode, effectively avoiding call failures caused by network abnormalities, fully utilizing the characteristics of audio transmission requiring lower network requirements, improving the call success rate, and improving the user experience. BRIEF DESCRIPTION OF DRAWINGS

[0038] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application and illustrate the illustrative embodiments of the present application and their description serve to explain the present application, and do not constitute improper limitations on the present application. In the drawings:

[0039] Figure 1 FIG. 1 is a schematic diagram of a normal call flow and an abnormal call flow in the prior art;

[0040] Figure 2 FIG. 5 is a flowchart of a video call processing method in the embodiments of the present application;

[0041] Figure 3 FIG. 6 is a schematic diagram of a video call processing flow in the embodiments of the present application;

[0042] Figure 4 FIG. 7 is a schematic diagram of a video call processing device in the embodiments of the present application;

[0043] Figure 5 FIG. 8 is a schematic diagram of a device in the embodiments of the present application. DETAILED DESCRIPTION

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0045] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0046] For ease of understanding of the various embodiments of this application, as follows: Figure 1 The diagram illustrates a normal call process and an abnormal call process in the prior art.

[0047] I. Normal Call Procedure

[0048] 1. Call Initiation Phase

[0049] UE initiates SIP INVITE request: The UE sends a SIP INVITE message to the network side (NW) carrying an SDP offer (Session Description Protocol offer), in which the media description fields m=audio & m=video indicate a request to establish a dual-stream audio and video call.

[0050] 2. Provisional Response and Session Negotiation

[0051] 100 Trying Response: NW returns 100 Trying immediately after receiving INVITE, indicating that the request has been received and is being processed.

[0052] 183 Session Progress (SDP): NW returns temporary session progress via 183 messages, carrying SDP information to negotiate media parameters (such as codec, port number, etc.).

[0053] 3. Reliability Validation (PRACK Process)

[0054] UE sends SIP PRACK: The UE confirms the reliability of the 183 response by sending a PRACK (Provisional Response Acknowledgment).

[0055] NW replies PRACK 200OK: NW confirms successful PRACK reception, completing reliable transmission of the temporary response.

[0056] 4. Establishment of the carrier

[0057] Audio / Video QCI Bearer Establishment: The UE and NW establish dedicated bearers for audio (QCI=1) and video (QCI=2) respectively.

[0058] 5. SDP Update and Confirmation

[0059] UE initiates SDP Update: The UE updates media parameters (such as adjusting resolution) through SDP Update messages based on local resources or user operations.

[0060] NW responds with Update 200 OK (SDP Answer): NW returns an updated SDP Answer containing complete audio and video media descriptions (m=audio & m=video).

[0061] 6. Call connection phase

[0062] 180 Ringing and Off-Hand: The NW sends a 180 Ringing prompt and rings. After the user goes off-hand, the system returns SIP 200 OK. The UE sends a SIP ACK to confirm and complete the call setup.

[0063] II. Abnormal Call Procedure

[0064] 1. The preceding process is consistent with the normal process.

[0065] The call initiation, provisional response, PRACK confirmation, and bearer establishment steps are the same as the normal process, up to the SDPUpdate stage.

[0066] 2. Trigger point: SDP Answer downgrade

[0067] NW responded with Update 200 OK (Abnormal SDP Answer): In the SDP Update response, NW returned an SDPANwer containing only the audio media description (Only m=audio), missing video stream information.

[0068] Possible causes: insufficient network resources, SDP negotiation errors, or abnormal core network configuration.

[0069] 3. UE-side exception handling failed.

[0070] Modem cannot resolve abnormal SDP: The UE's modem design does not consider abnormal scenarios where video stream information is missing, and it cannot process SDP answers containing only audio.

[0071] Triggering Local Release: Due to a conflict in the protocol stack logic, the modem actively triggers the local release process (Local release happened), terminating the current session.

[0072] 4. Call failed

[0073] NW detects Call Fail: The core network determines the call to have failed because it did not receive the expected signaling (such as SIP ACK or media stream).

[0074] It can be seen that in the existing call process described above, the UE side lacks fault tolerance handling logic for SDP Answer anomalies. When video stream information is missing, the session is released directly, resulting in a decline in user experience.

[0075] Based on this, embodiments of this application provide a video call processing method, such as... Figure 2 The diagram shows a flowchart of a video call processing method according to an embodiment of this application. The video call processing method includes the following steps S210 to S230:

[0076] Step S210: Receive a first video call update message sent by the network side. The first video call update message indicates that the network side has successfully updated the session parameters and that the current session only supports audio transmission.

[0077] Combination Figure 3 This document provides a schematic diagram of a video call processing flow in an embodiment of this application. The UE receives the first video call update message, i.e., the SDP Update response message (update ok), sent by the network side. By parsing the SDP parameters, it finds only the m=audio identifier, indicating that the network side has successfully updated the session parameters and the current session only supports audio transmission. The UE triggers a degradation processing flow based on a preset exception handling strategy (such as an audio-only degradation rule), instead of directly executing local release.

[0078] Step S220: In response to the first video call update message, a second video call update message is sent to the network side, the second video call update message indicating that it is ready to downgrade the transmission mode of the current session to audio transmission.

[0079] The UE generates a second video call update message, namely a new SDP Update request message. It retains only the m=audio parameter in the media description field and removes all video-related configurations (such as m=video, codec parameters, etc.), forming an update message confirming the downgrade (update (audio only)). This indicates that the UE accepts and is ready to downgrade the transmission mode of the current session to audio transmission.

[0080] Step S230: Receive the response result from the network side to the second video call update message, and process the current session according to the response result using a corresponding call processing strategy, the call processing strategy including a downgraded call strategy.

[0081] The UE receives the network's response to the update (audio only) message and determines the appropriate call processing strategy based on that response. For example, if the network returns a message confirming call degradation, the UE employs a downgraded call strategy to degrade the current session, reducing its transmission mode to audio-only. This ensures call success rate and improves user experience even in scenarios with abnormal video streams.

[0082] The video call processing method in this application significantly improves the robustness and user experience of video calls by introducing a dynamic degradation mechanism under abnormal scenarios. When the SIP Update message is missing video parameters due to network resource limitations or protocol errors, the UE no longer directly releases the call because it cannot resolve the anomaly. Instead, it actively identifies the "audio only" flag and sends a degradation confirmation message, enabling the session to seamlessly switch to pure audio mode. This effectively avoids call failures caused by network anomalies, fully utilizes the low network requirements of audio transmission, improves call success rate, and enhances user experience.

[0083] In some embodiments of this application, sending a second video call update message to the network side in response to the first video call update message includes: suspending the video transmission process and sending the second video call update message to the network side in response to the first video call update message.

[0084] When the UE receives the "update ok (only m=audio)" message from the network, it immediately triggers a video transmission process suspension operation. This message explicitly includes an identifier indicating that only audio transmission is supported (only m=audio), suggesting that the network is forcibly requiring session degradation due to resource limitations or protocol anomalies. At this point, the UE immediately stops data encapsulation and parsing by the video encoder / decoder, releasing the transport layer port resources occupied by the video stream.

[0085] Subsequently, the UE generates an update (only m=audio) message containing only audio parameters according to the network's requirements. Specifically, it removes all video-related media description lines (m=video and its associated codec parameters, port numbers, etc.) from the original SDP. It retains the audio media description line (m=audio) and updates the session version number to indicate the negotiated result after the downgrade.

[0086] Finally, a reconstructed update (only m=audio) message is sent to the network side via the SIP protocol stack, and a timeout retransmission mechanism can also be initiated. If the network supports a temporary response reliability mechanism (such as PRACK), the network side's acknowledgment response is processed synchronously to ensure that the degradation command has been accurately delivered.

[0087] This application's embodiments achieve smooth fault tolerance for video calls under abnormal network conditions by proactively responding to network-side degradation commands and quickly suspending the video transmission process. Specifically, by instantly releasing video resources, adjusting bearer configurations, and sending confirmation messages, forced call failures caused by the protocol stack's inability to parse abnormal SDPs are avoided. This mechanism not only ensures the continuity of audio calls but also reduces network load through dynamic resource optimization, improving the robustness of the video call system in complex network environments and effectively balancing call reliability and resource utilization.

[0088] In some embodiments of this application, the step of processing the current session by adopting a corresponding call processing strategy based on the response result includes: determining whether a transmission mode downgrade confirmation message sent by the network side has been received based on the response result; and, if a transmission mode downgrade confirmation message sent by the network side has been received, adopting a corresponding downgrade call strategy to downgrade the current session.

[0089] After receiving the response message from the network, the UE can first perform signaling integrity verification, including SIP status code parsing (e.g., 200 OK), message header field verification, and SDP parameter validity checks, to ensure that the response message is a valid transmission mode downgrade confirmation (update 200 OK (audio only)). By parsing the SDP message body, if it is confirmed that it only contains the m=auido identifier, which is consistent with the expected downgrade parameters, it is clear that the network has accepted the UE's downgrade request and completed the parameter configuration.

[0090] On the UE side, the video stream transmission port is closed, the data processing of the video codec is stopped, and the video buffer is cleared to prevent residual data from interfering with audio transmission.

[0091] This application embodiment achieves precise fault tolerance and resource optimization for video call systems in abnormal scenarios through a closed-loop degradation processing mechanism based on response confirmation. When the network side returns a degradation confirmation message, the UE ensures the validity of the instruction through strict signaling verification, and then executes the degradation processing flow, which improves the adaptability of the video call system in complex network environments and effectively balances the efficiency of abnormal handling with the guarantee of user experience.

[0092] In some embodiments of this application, the step of downgrading the current session by adopting a corresponding downgraded call strategy upon receiving a transmission mode downgrade confirmation message sent by the network side includes: upon receiving a transmission mode downgrade confirmation message sent by the network side, determining whether a ringing message sent by the network side has been received, wherein the ringing message indicates that the peer device has received the call request and started ringing; and upon receiving a ringing message sent by the network side, adopting a corresponding downgraded call strategy to downgrade the current session.

[0093] After receiving the transmission mode downgrade confirmation message (update 200OK(only m=audio)) from the network side, the UE listens for a ringing message (180 Ring) from the network side. This message indicates that the peer device has received the call request and triggered a user ringing notification. When a valid 180 Ring message is detected, the UE automatically triggers the downgrade process, releasing the hardware acceleration resources occupied by the video encoder in advance and closing the video stream transmission port to avoid initialization failure due to resource conflicts after the peer answers the call.

[0094] This application embodiment achieves dual optimization of call establishment success rate and user experience in abnormal network environments by deeply coupling transmission mode degradation confirmation with ringing message arrival status. Specifically, after confirming that the network side accepts the degradation parameters, the UE waits for the peer device's ringing response before performing the final degradation operation. This ensures strict synchronization between session mode switching and peer status changes, avoids media capability mismatch issues caused by unilateral degradation, reduces the probability of initialization failure due to resource conflicts at the moment of answering, and achieves an organic balance between call establishment reliability and resource utilization efficiency in complex network fluctuation scenarios.

[0095] In some embodiments of this application, the step of downgrading the current session by adopting a corresponding downgraded call strategy upon receiving a ringing message from the network side includes: determining, based on the response result, whether a message for wireless resource reconfiguration and release of specific resources sent by the network side has been received; if a message for wireless resource reconfiguration and release of specific resources sent by the network side has been received, and a ringing message sent by the network side has also been received, downgrading the transmission mode of the current session to audio transmission by adopting a corresponding downgraded call strategy; if a message for wireless resource reconfiguration and release of specific resources has not been received, but a ringing message sent by the network side has been received, downgrading the transmission mode of the current session to audio transmission by adopting a corresponding downgraded call strategy; and determining whether the network side releases specific resources after the call ends.

[0096] Continue to refer to Figure 3When the UE is listening to the ringing message (180 Ring) sent by the network side, it also needs to listen to the Radio Resource Control (RRC) reconfiguration message and focus on checking whether it contains the instruction to "release QCI=2 dedicated bearer" (i.e. delete the data radio bearer related to video transmission).

[0097] If both an RRC reconfiguration message releasing QCI=2 resources and a ringing message from the network side are received simultaneously, the synchronization resource cleanup process is immediately triggered. Specifically, the QCI=2 data radio bearer (DRB) can be immediately deleted according to the RRC command, releasing the air interface video transmission resources. A video bearer deletion confirmation is sent to the core network via NAS layer signaling to ensure end-to-end resource state consistency. In addition, the local session context is forcibly updated to "pure audio mode," and video-related functional modules (such as camera call interfaces, video rendering engines, etc.) are disabled.

[0098] If no RRC reconfiguration message is received but the ringing message is valid, call degradation is prioritized, and resource release can be postponed until after the call ends. Specifically, the QCI=2 resource can be marked as "pending release" in memory, but the actual deletion operation is not performed yet to ensure that the audio call establishment process is not blocked. After the call ends, a resource cleanup task is started to actively trigger Local Release to release the RRC link.

[0099] This application's embodiments achieve dual optimization of call success rate and resource utilization efficiency in complex signaling interaction scenarios by dynamically adapting the arrival time of RRC reconfiguration messages. In synchronous release scenarios, the UE strictly follows the protocol process to promptly clear video resources, ensuring efficient reclamation of air interface resources; while in asynchronous release scenarios, through a fault-tolerant design of "prioritizing call release and then releasing resources," it breaks through the strong dependence of traditional processes on RRC reconfiguration messages, prioritizing the rapid establishment of audio calls and significantly reducing call establishment failures caused by resource release timing issues.

[0100] In some embodiments of this application, the video call processing method further includes: processing the current session according to the call processing strategy of the protocol if no transmission mode downgrade confirmation message is received from the network side or no other indication message is received from the network side, wherein the call processing strategy of the protocol includes a call termination strategy.

[0101] The UE continuously tracks the network's response to the update (only m=audio) message, mainly involving the following scenarios:

[0102] 1) No response scenario: No response is received after exceeding the preset number of retransmissions (e.g., 3 times);

[0103] 2) Error response scenario: Receive a non-200 OK message returned by the network side (such as 488 Unacceptable Negotiation, 500 Internal Server Error, etc. SIP status codes).

[0104] The pre-defined protocol processing logic is triggered based on the response type. For example, if there is no response from the network side, the SIP timer timeout process is initiated, triggering the local session termination. If the network side has not released QCI 2, the UE side actively triggers resource release (LocalRelease). If the network side returns an error response, the SIP error code is parsed and mapped to a specific operation, such as a 488 error triggering SDP parameter adjustment and retrying.

[0105] This application's embodiments achieve standardized handling and resource security management of video call systems in extreme abnormal scenarios by constructing a protocol-compatible anomaly handling framework. When the network side does not respond or returns a non-degraded confirmation message, the UE strictly follows the protocol to execute the session termination procedure, ensuring signaling compliance; at the same time, through differentiated error code parsing and dynamic policy selection, it provides self-healing capabilities (such as retry mechanisms) for temporary network failures while ensuring system robustness, thereby improving the robustness of the video call system in complex network environments.

[0106] In some embodiments of this application, the video call processing method further includes: after the call ends, determining whether the network side releases a specific resource; if the network side does not release the specific resource, actively releasing the RRC link through the LocalRelease process.

[0107] After a call ends normally (e.g., after completing a SIP BYE signaling interaction) or is abnormally interrupted (e.g., the network side initiates a separation process), the UE immediately initiates a resource status detection process.

[0108] The UE obtains the currently active bearer configuration through the Radio Resource Control (RRC) layer interface and compares it to check if the QCI=2 video bearer still exists. If the local system detects that the QCI=2 data radio bearer (DRB) has not been released, the UE actively releases the RRC link through the Local Release procedure to ensure that the subsequent RRC status and resources remain consistent with the network side.

[0109] This application's embodiments effectively solve the problem of suspended video bearer resources caused by network-side anomalies by introducing a proactive resource release mechanism after a call, significantly improving the utilization efficiency of terminal and network resources. When the network fails to release specific resources in a timely manner due to signaling delays, protocol stack defects, or partial failures, the UE proactively triggers resource reclamation, avoiding the continuous occupation of radio spectrum and core network storage resources, and preventing subsequent call establishment failures caused by resource leakage.

[0110] This application also provides a video call processing device 400, such as... Figure 4 As shown, a schematic diagram of a video call processing device according to an embodiment of this application is provided. The video call processing device 400 includes:

[0111] The receiving unit 410 is used to receive a first video call update message sent by the network side, wherein the first video call update message indicates that the network side has successfully updated the session parameters and the current session only supports audio transmission.

[0112] The sending unit 420 is configured to send a second video call update message to the network side in response to the first video call update message, wherein the second video call update message indicates that it is ready to downgrade the transmission mode of the current session to audio transmission;

[0113] The call processing unit 430 is configured to receive the response result from the network side to the second video call update message, and to process the current session by adopting a corresponding call processing strategy based on the response result, wherein the call processing strategy includes a downgraded call strategy.

[0114] In some embodiments of this application, the sending unit 420 is specifically used to: suspend the video transmission process and send the second video call update message to the network side in response to the first video call update message.

[0115] In some embodiments of this application, the call processing unit 430 is specifically used to: determine whether a transmission mode downgrade confirmation message sent by the network side is received based on the response result; and if a transmission mode downgrade confirmation message is received by the network side, adopt a corresponding downgrade call strategy to downgrade the current session.

[0116] In some embodiments of this application, the call processing unit 430 is specifically used to: upon receiving a transmission mode downgrade confirmation message sent by the network side, determine whether a ringing message sent by the network side has been received, wherein the ringing message indicates that the peer device has received the call request and started ringing; upon receiving the ringing message sent by the network side, adopt a corresponding downgrade call strategy to downgrade the current session.

[0117] In some embodiments of this application, the call processing unit 430 is specifically configured to: determine whether a message for wireless resource reconfiguration and release of specific resources sent by the network side has been received based on the response result; if a message for wireless resource reconfiguration and release of specific resources sent by the network side has been received, and a ringing message sent by the network side has been received, adopt a corresponding downgraded call strategy to downgrade the transmission mode of the current session to audio transmission; if a message for wireless resource reconfiguration and release of specific resources sent by the network side has not been received, but a ringing message sent by the network side has been received, adopt a corresponding downgraded call strategy to downgrade the transmission mode of the current session to audio transmission, and determine whether the network side releases specific resources after the call ends.

[0118] In some embodiments of this application, the call processing unit 430 is further configured to: process the current session according to the call processing strategy of the protocol if no transmission mode downgrade confirmation message is received from the network side or the network side replies with other indication messages, wherein the call processing strategy of the protocol includes a call termination strategy.

[0119] In some embodiments of this application, the video call processing device 400 further includes: a resource release unit, used to determine whether the network side releases a specific resource after the call ends; and if the network side does not release the specific resource, to actively release the RRC link through a Local Release procedure.

[0120] It is understood that the above-described video call processing device can implement each step of the video call processing method provided in the foregoing embodiments. The relevant explanations of the video call processing method are applicable to the video call processing device and will not be repeated here.

[0121] Figure 5 This is a schematic diagram of the structure of a device according to an embodiment of this application. For example... Figure 5 As shown, the device includes one or more processors (or processing units), and may also include one or more memories coupled to the processors, and may also include a communication module coupled to the processors.

[0122] A communication module can be used to communicate with other devices or apparatuses, such as sending or receiving data and / or signals. A communication module may have at least one communication module for communication. A communication module may include any interface necessary for communicating with other devices. Exemplarily, a communication module may be a transceiver, circuit, bus, module, or other type of communication module.

[0123] The processor may include, but is not limited to, one or more of the following: a general-purpose computer, a special-purpose computer, a microcontroller, a digital signal processor (DSP), or a controller-based multi-core controller architecture. The device may have multiple processors, such as application-specific integrated circuit (ASIC) chips, which are time-dependent on a clock synchronized with the main processor.

[0124] The memory may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, at least one of the following: read-only memory (ROM), electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), or other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, at least one of the following: random access memory (RAM), or other volatile memories that do not persist during the duration of a power outage.

[0125] A computer program consists of computer-executable instructions that are executed by an associated processor. Programs can be stored in ROM. A processor can perform any appropriate action and processing by loading the program into RAM.

[0126] Possible implementations of this application can be achieved through a program, enabling the communication device to execute any of the processes discussed in the foregoing embodiments. Possible implementations of this application can also be achieved through hardware or a combination of software and hardware.

[0127] In some implementations, the program may be tangibly contained in a computer-readable storage medium, which may include in a device (such as in memory) or other storage device accessible by the device. The program may be loaded from the computer-readable storage medium into RAM for execution. The computer-readable storage medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0128] This application also provides a computer-readable storage medium storing computer instructions or program code thereon, which, when executed by a processor, causes the processor to perform the methods and functions involved in any of the above embodiments. A computer-readable medium can be any tangible medium that contains or stores a program for or relating to an instruction execution system, apparatus, or device. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. More detailed examples of computer-readable storage media include electrical connections with one or more wires, magnetic media (e.g., disks, floppy disks, hard disks, magnetic tapes, magnetic storage devices), optical media (e.g., optical storage devices, DVDs), semiconductor media (e.g., solid-state drives), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), or any suitable combination thereof.

[0129] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. Embodiments of this application also provide at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. This computer program product includes one or more computer-executable instructions, such as instructions included in a program module, which execute in a device on a target real or virtual processor to perform the processes, methods, and functions involved in any of the above embodiments. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0130] This application also proposes a computer program product, including a computer program or instructions that, when run on a computer, cause the computer to perform the processes, methods, and functions described in the above embodiments. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided as needed. The machine-executable instructions for the program modules can be executed locally or in a distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0131] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software, which can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or represented using some other illustration, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as, as non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0132] It should be noted that although embodiments of this application have been described above with reference to the accompanying drawings, these embodiments are not independent of each other, and they can be combined to obtain other embodiments. The methods, situations, categories, and classifications of embodiments in this application are only for the convenience of description and should not constitute a special limitation. Various methods, categories, situations, and features in embodiments can be combined with each other if logically consistent. The various embodiments of this application can be arbitrarily combined to achieve different technical effects. The embodiments of this application will not list various combinations.

[0133] Furthermore, although the operation of the methods of this disclosure is described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Rather, the steps depicted in the flowcharts may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps. It should also be noted that the features and functions of two or more devices according to this disclosure may be embodied in one device. Conversely, the features and functions of one device described above may be further divided and embodied by multiple devices.

[0134] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0135] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A video call processing method, characterized in that, The video call processing method includes: Receive a first video call update message sent by the network side, the first video call update message indicating that the network side has successfully updated the session parameters and the current session only supports audio transmission; In response to the first video call update message, a second video call update message is sent to the network side, the second video call update message indicating that it is ready to downgrade the transmission mode of the current session to audio transmission; The system receives the response from the network side to the second video call update message, and processes the current session according to the response, using a corresponding call processing strategy, including a downgraded call strategy.

2. The video call processing method according to claim 1, characterized in that, Sending a second video call update message to the network side in response to the first video call update message includes: In response to the first video call update message, the video transmission process is suspended and the second video call update message is sent to the network side.

3. The video call processing method according to claim 1, characterized in that, The step of processing the current session according to the response result and adopting the corresponding call processing strategy includes: Based on the response result, determine whether a transmission mode downgrade confirmation message sent by the network side has been received; Upon receiving a transmission mode downgrade confirmation message from the network side, the current session is downgraded using a corresponding downgrade call strategy.

4. The video call processing method according to claim 3, characterized in that, Upon receiving a transmission mode downgrade confirmation message from the network side, the step of implementing a corresponding downgrade call strategy to downgrade the current session includes: Upon receiving a transmission mode downgrade confirmation message from the network side, determine whether a ringing message from the network side has been received. The ringing message indicates that the peer device has received the call request and started ringing. Upon receiving a ringing message from the network side, a corresponding downgrade call strategy is adopted to downgrade the current session.

5. The video call processing method according to claim 4, characterized in that, The step of downgrading the current session by adopting a corresponding downgrade call strategy upon receiving a ringing message from the network side includes: Based on the response result, determine whether a message from the network side regarding the reconfiguration of radio resources and the release of specific resources has been received; Upon receiving a message from the network side requesting the reconfiguration and release of specific resources for wireless resources, and upon receiving a ringing message from the network side, a corresponding downgrade call strategy is adopted to downgrade the transmission mode of the current session to audio transmission. If no message for wireless resource reconfiguration and release of specific resources is received from the network side, but a ringing message is received from the network side, a corresponding downgrade call strategy is adopted to downgrade the transmission mode of the current session to audio transmission, and it is determined whether the network side releases specific resources after the call ends.

6. The video call processing method according to claim 3, characterized in that, The video call processing method further includes: If no transmission mode downgrade confirmation message is received from the network side or no other indication message is received from the network side, the current session shall be processed in accordance with the call processing policy of the protocol, which includes a call termination policy.

7. The video call processing method according to any one of claims 1 to 6, characterized in that, The video call processing method further includes: After the call ends, determine whether the network side releases specific resources; If the specific resource is not released on the network side, the RRC link is actively released through the Local Release procedure.

8. A video call processing device, characterized in that, The video call processing device includes: The receiving unit is used to receive a first video call update message sent by the network side, wherein the first video call update message indicates that the network side has successfully updated the session parameters and the current session only supports audio transmission. The sending unit is configured to send a second video call update message to the network side in response to the first video call update message, wherein the second video call update message indicates that it is ready to downgrade the transmission mode of the current session to audio transmission; The call processing unit is configured to receive the response result from the network side to the second video call update message, and to process the current session by adopting a corresponding call processing strategy based on the response result, wherein the call processing strategy includes a downgraded call strategy.

9. An apparatus comprising: processor; And a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the video call processing method of any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the video call processing method according to any one of claims 1 to 7.

Images