Gruppenzugehörigkeit ermitteln

[mac_key]

Hmm, ich stehe gerade mal wieder vor dem selben Thema.

 

Bei mir sieht es so aus:

- Ein interner Call soll zum Zieluser durchgestellt und nicht weiter behandelt werden. D.h. ist der Zieluser angemeldet, soll es klingeln bis der Anrufer keine Lust mehr hat

- Ein externer Call während der Geschäftszeiten soll für 10 Sek. an das ursprüngliche Ziel weitergeleitet werden.

  - wird er dort nicht erfolgreich zugestellt, soll er für weitere 10 Sek. an die Gruppe (hier sind aber nur die Abteilungsgruppen gemeint) weitergeleitet werden.

  - wenn der Call da auch nicht zugestellt werden kann, dann soll er an die zentrale Rufannahmegruppe weitergeleitet werden.

  - sollte sogar das scheitern, dann soll an das ursprüngliche Ziel eine E-Mail gesandt werden, in der der Anrufer auf den versäumten Call hingewiesen wird.

Die Gruppen sind bekannt und können der Reihe nach abgefragt werden, ob der Angerufene Mitglied ist. Es ist durch den administrativen Prozess auch sichergestellt, dass er nur Mitglied einer solcher Gruppe ist.

Hat jemand so was schon mal gebaut?

 

[Tom Wellige]

Geht es Dir jetzt darum, dieses Call Routing global für alle Benutzer zu hinterlegen (siehe Title dieses Topics), oder ganz prinzipiell wie man ein Call Routing wie Du es beschrieben hast baut?

[mac_key]

Moin Tom,

 

es geht mir darum über die Gruppenzugegehörigkeit eines Users zu steuern, an welche Gruppe der Call nötigenfalls weitergeleitet werden soll.

Das soll den Beachtungsaufwand bei späteren administrativen Änderungen reduzieren und die Fehlerwahrscheinlichkeit reduzieren.

In diesem Fall administrieren nämlich auch Menschen die nicht so tief im Callrouting stecken die User.

Zwar wissen die in welche Abteilungen die Leute gehören, aber nicht viel über Callrouting.

[Tom Wellige]

Ich habe da ein eigenes Topic draus gemacht, weil das erst einmal nichts mit globalem Call Routing zu tun hat.

 

Prinzipiell kann man per eigenem Skript Code SwyxWare Benutzer Gruppen auflösen. Wenn es eine feste Anzahl von Gruppen gibt, in denen der aktuelle Benutzer wahlweise stecken kann, dann könnte man in jede dieser Gruppen hineinschauen, wo der Benutzer denn gerade drin ist, um den Ruf dann anschliessend dort hin zu verbinden.

 

[jodost]

Ansonsten, anderer Denkansatz:

 

Wir haben ein ähnliches Setup bei einem Kunden. Globale CallRouting-Regel, die erst einen Zustellversuch macht, und danach ein Sprachmenü "drücke die 1 für Voicemail oder die 2 für einen anderen Mitarbeiter aus meinem Team". Da nicht automatisch Gruppenmitglieder = Team-Mitglieder sind, und umgekehrt Überschneidungen in den Team-Mitgliedschaften waren, fiel die Gruppenmitgliedschaft aus.

 

Lösung:

- Im CallRouting wird eine Variable mit =9000 + gewählte Rufnummer errechnet.

- Diese Variable wird dann angerufen, wenn der Anrufer die Teammitglieder sprechen will.

=> Ein Anruf für den Mitarbeiter mit Nr. 123 wird dann also an 9123 umgeleitet, Mitarbeiter 124 dann 9124, 125 an 9125. Ein anderer Standort hat die 3xx-Rufnummerngasse, der dortige Mitarbeiter 345 würde also an 9345 weiterleiten usw. usw.

 

Jetzt gibt es eine Gruppe, die das Team von Mitarbeitern 123 und 124 darstellt (und noch einer Handvoll anderer Mitarbeiter auch). Diese hat mehrere Gruppenrufnummern, nämlich unter anderem die 9123 und 9124. Die Gruppe, die für 125 zuständig ist, hat dann die 9125.

 

Da, wo die Zuordnung etwas einfacher möglich ist (z.B. bildet der Außenstandort mit den 3xx-Rufnummern ein einziges Team), ist das primitiver gelöst: Die dortige Gruppe hat einfach die 93 als interne Nummer. Wenn jetzt Mitarbeiter 345 einen Anruf bekommt, und der Anrufer sich an die Teammitglieder durchstellen lässt, wäre das die 9345 -> in dem Fall ignoriert die Swyx einfach die überzähligen Ziffern und lässt Gruppe 93 klingeln (ohne dass da jeder Mitarbeiter einzeln aufgeführt werden muss).

 

Ist nachher einfacher als es hier vermutlich klingt :-)

 

[mac_key]

Klingt interessant und ist mindestens eine Lösung. Allerdings geht es mir hauptsächlich darum, den Beachtungsaufwand bei der Administration zu senken. Ich glaube das ist bei diesem Vorschlag eher schwierig.

[Tom Wellige]

Wenn Du willst, kannst Du meinen Vorschlag weiter verfolgen:

• Nimm Dir einen Testbenutzer und richte ihm eine neue GSE egel ein
• kopiere den folgenden Code per Copy&Paste in das Textfeld auf der Parameter Seite des Start Blocks
   

  Please find the IsUserInGroup function in the Function Collection (VBScript) and Function Collection (Lua) area of the Programming References section of the SwyxPEDIA here on Swyx Forum. 

   

• Verbinde den Start Block mit einem Skript Code Block.
• Auf der Parameter Seite fügst Du folgenden Code ein (alles was dort vorher drin gestanden hat bitte überschreiben!)

  if IsUserInGroup ("AAA") then
  	UseExit = 1
  elseif IsUserInGroup ("BBB") then
  	UseExit = 2
  elseif IsUserInGroup ("CCC") then
  	UseExit = 3
  elseif IsUserInGroup ("DDD") then
  	UseExit = 4
  elseif IsUserInGroup ("EEE") then
  	UseExit = 5
  else
  	UseExit = 0
  end if

• Die AAA, BBB, etc. sind jeweils Gruppennamen oder Gruppennummern (geht beides) wo Du prüfen musst, ob der Testbenutzer dort Mitglied ist. D.h. die kannst/musst Du entsprechend anpassen.
• Auf der Verbindungen Seite des Skript Code Blocks mußt Du noch weitere Ausgänge (1-5 gemäß Beispielcode) einschalten.
• Hinter jeden Ausang des Blocks kannst Du nun einen Durchstellen Block setzen, der auf die jeweilige Gruppe zustellt.

 

Ergebnis sollte sein:

 

Wenn der aktuelle Skriptbenutzer (Dein Testbenutzer) Mitglied in Gruppe AAA ist, wird der Anrufer an Gruppe AAA durchgestellt. Wenn er Mitglied in Gruppe BBB ist wird der Anrufer an BBB durchgestellt, u.s.w.

 

Damit kann ein Administrator ganz einfach über die Gruppenzugehörigkeit vom Testbenutzer festlegen, wo es noch überall klingeln soll.

 

Wenn das das ist was Du brauchst, können wir uns darüber unterhalten, wie Du dieses GSE Regel auf alle relevanten Benutzer verteilt bekommst.

 

 

[mac_key]

Sieht aus wie ich mir das vorgestellt habe. Da ist noch ein winziges Problem, das Script hat keinen Wert für sNumber, also die Durchwahl des Users.

Gebe ich den im VB-Script Block mit oder kann ich mir den im Startblock schon holen`?

 

[mac_key]

Sieht aus wie ich mir das vorgestellt habe. Da ist noch ein winziges Problem, das Script hat keinen Wert für sNumber, also die Durchwahl des Users.

Gebe ich den im VB-Script Block mit oder kann ich mir den im Startblock schon holen`?

Dim Users
    Set Users = g_PBXConfig.GetUserByAddress(sNumber)

wird bemerckert

[Tom Wellige]

Oops, sorry. Das kommt dabei heraus wenn man das nur runter schreibt und nicht ausprobiert. 

 

Das muss "sGroup" heissen. 

 

Ich passe das gleich mal oben an. 

 

[mac_key]

Hmmpf, hätte ich ja auch selber drauf kommen können, jedenfalls klappt das jetzt und tut exakt das was es soll!

Perfekt!

Jetzt ins rulePreProcessing?

[Tom Wellige]

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.

 

[Thomas Freidank]

Am 26.11.2017 um 17:57 Uhr sagte Tom Wellige:

Ups, Entschuldigung. Das kommt dabei heraus, wenn man das nur runter schreibt und nicht ausprobiert. 

 

Das muss "sGroup" heißen. 

 

Ich passe das gleich mal oben an. 

 

Das ist genau was ich suche, wie sieht den das Call Routing aus, ich bekomme keine Verbindung zur Rufnummer des Gruppenmitgliedes 

[Tom Wellige]

Die Zuordnung in der obigen Funnktion IsUserInGroup erfolgt über den Namen des Benutzers und nicht dessen Rufnummer. Da ein Benutzer ja beliebig viele interne Durchwahlen und externe Rufnummer zugeordnet haben kann, ist der Weg über den Namen der einfachste.

 

Die Funktion bekommt als Parameter den Namen einer Gruppe und schaut dann, ob der aktuelle Skript Benutzer (also der für den das Call Routing gerade läuft) sich in dieser Gruppe befindet.

 

Ist das wirklich exakt das, was Du brauchst?

[Thomas Freidank]

Wir haben mehrere Gruppen mit 2 oder mehr Mitgliedern.

Je nach Anruf der Gruppendurchwahl soll der Anruf weitergeleitet werden.

Die Persönlichen Rufnummen sollen aber nachwievor funktionieren, da hier bereits das Holiday Script im Call Routing aktiv ist

[Tom Wellige]

Das hat dann aber überhaupt nichts mit der obigen Funktion IsUserInGroup zu tun.

 

Da Gruppen selbst kein Call Routing haben, legt man dazu einen Dummy Benutzer an, gibt dem die ööfentliche Gruppen Nummer und das Call Routing, welches dann per "Durchstellen" an die Gruppe zustellt. Das ist auch nochmal etwas ausführlicher hier beschrieben:

• How to configure call routing for a group