Vorbemerkung

Die Sammelgruppenanalysen werten Anrufe auf HuntGroups des Cisco Communication Managers (CUCM) aus. Sie werden auf Basis der vom CUCM gelieferten CDRs generiert. Jede HuntGroup wird dabei kontextlos betrachtet. Interaktionen mit CallCenter Lösungen, Vermittlungsplätzen etc. können nicht in die Analysen einbezogen werden.
Aufgrund der vielseitigen Konfigurationsmöglichkeiten des CUCMs und der nahezu unbegrenzten Möglichkeiten Anrufszenarien abzubilden, kann eine exakte Abbildung der Realität nicht garantiert werden. So wird es Fälle geben, die trotz Einhaltung der vorgegebenen technischen Randbedingungen nicht korrekt erfasst werden.

Definitionen

HuntGroups in Cisco UCM

Aufbau der HuntGroups

Dokumentation der Leistungsmerkmale und Zählweise

Open

1. Jede HuntGroup besitzt eine HuntList

2. Eine HuntList kann mehrere LineGroups referenzieren, auch wenn diese bereits in einer anderen LineGroup referenziert ist

3. Eine LineGroup beinhaltet mehrere Agenten

4. Overflows können auf LineGroups definiert werden

5. Overflows können auf HuntGroups definiert werden

6. Ein und dieselbe LineGroup kann in mehreren LineLists (HuntGroups) zugeordnet sein

7. Ein Agent kann zwei verschiedenen LineGroups zugeordnet sein

8. Im CUCM können Translation Patterns definiert werden. Dabei werden im CUCM intern Nummern substituiert.

Prinzipieller Aufbau der CUCM CDRs

In den Call Detail Records (CDRs) stehen neben Informationen wie Datum und Uhrzeit, Gesprächs- und Klingeldauer, 4 Felder für die Zuordnung der Gespräche zu Nebenstellen bzw. Agenten:

• Calling Number

• Original Called

• Last Redirect

• Finally Called

Dabei ist „Calling Number" die rufende Nummer, „Original Called" die ursprünglich gewählte, „Last Redirect" die Nummer, die zuletzt „weitergeleitet" hat und „Finally Called" die Rufnummer, die schlussendlich das Gespräch entgegen genommen hat.

Open

Im CDR des abgebildeten Beispiels enthält das Feld „Calling Number" die von extern anrufende Nummer, „Original Called" die Nummer der HuntGroup, die ursprünglich gewählt wurde, „Last Redirect" ebenfalls die HuntGroup und „Finally Called" die Nummer des annehmenden Agenten.
Die Anna4 HuntGroup Analysen werden Insbesondere aus den 4 dargestellten Feldern erstellt. Einschränkungen ergeben sich aus fehlenden oder unzulänglichen Informationen dieser Felder.

Beispiele von Einschränkungen

Verkettung von HuntGroups

Im vorliegenden Beispiel enthält „Calling Number" die von extern rufende Nummer, „Original Called" die Nummer der HuntGroup 1, „Last Redirect" die Nummer der HuntGroup 3, und „Finally Called" den Agenten 3-1. Die Information, dass die HuntGroup 2 ebenfalls involviert war, ist nicht vorhanden.
Fazit: Anna4 HuntGroup Analysen beinhalten bei Verkettungen nur Informationen über die erste und die letzte beteiligte HuntGroup.

HuntGroups als Bestandteil übergeordneter Call Flows

Ist eine HuntGroup Bestandteil eines übergeordneten CallFlows, kann dies bei den Analysen nicht berücksichtigt werden. Ein eingehender Anruf wird unter Umständen mehrfach gezählt. Eine generelle Aussage, wie in diesen Fällen in den CDRs protokolliert wird, kann nicht getroffen werden. Im oben skizzierten Beispiel wird ein Anruf nach dem Einspielen der Ansage 1 der HuntGroup weitergeleitet. Ist diese „besetzt", protokolliert sie ein Besetztgespräch und leitet den Anruf an die Ansage 2 weiter. Diese übergibt wieder an die HuntGroup, wodurch ein weiteres Gespräch protokolliert wird. Aus einem eingehenden Gespräch können so mehrere CDRs, also Gesprächszählungen, entstehen.

Vermittlung zu HuntGroups

Gehen beispielsweise Gespräche über eine Zentrale ein, welche dann entscheidet, an welche HuntGroup der Anrufer weitergeleitet wird, kann dies durch die HuntGroup Analyse nicht direkt ausgewertet werden. Das vermittelte (externe) Gespräch unterscheidet sich nicht von einem direkt von extern auf die HuntGroup eingehenden. In den Analysen über die HuntGroup 1 erscheinen je ein internes Gespräche (die Rückfrage) und ein externes Gespräch (das vermittelte Gespräch).

HuntGroups in Verbindung beliebiger Prozesse

Der CUCM erlaubt komplexe Eingriffe in den Gesprächsfluss. Im obigen Beispiel greift ein Call Server in das Streaming ein um z. B. Tarifinformationen in das Gespräch einzumischen. In einem solchen Fall können keinerlei Rückschlüsse gezogen werden, woher z. B. das Gespräch kam. Aus Sicht der HuntGroup ist der Teilnehmer stets der Route Point des Call Servers, obwohl das Gespräch ursprünglich von extern eingeht.

HuntGroups in Verbindung mit Queue

Wenn im folgenden von Queue gesprochen wird, so ist damit der im CUCM integrierte Mechanismus gemeint, welcher ab CUCM Version 9.0 verfügbar ist.
Pro Huntgroup können im CUCM Einstellungen getroffen werden wie Timeout und Abwurf, …
Grundsätzlich stellt sich dies in den CDR dann so dar, dass das Gespräch zuerst auf die Queue geht und dort angenommen wird. Abhängig vom Call-Szenario kommen hier dann noch weitere CDR (z.B.: wenn ein Abwurf stattfindet, …). AlwinPro fasst diese CDR entsprechend zusammen um die HuntGroup-Analysen bilden zu können.

Technische Randbedingungen

Die in diesem Dokument beschriebenen Analysen setzen die Einhaltung folgender technischer Randbedingungen voraus.

Konfiguration des CUCM

Die Sammelgruppen-Analysen sind erst ab dem CUCM Release 7.1.5.31900-3 möglich.
Außerdem müssen die CUCM Einstellung „Show Line Group Member DN in finalCalledPartyNumber CDR Field" und „Show Line group Member Non Masked DN in finalCalledPartyNumber CDR Field" gesetzt werden.

Einführung einer „ProxyNst" (Vornebenstelle) bei der Konfiguration von HuntGroups

Auf Grund der von Cisco gewählten Protokollierung von Vorgängen in HuntGroups, muss eine „ProxyNst" eingefügt werden. Huntgroups dürfen ausschließlich über diese „ProxyNst" angerufen werden und nicht über den HuntPilot direkt. Über die „ProxyNst" erfolgt dann ein „Forward all" auf die HuntPilot-Nummer.

Als „ProxyNst" kann z. B. ein “CTI Port” oder eine “Directory Number” verwendet werden. Ein TranslationPattern funktioniert z. B. nicht als „ProxyNst".

(Die Notwendigkeit dieser „ProxyNst" ergibt sich, da bei einem Abwurf einer HuntGroup auf eine zweite, die das Gespräch dann entgegen nimmt, im Feld „Last Redirect" nicht die HuntPilot-Nummer der letzten HuntGroup eingetragen wird, sondern die der ersten. Somit würde dieses Gespräch fälschlicherweise der ersten HuntGroup zugeordnet werden)
Die Konfiguration der „ProxyNst" kann sehr einfach umgesetzt werden, ohne ein bestehendes komplexes Routing zu beeinflussen. Die ursprüngliche HuntPilot-Nummer wird zur Vornebenstelle und für den neuen HuntPilot wird eine neue Nummer verwendet.

Konfiguration der Sammelgruppen in UC-Analytics

Die Festlegungen der HuntGroups (Vornebenstelle, HuntPilot-Nummer) erfolgen in einer gesonderten Liste. Die Analysen sind unabhängig von der Organigramm Struktur.

Optional können direkte Anrufe auf Agenten deren HuntGroup zugerechnet werden. Dazu müssen die Agenten einer HuntGroup in UC-Analytics explizit bekannt gemacht werden. Die Option ist über Ini-Key „StatHP2Direktanrufe=" aktivierbar.
Konferenzen erzeugen für jeden Teilnehmer separate Call Logs. Diese können entweder alle einzeln ausgewertet, oder nach einer bestimmten Regel zusammengefasst werden (siehe Abschnitt Konferenzen). Die Verarbeitungslogik ist über Ini-Key „StatHP2VarianteB=" einstellbar.

Bedingung beim Einsatz mehrerer CUCMs

Werden mehrerer CUCMs eingesetzt, müssen die CDRs aller CUCMs in zeitlich aufsteigender Reihenfolge zur Verfügung gestellt werden, da sonst notwendige Korrekturen nicht durchgeführt werden können (dies ist im Standardbetrieb gegeben)

Mehrclusterlösungen werden nicht unterstützt

Die HuntGroup Analysen sind nur in einem Cluster möglich, Mehrclusterlösungen werden nicht unterstützt.

Weitere Einschränkungen

Wie oben beschrieben, unterliegen die HuntGroup Analysen bestimmten Einschränkungen z. B. bei Verkettung, einer Integration von HuntGroups in einen übergeordneten Callflow etc.