wir haben hier mehrere Rufgruppen, die auf andere Rufgruppen abwerfen. Im Prinzip funktioniert der Abwurf. Das Problem ist, die Rufgruppen werfen immer erst nach dem Timeout ab, auch wenn alle Mitglieder der Gruppe nicht erreichbar sind (nicht erreichbar sind sie hier, wenn sie die DND Taste drücken). Dadurch bekommt ein Anrufer von extern für ca. 10 Sekunden ein Freizeichen, obwohl intern kein Telefon klingelt. In der Commander Version 5 hatten die Gruppen, meiner Meinung nach, direkt abgeworfen, wenn kein Gruppen Mitglied erreichbar war.
die Verwendung der Endgeräte-Funktionen ist immer etwas problematisch. In deinem Fall sind die Telefone bei Beginn des Anrufes in die Rufgruppe erstmal erreichbar. Deshalb wird der Anruf in die Rufgruppe weitergestellt. Der Teilnehmer wird gerufen, erst jetzt kann das snom per SIP response 480 “Do Not Disturb” mitteilen, dass die DND-Taste gedrückt ist.
Alternativ zur Rufgruppe könntest du auch eine Warteschlange mit dynamischen Agenten verwenden. Hier können sich dann die Mitglieder per Tastendruck oder per Client aus der Warteschlange ausbuchen/pausieren, falls sie keine Anrufe mehr entgegen nehmen möchten. Vielleicht hilft dir der Ansatz weiter.
Danke für Deinen Antwort, Warteschlangen sind in diesem Fall leider keine Option.
Ich möchte nochmal auf das Problem zurück kommen, und formuliere dazu Deine Antwort etwas um:
“In deinem Fall sind die Benutzer bei Beginn des Anrufes in die Rufgruppe erstmal erreichbar. Deshalb wird der Anruf in die Rufgruppe weitergestellt. Die Teilnehmer werden gerufen, erst jetzt können die snom’s per SIP response 480 “Do Not Disturb” mitteilen, dass die DND-Taste gedrückt ist.”
Soweit ist alles OK und wird auch so erwartet, ab jetzt kommt meiner Meinung nach das Problem. Wenn jetzt alle Teilnehmer der Gruppe, bzw. deren Telefone, DND signalisieren, dann sollte die Aktion “nicht erreichbar” der Gruppe zuschlagen, oder habe ich hier einen Denkfehler. Vielmehr läuft der Anruf weiter, bis die Aktion “keine Antwort” zuschlägt, was ich im ersten Post als Timeout bezeichnet habe. Im Commander 5 haben die Gruppen meiner Meinung so funktioniert, Version 6 haben wir nicht eingesetzt. Noch eine Anmerkung zur DND Taste, die ist überall deaktiviert, und DND liegt auf eine Funktionstaste, damit ein Lämpchen leuchtet, das macht aber keinen Unterschied, oder?
zu dem DND-Problem bei Rufgruppen habe ich ein Ticket aufgenommen. Hier entsteht in der Abhandlung der Rufgruppe durch die snom-Funktion noch ein Lücke. Ich halte dich auf dem laufenden sobald es etwas Neues gibt.
Aktuell könnte man das Problem wohl durch ein Skript erschlagen, welches wie in der Vorgängerversion einen Multi-Dial absetzt. Hierzu würde ich dich dann an den Support verweisen, weil dies sehr anlagen-individuell sein wird.
Zum Lämpchen, solange du die snom-interne Funktion verwendest macht das keinen Unterschied.
aktuell hat sich hier noch nichts geändert. Was du allerdings alternativ tun könntest ist, dass du anstatt einer Rufgruppe eine Warteschlange mit dyn. Agenten verwendest. Hier können sich die Agenten ein-/ausbuchen und pausieren. Anstatt der DND Taste würden sie dann eine snom-Funktionstaste drücken, siehe auch https://www.pascom.net/doc/de/teams/
Danke für die prompte Antwort. Wenn ich das mache, kann ich aber die Reihenfolge nicht bestimmen, da unsere Warteschlange hintereinander geht.
Oder gibt es eine Variante, die wie folgt aussieht:
Apparat - wenn eingebucht, dann Annahme sofort
Apparat - wenn Apparat 1 eingebucht mit 3 sec Verzögerung, sonst sofort
Apparat - wieder 3 Sekunden später
Wenn ich verschiedene Gruppen mache, dann unterbricht es mir die Warteschlangenmusik.
Danke
den Mitglieder Timeout kannst du über Basisdaten->Mitglied-Timeout setzen. Würde ich aber nicht zu kurz machen, damit der Agent auch eine Chance hat den Anruf anzunehmen, 3 x klingeln sind ca. 12 Sekunden. Bei der Rufstrategie würde ich dann “alle klingeln” wählen und zusätzlich bei den Mitgliedern eine Priorität festlegen oder du verwendest die Strategie “nacheinander”. Hier muss man ein wenig spielen um die richtige Kombi zu finden. Hängt halt davon ab, ob sich die Agenten ein-/ausbuchen, pausieren usw.
Die von Dir gebrachte Lösung heißt, daß am Anfang alle Telefone läuten. Bei der Lösung nacheinander kann ich keine dynamischen Mitglieder haben, da es sonst die Reihenfolge immer nach Einbuchen festlegt. Wie kann man eine Reihenfolge fixieren?
zur Priorität, z.B. Agent A (prio 0), Agent B (prio 0), Agent C (prio 1) und Agent D (prio 2). Unabhängig von der Strategie sollte Agent C erst dann einen Anruf erhalten, wenn Agent A und Agent B nich zur Verfügung stehen. Agent D sollte erst Anrufe zugestellt bekommen, wenn Agent A,B und C nicht zur Verfügung stehen.
Du kannst anstatt dyn. Agenten auch statische verwenden, wenn du pausieren Funktion usw. nicht benötigst. Alternativ könntest du die Agenten nicht ein-/ausbuchen lassen sondern nur pausieren.
Hallo, wir haben hier den Ablauf etwas umgebaut, Gruppe auf Gruppe gibt es kaum noch, dadurch haben wir das Problem nicht mehr. Zusätzlich nutzen wir DND nicht mehr, sondern die Mitarbeiter melden sich vom Telefon ab. Das mussten wir machen, da ab irgendeiner Commander Version DND anders interpretiert wurde (Ist etwas ungenau, bekomme es aus dem Kopf gerade nicht besser zusammen). Vielleicht könnte abmelden auch bei diesem Problem helfen.
Hallo, Danke, das Problem habe ja andere VOIP-Anlagen auch. Kann ich beim Einbuchen eine Priorität mitgeben? Wenn nein, könnte mir ein cron-job helfen, der alle 5 Minuten prüft, ob die angemeldeten Telefone in der richtigen Reihenfolge eingebucht sind. Wäre das möglich?
wenn ich dich richtig verstehe, sollen die Agenten einfach immer in der gleichen Reihenfolge angerufen werden, sofern sie eingebucht sind?
Mit der mobydick 7.11 könntest du hierzu auch das Skill-Based-Routing “missbrauchen”. Die genaue Logik wird ja über ein Skript gesteuert. (Details gibt’s in der Release Keynote und in der Wiki).
Die grundsätzliche Idee ist hier, das Skill-Based-Routing Lua-Skript so zu manipulieren, dass immer eine feste Reihenfolge zurückgegeben wird, anstatt die Labels auszuwerten.
Grüße,
Jan
PS: Ein solches Skript standardmäßig mitzubringen steht bei uns auf der TODO-Liste, aber es gibt noch keinen festen Zeitplan dafür.
So, jetzt habe ich mich 2 Std. lang geplagt, ich bekomme das nicht hin. Wie soll das skill-based-routing aufgebaut sein? Wenn es nicht zu umständlich ist, könnte ich die Einstellung per mail bekommen?
Jetzt bin ich bei den scripts gelandet. Wäre es möglich, zuerst abzufragen, ob ein Telefon erreichbar ist und dann per Anrufverteilung auf die richtige Warteschlange zu gehen?