Re: Issue 165: Ice re-gathering

If that's something we want to do, I think that's a good way to solve it.
But is this a real use case that we want to support?  Is there really a
need to gather new candidates without changing the ufrag/pwd?

Also, it makes me wonder: what happens to the IceTransports that are tied
to the IceGatherer?  What are they supposed to do?   Do they all go back to
the "connecting" state and out of the "completed" state?  Would one expect
to change one object and then the state of a bunch of other objects change
like that?

On Tue, Dec 2, 2014 at 4:30 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  Currently the text on RTCIceTransport.start states:
>
>
>
> "The first time start is called candidate connectivity checks are started
> and the ICE transport attempts to connect to the remote RTCIceTransport. If
> start is called with invalid parameters, throw an InvalidParameters
> exception. If start is called again, an ICE restart occurs, all remote
> candidates are flushed, and addRemoteCandidates or setRemoteCandidates must
> be called to add the remote candidates back or replace them."
>
>
>
> In an ICE restart as defined in RFC 5245, the ICE ufrag/password is
> changed and candidates are re-gathered.  This would imply constructing a
> new RTCIceGatherer object to use when calling RTCIceTransport.start again.
> But what if it is desired to restart ICE connectivity checks with a new set
> of gathered candidates (possibly with a different gather policy) without
> having to change the ufrag/password?
>
>
>
> In this situation it would be useful to add a gather method to the
> RTCIceGatherer, as follows:
>
>
>
> partial interface RTCIceGatherer {
>
>     void gather (optional RTCIceGatherOptions options);
>
> };
>