Tom Wellige

Angenommen ich drücke in Deinem Call Routing die "1" und lande dann in einem Durchstellen Block. Stellt dieser dann direkt auf einen Benutzer zu, oder auf eine Benutzergruppe?
 
Wenn Du willst, dass das Umleitungen respektiert werden, wenn Du mittels Durchstellen Block auf einen Benutzer zustellst, musst Du auf der Parameter Seite des Blocks ganz unten "mit dem Call Routing des Ziels fortfahren" aktivieren.
 
Wenn auf eine Gruppe zugestellt wird, dann kannst Du der Gruppe bei Bedarf auch ein Call Routing geben.
 

Hallo,
 
das Swyx Forum ist kein offizielles Enreach Support Forum. Daher müüstest Du Dich mit Fehlermeldungen an Deinen betreuenden Partner, Deinen Distributor oder den Enreach Support wenden.
 
Du kannst das auch in die Enreach Community schreiben, sofern Du Enreach Partner bist.
 

Vom Call Routing aus kommst Du nur direkt an 
PBXCall.CallingPartyName PBXCall.CallingPartyNumber ran, wobei CallingPartyName ggf. durch das globale Telefonbuch gefüllt wurde.
 
Es gibt tatsächlich eine API, mit der Du an das globale Telefonbuch heran kommst, die Config Data Store API (CDS). Mit der solltest Du auch an das Beschreibungsfeld kommen. Da müüstest Dir Dir dann aber einen Wrapper selbst bauen, der in Richtung des Call Routings eine COM Schnittstelle zur Verfügung stellt, auf die Du dann mit VBScript zugreifen kannst.
 
Einen Ansatz dazu findest Du neben der Doku im CDS API Paket hier:
CDS User Status  
Auf der CDS API basiert auch das SwyxWare Powershell Modul auf.
 
Einen Ansatz hierfür findest Du in diesem Post:
Powershell Telefonbuch Export ohne Builtin User und Gruppen ? Wenn Du ein PowerShell Script hast, kannst Du das vom Call Routing aus einfach über eine der beiden folgenden VBScript Funktionen starten:
LaunchCmd LaunchCmdEx Bitte beachte hier jeweils den Link auf "Introduction" direkt über dem VBScript Code.
 
 
 
Du kannst natürlich auch wie bei meinem ersten Vorschlag den Namen im Telefonbuch ändern, und statt den Produktname an Ende zu setzen, ihn an den Anfang. Hierbei musst Du nur beachten, dass wenn Du z.B. nur nach einem "X" an erste Stelle des Namens suchst, Du auch alle Kunden erwischst, deren Name selbst mit "X" anfängt. Etwas eindeutiger wäre z.B. "X " (X Leereichen).
 
Im Variable auswerten Block müsstest Du dann
Left(PBXCall.CallingPartyName, 2) = "X " eintragen.
 

I assume you refer to the Visual Groups wallboard (type: user infor).
 
Here the blue dot shows the user who will receive the next call in the group. 
 
See also here: https://help.enreach.com/visualgroups/1.10/web/Swyx/en-US/index.html#page/help/chap_VisualGroups_Wallboards.5.2.html - Wallboard Types.
 

Wenn ich Dein Call Routing richtig verstehe, dann benutzt Du die 3 Bedingungsblöcke ohne dass Du da eine echte Bedingung eingetragen hast, sondern Du hast sie auf "In jeder Situation", "Für jeden ruf", "Zu jeder Zeit" konfiguriert. In diesem Fall kannst Du Dir diese Blöcke auch komplett sparen. Du musst eine Call Routing Regel die Du mit dem Regel Assistenten machst, nicht eins zu eins im GSE nachbilden.
 
Dann sehe ich, dass Du beim "Durchstellen" Block alle anderen Ausgänge bis auf "Nicht zugestellt" ausgebelendet hast. Das solltest Du nicht tun, weil Dein Call Routing nun in Zustände laufen kann, welche nicht bearbeitet werden (z.B. "Verbunden"). Wenn es Dir ohnehin nur um den Versandt der EMail geht, dann brauchst Du den "Durchstellen" Block auch gar nicht.
 
Damit die Alarmanlage nicht auf die Idee kommt mehrfach anzurufen (was in diesem Fall glaube ich Dein Problem ist, weil der Ruf nicht verbunden wurde), würde ich ein Call Routing wie folgt vorschlagen:
 
"EMail versenden" Block um die benötigte EMail zu verschicken "Ansage abspielen" Block nehmen und eine Ansage abspielen. Damit verbindest Du den Ruf und teilst der Alarm Anlage damit mit, dass Du den Ruf empfangen hast  
 

Schau mal ob Du eine Datei
 
C:\ProgramData\Swyx\license.dat  
findest. Wenn ja, lösche sie.
 

Da ich die kommenden Tage mit anderen Dingen komplett dicht bin, habe ich die Entscheidung gerade selber gertroffen (Variante 1 - NULL) und eine neue Version der Persistenten Variablen erstellt, die Deinen Feature Request enthält.
 
 
 

Oops, das hatte ich vergessen zu beatworten.
 
Das kannst Du über das PBXConfig Objekt abfragen:
 
 
 

Hallo Marcel,
 
spontan sehe ich da kein offensichtliches Problem. Wenn Du willst, kannst Du mir ein aktuelles Server Trace schicken (per Forum Nachricht, bitte nicht hier öffentlich posten), dann werfe ich da mal einen Blick rein. Die PVs erzeugen einiges an Trace Ausgaben mit deren Hilfe das Problem schnell zu finden sein sollte.
 
Hier findest Du eine Anleitung wo das Trace zu finden ist, und wie Du es für Dich ganz einfach lesbar machen kannst.
 

Variablen gelten grundsätzlich nur für den aktuellen Ruf. Wenn Du eine Variable A in Deinem Call Routing Skript hast und zwei Rufe befinden sich gerade im Call Routing dann gibt es in diesem Augenblick 2 Versionen der Variable A, jeweils eine für jedes der beiden Skripte. Ebenso verlieren Variablen ihren Inhalt wenn ein Ruf beendet wird.
 
Mittles der persistenten Variablen kannst Du diese beiden "Einsckränkungen" (sofern man das so nennen möchte) umgehen. Für Deine aktuelle Frage werden die aber nicht benötigt.
 
Zwischen den "Warteschlange erstellen" Block und den "Warteschlangen-Attribute setzen" Block kannst Du einen "Warteschlangen-Attribute abrufen" Block setzen. Mit diesem Block kannst Du die aktuelle Anzahl der Rufe in der Warteschlange in eine Variable speichern lassen und damit dann die durchschnittliche Wartezeit berechnen und setzen (Feld: Durchschnittliche Rufdauer).
 
Ob Du damit allerdings realistische Werte für die Wartezeit errechnest musst Du Dir selber beantworten. Wenn Rufe immer in etwa gleiche Lange warten und bearbeitet werden dann kommt Dein Wert wohl einigermassen hin. Anonsten eher weniger. Dann wird entweder eine deutlich zu kurze oder zu lange Wartezeit angesagt. Letzteres ist nicht so schlimm. Wenn Du dem Anrufer aber sagst, dass er vermutlich in 2 Minuten drann kommt und er dann aber 20 Minuten wartet ist das nicht Stimmungsaufhellend.
 
In meinen Augen macht das Wartezeit Feature in der Warteschlange nur dann wirklich Sinn, wenn Du dort umfangreiche Statistiken hinterlegst, wie lange Anrufer abhängig von Wochentag und Uhrzeit bei Dir warten. Diese Werte kannst Du aus den Call Details Records der SwyxWare ermitteln, in geeigneter Form (eigener VBkript Code) in der Call Routing Regel hinterlegen und dann passend zum Wochentag und Uhreit verwenden.
 
Diesen Aufwand muss man in meinen Augen schon treiben, wenn man ansatzweise vernünftige Wartezeiten ansagen möchte. Wenn man diesen Aufwand nicht treiben möchte, dann sollte das Wartezeit Feature nicht verwendet werden. Dazu dann einfach beide Ansagen auf "keine Auswahl" stellen.
 

This function doesn't work in a group call routing at the moment. It uses "g_PBXConfig.GetUserByAddress" which is not working in a group context. 
 
As stated on the IsGroupLoggedOff page you can use the PBXGroup.IsLoggedIn in a group call routing script. 
 
The usage is as simple as with the previous function:
 
if not IsGroupLoggedOff ("11") then ... end if  
respective:
 
if PBXGroup.IsLoggedIn then ... end if  
 
Or when being used in an Evaluate block (Variable auswerten):
 

 
 

Hi Mitesh,
 
you need to enable "ASP" (Active Server Pages) in your IIS. This page explains how this can be done:
 
https://learn.microsoft.com/en-us/iis/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/classic-asp-not-installed-by-default-on-iis
 

Habe ich Dich richtig verstanden, dass Du die Durchwahl ermitteln möchtest, welche angerufen wurde? 
 
Und für das Call Routing hast Du einen Benutzer angelegt, dem Du den kompletten Durchwahlbereich  12345 000 - 12345 999  als externe Rufnummern zugewiesen hast?
 
 
Wenn dem so ist:
 
Mittels PBXCall.CalledPartyNumberCanonical kannst Du die externe Rufnummer ermitteln, die angerufen wurde.
 
Davon musst Du nun die letzten drei Ziffern kopieren und an diese den Ruf durchstellen. Im Durchstellen Block könnte dann das hier als Ziel stehen:
 
= Right(PBXCall.CalledPartyNumberCanonical, 3)  

Hallo,
 
es ist richtig, dass bei Gruppenrufen das Call Routing der Gruppenmitglieder grundsätzlich nicht berücksichtigt wird.
 
Der Grund dafür ist ein ganz einfacher: stelle Dir eine parallele Rufzustellung in der Gruppe vor, und es kämpfen plötzlich sämtliche Call Routings aller Gruppenmitglieder darum, den Ruf zu behandeln.
 
Was Du machen kannst/musst, ist das Call Routing der Gruppe so abzubilden, dass es das Call Routing der Gruppenmitglieder weitestgehend nachbildet.
 

Hi Jack,
 
I am not aware of any reasons why it shouldn't. It uses plain ECR functionality which haven't changed in years within SwyxWare.
 

Hi,
 
the current version of that broken link you mentioned is this one:
 
https://service.swyx.net/hc/en-gb/articles/360011686580-INFO-SwyxIt-Client-SDK
 
It provides some basic information about the Client SDK and download links to the different versions. I have added this link also to the post you mentioned.
 
I have just figured that the links within the above given link are also broken. Basically you can fix them yourself by replacing "swyx.de" or "swyx.com" by "enreach.de" in those links. 
 
So the working download link to the latest Client SDK is this one:
 
https://www.enreach.de/download.php?loc=extern&filen=SwyxItClientSDK_v12.10.0.0.zip
 
 
Unforatunately I can't help you with your question.
 

Him
 
I was on vacation and am only now able to answer your question. 
 
Beside having the list of numbers to connect emergency calls to in somewhere in the code, e.g. in a VBScript array, I would use two Persistent Variables to hold the current phone number and the week number for that phone number
 
So when a calls comes in, you first check if the current week number is equal to the one stored in the persistent variable. You can get the current number of the week with DatePart:
 
Dim nWeek nWeek = DatePArt("ww", Now)  
If they are equal you just connect the call to the number stored in the other persistent variable.
 
If they are not equal, you take the next number from the list, store it into the persistent variable, store the current week number as well in the persistent variable and connect the call to the new phone number.
 
 
Is that enough to get you going?
 

Definitiv!
 
 
Der Status kann nur abgefragt werden, wenn zwischen allen beteiligten Benutzern die gegenseitige Statussignalisierung konfiguriert ist. Das gilt selbstverständlich auch für Deinen Call Routing Benutzer
 
 

