Este documento aborda problemas relacionados ao progresso de chamadas in-band no entrelaçamento de ISDN e sinalização H.323 entre as redes VoIP e PSTN. Os desafios surgem quando o roteador/os gateways VoIP da Cisco trocam recursos de sinalização com o switch Telco.
É necessário ter conhecimento sobre H.323 e sobre a configuração do Cisco CallManager para compreender este documento.
Este documento usa gateways de voz do Cisco CallManager e do Cisco IOS® para a solução do problema discutido nele.
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.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Esse documento envolve questões relacionadas ao andamento de chamadas in-band no entrelaçamento de ISDN e sinalização H.323 entre redes VoIP e PSTN. Os desafios surgem quando o roteador/os gateways VoIP da Cisco trocam recursos de sinalização com o switch Telco. Esta lista descreve cenários/sintomas comuns do problema:
Sem tom de chamada de volta em chamadas de contorno de tarifa VoIP
Sintoma: Um usuário do Serviço de telefonia tradicional (POTS, Plain Old Telephone Service) (PSTN/PBX) faz uma chamada através de um roteador/gateway da Cisco e não ouve um tom de chamada de volta antes que ela seja atendida.
Sintoma: Um usuário do POTS (PSTN/PBX) faz uma chamada para um telefone IP através de um roteador/gateway da Cisco e não ouve um tom de chamada de volta antes que ela seja atendida.
Sintoma: Um usuário faz uma chamada de um telefone IP ou de um dispositivo de terceiros para um número externo através de um roteador/gateway da Cisco e não ouve um tom de chamada de volta.
Sem tom de chamada de volta para o PSTN (Cisco CallManager)
Sintoma: Quando as chamadas provêm do PSTN através do Cisco CallManager, o chamador não ouve um tom de chamada de volta. Se a chamada for atendida, ambas as partes conseguirão ouvir uma à outra ou o chamador conseguirá ouvir os alertas do correio de voz.
Sintoma: Uma chamada recebida de um gateway/roteador da Cisco para o Cisco CallManager ou o correio de voz do Cisco Unity que seja transferida depois que a chamada for atendida não ouve uma chamava de volta.
Sem tom de chamada de volta para chamadas do Cisco CallManager para o Cisco CallManager Express
Sintoma: Quando um usuário disca de um telefone IP registrado para o Cisco CallManager que é destinado a um telefone IP registrado com o Cisco CallManager Express, a chamada de volta não é ouvida. Isso ocorre mesmo que o telefone receptor toque e que a chamada seja completada.
Observação: a Cisco recomenda que você leia a seção Informações de Fundo antes de ler a seção Soluções.
O entrelaçamento é definido como o mapeamento das mensagens de sinalização de chamada entre dois conjuntos de protocolos diferentes. Este documento concentra-se em problemas de entrelaçamento de ISDN e H.323 (VoIP). Esse diagrama exibe as mensagens de sinalização de chamada no segmento de chamada ISDN (Q.931) e VoIP (H.225).
Observação: H.225 é um protocolo especificado pelo H.323 para sinalização de chamadas e configuração de chamadas. O H.225 especifica o uso e o suporte de Q.931. Consulte o Tutorial do H.323para obter mais informações sobre o H.323.
Tons de progresso in-band, como os tons de chamada de volta e de ocupado, e anúncios, como “O número que você discou não é mais válido”, são exigidos para sinalizar chamadas de voz com êxito. Os tons de progresso são gerados pelos dispositivos de origem, destino e intermediários.
A indicação de tons e anúncios in-band é controlada pelo IE (elemento de informação) do PI (Progress Indicator) em redes ISDN e H.323. O indicador de progresso sinaliza as situações de entrelaçamento em que os tons e anúncios associados devem ser utilizados. No contexto deste documento, estes são os valores de interesse do Indicador de progresso (PI, Progress Indicator) ITU Q.931:
Indicador de progresso = 1 — a chamada não é ISDN fim-a-fim. Mais informações sobre o progresso da chamada podem estar disponíveis in-band.
Indicador de progresso = 2 — o endereço de destino não é ISDN.
Indicador de progresso = 3 — o endereço de origem não é ISDN.
Progress Indicator = 8 — as informações in-band ou um padrão apropriado está agora disponível.
A indicação de que tons e anúncios estão disponíveis é sinalizada por uma mensagem de alerta, prosseguimento de chamada, progresso, conexão, reconhecimento de configuração ou desconexão que contém um indicador de progresso igual a 1 ou 8.
Quando uma mensagem de configuração chega ao gateway de origem com um PI igual a 3, o switch informa o gateway que mensagens in-band são esperadas.
Observação: a falta de um PI em uma mensagem pressupõe que o dispositivo de origem fornece a sinalização de tom apropriada para o chamador. Se você configurou o gateway para acesso direto a voz e para enviar um tom de chamada de volta, e mesmo assim não ouvir o tom de chamada de volta, é possível que o problema seja na configuração de PBX do provedor de serviços.
Observação: os circuitos PSTN de sinalização associada a canal analógico e digital (CAS) geralmente transportam as informações como informações na banda.
Corte pelo caminho da voz é a conclusão do caminho de transmissão do portador de uma chamada de voz. Em uma chamada de voz, a conclusão ocorre em dois estágios:
Transmissão direta na direção inversa — isto significa que somente o caminho de voz da parte chamada para a parte chamadora está completo.
Transmissão direta em ambos os sentidos — isto significa que o caminho de voz entre a parte chamada e a parte chamadora está completo.
Os tons e anúncios podem ser gerados no switch de origem ou de destino. Se os tons e anúncios forem gerados pelo switch de destino, o caminho de transmissão de voz na direção inversa, do switch de destino à parte chamadora, deve ser direto antes do momento em que os tons e anúncios são gerados. Uma transmissão direta antecipada do caminho inverso do portador (antes da mensagem de conexão) é necessária para transportar tons e anúncios in-band da parte chamada à chamadora e para evitar cortes na voz.
O roteador/gateway de destino da chamada da Cisco transmite diretamente o caminho de áudio na direção inversa a fim de transmitir informações in-band quando o switch ISDN de destino envia estas mensagens:
Mensagem de alerta com o PI igual a 1 ou igual a 8.
Mensagem de progresso com o PI igual a 1 ou igual a 8.
Mensagem de prosseguimento de chamada com o PI igual a 1 ou igual a 8.
Mensagem de reconhecimento de configuração com o PI igual a 1 ou igual a 8.
Mensagem de desconexão com o PI igual a 1 ou a 8.
Observação: nas interfaces CAS de terminação, o roteador/gateway da Cisco corta o áudio na direção inversa quando todos os dígitos do número chamado são enviados.
O roteador/gateway de destino da Cisco transmite diretamente o caminho de áudio em ambas as direções nestes casos:
A mensagem de conexão é recebida em uma interface ISDN.
A supervisão de resposta (fora do gancho) é recebida em uma interface de CAS.
A transmissão direta em ambas as direções pode ser configurada nos gateways com o uso do comando de configuração global do Cisco IOS voice rtp send-recv.
Nos Cisco IOS Software Releases 12.1(3)XI1 e 12.1(5)T, a indicação de progresso é alterada para oferecer um melhor entrelaçamento entre as interfaces VoIP e POTS. Isso é conseguido principalmente com a ativação e a propagação dos valores de indicação de progresso fim-a-fim que define a geração do tom de indicação de progresso.
O uso desses comandos supõe que você possua o Cisco IOS Software Releases 12.1(3a)XI5 ou 12.2(1) e posterior. Consulte Interworking Signaling Enhancements for H.323 and SIP VoIP e Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2 para obter mais informações.
Um usuário do POTS (PSTN/PBX) faz uma chamada através de um roteador/gateway da Cisco e não ouve um tom de chamada de volta antes que ela seja atendida.
Neste cenário, o switch de destino da chamada envia o tom de chamada de volta. Ele sinaliza um PI=8 ao roteador/gateway de destino da Cisco. A informação de PI é encaminhada ao gateway de origem através de uma mensagem de progresso H.225. O gateway de origem é incapaz de decodificar a mensagem de progresso. Ele não transmite diretamente o caminho de áudio inverso para permitir a transmissão dos tons de chamada de volta. Alguns cenários comuns são:
Um gateway/roteador de destino executa o Cisco IOS Software Release 12.1(3)XI/12.1(5)T ou posteriores com um gateway de origem que executa o Cisco IOS Software Release 12.1T. O gateway de origem não compreende a mensagem de progresso H.225. Ele não transmite diretamente o caminho de áudio até que a mensagem de conexão seja recebida.
Um gateway/roteador de destino da Cisco é conectado a uma interface de CAS ou analógica. Ele envia a informação de PI em uma mensagem de progresso H.225 ao gateway de origem. O roteador/gateway de origem é incapaz de decodificar a mensagem de progresso H.225.
Os gateways e gatekeepers de origem de terceiros não analisam corretamente as mensagens de progresso H.225.
O switch ISDN envia uma chamada de volta in-band, mas a mensagem de alerta não contém um PI.
Tente qualquer uma destas soluções:
Configure o comando de configuração global do Cisco IOS voice call send-alert no gateway/roteador de destino.
Este comando permite que o gateway de destino envie uma mensagem de alerta em vez de uma mensagem de progresso depois de receber uma configuração de chamada.
Atualize o Cisco IOS Software no roteador/gateway de origem para o Cisco IOS Software Release 12.11(3a)XI/12.1(5)T ou posterior.
Se a solução anterior não funcionar, configure o gateway de terminação para enviar um PI = 8 na mensagem de alerta configurando o comando progress_ind alert enable 8 na configuração voice dial-peer # pots.
Esse comando substitui o valor de PI recebido na mensagem de alerta ISDN. Ele faz com que o roteador transmita diretamente o caminho de áudio de volta em direção à parte chamadora antes da conexão.
Observação: os comandos progress_ind alert e progress_ind setup estão ocultos em algumas versões do Cisco IOS Software e podem não estar visíveis no analisador de ajuda. No entanto, se o comando progress_ind progress estiver disponível no analisador de ajuda, esses comandos também estarão disponíveis e poderão ser inseridos no dial peer por inteiro. Esses comandos aparecem subsequentemente na configuração de execução.
Um usuário do POTS (PSTN/PBX) faz uma chamada para um telefone IP através de um roteador/gateway da Cisco e não ouve um tom de chamada de volta antes que ela seja atendida.
Isso é causado geralmente quando a chamada recebida não chega ao roteador/gateway da Cisco com um PI=3. Os switches ISDN enviam o PI=3 na mensagem de configuração para informar o gateway de que a chamada de origem não é ISDN e que mensagens in-band são esperadas. Esse cenário também é descrito em Chamadores de PSTN que não ouvem nenhuma chamada de volta quando fazem uma chamada para telefones IP.
Realize uma destas soluções:
Configure o comando progress_ind setup enable 3 do Cisco IOS com a configuração de VoIP voice dial-peer # no gateway/roteador da Cisco.
Esse comando força o gateway/roteador a tratar a mensagem de configuração ISDN de entrada como se tivesse chegado com um PI igual a 3 e a gerar um tom de chamada de volta em direção à parte chamadora se a mensagem de alerta H.225 não contiver um PI igual a 1, 2 ou 8.
Observação: os comandos progress_ind alert e progress_ind setup estão ocultos em algumas versões do Cisco IOS Software e não estão visíveis no analisador de ajuda. No entanto, se o comando progress_ind progress estiver disponível no analisador de ajuda, esses comandos também estarão disponíveis e serão inseridos no dial peer por inteiro. Esses comandos aparecem subsequentemente na configuração de execução.
Uma alternativa ao comando progress_ind setup é o subcomando tone ringback alert-no-pi do comando dial-peer voice # voip.
Isso faz com que o gateway gere uma chamada de volta em direção à parte chamadora se um aleta for recebido no segmento de chamada IP sem nenhum PI. É diferente do comando progress_ind setup porque a mensagem de configuração H.225 de saída não contém um PI de 3 com o comando tone ringback. É possível que alguns dispositivos não aceitem mensagens de configuração quando um PI estiver incluído.
Um usuário faz uma chamada de saída de um telefone IP para o PSTN através de um roteador/gateway Cisco IOS e não ouve um tom de chamada de volta.
Nessa situação, o dispositivo de origem espera tons de chamada de volta in-band. Em vez disso, uma das seguintes opções poderá acontecer:
O PSTN/switch não fornece o tom de chamada de volta.
O roteador/gateway do Cisco IOS não transmite diretamente o áudio ao dispositivo de origem.
Se o PSTN fornecer uma chamada de volta in-band e a mensagem de alerta Q.931 não fornecer um PI que indique que haja informações in-band, o gateway não transmitirá diretamente o áudio até que a chamada seja conectada.
Realize uma destas soluções:
Os tons de chamada de volta devem vir do PSTN para os circuitos de tronco nessa situação. Há dois subcomandos de dial-peer que podem ajudar. No roteador/gateway do Cisco IOS com o comando de saída voice dial-peer # pots, configure estes comandos: .
progress_ind alert enable 8 progress_ind progress enable 8 progress_ind connect enable 8
O comando progress_ind alert enable 8 apresenta a mensagem de alerta Q.931 ao software no roteador/gateway como se ela tivesse um PI igual a 8 e transmite diretamente o caminho de áudio. Consulte Configuração do indicador de progresso em dial peers de POTS H.323 para obter mais informações.
Observação: os comandos progress_ind alert e progress_ind setup estão ocultos em algumas versões do Cisco IOS Software e podem não estar visíveis no analisador de ajuda. No entanto, se o comando progress_ind progress estiver disponível no analisador de ajuda, esses comandos também estarão disponíveis e poderão ser inseridos no dial peer por inteiro. Esses comandos aparecem subsequentemente na configuração de execução.
Se o comando anterior não resolver o problema, nos Cisco IOS Software Releases de 12.2(1) to 12.2(2)T e posteriores, configure o comando progress_ind setup enable 3 com a configuração voice dial-peer # pot.
Esse comando faz com que o gateway envie um PI com um valor de 3 na mensagem de configuração ISDN. Isso indica ao PSTN/PBX que o dispositivo de origem não é um dispositivo ISDN e que informações in-band precisam ser apresentadas. Recomenda-se que esse comando seja usado em conjunto com o comando progress_ind alert enable 8.
Se o dispositivo PSTN não puder gerar uma chamada de volta in-band (por exemplo, um telefone ISDN conectado diretamente a uma porta BRI no gateway), o gateway poderá ser configurado para gerar uma chamada de volta no segmento da chamada IP configurando o comando tone ringback alert-no-pi no dial-peer voice # pots.
Quando o alerta ISDN é recebido sem o PI, o gateway gera a chamada de volta e inclui um PI=0x8 na mensagem de alerta H.225.
Quando as chamadas provêm do PSTN através do Cisco CallManager, o chamador não ouve um tom de chamada de volta. Se a chamada for atendida, ambas as partes conseguirão ouvir uma à outra ou o chamador conseguirá ouvir os alertas do correio de voz.
Para resolver esse problema, defina o parâmetro de serviço Disable Alerting Progress Indicator para False no Cisco CallManager. Você pode fazer isso ao fazer login na página de administração do Cisco CallManager e seguir estas etapas:
Vá até o menu Service e selecione Service Parameters na página de administração do Cisco CallManager.
Escolha o serviço Publisher CallManager Server e Cisco CallManager.
Mova a barra de rolagem para baixo até Disable Alerting Progress Indicator na seção Clusterwide Parameters (Device - PRI and MGCP Gateway). Ajuste esse parâmetro para False e clique em Update.
Quando uma chamada para um telefone IP é atendida e, em seguida, transferida, o chamador não ouve uma chamada de volta. Quando a chamada transferida é atendida, ambas as partes podem ouvir uma à outra.
Da perspectiva do roteador/gateway do Cisco IOS, a chamada é completada quando é atendida por um telefone IP (através do Cisco CallManager) ou pelo sistema de correio de voz do Cisco Unity. Qualquer outro tom de progresso (em caso de transferência de chamada) precisa ser gerado pelo dispositivo de destino. Contudo, o Cisco CallManager e o Cisco Unity não podem gerar os tons de progresso in-band.
Para resolver esse problema, siga as etapas destacadas aqui ou configure o roteador/gateway do Cisco IOS como um gateway MGCP em vez de um gateway H.323.
ToSend H.225 User Info Message: Este parâmetro especifica se o Cisco CallManager envia uma mensagem de informação do usuário H.225 ou uma mensagem de informação H.225.
Primeiramente você deve ter o Cisco CallManager 3.0 (8) ou posterior.
Na página de administração do Cisco CallManager (http://<Your Cisco CallManager name or IP address>/ccmadmin/), vá para o menu Service. Selecione Service Parameters.
Siga estas etapas para cada servidor Cisco CallManager ativo:
Na caixa Configured Services, escolha Cisco CallManager.
Na caixa da lista suspensa Parameter, escolha ToSendH225UserInfoMsg.
Defina a caixa da lista suspensa Value para T para verdadeiro (do inglês "true").
Atualize o roteador/gateway para Cisco IOS Software Release 12.2 (2.4) ou posterior.
Esse problema é documentado na ID de bug CSCds11354 da Cisco (apenas para clientes registrados).
Observação: essas correções são válidas para tons de chamada de volta, mas não para outros tons de progresso, como sinal de ocupado.
Observação: algumas alterações feitas nas opções disponíveis para ToSendH225UserInfoMsg nas versões posteriores do Cisco CallManager 3.3 e 4.0 estão listadas na próxima seção.
O Cisco CallManager 3.3 tem estas opções:
No Ring Back— a mensagem de informação do usuário H.225 ou a mensagem de informação H.225 não é enviada ao gateway do Cisco IOS para reproduzir um tom de chamada de volta.
User Info for Ring Back Tone — envia a mensagem de informação do usuário H.225 ao gateway do Cisco IOS para reproduzir o tom de chamada de volta.
H.225 Info for Ring Back — a mensagem de informação H.225 é enviada ao gateway do Cisco IOS para reproduzir o tom de chamada de volta.
Observação: o Cisco CallManager versão 3.1 não tem suporte para a mensagem de informações H.225. Escolha a opção User Info for Ring Back Tone se você usar troncos intercluster e qualquer um dos clusters executar a versão 3.1 do Cisco CallManager ou uma versão posterior. Contudo, se todos os clusters executarem o Cisco CallManager 3.2(2a) ou uma release posterior, escolha a opção H225 Info for Ring Back. Padrão: User Info for Ring Back Tone.
O Cisco CallManager 4.0 tem estas opções:
No CallManager da Cisco 4.0, este parâmetro especifica qual mensagem o Cisco CallManager envia como tom de chamada de volta ou tom de espera.
Use ANN for Ring Back — usa o Cisco Signaling Connection Control Part (SCCP) Annunciator para reproduzir um tom de chamada de volta (disponível no Cisco CallManager release 4.0 e posteriores).
User Info for Call Progress Tone — envia uma mensagem de informação do usuário H.225 ao gateway do Cisco IOS para reproduzir um tom de chamada de volta ou um tom de espera (esta é a opção padrão).
H.225 Info for Call Progress Tone — envia uma mensagem de informação H.225 ao gateway do Cisco IOS para reproduzir um tom de chamada de volta ou um tom de espera.
Quando um usuário disca de um telefone IP registrado para o Cisco CallManager que é destinado a um telefone IP registrado com o Cisco CallManager Express, a chamada de volta não é ouvida. Isso ocorre mesmo que o telefone receptor toque e que a chamada seja completada.
Para resolver esse problema, adicione estes comandos ao dial-peer VoIP que aponte para o Cisco CallManager a partir do Cisco CallManager Express:
Adicione o comando incoming called-number ao dial-peer VoIP que aponte para o Cisco CallManager.
Adicione o comando delay transport-address, que força o telefone IP a criar um tom de chamada de volta no mesmo dial-peer.
Observação: esse comando pode ser ocultado em algumas versões do Cisco IOS.
Consulte Ativação do entrelaçamento com o Cisco CallManager para obter mais informações.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
27-Nov-2005 |
Versão inicial |