For a given message id $lastReadMessage we cache the number of messages
that exist past that message, which happen to also be the number of
unread messages, because this is expensive to query per room and user repeatedly
Signed-off-by: Joas Schilling <coding@schilljs.com>
This will allow the clients to react to "publishingPermissions" changes
directly from the signaling messages, without needing to fetch again the
participants (although they may need to fetch them again nevertheless
for UI updates).
The internal signaling server also needs to listen to changes on the
property to be able to know when to send the message (the external
signaling server already listened to the changes to be able to update
the permission flags internally).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant does not have publishing permissions the HPB will
block signaling messages related to establishing a connection, like
sending the candidates. This would prevent participants using clients
not supporting yet the publishing permissions (and thus still trying to
publish even if they are not allowed to) from sending media in a call.
Unfortunately the lack of permissions only prevents the connection from
being established. If a participant is already sending media revoking
the publishing permissions will not cause the connection to be stopped
by the HPB.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The call flags are updated when joining and leaving a call. However,
during a call the audio and video devices can be disabled without
needing a reconnection, so an endpoint to just update the call flags is
also needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "stunservers" parameter was a list of several elements each one with
a "url" parameter, which was a string. Now the "stunservers" parameter
is a list of several elements (although in practice there will be just
one) each one with a "urls" parameter, which is a list of strings.
The "turnservers" parameter was a list of several elements each one with
a "url" parameter and a "urls" parameter, which were both a list of a
single string. Now the "turnservers" parameter is a list of several
elements each one with a "urls" parameter, which is a list of strings.
Each element of "turnservers" contain too "username" and "credential"
parameters that apply to all the elements in the "urls" parameter.
The format resembles the RTCIceServer format, so the returned values can
be directly used by the WebUI like done until now. Mobile clients will
need to be adjusted, though.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
- Provide multiple STUN servers to webrtc client when specified in
nextcloud backend instead of just 1 random one
Signed-off-by: Sebastian L <sl@momou.ch>
Gary Kim
Joas Schilling
Daniel Calviño Sánchez
Joas Schilling
Sebastian L