Alex Galhano Robertson Engenheiro de Telecomunicações e A RNP – Rede

Nacional de Ensino
Mestre em Engenharia de Redes com ênfase em Comunicações
e Pesquisa – é qualificada como
Multimídia, ambos pela Universidade Federal Fluminense (UFF).
uma Organização Social (OS),
Edison Tadeu Melo Graduado em Ciências da Computação
sendo ligada ao Ministério da
e mestre em Sistemas de Computação pela Universidade
Federal de Santa Catarina. Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Estefania Borm Graduada em Sistemas de Informação pela
Universidade Federal de Santa Catarina - UFSC. Pós-Graduanda Programa Interministerial RNP,
em Sistemas de Telecomunicações pela ESAB. que conta com a participação dos
Guilherme Rhodem Bacharel em Informática pela UFPEL
ministérios da Educação (MEC), da

Serviço
(1999), Mestre em Ciências da Computação pela UFSC (200). Saúde (MS) e da Cultura (MinC).
O curso tem por objetivo capacitar profissionais das Pioneira no acesso à Internet no

LIVRO DE APOIO AO CURSO
Helder Vitorino Mestre em Gestão do Conhecimento e
Tecnologia da Informação pela Universidade Católica de instituições clientes da RNP na solução técnica de seu Brasil, a RNP planeja e mantém a

fone@RNP
Brasília. Possui MBA em Gestão de Projetos, Especialização
serviço de Voz sobre IP, o fone@RNP. O profissional rede Ipê, a rede óptica nacional
em Engenharia de Software.
será capaz de instalar, operar e manter em sua insti- acadêmica de alto desempenho.

Serviço fone@RNP V.2012
Jonatan Hartmann Matschulat Engenheiro de software com
tuição o conjunto de servidores que constituem a rede Com Pontos de Presença nas
especialidade em desenvolvimento web e móvel. Graduado
em Sistemas de Informação pela UFSC em 2010. de VoIP da RNP. Este livro tem o objetivo de apoiar 27 unidades da federação, a rede

V.2012
os profissionais na disseminação do conhecimento em tem mais de 800 instituições
Luís Fernando Cordeiro Possui graduação em Sistemas de
Informação (2012) e especialização em Engenharia e Arqui- suas organizações ou localidades de origem. conectadas. São aproximadamente
tetura de Software (2015). 3,5 milhões de usuários usufruindo
Murilo Vetter Graduado em Ciências da Computação pela de uma infraestrutura de redes
Universidade Federal de Santa Catarina - UFSC (2008). Mestre
Alex Galhano Robertson Luís Fernando Cordeiro avançadas para comunicação,
em Ciências da Computação pela Universidade Federal de
Santa Catarina - UFSC (2015). Edison Tadeu Melo Murilo Vetter computação e experimentação,
Estefania Borm Paulo Alexandre de O Brandtner que contribui para a integração
Paulo Alexandre de O Brandtner Graduado em Sistemas
Guilherme Rhodem Thiago Maluf entre o sistema de Ciência e
de Informação pela Universidade Federal de Santa Catarina.
Helder Vitorino Wescley Patrick da Silva Tecnologia, Educação Superior,
Thiago Maluf Bacharel em Ciência da Computação pela Jonatan Hartmann Matschulat
Saúde e Cultura.
UFRJ e detentor da certificação DCAP.

Wescley Patrick da Silva Graduado em análise e desenvol-
vimento de sistemas, possui especialização em segurança
de redes de computadores, é certificado em DELL DCSE
Foundation 2010, ITIL Foundation, Digium dCCA.

ISBN 978-85-63630-58-2

9 788563 630582
A RNP – Rede Nacional de Ensino
e Pesquisa – é qualificada como
uma Organização Social (OS),
sendo ligada ao Ministério da
Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Programa Interministerial RNP,
que conta com a participação dos
ministérios da Educação (MEC), da
Saúde (MS) e da Cultura (MinC).
Pioneira no acesso à Internet no
Brasil, a RNP planeja e mantém a
rede Ipê, a rede óptica nacional
acadêmica de alto desempenho.
Com Pontos de Presença nas
27 unidades da federação, a rede
tem mais de 800 instituições
conectadas. São aproximadamente
3,5 milhões de usuários usufruindo
de uma infraestrutura de redes
avançadas para comunicação,
computação e experimentação,
que contribui para a integração
entre o sistema de Ciência e
Tecnologia, Educação Superior,
Saúde e Cultura.
Serviço
fone@RNP
V.2012
Alex Galhano Robertson
Edison Tadeu Melo
Estefania Borm
Guilherme Rhodem
Helder Vitorino
Jonatan Hartmann Matschulat
Luís Fernando Cordeiro
Murilo Vetter
Paulo Alexandre de Oliveira Brandtner
Thiago Maluf
Wescley Patrick da Silva
Serviço
fone@RNP
V.2012
Alex Galhano Robertson
Edison Tadeu Melo
Estefania Borm
Guilherme Rhodem
Helder Vitorino
Jonatan Hartmann Matschulat
Luís Fernando Cordeiro
Murilo Vetter
Paulo Alexandre de Oliveira Brandtner
Thiago Maluf
Wescley Patrick da Silva

Rio de Janeiro
Escola Superior de Redes
2016
Copyright © 2016

– Rede Nacional de Ensino e Pesquisa – RNP
Rua Lauro Müller, 116 sala 1103
22290-906 Rio de Janeiro, RJ

Diretor Geral
Nelson Simões

Diretor de Serviços e Soluções
José Luiz Ribeiro Filho

Escola Superior de Redes
Diretor Adjunto
Leandro Marcos Oliveira Guimarães

Edição
Lincoln da Mata

Coordenador Área de Mídia Digitais
Renato Duarte

Equipe ESR (em ordem alfabética)
Adriana Pierro, Alynne Figueiredo, Celia Maciel, Edson Kowask, Elimária Barbosa, Evellyn Fei-
tosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Márcia Correia, Marcia Rodrigues,
Luiz Carlos Lobato, Thays Farias, Yve Marcial.

Capa, projeto visual e diagramação
Tecnodesign

Versão
2.0.0

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.

Distribuição
Escola Superior de Redes
Rua Lauro Müller, 116 – sala 1103
22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br

Dados Internacionais de Catalogação na Publicação (CIP)

M236s Robertson, Alex Galhano.
Serviço fone@RNP / Alex Galhano Robertson, et al. – Rio de Janeiro: RNP/ESR, 2016.
316 p. : il. ; 27,5 cm.

ISBN 978-85-63630-58-2

1. Redes VoIP – instalação e manutenção. 2. Protocolos de redes VoIP. 3. Asterisk
(software). 4. OpenSER (software). I. Robertson, Alex. II. Titulo.

CDD 004.65
Sumário

1. Apresentação
Visão básica da RNP 1

Serviços avançados na RNP 2

Comunicação e Colaboração 3

Gestão de identidade 3

Suporte à rede acadêmica 3

Disponibilização de conteúdos digitais 3

Hospedagem estratégica 3

Apoio a serviços 3

O serviço Fone@RNP 3

O GT-VoIP 4

O projeto VoIP4All 4

Projeto de melhoria do fone@RNP 5

Evolução dos clientes do fone@RNP 5

Alcance do fone@RNP 6

Alcance internacional do fone@RNP  6

Processo de adesão ao fone@RNP 7

2. Introdução à telefonia
Um pouco de história 9

Circuito elétrico equivalente 10

Arquitetura hierárquica e em estrela 11

Encaminhamento das chamadas 13

iii
Protocolos e sinalização 14

Telefonia digital 15

Digitalização da voz: PCM 16

Amostragem 17

Quantização 17

Codificação 18

O que é TDM? 18

E1/T1 e PDH 19

RDSI ou R2-Digital 20

Cabos e conexões 20

Tráfego e dimensionamento de canais 22

Tráfego Telefônico (A) 22

Hora de Maior Movimento (HMM) 22

Grau de Serviço (GoS) 23

Dimensionamento de canais e tabelas de Erlang 23

Plano de Numeração Nacional 24

Terminais telefônicos dentro de centrais privadas (PABX) 26

3. Introdução à Voz sobre IP
Protocolo de iniciação de sessão – SIP 27

Características do protocolo SIP 28

Funcionalidades 28

O que o SIP não é e não faz: 28

Elementos de uma rede SIP 29

Fluxo de mensagens SIP 30

Servidor de redirecionamento (Redirect Server) 31

Servidor de registro (Registrar Server) 32

Mensagens SIP 32

Mensagem de requisição SIP (SIP Requests) 32

Mensagem de resposta (SIP Response) 34

Protocolo SDP 36

Exemplo: 37

Real-time Transport Protocol – RTP 37

Formato do pacote RTP 38

Real-time Transport Control Protocol – RTCP 39

iv
Empacotamento da voz: CODEC 40

Codec 40

Super-resumo de Voz sobre IP 44

4. Arquitetura do fone@RNP v.2012
SIP Router Central (SRC) 46

SIP Router Local (SRL) 46

PBX IP 47

Gateway Transparente (GWT) 47

A arquitetura típica do fone@RNP 48

A instituição típica 48

Características do cenário 49

Fluxos de comunicação entre os dispositivos 50

Exemplos ilustrados para fluxo de mídia e sinalização 51

Sobre firewall e portas de comunicação nos servidores 52

Testes de chamadas (checklist) 55

Encaminhamento das chamadas 56

O plano de numeração recomendado 57

Planejamento para instalação do fone@RNP 57

5. Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
GWT 59

GWT 2.0 60

Gateway Transparente 2.0 60

Ligando os cabos 61

Acessando e configurando o GWT 61

Acessando e configurando o GWT 66

Monitoramento 87

Contabilização 89

Estatísticas 89

Completadas 90

Não Completadas 90

Mais Chamados 91

v
Gateway Transparente Analógico (GWTa) 91

Cenário considerado 92

O que é o CIP 850? 92

Instalação física do CIP 850 94

Configuração lógica da central 96

6. SIP Router Local (SRL)
Sobre o SIP Router Local – SRL 109

Quando usar o SRL? 110

Roteiro de instalação e configuração 110

Pré-instalação 110

Instalação 111

Acessando e configurando o SRL 120

Replicação LDAP entre dois SRLs 135

Rotas 142

Contabilização 150

Usuários 152

País 153

Sistema 154

Console 155

Backup/Restore 156

Logs 157

7. PBX IP
Sobre o PBX IP Corporativo 159

Roteiro de instalação e configuração – PBX IP Corporativo 160

Instalação do PBX Corporativo 160

Acessando e configurando 166

Configurando uma estação para acessar o PBX IP 166

Configurando o PBX-IP Corporativo 170

Central – gerência de usuários e ramais 184

Usuários SIP 185

Painel de Controle 195

Status 196

Contabilização 197

vi
Sobre o PBX IP Acadêmico 198

Instalação do PBX IP acadêmico 199

Configuração de DNS para a PBX-IP Acadêmica 200

Acessando e configurando 201

Configurando o PBX-IP Acadêmico 201

Guia de operação 215

Integração de sistemas: WebService 230

createRamal 231

alterarSenha 232

buscaInfoRamais 232

excluirUsuário 233

8. Estudo de casos
Lembrete sobre o uso do SRL nas instituições 235

Caso 1 236

Cenário 236

Solução proposta 236

Caso 2 236

Cenário 236

Solução proposta 237

Caso 3 237

Cenário 237

Solução proposta 238

Caso 4 238

Cenário 238

Solução proposta 239

Caso 5 239

Cenário 239

Solução proposta 239

Caso 6 240

Cenário 240

Solução proposta 240

Caso 7 241

Cenário 241

Solução proposta 241

vii
Caso 8 242

Cenário 242

Solução proposta 243

9. Estatísticas
Sobre estatísticas 245

Relatórios do Sistema de Estatísticas 246

Uso do mapa 246

Uso dos relatórios 247

Exibição de outros relatórios 248

Relatório em Detalhes 249

Comparação de relatórios 250

Descrição dos relatórios 252

Relatórios dos módulos do fone@RNP 257

Relatórios do GWT 257

10. Anexos
Anexo 1 – Planejamento para instalação do fone@RNP em uma empresa fictícia 269

Anexo 2 – Configuração de firewall 274

Anexo 3 – Instalação manual do SRL 279

IAnexo 4 – Plano de Testes 283

viii
Escola Superior de Redes
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa
(RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação
e Comunicação (TIC).

A ESR nasce com a proposta de ser a formadora e disseminadora de competências em
TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e
unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica
do corpo funcional das organizações usuárias da RNP, para o exercício de competências
aplicáveis ao uso eficaz e eficiente das TIC.

A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Pro-
jeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração
Digital e Governança de TI.

A ESR também participa de diversos projetos de interesse público, como a elaboração
e execução de planos de capacitação para formação de multiplicadores para projetos
educacionais como: formação no uso da conferência web para a Universidade Aberta do
Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um con-
junto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR
A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na
aprendizagem como construção do conhecimento por meio da resolução de problemas
típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de
natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didá-
tico, atua não apenas como expositor de conceitos e informações, mas principalmente
como orientador do aluno na execução de atividades contextualizadas nas situações do
cotidiano profissional.

A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema
semelhantes às encontradas na prática profissional, que são superadas por meio de aná-
lise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução
do problema, em abordagem orientada ao desenvolvimento de competências.

Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno
para as atividades em laboratório. Até mesmo a apresentação da teoria no início da ses-
são de aprendizagem não é considerada uma simples exposição de conceitos e informa-
ções. O instrutor busca incentivar a participação dos alunos continuamente.

ix
As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das
atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas
de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de
atuação do futuro especialista que se pretende formar.

As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de
tempo para as atividades práticas, conforme descrição a seguir:

Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos).
O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema
da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor
levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando
a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que
o aluno se coloque em posição de passividade, o que reduziria a aprendizagem.

Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos).
Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assín-
crona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades
proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar
dúvidas e oferecer explicações complementares.

Terceira etapa: discussão das atividades realizadas (30 minutos).
O instrutor comenta cada atividade, apresentando uma das soluções possíveis para
resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são
convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham
gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os
alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso
existam, a comentá-las.

Sobre o curso
O curso “Serviço fone@RNP v.2012” é uma atualização do curso “Serviço fone@RNP”.

Este curso apresenta o serviço de telefonia IP da RNP, oferecido à suas instituições parcei-
ras. Aborda as tecnologias que servem de alicerce para seu funcionamento e, principal-
mente, apresenta a instalação e operação do serviço e seus componentes.

Objetivo: Ensinar o profissional técnico a instalar, operar e manter os dispositivos que
compõem o serviço fone@RNP em sua instituição.

Ao final do curso, o profissional será capaz de instalar e manter o serviço fone@RNP em
sua instituição

A quem se destina
Engenheiros, analistas, técnicos e outros profissionais responsáveis pelo serviço de telefonia
IP das instituições parceiras, bem como quaisquer outros interessados em soluções de Voz
sobre IP.

Convenções utilizadas neste livro
As seguintes convenções tipográficas são usadas neste livro:

Itálico
Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

x
Largura constante

Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída
de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo
Indica referência complementar disponível em site ou página na internet.

Símbolo
Indica um documento como referência complementar.

Símbolo
Indica um vídeo como referência complementar.

Símbolo
Indica um arquivo de aúdio como referência complementar.

Símbolo
Indica um aviso ou precaução a ser considerada.

Símbolo
Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao
entendimento do tema em questão.

Símbolo
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou
mesmo uma observação.

Permissões de uso
Todos os direitos reservados à RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citação: MALUF, Thiago; ROBERTSON, Alex Galhano. Serviço fone@RNP. Rio de
Janeiro: Escola Superior de Redes, RNP, 2013.

Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação:
Escola Superior de Redes RNP
Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo
Rio de Janeiro – RJ – 22290-906
E-mail: info@esr.rnp.br

xi
Sobre os autores
Alex Galhano Robertson Engenheiro de Telecomunicações e Mestre em Engenharia
de Redes com ênfase em Comunicações Multimídia, ambos pela Universidade Federal
Fluminense (UFF). Possui experiência em gerência de redes IP, QoS, Voz sobre IP e telefo-
nia computacional, tendo atuado como consultor em diversos projetos de importantes
empresas brasileiras. Coordenou projeto em VoIP no âmbito da RedCLARA - Rede de
Colaboração Latino Americano em Redes Avançadas. Escreveu e ministrou treinamento em
Voz sobre IP para Redes Nacionais da América Latina, ministrou cursos de VoIP na UFF e na
ESR e escreveu o livro do fone@RNP para Escola Superior de Redes da RNP. Atualmente é
Especialista em Serviços na Rede Nacional de Ensino e Pesquisa sendo responsável técnico
pelos serviços de Comunicação e Colaboração, representa a América Latina no Comitê
Global de Governança do NRENum.net (GNGC) e é integrante do grupo Global RealTime
Communications Exchange (GRTC).

Edison Tadeu Melo Superintendente da SeTIC/UFSC (Superintendência de Governança
Eletrônica e Tecnologia da Informação e Comunicação da UFSC). Coordenador administrativo
do PoP-SC e REMEP-FLN. Graduado em Ciências da Computação e mestre em Sistemas de
Computação pela Universidade Federal de Santa Catarina. Atua em projetos de TI desde 1981.

Estefania Borm Técnica em Telecomunicações pelo IFSC - São José. Graduada em Sistemas
de Informação pela Universidade Federal de Santa Catarina - UFSC. Pós-Graduanda em
Sistemas de Telecomunicações pela ESAB. Atua desde 2008 na área de Telefonia IP e Redes de
Computadores. Atuou na implantação da Telefonia IP na UFSC, bem como no desenvolvimento
do projeto Fone@RNP. É analista de TI da equipe do PoP-SC, trabalhando principalmente nos
projetos fone@RNP e MonIPÊ.

Guilherme Rhodem Possui mais de 15 anos de experiência em redes de computadores.
Bacharel em Informática pela UFPEL (1999), Mestre em Ciências da Computação pela UFSC
(2002), trabalhou na redeUFSC e desde 2003 é analista de redes do PoP-SC/RNP.
Atualmente exerce a coordenação técnica do PoP-SC/RNP e PTT/SC. Já participou de diver-
sos grupos de pesquisa, como GT-QoS, GT-Medições, MONIPÊ, MonCircuitos, foi técnico
responsável pela implantação da REMEP-FLN e exerce atividades de consultoria em Redes e
Telefonia IP. Fez parte do corpo técnico que implantou a Telefonia IP na UFSC, responsável
pela concepção e desenvolvimento do novo fone@RNP (2012-2015).

Helder Vitorino Pernambucano, Mestre em Gestão do Conhecimento e Tecnologia da
Informação pela Universidade Católica de Brasília. Possui MBA em Gestão de Projetos,
Especialização em Engenharia de Software. É certificado como Project Management Pro-
fessional (PMP) pelo Project Management Institute (PMI). Atua há mais de 20 anos na área
de Tecnologia da Informação. Atualmente é Gerente de Serviços na Diretoria Adjunta de
Gestão de Serviços da Rede Nacional de Ensino e Pesquisa (RNP).

Jonatan Hartmann Matschulat é engenheiro de software com especialidade em desenvol-
vimento web e móvel. Graduado em Sistemas de Informação pela UFSC em 2010, desenvol-
veu seu projeto de conclusão de curso com o tema “Convergência de mídias em um ambiente
VoIP”. Possui mais de 8 anos de experiência em design e desenvolvimento web e atua há 5
anos como diretor de criação em uma empresa focada na construção de aplicativos móveis
para as plataformas iOS e Android.Ao longo de sua carreira profissional, participou de mais
de 30 projetos envolvendo tecnologias para telefonia IP, dispositivos móveis e sistemas web.

xii
Nestes projetos, contribuiu nas fases de concepção, validação, desenvolvimento, gerencia-
mento e implantação. Além das capacidades técnicas, possui conhecimentos e experiências
aprofundadas em gestão de equipes, desenvolvimento de negócios, empreendedorismo,
planejamento estratégico, processo de vendas e marketing digital.

Luís Fernando Cordeiro Analista de Tecnologia da Informação na Universidade Federal de
Santa Catarina (UFSC). Possui graduação em Sistemas de Informação (2012) e especializa-
ção em Engenharia e Arquitetura de Software (2015). É consultor do PoP-SC em projetos
como o MonIPÊ e Fone@RNP.

Murilo Vetter Possui mais de 10 anos de experiência em desenvolvimento de software
para redes. Graduado em Ciências da Computação pela Universidade Federal de Santa
Catarina - UFSC (2008). Mestre em Ciências da Computação pela Universidade Federal de
Santa Catarina - UFSC (2015). Atualmente é analista de redes da Rede Metropolitana de
Florianópolis – REMEP-FLN. Coordenador de desenvolvimento do serviço MonIPÊ da RNP.
Integrante do corpo técnico que implantou a Telefonia IP na UFSC, equipe responsável
pela concepção e desenvolvimento do novo fone@RNP (2012-2015). Possui experiência em
redes e desenvolvimento de software voltado para redes, mais especificamente em telefo-
nia IP e monitoração de redes IP. Atua em projetos de pesquisa de monitoração de redes IP
convencionais (MonIPê) e redes IP híbridas (MonCircuitos).

Paulo Alexandre de Oliveira Brandtner Analista de sistemas, atua como desenvolvedor
WEB e colaborador no Ponto de Presença da RNP em Santa Catarina, faz parte da equipe
do Fone@RNP e do serviço MonIPÊ da Rede Nacional de Ensino e Pesquisa. Graduado em
Sistemas de Informação pela Universidade Federal de Santa Catarina.

Thiago Maluf Bacharel em Ciência da Computação pela UFRJ e detentor da certificação
DCAP. Atuante na área de desenvolvimento de aplicações multimídias, principalmente
no setor de telefonia IP. Enquanto bolsista no Laboratório de Voz sobre IP da UFRJ, par-
ticipando da criação do projeto Fone@RNP. Atualmente, sócio e gerente de projetos da
empresa prestadora de serviços, CAM Tecnologia. Leciona a matéria de telefonia IP no Pro-
grama MOT-CN/NCE/UFRJ e o curso de Administração do Serviço Fone@RNP para Escola
Superior de Redes/RNP.

Wescley Patrick da Silva Natural de Arcoverde/PE, é graduado em análise e desenvol-
vimento de sistemas, possui especialização em segurança de redes de computadores, é
certificado em DELL DCSE Foundation 2010, ITIL Foundation, Digium dCCA. Possui experi-
ência em desenvolvimento de software, gerência de redes IP e Voz sobre IP. Já atuou como
professor colaborador em eventos pela Universidade de Pernambuco, foi monitor do curso
de fone@RNP na Escola Superior de Redes da RNP, foi um dos instrutores no SCI 2013 e
2015 nos cursos: Implementando o Novo fone@RNP (GWT) e Instalando e configurando a
PBX-IP, respectivamente. Atualmente, é, Analista de Operações da Rede Nacional de Ensino
e Pesquisa (RNP).

xiii
Abreviações utilizadas neste livro
CDR Call Detail Record (Detalhamento dos Registros de Chamadas)
DNS Domain Name System
GWT Gateway Transparente
GWT-a Gateway Transparente Analógico
ICMP Internet Control Message Protocol
IP Internet Protocol
NTP Network Time Protocol
PABX Public Automatic Branch Exchange
PBX Public Branch Exchange
POTS Public Old Telephony Service (utilizada como sinônimo de da rede analógica)
PSTN Public Switched Telephony Network
RTCP RTP Control Protocol
RTFC Rede de Telefonia Fixo Comutada
RTP Realtime Transport Protocol
SBC Session Border Controller
SDP Session Description Protocol
SIP Session Initiation Protocol
SNMP Simple Network Management Protocol
SRC SIP Router Central
SRL SIP Router Local
SRTP Secure RTP
TCP Transmission Control Protocol
ToIP Telephony over IP (Telefonia sobre IP)
UDP User Datagram Protocol
VoIP Voice over IP (Voz sobre IP)

xiv
Aviso!
O serviço fone@RNP, baseado na tecnologia de Voz sobre Protocolo Internet (VoIP), é uma
aplicação que utiliza a infraestrutura de redes IP para encaminhar ligações telefônicas. Por
isso mesmo, assim como qualquer outra implementação do serviço de telefonia sobre IP,
está sujeita às vantagens e desvantagens do IP.

Diante disso, a Rede Nacional de Ensino e Pesquisa possui o dever de informar que não é
responsável por quaisquer danos ou prejuízos causados pelo mau uso do serviço fone@
RNP, principalmente relacionados à qualidade das chamadas e à segurança contra invasões
e outros ataques aos dispositivos hospedados nos clientes.

A implantação e manutenção de um serviço de telefonia IP não é trivial, e requer profissio-
nais qualificados para exercer tais tarefas. É necessário que o profissional técnico respon-
sável pelo serviço na instituição esteja atento aos riscos da implantação do serviço de
telefonia IP. É fortemente recomendado que a instituição adote práticas de Qualidade de
Serviço (QoS) em sua rede IP. É imprescindível que ele promova e coordene o diálogo entre
as equipes de redes, segurança e de telefonia (ou equivalentes) de sua instituição. Além
disso, independente da adoção do PBX IP (educacional ou corporativa), lembramos que
continua sendo necessário que a instituição cliente mantenha uma equipe de suporte para
seu PABX, seja ela interna ou terceirizada.

A RNP se preocupa com a segurança do sistema e a qualidade das ligações. O fone@RNP é
dotado de uma série de funções e subsistemas que tratam essas questões de forma mais
eficiente possível.

xv
Agradecimentos
Mesmo correndo o risco de sermos injustos com algumas pessoas por não citá-las aqui, a
RNP gostaria de agradecer a:

Prof. Paulo Aguiar, Coordenador do LabVoIP, da UFRJ, que foi o pesquisador líder da cria-
ção da primeira versão do fone@RNP.

Alberto Wester, do Museu de Astronomia, que perseverou e ficou horas e horas testando e
apoiando a iniciativa desde a sua criação.

Emerson Ribeiro de Mello, em 2012 Diretor de Tecnologia da Informação e Comunicação
do IFSC, um grande impulsionador do serviço no estado de Santa Catarina, incentivando a
adesão, implantação e o uso no IFSC - Instituto Federal de Santa Catarina.

Glaidson Verzeletti do IFSC - Instituto Federal de Santa Catarina, campus Lajes, primeiro
campus a instalar de forma oficial a versão atualizada e por colaborar na elaboração da
documentação do GWT.

Rodrigo Lira do Instituto Federal da Paraíba, campus Campina Grande, primeiro campus
a instalar de forma colaborativa e de testes o PBX-IP, em funcionamento até hoje. Utiliza a
solução completa e oficial do fone@RNP no campus.

Gustavo Gomes, em 2013 fazia parte da equipe do IFBA - Instituto Federal da Bahia, colabo-
rou com diversas correções na documentação de instalação e configuração do GWT.

E tantos outros que diretamente e indiretamente ajudaram na elaboração deste exemplar
e na construção e evolução do fone@RNP.

Muito obrigado!

xvi
1
Apresentação
objetivos

Conhecer a RNP, os serviços avançados e como o serviço fone@RNP nasceu e vem
se desenvolvendo desde então.

conceitos
RNP; Serviços Avançados.

Visão básica da RNP
A Rede Nacional de Ensino e Pesquisa (RNP) foi a primeira rede de acesso à internet no
Brasil. Sua missão é promover o uso inovador de redes avançadas no país. Foi criada em
1989 pelo Ministério da Ciência e Tecnologia (MCT) com o objetivo de construir uma infra-
estrutura de rede internet nacional para a comunidade acadêmica. A rede começou a ser
montada em 1991. Em 1994, já estava presente em todas as regiões do país. Entre 2000 e
2001, a rede foi totalmente atualizada para oferecer suporte a aplicações avançadas. Desde
então, a rede Ipê possui pontos de presença em todos os estados brasileiros.

Desde 2002, é uma Organização Social (OS) vinculada ao Ministério da Ciência, Tecnologia
e Inovação (MCTI), e mantida por este em conjunto com os ministérios da Educação (MEC),
Cultura (MinC) e Saúde (MS).

Um universo estimado em mais de um milhão usuários da comunidade acadêmica brasi-
leira se beneficia dessa infraestrutura que estimula o progresso da ciência e da educação
superior no país.

A rede Ipê é a primeira rede óptica nacional acadêmica da América Latina, inaugurada pela
RNP em 2005. O backbone da rede Ipê foi projetado para garantir não só a largura de banda
necessária ao tráfego internet usual (navegação web, correio eletrônico, transferência de
arquivos), mas também o uso de serviços e aplicações avançadas e a experimentação.
A infraestrutura engloba 27 Pontos de Presença (PoPs), um em cada unidade da federação,
Capítulo 1 - Apresentação

além de ramificações para atender mais de 500 instituições de ensino e pesquisa em todo o
país, beneficiando mais de 3,5 milhões de usuários.

Em 2010, a rede Ipê passou por um grande salto qualitativo, atingindo a capacidade agre-
gada de 233,2 Gbps, aumento de 280% em relação à capacidade agregada anterior. Nessa
nova rede, que é a sexta geração do backbone operado pela RNP, as velocidades multigiga-
bits (acima de 1 Gbps) estão disponíveis para 24 dos 27 PoPs. A ampliação foi resultado de

1
acordo de cooperação com a empresa de telecomunicações Oi, que proverá à RNP infraes-
trutura de transmissão em fibras ópticas para uso não comercial e participará de projetos de
Pesquisa & Desenvolvimento (P&D) de interesse comum.

Agente de integração de iniciativas acadêmicas no Brasil e na América Latina, a RNP tem
papel de destaque na Cooperação Latino Americana de Redes Avançadas (RedCLARA). A
rede Ipê tem uma conexão de 1,45 Gbps com a rede dessa iniciativa, que integra atualmente
15 países da América Latina. Além disso, por meio de uma conexão de 20 Gbps operada
em parceria entre a RNP e a Academic Network at São Paulo (ANSP), a rede Ipê se conecta
a outras infraestruturas acadêmicas internacionais, como a norte-americana Internet2 e a
europeia Géant, e à internet comercial mundial.

Figura 1.1
Rede Ipê.

Serviços avançados na RNP
Desde 2000, a Rede Nacional de Ensino e Pesquisa (RNP) tem se dedicado à promoção do
uso de aplicações avançadas em redes de computadores. Telefonia sobre a rede internet, TV
digital transmitida pela rede, educação a distância, videoconferência IP e Identidade Digital são
algumas das aplicações que estão sendo implantadas na forma de serviços para os usuários.

Os serviços avançados disponibilizados pela RNP às suas organizações usuárias são o resul-
tado de processos de inovação e prospecção, de acordo com as necessidades dos clientes,
Serviço fone@RNP

em atividades de análise de cenários e tendências com parceiros como a academia, o setor
empresarial e as principais redes acadêmicas mundiais. Os principais benefícios dos ser-
viços da RNP são facilitar e promover a comunicação, a colaboração a distância e a dissemi-
nação de conhecimento.

2
As informações sobre os serviços disponibilizados pela RNP para suas organizações usuárias
e comunidades de clientes especiais e estratégicos encontram-se consolidadas no Catálogo
de Serviços, que são classificados da seguinte forma:

11 Comunicação e Colaboração;

11 Disponibilização de Conteúdos Digitais;

11 Gestão de Identidade;

11 Hospedagem Estratégica;

11 Suporte à Rede Acadêmica.

Comunicação e Colaboração
A RNP oferece aos seus clientes os seguintes serviços de comunicação e colaboração:
conferência web, fone@RNP, Videoconferência, Telepresença e fileSender@RNP.

Gestão de identidade
A RNP reúne as Instituições Federais de Ensino Superior (Ifes), Unidades de Pesquisa (UPs) e
demais instituições acadêmicas em uma rede de confiança, por meio dos serviços: Comuni-
dade Acadêmica Federada (CAFe) e Infraestrutura de Chaves Públicas para Ensino, Pesquisa
(ICPEdu) e eduroam.

Suporte à rede acadêmica
Gerenciado e operado pela RNP, o Ponto Federal de Interconexão de Redes (FIX) é um Ponto
de Troca de Tráfego (PTT) que viabiliza a interconexão entre redes, aumentando a eficiência
da transferência de dados.

Disponibilização de conteúdos digitais
Através de sua rede inteligente de distribuição de vídeo digital, a RNP provê os serviços de Vídeo
sob Demanda, Transmissão de Sinal de TV, Transmissão de Vídeo ao Vivo e Videoaula@RNP.

Hospedagem estratégica
O Internet Data Center (IDC) é o serviço de hospedagem de equipamentos e servidores
dentro do modelo conhecido como colocation. Esse serviço fornece uma infraestrutura
w de segurança, física e lógica, para clientes estratégicos para o sistema nacional de CT&I
O Catálogo de Serviços (Ciência, Tecnologia e Inovação), Cultura e Saúde, com garantias de disponibilidade e ope-
e outras informações ração ininterrupta.
podem ser encontradas
na página de Serviços
da RNP: Apoio a serviços
www.rnp.br/servicos/
servicos-avancados O Service Desk é uma instância de apoio, voltada à resolução de dificuldades que as institui-
ções que são clientes dos serviços possam encontrar na entrega, acesso ou utilização.
Capítulo 1 - Apresentação

O serviço Fone@RNP
O fone@RNP é o serviço que tem como objetivo interconectar a rede de telefonia dos
clientes da RNP. Ele utiliza a tecnologia de Voz sobre IP (VoIP). A solução começou a ser
desenvolvida em 2002, como um grupo de trabalho (GT) no âmbito do programa de

3
pesquisa e desenvolvimento, fomentado pela própria RNP. Melhoramentos nessa solução
l
O principal objetivo
permitiram pôr em produção e oferecê-la como serviço para as instituições de ensino e desse serviço é
pesquisa brasileiras. economizar recursos
financeiros com
Não há custo para adesão ao serviço. As instituições clientes do fone@RNP podem realizar chamadas de longa
distância para telefones
chamadas entre elas sem qualquer custo. Elas também podem realizar chamadas de longa
fixos, que no Brasil são
distância para telefones na rede pública de telefonia (RTFC), desde que haja na cidade-destino relativamente caras,
outro cliente do fone@RNP. Como esse é um serviço colaborativo, nenhuma das chamadas custando aproximada-
mente dez vezes mais
é cobrada da instituição que a originou, incluindo aquelas que terminaram na rede pública.
que uma ligação local.
Nesse caso, a universidade na cidade de destino da ligação é quem paga a conta dessas cha-
madas. Na prática, o custo das ligações a distância é convertido em custo de ligações locais,
gerando economia significativa, conforme comparação indicada no parágrafo anterior.

Ademais, os recursos financeiros que as instituições de ensino e pesquisa clientes do serviço
utilizam para pagar a conta de telefone têm a mesma origem orçamentária, ou seja, os
cofres do Governo. Então, quando as universidades economizam dinheiro, na verdade, o
Governo Federal é que está, de fato, economizando recursos.

Assim, expandir o número de clientes do fone@RNP é um fator muito importante não
apenas para o serviço ou para seus clientes, mas para tornar possível economizar mais
recursos públicos, no curto e longo prazos. Cada instituição que adere ao serviço tem a
oportunidade de economizar não apenas para ela mesma, mas também ajuda a outras insti-
tuições a economizar da mesma forma.

O GT-VoIP
O serviço Fone@RNP é fruto direto de um programa de Pesquisa e Desenvolvimento da RNP.
Teve como marco inicial a criação do Grupo de Trabalho – VoIP em maio de 2002, com a ideia
de pesquisar e gerar um produto final que funcionaria como alternativa ao tradicional sistema
de telefonia. O objetivo principal do GT é a implantação de um serviço experimental de tele-
fonia no backbone RNP, permitindo às instituições usuárias utilizar suas redes para estabe-
lecer comunicação de voz a partir de seus PBXs, telefones IP e/ou estações de trabalho.

Como produto final desse GT, em 2004 o LabVoIP do NCE/UFRJ definiu a arquitetura e
implantou o serviço Fone@RNP em 17 instituições-piloto em 10 estados do território
brasileiro. Nesse momento, comunicação de voz sobre IP não era mais novidade devido à
popularidade de sistemas como o MSN ou Skype, que permitiam aos usuários realizarem
comunicação de computador para computador.

Não obstante a isso, o serviço Fone@RNP permite a comunicação não só com os disposi-
tivos VoIP do computador, mas também integra o serviço aos ramais convencionais das
instituições e aos números da rede pública de telefonia, RTFC. A integração dos números
da rede pública faz parte da ideia colaborativa do serviço. As chamadas originadas em uma
instituição serão encaminhadas por outro cliente situado na mesma localização do destino
discado, realizando uma chamada local para alcançar o telefone destino.

O projeto VoIP4All
Serviço fone@RNP

Com a evolução do Grupo de Trabalho GT-VoIP a serviço, houve a necessidade de expandi-
-lo para mais instituições usuárias. Para essa demanda, a RNP criou o projeto VoIP4All, que
teve como objetivo a adesão de 77 instituições ao serviço em todo o país. Foram adquiridos
servidores, placas de interface de telefonia, telefones IP básicos e telefones IP Avançado.

4
Sendo parte do projeto, o LabVoIP foi contratado para prestar suporte às instituições
durante o período de implantação do serviço e para desenvolver o treinamento básico e
avançado ao serviço, oferecidos a dois técnicos de cada instituição beneficiada pelo projeto.

Os treinamentos se dividiram em quatro turmas básicas e quatro turmas avançadas, totalizando
assim 164 alunos de 82 instituições (7 instituições foram convidadas, além das 77 iniciais).

Projeto de melhoria do fone@RNP
Seguindo o caminho da evolução do serviço, em 2012 a RNP deu início ao projeto de
melhoria do fone@RNP. Nessa ocasião, o serviço foi totalmente redesenhado. Sua estrutura,
que antes era dependente de dois servidores em cada cliente, foi completamente modulari-
zada, permitindo maior escalabilidade, maior confiabilidade e aumenta consideravelmente
sua eficiência. Como resultado, o serviço é capaz de conferir maior economia para seus
clientes. Além disso, também foi desenvolvido um módulo com funções de um PABX tradi-
cional, inexistente na versão anterior.

Para identificar as versões do fone@RNP, chamamos a versão mais antiga de distribuição
2008 e a mais nova de distribuição 2012. Este livro se dedica a apresentar a nova versão, a
distribuição 2012 do fone@RNP.

A próxima figura apresenta a arquitetura do fone@RNP distribuição 2012, com seus módulos
e conexões com outras redes que oferecem serviço de telefonia IP.

SBC
Para redes externas
SRC

GWT SRL SRL SRL ...

PBX PSTN PBX IP PBX IP GWT GWT PBX IP SRL GWT
Tradicional 3os Corporativo Qualquer

PBX PBX PBX IP GWT Cell
PSTN Tradicional PSTN Tradicional PSTN PSTN

PBX
Tradicional PSTN

Figura 1.2 O detalhamento das funções de cada módulo será apresentado em um capítulo adiante.
Arquitetura do
fone@RNP.
Evolução dos clientes do fone@RNP
A evolução da telefonia IP, principalmente do protocolo SIP, e as novas demandas solicitadas
ao serviço Fone@RNP, o levaram a uma nova arquitetura baseada no SIP.

Essa evolução forneceu uma reestruturação das instituições participantes. A etapa de
Capítulo 1 - Apresentação

instalação do serviço na instituição passou a ser automatizada com scripts de instalação e
arquivos de configurações padrão, e informações de roteamento foram transferidas à base
de dados. Tais alterações forneceram ao serviço um novo patamar de estabilidade e agili-
dade na implantação e manutenção.

Em paralelo ao projeto de melhoria, em 2012 também foi executado o projeto de ampliação
dos clientes do fone@RNP. Dada a sua importância e sucesso, o projeto foi repedido ano
após ano até o momento da escrita deste livro.

5
Expandir o número de clientes do fone@RNP é um fator muito importante não apenas para
seus clientes, mas para tornar possível economizar mais recursos públicos da União, no
curto e longo prazos. Cada instituição que adere ao serviço tem a oportunidade de econo-
mizar não apenas para ela mesma, mas também ajuda a outras instituições a economizar da
mesma forma.

Em março de 2012, o serviço Fone@RNP contava com a participação de pouco mais de
100 instituições usuárias compostas por unidades de ensino federais, unidades da RNP,
unidades da EMBRAPA e instituições convidadas. A partir daí, também os Institutos Federais
de Educação, Ciência e Tecnologia (IFs) começaram a aderir ao serviço.

A próxima figura mostra o crescimento dos clientes do fone@RNP.

As duas rampas entre 2009-2010 e 2012-2013, degraus em 2014 e outra rampa em 2015
evidenciam os projetos com objetivo de ampliar o número de clientes do serviço.

Em janeiro de 2014, o serviço passou a contabilizar apenas as instituições ativas, o que
explica a redução no número de instituições nessa data.

Histórico Completo
250

200

150

100

50

0
jan/08

mai/08

set/08

jan/09

mai/09

set/09

jan/10

mai/10

set/10

jan/11

mai/11

set/11

jan/12

mai/12

set/12

jan/13

mai/13

set/13

jan/14

mai/14

set/14

jan/15

mai/15

set/15

Figura 1.3
Alcance do fone@RNP Movimentação de
clientes.
Além de encaminhar chamadas entre as instituições participantes do fone@RNP, o serviço
também completa chamadas para telefones na rede pública em toda cidade onde há um cliente.

Caso haja indisponibilidade temporária em qualquer localidade, as chamadas serão encami-
nhadas normalmente, de forma transparente, através da rede pública.

Alcance internacional do fone@RNP
Além das universidades e instituições brasileiras, o fone@RNP também é capaz de encami-
nhar ligações via IP de forma transparente para instituições clientes das Redes Nacionais de
Serviço fone@RNP

Pesquisa (NRENs) de vários países. Para isso, o fone@RNP utiliza uma tecnologia chamada
Eletronic Number Mapping (ENUM) e consulta as árvores e164.arpa e NRENum.net. Há
também casos onde a RNP estabelece acordos bilaterais com entidades em outros países ou
instituições internacionais, como a RedClara.

6
w A disponibilidade do serviço nas instituições desses países não está sob controle da RNP,
Confira a lista de e depende das Redes Nacionais e da própria instituição de destino. Da mesma forma, caso
instituições nacionais não seja possível encaminhar a ligação pela rede IP, as chamadas serão completadas nor-
clientes e de outros
países com quem a malmente, de forma transparente, pela rede tradicional de telefonia.
RNP é capaz de encami-
nhar ligações via SIP na
página do serviço, no
Processo de adesão ao fone@RNP
portal da RNP.
A adesão ao serviço é aberta a todos as instituições clientes da RNP que disponham de
técnicos com conhecimento básico em VoIP para realizar a gestão e a operação da infraes-
trutura local. As instituições também devem contar com uma conexão adequada à Rede Ipê
para suportar o tráfego decorrente da demanda.

A solicitação deverá ser realizada pelo contato técnico da instituição usuária, estando de
acordo com a sua Política de Uso e ciente sobre o Guia do Usuário, enviando uma mensagem
para o Service Desk pelo e-mail sd@rnp.br.

Os profissionais da RNP responderão ao contato enviando a Política do Serviço e o Termo de
Adesão, onde a instituição formaliza a sua concordância com a Política e indica os profissionais
que serão os responsáveis pelo serviço junto à RNP. Esses técnicos também são convidados
a preencher um formulário descrevendo seu ambiente de telefonia. Logo depois, é marcada
uma entrevista técnica entre os profissionais da instituição e da RNP, visando encontrar a
melhor solução para atender às necessidades das instituições. Depois disso, a RNP auxilia com
a instalação e configuração da solução, até sua completa homologação no fone@RNP.

Capítulo 1 - Apresentação

7
8
Serviço fone@RNP
2
Introdução à telefonia
objetivos

Obter um resumo dos jargões, conceitos básicos e de uso frequente envolvidos na
área de telefonia.

conceitos
Telefonia analógica e digital; PCM; TDM; RTFC; RDSI; ISDN; R2; E1; HMM; GoS;
Tráfego telefônico; Tabelas de Erlang.

Um pouco de história
Assim como diversas outras áreas da ciência moderna, a telefonia teve como impulso a des-
coberta da eletricidade e do magnetismo, em 1830, por Michael Faraday.

A primeira invenção feita após essa descoberta foi a do telégrafo elétrico, criado por Samuel
Morse, em 1837. Invenção que permitiu a comunicação entre dois pontos ligados por fios
condutores de eletricidade.

A invenção do telefone é um tópico de grande discussão, já que três cientistas se apre-
sentam na história como seus inventores. Inicialmente o italiano Antonio Meucci, em 1851,
construiu um telefone eletromagnético nomeado de telettrofono, para conectar seu escri-
tório ao seu quarto, localizado no andar acima, para se comunicar com a sua esposa, que
sofria de reumatismo.

Passando por dificuldades financeiras, Meucci não pôde dar continuidade à sua invenção,
e acabou vendendo a Alexander Graham Bell. Bell utilizou a descoberta de Meucci para dar
continuidade a suas pesquisas sobre o telefone. Em 1876, Bell patenteou o telefone, mesmo
sem ter ainda conseguido realizar uma ligação, na U.S. Patent Office. Curiosamente, sua
requisição chegou horas antes de outro inventor, Elisha Gray.
Capítulo 2 - Introdução à telefonia

Com a patente obtida, Bell pôde trabalhar tranquilamente na sua invenção e posteriormente
fundar a American Telephony & Telegraphy Company (AT&T). O sistema de telefonia desenvol-
vido por Bell inicialmente definia uma comunicação ponto a ponto entre dois equipamentos,
sendo um deles ativo – gerando pulso elétrico – e outro passivo – não gerando pulso elétrico.

9
Circuito elétrico equivalente
Deixando de lado as discussões sobre a paternidade da telefonia, desde sua invenção até
a era digital, não houve muitas mudanças na forma de transportar a voz de um ponto ao
outro. O esquema básico para que um aparelho telefônico pudesse se comunicar com outro
aparelho sempre foi modelado com um circuito elétrico. De fato, o conjunto de telefones e
fios realmente forma um circuito elétrico fechado, conforme ilustrado na figura a seguir.

Linha telefônica
Receptor

Transmissor

Grãos de carbono

Transmissor

Receptor
Figura 2.1
Circuito equivalente
Alimentação de dois telefones.

Inicialmente, um par de fios ligava dois telefones. Se um desses quisesse falar com outro
ponto, outro par de fios era lançado entre ele e o novo participante. Seria necessário ligar
todos os locais a todos os outros locais onde fosse necessária a comunicação.

Usando essa arquitetura, a telefonia expandiu-se de forma desorganizada, já que locais deti-
nham mais de um telefone para que fosse possível se comunicar com localidades diferentes,
observando que cada telefone se comunicava com apenas uma localidade.

Por exemplo, para interligar três pontos, A, B e C, seria necessário haver dois telefones em
cada localidade. No ponto A, um telefone e seu circuito se liga ao ponto B e outro telefone e
seu circuito se liga a C. Da mesma forma, no ponto B haveria o segmento BA e BC e, em C, os
segmentos CA e CB.

A
Serviço fone@RNP

B C

Figura 2.2
Rede ponto-a-
ponto de três nós.

10
Aumentando para 12 pontos em uma cidade, não bastaria haver 12 +[12x(12-3)]/2= 66 linhas
(quantidade de diagonais mais lados). Seria preciso também haver dois telefones para cada
uma das 66 linhas, ou seja, 132 telefones divididos nas 12 localidades. Exatamente 11 telefones
para cada um dos 12 pontos!

Figura 2.3
Rede
ponto-a-ponto
de 12 nós.

Logo se percebeu que essa “arquitetura de rede” não era adequada, pois, no mínimo, era de
difícil expansão.

Arquitetura hierárquica e em estrela
Bell identificou também esse problema e planejou uma comunicação hierárquica de tele-
fonia, implantando centrais de telefonia nas cidades e definindo todos os telefones insta-
lados como assinantes dessa central.

Figura 2.4
Rede em estrela
de 12 nós.
Capítulo 2 - Introdução à telefonia

Os assinantes eram interligados às centrais e a partir das centrais poderiam se comunicar
com qualquer outro assinante. Esse sistema evoluiu até os dias de hoje e atualmente não
há a necessidade de solicitar à telefonista da central para estabelecer a comunicação com o
assinante final, e as inúmeras centrais existentes nas diversas cidades podem ser comunicar.

11
Figura 2.5
Rede
(ponto-a-ponto)
de redes (estrela).

A nova topologia também tentava resolver problemas de disponibilidade, inserindo enlaces
duplicados. O desenho era um misto de malha no núcleo e estrela nas bordas, próximo aos
terminais telefônicos. A próxima figura ilustra essa arquitetura mista, onde é possível
identificar um núcleo em malha formando uma estrela de novas malhas intermediárias que,
no acesso, volta a formar estrelas para alcançar o usuário final.
Serviço fone@RNP

12
x281 x307 x401

703-330-3305
(DDR)

PBX Empresa XPTO
3000 202225-6827

PBX

RDSI
PSI
6827
(DDR)
CO
CO IOT CO IOT CO
266
330 874 225
815
4129

IO
IO

T
T
IOT

IOT

IOT

IOT
T
T

IO
IO

CO FEX IOT FEX CO
365 703 202 619
IOT IOT

8134 TRONCOS
IOT

Enlace Digital IOT
Cobre
Grupos de 32 pares
FEX FEX IEX
802 IOT 757 IOT +011

LOOP LOCAL
1828 Voz analógica
Par trançado de cobre

CO = Central Office -> Central Local
FEX = Federal Exchange -> Central Trânsito Nacional
IEX = International Exchange -> Central Internacional

Figura 2.6 Depois de algum tempo, umas ideias foram evoluindo e outras perecendo. Os telefones
Exemplo de rede ganharam teclas que podiam ser usadas para alcançar endereços específicos na rede de
telefônica, com
centrais e terminais telefonia e, conjuntamente, as centrais foram se tornando automáticas, com comutação dos
telefônicos. circuitos sendo executadas por relés.

Ao mesmo tempo em que as telefonistas iam perdendo seus empregos, maior quan-
tidade de telefones podia ser inserida no sistema.
Capítulo 2 - Introdução à telefonia

Encaminhamento das chamadas
Para efetuar uma ligação telefônica, o usuário deve digitar a rota até seu destino final. Por
exemplo, +55 21 2102-9600, o número do escritório da RNP no Rio de Janeiro, é definido
pelas rotas +55 = Roteadores do Brasil + 21 = roteadores da cidade do Rio (e vizinhança) +
2102 = endereço da central local que atende a área entre Botafogo e Urca, na porta que leva
ao PABX da RNP + 9600 = número do ramal a ser alcançado dentro do PABX da RNP.

13
Hoje, a portabilidade mudou um pouco essa lógica, e um número de telefone pode ser
alocado para outra localidade ou mesmo para outra operadora telefônica. Dito de outra
forma, o endereço de um telefone não está mais diretamente atrelado à rota para alcançá-lo.

A seguir, a figura ilustra a comparação de tamanho entre uma central dos anos 50 em
relação à altura de um homem.

Figura 2.7
Exemplo de central
telefônica dos
anos 50.

Protocolos e sinalização
Para tornar a automação de ligações telefônicas possível, era necessário criar um código que
todos os telefones e centrais entendessem. Algumas tentativas de construir um protocolo
de sinalização foram experimentadas. Algumas usavam 8 ou 7 fios, que foram deixadas de
lado para dar lugar a protocolos que utilizam 2 fios por assinante.

Normalmente, a sinalização analógica utiliza a janela de frequências que o ouvido humano
é capaz de perceber e pode ser realizada utilizando os mesmos fios que são utilizados para
transportar a voz. Por isso é possível ouvir os tons de controle como ocupado e chamando,
os pulsos produzidos ao se discar um número em telefones mais antigos e, mais atualmente,
o DTMF (Dual Tone Multi-Frequency), utilizado para enviar para a central os dígitos de 0 a 9
mais “*” e “#”, e outros 4 símbolos adicionais, ABCD.

Em 1927, a primeira chamada de voz transatlântica foi feita utilizando ondas de rádio. Ino-
vações durante as duas Grandes Guerras fizeram surgir os primeiros telefones móveis. Nos
anos 60, os telefones passavam a ser endereçados apenas por caracteres numéricos e os
primeiros cabos transatlânticos eram lançados para possibilitar as ligações intercontinen-
tais. Em 1962, foi lançado o primeiro satélite para telefonia.

Ainda na era analógica, surgiu também a telefonia celular. Assim como no início do surgi-
mento dos telefones fixos, os telefones celulares eram caros e pouco eficientes. A seguir, as
figuras ilustram exemplos de telefones móveis.
Serviço fone@RNP

14
Figura 2.8
Um dos primeiros
telefones celulares.

Figura 2.9
Comparação entre
telefones celulares.

Hoje em dia, na maior parte do Brasil, apenas as ligações entre o assinante residencial e a
central da rede fixa é analógica. Nas empresas, semelhante à situação do assinante residencial,
a ligação dos ramais ao PABX também é feita de forma analógica na grande maioria das vezes.

Telefonia digital
Após alguns anos, a tecnologia digital evoluiu e se mostrou mais confiável, mais econômica
e mais eficiente que a analógica. A transmissão digital de dados começou a substituir a
tecnologia analógica.

Capítulo 2 - Introdução à telefonia

Figura 2.10
Exemplo de
telefone digital.

Hoje, para ligação entre centrais telefônicas, normalmente se utiliza tecnologia digital.
Os tons de controle, mensagens de linha, os dígitos e até a voz são agora enviados entre
as centrais utilizando bits 0 e 1. Não é comum no Brasil, mas também é possível utilizar
comunicação digital entre um telefone residencial e a sua central. Nas empresas, a situação

15
é semelhante: telefones digitais são usados para um número reduzido de funcionários, pois
eles são mais caros e poucas pessoas realmente precisam das funcionalidades adicionais
suportadas por esses telefones.

A rede de telefonia cresceu e a tecnologia avançou. As centrais deixaram de ser eletrome-
cânicas e surgiram as CPAs, ou Centrais de Programa Armazenado, que são como computa-
dores especializados em realizar a comutação das ligações. Consequentemente, protocolos
de sinalização mais adequados foram desenvolvidos. Entre eles podemos destacar o
Sistema de Sinalização nº 7, SS7 (da família ITU Q.7xx), muito utilizado entre as centrais das
operadoras de telefonia e a Rede Digital de Serviços Integrados, RDSI (ITU Q.931) – ou ISDN

l
em inglês – mais utilizado nas comunicações entre as centrais das companhias operadoras e
os PABX digitais dos assinantes.
Na América Latina
No Brasil, a sinalização definida como padrão para a comunicação entre a operadora e o também é comum o
assinante de tronco digital é a R2-D/MFC-5C (Multi Frequencial Compelida) – Prática Telebrás uso da sinalização
R2-Digital.
SDT 210.110.703. Entretanto, várias operadoras de telefonia oferecem para seus assinantes
de troncos digitais o protocolo ISDN, que é mais moderno e mais rápido.

Também a rede de telefonia celular evoluiu para uma rede digital. No Brasil, a Anatel
(Agência Nacional de Telecomunicações) chegou a marcar data, 30/6/2008, para o fim das
operações com celulares analógicos. Entretanto, a agência resolveu suspender a decisão,
adiando para fevereiro de 2013 o desligamento do sistema. E, mais uma vez, a agência
resolveu dar uma sobrevida à rede analógica de celular até dezembro de 2015, por conta
de clientes do RuralCel, um serviço de telefone fixo onde não há cabeamento de linhas con-
vencionais. De acordo com a Anatel, em meados de 2010 já não havia mais linhas celulares
analógicas ativas no Brasil.

Digitalização da voz: PCM
O acrônimo PCM significa Pulse-Code Modulation, que em português pode ser traduzido
como Modulação por Código de Pulso. Essa modulação atribui códigos de 8 bits a pulsos
amostrados e quantizados. São 8.000 amostras por segundo, a partir de um sinal analógico
que pode variar de 1 Hz até 4 kHz.

Não é por coincidência que esse intervalo contém o intervalo de frequência da voz humana,
que varia de 300 Hz até 3 kHz. E ainda bem que o ouvido humano também capta e entende
sinais nessa faixa de frequência!

O PCM pode ser compreendido como o processo de digitalização da voz utilizado no serviço
telefônico. Esse processo é compreendido por quatro etapas, onde as três primeiras são
Figura 2.11
muito evidentes. Amostragem,
Quantização e
Amostragem > Quantização > Compressão > Codificação Codificação.

00110101111010
Amostragem Quantização Codificação
Serviço fone@RNP

O padrão G.711 utiliza o PCM para digitalização da voz e as leis de compressão lei-A (a-law),
utilizada na Europa e no Brasil, e Lei-μ (u-law), mais utilizada nos Estados Unidos e Japão.

16
Amostragem

Amplitude
Amostragem
111
110
101
100
Tempo
000
001
011
010

Figura 2.12 Na amostragem, como o próprio nome diz, são retiradas amostras do sinal de voz em
Amostragem. intervalos regulares de tempo, o intervalo de amostragem. A quantidade de amostras no
tempo é a frequência de amostragem. Segundo o Teorema de Nyqist, é necessário que a
frequência de amostragem seja o dobro (ou maior) que a frequência máxima do espectro do
sinal. Nesse caso, um sinal de 4kHz implica 8.000 amostras por segundo.

Quantização
V
Níveis de Decisão

T

V
Sinal Quantizado

T
Capítulo 2 - Introdução à telefonia

Figura 2.13
Quantização.

A quantização é o processo de conversão da amplitude da amostra obtida na etapa anterior
em valores discretos predefinidos. São utilizados 256 intervalos de quantização no G.711.

Esse processo insere pequenas dissorções do sinal quantizado em relação ao sinal real.

17
Níveis de
Quantização Quantização

111
110
101
100
Tempo
000
001
011 Figura 2.14
010 Erro de
quantização.

Com o objetivo de minimizar a dissorção causada pela quantização, nessa etapa também
ocorre o procedimento de compressão. Há duas possibilidades para a compressão: lei-A ou
Lei-μ, ambas descritas na recomendação G.711.

Codificação

Codificação
111
110
Códigos de Pulsos

101
100
Tempo
000
001
011
010
Sequência
Binária

000 010 011 110 111 101 010 011 110 111 100

Tempo

A codificação é a maneira como os níveis quantizados são representados de forma binária. Figura 2.15
Para representar os 256 níveis de quantização, são necessários 8 bits (28=256). Codificação.

As 8.000 amostras por segundo vezes 8 bits por amostra resultam uma taxa de bits de
64.000 bits por segundo (64kbps).

O que é TDM?
É muito comum os profissionais de telefonia se referirem à telefonia tradicional utilizando o
termo “TDM”.

TDM significa Time Division Multiplexing, que em português quer dizer Multiplexação por
Serviço fone@RNP

Divisão de Tempo. Em outras palavras, é o compartilhamento de um meio de transmissão
por diversas fontes de informação, utilizando o tempo como referência para mesclar essas
informações.

No caso da telefonia, as fontes de informação são as linhas ou canais telefônicos.

18
As chamadas telefônicas são digitalizadas e transformadas em bits. Depois, as várias
chamadas são organizadas e enfileiradas formando um único “trem de bits”. Esse trem de
bits é encaminhado pelo meio de transporte utilizando a técnica TDM.

10100110 01001101 00101101 00111010 ..... 00101101
Figura 2.16
Trem de bits e slots 8 bits
de tempo.
32 ‘slots’ de tempo
64 kbps x 32 canais = 2048 Mbps

TDM é uma técnica de transmissão digital utilizada largamente nos enlaces de telefonia
entre operadoras e centrais privadas, os PABX. Essa técnica simula a divisão de tempo em
fatias (ou slots) digitais. Cada fatia transporta um canal, ou seja, uma ligação. Na prática,
o que o TDM faz é utilizar o meio de transmissão para transmitir mais de uma informação
(quase) ao mesmo tempo.

E1/T1 e PDH
Os equipamentos nas pontas dos enlaces TDM não precisam ter seus relógios sincronizados.
Em vez disso, cada linha de transmissão possui seu próprio sincronismo. Cada um com seu
equipamento par, após configuração de um como Master e outro como Slave, no próprio
trem de bits, no quadro 0, o equipamento Master envia a informação de sincronismo.
O equipamento Slave recebe a informação e sincroniza a linha de transmissão. Agora será
possível para ambos realizar a multiplexação dos 32 canais, um após o outro.

Esse método de sincronização é chamado plesiócrono, ou quase síncrono. Com esse método
foi possível criar toda uma hierarquia de comunicação, multiplexando cada vez mais infor-
mação no mesmo meio de transmissão. Essa hierarquia é chamada de PDH (Plesiochronos
Digital Hierarchy) ou Hierarquia Digital Pesiócrona.

Um enlace E1 é o primeiro degrau na hierarquia PDH. Cada agregação de quatro canais E1
forma o próximo no nível da hierarquia para um canal E2, de 8 Mbps. Ao agregar quatro
canais E2 a hierarquia sobe para um canal E3, de 34 Mbps. Quatro E3 formam um E4, de
140 Mbps. Até quatro E4 formarem um E5, de 565 Mbps.

2.048 Mpbs

8.448 Mpbs
E1-E2
34.368 Mpbs
E2-E3
139.264 Mpbs
E3-E4
565.148 Mpbs
E4-E5
Capítulo 2 - Introdução à telefonia

Figura 2.17 Em telefonia, dos 32 canais de uma E1, dois são utilizados para sincronismo e sinalização e
Hierarquia PDH. nos outros 30 canais são transmitidas as ligações telefônicas.

Outra característica dos canais E1 é que há um meio de transmissão em um sentido e outro
meio de transmissão no sentido contrário. Dito de outra forma, o A linha E1 que liga os equi-
pamentos A e B possui dois “cabos”: um para enviar informação de A para B e outro para
enviar informação de B para A.

19
Tx Rx
Central Telefônica
PBX IP do cliente
da operadora
Rx Tx
Figura 2.18
Ramais Dois canais
telefônicos unidirecionais.

Há outras formas de combinar canais. Nos Estados Unidos e no Japão, o canal básico de
64 kbps é multiplexado em enlaces de 24 canais, totalizando 1.544 Mpbs. É conhecido por
T1, ou DS1. Daí, seguem agregando de 4 em 4, formando a hierarquia até T4 ou DS4.

RDSI ou R2-Digital
Esses dois termos causam bastante confusão para quem está começando a estudar Voz
sobre IP e não tem conhecimento em telefonia. Ambos se referem à sinalização telefônica.
Para que uma ligação ocorra, centrais telefônicas trocam sinalização de linha (ocupado,
chamando, livre) e sinalização entre registradores (números envolvidos, categorias). Eles são
o equivalente digital para esses sinais.

R2-Digital
No Brasil é instituído o uso de R2-Digital para sinalização de linha e MFC para sinalização de
registro. A R2D/MFC é uma Sinalização por Canal Associado (CAS). Isso significa que a sinali-
zação de cada chamada ocorre pelo mesmo canal que a ligação está sendo executada. MFC
é o acrônimo para Multifrequencial Compelida, que indica que cada dígito ou informação é
enviado utilizando um sinal DTMF (Multifrequencial), e que a próxima informação só segue
depois de se receber uma resposta do outro equipamento. A sinalização MFC possui variantes.
O R2 Digital é utilizado em vários países da América Latina. No Brasil é utilizada a variação 5C.
l
Interessante: houve
RDSI/ISDN uma tentativa de
implantar o sistema
digital para o assinante
O protocolo RDSI: Rede Digital de Serviços Integrados (do inglês ISDN: Integrated Services
de telefonia. O produto
Digital Network) é mais atual e mais rápido que o R2. Ele é uma Sinalização por Canal foi introduzido pela
Comum (CCS), que utiliza um único canal, o 16o slot de tempo, para transmitir a sinalização antiga Telemar, sob o
nome de DVI, mas não
dos outros 30 canais de voz, no caso uma E1. Essa configuração é também conhecida como
vingou. A tecnologia
30B+D. utilizava a configuração
2B+D, com dois canais
O RDSI (ISDN) é utilizado nos Estados Unidos e em grande parte do mundo. para voz (ou ‘internet
discada’) e um para
No Brasil, várias operadoras entregam enlaces RDSI. Algumas oferecem um pouco de resis- sinalização.
tência. Outras até preferem essa sinalização.

Cabos e conexões
Para transportar toda essa informação no formato de zeros e uns (0 e 1) é necessário um meio
físico, um meio de transporte desenhado especificamente para esse tipo de informação.

Normalmente, ao se adquirir um ou mais enlaces E1 com a operadora telefônica local, inde-
pendente do protocolo (ISDN ou R2D), o que se recebe são portas Rx e Tx, um par para cada
Serviço fone@RNP

E1 contratada, na forma de conectores coaxiais como os da figura a seguir.

20
Figura 2.19
Conectores BNC
(fêmeas) na régua
de E1s. (tarifários).

Esses são conectores BNC-fêmea. Os cabos coaxiais devem ter impedância de 75 Ohms e
máximo de 400 metros. Mesmo assim, a grande maioria das instalações não chega a
10 metros. Frequentemente, se utiliza cabos finos. Os conectores devem ser BNC-macho,
como na figura a seguir.

Figura 2.20
Cabo coaxial
para E1.

Figura 2.21
Conector BNC
Macho.

Entretanto, alguns PABX possuem conectores ligeiramente diferentes. A seguir, exemplos de
conectores e adaptadores do tipo IEC e do tipo F.
Capítulo 2 - Introdução à telefonia

Figura 2.22
Vários tipos de
conectores.

21
Figura 2.23
Mais conectores
diversos.

Tráfego e dimensionamento de canais
Os canais de telefonia são um recurso caro, finito e, em alguns casos, escasso. É necessário
otimizar ao máximo sua utilização. Por exemplo, um escritório com 100 ramais normalmente
não possui 100 canais de saída/entrada para a rede pública de telefonia. Observe que na
maior parte do tempo os ramais dos colaboradores ficam desligados, no gancho. Além disso,
é possível observar que há períodos de maior ou menor utilização dos telefones durante o
decorrer do dia. As mesmas observações podem ser feitas para tipos diferentes de escritó-
rios, bairros, campus ou toda uma universidade.

Então, para dimensionar a quantidade ideal de linhas telefônicas que vai atender a uma loca-
lidade, é preciso saber quantos ramais são utilizados simultaneamente durante o período de
maior utilização do dia.

Para otimizarmos o sistema, é necessário calcular o número ideal de canais com a rede
pública. A esse cálculo dá-se o nome de dimensionamento de canais. Para tanto, é necessário
conhecer o conceito de tráfego telefônico, o conceito de grau de serviço e as tabelas de Erlang.

Tráfego Telefônico (A)
A intensidade de tráfego em um sistema telefônico pode ser definida como o somatório dos
tempos das chamadas telefônicas em um determinado período de tempo. É comum utilizar
o período de uma hora, medindo-se geralmente nos 60 minutos mais movimentados.

Hora de Maior Movimento (HMM)
O período de 60 minutos (hora) cuja ocupação dos canais é máxima é conhecido como HMM,
a Hora de Maior Movimento. A HMM é encontrada através de simples observação do inte-
resse de tráfego telefônico de determinada localidade.
Figura 2.24
Perceba no gráfico a seguir que há dois períodos no dia onde o tráfego telefônico é elevado, Perfil de tráfego
sendo o intervalo de 10 horas da manhã o de maior movimento. telefônico.

220 Duração realizada
200
Duração recebida
180
160
140
120
Serviço fone@RNP

100
80
60
40
20
0 hs
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

22
Voltando ao cálculo do tráfego, por exemplo, o escritório hipotético citado acima faz
15 chamadas de 2 minutos cada (em média) durante sua HMM. Podemos afirmar que o
tráfego durante a hora mais movimentada do dia é

A= (15 chamadas x 2 minutos) / 60 minutos = 30 minutos / 60 minutos
==> A = 0,5 Erl

Note que o Tráfego é uma divisão de tempo por tempo, resultando em uma medida adimen-
sional chamada Erlang (Erl).

Grau de Serviço (GoS)
Grau de Serviço (GoS) é definido como o percentual de chamadas da oferta total de tráfego
que se admite perder, ou seja, é o percentual de chamadas que podem ser perdidas por falta
de canais disponíveis. Esse valor é assumido (“chutado” não seria a melhor palavra!) pelos
administradores ao realizar o dimensionamento.

Continuando no escritório do exemplo, admite-se perder 0,3% das tentativas de chamadas
para fora do escritório. Nesse caso, GoS = 0,3%.

Dimensionamento de canais e tabelas de Erlang
Para calcular o número de canais necessários para atender às especificações de um sistema
de telefonia, existe uma fórmula um tanto complicada que está apresentada a seguir a título
de ilustração, mas vamos poupá-los de decifrar.

N
A
Figura 2.25 N!
P =
Fórmula que dá b N Ai
origem à tabela Σ
de Tráfego. i=0 i!

11 A = Tráfego Oferecido;

11 N = Número de Canais para escoar o tráfego;

11 Pb = Probabilidade de Bloqueio.

Em vez da longa explicação da fórmula, apresentamos as tabelas de Erlang. Com elas é pos-
sível obter o número de canais necessários para atender à demanda, considerando o GoS.

Tronco

N 0,01% 0,02% 0,03% 0,05% 0,1% 0,2% 0,3% 0,4% 0,5%

1 ,0001 ,0002 ,0003 ,0005 ,0010 ,0020 ,0030 ,0040 ,0050
2 ,0142 ,0202 ,0248 ,0321 ,0458 ,0653 ,0806 ,0937 ,105
3 ,0868 ,110 ,127 ,152 ,194 ,249 ,289 ,321 ,349
Capítulo 2 - Introdução à telefonia

4 ,0235 ,282 ,315 ,362 ,439 ,535 ,602 ,656 ,701
5 ,452 ,527 ,577 ,649 ,762 ,900 ,994 1,07 1,13

6 ,728 ,832 ,900 ,996 1,15 1,33 1,45 1,54 1,62
7 1,05 1,19 1,27 1,39 1,58 1,80 1,95 2,06 2,16
8 1,42 1,58 1,69 1,83 2,05 2,31 2,48 2,62 2,73
9 1,83 2,01 2,13 2,30 2,56 2,85 3,05 3,21 3,38
10 2,26 2,47 2,61 2,80 3,09 3,43 3,65 3,82 3,96

23
A utilização da tabela de Erlang é bem simples.
w
1. Localize a coluna correspondente ao grau de serviço desejado. Existem ainda algumas
calculadoras disponí-
2. Nesta coluna, localize o valor imediatamente superior ao tráfego esperado. veis na internet. Essa é
a referência para uma
3. Identifique o valor de N, que ocorre no início de cada linha. Esse é o valor desejado, que delas, disponibilizadas
pelo site Teleco: http://
significa o número de canais necessários para atender ao seu sistema.
www.teleco.com.br/
erlangb.asp.
De acordo com o caso do exemplo anterior, são necessários quatro canais com a rede
pública para atender um tráfego de 0,5 Erl (equivalentes a 15 chamadas de 2 minutos
durante uma hora), com um GoS de 0.3%.

Observação: para o dimensionamento de ambientes com filas de atendimento, como
callcenters, o metodo é ligeiramente diferente e utiliza outras tabelas de Erlang.

No site erlang.com, essa tabela de Erlang está completa:
http://www.erlang.com.br/download/ErlangB.PDF

Plano de Numeração Nacional l
Para alcançar corretamente essa quantidade gigantesca de aparelhos telefônicos (fixos e No momento em que
móveis) no mundo é necessário haver rígida padronização na formatação dos “endereços” escrevemos este livro,
o Brasil está passando
dos telefones. No Brasil, a ANATEL define o Plano de Numeração da seguinte forma: pela migração de 8
para 9 dígitos para os
11 Para as chamadas locais, são discados 8 dígitos para telefones fixos ou 9 dígitos celulares. Essa
para celulares. mudança deve ser
concluída até o fim do
11 Chamadas a cobrar devem utilizar o prefixo 9090 antes do número. ano de 2016.

Figura 2.26
Exemplo de ligação
local e a cobrar.
Serviço fone@RNP

11 Para chamadas de Longa Distância Nacional (LDN), o plano de discagem nacional é:
0 + CSP + CA + NÚMERO, onde:

22 CSP = 2 dígitos do Código de Seleção de prestadora;

22 CA = 2 dígitos do Código de Área.

24
11 Para chamadas LDN a cobrar, inclua o dígito 9 antes do prefixo LDN (0):

22 90+0+CSP+CA+NÚMERO

Figura 2.27
Exemplo de
chamada a
distância nacional.

11 Para chamadas de Longa Distância Internacional (LDI), o plano de discagem nacional é
00 + CSP + CP + (CA+NÚMERO), onde:

22 CP = Código do país, que pode ter de 1 a 3 dígitos.

Capítulo 2 - Introdução à telefonia

Figura 2.28
Exemplo
de ligações
internacionais.

25
Terminais telefônicos dentro de centrais privadas (PABX)
No Brasil, quando o terminal telefônico está ligado a um PABX tradicional analógico ou
digital, é comum utilizar o dígito 0 (zero) para solicitar acesso ao tronco externo, ou como
comumente se ouve dizer, para “pegar linha”. Depois disso, devem ser marcados os dígitos
do número a ser alcançado na RTFC como se o usuário estivesse em sua própria casa, nor-
malmente seguindo o Plano Nacional.

Entretanto, nos PBX IP não é necessário alocar um tronco de saída, ou seja, não é neces-
sário digitar o primeiro 0 (zero), para acesso à linha externa. Mesmo assim, é recomendável
manter a forma de discar (0, para “pegar linha”) para que não haja impacto na cultura de
utilização dos telefones pelos usuários.
Serviço fone@RNP

26
3
Introdução à Voz sobre IP
objetivos

Estudar os principais protocolos e técnicas de empacotamento de áudio utilizados
em VoIP.

conceitos
SIP; SDP; RTP; CODECs.

Voz sobre IP é a tecnologia em que se baseia o serviço de telefonia sobre IP. Há vários proto-
colos e recomendações associadas a VoIP. O SIP e H.323 são os mais conhecidos desses pro-
tocolos, mas existem outros, como MGCP, RTSP etc. O fone@RNP utiliza SIP para sinalização
das chamadas telefônicas.

Este capítulo apresenta o SIP e outros componentes que fazem parte da solução de telefonia
IP da RNP.

Protocolo de iniciação de sessão – SIP
O protocolo de iniciação de sessão (Session Initiation Protocol – SIP) foi desenvolvido pela
Internet Engineering Task Force (IETF) na década de 90. Sua primeira versão, lançada em
1996, foi chamada inicialmente de Session Invitation Protocol, onde sua função era basi-
camente estabelecer a sessão. Outras funcionalidades, como controles para conferências,
foram introduzidas na versão 2.0, lançada em 1997. Em fevereiro de 1999, o SIP foi proposto
como um padrão e publicado na RFC 2543. Sua última versão (SIPv2) foi publicada na
RFC 3261 em 2002, substituindo a versão anterior.

O SIP é utilizado para estabelecer, manter e encerrar conferências multimídia em uma arqui-
Capítulo 3 - Introdução à Voz sobre IP

tetura cliente/servidor — o originador é o usuário cliente e o destino é o usuário servidor.
Existem as versões SIP-T IETF, SIP-I ITU e SIP-I ANSI, similares ao SIP, mas com diferenças sutis,
utilizadas para tunelar mensagens ISUP ou outras sinalizações telefônicas através de redes IP.

Em uma sessão SIP, um servidor e um cliente terão total controle sobre a sessão, podendo
ser de transmissão de voz, vídeo ou bate-papo.

O SIP utiliza outros protocolos para complementar sua função. Os dois mais conhecidos são:

11 Real Time Protocol/Real Time Control Protocol (RTP/RTCP);

11 Session Description Protocol (SDP).

27
Padronizado pelo IETF na RFC 1889, o Real Time Transport Protocol (RTP) foi projetado para per-
mitir que os receptores compensem o jitter e a perda de pacotes introduzidos pelas redes IP.
Sua última versão é o Secure RTP (SRTP), publicada na RFC 3711. Inclui as seguintes informações:

11 Tipo de dado transportado;

11 Timestamps;

11 Número de sequência.

O protocolo de controle de transporte em tempo real (Real Time Control Protocol – RTCP)
foi projetado para trabalhar em conjunto com o RTP. Em uma sessão RTP, os participantes
enviam periodicamente pacotes RTCP para receberem informações sobre a qualidade da
entrega dos dados, sobre jitter e sobre a perda de pacotes.

O protocolo de descrição de sessão (Session Description Protocol – SDP), definido pela IETF
na RFC 2317, é utilizado em conjunto com o protocolo SIP para definir as sessões, tipo de
mídia, CODECs, portas para transporte de mídia e criptografia.

Características do protocolo SIP
11 SIP é baseado em texto;

11 O SIP é baseado em Requisições e Respostas;

11 SIP é independente da camada de transporte.

O Protocolo de Iniciação de Sessão é um protocolo de aplicação que utiliza o modelo “requi-
sição-resposta”, similar ao HTTP, para iniciar sessões de comunicação interativa entre usuários.

Sua rápida adoção talvez esteja relacionada principalmente à sua simplicidade (possui apenas
seis métodos), à sua independência em relação ao protocolo de transporte (pode funcionar
com UDP ou TCP), por ser baseada em texto e, assim como o HTTP, o SIP leva os controles da
aplicação para o terminal, eliminando a necessidade de uma central de comutação.

Funcionalidades
As principais funcionalidades do SIP são:

11 Localização do usuário;

11 Disponibilidade do usuário;

11 Capacidades do usuário;

11 Estabelecimento de sessão;

11 Gerência de uma sessão estabelecida.

O que o SIP não é e não faz:
11 Não é um protocolo de transferência de dados;

11 Transporta pequenas mensagens, mas não grande quantidade de dados;

11 Não fornece suporte para QoS;
Serviço fone@RNP

11 Não tem a finalidade de substituir todas as características da telefonia;

11 Não é um protocolo de reserva de recurso;

11 Não é um protocolo para controle de dispositivos.

28
O SIP não é um protocolo milagroso desenvolvido para solucionar todos os problemas da
comunicação. Não tem o objetivo de substituir todas as características e serviços providos

l
pela rede comutada de telefonia com serviços idênticos. Não é um protocolo de transferência
como o HTTP, que foi desenvolvido para transportar uma quantidade grande de dados. O
O SIP não provê
serviços. Ele provê SIP transporta uma pequena quantidade de dados requerida para configurar comunicações
primitivas que podem iterativas (pequenas mensagens de texto). Também não age como um dispositivo de reserva
ser utilizadas para
de recursos, por não prover QoS, apenas interagindo com protocolos desenvolvidos para
montar um serviço, por
exemplo, o serviço de suportar QoS. Não é um protocolo que substituirá a PSTN, sendo bem diferente dos modelos
Telefonia sobre IP. de chamadas telefônicas e dos protocolos de sinalização de telecomunicação. O SIP pode inte-
ragir com a PSTN por meio de gateways, mas essa não é sua função principal.

Elementos de uma rede SIP
Uma rede SIP típica contém basicamente dois tipos de elementos: telefones ou EndPoints,
chamados User Agent, e os servidores, chamados de proxy servers. O User Agent (UA) é
uma entidade lógica da arquitetura SIP e se subdivide em:

11 User Agent Client (UAC): executa a função de cliente da aplicação e é responsável por
iniciar uma chamada SIP enviando requisições;

11 User Agent Server (UAS): é a parte com função de servidor e permanece “ouvindo” a
rede, aguardando requisições.

Um user agent chamador atua como UAC quando envia uma mensagem de requisição INVITE
e recebe resposta das requisições feitas. Um user agent chamado se comporta como um UAS
quando este recebe a requisição INVITE e retorna uma resposta. Essa situação muda quando a
pessoa chamada decide enviar um BYE e terminar a sessão. Nesse caso, o user agent chamado
(que envia BYE) se comporta como um UAC, e o user agent chamador atua como um UAS. Dito
de outra forma, o UAC e UAS só existem durante a transação SIP (SIP Transaction).

Os servidores (ou SIP Proxies) são elementos encarregados de executar o registro dos telefones
e o encaminhamento das chamadas entre os diferentes domínios. São usados para traduzir
nomes e números de identificação dos UA para o endereço IP em que eles estão instalados.

Os SIP Proxies são classificados de acordo com sua função principal:

11 Registar ou Servidor de registro: servidor onde os telefones IP se registram para que
possam ser encontrados quando uma chamada chega para eles;

11 Redirect Server ou Servidores de redirecionamento: servidor utilizado apenas para
indicar rotas alternativas. Responde às requisições com mensagens 3xx;

11 Servidor Proxy: seu propósito é receber requisições e encaminhá-las para o destino.
Sua função principal é rotear as chamadas. Também podem exercer funções de controle,
admissão e segurança. Podem ser de dois tipos:
Capítulo 3 - Introdução à Voz sobre IP

22 Proxies Stateless não mantêm o estado das chamadas. Eles reencaminham as mensa-
gens para o destino ou para outro proxy. São mais simples e mais rápidos. São similares
às “centrais tandem” da velha telefonia. Armazenam poucas informações e são indi-
cados para implementação de centrais trânsito, a fim de evitar congestionamentos;

22 Proxies Stateful mantêm o estado das chamadas. Podem se encarregar de tarefas como
bilhetagem e contabilização. São mais lentos e consomem mais recursos computacionais.

29
Fluxo de mensagens SIP
atlanta.com . . . biloxi.com
. proxy proxi .
. .
Alice’s . . . . . . . . . . . . . . . . . . . . . Bob’s
Softphone SIP Phone
| |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<---------------| 180 Trying F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| | Figura 3.1
Trapézio do SIP.

Essa clássica figura foi retirada da RFC 3261 e representa o “Trapézio do SIP”, onde Alice, uti-
lizando o proxy atlanta, liga para Bob, no proxy biloxi. Nesse caso, os servidores em questão
são “Stateless”, pois não se mantêm na chamada até sua finalização.

Servidor DNS

DNS

2. SIP SRV
para b.com 3. proxy.b.com

Empresa A Empresa B

Joe Bob
Serviço fone@RNP

proxy.a.com proxy.b.com

1.INVITE 4.INVITE 5.INVITE

Figura 3.2
5.6.7.8 6.BYE 1.2.3.4 Fluxo de
mensagens SIP.

30
Também é possível observar o trapézio SIP em um cenário hipotético com duas companhias,
A e B, com dois servidores proxy diferentes, um para cada. Nesse caso, observe a etapa
onde o proxy A encontra o endereço do proxy B.

11 O funcionário Joe, da companhia A, deseja se comunicar com o funcionário Bob,
da companhia B;

11 O usuário Joe utiliza o endereço “sip:bob@b.com” para fazer uma ligação para o usuário
Bob. O user agent de Joe não sabe a localização de Bob, mas está configurado para enviar
todas as chamadas para o servidor SIP “proxy.a.com” de sua companhia;

11 O servidor proxy de A descobre que o usuário “sip:bob@b.com” está em uma companhia
diferente, então vai procurar servidor SIP proxy da companhia B e enviar o convite para
lá. Os endereços dos servidores proxy da companhia B podem estar pré-configurados no
“proxy.a.com”, ou o proxy de A utilizará os registros DNS SRV para encontrar os servi-
dores proxy de Bob;

11 O convite chega até “proxy.b.com”, que sabe que Bob tem condições de atender a
chamada em seu telefone. Então o proxy envia o convite para o endereço do telefone
IP de Bob.

Servidor de redirecionamento (Redirect Server)
Servidor de redirecionamento

1.INVITE 2. 302 movido temporariamente

Figura 3.3 3.INVITE
Mensagens SIP:
Servidor de
redirecionamento. User agent A User agent B

Funcionamento do redirect server:

11 Servidor que recebe uma requisição e retorna uma resposta contendo uma lista da locali-
zação atual do cliente;

11 Gera respostas do tipo 3xx para as requisições feitas.

Um servidor de redirecionamento (redirect server) mapeia um endereço em zero ou mais
novos endereços associados a um cliente, que não é nada mais do que um servidor gerador
Capítulo 3 - Introdução à Voz sobre IP

de respostas 3xx para as requisições que recebe, direcionando o cliente ao contato com um
conjunto de URIs alternativos.

Pode ser utilizado para a implementação de serviços de voz, como o correio eletrônico, ou
para a configuração de rotas alternativas.

Nesse cenário, o redirect server recebe a requisição e consulta o destinatário no banco de
dados criado pelo servidor de registro (registrar). Depois disso, uma lista da localização atual
do usuário é criada e enviada ao originador da requisição em uma resposta SIP 3xx da classe
de resposta de redirecionamento. O originador da requisição extrai a lista de endereços e
envia outra requisição diretamente para eles.

31
Servidor de registro (Registrar Server)
O servidor de registro é um dos elementos da arquitetura SIP, onde se recebe os registros dos
usuários. Ele extrai a informação de sua localização atual (endereço IP, porta e username) e a
armazena em um banco de dados. Armazena informações sobre os locais onde uma parte
pode ser encontrada, trabalhando em conjunto com o servidor de redirecionamento e o
servidor proxy. O propósito do banco de dados é mapear clientes em uma mesma zona,
permitindo que sejam encontrados no momento de uma requisição.

Location Database
Record in Location Database
Location
Use sip:jan@iptel.org is UA Registrar Database
reachable at sip:jan@1.2.3.4.5060
REGISTER Store
Location
sip:jan@iptel.org 2. STORE

200 OK
DNS

1. REGISTER

3. 200 OK
1.2.3.4.5060 Registrar

Esse cenário demonstra um exemplo de um servidor de registro (registrar), no qual uma Figura 3.4
mensagem REGISTER contém o endereço de registro “sip:jan@iptel.org” e o endereço de Mensagens SIP:
Servidor de
contato “sip:jan@1.2.3.4:5060”, em que 1.2.3.4 é o endereço IP do telefone enviado ao ser- registro.
vidor de registro, que extrai a informação e a armazena em um banco de dados local.
Se tudo correr bem, o servidor de registro envia uma mensagem de resposta 200 OK ao
telefone e o processo de registro termina corretamente.

Mensagens SIP
A comunicação SIP determina a troca de várias mensagens, que podem ser transportadas
via UDP ou TCP, sendo o primeiro o método mais usual. Uma mensagem pode ser:

11 Requisição do cliente para o servidor ou;

11 Resposta do servidor para o cliente.

22 SIP Requests: uma mensagem SIP enviada do cliente ao servidor com o propósito de
invocar uma operação em particular;

22 SIP Responses: quando um UA (User Agent) ou um proxy server recebe uma requi-
sição e envia uma resposta.

Mensagem de requisição SIP (SIP Requests)
O formato de uma requisição SIP é caracterizado pela utilização de uma linha de requisição
como primeira linha. Cada linha de requisição é formada por um método (tipo de operação
de requisição), um endereço e pela identificação da versão SIP utilizada. São especificados
seis métodos para a versão corrente do SIP. Porém, outros métodos foram definidos por
Serviço fone@RNP

extensões do SIP. Com relação ao endereço, o formato é definido como uma URI SIP, uma
SIPS ou uma URI genérica.

32
Método Funcionalidade

INVITE Usado para convidar um UA a estabelecer uma sessão.

ACK Confirma convite do INVITE.

BYE Termina a sessão multimídia.

CANCEL Cancela a sessão, mas não por inteiro.

REGISTER Registra a informação do contato.
Tabela 3.1
Métodos SIP. OPTIONS Faz consulta ao servidor para saber suas capacidades.

Há ainda os métodos estendidos de requisição. Eles estão enumerados na tabela a seguir.

Método RFC Funcionalidade

INFO 2976 Carrega informações de controle geradas durante a sessão.

MESSAGE 3428 Permite a transferência de mensagens instantâneas.

NOTIFY 3265 Permite a notificação de eventos específicos.

PRACK 3262 Confirma a recepção de uma mensagem de resposta informativa.

PUBLISH 3903 Publica o estado de um evento.

REFER 3515 Solicita que um receptor faça contato com um terceiro participante.

Tabela 3.2 SUBSCRIBE 3265 Permite que se subscreva para um estado particular em um recurso.
Métodos
UPDATE 3311 Permite a atualização dos parâmetros de uma sessão.
estendidos.

Exemplo de SIP Request
INVITE sip:7170@rnp.br SIP/2.0
Via: SIP/2.0/UDP 195.37.77.100:5060;rport
Max-Forwards: 10
From: “jiri” <sip:renatoduarte@rnp.rnp>;tag=76ff7a07-c091-4192-84a0-d56e91fe104f
To: sip:luiz@rnp.br
Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.20.128.35
CSeq: 2 INVITE
Contact: sip:213.20.128.35:9315
User-Agent: Windows RTC/1.0
Proxy-Authorization: Digest username=“renatoduarte”, realm=“rnp.br”,
algorithm=”MD5”, uri=”sip:renatoduarte@rnp.br”,
Capítulo 3 - Introdução à Voz sobre IP

nonce=”3cef753900000001771328f5ae1b8b7f0d742da1feb5753c”,
response=”53fe98db10e1074

l b03b3e06438bda70f”
Continua com linhas Content-Type: application/sdp
SDP... Content-Length: 451

A primeira linha indica que a mensagem INVITE é usada para estabelecer uma sessão. A URI,
da primeira linha SIP “7170@rnp.br SIP/2.0”, é chamada de Request URI e contém a URI da
pessoa chamada. Um SIP request pode conter um ou mais cabeçalhos Via, que são usados
para guardar o endereço da requisição. Eles são utilizados para o roteamento de SIP Res-
ponses (respostas SIP). A mensagem INVITE contém apenas um cabeçalho Via criado pelo

33
user agent que envia a requisição. Sobre o campo “Via” podemos dizer que o user agent está
executando no endereço 195.37.77.100, na porta 5060.

Nos campos do cabeçalho “To” e “From”, identifica-se quem vai receber o convite e de quem
está sendo recebido determinado convite para determinada sessão. Também possui um
campo “Tag”, que serve como um identificador de diálogo.

Mensagem de resposta (SIP Response)
É muito similar às requisições, exceto pela primeira linha. Caracterizada pela utilização de
uma linha de status como linha de início, formada pela Identificação da versão SIP, Código de
status numérico, Código de resultado com três dígitos e Frase textual.

Existem seis classes do tipo SIP Responses:

11 1xx: resposta informativa;

11 2xx: respostas de sucesso;

11 3xx: respostas de redirecionamento;

11 4xx: respostas de falha de requisição;

11 5xx: respostas de falha em servidor;

11 6xx: respostas de falha global.

22 1xx: usadas para respostas provisórias, que dizem ao receptor que a requisição feita
foi recebida, mas o resultado ainda está em processo;

22 2xx: respostas finais de sucesso, em que o originador da requisição sempre as receberá.
Também terminam transações;

22 3xx: respostas usadas para redirecionamento do chamador. Fornecem informações
sobre a nova direção do usuário ou sobre um serviço alternativo que o chamador
precisa usar para satisfazer a ligação;

22 4xx: respostas utilizadas para indicar que houve erro da parte de quem enviou a
requisição; erro na sintaxe ou por não ter sido bem preenchida pelo servidor. Resposta
de falha de requisição;

22 5xx: utilizadas para indicar que houve um erro da parte do servidor. Resposta de falha
no servidor;

22 6xx: usada para indicar que a resposta não pode ser completada em nenhum servidor.
Resposta de falha global.

Exemplo de SIP Response
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68
From: sip:sip2@iptel.org
To: sip:sip2@iptel.org;tagi=794fe65c16edfdf45da4fc39a5d2867c.b713
Call-ID: 2443936363@192.168.1.30
CSeqi: 63629 REGISTER
Serviço fone@RNP

Contact: Msip:sip2@66.87.48.68:5060;transport=udp>;q=0.00;expires=120
Server: Sip EXpress router (0.8.11pre21xrc (i386/linux))
Content-Length: 0
Warning: 392 195.37.77.101:5060 “Noisy feedback tells:
pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org
out_uri=sip:iptel.org via_cnt==1”

34
Esse exemplo de SIP Response mostra que as respostas são bem similares às requisições,
exceto na primeira linha, que contém a versão do protocolo (SIP/2.0), o código da resposta e
a frase textual. Os códigos têm a intenção de serem processados pelas máquinas, não sendo
muito amigáveis aos humanos, mas facilitando para que as máquinas façam o parse deles.
Já a frase textual é legível aos humanos, descrevendo o resultado do processo.

Um exemplo mais completo

Aqui retomamos o Trapézio do SIP.

atlanta.com . . . biloxi.com
. proxy proxi .
. .
Alice’s . . . . . . . . . . . . . . . . . . . . . Bob’s
Softphone SIP Phone
| |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<---------------| 180 Trying F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
Figura 3.5
Trapézio SIP. | |

O proxy server recebe uma requisição INVITE e envia uma resposta 100 (trying) para o softphone
de Alice. A resposta 100 (trying) indica que a requisição INVITE foi recebida e que o proxy
está trabalhando por ela para rotear a mensagem INVITE para seu destino. Respostas no
SIP usam código com três dígitos seguidos de uma frase descritiva. Essa resposta contém
Capítulo 3 - Introdução à Voz sobre IP

os mesmos campos “To”, “From”, “Call-ID”, “CSeq” e “Via”, que permitem que o softphone da
Alice correlacione a resposta com a mensagem INVITE enviada. O servidor proxy “atlanta.
com” localiza o proxy no servidor “biloxi.com”, possivelmente executando um tipo de
procura no servidor de DNS para encontrar o servidor SIP que serve ao domínio “biloxi.com”.
Como resultado, este obtém o endereço IP do servidor proxy “biloxi.com” e envia a requi-
sição INVITE para lá. Antes de enviar a requisição, o servidor proxy “atlanta.com” adiciona
um campo “Via” adicional, que contém seu próprio endereço. O servidor proxy “biloxy.com”
recebe a requisição INVITE e responde com 100 (trying) ao servidor proxy “atlanta.com”,
indicando que recebeu a requisição INVITE e a está processando. O servidor proxy consulta
o banco de dados, geralmente chamado de “location service”, que contém o endereço IP

35
atual do Bob. O servidor proxy “biloxi.com” adiciona outro campo “Via” no cabeçalho com o
seu endereço para a requisição INVITE e a envia ao telefone SIP do Bob.

O telefone SIP de Bob recebe a requisição INVITE e alerta a Bob que existe uma chamada de
Alice. O telefone SIP do Bob indica essa ação com uma mensagem de resposta 180 (ringing), que
é roteada pelos dois proxies na direção reversa. Cada proxy utiliza o campo “Via” do cabeçalho
para saber para onde enviar a resposta, depois elimina-as do topo da mensagem. Quando o
softphone de Alice recebe a resposta 180 (ringing), a informação é passada para Alice, talvez
utilizando tom de áudio “ringback” ou mostrando uma mensagem na tela do softphone dela.

Quando Bob atende à ligação, o seu telefone SIP envia uma mensagem 200 (OK) para indicar
que a ligação foi atendida. A mensagem 200 (OK) contém o corpo da mensagem juntamente
com a descrição de mídia SDP (Session Description Protocol) do tipo de sessão que Bob está
esperando estabelecer com Alice. Se Bob resolvesse não atender à chamada, uma mensagem
de erro seria retornada em vez da mensagem 200 (OK), e a sessão de mídia não existiria.

Protocolo SDP
SDP significa Session Description Protocol (Protocolo de Descrição de Sessão). É um formato
para a descrição dos parâmetros de inicialização de mídia streaming. Foi publicado pela IETF
como RFC 2327 e substituído pela RFC 4566. A mídia streaming é o conteúdo visto ou ouvido
durante um envio de dados.

Durante o processo de estabelecimento de uma sessão, é necessário negociar a mídia a
ser utilizada (voz, vídeo ou dados) e as respectivas informações para a transmissão dessa
mídia, como o padrão do CODEC e o protocolo de controle para transmissão. Enquanto o SIP
especifica o processo para o anúncio da descrição das informações de uma sessão, o SDP
especifica apenas o formato para descrição dessas informações.

A descrição das informações de uma sessão SDP é inteiramente representada de forma
textual. Isso permite uma variedade de formas de transporte da informação e possibilita
que ferramentas baseadas em texto possam gerar e processar as descrições das sessões, de
forma que os valores dos atributos podem utilizar todo o conjunto de caracteres do UTF-8.

Uma mensagem SDP é composta por uma série de linhas denominadas campos. Os nomes
são abreviados por uma só letra. A formatação das linhas de texto está descrita da seguinte
forma: Tipo do campo = valor do campo.

Por exemplo, no campo “mídia” (m), o SDP usa um código para listar os CODECs que poderão
ser utilizados na sessão. Os códigos correspondentes aos CODECs para os diversos tipos de
mídia são detalhados na RFC 3551.

m=áudio 3456 RTP/AVP 0,3,4 e 5 (0=PCM G711, 3=GSM, 4=G.723 e 5=DVI4)

A tabela a seguir mostra os campos e sua descrição.
Serviço fone@RNP

36
Tipo do Valor do campo Presença
campo obrigatória

v Versão do protocolo Sim

o Originador ou criador da sessão e identificador da sessão Sim

s Nome da sessão Sim

i Informação sobre a sessão Não

u URI da sessão Não

e Endereço de e-mail Não

p Número do telefone Não

c Informação sobre a conexão Não

b Informação sobre largura de banda Não

Uma ou mais descrições de horário Sim

z Ajustes do time zone Não

k Chave de encriptação Não

Tabela 3.3 a Zero ou mais linhas de atributo da sessão Não
Campos do SDP e
Zero ou mais discrições de mídia Não
suas descrições.

Exemplo:
v=0
o=renatoduarte 2890842807 2890842807 IN IP4 serv.esr.rnp.br
s=Resultado Anual
u=http://www.esr.rnp.br/resultados
c=IN IP4 serv.esr.rnp.br
t=2873397496 0
m=audio 30530 RTP / AVP 0 97 101
a=rtpmap:0 PMCU/8000
a=rtpmap97 G726-32/8000
a=rtpmap101 G726/8000
a=ptime:20

Real-time Transport Protocol – RTP
Capítulo 3 - Introdução à Voz sobre IP

O Real-time Transport Protocol (RTP) é um protocolo que oferece funções direcionadas para
aplicações que transmitem fluxos de dados em tempo real, como áudio, vídeo e dados de
simulações, por meio de serviços de rede unicast e multicast. Esse tipo de fluxo deve ser
transportado utilizando o UDP, pois o TCP possui controle de fluxo, que diminui a taxa de
transmissão em caso de perda de pacotes. Assim, é natural que o RTP funcione sobre o
UDP ao invés do TCP, evitando o controle de fluxo e retransmissões. O custo disso é a pouca
confiabilidade e a falta de ordenação na chegada dos pacotes. A retransmissão de pacotes
também não é uma característica desejada em fluxos de áudio e vídeo interativos, uma vez
que o pacote retransmitido normalmente não chega ao receptor a tempo de ser utilizado.
Alguns protocolos mais sofisticados de streamming calculam a probabilidade de o pacote

37
ser retransmitido, permitindo que ele possa chegar a tempo de ser processado. Assim,
apenas em caso positivo o pacote é retransmitido.

Resumidamente, o serviço RTP inclui:

11 Identificação do tipo payload;

11 Numeração sequencial;

11 Marcas temporais (timestamping);

11 Monitoração da entrega de dados;

11 Permite interpolação;

11 Não trata da reserva de recursos e não garante qualidade de serviço (QoS) em tempo real.

Funcionando sobre o UDP, soma-se a essas algumas informações de sequenciamento e
de timestamp necessárias para a sincronização de imagem e áudio, e para possibilitar o
sequenciamento correto pela aplicação. O RTP possibilita à aplicação identificar perdas e
avaliar quanto tempo uma amostra pode permanecer armazenada em um buffer aguar-
dando a chegada do próximo pacote.

A recomendação Secure RTP (RFC 3711) permite uso de criptografia e autenticação das
mensagens RTP e RTCP.

Formato do pacote RTP
Os doze primeiros octetos estão presentes em todos os pacotes de um fluxo de dados de
uma sessão RTP.

0 8 16 24 32

V P X #CSRC M PT Sequence Number

Timestamp

Syncronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifiers

Header Extention
Figura 3.6
Payload (áudio, video etc) Cabeçalho RTP.

11 V (Version): versão do RTP;

11 P (Padding): indica a presença ou não de preenchimento das posições finais do pacote
com um ou mais bytes que não fazem parte da carga;

11 X (Extention): indica presença ou não de extensão de cabeçalho;

11 CC (CSRC Counter): contador do número de identificadores CSRC após o cabeçalho fixo;

11 M (Marker Bit): delimita um conjunto de dados relacionados, o início de uma rajada de
áudio ou o fim de um quadro de vídeo;

11 PT (Payload Type): indica o formato da carga do RTP e determina sua interpretação pela
Serviço fone@RNP

aplicação;

11 Sequence Number: incrementado em cada pacote RTP e utilizado pelo receptor para
detectar perda de pacote ou para restaurar a própria sequência;

11 Timestamp: utilizado pelo receptor para sincronização e cálculo do jitter;

38
11 SSRC (Synchronization Source) Identifier: utilizado para identificar um fluxo específico
em uma sessão RTP. Necessário para o receptor agrupar pacotes com o mesmo SSRC
para a reprodução;

11 CSRC (Contributing Source) Identifiers: lista de identificadores CSRC inseridos por mixers.

Quando pacotes RTP relativos a um fluxo chegam ao seu destino, o número de sequência de
cada pacote é examinado para determinar a sequência correta dos dados, e também para
registrar a fração de dados (por exemplo, amostras de áudio ou quadros de vídeo) perdidos.

O valor do timestamp do cabeçalho RTP pode ser utilizado para determinar o atraso entre a
fonte e o receptor. O valor do timestamp é marcado pelo transmissor do fluxo no momento
do envio dos dados. Conforme os pacotes do fluxo chegam ao receptor, a variação no
espaçamento entre pacotes (variação do atraso ou jitter) pode ser examinada, e, durante a
reprodução, essa informação pode ser utilizada para cálculo de um buffer dinâmico, com
a finalidade de eliminar a variação do atraso e, ao mesmo tempo, impor o menor atraso
possível, de forma que o decodificador possa reproduzir a mídia mantendo uma boa experi-
ência de interatividade.

Real-time Transport Control Protocol – RTCP
Resumidamente, é o controle do RTP. A frequência de transmissão de pacotes de controle
pode variar com a quantidade de participantes em uma sessão, uma vez que, em caso de uma
quantidade muito alta, o fluxo de dados de controle pode comprometer os fluxos de dados.

Uma das melhorias que a atualização da RFC-3550 traz é justamente o desempenho do
protocolo RTCP com um novo algoritmo para cálculo do tempo de transmissão dos pacotes
desse protocolo em conferências.

O RTCP complementa o transporte de dados feito pelo RTP. Ele possibilita o monitoramento
da entrega de dados de forma escalável em redes multicast. Seu funcionamento é baseado na
transmissão periódica de pacotes de controle para todos os participantes de uma sessão RTP.

O RTCP provê o feedback da qualidade da distribuição, útil para CODECs adaptativos e para
a detecção de problemas locais ou globais.

O identificador CNAME é utilizado para associar múltiplos streammings, como voz e vídeo.
Controla a taxa que os participantes devem enviar informações de controle para que o fluxo
de dados não seja prejudicado. Provê um mínimo de informações de controle. Informações
mais detalhadas, necessárias para algumas aplicações devem ser providas por nível superior.

Há cinco tipos de pacotes RTPC definidos na especificação do RTP, um para cada mensagem:
SR, RR, SDES, BYE e APP.

11 Sender Report (SR): para estatísticas de transmissão e recepção de participantes que
Capítulo 3 - Introdução à Voz sobre IP

são transmissores ativos em uma sessão;

11 Receiver Report (RR): para estatísticas de recepção de participantes que não são
transmissores ativos em uma sessão;

11 Source Description (SDES): itens que descrevem um transmissor em uma sessão, como
o CNAME;

11 BYE: para indicar o fim da participação de uma aplicação em uma sessão;

11 APP: para funções específicas da aplicação.

39
O cabeçalho dos pacotes RTCP têm em comum cinco campos que ocupam 32 bits:

11 Número da versão (V): o número da versão atual do RTP é 2. Não existem planos para
introduzir novas versões, e as versões antigas são utilizadas raramente hoje em dia;

11 Padding (P): indica que o pacote foi preenchido com bits além do seu tamanho natural.
Esse tipo de expediente é necessário quando são utilizados alguns algoritmos de cripto-
grafia que necessitam de blocos com tamanho constante;

11 Contagem de itens (IC): indica o número de itens contidos em um pacote. Normalmente
utilizado para indicar o número de receiver reports contido no pacote;

11 Tipo do pacote (PT): identifica o tipo de informação contida no pacote. Atualmente
existem cinco tipos;

11 Comprimento (Length): indica o tamanho do conteúdo do pacote contido após esse
cabeçalho comum.

Não é de interesse deste curso se estender na teoria desse protocolo. Para saber mais sobre
o RTCP, pesquise a RFC-3550.

Empacotamento da voz: CODEC
A codificação de áudio consiste na captura dos sinais mecânicos do som (ondas sonoras) e
transformação destes em sinais digitais. Primeiro ocorre a captura do som e sua transfor-
mação em sinal elétrico e, depois, ocorre sua digitalização. A técnica utilizada em telefonia é
o PCM (Pulse Code Modulation), que já foi estudado no capítulo 2: Introdução à telefonia.

Codec
CODEC é uma abreviação de codificador-decodificador. Eles especificam como os sinais ana-
lógicos da voz devem ser codificados em dados digitais, permitindo ou não a compressão
dos dados, com ou sem perda de informação. Na verdade, CODECs são algoritmos para codi-
ficação de sinais. Para voz, grande parte dos padrões são baseados na codificação da forma
de onda (PCM – Pulse Code Modulation).

Um CODEC comprime os dados, eliminando informações redundantes e previsíveis, tanto
em áudio como em vídeo. Os dados passam por uma conversão analógica-digital, compre-
endendo a amostragem do sinal. Gera-se, então, um formato digital, denominado Pulse
Code Modulation (PCM).

O PCM realiza 8 mil amostras por segundo (carregando 125µsec em cada amostra), devido
ao teorema de Nyquist, que diz que essa medida é suficiente para capturar toda a infor-
mação em um canal telefônico com largura de banda de 4 KHz. Em uma amostragem menor,
a informação transmitida seria perdida; já em uma amostragem maior, nenhuma infor-
mação adicional seria acrescentada. Essa técnica, o PCM, é o coração do sistema moderno
de telefonia. Como consequência, todos os intervalos de tempo dentro do sistema telefônico
são múltiplos de 125 µsec.

Técnicas de codificação
Serviço fone@RNP

Codificação de forma de onda

A codificação de forma de onda de sinais de voz é baseada principalmente na predição
linear, e o esquema mais utilizado é o Adaptive Differential Pulse Code Modulation (ADPCM).
Os codificadores de forma de onda são os que propiciam voz de melhor qualidade, mas são
os que despendem a maior taxa de bits, em geral com taxas superiores a 30 kbps.

40
Codificação paramétrica

O estudo da natureza do sinal (no caso da telefonia, a voz) é essencial para obter máxima
compressão, embora com sensível perda de qualidade. Os codificadores paramétricos,
também denominados vocoders (voice coders), utilizam no decodificador um modelo de
produção de voz, cujos parâmetros são estimados e transmitidos pelo codificador a inter-
valos curtos de tempo (10 a 30 ms). A classe de codificadores paramétricos mais utilizada é a
dos vocoders LPC (Linear Predictive Coding). Os vocoders conseguem codificar os sinais de
voz a taxas de no máximo cerca de 2 kbps, mas com qualidade entre ruim e regular.

Codificação híbrida

Usa conceitos das duas outras formas de codificação (codificação paramétrica e codificação
em forma de onda), procurando um balanço entre qualidade e taxa de compressão. Os codi-
ficadores híbridos são esquemas que combinam características dos codificadores de forma
de onda e dos vocoders. Atualmente, a maioria dos codificadores híbridos utiliza o modelo
de codificação Code Excited Linear Predictive (CELP), com taxas de bits entre 4 e 16 kbps,
proporcionando qualidade muito melhor do que a dos vocoders. Alguns deles propiciam
qualidade muito próxima da obtida com os codificadores de forma de onda.

Com base nos tipos de codificação citados, concluímos que os codificadores de forma de
onda são os que proporcionam voz com melhor qualidade, mas despendem maior taxa de
bits. Em geral, taxas superiores a 30 kbps.

Sobre atraso/delay

Um fator importante a ser considerado é o delay inserido pelo codificador. O processo
computacional de codificar e, na outra ponta, decodificar os pacotes significa inserir mais
atraso na comunicação. De maneira geral, quanto menor for a taxa do CODEC, maior será
seu delay, mas também depende muito da complexidade do algoritmo e da implementação
do CODEC.

Em uma rede de pacote, onde os pacotes de voz podem sofrer grandes atrasos, a escolha
do CODEC em função do seu atraso pode ser um diferencial do projeto, principalmente se
existem enlaces onde o delay é crítico, como em uma conexão via satélite.

Em redes com grande disponibilidade de banda, um CODEC indicado é o G.711, que possui
taxa de transmissão a 64 Kbits/seg, mas com delay (de processamento) próximo de zero,
boa qualidade e livre de licença.

Comparação entre as técnicas

A tabela a seguir mostra um resumo da faixa de frequência, taxas de transmissão e latência
utilizada nos principais padrões de codificação de áudio.
Capítulo 3 - Introdução à Voz sobre IP

41
Padrão faixa de frequência Taxa de transmissão latência Qualidade

G.711 300 Hz-3.4 kHz 64 kbits/s <1 Excelente

G.722 50 Hz-7 kHz 48,56 ou 64 kbits/s <2 –

G.722.1 14 kHz 24-32 kbits/s – Boa

G.722.2 50 Hz-7 kHz 6.6-23.85 kbits/s – –

G.723.1 8 kHz 5.3 ou 6.3 kbits/s 100 Razoável a boa

G.726 8 kHz 16-40 kbits/s 60 Boa a razoável

G.728 300 Hz-3.4 kHz 16 kbits/s <2 Boa
Tabela 3.4
G.729 8 kHz 8 kbits/s 25-35 Boa
Principais CODECs.

O padrão G.711 é um dos melhores disponíveis (embora o conceito de “melhor” seja
relativo), com delay próximo de zero, mesmo que sua taxa de transmissão de bits seja muito
alta (64 Kbits/seg), consumindo muita banda em comparação com os demais CODECs. Seu
grande diferencial é que está livre de licença, sendo um fator a considerar para projetos com
disponibilidade de banda. Outro fator a considerar é que esse é um CODEC lossless e não
perde informação, sendo utilizado em transmissão de fax.

O padrão G.729 possui taxa de 8 Kbits/seg e é muito utilizado no mercado. É um CODEC
ITU com a necessidade de compra de licença, pois seu algoritmo foi patenteado. Existem as
versões G729a, menos complexa que a G729, e a versão G729b, com capacidade de inserir
ruído de conforto nas ligações que utilizam VAD (detecção de atividade de voz).

O padrão G 723.1 possui taxas menores que o G.729, é um CODEC ITU e também necessita
de pagamento de licença. Possui taxas de 6,3 ou 5,3 Kbits/seg e seu atraso é da ordem de
37,5 mseg.

O CODEC iLBC tem fonte aberta, sem exigência de pagamento de licença, sendo uma boa
opção de solução. Sua taxa é da ordem de 13,3 Kbits/seg.

G.711

A função básica do algoritmo é codificar a voz utilizando 8 bits por amostra; a banda de
entrada de voz é amostrada a 8 kHz, mantendo a largura de banda de 300 a 3400 Hz.
Com isso, cada canal de voz precisa de 64 kbps.

Dois algoritmos foram definidos no padrão ITU-T G.711:

11 u (ulaw): utilizado na América do Norte e no Japão;

11 A (alaw): na Europa e no resto do mundo.

O princípio do codificador G.711 é que se deve utilizar a quantização com escala logarítmica
para obter uma relação sinal/ruído independente da intensidade. Isso foi possível duplicando
o passo de quantização a cada vez que a intensidade do sinal era duplicada; desse modo,
obteve-se uma constante.
Serviço fone@RNP

G.729

O codificador G.729 codifica sinais de voz a uma taxa de 8 kbps usando o modelo CS-ACELP
(Conjugate Structure Algebraic Code Excited Linear Prediction), que é baseado no modelo
de codificação CELP. Ele é projetado para operar com o sinal de voz de entrada já convertido
para o formato PCM uniforme, com 16 bits/amostra e taxa de amostragem de 8 kHz.

42
O codificador G.729 trabalha com quadros de 10 ms (ou 80 amostras), que são divididos em
dois subquadros de 5 ms (ou 40 amostras). Cada quadro de 10 ms do sinal de voz é analisado
para extrair os parâmetros do modelo CELP: os coeficientes preditores do filtro de síntese,
os índices dos dicionários fixo e adaptativo e seus respectivos ganhos. Estes últimos são os
parâmetros da excitação, determinados para cada subquadro de 5 ms. Esses parâmetros
são codificados e transmitidos.

No decodificador, esses parâmetros são recuperados para construir a excitação e obter os
parâmetros do filtro de síntese. O sinal de voz é reconstruído passando a excitação pelo filtro
de síntese de ordem 10. Depois de reconstruído, o sinal de voz é passado por um pós-filtro
para melhorar a qualidade do sinal de saída.

G.723.1

O codificador G.723.1 tem duas taxas de bits associadas a ele, de 5,3 e 6,3 kbps. Ele codifica
sinais de voz quadro a quadro usando codificação preditiva linear baseada em análise por
síntese (CPLbAS). A codificação em taxa alta (6,3 kbps) usa um modelo MP-MLQ (Multipulse
Maximum Likelihood Quantization) para gerar o sinal de excitação, enquanto a codificação
em taxa baixa (5,3 kbps) usa um modelo ACELP (Algebraic Code Excited Linear Prediction).
O tamanho dos quadros é de 30 ms (ou 240 amostras).

O codificador G.723.1 é projetado para operar com o sinal de voz de entrada já convertido
para o formato PCM uniforme, 16 bits/amostra e taxa de amostragem de 8 kHz.

iLBC

O codificador iLBC utiliza o algoritmo de predição linear e suporta dois comprimentos
básicos, quadros de 20 ms a 15.2 kbps e de 30 ms a 13.33 kbps. Quando o codificador
trabalha com quadros de comprimento de 20 ms, produz 304 bits de saída por quadro, e
para um comprimento de 30 ms por quadro, produz 400 bits de saída, os quais devem ser
empacotados para serem transmitidos. Os dois modos para quadros de diferentes tama-
nhos operam de maneira similar. A descrição do algoritmo resulta em um sistema de codi-
ficação de voz com resposta controlada diante da perda de pacotes, similar à especificada
no PCM com perda de pacotes no padrão ITU-T G.711, que opera a uma taxa fixa de 64 kbps.
Algumas das aplicações para esse codificador estão nas formas de comunicação em tempo
real, como telefonia, videoconferência, áudio e envio de mensagens.

G.722

O CODEC G.722 é conhecido como CODECs de banda larga ou também como CODECs de
alta definição (High Definition: HD). Possui faixa de frequência maior do que os demais, em
7kHz. Isso faz com que capture mais detalhes da voz. É baseado na técnica sub-band ADPCM
(SB-ADPCM). Esse CODEC utiliza 14 bits para determinar cada amostra de some consome até
Capítulo 3 - Introdução à Voz sobre IP

64kbits/seg (mais os cabeçalhos de transporte, rede e enlace).

G.722.2

O G.722.2 é um CODEC de voz mais moderno, que utiliza a técnica AMR-WB, Adaptative
Multi-Rate Wideband, desenvolvido com base no AMR e com metodologia similar a ACELP.
Esse CODEC é capaz de se adaptar às condições de rede, reduzindo ou aumentando o
bitrate, sempre tentando entregar a melhor qualidade de voz que a rede permite. É licen-
ciado pela VoiceAge Corporation.

43
Super-resumo de Voz sobre IP
Agora que já é conhecida a maior parte das técnicas aplicadas na tecnologia de voz sobre IP,
é possível fazer um resumo sobre como todos os componentes se interligam.

A seguir, a sequência de fatos quando uma ligação ocorre em um serviço de telefonia sobre IP:

1. O usuário A tira o telefone IP do gancho e disca o número de B;

2. O telefone de A envia um INVITE para seu proxy local (ou seu PBX IP);

3. O proxy local localiza e identifica o Proxy de B (ou seu PBX IP);

4. O proxy de B encontra o telefone B (seu ramal no PBX);

5. A e B (e seus proxies) negociam os parâmetros da sessão usando SDP;

6. A ligação é estabelecida;

7. A voz dos interlocutores é codificada, digitalizada e comprimida nos respectivos telefones
IP, utilizando o CODEC negociado durante o estabelecimento da chamada;

8. A informação da voz digitalizada é enviada utilizando o RTP;

9. Os pacotes de voz chegam ao outro lado e são enfileirados para que possam ser decodifi-
cados corretamente;

10. A informação da voz é desempacotada, decodificada e reproduzida;

11. Depois de algum tempo, alguém decide desligar e, ao colocar o telefone de volta no
gancho, envia um BYE para o outro lado;

12. A ligação é desconectada.
Serviço fone@RNP

44
4
Arquitetura do fone@RNP v.2012
objetivos

Conhecer os componentes do serviço fone@RNP e como eles se relacionam entre si
e com os equipamentos de telefonia preexistentes na instituição.

conceitos
fone@RNP 2012; SRC; SRL; GWT; PBX IP.

Recentemente, o fone@RNP passou por um projeto de evolução, onde foi totalmente rede-
senhado. Sua estrutura, que antes era dependente de dois servidores em cada cliente, foi
modularizada e permite maior escalabilidade, maior confiabilidade e aumenta consideravel-
mente sua eficiência, conferindo maior economia para seus clientes. Além disso, também
foi desenvolvido um módulo com funções de um PABX tradicional, inexistente na versão
anterior. Para identificar as versões do fone@RNP, chamamos a versão mais antiga de distri-
buição 2008 (ou simplesmente fone 2008) e a mais nova de distribuição 2012
(ou simplesmente fone2012).

A arquitetura do serviço fone@RNP necessita que os diversos dispositivos distribuídos pela
rede se comuniquem uns com os outros. Em outras palavras, os dispositivos SIP de uma ins-
tituição devem ser capazes de alcançar os dispositivos SIP de outra instituição participante
do serviço.

O uso de NAT (Network Address Translation) não é compatível com o protocolo SIP, por-
tanto não é uma opção. Assim, é necessário que todos os dispositivos possuam endereço IP
“alcançável”. Exceção para os telefones do tipo IP, que, apesar de poder ter endereços “não
Capítulo 4 - Arquitetura do fone@RNP v.2012

roteáveis”, também não deve fazer uso de NAT.

Além disso, o fone@RNP é um serviço colaborativo, isto é, todos os participantes contribuem
para o funcionamento completo do serviço. Sendo assim, a gerência do serviço precisa
monitorar todos dispositivos que fazem parte do serviço, inclusive aqueles instalados nas
premissas dos clientes. O monitoramento da RNP é realizado utilizando o protocolo SNMP.

Para minimizar riscos, recomendamos o uso de firewall com capacidade de inspeção de
pacotes, que suporte o protocolo SIP para abrir dinamicamente as portas de comunicação
de cada chamada. A estratégia a ser utilizada é negar todo o tráfego e permitir apenas cone-
xões conhecidas. Um guia com regras recomendadas será apresentado adiante.

45
A figura a seguir apresenta a arquitetura do fone@RNP distribuição 2012, detalhando seus
módulos e conexões com outras redes que oferecem serviço de telefonia IP.

SBC
Para redes externas
SRC

GWT SRL SRL SRL ...

PBX PSTN PBX IP PBX IP GWT GWT PBX IP SRL GWT
Tradicional 3os Corporativo Qualquer

PBX PBX PBX IP GWT Cell
PSTN Tradicional PSTN Tradicional PSTN PSTN

PBX
Tradicional PSTN

A caixa (ou módulo) que se encontra próxima ao mapa-múndi identificada como SBC, que Figura 4.1
significa Session Border Controller (Controlador Sessão de Borda), é responsável pelo Arquitetura do
fone@RNP.
controle da comunicação entre o fone@RNP e outras redes de telefonia IP, dentro ou fora
do país. É através desse dispositivo que as chamadas de/e para instituições mapeadas pelo
NRENum.net são encaminhadas. É também através do SBC que o fone@RNP se comu- NRENum.net
nica com o PIT-VoIP (é um serviço de Voz sobre IP oferecido pela RedCLARA para as redes É um serviço ENUM
para academia. Foi ori-
acadêmicas – NRENs – associadas. Ele estabelece um relacionamento de confiança entre SIP
ginalmente concebido
proxies das NRENs da América Latina). no âmbito de TERENA
(Trans-European
Esse módulo está sendo desenvolvido para a distribuição 2012, baseado na solução do SRL, Research and Education
a ser detalhado mais à frente. Atualmente, é utilizado o servidor “proxy externo”, da versão Networking Associa-
tion). Esse serviço pos-
2008, para executar essa função.
sibilita alcançar, via VoIP,
telefones tradicionais
Para executar a função de SBC no nível das instituições, separando o perímetro interno e
nas universidades dos
externo, estão sendo utilizados os próprios SRLs, com função principal de “esconder” a rede países participantes.
VoIP do cliente. As demais caixas serão apresentadas a seguir.

SIP Router Central (SRC)
No primeiro nível, mais acima, se encontra o SIP Router Central (SRC). Esse módulo é res-
ponsável por manter a informação de cada cliente e das rotas para encaminhamento das
chamadas entre as várias instituições e entre redes externas. Conhece todos os dispositivos
do nível a seguir e só aceita INVITEs vindos deles.

No SRC encontram-se todas as rotas para os números alcançados pelo fone@RNP, sejam
eles internos dos clientes, números na RTFC ou números virtuais do fone@RNP. As informa-
ções de rota são publicadas no DNS, em registros NAPTR, de acordo com o protocolo ENUM
[RFC-6116].

SIP Router Local (SRL)
Serviço fone@RNP

No segundo nível (e a partir daí), já se encontram equipamentos que ficam sob responsabili-
dade das instituições clientes. O segundo módulo que aparece (da esquerda para direita) é o SIP
Router Local (SRL). Ele é equivalente ao SRC, mas instanciado nas premissas dos clientes. O SRL

46
contém as rotas para encaminhamento das chamadas entre os dispositivos SIP sob domínio da
instituição responsável por ele, só aceitando também chamadas vindas desses dispositivos.

O SRL pode ser instanciando mais de uma vez dentro da mesma instituição. Isso significa
que o próprio SRL pode ser hierarquizado, criando níveis de atendimento e isolando logica-
mente os campi das instituições clientes.

Quando um INVITE chega ao SRL, ele realiza uma pesquisa ENUM para verificar o endereço
SIP equivalente ao número discado. Pode receber como resposta

11 A indicação de encaminhamento pelo SRC quando a chamada é para outro cliente do
fone ou para uma cidade onde haja um cliente ou;

11 A indicação de outro módulo SRL, PBX IP ou para um GWT da própria instituição quando
a chamada é para um telefone analógico da própria instituição ou para um telefone na
RTFC local.

Na próxima camada, a terceira de cima para baixo, estão o Gateway Transparente (GWT) e o
PBX IP, que serão descritos nos próximos parágrafos. Nessa camada é possível utilizar não
só os dispositivos desenvolvidos para o fone@RNP, mas também qualquer dispositivo SIP,
desde que seja compatível com a RFC 3261 (SIP versão 2.0).

PBX IP
O PBX IP é uma implementação especial de um PABX tradicional, desenvolvido para o
fone@RNP, que procura atender às demandas comuns do serviço de telefonia de uma
grande universidade brasileira. Foi desenvolvido primeiramente pela Universidade Federal
de Santa Catarina (UFSC), para atender a UFSC, e foi melhorado para atender a todos os
clientes do fone.

O PBX IP deve receber INVITES apenas do SRL diretamente acima. Todas as chamadas feitas
a partir de um PBX IP devem ser encaminhadas para o SRL. Como visto nos parágrafos ante-
riores, o SRL fica responsável por indicar a rota correta para o número de telefone desejado.

O PBX IP conta com duas versões: uma que se chama corporativa, para atender aos funcioná-
rios, e outra que chamamos acadêmica, para atender aos alunos das universidades. Essa última
versão possui integração com o serviço de Identidade Digital da RNP, a CAFe, Comunidade
Acadêmica Federada. Essa integração permite a implementação de uma característica única
no PABX IP desenvolvido pelo serviço. É a função de autoatendimento, onde o aluno é capaz de
solicitar seu próprio ramal IP em um página web, sem a intervenção de qualquer funcionário.

Gateway Transparente (GWT)
Capítulo 4 - Arquitetura do fone@RNP v.2012

O Gateway Transparente (GWT), de acordo com o modelo acima, pode aparecer na segunda
camada, diretamente ligado ao SRC ou na terceira camada, a seguir de um SRL. O GWT é a
peça fundamental do novo fone@RNP. Ele faz a ligação entre o serviço de telefonia digital
tradicional e o serviço de telefonia IP.

A quarta camada representa os tradicionais dispositivos PABX e as redes de telefonia, ou
seja, PABX legados e as operadoras telefônicas. Os PABX legados, pré-existentes nas institui-
ções, podem ser totalmente integrados ao serviço fone@RNP. Inclusive, ligações entre tele-
fones IP e telefones tradicionais poderão ser executadas com números abreviados (quatro
dígitos) e de forma transparente.

47
Da mesma forma que o PBX, o GWT espera receber INVITES apenas no SRL. E também só
deve encaminhar INVITES para seu SRL. Ele é capaz de entregar ligações na RTFC ou em um
PABX legado com interface digital.

Inicialmente, a RNP desenvolveu apenas um GWT para interfaces digitais de telefonia, RDSI
ou R2Digital. Posteriormente, a RNP adaptou a configuração de um dispositivo de mercado
para que ele seja utilizado no fone@RNP como um GWT analógico. No momento da escrita
desse livro, ainda estuda uma terceira opção, que integra o hardware do GWT, uma distri-
buição customizada do Asterisk e interfaces analógicas.

A imagens das máquinas virtuais e ISO (para o GWT) estão disponíveis no repositório do
fone@RNP, nos links:

11 SRC: http://repositorio-fone.rnp.br/fone2012/SRC/VM/release/1.0/update-20150327/
SRC2012-M1.ovf

11 GWT: http://repositorio-fone.rnp.br/downloads/IMG_FONERNP_2012_20130613.iso

11 SRL: http://repositorio-fone.rnp.br/fone2012/SRL/VM/release/1.0/update-20150313/
FoneRNP-SRL-v2.ovf

11 PBX-IP Corp: http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-
PBXIP-v3-m1/FoneRNP-PBXIP-v3-m1.ovf e http://repositorio-fone.rnp.br/fone2012/
PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3-m2/FoneRNP-PBXIP-v3-m2.ovf

11 PBX-IP Acad: http://repositorio-fone.rnp.br/fone2012/PBX-IP-ACAD/VM/1.0/stable/
FoneRNP-PBXIP-ACAD.ovf l
O GWT também pode
Com exceção do GWT, todos os dispositivos do novo fone@RNP podem ser implementados ser embarcado em
em máquinas virtuais. Além disso, todos eles podem ter duas instâncias, para fins de redun- dispositivo próprio,
especializado nessa
dância, contribuindo para alta disponibilidade do serviço. Se uma máquina parar, a outra
tarefa. Nesse caso,
assume o trabalho automaticamente. O GWT é o único módulo que precisa ser implemen- chamamos de GWT2.0,
tado em uma máquina real, pois precisa de uma placa de telefonia para interligar com a rede o “verdinho”.
de telefonia convencional.

A arquitetura típica do fone@RNP
A instituição típica
Tipicamente, as instituições clientes do fone@RNP são multicampi, ou seja, possuem prédios
em vários locais distantes uns dos outros: o cenário perfeito para o uso do fone@RNP.
Serviço fone@RNP

48
Reitoria

Campus A Campus B

Figura 4.2
Exemplo de
instituição cliente Campus C
Instituição cliente
do fone@RNP.

Alguns clientes do fone@RNP possuem uma estrutura mais simplificada, às vezes, com
apenas um prédio ou escritório. De qualquer forma, pode ser modelada aqui como uma
simplificação da instituição típica apresentada nesse livro.

Características do cenário
Reitoria:

A reitoria possui um PABX digital, com uma ou mais interfaces E1, ligado diretamente na
operadora telefônica. Pretende utilizar o PBX IP do fone@RNP para expandir seu serviço de
telefonia e para economizar com chamadas telefônicas.

Campus A:

O Campus A é novo. O PABX existente é velho e não tem contrato de manutenção. Possui um
link E1 para telefonia. O PABX antigo será substituído pelo PBX IP do fone@RNP.

Campus B:

Já possui PABX IP de outro fabricante. Interface com RTFC já está configurada e deve ser
aproveitada. Não haverá qualquer tipo de modificação nesse campus, além da participação
no serviço.

Campus C:

O campus C é o menor e mais distante de todos. Possui um PABX com quatro troncos analó-
Capítulo 4 - Arquitetura do fone@RNP v.2012

gicos e alguns ramais.

Outras considerações:

11 A instituição pretende utilizar o PBX IP acadêmico, para poder oferecer ramais para seus
alunos. Eles poderão fazer qualquer chamada que não gere custo para nenhuma insti-
tuição cliente;

11 A instituição estuda contratar um Provedor de telefonia pela internet (ITSP, a sigla em inglês)
para conseguir melhores preços nas ligações para celulares. A adesão dos campi é opcional.

49
Arquitetura típica

Sempre baseado na premissa de que a rede IP (LAN e WAN) foi revisada pela instituição e
é adequada, de forma que suporte o serviço de Voz sobre IP, é possível apresentar alguma
solução para o ambiente proposto.

Arquitetura de referência do fone@RNP v.2012

SRCs
RNP

SRL
PBX IP
Acadêmico

SRL

RTFC
PBX IP GWT
PBX IP GWT 3os Analógico

PBX RTFC Campus B PBX RTFC
Legado Legado

SRL
Reitoria Campus C

PBX IP GWT GW GSM

Figura 4.3
Arquitetura
RTFC Móvel ITSP
de referência
com ambientes
Campus A diversos.

Fluxos de comunicação entre os dispositivos
Fluxo de Sinalização

A sinalização do ambiente de telefonia IP da RNP é, como já se sabe, baseada no protocolo
SIP (RFC 3261). Utiliza como transporte para sinalização, o UDP e não é criptografado.

A seguir, é apresentado o tráfego de sinalização esperado entre os componentes da arquite-
tura de referência, indicando as portas preferenciais para se utilizar no serviço do fone@RNP.

11 SRC (UDP 5060) <> SRL (UDP 5071);

11 SRL (UDP 5060) <> PBX-IP ACADÊMICA (UDP 5080);

11 Telefone IP (UDP 5060) <> PBX-IP ACADÊMICA (UDP 5080);

11 SRL (UDP 5060) <> GWT (UDP 5071);
Serviço fone@RNP

11 SRL (UDP 5060) <> PBX-IP CORPORATIVA (UDP 5080);

11 Telefone IP (UDP 5060) <> PBX-IP CORPORATIVA (UDP 5080);

11 SRC (UDP 5060) <> GWT (UDP 5071);

11 SRL (UDP 5060) <> Central IP (5060).

50
Fluxo de mídia

O fluxo de mídia (áudio/vídeo) utiliza portas altas negociadas na etapa de estabelecimento
das chamadas. Também utiliza o protocolo UDP e não há criptografia. O CODEC preferencial
é o G.711. Recomenda-se habilitar a função de media proxy nos seguintes componentes:

11 SRL;

11 PBX-IP ACADÊMICA.

Caso seja utilizada a configuração recomenda por esse documento, deverão existir os
seguintes fluxos de mídia:

11 SRL <> SRL;

11 SRL <> PBX-IP ACADÊMICA;

11 PBX-IP ACADÊMICA <> Telefone IP;

11 Telefone IP <> Telefone IP.

Exemplos ilustrados para fluxo de mídia e sinalização
Exemplo1: telefone IP chamando número na RTFC

SRCs
RNP

2 SRL 3

PBX IP GWT
5
1
Figura 4.4 4 PBX RTFC
Legado
Mídia e sinalização:
Exemplo 1.

1. INVITE do telefone IP para o PABX;

2. INVITE do PABX para o SRL;

3. INVITE do SRL par ao GWT;

4. Mídia entre Telefone e GWT, passando pelo PBX; Capítulo 4 - Arquitetura do fone@RNP v.2012

5. Entrega da ligação para RTFC pela E1 do GWT.

Note que o SRC não toma conhecimento da chamada que ocorre dentro de uma
instituição!

Veja que o SRL não fica no caminho da mídia para chamadas entre peers.

51
Exemplo2: telefone IP chamando outra instituição cliente

SRCs
RNP

3 4
SRL 7 SRL
2
5

PBX IP GWT PBX IP GWT
6
1
PBX RTFC PBX RTFC Figura 4.5
Legado Legado
Mídia e sinalização:
Exemplo 2.

1. INVITE do telefone IP para o PBX IP;

2. INVITE do PABX para o SRL da 1a instituição;

3. INVITE do SRL para o SRC;

4. INVITE do SRC para o SRL da 2a instituição;

5. INVITE do SRL para o PBX IP;

6. INVITE do PBX IP para o Telefone IP;

7. Mídia entre os dois telefones IP, mas passando pelos PABX e SRLs (mídia não passa pelo
SRC. Nunca!).

Note que o SRL fica no caminho da mídia para chamadas entre um peer e o
ambiente externo.

Sobre firewall e portas de comunicação nos servidores
Uma característica importante da tecnologia de voz sobre IP é que os firewalls precisam
estar configurados corretamente para que a comunicação ocorra.

Uma vez que firewalls são largamente utilizados e, de fato, são essenciais para segurança
de redes, grande atenção deve ser dedicada à configuração desses dispositivos para que o
fone@RNP funcione corretamente.

A seguir, as informações dos dispositivos do fone@RNP e as portas em que esperam
receber pacotes.
Serviço fone@RNP

52
Código Descrição da regra

#1 Deve estar aberto somente para os peers, para maior segurança.

#2 Somente entre os peers (Redundantes).

#3 Somente para servidor de gerência (NMS).

#4 Somente para equipe de operação/manutenção.

#5 Somente localhost.

#6 Público internet. Aberto para todos.

#7 Provisionamento telefones. Rede dos telefones IP.

#8 CDR FONE/RNP. Sistema de estatísticas.
Tabela 4.1
#9 Entre SRC e SRL (Fone2014).
Regras de firewall.

SRC/SRL

Opensip udp/5060 #1

ISC-Bind udp/tcp 53 #1

MySQL tcp/3306 #2

OpenLDAP tcp/389 #2

SNMP udp/161 #3

APACHE tcp/443 #4

APACHE: FONE-ESTATISTICAS tcp/8443 #8

APACHE: Troca de Rotas Automatizada #9 (Fone@2014)
Figura 4.2 (SRC e SRL) tcp/8443
Regras de firewall
para SRC ou SRL. ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014)

GWT

asterisk udp/5071 #1

asterisk-rtp udp/10.000-20.000 #6
Capítulo 4 - Arquitetura do fone@RNP v.2012

ISC-Bind udp/tcp 53 #1

MySQL tcp/3306 #5

SNMP udp/161 #3

APACHE tcp/443 #4
Tabela 4.3
Regras de firewall ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014)
para O GWT.

53
PBX-IP: Corp

Opensip udp/5080 #1

ISC-Bind udp/tcp 53 #1

media-proxy udp/50000:60000 #6 (se ativo)

MySQL tcp/3306 #2

OpenLDAP tcp/389 #2

RSYNC tcp/873 #2

SNMP udp/161 #3

APACHE tcp/443 #4,
#7

APACHE tcp/80 #6, Tabela 4.4
#7 Regras de firewall
para o PBX IP
ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, fone@2014) Corporativo.

PBX-IP: Acadêmico

Opensip udp/5080 #1

media-proxy udp/50000:60000 #6 (recomendado estar ativo, para o
nathelper funcionar)

ISC-Bind udp/tcp 53 #1

MySQL tcp/3306 #2

OpenLDAP tcp/389 #5

SNMP udp/161 #3

APACHE tcp/443 #4

APACHE tcp/80 #6 Tabela 4.5
Regras de firewall
ICMP/ECHO REQUEST/REPLAY #1 (Para medição da qualidade, para o PBX IP
fone@2014) acadêmico.

A maior parte dos problemas que tivemos na instalação do trio GWT + SRL + PBXIP foi por
consequência de confusão na configuração das portas dos serviços.

11 As portas UDP 10000-20000 devem ser liberadas a partir do GWT;

11 As portas UDP 50000-60000 devem ser liberadas a partir do PBX-IP;

11 A porta UDP 5060 é para SRLs, a 5071 para GWT e a 5080 para PABX.

Seguem alguns endereços importantes na arquitetura:
Serviço fone@RNP

54
SRC-RJ 200.143.193.54 ----

SRC-DF 200.130.35.113 ----

Monitoramento SNMP da RNP 200.130.77.77 monitora.rnp.br

Serviço de estatísticas do fone 200.143.193.54:8443 ----

Repositório de arquivos e imagens 200.130.35.236 repositório-fone.rnp.br

Servidor de Hora 200.144.121.33:123 ntp.cais.rnp.br
Figura 4.6
Alguns endereços Servidor de Hora (alternativo) ---- a.npt.br; b.ntp.br; c.rnp.br
importantes.

Outro resumo interessante para configuração de firewalls e dos próprios dispositivos:

11 Porta SIP do SRL é 5060;

11 Porta SIP do GWT é 5071;

11 Porta SIP do PBX é 5080.

Sempre que estiver na dúvida, sempre que configurar um módulo do fone@RNP, volte aqui e
revise os fluxos para configurar corretamente seu firewall.

Testes de chamadas (checklist)
Após a instalação da solução e depois de cada instalação de um módulo do fone, será neces-
sário testar se todos os tipos de chamadas podem ser realizados normalmente.

Tomemos um hipotético Campus A como referência. Todos os tipos e direções de chamadas
devem ser testadas, sempre que for cabível, conforme listadas a seguir.

Ligações dentro do Campus A

11 Ligações feitas a partir de telefones IP para telefones IP;

11 Ligações feitas a partir de telefones analógicos para telefones analógicos;

11 Ligações feitas a partir de telefones IP para telefones analógicos;

11 Ligações feitas a partir de telefones analógicos para telefones IP.

Ligações “entrantes” no Campus A

11 Ligações para dentro do Campus A, com origem na RTFC.

22 Para ramais IP;

22 Para ramais analógicos.
Capítulo 4 - Arquitetura do fone@RNP v.2012

11 Ligações para dentro do Campus A, com origem em outro campus da mesma instituição.

22 Para ramais IP;

22 Para ramais analógicos.

11 Ligações para dentro do Campus A, com origem em outro cliente do fone@RNP.

22 Para ramais IP;

22 Para ramais analógicos.

55
Ligações “saintes” do Campus A

11 Ligações para fora do Campus A, para outro Campus da mesma instituição.

22 A partir de telefones IP;

22 A partir de telefones analógicos.

11 Ligações para fora do Campus A, para outra instituição do fone@RNP no mesmo DDD.

22 A partir de telefones IP;

22 A partir de telefones analógicos.

11 Ligações para fora do Campus A, para outra instituição do fone@RNP em outro DDD.

22 A partir de telefones IP;

22 A partir de telefones analógicos.

11 Ligações para fora do Campus A, mas dentro da mesma cidade.

22 A partir de telefones IP para números locais na RTFC:

33 Celulares;

33 Fixos.

22 A partir de telefones analógicos para números locais na RTFC, celulares ou fixos:

33 Celulares;

33 Fixos.

22 Ligações para fora do Campus A, para números na RTFC em outro código de área:

33 Celulares;

33 Fixos.

22 A partir de telefones IP para números DDD na RTFC:

33 Celulares;

33 Fixos.

22 A partir de telefones analógicos para números DDD na RTFC:

33 Celulares;

33 Fixos.

Ligações para serviços especiais

11 1XX

11 1XX XXXX

11 0X00 XXXXXXX

11 9090 XXXXXXXX

11 90CA XXXXXXXX

Esses testes devem ser repetidos a cada modificação no serviço de telefonia, em todos os
sites dos clientes.
Serviço fone@RNP

Encaminhamento das chamadas
Uma importante premissa do novo fone@RNP diz que o encaminhamento das ligações
sempre deve ser feito de forma transparente ao usuário final.

56
O plano de numeração recomendado
Como já foi verificado em capítulo anterior, o Plano de Discagem (ou Plano de Numeração)
descreve a forma como são realizadas as chamadas no serviço de telefonia. Além dos dígitos
do Plano Nacional, os usuários dentro das instituições normalmente também precisam
discar o 0 (zero) para “pegar linha” ou para simular essa situação em PBX IP, evitando mudar

l
a cultura dos usuários.

11 0 (linha) + NÚMERO, para ligações locais;
A RNP recomenda
manter o mesmo Plano 11 0 (linha) + 0 (PrefixoLDN) + CSP + CA + NÚMERO, para ligações a distância e;
de Numeração
existente, indepen- 11 0 (linha) + 00 (Prefixo LDI)+ CSP + PC + (CA+NÚMERO), para ligações internacionais.
dente da tecnologia ou
da localidade. Então, não deve haver diferença na forma de discar, esteja um ramal atrás de um PABX IP ou
tradicional, seja analógico ou digital.

Integração de PABX legado e IP utilizando quatro dígitos

O fone@RNP foi desenhado de forma a permitir a fácil expansão da rede de telefonia de
suas instituições clientes. A utilização de um PBX IP, juntamente com o GWT e SRL, permite
a integração dos ramais IP e legados através de discagem abreviada, tipicamente implemen-
tada com quatro dígitos. Também é possível utilizar três ou cinco dígitos.

Além disso, através do serviço de DDR (das operadoras) também é possível encaminhar
automaticamente ligações que chegam pela RTFC tanto para os ramais analógicos quanto
para os ramais IP, no novo PBX IP.

Obviamente, a solução final depende de análise do plano de numeração e da distribuição de
DDRs em cada instituição.

Planejamento para instalação do fone@RNP
É importante que não só os procedimentos de instalação, mas também as características do
serviço na sua instituição estejam claramente documentadas. Então, escreva um plano de
mudança para sua instituição.

Se desejar, utilize o Plano de Mudança de exemplo, que se encontra na sessão de anexos,
adaptando para a realidade de sua instituição.

Capítulo 4 - Arquitetura do fone@RNP v.2012

57
58
Serviço fone@RNP
5
Gateway Transparente (GWT) e
Gateway Transparente analógico
(GWT-a)
objetivos

Aprender o roteiro de instalação, configuração e operação do módulo Gateway
Transparente do fone@RNP.

conceitos
GWT.

GWT

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
O Gateway Transparente (GWT) é o módulo fundamental do novo fone@RNP. Ele faz a
ligação entre o serviço de telefonia digital tradicional das instituições e o serviço de telefonia
IP da RNP de forma transparente, isto é, sem que o usuário do serviço telefônico precise
decidir se quer usar ou não o fone@RNP. Com esse módulo, o fone@RNP consegue alcançar
reduções expressivas na conta de telefonia das instituições clientes, com valores de cerca de
30% a 80% das chamadas de longa distância para números fixos. Mas atenção: esse número
pode variar bastante, para mais e para menos, dependendo do perfil de cada instituição.

O GWT foi desenhado para trabalhar com outros módulos do fone@RNP e com quaisquer
PABX legados, pré-existentes nas instituições. Ele espera receber INVITES apenas do SRL ou
SRC. E também só deve encaminhar INVITES para seu SRL ou SRC. Ele é capaz de entregar
ligações para serem terminadas na RTFC ou em um PABX legado com interface digital. O
GWT suporta os protocolos RDSI – Rede Digital de Serviços Integrados (em inglês, ISDN –
Integrated Services Digital Network) ou R2Digital (R2D) nas interfaces de telefonia e suporta
o protocolo SIP versão 2 na interface IP, de acordo com a RFC 3261.

O GWT é uma solução formada por um conjunto de partes, cada uma com uma função espe-
cífica. É possível destacar quatro partes principais:

11 Programas do fone@RNP:

22 Um conjunto com o Sistema Operacional (Ubuntu), Asterisk, OpenLDAP, Mysyql, Apache
(e outros) é responsável pela interface gráfica de configuração do GWT, pelo backup das
configurações e pelo funcionamento do GWT em conjunto com o serviço fone@RNP.

59
11 Servidor (com interface de rede IP):

22 Responsável por abrigar o Sistema Operacional e programas do GWT. Pode variar
bastante, tanto no poder computacional quanto de fabricante ou montador. Não há
rigidez quanto a requisitos de disco, memória ou mesmo velocidade da CPU. De forma
geral, um servidor mediano atual é suficiente.

11 Placas de telefonia digital (E1):

22 Responsáveis pela interface com a rede de telefonia tradicional. A RNP começou utili-
zando placas fabricadas pela Digium, a mesma empresa responsável pela evolução do
Asterisk, mas depois evoluiu e está utilizando atualmente placas da empresa brasileira
Khomp, sediada em Florianópolis.

11 Kommuter:

22 Dispositivo de fabricação nacional, também pela Khomp, responsável pela sobrevi-
vência do serviço de telefonia no caso de parada do servidor.

GWT 2.0
Em 2013, foi testada e aprovada uma solução de hardware para telefonia com portas E1 e
Kommuter integrados, de fabricação nacional, onde seria possível embarcar todo o software
necessário ao funcionamento do GWT, integrando totalmente as quatro partes que citamos.
A essa solução a RNP deu o nome de GWT 2.0.

Essa ação facilitou substancialmente os processos de:

11 Aquisição de hardware, eliminando importações;

l
11 Composição da solução, reduzindo o número de fornecedores;

11 Instalação do software, que agora virá pronto, já embutido no hardware;
Para informações sobre
11 Manutenção, já que o fornecedor é nacional e com ótimo relacionamento com a RNP. como instalar o GWT
com servidores Dell +
Portanto, restou ao cliente do GWT 2.0 ligar os cabos e configurá-lo. Placas Digium +
Kommuter, veja os
Esse capítulo tratará da configuração do Gateway transparente 2.0, implementado em anexos neste livro.
hardware nacional, da empresa Khomp.

Gateway Transparente 2.0
O GWT 2.0 é módulo do fone@RNP GWT embarcado em hardware nacional que já con-
templa portas E1 para telefonia digital, by-pass (kommuter) e todos os recursos computacio-
nais necessários para rodar o fone@RNP.

Figura 5.1
O Gateway
Transparente
(GWT).
Serviço fone@RNP

60
l Ligando os cabos
Para ilustrar esse guia,
foi utilizando o Sistema A ligação física do GWT 2.0 é muito fácil. Reserve o cabo de força para ligá-lo apenas no final
Operacional Windows 7. da operação.
Caso você esteja
utilizando outra versão 11 Tomemos por base a figura que apresenta a visão da parte de trás do GWT. Há pelo
do Windows ou mesmo
menos cinco portas que parecem ser portas ethernet;
outro Sistema
Operacional, será 11 As duas portas da metade superior estão sobre um fundo preto. Esse é o módulo das placas
necessário adequar as
E1. Portanto, não são portas de rede! A porta E1 que fica mais à esquerda deve ser ligada ao
instruções à sua
estação de trabalho. balun que vai ligar ao tributário da operadora. A porta E1 que se localiza à direita deve ser
ligada ao balun que vai se ligar ao PABX da instituição. Há a possibilidade de o GWT apre-
sentar mais módulos. Note que há mais dois espaços para inserção de módulos adicionais;

11 As portas que se localizam na metade de baixo são as portas de rede. Utilize a porta mais
à esquerda para ligar o cabo UTP ao seu switch. Deixe as demais portas livres;

11 Por fim, ligue o cabo de energia e ligue o GWT.

Ligação
Convencional PABX

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Conexão
RJ45
Balum Balum

Placa VoIP do Servidor Gateway
com kommuter embutido

Internet
Figura 5.2 SRL ou SRC
Ligação dos cabos e Fone@RNP
baluns no GWT.

Acessando e configurando o GWT
Configurando uma estação para acessar o GWT
O GWT vem pré-configurado com o endereço IP 10.255.255.1. Para acessá-lo, coloque seu
desktop ou outra máquina no mesmo segmento de rede, por exemplo: 10.255.255.5. Clique
no botão “Iniciar”, “Painel de Controle”, “Rede e Internet”, “Central de Rede e Compartilha-
mento” e do lado esquerdo escolha, “Alterar as configurações do adaptador”.

61
Aparecerá a tela conforme próxima imagem. Figura 5.3
Central de rede e
compartilhamento.

Clique com o botão direito na placa de rede do computador e escolha a opção “Propriedades”. Figura 5.4
Conexões de rede.
Serviço fone@RNP

62
Figura 5.5 Selecione “Protocolo TCP/IP Versão 4” e clique em “Propriedades”.
Conexões de rede.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Figura 5.6
Propriedades de
conexão local.

63
Selecione a opção “Usar o seguinte endereço IP:” e preencha os campos de acordo com a
próxima figura. Clique em “OK” para salvar a configuração.

Figura 5.7
Propriedades de
protocolo TCP/IP v4.

Para testar, execute um comando através do prompt de comando. Clique no botão “Iniciar”. No
campo destinado a “Pesquisar programas e arquivos”, digite CMD e tecle “ENTER” (figura 5.8).
Serviço fone@RNP

64
Figura 5.8
Menu Iniciar.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Figura 5.9
Ping: Prompt de Na tela do prompt digite: “ping 10.255.255.1” e tecle “ENTER”. O resultado deve ser seme-
comando. lhante à próxima figura.

65
Feche o prompt e, utilizando o navegador de sua preferência, digite o endereço
“https://10.255.255.1”. Nesse guia, foi utilizado o Google Chrome.

Figura 5.10
Primeiro acesso
ao GWT.

Ignore o aviso do certificado autoassinado. Clique em “Continuar mesmo assim”.

Acessando e configurando o GWT Figura 5.11
Seguindo os passos anteriores, será exibida a tela de login: Login.
Serviço fone@RNP

66
Informe os dados a seguir para o acesso e clique no botão “login”.

Usuário: admin
Senha: gwt.admin

Substitua o usuário e a senha padrão de administrador imediatamente!

Após fazer o acesso, será exibida a tela inicial, semelhante à figura 5.10. Observe no canto
superior direito que o módulo “Gateway” está selecionado. Essa é a tela de monitoramento
do GWT, que indica quais serviços estão funcionando ou não, informações do hardware,
informações de rede e outros detalhes.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Figura 5.12 Para fazer a configuração do GWT, acesse a tela de administração do sistema, clicando em
Status. “Sistema” no canto superior direito.

67
1

4
2

3

Nesta tela, é possível criar um novo usuário (3) ou editar as informações de um usuário Figura 5.13
existente (4), além de fazer as configurações para o funcionamento do equipamento (2). Usuários.

Lembre-se de trocar o usuário Admin e altere a senha padrão, para uma nova senha, mas
desta vez use uma senha forte.
Serviço fone@RNP

68
Figura 5.14 Feitas as configurações, devemos em seguida configurar o firewall para evitar a perda de
Edição de usuários. acesso ao servidor, quando este for configurado com IP público.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Configurações > Firewall

O início da configuração do GWT será feito pelo firewall, pois será preciso cadastrar o IP da
máquina e/ou rede que fará a gerência do GWT. Se for feita alguma alteração de IP antes da
configuração da gerência, poderá ocorrer a perda do acesso ao GWT.

No menu “Configurações”, clique na opção “Firewall”. Role a página até o final e localize a
área que contém “Rede de Gerência”.

69
Observe na próxima figura que o IP 10.255.255.0 está cadastrado e deve permanecer assim Figura 5.15
até a finalização da configuração, pois ele permitirá acesso a essa rede caso algo saia errado. Configuração de
firewall.
Você deve removê-lo apenas em uma segunda etapa.

Agora inclua as demais redes de onde você poderá realizar manutenção no GWT. Clique no Figura 5.16
botão e informe o IP da máquina/rede que fará o acesso ao GWT e a máscara da rede, Rede de Gerência.

conforme exemplos na figura anterior. Clique em “Salvar” e depois em “Aplicar Configurações”.

Na área “Ações”, ainda na página do Firewall, forneça os IPs que poderão enviar mensagens
SIP ao GWT (no caso SRC ou SRL). Se o ambiente estiver conectado ao SRL, somente esses
IPs são necessários.
Serviço fone@RNP

Insira também a porta 8443 TCP com origem no endereço IP 200.143.193.54/32. Esse é o Figura 5.17
servidor que busca informações de CDR para o sistema de estatísticas nacionais. Ações.

Seguem alguns endereços importantes para configuração:

70
SRC-RJ 200.143.193.54

SRC-DF 200.130.35.113

Monitoramento SNMP da RNP 200.130.77.77

Serviço de estatísticas do fone 200.143.193.54:8443

Tabela 5.1 Servidor de Hora 200.144.121.33 (CAIS – RNP)
Endereços
importantes. Servidor de Hora (alternativo) 200.160.0.8; 200.189.40.8; 200.192.232.8 (NTP.br)

Após configurar o firewall revisando os parâmetros de sua instituição, clique em “Salvar” e
depois “Aplicar”.

Configurações > Ambiente: Configuração Inicial

Nesta opção, o administrador poderá inserir ou editar configurações de funcionamento
do serviço FONE@RNP. No menu “Configurações”, do lado esquerdo da página, na opção
“Ambiente”, existem algumas guias que serão descritas a seguir.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Figura 5.18 Guia Instituição
Configurações
de Ambiente: Guia que contém as informações da instituição e do responsável pela administração do
Instituição. serviço Fone@RNP.

Clique na guia Instituição e preencha com os dados do solicitados. Ao concluir clique em
“Salvar Alterações”.

71
11 Sigla: sigla corresponde à instituição que está sendo instalado o GWT. Não devem ser Figura 5.19
utilizados espaços em branco nem mais de uma palavra para a sigla. Caso necessário, Instituição.

utilize um traço;

11 Campus: campus ou unidade correspondente a instituição em que está sendo instalado
o GWT;

11 Nome da Instituição: nome completo da instituição;

11 Nome do responsável para contato: nome da pessoa que ficará responsável pelo
serviço na instituição;

11 Telefone para contato: telefone de contato do responsável; preferencialmente,
telefone móvel;

11 E-mail para contato: correio eletrônico de contato do responsável.

Guia Sistema

Guia responsável pelas configurações do Sistema do GWT. A seguir, a descrição de cada
campo, conforme mostrado na próxima figura.

11 Hostname: nome do servidor no domínio. Não deve conter espaços em branco; Figura 5.20
Instituição.
11 IP: preencher com o IP que será destinado ao GWT. este IP deve ser público;

11 Máscara: máscara de Rede do IP;
l
11 Gateway: IP do Gateway da rede; No “Hostname” a
11 NTP1 e NTP2: endereços dos servidores de NTP; padronização adotada
para o FONE@2014 é
Serviço fone@RNP

11 DNS Resolver1 e DNS Resolver 2: esses servidores de nomes devem ser capazes de “GWT-sigla da
instituição”,
resolver zonas de ENUM;
Exemplo:Exemplo:: o
11 Domínio: o domínio ao qual o GWT pertence. IFPE Campus de
Garanhuns/PE, por
exemplo, será
“GWT-IFPEGUS”.

72
Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Alterações”.

Guia Aplicar Configurações

Após configurar o ambiente, é necessário aplicar as configurações do sistema, para que
todas as alterações surtam efeitos. Para isso, você deve acessar, no menu “Ambiente”, a
opção “Aplicar Configurações”.

Figura 5.21 11 Configurações de Sistema: quando selecionada, aplica as configurações que foram feitas no
Aplicar que se diz respeito ao sistema, como alterações nas guias Instituição, Sistema e Gerência;
configurações.
11 Configurações de Asterisk (TDM, ENUM, Proxy SIP): quando selecionada, aplica as
configurações que foram feitas no que se diz respeito ao GWT e seus serviços.

l

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Marque as duas caixas de opção (“Configurações de Sistema” e “Configurações de Asterisk”,
e clique no botão “Aplicar configurações selecionadas”).
Lembre-se que, após
esse procedimento, Configurações > Sistema: atualizando o GWT
você perderá o acesso
ao GWT. Para obter
No menu “Configurações”, selecione “Sistema” e, em seguida, a opção “Atualizações”. Se
novamente o acesso ao
GWT, você terá de houver alguma atualização disponível, será exibido conforme a próxima figura.
reconfigurar a rede da
sua máquina e acessar,
via browser, o novo IP
que foi configurado no
GWT.

73
Caso a aba de atualização apresente algum erro na conexão, por favor, entre em contato Figura 5.22
com o Service Desk. Ações do sistema.

Para atualizar, basta clicar então em “Atualizar aplicações” e aguardar a execução do proce-
dimento. Na sequência, clique na guia “Ações” e em “Reiniciar Servidor”.
l
Nesse ponto, pode ser
Configurações > Ambiente: finalizando a Configuração necessário entrar em
contato com o suporte
do fone@RNP para
Guia Gerência liberação do acesso de
seu novo servidor ao
Nesta tela é possível definir comunidades SNMP de Read-Only para gerência do ambiente, repositório do serviço,
onde se encontram as
desviar logs para um servidor centralizado e ainda definir um servidor para envio de e-mails.
atualizações de todos
os módulos do fone.
No quadro SNMP, configure com sua comunidade e a rede de gerência, caso sua instituição
possua um sistema de gerência de redes. O serviço de monitoramento da RNP já é auto-
maticamente inserido e não fica explícito aqui. Você deve apenas configurar a firewall para
permitir o acesso do servidor da RNP.

O servidor de e-mail permite realizar relay de forma autenticada. Se você tem um relay de
e-mails em sua instituição, configure com esse parâmetro para receber mensagens de alerta
desse módulo do fone.

Você também pode configurar um servidor de syslog. Para desabilitar o relay para um syslog
externo, forneça o endereço 127.0.0.1.
Serviço fone@RNP

74
Figura 5.23 Guia TDM
Gerência.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Nesta opção, serão definidos os prefixos dos números da instituição, e como será realizado
o encaminhamento interno no GWT.

Na área “Telefonia convencional”, devem ser informados os dados atuais de telefonia
da instituição.

75
11 Código de País: não é necessário incluir o sinal “+”. Digite 55 para Brasil; Figura 5.24
TDM.
11 DDD: deve ser preenchido com o código de área da localidade da instituição cliente;

11 Prefixo: são os quatro primeiros dígitos do número telefônico da instituição.
Por exemplo, a RNP-RJ possui o número (21) 2102-9660. O prefixo é 2102;

11 Código da Operadora: é o CSP, código de seleção da prestadora. Exemplo: 31 (Oi),
21 (Embratel);

11 Linha Externa: se existe algum número programado, para ser digitado para acessar a
PSTN. Normalmente, é utilizado 0 (“para dar linha”). Caso não possua, deixe em branco.

11 Ramal PBX Inicial e Final: informações da faixa de ramal PABX convencional, onde o
GWT encaminhará as chamadas recebidas para o tronco conectado ao PABX.

Os campos na área “VoIP” devem ser preenchidos com informações fornecidas pela RNP:

11 Prefixo: são os quatro primeiros dígitos (do total de 8 dígitos) dos números de telefones
virtuais. Esses prefixos são informados pela RNP ao cliente durante a adesão e são
válidos apenas dentro do serviço Fone@RNP;

11 Ramal Inicial: são os quatro últimos dígitos (do total de oito dígitos) que especificam o
primeiro ramal do intervalo que o cliente deseja utilizar como números virtuais. Esses
números são determinados pelo administrador do fone@RNP na instituição;

11 Ramal Final: são os quatro últimos dígitos (do total de 8 dígitos) que especificam o último
ramal do intervalo que o cliente deseja utilizar como números virtuais. Esses números
são determinados pelo administrador do fone@RNP na instituição;

11 Ramal Padrão de Saída: é o número que será apresentado como origem das chamadas
feitas pela instituição. Normalmente, se utiliza o tronco-chave;
Serviço fone@RNP

11 Ramal da URA: é o ramal que deve ser discado para acesso ao sistema de telefonia IP,
utilizado no fone versão 2008. Está presente aqui para fins de compatibilidade com as
versões anteriores do fone.

76
Na área externa:

11 Valor do Minuto: valor estimado do custo do minuto de uma chamada telefônica. Utili-
zado para cálculo aproximado da economia.

Os botões de período de contabilização são utilizados para definir o intervalo de tempo que
se deseja apresentar a estimativa de economia.

Guia ENUM

O GWT utiliza mais de uma árvore ENUM em sua lógica interna para encaminhamento das
chamadas.

Nesta guia, devem-se definir quais tabelas ENUM o GWT vai consultar para verificar se existe
rota IP para o número discado. Caso o GWT esteja conectado ao SRL, deverá ser habilitada a
tabela local para ativar a consulta de rotas do SRL criadas pela instituição.

Figura 5.25 Ative todas as tabelas de pesquisa. Clicando em “Selecionar” em todas as opções. Só ative a
ENUM. tabela Local se estiver utilizando um SRL. Em seguida, clique em “Salvar as Alterações”.

Guia Proxy SIP

Define as informações referentes ao GWT e IPs do SIP-Router (Central ou Local).

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Figura 5.26 11 Realm VoIP: preencher com o realm da instituição. Exemplo: rnp.br ou voip.rnp.br (realm
Proxy SIP. = reino; domínio);

11 IP do Gateway: endereço IP no qual o GWT vai escutar. Esse endereço deve ser o mesmo
fornecido da Guia Sistema, campo “IP” (figura 18);

11 Porta do Gateway: recomenda-se deixar a padrão: 5071;

11 IP SIP Router: colocar os endereços do SRL ou SRC, de acordo com a topologia escolhida.

77
Guia Serviços Habilitados

Para iniciar um serviço, basta clicar em “Selecionar” e, para parar. clique em “Cancelar”.

Após finalizar as configurações do ambiente, repita o procedimento para aplicar as configu- Figura 5.27
rações, conforme descrito no item 2.2.2.c (Guia Aplicar Configurações). Serviços
Habilitados.
Configurações > Placas: configuração das Placas E1

Para acessar o módulo de configuração do EBS da Khomp, clique em “Mostrar Módulo de
Configurações Khomp”.

Feito isso, será exibida a tela conforme figura a seguir. Figura 5.28
Configurações
das placas.
Serviço fone@RNP

78
Figura 5.29 Para acessar o módulo de configuração Khomp, utilize as credenciais confirme informado na
Acesso ambiente tela: usuário: “config” e Senha: “config”.
Khomp.
Após o acesso, deverá ser exibida uma tela semelhante a esta:

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Figura 5.30 Na interface da Khomp, no quadro interno, selecione as opções “Configuração”,
Configuração de “Dispositivos”, “Procurar”.
placas Khomp.

79
Selecione o dispositivo encontrado e clique em “Adicionar”. Figura 5.31
Configuração de
placas Khomp.

Clique na imagem do dispositivo para fazer a sua configuração. Figura 5.32
Configuração de
placas Khomp.
Serviço fone@RNP

80
Figura 5.33 Será exibida a tela a seguir, onde você deverá configurar o IP e o sincronismo das placas.
Configuração do Utilize o IP 192.0.2.201.
EBS Server.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Figura 5.34 A seguir, configure o tipo de sinalização utilizado no seu link e o clock. O link 1 será o link da
Configuração do operadora e deverá “Receber” o clock. O link 0 vai “Gerar” clock. Ao final, clique em “Salvar”.
EBS Server.

81
Figura 5.35
Deve-se acertar o número de dígitos de entrada dos canais R2. Para a placa da PBX, confi- Configuração do
gure com 20 dígitos e, para a placa da PSTN, configure com 4 ou 8, dependendo de quantos sincronismo de
dígitos serão de identificação e encaminhados para a operadora. linha.

Você será redirecionado para a visão do dispositivo, conforme a próxima figura, onde não Figura 5.36
mais consta o erro, possivelmente exibido antes. Configuração da
quantidade de
dígitos esperados.
Serviço fone@RNP

82
Figura 5.37 Em seguida, habilite o serviço Asterisk em “Ambiente” > “Serviços Habilitados”, e clique em
Configuração do “Salvar Alterações”.
EBS Server.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Figura 5.38 Ao acessar, pela interface do Khomp, a opção de monitoração dos serviços, você poderá
Serviços obter um erro conforme mostra a figura a seguir.
habilitados.

83
Caso isso ocorra, reinicie o servidor no menu “Sistema”, “Ações”, “Reiniciar Servidor”. Figura 5.39
Configuração do
EBS Server.

Acesse novamente a opção de monitoração dos serviços Khomp e verifique se o serviço Figura 5.40
Reiniciar GWT.
Serviço fone@RNP

Asterisk está ativo. Observe que agora já são exibidas as interfaces dos links 0 e 1.

84
Figura 5.41 O próximo passo é fazer a configuração das placas. Selecione a primeira placa, clicando no
Configuração do ícone da coluna “Editar”, e preencha os dados conforme mostrado na figura a seguir. Essa
EBS Server.
placa refere-se ao contexto da PBX.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Em seguida, configure a segunda placa com o contexto PSTN, conforme demonstrado na
Figura 5.42 próxima figura.
Configuração do
primeiro link.

85
Volte ao menu “Ambiente”, “Aplicar as Configurações”. Selecione a opção “Configurações de Figura 5.43
Asterisk” e aplique as configurações selecionadas. Configuração do
segundo link.

Habilite em seguida o Kommuter, no menu “Ambiente” > “Serviços Habilitados”, e salve as Figura 5.44
alterações, aplicando novamente as configurações em seguida. Aplicar
Serviço fone@RNP

configurações.

86
Figura 5.45 Configurações > Backup
Confirmação
para aplicar Essa opção permite a criação de arquivos de backup, bem como restaurar a configuração
configurações. importando as informações de um arquivo de backup existente.

Caso aconteça alguma falha de hardware no servidor ou por algum motivo você tenha de
trocá-lo, os dados de configuração de seu ambiente podem ser facilmente restaurados,
otimizando o tempo de instalação e configuração.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Figura 5.46 Crie um arquivo de backup, clicando no botão “Backup do arquivo M4”, e escolha onde vai
Fazendo backup. guardar o arquivo. Caso seja necessário restaurar as configurações, basta clicar no botão
“Escolher arquivo” e apontar onde o arquivo M4 estaria e em seguida clicar no botão “Enviar”.

Monitoramento
É a tela exibida logo assim que se entra no módulo ou quando se clica no botão Gateway, no
canto superior direito da página. Nessa página serão apresentados erros de não confor-
midade com algum serviço monitorado, que merece atenção e devem ser corrigidos para
evitar problemas de disponibilidade ou segurança.

Clique no módulo “Gateway” (canto superior direito da página) para abrir a página de
monitoramento.

87
Observe que quando executada a ação anterior, no lado esquerdo da página nas opções do Figura 5.47
menu “Monitoramento”, podemos escolher “TDM” ou “Canais”. Status do GWT.

Clique na opção “TDM”.

Quando clicado na opção “TDM”, é possível monitorar as interfaces (placa 1 e placa 2) conec- Figura 5.48
tadas na PABX e PSTN, informando visualmente um status das interligações. A figura mostra Status dos links E1.

como ficará a tela após tudo configurado corretamente.

Clique no botão “Detalhes”, último ícone na linha de cada placa.

Ao clicar no botão “Detalhes”, sua página deve ficar semelhante à próxima figura, onde são
exibidos todos os canais de comunicação e seu status.
Serviço fone@RNP

88
Figura 5.49 É possível também visualizar as ligações que estão ocorrendo nesse instante no GWT. Em
Status dos links E1. “Monitoramento” > “Canais”, será exibida uma tela como a da próxima figura. Observe que
existe uma ligação em andamento. O sistema mostra as duas “pernas” da ligação.

Figura 5.50
Ligação em curso. Contabilização
No menu Contabilização, existem as opções que nos dão relatórios de como está o compor-
tamento do serviço Fone@RNP no GWT. Nesse menu existem as opções: Estatísticas,
Chamadas Completadas, Não Completadas e Mais Chamados (Números mais discados).

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Estatísticas
Na opção “Estatísticas” do menu “Contabilização”, é possível acompanhar e observar
graficamente as estatísticas das ligações do ambiente. Abrange ainda estatística de “Estima-
Figura 5.51
Estatísticas. tiva de Economia” e exibe os valores em moeda corrente.

89
Completadas
Na opção é mostrado o CDR (Call Detail Record ou Registro de Detalhes da Chamada: registro
de uma ligação – conexão – telefônica) das chamadas completadas pelo GWT. Essa tela
também exibe o tipo de terminal utilizado para fazer essa ligação: se foi IP, PSTN ou PABX.

Figura 5.52
Não Completadas Chamadas
completadas.
Mostra o CDR das chamadas não completadas pelo GWT, informa o motivo por que não
completou e com o tipo de terminal utilizado para realizar a chamada IP, PSTN ou PABX.
Figura 5.53
Note que chamadas “não completadas” nem sempre significam um problema. Uma ligação Chamadas não
para um número ocupado ou inexistente gera um registro (CDR) de não completamento. completadas.
Serviço fone@RNP

90
Mais Chamados
Em “Mais Chamados”, no menu “Monitoramento”, o administrador tem acesso às informa-
ções de uma base de reputação do GWT, onde fornece informações sobre os destinos. Esse
relatório foi desenvolvido para ajudar a detectar falhas em alguma entrega através de rede IP.

Figura 5.54
Números mais Gateway Transparente Analógico (GWTa)
chamados.
Uma das solicitações mais recorrentes que a equipe do fone@RNP recebia das instituições
era uma solução para que as instituições que não possuem enlaces digitais E1 pudessem

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
participar ativamente do serviço.

Inicialmente, foi esboçada a especificação de uma solução a qual teria capacidade de
atender aos requisitos funcionais da demanda. Em continuidade a essa ação, foi iniciada
uma busca nos sites (internet) e agendadas reuniões com os principais fabricantes, objeti-
vando identificar quais equipamentos poderiam funcionar como GWT analógico.

Após essas ações com os principais fabricantes de equipamentos de telefonia IP com sede
ou representante no Brasil, identificamos que o aparelho CIP850, fabricado pela Intelbras,
possui características compatíveis com o tipo de uso proposto e capaz de atender as especi-
ficações mínimas. Adicionalmente, o equipamento apresentou opções de uso superiores às
necessidades definidas.

Muito simplificadamente, o CIP850 possui capacidade para 50 ramais (ou troncos) SIP, mais
8 portas analógicas, FXS ou FXO, agrupadas de 2 a 2.

É importante ressaltar que outros equipamentos também podem ser utilizados, como
Gateways AudioCodes ou um conjunto de servidor + placas Digium). A RNP decidiu realizar
um Piloto com esse produto, pois do ponto de vista financeiro, o equipamento utilizado aqui é
significativamente mais barato que outras soluções estudadas. Além disso, no momento em
que este livro é escrito, a RNP ainda realiza outro piloto para um GWTa, utilizando o mesmo
hardware que o GWT (digital), do fabricante Khomp. Deve-se embarcar uma distribuição
modificada do Asterisk.

91
É de extrema importância que todas as instituições que queiram utilizar o GWTa acatem e exe-
cutem as recomendações a seguir desde os primeiros momentos da instalação do equipamento.

De qualquer forma, recomendações mínimas já podem ser listadas aqui:

11 Recomendamos fortemente sua instalação atrás de um firewall;

11 Também recomendamos fortemente a troca da senha de administrador ime-
diatamente após o primeiro acesso ao equipamento;

11 E recomendamos fortemente utilizar senhas fortes para os ramais! Jamais use
como senha o mesmo número do ramal ou o nome do usuário ou qualquer
combinação desses dois!

Enquanto escrevemos este livro, apenas o roteiro de instalação e configuração da solução
com o CIP850 está concluído. Veja a seguir.

Cenário considerado
Como a figura mostra, o CIP 850 deve funcionar interligando a operadora local aos ramais
analógicos pré-existentes. Há também a possibilidade de adicionar ramais IP diretamente
ao dispositivo, que pode funcionar como um PABX. Para garantir a interligação com o fone@
RNP, deve haver nessa localidade um SRL. O PBX IP da RNP é opcional.

SRL
RTFC

SIP FXOs
PBX IP CIP 850
Figura 5.55
FXSes Esquema de blocos
do ambiente com
Ramais IP Ramais analógicos GWTa.

O que é o CIP 850?
O equipamento CIP850, fabricado pela empresa brasileira Intelbras, é um PABX IP de
pequeno porte com interfaces analógicas para ramais e para troncos (FXSes e FXOs), e conta
também com a possibilidade de criar ramais e troncos IP através do protocolo SIP ou IAX.

Características básicas

11 Capacidade máxima de 50 afiliações (troncos + ramais);

11 Capacidade máxima de 8 portas analógicas para FXO/FXS (Modularizado de 2 em 2);

11 Suporte a cancelamento de ECO de 16ms;

11 Suporte a Codecs de Áudio (G711, G729) e Vídeo (H.261, H.263, H.263+, H.264).
Serviço fone@RNP

92
Objetivo

O principal objetivo no uso do CIP850 é a possibilidade de integrar ao fone@RNP pequenos
escritórios onde existam troncos analógicos. Existe também a possibilidade da utilização
integrada de telefones analógicos e telefones IP diretamente nessa unidade.

O CIP850 pode ser utilizado como única solução de telefonia em unidades pequenas. O
equipamento conta com recursos como grupo de ramais, definição de categorias, salas de
conferência, correio de voz etc. Entretanto, o escopo desse trabalho não prevê a configu-
ração de tais recursos.

Pré-requisito para utilização do CIP850 como GWTa do fone@RNP

Deve existir uma instância do SIP Router Local (SRL) na instituição atendida pelo CIP850.

Especificações técnicas

Capacidade máxima 50 linhas e/ou ramais IP
8 linhas e/ou ramais analógicos

Atendimento Automático DISA Incorporado

Identificação de chamadas Incorporado via DTMF e/ou FSK

Codecs de áudio G.711 U/A, G.729

Codecs de vídeo H.261, H.263, H.263+, H.264

Numeração dos ramais Flexível (qualquer número)

Peso 2 Kg

Dimensões 432 x 44,45 x 169 mm

Alimentação AC 90-240 Vac Bivolt automática, 50 ou 60 Hz

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Potência máxima 14 W

Alcance de linhas e ramais Linhas: 2000 Ohms
Ramais: 1100 Ohms (incluindo o telefone)

Proteção elétrica Nos troncos, ramais e alimentação AC contra transientes e oscilações da rede

Proteção de programação Uso de memória flash

Cancelamento de eco 16 ms

Interface Ethernet 1 porta RJ45 10/100

Protocolo SIP SIP Intelbras (solução proprietária compatível SIP 2.0)

Processador Blackfin BF 537 600 MHz

Memória Flash NAND 256 MB

93
Painel frontal

1 2 3 4 5

1. LEDs indicando o status da central.
2. Botão de Reset.
3. Conector RJ45 para porta Ethernet.
4. Conector para saída de áudio (Busca Pessoa).
5. Conectores RJ45 para portas analógicas. Figura 5.56
Painel frontal.

LEDs no painel frontal

1 2 3 4 5

1. LEDs indicando o status da central.
2. Botão de Reset.
3. Conector RJ45 para porta Ethernet. Figura 5.57
4. Conector para saída de áudio (Busca Pessoa). LEDs do painel
5. Conectores RJ45 para portas analógicas. frontal.

Painel traseiro

3 1 2 3

1. Conector do cabo de alimentação.
2. Parafusos para fixação da parte traseira da central. Figura 5.58
3. Suporte para fixação em rack 19”. Painel traseiro.

Instalação física do CIP 850
Instalação das placas FXOs e FXSs

O PABX IP CIP 850 possui a capacidade máxima de oito portas FXO e/ou FXS. As oito portas
são definidas através de placas modulares para uso da interface em duas em duas portas.
Caso o equipamento não esteja com os módulos previamente instalados, será preciso que
siga os seguintes procedimentos:
Serviço fone@RNP

1. Desconecte a central da alimentação elétrica;

2. Retire os parafusos da parte posterior da central;

3. Com a central aberta, encaixe as placas conforme a figura a seguir:

94
Figura 5.59
Instalação das
placas FXSs e FXOs.

Identifique a porta que a interface FXO e/ou FXS estará conectada.

Montagem em rack 19” (EIA)

As dimensões da central CIP 850 atendem ao padrão EIA: Electronic Industries Alliance, per-
mitindo sua instalação em Rack 19 polegadas. A central CIP 850 necessita de 1 U de altura
disponível no Rack para sua correta fixação. Para instalar corretamente o equipamento no
Rack, siga os seguintes procedimentos:

1. Desconecte a central da rede elétrica;

2. Instale os dois suportes em L (acompanham o produto), parafusando-os nas laterais da
central, conforme figura a seguir:

Figura 5.60
Presilha lateral.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
3. Escolha a posição desejada no rack e parafuse a central, conforme figura a seguir:

Figura 5.61
Fixação no rack.

4. Conecte o cabo de alimentação à central em uma tomada elétrica;

5. Conecte a central à rede através da porta Ethernet e conecte as linhas ou aparelhos tele-
fônicos às portas analógicas (caso as interfaces FXS e/ou FXO estejam instaladas).

Atenção: para garantir a ventilação correta e a dissipação do calor, não obstrua as
laterais da central.

95
Montagem em uma superfície lisa

A central pode ser posicionada sobre uma superfície lisa como uma mesa ou uma prateleira.
Para instalar nesse tipo de ambiente, siga o seguinte procedimento:

1. Desconecte a central da rede elétrica;

2. Fixe os quatro pés de borracha (acompanham o produto) na base da central, conforme
a figura a seguir. Os pés de borracha são autoadesivos. Retire a proteção para possibilitar
a colagem;

Figura 5.62
Apoio em mesa.

3. Conecte o cabo de alimentação à central e, em seguida, a uma tomada elétrica;

4. Conecte a central à rede através da porta Ethernet. Conecte as linhas ou aparelhos telefô-
nicos às portas analógicas (caso as interfaces FXS e/ou FXO estejam instaladas).

Aterramento

O aterramento é realizado pelo cabo tripolar que acompanha o produto.

Acoplamento

Na falta de energia elétrica, a central realiza o acoplamento. Para que ocorra o acoplamento,
os jumpers J5 e J6 (placa CPU) devem estar fechados. Para o correto funcionamento do aco-
l
Observação: os
plamento, obrigatoriamente deverá constar no slot 1 uma placa FXO, e no slot 4 uma placa jumpers J5 e J6 são
FXS. Caso não exista a conexão de placas distintas ou na ordem pré-definida, os jumpers abertos de fábrica.
deverão permanecer abertos, conforme padrão de fábrica.

Configuração lógica da central
Definições e conceitos básicos

Para correta configuração da central, alguns conceitos devem ser entendidos, tais como:

11 Juntores: troncos que permitem aos ramais realizarem e receberem ligações externas.
Os juntores operam como sendo a ponte de conexão entre a central privada e a pública.
Podemos configurar juntores analógicos, SIP e IAX;

11 Ramais: usuários que podem originar e receber chamadas, operando como linhas telefô-
nicas internas. A central CIP 850 disponibiliza a configuração de ramais analógicos, SIP e IAX;

11 Rota: as rotas são utilizadas pelos ramais para efetuar chamadas externas (para rede
pública, outra central ou um provedor de serviços VoIP) através dos juntores.
Serviço fone@RNP

96
Plano de numeração da Central

A Central CIP 850 tem um plano de numeração completamente configurável. Além de per-
mitir a troca de numeração dos ramais, podem ser alterados os códigos das funcionalidades
oferecidos aos usuários.

Sinalização dos aparelhos telefônicos

A central CIP 850 somente trabalha com sinalização por tom, não suportando a sinalização
por pulso (decádico). O uso das teclas * ou # é essencial para utilização dos serviços disponi-
bilizados ao usuário.

Configurando a central

A central CIP 850 é configurada através do programador web. Para acessá-lo, o endereço
IP da central deve estar na mesma faixa de endereço IP da rede do(s) computador(es) que
fará(ão) a configuração.

Informações de fábrica ao iniciar o uso do CIP 850

11 Endereço IP: 10.0.0.50

11 Máscara: 255.0.0.0

11 Login: admin

11 Senha: 1234

Para alterar o IP de fábrica da central CIP 850 (10.0.0.50), conecte a central CIP 850 direta-
mente ao computador, conforme a figura a seguir.

Figura 5.63

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
Primeiro acesso.

No computador, coloque o endereço de rede, na mesma faixa do endereço de rede de
fábrica da central CIP 850 (exemplo: 10.0.0.51/255.0.0.0). Dessa forma, podemos acessar no
navegador o IP de fábrica da central CIP 850 e alterar a rede conforme necessidades.

97
Abra o browser de sua preferência e acesse http://10.0.0.50 utilizando o usuário admin e a Figura 5.64
senha 1234. Propriedades da
placa de rede.

l
Observação: sempre
que realizar qualquer
alteração, clique no
botão “Aplicar/Salvar”
para que não perca a
configuração.
Serviço fone@RNP

Figura 5.65
login.

Alterar senha do usuário para acesso WEB

Para alterar a senha do usuário no acesso WEB do CIP 850, é preciso acessar o Sistema e a
opção Configurações. A aba Geral já será carregada automaticamente.

98
Troque a senha de administrador agora!

Figura 5.66
Alterando a senha
do administrador.

Configurando a interface de rede

Para alterar o endereçamento IP do CIP 850, é preciso acessar o Sistema e a opção
“Configurações”, escolhendo depois “Rede”. Para o projeto fone@RNP, o equipamento pode
Figura 5.67
Configuração da estar associado a um IP Privado; contudo, a saída da rede privada obrigatoriamente deverá
interface de rede. ter um IP fixo associado.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

Alterar configuração de data e hora

Para alterar as configurações de data e hora do CIP 850, é preciso acessar o Sistema e a
opção Configurações. Selecione a aba “Data/Hora”.

99
Figura 5.68
Configuração da
data e hora.

Alterar configuração de SIP

Para alterar as configurações básicas do protocolo SIP no CIP 850, é preciso acessar o
“Sistema” e a opção “Configurações”. Selecione a aba “SIP”.

Colocar o IP externo SRL

Colocar o IP externo SRL
Serviço fone@RNP

Figura 5.69
Configurações SIP.

100
No campo “Endereço Externo”, é essencial que se cadastre o valor do IP fixo associado ao
NAT na qual será identificado pelo SRL.

O campo “Bind Address” é o endereço IP do equipamento CIP 850.

Criando Juntor CIP850 para acesso ao fone@RNP

Para cadastrar o Juntor (tronco) do fone@RNP no CIP 850, é preciso acessar “Portas” e a
opção “Juntores”. Selecione a opção “Adicionar SIP” para cadastrar um Juntor SIP que será
configurado o fone@RNP.

Figura 5.70 Para esclarecer algumas informações, é importante saber que:
Juntores.
11 Número piloto: número enviado como identificação externa pelo Juntor;

11 ID Juntor: quando mais de um juntor SIP configurado em uma mesma central CIP 850 for
registrado em uma mesma operadora ou asterisk, ou seja, mesmo IP de destino, deve
ser configurado um identificador (número associado ao juntor) onde a central utiliza para
rotear/encaminhar as chamadas entrantes;

11 Modo de operação de DTMF: permite selecionar o modo como os DTMFs serão enviados
pelo juntor;

11 Permitir reinvites: se habilitado, permite que após estabelecida a chamada a mídia seja
trocada diretamente entre os ramais sem passar pela central;

11 Substituir reinvites por updates: envia um UPDATE em vez de um novo INVITE. Na
maioria dos casos não existem diferenças, exceto para algumas funcionalidades, como

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
por exemplo, uma renegociação do SDP;

11 SIP Qualify: permite selecionar o tempo máximo de resposta para que o juntor seja
considerado ativo;

11 Limite de chamadas: permite selecionar o número de chamadas (entrantes e saintes
somadas) que podem ser estabelecidas através desse Juntor;

Ao carregar a opção de “Adicionar SIP”, o formulário de cadastro será disponibilizado no padrão
a seguir. Atentem-se às informações de cadastro para que o serviço funcione perfeitamente.

101
1
Fone 2012

2

3

4

5

6
CIP850

7
*******

Figura 5.71
8 Configuração
IP do SRL
de juntores.

1. Nome: fone 2012 (Nome utilizado para identificar o Juntor);

2. Número piloto: YYXXXXXXXX (Número de identificação da Central através desse juntor.
Exemplo: 2131891050);

3. Atendente diurno: bridge (permite a função central de trânsito);

4. Atendente noturno: bridge (permite a função central de trânsito);

5. Direção: bidirecional (pode efetuar e receber o retorno da consulta);

6. Usuário: cIP850 (informação cadastrada no SRL);

7. Senha: foneatrnp (informação cadastrada no SRL);

8. Servidor: endereço do servidor SRL da sua instituição;

9. Porta: 5060 (Porta padrão SIP 5060);

10. Enviar pedido de registro: sim (Manter o CIP 850 registrado e assim com tronco funcional);
Serviço fone@RNP

11. Permitir reinvites: não permitir (SRL não permite reinvites);

12. Fromuser: manter informação não preenchida;

13. Fromdomain: manter informação não preenchida.

Após executar essas configurações, o status do Juntor SIP deverá estar indicando REGISTRADO,
conforme a imagem:

102
Figura 5.72 Fone 2012
Juntor registrado.

Criando Juntor CIP850 para acesso aos canais Analógicos

O CIP 850 cria automaticamente os Juntores associados aos canais Analógicos FXOs insta-
lados. Dessa forma, ao acessar o menu “Portas” e a opção “Juntores”, serão listadas todas as
Portas de 1 a 8 que estiverem com módulo FXS.

Para editar a configuração desses módulos, basta clicar na opção do lápis próximo ao nome
do juntor e escolher as configurações melhor associadas ao cenário da sua instituição.

Configurando encaminhamento de chamadas no CIP 850

Após a configuração dos juntores analógicos e o juntor SIP do fone@RNP, é preciso confi-
gurar o roteamento das chamadas. Para isso, clique na opção “Roteamento” e depois na
opção “Rotas”.

O CIP 850, para funcionar corretamente no fone@RNP 2012, precisa configurar duas rotas de
acesso. A primeira rota é a rota de acesso direto à operadora. Para isto, clique em “Adicionar
rota” e preencha o formulário de cadastro com as seguintes informações:

11 Nome: operadora;

11 Acesso: 5;

11 Categoria Livre: sim;

11 Sem bilhetagem: sim;

11 Juntores utilizados: transfira para a caixa de seleção Juntores Utilizados todos os juntores

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)
ativos de FXS (Juntores que começam com o nome PORTAX);

11 Mantenha o Fone2012 na caixa de selação Juntores Disponíveis.

A segunda rota é a rota de acesso comum do serviço que incluirá o Juntor Fone 2012. Para isso,
clique em “Adicionar rota” e preencha o formulário de cadastro com as seguintes informações:

11 Nome: rotaFone;

11 Acesso: 0;

11 Categoria Livre: sim;

11 Sem bilhetagem: sim;

11 Juntores utilizados: transfira para a caixa de seleção Juntores Utilizados primeiramente
o juntor Fone2012 e posteriormente todos os juntores ativos de FXS (Juntores que
começam com o nome PORTAX);

11 Importante que o primeiro juntor na caixa de Juntores Utilizados seja o Fone2012.

103
Figura 5.73
Rotas.

Dessa forma, configuramos o dígito 0 como acesso para encaminhar chamadas para o Juntor
RotaFone, portanto, todo número que for discado com 0 na frente (exemplo: 0 048 9999-9999)
Figura 5.74
será encaminhado para o SRL. Visualizando rotas.

Configurando ramais no CIP 850
Figura 5.75
Clicar em ramais, depois em adicionar SIP. Ramais e rotas.
Serviço fone@RNP

104
Figura 5.76
Ramais.
Configurar ramais de 3 ou 4 posições e adicionar a RotaFone.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

105
Figura 5.77
Ramais.
Serviço fone@RNP

106
Figura 5.78
CODECs.
Configurando os CODECs

Marque ao menos alaw, ulaw e G.729.

Capítulo 5 - Gateway Transparente (GWT) e Gateway Transparente analógico (GWT-a)

107
Serviço fone@RNP

108
6
SIP Router Local (SRL)
objetivos

Conhecer o roteiro de instalação, configuração e operação do módulo SIP Router
Local do fone@RNP.

conceitos
SRL.

Sobre o SIP Router Local – SRL
O SIP Router Local (SRL) é o módulo do fone@RNP responsável por manter a informação
de cada dispositivo SIP, da manipulação (reescrita) de números, quando necessário, e das
rotas para encaminhamento das chamadas entre os diversos campi e/ou dispositivos SIP da
instituição e o núcleo do serviço fone@RNP. O SRL só aceita INVITEs vindos dos dispositivos
cadastrados nele ou dos SRCs.

No SRL encontram-se todas as rotas para os números alcançáveis pela instituição cliente,
sejam eles números internos (dos ramais dos PABX pré-existentes), números na RTFC ou
números virtuais do fone@RNP. As informações de rota ficam armazenadas no LDAP e são
publicadas no DNS, em registros NAPTR, de acordo com o protocolo ENUM [RFC-6116].

O SIP Router Local (SRL) é equivalente ao SRC, mas instanciado nas premissas dos clientes.
O SRL pode ser instanciado mais de uma vez dentro da mesma instituição. Isso significa que
o próprio SRL pode ser hierarquizado, criando níveis de atendimento e isolando logicamente
os campi das instituições clientes.

Quando um INVITE chega ao SRL, ele realiza uma pesquisa ENUM para verificar o endereço
SIP equivalente ao número discado. Pode receber como resposta
Capítulo 6 - SIP Router Local (SRL)

11 A indicação de encaminhamento pelo SRC quando a chamada é para outro cliente do
fone ou para uma cidade onde haja um cliente ou;

11 A indicação de outro módulo SRL, PBX IP ou para um GWT da própria instituição quando
a chamada é para um telefone analógico da própria instituição ou para um telefone na
RTFC local.

O SRL é preferivelmente implementado como uma Máquina Virtual. A RNP utiliza VMWare,
mas é possível implementar em qualquer outro fabricante ou tecnologia de virtualização,
embora a RNP não dê suporte para outras VMs.

109
O SRL é implementado sempre em duplas com finalidade de promover a “alta disponibili-
dade” do serviço. Se um servidor parar de responder por qualquer motivo, o outro deve
assumir e o serviço de telefonia não deve parar. Por isso, escolha servidores de virtualização
diferentes para instalar os SRLs, de preferência, distantes geograficamente.

Quando usar o SRL?
O único caso em que o SRL é dispensável é quando há apenas um GWT em uso pela insti-
tuição cliente. Em qualquer outro caso, o uso do SRL é recomendável. Mesmo que pareça
trivial a ligação de um dispositivo SIP diretamente ao fone@RNP, é recomendado a insta-
lação de um (par de) SRL na instituição cliente.

O SRL isola a rede interna, no domínio do cliente, do “core” do serviço do fone@RNP.
Fazendo uma analogia para redes IP, ligar um PABX diretamente ao SRC seria igual a querer
conectar uma estação de trabalho diretamente em um roteador do backbone.

Além disso, o SRL instalado na rede local da instituição diminui consideravelmente o tempo de
resposta das mensagens de controle e, consequentemente, o tempo de conexão das chamadas.

O SRL também faz manipulações no número discado, formatando de acordo com a reco-
mendação E.164 para que as pesquisas por rotas sejam padronizadas ou, ainda, adequando-o
para integração com outros dispositivos do fone@RNP.

As mensagens que os dispositivos SIP ligados ao SRL devem esperar como resposta quando
uma chamada não pode ser realizada são:

11 404: Not Found: sem Rota;

11 408: Request Timeout: o outro lado não responde. Pode estar indisponível;

11 503: Serviço Indisponível: enviado pelo GWT quando a E1 apresenta problemas;

11 486: Busy: o número discado está ocupado;

11 487: Request Terminated: o usuário chamou determinado número e cancelou antes de
atender ou chamou até cair.

Roteiro de instalação e configuração
Este guia apresenta como instalar, configurar e gerenciar o SIP Router Local (SRL), compo-
nente do fone 2012 responsável por realizar o controle, encaminhamento e contabilização
das chamadas no ambiente local da instituição.

Este guia foi elaborado com suporte as seguintes versões:

11 web: 1.0.35: 07/01/2014;

11 Core: 1.0.64: 07/01/2014.

O guia está dividido em Pré-instalação, Instalação, Configuração dos componentes e Docu-
mentação de uso de todos os dos módulos desenvolvidos até a versão atual.

Pré-instalação
Serviço fone@RNP

O SIP Router Local pode ser instalado tanto em máquina física quanto em máquina virtual,
através de procedimento manual ou via imagem do VMware. Para se instalar o componente
de forma redundante, é necessário realizar o procedimento de instalação duas vezes.
Recomenda-se o uso da imagem VMware.

110
Os requisitos mínimos para a operação são os seguintes:

11 Memória: 2GB RAM;

11 Armazenamento: 50 GB;

11 Sistema Operacional: Linux Debian 6.0.6;

11 VMware 5.0 e VMware-Tools instalados (somente quando instalado como máquina virtual).

Tenha em mão os endereços IP do servidor de máquinas virtuais e dos novos servidores que
serão instalados.

Nesse momento, é necessário entrar em contato com o Suporte do FONE@RNP, para
que seja liberado o IP da máquina que está baixando os pacotes para instalação, e
assim prosseguir com a instalação.

Instalação
O SIP Router pode ser instalado manualmente, partindo de um Sistema Debian, ou através
de imagem disponível de VMWare.

A seguir, é detalhado o procedimento para máquinas virtuais, utilizando VSphere Client.
A instalação manual será apresentada em um documento anexo.

Instalação utilizando VMWare

Antes de qualquer coisa, você deve ter instalado em uma estação de trabalho o programa
VMware vSphere, para acessar o servidor de VMs da sua instituição, que hospedará o SRL.

Para iniciar a instalação do SRL, siga os procedimentos a seguir:

11 Acessar o servidor de VMs através do VMware vSphere Client.

Capítulo 6 - SIP Router Local (SRL)

Figura 6.1
Login no VMware
vSphere Client.

Iniciar processo de importação da máquina através do menu “File” > “Deploy OVF Template...”.

111
Figura 6.2
vSphere Client:
Inventário.

No campo “Deploy from a file or URL”, definir a URL para selecionar o arquivo do template da VM:
http://repositorio-fone.rnp.br/fone2012/SRL/VM/release/1.0/update-20150313/FoneRNP-
-SRL-v2.ovf
Serviço fone@RNP

112
Figura 6.3
vSphere Client: ovf
template.

Capítulo 6 - SIP Router Local (SRL)

113
Prossiga com a instalação clicando em “Next/Próximo”.

Figura 6.4
vSphere Client: ovf
template details.
Serviço fone@RNP

114
Definir um nome para a máquina.

Figura 6.5
vSphere Client:
Nome e localização.

Capítulo 6 - SIP Router Local (SRL)

115
Definir o Resource Pool para colocar a máquina.

Figura 6.6
vSphere Client:
Resource Pool.
Serviço fone@RNP

116
Definir o disco a ser alocado para o SRL.

Figura 6.7
vSphere Client:
Storage.

Capítulo 6 - SIP Router Local (SRL)

117
Definir o formato do disco, selecionar “Thick Provision Lazy Zeroed”.

Figura 6.8
vSphere Client:
Formato do disco.
Serviço fone@RNP

118
Definir a rede a ser alocada para o SRL.

Figura 6.9
vSphere Client:
Mapeamento
de rede.

Capítulo 6 - SIP Router Local (SRL)

119
Finalizar a importação da VM.

Após ter concluído o processo de importação da VM, ligar a VM e a instalação estará concluída. Figura 6.10
vSphere Client:
Instalação com outros servidores de virtualização Pronto!

Alternativamente, é possível realizar a instalação da máquina virtual utilizando outras
soluções de virtualização. Nesse caso, a RNP não dará suporte nessa etapa, cabendo à insti-
tuição cliente concluir a instalação da máquina virtual.

Acessando e configurando o SRL
Configurando uma estação para acessar o SRL

O SRL está pré-configurado com o endereço IP 10.255.255.10/24. Para acessá-lo, é preciso
colocar uma estação de trabalho no mesmo segmento de rede do novo SRL, ou seja,
Serviço fone@RNP

10.255.255.0/24. Essa estação de trabalho pode ser uma máquina real, com a devida confi-
guração de switches. Alternativamente, um método menos trabalhoso talvez seja instalar
uma estação de trabalho virtual no mesmo servidor de máquinas virtuais e acessá-la remo-
tamente, como um Desktop Virtual. A seguir, os passos a serem executados:

120
Na estação de trabalho já ligada na mesma rede do SRL, clique no botão “Iniciar”, depois em
“Painel de Controle”, e então em “Central de Rede e Compartilhamento”. Do lado esquerdo,

l
escolha “Alterar as configurações do adaptador”.

Observação: se a Se a tentativa de acesso for de dentro do servidor de máquinas virtuais, basta adicionar um
máquina virtual estiver novo IP dentro da placa de Rede do TCP/IP.
atrás de um firewall, é
preciso ficar atendo às
Para ilustrar esse guia, foi utilizado o Sistema Operacional Windows 7. Caso você esteja
configurações e
permissões de acesso. utilizando outra versão do Windows ou mesmo outro Sistema Operacional, será necessário
adequar as instruções à sua estação de trabalho.

Figura 6.11 Aparecerá a tela conforme imagem seguinte:
Central de
compartilhamento.

Capítulo 6 - SIP Router Local (SRL)

Figura 6.12 Depois, clique com o botão direito em cima da placa de rede do computador e escolha a
Conexões de rede. opção “Propriedades”:

121
Nesse momento, será feita a configuração do IP da máquina no mesmo segmento de rede Figura 6.13
do SRL, para ser iniciado o acesso. Conexão local.

Dê um clique duplo em “Protocolo TCP/IP Versão 4”, conforme selecionado na figura a seguir.
Serviço fone@RNP

Figura 6.14
Propriedades da
conexão local.

122
Selecione a opção “Usar o seguinte endereço IP:” e digite, por exemplo, 10.255.255.5, de
acordo com a figura a seguir, e depois clique no botão “OK”.

Figura 6.15
Propriedades de
protocolo TCP/IP v4.

Para testar se o SRL está ”alcançável”, execute um comando através do prompt de comando.
Clique no botão “Iniciar”. No campo destinado a “Pesquisar programas e arquivos”, clique e
digite CMD e tecle “ENTER” (figura 6.16).

Capítulo 6 - SIP Router Local (SRL)

Figura 6.16
Iniciar.

123
Na tela do prompt, digite: “ping 10.255.255.10” e tecle “ENTER”. O resultado deve ser como o
da próxima figura, indicando que o SRL pode ser acessado pela sua estação de trabalho.

Figura 6.17
Saia dessa tela digitando “exit” e tecle “ENTER”. Prompt de
Comando – ping.
Abra o navegador de sua preferência e digite o endereço https://10.255.255.10.
Serviço fone@RNP

Aceite o certificado autoassinado. Figura 6.18
Primeiro acesso
ao SRL.

124
Clique em “Entendo os riscos” e, depois, no botão “Adicionar exceção...”. Aparecerá uma
janela na qual você deve clicar no botão “Confirmar exceção de segurança”.

Configuração preliminar do SRL

Seguindo os passos anteriores, aparecerá a seguinte tela:

Figura 6.19 Digite os seguintes dados para o acesso iniciais:
Primeiro login
no SRL. Usuário: admin
Senha: srl.admin

Após logar, a tela inicial será semelhante à figura 6.20. No canto superior esquerdo se
encontra o logo de identificação do SRL (1); na extrema direita se encontra a data de acesso
no sistema, nome do usuário de acesso e a opção de sair do sistema – Logout (2); a seguir se
encontram os menus que o usuário tem habilitado no sistema (3).

Ao entrar no ambiente pela primeira vez com o usuário admin, o usuário acessa o primeiro item
Capítulo 6 - SIP Router Local (SRL)

do menu “Status”, no qual o usuário tem acesso ao Status da máquina e o Status do Ambiente.

125
Status Figura 6.20
Status.
Na tela da guia Status, o administrador consegue obter as informações referentes à utili-
zação dos recursos da máquina do SRL e do ambiente.
Serviço fone@RNP

126
Figura 6.21 As informações contidas nessa sessão são as seguintes:
Status.
11 Número de CPUs e Porcentagem de Utilização: é listada a quantidade de CPUs alocadas
para o SRL, assim como seu modelo e velocidade, contendo ao lado o percentual de utili-
zação de cada uma;

11 Memória Efetiva, Memória Utilizada e Swap: memória Efetiva é a memória efetivamente
sendo usada pelo sistema; Memória Utilizada é o total de memória utilizada contando a
memória em cache; e swap é o total de memória utilizada como swap;

11 Número de processos: número de processos rodando no SRL;

11 Endereço IP: endereço IP alocado para o SRL;

11 Uptime: quantidade de tempo contada em dias, horas e minutos que o SRL está no ar
desde a última reinicializada;

11 Carga média do sistema: carga média do SRL no último minuto, nos últimos 5 minutos e
na última hora;
Capítulo 6 - SIP Router Local (SRL)

11 Partições e Porcentagem de Utilização: lista de partições utilizadas pelo SRL, contendo
respectivamente suas porcentagens de utilização;

11 Versão das tabelas do ENUM: listagem das versões das tabelas ENUM utilizadas pelo SRL.
As tabelas listadas são as seguintes:

22 enum.local: gerenciada pelo próprio SRL, na aba Rotas;

22 enum.fonernp.central: contém rotas internas do Fone@RNP. Gerenciada pelos SRC,
obtidas através de transferência DNS;

127
22 enum.pbx.central: contém rotas de PBX do Fone@RNP. Gerenciada pelos SRC, obtidas
através de transferência DNS;

22 enum.pstn.central: contém rotas de PBX do Fone@RNP. Gerenciada pelos SRC, obtidas
através de transferência DNS;

22 O formato de “Versão” é a data de última alteração da tabela mais um número de
2 dígitos.

11 Informações Gerenciais: contém o número de peers configurados, quantidade de rotas
configuradas, número de chamadas completadas e não completadas, e a quantidade de
chamadas dos últimos 5 minutos. Ao final, há um gráfico mês a mês contendo o número
de chamadas completadas e não completadas.

Configurações

Para realizar as configurações do sistema, o administrador deve acessar o menu “Configura-
ções”. Nessa sessão, devem ser inseridas as informações pertinentes à instituição. Cada aba
de configuração vai ser detalhada nas sessões subsequentes.

Aba Instituição Figura 6.22
Configurações:
Aba que contém as informações da instituição, o responsável pela Administração do serviço Instituição.
Serviço fone@RNP

Fone@RNP e configuração das Estatísticas Nacionais.

Clique na guia Instituição e preencha com os dados solicitados. Ao concluir, clique em
“Salvar Configurações”.

128
Figura 6.23 Informações gerais:
Configurações:
Instituição. 11 Sigla: sigla corresponde à instituição em que está sendo instalado o SRL;

11 Campus: Campus ou Unidade corresponde à instituição que está sendo instalado o SRL;

11 Nome da Instituição: nome completo da instituição. Existe um bug, que será corrigido
(a quantidade de caracteres não deve ser superior a 20);

11 Nome do responsável para contato: nome da pessoa que ficará responsável pelo
serviço na instituição;

11 Telefone para contato: telefone de contato do responsável; preferencialmente,
telefone móvel;

11 E-mail para contato: correio eletrônico de contato do responsável.

Estatísticas nacionais:

11 ID da Instituição: ID de identificação da instituição no serviço de Estatísticas Nacionais
da RNP, da antiga versão do serviço fone@rnp. Essa informação é vital para o sistema de
estatísticas. A RNP poderá fornecer o ID de sua instituição;

11 DDD Padrão: DDD padrão da instituição para fins de contabilização nas Estatísticas
Nacionais da RNP.

Aba Sistema

Aba responsável pelas configurações do Sistema do SRL. É onde se configura o SRL com um
dispositivo de rede. A seguir, a descrição de cada campo, conforme mostrado na figura.

Capítulo 6 - SIP Router Local (SRL)

Figura 6.24 11 Hostname: nome do servidor no domínio.
Configurações:
Sistema. Importante: no “Hostname”, a padronização adotada para o FONE@2012 é “SRL-sigla da
instituição-0X”, no qual o X deve ser substituído por 1 ou 2, indicando respectivamente,
o SRL principal e secundário. Exemplo: a RNP em Brasília terá os seguintes hostnames:
sRL-RNPDF-01 e SRL-RNPDF-02.

129
11 IP: aqui é inserido o endereço IP definitivo que será destinado ao SRL. Este IP deve
ser público;
l
Utilize um hostname
11 Máscara: máscara de Rede do SRL; qualificado. Não use:
“_”, “:”, ou outro
11 Gateway: é o endereço IP do Gateway dessa rede; caractere que não
11 NTP1 e NTP2: servidores NTP, para manter o relógio do servidor sincronizado. forme um FDQN (Fully
Qualified Domain
Por exemplo, ntp.cais.rnp.br, a.npt.br ou b.ntp.br; Name). FQDN é o nome
dado a computadores e
11 DNS Resolver1 e DNS Resolver 2: esses servidores devem ser capazes de resolver
domínios de redes de
zonas de ENUM. Caso não possua servidores capazes de resolver DNS ENUM, repita computadores após a
os endereços dos SRCs 1 e 2; atribuição do Domínio.

11 Domínio: o endereço ao qual o SRL pertence;

11 Timezone: fuso horário que deve ser definido para ser adotado para o SRL.

Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”.

Aba Gerência

Nesta tela, é possível definir comunidades SNMP de Read-Only para gerência do ambiente,
desviar logs para um servidor centralizado e ainda definir um servidor para envio de
e-mails.

No quadro SNMP, configure com sua comunidade e a rede de gerência, caso sua instituição
possua um sistema de gerência de redes. O serviço de monitoramento da RNP já é auto-
maticamente inserido e não fica explícito aqui. Você deve apenas configurar a firewall para
permitir o acesso do servidor da RNP.

O servidor de e-mail permite realizar relay de forma autenticada. Se você tem um relay de
e-mails em sua instituição, configure com esse parâmetro para receber mensagens de alerta
desse módulo do fone.

Você também pode configurar um servidor de syslog. Para desabilitar o relay para um syslog Figura 6.25
externo, forneça o endereço 127.0.0.1. Configurações:
Gerência.
Serviço fone@RNP

130
Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”.

Aba Proxy SIP

Nesta aba são definidas as informações referentes ao SRL atuando como um SIP Proxy, os
endereços IP dos SRCs (SIP Router Centrais), portas de comunicação e prioridades.

Figura 6.26 11 Realm VoIP: colocar o voip REALM da instituição: Exemplo: fone.rnp.br ou voip.ufsc.br
Configurações: ou ufsc.br;
Proxy SIP.
11 IP do SIP Router: endereço IP no qual o SRL vai escutar. Esse endereço deve ser o mesmo
indicado da Aba Sistema, campo IP (figura 6.24);

11 Porta do SIP Router: recomenda-se deixar a padrão: 5060;

11 IP SIP Router Central 1, Porta SIP Router Central 1, IP SIP Router Central 2, Porta SIP
Router Central 2: colocar os endereços e portas dos SRCs, os quais no ambiente da RNP
são: 200.143.193.54:5060 e 200.130.35.113:5060;

11 IP Proxy SIP DNS Srv 1, Prioridade, IP Proxy SIP DNS Srv 2, Prioridade: definição dos
endereços IP e prioridade, que serão utilizados para configurar a zona DNS que respon-
derá pelas configurações de rotas ENUM. Utilizar os endereços IP do SRL1 e do SRL2. As
prioridades devem ser definidas conforme desejar, seguindo padrão de configuração
conforme prioridades do DNS.

Faça a configuração de acordo com seu ambiente e depois clique em “Salvar Configurações”.

Atenção! Clique em “Salvar Configurações”, mas ainda não aplique as configurações.

Nesse momento, devemos configurar o firewall para que não percamos o acesso ao servidor.
Depois voltaremos às próximas abas de configuração.

Aba Firewall

Além de controlar o iptables (acesso na camada 3, de rede), a aba Firewall e sua sessão
Gerência, também são responsáveis por configurar e controlar o acesso a pastas do apache
Capítulo 6 - SIP Router Local (SRL)

(acesso na camada 7, de aplicação).

Deixar de configurar a aba firewall nesse momento poderá comprometer todo o procedimento
de configuração do SRL, pois deixará o usuário sem alternativas para acessá-lo novamente.

No menu superior, clique na opção “Firewall” para acessar suas configurações.

131
Localize a área/sessão “Rede de Gerência”.

Observe na próxima figura que o IP 10.255.255.0 está cadastrado. Ele deve permanecer Figura 6.27
assim até a finalização da configuração, pois permitirá acesso a partir dessa rede caso algo Configurações
de firewall.
saia errado. Você deve removê-la em uma segunda etapa.

Agora inclua as demais redes de onde você poderá realizar a configuração e manutenção Figura 6.28
do SRL. Clique no botão “+” e depois no campo onde deve digitar o IP. Seguindo o exemplo, Firewall: Rede
de gerência.
digite o IP da máquina que fará o acesso ao SRL.

Nesse ponto, já temos as condições suficientes para aplicar as modificações e retomarmos
as configurações na aba “Configurações” e suas sub-abas.

Insira também a porta 8443 TCP com origem no endereço IP 200.143.193.54/32. Esse é o
servidor que busca informações de CDR para o sistema de estatísticas nacionais.
Serviço fone@RNP

Vamos, agora, terminar a configuração do firewall interno para podermos prosseguir e
aplicar todas as configurações realizadas até agora.

Ao incluir todas as redes de onde será possível acessar o SRL, clique no botão “Salvar” e
depois em “Aplicar Configurações”.

132
Agora é hora de aplicar as configurações realizadas até aqui.

Aba Aplicar Configurações

Após configurar o ambiente, é necessário aplicar as configurações do sistema, para que
todas as alterações surtam efeito.

Figura 6.29 11 Configurações de Sistema: quando selecionada, aplica as configurações que foram
Configurações: feitas no que diz respeito ao sistema, como alterações nas guias, Instituições, Sistema e
Aplicar
configurações. Gerência;

11 Configurações de Proxy SIP: quando selecionada, aplica as configurações que foram
l feitas no que diz respeito ao SRL e seus serviços;
O SRL vai aplicar as
primeiras configura- 11 Realizar sincronização LDAP: quando selecionada, realiza a sincronização do LDAP dos
ções escolhidas e dois SRL configurados na instituição.
reiniciar com o novo IP.
Realizar o acesso com Marque as duas caixas de opção “Configurações de Sistema” e “Configurações de Proxy SIP”,
o novo IP após o SRL
e clique no botão “Aplicar configurações selecionadas”.
ter reiniciado e
continuar com a sua
Aparecerá uma tela de confirmação. Selecione o botão “OK” para aceitar a aplicação das
configuração.
configurações.

Figura 6.30 Nesse ponto, a conectividade com o servidor é perdida.
Configurações:
Confirmação para Agora você deve colocar a estação de trabalho (de onde você está acessando o SRL) na rede
Capítulo 6 - SIP Router Local (SRL)

aplicar mudanças. gerência que foi configurada há pouco.

Acesse o novo endereço IP pelo browser. Depois, aceite o certificado autoassinado clicando
em “Entendo os riscos” e “Adicionar exceção...”. Aparecerá uma janela onde você deve clicar
no botão “Confirmar exceção de segurança”.

Entre com o usuário admin e suas credenciais para continuar as configurações.

Observação: esses avisos de segurança são reportados pelo browser devido ao uso do certi-
ficado autoassinado. Não é necessariamente um problema do fone@RNP.

133
Retomando a configuração do servidor, voltemos à aba “Configurações” > “Serviços Habilitados”.

Aba Serviços Habilitados

Para iniciar um serviço, basta clicar em “Selecionar” e, para parar um serviço, clicar em
“Cancelar”.

Figura 6.31
Habilite todos os serviços! Serviços
habilitados.

Atualização

Após ter realizado as configurações iniciais, é necessário realizar a atualização do SRL para
obter a última versão do software desse componente. Para tal, acesse o menu superior
“Atualização” e clique no botão “Atualizar Aplicações” e, em seguida, aceite a atualização
Figura 6.32
clicando no botão “OK”. Atualizações.

Logo após, aparecerá a tela com as configurações aplicadas e uma caixa de texto verde Figura 6.33
informando sobre a necessidade de aplicar as configurações. Confirmação de
atualização.
Serviço fone@RNP

Clique no link “Configurações de Ambiente” destacado nessa caixa de texto. Você será redi-
recionado para a tela de aplicação de configurações.

134
Figura 6.34 Aplique a configuração selecionando as opções “Configurações de Sistema” e “Configurações
Logs de atualização. de Proxy SIP”.

Capítulo 6 - SIP Router Local (SRL)

Figura 6.35
Aplicar Replicação LDAP entre dois SRLs
configurações.
É possível para o fone@RNP funcionar com apenas um SRL por instituição. Entretanto, é
aconselhável ter dois SRLs instalados e funcionando em redundância para aumentar a
disponibilidade do serviço.

Internamente, no SRL existem módulos que operam de forma redundante e outros não.
Os que operam de forma redundante são os que mais sofrem alterações e que precisam
estar sincronizados. Os módulos redundantes são: peers, Rotas e País. Os demais não são
redundantes e operam de forma independente.

135
Para habilitar a replicação dos dados entre os SRLs, é necessário que os dois SRLs estejam
instalados e configurados até o passo 4 do manual de instalação. Uma vez que essa con-
dição tenha sido atendida, prossiga com os passos a seguir.

Faça login no primeiro SRL. Acesse a guia “Configurações”, aba “Gerência”, sessão “Replicação
LDAP” e altere os seguintes parâmetros (figura 6.86):

11 Server ID: preencher com o valor “1” o primeiro SRL;

11 Server Provider: preencher com o endereço IP do segundo SRL;

11 Habilitar Replicação: habilitar campo para realização de replicação.

Logo após ter preenchido os valores, clique no botão “Salvar Configurações”. Figura 6.36
Replicação LDAP –
Depois, vá para a guia “Configurações”, aba “Aplicar Configurações”. Marque “Configurações Servidor 1.
de Sistema”, clique no botão “Aplicar Configurações Selecionadas” e no botão “OK” para
confirmar ação.

Importante: após realizada a aplicação das configurações, devemos entrar na guia “Firewall” Figura 6.37
e clicar em “Aplicar Configurações”, para que as configurações do espelhamento do LDAP Aplicar
configurações.
sejam refletidas nas regras de firewall.

Agora, faça login no segundo SRL. Acesse a guia “Configurações”, aba “Gerência”, sessão
“Replicação LDAP” e altere os seguintes parâmetros (figura 6.89):

11 Server ID: preencher com o valor “2” o segundo SRL;

11 Server Provider: preencher com o endereço IP do primeiro SRL;

11 Habilitar Replicação: habilitar campo para realização de replicação.
Serviço fone@RNP

Figura 6.38
Replicação LDAP:
servidor 2.

136
Logo após ter preenchido os valores, clique no botão “Salvar Configurações”. Depois vá para
a guia “Configurações”, aba “Aplicar Configurações”. Marque “Configurações de Sistema” e
Figura 6.39
Aplicar “Realizar sincronização LDAP”. Clique no botão “Aplicar Configurações Selecionadas” e no
configurações. botão “OK” para confirmar ação.

Figura 6.40 Peers
Confirmação
de mudança na Um peer (ou parceiro) é o equivalente a uma instituição (ou ao equipamento SIP dessa ins-
base LDAP. tituição) que será ligado ao fone@RNP. Um peer pode ser o GWT do fone@RNP, um gateway
de outro fabricante, o PBX-IP (do fone@RNP ou de terceiros) ou outro SRL.

Na guia Peers vamos realizar o gerenciamento dos peers cadastrados no SRL. Nessa tela,
é possível inserir, excluir e alterar um peer. A listagem contida nessa tela possui os peers
cadastrados no SRL.

As informações listadas nessa tela são: sigla, Nome, website, E-mail e Telefone.

Podemos visualizar cinco sessões distintas: filtro de exibição de resultados: 20, 25, 50 etc.,
que significam a quantidade de linhas a serem apresentadas na tabela (1); campo de pes-
quisa dos peers (2); tabela de exibição dos peers (3); botões para cadastro e exclusão de
Capítulo 6 - SIP Router Local (SRL)

peers (4); e botões de paginação da tabela de peers (5).

137
1 2

3
4 5

Cadastro de um novo peer Figura 6.41
Peers.
Para realizar o cadastro de um novo peer, na tela de Peers, clique no botão “Cadastrar”.

Figura 6.42
Botão cadastrar
peer.

Após clicar no botão “Cadastrar”, aparecerá a tela de gerenciamento do peer. Essa tela
contém as seguintes abas com as seguintes informações cadastrais:
Serviço fone@RNP

11 Aba Dados do Peer: dados gerenciais do peer, incluindo compatibilização com o sistema
de estatísticas nacionais do fone@RNP 2008:

22 Sigla [*]: sigla adotada para identificar o peer no SRL, podendo ser a sigla da ins-
tituição de interesse. Atenção: a string “SRL” é uma palavra reservada e não pode
aparecer no campo “Sigla”.

138
22 Nome [*]: nome de identificação do peer;

22 website: website de identificação do peer, podendo ser o website da instituição;

22 Telefone: telefone de contato do peer;

22 E-mail: e-mail de contato do peer;

22 Estatísticas Nacionais [*]: ID da Instituição e DDD Padrão: esses dados são utilizados
para a adequação ao sistema de estatísticas nacionais do fone@RNP 2008. O ID da
instituição identifica uma instituição no sistema de estatísticas, e o DDD Padrão é utili-
zado quando não é possível identificar corretamente o DDD pelo número de origem.

11 Aba Endereço: dados do endereço de contato da instituição para fins de gerenciamento,
sendo que os dados são autodescritivos: CEP, Logradouro, Número, Complemento,
Bairro, Cidade, Estado e País;

11 Aba Responsável: dados sobre o responsável por administrar o peer, contendo os
seguintes dados de cadastro: Nome, Telefone e E-mail;

11 Aba Troncos: dados referentes ao endereçamento IP dos equipamentos do peer e sobre
que tabelas devem ser exportadas para o peer:

22 Status: opção para ativar ou desativar o peer. Quando o peer é desativado, suas rotas
deixam de valer no serviço;

22 Tipo do Peer: define o tipo do peer (origem e destino) que é utilizado na contabilização,
quando não consegue definir qual o tipo de ligação através das marcações do ambiente;

22 Endereço do SIP Proxy [*] [**]: define qual é o endereço do peer, que pode ser um
SIP Proxy ou um gateway. Deve ser preenchido de acordo com o formato: “[ENDEREÇO
IPv4]:[PORTA]”, Exemplo: 10.20.30.40:5071;

22 Endereço dos Servidores DNS [**]: define quais são os servidores que receberão
as tabelas ENUM (local e as centrais – fone@RNP, PBX e PSTN). Para dispositivos do
fone@RNP, repita o endereço IP do peer, mas sem a informação de porta. Deixe em
branco caso o peer não seja um dispositivo do fone@RNP. Esse campo tem o seguinte
formato: “[ENDEREÇO IPv4]”, considerando como porta padrão a do DNS (UDP 53);

22 Completar para: define se o peer vai acessar a tabela local. A princípio, devem-se
selecionar todas as tabelas sem restrições. As tabelas centrais são automaticamente
exportadas conforme os privilégios gerenciados no SRC.

[*] Campos obrigatórios.

[**] Para adicionar o campo, é necessário clicar no botão logo ao lado o do campo corres-
pondente, logo após seu preenchimento. O campo será mostrado na listagem a seguir do
próprio campo. Caso deseje remover um valor associado ao campo que esteja na listagem a
seguir, deve-se selecionar o campo e pressionar o botão ao lado da listagem dos campos.
Capítulo 6 - SIP Router Local (SRL)

139
Figura 6.43
Dados do peer.

Após ter preenchido com os campos obrigatórios e os desejados para questões de gerencia-
mento, deve-se clicar no botão ”Adicionar”. O SRL controla caso tenha algum campo faltando
ser preenchido e retorna uma mensagem de aviso autoexplicativo logo após clicar no botão
“Adicionar”. Caso o peer tenha sido cadastrado com sucesso, aparecerá uma mensagem de
confirmação de cadastro após clicar no botão “Adicionar”.

Figura 6.44
Dados do peer:
Itens obrigatórios.
Serviço fone@RNP

140
Edição de um peer existente

Para editar um peer existente, deve-se mover o mouse em cima de uma das linhas da
listagem de peers cadastrados, até que o cursor do mouse vire uma “mãozinha” e essa linha
fique em tom de cinza. Logo após, dê um clique com o mouse para aparecer sua tela de
edição. Note que essa tela e seus campos são os mesmos já apresentados anteriormente,
alterando o botão “Adicionar” para o botão “Atualizar”. Podemos alterar qualquer campo e
no final pressionar o botão “Atualizar”.

Figura 6.45
Peer pré-existente.

Exclusão de um ou mais peers existentes

Para excluir um ou mais peers, deve-se selecionar os peers desejados para realizar a
exclusão e logo após clicar no botão “Excluir selecionados”. Ao remover os peers, as rotas
cadastradas para para eles também serão removidas. Um aviso é mostrado. Clique em “OK”
para confirmar ou “Cancelar” para não realizar a exclusão dos peers selecionados.

Figura 6.46
Peer pré existente.

Procurando informações sobre os peers cadastrados

Para realizar uma procura dos peers, basta digitar os termos de pesquisa no campo
“Procurar”. O filtro é aplicado conforme são digitados os termos de pesquisa, e a seleção
Figura 6.47
Busca. aparece na planilha a seguir.
Capítulo 6 - SIP Router Local (SRL)

141
Rotas
No contexto do fone@RNP, as rotas estão relacionadas aos números de telefone e o peer
responsável por terminar a ligação telefônica feita para esse determinado número. Por
exemplo, para ligar para +55 21 2102-9600, um dos peers que terminam essa chamada é o
escritório da RNP na cidade do Rio de Janeiro, na tabela de PBX, o que significa que esse é
um número dentro da própria instituição.

Ao clicar na guia Rotas, serão listados os peers previamente cadastrados. Nessa tela, é pos-
sível realizar o gerenciamento das rotas dos peers cadastrados previamente no SRL.

Nesta tela, é possível inserir, excluir e alterar rotas referentes aos peers. As informações
listadas nessa tela são: Sigla, Nome, Website, E-mail e Telefone.

Podemos visualizar 5 sessões distintas: filtro de exibição de resultados: 20, 25, 50 etc. (1);
campos de aplicação das rotas cadastradas e verificação de encaminhamento ENUM (2),
campo de pesquisa das rotas (3); tabela de exibição dos peers (4); e botões de paginação da
tabela de peers (5).

2
1
3

4
5

Para se gerenciar as rotas de cada peer, deve-se mover o mouse para cima de uma das Figura 6.48
linhas da listagem até o peer desejado, quando essa linha fica em tom de cinza. Logo após, Rotas.
Serviço fone@RNP

dê um clique para que abra a tela de gerenciamento de rotas do peer selecionado.

A listagem contida nessa tela possui informações das rotas do peer. As informações listadas
nessa tela são: Código de País, Código de Área, Prefixo inicial, Prefixo final, Prefix, Strip,
Destino, Prioridade e Status.

142
Podemos visualizar 8 sessões distintas: navegação hierárquica indicando em qual peer está
sendo gerenciado as rotas (1); filtro de exibição de resultados: 20, 25, 50, 100, 200 e 500 (2);
campos de aplicação das rotas cadastradas, importação e exportação de rotas (3), campo
de pesquisa das rotas (4); tabela de exibição das rotas do peer selecionado (5); opção para
excluir todas as rotas cadastradas (6); botões de cadastro, exclusão e atualização de rotas (7);
e botões de paginação da tabela de rotas (8).

3
1
2 4

6 5
7 8

Figura 6.49 Cadastro de uma nova rota
Rotas do peer
DEMO. Para realizar o cadastro de uma nova rota, deve-se selecionar um peer na guia Rotas e clicar
no botão “Cadastrar”.

Capítulo 6 - SIP Router Local (SRL)

Figura 6.50
Cadastrar rotas do
peer DEMO.

Após clicar no botão “Cadastrar”, vai aparecer a tela de gerenciamento da rota. Essa tela
contém as seguintes informações cadastrais, que devem ser preenchidas:

143
11 Código de área: define o código de área da determinada rota ou, mais especificamente,
esse campo se refere ao DDD sem o código de nação. Exemplo: Rio de Janeiro: DDD 21;

11 Prefixo inicial e Prefixo final: define o início da faixa e o final da faixa de números de
determinada rota. Os dois campos devem conter o mesmo número de dígitos;

11 Strip: número de dígitos que serão suprimidos do número chamado após a definição da
rota. Exemplo: 554837211000 com strip de 4 fica como 37211000;

11 Prefix: sequência de caracteres alfanuméricos que será incluída após a definição da rota.
Exemplo: 554837211000 com prefix “TESTE” fica como TESTE554837211000;

11 Prioridade: definição de prioridade da rota. Quanto menor o número, mais prioritário.
Para os mesmos números de prioridades, serão chamados os destinos simultaneamente;

11 Proxy SIP: seleção do destino que deve ser encaminhado para essa especificação de
rota. Esse campo é buscado nos endereços do SIP Proxies definidos na aba Troncos do
Guia peers;

11 Protocolo: definição do protocolo para ser usado pela rota (UDP ou TCP). Por padrão,
definir como sendo UDP;

11 País: selecionar o país da rota. Esse campo define o Código do País, o qual é definido na
Guia “País”;

11 Status: opção para ativar ou desativar a rota.

Figura 6.51
Informações
de rota.

Após ter preenchido com os campos, deve-se clicar no botão “Cadastrar”. Caso os campos
“Código de área”, “Prefixo inicial” e “Prefixo final” não estejam preenchidos, o sistema
retorna o erro.

Observe que as rotas são formadas através de faixas numerais que são formadas com os
seguintes campos:

“Código de País + Código de Área + Prefixo inicial”
Serviço fone@RNP

até

“Código de País + Código de Área + Prefixo final”

Exemplo:

144
País: Brasil (implica em “Código de País” = 55)
Código de Área: 48
Prefixo Inicial: 37210000
Prefixo Final: 37219999

A faixa de números será definida pelos telefones:

554837210000 até 554837219999

O sistema está preparado para gerenciar as rotas conflitantes, o qual aponta para os
diversos destinos levando em consideração suas prioridades, independentes de serem ou
não faixas de rotas exatamente iguais.

Edição de uma rota existente

Para editar uma rota existente, mova o mouse para cima de uma das linhas da listagem de
rotas cadastradas até que o cursor do mouse vire uma “mãozinha” e essa linha fique em tom
de cinza. Logo após, dê um clique com o mouse para aparecer sua tela de edição.

Note que essa tela e seus campos são os mesmos dos já apresentados anteriormente,
quando se realiza um cadastro de uma rota nova, alterando o botão “Cadastrar” para o
botão “Salvar”. Podemos alterar qualquer campo e no final pressionar o botão “Salvar”.

Figura 6.52
Informações
de rota.

Exclusão de uma ou mais rotas existentes

Para excluir uma ou mais rotas, deve-se selecionar as rotas desejadas para realizar a
exclusão e logo após clicar no botão “Excluir selecionados”.
Capítulo 6 - SIP Router Local (SRL)

145
Figura 6.53
Excluir rotas do
peer DEMO.

Exclusão de todas as rotas

Para excluir todas as rotas, deve-se clicar no link “Excluir Todas as Rotas”.

Atualização de múltiplas rotas

Para a realização de atualização de vários campos simultaneamente, devem ser selecio-
nados as linhas que a serem atualizadas e, em seguida, clicar no botão “Atualizar selecio-
nados”. vai aparecer a tela com os possíveis campos para serem atualizados. Devemos
alterar os campos desejados e checá-los para definir quais devem ser alterados, conforme
exemplo da figura 6.55. Em seguida, clicar no botão “Salvar”.

Figura 6.54
Excluir todas
as rotas.
Serviço fone@RNP

146
Figura 6.55
Modificação de
rotas de um peer.

Aplicação das alterações de rotas

Logo após serem incluídas, excluídas, alteradas, habilitadas e/ou desabilitadas as rotas e/ou
peers, deve-se aplicar as modificações para que de fato sejam consideradas como válidas.
Para tal, na guia rotas deve-se clicar no botão “Aplicar alterações” e logo em seguida clicar
no botão “Aplicar”, para que sejam aplicadas as alterações feitas.

Figura 6.56
Aplicando
modificações
nas rotas.
Capítulo 6 - SIP Router Local (SRL)

147
Figura 6.57
Resultado da
aplicação de
mudanças.

Procurando informações sobre as rotas cadastradas

Existem duas formas de busca das rotas cadastradas. As duas formas podem ser aplicadas
tanto na tela de visualização da listagem de peers ou na listagem das rotas do peer selecio-
nado. O filtro é aplicado conforme são digitados os termos de pesquisa e a seleção aparece
na planilha a seguir. A diferença da busca é o resultado, todavia a forma de operação é a
mesma.

Na primeira os resultados conterão a listagem dos peers que foram filtrados com os parâ-
metros de busca, e na segunda as rotas de determinado peer.

A primeira forma de busca é a busca por atributo. Essa considera todos os campos da pla-
nilha como campos de filtro, sendo que o campo “Tipo” deve ser definido como “Atributo”.

A segunda forma de busca é a busca de rotas ativas. Essa realiza o filtro dos peers buscando Figura 6.58
como critério de pesquisa uma rota no formato E.164, ou seja, deve-se inserir no campo o Busca por atributo.

número inteiro de busca a partir do código de país. Exemplo: caso deseje-se buscar as insti-
tuições que possuam rotas para o número +55-48-37216335, deve-se selecionar como tipo
de busca a opção “Rotas Ativas” e no campo de busca inserir o valor “554837216335” (Visão
peers e; Visão rotas de determinado peer).
Serviço fone@RNP

Figura 6.59
Busca por rotas
(mostra peer).

148
Figura 6.60 Verificar encaminhamento DNS ENUM
Busca por rotas.
Para verificar o encaminhamento de rotas nas zonas de encaminhamento DNS ENUM,
deve-se clicar no botão “Verificar Encaminhamento” na guia Rotas.

Figura 6.61 Em seguida, deve-se entrar com o número completo no formato E.164, conforme explicado
Verificação do na sessão 6.6, sendo que ao digitar o número de busca o sistema vai realizar o filtro para
encaminhamento
ENUM. verificar em qual zona a rota se encontra cadastrada.

É possível verificar detalhes do registro, clicando no ícone “+” ao lado da zona ENUM. Caso o
status apresente como “OK”, é porque existe rota na zona ENUM; caso apresente como “SEM
ROTA!”, é porque não existe rota ENUM nessa zona.

Figura 6.62
Resultado da
verificação do
encaminhamento.
Capítulo 6 - SIP Router Local (SRL)

149
Exportação/Importação de rotas Figura 6.63
Resultado da
Na guia Rotas, visão Peers, podemos facilmente exportar as rotas clicando no ícone verificação do
“Exportar Rotas”. Vai ser criado um arquivo com todas as rotas do peer. Para poder importar, encaminhamento.

basta clicar no ícone “Importar Rotas”, selecionar o arquivo com as rotas de importação e
clicar em “Enviar”. Caso esteja marcado para “Preencher com valores padrão se o valor não
estiver setado”, os campos que no arquivo não estiverem configurados serão utilizados os
campos preenchidos da interface.

Contabilização
Na guia Contabilização, é possível realizar a contabilização das chamadas que passam pelo
SRL. Essa tela é autoexplicativa, sendo que devem ser selecionados os peers de origem e os
peers de destino, selecionar o intervalo de contabilização desejado e informar o tipo de rela-
tório desejado. O relatório que essa tela gera pode ser no formato em tabela, nas quais as
ligações completadas e não completadas aparecem em linhas de tabelas distintas; pode ser
no formato em matriz, nos quais aparecem os Peers nas linhas e colunas e contêm a quantia
de chamadas e total de tempo das ligações completadas e não completadas em tabelas
distintas; e ainda pode ser no formato de gráficos.
Serviço fone@RNP

Figura 6.64
Contabilização.

150
Figura 6.65
Contabilização –
tabela.

Figura 6.66
Contabilização:
Matriz de tráfego.

Capítulo 6 - SIP Router Local (SRL)

151
Figura 6.67
Contabilização:
Gráficos.

Usuários
Na guia Usuários é onde são gerenciados os usuários do SRL. Nessa guia é possível incluir,
excluir, alterar e visualizar os usuários cadastrados.

Os campos de cadastro dessa guia são os seguintes: Figura 6.68
Usuários.
11 Login: login do usuário para acesso no SRL;

11 Senha: senha do usuário para acesso ao SRL;

11 Nome: nome do usuário por extenso;

11 E-mail: e-mail de contato do usuário;

11 Telefone: telefone de contato do usuário;
Serviço fone@RNP

11 Privilégios: seleção dos módulos e modo de acesso (escrita/leitura ou somente leitura) a
que o usuário terá acesso.

152
Figura 6.69
Edição de usuário.

País
Figura 6.70 Na guia País é possível cadastrar os países que o SRL terá conhecimento para formar as
País. rotas. Nessa guia é possível incluir, excluir, alterar e visualizar os países cadastrados.

Capítulo 6 - SIP Router Local (SRL)

153
Os campos de cadastro dessa guia são os seguintes (figura 6.71):

11 Sigla: sigla do país;

11 Nome: nome do país;

11 Código Nação: código de nação do país de cadastro;

11 Rota Final: expressão regular que define o número em formato E.164 completo que um país
tem, importante para definir corretamente as rotas no SRL. Para adicionar novas expressões,
deve clicar no ícone “+”, e para remover uma expressão deve-se clicar no ícone “-”.

Figura 6.71
Configuração de
um país.

Para testar se a expressão está correta, deve-se entrar com um número completo no
formato E.164 no campo “Teste de Rota” e verificar se está de acordo (verde) com uma das
expressões listadas.

Figura 6.72
Configuração de
um país: Campo de
teste de rota.

Sistema
Atualizações

Na guia Sistema, aba “Atualizações”, é possível realizar a atualização do sistema de forma
semelhante como foi explicado na sessão 5.1.2, destacando que essa funcionalidade foi
movida de abas somente, diferentemente do que estava descrito na sessão citada.
Serviço fone@RNP

154
Figura 6.73 Ações
Atualizar sistema.
Na guia sistema, aba “Ações”, é possível reiniciar ou desligar o SRL, bastando clicar nos
ícones correspondentes a cada ação.

Figura 6.74
Ações. Console
Na guia Console, é possível visualizar os logs do Opensips e do Apache2 (acesso e erros),
Figura 6.75 podendo selecionar filtros através de expressões regulares. Podemos também alterar a taxa
Console. de atualização e número de linhas consideradas para filtro no arquivo especificado.

Capítulo 6 - SIP Router Local (SRL)

155
Backup/Restore
No Fone@RNP distribuição 2012, foi desenvolvida uma ferramenta para criação de arquivos
de backup, ou seja, será possível, após finalizar todas as configurações do SRL ou sempre
que desejado, criar um arquivo de backup.

Essa ferramenta está na aba “Backup” no menu superior.

Além de criar, é possível restaurar a configuração importando as informações de um
arquivo backup.

É importante manter uma cópia de segurança (Backup) das configurações, porque, caso Figura 6.76
aconteça alguma falha de hardware no servidor, ou por algum motivo você tenha de trocá- Backup.

-lo, os dados de configuração de seu ambiente podem ser facilmente restaurados, otimi-
zando o tempo de instalação e configuração.

Crie um arquivo de backup, clicando no botão “Backup do arquivo M4”, e escolha onde vai
guardar o arquivo. Caso seja necessário restaurar as configurações, basta clicar no botão
“Escolher arquivo” e apontar onde o arquivo M4 estaria e em seguida clicar no botão “Enviar”.
Serviço fone@RNP

156
Logs
Na guia Logs é possível verificar os eventos que ocorrem no SRL na questão da adminis-
tração e gerência, podendo verificar detalhes de cada ação.

Figura 6.77
Logs.

Capítulo 6 - SIP Router Local (SRL)

157
Serviço fone@RNP

158
7
PBX IP
objetivos

Estudar o roteiro de instalação, configuração e operação do módulo PBBX IP
do fone@RNP.

conceitos
PBX IP.

Sobre o PBX IP Corporativo
O PBX IP é uma implementação especial de um PABX tradicional, desenvolvido para o
fone@RNP, que procura atender às demandas comuns do serviço de telefonia de uma
grande universidade brasileira. Foi desenvolvido primeiramente pela Universidade Federal
de Santa Catarina (UFSC), para atender às necessidades da UFSC. Quando da solicitação
de incorporação dessa solução ao fone@RNP, foi modificado para se integrar ao serviço e
melhor atender a todos os clientes do fone.

Desenhado para funcionar com outros módulos do fone, o PBX IP tem como pré-requisito
a instalação de um SRL. Além disso, a terminação de ligações na RTFC deve ser feita por um
gateway (idealmente o GWT) configurado como um peer do SRL que controla esse domínio.

O PBX IP deve receber INVITES apenas do SRL diretamente acima. Todas as chamadas feitas
a partir de um PBX IP devem ser encaminhadas para o SRL. Conexões de áudio e vídeo
podem seguir entre o PBX e o SRL, e o PBX e outros dispositivos desse domínio. Como visto
nos parágrafos anteriores, o SRL fica responsável por indicar a rota correta para o número
de telefone desejado.

Há duas versões do PBX IP: uma que se chama corporativa, para atender aos funcionários,
e outra que chamamos acadêmica, para atender aos alunos das universidades. Essa última
versão possui integração com o serviço de Identidade Digital da RNP, a CAFe, Comunidade
Acadêmica Federada. Essa integração permite a implementação de uma característica única
no PABX IP desenvolvido pelo serviço. É a função de autoatendimento, onde o aluno é capaz de
Capítulo 7 - PBX IP

solicitar seu próprio ramal IP em uma página web, sem a intervenção de qualquer funcionário.

O PBX IP também é preferivelmente implementado como uma Máquina Virtual. A RNP utiliza
VMWare, mas é possível implementar em qualquer outro fabricante ou tecnologia de virtua-
lização, embora a RNP não dê suporte para outras VMs.

159
Além disso, o PBX IP é implementado sempre em duplas, para garantir a Alta Disponibilidade
do serviço. Se um servidor parar de responder por qualquer motivo, o outro deve assumir e
o serviço de telefonia não deve parar. Por isso, escolha servidores de virtualização dife-
rentes para instalar os SRLs, de preferência, distantes geograficamente.

É muito importante ressaltar que a RNP não atuará como mantenedora do PABX das
instituições, mesmo se elas optarem por instalar o PABX do fone@RNP.
Nós desenvolvemos a solução e estamos oferecendo-a para uso nas instituições
em conjunto com os outros módulos do serviço fone@RNP. Mas, exatamente como
quando uma instituição escolhe utilizar qualquer outro PABX, seja ele Siemens,
Avaya, Cisco, Leucotron, Intelbras, Asterisk, Elastix, SNEP ou qualquer outro fabri-
cante, é necessário que a instituição contrate uma empresa (ou possua o conheci-
mento internamente) para manter seu PABX funcionando corretamente.

Atualmente, no momento em que este livro está sendo escrito, para realizar o
trabalho de mantenedor do PABX IP do fone@RNP, a RNP conta com a equipe do
PoP-SC, que desenvolveu o PABX, e com a CAM Tecnologia, que nos dá suporte no
fone@RNP

Roteiro de instalação e configuração – PBX IP Corporativo
Instalação do PBX Corporativo
A instalação do módulo PBX-IP Corporativo está disponível na forma de duas imagens de
máquinas virtuais (VM – Virtual Machine. Neste documento, sempre será referenciada como
VM1 para a Máquina Virtual 1 e VM2 para a Máquina Virtual 2), pré-configuradas no formato
OVF (Open Virtualization Format), facilitando assim sua implementação. Para cada VM, será
l
Importante: as duas
necessário um IP Público (portanto, dois endereços) e mais um terceiro endereço IP que será PBX-IP funcionam em
utilizado para a redundância através do Virtual Router Redundancy Protocol (VRRP). modo redundante e
devem estar no mesmo
Estas imagens requerem do sistema hospedeiro: segmento de rede.
Após a importação das
11 Ambiente VMware; VMs, configurar a
primeira interface de
11 35GB de HD; rede de cada VM para a
sub-rede de telefonia e
11 2GB de RAM;
a segunda interface,
11 Duas interfaces de rede, 1 com IP público e 1 interface para conexão direta entre os dois com uma VLAN interna
de comunicação entre
PBX-IP, para realizar procedimentos de redundância;
as duas máquinas.
11 Tamanho do download: 1 GB.

Configuração de DNS
Na configuração do DNS da instituição, devem ser incluídas as entradas das duas máquinas,
mais o IP virtual, e o domínio de provisionamento, o qual será utilizado para configuração
dos telefones IP.
Serviço fone@RNP

A configuração deve ser realizada conforme modelo a seguir, adequando os endereços IP e
nomes conforme cada instituição.

m1.lab IN A 10.10.2.111
m2.lab IN A 10.10.2.112
vrrp.lab IN A 10.10.2.110

160

adm.voip CNAME vrrp.lab
aprov.voip CNAME vrrp.lab

_sip._udp.adm.voip SRV 5 10 5080 vrrp.lab
_sip._udp.adm.voip SRV 10 10 5080 m1.lab
_sip._udp.adm.voip SRV 10 10 5080 m2.lab

Importação das Máquinas Virtuais
As imagens poderão ser importadas diretamente pelo hypervisor, a partir das seguintes URLs:

Link da VM1

http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3-m1/
FoneRNP-PBXIP-v3-m1.ovf

Link da VM2

http://repositorio-fone.rnp.br/fone2012/PBX-IP/VM/release/2.0/FoneRNP-PBXIP-v3-m2/
FoneRNP-PBXIP-v3-m2.ovf

Os demais passos demonstram um procedimento básico de importação através do cliente
VMware vSphere.

Faça o deploy da VM1 utilizando o link da VM1 de acordo com as próximas figuras; depois,
repita o mesmo procedimento para a VM2 utilizando o link da VM2.

Figura 7.1
Deploy ovf
template.
Capítulo 7 - PBX IP

161
Figura 7.2
Arquivo ovf de
origem.
Serviço fone@RNP

Figura 7.3
Detalhes do ovf.

162
Na tela a seguir, é solicita qual será o nome da máquina virtual. Aconselhamos deixar no
formato que virá no arquivo.OVF, como mostra na imagem:

Figura 7.4 Prossiga com a configuração da VM. Para o formato do disco, selecionar “1 – Thick Provision
Nome da Máquina Lazy Zeroed”.
Virtual.

Capítulo 7 - PBX IP

163
Você deve realizar instalação das duas VMs. Assim que terminar a VM1, instale também a VM2. Figura 7.5
Pronto para
Após finalizar a importação das duas VMs, ligue a as duas. Acesse o console, conforme mostra completar.
a próxima figura. Depois, digite os comandos que serão apresentados na próxima sessão.
Serviço fone@RNP

164
Figura 7.6
Tela de login do
PBX IP.

Realize o sincronismo das bases MySQL da PBX-IP
Nessa versão do PABX IP, foi identificado um bug no sincronismo do banco de dados das duas
máquinas virtuais. Os próximos passos ajudam a recuperar o sincronismo entre as máquinas.

bug já foi corrigido na próxima versão do PABX IP do fone@RNP.

Login

Feito o deploy das duas VMs, inicie-as, acesse a console da PBX-IP da VM1 e execute os
passos a seguir. Depois, repita os mesmos passos para a VM2.

Login: root
Password: pbxip.root

Conectividade

O primeiro passo é verificar se há conectividade entre as VMs.

Cada PBX possui uma segunda interface de rede especificamente para o sincronismo do
mysql.

É necessário que essas interfaces se alcancem uma a outra. Teste utilizando “ping”.

Após essa verificação, execute os passos a seguir.

Sincronismo
Capítulo 7 - PBX IP

pbxip-m1# mysql -p
Enter Password: mysql.admin
mysql> stop slave;
Query OK, 0 rows affected (0.02 sec)
mysql> reset slave;

165
Query OK, 0 rows affected (0.04 sec)
mysql> start slave;
Query OK, 0 rows affected (0.06 sec)
mysql> show slave status\G

Após a execução do último comando acima, a saída deve ser semelhante ao texto a seguir:

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.0.2.2
Master_User: replicant
Master_Port: 3306
....

Agora execute:

mysql> exit
pbxip-m1# exit

Lembre-se: execute esse procedimento nas duas máquinas.

Quando entrar na interface gráfica (alguns passos mais adiante), antes de iniciar a configu-
ração do PBX IP, lembre-se de verificar se as duas máquinas estão sincronizadas. Caso não
estejam, aguarde alguns minutos e verifique novamente.

Figura 7.7
Status da replicação
do banco de dados
(mysql).

Se for necessário, repita o procedimento de sincronismo nas duas VMs.

Acessando e configurando
Configurando uma estação para acessar o PBX IP
Para ilustrar esse guia, foi utilizado o Sistema Operacional Windows 7. Caso você esteja
utilizando outra versão do Windows ou mesmo outro Sistema Operacional, será necessário
adequar as instruções à sua estação de trabalho.
Serviço fone@RNP

A seguir, seguem os passos a serem executados. Os passos seguintes serão executados para
a VM1. Depois, basta executar os mesmos procedimentos para a VM2.

166
Como mostrado na figura do console, o PBX-IP vem pré-configurado na VM1 com o
endereço IP 10.255.255.20. As demais interfaces de rede seguem na sequência. IP VM 2:
10.255.255.21, IP da VRRP: 10.255.255.22.

Para acessar o servidor de outra máquina, coloque-a no mesmo segmento de rede do ser-
vidor, por exemplo: 10.255.255.5.
Figura 7.8
Central de Clique no botão “Iniciar”, depois em “Painel de Controle”, então em “Central de Rede e
compartilhamento. Compartilhamento” e, do lado esquerdo, escolha, “Alterar as configurações do adaptador”:

Aparecerá a tela conforme imagem da figura 7.9:

Capítulo 7 - PBX IP

Figura 7.9 Depois, clique com o botão direito no ícone da placa de rede do computador e escolha a
Conexões de rede. opção “Propriedades”:

167
Nesse momento, será feita a inserção do IP da máquina no mesmo segmento de rede da Figura 7.10
PBX-IP, para ser iniciado o acesso. Conexão local.

Dê um clique duplo em “Protocolo TCP/IP Versão 4”, conforme selecionado na próxima figura.
Serviço fone@RNP

Figura 7.11
Propriedades de
conexão local.

168
Selecione a opção “Usar o seguinte endereço IP:” e digite o IP exemplo 10.255.255.5. Depois,
clique no botão “OK”.

Figura 7.12
Propriedades de
protocolo TCP/IP v4.

Para testar, execute um comando através do prompt de comando. Clique no botão “Iniciar”.
No campo destinado a “Pesquisar programas e arquivos” clique e digite CMD e tecle “ENTER”.

Na tela do prompt digite: “ping 10.255.255.20”, tecle “ENTER” e o resultado deve ser exata-
mente como o da figura 7.13.

Capítulo 7 - PBX IP

Figura 7.13 Feche a tela do prompt e abra o navegador de sua preferência, digitando o endereço
Prompt de https://10.255.255.20/PBX-IP.
comando: ping.

169
A máquina a partir da qual o acesso está sendo feito deve estar na mesma LAN das
máquinas que serão acessadas.

Para esse guia, utilizamos o Chrome.

Os componentes do fone@2012 utilizam certificados autoassinados para não deixar que Figura 7.14
informações de administração e configuração trafeguem em texto plano pela rede. Primeiro acesso à
interface gráfica
Clique em “Entendo os riscos”, caso apareça essa mensagem, e depois clique em “Continuar do PBX IP.

mesmo assim”.

Configurando o PBX-IP Corporativo
Serviço fone@RNP

Figura 7.15
Login.

170
Digite os seguintes dados para o primeiro acesso:

11 Usuário: admin

11 Password: pbxip.admin

Após o primeiro acesso, troque a senha de administrador imediatamente.

No canto superior direito, clique em “Sistema”, depois em “Administradores”. Edite o admi-
nistrador padrão e certifique-se de utilizar uma senha forte!

Após efetuar o login, será exibida a tela de status ou visão geral do ambiente representada
na próxima figura.

Figura 7.16 Nesta tela, é possível verificar:
Status.
11 Status dos serviços;

11 Estatísticas da central;

11 Status do ambiente;

11 Status de replicação do banco de dados;

11 Status administrativo e operacional dos servidores master (VM1) e slave (VM2).
Capítulo 7 - PBX IP

171
Caso o sincronismo não tenha sido realizado com sucesso, repita o procedimento de sincro-
nização do mysql informado anteriormente, no início deste capítulo.
l
Observação: a
No canto superior direito, é informado o nome do usuário que está logado, e há a opção sincronização entre o
máster (VM1) e o slave
“Sair”. Ainda nessa posição, é possível alternar entre as opções de configuração e gerência (VM2) pode demorar
do Sistema e da Central PBX-IP. alguns minutos; por
isso, os serviços podem
À esquerda da tela, há um menu com opções para administração e controle de funcionali- aparecer como
desabilitados (ícone
dades, além de serviços relacionados aos ramais que serão gerenciados pelo ambiente.
vermelho) por algum
tempo.
Administradores

Nesta opção, é possível fazer o gerenciamento dos administradores do ambiente PBX-IP,
cadastrando usuários e definindo permissões de acesso.

Para o cadastro de um usuário, é necessário informar os dados de login, nome, e-mail
e unidade à qual o usuário é vinculado. Além disso, devem ser marcadas as opções de
módulos e acessos que o usuário poderá visualizar e/ou modificar no sistema. Os módulos
que não forem selecionados na criação de um usuário não serão visíveis a ele na aba
“Central” da PBX-IP quando esse usuário estiver logado. É possível marcar os acessos como
somente leitura, nos quais o usuário não poderá fazer alterações. Para dar permissão total,
basta deixar a opção “Somente Leitura” desmarcada.
Serviço fone@RNP

Logs Figura 7.17
Cadastrar
Todo o histórico de ações do usuário da PBX-IP fica registrado no log do ambiente, permi- administrador.
tindo identificar quais operações foram executadas por ele, quando e a partir de qual IP esse
acesso foi feito.

172
Ao clicar sobre uma das linhas de registro de log, é aberta uma aba a seguir do registro,
detalhando as modificações realizadas por aquela operação. Assim, rastrear operações
indevidas ou incorretas de modo a fazer as correções necessárias. É possível filtrar os resul-
tados do log por data, por usuário, por IP de origem do acesso ou até mesmo por tipo de
ação executada.

Figura 7.18 Menu Configurações
Logs do sistema.
No cabeçalho, à direita, clique em “Sistema”.

Firewall

O início da configuração da PBX-IP será pelo Firewall, pois vamos precisar inserir o IP da
máquina que fará a gerência do PBX-IP. Se fizermos alguma alteração de IP antes de configu-
rarmos a gerência, poderemos perder o acesso ao PBX-IP.

No cabeçalho, à direita, clique em “Sistema”. No menu à esquerda, clique em “Firewall”.

Deverão ser liberados também os endereços NTP, DNS, Estatísticas do fone, monitoramento etc.

Na opção “Ações” serão fornecidos os endereços IP que poderão enviar mensagens SIP ao
GWT (no caso SRC ou SRL). Se o ambiente estiver conectado ao SRL, somente esses IPs são
necessários.

Após configurar o firewall revisando os parâmetros de sua instituição, clique em “Salvar” e
depois em “Aplicar”.

A aplicação de regras de firewall pode demorar alguns minutos caso haja algum problema
Capítulo 7 - PBX IP

com a resolução de nomes.

173
Figura 7.19
Configuração
de firewall.
Serviço fone@RNP

Figura 7.20
Configuração > Sistema Firewall: Ações e
Rede de gerência.

174
Guia Instituição

Ainda na sessão “Sistema”, no menu à esquerda, clique também em “Sistema”. Depois,
acesse a aba “Instituição”.

Nesse item são registradas informações sobre a instituição. Essas informações são utili-
zadas para diversos processos internos, algumas são somente para registro e outras são
utilizadas para gerar o certificado autoassinado para acesso nas telas administrativas.
Os seguintes dados devem ser preenchidos:

11 Nome da Instituição: nome completo da instituição;

11 Sigla: sigla corresponde à instituição em que está sendo instalada a PBX-IP;

11 Campus: campus ou unidade corresponde à instituição em que está sendo instalada
a PBX-IP;

11 Nome do responsável para contato: nome da pessoa que ficará responsável pelo
serviço na instituição;

11 E-mail para contato: correio eletrônico de contato do responsável;

11 Telefone para contato: telefone de contato do responsável; preferencialmente, telefone
móvel;

11 CEP: Código de Endereçamento Postal;

11 Endereço, Bairro, Cidade, Estado, País: informações de endereço postal da instituição;

11 CNPJ: número correspondente ao Cadastro Nacional da Pessoa Jurídica da instituição;

11 website: site web da instituição.

Após realizar o preenchimento dos dados da instituição, não se esquecer de salvar.

Figura 7.21 Sistema
Configurações do
Capítulo 7 - PBX IP

sistema: Instituição. Nesta aba, é feita a parametrização das configurações do sistema, devendo ser preenchidos
os seguintes campos:

11 IP: aqui é inserido o endereço IP que será destinado a PBX-IP Administrativa. Este IP deve ser
público! Após a configuração do IP, deve ser alterada a VLAN da VM para acessar a máquina;

11 Máscara: máscara de rede do IP;

175
11 Gateway: É o endereço IP do gateway da instituição;

11 MTU: Tamanho máximo da MTU no segmento LAN, padrão: 1500;

11 Hostname: Nome do servidor no domínio;

11 NTP1 e NTP2: utilizar os servidores NTP da instituição. Caso não possua, utilizar: pool.
ntp.br e ntp.cais.rnp.br;

11 DNS Resolver1 e DNS Resolver2: caso a instituição possua servidor de DNS, ou tenha
algum que deseje apontar, inserir nesses campos. Esses DNSs devem ser capazes de
resolver zonas de ENUM;

11 Domínio: o endereço ao qual a PBX-IP pertence;
Figura 7.22
11 TimeZone: selecionar de acordo com o Timezone de sua região. A entrada e saída do
Configurações do
horário de verão é realizada automaticamente. sistema: Sistema.

Gerência
l
Na aba Gerência, é possível parametrizar as informações de acesso SNMP/RO, Syslog, SMTP Importante: no
e Acesso WEB da interface administrativa da PBX-IP. “Hostname”, a
padronização adotada
para o FONE@2012 é
11 SNMP:
“PBXIP-adm-sigla da
22 Comunidade: Comunidade SNMP somente leitura; instituição”,
Exemplo:Exemplo:: rNP
22 Rede de Gerência: rede de gerência para onde a comunidade de leitura terá acesso. / Brasília, será,
“PBXIP-DF-RNP”. No
11 SYSLOG:
“Hostname” não
22 IP: Endereço IP do servidor syslog de sua instituição; utilizar: “_” “;” “.” Ou
outro caractere que
22 Porta: Porta onde o servidor estará escutando (Padrão: 514); possa quebrar na
formação do FDQN
22 Protocolo: Protocolo de transporte, atualmente suportado TCP e UDP (Padrão: UDP); (fully qualified domain
Serviço fone@RNP

22 Syslog: para desabilitar o envio remoto via syslog, apontar para o IP 127.0.0.1. name).

11 SMTP

22 Servidor SMTP: nome ou endereço IP do servidor SMTP responsável por encaminhar
os e-mails da PBX-IP Administrativa;

176
22 Porta do servidor SMTP: porta do servidor SMTP utilizada para receber os e-mails.

l Exemplo: 25, 465;

22 E-mail de origem: e-mail utilizado para compor as mensagens;
Acesso WWW: liberar
somente para a rede de 22 Autenticação SMTP: marcar caso o serviço de e-mail requeira autenticação:
gerência da instituição
ou equipe de suporte 22 Usuário: usuário utilizado para autenticação de envio;
RNP. Acesso WebSer-
vice: o método atual de 22 Senha: senha do usuário para autenticação.
autenticação é através
11 Acesso WEB: define a partir de quais redes é possível acessar as interfaces administra-
do IP de origem.
Somente liberar para o tivas e de WebService:
IP de sua aplicação
22 WWW [1 – 5]: Redes onde as interfaces administrativas poderão ser acessadas, isto é,
caso deseje interagir
com a PBX-IP. Para /PBX-IP/;
desabilitar, deixar em
22 WebService: rede ou Host de onde o WebService da PBX-IP para criação de ramais
branco.
poderá ser acionado.

Figura 7.23 11 Acesso Provisionamento: define a partir de quais redes os telefones IP podem acessar o
Configurações do servidor de provisionamento para buscar configurações:
sistema: Gerência.
22 Domínio Aprovisionamento: nome do servidor de provisionamento. Exemplo: prov.
voip.instiuição;

22 Redes: devem ser incluídas as redes nas quais há telefones IP que precisam acessar
Capítulo 7 - PBX IP

o servidor de provisionamento. Podem ser incluídas até cinco redes diferentes.
Exemplo: x.X.0.0/16.

11 Catálogo Telefônico: define a visibilidade do catálogo telefônico, delimitando qual é o escopo
de rede da instituição. Os acessos ao catálogo a partir de IPs que casem com o definido
poderão visualizar todas as informações do ramal/usuário. Já os acessos de redes externas,
não vão visualizar alguns ramais/usuário, nem os nomes de contatos e responsáveis;

177
22 Rede Interna: segue o padrão de expressão regular /^10.10./ para definir qual é a rede
interna da instituição;
Figura 7.24
22 E-mail: e-mail para o qual serão enviadas notificações de alterações de erros no catálogo. Aprovisionamento.

Proxy SIP
lImportante: para que o
Nesta aba configuramos o PBX IP como um cliente SIP do fone@RNP. REALM funcione, será
necessário criar as
11 PBX: VoIP REALM-REALM que será utilizado para atender ao serviço VoIP. Exemplo: voip. entradas DNS SRV
instituicao.br; apontando para a
PBX-IP, informando em
11 OpenSIPs: porta onde o SIPProxy (OpenSIPS) vai atender requisições. Padrão: 5080; qual porta o proxy vai
trabalhar. Portas
11 OpenSIPs: nível de Debug: nível de log que será gerado pelo OpenSIPs. Escolha entre
SIPProxy e Mídia
0 e 7. Recomenda-se utilizar 1; Server: recomenda-se
evitar o uso da porta
11 Midia Server: porta UDP onde o Asterisk responsável por executar funções de Servidor
5060 para utilizar
de Mídia vai atender requisições (padrão: 5071). Não pode ser a mesma do OpenSIPs. dispositivos SIP, pois é a
O Acesso dessa porta somente será realizado pelo OpenSIPs. maior fonte de
incidentes de scans
11 VRRP/UCARP: IP virtual para implementação de failover entre o servidor Master e o Slave. devido ao seu interesse
comercial.
Serviço fone@RNP

Figura 7.25
Configurações do
178
sistema: Proxy SIP.
SIP Router

Configuração dos parâmetros do SIP Router Local (SRL) da instituição que será utilizado
pelo ambiente:

11 IP Master: endereço IP do SipRouter Local (SRL) de sua instituição (Máquina 1);

11 Porta Master: porta do SipRouter Local (Máquina 1). Padrão: 5060;

Figura 7.26 11 IP Slave: endereço IP do SipRouter Local (SRL) de sua instituição (Máquina 2);
Configurações do
sistema: SIP Router. 11 Porta Slave: porta do SipRouter Local (Máquina 2). Padrão: 5060;

TDM

l Parâmetros de telefonia convencional:
AImportante: a PBX-IP
somente aceita cnvites 11 Código de País: código do País/CN: para o Brasil utilizar 55;
de chamadas (INVITES)
11 DDD: código DDD da instituição;
de peers válidos (SIP
Router Locais) ou 11 Prefixo: prefixo TDM da instituição;
usuários autenticados.
INVITES não autenti- 11 Código da Operadora: código da operadora de longa distância. Exemplo: Embratel 21;
cados ou de fontes
11 Linha Externa: código extra para acesso alinha externa. Exemplo: 0;
desconhecidas são
negados. O SRL 11 Ramal PBXIP Inicial: ramal inicial no prefixo TDM que será atendido por essa PBX-IP;
somente aceita INVITES
dos peers válidos. O 11 Ramal PBXIP Final: ramal final no prefixo TDM que será atendido por essa PBX-IP;
uso da porta 5060
11 Ramal Padrão de Saída: ramal no prefixo TDM utilizado para completar ligações através
pode ser utilizado sem
grade impacto na da URA da PBX-IP.
segurança. Para saber
como configurar um Parâmetros de VoIP: numeração Interna do Fone@RNP.
peer no SRL, consultar
o Guia de Implemen- 11 Prefixo: prefixo fornecido pela RNP para uso interno da instituição. Exemplo: 1XXX;
tação do SRL – FONE@
11 Ramal Inicial: ramal inicial no prefixo VoIP que será atendido por essa PBX-IP;
RNP Versão 2012.
11 Ramal Final: ramal final no prefixo VoIP que será atendido por essa PBX-IP.
Capítulo 7 - PBX IP

179
Serviços Figura 7.27
Configurações do
Os serviços disponíveis nessa opção podem ser habilitados/desabilitados clicando sobre o sistema: TDM.
serviço desejado.

Aplicar Figura 7.28
Configurações do
Modificações feitas na configuração do sistema devem ser aplicadas para ter efeito. Basta sistema: Serviços.
selecionar os itens onde as configurações devem ser aplicadas. Normalmente, selecionam-se
os três itens: sistema, OpenSips e Asterisk. Em seguida, clicar em “Aplicar” e “Aguardar”.
Serviço fone@RNP

Figura 7.29
Configurações do
sistema: Aplicar.

180
Permissões de Discagem

Os tipos de chamadas permitidas pelo ambiente são mapeados através de expressões regu-
lares, definidas nesta sessão. Esses tipos são os perfis que permitem a cada usuário realizar
(ou não) ligações para determinados tipos de telefones. A combinação das chamadas efetu-
adas com as expressões definidas é utilizada para geração de relatórios, contabilização de
custos (para chamadas tarifadas) e geração de faturas, bem como a identificação dos tipos
de chamadas autorizadas na configuração individual de cada usuário.

Existe um campo para teste de número destino, no qual é possível testar com quais regras
um determinado número destino casa.

Figura 7.30 Plano de Discagem
Permissões de
discagem. Define como os números discados pelos usuários serão encaminhados para o próximo
módulo do fone@RNP. Em outras palavras, define regras de reescrita.

11 Descrição: id/nome da regra sendo criada;

11 Prefixo: definido de acordo com a regra

11 Expressão: expressão regular que case com a discagem feita pelo usuário;

11 Strip: quantidade de dígitos à esquerda do número que devem ser removidos na reescrita;

11 Ativo: Ativar/Desativar regra. Capítulo 7 - PBX IP

181
Faixa de Valores Figura 7.31
Plano de discagem.
Utilizada para geração de faturas e contabilização de custos de ligações, dependendo do
tipo e horário.

Essas informações são utilizadas também para desconto de créditos de usuários. Deve ser
informados para cada tipo de ligação qual o valor por minuto. Podem ser incluídas faixas de
horário diferentes para cada tipo de ligação, caso a tarifação pela operadora seja feita dessa
forma. Para adicionar outra faixa de horário, basta clicar no ícone “+”. Ao concluir a configu-
ração, clicar em “Atualizar” no final da página.
Serviço fone@RNP

182
Figura 7.32
Faixa de valores.

Backup

É possível fazer o download ou upload de arquivo com as configurações de sistema.

Para fazer o download do arquivo de backup, basta clicar em “Backup do arquivo M4”.

Para fazer o upload do arquivo, basta clicar em “Selecionar Arquivo”. Em seguida, clicar
em “Enviar”.

Capítulo 7 - PBX IP

Figura 7.33 Atualização
Backup.
Quando estiver na opção sistema e clicar no menu “Atualização”, caso haja alguma a ser
feita, vai aparecer conforme imagem a seguir:

183
Caso não haja atualizações a fazer, será informado que o sistema já está atualizado. Figura 7.34
Atualizações.

Acesso Provisionamento Figura 7.35
Sistema atualizado.
Permite cadastrar um par de usuário e senha que serão utilizados pelos telefones IP para se
autenticar no servidor de provisionamento e assim ter acesso aos arquivos de configuração.

Figura 7.36
Provisionamento:
Cadastro de acesso.

Central – gerência de usuários e ramais
Serviço fone@RNP

Após a instalação e configuração do PABX como um dispositivo de rede e com os parâmetros
globais de telefonia, é hora de configurar os ramais, departamentos, custos, perfis, usuários,
grupos de captura etc. Enfim, é hora de popular o PABX.

184
A melhor forma de popular seu PABX é começar preenchendo os dados da sua instituição.
Isso é feito na Guia “Organização”, no menu lateral esquerdo. Primeiro preencha os dados das
unidades atendidas por esse PABX. Depois, preencha os departamentos de cada unidade.

Depois, partimos para a configuração dos ramais. Nessa etapa, os ramais ainda não serão asso-
ciados a uma pessoa. Nesse momento, eles serão associados aos departamentos e unidades.

Primeiramente, devemos criar os “prefixos” que serão atendidos por esse PABX. Logo
depois, devem ser cadastradas as faixas de números DDR de cada prefixo. Você pode dividir
sua faixa DDR em sub-faixas para, por exemplo, distribuí-las por diferentes departamentos.

Se houver centrais legadas em sua solução, agora é a hora de cadastrar os prefixos e faixas DDR
que elas serão responsáveis em atender. Finalmente, no menu “Ramais” > “Gerenciar”, você
poderá cadastrar cada ramal de sua instituição, já sob a estrutura organizada anteriormente.

Por fim, é hora de associar usuários aos ramais cadastrados. Vá em “usuários SIP” > “Gerenciar”
e crie seus usuários de acordo com os funcionários. Nesse momento, os usuários serão
associados aos números de telefones (ramais) e seus departamentos, são descritos os perfis
com permissões de ligação, quantidade de créditos e outros parâmetros ligados à pessoa
que utilizará esse recurso.

Usuários SIP
Gerenciar

Nesse menu, é possível consultar a lista de usuários cadastrados, bem como cadastrar novos
usuários no sistema. Na lista de usuários, a coluna SO (Status Operacional) contém um ícone
que fica na cor cinza quando o usuário não está registrado e verde, quando o usuário está
registrado. Já a coluna SA (Status Administrativo) indica os seguintes estados de ramal:

11 Verde: ativo;

11 Amarelo: em manutenção;

11 Vermelho: inativo/Bloqueado.

Figura 7.37 Apenas o status ativo (verde) permite que o usuário possa efetuar e receber chamadas.
Usuários SIP. Quando o usuário estiver em manutenção ou bloqueado, não poderá efetuar nem receber
chamadas. Para alternar entre os estados do ramal, basta clicar sobre o ícone da coluna SA
do usuário desejado, que mudará de cor indicando o novo estado do usuário.

É possível exibir toda a lista, bem como fazer buscas específicas por usuários ou por dados
de outras colunas, como departamento, local etc. A ordenação padrão da lista de resultados
é feita por ordem alfabética de usuário, mas também pode ser feita clicando sobre o nome
Capítulo 7 - PBX IP

da coluna de acordo com a qual os resultados devem ser ordenados.

185
Ao clicar sobre o nome do usuário na lista, uma aba é aberta a seguir do mesmo, indicando
algumas informações e dados. É possível ver o número dos ramais associados ao usuário,
endereço IP, caso ele esteja registrado, histórico de endereços IP nos quais o usuário já se
registrou, versão de firmware, modelo e MAC do telefone IP do usuário, com as respectivas
datas e horários.

É possível também reiniciar o telefone IP do usuário, utilizando o ícone “Reiniciar” ao lado do Figura 7.38
último registro de IP ou através de “Reiniciar Telefone”. Informações de
cadastro.
Serviço fone@RNP

Figura 7.39
Reiniciar cadastro.

186
Cadastrar Usuário

Ao clicar na opção “Cadastrar Usuário”, uma nova tela será aberta, conforme a próxima figura:

Figura 7.40 Nesse formulário, as seguintes informações devem ser preenchidas:
Cadastrar usuário.
11 Nome completo do usuário;

11 Login para registro;

11 E-mail do usuário: receberá os dados do cadastro, faturas etc.;

11 Senha registro: é a senha que será utilizada para registrar o login do usuário. Ao clicar no
ícone , é feita a geração automática de uma senha para registro. Por default, a senha de
registro não é informada ao usuário. Caso deseje enviar a senha para o e-mail cadastrado
do usuário, basta clicar no ícone;

11 Senha web: senha para acesso ao Portal do Usuário. Pode ser gerada automaticamente
clicando-se no ícone. Essa senha sempre será enviada para o e-mail cadastrado do usuário;

11 Local: onde o usuário será registrado, bem como sua Unidade e Departamento;

11 Captura direta: permite ao usuário fazer captura de chamadas, quando ativada, direta-
mente de outro usuário específico;

11 Grupo de captura: informará o id do grupo de captura, caso o usuário seja membro de
algum grupo;

11 Permissão IP: por default o usuário pode ser registrado em qualquer IP. Para limitar o
acesso, é possível permitir que o usuário registre-se apenas em IPs da instituição. Para
Capítulo 7 - PBX IP

isso, basta selecionar “Limitar” e informar a expressão regular da rede autorizada no
campo IP. Exemplo: ^200\.135\..;

11 Sistema de créditos: permite ligações tarifadas ilimitadas, caso esteja inativo, ou restringe
ao valor de créditos do usuário, caso esteja ativo.

187
11 Créditos (Tipo Recarga):

22 Sem substituição: o usuário poderá utilizar apenas o valor de crédito disponível no
campo “Créditos Atuais”, mas não será feita recarga mensal, mesmo que haja valor
preenchido no campo “Crédito Recarga”;

22 Com substituição: o valor no campo “Créditos Atuais”, é substituído mensalmente
pelo valor fixo contido no campo Crédito Recarga, independentemente de o valor de
Créditos Atuais possuir saldo ou não;

22 Incremental: o valor fixo no campo Crédito Recarga é somado ao saldo do campo
Créditos Atuais, que ficará com o valor acumulado de créditos.

11 Ramais Associados: define quais ramais estão associados ao usuário. É necessário
informar pelo menos um ramal. Caso haja mais de um ramal associado a um usuário, é
necessário selecionar o ramal que será Default, isto é, o número de telefone que permi- l
tirá ao usuário efetuar e receber chamadas. A inclusão/exclusão de ramais associados Editar Usuário: para
pode ser feita utilizando os ícones “+” e “-”; alterar as configurações
e os dados de um
11 Permissões: indicam os privilégios de ligações que o usuário possui; usuário, basta clicar no
ícone do lápis na linha
11 Ativar sistema de bloqueio: ao marcar essa opção, deverá ser informada uma senha do usuário desejado.
de 6 números que será solicitada ao usuário toda vez que for realizada uma chamada Após fazer as modifica-
ções desejadas, é
dos tipos indicados com o ícone do cadeado fechado. Os tipos de permissão que estejam
necessário clicar em
com o ícone do cadeado aberto indicam que para esse tipo de ligação não será solicitada “Alterar” para salvar as
a senha, mesmo que o sistema de bloqueio esteja ativado. Para abrir/fechar o cadeado, novas configurações.
basta clicar sobre o ícone.

Ramais
Gerenciar

Nesta sessão, é possível ver a lista dos ramais cadastrados, bem como fazer buscas, novos Figura 7.41
cadastros e editar ramais já cadastrados. Ramais.

É possível gerenciar tanto ramais IP, que são indicados pelo ícone do telefone digital na
coluna “Tipo”, quanto ramais convencionais (analógicos ou digitais), identificados pelo ícone
Serviço fone@RNP

do telefone analógico.

A coluna “Usuários” indica quantos IDs de usuários estão associados a cada ramal.

É possível fazer busca por número de ramal, ou por dados de localização (unidade, departa-
mento e local), bem como por nome de central telefônica, para ramais convencionais.

188
Para editar dados de ramais já cadastrados, basta clicar no ícone do lápis e, após fazer as
alterações desejadas, clicar em ‘alterar’ para salvar as novas configurações.

Cadastrar Ramal

Os dados informados no cadastro do ramal são os dados que vão constar na página do
catálogo telefônico, independente dos dados de localização cadastrados nos usuários asso-
ciados. Os seguintes itens devem ser preenchidos no formulário:

11 Tipo de Ramal: define o ramal sendo cadastrado. Atualmente somente o cadastro de
ramal IP é suportado;

11 Unidade/Departamento/Local: os dados preenchidos nesses campos são os que serão
exibidos no catálogo telefônico;

11 Ramal: número do ramal com 4 dígitos;

11 Prefixo: tronco/prefixo com a operadora;

11 Páginas amarelas: define a visibilidade do ramal no catálogo:

22 Público: será exibido no catálogo disponível para toda a internet;

22 Somente Interno: será exibido somente quando a consulta ao catálogo for feita
dentro da rede da instituição;

22 Não exibir: o ramal não será exibido nem dentro nem fora da instituição.

11 Contatos do Ramal: podem ser incluídos nomes de usuários do ramal, além do respon-
sável, que é o usuário associado. Para incluir mais de um nome, basta clicar no ícone;

11 Serviços: serviços disponíveis apenas para ramais IP:

22 Modo Fax: todas as chamadas recebidas pelo ramal receberão tom de fax;

22 Modo Fax Temporário: apenas a próxima chamada após a habilitação desse campo
receberá tom de fax e as demais serão tratadas como chamadas de voz;

22 Siga-me contínuo: todas as chamadas serão encaminhadas para o ramal preenchido
nesse campo;

22 Correio de voz – Secretária Eletrônica: habilita as chamadas não atendidas a serem
enviadas para a caixa postal do ramal, acessível com a senha preenchida nesse item;

22 Correio de voz – Anexar recado para o e-mail: as chamadas encaminhadas para o
correio de voz serão enviadas por e-mail para o usuário responsável, no formato de
arquivo de áudio;

22 Correio de voz – Secretária Eletrônica: as chamadas encaminhadas para a caixa
postal ficarão disponíveis para acesso apenas através do ramal, sem o envio de e-mail.
Capítulo 7 - PBX IP

189
Figura 7.42
Cadastrar ramal.

Prefixos

Definem os troncos com a operadora que a instituição possui, indicando os prefixos aos
quais serão atribuídos ramais.

Para o cadastro de prefixo, deverão ser informados:

11 Código do País (2 dígitos);

11 Código DDD do prefixo (2 dígitos);

11 Prefixo (4 dígitos);

11 Descrição: informações opcionais.
Serviço fone@RNP

Figura 7.43
Prefixos.

190
Faixas

Permite definir faixas de ramais para unidades específicas. Ao fazer um cadastro de ramal,
após selecionar uma unidade cadastrada com uma faixa de ramais, basta clicar nos ícones
das setas para esquerda e direita para que o sistema selecione automaticamente o primeiro
ou o último ramal disponível na faixa reservada para a unidade, respectivamente.

Ao fazer o cadastro de uma faixa, é necessário informar:

11 Tipo de Faixa: normalmente, Ramais IP;

11 Prefixo: prefixo dos ramais da faixa;

11 Início/Fim da Faixa: o ramal inicial e final da faixa;

11 Descrição: informações opcionais;

11 Unidade Preferencial: se nenhuma unidade preferencial for escolhida, os ramais perten-
centes à faixa poderão ser atribuídos a qualquer unidade. Se uma unidade for selecionada
como preferencial, os ramais da faixa somente poderão ser atribuídos a essa unidade.

Figura 7.44
Faixas.

Provisionamento

No provisionamento, é feita a configuração de telefones IP com ramais/usuários cadas-
trados no ambiente, bem como fazer o controle patrimonial dos aparelhos de telefone IP.

É possível consultar MACs de telefones IP cadastrados, códigos de tombamento patrimonial,
modelos de telefones IP e usuários, bem como alterar o arquivo.cfg com configurações dos
telefones Polycom.

Para edição do arquivo.cfg, basta clicar no ícone da engrenagem ao lado do aparelho desejado.
Para edição dos mapeamentos entre telefone IP x usuário, basta clicar no ícone do lápis.

Figura 7.45 É possível ainda exportar a listagem dos dados dos telefones IP para um arquivo.xls clicando
Provisionamento. no botão “Exportar para Excel”.
Capítulo 7 - PBX IP

191
Cadastrar Configuração

Para fazer o provisionamento de um telefone IP, devem ser preenchidas as seguintes
informações:

11 Número do Patrimônio: código de tombamento patrimonial do aparelho;

11 Número de Série/Endereço MAC: o endereço completo deve ser preenchido, pois esse dado
será utilizado para fazer a configuração do aparelho quando o este for conectado à rede;

11 Modelo do Telefone: ao selecionar o modelo, são mostrados os campos de usuário/
ramal, de acordo com a quantidade de linhas suportada por cada modelo;

11 Usuário: deverá ser preenchido com o login de usuário previamente cadastrado.

11 Telefone: após o preenchimento do usuário, serão mostrados os ramais associados a
ele. Deverá ser selecionado no combo, o ramal que deseja utilizar para o usuário nesse
telefone IP sendo configurado.

11 Nome/Email do Responsável: após preencher o usuário e telefone, basta clicar no ícone
para preencher automaticamente esses campos com os dados do usuário.

Telefones Figura 7.46
Patrimônio.
Essa opção permite cadastrar e consultar os modelos e características dos telefones IP que
serão utilizados no ambiente.
Serviço fone@RNP

Para cadastrar um telefone IP, devem ser informados: Figura 7.47
Lista de telefones.
11 Fabricante;

11 Modelo;

192
11 Quantidade de linhas suportadas;

11 Se há ou não suporte a PoE.

Figura 7.48 Fabricantes
Cadastro de
telefones. Os nomes de fabricantes cadastrados nessa opção serão utilizados para o posterior
cadastro de telefones.

Figura 7.49 Histórico
Cadastro de
fabricantes. Permite consultar informações de data/hora de cadastro e alteração de provisionamento.

É um registro histórico de cada telefone IP, indicando quais usuários já foram configurados
em um dado aparelho e quando as alterações foram feitas.

Figura 7.50 Serviços
Histórico.
São funcionalidades adicionais para os ramais da instituição. Estão disponíveis os serviços
de gravação de mensagem para informar sobre mudanças de número de ramal, bem como
captura de ligações entre grupos predefinidos.
Capítulo 7 - PBX IP

Troca de Número

Quando um ramal é desativado e substituído por outro, é possível criar uma mensagem
informando o novo número quando houver ligações para o número antigo. Essa opção
apenas faz a gravação da mensagem, sendo necessário configurar o funcionamento do
serviço e a rota no SRL.

193
Ao cadastrar o número novo e o antigo, é necessário que eles estejam no formato Cód.País +
DDD + Prefixo + número (Exemplo: 554837210000).

Figura 7.51
Troca de número.

Captura

A captura de chamadas entre ramais IP gerenciados pelo ambiente foi testada e homologada
para telefones IP Polycom. Para fazer a captura de chamadas, basta teclar Menu 1 8 no apa-
relho que deseja “puxar” uma ligação de outro.

Para que possa ser feita a captura, é necessário cadastrar um grupo, no qual deverá ser
informado:

11 Um ID para o grupo (geralmente o número de um dos ramais pertencentes ao grupo);

11 Descrição/Nome;

11 Login dos usuários pertencentes ao grupo. Para adicionar mais usuários, basta utilizar
o ícone “+”.

Figura 7.52
Grupo de captura.

Organização

Essa opção permite o cadastro de informações administrativas de localização dos ramais
instalados.

Unidades

Como Unidades, geralmente são cadastrados centros de ensino e pró-reitorias, por exemplo.

Para o cadastro de Unidades devem ser preenchidas as seguintes informações:

11 Nome: identificador único para cada unidade;

11 Descrição: informações opcionais;

11 Créditos Padrão: caso deseje que todos os ramais vinculados a uma unidade, que uti-
lizem o sistema de créditos, recebam inicialmente o mesmo valor, deverá ser informado
Serviço fone@RNP

nesse campo o valor desejado;

11 Responsável/E-mail: informações utilizadas apenas para fins de geração de relatórios;

194
11 Permissões Padrão: caso deseje que todos os usuários vinculados a uma unidade sejam ini-
cialmente autorizados para os mesmos tipos de ligação, deverão ser marcadas as permissões
desejadas. É possível selecionar configurações diferentes para unidades diferentes.

Figura 7.53
Cadastro de
unidade.

Departamentos

Para o cadastro de departamentos, devem ser utilizados nomes únicos. Cada departamento
é vinculado a apenas uma unidade.

Figura 7.54
Cadastro de
departamento.

Painel de Controle
Console

Essa opção visa facilitar o debug e acompanhamento de logs. É possível filtrar logs de
ligações, de erros, de acesso ao boot Server, entre outros. O log é atualizado no intervalo de
tempo definido, sendo que é possível pausar a atualização para verificação.
Capítulo 7 - PBX IP

195
Status Figura 7.55
Console.
Visão geral

Nesse menu, é possível verificar:

11 Status dos serviços;

11 Estatísticas da central;

11 Status do ambiente;

11 Status de replicação do banco de dados;
Figura 7.56
11 Status administrativo e operacional dos servidores Master e Slave. Status.
Serviço fone@RNP

196
Ligações

É possível acompanhar as ligações ativas em tempo real, observando origem, destino e
duração da chamada até o momento. Para atualizar o registro das ligações, basta clicar no
ícone no canto inferior direito.

Figura 7.57
Estatísticas. Contabilização
Completadas

Disponibiliza a listagem das chamadas completadas pelos ramais do ambiente, tanto chamadas
feitas, quanto recebidas, informando origem, destino, data e hora, duração e usuário associado.

É possível aplicar filtros para consulta por data, origem, destino, prefixo do tronco e usuário
associado. Há três botões de atalho rápido para filtro por data, para pesquisar chamadas
completadas nos sete dias anteriores, nos 30 dias anteriores, ou no mês atual.

Figura 7.58 Não Completadas
Contabilizações
Ligações Disponibiliza a listagem das chamadas não completadas pelos ramais do ambiente, tanto
completadas. chamadas feitas, quanto recebidas, informando origem, destino, data e hora, código de erro
e usuário associado.
Capítulo 7 - PBX IP

É possível aplicar filtros para consulta por data, origem, destino, prefixo do tronco e usuário
associado. Há três botões de atalho rápido para filtro por data, para pesquisar chamadas
não completadas nos sete dias anteriores, nos 30 dias anteriores, ou no mês atual.

197
Figura 7.59
Sobre o PBX IP Acadêmico Contabilização
Ligações não
O PBX IP Acadêmico é uma implementação especial de um PABX tradicional, desenvolvido completadas.
para o fone@RNP, que procura atender às demandas comuns do serviço de telefonia de uma
grande universidade brasileira. Foi desenvolvido primeiramente pela Universidade Federal
de Santa Catarina (UFSC), para atender às necessidades da UFSC. Quando da solicitação
de incorporação dessa solução ao fone@RNP, foi modificado para se integrar ao serviço e
melhor atender a todos os clientes do fone.

O PBX IP foi desenhado para funcionar com outros módulos do fone, tendo como pré-requisito
a instalação de um SRL. Além disso, a terminação de ligações na RTFC deve ser feita por um
gateway (idealmente o GWT) configurado como um peer do SRL que controla esse domínio.

O PBX IP deve receber INVITES apenas do SRL diretamente acima. Todas as chamadas feitas
a partir de um PBX IP devem ser encaminhadas para o SRL. Conexões de áudio e vídeo
podem seguir entre o PBX e o SRL, e o PBX, e outros dispositivos desse domínio. Como visto
nos parágrafos anteriores, o SRL fica responsável por indicar a rota correta para o número
de telefone desejado.

Essa versão do PBX IP se chama acadêmica porque foi desenhada para atender aos alunos
das universidades. Ela possui integração com o serviço de Identidade Digital da RNP, a
CAFe, Comunidade Acadêmica Federada. Essa integração permite a implementação de uma
função de autoatendimento, onde o aluno é capaz de solicitar seu próprio ramal IP em uma
página web, sem a intervenção de qualquer funcionário. Uma característica única no PABX IP
desenvolvido para a comunidade acadêmica brasileira.

O PBX IP também é preferivelmente implementado como uma Máquina Virtual. A RNP utiliza
VMWare, mas é possível implementar em qualquer outro fabricante ou tecnologia de virtua-
lização, embora a RNP não dê suporte para outras VMs.

O PBX IP Acadêmico não é implementado em dupla. Há apenas uma máquina virtual para ele.
Serviço fone@RNP

O PBX-IP Acadêmico foi concebido para prover um ambiente gráfico de gerência de acesso
à telefonia IP para alunos e funcionários de uma instituição. Esse guia descreve uma visão
geral da PBX-IP Acadêmica, contemplando todos os passos necessários para a instalação,
configuração e operação do ambiente, incluindo a integração com a federação CAFe e com
aplicações da instituição via WEB Service.

198
l A PBX-IP Acadêmica possui duas formas de integração com os sistemas da instituição:
É muito importante
ressaltar que a RNP 11 Através do LDAP da Federação CAFe;
não atuará como
11 Através do WebService da PBX-IP.
mantenedora do PABX
das instituições, A PBX-IP Acadêmica disponibiliza para a instituição:
mesmo se elas optarem
por instalar o PABX do 11 Catálogo Telefônico: listagem pública para consulta de ramais e usuários;
fone@RNP.Nós
desenvolvemos a 11 Portal do Usuário: interface de autosserviço, para acesso individual de cada usuário à
solução e estamos criação e configurações do seu próprio ramal;
oferecendo-a para uso
nas instituições em 11 Área administrativa: Módulo Sistema: para configuração de parâmetros da própria
conjunto com os outros máquina, firewall etc., através de uma interface web;
módulos do serviço
fone@RNP. Mas, 11 Área administrativa: Módulo Central: para gerência (cadastros, consultas e alterações)
exatamente como de ramais, usuários e permissões de discagem;
quando uma instituição
escolhe utilizar 11 WebService: para integração com sistemas de gerenciamento de identidade e vínculo
qualquer outro PABX, com a instituição, consultando os alunos e funcionários com vínculo ativo/regular, permi-
seja ele Siemens, Avaya,
Cisco, Leucotron, tindo então o uso de ramal da PBX-IP Acadêmica.
Intelbras, Asterisk,
Elastix, SNEP ou Esse guia foi elaborado com suporte as seguintes versões:
qualquer outro
fabricante, é necessário 11 Web: 2.0.158: 01/04/2015
que a instituição
11 Core: 2.0.28- 05/06/2015
contrate uma empresa
(ou possua o conheci-
mento internamente) Instalação do PBX IP acadêmico
para manter seu PABX
funcionando correta- Os requisitos mínimos para o funcionamento da máquina são os seguintes:
mente.
Atualmente, no 11 Memória: 2GB RAM;
momento da escrita
desse livro, para 11 Armazenamento: 50 GB;
realizar o trabalho de
11 VMware 5.0 e VMware-Tools instalado.
mantenedor do PABX IP
do fone@RNP, a RNP
Além disso, os seguintes requisitos também devem ser atendidos para a implantação da
conta com a equipe do
PoP-SC, que desen- PBX-IP Acadêmica:
volveu o PABX, e com a
CAM Tecnologia, que 11 Já possuir o SIP Router Local (SRL) instalado e em produção na instituição;
nos dá suporte no
11 Já possuir implantado o serviço da Comunidade Acadêmica Federada (CAFe) da RNP;
fone@RNP.
11 Ter um endereço IP público disponível para ser alocado à PBX-IP;

11 Fazer a configuração hostname/IP no DNS da rede da instituição;

11 Ter faixa de ramais para alocação TDM ou números privados do fone@RNP;
Capítulo 7 - PBX IP

199
Antes de iniciar a configuração da PBX-IP Acadêmica, tenha em mão os seguintes dados:

Informação Descrição Exemplo

IP SRL-M1 Endereço IP do SIP Router Local Máquina 1 200.0.2.11

IP SRL-M2 Endereço IP do SIP Router Local Máquina 2 200.0.50.22

Realm Domínio que será utilizado para registro dos usuários voip.instituicao.br
ou acad.voip.instituicao.br

IP para a PBX-IP Endereço IP Público que será utilizado pela PBX-IP 200.0.20.33
Acadêmica Acadêmica

LDAP CAFe Informações do LDAP da CAFe como: hostname/IP, ldap.pop-sc.rnp.br
DN ou=people,dc=ufsc,dc=br

Faixa TDM Prefixo e faixa de ramais TDM e/ou fone@RNP 48 1234-1000 a 48 1234-1999

Configuração de DNS para a PBX-IP Acadêmica
Para o registro de ramal dos usuários da PBX-IP Acadêmica, será necessário fazer a configu-
ração de um Realm para a máquina. Para isso, deve-se fazer a configuração de Realm/Porta
no DNS-SRV da instituição, isto é, incluir no DNS o registro SRV do Realm que será utilizado.
Siga os exemplos a seguir para fazer a configuração no DNS da sua instituição:

Exemplo 1: Realm direto no nome da instituição

11 Realm: instituicao.edu.br

11 Catálogo/Acesso usuários: acad.instituicao.edu.br

11 Porta SIP: 5080

instituicao.edu.br

pbxip-acad IN A 10.10.2.33
acad CNAME pbxip-acad
_sip._udp SRV 5 10 5080 pbxip-acad.instituicao.edu.br

Exemplo 2: Realm em um subdomínio da instituição

11 Realm: voip.instituicao.edu.br

11 Catálogo/Acesso usuários: acad.voip.instituicao.edu.br

11 Porta SIP: 5080

voip.instituicao.edu.br

@A 10.10.2.33
pbxip-acad IN A 10.10.2.33
acad CNAME pbxip-acad
_sip._udp SRV 5 10 5080 pbxip-acad.instituicao.edu.br.
Serviço fone@RNP

Importação da Máquina Virtual

A PBX-IP Acadêmica deve ser instalada através de imagem para VMware. Caso tenha outro
tipo de sistema de virtualização, podemos baixar o disco do VMware através do seguinte link:
http://repositorio-fone.rnp.br/fone2012/PBX-IP-ACAD/VM/1.0/stable/FoneRNP-PBXIP-ACAD-
disk1.vmdk

200
w Para realizar a instalação via imagem do VMware, acesse o servidor de VMs através do
Para que você consiga VMware vSphere Client.
fazer o deploy da URL,
você deve antes Siga os passos descritos no item 1.2 desde capítulo para o PABX Corporativo, logicamente,
solicitar à RNP a
substituído o link da VM para o PABX Acadêmico.
liberação do IP do seu
servidor de VM junto ao
Após concluído o processo de importação da VM, ligue a máquina para poder acessá-la e
repositório. Para
consultar a chave SHA1 iniciar a configuração.
para validação das
imagens, utilize o
seguinte link: http://
Acessando e configurando
repositorio-fone.rnp.br/
Configurando uma estação para acessar a PBX-IP
fone2012/PBX-IP-
-ACAD/VM/1.0/stable/
FoneRNP-PBXIP-ACAD.
A configuração de uma estação de trabalho para acesso inicial ao PBX IP Acadêmico é idên-
mf tica a preparação para acesso a outra VM qualquer do fone@RNP.

Repita os procedimentos descritos no item 2.1 desde capítulo, até o acesso pelo browser.

Para fazer o acesso inicial à área administrativa da PBX-IP Acadêmica basta acessar a URL
https://10.255.255.30/PBX-IP. Você será direcionado à tela inicial de login.

Configurando o PBX-IP Acadêmico
Seguindo os passos anteriores, aparecerá a tela de login.

Figura 7.60 Digite os seguintes dados para o acesso:
Primeiro login do
Capítulo 7 - PBX IP

PBX IP Acadêmico. 11 Usuário: admin

11 Password: pbxip.admin

Após o primeiro acesso, troque a senha de administrador imediatamente!

201
No canto superior direito, clique em “Sistema”, depois em “Administradores”. Edite o admi-
nistrador padrão e certifique-se de utilizar uma senha forte.

Módulo Central: Status

Após fazer o login, será exibida uma tela inicial de visão geral da máquina e da aplicação,
na qual é possível observar diversas informações, como status de recursos da máquina,
serviços, estatísticas, entre outras.

11 Status dos Serviços: lista os principais serviços utilizados pela PBX-IP, informando se Figura 7.61
estão rodando (ícone verde) ou não (ícone amarelo ou vermelho); Status.

11 Estatísticas da Central: estatísticas de ramais e chamadas da PBX-IP;

11 Status Administrativo: endereço IP alocado para a PBX-IP;

11 Número de CPUs e Porcentagem de Utilização: lista de CPUs da máquina, assim como
seu modelo e velocidade, contendo ao lado o percentual de utilização de cada uma;

11 Memória Efetiva, Memória Utilizada e Swap: memória efetiva é a memória efetiva-
mente sendo usada pelo sistema. Memória utilizada é o total de memória utilizada con-
tando a memória em cache, e swap é o total de memória utilizada como swap;

11 Carga média do sistema: carga média da PBX-IP no último minuto, nos últimos
5 minutos e na última hora;

11 Número de processos: número de processos rodando na PBX-IP;

11 Partições: lista de partições utilizadas pela máquina, contendo respectivamente suas
porcentagens de utilização.
Serviço fone@RNP

202
Central/sistema

São os módulos de configuração e operação da PBX-IP, os quais podem ser alternados,
clicando no canto superior direito da tela inicial, conforme figura 7.62.

11 No módulo central, é feita a operação da PBX-IP, isto é, a gerência de ramais e usuários,
contabilização de chamadas etc.;

11 No módulo sistema, é feita a configuração da máquina e da aplicação, isto é, são feitas
configuração de rede, firewall, TDM etc.

Firewall

Iniciaremos a configuração da PBX-IP Acadêmica pelo Firewall, de modo a evitar a perda de
acesso após alterar as configurações de rede da máquina. Para isso, clique em “Sistema”, no
canto superior direito da tela inicial. Em seguida, abra o menu lateral “Firewall”. Nessa tela, é
possível liberar diversos tipos de acesso à máquina.

Figura 7.62 Inicialmente, na opção “Rede de Gerência”, clique no botão para adicionar uma nova linha.
Firewall.
Preencha o IP/máscara da rede da instituição a partir da qual serão feitos acessos futuros
para operação da PBX-IP, quando for alterado para IP válido. Além disso, você deverá liberar
os IPs de NTP e DNS que serão utilizados pela máquina. Também é possível liberar acesso a
portas específicas através do item “Ações”, conforme exemplo da próxima figura.
Capítulo 7 - PBX IP

203
Por default, a porta padrão 5060 não é aberta, a fim de evitar acessos não autorizados. Caso Figura 7.63
queira que a porta fique aberta, basta incluir no item “Portas Abertas”, mas não é recomen- Configuração da
firewall.
dado, por ser uma porta comumente explorada em tentativas de SIP scan. A porta SIP local
padrão para operação do ambiente é a 5080, mas poderá ser alterada na opção “Portas
Abertas”. Essa porta será utilizada pelos usuários para registro de ramal na PBX-IP e deve
ser a mesma porta configurada no DNS da instituição.

Configurações > Sistema
l
Após fazer a liberação de firewall, faremos a configuração da máquina e da aplicação. Para Sempre após fazer
isso, acesse o menu lateral “Sistema” e preencha nas abas, as informações pertinentes da alterações na configu-
ração do firewall, clique
instituição e as principais configurações da aplicação e da máquina. em “Salvar” e em
seguida em “Aplicar”. É
Aba Instituição necessário aplicar para
que as configurações
Aba que contém as informações da instituição e do responsável pela administração da do firewall tenham
PBX-IP Acadêmica. Clique na guia “Instituição” e preencha com os dados cadastrais solici- efeito.

tados, conforme exemplo da figura a seguir. Ao concluir, clique em “Salvar”.
Serviço fone@RNP

204
Figura 7.64 Aba Sistema
Configurações do
sistema: Instituição. Nesta aba, serão preenchidas as configurações básicas da máquina, como rede, DNS, NTP etc.

Figura 7.65 11 IP: IP válido que será atribuído à máquina. Este IP deve ser público;
Configurações do
sistema: Sistema. 11 Máscara: máscara de rede do IP;

11 Gateway: gateway da rede à qual pertence o IP da máquina;

l 11 MTU: tamanho máximo da MTU no segmento LAN, padrão: 1500;

Observação: não 11 Hostname: nome do servidor no domínio de rede da instituição;
utilizar: “_” “;” “.” ou
outro caractere que Importante: no “Hostname”, a padronização adotada é “PBXIP-Acad-Sigla da Instituição”.
possa quebrar na
Exemplo: a UFSC terá o seguinte hostname: PBXIP-Acad-UFSC.
formação do
FDQN(Fully Qualified
11 NTP1 e NTP2: endereços dos servidores de NTP que serão utilizados pela máquina.
Capítulo 7 - PBX IP

Domain Name).
Lembre de liberar esses endereços no firewall;

205
11 DNS Resolver 1 e DNS Resolver 2: caso a instituição possua servidor de DNS, ou tenha
algum que deseje apontar, inserir nesses campos e liberar no firewall. Esses DNSs devem
ser capazes de resolver zonas de ENUM. Caso não possua DNS capaz de resolver DNS
ENUM, utilize os mesmos endereços IP dos SRLs. Esses endereços também devem ser
liberados no firewall;

11 Domínio: domínio de rede ao qual pertence o IP da máquina;

11 Time zone: fuso horário que a máquina vai utilizar.

Aba Gerência

Na aba Gerência, é possível configurar comunidades de monitoramento SNMP, desviar
os logs para um servidor externo, configurar o SMTP para envio de e-mails automáticos e
configurar permissão acesso para determinadas redes à interface de gerência da PBX-IP
(IPdaPBX/PBX-IP).

11 SNMP: Figura 7.66
Configurações do
22 Comunidade: Comunidade SNMP somente leitura; sistema: Gerência.
22 Rede de Gerência: rede de gerência para onde a comunidade de leitura terá acesso.

11 SYSLOG:

22 IP: endereço IP do servidor syslog de sua instituição;

22 Porta: porta onde o servidor estará escutando (Padrão: 514);

22 Protocolo: protocolo de transporte, atualmente suportado TCP e UDP (Padrão: UDP).

22 Syslog: para desabilitar o envio remoto via syslog, apontar para o IP 127.0.0.1.

11 SMTP:

22 Servidor SMTP: nome ou endereço IP do servidor SMTP responsável por encaminhar
Serviço fone@RNP

os e-mails da PBX-IP Administrativa;

22 Porta do servidor SMTP: porta do servidor SMTP utilizada para receber os e-mails.
Exemplo: 25, 465;

22 E-mail de origem: e-mail utilizado para compor as mensagens;

206
l 22 Autenticação SMTP: marcar caso o serviço de e-mail requeira autenticação:
Importante: acesso 22 Usuário: usuário utilizado para autenticação de envio;
WWW: liberar somente
para a rede de gerência 22 Senha: senha do usuário para autenticação.
da instituição ou
equipe de suporte RNP. 11 Acesso WEB: define a partir de quais redes é possível acessar as interfaces administra-
Acesso WebService: o tivas e de WebService:
método atual de
autenticação é através 22 WWW [1 – 5]: redes onde as interfaces administrativas poderão ser acessadas, isso é,
do IP de origem. /PBX-IP/;
Somente liberar para o
IP de sua aplicação 22 WebService: rede ou Host de onde o WebService da PBX-IP para criação de ramais
caso deseje interagir poderá ser acionado.
com a PBX-IP. Para
desabilitar, deixar em
branco.

Figura 7.67 Aba Proxy SIP
Configurações
do sistema: Define as configurações dos proxys para comunicação com a PBX-IP.
Acesso web.

11 PBX: VoIP Realm: Realm que será utilizado para responder ao serviço VoIP, isto é, o nome
Capítulo 7 - PBX IP

Figura 7.68
Configurações do definido para o IP da máquina no DNS da instituição. Exemplo: acad.voip.instituicao.br;
sistema: Proxy SIP.
11 OpenSIPs: Porta: porta onde o SIPProxy (OpenSIPS) vai atender requisições. Padrão: 5080;

11 OpenSIPs: Nível de Debug: nível de log que será gerado pelo OpenSIPs. Escolha entre
0 até 7. Recomenda-se utilizar 1;

207
11 Midia Server: Porta: porta UDP onde o asterisk responsável por executar funções de
servidor de mídia vai atender requisições (padrão: 5071). Não pode ser a mesma do
OpenSIPs. O acesso dessa porta somente será realizado pelo OpenSIPs;

11 Sip Router Local: IP Master: IP do Sip Router Local (SRL) master da instituição (Máquina 1);

11 Sip Router Local: Porta Master: porta do SRL master (Máquina 1). Padrão: 5060;

11 Sip Router Local: IP Slave: iP do Sip Router Local (SRL) slave de sua instituição (Máquina 2);

11 Sip Router Local: Porta Slave: porta do SRL slave (Máquina 2). Padrão: 5060;

Aba CAFe

Contém os parâmetros do LDAP de acesso para realizar a integração da PBX-IP com a
Federação CAFe.

11 CAFe LDAP Host: IP ou hostname do servidor LDAP da CAFe de sua instituição; Figura 7.69
Configurações do
11 DN: ponto de acesso DN (Nome distinto) do diretório LDAP da instituição; sistema: CAFe.
11 Modo: Modo de Conexão: default ou SSL. Padrão: default;

11 Porta: porta para realizar conexão. Padrão: 389 ou 636 (LDAP sobre SSL); l
A PBX-IP somente
11 Autenticação Por: informar o modo de autenticação: uID ou CN. aceita INVITES de
chamadas de peers
Aba TDM válidos (SIP Routers
Locais) ou usuários
Nesta aba, serão configurados os parâmetros de TDM, isto é, numeração de telefonia que autenticados. Invites
será utilizada pela PBX-IP. não autenticados ou de
fontes desconhecidas
são negados. Para que
o Realm funcione será
necessário criar as
entradas DNS-SRV
apontando para a
PBX-IP, informando em
qual porta o proxy vai
Serviço fone@RNP

trabalhar (padrão
5080).

208
Figura 7.70 Parâmetros de telefonia convencional:
Configurações do
sistema: TDM. 11 Código de País: código do País/CN: para o Brasil utilizar 55;

11 DDD: código DDD da instituição;

11 Prefixo: prefixo TDM da instituição;

11 Código da Operadora: código da operadora de longa distância. Exemplo: Embratel 21;

11 Linha Externa: código extra para acesso alinha externa. Exemplo: 0;

11 Ramal PBXIP Inicial: ramal inicial no prefixo TDM que será atendido por essa PBX-IP;

11 Ramal PBXIP Final: ramal final no prefixo TDM que será atendido por essa PBX-IP;

11 Ramal Padrão de Saída: ramal no prefixo TDM utilizado para completar ligações através
da URA da PBX-IP.

Parâmetros de VoIP: numeração Interna do Fone@RNP

11 Prefixo: prefixo fornecido pela RNP para uso interno da instituição. Exemplo: 1XXX;

11 Ramal Inicial: ramal inicial no prefixo VoIP que será atendido por essa PBX-IP;

11 Ramal Final: ramal final no prefixo VoIP que será atendido por essa PBX-IP.

Aba Serviços

Os serviços disponíveis nessa opção podem ser habilitados/desabilitados clicando sobre o
serviço desejado, em “Cancelar” > “Selecionar”. Capítulo 7 - PBX IP

209
Aba Aplicar Figura 7.71
Configurações do
Modificações feitas na configuração do sistema devem ser aplicadas para ter efeito. Sele- sistema: Serviços.
cione os itens onde as configurações devem ser aplicadas. Normalmente, seleciona-se os
três itens: sistema, OpenSips e Asterisk. Em seguida, clicar em “Aplicar configurações” e
aguardar sua conclusão.

Após aplicar as configurações, o IP da máquina será alterado. Será necessário voltar à Figura 7.72
configuração original de IP na máquina de acesso. Pode ser necessário também alterar a Configurações do
sistema: Aplicar.
configuração de vlan da máquina virtual no ambiente WMWare, caso tenha utilizado uma
vlan diferenciada para a configuração.

Em seguida, acesse novamente a o PBX IP Acadêmico, agora utilizado o IP válido que foi
configurado.
Serviço fone@RNP

Configurações > Atualização

Após acessar a máquina através do IP válido, com saída para a internet, o primeiro passo é
verificar se há atualizações disponíveis. Para isso, acesse o menu “Atualização”.

Se houver atualização disponível, será exibido conforme figura a seguir:

210
Figura 7.73 Clique em “Atualizar Aplicações”. Após concluir a atualização, será exibido o log conforme
Atualizações. exemplo da próxima figura. Na caixa de texto destacada em verde, clique em “Configurações
de Ambiente”. Você será redirecionado para a tela do menu Sistema, onde deverá aplicar as
configurações para que as alterações tenham efeito.

Figura 7.74 Caso não tenha nenhuma atualização disponível, será exibida a mensagem conforme figura
Atualização a seguir.
aplicada.
Caso o sistema informe “Erro ao buscar atualizações”, solicite à RNP permissão para fazer
Figura 7.75
Sistema atualizado. atualização do componente, ligando para o Service Desk.

Capítulo 7 - PBX IP

211
Configurações > Backup

É possível guardar um arquivo de backup das configurações atualizadas de sistema e firewall
da PBX-IP, caso ocorra algum problema com a máquina e seja necessário fazer uma reinsta-
lação futuramente.

Para fazer o download do arquivo de backup, basta acessar o menu “Backup” e clicar em
“Backup do arquivo M4”. Será gerado um arquivo de texto com os principais parâmetros e
variáveis do sistema. Recomenda-se fazer o download do arquivo e armazená-lo para uso
futuro, caso seja necessário.

Para fazer o upload do arquivo M4 (restauração de backup), basta clicar em “Selecionar
Arquivo”. Em seguida, clicar em “Enviar”.

Figura 7.76
Backup.

Administradores > Gerenciar

Após concluir a configuração e atualização, mais que alterar a senha do usuário de adminis-
tração, recomenda-se trocar o login “admin” (que já é conhecido e documentado), a fim de
evitar acessos não autorizados.

Para isso, acesse o menu “Gerenciar”, na guia “Administradores”.

Será exibida a listagem dos usuários administrativos cadastrados no sistema, onde é pos-
sível editar as informações de um usuário clicando no ícone do lápis.

Apague o usuário “admin” e cadastre outro Administrador. Clique em “Cadastrar Administrador”. Figura 7.77
Usuários
Será exibida uma tela para preenchimento das informações do usuário, bem como as (Administradores
permissões de acesso que serão concedidas a ele. Caso deseje que o usuário tenha acesso do PBX).

somente leitura a algum módulo específico, basta marcar a opção “Somente Leitura” ao
lado da permissão. Caso deseje que o usuário não tenha acesso a um determinado módulo,
basta deixá-lo desmarcado.
Serviço fone@RNP

212
Figura 7.78 Logs > Visualizar
Configuração dos
administradores. Os usuários cadastrados para acesso à área administrativa da PBX-IP terão suas ações
registradas através do menu logs, desde tentativas de login, cadastro de usuários, alteração
de privilégios, entre outras.

Figura 7.79 Ao acessar o menu “Visualizar”, serão listadas as ações do arquivo de logs, onde é possível
Filtros dos logs. realizar filtragem por data, usuário, ações, endereço IP e/ou alguma descrição.

Figura 7.80
Capítulo 7 - PBX IP

Logs do sistema.

213
Para obter mais detalhes sobre uma determinada ação, basta clicar sobre a linha, conforme
exemplificado na próxima figura.

Configurações > Permissões de Discagem Figura 7.81
Detalhes dos logs.
O próximo passo de configuração antes de poder iniciar a operação da PBX-IP Acadêmica é a
configuração dos tipos de chamadas que poderão ser realizados pelos usuários, bem como
as regras de formatação de número para encaminhamento ao SRL.

Os tipos de chamadas permitidas pelo ambiente são mapeados através de expressões regu-
lares, definidas nesta sessão. Quando um usuário fizer uma chamada, o número destino
será comparado com as expressões regulares definidas nessa sessão, para identificar qual
o tipo de destino que está sendo discado (Ramal, fixo/celular local, DDD etc.). Em seguida,
será verificado se o usuário possui permissão para esse tipo de chamada, para então fazer o
encaminhamento ou recusar a chamada. Além disso, a combinação das chamadas efetu-
adas com as expressões definidas é utilizada para geração de relatórios e contabilização de
custos (para chamadas tarifadas). Por exemplo, se o número discado por um usuário casar
com a linha “Chamadas locais de PSTN para Fixo”, conforme a figura 7.82, será em seguida
verificado se esse usuário possui permissão para fazer chamadas para fixo local PSTN. Se
possuir, a chamada será encaminhada e o tipo de chamada será marcado na contabilização
como sendo do tipo “Fixo local PSTN”.

Nesta sessão, devem basicamente ser alterados nas expressões regulares o DDD, código de
operadora, prefixo da instituição e faixa de ramais. Existe um campo para teste de número
destino, no qual é possível testar as regras alteradas, inserindo um número e verificando se
casa com alguma regra.
Serviço fone@RNP

Configurações > Plano de Discagem Figura 7.82
Permissões de
Após definir os tipos de chamadas permitidos no ambiente, é necessário definir os planos de discagem.
discagem (dialplan) contendo as regras alteração de numeração/reescrita para fazer o enca-

214
minhamento dessas chamadas ao SRL. Através dos planos de discagem, é possível alterar
o formato do número discado pelo usuário antes de encaminhar ao SRL. Por exemplo, a
instituição pode definir que os usuários disquem 0+DDD+8 números para chamadas interur-
banas, e o plano de discagem pode incluir o código de operadora automaticamente antes de
encaminhar a chamada ao SRL.

Figura 7.83 11 Descrição: id/nome da regra sendo criada;
Plano de discagem.
11 Expressão: expressão regular que case com a discagem feita pelo usuário;

11 Strip: quantidade de dígitos à esquerda do número destino que devem ser removidos
na reescrita;
l 11 Prefixo: dígitos/caracteres que devem ser inseridos à esquerda do número destino,
Uma chamada somente depois que os dígitos do strip foram removidos;
será encaminhada ao
SRL depois de casar 11 Ativo: ativar/Desativar regra.
com pelo menos um
plano de discagem, Nesse ponto, a configuração da PBX-IP está concluída e a máquina já está pronta para operação.
mesmo que esse não
Para isso, será detalhado a seguir os procedimentos de operação do módulo Central.
altere o número. Caso
haja planos de
discagem conflitantes, Guia de operação
será casado com o que
aparecer primeiro na O módulo Central permite ao administrador fazer a operação do ambiente, oferecendo
lista.
acesso ao status da PBX-IP, painel de controle, gerência de usuários, definição de infor-
mações de ramais, mapeamento de grupos da entidade Eduperson para os privilégios de
interesse, informações de contabilização, entre outras funções.

Organização: Classes

Inicialmente, é necessário cadastrar as classes de usuários (alunos, funcionários etc.) refe-
rentes ao esquema BR Eduperson, presentes na Federação CAFe, que serão utilizadas para
o mapeamento no momento do auto-serviço de cadastro. Por padrão, a PBX-IP já possui três
classes cadastradas conforme tipo de afiliação do Eduperson, as quais você deverá editar e
definir os parâmetros de permissões e créditos.
Capítulo 7 - PBX IP

215
É possível editar uma classe clicando no ícone na linha da classe desejada. Também é Figura 7.84
possível fazer cadastro de novas classes clicando em “Cadastrar Classe”. Tanto para cadastro Classes.

quanto edição de classe, os seguintes campos ficam disponíveis para preenchimento:

11 Nome: identificador único para cada classe;

11 Descrição: informações opcionais;

11 Tipo de Afiliação: tipo de afiliação (classe) ao Eduperson;

11 Créditos Padrão: todos os ramais de usuários vinculados a uma classe, que utilizem o
sistema de créditos, receberão inicialmente o mesmo valor de créditos, definido nessa
tela, e será feita uma recarga automática mensal no mesmo valor;

11 Permissões Padrão: caso deseje que todos os usuários vinculados a uma classe sejam
inicialmente autorizados para os mesmos tipos de ligação, deverão ser marcados as per-
missões de ligação desejadas.
Serviço fone@RNP

216
Figura 7.85 Ramais: Prefixos
Cadastro de
classes. Após definir as classes de usuários, é necessário definir os prefixos e as faixas TDM de
ramais que serão atribuídas a cada uma, pela PBX-IP. Para isso, acesse o menu “Ramais” >
“Prefixos” e cadastre os prefixos de numeração que serão utilizados pela PBX-IP, conforme
cadastrado anteriormente na aba TDM, das configurações do sistema.

Figura 7.86 Para o cadastro de prefixo, deverão ser informados os parâmetros, conforme exemplo.
Prefixos.
11 Código do País (2 dígitos). Exemplo: 55;

11 Código DDD do prefixo (2 dígitos). Exemplo: 48;
Capítulo 7 - PBX IP

11 Prefixo (4 dígitos). Exemplo: 1050;

11 Descrição: informações opcionais. Exemplo: prefixo Fone@RNP.

217
Ramais: Faixas Figura 7.87
Cadastro de
Após cadastrar os prefixos que serão utilizados, é necessário definir as faixas de ramais do prefixos.
prefixo, fazendo a divisão para cada classe, isto é, será definido o pool de ramais para cada
classe Eduperson.

Para fazer o cadastro de uma faixa, é necessário informar: Figura 7.88
Faixas de ramais.
11 Prefixo: prefixo dos ramais da faixa;

11 Início/Fim da Faixa: o ramal inicial e final da faixa;

11 Descrição: informações opcionais;

11 Classe Preferencial: deve ser informada uma classe, previamente cadastrada, à qual a
faixa de ramais será atribuída.
Serviço fone@RNP

218
Figura 7.89
Cadastro de faixa
de ramais.

Usuários SIP

l Após concluir o cadastro através do Portal do Usuário, os ramais/usuários são inseridos na
Quando for cadastrado interface administrativa da PBX-IP. No menu “Usuários SIP”, é possível consultar a lista de
um usuário, será usuários cadastrados. Na lista de usuários, a coluna SO (Status Operacional) contém um
automaticamente
atribuído o próximo ícone que fica na cor cinza quando o usuário não está registrado, e verde, quando o usuário
ramal disponível da está registrado. Já a coluna SA (Status Administrativo) indica os seguintes estados de ramal:
faixa associada a sua
classe. 11 Verde: usuário ativado;

11 Vermelho: usuário aguardando ativação.

Figura 7.90 Apenas o SA ativo (verde) permite que o usuário possa se registrar e efetuar/receber
Usuários SIP – chamadas. Para fazer a ativação manual de um usuário, sem clicar no link do e-mail, basta
Contatos.
clicar sobre o ícone da coluna SA do usuário desejado, passando de vermelho para verde.

É possível exibir toda a lista, bem como fazer buscas específicas por usuários ou por dados
de outras colunas, local, responsável etc. A ordenação default da lista de resultados é feita
por ordem de usuário, mas também pode ser feita clicando sobre o nome da coluna de
acordo com a qual os resultados devem ser ordenados.
Capítulo 7 - PBX IP

Ao clicar sobre o nome do usuário na lista, uma aba é aberta a seguir, indicando algumas
informações e dados. É possível ver o número dos ramais associados ao usuário, endereço
IP, caso ele esteja registrado, histórico de endereços IP nos quais o usuário já se registrou,
com as respectivas datas e horários, conforme pode ser observado nas próximas figuras.

219
Figura 7.91
Usuários SIP:
detalhes.

Também é possível editar um usuário e alterar manualmente algumas informações, seme- Figura 7.92
lhante ao que é feito através do Portal do Usuário. Para isso, basta clicar no ícone do lápis ao Usuários SIP:
detalhes.
lado do usuário que se deseja editar. Ao fazer alterações no usuário, não deve ser alterado os
dados de nome, login e documento, pois são dados automaticamente preenchidos pelo LDAP
da CAFe. Podem ser alterados o e-mail, habilitar/desabilitar sistema de créditos, inserir mais
créditos, alterar o ramal, deixar o ramal como público ou não exibir no catálogo e alterar as
permissões de discagem. Após fazer as alterações desejadas, clique em “Alterar”.
Serviço fone@RNP

220
Figura 7.93 Ramais: Gerenciar
Cadastro de
usuário SIP. Embora seja permitido cadastrar um ramal manualmente, essa ação não é necessária, pois
no momento do cadastro do usuário SIP também é automaticamente cadastrado o ramal
escolhido pelo usuário no Portal. Nessa sessão, é possível ver a lista dos ramais cadas-
trados, bem os usuários associados, fazer buscas, cadastrar novos ramais ou editar ramais
já cadastrados. Podemos fazer buscas por número de ramal ou outros dados do ramal.
Ao clicar na linha do ramal, é aberta uma extensão a seguir do ramal, onde são detalhadas
algumas informações do ramal selecionado.
Capítulo 7 - PBX IP

221
Para cadastrar um novo ramal, basta clicar em “Cadastrar Ramal” e preencher os dados Figura 7.94
solicitados. Para editar dados de ramais já cadastrados, basta clicar no ícone do lápis e, após Ramais.

fazer as alterações desejadas, clicar em “Alterar” para salvar as novas configurações.

Figura 7.95
Cadastro de ramais.

Os seguintes campos estão disponíveis na tela de cadastro/edição de ramal:

11 Classe: classe de afiliação, definida no cadastro da faixa que inclui o ramal;

11 Prefixo: prefixo da faixa do ramal;
Serviço fone@RNP

11 Ramal: número do ramal (dígitos);

11 Local: informação de local a ser exibida no catálogo telefônico.

11 Páginas Amarelas: visibilidade do ramal no catálogo telefônico: público, somente rede
interna da instituição ou não ser exibido;

222
11 Contatos do Ramal: caso um ramal tenha mais de um usuário;

11 Serviços: Correio de Voz: para habilitar a secretária eletrônica. É necessário definir uma
senha de 6 números, para acesso a partir do dispositivo onde o ramal estiver registrado
(Telefone IP ou Softfone);

11 Hora e Data Certa: serviço que fala a data e hora certa;

11 Teste de Eco: realiza teste de latência de áudio permitindo o usuário perceber a quali-
dade da chamada;

11 Siga-me: permite realizar um desvio contínuo para outro ramal ou número externo.
O usuário poderá alterar essa função através do Portal do Usuário. O número a ser
preenchido nesse campo deve obedecer as regras de discagem. Caso o siga-me seja para
um número externo, o usuário deve ter permissão para fazer esse tipo de chamada.

Registro de Usuário em Sofphone para teste

Nesse ponto, a PBX-IP já está com a configuração finalizada e possui um usuário/ramal
cadastrado.

Para testar as configurações da PBX-IP e o registro e realização de chamadas do usuário,
vamos fazer o registro do usuário SIP. Para isso, utilize qualquer softfone de sua preferência
ou Telefone IP, com os seguintes dados para o registro:

11 Domínio: Realm da PBX-IP, conforme configurado no DNS da instituição e na configuração
de sistema de máquina;

11 Porta SIP Local: 5080;

11 Username: usuário da CAFe/LDAP. Exemplo: nome.sobrenome;

l 11 Password: senha configurada no momento do cadastro do usuário no Portal;

Para que a PBX-IP 11 Authentication Username: usuário da CAFe/LDAP. Exemplo: nome.sobrenome;
Acadêmica possa
realizar e receber 11 Caller ID: nome do usuário ou número do ramal.
chamadas, é necessário
Você pode acompanhar o registro do ramal na interface de gerência de usuários SIP. Quando
que esteja cadastrada
como um peer no SRL o usuário SIP estiver registrado na PBX-IP, o ícone do telefone, na coluna SO, da linha do
da instituição e que usuário, ficará verde. Após o usuário registrar, já é possível realizar chamadas.
tenha como rotas as
faixas de ramais por ela Painel de Controle: Console
atendidas. Também é
necessário que esteja Você pode acompanhar o log das chamadas de um usuário através do menu “Console”. Essa
liberado o acesso da
opção visa facilitar o debug e acompanhamento de logs quase em tempo real. É possível
PBX-IP Acadêmica no
firewall do SRL. filtrar logs de ligações do OpenSIPS, de erros, Fail2Ban, entre outros. O log é atualizado no
intervalo de tempo definido, sendo que é possível pausar a atualização para verificação.
Capítulo 7 - PBX IP

223
Ligações Figura 7.96
Console.
Através desse menu, também é possível acompanhar informações das ligações ativas em
tempo real, observando de forma resumida origem, destino e duração da chamada até o
Figura 7.97
momento. Para atualizar o registro das ligações, basta clicar no ícone no canto inferior direito. Estatísticas.

lVocê pode também
Contabilização

A PBX-IP gera um relatório interno de chamadas completadas e não completadas.
acompanhar os logs
Completadas das chamadas externas
geradas/recebidas pela
Disponibiliza a listagem das chamadas completadas pelos ramais do ambiente, tanto cha- PBX-IP Acadêmica,
através da tela de
madas realizadas, quanto recebidas, informando origem, destino, data e hora, duração e
console do SRL da
usuário associado. instituição. Assim, é
possível identificar se
Serviço fone@RNP

É possível aplicar filtros para consulta por data, origem, destino, prefixo do tronco e usuário está ocorrendo
associado. Há três botões de atalho rápido para filtro por data, para pesquisar chamadas corretamente a
comunicação entre a
completadas nos sete dias anteriores, nos 30 dias anteriores, ou no mês atual. Um exemplo
PBX-IP e o SRL para o
dessa tela pode ser visualizado na figura. encaminhamento de
chamadas.

224
Figura 7.98 Não completadas
Contabilização:
Completadas. Disponibiliza a listagem das chamadas não completadas pelos ramais do ambiente, tanto
chamadas realizadas, quanto recebidas, informando origem, destino, data e hora, código
SIP e usuário associado. As opções de filtragem são semelhantes as chamadas completadas,
com acréscimo do código SIP.

w Os códigos SIP mais comuns são de erros associados a clientes e alguns do serviço ou servidor:
Para acessar o Portal
do Usuário, digite no 11 401/403: não permitido ou sem privilégio;
navegador web o
11 404: usuário/Ramal/Rota não encontrado;
endereço: https://
IPdaMáquina/usuario 11 480: temporariamente não disponível;
ou https://NomeDNS-
daMáquina/usuario. 11 486: ocupado (provavelmente em ligação);

11 487: geralmente o usuário não atendeu a ligação.

Capítulo 7 - PBX IP

Figura 7.99 Portal do Usuário
Contabilização: Não
completadas. Após a configuração dos prefixos e faixas, é possível iniciar o cadastro de usuários.
O cadastro de usuários não pode ser feito de forma manual na interface administrativa da
PBX-IP Acadêmica. Esta interface permite apenas a gerência, consulta e edição de alguns

225
dados dos usuários. Para o cadastro de usuários, deverá ser utilizado sistema próprio da
instituição, integrado à PBX-IP via web service, ou poderá ser cadastrado via interface de
autosserviço do Portal do Usuário.

Para acessar o portal, o usuário deve utilizar suas credenciais da CAFe: Figura 7.100
Portal do usuário.
11 Usuário: usuário da CAFe. Exemplo: nome.sobrenome;

11 Senha: senha do usuário da CAFe.

Após a autenticação, a PBX-IP Acadêmica busca os vínculos do usuário e, caso possua mais
Figura 7.101
de um vínculo (exemplo: funcionário e aluno), ficará a cargo do usuário definir qual vínculo Portal do usuário:
ele utilizará na criação de sua conta. vínculo.
Serviço fone@RNP

226
Após selecionar a afiliação, será solicitado o e-mail do usuário para confirmação do
cadastro. É necessário informar um e-mail válido, bem como a configuração de SMTP da
PBX-IP deve ser válida. Como o campo “e-mail” não é obrigatório na CAFe, caso seja encon-
trado o e-mail do usuário no LDAP, este será resgatado e caso não encontre o usuário
poderá fornecer outro e-mail. Após a escolha do e-mail, será solicitada uma senha que o
usuário vai utilizar para fazer o registro do seu ramal. Por questões de segurança, optou-se
por não forçar o uso da mesma senha da CAFe, pois ficará salva na configuração do softfone
e somente servirá para registro do usuário SIP. Além disso, o usuário deve selecionar um dos
ramais disponíveis no combo. Feito isto, deve-se clicar em “Selecionar Ramal”.

Figura 7.102 Com isso, o cadastro do usuário está concluído e esse será redirecionado para a tela inicial
Portal do usuário: do Portal do Usuário, onde constam alguns dados da conta.
cadastro.
Capítulo 7 - PBX IP

227
Além disso, o usuário receberá uma mensagem no e-mail cadastrado, com as informações Figura 7.103
de registro do seu usuário, e com um link para fazer a ativação da conta. O ramal ficará Portal do usuário.

bloqueado e não poderá ser utilizado enquanto o usuário não clicar no link enviado no
e-mail para fazer a ativação.

Caso ainda não tenha confirmado a ativação da conta, o usuário não conseguirá logar seu
softfone e aparecerá na tela inicial do portal a mensagem de status: “Para ativar seu ramal,
utilize o link enviado no seu e-mail”.
Serviço fone@RNP

228
Figura 7.104 Após a ativação, o status do ramal na página inicial do Portal do Usuário, deverá aparecer
Portal do usuário: como “Ativo”.
e-mail de requisição
de ramal.

Figura 7.105
Status do usuário.
Capítulo 7 - PBX IP

Após a ativação do ramal, o usuário poderá realizar pequenos ajustes em suas configurações,
através do portal do usuário, como alterar o e-mail e a senha, ativar serviço de correio de
voz ou até mesmo realizar um redirecionamento contínuo (siga-me) para outro número,
desde que possua privilégios para isso.

229
O Portal do Usuário dispõe ainda de uma agenda onde o usuário pode cadastrar seus contatos. Figura 7.106
Portal do usuário:
configurações.

Integração de sistemas: WebService Figura 7.107
Portal do usuário:
O Web Service provê uma interface para comunicação da PBX-IP Acadêmica com outros Contatos.
sistemas da instituição. A instituição poderá optar por utilizar o autosserviço da PBX-IP
integrado à CAFe (Portal do Usuário) ou incorporar em sua plataforma de serviços a gerência
das contas SIP.

Para ambos os casos, o endereço de acesso é:
https://IP_DO_SERVIDOR/webservice/webservice.php?wsdl.

Os parâmetros de saída (retorno das chamadas dos métodos) são devolvidos na forma de
string codificada em JSON que pode ser interpretada e utilizada para mostrar as informa-
ções solicitadas, possíveis erros ou mensagem de sucesso na chamada do método. Exem-
plos de mensagem de retorno:

string(61) “{“status”:”success”,”msg”:”Usuário criado com sucesso.”}”.
string(86) “{“status”:”error”,”msg”:”Erro no banco de dados. A operação foi
cancelada!”}”.
Serviço fone@RNP

O acesso ao WS é restrito para o IP/rede configurado em: “Sistema” > “Configurações” >
“Sistema” > “Gerência” > “WebService”.

O WebService facilita a integração com outros sistemas desenvolvidos em qualquer lin-
guagem. Exemplo de acesso em PHP utilizando a biblioteca SOAP do framework Zend:

230
require_once(dirname(__FILE__) . ‘/Zend/Soap/Client.php’);
$url= ‘https://IP_DO_SERVIDOR/webservice/webservice.php?wsdl’;
$client = new Zend_Soap_Client($url);
try{
$retorno= json_decode($client-> excluirUsuario(‘100000000263074@edu.br’),
true);
if($retorno[‘status’] == “success”){
//Trecho de código em caso de sucesso
} else if ($retorno[‘status’] == “error”) {
//Exemplo de impressão do erro ocorrido
echo”ERRO: “.utf8_decode($retorno[‘msg’]);
}
}catch (Exception$e) {
echo”Ocorreu um erro no WebService: “.$e-> getMessage();

Os seguintes métodos estão disponíveis para utilização:

createRamal
Recebe como parâmetros o UID do usuário na instituição, o tipo de afiliação, a senha e o
e-mail. Os quatro campos são obrigatórios e através do UID consultam-se as outras infor-
mações na CAFe, como nome, número de documento etc. Levando-se em consideração o
tipo de afiliação (student, employee, staff) o primeiro ramal disponível para a respectiva
classe é criado e associado ao usuário. É feito um hash com a senha e outras informações
que depois são confrontadas durante o registro do usuário em um cliente SIP (softphone).

Parâmetros de Entrada

Parâmetro Tipo Obrigatório Observações

Uid String Sim Identificador único do usuário
Exemplo: 100000000287834@edu.br

affType String Sim “student”, “employee”, “staff”

Tabela 7.1 senha String Sim Senha de registro
createRamal –
Parâmetros de mail String Sim E-mail do usuário
entrada.

Parâmetros de Saída

Parâmetro Observações

Tabela 7.2 status “success”, “error”
createRamal:
Parâmetros msg Mensagem informativa do resultado
de Saída.
Capítulo 7 - PBX IP

231
alterarSenha
Recebe o UID do usuário e a nova senha, recalcula o hash e altera os dados no banco de dados.

Parâmetros de Entrada

Parâmetro Tipo Obrigatório Observações

uid String Sim Identificador único do usuário
Tabela 7.3
Exemplo: 100000000287834@edu.br alterarSenha:
Parâmetros de
senha String Sim Senha de registro entrada.

Parâmetros de Saída

Parâmetro Observações
Tabela 7.4
Status “success”, “error” alterarSenha:
Parâmetros de
Msg Mensagem informativa do resultado saída.

buscaInfoRamais
Recebe o UID do usuário e retorna os dados dele.

Parâmetros de Entrada

Parâmetro Tipo Obrigatório Observações Figura 7.3
buscaInfoRamais:
uid String Sim Identificador único do usuário
Parâmetros de
Exemplo: 100000000287834@edu.br entrada.

Parâmetros de Saída

Parâmetro Tipo Observações

usuário String nome de usuário (username)

status String -1 = Inativo, 0 = Manutenção, 1 = Ativo
“error” = em caso de erro

creditosatual String Valor dos créditos atuais do usuário

creditosvalorreposicao String Valor da reposição mensal dos créditos

telefones Array de Array contendo os telefones associados ao usuário
Strings

tempo_total_falado String Tempo total de ligações do usuário no formato
HH:MM:SS

tempo_total_falado_ String Tempo total de ligações no mês atual do usuário
mes no formato HH:MM:SS Figura 7.6
buscaInfoRamais:
msg String Mensagem de erro (Só retorna no caso de status = Parâmetros de
Serviço fone@RNP

“error”) saída.

232
excluirUsuário
Recebe o UID do usuário e o exclui do banco de dados, excluindo-se também os contatos cadas-
trados no portal do usuário. Se os ramais só estiverem associados a esse usuário, são deletadas
também as mensagens do correio de voz do ramal e o próprio correio de voz. Durante o pro-
cesso de exclusão é armazenado em tabela do banco de dados a atual informação de créditos,
que será utilizada em caso de nova criação desse usuário dentro do mesmo mês, evitando
abusos por parte do usuário para tentativa de renovação dos créditos de forma indevida.

Parâmetros de Entrada

Parâmetro Tipo Obrigatório Observações
Tabela 7.7
excluirUsuário: uid String Sim Identificador único do usuário
Parâmetros de Exemplo: 100000000287834@edu.br
entrada.

Parâmetros de Saída

Parâmetro Observações

Figura 7.8 status “success”, “error”
excluirUsuário:
Parâmetros msg Mensagem informativa do resultado
de saída.

Capítulo 7 - PBX IP

233
Serviço fone@RNP

234
8
Estudo de casos
objetivos

Conhecer exemplos e possibilidades reais de uso do fone@RNP em diversos tipos de
ambientes.

conceitos
Versatilidade do fone@RNP.

Neste capítulo, são propostos casos de uso do fone@RNP que vêm sendo encontrados em
diversas instituições clientes. Vários são casos reais.

A dinâmica se baseia na apresentação do caso. O aluno deve sugerir a solução, descrevendo-a
textualmente e através de um esquema de blocos. Idealmente, se houver tempo, deve-se
finalizar o estudo no laboratório, com a instalação e configuração das soluções.

Lembrete sobre o uso do SRL nas instituições
O único caso em que o SRL é dispensável é quando há apenas um GWT em uso pela insti-
tuição cliente. Em qualquer outro caso, o uso do SRL é recomendável. Mesmo que pareça
trivial a ligação de um dispositivo SIP diretamente ao fone@RNP, é recomendada a insta-
lação de um (par de) SRL na instituição cliente.

O SRL isola a rede interna, no domínio do cliente, do “core” do serviço do fone@RNP.
Fazendo uma analogia para redes IP, ligar um PABX diretamente ao SRC seria igual a querer
conectar uma estação de trabalho diretamente em um roteador do backbone.

Além disso, o SRL instalado na rede local da instituição diminui consideravelmente o tempo de
resposta das mensagens de controle e, consequentemente, o tempo de conexão das chamadas.

O SRL também faz manipulações no número discado, formatando de acordo com a recomen-
Capítulo 8 - Estudo de casos

dação E.164 para que as pesquisas por rotas sejam padronizadas ou ainda, adequando-o
para integração com outros dispositivos do fone@RNP.

As mensagens que os dispositivos SIP ligados ao SRL devem esperar como resposta quando
uma chamada não pode ser realizada são:

11 404: Not Found: sem Rota;

11 408: Request Timeout: o outro lado não responde. Pode estar indisponível;

11 503: Serviço Indisponível: enviado pelo GWT quando a E1 apresenta problemas;

235
11 486: Busy: o número discado está ocupado;

11 487: Request Terminated: o usuário chamou determinado número e cancelou antes de
atender ou chamou até cair.

Caso 1
Cenário
A instituição possui um PABX digital, sem interfaces IP, com uma porta E1 para a operadora
e diversos ramais internos. Ela pretende apenas integrar seu PABX ao fone@RNP, sem
nenhuma pretensão de expandir de seu parque de telefonia.

PBX RTFC
Figura 8.1
Caso 1: Cenário.

Solução proposta
Nesse caso, o mais indicado é a instalação do GWT entre seu PABX e a operadora telefônica,
ligado diretamente ao SRC.

SRCs
RNP

PBX GWT RTFC
Figura 8.2
Caso 1: Solução.

Caso 2
Cenário
A instituição possui um PABX digital, com interfaces SIP disponível, com uma porta E1 para a
operadora e diversos ramais internos.

Ela pretende apenas integrar seu PABX ao fone@RNP, sem pretensão de expandir de seu
parque de telefonia.

RTFC
PBX IP
3os
Figura 8.3
Caso 2: Cenário.
Serviço fone@RNP

236
Solução proposta
Nesse caso, há duas saídas:

1. Se a instituição não quer ou tem dificuldades em configurar seu PABX, a solução indicada
é a mesma do caso 1: a instalação do GWT entre seu PABX e a operadora, ligado direta-
mente ao SRC.

A solução 1 deve ser evitada, pois gera custos desnecessários. Além disso, ocupa espaço no
datacenter e consome mais energia que uma VM.

2. É possível integrar ao fone@RNP sem a aquisição de nenhum hardware adicional.
Deve-se, então:

11 Instalar um par de SRLs (máquinas virtuais);

11 Configurar um tronco SIP em seu PABX IP e;

11 Configurar lá a “transparência”, isto é, chamadas a distância para números fixos devem
tentar ser entregues pelo tronco SIP (fone@RNP);

22 Se a ligação não puder ser completada, a chamada deve ser transbordada pelo tronco
padrão, com a operadora local.

11 Configurar a entrega de ligações locais, entrantes pelo fone@RNP, com destino à cidade
da instituição.

Vamos ilustrar aqui a opção 2, já que a primeira é desaconselhável e idêntica ao primeiro caso.

SRCs
RNP

SRL

RTFC
PBX IP
3os
Figura 8.4
Caso 2: Solução.

Caso 3
Cenário
A instituição do caso 3 tem um perfil de escritório. Foi crescendo com pouco (ou sem) pla-
Capítulo 8 - Estudo de casos

nejamento do seu serviço de telefonia. Hoje, possui um PABX sem troncos digitais, mas com
25 troncos analógicos com a operadora local e 30 ramais. Está adequando sua rede IP para
suportar a implementação do serviço de Telefonia sobre IP.

237
25 FXOs
PBX RTFC
Figura 8.5
Caso 3: Cenário.

Solução proposta
Tendo um perfil aproximado de escritório, com 30 ramais, dificilmente a quantidade de
ligações durante a HMM vai ocupar os 25 troncos simultaneamente. Assim, não deve haver
grande impacto perder alguns troncos. Para confirmar isso, é preciso conseguir relatórios de
uso desses recursos.

Além disso, ao interligar com o fone@RNP, parte das ligações que utilizariam os troncos
analógicos passarão a ser encaminhados pelos troncos SIP, pelo fone@RNP.

Também somos encorajados a indicar a adoção da tecnologia de voz sobre IP porque a
instituição mostra interesse em modernizar seu serviço de telefonia e porque a ampliação
do serviço baseado em VoIP é relativamente mais fácil e menos custosa do que a ampliação
do serviço tradicional.

Assim, a sugestão é a substituição do PABX atual pelo GWT Analógico, implementado pelo
equipamento CIP850. Apesar dos troncos analógicos serem limitados a oito canais simultâ-
neos, as ligações a distância para fixos serão encaminhados pelo fone@RNP (gerando eco-
nomia) e a quantidade de ramais poderá aumentar. Futuramente, se houver a necessidade
de aumentar a quantidade de troncos, é possível expandir a solução com relativa facilidade,
adicionando módulos do fone@RNP.

Para a integração do GWT analógico ao fone@RNP, é necessária a instalação do SRL para
manipulação dos números e controle das rotas dentro desse domínio.

SRCs
RNP

SRL

SIP

GWT 8 FXOs RTFC
analógico Figura 8.6
Ramais IP Caso 3: Solução.

Caso 4
Cenário
Serviço fone@RNP

A instituição possui um PABX com uma interface digital com a operadora telefônica.
Ela precisa expandir sua oferta de ramais, mas têm dificuldades em adquirir novas placas
(ou não há mais espaço no aparelho). A rede IP é saudável e há condições de implantação
de telefonia IP.

238
PBX RTFC
Figura 8.7
Caso 4: Cenário.

Solução proposta
Para a integração da rede de telefonia tradicional com a rede IP, será necessário um GWT.
Para ampliar a oferta de ramais, a sugestão é utilizar o PBX IP do fone@RNP. Sempre que há
mais de um dispositivo SIP na instituição, para que eles funcionem juntos será necessária a
instalação também do SRL, que controlará as rotas dentro desse domínio.

SRCs
RNP

SRL

PBX IP

PBX GWT RTFC
legado
Figura 8.8
Caso 4: Solução.

Caso 5
Cenário
A instituição ainda não possui solução de voz. Quer aproveitar 100% do fone@RNP. Mas
precisa ter uma interface digital local. A instituição considera acrescentar troncos GSM,
para celular. Também considera a contratação de provedor de telefonia IP (ITSP).

PBX RTFC

Figura 8.9
Caso 5: Cenário.

Solução proposta
Capítulo 8 - Estudo de casos

Como no caso anterior, há mais de um dispositivo SIP a ser controlado nesse domínio. Logo,
será necessária a instalação de um par de SRLs.

A seguir dele, o PBX IP do fone@RNP, porque a instituição manifestou o interesse de utilizar
100% da solução do fone@RNP.

Para a interface com a rede digital de telefonia, é necessário um GWT, configurado como um
peer no SRL.

239
O tronco com o ITSP será configurado como um peer no SRL.

O gateway para telefonia celular pode ser de dois tipos diferentes:

11 E1 - GSM: ficaria instalado no GWT;

11 SIP - GSM: instalado como um peer do SRL, como ilustrado a seguir.

SRCs
RNP

SRL

PBX IP GWT GW GSM

RTFC Móvel ITSP Figura 8.10
Caso 5: Solução.

Caso 6
Cenário
A instituição é composta por vários sites e já possui um serviço de telefonia IP que interliga
seus campi. Toda a lógica de encaminhamento de chamadas é controlada pela rede VoIP
pré-existente.

Reitoria
RTFC

Site 1
Serviço ToIP RTFC
RTFC da instituição
Site N
RTFC Site 2 Figura 8.11
Caso 6: Cenário.

Solução proposta
Nesse caso, todos os sites interligados pelo serviço de Telefonia IP da instituição se beneficiará
quando apenas um ponto se integrar ao fone@RNP. Basta instalar um par de SRLs para
interligar as duas redes.
Serviço fone@RNP

240
Assim como no caso 2, o cliente deverá configurar seu serviço para encaminhar chamadas a dis-
tância para números fixos pelo tronco do fone@RNP e, se a ligação não for completada, deverá
transbordar para sua estratégia padrão de terminação de chamadas. Deverá também aceitar
chamadas vindas do fone@RNP para serem entregues na RTFC nas cidades de seus sites.

SRCs
RNP

SRL

Reitoria
RTFC

Site 1
Serviço ToIP RTFC
RTFC da instituição
Site N
RTFC Site 2
Figura 8.12
Caso 6: Solução.

Caso 7
Cenário
A instituição é composta por três sites. Cada campus é independente (administrativamente)
do outro. Cada um possui um PABX digital com uma interface E1 com a operadora. Não há
intenção de expandir o serviço de telefonia a curto prazo para nenhum dos campi.

RTFC RTFC
PBX PBX

Reitoria Site 1

RTFC
PBX

Site 2
Figura 8.13
Caso 7: Cenário.

Solução proposta
Capítulo 8 - Estudo de casos

Novamente há mais de um dispositivo SIP no domínio do cliente. Então, há a necessidade
de instalar um par de SRLs. A seguir dele, configurado como peers, devem estar os GWTs,
ligados entre o PABX e a RTFC de cada site.

241
SRCs
RNP

SRL

PBX GWT RTFC PBX GWT RTFC

Reitoria Site 1

PBX GWT RTFC

Site 2
Figura 8.14
Caso 7: Solução.

Caso 8
Cenário
A instituição, uma universidade, é composta por vários sites. Cada campus tem sua adminis-
tração independente dos outros e os ambientes são extremamente heterogêneos. Suponha
que os campi são equivalentes aos casos 4 (Reitoria), 5 (Site1), 2 (Site2) e 6 (sites {3+4+5+N}).

A instituição já possui uma rede IP que interliga seus sites, com condições de implantar o
serviço de telefonia IP.

Além disso, a universidade também tem interesse em brindar seus alunos com o serviço de
telefonia IP, concedendo-lhes ramais IP (não o aparelho, mas números locais) para se comu-
nicarem entre si e com outros alunos e pesquisadores de outras universidades.

RTFC
PBX RTFC PBX IP
3os
Reitoria
Site 2

Site 3
RTFC

Site 4
Serviço ToIP RTFC
PBX RTFC RTFC da instituição
Site N
Site 1 RTFC Site 5
Figura 8.15
Caso 8: Cenário.
Serviço fone@RNP

242
Solução proposta
l Como há vários dispositivos SIP a serem controlados, há a necessidade de instalação de um
*Nota: os sites 1 e par de SRLs para o domínio da instituição cliente.
{3+4+5+N} podem (ou
não) precisar de um Para brindar seus alunos com ramais IP, basta instalar o PBX IP Acadêmico, ligado direta-
SRL local (nesses
mente ao SRL principal do cliente.
subdomínios),
dependendo das
No primeiro site, equivalente ao caso 4, basta seguir a solução do caso 4: um par de SRLs
características do
modelo de negócio do para esse (sub)domínio, um par de PBX IP e um GWT.
cliente e, eventual-
mente, do plano de No próximo site, equivalente ao caso 5, basta seguir a solução do caso 5: um par de SRLs
numeração envolvido para controlar esse (sub)domínio, ou seja, a saída pelo ITSP um (par de) PBX IP, um GWT e
no cenário.
um GW GSM.

No terceiro site, equivalente ao caso 2, basta aplicar a solução do caso 2: ligar o PABX de 3o
no SRL do domínio.*

Figura 8.16 No último site, equivalente ao caso 6, basta aplicar a solução do caso 6: ligar o serviço ToIP
Caso 8: Solução. da instituição ao SRL do domínio.*

SRCs
RNP

SRL
PBX IP
Acadêmico

SRL
Reitoria RTFC
PBX IP SRL
3os RTFC
Site 2 Site 4 Site 3
PBX IP GWT Serviço ToIP RTFC
RTFC da instituição
Site N
RTFC Site 5

PBX RTFC
legado

SRL Site 1

PBX IP GWT GW GSM
Capítulo 8 - Estudo de casos

RTFC Móvel ITSP

243
Serviço fone@RNP

244
9
Estatísticas
objetivos

Entender como extrair informações sobre as chamadas realizadas pelo fone@RNP,
individualmente, em cada módulo do serviço e, globalmente, pelo Sistema de
Estatísticas Nacionais.

conceitos
Estatística; Call Detail Record (CDR).

Sobre estatísticas
De acordo com o dicionário online Michaelis:

estatística

substantivo feminino

1 Ciência que tem por objetivo a coleção, análise e interpretação de dados numéricos a
respeito de fenômenos coletivos ou de massa, bem como a indução das leis a que tais
fenômenos cabalmente obedecem e, ainda, a representação numérica e comparativa, em
tabelas ou gráficos, dos resultados da análise desses fenômenos.

2 Os fatos numéricos pertencentes a um fenômeno coletivo ou de massa.

O fone@RNP possui uma frente de trabalho que se preocupa exatamente com as estatísticas
de uso do serviço. Os dados das chamadas realizadas dentro do serviço são coletados e
organizados de forma a permitir a análise e interpretação por nós: gerentes, engenheiros,
técnicos e analistas responsáveis pelo serviço.

Seja do ponto de vista da RNP, do prestador do serviço ou do ponto de vista das instituições,
clientes do serviço, o fone@RNP apresenta relatórios estatísticos ricos e úteis para tomada
de decisão.
Capítulo 9 - Estatísticas

Os relatórios do fone@RNP estão disponíveis online, com dois tipos de acesso:

11 No portal estatisticasfone.rnp.br, com acesso livre para qualquer pessoa;

11 Nos dispositivos do fone, com acesso restrito aos administradores e operadores
dos clientes.

245
O primeiro é mais útil para mostrar séries históricas e perfis de uso do sistema. O segundo
pode ter um caráter mais voltado para a descoberta de problemas, com pesquisas mais
pontuais. Mas ambos são muito importantes para tomada de decisão de técnicos e gestores.

Relatórios do Sistema de Estatísticas
O Sistema de Estatísticas (estatisticasfone.rnp.br) foi elaborado ainda na versão anterior
do fone@RNP, a distribuição 2008. Ele foi adequado para exibir também as estatísticas dos
dados recolhidos dos dispositivos da distribuição 2012.

Seu funcionamento é baseado nas ações de coleta dos Registros de Detalhes das Chamadas
(CDRs, na sigla em inglês), processamento dos CDRs, consolidação dos CDRs e apresentação
da informação em diversos relatórios diferentes. Cada relatório possui um ponto de vista
diferente, resultando em diferentes informações.

Ao acessar o sistema de estatísticas, o usuário vai encontrar uma tela de apresentação com
um dashboard contendo um mapa e uma tabela com informações resumidas à esquerda, e
quatro relatórios.

Uso do mapa Figura 9.1
Sistema de
O mapa à esquerda funciona como um filtro rápido, auxiliando a selecionar informações das estatísticas.
regiões e estados do Brasil. Conforme se clica no mapa, as estatísticas vão se atualizando.

Para voltar a apresentar informações nacionais ou regionais, ou seja, de todas as institui-
ções de uma região ou de todas as regiões do Brasil, basta clicar no botão “REGIONAL” ou
“NACIONAL”, que aparecem acima do mapa quando uma região ou estado é selecionado.

A tabela exibe as quantidades de chamadas, instituições e minutos com base nos filtros
Serviço fone@RNP

aplicados naquele instante.

246
Figura 9.2
Estatísticas gerais:
Detalhe.

l Para melhorar a visualização dos relatórios, o mapa pode ser omitido clicando na pequena
único gráfico que não seta, localizada à meia altura na divisória entre a coluna no mapa e os 4 relatórios.
reflete as escolhas do
mapa é a Matriz de
Tráfego.

Figura 9.3
Retrair painel
esquerdo.

Para voltar a apresentar o mapa, clique na mesma seta, que se reposicionará à extrema
esquerda do quadro.

Uso dos relatórios
Os relatórios apresentados no dashboard possuem botões de controle e áreas para infor-
mações, independente do tipo de gráfico que está sendo exibido.

Repare as marcações na figura a seguir.

Capítulo 9 - Estatísticas

Figura 9.4
Navegação nos
relatórios.

247
As marcações à esquerda são de áreas de informação. Acima, exibe o título do gráfico/rela-
tório, e a marcação de baixo é a legenda. Quando o mouse é colocado sobre essa área, a
legenda para esse relatório é exibida.

As marcações à direita são botões de ação e controle desse relatório. Acima, os já assimi-
lados botões de minimizar, expandir e fechar. E a seguir, um botão para exportar o relatório,
para comparar com outros relatórios, e um botão de detalhes, que tem a mesma função do
botão expandir, do conjunto superior de botões.

Na área mais interna de cada janela de relatório, além da informação propriamente dita, há
também alguns outros botões para controle do que e como deve ser plotado no gráfico.

Repare na figura a seguir.

Figura 9.5
Tipos de relatórios.

A área destacada acima mostra as possibilidades de se exibir a informação, se o gráfico deve
ser em linhas ou em barras.

A área destacada a seguir mostras opções de informações a serem plotadas no gráfico.
Nesse caso, é possível escolher entre número de chamadas, tempo total das chamadas ou
tempo médio das chamadas. Também é possível escolher se o que está sendo plotado são
chamadas feitas ou chamadas recebidas.

Exibição de outros relatórios
Serviço fone@RNP

O dashboard só mostra quatro relatórios simultaneamente. Só há espaço para esses quatro.

Para exibir outros relatórios, primeiro é necessário fechar um ou mais relatórios em exibição.

Novos relatórios estão disponíveis na combo box localizada na parte superior do portal
de estatísticas.

248
O botão “Instituição usuária” pode ser utilizado em conjunto com o “Relatório estatístico”.
Ao selecionar uma instituição e um relatório, quando o botão “Adicionar relatórios” é acio-
nado, o relatório já aparece com o filtro marcado para a instituição escolhida.

Figura 9.6 É possível até oito gráficos abertos, quatro em estado normal e quatro minimizados;
Lista de relatórios.

Relatório em Detalhes
Para apresentar um relatório em detalhes, clique no botão “Maximizar” ou no botão “Detalhes”.
Figura 9.7
Detalhes de A seguir, note dois relatórios exibidos no modo de detalhes. O primeiro é do tipo série
relatório em barras. histórica, apresentado em barras, e o segundo é um Ranking, apresentado em forma de “pizza”.

Capítulo 9 - Estatísticas

249
Note que no modo maximizado aparecem mais opções e informações: Figura 9.8
Detalhes de
11 Diversos filtros na parte superior da janela do gráfico; relatório em pizza.

11 Uma tabela com informações utilizadas para gerar o gráfico;

11 A escolha do tipo de informação a ser plotada;

11 Um resumo totalizando os dados considerados no filtro aplicado.

Comparação de relatórios
Agora que já sabemos retirar e adicionar relatórios no dashboard, é possível comparar
relatórios.

A função de comparação de relatórios foi pensada para ser utilizada com dois relatórios por vez.

Eles podem ser de mesmo título ou de títulos diferentes, e podem assumir qualquer filtro
que o usuário deseje configurar.

Para comparar dois relatórios, feche todos os relatórios. Depois escolha os dois gráficos
que você deseja comparar. Então, clique no botão “Comparar” do primeiro relatório e,
depois, no segundo.

A seguir, a figura exemplifica a comparação das “Chamadas Realizadas e Recebidas”, durante
o ano de 2012 pelos clientes RNP-Campinas e CEFET-MG.
Serviço fone@RNP

250
Figura 9.9 Note que o modo de comparação exibe os dois gráficos maximizados, com detalhes. Depois
Comparação de de maximizados, é possível navegar livremente entre os filtros e escolher o tipo de infor-
relatórios.
mação a ser plotada para realizar a comparação desejada.

Para sair do modo de comparação, é necessário clicar no botão “Restaurar”, o botão do
meio, nos três botões superiores à direita de uma das janelas.

Figura 9.10
Botão restaurar.

Descrição dos filtros
Os relatórios podem ser filtrados por período e localidade:

Período

Ano: pode ser escolhido um único ano ou um range de anos, deslizando os pontos:
Capítulo 9 - Estatísticas

Figura 9.11
Filtro de data – Ano.

Obs.: os anos que aparecem para os filtros são derivados das coletas. No caso acima
existem informações de 2010 até 2016.

251
Mês: pode ser feita a combinação de mês e ano:

Figura 9.12
Filtro de data: Mês.

Dia: pode ser feita para um único dia (inicial igual à final) ou um range de datas:

Figura 9.13
Filtro de data: Dia.

Hora: pode ser escolhido um período do dia para a exibição do relatório (25/08/2011 de
8h até 18h):

Figura 9.14
Filtro de data: Hora.

l
Localidade

Todo o filtro tem a opção “Todos”, assim, não é preciso limpar todo o filtro para modificação
Todos os filtros de
de apenas um item. localidade estão
interligados; assim,
Região: quando selecionamos
uma região, ela filtra as
Norte, Nordeste, Centro-Oeste, Sudeste e Sul. UFs, uma UF filtra os
DDDs e quando
UF: selecionamos um DDD
ele filtra as instituições.
Todas as UFs do Brasil, porém se a região Sudeste for selecionada, por exemplo, serão exi-
bidos só os estados dessa região, Espírito Santo, Minas Gerais, Rio de Janeiro e São Paulo.

DDD:

Todos os DDDs do Brasil, porém se o estado do Rio de Janeiro for selecionado, por exemplo,
serão exibidos os DDDs desse estado, 21, 22 e 24.

Instituição:

Todas as instituições participantes do Fone@RNP. Esse filtro segue o mesmo padrão dos
anteriores.

Descrição dos relatórios
Chamadas Completadas – Realizadas e Recebidas

Descrição do gráfico: o gráfico Chamadas Completadas mostra quantidade de chamadas
que foram feitas entre todas as instituições onde houve atendimento. Também há a opção
de exibir a duração das chamadas em minutos.

Estão excluídas desse gráfico, por exemplo, as chamadas em que o número chamado estava
Serviço fone@RNP

ocupado, não atendeu ou ainda com destino inexistente.

Filtros auxiliares:

11 Totais: quantidades das chamadas realizadas e das chamadas recebidas;

11 Durações: minutos das chamadas realizadas e das chamadas recebidas;

252
11 Tempo médio: exibe o tempo médio das chamadas, calculado no período do filtro principal.

Modos de exibição

Barras ou linhas.

Comparação de tipos por direção

Descrição do gráfico: o gráfico Comparação de Tipo por Direção mostra a quantidade
de ligações feitas de acordo com seu destino ou origem. Também há a opção de exibir a
duração das chamadas em minutos.

A seleção de origem ou destino é feita na caixa de opções a seguir da legenda. Quando sele-
cionado “Recebidas”, os tipos de chamadas se referem aos destinos. Quando selecionado
“Realizadas”, os tipos de chamadas se referem às origens.

Os destinos ou origens estão qualificados como:

11 RTFC: quando as chamadas são destinadas (Recebidas) ou originadas (Realizadas) em
telefones na Rede de Telefonia Fixa Comutada, ou seja, telefones na rede pública, fora
dos institutos e universidades;

11 PABX: quando as chamadas são destinadas (Recebidas) ou originadas (Realizadas) em
telefones convencionais dentro das instituições clientes;

11 VoIP: quando as chamadas são destinadas (Recebidas) ou originadas (Realizadas) em
telefones IP, sejam eles softphones ou deskphones.

Filtros auxiliares

11 Totais: quantidades das chamadas realizadas e das chamadas recebidas;

11 Durações: minutos das chamadas realizadas e das chamadas recebidas;

11 Tempo médio: exibe o tempo médio das chamadas, calculado no período do filtro principal.

Modos de exibição

Linhas ou barras.

Chamadas Completadas por Diferentes Tipos de Origem e Destino

Descrição do gráfico: o gráfico Chamadas Completadas por Diferentes Tipos de Origem e
Destino compara as chamadas feitas pelo sistema fone@RNP de acordo com os tipos de
origem e destino

A qualificação dos tipos de origem e destino é semelhante ao gráfico anterior.

11 RTFC: quando as ligações são originadas ou destinadas em telefones da rede pública, ou
seja, fora das instituições clientes;

11 PABX: quando as ligações são originadas ou destinadas em telefones convencionais
dentro das instituições clientes;

11 PABX: quando as ligações são originadas ou destinadas em telefones IP, sejam
Capítulo 9 - Estatísticas

deskphones ou softphones.

A tabela associada ao gráfico mostra também os valores absolutos da quantidade de chamadas
e tempo de duração de cada par origem x destino, separados por tipo.

253
Filtros auxiliares

11 Totais: percentuais das chamadas completadas de acordo com o cruzamento dos tipos
(origem x destino) possíveis;

11 Durações: percentuais dos minutos das chamadas completadas de acordo com o cruza-
mento dos tipos (origem x destino) possíveis;

11 Tempo médio: exibe o tempo médio das chamadas, calculado no período do filtro principal

Modo de exibição

Pizza

Ranking de Uso para Chamadas Completadas por Local

Descrição do gráfico: o gráfico Ranking de Uso para Chamadas Completadas por Local
mostra um comparativo das chamadas realizadas ou recebidas de acordo com a opção sele-
cionada em Tipo do Gráfico.

É possível ordenar as ligações pela quantidade de chamadas originadas ou quantidade de
chamadas recebidas. Também é possível ordenar de acordo com a quantidade de minutos
realizados ou recebidos.

A tabela associada ao gráfico mostra também os valores absolutos dos gráficos selecionados.

Filtros auxiliares:

11 Fez mais ligações: percentuais das chamadas completadas;

11 Recebeu mais ligações: percentuais das chamadas completadas;

11 Tempo de ligações realizadas: percentuais dos minutos das chamadas completadas;

11 Tempo de ligações recebidas: percentuais dos minutos das chamadas completadas.

Modo de exibição

Pizza.

Ocupação de Canais

Descrição do gráfico: o gráfico Ocupação de Canais mostra exatamente o que título propõe.
Em sua apresentação padrão, mostra as 24 horas do dia anterior, para todas as instituições.

Quando visualizado sem filtro de instituições, mostra a quantidade de chamadas simultâ-
neas que o sistema foi capaz de trafegar. Quando filtrado para uma instituição, mostra a
quantidade de troncos necessários para atender à demanda de chamadas a distância para
números locais desse cliente.

Em sua apresentação padrão, mostra as 24 horas do dia anterior, para todas as instituições.

Não faz sentido exibir esse gráfico para intervalos além de um dia. Por isso, o filtro de tempo
foi limitado para esse relatório.

Modo de exibição
Serviço fone@RNP

Linhas ou barras.

254
Ranking de Economia

Descrição do gráfico: o gráfico Ranking de Economia mostra um comparativo entre as
regiões ou instituições que mais economizaram com o uso do fone@RNP, de acordo com a
opção selecionada em Tipo do Gráfico.

Antes de visualizar a informação desse relatório é necessário que o usuário estime valores para
o custo do minuto de uma chamada a distância e o custo do minuto de uma chamada local.

É possível ordenar as ligações pela economia alcançada.

Filtros auxiliares

11 Quem economizou mais no total de ligações: total de ligações para outros clientes
e cidades;

11 Quem economizou por ligações não pagas: ligações para outros clientes do fone;

11 Quem economizou mais por ligações pagas: ligações para cidades onde há clientes
do fone@RNP.

Modo de exibição

Pizza.

Ranking de Ligações Públicas

Descrição do gráfico: o gráfico Ranking de Ligações Públicas mostra um comparativo entre
as regiões geográficas ou instituições, das chamadas realizadas ou recebidas para RTFC, de
acordo com a opção selecionada em Tipo do Gráfico.

É possível ordenar as ligações pela quantidade de chamadas originadas ou quantidade de
chamadas recebidas. Também é possível ordenar de acordo com a quantidade de minutos
realizados ou recebidos.

A tabela associada ao gráfico mostra também os valores absolutos dos gráficos selecionados.

Filtros auxiliares

11 Fez mais ligações: percentuais das chamadas completadas;

11 Recebeu mais ligações: percentuais das chamadas completadas;

11 Tempo de ligações realizadas: percentuais dos minutos das chamadas completadas;

11 Tempo de ligações recebidas: percentuais dos minutos das chamadas completadas.

Modo de exibição

Pizza.

Motivos de Não Completamento

Descrição do gráfico: o gráfico Motivos de Não Completamento mostra um comparativo
entre as mensagens de retorno mais comuns quando as ligações não são completadas.
Capítulo 9 - Estatísticas

A tabela associada mostra também os valores absolutos e é ordenada pela quantidade
de ocorrência.

As informações desse gráfico não significam necessariamente um problema com o
sistema fone@RNP.

255
Ocorrências como “chamou até cair”, “usuário estava ocupado” e “discagem para número
inexistente” estão incluídas aqui.

Modo de exibição

Pizza.

Estimativa de Economia

Descrição do gráfico:

O gráfico Estimativa de Economia oferece informações para que seja possível estimar a eco-
nomia feita com as ligações executadas através do fone@RNP. Apresenta valores de quanti-
dade de ligações e de duração total das chamadas. No gráfico são apresentadas três barras:

11 Quantidade de chamadas a distância não pagas: são as chamadas realizadas para
telefones IP ou para ramais convencionais dentro das instituições clientes. Assim, não foi
gerado nenhum custo adicional para nenhuma instituição;

11 Quantidade de chamadas a distância pagas: são aquelas terminadas na rede de tele-
fonia pública. Nesse caso, alguma instituição no estado destino arcou com o custo dessa
ligação local;

11 Economia Total: é a soma dos dois valores descritos acima. Essa barra só aparece l
quando os campos “Valor DDD” e “Valor Ligação Local” são preenchidos. O campo “Valor DDD”
deve ser preenchido
Filtros auxiliares com uma estimativa do
custo do minuto para
11 Totais: quantidades das chamadas realizadas; chamadas a distância
para fixo. O campo
11 Durações: minutos das chamadas realizadas; “Valor Ligação Local”
deve ser preenchido
11 Tempo médio: tempo médio das chamadas, calculado no período do filtro principal;
com uma estimativa
11 Economia: estimativa de economia, em reais. Os campos “Valor DDD” e “Valor Ligação do custo do minuto
para chamadas locais
Local” devem ser preenchidos pelo usuário.
para fixo.
Modos de exibição

Barras e Linhas.

Matriz de Tráfego

Descrição do gráfico: o gráfico Matriz de Tráfego oferece uma visão geral das ligações feitas
pelo sistema fone@RNP. As células da matriz mostram a quantidade de chamadas e o total
de duração das chamadas.

A matriz apresenta todos os possíveis fluxos, indicando origem e destino das ligações, agru-
pado de acordo com o filtro selecionado.

Filtros auxiliares

11 Tráfego: a opção “tráfego” mostra as ligações que foram atendidas;

11 Não tráfego: a opção “não tráfego” mostra a quantidade de ligações que não foram
atendidas, independente do motivo.
Serviço fone@RNP

256
Filtros

Esse relatório tem um sistema de filtros particular. A construção da matriz depende da com-
binação de Regiões, UFs, DDDs, Instituições (origem e destino) e a escolha do Tipo de Filtro.
Exemplos:

11 Criação de uma matriz com os estados da Região Sudeste:

22 Selecione a Região Sudeste na combo box Região;

22 Em Tipo de Filtro, selecione UF;

22 Clique em Filtrar Relatório.

11 Criação de uma matriz com alguns estados da Região Nordeste:

22 Selecione a Região Nordeste na combo box Região;

22 Com o botão shift do teclado sendo pressionado, selecione Alagoas, Bahia, Ceará e
Maranhão, por exemplo;

22 Em Tipo de Filtro, selecione UF;

22 Clique em Filtrar Relatório.

11 Criação de uma matriz com todas as instituições do Rio de Janeiro com DDD 21:

22 Selecione a Região Sudeste na combo box Região;

22 Selecione Rio de Janeiro na combo box UF;

22 Selecione 21 na combo box DDD;

22 Em Tipo de Filtro, selecione Instituição;

22 Clique em Filtrar Relatório.

Relatórios dos módulos do fone@RNP
Os relatórios embutidos nos módulos do fone@RNP (GWT, SRL e PBX IP) são mais indicados
para identificação e auxílio na resolução de problemas locais. Embora nada impeça que possa
ser utilizado para gerar séries históricas de sua instituição ou do domínio que atendem.

Relatórios do GWT
Ao acessar a interface gráfica de configuração do GWT, na coluna à esquerda, o módulo de
Figura 9.15
Estatísticas contabilização aparece na segunda posição. O GWT conta com quatro relatórios estatísticos
no GWT. que serão descritos nesse momento.

Capítulo 9 - Estatísticas

257
Estatísticas

Esse é um relatório online e interativo.

À direita exibe um gráfico com a quantidade de chamadas nos últimos 13 meses. É possível
plotar quatro tipos de chamadas:

11 Completadas VoIP: que seguiram pelo fone@RNP;

11 Completadas PSTN: que seguiram pela RTFC;

11 Não completadas VoIP: que não foram completadas e deveriam seguir pelo fone;

11 Não completadas PSTN: que não foram completadas e deveriam seguir pela RTFC.

Ao clicar na linha ou na legenda de cada tipo de informação, é possível habilitar do desabi-
litar a informação correspondente no gráfico.

A seguir desse gráfico vê-se a estimativa de economia, baseada em informação fornecida
quando da configuração do GWT.

Figura 9.16
Relatório interativo.

À esquerda é exibida a informação sobre o número de chamadas completadas ou não desde o
início de operação do GWT. Esses números são utilizados para a formação do gráfico à direita.

Essa informação também é interativa. Ao se clicar em completadas, por exemplo, os
números se desdobram em VoIP ou PSTN, indicando se as ligações foram encaminhadas
pelo fone@RNP ou pela RTFC, respectivamente. Novamente, ao se clicar em VoIP, por
exemplo, a informação se desdobra nos anos em que o GWT esteve em operação. Por
último, ao se clicar em um ano, a informação se desdobra nos meses daquele ano.
Serviço fone@RNP

Figura 9.17
Resumo das
informações.

258
Completadas

O relatório “Completadas” exibe o detalhamento das chamadas completadas com sucesso.
Basicamente, é o CDR.

Figura 9.18 Na parte superior, há uma série de campos onde é possível criar filtros para conseguir a
Chamadas informação desejada com maior precisão.
completadas.
Na parte de baixo do quadro de filtros há botões com filtros de tempo predefinidos.

Logo a seguir, é exibida a tabela com os detalhes das chamadas. É possível ordenar a tabela
de acordo com a coluna desejada clicando no cabeçalho da referida coluna.

As colunas de informação são:

Data A data e hora do início da tentativa de chamar o destino

Origem O número de origem, exatamente como repassado pelo GWT

Destino O número de destino, exatamente como repassado pelo GWT

Duração Tempo desde o início da tentativa de estabelecer a chamada

Tempo de Bilhetagem Duração a partir do atendimento
Capítulo 9 - Estatísticas

Tabela 9.1 Entrada Informa se a chamada entrou pelo PABX, RTFC ou fone@RNP
Informações
do relatório Categoria FORA DE USO
de chamadas
completadas. Terminação Informa se a chamada saiu para o PABX, RTFC ou fone@RNP

259
Não Completadas

O relatório “Não Completadas” exibe o detalhamento das chamadas que não foram com-
pletadas com sucesso. De forma geral, é um dos primeiros lugares a se visitar quando há
suspeita de problemas com as entregas das chamadas.

As informações são muito semelhantes ao relatório anterior, incluindo a área de filtros.

A única mudança é que as colunas “Duração” e “Tempo de Bilhetagem” são substituídas pela
coluna “Motivo”, que informa o motivo pelo qual a chamada não foi completada.

Mais Chamados Figura 9.19
Chamadas não
O relatório “Mais Chamados” exibe os números que mais foram chamados por esse GWT, a completadas.
partir do PABX.

Na parte superior há dois campos onde é possível criar filtros para conseguir a informação
desejada com maior precisão. É possível escolher a terminação, ou seja, se a ligação foi
encaminhada pelo fone@RNP ou pela RTFC. Também é possível filtrar o número destino.

Ainda existem dois filtros predefinidos. O primeiro botão exibe as chamadas que foram
encaminhadas pela RTFC que não possuem rota pelo fone@RNP (um comportamento
esperado). O segundo botão exibe chamadas que foram encaminhadas pela RTFC, mas que
possuem rotas pelo fone@RNP. Essas, podem ser indício de algum problema.

Logo a seguir é exibida a tabela com os detalhes das chamadas. É possível ordenar a tabela
de acordo com a coluna desejada clicando no cabeçalho da referida coluna.

As colunas de informação são:

Número destino Número mais discado

Última atualização Última vez em que o número foi discado
Serviço fone@RNP

Sucesso VoIP Quantidade de vezes em que foi encaminhado pelo fone@RNP

Sucesso PSTN Quantidade de vezes em que foi encaminhado pela RTFC Tabela 9.2
Informações
Próxima ligação Porta pela qual a próxima ligação deve ser encaminhada do relatório de
chamadas mais
Detalhe Apenas apresenta o ícone de detalhe discadas.

260
Figura 9.20 Ao clicar sobre o número mais chamado, na primeira coluna, é apresentada uma nova janela
Números mais de informações com os detalhes das chamadas para o número em questão.
chamados.

Figura 9.21
Lista de chamadas
Capítulo 9 - Estatísticas

para determinado
destino mais
chamado.

Ao clicar sobre o ícone da lupa, na última coluna, é apresentada uma nova janela de informa-
ções com os detalhes das informações tabeladas para o número em questão.

261
Relatórios do SRL Figura 9.22
Detalhes do
O SRL, assim como o SRC, possui três tipos de relatórios estatísticos. Todos baseados nos número destino.
Registros das Chamadas (CDRs) que passam por eles. Eles mostram, basicamente:

11 O próprio detalhamento das chamadas;

11 A matriz de tráfego, com quantidade de chamadas e minutos;

11 Gráficos da matriz de tráfego, com a quantidade de chamadas.

Figura 9.23
Serviço fone@RNP

Contabilização
do SRL: Seleção
de peers.

Essa imagem é a tela da aba de contabilidade do SRC. São apresentados todos os peers

262
cadastrados para escolha da origem e para escolha do destino, um ao lado do outro.
A seguir e à esquerda há um quadro para configuração do filtro de intervalo de tempo.
E a seguir e à direita se encontram os três botões para os três tipos de relatórios diferentes.
Os passos para geração de um relatório são bem simples.

Na aba Contabilização:

11 Escolha os peers de origem;

11 Escolha os peers de destino;

11 Escolha o intervalo de tempo a ser analisado;

11 Escolha o tipo de relatório desejado.

Gerar tabela

Figura 9.24 Na imagem, um exemplo de relatório do botão “Gerar tabela”.
Contabilização do
SRL: tabela. A tabela é o próprio Detalhamento da Chamada, o CDR.
Capítulo 9 - Estatísticas

As colunas de informação são:

263
Data e hora da chamada Marca o início da chamada Tabela 9.3
Informações da
Origem Informa o peer que originou a chamada tabela de ligações.

Tipo Origem Informa tipo de telefone que originou a chamada

Número Origem Informa o número “chamador”

Destino Informa o peer para onde a chamada foi encaminhada

Tipo Destino Informa o tipo de telefone onde a chamada foi terminada

Número Destino Informa o número chamado, no formato E.164

Duração Informa a duração da chamada

A janela ainda apresenta alguns comandos auxiliares. l
As ligações não
No canto superior direito encontram-se dois botões: “Completadas” e “Não completadas”. completadas não
significam necessaria-
Por padrão, o botão “Completadas” está selecionado. Ele exibe as ligações que ocorreram mente um problema no
normalmente. Se o usuário escolher o botão “Não Completadas”, serão exibidas as tenta- fone@RNP. Ali podem
estar listadas, por
tivas de conexão que não foram bem-sucedidas.
exemplo, chamadas
feitas para destinos
No canto inferior direito estão botões de navegação nos registros. Sua utilização é
que estavam ocupados
bem intuitiva. na hora da ligação.

No canto inferior esquerdo estão botões com opções para exportação dos dados exibidos
na tela. É possível exportar os dados para o “clipboard” (memória), para o formato Excel
Figura 9.25
(separado por vírgulas), para o formato PDF e para impressora. Contabilização
do SRL: Matriz de
Gerar Matriz tráfego.
Serviço fone@RNP

Essa imagem é um exemplo de relatório do botão “Gerar Matriz”.

264
O relatório é a própria matriz de tráfego entre os peers selecionados. Não há necessidade de
escolher os mesmos peers de origem e destino. Ou seja, a matriz não precisa ser quadrada.

l Os peers mostrados no início de cada linha são as origens e os peers mostrados no início de
Nesse contexto, o
PoP-SP é um peer cada coluna são os destinos.
mantido pela RNP. Sua
função é apenas A informação dentro de cada célula é o número de chamadas e o volume em minutos entre
entregar chamadas na origem e destino.
cidade de São Paulo
para as instituições Por exemplo, a matriz mostra que a UFSC fez 249 chamadas, totalizando mais de 15 horas
clientes.
de conversação, para São Paulo, pelo peer PoP-SP. Por outro lado, o PoP-SP não realizou
chamadas para nenhum dos peers exibidos.

Gerar Gráfico

Figura 9.26 Na imagem está um exemplo do relatório obtido ao escolher o botão “Gerar Gráfico”.
Contabilização do
SRL: Gráficos. Esse relatório exibe em forma de gráfico a informação de quantidade de ligações que ocor-
reram com sucesso e também as tentativas que não foram completadas.

Os gráficos são obtidos com dados da matriz de tráfego equivalente às instituições escolhidas.

As abas correspondem aos peers de origem. Todas as abas (origens) exibem um gráfico para
cada destino.

Por exemplo, de acordo com o gráfico, houve tentativas sem sucesso de ligações da RNP-DF
para RNP-RJ em alguns dias. Em outros, houve quantidades semelhantes de ligações com
Capítulo 9 - Estatísticas

sucesso. Então, é possível inferir que houve algum problema entre os peers RNP-DF e
RNP-RJ no início e no meio de fevereiro.

Relatórios do PBX IP

As estatísticas do PBX IP são bem simples. Podemos encontrar informações estatísticas em
dois lugares.

265
Na primeira página, “Visão Geral” (Primeiro quadro, Status, na coluna da esquerda), há um
pequeno resumo da quantidade e da situação dos ramais cadastrados e das ligações.

O outro local onde é possível encontrar informações estatísticas no PBX IP se está no último Figura 9.27
quadro da coluna esquerda, chamado “Contabilização”. Estatísticas do
PBX IP.
Serviço fone@RNP

Há dois relatórios nesse módulo: Completadas e Não completadas. Figura 9.28
Menu de
contabilização.
266
Completadas

O relatório Completadas mostra, basicamente, o CDR das ligações que foram originadas e
recebidas pelos ramais do PBX.

Na parte superior há uma série de campos onde é possível criar filtros para conseguir a
informação desejada com maior precisão.

Na parte de baixo do quadro de filtros há botões com filtros de tempo predefinidos.

Logo a seguir é exibida a tabela com os detalhes das chamadas. É possível ordenar a tabela
de acordo com a coluna desejada clicando no cabeçalho da referida coluna.

As colunas de informação são:

Data A data e hora do início da tentativa de chamar o destino

Origem O número de origem, no formato E.164 ou como recebido pelo PBX

Destino O número de destino, no formato E.164 ou como recebido pelo PBX
Tabela 9.4
Informações da Duração Intervalo de tempo em que o chamado ocupou recursos no PBX
tabela de chamadas
Usuário O nome do usuário no PBX ou o número recebido pelo PBX
completadas.

Capítulo 9 - Estatísticas

Figura 9.29 Não Completadas
Contabilização do
PBX IP: Relatório O relatório “Não Completadas” exibe o detalhamento das chamadas que não foram com-
de chamadas pletadas com sucesso. De forma geral, é um dos primeiros lugares a se visitar quando há
completadas.
suspeita de problemas com as entregas das chamadas.

267
As informações são muito semelhantes ao relatório anterior, incluindo a área de filtros.

A única mudança é que a coluna “Duração” é substituída pela coluna “Código”, que informa
o código da mensagem SIP com que a chamada foi desligada, indicando o motivo pelo qual a
chamada não foi completada.

Figura 9.30
Contabilização do
PBX IP: Relatório
de chamadas não
completadas.
Serviço fone@RNP

268
10
Anexos

dAnexo 1 – Planejamento para instalação do
fone@RNP em uma empresa fictícia
Mudança
Renovação do serviço de telefonia da empresa fictícia XPTO e integração de seus três escritórios.

Resumo da mudança
O serviço de telefonia atual que utiliza equipamentos tradicionais e é independente em cada
escritório será substituído pela solução de telefonia IP desenvolvida para o serviço fone@RNP,
distribuição 2012. Também será substituído o serviço fone@RNP na sua versão antiga.

Além da substituição de equipamentos (PABX e telefones), também serão incluídas algumas
funções extras no serviço de telefonia.

11 Chamadas a quatro dígitos entre os escritórios;

11 Criação de caixas de mensagens para todos os ramais.

22 Encaminhamento de recados para e-mail, com arquivo de áudio anexado.

11 Para os viajantes, mesmo número na mesa ou no softphone.

22 Registro em mais de um telefone IP ao mesmo tempo;

22 Softphone herdará todas as características do telefone de mesa;

22 Possibilidade de atender ou realizar chamadas na mesa ou no softphone.

11 Capacidade de FAX para cada ramal.

O que será instalado?
Capítulo 10 - Anexos

Instalação do fone@RNP v.2012, com substituição do fone 2008 e do sistema tradicional de
telefonia nos três escritórios.

269
Ações previstas
A mudança está prevista para ocorrer em duas fases:

11 Fase1: Piloto;

11 Fase2: Migração completa;

A fase1: piloto contará com a participação de toda a equipe da Serviços, Colaboradores indi-
cados pela TI, colaboradores indicados de P&D, mais alguns colaboradores-chave.

Após a instalação e configuração da fase1, haverá um período de dois meses de avaliação
do piloto.

A fase2: migração completa deverá executar a migração dos telefones dos demais colabora-
dores da XPTO.

As seguintes atividades estão previstas:

11 Aprovação do plano de migração;

11 Instalar GWTs em cada escritório;

11 Instalar SRL para XPTO (1º nível);

11 Instalar SRLs em cada escritório (2º nível);

11 Instalar PBX IP em cada escritório;

11 Instalar os primeiros ramais IP (registrar telefones no PBX IP);

11 Considerar configuração dos telefones por autoprovisionamento;

11 Configurar encaminhamento padrão pela rota de menor custo;

11 Configurar encaminhamento dos DDRs dos telefones antigos para os novos;

11 Configurar encaminhamento a 4 dígitos entre sites internos;

11 Configurar encaminhamento dos números virtuais (2008) para novos ramais;

11 Automatizar como “siga-me” do número virtual para o novo ramal IP;

11 Conversar com cada usuário do ramal antigo;

11 Rodar o checklist;

11 Revisar e corrigir configurações no serviço fone@RNP e na rede IP de suporte (rotas e firewall);

11 Rodar o checklist sem nenhum erro;

11 Período de análise do Piloto do fone@RNP nos escritórios da RNP;

11 Migrar os outros telefones;

11 Rodar o checklist sem nenhum erro;

11 Desligamento dos servidores do fone antigo;

11 Desligamento dos PABX legados;

11 Retirada dos telefones analógicos.
Serviço fone@RNP

270
Cronograma
# Descrição Data Início Data final Observação

1 Aprovação do plano de Migração 14/10 17/10

2 Instalar GWTs em cada escritório GWT-S1 ok GWT-S1 ok
GWT-S2 ok GWT-S2 ok
GWT-S3 ok GWT-S3 ok

3 Instalar SRL para XPTO (1o nível) SRL (1n1) ok SRL (1n1) ok
SRL (1n2) SRL (1n2) 17/10
14/10

4 Instalar SRLs em cada escritório 14/10 24/10
(2º nível) SRL2n1-S1 SRL2n1-S1
SRL2n2-S1 SRL2n2-S1
SRL2n1-S2 SRL2n1-S2
SRL2n2-S2 SRL2n2-S2
SRL2n1-S3 SRL2n1-S3
SRL2n2-S3 SRL2n2-S3

5 Instalar PBX IP em cada escritório 14/10 24/10
PBX1-S1 PBX1-S1
PBX2-S1 PBX2-S1
PBX1-S2 PBX1-S2
PBX2-S2 PBX2-S2
PBX1-S3 PBX1-S3
PBX2-S3 PBX2-S3

6 Instalar os primeiros ramais IP (registrar 27/10 31/10 Com auxílio das equipes
telefones no PBX IP) de suporte locais.

7 Configurar encaminhamento padrão 03/11 07/11 Auxílio de suporte
pela rota de menor custo terceirizado

8 Configurar encaminhamento dos DDRs 03/11 07/11 Auxílio de suporte
dos telefones antigos para os novos terceirizado

9 Configurar encaminhamento a 4 dígitos 03/11 07/11 Auxílio de suporte
entre sites internos terceirizado

10 Configurar encaminhamento dos números 03/11 07/11 Auxílio de suporte
virtuais (2008) para novos ramais terceirizado

11 Rodar o checklist 07/11 07/11

12 Revisar e corrigir configurações no 10/11 12/11
serviço fone@RNP e na rede IP de
suporte (rotas e firewall)

13 Rodar o checklist sem nenhum erro 13/11 13/11

-- Período de análise do Piloto 13/11 15/01

14 Migrar os outros telefones 01/02 01/03
Capítulo 10 - Anexos

15 Rodar o checklist sem nenhum erro 01/03 01/03

16 Desligamento dos servidores do 15/03 15/03
fone antigo

17 Desligamento dos PABX legados 15/03 15/03

18 Retirada dos telefones analógicos 16/03 23/03

271
Plano de discagem
Sempre que possível, deve ser mantida a forma de discar atualmente em vigor na empresa.
Para evitar mudança no hábito dos colaboradores, será mantido o primeiro “0”, para “pegar
linha externa”, apesar de saber que, tecnicamente, não é mais necessário.

11 Números internos do mesmo escritório: 4 dígitos;

11 Números internos de outros escritórios: 4 dígitos ou completo (0+CA+8dígitos);

11 Números locais fixos: 0 + 8 dígitos iniciados por 2-5;

11 Números locais celulares: 0 + 8 dígitos iniciados por 6-7 | 0 + 9 dígitos iniciados por 8-9;

11 Números a distância fixo: 0 + CA + 8 dígitos iniciados por 2-5;

11 Números a distância celular: 0 + CA + 8 dígitos iniciados por 6-7 | 0 + CA + 9 dígitos
iniciados por 8-9;

11 Números Internacionais: 0 + 0 + CP + número de 7 a 11 dígitos (incluindo código de área
do país);

11 Ligações a cobrar local: 0 + 90 + 90 + 8 ou 9 dígitos;

11 Ligações a cobrar a distância: 0 + 90 + CA + 8 ou 9 dígitos.

Serviços especiais:

0 + 0X00 + 8 dígitos
0 + 1XX

Sobre a infraestrutura
Lista de dispositivos e DMZs
DMZ para serviços externos

SRC: Serviço Nacional para clientes da RNP (Já existe! Pertence ao prestador do serviço).

SRC-RJ: 200.143.193.54

SRC-DF: 200.130.35.113

Rede Externa

SRL-S1 (2o nível): Serviço local para o escritório (Site1).

SRL-S1-2n1:

SRL-S1-2n2:

PBX-S1: Serviço local para o escritório (Site1)

PBX-S1-1:

PBX-S1-2:
Serviço fone@RNP

GWT-S1: Serviço local para escritório (Site1)

GWT-S1: XXX.XXX.XXX.XXX

SRL-S2 (2o nível): Serviço local para o escritório (Site2)

SRL-S2-2n1:

272
SRL-S2-2n2:

PBX-S2: Serviço local para o escritório (Site2)

PBX-S2-1:

PBX-S2-2:

GWT-S2: Serviço local para escritório (Site2)

GWT-S2: XXX.XXX.XXX.XXX

SRL-S3 (2o nível): Serviço local para o escritório (Site3)

SRL-S3-2n1:

SRL-S3-2n2:

PBX-S3: Serviço local para o escritório (Site3)

PBX-S3-1:

PBX-S3-2:

GWT-S3: Serviço local para escritório (Site3)

GWT-S3: XXX.XXX.XXX.XXX

Rede (ou VLAN) de telefonia

Telefones IP Site1: Serviço local para o escritório

l
Rede IP: XXX.XXX.XXX.XXX/24

Telefones IP Site2: Serviço local para o escritório
Os telefones podem ter
endereço IP “não Rede IP: XXX.XXX.XXX.XXX/24
roteável” (RFC-1718),
desde que haja rota e
Telefones IP Site3: Serviço local para o escritório
não haja NAT entre os
demais dispositivos de
Rede IP: XXX.XXX.XXX.XXX/24
telefonia.
QoS da camada 2

Recomendável criação de VLAN para telefonia. Ou mesmo o uso de switch separado.

Priorização de quadros nos switches não necessário, mas também pode ser aplicável.

QoS da camada 3

Amplamente recomendável a priorização de pacotes de voz (e vídeo).

QoS entre escritórios é responsabilidade da equipe de Engenharia.

QoS interno a cada escritório não necessário, mas também pode ser aplicado.

Alimentação dos telefones
Capítulo 10 - Anexos

DADO: os telefones IP existentes no estoque são antigos e não suportam PoE.

Se houver, nas baias, ponto de energia assegurado por nobreaks, utilizar esses pontos para
alimentação dos telefones IP.

Novas aquisições de telefones devem considerar PoE e também a compra de Switches PoE.

273
dAnexo 2 – Configuração de firewall
Esse guia apresenta as regras de firewall que devem ser abertas para cada componente do
fone 2012. O ambiente é composto por quatro tipos de componentes, sendo:

11 SRC – SIP Router Central;

11 SRL – SIP Router Local;

11 GWT – Gateway Transparente;

11 PBX-IP – Private Branch Exchange-Internet Protocol.

SRC – SIP Router central
Gerencia a tabela ENUM global dos participantes do Fone@2012. Responsável por rotear as
sinalizações SIPs entre os participantes e controle de DNS na zona ENUM. Pode interagir com
SRL e GWT, SIP e DNS e outros peerings externos. Ambiente composto por duas máquinas
para contingência.

IPs do SRC
SRC-DF: 200.130.35.113
SRC-RJ: 200.143.193.54

A seguir, exemplo em pseudo linguagem de firewall. SRC conectado com SRL e GWT. O SRL já
realiza controle das chamadas permitindo somente sinalização entre peerings autorizados.
Para facilitar as regras de firewall, serão liberadas somente as portas de SRL e GWT.

Sentido Internet > DMZ

;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP
permitir protocolo UDP origem INTERNET porta 5060,5071 destino SRC-DF,SRC-RJ porta
5060
;;
;; RTP -- NÃO REALIZA MIDIA PROXY.
;;
;; ZONE-TRANSFER e consultas DNS
permitir protocolo UDP,TCP origem INTERNET porta 53,>1024 destino SRC-DF,SRC-RJ
;;
;; NTP
permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino SRC-DF,SRC-RJ
porta 123
;; GERENCIA do ambiente
permitir protocolo TCP origem REDE_GERENCIA destino SRC-DF,SRC-RJporta 22,80,443
;; GERENCIA do ambiente
permitir protocolo udp origem REDE_GERENCIA_NMS destino SRC-DF,SRC-RJ porta 161
Serviço fone@RNP

274
SentidoMZ > Internet

alguns ADMs de firewall permitem tudo do SRV - > Internet
;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP
permitir protocolo UDP origem SRC-DF,SRC-RJ porta 5060 destino INTERNET porta
5060,5071
;; RTP -- NAO REALIZA
;; DNS-QUERY E ZONE TRANSFER
permitir protocolo UDP,TCP origem SRC-DF,SRC-RJ porta 53,>1023 destino INTERNET
porta 53,>1023
;; GERENCIA
permitir protocolo UDP origem SRC-DF,SRC-RJ destino IP-SYSLOG porta 514

SRL – SIP router local
Gerencia a tabela ENUM local da instituição e recebe cópias das tabelas do serviço central.
Responsável por rotear as sinalizações SIPs no âmbito local da instituição, podendo ser inte-
grado com PBX-IP, GWT e outros proxys/Gateways SIP, como (AudioCodes, Asterisk, Central
IP, Provedor SIP externo. Exemplo: VONO etc.). Pode realizar Realiza Media-Proxy. Ambiente
composto por duas máquinas para contingência. Exemplo: em pseudo linguagem de firewall.
SRC conectado com SRL e GWT. O SRL já realiza controle das chamadas permitindo somente
sinalização entre peerings autorizados. Para facilitar as regras de firewall, será liberado
somente as portas de SRL e GWT.

SentidoInternet > DMZ

;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP
permitir protocolo UDP origem SRC-DF,SRC-RJ porta 5060 destino SRL1,SRL2 porta
5060
;;
;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP
permitir protocolo UDP origem INTERNET porta >1024 destino SRL1,SRL2 porta RANGE
50000-60000
;;
;; ZONE-TRANSFER e consultas DNS
permitir protocolo UDP,TCP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp, GWT destino
SRL1,SRL2 porta 53
;;
;; NTP
Capítulo 10 - Anexos

permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino SRL1,SRL2
porta 123
;; GERENCIA do ambiente
permitir protocolo TCP origem REDE_GERENCIA destino SRL1,SRL2 porta 22,80,443
;; GERENCIA do ambiente
permitir protocolo udp origem REDE_GERENCIA_NMS destino SRL1,SRL2 porta 161

275
SentidoMZ > Internet

;; alguns ADMs de firewall permitem tudo do SRV - > Internet
;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP
permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino PBX-IP-m1, PBX-IP-m2,
PBX-IP-vrrp porta 5060
permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino GWT porta 5071
permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino [CASO EXISTA OUTROS\
PROXYS LOCAIS, ADICONAR AQUI]
;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP
permitir protocolo UDP origem SRL1,SRL2 destino INTERNET porta RANGE 50000-60000
porta >1023
;; DNS-QUERY E ZONE TRANSFER
permitir protocolo UDP,TCP origem SRL1,SRL2 porta 53,>1023 destino PBX-IP-m1, PBX-
IP-m2, PBX-IP-vrrp, GWT porta 53,>1023
;; GERENCIA
permitir protocolo UDP origem SRL1,SRL2 destino IP-SYSLOG porta 514

GWT – Gateway transparente
O GWT faz o roteamento de menor custo de forma transparente entre a instituição,
FONE@RNP e PSTN local. Esse equipamento também realiza o Media-Proxy.

Em um momento pertinente, o administrador encontrará os seguintes parâmetros a
serem configurados:

11 DNS: Zone Transfer do SIP-Router (Local ou Central), dependendo da configuração;

11 TCP/UDP 53: Realiza o DNS-Forward para os DNS da instituição;

11 SIP: udp: 5071;

11 RTP: udp: 10.000 até 20.000;

11 IP-GWT: Definido pela instituição;

11 IP-DNS_RECURSIVO1: DNS Recursivo da instituição;

11 IP-DNS_RECURSIVO2: DNS Recursivo da instituição;

11 IP-NTP1: definido pela instituição: Exemplo: ntp.pop-sc.rnp.br, ntp.cais.rnp.br,
ntp.intituição.br;

11 IP-NTP2: definido pela instituição: Exemplo: ntp.pop-sc.rnp.br, ntp.cais.rnp.br,
ntp.intituição.br;

11 REDE_GERENCIA: rede de gerência do ambiente;

11 REDE_GERENCIA_NMS: rede ou IP da estação de gerência SNMP Exemplo: cacti, Nagios,
Dude, WhatsUP etc.;
Serviço fone@RNP

11 IP-SYSLOG: permitir exportar logs do sistema para outra máquina, caso necessário.
Exemplo em PSEUDO linguagem de firewall o GWT Conectado ao SRC. Caso o GWT
conecte ao SRL, basta trocar os IPs de SRC-DF e SRC-RJ pelos respectivos IPs do SRL.

276
SentidoInternet > DMZ

;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP
permitir protocolo UDP origem SRC-DF,SRC-RJ porta 5060 destino IP-GWT porta 5071
;;
;; RTP
;; OBS: caso o firewall possua suporte a SIP/RTP, basta habilitar as regras do SIP,
que as demais
;; serão abertas automaticamente
permitir protocolo UDP origem INTERNET porta >1023 destino IP-GWT porta RANGE
10.000-20.000
;;
;; ZONE-TRANSFER e consultas DNS
permitir protocolo UDP,TCP origem SRC-DF,SRC-RJ porta 53 destino IP-GWT
;;
;; DNS FORWARD para DNS da instituição, retorno das requisições
permitir protocolo UDP,TCP origem IP-DNS_RECURSIVO1,IP-DNS_RECURSIVO2 porta 53
destino IP-GWT
;;
;; NTP
permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino IP-GWT porta
123
;; GERENCIA do ambiente
permitir protocolo TCP origem REDE_GERENCIA destino IP-GWT porta 22,80,443
;; GERENCIA do ambiente
permitir protocolo udp origem REDE_GERENCIA_NMS destino IP-GWT porta 161

SentidoMZ > Internet

;; alguns ADMs de firewall permitem tudo do SRV - > Internet
;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP
permitir protocolo UDP origem IP-GWT porta 5071 destino SRC-DF,SRC-RJ porta 5060
;; RTP
;; OBS: caso o firewall possua suporte a SIP/RTP, basta habilitar as regras do SIP,
que as demais
;; serão abertas automaticamente
permitir protocolo UDP origem IP-GWT porta RANGE 10.000-20.000 destino INTERNET
porta >1023
;;
Capítulo 10 - Anexos

;; DNS FORWARD para DNS da instituição, retorno das requisições
permitir protocolo UDP origem IP-GWT destino IP-DNS_RECURSIVO1,IP-DNS_RECURSIVO2
porta 53
;; NTP
permitir protocolo UDP origem IP-GWT destino IP-NTP1,IP-NTP2 porta 123
;; GERENCIA
permitir protocolo UDP origem IP-GWT destino IP-SYSLOG porta 514
277
PBX IP
PBX IP responsável pelo AAA dos ramais SIP, gerenciamento do aprovisionamento dos Tele-
fones, Catálogo, Relatórios etc. Para telefones corporativos da Instituição. Ambiente composto
por duas máquinas para contingência, que compartilham um IP Virtual para rápido failover.
Esse componente somente pode falar com o SRL. Pode fazer Media-Proxy, se habilitado.

SentidoInternet > DMZ

;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
;;
;; SIP -- INVITE
permitir protocolo UDP origem SRL1,SRL2 porta 5060 destino PBX-IP-m1, PBX-IP-m2,
PBX-IP-vrrp porta 5060
;; SIP -- INVITE/REGISTER -- TELEFONES
permitir protocolo UDP origem REDE_TELEFONES_IPS_INSTITUICAO destino PBX-IP-m1,
PBX-IP-m2, PBX-IP-vrrp porta 5060
;;
;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP
permitir protocolo UDP origem INTERNET porta >1024 PBX-IP-m1, PBX-IP-m2, PBX-IP-
vrrp porta RANGE 50000-60000
;;
;; ZONE-TRANSFER e consultas DNS
permitir protocolo UDP,TCP origem SRL1,SRL2 porta 53 destino PBX-IP-m1, PBX-IP-m2,
PBX-IP-vrrp
;;
;; DNS FORWARD para DNS da instituição, retorno das requisições
permitir protocolo UDP,TCP origem IP-DNS_RECURSIVO1,IP-DNS_RECURSIVO2 porta 53
destino PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp
;;
;; NTP
permitir protocolo UDP origem IP-NTP1,IP-NTP2 porta 123,>1023 destino PBX-IP-m1,
PBX-IP-m2, PBX-IP-vrrp porta 123
;; GERENCIA do ambiente
permitir protocolo TCP origem REDE_GERENCIA destino PBX-IP-m1, PBX-IP-m2, PBX-IP-
vrrp porta 22,80,443
;; GERENCIA do ambiente
permitir protocolo udp origem REDE_GERENCIA_NMS destino PBX-IP-m1, PBX-IP-m2, PBX-
IP-vrrp porta 161

SentidoDMZ > Internet

;; alguns ADMs de firewall permitem tudo do SRV - > Internet
;; PERMITIR CONEXÃO TCP ESTABELECIDAS
permitir conexoes estabelecidas
Serviço fone@RNP

;;
;; SIP
permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 destino
SRL1,SRL2 porta 5060
permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 5060 destino

278
REDE_TELEFONES_IPS_INSTITUICAO
;; RTP -- SE HABILITADO MEDIA PROXY e sem SUPORTE FIREWALL SIP/RTP
permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta RANGE 50000-
60000 destino INTERNET porta >1023
;; DNS-QUERY E ZONE TRANSFER
permitir protocolo UDP,TCP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp porta 53,>1023
destino SRL1,SRL2 porta 53,>1023
;; DNS FORWARD para DNS da instituição, retorno das requisições
permitir protocolo UDP,TCP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp destino IP-DNS_
RECURSIVO1,IP-DNS_RECURSIVO2 porta 53
;; GERENCIA
permitir protocolo UDP origem PBX-IP-m1, PBX-IP-m2, PBX-IP-vrrp destino IP-SYSLOG
porta 5140 2 –

dAnexo 3 – Instalação manual do SRL
O SIP Router pode ser instalado via configuração manual ou através de imagem disponível
de VMWare.

A seguir, é detalhado o procedimento manual.

Instalação manual
Para realizar a instalação manualmente, deve ser informado qual máquina vai ser instalada,
1 ou 2. Quando o componente for operar sem redundância, podemos informar que está se
instalada a máquina 1 e, quando solicitado na instalação o IP da máquina vizinha, informar
o mesmo IP. A configuração do host e da redundância entre as duas máquinas finais serão
aplicadas na interface gráfica.

Particionamento
É recomendado o uso de LVM nas partições para facilitar futuras expansões de disco caso
sejam necessárias. O particionamento da máquina é recomendado que seja feito utilizando
LVM seguindo o modelo a seguir:

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg--root-lv--root 1.9G 174M 1.6G 10% /
/dev/mapper/vg--root-lv—tmp1.9G 35M 1.8G 2% /tmp
/dev/mapper/vg--root-lv—usr3.7G 495M 3.0G 14% /usr
/dev/mapper/vg--root-lv—var3.7G 104M 3.4G 3% /var
/dev/mapper/vg--root-lv--var--lib 22G 237M 21G 2% /var/lib
/dev/mapper/vg--root-lv--var--log 15G 180M 14G 2% /var/log

Configuração pacotes Linux
Capítulo 10 - Anexos

Adicionar no arquivo /etc/apt/sources.list as seguintes entradas:

deb http://debian.pop-sc.rnp.br/debian/ squeeze main
deb-src http://debian.pop-sc.rnp.br/debian/ squeeze main
deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

279
# squeeze-updates, previously known as ‘volatile’
deb http://debian.pop-sc.rnp.br/debian/ squeeze-updates main
deb-src http://debian.pop-sc.rnp.br/debian/ squeeze-updates main
# AG Projects software
deb http://ag-projects.com/debian stable main
deb-src http://ag-projects.com/debian stable main

Atualizar a base de pacotes do Sistema Operacional e instalar a chave para o repositório do
Media Proxy e pacotes requeridos para realizar a instalação:

apt-get update
cd /usr/local/src
wget http://download.ag-projects.com/agp-debian-gpg.key
apt-key add agp-debian-gpg.key
apt-get install rsync vim

Sistema Core e Web
Para realizar a instalação do SRL, executar os seguintes comandos:

cd /usr/local/src/
wget http://rep.fone2012.pop-sc.rnp.br/fone2012/SRL/APP/core/SRL-core-last-stable.
tar.gz
wget http://rep.fone2012.pop-sc.rnp.br/fone2012/SRL/APP/web/SRL-web-last-stable.
tar.gz
tar zxvf SRL-core-last-stable.tar.gz
tar zxvf SRL-web-last-stable.tar.gz
cd SRL
./update_scripts.sh

É esperado ocorrer erro na versão 1.0.0, na cópia do “/var/lib/backup/local-config.m4.ORIGINAL”.

Opensips
É necessário realizar a compilação do OpenSIPs e inicializar a base de dados. O script de
instalação vai baixar as dependências de compilação e uso, solicitando as senhas do MySQL
e LDAP. Guarde-as para posterior uso.

Tempo estimado: 10 minutos, dependendo do tempo da rede e processamento do host.
Para isso, executar o seguinte procedimento:

cd /usr/local/SRL/install
./pacotes_debian_geral.sh

Ao instalar, o postfix deve ser configurado como “local-only”, conforme tela a seguir:
Serviço fone@RNP

280
l
Aceitar instalar mesmo
não autenticado os
APT-GET INSTALL.

Após será solicitado o nome do host para o SRL. É importante que esse nome seja FDQN
para que o SMTP da instituição possa trabalhar corretamente.

A instalação do OpenSIPs para o SRL é disparada através do seguinte comando:

cd /usr/local/SRL/install
./install_opensips.sh 0

Media proxy
Para disparar a instalação do Media Proxy, devem ser executados os seguintes comandos:

cd /usr/local/SRL/install
./install_mediaproxy.sh

Configuração inicial
Para realizar a configuração inicial, deve ser executado o procedimento a seguir respon-
dendo as perguntas conforme forem sendo mencionadas. No final, a máquina estará insta-
lada e pronta para ser configurada via interface gráfica:

cd /usr/local/SRL/install
./init_sistema.sh
____ ____ _
/ ___|| _ \| |
\___ \| |_) | |
___) | _ <| |___
Capítulo 10 - Anexos

|____/|_| \_\_____|
Versao 1.0.0 / 2012/12/18
SRL Install
Entre com as informacoes do Host
SRL Servidor (1 ou 2): 1
IP da SRL_M1: 10.255.255.10

281
Digite o IP da SRL_M2 (VIZINHO): 10.255.255.11
Defina o dominio [voip.rnp.br]: fone.rnp.br
Defina o LDAP DN [dc=fone,dc=rnp,dc=br]:
Inicializar MySQL (S/N):S
*** DB:MySQL ***
Digite a senha de root do MySQL(Definida na Instalacao do MySQL)
MySQL ROOT PW:
Crie uma senha para os acessos ao MySQL
MySQL USER PW:
LDAP
Inicializar LDAP (S/N):S
*** LDAP ***
Crie uma nova senha para o LDAP
SENHA LDAP ADMIN: Senha para replicacao- ** LDAP ** Ambas IGUAIS em M1 e M2
LDAP REPLICACAO PW:
OPENSSL_CONF: Houve alteracoes
md5sum: /var/lib/backup/last/openssl.cnf.tar.gz: No such file or directory
Nova versao, arquivar e atualizar last - openssl.cnf -
Jah Arquivado - local-config.m4 -
OPENSSL_CONF: Reiniciando..
rm /etc/apache2/apache.pem
rm: cannot remove `/etc/apache2/apache.pem’: No such file or directory
Gerando certificado...
Generating a 1024 bit RSA private key
.......................................++++++
...........++++++
writing new private key to ‘/etc/apache2/apache.pem’
-----
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and
create self-signed certificates.
Run ‘/etc/init.d/apache2 restart’ to activate new configuration!
Enabling module rewrite.
Run ‘/etc/init.d/apache2 restart’ to activate new configuration!
Inicializando OpenSIPS
stty: standard input: Invalid argument
stty: standard input: Invalid argument
stty: standard input: Invalid argument
Inicializando LDAP...
Stopping OpenLDAP: slapd.
Starting OpenLDAP: slapd.
Inicializando LDAP...
ldap_add: Already exists (68)
Serviço fone@RNP

update-rc.d: using dependency based boot sequencing
FIREWALL: Houve alteracoes
md5sum: /var/lib/backup/last/firewall.sh.tar.gz: No such file or directory
Nova versao, arquivar e atualizar last - firewall.sh -
Jah Arquivado - local-config.m4 -

282
FIREWALL: Reiniciando..
/etc/init.d/firewall restart
Reiniciando Firewall..
.
Restarting web server: apache2... waiting.

Observações:

11 Na seleção do campo “SRL Servidor (1 ou 2)”, caso esteja instalando uma segunda
máquina para operar de forma redundante, definir como sendo o servidor 2;

11 No campo “IP da SRL_M1”, selecionar o IP que deve ser configurado pela máquina.

11 No campo “IP da SRL_M2 (VIZINHO)”, selecionar o IP que a máquina vai fazer peering.

A partir daqui, retome o manual de instalação e configuração do SRL.

dAnexo 4 – Plano de Testes
Cada instalação do fone@RNP possui um caderno de testes específico. Para evitar várias
cópias de documentos similares, vamos apresentar a ideia geral que originou os formulários.

Antes e após cada instalação de um módulo do fone, será necessário testar se todos os tipos
de chamadas podem ser realizados normalmente.

Testes de chamadas (Checklist)
Tomemos um hipotético Campus A como referência.

Todos os tipos e direções de chamadas devem ser testadas, sempre que for cabível, con-
forme listadas a seguir.

Ligações dentro do Campus A

11 Ligações feitas a partir de telefones IP para telefones IP;

11 Ligações feitas a partir de telefones analógicos para telefones analógicos;

11 Ligações feitas a partir de telefones IP para telefones analógicos;

11 Ligações feitas a partir de telefones analógicos para telefones IP.

Ligações “entrantes” no Campus A

11 Ligações para dentro do Campus A, com origem na RTFC.

22 Para ramais IP;

22 Para ramais analógicos.

11 Ligações para dentro do Campus A, com origem em outro Campus da mesma instituição.

22 Para ramais IP;
Capítulo 10 - Anexos

22 Para ramais analógicos.

11 Ligações para dentro do Campus A, com origem em outro cliente do fone@RNP.

22 Para ramais IP;

22 Para ramais analógicos.

283
Ligações “saintes” do Campus A

11 Ligações para fora do Campus A, para outro Campus da mesma instituição.

22 A partir de telefones IP;

22 A partir de telefones analógicos.

11 Ligações para fora do Campus A, para outra instituição do fone@RNP no mesmo DDD.

22 A partir de telefones IP;

22 A partir de telefones analógicos.

11 Ligações para fora do Campus A, para outra instituição do fone@RNP em outro DDD.

22 A partir de telefones IP;

22 A partir de telefones analógicos.

11 Ligações para fora do Campus A, mas dentro da mesma cidade.

22 A partir de telefones IP para números locais na RTFC.

33 Celulares;

33 Fixos.

22 A partir de telefones analógicos para números locais na RTFC, celulares ou fixos.

33 Celulares;

33 Fixos.

22 Ligações para fora do Campus A, para números na RTFC em outro código de área

33 Celulares;

33 Fixos.

22 A partir de telefones IP para números DDD na RTFC

33 Celulares;

33 Fixos.

22 A partir de telefones analógicos para números DDD na RTFC

33 Celulares;

33 Fixos.

Ligações para serviços especiais

11 1XX

11 1XX XXXX

11 0X00 XXXXXXX

11 9090 XXXXXXXX

11 90CA XXXXXXXX

Esses testes devem ser repetidos a cada modificação no serviço de telefonia, em todos os
sites dos clientes.
Serviço fone@RNP

284
dAnexo 5 – Ajuste de temporização do R2
Problema
Após a instalação do GWT 2.0, o tempo de comutação de uma ligação da PBX para a PSTN
com o kommuter habilitado estiver muito mais elevado que com o kommuter desabilitado.

Solução
Uma possível solução para esse problema é ajustar o comportamento da sinalização R2 que
vem por padrão configurada no GWT 2.0. Para tal, entre na configuração das placas aces-
sando a guia Sistema e menu “Configurações” > “Placas”.

Lembrete: para acessar o módulo de configuração Khomp, utilize as credenciais:

Usuário: config
Senha: config

l Entrar na aba Configuração, menu “Telefonia” > “Profiles” e copiar o Perfil R2.

Feche os jumpers e
insira em um slot PCI
do Servidor. Caso a
placa já venha instalada
fisicamente no GWT, é
importante que seja
feita a verificação do
jumper. Se essa
Capítulo 10 - Anexos

configuração não
estiver correta, a
ligação com o PABX e
com a operadora não
funcionará.

285
Alterar o nome do perfil para R2_PABX e ajustar os parâmetros Comportamento para fim
de número de destino para Enviar I15 e Timeout de recepção de MFC para frente para 1000.
Esses parâmetros podem ser ajustados conforme central integrada. Ao finalizar a configu-
ração clique em “Concluir”.
Serviço fone@RNP

Mapear o perfil recém-criado para a placa da PBX. Para tal, entrar na aba “Configuração”,
menu “Telefonia” > “Links E1”. Alterar o parâmetro Sinalização da placa PBX para o perfil
R2_PABX e clicar em Aplicar.

286
Reiniciar o serviço Khomp API Server, através da aba Monitoração, guia Serviços.

Para finalizar, entrar na guia “Sistema”, menu “Configurações” > “Ambiente”, aba Serviços
Habilitados e reiniciar o serviço Asterisk.
Capítulo 10 - Anexos

287
dAnexo 6 – Instalação do GWT com Servidor
+ Placa Digium
Pré-instalação
Antes de começar, certifique-se de ter disponíveis em sua instituição todas as informações
relacionadas a seguir.

Relação de materiais

11 1 placa TDM Digium modelo TE220 com duas interfaces E1, RJ45, com módulo de cancela-
mento de eco;

11 1 Servidor homologado e com automático após queda de energia, que a partir desse
momento será chamado de Gateway Transparente ou GWT;

11 1 Kommuter 10, modelo RJ45(figura 1), para alta disponibilidade da conexão com a opera-
dora, com 4 interfaces E1, RJ45 e uma interface USB utilizada para alimentação e comuni-
cação com o driver do Asterisk;

Kommuter 10
Serviço fone@RNP

Modelo RJ45

288
11 2 Baluns (figura 2) para balanceamento de impedância, possuindo um conector RJ45 de
um lado e 2 conectores BNC no outro lado;

11 2 cabos coaxiais, duplex, 75 Ohms com 1 ponta BNC e outra (IEC ou BNC), dependendo da
interface de conexão com a PSTN, devidamente identificados como C1 e C2;

11 2 cabos coaxiais, duplex, 75 Ohms com 1 ponta BNC e outra (IEC ou BNC), dependendo da
interface da PABX, devidamente identificados como C3 e C4;

11 1 Cabo RJ45, de tamanho que atenda a necessidade de seu ambiente, para a conexão
entre balun e o Kommuter, devidamente identificado como C5;

11 1 Cabo RJ45, pode ser padrão de 1,5mt ou do tamanho da necessidade de seu ambiente,
para a conexão entre balun e o Kommuter, devidamente identificado como C6;

11 1 Cabo USB, devidamente identificado como C7. Na caixa do Kommuter já contém um no
tamanho padrão, para conexão Kommuter > Servidor;

11 2 cabos RJ45, 1,5mt que servirá para a conexão do Kommuter com o Servidor, devida-
mente identificados como C8 e C9;

11 Servidor conectado à rede local.

Instalação da placa e1
A placa para telefonia digital, utilizada para comunicação do servidor com a rede de telefonia
pública convencional (PSTN) e com o PABX, vem configurada de fábrica para o padrão T1.
Antes de instalá-la no servidor é necessário configurá-la para o padrão E1. Para isso, antes ins-
talar a placa no GWT será necessário fechar os jumpers J1-J2 e J3-J4, no local indicado a seguir:

Capítulo 10 - Anexos

289
Conexão entre GWT, KOMMUTER, PABX e PSTN
Inicialmente é feita a identificação do tipo de conector. Observe na figura a seguir qual o tipo
de conector sua central possui:

BCN

IEC

Mini-IEC

Antes de continuar a instalação, certifique-se de que está de posse de todos os
cabos, compatíveis com o seu ambiente de telefonia.

11 BNC: conector tipo BNC, tamanho “grande”, tipo encaixe. Tamanho de 5cm;

11 IEC: conector tipo IEC, tem um tamanho menor que o BNC, sendo uma extremidade de
rosca (2cm) com um antiderrapante;

11 Mini-IEC: conector tipo mini-IEC. Em sua extremidade de conexão tem formato de rosca,
na extremidade dessa rosca ele tem formato de uma “porca” (hexagonal), diferente do IEC.

Na próxima figura, observa-se o diagrama de como deve ficar a conexão dos cabos entre os
equipamentos (Atenção, a seguir está ilustrado um cenário possível, entre vários outros).

BALUN BALUN
PSTN B1 B1 PBX
C1 C3
RX RX RX RX
TX TX TX TX
C2 RJ-45 RJ-45 C4
C5
KOMMUTER 10 (ISDN)
C6
l
Faça a identificação dos
USB A B C D cabos de acordo com a
descrição anterior.
Lembre-se de
C7 C8 C9
identificar os dois lados
SERVIDOR ou GATEWAY TRANSPARENTE do cabo, para que
posteriormente seja
USB LAN 2 1 Placa E1
possível o suporte em
caso de problemas.
REDE LOCAL
C10

O Kommuter é o componente utilizado para prover alta disponibilidade do ambiente, em
caso de falha da máquina (exemplo: software, hardware e falha elétrica), esse equipa-
mento vai chavear automaticamente da PSTN para a PBX convencional Porta (A) PARA (D).
Serviço fone@RNP

O Kommuter possui LEDs verdes, que quando está aceso indica que as chamadas estrarão
passando pelo GWT, e os LEDs vermelhos, que indicam que as chamadas seguem direto
entre PABX e a PSTN.

290
A conexão deve seguir o seguinte padrão:

11 Cabo coaxial 1, identificado como C1 (PSTN-RX > B1-TX);

11 Cabo coaxial 2, identificado como C2 (PSTN-TX > B1-RX);

11 Cabo coaxial 3, identificado como C3 (PBX-RX > B2-RX);

11 Cabo coaxial 4, identificado como C4 (PBX-TX > B2-TX);

11 Cabo RJ-45, identificado como C5 (B1-RJ45 > KOMMUTER-PORTA A);

11 Cabo RJ-45, identificado como C6 (B2-RJ45 > KOMMUTER-PORTA D);

11 Cabo USB, identificado como C7 (KOMMUTER-USB > Servidor-USB);

11 Cabo RJ45, identificado como C8 (KOMMUTER-PORTA B > PLACA DIGIUM: PORTA 2);

11 Cabo RJ45, identificado como C9 (KOMMUTER-PORTA C > PLACA DIGIUM: PORTA 1);

11 Cabo RJ45, identificado como C10 (LAN > Rede Local).

Note que após a ligação completa dos cabos conforme descrito anteriormente, o serviço de
telefonia deve estar funcionando exatamente como antes da ligação dos cabos. Além disso,
mesmo durante a instalação do servidor GWT o serviço de telefonia também não deve
sofrer nenhum prejuízo.

Instalação do servidor
a. Instale o servidor no rack;

b. Conecte o cabo de rede local;

c. Ligue o Servidor.

d. Inicialize o servidor com o DVD de instalação do módulo de Gateway Transparente.

e. Quando iniciar, aparecerá a tela a seguir. Escolha a primeira opção e tecle “ENTER”. Na
próxima tela aguarde a carga completa dos componentes, para prosseguir a instalação:

Capítulo 10 - Anexos

291
l
Se após o término o
GWT não reiniciar e
ficar parado no status
da figura 15, desligue e
ligue o GWT para que
seja concluída a tarefa.

A próxima figura apresenta um alerta, o qual lembra que ao prosseguir com a instalação todos
os dados no servidor serão perdidos, pois este será formatado. Caso queira continuar com a
instalação, certifique-se de que não há dados importantes no servidor. Informa também que
por questões de segurança será solicitado que confirme seu desejo de continuar.

Tecle ENTER (“EXIT”), para continuar.

Conforme alertado na tela anterior, a confirmação é solicitada.
Serviço fone@RNP

292
Digite GWT e tecle “ENTER”.

Aparecerá mais um aviso informando sobre a exclusão de dados e perguntando se realmente
é essa ação que você quer executar.

Tecle “ENTER” – “YES”.

Quando confirmar, aparecerá a tela de instalação (figura 11), informando o tempo de instalação.
Esse tempo pode variar de 40 minutos até 2 horas.
Capítulo 10 - Anexos

293
Com o progresso da instalação, as próximas telas serão:
Serviço fone@RNP

294
Após o término da instalação, a tela ficará assim.

Em seguida, o servidor será reiniciado automaticamente, mas em alguns casos, por dife-
renças de equipamento de hardware, essa ação pode não ser executada. Se ocorrer falha ao
reiniciar o servidor, a tela ficará como mostra a figura anterior. Isso significa que a instalação
foi concluída, porém não reiniciou automaticamente. Capítulo 10 - Anexos

295
Essa é a tela padrão do GWT (Gateway Transparente). Observe que nela está informado seu
nome e o domínio ao qual pertence esse GWT, o endereço IP, Versão do Core (núcleo da
solução) e do Ambiente web (interface gráfica da solução).

A partir desse ponto, os procedimentos são os mesmos aos apresentados no capítulo 5:
Gateway Transparente (GWT) e Gateway Transparente Analógico (GWTa), a partir da sessão 2.

dAnexo 7 – Expressões regulares: RegEx
Não é nossa intenção esgotar o assunto sobre expressão regular. Até porque há um livro
inteiro dedicado a isso: http://regex.info/book.html.

Mas vemo-nos obrigados a, minimamente, apresentar o conceito básico e algumas regras
úteis, muito utilizadas na configuração dos dispositivos do fone@RNP.

Expressões regulares são utilizadas para representar toda uma variação possível de um
conjunto de caracteres.

O fone@RNP usa Expressões Regulares (RegEx) para classificar e diferenciar os números
para onde os usuários estão discando: discagem local ou a distância, celular ou fixo etc.
Serviço fone@RNP

296
Regras mínimas
. Ponto indica qualquer caractere, em qualquer quantidade.

^4 Acento circunflexo indica início da expressão.

25 Número (ou sequência de números) fora de marcadores indica o próprio número ou seq.

[135] Números entre colchetes indica um grupo de possíveis caracteres nessa posição.

[1-9] Traço indica “todos os valores entre 1 e 9, inclusive, nessa posição.

{2} Chaves indica o tamanho da string do “colchete” imediatamente anterior.

$ Dólar indica o fim da string.

Exemplos
^0.

=> Números começados por 0 seguidos por qualquer sequência de outros números.

^[2-5][0-9]{7}$

=> Números de 8 dígitos, onde o primeiro dígito está entre 2 e 5, inclusive. Ou seja, números
locais fixos.

^2000[0-9]{4}$

=> Números de 8 dígitos que começam com 2000, onde os 4 últimos dígitos podem variar de
0000 até 9999.

^0[1-9][0-9][7-9][0-9]{7}$

=> Números que começam com 0 + 2 dígitos, onde o primeiro não pode ser 0 (código de
área) + 8 dígitos, onde o primeiro começa entre 7 e 9, inclusive (números de celulares). Ou
seja, ligação a distância para celulares.

Capítulo 10 - Anexos

297
Serviço fone@RNP

298
Alex Galhano Robertson
PauloEngenheiro de Telecomunicações
Cayres possui e
graduação no curso
Mestre em EngenhariaSuperior
de Redesde
comTecnologia
ênfase em Comunicações
em Processa-
Multimídia, ambos pela Universidade
mento de DadosFederal Fluminense (UFF).
pela Universidade para
o Desenvolvimento do Estado e da Região
Edison Tadeu Melo Graduado em(UNIDERP),
do Pantanal Ciências daespecialização
Computação
e mestre em Sistemasem de Computação
Análise pela pela
de Sistemas Universidade
Universi-
Federal de Santa Catarina.
dade Federal de Mato Grosso do Sul
(UFMS) e mestrado em Ciências da Computação pela Universi-
Estefania
dade Borm
Federal Graduada
do Rio emSul
Grande do Sistemas
(UFRGS).de Informação
Atualmente pela
é coor-
Universidade
denador do Federal
Núcleo de
deSanta Catarina
Educação a -Distância
UFSC. Pós-Graduanda
- NEaD da
em Sistemas de Telecomunicações pela ESAB.
Faculdade da Indústria do Sistema FIEP. Sócio-diretor da CPP
Consultoria e Assessoria em informática Ltda. Tem experiência
Guilherme
na Rhodem
área de Ciência Bacharel emcom
da Computação, Informática
ênfase empela UFPEL
Engenharia
(1999),
de MestreProfessor
Software. em Ciências da Computação
titular pelagraduação
em cursos de UFSC (200).
e
pós-graduação ministrando disciplinas de desenvolvimento de
Helder Vitorino
sistemas Mestre
desde 1995. em Gestão
Instrutor do Conhecimento
de treinamento na linguageme
Tecnologia
Java da Informação
de programação junto aopela Universidade
CITS em Curitiba e naCatólica
ESR-RNP.de
Brasília. Possui MBA em Gestão de Projetos, Especialização
em Engenharia de Software.

Jonatan Hartmann Matschulat Engenheiro de software com
especialidade em desenvolvimento web e móvel. Graduado
em Sistemas de Informação pela UFSC em 2010.

Luís Fernando Cordeiro Possui graduação em Sistemas de
Informação (2012) e especialização em Engenharia e Arqui-
tetura de Software (2015).

Murilo Vetter Graduado em Ciências da Computação pela
Universidade Federal de Santa Catarina - UFSC (2008). Mestre
em Ciências da Computação pela Universidade Federal de
Santa Catarina - UFSC (2015).

Paulo Alexandre de O Brandtner Graduado em Sistemas
de Informação pela Universidade Federal de Santa Catarina.

Thiago Maluf Bacharel em Ciência da Computação pela
UFRJ e detentor da certificação DCAP.

Wescley Patrick da Silva Graduado em análise e desenvol-
vimento de sistemas, possui especialização em segurança
de redes de computadores, é certificado em DELL DCSE
Foundation 2010, ITIL Foundation, Digium dCCA.
Alex Galhano Robertson Engenheiro de Telecomunicações e A RNP – Rede Nacional de Ensino
Mestre em Engenharia de Redes com ênfase em Comunicações
e Pesquisa – é qualificada como
Multimídia, ambos pela Universidade Federal Fluminense (UFF).
uma Organização Social (OS),
Edison Tadeu Melo Graduado em Ciências da Computação
sendo ligada ao Ministério da
e mestre em Sistemas de Computação pela Universidade
Federal de Santa Catarina. Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Estefania Borm Graduada em Sistemas de Informação pela
Universidade Federal de Santa Catarina - UFSC. Pós-Graduanda Programa Interministerial RNP,
em Sistemas de Telecomunicações pela ESAB. que conta com a participação dos
Guilherme Rhodem Bacharel em Informática pela UFPEL
ministérios da Educação (MEC), da

Serviço
(1999), Mestre em Ciências da Computação pela UFSC (200). Saúde (MS) e da Cultura (MinC).
O curso tem por objetivo capacitar profissionais das Pioneira no acesso à Internet no

LIVRO DE APOIO AO CURSO
Helder Vitorino Mestre em Gestão do Conhecimento e
Tecnologia da Informação pela Universidade Católica de instituições clientes da RNP na solução técnica de seu Brasil, a RNP planeja e mantém a

fone@RNP
Brasília. Possui MBA em Gestão de Projetos, Especialização
serviço de Voz sobre IP, o fone@RNP. O profissional rede Ipê, a rede óptica nacional
em Engenharia de Software.
será capaz de instalar, operar e manter em sua insti- acadêmica de alto desempenho.

Serviço fone@RNP V.2012
Jonatan Hartmann Matschulat Engenheiro de software com
tuição o conjunto de servidores que constituem a rede Com Pontos de Presença nas
especialidade em desenvolvimento web e móvel. Graduado
em Sistemas de Informação pela UFSC em 2010. de VoIP da RNP. Este livro tem o objetivo de apoiar 27 unidades da federação, a rede

V.2012
os profissionais na disseminação do conhecimento em tem mais de 800 instituições
Luís Fernando Cordeiro Possui graduação em Sistemas de
Informação (2012) e especialização em Engenharia e Arqui- suas organizações ou localidades de origem. conectadas. São aproximadamente
tetura de Software (2015). 3,5 milhões de usuários usufruindo
Murilo Vetter Graduado em Ciências da Computação pela de uma infraestrutura de redes
Universidade Federal de Santa Catarina - UFSC (2008). Mestre
Alex Galhano Robertson Luís Fernando Cordeiro avançadas para comunicação,
em Ciências da Computação pela Universidade Federal de
Santa Catarina - UFSC (2015). Edison Tadeu Melo Murilo Vetter computação e experimentação,
Estefania Borm Paulo Alexandre de O Brandtner que contribui para a integração
Paulo Alexandre de O Brandtner Graduado em Sistemas
Guilherme Rhodem Thiago Maluf entre o sistema de Ciência e
de Informação pela Universidade Federal de Santa Catarina.
Helder Vitorino Wescley Patrick da Silva Tecnologia, Educação Superior,
Thiago Maluf Bacharel em Ciência da Computação pela Jonatan Hartmann Matschulat
Saúde e Cultura.
UFRJ e detentor da certificação DCAP.

Wescley Patrick da Silva Graduado em análise e desenvol-
vimento de sistemas, possui especialização em segurança
de redes de computadores, é certificado em DELL DCSE
Foundation 2010, ITIL Foundation, Digium dCCA.

ISBN 978-85-63630-58-2

9 788563 630582

Sign up to vote on this title
UsefulNot useful