Tom Wellige

Dann habe ich darauf leider keine Antwort. Das hört sich nach einem Fall für den Support an. Da sollte mal jemand kundiges einen Blick in die Traces werfen.

Hallo Simon, solange auf keinem Benutzer an der Standard Fernabfrage Änderungen im Callrouting vorgenommen wurden (was theoretisch möglich ist), sollte das alles einwandfrei funktionieren. Seit Version 13.27 werden die Nachrichten in der SwyxWare selbst gespeichert und von dort aus bei Bedarf ausgelesen. Vor der 13.27 war es so, dass in der Fernabfrage per IMAP4 rückwarts an den Mailserver gegangen urde, um die Voicemails von da aus nochmal herunter zu laden. Haben alle Benutzer bei Dir das Problem, oder nur einige wenige? Bei letzterem, mach mal den Call Routing Manager eines dieser Benutzer auf, klicke auf den Aktionsfolge Schalter und schau mal in der Liste, ob Du dort einen Eintrag "actionStandardRemoteInquiry" mit oder ohne "(System)" hinter dem Namen findest. Wenn da kein "(System)" hinter steht, dann ist dort tatsächlich bei Euch mal was an der alten Fernabfrage geändert worden, was jetzt im Augenblick verhindert, dass die neue benutzt wird. Die Lösung ist dann aber ganz einfach: gehe in den Eigenschaften des Benutzer in die Administration, dort auf die Dateien Seite und dann bearbeiten. Aus der Liste dort musst Du dann die beiden Dateien actionStandardRemoteInquiry.ase und actionStandardRemoteInquiry.vbs löschen. Das machst Du dann bei allen betroffenen Benutzern.

Wenn noch Fragen dazu im Verlauf aufkommen, Du weisst ja jetzt, wo Du Antworten bekommen kannst Viel Erfolg!

Hallo Simon, die globale Variable "g_resStandardVoicemailSubject" gibt es noch und die kann auch problemlos in eigenen Skripten benutzt werden. Die andere globale Variable "g_resStandardVoicemailBody" hingegen gibt es nicht mehr. Die mit SwyxWare 13.27 (Einführung des Gruppen Call Routings und der VoiceBox als Erweiterung der Voicemail) entfallen. Es gibt auch keinen 1 zu 1 Ersatz für dieseVariable. Statt dessen verwendent die Voicebox/Voicemail Funktionalität folgende Logik um den Body einer Voicemail zu füllen. If (g_bIsGroupContext) Then resVoiceMessage = PBXScript.GetString(115, CStr(PBXCall.CalledPartyNumber), CStr(PBXCall.VoiceMessageId)) Else resVoiceMessage = PBXScript.GetString(104, CStr(PBXCall.VoiceMessageId)) End If resStandardVoicemailBody = PBXScript.GetString(103,Extension()) + vbLF + vbLF + g_resCallBack + g_resEmailReply + vbLF + vbLF + resVoiceMessage Die Variable "resStandardVoicemailBody" ist eine lokale Variable innerhalb der Voicebox/Voicemail Funktionalität, auf die Du in Deinem eigenen Call Routing keinen Zugriff hast. Du könntest Dir allerdings einen "Skript Code einfügen" Block vor Deinen "EMail" Block setzen und dort eine eigene Variable mittels "Dim" anlegen und wie oben gezeigt mit Inhalt füllen. Oder Du verwendest gleich den "Voicebox" Block, dann hast Du damit gar nichts mehr zu tun,

AzureTranslate AzureTTS (text-to-speech)

View File AzureTranslate This extension provides text translation functionality for the SwyxWare call routing. It uses the Microsoft Azure Cognitive Speech services comes for VBscript based and Lua based call routing requires SwyxWare 12.40 (or newer) for VBScript based call routing requires SwyxWare 13.20 (or newer) for Lua based call routing Please refer to the Project Page for all details. Please refer to the Forums to discuss this project or for support reuqests. Please refer for documentation (setup, usage, etc.) for this extension to the Project Page. Find the license information on the Project Page. If you want to get involved into this project please refer to this topic. As with all other Swyx Forum Open Source Projects, Support is EXCLUSIVELY provided in the Project Froum (see link above). Submitter Tom Wellige Submitted 08/29/2024 Category Open ECR Extensions

View File AzureTTS (text-to-speech) This extension provides text to speech functionality for the SwyxWare call routing. It uses the Microsoft Azure Cognitive Speech services comes for VBscript based and Lua based call routing requires SwyxWare 14.10 (or newer) Please refer to the Project Page for all details. Please refer to the Forums to discuss this project or for support reuqests. Please refer for documentation (setup, usage, etc.) for this extension to the Project Page. Find the license information on the Project Page. If you want to get involved into this project please refer to this topic. As with all other Swyx Forum Open Source Projects, Support is EXCLUSIVELY provided in the Project Froum (see link above). Submitter Tom Wellige Submitted 08/29/2024 Category Open ECR Extensions

Hallo Mario, der Grund ist relativ einfach, aber leider nicht so offensichtlich. Die PBXConfig.GetUserByAddress Methode liefert Eine Liste von Objekten vom Typ PBXUser zurück. Leider ist dieser Name irreführend, da es sich hier NICHT um das PBXUser Objekt der Server Script API handelt. Da ist vor sehr vielen Jahren ein Name ungünstig bzw. schlecht gewählt worden. Über das PBXUser Objekt der Server Script API kannst Du u.a. auf die Umleitungskonfiguration des aktuellen Skriptbenutzers zugreifen. Über das PBXUser Objekt in der Liste die von GetUserByAddress zurück geliefert wird, sind nur einige wenige Informationen über beliebige Benutzer der SwyxWare enthalten. Nicht jedoch ist der Zugriff auf deren Umeltungskonfiguration enthalten. Du kannst also von einem Call Routing aus, nur die Umleitungskonfiguration des aktuellen Skriptbenutzer zugreifen, nicht aber die auf Konfiguration aller/beliebiger Benutzer. In Deinem Anwendungsfall musst Du das Ändern der Umleitung in die jeweiligen Call Routings der einzelnen Benuztzer platzieren. Hier könnten Dir evtl. die persitenten Variablen helfen. Da kannst Du ja mal einen Blick drauf werfen,

Enreach hat einen Posten als Mitarbeiter Vertriebsinnendienst/Inside Sales (all genders) zu besetzen. Alle weiteren Details hierzu finden Sie hier: https://www.enreach.de/de/stellenangebote?jh=73imif9h549jcy8d7z1cp07ep9t73no

Ist die Statussignalisierung zwischen allen beteiligten (Gruppenmitglieder und Benutzer auf dem das Call Routing mit dieser Funktion drin läuft) richtig konfiguriert? Das Server Trace sollte hier eine eindeutige Antwort liefern. Details dazu gibt es hier. Welcher Statuswert steht im Trace für die beiden Gruppenmitglieder?

Hier ist noch einmal das Thema "PreProcessing" erklärt: This arctile explains again the topic "PreProcessing": https://www.swyxforum.com/blogs/entry/103-22-global-call-routing-rules-meet-the-preprocessing/

Hier ist noch einmal das Thema "PreProcessing" erklärt: This arctile explains again the topic "PreProcessing": https://www.swyxforum.com/blogs/entry/103-22-global-call-routing-rules-meet-the-preprocessing/

To understand the so called PreProcessing we first need to take a look into the Call Routing Manager. In there we see the list of all call routing rules, the system ones and the own ones. But this picture is not complete. There are two more rules, which are hidden in the list, but are getting executed for every call. The PreProcessing rule which is started before the user's call routing, and the PostProcessing which is started after the user's call routing. As both rules are hidden, it is not possible to deactivate them. They can also not that easily get manipulated by a user. In the following we will focus on the PreProcessing, as this is the one which can be used best in some own call routing tasks. But every that is said in the following is also true for the PostProcessing (except that in the PostProcessing the call is already disconnected). The default PreProcessing is an empty GSE rule, which is left through the Rule skipped exit. This ensures that following rules (the entire user call routing) will be executed. Before going into detail on how to create your own PreProcessing I want to take a look on what the it can be used for. There are multiple usage examples: User based/Global name resolution against own database. User based/Global black/white listing of calls. User based/Global break through redirections for certain callers. User based/Global own call logging (in combination with a user based/global PostProcessing). A identical call routing for all users of a company. In this case I would highly recommend to place that call routing into a global GSE Action which is called by the PreProcessing rule. This makes the maintenance of the call routing more easy. There will be another blog article soon explaining all there is to know about GSE Actions. From the above list you can take that a PreProcessing rule is either a local rule to a user or a global rule being used by all users. By the way: beside GSE Actions the Pre- and PostProcessing rules are the only call routing functionalities, which can be made global. To create your own PreProcessing all you need to do is to create a new GSE rule on your test user and name it PreProcessing. You are absolutely free to do what every you want within this rule, just keep a few things in mind: If you leave the rule through the Rule executed exit, no following rules will be started, i.e. you completely disable the user's own call routing rule. This might be totally fine and wanted (like in a black/white listing task, to block callers), just be aware of what you are doing. If you leave the rule through the Rule skipped exht, the users own call routing will be executed. This should be the default behaviour of your rule. After having created the PreProcessing rule, it is a local rule of the current user, and you have it in the list of rules of the Call Routing Manager. I strongly advise to use a test user for creating the needed PreProcessing, regardless if you need it afterwards only for one other user or all users within your SwyxWare. This ensures that you can modify and re-test it at any time. Now that you have the PreProcessing rule on your test user, how do you get it to another user or make it even global? All you need to do is to get one certain file out from the SwyxWare configuration database, the generated VBScript/Lua code for your rule: rulePreProcessing.vbs or rulePreProcessing.lua. To get this file follow these steps: Open the SwyxWare Administration Open the Users branch in the tree view on the left Right click your test user to open his context menu Select Special properties, and then Administration... Switch to the Files tab and click Edit... Select the file rulePreProcessing.vbs or ruleProcessing.lua in the list and click Save As... Selet a local folder on your hard drive to store the file in. Close the File List window and the Administration Properties again. If you want to have the PreProcessing rule local to selected user(s): Repeat the above steps 1-5 Click Add... Click "..." and select the previously stored file As Category select either Call Routing VBS scripts or Call Routing Lua scripts Click Ok If you want to have the PreProcessing global, i.e. it will be used for ALL users: Open the SwyxWare Administration Right click your SwyxServer name in the left tree view to open his context menu Select Properties Switch to the Files tab and click Edit... Click Add... Click "..." and select the previously stored file As Sope make sure that Global is selected (should be the default) As Category select either Call Routing VBS scripts or Call Routing Lua scripts Click Ok There are a few things you really have to keep in mind when making a PreProcessing rule global: Test you PreProcessing rule extensivley before making it global! Worst case: no one within your company can be called anymore (internally or externally) if your rule contains an error. So again, test, test, test! When including own VBScript/Lua code, make sure to Implement proper error handling! For VBScript code check the CheckCallerInDatabase function as an example for proper error handling. For Lua code check the CheckCallerInTextFile() function. Unhandled runtime errors lead to disconnection of the call, i.e. no one within your company can be called anymore. Consider the resource and time consumption of your PreProcessing script, as it will be called vor EVERY call. I have already pointed on two different rulePreProcessing files: .vbs and .lua For users you have switched to Lua based call routing, you need a PreProcessing also made on a Lua based test user and the rulePreProcessing.lua file. For users using the default (at the time of writing this blog article) VBScript based call routing, you need a PreProcessing also made on a VBScript based test user and the rulePreProcessing.vbs file. If you make your PreProcessing global and have VBScript based as also Lua based call routing users in your system, you need to create the PreProcessing also in both environemts and make both files global. There is also a webinar available to all Enreach Partners within the Enreach Partner Net, explaining all above again in a video and even providing a short live demo. The webinar is available in German and English language (Partner login required!) and was already recorded a few years back, before Swyx turned into Enreach and before Lua became an option within the call routing. Enjoy! PS: don't miss to take a look into the ECR Useful Link Collection.

Hier ist noch einmal das Thema "Black/White Listing" erklärt: This arctile explains again the topic "black/white listing": https://www.swyxforum.com/blogs/entry/100-21-the-world-isnt-black-white-or-is-it/

Hier ist noch einmal das Thema "Black/White Listing" erklärt: This arctile explains again the topic "black/white listing": https://www.swyxforum.com/blogs/entry/100-21-the-world-isnt-black-white-or-is-it/