INFRAESTRUTURA DE TELEFONIA VOIP DO IFRN - RNP

INFRAESTRUTURA DE TELEFONIA VOIP DO IFRN
RESUMO
Neste texto, nós descrevemos a infraestrutura de telefonia VoIP
adotada no IFRN, tal como os equipamentos e tecnologias
utilizadas no projeto e as ações planejadas para o futuro.
Palavras-Chave
VoIP, AudioCodes, Asterisk, Sobrevivência, Máquina
Virtual, Telefone IP.
1. INTRODUÇÃO
Este trabalho visa apresentar a atual infraestrutura de telefonia
VoIP implantada no IFRN. Baseada em equipamentos gateway
VoIP AudioCodes e no IPBX Asterisk
2. MOTIVADORES
A implantação do projeto mudou toda a infraestrutura de telefonia
da instituição, nesse cenário, houveram vários motivadores que
abalizaram essa mudança, tais como, eliminar os custos com
ligações entre os diversos câmpus do Instituto; reduzir os custos
nas ligações dos câmpus para os telefones fixos da capital;
eliminar custos com aluguel e manutenção de centrais telefônicas
analógicas; redução nos custos com chamadas interurbanas
através do projeto fone@RNP; facilitar e agilizar a comunicação
interna dos servidores e setores do instituto; padronizar o plano
de numeração dos ramais internos do Instituto; melhorar a
gerência da telefonia; e adequação às novas tecnologias de
comunicação.
3. ARQUITETURA DA
SOLUÇÃO
3.1 Equipamentos utilizados
Na solução são utilizados somente IP Phones, não sendo
utilizados softphones ou equipamentos ATA. Para a interface com
a PSTN são utilizados os gateway VoIP AudioCodes dos modelos
MP-114 e Mediant 1000 com interface E1. O IPBX Asterisk é
uma máquina virtual hospedada dentro do datacenter do IFRN.
3.2 Registro dos telefones
O procedimento de registro dos telefones IP é o método
necessário para que o IPBX (Asterisk), ou a aplicação SAS do
gateway, saiba qual é o IP do ramal que está registrado para usar a
infraestrutura VoIP.
Nesse procedimento, o telefone IP envia o pacote SIP REGISTER
para o PROXY SIP que está configurado no telefone IP.
Na nossa arquitetura, a configuração do proxy SIP nos telefones
IP deve ser definida para o IP do gateway VoIP AudioCodes, na
porta 5080 (porta da aplicação SAS-Stand Alone Survivability). A
Carlos Eduardo Gomes do Egito
IFRN
eduardo.egito@ifrn.edu.br
aplicação SAS é configurada para entrar em funcionamento
quando o proxy definido (que no nosso caso é o Asterisk), não
estiver acessível, seja por falha no link, ou seja por falha no
próprio servidor do Asterisk.
Quando o link está operacional, os telefones IP se registram no
gateway VoIP AudioCodes, o gateway repassa o registro dos
telefones IP para o proxy que está configurado nele (Asterisk), e o
Asterisk recebe o registro desses telefones, atualizando a sua
tabela de registro, que consta com a relação do número do ramal e
do IP do telefone desse ramal.
Quando o link do campus ou o servidor do Asterisk fica
indisponível, o gateway VoIP desse campus entra no modo de
sobrevivência. Nesse modo o gateway AudioCodes efetua o
registro dos telefones IP. Contudo, a aplicação de sobrevivência
do gateway (SAS) não autentica os telefones IP com senha, ou
seja, as senhas definidas nos telefones IP são transparentes para o
gateway VoIP.
3.3 Ligação entre ramais
O IPBX Asterisk detém os registros de todos os ramais. Nele
constará os endereços IP de todos os telefones dos campi do
Instituto.
Quando um usuário discar um número de um ramal válido de
qualquer campus, o Asterisk irá direcionar essa ligação para o
endereço IP do telefone do ramal de destino. O telefone do ramal
de destino responderá à ligação diretamente ao telefone originador
da chamada, fechando assim o canal de comunicação, esse canal é
ponto-a-ponto, ou seja, a ligação não fica intermediada pelo
servidor do Asterisk.
A ligação entre ramais deve ser transparente para o usuário, ou
seja, estando o link de comunicação funcionando ou não, a ligação
deve chegar ao destino sendo digitados somente os números dos
ramal desejado. Nesse contexto temos duas situações:
Situação 1:
É efetuada uma chamada entre ramais com destino a um campus
que está com o link de rádio inoperante: Quando um usuário disca
um número de um ramal, ele não sabe se no campus do número de
destino o link de dados está funcionando ou não, isto é, essa
informação deve ser transparente ao usuário.
O monitoramento do link de dados fica a cargo do gateway VoIP
e do Asterisk. No gateway VoIP o monitoramento é feito através
de pacotes SIP OPTIONS enviados ao proxy configurado nele,
conforme configuração do proxy nos gateways VoIP. Já no
Asterisk, o monitoramento é feito através do parâmetro
qualify=yes, inserido na configuração dos troncos, e por uma
macro no dialplan do Asterisk, que verifica o status do tronco
relacionado ao campus de destino, e direciona a ligação ao ramal

