GT VoIP – relatório de avaliação do serviço experimental

Paulo Henrique de Aguiar Rodrigues <aguiar@nce.ufrj.br>
Cesar Cavalheiro Augusto Marcondes
Fabio David
João Carlos Peixoto de Almeida da Costa

Rede Nacional de Ensino e Pesquisa (RNP)

1. Introdução
2. Infra-Estrutura Instalada
2.1. Equipamentos Utilizados
2.2. Topologia Completa do Ambiente
2.3. Softwares Envolvidos no Ambiente
2.4. Configuração de QoS nos Roteadores
3. Descrição do Serviço
4. Relatórios de Uso
4.1. Histórico da Utilização do Ambiente
4.2. Estatísticas de Uso e Perfil do Tráfego dos Gateways VoIP
5. Problemas Encontrados
6. Conclusões
Nota do editor

1. Introdução

Este relatório técnico descreve a implantação do serviço experimental de telefonia e de voz sobre IP (VoIP), instalado para atender aos participantes do 4^o. Workshop da Rede Nacional de Pesquisa (WRNP) e do 21^o. Simpósio Brasileiro de Redes de Computadores (SBRC). Os dois eventos foram realizados no Hotel Pirâmide em Natal, Rio Grande do Norte, em maio de 2003. O objetivo deste experimento foi realizar uma demonstração do serviço VoIP utilizando a estrutura da Rede Nacional de Pesquisa, com uma topologia idêntica à do futuro piloto a ser implementado pelo GT-VoIP, que envolverá várias instituições interligadas através da RNP2.

Para a implantação do piloto VoIP é necessário a instalação de equipamento gateway, que conectará o PBX da instituição participante à Internet. O piloto irá envolver diversas instituições e, no momento, estamos aguardando a chegada dos gateways que estão sendo adquiridos pela RNP. Com o uso de gateways emprestados pela Cisco, um instalado na UFRJ e o outro no hotel do evento, foi possível avaliar as configurações adequadas dos equipamentos envolvidos, bem como aspectos associados a segurança, qualidade de serviço (QoS), plano de numeração e gerenciamento (monitoração do serviço e contabilização das chamadas), necessários à implementação do serviço.

 

2. Infra-Estrutura Instalada

A idéia do experimento foi possibilitar que os usuários congressistas do WRNP/SBRC pudessem realizar e receber ligações vindas tanto da Internet como da telefonia convencional, através dos PBXs da UFRJ e do hotel do evento. Deste modo foi montado um ambiente no hotel, onde o evento estava sendo realizado, e outro, na Universidade Federal do Rio de Janeiro, conforme apresentado no esquema abaixo.

Figura 1: Esquema adotado no ambiente experimental de Voz sobre IP

 

2.1. Equipamentos Utilizados

Gateway de Voz sobre IP: Equipamento com capacidade de realizar a tradução entre a sinalização do PBX e a sinalização VoIP da Internet.

Gatekeeper: Servidor de registro, autorização e autenticação no Cenário H.323. Suas funções incluem o registro de terminais H.323, de forma que só os clientes autorizados façam uso do serviço; o mapeamento de identificadores (números de telefone E.164, URLs) para endereços IP de gateways ou terminais, para que possa ser localizado o destino das chamadas; e um controle básico de admissão de chamadas. Todos os gateways de Voz sobre IP devem se registrar no Gatekeeper, para que seus prefixos atendidos pelos PBXs conectados fiquem acessíveis.

Radius: Servidor de autenticação e contabilização. Sua função é controlar o acesso aos equipamentos VoIP e armazenar as estatísticas associadas às chamadas realizadas através dos gateways de voz. Em sua função de autenticação, este servidor previne que usuários não autorizados tenham acesso à console dos equipamentos de VoIP, ou seja, toda vez que uma mudança na configuração tiver que ser feita, o usuário terá que ser validado e autenticado previamente pelo servidor RADIUS. É importante ressaltar que esta função de autenticação não tem nenhum relacionamento com a autenticação das chamadas telefônicas IP. Sua segunda função consiste em obter as estatísticas de uso, extraindo de cada chamada parâmetros como tempo de ligação, quantidade pacotes transmitidos e perdidos, entre outros. O serviço Radius foi implementado utilizando o pacote FreeRadius 0.8.1 instalado em um PC Pentium com sistema operacional Linux Slackware.

 

2.2. Topologia Completa do Ambiente

Foram instalados dois gateways durante o evento: um roteador Cisco 2611 conectado ao PBX do hotel Pirâmide, configurado com 4 interfaces analógicas FXO (Foreign Exchange Office) e uma interface de rede ethernet (10 Mbps), configurada com o IP 200.19.164.2/24; e um segundo gateway modelo Cisco Access Gateway 4224 instalado no laboratório VoIP do Núcleo de Computação Eletrônica/UFRJ, contendo 1 interface digital E1, com suporte à sinalização CAS R2 e conectada ao PBX do NCE, e uma interface de rede FastEthernet (100 Mbps), configurada com o IP 146.164.247.200/26.

A Fig. 2 apresenta a topologia completa do ambiente experimental implantado.

Figura 2: Topologia Completa do Ambiente Experimental de Voz sobre IP

 

2.3. Softwares Envolvidos no Ambiente

Interactive Voice Response (IVR)

O desenvolvimento de um script, utilizando o suporte à linguagem TCL presente nos gateways de voz dos equipamentos Cisco, permitiu que uma mensagem audível fosse apresentada ao usuário, orientando-o sobre o uso do serviço. O usuário, ao discar para um ramal conectado ao gateway, recebia a mensagem e através da discagem normal, que também interpretada pelo IVR, podia chamar qualquer dispositivo utilizando o protocolo H.323. Esta facilidade permitiu que o serviço pudesse ser oferecido aos usuários sem alterações na configuração do PBX e sem que os usuários precisassem ter qualquer treinamento no uso do serviço.

Dentre as dificuldades enfrentadas, podemos relatar que os scripts TCL IVR só funcionam quando assinados com a ferramenta lockScript da Cisco, cuja única versão disponível é para plataforma Sun Solaris. Alternativamente, pode ser desativada a opção de verificação de assinaturas com o comando test voip scripts . No nosso ambiente, utilizamos a ferramenta lockScript, obtida do site da Cisco, para assinar o script ring.tcl.

As mensagens de áudio utilizadas no serviço IVR foram gravadas no Laboratório de Multimídia do NCE/UFRJ. (http://videolab.nce.ufrj.br/). Por restrição do gateway, os arquivos tiveram que ser codificados utilizando o padrão .au do UNIX. Na primeira bateria de testes do ambiente, verificamos que os espaços de silêncio dentro de cada mensagem foram suprimidos pelo gateway, descaracterizando a mensagem. Para solucionar este problema, colocamos um som de fundo durante a mensagem, para que não tivéssemos nenhum período de silêncio absoluto.

GnuGK

Foi utilizado no experimento apenas um Gatekeeper, localizado em Natal e instalado em um PC Desktop com sistema operacional Linux Conectiva, utilizando o software GNUGK v2.0.3. O GnuGK é um software de gatekeeper de código-fonte aberto, apresentando uma série de vantagens e flexibilidades para nosso ambiente VoIP experimental. Com ele, foi criada uma zona administrativa H.323, à qual os gateways VoIP e clientes H.323 que quisessem fazer uso do serviço deveriam se registrar. O gatekeeper pode ser configurado para permitir que somente clientes registrados possam fazer chamadas usando o(s) gateway(s) VoIP também registrados nele. Outras facilidades desta implementação de gatekeeper incluem a operação como proxy de mídia e a convivência com NATs na rede, facilitando a configuração de firewalls. O GnuGK pode, ainda limitar o registro a clientes autorizados através do endereço IP ou somente a usuários pré-cadastrados.

O GNUGK oferece uma console de gerenciamento através da porta TCP/7000, onde pode ser controlada a operação do gatekeeper, visualizados os gateways e clientes registrados e gerenciadas as chamadas em curso. Várias mensagens de console são apresentadas, incluindo o CDR (Call Detail Record), que apresenta informações sobre as chamadas, quando estas terminam.

Servidor FreeRadius

O software FreeRadius v 0.8.1 foi utilizado para implementar o serviço que permitiu manter uma descrição de todas as chamadas realizadas através dos dois gateways de voz, permitindo identificar o tempo da chamada e o tráfego gerado por cada uma. A contabilização é realizada através de informações recebidas nos CDRs (Call Detail Record), registros que podem ser enviados pelos gateways quando é iniciada ou encerrada uma chamada. O IETF (Internet Engineering Task Force) definiu, através da RFC 2866, um conjunto de atributos básico para fins de contabilização, incluindo o tempo da sessão e o tráfego (bytes e pacotes) recebido e enviado. Entretanto, os fabricantes podem incluir novos atributos aos básicos, chamados de Vendor Specific Attributes (VSA). Os gateways Cisco podem incluir VSAs que fornecem dados sobre a qualidade da chamada, como por exemplo, pacotes perdidos, pacotes atrasados, pacotes adiantados, round trip time (RTT), receive delay, entre outros.

A fim de limitar o tempo das chamadas, foi desenvolvido um script perl que controlava as chamadas através da console de gerenciamento do gatekeeper (porta TCP/7000).

Foi também desenvolvido outro script perl que permitia a visualização dos equipamentos registrados no GK, as chamadas ativas e os CDRs associados às últimas chamadas terminadas.

 

2.4. Configuração de QoS nos Roteadores

O serviço VoIP é sensível a problemas como atraso, variação no atraso (jitter) e perda de pacotes. Desta forma, é necessário que a rede onde o serviço é implementado ofereça mecanismos de QoS que tratem os pacotes de Voz com a maior prioridade possível. De acordo com as RFCs 2597 e 2598, é recomendável que o tráfego de voz seja marcado como serviço expedited forwarding (EF, DSCP 46). O tráfego associado à sinalização de voz deve ser marcado com serviço AF31, DSCP 26, para que também possa ser priorizado.

No experimento, só o roteador do PoP-RN estava preparado para dar tratamento diferenciado ao tráfego de voz. A identificação do serviço era realizada através de listas de acesso que identificavam a origem dos pacotes (IPs 200.19.164.2 e 3). Este tráfego era classificado como EF e era tratado por uma fila de baixa latência (Low Latency Queue LLQ).

No entanto, a mesma marcação foi incorretamente adotada para o tráfego de vídeo, quando o recomendável seria que este fosse classificado com o serviço AF41, DSCP34, de prioridade abaixo da de voz. É importante lembrar que o tráfego de vídeo, diferentemente do tráfego de voz, gera pacotes maiores e requer uma grande banda, podendo impactar significativamente na qualidade da voz. A voz por seu lado, gera pacotes pequenos e a banda total associada a uma sessão de voz está, em geral, abaixo de 100 Kbps.

Durante o evento, o tráfego de vídeo estava sendo roteado somente para São Paulo, não havendo competição direta com o de voz, em boa parte da rota utilizada. O restante dos roteadores, no caminho entre Natal e a UFRJ, não foram configurados com nenhuma opção de priorização de tráfego. Também não existia nenhuma priorização para o tráfego de voz no sentido UFRJ Natal, pela própria impossibilidade de suportar QoS no roteador da RNP no Rio.

Para a implantação do serviço de VoIP na RNP é recomendado o uso de duas LLQs, a primeira utilizada exclusivamente para voz e a segunda para vídeo.

 

3. Descrição do Serviço

A divulgação do serviço aos participantes do WRNP e do SBRC foi realizada através da própria página do evento e de avisos colocados em vários locais do hotel, que orientavam como fazer uso do serviço. Através da página havia a possibilidade de se cadastrar para receber um número de telefone virtual para que as ligações pudessem ser feitas de/para clientes H.323 instalados em micros. Os usuários que fizeram cadastro receberam um e-mail com instruções de como usar o serviço.

 

4. Relatórios de Uso

4.1. Histórico da Utilização do Ambiente

São apresentadas abaixo as estatísticas obtidas através dos CDRs gerados pelo gatekeeper. Foram consideradas somente as chamadas que conseguiram iniciar com sucesso, sendo expurgadas as chamadas realizadas durante os testes. Na seqüência podem ser observados os quadros contendo o número de chamadas, os tempos totais das chamadas e a média de duração de cada chamada, englobando:

• Todas as chamadas realizadas no período;
• As chamadas realizadas do Rio de Janeiro para Natal;
• As chamadas realizadas de Natal para o Rio de Janeiro;
• As chamadas realizadas de ramais da UFRJ para Natal, não incluídas nas chamadas do Rio para Natal;
• As chamadas realizadas a partir de clientes H.323 (ramais virtuais).

 

4.2. Estatísticas de Uso e Perfil do Tráfego dos Gateways VoIP

Os CDRs recebidos pelo servidor Radius relativos a todas as chamadas, incluindo as que não foram iniciadas por algum motivo, foram armazenados para análise. Com as informações recebidas, foi possível gerar um histograma com a distribuição das chamadas realizadas por dia. A maior incidência de chamadas ocorria no final do dia, entre 19:00 e 20:00 hs, quando terminavam as atividades dos eventos.

Durante o experimento foi possível observar problemas como degradação na qualidade da voz durante a chamada, normalmente sentida somente por um dos lados, e o término anormal das chamadas. Através dos dados dos CDRs foram detectados alguns fatores que poderiam explicar estes problemas. Foram analisados a princípio, o round-trip time (RTT) e a perda de pacotes, já que a qualidade de ligações VoIP é afetada diretamente por estes dois fatores. Uma chamada VoIP está associada pelo menos a dois fluxos de mídia independentes, um para cada sentido da conversa. Desta forma, a análise foi realizada nos fluxos gerados nos dois sentidos: Rio de Janeiro/Natal e Natal/Rio de Janeiro.

No sentido Natal/Rio de Janeiro foi possível observar uma perda grande no domingo (18/05/03) e na segunda (19/05/03), o que explica uma perda na qualidade da voz recebida pelos usuários no Rio de Janeiro. Após um trabalho realizado em conjunto com a equipe da RNP, foram identificados vários fluxos saindo da Natalnet que ocupavam completamente o PVC da RNP (limitado a 2.5Mbps) no sentido Natal-Rio de Janeiro. Por limitações impostas pela interface ATM do roteador Cisco do PoP-RN, não pudemos determinar precisamente a ocorrência de descartes naquele ponto, embora soubéssemos que as estatísticas de perda do tráfego de voz indicavam perdas acima de 20% e elevado RTT. As perdas poderiam estar ocorrendo por problemas de policiamento na Embratel, ou em algum ponto intermediário na rota.

A partir da noite de domingo, todo o tráfego de Natal direcionado ao gateway VoIP localizado na UFRJ passou a ser roteado por São Paulo, já que havia uma suspeita no comportamento do PVC Natal/Rio. Entretanto, foi observado que este caminho acabava sendo pior, o que pôde ser visto pelo RTT coletado nos dois sentidos. O RTT persistiu elevado na segunda-feira, o que pode ser explicado pela mudança no roteamento por São Paulo e pelo gargalo existente na rede da UFRN, cuja existência somente seria desvendada mais tarde.

Em uma reunião de emergência na noite de segunda feira, envolvendo o PoP-RNP, Natal-Net, UFRN, GT-VoIP e VT-Vídeo, o tráfego saturante foi identificado como experimento do GT-Vídeo a partir de estações de trabalho internas da UFRN, que, inadvertidamente, estavam gerando tráfego pesado de testes para vários destinos na RNP, ocupando banda além da capacidade em enlaces na UFRN e saturando a conexão para o PoP-RN. Esta geração desenfreada de tráfego estava provocando, provavelmente, descartes em switch na UFRN com entrada em portas de 100 Mbps e saída em 10 Mbps. Por este switch na UFRN estava passando todo o tráfego do hotel (inclusive o de VoIP), com exceção do tráfego de vídeo de geração local, que utilizava um PVC de 155Mbps direto com o PoP-RN. O roteamento voltou à situação original na noite de segunda-feira. Na noite da segunda-feira, todo o tráfego proveniente do hotel passou a ser roteado através do mesmo PVC dedicado anteriormente aos experimentos de vídeo, evitando a rede local da UFRN. Estas alterações puderam explicar algumas melhoras nas condições da rede. Nos outros dias, o RTT médio esteve dentro de valores mais aceitáveis em ambos os sentidos.

Ao serem removidos os fluxos saturantes na manhã de terça-feira, houve uma redução na perda de pacotes e uma melhora significativa na qualidade de voz obtida. De qualquer forma, o tratamento de filas configurado no roteador do PoP-RN deveria dar preferência aos fluxos associados a VoIP, o que não foi observado. As suspeitas sobre este comportamento estavam associadas a problemas no IOS, que só foi trocado na quarta-feira (21/05/03), e à rede ATM da Embratel, onde poderia estar havendo algum descarte em função da configuração de policing, como já mencionado.

A fim de verificar o motivo do término anormal das chamadas, foram mapeados os motivos de desconexão das chamadas VoIP através de informações obtidas do Radius. Estas informações estão ainda sendo estudadas de forma a correlacionar as chamadas terminadas de forma anormal e os motivos da desconexão.

 

5. Problemas Encontrados

Em função de suas características, os protocolos utilizados no ambiente VoIP são problemáticos quando utilizados em ambientes com firewalls e NATs, como no caso da rede montada para atender o SBRC. A solução para que o serviço VoIP pudesse funcionar corretamente foi utilizar uma rede com IPs válidos (rede 200.19.164.0/24), onde foram instalados o gateway de voz e o gatekeeper. O gatekeeper foi configurado para atuar como proxy de mídia para as máquinas internas, que eram protegidas por NAT (rede 10.249.0.0/16) e por firewall. Houve a necessidade de abrir a porta TCP/1720 do gatekeeper para a rede interna. Desta forma, era possível a comunicação de clientes da rede interna com qualquer outro na Internet, ou com um telefone ligado aos PBXs conectados.

Um dos problemas que afeta interfaces FXO conectadas a ramais de PBXs é o reconhecimento da desconexão quando termina a chamada. Em função da sinalização adotada nos ramais de telefonia tradicional, o gateway não tem como identificar o término da chamada e, por conseguinte, não libera a linha. Algumas soluções são adotadas para contornar este problema. A solução adotada no gateway instalado em Natal permitiu que o mesmo identificasse o tom de desconexão gerado pelo PBX ao término da chamada. Como estes tons variam de país para país, é necessário que o gateway seja configurado para reconhecer o tom adequado, compatibilizando-o com a configuração do PBX. Normalmente, a configuração do gateway é para reconhecer o padrão de tons adotado no Brasil. Entretanto, ao utilizar esta configuração não havia o reconhecimento dos tons gerados pelo PBX do hotel. A solução foi testar as várias opções disponíveis de configuração, só funcionando corretamente quando foi utilizado o padrão belga.

A versão de sistema operacional utilizada (Cisco IOS 12.2(13)T3) implementa a versão 4 do H.323, a qual ainda não é implementada no gatekeeper (GnuGK 2.0.3). Algumas facilidades que funcionavam em versões anteriores do IOS com o gatekeeper, deixaram de funcionar corretamente. Um exemplo é o cadastro de prefixos (tech-prefix) atendidos pelo gateway, que agora tem que ser registrado manualmente no gatekeeper. Há incompatibilidades também com o software Netmeeting da Microsoft. Neste caso, tiveram que ser desabilitadas algumas funcionalidades do gateway (comando h245 caps mode restricted).

 

6. Conclusões

O serviço foi implementado com relativo sucesso durante o evento. O retorno recebido pelos usuários era de que, apesar de alguns problemas que ocorriam, o serviço ficou acima das expectativas. Entretanto, ficou claro que o serviço VoIP é bastante sensível a problemas como o atraso e a perda de pacotes, fatores que podem afetar seriamente a qualidade da voz. Logo, dentre várias medidas, é importante que o tráfego de voz seja priorizado para que o serviço possa ser operacionalizado no backbone da RNP. Com este objetivo, é recomendável que os roteadores do backbone sejam configurados para dar um tratamento de mais alta prioridade ao tráfego de voz com um mínimo de descarte e de atraso (serviço Expedited Forwarding, DSCP 46). Uma atenção especial deve ser dada também aos fluxos de sinalização. O recomendável neste caso é trabalhar com AF31, DSCP26.

 

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004