New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IceTransportState after consent failure #216

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

Comments

Projects
None yet
1 participant
@aboba
Copy link
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

This comment has been minimized.

Copy link
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.

@aboba aboba added the PR exists label Jun 21, 2015

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

@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