Tom Wellige

They can't.
 
You need some sort of clever call routing around it. Something like a global switch which can be accessed by every user to set it or to check its current position.
 
Easiest way for that would be the Persistent Variables.
 
The included "Night Switch" example is more or less exactly what you need.
 
You can place a simple call routing rule to the VG user which checks the status of a global "Announcement" variable and play the needed announcement of the variable is set to 1 (do not touch the original VG call routing rule, but add yours in front of it).
 
Additionally you will have one sort of dummy user with a "manager call routing", where certain (or all users) can call and modify the status of your "Announcement" variable either via DTMF menu or by using post dialing digits when calling into that user.
 

You misunderstood my previous answer. Within the "Get DTMF Char" block you can define a variable that also keeps the pressed key. Something like this:
 

 
Within the "Write To File" block you call a VBScript function that you have placed into the "Start" block of the script and which is based on the one from the link above. When calling it, you need to pass the "pressed_key" variable as function parameter into that function.
 
The second "Insert Script Code" block is there, to let you differentiate graphically again what the caller has entered.
 

You need to separate this into two parts:
 
1) as you already described using a call routing script to recognize the caller and place the call back request into a database
 
2) using a small application that checks for call back request in you database and if so using the client sdk to initiate a call via SwyxIt!. Once it is connected you can transfer it into another call routing script which provides the DTMF menu.
 
On outbound calls the DTMF detection is disabled by default (for security reasons) but can be enabled via a registry key. As this is not a published key you need to request it from Swyx Support (via your reseller or distributor).
 

Hallo Jochen,
 
der folgende Blog Artikel beschreibt die Möglichkeiten die Du hast:
https://www.swyxforum.com/blogs/entry/11-4-take-me-to-your-leader/  

Ja, das sollte gehen.
 
Setze den Block "Warten auf Verbidungsende" einfach hinter den "Verbunden" Ausgang vom "Durchstellen" Block.
 
In den Eigenschaften vom Block kannst Du den gewünschten Timeout definieren.
 
Hinter den "Timeout" Aufgang vom "Warten auf Verbindungsende" Block setzt Du dann einfach einen "Ruf beenden" Block. In dessen Eigenschaften musst Du nichts mehr ändern. 
 
Von da geht es dann direkt in den "Regel ausgeführt" Ausgang.
 
 

Hello Björn,
 
you can't modify any files in the "system default" scope. The "rulePreProcessing" that is placed in there is marked as "none ECR file" and is therefore executed by the system, even if there are no ECR license available.
 
So if you would be able to place your own file into the "system default" scope, or the "global" scope (where it would belong into) you still have the problem, that your own created file is marked as "ECR file" and therefore ECR licenses are required.
 
While it is technically possible to mark your own file as "none ECR file", this is nothing that can be discussed in a public forum. Swyx/Enreach is of course able to modify your file accordingly, but it would first need an approval from the sales department. 
 
I suggest that you get in touch with "channel.sales@swyx.com" for this.
 

The WAV file need to be in 8kHz, 16bit, mono format.

Es gibt die Möglichkeit dies über das globale PreProcessing zu lösen.
 
In dem folgenden Topic hatte ich das PreProcessing schonmal erklärt:
 
 
 

Mit dem Call Routing ist das ein Kinderspiel:
leg Dir einen Call Routing Benutzer mit der SwyxWare Administration an von dort öffne den Call Routing Manager für diesen Benutzer erstelle eine neue Regel mit dem Grafischen Skript Editor dort setzt Du hinter den Start Block einen Ansage spielen Block. In diesem Block konfigurierst Du die freundliche Begrüssung die Du hören möchtest. danach setzt Du einen Nachricht aufzeichnen Block. In dessen Eigenschaften setzt Du den Timeout z.B. auf 15 Sekunden.  Du musst auch noch Dateinamen in Variable speichern einschalten, und einen Namen für die Variable festlegen, z.B. Test


  nach den Nachricht aufnehemen Block setzt Du wieder einen Ansage spielen Block und setzt als Ansage:  = Test


  Und das war es auch schon    
Wenn Du das Call Routing Skript speicherst und den neuen Benutzer anrufst hörst Du erst die Begrüßung, dann einen Beep, dann darf man 15 Sekunden etwas sagen und bekommt es anschließen vorgespielt.
 

 
 
Sound Test.rse
 
 
 

Hi,
 
I took the liberty to put all this into a complete script and wrote a small blog article about it. You can find it here:
#12: Rotating call distribution to engineers Please feel free to ask any follow up questions.
 

I have just tested it myself, and it work. Although only after tricking the GSE a little bit. Instead of entering the path directly into the "Play Announcement" block
C:\Test\Test.wav I had to enter it like this
= "C:\Test\Test.wav"  
I have also tested a UNC path and it didn't work, but the server trace revealed the answer:
28 11:49:55.980 001884 Warn SrvPathHlp 0A26F60C 00000000 SPathHelper::GetLocalPath () UNC path's are not supported  
So I was wrong with saying that one can use UNC paths.
 
But that's not much of a problem. Just map the share to a network drive to circumnavigate the UNC path.
 

Wie gesagt, den Umleitungsstatus bekommst Du nur im Call Routing des entsprechenden Benutzers abgefragt. Out of the Box sehe ich da keine einfache Lösung.
 
Auch persistente Variablen lösen Dein Problem nicht wirklich, denn in dem Augenblick in dem der Benutzer X seine Umleitung setzt ja kein Call Routing angestossen wird mit dem den neuen Status selber speichern könntest.
 
Die komplette Umleitungskonfiguration kann über den ConfigDataStore abgefagt werden, da sind vom Call Routing aus aber einige Klimmzüge für notwendig.
 
Finally steht die Umleitungskonfiguration in der SwyxWare Datenbank. Technisch kann es natürlich niemand verhindern dass dort z.B. ein Call Routing Skript der Zentrale hineinschaut um sich mal in Bezug auf den Benutzer X ein wenig schlauer zu machen...
 
Es sei allerdings ausdrücklich darauf hingewiesen, dass es dafür an keiner Stelle Support gibt. Bei schreibenden Zugriff auf die Datenbank würde sogar der komplette Support für diesen Server eingestellt.
 

Du solltest in dem Skript nachdem Du aufgelegt hast direkt in den Ausgang "Regel ausgeführt" springen. In den Block "Ruf beendet" zu gehen macht zwar nicht kaputt, bringt aber auch nichts.
 

 
Ansonsten sehe ich keinen Grund, weswegen das im GLOBAL Scope nicht funktionieren sollte, wenn es zurvor im USER Scope des Testbenutzers funktionert hat.
 
Im SYSTEM DEFAULT Scope hat niemand etwas verloren, der ist komplett Read-Only und enthält alle Dateien die von der SwyxWare mitgebracht werden. Wenn ein Update installiert wird, wird dieser Scope komplett geleert und anschliessend neu gefüllt. Deine Änderungen wären damit also Geschichte.
 
Man muss da aber nichts rein schreiben, der GOBAL Scope reicht vollkommen aus.
 
Der der Server eine Datei laden will (Skript, Ansage, Skin, etc.) dann sucht er diese in dieser Reiehenfolge bis der sie gefunden hat:
USER Scope des Benutzers GLOBAL Scope (sichtbar für alle Benutzer) SYSTEM DEFAULT Scope (sichtbar für alle Benutzer)  
Wenn Dein PreProcessing also beim Testbenutzer funktionert hat, und Du es anschliessed in den GLOBAL Scope legst (wirklich relevant ist nur die rulePreProcessing.vbs an dieser Stelle), und ein Ruf für einen Benutzer ungleich Deines Testbenutzers kommt rein, dann sucht der Server nach der Datei "rulePreProcessing.vbs"). Da diese nicht im USER Scope des Benutzers liegt, schaut er als nächstes in den GLOBAL Scope und dort wird er fündig.
 
Ich weiss nicht, was Du evtl. noch auf dem Server gemacht hast, aber wie gesagt, wenn Dein PreProcessing beim Testbenutzer läuft wird es anschliessend auch für alle Benutzer im GLOBAL Scope laufen. 
 
 

Hallo,
 
in meinen Augen ist das nichts fürs Call Routing, da das ja nur durch kommende Rufe auf einen Benutzer getriggert wird. Wenn kein Ruf für einen Benutzer rein kommt, bekommst Du dann auch den Statustext nicht aktualisiert.
 
Denkbar wäre eine kleine Applikation auf den Clients parallel zum SwyxIt!, welche über das Client SDK den Statustext passend setzt, oder eine zentrale Applikation irgendwo (z.B. auf dem Server selbst) welche regelmässig (z.B. alle 10 Minuten) per Config Datastore SDK oder PowerShell alle benötigten Daten ermittelt und setzt.
 
Persönlich würde ich den zweiten Ansatz verfolgen. Das könnte dann in etwa so aussehen:
 
- über das globale Telefonbuch alle Benutzer inkl. aktuellem Status ermitteln
- über die Login Device Liste pro Benutzer die IP Adresse des SwyxIt! Clients ermitteln (wobei natürlich auch eine Telefon IP Adresse verwendet werden könnte)
- Statustext pro Benutzer passend setzen oder auch löschen (bei abgemeldeten Benutzern)
 
 

As you use more of less the same function for both cases (Azubi, Buero) I would just place the following function in the "Start" block and use a "Variable auswerten" block to call it:
 
 
Please find the IsGroupLoggedOff function in the Function Collection (VBScript) and Function Collection (Lua) area of the Programming References section of the SwyxPEDIA here on Swyx Forum. 
 
 
And instead of hard coding the numbers of the group members into the code, I would create a SwyxWare user groups with the desired users in them and call the above function with the group number (or name) as parameter.
 

Ganz genau.
 
Lege Dir bei Deinem Testbenutzer eine Regel mit dem Namen PreProcessing an, und füge das Call Routing dort ein. 
 
Wenn das PreProcessing anschließend global für alle Benutzer gemacht werden soll, sollte die Regel auch mit allen Benutzern umgehen können. D.h. auch immer irgendeinen Weg über "Regel übersprungen" enthalten, damit das Call Routing eines Benutzers (Umleitungen, etc. pp.) noch greifen können.
 
Wenn die Regel fertig ist und ausreichend getestet wurde, kann Du mit dem IpPbx File Explorer (SwyxWare DVD - Swyx - Tools - File Explorer) die beiden Dateien
rulePreProcessing.rse rulePreProcessing.vbs aus dem USER Scope des Testbenutzers lokal auf Deinen Rechner herunter laden.
 
Im nächsten Schritt lädst Du die beiden Datein wieder hoch, nun aber in den GLOBAL Scope.
 
Ab diesem Augenblick wird die PreProcessing Regel für jeden Anruf auf einen beliebigen Benutzer gestartet.
 
Wenn etwas nicht klappen sollte, lösche die beiden Dateien aus dem GLOBAL Scope und korrigiere und teste die Regel auf dem Testbenutzer. Anschließend kannst Du sie wieder global hinterlegen.
 
Wenn Du das global nicht willst, kannst Du die beiden Dateien auch in den USER Scope aller relevanten Benutzer hochladen.
 

Mir ist nicht so ganz klar, was die Zeile file.Write Content in Deinem Code machen soll.

 

Du schreibst also schon erfolgreich eine PIN in eine Textdatei, richtig?

 

Im prinzip geht das Lesen aus einer Textdatei genau so, nur dass der Befehl nicht WriteLine sondern ReadLine heisst.

 

Ein Beispiel wie man aus einer Textdatei liesst findest Du entweder hier

 

http://www.swyx.com/support/ssdb.html?kbid=kb2285

 

oder hier

 

http://www.w3schools.com/asp/asp_ref_textstream.asp

 

oder per Google. Einfach mal nach "VBScript" und "ReadLine" suchen.

Die SwyxWare selbst hat keine Spracherkennung. Wenn Du allerdings eine Spracherkennung findest, die ihre Dienste z.B. via COM Schnittstelle zur Verfügung stellt, dann ist es ein leichtes, diese in das Call Routing einzubauen.

Hallo,

 

über das SwyxIt! Client SDK kann man sich recht einfach mit dem SwyxIt! verbinden und alles mögliche anstellen :-)

 

Ich habe gerade ein Beispiel von der alten Forum Seite neu hochgeladen (weil es dort nicht mehr verfügbar ist) was genau das macht, was Du haben möchtest:

http://www.swyx-forum.com/index.php/files/file/36-vbscript-open-browser-on-incoming-call/
 

 

Schau auf alle Fälle mal ins Client SDK Forum:

http://www.swyx-forum.com/index.php/forum/28-client-sdk/
 

Dort findest Du das Client SDK selbst (enthält bereits etliche Beispiele) als auch Links zu weiteren Beispielen. Das ist auch der Ort, um gezielt Fragen zum SDK los zu werden.

The following posts might be a good starter:
 
 
    For general information on how to use the IpPbx Powershell module I recommend reading through the archived forum  
 
 
 
 
https://www.swyxforum.com/forum/30-powershell/