Tom Wellige

Hallo,

Du hast dort keine ganz seltene Aufgabenstellung an das Call Routing. Mit der aktuellen SwyxWare Version ist das allerdings (noch) nicht abbildbar.

Wenn Du im Call Routing einen Durchstellen Block benutzt, dann laufen die Audio-Mediendaten ab dem Augenlick wo der Ruf verbunden wird nicht mehr über Dein Call Routing sondern direkt zwischen Anrufer und Ziel. Damit kann das Call Routing dort nicht mehr Ansagen hineinspielen oder auf DTMF Zeichen lauschen.

Da wird aber bereits an einer Erweiterung gearbeitet, die es Dir erlauben wird, soetwas in Zukunft problemlos im Call Routing abbilden zu können. In welcher SwyxWare Version bzw. wann geanu das verfügbar werden wird, kann ich Dir leider nicht sagen. Es wird aber auf alle Fälle kommen.

Enreach has switched the content management system of the knowledge base some time ago, and not all "old" content has been taken over into the new system.

I have just updated the Client SDK list you are referring to with the direct download links. They are all working.

Es sollte nicht notwendig sein, dass Du die Variable selber definierst. Das sollte der "Attribute abfragen" Block für Dich machen. Nimm also mal den "Variable setzen" Block raus.

Wenn der Ruf dann immer noch abbricht, werf mal einen Blick ins Server Trace. Dort solltest Du dann einen "Laufzeitfehler / Runtime Error" finden der Dir sagt, weswegen genau das Call Routing nicht gültig ist.

Hier findest Du Hinweise, wo Du das Server Trace findest.

Freut mich zu lesen, dass meine Hilfe hier "ankommt"! Genau dafür ist das Forum da  

Werf doch mal einen Blick in die Beispiele die bei den persistenten Variablen mit dabei sind.

Dort findest Du eine kleine Webseite die als WebExtension in der Skin des Client angezeigt werden kann. Das Beispiel zeigt den Status einer Variable an und erlaubt es, sie per Mausklick zu ändern.

Es sollte kein grösseres Problem sein, die Webseite so anzupassen, dass sie Dir die Ansage anzeigt.

Hi, generally that is exactly what PBXCall.ConnectedName und PBXCall.ConnectedNumber is there for (beside figuring who took the call if you connected it to a group).

As it should work you should check the server trace file for more details on what name was returned by this function.

Here you will find some hits on how to find the server trace file and filter it down to the information you are interested in.

Additionally, here you will find some hints how to add own tracing into the server trace file to make debugging more easy.

Nein, das geht leider nicht. Die WebExtension ist immer sichtbar, es sei denn, Du platzierst sie auf einer Registerkarte und kann sie damit in den Hintergrund verfrachten wenn sie nicht gebraucht wird.

Sehr gern geschehen  

Auf der "Tab Group" Seite der WebExtension kannst Du festlegen in welcher Gruppe und auf welcher Seite der Gruppe die Extension angezeigt werden soll:

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.

Wenn ich Dich richtig verstehe, willst von quasi von Hand die Zustellung von Rufen auf diesen Benutzer (im Call Routing auf das "urpüngliche Ziel") auf einen anderen Benutzer umstellen können. Als Flag dafür willst Du DND benutzen.

Sofern Du Deinen Zentrale Benutzer nicht von Hand auf "Lua" umgestellt hast, basiert Dein Call Routing auf "VBScript". In Deinem Screenshot verwendest Du aber "Lua" Syntax. Ich hab das nicht ausprobiert, glaube aber nicht, dass VBScript damit glücklich ist.

Du bist in der Server Script API Referenz vermutlich versehentlich in der "Lua" Version gelandet. Hier findest Du die "VBScript" Version.

ABER...

Ich würde als Flag mit welchem Du markieren willst, wohin zugestellt werden soll nicht DND oder Away nehmen. Die haben um Zweifelsfall Einfluss auf die Rufzustellung auf den Benutzer. Statt dessen würde ich persistente Variablen (PV) vorschlagen wollen. Eine solche merkt sich ihren Inhalt dauerhaft auf über das Skript Ende hinaus in einer Datenbank und ihr Inhalt kann entweder nur für die aktuellen Benutzer oder alle Benutzer erreichar sein. Keine Sorge, die PVs kümmern sich um die Datenbank, Du hast damit nichts zu tun. Für Dich ist das nur eine Variable in die Du etwas rein tust oder heraus liest.

In dem PV Projekt findest Du ein Beispiel für eine Nachtschaltung, die Du hier eins zu eins übernehmen kannst! Statt den Status von DND abzufragen bevor Du zustellst, fragst Du einfach die persistente Variable ab. Das sieht in der Praxis dann wirklich einfach und übersichtlich aus (siehe hier). In dem Beispiel ist ein Manager Skript enthalten, über das Du die PV entweder einfach per DTMF Menü oder Nachwahlziffer umstellen kannst (siehe hier).

Hallo Julian,

wenn Du mit den "Nachrichten aufnehmen" Block eine neue Ansage aufnimmst, ist das aus Server Sicht erst einmal eine temporäre WAV Datei, die er nach Beendigung des Rufes wieder löscht.

Du musst sie also nach der Aufnahme selbst dauerhaft an geeigneter Stelle speichern, damit sie anschliessend in Call Routing Skripten des gleichen Benutzers zur Verfügung steht.

Mit der PBXUser.UploadFile Funktion von der Server Script API kannst Du die aufgenommene Datei in die SwyxWare Datenbank in den Sichtbarkeitsbereich (Scope) des aktuellen Skript Benutzers laden. 

Den Namen der aufgenommenden Datei vergibt der Server (damit er immer eindeutig ist). In anderen Call Routing Skripten des Benutzers musst Du diesen Namen dann natürlich kann, damit die die Ansage per "Ansage spielen" Block abspielen kann. Dazu gibt es grundsätzlich zwei Lösungsansätze:

• Du merkst Dir den Namen der aufgenommenen Datei (ohne den Pfad) in einer persistenten Variblen (diese merkt sich ihren Inhalt über das Ende eines Rufes hinweg) und alle Call Routing Skripte die die Ansage brauchen, schauen dann einfach in dieser Varible hinen.  
   
• Bevor Du die Datei mittels UploadFile hochlädst, kopierst Du sie und gibst ihr dabei einen eigenen Namen (z.B. "AnsageBenutzerXYZ.wav") und benutzt diesen dann in allen anderen Call Routing Skripten. Da der Server die von Dir kopierte Datei nicht kennt, musst Du sie nachdem Du sie hochgeladen hast selbst von der Platte löschen.

Ganz genau darum geht es. Die gegenseitige Statussignalisierung muss passend konfiguriert sein. Das kann man entweder auf Benutzerebene oder Gruppenebene machen.

Entscheidend ist, dass Dein Call Routing Benutzer den Status vom Benutzer 101 sehen darf.

Wenn Du einen Blick in das Server Trace wirfst, dann vermute ich mal, dass Du dort als aktuellen Status von 101 eine "0" angezeigt bekommst. Das heisst dann, dass der Status nicht ermittelt werden kann weil der Admin keine passende Konfiguration vorgenommen hat.

Hast Du die Statussignalisierung wie in dem UserStatus Artikel beschrieben konfiguriert?

Du kannst auch mal einen Blick in das Server Trace werfen um zu sehen, welcher Status Wert für den Benutzer 101 denn ermittelt wird. Wie Du Dich im Server Trace zurecht finden kannst, ist hier beschrieben.

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.

You are mostly welcome! I am always glad to be of help  

Ich habe gerade gesucht und stelle fest, dass ich damals keine Rückmeldung bekommen hatte.

Unmittelbar nach meinem Report hatte ich alle Details zu den Call Routing Änderungen in der 13.27 erhalten und angefangen, die hier zu dokumentieren. Da ist mir Dein Problem aus dem Fokus geraten.

Ich werde da nochmal nachfragen, ob da schon was passiert ist.

4 hours ago, mac_key said:

29 12:11:52.505 0013e4 Info SrvScript  09CD46C0 0000009b SPBXScriptVbs::OutputTrace              () -------------> IsGroupLoggedOff ( sNumber = 11 )
29 12:11:52.511 0013e4 Info SrvScript  09CD46C0 0000009b SPBXScriptVbs::OutputTrace              () bReturn = Wahr
29 12:11:52.511 0013e4 Info SrvScript  09CD46C0 0000009b SPBXScriptVbs::OutputTrace              () <------------- IsGroupLoggedOff

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):

And the user for whom the call routing script is running is also part of that group?

You can take a look into the server trace to see exactly what the function IsGroupLoggedOff is doing.

The following article describes how to identify and filter a spcific call within the server trace file and how to filter it further down to just the call routing trace output:

• How to filter SwyxWare traces for call routing output of single call

Feel free to post that filtered trace output here.

The most important requirement is stated right below the script code:

Do you have mutual status signalling enabled between all envolved users (the ones in the group and the one the current call routing script runs for)?

Hallo Dirk,

grundsätzlich kann Funktionalität im Call Routing der SwyxWare mittels VBSkript (und auch Lua, allerdings ist das noch in der Beta Phase) erweitert werden. Dazu schreibt sich eine VBSkript Funktion und kopiert diese in den Start Block. Das ist hier nochmal erklärt und dort ist auch eine Sammlung von fertigen VBSkript Funktionen die Du per Copy & Paste in den Start Block kopieren kannst.

• Function Collection (VBScript)

Alles was sich an Code im Start Block befindet ist global im gesamten Call Routing des aktuellen Benutzers verfügbar.

Das PreProcessing ist ein Sonderfall, mit dem es möglich ist, Call Routing Funktionalität allen Benutzern zur Verfügung zu stellen, da man diese Regel global in der SwyxWare hinterlegen kann. Alle anderen Call Routing Regeln sind immer lokal bei einem Benutzer.

Mit dem Call Routing Manager verwaltest Du alle Call Routing Regeln. Bei einem kommenden Ruf wird die Liste der Regeln von oben nach unten abgearbeitet, solange bis eine Regel von sich behauptet den Ruf bearbeitet zu haben. Danach ist dann normalerweise Schluss.

Du kannst die Position von Regeln in der Liste beinflussen (Pfeil hoch und runter Tasten rechts neben der Liste) und Regeln aktivieren oder deaktivieren (Checkbox vor dem Namen der Regel). Deaktivierte Regeln werden nicht ausgeführt.

Eine grundsätzliche Einführung in das Call Routing findest Du in den Call Routing und Extended Call Routing Handbüchern. Für Partner gibt es bei Enreach auch eine eintägige ECR Einführungsschulung sowie eine zweitägige ECR Plus Schulung (Erweiterung des Call Routing via eigenem Skript Code). 

Hallo Dirk,

Du kannst das entweder Zentral auf dem Server in einer Call Routing Regel oder auf jedem Client mittels Client SDK machen.

Call Routing
Mit eigenem VBScript Code in einer Call Routing Regel kannst Du einen WebRequest ausführen. Wenn Du darüber den Namen ermittelt hast, kannst Du ihn per PBXCall.CallingPartyName setzen.
Ein Beispiel für die Anwendung des WebReuest und Verwendung von JSON formatierten Daten im Request und Response findest Du in Zendesk Integration Projekt hier auf der Forum Seite.
Wenn Du die Call Routing Regel fertig hast, kannst Du sie als "PreProcessing" Regel global hinterlegen. Hinweise hierzu findest Du hier oder als Webinar im Enreach Partner Net.

Client SDK

Das Client SDK enthält ein C# Beispiel, welches ein SwyxIt! PlugIn zur Namensauflösung zeigt (ähnlich dem Outlook PlugIn): Visual Studio.Net C# PlugIn

