Method and system for optimizing real-time voice call between web browsers

Abstract

The invention discloses a method and a system for optimizing a real-time voice call between web browsers. The method comprises the following steps: completing local voice resource preparation through user media permission acquisition and audio stream configuration; a signaling channel with WebSocket as a main part and Socket.IO as a standby part is established, and reliable transmission of instructions is ensured by a standardized data format and a heartbeat mechanism; the method comprises the following steps: initializing an RTCPeerContion and binding a key event, completing session negotiation through Offer and Answer exchange, synchronously starting ICE candidate screening, and determining an optimal communication path according to a preset priority; quality is monitored in real time after connection is established, interruption is dealt with through an automatic reconnection mechanism, and resources are released normatively when a call is ended.

Description

Technical Field

[0001] This invention relates to the field of real-time communication technology, and specifically to a method and system for optimizing real-time voice calls between web browsers. Background Technology

[0002] With the development of internet technology, the demand for real-time communication is increasing. Traditional voice calls typically rely on dedicated software or plugins, and existing technologies suffer from the following core pain points: 1. Limitations of traditional voice call solutions: Traditional browser-based voice communication relies on dedicated plugins (such as Flash, Java Applet) or client software (such as QQ), which require users to manually download and install, and there are also version compatibility issues.

[0003] 2. Shortcomings of existing WebRTC applications (such as ambiguous signaling protocol selection, low NAT traversal efficiency, and insufficient voice quality adaptation).

[0004] 3. Real-time voice calls on the browser side rely on plugins, which have high barriers to entry for users and poor compatibility; 4. The signaling channel lacks standardized design, resulting in low connection establishment stability and weak anomaly recovery capability; 5. NAT traversal has a low success rate and poor network adaptability; 6. The voice processing is not optimized for complex scenarios, the sound quality is greatly affected by bandwidth and noise, and cross-browser compatibility is insufficient. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for optimizing real-time voice calls between web browsers, overcoming the shortcomings of existing technologies. This invention utilizes the peer-to-peer communication characteristics of WebRTC, coordinating connections through a signaling server to achieve direct voice communication between browsers without requiring additional plugins or software. This invention offers advantages such as low latency, high quality, and easy deployment, making it suitable for various scenarios including online customer service, remote collaboration, and social applications.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A method for optimizing real-time voice calls between web browsers includes the following steps: Step 1: Complete the preparation of local voice resources by obtaining user media permissions and configuring audio streams; Step 2: Establish a signaling channel with WebSocket as the primary and Socket.IO as the backup, and standardize the data format and heartbeat mechanism to ensure reliable transmission of instructions; Step 3: Initialize RTCPeerConnection and bind key events, complete session negotiation through Offer and Answer exchange, synchronously start ICE candidate filtering, and determine the optimal communication path according to preset priority; Step 4: Monitor the quality in real time after the connection is established, handle interruptions through an automatic reconnection mechanism, and release resources in a standardized manner when the call ends.

[0007] Furthermore, the step of preparing local voice resources through user media permission acquisition and audio stream configuration specifically includes: Step 1.1: Call the navigator.mediaDevices.getUserMedia(constraints) API, passing in the audio constraint parameters; Step 1.2: If the user denies microphone permission, a PermissionDeniedError is triggered, a pop-up window appears on the front end, and a link to guide the user through the settings is provided. If no microphone is detected to be available, a NotFoundError will be triggered, and the user will be notified. Step 1.3: Cache the obtained MediaStream object to a global variable on the client side for later binding to RTCPeerConnection.

[0008] Furthermore, in step 1.2, the front-end pop-up window prompts "Please grant microphone permission to continue the call" and provides a guide link to "Go to browser settings"; In step 1.3, the user is prompted with the message: "No microphone device detected. Please check the hardware connection."

[0009] Furthermore, the establishment of a signaling channel with WebSocket as the primary channel and Socket.IO as the backup, and the standardization of data formats and heartbeat mechanisms to ensure reliable instruction transmission, specifically include: Step 2.1: Prioritize the WebSocket protocol. If the browser does not support it, downgrade to the Socket.IO protocol. Step 2.2: The client initiates a WebSocket connection request with the address format wss: / / [signaling server domain name]:[port] / signaling; Step 2.3: To prevent the connection from being disconnected by the network device, the client sends a heartbeat packet to the signaling server every preset time. After receiving the heartbeat packet, the server returns an acknowledgment packet. If no acknowledgment is received for a preset number of consecutive times, the client automatically re-initiates the connection.

[0010] Furthermore, the initialization of RTCPeerConnection and binding of key events specifically includes: Step 3.1.1: When initializing RTCPeerConnection, pass in the list of ICE servers, distinguishing between STUN and TURN. STUN is used to obtain public IP addresses, while TURN is used to relay data, resolving NAT traversal failure scenarios. Step 3.1.2: Bind core events to RTCPeerConnection to enable connection status monitoring and data processing: Core event Icecandidate: This core event is triggered when an ICE candidate is generated, and the candidate information is sent to the peer through the signaling server; The core event `connectionstatechange` monitors the connection status and automatically triggers a reconnection when the connection status is "disconnected".

[0011] Furthermore, the process of completing the session negotiation through the exchange of Offer and Answer specifically includes: Step 3.2.1: Create and send an Offer. The party initiating the call creates a session description Offer and sends it to the recipient through the signaling server. Step 3.2.2: After receiving the Offer signal, the recipient verifies the integrity of the fields; Step 3.2.3: The receiver calls peerConnection.createAnswer() to generate an Answer, sets it to a local description, and sends it to the initiator through the signaling channel, while simultaneously starting the ICE candidate exchange process.

[0012] Furthermore, the step of determining the optimal communication path according to a preset priority specifically includes: Prioritize host candidates. If a host candidate is unavailable, select a server reflection candidate. If both types of candidates fail, select a relay candidate. For candidates that fail to establish a connection, mark them as invalid and remove them from the candidate list to avoid repeated attempts.

[0013] Furthermore, the real-time monitoring of quality after connection establishment, the handling of interruptions through an automatic reconnection mechanism, and the standardized release of resources upon termination of the call specifically include: Step 4.1: After both ends complete the ICE candidate exchange and establish a P2P connection, the connectionstatechange event of RTCPeerConnection triggers the connected state, the front-end updates the UI to show that the call is in progress, and at the same time starts playing the audio stream from the other end; Step 4.2: Monitor voice transmission quality in real time through the RTCP feedback mechanism; Step 4.3: If a connection is detected to be disconnected, i.e., the connectionstatechange is disconnected or failed, the client will automatically re-execute step 3 and provide a prompt during the reconnection process. The call will resume after the reconnection is successful. Step 4.4: Either client initiates a hang-up request, and both ends call peerConnection.close() to close the connection, release microphone resources, and clear the signaling channel.

[0014] A system for optimizing real-time voice calls between web browsers includes: The first module is used to prepare local voice resources by obtaining user media permissions and configuring audio streams. The second module is used to establish a signaling channel with WebSocket as the primary channel and Socket.IO as the backup channel. Standardized data formats and heartbeat mechanisms ensure reliable transmission of commands. The third module is used to initialize RTCPeerConnection and bind key events, complete session negotiation through Offer and Answer exchange, synchronously start ICE candidate filtering, and determine the optimal communication path according to preset priority. The fourth module is used to monitor the quality in real time after the connection is established, handle interruptions through an automatic reconnection mechanism, and release resources in a standardized manner when the call ends.

[0015] A computer storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the method for optimizing real-time voice calls between web browsers.

