Fehlerbehebung bei der Registrierung von IP-Telefonen - eine Fallstudie

Einführung

Dieses Dokument beschreibt Informationen, die Sie zur Fehlerbehebung in Ihrer Konfiguration verwenden können.

Cisco IP-Telefone verwenden einen Mechanismus zum Keepalives auf Anwendungsebene zusätzlich zum Mechanismus zum Keepalive auf Netzwerkebene. Keep-Alive-Mechanismus für Skinny Call Control Protocol (SCCP)- und Session Initiation Protocol (SIP)-Geräte stellt sicher, dass das Gerät bei der Anrufsteuerung registriert bleibt. Sie sollen auch die Verbindung von Geräten mit der Anrufsteuerung wiederherstellen.

Voraussetzungen 

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

SCCP-Keep-alives und Failover-Mechanismus

SCCP verwendet das TCP-Protokoll für Transport und verwendet die Ports 2000 und 2443 (für gesicherte Verbindungen), um eine Verbindung zum Call Manager herzustellen. Die SCCP-Telefone sollten eine TCP-Verbindung mit dem Cisco Unified Communications Manager (CUCM) herstellen, bevor sie sich registrieren. Anschließend erfolgt ein TCP-Handshake mit drei Richtungen auf Port 2000, um einen Kommunikationskanal einzurichten. Das Telefon initiiert diese Verbindung, indem es ein SYN (synchronisieren) an CUCM sendet und CUCM antwortet mit SYN, ACK (Bestätigung). Das Telefon reagiert wiederum mit einem ACK, und die TCP-Verbindung wird hergestellt.

Haltbare Alben

Es gibt zwei Keepalive-Methoden: Anwendungsebene (SKINNY Keep-Alive) und Netzwerkebene (TCP Keep-Alive)

Failover

In einem idealen Szenario stellt ein SCCP-Telefon eine TCP-Verbindung zum primären CUCM und dem ersten Backup-CUCM her. Das SCCP-Telefon sendet Keep-Alive an den CUCM, an den die TCP-Verbindung hergestellt wurde. Der primäre Server antwortet dann auf das SCCP-Keep-Alive. Das Zeitintervall beträgt 30 Sekunden für den primären Server und 60 Sekunden für den Backup-Server.

Der primäre CUCM antwortet mit dem SCCP-Keepalive-ACK, der sowohl die SCCP- als auch die TCP-Verbindung bestätigt. Der Backup-CUCM sendet einfach ein TCP-ACK an den Keepalive, der vom Telefon gesendet wird. Wenn das Telefon beim Sichern von CUCM nicht vorgeht, weil der Call Manager-Dienst nicht verfügbar ist oder die TCP-Verbindung selbst beim primären CUCM nicht verfügbar ist, verwendet es zwei Arten von Mechanismen, um den primären CM-Ausfall zu erkennen. Diese sind normal und verzögert.

Normales Failover

Diese Methode verwendet einen Algorithmus, um den Durchschnitt der Zeit zu berechnen, die der CUCM zur Bestätigung der vorherigen Keepalives benötigt.

Wenn der CUCM beispielsweise im Durchschnitt X Sekunden benötigt, um auf die letzten 10.000 Keepalives zu reagieren, wartet das Telefon X Sekunden, bevor es den Ausfall von CUCM erkennt. Anschließend wird versucht, sich beim Backup-CUCM zu registrieren.

Verzögertes Failover

Bei diesem Mechanismus wartet das Telefon auf die 3 Keepalive-Intervalle, um den Ausfall des primären CUCM zu erkennen.

Rückzug

Netzwerke, in denen die Transitzeit von Paketen schwankt, sowie ein verzögertes Failover helfen, eine unnötige Aufhebung der Registrierung zu vermeiden. 

Beispiel für eine Transit-Zeitfluktuation (Beachten Sie die Zeitverzögerung für die Ping-Antwort):

64 bytes from 10.106.97.150: icmp_seq=1 ttl=63 time=0.100 ms
64 bytes from 10.106.97.150: icmp_seq=2 ttl=63 time=200 ms
64 bytes from 10.106.97.150: icmp_seq=3 ttl=63 time=0.180 ms
64 bytes from 10.106.97.150: icmp_seq=4 ttl=63 time=0.678 ms
64 bytes from 10.106.97.150: icmp_seq=5 ttl=63 time=590 ms
64 bytes from 10.106.97.150: icmp_seq=6 ttl=63 time=0.100 ms
64 bytes from 10.106.97.150: icmp_seq=7 ttl=63 time=345 ms
64 bytes from 10.106.97.150: icmp_seq=8 ttl=63 time=456 ms
64 bytes from 10.106.97.150: icmp_seq=9 ttl=63 time=0.345 ms

[an error occurred while processing this directive]

Vorteil

Dieser Mechanismus kann in verzögerungsempfindlichen Netzwerken verwendet werden.

  

SIP Keep-Alive

Das SIP-Telefon registriert sich beim CUCM und sendet gemäß den Einstellungen in CUCM alle 120 Sekunden Keep-Alive. Wenn das Telefon die Erstregistrierung an den primären CUCM sendet, wird der Expires Timer auf 3600 Sekunden festgelegt (Standardeinstellung im SIP-Profil, das auf dem Telefon angewendet wird). Der CUCM sendet eine ACK, indem der Timer entsprechend dem im Service-Parameter festgelegten Wert auf 120 Sekunden geändert wird.

Aus diesem Grund sendet das Telefon alle 120 Sekunden "Keep-Alive" (Keepalive) (tatsächlich 115 Sekunden, also 120 Sekunden minus Delta-Wert, der im SIP-Profil konfiguriert wurde, was standardmäßig 5 Sekunden beträgt). In diesem Fall sendet das Telefon alle 115 Sekunden "Keep-Alive".

SIP-Telefon tauscht die Nachricht registrieren an Backup-CUCM aus, wobei das Feld "Expires" auf 0 gesetzt ist.

Zu primär

REGISTER sip:10.106.114.161 SIP/2.0

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

Max-Forwards: 70

Date: Wed, 15 Jul 2015 12:42:56 GMT

CSeq: 11435 REGISTER

User-Agent: Cisco-CP7975G/9.3.1

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1

Content-Length: 0

Expires: 3600



SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Content-Length: 0



SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>;tag=1708299782

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Expires: 120

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0

Content-Length: 0

[an error occurred while processing this directive]

An sekundär

REGISTER sip:10.60.1.12:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.60.63.21:3784;rport;branch=z9hG4bKPjdcJ819aZtTCtmvr0VBheV6p0uL8aC.pG

Max-Forwards: 70

From: <sip:6836@10.60.1.12>;tag=5oI-ew53.DGjTDu5LB9orkdDpZlccNbv

To: <sip:6836@10.60.1.12>

Call-ID: HxTK.m6BH9qxjstVwexTbhVnUxNeuxle

CSeq: 18800 REGISTER

Expires: 0

Contact: <sip:e2b0f175-feae-d664-befa-b7cd0837fcc6@10.60.63.21:5060;transport=TCP>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-e0d1730ac1b1>";+u.sip!devicename.ccm.cisco.com="SEPE0D1730AC1B1";+u.sip!model.ccm.cisco.com="592";expires=0;cisco-keep-alive

Content-Length:  0

[an error occurred while processing this directive]

Erforderliche Protokolle

Sammeln Sie die folgenden Informationen, um zu ermitteln, warum die Telefonregistrierung auftrat:

• Event Viewer Application and System Logs (Ereignisanzeige und Systemprotokolle): Stellt Alarm-/Fehlercodes für die Aufhebung der Registrierung des Telefons bereit, mit denen wir die Fehlerbehebung fortsetzen können.

• Paketerfassung vom Telefon und vom CUCM (primär und Backup) gleichzeitig - hilft bei der Isolierung der Netzwerkproblematik.

• Cisco Call Manager Traces

Relevante Links

Sammeln von Paketerfassungen vom CUCM

Erfassung über IP-Telefon

Erfassen von CUCM-Ablaufverfolgungen

Analysieren der Protokolle und Paketerfassungen

• Das Ereignisanzeige-Anwendungsprotokoll druckt EndPointUnregistered-Nachricht sowie verwandte Ursachencodes.

Example: 31 uc-ucm-01 local7 3 : 41679: uc-ucm-01.pcce.local Jul 02 2015 06:22:31 UTC :   %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEPE0D1730A8137][IPAddress=10.60.98.210][Protocol=SIP][DeviceType=592][Description=Phone][Reason=13][IPAddrAttributes=0][LastSignalReceived=SIPStationDPrimaryLineTimeout][AppID=Cisco CallManager][ClusterID=StandAloneCluster][NodeID=uc-ucm-01]: An endpoint has unregistered

[an error occurred while processing this directive]

Die Ursachencodes für die EndPointUnregistration finden Sie in der Dokumentation zu Systemfehlermeldungen.

Lesen von Wireshark-Protokollen

Bei der Erfassung von Aufnahmen an beiden Enden wird überprüft, ob der per Telefon gesendete Keepalive tatsächlich den CUCM erreicht oder nicht.

Die Sequenznummer des TCP-Pakets erleichtert die Verfolgung des TCP-Datenverkehrs zwischen Telefon und CUCM bei der Sniffer-Erfassung.

Erfassung vom Telefon

Telefon sendet ein Paket mit der Sequenznummer 2991996107. Überprüfen Sie, ob dieses Paket den CUCM erreicht.

Erfassung über CUCM

Die Sequenznummer, die bei der Erfassung von Telefonschniffern angezeigt wird, sollte in der CUCM-Erfassung angezeigt werden.

Anwenderbericht 1.2

Beschreibung des Problems

Die SCCP-Telefone werden in regelmäßigen Abständen neu gestartet.

Fehlerbehebung

Das Ereignisanzeige-Anwendungsprotokoll gibt an, dass die Telefone aufgrund fehlender Keepalives mit Fehlercode 13 weiterhin neu gestartet wurden.

Event Viewer Message.

[an error occurred while processing this directive]

Paketerfassung über IP-Telefon und CUCM  In diesem Szenario erreichte der letzte von einem IP-Telefon gesendete Keep-Alive-Vorgang nicht den CUCM.

Image.

[an error occurred while processing this directive]

Keep-Alive wird aus diesem Grund verworfen:

Als das Telefon einen ARP schickte, um die MAC-Adresse des CUCM zu erhalten, kam die Antwort vom ARP-Proxy mit der ASA-MAC-Adresse. Die erste Antwort stammte eindeutig nicht von CUCM. Da das Telefon das Telefon jedoch zuerst empfängt, sendet es den Frame mit der MAC-Adresse des anderen Geräts an den Switch.

Dies geschieht hauptsächlich, wenn ARP-Proxy auf ASA aktiviert ist.

Auflösung

Deaktivieren Sie den ARP-Proxy auf ASA, um das Problem zu beheben.

Anwenderbericht 2.

Beschreibung des Problems

Alle 16 Minuten werden die Telefone des Cisco IP-Telefons 8961 zurückgesetzt und beim sekundären CUCM registriert. Nach 2 Minuten wird das Telefon wieder zum primären CUCM zurückgesetzt, und dieser Zyklus wird fortgesetzt.

Fehlerbehebung

Sammeln Sie Paketerfassungen vom Telefon und von CUCM-Ablaufverfolgungen. Die Aufhebung der Registrierung war darauf zurückzuführen, dass das IP-Telefon den SIP-Keep-Alive-Modus verpasst hat.

Analyse

Das SIP-Telefon registriert sich beim CUCM und sendet gemäß den Einstellungen in CUCM alle 120 Sekunden "Keep-alive".

Wenn das Telefon die Erstregistrierung sendet, setzt es den Zeitgeber auf 3600 Sekunden (Standardeinstellung im SIP-Profil, das auf das Telefon angewendet wird). Der CUCM bestätigt dies, indem er den Timer entsprechend dem im Service-Parameter festgelegten Wert auf 120 Sekunden ändert.

Das Telefon sendet Keepalive alle 120 Sekunden (Keepalive-Intervall beträgt 115 Sekunden, was 120 minus dem im SIP-Profil konfigurierten Delta-Wert entspricht, der standardmäßig 5 Sekunden beträgt). In diesem Fall sendet das Telefon alle 115 Sekunden Keepalive.

In diesem Problemszenario sendet das Telefon mit 115 Sekunden die erste Keepalive-Nachricht, die im Netzwerk verworfen wird. Dies führt dazu, dass das Telefon den Keepalive in 100 ms (101 Sekunden) erneut sendet. Er erhält eine Antwort vom CUCM auf die REGISTER-Anfrage.

Jetzt sendet das Telefon die zweite Keepalive-Nachricht nach 115 Sekunden und wird im Netzwerk verworfen. Jetzt erhöht das Telefon das Intervall zum erneuten Wiederholen von REGISTER auf 0,02 Sekunden (200 Millisekunden).

Jedes Mal, wenn das Telefon die Keepalive-Übertragung nach 115 durchführt, wird sie im Netzwerk verworfen, wodurch das Telefon das Paket erneut übertragen kann. Auch das Telefon erhöht exponentiell das Wiederholungsintervall. Nach wenigen solchen Keepalives erhöht sich der Wiederholungsversuch der Telefone auf 14 Sekunden.

Das Telefon wird nach 14 Sekunden erneut übertragen, und es erhält ein ACK vom CUCM.

Wenn das Telefon das nächste Mal "Keep-Alive" sendet, geht es verloren, und das Telefon sendet nach 28 Sekunden erneut eine REGISTER-Anfrage. Der CUCM kann nicht 28 Sekunden warten, er wartet nur 15 Sekunden (nach den 115 s) und sendet dann das Rückmeldesignal.

Die Keep-Alive-Zeit und die RTO-Funktion summieren sich auf bis zu 16 Minuten und ein paar Sekunden.

Nach 16 Minuten aufgrund des Rückmeldesignals vom CUCM registrieren sich die Telefone beim sekundären CUCM, und nach 2 Minuten melden sie sich wieder bei Primary (Primäres Telefon) an. Dies wird fortgesetzt.

Ursache für die Keepalive-Drops

Wenn der Switch-Port mit Port-Sicherheit konfiguriert wurde, wurde die Port-Alterung mit inaktivem Timer konfiguriert. Der Timer wurde auf eine Minute festgelegt, die kleiner ist als der SIP-Keepalive-Timer. Dies führte dazu, dass der Switch-Port die Telefon-MAC-Adresse alle eine Minute löschte. Die Pakete werden weiterhin verworfen, da das SIP-Keepalive-Intervall alle 2 Minuten beträgt.