Documento de Avaliação do Ambiente Experimental de VOIP durante o 4 o. WRNP e 21 o. SBRC: Descrição, Resultados, Problemas

Transcrição

1 GT-VOIP Relatório P4.1: Documento de Avaliação do Ambiente Experimental de VOIP durante o 4 o. WRNP e 21 o. SBRC: Descrição, Resultados, Problemas Paulo Henrique de Aguiar Rodrigues, Cesar Cavalheiro Augusto Marcondes, Fabio David, João Carlos Peixoto de Almeida da Costa Junho de 2003 Este relatório consiste da descrição e da análise dos resultados do ambiente de demonstração VOIP montado pelo GT-VoIP durante o Workshop da RNP e o Simpósio Brasileiro de Redes de Computadores em Natal, em maio de RNP/REF/0204

2 Sumário 1. Introdução Infra-Estrutura Instalada Equipamentos Utilizados Topologia Completa do Ambiente Softwares Envolvidos no Ambiente Configuração de QoS nos Roteadores Descrição do Serviço Relatórios de Uso Histórico da Utilização do Ambiente Estatísticas de Uso e Perfil do Tráfego dos Gateways VOIP Problemas Encontrados Conclusões Anexos GT-VoIP Relatório P4.1 2

3 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 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. Fig.1 Esquema adotado no ambiente experimental de Voz sobre IP GT-VoIP Relatório P4.1 3

4 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 instalado em um PC Pentium com sistema operacional Linux Slackware Topologia Completa do Ambiente A Fig. 2 apresenta a topologia completa do ambiente experimental implantado. 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 /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 /26. GT-VoIP Relatório P4.1 4

5 Fig.2 - Topologia Completa do Ambiente Experimental de Voz sobre IP Configuração do gateway da UFRJ Configuração da controladora E1 para utilizar a sinalização E1/R2, padrão Brasil (CAS) Foram utilizados somente 12 canais em função do número de DSPs disponíveis no gateway. Todos os canais estavam associados ao ramal 3000 do PBX ( ) controller E1 2/0 framing NO-CRC4 ds0-group 1 timeslots 1-12 type r2-digital r2-compelled ani cas-custom 1 country brazil answer-signal group-b 1 Configuração da Interface Fast Ethernet. Definição do Gatekeeper onde o gateway irá se registrar ( ) com o ID UFRJ-VOIP-E1 interface FastEthernet0/0 ip address h323-gateway voip interface h323-gateway voip id NATALGK ipaddr h323-gateway voip h323-id UFRJ-VOIP-E1 h323-gateway voip bind srcaddr Configuração do plano de discagem Direcionar para o gatekeeper (NATAL) Direcionar para o PBX conectado à porta E1 (discagem direta ao ramal) Direcionar para o PBX conectado à porta E1 (discagem direta ao ramal) 21 Direcionar para o PBX conectado à porta E1 (acrescentar prefixo 0 para GT-VoIP Relatório P4.1 5

6 selecionar linha externa). dial-peer voice 10 pots preference 5 application ring destination-pattern port 2/0:1 prefix 0 dial-peer voice 11 pots preference 1 destination-pattern port 2/0:1 dial-peer voice 12 voip destination-pattern session target ras no vad dial-peer voice 51 pots preference 1 destination-pattern port 2/0:1 gateway Configuração do gateway de Natal Configuração das porta de voz FXO. Os ramais 781, 782, 783 e 784 estavam associados às porta 1/0/0, 10/1, 11/0 e 1/1/1, respectivamente Configurada desconexão na porta ao identificar término da chamada. Foi utilizado o cptone BE (Bélgica) para compatibilizar com o PBX do hotel. voice-port 1/0/0 cptone BE timeouts call-disconnect 1 supervisory disconnect dualtone mid-call no battery-reversal voice-port 1/0/1 cptone BE timeouts call-disconnect 1 supervisory disconnect dualtone mid-call no battery-reversal voice-port 1/1/0 cptone BE timeouts call-disconnect 1 supervisory disconnect dualtone mid-call GT-VoIP Relatório P4.1 6

