WebRTC Trickle ICE
ICE is used in WebRTC and in SIP for finding the possible media routes for a session. In essence, the process involves gathering candidates and checking connectivity to see if a connection between the parties is possible using each of the candidates.
This process takes time to complete and is one of the reasons for delay in establishing media connections in SIP and in WebRTC.
One of the methods for speeding up the ICE process is Trickle ICE. The idea behind Trickle ICE is that an agent may send and receive ICE candidates incrementally. By doing so, the agent may start connectivity checks before all candidates have been gathered, thus shortening ICE process time.
WebRTC Trickle ICE – The details below review the changes in WebRTC that allow for the browsers to make best use of the Trickle ICE procedure.
WebRTC Live Q&A
Checkout our live WebRTC Q&A webinars.
This will allow for faster media connection between WebRTC clients and better detection of some failures. As long as a null candidate received in the onicecandidate handler is passed to addIceCandidate() on the remote browser (as with any candidate), this should work.
The changes are in the specification today.
Trickle ICE is a great addition to ICE that has been crucial for rapid Peer Connection setup in WebRTC.
Although candidates are included in the SDP, WebRTC supports JavaScript APIs for getting local ICE candidate addresses (onicecandidate event handler) and for informing the local browser of remote ICE candidates (addIceCandidate()). However, until now there has not been a way to indicate when no more candidates were forthcoming.
The Trickle ICE spec says:
“Receiving an end-of-candidates notification allows an agent to update check list states and, in case valid pairs do not exist for every component in every media stream, determine that ICE processing has failed. It also allows agents to speed ICE conclusion in cases where a candidate pair has been validated but it involves the use of lower-preference transports such as TURN.”
The key here is that the browser can determine ICE failure in some cases and speed up ICE conclusion in others, but it needs to know when no more candidates are forthcoming in order to do so. It will now be possible to pass a JavaScript null value into addIceCandidate() to indicate that there will be no more remote candidates. This capability is in the Editor’s Draft of the WebRTC spec now.
As a consequence of this change, there is now another important set of changes concerning the values of the iceConnectionState property. First, the briefest of high-level refreshers on ICE: In the ICE process, each endpoint gathers all the possible addresses it can for itself and exchanges them with the other side (called the “gathering” step). Each side then tries to reach each of the remote candidates (called the “checking” step). Although originally designed as sequential steps, in modern usage of ICE, with trickling, each candidate can be checked as soon as it arrives. Until now in WebRTC, though, the lack of a means to indicate end-of-candidates meant that the browser could never know whether gathering was complete and could thus not ever guarantee that checking was complete as well. Along with the change to addIceCandidate(), several of the state values in iceConnectionState will have their definitions updated to clarify that not just checking, but gathering as well, could be the reason for the state.
See the merged pull request for details.