[stable32] Fix unneeded messages when sending initial state#17407
Merged
nickvergessen merged 11 commits intostable32from Mar 20, 2026
Merged
[stable32] Fix unneeded messages when sending initial state#17407nickvergessen merged 11 commits intostable32from
nickvergessen merged 11 commits intostable32from
Conversation
This will make possible to explicitly call it from other objects rather than having to emit events in the WebRTC object. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will make possible to decouple the messages sent for the initial media state from the messages sent when the media state changes during the call. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently only changes in the audio, speaking and video state are notified, although in the future it should also notify about the nick, the raised hand or any other state. Similarly, although right now it only notifies of changes in the state it will also take care of notifying other participants about the current state when they join the call (or the local participant joins). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will make possible to use module augmentation to provide a TypeScript definition of the class that includes the methods added by the EmitterMixin. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will make possible to explicitly call them from other objects rather than having to emit events in the WebRTC object. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Besides changing where they are sent in the code the new code also reduces the number of signaling messages, as now it sends them directly to each participant rather than to every participant. Moreover, when Janus is used, the state is sent now when the remote participant joins the call rather than when a connection was established with that participant (or joined, if that participant was not a publisher, as in that case no connection was established with it). Sending the state when a connection was established with the remote participant did not guarantee in any way that the signaling message would be received by the remote participant (hence the repeated sending with an exponential backoff), so sending it instead when the participant joins has essentially the same result (as the repeated sending with an exponential backoff is kept), but simplifies the code and makes more sense conceptually (as before the state of the publisher was sent when a connection with a subscriber was established). Similarly, when Janus is not used the state is sent now the first time that a connection is established with the remote participant, but not on every change to the connected state, as doing it only the first time is actually needed. Data channel messages are also sent now directly to the other participant when Janus is not used. However, when Janus is used they are still sent to all participants, as Janus does not support sending data channel messages to a specific participant. Unfortunately that means that data channel messages are still repeated for every participant in the call when another remote participant joins it. This is specially bad when the local participant joins a call, as in that case all the remote participants joined at the same time from the point of view of the local participant. Independently of that, note that when Janus is used the media state is always sent even if the local participant is not publishing, but if Janus is not used it will not be sent if neither the local participant nor the remote participant are publishing. While it should be possible to not sent the media state in all cases if the local participant is not publishing (because the audio and video will be implicitly disabled in that case) this is not properly handled by the iOS client yet, so for now the media state is still sent in that case. Note that this means that without Janus and when neither the local nor remote participants are publishing the iOS client will show the audio as available. In the previous code this was less problematic, because as the media state was sent to all participants, the media state could be received by a remote participant (through a signaling message) even if neither the remote participant nor the local participant was publishing if the local participant established a connection with a different remote participant that was publishing. This is no longer the case, but is nevertheless something to be fixed in the iOS client (and not a big deal anyway, as limited publishing permissions are unlikely to be used in a setup without Janus). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The attribute stores the display name of the local participant no matter if it is a guest or a regular user. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Similarly to the initial sending of the media state the nick is now sent using the LocalStateBroadcaster subclasses as part of the current state. Like for the media state the new code reduces the messages sent by sending them directly to each participant instead of to all participants, except for data channels using Janus which are still sent to all participants. When Janus is not used the nick is sent only if no connection will be established with the remote participant, as otherwise the nick is sent as part of the offer/answer. Nevertheless, the detection of the peer being set to null does not properly work due to the peer attribute being initialized to "null", but that will be fixed in a follow up commit. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If a null peer is set the CallParticipantModel did not trigger a "change:peer" event, as the peer was originally initialized to null. To work around that now "set:peer" is emitted whenever the peer attribute is set, no matter its value. "peer" (and "screenPeer") attribute(s) should be instead initialized to "undefined", like other unknown attributes, and the standard "change:peer" should be listened to. However, for simplicity and "safety" for the time being "set:peer" is emitted instead as it is needed only for the LocalStateBroadcasterNoMcu and changing the initial value may, even if it should not, cause unexpected issues. Moreover, the semantics of undefined attributes may require further changes, like special handling when removing a screen peer. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
backportbot
bot
added
bug
feature: signaling 📶
nickvergessen
approved these changes
Mar 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of PR #16420