- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 27 May 2016 08:01:04 -0700
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CABcZeBN7Yj_OaxE_GrSD5WByoSsjwi6ee6e4-b7R9g+bzW=iug@mail.gmail.com>
Section 4.3.1. reads in part:
1.
If the process to apply description fails for any reason, then user
agent must queue a task runs the following steps:
1.
If connection's [[isClosed
<http://w3c.github.io/webrtc-pc/#dfn-isclosed>]] slot is true, then
abort these steps.
2.
If elements of the SDP were modified in an invalid way as specified
in [JSEP <http://w3c.github.io/webrtc-pc/#bib-JSEP>] (section 6.
<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-6>),
then reject p with an InvalidModificationError and abort these steps.
3.
If the description's type
<http://w3c.github.io/webrtc-pc/#dom-rtcsessiondescription-type> is
wrong for the current signaling state
<http://w3c.github.io/webrtc-pc/#dfn-signaling-state> of connection,
then reject p with aInvalidStateError and abort these steps.
4.
If the content of description is invalid, then reject p with an
InvalidAccessError and abort these steps.
5.
For all other errors, for example if description cannot be applied at
the media layer, reject p withOperationError.
Consider what happens if I invalidly modify an SDP *and* the PC is in the
wrong state. This algorithm clearly tells you that you should be returning
InvalidModificationError, which doesn't seem sensible.
In general, I don't think the spec should be requiring a specific order of
error checking.
-Ekr
Received on Friday, 27 May 2016 15:02:12 UTC