#721 Fix publisher negotiation race condition causing ICE timeouts #789
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: 8877634 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
adrian-niculescu
force-pushed
the
fix-publisher-negotiation-race-721
branch
from
05e6642 to
dbefc91
Compare
Added Mutex to serialize concurrent negotiatePublisher() calls that were causing ICE gathering failures when subscriberPrimary=true and fastPublish=true. The race condition occurred when: 1. negotiatePublisher() called from RTCEngine.join() (fastPublish=true) 2. negotiatePublisher() called again from ensurePublisherConnected() 3. Both coroutines executed concurrently, bypassing the debounce mechanism 4. Multiple parallel SDP offers corrupted ICE state The fix uses tryLock() to make the second call a no-op, ensuring only one negotiation runs at a time. Fixes: #721
adrian-niculescu
force-pushed
the
fix-publisher-negotiation-race-721
branch
from
dbefc91 to
8877634
Compare
adrian-niculescu
changed the title
davidliu
approved these changes
Nov 2, 2025
Contributor
|
Wow! Thank you so much for the investigation here! |
Merged
Contributor
Author
Happy to help! Really appreciate your quick turnaround and for getting the fix published so fast. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
This PR fixes a race condition in
negotiatePublisher()that causes ICE gathering failures and connection timeouts when sending data messages immediately after connecting to a room.Issue
Fixes #721
Root Cause Analysis
The detailed analysis is in this comment: #721 (comment)
TL;DR
When the server responds with both
subscriberPrimary=trueandfastPublish=true, two concurrent calls tonegotiatePublisher()occur:RTCEngine.join()at connection time (whenfastPublish=true)ensurePublisherConnected()when sending the first data messageThe existing debounce mechanism fails with concurrent coroutines due to non-atomic read-modify-write operations on the shared
debounceJobvariable. This results in:The Fix
Added a
Mutexto serializenegotiatePublisher()calls usingtryLock():Testing
This fix has been tested in production with a VoIP application handling incoming calls that:
subscriberPrimary=trueBefore: ~20% failure rate with publisher ICE timeouts
After: 0% failure rate in extensive testing
Impact
This should also fix the issue reported in #721 by @Christophe-DC and others experiencing connection instability when sending data messages immediately after room connection.