Pesquise defeitos falhas de chamada nos valores-limite TC registrados ao CallManager da Cisco

Introduction

Este documento explica alguns dos problemas comuns de falha de chamada enfrentados com os terminais Tandberg Codec (TC) registrados no Cisco CallManager e as soluções sugeridas.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

Como capturar logs de depuração H.323

Note: Certifique-se de que a saída da sessão SSH (Secure Socket Host) seja capturada.

1. Use SSH na CLI do codec e digite estes comandos:
   • log ctx H.323Packet debug 9
   • log output on (Isso exibe todos os logs para a tela de sessão de terminal da sessão SSH.)
2. Inicie uma chamada e recrie o problema.
3. Insira os comandos log output off e log ctx H.323Packet debug off.

Como capturar logs de depuração do Session Initiation Protocol (SIP)

Note: Verifique se a saída da sessão SSH foi capturada.

1. Use SSH na CLI do codec e digite estes comandos:
   • log ctx SIPPacket debug 9
   • log output on (Isso exibe todos os logs para a tela de sessão de terminal da sessão SSH.)
2. Inicie uma chamada e recrie o problema.
3. Insira os comandos log output off e log ctx SIPPacket debug off.

Como Coletar Logs de Captura de Pacotes/Pontos Finais de Pontos Finais TC

1. Na GUI da Web, escolha Diagnostics > Log files e habilite o registro estendido com captura de pacote completo.
2. Inicie uma chamada e recrie o problema. Observe que a captura de pacotes só pode ser ativada por 3 minutos.
3. Na GUI da Web, escolha Diagnostics > Log files e faça download do arquivo de registro completo e da captura de pacotes.

Outras informações necessárias

• Fluxo de chamadas completo com todos os dispositivos envolvidos
• Número chamado e chamador
• Data e hora em que o problema ocorreu

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problema: Falhas de chamada devido a problemas de espaço de pesquisa de chamada (CSS)/partição no CallManager

As chamadas entre dois pontos finais registrados no Cisco Unified Communications Manager (CUCM) podem falhar devido a um problema de CSS/Partição no CUCM.

Capture os logs SIP do ponto de extremidade de chamada. Essa mensagem "404 Não encontrado" aparece nos logs SIP de endpoint que vêm do 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

Solução

Conclua estas etapas para verificar o CSS do ponto final de Chamada e a partição do ponto final Chamado. Certifique-se de que o CSS do ponto final de chamada tenha a partição do ponto final chamado.

Você pode atribuir um CSS no nível do dispositivo e da linha no endpoint:

1. Escolha Device > Phone, selecione o endpoint, clique na linha e verifique o Calling Search Space (CSS) no nível da linha. Neste exemplo, nenhum CSS é configurado no nível da linha. No entanto, se houver um CSS no nível do número de diretório, qualquer um dos CSSs deverá ter a partição do número chamado:

   

2. Verifique o CSS atribuído no nível do telefone. Escolha Device > Phone e selecione o ponto final de chamada em questão:

   

3. Verifique a partição do número chamado. Escolha Device > Phone, selecione o dispositivo chamado, clique na linha e verifique a Route Partion:

   

4. Depois de verificar a Partição e o CSS em ambos os endpoints, verifique se o CSS do dispositivo de chamada tem a partição do dispositivo chamado:

   

   Caso contrário, essa pode ser a causa do erro "404 Não encontrado".

Problema: Desconexão de chamada SIP após 15 minutos (ou após qualquer horário específico)

Em geral, os descartes de chamadas em intervalos de tempo específicos são causados por temporizadores SIP ou tempo limite TCP configurados em firewalls, roteadores e assim por diante.

Solução

Quando a chamada é desconectada em exatamente 15 minutos, o problema comum observado é que o tempo limite de TCP configurado na rede (firewalls, roteadores) é menor que o temporizador de expiração da sessão SIP. Por padrão no CallManager, o temporizador de expiração de sessão SIP é definido como 1800 segundos.

Para verificar isso, escolha Cisco Unified CM Administration > System > Service Parameters > Cisco Call Manager Service > Procure - Sessão SIP Expira Timer.

Todos os endpoints registrados no CUCM usam esse temporizador. Quando o endpoint está em chamada com outro endpoint remoto, uma das partes precisa atualizar a sessão e enviar um re-INVITE ou UPDATE. Essa atualização deve ser enviada antes que metade do Temporizador de Expiração da Sessão ( 1800/2 = 900 segundos = 15 minutos). Se nenhuma mensagem de atualização for recebida, a chamada será desconectada.

Verifique o temporizador da sessão no CONVITE inicial. Uma atualização (INVITE / UPDATE) deve ser recebida antes que este tempo expire:

|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

Com base na negociação inicial do UAC/UAS (User Agent Client/User Agent Server), um dos pontos de extremidade atualiza a sessão quando envia um Re-INVITE. Se o atualizador for UAC, o iniciador da chamada terá a responsabilidade de atualizar a sessão. Se o atualizador for UAS, o servidor terá que atualizar a sessão. Colete os logs de depuração SIP de ambos os pontos de extremidade e verifique estes itens:

Exemplo: Chamada feita do participante A para o CUCM para o participante B. Se o atualizador for UAC na Parte A e UAS na Parte B:

1. A Parte A deve enviar o CONVITE/ATUALIZAÇÃO novamente para o CUCM.
2. O CUCM precisa enviar um CONVITE/ATUALIZAÇÃO novamente para o participante B.
3. A Parte B recebe o re-INVITE e responde a essa mensagem com um 200 OK.
4. O CUCM precisa enviar 200 OK ao participante A.

Se um endpoint enviar a mensagem re-INVITE para o CUCM, o CUCM enviará um re-INVITE para o outro participante. No entanto, se isso não for recebido pelo lado remoto, isso pode ser devido a alguns dispositivos de rede intermediários. É altamente possível que o re-INVITE/response não chegue para um dos lados devido à inspeção SIP ou às configurações de rede.

Se os pontos de extremidade não iniciarem o CONVITE novamente, pode haver um problema com o ponto de extremidade. Envolva o Cisco Technical Assistance Center (TAC) para investigar mais.

Problema: A chamada H.323 cai após qualquer horário específico

Como no SIP, em chamadas H.323, as quedas de chamada em um intervalo de tempo específico ocorrem geralmente devido à configuração de tempo limite de rede ou firewall.

Solução

Em chamadas H.323, uma mensagem RTDR (Round Trip Delay Request) é enviada a cada 30 segundos entre os pontos finais juntamente com os números de sequência . Espera-se uma resposta para cada solicitação.

O Cisco Endpoint utiliza a mensagem RTDR/Round Trip Delay Response, que faz parte da Mensagem de Controle do Sistema Multimídia H.245. Isso mantém a sessão TCP H.245 ativa durante a chamada que é usada para o gerenciamento de chamadas ativo. Se o ponto final receber uma resposta para RTDR inicialmente e nenhuma resposta for recebida durante a chamada, o ponto final encerrará a chamada.

Neste cenário, colete os logs de depuração H.323 e os logs de endpoint para isolar o problema. Nos registros de depuração H.323, verifique as mensagens de solicitação e resposta RTDR e descubra se ele cai.

Nesta saída de exemplo, o ponto final envia uma solicitação RTDR ao ponto final remoto e não recebe uma resposta da extremidade remota. Portanto, ela desconecta a chamada:

 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

As solicitações e respostas podem ser rastreadas com sequenceNumbers.

Este exemplo dos logs de endpoint mostra a causa da desconexão:

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: Falha de chamada devido a falha de alocação de recurso de mídia

No caso de chamadas de vídeo, as chamadas que falham devido a uma falha de alocação de recurso de mídia são vistas. Por exemplo, se o ponto de extremidade chamado e de chamada não suportar um codec comum, um transcodificador será necessário , para uma incompatibilidade de Dual Tone Multi Frequency (DTMF), um Media Termination Point (MTP) será necessário no Call Manager.

Solução

Para a transcodificação de vídeo, é necessário um transcodificador DSP (Processador de Sinal Digital) PVDM3 (Módulo Digital de Voz em Pacotes), pois os transcodificadores em PVDM2 não oferecem suporte a vídeo. Se um transcodificador/MTP não estiver disponível, uma mensagem 503 Serviço indisponível será enviada ao ponto final:

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 

