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

This would be very helpful for us. We have been in situations in which the
clients were unable to retrieve relay candidates, where the proposed event
could have helped us discover the error sooner than we did, and also
to instantly let the users know that we were having issues.

Our service would be one of the cases you mentioned, where the same URI
could produce both an error and a success event, as we only supply servers
with the 'turn' scheme (one UDP, and one TCP). In this case, is it the
responsibility of the server to indicate that it occured while trying a
TURN binding request, or should the agent provide this information in
addition to the server/connection error code?


-- 
Thomas Bruun
https://appear.in

On Sun, May 18, 2014 at 8:41 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.
>