Risoluzione dei problemi di annullamento della registrazione di un telefono IP - Caso aziendale
Sommario
Introduzione
Questo documento descrive le informazioni che possono essere usate per risolvere i problemi relativi alla configurazione.
Cisco IP Phone utilizza il meccanismo keep-alive a livello di applicazione in aggiunta al meccanismo TCP keep-alive a livello di rete. Il meccanismo Keep-Alive per i dispositivi SCCP (Skinny Call Control Protocol) e SIP (Session Initiation Protocol) garantisce che il dispositivo rimanga registrato con il controllo delle chiamate. Sono inoltre destinati a ristabilire la connessione dei dispositivi con il controllo delle chiamate.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Keep-alives e meccanismo di failover SCCP
SCCP utilizza il protocollo TCP per Transport e le porte 2000 e 2443 (per secure) per stabilire la connessione con Call Manager. I telefoni SCCP devono stabilire una connessione TCP con Cisco Unified Communications Manager (CUCM) prima di registrarsi. In seguito, sulla porta 2000 verrà eseguito un handshake TCP a 3 vie per stabilire un canale di comunicazione. Il telefono avvia questa connessione inviando un SYN (sincronizza) a CUCM e CUCM risponde con SYN, ACK (conferma). Il telefono a sua volta risponde con un ACK e la connessione TCP viene stabilita.
Keep-alive
Esistono due metodi keep-alive: Livello applicazione (SKINNY keep-alive) e Livello rete (TCP keep-alive)
Failover
In uno scenario ideale, un telefono SCCP mantiene una connessione TCP stabilita al CUCM primario e al primo CUCM di backup. Il telefono SCCP invia keep-alive a tutti i CUCM a cui ha stabilito una connessione TCP. Il server primario risponde quindi al keep-alive SCCP. L'intervallo di tempo è di 30 secondi per il server principale e di 60 secondi per il server di backup.
Il CUCM primario risponde con il comando SCCP keepalive ACK, che riconosce sia la connessione SCCP sia la connessione TCP. Il CUCM di backup invia semplicemente un ACK TCP al keep-alive inviato dal telefono. Quando il telefono non riesce a eseguire il backup di CUCM perché il servizio Gestione chiamate non è disponibile o la connessione TCP stessa non è disponibile con il CUCM primario, utilizza due tipi di meccanismi per rilevare l'errore del CM primario e sono normali e ritardati.
Failover normale
Questo metodo utilizza un algoritmo per calcolare la media del tempo impiegato da CUCM per riconoscere i precedenti keep-alive.
Ad esempio, se il tempo medio impiegato da CUCM è di X secondi per rispondere agli ultimi 10.000 keep-alive, il telefono attenderà X secondi prima di rilevare il guasto di CUCM. In seguito, proverà a registrarsi al backup CUCM.
Failover ritardato
In questo meccanismo, il telefono attende 3 intervalli keep-alive per rilevare il guasto del CUCM primario.
Ritorno
Reti in cui il tempo di transito dei pacchetti oscilla, il failover ritardato aiuta a evitare un'inutile annullamento della registrazione.
Esempio di fluttuazione del tempo di transito (notare il ritardo della risposta ping):
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]
Vantaggio
Questo meccanismo può essere utilizzato nelle reti sensibili al ritardo.
SIP Keep-alive
Il telefono SIP si registra in CUCM e invia keep-alive ogni 120 secondi secondo le impostazioni in CUCM. Quando il telefono invia la registrazione iniziale al CUCM primario, imposta il timer Expires su 3600 secondi (impostazione predefinita nel profilo SIP applicato al telefono). CUCM invia un ACK modificando il timer a 120 secondi come indicato nel parametro Service.
Pertanto, il telefono invia keep-alive ogni 120 secondi (in realtà 115 secondi, pari a 120 meno il valore delta configurato nel profilo SIP, che per impostazione predefinita è 5 secondi). In questo caso, il telefono invia keep-alive ogni 15 secondi.
Il telefono SIP invia il messaggio Register a Backup CUCM con il campo Expires impostato su 0.
Primario
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]
A secondario
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]
Registri necessari
Per identificare il motivo per cui è stata annullata la registrazione, raccogliere le informazioni indicate di seguito:
- Registri applicazioni e di sistema del Visualizzatore eventi: fornisce i codici di allarme/errore per l'annullamento della registrazione telefonica e l'utilizzo dei quali è possibile procedere con la risoluzione dei problemi.
- Acquisizione dei pacchetti dal telefono e dal CUCM (primario e di backup) contemporaneamente: aiuta a isolare la prospettiva della rete di problemi.
- Tracce di Cisco Call Manager.
Collegamenti rilevanti
Raccolta delle acquisizioni di pacchetti da CUCM
Raccolta acquisizione da IP Phone
Analisi dei registri e delle acquisizioni dei pacchetti
- Nel registro applicazioni del Visualizzatore eventi vengono stampati il messaggio EndPointUnregistered e i relativi codici motivo.
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]
I codici motivo per EndPointUnregistration sono disponibili nella documentazione dei messaggi di errore di sistema.
Lettura dei log di Wireshark
Quando vengono raccolte le clip da entrambe le estremità, per verificare che il keepalive inviato per telefono raggiunga o meno il CUCM.
Il numero di sequenza del pacchetto TCP aiuterà a tenere facilmente traccia del traffico TCP tra il telefono e il CUCM nell'acquisizione dello sniffer.
Acquisisci da telefono
Il telefono invia un pacchetto con numero di sequenza 2991996107. Verificare che il pacchetto raggiunga il CUCM.
Cattura da CUCM
Il numero di sequenza visualizzato nell'acquisizione dello sniffer del telefono deve essere visualizzato nell'acquisizione CUCM.
Case study 1.2
Descrizione del problema
I telefoni SCCP continuano a riavviarsi a intervalli regolari.
Risoluzione dei problemi
Il registro applicazioni del Visualizzatore eventi indica che i telefoni hanno continuato a riavviarsi a causa di keep-alive mancante con codice di errore 13.
Event Viewer Message.[an error occurred while processing this directive]
Raccogliere l'acquisizione dei pacchetti da IP Phone e CUCM. In questo scenario, l'ultimo keep-alive inviato da IP Phone non ha raggiunto CUCM.
Image.[an error occurred while processing this directive]
Keep-alive viene eliminato per questo motivo:
Quando il telefono ha inviato un ARP per ottenere l'indirizzo MAC di CUCM, la risposta è arrivata da ARP Proxy con indirizzo MAC ASA. Ovviamente, la prima risposta non è stata da parte di CUCM. Tuttavia, poiché il telefono riceve il frame per primo, lo invia allo switch con l'indirizzo MAC dell'altro dispositivo.
Ciò si verifica principalmente quando il proxy ARP è abilitato sull'appliance ASA.
Risoluzione
Disabilitare il proxy ARP sull'appliance ASA per risolvere il problema.
Studio del caso 2.
Descrizione del problema
I telefoni Cisco IP Phone modello 8961 vengono ripristinati ogni 16 minuti e si registra nel CUCM secondario. Dopo 2 minuti il telefono ritorna al primario CUCM e questo ciclo continua.
Risoluzione dei problemi
Raccogli le clip del pacchetto dal telefono e le tracce CUCM. L'annullamento della registrazione è stato causato dalla mancata corrispondenza del blocco SIP da parte del telefono IP.
Analisi
Il telefono SIP si registra in CUCM e invia Keep-alive ogni 120 secondi secondo le impostazioni in CUCM.
Quando il telefono invia la registrazione iniziale, imposta il timer di scadenza su 3600 secondi (impostazione predefinita nel profilo SIP applicato al telefono). CUCM lo riconosce modificando il timer a 120 secondi come indicato nel parametro Service.
Il telefono invia Keepalive ogni 120 secondi (l'intervallo di keep-alive è di 115 secondi, pari a 120 meno il valore delta configurato nel profilo SIP, che per impostazione predefinita è di 5 secondi). In questo caso il telefono invia keepalive ogni 15 secondi.
In questo scenario il telefono invia il primo keepalive a 115 secondi e viene scartato nella rete. In questo modo, il telefono ritrasmette il keepalive in 0,01 secondi (100 ms). Riceve una risposta da CUCM per la richiesta REGISTER.
Ora il telefono invia il secondo keepalive a 115 secondi e viene scartato dalla rete. Ora il telefono aumenta l'intervallo tra tentativi di registrazione a 0,02 secondi (200 millisecondi).
Ogni volta che il telefono invia il keepalive dopo il 115, questo viene scartato nella rete e ciò fa sì che il telefono ritrasmetta il pacchetto. Anche il telefono aumenta esponenzialmente l'intervallo tra i tentativi. Dopo pochi di questi keep-alive i telefoni riprovare aumenta a 14 secondi.
Il telefono ritrasmette dopo 14 secondi e ottiene un ACK dal CUCM.
Al successivo invio del comando keep-alive, il telefono viene perso e quindi ritrasmette la richiesta REGISTER dopo 28 secondi. Il CUCM non può attendere per 28 secondi, attende solo per 15 secondi (dopo i 115), quindi invia il segnale di annullamento della registrazione.
Il tempo di keep-alive e l'RTO sono pari a 16 minuti e pochi secondi.
Dopo 16 minuti a causa del segnale di annullamento della registrazione da CUCM, i telefoni si registrano al CUCM secondario e dopo 2 minuti si registrano nuovamente al primario e questo continua.
Causa delle gocce di keep-alive
Quando la porta dello switch è stata configurata con la funzione di sicurezza delle porte, la durata della porta è stata configurata con un timer inattivo. Il timer è stato impostato su un minuto, un valore inferiore rispetto al timer keep-alive SIP. Il risultato è stato che la porta dello switch scarica il MAC del telefono ogni minuto. I pacchetti continuano a essere scartati perché l'intervallo keep-alive SIP è ogni 2 minuti.
Feedback