redline

Hab's gefunden: PBXCall.PhoneCallListEntry.Delete Ein weiterer VB-Block vor dem Auflegen mit der Funktion und der Ruf ist nicht mehr ersichtlich! Thema abgeschlossen, herzlichen Dank @jodost

So... Das Problem tritt in der Tat nicht auf, wenn das System korrekt verwendet wird. Ein Wählen via F11 landet nicht bei der internen Durchwahl. Das Problem tritt auf, wenn die AnwenderInnen die Nummer (unvollständig) kopieren und ins Rufnummernfeld einfügen. 🙄 Ein erster Test meiner Regel war nicht erfolgreich, das lag aber primär daran, dass ich das end if vergessen habe. Außerdem ist die korrekte Funktion PBXCall.DialedNumber. Das Script sieht daher nun so aus: if PBXCall.DialedNumber = "49" then UseExit = 0 else UseExit = 1 end if Funktioniert wie gewünscht, ABER leider wird der eingehende Anruf nun doch in der Liste entgangener Anrufe angezeigt. Ist es möglich das zu unterbinden? Das Ablehnen soll völlig still im Hintergrund erfolgen.

Hi, ich muss mir das genaue Fehlerbild tatsächlich nochmal anschauen, ich habe es so weitergeleitet bekommen und nur in der Theorie durchdacht. Ob nun wirklich F11 gedrückt wird (wovon ich ausgegangen bin), muss ich nochmal prüfen. Vielen Dank für den Denkanstoß... Ich hätte die Regel nun wie folgt aufgesetzt: 'Wenn keine Ziffer nach der Durchwahl erkannt wird, wird die Regel übersprungen 'Ansonsten der Ruf abgelehnt if PostDialingDigits = "" then UseExit = 0 else UseExit = 1 Sollte korrekt sein, oder? Teste es bei Gelegenheit mal. EDIT: Ich hab es mir zu kompliziert gemacht.. Du sagstest ja schon, einfach "PBXCall.CalledPartyNumber" auf die 49 prüfen... Also: 'Wenn gewählte Rufnummer = Durchwahl (49) ist, wird die Regel übersprungen 'Ansonsten der Ruf abgelehnt if PBXCall.CalledPartyNumber = "49" then UseExit = 0 else UseExit = 1

Hallo Zusammen, traurig aber wahr. Im Betreff genanntes Problem passiert wohl häufiger als man es sich vorstellen mag. Wenn interne Kolleginnen und Kollegen eine Rufnummer mit deutscher Landesvorwahl markieren, dabei aber das + vergessen und wählen, wird der interne Benutzer mit Durchwahl 49 angerufen. Dies kostet Arbeitszeit und der betroffene, genervte Mitarbeiter möchte gerne eine neue Durchwahl. Ich würde das Problem aber gerne technisch lösen und habe mir überlegt dass es ja prinzipiell funktionieren müsste wenn via CallRouting geprüft wird, ob hinter der "49" noch weitere Ziffern gewählt wurden. Sofern dies der Fall ist, kann es sich nicht um einen gewünschten internen Anruf handeln und das Gespräch soll (ohne Benachrichtigung auf Telefon/Client) abgelehnt werden. Der Kollege wird hoffentlich zeitnah seinen Fehler bemerken und die vollständige Rufnummer wählen. Weiß jemand, wie so eine Regel aussehen müsste? Danke!

@RaKinvielen Dank! Ja, in der Tat ist die überwiegende Mehrheit L615/L640. Es gibt allerdings auch schon L62/L64 (welche V1 R5.6.1) installiert haben sollten. Diese sind aber wohl noch nicht für die 13.10 (und damit auch 13.15) freigegeben. Gab es signifikante Änderungen, sodass es hier zu Problemen kommen wird? Andernfalls wäre meine Vorgehensweise wie folgt: -FW Update der L6XX auf V3 R0.42.1 -Swyx Update auf v13.15 -FW Update der L6X auf V1 R6.3.0 Ich gehe zwar davon aus, dass unter ftp://ftp.swyx.com/pub/fw13 die L615.img und L640.img die aktuellste 0.42.1 ist, aber gibt es grundsätzlich eine Möglichkeit dies zu ermitteln, ohne via SwyxAdministration die Dateien im Reiter Firmware-Aktualisierung einzulesen? EDIT: Habe mir meine Frage selbst beantwortet. Mit Notepad++ geöffnet, steht die Versionsnummer in der ersten Zeile:

