W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sun, 18 May 2014 19:28:23 -0700
Message-ID: <CABkgnnX+B=hg+PnPWAGpkSSUzP3xoxO3pViQjKfvh0oWaOSiig@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Thomas Bruun <thomas@appear.in>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.
Received on Monday, 19 May 2014 02:28:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC