AIO ova - Talk Spreed HPB - Cannot connect to Signaling Server

[ive_online]

Hello

I am a newbie to the use and implementation of Nextcloud-AIO. Very very nice !

I made use of the All-in-One VM image,
no proxy and setup with daily backup & automatic updates.

Unfortunately, a constant error occurs regarding Talk, that it cannot connect to server:

Der Aufbau der Signaling-Verbindung dauert länger als erwartet…
Fehler beim Herstellen der Signalisierungsverbindung. Möglicherweise stimmt etwas in der Konfiguration des Signalisierungsservers nicht

@AIO-Interface:
Talk (Running)
Talk Recording (Running)

@Administration
Talk Settings:

• STUN-Server
• TURN-Server
• Hochleistungs-Backend
• Aufzeichnungs-Backend show no failure
  
  

Result of

$ curl -vvv https://[DOMAIN.COM]:443/standalone-signaling/api/v1/welcome
* Trying [SERVERIP]:443…
* Connected to [DOMAIN.COM] ([SERVERIP]) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=[DOMAIN.COM]
* start date: Oct 24 17:56:12 2023 GMT
* expire date: Jan 22 17:56:11 2024 GMT
* subjectAltName: host “[DOMAIN.COM]” matched cert’s “[DOMAIN.COM]”
* issuer: C=US; O=Let’s Encrypt; CN=R3
* SSL certificate verify ok.
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://[DOMAIN.COM]:443/standalone-signaling/api/v1/welcome
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: [DOMAIN.COM]]
* [HTTP/2] [1] [:path: /standalone-signaling/api/v1/welcome]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
> GET /standalone-signaling/api/v1/welcome HTTP/2
> Host: [DOMAIN.COM]
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/2 200
< alt-svc: h3=“:443”; ma=2592000
< content-type: application/json; charset=utf-8
< date: Mon, 13 Nov 2023 11:57:02 GMT
< server: Caddy
< server: nextcloud-spreed-signaling/12de5a9b71afef06eaf171099712ef0a5f6ca0c4
< x-spreed-signaling-features: audio-video-permissions, hello-v2, incall-all, mcu, simulcast, switchto, transient-data, update-sdp, welcome
< content-length: 94
<
{“nextcloud-spreed-signaling”:“Welcome”,“version”:“12de5a9b71afef06eaf171099712ef0a5f6ca0c4”}
* Connection #0 to host [DOMAIN.COM] left intact

Log of the nextcloud-aio-talk container:

