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

I would also suggest to add |reason| to onicecandidateerror.
On May 18, 2014 2:43 PM, "Justin Uberti" <juberti@google.com> wrote:

> Currently, there is no way to know if you failed to get STUN/TURN
> candidates from the servers specified in RTCConfiguration, except by
> working backwards from the generated candidates to see if they match what
> you expect, which is inexact at best.
>
> This includes cases where the server is unreachable (due to server
> problems or a bad URI), as well as authentication failures.
>
> To improve this situation, I suggest the following changes:
> - in RTCPeerConnectionIceEvent, add the URI for the RTCIceServer used to
> generate the candidate as a new |uri| parameter. For host candidates, this
> parameter will be null. This will allow apps to know if they were able to
> successfully obtain candidates from a specific STUN/TURN server.
> - 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.
>
> In some cases, it could be possible to get both a success and error event
> from the same server, e.g. if a STUN address was allocated but a TURN
> request failed.
>