PUSH Mitteilungen (wwmobile Android und iOS)
Funktionsweise PUSH
An dieser Stelle ein kurzer technischer Crashkurs zu VoIP Apps auf Mobiltelefonen (betrifft im Grunde sämtliche VoIP Apps, da sowohl Google, als auch Apple seit einigen Jahren vorschreiben, dass VoIP Apps nicht mehr klassisch eine dauernde SIP-Verbindung zum Server offen halten dürfen, sondern mit PUSH Meldungen arbeiten müssen, damit die Akkulaufzeit des Mobiltelefons verlängert werden kann):
Wieso Push:
Die Idee dahinter: anstatt dass sich 50 verschiedene Apps gleichzeitig eine Verbindung zu irgendwelchen Systemen offen halten und dafür sorgen, dass die Apps im Hintergrund laufen müssen und das Mobiltelefon nie in den Schlafmodus wechseln kann, werden Meldungen über die Push Services der beiden Anbieter gebündelt. Android und iOS garantieren, dass VoIP-Push-Mitteilungen dazu führen, dass einerseits die App geweckt wird, falls sie bereits läuft und unmittelbar die Meldung erhält und andererseits, dass sie gestartet wird, falls sie noch nicht läuft. Die Problematiken dahinter: einerseits gibt es Android Hersteller, welche dies missachten, solange man die App nicht vom Stromsparen ausnimmt (genau daher weist unsere App darauf hin, wenn sie nicht vom Stromsparen ausgenommen wurde und führt zum korrekten Ort, um dies anzupassen, wenn man auf den Hinweis klickt) und zudem funktioniert dies natürlich nur, falls die Meldung überhaupt auf dem Gerät ankommt.
Es ist nun so, dass sowohl Android, als auch iOS eine TCP-Verbindung zum Google resp. Apple Push-Service aufbauen. Gelegentlich sendet das Gerät oder der Push Service bei Inaktivität ein paar Bytes durch die Verbindung, um die Verbindung offen zu halten. Sie tun dies so wenig wie möglich, um den Akku nicht unnötig zu belasten. Natürlich muss hier aber die Firewall mitspielen: schliesst sie Verbindungen nach kürzerer Zeit, als Keepalive Nachrichten geschickt werden, ist teilweise der Socket zu und daher kann dann die Push Mitteilung nicht zugestellt werden (resp. erst verspätet, sobald das Mobiltelefon wieder mit dem Push Server kommuniziert hat und somit vom Lan her die Verbindung auf der Firewall geöffnet hat. Solche Verhaltensweisen kennt man teilweise auch von SSH Verbindungen, bei welchen man plötzlich nichts mehr eintippen kann, nachdem man 10-20 Minuten nichts mehr ins Terminal getippt hat: die Firewall hat dann in der Zwischenzeit die Verbindung geschlossen). Ebenso kann es passieren, dass ein Hersteller einen fehlerhaften Schlafmodus implementiert hat und so das Gerät das Senden der Keepalive Nachrichten verpasst oder aber die Funkverbindung im Schlafmodus trennt.
Wie man das analysieren kann:
Auf dem iPhone können Sie indem Sie im Menü auf den Menüpunkt wwmobile.log klicken direkt in der App nachvollziehen, zu welchem Zeitpunkt welche PUSH Mitteilungen an die App ausgeliefert wurden
Auf Mobiltelefonen von Google:
- das Dialpad von Android öffnen
- die Nummer *#*#426#*#* eingeben
- auf den Knopf "EVENTS" klicken
Auf Mobiltelefonen von Samsung:
- App FCM Toolbox installieren
- oben rechts im Menü "Diagnostics" auswählen
- auf den Knopf "EVENTS" klicken
Sieht man hier teilweise bevor Nachrichten eintreffen Einträge, wie im untenstehenden Screenshot (insbesondere Close err etc.), so scheint das Grät zwischenzeitlich die Verbindung zum Push Service verloren zu haben. Merkt das Gerät dies zu langsam, kann es sein, dass Mitteilungen nicht rechtzeitig ankommen und daher Anrufe verpasst werden. Leider haben wir hierauf als Hersteller der App und der Anlage keinerlei Einfluss. Beachten Sie auch, dass dies sämtliche Apps betrifft und nicht nur wwmobile. Aber natürlich bemerkt man bei einer Realtime App zuverlässig, wenn eine Push Benachrichtigung verspätet eintrifft, wohingegen man dies bei einem Messenger wie Signal und co. im Normalfall nicht bemerkt.
Hat man die beschriebenen Probleme in einem WLAN, so kann womöglich eine fehlerhafte Einstellung auf der Firewall für die Problem sorgen:
Goolge empfiehlt sicherzustellen, dass das Zeitlimit für die NAT-Session auf fcm.googleapis.com, TCP Ports 5228, 5229 und 5230 mindestens 30 Minuten beträgt
(https://firebase.google.com/docs/cloud-messaging/network-configuration?hl=de)
Beachten Sie bitte: Benachrichtigungen für ankommende Anrufe haben eine beschränkte Gültigkeitsdauer. Denn es würde nicht viel brigen, wenn der ankommende Anruf angezeigt würde, wenn der Anruf bereits wieder aufgehört hat zu klingeln. Daher beschränken wir die Gültigkeitsdauer auf die eingestellte Klingeldauer des Anrufes. Somit kann es passieren, dass Sie nach einem solchen Unterbruch der Push Verbindung die Benachrichtigung für den Anruf gar nicht in den Logs finden, da die Mitteilung zum Zeitpunkt des Wiederverbindens gar nicht mehr gültig war. In diesem Fall wird sie durch den Push Service seitens Goolge oder Apple gar nicht mehr an das Mobiltelefon gesendet und taucht daher nicht in den Logs auf.