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:
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.
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.
@nils-ohlmeier @alvestrand I have submitted RTCIceTransportState definitions that at least partially takes consent check failures into account: PR #533
Related to #457
Depends on #457
Clarify ICE consent freshness feedback
Fix for Issue #517
@nils-ohlmeier @taylor-b Can you review PR #611 ?
Consent checks: RTCIceTransportState corrections
In response to WebRTC 1.0 Issue w3c/webrtc-pc#517