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

This sounds reasonable.  Note that Firefox is adding telemetry to
track (i.e., count) the different types of candidates that were
present when we succeeded or failed in connecting a component.

On 18 May 2014 15:18, Justin Uberti <juberti@google.com> wrote:
> 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.
>>
>>
>
>