Clarify ICE consent freshness feedback #517

Closed
nils-ohlmeier opened this Issue Feb 22, 2016 · 8 comments

Projects

None yet

4 participants

@nils-ohlmeier

When implementing RFC 7665 it is not very well defined how the different state transitions from that RFC get reported back through the PeerConnection APIs.

@nils-ohlmeier

I think it is kind of obvious to use the RTCIceConnectionState to communicate the events.

As RFC 7665 mandates that loosing consent after the 30s timer is permanent for a given pair translating loosing consent for a single component into the 'failed' state appears appropriate.
The open question for me is if each STUN transaction timeout from 7665 should get translated into 'disconnected', followed by potentially switching back to 'connected' or 'completed' once consent has been re-established.

@alvestrand
Contributor

@nils-ohlmeier can you check #457 to see if this is part of the same problem?
Also check the slides for the interim here:
https://docs.google.com/presentation/d/1R7lQeo4LNGu0KKW9GLdkwJ5x8FUmR4qrnhfPFZO3WS8/edit#slide=id.gd4bd98a32_0_387

@elagerway opinions?

@nils-ohlmeier

To some degree yes it is the same problem, as it also touches the same state diagram.

Whether [CONSENT] final 30s timeout leads to 'failed' or to 'disconnected' (or 'checking' as proposed on the slides for the checking state) does not really matter to me. It just needs to be defined and written down. That should be easy.
The open questions which I don't have a good answer to (yet) is if a timeout on a single STUN transaction from [CONSENT] should result in a (temporary) state change (and if so to which state). From reading through #457 that does not appear as question which has been raised. But I'll happily add it to the discussion in #457, because it makes sense to clean that up together.

@aboba
Contributor
aboba commented Feb 24, 2016

The outcome of each individual consent check should not be reflected in either RTCIceTransportState or RTCIceConnectionState, because there is nothing a developer can or should do about the failure of individual consent checks. Consent request/response statistics is another matter.

My suggestion is that a consent failure in the "completed" state should cause a transition to "failed" for both RTCIceTransportState and RTCIceConnectionState.

@aboba aboba was assigned by dontcallmedom Mar 1, 2016
@aboba
Contributor
aboba commented Mar 3, 2016

@nils-ohlmeier @alvestrand I have submitted RTCIceTransportState definitions that at least partially takes consent check failures into account: PR #533

@aboba aboba added the PR exists label Mar 3, 2016
@aboba aboba removed the PR exists label Mar 17, 2016
@aboba
Contributor
aboba commented Apr 14, 2016

Related to #457

@alvestrand
Contributor

Depends on #457

@aboba aboba added a commit that referenced this issue May 2, 2016
@aboba aboba Clarify ICE consent freshness feedback
Fix for Issue #517
69820c9
@aboba
Contributor
aboba commented May 2, 2016

@nils-ohlmeier @taylor-b Can you review PR #611 ?

@aboba aboba added a commit to w3c/ortc that referenced this issue May 2, 2016
@aboba aboba Consent checks: RTCIceTransportState corrections
In response to WebRTC 1.0 Issue w3c/webrtc-pc#517
0096e67
@alvestrand alvestrand closed this May 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment