fix(call): recover subscriber connections stuck before ICE failure - #18715
fix(call): recover subscriber connections stuck before ICE failure#18715tareko wants to merge 1 commit into
Conversation
With the high performance backend a subscriber connection that stays in "disconnected" is not acted upon, as only "failed" connections request a new offer. However, some browsers may never report the connection as "failed" (and ICE has no timeout at all while in "new" state, with "checking" also able to get stuck), so the participant tile stays in "connecting" state and no audio is heard until the call is rejoined. Extract the existing "request offer and retry every 10 seconds until received" logic into a helper and reuse it from two new watchdogs for MCU subscriber peers: - a connection still "disconnected" 10 seconds after entering the state requests a new offer, - a connection still in "new" or "checking" state 30 seconds after the peer was created requests a new offer (re-armed for each replacement peer, so recovery keeps retrying until it succeeds). The retry interval is cleared when the new offer arrives, and the state guards make the timers no-ops once the connection leaves the stuck state or the peer is ended. Non-MCU connections and the own publishing peer are intentionally left unchanged. Assisted-by: OpenCode:moonshotai/kimi-k3
nickvergessen
added
feature: WebRTC 🚡
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
|
Quick ping that I've been using this patch in production since I posted it and it has been working very well so far. |
|
Thanks for confirmation! Sorry it has slipped our attention... We'll try to get this reviewed soon cc @danxuliu for a better expertise |
3 participants
With the high performance backend a subscriber connection that stays in "disconnected" is not acted upon, as only "failed" connections request a new offer. However, some browsers may never report the connection as "failed" (and ICE has no timeout at all while in "new" state, with "checking" also able to get stuck), so the participant tile stays in "connecting" state and no audio is heard until the call is rejoined.
Extract the existing "request offer and retry every 10 seconds until received" logic into a helper and reuse it from two new watchdogs for MCU subscriber peers:
The retry interval is cleared when the new offer arrives, and the state guards make the timers no-ops once the connection leaves the stuck state or the peer is ended. Non-MCU connections and the own publishing peer are intentionally left unchanged.
Assisted-by: OpenCode:moonshotai/kimi-k3
☑️ Resolves
AI