DE102006005814A1

DE102006005814A1 - Verfahren und Vorrichtung zum Verarbeiten eines Kontaktes mit einem Client innerhalb eines Kontaktverteilers in Verbindung mit computerunterstützten automatischen Rufvermittlungen

Info

Publication number: DE102006005814A1
Application number: DE102006005814A
Authority: DE
Inventors: Michael Downers Grove Peters
Original assignee: Rockwell Electronic Commerce Technologies LLC; Rockwell Electronic Commerce Corp
Current assignee: Rockwell Firstpoint Contact Corp
Priority date: 2005-02-08
Filing date: 2006-02-08
Publication date: 2006-10-05
Also published as: US20060176805A1; GB2422983A; GB2422983B; US7688804B2; GB0602452D0

Abstract

Die Erfindung betrifft ein Verfahren zum Verarbeiten eines Kontaktes mit einem Clienten innerhalb eines Kontaktverteilers, wobei das Verfahren aufweist: DOLLAR A Bereitstellen eines ersten SIP-End-zu-End-Nutzeragenten und eines zugehörigen zweiten SIP-End-zu-End-Nutzeragenten für jedes Betriebsmittel einer Vielzahl von Betriebsmittels des Kontaktverteilers; DOLLAR A Aufsetzen einer Kommunikationsverbindung zwischen dem Clienten und einem Betriebsmittel der Vielzahl der Betriebsmittel durch den bereitgestellten ersten End-zu-End-Nutzeragenten des Betriebsmittels; DOLLAR A Überwachen der Kommunikationsverbindung zwischen dem Clienten und dem Betriebsmittel mit einem Verfügbarkeitsserver; DOLLAR A Detektieren eines Fehlers des ersten End-zu-End-Nutzeragenten mit dem Verfügbarkeitsserver; und DOLLAR A Übertragen der Verbindung von dem ersten End-zu-End-Nutzeragenten zu dem zugehörigen zweiten End-zu-End-Nutzeragenten des Betriebsmittels mit dem Verfügbarkeitsserver, wenn der erste End-zu-End-Nutzeragent scheitert.

Description

Gebiet der Erfindung
Das Gebiet der Erfindung betrifft Computersysteme und insbesondere automatische Anrufverteiler.

Hintergrund der Erfindung

Automatische Anrufverteiler (ACDs) sind bekannt. Solche Systeme werden typischerweise von Organisationen benutzt, um eine große Anzahl von Anrufern durch ein öffentliches Fernsprechwählnetz (PSTN) zu bedienen. Typischerweise sind eingehende Anrufe auf eine allgemeine Rufnummer der Organisationen gerichtet und werden basierend auf einigen Kriterien (z.B. Agentenwartezeit) verteilt.

Zusätzlich zur Verarbeitung von eingehenden Anrufen können automatische Anrufverteiler auch ausgehende Anrufe verarbeiten. Typischerweise überwacht ein Steuergerät eine Arbeitsbelastung seiner Agenten. Wo eine Arbeitsbelastung von empfangenen Anrufen unter einen Schwellwert fällt, kann das Steuergerät damit beginnen, ausgehende Anrufe zu initiieren.

Zusätzlich zum Platzieren und Verteilen von Anrufen kann ein automatischer Anrufverteiler auch Dokumente identifizieren und auf Agentenendgeräten als eine Hilfe zur Verarbeitung der Anrufe anzeigen. Im Falle von eingehenden Anrufen können die Anrufe zusammen mit einem Rufnummeridentifizierungsdienst (DNIS) und/oder einer automatischen Rufnummeridentifizierung(ANI)-Information empfangen werden. ANI kann dazu genutzt werden, einen Anrufer zum selben Augenblick zu identifizieren, als der Anrufer dem ACD übergeben wird. Das Steuergerät des ACD kann die ANI-Information nutzen, um Teilnehmer-Aufzeichnungen zu erhalten und auf einem Endgerät des Agenten, der ausgewählt wurde, den Anruf zu verarbeiten, im selben Augeblick anzuzeigen, in dem der Anruf dem Agenten übergeben wird.

Zusätzlich kann eine Textinformation auf einem Endgerät des Agenten angezeigt werden, der den Agenten durch eine Verkaufspräsentation leitet. Eine DNIS-Information kann zum Identifizieren eines beabsichtigten Anrufziels und zum Auswählen einer geeigneten Verkaufspräsentation zur Verwendung durch den Agenten basierend auf dem beabsichtigten Anrufsziel genutzt werden.

Während automatische Anrufverteiler relativ gut arbeiten, sind sie nicht besonders gut geeignet für das Internet. Die Standards, die für die Verarbeitung von leitungsvermittelnden Anrufen und zum Austauschen von Steuerinformation durch das PSTN genutzt werden, können innerhalb des Internets nicht genutzt werden. Oft sind die Elemente von Internet-Kontaktverteilern über geografisch unterschiedliche Orte verteilt. Als Ergebnis wird das Management der Betriebsmittel und die Detektion von Systemfehlern sehr viel schwieriger. Aufgrund der Wichtigkeit von Internet-Kontaktverteilern existiert das Bedürfnis für ein Verfahren und eine Vorrichtung zum Detektieren eines Systemfehlers, welches flexibler ist.

