Improve log message in case of disinvite #512
Comments
mahibi
added a commit
to nextcloud/talk-android
that referenced
this issue
Jul 12, 2023
… on HPB Everytime a second attempt was made to enter a call, the connection failed. How to reproduce: - Enter the ChatActivity -> joins the room (so the new session is in the ApplicationWideCurrentRoomHolder) - Start call -> in the CallActivity we don't join again and instead execute callOrJoinRoomViaWebSocket() - Call connection is successful - Hangup on android -> the ApplicationWideCurrentRoomHolder gets cleared (so also it's session) - Staying in the chat and start the call another time -> When we open CallActivity another time, ApplicationWideCurrentRoomHolder.sessionId is empty.Because of this, in joinRoomAndCall, joinRoom is executed again. But as we are still in the room and have a session, joinRoom is problematic because on serverside in SignalingController - if there is still a session - it's considered as old. So Nextcloud now sends a backend message (disinvite) to the external signaling controller that the session (of the first join) was removed. So the External signaling server removes the session and closes the websocket. (The message for this might be improved, see strukturag/nextcloud-spreed-signaling#512) As the websocket is now closed, it won't be possible for the android app to send any signaling message anymore. There will just be the connecting screen and the call connection fails. Solution for now: ApplicationWideCurrentRoomHolder.getInstance().clear() should not be executed when hanging up, so the session won't be cleared and in the next attempt to start the call the room is not joined again mistakenly. Instead to clear the `ApplicationWideCurrentRoomHolder`, only setInCall(false); setDialing(false); are set so that the method isNotInCall() in ChatActivity remains working correctly. Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
9 tasks
mahibi
added a commit
to nextcloud/talk-android
that referenced
this issue
Jul 12, 2023
… on HPB Everytime a second attempt was made to enter a call, the connection failed. How to reproduce: - Enter the ChatActivity -> joins the room (so the new session is in the ApplicationWideCurrentRoomHolder) - Start call -> in the CallActivity we don't join again and instead execute callOrJoinRoomViaWebSocket() - Call connection is successful - Hangup on android -> the ApplicationWideCurrentRoomHolder gets cleared (so also it's session) - Staying in the chat and start the call another time -> When we open CallActivity another time, ApplicationWideCurrentRoomHolder.sessionId is empty.Because of this, in joinRoomAndCall, joinRoom is executed again. But as we are still in the room and have a session, joinRoom is problematic because on serverside in SignalingController - if there is still a session - it's considered as old. So Nextcloud now sends a backend message (disinvite) to the external signaling controller that the session (of the first join) was removed. So the External signaling server removes the session and closes the websocket. (The message for this might be improved, see strukturag/nextcloud-spreed-signaling#512) As the websocket is now closed, it won't be possible for the android app to send any signaling message anymore. There will just be the connecting screen and the call connection fails. Solution for now: ApplicationWideCurrentRoomHolder.getInstance().clear() should not be executed when hanging up, so the session won't be cleared and in the next attempt to start the call the room is not joined again mistakenly. Instead to clear the `ApplicationWideCurrentRoomHolder`, only setInCall(false); setDialing(false); are set so that the method isNotInCall() in ChatActivity remains working correctly. Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
backportbot-nextcloud bot
pushed a commit
to nextcloud/talk-android
that referenced
this issue
Jul 12, 2023
… on HPB Everytime a second attempt was made to enter a call, the connection failed. How to reproduce: - Enter the ChatActivity -> joins the room (so the new session is in the ApplicationWideCurrentRoomHolder) - Start call -> in the CallActivity we don't join again and instead execute callOrJoinRoomViaWebSocket() - Call connection is successful - Hangup on android -> the ApplicationWideCurrentRoomHolder gets cleared (so also it's session) - Staying in the chat and start the call another time -> When we open CallActivity another time, ApplicationWideCurrentRoomHolder.sessionId is empty.Because of this, in joinRoomAndCall, joinRoom is executed again. But as we are still in the room and have a session, joinRoom is problematic because on serverside in SignalingController - if there is still a session - it's considered as old. So Nextcloud now sends a backend message (disinvite) to the external signaling controller that the session (of the first join) was removed. So the External signaling server removes the session and closes the websocket. (The message for this might be improved, see strukturag/nextcloud-spreed-signaling#512) As the websocket is now closed, it won't be possible for the android app to send any signaling message anymore. There will just be the connecting screen and the call connection fails. Solution for now: ApplicationWideCurrentRoomHolder.getInstance().clear() should not be executed when hanging up, so the session won't be cleared and in the next attempt to start the call the room is not joined again mistakenly. Instead to clear the `ApplicationWideCurrentRoomHolder`, only setInCall(false); setDialing(false); are set so that the method isNotInCall() in ChatActivity remains working correctly. Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
mahibi
added a commit
to nextcloud/talk-android
that referenced
this issue
Jul 12, 2023
… on HPB Everytime a second attempt was made to enter a call, the connection failed. How to reproduce: - Enter the ChatActivity -> joins the room (so the new session is in the ApplicationWideCurrentRoomHolder) - Start call -> in the CallActivity we don't join again and instead execute callOrJoinRoomViaWebSocket() - Call connection is successful - Hangup on android -> the ApplicationWideCurrentRoomHolder gets cleared (so also it's session) - Staying in the chat and start the call another time -> When we open CallActivity another time, ApplicationWideCurrentRoomHolder.sessionId is empty.Because of this, in joinRoomAndCall, joinRoom is executed again. But as we are still in the room and have a session, joinRoom is problematic because on serverside in SignalingController - if there is still a session - it's considered as old. So Nextcloud now sends a backend message (disinvite) to the external signaling controller that the session (of the first join) was removed. So the External signaling server removes the session and closes the websocket. (The message for this might be improved, see strukturag/nextcloud-spreed-signaling#512) As the websocket is now closed, it won't be possible for the android app to send any signaling message anymore. There will just be the connecting screen and the call connection fails. Solution for now: ApplicationWideCurrentRoomHolder.getInstance().clear() should not be executed when hanging up, so the session won't be cleared and in the next attempt to start the call the room is not joined again mistakenly. Instead to clear the `ApplicationWideCurrentRoomHolder`, only setInCall(false); setDialing(false); are set so that the method isNotInCall() in ChatActivity remains working correctly. Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the following scenario:
disinvite) to the external signaling controller that the session (of the first join) was removedThe logs shown in this case are like this:
Not sure why the first one happens really, but wouldn't it be possible to log something different in case we close the websocket connection because of the received
disinvite? Something like "Received disinvite for session ... closing web socket".The text was updated successfully, but these errors were encountered: