In diesem Dokument wird die Befehlsausgabe show call active voice (nur für registrierte Kunden) erläutert und veranschaulicht, wie durch die Befehlsausgabe Probleme mit der Sprachqualität behoben werden.
Hinweis: Die in diesem Dokument erwähnten Befehle sind mit dem Command Lookup Tool verknüpft (nur für registrierte Kunden). Mit diesem Tool können Sie nach weiteren Informationen zu bestimmten Befehlen suchen.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Mit dem Befehl show call active voice (Anruf mit aktiver Stimme anzeigen) können Sie den Inhalt der Tabelle mit aktiven Anrufen anzeigen. Die angezeigten Informationen umfassen Anrufzeiten, DFÜ-Peers, Verbindungen, Quality-of-Service-Parameter und die Verarbeitung von Jitter durch das Gateway. Diese Informationen können bei der Behebung verschiedener Probleme mit der Sprachqualität hilfreich sein.
Die Tabelle in diesem Dokument enthält die Ausgabe eines Beispielbefehls show call active voice sowie eine kurze Erläuterung der einzelnen Parameter.
Hinweis: Mit dem Befehl show call active voice werden Daten des einfachen alten Telefondienstes (POTS) und der VoIP-Anrufabschnitte am Sprach-Gateway angezeigt. Einige Parameter werden fett dargestellt, um im weiteren Verlauf des Dokuments besprochen zu werden.
Der Befehl show call active zeigt Werte für die Telefonie- und die VoIP-Komponente eines jeden aktiven Anrufs an. Für jeden Abschnitt werden die gleichen allgemeinen Parameter angezeigt, gefolgt von Parametern, die für den Typ des Anrufabschnitts spezifisch sind. In dieser Tabelle werden diese Parameterabschnitte durch einen schattierten Header gekennzeichnet.
Verwenden Sie den Befehl show call active voice im Benutzer-EXEC- oder privilegierten EXEC-Modus, um Anrufinformationen für laufende Sprachanrufe anzuzeigen.
show call active voice [brief [id identifier] | compact [duration {less time | more time}] | echo-canceller call-id | id identifier | redirect {rtpvt | tbct}]
Für diesen Befehl gibt es viele Argumentoptionen. Diese Liste beschreibt einige der nützlicheren Argumente:
brief - (Optional) Zeigt eine gekürzte Version an.
compact - (Optional) Zeigt aktive Anrufe an, die länger oder kürzer als eine angegebene Zeit sind.
duration (Optional) Zeigt aktive Anrufe an, die länger oder kürzer als eine angegebene Zeit sind.
echo-cancel call-id - (Optional) Zeigt Informationen zum Status der erweiterten Echokompensation an. Um den Echo-Status abzufragen, müssen Sie die Hex-ID im Voraus kennen. Um die Hex-ID zu ermitteln, geben Sie den Befehl show call active voice brief ein, oder verwenden Sie den Befehl show voice call status. Der Bereich liegt zwischen 0 und FFFFFFFF.
show call active voice-Parameter | Erläuterung des Parameters |
---|---|
ALLGEMEIN: | Allgemeine Statistiken für den POTS-Anrufabschnitt: |
SetupTime=866793 ms | Die Taktzeit in 100 ms erhöht sich, wenn der POTS-Abschnitt initiiert wird. Bei eingehenden ISDN-POTS-Anrufen ist dies der Zeitpunkt, an dem die Q.931-Anrufeinrichtungsnachricht empfangen wird. |
Index = 1 | |
PeerAddress=100 | Das Zielmuster, das zu diesem POTS-Peer passt. Bei einem eingehenden POTS-Anrufabschnitt ist dies die anrufende Nummer oder die automatische Rufnummernerkennung (Automatic Number Identification, ANI). |
PeerSubAddress= | |
Peer-ID = 100 | Die für diesen Anrufabschnitt verwendete DFÜ-Peer-ID. In diesem Fall sind PeerID und PeerAddress zwar nicht erforderlich, aber identisch. |
PeerIfIndex=9 | Die Indexnummer des Sprach-Ports für diesen Peer. Bei ISDN-Medien ist dies die Indexnummer des für diesen Anruf verwendeten B-Kanals. |
LogicalIfIndex=5 | Der intern verwendete Index zur Identifizierung der logischen Schnittstelle für den Anruf. |
ConnectTime=867030 | Die Uhrzeit in 100 ms erhöht sich, wenn der POTS-Abschnitt eine Verbindung herstellt. Bei einem eingehenden ISDN POTS-Anrufabschnitt ist dies der Zeitpunkt, zu dem die Q.931-Verbindungs-Nachricht gesendet wird. |
Anrufdauer=00:12:26 | Die Zeit in hh:mm:ss, für die der Anruf erstellt wird. |
Anrufstatus = 4 | Der Anrufstatus für die Anrufstrecke (4=aktiv,3=verbunden,2=verbunden). Der Anrufstatus ist aktiv. |
Anrufquelle = 2 | Ursprung und Antwort (1 = Ursprung, 2 = Antwort) für den Anrufabschnitt. Dieses Gateway beantwortet diesen Anrufabschnitt (POTS). |
ChargedUnits = 0 | Die Gesamtanzahl der Ladeeinheiten, die seit dem Systemstart auf diesen Peer angewendet wurden. Die Maßeinheit für dieses Feld ist eine Hundertstelsekunde. |
InfoType=2 | Der Informationstyp für diesen Anruf (1=Fax, 2=Sprache). Dies ist ein Telefongespräch. |
TransmitPackets = 37291 | Die Anzahl der Pakete, die vom digitalen Signalprozessor (DSP) an die Telefonieschnittstelle übertragen werden. |
TransmitBytes = 725552 | Das Byteäquivalent des POTS-TransmitPackets-Werts. |
ReceivePackets=1689 | Die Anzahl der Pakete, die der DSP von der Telefonieschnittstelle empfangen hat. |
ReceiveBytes = 33780 | Das Byteäquivalent des POTS ReceivePacketsPackets-Werts. |
TELE: | POTS-Rufstrecke |
ConnectionId=[0xC59FE183 0xB1700D7 0x0 0x84431C] | Dies ist die Verbindungsidentifizierungsnummer, die das Kabelmodem bereitstellt, um diesen Anruf eindeutig darzustellen. Er wird über alle Anrufabschnitte des Anrufs auf diesem Gateway abgeglichen. |
TxDuration=746070 ms | Die Dauer des Anrufs (ms) = 12 Minuten 26 Sekunden = 746 Sekunden = 746070 ms. |
VoiceTxDuration=33780 ms | Die kumulierte Zeit in ms, in der Sprachpakete vom Telefonie-POTS-Peer an das VoIP-Gateway gesendet werden. |
FaxTxDuration=0 ms | Die kumulierte Zeit in ms, während der Router sich im Faxmodus befindet. |
CoderTypeRate=g729r8 | Der für den Anruf verwendete Codec. |
Rauschpegel = -59 | Der aktive Geräuschpegel für diesen Anruf. Dieser Wert wird im Modul zur Erzeugung von Komfortrauschen berechnet und zur Erzeugung von Komfortrauschen verwendet, wenn die Sprachpausenerkennung (VAD) aktiviert ist. |
ACOMLevel=20 | Die aktuelle ACOM-Ebene für diesen Anruf. ACOM ist der kombinierte Verlust, der durch den Echokompensator erzielt wird. Dieser Wert ist die Summe der Verluste aus Echorückstrahlungsverlusten (ERL), Echorückstrahlungsverlusten (ERLE) und nichtlinearen Verarbeitungsprozessen (NLP) für den Anruf. |
OutSignalLevel=-64 | Der Ausgangssignalpegel in Dezibel pro Milliwatt (dBm). |
InSignalLevel=-58 | Eingangssignalpegel in dBm. |
InfoActivity=2 | Der Aktivitätsstatus für die aktive Informationsübertragung für diesen Anruf. |
ERL-Pegel = 20 | Die URL für diesen Anruf. |
Sitzungsziel | 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 folgenden VoIP-Anrufabschnitt: |
SetupTime=866928 ms | Die Uhrzeit in 100 ms wird erhöht, wenn die VoIP-Gesprächsverbindung initiiert wird. Bei ausgehenden H.323-VoIP-Anrufen ist dies der Zeitpunkt, an dem die H.323-Anrufeinrichtungsnachricht gesendet wird. |
Index = 1 | |
PeerAddress=200 | Das Zielmuster des Peers. Bei einem ausgehenden VoIP-Anrufabschnitt ist dies die angerufene Nummer oder der gewählte Rufnummernidentifizierungsdienst (DNIS). |
PeerSubAddress= | |
PeerId = 200 | Die Peer-ID, mit der der DNIS übereinstimmt. In diesem Fall sind Peer-ID und DNIS zwar nicht erforderlich, aber identisch. |
PeerIfIndex = 11 | |
LogicalIfIndex=0 | |
ConnectTime=867029 | Die Uhrzeit in 100 ms-Schritten, mit der die VoIP-Verbindung hergestellt wird. Bei einem ausgehenden H.323-VoIP-Anrufabschnitt ist dies der Zeitpunkt, an dem die H.323-Verbindungs-Nachricht empfangen wird. |
Anrufdauer=00:12:27 | Die Dauer eines Anrufs in hh:mm:ss. |
Anrufstatus = 4 | Der Anrufstatus für die Anrufstrecke (4=aktiv, 3=verbunden, 2=verbunden). Der Anrufstatus ist aktiv. |
Anrufquelle = 1 | Ursprung und Antwort (1 = Ursprung, 2 = Antwort) für die Anrufstrecke Von diesem Gateway stammt diese (VoIP-)Anrufstrecke. |
ChargedUnits = 0 | |
InfoType=2 | |
TransmitPackets = 1.689 | Die Anzahl der VoIP-Pakete, die von diesem Gateway für diesen Anrufabschnitt übertragen wurden |
TransmitBytes = 33780 | Die Byteanzahl, die dem VoIP TransmitPackets-Wert entspricht. Dies muss der VoiceTxDuration-Einstellung im Telefonie-Anrufabschnitt 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 wurden |
ReceiveBytes = 746860 | Die Byteanzahl, die dem VoIP ReceivePackets-Wert entspricht. |
VOIP: | VoIP-Anrufstrecke |
Verbindungs-ID[0xC59FE183 0xB1700D7 0x0 0x84431C] | Dies ist die Verbindungsidentifizierungsnummer, die das Kabelmodem bereitstellt, um diesen Anruf eindeutig darzustellen. Er wird über alle Anrufabschnitte des Anrufs auf diesem Gateway abgeglichen. |
RemoteIPAddress=10.1.1.2 | Die Remote-IP-Adresse für den Anruf. |
RemoteUDPPort=18280 | Der Remote-UDP-Port (User Datagram Protocol) für den Anruf. |
RoundTripDelay = 53 ms | Die Round-Trip-Verzögerung, gemessen vom Gateway. |
SelectedQoS=bestmögliche Leistung | Das Resource Reservation Protocol (RSVP) ist im DFÜ-Peer für diesen Anruf nicht ausgewählt. |
tx_DtmfRelay=cisco-rtp | Die Form des DTMF RELAY, die für den Anruf verwendet wird (falls verfügbar). |
SessionProtocol = Cisco | Das Session Protocol für den Anruf. Das Standardprotokoll "cisco" verwendet H.323-Signalisierung und RTP-Pakete für den Sprachverkehr. Session Initiation Protocol (SIP) ist das andere VoIP-Signalisierungsprotokoll, das mithilfe des DFÜ-Peer-Befehls des Sitzungsprotokolls (nur registrierte Kunden) festgelegt werden kann. Es können auch 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 angegeben werden. |
SessionTarget=ipv4:10.1.1.2 | Das Sitzungsziel des DFÜ-Peers. Das Sitzungsziel ist RAS, wenn ein Gatekeeper verwendet wird. |
OnTimeRvLayout=742740 | Die Dauer in ms der Sprachwiedergabe aus den pünktlich für diesen Anruf empfangenen Daten. Die Gesamtdauer des Sprach-Playouts kann abgeleitet werden, indem die Lückenfülldauer zur OnTimeRvPlayout-Dauer hinzugefügt wird. |
GapFillWithSilence = 0 ms | Zeit (ms) Gateway (GW) spielte Stille. In diesen Situationen spielt sich Schweigen ab:
|
GapFillWithPrediction=0 ms | Die Dauer in ms des Sprachsignals, das bei der Synthese des Signals aus Parametern oder zeitlich vorangehenden Datenmustern abgespielt wird. Diese Lücke wird geschlossen, weil Sprachdaten verloren gehen oder nicht rechtzeitig vom Sprach-Gateway für diesen Anruf empfangen werden. Beispiele für einen solchen Pullout sind Frame-Radiergummi- und Frame-Verbergungsstrategien in G.729- und G.723.1-Kompressionsalgorithmen. |
GapFillWithInterpolation=0 ms | Wie für GapFillWithPrediction, aber unter Berücksichtigung von Samples, 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 und mit einem geringeren Einfluss auf die Sprachqualität wiedergegeben werden. Diese Technik wird derzeit nicht unterstützt. |
HiWaterPlayoutDelay=70 ms | Die FIFO-Markierung (First-In, First-Out) für den Jitter-Puffer, die die maximale Tiefe angibt, bis zu der sich der De-Jitter-Puffer für diesen Anruf anpasst. |
LoWaterPlayoutDelay=69 ms | Der FIFO-Jitter-Puffer-Low-Mark, der die minimale Tiefe angibt, an die sich der De-Jitter-Puffer für diesen Anruf anpasst. |
ReceiveDelay = 69 ms | Die aktuelle FIFO-Wiedergabeverzögerung plus die Decoderverzögerung für den Anruf. |
Verlorene Pakete = 0 ms | Die verlorenen RTP-Pakete in ms. Jeder positive Sprung in der Sequenznummer wird dem Zähler "LostPackets" hinzugefügt. Wenn ein Gateway beispielsweise Pakete mit einer Ziffernfolge in der Reihenfolge N-1, N, N+1, N+3, N+2, N+4 empfängt, erhöht sich der Zähler für verlorene Pakete. Die Größe des Dejitter-Puffers und der Zeitpunkt, an dem das verlorene Paket eintrifft, bestimmen, ob das Paket abgespielt werden kann. |
Early Packets = 1 ms | Die Anzahl der frühen RTP-Pakete, dargestellt in ms RTP-Pakete werden beim Senden mit einem Zeitstempel versehen, und der RTP-Zeitstempelwert wird in das Paket eingefügt. Die Uhrzeit, zu der das Paket empfangen wird, wird ebenfalls von der lokalen Uhr des Gateways bestimmt. Wenn die lokale Zeitdifferenz (empfangene Zeit) zweier benachbarter Pakete kleiner ist als die Differenz ihrer RTP-Zeitstempel (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, dargestellt in ms. Dieser Wert wird erhöht, wenn ein Paket mit einer RTP-Sequenznummer empfangen wird, und zwar in einem der folgenden Fälle:
|
VAD = aktiviert | VAD ist für diese Anrufstrecke aktiviert. |
CoderTypeRate=g729r8 | Der für diesen Anruf verwendete Codec-Typ. |
CodecByte = 20 | Die Nutzlastgröße für den verwendeten Codec in Byte. |
SignalingType=CAS | Der Signalisierungstyp für den Anruf. Dies gilt nur für Daueranrufe. |
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-Abschnitt eines Anrufs. In diesem Beispiel für einen Anrufabschnitt entspricht der Anruf dem DFÜ-Peer 200, als Codec wird G.729 mit einer Nutzlastgröße von 20 Byte verwendet, und VAD ist aktiviert.
PeerId = 200
CoderTypeRate=g729r8
CodecByte = 20
VAD = aktiviert
In Kombination mit Informationen über die Netzwerkkonfiguration, z. B. dem Layer-2-Transport und der optionalen Verwendung von komprimiertem RTP, können Sie mit diesen Informationen die Bandbreitenanforderungen pro Anruf für Anrufe ermitteln, die diesem DFÜ-Peer entsprechen. Weitere Informationen finden Sie unter Voice Over IP - Per Call Bandwidth Consumption (Voice-over-IP - Bandbreitennutzung pro Anruf).
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 an H323-Netzwerke.
Wenn die Merkmale des Anrufabschnitts nicht richtig zu sein scheinen, überprüfen Sie die DFÜ-Peer-Konfiguration und die Übereinstimmung. Weitere Informationen finden Sie in einigen der Dokumente zum DFÜ-Peer, die auf der Seite Technischer Support für Anrufweiterleitung/Wählpläne aufgeführt sind.
Verstümmelte Sprachverbindungen, wofür abgehackte und synthetische Sprachverbindungen gute Beispiele sind, können unter verschiedenen Umständen auftreten, die in der Regel mit falsch bereitgestellten WAN-Verbindungen verbunden sind. Mögliche Ursachen sind das Fehlen einer geeigneten Zugangskontrolle (Connection Admission Control, CAC) oder eine falsch konfigurierte Priorisierung von Sprachdaten. Der Befehl show call active voice bietet Einblick in diese Probleme mithilfe der folgenden Parameter:
OnTimeRvLayout=742740
GapFillWithSilence = 0 ms
GapFillWithPrediction=0 ms
HiWaterPlayoutDelay=70 ms
LoWaterPlayoutDelay=69 ms
ReceiveDelay = 69 ms
Verlorene Pakete = 0 ms
Early Packets = 1 ms
LatePackets = 0 ms
Der Befehl OnTimeRvPlayout bietet eine gute allgemeine Ansicht des Zustands des Anrufs, wenn er mit der Gesamtdauer des Sprach-Playouts verglichen wird. Die Gesamtdauer des Sprach-Playouts kann durch Hinzufügen der Lückenfülldauern zur OnTimeRvPlayout-Dauer abgeleitet werden. Wenn der Anteil der pünktlichen Sprachwiedergabe hoch ist, ist der Anruf wahrscheinlich fehlerfrei.
Verworfene oder zu lange verzögerte Pakete im Paketnetzwerk können Probleme mit der Sprachqualität verursachen.
Beim Empfang von Paketen, die so lange verzögert sind, dass sie nicht verwendet werden können, oder wenn Pakete im Netzwerk verworfen und überhaupt nicht empfangen werden, versucht ein IP-Telefon oder Voice Gateway den Sprachdatenstrom durch die Vorhersage des Sprachsignals bestmöglich zu rekonstruieren.
Führen Sie wiederholt den Befehl show call active voice auf einem IOS-Gateway aus, um die Transparenz dieses Problems zu gewährleisten:
LatePackets: Die Anzahl der Pakete, die außerhalb der De-Jitter-Puffer-Wiedergabeverzögerungsperiode ankommen. Diese Pakete werden verworfen.
LostPackets: Die Anzahl der Pakete, die nie am empfangenden IP-Telefon oder Gateway eingehen.
GapFillWithPrediction (GapFillWithPrediction): Die Menge der Paketvorhersage in einem Aufruf. Teilen Sie diese Zahl durch die Paketstichprobenzeit, um die Anzahl der betroffenen Pakete zu ermitteln.
GapFillWithSilence - Die Anzahl der Stille, die in den Aufruf eingefügt wird.
Hinweis: Der Befehl show port voice active auf einem Catalyst Gateway gibt einen Hinweis auf Jitter bei einem Anruf (Playout-Verzögerung bei hoher/niedriger Signalstärke), unterscheidet jedoch nicht zwischen vorhersagbarer und Pauseneinfügung.
Ein kleiner Anteil an prädiktiver Insertion ist für das menschliche Ohr nicht nachweisbar. 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 werden oder spät ankommen, ist es dem empfangenden Codec-Decoder nicht möglich, das Sprachsignal vorherzusagen. In diesem Fall wird das Signal durch in Sprache eingefügte Stille ersetzt.
Wenn die Verzögerung variabel ist (Jitter), werden Pakete, die spät, aber innerhalb der Wiedergabeverzögerungszeit des empfangenden De-Jitter-Puffers ankommen, abgespielt, können jedoch einen Unterlauf des De-Jitter-Puffers verursachen. Ein Unterlauf tritt auf, wenn keine Pakete mehr im Puffer gespeichert sind und die Sprache verzögert wird, wenn der Puffer auf das nächste Paket wartet. Eine akustische Lücke in der Sprache kann die Folge sein.
Eine kleine Menge von Stille Insertion oder Jitter ist für das menschliche Ohr nicht nachweisbar. Ein großer Teil der Sprachqualität kann jedoch auch als abgehackte oder unterbrochene Stimme bezeichnet werden.
Hinweis: Wenn die Netzwerkverzögerung ausreichend variabel ist, ist es wahrscheinlich, dass der resultierende Laut der Sprache sowohl synthetisch als auch abgehackt ist.
Beheben von Problemen mit verstümmelten Sprachfunktionen
Bestimmen Sie die Ursache der Verzögerung und beseitigen Sie sie (wenn möglich).
Die Ursachen von Verlusten oder Verzögerungen in einem Pakettelefonie-Netzwerk können vielfältig sein. Einige gängige Beispiele:
Falsch konfigurierte Fragmentierung für langsame Verbindungen
Falsch konfigurierte Traffic-Shaping und/oder Frame-Relay-CIR (nur registrierte Kunden) überschritten
Verbindungen mit überlasteter 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.
Duplexdiskrepanzen in einer Ethernet-Umgebung
CPU-intensiver Betrieb auf einem Router im Pfad des Anrufs. Debugging-Vorgänge an einer Konsole oder das Speichern der Router-Konfiguration können eine hohe CPU-Auslastung verursachen, die die Übertragung von Paketen verzögert.
Es ist auch möglich, die Gateway-De-Jitter-Puffer auf eine bessere Sprachleistung in suboptimalen Datennetzwerken abzustimmen. Die Ergebnisse sind jedoch auf das korrekte Verhalten des Datennetzes beschränkt. Weitere Informationen finden Sie unter Troubleshooting QoS Choppy Voice Issues (Problembehebung bei abgehackten QoS-Sprachsystemen) oder in einer Reihe der Dokumente, die auf der Seite für den technischen Support für Sprachqualität aufgeführt sind.
Anhand dieser Parameter wird ermittelt, ob VAD für diesen Anruf verwendet wird und welcher DFÜ-Peer verwendet wird:
VAD = aktiviert
PeerId = 200
Rauschpegel = -59
Beheben von Problemen beim Verstreichen und Beschneiden
Um Fehler und einige Front-End-Clipping-Probleme zu beheben, passen Sie die Musik-Schwellwert- oder VAD-Zeit-Werte an (oder deaktivieren Sie VAD), bevor Sie andere mögliche Probleme beheben.
Testen Sie das System, indem Sie Comfort-Noise (nur für registrierte Kunden) oder VAD vollständig deaktivieren. Wenn das Symptom zum Erliegen kommt, ist die Erzeugung von beruhigendem Geräusch die wahrscheinliche Ursache des Problems. Durch die Verringerung der Musik-Schwelle (nur registrierte Kunden), bei der Sprache erkannt wird, bzw. die Erhöhung der vad-Zeit-Werte (nur registrierte Kunden) auf dem Gateway kann das Zischen bzw. Clipping weniger auffällig werden, ohne dass VAD dauerhaft deaktiviert werden muss. Diese Techniken deaktivieren VAD bei niedrigen Lautstärken bzw. bei kleinen Lücken. Es ist nicht praktikabel, Komfortgeräusche einfach zu deaktivieren, da diese Aktion andere Symptome der Sprachqualität verursacht, wie Klicken und/oder Lücken der absoluten Stille zwischen den Sätzen.
Weitere Informationen finden Sie unter Fehlerbehebung bei "Hissing" und "Static". Wenn diese Optimierungstechniken das Problem nicht lösen, deaktivieren Sie VAD. Dies führt zu einem Verlust an Bandbreiteneinsparungen.
Beheben von Problemen beim Zuschneiden und Zuschneiden in eine Richtung
VAD ist die Ursache für die meisten Probleme beim Zischen. Daher muss ermittelt werden, ob die Funktion aktiviert ist. Einer der ersten Schritte bei der Fehlerbehebung beim Abschneiden oder Abschneiden von Sätzen am Front-End ist die Deaktivierung von VAD. Daher ist es wichtig, feststellen zu können, ob sie deaktiviert ist.
Wenn ein Zischen oder Clipping nur in eine Richtung (die ausgehende Richtung) auftritt, kann dies darauf zurückzuführen sein, dass VAD in dieser Richtung aktiviert ist, obwohl Sie versucht haben, es im VoIP-Dial-Peer zu deaktivieren. In diesem Fall zeigt der Befehl show call active voice die aktivierte VAD an, und die verwendete Peer-ID ist 0. Um dieses Problem zu beheben, konfigurieren Sie den Befehl incoming called-number <Nummer_gewählt> (nur registrierte Kunden) auf dem VoIP-DFÜ-Peer, um sicherzustellen, dass Anrufe an das PSTN mit diesem Peer am Gateway übereinstimmen. Andernfalls stimmen Anrufe in dieser Richtung mit dem Standard-Dial-Peer überein, für den VAD standardmäßig aktiviert ist.
Diese Parameter sind wichtig für die Fehlerbehebung von echo:
ACOMLevel=20
OutSignalLevel=-64
InSignalLevel=-58
ERL-Pegel = 20
Die Testtonausgabe beträgt -15 und wird mit 0 dB Verlust zurückgeschleift. Daher liegt er bei -15 dB. Der ERL-Wert hat hier keine Bedeutung, da der Echokompensator das Eingangssignal nicht als Echo betrachtet.
Hinweis: Der OutSignalLevel gibt den Wert des Pegels an, nachdem die Ausgangsdämpfung auf das Signal angewendet wurde. InSignalLevel gibt den Wert des Pegels 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 Sprechersignals). Dies veranlasst die Echokompensation dazu, sie als Sprache (Doppelnutzen) anstatt als Echo zu betrachten. Daher wird das Echo durch die Echokompensation nicht aufgehoben. Die Echokompensation muss zwischen 6 dB und 20 dB erfolgen, damit die Echokompensation aktiviert wird.
Informationen zur Behebung von Echo-Problemen finden Sie unter Problembehandlung bei Echo-Signalen zwischen IP-Telefonen und Cisco IOS Gateways und unter Problembehandlung bei Echo in IP-Telefonienetzwerken (Audio on Demand).
In diesem Abschnitt wird erläutert, wie Sie mit dem Befehl show call active voice Jitter und typische Symptome der Sprachqualität identifizieren.
Eine allgemeine Vorstellung von Jitter im Netzwerk kann ermittelt werden, indem der Befehl show call active voice wiederholt ausgegeben wird, während ein Anruf ausgeführt wird. Im Idealfall sollten diese Parameter relativ stabil bleiben. Wenn dies der Fall ist, weist dies auf einen reibungslosen Paketfluss hin. Wenn jedoch Jitter vorliegt, treten kurze, steile Spitzen auf, wie sie in den beiden folgenden Beispielausgängen dargestellt 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 zunehmende Anzahl an verspäteten Paketen in diesen Sample-Ausgängen offenbart einen Grad an Jitter. Die durch eine Erhöhung des GapFillWithSilence-Werts angezeigte Silence-Einfügung manifestiert sich als abgehackte Stimme. Die prädiktive Einfügung, die durch eine Erhöhung des GapFillWithPrediction-Werts angezeigt wird, neigt dazu, sich als synthetische Stimme zu manifestieren.
Um die Menge des gepufferten Sprachsignals zu ändern und Jitter-Buffer-Unter- oder -Überläufe zu vermeiden, geben Sie den Befehl playout-delay (Wiedergabeverzögerung) ein.
Die beiden Konfigurationsmodi für die Wiedergabeverzögerung sind adaptiv und fest:
Mit Adaptive kann der Jitter-Puffer während der Dauer des Anrufs innerhalb eines konfigurierten Bereichs vergrößert und verkleinert werden, wenn Sie die Wiedergabeverzögerung {Nennwert | Höchstwert | minimum {default | Gering | hoch}} Befehl.
Behoben wird zu Beginn eines Gesprächs gesetzt, wenn Sie den Wiedergabeverzögerungsmodus {adaptive | fester [keine Zeitstempel]} Befehl.
Weitere Informationen zu VoIP finden Sie unter Verbesserungen der Playout-Verzögerung.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
18-Sep-2013 |
Erstveröffentlichung |