Risoluzione dei problemi di chiamata non riuscita sugli endpoint TC registrati in Cisco CallManager

Introduzione

Questo documento spiega alcuni dei problemi più comuni che si verificano quando si usano gli endpoint Tandberg Codec (TC) registrati su Cisco CallManager e suggerisce alcune soluzioni.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

Come acquisire i log di debug H.323

Nota: Verificare che l'output della sessione SSH (Secure Sockets Host) sia stato acquisito.

1. SSH nella CLI del codec e immettere questi comandi:
   • log ctx H.323Packet debug 9
   • log output on (questo comando invia tutti i log alla schermata della sessione terminale SSH).
2. Avviare una chiamata e ricreare il problema.
3. Immettere l'output log off e i comandi log ctx H.323Packet debug off.

Come acquisire i log di debug SIP (Session Initiation Protocol)

Nota: Verificare che l'output della sessione SSH sia stato acquisito.

1. SSH nella CLI del codec e immettere questi comandi:
   • log ctx SIPPacket debug 9
   • log output on (questo comando invia tutti i log alla schermata della sessione terminale SSH).
2. Avviare una chiamata e ricreare il problema.
3. Immettere l'output di log off e i comandi log ctx SIPPacket debug off.

Come raccogliere i log di acquisizione pacchetti/endpoint dagli endpoint TC

1. Dalla GUI del Web, selezionare Diagnostics > Log files (Diagnostica > File di log) e abilitare la registrazione estesa con l'acquisizione completa dei pacchetti.
2. Avviare una chiamata e ricreare il problema. L'acquisizione dei pacchetti può essere abilitata solo per 3 minuti.
3. Dalla GUI del Web, selezionare Diagnostics > Log files (Diagnostica > File di log) e scaricare l'archivio di log completo e l'acquisizione dei pacchetti.

Altre informazioni richieste

• Flusso di chiamate completo con tutti i dispositivi interessati
• Numero chiamato e chiamante
• Data e ora del problema

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Problema: Errori di chiamata causati da problemi di partizione/spazio di ricerca delle chiamate (CSS) in CallManager

Le chiamate tra due endpoint registrati in Cisco Unified Communications Manager (CUCM) potrebbero non riuscire a causa di un problema di partizione/CSS su CUCM.

Acquisire i registri SIP dell'endpoint chiamante. Questo messaggio "404 Not Found" (404 non trovato) viene visualizzato sui log SIP degli endpoint provenienti da CUCM:

 |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

Soluzione

Completare questa procedura per controllare il CSS dell'endpoint chiamante e la partizione dell'endpoint chiamato. Verificare che il CSS dell'endpoint chiamante disponga della partizione dell'endpoint chiamato.

È possibile assegnare un foglio di stile CSS a livello di dispositivo e di linea sull'endpoint:

1. Scegliete Periferica > Telefono, selezionate l'endpoint e fate clic sulla linea, quindi controllate lo spazio di ricerca chiamate (CSS) a livello di linea. In questo esempio, non è configurato alcun foglio di stile CSS a livello di linea. Tuttavia, se esiste un foglio di stile CSS a livello di numero di directory, uno dei fogli di stile CSS deve avere una partizione del numero chiamato:

   

2. Controllare i fogli di stile CSS assegnati a livello di telefono. Scegliere Dispositivo > Telefono e selezionare l'endpoint chiamante in questione:

   

3. Controllare la partizione del numero chiamato. Scegliete Periferica > Telefono, selezionate la periferica chiamata, fate clic sulla linea e controllate la Partizione stesura:

   

4. Dopo aver verificato la partizione e il foglio di stile CSS su entrambi gli endpoint, verificare se il foglio di stile CSS del dispositivo chiamante contiene la partizione del dispositivo chiamato:

   

   In caso contrario, è possibile che sia stato generato l'errore "404 Not Found".

Problema: Interruzione delle chiamate SIP dopo 15 minuti (o dopo un orario specifico)

In genere gli intervalli di tempo specifici in cui le chiamate vengono interrotte sono causati da timer SIP o da timeout TCP configurati su firewall, router e così via.

Soluzione

Quando la chiamata si disconnette esattamente entro 15 minuti, il problema comune rilevato è che il timeout TCP configurato sulla rete (firewall, router) è inferiore al timer di scadenza della sessione SIP. Per impostazione predefinita, in CallManager il timer scadenza sessione SIP è impostato su 1800 secondi.

Per verificare questa condizione, scegliere Cisco Unified CM Administration > System > Service Parameters > Cisco Call Manager Service > Look for - SIP Session Expires Timer.

Tutti gli endpoint registrati in CUCM utilizzano questo timer. Quando l'endpoint è in chiamata con un altro endpoint remoto, una delle parti deve aggiornare la sessione e inviare un nuovo INVITE o UPDATE. Questo aggiornamento deve essere inviato prima che metà del timer di scadenza della sessione (1800/2 = 900 secondi = 15 minuti). Se non viene ricevuto alcun messaggio di aggiornamento, la chiamata viene disconnessa.

Controllare il timer della sessione nell'INVITE iniziale. È necessario ricevere un aggiornamento (INVITE / UPDATE) prima della scadenza di questo periodo di tempo:

|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

In base alla negoziazione iniziale tra client agente utente e server agente utente (UAC/UAS), uno degli endpoint aggiorna la sessione quando invia un nuovo invito. Se l'aggiornamento è UAC, l'iniziatore della chiamata ha la responsabilità di aggiornare la sessione. Se l'aggiornamento è UAS, il server deve aggiornare la sessione. Raccogliere i log di debug SIP da entrambi gli endpoint e verificare i seguenti elementi:

Esempio: Chiamata effettuata dal gruppo A al gruppo CUCM al gruppo B. Se l'aggiornamento è UAC sulla parte A e UAS sulla parte B:

1. La parte A deve inviare il messaggio di invito/aggiornamento al CUCM.
2. CUCM deve inviare un nuovo INVITE/AGGIORNAMENTO all'entità B.
3. La parte B riceve il messaggio di invito e risponde con 200 OK.
4. CUCM deve inviare 200 OK al gruppo A.

Se un endpoint invia il messaggio di richiesta di nuovo invito al CUCM, quest'ultimo invia una richiesta di nuovo invito all'altra parte. Tuttavia, se questo messaggio non viene ricevuto dal lato remoto, è possibile che nel mezzo vi siano alcuni dispositivi di rete. È molto probabile che il comando re-INVITE/response non raggiunga uno dei lati a causa dell'ispezione SIP o delle impostazioni di rete.

Se gli endpoint non avviano la funzione RE-INVITE, è possibile che si sia verificato un problema con l'endpoint. Coinvolgere il Cisco Technical Assistance Center (TAC) per ulteriori indagini.

Problema: La chiamata H.323 scade dopo un orario specifico

Come con il SIP, nelle chiamate H.323 le interruzioni a un intervallo di tempo specifico si verificano in genere a causa della configurazione del timeout della rete o del firewall.

Soluzione

Nelle chiamate H.323, viene inviato un messaggio Round Trip Delay Request (RTDR) ogni 30 secondi tra gli endpoint con i numeri di sequenza. Per ogni richiesta è prevista una risposta.

Cisco Endpoint utilizza il messaggio di risposta RTDR/Round Trip Delay, che fa parte del messaggio di controllo del sistema multimediale H.245. In questo modo, la sessione TCP H.245 rimane attiva durante la chiamata, che viene utilizzata per la gestione attiva delle chiamate. Se l'endpoint riceve una risposta per RTDR inizialmente e non viene ricevuta alcuna risposta durante la chiamata, l'endpoint termina la chiamata.

In questo scenario, raccogliere i log di debug H.323 e i log degli endpoint per isolare il problema. Dai log di debug H.323, controllare la presenza dei messaggi di richiesta e risposta RTDR e verificare se diminuisce.

In questo output di esempio, l'endpoint invia una richiesta RTDR all'endpoint remoto e non riceve una risposta dall'estremità remota. Pertanto disconnette la chiamata:

 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

Le richieste e le risposte possono essere registrate con sequenceNumbers.

Questo esempio dai log degli endpoint mostra la causa della disconnessione:

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

Problema: Chiamata non riuscita a causa di un errore di allocazione delle risorse multimediali

In caso di videochiamate, vengono visualizzate le chiamate non riuscite a causa di un errore di allocazione risorse multimediali. Ad esempio, se l'endpoint chiamante e chiamato non supportano un codec comune, è necessario un transcodificatore. Per una mancata corrispondenza DTMF (Dual Tone Multi Frequency), è necessario un MTP (Media Termination Point) sul Call Manager.

Soluzione

Per la transcodifica video, è necessario un transcodificatore Packet Voice Digital Module (PVDM3) Digital Signal Processor (DSP) poiché i transcodificatori su PVDM2 non supportano il video. Se un transcoder/MTP non è disponibile, viene inviato un messaggio di servizio 503 non disponibile all'endpoint:

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 

