IceTransportState after consent failure #216

Closed
aboba opened this Issue Jun 21, 2015 · 1 comment

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Jun 21, 2015

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.

@aboba aboba added the 1.1 label Jun 21, 2015
@aboba
Contributor
aboba commented Jun 21, 2015

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.

@robin-raymond robin-raymond pushed a commit that referenced this issue Jun 22, 2015
Robin Raymond Addressed Philipp Hancke's review comments, as noted in: Issue #198
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
894b08b
@aboba aboba closed this Jun 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment