Verwalten der Sprachqualität mit CVM und Telemate

Einführung

Dieses Dokument beschreibt die Verwendung von Cisco Voice Manager und Telemate zur Verwaltung der Sprachqualität in einem VoIP-Netzwerk. Alle Inhalte basieren auf einer echten IP-Telefonie-Implementierung. Dieses Dokument konzentriert sich auf die Anwendung der Produkte und nicht auf die Verwendung der Produkte. Sie sollten bereits mit CVM und Telemate vertraut sein und Zugriff auf die erforderliche Produktdokumentation haben. Siehe Zugehörige Informationen für eine Liste zugehöriger Dokumentation.

Bei der Verwaltung eines umfangreichen VoIP-Netzwerks müssen Sie über die erforderlichen Tools für die objektive Überwachung und Berichterstellung der Sprachqualität im Netzwerk verfügen. Das Feedback der Benutzer allein ist nicht umsetzbar, da es subjektiv und unvollständig ist. Ein Teil dieser Funktion kann gemeinsam mit Telemate von CVM bereitgestellt werden. Die Sprachqualität wird mithilfe des Impairment/Calculated Impairment Planning Factor (Icpif) gemeldet, der von einem IOS-Gateway für jeden Anruf berechnet wird. Auf diese Weise kann der Netzwerkmanager Standorte identifizieren, die unter schlechter Sprachqualität leiden, und diese entsprechend bearbeiten.

Sobald Sie Problemstandorte identifiziert haben, benötigen Sie möglicherweise weitere Tools, um mögliche QoS-Probleme im Netzwerk zu beheben. Zwei Tools sind der Internetwork Performance Monitor (IPM) und Cisco Service Assurance Agent (CSAA). Diese Themen werden in einem anderen auf unserer Website veröffentlichten Dokument behandelt.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

• Cisco Voice Manager und Telemate

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Überblick über die Sprachqualität

Die folgenden Abschnitte bieten einen Überblick über Probleme mit der Sprachqualität:

• Messung der Sprachqualität
• ITU G.113 - Überblick

Messung der Sprachqualität

Der ITU-Standard G.113 legt fest, wie die Sprachqualität gemessen wird. Diese Methode schreibt vor, dass Sie die Qualität von Sprachanrufen durch Berechnung des Icpif bestimmen können. IOS-basierte Gateways berechnen den Icpif-Wert für jeden Anruf und protokollieren ihn als Teil des CDR-Datensatzes. Darüber hinaus kann ein Quality of Voice (QoV)-Trap über SNMP gesendet werden, wenn der Icpif-Wert eines Anrufs einen voreingestellten Wert überschreitet. Dies bedeutet, dass die Gateways über integrierte Messfunktionen für die Sprachqualität verfügen. Es müssen lediglich diese Messwerte erfasst und die Daten analysiert werden, um Trends zu identifizieren.

Die VoIP-Sprachqualität wird hauptsächlich durch die Netzwerk-QoS beeinflusst. Die Anrufanalyse konzentriert sich daher auf die standortbasierte Identifizierung von Problemen bei der Sprachqualität. Wenn Standorte mit einer großen Anzahl von Anrufen mit schlechter Sprachqualität identifiziert werden können, können wir uns auf alle QoS-Probleme im Netzwerkpfad zu und von diesen Standorten konzentrieren.

ITU G.113 - Überblick

Der folgende Abschnitt bietet nur eine kurze Übersicht. Weitere Informationen finden Sie in der G.113-Norm.

Die allgemeine Idee hinter G.113 besteht darin, einen Wertminderungsfaktor für jedes Gerät entlang des Sprachpfads zu berechnen und diese dann zu addieren, um die gesamte Beeinträchtigung zu erhalten. Es gibt verschiedene Arten von Beeinträchtigungen (Geräusch, Verzögerung, Echo usw.), die durch die ITU in fünf Kategorien unterteilt werden. Addieren Sie sie, um die gesamte Beeinträchtigung Itot zu erhalten:

Itot = Io + Iq + IDT + IDD + IE

Jeder dieser Werte wird wie folgt definiert (mithilfe von ITU-Terminologie):

• Io - Beeinträchtigungen, die durch eine nicht optimale Gesamtlautstärke und/oder ein hohes Schaltgeräusch verursacht werden.

• Iq: Beeinträchtigungen, die durch die Quantifizierung der Verzerrung durch den PCM-Typ verursacht werden.

• Idte: Beeinträchtigungen durch Talker-Echo.

• IDD - Sprachkommunikationsstörungen, die durch lange unidirektionale Übertragungszeiten (Verzögerung) verursacht werden.

• Ie - Beeinträchtigungen durch spezielle Geräte, insbesondere Codecs ohne Wellenform mit niedriger Bitrate.

Wenn die Cisco IOS-Software Itot berechnet, ignoriert sie Io und Iq als unerheblich und setzt Idte auf 0. Der Idd-Wert wird aus der folgenden Tabelle abgeleitet, die aus G.113 stammt:

Verzögerung	ID
150	0
200	3
250	10
300	15
400	25
500	30
600	35
800	40

Normalerweise ist Ie ein fester Wert, der nur vom Codec-Typ abhängt. G.113 legt die Werte für Codecs fest, die normalerweise von Cisco Gateways verwendet werden, wie in der folgenden Tabelle gezeigt:

Code	e
G.711	0
G.729/G.729a	10

Da diese Codecs jedoch in einer Paket-Sprach-Umgebung verwendet werden, hängt die tatsächliche Beeinträchtigung vom Paketverlust ab. Je höher der Paketverlust, desto höher ist die Beeinträchtigung. Cisco Engineering hat die Sprachqualität mit PSQM (ITU P.861) bei diskreten Paketverlusten gemessen. In der folgenden Tabelle sind die Werte für die Sprachverzerrung im Verhältnis zu den Paketverluststufen für bestimmte Codecs aufgeführt:

Paketverlust %	G.711	G.729/G.729a
0	0	10
1	8	15
2	12	20
3	18	25
4	22	30
5	26	34
6	28	38
7	30	40
8	32	42
9	34	44

Wie erwartet ist G.729 anfälliger für Paketverluste als G.711.

Bei der Sprachqualität geht es um menschliche Wahrnehmung und Erwartung. Die Erwartungen an das Servicelevel von Mobilfunkbenutzern sind niedriger als die von Festnetzbenutzern. Dies wird bei der Berechnung des Icpif berücksichtigt, indem Itot um den Faktor A der menschlichen Erwartung verringert wird. Die Formel hierfür lautet:

Icpif = Itot - A

G.113 bietet auch Erwartungsfaktoren für typische Sprachnetzwerke. Siehe folgende Tabelle:

Voice Network Access-Methode	Erwartungsfaktor A
Herkömmliches Festnetz-Festnetz	0
Wireless LAN (schnurloses Telefon)	5
Wireless-LAN (Mobiltelefon)	10
Satellit	20

G.113 verfügt außerdem über eine Tabelle, die den Icpif-Wert und die Sprachqualität abbildet. Sie ist in der folgenden Tabelle aufgeführt:

Voice Network Access-Methode	Erwartungsfaktor A
5	Sehr gut
10	Gut
20	Angemessene
30	Beschränkungsfall
45	Außergewöhnlich begrenzter Fall
55	Benutzer beschweren sich wahrscheinlich stark

Ein Icpif-Wert von 0 für einen Anruf ist eine perfekte Punktzahl. Dies sollte unser Ziel für VoIP-Netzwerke sein.

In einem herkömmlichen Sprachnetzwerk berechnet der Designer das gesamte Budget für Wertminderungen.

Beispiel: Io = 0; Iq = 0; IDTE = 0; IDD = 3; Ie = 7, was Itot = 10 ergibt.

Wenn der Benutzer von einem schnurlosen Telefon aus auf das Netzwerk zugreift, kann der maximale Erwartungsfaktor 5 abgezogen werden. Das Endergebnis ist also:

Icpif = Itot - A = 10 - 5 = 5

Die obige Tabelle zeigt, dass die Benutzer dann die Sprachqualität sehr gut wahrnehmen.

In diesem Dokument wird eine Lösung erläutert, die den Icpif-Wert für die Überwachung der Sprachqualität verwendet, anstatt ihn für Planungszwecke zu verwenden.

Verwalten der Sprachqualität mit CVM und Telemate

In den folgenden Abschnitten wird beschrieben, wie die Sprachqualität mit CVM und Telemate verwaltet wird:

