Gateway Mediator for WebRTC and Legacy SIP Connectivity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The use of Trickle Ice in communication networks can cause connectivity issues and delays when legacy devices, which follow the Session Initiation Protocol (SIP), are used alongside modern devices that support the Trickle Ice extension, posing cost and reliability constraints and making it economically infeasible for some systems to utilize this extension.
Innovation Solution
A method and system where a gateway facilitates communication terminal connections by modifying messages to establish connections between devices with and without WebRTC clients, allowing for direct or TURN server-anchored media connections, and managing ICE candidates to ensure compatibility and quick session establishment.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If Trickle Ice extension is used to permit incremental candidate exchange and improved connectivity, then connectivity speed and session establishment are improved, but compatibility with legacy SIP devices is lost causing unforeseen delays and connectivity problems
Solution Approach 1:
The gateway acts as an intermediary between WebRTC devices and legacy SIP devices. It receives ICE candidates from WebRTC devices, translates them into SIP-compatible formats, and forwards them to legacy devices. This mediation allows the benefits of Trickle Ice to be realized while maintaining compatibility with legacy equipment that cannot natively process ICE candidates.
Solution Approach 2:
The gateway transforms the parameter format of ICE candidates from WebRTC protocol format to SIP protocol format. By changing the representation and structure of candidate data, the system enables legacy SIP devices to process and respond to ICE candidates that originate from modern WebRTC devices, thus resolving the compatibility issue.
2Reliability
If complete ICE candidate lists are exchanged before connectivity checks, then all connectivity options are available, but session establishment time increases
Solution Approach 1:
The system performs preliminary gathering of ICE candidates and prepares them for incremental exchange before the actual connectivity check is needed. By having candidates ready in advance and using Trickle Ice to transmit them progressively, the system ensures that when connectivity checks are initiated, the necessary candidate information is already available, reducing delays while maintaining reliable connectivity options.
Solution Approach 2:
The complete ICE candidate list is segmented and transmitted incrementally through the Trickle Ice mechanism rather than as a single complete exchange. This segmentation allows connectivity checks to begin with the candidates available at each stage, rather than waiting for the entire list to be exchanged, thus reducing session establishment time while maintaining access to all connectivity options as they become available.
3Adaptability or versatility
If legacy SIP devices are used in the network, then broader device compatibility is maintained, but Trickle Ice extension cannot be utilized effectively
Solution Approach 1:
The gateway serves as a protocol translation intermediary that enables legacy SIP devices to participate in WebRTC-based Trickle Ice sessions. It receives SIP messages from legacy devices, extracts necessary information, translates it into WebRTC/ICE formats, and manages the candidate exchange process, thereby allowing legacy devices to be included in modern WebRTC sessions without sacrificing productivity.
Solution Approach 2:
The gateway is designed with multi-functionality to handle both legacy SIP protocols and modern WebRTC/ICE protocols simultaneously. It can process SIP messages, generate and manage ICE candidates, translate between protocols, and coordinate connectivity checks, making it a universal interface that bridges old and new device types while maintaining high session establishment efficiency.
Data Source
AI summary
A gateway receives a message from a first terminal to establish a connection between the first terminal and a second terminal. The gateway sends a second message to the second terminal to offer a connection. After receiving the first message from the first terminal, the gateway receives subsequent third messages from the first terminal that identify candidates for assisting in the formation of the connection. The gateway saves information about these candidates. The gateway either uses such information for facilitating the formation of the connection or forwards that information to the second communication terminal after receiving an answer accepting the establishment of a connection from the second terminal and determining whether the second terminal has a WebRTC client.