GT-VOIP Relatório P4.

1:

Documento de Avaliação do Ambiente Experimental de

VOIP durante o 4o. WRNP e 21o. 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 2003.

RNP/REF/0204
Sumário

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

GT-VoIP Relatório P4.1 2

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 4o. Workshop da Rede Nacional de Pesquisa
(WRNP) e do 21o. 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.

Fig.1 – Esquema adotado no ambiente experimental de Voz sobre IP

GT-VoIP Relatório P4.1 3

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

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 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.

GT-VoIP Relatório P4.1 4

 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 (2598-3000)
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 (200.19.164.3) com o ID UFRJ-VOIP-E1
interface FastEthernet0/0
ip address 146.164.247.200 255.255.255.192
h323-gateway voip interface
h323-gateway voip id NATALGK ipaddr 200.19.164.3 1719
h323-gateway voip h323-id UFRJ-VOIP-E1
h323-gateway voip bind srcaddr 146.164.247.200
!
!
! Configuração do plano de discagem
! 842022 Direcionar para o gatekeeper (NATAL)
! 212598 Direcionar para o PBX conectado à porta E1 (discagem direta ao ramal)
! 212562 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

 ! selecionar linha externa).
dial-peer voice 10 pots
preference 5
application ring
destination-pattern 21........
port 2/0:1
prefix 0
!
dial-peer voice 11 pots
preference 1
destination-pattern 212598....
port 2/0:1
!
dial-peer voice 12 voip
destination-pattern 842022...
session target ras
no vad
!
dial-peer voice 51 pots
preference 1
destination-pattern 212562....
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

 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 (200.19.164.3) com o ID VOIP-NATAL, respondendo pelo prefixo 842022
interface Ethernet0/0
ip address 200.19.164.2 255.255.255.0
h323-gateway voip interface
h323-gateway voip id NATALGK ipaddr 200.19.164.3 1719
h323-gateway voip h323-id VOIP-NATAL
h323-gateway voip tech-prefix 842022
!
! Configuração do plano de numeração
! prefixo 21 direciona para o gatekeeper (destino Rio de Janeiro)
! prefixo 842022 direciona para as portas FXO
! Configuração IVR Application ring (olhar capítulo especifico)
dial-peer voice 20 pots
application ring
destination-pattern 842022...
port 1/1/0
!
dial-peer voice 21 pots
application ring
destination-pattern 842022...
port 1/1/1
!
dial-peer voice 22 pots
application ring
destination-pattern 842022…
port 1/0/0
!
dial-peer voice 23 pots
application ring
destination-pattern 842022…
port 1/0/1
!
dial-peer voice 16 voip
destination-pattern 21........
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 842022.

