RTCIceTransportState and IceGatherer pruning #197
From Robin Raymond:
If an ice transport has exhausted all candidate testing possible (but not found any route) but end of candidates is not received yet, what state is the ice transport in?
not connected - no route is possible
In Section 3.7, the definition of "disconnected" state says:
“Liveness checks have failed (such as those in [CONSENT]). This may trigger intermittently (and resolve itself without action).”
Based on that text, it would seem that RTCIceTransportState should be "disconnected", BUT...
We are proposing that Section 5.1 (RTCIceGatherer Overview) say the following:
“The RTCIceGatherer does not prune local candidates until at least one RTCIceTransport object has become associated and all associated RTCIceTransport objects are in the "completed" or "disconnected" state.”
But we don’t want to prune in disconnected state when there’s no “end of candidates”.
The text was updated successfully, but these errors were encountered:
Here is what draft-ietf-mmusic-trickle-ice Section 8.1 says:
8.1. Check List and Timer State Updates
The vanilla ICE specification requires that agents update check lists
o all of the pairs in the check list are either in the Failed or
o if at least one of the components of the media stream has no pairs
With trickle ICE, the above situation would often occur when
o all candidate harvesters have completed and the agent is not
o the remote agent has sent an end-of-candidates indication for that
Vanilla ICE requires that agents then update all other check lists,
Also, Section 9.3 says:
Receiving an end-of-candidates notification allows an agent to update
An agent MAY also choose to generate an end-of-candidates event
When performing half trickle agents SHOULD send end-of-candidates
When end-of-candidates is sent as part of an offer or an answer it
Once an agent sends the end-of-candidates event, it will update the
How about the following edits to Section 3.7?
#148 - Clarified handling of incoming connectivity checks prior to calling iceTransport.start(), as noted in: #170 - Clarified handling of incoming DTLS packets, as noted in: #173 - Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in: #174 - Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in: #185 - Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the "closed" state, as noted in: #186 - Added component method and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in: #188 - Added close() method to the RTCIceGatherer object as noted in: #189 - Clarified behavior of TCP candidate types, as noted in: #190 - Clarified behavior of iceGatherer.onlocalcandidate, as noted in: #191 - Updated terminology in Section 1.1 as noted in: #193 - Updated RTCDtlsTransportState definitions, as noted in: #194 - Updated RTCIceTransportState definitions, as noted in: #197