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

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

From: Justin Uberti <juberti@google.com>
Date: Sun, 18 May 2014 15:18:40 -0700
Message-ID: <CAOJ7v-3o3YRaOD4E6HfQyGN_F0h8a1VZKCmOk5m_T_OGVpJeig@mail.gmail.com>
To: Thomas Bruun <thomas@appear.in>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 Sunday, 18 May 2014 22:19:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC