Re: [webrtc-pc] Impossible to know if ICE agent is "finished checking", for "failed" and "completed" states.

On Thu, Dec 17, 2015 at 5:15 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 18 December 2015 at 07:57, Bernard Aboba <Bernard.Aboba@microsoft.com>
> wrote:
> > However, because "a=end-of-candidates" is not per m-line, it operates
> only at the level of the "ICE Agent" rather than individually on each of
> the RTCIceTransport objects and their "state" attributes.
>
> We've certainly implemented it as a per-media-section attribute.
> There's no reason that the signal can't be more granular, just that
> the signal we have in SDP loses a bit of information.  Firefox does
> have a single agent that signals a single end to the gathering phase,
> but the attribute is added to every affected media section.
>
> > This means that it is not applicable to ORTC/WebRTC NV.
>
> ???  You don't have a notion of an ICE agent?  I thought that we'd
> agreed that an ICE agent was a good idea.


​There is an IceController.  But it doesn't have an aggregate connection
state, since ORTC/WebRTC NV is a low-level API and the application can
aggregate states how it wants.​



> In either case, I think that the right answer is to use the underlying
> state: have you finished gathering, rather than use
> a=end-of-candidates for that state.  If you want to report a failed
> state, then you only do so if gathering is done (or stopped for now if
> you prefer) and all the checks have failed for those pairs that you do
> have
> ​.​
>


I don't think there's any reason to have a "failed" state at all in
ORTC/WebRTC NV​
​
​.  It's really just a combination of two dimensions: [still gathering,
done gathering]​ x [init, checking, connected, disconnected], and if the
application cares to combine those two states, it can, but there's no
reason to do it with a low-level API.  Similarly, the "completed" is a
compound that  that doesn't need to be created in a low-level API since the
JS can do so.


> I'm an anti-fan of the idea of a special candidate, favouring instead
> a separate method, but I get the appeal.
>


I'm not a fan of a special end-of-candidates value either.  However, if
it's a separate method, what percentage of applications do you think will
remember to listen to the event, signal the event, and call the method on
the remote end, and notice if they didn't do it correctly?  And if no one
uses it, why put it in there?

Another option is to say something like "if you haven't gotten a candidate
in 15 seconds since the last candidate, assume that's the end".  While a
little hacky, it will work even if an application doesn't remember to set
up the extra end-of-candidates signalling.