New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling #26

Closed
aboba opened this Issue Jan 31, 2014 · 1 comment

Comments

Projects
None yet
2 participants
@aboba
Copy link
Contributor

aboba commented Jan 31, 2014

From: Adalberto Foresti aforesti@microsoft.com
To: public-orca@w3.org
Subject: error handling
Date: Sun, 26 Jan 2014 21:16:54 +0000
URL: http://lists.w3.org/Archives/Public/public-orca/2014Jan/0037.html

An area where the spec does not delve into much detail yet is the error handling strategy. To make an example among other possible ones:

RTCDtlsTransport does not offer any way to communicate failure to establish transport currently. There is neither a failure callback in the constructor, nor a "failed" state. A possible way to address this is to add such a "Failed" state to the RTCDtlsTransportState enum and use it to notify via onstatechange event.

Thoughts? (on either this specific scenario or the more general issue)

Adalberto Foresti
Principal Program Manager
Microsoft Open Technologies, Inc.
A Subsidiary of Microsoft Corporation

[Justin Uberti]
I think we need the ability to surface details about the error; also, an
error could occur at any time, not just while handshaking (e.g. upon
receipt of a DTLS alert).

So while a 'failed' state may make sense, it may be better to simply have
errors trigger a change to "closed" with an accompanying .onerror callback
that surfaces a detailed error object.

[Martin Thomson]
That makes plenty of sense to me. onerror seems like a general
pattern worth following. Having more direct error reporting for
specific actions can still be useful, but I'd expect that with an
'onerror', the bar would be higher for adding secondary error
reporting channels.

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Apr 25, 2014

This issue has been open for a while. Here is a proposal for resolving it.

  1. Add an onerror event to the RTCDTlsTransport object, as follows:

[Constructor(optional RTCIceTransport transport)]
interface RTCDtlsTransport {
attribute RTCIceTransport transport;
readonly attribute RTCDtlsTransportState state;
RTCDtlsParameters getLocalParameters ();
RTCDtlsParameters? getRemoteParameters ();
void start (RTCDtlsParameters remoteParameters);
void stop ();
attribute EventHandler? onstatechange;
attribute EventHandler? onerror;
};

interface onerror : Event {
readonly attribute DOMError e;
};

  1. Add an onerror event to the RTCDataChannel interface (this is already supported in WebRTC 1.0).

On reviewing the rest of the specification, it wasn't obvious that other modifications were needed. For example:

a. The RTCIceTransport object has an ongatherfailure event. This seemed like the most common error, so it wasn't clear that an onerror event was needed in addition;
b. The RTCIceListener and RTCRtpListener objects are simple enough that an onerror event doesn't seem needed;
c. Errors in SCTP transport establishment will presumably surface via the RTCDataChannel.onerror event, so that an onerror event wouldn't be needed for the RTCSctpDataTransport object;
d. The Stats API supports an error callback (although it isn't clear to me when this would fire), and this is probably sufficient.

@robin-raymond robin-raymond added the 1.1 label Apr 29, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 29, 2014

Robin Raymond
- Fixes for error handling, as described in w3c#26
- Support for contributing sources removed (re-classified as a 1.2 feature), as described in w3c#27
- Cleanup of DataChannel construction, as described in w3c#60
- Separate proposal on simulcast/layering, as described in w3c#61
- Separate proposal on quality, as described in w3c#62
- Fix for TCP candidate type, as described in w3c#63
- Fix to the fingerprint attribute, as described in w3c#64
- Fix to RTCRtpFeatures, as described in w3c#65
- Support for retrieval of remote certificates, as described in w3c#67
- Support for ICE error handling, described in w3c#68
- Support for Data Channel send rate control, as described in w3c#69
- Support for capabilities and settings, as described in w3c#70
- Removal of duplicate RTCRtpListener functionality, as described in w3c#71
- ICE gathering state added, as described in w3c#72
- Removed ICE role from the ICE transport constructor, as described in w3c#73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment