KlausP

Doch. Je nach iOS Version wird eine Rufsignalisierung im iPhone vom CallKit nach einer Minute hart abgebrochen. Bei neueren iOS Versionen ist dies definitiv so, ältere sind da noch kulant.

Da solltest Du besser deinen Vertriebspartner/Admin befragen, welcher die SwyxWare installiert und eingerichtet hat. 22 13:57:30.390 001318 Info SrvScript 0000027220CF2EE0 00000561 SPBXScriptVbs::OutputTrace () Rule result: Wahr 22 13:57:30.390 001318 Info SrvScript 0000027220CF2EE0 00000561 SPBXScriptVbs::OutputTrace () End GSE Script (Rule: rulePreProcessing) 22 13:57:30.390 001318 Info SrvScript 0000027220CF2EE0 00000561 SPBXScriptVbs::OutputTrace () Call is handled by PreProcessing rule Normalerweise macht das SwyxWare PreProcessing gar nichts. Aber bei deiner Installation ist dieses durch ein eigenes CallRouting Skript ersetzt worden und führt zum schnellen Abbruch. Im "Global Scope" der SwyxWare DB (MMC oder SCC, Option Dateien) befindet sich also ein Skript namens "rulePreProcessing.vbs". Lade dir dieses herunter und suche nach Kommentaren, welche Hinweise auf den Ersteller geben.

Welche SwyxWare Version ist denn aktuell im Einsatz? Im Prinzip funktionieren auch ältere Clients mit einer neueren SwyxWare. Aber natürlich nur eingeschränkt, da alte Clients die neuen SwyxWare Features nicht kennen. Mit einer SwyxWare 13.29 gab es jedoch Änderungen bzgl. der Anmeldung der Clients. Alte Clients funktionieren weiterhin, dürfen/können aber nicht mehr ihr Passwort ändern. Insofern würde ich raten nach dem Update auf 14.00 auch die Clients schnellstmöglich auf den aktuellen Stand zu bringen. Der Sprung von 13.05 auf 14.00 ist dann doch recht groß.

SwyxWare always answers to a Re-Invite. Either positive (200 OK) or negative (4xx). If you see only a 100 Trying, then you should contact your reseller and open a support ticket.

Ich hatte mal ein Windows 2016 Inplace auf Windows 2019 aktualisiert. Schien erstmal zu laufen, aber die SwyxWare war nicht erreichbar. Hatte sich schnell herausgestellt, daß der Windows Netzwerktreiber zu lange für die Initialisierung brauchte. Die SwyxWare hatte sich also auf 127.0.0.1 als eigene Adresse gebunden, da zum Startzeitpunkt keine andere IP verfügbar war. Netzwerktreiber neu installiert und die SwyxWare lief. Nach zwei Wochen gab es aber durch den Ausfall des VMware Servers ein hartes Ende, und die SwyxWare wollte fortan nicht mehr starten. Ich stimme daher mit meinen Vorrednern überein, immer ein neues Windows aufsetzen, und dann die SwyxWare zu importieren. Alles andere sehe ich mittlerweile als großes Risiko an.

Hast Du mal versucht alle "Soundverbesserungen" abzuschalten? Gerade seit Windows 11 bereiten diese Features immer mehr Probleme, als daß diese etwas verbessern. Dies gilt nicht nur für Windows selber, sondern auch für die "tollen" Treiber des PC/Notebook Herstellers bis hinunter zur "Audio Enhancement Unit" einer Intel CPU. Als aller erstes würde ich immer den "Exklusiven Zugriff" in den erweiterten Audioeinstellungen aller Devices deaktivieren. Und dann auch alle "Soundverbesserungen" welche man versteckt in denselben Untermenüs findet.

Wenn man sich mit einem SwyxIt! anmeldet, dann kann jeder Benutzer dieses im "Classic SwyxIt!" unter Einstellungen -> Benutzerprofil... -> Voice Box selber ändern. Voraussetzung ist natürlich ein SwyxIt! >= 13.27.

Das Problem hat primär mit den Veränderungen am Windows OS zu tun. Das SwyxIt! speichert sich die nötigen Skin-Elemente im jeweilen %TEMP% Ordner des Benutzers zwischen. Seit diversen Windows Updates ist Microsoft der Meinung, es müßte das %TEMP% Verzeichnis des Benutzers regelmäßig ausmisten. Dabei werden auch die zwischengespeicherten Skin-Elemente gelöscht, wodurch das SwyxIt! plötzlich in die Röhre schaut und nichts mehr aktualisieren kann. Ab einem SwyxIt! 14.00 liegt der Pfad nun unter %LOCALAPPDATA%. Bei älteren SwyxIt!'s kann man daher nur versuchen die erweiterte Datenträgerbereinigung auszuschalten.

Hast Du es jeweils mal mit dem Stern "*" versucht? Wirkt manchmal Wunder 😉