- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Jan 2019 08:10:39 +0000
- To: public-webrtc-logs@w3.org
Both state 1 and state 3 should be valid states at different points in the setup.
Before choosing a pair, we will have state 1.
The DTLS handshake is exchanged on the media path, which can only be exchanged once the candidate pair has been selected, which means that the ICE connection's state has changed to "connected" or "completed" state.
Thus, there is a time lag between the ICE state reporting "connected" and the DTLS state reporting "connected". Before DTLS state "connected", we have state 3; after it, we have state 2.
RFC 5245 section 11.1.1 says about the selected pair:
The selected pair for a component of a media stream is:
o empty if the state of the check list for that media stream is
Running, and there is no previous selected pair for that component
due to an ICE restart
o equal to the previous selected pair for a component of a media
stream if the state of the check list for that media stream is
Running, and there was a previous selected pair for that component
due to an ICE restart
o equal to the highest-priority nominated pair for that component in
the valid list if the state of the check list is Completed
The test is not doing an ICE restart (I assume, without checking), so the middle category does not apply.
So if the selected pair exists, the state of the check list has to be Completed.
The candidate pair's state is defined as one of frozen, waiting, in-progress, failed or succeeded according to RFC 5245 section 5.7.4, where it says that "The state is assigned once the check list for each media stream has been computed", and is subsequently updated.
The existence of nominated pairs depends on whether we are doing regular or aggressive nomination (8.1.1) - with aggressive nomination, it is possible to have nominated pairs in the failed state.
But aggressive nomination is discouraged, and outright removed from ICEv2 - I don't think Chrome does it.
Short-short: If we have a selected pair that is not in the "succeeded" state, I think that's a bug.
If we don't have a selected pair, that just means we haven't gotten to that point yet.
--
GitHub Notification of comment by alvestrand
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2088#issuecomment-458850415 using your GitHub account
Received on Wednesday, 30 January 2019 08:10:42 UTC