Improve amount of signaling messages when joining a call

[SystemKeeper]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Have an ongoing call with about 55 participants
2. Join the call

Expected behaviour

You receive a reasonable amount of signaling messages

Actual behaviour

In the first 26s you receive around 1070 signaling messages.

Details

Received signaling messages by type:

   1         type = answer;
  16         type = offer;
   1         type = answer;
 695         type = mute;
 351         type = nickChanged;
  16         type = offer;
  7          type = unmute;

#4181 implemented a mechanism to make sure that the initial status of all participants is actually received, which results in a high amount of signaling messages in the first 30s after joining a call. Additionally to those signaling message, some messages are also send/received via the webrtc data channel (nickChanged for example).

Some ideas

• Check that the messages from Improve setting initial audio and video status when the HPB is used #4181 are sent only to the newly joined participant
• Only send speaking/speakingStopped messages through data channel, use signaling for everything else (only possible after all clients support all signaling message types)
• Ignore data channel messages client side, when the type is supported as a signaling message
• Introduce some kind of state message where nickChanged, mute (audio/video) and raisedHand are combined into one single message
• According to Improve setting initial audio and video status when the HPB is used #4181 it is not possible to detect when to send the initial state to a newly joined participant. We could think about letting the newly joined participant request the state, this way it would be 1 message to all (the new participant requesting the state) and 1 message from each participant to the new participant (the actual state), so 56 messages in total.

[SystemKeeper]

Inspired by the discussion at #9272, we could also think about using transient data to provide a current state to newly joined clients.