Fix unneeded messages when sending initial state

[danxuliu]

TL;DR; this pull request introduces specific classes to send the media state and name to other participants, and while doing so it changes how they are sent, greatly reducing their number.

When the media state (audio/video enabled/disabled, speaking/not speaking) and the name of the local participant changes the rest of participants in the call need to be notified. This is done through data channel and signaling messages. Similarly, when a remote participant joins the call the local participant needs to sent the current media state and name to the remote participant so it can set its initial state. If the local participant is the one joining the call it needs to notify the state to all the other participants already in the call.

Until now in all cases the notification was done to all the remote participants in the call. However, although that is needed when the state changes, it was overkill when sending the initial state, as the messages should have been sent only to the specific participant that joined. Now the initial state is sent only to specific participants rather than to all participants (except when using Janus and data channel messages, as Janus does not support sending data channel messages to specific participants).

Nevertheless, when using Janus the messages are still sent with an exponential backoff, as it is not possible to know when the remote participant has "seen" the local participant. However, before that was done when a subscriber connection was established with a remote participant (or a remote participant joined, if it was not publishing). That did not guarantee that the message would be received by the remote participant (hence the exponential backoff), and it was actually a bit messy (as the state of a publisher was sent based on a subscriber). Moreover, it sent many unneeded messages, as they were sent whenever the connection changed to the connected state, so it would be also sent if the subscriber WebRTC connection briefly disconnected and recovered by itself. Due to all that when using Janus now the state to the remote participants are sent just when they join the call.

When not using Janus the state is still sent when the connection is established, but only when it is established for the first time. Similarly, doing it whenever the connection changed to the connected state was unneeded. Note that without Janus the exponential backoff is not needed, because the connections are peer connections between the participants, so if it is established it is guaranteed that the remote participant has "seen" the local participant.

For further details please refer to the commit messages and the documentation in the classes.

All the above changes can greatly reduce the number of messages (specially signaling messages) that are sent in large calls. For reference, when using Janus, in a best case scenario with each participant joining just once, before these changes, in a webinar with 200 participants there would have been, at least, ~48M signaling messages just from sending the initial state (because the messages were sent to all participants, and it was sent every time a participant established a connection / joined, so it was a summatory from 1 to n of n*n states, and each state is sent in 3 separate messages and 6 times for each due to the exponential backoff). With these changes, in a best case scenario, there would be ~720k signaling messages from the initial state (because the messages are now sent directly to the participant that joined, although the exponential backoff and separate messages are still used).

Follow ups

• When using Janus, do not send the media state if the local participant is not publishing
  • Requires fix: Set correct defaults for remote media talk-ios#2430
• When using the external signaling server, probably use transient data to send the media state and the name
  • Requires adjustments in all clients
  • Combining the messages would be automatically done
• Send speaking state through signaling messages (also with the internal signaling server) and finally get rid of data channel messages?
  • Requires adjustments in all clients
• Add hand raised to the initial state

[fancycode]

Can't you just listen on the join event and when a new session joins, send it the data? With that you should not need to sent it multiple times. If you received the join event for a session, it is connected and in the room (and will be able to receive events).

[danxuliu]

If I am not mistaken the join event is sent when a participant joins the room, so it can not be used here as the messages should be sent only to the participants that joined the call.

Nevertheless, the equivalent would be participants->update, but if I recall correctly the problem is that the clients might ignore the messages with the state of other participants if they are sent "too soon":

• the client sends the HTTP request to join the call
• another client receives the signaling message with the participants update
• that other client sends the state with a signaling message
• the client that just joined has not received yet the list of participants in the call -> the signaling message with the state is ignored

I think there were other possible scenarios, like getting the signaling message before receiving the HTTP response so the client also ignored the messages (that was fixed in the WebUI for an unrelated issue, but I am not sure about other clients).

Of course all that could be solved by ensuring that all clients keep track of the state of remote participants as soon as the client begins the HTTP request to join the call. However, the current changes should be an intermediate step until a better overall solution, most likely using the transient states feature of the signaling server :-) so adjusting all the clients is better deferred until then.

[danxuliu]

/backport to stable33 please

[danxuliu]

/backport to stable32 please

[Antreesy]

Read through, smoke tested with janus+hpb in local docker env. Don't have much comments on that.

Follow-up: need to look into boilerplate binding for functions and webrtc listeners, maybe we could avoid that in future