Von Terminvereinbarungen und Tischreservierungen bis hin zu häufigen Service-Anfragen – damit Unternehmen Routineaufgaben im Bereich Kommunikation besonders effizient abwickeln können, hat Enreach smarte, KI-gesteuerte Sprachassistenten für verschiedene Anwendungsszenarien entwickelt. Partner können ihren Kunden die fertig trainierten Voicebots als Zusatzoption zu einer Enreach Kommunikationslösung oder als Stand-Alone-Produkt anbieten, ohne selbst Zeit und Ressourcen in die Bot-Entwicklung zu investieren.

Einfach effizient

Für häufig vorkommende Anfragen und andere Routineaufgaben in der Kommunikation von Arztpraxen, Restaurants, Werkstätten und weiteren Unternehmen hat Enreach dedizierte Voicebots entwickelt, die Partner ganz einfach und schnell über ein übersichtliches Web-Interface mit individuellen Namen, Adressen, Sprech- bzw. Öffnungszeiten sowie weiteren Einstellungen für ihre Kunden konfigurieren können. Die BotApps von Enreach übernehmen Termin- und Reservierungsmanagement, Auskünfte, Rezeptbestellungen oder die Abfrage von Informationen – vollautomatisiert, besonders effizient und falls gewünscht, rund um die Uhr, an sieben Tagen pro Woche.

So werden Mitarbeiter entlastet und können sich auf das konzentrieren, was wirklich wichtig ist. Unternehmen verbessern zugleich ihren Kundenservice: Statt in der Warteschleife darauf zu warten, mit einem Mitarbeiter oder einer Mitarbeiterin zu sprechen, können Kunden und Interessenten ihr Anliegen direkt und ohne Verzögerungen mit dem smarten Sprachassistenten klären.

„Mit unseren neuen BotApps können Enreach Vertriebspartner schnell und bequem in den Markt für Sprachassistenten einsteigen. Auf diese Weise profitieren sie von dem hohen Interesse an KI-Technologien, schaffen für ihre Kunden echte Mehrwerte und können sich neue Zielgruppen erschließen. Unsere Voicebots sind die perfekte Lösung für alle Unternehmen, die ihren Kunden auch außerhalb der Öffnungs- oder zu Spitzenzeiten zeitgemäßen Service bieten wollen. Die smarten Sprachassistenen helfen dabei, Herausforderungen wie Personalmangel und Kostendruck zu begegnen sowie dynamisch auf Veränderungen zu reagieren. Ein unkompliziertes Abrechnungsmodell mit praktischen Minutenpaketen sorgt dabei für hohe Flexibilität“, erläutert Marco Crueger, VP Sales von Enreach.

Neben den fertig entwickelten BotApps stellt Enreach Partnern und Kunden weiterhin ein einfach zu bedienendes Entwicklungsstudio zur Verfügung, mit dem individualisierte Chat- oder Voicebots erstellt werden können.

Weitere Informationen über die BotApps gibt es auf der Website von Enreach und im Partnerportal.

Pressemitteilung auf enreach.de

Sorry, dass das einen Augenblick gedauert hat.

Auf meinem Testsystem läuft das SCC nicht vernünftig und ich musste mir erst ein anderes System besorgen.

Also ich kann Dein Problem wieder mit dem Swyx Control Center (Webadmin) noch mit der regulären SwyxWare Administration nachstellen. Beim Export sind immer alle Nummern enthalten, so dass sie anschliessend auch wieder sauber importiert werden können.

Ich würde vorschlagen wollten, dass Du Dich damit mal an Deinen Swyx Händler wendest, damit das zum Support gegeben werden kann. Irgendetwas scheint auf Deinem System nicht in Ordnung zu sein.

Danke für die csv Dateien. Die stammen nicht aus der SwyxWare Administration, richtig?

Ich nehme an, die machst das direkt über das Webinterface eines Telefons? Wenn ja, welches Telefon ist das genau? (Hersteller, Typ, Firmware Version)