Nextcloud Talk Android: no push notifications

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…

@MichaIng

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 :wink:.

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