1527916 - Support RTCError interface

Status: NEW

(Core :: WebRTC: Signaling, enhancement, P3)

Comment 1

[Paul Adenot (:padenot)]

Byron, I assume you want to do this soon, maybe it's a P3 for later though.

Comment 2

[Byron Campen [:bwc]]

Note that most of this stuff is currently marked as a feature at risk, and the wpt do not quite reflect the spec.

This involves:

• Add RTCErrorDetailType
• dom::PCError probably converted to RTCError
• I suspect there are some wpt that need to be adjusted to expect RTCError (potential web-compat headache here)
• I suspect there are some spec issues that we'll find while doing this
• The wpt for RTCError is checking for RTCError.httpRequestStatusCode, which is not in the spec.
• We'll need to bring JsepSession::Result in line with this; it will need to be able to cause either a DOMException or an RTCError with it, and we'll need to make updates to JsepSessionImpl to throw the right thing.
• I think we already have line-numbers for all SDP parse errors, so we should be able to populate RTCError.sdpLineNumber easily.
• We'll need to plumb SCTP/DataChannel failures back to PeerConnectionImpl for sctpCauseCode, and the "data-channel-failure" and "sctp-failure" RTCErrorDetailTypes.
• We'll need to plumb DTLS failures back to PeerConnectionImpl (need to add some stuff to MediaTransportHandler and friends for this) for receivedAlert, sentAlert, and the "dtls-failure" and "fingerprint-failure" RTCErrorDetailTypes.
• We'll need to plumb media stack hardware encoder errors for the "hardware-encoder-not-available" and "hardware-encoder-error" RTCErrorDetailTypes.

This is a lot, and it probably makes sense to do this in stages.