I proposed an onError event for RTCPeerConnection to fire RTCPeerConnectionErrorEvent.

We can use this single error event for almost all kinds of errors that may arise on RTCPeerConnection, with different error names.




and some more that might be discussed, some time down the line in the group.

Propably you might see that in Error Handling slides to be discussed on day-2.



------- Original Message -------

Sender : Roman Shpount<roman@telurix.com>

Date : May 19, 2014 12:59 (GMT+09:00)

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


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.