Avaliação de Gateways VOIP

Transcrição

1 Avaliação de Gateways VOIP Paulo H. Aguiar Rodrigues [IM/NCE/UFRJ], Cesar Augusto C. Marcondes [NCE/UFRJ], Fabio David [IM/NCE/UFRJ], João Carlos Peixoto de A. da Costa [IM/NCE/UFRJ] Núcleo de Computação Eletrônica UFRJ Caixa Postal 2324, CEP Rio de Janeiro - RJ Brasil Introdução peixoto@nce.ufrj.br Área WRNP2: Aplicações em Redes Avançadas: Telefonia IP O Laboratório de Voz sobre IP (VOIP) do NCE/UFRJ participa do GT-VOIP da RNP com a responsabilidade de implementar um projeto piloto de telefonia IP no backbone RNP2, permitindo às organizações usuárias utilizar suas redes de dados para estabelecer comunicação de voz a partir de seus PBXs, telefones IP e/ou estações de trabalho. A primeira fase deste experimento envolve a utilização de gateways que irão interligar a estrutura tradicional de telefonia (PSTN) à rede IP, adaptando a sinalização VOIP à sinalização utilizada na PSTN. Os testes que estão sendo realizados visam identificar as características necessárias em um gateway VOIP, de forma a orientar a RNP e as instituições que desejarem implementar este serviço, na aquisição dos equipamentos que serão necessários. Estão sendo avaliadas as interfaces de voz analógicas disponíveis para os gateways, a sinalização suportada e as facilidades disponíveis para a diagnóstico de problemas (troubleshooting). Foram testados como gateways, roteadores Cisco 2610 e switches Alcatel OA-512, ambos configurados com portas de voz analógicas do tipo Foreign Exchange Station () e Foreign Exchange Office (). As portas de voz destes equipamentos foram conectadas a ramais analógicos de centrais telefônicas NEC, modelo NEAX 2400 IMS, e Philips, modelo Sopho is3030. Experimentos de Interoperação entre Gateways Nos experimentos, os gateways foram conectados aos dois PBXs seguindo a topologia apresentada na fig.1. A análise do comportamento dos gateways foi efetuada com o uso dos comandos de visualização e das facilidades disponíveis nos sistema operacionais dos equipamentos: os comandos show e debug, da Cisco, e os comandos view e vsx spy, da Alcatel. A análise da sinalização e dos canais de áudio foi realizada com o auxílio da ferramenta Ethereal, versão 0.9.9, e dos clientes OpenPhone[1], versão 1.7.0, e Netmeeting v3.0.1, da Microsoft. Philips Sopho is3030 Cisco 2600 NEC Neax 2400 IMS 4002 Alcatel OA Figura 1 - Topologia adotada nos testes

2 Análise da Sinalização A sinalização das chamadas e o transporte da mídia na rede IP serão baseados no conjunto de protocolos que compõe a recomendação ITU-T H.323 [2]. No experimento foi verificada a sinalização adotada pelo gateway na comunicação com gatekeepers e com outros endpoints, observando a compatibilidade com as recomendações H.225[3] e H.245[4]. Nos dois gateways testados foram observadas facilidades como o Fast Connect, H.245 tunneling e o DTMF Relay, mostrando serem compatíveis com a recomendação H.323v2. As versões mais recentes do sistema operacional da Cisco (IOS Internetworking Operating System) já suportam o H.323v4. Objetivando uma compatibilidade com os serviços tradicionais de centrais telefônicas, é prevista a transferência de chamadas entre endpoints H.323. Este serviço pode ser efetuado utilizando uma facilidade do H.225 (facilityreason: callforwarded), ou através dos serviços suplementares H (call transfer)[5] e H (call deflection)[6]. Os dois gateways operaram corretamente com a facilidade do H.225, entretanto somente o gateway Cisco suportou o uso de serviços suplementares. Segundo a recomendação H.323, todos os endpoints, incluindo o gateway, devem suportar a codificação e decodificação da voz usando a recomendação G.711 (A-law e µ-law), sendo opcional o suporte às recomendações G.722, G.728, G.729, MPEG-1, GSM e G Os codecs (codificadores/decodificadores) G.711, G e G.729 são suportados nos dois gateways. O equipamento Cisco opera ainda com os codecs G.726 (nonstandard capability), G.728 e GSM. Com a configuração padrão, o gateway Alcatel anuncia nas mensagens H.245 todos os codecs que suporta. O gateway Cisco anuncia somente o codec G.729, sendo preciso configurar explicitamente outros codecs se estes forem necessários. A recomendação H.235 [7] define os mecanismos que permitem autenticar e encriptar os fluxos de dados H.323 entre endpoints. O gateway Alcatel não implementa nenhum destes mecanismos. O equipamento Cisco implementa somente o mecanismo password-with-hashing, usando a facilidade cryptotokens da sinalização H.225 para autenticar as mensagens RAS enviadas para o gatekeeper. Este mecanismo pode ser utilizado em conjunto com o IVR (Interactive Voice Response) para autenticar os usuários que utilizam os serviços de voz do gateway e implementar serviços de chamadas pré-pagas. Portas de Voz Analógicas Um dos pontos mais importantes na seleção do gateway é o tipo e a quantidade de interfaces de voz disponíveis. Os gateways suportam portas de voz analógicas e digitais. Nos testes foram utilizadas somente portas analógicas do tipo Foreign Exchange Station (), para conectar os telefones tradicionais, e Foreign Exchange Office (), para conectar os ramais analógicos dos PBXs. Nas portas analógicas conectadas a PBXs é possível utilizar dois tipos de sinalização para estabelecer, manter e terminar a conexão com o PBX: loop-start e ground-start. As conexões com os telefones utilizam somente a loop-start. A mudança no tipo de sinalização depende também da configuração dos PBXs, que não foi possível ser alterada durante os testes. Logo, os experimentos envolveram somente o uso de loop-start, apesar dos gateways também suportarem o ground-start.

3 Nos testes realizados nas portas conectadas a ramais do PBX, com a sinalização loop-start, foi observado um problema proveniente da forma como esta sinalização opera. existe no PBX uma forma de sinalizar à porta que o usuário terminou a chamada (colocou o telefone no gancho); como conseqüência o ramal continua ocupado mesmo não estando mais em uso. Diversos mecanismos são utilizados para corrigir este problema [8]: battery reversal, onde a polaridade da linha é invertida durante a chamada; power denial, onde a alimentação na linha é removida momentaneamente após o término da chamada; e o supervisory disconnect tone, quando o PBX envia tons específicos (Busy signal) indicando a desconexão, os quais devem ser identificados pelo gateway para liberar a linha. Os dois primeiros dependem da configuração do PBX e, como não foi possível alterá-la, não puderam ser testadas. No caso, os ramais da central Philips já estavam configurados com a opção Power Denial. O gateway da Cisco operou corretamente com este mecanismo. A identificação correta do mecanismo de supervisory disconnect tone funcionou adequadamente com as versões mais recentes do IOS. O gateway da Alcatel, apesar de prever estes mecanismos, não realizou a desconexão corretamente. Segundo informações recebidas da Alcatel, a placa VSA utilizada nos testes estava desatualizada (Hw revision A10), o que explicaria o problema. foram realizados testes com uma placa atualizada. A operação normal do gateway ao receber uma chamada VOIP é encaminhá-la a um telefone ou a um ramal do PBX, conectados a portas ou, respectivamente. No caso do PBX, o usuário que iniciou a chamada receberá um segundo tom de discagem do PBX (dial tone), quando deverá discar o ramal desejado. A segunda possibilidade é o gateway receber a sinalização de uma chamada proveniente de uma porta de voz. Neste caso, o gateway poderá se comportar de dois modos básicos [9]: Normal (comutado) - Será dado um tom de discagem para que o usuário disque o número desejado. A chamada será encaminhada de acordo com o plano de discagem definido no gateway. PLAR (Private Line Automatic Ring-Down) - Já estará associado, à porta de voz, o número do destino. A chamada será então encaminhada de acordo com o plano de discagem definido no gateway, sem que seja necessário o usuário discar qualquer número. Os dois gateways suportaram os dois modos descritos acima. Adicionalmente, o gateway da Cisco ainda implementa outros três modos de conexão: PLAR-OPX No modo PLAR, a conexão com o PBX originador da chamada é estabelecida assim que é recebida a indicação da chamada no ramal (Ring Tone). Se a chamada não for completada até o destino, seja por problemas na rede, ou porque o PBX destino não conseguiu completá-la, para o PBX origem a chamada já foi atendida. No modo PLAR-OPX, a chamada com o PBX origem só será estabelecida quando o usuário chamado atender. Caso não seja estabelecida a chamada, o PBX origem poderá ser programado para encaminhá-la para outros ramais. Este modo só está disponível em portas. Tie-line Opera de forma semelhante ao PLAR, diferindo somente na forma como dígitos adicionais são encaminhados. Nos dois modos, a chamada pode ser encaminhada para um PBX remoto, que dará um tom de discagem para o usuário origem discar o número do ramal com que deseja falar. No modo PLAR, o DTMF (Dual Tone Multi-Frequency) é encaminhado através do fluxo de áudio estabelecido (UDP/RTP), sujeito a perdas e

4 distorções, principalmente se forem utilizados codecs com maiores taxas de compressão, como o G.729. No modo tie-line, o DTMF é encaminhado através da sinalização H.245. Cisco Trunk As conexões entre PBXs ficam estabelecidas permanentemente, facilitando a sinalização entre as centrais. Facilidades de Configuração Um ponto importante é como a configuração será ativada nos equipamentos. No gateway Alcatel, apesar do mesmo aceitar comandos de configuração através da console, qualquer alteração tem que ser incluída no arquivo vsmboot.asc e só será ativada após a inicialização do equipamento. No equipamento Cisco, a configuração é ativada assim que executada através de comandos de console. Um dos requisitos do serviço de telefonia é a alta disponibilidade, logo é importante que os equipamentos sofram o menor número de interrupções, principalmente nas relacionadas à configuração. Trabalhos Futuros Os trabalhos subseqüentes incluem os testes de interfaces digitais, além do uso de uma maior variedade de gateways, a fim de manter um banco de informações que auxiliem os interessados na implementação do serviço VOIP. Bibliografia [1] OpenPhone - openphone.org/ [2] ITU-T Recommendation H.323 (1997), Packet-Based Multimedia Communications Systems. Genova, Suíca. [3] ITU-T Recommendation H (2001) Call signalling protocols and media stream packetization for packet-based multimedia communication systems. Genova, Suíca [4] ITU-T Recommendation H.245 (1998), Control protocol for multimedia communications. Genova, Suíca. [5] ITU-T Recommendation H (1997), Call Transfer Supplementary Service for H.323. Genova, Suiça. [6] ITU-T Recommendation H (1997), Call Diversion Supplementary Service for H.323. Genova, Suíca [7] ITU-T Recommendation H.235 (2000), Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals. Genova, Suiça [8] Understanding Disconnect Problem - ml [9] Cisco IOS Voice, Video, and Fax Command Reference Release 12.2T - a008011bd39.pdf

5 Anexo Resumo das funcionalidades testadas Características Cisco 2610 Alcatel AO-512 Sinalização VOIP ITU-T H.323 H.323v2, H.225v2, H.245 H.323v2, H.225v2, H.245 ITU-T H.235. A autenticação é (segurança em H.323) baseada em password-withhashing IETF SIP Codecs Suportados G.711 (A-law e u-law); G.711 (A-law e u-law). G (5300, 6300 bps e G.729 (anexo A) e G anexo A); G.726 (16, 24 e 32Kbps); G.728; G.729 (anexo A e anexo B); e GSM Suporte à facility callforward da recomendação H.225 (call transfer) Call Transfer. O suporte é limitado à (Recomendação ITU-T H.450.2) atuação como transferred e transferred-to endpoint Call Diverte (Recomendação ITU-T H.450.3) Portas Analógicas Foreign Exchange Office () VIC-2 (max. 2 VIC) VSA-2 VSA-4 (máx. 1 VSA) Foreign Exchange VIC-2 VSA-4 Station () (max. 2 VIC) VSA-8 VSA-6+2 E&M Sin alização Loop-start / Ground-start Loop-start / Ground-start Power Denial Battery Reversal (não,. Somente testado) suportado nas interfaces VIC-2-M2 Supervisory Disconnect Tone Modos de Conexão Suportados Modo Normal (comutado), PLAR, PLAR-OPX, Tie-line e Cisco Trunk Esta funcionalidade não funcionou na placa testada. Modo Normal (comutado) e PLAR