UCC Client auf iOS reagiert nicht

Hi,

hat jemand folgendes Problem auch? Bei einem Kunden mit aktueller Starface VM und iOS APP, tritt folgender Fall ein (ca. 1-2 Wochen).

Haben einige User dort, die nur ein iOS-Gerät nutzen, mit der APP, wenn das Handy locked ist und nicht benutzt wird und jemand versucht den Teilnehmer anzurufen, dann reagiert das Handy nicht.

Keine Signalisierung. Wenn aber das Handy unlocked ist und ein Anruf getätigt wird zu diesem Teilnehmer, dann reagiert es.

Bei Usern, die ein feststehendes Telefon haben, klingelt das Yealink und verzögert nach ca. 15-30 Sekunden das Handy erst.

Berechtigung, Hintergrundaktualisierung usw. alles schon gemacht, beim Support ist auch ein Ticket offen. Handys auf dem aktuellsten iOS Stand und und und...

Sind wir die einzigen damit?

Quote from areeh

Hallo Damian,

>Handy unlocked

Nur unlocked, STARFACE App aber trotzdem im Hintergrund oder gar nicht gestartet? (dann hätte es etwas mit den Push-Benachrichtigungen zu tun)

Oder App offen und im Vordergrund? (dann muss es andere Gründe haben, App selbst oder Verbindung zur STARFACE PBX)

Gruß

Andreas

Display More

Also wenn das Handy entsperrt ist und Starface im Hintergrund aktiv ist, funktioniert es.

IOS-Gerät gesperrt, keine Signalisierung möglich.

Es ist ganz komisch und wir tun schon die ganze Woche herum und bis jetzt keine Lösung.

Benachrichtigungen sind alle aktiv.

Tut mir leid für die verspätete Antwort.

Quote from areeh

ja klingt komisch, aber da Du schon ein Ticket offen hast (am besten mit Client und Server Logs und konrekten Beispielen mit Zeitstempeln?), wird unser Support versuchen die Ursache zu finden, das ist zielführender, als wenn ich hier oberflächlich weiter spekuliere

Hi areeh, danke. Das habe ich gemacht, es hat weiter geholfen, den Fehler zu finden.

Quote from Daniel Mauritz

Nochmal die Frage in die Runde: Nutzt Ihr das iOS Feature iCloud Private Relay?

Wir hatten einige Meldungen, bei denen es als Ursache für Verbindungsprobleme identifiziert werden konnte. Auf der Apple-Seite findet Ihr weitere Informationen dazu und auch Infos wie man es bei Bedarf deaktivieren kann:

https://support.apple.com/de-de/HT212614

Die Funktion iCloud Private Relay ist immer deaktiviert und grundsätzlich alle Features, die Mac-Adresse anonymisieren, usw.

Quote from d i r k

Ich bzw. meine Kunden nutzen das natürlich nicht, ich habe die Kunden darüber informiert bevor das herauskam, dass das bitte nicht zu verwenden ist und sogar teilweise ein Sicherheitsrisiko darstellt(e). Siehe Fachliteratur.

Kann ich verstehen, in meinen Fall wurde die APP nur intern via WLAN verwendet und ohne SIM-Karten. Kunde hat bereits ein perfektes WLAN-Netzwerk mit 12 AP's und wollte keine DECT Sender aufbauen.

Quote from d i r k

Meine Kunden mit iPhones haben alle die App deinstalliert, weil sie nicht zuverlässig funktioniert.

Liegt das mit den nicht vorhandenen Tickets möglicherweise daran?

Oder andersherum: Nutzt jemand hier die iPhone-App produktiv und überwiegend ausschließlich und mit sagen wir mal 10-30 Usern aufwärts ohne regelmäßig Probleme zu haben (bzw. bei meinen Kunden war es so, bei manchen Mitarbeitern hat es manchmal funktioniert, bei anderen Mitarbeitern desselben Kunden überwiegend nicht usw.).

Für mich war da keine Systematik erkennbar und nichts hat geholfen.

Das ist übrigens eine ernstgemeinte Frage, ich habe alle Kunden mit iPhones über ein Jahr vertröstet, es kann ja sein, dass es mittlerweile funktioniert. Wenn ich aber jetzt zum x-ten Male sage "jetzt" funktioniert es und dann ist dem nicht so, dann war es das leider!

Es hat immens viel Zeit gekostet, das zu erklären und die Kunden zur Geduld zu überreden!

Display More

Ich habe einige Kunden die tatsächlich die APP nutzen, einen davon auch als Power-User, es wird aber immer wieder mal berichtet das die APP "spinnt". Fehlermeldung erscheint, die weg geklickt wird und dann dennoch eine Verbindung stattfindet oder dass die App "weg geswiped" werden muss und beim erneuten Öffnen es funktioniert.

Aber alles Themen, die man so im Nachhinein erfährt und nie so wirklich analysiert.

Quote from Sander

Die Kunden die es rein mit der App versuchen wechseln enttäuscht auf IFMC. Das sind dann aber auch Kunden unter 10 User. Auch mit den aktuellen IOS Versionen. Die App ist stabiler geworden aber wir bewegen uns leider immer noch gefühlt im Bereich Note 4. Stabilität ist einfach wichtiger als Funktionsumfang.

Kann ich verstehen, wir haben zum Teil aber auch Nutzer die, die APP mit der Cloud nutzen (unter 10 User) und bis jetzt kaum bis selten was gehört habe.

Da kommen wir wieder zum Thema, keine Systematik erkennbar, wieso bei manchen es sehr unstabil funktioniert.

So, nun mal zu dem Angefangen Problem, nach gründlicher Analyse, konnten wir den Fehler finden, aber leider noch nicht beheben.

Es scheint so, dass das WLAN Netzwerk eine Art Standby für die Wi-Fi Geräte realisiert.

Das ganze schimpft sich "Unscheduled Automatic Power Save Delivery", kurz UAPSD.

Die Datenpakete werden vorgehalten und erst verzögert dem Gerät geliefert, damit der Akku gespart werden kann ...

Obwohl dies deaktiviert ist, werden dennoch "komischerweise" alle mobilen Geräte (Handys) damit versorgt.

Da wir keine SIM-Karten eingesetzt haben und die Geräte nur ein Wi-Fi Verbindung haben, reagiert die Fallbackverbindung "Mobile Daten" nicht.

→ Somit keine Signalisierung seitens der Starface Anlage.

Wird jetzt eine SIM-Karte eingesetzt, mit Zugriff auf Mobile Daten, funktioniert die Push-Benachrichtigung und eine Signalisierung der Starface Anlage zu Endgerät findet statt.

Workaround, es wurden kurzfristig SIM-Karten eingesetzt, bis das Problem endgültig gelöst wird.

Sorry für den Doppelpost, wollte es abgrenzen.

Quote from areeh

Hi Damian, sehr interessant, danke fürs Teilen!

Lässt sich das Verhalten der Geräte auch irgendwie mit einfachen Mitteln nachvollziehen? Was ist z.B., wenn man die iPhones im gesperrten nicht genutzten Zustand von der STARFACE / aus dem LAN anpingt, gehen die Pings normal durch, gar nicht, stark verzögert? (ich überlege, ob es sinnvoll wäre, einen solch einen Check in einen unsere Fehlerleitfaden zwecks Eingrenzung aufzunehmen)

Gruß

Andreas

An ein Ping habe ich gar nicht gedacht, da das Netzwerk eine Segmentierung besitzt und ich erst hierzu Firewall Regeln erstellen müsste … Um ein Ping in dieses Netz hereinzulassen. Da das VoIP Netzwerk vollständig isoliert ist. Gerne würde ich aber sowas noch testen und bei Gelegenheit Bescheid geben.

Was noch interessant zu wissen ist, da die Pakete mittels UAPSD verzögert übermittelt werden, ist es sogar des Öfteren der Fall gewesen, dass wenn ein User, das Gespräch mit einem Yealink annimmt ... 2-5min später die UCC APP reagiert und den Call durchstellt, der schon längst am Yealink läuft!

Eine Mitarbeiterin, hat es sogar geschafft (meine Vermutung mittlerweile) mittels "dieser Technik" versehentlich, dass Telefonat des Chefs mitzuhören, ohne dass er das mitbekommen hat !!!!

(Auch dazu liegt ein Ticket vor, nur war mir bis jetzt nicht bewusst, dass es damit zusammenhängen könnte!)

Quote from roady1969

Welcher Hersteller ist das, der Unscheduled Automatic Power Save Delivery" nutzt?

In diesem Fall werden Unifi Access Points verwendet.

Quote from areeh

Und kann man das dann auf den APs üblicherweise nur komplett an/ausschalten, oder lassen sich ggf. whitelists/blacklists erstellen? Sodass man sagen kann, mach das für bestimmten Traffic, oder für bestimmten Traffic nicht? Z.B. aufgrund Source/Target IP/Ports? Oder ggf. auch abhängig von bestimmten QoS-Markierungen?

Da sind wir noch dran, da anscheinend das normalerweise möglich ist auszuschalten, aber in diesem Fall liegt beim Kunden eine Abweichung vor und lässt es dennoch zu. Als kleiner Dienstleister, leider etwas Zeitaufwändig ...