GT-VoIP Relatório P4.1 7

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://146.164.247.209/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. (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. 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 www.voip.nce.ufrj.br.

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

 • Texto 2 (arquivo (user_busy.au)

Número Ocupado, por favor tente mais tarde.

Acesse nosso website (http://www.voip.nce.ufrj.br) 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 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.

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 (10.249.0.0) 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=10.249.0.0/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

 # 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=842022
UFRJ-VOIP-E1=21;212598;212562

# 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:200.19.164.2:1719
VOIP-UFRJ=sigip:146.164.247.200:1719
04001= sigip:146.164.248.28:1719
04002= sigip:200.135.21.253:1719
04003= sigip:200.133.0.200:1719
04004= sigip:200.179.187.24:1719
04005= sigip:169.254.224.131:1719
04006= sigip:200.17.63.111:1719
04007= sigip:146.164.251.72:1719
default=reject

# Limitamos o acesso à console de gerenciamento do gatekeeper (porta TCP 7000)

# Foi permitido o acesso a qualquer máquina da rede 200.19.164
[GkStatus::Auth]
rule=regex
regex=^200\.19\.164\.

# O Gatekeeper vizinho é o DGK (Directory Gatekeeper) que permite realizar ligações

# internacionai.
[RasSrv::Neighbors]
UFRJGK=146.164.247.202: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

 # Aqui temos as regras de permissão e negação dependendo do número discado
[CallTable]
212598=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|111|91 7d 56 f1 87 c6 11 d7 82 27 cd a5 4d 5c c3 69|39|Sat, 17 May 2003 14:47:19

+0300|Sat, 17 May 2003 14:47:58 +0300|200.19.164.2:1720|8129_endp|
146.164.247.196:1721|oz_1008_endp|2125983240:dialedDigits|782:
dialedDigits=VOIP-NATAL:h323_ID|NATALGK;

Onde:
CDR = Call Detail Record
111 = Call number
91 7d 56 f1 87 c6 11 d7 82 27 cd a5 4d 5c c3 69 = Call ID
Sat, 17 May 2003 14:47:19 = Data /Hora do início da chamada
Sat, 17 May 2003 14:47:58 = Data /Hora do término da chamada
200.19.164.2:1720 = Endereço IP do terminal chamador
146.164.247.196:1721 = Endereço IP do terminal chamado
2125983240 = Número telefônico chamado
782 = Número telefônico do chamador

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.
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

 Acct-Session-Id = "000003F6"
h323-setup-time = "h323-setup-time=.06:29:54.049 BRST Wed May 21 2003"
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:05.685 BRST Wed May 21 2003"
Acct-Input-Octets = 40210
Acct-Output-Octets = 182080
Acct-Input-Packets = 2071
Acct-Output-Packets = 9104
Acct-Session-Time = 182
h323-disconnect-time = "h323-disconnect-time=.06:33:07.849 BRST Wed May 21 2003"
h323-disconnect-cause = "h323-disconnect-cause=1B"
h323-remote-address = "h323-remote-address=200.19.164.3"
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=146.164.247.200"
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

 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 = 200.19.164.2
Acct-Delay-Time = 0
Client-IP-Address = 200.19.164.2
Timestamp = 1053509577

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 = '146.164.247.196';

# 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

 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

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 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.

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 200.19.164.2 any

access-list 170 permit ip host 200.19.164.3 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 e-mail com instruções de como usar o serviço.
Uma cópia do e-mail e das instruções de uso do serviço são apresentadas no anexo 2.

GT-VoIP Relatório P4.1 15

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

Número de ligações Tempo total de uso do Duração Média das

Dia
realizadas serviço (segundos) Chamadas (segundos)
17/mai 44 4970 113
18/mai 44 6646 151
19/mai 72 8209 114
20/mai 65 12666 195
21/mai 68 15745 232
22/mai 73 15344 210
23/mai 74 15030 203
TOTAL 440 78610 179

Chamadas realizadas do Rio de Janeiro para Natal

Número de ligações Tempo total de uso do Duração Média das

Dia
realizadas serviço (segundos) Chamadas (segundos)
17/mai 13 1451 112
18/mai 5 579 116
19/mai 11 470 43
20/mai 7 2299 328
21/mai 8 1103 137
22/mai 3 1981 660
23/mai 5 345 69
TOTAL 52 8228 158

GT-VoIP Relatório P4.1 16

 Chamadas realizadas de Natal para o Rio de Janeiro

Número de ligações Tempo total de uso do Duração Média das

Dia
realizadas serviço (segundos) Chamadas (segundos)
17/mai 31 3519 114
18/mai 39 6067 156
19/mai 61 7739 127
20/mai 52 10151 195
21/mai 56 14460 258
22/mai 69 13324 193
23/mai 68 14570 214
TOTAL 376 69830 186

Chamadas realizadas de ramais internos do NCE para Natal

Número de ligações Tempo total de uso do Duração Média das

Dia
realizadas serviço (segundos) Chamadas (segundos)
17/mai
18/mai
19/mai
20/mai 6 216 36
21/mai 2 73 37
22/mai 1 39 39
23/mai 1 115 115
TOTAL 10 443 44

Chamadas realizadas utilizando ramais virtuais

Número de ligações Tempo total de uso do Duração Média das

Dia
realizadas serviço (segundos) Chamadas (segundos)
17/mai
18/mai
19/mai
20/mai
21/mai 2 109 54
22/mai
23/mai
TOTAL 2 109 54

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

GT-VoIP Relatório P4.1 17

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

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

 Perda de Pacotes

Fluxos de mídia Rio de Janeiro Natal

Fluxos Natal Rio de Janeiro

GT-VoIP Relatório P4.1 20

 Round Trip Time (RTT)

Fluxos Rio de Janeiro Natal

Fluxos Natal Rio de Janeiro

GT-VoIP Relatório P4.1 21

 Motivos de Desconexão

Gateway Rio de Janeiro Natal (146.164.247.200)

17/05 18/05 19/05 20/05 21/05 22/05 23/05

Causa da Desconexão 2003 2003 2003 2003 2003 2003 2003
destination out of order (27) 20 5 25 30 20 41 38
no resource (47) 2 29 46 31 47 32 47
no route to destination (3) 3 3
no user answer (19) 1
normal 1
normal call clearing (16) 26 11 11 13 10 4 6
recovery on timer expiry (102) 8 2 3
service or option not available 1 1
subscriber absent (20) 1 1 1
switch congestion (42) 5 4 13 4
unassigned number (1) 1
user busy (17) 5 1 4 5 2 5 4
Total 63 49 94 83 84 98 102

Gateway Natal Rio de Janeiro (200.19.164.2)

18/05 19/05 20/05 21/05 22/05 23/05

Causa da Desconexão 2003 2003 2003 2003 2003 2003
destination out of order (27) 52 126 98 108 130 132
message in incomp call state (101) 3
no resource (47) 1 2
no route to destination (3) 6 6 1 1
Normal 1
normal call clearing (16) 1
recovery on timer expiry (102) 13 8 15 5 20 15
service or option not available 1
subscriber absent (20) 1
switch congestion (42) 2
user busy (17) 3 2
Grand Total 71 147 115 118 155 147

GT-VoIP Relatório P4.1 22

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 utilizada de sistema operacional ( 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.

GT-VoIP Relatório P4.1 23

7.
Anexos

Anexo 1 – Código fonte do script IVR TCL – ring.tcl

The TCL Script is:

------------------
# Script Locked by: voip
# Script Version: 1.1
# Script Name: ring.tcl
# Script Lock Date: Fri Jan 17 14:16:46 2003
# Copyright (c) 1998, 1999, 2000 by cisco Systems, Inc.
# All rights reserved.
#------------------------------------------------------------------
# Audio files required:
# user_busy.au
# welcome.au
#
# The main routine is at the bottom. Start reading there.

proc do_active_notimer {} {
global state
set event [waitEvent]
while { $event == "digit" || $event == "call connected" } {
set event [waitEvent]
}
set state end
return 0
}
proc do_active {} {
global state
do_active_notimer
}
proc do_place_fail {} {
global state

puts "The call was released with User Busy\n"

set prompt(url) flash:user_busy.au
set prompt(playComplete) true
set event [promptAndCollect prompt info]
set state end
return 0
}

proc do_place_call {} {
global state
global destination

puts $destination

GT-VoIP Relatório P4.1 24

 set event [placeCall $destination callInfo info]

if {$event == "active"} {
set state active
return 0
}
if {$event == "call fail"} {
if {$info(code) == 17} {
set state place_fail
return 0
}

set state end

return 0
}

set state end

return 0
}
#-------------------------------------------------------
# And here is the main routine
#
acceptCall
set state init
set prompt(url) flash:welcome.au
set prompt(interrupt) true
set prompt(abortKey) *
set prompt(dialPlan) true
set event [promptAndCollect prompt returnInfo]
if { $event != "collect success" } {
puts "Call [callID] got event $event collecting destination"
exit 0
}
set state place_call
set destination $returnInfo(digits)

while {$state != "end"} {

puts "cid([callID]) running state $state"
if {$state == "place_call"} {
do_place_call
} elseif {$state == "place_fail"} {
do_place_fail
} elseif {$state == "active"} {
do_active
} else {
break
}
}
# Script Approval Signature: C/fa2d

GT-VoIP Relatório P4.1 25

Anexo 2 - Email enviado aos usuários que se cadastraram para uso do serviço na página do
evento

Caro usuário.
Estamos confirmando o seu registro no Sistema VoIP WRNP/SBRC.
Seu telefone virtual é 04001.
Para fazer o acesso ao serviço, utilize um software cliente baseado em H.323
como o Netmeeting. Configure o Netmeeting com os seguintes parâmetros:
• Acione o Netmeeting
• Acesse o menu *Tools*. Depois acesse a opção *Options* e, por fim, clique no
botão: *Advanced Calling*
• Habilite a opção “Use a Gatekeeper to place calls”
• Configure o endereço IP oficial do Gatekeeper do Serviço VoIP WRNP/SBRC:
*Gatekeeper: 200.19.164.3*
• Opcionalmente configure o seu nome na opção *Log on using my account name”
• Obrigatoriamente configure a identificação do seu número
telefônico virtual na opção “Log on using my phone number = 04001”

Para usar o serviço, siga estas orientações:

Quero ligar para ramais internos do Hotel Pirâmide?

Cliente H.323 disca 84-202-2XXX, onde XXX é um ramal interno do
hotel Pirâmide.
Quero ligar do ramal do hotel para ramal virtual?
Discar 784 ou 783 ou 782 ou 781.
Após entrada da mensagem gravada, disca 0 seguido do número de
telefone virtual.
Quero ligar para números telefônicos no Rio?
Discar (21) 2598-3000
Após entrada da mensagem gravada, disca 0 seguido do número de
telefone virtual.
Quero ligar do Rio de Janeiro para ramal virtual?
Cliente H.323 disca 21-202-2XXX, onde XXX é um ramal interno do
hotel Pirâmide.
Quero ligar para outro telefone virtual?
Cliente H.323 disca 0 seguido do número de telefone virtual.
Quais os ramais virtuais estão logados e disponíveis para conversação
pelo Brasil?
http://belem.voip.nce.ufrj.br/cgi-bin/rv.cgi

Atenção! Todas as ligações estão sendo contabilizadas e limitadas em

aproximadamente 5 minutos.
Não estão permitidas ligações para celulares pelo Servico VOIP da UFRJ.

GT-VoIP Relatório P4.1 26

Anexo 3 – Anúncio do serviço VOIP durante o WRNP/SBRC

WRNP/SBRC 2003
Serviço VOIP
GT-VOIP
ACESSANDO E RECEBENDO LIGAÇÕES
TELEFÔNICAS
Telefones da rede de telefonia (fixa ou celular) ligando para ramais internos do hotel através do
Serviço VOIP na UFRJ:
Discar para (21) 2598-3000.
Após entrada da mensagem gravada, disca 84-202-2XXX, onde XXX é um ramal interno
do hotel Pirâmide.

Ramais internos do hotel discando para telefones fixos no Rio de Janeiro, através do Serviço
VOIP do GT-VOIP implantado no hotel:
Discar 784 ou 783 ou 782 ou 781.
Após entrada da mensagem gravada, discar 21, seguido do número de telefone fixo no
Rio.

TELEFONES VIRTUAIS
Ligando para ramais internos do Hotel Pirâmide:
Cliente H.323 chama 84-202-2XXX, onde XXX é um ramal interno do hotel Pirâmide.

Ramal do hotel ligando para ramal virtual:

Discar 784, ou 783, ou 782, ou 781.
Após entrada da mensagem gravada, discar 0 seguido do número de telefone virtual.

Ligando para números telefônicos no Rio:

Cliente H.323 chama 21 + número de telefone fixo no Rio.
Ligando para outro telefone virtual:
Cliente H.323 chama 0 + número de telefone virtual.

Telefones virtuais devem ser pré-cadastrados nos sites www.voip.nce.ufrj.br ou www.sbrc2003.ufrn.br

. Todas as ligações estão sendo contabilizadas e limitadas em aproximadamente 5 minutos. Não
estão permitidas ligações para celulares pelo Servico VOIP da UFRJ.

GT-VoIP Relatório P4.1 27