Re: Delivering ICE candidates as packages of "available now" candidates in signaling

[RR]
The more I think about it, the more I agree with Martin's comment here:
https://github.com/openpeer/ortc/issues/52#issuecomment-40289336

As such I think it's best we have an event "onLocalCandidatesChanged" 
event and "getLocalCandidates" method. This would allow us to get the 
definitive current list of current candidates and it addresses the 
flushing of candidate issue as well as the packaging issue. With a 
"setRemoteCandidates" on the remote side in parallel we'd have what we 
need to accurately perform ICE connectivity checks.

The "final" candidate state could be determined from the "gathering 
state" as follows if a web developer wants to determine when there's not 
likely to be any more candidates coming (because there's no active 
gathering):

enum GatherStates {
   "idle",
   "gathering"
};

with:
onGatheringStateChanged(...) event.

The 'onGatherNeeded' event can be turfed.

Thus the packaging, flushing, and "final" candidate gathered concerns 
are effectively addressed in a relatively clean manner.
[/RR]

> Bernard Aboba <mailto:Bernard.Aboba@microsoft.com>
> April 12, 2014 at 3:28 PM
>
>
> [BA] If candidates can be invalidated without a corresponding event, 
> getLocalCandidates is the only way to obtain a list of non-stale 
> candidates. So given the current API, I would agree with you, 
> particularly if there is a desire to support both IPv6 and IPv4 in a 
> multiple-interface setting.