On Mon, May 19, 2014 at 3:01 AM, Philipp Hancke <fippo@goodadvice.pages.de>wrote: > 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