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

I see three cases:
- STUN and TURN failed, perhaps due to an invalid hostname. You get a
single onicecandidateerror with your URI, and no onicecandidate callbacks
with your URI.
- STUN succeeded, but TURN failed. You can a single onicecandidateerror
with your URI (since for turn:, a relay candidate is expected), and an
onicecandidate callback with the STUN candidate.
- STUN and TURN succeeded. You get two onicecandidate callbacks, with the
STUN and TURN addresses.


On Sun, May 18, 2014 at 1:29 PM, Thomas Bruun <thomas@appear.in> wrote:

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