| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
This is needed to prevent issues with the request body size:
POST https:\/\/192.168.178.101:18443\/api\/v1\/room\/3097975620`
resulted in a `413 Request Entity Too Large` response:\nRequest entity
too large
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Vitor Mattos <vitor@php.rio>
|
|
When the local participant joins a call the sent media is based on the
last fetched permissions. However, once the call is joined the sent
media is based on the participant permissions updates notified by the
signaling messages.
When the HPB is used the "participantPermissions" property of the
"participants->update" signaling messages is used. Those messages are
sent when the permissions are modified and also when a participant joins
a call, but in this last case it did not include the expected property.
Due to this, if the permissions of the local participant were updated
right before the participant joined the call and the participant data
was not fetched again yet the previous permissions would be used. If the
message sent when the permissions were updated was received before
actually joining the call then it would be ignored, and although the
message sent due to joining the call would be processed the WebUI would
not notice the permission change, as the message did not provide them.
To solve that now the "participants->update" message sent when joining a
call also includes the permissions. This way, even if the previous
permissions are initially used when joining the call as soon as the
signaling message sent due to joining the call is received the WebUI
will adjust the sent media to the new permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
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>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
When the internal signaling server is used the Nextcloud session id and
the signaling session id are the same. However, if the external
signaling server is used they are different.
Signaling messages for participants in calls (like joining the call,
muting and so on) are identified only by their signaling session id, so
when the external signaling server is used it was not possible to
associate participants in calls with the participant information
provided by the Nextcloud server.
However, when a participant joins a call her client notifies the
Nextcloud server (either directly or, in the case of SIP clients,
through the signaling server). The Nextcloud server then notifies the
signaling server which, in turn, notifies all the clients. When
Nextcloud notifies the signaling server the participant is identified
with the Nextcloud session id, and the signaling server then replaces
that with the signaling session id before relaying the message to the
clients.
Due to this when a participant joins (or leaves) a call now the
Nextcloud session id is sent too in an extra property. This property is
not adjusted by the external signaling server, so the clients receive
both the signaling session id and the Nextcloud session id and thus are
able to map them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
So we can use it to decide which HPB to talk to
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
In order to filter control messages the external signaling server needs
to know the permissions of each participant. Those permissions need to
be set when the participant joins the room or if the participant type is
changed.
All participants should have permissions to publish media and screen,
but only logged in moderators should have permission to send control
messages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Also dispatch an event so other apps can extend the properties to return.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
The flags encode if a user is in the call and whether he is publishing
audio and/or video.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
This removes the long-polling against the PHP backend and instead sends an
event to all users in a room through the standalone signaling server to
notify that new chat messages exist.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
|
Signed-off-by: Joachim Bauch <bauch@struktur.de>
|
