Issue 692: Meaning of "Liveness checks have failed" for `disconnected` ICE state is not clear

Taylor has filed the following issue against WebRTC 1.0, which also applies to the ORTC specification:
https://github.com/w3c/webrtc-pc/issues/692

Both specifications now have very similar RTCIceTransportState definitions, which make reference both to "consent checks" (checking, connected and completed states),  "liveness checks" (disconnected state), and "connectivity checks" (failed state).

My assumption is that "consent checks" refers to Consent Freshness (RFC 7675), and that "connectivity checks" refers to ICE Connectivity checking as described in RFC 5245 Section 7.  But what does "liveness checks" refer to?  Elsewhere in the description of the disconnected state, a reference is made to consent failure, so presumably "liveness checks have failed" does not represent consent failure (which cannot "resolve itself without action").

Personally, I am not sure it really makes sense to enter the disconnected state based on the failure of a few consent checks prior to consent failure. Could we just delete the first two sentences in the disconnected state description?

Enumeration description

new

The RTCIceTransport is gathering candidates and/or waiting for remote candidates to be supplied, and has not yet started checking.

checking

The RTCIceTransport has received at least one remote candidate and is checking candidate pairs and has either not yet found a connection or consent checks [RFC7675<http://w3c.github.io/webrtc-pc/#bib-RFC7675>] have failed on all previously successful candidate pairs. In addition to checking, it may also still be gathering.

connected

The RTCIceTransport has found a usable connection, but is still checking other candidate pairs to see if there is a better connection. It may also still be gathering and/or waiting for additional remote candidates. If consent checks [RFC7675<http://w3c.github.io/webrtc-pc/#bib-RFC7675>] fail on the connection in use, and there are no other successful candidate pairs available, then the state transitions to "checking" (if there are candidate pairs remaining to be checked) or "disconnected" (if there are no candidate pairs to check, but the peer is still gathering and/or waiting for additional remote candidates).

completed

The RTCIceTransport has finished gathering, received an indication that there are no more remote candidates, finished checking all candidate pairs and found a connection. If consent checks [RFC7675<http://w3c.github.io/webrtc-pc/#bib-RFC7675>] subsequently fail on all successful candidate pairs, the state transitions to "failed".

failed

The RTCIceTransport has finished gathering, received an indication that there are no more remote candidates, finished checking all candidate pairs, and all pairs have either failed connectivity checks or have lost consent.

disconnected

Liveness checks have failed. This is more aggressive than failed, and may trigger intermittently (and resolve itself without action) on a flaky network. Alternatively, theRTCIceTransport<http://w3c.github.io/webrtc-pc/#idl-def-rtcicetransport> has finished checking all existing candidates pairs and failed to find a connection (or consent checks [RFC7675<http://w3c.github.io/webrtc-pc/#bib-RFC7675>] once successful, have now failed), but is still gathering and/or waiting for additional remote candidates.

closed

The RTCIceTransport has shut down and is no longer responding to STUN requests.