[0016] Compared with the prior art, the present invention has the following beneficial technical effects: 1. RTCPeerConnection, as a core component of WebRTC, plays a crucial role in media stream transmission and connection management. This invention's method inputs a list of STUN / TURN servers during the initialization phase and binds core events such as connectionstatechange and icecandidate, ensuring connection controllability from the ground up. On one hand, it captures connection state changes in real time through event listening, immediately triggering reconnection logic when a disconnected state is detected, avoiding the "unnoticed connection interruption" problem in traditional solutions. On the other hand, it efficiently binds the audio stream to RTCPeerConnection, eliminating the extra time spent on plugin relays, reducing media stream transmission latency by more than 30%, laying a low-latency foundation for real-time voice calls.

[0017] 2. Addressing the pain points of ambiguous signaling protocol selection and inconsistent data formats in existing technologies, this invention adopts a "WebSocket priority + Socket.IO fallback" protocol strategy. This ensures full-duplex, low-latency communication in modern browsers while maintaining compatibility with older browsers, improving compatibility coverage to over 95%. Simultaneously, through a 10-second heartbeat mechanism and standardized JSON signaling format, it effectively solves problems such as signaling channels being easily disconnected by network devices and data parsing anomalies. Testing shows that the standardized signaling design increases the connection establishment success rate from 75% in traditional solutions to 98%, and reduces anomaly recovery time to within 2 seconds, significantly reducing user experience disruptions caused by connection issues.

[0018] 3. NAT traversal is a core challenge in P2P calls. This invention's method achieves comprehensive network scenario adaptation through a "three-level candidate screening" strategy: it prioritizes candidates with direct intranet connections, keeping latency below 50ms; secondly, it selects candidates with direct public network connections via server reflection to meet cross-network segment communication needs; and finally, it uses relay candidates as a fallback to ensure connection success rates in complex network environments such as symmetric NAT. Compared to traditional solutions relying solely on STUN, this invention's method improves NAT traversal success rates from 60% to 92%, with particularly significant improvements in connection stability in complex scenarios such as enterprise intranets and multi-level routing, effectively addressing the user pain point of significant differences in call quality across different network environments. Attached Figure Description

[0019] The accompanying drawings are provided to further understand the invention and constitute a part of this invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0020] Figure 1 This is a flowchart of a method for optimizing real-time voice calls between web browsers according to the present invention. Figure 2 This is a system architecture diagram for optimizing real-time voice calls between web browsers according to the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] Example 1 like Figure 1 As shown, the present invention provides a method for optimizing real-time voice calls between web browsers, comprising the following steps: Step 1: Complete the preparation of local voice resources by obtaining user media permissions and configuring audio streams; Step 2: Establish a signaling channel with WebSocket as the primary and Socket.IO as the backup, and standardize the data format and heartbeat mechanism to ensure reliable transmission of instructions; Step 3: Initialize RTCPeerConnection and bind key events, complete session negotiation through Offer and Answer exchange, synchronously start ICE candidate filtering, and determine the optimal communication path according to preset priority; Step 4: Monitor the quality in real time after the connection is established, handle interruptions through an automatic reconnection mechanism, and release resources in a standardized manner when the call ends.

[0024] This invention provides a browser-based real-time voice call method based on WebRTC. By utilizing key technologies such as RTCPeerConnection, signaling exchange, and NAT traversal, it fully leverages the capabilities of modern browsers, reduces connection time, improves connection stability, optimizes the real-time voice process, and enhances the user experience.

[0025] Example 2 This invention provides a method for optimizing real-time voice calls between web browsers, comprising the following steps: Step 1: Obtaining user media permissions and configuring audio streams 1.1: Permission Request: Call the navigator.mediaDevices.getUserMedia(constraints) API, passing in the audio constraint parameters (since only voice is needed, the video constraint is set to false). For the audio part, set the sample rate sampleRate to 48kHz (sampleRate: 48000) to balance sound quality and bandwidth requirements, and the number of channels to 1 (channelCount: 1,) to reduce bandwidth usage. At the same time, enable echo cancellation (echoCancellation: true), noise suppression, and automatic gain control (noiseSuppression: true, autoGainControl: true). The video part is set to off (video: false) because this method only requires voice call functionality.

