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

Received on Monday, 19 May 2014 03:59:37 UTC