Problems with voice and video calls!

[ReaneZ]

Steps to reproduce

1. Open the Nextcloud Talk app on an Android device (e.g., Xiaomi Redmi Note 12 Pro 5G).
2. Initiate an audio or video call.
3. Wait for the call to connect.

Expected behaviour

The call should connect successfully and the connection should be stable. For context, the exact same setup works perfectly fine when making calls from Windows, Linux, and iOS devices.

Actual behaviour

The call either completely fails to connect or connects with extremely poor video/audio quality. This issue appears to be strictly limited to the Android operating system.

Talk app

Talk app version: Latest
Custom Signaling server configured: yes
Custom TURN server configured: yes
Custom STUN server configured: yes

Client Device

Device model: Xiaomi Redmi Note 12 Pro 5G
Operating system: Android
Microphone available: yes
Camera available: yes
Battery optimization: Disabled (unrestricted priority set for the app)
Browser name/version: N/A (Using the native Android app)

Server configuration

Operating system: Debian 12
Web server: Nginx
Database: (Not specified)
PHP version: 8.2
Nextcloud Version: Latest

Additional Context / Feature Request

Since it is difficult to troubleshoot this without logs, it would be extremely helpful if a feature could be added to the Talk app allowing users to view and export application logs directly from the app's interface.

[alauzon]

This looks like the client-side bug #6169.

In High-Performance Backend (external signaling) mode, the Talk Android client elects the WebRTC offerer by lexicographically comparing the local and remote session IDs. But the remote ID it receives is a signaling-layer session ID, while the local ID it compares against is the Nextcloud session ID — two different namespaces. The comparison is then meaningless, and both peers can compute the same role: both "not offerer" → nobody creates the offer → the call never connects. Because the session IDs are effectively random per call, the failure is intermittent, and it is Android-only — web, desktop and iOS elect the offerer differently. That matches your report exactly ("strictly limited to Android", "works perfectly fine from Windows, Linux, and iOS", custom signaling server configured).

A fix is proposed in #6375 — it passes the local signaling session so both peers compare IDs from the same namespace. On a test instance with the same HPB-without-MCU setup, automated 2‑party Android calls went from ~1/3 connecting to consistently connecting. If you can build that branch, it should resolve the "fails to connect" cases.

One caveat: the "connects with extremely poor video/audio quality" symptom you also mention is most likely a separate issue (TURN relay / bandwidth), not this offerer deadlock — nextcloud/spreed#6375 would not address that part.

[mahibi]

Thank for reporting @ReaneZ and for the detailed analysis @alauzon 👍
I plan to have a close took very soon!