Re: A proposal for returning STUN/TURN server errors to applications

On Mon, May 19, 2014 at 3:01 AM, Philipp Hancke
<fippo@goodadvice.pages.de>wrote:

> This will allow apps to know if they were able to
>> successfully obtain candidates from a specific STUN/TURN server.
>>
>
> Does this matter to the app? This information is not very interesting if
> the connection succeeds.
>
> I'm expecting apps to use getStats to find out the candidate pair / type
> of connection actually used.
> So requiring them to use getStats in the case of failure does not seem to
> increase complexity that much.


Would you expect to find failed candidates in stats? I guess we could do
that, but we'd have to add a new stats object for failed candidates.

>
>
>  - add a new onicecandidateerror event, which emits an event for every URI
>> that did not generate the expected candidates (e.g. srflx for a STUN
>> server, relay for a TURN server). The onicecandidateerror event has two
>> fields, |uri|, and |code|, where code is either the error from the server,
>> or some 6xx error code if the connection failed.
>>
>
> Assuming the app only wants to show an error if ice fails, this means that
> the information has to be stored in the callback and retrieved later in the
> ice connection state change event (or the onicecandidate event with a null
> candidate for the use-case of checking a servers availability without
> actually establishing a connection).
> Which seems to reinvent getStats.
>

I doubt that this information would be exposed to the user. Most likely,
this would be emitted to some sort of debug or monitoring facility,
regardless of whether ICE failed.

>
> Either way, solving this is important for failure diagnosis.
>
>