Disconnect received videos by toggling the video directly in Janus

[danxuliu]

Follow up to #6862
Requires strukturag/nextcloud-spreed-signaling#239 (v0.5.0)

Originally the HPB required a renegotiation to block the received videos. However, besides the standard WebRTC way, Janus also supports directly toggling on and off the video without any renegotiation. This is now exposed by the signaling server through the selectStream message, so the video is now blocked using that approach instead.

The previous code to block the video using a renegotiation is still kept, though, as it could be used without HPB once all the clients support renegotiations.

Pending:

• Explicitly block the video after a renegotiation? After a renegotiation the video needs to be explicitly blocked again, although currently no renegotiations (requesting an offer again with the same sid) should be triggered on the HPB subscribers (it was done only to block the video before doing that with the Janus specific approach) - Not needed, see comment below

How to test

In the test below, in Firefox it can be verified that the video is stopped and resumed again opening about:webrtc and checking the video stats in the receiver connection; for easier checking it is recommended to join the call without audio nor video in the private window so there is only one sender and one receiver connection.

• Setup the HPB
• Start a call with audio and video
• In a private window, join the call
• Open the browser console to check the messages
• Disable and enable the received video

Result with this pull request

No offers are requested (there are no new Request offer from messages when the video is disabled and enabled); the video immediately resumes after enabling it again

Result without this pull request

Offers are requested to renegotiate the existing connection and disable the video; the video may take a few seconds to resume once it is enabled again

[danxuliu]

When forced reconnections are used to start or stop sending a video disconnecting the received video works without issues, no matter the Janus version, as a new connection is established in each case. This is the current state.

However, once forced reconnections are replaced with renegotiations there are several scenarios:

• Janus < 0.12.2: after a renegotiation the received video will be always enabled, even if it was explicitly blocked before
• Janus 0.12.2 and 0.12.3: after a renegotiation the received video will be always disabled, even if it was never explicitly blocked before; this was a side effect of fixing the previous behaviour when a configure request was explicitly sent
• Janus >= 0.12.4: after a renegotiation the received video state will be enabled if not explicitly blocked before, and disabled if explicitly blocked before; the behaviour introduced in 0.12.2 when a video is implicitly disabled was fixed

Nevertheless, replacing forced reconnections with renegotiations will require Janus 0.12.4 to be used, no matter if the received videos are disconnected or not. Janus 0.12.4 is the version paired with nextcloud-spreed-signaling 1.0.0 in the HPB repository.

Due to all of the above there is no need to work around the issues in Janus < 0.12.4 in this pull request.

[nickvergessen]

Due to all of the above there is no need to work around the issues in Janus < 0.12.4 in this pull request.

Totally agree.

[nickvergessen]

Works as advertised