fix: (Mobile) Voice calls failing when accepted from the lock screen
Proposed changes (including videos or screenshots)
Due to how the mobile app implements voice calls, when a call is accepted from the phone's lock screen it will be registered in the lib and then immediately accepted. This was causing a soft lock where the lib would never request the user's audio for that call, the negotiation would eventually timeout and the call would be dropped.
It happened because when a call is first initialized, it doesn't yet need to request the audio; only after it was accepted. The initialization would trigger the function that updates the state of audio track and it would determine the track is not yet needed, but this function has an await instruction that causes it to remain in the "updating" state until after the call is flagged as accepted. Once the update function completes, the call would be flagged as already updated and the state change would not be processed.
This PR changes the code so that the call will only enter the "updating" state when the track state is actually being changed (as opposed to every time it checks if it needs to change).
In addition I've also made sure that the call's internal state will be refreshed when the first negotiation starts and I also improved the timeout code to explicitly identify when a call fails due to missing the audio track.
Issue(s)
Steps to test or reproduce
Further comments
Summary by CodeRabbit
-
Bug Fixes
- Resolved soft lock issue in call negotiation that could stall when calls are accepted during initialization.
-
Improvements
- Enhanced input track switching with improved concurrency handling and race condition protection.
- Strengthened state management during call negotiation lifecycle for better stability.