7 voice-port 1/1/1 cptone BE timeouts call-disconnect 1 supervisory disconnect dualtone mid-call Configuração da Interface Ethernet. Definição do Gatekeeper onde o gateway irá se registrar ( ) com o ID VOIP-NATAL, respondendo pelo prefixo interface Ethernet0/0 ip address h323-gateway voip interface h323-gateway voip id NATALGK ipaddr h323-gateway voip h323-id VOIP-NATAL h323-gateway voip tech-prefix Configuração do plano de numeração prefixo 21 direciona para o gatekeeper (destino Rio de Janeiro) prefixo direciona para as portas FXO Configuração IVR Application ring (olhar capítulo especifico) dial-peer voice 20 pots application ring destination-pattern port 1/1/0 dial-peer voice 21 pots application ring destination-pattern port 1/1/1 dial-peer voice 22 pots application ring destination-pattern port 1/0/0 dial-peer voice 23 pots application ring destination-pattern port 1/0/1 dial-peer voice 16 voip destination-pattern session target ras dtmf-relay h245-alphanumeric no vad Na estrutura montada, o gateway da UFRJ respondeu pelo prefixo 21 (ligações para o Rio de Janeiro), enquanto que o do hotel, pelo GT-VoIP Relatório P4.1 7

8 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. A configuração do gateway para que seja utilizado o script ring.tcl é apresentada a seguir. O código fonte do script é apresentado no anexo 1. Configuração do script IVR TCL nos gateways de VOZ Cisco ## Definição da aplicação ring, cujo carga do código (script TCL) será feita a partir do servidor ## TFTP Router(config)# call application voice ring tftp:// /tcl/ring.tcl ## Configuração do Dial-Peer 1 pots para acionar automaticamente o IVR quando receber ## ligações através da porta de voz 2/0:1 (CAS-group 1 associado à controladora E1 2/0) ## Esta porta está associada ao ramal 3000 no PBX da UFRJ Router(config)# dial-peer voice 1 pots application ring port 2/0:1 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. ( 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. As mensagens de voz adotadas no ambiente seguiram os seguintes textos: Texto 1 (arquivo welcome.au) Bem-vindo ao Sistema Experimental de Telefonia sobre IP do GT-VOIP Maiores informações podem ser obtidas no site Todas as chamadas estão sendo contabilizadas, e existe um tempo máximo de utilização por chamada. Aproveite o serviço. Após o sinal disque o número desejado. GT-VoIP Relatório P4.1 8

