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: Mon, 19 May 2014 06:31:59 -0700
Message-ID: <CAOJ7v-3zh05K-joEnhmnDKFZ9RSjqVDiO+qX4hv=7ZrhUYDYqg@mail.gmail.com>
To: Philipp Hancke <fippo@goodadvice.pages.de>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Mon, May 19, 2014 at 3:01 AM, Philipp Hancke

> This will allow apps to know if they were able to
>> successfully obtain candidates from a specific STUN/TURN server.
> Does this matter to the app? This information is not very interesting if
> the connection succeeds.
> I'm expecting apps to use getStats to find out the candidate pair / type
> of connection actually used.
> So requiring them to use getStats in the case of failure does not seem to
> increase complexity that much.

Would you expect to find failed candidates in stats? I guess we could do
that, but we'd have to add a new stats object for failed candidates.

>  - 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.
> Assuming the app only wants to show an error if ice fails, this means that
> the information has to be stored in the callback and retrieved later in the
> ice connection state change event (or the onicecandidate event with a null
> candidate for the use-case of checking a servers availability without
> actually establishing a connection).
> Which seems to reinvent getStats.

I doubt that this information would be exposed to the user. Most likely,
this would be emitted to some sort of debug or monitoring facility,
regardless of whether ICE failed.

> Either way, solving this is important for failure diagnosis.
Received on Monday, 19 May 2014 13:32:50 UTC

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