[0026] 1.2: Error Handling: If the user denies microphone permission (triggers PermissionDeniedError), the front end will display a pop-up message "Please grant microphone permission to continue the call" and provide a link to "Go to browser settings"; If no microphone is detected (triggers a NotFoundError), the user will be prompted with "No microphone device detected. Please check your hardware connections." 1.3: Audio Stream Caching: The obtained MediaStream object is cached in a global variable on the client side for subsequent binding to RTCPeerConnection.

[0027] Step 2: Signaling Channel Establishment and Standardization Design 2.1 Protocol Selection: WebSocket protocol (full-duplex, low latency) should be used first. If the browser does not support it (such as older versions of IE), it should be downgraded to Socket.IO protocol (based on HTTP long polling, with wider compatibility). 2.2: Server Connection: The client initiates a WebSocket connection request with the address format wss: / / [signaling server domain name]:[port] / signaling; 2.3: Heartbeat Mechanism: To prevent the connection from being dropped by network devices (such as routers), the client sends a heartbeat packet to the signaling server every 10 seconds. After receiving the packet, the server returns an acknowledgment packet. If no acknowledgment is received for three consecutive times, the client automatically re-initiates the connection. 2.4 Signaling Data Format: Signaling is uniformly encapsulated in JSON format. Core fields include: type (signaling type, such as "order", "answer", "icecandidate", "disconnect", etc., used to identify the purpose of the signaling), from (sender identifier, usually a unique client ID used to distinguish call participants), to (receiver identifier, specifying the target of signaling reception), data (specific signaling content, such as the SDP description of Order / Answer, ICE candidate information, etc.), and timestamp (signaling transmission timestamp, used for sorting and timeout determination).

[0028] Step 3: Initialize the RTCPeerConnection object 3.1: When initializing RTCPeerConnection, pass in the list of ICE servers, distinguishing between STUN (used to obtain public IP) and TURN (used for relaying data, resolving NAT traversal failure scenarios); 3.2 Event Listener Binding: Bind core events to RTCPeerConnection to achieve connection status monitoring and data processing: icecandidate: This event is triggered when an ICE candidate is generated, and the candidate information is sent to the peer through the signaling server; connectionstatechange: Monitors the connection status (such as connecting, connected, disconnected), and automatically triggers reconnection when the status is disconnected; Step 4: Offer Creation and Sending: Create and send an Offer: The party initiating the call creates a session description Offer and sends it to the recipient via the signaling server.

[0029] Step 5: Answer Reception and Processing 5.1: Offer Verification: After receiving the Offer signal, the recipient verifies the integrity of the fields; 5.2: Answer Generation and Sending: The receiver calls peerConnection.createAnswer() to generate an Answer, sets it to a local description, and sends it to the initiator through the signaling channel, while simultaneously initiating the ICE candidate exchange process.

[0030] Step 6: Optimal Path Selection 6.1: Prioritize "host candidates" (direct intranet connection, lowest latency, highest bandwidth); 6.2: If the host candidate is unavailable (across network segments), select "Server Reflection Candidate" (direct public network connection, latency is secondary); 6.3: If the first two candidate types fail (e.g., symmetric NAT), select "Relay Candidate" (relay via TURN server to ensure successful connection); 6.4: Candidate Failure Handling: For candidates that fail to establish a connection, mark them as "failed" and remove them from the candidate list to avoid repeated attempts.