9 Texto 2 (arquivo (user_busy.au) Número Ocupado, por favor tente mais tarde. Acesse nosso website ( para saber mais informações sobre o uso GnuGK No experimento foi utilizado apenas um Gatekeeper, localizado em Natal e instalado em um PC Desktop com sistema operacional Linux Conectiva utilizando o software GNUGK v 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. Configuração do GnuGK durante o evento WRNP/SBRC [Gatekeeper::Main] Fourtytwo=42 # Aqui temos o Identificador do Gatekeeper = NATALGK Name=NATALGK [RoutedMode] # Para uma análise de problemas durante o evento, optamos por redirecionar toda a # sinalização H.225/H.245 através do Gatekeeper, facilitando a configuração do # Firewall GKRouted=1 H245Routed=1 AcceptNeighborsCalls=1 AcceptUnregisteredCalls=1 SupportNATedEndpoints=1 [Proxy] # O gatekeeper foi configurado para atuar como proxy, de forma que todo o tráfego H.323 # proveniente ou destinado à rede interna ( ) passasse necessariamente através # do gatekeeper, possibilitando uso de H.323 através do NAT. É necessário que o # gatekeeper tenha conectividade com a rede interna, seja através de conexão direta, # ou através de roteamento Enable=1 ProxyForNAT=1 ProxyForSameNAT=0 InternalNetwork= /16 # Esta seção mapeia estaticamente prefixos ao gateway que será utilizado para # alcança-los. Esta configuração é necessária com as versões mais recentes de IOS GT-VoIP Relatório P4.1 9

10 # Cisco registrados no gnugk (o problema ocorre porque o gnugk ainda não interpreta # corretamente as mensagens enviadas pelo Cisco (H.323 versão 4). [RasSrv::GWPrefixes] VOIP-NATAL= UFRJ-VOIP-E1=21;212598; # Nesta seção temos os endereços IPs dos Gateways e Clientes H.323 autorizados # a usar o ambiente VoIP Demo durante o evento # Endereços IP fora desta faixa automaticamente recebem uma rejeição no seu registro [RasSrv::RRQAuth] VOIP-NATAL=sigip: :1719 VOIP-UFRJ=sigip: : = sigip: : = sigip: : = sigip: : = sigip: : = sigip: : = sigip: : = sigip: :1719 default=reject # Limitamos o acesso à console de gerenciamento do gatekeeper (porta TCP 7000) # Foi permitido o acesso a qualquer máquina da rede [GkStatus::Auth] rule=regex regex=^200\.19\.164\. # O Gatekeeper vizinho é o DGK (Directory Gatekeeper) que permite realizar ligações # internacionai. [RasSrv::Neighbors] UFRJGK= :1719;00 [RasSrv::LRQFeatures] AlwaysForwardLRQ=1 # Mensagens ARQ e RRQ podem ser autenticadas através do protocolo H.235 com o # uso de senhas, se o cliente tiver suporte a esta funcionalidade, ou através das regras # definidas na seção RasSrv::RRQAuth. O cadastro das senhas pode ser realizado # através do programa addpasswd [Gatekeeper::Auth] SimplePasswordAuth=optional;RRQ;ARQ AliasAuth=required;RRQ default=allow # Habilitamos o mecanismo de análise destino para limitar as ligações para celulares # locais, cujas regras estão na seção CallTable [Gatekeeper::DestAnalysis] default=allow GT-VoIP Relatório P4.1 10

11 # Aqui temos as regras de permissão e negação dependendo do número discado [CallTable] =allow ipv4:0/0 21=allow alias:^77.* allow ipv4:0/0 # ligação local = permitida para qualquer IP 219=deny ipv4:0/0 # ligação para celular local = proibida para qualquer IP 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. Exemplo das Estatísticas Coletadas pelo GnuGK ao longo do evento: CDR d 56 f1 87 c6 11 d cd a5 4d 5c c Sat, 17 May :47: Sat, 17 May :47: : _endp :1721 oz_1008_endp :dialedDigits 782: dialeddigits=voip-natal:h323_id NATALGK; Onde: CDR = Call Detail Record 111 = Call number 91 7d 56 f1 87 c6 11 d cd a5 4d 5c c3 69 = Call ID Sat, 17 May :47:19 = Data /Hora do início da chamada Sat, 17 May :47:58 = Data /Hora do término da chamada :1720 = Endereço IP do terminal chamador :1721 = Endereço IP do terminal chamado = Número telefônico chamado 782 = Número telefônico do chamador Servidor FreeRadius O software FreeRadius v 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. para coletar estas informações foram utilizados os comandos a seguir na configuração dos gateways: (config)#gw-accounting aaa (config-gw-accounting-aaa)# acct-template callhistory-detail As informações básicas obtidas pelo FreeRadius provenientes dos gateways de voz podem ser vistas a seguir, as quais incluem atributos definidos pelo IETF e VSAs (informações H.323). GT-VoIP Relatório P4.1 11

12 Acct-Session-Id = "000003F6" h323-setup-time = "h323-setup-time=.06:29: BRST Wed May " h323-gw-id = "h323-gw-id=voip-natal." h323-conf-id = "h323-conf-id=973ad848 8AA511D7 82F3CC5B BEEA20B3" h323-call-origin = "h323-call-origin=originate" h323-call-type = "h323-call-type=voip" Cisco-AVPair = "h323-incoming-conf-id=973ad848 8AA511D7 82F3CC5B BEEA20B3" Cisco-AVPair = "subscriber=regularline" Cisco-AVPair = "session-protocol=cisco" h323-connect-time = "h323-connect-time=.06:30: BRST Wed May " Acct-Input-Octets = Acct-Output-Octets = Acct-Input-Packets = 2071 Acct-Output-Packets = 9104 Acct-Session-Time = 182 h323-disconnect-time = "h323-disconnect-time=.06:33: BRST Wed May " h323-disconnect-cause = "h323-disconnect-cause=1b" h323-remote-address = "h323-remote-address= " Cisco-AVPair = "release-source=1" h323-voice-quality = "h323-voice-quality=9" Detalhes Específicos Coletados pelos CDRs gerados pelos equipamentos Cisco (AVPairs) Cisco-AVPair = "remote-media-address= " Cisco-AVPair = "outgoing-area=natalgk" Cisco-AVPair = "gw-final-xlated-cdn=21xxxxxxxx" Cisco-AVPair = "gw-final-xlated-cgn=783" Cisco-AVPair = "charged-units=0" Cisco-AVPair = "disconnect-text=destination out of order (27)" Cisco-AVPair = "peer-address=21xxxxxxxx " Cisco-AVPair = "info-type=speech" Cisco-AVPair = "peer-id=16" Cisco-AVPair = "peer-if-index=21" Cisco-AVPair = "logical-if-index=0" Cisco-AVPair = "codec-bytes=20" Cisco-AVPair = "coder-type-rate=g729r8" Cisco-AVPair = "ontime-rv-playout=39780" Cisco-AVPair = "remote-udp-port=1721" Cisco-AVPair = "remote-media-udp-port=19280" Cisco-AVPair = "vad-enable=disable" Cisco-AVPair = "receive-delay=57 ms" Cisco-AVPair = "round-trip-delay=74 ms" Cisco-AVPair = "hiwater-playout-delay=70 ms" Cisco-AVPair = "lowater-playout-delay=57 ms" Cisco-AVPair = "gapfill-with-interpolation=0 ms" Cisco-AVPair = "gapfill-with-prediction=80 ms" Cisco-AVPair = "gapfill-with-redundancy=0 ms" Cisco-AVPair = "gapfill-with-silence=20 ms" Cisco-AVPair = "early-packets=1" GT-VoIP Relatório P4.1 12

13 Cisco-AVPair = "late-packets=0" Cisco-AVPair = "lost-packets=3" User-Name = "783" Acct-Status-Type = Stop Calling-Station-Id = "783" Called-Station-Id = "21XXXXXXXX " Service-Type = Login-User NAS-IP-Address = Acct-Delay-Time = 0 Client-IP-Address = Timestamp = 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). O código desse script é apresentado abaixo: Código-Fonte do script KillConn.pl #/usr/sbin/perl -w use Socket; use Net::Telnet (); $timeout = ($ARGV[0]? $ARGV[0]:5) * 60; $arquivolog = "killconn.log"; $port = 7000; $host = ' '; # Abre a conexao com o GateKeeper $t = new Net::Telnet; $t->open(host => $host, Port => $port) or die "Erro na conexao com GK"; while ($t) { $line = $t->getline; $t->open(host => $host, Port => $port) or die "Erro na conexao com GK"; for (;;) { if ($t->getline =~ /^;/o) { last; $now = `date`; chomp($now); if ( $now =~ /.* (.*) (.*) (.*):(.*):(.*).* (.*)/o ) { $horaatual = converteparasegundos ($6, $1, $2, $3, $4, $5); $t->print("cv"); while ($t) { $line = $t->getline; GT-VoIP Relatório P4.1 13

14 if ($line =~ /^;/o ) { last; if ($line =~ /^Call No. (\d*)/o ) { $call = $1; if ($line =~ /^\#.*\.*\.*\.*, (.*) (.*) (.*) (.*):(.*):(.*) -.*/o ) { $iniciochamada = converteparasegundos ($3, $2, $1, $4, $5, $6); $duracao = $horaatual - $iniciochamada; if ( $duracao >= $timeout) { open (LOG, ">>$arquivolog") or die ("Erro na abertura do arquivo de log"); print LOG "$now *** Timeout ($timeout) conexao $call com duracao $duracao\n"; print LOG $line; close LOG; $t->print("disconnectcall $call"); $t->close; 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. Código-Fonte do script de Visualização de Registros Código-Fonte do script de Visualização de Chamadas Ativas # Manda o comando (seja ele RV registros ativos ou CV ligações ativas) $t->print($cmd); while ($t) { $line = $t->getline; if ($line =~ /RCF\ (.*):.*\ (.*):.*\ gateway/o ) { print "<TR><nobr><TD style=\"color: black; BACKGROUND-COLOR: #66ff99\" align=left>gateway</nobr></td><td align=left><nobr>$2</ nobr></td>"; elsif ($line =~ /^Prefixes: (.*)/o ) { print "<TD align=left><nobr>prefixos: $1</nobr></TD></TR>"; elsif ($line =~ /^RCF\ (.*):.*\ (.*):.*=(.*):.*terminal/o ) { print "<TR><TD style=\"color: black; BACKGROUND-COLOR: #ffcc00\" align=left><nobr>terminal</nobr></td><td align=left><nobr>$2< /nobr></td><td align=left><nobr>$3</nobr></td></tr>"; elsif ($line =~ /^;/o ) { last; 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 GT-VoIP Relatório P4.1 14

15 46). O tráfego associado à sinalização de voz deve ser marcado com serviço AF31, DSCP 26, para que também possa 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 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. Configuração de QoS no roteador do POP-RN class-map match-any Gateway-VoIP match access-group 170 policy-map VoIP class Gateway-VoIP priority 600 interface ATM4/0/0.111 point-to-point description Conexao PoP-RN <--> PoP-RJ pvc RJ 0/111 service-policy out VoIP access-list 170 permit ip host any access-list 170 permit ip host any 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 com instruções de como usar o serviço. Uma cópia do e das instruções de uso do serviço são apresentadas no anexo 2. GT-VoIP Relatório P4.1 15

16 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). Total Global de Chamadas realizadas utilizando o serviço VOIP no SBRC Natal Dia Número de ligações Tempo total de uso do Duração Média das realizadas serviço (segundos) Chamadas (segundos) 17/mai /mai /mai /mai /mai /mai /mai TOTAL Chamadas realizadas do Rio de Janeiro para Natal Dia Número de ligações Tempo total de uso do Duração Média das realizadas serviço (segundos) Chamadas (segundos) 17/mai /mai /mai /mai /mai /mai /mai TOTAL GT-VoIP Relatório P4.1 16

17 Chamadas realizadas de Natal para o Rio de Janeiro Dia Número de ligações Tempo total de uso do Duração Média das realizadas serviço (segundos) Chamadas (segundos) 17/mai /mai /mai /mai /mai /mai /mai TOTAL Chamadas realizadas de ramais internos do NCE para Natal Dia Número de ligações Tempo total de uso do Duração Média das realizadas serviço (segundos) Chamadas (segundos) 17/mai 18/mai 19/mai 20/mai /mai /mai /mai TOTAL Chamadas realizadas utilizando ramais virtuais Dia Número de ligações Tempo total de uso do Duração Média das realizadas serviço (segundos) Chamadas (segundos) 17/mai 18/mai 19/mai 20/mai 21/mai /mai 23/mai TOTAL 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 GT-VoIP Relatório P4.1 17

18 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 na voz recebida pelos usuários no Rio de Janeiro. Após um trabalho realizado em conjunto com a equipe da RNP (Marcel e Ari Frazão), foram identificados vários fluxos saindo da Natalnet ocupando 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 existentes 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 certamente 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. de VOIP. 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, GT-VoIP Relatório P4.1 18

19 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. Distribuição horária das chamadas realizadas Gráfico de uso do canal Natal/Rio de Janeiro Tráfego Rio de Janeiro/ Natal (Limitado a 5Mbps) Tráfego Natal/Rio de Janeiro (Limitado a 2.5Mbps) (Extraído da página de estatística da RNP. Gráfico original produzido através do software MRTG) GT-VoIP Relatório P4.1 19

20 Perda de Pacotes Fluxos de mídia Rio de Janeiro Natal Fluxos Natal Rio de Janeiro GT-VoIP Relatório P4.1 20