Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While digging into connectivity issues as part of jitsi/jitsi-meet#3738 , I discovered a bug (and potential fix) in the way that connectivity-readiness is notified out to other participants/channels during a conference.
In short, are two paths which both need to be called in order for a connection to become 'ready'.
However, only one of these locations currently performs the before & after check to see if the connection state has changed from unready to ready. This should be innocent and just result in more
notifySctpConnectionReady
calls than necessary, but there appear to be side-effects from that call which result in the connection looping. 7492b47 can be merged in isolation to see the effect of that by enhancing the debug logs a little.Not yet certain this is the correct or full fix - I think something further down the chain from
notifySctpConnectionReady
also needs to be handled here, but this helped me to make a bit of progress.NB: Tests aren't yet working due to an obscure dual-classloaders issue, and commits are out-of-order from some rebasing.