[stable20.1] Stop sending the nick through data channels after some time #4726

"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>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[stable20.1] Stop sending the nick through data channels after some time #4726

[stable20.1] Stop sending the nick through data channels after some time #4726

Commits on Dec 9, 2020