• Einschränkungen
• Gateway-Konfiguration
• CVM- und Telemate-Architektur
• Telematikverzeichnis
• Berichterstellung

Einschränkungen

Die angebotene Lösung weist zwar einige Einschränkungen auf, es sind jedoch offenbar keine anderen skalierbaren Tools verfügbar. Zu den bekannten Einschränkungen gehören:

• Nur Anrufe über ein Gateway unterliegen einer Qualitätskontrolle. Anrufe von IP-Telefon zu IPhone können nicht gemessen werden. Diese Anrufe werden vom Gateway nicht angezeigt, und der CallManager unterstützt derzeit nicht G.113.

• Bei der Icpif-Berechnung werden nur Paketverluste und -verzögerungen berücksichtigt. Echo ist nicht in den Icpif-Berechnungen enthalten. Daher kann ein Anruf unter starkem Echo leiden und trotzdem eine perfekte Icpif-Punktzahl erhalten.

• Die Sprachqualität wird nur in IP-Telefon-zu-Gateway-Richtung gemessen. Der Icpif-Wert in einem Sprachnetzwerk ist in beide Richtungen wahrscheinlich asymmetrisch. QoS-Probleme bei unidirektionalen Netzwerken in der Richtung Gateway-zu-IP-Telefon spiegeln sich nicht in dem vom Gateway berechneten Icpif-Wert wider.

• Probleme mit der Sprachqualität treten im Allgemeinen in einem WAN häufiger auf. Die beschriebene Lösung eignet sich am besten für eine Umgebung mit zentralisierten Gateways, da Anrufe von IP-Telefonen an Remote-Standorten das WAN passieren müssen, um auf die Gateways zuzugreifen. Wenn Gateways verteilt werden (d. h. jeder Remote-Standort wird von einem lokalen Gateway bedient), werden die meisten Gateway-Anrufe nicht über das WAN geleitet. Bei VoIP-Anrufen im gesamten WAN handelt es sich hauptsächlich um IP-Telefon-zu-IP-Telefone, die für das Gateway nicht sichtbar sind.

Gateway-Konfiguration

Im Rahmen der vorgeschlagenen Lösung müssen alle Gateways für die CDR-Erfassung konfiguriert werden:

dial-control-mib max-size <max-number-of-cdr>
dial-control-mib retain-timer 600

Auf allen Gateways muss auch die QoV-Trap-Funktion aktiviert sein. Diese Funktion ist standardmäßig deaktiviert:

Calibra#show dial-peer voice 99 | include QOV|Icpif
Expect factor = 0, Icpif = 20,
VAD = enabled, Poor QOV Trap = disabled,

Diese Funktion wird auf VoIP-Basis per Dial-Peer aktiviert, indem Folgendes hinzugefügt wird:

dial-peer voice XYZ voip
snmp enable peer-trap poor-qov
icpif <threshold>
expect-factor 0

Wenn ein Anruf beendet wird, berechnet das Gateway die gesamte Beeinträchtigung (Itot) für diesen Anruf. Anschließend wird der konfigurierte Erwartungsfaktor von Itot abgezogen, um den tatsächlichen Icpif-Wert zu ermitteln. Wenn diese Zahl den Icpif-Grenzwert überschreitet, wird ein QoV-Trap gesendet. Die Anrufdauer muss mindestens 10 Sekunden betragen, damit das Gateway den Icpif-Wert für den Anruf berechnen kann.

Sehen wir uns ein Beispiel an, in dem die Gateway-Konfiguration wie folgt lautet:

dial-peer voice XYZ voip
icpif 10
expect-factor 5

Angenommen, ein Anruf wird mit einem Itot-Wert von 20 abgeschlossen. Das Gateway zieht dann einen erwarteten Faktor 5 von dieser Zahl ab, was einem Icpif-Wert von 15 entspricht. Da 15 mehr als 10 ist, generiert das Gateway ein QoV-SNMP-Trap.

Global müssen QoV-Traps an CVM gesendet werden:

snmp-server enable traps voice poor-qov
snmp-server host 10.x.x.x.x public<----- CVM station

Achten Sie darauf, dass Voice-Gateways SNMP-Traps für Verbindungen und Verbindungen erstellen, wenn ein Anruf eingerichtet oder beendet wird. Dies kann eine enorme Anzahl von Traps auf einem High-Density-Gateway bedeuten. Deaktivieren Sie diese Traps, indem Sie den folgenden Befehl hinzufügen:

interface serial1/0:15no snmp trap link-status

CVM- und Telemate-Architektur

CVM und Telemate sind vollkommen separate Anwendungen. Wie der Name bereits andeutet, ist CVM ein von Cisco entwickeltes Produkt. Telemate dagegen ist ein Drittanbieterprodukt, das Cisco im Paket mit CVM anbietet.

CVM führt eine Vielzahl von Funktionen aus. Die beiden Funktionen, die wir nutzen werden, sind:

• Erfassung von CDRs (Call Detail Records) über SNMP von den Gateways.

• Empfangen von QoV-SNMP-Traps von den Gateways.

Nach der Erfassung dieser Informationen formatiert CVM die Daten und gibt sie über eine einfache Dateifreigabe an Telemate weiter. Telemate verarbeitet diese Daten und speichert sie in einer Microsoft SQL-Datenbank. Das Endergebnis ist eine Datenbank mit einer Liste von Aufrufen mit den entsprechenden Details, einschließlich des Icpif-Werts. Anschließend können verschiedene Berichte für die Datenbank ausgeführt werden, darunter auch QoV-Berichte.

Der für uns interessante Telemate QoV-Bericht "Packet Voice Calls with Quality of Service Traps" (Packet-Sprachanrufe mit Quality of Service-Traps). Dieser Bericht listet alle Anrufe auf, für die das Gateway ein QoV-Trap generiert hat. Die einzelnen Anrufe interessieren uns nicht. Stattdessen sind wir daran interessiert, die Standorte zu identifizieren, die einen überdurchschnittlichen Prozentsatz an Anrufen mit Sprachqualität aufweisen. Um dies zu erreichen, muss Telemate die Anrufe nach Standort kategorisieren können. Dies wird im folgenden Abschnitt erläutert.

Telematikverzeichnis

Wenn wir das Telemate-Verzeichnis mit Informationen darüber ausfüllen, welche Nebenstellen sich an welchen Standorten befinden, können wir Telemate verwenden, um Anrufe nach Standort zu kategorisieren.

Das Telemate-Verzeichnis ist eine fünfschichtige Hierarchie mit den folgenden Ebenen:

• Stufe 1 - Unternehmen

• Ebene 2 - Abteilung

• Stufe 3 - Abteilung

• Stufe 4 - Benutzer

• Stufe 5 - Durchwahl

Sie können einem Benutzer mehrere Durchwahlen zuordnen.

Im Idealfall sollte jeder Anruf im QoV-Bericht mit dem Namen der Abteilung aufgeführt werden. Anschließend können wir den Namen der Abteilung verwenden, um eine bestimmte Site darzustellen. Dadurch können Anrufe nach Abteilung/Standort sortiert werden. Da Erweiterungen jedoch nur Benutzern zugeordnet werden können, müssen wir dies auf eine etwas unangenehme Weise erreichen. Grundsätzlich erstellen wir einen Dummy-Benutzer pro Standort, und wir machen den Namen dieses Benutzers zum Sitenamen oder Standortcode. Diesem Dummy-Benutzer werden dann alle Erweiterungen für diese Site zugewiesen. Die Anrufe können dann nach Benutzer sortiert werden, was einer Standortbestimmung entspricht.

Für die QoV-Berichterstellung sind die drei obersten Ebenen der Verzeichnishierarchie unwichtig, und diesen kann ein beliebiger Wert zugewiesen werden.

Für diese Implementierung sind 200 Standorte mit 45.000 Nebenstellen zugewiesen, wenn auch nicht unbedingt alle in Gebrauch. Das Verzeichnis enthält 200 Dummy-Benutzer, und jeder Dummy-Benutzer ist mit dem Bereich der Durchwahlen für seine Site verknüpft. Das manuelle Ausfüllen des Verzeichnisses wäre nicht möglich. Daher erstellen wir halbautomatisch eine CSV-Datei mit einer Zeile pro Durchwahl. Anschließend importieren wir die Datei mithilfe der Telemate-Importfunktion in das Verzeichnis. Jeder Posten in dieser CSV-Datei hat das folgende Format:

Company,Division,Department,User,Extension

Die Generierung der CSV-Datei selbst erfolgt auch halbautomatisch, indem ein Unix-Shell-Skript ausgeführt wird. Dieses Skript nimmt eine Seed-Datei als Eingabe. Diese Seed-Datei listet die Sites und die zugehörigen Durchwahlbereiche auf. Jede Zeile in der Seed-Datei hat folgendes Format:

site_name,extention_start,extension_end

Das Shell-Skript selbst ist sehr einfach und sieht wie folgt aus:

#--------------------------- Telemate script start ------------------------

#!/bin/ksh
 
 for i in `cat ./$1`
 do (
   echo $i | awk 'BEGIN{FS=","}{for (j=($2+0);j<($3+0);++j) printf "Company,Division,Dept,%s,%s\n", $1,j}'
) done
#--------------------------- Telemate script end ------------------------

Wenn das Skript selbst den Namen "make_dir" hat und die Seed-Datei 'seedfile.csv' heißt, wird die Datei "import CSV telemate_dir.csv" erstellt, indem der folgende Befehl an der Unix-Eingabeaufforderung ausgeführt wird:

unix$ make_dir seedfile.csv > telemate_dir.csv

Die Ausgabedatei telemate_dir.csv wird dann in Telemate importiert. Detaillierte Anweisungen hierzu finden Sie in der Telemate-Dokumentation.

Berichterstellung

Beim Ausführen eines Telemate-Berichts können Sie das Ausgabeziel auswählen. Für große Berichte wird empfohlen, die Datei im CSV-Format zu erstellen. Anschließend können Sie den Bericht in Excel bearbeiten, wo er wie folgt aussehen würde:

Dauer	Gewählte Nummer	Standort	Datum	Zeit	Standort	Nebenstelle
0:00:57	3-573-7783	10.200.16.33	10/05/2000	16:49:45 Uhr	BLM	37569
0:00:57	3-573-7783	10.200.16.33	10/05/2000	16:49:45 Uhr	BLM	37569
0:00:38	3-577-2958	10.200.16.33	10/05/2000	16:28:28 Uhr	BLM	37576
0:00:38	3-577-2958	10.200.16.33	10/05/2000	16:28:28 Uhr	BLM	37576
0:00:52	3-577-2985	10.200.16.33	10/05/2000	21:26:33 Uhr	BLM	37593
0:01:19	3-577-1770	10.200.16.33	10/05/2000	19:26:05 Uhr	BMC	34270
0:00:23	3-577-1770	10.200.16.33	10/05/2000	20:08:27 Uhr	BMC	34270
0:00:23	3-577-1770	10.200.16.33	10/05/2000	20:08:27 Uhr	BMC	34270
0:00:11	4-566-5302	10.132.16.33	10/05/2000	19:05:33 Uhr	COR	42791
0:00:32	4-567-0417	10.132.16.33	10/05/2000	17:29:51 Uhr	COR	42805
0:00:32	4-567-0417	10.132.16.33	10/05/2000	17:29:51 Uhr	COR	42805
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17:42:07 Uhr	COR	42823
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17:42:07 Uhr	COR	42823
0:00:39	4-472-5011	10.132.16.33	10/05/2000	17:59:23 Uhr	COR	46578
0:00:39	4-472-5011	10.132.16.33	10/05/2000	17:59:23 Uhr	COR	46578
0:00:28	4-236-7687	10.132.16.33	10/05/2000	19:17:51 Uhr	COR	46578
0:00:17	6-867-9766	10.132.16.35	10/05/2000	16:08:02	GIS	64197
0:00:17	6-867-9766	10.132.16.35	10/05/2000	16:08:02	GIS	64197
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18:15:48 Uhr	GIS	68549
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18:15:48 Uhr	GIS	68549
0:01:26	6-876-5223	10.132.16.35	10/05/2000	19:10:23 Uhr	HAH	68369
0:01:26	6-876-5223	10.132.16.35	10/05/2000	19:10:23 Uhr	HAH	68369
0:00:52	6-876-2223	10.132.16.35	10/05/2000	17:37:58	HAH	68397
0:01:05	4-477-5402	10.132.16.33	10/05/2000	16:23:20 Uhr	JVL	47162
0:00:24	4-478-8848	10.132.16.33	10/05/2000	19:07:09 Uhr	JVL	47168
0:00:24	4-478-8848	10.132.16.33	10/05/2000	19:07:09 Uhr	JVL	47168
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19:49:16 Uhr	KIB	49252
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19:49:16 Uhr	KIB	49252
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16:07:10	KIB	49254
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16:07:10	KIB	49254
0:00:29	4-387-1337	10.132.16.33	10/05/2000	16:06:45 Uhr	KIB	49256
0:00:29	4-387-1337	10.132.16.33	10/05/2000	16:06:45 Uhr	KIB	49256
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16:09:38 Uhr	KIB	49261
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16:09:38 Uhr	KIB	49261
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16:09:38 Uhr	KIB	49261
0:00:17	4-387-1344	10.132.16.33	10/05/2000	16:33:04	KIB	49263
0:00:17	4-387-1344	10.132.16.33	10/05/2000	16:33:04	KIB	49263
0:00:31	6-367-5103	10.132.16.35	10/05/2000	20:44:46	LEV	64233
0:00:31	6-367-5103	10.132.16.35	10/05/2000	20:44:46	LEV	64233
0:00:30	6-368-9088	10.132.16.35	10/05/2000	16:11:06	LEV	64247
0:00:30	6-368-9088	10.132.16.35	10/05/2000	16:11:06	LEV	64247
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26 Uhr	LHT	43636
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26 Uhr	LHT	43636