https://[DOMAIN.COM]:8443/api/docker/logs?id=nextcloud-aio-talk
++ dig nextcloud-aio-talk IN A +short ++ grep ‘[1]+$’
++ head -n1
++ sort
IPv4_ADDRESS_TALK=172.18.0.3 ++ dig nextcloud-aio-talk AAAA +short ++ grep ‘[2]+$’++ ++ sort head -n1
IPv6_ADDRESS_TALK=
set +x Exec: /opt/eturnal/erts-14.0.2/bin/erlexec -noinput +Bd -boot /opt/eturnal/releases/1.12.0/start -mode embedded -boot_var SYSTEM_LIB_DIR /opt/eturnal/lib -config /opt/eturnal/releases/1.12.0/sys.config -args_file /opt/eturnal/releases/1.12.0/vm.args -erl_epmd_port 3470 -start_epmd false – foreground Root: /opt/eturnal
rnal
[27] 2023/11/13 04:02:06.438144 [INF] Starting nats-server
[27] 2023/11/13 04:02:06.441151 [INF] Version: 2.10.3
[27] 2023/11/13 04:02:06.441153 [INF] Git: [1528434]
[27] 2023/11/13 04:02:06.441155 [INF] Name: NAAJ4IULGZSXDTKSEQJM6OFLGIBKVCM5YHKLQGN62OT27QLADTU4L7GQ
[27] 2023/11/13 04:02:06.441160 [INF] ID: NAAJ4IULGZSXDTKSEQJM6OFLGIBKVCM5YHKLQGN62OT27QLADTU4L7GQ
[27] 2023/11/13 04:02:06.441167 [INF] Using configuration file: /etc/nats.conf
[27] 2023/11/13 04:02:06.453493 [INF] Listening for client connections on 127.0.0.1:4222
[27] 2023/11/13 04:02:06.453501 [INF] Server is ready
Janus commit: 22298e847202d7ae6e60a0592130b6f96752789e
Compiled on: Fri Oct 27 11:14:22 UTC 2023
Logger plugins folder: /usr/local/lib/janus/loggers
Starting Meetecho Janus (WebRTC Server) v0.14.0
Checking command line arguments…
Debug/log level is 3
Debug/log timestamps are disabled
Debug/log colors are disabled
[WARN] Janus is deployed on a private address (172.18.0.3) but you didn’t specify any STUN server! Expect trouble if this is supposed to work over the internet and not just in a LAN…
[WARN] libcurl not available, Streaming plugin will not have RTSP support
[WARN] libogg not available, Streaming plugin will not have file-based Opus streaming
main.go:133: Starting up version 12de5a9b71afef06eaf171099712ef0a5f6ca0c4/go1.20.5 as pid 28
main.go:142: Using a maximum of 3 CPUs
natsclient.go:108: Connection established to nats://127.0.0.1:4222 (NAAJ4IULGZSXDTKSEQJM6OFLGIBKVCM5YHKLQGN62OT27QLADTU4L7GQ)
grpc_common.go:167: WARNING: No GRPC server certificate and/or key configured, running unencrypted
grpc_common.go:169: WARNING: No GRPC CA configured, expecting unencrypted connections
backend_storage_static.go:72: Backend backend-1 added for https://[DOMAIN.COM]/
hub.go:200: Using a maximum of 8 concurrent backend connections per host
hub.go:207: Using a timeout of 10s for backend connections
hub.go:303: Not using GeoIP database
main.go:228: Could not initialize janus MCU (dial tcp 127.0.0.1:8188: connect: connection refused) will retry in 1s
[WARN] No Unix Sockets server started, giving up…
[WARN] The ‘janus.transport.pfunix’ plugin could not be initialized
mcu_janus.go:294: Connected to Janus WebRTC Server 0.14.0 by Meetecho s.r.l.
mcu_janus.go:300: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
mcu_janus.go:305: Data channels are supported
mcu_janus.go:309: Full-Trickle is enabled
mcu_janus.go:311: Maximum bandwidth 1048576 bits/sec per publishing stream
mcu_janus.go:312: Maximum bandwidth 2097152 bits/sec per screensharing stream
mcu_janus.go:318: Created Janus session 6821307493612106
mcu_janus.go:325: Created Janus handle 1522041572882229
main.go:263: Using janus MCU
hub.go:385: Using a timeout of 10s for MCU requests
backend_server.go:111: No IPs configured for the stats endpoint, only allowing access from 127.0.0.1
main.go:339: Listening on 0.0.0.0:8081
client.go:284: Client from [CLIENTIP] has RTT of 151 ms (151.414891ms)
client.go:284: Client from [CLIENTIP] has RTT of 112 ms (112.687309ms)
client.go:284: Client from [CLIENTIP] has RTT of 94 ms (94.838008ms)
client.go:284: Client from [CLIENTIP] has RTT of 107 ms (107.658469ms)
client.go:284: Client from [CLIENTIP] has RTT of 409 ms (409.641487ms)
client.go:284: Client from [CLIENTIP] has RTT of 213 ms (213.879134ms)
client.go:284: Client from [CLIENTIP] has RTT of 426 ms (426.639512ms)
client.go:284: Client from [CLIENTIP] has RTT of 283 ms (283.914738ms)
client.go:284: Client from [CLIENTIP] has RTT of 122 ms (122.435144ms)
client.go:284: Client from [CLIENTIP] has RTT of 218 ms (218.577487ms)
client.go:284: Client from [CLIENTIP] has RTT of 372 ms (372.43193ms)
client.go:284: Client from [CLIENTIP] has RTT of 18 ms (18.36552ms)
client.go:284: Client from [CLIENTIP] has RTT of 16 ms (16.601217ms)
client.go:284: Client from [CLIENTIP] has RTT of 18 ms (18.548559ms)
client.go:284: Client from [CLIENTIP] has RTT of 18 ms (18.26575ms)
client.go:284: Client from [CLIENTIP] has RTT of 18 ms (18.064661ms)
client.go:284: Client from [CLIENTIP] has RTT of 17 ms (17.968451ms)

Where else could I look ? Is there anything I might have missed regarding “All-in-One VM image” and “Talk” ?
Your support would be greatly appreciated.

Best regards, Ive

---

Using: All-in-One VM image
https://download.nextcloud.com/aio-vm/

Nextcloud Hub 6 (27.1.3)
Nextcloud AIO v7.5.1
Using the integrated
Daily backup and automatic updates

---

---

1. 0-9. ↩︎

2. 0-9a-f: ↩︎

[szaimen]

Hi, are you using Cloudflare? Also can you check if it works from a different network/browser/device?

[ive_online]

Dear szaimen,

thank you for your time !

No Cloudflare,
and I tested
with different Browser (Fennec, Firefox, Chromium, Brave (even Tor ;-), different devices (Desktop PC, Smartphone), and with different networks.

I used at my local network (LAN)

• Fennec at Android Smartphone
• Firefox, Chromium at Linux
• Brave at Macbook
  and
• checked with Tor Browser

At a remote virtual machine (Fedora) in a different network (LAN, no DMZ) I used

• Firefox

I add some screenshots. (Please ignore the WebSocket Connection “https://DOMAIN/push/ws” failure in the screenshots regarding Notification Push Container.)

Based on the tests with the different browsers / devices / networks, it can be ruled out that the cause is client-side, correct ?

Where else could I possibly look into, which would be helpful and can provide information ? Thank you for accompanying me in finding (the cause) or better the solution Ive

---

[szaimen]

Did you enable websockets in your reverse proxy?

[SysKeeper]

Invalid_backend means that the URL you use to connect to the Nextcloud instance is not the one expected by the signaling server.

[szaimen]

This would make sense. The url also looks suspocious. Can you remove the spreed part from the url end?

[ive_online]

Thank you very much for your thoughts !
I didn’t make any arbitrary adjustments, but took the VM as it is. I just wanted to take a look at the Nextcloud-AIO solution.
Therefore, I can’t really give any information for settings that I might have been able to make on my own. I changed the ssh user password, set up the automated backup & update, and previously typed in the domainname for validation & initialization. According to the AIO Interface, all Containers are Running ( except Notify Push (Starting) 3 days later with the automated update from notify_push v0.6.3 to v0.6.4 03:00 UTC at Nov 9 23 ). I changed nothing at the Admininistration Setting for Talk and there is no failure shown (see first post). and I checked again the nslookup DOMAIN: SERVERIP, nslookup SERVERIP: DOMAIN, which are ok. And no proxy is in place. I really don’t know what “invalid_backend” means or indicates. The backend is the ready to use VM with the automated updates.
I’ll probably set up the virtual machine again. Unfortunately, I don’t have any other approach.

Using: All-in-One VM image
https://download.nextcloud.com/aio-vm/

[ive_online]

Hello. I’m sorry I’m just getting back to you. I’m on vacation right now. Shortly before that, I managed to get rid off the error messages when connecting to the signaling server. However, I haven’t tested yet, that will follow after my vacation.
The reason why I got the error at talk was very likely because I received an error message during domain validation (installation process). With my troubleshooting I changed the domain name and in the end it worked.
I assume that the first domain name was saved as well and caused the error in the system.
At the moment I thank you very much for your time and your thoughts, which are thought-provoking and I was able to get to the bottom of the cause Ive