Em ambientes com Cluster de UCM integrado com um (ou vários) Clusters de UCCX devemos ter cautela em relação a versão de JTAPI que é utilizada por ambas as soluções: A versão do JTAPI precisa ser a mesma para que a integração funcione. Para quem não sabe, a integração UCM x UCCX funciona através de JTAPI. Caso queira aprender mais sobre, recomendo os seguintes links. http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/jtapi_dev/8_6_1/jtapidevguide.html http://www.oracle.com/technetwork/java/jtapi-136088.html Continuando... Ao realizar o update de versão do UCM para uma release mais recente, verifique no RELEASE NOTES da versão do update quais são as novas firmwares/plugins que serão instalados. Este exemplo é do Release Notes do update 8.6(2a)su3: http://www.cisco.com/web/software/282074295/102724/cucm-readme-862asu3.pdf Neste documento podemos ver que o update contém uma nova versão do plugin JTAPI para o UCM e desta forma teremos que atualizar o plugin nos servidores de UCCX, caso contrário, a integração não irá funcionar. Verificando a versão do JTAPI no UCCX Acesso o servidor via CLI e execute o comando #show uccx jtapi_client version Será exibido a versão que está na partição ativa (em produção) e na partição inativa do UCCX. #show uccx jtapi_client version Active:Cisco JTAPI version 8.6(2.10000)-10 Release Inactive: Cisco JTAPI version 8.5(1.10000)-1 Release Conforme exibido acima, podemos ver que no UCCX a versão do JTAPI que encontra-se na partição ativa é a 8.6(2.10000)-10, e desta forma podemos deduzir que a versão de JTAPI que o UCM possui é a mesma, senão a integração não funcionaria. Sincronizando a versão de JTAPI do UCCX com o UCM Após realizado o upgrade do UCM e tomado nota de refazer o re-sincronismo do JTAPI no UCCX, agora temos duas opções: Fazer o resync via interface WEB ou via CLI. Sincronizando o a versão do JTAPI via interface WEB Após validar o upgrade do seu UCM com sucesso, agora é hora de verificar o UCCX. Logo após efetuar o login na interface de administração do UCCX você receberá uma mensagem de erro relacionado a versão do JTAPI não estar sincronizada. Não se assuste, para corrigir isso basta ir em Subsystems >>> Cisco Unified CM Telephony >>> Cisco JTAPI Resync O sincronismo será feito (o UCCX baixa e aplica o novo client JTAPI do UCM) e será solicitado reiniciar o serviço UCCX Engine do UCCX, muito cuidado pois este é o serviço principal do UCCX, reiniciando ele ocorrerá indisponibilidade para os agentes, supervisores e principalmente para os clientes das filas de atendimento. Após este procedimento, vá novamente em Cisco JTAPI Resync e execute a verificação, deverá aparecer versões consistentes. (Sucesso total) Sincronizando a versão do JTAPI via CLI Caso o update via interface WEB não funcione (já aconteceu comigo, veja imagem acima) temos a opção via CLI. Acesse o servidor via CLI, e execute o comando utils uccx jtapi_client update o sincronismo será feito e será solicitado o restart dos serviços: #utils service restart Cisco Unified CCX Cluster View Daemon #utils service restart Cisco Tomcat ... View more

Para realizar a captura direto na interface do Voice Gateway, segue abaixo o procedimento. !Configure a captura VOICE_GATEWAY#conf t VOICE_GATEWAY(config)#ip traffic-export profile pcap mode capture VOICE_GATEWAY(conf-rite)#bidirectional VOICE_GATEWAY(conf-rite)#exit !Defina a captura na interface desejada VOICE_GATEWAY(config)#int GigabitEthernet0/1 VOICE_GATEWAY(config-if)#ip traffic-export apply pcap size 10000000 VOICE_GATEWAY(config-if)#exit VOICE_GATEWAY(config)#exit !Para iniciar a captura VOICE_GATEWAY#traffic-export inter gig 0/1 start !Para encerrar a captura VOICE_GATEWAY#traffic-export inter gig 0/1 stop !Para exportar a captura para um servidor externo VOICE_GATEWAY#traffic-export inter gig 0/1 copy tftp !Para limpar a captura do buffer VOICE_GATEWAY#traffic-export inter gig 0/1 clear Mais informações: http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t11/ht_rawip.html ... View more

