Distribuição de vídeo e conteúdo : Cisco TelePresence Codec C40

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

18 Junho 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Feedback

Introdução

Este documento explica algumas das edições comuns da falha de chamada enfrentadas com os valores-limite do codec de Tandberg (TC) registrados ao CallManager da Cisco e às soluções sugeridas.

Contribuído por Ankita Kanyal, por Devasayee Gopalan, e por Ishan Sambhi, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

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

Como capturar H.323 debugar logs

Nota: Assegure fixam a saída da sessão do host do soquete (SSH) é capturado.

  1. O SSH no codec CLI e incorpora estes comandos:
    • o ctx H.323Packet do log debuga 9
    • registro de saída em (este outputs todos os logs à tela da sessão terminal da sessão SSH.)
  2. Comece um atendimento e recreie o problema.
  3. Incorpore o registro de saída fora e o ctx H.323Packet do log debuga fora dos comandos.

Como capturar o Session Initiation Protocol (SIP) debugar logs

Nota: Assegure-se de que saída da sessão SSH esteja capturada.

  1. O SSH no codec CLI e incorpora estes comandos:
    • o ctx SIPPacket do log debuga 9
    • registro de saída em (este outputs todos os logs à tela da sessão terminal da sessão SSH.)
  2. Comece um atendimento e recreie o problema.
  3. Incorpore o registro de saída fora e o ctx SIPPacket do log debuga fora dos comandos.

Como recolher logs do valor-limite da captação do pacote dos valores-limite TC

  1. Da Web GUI escolha diagnósticos > arquivos de registro e permita registo prolongado com captação do pacote completo.
  2. Comece um atendimento e recreie o problema. Note que a captura de pacote de informação pode somente ser permitida por 3 minutos.
  3. Da Web GUI escolha diagnósticos > arquivos de registro e transfira o arquivo e a captura de pacote de informação completos do log.

A outra informação exigida

  • Termine o fluxo de chamadas com todos os dispositivos envolvidos
  • Número chamado e chamador
  • A data e hora da edição ocorreu

Componentes Utilizados

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

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Problema: Falhas de chamada devendo chamar a edição do espaço de pesquisa (CSS) /Partition no CallManager

Os atendimentos entre dois valores-limite registrados ao gerente das comunicações unificadas de Cisco (CUCM) puderam falhar devido a uma edição CSS/Partition no CUCM.

Capture os logs de chamada do SORVO do valor-limite. Esta” mensagem "404 não encontrada aparece nos logs do SORVO do valor-limite 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

Termine estas etapas a fim verificar o CSS do valor-limite de chamada e a separação do valor-limite chamado. Assegure-se de que o CSS do valor-limite de chamada tenha a separação do valor-limite chamado.

Você pode atribuir um CSS a dispositivo e nível de linha no valor-limite:

  1. Escolha o dispositivo > o telefone, selecione o valor-limite e clique sobre a linha, e verifique o Calling Search Space (CSS) a nível de linha. Neste exemplo, nenhum CSS é configurado a nível de linha. Contudo se há um CSS a nível do número de diretório, qualquer um dos CSS tem que ter o partiton do número chamado:

  2. Verifique o CSS asigned no nível do telefone. Escolha o dispositivo > o telefone e selecione o valor-limite de chamada na pergunta:

  3. Verifique a separação do número chamado. Escolha o dispositivo > o telefone, selecione o dispositivo chamado, clique sobre a linha, e verifique a rota Partion:

  4. Depois que você verifica o Partiton e o CSS em ambos os valores-limite, verifique se o CSS do dispositivo chamando tem a separação do dispositivo chamado:

    Se não, esta podia ser a causa do” erro "404 não encontrado.

Problema: Gota do atendimento do SORVO após 15 minutos (ou após algumas horas específicas)

As gotas do atendimento em intervalos de horas específicas são causadas geralmente pelos temporizadores ou pelo TCP timeout do SORVO configurados em Firewall, Roteadores, e assim por diante.

Solução

Quando as disconexões do atendimento em exatamente 15 minutos, o problema comum considerado são o TCP timeout configurado na rede (Firewall, Roteadores) são menos do que a sessão do SORVO expira temporizador. À revelia no CallManager, a sessão do SORVO expira temporizador é ajustada a 1800 segundos.

A fim verificar isto, escolha a administração CM > o sistema > parâmetros de serviço > o serviço unificados Cisco do Cisco Call Managerprocuram - a sessão do SORVO expira temporizador.

Todos os valores-limite registrados a CUCM usam este temporizador. Quando o valor-limite está no atendimento com um outro ponto final remoto, um dos partidos tem que refrescar a sessão e envia um re-CONVITE ou uma ATUALIZAÇÃO. Isto refresca tem que ser enviado antes que a metade da sessão expire 15minutes do temporizador (1800/2 = 900 segundos =). Se não há nenhum mensagem de atualização recebido, o atendimento está desligado.

A verificação para o temporizador de sessão na inicial CONVIDA. Um refrescamento (CONVIDE/ATUALIZAÇÃO) deve ser recebido antes que esta vez 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

Baseado na negociação inicial do servidor IP Phone Agent de /User do cliente do agente de usuário (UAC/UAS), um dos valores-limite refresca a sessão quando envia um Re-CONVITE. Se o refresher é UAC, o iniciador do atendimento tem a responsabilidade refrescar a sessão. Se o refresher é UA, o server tem que refrescar a sessão. Recolha o SORVO debugam logs de ambos os valores-limite e verificam estes artigos:

Exemplo: Atendimento feito do partido à CUCM para party o B. Se o refresher é UAC no partido A e UA no partido B:

  1. Party A tem que enviar o re-CONVITE/ATUALIZAÇÃO ao CUCM.
  2. CUCM tem que enviar um re-CONVITE/ATUALIZAÇÃO para party o B.
  3. O partido B recebe o re-CONVITE e responde a essa mensagem com uma APROVAÇÃO 200.
  4. CUCM tem que enviar a APROVAÇÃO 200 para party o A.

Se um valor-limite envia a mensagem do re-CONVITE ao CUCM, CUCM envia um re-CONVITE ao outro partido. Contudo, se este não é recebido pelo lado remoto então isto poderia ser devido a alguns dispositivos de rede in-between. É altamente possível que o re-CONVITE/resposta não obtém a um dos lados devendo SORVER a inspeção ou as configurações de rede.

Se os valores-limite não iniciam o re-CONVITE, poderia ser um problema com o valor-limite. Envolva o centro de assistência técnica da Cisco (TAC) a fim investigar mais.

Problema: Gotas do atendimento de H.323 após algumas horas específicas

Como com SORVO, em gotas do atendimento dos atendimentos de H.323 em um intervalo de horas específicas ocorra geralmente devido à configuração do intervalo da rede ou do Firewall.

Solução

Em atendimentos de H.323, uma mensagem do pedido do retardo de round trip (RTDR) é enviada cada 30 segundos entre valores-limite junto com números de sequência. Para cada pedido, uma resposta é esperada.

O valor-limite de Cisco utiliza o mensagem de resposta do retardo de ida e volta RTDR/Round, que é parte da mensagem do controle de sistema multimídia H.245. Este keps a sessão de TCP H.245 viva durante o atendimento que é usado para o Gerenciamento de chamada ativa. Se o valor-limite recebe uma resposta para RTDR inicialmente e nenhuma resposta está recebida durante o atendimento, o valor-limite termina o atendimento.

Nesta encenação, recolha H.323 debugam logs e o valor-limite entra a ordem para isolar a edição. De H.323 debugar logs, verificação para o pedido RTDR e mensagens de resposta e encontre se deixa cair.

Nestas saídas de exemplo, o valor-limite envia um pedido RTDR ao ponto final remoto e não recebe uma resposta da extremidade remota. Desliga consequentemente o atendimento:

 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

Os pedidos e as respostas podem ser seguidos com sequenceNumbers.

Este exemplo dos logs do valor-limite mostra a causa para a 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 à falha de alocação dos recursos de mídia

No caso dos atendimentos video, os atendimentos que falham devido a uma falha do alocation dos recursos de mídia são considerados. Por exemplo, se a chamada e o valor-limite chamado não apoiam um codec comum então um transcodificador é exigido, porque má combinação da frequência do tom dual uma multi (DTMF) um Media Termination Point (MTP) é exigida no gerenciador de chamada.

Solução

Para transcoding video, um transcodificador do processador do sinal digital do módulo de Digitas da voz de pacote de informação (PVDM3) (DSP) é exigido porque os transcodificadores no PVDM2 não apoiam o vídeo. Se um Transcodificador/MTP não está disponível, um mensagem Serviço 503 Indisponível estaria enviado ao valor-limite:

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 

