Serviço Fone@RNP

Thiago Maluf é bacharel em Ciência da Computação pela A RNP – Rede Nacional de Ensino
UFRJ com certificação DCAP pela Digium, atuante na área de

desenvolvimento de aplicações multimídias, principalmente e Pesquisa – é qualificada como
no setor de telefonia IP. Bolsista no Laboratório de Voz sobre uma Organização Social (OS),
IP da UFRJ, participou da criação do projeto fone@RNP. Atu-
almente é sócio e gerente de projetos da empresa presta- sendo ligada ao Ministério da
dora de serviços, CAM Tecnologia. A CAM Tecnologia, hoje, Ciência, Tecnologia e Inovação
é a empresa mantenedora do serviço fone@RNP, ofertando
suporte e ampliação do serviço. (MCTI) e responsável pelo
Programa Interministerial RNP,
Alex Galhano Robertson é Enge- que conta com a participação dos
nheiro de Telecomunicações (2005)
e Mestre (2010) em Engenharia de
ministérios da Educação (MEC), da
Serviço
redes, ambos pela Universidade Fede- O curso tem por objetivo capacitar profissionais das insti- Saúde (MS) e da Cultura (MinC).
ral Fluminense (UFF). É professor de
LIVRO DE APOIO AO CURSO

cursos de VoIP e tecnologias afins em tuições clientes da RNP na solução técnica de seu serviço Pioneira no acesso à Internet no
cursos extracurriculares na UFF e par- de Voz sobre IP, o fone@RNP. O profissional será capaz Brasil, a RNP planeja e mantém a
fone@RNP
ticipa de projetos de instalação de infraestrutura de redes
IP. Coordena projetos de desenvolvimento e instalação de de instalar, operar e manter em sua instituição o conjun- rede Ipê, a rede óptica nacional
Serviço fone@RNP
sistemas para troca de tráfego VoIP entre universidades do to de servidores que constituem a rede de VoIP da RNP. acadêmica de alto desempenho.
Brasil e entre redes nacionais de outros países. Participa ati-
vamente em projetos de modernização de sistemas de tele- Este livro inclui os roteiros das atividades práticas e o con- Com Pontos de Presença nas
fonia, de integração voz, vídeo e dados e de otimização de
teúdo dos slides apresentados em sala de aula, apoiando 27 unidades da federação, a rede
recursos de telecomunicações.
profissionais na disseminação deste conhecimento em tem mais de 800 instituições
suas organizações ou localidades de origem. conectadas. São aproximadamente
3,5 milhões de usuários usufruindo
Thiago Maluf de uma infraestrutura de redes

avançadas para comunicação,
Alex Galhano Robertson 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.
Ministério da
Cultura
Ministério da
Saúde
Ministério da
Educação
ISBN 978-85-63630-28-5 Ministério da

Ciência, Tecnologia
e Inovação
9 788563 630285
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
que conta com a participação dos
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
de uma infraestrutura de redes
computação e experimentação,
Saúde e Cultura.
Ministério da
Cultura
Ministério da
Saúde
Ministério da
Educação
Ministério da
e Inovação
Serviço
fone@RNP
Thiago Maluf
Alex Galhano Robertson
Serviço
fone@RNP
Thiago Maluf
Alex Galhano Robertson
Rio de Janeiro
Escola Superior de Redes
2013
Copyright © 2013 – 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

Coordenação
Luiz Coelho
Edição
Pedro Sangirardi
Coordenação Acadêmica de Mídias de Suporte à Colaboração Digital

Renato Duarte
Equipe ESR (em ordem alfabética)

Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Lourdes
Soncin, Luciana Batista, Luiz Carlos Lobato, Sergio Ricardo de Souza e Yve Abel Marcial.
Capa, projeto visual e diagramação

Tecnodesign
Versão
1.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
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 Maluf, Thiago.

Serviço fone@RNP / Thiago Maluf, Alex Robertson. – Rio de Janeiro: RNP/ESR, 2013.
228 p. : il. ; 28 cm.
Bibliografia: p. 211.
ISBN 978-85-63630-28-5
1. Redes VoIP – instalação e manutenção. 2. Protocolos de redes VoIP. 3. Asterisk

(software). 4. OpenSER (software). I. Robertson, Alex. II. Título.
CDD 004.65
Sumário
1. Introdução ao fone@RNP
Visão básica da RNP 1
Serviços na RNP 2
Serviço fone@RNP 3
GT-VoIP 4
Projeto VoIP4All 4
Serviço fone@RNP 5
Funcionalidades do serviço 5
Integração das instituições usuárias 5
Redução do custo das chamadas 6
Adoção de medidas de QoS para a qualidade de serviço 7
Composição do serviço fone@RNP 7
Endereçamento no serviço 7
Arquitetura do serviço nacional 8
Arquitetura do serviço local 9
Dispositivos VoIP 10
VoIP via Softphone 10
VoIP via ATA 10
VoIP via telefone IP 11
Gateway VoIP 11
Programa de Estatísticas Nacionais 11
Chamadas completadas por diferentes tipos de origem e destino 12
Ranking de uso para chamadas completadas por local 12
Motivos de não completamento 12
Estimativa de economia 13
iii
Roteiro de Atividades 1 15
Atividade 1.1 – Instalando o softphone 15
Atividade 1.2 – Configurando o telefone IP 18
Atividade 1.3 – Configurando o ATA 19
Atividade 1.4 – Efetuando chamadas com ATA, telefone IP e softphone 20
2. Tecnologia VoIP
Protocolo de iniciação de sessão – SIP 21
Funções do protocolo SIP 21
Conjunção com outros protocolos 22
Extensões ao protocolo SIP 23
Características do protocolo SIP 23
Elementos de uma rede SIP 24
User Agents (UA) 24
Servidor Proxy 26
Utilização do servidor proxy 26
Servidor de redirecionamento 27
Servidor de registro 28
Servidor de registro no fone@RNP 29
Mensagens SIP 30
Protocolo SDP 35
Anatomia do SDP 35
Negociando a sessão SDP 36
Mudando parâmetros da sessão 36
Real-time Transport Protocol (RTP) 37
Real-time Transport Control Protocol (RTCP) 39
Empacotamento da voz – codec 41
Codec 44
Codificação de forma de onda 44
Codificação paramétrica 44
Codificação híbrida 45
iv
Padrões de codificação de voz 45
G.711 46
G.729 46
G.723.1 47
iLBC 47
Características de escolha do codec 48
Atividade 2.1 – Capture e avalie as mensagens SIP 49
3. Princípios do serviço VoIP na instituição usuária

Bases de dados 54
Autenticação de usuários (ramais IP) 55
Gateway para telefonia convencional 55
Outros serviços 55
Distribuição dos serviços nas máquinas 1 e 2 57
Encaminhamento de chamadas ao serviço 58
Acesso ao serviço 60
Controle de chamadas não autorizadas 61
Adesão do serviço 62
Instalação e homologação do serviço 62
Fluxo de instalação e homologação 62
Execução do checklist 63
Instalação do serviço 63
Homologação do serviço 63
Atividade 3.1 – Instalação e homologação do serviço fone@RNP 66
4. Manutenção do sistema
Configuração de usuários e ramais IP 67
Busca de usuários ou ramais IP cadastrados 69
Modificação de um usuário ou ramal IP 71
Remover usuário ou ramal IP 72
Estatística e CDR 73
Princípios básicos da estatística e CDR 73
Contabilidade no serviço fone@RNP 74
v
Relatórios 76
Últimos dias 76
Chamadas por dia no mês 76
Durações da chamada por hora num dia 77
Motivo de desconexões das chamadas 78
Matriz de chamadas 79
Backup e restauração do sistema 79
Procedimentos de backup 80
Procedimentos de restauração 80
Atividade 4.1 – Manipulação de ramais no FÉJECA 81
Atividade 4.2 – Teste de chamadas local 81
Atividade 4.3 – Estatística 82
Atividade 4.4 – Backup do serviço 82
5. Serviço fone@RNP: ambiente nacional

Estrutura do ambiente nacional 83
DSER 85
Replicação do Slon 88
Proxy Externo 89
Estrutura local 90
FEGEN 91
Atividade 5.1 – Efetuando chamadas para outras instituições 93
Atividade 5.2 – Análise de log de chamadas 93
6. Proxy SIP – OpenSER

O que é OpenSER? 95
Características do OpenSER 96
Estrutura básica do OpenSER 96
Arquivo de configuração openser.cfg 97
Lógica de roteamento das mensagens 101
Funções básicas do OpenSER 102
vi
OpenSER no fone@RNP 106
Asterisk 107
Asterisk e Linux 107
Asterisk versus PABX 109
Funções do Asterisk 110
O que o Asterisk não é e não faz 111
Protocolos usados pelo Asterisk 112
Protocolo IAX 114
Arquitetura do Asterisk 117
Estrutura dos arquivos de configuração 121
Organização dos arquivos de configuração 123
Aplicações 124
Asterisk no fone@RNP 126
Atividade 6.1 – Análise do arquivo de configuração do OpenSER 127
Atividade 6.2 – Análise do arquivo de configuração do Asterisk 128
7. Softwares de apoio ao
ambiente local
LDAP 129
OpenLDAP 133
Instalação do OpenLDAP 135
RADIUS 135
FreeRADIUS 136
Instalação do FreeRADIUS 138
Slony-I 139
Instalação do Slony-I 140
PostgreSQL 141
Instalação do PostgreSQL 142
Manutenção das informações do PostgreSQL 143
MediaProxy 144
Instalação do MediaProxy 145
vii
Atividade 7.1 – Configurações PostgreSQL, OpenLDAP e MediaProxy 147
8. Introdução à telefonia
Distorções da telefonia 150
Tráfego e dimensionamento 150
Tráfego 151
Grau de Serviço (GoS) 151
Cálculo de canais e Tabelas de Erlang 151
Introdução a canais analógicos 152
Sinalização utilizada na telefonia analógica 152
On-hook (no gancho) 153
Off-hook (fora do gancho) 154
Dual Tone Multi Frequency (DTMF) 154
Gateway de voz sobre IP 156
Sinalização nos troncos 156
Loop start 157
Ground start 157
Kewl start 157
Introdução a canais digitais 158
Entroncamento digital 158
Hardware e interfaces para Asterisk 160
Conexões entre a interface VoIP e a telefonia convencional 161
Configurações preliminares à instalação da placa 162
Configuração da interface FXO 164
Configuração do canal Zapata no Asterisk 165
Configuração da interface E1/ISDN 167
Configuração do canal Zapata no Asterisk 168
Configuração da interface E1/MFC-R2 169
Configuração do canal Unicall no Asterisk 170
Atividade 8.1 – Identifique o status da sua interface antes da ativação 173
Atividade 8.2 – Ative a comunicação do serviço de telefonia com o serviço VoIP 173
Atividade 8.3 – Realização de testes 174
viii
9. Serviços extras no fone@RNP
IAX2: Protocolo VoIP alternativo 175
IAX2 em rede VoIP 177
Filtro transparente no fone@RNP 177
Serviço fone@RNP e conexões com a operadora 178
Filtro Transparente 178
Entroncamento SIP com operadoras e outros PABX IP 180
Vantagens do entroncamento SIP sobre o convencional E1 180
Formas de entroncamento VoIP: SIP x IAX 180
Modos de entroncamento: Proxy SIP x Gateway VoIP 180
Atividade 9.1 - Entroncando fone com PABX SIP 183
Atividade 9.2 - Configurando o Filtro Transparente 184
10. QoS e Troubleshooting

O que é QoS? 193
Parâmetros importantes 194
Sobre enlaces congestionados 195
Compressão de cabeçalho 196
Fragmentação e interposição de quadros 197
Modelos de QoS 198
IntServ – Integrated Services 198
DiffServ – Differentiated Services 198
Mecanismos de condicionamento de tráfego 199
Marcação de pacotes 199
Per Hop Behavior 200
Enfileiramento 200
Medindo o QoS 201
Mean Opinion Score 201
Modelo-E 202
Firewall e NAT 202
Troubleshooting 204
Registro de usuários e autenticação de SIP Requests 204
Gateway Asterisk 205
ix
Atividade 10.1 – Troubleshooting 207
Atividade 10.2 – Marcação dos pacotes de voz 209
Bibliografia 211
x
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 Projeto
de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital,
Governança de TI e Gestão de Identidade.
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 edu-
cacionais 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 conjunto 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ípi-
cos 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 pro-
blema, 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 sessão de apren-
dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor
busca incentivar a participação dos alunos continuamente.
xi
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 tem por objetivo capacitar profissionais das instituições clientes da RNP na solução
técnica de seu serviço de Voz sobre IP, o fone@RNP. A solução foi inicialmente desenvolvida
pelo Laboratório LabVoIP, da Universidade Federal do Rio de Janeiro (UFRJ), sob a coorde-
nação do professor Paulo Aguiar.
Ao final do curso o profissional será capaz de instalar, operar e manter em sua instituição o
conjunto de servidores que constituem a rede de Voz sobre IP da RNP, o fone@RNP.
A quem se destina
Este curso é destinado aos profissionais das instituições usuárias da RNP designados como
responsáveis técnicos pelo serviço fone@RNP em suas instituições.
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.
xii
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
xiii
Sobre os autores
Alex Galhano Robertson é Engenheiro de Telecomunicações (2005) e Mestre (2010) em
Engenharia de redes, ambos pela Universidade Federal Fluminense (UFF). É professor de
cursos de VoIP e tecnologias afins em cursos extracurriculares na UFF e participa de pro-
jetos de instalação de infraestrutura de redes IP. Coordena projetos de desenvolvimento
e instalação de sistemas para troca de tráfego VoIP entre universidades do Brasil e entre
redes nacionais de outros países. Participa ativamente em projetos de modernização de
sistemas de telefonia, de integração voz, vídeo e dados e de otimização de recursos de
telecomunicações.
Thiago Maluf é bacharel em Ciência da Computação pela UFRJ com certificação DCAP pela
Digium, atuante na área de desenvolvimento de aplicações multimídias, principalmente no
setor de telefonia IP. Bolsista no Laboratório de Voz sobre IP da UFRJ, participou da criação
do projeto fone@RNP. Atualmente é sócio e gerente de projetos da empresa prestadora de
serviços, CAM Tecnologia. A CAM Tecnologia, hoje, é a empresa mantenedora do serviço
fone@RNP, ofertando suporte e ampliação do serviço.
Renato Duarte é formado em Ciência da Computação pela UniCarioca e trabalha há treze

anos na área. Atualmente é responsável pela área acadêmica de Mídias de Suporte à Cola-
boração Digital e coordena a equipe de analistas das unidades da Escola Superior de Redes
da Rede Nacional de Ensino e Pesquisa (ESR-RNP). É responsável pela infraestrutura de TI
de apoio à coordenação da ESR, e pelo preparo e validação dos laboratórios para execução
das atividades práticas dos cursos da ESR.
xiv
1
Introdução ao fone@RNP
objetivos
Apresentar a RNP e os serviços disponibilizados aos seus clientes, com foco no serviço
fone@RNP, sua história e características.
conceitos
Panorama conceitual dos serviços oferecidos pela RNP, com ênfase no fone@RNP.
Visão básica da RNP

11 Rede Nacional de Ensino e Pesquisa (RNP). q
11 Criada em 1989 pelo Ministério da Ciência e Tecnologia (MCT).
A RNP é a primeira rede de acesso à internet no Brasil. Sua missão é promover o uso ino-
vador de redes avançadas no Brasil. Foi criada em 1989 pelo Ministério da Ciência e Tecno-
logia (MCT) com o objetivo de construir uma infraestrutura de rede internet nacional para a
comunidade acadêmica. A rede começou a ser montada em 1991. Em 1994, já atingia 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, o backbone RNP, como é chamado, possui pontos de
presença em todos os estados brasileiros.
A RNP oferece conexão gratuita à internet para instituições federais de ensino superior
ligadas ao Ministério da Educação (MEC), unidades de pesquisa federais ligadas ao MCT,
agências de ambos os ministérios e outras instituições de ensino e de pesquisa públicas e
privadas. Um universo estimado em mais de um milhão de usuários da comunidade acadê-
mica brasileira se beneficia dessa infraestrutura, que estimula o progresso da ciência e da
educação superior no país.
Capítulo 1 - Introdução ao fone@RNP
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 etc.), 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,
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 agregada
de 233,2 Gb/s, aumento de 280% em relação à capacidade agregada anterior. Nessa nova
rede, que é a sexta geração do backbone operado pela RNP, as velocidades multigigabits
1
(acima de 1 Gb/s) estão disponíveis para 24 dos 27 PoPs. A ampliação foi resultado de acordo
de cooperação com a empresa de telecomunicações Oi, que proverá à RNP infraestrutura 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 conexão de 1,45 Gb/s com a rede dessa iniciativa, que integra atualmente 15 países
da América Latina. Além disso, por meio de conexão de 20 Gb/s operada em parceria entre
a RNP e a Academic Network at São Paulo (ANSP), a rede Ipê se conecta a outras infraestru-
turas acadêmicas internacionais, como a norte-americana Internet2 e a europeia Géant, e à
internet comercial mundial.
Figura 1.1
Fonte:
website da RNP
(www.rnp.br).
Serviços na RNP
Os serviços são oferecidos a todos os clientes da RNP e a instituições parceiras ou que q
possuem algum projeto com a RNP.
11 Comunicação e colaboração.
11 Gestão de identidade.
11 Suporte à rede acadêmica.
11 Disponibilização de conteúdos digitais.
11 Hospedagem estratégica.
Serviço fone@RNP
11 Apoio a serviços.
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.
2
Os serviços disponibilizados pela RNP às suas organizações usuárias são o resultado de pro-
cessos de inovação e prospecção, de acordo com as necessidades dos clientes, 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 serviços da RNP são faci-
litar e promover a comunicação, a colaboração a distância e a disseminação de conhecimento.
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, classificadas da seguinte forma: Comunicação e Colaboração,
Disponibilização de Conteúdos Digitais, Gestão de Identidade, Hospedagem Estratégica e
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 e Telepresença.
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:
Comunidade Acadêmica Federada (CAFe) e Infraestrutura de Chaves Públicas para Ensino e
Pesquisa (ICPEdu).
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 infraestrutura de segu-
rança, física e lógica, para clientes estratégicos para o sistema nacional de CT&I, Cultura e
w Saúde, com garantias de disponibilidade e operação ininterrupta.

Para informações Apoio a serviços
específicas sobre cada
serviço, acesse http:// O Service Desk é uma instância de apoio, voltada à resolução de dificuldades que as institui-
www.rnp.br/servicos/.
ções clientes dos serviços possam encontrar em sua entrega, acesso ou utilização.
Serviço fone@RNP
GT-VoIP: q
11 Grupo de Pesquisa da UFRJ – LabVoIP.
11 Professor Paulo Aguiar.
11 Domínio da arquitetura VoIP com H.323, SIP, Gateways Cisco e Asterisk.
11 Pesquisa sobre Qualidade da Chamada.
3
Projeto VoIP4All: q
11 Implantação de uma arquitetura central na RNP para gerenciamento do projeto VoIP.
11 Organização e desenvolvimento de sistema VoIP local para as instituições usuárias.
11 Implantação piloto de aproximadamente 17 instituições.
11 Desenvolvimento de treinamento para 164 técnicos das instituições.
Serviço fone@RNP:
11 Evolução do GT-VOIP a Serviço.
11 Novo modelo de arquitetura adotado.
11 Adoção do protocolo SIP.
11 Implantação de sistema de instalação automático nas instituições.
GT-VoIP
O serviço fone@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 telefonia no backbone RNP, permitindo às instituições
usuárias utilizar suas redes para estabelecer 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 dez estados do território
brasileiro. Nesse momento, a comunicação de voz sobre IP não era mais novidade devido à
popularização de sistemas como o MSN ou Skype, que permitiam aos usuários realizarem
comunicação de computador para computador.
Não obstante, o serviço fone@RNP permite a comunicação não só com os dispositivos 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, reali-
zando uma chamada local para alcançar o telefone destino.
Projeto VoIP4All
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çados.
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 os treinamentos básico e
avançado ao serviço, oferecidos a dois técnicos de cada instituição beneficiada pelo projeto.
Serviço fone@RNP
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).
4
Serviço fone@RNP
A evolução da telefonia IP, principalmente do protocolo SIP, e as novas demandas solicitadas
ao serviço fone@RNP, levaram-no a uma nova arquitetura baseada no SIP.
Essa evolução promoveu uma reestruturação das instituições participantes. A etapa de

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 para a
base de dados. Tais alterações forneceram ao serviço novo patamar de estabilidade e agili-
dade na implantação e manutenção.
Em março de 2012, o serviço fone@RNP contava com a participação de 115 instituições usu-
árias compostas por unidades de ensino federais, unidades da RNP, unidades da Embrapa e
instituições convidadas.
Funcionalidades do serviço
11 Possibilitar a integração das instituições usuárias. q
22 Arquitetura padrão do serviço fone@RNP.
22 Integração dos dispositivos VoIP.
22 Integração com os ramais da instituição.
22 Integração com os números da RTFC.
11 Redução dos custos das chamadas.
11 Adoção de medidas de QoS para qualidade do serviço.
Integração das instituições usuárias

A principal funcionalidade do serviço é fornecer a arquitetura para a comunicação VoIP
entre as instituições. A RNP é responsável por manter o núcleo do serviço e as instituições
Figura 1.2 usuárias, manter os servidores VoIP locais ativos.
Visão nacional do
serviço fone@RNP.
DSER1
SLOM SLOM
pares pares
prefixos prefixos
Proxy SIP DNS Proxy SIP
Cliente A Cliente B
“OpenSER” NAPTR “OpenSER”
DNS Gateway Gateway Gateway Gateway DNS

SRV VoIP/RTFC H.323/SIP H.323/SIP VoIP/RTFC SRV
DSER2
Instituição A Instituição B
PABX Gatekeeper Gatekeeper PABX
5
A adesão ao serviço fone@RNP é permitida a qualquer instituição usuária da RNP. O pro-
cesso de adesão segue os seguintes passos: (i) Preenchimento da ficha de adesão ao serviço,
(ii) instalação do serviço seguindo a arquitetura padrão e (iii) homologação do serviço
padrão na instituição usuária.
O serviço permite a integração de todos os equipamentos IP (hardphone e softphone),

preferencialmente homologados pela Anatel no caso dos hardphones, com o protocolo SIP e
suporte a codecs padrão como G.711 e G.729, consulta DNS SRV e transposição a NAT.
Uma das funcionalidades diferenciais do serviço é a integração da central telefônica (PABX)

da instituição ao serviço VoIP local. Essa integração permite a comunicação dos ramais com
telefones IP de todo o serviço ou com ramais de outras instituições caso possuam essa
integração, que é totalmente gratuita, já que não há a necessidade de participação de uma
operadora de telefonia fixa para estabelecimento da chamada.
Para expandir a possibilidade de comunicação do serviço, outra funcionalidade diferenciada

do serviço é a comunicação do serviço VoIP com as redes pública de telefonia (RTFC). Assim,
usuários do serviço podem receber ou realizar chamadas para números da RTFC, caso haja
alguma instituição na localidade destino integrada à RTFC, em vez de realizar uma chamada
de longa distância.
As instituições podem escolher não completar chamadas para RTFC. Entretanto, se assim
decidirem, também não poderão ter suas chamadas a distância completadas por outra insti-
tuição, deixando de se beneficiar da economia gerada por essa funcionalidade do serviço. As
estatísticas de uso deixam clara a vantagem de permitir as ligações para RTFC. Verifique no
gráfico Estimativa de Economia, em http://estatisticasfone.rnp.br.
Redução do custo das chamadas

Conforme já citado, o serviço VoIP permite a redução dos gastos de telefonia das instituições
usuárias, reduzindo a zero os custos das chamadas realizadas entre as instituições partici-
pantes e transferindo o custo de ligação de longa distância, que seria paga na origem, para o
custo de ligação local a ser pago pela instituição cliente no destino, para chamadas reali-
zadas para a RTFC de outra localidade.
A transferência de custo DDD para custo local é avaliado pensando o serviço de telefonia de
todas as instituições como uma única conta. É claro que, nesse caso, a instituição de origem
altera o valor da chamada de longa distância para uma chamada gratuita, enquanto a ins-
tituição destino altera o custo de uma chamada que não existiria, ou seja, gasto zero para
uma chamada local.
Considerando que a razão das chamadas DDD com as chamadas locais variam de três a
cinco, para uma instituição não ter redução das chamadas é necessário que receba número
de ligações locais do serviço fone@RNP três a cinco vezes maior que o número de ligações
que a mesma instituição realiza para chamadas DDD.
Ligações para números móveis não são completadas pelo serviço fone@RNP. É sabido que
a razão das ligações para números móveis é maior que a razão das ligações para fixos.
Serviço fone@RNP
Entretanto, se fosse permitido, esse tipo de chamada poderia elevar demasiadamente o

custo com telefonia de uma instituição, caso houvesse um desbalanceamento no número de
chamadas recebidas/realizadas.
6
Adoção de medidas de QoS para a qualidade de serviço
Diferentemente da rede de telefonia fixa comutada, a rede VoIP não usa comutação por
circuitos dedicados e sim a comutação por pacotes da rede IP. O uso da comutação por
pacotes obriga as chamadas VoIP a concorrem com outros pacotes da rede IP. Essa concor-
rência pode levar o tráfego VoIP a ter pacotes descartados ou atrasados. Em transmissões
de tempo real, como o VoIP, atrasos de pacotes são tão prejudiciais para a perda da interati-
vidade quanto o descarte dos pacotes.
Para amenizar tais cenários, o backbone da RNP possui regras de priorização do tráfego das
chamadas VoIP nos roteadores baseadas em marcações de QoS. Por segurança no uso da
priorização dos tráfegos, os roteadores apenas priorizam os pacotes originados pelos ende-
reços IP dos servidores VoIP das instituições usuárias.
Composição do serviço fone@RNP

Endereçamento no serviço: q
11 Endereçamento no serviço SIP: URI.
11 Endereçamento E.164.
Arquitetura do serviço nacional:
11 Visão geral.
11 Componentes do DSER.
11 Componentes do Proxy Externo.
Arquitetura do serviço local:
11 Visão geral.
11 Componentes da máquina 1.
11 Componentes da máquina 2.
Endereçamento no serviço
O endereçamento no serviço fone@RNP é o modelo de endereçamento do protocolo SIP,
seguindo as recomendações da RFC 2396 – Uniform Resource Identifiers (URI).
A URI possui formato padrão do protocolo SIP, que é:
sip:usuario:senha@host_IP:porta;parametos?cabeçalhos
Porém, esse formato padrão não é usado para a localização de usuário ou de Proxy destino,
sendo, para isso, adotado o seguinte padrão:
sip:usuario@domínio
O campo usuário é do tipo string e faz referência ao usuário destino ou ao endereçamento

E.164 do telefone destino. O campo domínio no formato de localização de usuário pode ser
substituído por host_ip:porta. Caso o campo domínio seja um endereço do DNS, este deverá
ser referenciado numa consulta SRV a um serviço localizado num endereço IP e a uma porta.
Esse endereçamento representa que o usuário está pesquisando por um usuário que é
conhecido e alcançável no servidor representado pelo domínio.
7
O endereçamento E.164 é uma recomendação da ITU-T que define a numeração na RTFC.
O E.164, como mencionado, pode ser utilizado no campo usuário para localizar usuários
através do número de telefone, sendo formatado das seguintes formas possíveis:
11 XXXX: números de 4 dígitos que representa um ramal na instituição usuária chamadora.
11 1XXXXXXX: número de 8 dígitos que representa um telefone IP de mesmo código de área

da instituição usuária chamadora.
11 [2-6]XXXXXXX: número de 8 dígitos que representa um ramal ou telefone na rede pública

de telefonia (RTFC) de mesmo código de área da instituição usuária chamadora.
11 0XX1XXXXXXX: número de 11 dígitos que representa um telefone IP do código de área

definido.
11 0XX[2-6]XXXXXXX: número de 11 dígitos que representa um ramal ou telefone da RTFC

do código de área definido.
11 +55XX1XXXXXXX: número de 13 dígitos que representa um telefone IP do código de área

definido.
11 +55XX[2-6]XXXXXXX: número de 13 dígitos que representa um ramal ou RTFC do código

de área definido.
11 +XXXXXXX.: Números de tamanho maior ou igual a 7 dígitos e menores que 15.
11 0055XX1XXXXXXX: número de 14 dígitos que representa um telefone IP do código de área

definido chamadora.
11 0055XX[2-6]XXXXXXX: número de 14 dígitos que representa um ramal ou RTFC do código

de área definido.
11 00XXXXXXX.: números maiores de 7 dígitos e menores de 15.
Arquitetura do serviço nacional

O serviço fone@RNP no âmbito nacional é formado por dois Proxies nacionais que geren-
ciam o serviço, o balanceamento das chamadas e as informações de roteamento que com-
plementam o serviço fone@RNP.
Como apresentando na Figura 1.1, as instituições utilizam o Proxy da RNP, nomeado de DSER
(Directory SIP Express Router), para realizar a localização das instituições no serviço. Esse
Proxy é replicado nos equipamentos DSER1 e DSER2, que são capazes de realizar o rotea-
mento das chamadas independentes.
Cada DSER é composto pelo Proxy SIP OpenSER, responsável pelo tratamento das mensagens
SIP, do banco de dados PostgreSQL Master do serviço e do DNS local para consulta ENUM.
Os Proxies SIP estão configurados para receber mensagens SIP de todos os equipamentos
participantes do serviço e consultar a base ENUM para localizar as instituições que com-
pletam a chamada para o número destino e as ordenam por prioridade.
O banco de dados PostgresSQL Master é responsável por manter a base do serviço fone@
RNP e replicar todas as informações da base para os bancos de dados slaves das instituições
Serviço fone@RNP
usuárias. Para essa replicação, o serviço utiliza o software adicional Slony, que realiza a
sincronização dos bancos de dados.
8
Arquitetura do serviço local
O serviço fone@RNP localmente é composto por duas máquinas que distribuem o serviço
entre si. Não existe balanceamento da carga entre as duas máquinas. Basicamente, os ser-
viços são distribuídos, evitando sobrecarga de um dos servidores.
Conforme apresentado na Figura 1.2, a reestruturação do serviço na versão 2 do fone@RNP

definiu que a máquina 1 é composta pelo Proxy SIP OpenSER, pelo Proxy H.323 GnuGK, pelo
Proxy de mídia MediaProxy e pelo gateway SIP/H.323 Asterisk.
Terminal H.323
Ambiente H.323
OpenPhone
GnuGK
Gatekeeper
Au
co ten
nt tic
ab aç
ilid ão
ad /
Asterisk e
Gateway SIP/H.323 e FreeRadius LDAP
Gateway VoIP/PBX
PSTN/PBX
Consulta
Diretório para identificação
Contabilidade
Cliente SIP e autenticação de usuários

ão
icaç
nt
te
Ambiente SIP Au
X-lite
SER Consulta
Proxy SIP
Contabilidade
PostgreSQL Apache para disponibilização
de estatísticas
Figura 1.3 Na máquina 2 está o gateway SIP/Telefonia convencional Asterisk, o banco de dados
Visão local do PostgreSQL, a base de usuários openLDAP, a ferramenta de autenticação e contabilização
serviço fone@RNP.
FreeRadius, a ferramenta de consolidação das estatísticas consolida e as ferramentas web
de gerência do serviço e de extração de dados estatísticos.
A base de dados PostgreSQL é slave do serviço fone@RNP, sendo sincronizada ao banco de

dados Master. Recordando que o banco de dados Master está localizado no DSER1 do serviço.
9
Ambiente nacional
DSER1
Linux
OpenSER
PostgreSQL (rotas) + Slony
DNS (ENUM privado)
Instituição A
Máquina 1 Máquina 2
Linux Linux
OpenSER Asterisk (GW telefonia convencional)

GnuGK PostgreSQL (CDRs, rotas) + Slony
MidiaProxy OpenLDAP (usuários)
Asterisk (GW SIP/H.323) FreeRadius (autenticação)
Consolidação de CDRs Figura 1.4
Integração dos
Interface web de gerência
ambientes nacional
e local.
Dispositivos VoIP
Utilizando um software adequado, um computador pode ser utilizado facilmente para a q
comunicação via VoIP.
VoIP via ATA:
11 Consiste em usar um Adaptador de Telefone Analógico (ATA).
11 Exemplo: pluga-se um telefone comum ao ATA e este ao computador, permitindo

assim o uso do sistema VoIP.
VoIP via telefones IP:
11 Possuem a mesma aparência de um telefone comum, mas utilizam conectores

RJ-45 Ethernet.
11 Também precisam de energia para funcionar.
VoIP via Softphone

Forma de comunicação VoIP que utiliza Softphone, isto é, software que emula o funciona-
mento de telefones convencionais para uma comunicação direta computador-computador.
Skype, MSN, Paltalk e ICQ são exemplos de softwares que utilizam VoIP e permitem a comu-
nicação por voz sobre a internet.
Serviço fone@RNP
VoIP via ATA

O Analog Telephone Adapter (ATA)permite a conexão de aparelhos do tipo analógico, decá-
dico ou MF. É necessário programar o ATA para conectá-lo à rede. Todos os ATAs necessitam
de uma fonte de alimentação, que pode ser local ou através de Power over Ethernet (PoE).
Hoje existem no mercado ATAs para 2, 4, 8, 16, 24 e 30 aparelhos telefônicos.
10
VoIP via telefone IP
Similar ao ATA, o telefone IP deve ser configurado previamente para ser conectado na rede.
Os telefones IP também precisam de energia para funcionar. Podem ter alimentação local
ou por PoE. Não é uma solução trivial, como nos telefones analógicos ou digitais, para os
quais bastava a conexão na tomada telefônica do tipo RJ-11. Algumas soluções de aprovi-
sionamento já permitem que os telefones equipados com esses recursos sejam capazes de
receber da rede toda a sua configuração, bastando ligá-lo na rede; para isso, a informação
de cada telefone deve estar previamente armazenada em algum servidor da rede.
Gateway VoIP
Equipamento que faz traduções de protocolos. No caso de gateway SIP-H.323, a tradução
realizada é entre protocolos VoIP. O fone@RNP instala nas instituições um gateway VoIP para
telefonia convencional, analógica (quando ligado em posições de ramal) ou digital (quando é
utilizada a interface E1). Esse equipamento torna possível a interligação da rede de telefonia
legada à nova infraestrutura de telefonia IP, resguardando assim todo o investimento reali-
zado anteriormente.
Programa de Estatísticas Nacionais

Disponibilização de informações sobre o uso do serviço. Gráficos: q
11 Chamadas completadas.
11 Comparação de tipo por direção.
11 Chamadas completadas por diferentes tipos de origem e destino.
11 Ranking de uso para chamadas completadas por local.
11 Motivos de não completamento.
11 Estimativa de economia.
O Programa Nacional de Estatísticas é o conjunto de ações cujo objetivo é disponibilizar

informações mais claras sobre a utilização do serviço fone@RNP. Com o sistema desenvol-
vido será possível conhecer o perfil de uso do serviço de Voz sobre IP da RNP.
O sistema não calcula valores das chamadas, mas com as informações disponibilizadas, é pos-
sível estimar com segurança a economia gerada com a utilização do serviço de Voz sobre IP.
A ferramenta coleta os registros das chamadas realizadas e recebidas em cada unidade

cliente do fone@RNP e os consolida em uma base de dados única, verificando origem e
destino de cada uma das ligações. Essas informações são processadas e apresentadas em
forma de gráficos e tabelas descritos a seguir.
Chamadas completadas
O gráfico “Chamadas completadas” mostra a 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 ocupado, não atendeu ou ainda com destino inexistente.
Comparação de tipo por direção

O gráfico “Comparação de Tipo por Direção” mostra a quantidade de ligações feitas de acordo
com o seu destino. Também há a opção de exibir a duração das chamadas em minutos.
11
Os destinos estão qualificados como:
11 RTFC: quando as chamadas são destinadas a telefones na Rede de Telefonia Fixa Comu-
tada, ou seja, telefones na rede pública, fora dos institutos e universidades.
11 PABX: quando as chamadas são destinadas a telefones convencionais dentro das institui-
ções clientes.
11 VoIP: quando as chamadas são destinadas a telefones IP, sejam eles softphones ou
deskphones.
Chamadas completadas por diferentes tipos de origem e destino

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 a telefones da rede pública, ou

seja, fora das instituições clientes.
11 PABX: quando as ligações são originadas ou destinadas a telefones convencionais dentro

das instituições clientes.
11 PABX: quando as ligações são originadas ou destinadas a telefones IP, sejam deskphones
ou Softphones.
A tabela associada ao gráfico mostra também os valores absolutos da quantidade de cha-

madas e tempo de duração de cada par origem versus destino, separados por tipo.
Ranking de uso para chamadas completadas por local

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 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.
Motivos de não completamento

O gráfico “Motivos de não completamento” mostra um comparativo das mensagens de
retorno mais comuns quando as ligações não são completadas. 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. Ocorrências como “chamou até cair”, “usuário estava ocupado” e “discagem para
número inexistente” estão incluídas aqui.
Serviço fone@RNP
12
Estimativa de economia
O gráfico “Estimativa de Economia” oferece informações para que seja possível estimar a
economia feita com as ligações executadas através do fone@RNP. Apresenta valores de
quantidade de ligações e de duração total das chamadas.
No gráfico são apresentadas duas barras:
w 1. Quantidade de chamadas à distância não pagas são as chamadas realizadas para tele-
O acesso ao sistema de fones IP ou para ramais convencionais dentro das instituições clientes. Assim, não foi
estatísticas pode ser
feito através do gerado nenhum custo adicional para nenhuma instituição.
endereço
2. Quantidade de chamadas a distância pagas são aquelas terminadas na rede de telefonia
http://estatisticasfone.
rnp.br pública. Nesse caso, alguma instituição no estado destino arcou com o custo dessa
ou através da página do ligação local.
fone@RNP.
13
14
Serviço fone@RNP
Roteiro de Atividades 1
Tabela de configuração do laboratório. Os números dos telefones nesta prática são da
MCDU, onde:
11 M especifica o tipo de dispositivo.
11 CD especifica o grupo ou instituição.
11 U especifica o usuário.
Dessa forma, as contas foram associadas aos grupos/instituição e seus dispositivos, exis-
tindo nesta atividade três tipos de contas: Softphone, telefone IP e ATA. Todos as contas dos
telefones estão definidas no PABX como softCDU para Softphone, telipCDU para telefones
IPs e ataCDU para ATAs.
Exemplificando este roteiro, abaixo estão descritas as contas criadas para o Grupo 01.
Grupo Tipo de Usuário Usuário Número Senha
01 Softphone soft011 1011 voip
01 Telefone IP telip011 2011 voip
01 ATA ata011 3011 voip
01 ATA ata012 3012 voip
Atividade 1.1 – Instalando o softphone

No ambiente Windows, instale os aplicativos X-Lite e 3CX, localizados no desktop. Os aplica-
tivos também poderão ser encontrados no site do fabricante: http://www.counterpath.com
e http://www.3cx.com.br. Ao final das instalações, não será necessário reiniciar o sistema.
Instalando e configurando o X-Lite

Instale e execute o X-Lite. Para entrar no modo de configuração, aponte o mouse sobre
o telefone e clique com o botão da direita. Feito isso, agora selecione a opção SIP Account
Settings..., como indicado na próxima imagem. Caso seja a primeira vez que você esteja confi-
gurando, esse passo não é necessário.
Capítulo 1 - Roteiro de Atividades
15
Figura 1.5
Acesso à
“Configuração
de contas SIP”.
Configure a sua conta de acordo com o plano de ramais. Substitua o CDU pelo número do
seu grupo, mais o usuário. A senha para autenticação no servidor é voip, devendo ser inse-
rida no campo Password.
Figura 1.6
Configuração
de contas SIP.
Serviço fone@RNP
Se a configuração da conta foi efetuada corretamente, a mensagem Ready será exibida na

tela do X-Lite, conforme ilustra a figura seguinte.
16
Figura 1.7
Telefone
X-Lite pronto.
Instalando e configurando o 3CX

Instale e execute o cliente 3CX. Para entrar no modo de configuração, aponte o mouse sobre
o telefone e clique com o botão da direita. Feito isso, agora selecione a opção Conexão. Caso
seja a primeira vez que você esteja configurando, esse passo não é necessário.
Configure a sua conta de acordo com o plano de ramais. Substitua o CDU pelo número do
seu grupo, mais o usuário. A senha para autenticação no servidor é voip, devendo ser inse-
rida no campo Password.
Figura 1.8
Configuração do
telefone 3CX.
17
Se a configuração da conta foi efetuada corretamente, a mensagem Conectado será exibida
na tela do 3CX.
Atividade 1.2 – Configurando o telefone IP

Acesse no seu browser o endereço http://<IP DO TELEFONE>. Em seguida são solicitados
usuário e senha para autenticação, conforme abaixo:
Figura 1.9
Acesso ao telefone
Polycom.
O nome do usuário é Polycom e a senha, 456. Após o sucesso na autenticação, a seguinte

página será apresentada:
Figura 1.10
Primeira página de
configuração do
telefone Polycom.
Clique no link Lines. Nessa página devemos configurar as contas SIP que serão utilizadas
pelo telefone. Nesta atividade iremos configurar apenas a linha 1. A página abaixo apresenta
as sessões Line 1 e Serve 1:
Serviço fone@RNP
18
Figura 1.11
Configuração de
linha 1 do telefone
Polycom.
A linha 1 será utilizada configurando apenas alguns dos campos existentes nas sessões Iden-
tification e Server 1. Na sessão Identification, os campos Display Name, Address, Auth User ID,
Auth Password e Label são configurados. Somente os campos Address e Port são configurados
na sessão Server 1. Substitua o CDU pelo número do seu grupo mais o usuário.
Para finalizar, clique no botão Submit e aguarde o telefone ser reiniciado. Em seguida, o tele-
fone está pronto para ser utilizado.
Atividade 1.3 – Configurando o ATA

Figura 1.12 Para iniciar a configuração, precisaremos do IP do adaptador. Para descobrir o IP recebido
Cabeçalho pelo adaptador, ligue-o a um telefone convencional, digite **** (quatro asteriscos) e em
da página de
configuração do seguida digite 110#. Uma mensagem com o número do IP será anunciada.
ATA Linksys.
Acesse no seu browser o endereço http://<IP ANUNCIADO PELA MENSAGEM> e efetue login
na interface de configuração do equipamento. Na página seguinte clique em Line 1:
Na página mostrada na próxima figura, configure apenas os parâmetros abaixo:
11 Proxy: <IP fornecido pelo instrutor>
11 Display Name: entre com seu nome completo
19
11 User ID: ataCDU (entre com o usuário indicado no início da prática)
11 Password: voip
11 Register Expires: 3600
Lembre-se de substituir o CDU pelo número do seu grupo, mais o usuário, e clique no botão
Save Settings...
A figura a seguir apresenta como deve ficar a configuração do seu adaptador:
Figura 1.13
Atividade 1.4 – Efetuando chamadas com ATA, telefone IP e softphone Página de
configuração da
Efetue chamadas entre os três clientes. Lembrando que o X-Lite deve estar configurado com linha 1 do ATA
o ramal 1CDU, o telefone IP com o ramal 2CDU e o ATA com o ramal 3CDU. Esse passo deverá Linksys.
ser realizado em dupla, onde os integrantes da dupla efetuarão chamadas entre eles.
Serviço fone@RNP
20
2
Tecnologia VoIP
objetivos
Nivelar o conhecimento teórico dos alunos com relação aos conceitos, protocolos
e métodos associados à tecnologia de Voz sobre IP (VoIP). Apresentar o protocolo
utilizado no serviço fone@RNP, codecs, transmissão da voz e consumo de banda.
conceitos
Protocolo SIP, codificação/decodificação da voz e transmissão da voz codificada.
Protocolo de iniciação de sessão – SIP

Session Initiation Protocol (SIP) é o protocolo de sinalização que estabelece sessões de q
comunicação interativa entre usuários. Entre outros recursos, cada sessão pode incluir:
11 Vídeo.
11 Voz.
11 Bate-papo.
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 e sua função era basicamente
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-
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 tutelar 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,
Capítulo 2 - Tecnologia VoIP
podendo ser de transmissão de voz, vídeo ou bate-papo.
Funções do protocolo SIP

O objetivo principal do SIP é contemplar a criação e o gerenciamento de sessões para q
troca de fluxos multimídia entre aplicações.
Ações do protocolo SIP:
11 Negociação e estabelecimento de sessão.
21
11 Alterações de parâmetros on-the-fly. q
11 Término de sessão.
Funções oferecidas:
11 Registro e localização de um usuário.
11 Disponibilidade de um usuário.
11 Recursos de um usuário.
11 Gerência da sessão.
Com o objetivo de criar e gerenciar sessões multimídias, o protocolo SIP atua na negociação
e no estabelecimento de sessões definindo todos os atributos que serão utilizados nos
fluxos de mídia. Alterando parâmetros durante uma sessão estabelecida, adicionando ou
encerrando fluxos de mídia da sessão. E, por fim, finalizando a sessão.
Funções essenciais para um projeto de comunicação IP são definidas pelo protocolo SIP,
funções como:
11 Registro de um usuário.
11 Localização de um usuário.
11 Verificação dos recursos disponíveis por um usuário.
11 Gerenciar sessões de mídia.
11 Estabelecer sessões de mídia.
Conjunção com outros protocolos

11 Real Time Protocol/Real Time Control Protocol (RTP/RTCP). q
11 Session Description Protocol (SDP).
11 Real Time Streaming Protocol (RTSP).
11 Media Gateway Control Protocol (MGCP).
Padronizado pelo IETF na RFC 1889, o Real Time Transport Protocol (RTP) foi projetado para
permitir que os receptores compensem o jitter e a perda de pacotes introduzidos pelas redes
IP. Sua última versão é o Secure RTP, publicada na RFC 3711. Inclui as seguintes informações:
11 Tipo de dado transportado.
11 Timestamps.
11 Número de sequência, entre outras informações.
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 os membros, jitter e 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
Serviço fone@RNP
mídia, codecs, portas de mídia e criptografia.
O Real Time Streaming Protocol (RTSP), ou protocolo de fluxo contínuo em tempo real, é utili-
zado para transmissão de áudio e vídeo, ou seja, streams sincronizados de mídias contínuas
em tempo real pela internet. Foi definido pela IETF na RFC 2326.
22
O Media Gateway Control Protocol (MGCP) assume o modelo de inteligência centralizada,
facilita a tarifação e barateia os terminais e gateways. Utiliza os protocolos RTP/RTCP para
o transporte de mídia, funcionando como sinalização por canal comum nº 7 ISUP e outras
sinalizações. É a junção do Internet Protocol Device Control (IPDC), protocolo para controle
de dispositivos de mídia, com o Simple Gateway Control Protocol (SGCP). Foi definido pela
IETF nas RFCs 2705 e 3435.
Extensões ao protocolo SIP

11 SIP for Instant Messaging and Presence Leveraging Extensions (Simple). q
11 Session Initiation Proposal Investigation (Sipping).
11 Multiparty Multimedia Session Control (Mmusic).
11 IP Telephony (Iptel).
11 PSTN-Internet Interworking (Pint).
11 Simple: grupo que foca seu trabalho nas aplicações relacionadas ao protocolo SIP, conhe-
cidas como instant messages e presence.
11 Sipping: grupo responsável por documentar o uso do SIP relacionado às aplicações de

telefonia e multimídia e por desenvolver requerimentos para futuras atualizações.
11 Mmusic: grupo responsável por desenvolver protocolos que suportem teleconferência e

comunicações multimídia.
11 Iptel: grupo com serviços focados nos problemas que dizem respeito à resolução de
nomes (URI) e ao roteamento para os protocolos de voz sobre IP.
11 Pint: grupo designado para estudar a arquitetura e os protocolos necessários para

suportar serviços para os quais um usuário localizado na internet faz a requisição de uma
ligação telefônica, através de um terminal PSTN.
Características do protocolo SIP

11 SIP é baseado em texto. q
11 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 às seguintes características:
11 Simplicidade, já que possui apenas seis métodos.
11 Independência em relação ao protocolo de transporte.
11 Baseado em texto.
11 Assim como o HTTP, o SIP leva os controles da aplicação para o terminal, eliminando a
necessidade de uma central de comutação.
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
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 SIP transporta uma pequena quantidade de dados requerida para configurar comunicações
interativas (pequenas mensagens de texto). Também não age como um dispositivo de reserva
23
de recursos, por não prover QoS, apenas interagindo com protocolos desenvolvidos para
suportar QoS. Não é um protocolo que substituirá a PSTN, sendo bem diferente dos modelos
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.
Características:
11 Simples.
11 Independente do protocolo de transporte.
11 Baseado em texto.
11 Sinalização ponto-a-ponto.
11 Toda lógica está armazenada nos clientes, exceto mensagens de roteamento.
11 Associado ao Session Description Protocol (SDP).
11 Usado para transportar descrições dos parâmetros de cada sessão.
11 Trabalha com IPv4 e IPv6.
11 O que o SIP não é e não faz:
22 Não é um protocolo de transferência de dados.
22 Transporta pequenas mensagens, mas não uma grande quantidade de dados.
22 Não fornece suporte para QoS.
22 Não tem a finalidade de substituir todas as características da telefonia.
22 Não é um protocolo de reserva de recurso.
22 Não é um protocolo para controle de dispositivos ou procedimento para chamadas

remotas (Remote Procedure Calls – RPC).
22 Trabalha juntamente com a PSTN através de gateways, mas essa não é sua função principal.
Elementos de uma rede SIP

Rede SIP típica contém basicamente dois tipos de elementos SIP: q
11 User agents.
11 SIP Servers.
22 Proxy Servers.
33 Stateful.
33 Stateless.
22 Redirect server.
22 Registrar.
User Agents (UA)

Terminais que usam SIP para se encontrar e negociar características da sessão. Dentro q
dos UA temos:
11 User Agent Client (UAC).

Serviço fone@RNP
22 Parte do UA que envia as requisições e recebe as respostas.
11 User Agent Server (UAS).
22 Parte do UA que recebe as requisições e envia as respostas.
UAC e UAS são entidades lógicas.
24
O User Agent (UA) é uma entidade lógica da arquitetura SIP. Pode atuar como um User Agent
Client (UAC) ou como um User Agent Server (UAS), ou seja, cada user agent contém um UAC
e um UAS.
11 UAC: o Usuário Agente Cliente (User Agent Client) executa a função de cliente da apli-
cação e é responsável por iniciar uma chamada SIP.
11 UAS: o Usuário Agente Servidor (User Agent Server) é a parte com função de servidor e
permanece “ouvindo” a rede, aguardando requisições.
Os terminais que usam SIP para se encontrar e negociar características da sessão são user
agents que podem ser telefones celulares, gateways ou PDAs. Proxy servers 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. Também são chamados de SIP Proxy. Podem ser de dois tipos:
11 Proxies Stateless: não mantêm o estado das chamadas. Eles simplesmente reencami-
nham as mensagens para o destino ou para outro proxy. São mais simples e rápidos.
11 Proxies Stateful: mantêm o estado das chamadas. Podem se encarregar de tarefas como
bilhetagem e contabilização.
Registar server é a entidade lógica responsável por manter os registros dos usuários.
Ela extrai informação sobre sua localização atual, armazena-a em um banco de dados e
mapeia nomes e números em endereços IP.
Redirect server é um tipo de servidor da arquitetura SIP que, ao receber uma mensagem,
envia de volta uma resposta, com um redirecionador, para o endereço de outro servidor
proxy, para quem o UAC deve reenviar a requisição original.
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.
Número
chamado A
Stateful Proxy UAC

Chamador
INVITE
UAC UAS
INVITE
UAC UAS
UAC
IN Número
UAS VI
TE chamado B
BYE
UAS
Figura 2.1 UAC

Topologia SIP.
A figura anterior mostra três dispositivos SIP e um stateful forking proxy. Cada user agent
contém um UAC e um UAS. A parte do proxy que recebe a requisição INVITE do chamador
atua como um UAS. Quando repassa a requisição, cria dois UACs, cada um responsável por
um dispositivo chamado.
25
Servidor Proxy
Entidade intermediária que atua como servidor e cliente, tem o propósito de fazer q
requisições em nome de outros clientes. Existem dois tipos de servidores proxy:
stateful e stateless.
Servidores stateful são indicados para o controle de terminação, pois possuem capacidade
para controlar todas as transações, mantêm o estado das chamadas e são capazes de pro-
duzir informações que possibilitam a bilhetagem (cobrança) das ligações.
Servidores stateless são similares às “centrais tandem” da velha telefonia. Armazenam

poucas informações e são indicados para implementação de centrais de trânsito, a fim de
evitar congestionamentos.
1 Request
Figura 2.2
Exemplo de
atuação do SIP
proxy.
chamador@provedor.b SIP Proxy fulano@casa.b
Servidor Proxy Stateful

Entidade lógica que mantém o estado de todas as transações de clientes e servidores: q
11 Mais complexo do que o servidor stateless.
11 Performance limitada.
11 Trabalha com forking.
11 Pode aplicar métodos mais sofisticados para buscar usuários.
Um servidor stateful mantém o estado das chamadas, do estabelecimento (INVITE) até sua
finalização (BYE), podendo implementar formas mais complexas para encontrar um usuário.
Por exemplo, pode tentar encontrar um cliente em seu telefone do escritório e, se não
atender, pode redirecionar a chamada para seu celular.
Servidor Proxy Stateless

11 Entidade lógica que não mantém o estado das transações feitas pelo cliente ou q
pelo servidor.
11 Repassa todas as requisições e respostas recebidas.
11 Não se importa com o que acontece com as transações, apenas as repassa.
11 Mais rápido do que o servidor stateful.
Um servidor stateless não mantém o estado das chamadas, repassando as requisições rece-
bidas. Não se importa com o que acontece com as transações, apenas as repassa. É mais
rápido do que o servidor stateful.
Serviço fone@RNP
Utilização do servidor proxy

Realiza a comunicação entre duas empresas com servidor proxy. q
26
Servidor DNS
DNS
2. SIP SRV
para b.com 3. proxy.b.com
Empresa A Empresa B
Joe Bob
proxy.a.com proxy.b.com
Figura 2.3 1.INVITE 4.INVITE 5.INVITE
Comunicação
entre dois domínios
diferentes. 5.6.7.8 6.BYE 1.2.3.4
Esse cenário supõe a existência de duas companhias, A e B, com dois servidores proxy
diferentes, um para cada. O funcionário Joe, da companhia A, deseja se comunicar com o
funcionário Bob, da companhia B.
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 todo o
tráfego para o servidor SIP proxy.a.com de sua companhia.
O servidor proxy descobre que o usuário sip:bob@b.com está em uma companhia dife-
rente, então vai procurar o servidor SIP proxy da companhia B e enviar o convite para lá. Os
servidores proxy da companhia B podem estar pré-configurados no proxy.a.com ou o proxy
utilizará os registros DNS SRV para encontrar os servidores proxy de B.
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, 1.2.3.4.
Servidor de redirecionamento
Servidor que recebe uma requisição e retorna uma resposta contendo uma lista da loca- q
lização atual do cliente. 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 user agent
gerador 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.
27
Servidor de redirecionamento
1.INVITE 2. 302 movido temporariamente
3.INVITE
Figura 2.4
Funcionamento do
User agent A User agent B redirect server.
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.
Servidor de registro
Entidade especial SIP que recebe os registros dos usuários e extrai a informação de sua q
localização atual:
11 Endereço IP.
11 Porta.
11 Username.
Armazena informações em um banco de dados e, caso o registro ocorra com sucesso,

uma mensagem do tipo 200 OK será retornada.
O servidor de registro (register server) é 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
Serviço fone@RNP
Figura 2.5
3. 200 OK
Funcionamento
1.2.3.4.5060 Registrar do servidor de
registro.
28
Esse cenário demonstra um exemplo de um servidor de registro (registrar), no qual uma
mensagem REGISTER contendo o endereço de registro sip:jan@iptel.org e o endereço
de contato sip:jan@1.2.3.4:5060, em que 1.2.3.4 é o endereço IP do telefone enviado ao
servidor 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 tele-
fone e o processo de registro termina corretamente.
Servidor de registro no fone@RNP

11 Modo de autenticação utilizando o método www-authenticated. q
11 Toda solicitação de REGISTER ou INVITE não é autorizada no primeiro momento.
22 Na resposta 401 – Unauthorized, o proxy encaminha informações para a realização

da autenticação.
11 Usuário confirma o recebimento da resposta.
11 Usuário encaminha REGISTER incluindo as credenciais de autenticação.
11 Modo de autenticação não faz a transmissão da senha.
22 Senha não passa na rede em texto claro.
22 Modo de autenticação por chave compartilhada.
O servidor do fone@RNP utiliza o recomendado método de autenticação baseado no modo

www-authenticated. Esse método permite que a senha não seja transmitida pela rede, pois,
como a senha está disponível em ambos os equipamentos, o servidor responde a solicitação
de autenticação com um desafio.
Tecnicamente o desafio é uma aplicação que gera um hash criptografado MD5. Para auten-
ticar-se usando esse método, o cliente deverá responder ao desafio através de um hash
criptografado baseado nas informações de domínio (realm), usuário e senha. As mesmas
informações estão disponíveis no servidor que executará a mesma função. Caso a resposta
do desafio encaminhada pelo cliente seja igual à resposta obtida pelo servidor, o cliente será
autenticado. Caso contrário, a resposta será negativa para a autenticação.
Sendo assim, no serviço SIP o envio do desafio é realizado durante a resposta 401 – Una-
thourized. Ao receber o desafio, o cliente confirma o recebimento da mensagem negativa e
encaminha um novo Register – como novo sequenciamento, porém como mesmo CALL-ID –
ao servidor com a resposta do desafio.
29
SIP User agent Proxy SIP (OpenSER)
1 – REGISTER
2-401 + www-autenticação
3 – REGISTER + autorização
Figura 2.6
Exemplo de
4-200 OK
autenticação de
telefones SIP.
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:
1. Requisição do cliente para o servidor.
2. Resposta do servidor para o cliente.
11 SIP Requests: uma mensagem SIP enviada do cliente ao servidor com o propósito de
invocar uma operação em particular.
11 SIP Responses: quando um UA (User Agent) ou um proxy server recebe uma requisiçã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 uma linha de início. 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 extensões do SIP. Com relação ao endereço, o formato é definido como uma
URI SIP, uma SIPS ou uma URI genérica.
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.

Tabela 2.1
REGISTER Registra a informação do contato.
Métodos de
Serviço fone@RNP
requisições no
OPTIONS Faz consulta ao servidor para saber suas capacidades.
SIP/2.0.
30
Há ainda os métodos estendidos de requisiçã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 ins-

tantâ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.
SUBSCRIBE 3265 Permite que se subscreva para um estado

Tabela 2.2 particular em um recurso.
Métodos de
UPDATE 3311 Permite a atualização dos parâmetros de
requisições
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”,
nonce=”3cef753900000001771328f5ae1b8b7f0d742da1feb5753c”,
response=”53fe98db10e1074
b03b3e06438bda70f”
Content-Type: application/sdp
Content-Length: 451
Continua com linhas SDP...
31
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 e para o roteamento de SIP Responses (respostas SIP).
A mensagem INVITE contém apenas um cabeçalho Via criado pelo 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.
Os campos do cabeçalho To e From identificam destinatário e emissor de determinado

convite para determinada sessão. Também possui um campo Tag, que serve como um iden-
tificador 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 por:
11 Identificação da versão SIP.
11 Código de status numérico ou status code (código de resultado com três dígitos).
11 Frase textual.
Existem seis classes do tipo SIP Responses:
11 1xx – Resposta informativa.
22 Usadas para respostas provisórias, que dizem ao receptor que a requisição feita foi
recebida, mas o resultado ainda está em processo.
11 2xx – Respostas de sucesso.
22 Respostas finais de sucesso, em que o originador da requisição sempre as receberá.

Também terminam transações.
11 3xx – Respostas de redirecionamento.
22 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.
11 4xx – Respostas de falha de requisição.
22 Respostas utilizadas para indicar que houve erro da parte de quem enviou a requi-
sição; erro na sintaxe ou por não ter sido bem preenchida pelo servidor. Resposta de
falha de requisição.
11 5xx – Respostas de falha em servidor.
22 Utilizadas para indicar que houve um erro da parte do servidor. Resposta de falha no
servidor.
11 6xx – Respostas de falha global.
22 Usada para indicar que a resposta não pode ser completada em nenhum servidor.
Resposta de falha global.
Serviço fone@RNP
32
Informações Sucesso Redirecionamento Falha de solicitação
100 Trying 200 OK 300 Multiple Choices 400 Bad Request

180 Ringing 301 Moved Perm. 401 Unauthorized
181 Call forwarded 302 Moved Temp. 403 Forbidden
182 Queued 380 Alternative Serv. 404 Not Found
183 Session Progress 405 Bad Method
415 Unsupp. Content
420 Bad Extensions
486 Busy Here
500 Server Error 600 Busy Everwhere

501 Not Implemented 603 Decline
503 Unavailable 604 Doesn´t Exist
504 Timeout 606 Not Acceptable
Figura 2.7
Respostas SIP. Falha no servidor Falha geral
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
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”
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.
33
Um exemplo mais completo
Atlanta.com Biloxi.com
proxy proxy
Bob SIP
Phone
INVITE F1
INVITE F2
100 Trying F3 INVITE F4
100 Trying F5
100 Trying F6
180 Ringing F7
180 Ringing F8 200 Ok F9
200 Ok F10
200 Ok F11
ACK F12
Sessão de mídia
BYE F13
Figura 2.8
200 Ok F14 Chamada SIP com
proxies.
Nesse exemplo 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 os mesmos campos To, From, Call-ID, CSeq e Via, que permitem que
o softphone de 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 requisiçã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 atual
de Bob. O servidor proxy biloxi.com adiciona outro campo Via no cabeçalho com o seu ende-
reço para a requisição INVITE e a envia ao telefone SIP de Bob. O telefone SIP de Bob recebe
a requisição INVITE e alerta a Bob de que existe uma chamada de Alice. O telefone SIP de
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 aonde enviar a resposta, depois disso, eliminando-a 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
Serviço fone@RNP
com a descrição de mídia Session Description Protocol (SDP) 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.
34
Protocolo SDP
SDP significa Session Description Protocol (Protocolo de Descrição de Sessão). É um q
formato para a descrição dos parâmetros de inicialização de mídia streaming. Foi publi-
cado pela IETF como RFC 2327 e substituído pela RFC 4566. Mídia streaming é o con-
teú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 facilita a portabilidade, permite uma variedade de formas de transporte e possibi-
lita 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.
Anatomia do SDP
Uma mensagem SDP é composta por uma série de linhas denominadas campos. q
Os nomes são abreviados por uma só letra. A formatação das linhas de texto está des-
crita 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 abaixo mostra os campos e sua descrição.
Descrição da sessão
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
35
Descrição da sessão
Tipo do Valor do campo Presença

campo obrigatória
k Chave de encriptação Não
a Zero ou mais linhas de atributo da sessão Não Tabela 2.3

Campos da
Zero ou mais descrições de mídia Não requisição SDP.
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
Negociando a sessão SDP

A descrição de sessão não é enviada em qualquer mensagem SIP, mas apenas nas mensa-
gens de requisição INVITE e na mensagem de resposta 200 OK. Toda solicitação de chamada
INVITE também encaminha anexada a descrição de mídia solicitante. Essa descrição compõe
todas as capacidades do usuário solicitante.
Na resposta 200 OK, também está anexada a descrição de mídia do usuário chamado. Nessa
descrição, o usuário chamado responde apenas às capacidades atendidas pelo usuário e,
caso deseje não habilitar um fluxo de mídia solicitado pelo usuário chamador, o usuário res-
ponde ao fluxo de mídia com porta RTP 0. Ao final dessa comunicação, ambos os usuários
estão prontos para o estabelecimento dos fluxos de mídia dessa sessão.
Mudando parâmetros da sessão

Durante uma sessão estabelecida de mídia, as configurações definidas nos fluxos SDP
podem ser alteradas. Exemplos de alterações possíveis nos fluxos de mídia:
11 Adição ou remoção de fluxos.

Serviço fone@RNP
11 Alteração de codecs.
11 Alteração nos parâmetros de transporte (RTP).
Para realizar a alteração dos parâmetros da sessão, o serviço utiliza a premissa do RE-INVITE.
O método RE-INVITE não existe no protocolo SIP, o que está definido é o reenvio da requi-
sição INVITE com as mesmas informações de diálogo existentes na sessão estabelecida,
36
porém contendo as novas informações de SDP válidas para a nova sessão, de forma que
sessões não alteradas deverão ser descritas, pois fluxos não descritos serão removidos.
Caso o RE-INVITE seja rejeitado, as informações descritas na sessão inicial permanecerão

válidas. Um uso muito comum desse método é a função de colocar a chamada em espera,
na qual um novo INVITE é gerado sem o fluxo de mídia e, posteriormente, ao fim da espera,
um terceiro INVITE é gerado para restabelecer os fluxos de mídia.
Real-time Transport Protocol (RTP)

Protocolo que oferece funções de transporte de rede fim-a-fim, como áudio e vídeo interativos.
UDP
Desempenho
RTP
TCP
Figura 2.9
Desempenho
versus
confiabilidade. Confiabilidade
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 em vez 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 streaming calculam a probabilidade do pacote ser
retransmitido, permitindo que ele possa chegar a tempo de ser processado. Assim, apenas
em caso positivo o pacote é retransmitido.
O serviço inclui: q
11 Identificação do tipo payload.
11 Numeração sequencial.
11 Marcas temporais (timestamping).
11 Monitoração da entrega de dados (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 a ele algumas informações de sequenciamento e de times-

tamp necessárias para a sincronização de imagem e áudio e para possibilitar o sequen-
ciamento correto pela aplicação. O RTP possibilita à aplicação identificar perdas e avaliar
quanto tempo uma amostra pode permanecer armazenada em um buffer, aguardando a
chegada do próximo pacote. A recomendação Secure RTP (RFC 3711) permite o uso de cripto-
grafia e autenticação das mensagens RTP e RTCP.
37
Formato do pacote RTP: q
11 Version (V).
11 Padding (P).
11 Extention (X).
11 CSRC Counter (CC).
11 Marker Bit (M).
11 Payload Type (PT).
11 Sequence Number.
11 Timestamp.
11 Synchronization Source (SSRC) Identifier.
11 Contributing Source (CSRC) Identifiers.
Os 12 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
Payload (áudio, video etc) Figura 2.10

Mensagem RTP.
11 Version (V): versão do RTP.
11 Padding (P): 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 Extention (X): indica presença ou não de extensão de cabeçalho.
11 CSRC Counter (CC): contador do número de identificadores CSRC após o cabeçalho fixo.
11 Marker Bit (M): delimita um conjunto de dados relacionados, o início de uma rajada de
áudio ou o fim de um quadro de vídeo.
11 Payload Type (PT): indica o formato da carga do RTP e determina sua interpretação
pela 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.
11 Synchronization Source (SSRC) Identifier: utilizado para identificar um fluxo específico

Serviço fone@RNP
em uma sessão RTP. Necessário para o receptor agrupar pacotes com o mesmo SSRC
para reprodução.
11 Contributing Source (CSRC) Identifiers: lista de identificadores CSRC inseridos por mixers.
11 V – Versão: 2 (RFC 3550).
11 p – padding = 1, se o pacote contém enchimento para completar múltiplos de 32 bytes.
38
11 x - 1, se houver extensão de cabeçalho.
11 Payload Type (PT): tipo de aplicação (codec), definido nas RFCs 1890 e 3551 (PT=200/RTCP).
11 cc (CSRC COUNT): número de fontes de mídia contribuintes.
11 m (marker): depende do PT (igual a 1), por exemplo, quando houver supressão de silêncio.
11 Número de sequência: de 0 a 65535, é inicializado aleatoriamente e incrementado de

um a cada pacote transmitido.
11 Timestamp: 32 bits, utilizado para calcular o jitter.
11 Synchronization source (SSRC): identificador da fonte e sincronismo.
11 Contributing source (CSRC): identifica as fontes contribuintes para mixagem.
11 Sessão RTP: cada fluxo de voz contém uma sessão RTP e uma RTCP.
RTP RTCP RTCP RTP

Figura 2.11 UDP UDP
Fluxo de IP IP
sessão RTP.
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 perdidos (por exemplo, amostras de áudio ou quadros de vídeo).
O valor do timestamp (estampa/selo de tempo) do cabeçalho RTP pode ser utilizado para
determinar o atraso entre a fonte e o receptor. O valor do timestamp é marcado pelo trans-
missor 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)

11 Protocolo que complementa o transporte de dados feito pelo RTP. q
11 Permite o monitoramento da entrega de dados de forma escalável em redes multicast.
11 Oferece funcionalidades mínimas de controle e identificação.
11 Baseado na transmissão periódica de pacotes de controle para todos os participantes

de uma sessão RTP.
11 Utiliza o mesmo mecanismo de distribuição definido para os pacotes que compõem

os fluxos de dados das aplicações.
Desempenha quatro funções:
11 Prover informação a respeito da qualidade da distribuição dos dados de um fluxo.
11 Transportar um identificador de nível de transporte persistente para um transmissor

em uma sessão RTP.
22 Nome canônico (canonical name ou CNAME).
11 As funções anteriores requerem que todos os participantes enviem pacotes

periodicamente.
11 Transportar informações mínimas de controle de sessão.
39
Informações geradas pelo RTPC: q
11 Sender Report (SR).
11 Receiver Report (RR).
11 Source Description (SDES).
11 BYE.
11 APP.
A frequência de transmissão de pacotes de controle pode variar com a quantidade de par-

ticipantes 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 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 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 streamings, como voz

e vídeo.
O RTCP controla a taxa de informações de controle que os participantes devem enviar 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.
11 Sender Report (SR): para estatísticas de transmissão e recepção de participantes que

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.
11 Estrutura do RTCP.
V P IC PT Length
Format-specific information
Padding if P=1
Serviço fone@RNP
V = version number
P = padding
IC = item count Figura 2.12
PT = packet type Mensagem RTCP.
40
Há cinco tipos de pacotes RTPC definidos na especificação do RTP, um para cada mensagem
discutida anteriormente: SR, RR, SDES, BYE e APP. Todos esses pacotes seguem uma estru-
tura comum, ilustrada na Figura 2.12.
Os cabeçalhos dos pacotes RTCP têm em comum cinco campos que ocupam 32 bits:
1. 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.
2. 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.
3. 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.
4. Tipo do pacote (PT): identifica o tipo de informação contida no pacote. Atualmente

existem cinco tipos.
5. Comprimento (Length): indica o tamanho do conteúdo do pacote contido após esse cabe-
çalho comum.
Os pacotes RTCP nunca são transmitidos individualmente. Eles são sempre agrupados para
a transmissão, formando pacotes compostos.
Empacotamento da voz – codec

11 Pulse Code Modulation (PCM). q
11 Como converter áudio analógico em digital?
33 Exemplo com símbolos de 3 bits.
22 Sinal é discretizado (gera erro de amostragem).
22 Como minimizar o erro de quantização (duas formas)?
22 Que taxa de amostragem deve ser utilizada, supondo que:
33 Frequência da voz humana: 20 Hz – 6.000 Hz (banda de 4 kHz fornece inteligibi-

lidade perfeita).
33 Frequência do ouvido humano: 20 Hz – 20.000 Hz.
22 Qual o número de níveis e amostras no PCM comercial?
O primeiro passo para a codificação de áudio consiste na captura dos sinais sonoros (ondas
sonoras) e transformação destes em sinais digitais. Como é feita a conversão de sinais ana-
lógicos para sinais digitais?
Uma técnica bastante utilizada em telefonia é o Pulse Code Modulation (PCM). Ele analisa
o sinal analógico em instantes uniformes de tempo, obtém a magnitude do sinal nesses
instantes e representa essa magnitude de forma numérica e binária. A imagem seguinte
mostra um exemplo de um sinal de áudio analógico que será convertido para digital:
41
Figura 2.13
Amostragem de
sinal analógico.
O eixo y do gráfico mostra a magnitude do sinal e o eixo x do gráfico denota o tempo. A linha
azul representa a onda sonora, enquanto as linhas verticais ao longo do gráfico marcam os
momentos em que serão obtidas amostras da onda sonora, ou seja, os momentos onde a
magnitude da onda será representada por um número binário.
O próximo gráfico mostra o resultado da aplicação do PCM sobre a primeira parte da onda:
111
110
101
100
011
010 Figura 2.14

001 Quantização e
000 codificação de sinal
0 0 1 0 0 1 1 1 analógico.
0 1 0 1 1 0 1 1
0 1 0 1 1 1 0 1
O eixo y mostra uma escala com um número para cada linha horizontal. Esse número
está representado em binário (com 3 bits para facilitar o entendimento) e corresponde ao
símbolo que será utilizado pelo PCM para representar cada uma das oito linhas horizontais.
A cada instante de tempo (linhas verticais) o PCM verifica a magnitude da onda e encontra a
linha horizontal que mais se aproxima desse valor. Ele usa então o símbolo associado a essa
linha para representar a magnitude da onda nesse instante. Esse processo vai se repetindo
em instantes de tempo uniformes, gerando os símbolos que representam a onda. Esses
símbolos estão exibidos no gráfico ao longo do eixo x (000, 011, 100 etc.). A linha vermelha
mostra o formato com que a onda passa a ser representada após ser convertida para o
formato digital pelo PCM.
Cada valor obtido pelo PCM ao longo do tempo é chamado de uma amostra do sinal, e por
isso esse processo é chamado de amostragem da onda sonora. A definição do número de
amostras obtidas é um parâmetro muito importante no processo, que influencia direta-
mente na qualidade do sinal digital. Quanto maior o número de amostras, maior será a
proximidade do sinal digital com o sinal analógico, mas também maior será a quantidade de
dados necessários para representar esse sinal. Há um teorema, o teorema de Nyquist, que
indica que a taxa de amostragem do sinal deve ser o dobro ou mais do que a frequência do
Serviço fone@RNP
sinal. Esse teorema é muito usado como base para definição da taxa de amostragem que
será utilizada.
A definição da taxa de amostragem normalmente é baseada na frequência da voz humana e

na sensitividade do ouvido humano. A voz humana pode variar entre 20 Hz e 6.000 Hz, apro-
ximadamente. Entretanto, limitando em 4 kHz a conversa fica totalmente inteligível, pois
42
frequências altas são mais raras. Portanto, muitos sistemas que trabalham com voz humana
tomam como base a frequência 4 kHz, que, aplicando o teorema de Nyquist, indica o uso de
uma taxa de amostragem de 8 kHz ou 8.000 amostras por segundo.
Já o ouvido humano é capaz de perceber sons entre 20 Hz e 20 kHz, aproximadamente, ou

seja, sons com frequências acima de 20 kHz não podem ser ouvidos. Esse conhecimento
costuma ser utilizado na digitalização de sons mais complexos que a voz, onde se deseja
a capacidade de representação de todo o espectro de frequências que pode ser ouvido
pelo homem. Em CDs de áudio, por exemplo, é utilizada a taxa de amostragem de 44.1 kHz,
pouco mais que o dobro da frequência máxima ouvida pelo homem.
Outro parâmetro que influencia diretamente na qualidade do sinal digital é o número de bits
utilizado em cada amostra. No exemplo anterior foram utilizados 3 bits por motivos didá-
ticos. Com um número maior de bits é possível representar mais fielmente o sinal analógico
(mais linhas horizontais no gráfico), reduzindo a diferença entre os sinais, o que é chamado
de erro de quantização. Em CDs de áudio, são utilizados 16 bits para cada amostra. Em tele-
fonia se trabalha com 8 bits por amostra.
Compansão do sinal: q
11 Voz pode variar 10 mil vezes, pois o ser humano pode falar baixinho ou gritando e o
outro lado deve ouvir perfeitamente. Como lidar com isso?
Outra técnica aplicada durante a digitalização de sinais sonoros é a compansão do sinal, repre-
sentada na figura a seguir. Esse processo é necessário, pois a amplitude dos sinais sonoros
pode variar muito. A voz humana pode variar 10 mil vezes, pois o ser humano pode falar muito
baixo ou gritando, e em ambos os casos deve ser totalmente entendido no destino. Isso cria
um problema para a digitalização, pois seriam necessários muitos bits para representar cada
amostra (o ideal seriam 13 bits por amostra, mas comercialmente são usados 8).
No processo de compansão, os sinais mais fracos são elevados e os mais fortes são redu-
zidos, e assim todos podem ser representados por um número fixo de bits, pois o sinal
analógico da voz é “homogeneizado”. Dessa forma, se a pessoa fala baixo, sua voz é ampli-
ficada antes da digitalização, e se fala alto, não é amplificada. Assim, todos os sinais podem
ser representados com os 8 bits, economizando na taxa de transmissão via rede. As duas
w
formas mais utilizadas de compansão são chamadas de lei A (mais usada na Europa) e lei μ
(mais usada nos Estados Unidos e Japão).
Saiba mais
Vs
Tutorial de VoIP dispo-
nível em: http://www.
teleco.com.br/tutoriais/
tutorialtelip/pagina_1.
asp
• Compansão segundo lei A ou µ (analógico)

• Usar 13 bits e comprimir segundo lei A ou µ (digital)

Figura 2.15
Compressão do
PCM.
Ve
43
Codec
11 Codec é uma abreviação de codificador-decodificador. q
11 Codecs especificam como os sinais analógicos da voz devem ser codificados
em dados digitais.
11 Codecs permitem compressão dos dados.
11 Grande parte dos padrões usa técnicas baseadas na codificação da forma de onda (PCM).
O 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, compreen-
dendo a amostragem do sinal. Gera-se, então, um formato digital, denominado Pulse Code
Modulation (PCM), usado em vídeo e áudio conferência e em meios de comunicação digital.
O codec realiza 8 mil amostras por segundo (125µsec/amostra), devido ao teorema de

Nyquist, que diz que essa medida é suficiente para capturar toda a informação em um canal
telefônico com largura de banda de 4 KHz. Em uma amostragem menor, a informação trans-
mitida seria perdida; já em uma amostragem maior, nenhuma informação adicional seria
acrescentada. A técnica 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.
O processo de codificação envolve uma transformação conhecida como conversão analógico-

-digital ou conversão A/D. Durante o processo de reprodução, deve ser adotada uma trans-
formação no sentido inverso, conhecida como conversão digital analógica ou simplesmente
D/A. O processo A/D consiste em capturar amostras da informação original em pequenos
intervalos de tempo, criando uma representação para cada uma das amostras, com base em
um código de representação bem conhecido. Na conversão D/A, com base no mesmo código
de representação, cada amostra é restaurada em seu formato original e reproduzida.
A seguir veremos três técnicas de codificação: a codificação de forma de onda, codificação

paramétrica e codificação híbrida.
Codificação de forma de onda

11 Na origem: conversão A/D -> Analógico-Digital. q
11 No destino: conversão D/A -> Digital-Analógico.
11 O esquema mais utilizado é o ADPCM.
11 Baseada em predição linear.
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.
Codificação paramétrica
11 Codificadores paramétricos também são denominados vocoders. q
Serviço fone@RNP
11 A classe de vocoders mais utilizada é a Linear Predictive Coding (LPC).
A natureza do sinal (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 intervalos curtos de tempo (10 a 30 ms).
44
A classe de codificadores paramétricos mais utilizada é a dos vocoders Linear Predictive
Coding (LPC). 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
11 Codificadores híbridos combinam características dos codificadores de forma de onda q
e dos vocoders.
11 A maioria dos codificadores híbridos utiliza o modelo de codificação Code Excited

Linear Predictive (Celp).
A codificação híbrida usa conceitos das duas outras formas de codificação (paramétrica e
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. Como vimos, um fator a ser considerado é o delay
inserido pelo codificador, onde de maneira geral quanto menor for a taxa do codec, maior
será seu delay.
Em uma rede de pacote, onde os pacotes de voz podem sofrer grandes delays, a escolha do
codec em função do seu atraso pode ser um diferencial do projeto em 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 próximo de zero, boa qualidade e livre de licença.
Padrões de codificação de voz

Principais padrões: q
11 G.711.
11 G.729.
11 G.723.1.
11 iLBC.
A tabela seguinte 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.
Padrão Faixa de frequência Taxa de transmisssão Latência Qualidade

G.711 300 Hz-3.4 kHz 64 kbit/s <1 Excelente
G.722 50 Hz-7 kHz 48, 56 ou 64 kbits/s <2 -
G.722.1 14 kHz 24-32 kbit/s - Boa
G.722.2 50 Hz-7 kHz 6.6-23.85 kbit/s - -
G.723.1 8 kHz 5.3 ou 6.3 kbit/s 100 Razoável a boa
45
Padrão Faixa de frequência Taxa de transmisssão Latência Qualidade
G.726 8 kHz 16-40 kbit/s 60 Boa a razoável

Tabela 2.4
G.728 300 Hz-3.4 kHz 16 kbit/s <2 Boa
Quadro
G.729 8 kHz 8 kbit/s 25-35 Boa comparativo de
codecs.
11 Padrão G.711: é um dos melhores oferecidos pelo mercado, com delay próximo de zero,
embora 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 codec não comprime, sendo utilizado em transmissão de fax.
11 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. Existe a versão G729a, menos complexa que
a G729, e a versão G729b, com capacidade de inserir ruído de conforto nas ligações que
utilizam detecção de atividade de voz (VAD).
11 Padrão G 723.1: possui taxas menores que o G.729, sendo um codec ITU que também
necessita de pagamento de licença. Com taxas de 6,3 ou 5,3 Kbits/seg, seu atraso é da
ordem de 37,5 mseg.
11 Codec iLBC: tem fonte aberta, sem exigência de pagamento de licença, sendo uma boa
opção de solução de fonte aberta. Sua taxa é da ordem de 13,3 Kbits/seg.
G.711
11 Codificador padrão ITU-T de larga aplicação. q
11 Representa os sinais de voz usando o formato PCM.
11 Comprime amostras PCM com 13 ou 14 bits em 8 bits usando escala logarítmica,

gerando 64 kbps.
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 3.400 Hz.
Com isso, cada canal de voz precisa de 64 kbps.
Dois algoritmos foram definidos no padrão ITU-T G.711: U (ulaw) e A (alaw); o primeiro é utili-
zado na América do Norte e no Japão; o segundo 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 dupli-
cando o passo de quantização a cada vez que a intensidade do sinal era duplicada; desse
modo obteve-se uma constante.
G.729
11 Padrão ITU-T para codificação de sinais de voz a uma taxa de 8 kbps, com quadros de q
2 ou 8 bytes a cada 10 ms.
11 Utiliza o algoritmo CS-Acelp, baseado no modelo de codificação Celp.

Serviço fone@RNP
11 Desenvolvido originalmente para uso na telefonia fixa com comutação de circuito.
O codificador G.729 codifica sinais de voz a uma taxa de 8 kbps usando o modelo Conjugate
Structure Algebraic Code Excited Linear Prediction (CS-ACelp), que é baseado no modelo de
codificação Code Excited Linear Prediction (Celp). Ele é projetado para operar com o sinal de
46
voz de entrada já convertido para o formato PCM uniforme, com 16 bits/amostra e taxa de
amostragem de 8 kHz.
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. Esses ú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
11 Padrão ITU-T para taxas de bits muito baixas (5,3 ou 6,3 kbps), desenvolvido para uso q
em telefonia por redes de pacotes.
11 Para taxas de 5,3 kbps, usa o algoritmo Acelp.
11 Para taxas de 6,3 kbps, usa o algoritmo MP-MLQ.
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 Multipulse Maximum
Likelihood Quantization (MP-MLQ) para gerar o sinal de excitação, enquanto a codificação
em taxa baixa (5,3 kbps) usa um modelo Algebraic Code Excited Linear Prediction (Acelp).
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
11 Internet Low Bit Rate Codec (iLBC) se encontra em caráter experimental, a ser padro- q
nizado pela IETF.
11 Desenvolvido para propiciar comunicação robusta em VoIP, com tolerância a perdas e

recuperação de erros.
11 Baseado em predição linear; não usa o modelo Celp.
11 Opera a taxas de 13,33 kbps (399 bits em quadros de 30 ms) ou 15,20 kbps (303 bits
em quadros de 20 ms).
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.
47
Características de escolha do codec
11 Taxa. q
11 Atrasos.
11 Qualidade da Voz.
11 Complexidade.
Ao escolher um codec, o administrador deverá levar em conta características sobre o

consumo de banda do codec, os atrasos implicados pelo codec nos tempos de processa-
mento, de quadro e de look-ahead. O administrador deve também atentar para informações
do codec sobre a qualidade da voz e a complexidade exigida por ele.
Serviço fone@RNP
48
Atividade 2.1 – Capture e avalie as mensagens SIP
Análise de mensagem de autenticação
1. Certifique-se de que o softphone 3CX ou o X-Lite do seu computador não estão sendo
executados.
2. Inicialize o Wireshark para sniffar a rede.
3. Inicialize a captura de pacotes na rede.
4. Inicialize novamente o softphone e avalie as mensagens de registro que o softphone

trocará com o servidor VoIP.
No Wireshark, habilite o filtro das mensagens pelo termo SIP e, com base nas informações
capturadas, responda ao questionário abaixo:
a. Sobre qual protocolo de transporte o protocolo SIP está configurado para trafegar na rede?
b. Sobre qual protocolo de transporte o áudio das chamadas está configurado para trafegar
na rede?
c. Quais são as portas de comunicação entre o cliente SIP e o servidor VoIP?
d. Detalhe o Status-Line do protocolo SIP e informe a sua versão.
e. Em Status-Code, informe a sequência obtida durante a autenticação.
f. Durante o processo de autenticação entre cliente e servidor, qual o comportamento

observado?
49
5. Crie uma tabela de estatística utilizando o Wireshark: clique em Telephony>SIP e, em seguida,
em Create Stat, e preencha o quadro abaixo de acordo com o resultado obtido na captura.
Figura 2.16
Janela de
estatísticas SIP.
As próximas atividades deverão ser realizadas em dupla.
Análise de mensagem de voz
1. Efetue uma chamada entre os clientes, mantenha um diálogo entre eles e finalize a
chamada, mantendo o Wireshark ativo, “sniffando” as mensagens.
2. No Wireshark, acesse o menu Telephone e em seguida selecione a opção Flow Graph. Com
as informações exibidas, responda ao questionário a seguir:
a. Quais são os endereços de origem e destino durante a ligação?
b. Por que a primeira requisição INVITE foi negada?
c. Em que mensagens há a negociação de codecs e portas de comunicação de mídia?

Serviço fone@RNP
d. Como identificar as portas RTP que serão utilizadas?
50
e. Qual a sequência de pacotes durante o encerramento de uma ligação?
Figura 2.17
Janela de detecção
de chamadas VoIP.
No Wireshark, acesse o menu Statistics e em seguida selecione VoIP Calls. Selecione a captura e
execute o Player, conforme ilustra a figura a seguir. Será exibida uma tela onde deverá ser
executado o Decode. A partir desse instante escutaremos a conversa realizada entre os clientes.
Na tela a seguir, você poderá selecionar o canal que escutará ou ambos os canais.
Figura 2.18 a. Quais as opções de codecs anunciadas?

Janela de
decodificação do
áudio capturado.
b. Existem mensagens provisórias antes de 200 OK ?
51
c. Qual é o codec de áudio utilizado durante a ligação?
d. Qual é a porta utilizada para o transporte de áudio?

Serviço fone@RNP
52
3
Princípios do serviço VoIP na
instituição usuária
objetivos
Ambiente local e seus serviços, regras de encaminhamento, plano de discagem

e adesão ao serviço.
conceitos
Apresentar o ambiente local do fone@RNP, correspondente aos servidores cuja
responsabilidade de administração recai sobre os técnicos indicados pelas instituições
clientes. Conhecer os requisitos de hardware e a configuração dos servidores
que compõem este ambiente, assim como a estrutura de uma instituição usuária.
Uma instituição usuária participante do serviço fone@RNP deverá seguir o modelo padrão
de instituição. Esse modelo encontra-se na versão 2. Ele pode ser obtido através de um
sistema de instalação automático, que obtém dados dinamicamente da base de dados da
RNP e através da tela de setup com o administrador.
Operadora
Fone@RNP
de telefonia
Capítulo 3 - Princípios do serviço VoIP na instituição usuária
MAQ1 MAQ2 Central PBX
Figura 3.1
Estrutura física do
serviço fone@RNP
numa instituição
Ramal
usuária na versão 2.
Cliente Cliente
VoIP VoIP
Conforme apresentado na figura anterior, a estrutura do serviço na versão 2 é formada por

dois servidores com as seguintes características mínimas:
11 Processador: Pentium 4 com 3 Ghz.
11 Memória RAM: 1 GB.
53
11 Disco rígido: 40 GB.
11 1 Porta PCI ou PCI-e (para máquinas físicas que tenham conexão com a telefonia).
Esses servidores se encaixam perfeitamente no sistema de virtualização, facilitando assim a

administração das máquinas 1 e 2. Contudo, caso a máquina 2 possua comunicação com o
sistema de telefonia convencional, esta deverá ser física para existir o acesso às portas PCI
ou PCI-e.
Apache para administração
dos usuários
Asterisk
Gateway VoIP/PBX
PSTN/PBX
FreeRadius
co
fone@RNP
nt
a
Consulta
bi
lid
OpenLDAP
ad
Contabilidade
e
Diretório para identificação
Cliente SIP Ambiente SIP o e autenticação de usuários
çã
ica
ent
A ut
OpenSER
X-lite Consulta
Proxy SIP
Contabilidade
PostgreSQL Apache para disponibilização
de estatísticas
A Figura 3.2 apresenta os principais serviços presentes numa instituição usuária partici- Figura 3.2
pante do fone@RNP utilizando a versão 2. O principal serviço desse conjunto é o OpenSER, Serviços locais na
instituição usuária
que permite o estabelecimento de sessões SIP dos clientes VoIP (X-lite, Telefones IPs ou ATAs ), na versão 2.
dos gateways Asterisk ou com outras instituições do fone@RNP.
A consulta de informações sobre roteamento, autenticação, autorização e contabilização

pelo OpenSER é feita em outros dois softwares, o FreeRadius e o PostgreSQL. A dependência
do OpenSER com o FreeRadius é fraca, pois, para consultar informações sobre autenticação
ou autorização, o OpenSER não necessita abrir conexões com o FreeRadius.
No entanto, a dependência do OpenSER com o PostgreSQL é forte. Ao inicializar o processo

do OpenSER, é aberta uma conexão com o PostgreSQL. Caso essa conexão seja perdida, o
processo do OpenSER identificará essa interrupção e encerrará o processo.
Bases de dados
No fone@RNP, o PostgreSQL possui quatro base de dados: asterisk, radius, openser e
chamadas. A base de dados asterisk mantém as chamadas contabilizadas pelo gateway
Asterisk. A base de dados radius mantém dados de execução do FreeRadius e chamadas
contabilizadas pelo Radius – esse serviço foi depreciado com o desuso do H.323. A base
Serviço fone@RNP
de dados openser mantém informações de roteamento e as chamadas contabilizadas pelo

SIP proxy. A base de dados com o nome chamadas contém informações do sincronismo de
dados da RNP com a instituição usuária e todas as chamadas consolidadas pela ferramenta
de consolidação local de chamadas.
54
A ferramenta de consolidação de chamadas é responsável pela leitura e interpretação dos
dados gerados pelos dispositivos que armazenam os dados das chamadas e gera um único
registro consolidado para cada chamada. Dessa forma, torna-se fácil a realização de estudos
estatísticos do uso do serviço baseado nesse conjunto de informações consolidadas.
Autenticação de usuários (ramais IP)

O FreeRadius é a ferramenta que permite a comunicação com a base de usuários e a base de
contabilização. Essa ferramenta era amplamente necessária com o uso do H.323 e GnuGK
como gatekeeper H.323 do serviço. Atualmente, com o desuso do H.323, a dependência do
FreeRadius no serviço é a realização da autenticação dos usuários para o OpenSER.
O OpenLDAP é a base de usuários do serviço fone@RNP. O uso do LDAP foi motivado pela
expectativa da RNP de incentivar o uso dessa estrutura nas instituições usuárias. Durante o
desenvolvimento da versão 2 do fone@RNP, não havia nenhuma estrutura pré-definida para
uso. Sendo assim, o LabVoIP desenvolveu um sistema particular que permitisse o desenvol-
vimento de diversas aplicações. Atualmente, esse é o modelo válido no serviço fone@RNP.
Gateway para telefonia convencional

Por fim, ainda guiado pela Figura 3.2, o gateway Asterisk é o serviço que realiza a integração
do ambiente VoIP com a telefonia convencional. Importante ponto do serviço VoIP, essa
integração permite o acesso ao serviço VoIP de usuários da telefonia legada e permite que
os usuários VoIP comuniquem-se com ramais convencionais das instituições usuárias e com
telefones públicos das localidades onde existe um ponto de presença do serviço.
Outros serviços
Outros softwares também fazem parte do cenário local da instituição. Eles dão apoio ao
objetivo principal do serviço, complementando a solução do fone@RNP. Os softwares são o
Consolida, Slon e Apache2. O Consolida, conforme mencionado, realiza a consolidação das
chamadas contabilizadas pelo Asterisk, OpenSER e FreeRadius.
O Slon permite a sincronização de dados da base Mestre da RNP com a base escrava “cha-
madas” da instituição local. A sincronização é essencial para que os softwares de rotea-
mento e de consolidação dos dados possam interpretar as informações corretamente e de
forma atualizada. O Apache2 permite a utilização das ferramentas web Féjeca e Estatística.
55
Figura 3.3
Página inicial da
ferramenta de
gerência Féjeca.
O sistema web Féjeca é a principal ferramenta de gerência do serviço local. Através desse
sistema é possível gerenciar a base de usuários da instituição (cadastrar/buscar/editar/
apagar os usuários), identificar os usuários que estão on-line no serviço e acessar outras
ferramentas web.
O sistema web de Estatística permite a extração de relatórios e gráficos capazes de apre- Figura 3.4
sentar o fluxo de chamadas existente na instituição, possibilitando relatórios como número Gráfico do sistema
web para geração
Serviço fone@RNP
de chamadas nos últimos dias, chamadas por dias no mês, chamadas por hora no dia, de relatórios.
distribuição da duração de chamadas, duração da chamada por dia ou hora, motivo da
desconexão da chamada, intensidade da chamada e matriz de tráfego da chamada.
56
Distribuição dos serviços nas máquinas 1 e 2
11 Motivação das máquinas 1 e 2. q
11 Distribuição atual dos serviços.
11 Como deverá ser a distribuição no futuro.
Durante o projeto VoIP4All, projeto embrionário do serviço fone@RNP, surgiu a ideia de

uma máquina ser o servidor VoIP e outra pudesse ser gateway para a integração com o PBX.
Porém, essa ideia ganhou novo rumo. Com a adição da função de gateway, a máquina 2
exerce também as funções de base de usuários, base de dados e servidor web.
Operadora
Fone@RNP de telefonia
OpenSER
MediaProxy
RadiusClient-NG
MAQ1 MAQ2 Central PBX
GnuGK
Asterisk (Gw SIP/H.323)
Asterisk
Zaptel
FreeRadius
Ramal
Cliente Cliente OpenLDAP
VoIP VoIP PostgresSQL
Slon
Apache2 (Fejeca, estatística,
Phppgadmin, Phpldapadmin)
Consolida
Figura 3.5 Conforme descrito na Figura 3.5, a máquina 1 detém os serviços de Proxy VoIP, tanto SIP ou
Descrição dos H.323. Serviços como MediaProxy e RadiusClient-NG são utilizados pelo OpenSER para a
serviços por
máquina numa gerência na mídia e para permitir o acesso ao FreeRadius, respectivamente.
instituição usuária.
Os softwares Asterisk, na função de gateway SIP/H.323, e o GnuGK, que exerce a função de

Proxy H.323, estão em desuso devido à não adesão das instituições locais ao serviço H.323.
A máquina 2 possui duas funções básicas para a disponibilidade do serviço. A função inicial
de gateway permite que através do Asterisk e do driver Zaptel o serviço possa ter integração
com a telefonia convencional. A função secundária é a base de dados e a base de usuários
da instituição através do PostgreSQL, do OpenLDAP e do FreeRadius.
As funções secundárias da máquina 2 são de servidor web para os sistemas de Féjeca, Estatís-
tica, PHPPgAdmin, PHPLdapAdmin e para a execução em background do Consolida e do Slon.
Na próxima versão do fone@RNP, existe a tendência de eliminar o serviço da máquina 2

FreeRadius e os serviços da máquina 1, como o Asterisk gateway SIP/H.323 do GnuGK e do
RadiusClient-NG.
57
Com as eliminações esperadas, o serviço provavelmente será redistribuído, mantendo
as bases de usuário, base de dados e servidor web na máquina 1, deixando a máquina 2
apenas com o serviço de gateway com o Asterisk e o driver da placa.
Encaminhamento de chamadas ao serviço

11 Autenticação e autorização de chamadas. q
11 Regras de discagem do serviço fone@RNP.
11 Encaminhamento de chamadas no gateway.
Todas as chamadas estabelecidas pelo serviço fone@RNP são primeiramente autenticadas

e autorizadas pelo proxy. Para realizar a autenticação, o proxy inicialmente identifica se a
chamada foi originada por um equipamento confiável, como outro proxy do serviço fone@
RNP ou um gateway do serviço local da instituição.
Caso o proxy não identifique a chamada como originada por um proxy conhecido, ele rea-
lizará a autenticação do serviço pelo modo http-digest do SIP. Caso não seja autenticado, a
chamada será encerrada pelo gateway.
Ao terminar a autenticação da chamada, o proxy identifica o destino da chamada e valida

se a origem pode realizar chamada para esse destino. As regras de autorização são as
seguintes no serviço fone@RNP:
11 Uma chamada originada por um proxy de um serviço do fone@RNP não pode ser
destinada a outro proxy do serviço fone@RNP, ou seja, duas instituições devem sempre
realizar chamadas diretamente no serviço fone@RNP, não permitindo transmiti-las a
instituições terceiras.
11 Uma chamada originada por um gateway local não pode retornar ao mesmo gateway
local, não permitindo transmissões de loops na instituição.
11 Nenhum usuário pode realizar ligações para telefones móveis.
11 Um usuário de origem rede pública não pode realizar chamadas para telefones públicos.
Todas as instituições usuárias possuem as seguintes regras de discagem por padrão no

serviço fone@RNP:
Origem Padrão de discagem Premissa do padrão Destino
Ramal VoIP XXXX Chamada destinada a ramal do PBX da insti- Ramal do PBX.
tuição.
Ramal VoIP 1XXXXXXX Chamada destinada a ramal VoIP da mesma Ramal VoIP.
localidade.
Ramal VoIP [2-5]XXXXXXX Chamada destinada a telefone convencional da Ramal do PBX ou

mesma localidade que pode ser ramal PBX de telefone público.
uma instituição ou telefone público.
Ramal VoIP 0XX1XXXXXXX Chamada destinada a ramal VoIP de outra Ramal VoIP.
localidade.
Ramal VoIP 0XX[2-5]XXXXXXX Chamada destinada a telefone convencional Ramal do PBX ou

Serviço fone@RNP
de outra localidade que pode ser ramal PBX de telefone público.

uma instituição ou telefone público.
Ramal VoIP 00XXXXXXXXXX. Chamada destinada a número internacional. Telefone internacional.
58
Origem Padrão de discagem Premissa do padrão Destino
Ramal do PBX 1XXXXXXX Chamada destinada a ramal VoIP da Ramal VoIP.

mesma localidade a partir do IVR.
Ramal do PBX [2-5]XXXXXXX Chamada destinada a telefone conven- Ramal do PBX ou

cional da mesma localidade, que pode ser telefone público.
ramal PBX de uma instituição ou telefone
público a partir do IVR.
Ramal do PBX 0XX1XXXXXXX Chamada destinada a ramal VoIP de outra Ramal VoIP.
localidade a partir do IVR.
Ramal do PBX 0XX[2-5]XXXXXXX Chamada destinada a telefone conven- Ramal do PBX ou

cional de outra localidade que pode ser telefone público.
ramal PBX de uma instituição ou telefone
público a partir do IVR.
Ramal do PBX 00XXXXXXXXXX. Chamada destinada a número interna- Telefone

cional a partir do IVR. internacional.
Telefone público 1XXXXXXX Chamada destinada a ramal VoIP da Ramal VoIP.

mesma localidade a partir do IVR.
Telefone público [2-5]XXXXXXX Chamada destinada a telefone conven- Ramal do PBX ou

cional da mesma localidade, que pode ser telefone público.
ramal PBX de uma instituição a partir do
IVR (telefone público é bloqueado).
Telefone público 0XX1XXXXXXX Chamada destinada a ramal VoIP de outra Ramal VoIP.
localidade a partir do IVR.
Telefone público 0XX[2-5]XXXXXXX Chamada destinada a telefone conven- Ramal do PBX ou

cional de outra localidade, que pode ser telefone público.
ramal PBX de uma instituição a partir do
IVR (telefone público é bloqueado).
Tabela 3.1 As possibilidades de integração são inúmeras no serviço fone@RNP. Ramais do PBX e
Tabela de ramais VoIP têm total acesso a qualquer número acessível ao serviço, seja outro ramal do
roteamento de
chamadas. PBX, outro ramal VoIP ou um telefone público, que poderão ser números da mesma
localidade ou de outras.
Contudo, chamadas originadas por telefones públicos só poderão ser completadas quando
destinadas a ramais do PBX ou ramais VoiP, permitindo números da mesma localidade ou

de outras. A identificação do serviço para origem de ramal do PBX ou telefone público é
realizada a partir de regras no PBX e/ou no gateway. E, ao acessar o IVR no gateway, este,
através dessas regras, determina se a chamada é interna (ramal do PBX) ou externa (tele-
fone público).
59
Ramais
Máquina 1
(Proxy SIP)
Telefones
PABX
Externos
Instituição A Máquina 2 Telefones

(Gateway) SIP
Tele
Cidade A
fone@RNP
Ramais
Telefones
PABX
Externos
Instituição B Máquina 2 Máquina 1 Telefones

(Gateway) (Proxy SIP) SIP
Figura 3.6
Esquema de
Tele integração do
Cidade B
serviço fone@RNP.
Acesso ao serviço
Por fim, para realizar chamadas através do gateway local, o administrador deverá realizar
chamadas utilizando o sistema de IVR (ou URA, em português), para que possa alcançar o
serviço VoIP através de um telefone convencional. O uso do IVR é feito a partir do número de
IVR, número de telefone chave ou tronco do PBX. Qualquer um desses sistemas permite que
o PBX encaminhe a chamada ao gateway. Ao receber a chamada, o gateway identificará a
origem da chamada através de regras pré-definidas com o PBX e tocará o áudio de intro-
dução ao IVR. Durante o áudio, o usuário poderá discar o número que deseja chamar e o
Serviço fone@RNP
gateway repassará a chamada ao Proxy SIP.
60
Instituição
destino
Telefone
destino
Figura 3.7
Esquema de ligação Internet
a partir de ramal
convencional
utilizando IVR. IVR
Controle de chamadas não autorizadas

Como foi apresentado, o serviço fone@RNP faz a interação entre o serviço VoIP e o serviço
de telefonia convencional. Essa integração permite a ampliação da área de cobertura do
serviço, permitindo que usuários VoIP ou usuários do PBX da instituição realizem chamadas
a qualquer destino alcançável pelo serviço, completando chamadas dessas origens para, por
exemplo, números da rede de telefonia fixa que não sejam ramais das instituições do serviço.
Esse tipo de utilização reduz o custo da chamada, substituindo o valor da chamada de longa
distância que seria realizada pela instituição origem por um custo de ligação local a ser reali-
zado pela instituição localizada na mesma cidade do número destino.
Essa chamada exemplificada faz apenas o uso de um pulso, que é o pulso da chamada rea-
lizada da instituição destino para o número destino. A chamada do ramal até o serviço VoIP
não utiliza pulso – pois é uma chamada interna ao PBX da instituição de origem – e entre as
instituições de origem e destino também não utiliza pulso, pois é uma chamada VoIP privada
entre as instituições do serviço.
Esse uso do serviço realizando chamadas que consumam zero ou apenas um pulso por
chamada é autorizado pela agência reguladora do serviço de telecomunicações no Brasil, a
Anatel. Caso a chamada consuma mais de um pulso, ela somente poderia estar sendo trafe-
gada por operadoras autorizadas para esse tipo de serviço.

No caso do serviço fone@RNP, a RNP não possui a intenção de atuar como operadora de
telefonia no país. Por isso, uma chamada tratada pelo serviço fone@RNP não pode utilizar
dois pulsos. Sendo assim, o serviço fone@RNP não autoriza uma chamada a obter um
segundo pulso.
Para a realização desse bloqueio, as configurações dos equipamentos de IVR devem identi-
ficar que a chamada recebida é de um usuário externo – usuário não é um ramal do PBX da
instituição – e repassar essa informação ao serviço. No fone@RNP, os servidores cancelam
todas as requisições de chamada que o proxy tenha identificado como de origem externa e
destino também.
Os equipamentos de IVR repassam a informação de que a origem é um usuário externo

marcando com o número 1 a chamada entre os números de DDD e o número destino. Exem-
plificando essa marcação, caso a origem seja externa e o número discado pela origem seja
08840014001, o equipamento de IVR rescreverá a chamada para 088140014401.
61
No serviço, os equipamentos de IVR realizam a identificação de origem interna ou externa de
diversas formas. Caso o tronco com o IVR seja digital, o número do usuário de origem pode ser
repassado ao IVR, que identifica se esse número pertence à lista de ramais da instituição ou
não. Caso o tronco seja analógico, normalmente as instituições criam números de atendimento
a ramais internos (IVR interno) e números de atendimento a ramais externos (IVR externo).
Adesão do serviço
11 Direcionado às instituições usuárias. q
11 Políticas de uso.
11 Formulário de solicitação.
11 Página do serviço: www.rnp.br/servicos/foneRNP
O serviço fone@RNP é direcionado às instituições usuárias da rede Ipê. Para aderir ao serviço,
é preciso conhecer e concordar com sua política de uso e preencher um formulário de solici-
tação, que está disponível apenas para os contatos técnicos das instituições usuárias.
As solicitações de adesão submetidas via formulário eletrônico serão identificadas por pro-
cessos numerados e avaliadas pela gerência do serviço fone@RNP.
Instalação e homologação do serviço

11 Fluxo de instalação e homologação. q
11 Execução do checklist.
11 Instalação do serviço.
11 Homologação do serviço.
Fluxo de instalação e homologação

O ato de instalar e homologar uma instituição do serviço fone@RNP é composto por
diversas etapas que são detalhadas no modelo da Figura 3.6. Esse modelo é iniciado com a
RNP repassando a solicitação de homologação a uma empresa credenciada por ela. Através
dessa empresa, a RNP encaminha ao responsável da instituição um e-mail padrão que indi-
cará as ações que deverão ser realizadas.
O administrador deverá instalar o Linux Debian 4.0 nas máquinas 1 e 2, conforme descrito no
documento de instalação. Após esse passo, o administrador deverá solicitar a liberação do
firewall da instituição para as máquinas 1 e 2 e realizar os registros SRV no servidor DNS da
instituição conforme descritas no documento de homologação. Ao final, deverá responder à
RNP (com cópia para a empresa) o formulário presente no documento de homologação.
Assim, será possível validar as informações recebidas, cadastrar a instituição no serviço

através da Fegen e solicitar a liberação do firewall da RNP para o acesso das máquinas 1 e
2 da instituição. Posteriormente, a RNP, via empresa de suporte, realiza o checklist da insti-
tuição e, com o sucesso dessa etapa, autoriza o administrador da IU a realizar a instalação
dos pacotes.
Serviço fone@RNP
Ao término da instalação, a instituição é ativada no serviço fone@RNP e realiza os proce-

dimentos de testes e homologação do serviço VoIP da instituição. Para concluir o fluxo, é
executada a verificação de segurança do CAIS/RNP ao serviço VoIP da instituição.
62
Execução do checklist
O checklist é o procedimento realizado pela empresa que presta suporte ao fone@RNP, que
valida as configurações preliminares à instalação dos pacotes do fone@RNP. Esses procedi-
mentos são divididos em:
11 Conferência das informações encaminhadas pelo administrador.
11 Verificação do firewall da instituição usuária.
11 Verificação do firewall da RNP.
11 Verificação do registro SRV no DNS.
11 Verificação da instalação do Linux Debian 4.0 nas máquinas 1 e 2.
O administrador não deverá realizar a instalação dos pacotes antes de obter a auto-
rização da empresa de suporte para continuar a instalação. Caso o checklist falhe, o
administrador deverá rever as configurações preliminares descritas no documento
de homologação.
Instalação do serviço
A instalação do serviço é baseada em pacotes gerados pela equipe do LabVoIP, que per-
mitem a instalação de todas as bibliotecas, binários e configurações para montar o serviço
VoIP local na instituição usuária.
As configurações são baseadas em arquivos pré-formatados com variáveis obtidas através

das informações encaminhadas pelo administrador, e inseridas na ferramenta de gerência
do serviço (FEGEN), e pelo diálogo entre o pacote de instalação e o administrador. Ao final da
instalação, o administrador, junto com a empresa de suporte ao serviço, ativam o fone@RNP
na instituição.
Homologação do serviço
A homologação do serviço, conforme descrita no documento de homologação, é o processo
de realização de testes, validação da instalação e das configurações existentes no serviço
VoIP da instituição usuária. Esses passos permitem que a adição da instituição usuária ao
serviço não vá prejudicar o serviço ou permitir chamadas não autorizadas.

A realização dos testes é feita em conjunto entre o administrador da instituição usuária e a
RNP, via empresa de suporte. São validadas todas as chamadas autorizadas na instituição
usuária e também é verificado se as chamadas não autorizadas estão sendo completadas.
Os procedimentos de instalação e homologação do serviço fone@RNP nas instituições serão

detalhados nas atividades práticas deste capítulo.
63
64
Serviço fone@RNP
O laboratório para estas atividades práticas foi desenhado visando refletir um ambiente real
genérico. Na unidade da Escola Superior de Redes de Brasília, o laboratório possui 24 esta-
ções de trabalho. Cada aluno utilizará uma máquina real, com Windows, softphone e anali-
sador de tráfego, uma máquina real com função de gateway do fone@RNP, onde se encontra
a interface com a telefonia tradicional, e uma máquina virtual, que funcionará como o outro
servidor do fone@RNP.
Na bancada do instrutor existem as máquinas DSER, com IP 192.168.109.250, um PABX que

simulará o PABX convencional das instituições e a própria RTFC. O DSER também funcionará
como repositório da distribuição do fone@RNP, no endereço http://192.168.109.250/debian-
treinamento
Os alunos serão divididos em instituições fictícias, grupos de 01 a 12. A sala de aula também
foi dividida para representarem estados e cidades distintas, cada uma com seu DDD (código
de área) e prefixos fictícios.
A seguir um esquema representando a configuração do laboratório. Cada célula equivale a

dois alunos e uma instituição.
Professor
Código de Área =21
Pref. IP Pref. IP Pref. IP Pref. IP

1301 1301 1303 1304
-XXXX -XXXX -XXXX -XXXX

1301 1301 1303 1304

1301 1301 1303 1304

Figura 3.8
1301 1301 1303 1304
Configuração do
laboratório.
65
Atividade 3.1 – Instalação e homologação do serviço fone@RNP
Neste capítulo observamos a estrutura local das instituições clientes do serviço fone@RNP.
Após a solicitação de adesão ou re-homologação, a instituição recebe um e-mail contendo
instruções e documentos que orientarão o responsável técnico a instalar e homologar sua
instituição no serviço fone@RNP.
Siga os procedimentos do documento de homologação e instale sua instituição de treinamento.
11 Acesse a página de documentação do serviço (www.voip.nce.ufrj.br/dochomolog) e faça

download do documento de homologação e de instalação do serviço.
11 Leia atentamente as seções 1 e 2 do documento de homologação e responda ao questio-

nário com as informações definidas no descritivo da topologia.
11 Encaminhe a resposta ao instrutor e aguarde a sua autorização para a execução da insta-

lação do serviço.
11 Para a instalação do serviço, siga a documentação de instalação nas seções 4 e 5.
11 Para ativar a instituição, siga a documentação de homologação na seção 4, realizando os

itens 4.1, 4.2 e 4.3.
O aluno deve preencher a planilha disponível na área de trabalho.

Serviço fone@RNP
66
4
Manutenção do sistema
objetivos
Manipulação de ramais, detalhamento das chamadas, backup e FÉGECA.
conceitos
Apresentar procedimentos e a ferramenta para operar o serviço fone@RNP, adicionar
rotas e ramais, fazer e restaurar backups e verificar o detalhamento das chamadas,
através de atividades para manutenção local e manipulação de logins e ramais IP.
Configuração de usuários e ramais IP

O fone@RNP possui uma interface gráfica para gerência de usuários locais. Ela fica instalada
na máquina 2, no diretório /ger2 e está acessível a qualquer um. Para acessá-la, basta digitar
na barra de endereço de um browser <IP_MAQ2>/ger2. A princípio, a interface deve funcionar
em qualquer navegador, mas atualmente está homologada apenas para o Mozilla Firefox.
Figura 4.1
Página inicial da
interface gráfica
para manipulação
de ramais IP.
É altamente recomendável melhorar a segurança para acesso controlado a esta interface,

Capítulo 4 - Manutenção do sistema
uma vez que, originalmente, o acesso está aberto a qualquer um que conheça o nome ou
endereço IP da máquina 2. Por exemplo, é possível configurar os endereços IP que possuem
acesso ao sistema no firewall interno do servidor. Também é possível configurar o servidor
Apache para permitir ou negar acesso mediante a inserção de uma senha. À esquerda, a inter-
face apresenta links para a configuração do sistema. Os dois primeiros links são funções de
manipulação de ramais IP, utilizados para adicionar e buscar ramais. O terceiro link é utilizado
para verificar os usuários ou ramais IP que estão ligados e on-line no momento. Se estiverem
na lista apresentada neste momento, é possível chamá-los em seus telefones IP.
67
Os próximos dois links “cadastrar redirect” e “listar redirect” estão fora de uso. Esta função Figura 4.2
seria utilizada para que as ligações feitas para o ramal analógico tradicional de uma pessoa Usuários on-line.
pudesse ser redirecionada para seu telefone IP.
No próximo bloco de funções, os dois primeiros links dão acesso às ferramentas de terceiros
“phppgadmin” e “phpldapadmin”, utilizadas para gerência e manutenção das bases de dados
Postgres e LDAP, respectivamente.
O link “estatísticas” dá acesso a uma interface onde é possível plotar gráficos baseados no
uso do sistema local de telefonia IP. Ao clicar neste link, o administrador tem acesso aos
seguintes tipos de gráficos:
11 Últimos dias.
11 Camadas por dia no mês.
11 Horas do dia.
11 Distribuição da duração das chamadas no mês.
11 Duração por dia.
11 Duração por hora.
11 Motivos de desconexão.
Serviço fone@RNP
11 Intensidade das chamadas.
11 Matrizes de chamadas.
68
Figura 4.3
Tipos de
estatísticas
disponíveis.
Busca de usuários ou ramais IP cadastrados

Para procurar por usuários cadastrados, clique no link “buscar usuário”. Você pode procurar
por nome, número de telefone, nome do usuário ou CPF. O valor digitado no campo de texto
deve estar contido no campo desejado. Por exemplo, foi feita uma busca pelo número de
telefone que contém a string “4061”. Foi encontrado o ramal de número “10204060”.
Figura 4.4
Resultado de busca
por telefone.
Criação de usuários e ramais IP
Para criar um novo usuário ou ramal IP:
11 Clique em ‘Cadastrar usuário’;
11 Preencha as informações indicadas. Os campos com ‘*’ são de preenchimento obrigatório;

22 * Número do telefone: é o número do telefone IP, iniciado pelo prefixo indicado no

processo de adesão. Não utilize pontos ou traços. Não coloque o código de área. Por
exemplo, na RNP-RJ, 1020XXXX.
22 Número do encaminhamento: não utilizado; número do ramal real do usuário.
22 * CPF: digite o CPF do usuário; não há verificação deste campo.
22 Categoria: texto livre para uso interno na instituição cliente.
22 * Nome completo: nome do dono do ramal IP.
69
22 Créditos: utilizado para o sistema de créditos, expresso em minutos; quando os cré-
ditos chegam ao fim, o ramal IP é bloqueado para fazer chamadas.
22 Créditos por período: os créditos são renovados a cada mês automaticamente.
22 Tipo de usuário: texto livre para uso interno na instituição cliente.
22 * E-mail: endereço de e-mail do usuário.
22 Responsável: texto livre para uso interno na instituição cliente.
22 Validade: validade do ramal; após a data especificada o ramal é bloqueado.
22 Endereço IP: caso o endereço IP do ramal seja conhecido e fixo.
22 * Login: login do usuário. Dica de segurança: utilizar um login diferente do número do

ramal. Os mais neuróticos também recomendam ser diferente do endereço de e-mail
e que seja de difícil descoberta.
22 * Senha: Senha do ramal IP. Aqui vale aplicar as recomendações conhecidas para
senhas seguras: não existir em dicionário nenhum, não usar sequências numéricas,
datas de aniversários etc.
11 Clique em “Ok”.
Ao clicar em “Ok”, a ferramenta tenta inserir as informações do usuário na base de dados do

LDAP. Se o número do telefone ou login já existir na base, é reportado erro, informando que
possivelmente já estão cadastrados.
Para verificar quais números estão cadastrados, basta fazer uma busca por número
de telefone, inserindo no campo de pesquisa o prefixo local dos números; por
exemplo, na rnp-rj, 1020.
Serviço fone@RNP
Figura 4.5
Resultado da ação
de adicionar um
ramal IP.
70
Modificação de um usuário ou ramal IP
Para modificar algum ramal IP é necessário primeiro realizar uma busca para identifica-lo no
sistema. Neste exemplo será atualizada a informação de “email” do ramal 10204061, criado
acima.
Buscamos pelo telefone 4061.
Figura 4.6
Busca por telefone.
Clicamos em “editar”, alteramos a informação, reescrevemos o campo “email” e clicamos em “Ok”.
71
Note que nem todas as informações são passíveis de serem alteradas. Dos campos obriga- Figura 4.7
tórios, apenas os valores de email e senha podem ser atualizados. Todos os campos não Edição de ramal.
obrigatórios podem ser alterados. Para alterar outros campos (como “nome completo”, por
exemplo) é necessário remover o ramal IP e criá-lo novamente.
Remover usuário ou ramal IP

Assim como na alteração dos parâmetros dos ramais IP, para removê-los também é neces-
sário realizar uma busca para identificar o ramal desejado. Vamos remover o ramal recém-
-criado 10204061. Após a busca, basta clicar no link “remover”. Ao clicar, o sistema solicita
confirmação da ação.
Serviço fone@RNP
72
Figura 4.8
Remoção de ramal.
11 Clicando em “sim”, o sistema volta para a página inicial.
11 Clicando em “não”, o sistema segue para página de edição do ramal selecionado.
Estatística e CDR
11 Princípios básicos da estatística e CDR. q
11 Contabilidade no serviço fone@RNP.
11 Relatório:
22 Últimos dias.
22 Chamadas por dia no mês.
22 Chamadas por hora no dia.
22 Durações da chamada por hora num dia.
22 Motivo de desconexões das chamadas.
22 Matriz de chamadas.
11 Geração de CDR pelos equipamentos.
11 Consolidação dos dados.
11 Visualização de relatórios.
11 Estatísticas nacionais.
Princípios básicos da estatística e CDR

Estatísticas do serviço VoIP são essenciais para que o administrador possa obter informa-
ções sobre as chamadas realizadas no serviço como duração, origem, destino, motivo de
desconexão, tipos de usuários e instituições envolvidas. Através do sistema de estatística
do serviço, o administrador pode também monitorar e contabilizar o sistema através de
matrizes de tráfego e utilização dos equipamentos e recursos da rede.
Todo o sistema de estatística é baseado na coleta de CDR, acrônimo de Call Detail Record
ou registro detalhado da chamada, conceito herdado do sistema de telefonia convencional.
Os dispositivos participantes da chamada registram informações detalhadas da chamada a
partir da ótica observada por cada dispositivo. Tipo de informações, formato das informa-
ções e formas de armazenamento dependem do dispositivo em questão.
73
Qualquer dispositivo participante pode gerar CDR da chamada, porém, equipamentos fora
do controle do administrador não são considerados na contabilização da chamada. Fora do
controle do administrador, estes equipamentos podem ter suas informações distorcidas e
assim inviabilizar a contabilização da chamada a partir destes registros CDR.
Exemplificando este caso, os telefones VoIP também podem gerar registros CDR. Porém, como
ficam no computador do cliente, os mesmos podem alterar estas informações e corromper a
estatística. Sendo assim, equipamentos como proxies e gateways do serviço VoIP da insti-
tuição são equipamentos confiáveis para a contabilização dos dados a partir dos CDR.
Contabilidade no serviço fone@RNP

Conforme apresentado na próxima figura, para a contabilização das chamadas tratadas
pelo serviço local do fone@RNP, o sistema de contabilização utiliza o proxy SIP e o gateway
de voz Asterisk.
O MediaProxy é outro equipamento que poderia gerar dados adicionais para a conta-
bilização do serviço. O proxy de mídia poderia registrar os áudios que trafegaram pelo
software; porém, estes áudios deveriam ser relacionados às mensagens SIP da mesma
chamada. Outros equipamentos não gerariam informações relevantes para a contabilização
de uma chamada no serviço Fone@RNP.
FONE@RNP Consulta
OpenLDAP
FreeRadius
LDAP Server
SIP ta Radius Server
s ul
Con
DNS
OpenSER + Armazenamento
MediaProxy
Proxy SIP e Mídia to
men
SIP a zena Postgres
Arm Banco de Dados
SIP
SIP SIP SIP

Telefonia
Asterix
GW de voz
X-Lite fonia
Tele PABX
RTFC
ATA
Tel IP Tel
O proxy SIP OpenSER armazena no banco de dados todas as requisições que possuam os Figura 4.9
Serviço fone@RNP
métodos INVITE, CANCEL e BYE e suas respostas finais. Desta forma, o OpenSER gera mais Serviço VoIP
na ótica da
de um CDR para todas as chamadas tratadas pelo proxy. O gateway de voz Asterisk arma- contabilização das
zena apenas um registro por chamada no banco de dados. O CDR será registrado apenas ao chamadas.
final da chamada no banco de dados.
74
Geração da estatística
Consulta
Base de Dados do CDR Consolidado
Armazenamento
Ferramenta de Consolidação
Consulta Consulta
Base de Dados do OpenSER Base de Dados do Asterisk

Armazenamento
Armazenamento Armazenamento
Figura 4.10
Mapa conceitual da
contabilização das
OpenSER Asterisk
chamadas.
No banco de dados PostgreSQL é armazenado os registros dos dispositivos em cada respec-

tiva base de dados OpenSER e Asterisk. Conceitualizando o sistema de contabilização das
chamadas, após serem armazenados nas bases de dados os registros poderão ser tratados
e assim contabilizados.
No fone@RNP foi adotada a ferramenta de consolidação dos registros, compilando todas as

informações registradas nas bases OpenSER e Asterisk para um único registro por chamada.
Periodicamente este daemon identifica novas chamadas armazenadas na base e as compila.
O script consolida é uma ferramenta essencial para que a contabilização das cha-
madas seja realizada. Caso encontre problemas nas estatísticas, sempre verifique se
ele está sendo executado corretamente.
Sobre os registros consolidados que estão na tabela chamadas (da base chamadas), são
obtidas as informações para encaminhar à RNP, para geração da estatística nacional e no
sistema web local para relatórios do serviço VoIP da instituição usuária.
A ferramenta web de estatística pode ser acessada em http://<IP_MAQ2>/estatistica. Trata-se

de uma ferramenta desenvolvida pelo próprio LabVoIP, incluído no sistema do fone@RNP local
e acessível a partir de qualquer browser da instituição usuária. A principal funcionalidade da
ferramenta de estatística é a geração de relatórios para acompanhamento e monitoração do
serviço. A ferramenta realiza consultas à base de dados consolidada, disponibilizando relató-
rios no formato de matrizes e histogramas.
75
Relatórios
Últimos dias
Este relatório apresenta o número de chamadas consolidadas por dia pelo serviço VoIP local
que foram completadas, e as não completadas nos últimos n dias. Por padrão a consulta é Figura 4.11
feita para n igual a 10 dias, mas este valor pode ser modificado. Caso não queira visualizar as Gráfico do número
de chamadas nos
chamadas atendidas ou não atendidas, basta desmarcar a opção direita. últimos dias.
Chamadas por dia no mês

Este relatório apresenta o número de chamadas consolidadas por dia pelo serviço VoIP local
Figura 4.12
que foram completadas e as não completadas no mês especificado. Por padrão, a consulta Gráfico de
é feita para o mês atual, mas este valor pode ser modificado. Caso não queira visualizar as chamadas por dia
chamadas atendidas ou não atendidas, basta desmarcar a opção direita. no mês.
Serviço fone@RNP
76
Chamadas por hora no dia
Este relatório apresenta o número de chamadas por hora consolidadas pelo serviço VoIP
Figura 4.13
Gráfico de local que foram completadas e as não completadas no dia especificado. Por padrão a
chamadas por hora consulta é feita para o dia atual, mas este valor pode ser modificado. Caso não queira
no dia. visualizar as chamadas atendidas ou não atendidas, basta desmarcar a opção direita.
Durações da chamada por hora num dia

Este relatório apresenta as durações das chamadas por hora consolidadas pelo serviço
Figura 4.14 VoIP local que foram completadas no dia especificado. As durações podem ser a máxima,
Gráfico das mínima, média e desvio padrão. Por padrão a consulta é feita para o dia atual, mas este
durações das
chamadas por hora valor pode ser modificado. As visualizações padrão são a máxima e a média, itens que
num dia. também podem ser modificados.
77
Motivo de desconexões das chamadas
Este relatório apresenta os motivos de desconexão das chamadas por quantidade de cha-
madas consolidadas pelo serviço VoIP local no dia especificado. Neste relatório é possível
identificar algum problema no serviço, pesquisando o motivo das desconexões ao serviço.
Por padrão a consulta é feita para o dia atual, mas este valor pode ser modificado.
Figura 4.15
Gráfico dos motivos
de desconexão.
Serviço fone@RNP
78
Matriz de chamadas
Este relatório apresenta as quantidades de chamadas originadas e destinadas para todas as
instituições usuárias do serviço durante o período. Este relatório permite ao administrador
identificar o fluxo de chamadas da sua instituição, e assim obter a média da economia do
serviço para a instituição.
Figura 4.16
Relatório da matriz
de tráfego.
Backup e restauração do sistema

11 Princípios do backup e restauração. q
11 Procedimento de backup.
11 Procedimento de restauração.
Backup são procedimentos de cópia de dados do serviço para um dispositivo de armazena-

mento para que assim possa ser restaurado em caso de perda dos dados originais ou caso
seja necessário reinstalar o serviço. O backup não torna o serviço tolerante a falhas, porém,
proverá a recuperação do serviço num curto espaço de tempo.
Conforme apresentando, o serviço VoIP de uma instituição usuária do Fone@RNP detém

os arquivos de configuração dos software pré-baseados. Durante a instalação, os arquivos
modelos são modificados para sobrescreverem os arquivos originais dos softwares.
Desta forma, caso os arquivos não sejam modificados, não há a necessidade de realizar o
backup destes arquivos. A instalação do serviço Fone@RNP não realiza nenhum procedi-
mento nas bases de dados da instituição, deixando-as vazias. Sendo assim, é importante
realizar o backup das bases de dados do PostgreSQL e do OpenLDAP.
Na máquina1, a não ser que haja alguma modificação específica feita pelos administradores
locais, não há necessidade de realizar backup utilizando o script fornecido pelo desenvol-
vedor. Neste caso, basta realizar nova homologação do serviço.
Para a máquina2, onde rodam bancos de dados do sistema, recomenda-se a utilização do

script faz_backup, descrito a seguir.
79
Procedimentos de backup
Para facilitar o trabalho dos administradores, a RNP, através de seu parceiro que presta
suporte ao serviço fone@RNP, disponibiliza o script de backup para as máquinas 1 e 2. Este
procedimento de backup cria um arquivo compactado dos principais arquivos de configu-
ração, e no caso do backup da máquina 2, o arquivo compactador também terá dumps da
base de dados PostgreSQL e do OpenLDAP.
Para realizar o backup seguindo o procedimento definido, baixe o script de backup em

http://www.albatecnologia.com/downloads/faz_backup. Deixe este arquivo disponibilizado
nas máquinas 1 e 2.
Para executar o backup da máquina 1, execute o comando: “./faz_backup -1”. O arquivo de

backup será gerado no diretório atual com o nome “voip_backup_1.tar.gz”. Para executar o
backup da máquina 2, execute o comando: “./faz_backup -2”. O arquivo de backup também
será gerado no diretório atual com o nome “voip_backup_2.tar.gz”.
Procedimentos de restauração
A RNP disponibiliza também o script de restauração dos backups das máquinas 1 e 2.
Este procedimento de restauração lê o arquivo compactado de backup com os principais
arquivos de configuração, e no caso do backup da máquina 2, com os dumps da base de
dados PostgreSQL e do OpenLDAP.
Para realizar a restauração seguindo o procedimento, baixe o script de BACKUP em

“http://www.albatecnologia.com/downloads/restura_backup”. Deixe este arquivo disponi-
bilizado nas máquinas 1 e 2.
Para executar a restauração da máquina 1, execute o comando: “./restaura_backup -1

<arquivo_backup.tar.gz>”. O arquivo de backup será restaurado no diretório “/usr/fonea-
trnp_bkp” para que possa ser utilizado. Para executar o backup da máquina 2, execute o
comando: “./restaura_backup -2 <arquivo_backup.tar.gz>”. O arquivo de backup também
será restaurado em “/usr/foneatrnp_bkp” e os dumps serão carregados automaticamente
nas bases de dados PostgreSQL e OpenLDAP.
A restauração deve ser executada em máquinas preparadas com o procedimento de

instalação e homologação.
Serviço fone@RNP
80
Seguindo o documento de homologação, deve-se agora realizar a seção 5 de testes locais no
serviço Fone@RNP. Desconsidere as chamadas que utilizam o protocolo H.323.
Na seção 5 do documento de homologação, os usuários realizarão as seguintes etapas:
a. Criação de usuários VoIP locais na FÉJECA;
b. Realização de chamadas entre os usuários;
c. Identificação da consolidação das chamadas no serviço de estatística.
Atividade 4.1 – Manipulação de ramais no FÉJECA

Como vimos, FÉJECA é a ferramenta de administração dos usuários no serviço Fone@RNP.
Um uso muito comum da FÉJECA é a criação de usuários, alteração de senhas ou identifi-
cação dos usuários logados no serviço.
Para iniciar, acesse através do browser de sua preferência a URL http://<IP_MAQ2>/ger2. Veri-
fique se o endereço IP da sua máquina está com acesso liberado no servidor web Apache2.
Criação de ramais
Ao acessar a FÉJECA, selecione a opção “cadastrar usuário” e preencha as informações
necessárias para a criação do usuário no serviço local. Com o usuário criado, teste-o utili-
zando um softphone.
Após realizar esta tarefa básica com sucesso, acesse a opção de “usuários online” para
identificar se o usuário foi registrado. Esta opção é importante também na manutenção do
serviço, pois ele permite apenas um único registro por usuário. Se o usuário já está regis-
trado, o mesmo receberá a mensagem de erro 487.
Edição de ramais
Com o serviço administrativo do FÉJECA, busque um usuário cadastrado no serviço local de
sua instituição e escolha a opção de editar. Nesta opção, o administrador terá acesso à alte-
ração de informações como nome, e-mail, senha e outros. Apenas dois campos não podem
ser modificados (login e telefone IP). Para alterar estes campos, o administrador deverá
remover o usuário e cadastrá-lo novamente.
Remoção de ramais
O administrador deverá realizar uma busca pelo ramal desejado, clicar em REMOVER ao lado
do ramal correspondente e confirmar a seleção.
Atividade 4.2 – Teste de chamadas local

Com a utilização de no mínimo dois usuários registrados no serviço, sejam eles softphones,
telefones IP ou ATAs, realize chamadas entre os dois usuários da seguinte forma:
a. Realização de chamada utilizando nome do usuário;
b. Realização da chamada utilizando alias (número) do usuário.
81
Atividade 4.3 – Estatística
Como vimos, a estatística do serviço local permite ao administrador gerenciar o uso do
serviço, sendo importante dimensionar o número de ligações diárias do serviço, o número
de ligações por hora do dia e a matriz de tráfego do serviço.
Para acessar a estatística do serviço, acesse a URL http://<IP_MAQ2>/estatistica. Como

tarefa inicial, utilize a opção para observar o uso do serviço nos últimos dias.
Caso não haja registros, observe se o serviço “consolida” na máquina 2 está em

execução.
Após identificar o número de chamadas por dia, identifique a utilização do serviço por hora
utilizando a opção “Horas do dia”. Nesta opção, selecione o dia de sua preferência. Nesta
tarefa identifique a quantidade de chamadas de testes feitas na atividade anterior, ou dê
preferência ao dia que tiver mais chamadas na sua instituição no último relatório.
Por fim, extraia a matriz de chamadas da sua instituição através da opção de mesmo nome.
Nesta opção, você deverá informar o intervalo da extração; escolha o período do curso.5
Atividade 4.4 – Backup do serviço

A iniciativa da ALBA/CAM tecnologia tornou o procedimento para a realização do backup da
sua instituição uma tarefa simples para todos os administradores do serviço Fone@RNP na
versão 2.
Backup
Para realizar o backup, iniciamos obtendo o arquivo de backup disponível em http://www.
albatecnologia.com/downloads/faz_backup. Assim, baixe este arquivo nas máquinas 1 e 2,
utilizando o comando:
wgethttp://www.albatecnologia.com/downloads/faz_backup
Ao finalizar o wget para baixar o arquivo, realize a operação de permissão para execução do
script com o comando:
chmod a+x faz_backup
Com estas medidas iniciais, podemos realizar o passo de geração do arquivo de backup dos
dados da instituição. Para realizar o backup na máquina 1, basta o administrador executar
o comando “./faz_backup -1”. Após este comando, o administrador identificará a criação do
arquivo voip_backup_1.tar.gz. O mesmo procedimento deverá ser realizado para a máquina 2
com o comando “./faz_backup -2” para a criação do arquivo voip_backup_2.tar.gz.
Neste momento, é importante que os arquivos gerados automaticamente nas máquinas 1 e

2 sejam transferidos para um local seguro.
Restauração
Serviço fone@RNP
Seguindo os passos indicados na parte teórica, efetue a restauração do backup na própria

máquina 2. Mas remova todos os usuários criados na FÉJECA antes de realizar restauração.
Observe que na FÉJECA, após a restauração, todos os usuários foram recriados. Observe
que na estatística o número de chamadas realizadas no serviço local foi replicado.
82
5
Serviço fone@RNP: ambiente
nacional
Apresentar o ambiente nacional, parte da arquitetura do serviço fone@RNP,
objetivos
o encaminhamento de chamadas entre as instituições e seus procedimentos

de configuração; apresentar o fone@RNP do ponto de vista do operador do
serviço, a RNP.
conceitos
Encaminhamento nacional de chamadas, proxy externo, operação dos nós centrais
do fone@RNP, FEGEN, DSER e replicação com SLON.
Estrutura do ambiente nacional

11 Estrutura de equipamentos. q
11 Estrutura de serviços do ambiente nacional.
11 Lógica de roteamento das chamadas.
O ambiente nacional do serviço fone@RNP tem a função de integrar as instituições usuárias

com outras instituições usuárias ou instituições externas. Como requisito da integração,
a arquitetura nacional autentica a instituição de origem e identifica as autorizações que a
instituição possui.
Na versão atual do fone@RNP, a forma de encaminhamento das chamadas é através do Capítulo 5 - Serviço fone@RNP: ambiente nacional
protocolo SIP. O protocolo H.323 ainda é aceito no serviço, porém, apenas habilitado para
serviços VoIP externos que desejam se comunicar com o fone@RNP através deste protocolo.
Outra função do ambiente nacional é fornecer a manutenção dos dados válidos em todo
o serviço fone@RNP. A manutenção dos dados é realizada através da gerência do banco
de dados PostgreSQL, que detêm as informações essenciais das instituições, seus equipa-
mentos, prefixos e números associados a IVR.
Estes dados permitem que o fone@RNP seja instalado ou atualizado a partir de configura-
ções padrão, evitando a manipulação destes arquivos e eliminando dificuldades com insti-
tuições co-localizadas e na geração de relatórios estatísticos do serviço.
Instituições co-localizadas são aquelas que se encontram no mesmo código de área

e na mesma cidade, e que terminam ligações para os mesmos prefixos da STFC.
83
Para prover tais serviços, o serviço dispõe dos equipamentos DSER e do Proxy Externo. No
intuito de oferecer maior disponibilidade do serviço, o equipamento DSER é replicado, sendo
assim usualmente invocados como DSER1 (Principal) e DSER2 (Secundário).
Proxy externo
Serviços VoIP externos
DSER1
DSER2
Figura 5.1
Descrição da
arquitetura de
equipamentos do
Instituições usuárias do Fone@RNP
ambiente nacional.
O Directory SIP Express Router (DSER) é formado pelos equipamentos principais do serviço
fone@RNP, formados a partir da seguinte estrutura: Proxy SIP OpenSER, ENUM através do
servidor DNS Bind, Banco de Dados PostgreSQL, servidor de sincronização SLONY e a ferra-
menta web de gerência do serviço FEGEN.
Como mediador das chamadas originadas ou destinadas a serviços externos ao fone@RNP,

o Proxy Externo é formado pelo proxy SIP OpenSER, pelo proxy de mídia RTP mediaProxy,
pelo gateway Asterisk para comunicação SIP/H.323, pelo proxy H.323 GnuGK e pelo cliente
de sincronização SLONY.
Serviço fone@RNP
84
Serviços VoIP externos
Proxy SIP externo Proxy H.323 externo

+ proxy de mídia + proxy de mídia
Banco de dados
do proxy externo
DNS
(postgres)
Gateway
externo
DNS DNS
DSER
ENUM via DNS Banco de dados

nacional (postgres)
Instituições usuárias do Fone@RNP
Figura 5.2 A regra de roteamento de chamadas no DSER é bem simples: inicialmente o DSER identifica
Estruturação se a chamada foi originada por um proxy confiável participante do Fone@RNP; se não for, a
dos serviços do
ambiente nacional. chamada será rejeitada. Identificando a chamada como confiável, o DSER consultará o ENUM
para identificar os destinos possíveis para a chamada.
Como o ENUM roda num servidor DNS, o serviço responderá ao registro que melhor corres-
ponder ao número destino. No próximo capítulo conheceremos a forma dos registros e da
consulta ao ENUM. O próprio servidor DNS realizará o balanceamento de carga das chamadas
quando mais de um registro for encontrado baseado no peso/prioridade dos registros.
Por outro lado, a regra de roteamento do Proxy SIP Externo é similar a de uma instituição Capítulo 5 - Serviço fone@RNP: ambiente nacional
usuária do serviço Fone@RNP. Contudo, chamadas originadas por outros serviços VoIP serão
apenas roteadas para o serviço Fone@RNP, e chamadas originadas no serviço Fone@RNP que
forem tratadas pelo SIP externo poderão apenas ser destinadas a serviços VoIP externos.
Similarmente, o Proxy H.323 Externo realiza a mesma análise, contudo as chamadas são
encaminhadas inicialmente ao ambiente do Proxy SIP Externo para assim serem tratadas no
serviço VoIP do Fone@RNP.
DSER
11 Princípios do DSER. q
11 Proxy SIP.
11 ENUM.
85
O DSER, acrônimo de Directory SIP Express Router, é o Proxy SIP nacional com a responsa-
bilidade de rotear as chamadas entre as instituições usuárias, incluindo o Proxy Externo.
O conceito DSER foi importado do ambiente H.323 que define como Directory GateKeeper
(DGK) o Proxy H.323 com a responsabilidade de interligar os GKs clientes.
A figura a seguir mostra o processo de localização de vizinhos utilizando o DSER, que con-
sulta um DNS privado. Neste exemplo, a instituição A realiza uma chamada que pode ser
encaminhada pelas instituições B ou C.
Servidor de localização
DSER
4
DNS
Instituição B
3 7
DNS
6 SV2 8
Instituição A 2 5
Tel IP B
(chamador) 9
1
Instituição C
SV1
11a
10 SV1
11b
Tel IP A
11d
SV3 11c
Tel IP C
Com funções de Proxy SIP de Redirecionamento (SIP Proxy Redirect), o DSER recebe as Figura 5.3
solicitações de chamada originadas numa instituição, e autentica se a instituição de origem Cenário de
operação com o
é uma instituição usuária ou o Proxy Externo. Ao confirmar a autenticidade da requisição, o DSER.
DSER consulta o ENUM através de uma consulta NAPTR ao servidor DNS.
Esta consulta responderá quais instituições usuárias completam para o destino pesquisado
no DSER. A resposta do ENUM será encaminhada na mensagem 302 de REDIRECT para a
instituição de origem, incluindo uma ou mais instituições como contato para esta chamada.
Caso não seja encontrada nenhuma instituição que possa completar esta chamada, a insti-
tuição de origem receberá uma mensagem 404 (NOT FOUND).
A solução para o mapeamento dos números associados a cada instituição usuária é feita através
do ENUM, conforme mencionado. O Eletronic Number Mapping (ENUM) relaciona números
E.164 com URIs válidas que apontam para servidores VoIP capazes de hospedar serviços.
Essa solução consiste em usar um DNS privado como base de conhecimento, realizando a
busca nesta base através dos registros NAPTR. Usando uma expressão regular de trans-
formação, ao receber um número de telefone no formato E.164 é devolvida uma URI para o
sistema. O OpenSER possui um módulo com essa funcionalidade.
Serviço fone@RNP
O ENUM destaca-se pela escalabilidade, facilidade de integração com o ambiente existente,

simplicidade e a capacidade de realizar o fork paralelo. A escalabilidade se dá pelo fato de
que o OpenSER e o DNS já são usados na estrutura atual sem problemas em relação à carga
do sistema. A fácil integração se dá pelo conhecimento já existente dos softwares adotados.
86
A simplicidade se deve ao fato de não estar sendo usada nenhuma tecnologia nova, mas
apenas trabalhando recursos de forma diferente.
Como foi dito, o ENUM funciona basicamente através de registros NAPTR. Cada campo tem
um significado e uma importância. A UFRJ possui telefones IP com prefixo 1100 xxxx. A dis-
cagem para um destes telefones IP é encaminhada ao DSER como um pedido para localizar
5521100 xxxx. Durante a realização de uma chamada, um número é transformado para a
sua forma E.164, utilizando o registro NAPTR mostrado abaixo.
11 $ORIGIN 1.2.5.5.enum.arpa.
11 *.0.0.1.1 NAPTR 1 1 “u” “E2U+sip” “!(^.*$)!sip:\\1@servidor.voip.nce.ufrj.br!” .
Esse número então será enviado ao DSER, que vai compará-lo com os prefixos existentes
no seu DNS privado. Caso encontre, o DSER verificará se alguma regra pode ser aplicada
ao número. Na segunda linha do registro existe a regra de transformação. Nessa linha
será verificado se ao número chamado pode ser aplicada alguma transformação. Nota-se
uma relação de especificidade entre a primeira linha e a segunda, onde a cada passo dado
restringe-se o domínio de busca.
Essas linhas definem uma regra que precisa ser atendida: o número E.164 de destino
possuir o prefixo 55211100. Atendida esta regra, a chamada é redirecionada para o servidor
“servidor.voip.nce.ufrj.br”, que a encaminha para um cliente IP do seu domínio. Dito isso e
considerando a configuração mostrada, fica simples entender o funcionamento do servidor
DNS utilizando ENUM.
O primeiro campo é o campo de domínio. É o nome de domínio ao qual o registro se refere e

o campo que em conjunto com o prefixo vai ser reescrito pela expressão regular. O segundo
campo contém a classe do registro de DNS dizendo que tipo de registro ele é (no nosso caso
é um registro NAPTR). O terceiro campo é o campo de ordem, definindo a regra que será
aplicada primeiro. O campo contém um valor inteiro de 16 bits e dá preferência a valores
menores. O quarto campo é a preferência, que serve para definir a ordem quando dois
registros possuem os campos de ordem iguais. Da mesma forma que o campo anterior, este
é um valor inteiro de 16 bits e dá preferência a valores menores.
A grande diferença entre os campos de ordem e preferência é que, depois de uma regra
satisfeita, não são considerados registros com ordens diferentes, mas podem ser consi-
derados registros com preferências diferentes. Partindo desse ponto de vista, podemos
ver que a preferência pode ser usada para diferenciar entre regras que possuem a mesma
importância de um ponto de vista da autoridade de domínio (como servidores de grandes
Capítulo 5 - Serviço fone@RNP: ambiente nacional
instituições), porém não do ponto de vista de balanceamento de carga.
O quinto campo é o Flag, responsável por controlar aspectos de reescrita e interpretação

dos campos do registro. Quando tratamos do ENUM, a flag “u” é a mais indicada, já que sig-
nifica que o próximo passo na resolução do DNS não será uma pesquisa (DNS lookup).
O sexto campo é o campo do serviço, ou seja, o campo que especifica o protocolo ou serviço
que está sendo utilizado. Na tag E2U+sip, E2U significa “E.164 to URI”, ou seja, transformará
um número E.164 em uma URI; +sip significa que o protocolo que realizará o serviço será o
SIP. O sétimo campo contém a expressão regular que é aplicada ao número E.164 chamado,
para que se construa o próximo domínio para fazer uma pesquisa (Look Up).
87
No DNS, quando existe mais de uma regra que pode ser aplicada, os campos de ordem e
preferência fazem a distinção/priorização entre os destinos escolhidos. Para cada regra
aplicada, o número do requisitante sofre ação da expressão regular para ser transformado
em uma URI.
Os prefixos são declarados como domínios diferentes na configuração do ENUM, quando

algum servidor encaminha chamadas com prefixos que estão incluídos no intervalo dos
números atendidos por outro Proxy SIP. Caso isso não ocorra, a busca deixará de retornar
na primitiva REDIRECT algum(ns) servidor(es). Por exemplo, supondo que uma instituição
A possa encaminhar chamadas com prefixo 55212256 e a instituição B respondendo pelo
prefixo 5521225616; nesse caso, após a consulta de ENUM, a sinalização REDIRECT de uma
tentativa de chamada para 552122561611 não conterá essas duas instituições.
Replicação do Slon
11 Princípios da replicação. q
11 Slony.
11 Estruturação do banco de dados Postgres.
Um dos principais conceitos estabelecidos no serviço na mudança de versão 1 para 2 foi a

criação de um sistema de replicação das bases de dados. Na versão inicial do fone@RNP,
o serviço tinha algumas dificuldades técnicas para identificar chamadas originadas por
outras instituições usuárias e instituições co-localizadas, e também na contabilização
correta das chamadas.
Na versão inicial, o fone@RNP utilizava a premissa de que as instituições não se comuni-

cavam diretamente. Todas as chamadas eram intermediadas pelo DGK; assim, todas as
instituições usuárias apenas identificavam o peer daquela chamada como DGK, e não a
instituição de origem ou destino.
Sobre as configurações de co-localizadas, na versão anterior os administradores eram

notificados de que uma nova instituição, de mesma co-localidade, aderiu ao serviço, e
que ele deveria configurar rotas de desvio das chamadas destinadas a esta co-localizada
pelo serviço VoIP e não pelo serviço de telefonia convencional. Quanto à contabilização da
chamada, não existia a identificação da instituição de origem e da instituição de destino,
pois as chamadas eram intermediadas pelo DGK.
Na versão 2 do serviço fone@RNP, todas as instituições usuárias necessitam ter uma cópia
atualizada das instituições ativas no serviço, seus equipamentos e prefixos. A identificação
das instituições ativas e os equipamentos pertencentes às instituições são importantes para
a autenticação na instituição destino de que a chamada foi originada por uma instituição
usuária do serviço.
Através dos prefixos, as instituições usuárias podem identificar se o número destino per-
tence a uma instituição co-localizada, encaminhando a chamada diretamente à instituição
sem intervenção do administrador. Através dos dados replicados, o sistema de contabili-
zação local na instituição usuária consegue identificar as instituições envolvidas na chamada
Serviço fone@RNP
e os tipos de equipamentos que originaram e receberam a chamada.
A ferramenta utilizada para realizar os sincronismos da base de dados da RNP com as bases
de dados das instituições usuárias é o Slony, um software livre para sistemas de replicação de
dados para o banco de dados PostgreSQL – banco de dados definido para o serviço fone@RNP.
88
Este sistema foi desenvolvido para cenários de backup onde os nós – banco de dados das
instituições replicadas – estão sempre disponíveis. Contudo, a ferramenta mantém a sin-
cronização das tabelas dos clientes com o banco de dados principal no serviço fone@RNP,
mesmo atuando em um cenário bem diferente.
Utilizando esta ferramenta, o sistema tem um ganho de desempenho comparado ao do

serviço anterior. Sempre que há alteração na base de dados principal, a informação é repli-
cada em pouco tempo para todas as instituições clientes, observando que todas as institui-
ções clientes estão bloqueadas para realizar alterações manualmente nas bases replicadas.
Exemplificando estes procedimentos, a figura a seguir explica o conceito da base principal e
clientes, enquanto apresenta a base de dados e as tabelas replicadas.
Bases de dados institucionais (slave) Bases de dados RNP (master)
openser chamadas chamadas
radius chamadas
instituições trusted
asterisk
instituições prefixos sip_friends
equipamentos equipamentos neighbors
Tabelas replicadas views

prefixos
trusted Tabelas replicadas prioridade_fork
views numero_vir
LEGENDA
Replicação
View
Pertencente à base
Tabelas estáticas
Tabelas replicadas
Views
Figura 5.4 Proxy Externo

q
Sincronização da
11 Princípios do Proxy Externo.
Capítulo 5 - Serviço fone@RNP: ambiente nacional
base de dados.
11 Estrutura local (Proxy SIP, Gateway SIP/H.323 e Proxy H.323).
Para permitir a integração das instituições usuárias com outros serviços VoIP externos ao
serviço fone@RNP, o Proxy Externo oferece ao serviço esta comunicação sem que os
administradores das instituições realizem configurações de roteamento das chamadas e
liberação nos firewalls.
Para todas as outras instituições usuárias, o Proxy Externo comporta-se como mais uma
instituição usuária ao serviço, diferenciando apenas que não há nenhum prefixo associado
a esta instituição. Quando uma instituição realiza uma chamada destinada a um serviço
externo, ela redireciona esta chamada ao DSER, que por fim, através de regras de rotea-
mento pré-definidas no ENUM, encaminhará as chamadas ao Proxy Externo.
89
Para a troca de tráfego do Proxy Externo e os serviços externos, ele deverá definir a sinali- d
zação a ser utilizada para a troca de tráfego (SIP ou H.323) e encaminhar as informações de Para facilitar a
peering do serviço externo ao administrador do fone@RNP. Estas informações serão alimen- integração das
instituições externas a
tadas na FEGEN para que sejam compartilhadas por todo o serviço, inclusive o Proxy Externo. trocarem tráfego com o
serviço Fone@RNP, foi
A RNP definirá o SLA no momento de inclusão do VoIP Externo na FEGEN. O SLA permite a disponibilizado um
autorização da chamada no Proxy Externo. Como forma de controle do serviço, atualmente arquivo XML contendo
informações essenciais
o Proxy Externo não permite a passagem de tráfego entre instituições externas.
do serviço, disponível
em: http://gateway.
Outro ponto importante da centralização da comunicação no Proxy Externo é a coleta de dados
fone.rnp.br/request_
para contabilização das chamadas trocadas entre o serviço fone@RNP e os serviços externos. prefixs.cgi
O plano de numeração aceito pelo Proxy Externo é o endereçamento E.164 definido a seguir:
11 00<país><área><número>
11 <país><área><número>
Estrutura local
Conforme mencionado, o Proxy Externo possui características similares às de uma instituição
usuária, sendo configurado com um Proxy SIP OpenSER que, trabalhando em conjunto com o
proxy de mídia MediaProxy, trata todas as mensagens do ambiente SIP. Diferente dos outros
proxys SIPs, o Proxy Externo não possibilita a autenticação de um usuário ao serviço externo;
apenas serviços pré-configurados no ambiente internacional têm acesso ao serviço VoIP.
O proxy H.323 GnuGK e o gateway Asterisk SIP/H.323 permitem a integração das instituições
externas que ainda utilizam a sinalização H.323. Este ambiente apenas interage com as insti-
tuições externas e encaminha para o ambiente SIP para comunicação no serviço Fone@RNP.
Figura 5.5
Como não há a autenticação dos usuários no serviço, não há o serviço LDAP no Proxy Instituição usuária
Externo. Para complementar estes serviços existe o sistema de banco de dados PostgreSQL, em comunicação
de replicação SLONY e de contabilização das chamadas consolidadas. com o Proxy
Externo.
Tabela DNS
vizinhos privado
prefixos ENUM
Cliente A Ambiente nacional
Proxy SIP
“OpenSER” Proxy SIP
externo
Gateway
VoIP/PBX
DNS PABX
SRV Instituição usuária
Gateway
H.323/SIP
Serviço fone@RNP
Instituições externas
via SIP
Proxy H.323 Instituições externas

externo via H.323
Proxy externo
90
FEGEN
11 Princípios da ferramenta. q
11 Funcionalidades da FEGEN.
Como explicado, o serviço Fone@RNP é totalmente dependente dos registros existentes na

base de dados. O serviço detém informações básicas de cadastro, informações referentes à
identificação das instituições usuárias e informações de roteamento das chamadas. Cenário
diferente da versão anterior, onde as informações de identificação e roteamento eram
cadastradas no próprio arquivo de configuração do DGK.
A FEGEN gerencia todas estas informações da base de dados principal da RNP, localizada
no DSER1, incluindo funcionalidades como ativar e desativar uma instituição e gerenciar as
instituições internacionais do serviço.
FeGeN
Administração do fone@RNP
(RNP)
Laptop
Nó master
Tabela 2
Tabela 1
Tabela N
Figura 5.6 BD
Gerenciamento do
serviço através da DSER
DNS
FEGEN.
A FEGEN lista todas as instituições do serviço e algumas informações básicas delas. É uma
ferramenta web acessada a partir de qualquer browser cadastrado no firewall para que
tenha seu acesso liberado.
Na página inicial, é possível acessar qualquer instituição cadastrada no serviço, criar uma
nova instituição, acessar o serviço de gerar os registros no DNS para o serviço ENUM ou
acessar o serviço de gerar as permissões das instituições ao banco de dados principal. Capítulo 5 - Serviço fone@RNP: ambiente nacional
91
Conforme descrito na figura anterior, na FEGEN existem as informações básicas de registro Figura 5.7
das instituições, os endereços IP dos equipamentos associados e os prefixos atendidos Informações
básicas de uma
pela instituição. instituição.
Serviço fone@RNP
92
Seguindo o documento de homologação do serviço, deve-se agora realizar a seção 6 de
testes com outras instituições. Desconsidere as chamadas que utilizam o protocolo H.323.
11 Efetuar chamadas para usuários VoIP de outras instituições;
11 Receber chamadas de usuários VoIP de outras instituições;
11 Identificação da consolidação das chamadas no serviço de estatística.
Atividade 5.1 – Efetuando chamadas para outras instituições

Inicie uma chamada destinada a um telefone VoIP de outra instituição homologada ao
serviço fone@RNP. Para realizar a chamada, deve-se levar em consideração o código de área
e o número do telefone VoIP que deseja ser chamado. Exemplo: 02117018000.
Atividade 5.2 – Análise de log de chamadas

Todas as mensagens SIP são registradas no serviço VoIP localmente. Estes registros permitem
ao administrador identificar o fluxo das mensagens SIP que estão sendo tratadas pelo proxy. A
identificação do fluxo apresenta ao administrador informações relevantes, como:
11 Identificação da instituição (peer) que recebeu a chamada;
11 Avaliação das falhas no estabelecimento da sessão VoIP.
O log do Proxy SIP está no arquivo “/var/log/openser.log”, podendo ser analisado em tempo
real através do comando:
tail – f /var/log/openser.log
11 Avalie o resultado do estabelecimento das chamadas no serviço VoIP, utilizando o log;
11 Verifique no serviço de estatística local as chamadas realizadas no serviço fone@RNP.
93
94
Serviço fone@RNP
6
Proxy SIP – OpenSER
objetivos
Apresentar o OpenSER e o Asterisk, os dois componentes principais do serviço

fone@RNP.
conceitos
OpenSER e Asterisk.
O que é OpenSER?
11 Open SIP Express Router. q
22 Open Source – GPL.
22 Acordado com padrão do protocolo SIP IETF RFC 3261.
11 Proxy SIP para manipulação e roteamento das mensagens SIP.
11 Capaz de tratar milhares de requisições simultâneas.
Open SIP Express Router (OpenSER) é um Proxy SIP de código aberto, altamente configurável
para atender às mais diferentes necessidades. O OpenSER foi desenvolvido e é mantido
pela companhia Voice System, sendo inicializado após a aquisição do software inicial SER, da
FhGFokus, pela Iptel.org. Ambos os softwares foram disponibilizados sob licença GPL e são
implementados em C para arquiteturas Unix, como Linux, Solaris e BSD.
Para ser compatível com todas as implementações de terceiros que usam o protocolo SIP,
o OpenSER é desenvolvido de acordo com o padrão do protocolo SIP definido pelo padrão
Request For Comments (RFC) 3261, da Internet Engineering Task Force (IETF). Outros
padrões da RFC que implementam funcionalidades adicionais ao padrão SIP também são
suportados pelo OpenSER. Alguns exemplos de padrões adicionais são as RFCs 3265, 3856,
3857 e 3858 para o módulo de presença.
Capítulo 6 - Proxy SIP – OpenSER
Sendo um servidor de Proxy SIP, o OpenSER é extremamente rápido para o encaminha-

mento das mensagens SIP, provendo assim a característica de manipular milhares de
requisições simultâneas usando baixa carga de processamento. E consolidando o OpenSER
para trabalhar em equipamentos que necessitam realizar o tratamento de alto número de
chamadas, como provedores VoIP.
Atualmente, o OpenSER não é mais suportado pela Voice System. Em 2008, o OpenSER
foi dividido em duas novas variantes, os projetos Kamailio e OpenSIPS. Este curso não vai
entrar na discussão sobre qual variante é melhor. Mas é de conhecimento de todos que o
95
SER possui ciclos muito longos de disponibilização de novas versões; o OpenSER não é mais
suportado e desde 2008 novas versões não são disponibilizadas.
Comparado ao Kamailio, o OpenSIPS possui gerenciamento mais consistente de disponibili-

zação de novas versões, não liberando versões de software com possíveis problemas. Mais
aplicado a novas funcionalidades, o Kamailio está amplamente focado no desenvolvimento
e na liberação dessas funcionalidades, gerando instabilidades ao software em algumas
versões liberadas.
Características do OpenSER
Robusto: q
11 Servidor de registro, localização, proxy e redirecionamento.
11 Pouca carga no servidor; consome poucos recursos computacionais.
Flexível:
11 Suporta TCP, UDP, TLS e SCTP.
11 Suporta IPv4 e IPv6.
11 Suporta MySQL, RADIUS, PostgreSQL e outros.
Extensível:
11 Módulos carregados definidos no script de configuração.
11 Módulos desenvolvidos por terceiros.
11 Scripts externos invocados para informações adicionais.
O OpenSER pode ser utilizado para implementar diversas funções, como servidores de
registro, Proxy SIP (SIP Router), servidor de redirecionamento, servidor de presença, ser-
vidor de mensagens instantâneas, balanceamento de carga e front-end para diversas outras
funcionalidades aplicáveis ao protocolo SIP.
Essas possibilidades e o fato de o software consumir pouco processamento do servidor e

ocupar pouco espaço no disco rígido confere ao OpenSER uma de suas principais caracterís-
ticas: sua robustez.
Flexibilidade é outra característica importante do software. O OpenSER possui suporte aos

protocolos de transporte TCP, UDP, TLS e SCTP, e suporta redes IPv4 e IPv6. O OpenSER é
capaz de interagir com equipamentos nos mais diversos ambientes. Também é possível
realizar comunicação com ambientes de gerenciamento de dados, como MySQL, RADIUS,
PostgreSQL e outros.
Outra característica importante do OpenSER é ser extensível, sendo possível:
11 Adicionar ou remover módulos instalados.
11 Carregar apenas módulos que serão utilizados.
11 Desenvolver novos módulos.
11 Executar scripts externos para obtenção de informação.

Serviço fone@RNP
Estrutura básica do OpenSER

Configuração: q
11 /etc/openser/openser.cfg
96
Comandos: q
11 /usr/sbin/openser
11 /etc/init.d/openser start
Arquivo de configuração
O arquivo de configuração do OpenSER está localizado por padrão em /etc/openser/openser.cfg
e é dividido em contextos.
O OpenSER pode ser inicializado através da execução do binário /usr/sbin/openser ou através do

script de inicialização /etc/init.d/openser start. Esse último modo é a forma mais recomendada.
Arquitetura modular
O OpenSER é construído pelo núcleo (core) responsável pelas funcionalidades básicas do
software e pelos módulos responsáveis pela maior parte das funcionalidades do software.
Toda a configuração é feita no arquivo openser.cfg. Assim é possível controlar o tratamento
das mensagens SIP e as chamadas das funcionalidades dos módulos carregados.
Para facilitar o entendimento, o núcleo é responsável por:
11 Gerência de memória e sistema de trava.
11 Parser de mensagens SIP.
11 Gerência de camada de transporte e DNS.
11 Parser e interpretador de arquivos de configuração.
11 Camada de abstração de banco de dados (DB API).
11 API de interface de gerência.
11 Stateless forwarding.
11 Pseudovariáveis e mecanismos de transformação.
11 API de mecanismos de estatística e temporização.
E os módulos são responsáveis por:
11 Gerência de localização de usuário.
11 Contabilidade, autorização e autenticação.
11 Processamento de texto e de expressões regulares.
11 Respostas stateless e processamento stateful.
11 Extensões para Instant Messaging (IM) e localização.
11 Suporte a RADIUS e a conexões de banco de dados.
11 Interpretador de Call Processing Language (CPL).

11 Gateway SMS e XMPP (Jabber).
11 NAT traversal.
11 Extensões para servlets Perl e Java.
Arquivo de configuração openser.cfg

11 Parâmetros de configuração global. q
11 Identificação dos módulos que serão carregados.
11 Configuração de parâmetros dos módulos.
97
11 Contexto de roteamento principal. q
11 Contexto de roteamento secundário.
11 Contexto de roteamento das respostas.
11 Contexto de roteamento de falhas.
O arquivo openser.cfg possui sintaxe semelhante a qualquer arquivo de configuração no Linux.

O caractere “#” indica que tudo o que aparece após ele é comentário. A declaração de parâme-
tros é feita da forma PARÂMETRO=VALOR. O openser.cfg é divido nas seguintes seções:
Parâmetros de configuração global
####### Global Parameters #########
debug=3
log_stderror=no
fork=yes
children=4
disable_tcp=yes
listen=udp:127.0.0.1:5060
listen=tcp:127.0.0.1:5061
###################################
Contém todos os parâmetros básicos para a execução do software, como o endereço IP e

porta que estará usando, nível de debug e outros.
Identificação dos módulos que serão carregados
####### Modules Section ########
#set module path
mpath=”/usr/local/lib/openser/modules/”
loadmodule “sl.so”
loadmodule “tm.so”
loadmodule “rr.so”
loadmodule “maxfwd.so”
loadmodule “usrloc.so”
loadmodule “registrar.so”
loadmodule “textops.so”
loadmodule “mi_fifo.so”
Serviço fone@RNP
loadmodule “uri_db.so”
###################################
98
Contém a lista dos módulos que serão carregados durante a execução do OpenSER. Todos
os módulos são invocados através do comando loadmodule.
O parâmetro mpath indica o caminho onde se encontram os módulos. Os demais indicam ao

OpenSER para carregar os módulos indicados.
Configuração de parâmetros dos módulos
# ----------------- setting module-specificparameters ---------------
# -- mi_fifoparams --
modparam(“mi_fifo”, “fifo_name”, “/tmp/openser_fifo”)
# -- usrlocparams --
modparam(“usrloc”, “db_mode”, 0)
Contém a configuração dos módulos para a sua execução correta. Todos os parâmetros são
definidos usando o seguinte comando:
modparam(“NomeModulo”, “NomeParametro”, “valor”)
Contexto de roteamento principal
####### RoutingLogic ########
# main request routing logic
route{
if (!mf_process_maxfwd_header(“10”)) {
sl_send_reply(“483”,”Too Many Hops”);
exit;
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
route(1);
} else {
sl_send_reply(“404”,”Not here”);
exit;
Contém o roteamento a ser invocado para cada requisição SIP processada, controlando a
execução de cada requisição.
99
Contexto de roteamento secundário
#initialrequests
# CANCEL processing
if (is_method(“CANCEL”) {
if (t_check_tran())
t_relay();
exit;
t_check_tran();
# record routing
if (!is_method(“REGISTER|MESSAGE”))
record_route();
if (!uri==myself) {
append_hf(“P-hint: outbound\r\n”);
route(1);
# requests for my domain
if (method==”REGISTER”) {
save(“location”);
exit;
if (!lookup(“location”)) {
switch ($retcode) {
case -1:
case -3:
t_newtran();
t_reply(“404”, “Not Found”);
exit;
case -2:
Serviço fone@RNP
sl_send_reply(“405”, “Not Found”);
exit;
100
route(1);
Contém o roteamento que é invocado pelas rotinas principais ou secundárias, facilitando a

estruturação da configuração de roteamento.
Contexto de roteamento de respostas
route[1] {
t_on_reply(“2”);
t_on_failure(“1”);
if (!t_relay()) {
sl_reply_error();
};
exit;
onreply_route[2] {
xlog(“incoming reply\n”);
Contém o roteamento a todas as mensagens de resposta recebidas pelo proxy.
Contexto de roteamento de falhas
failure_route[1] {
if (t_was_cancelled()) {
exit;
if (t_check_status(“3[0-9][0-9]”)) {
t_reply(“404”,”Not found”);
exit;
}
Contém o roteamento das mensagens de resposta a falhas, como mensagens de timeout.
Lógica de roteamento das mensagens

11 Lógica sequencial. q
11 Identificação de atributos da mensagem.
22 Tipo de requisição.
22 Request URI da mensagem.
101
22 Informações do cabeçalho da mensagem (usuário de origem e domínio). q
22 Identificação do transporte (endereço IP de origem, porta de origem e outros).
11 Utilização dessas informações para rotear as requisições.
Para cada requisição recebida pelo OpenSER, é realizado o tratamento inicial da mensagem para
obter todas as informações importantes dessa requisição e encaminhar a mensagem à rota
principal. Na rota principal serão seguidas sequencialmente as regras definidas nesse contexto.
Para facilitar o desenvolvimento de lógicas nos contextos de rotas, o OpenSER disponibiliza

todas as informações existentes na requisição, como por exemplo:
11 Tipo de requisição: identificação do método que está sendo utilizado: INVITE, CANCEL,
REGISTER e outros.
11 Request URI: identificação do endereço de requisição solicitada pela origem.
11 Informações de cabeçalho: informações essenciais, como nome de usuário, domínio e

capacidades do usuário.
11 Identificação do transporte: informações sobre o tipo de protocolo utilizado, endereço IP,

porta e outros.
Através dessas informações, os contextos de roteamento aplicam as melhores regras para

manipular as mensagens. Como exemplo disso, observe a próxima figura:
Começo
Não Não
Usuário on-line? Solicitação INVITE? Linguagem de roteamento SER
/* user online ? */
Sim Sim if (lookup(“location”)) {
t_relay();
Reporta
break;
chamada perdida
};
If (method==”INVITE”) {
SIP: encaminha SIP: 404 /* report to syslog */
solicitação not found log(“ACC: missed call\n”);
};
Sl_send_reply(“404”, “Not Found”);
Feito
Figura 6.1
Funções básicas do OpenSER Lógica de
11 Identificação do domínio. q programação do

OpenSER.
11 Encaminhamento da mensagem statefull.
11 Encaminhamento da mensagem stateless.

Serviço fone@RNP
11 Tratamento das mensagens.
11 Verificação de método da requisição.
11 Análise da URI da mensagem.
11 Reescrever URI da mensagem.
11 Chamada de contextos secundários.
102
Identificação de domínio
A identificação de um domínio é feita de forma bem simples. Nos parâmetros globais do
arquivo de configuração existe o parâmetro chamado alias, que define o domínio desse
servidor SIP. E durante a lógica de roteamento, as mensagens SIP podem ser verificadas pela
seguinte programação:
alias=“demo.rnp.br”
route {
if (uri!=myself) {
#Não sou eu
};
Encaminhamento de mensagens statefull

O encaminhamento de mensagens statefull é realizado pelo comando t_relay. Esse comando
aguarda que mensagens de identificação de rotas de resposta e de falhas sejam definidas
para o correto funcionamento da função.
route {
if (uri!=myself) {
t_on_reply(1);
if (!t_relay()) {
sl_reply_error();
};
return(0);
};
Encaminhamento de mensagens stateless

O encaminhamento de mensagens stateless é realizado pelo comando forward. Esse
comando não necessita de parâmetros de mensagem de resposta ou falha, pois essas men-
sagens não serão encaminhadas ao servidor.
route {
if (uri!=myself) {
forward(10.0.1.2, 5060);
return(0);
};
103
Tratamento das mensagens de resposta
O encaminhamento de mensagens statefull é realizado pelo comando t_relay. Esse comando
aguarda que mensagens de identificação de rotas de resposta e de falhas sejam definidas
para o correto funcionamento da função.
route {
if (uri!=myself) {
t_on_reply(1);
if (!t_relay()) {
sl_reply_error();
};
return(0); };
onreply_route[1] {
if (status==”200”) {
log(1, “Chegou um 200 OK\n”);
} else if (status==”180”) {
log(1, “Chegou um 180 RINGING\n”);
}else {
log(1, “Chegou outro tipo de resposta\n”); };
Verificação de método da requisição

A verificação do método de requisição recebida pelo proxy é feita de forma muito simples
através da variável pré-definida method ou pela função is_method (NomeMetodo):
route {
log(1, “Chegou um REGISTER\n”);
} else if (method==”INVITE”) {
} else if (method==”CANCEL”) {
log(1, “Chegou um CANCEL\n”);

Serviço fone@RNP
}else {
log(1, “Chegou outro tipo de mensagem\n”);
};
104
Análise da URI da mensagem
A avaliação da URI requisitada pelo UAS de origem da mensagem é feita de forma prática
através da variável pré-definida chamada de uri:
if (uri=~”^sip:1100.*”) {
log(1, “Usuarios desconhecidos.\n”);
sl_send_reply(“404”, “Not Found”);
return(0);
} else if (uri=~”^sip:2598.*” || uri=~”^sip:2562.*” ||

uri=~”^sip:3873.*” || uri=~”^sip:0.*”) {
log(1, “Numero de destino e local\n”);
log(1, “Enviando ao gateway\n”);
t_relay(“146.164.247.235”, “5060”);
Reescrever a URI da mensagem

Antes de realizar o encaminhamento da mensagem para o próximo UA, normalmente se faz
necessário reescrever a URI da mensagem. Para isso existem as funções rewriteuser e rewritehost.
if (uri=~”^sip:00552111000092@voip.rnp.br”) {
if (method==”INVITE”) {
rewriteuser(“teste2”);
rewritehost(“demo.rnp.br”);
log(“Forwarding to User teste 2”);
forward(146.164.247.235, 5060);
return(0);
};
};
Chamada de contextos secundários

Para facilitar a organização e a reutilização de trechos de roteamento, o OpenSER permite
a criação de contextos secundários. Esses contextos secundários são normalmente usados
para funções específicas que podem ser utilizadas mais de uma vez em todo o código.
route {
route(2);
log(1, “voltou da rota 2\n”);
105
};
route[2] { # rota de autenticação e registro
if (!www_authorize(“demo.rnp.br”)) {
log(1, “REGISTER não autorizado, gerando digest\n”);
www_challenge(“demo.rnp.br”, “0”);
return(0);
};
if (!check_to()) {
log(1, “REGISTER con nome de usuarioinvalido\n”);
sl_send_reply(“401”, “Unauthorized”);
return(0);
};
log(1, “REGISTER con nome de usuario valido\n”);
consume_credentials();
if (!save(“location”)) {
sl_reply_error();
return(0);
};
OpenSER no fone@RNP
Serviço principal em execução na instituição, que realiza o tratamento de todas as q
mensagens SIP que forem encaminhadas pelo serviço.
11 Autenticação dos usuários da instituição.
11 Autorização das chamadas a serem encaminhadas.
11 Contabilização de cada mensagem relativa a uma chamada.
11 Integração com o gateway da instituição.
11 Integração com o serviço fone@RNP.
O OpenSER no serviço VoIP das instituições usuárias do fone@RNP é responsável pelo

tratamento de todas as mensagens SIP que forem encaminhadas ao serviço, tornando-se o
principal serviço em execução na instituição usuária.
Serviço fone@RNP
Ao tratar as mensagens SIP do serviço local, o OpenSER realiza as seguintes funcionalidades

no serviço:
11 Autenticação dos usuários da instituição através do método www-authenticated.
11 Autorização das chamadas a serem encaminhadas, impedindo que chamadas alcancem

destinos bloqueados.
106
11 Contabilização de cada mensagem relativa a uma chamada nos registros de CDR.
11 Integração com o gateway da instituição, possibilitando a comunicação do gateway ao

serviço e do serviço ao gateway. O gateway apenas recebe mensagens originadas pelo
Proxy SIP OpenSER.
11 Integração com o serviço fone@RNP, possibilitando comunicação com o DSER e com

todos os Proxies SIP das outras instituições.
Asterisk
É um Private Automatic Branch eXchange (PABX) implementado em software que q
permite conectividade em tempo real entre redes PSTN e redes VoIP. Foi o primeiro PABX
de código aberto do mercado.
O Asterisk é um software que implementa funções de PABX. Foi desenvolvido de acordo

com a filosofia do código livre e é disponibilizado sob os termos da General Public License
(GPL). Foi criado pela Digium Inc. e tem uma base de usuários em contínuo crescimento. A
Digium investe no desenvolvimento do código-fonte do Asterisk, em serviço de consultoria,
suporte especializado e, principalmente, em hardware de telefonia de baixo custo, também
aberto, que funciona com o Asterisk.
O Asterisk roda em distribuições Linux e outras plataformas Unix. Não é necessário adquirir
as placas da Digium ou de outro fabricante para que o Asterisk funcione. Mas se essas
placas forem utilizadas, é possível criar um gateway interligando a Rede Pública de Telefonia
Comutada – na sigla em inglês, Public Switched Telephony Network (PSTN) – a uma rede
de telefonia IP. Também será possível construir novas aplicações de voz para o sistema de
telefonia tradicional.
11 Escrito totalmente na linguagem C.
11 Desenvolvido para plataforma Linux.
11 Kernel 2.4 ou superior.
11 Portado para Solaris, FreeBSD e OpenBSD.
11 Possibilidade de alteração de código de acordo com o cliente.
Asterisk e Linux
11 Por que utilizar o Linux? q
11 Ambos são soluções Open Source.
11 Hardware para acesso a PSTN; toda a implementação do Asterisk é voltada para a

plataforma Linux.
Licenciamento duplo:
11 GPL.
11 LGPL.
O Asterisk foi escrito originalmente utilizando a linguagem de programação C, amplamente

conhecida na comunidade de desenvolvedores. Isso garante que praticamente qualquer
pessoa no mundo com alguma experiência em programação possa contribuir aprimorando
seu código-fonte.
Foi desenvolvido sobre o sistema operacional Linux e, por isso mesmo, esse é o sistema
operacional de suporte nativo do Asterisk. Também funciona em OpenBSD, FreeBSD e MAC
107
OS X. Portar o Asterisk para outros sistemas baseados no Unix deve ser uma tarefa relativa-
mente fácil para pessoas com tempo e habilidade com esses sistemas.
General Public License (GNU) – Licença Pública Geral, na sigla em inglês –, GNU GPL ou sim-
plesmente GPL é a designação da licença para software livre idealizada por Richard Stallman
no final da década de 90, no âmbito do projeto GNU da Free Software Foundation.
A GPL é a licença com maior utilização por parte de projetos de software livre, em grande parte
devido à sua adoção para o Linux. Em termos gerais, a GPL se baseia em quatro liberdades:
11 De executar o programa para qualquer propósito (liberdade nº 0).
11 De estudar o funcionamento do programa e adaptá-lo para suas necessidades

(liberdade nº 1). O acesso ao código-fonte é um pré-requisito para essa liberdade.
11 De redistribuir cópias de modo a ajudar o próximo (liberdade nº 2).
11 De aperfeiçoar o programa e liberar os aperfeiçoamentos de modo que toda a comuni-

dade seja beneficiada por eles (liberdade nº 3). O acesso ao código-fonte é um pré-requi-
sito para essa liberdade.
A licença GPL foi originalmente publicada em janeiro de 1989. No entanto, pouco tempo
depois, ficou claro que o texto da licença continha vários problemas. Assim, em junho de
1991 foi publicada a GPL versão 2, sendo ao mesmo tempo introduzida uma nova licença
LGPL. Em 2005, Stallman anunciou que estava preparando uma nova versão da licença em
conjunto com Eben Moglen. Essa nova versão foi chamada de GPLv3 e o primeiro esboço
dela foi publicado em 16 de janeiro de 2006.
A GNU Lesser General Public License (antes conhecida como GNU Library General Public
License) é uma licença de software livre aprovada pela FSF e escrita com o intuito de ser um
meio-termo entre a GPL e as licenças mais permissivas, como BSD e MIT. Foi escrita em 1991
(e atualizada em 1999) por Richard Stallman e Eben Moglen.
A principal diferença entre a GPL e a LGPL é que a última permite ser ligada a programas
que não sejam GPL ou LGPL (software livre ou proprietário). Outra diferença é que trabalhos
derivados (que não sejam GPL) devem ser bibliotecas de software. A LGPL coloca restrições
de copyleft no próprio programa, mas não aplica essas restrições a outro software que
apenas se liga ao programa. Há, contudo, outras restrições nesse software. Essencialmente,
deve ser possível ao software ser ligado a uma versão mais nova do programa sob LGPL. O
método mais usado para fazer isso é por meio de um mecanismo de biblioteca comparti-
lhada para ligação. Alternativamente, a ligação estática é permitida se o código-fonte ou os
arquivos do objeto a ser ligado forem disponibilizados.
A LGPL é primariamente utilizada em bibliotecas de software, embora também seja usada

por aplicações como OpenOffice.org e Mozilla. Uma característica da LGPL é que se pode
converter qualquer pedaço de software em LGPL em outro sob GPL (seção 3 da licença). Essa
característica é útil para a criação de uma versão de código que empresas de software não
podem usar em produtos de softwares proprietários. Também é necessário assegurar que
a LGPL seja compatível com a GPL, de modo que programas cobertos pela GPL possam usar
bibliotecas sob LGPL.
Serviço fone@RNP
108
Asterisk versus PABX
As soluções de telefonia encontradas no mercado normalmente têm custo elevado. Tradicio- q
nalmente há dificuldade para a adoção de novas funcionalidades, pelas seguintes razões:
11 Novas funcionalidades significam novos custos.
11 Dificuldades de instalação.
11 Em geral implica a compra de novo hardware.
Vantagens do Asterisk em relação ao PABX:
11 Custo mais atrativo.
11 Possui leque superior de funcionalidades.
22 Novos serviços são adicionados ao código-fonte.
11 Novas funcionalidades não implicam a compra de novos equipamentos.
11 Controle de seu sistema de telefonia.
11 Ambiente de desenvolvimento fácil e rápido.
11 Plano de discagem flexível e poderoso.
11 Código aberto.
Funções básicas:
11 Voice mail (mensagem de voz por e-mail).
11 Música em espera (mp3).
11 Salas de conferência.
11 Parking (estacionamento de chamadas).
11 Caller ID.
11 Siga-me.
11 Transferência de chamadas.
A definição do Asterisk na página oficial do programa diz que ele é um software livre e de
código aberto, que transforma um computador comum em um rico servidor de comunica-
ções de voz. O Asterisk é uma plataforma de desenvolvimento de aplicações de voz. Assim,
é possível criar quase qualquer tipo de serviço envolvendo aplicações de voz sem os altos
custos das licenças cobradas pelos fabricantes tradicionais de PABX e desenvolvedores de
soluções de telefonia.
O modelo de negócios adotado há muitos anos pela indústria da telefonia torna sua imple-
mentação proibitiva em muitos casos, principalmente para pequenas empresas. Para cada
novo serviço, era preciso realizar upgrade no sistema com a aquisição de novo hardware,
com a necessidade de comprar mais uma licença. Mesmo quando o PABX já estava prepa-
rado para o crescimento, não sendo necessário adquirir novo hardware, para cada novo
canal de voz era preciso comprar uma nova licença. O Asterisk e a filosofia de código aberto
vêm democratizar a utilização de aplicações de voz, pois cada novo serviço no Asterisk é
implementado por software normalmente aberto e livre de licenças.
109
Para pensar
Ter controle do seu próprio sistema de telefonia é um dos benefícios que o Asterisk
oferece. Em vez de esperar e pagar para alguém configurar seu PABX proprietário (a
maioria não fornece nem a senha para o cliente final), o Asterisk dá toda a liberdade
de configurá-lo e programá-lo. Em relação à adição de novas funcionalidades, com o
Asterisk basta adicionar os programas adequados. Já com soluções convencionais é
muito provável que seja necessário adquirir novas licenças e novo hardware.
É possível desenvolver todas as funcionalidades presentes em sistemas tradicionais no

Asterisk, em que mesmo aplicações especializadas são programáveis, como as utilizadas em
call centers. No entanto, cada nova funcionalidade em sistemas convencionais exige a aqui-
sição de nova licença e, quase sempre, de novo hardware. Além disso, o Asterisk suporta
protocolos de Voz sobre IP, isto é, possibilita a fácil integração das redes de voz e dados. Na
verdade, o Asterisk é entendido como um sistema de voz sobre IP que pode ser interligado
ao sistema de telefonia convencional com a instalação de placas especiais. Assim, já traz
embutidas as vantagens das soluções de telefonia IP, assim como a possibilidade de apro-
veitar a infraestrutura de dados para o tráfego de voz e mobilidade dos ramais, entre outras
vantagens. O Asterisk não é apenas um PABX, porque faz muito mais que unir um conjunto
de ramais e ligá-los à rede de telefonia pública.
Funções do Asterisk
Algumas funções e serviços complementares suportados pelo Asterisk:
11 Identificador de chamada.
11 Siga-me.
11 Transferência assistida ou cega.
11 Pêndulo.
11 Desvios baseados no chamador.
11 Secretária eletrônica (com envio da mensagem por e-mail).
11 Música em espera (configurável por contextos).
11 Conferência.
11 Estacionamento de chamadas.
11 Funções avançadas:
22 Resposta Interativa por Voz (IVR).
22 Billing (tarifação) utilizando o registro detalhado das chamadas (CDR).
22 Queue (filas de chamadas).
22 Fax over IP.
22 Gravação de conversas ou conferências.

Serviço fone@RNP
22 Entrega automática de chamadas (ACD).
22 Call pickup.
110
Interactive Voice Response (IVR)
Também conhecida como Unidade de Resposta Audível (URA), serve para criar menus de
navegação. Dessa forma é possível encaminhar o cliente até um atendente especializado ou
ainda, em alguns casos, automatizar o atendimento sem nenhuma participação humana.
Reconhecimento de voz
É possível instalar um módulo (software) para reconhecimento de voz. Assim, quando utili-
zado em conjunto com o IVR, possibilita a navegação simplesmente enunciando as opções
do menu, aumentando-as consideravelmente, pois o limite do teclado deixa de existir.
Text-to-Speech (TTS)
Movimento contrário ao reconhecimento de voz; um texto colhido de um banco de dados,
por exemplo, pode ser lido para o cliente. Implementada via software, essa função permite
elevado grau de automação, dispensando atendentes humanos em alguns casos.
Call Detail Record (CDR)

O Registro do Detalhamento das Chamadas identifica e detalha todas as chamadas reali-
zadas e recebidas pelo sistema. A partir dessa informação é possível tarifar chamadas com
preços diferenciados por qualquer regra estabelecida. É possível também criar sistemas
de bilhetagem (pré e pós-pago) e instalar módulos para pagamento on-line e impressão de
boleto bancário, para a criação de um serviço de compra e venda de minutos ou qualquer
outro tipo de comercialização de serviços de voz.
DAC (Automatic Call Delivery – ACD)

Também conhecido como serviço de filas de chamadas (queues), é um recurso criado para
evitar a perda de chamadas entrantes por falta de atendentes, com larga utilização em call
centers. As chamadas chegam e são enfileiradas para que sejam atendidas assim que um
atendente estiver livre.
Uma vez enfileiradas, as chamadas podem ser encaminhadas para atendentes especiali-
zados, dependendo do número chamador ou do encaminhamento através de um IVR. Ainda
é possível realizar o encaminhamento por prioridade, por data e hora, por disponibilidade
etc. É possível também obter informações estatísticas das chamadas nas filas, como o
tempo médio de espera de uma chamada em determinada fila e taxa de desistência.
Gateway Fax-E-mail
É possível utilizar o Asterisk para receber e enviar fax utilizando o sistema de e-mail. Um
usuário da rede envia um e-mail para um endereço específico; o sistema recebe o e-mail e
transforma o corpo da mensagem ou o anexo (PDF, PS, DOC e TXT) e o encaminha via fax
pela rede de telefonia. No sentido inverso, o sistema recebe um fax, transforma-o em PDF e
o encaminha por e-mail para o usuário do sistema. Dessa forma, cada usuário que tiver um
ramal próprio pode ter também o seu fax pessoal.
O que o Asterisk não é e não faz

11 Sistema comum de telefonia. q
11 SIP Proxy.
22 OpenSER.
111
11 Gatekeeper H.323. q
22 GnuGK.
11 Não executa nativo no Windows.
11 O Asterisk possui como principal característica a flexibilidade:
22 Todos os seus arquivos são configuráveis.
11 Qualquer alteração em um de seus arquivos terá efeito em todo o sistema.
22 Não precisa de software adicional para funcionar.
O Asterisk não é um sistema comum de telefonia, porque para utilizá-lo é necessário algum
conhecimento, mesmo que mínimo, em Linux, redes e telefonia. Não basta ligá-lo na tomada
e conectar os fios dos ramais e da linha telefônica. É preciso configurá-lo antes de utilizá-lo.
O Asterisk não é um SIP Proxy, mas um Back-to-Back User Agent (B2BUA). Isso significa
que se trata de um User Agent (dispositivo SIP), que em uma conversa entre dois telefones
SIP simula um SIP Proxy. Na verdade, é visto como um telefone SIP para cada “perna” da
chamada. Na prática, é visto como um SIP Proxy. Da mesma forma, utilizando o protocolo
H.323, o Asterisk não é um gatekeeper, mas simula ser um gatekeeper, uma espécie de
B2BUA. Essa característica faz com que o Asterisk não seja a melhor ferramenta para lidar
com grande quantidade de telefones IP. Dois exemplos de softwares de código aberto para
grandes instalações VoIP são o OpenSIPS, que funciona como SIP Proxy, e o GnuGK, que
funciona como gatekeeper. Em grandes redes, o Asterisk deve trabalhar em conjunto com
outras ferramentas mais apropriadas para essa finalidade, exercendo o papel de gateway
(traduzindo protocolos ou fazendo a interface com o sistema de telefonia convencional) ou
de servidor de aplicações de voz.
O Asterisk é altamente flexível, com configuração totalmente baseada em arquivos de texto

e sintaxe facilmente compreendida. A estratégia de manter comentários nos arquivos de
configuração facilita muito a configuração do sistema, mesmo para usuários iniciantes que
nunca viram o sistema.
Existe um arquivo de configuração para cada parte do sistema: SIP, H.323, filas, música em
espera, interface com banco de dados, Call Detail Record (CDR) etc. Cada módulo possui um
arquivo separado e de fácil entendimento. Além disso, utilizando Asterisk Gateway Interface
(AGI) ainda é possível criar novos programas em qualquer linguagem de programação para
interação com a rede de dados. Por exemplo, é possível construir uma aplicação que, ao
receber uma chamada, o sistema peça para digitar um número de matrícula. Após o recebi-
mento do número, o sistema procura o status do cliente em um banco de dados e, depen-
dendo da informação retornada, decide a ação a ser executada.
Protocolos usados pelo Asterisk

11 Uso de protocolos VoIP no Asterisk: q
22 Estabelecer as conexões.
22 Determinar o ponto de destino.

Serviço fone@RNP
22 Estabelecer questões relacionadas à sinalização de telefonia, como:
33 Indentificador de chamada.
33 Desconexão.
112
11 IAX e o Asterisk. q
22 Protocolo aberto.
22 Histórico.
33 Desenvolvido pela Digium com o propósito de comunicação com outros servi-

dores Asterisk.
33 Protocolo de transporte.
33 Utiliza porta UDP (4569).
11 Canais de sinalização.
11 Transporte de mídia.
11 No IAX, usuários são autenticados de três formas:
22 Plaintext.
22 MD5 hashing.
22 RSA.
Facilidades do IAX:
11 Fornece controle e transmissão de voz sobre redes IP.
11 Utiliza qualquer tipo de mídia, como voz e vídeo.
Características do IAX:
11 Derivado da experiência dos protocolos SIP e MGCP.
11 Utiliza o mesmo protocolo para sinalização e mídia em uma mesma porta UDP.
Objetivos do protocolo IAX:
11 Minimizar o uso de banda.
11 Prover transparência à NAT.
11 Facilidade de uso na presença de firewalls.
11 Possibilidade de transmitir informações sobre plano de discagem.
O protocolo é um conjunto de regras. Fazendo uma analogia, imagine que você encontra
uma pessoa na rua e a cumprimenta com um “bom dia”. No mínimo você espera um “bom
dia” como resposta. Mas imagine que você não recebeu de volta a sua resposta. Então, você
repete o “bom dia”. Desta vez você recebe a sua resposta e inicia uma conversa. Durante a
conversa, enquanto a outra pessoa fala, de vez em quando você balança a cabeça afirma-
tivamente para demonstrar que está acompanhando seu interlocutor. No final, vocês se
despedem dizendo “tchau”.
Essas ações fazem parte de um protocolo de comunicação pessoal. Nada foi declarado,
escrito ou documentado para fazer desses gestos e frases um protocolo formal, mas a
prática aprendida no cotidiano faz esse conjunto de ações definirem o início da conversação
(“bom dia”), o acompanhamento (“uhum”) e o término (“tchau”) da conversa.
Note que, mesmo quando a informação é perdida, quando no início da conversa você não
recebe a resposta do seu interlocutor, existe uma “regra” que o faz tentar novamente o esta-
belecimento da conversa. Essa regra diz: caso não haja resposta em um tempo adequado,
repita o “bom dia”. A mesma coisa pode-se dizer das comunicações de dados. A forma como
uma página da internet é solicitada e transferida faz parte de protocolos como HTTP, TCP,
UDP, RTP, IP e FTP, exemplos de protocolos para a transferência de informação.
113
Em VoIP não é diferente: H.323, SIP, MCGP e IAX são protocolos de Voz sobre IP suportados
pelo Asterisk. Todos eles possuem uma forma de estabelecer, controlar e finalizar chamadas,
além de uma forma de lidar com a perda de mensagens importantes. Mesmo na telefonia
tradicional, digital ou analógica, existem meios de estabelecer, controlar e finalizar chamadas.
Principais protocolos de Voz sobre IP suportados pelo Asterisk:
11 Session Initiation Protocol (SIP).
11 H.323 (padrão definido pela ITU).
11 Inter-Asterisk eXchange Protocol (IAX) v1 e v2.
11 Media Gateway Control Protocol (MGCP).
11 SCCP (Cisco Skinny), protocolo proprietário da Cisco.
Protocolo IAX
O Inter Asterisk eXchange (IAX) foi desenvolvido pela Digium com o propósito de comuni-
cação eficiente com outros servidores Asterisk. A versão 2 do protocolo (IAX2) está definida
na RFC 5456. É um protocolo aberto, isto é, qualquer pessoa pode baixá-lo da internet e
aprimorá-lo. De acordo com o texto da RFC, ele não é um padrão do IETF e deve ser utilizado
com cautela.
O Asterisk utiliza apenas uma porta UDP conhecida e fixa (4569), para tráfego de sinalização
e mídia. Essa estratégia cria uma boa vantagem sobre os outros protocolos de VoIP, pois não
sofre com implementações de NAT. Além disso, também facilita o tratamento dos pacotes
em firewalls, sem a necessidade da instalação de módulos específicos para VoIP.
O protocolo IAX2 permite a autenticação de dispositivos utilizando:
11 MD5 Message-Digest (conforme a RFC 1321): nesse caso, a senha não trafega pela rede,
mas sim a resposta a um desafio calculado, utilizando uma combinação com o domínio e
um número aleatório. Forma utilizada pelo SIP, com base na autenticação www.
11 RSA (de acordo com a RFC 3447): utiliza par de chaves pública e privada. A chave pública
deve ser criptografada como algoritmo 3DES, descrito na RFC 1851.
Como já sabemos, o IAX utiliza apenas a porta UDP 4569, tanto para a sinalização das cha-
madas quanto para o transporte da voz. Além disso, diferentemente do SIP e do H.323, o IAX
não utiliza o RTP para transporte de mídia, mas implementa seu próprio mecanismo para
transporte e controle do canal de mídia, seja de voz ou vídeo.
O IAX foi desenvolvido para prover controle e transmissão de voz e vídeo por meio de
servidores Asterisk. Também é utilizado para conexões entre clientes e servidores que o
suportam. Ele aproveita ideias do SIP, do H.323 e de outros protocolos. Por exemplo, evita
fortemente o envio de informação redundante e já conhecida, que não seria aproveitada.
Também utiliza códigos em vez de descrever textualmente a informação. Essas caracterís-
ticas tornam o IAX um protocolo mais rápido e eficiente para tratamento de chamadas.
Network Address Translation (NAT) é um recurso de tradução de endereço de rede muito comum,
Serviço fone@RNP
usado quando é necessário ligar mais de um dispositivo de rede à internet, mas só há um ende-
reço roteável pela grande rede. O NAT causa problemas com protocolos como H.323 e SIP, porque
eles utilizam um canal (par de portas origem e destino) para o controle das chamadas e, durante
o estabelecimento da chamada, negociam dinamicamente outros dois canais para mídia, um em
cada sentido. O que acontece é que o roteador que implementa o NAT fica “perdido” e não con-
segue saber o par de portas através do qual o canal de mídia será transmitido.
114
Essa alocação dinâmica dos canais de mídia representa um problema adicional para os
firewalls que, da mesma forma que no NAT, não conseguem saber que portas devem ser
abertas para as ligações estabelecidas.
Existem implementações de firewall e NAT que conseguem identificar os canais de

mídia porque, ao perceberem um pacote com características de uma ligação SIP ou
H.323, analisam o pacote completamente até a camada 7 (de aplicação) e verificam
os endereços e portas que serão utilizadas para o tráfego de mídia. Obviamente,
esse artifício consome recursos computacionais do firewall e deve ser evitado
quando possível.
O protocolo IAX resolve facilmente esses problemas, porque utiliza apenas a porta UDP
4569 para controle e transmissão de todas as chamadas entre os dois servidores. Outra
vantagem do protocolo IAX é o modo trunk (tronco) para transmissão das chamadas entre
servidores. Quando configurados para operar nesse modo, dois servidores Asterisk são
capazes de otimizar o consumo de banda quando houver mais de uma chamada em curso
entre eles. O IAX consegue utilizar o mesmo cabeçalho IP e UDP para transmitir várias
ligações simultaneamente em um só pacote, aumentando apenas 4 bytes de cabeçalho para
cada chamada no “tronco”.
Por exemplo, para 30 chamadas utilizando SIP ou H.323 com codec G.729, para cada pacote
de voz seria necessário um cabeçalho IP+UDP+RTP. Como cada cabeçalho possui 40 bytes
e cada payload (carga útil do pacote de voz) também possui 40 bytes, teremos 30 x (40+40)
bytes trafegando na rede 50 vezes por segundo. O resultado da conta revela consumo de
banda de aproximadamente 960 kbps.
Por outro lado, se for utilizado o IAX2 em modo tronco com as mesmas 30 ligações e codec
G.729, teremos um cabeçalho IP+UDP de 28 bytes mais 30 vezes 4 bytes, mais 30 vezes o
payload de 40 bytes: 28 + 30 x (4+40). O resultado dessa conta indica consumo de banda de
539,2 kbps, pouco mais que a metade dos protocolos consagrados.
As mensagens IAX são chamadas de frames. Existem vários tipos de frames, como o
Frame completo e o Miniframe.
As mensagens IAX são chamadas de frames. Existem vários tipos de frames. Um bit F é
usado para indicar se o frame é completo (full) ou não. O valor 0 indica que é completo. Um
número de chamada de 15 bits é usado para identificar o ponto final do fluxo de mídia. Valor
0 indica que o ponto final não é conhecido. Uma chamada tem dois números de chamada
Figura 6.2
Frame completo associados a ele em qualquer uma das direções. O horário (timestamp) pode ser um campo
do IAX. de 32 ou 16 bits. De qualquer forma, o campo ocupa 32 bits.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
F Número originador da chamada R Número de destino da chamada
Timestamp
OSeqno ISeqno Frame Type C Subclasse
115
Um frame completo pode ser usado para enviar sinalização, áudio e vídeo de forma confi-
ável. O frame completo é o único tipo de frame transmitido de maneira confiável. Isso signi-
fica que após o recebimento o receptor deve retornar algum tipo de mensagem ao emissor.
O bit R é marcado para 1 se o frame está sendo retransmitido. A retransmissão ocorre após
um período de timeout. As retransmissões são tentadas várias vezes, dependendo do con-
texto. O número de sequência do fluxo de saída (outbound) OSeqno inicia com 0 e é incre-
mentado de um em um. O campo OSeqno é usado para identificar a ordenação dos frames
de mídia. O campo ISeqno é o mesmo, só que no sentido de entrada (inbound). O tipo de
frame indica a classe da mensagem. O bit C determina como a subclasse é interpretada.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
F Número originador da chamada Timestamp
Dados
Figura 6.3
O miniframe é usado para enviar áudio ou vídeo (mídia) com um mínimo de sobrecarga de Miniframe do IAX.
protocolo. O formato do miniframe é apresentado na Figura 6.3.
O timestamp do miniframe é truncado. O cliente geralmente mantém o timestamp completo

de 32 bits. Quando está enviando miniframes, os 16 bits de ordem mais baixa são enviados
no campo timestamp. Quando o timestamp de 16 bits dá a volta (estoura), um frame com-
pleto é enviado para permitir que o outro lado sincronize. Uma descrição completa do
protocolo IAX pode ser encontrada na RFC 5456 ou em: http://www.cornfed.com/iax.pdf
Campos do frame completo do IAX
Campo Descrição
F Marcado para 1, indica que é um frame completo.
Source Call Number Número de chamada originador do lado de transmissão.
R Marcado para 1, indica que o frame está sendo retransmitido e o valor do 0 para a
transmissão inicial.
Destination Call Number Número de chamada de destino do lado receptor do frame.
Timestamp Timestamp completo de 32 bits.
OSeqno Número de sequência do fluxo de saída.
ISeqno Número de sequência do fluxo de entrada.
Frame Type Tipo de frame.
C Formato do valor da subclasse.
Subclasse Subclasse.
Serviço fone@RNP
Tabela 6.1
Campos do frame
completo do IAX.
116
Campos do miniframe do IAX
Campo Descrição
F Marcado para 0, indica que é um frame

incompleto.
Source Call Number Número de chamada originador do lado de

Tabela 6.2 transmissão do frame completo.
Campos do
miniframe do IAX. Timestamp Timestamp de 16 bits.
Dados Dados.
SIP IAX H.323
Vantagens 11Largamente implementado 11Uso eficiente da banda. 11Larga adoção pelo

pelas operadoras VoIP. 11Transparente a implemen- mercado.
11Padrão de fato para a tações de NAT. 11Padrão de fato para
telefonia IP no momento. 11 Simples e rápido. videoconferência.
11Essencial na conectividade
com projetos mais antigos.
Desvantagens 11Problemas com NAT e FW. 11Protocolo ainda pouco 11Arquitetura complexa.
difundido, implementado 11Problemas com NAT e FW.
em poucos dispositivos.
Tabela 6.3 A Tabela 6.3 resume as qualidades e defeitos dos dois principais protocolos, confrontando-os
Comparativo entre com o IAX, o protocolo feito para o Asterisk.
IAX, SIP e H.323.
Resumo
11 IAX: protocolo eficiente, que procura economizar ao máximo os recursos da rede,

reduzindo o consumo de banda da rede, o consumo de processamento em roteadores e,
por ser bem simples, também reduz o consumo de recursos para o processamento das
chamadas no PABX.
11 H.323: mais antigo e maduro protocolo de VoIP. Completo e bem consolidado, é o

protocolo mais utilizado para videoconferência. Por outro lado, é relativamente lento e
complexo, além de apresentar problemas com implementações de NAT.
11 SIP: protocolo da vez na internet, é o mais utilizado para chamadas VoIP, talvez sendo
o mais adequado para uma implementação em larga escala. Mais flexível que o H.323,
porém menos eficiente que o IAX.
Arquitetura do Asterisk
q
O Asterisk possui uma arquitetura simples, diferente da maioria dos produtos de tele-
fonia. Atua como um intermediador entre:
11 Tecnologias de telefonia.
22 IAX.
22 SIP.
22 H.323.
117
11 Aplicações da telefonia. q
22 Conferência de voz.
22 Secretária eletrônica.
22 Estacionamento de chamadas.
Limitações da arquitetura do Asterisk:
11 Usa a CPU do servidor para processar os canais de voz.
11 Sistema muito dependente da performance da CPU.
11 Requer acesso de alta prioridade frequente para a CPU.
Canais do Asterisk:
11 Conexões lógicas para a trajetória das sinalizações e transmissões.
11 As conexões podem ser:
22 Físicas.
22 Baseadas em software.
11 As regras para os canais são definidas no plano de discagem.
Os canais têm vários tipos de formatos. Circuitos físicos:
11 FXO: ForeigneXchange Office.
11 FXS: ForeigneXchange Station.
11 PRI: Primary Rate Interface.
11 BRI: Basic Rate Interface.
Baseados em software:
11 SIP: Session Initiation Protocol.
11 IAX: Inter-AsteriskeXchange Protocol.
Canais internos do Asterisk:
11 Agent.
11 Local.
11 TDMoE: TDM over Ethernet.
Em essência, o Asterisk atua como um mediador, conectando as tecnologias de telefonia

às aplicações da telefonia, criando um ambiente consistente. As tecnologias de telefonia
podem incluir serviços VoIP, como SIP, H.323, IAX e MGCP; tecnologia TDM, como T1/E1, ISDN
PRI e R2D, e ainda as linhas analógicas conhecidas como POTS e/ou PSTN. Já as aplicações de
telefonia incluem: callbridging, conferência de voz (conferencing), secretária eletrônica (voi-
cemail), IVR scripting (Unidade de Resposta Audível – URA) e estacionamento de chamadas
(call parking), entre outras.
Serviço fone@RNP
118
API de aplicação
Tradutor
API de formatos de arquivos

API para tradução de codec
de codecs
Inicializador Gerenciador e escalonador

de aplicações de Entrada/Saída
Núcleo de
comutação
Carregador de
módulos dinâmicos
Figura 6.4
Dynamic Module
API de canais
Loader.
Módulo responsável por carregar e inicializar todos os drivers necessários, providos por:
11 Drivers de canal (channel drivers).
11 Formato de arquivos (file formats).
11 Detalhe de chamadas gravadas (call detail records).
11 Codecs.
11 Aplicações.
Tradutor de codec (codec translator)

Conversão transparente entre canais utilizando diferentes codecs, realizada para obter o
máximo de chamadas possíveis em uma rede de dados em que haja necessidade de con-
verter os codecs.
Núcleo de comutação PBX (PBX switching core)

Começa aceitando chamadas vindas das interfaces, depois as encaminha para a aplicação
adequada, conforme descrito no plano de discagem para:
11 Fazer um telefone tocar.
11 Conectar-se ao correio de voz.
11 Discagem para a rede pública.
Agendador e gerente de I/O (scheduler and I/O manager)

Módulo que oferece funções para aplicativos e drivers. O Asterisk usa a CPU do servidor para
processar os canais de voz, em vez de ter um processador de sinais digitais (DSP) dedicado a cada
canal. Por isso exige muito da capacidade de processamento da sua CPU. Sendo assim, deve-se
evitar realizar muitas traduções entre codecs diferentes. A utilização do cancelador de eco via
software em ambientes muito carregados ou com baixa capacidade de processamento também
pode prejudicar a qualidade das chamadas. Entretanto, existem placas para uso com o Asterisk
que contam com DSP próprio, inclusive possuem os codecs G.729 e GSM. Também existem
módulos e placas exclusivamente voltadas para o cancelamento de eco. A utilização de placas com
DSP embutido reduz consideravelmente a utilização de CPU no servidor que hospeda o Asterisk.
Para o Asterisk, canais são conexões lógicas para a trajetória das várias sinalizações e
transmissões que podem ser utilizadas para criar e conectar chamadas. Podem ser físicas
(porta analógica FXO ou FXS) ou baseadas em software (canal IAX). No plano de discagem
119
são definidas as regras que o Asterisk deve seguir para conectar canais. Por exemplo, se
uma chamada é recebida pela rede de telefonia tradicional por um tronco E1 e deve chamar
um ramal SIP, o plano de discagem deve possuir regras para ligação dos canais digitais TDM
ao canal digital (por software) SIP correspondente ao telefone de destino. A forma como o
Asterisk trata os canais de comunicação simplifica bastante sua configuração, pois no plano de
discagem todos são tratados da mesma forma, praticamente com a mesma sintaxe.
Principais canais do Asterisk:
11 ForeingeXchange Office (FXO): interfaces analógicas utilizadas para a comunicação com

a operadora ou posição de ramal de um PABX.
11 ForeingeXchange Station (FXS): interfaces analógicas para ligação de ramais tradicionais.
11 Primary Rate Interface (PRI): serviço Redes Digitais de Serviços Integrados (RDSI) que provê
30 canais do tipo B (Bearer) de 64 Kbps para voz e um canal do tipo D (Data) para controle e
sinalização, também conhecido como 30B+D. Utilizam interfaces digitais E1. Nos EUA, é utili-
zada a interface T1 e, nesse caso, a quantidade de canais para voz diminui para 24.
11 Basic Rate Interface (BRI): interface RDSI desenvolvida para pequenos negócios. Contém
apenas dois canais do tipo B e um canal do tipo D, também conhecido como 2B+D.
11 Session Initiation Protocol (SIP): protocolo utilizado na telefonia IP.
11 Inter AsteriskeXchange (IAX): protocolo utilizado na telefonia IP, proprietário do Asterisk.
11 Agent: canal proxy de distribuição de chamadas em fila para atendentes, muito utilizado
em implementações para centrais de atendimento.
11 Local: utilizado na lógica de programação do Asterisk, faz loops com as chamadas dentro
do plano de discagem, em contextos diferentes.
11 TDMoE: canal especial do Asterisk que simula conexões Time Division Multiplexing (TDM)
Tabela 6.4
na camada de enlace da rede local, útil para interligar dois ou mais servidores Asterisk na Canais que o
mesma Local Area Network (LAN). Asterisk suporta.
Canais que o Asterisk suporta
Canais Detalhe
Agent Um canal de agente ACD.
Console Cliente de console do Linux. Driver para placas de som (OSS ou ALSA).
H.323 Um dos protocolos mais antigos de VoIP.
IAX e IAX2 O próprio protocolo do Asterisk.
MGCP Outro protocolo de VoIP.
Modem Usados para linhas ISDN e não modem.
NBS Usado para broadcast de som.
Phone Canal de telefonia do Linux.
SIP Protocolo mais comum em VoIP.

Serviço fone@RNP
Skinny Um driver para o protocolo dos telefones IP da Cisco.
VOFR Voz sobre Frame Relay.
VPB Linhas telefônicas para placas da Vicetronix.
ZAP Para conectar telefones e linhas com placas da Digium. Também usado para TDMoE e para
Asterisk ZPHFC (ISDN em modo NT).
120
Outros canais do Asterisk:
11 H.323: protocolo de voz sobre IP do ITU.
11 MGCP: protocolo de voz sobre IP.
11 Modem: utilizado em linhas Integrated Services Digital Network (ISDN).
11 NBS: utilizado para broadcast de som.
11 Phone: utilizado para telefonia no Linux.
11 Skinny: protocolo de voz sobre IP utilizado nos telefones da Cisco.
11 VOFR: voz sobre Frame Relay.
11 VPB: canais de voz das placas Voicetronix.
11 ZAP: canais de voz das placas baseadas no projeto Zapata (placas digitais da Digium).
Conforme mais empresas desenvolvem soluções para Asterisk, mais essa lista cresce. Os
parâmetros de configuração dos canais dependem de cada fabricante. Portanto, não há uma
regra única para configurar os diversos canais do Asterisk.
Estrutura dos arquivos de configuração

11 O Asterisk é controlado por meio de arquivos de configuração. q
22 /etc/asterisk
11 O formato dos arquivos de configuração do Asterisk é semelhante ao formato dos

arquivos Windows (.ini).
11 Os arquivos estão em formato ASCII, divididos em seções.
22 Nomes das seções entre [ ].
11 Em seguida aos pares de colchetes:
22 Valor separado por (=) ou (=>).
11 ( ; ) é usado para comentário.
O Asterisk é controlado por meio de arquivos de configuração localizados no diretório

padrão /etc/asterisk. O formato dos arquivos de configuração do Asterisk é semelhante ao
dos arquivos (.ini) do Windows. Os arquivos estão em um formato ASCII, em texto plano.
Sintaxe
Os arquivos de configuração são divididos em seções designadas pelo nome entre colchetes
“[ ]”. O ponto e vírgula “;” é o caractere de comentário.
Dentro de cada seção, seguem os atributos e seus valores, separados por um sinal de igual
“=” ou por um sinal de igual seguido de maior “=>”. Uma forma de distinguir a utilização
dos sinais de atribuição pode ser adotada como no exemplo, onde é usado o sinal “=” para
atribuição de valores a variáreis e o sinal “=>” para a instanciação de objetos, muito embora
possam ser utilizados indistintamente. Veja o exemplo:
; A primeira linha sem ser comentário deve ser um título de sessão.
[sessao1]
chave = valor ; Designação de variável
[sessao2]
121
objeto => valor ; Declaração de objeto
Grupo simples
Formato mais básico, usado por arquivos de configuração em que os objetos são declarados
com todas as opções na mesma linha. Os arquivos extensions.conf, meetme.conf e voice.conf
seguem esse formato. No exemplo a seguir, o objeto1 é criado com as opções op1, op2 e
op3, enquanto o objeto2 é criado com as opções op1b, op2b e op3b.
[sessao]
objeto1 => op1, op2, op3
objeto2 => op1b, op2b, op3b
Entidades individuais
Sintaxe usada por arquivos de configuração em que objetos são declarados com muitas
opções, raramente compartilhadas com outros objetos, de modo que uma seção é asso-
ciada a cada objeto. Existe normalmente uma seção [general] para as configurações globais.
No exemplo seguinte, a seção geral define duas variáveis globais. Em seguida, dois objetos
são criados: [objeto1] e [objeto2].
[general]
globalop1=valorglobal1
globalop2=valorglobal2
[objeto1]
op1=valor1
op2=valor2
[objeto2]
op1=valor3
op2=valor4
Formato de objeto com herança de opções

Esse formato é usado por: phone.conf, mgcp.conf, zapata.conf e outras interfaces onde há
muitas opções. Na classe de arquivo de configuração, existem, tipicamente, uma ou mais
seções que contêm declarações de um ou mais canais ou objetos. As opções para o objeto
são especificadas acima da declaração do objeto e podem ser mudadas para a declaração de
outro objeto. Considere o exemplo abaixo:
[sessao]
op1 = bas
Serviço fone@RNP
op2 = adv
objeto => 1
op1 = int
objeto => 2
122
As duas primeiras linhas configuram o valor das opções op1 e op2 para “bas” e “adv”, respec-
tivamente. Quando o objeto1 é instalado, é criado com sua opção1 como “bas” e sua opção2
sendo “adv”. Após declarar o objeto1, mudamos o valor da opção1 para “int”. O objeto2 é
criado com sua opção1 como “int” e sua opção2 permanecendo “adv”.
Objeto entidade complexa

Formato usado por iax.conf, sip.conf e outras interfaces nas quais existem numerosas
entidades com muitas opções, que tipicamente não compartilham grande volume de con-
figurações comuns. Cada entidade recebe seu próprio contexto; pode existir um contexto
reservado, como [general], para as configurações globais. As opções são especificadas na
declaração de contexto. Considerando o exemplo:
[entidade1]
op1=valor1
op2=valor2
[entidade2]
op1=valor3
op2=valor4
A entidade [entidade1] tem valores valor1 e valor2 para as opções op1 e op2, respectiva-
mente. A entidade [entidade2] tem valores valor3 e valor4 para as opções op1 e op2.
Organização dos arquivos de configuração

11 Os arquivos de configuração do Asterisk são comumente organizados nos q
diretórios abaixo:
11 Arquivos de configuração.
22 /etc/asterisk
11 Executáveis e scripts.
22 /usr/sbin/asterisk astmanastgenkeysafe_asterisk
11 Bibliotecas e módulos.
11 /usr/lib/asterisk/modules
Os arquivos de configuração do Asterisk são comumente instalados nos diretórios listados

a seguir. Para facilitar a administração do sistema, recomenda-se que a estrutura original
seja mantida. Se for alterada, deverá ser escrita uma documentação bem estruturada, para
facilitar a manutenção do sistema.
Alguns desses locais podem ser personalizados no arquivo de configuração /etc/asterisk/

asterisk.conf. Outros podem ser modificados durante a compilação do programa.
11 Arquivos de configuração.
22 /etc/asterisk
11 Executáveis e scripts.
22 /usr/sbin/asterisk
22 /usr/sbin/astman
123
22 /usr/sbin/astgenkey
22 /usr/sbin/safe_asterisk
11 Bibliotecas e módulos.
22 /usr/lib/asterisk
22 /usr/lib/asterisk/modules
11 Arquivos (headers) para criação de aplicativos, drivers e módulos.
22 /usr/include/asterisk
11 PID do processo.
22 /var/run/asterisk
11 Arquivos Voice Mail e chamadas outbounds.
22 /var/spool/asterisk
11 Área de dados.
22 /var/lib/asterisk
11 Scripts usados pelo AGI.
22 /var/lib/asterisk/agi-bin
11 Banco de dados.
22 /var/lib/asterisk/astdb
Aplicações
11 Partes fundamentais do Asterisk. q
11 Cada aplicação executa uma ação específica no canal em questão.
22 Emitem sons.
22 Aceitam dígitos.
22 Desligam uma chamada.
11 No Command Line Interface (CLI) é utilizado o comando show applications.
As aplicações são partes fundamentais do Asterisk, funcionando como comandos. Elas

tratam o canal de voz, tocam sons, aceitam dígitos, atendem e desligam uma chamada. As
aplicações normalmente são utilizadas com opções que afetam a sua forma de funciona-
mento. As opções variam entre as aplicações e cada uma possui seu próprio leque de opções.
No console do Asterisk você pode digitar o comando show applications para visualizar a lista de
aplicações suportadas pela sua instalação do Asterisk. Veja alguns exemplos de aplicações.
Aplicações Descrições
Answer ( ) Responde a um canal que está chamando.
Absolute Timeout ( ) Define o limite de tempo de uma chamada em segundos.
Background ( ) Reproduz o(s) arquivo(s) de áudio especificado(s) enquanto espera

que o usuário comece a inserir um ramal.
Serviço fone@RNP
Congestion ( ) Solicita que o canal indique o congestionamento e então espera

que o usuário desligue ou que o tempo de expiração acabe (em
segundos).
Dial ( ) Permite que você conecte todos os tipos de canal.
124
Aplicações Descrições
Hangup Incondicionalmente desliga o canal atual.
Playback ( ) Toca um arquivo de som previamente gravado sobre um canal.
SetGlobalVar ( ) Define uma variável global. As variáveis globais estão disponíveis

para todos os canais.
Tabela 6.5
Aplicações comuns VoiceMail ( ) Deixa mensagens de voz em determinada caixa postal.
do Asterisk.
Exemplo: [incoming]
Exten=>s,1,Answer
Exten=>s,2,Background(enter-ext-of-person)
Exten=>1,1,Playback(digits/1)
Exten=>1,2,Goto(incoming,s,1)
Exten=>2,1,Playback(digits/2)
Exten=>2,2,Goto(incoming,s,1)
Nesse exemplo, as ligações que chegam ao contexto incoming são recebidas pela primeira
linha, a extensão especial “s”. A primeira aplicação associada, ou seja, o primeiro comando
executado é o Answer, que responde à chamada e prepara o ambiente para tratá-la. Em
seguida, a chamada é colocada em segundo plano pela aplicação background. Esse comando
toca o arquivo inter-ext-of-person e aguarda que o chamador digite uma opção. Caso ele
digite 1, a extensão 1, prioridade 1 (exten => 1,1) é executada tocando o arquivo digits/1.
Quando o arquivo termina, a ligação passa para a prioridade 2 (exten => 1,2), que envia o
fluxo para o contexto incoming (o mesmo em que a ligação se encontra), extensão s, priori-
dade 1, ou seja, para o início. A outra opção válida nesse exemplo é o dígito 2, que executará
as prioridades 1 e 2. Qualquer outra opção será inválida.
Exemplo: de aplicação echo( )

Não são necessários parâmetros adicionais.
exten => 100,1,Answer() # Atende a chamada
exten => 100,2,Playback(welcome) # A mensagem padrão welcome é

reproduzida
exten => 100,3,Playback(demo-echotest) # A mensagem padrão de eco

demo teste é reproduzida
exten => 100,4,Echo() # Executa a função de teste de eco. Para

terminar tecle ‘#’
exten => 100,5,Playback(demo-echodone) # Reproduz o que foi gravado

no teste de eco anterior
exten => 100,6,Playback(vm-goodbye) # Reproduz a mensagem padrão

goodbye (voicemail)
exten => 100,7,Hangup() # Desconecta a chamada, liberando a linha
125
Asterisk no fone@RNP
11 Serviço de gateway da instituição. q
11 Integração do serviço VoIP ao serviço de telefonia convencional.
Pode se integrar a:
11 PABX Convencional.
11 Empresa de telecomunicação.
11 PABX IP.
Realiza o encaminhamento das chamadas do serviço de telefonia convencional ao

serviço VoIP:
11 Aplica regras de discagem para a realização da chamada.
11 Aplicação de IVR para permitir integração com o serviço VoIP.
11 Contabilização das chamadas que forem tratadas pelo servidor.
11 Integração com o Legado.
O Asterisk no serviço VoIP das instituições usuárias do fone@RNP está disponível nas
máquinas 1 e 2 do serviço. Na máquina 1, o Asterisk encontra-se na versão 1.2 e seu uso é
obsoleto devido ao fato da sua função ser integrar o serviço SIP local ao serviço H.323 local.
Assim, com o desuso do serviço, H.323 também levou ao desuso do Asterisk da máquina 1.
Na máquina 2, encontra-se o Asterisk com função de gateway no serviço fone@RNP, sendo

responsável pela integração do serviço VoIP da instituição ao serviço de telefonia conven-
cional, alcançando assim ramais e telefones públicos da RTFC.
Através desse ponto de comunicação é possível integrar o serviço VoIP a outros serviços de
telefonia, como:
11 PABX Convencional utilizando entroncamentos analógicos ou digitais E1 via MFC/R2 ou

ISDN.
11 Empresa de telecomunicação também utilizando entroncamentos analógicos ou digitais

E1 via MFC/R2 ou ISDN.
11 PABX IP utilizando entroncamento SIP ou IAX.
Portanto, o Asterisk no fone@RNP é responsável por integrar o ambiente legado com os

entroncamentos com o PABX Convencional, reproduzir sistemas de IVR para identificação dos
números desejados, contabilizar as chamadas no serviço e definir regras de discagem válidas.
Serviço fone@RNP
126
Atividade 6.1 – Análise do arquivo de configuração do OpenSER
Analisando os arquivos de configuração criados pelo serviço fone@RNP nas máquinas 1 e 2,
responda as questões a seguir:
a. Qual o domínio utilizado pelo Proxy SIP?
b. O Proxy SIP utiliza algum Proxy de Mídia? Se sim, qual?
c. Descreva a forma de realizar autenticação no Proxy SIP.
d. Quais são os scripts externos utilizados pelo Proxy SIP? Identifique o objetivo de cada script.
e. Identifique no arquivo de configuração do OpenSER o local onde se registram as tenta-

tivas incorretas de REGISTER e INVITES.
f. Acrescente a informação do endereço IP de origem nos logs das tentativas sem sucesso
de registro de novas chamadas.
127
Atividade 6.2 – Análise do arquivo de configuração do Asterisk
Analise o arquivo de configuração do servidor Asterisk e responda as questões seguintes:
a. Defina a característica da variável EXTEN.
b. Escreva uma expressão regular que represente todos os ramais de 3 ou 4 dígitos da

sua instituição.
c. Descreva a função do Include.
d. Por que a necessidade de preencher as informações do OpenSER no sip.conf ?

Serviço fone@RNP
128
7
Softwares de apoio ao
ambiente local
Apresentar os principais conceitos de telefonia convencional, digital e analógica;
objetivos
mostrar modelos de hardware utilizados em VoIP e telefonia computacional;

apresentar a configuração do Asterisk para funcionar como gateway entre as redes
de telefonia convencional e IP.
conceitos
Telefonia analógica, telefonia digital, Asterisk como gateway.
LDAP
11 Lightweight Directory Access Protocol. q
11 Definido pela RFC 4510.
Lightweight Directory Access Protocol (LDAP) é um protocolo cliente/servidor de acesso a

diretórios X.500. Ele foi desenvolvido com base na pilha TCP/IP, utilizando a porta TCP 398, e
tinha como principal objetivo ser uma alternativa mais eficiente ao Directory Access Protocol
(DAP), que utilizava a pilha OSI. Atualmente o protocolo está na versão 3, sendo padronizado
pela RFC 4510. Sua estrutura de diretórios é otimizada para operações de busca, tendo como
objetivo retornar em um tempo curto a resposta para consultas de grande volume.
Os diretórios LDAP são organizados na forma de uma árvore hierárquica chamada Directory Capítulo 7 - Softwares de apoio ao ambiente local
Information Tree (DIT), onde cada um dos seus vértices representa uma entrada na base
de dados. Uma entrada no diretório representa um objeto e consiste de um conjunto de
atributos que forma uma coleção de informações sobre o elemento. Cada vértice da DIT é
identificado por um Distinguished Name (DN), que representa unicamente qualquer entrada
na árvore. Um DN é definido através de Relative Distinguished Names (RDNs), que repre-
sentam os ramos na árvore de diretório da raiz até a entrada.
O protocolo utiliza o conceito de cliente/servidor, onde o cliente transmite requisições des-

crevendo operações do protocolo que ele deseja que sejam executadas pelo servidor.
As principais operações definidas são:
11 Bind: permite a autenticação de um cliente ao servidor LDAP.
11 Unbind: termina uma sessão LDAP. Não representa o contrário da operação bind.
129
11 Search: retorna um conjunto de entradas que satisfaçam a um critério de seleção. Pode
ser utilizado para ler atributos de uma entrada (BASE), de entradas subordinadas (ONE)
ou da sub-árvore de entradas com raiz em um determinado vértice (SUBTREE).
11 Modify: permite que um cliente requisite uma modificação em uma entrada.
11 Add: permite que um cliente requisite a adição de uma entrada no diretório.
11 Delete: permite que um cliente requisite a remoção de uma entrada no diretório.
11 Modify DN: permite que um cliente modifique o RDN de uma entrada no diretório ou que
mude uma sub-árvore de entradas para uma nova localização no diretório.
11 Compare: permite a comparação de um determinado valor com um atributo de uma

entrada no diretório.
11 Abandon: permite o abandono de uma operação incompleta.
11 Extended Operation: permite a definição de operações adicionais.
11 StartTLS: inicia a instalação de uma camada TLS para comunicação segura.
O LDAP utiliza o conceito de Object Class (classe de objetos), através do qual se define
uma família de objetos que compartilham certas características. Um Object Class define o
conjunto de atributos obrigatórios e o conjunto de atributos opcionais para uma entrada
daquela classe, de forma que os elementos presentes em um objeto são definidos através
de suas classes de objetos. Entre as classes de objetos existe o conceito de herança, onde é
possível obter características a partir de uma classe pai.
As classes podem ser divididas em três categorias:
11 Abstract Object Classes: classe que provê um conjunto de características que têm como
objetivo serem herdadas por outra Object Class. Não pode representar um objeto direta-
mente, sendo necessário que um Structural ou Auxiliary Object Class herdem deste tipo
de classe para que uma entrada possua suas características.
11 Structural Object Classes: Object Class que define o núcleo de um objeto, com uso na
especificação da estrutura da DIT; através deste tipo de classe é definida a posição da
entrada na árvore de diretórios.
11 Auxiliary Object Classes: classe utilizada para implementar características adicionais,

aumentando o conjunto de atributos de uma determinada entrada.
Para definir a sintaxe utilizada na base de dados LDAP é utilizado um Directory schema. Um
schema é um conjunto de definições e limitações sobre a estrutura de uma DIT. É através
dele que se definem os Object Classes e seus atributos. O arquivo abaixo é um exemplo de
schema utilizado no ambiente fone@RNP.
attributetype ( 1.3.6.1.4.1.4203.666.3.110
NAME ‘alias’
DESC ‘Numero do telefone IP’
EQUALITY caseIgnoreMatch
Serviço fone@RNP
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
130
attributetype ( 1.3.6.1.4.1.4203.666.3.111
NAME ‘categoria’
DESC ‘Categoria do Usuario para tratamento diferenciado’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.112
NAME ‘callforward’
DESC ‘Descricao do callforwad ‘
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.113
NAME ‘ipaddress’
DESC ‘Endereço IP que o usuario devera usar para se registrar’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.114
NAME ‘validade’
DESC ‘Data de expiracao da conta’

Capítulo 7 - Softwares de apoio ao ambiente local
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.115
NAME ‘creditos’
DESC ‘Saldo em segundos’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
131
attributetype ( 1.3.6.1.4.1.4203.666.3.116
NAME ‘creditos-periodo’
DESC ‘Saldo por periodo’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.117
NAME ‘responsavel’
DESC ‘uid do responsavel’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.210
NAME ‘Cisco-AVPair’
DESC ‘Identificacao de usuarios cisco’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 1.3.6.1.4.1.4203.666.3.211
NAME ‘H323passwd’
DESC ‘chave de acesso do uid’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
objectclass ( 1.3.6.1.4.1.4203.666.3.1
Serviço fone@RNP
NAME ‘foneatrnp’
DESC ‘Fone@RNP’
SUP top
AUXILIARY
132
MUST ( uid $ cn $ userPassword $ mail $ alias $ carLicense )
MAY ( employeeType $ callforward $ responsavel $ creditos-periodo

$ creditos $ ipaddress $ validade $ categoria )
objectclass ( 1.3.6.1.4.1.4203.666.3.2
NAME ‘foneatrnp-h323’
DESC ‘Fone@RNP’
SUP top
AUXILIARY
MUST ( Cisco-AVPair $ H323passwd )
OpenLDAP
11 Suporta IPv4 e IPv6. q
11 Transporte seguro utilizando TLS e SSL.
11 Possibilidade de escolha de banco de dados.
11 Alta performance em múltiplas chamadas.
11 Possibilidade de replicação da base.
O OpenLDAP é um software open source utilizado por muitas distribuições Linux como sof-
tware padrão para acesso ao LDAP. O software foi desenvolvido inicialmente pela Universi-
dade de Michigan e conta com uma ativa comunidade de desenvolvedores.
O software possui como componentes principais um daemon (slapd), bibliotecas que imple-
mentam o protocolo LDAP e a codificação ASN.1 e outros softwares utilizados pelo cliente,
como ldapsearch, ldapadd e ldapdelete.
Existem dois principais arquivos de configuração:
11 ldap.conf: responsável pela configuração do acesso dos clientes à base de dados.

11 slapd.conf: responsável pela configuração do daemon.
Um exemplo deste arquivo de configuração utilizado no ambiente fone@RNP é dado a seguir:
include /usr/etc/openldap/schema/core.schema
include /usr/etc/openldap/schema/cosine.schema
include /usr/etc/openldap/schema/nis.schema
include /usr/etc/openldap/schema/inetorgperson.schema
include /usr/etc/openldap/schema/voip.schema
pidfile /usr/var/run/openldap/slapd.pid
133
argsfile /usr/var/run/openldap/slapd.args
loglevel 255
# Load dynamic backend modules:
moduleload unique
access to *
by dn=”cn=admin,dc=voip,dc=nce,dc=ufrj,dc=br” write
by anonymous auth
by * none
#############################################################
##########
# BDB database definitions
#############################################################
##########
database ldbm
suffix “dc=voip,dc=nce,dc=ufrj,dc=br”
rootdn “cn=admin,dc=voip,dc=nce,dc=ufrj,dc=br”
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details. Use of

strong authentication encouraged.
rootpw {SSHA}73GZpfjZTAZ+cD4aCtpgwrtnNzz35yXx
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.

Serviço fone@RNP
directory /usr/var/openldap-data
mode 0700
134
# Indices to maintain
index objectClass eq
index uid eq
index cn eq
index alias eq
overlay unique
unique_base “ou=users,dc=voip,dc=nce,dc=ufrj,dc=br”
unique_attributes alias
# Caso utilize H.323 descomente a linha abaixo
unique_attributes Cisco-AVPair
Instalação do OpenLDAP
Muitas versões do Linux possuem em seus repositórios uma versão do OpenLDAP.
É possível obtê-la através do comando:
apt-get install slapd
Caso não seja possível a instalação utilizando o comando acima, será necessário compilar o
código-fonte do OpenLDAP. O primeiro passo é a obtenção do código através do link:
http://www.openldap.org/software/download/
Após obter o pacote é necessário realizar a extração do código. Para isso, utilize o comando:
gunzip -c openldap-VERSAO.tgz | tar xf –cd openldap-VERSAO
Em seguida, execute o script configure através do comando:
./configure
Para dar build nas dependências, execute o comando:

make depend
Em seguida, compile o software através do comando:
make
Por fim, instale o software com o comando:
make install
RADIUS
11 Remote Authentication Dial In User Service. q
11 Definido pelas RFCs 2865 e 2866.
135
Remote Authentication Dial In User Service (RADIUS) é um protocolo Authentication, Autho-
rization, Accounting (AAA) desenvolvido em 1991 pela Livingston Enterprises e padronizado
pelas RFC 2865 e 2866. O protocolo se baseia no modelo cliente/servidor e é utilizado para
autenticação entre um Network Access Server (NAS), que atua como cliente, e um servidor
de autenticação.
As transações RADIUS são autenticadas através do uso de uma chave compartilhada que
nunca é enviada na internet, e as senhas utilizadas são enviadas de maneira criptografada.
O protocolo utiliza a porta UDP 1812 para autenticação e a porta UDP 1813 para contabilidade.
O processo de autenticação no protocolo é dado através de mensagens. A primeira mensagem

enviada pelo NAS para se autenticar é Access-Request, que contém atributos como nome do
usuário, senha do usuário (criptografada utilizando MD5), ID do cliente e porta, para o servidor
RADIUS. Ao receber um Access-Request, o servidor RADIUS tenta validar o cliente. Caso consiga
validar, o servidor consultará uma base de dados para tentar autenticar o usuário.
Caso os dados disponibilizados pelo cliente não correspondam aos encontrados na base
de dados, o servidor RADIUS enviará uma mensagem Access-Reject, negando o acesso do
usuário ao serviço. Caso os dados sejam válidos o servidor pode realizar um desafio através
da mensagem Access-Chalenge, enviando um número aleatório ao cliente e pedindo para que
este o criptografe com o objetivo de verificar a sua identidade.
Caso todas as condições especificadas para o acesso sejam satisfeitas, o servidor enviará
uma mensagem Access-Accept.
Cliente Servidor
RADIUS RADIUS
RADIUS: Access-Request
RADIUS: Access-Accept
or
RADIUS: Access-Reject
Figura 7.1
or Fluxo de
RADIUS: Access-Challenge
mensagens
RADIUS.
FreeRADIUS
11 Servidor modular. q
11 Rápido e escalável.
O software FreeRADIUS é uma suíte RADIUS modular de alta performance e de código

aberto, que inclui um servidor RADIUS, uma biblioteca para implementação de clientes
RADIUS e outros utilitários. É possível a inclusão de diversos módulos para permitir o acesso
a diversos tipos de bases de dados, como LDAP, MySQL, PostgreSQL e Oracle.
Serviço fone@RNP
O daemon do servidor FreeRADIUS é o radiusd. É extremamente recomendável rodar o

daemon em modo debugging durante a configuração do sistema, para que seja possível
identificar problemas na configuração. Para isso, o seguinte comando deve ser executado:
radiusd –X
136
As principais configurações do RADIUS são encontradas nos seguintes arquivos:
11 radiusd.conf: principal arquivo de configuração, que define as configurações de adminis-

trador e o modo de operação do servidor.
Um exemplo de configuração para conexão com LDAP é dado em:
modules {
ldap {
# Nome completo do servidor LDAP.
server=”10.10.10.10”
# Define a identificacao do usuario administrador

do LDAP.
# No exemplo eh considerado o dominio insta.nce.

ufrj.br.
identity=”cn=admin,dc=insta,dc=nce,dc=ufrj,dc=br”
# Senha do administrador do LDAP.
password=minhasenha
# basedn para buscar os usuarios
basedn=”ou=users,dc=insta,dc=nce,dc=ufrj,dc=br”
# notifica que o uid usado no filtro eh o stripped

username ou
# o username (inclui dominio)
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
password_attribute = H323passwd
# mapeia os attributetypes do LDAP com os atributos

do RADIUS
dictionary_mapping = /usr/etc/raddb/ldap.attrmap
ldap_cache_timeout = 150
ldap_cache_size = 0
ldap_connections_number = 10
timeout = 3
timelimit = 5
net_timeout = 1
compare_check_items = no
137
11 dictionary: define todos os atributos RADIUS usados em outros arquivos de configuração.
11 O arquivo a seguir exemplifica um dicionário usado no fone@RNP:
ATTRIBUTE Originating-Line-Info 94 string
ATTRIBUTE Digest-Response 206 string
ATTRIBUTE Digest-Attributes 207 octets
VALUE Service-Type Voice 12
VALUE Service-Type Fax 13
VALUE Service-Type Modem-Relay 14
VALUE Service-Type IAPP-Register 15
VALUE Service-Type IAPP-AP-Check 16
VALUE Framed-Protocol GPRS-PDP-Context 7
VALUE NAS-Port-Type Wireless-CDMA2000 22
VALUE NAS-Port-Type Wireless-UMTS 23
VALUE NAS-Port-Type Wireless-1X-EV 24
VALUE NAS-Port-Type IAPP 25
VALUE Framed-Protocol PPTP 9
11 clients.conf: contém o IP e uma chave secreta para todos os clientes que desejam se
conectar com o servidor. A seguir um exemplo de configuração deste arquivo:
client 127.0.0.1 {
secret = minhasenha
shortname = localhost
nastype = other # localhost isn’t usually a NAS...
client 10.10.10.10 {
secret = minhasenha
shortname = maq1
Instalação do FreeRADIUS
A forma mais simples de instalar o software em algumas distribuições Linux é através do
repositório. Para estes casos, basta utilizar o comando:
Serviço fone@RNP
# apt-get install freeradius
Caso não seja possível, será necessário compilar o código-fonte. É necessário realizar o seu
download na página:
# http://freeradius.org/download.html
138
O primeiro passo para instalar o software é a extração de seu código-fonte através do comando:
# tar zxvf freeradius-VERSAO.tar.gz
Mude para o diretório obtido usando o comando:
# cd freeradius-VERSAO
Em seguida é necessário executar o comando:
# ./configure
Para compilar o software é necessário executar o comando:
# make
O último passo da instalação do software é a execução do comando:
# make install
Slony-I
11 Replicação assíncrona. q
11 Um mestre e múltiplos escravos.
11 Suporte a cascading e failover.
Slony-I é um software open source de replicação assíncrona de bases de dados PostgreSQL.

Ele funciona no esquema mestre-escravo e dá suporte a cascading, onde escravos podem
ser criados e atualizados a partir de outros escravos, e failover, onde um servidor de backup
pode substituir o servidor principal em caso de falha. Dentre as funções do Slony-I podem
ser destacadas:
11 Replicação entre diferentes versões do PostgreSQL;
11 Replicação entre diferentes hardwares e sistemas operacionais;
11 Possibilidade de replicação de apenas uma parte das tabelas aos escravos;
11 Possibilidade de replicação de determinadas tabelas para um escravo e de tabelas

distintas para outro escravo;
11 Possibilidade de servidores diferentes serem mestres para tabelas diferentes.
O Slony-I define uma série de elementos que fazem parte do ambiente de replicação. São eles:
11 Cluster: conjunto de bases de dados PostgreSQL através das quais se dá a replicação. Capítulo 7 - Softwares de apoio ao ambiente local
Possui um nome definido.
11 Node: base de dados PostgreSQL que faz parte da replicação.
11 Replication Set: conjunto de tabelas e sequências que serão replicadas entre nós em um
cluster Slony-I.
11 Origem: nó a partir do qual os dados para replicação serão disponibilizados. Também conhe-
cido como Master Provider, é onde todas as modificações na base devem ser executadas.
11 Subscriber: nós do cluster que se cadastram em um Replication Set para receber os dados
replicados. Podem ser providers caso possuam outros subscribers associados a ele.
11 slon: daemon que gerencia a replicação em cada nó.
11 slonik: processador de comandos utilizados no Slony-I.
139
A configuração do software é dada através dos parâmetros passados na execução do
daemon. Um exemplo de configuração é dado pelo script abaixo:
#!/bin/sh
CLUSTERNAME=slave
MASTERDBNAME=chamadas
SLAVEDBNAME=chamadas
MASTERHOST=dser1.rnp.br
SLAVEHOST=10.10.10.10
REPLICATIONUSER=postgres
export CLUSTERNAME MASTERDBNAME SLAVEDBNAME
export MASTERHOST SLAVEHOST REPLICATIONUSER
chown postgres.postgres /var/lib/postgresql/.pgpass
chmod 0600 /var/lib/postgresql/.pgpass
/usr/bin/slon -s 1200000 -t 1800000 $CLUSTERNAME

“dbname=$SLAVEDBNAME user=$REPLICATIONUSER port=5432
host=$SLAVEHOST” > /dev/null &
Instalação do Slony-I
O Slony-I faz parte do repositório de algumas distribuições Linux, podendo ser obtido
usando o comando:
# apt-get install slony1-bin
Outra forma de instalação é a compilação do seu código. O primeiro passo para instalação
do software é a obtenção de seu código-fonte em: http://slony.info/downloads/
Em seguida, extraia o pacote obtido através do comando:
# tar -jxvf slony1-VERSAO.tar.bz2
Mude para o diretório extraído usando o comando:
# cd slony1-VERSAO
Em seguida execute o comando:
# ./configure
O próximo passo é a compilação do código-fonte através do comando:
# make all
Por fim, o último comando da instalação é:

Serviço fone@RNP
# make install
140
PostgreSQL
11 Livre. q
11 Código aberto.
11 Possibilidade de replicação (a partir da versão 9.0).
PostgreSQL é um Sistema de Gerenciamento de Banco de Dados (SGBD) desenvolvido

inicialmente na universidade de Berkeley na Califórnia, sendo o software open source atual
baseado no código original. Dá suporte a diversas funções, como:
11 Consultas complexas.
11 Chaves estrangeiras.
11 Triggers.
11 Views.
11 Integridade transacional.
11 Controle de concorrência multiversões.
Além disso, ainda é possível que os próprios usuários estendam sua funcionalidade com a
adição de novos:
11 Tipos de dados.
11 Funções.
11 Operadores.
11 Funções agregadas.
11 Métodos de indexação.
11 Linguagens procedurais.
A manipulação das bases de dados no PosgreSQL é dada através do terminal, utilizando

o comando psql, através do qual é possível executar consultas SQL diretamente ou de um
arquivo. Ao se instalar o software no Linux é criado um usuário postgres, que possui inicial-
mente permissão de alterar as tabelas. Para acessar este usuário, utilize o comando:
# su postgres
O usuário postgres tem a capacidade inicial de acessar qualquer base de dados através
do comando:
# psql DATABASE Capítulo 7 - Softwares de apoio ao ambiente local
As principais configurações do SGBD são dadas através dos arquivos:
11 postgresql.conf: arquivo utilizado para a configuração do servidor. Exemplo:
hba_file = ‘/etc/postgresql/8.1/main/pg_hba.conf’
ident_file = ‘/etc/postgresql/8.1/main/pg_ident.conf’
external_pid_file = ‘/var/run/postgresql/8.1-main.pid’
listen_addresses = ‘*’
port = 5432
max_connections = 500
141
unix_socket_directory = ‘/var/run/postgresql’
ssl = true
shared_buffers = 1000
log_line_prefix = ‘%t ‘
stats_row_level = on
autovacuum = on
lc_messages = ‘en_US.UTF-8’
lc_monetary = ‘en_US.UTF-8’
lc_numeric = ‘en_US.UTF-8’
lc_time = ‘en_US.UTF-8’
11 pg_hba.conf: arquivo para configuração da autenticação de hosts. Exemplo:
# Database administrative login by UNIX sockets
local all postgres ident sameuser
local all all md5
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# “local” is for Unix domain socket connections only
# IPv4 local connections:
host all all 127.0.0.1 255.255.255.255 md5
host all all 10.10.10.10 255.255.255.255 md5
host chamadas postgres 11.11.11.11 255.255.255.255 trust
host chamadas postgres 12.12.12.12 255.255.255.255 md5
host chamadas postgres 127.0.0.1 255.0.0.0 md5
host chamadas postgres 13.13.13.13/32 trust
host chamadas postgres 14.14.14.14/32 trust
host chamadas all 127.0.0.1/8 trust
host chamadas all 15.15.15.15/32 trust
Instalação do PostgreSQL
O PostgreSQL é disponibilizado no repositório de algumas distribuições Linux. Nestes casos,
basta obtê-lo a partir do comando:
Serviço fone@RNP
# apt-get install postgresql
Outra forma de instalação é através da compilação do software. O primeiro passo é a

obtenção de seu código-fonte no site da PostgreSQL. A seguir é necessário extrair os
arquivos. Se foi baixado o arquivo .tar.gz, utilize o comando:
142
# tar -xzvf postgresql-VERSAO.tar.gz
Caso o arquivo baixado tenha a extensão .tar.bz2, execute:
# tar -jxvf postgresql-VERSAO.tar.bz2
Mude para o diretório da instalação com o comando:
# cd postgresql-VERSAO
O primeiro script a ser executado é o configure, através do comando:
# ./configure
Para compilar o código use o comando:
# make
Para instalar o software execute o comando:
# Make install
Manutenção das informações do PostgreSQL

O PostgreSQL possui uma ferramenta simples de manutenção dos dados que é o Phppgadmin.
Disponível também para os endereços IP dos administradores e acessível pela URL
http://<IP_MAQ2>/phppgadmin.
Esta ferramenta dispõe de uma navegação simples e prática nas bases de dados existentes
e executar comandos SQL sobre elas. Como mencionado, no banco de dados do fone@RNP
existem quatro base de dados: RADIUS, OpenSER, Asterisk e chamadas.
Para acesso ao serviço também foram criados três usuários: radius, openser e asterisk.
O usuário Asterisk apenas faz acesso à base de dados Asterisk. O usuário OpenSER acessa
apenas a base de dados OpenSER. Por fim, o usuário RADIUS acessa as bases de dados RADIUS.
143
MediaProxy
11 Media Relay. q
11 Facilita a travessia de NAT.
Mediaproxy é um media relay para fluxos RTP/RTCP e UDP, sendo utilizado em conjunto com
o OpenSER/OpenSIPS. Sua principal funcionalidade é facilitar a travessia de NAT para fluxos
de mídia provenientes de agentes SIP.
Funcionalidades deste software:
11 Escalabilidade de milhares de chamadas por servidor.
11 Capacidade de utilização de TLS.
11 Suporte a fax T.38.
11 Balanceamento de carga e redundância automática entre servidores.
11 Faixa de IPs e de portas configuráveis.
11 Suporte a qualquer combinação de fluxos de áudio e vídeo.
11 Suporte a negociação ICE ao se comportar como um candidato a TURN relay.
O software é configurado através do arquivo de configuração mediaproxy.ini. O arquivo

abaixo exemplifica a utilização deste software:
; Configuration file for MediaProxy
[Dispatcher]
start = yes
socket = /var/run/mediaproxy/proxydispatcher.sock
group = openser
defaultProxy = /var/run/mediaproxy/mediaproxy.sock
[MediaProxy]
socket = /var/run/mediaproxy/mediaproxy.sock
group = openser
proxyIP = 146.164.247.240
portRange = 50000:50998
accounting = off
[Accounting]
Serviço fone@RNP
user = user
password = nopass
host = 10.10.10.10
144
database = openser
table = acc
Instalação do MediaProxy
O primeiro passo para instalação do software é a sua obtenção através do link:
http://download.ag-projects.com/MediaProxy/
Em seguida é necessária a extração do código através do comando:
# tar -xzvf mediaproxy-VERSAO.tar.gz
Depois, deve-se acessar o diretório, executando:
# cd mediaproxy-VERSAO
A seguir, deve-se executar o seguinte comando para compilação do código:
# ./setup.py build
Por fim, execute o seguinte comando para a instalação do software:
# ./setup.py install
145
Serviço fone@RNP
146
Atividade 7.1 – Configurações PostgreSQL, OpenLDAP e MediaProxy
responda as questões sobre a configuração do PostgreSQL.
a. Identifique os endereços IP liberados para acessar o banco de dados PostgreSQL:
b. Identifique o número de conexões simultâneas habilitadas no banco de dados:
c. Informe a única forma de acesso ao banco de dados sem o uso de senha:
d. Qual a porta configurada para acesso ao banco de dados?
Responda às questões sobre a configuração do OpenLDAP.
a. Identifique o Distingued Name (DN) para acesso do serviço em nível administrador:
b. Identifique o sufixo em uso no LDAP:
c. Identifique o domínio base do LDAP:
Responda às questões sobre a configuração do MediaProxy:
a. Observe no arquivo de configuração do MediaProxy o IP do proxy de mídia e o intervalo

de portas UDP utilizadas para repassar os pacotes RTP:
b. Com qual usuário Linux o MediaProxy está configurado para ser executado? Por que o
sistema necessita desta configuração?
147
Serviço fone@RNP
148
8
Introdução à telefonia
objetivos
Apresentar outros softwares que compõem o fone@RNP, programas auxiliares que

têm por função autenticar telefones IP, armazenar dados de usuários e das chamadas
realizadas e manter a sincronia de informação entre os servidores.
conceitos
LDAP, RADIUS, PostgreSQL, Slony, MediaProxy, sistema de telefonia ponto a ponto
e de telefonia hierárquica.
Assim como diversas áreas da ciência moderna, a telefonia teve como impulso a descoberta
da eletricidade e do magnetismo em 1830, por Michael Faraday. A primeira invenção após
esse impulso foi a do telégrafo elétrico, criado por Samuel Morse em 1837, que permitiu a
comunicação entre dois pontos ligados por uma fiação condutora.
A invenção do telefone é um tópico de grande discussão, já que três cientistas se apresentam na

história como seus inventores. Inicialmente, o italiano Antonio Meucci, em 1851, construiu um
telefone eletromagnético chamado de “telettrofono” para conectar seu escritório ao seu quarto,
localizado no andar de cima, para se comunicar com sua mulher, que sofria de reumatismo.
Passando por dificuldades financeiras, Meucci não pôde dar continuidade à sua invenção e a
vendeu para Alexander Graham Bell, que utilizou a descoberta de Meucci para dar continui-
dade às 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 requi-
sição chegou horas antes da de outro inventor, Elisha Gray.
Com a patente obtida, Bell pôde trabalhar pacificamente 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,
Capítulo 8 - Introdução à telefonia
sendo um deles ativo – gerando pulso elétrico – e outro passivo, não gerando pulso elétrico.
Usando essa arquitetura, a telefonia expandiu-se de forma desorganizada, já que locais

detinham mais de um telefone para que fosse possível se comunicar com localidades
diferentes, observando que cada telefone se comunicava com apenas uma localidade. Bell
identificou também esse problema e planejou uma comunicação hierárquica de telefonia,
implantando centrais de telefonia nas cidades e definindo todos os telefones instalados
como assinantes dessa central.
149
Os assinantes eram interligados às centrais e a partir delas poderiam se comunicar com
qualquer outro assinante. Esse sistema evoluiu até os dias de hoje, em que não há a neces-
sidade 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.
Distorções da telefonia
11 Limite da amplitude. q
11 Deslocamento da frequência.
11 Retardos no início do sistema.
11 Atraso na transmissão.
11 Eco.
11 Ruído.
Algumas características dos sistemas telefônicos levam à distorção do sinal de voz. Assim,
um projeto de sistema de telefonia digital necessita avaliar diversos aspectos da rede, dos
assinantes de origem ao destino. A seguir alguns dos problemas mais comuns encontrados:
11 Limite na amplitude: cortes dos níveis altos e baixos do sinal, interferindo na qualidade
da voz e afetando a inteligibilidade da fala.
11 Deslocamento da frequência: alteração da frequência recebida comparando com a

transmitida. Afeta o reconhecimento da voz e do interlocutor.
11 Retardos no início do sistema: resulta na perda da mensagem inicial do locutor, afe-

tando a inteligibilidade da comunicação.
11 Atraso da transmissão: ocorre quando o meio de transmissão gera atraso na recepção

da mensagem. Atrasos são inferidos por todos os meios; porém, meios como a trans-
missão via satélite geram atrasos superiores aos valores aceitos para que haja interativi-
dade, valor estabelecido em 200 ms.
11 Eco: são reflexões do sinal em pontos terminais da linha digital que provocam o retorno
da mensagem do locutor ao próprio locutor. Atrasos acima de 65 ms produzem ecos
perceptíveis.
11 Ruído: sinal aleatório que provoca sensação desagradável ao ouvido.
Tráfego e dimensionamento
11 Tráfego. q
11 Grau de Serviço (GoS).
11 Cálculo de canais e Tabelas de Erlang.
Como se sabe, 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.
Para aperfeiçoar o sistema é necessário calcular o número ideal de canais com a rede
Serviço fone@RNP
pública. A esse cálculo dá-se o nome de dimensionamento de canais. Para tanto, é neces-
sário conhecer três aspectos do sistema de telefonia: o tráfego, o grau de serviço e as
Tabelas de Erlang.
150
Tráfego
A correta caracterização do tráfego telefônico é essencial para o sucesso do sistema de tele-
fonia. A intensidade de tráfego em um sistema telefônico pode ser definida como o soma-
tó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 movi-
mentados. Esse período de 60 minutos cuja ocupação é máxima é conhecido como a Hora
de Maior Movimento (HMM).
Por exemplo, o escritório hipotético citado faz 15 chamadas de 2 minutos cada (em média)
durante sua HMM. Pode-se afirmar que o tráfego durante a hora mais movimentada do dia é:
A= (15 chamadas x 2 minutos) / 60 minutos ==> A = 0,5 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.
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%.
Cálculo 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 abaixo a título
de ilustração, mas que vamos poupá-los de decifrar:
A = Tráfego oferecido.
N = Número de canais para escoar o tráfego.
Pb = Probabilidade de bloqueio.
Em vez da longa explicação da fórmula, apresentamos as Tabelas de Erlang. Com elas é pos-
sível calcular o número de canais necessários para atender à demanda, considerando o GoS.
151
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
4 .235 .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.33 Tabela 8.1
10 2.26 2.47 2.61 2.80 3.09 3.43 3.65 3.82 3.96 Tabela de Erlang
(parcial).
A utilização da Tabela de Erlang é bem simples.

w
1. Localize a coluna correspondente ao grau de serviço desejado. No site www.erlang.
com, a tabela de Erlang
2. Nessa coluna, localize o valor imediatamente superior ao tráfego esperado. está completa. Existem
ainda algumas
3. Identifique o valor de N, que ocorre no início de cada linha. Esse é o valor desejado, que calculadoras disponí-
veis na internet. Essa é
significa o número de canais necessários para atender ao seu sistema.
a referência para uma
delas, disponibilizada
De acordo com o caso do exemplo acima, são necessários quatro canais com a rede pública
pelo site Teleco.
para atender a um tráfego de 0,5 Erl (equivalente a 15 chamadas de 2 minutos durante uma
hora), com um GoS de 0.3%.
Introdução a canais analógicos

11 Uso de fios metálicos. q
11 Tip.
11 Ring.
11 Loop fechado.
22 Telefone recebe o tom de discagem da central telefônica.
22 Sinalização do tipo loop-start.
22 Sinalização do tipo ground-start.
Sinalização utilizada na telefonia analógica

A maior parte das implementações de telefonia analógica usa um par de fios metálicos
(tip and ring). Quando um loop é fechado, o telefone recebe o tom de discagem da central
telefônica, seja ela pública (operadora) ou privada (PABX). Nos primeiros telefones, a dis-
cagem era feita por meio de um disco que gerava uma sequência de pulsos na linha telefô-
nica. Ao ocupar a linha, o laço (loop) era fechado e, ao efetuar a discagem, ocorriam aberturas
periódicas desse laço, tantas vezes quanto o número discado. Dizemos que esse tipo de sina-
Serviço fone@RNP
lização é do tipo loop start. Existem outras sinalizações menos comuns, como ground start.
11 Loop start: técnica para sinalização de chamada telefônica usada por praticamente
todas as linhas analógicas.
11 Ground start: técnica de sinalização de telefonia utilizada geralmente em linhas telefô-

nicas conectadas a um PABX.
152
Existem basicamente três tipos de sinalização: q
11 Sinalização de supervisão.
22 On-hook (no gancho).
22 Off-hook (fora do gancho).
11 Ringing (tocando).
11 Sinalização de endereçamento.
11 Sinalização de informação.
De forma muito resumida pode-se dizer que:
11 Sinalização de supervisão: indica se o telefone está no gancho (o-hook), fora do gancho

(of-hook) ou tocando (ringing).
11 Sinalização de endereçamento: indica os números que foram marcados pelo usuário.
11 Sinalização de informação: indica se o telefone chamado está ocupado, se o número

marcado está errado etc. Podemos destacar os seguintes eventos:
22 Tom de discagem.
22 Sinal de ocupado.
22 Tom de retorno (ringback).
22 Congestionamento (congestion).
22 Número inválido.
22 Tom de confirmação.
Existem diferenças nas sinalizações dos tons de discagem, de ocupado e da campainha

(ringing), que variam de acordo com as regras adotadas por países e fabricantes.
On-hook (no gancho)
Estado IDLE
PBX Telefone
TIP
No gancho
RING
Figura 8.1
Circuito elétrico Bateria
equivalente ao
telefone no gancho. Detector de corrente
Quando o usuário deixa o telefone no gancho, o circuito elétrico é interrompido e não

permite que a corrente seja transmitida. Nesse caso, o circuito está em estado on-hook.
Quando o telefone está nessa posição, apenas a campainha (ringer) está ativa. A figura
ilustra a sinalização loop start. A sinalização ground start não é usada com frequência.
153
Off-hook (fora do gancho)
Estado IDLE
PBX Telefone
TIP
Corrente
elétrica
Fora do
RING gancho Figura 8.2
Circuito elétrico
Bateria
equivalente a
telefone fora do
Detector de corrente gancho.
O usuário que deseja fazer uma chamada telefônica deve passar para o estado off-hook,
retirando o telefone do gancho. Esse estado fecha o circuito elétrico, que indica ao PABX que
o usuário deseja fazer uma chamada telefônica. Após receber essa indicação, o PABX gera o
tom de discagem, indicando ao usuário que está pronto para receber o endereço de destino
(número do telefone).
No Asterisk é possível usar dois tipos de sinalização para a discagem: multifrequencial de

dois tons (DTMF) e pulsada, como nos antigos telefones de disco. DTMF é a sigla de Dual
Tone Multi Frequency, em referência aos tons das frequências utilizadas na “discagem” dos
telefones mais modernos. Nos primeiros telefones, quando o termo “discagem” foi origi-
nado e fazia sentido, o endereço de destino era informado por meio de um disco que gerava
uma sequência de pulsos na linha telefônica. Ao ocupar a linha, o laço (loop) era fechado e,
ao se efetuar a discagem, ocorriam aberturas periódicas desse laço, tantas vezes quanto o
número discado: para a discagem do 1, uma abertura; para a discagem do 2, duas aberturas,
e assim sucessivamente. O número 0 (zero) equivalia a dez aberturas no circuito. Com a evo-
lução, as centrais telefônicas modernas passaram a utilizar a sinalização multifrequencial,
uma combinação de tons para discagem.
A sinalização DTMF foi desenvolvida nos laboratórios Bell e é vulgarmente conhecida em

inglês como touch tones. Mais detalhes na recomendação ABNT 13083.
Dual Tone Multi Frequency (DTMF)

Teclado de discagem: q
11 Frequências altas e baixas.
11 Indica para a central o número discado.
1209 1336 1477 1633

697 1 2 3 A
770 4 5 6 B
Figura 8.3
Serviço fone@RNP
852 7 8 9 C Teclado DTMF

e frequências
941 * 0 # D associadas em
Hertz.
154
Os usuários que têm um teclado para discagem possuem, associado a cada botão, um
conjunto de frequências de tons altos e baixos. A combinação desses dois tons indica para a
central os dígitos selecionados. Esse mecanismo é conhecido como Dual Tone Multi Fre-
quency (DTMF).
Na Figura 8.3 são mostradas as frequências altas na linha superior e as baixas na coluna
mais à esquerda. No centro estão os números do teclado. Nos teclados dos telefones são
mostrados apenas os números de 1 a 0 e os caracteres * e #. Foi definida uma quarta
coluna, com letras de A a D. A frequência de 1.633 hertz correspondente aos algarismos A, B,
C e D, e é utilizada apenas internamente, entre equipamentos de teste e medida.
A sinalização de informação mostra o progresso da chamada e os diferentes eventos.

Os mais conhecidos são:
11 Tom de discagem: normalmente um tom contínuo, que indica que a linha está disponível.
11 Sinal de ocupado: tom intermitente, intercalado com 250 ms de silêncio, indica que o
destino está off-hook.
11 Congestionamento: semelhante ao tom de ocupado, indica falta de recurso na rede para

completar a chamada.
Outros sinais menos comuns:
11 Tom de retorno.
11 Número inválido.
11 Tom de confirmação.
As frequências e tempos também podem variar ligeiramente de acordo com o padrão adotado.
Os padrões podem ser configurados no Asterisk no arquivo /etc/asterisk/indications.conf.
Os padrões utilizados no Brasil estão descritos na prática Telebras para telefonia e podem
ser encontrados no site da Anatel.
11 Interfaces ForeigneXchange (FX). q

11 Interfaces analógicas.
11 O termo ForeigneXchange é aplicado para troncos.
11 Duas interfaces:
22 ForeigneXchange Office (FXO).
22 ForeigneXchange Station (FXS).
Interfaces ForeigneXchange (FX) são interfaces analógicas. O termo ForeigneXchange é apli-

cado para troncos, para o acesso à operadora de telefonia.
Resumo
11 Um canal da central da operadora é ligado em uma porta FXO (linha telefônica tradicional).
11 Um telefone analógico convencional é ligado em uma porta FXS.
11 Então, é possível ligar uma porta FXO em uma porta FXS, assim como é possível ligar um
telefone à linha da operadora.
11 Dito de outra forma, um telefone analógico possui uma porta FXO, e um tronco na opera-
dora telefônica é uma porta FXS.
155
Gateway de voz sobre IP
ForeigneXchange Office (FXO)
11 Interface utilizada para comunicação com Central Office ou PABX. q
11 Essas interfaces conectam um PABX a outro PABX ou à rede pública.
As interfaces FXO são normalmente utilizadas para ligação com a central da operadora
telefônica ou com a posição de ramal de um PABX comum. Essa porta espera receber o tom
de discagem ou de linha (dialtone) e a indicação de que está chamando o destino (ringing). A
porta FXO deve prover indicadores de chamadas em progresso.
FXO Tom de discagem
Figura 8.4
Porta FXO recebe
Companhia telefônica
tom de discagem.
É muito comum ligar, no lugar de um telefone, uma interface FXO de um gateway VoIP e
transportar a voz empacotada pela rede IP até outro gateway remoto, no qual o telefone é
conectado em uma interface FXS. Essa operação é conhecida como Off-Promises eXtension
(OPX) ou ramal remoto.
ForeigneXchange Station (FXS)

Linhas residenciais padrão, utilizadas para conectar dispositivos básicos: q
11 Telefones.
11 Modem.
11 Fax.
Elas devem:
11 Prover voltagem.
11 Gerar ringing.
11 Detectar off-hook.
11 Indicar chamadas em processo.
As interfaces ForeigneXchange Station (FXS) são as conhecidas linhas residenciais padrão.

Podem ser utilizadas para conectar dispositivos básicos como telefones, aparelhos de
modem e fax. Também é possível conectar uma porta FXO nessas linhas. As portas FXS
devem prover voltagem para acionar a campainha, ou seja, 88 V AC a 20 Hz. O sinal ringing
deve detectar o estado off-hook do telefone e indicar chamadas em progresso.
Sinalização nos troncos

11 Loop start. q
11 Ground start.
Serviço fone@RNP
11 Kewl start.
11 Outros (não serão abordados):
22 E&M Wink Start.
22 E&M Immediate Start.
22 E&M Delay Start.
156
Kewl start é o mesmo que loop start, exceto por ter inteligência maior e por isso maior
capacidade para detectar desconexões remotas. Dessa forma, recomenda-se a utilização da
sinalização kewl start com interfaces analógicas no Asterisk.
E&M é uma forma de sinalização de supervisão analógica utilizada entre PABXs. Também
pode ser utilizada em linhas digitais, em versões adaptadas para isso. Entretanto, a sinali-
zação E&M está obsoleta. Essa sinalização não será abordada no curso, pois placas E&M não
estão disponíveis para o Asterisk.
Loop start
11 Usado por praticamente todas as linhas analógicas. q
11 Permite ao telefone indicar os estados de:
22 On-hook.
22 Off-hook.
11 Indica ao switch os estados de:
22 Ring.
22 No ring.
11 É uma linha aberta.
11 Uma chamada entrante é sinalizada por 100 V ring voltage.
Usado por praticamente todas as linhas analógicas, é o sistema que você tem em casa.
Permite ao telefone indicar os estados on-hook/off-hook e indicar ao PABX o estado de ring.
Cada linha tem um par separado de fios, podendo ser utilizada tanto para fazer quanto para
receber chamadas.
Nessa sinalização, o switch da central fornece 48 volts a um dos fios da linha, mas o circuito
permanece aberto pelo telefone ou PABX do cliente, indicando a posição (on-hook). Quando
o telefone é retirado do gancho, o circuito é fechado, indicando a posição off-hook. Esse é o
sinal enviado para a interface da central para que ela forneça o tom de linha, de forma que o
usuário possa discar o número de destino.
No outro sentido, ao receber uma chamada entrante, a central sinaliza o telefone ou o PABX do
cliente utilizando uma tensão alternada (20 Hz) de 88 volts, conhecida como ringing voltage. Para
responder à chamada, o loop deve ser fechado, com a retirada do telefone do gancho.
Ground start
11 Semelhante ao loop start. q
11 No momento de fazer uma ligação, o loop não é fechado.
Sinalização semelhante ao loop start. Nesse caso, o switch da operadora permanece forne-
cendo -48 volts em um dos fios, mantendo o outro aberto. Quando uma ligação é iniciada, o
loop é fechado no lado do cliente e o circuito é aterrado (ground). Esse é o sinal para que a
interface da operadora feche o circuito e envie o tom de discar.
Kewl start
11 Monitora o que o outro lado está fazendo. q
11 Incorpora vantagens do loop start e do ground start.
157
Adiciona inteligência à habilidade dos circuitos em monitorar o estado do dispositivo
remoto. É a supervisão de desconexão. Desde que o kewl start incorporou as vantagens do
loop start e ground start, sendo superior a ambos, você provavelmente vai utilizá-lo. Kewl
start tornou-se, informalmente, o padrão para o uso com o Asterisk.
Introdução a canais digitais

11 Canais digitais. q
11 Entroncamentos E1 e T1.
11 Sinalizações ISDN e MFCR2.
Com a evolução tecnológica surgiram as linhas digitais, interfaces capazes de carregar

mais informação de modo mais confiável. Assim, quando a demanda por troncos de voz é
relativamente alta (mais que oito canais simultâneos), utilizar canais digitais é uma opção
mais vantajosa. Os canais digitais são amplamente usados por ampliar a comunicação das
centrais locais com as operadoras e por troca de informação para o estabelecimento de fun-
cionalidades aos assinantes. Canais digitais são requisitos para a criação de aplicações como
Discagem Direta Ramal (DDR), retorno de chamadas e outros.
Existem dois padrões de comunicação digital: o padrão europeu E1 e o padrão americano

T1. No Brasil, o padrão de canal digital é o tronco E1 em contrapartida ao T1. Esses padrões
de comunicação definem a forma de acesso ao meio.
Para a troca de mensagens entre os equipamentos conectados pelo canal digital, os proto-
colos de telefonia são responsáveis por essa troca de sinalização. Protocolos comuns para o
estabelecimento dessas comunicações são MFC-R2, ISDN e SS7.
No Brasil, a sinalização MFC-R2 no Brasil é a mais comum entregue pelas operadoras.

A sinalização SS7 não é suportada pelo serviço fone@RNP.
Entroncamento digital
T1: q
11 24 canais de 8 bits.
11 8.000 frames por segundo.
11 64 kbits/segundo por canal.
11 1,54 Mbps no tronco.
11 Um canal de sinalização e 23 de dados.
E1:
11 32 canais de 8 bits.
11 8.000 frames por segundo.
11 64 kbits/segundo por canal.

Serviço fone@RNP
11 2,048 Mbits/segundo no tronco.
11 Um canal de sincronismo, um canal de sinalização e 30 de dados.
158
A tecnologia utilizada nos enlaces digitais da telefonia divide o meio de transporte em fatias
de tempo, também conhecidas como time slots. Cada fatia é um canal de transmissão de
dados. Essa tecnologia é conhecida como Time Division Multiplexing (TDM) – Multiplexação
por Divisão do Tempo. No Brasil, assim como na Europa, a interface digital mais utilizada é
a E1, composta por 32 canais de 64 kbps, comumente chamada de canal ou link de 2 Mbps.
Nos Estados Unidos é utilizado o padrão T1, composto por 24 canais de 64 kbps.
125 μseg
TS
TS 16
0
Figura 8.5
Multiplexação por
Divisão de Tempo: Sinalização Dados
32 canais digitais. Sincronismo, alarmes e mensagens (futuro)
MFC/R2: q
11 Sinalização definida pela ITU-T.
11 Usada principalmente na América Latina e na Ásia.
11 Utiliza Channel Associated Signaling (CAS).
22 R2 Digital Brasil.
11 Possui variações específicas para cada país.
MFC/R2 é uma sinalização definida pela ITU (Q.421/Q.441), usada principalmente na América
Latina e na Ásia. Utiliza Sinalização por Canal Associado (CAS), onde uma associação entre
a sinalização de linha é realizada através do canal 16 e cada canal de voz, ou seja, a sinali-
zação de linha, ocorre no canal 16, enquanto a sinalização de registro ocorre no canal de voz,
definido no canal 16. O R2 possui variações específicas de acordo com o país, sendo a sinali-
zação de linha digital mais comum no Brasil, seguindo a Prática Telebras TB 210-110-703.
A Telebras estipulou que o protocolo digital padrão para comunicação dos PABX dos assi-
nantes com as operadoras deveria ser E&M pulsada, E&M contínua ou R2D/MFC-5C. O pro-
tocolo R2 é o mais utilizado e, juntamente com a interface E1, pode endereçar até 30 canais
de voz; já as sinalizações E&M caíram em desuso. Junto com o protocolo de sinalização de
linha, é utilizada a sinalização de registro multifrequencial compelida, que significa que cada
sinal só pode ser enviado após a resposta do sinal anterior ter sido recebida. O Brasil utiliza
os tipos de sinalização de registro MFC 5C terrestre (compelida), e MFC 5S (não compelida),
embora mantenha a sigla MFC.
Integrated Services Digital Network (ISDN) apresenta: q

11 Vantagens sobre R2.
11 Uso flexível possibilitando uso simultâneo de dados de voz.
11 Interface E1 com possibilidade de 30 canais de voz, conhecida como 30B+D.
11 Interface T1 com 23 canais de voz + um de dados.
O protocolo para telefonia digital Rede Digital de Serviços Integrados (RDSI), do inglês Inte-
grated Services Digital Network (ISDN), possui algumas vantagens sobre o R2. As principais
são sua maior rapidez e o fato de prover um serviço flexível, possibilitando inclusive uso
simultâneo de dados e voz. O ISDN utilizado com interfaces E1 é conhecido como Primary
Rate Interface (PRI) e tem capacidade para endereçar 30 canais de voz, mais um canal para
159
controle das ligações, ou seja, para sinalização. Também é conhecido como 30B+D. Nos
Estados Unidos, utilizado com o padrão T1, tem sua capacidade reduzida para 23 canais de
voz e um para sinalização.
Hardware e interfaces para Asterisk

Tecnologias suportadas: q
11 O Asterisk foi desenvolvido para permitir a adição de novas tecnologias e interfaces
com facilidade.
11 Seu objetivo é suportar todo tipo possível de tecnologia de telefonia.
O Asterisk é desenvolvido para permitir que novas interfaces e tecnologias sejam agregadas
facilmente. Essa meta visa suportar qualquer tipo de tecnologia telefônica possível. A lista
dos últimos protocolos e hardwares compatíveis pode ser encontrada em http://www.
digium.com ou em http://www.asterisk.org.
Zaptel Pseudo TDM interfaces proveem integração com interfaces telefônicas analógicas e
digitais, tradicionais e legadas, incluindo conexão ao sistema de telefonia pública.
Time Division Multiplexing (TDM) – ou Multiplexação por Divisão do Tempo – em telefonia sig-
nifica que o canal digital utilizado para transporte da voz é separado em fatias de tempo (Time
Slots – TS). Em cada fatia, segue um canal de voz. O termo TDM acabou ganhando um novo
sentido entre os usuários do Asterisk, designando também os canais analógicos da telefonia
tradicional, como as interfaces ForeingeXchange Station (FXS) e ForeingeXchange Office (FXO).
Essas interfaces também são conhecidas como Public Old Telephony System (POTS). O sistema
de telefonia que compreende as duas tecnologias (analógica e digital) é conhecido como Public
Switched Telephony Network (PSTN), a Rede de Telefonia Pública Comutada.
As interfaces não Zaptel proveem conectividade a outros tipos de interfaces. Essas inter-
faces dão acesso a outros dispositivos, como a placa de som do computador, interfaces BRI
(ISDN), JACK ou outras placas de telefonia não baseadas na tecnologia Zaptel.
TDM400P é uma placa base de quatro entradas que permite a inserção de até quatro
cartões irmãos, que admitem portas FXO (módulo vermelho) e FXS (módulo verde), sendo os
módulos FXO e FXS intercambiáveis para a criação de várias combinações de interface.
Figura 8.6
Zaptel: TDM400P.
Serviço fone@RNP
160
Atualmente existem outras placas para telefonia analógica que possibilitam uma série de
combinações de interfaces FXSs (para ligação de ramais analógicos comuns) e FXOs para
ligação de uma linha telefônica comum. Para mais informações, visite o site da Digium.
Outros fabricantes produzem interfaces de telefonia suportadas pelo Asterisk; porém, esses
equipamentos ainda não são suportados pelo fone@RNP. Fabricantes como Sangoma e os
nacionais Khomp e DigiVoice possuem placas e soluções com densidades diferentes. Também
possuem placas com Digital Signal Processor (DSP), provendo integração dos codecs mais
utilizados e assim aliviando consideravelmente a carga de processamento no servidor.
Protocolos de Linhas
telefonia IP digitais
SIP E1
Interface de rede
(Ethernet)
IAX2 Placas de comunicação T1
MGCP BRI
Figura 8.7 H323 ...

Interconexão de
protocolos VoIP PC / Servidor
e sinalização
de telefonia
convencional. Linhas analógicas
A figura anterior mostra um esquema conceitual do Asterisk utilizando uma placa de rede
(Ethernet) para sua comunicação com a rede IP, uma placa digital e uma analógica para
comunicação com a rede de telefonia. Nesse exemplo, o Asterisk pode funcionar como um
gateway entre as redes de telefonia IP e a tradicional (TDM).
Conexões entre a interface VoIP e a telefonia convencional

11 Conexões FXO. q
11 Conexões E1.
Conexões FXO
Comumente utilizada, a conexão FXO ou FXS deve ser realizada por um par metálico, uti-
lizando conectores RJ11 na placa TDM de quatro ou oito portas. As vias ativas são os dois
pinos centrais do conector. Algumas placas de telefonia com maior densidade de portas FXO
ou FXS podem utilizar conectores do tipo Telco, de 25 pares.
161
Figura 8.8
Conector Telco,
com 25 pares.
Conexões E1
Diferentemente do que é observado, as placas VoIP E1 não utilizam conexões RJ45, pois o
familiarizado RJ45 utiliza os pinos 1, 2, 3 e 6 para receber e transmitir dados, enquanto o
RJ48, em comunicações E1, utiliza os pinos 1, 2, 4 e 5. Ambos, RJ48 e RJ45, usam o plug 8P8C
modular e dois pares de fios, um par para transmissão e um par para receber dados.
RJ-48 Plug
1 2 3 4 5 6 7 8
1 1
2 2
3 3
4 4
5 5
6 6
7 7
Figura 8.9
8 8 Pinagem RJ48.
Configurações preliminares à instalação da placa

q
Serviço fone@RNP
11 Identificação das placas.
11 Identificação e testes das linhas para canais FXO.
11 Identificação e testes das linhas para canais E1.
11 Validar o reconhecimento da placa no servidor Linux.
162
Identificação das placas
Antes de instalar e configurar a interface, deveremos inicialmente identificar que tipo de
placa VoIP é usada para cada tipo de comunicação. Atualmente existem diversos fabri-
cantes que desenvolvem interfaces VoIP, como Digium, Digivoice, Khomp ou Sangoma.
O único fabricante suportado nativamente pelo serviço fone@RNP são as interfaces da
Digium. As outras interfaces necessitam de modificações no serviço não padronizadas
pelo fone@RNP e de responsabilidade da instituição usuária.
Conforme apresentado, a placa padrão para comunicação FXO é a placa Digium TDM400P
com barramento PCI, de interface modular com a possibilidade de ter até quatro canais FXO
ou FXS. Para barramento PCI-e, a Digium lançou a placa AEX400P, também modular, com
suporte para até quatro ramais.
Para comunicação digital E1, o padrão do serviço é a placa TE110P, com apenas uma porta E1
e barramento PCI. Atualmente, essa placa não é mais fabricada na TE121, para barramento
PCI-e, e TE122, para barramento PCI.
Identificação e testes das linhas para canais FXO

A interface FXO, conforme já definido, é uma interface analógica passiva da mesma forma que
o aparelho de telefone convencional. Sendo assim, serão conectadas à interface FXO quatro
linhas analógicas. Mas antes de configurar as linhas, o administrador da instituição deverá
responder à seguinte questão: será disponibilizado acesso ao IVR a partir da rede pública?
Disponibilizar acesso a partir da rede pública é ter um número de Discagem Direta a Ramal
(DDR) que acesse o IVR, porém, conforme norma da Anatel, essa linha será bloqueada para
realizar chamada para a rede pública, disponibilizando acesso apenas a números do serviço
fone@RNP.
Caso não queira ter acesso ao IVR a partir da rede pública, configure os quatro ramais da
central telefônica (PBX) da seguinte forma:
1. Os quatro ramais serão ramais privados, ou seja, sem DDR.
2. Configure o roteamento entre os quatro ramais de forma que, caso dê ocupado no ramal,
a central encaminhe a chamada para o próximo ramal.
3. Habilite esses ramais para realizarem ligações para números fixos da própria cidade.
4. Identifique o dígito para obtenção da rota para a realização de ligações para números fixos.
Caso queira ter acesso ao IVR a partir da rede pública, configure os quatro ramais da central
telefônica (PBX) da seguinte forma:
1. Três ramais serão ramais privados, ou seja, sem DDR.

2. Apenas um ramal será público, ou seja, com DDR.
3. Configure o roteamento entre os três ramais privados de forma que, caso dê ocupado no
ramal, a central encaminhe a chamada para o próximo ramal.
4. Habilite os quatro ramais a realizarem ligações para números fixos da própria cidade.
5. Identifique qual é o dígito para obtenção da rota para a realização de ligações para
números fixos.
163
Para finalizar os testes dessas linhas, utilize um telefone convencional e teste cada um
desses ramais. Ao confirmar a correta configuração das linhas de telefones, instale a placa
no servidor onde serão instalados os serviços da máquina 2. Obviamente, não deixe de
tomar alguns cuidados que devem ser realizados antes de manusear itens de hardware. É
de suma importância descarregar a energia eletrostática de seu corpo. Salienta-se também
que, mesmo estando seguro quanto ao manuseio, nunca é recomendável que toque nos
contatos metálicos das placas.
Identificação e testes das linhas para canais E1

A interface E1 depende apenas da conexão no padrão G.703 entre o equipamento VoIP e a
outra ponta, que pode ser a central ou a operadora. O padrão G.703 permite a transmissão
em meios não balanceados – cabos coaxiais RX / TX – ou balanceados – cabos par trançados.
Grande dúvida dos administradores das instituições usuárias: que tipo de cabeamento deve
existir no padrão G.703 para par trançado?
Esse cabo par trançado pode ser o padrão de última milha – não ultrapassando assim dez
metros – e seguindo a combinação de 1 – 5, 2 – 4, 3 – 3, 4 – 1, 5 – 2, 6 – 6 , 7 – 7 e 8 – 8. As
placas E1 mais recentes da Digium são oferecidas com um dispositivo de loop da conexão do
par trançado para identificar alguma falha no cabeamento.
A forma de configuração do canal E1 no PBX não é a mesma do PBX com a operadora. O PBX
deverá permitir uma rota de comunicação das chamadas originadas no entroncamento do
VoIP com o PBX para a operadora – rota comumente é a 0.
O técnico da central deverá configurar uma rota de acesso aos ramais do PBX para alcançar
o tronco VoIP. Essa rota deverá permitir ligações de 4 a 20 dígitos. Caso o administrador da
instituição deseje disponibilizar o acesso ao IVR a partir da rede pública, o técnico da central
deverá configurar um número do DDR que seja redirecionado ao tronco VoIP.
Validar o reconhecimento da placa no servidor Linux

Ao inicializar o computador novamente, verifique se a máquina foi devidamente identificada
pelo servidor Linux. Para isso, utilize a ferramenta lspci, que apresentará todos os disposi-
tivos reconhecidos pelo servidor:
root@maq2:~# lspci
Entre outros dispositivos, deve ser mostrado um conforme a linha a seguir:
“0000:02:0c.0 Communication controller: Tiger Jet Network Inc.

Tiger3XX Modem/ISDN interface”
Configuração da interface FXO

Configuração do driver Zaptel para interface FXO: q
11 Validar se o driver está carregado.
11 Editar o arquivo de configuração.

Serviço fone@RNP
11 Carregar arquivo de configuração.
11 Identificar o status do tronco.
164
Configuração do Canal Zapata: q
11 Identificar o status do canal.
Configuração do driver Zaptel para interface FXO
Após a correta configuração preliminar da interface, o próximo passo é a configuração do

driver Zaptel. Esse driver faz a comunicação do serviço Asterisk com a interface. A configu-
ração do driver é definida no arquivo /etc/zaptel.conf.
Arquivo padrão do Driver Zaptel para interface FXO
# Arquivo padrão do ZAPTEL para interface FXO c/ 4 ramais
# /etc/zaptel.conf
# Padrão Fone@RNP – versão 2007
fxsks=1-4
loadzone=us
defaultzone=us
Carregar arquivo de configuração
Para carregar o driver do Asterisk com o novo arquivo de configuração, o administrador

deverá executar a ferramenta ztcfg:
root@maq2:~# ztcfg -vvvd
Identificar o status do driver
Para identificar o status do driver e da conexão na interface, o administrador deverá exe-

cutar a ferramenta ztscan.
root@maq2:~# ztscan
Configuração do canal Zapata no Asterisk

Concluindo as configurações básicas do driver para assim obter o acesso às interfaces FXO,
o serviço depende da configuração do canal Zapata do Asterisk. Esse canal é responsável
por comunicar o Asterisk com o driver e assim com a interface. A figura a seguir ilustra a
hierarquia top-down que detalha a comunicação do Asterisk com a interface FXO.
Asterisk
Canal Zapata (chan_zap.so)
Driver Zaptel
Figura 8.10
Hierarquia da Driver da Placa (wctdm)
comunicação do
Asterisk com a Interface VoIP
interface FXO.
165
Arquivo padrão do Canal Zapata para interface FXO
; Arquivo padrão do Canal Zapata para int FXO c/ 4 ramais
; /etc/asterisk/zapata.conf
; Padrão Fone@RNP – versão 2007
[trunkgroups]
[channels]
;# Canais com inclusao de 1 # canais externos
context=from-pstn
signalling=fxs_ks
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
busydetect=yes
busycount=6
callerid=25983000
group => 1
channel => 4
jbenable=yes
;# Canais sem inclusao de 1 # canais internos
context=from-pabx
signalling=fxs_ks
echocancel=yes
rxgain=0.0
txgain=0.0
busydetect=yes
Serviço fone@RNP
busycount=6
group => 1
callerid=25983000
channel => 1-4
166
loadzone=us
defaultzone=us
A forma mais segura de carregar a configuração do Asterisk é reiniciando o processo em

execução. O administrador possui o script padrão de inicialização do Asterisk na máquina 2
para que possa executar o seguinte comando:
root@maq2:~# /etc/init.d/asterisk restart
Identificar o status do canal Zapata no Asterisk
O console do Asterisk permite a execução de comandos que apresentem o status do serviço.

Para validar a configuração do canal Zapata e identificar o status do canal, o administrador
deverá executar o seguinte comando:
root@maq2:~# asterisk –vvvvr
maq2*CLI>zap show channels
Configuração da interface E1/ISDN

Configuração do driver Zaptel para interface E1/ISDN: q
Configuração do Canal Zapata:
Configuração do driver Zaptel para interface E1/ISDN

Arquivo padrão do driver Zaptel para interface ISDN
# Arquivo padrão do ZAPTEL para interface E1 / ISDN
# /etc/zaptel.conf
span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
dchan=16
loadzone = us
defaultzone = us
167


cutar a ferramenta ztscan:
root@maq2:~# ztscan
Configuração do canal Zapata no Asterisk

Concluindo as configurações básicas do driver para assim obter o acesso à interface E1/ISDN,
o serviço depende da configuração do canal Zapata do Asterisk. Esse canal é responsável por
comunicar o Asterisk com o driver e assim com a interface. A figura a seguir detalha de modo
top-down essa hierarquia na comunicação do Asterisk com a interface E1/ISDN.
Asterisk
Canal Zapata (chan_zap.so)
Lib PRI
Driver Zaptel
Driver da Placa (wcte11xp) Figura 8.11

Hierarquia da
comunicação do
Interface VoIP
Asterisk com a
interface E1/ISDN.
Arquivo padrão do Canal Zapata para interface E1/ISDN
; Arquivo padrão do Canal Zapata para int E1 / ISDN
; /etc/asterisk/zapata.conf
; Padrão Fone@RNP – versão 2007
[trunkgroups]
[channels]
context=default
switchtype=qsig
Serviço fone@RNP
signalling=pri_cpe
usecallerid=yes
group=1
168
context=> from-pabx
channel=> 1-15,17-31
jbenable=yes
loadzone=us
defaultzone=us

Identificar o status do canal Zapata no Asterisk

Para validar a configuração do canal Zapata e identificar o status do canal, o administrador
maq2*CLI>zap show channels
Configuração da interface E1/MFC-R2

Configuração do driver Zaptel para interface E1/MFC-R2: q
11 Carregar o arquivo de configuração.
Configuração do Canal Unicall:
11 Carregar o arquivo de configuração.
Configuração do driver Zaptel para interface E1/MFC-R2

Arquivo padrão do driver Zaptel para interface ISDN
# Arquivo padrão do ZAPTEL para interface E1 / MFC-R2
# /etc/zaptel.conf
span=1,1,0,cas,hdb3
169
cas=1-15:1001
cas=17-31:1001
loadzone = us
defaultzone = us


cutar a ferramenta ztscan:
root@maq2:~# ztscan
Configuração do canal Unicall no Asterisk

Concluindo as configurações básicas do driver para assim obter o acesso à interface E1/
MFC-R2, o serviço depende da configuração do canal Unicall do Asterisk. Esse canal foi
desenvolvido por terceiros e, no momento do lançamento do serviço fone@RNP na versão
2, era o único capaz de fazer a comunicação do Asterisk com o driver usando o protocolo
MFC-R2. A figura a seguir mostra um detalhamento top-down dessa hierarquia na comuni-
cação do Asterisk com a interface E1/MFC-R2.
Asterisk
Canal Unicall (chan_unicall.so)
Lib Unicall
Lib MFC-R2
Figura 8.12
Driver Zaptel Hierarquia da
comunicação
Driver da Placa (wcte11xp) do Asterisk com
a interface E1/
MFC-R2.
Interface VoIP
Arquivo padrão do Canal Unicall para interface MFC-R2
;Arquivo padrão do Canal Unicall para interface E1
;/etc/asterisk/unicall.conf
;Padrão Fone@RNP – versão 2007

Serviço fone@RNP
[channels]
context=from-pabx
usecallerid=yes
hidecallerid=no
170
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
protocolclass=mfcr2
protocolvariant=br,20,4
protocolend=cpe
channel => 1-15
channel => 17-31

Identificar o status do canal Unicall no Asterisk

Para validar a configuração do canal Unicall e identificar o status do canal, o administrador

maq2*CLI>UC show channels
171
Serviço fone@RNP
172
A integração do serviço VoIP com o serviço de telefonia convencional é realizada no serviço
fone@RNP, atualmente utilizando a comunicação analógica FXO ou a comunicação digital
através dos protocolos ISDN ou MFC-R2.

ative a comunicação do serviço de telefonia de sua instituição com o serviço VoIP e res-
ponda as questões abaixo.
Atividade 8.1 – Identifique o status da sua interface antes da ativação

Utilize os comandos ztscan e lspci para responder as seguintes perguntas:
1. Quantas interfaces estão instaladas no servidor?
2. Que tipo de comunicação a interface VoIP possui?
3. Identifique o status da interface.
Atividade 8.2 – Ative a comunicação do serviço de telefonia com o serviço VoIP

Identifique o tipo de comunicação que será estabelecida entre o serviço de telefonia e o
serviço VoIP. Execute as atividades baseadas na sua comunicação:
FXO
1. Certifique-se de que os cabos RJ11 estão devidamente conectados entre o PBX e a placa VoIP.
2. Obtenha com o técnico responsável pelo serviço de telefonia (no caso, o instrutor) as
seguintes questões:
a. Quais são os números dos ramais do PBX conectados ao Asterisk?
b. Qual o código chave para alcançar a linha externa do PBX?
c. Qual o número de IVR interno?
d. Qual o número de IVR externo?
3. Confira as configurações do Zaptel e do canal ZAP do Asterisk e veja se as informações

estão condizentes com as repassadas pelo técnico.
4. Caso não esteja, corrija os valores.
5. Recarregue o Zaptel na máquina 2 e informe o status do driver.
6. Recarregue o Asterisk na máquina 2 e informe o status do canal ZAP.
173
ISDN
1. Certifique-se de que os cabos RJ48 estão devidamente conectados entre o PBX e a placa VoIP.
2. Obtenha com o técnico responsável pelo serviço de telefonia as seguintes questões:
a. Qual é o dispositivo de telefonia na outra ponta que está gerando ou aguardando

sincronismo?
b. Identifique se a comunicação está usando CRC4.
c. Qual é o número de IVR interno?
d. Qual é o número de IVR externo?
3. Confira as configurações do Zaptel e do canal ZAP do Asterisk e veja se as informações

6. Recarregue o Asterisk na máquina 2 e informe o status do canal ZAP.
MFC-R2
1. Certifique-se de que os cabos RJ48 estão devidamente conectados entre o PBX e

a placa VoIP.
2. Obtenha com o técnico responsável pelo serviço de telefonia as seguintes questões:
a. Qual é o dispositivo de telefonia na outra ponta que está gerando ou aguardando

sincronismo?
b. Identifique a quantidade de dígitos do número de origem (ANI).
c. Identifique a quantidade de dígitos do número de destino (DNIS).
d. Qual é o número de IVR interno?
e. Qual é o número de IVR externo?
3. Confira as configurações do Zaptel e do canal Unicall no Asterisk e veja se as informações

6. Recarregue o Asterisk na máquina 2 e informe o status do canal Unicall.
Atividade 8.3 – Realização de testes

Seguindo o documento de homologação, deve-se agora realizar a seção 8 de testes de IVR
no serviço fone@RNP. Desconsidere as chamadas que utilizam o protocolo H.323.
Serviço fone@RNP
1. Realização de chamadas utilizando ramais VoIP.
2. Realização de chamadas utilizando ramais do PBX.
3. Realização de chamadas utilizando telefones do PSTN.
4. Identificação da consolidação das chamadas no serviço de estatística.

174
9
Serviços extras no fone@RNP
objetivos
Apresentar soluções agregadas ao fone@RNP, como a configuração de proxy

transparente, integração com outros sistemas de Voz sobre IP e a configuração
de solução contra ataques aos servidores do serviço.
conceitos
IAX2, proxy transparente e troncos SIP.
IAX2: Protocolo VoIP alternativo

11 InterAsterisk eXchange. q
11 RFC 5456.
11 Reduz overhead na rede.
11 Ilustrar problema do SIP e do H.323 com NAT e firewalls.
11 IAX2 é transparente a implementações de NAT.
Digium IAX é o acrônimo de InterAsterisk eXchange, protocolo desenvolvido pela Digium para o PABX
Empresa que lançou o IP Asterisk, também desenvolvido por essa empresa. O IAX se encontra na versão 2, por isso o
Asterisk, um PABX de
nome IAX2. Ele está descrito na RFC 5456 e sua última atualização data de fevereiro de 2009.
código aberto. Também
fabrica placas PCI para
IAX é capaz de multiplexar a sinalização e a mídia de vários fluxos de chamadas telefônicas
telefonia com interfaces
analógicas e digitais. sobre a mesma comunicação UDP entre dois computadores. Ele utiliza a porta UDP 4569
Na realidade, o Asterisk para todos os tipos de tráfego (controle das chamadas e transporte de mídia). Assim, reduz
funciona como uma
drasticamente o overhead do transporte da mídia e é transparente a implementações de
grande vitrine das
placas Digium. NAT, diferentemente de SIP e H.323.
Capítulo 9 - Serviços extras no fone@RNP
Como foi abordado, SIP e H.323 utilizam um canal para sinalização e, durante o estabeleci-
mento da chamada, negociam outros canais para o transporte de mídia, um em cada direção.
Isso faz aumentar consideravelmente a complexidade de firewalls e implementações de NAT,
podendo até em alguns casos inviabilizar a comunicação. Além disso, para transportar a
mídia, esses protocolos utilizam um cabeçalho IP/UDP/RTP para cada chamada, resultando em
um grande overhead no tráfego. O IAX não transporta a mídia sobre o protocolo RTP e pode
utilizar apenas um cabeçalho IP/UDP/IAX para todas as chamadas em curso.
IAX2 utiliza uma codificação binária que confere ao protocolo melhor utilização de banda.
Ele acrescenta 4 bytes de overhead para um fluxo de voz. Apenas o cabeçalho RTP possui
12 bytes. Sua forma de multiplexar as chamadas simultâneas é notadamente a principal
vantagem deste protocolo.
175
Para cada chamada SIP ou H.323 é necessário um cabeçalho RTP (12 bytes), UDP (8 bytes) e
IP (20 bytes). A soma destes cabeçalhos é igual a 40 bytes. O codec G.729 tem um payload de
20 bytes. Para aumentar a eficiência da comunicação, normalmente são transportados dois
Figura 9.1
payloads por pacote. Tem-se então um pacote de 40 bytes de cabeçalho mais 40 bytes de Modelo de
dados, para cada chamada simultânea, sem contar o cabeçalho de nível 2. transporte de mídia
em redes SIP ou
H.323.
IP UDP RTP PAYLOAD1 IP UDP RTP PAYLOAD2 IP UDP RTP PAYLOAD_N
Para N chamadas, tem-se N vezes 40 bytes de cabeçalho mais N vezes 40 bytes de carga,
tudo isso vezes 50 pacotes por segundo. Aproximadamente, essa conta chega ao consumo
de banda igual a N vezes a ocupação de uma chamada.
{ (N x 40 Bytes) + (N x 40 Bytes) } x8 bits x 50 pps = N x 80 x 8 x 50 = N x 32 kbps
Note que o cabeçalho aumenta na mesma velocidade que o payload.

Figura 9.2
Já o protocolo IAX acrescenta 4 bytes a cada chamada, mas em apenas um pacote, ou seja, Modelo de
apenas um cabeçalho IP e um UDP. transporte de mídia
em redes IAX2.
IP UDP IAX PAYLOAD1 PAYLOAD2 PAYLOAD_N
Para N chamadas tem-se 1 cabeçalho de 28 bytes (IP+UDP), mais N vezes 4 bytes, mais N
vezes 40 bytes do codec vezes 50 pacotes por segundo.
{(28bytes + Nx4bytes) + (N x 40bytes)} x8 bits x 50 pps = (28 +N x 44) x 8 x 50 =

(11,2 + N x 17,6) kbps ~= N x 32 x 0,55 kbps, quando N g ∞
Note que o cabeçalho aumenta 10 vezes mais devagar que o payload conforme o número
de chamadas aumenta. Assim, quanto maior o número de chamadas simultâneas, maior a
eficiência do protocolo, fazendo com que o consumo de banda se aproxime da metade do
que seria consumido se fosse utilizado SIP ou H.323.
Quanto mais ligações simultâneas, mais o consumo de banda com IAX2 se aproxima
da metade do consumo do SIP ou H.323.
Para exemplificar o cálculo anterior, um tronco SIP ou H.323 utilizando o codec G.729 com
30 chamadas simultâneas consumiria 960 kbps. Um tronco IAX utilizando o codec G.729 com
30 chamadas consumiria 539,2 kbps, apenas 12,33% além da metade do consumo do SIP. Em
relação ao consumo total, o IAX2 consome 56,16% da banda que o SIP consome.
Para 60 ligações simultâneas, a diferença do consumo cai para 55,58%, sendo o consumo do
SIP igual a 1.920 kbps e do IAX2 igual a 1.067,2 kbps. E a relação entre IAX2 e a metade do
consumo do SIP cai para 11,17%.
As contas anteriores são feitas desconsiderando o cabeçalho de nível 2, Ethernet ou Frame

Serviço fone@RNP
Relay. Essa característica permite que sejam estabelecidas mais chamadas por mbps
quando se utiliza o protocolo IAX. Enquanto o SIP ou H.323 consegue transportar aproxima-
damente 30 canais G.729 por Mbps, o IAX consegue transportar quase 60 canais por Mbps.
176
IAX2 em rede VoIP
11 Mais eficiente para muitas ligações. q
11 Transparente a implementações de NAT e firewall.
11 Capaz de processar mais chamadas simultâneas em relação ao SIP e H.323.
O IAX traz grandes vantagens para implementações de redes de telefonia onde há a neces-
sidade de interligar dois ou mais PABX através de enlaces de velocidade limitada. Ele otimiza
o consumo de banda utilizado nas ligações, podendo oferecer economia da ordem de 55%
em relação ao SIP ou H.323. Quando configurado para operar em modo tronco, o protocolo
utiliza apenas um cabeçalho para transportar dados de todas as ligações que estão ocor-
rendo naquele instante. Todos os outros protocolos de Voz sobre IP utilizam um cabeçalho
RTP (mais UDP e IP) para cada uma das ligações em curso.
Outra vantagem que pode ser aproveitada por tele-trabalhadores é a facilidade de operação
do IAX2 com implementações de NAT. O IAX2 é transparente à NAT e não sofre nenhum pro-
blema, diferentemente do SIP e do H.323. Além disso, o IAX implementa e transfere informa-
ções em forma de códigos, além de não enviar informações redundantes, não utilizadas nas
transações. Já o SIP, por exemplo, implementa a troca de mensagens utilizando texto plano e
repete muitas informações em seus diálogos.
Por que não considerar o IAX2 em uma rede VoIP?

Poucos fabricantes implementam soluções que suportem IAX2. Apenas o PABX da Digium,
o Asterisk, implementa este protocolo. Até o momento não há conhecimento de nenhum
grande fabricante que utilize o IAX em suas redes. Além disso, poucas empresas fabricam
dispositivos como Analog Telephone Adapter (ATA) de pequena densidade com este pro-
tocolo. Portanto, a verdadeira desvantagem do protocolo é a falta de produtos e equipa-
mentos que o utilizam.
Filtro transparente no fone@RNP

11 Ligações de longa distância são transportadas pelo fone@RNP. q
11 Entretanto, é necessário “entrar” na rede digitando para o ramal de acesso ao fone@RNP.
11 Caso fosse transparente, a economia poderia ser muito maior.
Conforme vimos, o serviço fone@RNP permite que instituições usuárias possam realizar
chamadas entre instituições usuárias ou externas ao serviço, quando a chamada se inicia
em uma instituição usuária para um telefone da rede pública de telefonia.
Essa característica do fone@RNP possibilita que as instituições usuárias substituam o custo

de chamadas de longa distância por chamadas locais, encaminhadas pela rede IP e termi-
nadas pela instituição na cidade de destino. Vale lembrar que o custo dessas chamadas
locais é coberto pela instituição na localidade de destino. Esta substituição só pode ser
realizada se a instituição usuária também completar chamadas em sua cidade. A entrega da
ligação para a rede pública na outra ponta (destino) é sempre transparente para o usuário,
pelo ponto de vista de que ele não sabe a instituição que está terminando a ligação na RTFC.
Resumidamente, quando a ligação é destinada para ramais dentro de outra instituição

usuária cliente do fone@RNP, não há custo para nenhuma das instituições envolvidas na
chamada. Quando a ligação termina na RTFC, o custo é absorvido pela instituição que
entregou a chamada na cidade destino. Entretanto, se a ligação é originada a partir de um
177
ramal convencional, é necessário “entrar” na rede do fone@RNP, digitando para o número
de acesso ao serviço. Caso o uso da rede do fone@RNP para transporte das chamadas à
distância fosse transparente, todos os usuários do sistema de telefonia seriam capazes de
economizar, e não apenas aqueles que conhecem e efetivamente usam o “ramal de entrada
no fone@RNP”.
Serviço fone@RNP e conexões com a operadora

11 Quando a ligação é destinada para ramais dentro de outra instituição usuária cliente q
do fone@RNP, não há custo para nenhuma das instituições envolvidas na chamada.
11 Quando a ligação termina na RTFC, o custo é absorvido pela instituição que entregou
a chamada na cidade destino.
11 Substitui o custo de uma chamada DDD pelo custo de uma chamada local.
O serviço fone@RNP integra cada instituição ao serviço de telefonia local, permitindo assim
a interação do ambiente VoIP com o ambiente de telefonia legado. Esta interação é a chave
principal da economia de recursos com o serviço de telefonia pelas instituições. Usufruindo
da rede de dados, as instituições usuárias devem encaminhar o tráfego de longa distância
ao serviço VoIP e esperar que a chamada seja completada pela integração do ambiente VoIP
com a telefonia legada da instituição usuária de mesma localidade do número destino; subs-
tituindo assim o custo de chamada de longa distância na instituição de origem por um custo
de chamada local na instituição destino.
Para utilizar este benefício, é necessário que os usuários de telefones convencionais das
instituições clientes acessem a rede de telefonia IP discando um ramal especial definido
quando da instalação do serviço. Os usuários de telefones IP do fone@RNP não precisam
discar esse ramal especial, pois já estão na rede VoIP. Dessa forma, é imprescindível que as
instituições clientes divulguem para seus funcionários e alunos este procedimento.
Porém, nem todos os clientes do fone@RNP escolhem terminar ligações na STFC. Além
disso, não há instituições em todas as cidades brasileiras, sendo impossível cobrir todas as
localidades do Brasil.
O serviço fone@RNP não completa chamadas para todas as localidades do terri-

tório nacional, apenas para onde existe uma instituição usuária participante que se
propõe a terminar as chamadas.
Para pensar
Estas duas características do serviço, a necessidade de divulgação interna e a cober-

tura limitada, são as principais forças que atuam contra a sua imagem. Elas resultam
em rejeição dos usuários finais, podendo gerar descrédito ao serviço, fazendo-os
preferir realizar as chamadas diretamente pela operadora ao invés de tentá-las pelo
serviço VoIP.
Serviço fone@RNP
Filtro Transparente
O Filtro Transparente completa as chamadas utilizando a rota de menor custo, sem que q
seja necessário discar o ramal de acesso (chamada em dois passos).
178
O conceito básico do serviço de Filtro Transparente é completar as chamadas recebidas
utilizando a rota de menor custo disponível, sem que seja necessário o usuário acessar o
sistema VoIP discando o ramal especial. Para isso, o servidor deverá receber todas as cha-
madas destinadas à operadora e identificar a melhor rota para completar a ligação.
Existem diversas formas de atribuir pesos (ou custos) às rotas para um número destino,
definindo assim a melhor rota. O uso mais comum é o custo em Real por minuto da ligação,
e assim será no fone@RNP. Outras formas avançadas consistem em adicionar ao custo em
Real por minuto variáveis de identificação da Qualidade de Serviço, disponibilidade e ocu-
pação das rotas.
11 Caso exista mais de uma rota com o mesmo custo, ambas as rotas devem ser utili-
zadas realizando chamadas em paralelo. A primeira rota que responder a solicitação de
chamada positivamente será utilizada pelo serviço, cancelando a chamada na outra rota.
11 Caso não haja resposta positiva, o Filtro Transparente tentará encaminhar a chamada
pela próxima rota de menor custo, obtendo assim o menor custo possível.
11 Caso não haja mais rotas para este número destino, o Filtro Transparente retornará uma
mensagem de falha para o usuário que originou a chamada.
Entroncamentos no Filtro Transparente

Para que todas as chamadas sejam tratadas pelo serviço de Filtro Transparente, o mesmo
deverá estar localizado entre o PBX e a operadora. Desta forma, o serviço de Filtro Trans-
parente passa a ter características de gateway de trânsito. O gateway de trânsito permite a
conexão de centrais e operadoras por canais digitais da telefonia tradicional ou por tecno-
logia VoIP e não possui assinantes (ramais) associados a eles.
Vantagens do Filtro Transparente

O Filtro transparente permite a redução significativa dos custos das chamadas de longa
distância, uma vez que os usuários do sistema de telefonia não precisam escolher a rota
do fone@RNP. AS tentativas de entregar as chamadas pela rede IP será feita automatica-
mente em todas as ligações. O gateway identificará as chamadas e as encaminhará pelo
serviço fone@RNP sempre que houver recurso disponível, mesmo sem que o usuário se
dê conta disso.
Outra característica do proxy transparente é a possibilidade de bilhetar as chamadas que

passam por ele. A bilhetagem do serviço consiste no armazenamento de dados relevantes
de cada chamada encaminhada pelo Filtro Transparente e a geração de relatórios desses
dados para avaliação posterior.
Desafios do Filtro Transparente

A implementação do filtro transparente faz com que o serviço de telefonia fique dependente
do gateway que desempenha essa função. O serviço de telefonia é crítico e não pode parar,
e a adoção do Filtro Transparente implica em conseguir a mesma disponibilidade atual com
mais um componente na rede.
É muito importante armazenar o equipamento do serviço em locais apropriados, com for-

necimento de energia adequado e sistema de no-break. Também é altamente aconselhável
manter uma equipe que possa prover assistência técnica ao servidor e suas configurações.
A configuração do filtro transparente no fone@RNP será apresentada nas atividades práticas

deste capítulo.
179
Entroncamento SIP com operadoras e outros PABX IP
11 Vantagens do entroncamento SIP sobre o entroncamento convencional E1. q
11 Formas de comunicação VoIP: SIP x IAX.
11 Modo de entroncamento: Proxy SIP ou Gateway VoIP.
Para expandir o uso do serviço VoIP na instituição usuária, o serviço local do fone@RNP
espera ser entroncado a outros equipamentos de telefonia da instituição. Estes equipa-
mentos permitem o aproveitamento da telefonia legada e o uso inteligente do serviço.
Formas de entroncamento convencionais já foram apresentadas, como o uso de linhas

analógicas ou digitais da telefonia convencional. Este capítulo apresenta formas de realizar
entroncamentos através de protocolos VoIP, fazendo um uso racional do serviço.
Vantagens do entroncamento SIP sobre o convencional E1

Entroncamentos convencionais E1 são serviços limitados pela forma de acesso ao meio
que permitem um número máximo de 30 chamadas. Estes entroncamentos necessitam de
equipamentos específicos nos equipamentos envolvidos, e de conexões apropriadas entre
os equipamentos e conversores, requisitos que encarecem o uso destas conexões.
Contrapondo estes requisitos, o entroncamento SIP não depende de conexões E1 e circuitos

de entroncamentos caros. O serviço é baseado na comunicação IP já existente entre os
equipamentos, de configuração simples. De forma que este circuito não depende de investi-
mentos – mediante que ambos os circuitos possuam entroncamento SIP.
No entroncamento SIP, não há uma limitação específica no número de chamadas. O serviço

permite que seja trafegado o número de chamadas permitido no enlace entre os equipa-
mentos. Uma chamada VoIP usando o codec básico G711 e o protocolo SIP demanda normal-
mente 128Kbits por segundo de banda. Assim, um enlace já sobrecarregado terá o número
de chamadas simultâneas limitado pela banda. Porém, num enlace fastEthernet ocioso, o
número de chamadas será muito maior que o permitido num link E1.
Formas de entroncamento VoIP: SIP x IAX

Conforme apresentado neste capítulo, IAX é um protocolo recente que possibilita um
entroncamento diferenciado entre os dispositivos VoIP. Utilizando o IAX, o serviço VoIP
reduz o consumo de banda entre troncos e interopera recursos de forma mais simples –
mesmo usando NAT. Porém, poucos equipamentos hoje possuem a tecnologia IAX dispo-
nível, o que impossibilita uma maior adoção deste protocolo.
Contudo, o protocolo SIP está amplamente utilizado no mercado pelos provedores VoIP
e centrais telefônicas (PABX Convencional). Portanto, caso o entroncamento esteja sendo
gerenciado pelo técnico e seja feito entre dois ou mais Asterisks, considere a possibilidade
de utilizar o IAX. Porém, caso não seja entre dois Asterisks, implante o entroncamento SIP
entre os dispositivos.
Serviço fone@RNP
Modos de entroncamento: Proxy SIP x Gateway VoIP

É possível realizar a configuração do equipamento SIP em dois dispositivos do serviço local: (i) o
Proxy SIP Openser na máquina 1 ou (ii) o Gateway VoIP Asterisk na máquina 2. Caso deseje rea-
lizar o entroncamento no Proxy SIP OpenSER, o técnico poderá realizar apenas entroncamentos
SIP e realizará diversas configurações de roteamento no OpenSER para que permita a integração.
180
Estas mudanças poderiam atrapalhar o sistema de roteamento das chamadas feitas
de forma dinâmica no OpenSER; consequentemente esta opção não é recomendada.
No segundo modo, o Gateway VoIP Asterisk da máquina 2 é utilizado para entroncar os

equipamentos. Diferentemente do Proxy SIP OpenSER, o Asterisk permite o uso dos proto-
colos SIP e IAX e as configurações de roteamento são mais simples e fáceis de realizar. Desta
forma, o técnico poderia realizar as alterações no plano de discagem sem causar trans-
tornos ao serviço.
181
Serviço fone@RNP
182
Atividade 9.1 - Entroncando fone com PABX SIP
O objetivo da prática de entroncamento SIP é possibilitar que o administrador do serviço
implante comunicação SIP do serviço fone@RNP para outros equipamentos de terceiros ao
serviço. Este tipo de entroncamento permite a integração de dispositivos como:
11 PBX IP;
11 PBX convencional com suporte SIP;
11 Operadoras VoIP.
Nesta etapa, utilizando o PBX IP do instrutor, o grupo deverá realizar os seguintes passos:
11 Obter informações básicas de entroncamento com o instrutor;
11 Configurar o tronco SIP no canal SIP do Asterisk (máquina 2);
11 Configurar o plano de discagem para encaminhar chamadas ao peer;
11 Configurar o plano de discagem para receber chamadas do peer;
11 Realizar testes para validar o entroncamento.
Informações básicas para entroncamento SIP

Nesta etapa, junto com o técnico do outro dispositivo, identifique:
11 O endereço IP do equipamento.
11 O protocolo de transporte: UDP ou TCP?
11 A porta do equipamento.
11 Os codecs aceitos na comunicação.
11 O modo de autenticação: por IP ou usuário e senha?
11 O plano de discagem aceito pelo equipamento.
11 O plano de discagem a ser repassado pelo equipamento.
Configurações do entroncamento SIP no canal SIP

Para configurar o entroncamento SIP no Asterisk da máquina 2, o técnico deve editar o
arquivo /etc/asterisk/sip.conf e adicionar as seguintes informações do entroncamento no final
do arquivo:
[peerPBXIP]
Host=<IP_PBXIP>
Port=<PORTA_PBXIP>
Disallow=all
Allow=ulaw
Allow=alaw
Context=from-pbxip
183
Ao finalizar a edição do arquivo, o técnico deverá reiniciar o processo do Asterisk usando o
seguinte comando:
/etc/init.d/asterisk restart
Configurar plano de discagem para encaminhar

Para configurar plano de discagem para o encaminhamento de chamadas para o outro PBX
IP, edite o arquivo do plano de discagem /etc/asterisk/extensions.conf e adicione o seguinte
contexto de chamadas:
[to-pbxip]
Exten => _7XXX,1,Noop(“Chamadas para pbxip”)
Exten => _7XXX,n,Dial(SIP/4004${EXTEN}@peerPBXIP,60,rtT)
Exten => _7XXX,n,Hangup()
Após a criação deste contexto, inclua no contexto “from-voip” a chamada para o contexto
“to-pbxip”. Para criar esta chamada, insira a seguinte regra:
include => to-pbxip
Ao finalizar a edição do arquivo, recarregue o plano de discagem no Asterisk. Para isso,

carregue o console do Asterisk com o comando asterisk -vvvvr e dentro do console execute o
comando dialplan reload.
Configurar plano de discagem para receber

Para configurar o plano de discagem para receber chamadas do PBX IP, edite o arquivo do
plano de discagem /etc/asterisk/extensions.conf e adicione o seguinte contexto de chamadas:
[from-pbxip]
include => ip
Ao finalizar a edição do arquivo, recarregue o plano de discagem no Asterisk. Para realizar

esta tarefa, carregue o console do Asterisk usando o comando asterisk -vvvvr. Dentro do
console do Asterisk execute o comando dialplan reload.
Testes para validar entroncamento

Para validar que o entroncamento foi realizado com sucesso, acesse o console do Asterisk com
o comando asterisk –vvvr. Dentro do console do Asterisk, execute o comando sip show peers
e identifique o status do entroncamento SIP. Com o serviço entroncado com sucesso, realize
testes de chamadas entre os usuários VoIP do serviço local com os usuários VoIP do PBX IP.
Atividade 9.2 - Configurando o Filtro Transparente

O objetivo da prática de filtro transparente é criar a documentação básica necessária para
que o administrador do serviço implante o serviço de Filtro Transparente na sua instituição.
Serviço fone@RNP
Nesta atividade, o gateway de Filtro Transparente estará conectado ao PBX, à operadora

de telefonia fixa e ao serviço VoIP fone@RNP local. Neste cenário é identificado apenas um
tronco E1 entre a operadora e o PBX. Caso existam outros, redimensione a comunicação do
serviço.
Nesta etapa, será realizada apenas a configuração do Filtro Transparente, pois não temos
184
uma terceira máquina requerida pelo serviço. Assim, para a configuração de teste do
serviço, realize as seguintes ações:
11 Obter informações básicas de entroncamento com o instrutor;
11 Configurar o tronco SIP no canal SIP do Asterisk (máquina 2);
11 Configurar o tronco SIP no canal SIP do Asterisk (máquina do Filtro Transparente);
11 Configure a interface E1 de comunicação do Asterisk com a operadora (máquina do

Filtro Transparente);
11 Configure a interface E1 de comunicação do Asterisk com o PBX (máquina do Filtro

Transparente);
11 Alteração do plano de discagem no Asterisk para encaminhamento das chamadas para o

Filtro Transparente (máquina 2);
11 Configure o plano de discagem para receber chamadas da operadora (máquina do

11 Configure o plano de discagem para receber chamadas do PBX (máquina do Filtro

Transparente);
11 Configure o plano de discagem para receber chamadas do serviço VoIP (máquina do

11 Configure o plano de discagem para encaminhar chamadas (máquina do Filtro

Transparente);
11 Realize testes para validar o entroncamento.
Informações básicas para entroncamento SIP

Nesta etapa, identifique junto com o técnico da telefonia as informações de entroncamento
E1 do PABX e da operadora. Importante também identificar os endereços IP da máquina 2 e
do servidor que está rodando o Filtro Transparente. As informações neste item, quanto aos
entroncamentos, são similares às informações obtidas no Capítulo 8.
Configurações do entroncamento SIP no canal SIP (máquina 2)

Para configurar o entroncamento SIP no Asterisk da máquina 2, o técnico deve editar o
arquivo /etc/asterisk/sip.conf e adicionar as seguintes informações do entroncamento no
final do arquivo:
[peerFILTRO]
Host=<IP_FILTRO>
Port=<PORTA_FILTRO>
Disallow=all
Allow=ulaw
Allow=alaw
Context=from-pabx

seguinte comando:
185
Configurações do entroncamento SIP no canal SIP (máquina Filtro Transparente)
Para configurar o entroncamento SIP no Asterisk da máquina do Filtro Transparente, edite o
arquivo /etc/asterisk/sip.conf e adicione as seguintes informações do entroncamento no final
do arquivo:
[peerVOIP]
Host=<IP_VOIP>
Port=<PORTA_VOIP>
Disallow=all
Allow=ulaw
Allow=alaw
Context=from-voip
Por fim, crie a variável global no arquivo /etc/asterisk/extensions.conf com a seguinte definição:
DOMINIO_VOIP=peerVOIP

comando /etc/init.d/asterisk restart.
Configuração da interface E1 de comunicação do Asterisk com a operadora

(máquina do Filtro Transparente)
Para configurar o entroncamento E1 no Asterisk da máquina do Filtro Transparente, inicial-
mente deve-se distinguir se a configuração é MFC/R2 ou ISDN.
Caso seja MFC/R2:
Edite o arquivo /etc/zaptel.cfg com os seguintes dados:
span=1,1,0,cas,hdb3
cas=1-15:1001
cas=17-31:1001
loadzone=us
defaultzone=us
E o arquivo /etc/asterisk/unicall.conf com as seguintes informações de entroncamento:
[channels]
context=from-pstn
usecallerid=yes
hidecallerid=no
Serviço fone@RNP
threewaycalling=yes
transfer=yes
186
cancallforward=yes
callreturn=yes
echocancel=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
protocolclass=mfcr2
protocolvariant=br,20,4; ajustar de acordo com a OPERADORA
protocolend=cpe
channel => 1-15
channel => 17-31
CANAL_OPERADORA=UNICALL/g1

comando /etc/init.d/asterisk restart.
Caso seja ISDN:
bchan=1-15,17-31
dchan=16
loadzone = us
defaultzone = us
E o arquivo /etc/asterisk/zapata.conf com as seguintes informações de entroncamento:

[channels]
context=default
switchtype=qsig
signalling=pri_cpe
usecallerid=yes
group=1
187
context=> from-pstn
channel=> 1-15,17-31
jbenable=yes
CANAL_OPERADORA=ZAP/g1
Ao finalizar a edição do arquivo, o técnico deverá reiniciar o processo do Asterisk

com o comando /etc/init.d/asterisk restart.
Configure a interface E1 de comunicação do Asterisk com o PBX (máquina do Filtro

Transparente)
Para configurar o entroncamento E1 no Asterisk da máquina do Filtro Transparente, inicial-
mente deve-se distinguir se a configuração é MFC/R2 ou ISDN.
Caso seja MFC/R2:
span=2,0,0,cas,hdb3
cas=32-46:1001
cas=48-62:1001
loadzone=us
defaultzone=us
E o arquivo /etc/asterisk/unicall.conf com as seguintes informações de entroncamento:
[channels]
context=from-pabx
usecallerid=yes
hidecallerid=no
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
Serviço fone@RNP
rxgain=0.0
txgain=0.0
group=1
188
callgroup=1
pickupgroup=1
immediate=no
protocolclass=mfcr2
protocolvariant=br,20,4; ajustar de acordo com o PBX
protocolend=cpe
channel => 32-46
channel => 48-62
CANAL_PABX=UNICALL/g2
Ao finalizar a edição do arquivo, reinicie o processo do Asterisk usando o seguinte comando:
Caso seja ISDN:
bchan=32-46,48-62
dchan=47
loadzone = us
defaultzone = us
E o arquivo /etc/asterisk/zapata.conf com as seguintes informações de entroncamento:
[channels]
context=default
switchtype=qsig
signalling=pri_net
usecallerid=yes
group=1
context=> from-pabx
channel=> 32-46,48-62
jbenable=yes
CANAL_PABX=ZAP/g2
Ao finalizar a edição do arquivo, reinicie o processo do Asterisk com o comando

/etc/init.d/asterisk restart.
189
Alteração do plano de discagem no Asterisk para encaminhamento das chamadas para
o Filtro Transparente (máquina 2)
Para configurar o plano de discagem para o encaminhamento de chamadas para o outro
PBX IP, o técnico deve editar o arquivo do plano de discagem /etc/asterisk/extensions.conf e
adicionar o seguinte contexto de chamadas:
CANALZAP=SIP
Todas as outras linhas que possuem a variável CANALZAP deverão ter adicionado o texto
@peerFILTRO após a variável ${EXTEN}.
Ao finalizar a edição do arquivo, recarregue o plano de discagem no Asterisk. Para rea-

lizar esta tarefa, carregue o console do Asterisk com o comando asterisk –vvvvr. Dentro do
console, execute o comando dialplan reload.
Configuração do plano de discagem para receber chamadas da operadora (máquina do

Filtro Transparente)
Para configurar plano de discagem para receber chamadas da operadora, edite o arquivo do
[from-pstn]
include => destino-ramal
include => destino-voip
Ao finalizar a edição do arquivo, recarregue o plano de discagem no Asterisk. Para realizar

esta tarefa, carregue o console do Asterisk com o comando asterisk -vvvvr. Dentro do console
do Asterisk execute o comando dialplan reload.
Configuração do plano de discagem para receber chamadas do PBX (máquina do Filtro

Transparente)
Para configurar o plano de discagem para receber chamadas do PBX, edite o arquivo do
[from-pabx]
include => destino-local-fixo
include => destino-local-movel
include => destino-interurbano-fixo
include => destino-interurbano-movel
include => destino-internacional
include => destino-voip
include => diversos

Serviço fone@RNP
Ao finalizar a edição do arquivo, recarregue o plano de discagem no Asterisk. Para isso,

carregue o console do Asterisk com o comando asterisk -vvvvr. Dentro do console do Asterisk
execute o comando dialplan reload.
Configuração do plano de discagem para receber chamadas do ambiente VoIP (máqui-

na do Filtro Transparente)
190
Para configurar o plano de discagem para receber chamadas do serviço VoIP fone@RNP local,
edite o arquivo do plano de discagem /etc/asterisk/extensions.conf e adicione o seguinte
contexto de chamadas:
[from-voip]
include => destino-ramal
include => destino-local-fixo-semvoip
include => destino-local-movel
include => destino-interurbano-fixo-semvoip
include => destino-interurbano-movel
include => destino-internacional
include => diversos
Ao finalizar a edição do arquivo, recarregue o plano de discagem no Asterisk. Para isso, car-
regue o console do Asterisk usando o comando asterisk -vvvvr. Dentro do console do Asterisk
execute o comando dialplan reload.
Configure o plano de discagem para encaminhar chamadas (máquina do Filtro

Transparente)
Para configurar plano de discagem para encaminhar chamadas e assim filtrá-las, edite o arquivo
do plano de discagem /etc/asterisk/extensions.conf e adicione o seguinte contexto de chamadas:
[destino-local-fixo]
Exten => _[2-5]XXXXXXX,1,Dial(SIP/${EXTEN}@${DOMINIO_VOIP},40,rtT)
Exten => _[2-5]XXXXXXX,n,GotoIf($[“${DIALSTATUS}”=”ANSWERED”]?hangup)
Exten => _[2-5]XXXXXXX,n,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
Exten => _[2-5]XXXXXXX,n(hangup),Hangup()
[destino-interurbano-fixo]
Exten => _0XXXX[2-5]XXXXXXX,1,Dial(SIP/0${EXTEN:3}@${DOMINIO_

VOIP},40,rtT)
Exten => _0XXXX[2-5]XXXXXXX,n,GotoIf($[“${DIALSTATUS}”=”ANSWERED”]?ha

ngup)
Exten => _0XXXX[2-5]XXXXXXX,n,Dial(${CANAL_

OPERADORA}/${EXTEN},40,rtT)
Exten => _0XXXX[2-5]XXXXXXX,n(hangup),Hangup()
[destino-local-fixo-semvoip]
Exten => _[2-5]XXXXXXX,1,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
[destino-interurbano-fixo-semvoip]
Exten => _0XXXX[2-5]XXXXXXX,1,Dial(${CANAL_
191
[destino-local-movel]
Exten => _[6-9]XXXXXXX,1,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
[destino-interurbano-movel]
Exten => _0XXXX[6-9]XXXXXXX,1,Dial(${CANAL_

[destino-internacional]
Exten => _00XXXXX.,1,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
Exten => _00XXXXX.,n(hangup),Hangup()
[diversos]
Exten => _0X00XXXX.,1,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
Exten => _0X00XXXX.,n(hangup),Hangup()
Exten => _XXX,1,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
Exten => _XXX,n(hangup),Hangup()
Exten => _XXXX,1,Dial(${CANAL_OPERADORA}/${EXTEN},40,rtT)
Exten => _XXXX,n(hangup),Hangup()
[destino-voip]
Exten => _1XXXXXXX,1,Dial(SIP/${EXTEN}@${DOMINIO_VOIP},40,rtT)
Exten => _1XXXXXXX,n(hangup),Hangup()
Exten => _0XX1XXXXXXX,1,Dial(SIP/${EXTEN}@${DOMINIO_VOIP},40,rtT)
Exten => _0XX1XXXXXXX,n(hangup),Hangup()
Exten => _0XXXX1XXXXXXX,1,Dial(SIP/0${EXTEN:3}@${DOMINIO_VOIP},40,rtT)
Exten => _0XXXX1XXXXXXX,n(hangup),Hangup()
[destino-ramal]
Exten => _XXXX,1,Dial(${CANAL_PABX}/${EXTEN},40,rtT)
Exten => _XXXX,n(hangup),Hangup()

Serviço fone@RNP
192
10
QoS e Troubleshooting
objetivos
Apresentar a Qualidade de Serviço (QoS), seus parâmetros relativos e como manter

uma boa qualidade nas chamadas por IP. Apresentar problemas comuns em VoIP
e suas soluções, através da resolução prática de problemas simulados.
conceitos
Qualidade de Serviço (QoS), firewalls e SIP.
Desde sua origem, a rede IP é uma rede de “melhor esforço”. Isto significa que a rede faz
o possível para que os pacotes que por ela trafegam alcancem seu destino, mas ela não
garante o tempo de entrega, a ordem de entrega, a integridade do pacote ou mesmo se a
entrega desses pacotes irá ocorrer. A rede IP simplesmente faz o melhor possível.
Para melhorar o serviço da rede IP, existem protocolos de camadas superiores, por exemplo
o TCP, que resolve boa parte dos problemas do IP. Entretanto, para manter a qualidade das
chamadas em uma rede de pacotes semelhante às da rede determinística, são aplicadas téc-
nicas de QoS à rede. Dessa forma, serviços com requisitos rígidos de atraso, banda e outros
parâmetros podem utilizar a rede IP sem perder qualidade.
Este capítulo apresenta considerações sobre Qualidade de Serviço em redes IP com foco
no serviço de Voz sobre IP, identificando cuidados a tomar junto aos firewalls; por fim,
demonstra técnicas de troubleshooting do serviço VoIP de uma instituição usuária local.
O que é QoS?
11 Quality of Service (Qualidade de Serviço). q
11 O tráfego é tratado de alguma forma:
Capítulo 10 - QoS e Troubleshooting
22 Priorizado.
22 Policiado.
11 Em telefonia, é definido na recomendação ITU X.902:
22 “Conjunto de requisitos de qualidade no comportamento coletivo de um ou

mais objetos.”
QoS é o acrônimo para Quality of Service, ou Qualidade de Serviço. De forma geral, diz-se que
uma rede “possui QoS”, quando o tráfego que passa por ela é tratado de forma a priorizar
os fluxos críticos, mantendo uma boa experiência de uso das aplicações que exigem intensa
interatividade, como telefonia.
193
A implementação de QoS em uma rede abrange ações que vão desde a simples atenção
para que um enlace não fique congestionado até a aplicação de regras de descarte. Nor-
malmente aplicadas em enlaces de baixa velocidade, as técnicas mais comuns consistem de
classificação de pacotes, enfileiramento e encaminhamento de acordo com prioridades
pré-estabelecidas e descarte de pacotes que não estão em conformidade com as políticas
estabelecidas.
Em telefonia, QoS é definido no padrão ITU X.902 como “um conjunto de requisitos de quali-
dade no comportamento coletivo de um ou mais objetos”.
Na prática, o termo QoS causa alguma confusão. Uma interpretação mais simples diz que
a rede sem QoS presta um serviço de melhor esforço, isto é, sem garantias de tempo ou de
entrega. Por outro lado, uma rede com QoS prioriza os serviços de quem contrata “QoS”, ou
seja, de quem contrata um certo nível de serviço, que lhe assegura que alguns parâmetros
são mantidos dentro de valores acordados. QoS, neste caso, é tratado como um produto ou
serviço prestado pela operadora que garante uma boa experiência de uso da rede.
Popularmente:5
11 Rede sem QoS => melhor esforço;
11 Rede com QoS => priorização de pacotes.
Um aspecto importante que muitos leigos desconhecem é que para ser possível adotar
políticas de QoS é necessário ter controle sobre a rede e seus dispositivos. Portanto, como
consequência da afirmação anterior, pode-se inferir que a internet é uma rede sem QoS, ou
seja, não há priorização de pacotes, classificação de serviços ou nada que garanta que fluxos
de voz terão maior prioridade que fluxos de dados. A internet é uma rede de melhor esforço.
De forma geral, para links de internet, operadoras e clientes minimizam problemas relacionados
à qualidade simplesmente mantendo a banda disponível em seus enlaces sempre acima das
suas demanda de utilização. Contudo, contratar mais banda invariavelmente significa aumentar
custos com telecomunicações. Por outro lado, em comparação com adoção de regras de QoS,
essa abordagem reduz a necessidade de recursos computacionais nos nós da rede e reduz con-
sideravelmente a complexidade na configuração e manutenção dos equipamentos.
Parâmetros importantes
Em Voz sobre IP, os parâmetros que mais degradam a qualidade da conversação são o
atraso, a perda de pacotes, o jitter (variação do atraso) e a banda disponível para as cha-
madas. Esses quatro parâmetros devem ser medidos e monitorados constantemente. Todos
concordam sobre os parâmetros que causam problemas em VoIP, mas muitos discordam
sobre os valores limites que a rede deve apresentar.
Cada fabricante ou pesquisador sugere números que diferem levemente, mas há um q

consenso em torno dos valores a seguir:
11 Perda de pacotes < 5%
11 Atraso fim-a-fim < 150 ms (em um sentido apenas)

Serviço fone@RNP
11 Jitter (variação de atraso) < 30 ms
11 Banda (margem de segurança) > 10% do tráfego real
Manter estes parâmetros dentro dos intervalos indicados é condição necessária para
manter a qualidade das ligações realizadas pela rede IP. Outra característica relevante que
contribui para o atraso fim-a-fim é o tempo que um codec leva para codificar e decodificar
194
fluxos de vídeo ou áudio. Os tempos de (de)codificação estão fortemente ligados à capaci-
dade de processamento das máquinas em que estão sendo executados.
A Tabela 10.1 apresenta uma análise comparativa dos tempos (em milissegundos) que se
leva para traduzir codecs de voz em um servidor Asterisk, Pentium IV 2,26 GHz e 512 MB de
memória RAM.
g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 ilbc
g723 - 14 12 12 14 12 11 17 20 28
gsm 12 - 2 2 4 2 1 7 10 18
ulaw 12 4 - 1 4 2 1 7 10 18
alaw 12 4 1 - 4 2 1 7 10 18
g726 12 4 2 2 - 2 1 7 10 18
adpcm 12 4 2 2 4 - 1 7 10 18
Tabela 10.1
Atraso (em slin 11 3 1 1 3 1 - 6 9 17
milissegundos) para
tradução entre lpc10 13 5 3 3 5 3 2 - 11 19
codecs. Formato
Fonte (linhas) – g729 13 5 3 3 5 3 2 8 - 19
Formato Destino
(colunas). ilbc 24 16 14 14 16 14 13 19 22 -
Além de ilustrar os tempos de que cada codec precisa, a Tabela 10.1 também mostra que
determinado codec A precisa de mais tempo para traduzir para B do que para outro codec C,
e que o tempo de tradução de um codec A para um codec B não é necessariamente o
mesmo tempo da tradução de B para A.
Por exemplo, para traduzir de ulaw (G.711, Lei-µ) para G.729, são necessários 10 ms; para
traduzir de G.729 para ulaw o tempo necessário é de 3 ms.
Sobre enlaces congestionados

11 Suscetível à perda de pacotes, atraso demasiado e jitter. q
11 Contratar mais banda ou “aplicar” QoS?
11 QoS em enlaces para a internet.
11 TCP possui controle de fluxo; UDP não.
Todos os parâmetros mencionados sofrem degradação principalmente devido ao con-

gestionamento em algum ponto da rede. Na verdade, se há congestionamento, não há
mais margem de segurança de banda disponível. O congestionamento se apresenta para
o usuário como ligações de baixa qualidade e pacotes na voz, pois faz extrapolar os níveis
aceitáveis de perda, jitter e latência.
Quando o congestionamento ocorre por insuficiência de banda, nas situações de sub-

-dimensionamento do circuito ou crescimento da taxa de chamadas simultâneas, pode-se
facilmente contornar o problema contratando mais banda da operadora. Essa é a única
forma de resolver o problema.
Quando o congestionamento ocorre por conta de rajadas de tráfego de dados, sendo este
um tráfego legítimo e indispensável, é possível definir regras de QoS que priorizam o tráfego
195
de voz. Neste caso, dependendo da quantidade e intensidade das rajadas, o tráfego de
dados pode experimentar atrasos e taxas de perda maiores para que a qualidade da voz se
mantenha aceitável. Provavelmente, isto aumentará a sensação de congestionamento para
os usuários dos serviços de dados.
Caso o enlace em questão seja um acesso à internet, só faz sentido priorizar o tráfego de
voz na saída da rede para a internet. Não há como controlar o tráfego de entrada na rede
interna, pois não se tem administração sobre os roteadores da internet. Uma análise inicial
poderia afirmar que regras de policiamento aplicadas na entrada da internet não surtem
efeito. Entretanto, como boa parte das conexões de dados é realizada utilizando o protocolo
de transporte TCP, o controle ou policiamento de tráfego de entrada pode sim surtir efeito
positivo, já que o TCP possui controle de fluxo embutido em seu mecanismo de transporte
de dados. Infelizmente, este raciocínio não se aplica ao tráfego UDP, que não possui controle
de fluxo. De qualquer forma, se este for o caso, a indicação para resolver o problema é
também contratar mais banda da operadora.
Para enlaces Frame Relay, ainda muito comuns no Brasil, que estejam com ocupação
próxima à saturação existem duas recomendações principais: 1) compressão de cabeçalho
e; 2) fragmentação e interposição de pacotes.
Compressão de cabeçalho
11 Redução de 40 para 5 bytes. q
11 Economia de cerca de 50%, dependendo do codec.
11 Deve ser feita em cada salto que suporte compressão.
A compressão de cabeçalho consiste em uma técnica que associa cabeçalhos IP+UDP+RTP

a códigos que variam de 2 a 5 bytes. Assim, dependendo do codec utilizado, a economia de
banda facilmente chega muito perto dos 50%, conforme mostrado na Figura 10.1.
A técnica parte do princípio de que em um determinado fluxo de dados, as informações

nesses cabeçalhos praticamente não se modificam, repetindo-se várias vezes. Assim, é pos-
sível montar uma tabela com informações de cada fluxo que atravessa o roteador.
20 bytes 8 bytes 12 bytes >=20 bytes<=160 bytes
IP UDP RTP Payload
>=20 bytes<=160 bytes
IP/
UDP/ Payload
RTP Figura 10.1
Compressão de
2-5 bytes cabeçalho.
A compressão de cabeçalho precisa ser estabelecida a cada salto (hop), o que faz aumentar
o tempo de processamento total na transmissão fim-a-fim do pacote. Seu uso é indicado
Serviço fone@RNP
para enlaces próximos da saturação ou onde o aumento da banda não é possível.
196
Fragmentação e interposição de quadros
11 Diminui o tempo de espera dos pacotes (tempo de serialização). q
11 Reduz o jitter.
11 Aumenta o overhead.
A fragmentação e interposição de pacotes (LFI) é utilizada em enlaces de baixa velocidade

para diminuir o atraso na serialização dos dados. Por exemplo, um pacote de 1500 bytes leva
214 ms para ser inserido em um enlace de 56 kbps, ou seja, se cada pacote de voz precisasse
aguardar um pacote de dados de 1500 bytes, a conversação seria impossível, pois o intervalo
entre os pacotes ultrapassa o valor de 150 ms, sugerido como limite para uso em telefonia.
1500 x 8 bits / 56000 bps = 214 ms
Antes
VOZ Dados
214 ms de atraso na serialização

para frame de 1500 bytes a 56 kbps
Depois
Figura 10.2
Fragmentação e
interposição.
Dados Dados VOZ Dados
A interposição dos pacotes de voz entre os fragmentos do pacote de dados, mostrada na

Figura 10.4 diminui o tempo de espera de cada pacote, contribuindo para a diminuição do
atraso fim-a-fim e do jitter. Uma vez fragmentado, o fragmento precisa de um novo cabe-
çalho, fazendo aumentar a quantidade de dados a serem transportados pelo link, ou seja,
a fragmentação acarreta o aumento do overhead. Por esse motivo, existem valores ótimos
para o tamanho do fragmento em relação à banda do enlace. Esses valores dependem do
atraso de serialização desejado e são calculados teoricamente, mas também podem ser
medidos empiricamente.
A Tabela 10.2 mostra uma relação de valores ótimos para tamanho do fragmento de acordo
com a velocidade do enlace, para atraso de serialização de 10 ms.
Taxa da porta Tamanho recomendado do fragmento (10 ms)
64 kbps 80 bytes
128 kbps 160 bytes

Tabela 10.2
Tamanho do 256 kbps 320 bytes
fragmento de
512 kbps 640 bytes
acordo com a
velocidade do
1536 kbps (full T1) 1600 bytes
acesso (adaptado
de tabela obtida no
2048 kbps (full E1) 1600 bytes
site da Cisco).
197
Modelos de QoS
11 Integrated Services – reserva de recursos na rede. q
11 Differentiated Services – marcação e priorização de tráfego.
Os recursos da rede para encaminhamento dos pacotes são limitados. Existem alguns
modelos de QoS para minimizar os efeitos dessa limitação ou para garantir que determi-
nado fluxo atravesse uma rede e chegue do outro lado com a qualidade desejada.
IntServ – Integrated Services

Descrito na RFC 1633, o modelo de serviços integrados garante que o fluxo terá plenas
condições de atravessar a rede com qualidade por requisitar e alocar recursos em todos
os roteadores no domínio IntServ antes mesmo de começar a transmitir os dados. Dessa
forma, a comunicação só acontece se todos os nós responderem positivamente à requisição
de recurso. Se não houver recurso disponível, não haverá comunicação.
O protocolo Resource Reservation Protocol (RSVP), descrito na RFC 2205, é o responsável

pela sinalização no domínio IntServ, estabelecendo e desfazendo caminhos confiáveis na
rede. Uma rede que implemente IntServ precisa garantir que seus roteadores sejam capazes
de executar as seguintes tarefas:
11 Controle de admissão: determina que um fluxo pode ser encaminhado com o grau de
qualidade requerido sem interferir em fluxos que já estejam em curso;
11 Classificação: reconhece pacotes que necessitam de níveis específicos de QoS;
11 Policiamento: age, inclusive descartando pacotes, quando o tráfego não está em confor-
midade com o especificado;
11 Enfileiramento e escalonamento: encaminha os pacotes de acordo com os requisitos

de QoS.
O modelo IntServ possui uma séria desvantagem. O RSVP requer muita memória nos rote-
adores. É necessário manter o estado de diversas conexões simultaneamente. A consequ-
ência desse problema é a dificuldade em escalar para redes muito grandes tornando-se
impraticável na internet.
DiffServ – Differentiated Services

O modelo de serviços diferenciados, descrito na RFC 2475 e atualizado pela RFC 3260, foi
criado pela necessidade de um método relativamente simples prover tratamento adequado
para os fluxos das diferentes aplicações de redes. Era preciso diferenciar os fluxos em
classes de serviços distintas e tratar os pacotes de acordo com suas necessidades.
Os roteadores que implementam DiffServ precisam possuir 4 blocos lógicos, ilustrados na

Figura 10.5:
11 Classificador: seleciona um pacote do fluxo baseado no conteúdo de alguma porção

do cabeçalho;
Serviço fone@RNP
11 Medidor: checa se os parâmetros do tráfego estão de acordo e passa os resultados

para o marcador e modelador;
11 Marcador: escreve (ou rescreve) o campo DSCP;
11 Modelador: atrasa ou descarta alguns pacotes para que o tráfego fique em conformidade
com o projeto.
198
Medidor
P2
Pacotes Modelado
Classificados Marcador Modelador/ Descarte
Descartado
Figura 10.3
Bloco de
condicionamento
de tráfego.
Mecanismos de condicionamento de tráfego

11 Policiamento (Policing): o policiamento consiste em descartar todo o tráfego que excede
determinada taxa.
11 Modelagem (Shaping): a modelagem tenta não descartar o tráfego excedente, enfilei-

rando e distribuindo as rajadas de dados que excedem determinado limite, amortecendo
o efeito da rajada no enlace.
Para alcançar o objetivo de encaminhar pacotes de diferentes classes e, portanto, com dife-
rentes prioridades, são necessárias duas ações principais: 1) marcação dos pacotes, usando
o campo ToS do cabeçalho IP e; 2) PHB (Per Hop Behavior), que define um comportamento
diferente a cada salto do pacote, ou seja, a cada roteador.
Marcação de pacotes
O campo Type of Service (ToS) do cabeçalho IP foi redefinido na RFC 2474 e agora é chamado
de Differentiated Services (DS). Consiste de 6 bits utilizados para classificação do fluxo
e mais 2 bits reservados e não utilizados. Os 6 bits substituem os 3 bits que antes era
chamado de IP Precedence e passa a ter o nome de DiffServ Code Point (DSCP). Este campo
é utilizado para marcar um pacote de acordo com sua classificação, que pode assumir até 64
(26) valores distintos. A Figura 10.4 mostra o exposto.
0-2 6-7
Precedência
Campo TOS Não usado
do IP
Cabeçalho IP
Byte TOS
antes de DiffServ
Cabeçalho IP
Campo DS
após DiffServ
Figura 10.4
Cabeçalho IP
antes e depois
do DiffServ. DSCP ECN
0-5 6-7
199
Per Hop Behavior
Uma vez que os pacotes são marcados, os roteadores devem encaminhá-los de acordo com
regras pré-estabelecidas. Dependendo de suas classes, um pacote terá maior ou menor
prioridade na fila de saída de cada interface de rede.
11 Pacotes com prioridade Expedit Forwarding (EF) são imediatamente enviados para a
rede. A classe EF está descrita na RFC 2598.
11 Pacotes com prioridade Assured Forwarding (AF) possuem 4 classes distintas, são enfilei-
rados e encaminhados de acordo com a política de enfileiramento. Pacotes da classe AF4
têm maior prioridade que pacotes da classe AF1. Dentro de cada classe, ainda existe uma
marcação conhecida como “three colour marking” ou marcação de três cores, que definem
a probabilidade de descartar pacotes dentro de cada fila. Assim, existem 12 classes AF
distintas, que vão desde a AF41 até AF13. As classes AF estão descritas na RFC 2597.
11 Pacotes com prioridade padrão, também chamados de Best Effort (BE), possuem a menor
prioridade e serão encaminhados depois de todas as outras classes, se houver recursos
para isso. A classe BE está descrita na RFC 2474.
A Tabela 10.3 ilustra a relação entre as diferentes classes de serviço, o campo DSCP e a
correspondência com o antigo campo IP Precedence e com o campo equivalente em redes
MPLS. A tabela ainda mostra três possibilidades de se obter uma classe de serviço menor
que o Best Effort.
Tabela 10.3
Enfileiramento Relação entre DSCP
e IP Precedence
As técnicas de enfileiramento são utilizadas para encaminhar os pacotes na interface de em ordem de
saída do roteador de acordo com as marcações do pacote. prioridade.
11 First In, First Out (FIFO): este é o mais simples dos algoritmos de enfileiramento. Como o
próprio nome sugere, o primeiro pacote que entra na fila é o primeiro a sair dela.
Serviço fone@RNP
11 Strict Priority (SP): o algoritmo Prioridade Estrita foi desenhado para aplicações de
tempo real. A fila com maior prioridade é checada e se houver algum pacote, ele é
enviado. Quando a fila SP estiver vazia, o algoritmo procura por pacotes na próxima fila.
Assim que chega um pacote na fila SP, o algoritmo volta a esvaziar esta fila e repete o
processo. Também é conhecido como Low Latency Queue (LLQ) ou fila de baixa latência.
200
11 A desvantagem deste método é a possibilidade das outras filas sofrerem um fenômeno
chamado de starvation, quando elas podem nunca ser atendidas por sempre haver
pacotes na fila SP.
11 Weighted Round-Robin (WRR): este algoritmo escalona todas as filas e quando chega ao
final volta para a primeira, mas como as filas têm pesos, o algoritmo envia uma quanti-
dade de dados maior ou menor de acordo com o peso de cada fila. Também é conhecido
como Weighted Fair Queuing (WFQ) ou enfileiramento justo com pesos.
De forma geral, uma maneira comum de se modelar as classes de serviço em uma rede é
utilizar a fila LLQ ou prioridade estrita para tráfegos marcados com DSCP EF, normalmente
tráfego de voz, mais algumas filas WFQ ou WRR para pacotes com marcação DSCP AFxy para
vídeo, sinalização e outros serviços importantes, e BE para o tráfego comum de internet.
Medindo o QoS
11 Mean Opinion Score (MOS) – Modelo subjetivo. q
11 Modelo E (E Model) – Modelo objetivo.
Não integra o escopo deste curso o aprofundamento sobre métodos de medição de QoS; entre-
tanto, se faz necessária uma apresentação mínima dos padrões de medição mais comuns.
Mean Opinion Score

Mean Opinion Score (MOS), ou tentando uma tradução direta “pontuação da opinião média”,
é um modelo subjetivo para medição da qualidade, ou seja, baseado na experiência das
pessoas que qualificam os fluxos. Assim, são necessários muitos avaliadores para que a
medida seja validada. A preparação do ambiente de teste deve seguir rigorosas diretrizes.
Dessa forma, é muito difícil, trabalhoso e dispendioso conseguir a medida da qualidade
utilizando o MOS.
O MOS é comumente conhecido pela escala de qualificação padronizada pela ITU-T, que
pode ser baseada na qualidade ou na degradação do fluxo a ser qualificado. A escala de qua-
lidade, a metodologia e a preparação do ambiente para determinação do MOS está descrita
na recomendação ITU-T P.800, que também descreve os testes recomendados.
A Tabela 10.4 mostra a pontuação sugerida de dois métodos de avaliação utilizados em

testes de “listening-opinion” para os níveis de qualidade (método ACR – Absolute Category
Rating) ou de degradação (método DCR – Degradation Category Rating).
MOS Qualidade Degradação
5 Excelente Imperceptível
4 Bom Perceptível, mas não incomoda
3 Aceitável Incomoda um pouco

Tabela 10.4
2 Pobre Incomoda
Escala de
qualidade/
1 Ruim Incomoda muito
degradação.
201
Modelo-E
Obviamente, a qualidade (ou a falta dela) na comunicação digital é causada por parâmetros
mensuráveis. Dentre os fatores que definem a qualidade de um fluxo multimídia pode-se
destacar o codec utilizado, a perda de pacotes, a latência, o jitter, a vazão e ocupação do
enlace e o poder de processamento do servidor e do receptor.
O Modelo-E, apresentado pelo ETSI na proposição ETR 250 e padronizado pela ITU-T G.107
(40), é um método de medida de qualidade que leva em consideração parâmetros da rede e
do ambiente para inferir a qualidade das ligações, expressas pelo valor do Fator R, que varia
de 0 (péssimo) a 100 (ótimo).
De acordo com a recomendação G.113 (41), “profissionais que planejam redes e serviços
preocupados com desempenho fim-a-fim da transmissão da voz podem usar os fatores de
degradação com o Modelo-E para definir os efeitos da introdução das tecnologias de proces-
samento da voz”.
A seguir é apresentada a relação entre fator R e MOS, da recomendação G.107.
For R < 0: MOS = 155 MOS = 1
For 0 < R < 100: MOS = 1 + 0.035R + R(R − 60)(100 − R) x 7 x 105 MOS = 1 + 0.035R + R(R − 60)(100 − R) x 7 x 10
−6
For R > 100: MOS = 4.555 MOS = 4.5
A Tabela 10.5 relaciona o Fator-R, MOS e a satisfação do usuário.
Fator-R MOS Satisfação do usuário
90 4,35 Muito satisfeito
80 4,03 Satisfeito
70 3,6 Alguns usuários satisfeitos

Tabela 10.5
Relação entre
60 3,1 Muitos usuários insatisfeitos
Fator-R, MOS e
50 2,58 Quase todos insatisfeitos a satisfação do
usuário.
Firewall e NAT
11 Canal de controle da chamada, diferente dos canais de mídia. q
11 Canais de mídia são negociados dinamicamente.
11 Firewalls precisam examinar até o nível de aplicação (nível 7) para identificar portas.
Implementações de firewalls representam um problema significativo para VoIP quando o

protocolo utilizado é o SIP ou H.323, entre outros que atuam de forma semelhante, mesmo
quando a porta UDP 5060 (no caso do SIP) está explicitamente aberta. Obviamente, se o
firewall estiver bloqueando o canal de controle, a ligação não será estabelecida. Então,
Serviço fone@RNP
estamos considerando apenas casos em que a porta para estabelecimento e controle das
chamadas esteja aberta.
202
Como vimos em capítulos anteriores, o SIP inicia uma chamada de voz ou vídeo enviando
uma mensagem INVITE para seu proxy ou diretamente para seu interlocutor. Durante o
estabelecimento da chamada, além do tipo de mídia e dos codecs que serão utilizados na
conversação, os parceiros utilizam o protocolo SDP para negociarem também os endereços
IP e as portas UDP em que estarão ouvindo a espera dos fluxos de áudio e vídeo. Assim,
para telefonia, são criados mais dois canais para transporte do áudio da ligação, um canal
para cada sentido, do chamador para o chamado e vice-versa.
Este problema se apresenta para o usuário de duas formas. A ligação sempre é estabelecida
normalmente, mas 1) um dos lados não escuta o outro ou; 2) nenhum dos lados se escutam.
Abaixo, a figura ilustra a segunda situação.
Chamador Firewall / NAT Chamado
Canal de controle
Áudio
Figura 10.5 Áudio

Canais de
comunicação
nos protocolos
SIP e H.323.
Existem diversas formas para tentar minimizar ou resolver este problema. Uma prática muito
comum é configurar os telefones e proxies para que o fluxo de áudio no sentido contrário seja
enviado utilizando o mesmo par de portas do sentido de dentro para fora do NAT, simulando
um canal duplex. Além disso, também é possível utilizar um mecanismo conhecido como
STUN para que o conteúdo do SDP seja completado com o endereço IP com que o cliente SIP/
H323 é visto pelo lado de fora da rede ao invés do endereço IP real da máquina. Normalmente,
estas técnicas são utilizadas em conjunto, mas nem sempre com o sucesso esperado.
A seguir, apresentamos duas soluções eficazes para atravessar NAT e firewalls.
Solução 1: Firewall inteligente

Neste caso, o equipamento que implementa o firewall ou NAT precisa ser “inteligente” e
precisa analisar os pacotes SIP e H.323 até a camada de aplicação. Eles verificam a nego-
ciação no estabelecimento das chamadas e identificam no SDP os endereços IP e portas que
serão utilizadas e se preparam para encaminhar estes fluxos, abrindo e fechando (também
aguardam o BYE) as portas dinamicamente, sempre que necessário.
Não é difícil encontrar soluções de firewall compatíveis com SIP e H.323. No Linux, já existem
helpers para o iptables há algum tempo.
Solução 2: Media Proxy

Outra forma de resolver problemas com firewall e NAT é utilizar um Media Proxy, também
conhecido por Media Gateway.
Um Media Proxy é um equipamento que deve ser posicionado entre a rede interna e a rede
externa, como uma ponte entre as duas redes. Dessa forma, ele precisa ter uma interface na
rede externa, com um endereço IP roteável pela internet, e outra interface na rede interna,
sem tradução de endereço. Ele funciona copiando (e, às vezes, traduzindo) o fluxo de áudio de
um lado para outro da rede, mantendo protegida a rede interna, isolando-a da rede externa.
203
Uma vantagem da utilização de Media Proxies é que não deve ser necessário realizar qual-
quer modificação no firewall. Toda configuração é feita no sistema de telefonia.
Chamador Firewall / NAT Chamado
Canal de controle
Media Proxy Áudio
Áudio
Figura 10.6
Canais de
comunicação
com utilização do
Media Proxy.
Troubleshooting
Os últimos oito capítulos apresentaram a estrutura e os softwares que formam o serviço
VoIP do fone@RNP. No intuito de manter os serviços ativados, o administrador deverá
preocupar-se com a manutenção da estrutura e dos softwares para assim obter a alta dispo-
nibilidade do serviço VoIP local.
Registro de usuários e autenticação de SIP Requests

Inicialmente, sempre que o administrador tiver problemas com o serviço VoIP para registrar
usuários ou autenticar chamadas, deverá avaliar o Proxy SIP OpenSER que encontra-se na
máquina 1. Este serviço deverá estar sempre em execução. Para identificar se o OpenSER
está rodando, o administrador deverá executar o seguinte comando:
# ps aux | grep openser
openser 2451 0.0 0.5 7888 5004 ? S Nov06 0:47

python /usr/mediaproxy/mediaproxy.py --pid /var/run/mediaproxy/
mediaproxy.pid
openser 8737 0.0 0.8 45456 7492 ? S Nov07 0:00 /

usr/sbin/openser
openser 8743 0.0 0.3 45456 3508 ? S Nov07 0:00 /

usr/sbin/openser
openser 8745 0.0 0.3 45456 3524 ? S Nov07 0:00 /

usr/sbin/openser
Para acompanhar as solicitações tratadas pelo software OpenSER, todas as mensagens de

debug são armazenadas no arquivo /var/log/openser.log. Este arquivo é a fonte de dados
para identificar o destino definido na chamada pelo proxy.
Dependências
Serviço fone@RNP
O OpenSER possui como dependência de outros softwares para a sua execução. Possui
dependência do RADIUSClient-NG, FreeRADIUS e do OpenLDAP para a realização da autenti-
cação e autorização dos usuários VoIP. O PostgreSQL é o sistema de banco de dados utilizado
pelo OpenSER e caso a conexão seja perdida o OpenSER é encerrado automaticamente.
A permissão do proxy da mídia nas chamadas tratadas pelo OpenSER depende do MediaProxy.
204
Gateway Asterisk
A avaliação do gateway Asterisk deverá ser feita sempre que há problemas de chamadas
entre o ambiente VoIP e ramais do PBX. O gateway encontra-se na máquina 2 e para identi-
ficar se ele está em execução utiliza-se o seguinte comando:
# ps aux | grep asterisk
asterisk 12453 0.0 1.0 21752 9348 ? Ssl Nov08 1:11 /

usr/sbin/asterisk -U
O gateway possui duas formas de debug, pelo arquivo de log /var/log/asterisk/asterisk-maq2.log

ou pelo console do Asterisk. Para acessar o console, o administrador utiliza o comando
asterisk –vvvvr. No console é possível utilizar os comandos abaixo para obter mais informações:
11 show channels: mostra as chamadas ativas no Asterisk;
11 zap show channels: mostra os canais configuradores do canal ZAP e seus status;
11 show dialplan: mostra o plano de discagem ativo;
11 sip show conf: mostra as configurações do canal SIP.
Dependências
O Asterisk depende exclusivamente do OpenSER para encaminhar a chamada para o
ambiente VoIP; do PostgreSQL para manter os registros armazenados na base de estatís-
tica, do driver Zaptel para se comunicar com a interface VoIP e com a conexão com o PBX. O
driver Zaptel possui a ferramenta ztscan que identifica o status da interface VoIP e o status
da conexão com o PBX.
Os softwares FreeRADIUS, OpenLDAP e PostgreSQL não necessitam muito de Debug para

identificar problemas no ambiente VoIP, pois, quando mantidos em suas configurações origi-
nais não causam problemas ao serviço VoIP local. Contudo, estes softwares devem sempre
manter-se em execução e o administrador é responsável por esta manutenção.
205
Serviço fone@RNP
206
Atividade 10.1 – Troubleshooting
O objetivo da prática de troubleshooting é analisar o ambiente da instituição, identificar os
problemas no serviço local e corrigi-los. Nesta etapa, utilizando a arquitetura do serviço já
implantada, o grupo deverá realizar os seguintes passos:
11 Avalie se o serviço está funcionando perfeitamente através dos testes da Documentação

de Homologação (testes locais, testes com outras instituições e testes de IVR). Desconsi-
dere os testes que utilizam H.323;
11 Identifique as falhas que serão apresentadas no serviço;
11 Identifique o motivo da falha no serviço;
11 Corrija as falhas encontradas no serviço;
11 Refaça os testes e prove que o serviço está operacional.
Problema 1
a. Falhas apresentadas no serviço:
b. Motivo da falha no serviço:
c. Correção da falha no serviço:
Problema 2

207
Problema 3
Problema 4
Problema 5

Serviço fone@RNP
208
Problema 6
Atividade 10.2 – Marcação dos pacotes de voz

O objetivo desta atividade é alterar o proxy de mídia para realizar a marcação dos pacotes
RTP de áudio ou vídeo. Estes pacotes marcados poderão ser diferenciados nos roteadores
das instituições. Esta diferenciação permite que o descarte de pacote e o atraso na trans-
missão sejam reduzidos e, assim, conferir melhor qualidade à chamada.
A primeira etapa desta configuração é editar o arquivo /etc/mediaproxy/mediaproxy.ini e na

seção MediaProxy, descomente a linha do registro:
;TOS= 0xb8
0xb8 indica que o campo Qos/ToS/DSCP de cada pacote IP será enviado com o valor 184
(0xb8) de expedited forwarding. Após esta alteração, reinicie o MediaProxy com o comando:
/etc/init.d/mediaproxy restart
209
Serviço fone@RNP
210
Bibliografia
11 BORDIM, Jacir L. Introdução à Voz sobre IP e Asterisk. Escola Superior de

Redes/Rede Nacional de Ensino e Pesquisa, 2010.
11 GONÇALVES, Flávio E. Building Telephony Systems with OpenSIPS 1.6. 2010.

Packet Publishing.
11 ITU-T: H.323 Packet-based multimedia communications systems.
11 Laboratório de Voz sobre IP: www.voip.nce.ufrj.br.
11 MARTINS, Ricardo Rhomberg. Telefonia, dos circuitos aos pacotes: redes e

centrais telefônicas, redes de dados e roteadores, redes celulares, teoria de
filas. Rio de Janeiro: COPPE, 2004.
11 Recomendação ITU – G.711.
11 RESENDE, T. M. Balanceamento de chamadas E.164 VoIP com controles

centralizado e distribuído. In: 25o Simpósio Brasileiro de Redes de
Computadores e Sistemas Distribuídos, Belém. Anais do SBRC, 2008. v. 1. p.
1057-1070.
11 RFC 3261.
11 TODD, John. Asterisk: A Bare-Bones VoIP Example. O’Reilly, 2003.
Bibliografia
211
Serviço fone@RNP
212
Thiago Maluf é bacharel em Ciência da Computação pela
UFRJ com certificaçãoDébora Christina
DCAP pela Digium, Muchaluat
atuante naSaade
área deé
desenvolvimento de professora associada doprincipalmente
aplicações multimídias, Departamento
no setor de telefonia de Ciência da
IP. Bolsista no Computação
Laboratório de daVoz
Universi-
sobre
IP da UFRJ, participoudade Federaldo
da criação Fluminense (UFF). É enge-
projeto fone@RNP. Atu-
nheira de computação formada
almente é sócio e gerente de projetos da empresa presta- pela
dora de serviços, CAM PUC-Rio e possui
Tecnologia. mestrado
A CAM e doutorado
Tecnologia, hoje,
em informática
é a empresa mantenedora do serviçopela mesmaofertando
fone@RNP, universi-
dade. É bolsista
suporte de produtividade
e ampliação do serviço. em Desenvolvimento Tec-
nológico e Extensão Inovadora pelo CNPq e foi Jovem
Cientista do Estado do Rio de Janeiro pela Faperj. Suas áreas
de pesquisa são redesAlex Galhano Robertson
de computadores, é Enge-
redes sem fio, siste-
nheiro TV
mas multimídia e hipermídia, de digital
Telecomunicações (2005)
interativa e telemedi-
e Mestre
cina. Já coordenou diversos (2010)
projetos em Engenharia
de pesquisa financiadosde
redes, ambos pela Universidade
pelo CNPq e Faperj e foi coordenadora do projeto piloto Edu- Fede-
ral Fluminense
roam-br, financiado pela (UFF).
RNP e realizado emÉparceria
professor
comde a
cursos de VoIP e tecnologias afins
UFMS, UFRJ e diversas outras instituições, implantando o serem
viço piloto eduroam no cursos
Brasil.extracurriculares na UFF e par-
IP. Coordena projetos de desenvolvimento e instalação de
sistemas para troca de Ricardo
tráfegoCampanha Carrano é enge-
VoIP entre universidades do
nheiro de
Brasil e entre redes nacionais de telecomunicações formado
outros países. Participa ati-
vamente em projetosem 1995 pela Universidade
de modernização de sistemas de Federal
tele-
Fluminense.
fonia, de integração voz, Em 2008,
vídeo e dados e deobteve o título
otimização de
de Mestre em Engenharia de Teleco-
municações pela mesma instituição
e atualmente cursa o doutorado em
Computação, também na UFF, onde atua como Professor
do Departamento de Engenharia de Telecomunicações. Foi
empresário e participou da implantação de provedores de
acesso no início da Internet comercial no Brasil, em 1995.
Atuou como Engenheiro de Redes para a ONG internacio-
nal One Laptop per Child (OLPC) e já participou de diversos
projetos de pesquisa financiados pela RNP, pelo MEC e por
empresas privadas.
Edelberto Franco Silva se tornou

Bacharel em Sistemas de Informação
pela Faculdade Metodista Granbery
em 2006, e obteve o título de Mestre
em Computação pela Universidade
Federal Fluminense em 2011. Atual-
mente é Doutorando em Computação
pela Universidade Federal Fluminense. Participou de diver-
sos projetos de pesquisa, possuindo experiência na área
de Ciência da Computação, com ênfase em redes, atuando
principalmente nos temas relacionados a redes sem fio,
Internet do Futuro e segurança.
Thiago Maluf é bacharel em Ciência da Computação pela A RNP – Rede Nacional de Ensino
UFRJ com certificação DCAP pela Digium, atuante na área de
desenvolvimento de aplicações multimídias, principalmente e Pesquisa – é qualificada como
no setor de telefonia IP. Bolsista no Laboratório de Voz sobre uma Organização Social (OS),
IP da UFRJ, participou da criação do projeto fone@RNP. Atu-
almente é sócio e gerente de projetos da empresa presta- sendo ligada ao Ministério da
dora de serviços, CAM Tecnologia. A CAM Tecnologia, hoje, Ciência, Tecnologia e Inovação
é a empresa mantenedora do serviço fone@RNP, ofertando
suporte e ampliação do serviço. (MCTI) e responsável pelo
Alex Galhano Robertson é Enge- que conta com a participação dos
nheiro de Telecomunicações (2005)
e Mestre (2010) em Engenharia de
Serviço
redes, ambos pela Universidade Fede- O curso tem por objetivo capacitar profissionais das insti- Saúde (MS) e da Cultura (MinC).
ral Fluminense (UFF). É professor de
LIVRO DE APOIO AO CURSO

cursos de VoIP e tecnologias afins em tuições clientes da RNP na solução técnica de seu serviço Pioneira no acesso à Internet no
cursos extracurriculares na UFF e par- de Voz sobre IP, o fone@RNP. O profissional será capaz Brasil, a RNP planeja e mantém a
fone@RNP
IP. Coordena projetos de desenvolvimento e instalação de de instalar, operar e manter em sua instituição o conjun- rede Ipê, a rede óptica nacional
Serviço fone@RNP
sistemas para troca de tráfego VoIP entre universidades do to de servidores que constituem a rede de VoIP da RNP. acadêmica de alto desempenho.
Brasil e entre redes nacionais de outros países. Participa ati-
vamente em projetos de modernização de sistemas de tele- Este livro inclui os roteiros das atividades práticas e o con- Com Pontos de Presença nas
fonia, de integração voz, vídeo e dados e de otimização de
teúdo dos slides apresentados em sala de aula, apoiando 27 unidades da federação, a rede
profissionais na disseminação deste conhecimento em tem mais de 800 instituições
suas organizações ou localidades de origem. conectadas. São aproximadamente
Thiago Maluf de uma infraestrutura de redes

Alex Galhano Robertson computação e experimentação,
Saúde e Cultura.
Ministério da
Cultura
Ministério da
Saúde
Ministério da
Educação
ISBN 978-85-63630-28-5 Ministério da

e Inovação
9 788563 630285

Serviço Fone@RNP

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Serviço Fone@RNP

Enviado por

Direitos autorais:

Formatos disponíveis

Thiago Maluf é bacharel em Ciência da Computação pela A RNP – Rede Nacional de Ensino

UFRJ com certificação DCAP pela Digium, atuante na área de

LIVRO DE APOIO AO CURSO

Thiago Maluf de uma infraestrutura de redes

ISBN 978-85-63630-28-5 Ministério da

Diretor de Serviços e Soluções

Escola Superior de Redes

Coordenação Acadêmica de Mídias de Suporte à Colaboração Digital

Equipe ESR (em ordem alfabética)

Capa, projeto visual e diagramação

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

M236s Maluf, Thiago.

1. Redes VoIP – instalação e manutenção. 2. Protocolos de redes VoIP. 3. Asterisk

Integração das instituições usuárias 5

Redução do custo das chamadas 6

Adoção de medidas de QoS para a qualidade de serviço 7

Composição do serviço fone@RNP 7

Arquitetura do serviço nacional 8

Arquitetura do serviço local 9

VoIP via Softphone 10

VoIP via ATA 10

VoIP via telefone IP 11

Programa de Estatísticas Nacionais 11

Chamadas completadas por diferentes tipos de origem e destino 12

Ranking de uso para chamadas completadas por local 12

Motivos de não completamento 12

Atividade 1.1 – Instalando o softphone 15

Atividade 1.2 – Configurando o telefone IP 18

Atividade 1.3 – Configurando o ATA 19

Atividade 1.4 – Efetuando chamadas com ATA, telefone IP e softphone 20

Funções do protocolo SIP 21

Conjunção com outros protocolos 22

Extensões ao protocolo SIP 23

Características do protocolo SIP 23

Elementos de uma rede SIP 24

User Agents (UA) 24

Servidor Proxy 26

Utilização do servidor proxy 26

Servidor de redirecionamento 27

Servidor de registro 28

Servidor de registro no fone@RNP 29

Negociando a sessão SDP 36

Mudando parâmetros da sessão 36

Real-time Transport Protocol (RTP) 37

Real-time Transport Control Protocol (RTCP) 39

Empacotamento da voz – codec 41

Codificação de forma de onda 44

Características de escolha do codec 48

Roteiro de Atividades 2 49

Atividade 2.1 – Capture e avalie as mensagens SIP 49

3. Princípios do serviço VoIP na instituição usuária

Autenticação de usuários (ramais IP) 55

Gateway para telefonia convencional 55

Distribuição dos serviços nas máquinas 1 e 2 57

Encaminhamento de chamadas ao serviço 58

Controle de chamadas não autorizadas 61

Adesão do serviço 62

Instalação e homologação do serviço 62

Fluxo de instalação e homologação 62

Roteiro de Atividades 3 65

Atividade 3.1 – Instalação e homologação do serviço fone@RNP 66

Busca de usuários ou ramais IP cadastrados 69

Modificação de um usuário ou ramal IP 71

Remover usuário ou ramal IP 72