Per risolvere questo problema, controllare la configurazione Media Resource Group/Media Resource Group List (MRG/MRGL) e assicurarsi che il trascodificatore video/MTP sia disponibile. Un MRGL può essere assegnato a un dispositivo a livello telefonico o a livello di pool di dispositivi:

1. In CallManager, selezionare Device > Phone (Dispositivo), quindi selezionare il dispositivo che ha il problema e controllare il pool di dispositivi e le impostazioni MRGL:

   

2. Se l'impostazione MRGL sul telefono è Nessuno, è necessario controllare le impostazioni del pool di dispositivi per assicurarsi che ci sia un transcodificatore.
3. Scegliere Sistema > Pool di dispositivi e selezionare il pool di dispositivi assegnato al dispositivo:

   

4. Scegliere Risorse multimediali > Elenco gruppi di risorse multimediali e selezionare l'MRGL assegnato a livello di telefono/pool di dispositivi e controllare gli MRG:

   

5. Annotare gli MRG e scegliere Risorse multimediali > Gruppo risorse multimediali, quindi selezionare gli MRG annotati. Accertarsi di aver aggiunto un transcodificatore hardware/MTP PVDM3.

   

Problema: Chiamata non riuscita a causa di larghezza di banda insufficiente

Il più delle volte si verificano scenari in cui una chiamata viene disconnessa a causa di una configurazione della larghezza di banda insufficiente in Region/Location sul dispositivo in CUCM. Quando l'area geografica è impostata su una larghezza di banda ridotta che l'endpoint non è in grado di supportare, CallManager invia un messaggio indicante "488 Supporti non accettabili" con causa 125, ovvero "Larghezza di banda insufficiente" o "Larghezza di banda insufficiente" dopo l'esecuzione della negoziazione dei supporti SIP.

È necessario acquisire i log SIP sull'endpoint come descritto e cercare questo messaggio:

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']

Soluzione

Se si verifica questo problema, controllare la regione configurata su entrambi gli endpoint e controllare la relazione di regione tra di essi:

1. Scegliete Periferica > Telefono e selezionate entrambe le periferiche. Controllare il pool di dispositivi assegnato ai dispositivi:

   

2. Dopo aver controllato il pool di dispositivi, scegliere System > Device Pool (Sistema) sul CUCM e controllare la regione configurata su entrambi i pool di dispositivi:

   

3. Scegliete Sistema > Informazioni area > Aree e selezionate Relazione area. Controllare la larghezza di banda audio/video sulla regione e verificare che l'endpoint possa funzionare alla larghezza di banda audio/video selezionata:

   

Nelle schermate precedenti si presume che un endpoint si trovi nella regione "Trunk Region" e l'altro nella "regione degli endpoint locali".

Un'altra soluzione è provare la videochiamata come chiamata audio se la larghezza di banda per la videochiamata è insufficiente. Utilizzare questa procedura per verificare e configurare:

1. Scegliere Periferica > Telefono e selezionare la Periferica chiamante con il problema. Controlla se il parametro in questa schermata è selezionato. Se non è selezionata, controllarla in modo che in caso di problemi di larghezza di banda la videochiamata ritorni all'audio:

   

   Questo problema può verificarsi a causa delle impostazioni di posizione in CallManager.

   È possibile assegnare le posizioni a livello telefonico o a livello di pool di dispositivi (il livello telefonico ha priorità più alta).

2. Per controllare le impostazioni della località a livello di telefono, scegliere Dispositivi > Telefoni e controllare la località sia sull'endpoint chiamante che su quello chiamato:

   

   La posizione può essere applicata anche a livello di pool di dispositivi. Pertanto, controllare innanzitutto il pool di dispositivi di entrambi gli endpoint:

   

3. Scegliete Sistema > Pool di dispositivi. Nel pool di dispositivi controllare il percorso assegnato agli endpoint chiamanti e chiamati. In questo esempio non viene assegnata alcuna posizione a livello di pool di dispositivi. Viene utilizzata la configurazione della località di chiamata:

   

4. Verificare che tra la posizione degli endpoint chiamanti e la posizione degli endpoint chiamati sia configurata una larghezza di banda sufficiente. In questo esempio si presume che un endpoint si trovi nella posizione degli endpoint locali e l'altro si trovi nella posizione Hub_None e la larghezza di banda per audio/video e le chiamate immersive sono configurate come Illimitate:

   

Ci potrebbero essere altri motivi per disconnettersi. Vedere pagina 178 della guida all'amministrazione dei record dei dettagli delle chiamate di Cisco Unified Communications Manager, versione 10.0(1) per i codici causa di disconnessione.