A fim resolver isto, para verificar a configuração da lista do grupo do grupo dos recursos de mídia/recursos de mídia (MRG/MRGL) e para assegurar o Transcodificador/MTP video está disponível. Um MRGL pode ser atribuído a um dispositivo a nível do telefone ou nível do pool de dispositivos:

  1. No CallManger escolha o dispositivo > o telefone e selecione o dispositivo que tem o problema e verifique o pool de dispositivos e os ajustes MRGL:

  2. Se o ajuste MRGL no telefone não é nenhum, a seguir você tem que verificar os ajustes do pool de dispositivos para certificar-se que há um transcodificador.
  3. Escolha o sistema > o pool de dispositivos e selecione o pool de dispositivos atribuído ao dispositivo:

  4. Escolha recursos de mídia > lista do grupo dos recursos de mídia e selecione o MRGL atribuído a nível do telefone/nível do pool de dispositivos e verifique os MRG:

  5. Note os MRG e escolha recursos de mídia > grupo dos recursos de mídia e selecione os MRG notáveis. Assegure-se de que você tenha um Transcodificador/MTP do hardware PVDM3 adicionado.

Problema: Falhas de chamada devido à insuficiente largura de banda

A maior parte da vezes há as encenações aonde um atendimento obtém desligado devido à insuficiente configuração de largura de banda na região/lugar no dispositivo em CUCM. Quando a região é ajustada a uma largura de banda baixa que o valor-limite não possa apoiar, o CallManager envia um media "488 não aceitável” com causa 125 que significa “fora da largura de banda” ou “da insuficiente largura de banda” depois que a negociação de mídia do SORVO acontece.

Você precisa o caputure que o SORVO entra o valor-limite como descrito e procura 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 esta edição acontece, verifique a região configurada em ambos os valores-limite e verifique o relacionamento da região entre eles:

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

  2. Uma vez que você verifica o pool de dispositivos, escolha o sistema > o pool de dispositivos no CUCM e verifique a região configurada em ambos os poois de dispositivos:

  3. Escolha o sistema > a informação > as regiões da região e verifique o relacionamento da região. Verifique a largura de banda video audio na região e assegure-se de que o valor-limite possa se operar largura de banda audio/video como selecionada:

Nos screenshots acima supõe-se que um valor-limite está na região do “região tronco” e o outro está dos “na região pontos finais locais”.

Uma outra ação alternativa é tentar o atendimento video como um atendimento audio se a largura de banda para a largura de banda de chamada video é insuficiente. Use este procedimento a fim verificar e configurar:

  1. Escolha o dispositivo > o telefone e selecione o dispositivo chamando com o problema. Verifique se o parâmetro neste tiro de tela é verificado. Se é desmarcado, verifique-o de modo que um atendimento video caia de volta ao áudio em caso das questões de largura de banda:

    Esta edição podia acontecer devido às configurações de local no CallManager.

    Os lugar podem ser atribuídos a nível do telefone ou a nível do pool de dispositivos (o nível do telefone toma a prioridade mais alta).

  2. A fim verificar configurações de local niveladas do telefone, escolher dispositivos > telefones e verificar o lugar em ambos que chamam e no valor-limite chamado:

    O lugar pode igualmente ser aplicado a nível do pool de dispositivos. Consequentemente, primeira verificação o pool de dispositivos de ambos os valores-limite:

  3. Escolha o sistema > o pool de dispositivos. No pool de dispositivos, verifique o lugar atribuído em ambos a chamada e os valores-limite chamados. Neste exemplo nenhum lugar é atribuído a nível do pool de dispositivos. A configuração do local do telefone é usada:

  4. Verifique se a largura de banda suficiente é configurada entre a chamada e o lugar chamado dos valores-limite. Neste valor-limite do exemplo um é suposto para estar no lugar dos pontos finais locais e outro está no lugar de Hub_None e a largura de banda para o áudio/atendimentos video e immersive todos é configurada como ilimitada:

Podia haver outras razões para a desconexão. Veja a página 178 do Guia de Administração dos registos dos destalhes da chamada do gerente das comunicações unificadas de Cisco, libere 10.0(1) para códigos de causa da desconexão.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.