[0031] Step 7: Connection Establishment and Voice Call Maintenance 7.1 Connection Confirmation: After both ends complete the ICE candidate exchange and establish a P2P connection, the connectionstatechange event of RTCPeerConnection triggers the connected state, the front-end updates the UI to "In Call", and starts playing the audio stream from the other end. 7.2: Voice Quality Monitoring: Voice transmission quality is monitored in real time via the RTCP (Real-Time Control Protocol) feedback mechanism; 7.3: Reconnection after disconnection: If a connection is detected to be disconnected (connectionstatechange is disconnected or failed), the client will automatically re-execute steps 2-6 (signaling channel reconstruction → offer / answer re-exchange → ICE candidate re-filtering). During the reconnection process, the message "Reconnecting..." will be displayed. The call will resume after the reconnection is successful. 7.4: Call End Handling: When either client initiates a "hang up" request (sending a type: "disconnect" signaling), both ends call peerConnection.close() to close the connection, release microphone resources, and clear the signaling channel.

[0032] Example 3 like Figure 2 As shown, the present invention provides a system for optimizing real-time voice calls between web browsers, comprising: The first module is used to prepare local voice resources by obtaining user media permissions and configuring audio streams. The second module is used to establish a signaling channel with WebSocket as the primary channel and Socket.IO as the backup channel. Standardized data formats and heartbeat mechanisms ensure reliable transmission of commands. The third module is used to initialize RTCPeerConnection and bind key events, complete session negotiation through Offer and Answer exchange, synchronously start ICE candidate filtering, and determine the optimal communication path according to preset priority. The fourth module is used to monitor the quality in real time after the connection is established, handle interruptions through an automatic reconnection mechanism, and release resources in a standardized manner when the call ends.

[0033] Example 4 A computer storage medium storing a computer program, which, when executed by a processor, implements the steps of the method for optimizing real-time voice calls between web browsers.

[0034] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code.

[0035] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0036] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0037] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0038] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit its protection scope. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that after reading the present invention, they can still make various changes, modifications or equivalent substitutions to the specific implementation of the invention, but these changes, modifications or equivalent substitutions are all within the protection scope of the invention.

Claims

1. A method for optimizing real-time voice calls between web browsers, characterized in that, Includes the following steps: Step 1: Complete the preparation of local voice resources by obtaining user media permissions and configuring audio streams; Step 2: Establish a signaling channel with WebSocket as the primary and Socket.IO as the backup, and standardize the data format and heartbeat mechanism to ensure reliable transmission of instructions; Step 3: Initialize RTCPeerConnection and bind key events, complete session negotiation through Offer and Answer exchange, synchronously start ICE candidate filtering, and determine the optimal communication path according to preset priority; Step 4: Monitor the quality in real time after the connection is established, handle interruptions through an automatic reconnection mechanism, and release resources in a standardized manner when the call ends.

2. The method for optimizing real-time voice calls between web browsers according to claim 1, characterized in that, The process of preparing local voice resources by obtaining user media permissions and configuring audio streams specifically includes: Step 1.1: Call the navigator.mediaDevices.getUserMedia(constraints) API, passing in the audio constraint parameters; Step 1.2: If the user denies microphone permission, a PermissionDeniedError is triggered, a pop-up window appears on the front end, and a link to guide the user through the settings is provided. If no microphone is detected to be available, a NotFoundError will be triggered, and the user will be notified. Step 1.3: Cache the obtained MediaStream object to a global variable on the client side for later binding to RTCPeerConnection.

3. The method for optimizing real-time voice calls between web browsers according to claim 2, characterized in that, In step 1.2, a pop-up window appears on the front end prompting "Please grant microphone permission to continue the call" and provides a link to "Go to browser settings"; In step 1.3, the user is prompted with the message: "No microphone device detected. Please check the hardware connection." 4. A method for optimizing real-time voice calls between web browsers according to claim 1, characterized in that, The establishment of a signaling channel with WebSocket as the primary channel and Socket.IO as the backup channel, and the standardization of data formats and heartbeat mechanisms to ensure reliable instruction transmission, specifically includes: Step 2.1: Prioritize the WebSocket protocol. If the browser does not support it, downgrade to the Socket.IO protocol. Step 2.2: The client initiates a WebSocket connection request with the address format wss: / / [signaling server domain name]:[port] / signaling; Step 2.3: To prevent the connection from being disconnected by the network device, the client sends a heartbeat packet to the signaling server every preset time. After receiving the heartbeat packet, the server returns an acknowledgment packet. If no acknowledgment is received for a preset number of consecutive times, the client automatically re-initiates the connection.

