wir haben eine Schnittstelle auf XMPP-Basis zwischen einer Call Center Anwendung und der MobyDick entwickelt und in Betrieb. Diese funktioniert so lange das Anrufvolumen der Warteschlangen relativ gering ausfällt auch sehr gut. Glühen die Leitungen haben wir verschiedene Probleme, welche nach langen Versuchen nicht mit den Mitteln der vorhanden XMPP-API zu lösen sind.
Hintergrund:
Es gibt “Arbeitsplätze” welchen fest Telefone zugeordnet sind. Agenten sind als flexible Benutzer für Warteschlangen konfiguriert. Agenten werden via Schnittstelle an frei wählbaren Arbeitsplätzen angemeldet und bekommen dadurch ihr Device zugeordnet. Ein Agent wird im Schnitt an acht Warteschlangen angemeldet.
Problem:
Befinden sich viele Anrufer in den Warteschlangen und ein Agent meldet sich via Schnittstelle am Arbeitsplatz und anschließend an seinen Warteschlangen (via queue.AgentLogin) an, führt das unweigerlich zu folgendem Ablauf:
Schritt 1: Anmeldung am Arbeitsplatz (bzw. am Telefon)
Schritt 2: Anmeldung an WS 1
Schritt 3: Anmeldung an WS 2
Schritt 4: Inbound-Call von WS 1
Schritt 5: Anmeldung an WS 3 (scheitert gegebenenfalls)
Schritt 6: Anmeldung an WS 4
Schritt 7: (…)
Alle weiteren “Anmelde-Befehle”, welche nach dem eintreffenden Inbound-Call noch abgesetzt werden, bereiten uns Probleme. Diese werden manchmal noch akzeptiert, manchmal auch nicht. Zumindest verursacht diese Konstellation inkonsistente Zustände. Diesbezüglich haben wir einiges Versucht: Zum Beispiel nach jedem Warteschlangenlogin sofort ein queue.AgentPause zu senden. Auch hier hatten wir Fälle in dem sich ein Inboundcall zwischen queue.AgentLogin und queue.AgentPause gedrängelt hat. Alles findet im Millisekundenbereich statt; trotzdem gibt es diese Ereignisse.
Unsere Vorstellung geht in die Richtung, dass queue.AgentLogin um einen Parameter zu ergänzen, mit dem man den Agent mit Anmeldung an eine Warteschlange zunächst in den Pausestatus versetzt und erst nach Anmeldung an der letzten Warteschlange diese Pausen zurücksetzt. Der Befehl “QueueAdd” aus der AMI kennt den Parameter “Paused”. Inwieweit können wir diesen via XMPP ansprechen?
Welche genaue MobyDick Version setzt ihr ein? Bei Versionen < 7.05.00 war ein kompatbiles (freies) Telefon zum An/Abmelden via XMPP an einer Warteschlange erforderlich, dies könnte euer Problem verursacht haben. Beginned mit Version 7.05.00 wurde das verändert, jetzt funktioniert es auch ganz ohne Telefon.
Wir sind mit 7.3 gestartet und haben die Schnittstelle ab 7.5 auf die dann neuen verfügbaren XMPP-Befehle umgestellt. Im Moment sind wir mit 7.05.01 unterwegs und planen auf 7.6 upzudaten. Die Einführung von queue.AgentLogin und queue.AgentPause mit der 7.5 hat uns schon ein erhebliches Stück weiter gebracht. Jetzt ist noch Feintuning angesagt, sodass die Schnittstelle auch bei viel Betrieb (im Sinne von vielen Inbound-Anrufen) stabil funktioniert. Die Problemstellung im ersten Post habe ich hoffentlich verständlich ausgedrückt. Wenn nicht, bitte nachhaken.
das abarbeiten der Queue Login/Logout Commands dürfte seit 7.5 nichts mehr mit eventuell parallel geführten Telefonaten zu tun haben.
Ich nehme zur Sicherheit ein Bug Ticket auf.
es ist wohl korrekt, dass die XMPP-Schnittstelle keine Probleme damit hat. Für unsere Anwendung wäre es nur sehr hilfreich, wenn die Initialisierungsphase (und dazu zählt bei uns auch die Anmeldung an allen Warteschlangen) ungestört - sprich ohne den Durchbruch eines Inbounds - durchgeführt werden könnte.
Ist es aus eurer Sicht ein guter feature requests queue.AgentLogin um den Pause-Parameter zu erweitern?
Wie/warum scheitert die Anmeldung an WS3 falls der Agent nun schon telefoniert? Gibt die XMPP Schnittstelle einen Fehler zurück? Wird der Agent nicht eingebucht?
Der Pause Parameter würde das ganze nur verzögern. Letzten Endes müsste ich ja auch hier irgendwann sequentiell alle Queues un-pausen.
Mit “Durchbruch eines Inbound-Calls” meine ich, dass die gesamte Anmeldephase durch einen ankommenden Anruf gestört wird. Wie du bereits geschrieben hast, hat die XMPP-Schnittstelle seit MobyDick-Version 7.5 damit kein Problem mehr, jedoch die Call Center Software. Alle konventionellen Call Center TK-Anlagen wie Alcatel, Siemens oder Avaya haben für genau diesen Anwendungsfall die Funktion “Agent pausiert bei Anmeldung”.
Wir haben nun diese Funktion nachgebaut und senden direkt nach “queue.AgentLogin” ein “queue.AgentPause”. Da die Latenz des XMPP-Server zwischen diesen beiden Befehlen streckenweise bei gut 900 Millisekunden liegt, hat ein wartendes Inboundgespräch in einer Queue genug Zeit, um durchzubrechen.
Meine Vermutung ist, dass der vorhandene Parameter “Paused” am Befehl “QueueAdd” aus dem AMI genau diese Lücke nicht zulässt. Korrekt, nachdem die Anmeldephase vorbei ist, werden dann alle gesetzten Pausen zurückgesetzt.
das ist sicher auch ein Weg, dass Problem zu umschiffen. Wir werden das in den nächsten Tagen einmal testen.
Können wir aus deiner Sicht ohne große Sorgen auf Version 7.06 updaten? Hat sich an der API etwas Gravierendes verändert, was die Schnittstelle möglicherweise lahmlegen könnte? Bis auf die obligatorische Anlage der Pausengründe habe ich nichts im Hinterkopf. Du?
abgesehen von den formalen Pausen sollte es kein Hindernis geben. Die Queue-API hat sich nur sehr wenig geändert.
Eine Rückmeldung bezüglich der Queue Anmeldung nach eurem Experiment wäre nett!
wir haben uns zu deinem Vorschlag die Warteschlangenanmeldungen vor die Arbeitsplatzanmeldungen zu setzen noch einmal verständigt und sind darauf gestoßen, dass die Schnittstelle auch Mitarbeiter unterstützt, welche fest mit einem Telefon verbunden sind. Somit ist der Schritt “Arbeitsplatzanmeldung” bei denen gar nicht erforderlich und wir stehen erneut vor dem Problem.
ich kann das mal zur Diskussion aufnehmen.
Vielleicht wäre aber ein globaler Schalter für “Benutzer ist gerade nicht erreichbar” eine bessere und noch dazu flexiblere Lösung.
Ablauf wäre dann:
Benutzer für zumindest Inbound-Calls evtl. aber sogar alle Calls sperren (neuer Aufruf)
Dinge erledigen, etwa Queue An-/Abmeldungen etc.
Benutzer wieder freigeben (neuer Aufruf)
Wir würden dadurch eine Art “Transaktions-Lock” auf Benutzerebene erhalten, im Client würde das Telefon des Users während dessen ggf. “gelb” oder gar “rot” werden.
das ist natürlich auch eine Möglichkeit um den Anmeldeprozess ungestört durchführen zu können.
Die Frage dabei ist, welchen Status hat der Agent unmittelbar nach Anmeldung an der Queue gegenüber der Queue. Ich erinnere mich, dass ihr uns anfänglich darauf hingewiesen habt, dass es für die Verteilungsalgorithmen und Statistiken von Warteschlangen nicht von Vorteil ist, wenn diesen Agenten angehören, welche zum Beispiel kein Telefon haben, DND am Telefon aktiv haben oder eben “global nicht erreichbar” sind.
in den Release-Notes von 7.11.00 schreibt ihr unter anderem “API: man kann sich nun an mehreren Warteschlangen gleichzeitig anmelden/abmelden/pausieren.”.
Frage 1:
Ist da etwas für unsere oben angesprochenen Themen dabei?
die API Doku scheint leider nicht komplett zu sein, wir werden dies nachholen.
Das Feature schein so zu sein das man bei AgentLogin/AgentLogout/AgentPause/AgentUnpause das “queue” Attribut weglassen kann. Dadurch wird der betreffenden Agent an allen seinen zugeordneten Queues nacheinander angemeldet/abgemeldet etc.
Wir können das intern auch nur über eine Schleife lösen da es ein echtes “parallel” anmelden einfach nicht gibt. Ob dies nun eines Deiner Probleme löst, zweifle ich an. Es macht halt einige Dinge etwas einfacher.
