W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

[webrtc-pc] When is ICE gathering triggered?

From: Soares Chen via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Jun 2017 05:48:16 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-238047002-1498196895-sysbot+gh@w3.org>
soareschen has just created a new issue for https://github.com/w3c/webrtc-pc:

== When is ICE gathering triggered? ==
Filing this issue to get clarification for PR #1399.

In the current browser implementations, ICE gathering is triggered when `setLocalDescription` is called. This can be tested with the following snippet: (Tested on Chrome and Firefox)

const pc = new RTCPeerConnection();

  ev => console.log('icecandidate event:', ev.candidate));
  ev => console.log('icegatheringstatechange event:', pc.iceGatheringState));

console.log('creating data channel');

console.log('creating offer');
pc.createOffer().then(offer => {
  console.log('setting local description');

However there is no normative definition in both webrtc-pc and JSEP that ICE gathering is triggered when `setLocalDescription` is called. The only time this is hinted is in section 3.5.4 of JSEP:

> When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual. This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used.

It can be problematic if there is no normative requirement of when ICE gathering must be fired. This would mean application developers are hopeless of what operations they need to do first to gather ICE candidates.

I think a reasonable expectation is to go with the current browsers behavior and add steps to `setLocalDescription` to describe that if `iceGatheringState` is `new`, trigger ICE gathering on the new ICE transports and update `gatheringState` to `gathering`.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1422 using your GitHub account
Received on Friday, 23 June 2017 05:48:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC