Nextcloud Talk geht nicht komplett

🌐 International support đŸ‡©đŸ‡Ș Deutsch (german)
, , , , , ,
1

Hallo zusammen,

ich habe vor kurzem mal Nextcloud Hub 9 - AIO via Docker ausgerollt und jetzt mit “Talk” folgendes Problem.

Zu meiner Umgebung:
Mein Homelab lÀuft unter einem Proxmox Server. Auf diesem lÀuft unter anderem eine Ubuntu 24 Server VM (IP: 192.168.1.2) , auf welcher meine ganzen Docker Container laufen.

Da ich bei mir vom Provider nur eine IPv6 Anbindung bekomme, habe ich mir zusÀtzlich im Internet noch einen virtuellen Server (VPS 200 G10s - Root-Server bei netcup) mit einer IPv4 Adresse angemietet.

Die ganzen FQDNs landen via DNS dann bei der externen IP des externen Internetserver. Auf diesem lÀuft auch Wireguard.

Auf meinem Proxmox lÀuft ebenfalls Wireguard in einem Container. Die VPN Verbindung zwischen beiden Servern steht.

Auf dem externen Server lĂ€uft noch NPM (Nginx Proxy Manager). Dieser verwaltet meine ganzen Microservices, unter anderem auch die Nextcloud, welche so gut funktioniert. Bedeutet also, das meine https://mein-nextcloud-server.tld via DNS bei der externen IPv4 Adresse meines VPS landet, der NPM dann sagt, das dieser auf 192.168.1.2 zu erreichen ist und der Wireguard dafĂŒr sorgt, das die Anfrage das Ziel erreicht.

Ich habe jetzt mal 2 Benutzer angelegt, welche sich via Talk unterhalten sollten. Wenn es nur um das schreiben geht, funktioniert alles gut, aber telefonieren via Talk geht nicht.

Was habe ich bisher zusÀtzlich eingestellt?!

Auf meiner Fritzbox den TCP und UDP Port 3478 (STUN) zur VM (192.168.1.2), auf welchem der Nextcloud Docker Container lÀuft geöffnet. ZusÀtzlich noch den TCP Port 5349 (TURN).

Auf meinem externen Server (ich habe dort aktuell noch keine Firewall aktiv, nur um eine weitere Fehlerquelle auszuschließen) habe ich mit oben beschriebenen Ports 2 Streams eingerichtet zur IP 192.168.1.2 eingerichtet.

Leider baut Talk aber keine Telefonie auf.

Da ich noch ein Neuling bin, brauche ich hier mal detaillierte Hilfe.

Falls noch irgendwelche Daten fehlen, bitte einfach nachfragen.

Gruß H-BLOGX

1 Like
2

hallo @holgair du stichst da ins Wespennest mit der Frage nach “detaillierte Hilfe”. Das Problem ist einfach und kompliziert zugleich. GrundsĂ€tzlich ist es so dass wenn CLients warum auch immer keine direkte Netzwerk Verbindung haben verwenden sie einen turn server - soweit hast du dich informiert und versucht es einzurichten. Dort steckt aber der Teufel :imp: im Detail - das TURN Protocol hat nichts mit http/s zu tun! es ist hĂ€ufig sehr wackelig weil man dort (bevorzugt) verbindungslos mit UDP arbeitet und die Komponenten darauf angewiesen sind eine direkte Punkt-zuPunkt Verbindung haben
 dies ist bei abentuerlichen Netwerk-Konstrukten mit VPN Tunnel usw sehr schwer herzustellen.

Einen Àhnlichen Thread findest du hier Coturn on VPS with NGINX Proxy Manager Connecting to VM in a VLAN (All This Trouble for Nextcloud Talk) dort sind auch einige Tipps zu loggen und troubleshooten zu finden.

Generell wĂŒrde ich empfehlen den turn server wenn es geht auf dem VPS zu installieren - diese Komponente dient als Relay fĂŒr den gesamten Media TRaffic - Audio und Video und Desktop Sharing
 Netzwerktechnisch ist es Unsinn das alles bis zum Server zu Hause und dann zurĂŒck zu senden, wenn Clients im Internet sind, die KomplexitĂ€t des VPN Tunnel kommt dazu.

Ich kann dir sehr ans Herz legen die Turn docs (mehrfach) zu lesen - es ist nicht einfach die Funktionsweise zu begreifen, damit man wirklich alles richtig implementieren kann:

3

Hi. I got the same issue. The TALK (NC 30.0.5) in NC admin panel can’t connect to coTURN server, but all manual checks works great. I have checked with tcpdump , it looks like NC really doesn’t make any checks. No NC logs.

manual checks:
on NC

root@4e7644ab2a46:/var/www/html# turnutils_uclient -p 8443 -W ..... -v -y turn.sv-tm.com
0: : IPv4. Connected from: 172.16.1.3:56334
0: : IPv4. Connected from: 172.16.1.3:56334
0: : IPv4. Connected to: 172.27.80.12:8443
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:58908
0: : clnet_allocate: rtv=15044093505180853946
0: : refresh sent
0: : refresh response received: 
0: : success
0: : IPv4. Connected from: 172.16.1.3:44630
0: : IPv4. Connected to: 172.27.80.12:8443
0: : IPv4. Connected from: 172.16.1.3:54170
0: : IPv4. Connected to: 172.27.80.12:8443
0: : IPv4. Connected from: 172.16.1.3:58082
0: : IPv4. Connected to: 172.27.80.12:8443
0: : IPv4. Connected from: 172.16.1.3:59427
0: : IPv4. Connected to: 172.27.80.12:8443
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:58909
0: : clnet_allocate: rtv=0
0: : refresh sent
0: : refresh response received: 
0: : success
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:59066
0: : clnet_allocate: rtv=4344758572690762291
0: : refresh sent
0: : refresh response received: 
0: : success
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:59067
0: : clnet_allocate: rtv=0
0: : refresh sent
0: : refresh response received: 
0: : success
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:52424
0: : clnet_allocate: rtv=12160875770328243089
0: : refresh sent
0: : refresh response received: 
0: : success
0: : channel bind sent
0: : cb response received: 
0: : success: 0x58b7
0: : channel bind sent
0: : cb response received: 
0: : success: 0x5131
0: : channel bind sent
0: : cb response received: 
0: : success: 0x701c
0: : channel bind sent
0: : cb response received: 
0: : success: 0x6bf3
0: : Total connect time is 0
1: : start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
2: : start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
3: : start_mclient: msz=4, tot_send_msgs=10, tot_recv_msgs=10, tot_send_bytes ~ 1000, tot_recv_bytes ~ 1000
4: : start_mclient: msz=4, tot_send_msgs=15, tot_recv_msgs=15, tot_send_bytes ~ 1500, tot_recv_bytes ~ 1500
5: : start_mclient: msz=4, tot_send_msgs=15, tot_recv_msgs=15, tot_send_bytes ~ 1500, tot_recv_bytes ~ 1500
5: : done, connection 0x7f43def14010 closed.
5: : done, connection 0x7f43deef3010 closed.
5: : done, connection 0x7f43deed2010 closed.
5: : done, connection 0x7f43deeb1010 closed.
5: : start_mclient: tot_send_msgs=20, tot_recv_msgs=20
5: : start_mclient: tot_send_bytes ~ 2000, tot_recv_bytes ~ 2000
5: : Total transmit time is 5
5: : Total lost packets 0 (0.000000%), total send dropped 0 (0.000000%)
5: : Average round trip delay 0.000000 ms; min = 0 ms, max = 0 ms
5: : Average jitter 1.450000 ms; min = 0 ms, max = 4 ms
root@4e7644ab2a46:/var/www/html# exit
exit
root@chat:/# docker exec -it nextcloud-app bash
www-data@4e7644ab2a46:~/html$ turnutils_uclient -p 8443 -W ......  -v -y turn.sv-tm.com
0: : IPv4. Connected from: 172.16.1.3:34654
0: : IPv4. Connected from: 172.16.1.3:34654
0: : IPv4. Connected to: 172.27.80.12:8443
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:58756
0: : clnet_allocate: rtv=18300310625497567295
0: : refresh sent
0: : refresh response received: 
0: : success
0: : IPv4. Connected from: 172.16.1.3:38503
0: : IPv4. Connected to: 172.27.80.12:8443
0: : IPv4. Connected from: 172.16.1.3:40385
0: : IPv4. Connected to: 172.27.80.12:8443
0: : IPv4. Connected from: 172.16.1.3:59257
0: : IPv4. Connected to: 172.27.80.12:8443
0: : IPv4. Connected from: 172.16.1.3:60632
0: : IPv4. Connected to: 172.27.80.12:8443
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:58757
0: : clnet_allocate: rtv=0
0: : refresh sent
0: : refresh response received: 
0: : success
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:57508
0: : clnet_allocate: rtv=12879225569029122996
0: : refresh sent
0: : refresh response received: 
0: : success
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:57509
0: : clnet_allocate: rtv=0
0: : refresh sent
0: : refresh response received: 
0: : success
0: : allocate sent
0: : allocate response received: 
0: : allocate sent
0: : allocate response received: 
0: : success
0: : IPv4. Received relay addr: 172.27.80.12:60340
0: : clnet_allocate: rtv=5116364282234924836
0: : refresh sent
0: : refresh response received: 
0: : success
0: : channel bind sent
0: : cb response received: 
0: : success: 0x7c06
0: : channel bind sent
0: : cb response received: 
0: : success: 0x6cec
0: : channel bind sent
0: : cb response received: 
0: : success: 0x66fd
0: : channel bind sent
0: : cb response received: 
0: : success: 0x7193
0: : Total connect time is 0
1: : start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
2: : start_mclient: msz=4, tot_send_msgs=5, tot_recv_msgs=5, tot_send_bytes ~ 500, tot_recv_bytes ~ 500
3: : start_mclient: msz=4, tot_send_msgs=5, tot_recv_msgs=5, tot_send_bytes ~ 500, tot_recv_bytes ~ 500
4: : start_mclient: msz=4, tot_send_msgs=10, tot_recv_msgs=10, tot_send_bytes ~ 1000, tot_recv_bytes ~ 1000
4: : done, connection 0x7fa4d1769010 closed.
4: : done, connection 0x7fa4d1748010 closed.
4: : done, connection 0x7fa4d1706010 closed.
4: : done, connection 0x7fa4d1727010 closed.
4: : start_mclient: tot_send_msgs=20, tot_recv_msgs=20
4: : start_mclient: tot_send_bytes ~ 2000, tot_recv_bytes ~ 2000
4: : Total transmit time is 4
4: : Total lost packets 0 (0.000000%), total send dropped 0 (0.000000%)
4: : Average round trip delay 0.000000 ms; min = 0 ms, max = 0 ms
4: : Average jitter 0.550000 ms; min = 0 ms, max = 1 ms

on TURN

Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 878: : session 001000000000000001: usage: realm=<turn.sv-tm.com>, username=<1738225947>, rp=3, rb=300, sp=3, sb=268
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000007: realm <turn.sv-tm.com> user <1738226414>: incoming packet CHANNEL_BIND processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000008: refreshed, realm=<turn.sv-tm.com>, username=<1738226414>, lifetime=600
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000008: realm <turn.sv-tm.com> user <1738226414>: incoming packet REFRESH processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000008: peer 172.27.80.12:58757 lifetime updated: 300
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000008: realm <turn.sv-tm.com> user <1738226414>: incoming packet CREATE_PERMISSION processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000008: peer 172.27.80.12:58757 lifetime updated: 600
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 568: : session 000000000000000008: realm <turn.sv-tm.com> user <1738226414>: incoming packet CHANNEL_BIND processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 001000000000000006: refreshed, realm=<turn.sv-tm.com>, username=<1738226414>, lifetime=0
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 001000000000000006: realm <turn.sv-tm.com> user <1738226414>: incoming packet REFRESH processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 001000000000000007: refreshed, realm=<turn.sv-tm.com>, username=<1738226414>, lifetime=0
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 001000000000000007: realm <turn.sv-tm.com> user <1738226414>: incoming packet REFRESH processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 000000000000000007: refreshed, realm=<turn.sv-tm.com>, username=<1738226414>, lifetime=0
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 000000000000000007: realm <turn.sv-tm.com> user <1738226414>: incoming packet REFRESH processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 000000000000000008: refreshed, realm=<turn.sv-tm.com>, username=<1738226414>, lifetime=0
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 572: : session 000000000000000008: realm <turn.sv-tm.com> user <1738226414>: incoming packet REFRESH processed, success
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000006: usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=13, rb=1436, sp=13, sb=1092
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000006: peer usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=5, rb=500, sp=5, sb=500
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 878: : session 001000000000000001: peer usage: realm=<turn.sv-tm.com>, username=<1738225947>, rp=0, rb=0, sp=0, sb=0
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000006: closed (2nd stage), user <1738226414> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:38503, reason: allocation timeout
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000006: delete: realm=<turn.sv-tm.com>, username=<1738226414>
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000006: peer 172.27.80.12:57509 deleted
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000007: usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=13, rb=1428, sp=13, sb=1104
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000007: peer usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=5, rb=500, sp=5, sb=500
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000007: closed (2nd stage), user <1738226414> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:60632, reason: allocation timeout
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000007: delete: realm=<turn.sv-tm.com>, username=<1738226414>
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 001000000000000007: peer 172.27.80.12:57508 deleted
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000007: usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=13, rb=1428, sp=13, sb=1104
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000007: peer usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=5, rb=500, sp=5, sb=500
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000007: closed (2nd stage), user <1738226414> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:40385, reason: allocation timeout
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000007: delete: realm=<turn.sv-tm.com>, username=<1738226414>
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000007: peer 172.27.80.12:60340 deleted
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000008: usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=13, rb=1436, sp=13, sb=1092
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000008: peer usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=5, rb=500, sp=5, sb=500
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000008: closed (2nd stage), user <1738226414> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:59257, reason: allocation timeout
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000008: delete: realm=<turn.sv-tm.com>, username=<1738226414>
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 878: : session 001000000000000001: closed (2nd stage), user <1738225947> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:47123, reason: allocation timeout
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 573: : session 000000000000000008: peer 172.27.80.12:58757 deleted
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 878: : session 001000000000000001: usage: realm=<turn.sv-tm.com>, username=<1738225947>, rp=3, rb=300, sp=3, sb=268
Jan 29 11:45:24 signal.sv-tm.com turnserver[2370]: 878: : session 001000000000000001: delete: realm=<turn.sv-tm.com>, username=<1738225947>
Jan 29 11:52:49 signal.sv-tm.com turnserver[2370]: 1323: : session 000000000000000004: usage: realm=<turn.sv-tm.com>, username=<1738226392>, rp=3, rb=300, sp=3, sb=268
Jan 29 11:52:49 signal.sv-tm.com turnserver[2370]: 1323: : session 000000000000000004: peer usage: realm=<turn.sv-tm.com>, username=<1738226392>, rp=0, rb=0, sp=0, sb=0
Jan 29 11:52:49 signal.sv-tm.com turnserver[2370]: 1323: : session 000000000000000004: closed (2nd stage), user <1738226392> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:56334, reason: allocation timeout
Jan 29 11:52:49 signal.sv-tm.com turnserver[2370]: 1323: : session 000000000000000004: delete: realm=<turn.sv-tm.com>, username=<1738226392>
Jan 29 11:53:11 signal.sv-tm.com turnserver[2370]: 1345: : session 000000000000000006: usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=3, rb=300, sp=3, sb=268
Jan 29 11:53:11 signal.sv-tm.com turnserver[2370]: 1345: : session 000000000000000006: peer usage: realm=<turn.sv-tm.com>, username=<1738226414>, rp=0, rb=0, sp=0, sb=0
Jan 29 11:53:11 signal.sv-tm.com turnserver[2370]: 1345: : session 000000000000000006: closed (2nd stage), user <1738226414> realm <turn.sv-tm.com> origin <>, local 172.27.80.12:8443, remote 172.27.80.13:34654, reason: allocation timeout
Jan 29 11:53:11 signal.sv-tm.com turnserver[2370]: 1345: : session 000000000000000006: delete: realm=<turn.sv-tm.com>, username=<1738226414>

When i press check (wave) in NC web interface:
on NC

image
image2139×302 22.4 KB

root@chat:/# tcpdump -i any port 8443
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^C
0 packets captured
2 packets received by filter
0 packets dropped by kernel

on TURN

root@signal:/# tcpdump -i any port 8443
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^C
0 packets captured
4 packets received by filter
0 packets dropped by kernel

root@chat:/# docker  exec -it nextcloud-app  php -r "var_dump(dns_get_record('turn.sv-tm.com', DNS_A ) ) ;"
array(1) {
  [0]=>
  array(5) {
    ["host"]=>
    string(14) "turn.sv-tm.com"
    ["class"]=>
    string(2) "IN"
    ["ttl"]=>
    int(0)
    ["type"]=>
    string(1) "A"
    ["ip"]=>
    string(12) "172.27.80.12"
  }
}


root@chat:/# docker  exec -it nextcloud-app  php -r "echo gethostbyname('turn.sv-tm.com');"
172.27.80.12
4

it’s not the server but the client who need TURN and connectivity checks (at least as long you don’t use signalling server which works like an MCU=conferencing bridge)

2 Likes
5

Exactly, the check is done in the browser (so client side), not from the Nextcloud instance as that wouldn’t indicate if connections from outside would work.
You can check the browser console for some details

1 Like
6

I am stupid. I decided that checks runs on NC, but they runs in client’s browser
 Something has been changed in network, and turn’s ports became unreachable.