You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the May editor's draft, it is stated that a consent failure causes a transition to the "checking" state:
"In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair, or liveness checks have failed (such as those in [CONSENT]) on a previously successful candidate pair."
Is this correct, or should the failure of liveness checks result in a transition to the "disconnected" state?
Proposed revised text for "checking" and "disconnected":
Checking
In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair.
Disconnected
The RTCIceTransport has received at least one local and remote candidate, and a local and remote RTCIceCandidateComplete dictionary was not added as the last candidate, but all appropriate candidate pairs thus far have been tested and failed (or consent checks [CONSENT], once successful, have now failed). Other candidate pairs may become available for testing as new candidates are trickled, and therefore the "failed" state has not been reached.
The text was updated successfully, but these errors were encountered:
Actually, it is possible to transition to checking due to a consent failure if all candidate pairs have not yet been checked:
The RTCIceTransport has received at least one remote candidate, and a local and remote RTCIceCandidateComplete dictionary was not added as the last candidate. In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair, or liveness checks have failed (such as those in [CONSENT]) on a previously successful candidate pair.
Added the "failed" state to RTCIceTransportState, as noted in: Issue #199
Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue #200
Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in: Issue #207
Updated the description of RTCIceGatherer.close() and the "closed" state, as noted in: Issue #208
Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue #214
Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue #215
Clarified state transitions due to consent failure, as noted in: Issue #216
Added a reference to [FEC], as noted in: Issue #217
In the May editor's draft, it is stated that a consent failure causes a transition to the "checking" state:
"In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair, or liveness checks have failed (such as those in [CONSENT]) on a previously successful candidate pair."
Is this correct, or should the failure of liveness checks result in a transition to the "disconnected" state?
Proposed revised text for "checking" and "disconnected":
Checking
In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair.
Disconnected
The RTCIceTransport has received at least one local and remote candidate, and a local and remote RTCIceCandidateComplete dictionary was not added as the last candidate, but all appropriate candidate pairs thus far have been tested and failed (or consent checks [CONSENT], once successful, have now failed). Other candidate pairs may become available for testing as new candidates are trickled, and therefore the "failed" state has not been reached.
The text was updated successfully, but these errors were encountered: