Hi! Iām experiencing the following problem: If I write to somebody via nextcloud talk , I do not receive any notification. Even if I tag user with ā@ā independently if it is a group chat or not. Also I do not any notifications if anyone calls me.
Iāve setup STUN and TURN server (coturn) as recommended here Requirements for Nextcloud Talk
Nextcloud version: 16.0.4
Notifications app version 2.4.1
Talk app version: 6.0.4
Android app version v 6.1.6
Please compare your TURN server setup against: HowTo: Setup Nextcloud Talk with TURN server
However AFAIK the notifications have nothing to do with STUN or TURN, since no WebRTC is established yet. This is a Nextcloud or network setup issue.
Other notifications appear well? Any related Nextcloud log entries?
@MichaIng thank you for your answer. Iāve used config from article you sent me but it didnāt work.
here is my turn server config
listening-port=3478
relay-ip=[redacted]
listening-ip=[redacted]
fingerprint
use-auth-secret
static-auth-secret=[redacted]
realm=[same with relay ip]
total-quota=100
bps-capacity=0
stale-nonce
no-loopback-peers
no-multicast-peers
syslog
no-stdout-log
simple-log
log-file=/var/log/turn.log
Here is turnserver log
0: log file opened: /var/log/turn_27233_2019-09-05.log
0:
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Coturn-4.5.0.7 'dan Eider'
0:
Max number of open files/sockets allowed for this process: 4096
0:
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 2000 (approximately)
0:
==== Show him the instruments, Practical Frost: ====
0: TLS supported
0: DTLS supported
0: DTLS 1.2 supported
0: TURN/STUN ALPN supported
0: Third-party authorization (oAuth) supported
0: GCM (AEAD) supported
0: OpenSSL compile-time version: OpenSSL 1.1.0g 2 Nov 2017 (0x1010007f)
0:
0: SQLite supported, default database location is /var/lib/turn/turndb
0: Redis supported
0: PostgreSQL supported
0: MySQL supported
0: MongoDB is not supported
0:
0: Default Net Engine version: 3 (UDP thread per CPU core)
=====================================================
0: Relay address to use: [redacted]
0: Listener address to use: [redacted]
0: 0 bytes per second allowed, combined server capacity
Coturn version: 4.5.0.7
Also I tried to use Googleās public STUN servers but it didnāt helpā¦
here is my /var/www/nextcloud/config/confg.php
<?php
$CONFIG = array (
'instanceid' => [redacted]
'passwordsalt' => [redacted]
'secret' => [redacted]
'trusted_domains' =>
array (
0 => '[redacted]',
1 => '[redacted]',
2 => '[redacted]',
),
'memcache.local' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 6379,
),
'memcache.locking' => '\\OC\\Memcache\\Redis',
'datadirectory' => '/var/www/nextcloud/data',
'dbtype' => 'mysql',
'logfile' => '/var/log/nextcloud.log',
'loglevel' => 2,
'version' => '16.0.4.1',
'overwrite.cli.url' => 'https://[redacted]',
'enable_previews' => false,
'dbname' => 'nextcloud',
'dbhost' => '127.0.0.1',
'dbport' => '',
'dbtableprefix' => 'oc_',
'dbuser' => '[redacted]',
'dbpassword' => '[redacted]',
'installed' => true,
'theme' => '',
'mysql.utf8mb4' => 'true',
'updater.release.channel' => 'stable',
'updater.secret' => [redacted],
'maintenance' => false,
);
Here are the logs. (nextclouds log says nothing while Iām trying to send a message.)
Apacheās access.log (error.log also keeps silence)
91.193.67.86 - user1 [05/Sep/2019:06:11:00 -0700] "POST /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee HTTP/1.1" 201 1135 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:10:57 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee?lastKnownMessageId=6816&limit=25&lookIntoFuture=1 HTTP/1.1" 200 1000 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:02 -0700] "POST /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee HTTP/1.1" 201 964 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:00 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee?lastKnownMessageId=6817&limit=25&lookIntoFuture=1 HTTP/1.1" 200 986 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:04 -0700] "POST /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee HTTP/1.1" 201 964 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:03 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee?lastKnownMessageId=6818&limit=25&lookIntoFuture=1 HTTP/1.1" 200 986 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:06 -0700] "POST /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee HTTP/1.1" 201 963 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:05 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee?lastKnownMessageId=6819&limit=25&lookIntoFuture=1 HTTP/1.1" 200 985 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:08 -0700] "POST /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee HTTP/1.1" 201 964 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:07 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee?lastKnownMessageId=6820&limit=25&lookIntoFuture=1 HTTP/1.1" 200 986 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:09 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee/mentions?search=&limit=5 HTTP/1.1" 200 841 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - - [05/Sep/2019:06:11:09 -0700] "GET /index.php/avatar/user2/252 HTTP/1.1" 201 4429 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:10 -0700] "POST /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee HTTP/1.1" 201 1045 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:08 -0700] "GET /ocs/v2.php/apps/spreed/api/v1/chat/ih4rdcee?lastKnownMessageId=6821&limit=25&lookIntoFuture=1 HTTP/1.1" 200 1067 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"
91.193.67.86 - user1 [05/Sep/2019:06:11:15 -0700] "DELETE /ocs/v2.php/apps/spreed/api/v1/room/ih4rdcee/participants/active HTTP/1.1" 200 782 "-" "Mozilla/5.0 (Android) Nextcloud-Talk v6.1.6"Anyone here who could help me?
Iāve tried to use nextcloudās official docker container inside of my LAN and also no success. No push notifications on moblie nor in browserā¦ I saw one or two times nextcloudās pop up but it was fairly random so I couldnāt understant which conditions exactly lead it to work.
Here is my TURN server config from docker-compose. This setup seems to be working fine for me, at least so far as I can get notifications and make video calls between on-network and off-network clients. One thing to note is I run a reverse proxy with certbot on the host which is why I have a Letās Encrypt folder mounted, and a cron job on the host that restarts the Coturn container monthly. Probably not necessary since I update my containers once or twice a month anyway, but itās been working fine. Coturn uses the cert for TLS.
coturn:
image: instrumentisto/coturn
container_name: nextcloud-coturn
restart: unless-stopped
ports:
- 3478:3478/tcp
networks:
- nextcloud
volumes:
- /etc/letsencrypt:/etc/letsencrypt:ro
command: ["-n","--log-file=stdout","--min-port=49160","--max-port=49200","--realm=cloud.mydomain.net","--no-udp","--use-auth-secret","--static-auth-secret=myturnsecret","--cert=/etc/letsencrypt/live/cloud.mydomain.net/fullchain.pem","--pkey=/etc/letsencrypt/live/cloud.mydomain.net/privkey.pem"]
Here is the documentation for the container: https://hub.docker.com/r/instrumentisto/coturn
Just to be sure, the TURN server is attached to the internet directly, so not behind a NAT? If it IS behind a NAT, you need to leave the two above settings unconfigured/commented.
Since you are below v4.5.0.8, you need to set lt-cred-mech as well in your turnserver.conf.
@KarlF12
If I understood right, @sinig does not use the coTURN docker container but a dedicated instance.
And, out-of-topic, you know that Nextcloud Talk does not use/support (D)TLS? You can configure your coTURN to support it, but Nextcloud Talk still uses the plain-text TCP or UDP connection (even on the tls-listening-port). This is also no big issue, since WebRTC is encrypted on its own connection layer anyway. So having TURN encrypted does not ship any relevant security benefit, hence is an obsolete overhead 
.
But back to the topic:
@sinig
What does actually work? Try all things from within the LAN first to avoid any interference with TURN. Assure first that everything is working outside of TURN, at best with TURN unconfigured in Nextcloud:
- Chat, Video chat, notifications when receiving new messages or incoming calls.
- If any of the above does not work from within a single LAN (without any NAT between participants), then it has nothing to do with the TURN server (as it is not used) and you need to figure out the related network issue first.
- Docker of course comes with an own internal network, however AFAIK as long as the participants are located within the same āhostā network (e.g. the PCs or phones from where you use the browser or Talk app), this should not be relevant.
Chat at least seems to work fine as of your logs above? Although I just see one user1 in the access log, not user2? When you enter the chat with user2, it receives the messages instantly?
Did you try it with different clients from different location, e.g. when chatting from within Nextcloud web UI or Android Talk app but once within the same LAN, once from another location?
And also again, the notification system AFAIK has nothing to do with WebRTC, hence the TURN server. So if the only issue is that notifications do not reach the client browser or e.g. Android Talk app, then its either network related, client related or Nextcloud ācoreā related. You could try to switch to debug log level to check if there is some output about it then: 'loglevel' => 0,
@MichaIng I just provided my container settings as an example working setup. I assume a regular installation of coturn with equivalent settings should work. I donāt know a whole lot about the inner workings of Talk, but I havenāt had any problems with my setup.
1 Like
Jep, got it. Its just the configuration/file format that looks different when you configure a dedicated coTURN instance, however the settings themselves are the same.
Interesting is that you disabled UDP even that UDP is the generally recommended protocol. Is there any reason you did this? I remember playing around with the proto when I faced unstable connection on international video calls, but actually TCP vs UDP didnāt make a difference in that case.
But at least, it is another switch that is worth to play with when facing issues with TURN. One does not need to change the coTURN settings for it, but the Nextcloud Talk settings as well allow to choose between TCP, UDP or both (in which case AFAIK UDP is chosen, if supported by the server, else TCP as fallback) on the fly.
Normally for VOIP or other low-latency applications you would use UDP because itās a stateless protocol with less overhead, but on a low load system, it shouldnāt make a noticeable difference. I set it up for TCP mainly because I wasnāt sure if it would enable TLS over UDP, and I only wanted to open one port in my firewall for it.
If Talk doesnāt enable TLS for either protocol and uses encryption specific to WebRTC instead, then I suppose it doesnāt really make a difference which protocol is in use. Iāll have to run a packet capture on it sometime to verify itās encrypted. It doesnāt matter much to me at what layer the encryption takes place as long as Big Brother isnāt reading my messages.
Thatās not an issue with turn. Push Notifications are either polling of the client app or pushing via Google. In either case TURN and STUN has nothing to do with it.
If itās not a bug itās probably an issue with Android battery saving nodes which got quite aggressive an current version and which were quite aggressive with some vendors before.
1 Like
Jep coTURN is DTLS-capable for UDP. However every port that you configure with coTURN, otherwise the defaults, can be used with plain-UDP, plain-TCP, TLS over TCP and DTLS over UDP, so their naming listening-port and tls-listening-port actually have no meaning.
Its up to the client, which protocol to use on any of the four ports, and coTURN can only deny a certain protocol completely, e.g. no-udp disables plain-UDP on all ports (while DTLS over UDP is still allowed).
However indeed it does not make any relevant security difference:
- WebRTC is encrypted anyway end-to-end, which also means that the TURN server or Nextcloud cannot āreadā anything.
- Having the TURN connection encrypted as well, would be just a second layer, producing unnecessary overhead.
- Only use case (why TURN encryption exist) is that some strict firewalls might not allow unencrypted traffic at all, which means that the enveloping signalling layer must be encrypted as well.
@MichaIng sorry for keeping silence. my turn server is located at the same server with nextcloud. Itās NOT behind NAT (Iām using a hosting provider).
Actually, I was able to receive messages (but also without notifications from my browser to my phone and backwards. Also no notifications about audio\video calls.
I also tried nextcloud setup without docker, just on simple Vbox VM bridged to my LAN.
Users are receiving messages but no push notifications. Iāll try to switch to debug mode as soon I get back to work.
Video calls work, right? So when two users are within the same Talk conversation, they can accept each other calls (hitting the user name) and see each other? Notifications indeed have nothing to do with WebRTC or TURN, however it is just a check that some other layer of network functions, besides bare HTTP(S) access.
Indeed if the notifications are handled or not is also case of the client, so try different clients and browsers in both directions. I once and a while get some Nextcloud log entry about a failed push notification, although they generally arrive. However a more verbose log level might give a hint.
just to share my experience: iāve just checked and i have the same issue. basically, talk-participants have to make appointments when they want to use talk. when it is started, everything (calls, video, chat, desktop) works.
turnserver works also.
iāve tested the following scenarios:
user-1 android-9-program (āappā) to browser, chat to user-2 not logged in: user-2 gets notification bell upon login into browser, can chat if user-1 still has prog open.
user-2 browser to user-1 android-9-program (running in fg, but no communication to user-1 currently running): nothing happens until user-1 manually forces screen-refresh. then chat is displayed. if user-1 joins chat, it works well and fast.
user-2 browser to user-1 android-9-program (not running): nothing happens at all.
of course, this is expected.
user-1 android-9-program to user-2 android-9-program, both running in fg: everthing works.
iāve checked in different networks (nat, proxy etc.) and all devices have no google-services at all installed.
for me this is an issue with a near-zero priority which does not really need fixing since for realtime communication i use xmpp (and, also, in my opinion the addition of spreed/talk to nextcloud seems a little premature.)
cheers, pd
Exactly the same here (although I use Google Services).
I have to open the Talk app to actually see the new messages arrive. (Samsung S7, Talk excluded from Power Saving, Data saving off).
Hi, did you find a solution ? Iām facing the seem issue 
I dont really know if itās exactly the same error but put it anyway.
This morning I had this error:
āI needed to change the loglevel configuration to 0 'Debugā to see it".
Info notifications GuzzleHttp\Exception\ClientException: Client error: POST [https://push-notifications.nextcloud.com/notifications](https://push-notifications.nextcloud.com/notifications) resulted in a 400 Bad Request response:
Then I followed the discussions on that topics here:
So I did what they told me to do;
- Uninstall apps on mobiles
- Deleting data from nextcloud database:
- DELETE FROM oc_notifications;
- DELETE FROM oc_notifications_pushtokens;
- Reinstall apps
- And disable batterie optimisation for AndroĆÆd.
And all work again.
Tried that on NC 18 without success, videochat & screensharing work fine. NC 18 was announced with support for text chat notifications, any other suggestions what might be the problem (upgraded manually from NC17)???
Well, I know Google changed the permissions of apps to use third part notifications servers, to be able to receive notifications outside Google services you app needs to have a permanent menu on the Android Task, so Android let the app communicate with the server and not pause it. This information is mentioned also when you use the App Telegram, they also state that to Telegram notifications work correctly they had to make a persistent Telegram Icon on the Android Status Bar so Android would it let permanent connect to the Telegram Notification server, this changes were made after Android 9 Pie, useless to say that Google did this to protect their Monopolyā¦!