connect to signaling service after refresh web page
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 2.2k
- Forks
- 586
- Avg merge
- 18h 27m
- Merged PRs (30d)
- 333
Description
[!TIP]
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
- upgrade NC from 31 to 32
- install Talk HPB AIO standalone on dedicated host (DNS records are correct)
- remove old High-performance backend setting and replace with the new ones and sure "OK" in all checks
Expected behaviour
we expect no changes at least
Actual behaviour
sometimes one or/and several users cannot connect to existing conversation. if they refresh the webpage, the Talk app will connect instantly.
This odd occurs randomly without any connection to session lifetime or Talk chat room.
Talk app
Talk app version: 22.0.9
Custom Signaling server configured: yes, running docker cont
Custom TURN server configured: yes
Custom STUN server configured: yes
Browser
Microphone available: yes
Camera available: yes
Operating system: Windows10/11 Ubuntu 24.04 LTS, Debian12
Browser name: Firefox Chrome Edge...
Browser version: various. has no affect
Browser log
cause odd rare and random occurs we unable collect log, but some users reports long time connect to spreed (ocs/v2.php/apps/spreed/api/v3/signaling/backend), that able to see in network panel in developers tool.
Server configuration
Operating system: Ubuntu 24.04 LTS minimal
Web server: Apache2
Database: MySQL
PHP version: 8.3
Nextcloud Version: Nextcloud Hub 25 Autumn 32.0.6
nextcloud_occ app:list
Enabled:
- activity: 5.0.0
- admin_audit: 1.22.0
- app_api: 32.0.0
- auto_groups: 1.6.2
- autocurrency: 1.6.8
- bruteforcesettings: 5.0.0
- calendar: 6.2.0
- circles: 32.0.0
- cloud_federation_api: 1.16.0
- comments: 1.22.0
- contacts: 8.3.2
- contactsinteraction: 1.13.1
- dashboard: 7.12.0
- dav: 1.34.2
- deck: 1.16.3
- drawio: 3.1.2
- federatedfilesharing: 1.22.0
- federation: 1.22.0
- files: 2.4.0
- files_3dmodelviewer: 0.0.16
- files_accesscontrol: 3.0.2
- files_downloadlimit: 5.0.0-dev.0
- files_external: 1.24.1
- files_fulltextsearch: 32.0.2
- files_pdfviewer: 5.0.0
- files_reminders: 1.5.0
- files_sharing: 1.24.1
- files_trashbin: 1.22.0
- files_versions: 1.25.0
- firstrunwizard: 5.0.0
- forms: 5.2.4
- groupfolders: 20.1.10
- integration_nuiteq: 1.1.1
- ldap_contacts_backend: 1.12.0
- logreader: 5.0.0
- lookup_server_connector: 1.20.0
- nextcloud_announcements: 4.0.0
- notes: 4.13.0
- notifications: 5.0.0
- notify_push: 1.3.0
- oauth2: 1.20.0
- onlyoffice: 9.12.0
- password_policy: 4.0.0
- photos: 5.0.0
- polls: 8.6.3
- privacy: 4.0.0
- profile: 1.1.0
- provisioning_api: 1.22.0
- recommendations: 5.0.0
- related_resources: 3.0.0
- secrets: 2.1.6
- serverinfo: 4.0.0
- settings: 1.15.1
- sharebymail: 1.22.0
- side_menu: 5.1.3
- spreed: 22.0.9
- support: 4.0.0
- survey_client: 4.0.0
- systemtags: 1.22.0
- tasks: 0.17.1
- text: 6.0.1
- theming: 2.7.0
- twofactor_backupcodes: 1.21.0
- updatenotification: 1.22.0
- user_ldap: 1.23.0
- user_status: 1.12.0
- viewer: 5.0.0
- weather_status: 1.12.0
- webhook_listeners: 1.3.0
- workflowengine: 2.14.0
Nextcloud configuration:
nextcloud_occ config:list system
{
"system": {
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"localhost",
"172.10.15.25",
"nnc.teka.local",
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "32.0.6.1",
"overwrite.cli.url": "https:\/\/nnc.teka.local",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"mysql.utf8mb4": true,
"installed": true,
"instanceid": "***REMOVED SENSITIVE VALUE***",
"upgrade.disable-web": true,
"log_type": "file",
"logfile": "\/var\/log\/nextcloud\/nextcloud.log",
"loglevel": "2",
"log.condition": {
"apps": [
"admin_audit"
]
},
"mail_smtpmode": "smtp",
"session_keepalive": true,
"session_lifetime": 6912000,
"remember_login_cookie_lifetime": 6912000,
"log_rotate_size": "0",
"trashbin_retention_obligation": "auto, 60",
"versions_retention_obligation": "auto, 180",
"activity_expire_days": "120",
"simpleSignUpLink.shown": false,
"default_phone_region": "ru",
"ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
"memcache.local": "\\OC\\Memcache\\APCu",
"filelocking.enabled": true,
"memcache.locking": "\\OC\\Memcache\\Redis",
"memcache.distributed": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 6379,
"timeout": 0
},
"maintenance": false,
"maintenance_window_start": 22,
"bulkupload.enabled": false,
"default_language": "us",
"onlyoffice": {
"jwt_secret": "***REMOVED SENSITIVE VALUE***",
"jwt_header": "AuthorizationJwt"
},
"data-fingerprint": "30c50d93a46572ce60b3d7e0e8275708",
"enforce_theme": "",
"mail_smtpsecure": "ssl",
"mail_sendmailmode": "smtp",
"mail_smtpauth": 1,
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "465",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"app_install_overwrite": [
"whiteboard"
],
"trusted_proxies": "***REMOVED SENSITIVE VALUE***"
}
}
Server log (data/nextcloud.log)
Insert your server log here
I have no idea how to reproduce this strange behavior for debug and logs collect.
and I do not to know what way to fix it.
any suggestion welcome
thnx
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reported /ocs/v2.php/apps/spreed/api/v3/signaling/backend request in the browser developer-tools network panel, comparing failed connections with those that succeed after a refresh. Review the custom signaling, TURN, and STUN configuration and collect server or browser logs during a failure. Done means identifying the cause of the intermittent connection failure and confirming that users connect without refreshing the page.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, javascript
- Domain
- audio-video-rtc, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100