desejado pelo IP do telefone se o link estiver funcionando, ou para
o número externo do campus via PSTN se o link estiver
inoperante.
Situação 2:
É efetuada uma chamada entre ramais originada por um campus
que está com o link de rádio inoperante: Nesse caso, a ligação é
gerada no próprio campus que está sem link. Como o gateway
VoIP já detectou que o proxy (Asterisk) está inacessível e já se
encontra em como de sobrevivência (SAS), primeiramente ele
verifica a sua tabela de registros da aplicação SAS, se o número
de destino não for do mesmo campus, se não estiver na tabela, ele
redirecionará a ligação para a sua aplicação SIP. A aplicação SIP,
então, roteia as ligações chegadas nela para a PSTN, conforme o
ramal digitado, ou seja, se o ramal de destino for um do campus
Ipanguaçu, irá cair na rota definida para os ramais de destino
52XX, que é o número externo do campus Ipanguaçu (84 3335-
2303). A plaicação SIP envia as chamadas para a PSTN através do
entroncamento FXO ou E1 instalados no próprio gateway.
3.4 Chamada externa
As chamadas efetuadas para números locais públicos são
recebidas pelo Asterisk através do redirecionamento do SIP
INVITE feito pelo gateway AudioCodes. Ao receber esse SIP
INVITE, o servidor Asterisk analisa 2 aspectos: de onde foi
originada a chamada; e se o originador da chamada possui
permissão para efetuar chamadas. Essa análise é feita baseado no
contexto em que o ramal originador da chamada se encontra.
Existem 3 contextos que determinam as permissões de geração de
chamadas:
1. poderamal - Nesse contexto, o ramal somente pode
efetuar chamadas para ramais internos da
instituição;
2. podelocal - Nesse contexto, o ramal pode efetuar
chamadas para telefones fixos com o DDD 84;
3. podecel - Nesse contexto, o ramal também pode
efetuar chamadas locais para celular;
4. podedddcel - Nesse contexto, o ramal pode efetuar
chamadas DDD, para fixos e para celular;
Se o ramal originador da chamada estiver nos contextos podelocal
ou podedddcel, o Asterisk redirecionará a chamada para a
aplicação SIP do gateway AudioCodes da Reitoria na porta 5060,
que completará a ligação via PSTN. Se não, o Asterisk não
autorizará a ligação, encerrando a mesma.
Na ausência de conectividade com o IPBX Asterisk, o gateway
entra em como de sobrevivência, com isso ele passa a fazer o
papel de servidor de registro SIP, recebendo e tratando todos
registros dos aparelhos telefônicos IP.
Quando um usuário origina uma ligação com destino a um
número público, o gateway recebe essa requisição (SIP INVITE)
na porta onde os telefones estão registrados (5080, aplicação SAS)
e manda para a PSTN através da aplicação SIP (5060), pois ele
não conhece esse número e manda para o "SAS Default
Gateway", na aplicação SIP a ligação é roteada para a PSTN
através do entroncamento FXO ou E1 instalados no próprio
gateway.
3.5 Recebimento de chamada externa
Ao receber uma chamada vinda da PSTN, o comportamento é
diferenciado para os gateways MP-114 (que comporta até 4 FXO),
e o gateway Mediant 1000 (que possui módulos para troncos E1).
No gateway MP-114, a ligação recebida em uma determinada
linha conectada ao gateway, é direcionada ao ramal configurado
para receber ligações na porta em que a linha está fisicamente
instalada.
Já no gateway Mediant 1000 instalados nos campus que possuem
troncos digitais E1 com funcionalidade de DDR (Discagem Direta
a Ramal), a operadora já entrega para o gateway somente os 4
últimos dígitos, ou seja, o ramal propriamente dito. Sendo assim, a
configuração é feita somente através de roteamento encaminhando
a chamada para a aplicação SAS.
4. CONCLUSÃO
A arquitetura implantada foi pensada para ser altamente escalável
e modificável com o menor impacto com o tempo de implantação.
No nosso caso a implantação da solução durou ao todo pouco
mais de 6 meses.
Para um futuro próximo, está planejada a integração da solução
com o sistema SUAP, para que a gerência da autorização dos
ramais e as estatísticas de uso e se consumo, sejam feitas através
do sistema.