In diesem Dokument wird die Ausgabe des Befehls show call active voice (nur registrierte Kunden) erläutert und veranschaulicht, wie die Befehlsausgabe Probleme bei der Sprachqualität behebt.
Hinweis: Die in diesem Dokument erwähnten Befehle sind mit dem Command Lookup Tool verknüpft (nur registrierte Kunden). Verwenden Sie dieses Tool, um nach weiteren Informationen zu bestimmten Befehlen zu suchen.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Mit dem Befehl show call active voice können Sie den Inhalt der Tabelle für aktive Anrufe anzeigen. Zu den angegebenen Informationen gehören Anrufzeiten, DFÜ-Peers, Verbindungen, Quality of Service-Parameter und die Gateway-Verarbeitung von Jitter. Diese Informationen können nützlich sein, wenn Sie eine Reihe von Problemen mit der Sprachqualität beheben.
Die Tabelle in diesem Dokument enthält die Ausgabe eines Beispielbefehls für die aktive Sprachübertragung und eine kurze Erläuterung der einzelnen Parameter.
Hinweis: Der Befehl show call active voice zeigt Daten aus dem normalen Telefondienst (Plain Old Telefone Service, POTS) und den VoIP-Anrufabschnitten auf dem Sprach-Gateway an. Einige Parameter werden im Text fett formatiert dargestellt, damit sie im weiteren Verlauf des Dokuments weiter erörtert werden können.
Der Befehl show call active zeigt Werte sowohl für die Telefonie- als auch für die VoIP-Phasen eines aktiven Anrufs an. Für jeden Abschnitt werden dieselben generischen Parameter angezeigt, gefolgt von Parametern, die für den jeweiligen Anrufabschnitt spezifisch sind. In dieser Tabelle werden diese Parameterbereiche durch einen schattierten Header gekennzeichnet.
Verwenden Sie den Befehl show call active voice im Benutzer-EXEC- oder privilegierten EXEC-Modus, um die Anrufinformationen für aktive Sprachanrufe anzuzeigen.
show call active voice [brief [id identifier] | compact [duration {less time | more time}] | echo-canceller call-id | id identifier | redirect {rtpvt | tbct}]
Dieser Befehl enthält viele Argumente. Diese Liste beschreibt einige der nützlichsten Argumente:
brief: (Optional) Zeigt eine gekürzte Version an.
compact (Optional) - Zeigt aktive Anrufe an, die länger oder kleiner als eine angegebene Zeit sind.
duration (Dauer): (Optional) Zeigt aktive Anrufe an, die länger oder kleiner als eine angegebene Zeit sind.
echo-Cancer call-id - (Optional) Zeigt Informationen über den Zustand der erweiterten Echounterdrückung (EC) an. Um den Echo-Zustand abfragen zu können, müssen Sie die Hex-ID im Voraus kennen. Um die Hex-ID zu finden, geben Sie den Befehl show call active voice brief ein, oder verwenden Sie den Befehl show voice call status (Sprachaufruf anzeigen). Der Bereich liegt zwischen 0 und FFFFFFFF.
Parameter für aktive Sprachübertragung anzeigen | Erläuterung des Parameters |
---|---|
ALLGEMEIN: | Allgemeine Statistiken für die nachfolgende POTS-Anrufkomponente |
SetupTime = 866793 ms | Die Uhrzeit in 100 ms erhöht sich, wenn die POTS-Komponente initiiert wird. Bei eingehenden ISDN POTS-Anrufen ist dies der Zeitpunkt, zu dem die Setup-Nachricht für Q.931-Anrufe empfangen wird. |
Index = 1 | |
PeerAddress=100 | Das Zielmuster, das diesem POTS-Peer entspricht. Bei einem eingehenden POTS-Anrufabschnitt ist dies die anrufende Nummer oder die automatische Rufnummernerkennung (Automatic Number Identification, ANI). |
PeerSubAddress= | |
PeerId=100 | Die DFÜ-Peer-ID für diesen Anrufabschnitt. In diesem Fall sind die PeerID und die PeerAddress, obwohl nicht erforderlich, identisch. |
PeerIfIndex=9 | Die Sprach-Port-Indexnummer für diesen Peer. Bei ISDN-Medien ist dies die Indexnummer des für diesen Anruf verwendeten B-Kanals. |
LogicalIfIndex=5 | Der Index, der intern verwendet wird, um die logische Schnittstelle für den Anruf zu identifizieren. |
ConnectTime = 867030 | Die Uhrzeit in 100 ms erhöht sich, wenn die POTS-Strecke verbunden wird. Bei einem eingehenden ISDN POTS-Anrufabschnitt ist dies der Zeitpunkt, an dem die Q.931-Anrufverbindungsnachricht gesendet wird. |
Anrufdauer=00:12:26 | Die Uhrzeit in hh:mm:ss, zu der der Anruf getätigt wird. |
CallState=4 | Der Anrufstatus für den Anrufabschnitt (4=aktiv,3=verbunden,2=Verbinden). Der Anrufstatus ist aktiv. |
CallOrigin=2 | Ursprung im Vergleich zu Antwort (1 = Ausgangspunkt, 2 = Antwort) für den Anrufabschnitt. Dieses Gateway beantwortet diesen POTS-Anrufabschnitt. |
ChargedUnits=0 | Die Gesamtzahl der Ladeeinheiten, die für diesen Peer seit dem Systemstart gelten. Die Maßeinheit für dieses Feld beträgt Hundertstel einer Sekunde. |
InfoType=2 | Der Informationstyp für diesen Anruf (1=Fax, 2=Sprache). Dies ist ein Sprachanruf. |
TransmitPackets=37291 | Die Anzahl der Pakete, die vom digitalen Signalprozessor (DSP) an die Telefonieschnittstelle übertragen werden. |
TransmitBytes = 725552 | Das Byteanzahl-Äquivalent des POTS TransmitPackets-Werts. |
ReceivePackets = 1689 | Die Anzahl der Pakete, die der DSP von der Telefonieschnittstelle erhält. |
ReceiveBytes = 33780 | Die Byteanzahl, die dem POTS ReceivePackets-Wert entspricht. |
TEIL: | POTS-Anrufbein |
ConnectionId=[0xC59FE183 0xB1700D7 0x0 0x84431C] | Dies ist die Verbindungs-Identifikationsnummer, die das Kabelmodem angibt, um diesen Anruf eindeutig darzustellen. Er ist für alle Anrufabschnitte auf diesem Gateway identisch. |
TxDuration = 746070 ms | Die Dauer des Anrufs (ms) = 12 Min. 26 Sekunden = 746 Sekunden = 746070 ms. |
VoiceTxDuration=33780 ms | Die kumulierte Zeit in ms, zu der Sprachpakete vom Telefonie-POTS-Peer an das VoIP-Gateway gesendet werden. |
FaxTxDuration=0 ms | Die kumulierte Zeit in ms, wenn sich der Router im Faxmodus befindet. |
CoderTypeRate=g729r8 | Der für den Anruf verwendete Codec. |
NoiseLevel=-59 | Der aktive Geräuschpegel für diesen Anruf. Dieser Wert wird im Komfort Noise Generation-Modul berechnet und zur Erzeugung von Komfortgeräusch verwendet, wenn Voice Activity Detection (VAD) aktiviert ist. |
ACOMLevel = 20 | Die aktuelle ACOM-Ebene für diesen Anruf. ACOM ist der durch den Echokompensation erzielte kombinierte Verlust. Dieser Wert ist die Summe aus den Verlusten für Echo Return Loss (ERL), Echo Return Loss Enhancement (ERLE) und Non-Linear Processing (NLP) für den Anruf. |
OutSignalLevel=-64 | Die Ausgangssignalstufe in Dezibel pro Milliwatt (dBm). |
InSignalLevel=-58 | Die Eingangssignalstufe in dBm. |
InfoActivity=2 | Der aktive Status der Aktivität zum Übertragen von Informationen für diesen Anruf. |
ERLevel = 20 | Die ERL für diesen Anruf. |
SessionTarget= | Dieser Wert gilt für VoIP-Anrufabschnitte. Dieser Wert wird im VoIP-DFÜ-Peer angegeben. Es gibt kein Sitzungsziel für POTS-Anrufabschnitte. |
ImgPages = 0 | |
ALLGEMEIN: | Allgemeine Statistiken für den VOIP-Anrufabschnitt: |
SetupTime = 866928 ms | Die Uhrzeit in 100 ms erhöht sich, wenn die VoIP-Anrufkomponente initiiert wird. Bei ausgehenden H.323-VoIP-Anrufen ist dies die Zeit, zu der die Setup-Nachricht für H.323-Anrufe gesendet wird. |
Index = 1 | |
PeerAddress=200 | Das Zielmuster des Peers. Bei einem ausgehenden VoIP-Anrufabschnitt ist dies die angerufene Nummer oder der Dienst zur Identifizierung der gewählten Nummer (DNIS). |
PeerSubAddress= | |
PeerId=200 | Die Peer-ID, die der DNIS-Befehl abgleicht. In diesem Fall sind die PeerID und der DNIS zwar nicht erforderlich, jedoch identisch. |
PeerIfIndex=11 | |
LogicalIfIndex=0 | |
ConnectTime = 867029 | Die Uhrzeitzeit in 100 ms erhöht die Anzahl der VoIP-Verbindungen. Bei einem ausgehenden H.323-VoIP-Anrufabschnitt ist dies die Zeit, zu der die H.323-Anrufverbindungsnachricht empfangen wird. |
Anrufdauer=00:12:27 | Die Dauer in hh:mm:ss eines Anrufs. |
CallState=4 | Der Anrufstatus für den Anrufabschnitt (4=aktiv,3=verbunden,2=Verbinden). Der Anrufstatus ist aktiv. |
CallOrigin=1 | Ursprung im Vergleich zu Antwort (1 = Ausgangspunkt, 2 = Antwort) für Anrufabschnitt. Dieses Gateway generiert diesen (VoIP) Anrufabschnitt. |
ChargedUnits=0 | |
InfoType=2 | |
TransmitPackets=1689 | Die Anzahl der VoIP-Pakete, die von diesem Gateway auf diesem Anrufabschnitt übertragen werden. |
TransmitBytes=33780 | Die Byteanzahl, die dem VoIP TransmitPackets-Wert entspricht. Dies muss der VoiceTxDuration-Stufe aus der Telefonie-Anrufkomponente entsprechen, da mit G.729 ein Byte pro 1 ms gesendet wird. |
ReceivePackets = 37343 | Die Anzahl der VoIP-Pakete, die von diesem Gateway auf diesem Anrufabschnitt empfangen werden. |
ReceiveBytes = 746860 | Die Byteanzahl, die dem VoIP ReceivePackets-Wert entspricht. |
VOIP: | VoIP-Anrufabschnitt |
ConnectionId[0xC59FE183 0xB1700D7 0x0 0x84431C] | Dies ist die Verbindungs-Identifikationsnummer, die das Kabelmodem angibt, um diesen Anruf eindeutig darzustellen. Er ist für alle Anrufabschnitte auf diesem Gateway identisch. |
RemoteIPAddress=10.1.1.2 | Die Remote-IP-Adresse für den Anruf. |
RemoteUDPPort=18280 | Der Remote User Datagram Protocol (UDP)-Port für den Anruf. |
RoundTripDelay=53 ms | Die Round-Trip-Verzögerung, gemessen vom Gateway. |
SelectedQoS=Best-Effort | Das Resource Reservation Protocol (RSVP) ist für diesen Anruf nicht im DFÜ-Peer ausgewählt. |
tx_dtmfRelay=cisco-rtp | Die für den Anruf verwendete Form von DTMF RELAY (falls vorhanden). |
SessionProtocol=cisco | Das Sitzungsprotokoll für den Anruf. Das Protokoll "cisco" ist der Standardwert, bei dem H.323-Signalisierungs- und RTP-Pakete für den Sprachverkehr verwendet werden. Das Session Intiation Protocol (SIP) ist das andere VoIP-Signalisierungsprotokoll, das mithilfe des Sitzungsprotokolls (nur registrierte Kunden) mit dem Befehl dial peer (DFÜ-Benutzer) festgelegt werden kann. Nicht-VoIP-Protokolle wie AAL2 für VoATM oder das proprietäre VoFR-Protokoll (Voice over Frame Relay) von Cisco und FRFll für VoFR können ebenfalls angegeben werden. |
SessionTarget=ipv4:10.1.1.2 | Das Sitzungsziel vom DFÜ-Peer. Das Sitzungsziel ist RAS, wenn ein Gatekeeper verwendet wird. |
OnTimeRvPlayout=742740 | Die Dauer in ms der Sprachwiedergabe aus den pünktlich für diesen Anruf empfangenen Daten. Die Gesamtdauer der Sprach-Playout-Dauer kann abgeleitet werden, indem der OnTimeRvPlayout-Dauer die Zeitdauer für die Lückenfüllung hinzugefügt wird. |
GapFillWithSilence=0 ms | Time (ms) Gateway (GW) spielte Stille. Stille spielt sich in diesen Situationen ab:
|
GapFillWithPrediction=0 ms | Die Dauer (in ms) des Sprachsignals, die mit dem Signal ausgespielt wird, das aus Parametern synthetisiert wurde, oder mit Stichproben von Daten, die dem Signal rechtzeitig vorangehen. Diese Lücke wird geschlossen, weil Sprachdaten für diesen Anruf verloren gehen oder nicht rechtzeitig vom Sprach-Gateway empfangen werden. Beispiele für solche Pullouts sind Frame-Easer- und Frame-Verheimlichungsstrategien in G.729- und G.723.1-Komprimierungsalgorithmen. |
GapFillWithInterpolation=0 ms | Was GapFillWithPrediction angeht, jedoch unter Berücksichtigung von Beispielen, die nach dem fehlenden Sprachdatenverkehr empfangen und im De-Jitter-Puffer gespeichert wurden. Derzeit nicht verwendet. |
GapFillWithRedundancy=0 ms | Wenn der Sender ein redundantes Kodierungsschema verwendet, kann die Nutzlast verlorener oder verspäteter Pakete teilweise oder vollständig wiederhergestellt werden, was die Sprachqualität weniger beeinträchtigt. Diese Technik wird derzeit nicht unterstützt. |
HiWaterPlayoutDelay=70 ms | Der First-In, First-Out (FIFO)-Jitter weist auf die maximale Tiefe hin, der der De-Jitter-Puffer für diesen Anruf angepasst wird. |
LoWaterPlayoutDelay=69 ms | Die niedrige Markierung für den FIFO-Jitter-Puffer gibt die Mindesttiefe an, an die sich der De-Jitter-Puffer für diesen Aufruf anpasst. |
ReceiveDelay = 69 ms | Die aktuelle Play-out FIFO-Verzögerung plus die Decoder-Verzögerung für den Anruf. |
LostPackets = 0 ms | Die verlorenen RTP-Pakete wurden in ms dargestellt. Jede positive Erhöhung der Sequenznummer fügt dem LostPackets-Zähler hinzu. Wenn beispielsweise ein Gateway Pakete mit einer Zahlenfolge in der Reihenfolge N-1, N, N+1, N+3, N+2, N+4 empfängt, erhöht sich der LostPackets-Zähler. Die Größe des Djitter-Puffers und der Zeitpunkt, zu dem das "verlorene" Paket eingeht, bestimmen, ob das Paket wiedergegeben werden kann. |
EarlyPackets = 1 ms | Die Anzahl der frühen RTP-Pakete, die in ms dargestellt werden. RTP-Pakete werden bei der Übertragung mit einem Zeitstempel versehen, und der RTP-Zeitstempel ist im Paket enthalten. Die Uhrzeit, zu der das Paket empfangen wird, wird ebenfalls von der lokalen Uhr des Kabelmodems festgelegt. Wenn die Zeitdifferenz zwischen den lokalen Uhren (empfangene Zeit) zweier benachbarter Pakete kleiner ist als die Differenz zwischen den RTP-Zeitstempeln (gesendete Zeit), wird das zweite Paket als früh angesehen. Ein frühes Paket kann auftreten, wenn die Netzwerkauslastung plötzlich sinkt. Dies führt zu einer geringeren Netzwerkverzögerung für ein bestimmtes Paket. |
LatePackets = 0 ms | Die Anzahl der verspäteten RTP-Pakete, die in ms dargestellt werden. Dieser Wert wird erhöht, wenn ein Paket mit einer RTP-Sequenznummer empfangen wird, wenn einer der folgenden Umstände eintritt:
|
VAD = aktiviert | Für diesen Anrufabschnitt ist VAD aktiviert. |
CoderTypeRate=g729r8 | Der für diesen Anruf verwendete Codec-Typ. |
CodecBytes = 20 | Die Nutzlastgröße für den verwendeten Codec in Byte. |
SignalingType=cas | Der Signalisierungstyp für den Anruf. Dies gilt nur für permanente Anrufe. |
Dieser Abschnitt enthält eine Diskussion über die Auswirkungen der Sprachqualität der markierten Parameter in der Tabelle Parameter.
Diese Parameter liefern Informationen zu einem bestimmten VoIP-Teil eines Anrufs. In diesem Beispiel für einen Anrufabschnitt stimmt der Anruf mit dem DFÜ-Peer 200 überein. Der verwendete Codec ist G.729 mit einer Nutzlastgröße von 20 Byte, und VAD ist aktiviert.
PeerId=200
CoderTypeRate=g729r8
CodecBytes = 20
VAD = aktiviert
In Kombination mit Informationen über die Netzwerkkonfiguration, wie dem Layer-2-Transport und der optionalen Verwendung von komprimiertem RTP, können Sie anhand dieser Informationen die Bandbreitenanforderungen pro Anruf für Anrufe bestimmen, die diesem DFÜ-Peer entsprechen. Weitere Informationen finden Sie unter Bandbreitennutzung pro Anruf unter Voice-over-IP.
Wenn die bereitgestellte Bandbreite nicht ausreicht, um die Anzahl der Anrufe zu unterstützen, kann das Ergebnis abgehackte oder synthetische Sprache sein.
Hinweis: Der Befehl call threshold kann als eine der Methoden für die Anrufzugangssteuerung verwendet werden, aber dieser Befehl funktioniert nicht für ausgehende Anrufe von ISDN-Schnittstellen zu H323-Netzwerken.
Wenn die Merkmale des Anrufabschnitts nicht korrekt erscheinen, überprüfen Sie die DFÜ-Peer-Konfiguration und die Zuordnung. Weitere Informationen finden Sie in einigen DFÜ-Peer-Dokumenten, die auf der Seite Technischer Support für Anrufweiterleitung/Nummernpläne aufgeführt sind.
Garbled Voice, bei dem abgehackte und synthetische Sprachfunktionen gute Beispiele sind, kann unter einer Reihe von Umständen auftreten, die normalerweise mit falsch bereitgestellten WAN-Links verbunden sind. Dies kann auf einen Mangel an entsprechender CAC-Steuerung (Connection Admission Control) oder eine falsch konfigurierte Priorisierung der Sprachdaten zurückzuführen sein. Der Befehl show call active voice bietet Einblick in diese Probleme mit folgenden Parametern:
OnTimeRvPlayout=742740
GapFillWithSilence=0 ms
GapFillWithPrediction=0 ms
HiWaterPlayoutDelay=70 ms
LoWaterPlayoutDelay=69 ms
ReceiveDelay = 69 ms
LostPackets = 0 ms
EarlyPackets = 1 ms
LatePackets = 0 ms
Der OnTimeRvPlayout-Befehl bietet eine gute allgemeine Ansicht des Status des Anrufs, wenn er mit der Gesamtdauer der Sprach-Layoutdauer verglichen wird. Die Gesamtdauer der Sprach-Playout-Dauer kann abgeleitet werden, indem der OnTimeRvPlayout-Dauer die Zeitdauer der Lückenfüllung hinzugefügt wird. Wenn der Anteil der pünktlichen Sprachausgabe hoch ist, ist der Anruf wahrscheinlich gesund.
Pakete, die im Paketnetzwerk verworfen oder zu lange verzögert werden, können zu Qualitätsproblemen bei der Sprachübertragung führen.
Bei Erhalt von Paketen, die so lange verzögert werden, dass sie nicht genutzt werden können, oder wenn Pakete im Netzwerk verworfen und überhaupt nicht empfangen werden, versucht ein IP-Telefon oder Voice Gateway, den Sprachstream bestmöglich durch die Voraussage des Sprachsignals wiederherzustellen.
Führen Sie den Befehl show call active voice auf einem IOS-Gateway wiederholt aus, um Transparenz hinsichtlich dieses Problems zu gewährleisten:
LatePackets: Die Anzahl der Pakete, die außerhalb der Wiedergabepause für den De-Jitter-Puffer eintreffen. Diese Pakete werden verworfen.
LostPackets (Verlorene Pakete): Die Anzahl der Pakete, die nie am empfangenden IP-Telefon oder Gateway eintreffen.
GapFillWithPrediction: Die Anzahl der Paketprognosen in einem Aufruf. Teilen Sie diese Zahl durch die Paketstichprobenzeit, um die Anzahl der betroffenen Pakete zu ermitteln.
GapFillWithSilence: Die Menge der Stille, die in den Anruf eingefügt wird.
Hinweis: Der Befehl show port voice active auf einem Catalyst-Gateway gibt Ihnen einen Hinweis auf Jitter für einen Anruf (Hi/Low Water Play-Out-Verzögerung), obwohl er nicht zwischen Vorhersage und Schweigeeinfügung unterscheidet.
Eine geringe Menge prädiktiver Insertion ist für das menschliche Ohr nicht erkennbar. Allerdings verursacht eine große Menge wahrscheinlich eine verstümmelte Qualität in der Stimme, die als synthetische oder robotische Stimme beschrieben werden kann.
Wenn Pakete verworfen oder spät eintreffen, kann der Codec-Decoder des Empfängers das Sprachsignal nicht vorhersagen. In diesem Fall wird das Signal durch Schweigen ersetzt, die in Sprache eingefügt wird.
Wenn die Verzögerung variabel (Jitter) ist, werden Pakete ausgegeben, die zu spät, aber innerhalb der Play-Out-Verzögerungszeit des Empfangs-De-Jitter-Puffers eintreffen, aber einen Unterlauf des De-Jitter-Puffers verursachen können. Ein Unterlauf tritt auf, wenn keine Pakete im Puffer verbleiben und die Sprache verzögert wird, wenn der Puffer auf das Eintreffen des nächsten Pakets wartet. Eine auditive Sprachlücke kann dazu führen.
Eine kleine Menge von Stille oder Jitter ist für das menschliche Ohr nicht erkennbar. Eine große Menge verursacht jedoch wahrscheinlich eine Qualität der Stimme, die als abgehackte Stimme oder unterbrochene Stimme beschrieben werden kann.
Hinweis: Wenn die Netzwerkverzögerung variabel genug ist, ist es wahrscheinlich, dass das resultierende Geräusch der Rede sowohl synthetisch als auch abgehackt ist.
Beheben von Sprachproblemen
Bestimmen Sie die Ursache der Verzögerung und beseitigen Sie sie (wenn möglich).
Die Ursachen für Verwerfen oder Verzögerungen in einem Telefonnetz können vielfältig sein. Einige häufige Beispiele:
Falsch konfigurierte Fragmentierung für Verbindungen mit niedriger Geschwindigkeit
Falsch konfiguriertes Traffic Shaping und/oder Frame Relay CIR (nur registrierte Kunden) wurde überschritten
Links mit übermäßiger Bandbreite im Anrufpfad. Beispiel: schlechte CAC für Sprachanrufe. Ein Beispiel ist ein G.711-Anruf ohne cRTP oder VAD über eine 64-Kbit/s-Verbindung.
Duplex-Diskrepanzen in einer Ethernet-Umgebung
CPU-intensive Operationen auf einem Router im Anrufpfad. Beispielsweise kann das Debuggen in einer Konsole oder das Speichern der Router-Konfiguration zu einer hohen CPU-Auslastung führen, die Pakete verzögert, die sie durchlaufen.
Es ist auch möglich, die Gateway-De-Jitter-Puffer so anzupassen, dass die Sprachleistung in suboptimalen Datennetzwerken verbessert wird. Die Ergebnisse sind jedoch auf das korrekte Verhalten des Datennetzwerks beschränkt. Weitere Informationen finden Sie unter Fehlerbehebung bei QoS-Problemen mit abgehackten Sprachfunktionen oder in einer Reihe von Dokumenten auf der Seite Sprachqualität Technischer Support.
Diese Parameter geben an, ob für diesen Anruf VAD verwendet wird und welcher DFÜ-Peer verwendet wird:
VAD = aktiviert
PeerId=200
NoiseLevel=-59
Beheben von Fehlern beim Klicken und Löschen
Um Fehler und Probleme mit dem Front-End-Clipping zu beheben, müssen Sie die Werte für die Musikschwelle oder Vad-Time anpassen (oder VAD deaktivieren), bevor Sie andere mögliche Probleme beheben.
Test durch Deaktivierung von Komfort-Geräusch (nur registrierte Kunden) oder vollständige Deaktivierung von VAD. Wenn das Symptom nicht mehr auftritt, ist die Komfort-Geräuscherzeugung die wahrscheinliche Ursache des Problems. Durch die Reduzierung des Musikschwellenwerts (nur registrierte Kunden), bei dem Sprachdaten erkannt werden, oder die Erhöhung der Vad-Time-Werte (nur registrierte Kunden) auf dem Gateway kann das Hissing oder Clipping weniger spürbar werden, ohne dass VAD dauerhaft deaktiviert werden muss. Diese Techniken deaktivieren VAD im Wesentlichen bei geringem Volumen bzw. bei kleinen Lücken. Es ist nicht praktikabel, nur Komfortgeräusch zu deaktivieren, da diese Aktion andere Symptome für die Sprachqualität hervorruft, wie Klicken und/oder Lücken für absolute Stille zwischen Sätzen.
Weitere Informationen finden Sie unter Fehlerbehebung bei Fehlern und Statisch. Wenn diese Optimierungstechniken das Problem nicht lösen, deaktivieren Sie VAD. Dies führt zu Bandbreiteneinsparungen.
Beheben von Fehlern beim Klicken und Löschen in eine Richtung
VAD ist die Ursache der meisten Hissing-Probleme. Daher ist es wichtig zu ermitteln, ob diese Funktion aktiviert ist. Einer der ersten Schritte zur Fehlerbehebung beim Fehlschlagen von Sätzen oder beim Frontend-Clipping ist die Deaktivierung von VAD. Es ist daher wichtig, dass Sie feststellen können, ob die Funktion deaktiviert ist.
Tritt das Herumspringen oder Abklappen nur in eine Richtung, d. h. in die ausgehende Richtung, auf, kann dies darauf zurückzuführen sein, dass VAD in diese Richtung aktiviert ist, obwohl Sie versucht haben, es im VoIP-DFÜ-Peer zu deaktivieren. In diesem Fall zeigt der Befehl show call active voice VAD enabled und die verwendete Peer-ID 0. Um dieses Problem zu beheben, konfigurieren Sie den Befehl für eingehende Anrufe <number_dial> (nur registrierte Kunden) auf dem VoIP-DFÜ-Peer, um sicherzustellen, dass Anrufe beim PSTN mit diesem Peer am Gateway übereinstimmen. Ansonsten stimmen Anrufe in dieser Richtung mit dem standardmäßigen DFÜ-Peer überein, für den VAD standardmäßig aktiviert ist.
Diese Parameter sind wichtig für die Fehlerbehebung bei Echo:
ACOMLevel = 20
OutSignalLevel=-64
InSignalLevel=-58
ERLevel = 20
Die Ausgabe des Testtons ist -15 und wird mit einem Loopback von 0 dB zurückgeleitet. Daher beträgt der Wert -15 dB. Der ERL-Wert hat zu diesem Zeitpunkt keine Bedeutung, da die Echounterdrückung das Eingangssignal nicht als Echosignal ansieht.
Hinweis: OutSignalLevel zeigt den Wert der Ebene an, nachdem die Ausgangsdämpfung auf das Signal angewendet wurde. InSignalLevel zeigt den Wert der Ebene an, nachdem die Eingangsverstärkung angewendet wurde.
Wenn der ERL-Wert zu niedrig ist, ist das Echo-Signal, das zum Gateway zurückkehrt, möglicherweise zu laut (innerhalb von 6 dB des Talker-Signals). Dadurch wird die Echokompensation als Sprache (Double-Talk) und nicht als Echo angesehen. Daher wird das Echo durch die Echounterdrückung nicht abgebrochen. Die ERL muss zwischen 6 dB und 20 dB liegen, damit die Echounterdrückung aktiviert werden kann.
Informationen zur Behebung von Echoproblemen zwischen IP-Telefonen und Cisco IOS-Gateways und zur Fehlerbehebung bei Echo in IP-Telefonienetzwerken (Audio on Demand) finden Sie unter Beheben von Echoproblemen.
In diesem Abschnitt wird erläutert, wie Sie den Befehl show call active voice verwenden, um Jitter und typische Symptome der Sprachqualität zu identifizieren.
Eine allgemeine Vorstellung von Jitter im Netzwerk kann durch wiederholtes Ausführen des Befehls show call active voice während eines Gesprächs ermittelt werden. Im Idealfall sollten diese Parameter relativ konstant bleiben. Ist dies der Fall, ist dies ein Hinweis auf einen reibungslosen Paketfluss. Wenn jedoch Jitter vorhanden ist, gibt es scharfe, kurzfristige Spitzen, wie sie in den beiden Beispielergebnissen gezeigt werden:
GapFillWithSilence=950 ms GapFillWithPrediction=1980 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms HiWaterPlayoutDelay=350 ms LoWaterPlayoutDelay=25 ms ReceiveDelay=29 ms LostPackets=0 EarlyPackets=0 LatePackets=83
. . GapFillWithSilence=1040 ms GapFillWithPrediction=2350 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms HiWaterPlayoutDelay=40 ms LoWaterPlayoutDelay=28 ms ReceiveDelay=35 ms LostPackets=0 EarlyPackets=0 LatePackets=99
Die wachsende Anzahl an verspäteten Paketen in diesen Beispielausgaben zeigt einen gewissen Grad an Jitter. Die durch eine Erhöhung des GapFillWithSilence-Werts angezeigte Stille manifestiert sich als abgehackte Stimme. Die vorausschauende Einfügung, die durch eine Erhöhung des GapFillWithPrediction-Werts angezeigt wird, neigt dazu, sich als synthetische Stimme zu manifestieren.
Führen Sie den Befehl play-delay aus, um die Anzahl der gepufferten Sprachsignale zu verändern, um zu verhindern, dass der Puffer nicht ausgelastet oder überlaufen wird.
Die beiden Konfigurationsmodi für die Wiedergabepause sind adaptiv und fest:
Adaptiv ermöglicht das Vergrößern und Verkleinern des Jitter-Puffers für die Dauer des Anrufs innerhalb eines konfigurierten Bereichs, wenn Sie die Play-Out-Verzögerung ausgeben {Nominaler Wert} | Maximaler Wert | Minimum {Default | Niedrig | high}}-Befehl.
Fest wird zu Beginn eines Anrufs festgelegt, wenn Sie den Wiedergabeverzögerungsmodus ausgeben {adaptiv | fixed [no-timestamps]}-Befehl.
Weitere Informationen zu VoIP finden Sie unter Verbesserungen bei der Playout-Verzögerung.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
31-Jul-2006 |
Erstveröffentlichung |