Hallo Zusammen, ein Kunde setzt noch v11.52 ein und die SwyxPhones haben FW V3 R0.40.0 installiert. Nun bereite ich derzeit ein Update auf 13.15 vor und überlege, wie ich die aktuelle Firmware-Version installiere. Laut https://service.swyx.net/hc/de/articles/4417873616530-Freigabe-SwyxPhone-Firmware-V1-R6-3-0-für-L62-L64-L66-Tischtelefone ist die aktuelle Version nur für V13 freigegeben. Kann mir jemand sagen ob die Version trotzdem mit der 11er kompatibel ist, sodass ich im Vorfeld ein FW-Update durchführen kann? Alternativ sehe ich als einzigen Weg die Installation auf v13.15 und anschließendem FW Update. Können sich in diesem Fall die Telefone denn trotz der alten Version zumindest anmelden und via FTP die Firmware-Daten ermitteln? Danke und viele Grüße

Hi! wir würden gerne die Rufaufschaltung verwenden, stellen nun jedoch fest, dass der Agent keine Kenntnis darüber hat, wenn das Gespräch abgehört wird. Laut https://help.swyx.com/cpe/12.30/Client/Swyx/de-DE/index.html#page/help/chap_features.13.65.html gibt es keine "Rufsignalisierung", also keine Anzeige, dass der Supervisor gerade mit DTMF Abfrage einen Anruf startet, was noch in Ordnung ist... Aber dass ein Abhören völlig unbemerkt erfolgen kann, finde ich datenschutzrechtlich etwas bedenklich. Kann dieses Verhalten angepasst werden? Ein kurzer Beep, wenn mitgehört wird, wäre klasse. Ggf. lässt sich dies per CallRouting realisieren? Viele Grüße

Hey jodost! Vielen Dank für deinen Input! Ich werde mir das nochmal durch den Kopf gehen lassen.... Version 13.10 steht ja kurz bevor, vielleicht warte ich das Update noch ab....

Hallo, ich benötige einmal Informationen zu einem Rollback auf eine alte Swyxware Version. In diesem Artikel hat Enreach bereits das Prozedere bei der fehlerhaften 11.40er Version genannt. Zitat Wie verhält sich das nun, wenn eine neue Version schon mehrere Tage im Einsatz ist. Ich nehme an, die aktualisierte Datenbank kann nicht runtergestuft werden? Mit dem Backup einer älteren Datenbank gehen also definitiv Daten (z.B. Konfigurationsänderungen) verloren. Aber selbst wenn hier keine relevanten Daten dazu gekommen sind, gehen ja mindestens die Trace-Logs verloren. Gibt es weitere "lose Daten" die bei einem Downgrade verloren gehen (wie FAX-Dateien - wenn nicht in der DB gespeichert)? Können diese neuen Daten in die alte Version übertragen werden? Wie sieht es mit Lizenzen aus? Ich nehme an, die Lizenz der alten Major Version ist noch enthalten und damit lauffähig? Wie sieht generell das "best practise" (wenn man von best-practise sprechen kann) aus, wenn ein Downgrade nötig ist?

Also wenn du den ganzen Server bzw. die Datenbank wiederhergestellt hast, kannst du ja über die Administrationskonsole das Telefonbuch exportieren. Wenn du es über die Datenbank machen willst, brauchst du erst die interne UserID des Benutzers. Anschließend wäre die Abfrage in etwa so: SELECT [EntryID] ,[UserID] ,[Name] ,[Number] ,[SearchNumber] ,[Hide] FROM [IpPbx].[dbo].[PhoneBook] where UserID = *ermittelte ID* Die ID findest du zb via SELECT TOP (1000) [UserID] ,[Name] FROM [IpPbx].[dbo].[Users] where Name = 'Vorname Nachname' Aber das ist dann quasi die PLAIN Ansicht. LG

Hallo, seit unserem Update der SwyxWare auf Version 13.05.22383 bemerken wir, dass die Videotelefonie nicht mehr zuverlässig funktioniert. Es gab eine Situation, wo die Videotelefonie mit einem Kollegen möglich war (beide SwyxIT Versionen auf aktuellem Stand). Dies lässt sich jedoch nicht mehr produzieren. Das Verhalten ist immer identisch: 1. Anruf: lokales Video öffnet sich jeweils für beide Teilnehmer, das Video des Gesprächpartners jedoch nicht 2 Anruf: es öffnet sich gar kein Videofenster, im Client ist "Video nicht möglich" zu lesen Gab es diesbezüglich Änderungen? Bzw. ist das Problem bereits jemandem aufgefallen? Welche Client-Logs können bei der Analyse helfen? Firewall konnte bereits ausgeschlossen werden. EDIT: Ergänzung, die Ereignislogs werden mit folgendem Event zugemüllt Quelle: Client Line Manager ID: 8192 In dem genannten Temp Ordner sind dutzende .dmp Dateien vom heutigen Datum....

Wie ich oben bereits geschrieben habe, hatte ich bereits den SwyxIt Client in der Version 12.41 ausprobiert, was ebenfalls erfolglos war. Am Wochenende haben wir nun die NetPhone Anlage auf Stand 12.41 gebracht und ich habe es just for fun mit dem NetPhone Client v12.41 ausprobiert. Es funktioniert.... Ich weiß nicht wieso, aber mir ist es egal. Ich prüfe das ganze jetzt bei allen anderen Betroffenen und dann ist das Thema hoffentlich erledigt! Danke und viele Grüße

Es gibt Neuigkeiten... Am Wochenende habe ich nochmals ein Update durchgeführt. Von der 12.40 auf die 12.41. Was soll ich sagen, anschließend hat die SwyxApp funktioniert. Ich kann mir das nur durch zwei Möglichkeiten erklären: 1. In der 12.40 gab es einen Bug oder aber die Installation war korrupt 2. Ein Umstellen von RemoteConnector auf internen Betrieb ist nicht "einfach so" möglich und ein Ausführen des Konfigurationsmanagers (wie er nach einem Update kommt) ist notwendig um die Einstellungen fest zu aktivieren. Ich tippe auf letzteres. Der Server wurde zwischendurch auch nicht neugestartet. Eventuell waren die Einstellungen einfach noch nicht aktiv. Ich freue mich jedenfalls, dass nun alles funktioniert und ich keine Schuld trage Dank an alle Beteiligten!

Hi, vielen Dank für deinen Beitrag! Ein Port-Forwarding kommt intern nicht zum Einsatz, da der Server direkt in der App hinterlegt ist und über das VPN erreichbar ist, kommt eine direkte Verbindung zu Stande. Auf dem Swyx Server ist Port 9101 offen. Port 16203 Ist zwar auf dem damaligen RemoteConnector Server noch geöffnet, kommt ja aber nicht mehr zum Einsatz. Auch wenn ich die Firewall kurzfristig auf dem System deaktiviere, habe ich keine Verbindung. Wie kann ich die Verbindung zu den Pushservern explizit testen? Ein Telnet auf api.push.apple.com 443 und fcm.googleapis.com 443 liefert eine Verbindung - damit sollte das abgehakt sein? Muss der Swyx Push Notification Service mit dem gleichen Dienstkonto laufen, wie die anderen Swyx-Dienste, oder bleibt das "Lokales System"? EDIT: Um meine Frage kurz selbst zu beantworten: Lokales System ist richtig.

Also ich hab es nochmal probiert. Wie gesagt, lief unsere App vorher bereits extern über den RemoteConnector. Zertifikate usw. sind daher noch vorhanden, sollten aber nicht stören. Den Remotezugriff habe ich deaktivert: Gebe ich in der App den NetPhone Server als internen Server an (egal ob IP oder DNS), lädt mein Avatar (Status grün) und ich bekomme nach einiger Zeit die bekannte Fehlermeldung. Das Debug-Log der Swyx App liefert folgenden (relevanten) Eintrag: 2021/07/01 16:45:52 [Debug] [main] [PJSUAAccountService.swift:376] pjsuaLibraryManagerRegistrationChangedState(_:) > RegistrationChangedState: sip:%LANGE-GUID%7D@domain.local;transport=tcp | Service Unavailable (503) | Offline (OFFLINE) | Expires = -1 2021/07/01 16:45:52 [Debug] [main] [PJSUAAccountService.swift:380] pjsuaLibraryManagerRegistrationChangedState(_:) > handleError: sipError(code: Swyx_Mobile.SipStatusCode.serviceUnavailable, message: nil) 2021/07/01 16:45:52 [Debug] [main] [DefaultSupervisor.swift:112] reportServiceError(sender:error:) > Async error handling disabled, ignore error: sipError(code: Swyx_Mobile.SipStatusCode.serviceUnavailable, message: nil) Auch ohne VPN im lokalen WLAN ist das Fehlerbild identisch. Ereignisanzeige schweigt sich aus. Könnte dieser Beitrag relevant sein? https://service.swyx.net/hc/de/articles/360009436040-Swyx-Mobile-for-iOS-und-iOS-13 Im Artikel steht leider nicht, wie sich dieser Fehler äußert (außer das keine Verbindung möglich ist). Ich will nicht, ohne sicher zu sein, die Zertifikate austauschen.