Kurzbeschreibung der Zeichnungen
1 ist ein vereinfachtes Blockdiagramm eines Verbindungspfades eines fehlertoleranten automatischen Kontaktprozessors in Bezug auf ein veranschaulichtes Ausführungsbeispiel der Erfindung;
2 ist ein Blockdiagramm, das den Verbindungspfad von 1 im Kontext einer Nutzung innerhalb eines automatischen Kontaktverteilers zeigt; und
3 zeigt den Verbindungspfad der 1 nach einem detektierten Fehler.
Zusammenfassung
Ein Verfahren und eine Vorrichtung zum Verarbeiten eines Kontaktes mit einem Clienten innerhalb eines Kontaktverteilers werden bereitgestellt. Das Verfahren beinhaltet die Schritte des Bereitstellens eines ersten SIP-End-zu-End-Nutzeragenten und eines zugehörigen zweiten SIP-End-zu-End-Nutzeragenten für jedes Betriebsmittel einer Vielzahl von Betriebsmitteln des Kontaktverteilers und des Aufsetzens einer Kommunikationsverbindung zwischen dem Clienten und einem Betriebsmittel der Vielzahl des Betriebsmittels durch den bereitgestellten ersten End-zu-End-Nutzeragenten des Betriebsmittels. Das Verfahren beinhaltet weiter die Schritte einer Überwachung der Kommunikationsverbindung zwischen dem Clienten und dem Betriebsmittel mit einem Verfügbarkeitsserver, wobei der Verfügbarkeitsserver einen Fehler des ersten End-zu-End-Nutzeragenten detektiert und der Verfügbarkeitsserver die Verbindung von dem ersten End-zu-End-Nutzeragenten zu dem zugehörigen zweiten End-zu-End-Nutzeragenten des Betriebsmittels überträgt, wenn der erste End-zu-End-Nutzeragent scheitert.
Detaillierte Beschreibung eines veranschaulichten Ausführungsbeispiels
1 ist ein vereinfachtes Blockdiagramm eines fehlertoleranten Kontaktverteilungssystems 10, welches allgemein in Bezug mit veranschaulichten Ausführungsbeispielen der Erfindung gezeigt ist. 2 ist ein Blockdiagramm des Kontaktverteilungssystems 10, das in einem Kontext einer Benutzung gezeigt ist. Das Kontaktverteilungssystem 10 kann durch eine Organisation benutzt werden, um Kontakte zwischen Clienten und Agenten der Organisation zu verarbeiten.
Kontakte zwischen den Clienten der Organisation bestehen vor allem durch das Internet 20 in einem geeigneten Internet-Format (beispielsweise E-Mail, Instant Messaging (IM), Voice-over-Internet-Protocol (VoIP), etc.). Zusätzlich können Kontakte auch unterstützt werden, die zumindest teilweise durch das PSTN 24 als leitungsvermittelte Anrufe auftreten. Der Ausdruck „Kontakt" wird hier als ein sehr allgemein gehaltener Begriff verwendet, der sich auf Kommunikationssessions bezieht, die ausschließlich durch das Internet stattfinden, und auf Kommunikationssessions bezieht, die zumindest teilweise durch das Internet und teilweise durch das PSTN 24 stattfinden.
Die Fehlertoleranz des Systems 10 kann für jeden Kontakt mittels eines Verfügbarkeitsproxys und eines Paars von End-zu-End-Nutzeragenten (B2BUAs) bereitgestellt werden, wo die B2BUAs im Wesentlichen arbeiten, wie in Internet Enginerring Task Forces (IETF) RFC #3261 beschrieben. Ein B2BUA des Paars der B2BUAs kann genutzt werden, um eine Verbindung zwischen dem Clienten und Agenten herzustellen, und der andere B2BUA kann als Backup genutzt werden. Wenn der erste B2BUA scheitert, detektiert der Verfügbarkeitsproxy den Fehler und überträgt die Verbindung auf den zweiten B2BUA.
Wie hierin benutzt, bezieht sich der Ausdruck B2BUA auf eine Softwareanwendung, die auf einem Server (beispielsweise einer Zentraleinheit (CPU)) arbeitet. Zusätzlich können die B2BUAs 26, 28 auch auf verschiedenen Servern arbeiten, so dass der zweite B2BUA dann fortsetzen kann, auf dem zweiten Server zu arbeiten, (falls der erste Server auf dem der erste B2BUA arbeitet) scheitern sollte.
Allgemein bezieht sich hier eine auf einen Verarbeitungsschritt gemachte Referenz auch auf den Prozessor (z.B. die Subroutine), der den Schritt durchführt.
Im Allgemeinen kann das System 10 durch eine einer Anzahl von verschiedenen Organisationen (z.B. gewerbliche, umweltpolitische, politische etc.) genutzt werden, um das Programm der Organisation zu fördern. Um das Programm der Organisation an ihre Clienten 12, 14, 16, 18 zu verkünden, kann die Organisation eine oder mehrere Telefonnummern oder Internetadressen (URLs) durch Werbung oder anders veröffentlichen, welche die Kommunikationspfade zu der Organisation identifizieren. In diesem Fall werden Kontakte durch den Clienten durch einen eingehenden Kontakt zum System 10 initiiert.
Alternativ kann die Organisation Kontaktlisten erwerben, die Kommunikationssystemadressen (beispielsweise Telefonnummern, Internetadressen (URLs), E-Mail-Adressen) von potentiellen Clienten beinhalten. In diesem Fall kann die Organisation die Kontakte mit den Clienten über eine ausgehende Kampagne durch den Host 30 des Systems 10 initiieren. Das Kontaktverteilungssystem 10 kann Kontakte unter Verwendung des Session Initiation Protocols (SIP), wie beschrieben in IETF RFC #3261 verarbeiten. Diesbezüglich kann das System eingehende Kontakte empfangen oder ausgehende Kontakte durch das Internet 20 oder durch das Internet 20 und das PSTN 24 unter Verwendung eines Gateways 22 platzieren. Die Verwendung eines SIP-Protokolls erlaubt zwei oder mehreren Teilnehmern eine Kommunikationssession zu etablieren, wobei ein oder mehrere Medienströme mit jedem Teilnehmer ausgetauscht werden. Die Medienströme können Audio, Video oder irgendeine andere Kombination von Internet-basierten Kommunikationsmedien sein. Das simultane Aufsetzen und Verwenden von Audio und Video durch das System für einen Ruf zwischen zwei oder mehreren Parteien ist ein Beispiel.
Das System 10 kann einen Host 30 beinhalten, der Rufe abgibt und empfängt und diese Rufe zu Agenten 34, 36 dieser Organisation verteilt. Eine oder mehrere Auswahlapplikationen 38 können innerhalb des Hosts 30 zum Detektieren von Rufen und zum Auswählen eines Agenten zur Verarbeitung jedes Rufes angeordnet werden.
Rufe können zu der Organisation abgegeben und von der Organisation (d.h. das System 10) unter Verwendung eines von einer Vielzahl verschiedener Kommunikationsvorrichtungen empfangen werden. Z.B. kann ein Client Rufe durch ein SIP-Telefon 12 oder einen Personalcomputer 14, der mit einer SIP-Kommunikationssoftware ausgestattet ist und der direkt mit dem Internet 20 oder mittels eines Internetserviceproviders (ISP) verbunden ist, abgeben oder empfangen.
Z.B. kann ein Client eine veröffentlichte Telefonnummer der Organisation (beispielsweise 1234567890) in sein SIP-Telefon 12 eingeben, um die Organisation zu kontaktieren. Die Eingabe einer Telefonnummer in das SIP-Telefon 12 veranlasst das Telefon 12 eine Anzahl von Nachrichten zu bilden, die letztlich in einem Ruf, der an die Organisation gerichtet ist, resultieren.
Falls ein PSTN-Teilnehmer 16, 18 wünschte, die Organisation zu kontaktieren, würde der Teilnehmer 16, 18 in gleicher Weise dieselbe Telefonnummer in sein Telefon eingeben. Die eingegebene Nummer würde das PSPN 24 veranlassen, den Ruf zu dem Gateway 22 zu leiten. Das Gateway 22 kann eine Voice-over-Internet-Protocol(VoIP)-Applikation bestimmen, um den Ruf zu bedienen. Wenn die VoIP-Applikation bestimmt ist, um den Ruf zu bedienen, kann ein Ruf, der durch das PSTN 24 initiiert ist, in der gleichen Weise wie ein Kontakt von einem SIP-Telefon 22 verarbeitet werden.
Um die Organisation zu kontaktieren, muss das Telefon 12 zuerst einen Proxy-Server lokalisieren. Um einen Proxy-Server zu lokalisieren, kann das Telefon 14 zuerst eine DNS-SRV-Suche durchführen, um einen Internet-Proxy-Server 21 (beispielsweise bei prox.com) zu lokalisieren. Auf das Lokalisieren eines Proxy-Servers kann das Telefon ein SIP INVITE 100 bilden, das die eingegebene Telefonnummer beinhaltet, und die Paketnachricht zu dem Proxy-Server 21 senden. Wie hierin verwendet, ist ein INVITE eine Internet-SIP-Nachricht, die gemäß IETF RFC #3261 gebildet ist.
Der Proxy-Server 21 identifiziert zuerst das INVITE und leitet dann das INVITE zu einer zu der eingegebenen Telefonnummer zugehörigen URL oder URI. Als ein erster Schritt des Weiterleitens des INVITEs kann der Proxy-Server 21 eine Anfrage zu einem Registrierungsserver 19 senden, um eine URL der Organisation zu identifizieren. Der Registrierungsserver 19 dient als ein Registrator für PSTN-Telefonnummern, die durch Web-Einheiten registriert sind. Die Registrierung mit dem Registrierungsserver 19 bedeutet in diesem Fall ein Registrieren einer URL, die zu der registrierten PSTN-Telefonnummer zugehörig ist.
Innerhalb des Registrierungsservers 19 kann die Telefonnummer mit den SIP INVI-TEs als ein Zeiger benutzt werden, um eine Speicherstelle innerhalb einer Nachschlagetabelle zu identifizieren. Innerhalb der identifizierten Speicherstelle kann eine URL der registrieren den Webeinheit sein. In diesem Fall kann die registrierende Webeinheit die Organisation sein und die URL, registriert durch die SIP-Einheit, kann eine Agentenauswahlapplikation 38 innerhalb des Hosts 30 des Systems 10 sein. In diesem Beispiel kann der Host 30 einen Domainnamen „host.com" haben und kann die URL „1234567890@host.com" zur Verwendung mit der registrierten Telefonnummer registriert haben.
Das Präfix „1234567890" innerhalb der URL kann als ein Bezeichner verwendet werden, um das INVITE zu der Applikation 38 zu leiten, und als Bezeichner für einen Ruftyp verwendet werden. Tatsächlich kann der Host 30 viele verschiedene Telefonnummern mit dem Registrierungsserver 19 registrieren, wobei jede Registrierung die Applikation 38 identifiziert und jedes Präfix einen verschiedenen Ruftyp für die Applikation 38 identifiziert. Alternativ können die Präfixe als ein RoutingBezeichner verwendet werden, um jeden Ruftyp zu verschiedenen Agentenauswahlapplikationen 38 zu leiten.
Um das INVITE an den Host 30 weiterzuleiten, kann der Proxy 21 den registrierten Domainnamen in ein Zieladressfeld des SIP-INVITEs einfügen. Sobald das Adressfeld des INVITEs zu der dem Host zugehörigen URL geändert worden ist, kann der Proxy-Server 21 das INVITE zu dem Host weiterleiten.
Innerhalb des Hosts 30 kann ein Nutzeragent vorgesehen werden, der jedes modifizierte INVITE empfängt und identifiziert. Während jedes INVITE empfangen wird, vergleicht ein Ruftypisierungsprozessor innerhalb des Nutzeragenten das Präfix der Zieladresse mit einer Liste von registrierten PSTN-Telefonnummern, um diese Rufe zu identifizieren, die zu den Agenten 34, 36 geleitet werden, und um einen Ruftyp dieser Rufe zu bestimmen. Sobald das INVITE als ein für einen Agenten Beabsichtigtes bestimmt worden ist, kann das INVITE zu der entsprechenden Agentenauswahlapplikation 38 weitergeleitet werden. Die Applikation 38 kann das INVITE parsen, um einen Bezeichner der gewählten Telefonnummer und die URL des Anrufers 12 zu erhalten.
Die gewählte Telefonnummer kann verwendet werden, um einen Inhalt des Rufes zu identifizieren. Die URL des Anrufers 12 kann eine Information über frühere Kontakte mit diesem Anrufer 12 bereitstellen.
In ähnlicher Weise können SIP-INVITE für Kommunikationssessions unter verschiedenen Formaten, (beispielsweise IM, E-Mail, etc.) gebildet werden. In jedem Fall kann ein Kommunikationsformat unter Verwendung eines Session-Description-Protocols (SDP), wie in IETF RFC #2327 beschrieben, ausgehandelt werden.
Innerhalb der Applikation 38 kann ein Agent 34, 36 ausgewählt werden, um einen Ruf von einer Agentenliste zu verarbeiten. Die Agentenliste kann eine aktuelle Liste (und universal resource indicators (URIs) oder (URLs)) von Agenten 34, 36 beinhalten, die bei dem Host 30 angemeldet sind und aktuell verfügbar sind, um Rufe zu empfangen. Auch kann eine referenzierte Liste von Qualifikationen (beispielsweise Ruf- oder Kontakttypen) innerhalb der Agentenliste beinhaltet sein, für welche jeder Agent kompetent ist.
Der Agent 34, 36 kann basierend auf einer Leerlaufzeit oder auf einer Qualifikation beim Verarbeiten dieses bestimmten Typs des Kontakts ausgewählt werden. Auf das Auswählen des Agenten 34, 36 kann die Applikation 38 den Kontakt zu dem ausgewählten Agenten (beispielsweise 34) in einer solchen Weise weiterleiten, als dass die Nachrichten zwischen dem Agenten und dem Clienten durch ein B2BUA 26, 28 geleitet werden. Die Applikation kann dies auf eine Vielzahl von Wegen tun (beispielsweise unter Verwendung eines Verfügbarkeitsservers 32).
Wie hierin verwendet, ist ein B2BUA 26, 28 ein Prozessor (beispielsweise ein Router), der mit einer ersten Adresse adressierte Pakete empfängt und die Pakete zu einer zweiten Adresse weiterleitet. Das Weiterleiten innerhalb eines B2BUAs 26, 28 kann auf Vorgaben eines Prozesses innerhalb des Kontaktcenters 10 basieren, das für das Steuern der Behandlung der Kontakte verantwortlich ist.
Der Verfügbarkeitsserver 32 kann zwei Funktionen bedienen. Zusätzlich zum Weiterleiten eines SIP-INVITEs von dem Host 30 zu dem geeigneten B2BUA 26, 28 kann der Verfügbarkeitsserver 32 auch die Verfügbarkeit der B2BUAs 26, 28 zum Zwecke eines Detektierens des Fehlers eines jeden bestimmten B2BUAs 26, 28 überwachen.
Die B2BUAs 26, 28 arbeiten, um die URL der Agenten 34, 36 vor jeglichen bedienten Clienten 12, 14, 16, 18 zu verbergen. Das Verbergen der URL der Agenten 34, 36 vor den Clienten 12, 14, 16, 18 wird durchgeführt, um der Organisation zu erlauben, die Agentennutzung effektiver zu steuern und die Clienten 12, 14, 16, 18 davor zu hindern, die Agenten direkt zu kontaktieren, ohne zuerst die Organisation zu kontaktieren (beispielsweise den Host 30).
Auf der Agentenseite kann das B2BUA 26, 28 eine Dritte-Partei-Anruf-Steuerung (wie unter SIP definiert) verwenden, um Agententelefone zur Agentenseite des B2BUA 26, 28 zum Zwecke des Verbundenwerdens mit einem Anrufer zu verbinden. Das Ereignis, das die Agentenseite des B2BUAs 26, 28 triggert, um die Dritte-Partei-Anruf-Steuerungssoftware für ein bestimmtes Agententelefon zu initialisieren, kann ein Agentensignieren mittels einer Desktop-Applikation sein.
Eine Verbindung des Agenten 34, 36 zu einem B2BUA 26, 28 resultiert in der Schaffung eines ersten Streckenabschnitts der Verbindung während eines Kontaktes zwischen dem Agenten 34, 36 und einem Clienten 12, 14, 16, 18. Der zweite Streckenabschnitt der Verbindung erfolgt, wie unten beschrieben, wenn ein Kontakt dem Agenten 34, 36 zugeteilt wird.
Zusätzlich zum Verbergen der URL des zugeteilten Agenten 34, 36 stellt das B2BUA 26, 28 eine geeignete Stelle zum „Parken" eines Rufes bereit. Falls beispielsweise alle Agenten 34, 36 beschäftigt sind, kann das B2BUA 26, 28 dann verwendet werden, um den Anrufer zu einer interaktiven Sprachserver-Einheit (IVR) zu verbinden, bis ein Agent verfügbar wird. Innerhalb der IVRs können zusätzliche Informationen von dem Kontakt gesammelt werden.
Auf der Anruferseite kann das B2BUA 26, 28 SIP-Rufe akzeptieren und Meldungen und Medien zum Rufersystem im Namen des Anrufers weiterleiten. Sobald der Anrufer wesentlich bei dem B2BUA 26 „geparkt" ist, können Kontakt-Center-Applikationen dem B2BUA 26, 28 leiten, die Meldungen oder die Medienströme des Rufers zum Zwecke der Verarbeitung und letztlich zum Verbinden mit einem Agenten zu manipulieren.
Die Agenten-Auswahl-Applikation 38 kann eine SIP-Sofortnachricht zu dem B2BUA (beispielsweise 26) senden, die das SIP-INVITE und einen Bezeichner des Agenten oder eines Medienservers für Meldungen (beispielsweise ein IVR, etc.), beinhaltet. Die Sofortnachricht zu dem B2BUA kann den B2BUA 26 veranlassen, dass der B2BUA 26 ein Weiterleiten zum Zwecke des Schaffens eines zweiten Streckenabschnitts des Kommunikationspfads zwischen dem B2BUA 26 und dem Clienten 12 durchführt. Die Weiterleitungsinformation kann in einem Dauerspeicher (beispielsweise in einer Datei einer Datenbank des B2BUAs 26) platziert werden. Innerhalb des B2BUAs 26 wird ein Verbindungsprozessor, der unter den Geschäftsregeln der Organisation arbeitet, den Clienten über einen ersten Streckenabschnitt der Verbindung zu der geeigneten SIP-Einheit innerhalb des Kontakt-Centers unter Verwendung von SIP-Verfahren leiten.
Auf das Empfangen des SIP-INVITEs von der Agenten-Auswahl-Applikation 38 kann das B2BUA 26 auf das INVITE des Anrufers in der für einen Nutzeragenten durch RFC 3261 der vorbeschriebenen Art antworten, um den zweiten Streckenabschnitt der Verbindung aufzusetzen, der letztlich einen ausgewählten Agenten (beispielsweise 34) beinhalten würde. Diesbezüglich kann ein Rufaufsetzprozessor 29 innerhalb des B2BUAs 26, 28 das SIP INVITE verarbeiten, um eine Verbindung zwischen dem Clienten 12 und dem Agenten 34 aufzusetzen. Falls sich der Agent 34 vorher dem B2BUA 26 gegenüber signiert hat, wird dann die endgültige Verbindung vom Anrufer zu dem Agenten durch Verbinden der zwei Dialoge innerhalb des B2BUAs 26, 28 oder einer äquivalenten Einheit gemacht.
Auf das Vervollständigen der Verbindung kann das B2BUA 26 eine SIP „200 OK"-Nachricht zu dem Clienten 12 senden und der Client 12 kann eine „ACK SIP:agent34@B2BUA26.com" zur Bestätigung der Vervollständigung des Aufsetzens eines Kommunikationskanals zurückschicken. Auf den Empfang durch das B2BUA 26 kann ein Verbindungsprozessor „agent34@host.com" für die Ziel-URL und „client12@B2BUA26.com" für die Quell-URL für jegliche durch das B2BUA 26, 28 empfangene Nachrichten, die zu dem Agenten 34, 36 weitergeleitet sind, ersetzen. In einer Nachricht, die von dem Agenten 34 durch das B2BUA 26, 28 empfangen wurde, um sie dem Clienten 12 weiterzuleiten, kann der Verbindungsprozessor „client12@phone.com" für die Ziel-URL und „agent34@B2BUA26.com" für die Quell-URL ersetzen.
Wie oben diskutiert, kann der Host 30 eine Anzahl von B2BUAs 26, 28 nutzen. Ein B2BUA (beispielsweise 26) kann ein erster B2BUA und ein anderer geeigneter B2BUA (beispielsweise 28) kann ein zweiter B2BUA sein.
Während das System 10 gezeigt ist, als hätte es nur zwei B2BUAs zeigt, es soll aber verstanden sein, dass das System 10 jede Anzahl von B2BUAs 26, 28 haben kann. Allgemein kann angenommen werden, dass jeder Kontakt, der durch das System 10 verarbeitet wird, einen ersten und einen zweiten B2BUA 26, 28 hat. Tatsächlich kann der Host 30 jedes Mal, wenn ein Kontakt zwischen einem Clienten 12, 14, 16, 18 und einem Betriebsmittel des Systems (beispielsweise einem Agenten, einem IVR, etc.) durch das System 10 aufgesetzt werden, einen ersten und einen zweiten B2BUA 26, 28 erzeugen, um den Kontakt zu verarbeiten.
Die erzeugten ersten und zweiten B2BUAs 26, 28 eines jeden Kontaktes kann zu verschiedenen Servern übertragen und auf verschiedenen Servern bearbeitet werden.
Sobald jeder Kontakt verarbeitet ist, kann dieser, wie oben erwähnt, durch den Verfügbarkeitsserver 32 weitergeleitet werden. Um die Verfügbarkeit eines jeden B2BUAs 26, 28 zu überwachen, kann der Verfügbarkeitsserver 32 einen RECORD-ROUTE-Kopf in das SIP-INVITE einfügen, welches es zu dem B2BUA 26, 28 überträgt.
Das Aktivieren der RECORD-ROUTE-Funktion verursacht, dass alle nachfolgende Kommunikation des Kontaktes zwischen dem B2BUA 26, 28 und dem Clienten 12, 14, 16, 18 durch den Verfügbarkeitsserver 32 fließt. Der Kommunikationsfluss des Kontaktes durch den Verfügbarkeitsserver 32 erlaubt dem Verfügbarkeitsserver 32, Fehler eines jeden bestimmten B2BUAs 26, 28 zu überwachen und zu detektieren.
Bezüglich der B2BUAs 26, 28 werden der erste und der zweite B2BUA 26, 28 programmiert, um Daten zu synchronisieren.
Diesbezüglich bilden das erste und zweite B2BUA 26, 28 einen Kommunikationslink 27 aus (1). Der Kommunikationslink 27 erlaubt dem zweiten B2BUA 26, 28, sich mit dem ersten B2BUA 26, 28 zu synchronisieren (den logischen Status verfolgen), während verschiedene Kontaktstatus zwischen Kontaktaufbau und Kontaktabbau. Dadurch, dass den zweiten B2BUA 26, 28 erlaubt wird, den Status des ersten B2BUAs 26, 28 zu verfolgen, kann der zweite B2BUA 26, 28 eingreifen und den ersten B2BUA 26, 28 ersetzen, wann immer der erste B2BUA 26, 28 ausfällt.
Diesbezüglich behält der Verfügbarkeitsserver 32 einen Ruf-Datensatz des Status jeden Kontaktes. Ein Fehlerdetektionsprozessor 33 innerhalb des Verfügbarkeitsservers 32 kann den Status des ersten B2BUAs 26, 28 überwachen. Das Überwachen kann in einer Vielzahl von Arten erreicht werden. Z.B. kann ein Klopfen-Prozessor 37 innerhalb des Fehlerdetektionsprozessors periodisch den ersten B2BUA 26, 28 „anklopfen". Alternativ kann ein Herzschlag-Prozessor 38 zuhören, um einen Herzschlag, der periodisch von dem ersten B2BUA 26, 28 gesendet wird, zu detektieren. Falls der erste B2BUA 26, 28 scheitern sollte, auf das Klopfen zu antworten oder den Herzschlag zu hören, kann der Fehlerdetektionsprozessor 33 erkennen, dass der erste B2BUA 26, 28 scheiterte.
Alternativ kann der Fehlerdetektionsprozessor 33 einen Zeitgeber 35 setzen, sobald jedes Kommunikationselement zu dem ersten B2BUA 26, 28 übertragen wurde. Falls der Zeitgeber 35 ausläuft, bevor eine Antwort von dem ersten B2BUA 26, 28 empfangen wird, überträgt der Fehlerdetektionsprozessor den Kontakt zu dem zweiten B2BUA 26, 28.
Um den zweiten B2BUA 26, 28 zu aktivieren, veranlasst der Fehlerdetektionsprozessor 33 einen Rufübertragungsprozessor 31 dazu, einen Aktivierungscode zu übertragen und das letzte von dem Clienten 12 empfangene Kontaktsteuerelement zu dem zweiten B2BUA 26, 28 zu übertragen. Das zweite B2BUA 26, 28 kann dann an die Stelle des ersten B2BUAs 26, 28 treten, um den Kontakt zwischen dem Clienten 12 und dem Agenten 34 durch den vorhergehenden zweiten B2BUA 26, 28 wiederherzustellen. Das Wiederherstellen des Kontaktes kann durch Senden einer „INVITE/200/ACK"-Sequenz, (d.h. einem SIP re-INVITE), wie in 3 gezeigt, erreicht werden.
Sobald der vorherige zweite B2BUA 26, 28 die Funktion des ersten B2BUAs angenommen hat, kann der vorherige erste B2BUA die zweite Funktion annehmen, sobald er wieder online ist. Diesbezüglich kann der neue erste B2BUA 26, 28 nun versuchen, den neuen zweiten B2BUA 26, 28 zu synchronisieren, und der Prozess kann sich wiederholen.
Ein spezifisches Ausführungsbeispiel des Verfahrens und der Vorrichtung zum Verteilen von Rufen wurde zum Zwecke der Darstellung der Art beschrieben, in welcher die Erfindung gemacht wurde und benutzt wird. Es sollte verstanden werden, dass die Implementierung von anderen Variationen und Modifikationen der Erfindung und ihrer verschiedenen Aspekte offensichtlich für einen Fachmann ist und dass die Erfindung nicht auf die beschriebenen spezifischen Ausführungsbeispiele eingeschränkt ist. Demnach ist vorgesehen, die vorliegende Erfindung und jegliche und alle Modifikationen, Variationen oder Äquivalente, die in den wahren Geist und Bereich der den hierin offenbarten und beanspruchten Prinzipien unterliegenden Basis fallen, abzudecken.

