Checks in https://w3c.github.io/webrtc-pc/#dom-RTCDTMFSender-insertDTMF could be simplified

[youennf]

Step 3 and 4 of insertDTMF are:
3. If transceiver's [[Stopped]] slot is true, throw an InvalidStateError.
4. If transceiver's [[CurrentDirection]] slot is recvonly or inactive, throw an InvalidStateError.
Step 6.6 (canInsertDTMF) will trigger an InvalidStateError if transceiver's [[CurrentDirection]] is neither "sendrecv" nor "sendonly".

Steps 4 is unneeded given step 6.6.
Since transceiver's [[CurrentDirection]] is supposed to be null in case transceiver's [[Stopped]] is true, we could also potentially remove step 3 as well.

It also seems checks 17.1 and 17.2 could be rewritten as a single check:
If transceiver's [[CurrentDirection]] slot is neither "sendrecv" nor "sendonly", abort these steps.

[alvestrand]

Those seem like simplifications of the language with no change in behavior.
I suspect 17.1 is older than the decision to make transceiver.stop() clear CurrentDirection, I'm a bit hesitant to depend on the "remote action" here. Current language seems to do no harm.

[youennf]

Agreed this is editorial.
When reading the spec, it seemed odd to me that there could be a possibility for canInsertDTMF to return true and for insertDTMF to throw InvalidStateError.

[youennf]

Fixed with #2285