Fehlerbehebung bei Anrufausfällen auf TC-Endpunkten, die beim Cisco CallManager registriert sind

Einleitung

In diesem Dokument werden einige häufige Probleme bei Anruffehlern bei Tandberg Codec (TC)-Endgeräten erläutert, die für Cisco CallManager registriert sind, sowie Lösungsvorschläge.

Voraussetzungen

Anforderungen

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

Erfassen von H.323-Debug-Protokollen

Anmerkung: Stellen Sie sicher, dass die Ausgabe der Secure Socket Host (SSH)-Sitzung erfasst wird.

1. SSH in die Codec-CLI ein, und geben Sie die folgenden Befehle ein:
   • log ctx H.323Paketdebug 9
   • Protokollausgabe ein (Dadurch werden alle Protokolle in den Terminalbildschirm der SSH-Sitzung ausgegeben.)
2. Starten Sie einen Anruf, und erstellen Sie das Problem neu.
3. Geben Sie die Protokollausgabe aus und protokollieren Sie ctx H.323Packet debug off-Befehle.

Erfassen von SIP-Debug-Protokollen (Session Initiation Protocol)

Anmerkung: Stellen Sie sicher, dass die Ausgabe der SSH-Sitzung erfasst wird.

1. SSH in die Codec-CLI ein, und geben Sie die folgenden Befehle ein:
   • log ctx SIPPacket debug 9
   • Protokollausgabe ein (Dadurch werden alle Protokolle in den Terminalbildschirm der SSH-Sitzung ausgegeben.)
2. Starten Sie einen Anruf, und erstellen Sie das Problem neu.
3. Geben Sie die Protokollausgabe ein und protokollieren Sie ctx SIPPacket debug off-Befehle.

Sammeln von Paketerfassungs-/Endpunktprotokollen von TC-Endpunkten

1. Wählen Sie in der Web-GUI Diagnostics > Log files (Diagnose > Protokolldateien) aus, und aktivieren Sie die erweiterte Protokollierung mit voller Paketerfassung.
2. Starten Sie einen Anruf, und erstellen Sie das Problem neu. Beachten Sie, dass die Paketerfassung nur für 3 Minuten aktiviert werden kann.
3. Wählen Sie in der Web-GUI Diagnostics > Log files (Diagnose > Protokolldateien) aus, und laden Sie das gesamte Protokollarchiv und die Paketerfassung herunter.

Weitere Informationen erforderlich

• Vollständiger Anruffluss für alle beteiligten Geräte
• Angerufene und anrufende Nummer
• Datum und Uhrzeit des Problems

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.

Problem: Anruffehler aufgrund von CSS-/Partitionsproblemen (Call Search Space) im CallManager

Anrufe zwischen zwei Endpunkten, die beim Cisco Unified Communications Manager (CUCM) registriert sind, können aufgrund eines CSS-/Partitionsproblems im CUCM fehlschlagen.

Erfassen Sie die SIP-Protokolle des anrufenden Endpunkts. Diese Meldung "404 Not Found" (404 nicht gefunden) wird in den Endpunkt-SIP-Protokollen angezeigt, die vom CUCM stammen:

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

Lösung

Führen Sie diese Schritte aus, um den CSS des anrufenden Endpunkts und die Partition des angerufenen Endpunkts zu überprüfen. Stellen Sie sicher, dass der CSS des anrufenden Endpunkts über die Partition des angerufenen Endpunkts verfügt.

Sie können auf Geräte- und Postenebene einen CSS zuweisen:

1. Wählen Sie Device > Phone (Gerät > Telefon), wählen Sie den Endpunkt aus, klicken Sie auf die Leitung, und prüfen Sie den CSS (Calling Search Space) auf Postenebene. In diesem Beispiel wird auf Postenebene kein CSS konfiguriert. Wenn jedoch ein CSS auf Verzeichnisnummernebene vorhanden ist, muss eines der CSSs eine Partition der angerufenen Nummer haben:

   

2. Überprüfen Sie den auf Telefonebene zugewiesenen CSS. Wählen Sie Device > Phone (Gerät > Telefon) aus, und wählen Sie das entsprechende Anrufer-Endgerät aus:

   

3. Überprüfen Sie die Partition der angerufenen Nummer. Wählen Sie Device > Phone (Gerät > Telefon) aus, wählen Sie das angerufene Gerät aus, klicken Sie auf die Zeile, und überprüfen Sie die Route Partion:

   

4. Nachdem Sie Partiton und CSS auf beiden Endpunkten überprüft haben, überprüfen Sie, ob der CSS des anrufenden Geräts die Partition des angerufenen Geräts aufweist:

   

   Andernfalls könnte dies die Ursache für den Fehler "404 Not Found" sein.

Problem: SIP-Anrufunterbrechung nach 15 Minuten (oder nach einer bestimmten Zeit)

Im Allgemeinen werden Anrufunterbrechungen in bestimmten Zeitintervallen durch SIP-Timer oder TCP-Timeout verursacht, das auf Firewalls, Routern usw. konfiguriert wurde.

Lösung

Wenn der Anruf nach genau 15 Minuten getrennt wird, besteht das häufigste Problem darin, dass die im Netzwerk konfigurierte TCP-Zeitüberschreitung (Firewalls, Router) geringer ist als die Zeitüberschreitung für die SIP-Sitzung. Standardmäßig ist der SIP Session Expire Timer auf CallManager auf 1800 Sekunden festgelegt.

Um dies zu überprüfen, wählen Sie Cisco Unified CM Administration > System > Service Parameters > Cisco Call Manager Service > Look for - SIP Session Expires Timer.

Alle für CUCM registrierten Endpunkte verwenden diesen Timer. Wenn der Endpunkt mit einem anderen Remote-Endpunkt verbunden ist, muss eine der Parteien die Sitzung aktualisieren und eine Re-INVITE- oder UPDATE-Nachricht senden. Diese Aktualisierung muss vor der Hälfte des Timers "Sitzung läuft ab" gesendet werden (1800/2 = 900 Sekunden = 15 Minuten). Wenn keine Aktualisierungsnachricht empfangen wird, wird die Verbindung zum Anruf getrennt.

Überprüfen Sie, ob der Sitzungs-Timer in der ersten INVITE-Nachricht vorhanden ist. Vor Ablauf dieser Zeit sollte eine Aktualisierung (INVITE/UPDATE) eingehen:

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

Basierend auf der anfänglichen Aushandlung über den User Agent Client/User Agent Server (UAC/UAS) aktualisiert einer der Endpunkte die Sitzung beim Senden einer Re-INVITE-Nachricht. Wenn es sich bei dem Auffrischender um UAC handelt, ist der Initiator des Anrufs dafür verantwortlich, die Sitzung zu aktualisieren. Wenn es sich bei dem Auffrischender um UAS handelt, muss der Server die Sitzung aktualisieren. Sammeln Sie die SIP-Debug-Protokolle von beiden Endpunkten, und überprüfen Sie diese:

Beispiel: Anruf von Partei A an CUCM an Partei B. Wenn die Auffrischung UAC auf Partei A und UAS auf Partei B lautet:

1. Partei A muss die Re-INVITE/AKTUALISIERUNG an den CUCM senden.
2. CUCM muss eine Re-INVITE/UPDATE an Partei B senden.
3. Partei B erhält die Re-INVITE und antwortet mit einem OK von 200 auf diese Nachricht.
4. CUCM muss 200 OK an Partei A senden.

Wenn ein Endpunkt die Re-INVITE-Nachricht an den CUCM sendet, sendet der CUCM eine Re-INVITE-Nachricht an die andere Partei. Wenn diese jedoch nicht von der Außenstelle empfangen wird, kann dies auf einige Netzwerkgeräte zurückzuführen sein. Es ist sehr wahrscheinlich, dass die Re-INVITE/Antwort aufgrund von SIP-Prüfung oder Netzwerkeinstellungen nicht zu einer der Seiten gelangt.

Wenn die Endpunkte die Re-INVITE-Nachricht nicht initiieren, kann dies ein Problem mit dem Endpunkt sein. Nehmen Sie an Cisco Technical Assiance Center (TAC) teil, um weitere Informationen zu erhalten.