Claims

Verfahren zum Verarbeiten eines Kontaktes mit einem Clienten innerhalb eines Kontaktverteilers, wobei das Verfahren aufweist: Bereitstellen eines ersten SIP-End-zu-End-Nutzeragenten und eines zugehörigen zweiten SIP-End-zu-End-Nutzeragenten für jedes Betriebsmittel einer Vielzahl von Betriebsmitteln des Kontaktverteilers; Aufsetzen einer Kommunikationsverbindung zwischen dem Clienten und einem Betriebsmittel der Vielzahl der Betriebsmittel durch den bereitgestellten ersten End-zu-End-Nutzeragenten des Betriebsmittels; Überwachen der Kommunikationsverbindung zwischen dem Clienten und dem Betriebsmittel mit einem Verfügbarkeitsserver; Detektieren eines Fehlers des ersten End-zu-End-Nutzeragenten mit dem Verfügbarkeitsserver; und Übertragen der Verbindung von dem ersten End-zu-End-Nutzeragenten zu dem zugehörigen zweiten End-zu-End-Nutzeragenten des Betriebsmittels mit dem Verfügbarkeitsserver, wenn der erste End-zu-End-Nutzeragent scheitert.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, wobei der Schritt des Aufsetzens der Kommunikationsverbindung weiter das Empfangen eines SIP-INVITEs, das das Aufsetzen der Verbindung anfragt, mit dem Verfügbarkeitsserver aufweist.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, weiter aufweisend die Aktivierung einer SIP-RECORD-ROUTE-Funktion mit dem Verfügbarkeitsserver während des Aufsetzens der Verbindung zwischen dem Clienten und dem Betriebsmittel des Kontaktverteilers.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, weiter aufweisend die Modifizierung eines SIP-INVITEs mit dem Verfügbarkeitsserver durch Aktivierung einer SIP-RECORD-ROUTE-Funktion während des Aufsetzens der Verbindung zwischen dem Clienten und dem Betriebsmittel des Anrufverteilers.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 4, weiter aufweisend das Weiterleiten des modifizierten SIP-INVITEs mit dem Verfügbarkeitsserver zu einem ersten End-zu-End-Nutzeragenten während des Kontakt-Aufsetzens.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, wobei der Schritt des Detektierens des Fehlers des ersten End-zu-End-Nutzeragenten weiter ein Detektieren einer Verzögerung einer zu der Nachrichtenverbindung zugehörigen SIP-Nachricht aufweist.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, wobei der Schritt des Detektierens des Fehlers des ersten End-zu-End-Nutzeragenten weiter ein Anklopfen des ersten End-zu-End-Nutzeragenten und ein Fehlschlagen eines Detektierens einer Antwort aufweist.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, wobei der Schritt des Detektierens des Fehlers des ersten End-zu-End-Nutzeragenten weiter ein periodisches Senden einer Herzschlag-Nachricht von dem ersten End-zu-End-Nutzeragenten zu dem Verfügbarkeitsserver aufweist.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, wobei der Schritt des Übertragens des Kontaktes zu dem zweiten End-zu-End-Nutzeragenten weiter das Abfangen einer Nachricht der Verbindung mit dem Verfügbarkeitsserver und, auf das Detektieren des Fehlers des ersten End-zu-End-Nutzeragenten, ein Subsituieren mit dem Verfügbarkeitsserver eines universellen Betriebsmittel-Indikators des zweiten End-zu-End-Nutzeragenten anstelle eines universellen Betriebsmittel-Indikators des ersten End-zu-End-Nutzeragenten aufweist.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, weiter aufweisend ein Synchronisieren eines Datensatzes des zweiten End-zu-End-Nutzeragenten mit einem Datensatz des ersten End-zu-End-Nutzeragenten.
Verfahren zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 1, weiter aufweisend ein Lokalisieren der ersten und zweiten End-zu-End-Nutzeragenten auf verschiedenen Servern.
Vorrichtung zur Verarbeitung eines Kontaktes mit einem Clienten innerhalb eines Kontaktverteilers, wobei die Vorrichtung aufweist: Mittel zum Bereitstellen eines ersten SIP-End-zu-End-Nutzeragenten und eines zugehörigen zweiten SIP-End-zu-End-Nutzeragenten für jedes Betriebsmittel einer Vielzahl von Betriebsmitteln des Kontaktverteilers; Mittel zum Aufsetzen einer Kommunikationsverbindung zwischen dem Clienten und einem Betriebsmittel der Vielzahl der Betriebsmittel durch den bereitgestellten ersten End-zu-End-Nutzeragenten des Betriebsmittels; Mittel innerhalb eines Verfügbarkeitsservers zum Überwachen der Kommunikationsverbindung zwischen dem Clienten und dem Betriebsmittel; Mittel innerhalb eines Verfügbarkeitsservers zum Detektieren eines Fehlers des ersten End-zu-End-Nutzeragenten; und Mittel innerhalb eines Verfügbarkeitsservers zum Übertragen der Verbindung von dem ersten End-zu-End-Nutzeragenten zu dem zugehörigen zweiten End-zu-End-Nutzeragenten des Betriebsmittels, wenn der erste End-zu-End-Nutzeragent scheitert.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, wobei das Mittel zum Aufsetzen der Kommunikationsverbindung weiter Mittel innerhalb des Verfügbarkeitsservers zum Empfangen eines SIP-INVITEs aufweist, das das Aufsetzen der Verbindung anfragt.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, weiter aufweisend Mittel innerhalb des Verfügbarkeitsservers zum Aktivieren einer SIP-RECORD-ROUTE-Funktion während des Aufsetzens der Verbindung zwischen dem Clienten und dem Betriebsmittel des Kontaktverteilers.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, weiter aufweisend Mittel innerhalb des Verfügbarkeitsservers zum Modifizieren eines SIP- INVITEs durch Aktivieren einer SIP-RECORD-ROUTE-Funktion während des Aufsetzens der Verbindung zwischen dem Clienten und dem Betriebsmittel des Anrufverteilers.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 15, weiter aufweisend Mittel innerhalb des Verfügbarkeitsservers zum Weiterleiten des modifizierten SIP-INVITEs zu einem ersten End-zu-End-Nutzeragenten während des Kontaktaufsetzens.
Vorrichtung für Mittel zum Detektieren des Fehlers des ersten End-zu-End-Nutzeragenten nach Anspruch 12 weist weiterhin Mittel zum Detektieren einer Verzögerung einer zu der Nachrichtenverbindung zugehörigen SIP-Nachricht auf.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, wobei die Mittel zum Detektieren des Fehlers des ersten End-zu-End-Nutzeragenten weiter Mittel zum Anklopfen des ersten End-zu-End-Nutzeragenten und des Fehlschlagens eines Detektierens einer Antwort aufweist.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, wobei die Mittel zum Detektieren des Fehlers des ersten End-zu-End-Nutzeragenten weiter Mittel zum periodischen Senden einer Herzschlag-Nachricht von dem ersten End-zu-End-Nutzeragenten zu dem Verfügbarkeitsserver aufweist.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, wobei die Mittel zum Übertragen des Kontaktes zu dem zweiten ersten End-zu-End-Nutzeragenten weiter Mittel innerhalb des Verfügbarkeitsservers zum Abfangen einer Nachricht der Verbindung und auf ein Detektieren des Fehlers des ersten End-zu-End-Nutzeragenten zum Substituieren eines universellen Betriebsmittel-Indikators des zweiten End-zu-End-Nutzeragenten anstelle eines universellen Betriebsmittel-Indikators des ersten End-zu-End-Nutzeragenten aufweist.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, weiter aufweisend Mittel zum Synchronisieren eines Datensatzes des zweiten End-zu-End-Nutzeragenten mit einem Datensatz des ersten End-zu-End-Nutzeragenten.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, weiter aufweisend Mittel zum Lokalisieren der ersten und zweiten End-zu-End-Nutzeragenten auf verschiedenen Servern.
Vorrichtung zum Verarbeiten eines Kontaktes mit einem Clienten innerhalb eines Kontaktverteilers, wobei die Vorrichtung aufweist: einen ersten End-zu-End-Nutzeragenten und einen zugehörigen zweiten End-zu-End-Nutzeragenten für jedes Betriebsmittel einer Vielzahl von Betriebsmitteln des Kontaktverteilers; einen Rufaufsetzprozessor, der eine Kommunikationsverbindung zwischen dem Clienten und einem Betriebsmittel der Vielzahl von Betriebsmitteln durch den bereitgestellten ersten End-zu-End-Nutzeragenten des Betriebsmittels aufsetzt; einen Verfügbarkeitsserver, der die Kommunikationsverbindung zwischen dem Clienten und dem Betriebsmittel überwacht und einen Fehler des ersten End-zu-End-Nutzeragenten detektiert, und einen Rufübertragungsprozessor innerhalb des Verfügbarkeitsservers, der die Verbindung zwischen dem ersten End-zu-End-Nutzeragenten zu dem zugehörigen zweiten End-zu-End-Nutzeragenten des Betriebsmittels überträgt, wenn der erste End-zu-End-Nutzeragent scheitert.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 23, weiter aufweisend ein SIP-INVITE von dem Clienten, das der Rufaufsetzprozessor an den ersten End-zu-End-Nutzeragenten zum Zwecke des Aufsetzens der Verbindung sendet.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 24, weiter aufweisend einen SIP-RECORD-ROUTE-Kopf, den der Rufaufsetzprozessor in das SIP-INVITE einsetzt.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 23, wobei der Verfügbarkeitsserver weiter einen Fehlerdetektionsprozessor aufweist.
Vorrichtung für Mittel zum Detektieren des Fehlers des ersten End-zu-End-Nutzeragenten nach Anspruch 26 weist weiter einen Timer auf, der eine Verzögerung einer zu der Nachrichtenverbindung zugehörigen SIP-Nachricht detektiert.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 26, wobei der Fehlerdetektionsprozessor weiter einen Klopf-Prozessor aufweist, der den ersten End-zu-End-Nutzeragenten anklopft, um einen Fehler zu detektieren.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 26, wobei der Fehlerdetektionsprozessor weiter einen Herzschlag-Prozessor aufweist, der eine Herzschlag-Nachricht von dem ersten End-zu-End-Nutzeragenten detektiert.
Vorrichtung zum Verarbeiten des Kontaktes mit dem Clienten nach Anspruch 12, weiter aufweisend eine Kommunikationsverbindung, die einen Datensatz des zweiten End-zu-End-Nutzeragenten mit einem Datensatz des ersten End-zu-End-Nutzeragenten synchronisiert.