Fehlerbehebung und Debuggen von VoIP-Anrufen

Einleitung

In diesem Dokument werden die grundlegenden Techniken und Befehle zum Beheben und Debuggen von VoIP-Netzwerken beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• VoIP-Konfiguration

• Sprach-QoS

• Design und Bereitstellung von VoIP-Netzwerken

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. Die angezeigten Ergebnisse basieren jedoch auf der Cisco IOS® Software-Version 12.3(8).

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 Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konventionen

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

Hintergrundinformationen

Dieses Dokument zeigt grundlegende Techniken und Befehle zur Fehlerbehebung und -suche in VoIP-Netzwerken. Es wird ein Überblick über den Sprachanrufverlauf und die Telefoniearchitektur in einem Cisco Router gegeben, gefolgt von einem Schritt-für-Schritt-Ansatz zur VoIP-Fehlerbehebung, der in diesen Schritten vorgestellt wird:

1. Überprüfen Sie die digitale und analoge Signalisierung.

2. Überprüfen Sie die Ziffern, die von den analogen und digitalen Sprach-Ports empfangen und gesendet wurden.

3. Überprüfen der End-to-End-VoIP-Signalisierung

4. Probleme mit der VoIP-QoS (Quality of Service) verstehen

5. Details zu Ursachencodes und Debugwerten für VoIP verstehen

Anmerkung: In diesem Dokument werden nicht alle Aspekte der Cisco IOS-Architektur erläutert, die in Cisco VoIP-Gateways und -Gatekeepern verwendet werden. Stattdessen soll gezeigt werden, welche Befehle verwendet werden können und welche Felder aus den Befehlsausgaben am wertvollsten sein können.

Vorsicht: Das Debuggen von Cisco IOS ist prozessorintensiv. Seien Sie vorsichtig, wenn Sie die in diesem Dokument aufgeführten Debugs verwenden. Weitere Informationen finden Sie unter Wichtige Informationen zu Debugbefehlen.

Debugs müssen mit Zeitstempeln ausgeführt werden, die im Protokoll aktiviert sind. Aktivieren Sie Zeitstempel mit den Befehlen: service timestamps debug datetime msec, service timestampslog datetime msec im privilegierten Modus.

Die Zeitstempel helfen dabei, das Zeitintervall zwischen Zustandsänderungen zu bestimmen.

Anrufablauf im Netzwerk

Bevor Sie mit der Fehlerbehebung oder Fehlerbehebung für VoIP beginnen, sollten Sie unbedingt beachten, dass VoIP-Anrufe aus drei Anrufabschnitten bestehen. Bei diesen Anrufabschnitten handelt es sich um Quelldienste für Plain Old Telefone Systems (POTS), VoIP und Ziel-POTS.

Die Fehlerbehebung und das Debugging müssen sich zunächst auf die einzelnen Levels und dann auf den VoIP-Anruf als Ganzes konzentrieren.

Anrufablauf des Routers

Diese Definitionen erläutern die Funktion der Hauptkomponenten, die im Anrufflussdiagramm des Routers angezeigt werden:

Anrufsteuerungs-API (Application Programming Interface) - Drei Clients verwenden die Anrufsteuerungs-API. Die drei Clients sind CLI, Simple Network Management Protocol (SNMP)-Agent und die Sitzungsanwendung. Die Hauptfunktionen der Anrufsteuerungs-API (auch CCAPI genannt) sind:

• Identifizieren Sie die Anrufabschnitte (z. B. welchen DFÜ-Peer handelt es sich? woher kam es?).

• Entscheiden Sie, welche Sitzungsanwendung den Anruf entgegennimmt (z. B. wer kümmert sich darum?).

• Rufen Sie den Pakethandler auf.

• Führen Sie alle erforderlichen Schritte gemeinsam durch.

• Starten der Aufzeichnung der Anrufstatistik

