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

> 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.

> - 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.

Either way, solving this is important for failure diagnosis.

Received on Monday, 19 May 2014 10:01:55 UTC