Problem: H.323-Anrufe werden nach einer bestimmten Zeit abgebrochen

Wie bei SIP treten bei H.323-Anrufen in einem bestimmten Zeitintervall Anrufe meist aufgrund der Netzwerk- oder Firewall-Timeout-Konfiguration auf.

Lösung

Bei H.323-Anrufen wird alle 30 Sekunden zwischen den Endpunkten eine RTDR-Nachricht (Round Trip Delay Request) mit Sequenznummern gesendet. Für jede Anforderung wird eine Antwort erwartet.

Cisco Endpoint verwendet die RTDR/Round Trip Delay Response-Nachricht, die Teil der H.245 Multimedia System Control Message ist. Dadurch wird die H.245-TCP-Sitzung während des Anrufs, der für die aktive Anrufverwaltung verwendet wird, aufrechterhalten. Wenn das Endgerät anfänglich eine Antwort für RTDR erhält und während des Anrufs keine Antwort empfangen wird, beendet das Endgerät den Anruf.

Sammeln Sie in diesem Szenario die H.323-Debug-Protokolle und Endpunktprotokolle, um das Problem zu isolieren. Überprüfen Sie in den H.323-Debug-Protokollen, ob die RTDR-Anforderungs- und Antwortnachrichten verworfen wurden und ob diese verworfen wurden.

In dieser Beispielausgabe sendet der Endpunkt eine RTDR-Anforderung an den Remote-Endpunkt, und er erhält keine Antwort vom Remote-Ende. Der Anruf wird daher getrennt:

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

Die Anfragen und Antworten können mit Sequenznummern nachverfolgt werden.

Dieses Beispiel aus den Endpunktprotokollen zeigt die Ursache für die Verbindungstrennung:

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

Problem: Anruffehler aufgrund eines Fehlers bei der Zuweisung von Medienressourcen

Bei Videoanrufen werden Anrufe angezeigt, die aufgrund eines Fehlers bei der Medienressourcenzuweisung fehlschlagen. Wenn der anrufende und der angerufene Endpunkt beispielsweise keinen gemeinsamen Codec unterstützen, ist ein Transcoder erforderlich, wenn eine DTMF-Diskrepanz (Dual Tone Multi Frequency) zu einem MTP (Media Termination Point) im Call Manager führt.

Lösung

Für die Videotranskodierung ist ein Packet Voice Digital Module (PVDM3) Digital Signal Processor (DSP)-Transcoder erforderlich, da die Transcoder auf PVDM2 keine Videoübertragung unterstützen. Wenn kein Transcoder/MTP verfügbar ist, wird eine Meldung über den nicht verfügbaren 503 Service an den Endpunkt gesendet:

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

Um dies zu beheben, überprüfen Sie die Konfiguration der Medienressourcengruppe/Medienressourcengruppe (MRG/MRGL), und stellen Sie sicher, dass Video-Transcoder/MTP verfügbar sind. Ein MRGL kann einem Gerät auf Telefon- oder Gerätepoolebene zugewiesen werden:

1. Wählen Sie im CallManager Device > Phone (Gerät > Telefon) aus, wählen Sie das Gerät aus, bei dem das Problem aufgetreten ist, und überprüfen Sie den Gerätepool und die MRGL-Einstellungen:

   

2. Wenn die MRGL-Einstellung auf dem Telefon Keine ist, müssen Sie die Einstellungen für den Gerätepool überprüfen, um sicherzustellen, dass ein Transcoder vorhanden ist.
3. Wählen Sie System > Device Pool (Gerätepool) aus, und wählen Sie den Gerätepool aus, der dem Gerät zugewiesen ist:

   

4. Wählen Sie Media Resources > Media Resource Group List (Medienressourcengruppen-Liste) aus, und wählen Sie die auf Telefon-/Gerätepoolebene zugewiesene MRGL aus, und überprüfen Sie die MRGs:

   

5. Notieren Sie die MRGs, wählen Sie Medienressourcen > Medienressourcengruppe aus, und wählen Sie die notierten MRGs aus. Stellen Sie sicher, dass ein PVDM3-Hardware-Transcoder/MTP hinzugefügt wurde.

   

Problem: Anrufausfälle aufgrund unzureichender Bandbreite

In der Regel gibt es Szenarien, in denen die Verbindung eines Anrufs getrennt wird, da die Bandbreitenkonfiguration in der Region/am Standort des Geräts im CUCM nicht ausreicht. Wenn die Region auf eine niedrige Bandbreite festgelegt ist, die vom Endpunkt nicht unterstützt werden kann, sendet der CallManager eine "488 Not Acceptable Media"-Nachricht mit Ursache 125. Dies bedeutet "Out of Bandwidth" (Aus Bandbreite) oder "Ingenügend Bandbreite" (Unzureichende Bandbreite), nachdem die SIP-Medienverhandlung stattgefunden hat.

Sie müssen die SIP-Protokolle am Endpunkt wie beschrieben erfassen und nach dieser Nachricht suchen:

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

Lösung

Wenn dieses Problem auftritt, überprüfen Sie die für beide Endpunkte konfigurierte Region, und überprüfen Sie die Regionsbeziehung zwischen ihnen:

1. Wählen Sie Device > Phone (Gerät > Telefon) aus, und wählen Sie beide Geräte aus. Überprüfen Sie den Gerätepool, der den Geräten zugewiesen ist:

   

2. Wenn Sie den Gerätepool überprüft haben, wählen Sie System > Device Pool (System > Gerätepool im CUCM aus, und überprüfen Sie die für beide Gerätepools konfigurierte Region:

   

3. Wählen Sie System > Region Information > Regions und überprüfen Sie die Region Relationship. Überprüfen Sie die Audio-Video-Bandbreite in der Region, und stellen Sie sicher, dass das Endgerät mit der gewählten Audio-/Video-Bandbreite betrieben werden kann:

   

In den obigen Screenshots wird davon ausgegangen, dass ein Endpunkt in der Region "Trunk Region" und das andere in der Region "Lokale Endpunktbereiche" liegt.

Eine weitere Problemumgehung besteht darin, den Videoanruf als Audioanruf auszuprobieren, wenn die Bandbreite für Videoanrufe nicht ausreicht. Mit diesem Verfahren können Sie Folgendes überprüfen und konfigurieren:

1. Wählen Sie Device > Phone (Gerät > Telefon) aus, und wählen Sie das anrufende Gerät mit dem Problem aus. Überprüfen Sie, ob der Parameter in diesem Screenshot aktiviert ist. Wenn diese Option deaktiviert ist, prüfen Sie sie, damit bei Bandbreitenproblemen ein Videoanruf wieder auf Audio zurückfällt:

   

   Dieses Problem kann durch die Standorteinstellungen auf dem CallManager auftreten.

   Standorte können auf Telefonebene oder auf Gerätepoolebene zugewiesen werden (Telefonebene hat höhere Priorität).

2. Um die Standorteinstellungen auf Telefonebene zu überprüfen, wählen Sie Devices > Phones (Geräte > Telefone) aus und überprüfen Sie den Standort für das anrufende und das angerufene Endgerät:

   

   Der Standort kann auch auf Gerätepoolebene angewendet werden. Überprüfen Sie daher zunächst den Gerätepool beider Endpunkte:

   

3. Wählen Sie System > Device Pool aus. Überprüfen Sie im Gerätepool den Standort, der sowohl den anrufenden als auch den angerufenen Endpunkten zugewiesen ist. In diesem Beispiel wird auf Gerätepoolebene kein Standort zugewiesen. Die Konfiguration des Telefonstandorts wird verwendet:

   

4. Überprüfen Sie, ob zwischen dem Standort der anrufenden und der angerufenen Endpunkte eine ausreichende Bandbreite konfiguriert ist. In diesem Beispiel wird davon ausgegangen, dass sich ein Endpunkt am Standort der lokalen Endpunkte befindet, das andere am Standort "Hub_None", und die Bandbreite für Audio-/Video- und immersive Anrufe werden alle als Unlimited (Unbegrenzt) konfiguriert:

   

Es könnte andere Gründe für eine Trennung geben. Siehe Seite 178 des Cisco Unified Communications Manager Call Detail Records Administration Guide, Release 10.0(1) für Trennungsursachencodes.