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.

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

fix(JitsiConference): sync up local tracks #2469

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

paweldomas
Copy link
Member

It can happen that a new session is started while JingleSessionPC operation is in progress.

Queue up the track operation on the new session to make sure it catches up with the correct tracks state.

Example:

  1. JitsiConference.replaceTrack(camera1, camera2);
  2. At the time there's only JVB session, it's replaceTrack will take 100ms.
  3. 50 ms later - a P2P session is started, it will use camera1 as "local tracks" to start the session, because the replacement has not finished yet and this.rtc.localTracks still contains camera1.
  4. Another 50ms later, JVB session finishes the replaceTrack and here we see that there's a new P2P session. Schedule a catch-up replaceTrack operation and make it part of the original addTrack operation chain.

It can happen that a new session is started while JingleSessionPC
operation is in progress.

Queue up the track operation on the new session to make sure it
catches up with the correct tracks state.

Example:
1. JitsiConference.replaceTrack(camera1, camera2);
2. At the time there's only JVB session, it's replaceTrack will
   take 100ms.
3. 50 ms later - a P2P session is started, it will use camera1
   as "local tracks" to start the session, because the
   replacement has not finished yet and this.rtc.localTracks
   still contains camera1.
4. Another 50ms later, JVB session finishes the replaceTrack
   and here we see that there's a new P2P session. Schedule
   a catch-up replaceTrack operation and make it part of the
   original addTrack operation chain.
@paweldomas
Copy link
Member Author

The tests are failing, because JVB conference uses "_getInitiaLocalTracks" while the P2P session uses "getLocalTracks".
The difference between the two is that "_getInitiaLocalTracks" filters out "start with muted" tracks, while "getLocalTracks" just adds all of them. This means that there are two parallel track operation planes, one for P2P and one for JVB.

There will be a crash in case where audio track is added initially and then removed just after (which is the case for start with audio muted, because for some reason jitsi-meet gets involved). If we call remove on the track that was skipped due to start audio/video muted that will fail with unable to find transceiver, because that track was never part of the JVB connection yet.

I may give up on this fix for now, things are just too complicated and trying to fix this case will add yet more "ifs" everywhere and complicate things even more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant