Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Do not force reconnections when starting and stopping media #6934

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Do not force reconnections when starting and stopping media #6934

wants to merge 3 commits into from

Conversation

danxuliu
Copy link
Member

@danxuliu danxuliu commented Feb 25, 2022 •
edited
Loading

Until now, when a participant started to publish media that participant had to force a reconnection. This caused the participant to leave and join the conversation again, which in turn ensured that the clients established a connection to receive the media from that participant (as the participant was treated as a new participant).

Instead of that clients must proactively establish the connection with a participant when the call flags changed (for example, from IN_CALL to IN_CALL | WITH_AUDIO). The WebUI will stop forcing a reconnection in those cases in order to have a smoother call experience (once handling the call flags is implemented in the mobile clients as well, but it should not be a very difficult change as shown in the second commit).

Pending:

  • Implement proactive creation of connections based on call flag changes in mobile apps
  • Check if there are other forced reconnections that can be removed
  • Test both with and without HPB, and both starting and stopping media
  • Fix trying to update the connection again and again when the other participant does not have streams and the local one does without HPB
  • Rebase on Use renegotiations to update publisher connections #6896 to get a full picture
  • Add capability so mobile apps know if they need to force a reconnection or just update the call flags (as publishers)?

How to test (scenario 1)

  • Start a call
  • In a private window, join the call and, in the device checker shown before actually starting the call, select no audio device and no video device
  • Join the call
  • Open the device settings, select a video device and close the device settings
  • Enable video

Result with this pull request

In the original window the video is now visible even if no forced reconnection was triggered

Result without this pull request

In the private window a forced reconnection was triggered

How to test (scenario 2)

  • Remove audio and video permissions by default in a conversation
  • Start a call as a moderator
  • In a private window, open the conversation as a guest
  • Join the call
  • In the original window, grant video permissions to the guest
  • In the private window, enable video

Result with this pull request

In the original window the video is now visible even if no forced reconnection was triggered

Result without this pull request

In the private window a forced reconnection was triggered

@danxuliu
Extract function to create a Peer for a participant
53ebe16 
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
@danxuliu
Create and destroy Peers based on call flag changes
cc3aac0 
Instead of relying on forced reconnections made by the publisher when
media was started or stopped (and there was no other media stream) now
the changes in the call flags are monitored to proactively create and
destroy Peers as needed. This will make possible to get rid of forced
reconnections in those cases (but this needs to be supported by the
mobile clients too before forced reconnections no longer need to be
triggered).

Note that, technically, even if all media streams are stopped there is
no real need to destroy the Peer object and stop the connection, as the
publisher will still keep the connection open, although with null
tracks. Nevertheless, closing the connection once no longer needed does
no harm either, and it can be started again later if needed.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
@danxuliu
Do not force reconnections when starting and stopping media
ef643d5 
Instead of forcing a reconnection to ensure that clients will realize
that there was a change in the media being published trust them to
proactively establish connections based on the changes in the call
flags.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
@danxuliu danxuliu added this to the 💛 Next Major (24) milestone Feb 25, 2022
This was referenced Mar 31, 2022
Merged
Open
@danxuliu danxuliu mentioned this pull request Apr 13, 2022
Draft
3 tasks
@danxuliu danxuliu mentioned this pull request May 17, 2022
Closed
@danxuliu danxuliu mentioned this pull request Aug 31, 2022
Open
6 tasks
@danxuliu danxuliu mentioned this pull request Dec 4, 2022
Draft
2 tasks
@nickvergessen nickvergessen removed this from the v16.0.0-beta.1 milestone Feb 23, 2023
@nickvergessen nickvergessen added feature: WebRTC 🚡 WebRTC connection between browsers and/or mobile clients feature: signaling 📶 Internal and external signaling backends labels Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
2. developing client: 🤖🍏 mobile feature: call 📹 Voice and video calls feature: signaling 📶 Internal and external signaling backends feature: WebRTC 🚡 WebRTC connection between browsers and/or mobile clients
Projects
None yet
Milestone
🌿 Next Beta (31)
Development

Successfully merging this pull request may close these issues.
2 participants
@danxuliu @nickvergessen