nextcloud
"Allow adding participants to one-to-one calls creating a new conversation" feature not working properly
How to use GitHub
- Please use the đź‘Ť reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Steps to reproduce
- Start a one-to-one audio/video call between two users.
- Click the "Add participants to this call" button during the call.
- Select a third user to join the conversation.
Expected behaviour
A new group conversation should start seamlessly with all participants connected in a single call, without disconnecting the original call or requiring any restart.
Actual behaviour
The ongoing one-to-one call is immediately dropped and replaced with a "connecting" status. The invited user sees a "waiting" message but is not connected to the call. In some cases, the desktop app becomes unresponsive and must be restarted to work again.
Diagnosis and logs
Diagnosis report
Server: OS: Debian 12 Nextcloud Server: 31.0.5 (self-hosted) Talk (spreed) app: 21.1.0 HPB: Commercial from Struktur AG
Client: OS: Windows 10 / Windows 11, macOS Nextcloud Talk Desktop: 1.2.3
Client logs
No logs on client and server side- 🪟 Windows:
- 🍎 macOS:
Hi!
A new group conversation should start seamlessly with all participants connected in a single call, without disconnecting the original call or requiring any restart.
Would be nice, but we can not implement it. It requires everyone to move to new room, connect with new signaling session and join new call.
The ongoing one-to-one call is immediately dropped and replaced with a "connecting" status.
So second participant is not connected, although was present in original call?
The invited user sees a "waiting" message but is not connected to the call.
Who do you mean here by invited, second or third person?
In some cases, the desktop app becomes unresponsive and must be restarted to work again.
Can you reproduce it in Web as well?
Hi,
A new group conversation should start seamlessly with all participants connected in a single call, without disconnecting the original call or requiring any restart.
Would be nice, but we can not implement it. It requires everyone to move to new room, connect with new signaling session and join new call.
Ok, than moving to a new room is expected behavior. I'm fine with this. However, the issue is that the new audio/video call does not get established after the transition. All participants remain stuck in a "waiting" state, and the call never connects. In some cases, the desktop app even requires a full restart. I’d also like to clarify that group calls work perfectly fine in my setup. When I initiate a group call directly (e.g., by calling all participants at once), the audio/video conference works without any issues. So the problem seems to be specifically related to the transition from a one-to-one call to a group call using the "Add participants to this call" feature.
The ongoing one-to-one call is immediately dropped and replaced with a "connecting" status.
So second participant is not connected, although was present in original call?
Apologies for not describing the issue clearly earlier.
Yes, each additional participant is correctly added to the new room — so the transition to the group conversation itself works as expected. The problem occurs only with re-establishing audio/video connection.
The invited user sees a "waiting" message but is not connected to the call.
Who do you mean here by invited, second or third person?
To clarify further: all users — both the original participants and the newly invited one — experience the same problem after the transition to the new room. The audio/video connection does not establish for anyone. Everyone remains stuck in the “waiting” state, and the call never starts. Additionally sometimes the “End Call” button becomes unresponsive for some users so they are forced to completely close and restart the desktop app to recover.
In some cases, the desktop app becomes unresponsive and must be restarted to work again.
Can you reproduce it in Web as well? I will try to reproduce it ASAP and will get back to you.
Please try with Devtools -> Network tab (and console) open. Maybe we'll see some failing requests there
Please try with Devtools -> Network tab (and console) open. Maybe we'll see some failing requests there
I won’t be able to test this today, so the earliest I can respond is Monday. At this point, I can only confirm that the same issue is reproducible in the web app.
Would be nice, but we can not implement it. It requires everyone to move to new room, connect with new signaling session and join new call.
I have yet to test it, but this sounds counterintuitive to me. I understand that it is automatic, I would expect that i am already in a room with the other person, and the third person then joins the room
The process should be more or less seamless already. It should be like this:
- Initiate "Add participant to 1:1"
- A new group conversation is created with all participants (*)
- All participants in the current call are moved to the new group conversation, while still being in a call. At this point audio/video should still work
- All participants that were not part of the 1:1 will receive a call notification
It looks like this:
https://github.com/user-attachments/assets/7e6a307b-a513-4840-b060-54befdd9f92d
(*) I can see that creating a new conversation might sound weird in the first place, but it makes sense, since it correctly retains all information, e.g. chat messages.
BTW the logic behind the 'switch-to-new-room' feature is the same as breakout rooms already have for 2 years. Please check it also fail there, @ayetee-re
The process should be more or less seamless already. It should be like this:
- Initiate "Add participant to 1:1"
- A new group conversation is created with all participants (*)
- All participants in the current call are moved to the new group conversation, while still being in a call. At this point audio/video should still work
- All participants that were not part of the 1:1 will receive a call notification
It looks like this:
Bildschirmaufnahme.2025-06-13.um.20.00.29.mov (*) I can see that creating a new conversation might sound weird in the first place, but it makes sense, since it correctly retains all information, e.g. chat messages.
I see this one works for you, could you please tell me if you are using HPB? I'm just wondering if there is any chance the one I've bought from Struktur AG doesn't work properly with this feature.
I see this one works for you, could you please tell me if you are using HPB?
Yes, this is all with the HPB. Even not the latest version on my end. As @Antreesy mentioned, it’s the same feature as with breakout rooms. Does this work for you?
I'm just wondering if there is any chance the one I've bought from Struktur AG doesn't work properly with this feature.
I don’t think so, as mentioned, it’s using an „old“ feature and the code base for the HPB is the same.
Please check the console when reproducing the issue and check if there’s anything logged there.
BTW the logic behind the 'switch-to-new-room' feature is the same as breakout rooms already have for 2 years. Please check it also fail there, @ayetee-re
Adding participants once group call is created and started works fine, problem only occurs with one-to-one calls.
BTW the logic behind the 'switch-to-new-room' feature is the same as breakout rooms already have for 2 years. Please check it also fail there, @ayetee-re
Adding participants once group call is created and started works fine, problem only occurs with one-to-one calls.
Now one thing catches my eye, why does it say "Has started quiet call"?
Please check the console tab of the dev tools. And also check if anything is logged at the nextcloud.log
Please check the console tab of the dev tools. And also check if anything is logged at the nextcloud.log
I dont' see anything in nextcloud.log related to this issue.
An error occurred processing the signaling message, please ask your server administrator to check the log file
Is it possible to expand that error in the console to show more information?
An error occurred processing the signaling message, please ask your server administrator to check the log file
Is it possible to expand that error in the console to show more information?
Do you mean this?
Ah processing_failed. That indeed seems to be something that needs to be checked in the HPB logs. I assume you don’t have direct access to these, right?
Ah
processing_failed. That indeed seems to be something that needs to be checked in the HPB logs. I assume you don’t have direct access to these, right?
Nope, Struktur AG has them. Should I open a ticket with their support?
I think it makes sense at this point. Please add a link to this thread and also include the logs of the console.
I think it makes sense at this point. Please add a link to this thread and also include the logs of the console.
Done. I'll let you know when I get more information from them
@nickvergessen I can reproduce this on our Nextcloud instance running Talk 21.1.1 and using the HPB service (signaling server 2.0.3).
How to reproduce:
- Have a 1-1 call with somebody.
- Add a third user (doesn't matter who adds it).
- One of the 1-1 users automatically joins the new room and starts to publish again.
- The other 1-1 user leaves the old room and joins the new one on the signaling server but gets a
404 Not FoundfromPUT /ocs/v2.php/apps/spreed/api/v4/call/<token>. He sees the spinner and "Waiting for others to join". - When the third user joins the call, he can see the first user.
- The failed user can join properly by reloading the page.
Maybe there is some timing issue / race condition if the second user joins the new room too fast / slow so the 404 is returned?
Happy to add some debugging to our instance to help tracking this down.
Frontend should be here: https://github.com/nextcloud/spreed/blob/main/src%2FApp.vue#L284
Although it does wait for conversation to be joined. False trigger?
Did some first debugging, problem seems to be caused by the route change to the new room that triggers leaveConversation:
https://github.com/nextcloud/spreed/blob/e9ba2b7697fb581b5ab93e883bd41074f006aff8/src/components/LeftSidebar/LeftSidebar.vue#L941
This ends up here: https://github.com/nextcloud/spreed/blob/e9ba2b7697fb581b5ab93e883bd41074f006aff8/src/utils/signaling.js#L1298
However the session has already joined the new room, so the new room is left immediately.
I tried this patch, which fixes the leaving - however now the own stream is not published in the new room:
diff --git a/src/utils/signaling.js b/src/utils/signaling.js
index 4ef636fee..2d6924e96 100644
--- a/src/utils/signaling.js
+++ b/src/utils/signaling.js
@@ -1292,6 +1292,11 @@ Signaling.Standalone.prototype.joinResponseReceived = function(data, token) {
}
Signaling.Standalone.prototype._doLeaveRoom = function(token) {
+ if (token !== this.signalingRoomJoined) {
+ console.debug('Not in room, not leaving', token, this.signalingRoomJoined)
+ return
+ }
+
console.debug('Leave room', token)
this.doSend({
type: 'room',
Still investaging further but adding in case you have some ideas what else to change.
Also even though the stream is not published, the camera and microphone are still active (the light of my camera is on).
To reproduce locally, add a sleep(1); before returning from leaveCall in CallController.php:
https://github.com/nextcloud/spreed/blob/e9ba2b7697fb581b5ab93e883bd41074f006aff8/lib/Controller/CallController.php#L540