Bei Anmeldung nach Neustart des Windows-Client erscheint der Dialog “Anmeldung fehlgeschlagen, Ihre Zugangsdaten haben sich anscheinend geändert…”
Die Anmeldung gelingt erst, wenn der Client mit dem vorgeschlagenen Button “Zurücksetzen” zurückgesetzt wird. Das ist wiederholt nachstellbar und bei uns bei allen Usern der Fall, die die 76er Beta-Version verwenden, unabhängig ob LDAP oder nicht. Ich hoffe, das ist vor dem Ausrollen behoben.
Viele Grüße
Hallo @hazington,
Berechtigungen:
Die zwei aus unserer sicht als Optional zu betrachtene Berechtigung sind die für die Kontatkliste und Kamera.
- Mikrofon brauchen wir zum telefonieren
- Medien / Storage ist für die Dateiübertragung notwendig, sonst darf der Client nix im Downloads-Ordner speichern
- Batteriespar-Ausnahmen sind Notwendig damit der Client sauber aus dem Hintergrun aufwachen kann.
- Zugriff auf den Telefonstatus ist notwendig, damit der client wissen kann, ob man über eine andere App oder GSM telefoniert und sich entsprechend richtig verhält
Diese Berechtigungen nicht zu vergeben ist aus unserer Sicht eine Fehlkonfiguration und darauf weisst der Client hin. Alles andere führt zu erhöhtem Supportaufwand und unnötigem Debugging. Wer die Berechtigung ja unbedingt entziehen will, kann das ja tun, die App verweigert ja, soweit es dann möglich ist, den Dienst nicht.
Text “Wir bereiten alles vor” nach Neustart:
Die Anzeige dieses Bildschirms ist technisch bedingt. Wir könnten höchstens einen anderen Text hinschreiben. Am besten ist es immer, die App nicht unnötig zu beenden. Ein Kaltstart verursacht zwangsweise zusätzliche Latenz. Und wir versuchen mit unserer App ohnehin möglichst wenig RAM zu verbrauchen.
Thema Ruckeln beim Synchronisieren:
Ja, wir arbeiten daran, sollte eigentlich nicht so sein.
Eingehende Anrufe warten auf Synchronisation:
Das ist ebenfalls technisch bedingt und ein Thema für eine zukünftige Verbesserung. Wir sind da auch dran das schneller zu machen.
Anzeige “Du hast kein Telefon” nach einem Neustart:
Das ist ein Bug, es werden ein paar notwendige Daten hier nicht zwischengespeichert. Werden wir reparieren.
danke für das Feedback, das sollte so nicht passieren und ist in unsereren Tests auch nicht aufgetreten. Magst du bitte folgende Schritte durchführen:
- Die Beta deinstallieren
- Das Verzeichnis
%APPDATA%\pascom Clientlöschen - 75.R installieren, mit einem Benutzer anmelden und in den Einstellungen den Debug-Modus einschalten
- Dann auf die Beta updaten, den Fehler reproduzieren
- Supportinfo erstellen und mir via PN hier senden
Das würde uns beim Debuggen helfen.
Grüße
Jan
Seit dem neuesten Update passiert es bei mir wieder häufiger, dass ein Anruf signalisiert wird den ich längst am Snom angenommen habe.
Es wurde mir auch schonmal ein Anruf erst dann signalisiert als ich den Anruf am Snom bereits angenommen und beendet hatte.
Was kann man dagegen tun?
Ich kann auf meinem iOS-Gerät auch beobachten, dass der Client nur sehr spät wenn überhaupt aufwacht und Anrufe signalisiert oder verpasste Anrufe anzeigt.
Heute morgen zum Beispiel hat es 47 Sekunden geklingelt, bevor das Smartphone reagiert hat. Das war der erste Anruf nach der Nacht, der Client wurde also sehr lange nicht benutzt
Mit Android dauerte es schon immer zwischen 6 und 14 Sekunden bis der Client Aktivität zeigt. Bei den 50er Versionen teilweise bis zu 30 Sekunden. Einige Kollegen meckern sich deswegen seit Monaten zu tode. Wird hoffentlich bald mit dem Offline-Modus und der Verbesserung der Hintergrund-Synchronisation Geschichte sein.
@jlorenz, ist der Ladebildschirm “wir bereiten alles vor” wirklich bei jedem Kaltstart gewollt, oder geht es gerade technisch nicht anders? Denn Offline Mode bedeutet für mich, dass der Client den letzten Zustand cached und dann bei Internet im Hintergrund die Daten synchronisiert. Demnach sollte der Ladebildschirm eigentlich nur beim absolut aller ersten Aufruf der App erscheinen.
Gibt es eine Zielversion, mit der die Startgeschwindigkeit und das Synchronisationsverhalten der mobilen App verbessert wird? 1-3 Sekunden nach dem Desktop Client sind okay, aber im Mittel bis zu 14 Sekunden später ist schon sehr grenzwertig. Zu wissen, dass aktiv dran gearbeitet wird und absehen zu können, wann man diese Verbesserung merken wird, wäre hier bereits super hilfreich.
Übrigens ist die Ladezeit unter Windows 10 (20H2) auch erheblich schlechter geworden. Bei mir dauert es 26 Sekunden bis der Client bedienbar ist. In dieser Zeit friert er bei Klick ein. Das gleiche passiert mir auch unter macOS 11.4.
Hier das Verhalten unter Windows:
Und auch hier wird mir erstmal angezeigt, dass ich kein Telefon hätte.
Und hier unter macOS:
Hallo zusammen,
@b.schliekmann: Wie genau ist denn dein Setup, und welches Gerät klingelt verspätet?
@noses: Das sollte nicht so sein. Kannst du bitte mal den Debug Modus in der App aktivieren und mir Logs senden wenn dieses verzögerte Klingeln auftritt. Bitte auch mit möglichst genauen Zeitstempeln WANN das passiert, dann fällt es mir mit der Analyse leichter.
@hazington:
Zuerst macOS und Windows:
Das ist definitiv ein Bug und nicht das erwünschte Verhalten. In unseren Test Setups startet das sehr viel schneller. Bitte Debug Modus aktivieren, auf beiden Plattformen die App neu starten und mir zusenden, vielleicht kann ich so schnell eine Ursache finden.
Android:
Was passiert bei Kaltstart?
- Android startet die App und lädt den Splash Screen. Das ist das pascom Logo ohne Text.
- Unser Prozess ist betriebsbereit und kann anfangen Dinge zu rendern. Das ist der Moment in dem der “Wir bereiten alles vor” Bildschirm erscheint, da wir bei einem Kaltstart zuerst noch das lokale Datenmodell aufbauen müssen. Hier findet z. B. auch eine Datenbankmigration statt, falls sich bei einem Update auf eine neue Version was ändert
- App ist betriebsbereit. Ab diesem Zeitpunkt sieht man das normale UI und kann die App bedienen, der Login erfolgt im Hintergrund. Hier ruckelt es noch, daran arbeiten wir bereits.
Zum Thema “Startgeschwindigkeit der mobilen App”:
Da du die ganze Zeit auf dem Kaltstart-Thema herumreitest:
Natürlich arbeiten wir immer daran, das die App möglichst schnell startet und sich möglichst schnell anmelden kann. Offline Mode ist einer der Schritte in diese Richtung.
Aber: Wenn die Mobile App komplett geschlossen ist und erst starten muss, wird sich “1-3 Sekunden nach dem Desktop Client”, der ja bereits gestartet und verbunden ist, nicht realisieren lassen. Alleine schon weil die Apple und Google Push Infrastruktur hier schon mehrere Sekunden braucht, um den Push auszuliefern. Und erst wenn der Push angekommen ist, kann es mit dem App Start weitergehen.
In Szenarien, in denen man das Handy als Tischtelefonersatz verwenden möchte, empfehle ich die Lektüre dieses Dokumentationsabschnittes. Insbesondere Docking-Stationen und “App im Vordergrund behalten” ist bei uns auch bei Kollegen die viel telefonieren sehr erfolgreich im Einsatz. Das eliminiert halt alle Push und Verbindungslatenzen.
Grüße,
Jan
macOs und Windows: Log-files
Mache ich im Laufe des Tages und hänge die Logfiles hier an.
Android: Eingehender Anruf
Mir geht es gar nicht darum groß drauf rumzureiten. Es wird jedoch von nahezu allen Kollegen als enormes Problem empfunden. Die Workarounds habe ich den Kollegen mitgeteilt noch bevor es die Dokumentation gab. Realität ist aber: Keiner macht es, weil man es von WhatsApp und Co anders kennt und stattdessen ärgert man sich fürchterlich und lautstark darüber. Ich möchte das ganz wertungsfrei an euch weitergeben, da der Normaluser kein Verständnis für Workarounds und technische Limitierungen hat und stattdessen alles beschissen findet, was nicht so läuft, wie er es haben möchte oder von anderen Anwendungen kennt, selbst, wenn diese einen ganz anderen Kontext haben.
Das wird nicht nur bei meinen Kollegen aus dem Vertrieb so sein, sondern vermutlich auch bei vielen anderen. Ich bin weiterhin mit Pascom zufrieden und spüre mit jeder Version, wie die App besser wird. Wir nutzen eure Produkte mittlerweile auch schon einige Jahre und ich habe mich bewusst und nach dem testen von über 50 anderen Produkten weltweit für euch entschieden.
Android: Kaltstart "wir bereiten alles vor"
Kann es sein, dass ihr einen RAM Cache benutzt? Denn sonst könntet ihr doch die Datenbank-Version ebenfalls cachen und nur bei Änderung den Index erneuern. Dadurch wäre das Verhalten bei kalt- und warmstart identisch. Grundsätzlich finde es merkwürdig, dass der Index bei jedem Kaltstart erneuert wird. Dieser Startvorgang ist ein Teil der gesamten Latenz, auch bei eingehenden Anrufen. Könnte man diesen auf wenige Millisekunden reduzieren (was ich für realistisch halte), dann sollten auch eingehende Anrufe zügiger ankommen.
Android: Ideen
Ein großes Problem ist doch, dass die App im Hintergrund verschwindet und irgendwann aus dem RAM fliegt. Was wäre, wenn ihr eine Benachrichtigung erstellt, welche alle 10 Minuten per Push aktualisiert wird und die App dadurch zwingt offen und vorne zu bleiben? Klar zieht das Akku, aber wenn es optional ist, ist es eine Überlegung wert.
Ein anderer Ansatz könnte doch eine Bild-in-Bild Implementierung sein. Dann haben Benutzer, welche die App sofort brauchen, die App eben als Bild-in-Bild über anderen Elementen.
Dritter Ansatz könnte ein Widget sein. Wenn es ein einfaches Widget gäbe, welches eingehende Anrufe und den Dialer-Status anzeigt, dann könnte man doch auch damit die App im Vordergrund halten.
Vierter Ansatz: Ihr spielt eine Art lokalen Dauer-Live-Stream auf dem Handy ab (evtl. Bild-in-Bild). Dadurch könnte verhindert werden, dass das Handy in standby geht, denn bei Videoplayback bleibt das Display an.
Das sind alles keine sauberen Lösungen, aber wenn auch nur eine davon funktioniert, dann kann man Nutzern die Möglichkeit geben selbst zu entscheiden, ob er einen erhöhten Akku-Verbrauch in Kauf nimmt, um dafür die Latenz auf ein absolutes Minimum zu reduzieren. Im Grunde genommen laufen alle Varianten auf folgendes hinaus:
1.) Der allgemeine Kaltstart muss auf Millisekunden reduziert werden
2.) Es muss verhindert werden, dass die App in den Hintergrund gerät
3.) Es muss ggf. verhindert werden, dass das Smartphone in den Standby geht
Wie man diesen Modus nennen soll, weiß ich nicht. Ich glaube aber, dass man das so in den Griff bekommen kann.
Edit:
Ein weiterer Ansatz, den ich gerade teste und auch etwas für eure Dokumentation sein könnte. Seit Android 8.1 kann man eine App anpinnen. Eine angepinnte App bleibt dauerhaft offen.
Pin & unpin screens - Android Help (google.com)
Um zu verhindern, dass das Display Timeout greift, könnte man noch eine App wie diese nutzen (oder Pascom integriert das für Pascom, damit Pascom offen bleibt):
pascom Client v76 BETA (76.D1826)
German
- Beim Starten wird nun nicht mehr fälschlicherweise “Sie haben kein Telefon” angezeigt
- Android: Problem mit Pairing behoen
- Diverse Glitches im Zusammenhang mit dem Offline Modus behoben
English
- Don’t show “You have no Phone” during startup
- Android: Fixed a problem with pairing
- Fixed various smaller glitches in offline mode
Falls ich es übersehen habe: Ist es gewollt, dass man sich als Benutzer nicht mehr abmelden kann?
Pascom 19.16 onsite, meinem Benutzer sind 2x Snom, 1x DECT und der Mobilclient zugeordnet.
Im Optimalfall klingeln alle Telefone gleichzeitig.
Ich nehme dann zum Beispiel den Anruf an einem der Snoms an, alle anderen hören auf zu klingeln.
Nur der Mobilclient (neueste Beta, mittlerweile auf Android12, passierte aber ebenso auf 11) klingelt munter weiter. Teils bis zu 30 Sekunden.
Gerade habe ich einen Anruf am Snom entgegengenommen, Mobilclient klingelt weiter. Mobile liegt neben mir, ohne weitere Berührung kommt plötzlich ein Besetztzeichen aus dem Telefon und es steht: “Anruf könnte nicht aufgebaut werden.” im pascom-Client.
Gestern ist mir aufgefallen, dass ich den Mobilclient während eines Gesprächs in den Hintergrund gepackt habe. Als ich die App im Vordergrund bedient habe hat zusätzlich der Pascom-Client reagiert und hat einen weiteren Ruf aufgebaut zu einer Gruppe.
Ich stelle jetzt meist auf GSM um. Das funktioniert zuverlässiger. Leider ohne Anzeige der Rufnummer.
Im MacOS Client Journal wird der Angerufene nicht korrekt entsprechend dem Telefonbuch (importierter Apple Kontakt) angezeigt.
Wenn ich vom gleichen Kontakt angerufen werde erscheint der Eintrag korrekt.
Bei Android Gesprächen fehlen Gelegentlich die Label. Vor allem dann, wenn der Pascom Client aus dem Hintergrund aufwacht und neu synchronisiert. Dies passiert nicht immer und ist nicht gezielt reproduzierbar, jedoch passiert es schon bei rund jedem 3. bis 4. Anruf. Cache leeren und resynchronisieren brachte keine Besserung.
@cbirkner,
wir brauchen noch mehr Informationen zu deinem Problemfall. Habt ihr in diesem Screen “Anmeldung fehlgeschlagen, ihre Zugangsdaten haben sich geändert…” versucht, euch mit dem jeweils aktuellen Passwort einzuloggen oder direkt “Reset” geklickt?
Ausserdem wäre es fürs Debugging sehr hilfreich die Serverlogs mit anzuschauen. Wenn du Zugriff darauf hast, kannst du mir bitte per PN die Server-Xmpp-Logs schicken.
VG
Jonas
pascom CLient v76 BETA (76.D1835)
German
- Video-Encoding wieder auf Software umgestellt
- Beim Abmelden aus einem Arbeitsplatz bleiben nun keine Anrufe oder Anrufbenachrichtigungen mehr “hängen”
- Android: Pairing Problem in bestimmten Netzwerkumgebungen behoben
- Android: Stabilität beim Aufwachen aus dem Hintergrund verbessert
- iOS: NAT64 Erkennung verbessert
- Windows: Kompatibilität zu bestimmten Webcams verbessert
English
- Video-Encoding now uses software encoders again
- No calls are left over when logging out from a location
- Android: Fixed a pairing problem in specific network environments
- Android: Improved stability when waking up from the background
- iOS: Improved NAT64 detection
- Windows: Improved compatibility to some webcams
Sporadisch ist das Journal leer - konnte es leider nicht direkt reproduzieren.
Nach dem Start im DebugMode war es dann wieder da…
Nach dem Standby verbindet sich der Client wieder, jedoch steht im Journal dann noch der Text, dass man offline sei. Beim Klicken auf “Über pascom client” ist der Client dann abgestürzt. An wen darf ich die pascomSupportInfo.zip schicken?
Servus, seit gestern haben wir auf zwei iOS iPhones das Problem, dass der Client sofort nach Start abstürzt und verschwindet.
Unpair hat er mitbekommen, lässt sich aber auch danach nicht starten.
Ich habe die iOS App gelöscht und dann via TestFlight neu installiert. Jetzt geht es.
Heute Nachmittag habe ich auf dem Windows 10 Desktop die App 76.D1835_474fc0e installiert, seitdem ist sie mir ein paar mal abgestüzt, einmal im Gespräch via Softphone, sonst bei aktionen wie zB Rufannahme.
Ich habe da ne Support Info, soll ich die irgendwo hinmailen? 
Grüße
Sebastian