Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Keep-alives e meccanismo di failover SCCP

Keep-alive

Failover

Failover normale

Failover ritardato

Ritorno

Vantaggio

SIP Keep-alive

Primario

A secondario

Registri necessari

Collegamenti rilevanti

Acquisisci da telefono

Cattura da CUCM

Case study 1.2

Descrizione del problema

Risoluzione dei problemi

Risoluzione

Studio del caso 2.

Descrizione del problema

Risoluzione dei problemi

Analisi

Causa delle gocce di keep-alive

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

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

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

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

Raccolta delle tracce CUCM

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

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.

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.

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.