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

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

From: Roman Shpount <roman@telurix.com>
Date: Sun, 18 May 2014 23:59:08 -0400
Message-ID: <CAD5OKxsz+Cp=G2emhxZ1mGoz=vMcnToi7rqU3X_8pzO-1kjmyw@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: public-webrtc@w3.org
I would also suggest to add |reason| to onicecandidateerror.
On May 18, 2014 2:43 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 03:59:37 UTC

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