Spreed: Users get kicked out of room on signaling 404

Created on 30 Jul 2019 · 8Comments · Source: nextcloud/spreed

Steps to reproduce

Create a room with a 2 users (you and someone else)
The other user (sometimes) cannot join the room, even after refreshing or logging out
Need to delete the room and create a new one (sometimes more than once) to join

Expected behaviour

When I contact a user, I expect him to be able to join the room without any issues.

Actual behaviour

The other other gets kicked out.
In the JavaScript console, I can see the signaling server responding with a 404, even though the room was just created and clearly visible in NextCloud.
I'm guessing NextCloud sometimes does not alert its internal signaling server of new created rooms.

Might be related to #1342 / #1330.

Browser

Microphone available: yes

Camera available: yes

Operating system: Windows

Browser name: Chrome

Browser version: 75

Browser log

JS Console:

GET https://cloud.my.domain.com/ocs/v2.php/apps/spreed/api/v1/signaling/52utpb5z 404

Network Console response:

{"ocs":{"meta":{"status":"failure","statuscode":404,"message":null},"data":[{"type":"usersInRoom","data":[]}]}}

Spreed app

Spreed app version: 5.0.4

Custom TURN server configured: yes (Coturn 4.5.1.1)

Custom STUN server configured: yes (Coturn 4.5.1.1)

Server configuration

Operating system: Ubuntu (Nextcloud official docker image)

Web server: Apache

Database: PostgreSQL

PHP version: 7.3.7

Nextcloud Version: 15.0.10.0

List of activated apps:

Enabled:
  - accessibility: 1.1.0
  - activity: 2.8.2
  - calendar: 1.6.5
  - cloud_federation_api: 0.1.0
  - comments: 1.5.0
  - contacts: 3.1.3
  - dav: 1.8.2
  - deck: 0.6.5
  - drawio: 0.9.3
  - federatedfilesharing: 1.5.0
  - federation: 1.5.0
  - files: 1.10.0
  - files_markdown: 2.0.6
  - files_pdfviewer: 1.4.0
  - files_sharing: 1.7.0
  - files_texteditor: 2.7.0
  - files_trashbin: 1.5.0
  - files_versions: 1.8.0
  - files_videoplayer: 1.4.0
  - firstrunwizard: 2.4.0
  - gallery: 18.2.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.3.0
  - mail: 0.11.1
  - nextcloud_announcements: 1.4.0
  - notes: 3.0.1
  - notifications: 2.3.0
  - oauth2: 1.3.0
  - password_policy: 1.5.0
  - passwords: 2019.8.0
  - polls: 0.10.2
  - provisioning_api: 1.5.0
  - quota_warning: 1.4.0
  - richdocuments: 3.3.14
  - serverinfo: 1.5.0
  - sharebymail: 1.5.0
  - spreed: 5.0.4
  - support: 1.0.0
  - survey_client: 1.3.0
  - systemtags: 1.5.0
  - theming: 1.6.0
  - twofactor_backupcodes: 1.4.1
  - twofactor_totp: 2.1.2
  - twofactor_u2f: 2.1.3
  - updatenotification: 1.5.0
  - user_ldap: 1.5.0
  - w2g2: 2.2.8
  - workflowengine: 1.5.0
Disabled:
  - admin_audit
  - encryption
  - files_external

Nextcloud configuration:

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpsecure": "tls",
        "mail_smtpauth": true,
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.my.domain.com"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "15.0.10.0",
        "overwrite.cli.url": "cloud.my.domain.com",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "als_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory"
    }
}

Server log (data/nextcloud.log)

bug

Source

madmath03

All 8 comments

Well, there is no "internal signaling" server that needs to be notified. It is just an API endpoint readin ght every same database.

The main question is why you would receive a 404 on the signaling and the only thing I could imagine is that there are general problems with your session (handled by php). Maybe updating to PHP 7.3.8 helps, otherwise I would recomment to try updating to Nextcloud 16 and Talk 6

Another thing to checkl would be to change the type in all the returns of this file:
https://github.com/nextcloud/spreed/blob/6e1e78ec05bf4bce192fbe373a6c6606534bb6d4/lib/Controller/SignalingController.php#L162

so you can see on which line your error is. But this then is more of a support issue than a bug, so I will close this.

nickvergessen on 19 Aug 2019

@nickvergessen I'm using NextCloud official docker image so I cannot really agree with you on the fact that this is a support request and not a bug...

I will try to first update the docker image, then edit the file you mentioned and share results.

madmath03 on 19 Aug 2019

@nickvergessen Updating to PHP 7.3.8 did not help, still have the issue. Updating to NC 16 and Talk 6 is not option for us right now but I will try to setup another environment to compare behavior.

I also edited the file you mentioned. All the errors are returned by this block of code:
https://github.com/nextcloud/spreed/blob/6e1e78ec05bf4bce192fbe373a6c6606534bb6d4/lib/Controller/SignalingController.php#L165-L170

So the manager cannot retrieve the room, even though it is displayed in the web page and throws a RoomNotFoundException and kicking the user out after 3 such errors.

This really looks like a bug when using the internal signaling API! Can you please reopen this issue?

madmath03 on 21 Aug 2019

👍1

Well this could also be caused by session problem. I have this from time to time. Login out and in again solves the issue in this case for me.

nickvergessen on 21 Aug 2019

@nickvergessen I've noticed this as well, but that's still a bug, and that's not even a valid solution for public rooms joined by external users who cannot logout in the first place.

madmath03 on 22 Aug 2019

I can confirm that the error comes from the session management.
When this happens, the session_id in the talk_participants table are all set to 0.

I did not find exactly at which moment the session ID is supposed to be updated, but it's either not called when it should or not given the good parameters.

madmath03 on 22 Aug 2019

I also encounter this bug with Nextcloud docker apache-16.0.4 and spreed 6.0.4 for old chats.
And I guess, #1839 describes the same bug.
This is difficult to test, because as for as I noticed it doesn't fail all the time.
Sometimes the chat messages are loaded partially and then stop loading instead of kicking the participant out.

JLueke on 5 Sep 2019

👍1

same here..

Cloud 18.0.2
talk 8.0.5
official docker image

the instance can barely handle a three person video call on a xenon e5440 with 32 gigs of ram
mostly because of 404 errors while accessing signalling endpoint.