Para resolver isso, verifique a configuração do Media Resource Group/Media Resource Group List (MRG/MRGL) e verifique se o transcodificador/MTP de vídeo está disponível. Uma MRGL pode ser atribuída a um dispositivo no nível do telefone ou no nível do pool de dispositivos:

1. No CallManager, escolha Device > Phone e selecione o dispositivo que tem o problema e verifique o Device Pool e as configurações MRGL:

   

2. Se a configuração MRGL no telefone for None, você terá que verificar as configurações do pool do dispositivo para verificar se há um transcodificador.
3. Escolha System > Device Pool e selecione o pool de dispositivos atribuído ao dispositivo:

   

4. Escolha Media Resources > Media Resource Group List e selecione o MRGL atribuído no nível do telefone / nível do pool de dispositivos e verifique os MRGs:

   

5. Observe os MRGs, escolha Media Resources > Media Resource Group e selecione os MRGs anotados. Certifique-se de ter um transcodificador/MTP de hardware PVDM3 adicionado.

   

Problema: Falhas de chamada devido à largura de banda insuficiente

Na maioria das vezes, há cenários em que uma chamada é desconectada devido à configuração de largura de banda insuficiente na região/local no dispositivo no CUCM. Quando a região está definida com uma largura de banda baixa que o endpoint não pode suportar, o CallManager envia uma "Mídia 488 Não Aceitável" com causa 125 que significa "Fora da Largura de Banda" ou "Largura de Banda Insuficiente" após a negociação de mídia SIP ocorrer.

Você precisa capturar os logs SIP no endpoint conforme descrito e procurar esta mensagem:

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

Solução

Se esse problema ocorrer, verifique a Região configurada nos dois pontos finais e verifique o relacionamento de Região entre eles:

1. Escolha Device > Phone e selecione ambos os dispositivos. Verifique o pool de dispositivos atribuído aos dispositivos:

   

2. Depois de verificar o pool de dispositivos, escolha System > Device Pool no CUCM e verifique a região configurada em ambos os pools de dispositivos:

   

3. Escolha Sistema > Informações da Região > Regiões e marque o Relacionamento da Região. Verifique a largura de banda de áudio e vídeo na região e certifique-se de que o endpoint possa operar na largura de banda de áudio/vídeo conforme selecionado:

   

Nas capturas de tela acima, presume-se que um endpoint esteja na região "Trunk Region" e o outro esteja na região "Endpoints locais".

Outra solução é tentar a chamada de vídeo como uma chamada de áudio se a largura de banda da chamada de vídeo for insuficiente. Use este procedimento para verificar e configurar:

1. Escolha Device > Phone e selecione o dispositivo de chamada com o problema. Verifique se o parâmetro nesta captura de tela está marcado. Se estiver desmarcada, marque-a para que uma chamada de vídeo volte para o áudio em caso de problemas de largura de banda:

   

   Esse problema pode ocorrer devido às configurações de local no CallManager .

   Os locais podem ser atribuídos no nível do telefone ou no nível do pool de dispositivos (o nível do telefone tem prioridade mais alta).

2. Para verificar as configurações de localização no nível do telefone, escolha Devices > Phones e verifique o local na chamada e no endpoint chamado:

   

   O local também pode ser aplicado no nível do pool de dispositivos. Portanto, verifique primeiro o pool de dispositivos de ambos os endpoints:

   

3. Escolha System > Device Pool. No pool de dispositivos, verifique o local atribuído nos endpoints chamador e chamado. Neste exemplo, nenhum local é atribuído no nível do pool de dispositivos. A configuração da localização do telefone é usada:

   

4. Verifique se há largura de banda suficiente configurada entre o local da chamada e o local dos pontos finais chamados. Neste exemplo, presume-se que um endpoint esteja no local de Endpoints Locais e o outro esteja no local Hub_None e que a largura de banda para áudio/vídeo e chamadas imersivas estejam configuradas como Ilimitadas:

   

Pode haver outras razões para a desconexão. Consulte a página 178 do Guia de administração de registros de detalhes de chamadas do Cisco Unified Communications Manager, versão 10.0(1) para obter os códigos de causa da desconexão.