5. A method for optimizing real-time voice calls between web browsers according to claim 1, characterized in that, The initialization of RTCPeerConnection and binding of key events specifically includes: Step 3.1.1: When initializing RTCPeerConnection, pass in the list of ICE servers, distinguishing between STUN and TURN. STUN is used to obtain public IP addresses, while TURN is used to relay data, resolving NAT traversal failure scenarios. Step 3.1.2: Bind core events to RTCPeerConnection to enable connection status monitoring and data processing: Core event Icecandidate: This core event is triggered when an ICE candidate is generated, and the candidate information is sent to the peer through the signaling server; The core event `connectionstatechange` monitors the connection status and automatically triggers a reconnection when the connection status is "disconnected".

6. A method for optimizing real-time voice calls between web browsers according to claim 5, characterized in that, The process of completing the session negotiation through the exchange of Offer and Answer specifically includes: Step 3.2.1: Create and send an Offer. The party initiating the call creates a session description Offer and sends it to the recipient through the signaling server. Step 3.2.2: After receiving the Offer signal, the recipient verifies the integrity of the fields; Step 3.2.3: The receiver calls peerConnection.createAnswer() to generate an Answer, sets it to a local description, and sends it to the initiator through the signaling channel, while simultaneously starting the ICE candidate exchange process.

7. The method for optimizing real-time voice calls between web browsers according to claim 6, characterized in that, The step of determining the optimal communication path according to a preset priority specifically includes: Prioritize host candidates. If a host candidate is unavailable, select a server reflection candidate. If both types of candidates fail, select a relay candidate. For candidates that fail to establish a connection, mark them as invalid and remove them from the candidate list to avoid repeated attempts.

8. A method for optimizing real-time voice calls between web browsers according to claim 5, characterized in that, The process of real-time quality monitoring after connection establishment, handling interruptions through an automatic reconnection mechanism, and properly releasing resources upon call termination specifically includes: Step 4.1: After both ends complete the ICE candidate exchange and establish a P2P connection, the connectionstatechange event of RTCPeerConnection triggers the connected state, the front-end updates the UI to show that the call is in progress, and at the same time starts playing the audio stream from the other end; Step 4.2: Monitor voice transmission quality in real time through the RTCP feedback mechanism; Step 4.3: If a connection is detected to be disconnected, i.e., the connectionstatechange is disconnected or failed, the client will automatically re-execute step 3 and provide a prompt during the reconnection process. The call will resume after the reconnection is successful. Step 4.4: Either client initiates a hang-up request, and both ends call peerConnection.close() to close the connection, release microphone resources, and clear the signaling channel.

9. A system for optimizing real-time voice calls between web browsers, characterized in that, include: The first module is used to prepare local voice resources by obtaining user media permissions and configuring audio streams. The second module is used to establish a signaling channel with WebSocket as the primary channel and Socket.IO as the backup channel. Standardized data formats and heartbeat mechanisms ensure reliable transmission of commands. The third module is used to initialize RTCPeerConnection and bind key events, complete session negotiation through Offer and Answer exchange, synchronously start ICE candidate filtering, and determine the optimal communication path according to preset priority. The fourth module is used to monitor the quality in real time after the connection is established, handle interruptions through an automatic reconnection mechanism, and release resources in a standardized manner when the call ends.

10. A computer storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for optimizing real-time voice calls between web browsers as described in any one of claims 1 to 8.

Images