Skip to content
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] Stop sending the nick through data channels after some time #4649

Merged
merged 9 commits into from
Dec 9, 2020

Conversation

backportbot-nextcloud[bot]
Copy link

backport of #4182

"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>
Copy link
Member

@danxuliu danxuliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and works 👍

@nickvergessen
Copy link
Member

So not sure if it related, but for me guests showed their sha1 for quite some time now in calls on sermo. only once they set a name it showed that.
But couldn't reproduce when retesting just now

@nickvergessen nickvergessen merged commit f5761db into stable20 Dec 9, 2020
@nickvergessen nickvergessen deleted the backport/4182/stable20 branch December 9, 2020 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants