When, if ever, are candidates in localDescription and/or CreateOffer

[ekr]

Section 3.4 reads:

When a new ICE candidate is available, the ICE Agent will notify the
application via a callback; these candidates will automatically be
added to the local session description. When all candidates have
been gathered, the callback will also be invoked to signal that the
gathering process is complete.

However, we agreed in London that we would do "always trickle", and
that even if there were candidates available at the time when CreateOffer
(because of candidate pooling) was called, they would not be included
in the initial offer. Consider the following sequence of events.

1. pc = new RTCPeerConnection();
2. pc.AddStream(stream);
3. pc.CreateOffer();
4. CreateOffer callback fires with offer A, and you call SetLocalDescription();
5. onicecandidate fires with candidate X.
6. pc.CreateOffer()
7. CreateOffer callback fires with offer B.
8. onicecandidate fires with null.

So, in London, I think we agreed that offer A would have no candidates.
The above text implies that if you were to examine localdescription prior
to step #5 or at step #7 it would contain candidate X, and probably that offer B would
also contain candidate X.

Note that it's quite inconvenient for non-trickle applications to never
have any candidates in the SDP, especially after gathering is completed
at step #7. However it also seems kind of inconsistent to only update the
candidates after SetLocal() has been called.

[juberti]

I think createOffer includes any candidates that have been given to the client via onicecandidate (since the last ICE restart).

[fluffy]

So sugestion is some mecahnism to tell when all the pool gatehring is done and when all the gathering is done

[martinthomson]

Discussed in DC: decided to have a new event that is raised when gathering state changes, and to add a state to indicate when the gathered pool drains so that an application can use that event to decide to start sending to a peer.

The SDP produced by createOffer() will not contain any candidates.

[ekr]

Also, that initial CreateOffer will have no candidates.

[fluffy]

no candiates means no host candiates

[juberti]

We will add a new onicegatheringstatechange callback to make the gathering state more clear. If needed, we can add a new state to IceGatheringState called "pool", and the sequence would go "new" -> "pool" -> "gathering" -> "complete"

[ekr]

I agree with this resolution. However, unless I am missing something, we don't even talk about oniceconnectingstatechange in this document, Is there anything to do in JSEP or is it just a W3C issue?

[martinthomson]

I think that the w3c can manage this if this document defines the states.

I assume that by "pool" you mean that the PC is drawing on the pool of candidates that have been pre-gathered. And the transition to "gathering" will happen after the pool is drained.

[juberti]

Yes, exactly. If the pool is empty, the "pool" state is skipped.