Clarify ICE consent freshness feedback #517

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


None yet

4 participants


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.


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.


@nils-ohlmeier can you check #457 to see if this is part of the same problem?
Also check the slides for the interim here:

@elagerway opinions?


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 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 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 commented Apr 14, 2016

Related to #457


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
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
@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