-
Notifications
You must be signed in to change notification settings - Fork 452
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
[stable20.1] Stop sending the nick through data channels after some time #4726
Merged
Conversation
This file contains 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
"startSendingNick" is only used when the HPB is used, and only with the own peer, so there is no need to provide the peer as a parameter. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the current participant is a guest the nick was always sent when another participant was connected. However, the nick is sent already (without HPB in the offer/answer, with HPB it is periodically sent), so there is no need to do it again. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of sending "nickChanged" data channel messages from different places now an internal "nickChanged" event with the name is emitted, and its handler takes care of sending the data channel message as needed. This also fixes trying to send data channel messages to receiving only peers when the nick is changed and the HPB is used. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The function will be used to send both the media state and the nick, so its name is adjusted accordingly. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Since the introduction of the HPB the nick has been sent over and over again every second, as it is not possible to know when other participants have established a data channel connection. However, it is possible to know when other participants join the call, and it is safe to assume that the other participant established a connection with the local one after a "reasonable" amount of time. As sending the nick every second is too aggressive (specially in calls with a lot of users) now the nick is sent when the local participant establishes a connection with the remote one and, as that does not guarantee that the remote one has established a connection with the local one, the nick is sent again several times (with an increasing interval) in the next 30 seconds. If a connection is established with another participant in the meantime the cycle starts again. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "userId" property was used only in CallParticipantModel, but as it is also set from the participant information provided by the signaling in most cases it is not needed. The only case in which it would be needed is if the Peer object is created and connected before the participant is found in the participant information provided by the signaling. However even in that rare case showing a user as a guest would happen very briefly and it will correct itself as soon as the signaling sends the participant information. Due to this, and as it will simplify also a "nickChanged" signaling message to be introduced later, the "userId" property is now ignored. Note that this only affects the internal "nick" event; the "userId" property still needs to be sent in the "nickChanged" data channel message as it is used by the Android app. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the HPB is used, if the local participant does not send audio nor video there is no Peer for the local participant, so it is not possible to send data channel messages (although they can be received if the other participant sends audio or video and thus has a Peer object). When the HPB is not used, if both the local participant and the remote one do not send audio nor video there is no Peer for their connection, so it is not possible to send or received data channel messages between those participants. The nick was only sent through data channel messages, so in the above cases the nick was not initially shown and neither updated if it was changed later. Now a "nickChanged" signaling message is introduced to ensure that the nick is transmitted even if there is no Peer for a participant. Even if the mobile apps do not currently handle the "nickChanged" event they will just ignore it without breaking havoc. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the HPB is not used the initial nick is sent along the offer and answer. However if there is no Peer between two participants there will be no offer/answer, so the nick needs to be explicitly sent in that case. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #4182