Du kannst Dir die Datei direkt aus der SwyxWare Datenbank herunter laden. Dazu musst Du nur wissen, unter welchem Benutzer Du sie aufgenommen hast, und Du brauchst Zugriff auf die SwyxWare Administration.
 
In der Administration öffnest Du die Eigenschaften des Servers, gehst auf die Dateien Seite, und klickst auf Bearbeiten...
 

 
 
Nun stellst Du den Filter auf Benutzerdateien anzeigen, wählst Deinen Benutzer aus, markierst die Datei die Du herunterladen möchtest und klickst auf Speichern unter...
 

 
 

Die "PostDialingDigits" waren auch mein erster Gedanke. Da ich aber nicht wusste, ob an dem Telefon immer jemand ist, der auch umschalten kann, habe ich mich für das Umschalten wie oben entschieden. Das erfordert nicht, dass jemand am Telefon sitzt und per Namenstaste umschaltet.
 
Was Deinen Code angeht: da Du ja von einer Namenstaste aus wählst, d.h. per Blockwahl, brauchst Du im Skript nicht mehr max. 3 Sekunden darauf zu warten, ob Du alles zusammen gesammelt hast. Es kommt ja immer in einem Rutsch und es wird nicht von Hand nachgewählt.
 
Was das Problem des setzens der Nummer angeht: ich habe das gerade bei mir nachstellen können und auch bereits als Bug gemeldet.
 

Wie wäre es mit einer einfachen Call Routing Regel bei dem Benutzer, die den Status auf "abgemeldet" prüft und den Ruf dann auf die gewünschte Gruppe zustellt.
Diese Regel sollte dann über allen anderen Regeln in Liste der Call Routing Regeln stehen.
 

 
 

Klar, das geht natürlich auch:
 
IpPbx.CallingName = "via " & PBXUser.Name & " - " & IpPbx.CallingNumber  

Es gibt sogar mehrere Möglichkeiten:
Im GSE "Anruf" Bedingungsblock unter "Rufe von Rufnummer" die Liste von Nummern hinterlegen. Die Nummern werden hier mittels ; (Semikolon) getrennt
  In einer Textdatei eine Liste von Nummern (eine pro Zeile) hinterlegen, und dann ein wenig VBScript Code einfügen: CheckCallerInTextFile
  in einer Datenbank eine Liste von Nummern hinterlegen, und dann ein wenig VBScript Code einfügen: CheckCallerInDatabase  
Wie Du den VBScript Code aus den obigen beiden Links in Deine GSE Regel bekommt, wird hier im Detail erklärt:
Function Collection (VBScript) - Introduction  
Grundsätzlich empfiehlt es sich, die Nummern immer im kanonischen Format anzugeben, d.h. mit +49 beginnend und ohne die ansonsten führende 0, also +4923147770 statt 023147770.
 

Hallo Andreas,
 
das Call Routing wird vom Swyx Server ausgeführt, d.h. von dort aus gibt es keine Möglichkeit auf einem Client eine MessageBox zu öffnen.
 
Du musst mit Deinem Code auf den Client ziehen. Dazu gibt es das Client SDK.
 
Hier sind zwei Beispiele wie Du Dich mittels VBS an das SwyxIt! (oder besser gesagt den darunter liegenden Client Line Manager) heften kannst:
CallDetails VBScript Open Browser on incoming call  
Im Client SDK Forum finden sich auch etliche ggf. hilfreiche Hinweise und Code Schnipsel, allen voran wo Du das aktuelle Client SDK (inkl. weiterer Beispeile und Doku) herunter laden kannst:
Client SDK - Where to find it?  
 

Hallo,
 
an diese Liste kommst Du nicht ohne einen Umweg aus dem Call Routing aus heran. 
 
Die Liste kann über die Config Data Store API bzw. über PowerShell abgefragt werden. Du müsstest Dir also etwas zwischen Dein Call Routing und den Config Data Store basteln, welches Du vom Call Routing aus ansprechen kannst, und was Dir die gewünschte Information zurück liefert.