Sitzungsanwendung und Wählplanzuordnung - Die Sitzungsanwendung verwendet die Wählplanzuordnung, um einem Dial-Peer (lokaler POTS oder Remote-VoIP) eine Nummer zuzuordnen.

Die Wählplanzuordnung sucht mithilfe der DFÜ-Peer-Tabelle nach aktiven DFÜ-Peers.

Telefonie und VoIP Service Provider Interface (SPI) - Der Telefonie-SPI kommuniziert mit dem POTS (analog: fxo, fxo, e&m Digital: isdn, qsig, e&m usw.) Dial-Peers.

Der VoIP-SPI ist die spezifische Schnittstelle zu den VoIP-Peers. Telefonie-/DSP-Treiber stellen Dienste für den Telefonie-SPI bereit, während der VoIP-SPI auf Sitzungsprotokollen beruht.

Architektur der Telefonieschnittstelle

Dieses Diagramm zeigt die Architektur der Telefonie-Bausteine des Cisco Routers und ihre Interaktion untereinander.

Diese Liste beschreibt die Funktionen und Definitionen der Hauptdiagrammkomponenten:

• CCAPI (Call Control Application Programming Interface) - Softwareeinheit, die Anrufabschnitte erstellt, terminiert und überbrückt.

• Voice Telefony Service Provider (VTSP) - Ein Cisco IOS-Prozess, der Anforderungen von der Anrufsteuerungs-API bedient und die entsprechenden Anforderungen an den digitalen Signalprozessor (DSP) oder das VPM formuliert.

• Voice Processor Module (VPM) - Das VPM überbrückt und koordiniert Signalisierungsprozesse zwischen den Telefonie-Ports des Signaling State Machine (SSM), dem DSP Resource Manager und dem VTSP.

• DSP Resource Manager - Das DSPRM stellt Schnittstellen bereit, über die der VTSP Nachrichten an die DSPs senden und von ihnen empfangen kann.

• Packet Handler - Der Packet Handler leitet Pakete zwischen den DSPs und den Peer Call-Abschnitten weiter.

• Call Peer - Der Call Peer ist die entgegengesetzte Anrufstrecke. Dies kann eine andere Telefonie-Sprachverbindung (POTS), VoFR, VoATM oder eine VoIP-Verbindung sein.

Überprüfen der digitalen und analogen Signalisierung (POTS-Anrufweiterleitung)

Für die Überprüfung der digitalen und analogen Signalisierung ist Folgendes erforderlich:

• Prüfen Sie, ob die richtige analoge oder digitale Signalisierung bei aufgelegtem und abgehobenem Hörer empfangen wird.

• Prüfen Sie, ob die richtige E&M-, FXO- und FXS-Signalisierung sowohl auf dem Router als auch auf dem Switch (CO oder PBX) konfiguriert ist.

• Überprüfen Sie, ob sich die DSPs im Ziffernsammelmodus befinden.

Die in diesen Abschnitten beschriebenen Befehle können zum Überprüfen der Signalisierung verwendet werden.

Show-Controller T1 / E1 (digital)

show controllers t1 [slot/port] (Controller t1 anzeigen [Steckplatz/Port]): Verwenden Sie zuerst diesen Befehl. Es wird angezeigt, ob die digitale T1-Verbindung zwischen Router und Switch (CO oder PBX) aktiv oder inaktiv ist und ob sie ordnungsgemäß funktioniert. Die Ausgabe dieses Befehls sieht wie folgt aus:

router# show controllers T1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is Line
Primary.
Data in current interval (6 seconds elapsed):

	0 Line Code Violations, 0 Path Code Violations
	0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 
  0 Degraded Mins
	0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
  0 Unavail Secs

Wenn Sie E1 verwenden, verwenden Sie den Befehl show controllers e1. Weitere Informationen finden Sie unter:

• T1 Layer 1 - Fehlerbehebung

• T1 Fehlerbehebung - Flussdiagramm

• Fehlerbehebung bei Problemen mit seriellen Leitungen

Sprachport anzeigen

show voice portsSteckplatznummer/Port - Mit diesem Befehl können Sie den Port-Status und die am Sprach-Port der Cisco Voice Interface Cards (VIC) konfigurierten Parameter anzeigen. Wie alle Cisco IOS-Befehle werden die Standardeinstellungen nicht in show running-config angezeigt, sondern mit diesem Befehl.

Dies ist eine Beispielausgabe für einen E&M-Sprach-Port:

router# show voice port 1/0:1
recEive and transMit Slot is 1, Sub-unit is 0, Port is 1
Type of VoicePort is E&M 
Operation State is DORMANT
Administrative State is UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Music On Hold Threshold is Set to -38 dBm
In Gain is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal (could be trunk or plar)
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Signal Type is wink-start
Operation Type is 2-wire
E&M Type is 1
Dial Type is dtmf
In Seizure is inactive
Out Seizure is inactive
Digit Duration Timing is set to 100 ms

InterDigit Duration Timing is set to 100 ms
Pulse Rate Timing is set to 10 pulses/second
InterDigit Pulse Duration Timing is set to 500 ms
Clear Wait Duration Timing is set to 400 ms
Wink Wait Duration Timing is set to 200 ms
Wink Duration Timing is set to 200 ms
Delay Start Timing is set to 300 ms
Delay Duration Timing is set to 2000 ms
Dial Pulse Min. Delay is set to 140 ms

debug vpm (Sprachprozessormodul)

Die folgenden Befehle werden zum Debuggen der VPM-Telefonieschnittstelle verwendet:

• debug vpm signal - Dieser Befehl dient zum Sammeln von Debuginformationen für Signalisierungsereignisse und kann beim Lösen von Signalisierungsproblemen an ein PBX hilfreich sein.

• debug vpm spi - Dieser Befehl verfolgt, wie die Sprachport-Modul-Service Provider-Schnittstelle (SPI) mit der Anrufsteuerungs-API interagiert. Dieser Debug-Befehl zeigt Informationen über die Behandlung der einzelnen Netzwerkindikationen und Anwendungsanforderungen an.

• debug vpm dsp - Dieser Befehl zeigt Meldungen des DSP auf dem VPM an den Router an und kann nützlich sein, wenn Sie vermuten, dass das VPM nicht funktioniert. Es ist eine einfache Möglichkeit, zu überprüfen, ob das VPM auf Off-Hook-Anzeigen reagiert, und das Timing für Signalisierungsnachrichten von der Schnittstelle auszuwerten.

• debug vpm all - Dieser EXEC-Befehl aktiviert alle debug vpm-Befehle: debug vpm spi, debug vpm signal und debug vpm dsp.

• debug vpm port - Verwenden Sie diesen Befehl, um die Debug-Ausgabe auf einen bestimmten Port zu beschränken. Diese Ausgabe zeigt beispielsweise debug vpm dspmessages only for port 1/0/0:

debug vpm dsp 

debug vpm port 1/0/0 

Beispielausgabe für debug vpm signalCommand

maui-voip-austin#debug vpm signal


!--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state.

htsp_process_event: [1/0/0, 1.2 , 36] 
fxsls_onhook_offhook htsp_setup_ind
*Mar 10 16:08:55.958: htsp_process_event: 
[1/0/0, 1.3 , 8] 


!--- Sends ringing alert to the called phone.

*Mar 10 16:09:02.410: htsp_process_event: 
[1/0/0, 1.3 , 10] htsp_alert_notify
*Mar 10 16:09:03.378: htsp_process_event: 
[1/0/0, 1.3 , 11] 


!--- End of phone call, port goes "on-hook".

*Mar 10 16:09:11.966: htsp_process_event: 
[1/0/0, 1.3 , 6] 
*Mar 10 16:09:17.218: htsp_process_event: 
[1/0/0, 1.3 , 28] fxsls_offhook_onhook
*Mar 10 16:09:17.370: htsp_process_event: 
[1/0/0, 1.3 , 41] fxsls_offhook_timer
*Mar 10 16:09:17.382: htsp_process_event: 
[1/0/0, 1.2 , 7] fxsls_onhook_release

Wenn die Signale bei aufgelegtem und abgehobenem Hörer nicht richtig ausgegeben werden, überprüfen Sie folgende Punkte:

• Überprüfen Sie die korrekte Verkabelung.

• Prüfen Sie, ob Router und Switch (CO oder PBX) ordnungsgemäß geerdet sind.

• Stellen Sie sicher, dass beide Enden der Verbindung über äquivalente Signalisierungskonfigurationen verfügen. Nicht übereinstimmende Konfigurationen können eine unvollständige oder unidirektionale Signalisierung verursachen.

Weitere Informationen zur Fehlerbehebung bei E&M finden Sie unter Verstehen und Beheben von Problemen bei analogen E&M-Schnittstellentypen und Verkabelungsanordnungen.

Beispielausgabe für debug vpm spiCommand

maui-voip-austin#debug vpm spi   
Voice Port Module Session debugging is enabled


!--- The DSP is put into digit collection mode.

*Mar 10 16:48:55.710: dsp_digit_collect_on: 
[1/0/0] packet_len=20 channel_id=128
 packet_id=35 min_inter_delay=290 
 max_inter_delay=3200 mim_make_time=18 max_make
_time=75 min_brake_time=18 max_brake_time=75

Überprüft empfangene und gesendete Ziffern (POTS-Rufzeichen)

Wenn die Signale bei aufgelegtem und abgehobenem Hörer verifiziert wurden und richtig funktionieren, überprüfen Sie, ob die richtigen Ziffern am Sprach-Port empfangen oder gesendet werden (digital oder analog).

Ein Dial-Peer wurde nicht zugeordnet, oder der Switch (CO oder PBX) kann den richtigen Sender nicht anrufen, wenn unvollständige oder falsche Ziffern gesendet oder empfangen werden.

Die folgenden Befehle können verwendet werden, um die empfangenen/gesendeten Ziffern zu überprüfen:

• show dialplan number - Mit diesem Befehl wird angezeigt, welcher DFÜ-Peer beim Wählen einer bestimmten Telefonnummer erreicht wird.

• debug vtsp session - Mit diesem Befehl werden Informationen zur Verarbeitung der einzelnen Netzwerkindikationen und Anwendungsanforderungen, Signalisierungsindikatoren und DSP-Kontrollmeldungen angezeigt.

• debug vtsp dsp - Vor Version 12.3 der Cisco IOS-Software zeigt dieser Befehl die Ziffern an, die vom Sprach-Port empfangen werden.

In Version 12.3 und höher der Cisco IOS-Software werden die Ziffern in der Ausgabe des Befehls debug nicht mehr angezeigt. Die Kombination aus debug hpi detail und debug hpinotification kann verwendet werden, um die eingehenden Ziffern anzuzeigen.

• debug vtsp all - Mit diesem Befehl können Sie die folgenden Befehle für den Sprach-Telefonie-Service Provider (VTSP) debuggen: debug vtsp session, debug vtsp error und debug vtsp dsp.

Wählplannummer anzeigen

show dialplan number <digit_string> - Mit diesem Befehl wird der Dial-Peer angezeigt, dem eine Zeichenfolge entspricht. Wenn mehrere DFÜ-Peers zugeordnet werden können, werden sie alle in der Reihenfolge angezeigt, in der sie zugeordnet werden.

Anmerkung: Sie müssen das #-Zeichen am Ende der Telefonnummern für DFÜ-Peers mit variabler Länge verwenden, um Zielmuster zu erkennen, die mit T enden.

Die Ausgabe dieses Befehls sieht wie folgt aus:

maui-voip-austin#show dialplan number 5000
Dial string terminator: #
Macro Exp.: 5000

VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation
        state is up,
        incoming called-number = `', 
        connections/maximum = 0/unlimited,
        application associated: 
        type = voip, session-target = 
        `ipv4:192.168.10.2',
        technology prefix: 
        ip precedence = 5, UDP checksum = 
        disabled, session-protocol = cisco, 
        req-qos = best-effort, 
        acc-qos = best-effort, 
        dtmf-relay = cisco-rtp, 
        fax-rate = voice,   
        payload size =  20 bytes
        codec = g729r8,   
        payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,
        signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 25630, Charged Units = 0,
        Successful Calls = 25, Failed Calls = 0,
        Accepted Calls = 25, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call 
        clearing.",
        Last Setup Time = 84427934.
        Matched: 5000   Digits: 4
        Target: ipv4:192.168.10.2

debuggen vtsp-Sitzung

Der Befehl debug vtsp session zeigt Informationen über die Interaktion des Routers mit dem DSP an, basierend auf den Signalisierungsangaben aus dem Signalisierungs-Stack und den Anforderungen der Anwendung.

Dieser Befehl debug zeigt Informationen über die Behandlung der einzelnen Netzwerkindikationen und Anwendungsanforderungen, Signalisierungshinweise und DSP-Kontrollmeldungen an.

maui-voip-austin#debug vtsp session 
Voice telephony call control session debugging is on


!--- Output is suppressed. 
!--- ACTION: Caller picked up handset. 
!--- The DSP is allocated, jitter buffers, VAD 
!--- thresholds, and signal levels are set.


*Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)]
packet_len=18 channel_id=1 packet_id=76 mode=1 
initial=60 min=4 max=200 fax_nom=300
*Mar 10 18:14:22.865: dsp_echo_canceller_control: 
[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66
flags=0x0
*Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)] 
packet_len=12 channel_id=1 packet_id=91 
in_gain=0 out_gain=65506
*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)] 
packet_len=10 channel_id=1 packet_id=78 
thresh=-38act_setup_ind_ack 
*Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)] 
packet_len=24 channel_id=1 packet_id=73 coding_type=1
 voice_field_size=80 
VAD_flag=0 echo_length=64 comfort_noise=1 
inband_detect=1 digit_relay=2 
AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mod
e()act_setup_ind_ack: passthru_mode = 0, 
no_auto_switchover = 0dsp_dtmf_mode
(VTSP_TONE_DTMF_MODE)


!--- The DSP is put into "voice mode" and dial-tone is 
!--- generated.


*Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)] 
packet_len=30 channel_id=1 packet_id=72 tone_id=4 
n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=
4000 amp_of_second=4000 direction=1 on_time_first=65535 
off_time_first=0 on_time
_second=65535 off_time_second=0

Wenn festgestellt wird, dass die Ziffern nicht richtig gesendet oder empfangen werden, kann es erforderlich sein, entweder einen Digit-Grabber (Testwerkzeug) oder einen T1-Tester zu verwenden, um zu überprüfen, ob die Ziffern mit der richtigen Frequenz und dem richtigen Zeitintervall gesendet werden.

Wenn sie für den Switch "falsch" gesendet werden (CO oder PBX), müssen möglicherweise einige Werte auf dem Router oder Switch (CO oder PBX) angepasst werden, damit sie übereinstimmen und interagieren können.

Dabei handelt es sich in der Regel um Werte für die Zifferndauer und die Interdigit-Dauer. Ein weiterer Punkt, bei dem geprüft werden muss, ob die Ziffern korrekt gesendet wurden, sind alle Nummernumwandlungstabellen im Switch (CO oder PBX), die Ziffern hinzufügen oder entfernen können.

Überprüfen der End-to-End-VoIP-Signalisierung (VOIP-Anrufstrecke)

Nachdem Sie sichergestellt haben, dass die Sprach-Port-Signalisierung ordnungsgemäß funktioniert und die richtigen Ziffern empfangen wurden, fahren Sie mit der Fehlerbehebung und Fehlerbehebung für die VoIP-Anrufsteuerung fort. Diese Faktoren erklären, warum das Debuggen der Anrufsteuerung zu einer komplexen Aufgabe werden kann:

• Cisco VoIP-Gateways nutzen die H.323-Signalisierung, um Anrufe abzuschließen. H.323 besteht aus drei Ebenen der Anrufverhandlung und -einrichtung: H.225, H.245 und H.323. Diese Protokolle verwenden eine Kombination aus TCP und UDP, um einen Anruf einzurichten und einzurichten.

• Das End-to-End-VoIP-Debugging zeigt eine Reihe von Cisco IOS-Statussystemen. Probleme mit Statuscomputern können dazu führen, dass ein Anruf fehlschlägt.

• End-to-End VoIP-Debugging kann sehr ausführlich sein und eine Menge Debug-Ausgabe erzeugen.

debuggen voip ccapi inout

Der primäre Befehl zum Debuggen von End-to-End-VoIP-Anrufen ist debug voip ccapi inout . In dieser Ausgabe wird die Ausgabe eines Aufrufdebugs angezeigt.

!--- Action: A VoIP call is originated through the 
!--- Telephony SPI (pots leg) to extension 5000. 
!--- Some output is omitted.


maui-voip-austin#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on


!--- Call leg identification, source peer: Call 
!--- originated from dial-peer 1 pots 
!--- (extension 4000).


*Mar 15 22:07:11.959: cc_api_call_setup_ind 
(vdbPtr=0x81B09EFC, callInfo={called=, 
calling=4000, fdest=0 peer_tag=1}, callID=0x81B628F0)

!--- CCAPI invokes the session application.


*Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"
*Mar 15 22:07:11.963: sess_appl: 
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)


!--- Allocate call leg identifiers "callid = 0x59"


*Mar 15 22:07:11.963: ccCallSetContext 
(callID=0x58, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck 
(callID=0x58)


!--- Instruct VTSP to generate dialtone
. 

*Mar 15 22:07:11.963: ccGenerateTone 
(callID=0x58 tone=8)


!--- VTSP passes digits to CCAPI.


*Mar 15 22:07:20.275:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:20.279: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:20.279: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:20.279: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:20.327: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=5
, duration=100)
*Mar 15 22:07:20.327: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:20.327: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.975:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:21.979: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:21.979: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.979: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:22.075: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:22.079: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:22.079: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.235: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, dgit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:23.239: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:23.239: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.239: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:23.335: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:23.339: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:23.339: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:25.147: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, d
igit=0, flags=0x1, timestamp=0xC2E63BB7, 
expiration=0x0)
*Mar 15 22:07:25.147: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:25.147: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:25.147: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:25.255: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=160)
*Mar 15 22:07:25.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:25.259: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)


!--- Matched dial-peer 2 voip. Destination number !--- 5000


*Mar 15 22:07:25.259: ssaSetupPeer cid(88) 
peer list:tag(2) called number(5000) 
*Mar 15 22:07:25.259: ssaSetupPeer cid(88), 
destPat(5000), matched(4), prefix(),
peer(81C04A10)


!--- Continue to call an interface and start the !--- next call leg.


*Mar 15 22:07:25.259: ccCallProceeding 
(callID=0x58, prog_ind=0x0)
*Mar 15 22:07:25.259: ccCallSetupRequest 
(Inbound call = 0x58, outbound peer =2,
dest=, params=0x81BAF168 mode=0, 
*callID=0x81B6DE58)
*Mar 15 22:07:25.259: callingNumber=4000, 
calledNumber=5000, redirectNumber=


!--- VoIP call setup.


*Mar 15 22:07:25.263: ccIFCallSetupRequest:
(vdbPtr=0x81A75558, dest=, 
callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}, mode=0x0)
*Mar 15 22:07:25.263: ccCallSetContext 
(callID=0x59, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert 
(callID=0x58, prog_ind=0x8, sig_ind=0x1)


!--- POTS and VoIP call legs are tied together.


*Mar 15 22:07:25.375: ccConferenceCreate 
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)
*Mar 15 22:07:25.375: cc_api_bridge_done 
(confID=0x1E, srcIF=0x81B09EFC, srcCall
ID=0x58, dstCallID=0x59, disposition=0, 
tag=0x0)


!--- Exchange capability bitmasks with remote 
!--- the VoIP gateway 
!--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth).


*Mar 15 22:07:26.127: cc_api_caps_ind 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59,caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20, 
signal_type=0})


!--- Both gateways agree on capabilities.

*Mar 15 22:07:26.127: cc_api_caps_ack 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59, caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:26.139: cc_api_caps_ack 
(dstVdbPtr=0x81A75558, dstCallId=0x59, src
CallId=0x58, caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:35.259: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=T
, duration=0)
*Mar 15 22:07:35.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:35.259: ssaTraceSct: 
cid(88)st(4)oldst(3)cfid(30)csize(0)in(1)
fDest(0)-cid2(89)st2(4)oldst2(1)
*Mar 15 22:07:35.399: cc_api_call_connected
(vdbPtr=0x81A75558, callID=0x59)
*Mar 15 22:07:35.399: sess_appl: 
ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0)
*Mar 15 22:07:35.399: ssaTraceSct: 
cid(89)st(4)oldst(1)cfid(30)csize(0)in(0)
fDest(0)-cid2(88)st2(4)oldst2(4)


!--- VoIP call is connected.


*Mar 15 22:07:35.399: ccCallConnect 
(callID=0x58)


!--- VoIP call is disconnected. Cause = 0x10
 

*Mar 15 23:29:39.530: ccCallDisconnect 
(callID=0x5B, cause=0x10 tag=0x0)

Wenn der Anruf fehlschlägt und die Ursache im VoIP-Bereich der Anrufeinrichtung liegt, müssen Sie möglicherweise den H.225- oder H.245-TCP-Bereich der Anrufeinrichtung betrachten, im Gegensatz zum UDP-Bereich der H.323-Einrichtung.

Die folgenden Befehle können zum Debuggen der H.225- oder H.245-Anrufeinrichtung verwendet werden:

• debug ip tcp transactions and debug ip tcp packet: Diese Befehle untersuchen den TCP-Teil der H.225- und H.245-Aushandlung. Sie geben die IP-Adressen, TCP-Ports und den Status der TCP-Verbindungen zurück.

• debug cch323 h225 - Dieser Befehl untersucht den H.225-Teil der Anrufaushandlung und verfolgt den Zustandsübergang des H.225-Zustandsmaschinensystems auf Basis des verarbeiteten Ereignisses. Stellen Sie sich dies als Layer-1-Komponente der dreiteiligen H.323-Anrufkonfiguration vor.

• debug cch323 h245 - Dieser Befehl untersucht den H.245-Teil der Anrufaushandlung und verfolgt den Zustandsübergang des H.245-Zustandsmaschinensystems auf Basis der verarbeiteten Ereignisse. Stellen Sie sich dies als Layer-2-Komponente der dreiteiligen H.323-Anrufkonfiguration vor.

Probleme mit der VoIP-QoS (Quality of Service)

Wenn VoIP-Anrufe richtig eingerichtet wurden, besteht der nächste Schritt darin, die gute Sprachqualität zu überprüfen.

QoS-Fehlerbehebung wird in diesem Dokument nicht behandelt. Um eine gute Sprachqualität zu erreichen, müssen jedoch die folgenden Richtlinien beachtet werden:

• Sie sollten wissen, wie viel Bandbreite ein VoIP-Anruf mit jedem Codec beansprucht. Dies umfasst Layer-2- und IP/UDP/RTP-Header. Weitere Informationen finden Sie unter Modify Bandwidth Consumption Calculation for Voice Calls.

• Erfassen der Merkmale des IP-Netzwerks, über das die Anrufe übertragen werden Beispielsweise ist die Bandbreite eines Frame-Relay-Netzwerks bei CIR sehr viel anders als die Bandbreite oberhalb von CIR (oder Burst), bei der Pakete verworfen oder in der Frame-Relay-Cloud in die Warteschlange gestellt werden können. Stellen Sie sicher, dass Verzögerungen und Jitter so weit wie möglich kontrolliert und eliminiert werden. Die unidirektionale Übertragungsverzögerung darf 150 ms nicht überschreiten (gemäß G.114-Empfehlung).

• Verwenden Sie eine Warteschlangenmethode, mit der VoIP-Datenverkehr identifiziert und priorisiert werden kann.

• Wenn Sie VoIP über langsame Verbindungen übertragen, sollten Sie Layer-2-Paketfragmentierungstechniken wie MLPPP mit Link Fragmentation and Interleaving (LFI) auf Point-to-Point-Verbindungen oder FRF.12 auf Frame-Relay-Verbindungen verwenden. Die Fragmentierung größerer Datenpakete ermöglicht einen geringeren Jitter und geringere Verzögerungen bei der Übertragung von VoIP-Datenverkehr, da die VoIP-Pakete auf der Verbindung ineinander verschachtelt werden können.

• Versuchen Sie, einen anderen Codec zu verwenden, und versuchen Sie, den Anruf mit aktivierter und deaktivierter VAD zu tätigen, um das Problem möglicherweise auf den DSP einzugrenzen, im Gegensatz zum IP-Netzwerk.

Bei VoIP sind die wichtigsten Aspekte bei der Fehlerbehebung von QoS-Problemen verlorene Pakete und Netzwerkengpässe, die Verzögerungen und Jitter verursachen können.

Suchen nach:

• Schnittstellen-Drops

• Pufferverluste

• Überlastung der Schnittstelle

• Verbindungsstau

Jede Schnittstelle im Pfad des VoIP-Gesprächs muss überprüft werden. Vermeiden Sie außerdem Versäumnisse und Staus. Außerdem muss die Round-Trip-Verzögerung so weit wie möglich reduziert werden.

Pings zwischen den VoIP-Endpunkten geben einen Hinweis auf die Round-Trip-Verzögerung einer Verbindung. Die Round-Trip-Verzögerung darf, wenn möglich, 300 ms nicht überschreiten.

Wenn die Verzögerung diesen Wert nicht überschreiten muss, müssen Anstrengungen unternommen werden, um sicherzustellen, dass diese Verzögerung konstant ist, damit kein Jitter oder eine variable Verzögerung entsteht.

Außerdem muss sichergestellt werden, dass die VoIP-Pakete mithilfe des Cisco IOS-Warteschlangenmechanismus in die richtigen Warteschlangen gestellt werden. Cisco IOS-Befehle wie show queue interface oder show priority können bei der Überprüfung der Warteschlange helfen.

Details zu Ursachencodes und Fehlerbehebungswerten für VoIP

Verwenden Sie diese Tabellen, wenn Sie Debugs und die zugehörigen Werte innerhalb der Debugs lesen.

Q.931 Ursachen für Verbindungstrennung (Cause_codes vom debug voip ccapi inout)

¹Dieses Problem kann aufgrund einer Codec-Diskrepanz innerhalb der H323-Konfiguration auftreten. Der erste Schritt zur Fehlerbehebung besteht daher darin, die VoIP-DFÜ-Peers fest zu codieren, um den richtigen Codec zu verwenden.

Codec-Verhandlungswerte (aus debug voip ccapi inout)

Weitere Informationen zu CODECs finden Sie unter Understanding Codecs: Komplexität, Hardware-Unterstützung, MOS und Verhandlung.

Tonarten

FAX-Rate- und VAD-Funktionswerte

Zugehörige Informationen

• T1 Layer 1 - Fehlerbehebung
• T1 - Fehlerbehebung
• Fehlerbehebung bei Problemen mit seriellen Leitungen
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support und Downloads von Cisco