The signaling object keeps a list of the known session IDS in the room
which is updated when participants join or leave the room. However, the
list was not updated when filtering the users that left in the meantime
during a reconnection.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The own peer was created if needed when the list of participants in the
call actually changed. In most cases this worked fine, but sometimes
(for example, with forced reconnections, depending on the timing of the
signaling messages) it could happen that the own peer was stopped and,
once the participant list was updated, the participants were still the
same as before and thus the own peer was not started again.
Now the own peer is started if needed on any "users changed" event; this
should make no difference in the cases in which the own peer was not
needed or it was already active, but it should fix the corner cases in
which it was needed but the participant list changed without the
participants actually changing.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The own peer and, therefore, the peer in LocalCallParticipanModel could
be null in some cases even if an own peer is needed to send media to the
HPB. This should be just a transient situation, although it could happen
too by bugs in the code.
Due to this the call view should show the local participant as "not
connected" not only when the own peer is null, but also if the own peer
is null and an own peer would be nevertheless needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"iceConnectionStateChanged" is not emitted when on transitions to the
"closed" state, as events are not emitted on user initiated actions.
Therefore, the own peer needs to be explicitly removed from the
LocalCallParticipanModel when ended.
In most cases this was already done, but sometimes the own peer could be
ended like a remote peer in the "disconnectedSessionIds" loop in
"usersChanged" (for example, after a forced reconnection, depending on
the timing of the signaling messages). When that happened the peer was
not removed from LocalCallParticipanModel, so it was still treated as it
was connected even if the connection was already closed (so, for
example, the analyzer still tried to get the stats and Firefox printed
"RTCPeerConnection is gone (did you enter Offline mode?)" on each try).
Due to this now "peerEnded" is emitted by the Peer object and the own
peer is removed from LocalCallParticipanModel by handling that event.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When an own peer is needed offers are periodically sent until the
connection is established. However, if the current session ID changed
(which would happen after a forced reconnection) the previous session
ID is no longer relevant, so the offers with the old ID should not be
sent anymore (the process to send offers with the new ID will be started
when needed).
Moreover, the previous process must be stopped as well to prevent
creating new Peer objects with the old ID, which would cause them to be
added to the CallParticipantCollection (as the ID does not match with
the current session ID, so it is seen as a peer for another participant)
and thus appear in the call view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The display name is not set for unnamed guests, so the computed name
(which is the one shown in the participant list) should be used instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The readme previously pointed to the commercial SimpleWebRTC product,
that has little in common with the deprecated open source library.
Signed-off-by: Andrea Pappacoda <andrea@pappacoda.it>
marco
Nextcloud bot
Joas Schilling
Daniel Calviño Sánchez
Joas Schilling
dependabot[bot]
Andrea Pappacoda