ICE is the process used to find a way to connect between 2 parties over the Internet. It is an independent protocol/procedure and therefore can be adopted and used by any standard.
Hence, it is used by both SIP and WebRTC.
If a long connection time (time to open a call) bugs you, ICE is likely the one to blame for that.
There have been different attempts to shorten the connection creation time. This post is just about that.
The ICE procedure includes 3 steps:
Gathering of candidates: Local Host (your local private IP address), STUN address(es) and TURN address(es).
Connectivity check: Sending STUN messages to each of the candidates to see if the other side has received it, meaning that that candidate can reach the remote party.
Nomination: Choosing which candidate to use for the session.
WebRTC uses Trickle ICE in an attempt to shorten the time this procedure takes. With Trickle ICE there is no need to wait for the gathering of all candidates to be complete before starting connectivity checks. Once connectivity with one pair of candidates succeeds, WebRTC may start using it. A WebRTC device might instead decide to wait for additional connectivity checks to be completed in hope for a better one; for example, WebRTC would prefer not to use a relay (TURN server).
Aggressive nomination, an older approach to speeding up ICE, has nothing to do with the gathering of candidates; it deals with the connectivity check and nomination.
When using aggressive nomination, within the connectivity check itself every candidate is treated as if it is nominated. In this way, once there is a successful connectivity check the remote party will start using it.
WebRTC prefers to have some liberty in the selection of the candidate pair that will be used (e.g. for media routing efficiency) and therefore, aggressive nomination is specifically deprecated now in what is being called “passive aggressive nomination”.
More information can be found in the details below.
In WebRTC applications that integrate with traditional VoIP systems and expect the browser to use aggressive nomination, this may fail at some point.
In the specifications now.
Traditionally ICE worked by gathering all possible IP addresses and ports at which the local endpoint could possibly be reached, pairing them with the corresponding addresses and ports for the remote endpoint to create “candidate pairs”, and then sending STUN connectivity checks to each of the candidate pairs in a priority order, waiting a certain amount of time to be sure that you have received all the responses you are likely to, and then “nominating” one pair as the one to use for media. Then media would begin flowing.
To speed this up by eliminating the wait for all the checks to complete, “aggressive nomination” was introduced, where all pairs are nominated in the original connectivity check and the first one to succeed became the one that was used.
Unfortunately, this presented a problem once WebRTC was introduced, because there is a set of requirements that specifies the order in which candidates must be checked, but WebRTC browsers may prefer to use a different pair than the first one that succeeds.
One example is if an IPv6 candidate check using a relay succeeds before an IPv4 candidate check using the local (host) address. Although ICE prefers IPv6, WebRTC prefers local addresses.
Additionally, any endpoint receiving a nominated address will believe they are truly a chosen address and potentially begin sending media to that address, only to have a different address chosen in the end.
Because of WebRTC, the decision was made that WebRTC endpoints are not to initiate aggressive nomination but must accept it if initiated by a non-WebRTC endpoint. This does not really delay ICE processing in WebRTC because WebRTC also supports Trickle ICE, where candidate pairs are checked as they come in.