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