Captura dos pacotes Como todos já devem saber, quando o problema é extremamente complexo e os debugs não estão sendo muito claros, devemos partir para a captura de pacotes. Ao ler sobre este termo, já nos vem a cabeça o Wireshark, sendo este o importante e famoso software de análise de protocolos. Através deste software podemos capturar todo o tráfego em uma interface para analisar as sinalizações, protocolos, etc. O intuito desde documento não será abordar o Wireshark (para isso e xiste diversos artigos na internet a fora explicando em como utilizá-lo) mas sim em QUANDO devemos fazer uma captura de pacotes para análise de problemas relacionados a VoIP. Pois bem, como dito acima, a "captura de pacotes" (em ingles o termo é conhecido como Sniffing) consiste em capturar todo o tráfego sendo transmitido ou recebido através de uma interface de redes para ser possível analisar os pacotes, mas para que essa captura seja feita é necessário algumas configurações na sua infraestrutura. Por exemplo, é necessário capturar todo o tráfego de uma interface do Switch onde um IP Phone está conectado. Para isso o administrador de redes faz o espelhamento da porta (através da feature SPAN - Switched Port Analyzer) onde o telefone está conectado para outra interface que está conectada a um computador e com o Wireshark aberto em modo de captura. No momento da captura é efetuado os devidos testes para reprodução do problema/comportamento e assim que finalizado, a captura é interrompida para iniciar a análise. Veja na imagem abaixo uma ilustração do exemplo acima. O exemplo acima demonstra uma captura de pacotes para analizar os pacotes RTP (Real-Time Protocol) trocados entre o IP Phone A e o IP Phone B. Existem várias formas de SPAN, todas abordadas neste documento oficial. Lembrando que o SPAN é aplicado em camada 2 apenas. Mas e se for necessário uma captura em um Voice Gateway que é interligado a um provedor SIP ? Bom, em casos assim podemos utilizar a feature IP Traffic Export (disponivel a partir da IOS 12.4) para capturar, e exportar para um servidor FTP, TFTP e analisar depois com o Wireshark.  Conforme exibido na imagem abaixo. Agora que já sabemos o que é e como fazer uma captura de pacotes, como devemos iniciar a análise ? Bom, primeiro deve-se ter mapeado aonde está o problema. Se o problema é relacionado a ligações ficando presas, digitos não sendo enviados, podemos deduzir que é algo relacionado a sinalização, portanto deve-se focar no protocolo SCCP ou SIP, se for problemas de one-way voice (voz em apenas um sentido da chamada) devemos checar o protocolo RTP Analisando a captura dos pacotes Agora vem a parte interessante: Analisar os pacotes capturados. Utilizando o Wireshark, abra a captura e reserve um bom tempo para analisar as informações. Felizmente o Wireshark possui diversos filtros e expressões para que a investigação seja mais rápida, e com base nestes filtros (que com certeza você encontrou em um excelente documento na internet explicando como usar o Wireshark) é possível filtrar origem, destino, tipo do pacote, protocolo etc etc etc.... Eu particularmente já tive que fazer diversas capturas para analisar chamadas voip, principalmente com problemas de One-Way Voice. Em captura de chamadas VoIP, é possivel "reconstruir" a conversa utilizando o Wireshark, sendo este  um importante recurso para validar estes problemas de "a pessoa do outro lado não me escuta, mas eu escuto ela". DICA: One Way Voice é ocasionado por Balanceamento/Roteamento indevido dos pacotes RTP ou bloqueio em regras de Firewall Para analizar os fluxos de voz presentes em sua captura com o Wireshark, vá em Telephony >> RTP >> Show All Streams Como podemos ver na imagem acima, temos 14 Streams RTP nesta captura. Cada sentido da chamada possui o seu Stream (entrada/saida). Ao selecionar um dos Streams e clicarmos em Analyze, podemos ver a origem e o destino da chamada e outras diversas informações como Jitter, perdas, etc. Ao clicarmos em Player, abrirá uma nova janela. Clique em Decode, e selecione o Stream para que o botão Play fique ativo para que você possa ouvir o áudio. Conforme exibido na imagem abaixo. Caso, sua análise forense exija que você exporte o arquivo, este poderá ser salvo em formato .raw ou .au. Exportando o áudio capturado Agora que a chamada foi capturada, analisada e exportada.... como podemos fazer para converter o arquivo .raw ou .au em WAV para que possamos ouvir o audio sem o uso do Wireshark? Simples, utilize o Audacity. No Audacity, vá em Arquivo > Importar > Dados Raw... Selecione o arquivo e em seguida insira as informações referente ao Codec utilizado na chamada. Se você não informar os dados corretamente a conversão não funcionará. Conforme exibido na imagem acima, podemos ver que o Codec é G711a-law, Little-Endian (ordem dos bytes) e a frequência de 8000Hz. Pronto, clique em importar e o áudio estará no Audacity, a partir dai você pode exportar para o formato que desejar, inclusive MP3. ... View more