Este documento aborda alguns dos problemas comuns que podem ocorrer em conversações de áudio de uma via por Telefonia IP que envolvem gateways Cisco. Os gateways Cisco abordados neste documento são os gateways e roteadores Cisco IOS®, os switches Catalyst e os gateways DT-24+.
Este documento destina-se a pessoas que estão envolvidas com redes de telefonia IP e têm conhecimento básico de redes de voz.
Este documento não é restrito a versões de software ou hardware específicas.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Este documento fornece cenários e soluções para estes problemas:
Quando uma chamada telefônica é estabelecida de uma estação IP através de um gateway de voz ou roteador do Cisco IOS, apenas uma das partes recebe áudio (comunicação unidirecional).
Quando uma chamada de desvio de tarifa é estabelecida entre dois gateways Cisco, apenas uma das partes recebe áudio (comunicação unidirecional).
Quando uma chamada telefônica é estabelecida a partir de uma estação IP colocada atrás de um VPN 3002 Hardware Client, apenas uma das partes recebe áudio (comunicação unidirecional).
As causas do áudio unidirecional na telefonia IP podem variar, mas a raiz do problema geralmente envolve problemas de roteamento IP. Esta seção analisa alguns dos cenários e soluções encontrados no campo.
Alguns gateways Cisco IOS, como o VG200, desabilitam o roteamento IP por padrão. Essa configuração padrão leva a problemas de voz unidirecionais.
Observação: antes de prosseguir, verifique se o roteamento IP está ativado no roteador. Em outras palavras, certifique-se de que o roteador não tenha o comando de configuração global no ip routing.
Para habilitar o roteamento IP, emita este comando de configuração global no gateway do Cisco IOS:
voice-ios-gwy(config)#ip routing
Sempre verifique primeiro a acessibilidade básica do IP. Como os fluxos do Protocolo de Transporte em Tempo Real (RTP - Real-Time Transport Protocol) são sem conexão (transportados sobre UDP), o tráfego pode trafegar com êxito em uma direção, mas se perde na direção oposta. Este diagrama mostra um cenário em que isso pode acontecer:
As sub-redes A e B podem alcançar a sub-rede X. A sub-rede X pode acessar as sub-redes A e B. Isso permite o estabelecimento de conexões TCP entre as estações finais (A e B) e o Cisco CallManager. Portanto, a sinalização pode chegar às duas estações finais sem nenhum problema, o que permite o estabelecimento de chamadas entre A e B.
Quando uma chamada é estabelecida, um fluxo de RTP que transporta o áudio deve fluir em ambas as direções entre as estações finais. Em alguns casos, a sub-rede B pode acessar a sub-rede A, mas a sub-rede A não pode acessar a sub-rede B. Portanto, o fluxo de áudio de A a B é sempre perdido.
Esse é um problema básico de roteamento. Use os métodos de identificação e solução de problemas de roteamento IP para chegar ao estágio em que você pode fazer ping com êxito no Telefone A a partir do Gateway B. Lembre-se de que o ping é uma verificação bidirecional.
Este documento não aborda a solução de problemas de roteamento IP. No entanto, confirme-as como algumas etapas iniciais a serem seguidas:
Os gateways padrão são configurados nas estações finais.
As rotas IP nesses gateways padrão levam às redes de destino.
Observação: esta lista explica como verificar a configuração padrão do roteador ou gateway em vários telefones IP da Cisco:
Cisco IP Phone 7910—Pressione Settings, selecione a opção 6 e pressione o volume para baixo até que o campo Default Router (Roteador padrão) seja exibido.
Cisco IP Phone 7960/40—Pressione Settings, selecione a opção 3 e role para baixo até que o campo Default Router (Roteador padrão) seja exibido.
Telefone IP da Cisco 2sp+/30vip—Pressione **# e pressione # até gtwy= aparecer.
Observação: ao usar o aplicativo Cisco IP SoftPhone e mais de uma placa de rede (NIC) estiver instalada na caixa, certifique-se de que a caixa tenha a placa de rede correta. Esse problema é comumente presente no software IP SoftPhone versão 1.1.x. A versão 1.2 deve resolver esse problema.
Observação: ao usar os gateways DT-24+ da Cisco, verifique o escopo do DHCP e certifique-se de que haja uma opção de gateway padrão (roteador 003) no escopo. O parâmetro do roteador 003 preenche o campo Default Gateway nos dispositivos e computadores. A opção de escopo 3 deve ter o endereço IP da interface do roteador que roteará para o gateway.
Se a transcodificação estiver configurada para um tronco intercluster (ICT), assegure-se de que um Ponto de Terminação de Mídia (MTP) esteja configurado no Grupo de Recursos de Mídia e na Lista de Grupos de Recursos de Mídia associados ao tronco. Se você especificar um MTP quando um não é necessário, ou não configurar um MTP se for necessário, sabe-se que ele causa problemas de voz unidirecionais para configurações de ICT.
Quando o gateway do Cisco IOS tem várias interfaces IP ativas, parte da sinalização H.323 pode ser originada de um endereço IP e outras partes dele podem referenciar um endereço de origem diferente. Isso pode gerar vários tipos de problemas. Um desses problemas é o áudio unidirecional.
Para contornar esse problema, você pode vincular a sinalização H.323 a um endereço de origem específico. O endereço de origem pode pertencer a uma interface física ou virtual (loopback). Use o comando h323-gateway voip bind srcaddr ip-address no modo de configuração de interface. Configure esse comando na interface com o endereço IP para o qual o Cisco CallManager aponta.
Este comando foi introduzido no Cisco IOS Software Release 12.1(2)T. Consulte Suporte H.323 para Interfaces Virtuais.
Cuidado: existe um bug no Cisco IOS Software Release 12.2(6) no qual essa solução pode realmente causar um problema de áudio unidirecional. Para obter mais informações, consulte o bug da Cisco ID CSCdw69681 (somente para clientes registrados) .
A voz unidirecional pode ocorrer em gateways do Media Gateway Control Protocol (MGCP) se a interface de origem para pacotes de sinalização e mídia não for especificada. Você pode vincular a mídia MGCP à interface de origem se emitir o comando mgcp bind media source-interface interface-id e o comando mgcp bind control source-interface interface-id. Redefina o gateway MGCP no Cisco CallManager depois de emitir os comandos.
Se o comando mgcp bind não estiver ativado, a camada IP ainda fornecerá o melhor endereço local.
As diretrizes para o comando mgcp bind são:
Quando há chamadas MGCP ativas no gateway, o comando mgcp bind é rejeitado para controle e mídia.
Se a interface de associação não estiver ativa, o comando será aceito, mas não entrará em vigor até que a interface seja ativada.
Se o endereço IP não estiver atribuído na interface de associação, o comando mgcp bind será aceito, mas entrará em vigor somente depois que um endereço IP válido for atribuído. Durante esse período, se as chamadas MGCP estiverem ativas, o comando mgcp bind será rejeitado.
Quando a interface vinculada fica inativa, por causa de um desligamento manual na interface ou por causa de uma falha operacional, a atividade de ligação é desabilitada nessa interface.
Quando a associação não está configurada no Media Gateway Controller (MGC), o endereço IP usado para o controle e a mídia de MGCP de origem é o melhor endereço IP disponível.
Se você tiver um gateway Cisco IOS que se conecta a uma Telco ou switch, verifique se a supervisão da resposta é enviada corretamente quando o dispositivo chamado atrás da Telco ou do switch atende a chamada. A falha ao receber a supervisão da resposta faz com que o gateway do Cisco IOS não corte (abra) o caminho de áudio em uma direção de encaminhamento. Essa falha causa voz unidirecional. Uma solução alternativa é emitir o comando voice rtp send-recv on.
Para obter mais informações, consulte Corte de Áudio Bidirecional Antecipado com o Comando voice rtp send-recv no Cisco IOS Gateway and Routers.
O caminho de voz é estabelecido na direção inversa no início do fluxo RTP. O caminho de áudio de encaminhamento não é cortado até que o gateway do Cisco IOS receba uma mensagem Connect da extremidade remota.
Em alguns casos, é necessário estabelecer um caminho de áudio bidirecional assim que o canal RTP for aberto, antes que a mensagem Connect seja recebida. Para conseguir isso, emita o comando de configuração global voice rtp send-recv.
Esse problema se aplica a cenários, como o desvio de tarifa, em que mais de um roteador ou gateway do Cisco IOS está envolvido no caminho de voz e o RTP compactado (cRTP) é usado. cRTP, ou RTP Header Compression, é um método para tornar os cabeçalhos dos pacotes VoIP menores para recuperar a largura de banda. O cRTP pega o cabeçalho IP de 40 bytes, User Datagram Protocol (UDP) ou RTP em um pacote VoIP e o comprime em 2 a 4 bytes por pacote. Essa compactação produz aproximadamente 12 kbps de largura de banda para uma chamada codificada em G.729 com cRTP. Para obter mais informações sobre cRTP, consulte Voice Over IP - Per Call Bandwidth Consumption (Voz sobre IP - Consumo de largura de banda por chamada).
O cRTP é feito salto a salto, com descompressão e recompressão em cada salto. Cada cabeçalho de pacote deve ser examinado para o roteamento. Portanto, o cRTP precisa ser ativado em ambos os lados de um link IP.
Também é importante verificar se o cRTP está funcionando conforme esperado nas duas extremidades do link. Os níveis de versão do Cisco IOS Software variam em termos de caminhos de switching e suporte a cRTP simultâneo.
Em resumo, o histórico é:
Nas versões do Cisco IOS Software anteriores ao Cisco IOS Software Release 12.0(5)T, o cRTP é comutado por processo.
No Cisco IOS Software Release 12.0(7)T, e no Cisco IOS Software Release 12.1(1)T, o suporte de switching fast e Cisco Express Forwarding (CEF) para cRTP é apresentado.
No Cisco IOS Software Release 12.1(2)T, são introduzidas melhorias no desempenho dos algoritmos.
Se você executar cRTP em plataformas do Cisco IOS Software (Cisco IOS Software Release 12.1), verifique se o bug da Cisco ID CSCds08210 (somente clientes registrados) não afeta sua versão do Cisco IOS Software. O sintoma desse bug é a falha do VoIP e do fax sobre IP em trabalhar com a compactação do cabeçalho RTP ativada.
Se você descobrir que há lapsos de relógio na interface E1 ou T1 do comando show controller {e1 comando | t1}, pode haver alguma incompatibilidade na configuração de temporização no gateway de voz. Consulte Configurações de Temporização em Plataformas Baseadas em IOS Capazes de Voz e verifique se as configurações de temporização no Gateway de Voz estão corretas.
Se você usar a NAT (Network Address Translation Conversão de Endereço de Rede), deverá atender aos requisitos mínimos de nível de software. As versões anteriores do NAT não suportam tradução de protocolo mirrado. Essas versões anteriores levam a problemas de voz unidirecionais.
Você deve executar o Cisco IOS Software Release 12.1(5)T ou posterior para gateways Cisco IOS para suportar skinny e H.323 versão 2 com NAT simultaneamente. Para obter mais informações, consulte NAT-Support do telefone IP para o Cisco CallManager.
Observação: se o Cisco CallManager usar uma porta TCP para sinalização skinny diferente da porta padrão (2000), você deverá ajustar o roteador NAT. Emita o comando de configuração global ip nat service skinny tcp port number.
O nível mínimo de software necessário para usar NAT e skinny simultaneamente em um PIX Firewall é 6.0. Para obter mais informações, consulte Cisco PIX Firewall versão 6.0.
Observação: esses níveis de software não suportam necessariamente todas as mensagens de Registro, Admissão e Status (RAS) necessárias para suporte completo do gatekeeper. O suporte de gatekeeper está fora do escopo deste documento.
O comando Cisco IOS Software voice-fastpath enable é um comando de configuração global oculto para o AS5350 e o AS5400. O comando é ativado por padrão. Para desabilitá-lo, execute o comando de configuração global no voice-fastpath enable.
Quando o comando é ativado, ele coloca em cache o endereço IP e as informações do número da porta UDP para o canal lógico que é aberto para uma chamada específica. O comando impede que o fluxo de RTP acesse a camada de aplicação. Em vez disso, os pacotes são encaminhados em uma camada inferior. Isso ajuda a reduzir marginalmente a utilização da CPU, em cenários de alto volume de chamadas.
Quando serviços suplementares como retenção ou transferência são usados, o comando voice-fastpath faz com que o roteador faça o fluxo do áudio para o endereço IP em cache e a porta UDP. As informações do novo canal lógico geradas após a retomada de uma chamada em espera ou após a conclusão de uma transferência não são consideradas. Para contornar esse problema, o tráfego deve ir constantemente para a camada de aplicação para que a redefinição do canal lógico seja levada em conta e o áudio seja transmitido para o novo endereço IP e par de portas UDP. Portanto, certifique-se de desativar o voice-fastpath para suportar serviços suplementares.
O Cisco IP SoftPhone permite que um PC funcione como um telefone Cisco IP Phone 7900 Series. Os usuários remotos que se conectam de volta à rede da empresa por meio de uma VPN (Virtual Private Network, Rede virtual privada) devem configurar algumas configurações adicionais para evitar um problema de voz unidirecional. Isso ocorre porque o fluxo de mídia precisa saber o ponto final da conexão.
A solução é configurar o endereço IP da VPN, em vez do endereço IP do adaptador de rede, nas Configurações de áudio da rede. Para obter mais informações, consulte Como usar o Cisco IP SoftPhone sobre VPN.
Um cliente de hardware Cisco VPN 3002 pode operar em dois modos: modo cliente e modo de extensão de rede (NEM). No modo cliente, todos os hosts por trás do cliente Cisco VPN 3002 são endereços de porta convertidos para o endereço IP externo do cliente VPN 3002. O H.323 não funciona com PAT (Port Address Translation Conversão de Endereço de Porta) e resulta em áudio unidirecional quando um telefone IP é colocado atrás de um cliente VPN 3002. Quando o VPN 3002 funciona no NEM, as redes remotas podem se ver através de seus endereços IP reais, não um endereço IP baseado em NAT ou em PAT. Se o VPN 3002 estiver configurado para funcionar no NEM, o H.323 poderá funcionar. Em outras palavras, os telefones IP que estão por trás de um cliente VPN 3002 só podem funcionar quando o VPN 3002 funciona no NEM. Portanto, para evitar problemas de voz unidirecional com um cliente VPN 3002, configure o cliente VPN 3002 para usar o NEM.
Para configurar o Cisco VPN 3002 Hardware Client para usar o NEM, escolha Configuration > Quick > PAT e clique em No, use Network Extension mode na janela PAT.
Para obter mais informações, consulte Configurando o Cisco VPN 3002 Hardware Client para o Cisco IOS Router com EzVPN no Network Extension Mode
Dois comandos úteis a serem usados para verificar o fluxo do pacote são o comando debug cch323 rtp e o comando debug voip rtp. O comando debug cch323 rtp exibe os pacotes que são transmitidos (X) e recebidos (R) pelo roteador. Um caractere maiúsculo indica transmissão ou recepção bem-sucedidas. Um caractere minúsculo indica um pacote descartado.
voice-ios-gwy#debug cch323 rtp RTP packet tracing is enabled voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# !--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and !--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. Mar 3 23:46:23.690: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXXrrrrrrrrrrrrrrrr voice-ios-gwy# voice-ios-gwy# !--- This is an example of an answered call: voice-ios-gwy# voice-ios-gwy# *Mar 3 23:53:26.570: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr !--- At this point, the remote end picks up the phone. *Mar 3 23:53:30.378: ****** cut through in BOTH direction ***** XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR !--- This is the end of the conversation.
Observação: no Cisco IOS Software Release 12.2(11)T e posterior, o comando debug cch323 rtp command-line interface (CLI) foi substituído pelo comando debug voip rtp.
voice-ios-gwy#debug voip rtp --------cut through in BOTH direction------------------- *Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002), pt=0, ts=4FFBF0, ssrc=8E5FC294 *Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C8D9, ssrc=1F1E5093 *Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002), pt=0, ts=4FFC90, ssrc=8E5FC294 *Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C979, ssrc=1F1E5093 *Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002), pt=0, ts=4FFD30, ssrc=8E5FC294 *Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CA19, ssrc=1F1E5093 *Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002), pt=0, ts=4FFDD0, ssrc=8E5FC294 *Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CAB9, ssrc=1F1E5093 *Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002), pt=0, ts=4FFE70, ssrc=8E5FC294 *Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CB59, ssrc=1F1E5093 *Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002), pt=0, ts=4FFF10, ssrc=8E5FC294 *Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CBF9, ssrc=1F1E5093 *Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002), pt=0, ts=4FFFB0, ssrc=8E5FC294 *Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CC99, ssrc=1F1E5093 *Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002), pt=0, ts=500050, ssrc=8E5FC294 *Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DEB9, ssrc=1F1E5093 *Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002), pt=0, ts=501270, ssrc=8E5FC294 *Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DF59, ssrc=1F1E5093 *Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002), pt=0, ts=501310, ssrc=8E5FC294 *Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DFF9, ssrc=1F1E5093
Você pode solucionar problemas de chamadas unidirecionais coletando informações de tráfego de chamadas através do PIX Firewall. O comando capture PIX pode ser usado para verificar a porta aberta e usada quando ocorre uma chamada. Consulte Lidar com Tráfego VoIP com o PIX Firewall para obter mais informações sobre o tráfego VoIP através do PIX Firewall.
Observação: certifique-se de desabilitar o comando capture depois de gerar os arquivos de captura necessários para solucionar problemas.
Esse problema só pode ocorrer em uma configuração inicial de chamada SIP de saída onde o MTP é necessário. Nesse caso, a mensagem CONVITE SIP de saída conterá uma oferta SDP. O problema pode ocorrer nestes cenários:
Chamadas de tronco SIP de saída com ponto de terminação de mídia obrigatório verificadas no tronco SIP
Chamadas entre endpoints somente IPv6 e endpoints somente IPv4
Os recursos MTP podem estar vazados intermitentemente, o que resulta em falha de chamadas SIP que exigem recursos MTP. De RTMT, os recursos MTP disponíveis chegam a 0 e as contagens de falhas de alocação MTP aumentam para cada chamada que requer um MTP. A parte SDP do CONVITE inicial conterá incorretamente a=inativo.
Siga estas etapas para resolver o problema:
Desmarque Media Termination Point Required na configuração do tronco SIP, se possível.
Se a oferta antecipada for necessária, configure a oferta antecipada, mas deixe a opção Media Termination Point Required (Ponto de encerramento de mídia obrigatório) desmarcada.
Para a implantação do IPv6, use a pilha dupla em vez de endpoints somente IPv6.
Observação: isso está documentado na ID de erro CSCtk77040 (somente clientes registrados) .
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
13-Oct-2008 |
Versão inicial |