ich habe auf zwei Rechner den Pascom Client in der Version 81.R2017_94e5180 am laufen (einmal Windows 10, einmal Windows 11).
diese Version braucht auf beiden PCs recht lange (ca. 45 Sekunden), bis eingaben nach dem Start möglich sind. (Auch Aktionen wie Debug Mode aktivieren / deaktivieren sorgen dafür, dass der Client hängen bleibt). Wartet man in beiden Fällen etwas ab, fängt sich dieser wieder und man kann weiter machen. Die vorherige Version 80 war bedeutend schneller - diese war maximal fünf Sekunden nach Start einsatzbereit.
Ich habe bereits Support Info gespeichert, um diese einem der Pascom Mitarbeiter per PN zur Verfügung zu stellen.
Bei einem Kollegen am iOS Gerät wurde die App automatisch auf Version 81 aktualisiert - hier tritt nun das gleiche Problem auf.
Daraus resultiert auch, dass er mobil mehr oder weniger nicht mehr erreichbar ist, da die App zu lange braucht, um aufzuwachen / zu Synchronisieren bis es klingelt.
Der pascom Client versucht heutzutage seine Netzwerkumgebung besser zu erkennen. Hierzu ist es erforderlich das der Client seine eigene externe IP kennt, wofür wir STUN verwenden.
Leider hat sich herausgestellt, das es bei restriktiven Firewall-Konfigurationen zu delays kommen kann, die sich im von dir beschriebenen Verhalten Zeigen.
Bitte schalte in der Firewall den Port 19302 (TCP und UDP) zu den Google STUN Servern frei:
bei solchen Änderungen sollten die Informationen m.E. auch direkt ins Changelog, damit man sowas von vornherein weiß.
Ich habe die Firewall Regeln entsprechend angelegt, das Problem besteht aber weiterhin.
(beim aktivieren / deaktivieren vom Debugging tritt dies ja auch wie bereits erwähnt auf).
Ich habe eine neue Supportdatei erstellt, nachdem ich die FW Regeln angelegt habe. Diese Datei sende ich per PN.
Gruß
dst
Update: kann es sein, dass der Client die DNS Auflösung nicht über den DNS Server des Rechners, sondern über einen eigenen versucht? Das würde die weiteren Fehler im Log erklären:
stunresolve .Failed in pj_getaddrinfo(): gethostbyname() has returned error (PJ_ERESOLVE)
pjsua_core.c .Error starting STUN socket for stun2.l.google.com:19302: gethostbyname() has returned error (PJ_ERESOLVE)
Falls ja, wäre dies nicht gut, da in Restriktiven Umgebungen (wie unserer) nur über gewisse DNS Server die Auflösung erlaubt ist.
auch wir haben massive Probleme mit der v81 hier im Haus. Hier dachten wir erst das IOS 15 ist zickig.
Dann stellten wir fest, das die Windows Version extrem lange benötigt um die Chats zu aktualisieren. Und Unter Mac OSX stürzt der Client nachdem starten dann wieder ab.
bitte stelle sicher das die Firewall wie oben beschrieben konfiguriert ist und aktualisiere den Client gleich mal auf die eben veröffentlichte v82.R2028. (iOS wird etwas dauern, da der Client zuerst durch die Apple Prüfung muss).
mit den Firewall freigaben läuft es… Aber könnt Ihr nicht einen eigenen STUN Dienst in Eurer Cloud (Port 80/443) etablieren. Damit könnte diese “blöde” Regel wieder entfallen. Und Port 80/443 ist eh überall freigeben.
Nebenbei bemerkt ein Gastnetz einer Fritzbox lässt auch nur 80,443, 25,110,143 durch. Hier hat man dann auch “schlechte Karten”