Verwenden Sie die Excel-Funktion "Zwischensummen", um die Anzahl schädlicher Anrufe pro Benutzer/Standort zu zählen. Erstellen Sie dann ein Excel-Makro, um die Subtotalierung zu halbautomatisieren. Siehe folgendes Beispiel:

Dauer	Gewählte Nummer	Standort	Datum	Zeit	Standort	Nebenstelle
				BCM-Anzahl	5
				BMC-Anzahl	3
				COR-Anzahl	8
				GIS-Anzahl	4
				HAH-Anzahl	3
				JVL-Anzahl	3
				KIB-Anzahl	11
				LEV-Anzahl	4
				LHT-Anzahl	2
				Große Anzahl	43

Die Spalte Standort enthält jetzt die Anzahl der ungültigen Aufrufe an bzw. von dieser Site. Die Spalte Location im Bericht ist die IP-Adresse des anderen Endes der VoIP-Komponente und stammt aus dem Gateway-CDR-Datensatz. In einer CallManager-Umgebung (CCM) sind die Signalisierungs- und Medienendpunkte zwei unterschiedliche IP-Adressen. Die angegebene IP-Adresse ist der Endpunkt für die Signalisierung (d. h. der CallManager). Ein DDTS (CSCds23283) wurde gesendet, um einen Knopf anzufordern, mit dem der CDR-Datensatz die IP-Adresse des Mediums protokollieren kann. Auf diese Weise können schädliche Anrufe nach Subnetz sortiert werden. Dies erhöht die Präzision, da es in der Regel mehrere Subnetze pro Standort gibt. Wenn nur einige dieser Subnetze QoV-Probleme haben, können diese identifiziert werden.

Wir empfehlen Ihnen, den Telemate Scheduler so einzurichten, dass der Bericht "Packet Voice Calls with Quality of Service Traps" einmal täglich automatisch ausgeführt wird. Abgeschlossene Berichte können dann per E-Mail an ausgewählte Mitarbeiter des Betriebs gesendet werden. Diese Mitarbeiter führen dann eine tägliche QoV-Prüfung für die letzten 24 Stunden durch. Die Berichte sollten mindestens einen Monat archiviert werden, damit jegliche Verschlechterung der QoV mit allen rund um diese Zeit vorgenommenen Netzwerkänderungen korreliert werden kann.

Hinweis: Telemate Version 4.7 oder höher ist erforderlich, damit Berichte ordnungsgemäß mit Gateways funktionieren, die in einer CallManager-Umgebung betrieben werden. Bei früheren Versionen von Telemate wird davon ausgegangen, dass sich die lokalen Nebenstellen immer auf der POTS-Seite des Kabelmodems befinden. In einer CallManager-Umgebung befinden sich die lokalen Nebenstellen (IP-Telefone) auf der VoIP-Seite des Gateways. Dadurch werden frühere Versionen von Telemate verwirrt, und die Berichte sind von begrenztem Wert.

Zugehörige Informationen

• Produktsupport für Unified Communications
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support und Dokumentation für Cisco Systeme