| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: marco <marcoambrosini@pm.me>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
When an offer is requested to the HPB the old connection is stopped and
a new one is created. If the HPB has support for updating the
subscribers this is now used instead when negotiation is needed, as this
prevents the existing connection (and thus the media) to be interrupted
during the renegotiation.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
nextcloud/fix-forced-reconnections-when-the-hpb-is-not-used
Fix forced reconnections when the HPB is not used
|
|
When the HPB is not used forcing a reconnection causes the call to be
left and then joined again. Although it was waited for the call to be
left first before joining again in some cases it could happen that,
after sending the join request but before receiving its response, the
"usersInRoom" event was received. In that case the call flags for the
participant will be "disconnected" (as at this point it is actually
disconnected), but as the join request was already sent it is seen as "a
moderator ended the call", and thus the call is left again. To prevent
that now it is explicitly waited for the "disconnected" flags to be
received and, then, the call is joined again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
When the HPB is not used forced reconnections just leave and then join
the call again. However, it was not waited for the call to be left first
before joining it again, so it could happen that the join request ended
being processed first and thus once the leave request was processed the
participant did not join again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
.substr() is deprecated so we replace it with .slice() which works similarily but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
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>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Currently whether the local user is in the call or not from the point of
view of the Nextcloud server is mostly ignored; the UI is based only on
whether the user explicitly joined or left the call. The reason is that
after the user joined the response from a previous request to get the
room information done when the user had not joined yet could be
received, so honouring that could make the UI jump between "in the call"
and "not in the call" (as it happened in older versions).
However, in the WebRTC related code whether the local user is in the
call or not is only based on the user events sent by the signaling
server, so in that case the state is always up to date.
Due to this, it is possible to detect whether the local user was kicked
out from the call by a moderator (for example, because the call was
ended for everyone) by comparing the local state ("localUserInCall",
which is updated when locally joining and leaving a call) with the
remote state provided by the signaling server.
Note that there is no rollback of "localUserInCall" if the join or leave
call request fails; the error is currently ignored by other parts of the
code, so handling it here does not provide any benefit.
An alternative approach would have been to ignore the "in call" state
provided by the server while a "join call" request is on-going, so the
local state and the server state would match except when the user was
kicked out from the call. This would have required deeper changes, so
even if it could be a better approach in the end for now the simpler
(but less clean) approach was used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Vincent Petry <vincent@nextcloud.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: Marco Ambrosini <marcoambrosini@pm.me>
|
|
Signed-off-by: Marco Ambrosini <marcoambrosini@pm.me>
|
|
When a media device is disabled during a call its track is replaced with
a null track in the peers, and if a media device is reenabled the null
track is replaced with the new track. In both cases neither a
renegotiation nor a reconnection is needed. Therefore the call flags
have to be explicitly updated.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The current call flags were not given in forced reconnections with the
internal signaling server, so the server used the default flags (audio
and video).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The mobile apps will need to adjust to the new version (note that only
the signaling settings endpoint actually changed), but they will not be
compatible with Talk < 12 anyway due to the changes in the conversation
endpoints.
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>
|
|
👥 Multiple sessions 👥
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Several errors in a row in the hello response usually point to a
misconfigured signaling server that can not connect to the Nextcloud
server. The error message now also takes into account the number of
hello response errors in a row and hints at a possible misconfiguration.
As this is a very specific issue the UI does not show any other detail
regarding the received error, and the message is not reverted to the
generic one if the websocket connection fails after the hello response
failed; it is just a hint to make an admin look at the browser console
or the signaling server logs.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Until now an error notification was shown if the connection of the
websocket to the external signaling server failed. However, if the
websocket connection succeeded but then there was an error when actually
connecting to the signaling server at an application level (the hello
message response was an error) no error notification was shown in the
UI. Now the error notification is also shown in that case, and it will
not be removed (no matter if originally it happened due to an error in
the websocket or in the connection) until the connection has succeeded.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
When the current conversation was deleted while in a call, or
whenever someone has been removed from a room, the redirect
now targets the not-found page instead of the one about duplicate
session.
Signed-off-by: Vincent Petry <vincent@nextcloud.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 a reconnection is forced and the standalone signaling server is
used the participant joins again the conversation to get a new session,
and then the websocket to the standalone signaling server is closed,
which causes the reconnection with the signaling server. However, when
the participant is a guest and joins again the previous session gets a
"disinvite" message, which causes the browser to be redirected to the
main Talk page.
Due to this, now the "disinvite" message will be ignored when a forced
reconnection is started until the socket has reconnected. It seems that
the "disinvite" message will always be delivered before the request to
rejoin a conversation returns, so the flag could be disabled as soon as
the request returned instead of when the socket is connected. However,
disabling it once the socket has connected again is also logical and
seems more future proof.
In any case, as the "disinvite" message is ignored that means that if a
participant is actually kicked out from the conversation while
performing a forced reconnection the browser will not be aware of it and
a wrong UI would be shown. However, the chance of that happening is
quite low.
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>
|
|
404: now redirects to /not-found
*: now retries after 10 seconds and shows an error
and give up after 5 minutes recommending a reload
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>
|
|
"Signaling.Standalone.joinCall" should return a promise, like done for
"Signaling.Base.joinCall".
The standalone signaling object is able to defer joining a call if
called before its room has been joined. However, it only takes into
account the last room that a call was tried to be joined in. This is
still the case now when the promise is returned; if "joinCall" is called
on a different room while a previous was pending the previous one is
just rejected (although if it is in the same room the previous promise
is reused).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
When the current user joins or leaves a call there is no need to fetch
all the conversations, but just the current conversation and the
participants. As when any user, including the current one, joins or
leaves a call a room participants update event is sent by the external
signaling server the current conversation and the participants are
already gotten, so it is not needed to add an explicit handling for
that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The room participants update events are sent by the external signaling
server:
-When a user resumes the session
-When an internal client joins or leaves the conversation
-When the BackendNotifier sends a "participants" event (that is, when
the type of a participant changes, when the name of a guest changes or
when guests are cleaned)
-When the BackendNotifier sends a "incall" event (that is, when a
participant joins or leaves the call)
In all those cases it is not really needed to fetch all the
conversations to get the updated state, but only the current
conversation. Note that it is not enough to fetch just the participants,
as for example when a call is started that modifies some attributes in
the conversation, like "hasCall".
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: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
