Introduao A Voz Sobre Ip e Asterisk PDF

Mídias de suporte
à colaboração digital
Introdução à Voz sobre
IP e Asterisk
Mídias de Suporte à Colaboração Digital

IP e Asterisk

IP e Asterisk
Copyright © 2010, Escola Superior de Redes RNP
Autor
Jacir L. Bordim
Revisão técnica
Alex Galhano Robertson
Antônio Tadeu Azevedo Gomes
Colaboradores
Bruno Correa
Sérgio Francisco
Supervisão técnica
Renato Duarte
Coordenação acadêmica
Derlinéa P. M. Miranda
Editor
Pedro Sangirardi
Design
Tecnodesign
Coordenação geral
Luiz Coelho
Versão
1.1.0
Todos os direitos reservados, no Brasil, por

Escola Superior de Redes RNP
http://esr.rnp.br
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado 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.
Escola Superior de Redes
A Escola Superior de Redes (ESR) é a unidade de serviço da Rede Nacional de
Ensino e Pesquisa (RNP) voltada à formação de competências em Tecnologias da
Informação e Comunicação (TIC). Sua missão é a disseminação do conhecimento,
com o oferecimento de cursos práticos intensivos com carga horária de até 40 horas
de duração, voltados ao mercado de trabalho.
Os cursos da ESR são baseados em atividades práticas que desenvolvem no aluno a

capacidade de análise e construção de hipóteses, para a superação dos problemas e
desafios encontrados no dia a dia do profissional de TI. A aprendizagem torna-se
mais efetiva se contextualizada à realidade profissional. Cada aluno tem sua própria
estação de trabalho nos laboratórios conectados à internet por meio da rede de alta
velocidade da RNP.
Apoiados por material didático exclusivo, elaborado por especialistas, os cursos são
distribuídos por cinco áreas temáticas: Administração e Projeto de Redes;
Administração de Sistemas; Segurança; Mídias de Suporte à Colaboração Digital e
Governança de TI.
Fazendo parte deste time, você está absorvendo a experiência acumulada de quem
trouxe a internet para o Brasil e continua inovando em pesquisa e desenvolvimento
na área de redes.
iii
MID1
Administração de
Videoconferência
40h
ADS1
Introdução
ao Linux
u
esto QUI 40h
ADR4
A MID2 Interconexão
Introdução à de Redes de SEG1
Voz sobre IP Computadores Introdução
e Asterisk 40h à Segurança
40h ADS2 de Redes
Administração 40h
de Sistemas
Linux ADR1
40h Arquitetura e
Protocolos de ADR6
Rede TCP-IP Tecnologias SEG2
ADS3 de Redes
40h
Adm. Sistemas Sem Fio Segurança
Linux: Redes de Redes
40h e Sistemas
e Segurança
40h
40h ADS5
ADS4 Virtualização ADR3

de Servidores
Adm. Sistemas Roteamento
Linux: Serviços SEG6
40h Avançado
para Internet Segurança
40h 40h em Redes
Sem Fio
40h
ADR7
ADR5
IPv6 Básico Gerência de
Redes de
40h Computadores
40h
Grade curricular da
Escola Superior de Redes
esr.rnp.br
GTI10
Planejamento
e Projeto de
Infraestrutura
para Datacenter
40h
GTI6
Gerenciamento
i co
Bás de Projetos de TI
GTI2
24h
Fundamentos
de Governança
GTI1 de TI
Planejamento 16h GTI3
GTI8
e Gestão
Gestão da
segurança da
Segurança
Estratégica de TI
di ário Gerenciamento
rme de Serviços de TI
informação
Informação 24h
Inte GTI4
27001,eNBR27002
NBR 27001 NBR 27002
24h
40h Governança
de TI
GTI9
24h
Gestão de
SEG4 Riscos de TI
NBR 27005
SEG3 Tratamento nç ado GTI7
de Incidentes
40h
Ava ITIL
Análise de Segurança Information Technology
Forense Infrastructure Library
40h GTI5
40h COBIT 16h
Control Objectives
for Information and
Related Technology
16h
SEG8
Engenharia
Reversa de
Código
Malicioso
40h
Áreas temáticas
Mídias de suporte à colaboração digital
Administração de sistemas
Legenda Administração e projeto de redes
Conhecimento Segurança
Todos os cursos da ESR prévio recomendado
requerem inglês para leitura e Curso Governança de TI v
noções de informática e Internet.
A interação através da internet é uma realidade entre as pessoas e organizações.
Aplicações como videoconferência, webconferência e VoIP suprem as necessidades
colaborativas de organizações e usuários domésticos, produzindo economia de
tempo e recursos. A capacitação na configuração, administração e operação das
mídias de suporte a reuniões, distribuição de áudio e vídeo, troca de arquivos e
compartilhamento de informações entre equipes e pessoas é de importância vital
nesse contexto. A Escola Superior de Redes oferece cursos preparatórios para o
domínio destas ferramentas essenciais no ambiente de qualquer organização.
A quem se destina?
\\Profissionaisque desejam aprender a utilizar e administrar recursos de
colaboração digital, para os mais diversos fins.
Convenções utilizadas
\\Texto puro
Usado no texto, opções de menu e auxiliares de teclado (Alt e Ctrl).
\\Itálico
Quando em títulos e parágrafos de texto, indica estrangeirismos, comandos e suas
opções, nomes de arquivos e referências a outras seções ou bibliografias. Quando em
largura constante, denota os parâmetros que serão indicados pelo usuário.
\\Texto em azul
Indica URLs acessíveis na internet ou no ambiente do laboratório. Podem ser
endereços de páginas, locais de rede ou endereços eletrônicos.
\\Texto em laranja
Sempre que constar nos parágrafos de texto indica uma entrada de glossário,
cuja definição deve ser vista na lateral do texto, próxima ao termo.
\\Largura constante
Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e
resultado da saída de comandos. Quando utilizados para indicar 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:\).
A separação entre o que o usuário digita e o retorno do computador é indicada

pelo caractere ↵ , em alusão à tecla Enter. Quando houver parâmetros opcionais
em exemplos, estes podem entrar entre colchetes [ ].
vi
\\ Parágrafo de texto com fundo laranja e ícone.
Representa notas e informações complementares como dicas, sugestões de
leitura adicional ou mesmo uma observação.
\\Parágrafo de texto com fundo laranja fonte em branco
Utilizado para destacar os enunciados das atividades ao longo do capítulo.
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
vii
viii
u Sumário
Capítulo 1
Histórico e conceitos básicos. . . . . . . . . . . . . . . . . . . 1
Capítulo 2
Protocolo SIP. . . . . . . . . . . . . . . . . . . . . . . . 49
Capítulo 3
Recomendação H.323. . . . . . . . . . . . . . . . . . . . . 93
Capítulo 4
Asterisk. . . . . . . . . . . . . . . . . . . . . . . . . . 125
Capítulo 5
Arquitetura do Asterisk . . . . . . . . . . . . . . . . . . . . 151
Capítulo 6
Plano de discagem. . . . . . . . . . . . . . . . . . . . . . 175
Capítulo 7
Serviços complementares. . . . . . . . . . . . . . . . . . . . 193
Capítulo 8
Distribuição de chamadas. . . . . . . . . . . . . . . . . . . 205
Capítulo 9
Unidade de Resposta Audível (URA). . . . . . . . . . . . . . . . 213
Capítulo 10
Qualidade de Serviço em VoIP. . . . . . . . . . . . . . . . . . 223
Bibliografia. . . . . . . . . . . . . . . . . . . . . . . . . 257
ix
x
1
Histórico e conceitos básicos
►► Sumário
Conceitos básicos de rede. . . . . . . . . . . . . . . . . . . . 3
Arquitetura TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 3
Camadas da arquitetura TCP/IP . . . . . . . . . . . . . . . . . . 4
Endereçamento IP . . . . . . . . . . . . . . . . . . . . . . . 7
Classes de endereçamento . . . . . . . . . . . . . . . . . . . . 8
Endereços especiais . . . . . . . . . . . . . . . . . . . . . . 9
Roteamento. . . . . . . . . . . . . . . . . . . . . . . . . 10
Comunicação VoIP . . . . . . . . . . . . . . . . . . . . . . 12
Evolução do VoIP. . . . . . . . . . . . . . . . . . . . . . . 12
VoIP ≠ ToIP . . . . . . . . . . . . . . . . . . . . . . . . . 13
Vantagens e desvantagens do VoIP . . . . . . . . . . . . . . . . . 13
Benefícios do VoIP . . . . . . . . . . . . . . . . . . . . . . 14
Existem três formas de comunicação via VoIP . . . . . . . . . . . . . 17
Padronização. . . . . . . . . . . . . . . . . . . . . . . . 20
Princípios de codificação de áudio . . . . . . . . . . . . . . . . . 21
Codificação da mídia de voz. . . . . . . . . . . . . . . . . . . 24
Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Codificação de forma de onda . . . . . . . . . . . . . . . . . . 25
Codificação paramétrica . . . . . . . . . . . . . . . . . . . . 26
Codificação híbrida. . . . . . . . . . . . . . . . . . . . . . 26
Padrões de codificação de voz . . . . . . . . . . . . . . . . . . 27
G.711 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
G.723.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iLBC. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Arquitetura VoIP. . . . . . . . . . . . . . . . . . . . . . . 30
Projetos VoIP no Brasil . . . . . . . . . . . . . . . . . . . . . 31
1
Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 33
Introdução à Voz sobre IP e Asterisk
Atividade 1 – Instalando o cliente X-Lite. . . . . . . . . . . . . . . 34

Atividade 2 – Configurando o X-Lite . . . . . . . . . . . . . . . . 34
Atividade 3 – Configurando o Telefone IP. . . . . . . . . . . . . . . 36
Atividade 4 – Configurando o ATA. . . . . . . . . . . . . . . . . 37
Atividade 5 – Efetuando chamadas com ATA, Telefone IP e X-Lite. . . . . . 39
Atividade 6 – Verificando codecs de áudio. . . . . . . . . . . . . . 39
Atividade 7 – Conhecendo o Wireshark. . . . . . . . . . . . . . . 43
Atividade 8 – Efetuando capturas com Wireshark . . . . . . . . . . . . 44
Atividade 9 – Capturando pacotes na rede. . . . . . . . . . . . . . 46
2
Conceitos básicos de rede
Capítulo 1 – Histórico e conceitos básicos

\\Conceitos básicos de rede:
\\Arquitetura TCP/IP;
\\Camadas da arquitetura TCP/IP;
\\Transporte dos pacotes;
\\Endereçamento IP;
\\Classes de endereçamento;
\\Endereços especiais;
\\Roteamento;
\\Protocolo de transporte.
A evolução das tecnologias de comunicação e a redução dos custos constituem os

principais fatores para a ampla adoção das redes de computadores nas
organizações. Tais redes são projetadas, essencialmente, para compartilhar recursos
de hardware e software e viabilizar a troca de informações entre usuários.
No entanto, as atuais tecnologias de redes restringem o número de dispositivos

conectados, e são geralmente incompatíveis entre si. Dispositivos conectados a uma
rede local que adota a tecnologia Ethernet, por exemplo, não interagem diretamente
com outros que utilizam outras tecnologias. Isso dificulta a comunicação de grandes
grupos de usuários e impede que usuários de redes distintas se comuniquem entre
si. Para viabilizar essa comunicação, a única alternativa é adotar mecanismos que
permitam a interoperabilidade, interconectando e compatibilizando as múltiplas
redes heterogêneas. A interconexão destas várias redes é denominada inter-rede.
Arquitetura TCP/IP
\\Conjunto pioneiro de protocolos;
\\Arquitetura universal.
A arquitetura TCP/IP é composta de um conjunto de protocolos e foi pioneira na

concepção de conectar qualquer máquina Unix (ou que utilize TCP/IP) a qualquer
outra, através de subredes interconectadas por gateways (roteadores).
O TCP/IP é de aplicação universal, com especificações que seguem um padrão e são

de conhecimento público (Request for Comments – RFC).
Em um ambiente TCP/IP, estações comunicam-se com servidores ou outras

estações. Isso é possível porque cada nó que usa o protocolo TCP/IP tem um único
endereço de rede lógico, de 32 bits.
3
O Transmission Control Protocol (TCP) é o protocolo de transporte responsável pela
entrega confiável dos dados no destino. Na RFC 793 que o define, ele é chamado
de Host to Host Protocol, porque é um protocolo residente somente nos hosts e não
nos gateways.
TCP
Host to Host
Internet
IP
Figura 1.1
Os dados são enviados de nó a nó, cada um deles decidindo qual é o próximo (next
hop). O responsável pelo roteamento na rede é o Internet Protocol (IP).
Camadas da arquitetura TCP/IP

\\Aplicação;
\\Transporte;
\\Rede;
\\Enlace de dados.
Segundo as RFCs, a arquitetura TCP/IP possui 4 camadas:
1. Aplicação – nesta camada estão os protocolos das aplicações suportadas por

esta arquitetura. Por exemplo, o protocolo HTTP é da aplicação www, e o
protocolo SMTP é da aplicação e-mail.
2. Transporte – nesta camada existem dois protocolos: TCP (orientado à conexão) e

UDP (sem conexão). A aplicação usará o que for mais adequado.
3. Rede – nesta camada temos o IP, que é um protocolo de rede sem conexão
(serviço datagrama) e os protocolos Internet Control Message Protocol (ICMP),
que envia mensagens de erro, e Internet Group Management Protocol (IGMP)
para endereçamento multicast.
4. Enlace de dados – nesta camada temos as subredes suportadas pelo IP.

Tipicamente são redes locais (LAN) ou enlaces seriais (WAN).
4
Telnet & NFS & Aplicação
Rlogin FTP HTTP SMTP DNS TFTP SNMP RPC
TCP UDP Transporte
ICMP IP IGMP Rede
Hardware Enlace
Figura 1.2 ARP Interface RARP
de dados
A arquitetura TCP/IP, conforme já vimos, é constituída de 4 camadas de protocolos.

Cada camada trata seus dados e monta a sua Unidade de Dados do Protocolo
(Protocol Data Unit – PDU).
A camada de aplicação monta a sua PDU com os dados da aplicação e o respectivo

protocolo (SMTP, FTP, entre outros) e passa para o TCP entregar ao host do outro
lado. Visto dessa forma, o TCP é comumente denominado Host to Host Protocol,
uma vez que ele se encarrega da comunicação fim a fim entre os hosts que estão
trocando informações.
O TCP monta a sua PDU (segmento TCP) e passa para o protocolo IP, que fica com
a tarefa de entregar o segmento TCP através de uma rede IP. Para isso, o protocolo
IP coloca o seu cabeçalho (header), criando assim a sua PDU, chamada de
datagrama IP ou simplesmente de pacote IP.
Nesse momento, o protocolo IP precisa se comunicar com a subrede, seja ela qual
for, para enviar o pacote IP devidamente encapsulado dentro do quadro da camada
de enlace de dados.
Evidentemente a subrede não entende o endereçamento IP e tem seu próprio

endereçamento. Assim, o protocolo IP precisa usar o endereçamento da subrede
para enviar o pacote IP. Existe então a necessidade de uma interface entre o
protocolo IP e a subrede.
Transporte dos pacotes

Algoritmos de comutação são relativamente simples e basicamente os mesmos para
a maioria dos protocolos de roteamento. Tipicamente, um host determina que precisa
enviar um pacote para outro host. Para isso ele tem que saber, de alguma forma, o
endereço do roteador que fará a ação (se não souber, não há como enviar o pacote).
O host envia o pacote para o roteador, colocando o endereço físico do roteador

(normalmente estão na mesma rede local, portanto o endereço físico será o MAC
address) e o endereço do protocolo de rede do host de destino. O roteador então
examina o pacote e tenta encaminhá-lo para o host de destino, baseado no seu
endereço de rede. Se o roteador tiver na sua tabela de rotas a rota adequada, ele
5
encaminhará para o próximo nó, mudando o endereço físico para o endereço do
próximo nó e mantendo o endereço de rede do host de destino. Se não tiver a rota

na tabela, o roteador simplesmente descartará o pacote. O processo se repetirá até
chegar no roteador que está na mesma rede do host de destino, que entregará o
pacote enviando-o para o endereço físico do host de destino. Assim, à medida que o
pacote atravessa a rede, seu endereço físico vai mudando; porém, o endereço do
protocolo de rede permanece igual (host de destino).
Origem
Pacote
Para: Destino (Endereço rede)

Router1 (Endereço físico)
Pacote
Roteador1 Para: Destino (Endereço rede)

Roteador2

Roteador3
Pacote

Destino (Endereço físico)
Pacote
Figura 1.3
Destino
6
Endereçamento IP

\\Endereços IP são baseados nos conceitos de rede e host;
\\Host é qualquer equipamento com capacidade de transmitir e receber pacotes

IP em uma rede;
\\Hosts são interconectados por uma ou mais redes;
\\O endereço IP é composto por:

\\Identificação da rede;
\\Identificação do host na rede.
\\Tamanho de 32 bits (4 octetos) representados por 4 números decimais

separados por um ponto;
\\Exemplo: 200.201.152.93 (notação decimal pontuada).
Um endereço IP é composto de um identificador de rede acrescido de um

identificador da estação nesta rede. Esta identificação independe da rede física
subjacente. Assim, para efeito de encaminhamento local (dentro da mesma rede), o
endereço IP é utilizado na estação emissora para a obtenção do endereço físico da
estação de destino. Esse processo é denominado mapeamento.
No caso do envio de uma mensagem para uma estação situada em outra rede, a
estação de origem obtém o endereço físico do gateway para a rede de destino. Vale
ressaltar que a rede de destino não necessariamente está conectada à rede local.
Neste caso, a mensagem é transportada por várias redes intermediárias, de
gateway a gateway, preservando o endereço IP de destino, que é utilizado na
obtenção dos endereços intermediários dos gateways presentes na rota. Assim, o
encaminhamento IP é uma sequência de ciclos repetidos: análise do endereço IP,
obtenção do endereço físico da estação (se a rede de destino foi atingida) ou do
gateway de saída (se a estação pertence a uma rede remota) e envio do datagrama
para o endereço físico obtido.
Endereço IP, com seus 32 bits, torna-se demasiado grande para a notação decimal.
Por isso é utilizada a notação decimal pontuada. Os 32 bits são divididos em quatro
grupos de 8 bits cada.
Por exemplo, dado o endereço IP: 00000011.00000111.00001111.00000001,

sua representação seria: 3.7.15.1.
7
Classes de endereçamento
\\Os primeiros bits do primeiro octeto definem a classe do endereço;
\\N = número da rede (network) dado pelo NIC;
\\H = número da estação (host) dado pelo administrador da rede.
32 Bits 8 Bits 8 Bits 8 Bits 8 Bits
Rede Host 131 108 122 204
Classe A N H H H
Classe B N N H H
Classe C N N N H
Figura 1.4
O endereço IP tem tamanho de 32 bits e possui duas partes:
\\Número de rede;
\\Número de host.
O formato do endereço é conhecido como notação decimal pontuada, que é

separada por pontos.
Exemplo de endereço: 131.108.122.204.
Cada bit no octeto tem um peso conforme sua posição, como (128, ..., 4, 2, 1).
O valor mínimo para um octeto é 0; ele tem todos os bits 0. O valor máximo para
um octeto é 255; ele tem todos os bits 1. Portanto, todos os endereços IP no
intervalo de 0.0.0.0 a 255.255.255.255 são endereços válidos.
A alocação dos endereços é gerenciada por uma autoridade central. Números de

rede são administrados pelo Internet Network Information Center (InterNIC). O NIC
também é o principal arquivo de RFCs (padrões dos protocolos da arquitetura TCP/
IP). No Brasil, a delegação de endereços IP é feita pela Fundação de Amparo à
Pesquisa de São Paulo (FAPESP), órgão credenciado pelo InterNIC.
Para facilidade de administração, os endereços IP são divididos em classes:
\\Classe A – utiliza somente o primeiro octeto para identificar a rede. Os outros 3

octetos identificam o host e são usados livremente pelo administrador da rede. A
classe A atende às necessidades de redes de grande abrangência, constituídas de
poucas redes e com elevado número de estações, estando disponíveis 8 bits (o
bit mais significativo vale 0) para identificação das redes, e 24 bits para a
identificação das estações.
8
\\Classe B – utiliza somente os dois primeiros octetos para identificar a rede. Os

outros 2 octetos identificam o host e são para uso do administrador da rede. A
classe B representa redes intermediárias, com 16 bits para a identificação das
redes (os bits mais significativos valem 1 e 0), e 16 para as estações.
\\Classe C – utiliza somente os três primeiros octetos para identificar a rede. O

octeto restante identifica o host e pode ser usado pelo administrador da rede.
Atende tipicamente à faixa das redes locais. Como estas são bastante numerosas,
são reservados 24 bits para a identificação das redes (os três bits mais
significativos valem 1, 1 e 0), e apenas 8 bits para a identificação das estações.
O(s) bit(s) mais significativo(s) do primeiro octeto determina(m) a classe do

endereço e também quantos bits representam a porção correspondente à rede.
Endereços classe A
\\Faixa dos números das redes: 1.0.0.0 até 126.0.0.0;
\\Quantidade de endereços de hosts: 16.777.214.
Endereços classe B
\\Quantidade de endereços de hosts: 65.534.
Endereços classe C
\\Quantidade de endereços de hosts: 254.
Classes A, B e C são as classes mais comuns de endereço IP, mas endereços de

classes D e E estão também definidos. Endereços de classe D começam em
224.0.0.0 e são usados para multicast, enquanto endereços de classe E começam
em 240.0.0.0 e são reservados para propósitos experimentais.
Endereços especiais
\\RFC 1918 – Endereços privados:
\\10.0.0.1 10.255.255.254 (10/8 prefix)
\\172.16.0.1 172.31.255.254 (172.16/12 prefix)
\\192.168.0.1 192.168.255.254 (192.168/16 prefix)
\\Somente endereços IP públicos globais têm acesso à internet;
\\Empresas que usam endereços IP privados terão que usar servidor proxy para
traduzir endereços privados para públicos.
A RFC 1918 (Address Allocation for Private Internets) define as faixas de endereços
que somente podem ser usados em redes privadas, os ditos endereços privados.
Esses endereços não podem ser roteados na internet. Os endereços que podem ser
9 9
roteados são os demais endereços das classes A, B e C, denominados endereços
globais ou endereços públicos, que não podem ser repetidos dentro da internet. A
utilização dos endereços públicos é controlada pelo InterNIC.
Os endereços privados, como são usados no âmbito de uma organização, não precisam
ser únicos na internet, podendo ser repetidos de uma organização para outra. Assim,
cada organização tem liberdade para usar como quiser as faixas acima definidas,
sem a necessidade de obter permissão do InterNIC para isso. Por outro lado, esses
endereços não poderão ser usados para acesso à internet, sendo necessário fazer
uma tradução desses endereços privados para públicos através de um servidor
chamado Proxy Server, que faz a função Network Address Translation (NAT).
A utilização de endereços IP públicos no âmbito de uma organização é desencorajada

por causa da escassez de endereços IP e principalmente de segurança (vulnerável a
ataques de hackers). De maneira geral, podemos classificar os hosts que usam
endereços IP dentro de uma organização nas seguintes categorias:
1. Hosts que não precisam acessar a internet;
2. Hosts que precisam acessar um limitado conjunto de serviços da internet (e-mail,

FTP, www), que podem ser ajudados por gateways de aplicação;
3. Hosts que precisam de acesso irrestrito à internet, normalmente servidores

disponibilizados para a internet.
Os hosts das categorias 1 e 2 podem usar endereços privados, mas não os da

categoria 3.
Nos endereços privados relacionados acima, o prefixo indica o número de bits

reservados para identificar a rede, do total de 32 bits. O primeiro bloco é uma classe
A (10.0.0.0), o segundo bloco representa 16 classes B contíguas (todas as 16
classes têm os 12 bits de rede iguais) e o terceiro bloco representa 256 classes C
contíguas (todas têm os 16 bits de rede iguais).
Os bits que restam para hosts em cada bloco são denominados respectivamente de
“bloco de 24 bits”, “bloco de 20 bits” e “bloco de 16 bits”.
Roteamento
\\Roteamento é a transferência de informação da origem até o destino através de
uma rede.
Roteamento é a transferência de informação da fonte até o destino através de uma

rede. Ao longo do caminho, tipicamente teremos pelo menos um nó intermediário.
De acordo com esta definição, a função do roteador parece ser a mesma que a de
uma ponte (switch/bridge). A principal diferença entre ambos é que a ponte opera
10
na camada 2 (enlace de dados) do modelo OSI, enquanto que os roteadores operam

na camada 3 (rede). Assim, eles operam de maneiras diferentes, embora ambos
executem operações de comutação.
Origem Destino
Figura 1.5
Protocolos de transporte
\\Dois protocolos de comunicação fim-a-fim são definidos:
\\UDP – User Datagram Protocol;
\\TCP – Transmission Control Protocol.
Ambos são responsáveis pela utilização de múltiplas aplicações de redes entre duas
máquinas. A aplicação determina o protocolo que vai ser utilizado.
TCP (Transmission Control Protocol)

O Protocolo de Controle de Transmissão possui mecanismos de controle de fluxo.
Confiável, mantém a ordem de transmissão dos dados. O TCP é um protocolo
orientado a conexões, que permite a entrega sem erros de um fluxo de bytes
originário de uma determinada máquina em qualquer computador da inter-rede.
Esse protocolo fragmenta o fluxo de bytes de entrada em mensagens discretas, e
passa cada uma delas para a camada inter-redes. O TCP também cuida do controle
de fluxo, impedindo que um transmissor rápido sobrecarregue um receptor lento
com um volume de mensagens maior do que ele pode manipular.
UDP (User Datagram Protocol)

O Protocolo de Datagrama do Usuário não possui mecanismos de controle de fluxo e
não mantém a ordem de transmissão dos dados. É um protocolo sem conexão e não-
confiável, destinado a aplicações que não querem controle de fluxo nem de manutenção
da sequência de mensagens enviadas, e desejam fornecer seus próprios recursos para
isso. Ele também é amplamente utilizado em consultas e aplicações diretas do tipo
cliente/servidor com solicitação/resposta, nas quais a entrega imediata é mais
importante do que a entrega precisa, como a transmissão de dados de voz ou de vídeo.
11
Comunicação VoIP
\\O VoIP pode utilizar os protocolos de transporte UDP e TCP;
\\Ambiente ideal hoje:

\\VoIP + UDP + RTP/RTCP + QoS.
A comunicação entre dispositivos VoIP pode ser realizada utilizando qualquer um

dos protocolos de transporte (TCP ou UDP). Em aplicações de tempo real é
comumente utilizado o UDP.
Como o UDP não é numerado, não tem controle de sequência, como a aplicação vai
reconstituir a informação de voz no destino? Neste caso é necessário um protocolo
auxiliar que numere os pacotes para que os mesmos possam ser reconstituídos
corretamente no destino. Esta nova ferramenta é o Protocolo de Tempo Real (RTP),
que será visto adiante.
Evolução do VoIP
\\1995:
\\Em Israel, a empresa VocalTec lança o primeiro software comercial de VoIP.
\\1998:
\\Surgem os primeiros sistemas que integram VoIP e telefones convencionais,

disseminando a tecnologia;
\\Aparecem os primeiros padrões relacionados a VoIP.
\\Criados por:
\\Internet Engineering Task Force (IETF);
\\União Internacional de Telecomunicações (ITU).
\\Hoje:
\\VoIP difundido no mercado, de diversas formas: PC-PC, PC-telefonia,

telefonia-telefonia.
Nos anos 90, a voz era digitalizada e comprimida para então ser transmitida pela
rede. A qualidade era ruim e só era possível a transmissão entre dois computadores.
Como a partir desse período houve um grande desenvolvimento de redes de dados,

com ênfase no protocolo TCP/IP e no aparecimento dos gateways, então muitas
empresas passaram a desenvolver aplicativos para permitir o transporte de voz
através das redes de dados, tendo em vista o pouco consumo de banda para voz.
12
Em 1996 surge o primeiro protocolo de sinalização para estabelecimento de

chamadas de voz através de redes de pacotes, que foi o H.323 desenvolvido pelo
ITU, uma evolução do protocolo ISDN da telefonia.
As redes de nova geração que estão substituindo as redes de circuitos permitem o

transporte de aplicações de tempo real, entre elas a voz, com qualidade similar ao
celular. O protocolo de sinalização mais eficaz é o SIP, desenvolvido pelo IETF.
VoIP ≠ ToIP
\\VoIP (Voz sobre IP) versus ToIP (Telefonia sobre IP);
\\VoIP:
\\Refere-se às técnicas de empacotamento e transmissão de amostras de voz

sobre redes IP e a mecanismos de sinalização para estabelecer as chamadas.
\\Telefonia IP:
\\Refere-se à aplicação das tecnologias VoIP na transmissão e na sinalização,
com o oferecimento de um serviço similar ao serviço convencional de telefonia.
ToIP (Telefonia sobre IP)

É o serviço de telefonia funcionando sobre uma rede IP, portanto, utilizando
procedimentos e protocolos de VoIP. Isto significa que, além das características de
uma rede preparada para VoIP, em ToIP também são oferecidos os serviços
suplementares comuns em redes de telefonia, como chamada em espera, voicemail,
re-chamada, segunda linha, entre outros serviços.
Voice Over Internet Protocol (VoIP)

É a tecnologia que permite o estabelecimento de chamadas e transporte da voz utilizando
a rede IP. Além disso, diz-se que uma rede está preparada para oferecer o serviço de VoIP
quando ela possui o tratamento adequado para tal, desde permitir este tipo de tráfego
através de seus firewalls até utilizar práticas de QoS para garantir a qualidade das ligações.
Vantagens e desvantagens do VoIP

Vantagens:
\\Custos reduzidos nas comunicações;
\\Proteção ao seu investimento;
\\Possibilidade de utilizar a infraestrutura existente;
\\Infraestrutura simplificada;
\\Portabilidade;
\\Funcionalidades acrescidas.
13
Desvantagens:
\\Alto custo inicial (para redes totalmente IP);
\\Aquisição de nova aparelhagem;
\\Modernização da aparelhagem já existente;
\\Escassez de mão de obra especializada;
\\Limitação da rede / problemas relacionados a QoS.
Benefícios do VoIP
\\Custos reduzidos nas comunicações;
\\Alto retorno sobre o investimento (ROI);
\\Infraestrutura simplificada;
\\Portabilidade;
\\Funcionalidades acrescidas;
\\Mão de obra especializada;
\\Limitações da rede / QoS;
\\Segurança*;
\\Integração com a PSTN*.
* Itens não abordados neste curso
Custos reduzidos nas comunicações

O serviço telefônico VoIP, quando bem planejado, tende a ser mais econômico que
os serviços telefônicos tradicionais, liberando o usuário de utilizar as operadoras
telefônicas tradicionais.
Alto retorno sobre o investimento (ROI)

Os PBX IP são baseados em softwares, permitindo atualização com novos protocolos
e funcionalidades. Há a possibilidade de utilizar a infraestrutura existente na
empresa tanto de rede quanto de telefonia, utilizando os telefones, aparelhos de fax,
o cabeamento e até a central em uso podem ser aproveitados para o serviço VOIP.
Infraestrutura simplificada
Todos os serviços de comunicação (telefone, fax e internet) estão centralizados numa
única infraestrutura. A voz correrá na infraestrutura de dados, ou seja, na rede IP.
14
Portabilidade

Não importa onde você esteja. Desde que haja uma rede IP conectada à internet,
você sempre poderá efetuar ligações através do seu ramal utilizando o softfone
instalado no seu computador, também é possível utilizar telefones IP pequenos,
leves e fáceis de transportar.
Funcionalidades acrescidas
Por ser praticamente baseada em software, VoIP possibilita a implementação de
funcionalidades que seriam difíceis ou impossíveis em redes tradicionais de telefone:
\\Permite a integração telefônica de instalações separadas fisicamente.;
\\Um telefone IP não está limitado em termos de numeração referente à

localização geográfica nem a nenhum prefixo, o que permite total mobilidade;
\\Ao receber uma chamada, esta é imediatamente redirecionada para o telefone

VoIP, onde quer que ele esteja ligado na rede. Qualquer localidade onde exista
internet pode receber e fazer chamadas de seu telefone VoIP, como se você
estivesse no escritório;
\\Agentes de call center que utilizam telefones VoIP podem trabalhar de qualquer
local que tenha uma boa conexão com a internet.
Mão de obra especializada

Ainda existe alguma dificuldade para encontrar no mercado um profissional que
entenda tanto de telefonia quanto de redes IP, e que também conheça os protocolos
de VoIP. Geralmente, os profissionais de telefonia demonstram resistência na
absorção do conhecimento de redes IP. De outro lado, os profissionais de redes
também demonstram certa despreocupação com assuntos relacionados às redes
tradicionais de telefonia. Não é fácil encontrar uma pessoa que se interesse por
ambos os mundos.
Em relação à mão de obra qualificada, as novas gerações cada vez mais estão
conectadas com o conhecimento de computadores e redes, facilitando o aprendizado
da telefonia IP, o que é diferente da telefonia convencional, que nunca teve seu
conhecimento divulgado e massificado.
Limitações da rede / QoS

Esta é uma característica que pode ser encontrada em implementações que não
tiveram o devido cuidado com a preparação da infraestrutura de rede. Para uma
rede de dados suportar o transporte de voz é necessário possuir qualidade para tal.
As desvantagens estão sendo reduzidas. A tradicional interface E-1 de 32 canais, com

uma taxa de transmissão de 2 Mbits/seg, que nos anos 90 custava cerca de dois mil
dólares, hoje custa em torno de 700 dólares. Já uma interface Ethernet de 10 Gbits/
seg custa entre mil e dois mil dólares. Em um E-1 é possível transportar 30 canais
de voz, enquanto que em uma interface 10 Gbits/seg são milhares de chamadas.
15
A limitação da rede está rapidamente sendo ultrapassada, tendo em vista que
aumenta a necessidade de fazer um upgrade nas redes ou até substituir os modelos

mais antigos. As novas soluções são aderentes aos serviços de VoIP e Telefonia IP e
já possuem QoS nativo.
Segurança
Hoje em dia, é uma das questões mais discutidas na comunidade VoIP. Alguns
ataques específicos no contexto da tecnologia VoIP:
\\Call Hijack – sequestro de chamada, que ocorre quando o intruso consegue

desviar uma chamada e se fazer passar por um dos participantes dela;
\\SIP Flood – negação de serviço, que consiste no envio de uma grande

quantidade de mensagens SIP forjadas para um componente da rede VoIP;
\\SIP-Cancel/Bye DoS – forma de negação de serviço em que o intruso simula

uma mensagem de sinalização SIP do tipo cancel ou bye, evitando que
chamadas sejam iniciadas ou causando a interrupção das ligações em
andamento;
\\Manipulação de registros – forma de spoofing na qual um usuário se registra como

outro, permitindo o recebimento ou realização de chamadas de outros usuários.
Integração com a PSTN

Uma das possibilidades de integrar o VoIP a PSTN (Public Switched Telephony
Network) é através da utilização do Asterisk.
As redes VoIP podem se comunicar de maneiras distintas, utilizando os se-guintes

protocolos:
\\ SIP (Session Initiation Protocol);
\\ H.323;
\\ IAX (Inter-Asterisk eXchange).
Pode-se utilizar o Asterisk como um gateway, para que redes VoIP com comunicação
distinta possam se entender.
16
Existem três formas de comunicação via VoIP

\\VoIP via softphone:
\\Utilizando um software adequado, um computador pode ser utilizado
facilmente para a comunicação via VoIP.
\\VoIP via ATA:

\\Consiste em usar um Adaptador de Telefone Analógico (ATA);
\\Exemplo: pluga-se um telefone comum ao ATA e este ao computador,
permitindo assim o uso do sistema VoIP.
\\VoIP via telefones IP:

\\Possuem a mesma aparência de um telefone comum, mas utilizam
conectores RJ-45 Ethernet;
\\Também precisam de energia para funcionar.
VoIP via Softphone

Forma de comunicação VoIP que utiliza softphone, isto é, software que emula o
funcionamento 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 comunicação por voz sobre a internet.
VoIP via ATA

O ATA (Analog Telephone Adapter) 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 PoE (Power over Ethernet).
Hoje existem no mercado ATAs para 2, 4, 8, 16, 24 e 30 aparelhos telefônicos.
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
aprovisionamento já permitem que os telefones equipados com estes 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.
17
Telefonia tradicional X telefonia IP
\\Telefonia tradicional:
\\PSTN: rede hierárquica;
\\Baseada em grandes centrais telefônicas ligadas entre si de forma
hierárquica;
\\Os terminais não possuem inteligência;
\\O endereçamento depende da região de abrangência da rede;
\\O codec utilizado nas redes digitais era o G.711;
\\Atrasos são muito controlados, com cerca de 40 ms.
\\Telefonia IP:
\\Rede não hierárquica (sob a óptica do serviço de voz);
\\Os terminais são diferentes dos usados na telefonia fixa;
\\O telefone IP pode ser um software executando em um computador ou
hardware dedicado.
\\Pacotes de voz precisam passar por filas;
\\Jitter e perdas de pacotes comprometem a qualidade da ligação;
\\Mecanismos de QoS são desejáveis.
A rede de telefonia é organizada hierarquicamente, onde o endereçamento dos

telefones (o número) depende da região geográfica. Na telefonia tradicional, o canal
de voz é estabelecido simultaneamente com a etapa de sinalização. Os terminais
telefônicos possuíam pouca inteligência; RDSI, os mais avançados, eram muito caros
e de baixa aceitação. Esta tecnologia utiliza o codec G.711 como padrão para áudio,
o que para telefonia convencional é excelente, pois possui desempenho de 64 Kbps
na taxa de transmissão. Fisicamente para o canal de voz é utilizado um par de fios
metálicos, entre dois pontos extremos. Neste meio físico o atraso da voz raramente
ultrapassa 30m/seg; os atrasos superiores a este valor começam a apresentar eco.
A rede ToIP não é hierárquica. Além disso, o número de telefone não está associado
a uma localização geográfica. Os terminais IP para voz são inteligentes e o usuário
pode ser localizado em qualquer tempo e em qualquer lugar, com custos cada vez
mais baixos. Os terminais podem ser implementados em hardware ou em software,
fazendo com que o seu computador funcione como um telefone.
Em VoIP, só os atrasos fixos, inseridos na origem e destino, são da ordem

aproximada de 90m/seg. Existem os roteadores de meio de caminho com suas filas
e congestionamentos, que aumentam muito o atraso total entre origem e destino.
Além disso, a variação de atraso (jitter) implica a utilização de buffers que inserem
mais atrasos nos pacotes. Para que a qualidade das ligações seja mantida é preciso
tomar providências relativas a QoS.
18
roteador
Voz analógica
sobre par trançado
PBX
voz pacotizada
assinante
Telefone IP
Rede comutada
Internet Internet
(Multiplexação TDM)
PBX
Voz analógica
sobre par trançado voz pacotizada
assinante
roteador
Telefone IP
Figura 1.6
Na telefonia TDM, cada canal ou circuito fica alocado para uma chamada, com uma
velocidade máxima de 64 Kbits/seg. Caso ocorra uma ociosidade do canal durante a
chamada, ele não poderá ser compartilhado com outra chamada. Na telefonia VoIP,
não existem os conceito de canal e circuito de transporte de pacote.
Sua velocidade não está limitada a 64 Kibts/seg, onde a velocidade permitida pela
tecnologia pode chegar a 10 Gbits/seg se for uma rede Ethernet.
Na telefonia tradicional, a voz tem uma via expressa, sem congestionamentos. Em

VoIP, a voz vai disputar espaço com todas as outras aplicações que trafegam na
rede, como outros pacotes de voz, de dados, de gerência de rede etc. Se não houver
um tratamento adequado para os pacotes de voz, eles poderão ser perdidos ou
chegar com atrasos ou fora de ordem. Para resolver estes problemas, as redes de
pacotes devem oferecer tratamento especial para os pacotes de voz. As ferramentas
que permitem esse tratamento são os protocolos de qualidade de serviço (QoS),
protocolos RTP e RTCP, entre outros, sem os quais uma rede de pacotes é
incompatível para o transporte de voz.
Imagine uma reunião: para que haja uma comunicação efetiva entre os
participantes, é necessário que os participantes se façam entender, dominando um
mesmo idioma e vocabulário. Sem o estabelecimento de uma linguagem comum,
não haverá entendimento entre os participantes da conversa. Imaginemos agora a
mesma situação, só que com computadores distribuídos em rede, em vez de
pessoas. Nesse caso, além da infraestrutura de redes, é necessária uma linguagem
padronizada para que haja uma comunicação efetiva entre os computadores.
Para garantir que os computadores “falem a mesma língua”, existem diversos

padrões e protocolos que regem essa comunicação, que são objetos de estudo de
19
diversas organizações que trabalham em sua manutenção e desenvolvimento.
Dentre estas organizações, as mais notáveis em relação a padrões de

videoconferência são: ITU-T, IETF e MPEG.
Padronização
\\Organizações que estabelecem normas e protocolos:
\\Telecomunication Standardization Sector do International Telecommunications
Union – ITU-T;
\\Internet Engineering Task Force – IETF.
\\Os padrões ITU-T de videoconferência exigem dos fabricantes a implementação

de um conjunto mínimo de padrões de compressão de áudio e vídeo;
\\Há padrões opcionais que também podem ser utilizados nos sistemas
de videoconferência;
\\Além disso, cada fabricante pode adicionar padrões proprietários às suas soluções:
\\Conjunto mínimo + padrões opcionais + padrões proprietários.
A International Telecommunication Union (ITU) atua no desenvolvimento de padrões

reconhecidos internacionalmente, no intuito de viabilizar a interação entre
computadores e outros equipamentos de telecomunicações. Esse órgão internacional,
responsável por estabelecer recomendações para telecomunicações, divide-se em
grupos de estudo onde cada grupo é incumbido de investigar um conjunto de
questões, cujos resultados definem as recomendações estabelecidas pela ITU-T.
Um desses grupos, responsável pela família ITU H.3xx, é responsável por

estabelecer recomendações para colaboração de dados e videoconferência, ou seja,
pela formalização de padrões para comunicação multimídia sobre redes IP.
A Internet Engineering Task Force (IETF) é uma comunidade internacional aberta,

constituída de administradores, operadores e pesquisadores concentrados em
padronizar a evolução da arquitetura da internet e a operação da rede. A IETF está
aberta a qualquer indivíduo interessado. O trabalho técnico da IETF também é
realizado em grupos de estudo, organizados por tópicos de interesse em diversas
áreas, como distribuição, transporte e segurança.
Outra preocupação de padronização diz respeito às estratégias de compressão e

transmissão de dados multimídia. Hoje em dia, existem cada vez mais aplicações
que envolvem áudio, vídeo e dados à disposição de um público distribuído e
crescente. A explosão da internet na década de 1990 levou milhares de usuários a
utilizarem esses serviços com intuito profissional, comercial ou doméstico. Assim, a
internet agrega um volume de dados multimídia cada vez maior, o que eleva a
demanda de banda e a necessidade de estratégias eficientes para transmissão
desses dados. Nesse sentido, uma organização aborda mecanismos para codificação
e transmissão de áudio e vídeo.
20
Padrões de videoconferência

Os padrões de videoconferência especificam um conjunto mínimo de padrões ITU-T
de compressão de áudio e vídeo, que devem ser implementados para que um
sistema seja homologado conforme este padrão. E além deste conjunto mínimo,
existem os padrões opcionais, que normalmente são padrões mais complexos, como
o H.264 para vídeo.
Muitos sistemas ainda incluem métodos proprietários de codificação de vídeo e

áudio. Por serem métodos proprietários, muitas vezes apenas o próprio fabricante
sabe como o método funciona. Outros sistemas dificilmente terão suporte a esses
métodos, o que impossibilita a interoperação entre os sistemas. Apesar disso,
métodos proprietários podem ser utilizados como um diferencial quando um
fabricante desenvolve um método novo ou otimiza um método de codificação. Nesse
caso, para utilizar tal padrão o cliente deverá possuir equipamentos do mesmo
fabricante, em todas as pontas.
Princípios de codificação de áudio

\\PCM (Pulse Code Modulation);
\\Como converter áudio analógico em digital?

\\Como minimizar o erro de quantização (duas formas)?
\\Que taxa de amostragem deve ser utilizada, supondo que:
\\Frequência da voz humana: 20 Hz – 6.000 Hz (banda de 4 kHz fornece
inteligibilidade perfeita).
\\Frequência do ouvido humano: 20 Hz – 20.000 Hz;
\\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 analógicos para sinais digitais?
Uma técnica bastante utilizada em telefonia é a técnica PCM (Pulse Code

Modulation). O PCM analisa o sinal analógico em instantes uniformes de tempo,
obtém a magnitude do sinal nestes instantes e representa esta magnitude de forma
numérica (de forma binária).
21
A imagem abaixo mostra um exemplo de um sinal de áudio analógico que será
convertido para digital:
Figura 1.7
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
001
Figura 1.8
000
011
100
011
011
101
110
111
O eixo y mostra uma escala com um número para cada linha horizontal. Este
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 deste valor.
Ele usa então o símbolo associado a esta 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 que a onda passa a ser representada após ser convertida para o
formato digital pelo PCM.
22
Cada valor obtido pelo PCM ao longo do tempo é chamado de uma amostra do sinal,

e por isso este processo é chamado de amostragem da onda sonora. A definição do
número de amostras obtidas é um parâmetro muito importante do processo, que
influencia diretamente 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 este 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 sinal. Este 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 6000 Hz, aproximadamente, entretanto, limitando em 4 kHz a conversa fica
totalmente inteligível, pois 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. Este 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 telefonia se trabalha com 8 bits por amostra.
\\Compansão do sinal;
\\Voz pode variar 10.000 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, representada na figura a seguir. Este processo é necessário, pois a amplitude
dos sinais sonoros pode variar muito. A voz humana pode variar 10.000 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).
23
No processo de compansão, os sinais mais fracos são elevados e os mais fortes são
reduzidos, 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 é amplificada 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 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).
Vs
Compansão segundo lei A ou μ (analógico)
Usar 13 bits e comprimir segundo lei A ou μ (digital)
Ve Figura 1.9
Mais informações:
\\Tutorialde VoIP disponível em:

www.teleco.com.br/tutoriais/tutorialtelip/pagina_1.asp
\\Resumo/Comparação de diversos codificadores de vídeo:

en.wikipedia.org/wiki/Comparison_of_audio_codecs
Codificação da mídia de voz

\\Técnicas:
\\Codificação de forma de onda;

\\Paramétrica;
\\Híbrida.
\\Comparação entre técnicas de codificação;
\\Codificadores de forma de onda:

\\Melhor qualidade, menor atraso, maior taxa de bits.
\\Vocoders:
\\Menor taxa de bits, pior qualidade, grande atraso e jitter.
\\ Codificadores híbridos:
\\Boa taxa de bits, boa qualidade, atraso e jitter razoáveis.
24
Codec

\\Codec é uma abreviação de codificador-decodificador;
\\Codecs especificam como os sinais analógicos da voz devem ser codificados

em dados digitais;
\\Codecs permitem compressão dos dados;
\\Grande parte dos padrões usa técnicas baseadas na codificação da forma de

onda (PCM – Pulse Code Modulation).
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, compreendendo 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 transmitida seria perdida; já em uma amostragem maior,
nenhuma informação adicional seria acrescentada. Esta técnica, também conhecida
como Pulse Code Modulation (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 transformaçã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.
Codificação de forma de onda

\\Na origem: conversão A/D -> Analógico-Digital;
\\No destino: conversão D/A -> Digital-Analógico;
\\O esquema mais utilizado é o Adaptive Differential Pulse Code Modulation

(ADPCM);
\\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
25
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
\\Também denominados vocoders (voice coders):
\\ A classe de vocoders mais utilizada é a dos vocoders LPC (Linear
Predictive Coding);
\\Utilizam, no decodificador, um modelo de produção da voz, onde os
parâmetros são estimados e transmitidos pelo codificador em intervalos de
tempo entre 10 e 30 ms.
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).
A classe de codificadores paramétricos mais utilizada é a dos vocoders LPC (Linear

Predictive Coding). Os vocoders conseguem codificar os sinais de voz a taxas de no
máximo cerca de 2 kbps, mas com qualidade entre ruim e regular.
Codificação híbrida
\\Combinam características dos codificadores de forma de onda e dos vocoders;
\\ A maioria dos codificadores híbridos utiliza o modelo de codificação Code

Excited Linear Predictive (CELP).
Usa conceitos das duas outras formas de codificação (codificação paramétrica e

codificação em forma de onda), procurando um balanço entre qualidade e taxa de
compressão. Os codificadores 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.
26
Em uma rede de pacote, onde os pacotes de voz podem sofrer grandes delays, a

escolha do codec em função do atraso do mesmo 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:
\\G.711;
\\G.729;
\\G.723.1;
\\iLBC.
A tabela abaixo 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 Taxa de transmissão Latência Qualidade

frequência
G.711 300 Hz – 3.4 kHz 64 kbit/s <1 Excelente
G.722 50 Hz – 7 kHz 48, 56 ou 64 kbit/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
G.726 8 kGz 16 – 40 kbits/s 60 Boa a

razoável
G.728 300 Hz – 3.4 kHz 16 kbit/s <2 Boa
G.729 8 kHz 8 kbits/s 25 – 35 Boa
ILBC 300 Hz – 3.4 kHz 13,33 ou 15,20 kbit/s 30 – 20 Boa Tabela 1.1
O 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 este codec não
comprime, sendo utilizado em transmissão de fax.
27
O padrão G.729 possui taxa de 8 Kbits/seg e é muito utilizado no mercado. É um
codec ITU com a necessidade de compra de licença. Existem as versões G729a,

menos complexa que a G729, e a versão G729b, com capacidade de inserir ruído
de conforto nas ligações que utilizam VAD (detecção de atividade de voz).
O padrão G 723.1 possui taxas menores que o G.729, é um codec ITU e também
necessita de pagamento de licença. Possui taxas de 6,3 ou 5,3 Kbits/seg e seu
atraso é da ordem de 37,5 mseg.
O codec iLBC tem fonte aberta, sem exigência de pagamento de licença, sendo uma
boa opção de solução de fonte aberta. Sua taxa é da ordem de 13,3 Kbits/seg.
G.711
\\Codificador padrão ITU-T de larga aplicação;
\\ Representa os sinais de voz usando o formato PCM;
\\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 3400 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
é utilizado 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 duplicando o passo de quantização a cada vez que a intensidade do sinal
era duplicada; deste modo obteve-se uma constante.
G.729
\\Padrão ITU-T para codificação de sinais de voz a uma taxa de 8 kbps, com
quadros de 2 ou 8 bytes a cada 10 ms;
\\Utiliza o algoritmo Conjugate Structure Algebraic Code Excited Linear

Prediction (CS-ACELP), baseado no modelo de codificação Code Excited
Linear Prediction (CELP);
\\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
CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Prediction), que é
baseado no modelo de codificação CELP. Ele é projetado para operar com o sinal de
28
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
\\Padrão ITU-T para taxas de bits muito baixas (5,3 ou 6,3 kbps), desenvolvido
para uso em telefonia por redes de pacotes;
\\Para taxas de 5,3 kbps, usa o algoritmo ACELP (Algebraic Code Excited
Linear Prediction);
\\Para taxas de 6,3 kbps, usa o algoritmo MP-MLQ (Multipulse Maximum

Likelihood Quantization).
O codificador G.723.1 tem duas taxas de bits associadas a ele, de 5,3 e 6,3 kbps.
Ele codifica sinais de voz quadro a quadro usando codificação preditiva linear
baseada em análise por síntese (CPLbAS). A codificação em taxa alta (6,3 kbps) usa
um modelo MP-MLQ (Multipulse Maximum Likelihood Quantization) para gerar o
sinal de excitação, enquanto a codificação em taxa baixa (5,3 kbps) usa um modelo
ACELP (Algebraic Code Excited Linear Prediction). O tamanho dos quadros é de 30
ms (ou 240 amostras).
O codificador G.723.1 é projetado para operar com o sinal de voz de entrada já convertido
para o formato PCM uniforme, 16 bits/amostra e taxa de amostragem de 8 kHz.
iLBC
\\Internet Low Bit Rate Codec (iLBC) se encontra em caráter experimental, a ser
padronizado pela IETF;
\\Desenvolvido para propiciar comunicação robusta em VoIP, com tolerância a

perdas e recuperação de erros;
29
\\Baseado em predição linear; não usa o modelo CELP.
\\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 tamanhos operam de maneira similar. A descrição
do algoritmo resulta em um sistema de codificaçã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 este codificador estão nas formas de comunicação em tempo real,
como telefonia, videoconferência, áudio e envio de mensagens.
Arquitetura VoIP
Zona 1 GK GK
Zona 2
TM MCU MCU TM
GC GC
Tel IP Tel IP
Rede IP
GW GW
...
...
PABX STFC PABX
... ...
Figura 1.10
Visão geral dos diversos elementos que podem interagir dentro da arquitetura VoIP:
\\Gatekeeper (GK) – permite o controle centralizado do sistema;
30
\\Private Branch eXchange (PBX) – centro de distribuição telefônica pertencente a

uma empresa que não inclui como sua atividade o fornecimento de serviços
telefônicos ao público em geral;
\\Unidades de Controle Multiponto (MCU) – permitem o estabelecimento de

conferências entre três ou mais pontos finais;
\\Gateway (GW) – necessário quando se deseja estabelecer comunicação entre

terminais em diferentes tipos de redes.
Projetos VoIP no Brasil

\\Projeto VoIP4All:
\\voip4all.rnp.br;
\\fone@RNP.
\\Aproximadamente 100 instituições conectadas:

\\www.rnp.br/voip.
Voip4All
Este projeto criou meios para que instituições federais, universidades, centros de
educação tecnológica e unidades de pesquisa possam implantar uma infraestrutura
de suporte a VoIP.
Fone@RNP
Serviço VoIP da RNP que evoluiu do projeto VoIP4All. Oferece comunicação por voz
utilizando a rede Ipê para pessoas em diversas instituições brasileiras de ensino e
pesquisa, usando:
\\Servidores;
\\Soluções de código aberto;
\\ Computadores;
\\ Telefones IP;
\\ Aparelhos telefônicos em seus departamentos.
31
A ilustração abaixo é referente à estrutura básica de uma instituição participante
do fone@RNP.
Terminal H.323
Ambiente H.323
Postgre SQL
GnuGK
Au
Consulta
ten
Gatekeeper H.323
+
tic
Apache para
aç
VQCDR Server
ão
para coleta de CDR disponibilização
de c formaç nto
e
ade
de estatísticas
bilid es
co
e
õ
de i zenam
+
nta
VQOpenPhone
Nagios para
bil
Suporte ao envio de
onta
ida
gerência do serviço
a
CDR com informação
Arm
n
de
de qualidade Asterisk
Gateway SIP/H.323
Gateway VOIP/PSTN
Consulta
PSTN LDAP
FreeRadius
Diretório para identificação
a de e autenticação e usuários
lid
Autenticação e contabilidade
abi
nt
Cliente SIP co
e
o
a çã
Ambiente SIP ic
ent
Aut Usuário que estabelece
sua conexão atrás
de um firewall
SER
Proxy SIP
VPN Server
Cliente SIP
Firewall
Figura 1.11
Softwares utilizados no service fone@RNP:
\\ GnuGK;
\\ OpenSER;
\\ Asterisk (gateway SIP/H323, gateway VoIP/PSTN);
\\ FreeRADIUS;
\\ PostgreSQL;
\\ Apache;
\\ Nagios;
\\ LDAP;
\\ Clientes SIP/H.323.
32
1
Roteiro de Atividades
Tópicos e conceitos
\\Instalação e configuração dos clientes VoIP X-Lite, Telefone IP e ATA;
\\Análise do tráfego da rede com ferramenta de captura de tráfego.
Competências técnicas desenvolvidas

\\Aprendizado sobre as funcionalidades dos clientes X-Lite, Telefone IP e ATA;
\\Identificação do tráfego da rede TCP/IP.
Tempo previsto para as atividades

\\1 hora a 1h30 minutos (trabalho em grupo).
Preparando o ambiente
Antes do início das atividades, o instrutor irá iniciar a máquina virtual que contém o
software Asterisk e efetuar dois passos importantes para estabelecer usuário e senha
de acesso para a máquina virtual:
\\Usuário = root;
\\Senha = voip.
Passo 1: Confirmar o endereço IP da máquina virtual com o comando:
# ifconfig
Passo 2: Editar o arquivo sip.conf que está localizado no diretório /etc/asterisk/,

em [general].
33
A linha bindaddr=0.0.0.0 deverá ser alterada para:
bindaddr=ip_da_máquina_ virtual
Inicie o Asterisk com o comando:
# asterisk –vvvv &
Atividade 1 – Instalando o cliente X-Lite
Passo 1: no ambiente Windows, execute o aplicativo localizado no desktop e instale

o cliente X-Lite. O aplicativo também poderá ser encontrado no site do fabricante:
www.counterpath.com/x-lite.html
Figura 1.12
Não há necessidade de reiniciar o sistema.
Atividade 2 – Configurando o X-Lite
Passo 1: 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.
34
Caso seja a primeira vez que você esteja configurando, este passo não é necessário.

Figura 1.13
Passo 2: configure a sua conta de acordo com o plano de ramais. Substitua o XX

pelo número da sua estação. A senha para autenticação no servidor é voip, devendo
ser inserida no campo Password.
Figura 1.14
35
Se a configuração da conta foi efetuada corretamente, a mensagem Ready será
exibida na tela do X-Lite, conforme ilustra a figura seguinte.
Figura 1.15
Atividade 3 – Configurando o Telefone IP
Passo 1: 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.16
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.17
36
Passo 2: clique no link Lines. Nesta 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:
Figura 1.18
A Linha 1 será utilizada configurando apenas alguns dos campos existentes nas
sessões Identification 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 XX pelo
número da sua estação.
Passo 3: para finalizar , clique no botão Submit e aguarde o telefone ser reiniciado.
Em seguida, o telefone está pronto para ser utilizado.
Atividade 4 – Configurando o ATA
Passo 1: precisamos do IP do adaptador. Para descobrir o IP recebido pelo

adaptador, ligue-o a um telefone convencional e digite **** (quatro asteriscos), e em
seguida digite 110#. Uma mensagem com o número do IP será anunciada.
Passo 2: acesse no seu browser o endereço http://<IP ANUNCIADO PELA

MENSAGEM>
37
Passo 3: no canto superior direito da página abaixo clique em Admin Login:
Figura 1.19
Passo 4: na página seguinte clique em Line 1:
Figura 1.20
Passo 5: na página mostrada na próxima figura configure apenas os parâmetros abaixo:
\\Proxy: IP fornecido pelo instrutor;
\\Display Name: entre com seu nome completo;
\\User ID: 30XX;
\\Password: voip;
\\Register Expires: 3600.
Lembre-se de substituir o XX pelo número da sua estação.
A figura abaixo apresenta como deve ficar a configuração do seu adaptador: Figura 1.21
38
Passo 6: clique no botão Save Settings.

Atividade 5 – Efetuando chamadas com ATA, Telefone IP e X-Lite
Passo 1: efetue chamadas entre os três clientes. Lembrando que o X-Lite deve estar
configurado com o ramal 10XX, o Telefone IP com o ramal 20XX e o ATA com o
ramal 30XX.
Este passo deverá ser realizado em dupla, onde os integrantes da dupla efetuarão
chamadas entre si.
Atividade 6 – Verificando codecs de áudio
Esta atividade tem como finalidade a observação da importância dos codecs nos clientes.
X-Lite:
Passo 1: clique com o botão direito no cliente e acesse a opção Options; na guia
lateral selecione a opção Advanced, desative e ative os codecs de áudio e efetue
chamadas com codecs desabilitados, anotando as suas observações.
Telefone IP:
Passo 1: acesse no seu browser o endereço http://<IP DO TELEFONE>. Em

seguida, na página apresentada abaixo clique no link General:
Figura 1.22
39
Na página abaixo, clique em Audio Processing:
Figura 1.23
40
Em seguida troque a ordem dos codecs de áudio apresentados na página abaixo,

clique em Submit, espere o telefone reiniciar e efetue chamadas com todos os
codecs, anotando as suas observações.
Figura 1.24
ATA
Passo 1: acesse no seu browser o endereço http://<IP DO ATA>. Em seguida, na

página apresentada abaixo clique no link Line 1:
Figura 1.25
41
Passo 2: na parte de baixo da página troque os codecs, efetue chamadas com todos
os codecs e anote as suas observações.
Figura 1.26
42
Atividade 7 – Conhecendo o Wireshark

Passo 1: inicialize o software Wireshark instalado no desktop. Observe as opções
destacadas na imagem abaixo.
Figura 1.27
Passo 2: escolha a interface de rede com a qual iniciaremos a captura; para isso,
selecione o botão List the available capture interfaces. A interface com a qual
trabalharemos deverá apresentar uma contagem crescente de pacotes, conforme
destacado na imagem a seguir.
Passo 3: conhecendo as opções de configuração da interface de rede.
Figura 1.28
43
Figura 1.29
Figura 1.30
Atividade 8 – Efetuando capturas com Wireshark
Inicie a captura de pacotes com a interface em modo promíscuo, e logo depois inicie
sem ativar o modo promíscuo. Descreva suas observações.
44
Com a interface em modo promíscuo, inicie a captura de pacotes e observe o campo

Protocol. Após exibir os protocolos TCP e UDP, pare a captura e observe os detalhes
na tela de Árvore de protocolos. Navegue e veja as características do protocolo TCP
e do protocolo UDP.
Figura 1.31
Figura 1.32
Complete a tabela abaixo conforme os dados obtidos na captura:
Pacote TCP Pacote UDP
No campo “Ethernet Src Src

II” informe:
Dst Dst
MAC e “IG bit”
No campo “Internet Version Version

Protocol”
Header length Header length
Total length Total length
Source Destination
Tabela 1.2
Do pacote TCP: Transmission Control Protocol
Source Port Destination Port Flags
Do pacote UDP: User Datagram Protocol
Source Port Destination Port Length
Data TCP UDP

Tabela 1.3
45
Com os dados obtidos, podemos observar algumas diferenças entre os pacotes TCP
e UDP. Liste-as e comente.
Atividade 9 – Capturando pacotes na rede
Para exemplificar a interação dos protocolos e o processo de encapsulamento,

vamos analisar um quadro capturado numa rede local Ethernet, durante uma sessão
de um host com um servidor web que usa o protocolo HTTP de aplicação e o
protocolo TCP de transporte. Neste caso, ambos estão na mesma rede local. O
programa utilizado para isso é o analisador de rede Wireshark.
Wireshark pode ser obtido em www.wireshark.org.
A figura a seguir mostra a tela principal do Wireshark. Na parte superior estão os

menus suspensos e logo abaixo a barra de ferramentas. Para abrir o arquivo de
captura chamado Atividade1.cap utilizamos o ícone da barra de ferramentas que
representa uma pasta (sexto da esquerda para a direita). Para esta análise
selecionamos o pacote no 258, que foi enviado do servidor web para o host do usuário.
Figura 1.33
Quadro capturado
em rede local
Ethernet
46
Na janela inferior temos o conteúdo total do pacote, representado na forma

hexadecimal. Na janela imediatamente acima estão representadas as diversas
camadas de protocolos (de baixo para cima), a saber:
\\Camada física;
\\Camada de enlace de dados;
\\Camada de rede;
\\Camada de transporte.
Cada camada, quando selecionada, faz com que os bytes correspondentes fiquem
destacados na janela inferior.
Usando o Wireshark:
1. Determine o tamanho do cabeçalho do protocolo IP:
2. Determine o tamanho do cabeçalho do protocolo TCP e o tamanho dos dados

da aplicação:
3. Finalmente, faça uma verificação do tamanho total do quadro, somando todos

os campos:
47
48
2
Protocolo SIP
►► Sumário
Protocolo de iniciação de sessão – SIP . . . . . . . . . . . . . . . 51
Objetivos básicos do protocolo SIP. . . . . . . . . . . . . . . . . 51
Extensões ao protocolo SIP . . . . . . . . . . . . . . . . . . . 52
Características do protocolo SIP . . . . . . . . . . . . . . . . . . 53
Elementos de uma rede SIP. . . . . . . . . . . . . . . . . . . 54
Servidor Proxy . . . . . . . . . . . . . . . . . . . . . . . . 56
Servidor Stateful . . . . . . . . . . . . . . . . . . . . . . . 57
Servidor Stateless . . . . . . . . . . . . . . . . . . . . . . . 57
Utilização do servidor proxy . . . . . . . . . . . . . . . . . . . 58
Servidor de redirecionamento (Redirect Server) . . . . . . . . . . . . 58
Servidor de registro (Register Server). . . . . . . . . . . . . . . . 59
SIP URI. . . . . . . . . . . . . . . . . . . . . . . . . . 60
Mensagens SIP . . . . . . . . . . . . . . . . . . . . . . . . 61
Exemplo de SIP Request. . . . . . . . . . . . . . . . . . . . 64
Mensagem de resposta (SIP Response). . . . . . . . . . . . . . . 64
Exemplo de SIP Response. . . . . . . . . . . . . . . . . . . . 67
Protocolo SDP . . . . . . . . . . . . . . . . . . . . . . . . 71
Sessões SDP . . . . . . . . . . . . . . . . . . . . . . . . 72
Exemplo de Sessão SDP . . . . . . . . . . . . . . . . . . . . 75
Modos de comunicação SIP. . . . . . . . . . . . . . . . . . . 75
Comunicação peer-to-peer . . . . . . . . . . . . . . . . . . . . 76
Comunicação via proxy. . . . . . . . . . . . . . . . . . . . . 77
Transações e diálogos SIP . . . . . . . . . . . . . . . . . . . . 78
Cenários SIP. . . . . . . . . . . . . . . . . . . . . . . . . 79
SIP Registration . . . . . . . . . . . . . . . . . . . . . . . 80
Session Invitation. . . . . . . . . . . . . . . . . . . . . . . 81
Session Termination . . . . . . . . . . . . . . . . . . . . . . 82
Instant Messages (IM). . . . . . . . . . . . . . . . . . . . . 83
49
Atividade 1 – Instalando o OpenSER. . . . . . . . . . . . . . . . 85

Atividade 2 – Captura e identificação da troca de mensagens entre os
clientes SIP e o OpenSER . . . . . . . . . . . . . . . . . . . . 87
Atividade 3 – Captura e identificação da troca de mensagens entre os
clientes SIP . . . . . . . . . . . . . . . . . . . . . . . . . 89
Atividade 4 – Decodificando os pacotes capturados para escutar a conversa entre
os clientes. . . . . . . . . . . . . . . . . . . . . . . . . 90
50
Protocolo de iniciação de sessão – SIP
Capítulo 2 – Protocolo SIP

\\Session Initiation Protocol – SIP;
\\Protocolo de sinalização que estabelece sessões de comunicação interativa

entre usuários. Entre outros recursos, cada sessão pode incluir:
\\Vídeo;
\\Voz;
\\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, onde 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 arquitetura cliente/servidor — o originador é o usuário cliente e o destino é o
usuário servidor. Existem as versões SIP-T IETF, SIP-I ITU e SIP-I ANSI, similares ao
SIP, mas com diferenças sutis, utilizadas para tunelar mensagens ISUP ou outras
sinalizações telefônicas através de redes IP.
Em uma sessão SIP, um servidor e um cliente terão total controle sobre a sessão,
podendo ser de transmissão de voz, vídeo ou bate-papo.
Objetivos básicos do protocolo SIP

\\Contemplar a criação e o gerenciamento de sessões para troca de fluxos
multimídia entre aplicações.
\\Tornar a comunicação possível com outros protocolos, como:

\\Real Time Protocol / Real Time Control Protocol (RTP/RTCP);
\\Session Description Protocol (SDP);
\\Real Time Streaming Protocol (RTSP);
\\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:
\\Tipo de dado transportado;
51
\\Timestamps;
\\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 mídia, codecs, portas de mídia e criptografia.
O Real Time Streaming Protocol (RTSP), ou protocolo de fluxo contínuo em tempo

real, é utilizado para transmissão de áudio e vídeo, ou seja, streams sincronizados de
mídias contínuas em tempo real pela internet. Foi definido peIa IETF na RFC 2326.
O Media Gateway Control Protocol (MGCP) assume 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

\\SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE);
\\Session Initiation Proposal Investigation (SIPPING);
\\Multiparty Multimedia Session Control (MMUSIC);
\\IP Telephony (IPTEL);
\\PSTN-Internet Interworking (PINT).
\\SIMPLE – grupo que foca seu trabalho nas aplicações relacionadas ao protocolo
SIP, conhecidas como instant messages e presence;
\\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;
\\MMUSIC – grupo responsável por desenvolver protocolos que suportem

teleconferência e comunicações multimídia;
\\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;
52
\\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

\\Simples;
\\Independente do protocolo de transporte;
\\Baseado em texto;
\\Sinalização ponto-a-ponto:
\\Toda lógica está armazenada nos clientes, exceto mensagens de roteamento.
\\Associado ao Session Description Protocol (SDP):

\\Usado para transportar descrições dos parâmetros de cada sessão.
\\Trabalha com IPv4 e IPv6;
\\O que o SIP não é e não faz:

\\Não é um protocolo de transferência de dados;
\\Transporta pequenas mensagens, mas não grande quantidade de dados;
\\Não fornece suporte para QoS;
\\Não tem a finalidade de substituir todas as características da telefonia;
\\Não é um protocolo de reserva de recurso;
\\Não é um protocolo para controle de dispositivos ou procedimento para
chamadas remotas (Remote Procedure Calls – RPC);
\\Não substituirá o protocolo da PSTN;
\\Trabalha juntamente com a PSTN através de gateways, mas esta não é sua
função principal.
O Protocolo de Iniciação de Sessão é um protocolo de aplicação que utiliza o modelo

“requisiçã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 características

listadas abaixo:
\\Simplicidade; possui apenas seis métodos;
\\Independência em relação ao protocolo de transporte;
\\Baseado em texto;
\\Assim como o HTTP, o SIP leva os controles da aplicação para o terminal,

eliminando a necessidade de uma central de comutação.
53
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 iterativas (pequenas mensagens de
texto). Também não age como um dispositivo de reserva 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 interagir
com a PSTN por meio de gateways, mas esta não é sua função principal.
Elementos de uma rede SIP

\\Rede SIP simples:
\\Apenas para comunicação entre dois user agents, enviando mensagens SIP
diretamente.
\\Rede SIP típica:

\\Contém mais de dois tipos de elementos SIP:
\\User agents;
\\Proxy Servers:
\\Stateful;
\\Stateless.
\\Redirect server;
\\Registrar.
\\User Agents (UA):

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

\\Parte do UA que envia as requisições e recebe as respostas.
\\User Agent Server (UAS):

\\Parte do UA que recebe as requisições e envia as respostas.
\\UAC e UAS são entidades lógicas.
54
Arquitetura do SIP

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.
\\UAC (User Agent Client) – o Usuário Agente Cliente executa a função de cliente
da aplicação e é responsável por iniciar uma chamada SIP;
\\UAS (User Agent Server) – o Usuário Agente Servidor é 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, 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:
\\Proxies Stateless não mantêm o estado das chamadas. Eles simplesmente

reencaminham as mensagens para o destino ou para outro proxy. São mais
simples e mais rápidos.
\\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, 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. Esta situação muda quando a pessoa chamada decide enviar um BYE e
terminar a sessão. Neste caso, o user agent chamado (que envia BYE) se comporta
como um UAC e o user agent chamador atua como um UAS.
55
Callee A
UAC
Caller Stateful Forking Proxy

UAS
Invite
UAC Invite UAC
UAS
UAS UAC Callee B

Invite
UAS
Bye
UAC Figura 2.1

UAS e UAC
UAS e UAC
Esta figura 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.
Servidor Proxy
\\Entidade intermediária que atua como servidor e cliente;
\\Tem o propósito de fazer requisições em nome de outros clientes;
\\Existem dois tipos de servidores proxy:

\\Stateful;
\\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 produzir 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
trânsito, a fim de evitar congestionamentos.
56
Servidor Stateful

\\Entidade lógica que mantém o estado de todas as transações de clientes e
servidores:
\\Mais complexo do que o servidor stateless;
\\Performance limitada;
\\Trabalha com forking;
\\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 Stateless
\\Entidade lógica que não mantêm o estado das transações feitas pelo cliente ou
pelo servidor;
\\Repassa todas as requisições e respostas recebidas;
\\Não se importa com o que acontece com as transações, apenas as repassa;
\\Mais rápido do que o servidor stateful, entre outras funções podendo servir de:
\\Tradutor de mensagens;
\\Roteador.
Um servidor stateless não mantém o estado das chamadas, repassando as

requisições recebidas. Não se importa com o que acontece com as transações,
apenas as repassa. É mais rápido do que o servidor stateful e pode servir como:
\\Tradutor de mensagens;
\\Roteador;
\\Balanceador de carga.
57
Utilização do servidor proxy
\\Comunicação entre duas empresas com servidor Proxy.
DNS Server
2. SIP SRV
for b.com 3. proxy.b.com
Company A Company B
Joe proxy.a.com proxy.b.com
1. Invite 4. Invite
5. In
vite
Bob
5.6.7.8
6. Bye
1.2.3.4
Figura 2.2
Este 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áiro 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

diferente, então irá procurar 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 (Redirect Server)

\\Servidor que recebe uma requisição e retorna uma resposta contendo uma lista
da localização atual do cliente;
\\Gera respostas do tipo 3xx para as requisições feitas.
58
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, direcionado 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.
Redirect Server
ite
rily
nv
ra
I
1.
po
m
Te
ov 02
ed
3
2.
M
3. Invite
Figura 2.3 User Agent A User Agent B
Neste 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 direto para eles.
Servidor de registro (Register Server)

\\Entidade especial SIP;
\\Recebe os registros dos usuários;
\\Extrai a informação de sua localização atual:

\\Endereço IP;
\\Porta;
\\Username.
\\Armazena informações em um banco de dados;
\\Caso o registro ocorra com sucesso, uma mensagem do tipo 200 OK será retornada.
O servidor de registro é um dos elementos da arquitetura SIP, onde se recebe os

registros dos usuários. Ele extrai a informação de sua localização atual (endereço IP,
porta e username) e a armazena em um banco de dados. Armazena informações
59
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.
Record in Location Database
User sip:jan@iptel.org is
reachable at sip:jan@1.2.3.4:5060 CDRs
Location
UA Registrar Database
2. Store Register
sip:jan@iptel.org
1. Register Store
Location
200 OK
3. 200 OK Registrar
1.2.3.4:5060
Figura 2.4
Este 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 telefone e o processo de registro termina corretamente.
SIP URI
\\As entidades SIP são identificadas utilizando SIP URI (Uniform Resource Identifier);
\\Sintaxe SIP: username@domain

\\Username: nome do usuário;
\\Domain: domínio utilizado pelo usuário.
\\Exemplo:
\\SIP: joao@rnp.br
Entidades SIP são identificadas com SIP URI (Uniform Resource Identifier), tendo a
sintaxe “sip:username@domain”. O SIP URI consiste de uma parte com o nome do
usuário e uma parte com o nome do domínio, delimitados por @ (at / arroba). Os
SIP URI são similares aos endereços de e-mail, de modo que é possível utilizar seu
endereço de e-mail como um SIP URI, facilitando a memorização.
60
Mensagens SIP

\\A comunicação SIP determina a troca de várias mensagens:
\\Uma mensagem pode ser:

\\Requisição do cliente para o servidor;
\\Resposta do servidor para o cliente.
\\As mensagens podem ser transportadas via UDP ou TCP;
\\Há dois tipos de mensagens SIP:
\\SIP Requests:
\\Uma mensagem SIP enviada do cliente ao servidor com o propósito de invocar
uma operação em particular.
\\SIP Responses:
\\Quando um User Agent ou um servidor proxy recebe uma requisição e envia
uma resposta.
\\Mensagem de requisição (SIP Request):

\\Linha de requisição como linha de início:
\\Método;
\\Endereço:
\\Formato definido como uma Universal Resource Identifier (URI).

\\Identificação da versão SIP:
\\SIP/2.0.
\\São especificados seis métodos para a versão corrente do SIP:

\\Outros métodos foram definidos por extensões do SIP.
Mensagens SIP possuem a seguinte estrutura:
\\Mensagem genérica: = linha de início;
\\Cabeçalho da mensagem;
\\CRLF (Carrige Return Line Feed);
\\[corpo da mensagem];
\\Linha de início = linha de requisição / linha de status.
SIP Requests são mensagens enviadas por um Usuário Agente Cliente (UAC)
solicitando uma sessão a um Usuário Agente Servidor (UAS).
SIP Responses são respostas à solicitação do UAC, podendo ser enviados por
servidor proxy ou pelo UAS final.
61
Nas sinalizações telefônicas CAS e CCS era possível identificar a causa da desconexão
ou da perda da chamada através de um código. As chamadas desconectadas por

Release (REL) no DSS-1, na telefonia (ISUP) ou no Q. SIG possuíam um código
numérico indicativo da causa, como por exemplo a causa 16, que significava uma
desconexão normal de uma chamada que teve atendimento e bilhetagem. As causas de
desconexão estão definidas na recomendação Q.850 do ITU, e discutidas entre as
operadoras fixas e móveis no Fórum Nacional de Completamento de Chamadas (FNCC).
O H.323 também permite relacionar a causa de liberação do canal de sinalização

através da mensagem RealeseComplete (RLC). É possível realizar uma comparação
das “SIP Responses” com as causas no H.323, na ISUP e em outras sinalizações.
Este acompanhamento é importante para profissionais que administram redes
corporativas conectadas com redes públicas, sejam de ISUP, sejam de nova geração
(SIP-T, SIP-I, MGCP ou H.248/Megaco). Por exemplo, uma resposta SIP 486,
corresponde a uma causa na ISUP/H323/DSS-1 17, com destino ocupado.
Para mais informações, consulte a RFC 3398 da IETF e a recomendação Q.850 do ITU.
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étodos de requisições no SIP/2.0
Método Funcionalidade
INVITE Usado para convidar um UA a estabelecer uma sessão.
ACK Confirma convite do INVITE.
BYE Termina a sessão multimídia.
CANCEL Cancela a sessão, mas não por inteiro.
REGISTER Registra a informação do contato.
OPTIONS Faz consulta ao servidor para saber suas capacidades. Tabela 2.1
Noções sobre o funcionamento de SIP com outras sinalizações:
\\INVITE – corresponde à mensagem Setup no DSS-1/Q.sig/H.323 e à mensagem

IAM (mensagem de endereçamento inicial) na ISUP;
\\ACK – pode corresponder às mensagens Alerting ou Connect no DSS-1/Q.

sig/H.323 ou ACM, Call progress ou ANM (atendimento) na ISUP;
\\BYE – corresponde à mensagem Release (REL) no DSS-1/Q.sig, Releasecomplete

(RLC) no H.323 e REL na ISUP;
62
\\CANCEL – corresponde à mensagem notify no DSS-1/Q.sig/H.323;

\\REGISTER – semelhante ao procedimento RAS no H.323, e manual nas
sinalizações telefônicas;
\\OPTIONS – não existe correspondente exato nas sinalizações telefônicas.
Métodos de requisições estendidos
Método RFC Funcionalidade
INFO 2976 Carrega informações de controle geradas durante a

sessão.
MESSAGE 3428 Permite a transferência de mensagens instantâneas.
NOTIFY 3265 Permite a notificação de eventos específicos.
PRACK 3262 Confirma a recepção de uma mensagem de resposta

informativa.
PUBLISH 3903 Publica o estado de um evento.
REFER 3515 Solicita que um receptor faça contato com um terceiro

participante.
SUBSCRIBE 3265 Permite que se subscreva para um estado particular em

um recurso.
Tabela 2.2 UPDATE 3311 Permite a atualização dos parâmetros de uma sessão.
A definição dos métodos nas RFCs não impede que muitos pontos continuem vagos,
permitindo que fornecedores implementem soluções proprietárias ou até versões
diferentes, ainda que a RFC seja atendida. É uma diferença importante entre as RFCs da
IETF e as recomendações do ITU, que são extremamente detalhadas, deixando poucas
opções para soluções proprietárias distintas, no caso de atendimento da recomendação.
Portanto, é necessário cautela na interconexão de redes com fornecedores diferentes.

Uma boa sugestão é um teste prévio avaliando a utilização de todos os métodos
disponíveis e a compatibilidade entre eles.
O mercado tem apresentado diversos casos de perda de funcionalidades com

impacto nos custos, quando são utilizados fornecedores diferentes sem um estudo
prévio de interfuncionamento e testes das facilidades e métodos.
63
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=”53fe98db10e1074b03b3e06438bda70f”
Content-Type: application/sdp
Content-Length: 451
Continua com linhas SDP...
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 dos servidores por onde passa a requisição. Eles são utilizados
para o roteamento de SIP Responses (respostas SIP). Esta mensagem INVITE
contém apenas um cabeçalho Via criado pelo user agent que enviou a requisição.
Sobre o campo Via podemos dizer que o user agent está executando no endereço
195.37.77.100, na porta 5060.
Nos campos do cabeçalho To e From identifica-se quem irá receber o convite e de

quem está sendo recebida a mensagem para determinada sessão. Também possui
um campo Tag que serve como um identificador de diálogo.
Mensagem de resposta (SIP Response)

\\Caracterizada pela utilização de uma linha de status como linha de início,
formada por:
\\Identificação da versão SIP;
\\Código de status numérico;
\\Código de resultado com três dígitos;
\\Frase textual.
\\Muito similares às requisições, exceto pela primeira linha.
64
\\Existem seis classes do tipo SIP Responses:
\\1xx – Resposta informativa;
\\2xx – Respostas de sucesso;
\\3xx – Respostas de redirecionamento;
\\4xx – Respostas de falha de requisição;
\\5xx – Respostas de falha em servidor;
\\6xx – Respostas de falha global.
A mensagem SIP Response é composta de Versão do SIP (SIP Version), Código de

estado (Status code) e Motivo (Reason phrase):
\\Versão do SIP – 2.0 (atual);
\\Status code – informacional, Sucesso, Erro no Cliente ou Falha Global;
\\Reason phrase – frase resumida explicando o significado do código de estado,

podendo ser uma informação ou uma resposta final.
Exemplos:
\\SIP 2.0 – 486 – busy here ou destino ocupado; neste caso é uma resposta final,
já que o destino não está disponível;
\\SIP 2.0 – 180 – ringing ou chamando; neste caso não é uma resposta final,
apenas um aviso para a origem de que a chamada está em processo de
recebimento pelo destino.
Conforme foi visto, quando existe interfuncionamento com outras sinalizações, é

necessário estar atento à correspondência entre as mensagens de resposta SIP e as
mensagens com causa nas outras sinalizações.
No primeiro exemplo, a mensagem “SIP 2.0 – 486 – usuário ocupado” corresponde

à mensagem RLC (17) no H.323, e REL (17) na ISUP e no DSSI.
Já no segundo exemplo, a mensagem “SIP 2.0 – 180 – chamado” corresponde à

mensagem alerting no H.323 e no DSS-1, e à mensagem ACM (mensagem de
endereço completo) na ISUP.
1xx
Respostas provisórias, que dizem ao receptor que a requisição feita foi recebida,
mas o resultado ainda está em processo.
2xx
Respostas finais de sucesso, que o originador da requisição sempre receberá.
Também terminam transações.
65
3xx
Respostas usadas para redirecionamento do chamador. Fornecem informações sobre

a nova direção do usuário ou sobre um serviço alternativo que o chamador precisa
usar para satisfazer a ligação.
4xx
Resposta de falha de requisição, utilizada para indicar que houve erro da parte de quem
enviou a requisição, erro na sintaxe ou devido ao mau preenchimento pelo servidor.
5xx
Resposta de falha no servidor, utilizada para indicar erro da parte do servidor.
6xx
Resposta de falha global, indicando que a resposta não pode ser completada em
nenhum servidor.
Exemplo:
Informational Success Redirection Request Failure

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 Extencions
486 Busy Here
500 Server Error 600 Busy Everwhe

501 Not Implemented 603 Decline
503 Unavailable 604 Doesn’t Exist
504 Timeout 606 Not Acceptable
Figura 2.5
Server Failure Global Failure
\\1xx – informativo, pedido recebido, sessão em progresso;
\\2xx – sucesso, ação recebida, entendida e aceita com sucesso;
\\3xx – Rrdirecionamento, ação adicional deve ser tomada para completar a sessão;
\\4xx – erro de cliente, sintaxe inválida ou por algum motivo a sessão não pode
prosseguir (os motivos são listados);
\\5xx – erro de servidor (os motivos são listados);
\\6xx – falha global (os motivos são listados);
No caso de interfuncionamento via gateway com redes telefônicas (ISUP) é

necessário estar atento à RFC 3398. As mensagens de respostas SIP são
parcialmente baseadas no HTTP.
66
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;expi
res=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”
\\Cabeçalho da mensagem:
\\Sequência estruturada de campos de cabeçalho (header fields) após a linha
de início;
\\Semelhantes aos campos do cabeçalho das mensagens HTTP;
\\Podem ser incluídos em mensagens de:
\\Requisição;
\\Resposta.
\\Dependendo da mensagem, os campos podem ser:

\\Obrigatórios;
\\Opcionais;
\\Não aplicáveis.
\\Cada campo é representado por uma linha:

\\Nome do campo seguido de “:” e zero ou mais valores do campo separados
por vírgula.
\\Alguns campos permitem que o valor seja seguido de pares de parâmetros

separados por “ ; ”
\\Formados por:
\\Nome do parâmetro
\\ =
\\Valor do parâmetro
\\Exemplo:
\\Contact: <sip:renato.duarte@rnp.br>;expires=3600
Este 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
67
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.
\\As mensagens SIP são codificadas usando a sintaxe HTTP v1 (RFC 2068);
\\Todas as solicitações de um usuário que deseja estabelecer uma sessão (por

exemplo uma chamada telefônica) são chamadas de Requisição. Uma Requisição
deve obrigatoriamente ter uma resposta, como a mensagem 486 (destino
ocupado). Neste caso é uma resposta final, já que o destino está ocupado.
Alguns campos podem estar nas mensagens de requisição e de respostas. Neste

caso, são partes do cabeçalho único.
Caso o tempo definido por ‘expires’ não seja suficiente, um proxy pode rejeitar a
mensagem, informando o seu tempo, e o UAC enviará uma nova mensagem com a nova
temporização. Caso isso não ocorra, a mensagem ficaria presa no proxy aguardando
tratamento, e a sessão seria encerrada por estouro de temporização (session expires).
Exemplo: se uma mensagem chegar a um proxy com “expires=50” e o tempo de

espera é de 3600, o proxy poderá enviar uma resposta solicitando a alteração do
campo “expires=50” para “expires=3600”. Neste caso o UAC enviará um novo
INVITE com o parâmetro alterado.
Alguns campos do cabeçalho
Via Contact
To Max-Forwards
From Content-Type
Call-ID Content-Length
CSeq ou Command Sequence
Obs.: Descrição completa dos campos que compõem o cabeçalho na RFC 3261,
sessão 20. Tabela 2.3
\\Via – indica o endereço para o qual a requisição deve seguir e o endereço que as
respostas devem tomar no momento da volta no roteamento das mensagens;
\\To – especifica o destinatário que deve receber a requisição;
\\From – indica quem irá fazer a requisição;
\\Call-ID – informa o identificador único específico para uma sessão;
\\Command Sequence (Cseq) – ordena transações dentro de um diálogo, para

prover uma identificação única das transações e diferenciar entre novas
requisições e retransmissões de requisições;
68
\\Contact – provê uma URI em que o significado depende do tipo de requisição ou

de resposta em que está. Pode conter o nickname de um usuário, uma URI com
parâmetros e parâmetros do cabeçalho;
\\Max-Forwards – serve para limitar o número de proxies ou gateways que podem

enviar requisições para um próximo servidor;
\\Content-Type – contém a descrição do corpo da mensagem, indicando o tipo de

mídia do corpo da mensagem enviada ao destinatário;
\\Content-Length – indica o tamanho do corpo da mensagem.
Campos gerais Campos para Campos para Campos para entidades

requisições respostas
Accept Authorization Authorization-Info Allow
Accept- Hide Error-Info Content-Disposition

Encding
Accept- In-Reply-To Min-Expires Content-Encoding

Language
Alert-Info Max-Forwards Proxy-Authenticate Content-Language
Call-ID Priority Retry-After Content-Length
Call-Info Proxy- Server Content-Type

Authorization
Contact Proxy-Require Unsupported Expires
Cseq Route Warning
Date Subject WWW-

Authenticate
Encryption Response-Key
From
MIME-Version
Organization
Record-Route
Reply-To
Require
Supported
Tabela 2.4 Timestamp

Categoria dos
To
campos
69
Campos gerais Campos para Campos para Campos para entidades

requisições respostas
User-Agent
Via
\\Campos gerais – possuem as informações básicas para tratamento das

requisições e respostas;
\\Campos para requisições – específicos para requisições, possibilitando prover

informações adicionais para o servidor a respeito da própria requisição ou do cliente;
\\Campos para respostas – específicos para mensagens de resposta, oferecendo

mais informações sobre o status indicado nessas mensagens;
\\Campos para entidades – indicam o tipo e o formato das informações presentes

no corpo da mensagem, possibilitando que a aplicação apropriada para tratar a
informação seja executada.
Exemplo de fluxo de mensagens:

Atlanta.com Biloxi.com
proxy proxy
Alice Bob SIP
softfone Phone
Invite F1
Invite F2
100 Trying F3 Invite F4
100 Trying F5
180 Ringing 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
200 OK F14 Figura 2.6
Neste exemplo, o proxy server recebe uma requisição INVITE e envia uma resposta
100 (trying) para o softphone da 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 3 dígitos
seguidos de uma frase descritiva. Esta resposta contém os mesmos campos To,
From, Call-ID, CSeq e Via, que permitem que o softphone da Alice correlacione a
resposta com a mensagem INVITE enviada. O servidor proxy “atlanta.com” localiza
o proxy no servidor “biloxi.com”, possivelmente executando um tipo de procura no
70
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” inclui 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 do Bob. O servidor proxy “biloxi.
com” adiciona outro campo Via no cabeçalho com o seu endereço para a requisição
INVITE, e a envia ao telefone SIP do Bob. O telefone SIP do Bob recebe a requisição
INVITE e alerta ao Bob que existe uma chamada de Alice, indicando essa ação com
uma mensagem de resposta 180 (ringing), que é roteada pelos dois proxies na
direção reversa. Cada proxy utiliza o campo Via do cabeçalho para saber para onde
enviar a resposta, depois disso eliminado-as do topo da mensagem. Quando o
softphone da Alice recebe a resposta 180 (ringing), a informação é passada para
Alice, talvez utilizando tom de áudio “ringback” ou mostrando uma mensagem na
tela do softphone dela.
Quando Bob atende à ligação, o seu telefone SIP envia uma mensagem 200 (OK)
para indicar que a ligação foi atendida. A mensagem 200 (OK) contém o corpo da
mensagem juntamente com a descrição de mídia SDP (Session Description Protocol)
do tipo de sessão que Bob está esperando estabelecer com Alice. Se Bob não
atendesse à chamada, uma mensagem de erro seria retornada em vez da mensagem
200 (OK), e a sessão de mídia não existiria.
Protocolo SDP
\\Session Description Protocol (SDP):
\\Definido pela RFC 2327;
\\Utilizado para descrever sessões;
\\Especifica apenas o formato para a descrição das informações trocadas
entre entidades SIP.
\\Mídia a ser utilizada;
\\Informações para a transmissão da mídia:

\\Padrão do codec;
\\Protocolo de controle para transmissão.
\\Para a mídia, o SDP inclui as seguintes informações:

\\Tipo de mídia (vídeo, áudio);
\\Protocolo de transporte (RTP / UDP / IP, H.320);
\\Formato da mídia (H.261 vídeo, MPEG vídeo).
71
\\As mensagens SDP podem ser transportadas mediante diferentes protocolos:

\\SIP;
\\SAP;
\\RTSP;
\\Correio eletrônico com aplicações MIME ou protocolos como HTTP.
Session Description Protocol (SDP) ou Protocolo de Descrição de Sessão é um

formato para a descrição dos parâmetros de inicialização de mídia streaming
(conteúdo visto ou ouvido durante um envio de dados). Foi publicado pela IETF
como RFC 2327 e substituído pela RFC 4566.
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
da mesma, 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 das informações.
No campo mídia, 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)
Neste caso a mídia é áudio, utiliza a porta UDP 3456, perfil “áudio e vídeo” e aceita
os codecs 0, 3, 4 e 5. Para identificar os codecs é necessário consultar a RFC 3551.
As mensagens SDP podem ser utilizadas para conexões ponto a ponto ou ponto-
multiponto (multicast). O SDP não é utilizado apenas pelo SIP. Também pode ser
utilizado pelo protocolo de anúncio de sessão (Session Announcement Protocol –
SAP), pelo protocolo de fluxo de tempo real (Real Time Streaming Protocol – RTSP)
para aplicações baseadas em streaming, pelo correio eletrônico com aplicações
MIME (Multipurpose Internet Mail Extensions), descritas nas RFCs 2045 e 2046, e
ainda pelo protocolo HTTP, entre outros.
Sessões SDP
\\A descrição das informações de uma sessão SDP é inteiramente representada
de forma textual:
\\Facilita a portabilidade;
\\Permite uma variedade de formas de transporte;
\\Possibilita que ferramentas baseadas em texto possam gerar e processar as
descrições das sessões:
\\Codificação UTF-8;
72
\\Nomes dos campos e atributos restritos ao subconjunto
US-ASCII do UTF-8;
\\Campos textuais e valores dos atributos podem utilizar todo o conjunto
de caracteres do UTF-8.
\\Uma mensagem SDP é composta por uma série de linhas denominadas campos:
\\Os nomes são abreviados por uma só letra;
\\A formatação das linhas de texto está descrita da seguinte forma:
\\Tipo do campo = valor do campo.
\\A descrição de uma sessão consiste de:

\\Descrição do nível de sessão:
\\Detalha informações que devem ser aplicadas à sessão como um todo e
a todos os fluxos de mídia.
\\Zero ou mais descrições do nível de mídia:
\\Detalha informações que devem ser aplicadas a um fluxo de mídia específico.
A RFC 2327 possui o procedimento detalhado para sessões multimídia. A codificação

UTF-8 (8-bit Unicode Transformation Format) é uma codificação unicode de
comprimento variável, usa 4 bytes por caractere e necessita de apenas um byte para
representar os 128 caracteres ASCII. A RFC 3629 (formato ISO 10646) informa
que os tipos de campos e o detalhamento da sessão são detalhados nas RFCs 2327
e 4566, e a parte de mídia na RFC 3551.
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 descriçã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

Tabela 2.5 z Ajustes do time zone Não
Descrição da
sessão k Chave de encriptação Não
73
campo obrigatória
a Zero ou mais linhas de atributo da sessão Não
Zero ou mais descrições de mídia Não
O SDP é um protocolo que permite fácil leitura. Portanto, em uma missão crítica é
necessária a criptografia e a autenticação de suas informações. O processo de
proteção para o protocolo SDP é definido no cabeçalho SIP, no campo Encryption. O
SDP utiliza caracteres ASCII e pode utilizar textos livres como informativos. A chave
de criptografia utilizada neste protocolo para os canais de mídia é definida na RFC
2327. O processo de criptografia e autenticação poderá ser UAC-UAS ou Proxy-UAS.

campo obrigatória
Tabela 2.6
t Horário em que a sessão está ativa Sim
Descrição do
r Zero ou mais horários repetidos Não horário

campo obrigatória
m Nome da mídia e endereço de transporte Sim
i Título da mídia Não
c Informação sobre a conexão Não
b Informação sobre a largura de banda Não

Tabela 2.7
k Chave de encriptação Não Descrição da
a Zero ou mais linhas de atributo da mídia Não mídia
Um servidor SIP que receber um campo SDP criptografado deve enviar suas
respostas obrigatoriamente criptografadas.
Para maior detalhamento dos valores do campo de mídia RTP e codecs, consulte a
RFC 3551.
74
Exemplo de Sessão SDP

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
\\V – versão;
\\o – originador, ID sessão, versão, tipo de rede, tipo de endereço, endereço;
\\s – nome da sessão;
\\u – URI de descrição;
\\c – informação sobre a conexão;
\\t – tempo que a sessão está ativa (tempo de início e tempo de parada, em segundos);
\\m – nome da mídia, endereço de transporte (porta), padrão (RTP/Áudio e vídeo),

tipos de codecs aceitos (RFC 3551);
\\a – outros atributos sobre mídia, tais como modulação, portas UDP e codec.
Modos de comunicação SIP

\\Existem dois modos de comunicação:
\\Modo direto:
\\Peer-to-peer;
\\Permite que um agente SIP envie requisições para outro agente.

\\Modo indireto:
\\Via servidor proxy;
\\Normalmente requer a presença de outros servidores de apoio que integram
a infraestrutura de um sistema de telefonia baseado em SIP.
\\Modo direto – quando um cliente SIP já conhece o endereço do telefone SIP de

interesse. Assim, é possível chamar diretamente para um número IP;
75
\\Modo indireto – quando é necessário um servidor que conheça o endereço IP do
usuário de interesse. Assim, as ligações precisam de um servidor proxy para

alcançarem seus destinos.
Comunicação peer-to-peer
(Protocolo SDP)
Agente A Agente B
1. Invite
2. 180 Ringing
3. 200 OK
4. ACK
5. Voz ( RTP )
6. Bye
7. 200 OK
Figura 2.7
Comunicação peer-to-peer
1. Invite – mensagem de requisição com todos os dados da origem para a conexão;
2. 180 ringing – mensagem informativa de que o destino está recebendo chamada;
3. 200 OK – mensagem final de que o destino atendeu, com o campo SDP

definindo as mídias;
4. ACK – resposta a uma mensagem final, que só existe para a mensagem 200 OK,
confirmando as mídias;
5. Mudança de mídia pode ser realizada por “re-invites”, ou seja, novos invites na sessão;
6. Voz (RTP) – troca de streams de áudio utilizando os protocolos RTP/RTCP;
7. BYE – requisição de desconexão pelo destino. Na telefonia tradicional PCM/TDM, a

desconexão pelo destino temporiza no ponto de bilhetagem por 90 segundos.
Aqui não existe nenhuma temporização, pois a desconexão é imediata;
8. 200 OK – mensagem final, em resposta a uma requisição de desconexão.
76
Comunicação via proxy

INVITE sip: claudio@ SIP/2.0 100 Trying ACK sip:claudio@rnp.br
rnp.br SIP/2.0 Via:SIP/2.0/UDP proxy. SIP/2.0
Via:SIP/2.0/UDP proxy. pop-rj.rnp.br; Via: SIP/2.0/UDP
pop-rj.rnp.br; branch=4 branch=4 Proxy.unb.br
Via:SIP/2.0/UDP proxy. Via:SIP/2.0/UDP proxy. From: Daniel
pop-rj.rnp.br; branch=2 pop-rj.rnp.br; sip:daniel@unb.br
Via:SIP/2.0/UDP proxy. branch=2 Call-ID: 12345@proxy.
unb.br Via:SIP/2.0/UDP proxy. unb.br
From:Daniel unb.br Cseq: 2 INVITE Subjet:
<sip:daniel@unb.br> From:Daniel Projeto fone@RNP
To:Claudio <sip:daniel@unb.br> Contact: sip:daniel@
<sip:claudio@rnp.br> To:Claudio proxy.unb.br
Call-ID:12345@proxy. <sip:claudio@rnp.br> Route: <sip:claudio@
unb.br Call-ID:12345@proxy. proxy.pop-df.rnp.br;
Cseq:2 INVITE unb.br maddr=10.0.0.1>,
Subject: Projeto fone@ Cseq:2 INVITE <sip:claudio@proxy.
RNP Subject: Projeto fone@ pop-rj.rnp.br>
Contact: <sip:daniel@ RNP ...
proxy.unb.br> Contact: <sip:daniel@
Record-Route: proxy.unb.br>
<sip:claudio@proxy. Record-Route:
pop-rj.rnp. <sip:claudio@proxy.
br;maddr=10.0.0.1>, pop-rj.rnp.br;
<sip:claudio@proxy. maddr=10.0.0.1>,
pop-df.rnp.br; <sip:claudio@proxy.
maddr=10.0.0.1> pop-df.rnp.br;
... maddr=10.0.0.1>
...
Requisição INVITE Conteúdo da resposta Conteúdo da requisição

recebida pelo agente 100 Trying enviada pelo ACK enviada pelo
servidor agente servidor agente cliente
\\INVITE SIP – destino, versão 2.0.;
\\Via – campo que marca o trajeto da mensagem e para onde a resposta ser
enviada. O objetivo é indicar o caminha de volta. Facilita o controle da chamada,
evita loops e auxilia a bilhetagem;
\\Branch=4 – campo utilizado para identificar a transação, inserido pela rede;
\\Record-Route – cabeçalho utilizado pelos proxies, que precisa estar no caminho da

sinalização durante todo o tempo da chamada, para fins de bilhetagem, por exemplo;
\\Maddr – utilizado para comunicação multicast;
\\SIP 2.0 Trying – mensagem informativa e provisória em resposta ao INVITE.

Equivalente à chamada em progresso;
\\Outros parâmetros são similares ao INVITE;
Note que o campo Route da mensagem ACK é construído com base no campo
Record-Route da mensagem TRYING. Veja os detalhes na RFC 3261.
77
Transações e diálogos SIP
\\SIP Transactions:
\\Sequência de mensagens trocada entre os elementos de uma rede SIP;
\\Inclui zero ou mais respostas provisórias e uma ou mais respostas finais;
\\Consiste de:
\\Uma requisição;
\\Várias respostas para a requisição feita.
\\Entidades com noção de transações são chamadas de stateful;
\\SIP Dialogs:
\\Sequência de transações;
\\Representa uma relação SIP P2P (peer-to-peer) entre dois user agents;
\\Facilitao sequenciamento e o roteamento das mensagens entre os
terminais SIP;
\\São identificados por Call-ID, From tag, To tag;
\\Possuem esses campos com o mesmo valor quando pertencem ao mesmo
diálogo.
Uma transação consiste de uma requisição e todas as suas respostas.
As requisições são ditas como transações do cliente ou “client transactions” e as

respostas são transações do servidor ou “server transactions”.
Um diálogo representa uma relação SIP peer-to-peer entre dois user agents. Tem
certo tempo de duração e é um conceito muito importante para os user agents. Os
diálogos facilitam o próprio sequênciamento e roteamento das mensagens entre os
terminais SIP. São identificados pelos campos Call-ID, From e To. Mensagens que
pertencem ao mesmo diálogo precisam ter esses campos iguais. O campo CSeq é
usado para ordenar mensagens dentro de um diálogo, contendo número que precisa
ser incrementado para cada mensagem enviada dentro de um diálogo. De outro modo,
o terminal iria manipular as requisições e retransmissões fora de ordem. O número
CSeq identifica a transação (requisição e respostas) dentro do diálogo. Isso significa
que apenas uma transação em cada direção pode estar ativa dentro de um diálogo.
78
Exemplo:

Primeira transação
Invite
100 Trying
200 OK
ACK
Bye
200 OK
Segunda transação
Figura 2.8 Cliente Servidor
1. INVITE – contém as informações de origem e destino (no H.323 são as

informações contidas na mensagem setup) e o campo SDP com as informações
de mídia (no H.323 são as informações H.245);
2. 100 Trying – chamada em progresso (na ISUP seria a mensagem Call Progress);
3. 200 OK – mensagem final de atendimento;
4. ACK – confirmação da mensagem e das mídias a serem utilizadas;
5. BYE – requisição de desconexão;
6. 200 OK – requisição aceita.
Note que neste exemplo não foi enviada a mensagem RINGING.
Cenários SIP
\\Alguns cenários SIP:
\\Registration;
\\Session Invitation;
\\Session Termination;
\\Instant Messages.
\\Registration – processo em que um User Agent (UA) se registra via rede em um

proxy de registro;
79
\\Session Invitation – usuário Agente Cliente (UAC) solicita o estabelecimento de
uma sessão a um Usuário Agente Servidor (UAS);
\\Session Termination – término da sessão por iniciativa do UAS ou UAC, por

temporização, destino não acessível, congestionamento na rede etc.;
\\Instant Messages – durante uma sessão, UAC e UAS podem enviar mensagens
sem encerrar a sessão.
SIP Registration
\\Tem a finalidade de registrar um user agent;
\\Se não houver registro, usuários com intenção de se comunicar não poderão se
comunicar;
\\Um registro compreende:

\\Mensagem REGISTER enviada pelo user agent;
\\Mensagem 200 OK enviada pelo servidor de registro, se o registro for
bem-sucedido;
\\Mensagem 407 em caso contrário.
O registro de um cliente SIP é feito em um servidor de registro. Sua função é saber como
encontrar os usuários caso haja uma ligação para eles. O registro e autenticação no SIP já
pode ser feito com texto plano, mas devido a questões de segurança este método não é
mais utilizado. Recomenda-se a utilização de um desafio utilizando um número aleatório
enviado pelo servidor de registro. O cliente SIP faz algumas contas com o realm (domínio a
que ele pertence), com o número aleatório e com uma senha simétrica, portanto de
conhecimento do cliente e do servidor. Estes dados servem de parâmetros para um cálculo
também conhecido por ambos. O resultado deste cálculo é enviado ao servidor, que
autentica (ou não) o usuário. Desta forma, a senha não trafega pela rede, aumentando
significativamente a segurança na comunicação e mantendo o sigilo da senha.
Este método é baseado no esquema de desafio implementado pelo HTTP, e está

descrito na RFC 2617 (foi estendido pela RFC 3310).
80
Exemplo:

Agente A Servidor de proxy Servidor de registro REGISTER sip:registrar.bsb.com.br
SIP/2.0
Via: SIP/2.0/UDP cxo.bsb.com.br
1. Register
From: <sip:claudio@bsb.com.br>
To: <sip:claudio@bsb.com.br>
2. 100 Trying
Call-ID: 12345@cxo.bsb.com.br
3. Register
Cseq : 1 REGISTER
4. 200 OK Contact:
<sip:claudio@cxo.bsb.com.br>
5. 200 OK Expire: 3600
Figura 2.9 Content-Length: 0
1. O cliente solicita o registro;
2. Servidor proxy repassa a solicitação de registo para o servidor de registro;
3. Servidor de registro verifica os dados e autentica ou nega a autenticação;
4. Neste exemplo, o registro foi aceito e confirmado pela mensagem 200 OK.
Session Invitation
\\Consiste em uma requisição INVITE, geralmente enviada ao proxy;
\\O proxy imediatamente envia uma resposta com a mensagem 100 Trying;
\\Finalidade: acabar com as retransmissões;
\\Todas as respostas geradas pelo UA chamado são devolvidas ao UA chamador.
O convite (Invitation) talvez seja a mensagem mais comum no SIP, e deve ser
respondido imediatamente com um “100 Trying” para indicar ao chamador que o
convite foi recebido e está sendo tratado.
Chamador Servidor proxy Chamado

1. Invite
2. 100 Trying
3. Invite
4. 100 Trying
5. 180 Ringing
6. 180 Ringing
7. 200 OK
8. 200 OK
9. ACK
RTP Streams
Figura 2.10
81
1. Como o chamador geralmente não tem a informação do endereço de destino,
solicita ao servidor proxy o encaminhamento da requisição INVITE para o chamado;
2. O servidor proxy envia mensagem informativa de chamada em progresso,

indicando que está tratando a chamada;
3. O servidor localiza o endereço do destino e envia o INVITE. O servidor poderia ter

vários endereços do destino, caso em que seriam enviados diversos INVITES, um
para cada destino;
4. O usuário chamado envia ao servidor a informação de que está processando a

chamada (100 Trying);
5. Na sequência, informa para o proxy que o telefone está chamando e aguardando

atendimento;
6. O servidor proxy repassa ao chamador a informação de que o destino está

recebendo (Ring). Neste momento, o telefone do chamador começa a tocar;
7. O atendimento acontece e a mensagem 200 OK é enviada ao proxy;
8. O proxy envia para o chamador a resposta 200 OK, para que retire o tom de
controle e abra os canais de áudio RTP/RTCP;
9. Uma última confirmação é enviada do chamador para o chamado através da

mensagem ACK;
10. É dado o início ao transporte da mídia, voz ou vídeo.
Session Termination
\\Tem a finalidade de terminar uma sessão;
\\Possui dois tipos de término de sessão:

\\Direta;
\\Envia uma requisição BYE para o outro UA envolvido, e este responde com
uma mensagem 200 OK.
\\Via proxy.
Assim como o INVITE, a terminação da chamada pode ser realizada de forma direta ou
indireta, ou seja, a mensagem utilizada para desconexão da chamada (BYE) pode ser
enviada diretamente para o usuário na outra ponta da chamada ou através do proxy.
Em ambientes em que é necessário ter controle total das chamadas, por exemplo
para fins de bilhetagem (cobrança das chamadas), é imprescindível que o BYE seja
enviado para o proxy, para que este possa registrar o final das chamadas.
82
Exemplo:

UA1 SIP proxy UA2
1. BYE
Forma direta 2. 200 OK
1. Bye
2. Bye
Figura 2.11 Forma indireta 3. 200 OK
4. 200 OK
A figura ilustra duas situações de como pode ocorrer o término de uma sessão. A
primeira mostra a forma direta, na qual os dois users agents negociam o término da
sessão diretamente. A segunda mostra a forma indireta, onde um SIP proxy está no
meio da comunicação entre os dois clientes, roteando as mensagens.
Instant Messages (IM)

\\Instant Messages são enviadas utilizando requisições do tipo MESSAGE;
\\Mensagens deste tipo não estabelecem diálogos;
\\O texto da IM é transportado no corpo (body) da requisição SIP.
UA1 SIP proxy UA2
1. Message
2. Message
3. 200 OK
4. 200 OK
5. Message
6. Message
Figura 2.12 7. 200 OK

8. 200 OK
Segundo a figura, UA1 envia mensagem para o proxy, pois não possui o endereço de
UA2 ou por programação da rede, para que o proxy tenha o controle da chamada.
\\O envio das mensagens instantâneas está definido na RFC 3428.
83
84
2
\\Instalação do servidor OpenSER.
\\Análise do tráfego de pacotes SIP na rede utilizando uma ferramenta de

captura de tráfego.

\\Capacidade de identificar e analisar o tráfego de pacotes SIP na rede.

Descompacte a máquina virtual Debian para o desktop e troque o nome do diretório

para OpenSER.
Atividade 1 – Instalando o OpenSER
Nesta atividade efetuaremos a instalação do OpenSER em uma máquina virtual

Debian. O OpenSER é um sistema que implementa as funções SIP proxy, registrar e
redirect server.
Passo 1: inicie a máquina virtual com sistema operacional Debian no diretório OpenSER.
85
Se for apresentada a tela abaixo, selecione a opção I copied it.
Figura 2.13
Passo 2: efetue login com o usuário root e senha rnpesr e em seguida verifique se a
máquina virtual obteve a configuração correta da rede, efetuando o comando ifconfig.
Qual foi o IP obtido na rede?
Passo 3: execute o comando apt-get update; não ocorrendo erro instale o pacote
openser com o comando apt-get install openser. Aguarde o fim da instalação.
Passo 4: a configuração do OpenSER é feita no arquivo openser.cfg, localizado no

diretório /etc/openser. O arquivo é organizado em 3 sessões: configurações globais,
configurações dos módulos e lógica de roteamento. Neste curso simplesmente
usaremos a configuração default do OpenSER.
Passo 5: para iniciar e parar o serviço do OpenSER, experimente:
# openserctl start
# openserctl stop
Para monitorar o funcionamento do OpenSER, experimente:
# openserctl monitor
86
Atividade 2 – Captura e identificação da troca de mensagens entre os clientes

SIP e o OpenSER
Passo 1: inicie o cliente X-Lite e o configure de modo a se registrar no servidor

OpenSER instalado anteriormente. Observe se a mensagem Ready será exibida no
display do cliente.
Display Name: 10XX

User name: 10XX
Password: voip
Authorization user name: 10XX
Domain: <IP_do_servidor_OpenSER>
Domain Proxy: <IP_do_servidor_OpenSER>
Passo 2: configure o Telefone IP de modo a se registrar no servidor OpenSER.
Passo 3: configure o ATA de modo a se registrar no servidor OpenSER.
Proxy: <IP do servidor OpenSER>

Display Name: Entre com o seu nome completo
User ID: 30XX
Password: voip
Register Expires: 3600
Passo 4: volte para a máquina virtual e certifique-se de que os clientes foram

registrados visualizando a lista de peers no OpenSER, utilizando o comando:
# openserctl ul show
Passo 5: encerre o X-Lite. Inicie o Wireshark com modo promíscuo desabilitado e

insira um filtro para o protocolo SIP. Reinicie o X-Lite novamente, usando a nova
configuração, e observe a autenticação do cliente com o servidor. No término da
autenticação, pare e salve a captura de pacotes como registrando.pcap.
Passo 6: no Wireshark, abra o arquivo salvo registrando.pcap. Com base nas

informações capturadas, responda ao questionário abaixo:
1. Sobre qual protocolo de transporte o protocolo SIP trafega na rede?
2. Quais as portas de comunicação entre cliente SIP e gatekeeper?
87
3. Detalhe o Status-Line do protocolo SIP e informe a sua versão.
4. Em Status-Code, informe a sequência obtida durante a autenticação.
5. Durante o processo de autenticação entre cliente e servidor, qual o

comportamento observado?
Passo 7: crie uma tabela de estatística utilizando o Wireshark, clique em

Statistics>SIP e em seguida em Create Stat, e preencha o quadro abaixo de acordo
com o resultado obtido na captura.
Figura 2.14
88
Atividade 3 – Captura e identificação da troca de mensagens entre os clientes SIP

Esta atividade deverá ser realizada em dupla.
Passo 1: inicie o Wireshark com modo promíscuo desabilitado, insira um filtro para
o protocolo SIP e em seguida inicie os clientes X-Lite, Telefone IP e ATA. Efetue uma
chamada entre os clientes, mantenha um diálogo entre eles, finalize a captura e
salve como ligando.pcap.
Passo 2: no Wireshark abra o arquivo ligando.pcap, acesse o menu Statistics e em

seguida selecione a opção Flow Graph. Com as informações exibidas, responda ao
questionário a seguir:
1. Quais os endereços de origem e destino durante a ligação?
2. Por que a primeira requisição INVITE foi negada?
3. Qual a sequência de pacotes durante o encerramento de uma ligação?
89
Atividade 4 – Decodificando os pacotes capturados para escutar a conversa
entre os clientes
Inicie o Wireshark, abra o arquivo ligando.pcap, acesse o menu Statistics e em

seguida selecione VoIP Calls. Selecione a captura e execute o Player, conforme
ilustra a figura a seguir. Em seguida será exibida uma tela onde deverá ser executado
o Decode. A partir deste instante escutaremos a conversa realizada entre os clientes.
Figura 2.15
Na tela a seguir você poderá selecionar o canal que escutará ou ambos os canais.
Figura 2.16
1. Quais as opções de codecs anunciadas?
90
2. Existem mensagens provisórias antes de 200 OK?
3. Qual o codec de áudio utilizado durante a ligação?
4. Qual a porta utilizada para o transporte de áudio?
91
92
3
Recomendação H.323
►► Sumário
Introdução à recomendação H.323 . . . . . . . . . . . . . . . . . 94
Componentes da arquitetura H.323 . . . . . . . . . . . . . . . . 96
Pilha de protocolos H.323 . . . . . . . . . . . . . . . . . . . . 98
Fluxos de controle e sinalização. . . . . . . . . . . . . . . . . . 99
Recomendação H.225.0. . . . . . . . . . . . . . . . . . . . 99
Mensagens RAS. . . . . . . . . . . . . . . . . . . . . . . 101
Controle de mídia . . . . . . . . . . . . . . . . . . . . . . 103
Modos de operação . . . . . . . . . . . . . . . . . . . . . 105
Estabelecimento de chamadas . . . . . . . . . . . . . . . . . 106
Chamada direta entre pontos finais. . . . . . . . . . . . . . . . 107
Chamada entre pontos finais registrados no mesmo gatekeeper . . . . . . 108
Chamada entre pontos finais em que somente um é registrado em gatekeeper . 110
Chamada entre pontos finais registrados em gatekeepers distintos . . . . . 113
Estabelecimento de canal de controle H.245. . . . . . . . . . . . . 115
Uso dos serviços da chamada . . . . . . . . . . . . . . . . . . 116
Recomendações H.235 . . . . . . . . . . . . . . . . . . . . 117
Recomendação H.460. . . . . . . . . . . . . . . . . . . . . 118

Atividade 1– Instalando o GnuGK. . . . . . . . . . . . . . . . . 119
Atividade 2 – Analisando a captura feita pelo Wireshark . . . . . . . . 124
93
Introdução à recomendação H.323
\\H.323 é uma série de recomendações produzidas pelo ITU-T para sistemas de

conferência audiovisual;
\\As recomendações são projetadas para:
\\Permitir interoperabilidade entre elas;
\\Possibilitar que usuários de sistemas de conferências possam se comunicar
e usar diferentes tecnologias de rede.
\\Outras recomendações:
\\H.310, para conferências sobre RDSI-FL;
\\H.320, para conferências sobre RDSI-FE;
\\H.322, para conferências sobre LANs que proveem garantias de QoS;
\\H.324, para conferências sobre RTPC.
\\Provê suporte a:
\\Conferências ponto-a-ponto e multiponto:
\\Chamadas H.323 podem ser estabelecidas entre dois ou mais usuários.
\\Heterogeneidade:
\\Um equipamento em um sistema H.323 deve dar suporte obrigatório à

comunicação de áudio.
\\Contabilidade e gerência:
\\Chamadas H.323 podem ser bloqueadas com base no número de
chamadas já estabelecidas, limitações na banda ou restrições de tempo.
\\Provê suporte a:
\\Segurança:
\\Suporte à autenticação de usuários e para a privacidade e não-repúdio

de dados trocados entre eles.
\\Serviços suplementares;
\\Permite a elaboração e o desenvolvimento de serviços adicionais.
O protocolo H.323 teve seu desenvolvimento iniciado pelo ITU na década de 90 e

ao longo do período foram desenvolvidas diversas versões.
\\V.1 – provisória, possuía muitas deficiências e não foi implementada;
\\V.2 – melhoramento da V.1, introduzia as facilidades Fast Connect, Tunelamento

e Overlap;
\\V.3 – permitia escolha de língua, serviços suplementares até 450.7;
\\V.4 – introdução de serviços suplementares 450.8 a 450.11, possibilidade de

gatekeeper alternativo, tunelamento Q.SIG e ISUP, URL, capacidade de
chamadas pré-pagas, DTMF via RTP;
\\V.5 – tunelamento DSS-1, Série 460.x (portabilidade, status do enlace etc.);
94
\\V.6 – as versões anteriores só permitiam codec ITU que necessitavam de licença.
Capítulo 3 – Recomendação H.323

A nova versão permitiu codecs de fonte aberta, tais como iLBC e GSM.
A última versão do protocolo H.323 (V.6), de junho de 2006, administra:
\\Registro de usuários;
\\Localização de destinos em endereços URI, IPv4, IPv6 ou telefônicos via gateway;
\\Largura de banda e escolha de codecs;
\\Controle de chamadas, conexão e desconexão;
\\Conferências multimídia centralizadas e descentralizadas;
\\Banco de dados de endereçamento;
\\Estatísticas;
\\Bilhetagem, entre outros registros.
Segurança na comunicação do protocolo H.323

O protocolo H.323 permite comunicação segura entre seus dispositivos, aplicando
criptografia e autenticações das mensagens de sinalização e criptografia das
mensagens de voz (RTP) e de controle (RTCP).
O protocolo Transport Layer Security (TLS) aplica segurança, através de criptografia,

na camada de transporte em redes IP, sendo o sucessor do protocolo Secure Sockets
Layer (SSL).
O protocolo TLS permite:
\\Negociação de algoritmos;
\\Chaves de autenticação;
\\Autenticação de mensagens.
Grande parte das aplicações de segurança são proprietárias, dificultando o

interfuncionamento com redes de fornecedores diferentes, sendo um ponto
impactante nos projetos que necessitam de segurança pela sua criticidade.
Serviços suplementares e adicionais

Os serviços suplementares definidos nas recomendações são limitados. Para suprir
as necessidades do mercado, algumas empresas desenvolvem serviços adicionais na
maioria das vezes proprietários, sendo outro fator impactante a considerar no caso
de redes com diversos fornecedores.
Principais serviços suplementares:
\\450.2 (Call Transfer) – transferência de chamadas;
\\450.3 (Call Diversion) – desvio de chamada;
95
\\450.4 (Call Hold) – retenção de chamada;
\\450.5 (Call Park e Call Pickup) – retenção e retomada;
\\450.6 (Call Waiting) – chamada em espera;
\\450.7 (Message Call Waiting) – mensagem de chamada em espera;
\\450.8 (Call Completion) – procedimentos no caso de ocupado;
\\450.9 (Display) – também conhecido por bina, permite exibir no telefone de

destino o número do chamador;
\\450.10 (Call Intrusion) – intrusão na chamada.
Componentes da arquitetura H.323

\\Terminais:
\\Podem ser um telefone IP ou uma aplicação executada em um computador

com recursos multimídia.
\\Gateways:
\\São necessários no momento em que dois terminais desejam estabelecer

comunicação entre diferentes tipos de rede.
\\Gatekeeper (GK):
\\Normalmente utilizado para controlar acesso às redes de comunicação.
\\Multipoint Control Unit (MCU):

\\Realiza as funções de controle e autorização de novos participantes para
conferências.
Intranet/Intranet
ISDN
H.320
H.323
Terminal
H.323 PSTN
Gatekeeper H.324
H.323
MCU
H.323
ATM
Gateway H.310. H.321
H.323
Terminal
Internet/Intranet
SIP Figura 3.1
O gatekeeper (GK) é responsável por:
\\Resolução de nomes;
\\Identificação do destino, já que possui o banco de endereços dos seus usuários;
96
\\Realização de controle de chamadas;

\\Mobilidade pessoal.
O gateway (GW) é um tradutor multimídia que interconecta os elementos H.323 a

outros ambientes de redes e protocolos. Um fator importante a considerar é que as
facilidades comuns ficam no GK ou no GW, como correio de voz e música de espera.
No caso de chamadas diretas de um terminal H.323 com outro terminal H.323 via
barramento, as facilidades anteriores são perdidas, já que ficam armazenadas no
GK. Grande parte dos terminais são proprietários, o que significa que o terminal de
um fabricante A não funciona na rede do fabricante B. São raros os fabricantes que
aceitam terminais de fonte aberta. É importante lembrar que os gateways com a
rede telefônica têm que criar certas condições que o H.323 não possui, como o
gerador de tom de controle (RBT), que no H.323 é gerado na origem, enquanto na
rede telefônica é gerado no destino. As chamadas com sobrediscagem originadas em
aparelhos decádicos são barradas nos codecs. Exemplo: um usuário disca para um
número de call center e recebe um menu de orientação com as alternativas. Ao
sobrediscar a alternativa escolhida (aparelho decádico) a sobrediscagem é perdida,
porque o destino não consegue interpretar corretamente a informação, alterada pela
interferência dos codecs.
Os gateways com a rede telefônica possuem, no lado de telefonia, interface E-1,

conforme a prática TB 220-250-707, sinalizações CAS E&M, R2 ou Canal Comum
DSS-1 com a rede pública de telefonia e Q.Sig com redes corporativas de PABX. No
lado com a rede IP, geralmente a interface é Ethernet e a sinalização é H.323
(poderia ser IAX, SIP).
A gerência da rede decide se programará o GK para ter todo o controle das

mensagens de sinalização ou se não irá habilitar essa opção. Exemplo: um GK pode
necessitar apenas da função RAS, sendo que as mensagens Q.931 poderiam ser
trocadas diretamente com os pontos finais.
Zona Todos os usuários de uma zona devem ser registrados no GK que a controla.
Uma zona é uma
região H.323
No caso de necessidade de controle da chamada, o GK pode solicitar, durante o
formada pelo
processo RAS, que todas as mensagens Q.931 e H.245 utilizadas para o
conjunto de
terminais, estabelecimento da chamada sejam feitas através dele. Tal processo é realizado com
gateways e MCUs o GK enviando para o telefone ou gateway de origem o seu próprio endereço e porta,
controlados por com destino. A mensagem recebida é encaminhada pelo GK para o destino, que
um único pode ser outro GK ou o telefone de destino, a depender da negociação durante o
gatekeeper.
processo RAS (Registro, Admissão e Status). O controle de admissão de chamadas é
Uma zona pode
abranger redes
feito através do protocolo H.225 RAS. A gerência da banda é feita através das
distintas. mensagens H.225, Q.931 e H.245 UDP.
Uma MCU ou Unidade de Controle Multiponto é o dispositivo da arquitetura H.323

responsável pelas conferências. Ela coordena os fluxos de áudio, vídeo e dados, de
forma que todos os participantes recebam os mesmos fluxos de forma coerente.
97
A MCU é formada por dois elementos básicos:
\\O Controlador Multiponto (MC), parte obrigatória da MCU, é responsável pela

negociação do protocolo H.245 para determinação das características de áudio e
vídeo dos terminais. Se houver algum participante utilizando transmissão
multicast, o MC também fica responsável por este controle;
\\O Processador Multiponto (MP), parte opcional da MCU, trata os fluxos de áudio,
vídeo e dados de uma conferência. Os fluxos de mídia não passam pelo MC.
Padrões Descrição
T.38 Transporte de dados (texto, imagem, fax, sinais de modem)

T.120
V.150.1
RTP Transporte de áudio e vídeo

RTCP (IETF)
H.245 Protocolos de controle e sinalização

H.225.0
H.246 Interoperabilidade com redes telefônicas comutadas por circuitos

H.248
H.235 Segurança em sistemas baseados no protocolo de controle H.245
H.450.x Serviços suplementares
H.460.x Extensões aos serviços de sinalização do protocolo H.255.0
H.501 Gerência e segurança de usuários, terminais e serviços em

H.510 ambientes móveis
H.530 Tabela 3.1
A recomendação H.323 é formada por um conjunto de outros padrões e

recomendações. Ela indica uma série de ponteiros para vários outros documentos.
Os padrões listados na tabela especificam os principais serviços, protocolos e
procedimentos adotados em sistemas H.323.
Pilha de protocolos H.323

\\Dados textuais:
\\T.120 (ITU T.120);
\\Padrão para intercâmbio de dados (textos e imagens estáticas);
\\Depende de um conjunto de outros padrões e recomendações: T.122,
T.124, T.125, T.126 e T.127.
\\Áudio e vídeo:
\\Protocolos RTP e RTCP.
98
Descrito na RFC 3550, o protocolo RTP é utilizado para transporte de áudio e vídeo.

O protocolo RTCP, parte do RTP, é utilizado para o seu controle, e é descrito na
mesma RFC.
O protocolo RTP utiliza UDP para transportar a mídia, em uma porta negociada
durante o estabelecimento da chamada. O RTCP utiliza uma porta acima do RTP.
Tais protocolos são utilizados também pelo SIP para transporte de mídia.
Fluxos de controle e sinalização

\\Existem três padrões de protocolos utilizados para controle e sinalização:
\\H.225.0;
\\H.225.0 RAS;
\\H.245.
\\O protocolo H.225.0 é utilizado para o estabelecimento de chamada entre dois

dispositivos H.323.
\\O protocolo H.225.0 RAS é utilizado com um gatekeeper para controle de

admissão e resolução de endereços.
\\O protocolo H.245, por sua vez, é utilizado para controlar a comunicação entre
os dispositivos.
\\O padrão H.225.0 RAS utiliza a porta TCP 1718 para conexões multicast e a
porta TCP 1719 para conexões unicast.
\\O padrão H.225 Q.931 utiliza a porta TCP 1920.
\\O padrão H.245 utiliza portas TCP dinâmicas.
Recomendação H.225.0
\\Sinalização de chamadas:
\\H.323 utiliza o protocolo H.225.0 para a sinalização das chamadas;
\\O protocolo H.225.0 utiliza um subconjunto das mensagens definidas
nas recomendações:
\\Q.931;
\\Q.932.
\\Mensagens de sinalização H.225.0:

\\Estabelecimento de chamadas:
\\Setup;
\\CallProceeding;
\\Alerting;
\\Progress;
99
\\Connect.
\\Encerramento de chamadas:
\\ReleaseComplete.
\\Outros:
\\Status/StatusEnquiry;
\\Facility.
O protocolo Q.931 é utilizado para estabelecer o canal de sinalização. A seguir suas

principais mensagens:
\\Setup (M) – mensagem enviada com a finalidade de estabelecer uma conexão,

podendo ser enviada diretamente do terminal de origem para o terminal ou
gatekeeper de destino, ou via gatekeeper;
\\Call proceding (O) – mensagem enviada pelo destino informando que todos os dados
relativos à chamada foram recebidos e nenhuma informação adicional será aceita;
\\Information (O) – mensagem enviada pela origem com informações complementares,

por exemplo, para envio de dígitos por OverLap após a mensagem Setup;
\\Alerting (M) – mensagem enviada do destino para a origem, indicando que o

terminal de destino está iniciando o toque de campainha e que o terminal de
origem deve iniciar o envio do tom de controle da chamada;
\\Connect (M) – mensagem enviada pelo destino informando que a chamada foi
aceita pelo usuário chamado;
\\Release Complete (M) – mensagem enviada pela origem ou pelo destino

informando que a chamada foi desconectada e que o canal está livre;
\\Status (M) – mensagem enviada em ambas as direções para relatar condições de erro;
\\Notify (O) – mensagem enviada em ambos os sentidos com informações sobre

uma chamada, tal como usuário suspenso;
\\Progress (O) – mensagem enviada para a origem para indicar inter-funcionamento;
\\Facility(M) – utilizada para serviços suplementares, tal como redirecionamento

de uma chamada.
Tipos de mensagens:
\\M (mandatório);
\\O (Opcional);
\\Mensagens restantes (F) não são utilizadas no H.323.
O protocolo Q.932 provê mensagens para suporte aos serviços suplementares:
\\Facility – mensagem utilizada para requisitar uma facilidade de serviço suplementar;
\\Hold (Ack/Rej) – facilidade de retenção;
100
\\Retrieve (Ack/Rej) – facilidade de recuperação;

\\Register (Ack/Rej) – registro de um evento;
\\Notify (Ack/Rej) – notificação de evento.
Mensagens RAS
\\Registro, Admissão e Status;
\\As funções de RAS (Registration Admission Status) incluem:

\\Descoberta de gatekeepers;
\\Registro de pontos finais;
\\Localização de pontos finais;
\\Gerência de banda e notificação de estado.
\\Mensagens H.225.0 RAS:

\\Descoberta:
\\GRQ (GatekeeperReQuest);
\\GCF (GatekeeperConFirm);
\\GRJ (GatekeeperReJect).
\\Registro:
\\RRQ (RegistrationReQuest);
\\RCF (RegistrationConfirm);
\\RRJ (RegistrationReJect);
\\URQ (UnRegistrationReQuest);
\\UCF (UnRegistrationConfirm);
\\URJ (UnRegistrationReJect).
\\Mensagens H.225.0 RAS:

\\Localização:
\\LRQ (LocationReQuest);
\\LCF (LocationConFirm);
\\LRJ (LocationReJect).
\\Controle de admissão:
\\ARQ (AdmissionReQuest);
\\ACF (AdmissionConfirm);
\\ARJ (AdmissionReject).
\\Alteração de banda:
\\BRQ (BandwidthReQuest);
\\BCF (BandwidthConfirm);
\\BRJ (BandwidthReject).
101
\\Mensagens H.225.0 RAS;
\\Informação de estado:
\\IRQ (InfoReQuest);
\\IRR (InfoReQuestResponse);
\\IACK (InfoReQuestAck);
\\INAK (InfoReQuestNak).
\\Desengajamento:
\\DRQ (DisengageReQuest);
\\DCF (DisengageConfirm);
\\DRJ (DisengageReject).
As mensagens RAS podem ser trocadas entre os terminais e o GW, entre GW e GK

ou entre terminais e GK, dependendo da configuração da rede.
\\GK Discovery (Descobrindo GK) – processo utilizado pelo terminal ou GW para

descobrir o seu GK: o terminal envia mensagem GRQ (GatekeeperRequest), onde
um ou mais GKs podem responder com as mensagens GCF ou GRJ. O GK
procurado responde com GCF e os demais respondem com GRJ; para as demais
mensagens o procedimento é semelhante.
\\GW Registration (Registrando no GK) – executado após o terminal identificar o

seu GK; o terminal envia mensagem RRQ (RegistrationRequest) para o GK, e a
mensagem RRQ deve possuir o endereço e o pseudônimo a ser registrado. Caso
não seja especificado, o GK adicionará um na mensagem RCF. O GK pode a
qualquer momento cancelar a RRQ.
\\Location Request (Localizando GK) – executado quando um GK deseja descobrir

o GK que controla o terminal de destino, e envia a mensagem LRQ para os GKs
mais próximos, com o campo TTL=1 e com informações de quem se deseja
conectar. Caso o destino não esteja nas zonas verificadas, recebendo LRJ dos
GKs consultados, o GK iniciará uma busca em nuvem crescente, aumentando
progressivamente o campo TTL, até que receba a mensagem LCF com o
endereço do GK procurado do próprio terminal de destino.
\\Call Admission (Admissão de uma chamada) – deve ser executado para cada
chamada que for realizar. Um terminal solicita permissão ao GK para encaminhar
uma chamada através da mensagem ARQ (AdmissionRequest), informando o
tipo de comunicação, endereço, banda e tipo de codec. O GK responderá com a
mensagem ACF, definindo banda, endereço de destino e obrigatoriamente
determinando se a chamada feita diretamente (entre os gateways ou terminais)
ou se será via GK. A alteração de banda é realizada de maneira similar: uma
alteração de banda poderá ser solicitada por qualquer uma das partes, através
da mensagem BRQ (BandwidthRequest). O terminal remoto só realizará a
mudança de banda após enviar uma mensagem BRQ ao seu GK de controle e
receber uma BCF. Por exemplo, um terminal poderá solicitar largura de banda
adicional para abrir canal de vídeo através da mensagem BRQ.
102
Mensagens de status com informações de estado são trocadas periodicamente entre

os terminais e o GW, e entre GW e GK. A qualquer momento ou periodicamente, um
GK poderá solicitar informação de estado de um terminal (através da mensagem
IRQ), recebendo como resposta a mensagem IRR (InformationRequestResponse) —
dos terminais ou GW — sobre o estado da chamada. Qualquer um dos terminais ou
GK podem cancelar uma conexão através da mensagem DRQ (DesengageRequest),
e o destino responderá com uma mensagem DCF.
Controle de mídia
\\Sistemas H.323 usam mensagens de controle de mídia definidas na
recomendação H.245;
\\A recomendação H.245 define as seguintes funções:

\\Troca de capacidades;
\\Estabelecimento e encerramento de canais lógicos;
\\Determinação de mestre e escravo;
\\Notificações.
\\Mensagens de controle H.245:

\\Determinação mestre e escravo:
\\MasterSlaveDetermination;
\\MasterSlaveDeterminationAck;
\\MasterSlaveDeterminationReject;
\\MasterSlaveDeterminationRelease.
\\Troca de capacidades:
\\TerminalCapabilitySet;
\\TerminalCapabilitySetAck;
\\TerminalCapabilitySetReject;
\\TerminalCapabilitySetRelease.
\\Comando:
\\EndSessionCommand.
\\Sinalização de canais lógicos:

\\OpenLogicalChannel;
\\OpenLogicalChannelAck;
\\OpenLogicalChannelReject;
\\OpenLogicalChannelConfirm;
\\CloseLogicalChannelAck;
\\RequestChannelClose;
\\RequestChannelCloseAck;
103
\\RequestChannelCloseReject;
\\RequestChannelCloseRelease.
Em relação às capacidades dos pontos finais, há demanda por um procedimento

que permita determinar configurações compatíveis entre eles antes que fluxos de
áudio, vídeo e dados textuais sejam criados. Sistemas H.323 usam mensagens
definidas na recomendação H.245 para proceder com o controle de mídias.
Em relação à troca de capacidades, os pontos finais informam uns aos outros suas
capacidades de transmissão e recepção em termos de: codecs, tipos de mídia
aceitos e taxa de bits toleráveis.
As mensagens H.245 controlam a abertura e o fechamento dos canais lógicos de

uma chamada, determinam as figuras do mestre e do escravo e estabelecem
mensagens em caso de conflitos entre pontos finais. Definem uma série de outras
mensagens que permitem a notificação entre pontos finais. Por exemplo:
\\Problemas de comunicação;
\\Determinação de retardo.
Fast Start
Considerando o tempo de ida e volta de cada mensagem gasto durante o processo
de admissão (ARQ/ACF), descrito basicamente nas mensagens abaixo:
1. Utilizando o protocolo de transporte UDP na troca de mensagens setup e

Connect no tempo de ida mais o de volta;
2. Utilizando o protocolo de transporte TCP na abertura de canais lógicos H.245 no

tempo de ida mais o de volta;
3. Utilizando o protocolo de transporte TCP durante o tempo de ida e de volta para

procedimento Mestre-Escravo em conferências.
Logo, a soma desses tempos é um valor muito elevado, prejudicando o

estabelecimento das chamadas H.323. Para reduzir o tempo do processo de
estabelecimento de uma chamada e habilitar os canais de mídia imediatamente
após o envio da mensagem Setup, a mensagem H.245 fast start é inserida na
mensagem Setup enviada. Caso o destino aceite, retornará nas próximas mensagens
Q.931 o elemento fast start em 1 (verdadeiro); caso contrário, o parâmetro será
mantido em 0 (falso) e será retornado o procedimento normal. Este método é
denominado de Fast Connect.
Tunelamento
O processo chamado tunelamento (tunneling) é similar ao anterior. O tunelamento
das mensagens H.245 ocorre nos elementos US-US (H.245 tunneling) das
mensagens Q.931, Call Proceding, Alerting ou Connect. Na mensagem Setup, o
parâmetro tunneling é configurado em 1 (verdade), para que a origem solicite a
facilidade de tunelamento H.245; o restante é similar ao processo Fast Connect.
104
Se necessário, negociações de banda ou codec, entre outras, poderão ser realizadas

através da mensagem Q.931 Facility, utilizando o campo US-US.
As mensagens H.245 também são transportadas por meio de um serviço fim-a-fim

confiável (TCP) na rede comutada por pacotes.
Mensagens de controle H.245:
\\MasterSlaveDetermination – mensagem para definir quem será mestre ou

escravo ou ainda para acordar facilidades comuns. Isto significa que este
procedimento aparece em chamadas comuns em que a mensagem só serve para
acordar facilidades comuns ou conferências para definição de mestre e escravo;
\\TerminalCapabilitySet – informações sobre terminais e canais de mídia, porta,

banda, codecs, criptografia, entre outras;
\\EndSessionCommand – encerramento da conexão e liberação dos terminais;
\\Sinalização dos canais lógicos;
\\LogicalChannelOpen – abertura do canal, porta UDP, tipo de mídia;
\\LogicalChannelClose – encerramento do canal de mídia, sem encerrar a conexão

realizada através do comando ESC.
Modos de operação
\\A comunicação entre pontos finais H.323 é dividida em 5 fases:
\\Início da chamada
\\Controle do canal H.245
\\Estabelecimento da conexão entre os canais lógicos
\\Utilização dos serviços da chamada
\\Encerramento da chamada
A comunicação entre dispositivos H.323 consiste em estabelecer uma chamada e

encerrá-la. Para estabelecer a chamada, mensagens Q.931 são enviadas através da
porta 1920 TCP (utilizando os métodos fast start ou tunneling; caso um dos
terminais não aceite um dos procedimentos, será executado o procedimento
normal). Um canal de controle H.245 é estabelecido através de uma porta TCP
dinâmica. Em seguida conexões entre canais lógicos são estabelecidas através da
porta de voz UDP dinâmica e os tipos de codecs são informados. Para o transporte
da voz é utilizado o protocolo RTP/UDP.
105
Encerramento da chamada
As mensagens a seguir encerram a chamada:
\\Encerramento do canal lógico H.245 – mensagem CLC;
\\Comando de fim de sessão H.245 – comando ESC;
\\Mensagem de liberação do canal de sinalização Q.931 – mensagem RLC;
\\Atualização do GK RAS – mensagem DRQ.
Estabelecimento de chamadas
\\Chamada entre pontos finais em que somente um é registrado em gatekeeper
Terminal 1 GK Terminal 2
Setup
Cellproceeding
ARQ
ACF/ARJ
Alerting
Connect
Sinalização direta com o ponto final chamado registrado
Mensagens de sinalização H.225.0 Mensagens de RAS
Figura 3.2
1. Setup – mensagem direta entre os dois terminais finais (definidos anteriormente

pelo GK no procedimento RAS). A mensagem contém número de destino e de
origem (números telefônicos) podendo levar no campo US-US informações sobre
URIs e H.245, método fast start, tunelling ou procedimento normal;
2. Call Proceeding – aviso do destino de que todas as informações foram recebidas

com sucesso e a chamada está em progresso;
3. ARQ (Admission Request) – mensagem de registro da chamada pelo terminal de

destino no GK. Solicitação para completar a chamada;
4. ACF/ARJ (Admission Confirm/Reject) – mensagem do GK ao terminal,

autorizando ou não o prosseguimento da chamada;
5. Alerting – mensagem informando que o destino está sendo chamado, equivalente

ao ringing, no SIP;
6. Connect – mensagem que informa que o destino atendeu a chamada, podendo

conter as informações H.245 no campo US-US. Quaisquer mensagens anteriores
também poderiam conter informações H.245 no campo US-US, procedimentos
fast start ou tunelling;
106
7. Informações dos campos Fast Start ou Tunneling: porta UDP para mídia, tipo de

mídia, tipos de codecs que podem ser aceitos, criptografia aceita etc.
Chamada direta entre pontos finais
Terminal 1 Terminal 2
Setup
Callproceeding
Alerting
Connect
Sinalização entre pontos finais não registrados em gatekeepers

Figura 3.3
Mensagens de sinalização H.225.0
1. Mensagem Setup com os números de origem e destino. O terminal 1 já possuía o

endereço do destino;
2. Call Proceeding – informação de que todos os dados foram recebidos para

prosseguimento da chamada;
3. Alerting – informação de que o destino está livre e sendo chamado. Ao receber o

alerting, a origem deve enviar tom de controle para o handset;
4. Connect – informação de que o destino atendeu e poderá ser iniciada a

negociação dos canais lógicos de mídia. Connect ou qualquer mensagem para a
origem irá conter o endereço no qual o terminal 2 receberá as mensagens de
abertura de canal de mídia (campo US-US).
107
Chamada entre pontos finais registrados no mesmo
gatekeeper
\\Sinalização direta
ARQ
ACF/ARJ
Setup
Cellproceeding
ARQ
ACF/ARJ
Alerting
Connect

Figura 3.4
1. ARQ – terminal 1 realiza procedimentos de RAS, com o endereço do destino do

seu GK. Solicitação para realizar a chamada;
2. ACF/ARJ – caso o GK permita o prosseguimento da chamada, informará o

endereço do destino naquele momento ao terminal 1. Caso o GK queira controlar
toda a chamada, o endereço informado será o seu. Caso o controle seja feito
diretamente entre os terminais, o endereço informado será o do terminal 2. Neste
caso, o GK não participa do estabelecimento da chamada, mas apenas autoriza
ou nega a chamada;
3. Setup – mensagem inicial com os dados do terminal 2 e do terminal 1 e outras

informações sobre a chamada. Por exemplo: se a identidade do terminal 1 é ou
não restrita;
4. Restante das mensagens – similar aos exemplos anteriores.
108
\\Sinalização roteada pelo gatekeeper
ARQ
ACF/ARJ
Setup
Setup
Cellproceeding
Cellproceeding
ARQ
ACF/ARJ
Alerting
Alerting
Connect
Connect
Figura 3.5 Mensagens de sinalização H.225.0 Mensagens de RAS
Neste caso, todas as chamadas Q.931 obrigatoriamente realizam trânsito no GK.
O procedimento foi definido pelo GK durante o processo RAS e solicitado na

mensagem ACF, em que o endereço de destino é o do próprio GK. Este procedimento
é realizado quando for necessário ao GK ter todo o controle da chamada, para
facilitar o billing ou quando o terminal 2 pertencer a outra zona, controlada por
outro GK.
109
Chamada entre pontos finais em que somente um é registrado
em gatekeeper
\\Sinalização direta com ponto final chamador registrado
ARQ
ACF/ARJ
Setup
Cellproceeding
Alerting
Connect
Figura 3.6
1. Terminal 1 realiza procedimentos RAS;
2. GK informa na mensagem ACF o endereço de destino do terminal 2;
3. Terminal 1 troca mensagens Q.931 diretamente com o terminal 2;
4. Neste caso, o terminal 2 não realiza procedimento de RAS. O terminal 2 não é

registrado no GK, porque foi assim programado pelo gerente da rede ou porque
pode pertencer a outra zona, sendo controlado por outro GK.
110
\\Sinalização roteada pelo gatekeeper com ponto final chamador registrado

ARQ
ACF/ARJ
Setup
Setup
Cellproceeding
Cellproceeding
Alerting Alerting
Connect
Connect
Figura 3.7
1. A diferença do caso anterior é que aqui o GK tem o controle de toda a chamada;
2. Durante o processo de RAS, o GK informou na mensagem ACF que o endereço

de destino é o seu;
3. A partir da informação recebida, todas as mensagens Q.931 enviadas pelo

terminal 1 serão para o GK;
4. Ao receber as mensagens Q.931, o terminal 2 responderá para o endereço de

origem, que é o do próprio GK;
5. O restante da chamada é semelhante aos casos anteriores.
111
\\Sinalização roteada pelo gatekeeper com ponto final chamado registrado
Setup
Cellproceeding
ARQ
ARJ
Facility
Release Complete
Setup
Setup
Cellproceeding
Cellproceeding
ARQ
ACF/ARJ
Alerting
Alerting
Cellproceeding
Connect

Figura 3.8
1. Mensagem Setup diretamente do terminal 1 para o terminal 2, com

procedimento definido durante o processo de RAS;
2. Callproceeding – informa que todos os dados da chamada foram recebidos;
3. ARQ e ARJ – o GK negou o prosseguimento da chamada e exigiu que o

estabelecimento da mesma ocorresse através dele, e não diretamente com o
usuário;
4. Facility – mensagem enviada ao terminal 1, solicitando a exigência do GK;
5. Releasecomplete – terminal 1 desconecta a chamada;
6. Terminal 1 envia novo Setup, desta vez para o GK, após atender a solicitação
contida na mensagem Facility. O GK repassa a informação para o terminal 2;
7. Terminal 2 envia mensagem Call Proceeding informando que recebeu todas as

informações necessárias para o prosseguimento da chamada;
8. Terminal 2 realiza os procedimentos de RAS no GK que libera a chamada;
9. Terminal 2 envia a mensagem alerting para o GK que a repassa ao terminal 1,

para que o mesmo envie tom de controle para o usuário do seu terminal e
simultaneamente envie ring para o seu terminal;
10. Terminal 2 atende a chamada e envia a mensagem Connect informando o evento

e dando prosseguimento à negociação dos canais de mídia.
112
Chamada entre pontos finais registrados em gatekeepers

distintos
\\Sinalização entre pontos finais registrados em gatekeepers distintos.
Terminal 1 GK GK Terminal 2
ARQ
ACF/ARJ
Setup
Callproceeding
ARQ
ARJ
Facility
ReleaseComplete
ARQ
DRQ
DCF
ACF/ARJ
Setup
Callproceeding
Setup
Callproceeding
ARQ
ACF/ARJ
Alerting
Alerting
Connect
Connect
Figura 3.9 Mensagens de sinalização H.225.0 Mensagens de RAS
1. Mensagem RAS ao GK solicitando permissão para usar a rede. Neste caso o

destino está em outro GK;
2. Mensagem Setup enviada diretamente para o terminal 2. Como não existe

nenhuma troca de sinalização entre os GKs, fica pressuposto que já ocorreu outra
chamada para o terminal 2, e o GK de destino passou o endereço do terminal 2
para o GK que controla o terminal 1, ficando fora do controle das mensagens de
sinalização. Como o GK que controla o terminal 1 já possui a informação do
terminal 2, esta é enviada ao terminal na mensagem ACF.;
3. Terminal 2 realiza procedimentos de RAS e recebe uma rejeição, com uma

solicitação para encaminhar a chamada;
4. A mensagem Facility é encaminhada ao terminal 1 com a solicitação do GK 2;
5. Terminal 1 encerra a conexão com a mensagem RLC;
113
6. Terminal 1 envia a mensagem DRQ (Disengage Request) ao seu GK, e a seguir
envia nova mensagem ACF (Admission Confirm) com as solicitações contidas na

mensagem Facility, recebendo mensagem ACF para prosseguimento da chamada.
Possivelmente a solicitação da mensagem Facility foi atendida pelo GK na
mensagem ACF, já que a capacidade do terminal é limitada;
7. Terminal 1 envia mensagem Setup com o endereço do GK que controla o

terminal 2 (esta foi a solicitação contida na mensagem Facility);
8. Terminal 2 envia mensagem Call Proceeding e realiza procedimentos de RAS;
9. Terminal 2 envia mensagem Alerting para a origem, solicitando tom de controle

para o terminal 1, e envia ring para o seu terminal;
10. Terminal 2 verifica o atendimento e envia a mensagem Connect para o terminal

1, para iniciar os procedimentos H.245.
\\Sinalização entre pontos finais com consulta entre gatekeepers
Terminal 1 GK GK Terminal 2
ARQ
ARQ
ACF LCF
Setup
Setup
Callproceeding Setup
Callproceeding
Callproceeding
ARQ
ACF
Alerting
Alerting
Alerting Connect
Connect
Connect

Figura 3.10
1. Terminal 1 envia mensagem ARQ ao seu GK, com os dados do terminal 2;
2. GK 1 verifica que o terminal 2 não pertence à sua zona e envia uma mensagem
LRQ (Location Request) em nuvem crescente, buscando o GK que controla o
terminal 2;
3. O GK que controla o terminal 2 responde com mensagem LCF (Location

Confirm), informando o seu endereço para receber as mensagens de sinalização;
os demais GK consultados respondem negativamente;
114
4. O GK envia ao terminal 1 mensagem ACF, informando o seu endereço para

recebimento das mensagens de sinalização. Neste caso, as mensagens de
sinalização farão trânsito nos dois GKs;
5. Terminal 1 envia mensagem Setup para o seu GK, que a repassa para o GK que
controla o terminal 2, que por sua vez envia a mensagem ao terminal 2;
6. Terminal 2 realiza os procedimentos RAS e recebe autorização para

prosseguimento da chamada;
7. Terminal 2 envia mensagem Alerting ao terminal 1 através dos dois GKs, e

mensagem ring para o terminal 1;
8. Terminal 2, ao receber o atendimento, envia mensagem Connect para o terminal

1 através dos dois GKs e inicia os procedimentos H.245.
Estabelecimento de canal de controle H.245
Terminal A Terminal B
Sinalização H.225.0
TerminalCapabilitySet(A))
TerminalCapabilitySetAck(A)
TerminalCapabilitySet(B)
TerminalCapabilitySetAck(B)
MasterSlaveDetermination
MasterSlaveDeterminationAck(slave)
MasterSlaveDeterminationAck(master)
(ponto final A é o mestre da chamada)
OpenLogicalChannel (canal de voz A =>B)
OpenLogicalChannelAck
OpenLogicalChannel (canal de voz B =>A)
OpenLogicalChannelAck
Chamada em uso
Figura 3.11
Uma vez que os terminais conseguiram completar com sucesso o procedimento de

estabelecimento de conexão de acordo com os exemplos anteriores, é hora de
estabelecer o canal de controle, seguindo indicações do padrão H.245.
1. Mensagem TerminalCapabilitySet(A), informando ao terminal B sobre as suas

capacidades;
2. Terminal B confirma o recebimento das informações;
115
3. Terminal B informa através da mensagem TerminalCapabilySet(B) de suas
próprias capacidades;
4. Terminal A confirma o recebimento das informações;
5. Terminal A envia mensagem MasterSlaveDetermination para definição Mestre-
Escravo;
6. Terminal B responde aceitando a condição de Escravo;
7. Terminal A responde confirmando sua condição de Mestre;
8. Terminal A envia mensagem de abertura de canal de mídia (OpenLogicalChannel)
informando codec e porta, entre outras informações;
9. Terminal B confirma o recebimento da mensagem com OpenLogicalChannelAck,
podendo, se for o caso, solicitar negociação de codec ou porta, entre outros.
Estabeleceu-se neste momento o 1º canal de mídia no sentido A para B;
10. Terminal B envia sua mensagem de abertura de canal de mídia
OpenLogicalChannel com informações sobre codec, porta e codificação;
11. Terminal A confirma o recebimento, concordando com os parâmetros.
Estabeleceu-se neste momento o 2º canal de mídia, no sentido de B para A;
12. Abertura dos canais de mídia e transporte RTP/RTCP.
Uso dos serviços da chamada

\\H.450 define um arcabouço para o desenvolvimento de serviços suplementares,
cujo controle é distribuído entre os pontos finais participantes da chamada.
H.450.1 Arcabouço geral
H.450.2 Transferência
H.450.3 Redirecionamento
H.450.4 Retenção
H.450.5 Atendimento
H.450.6 Chamada em espera
H.450.7 Indicação de mensagem
H.450.8 Identificação de chamador
H.450.9 Notificação de encerramento
H.450.10 Oferta de chamada
H.450.11 Intrusão de chamada Tabela 3.2
116
O H.323 possui um número limitado de serviços suplementares, conforme a

recomendação H.450, se comparado com o Q.Sig, sinalização utilizada em redes
corporativas de telefonia.
Para preencher essa lacuna, os diversos fornecedores desenvolvem as suas próprias

soluções para desenvolver uma quantidade maior de serviços, além dos que estão
definidos na H.450.
Em função disto, é preciso estar atento às implementações dessas facilidades no caso da

utilização de mais de um fornecedor na mesma rede corporativa, pois o interfuncionamento
entre equipamentos de fabricantes diferentes muitas vezes é prejudicado.
Além disso, ainda existem os casos de algumas empresas que forçam a utilização
de seus equipamentos, como estratégia de mercado. Assim como os telefones
digitais só funcionam com PABX de mesmo fabricante, algumas empresas fabricam
telefones IP que funcionam apenas com seus PABX (que normalmente incorporam
as funções de gatekeeper e gateway). Ou seja, nem mesmo uma simples ligação é
realizada quando mais de um fabricante é utilizado.
Recomendações H.235
\\Definidas com o propósito de prover um arcabouço para serviços de segurança
em sistemas que usam protocolos de controle:
\\Os serviços envolvem três aspectos principais:

\\Autenticação de pontos finais
\\Privacidade dos fluxos de informação
\\Integridade dos fluxos
As recomendações H.235.0 e H.235.1 do ITU definem os perfis básicos de

segurança, prevendo a possibilidade de autenticação e integridade ou só
autenticação utilizando criptografia e uso de chaves.
É necessário dar atenção especial a este item, porque muitas soluções de segurança
são desenvolvimentos proprietários que podem sofrer os mesmo problemas
relatados anteriormente.
\\Sistemas H.323 com suporte para a recomendação H.235 possuem as

seguintes características:
\\Sinalização H.225.0 segura
\\Fases de autenticação
\\Trocas de capacidades criptográficas
\\Uso de chaves criptográficas nos canais de mídia
117
As recomendações H.235.0 e H.235.1 do ITU definem os perfis básicos de
segurança, para as mensagens RAS, H.225, Q.931, Q.932 e H.245, ou seja, nos
canais de controle das chamadas.
O uso de criptografia nos canais de mídia (voz e vídeo) é definido no protocolo RTP,
cuja última recomendação é a RFC 3550. O uso de criptografia aumenta o consumo
de banda em pelo menos 10%.
Recomendação H.460
\\Define um arcabouço que permite a negociação de várias facilidades entre
pontos finais, por meio de mensagens de sinalização:
\\H.225.0;
\\Mensagens RAS.
H.460 é um padrão ITU que define uma extensão opcional do H.323. Entre outras
funções, é utilizado para resolver problemas com NAT e firewalls.
Sua estrutura completa está descrita em uma série de documentos:
\\H.460.1 – arcabouço geral;
\\H.460.2 – portabilidade de número;
\\H.460.3 – informação de capacidade;
\\H.460.4 – prioridade de chamada;
\\H.460.7 – recursos de numeração;
\\H.460.8 – consulta a rotas alternativas;
\\H.460.9 – monitoração de QoS;
\\H.460.11 – retardo de chamada;
\\H.460.12 – indicação de controle de colisão de chamada;
\\H.460.13 – liberação de chamada pelo ponto final chamado.
118
3
\\A atividade prática tem como objetivo instalar o servidor GnuGK e analisar o
protocolo H.323.

\\Ao final desta prática o aluno terá capacidade de analisar a troca de
mensagens cliente-servidor utilizando o protocolo H.323.

Requisitos
\\Esta prática envolve atividades individuais e em grupo.
Descompacte a máquina virtual Debian para o desktop e troque o nome do diretório

para GnuGK.
Atividade 1– Instalando o GnuGK
Nesta atividade efetuaremos a instalação do GnuGK em uma máquina virtual Debian.
Passo 1: inicie a máquina virtual com sistema operacional Debian no diretório GnuGK.
119
Se for apresentada a tela abaixo selecione a opção I copied it.
Passo 2: efetue login com o usuário root e senha rnpesr e em seguida verifique se a
máquina virtual obteve a configuração correta da rede, efetuando o comando ifconfig.
Qual foi o IP obtido na rede?

Figura 3.12
Passo 3: execute o comando # apt-get update; não ocorrendo erro, instale o pacote
gnugk com o comando # apt-get install gnugk. Aguarde o fim da instalação.
Passo 4: a configuração do GnuGK é feita no arquivo gnugk.ini, localizado no

diretório /etc. O arquivo é organizado por sessões, sendo cada uma responsável pela
configuração de algumas funcionalidades.
Crie o arquivo gnugk.ini com o comando vim /etc/gnugk.ini. Inclua as linhas abaixo:
[Gatekeeper::Main]
### É usado para testar a presença do arquivo de configuração;

Fourtytwo=42
### É usado para definir o nome do gatekeeper;

Name=PCXXGK
### Nesta seção ainda podemos realizar outras configurações;

[RoutedMode]
### Especifica se o gatekeeper está operando em modo routed ou não;

GKRouted=1
### Habilitar ou não o encaminhamento do canal de controle H.245

### pelo gatekeeper;
H245Routed=1
### Define se aceita ou não chamadas de usuários não autenticados;

AcceptUnregistered=1
120
### Permite que o gatekeeper aceite chamadas dos seus vizinhos;

AcceptNeighBordsCalls=1
### Especifica uma faixa de portas TCP dos canais de sinalização Q.931;
Q931PortRange=30000-39999
[GKStatus::Auth]
### Através da porta de status é possível desligar o gatekeeper,

### a opção forbin bloqueia esta ação;
shutdown=forbin
### Nesta opção são definidas as regras de acesso;

rule=allow
Reinicie o gatekeeper com o comando:
# /etc/init.d/gnugk restart
Passo 5: o GnuGK utiliza a porta TCP/7000 como console de monitoração da

operação do gatekeeper. Dê um telnet na porta 7000 a partir do Windows para
verificar se o serviço está respondendo. Se conectado com sucesso, execute o
comando rv e deixe a sessão telnet aberta.
Passo 6: inicie o Wireshark, desative o modo promíscuo e inicie a captura.
Passo 7: configure o cliente OpenPhone, no menu Options/General.
Figura 3.13
\\No campo Username, insira seu nome;
121
\\Para que você fique sabendo se tem alguém te ligando, clique em Browser e
escolha o arquivo ringback.wav que veio dentro do arquivo OpenPhone.rar. Caso

contrário, o OpenPhone não emitirá nenhum som;
\\Verifique se a opção marcada é DTMF as H.245 String. Não marque nenhuma

das seguintes opções: Auto-Answer, Disable Fast-Start, Disable H.245Tunneling e
Disable H.245 in Setup. Abaixo de Call Intrusion Protection Level, verifique se a
opção Full está marcada.
Figura 3.14
Clique em OK.
\\No menu Options/Gatekeeper;
Figura 3.15
122
\\Marque as opções Use Gatekeeper e Require Gatekeeper. Verifique se a opção

Static Host está marcada. Digite o IP do gatekeeper nesse campo.;
\\Deixe o campo H.235 Password em branco.
Figura 3.16
Clique em OK.
Seu registro está feito. Observe que na janela do OpenPhone está escrito que você
está registrado no gatekeeper.
Figura 3.17
Caso a mensagem mostrada acima não apareça, confira os valores de configuração

e tente novamente.
Passo 8: Em dupla, usuários deverão se registrar em um gatekeeper e efetuar

chamadas entre a dupla, finalizando a chamada e salvando a captura feita pelo
Wireshark como sip.pcap.
123
Atividade 2 – Analisando a captura feita pelo Wireshark
1. Em que modo o gatekeeper está operando?
2. Identifique os endereços IP, protocolos de transporte e portas utilizadas para a

sinalização RTP e RTCP? Descreva suas observações.
3. Visualize o gráfico gerado pelo Wireshark e descreva o que ele exibe.
124
4
Asterisk
►► Sumário
Apresentação do Asterisk. . . . . . . . . . . . . . . . . . . . 126
Projeto Zapata . . . . . . . . . . . . . . . . . . . . . . . 126
Asterisk. . . . . . . . . . . . . . . . . . . . . . . . . . 128
Asterisk e Linux . . . . . . . . . . . . . . . . . . . . . . . 129
Asterisk e a GNU General Public License . . . . . . . . . . . . . . 131
Asterisk versus PABX . . . . . . . . . . . . . . . . . . . . . 131
O que o Asterisk não é e não faz . . . . . . . . . . . . . . . . . 134
Hardware e interfaces para Asterisk . . . . . . . . . . . . . . . . 136
Zaptel Pseudo TDM interfaces. . . . . . . . . . . . . . . . . . 136
Non-Zaptel hardware interfaces . . . . . . . . . . . . . . . . . 137
Packet voice protocol. . . . . . . . . . . . . . . . . . . . . 138
Protocolos usados pelo Asterisk . . . . . . . . . . . . . . . . . 140

Atividade 1 – Instalando o Asterisk . . . . . . . . . . . . . . . . 147
Atividade 2 – Configurando e testando os clientes X-Lite, Telefone IP e ATA . . 149
125
Apresentação do Asterisk
\\Digium:
\\Criada em 1999 e localizada em Huntsville, Alabama (EUA);

\\Criadora e desenvolvedora primária do Asterisk;
\\Principal patrocinadora do Asterisk;
\\Investimento em:
\\Desenvolvimento de código-fonte;
\\Hardware de telefonia a baixo custo.
A Digium, localizada em Huntsville, Alabama, é a criadora e desenvolvedora TDM

primária do Asterisk, o primeiro PABX de código aberto da indústria. Usado em A arquitetura
TDM pode ser
conjunto com as placas de telefonia PCI, ele oferece uma abordagem estratégica
entendida como
com excelente relação custo/benefício para o transporte de voz e dados sobre
as redes digitais
arquiteturas TDM, comutadas e redes Ethernet. tradicionais de
telefonia, que
A Digium é hoje a principal patrocinadora do Asterisk e uma das líderes na indústria utilizam o TDM
do PABX em código aberto, sendo Mark Spencer o criador e principal mantenedor do (Time Division
Multiplexing)
Asterisk. Na verdade, o Asterisk funciona como uma poderosa vitrine das placas de
para transportar
telefonia fabricadas pela Digium, que também investe em versões comerciais do várias ligações
Asterisk, serviços de consultoria e suporte profissional. em um mesmo
enlace.
Projeto Zapata
\\Projeto de hardware aberto (OpenSource);
\\Desenvolve hardware para telefonia com interfaces E1 / T1;
\\As placas são produzidas por diversas empresas:

\\Exemplos:
\\Digium;
\\Sangoma;
\\Varion.
O projeto Zapata foi conduzido por Jim Dixon, o responsável pelo desenvolvimento
de hardware da Digium. O hardware também é aberto e pode ser produzido por
qualquer empresa. Hoje, as placas com E1/T1 (circuitos de telefonia digital) são
produzidas por empresas como Digium, Sangoma e Varion, entre outras.
Jim Dixon é um engenheiro consultor de telefonia inspirado pelos incríveis avanços

alcançados pela indústria de computadores em relação à velocidade de CPU. A
crença de Dixon era que sistemas de telefonia muito mais econômicos podiam ser
criados se houvesse um cartão em que fossem implantados nada mais do que os
componentes eletrônicos básicos necessários para fazer interface com um circuito de
126
telefonia. Em vez de ter componentes caros no cartão, o Sistema Digital de
Capítulo 4 – Asterisk
Processamento (DSP) seria manipulado na CPU por software. Mesmo que isso
impusesse uma tremenda carga à CPU, Dixon estava certo de que o baixo custo das
CPUs em relação ao seu desempenho fazia delas muito mais atraentes que DSPs
caros e, o que era mais importante, a sua relação custo/desempenho deveria
continuar a melhorar à medida que as CPUs aumentassem seu poder de
processamento. Depois de alguns anos, ele observou que, além de ninguém ter
criado esses cartões, nada indicava que isso seria feito. Nesse momento, ele
percebeu que, se queria uma revolução, ele mesmo deveria iniciá-la. E assim nasceu
o projeto Zapata.
Pequeno resumo da história do projeto Zapata, por Jim Dixon

“Há 20 ou 25 anos atrás, a AT&T começou a oferecer uma API permitindo aos usuários
customizar a funcionalidade de seu sistema de correio de voz e auto-atendimento,
chamada Audix. Audix rodava em plataforma Unix e custava, como tudo em telefonia
até o momento, milhares de dólares por porta, com funcionalidade bastante
limitada. Em uma tentativa de tornar as coisas possíveis e atrativas (especialmente
para quem não tinha um PABX AT&T), alguns fabricantes lançaram uma placa que
podia ser colocada em um computador que rodava DOS e respondia a uma única
linha telefônica (FXO apenas). As placas não tinham uma qualidade tão boa quanto
as atuais, e muitas terminaram como secretárias eletrônicas igualmente ruins.
Novas placas de telefonia foram lançadas com preços elevados e as companhias

gastavam milhares de dólares por porta. Afinal de contas, mesmo com as margens
altas de muitos fabricantes, as placas de telefonia possuíam muita capacidade de
processamento na forma de DSPs, processadores de sinais digitais. Ainda hoje, se
você observar um gateway de voz sobre IP, vai observar que boa parte do custo
ainda está relacionada aos DSPs.
No entanto, o poder de processamento dos microcomputadores continuou

crescendo. Para comprovar o conceito inicial, comprei uma placa Mintel 89000C
“ISDN Express Development Card” e escrevi um driver para o FreeBSD. A placa
ocupou pouco processamento de um Pentium III 600 Mhz, provando que se não
fosse a limitação do I/O (a placa gerenciava de forma ineficiente o I/O, exigindo
muitos wait-states) ela poderia atender de 50 a 75 canais. Como resultado do
sucesso, saí e comprei o necessário para criar um novo desenho de cartão ISA que
usasse o I/O de forma eficiente. Consegui dois T1s (48 canais) de dados transferidos
sobre o barramento e o computador gerenciou isto sem problemas. Então eu tinha
as placas e as ofereci para venda (umas 50 foram vendidas), disponibilizando o
desenho completo (incluindo arquivos de plotagem da placa) na web.
Como o conceito era revolucionário e faria ondas na indústria, decidi colocar um

nome inspirado no revolucionário mexicano (Emiliano Zapata) e decidi chamar a
placa de “tormenta”. Assim começou a telefonia Zapata. Escrevi um driver completo
e coloquei na rede. A resposta que obtive foi quase sempre a mesma: “Ótimo, e
você tem para Linux?”.
127
Pessoalmente, nunca havia visto o Linux rodar antes, mas fui correndo ao Fry’s
(uma loja enorme de produtos eletrônicos, famosa nos EUA) e comprei uma cópia
do Linux Red Hat 6.0. Dei uma olhada nos drivers e usei o Vídeo Spigot como base
para traduzir o driver de BSD para Linux.
De qualquer forma, minha experiência com Linux não era grande e comecei a ter
problemas para desenvolver o módulo do kernel na forma de módulos carregáveis.
Ainda assim, liberei-o na web sabendo que algum guru em Linux iria rir dele e talvez
me ajudasse a reformá-lo em “linuquês” apropriado. Em 48 horas, recebi um e-mail
de um cara do Alabama (Mark Spencer), que se ofereceu para fazer exatamente isto.
Ele disse que tinha algo que seria perfeito para a coisa toda (o Asterisk).
Nesse momento, o Asterisk era um conceito funcional, desprovido de um

funcionamento prático e útil. O casamento do sistema de telefonia Zapata e o
desenho da biblioteca de hardware/driver e interface permitiram que ele crescesse
para ser um PABX real que poderia falar com telefones reais e linhas.
Mark era brilhante em VoIP e em redes na parte interna do sistema, com grande
interesse por telefonia, mas sua experiência com o funcionamento de sistemas de
telefonia era limitada, particularmente na área de interfaces de hardware. Desde o
início eu estava e sempre estive lá para ajudá-lo nessas áreas, fornecendo
informações e implementando códigos nos drivers e no switch (PABX). Nós, e mais
recentemente outros, fazemos um bom time trabalhando no objetivo comum de
levar o melhor da tecnologia de telecomunicações ao público por um custo realista.
A partir do cartão ISA, desenhei o “Tormenta 2 PCI Quad T1/E1”, que Mark vende
como Digium T400P e E400P, e que agora a Varion está vendendo como V400P
(ambos T1 e E1). Todos os arquivos do projeto (incluindo fotos e arquivos de
plotagem) estão disponíveis em zaptelephony.org (www.zaptelephony.org) para uso
público. Como qualquer um pode ver, com o trabalho dedicado de Mark (assim
como o meu e o de outras pessoas) nos drivers da Saptel e no software do Asterisk,
as tecnologias crescem e melhoram a cada dia”.
Asterisk
\\É um PABX (Private Automatic Branch eXchange) implementado em software;
\\Permite conectividade em tempo real entre redes PSTN e redes VoIP;
\\Primeiro PABX de código aberto do mercado:

\\Criado pela a Digium Inc.
O Asterisk é um software (um programa de computador) que implementa funções de

PABX. Foi desenvolvido de acordo com a filosofia do código livre e é disponibilizado
livremente sob os termos da GPL (General Public License). 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 e suporte
128
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 (PSTN – Public Switched Telephony Network)
a uma rede de telefonia IP. Também será possível construir novas aplicações de voz
para o sistema de telefonia tradicional.
\\Escrito totalmente na linguagem C;
\\Desenvolvido para plataforma Linux;
\\Kernel 2.4 ou superior;
\\Portado para Solaris, FreeBSD e OpenBSD;
\\Possibilidade de alteração de código de acordo com o cliente.
Asterisk e Linux
\\Por que utilizar o Linux?
\\Ambos são soluções Open Source (Asterisk e Linux);
\\Hardware para acesso a PSTN; toda a implementação do Asterisk é voltada
para a plataforma Linux;
\\Licenciamento duplo:
\\GPL;
\\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, este é o sistema
operacional de suporte nativo do Asterisk. Também funciona em OpenBSD, FreeBSD
e MAC OS X. Portar o Asterisk para outros sistemas baseados no Unix deve ser uma
tarefa relativamente fácil para pessoas com tempo e habilidade com estes sistemas.
GNU General Public License (Licença Pública Geral), GNU GPL ou simplesmente
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.
129
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 4 liberdades:
\\De executar o programa para qualquer propósito (liberdade nº0);
\\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 esta liberdade;
\\De redistribuir cópias de modo a ajudar o próximo (liberdade nº2);
\\De aperfeiçoar o programa e liberar os aperfeiçoamentos de modo que toda a

comunidade seja beneficiada por eles (liberdade nº 3). O acesso ao código-fonte
é um pré-requisito para esta 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 a
BSD e a 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 com
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 com o 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 compartilhada 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.
130
Asterisk e a GNU General Public License
\\Existem algumas formas para se contribuir com a evolução do Asterisk:
\\Desenvolvimento de código;
\\Conserto de bugs;
\\Relato de melhorias;
\\Novas aplicações;
\\Documentação;
\\Canal IRC e mailing list.
O Asterisk é distribuído mediante os termos da licença GPL (GNU General Public

License). Esta licença permite a distribuição do Asterisk em forma de código ou em
forma binária, com ou sem modificações. Sendo você um desenvolvedor, é possível
contribuir com o código-fonte do Asterisk, consertando eventuais bugs, relatando
melhorias, novas aplicações e drivers para os canais. Geralmente essas
contribuições são disponibilizadas no CVS (Concurrent Version System), para que
outros desenvolvedores possam testar e aprimorar os novos códigos.
Caso não seja um desenvolvedor, pode-se contribuir com a evolução do Asterisk de

uma maneira muito importante, escrevendo toda a sua experiência em configuração
de ambientes e aplicações de voz utilizando o Asterisk. A documentação sobre o
Asterisk pode facilitar o aprendizado de pessoas interessadas.
Também é possível contribuir com o projeto através da participação de discussões e

depois repassar o conhecimento obtido a outros usuários em um canal IRC (Internet
Relay Chat): irc.freenode.net, ou em uma lista de e-mail (http://lists.digium.com).
Asterisk versus PABX

\\As soluções de telefonia encontradas no mercado normalmente têm custo
elevado;
\\Tradicionalmente há dificuldade para a adoção de novas funcionalidades:

\\Novas funcionalidades significam novos custos;
\\Dificuldades de instalação;
\\Em geral implica a compra de novo hardware.
\\Vantagens do Asterisk em relação a PABXs:

\\Custo mais atrativo;
\\Possui um leque superior de funcionalidades:
\\Novos serviços são adicionados ao código-fonte.
\\Novas funcionalidades não implicam a compra de novos equipamentos;
\\Controle de seu sistema de telefonia;
131
\\Ambiente de desenvolvimento fácil e rápido;
\\Plano de discagem flexível e poderoso;

\\Código aberto.
\\Funções básicas:
\\Voice mail (mensagem de voz por e-mail);
\\Música em espera (mp3);
\\Salas de conferência;
\\Parking (estacionamento de chamadas);
\\Caller ID;
\\Siga-me;
\\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
implementaçã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 preparado 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.
Ter controle do seu próprio sistema de telefonia é um dos benefícios que o Asterisk
oferece. Ao invés 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 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. Por outro lado, cada nova funcionalidade em sistemas
convencionais exige a aquisição de nova licença e, quase sempre de novo hardware.
Além de tudo, 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 pode ser entendido
como um sistema de voz sobre IP que pode ser interligado ao sistema de telefonia
132
convencional com a instalação de placas especiais. Assim, já traz embutidas as
vantagens das soluções de telefonia IP, como a possibilidade de aproveitar 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:
\\Identificador de chamada;
\\Siga-me;
\\Transferência assistida ou cega;
\\Pêndulo;
\\Desvios baseados no chamador;
\\Secretária eletrônica (com envio da mensagem por e-mail);
\\Música em espera (configurável por contextos);
\\Conferência;
\\Estacionamento de chamadas;
\\Funções avançadas:
\\Resposta Interativa por Voz (IVR);
\\Billing (tarifação) utilizando o registro detalhado das chamadas (CDR);
\\Queue (filas de chamadas);
\\Fax over IP;
\\Gravação de conversas ou conferências;
\\Entrega automática de chamadas (ACD);
\\Call pickup.
Iteractive Voice Response (IVR)

Também conhecida como URA (Unidade de Resposta Audível), serve para criar
menus de navegação. Desta 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 utilizado 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.
133
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, esta
função permite um 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
realizadas e recebidas pelo sistema. A partir desta 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 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

especializados, 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 obter informações estatísticas das chamadas nas filas, como tempo
médio de espera de uma chamada em determinada fila e taxa de desistência.
Gateway Fax-Email
É 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, 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

\\Sistema comum de telefonia;
\\SIP Proxy:
\\OpenSER.
\\Gatekeeper H.323:
\\GnuGK.
\\Não executa nativo no Windows;
134
\\O Asterisk possui como principal característica a flexibilidade:
\\Todos os seus arquivos são configuráveis.
\\Qualquer alteração em um de seus arquivos terá efeito em todo o sistema:

\\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). Isto
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 grande instalações
VoIP são OpenSIPS, que funciona como SIP Proxy, e GnuGK, que funciona como
gatekeeper. Em grandes redes, o Asterisk deve trabalhar em conjunto com outras
ferramentas mais apropriadas para esta finalidade, exercendo o papel de gateway
(traduzindo protocolos ou interfaceando com sistema de telefonia convencional) ou
de servidor de aplicações de voz.
O Asterisk é altamente flexível, com configuração totalmente baseada em arquivos

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, CDR (Call Detail Record) etc.
Cada módulo possui um arquivo separado e de fácil entendimento. Além disso,
utilizando AGI (Asterisk Gateway Interface) 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 recebimento do número,
o sistema procura o status do cliente em um banco de dados e, dependendo da
informação retornada, decide a ação a ser executada.
135
Hardware e interfaces para Asterisk
\\Tecnologias suportadas:
\\O Asterisk foi desenvolvido para permitir a adição de novas tecnologias e
interfaces com facilidade;
\\Seu objetivo é suportar todo tipo possível de tecnologia de telefonia;
\\Em geral, as interfaces podem ser divididas em três:
\\Zaptel hardware;
\\Non-Zaptel hardware;
\\Packet voice.
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. De forma
geral, as interfaces são divididas em três categorias: Hardware Zaptel, Hardware
não-Zaptel e pacotes de voz.
ISDN4Linux – Basic rate ISDN Interface for Linux

OSS/Alsa – Sound card interfaces
Linux Telephony Interface (LTI) – Quicknet internet ihonejac/Linejack
Dialogic hardware1 – Full-duplex Intel/Dialogic hardware
Figura 4.1
Session Initiation Protocol (SIP)

Inter-Asterix eXchange (IAX) versions 1 and 2
Media Gateway Control Protocol (MGCP)
ITU H.3232
Voice over Frame Relay (VOFR)
Figura 4.2
Zaptel Pseudo TDM interfaces

\\Zaptel Pseudo TDM interfaces, disponíveis em: www.digium.com:
\\Para uma variedade de interfaces de rede:
\\PSTN, POTS;
\\T1, E1;
\\PRI, PRA:
\\T100P Single Span T1 ou PRI connections;
\\T400P Quad Span T1 ou PRI connections.
136
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.
TDM (Time Division Multiplexing) ou Multiplexação por Divisão do Tempo, em

telefonia significa 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. Em uma
interface E1, padrão utilizado no Brasil e na Europa, existem 32 time slots, sendo o
TS0 utilizado para sincronismo e o TS16 para transporte das informações das
ligações. Os outros 30 time slots – TS1 a TS15 e TS17 a TS31, são os 30 canais
de voz da interface E1.
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 FXS (Foreing Exchange Station) e FXO (Foreing Exchange Office). Essas
interfaces também são conhecidas como POTS (Public Old Telephony System). O
sistema de telefonia que compreende as duas tecnologias (analógica e digital) é
conhecido como PSTN (Public Switched Telephony Network), a Rede de Telefonia
Pública Comutada.
Non-Zaptel hardware interfaces

\\Conectividade a outros tipos de interfaces;
\\Exemplo de hardware suportado pelo Asterisk para conexão a PSTN:

\\Zaptel – TDM400P.
As interfaces não-Zaptel proveem conectividade a outros tipos de interfaces. Essas

interfaces 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 4 entradas que permite a inserção de até 4 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 criação de várias combinações de interface.
Figura 4.3
Zaptel TDM400P
137
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: www.digium.com.
Fabricantes como Sangoma e os nacionais Khomp e DigiVoice possuem placas e

soluções com densidades diferentes. Também possuem placas com DSP (Digital
Signal Processor), provendo integração dos codecs mais utilizados e assim aliviando
consideravelmente a carga de processamento no servidor.
Protocolos de
Telefonia IP
SIP Interface de rede

(Ethernet ...) Linhas
IAX2 Digitais
MGCP Placas de E1
comunicação
H323 T1
BRI
...
PC / Servidor
Linhas
Analógicas Figura 4.4
Esta figura 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. Neste exemplo, o Asterisk pode
funcionar como um gateway entre as redes de telefonia IP e a tradicional (TDM).
Packet voice protocol

\\Únicas interfaces que não requerem um hardware específico Asterisk Gateway
Interface (AGI):
\\Interface padrão:
\\AGI;
\\EAGI;
\\Dead AGI;
\\Fast AGI.
\\Os scripts são utilizados em lógica avançada.
\\AGI permite também comunicação com bancos de dados relacionais:
138
\\PostgreSQL;
\\MySQL:
\\Acesso a outros recursos externos.
\\Scripts AGI podem ser escritos em quase todas as linguagens de programação

moderna, como:
\\Perl;
\\PHP;
\\Python.
Packet Voice Protocol são protocolos para comunicação em redes comutadas por
pacotes, como IP e Frame Relay. As interfaces de “packet voice”, ou numa tradução
livre, de pacotes de voz, não requerem placas específicas. Elas utilizam a
infraestrutura de rede disponível com o servidor.
É possível montar uma rede de telefonia totalmente baseada em “packet voice”. Assim
não seria necessário possuir nenhuma interface para telefonia no servidor. Por outro lado,
os telefones tradicionais devem ser trocados por telefones IP, que são bem mais caros.
AGI (Asterisk Gateway Interface) é uma interface muito similar ao Common Gateway
Interface (CGI) para o HTML. Ela oferece uma interface padrão pela qual programas
externos podem controlar o plano de discagem do Asterisk. Utilizar AGI é uma
maneira elegante de estender a capacidade do Asterisk. É possível criar programas
em qualquer linguagem (shell script, C, php, perl, java, pascal, python), que podem
controlar o plano de discagem do Asterisk e também podem interagir com o sistema
e a rede de dados, conforme a vontade e necessidade do programador.
\\AGI – pode controlar o plano de discagem;
\\EAGI – possibilidade de acessar e controlar o canal de som, além da interação

com o plano de discagem;
\\Dead AGI – permite acesso ao canal morto após um hangup*, tendo sido
descontinuado após o Asterisk 1.6;
\\Fast AGI – permite que o script AGI seja chamado pela rede, para que múltiplos
servidores Asterisk possam chamar scripts AGI de um local centralizado.
* Neste caso, mesmo que a ligação tenha sido desligada e um comando hangup
tenha sido executado, o canal continuará no estado UP até que o programa
termine, criando um canal morto. Isto pode gerar inconsistências diversas na
aplicação, por exemplo no CDR que continuará contabilizando a chamada até o
canal ser fechado propriamente.
Normalmente, scripts AGI são utilizados na lógica avançada, na comunicação com

bancos de dados relacionais e no acesso a outros recursos externos. Passar o
139
controle do plano de discagem para um script AGI externo permite que o Asterisk
execute facilmente tarefas que de outra forma seriam difíceis ou impossíveis.
O AGI funciona fazendo com que o programa se comunique com o Asterisk por meio
do standard input (em um programa normal seria o teclado, no AGI é o Asterisk que
envia estes dados) e do standard output (em um programa normal seria a tela do
computador, no AGI o programa envia comandos como se estivesse escrevendo na tela).
Base de Dados
d)
ecor CDRs
il R
eta
ll D
Ca
R(
CD
Dia
lpla
Asterisk nC
ont
rol
Programa C / C++
externo Java / .Net
Python
Figura 4.5
Bash Exemplos de uso
[ ... ] AGI
Esta figura ilustra os conceitos apresentados em slides anteriores, onde temos um

programa externo que nos dá controle do plano de discagem do Asterisk, permitindo
também ter acesso a seu banco de dados para uma coleta de CDRs com o intuito
de que seja realizada alguma operação (billing, tempo gasto em uma ligação por um
cliente etc.).
Protocolos usados pelo Asterisk

\\Uso de protocolos VoIP no Asterisk:
\\Estabelecer as conexões;
\\Determinar o ponto de destino;
\\Estabelecer questões relacionadas à sinalização de telefonia, como:
\\Indentificador de chamada;
\\Desconexão.
\\IAX e o Asterisk:
\\Protocolo aberto;
\\Histórico:
\\Desenvolvido pela Digium com o propósito de comunicação com outros

servidores Asterisk;
\\Protocolo de transporte;
140
\\Utiliza porta UDP (4569):
\\Canais de sinalização;
\\Tansporte de mídia.
\\No IAX, usuários são autenticados de três formas:

\\Plain text;
\\MD5 hashing;
\\RSA.
\\Facilidades do IAX:
\\Fornece controle e transmissão de voz sobre redes IP;
\\Utiliza qualquer tipo de mídia, como:
\\Voz;
\\Vídeo.
\\Características do IAX:
\\Derivado da experiência dos protocolos:
\\SIP;
\\MGCP.
\\Utiliza o mesmo protocolo para sinalização e mídia em uma mesma porta

UDP.
\\Objetivos do protocolo IAX:

\\Minimizar o uso de banda;
\\Prover transparência à NAT;
\\Facilidade de uso na presença de firewalls;
\\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” de 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 afirmativamente 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 este conjunto de ações definirem o início da
conversação (bom-dia), o acompanhamento (“uhum”) e o término (tchau) da conversa.
141
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 estabelecimento da conversa. Esta 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, FTP, exemplos de protocolos para transferência de informação.
Em VoIP não é diferente; H.323, SIP, MCGP e IAX são protocolos de Voz sobre IP
suportados pelo Asterisk, e 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:
\\SIP (Session Initiation Protocol);
\\H.323 (padrão definido pela ITU);
\\IAX (Inter-Asterisk eXchange Protocol) v1 e v2;
\\MGCP (Media Gateway Control Protocol);
\\SCCP (Cisco Skinny), protocolo proprietário da Cisco.
Protocolo IAX
O IAX (Inter Asterisk eXchange) foi desenvolvido pela Digium com o propósito de
comunicaçã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. Esta 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:
\\MD5 Message-Digest (conforme a RFC 1321) – neste 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.
\\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.
142
Como já sabemos, o IAX utiliza apenas a porta UDP 4569 tanto para a sinalização
das chamadas 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 H323 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 ao invés de descrever textualmente a
informação. Estas características tornam o IAX um protocolo mais rápido e eficiente
para tratamento de chamadas.
NAT (Network Address Translation) é um recurso de tradução de endereço de rede

muito comum, usado quando é necessário ligar mais de um dispositivo de rede a
internet, mas só há um endereç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
consegue saber o par de portas através do qual o canal de mídia será transmitido.
Esta 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.
Já 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, este artifício consome recursos computacionais do firewall
e deve ser evitado quando possível.
O protocolo IAX resolve facilmente estes 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 neste
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
143
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 um 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
desta conta indica um 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:

\\Frame completo;
\\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 associados a ele em qualquer uma das direções. O
horário (timestamp) pode ser um campo 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
Figura 4.6
Frame completo
OSeqno ISeqno Frame Type C Subclasse
do IAX
A figura ilustra o formato binário de um frame completo.
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 significa 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 contexto. O número de sequência do fluxo de saída (outbound)
“OSeqno” inicia com 0 e é incrementado 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.
144
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
Figura 4.7
Dados
Miniframe do IAX
O miniframe é usado para enviar áudio ou vídeo (mídia) com um mínimo de

sobrecarga de protocolo. O formato do miniframe é o apresentado na figura.
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 completo é enviado para permitir que o outro lado sincronize.
Uma descrição completa do protocolo IAX pode ser encontrada na RFC 5456 ou em:
\\www.cornfed.com/iax.pdf
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 de 0 para a transmissão inicial.
Destination Call Número de chamada de destino do lado receptor do frame.

Number
Timestamp Timestamp completo, 32 bits.
OSeqno Número de sequência do fluxo de saída.
ISeqno Número de sequência do fluxo de entrada.

Tabela 4.1 Frame Type Tipo de frame.
Campos do
frame completo C Formato do valor da subclasse.
do IAX Subclasse Subclasse.
145
Campo Descrição
F Marcado para 0 indica que é um frame incompleto
Source Call Number Número de chamada originador do lado de transmissão

do frame completo
Tabela 4.2
Timestamp Timestamp completo, 16 bits.
Campos do
Dados Dados Miniframe do IAX
SIP IAX H.323
Vantagens Largamente Uso eficiente da Larga adoção pelo

implementado banda; mercado;
pelas operadoras Transparente a Padrão de
VoIP; implementações de videoconferência;
Padrão de fato para NAT; Essencial na
a telefonia IP no Simples e rápido. conectividade com
momento. projetos mais
antigos.
Tabela 4.3
Desvantagens Problemas com Protocolo ainda Arquitetura
Comparativo
NAT e FW. pouco difundido, complexa
implementado em Problemas com entre IAX, SIP e
poucos dispositivos. NAT e FW. H.323.
Este quadro resume as qualidades e defeitos dos dois principais protocolos,

confrontando-os com o IAX, o protocolo feito para o Asterisk.
Resumo
\\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.
\\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.
\\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.
146
4
\\A atividade tem por objetivo instalar e configurar o Asterisk.

\\Ao final desta prática o aluno irá aprender a instalar e configurar o Asterisk.

\\1 hora a 1h30 minutos (trabalho individual).
Requisitos
\\Esta prática envolve atividades individuais.
Descompacte a máquina virtual para o desktop e troque o nome do diretório para Asterisk.
Atividade 1 – Instalando o Asterisk
Nesta atividade efetuaremos a instalação do Asterisk em uma máquina virtual Debian.
Passo 1: inicie a máquina virtual com sistema operacional Debian no diretório Asterisk.
147
Se for apresentada a tela abaixo selecione a opção I copied it.
Figura 4.8
Passo 2: execute o comando: apt-get update
Passo 3: execute o comando: apt-get install asterisk
Ao término da instalação do Asterisk, o arquivo asterisk localizado no diretório /etc/

default deverá ser editado.
Somente a linha RUNASTERISK=no deverá ser modificada, alterando o valor de no

para yes.
Uma instalação típica inclui vários arquivos de configuração padrão, normalmente

localizados em /etc/asterisk, sendo os mais importantes para começar:
\\asterisk.conf;
\\extensions.conf;
\\sip.conf;
\\voicemail.conf.
Para nossa primeira atividade, primeiro editaremos o arquivo sip.conf, onde

definiremos os softphones disponíveis na rede.
O arquivo sip.conf é dividido em duas partes, onde a primeira é uma seção de

configurações gerais, que pode ser deixada com quase todas as entradas com o valor
padrão. A segunda é composta por entradas de telefones individuais para cada aparelho.
Passo 4: o arquivo sip.conf será o primeiro arquivo a ser editado. Abra o arquivo:
# vi /etc/asterisk/sip.conf
Mude o bindaddr para o endereço da sua máquina virtual (será o IP do servidor).
148
No fim do arquivo, adicione os novos ramais:
;RAMAL PARA O X-LITE
[10XX]
type=friend
secret=voip
Host=dynamic
Canreinvite=no
;RAMAL PARA O TELEFONE IP
[20XX]
type=friend
secret=voip
Host=dynamic
Canreinvite=no
;RAMAL PARA O ATA
[30XX]
type=friend
secret=voip
Host=dynamic
Canreinvite=no
Salve o arquivo e reinicie o serviço:
# /etc/init.d/asterisk restart
Atividade 2 – Configurando e testando os clientes X-Lite, Telefone IP e ATA
X-Lite
Passo 1: configure o cliente X-Lite para o registro em seu servidor Asterisk. Observe
se a mensagem Ready será exibida no display do cliente.
Display Name: 10XX

User name: 10XX
Password: voip
Authorization user name: 10XX
Domain: <IP_do_servidor_Asterisk>
Domain Proxy: <IP_do_servidor_Asterisk>
149
Telefone IP
Line 1
Display Name: 20XX
Address: 20XX
Auth User ID: 20XX
Auth Password: voip
Server 1
Address: <IP do servidor Asterisk>
Port: 5060
Transport: DNSnaptr
ATA
Proxy: <IP do servidor Asterisk>

Display Name: Entre com o seu nome completo
User ID: 30XX
Password: voip
Register Expires: 3600
Volte para a máquina virtual e se conecte no console do Asterisk com o comando

asterisk -r.
Certifique-se de que o X-Lite foi registrado visualizando a lista de peers no console

SIP, utilizando o comando sip show peers.
Passo 2: teste os clientes e o servidor efetuando uma chamada para o ramal 1000
do X-Lite, do Telefone IP e do ATA.
Ouça a mensagem em inglês e observe as opções apresentadas na mensagem.
“Congratulations. You have successfully installed and executed the Asterisk open
source PBX. You have also installed a set of sample sounds and configuration files
that should help you to get started. Like a normal PBX, you will navigate this
demonstration by dialing digits. If you are using a console channel driver instead of a
real phone you can use the dial, answer, and hang up commands to simulate the
actions of a standard telephone.”
Opções
200 Para maiores informações
600 Para teste de eco (excelente para teste de atraso)

Tabela 4.4
# Para retornar ao menu
150
5
Arquitetura do Asterisk
►► Sumário
Arquitetura do Asterisk . . . . . . . . . . . . . . . . . . . . 152
Introdução a canais analógicos e digitais . . . . . . . . . . . . . . 156
Dual Tone Multi Frequency (DTMF). . . . . . . . . . . . . . . . 159
Gateway de voz sobre IP. . . . . . . . . . . . . . . . . . . . 160
Loop start . . . . . . . . . . . . . . . . . . . . . . . . . 162
Ground start. . . . . . . . . . . . . . . . . . . . . . . . 163
Kewl start . . . . . . . . . . . . . . . . . . . . . . . . . 163
Estrutura dos arquivos de configuração . . . . . . . . . . . . . . 165
Organização dos arquivos de configuração . . . . . . . . . . . . . 167
Introdução às aplicações . . . . . . . . . . . . . . . . . . . 168

Atividade 1 – Configurando um novo ramal . . . . . . . . . . . . . 171
151
Arquitetura do Asterisk
\\O Asterisk possui uma arquitetura simples, diferente da maioria dos produtos
de telefonia;
\\Atua como um intermediador entre: Internet e Telephony applications

\\Tecnologias de telefonia:
\\IAX;
\\SIP;
\\H.323.
Asterisk
\\Aplicações da telefonia:
\\Conferência de voz;
\\Secretária eletrônica; Figura 5.1
Internet e Telephony technologies
\\Estacionamento de chamadas.
\\Limitações da arquitetura do Asterisk:

\\Usa a CPU do servidor para processar os canais de voz;
\\Sistema muito dependente da performance da CPU;
\\Requer acesso de alta prioridade frequente para a CPU.
\\Canais do Asterisk:
\\Conexões lógicas para a trajetória das sinalizações e transmissões;
\\As conexões podem ser:
\\Físicas;
\\Baseadas em software.
\\As regras para os canais são definidas no plano de discagem.
\\Os canais têm vários tipos de formatos:

\\Circuitos físicos:
\\FXO – Foreign eXchange Office;
\\FXS – Foreign eXchange Station;
\\PRI – Primary Rate Interface;
\\BRI – Basic Rate Interface.
\\Baseados em software:
\\SIP – Session Initiation Protocol;
\\IAX – Inter-Asterisk eXchange Protocol.
\\Canais internos do Asterisk:
\\Agent;
\\Local;
\\TDMoE – TDM over Ethernet.
152
Em essência, o Asterisk atua como um mediador, conectando as tecnologias de
Capítulo 5 – Arquitetura do Asterisk

telefonia às aplicações da telefonia, criando assim 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, R2D, e ainda as linhas analógicas
conhecidas como POTS e/ou PSTN. Já as aplicações de telefonia incluem: call
bridging, conferência de voz (conferencing), secretária eletrônica (voicemail), IVR
scripting (URA – Unidade de Resposta Audível) e estacionamento de chamadas (call
parking), entre outras.
Asterisk Application API
Codec
Translator
Asterisk File Format API

Codec Translator API
Application Scheduler and

Laucher I/O Manager
PBX Switching
Core
Dinamic
Module
Loader
Asterisk Channel API

Figura 5.2
Dynamic Module Loader

Módulo responsável por carregar e inicializar todos os drivers necessários, providos por:
\\Drivers de canal (channel drivers);
\\Formato de arquivos (file formats);
\\Detalhe de chamadas gravadas (call detail records);
\\Codecs;
\\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 converter os codecs.
153
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:
\\Fazer um telefone tocar;
\\Conectar-se ao correio de voz;
\\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, ao invés 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
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:
\\FXO (Foreing Exchange Office) – interfaces analógicas utilizadas para a

comunicação com a operadora ou posição de ramal de um PABX;
\\FXS (Foreing Exchange Station) – interfaces analógicas para ligação de ramais

tradicionais;
\\PRI (Primary Rate Interface) – serviço RDSI (Redes Digitais de Serviços

Integrados) 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, é utilizada a interface T1 e,
neste caso, a quantidade de canais para voz diminui para 24;
\\BRI (Basic Rate Interface) – 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;
154
\\SIP (Session Initiation Protocol) – protocolo utilizado na telefonia IP;

\\IAX (Inter Asterisk eXchange) – protocolo utilizado na telefonia IP, proprietário
do Asterisk;
\\Agent – canal proxy de distribuição de chamadas em fila para atendentes, muito

utilizado em implementações para centrais de atendimento;
\\Local – utilizado na lógica de programação do Asterisk, faz loops com as

chamadas dentro do plano de discagem, em contextos diferentes;
\\TDMoE – canal especial do Asterisk que simula conexões TDM (Time Division
Multiplexing) na camada de enlace da rede local, útil para interligar dois ou mais
servidores Asterisk na mesma LAN (Local Area Network).
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.
Skinny Um driver para o protocolo dos telefones IP da Cisco.
VOFR Voz sobre Frame Relay.
VPB Linhas telefônicas para placas da Voicetronix.

Tabela 5.1
Canais que o ZAP Para conectar telefones e linhas com placas da Digium. Também
usado para TDMoE e para Asterisk ZPHFC (ISDN em modo NT).
Asterisk suporta
Outros canais do Asterisk:
\\H.323 – protocolo de voz sobre IP do ITU;
\\MGCP – protocolo de voz sobre IP;
\\Modem – utilizado em linhas ISDN (Integraded Services Digital Network);
\\NBS – utilizado para broadcast de som;
\\Phone – utilizado para telefonia no Linux;
\\Skinny – protocolo de voz sobre IP utilizado nos telefones da Cisco;
\\VOFR – voz sobre Frame Relay;
155
\\VPB – canais de voz das placas Voicetronix;
\\ZAP – canais de voz das placas baseadas no projeto Zapata (placas digitais
da Digium).
Conforme mais empresas desenvolvem soluções para Asterisk, esta 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.
Introdução a canais analógicos e digitais

\\Revisão dos conceitos de telefonia
\\A maior parte das implementações de telefonia usa fios metálicos:
\\Tip;
\\Ring.
\\Loop fechado:
\\Telefone recebe o tom de discagem da central telefônica:
\\Sinalização do tipo loop-start;
\\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 discagem 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 deste laço, tantas vezes
quanto o número discado. Dizemos que este tipo de sinalização é do tipo loop start.
Existem outras sinalizações menos comuns, como ground start.
\\Loop start – técnica para sinalização de chamada telefônica usada por

praticamente todas as linhas analógicas;
\\Ground start – técnica de sinalização de telefonia utilizada geralmente em linhas

telefônicas conectadas a um PABX.
\\Existem basicamente três tipos de sinalização:

\\Sinalização de supervisão:
\\On-hook (no gancho);
\\Off-hook (fora do gancho);
\\Ringing (tocando);
\\Sinalização de endereçamento;
\\Sinalização de informação.
\\Ajustes de tons deve ser realizado no arquivo indications.conf..
156
De forma muito resumida pode-se dizer que:

\\Sinalização de supervisão – indica se o telefone está no gancho (On-hook), fora
do gancho (Off-hook) ou tocando (Ringing);
\\Sinalização de endereçamento – indica os números que foram marcados pelo usuário;
\\Sinalizaçãode informação – indica se o telefone chamado está ocupado, se o

número marcado está errado etc. Podemos destacar os seguintes eventos:
\\Tom de discagem;
\\Sinal de ocupado;
\\Tom de retorno (ringback);
\\Congestionamento (congestion);
\\Número inválido;
\\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. Você pode ajustar os tons do Asterisk para o padrão brasileiro através
do arquivo indications.conf.
On-hook (no gancho)

IDLE State
PBX Telefone
TIP
ON-Hook
RING
Bateria
Figura 5.3
IDLE State 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. Neste caso, o circuito está em estado on-hook.
Quando o telefone está nesta 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.
157
Off-hook (fora do gancho)
Telefone inicia chamada
PBX Telefone
TIP
corrente
elétrica OFF-Hook
RING
Bateria
Figura 5.4
Telefone inicia
Detector de corrente chamada
O usuário que deseja fazer uma chamada telefônica deve passar para o estado off-
hook, retirando o telefone do gancho. Este 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 originado 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 deste 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 10 aberturas no
circuito. Com a evolução, as centrais telefônicas modernas passaram a utilizar a
sinalização multifrequêncial, 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.
158
Dual Tone Multi Frequency (DTMF)

\\Teclado de discagem
\\Frequencias altas e baixas
\\Indica para a central o número discado
1209 1336 1477 1633
697 1 2 3 A
770 4 5 6 B
852 7 8 9 C
Figura 5.5
941
* 0 # D
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 destes dois tons
indica para a central os dígitos selecionados. Este mecanismo é conhecido como
DTMF (Dual Tone Multi Frequency).
Na figura 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 1633 hertz correspondente aos
algarismos A, B, C e D é 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:
\\Tom de discagem – normalmente um tom contínuo, que indica que a linha está
disponível;
\\Sinal de ocupado – tom intermitente, intercalado com 250ms de silêncio, indica

que o destino está off-hook;
\\Congestionamento – semelhante ao tom de ocupado, indica falta de recurso na

rede para completar a chamada.
Outros sinais menos comuns:
\\Tom de retorno;
\\Número inválido;
\\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.
159
Os padrões utilizados no Brasil estão descritos na prática Telebras para telefonia, e
podem ser encontrados no site da Anatel, www.anatel.gov.br.
\\Interfaces FX (Foreign eXchange):

\\Interfaces analógicas;
\\O termo “Foreign eXchange” é aplicado para troncos;
\\Duas interfaces:
\\FXO (Foreign eXchange Office);
\\FXS (Foreign eXchange Station).
Interfaces FX (Foreign eXchange) são interfaces analógicas. O termo “Foreign

eXchange” é aplicado para troncos, para o acesso à operadora de telefonia.
Resumo
Um canal da central da operadora é ligado em uma porta FXO (linha telefônica
tradicional).
Um telefone analógico convencional é ligado em uma porta FXS.
Então, é possível ligar uma porta FXO em uma porta FXS, assim como é possível
ligar um telefone à linha da operadora.
Dito de outra forma, um telefone analógico possui uma porta FXO, e um tronco
na operadora telefônica é uma porta FXS.
Gateway de voz sobre IP
Tom de discagem
FXO Companhia telefônica Figura 5.6
\\FXO (Foreign eXchange Office):

\\Interface utilizada para comunicação com Central Office ou PABX;
\\Estas interfaces conectam um PABX a outro:
\\PABX:
\\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. Esta 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.
160
É 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, em que
o telefone é concetado em uma interface FXS. Esta operação é conhecida como OPX
(Off-Promises eXtension) ou ramal remoto.
\\FXS (Foreign eXchange Station):

\\São as conhecidas linhas residenciais padrão;
\\Utilizadas para conectar dispositivos básicos:
\\Telefones;
\\Modem;
\\Fax.
\\Deve prover:
\\Voltagem;
\\Gerar “ringing”;
\\Detectar “off-hook”;
\\Indicar chamadas em processo.
As interfaces FXS (Foreign eXchange Station) 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,
88V AC a 20Hz. O sinal ringing, deve detectar o estado off-hook do telefone e
indicar chamadas em progresso.
O termo E&M é proveniente de “Ear and Mouth” (Ouvido e Boca) e indica a analogia
de uma orelha para receber sinais e de uma boca para transmitir sinais. Interfaces
E&M também são interfaces analógicas, usadas principalmente nas ligações entre
PABXs ou entre Net-Net Switches.
\\Interfaces E&M:
\\Interfaces analógicas;
\\E&M “Ear (receive) and Mouth (transmit)”;
\\Usadas em ligações entre PABXs ou entre Net-Net Switches;
\\Não estão disponíveis para o Asterisk;
\\Conhecidas no mercado como tie-lines analógicas;
\\Permitem comunicação bidirecional.
161
As placas E&M são conhecidas no mercado de telefonia como “tie-lines” analógicas,
e não estão disponíveis para Asterisk. A maioria das centrais não vem com este tipo
de interface, muito embora as centrais de marcas conhecidas possuam E&M como
um componente opcional. As placas E&M permitem uma comunicação bidirecional,
podendo dar ou receber tom. Se você precisar usar uma interface E&M com o Asterisk,
a melhor opção é a integração com um gateway de voz. A Cisco possui interfaces
E&M para a maioria de seus roteadores de voz, que podem ser integradas ao Asterisk.
\\Sinalização nos troncos:

\\Loop start;
\\Ground start;
\\Kewl start;
\\Outros (não serão abordados):
\\E&M Wink Start;
\\E&M Immediate Start;
\\E&M Delay Start.
Kewl start é o mesmo que loop start, exceto por ter uma inteligência maior e por isso
maior capacidade para detectar desconexões remotas. Desta 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 sinalização E&M está obsoleta. Esta sinalização não será abordada no
curso, pois placas E&M não estão disponíveis para o Asterisk.
Loop start
\\Usado por praticamente todas as linhas analógicas;
\\Permite ao telefone indicar os estados de:

\\On-hook;
\\Off-hook.
\\Indica ao switch os estados de:

\\Ring;
\\No ring.
\\É uma linha aberta;
\\Uma chamada entrante é sinalizada por 100 V “ring voltage”.
162
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.
Nesta 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. Este é 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
\\Semelhante ao loop start;
\\No momento de fazer uma ligação, o loop não é fechado.
Sinalização semelhante ao loop start. Neste caso, o switch da operadora permanece

fornecendo -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). Este
é o sinal para que a interface da operadora feche o circuito e envie o tom de discar.
Kewl start
\\Monitora o que o outro lado está fazendo;
\\Incorpora vantagens do loop start e do ground start.
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 irá
utilizá-lo. Kewl start tornou-se, informalmente, o padrão para o uso com o Asterisk.
Nova forma de conexão, completamente digital.
PRI
Channel B
Figura 5.7 D Channel
163
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 8 canais simultâneos), utilizar canais digitais é
uma opção mais vantajosa. 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. Esta tecnologia é conhecida
como TDM (Time Division Multiplexing – 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 chamado de canal ou link de 2 Mbps. Nos
Estados Unidos é utilizado o padrão T1, composto por 24 canais de 64 kbps.
A Telebrás estipulou que o protocolo digital padrão para comunicação dos PABX dos
assinantes com as operadoras deveria ser E&M pulsada, E&M contínua ou R2D/
MFC-5C. O protocolo 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:

\\Vantagens sobre R2;
\\Uso Flexível possibilitando uso simultâneo de dados de voz;
\\Interface E1 com possibilidade de 30 canais de voz, conhecida como
30B+D;
\\Interface T123 com canais de voz +1;
Existe ainda outro protocolo para telefonia digital, conhecido como Rede Digital de Serviços
Integrados (RDSI), do inglês Integrated Services Digital Network (ISDN), que 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 PRI (Primary Rate Interface), e tem capacidade para
endereçar 30 canais de voz, mais um canal para 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.
\\MFC/R2:
\\Sinalização definida pela ITU-T;

\\Usada principalmente na América Latina e na Ásia;
\\Utiliza CAS (Channel Associated Signaling):
\\R2 Digital Brasil:
\\Possui variações específicas para cada país.
164
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 sinalizaçã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 sinalização de linha digital mais
comum no Brasil, seguindo a Prática Telebrás TB 210-110-703.
Estrutura dos arquivos de configuração

\\O Asterisk é controlado por meio de arquivos de configuração:
\\/etc/asterisk;
\\O formato dos arquivos de configuração do Asterisk é semelhante ao formato

dos arquivos Windows (.ini);
\\Os arquivos estão em formato ASCII, divididos em seções:

\\Nomes das seções entre [ ].
\\Em seguida aos pares de colchetes:

\\ Valor separado por (=) ou (=>).
\\( ; ) 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
instanciação de objetos, muito embora possam ser utilizados indistintamente.
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]
objeto => valor ; Declaração de objeto
165
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 este 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 é associada 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

Este 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
op2 = adv
objeto => 1
op1 = int
objeto => 2
As duas primeiras linhas configuram o valor das opções op1 e op2 para “bas” e
“adv”, respectivamente. 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
166
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 um
grande volume de configuraçõ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,
respectivamente. A entidade [entidade2] tem valores valor3 e valor4 para as
opções op1 e op2.
Organização dos arquivos de configuração

\\Os arquivos de configuração do Asterisk são comumente organizados nos
diretórios abaixo:
\\Arquivos de configuração :
\\/etc/asterisk
\\Executáveis e scripts:
\\/usr/sbin/asterisk astman astgenkey safe_asterisk
\\Bibliotecas e módulos:
\\/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 destes locais podem ser personalizados no arquivo de configuração /etc/asterisk/

asterisk.conf. Outros podem ser modificados durante a compilação do programa.
\\Arquivos de configuração:
\\/etc/asterisk
167
\\Executáveis e scripts:
\\/usr/sbin/asterisk
\\/usr/sbin/astman
\\/usr/sbin/astgenkey
\\/usr/sbin/safe_asterisk
\\Bibliotecas e módulos:
\\/usr/lib/asterisk
\\/usr/lib/asterisk/modules
\\Arquivos (headers) para criação de aplicativos, drivers e módulos:
\\/usr/include/asterisk
\\PID do processo:
\\/var/run/asterisk
\\Arquivos VoiceMail e chamadas outbounds:
\\/var/spool/asterisk
\\Área de dados:
\\/var/lib/asterisk
\\Scripts usados pelo AGI:
\\/var/lib/asterisk/agi-bin
\\Banco de dados:
\\/var/lib/asterisk/astdb
Introdução às aplicações
\\Partes fundamentais do Asterisk;
\\Cada aplicação executa uma ação específica no canal em questão:

\\Emitem sons;
\\Aceitam dígitos;
\\Desligam uma chamada.
\\No CLI (Command Line Interface) é utilizado o comando show applications.
168
Aplicações

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 funcionamento. 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.
Exemplos de aplicações:
Aplicações Descrição
Answer ( ) Responde a um canal que está chamando.
AbsoluteTimeout( ) 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.
Congestion ( ) Solicita que o canal indique o congestionamento e então

espera que o usuário desligue ou que o tempo de expiração
(em segundos) acabe.
Dial( ) Permite que você conecte todos os tipos de canal.
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 5.2 VoiceMail ( ) Deixa mensagens de voz em determinada caixa postal.
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)
Neste exemplo, as ligações que chegam no 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 a chamada e prepara o
169
ambiente para tratá-la. Em seguida, a chamada é colocada em segundo plano, pela
aplicação background. Este 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’, prioridade ‘1’, ou
seja, para o início. A outra opção válida neste exemplo é o dígito 2, que executará as
prioridades 1 e 2.Qualquer outra opção será inválida.
Exemplo:
Aplicação echo()
Não são necessários parâmetros adicionais.
exten => 100,1,Answer()

exten => 100,2,Playback(welcome)
exten => 100,3,Playback(demo-echotest)
exten => 100,4,Echo()
exten => 100,5,Playback(demo-echodone)
exten => 100,6,Playback(vm-goodbye)
exten => 100,7,Hangup()
Plano de discagem para teste de eco
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).
Desconecta a chamada, liberando a linha.
170
5
\\A atividade tem por objetivo compreender e analisar os arquivos de
configurações do Asterisk.

\\Ao final desta prática o aluno conhecerá os arquivos de configuração do
Asterisk.

\\30 minutos a 1 hora (trabalho individual).
Requisitos
\\Esta prática envolve atividades individuais e em dupla.
Atividade 1 – Configurando um novo ramal
Passo 1: inicie a máquina virtual localizada no diretório Asterisk, e efetue login com
usuário root e a senha rnpesr.
Passo 2: abra para edição o arquivo executando o comando:
# vim /etc/asterisk/sip.conf
171
Passo 3: no fim do arquivo adicione o ramal incluindo as linhas conforme o exemplo
abaixo, onde XX será o número do ramal da sua dupla.
;RAMAL PARA O X-LITE

[10XX]
type=friend
secret=voip
Host=dynamic
canreinvite=no
;RAMAL PARA O TELEFONE IP

[20XX]
type=friend
secret=voip
Host=dynamic
canreinvite=no
Dialplan
;RAMAL PARA O ATA
O dialplan define
[30XX] o modo como o
type=friend Asterisk PBX irá
secret=voip lidar com
Host=dynamic chamadas de
entrada e de
canreinvite=no
saída, e também
Salve o arquivo e reinicie o Asterisk executando o comando: contém todos os
números de
# /etc/init.d/asterisk restart extensão. O
dialplan é
Tente efetuar chamadas de um softphone para o outro. A chamada não poderá ser dividido em
completada porque ainda não definimos nenhuma regra de discagem. seções chamadas
de contextos.
Cada quadro é
Passo 4: faça um backup do arquivo de configuração extensions.conf executando o
composto de
comando:
mais de uma
# cp extensions.conf extensions.conf.bak extensão.
O arquivo extensions.conf é o mais importante arquivo de configuração no PBX Extensão

Asterisk, contendo o dialplan e as extensões. Na maioria das distribuições ele fica A extensão é o
número de
localizado em /etc/asterisk.
telefone,
podendo ser
Abra o arquivo utilizando o comando: composto de
números, letras
# vi /etc/asterisk/extensions.conf
ou ambos.
Qualquer
prorrogação tem
uma prioridade e
uma aplicação.
Com a ajuda de
contextos é
possível
organizar o
dialplan.
172
Passo 5: neste passo iremos configurar o arquivo extensions.conf.

Na seção [general], altere os parâmetros abaixo:
[general]
writeprotect=yes
static=yes
Na seção default localizada no fim do arquivo, insira os parâmetros abaixo:
[default]
exten=>_10XX,1,Dial(SIP/${EXTEN},20,r)
exten=>_10XX,2,Hangup()
Passo 6: se conecte no console do Asterisk com o comando asterisk –r e execute

comando extensions reload.
Passo 7: efetue chamadas entre o X-Lite, o Telefone IP e o ATA.
173
174
6
Plano de discagem
►► Sumário
O plano de discagem. . . . . . . . . . . . . . . . . . . . . 176
Contextos . . . . . . . . . . . . . . . . . . . . . . . . . 176
Extensões. . . . . . . . . . . . . . . . . . . . . . . . . 178
Prioridades. . . . . . . . . . . . . . . . . . . . . . . . . 179
Aplicações. . . . . . . . . . . . . . . . . . . . . . . . . 179
extensions.conf . . . . . . . . . . . . . . . . . . . . . . . 180
Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . 181
Variáveis predefinidas . . . . . . . . . . . . . . . . . . . . . 183
Expressões. . . . . . . . . . . . . . . . . . . . . . . . . 183
Operadores. . . . . . . . . . . . . . . . . . . . . . . . . 184
Padrões de extensão. . . . . . . . . . . . . . . . . . . . . 185
Aplicação Background() . . . . . . . . . . . . . . . . . . . . 186
Aplicação Goto(). . . . . . . . . . . . . . . . . . . . . . . 186
Aplicação Dial() . . . . . . . . . . . . . . . . . . . . . . . 187

Atividade 1 – Primeiro plano de discagem. . . . . . . . . . . . . . 190
Atividade 2 – Configuração do plano de discagem com Background e Goto . . 191
Atividade 3 – Tratamento de erros . . . . . . . . . . . . . . . . 191
Atividade 4 – Aperfeiçoamento do plano de discagem . . . . . . . . . 192
175
O plano de discagem
\\O plano de discagem é a parte mais importante de um sistema Asterisk;
\\O arquivo extensions.conf, localizado no diretório etc/asterisk, especifica o

plano de discagem;
\\O plano de discagem é composto por quatro elementos:

\\Contextos;
\\Extensões;
\\Prioridades;
\\Aplicações.
O plano de discagem é considerado por muitos a parte mais importante de uma

implementação de PABX. Nele são definidos a lógica de atendimento, os perfis e
como cada chamada deve ser tratada. No Asterisk, o plano de discagem é definido
no arquivo extensions.conf. Portanto, este é considerado o arquivo de configuração
mais importante do Asterisk. Pode-se considerar que o plano de discagem consiste
em uma lista de instruções que deverão ser seguidas pelo Asterisk.
No plano de discagem são implementadas instruções para:
\\Perfis dos ramais usuários do sistema;
\\Roteamento de chamadas e os fatores sobre os quais as decisões serão

baseadas;
\\Variar o comportamento do sistema de acordo com o horário;
\\Auto-atendimento;
\\URA (Unidade de Resposta Audível) e filas para atendimento.
É possível separar o plano de discagem em quatro elementos: contextos, extensões,

prioridades e aplicações.
Contextos
\\Os planos de discagem são divididos em seções chamadas contextos.
\\Especificamos um contexto definindo um cabeçalho:

\\Colocamos seu nome entre colchetes [ ];
\\Exemplo:
\\[meu_contexto]
\\Exemplo:
\\[gerente] e [funcionário]
\\Dois contextos com permissões diferentes.
176
Capítulo 6 – Plano de discagem
\\Usamos contextos para implementar um número importante de recursos, como:
\\Autenticação: solicitar senha para certas extensões;
\\Segurança: podemos evitar que determinados usuários tenham acesso a
certas funções que são vetadas a outros;
\\Privacidade: bloquear certas pessoas, por exemplo.
O plano de discagem é organizado de acordo com contextos. Os contextos são

responsáveis por parte da segurança do plano de discagem. Com eles é possível
definir diferentes perfis de utilização do sistema. Por exemplo, um gerente poderá
fazer chamadas internacionais. Já um funcionário não poderá.
Os contextos estão ligados diretamente aos canais pelo arquivo de configuração de

cada canal. Quando uma ligação entra no Asterisk por um canal, ela é direcionada
para um contexto específico, identificado no arquivo de configuração deste canal. Da
mesma forma, um ramal analógico, digital ou VoIP, pode ser “colocado” em um
contexto específico na sua configuração.
Com a utilização de contextos é possível fazer com que o mesmo código se comporte
de forma diferente, dependendo do perfil associado ao contexto. Por exemplo, dentro
do contexto [gerente], quando o dígito 0 é discado, ouve-se o tom de discagem da
rede pública. Dentro do contexto [funcionário], quando o dígito 0 é discado, é
recebida uma gravação “ligação não autorizada”.
No arquivo extensions.conf., os contextos são delimitados simplesmente pela

definição de outros contextos. Exemplo:
[primeiro_contexto]
instrução01
instrução02
[segundo contexto]
instrução01
instrução02
Os contextos servem principalmente para organizar o fluxo de cada chamada no plano

de discagem. É possível configurar comportamentos diferentes para um mesmo
número, dependendo de quem liga ou de que canal uma ligação é recebida. Também
é possível controlar as permissões e perfis distintos para grupos de ramais ou usuários.
Com a separação do plano de discagem em contextos, consegue-se criar ambientes

virtualmente separados. Por exemplo, com apenas uma implementação de Asterisk,
é possível emular uma série de PABXs virtuais, cada um com seus ramais e troncos
específicos. Implementações deste tipo são importantes para uma utilização mais
eficiente de recursos.
177
Extensões
\\Os contextos são formados por extensões;
\\Uma extensão é uma instrução que o Asterisk segue, acionada por uma
chamada de entrada ou por dígitos discados em um canal;
\\A declaração de uma extensão possui o seguinte formato:

\\exten=> número, prioridade, aplicação:
\\Número ou nome da extensão;
\\Prioridade;
\\Aplicação.
\\As extensões seguem a forma:

\\exten=> nome, prioridade, aplicação()
\\Um exemplo prático de uma extensão poderia ser:

\\exten=1001,1,Answer()
\\Neste exemplo, o nome da extensão é 1001, a prioridade é 1 e a

aplicação é answer.
\\A extensão especial “s”:

\\Quando uma ligação entra em um contexto, sem estar destinada a uma
extensão específica, ela é tratada automaticamente pela extensão “s”.
Dentro de cada contexto se encontram as extensões. Uma extensão é uma regra ou

instrução que deve ser seguida pelo Asterisk. Ações como atender ou desligar o
canal, tocar um arquivo de áudio ou executar o tratamento de variáveis são
instruções típicas das extensões.
A declaração de uma extensão possui o seguinte formato:
exten => EXTENSÃO, PRIORIDADE, APLICAÇÃO(OPÇÕES)
Os termos em letras maiúsculas serão abordados adiante. Os outros são fixos e

fazem parte da sintaxe da declaração.
O Asterisk possui uma série de extensões especiais pré-definidas. São elas:
\\a – chamada quando o usuário pressiona * (asterisco) durante a mensagem

do voicemail;
\\h – extensão chamada após o desligamento;
\\i – extensão inválida;
\\o – extensão do Operador, usada para saída do voicemail ao pressionar 0 (zero);
\\s – start ou extensão de início em cada contexto;
\\t – extensão de timeout;
178
\\T – extensão chamada após o AbsoluteTimeout();

\\failed – usado se uma chamada auto-dial falhar;
\\fax – usado para detecção de fax em canais zap;
\\talk – usado conjuntamente com BackgroundDetect.
Fonte: www.voip-info.org/wiki/view/Asterisk+standard+extensions
Prioridades
\\As extensões podem ter vários passos;
\\Chamamos estes passos de prioridades;
\\Exemplo de extensão que atende a uma chamada e em seguida a desliga:

\\exten => 1001,1,Answer()
\\exten => 1001,2,Hangup()
\\A prioridade “n” significa “próxima” (next).
Cada extensão normalmente possui mais de um comando (ou aplicação). Por isso
foi definido o número de prioridade, que designa a ordem em que as aplicações
devem ser executadas.
No exemplo seguinte (sem uma função prática), primeiro a chamada é atendida e

logo depois desconectada:

Para facilitar a configuração, o Asterisk pode utilizar a prioridade n (next) para

indicar o próximo número sequencial de prioridade. Neste caso, o exemplo ficaria:
exten => 1001,1,answer()

exten => 1001,n,hangup()
Aplicações
\\As aplicações executam ações específicas nos canais;
\\Exemplos de aplicações:
\\Answer();
\\Playback()
\\Hangup()
As aplicações são como os comandos das extensões. Elas indicam as ações a serem
executadas durante o fluxo da chamada no plano de discagem, como emitir sons,
aceitar entradas ou desligar chamadas.
179
Answer()
A aplicação Answer() é utilizada para responder a um canal que está tocando. Ela
faz a configuração inicial para que o canal receba uma ligação. É uma das
aplicações mais importantes, pois boa parte das outras aplicações necessita que o
canal tenha sido configurado por Answer() para operar corretamente, por exemplo
para executar um arquivo de som no canal. Esta aplicação não recebe argumentos.
Playback()
Utilizada para reproduzir um arquivo de som sobre o canal. Recebe o nome do
arquivo de som como argumento. Para facilitar o uso desta aplicação, existe um
diretório padrão, var/lib/asterisk/sounds/, onde todos os sons do Asterisk se
encontram. Assim não precisamos especificar o caminho completo ao utilizar a
aplicação. Este caminho pode ser modificado no arquivo asterisk.conf.
Hangup()
Simplesmente desliga um canal ativo e desaloca os recursos computacionais que
estavam sendo utilizados na chamada. Não recebe argumentos.
extensions.conf
\\Os dois primeiros cabeçalhos que encontramos no arquivo extensions.conf —
[general] e [globals] — são especiais e chamados de seções;
\\Seções que encontramos no arquivo:

\\[general]
\\[globals]
Os dois primeiros contextos do arquivo extensions.conf são seções especiais.
[general]
São declaradas opções gerais sobre o plano de discagem.
Por enquanto, duas opções importantes são static e writeprotect, que especificam se
o arquivo extensions.conf pode ser modificado pelo plano de discagem
dinamicamente no Asterisk. É uma boa escolha trocar o parâmetro para
writeprotect=yes, que evita que o plano de discagem seja modificado pelo comando
save dialplan, na linha de comando do Asterisk.
[globals]
Na seção [globals] podemos definir e iniciar as variáveis globais com seus
respectivos valores. Da mesma forma que em programas de computadores,
normalmente as variáveis globais são utilizadas para simplificar mudanças na
configuração do sistema. Na prática, estas variáveis são utilizadas como constantes.
180
Variáveis

\\Valores de variáveis são obtidos com a seguinte sintaxe:
\\${nomedavariavel}
\\Variáveis podem ser:

\\Globais;
\\De ambiente;
\\Associadas a um canal.
\\Variáveis globais:
\\São configuradas na classe [globals] ou utilizando o comando SetGlobalVar;
\\Uma vez definidas, podem ser referenciadas a qualquer momento.
\\Variáveis de ambiente:
\\Servem para acessar as variáveis de ambiente do sistema operacional;
\\Podemos fazer referência às variáveis de ambiente da seguinte forma:
\\${ENV(nomedavariavel)}
\\Variáveis de canal:
\\Configuradas com o comando Set(), antigo SetVar;
\\Têm um escopo local restrito ao canal em que foram criadas. São destruídas
quando o canal é encerrado, para liberar memória;
\\Algumas variáveis de canal são predefinidas e podem ser referenciadas no
plano de discagem.
As variáveis são declaradas e têm seus valores atribuídos como abaixo:
RINGTIME=>3
Define quanto tempo (em segundos) vai tocar antes de executar a próxima
aplicação.
VMANNOUCE=>mysounds/my-vm-annouce
Define qual arquivo de áudio usar quando anunciar o voicemail.
RAMAL01=>Zap/2
Define o canal associado à extensão. As variáveis globais não são “case sensitive”. A
utilização de caixa-alta é mera convenção.
Para resgatar o valor de uma variável no plano de discagem, é preciso acessá-la da

seguinte forma:
${VARIÁVEL}
181
Exemplo:
exten => 1,1, answer()

exten => 1,n, Dial(${RAMAL01})
exten => 1,n, hangup()
Também é possível declarar uma variável global durante o fluxo de uma chamada,
utilizando a aplicação SetGlobalVar() no plano de discagem. Por exemplo:
[contexto1]
exten => 123,1, Answer()
exten => 123,n, SetGlobalVar(saidaPadrao=Zap/2)
exten => 123,n,GoTo(contexto2,456,1)
[contexto2]
exten => 456,1, Dial(${saidaPadrao})
exten => 456,n, hangup()
${ENV(ASTERISK_PROMPT)}: Prompt atual da linha de comando do CLI do

Asterisk
${ENV(RECORDED_FILE)}: Último arquivo gravado com o comando Record
O Asterisk pode usar uma série de variáveis como argumentos das aplicações ou
comandos. Podem ser do tipo Global, Compartilhada, De canal ou De ambiente.
Variáveis também podem ser manipuladas (cortadas, somadas, concatenadas).
Variáveis de ambiente oferecem um meio de resgatar via Asterisk as variáveis de

ambiente Unix.
Mais informações sobre as variáveis do Asterisk em:

www.voip-info.org/wiki/view/Asterisk+variables
Cada canal no Asterisk possui seu próprio espaço para variáveis. Elas podem ser
definidas dinamicamente através do plano de discagem, pelo comando Set() —
antigo SetVar. Variáveis de canal são destruídas e seu espaço na memória é
desalocado quando a chamada termina, quando o comando Hangup() é executado.
Algumas variáveis de canal predefinidas no Asterisk podem ser utilizadas pelo plano
de discagem, como veremos a seguir.
182
Variáveis predefinidas

\\Exemplos de variáveis de canal predefinidas:
\\${ACCOUNTCODE}: código de contabilização;
\\${ANSWERDTIME}: horário em que a chamada foi atendida;
\\${CALLERID}: identificador da chamada;
\\${CHANNEL}: nome do canal atual;
\\${CONTEXT}: nome do contexto atual;
\\${DIALEDPEERNAME}: nome de quem foi chamado;
\\${DIALEDPEERNUMBER}: número de quem foi chamado;
\\${DIALEDTIME}: hora em que o número foi discado;
\\${EXTEN}: extensão atual (nome da extensão atual);
\\${PRIORITY}: prioridade atual.
A variável ${EXTEN} é talvez a variável de canal mais utilizada nos planos de

discagem. Ela contém o número da extensão corrente e pode simplificar e facilitar
significativamente a configuração do Asterisk.
Existem diversas variáveis no Asterisk. O aluno pode visitar a documentação on-line

para conhecer a lista completa.
Expressões
\\As expressões utilizam variáveis, valores e operadores para retornar resultados
que são utilizados no plano de discagem;
\\Uma expressão segue a seguinte sintaxe:

\\$[expressão]
\\Um exemplo de expressão poderia ser:

\\$[${nomedavariavel}+200]
Os argumentos dos comandos podem ser calculados dinamicamente na hora em

que serão utilizados.
O Asterisk suporta que sejam realizados cálculos durante a execução do plano de discagem.
Portanto, é possível utilizar uma expressão matemática ou manipulação de strings

como argumentos de comandos.
183
Por exemplo, a linha
exten => 2112345678,n, dial(ZAP/g1/${EXTEN:2})
Irá chamar o número 12345678 no canal ZAP/g1, cortando os dois primeiros

algarismos: “21”.
No exemplo abaixo temos uma variável referenciada com seu valor somado ao valor 200.
$[${nomedavariavel}+200]
Operadores
\\Existem basicamente três tipos de operadores que podem ser utilizados nas
expressões:
\\Matemáticos:
\\+
\\-
\\/
\\%
\\Lógicos:
\\&
\\|
\\Operador para expressões regulares:

\\“:” (dois pontos)
Funções dos operadores apresentados:
\\+ – soma um número a outro
\\- – subtrai um número de outro
\\/ – retorna o resultado da divisão de dois números
\\% – retorna o resto da divisão de dois números
\\& – “E” lógico
\\| – “OU” lógico
\\: – utilizado para produzir substrings. ${STRING:início:comprimento}
Mais informações em: www.voip-info.org/wiki/view/Asterisk+Expressions
184
Padrões de extensão

\\Os seguintes caracteres são exemplos de padrões:
\\X – dígitos de 0 até 9;
\\Z – dígitos de 1 até 9;
\\N – dígitos de 2 até 9;
\\[1237-9] – qualquer dígito entre as chaves e o intervalo 7-9, neste caso 1,
2, 3, 7, 8, 9;
\\“.” – ponto é um padrão curinga que combina com um ou mais dígitos.
Para auxiliar a produzir planos de discagem mais complexos e menos extensos, o

Asterisk oferece uma forma de coincidir os caracteres digitados no teclado do
telefone. São as expressões regulares, que diferem bastante da expressão regular
conhecida da programação.
Para indicar que um número de extensão é uma expressão regular, deve começar
com o caractere “_” (underline).
Exemplos:
\\Número de 6 dígitos, onde os dois primeiros são diferentes de 0:
exten => _ZZXXXX,1,Answer()

exten => _ZZXXXX,n,Dial(SIP/meuTroncoSip/${EXTEN})
exten => _ZZXXXX,n,Hangup()
\\Número de 8 dígitos + 2 de código de área;
\\Código de área não inicia com 0 nem com 1, e o segundo dígito é diferente de
zero;
\\Número do telefone começa com os algarismos 2, 3, 4 ou 5. Depois tem mais 7

dígitos livres;
\\Apenas o número de 8 dígitos é discado pelo tronco “meuTroncoSip”:
exten => _NZ[2-5]XXXXXX,1,Answer()

exten => _NZ[2-5]XXXXXX,n,Dial(SIP/meuTroncoSip/${EXTEN:2})
exten => _NZ[2-5]XXXXXX,n,Hangup()
\\Qualquer número de qualquer tamanho que comece com zero;
\\É passado para o tronco SIP apenas o número, sem o zero inicial:
exten => _0.,1,Answer()

exten => _0.,n,Dial(SIP/meuTroncoSip/${EXTEN:1})
exten => _0.,n,Hangup()
185
Aplicação Background()
\\Uma das peças chave para interação no Asterisk;
\\Diferentemente da aplicação Playback(), a aplicação Background() reproduz

um arquivo de áudio:
\\Porém, quando o usuário digita alguma coisa em seu softphone, a ligação é
redirecionada para o ramal especificado.
A aplicação Background() é essencial para a construção de URAs. Ela reproduz um

arquivo de áudio para o chamador, mas fica aguardando que ele digite alguma tecla.
Assim podemos tocar um arquivo que diz “Por favor, digite 1 para compras ou 2
para vendas” e teremos um menu de voz interativo.
A aplicação Background() possui a mesma sintaxe da aplicação Playback(). Então,

seu argumento é o nome do arquivo de áudio a ser reproduzido, também com
referência ao diretório padrão dos arquivos de áudio do Asterisk.
Aplicação Goto()
\\Útilpara direcionar a ligação para diferentes extensões, prioridades e até
mesmo contextos;
\\Possibilita programação do fluxo de uma ligação pelo plano de discagem;
\\Sintaxe: exten=> extensão, prioridade, Goto (contexto, extensão, prioridade);
\\Há também a aplicação Gotoif().
A aplicação GoTo() é muito útil para produzir desvios no fluxo da chamada, ou seja,
no caminho que a chamada percorre pelos comandos do plano de discagem. Um
desvio incondicional é implementado de acordo com a sintaxe GoTo (contexto,
extensão, prioridade), mas extensão e contexto são opcionais.
Há também a forma condicional desta aplicação, Gotoif(). Neste caso, a sintaxe

muda consideravelmente.
Gotoif(EXPRESSÃO?LABEL_SE_VERDADE:LABEL_SE_FALSO)
Onde:
EXPRESSÃO é um teste de condição. Uma string vazia ou o valor 0 (zero) são

considerados falsos.
LABEL_SE_VERDADE e LABEL_SE_FALSO podem assumir a mesma forma que na

aplicação Goto().
186
Mais informações:

\\www.voip-info.org/wiki/view/Asterisk+cmd+Goto
\\www.voip-info.org/wiki/view/Asterisk+cmd+GotoIf
Aplicação Dial()
\\Utilizada literalmente para discar para algum destino:
\\A aplicação Dial() é útil, pois permite que usuários que estejam usando
métodos de comunicação distintos possam se comunicar.
\\Recebe quatro argumentos:

\\Destino;
\\Timeout;
\\Opções;
\\URL (pouco usual).
\\Exemplo:
\\exten => 123,1,Dial(Zap/1/33072022,10,r);

\\Disca para o número 3307 2022 no canal Zap/1;
\\Espera 10 segundos;
\\Dá o tom de chamada para quem está discando pela opção “r”;
\\Não especificamos nenhum URL.
\\Outro exemplo:
\\exten => 123,1,Dial(SIP/1001,20,t);
\\Disca para o ramal SIP 1001;
\\Espera 20 segundos;
\\Permite transferência de chamadas com a opção “t”.
\\Mais um exemplo:
\\exten => 123,1,Dial(SIP/1001,,rt);
\\Disca para o ramal SIP 1001;
\\Não foi especificado o tempo de espera;
\\Dá o tom de chamada para quem está discando pela opção “r”;
\\Não foi especificado nenhum URL.
A aplicação Dial() é, talvez, a mais importante de todas. Ela é responsável por

estabelecer uma conexão com o canal desejado e ligá-lo ao canal solicitante. Recebe
como argumento pelo menos o nome do canal de destino, mas existem opções que
podem ser passadas no momento da “discagem”.
187
De forma simplificada, pode ser utilizada de acordo com a sintaxe Dial (tipo/
identificador, timeout, opções, URL), onde:
\\Type – tipo do canal (SIP, H.323, Zap, Agent etc);
\\Identifier– identificador do canal, especificado no arquivo de configuração

apropriado;
\\Timeout – tempo durante o qual o canal deve ser chamado até desistir;
\\URL– envia este URL para o dispositivo destino quando ele suporta, mas
raramente é utilizado;
\\Options – opções que adicionam funcionalidades ao comando Dial.
A lista de opções é grande. Confira no link abaixo:
\\http://www.voip-info.org/wiki/view/Asterisk+cmd+dial
Deve-se notar que os argumentos da aplicação Dial() não são obrigatórios, podendo
ser passadas várias opções como argumento.
188
6
\\A atividade tem por objetivo compreender e analisar os arquivos de configurações
do Asterisk.

\\Ao final desta prática o aluno irá aprender a configurar um plano de discagem
no Asterisk.

Requisitos
\\Esta prática envolve atividades individuais
Introdução ao arquivo de configuração extensions.conf.
A sintaxe para uma extensão é a palavra exten, seguida por uma seta formada por
um sinal de igual (=) e um sinal de maior (>).
exten => <nome_da_extensão>
Uma extensão completa é composta por três componentes:
1. Nome ou número da extensão;
2. Prioridade;
3. Aplicação ou comando a ser executado na chamada.
189
Os três componentes são separados por vírgulas.
Exemplo:
exten => nome, prioridade, aplicação( )
\\Nome – é o número que será digitado para executar a aplicação;
\\Prioridade – cada prioridade é numerada sequencialmente, iniciando a partir do

número 1, onde cada prioridade executa uma aplicação específica.
Exemplo:
exten => 123,1,Answer( )

exten => 123,2,Hangup( )
A versão 1.2 do Asterisk introduziu o uso da prioridade “n” (next). O parâmetro “n”
adiciona 1 ao valor anterior.
Exemplo:
exten => 123,1,Answer( )

exten => 123,n,Hangup( )
A extensão especial start (representada pela letra “s”) é utilizada quando uma
ligação entra em um contexto sem estar destinada a uma extensão específica.
Nesta atividade o aluno aprenderá e entenderá o uso e a sintaxe dos parâmetros de

configuração do arquivo, para o funcionamento adequado do Asterisk.
Dicas
\\No arquivo sip.conf, altere o parâmetro context=default para

context=cursovoip.
\\No fim do arquivo extensions.conf insira a seção [cursovoip]; os parâmetros

das atividades deverão ser incluídos dentro desta seção.
Inicie a máquina virtual localizada no diretório Asterisk, e efetue login com usuário
root e a senha rnpesr.
Atividade 1 – Primeiro plano de discagem
Começaremos a editar nosso plano de discagem utilizando uma das maiores

tradições existentes na computação. Criaremos um “Hello Word!” com o que foi
visto até agora.
Os arquivos de áudio estão localizados no diretório /usr/share/asterisk/sound.
190
Anote as linhas inseridas:

Atividade 2 – Configuração do plano de discagem com Background e Goto
Vamos criar agora um plano de discagem mais complexo utilizando as aplicações

Background e Goto, onde deveremos chamar o ramal 9 no cliente X-Lite e escutar
uma gravação; ao digitar 1 e 2, o Asterisk confirmará o número digitado, e ao
digitarmos 3 a ligação deverá ser encerrada.
Para a elaboração de um plano mais complexo, precisamos ser capazes de tratar

exceções com eficiência. Exemplos básicos são as extensões especiais “i” e “t”.
Desafio: na atividade 2, ao clicar em qualquer número que seja diferente de 1, 2 ou

3, uma mensagem de erro deverá ser emitida e a ligação não poderá ser encerrada.
Atividade 3 – Tratamento de erros
De acordo com o plano de discagem abaixo, faça as atividades propostas.
[cursovoip]
exten => 9,2,Background(vm-enter-num-to-call)
exten => 1001,1,Dial(SIP/1001,10,r)
exten => 1002,1,Dial(SIP/1002,10,r)
191
1. Acrescente um tratamento de erro para um canal ocupado.
2. Podemos acrescentar variáveis para simplificar o plano de discagem. Adicione as

variáveis “RAMAL01=SIP/1001” e “RAMAL02=SIP/1002” em [globals].
[globals]
[cursovoip]
3. Disque 9 e depois os números dos ramais definidos no plano de discagem.
Atividade 4 – Aperfeiçoamento do plano de discagem
O último plano de discagem realizado na atividade 3 tem um grande defeito: para

cada novo ramal, precisamos modificar o plano de discagem. Qual seria a sua
proposta de solução?
192
7
Serviços complementares
►► Sumário
Transferência de chamadas . . . . . . . . . . . . . . . . . . . 194
Estacionamento de chamadas . . . . . . . . . . . . . . . . . . 194
Captura de chamadas. . . . . . . . . . . . . . . . . . . . . 196
Música em espera. . . . . . . . . . . . . . . . . . . . . . 196
Correio de voz (voicemail). . . . . . . . . . . . . . . . . . . 197

Atividade 1 – Transferência de chamadas (Blind transfer). . . . . . . . 199
Atividade 2 – Estacionamento de chamadas . . . . . . . . . . . . . 200
Atividade 3 – Captura de chamadas . . . . . . . . . . . . . . . 201
Atividade 4 – Música em espera. . . . . . . . . . . . . . . . . 202
Atividade 5 – Correio de voz . . . . . . . . . . . . . . . . . . 202
193
Transferência de chamadas
\\A transferência de chamadas é habilitada de forma bastante simples no Asterisk;
\\ A transferência de chamadas pode ser feita de duas formas:

\\Transferência cega (blind transfer);
\\Transferência assistida.
Permite que chamadas sejam encaminhadas para outros ramais. Quando um usuário
recebe uma ligação e decide transferi-la para outra pessoa, pode fazê-lo de duas formas:
\\Transferência cega (blind transfer) – o usuário pode simplesmente passar a

ligação para a segunda pessoa, sem antes falar com ela. Neste caso, o primeiro
usuário disca o segundo ramal e, quando ouve o sinal de chamando, pode
desligar o telefone;
\\Transferência assistida – o primeiro usuário pode conversar com o segundo

enquanto a ligação aguarda em hold e, apenas quando o primeiro desliga o
telefone é que a chamada é repassada para o segundo;
Estacionamento de chamadas
\\Funcionalidade muito útil e conhecida dos usuários de PABX convencionais;
\\Serve para estacionar uma chamada enquanto o usuário se locomove de um

terminal para outro;
\\Parâmetros de configuração:
\\parkext;
\\parkpos;
\\context;
\\parkingtime.
De forma simplificada, o estacionamento de chamadas (call parking) pode ser

entendido como uma transferência para uma “sala virtual”, de forma que seja
possível desligar o ramal sem que a chamada seja desligada. Depois, em outro
ramal, é possível resgatar a chamada original telefonando para o número da “sala
virtual”. A chamada é estacionada em determinada extensão e o usuário pode
recuperá-la digitando o número da extensão onde ela está. Por padrão, no Asterisk a
extensão 700 é responsável pelo estacionamento de chamadas.
Durante uma chamada, o usuário disca #700 e o Asterisk anuncia a extensão de

estacionamento (normalmente o intervalo 701-720).
Discar a extensão anunciada faz com que a chamada prossiga.
194
Parâmetros de configuração
Capítulo 7 – Serviços complementares

Os parâmetros do estacionamento de chamadas são controlados pelo arquivo de
configuração features.conf e estão contidos na seção [general].
parkext
Extensão utilizada para colocar a chamada em estacionamento. Ao transferir a
chamada para esta extensão, o sistema informa a posição de estacionamento em
que a chamada foi colocada. Por padrão é a extensão 700.
parkpos
Esta opção define o número de posições de estacionamento. Por padrão, temos o
intervalo 701-720 (20 extensões).
context
Nome do contexto de estacionamento. Para estacionar chamadas, precisamos incluir
este contexto no plano de discagem (include =>parkedcalls).
parkingtime
Permite que uma chamada em andamento não precise ser desligada quando um dos
usuários tiver que se deslocar para outro ramal. Quando configurada, esta opção
controla o tempo (em segundos) que uma chamada pode ficar estacionada. Se não for
recuperada no tempo fornecido, a extensão que estacionou a chamada voltará a tocar.
Além do arquivo features.conf, também precisamos fazer alterações no extensions.

conf para habilitar o uso do estacionamento de chamadas. Para habilitar o
estacionamento de chamadas, devemos fazer a inclusão do contexto para
estacionamento de chamadas.
include=>parkedcalls
Figura 7.1
195
A chamada fica estacionada até que o lado que a colocou em espera se conecte
novamente.
Exemplo: em chamada entre os ramais 101 e 102, o usuário que está falando no
ramal 101 deseja ir até a sala em que se encontra o ramal 103 e continuar a
ligação de lá. Ao digitar #700, ele recebe do Asterisk um número associado à
chamada estacionada. Ao discar para esse número a chamada é capturada.
Captura de chamadas
\\A captura de chamadas (call pickup) permite que o usuário atenda a chamadas
direcionadas a outros usuários que estejam em um mesmo grupo;
\\ É outro velho conhecido dos usuários de PABX convencionais;
\\Evita que tenhamos que levantar para atender ao telefone de outro colega.
Permite que um usuário capture a chamada de outro ramal que ainda não tenha
sido atendida.
No Asterisk, o código padrão para captura de ligações é *8. Este código pode ser
modificado no arquivo features.conf pelo parâmetro pickupexten. Além disso, para
habilitar a captura, devemos configurar grupos de chamadas nos arquivos que
correspondem a cada tecnologia utilizada:
\\sip.conf;
\\iax.conf;
\\zapata.conf / chan_dahdi.conf.
O usuário do ramal 101 está ligando para o usuário do ramal 103. O usuário do
ramal 102, ao escutar o ramal 103 tocando na sala ao lado, sem que ninguém
atenda, disca *8 em seu próprio telefone e captura a chamada, sem precisar se
levantar e ir até a sala ao lado onde o ramal está tocando.
Música em espera
\\A música em espera é utilizada em diversas situações, como estacionamento
de chamadas, filas e transferências;
\\A música em espera é controlada pelo arquivo musiconhold.conf;
\\Podemos definir várias classes para organizar as músicas;
\\Podemos utilizar a variável mohsuggest para definir classes-padrão de música

em espera para os diversos canais.
Permite que um usuário em espera escute uma música de fundo. É possível utilizar
quase qualquer tipo de mídia como música de espera do Asterisk, de arquivos wav
até streams mms://.
196
A escolha mais segura é a utilização de arquivos locais wav ou mp3. Para tocar

arquivos mp3 é necessário instalar o pacote addons do Asterisk. Os arquivos mp3 não
devem ter bitrate variável. Também é preciso remover as identificações ID3. É possível
fazer essas modificações nos arquivos mp3 usando ferramentas de edição de áudio.
O arquivo musionhold.conf controla as opções da música em espera. É possível configurar

várias “classes” de música em espera. Isto é muito útil, por exemplo, para implementações
de callcenters que atendem a diversos tipos de clientes. Ligações para Loja1 escutam
anúncios corporativos da Loja1. Ligações para Loja2, escutam os da Loja2.
Nos arquivos de configuração dos diversos canais (sip.conf, queues.conf, chan_

dahdi.conf, etc) é possível especificar a classe da música em espera que deve ser
utilizada. Também é possível definir estas classes em termos globais ou
individualmente para cada ramal.
A funcionalidade music on hold permite que um usuário em espera escute uma

música de fundo para que não ache que a chamada foi terminada.
Exemplo: existe uma chamada entre os ramais 101 e 102, e o usuário do ramal
103 faz uma chamada para o ramal 102. Ao receber a notificação de uma nova
chamada, o usuário do ramal 102 avisa ao ramal 101 que vai deixá-lo em espera,
sendo disponibilizada uma música de fundo para o usuário do ramal 101.
Correio de voz (voicemail)

\\Mais do que uma simples secretária eletrônica, ele pode aprimorar a
experiência do usuário com uma interface simples e funcional;
\\Utilizamos a aplicação VoiceMail() para direcionar ligações para o correio de voz;
\\Utilizamos a aplicação VoiceMailMain() para acessar nossa caixa de correio.
A funcionalidade de correio de voz do Asterisk permite que as mensagens deixadas

na caixa postal de voz sejam gravadas em arquivos (mp3 ou wav). Posteriormente, é
possível acessá-las utilizando qualquer telefone, dentro ou forma da empresa,
bastando que o Asterisk seja corretamente programado.
Além disso, também é possível enviar e-mails avisando sobre a chegada de recados na
caixa postal de voz. O texto do e-mail é configurável e pode informar a data e a hora
em que a ligação foi recebida e o número de origem, entre outras opções. Além disso,
ainda é possível anexar a esta mensagem o próprio recado, gravado em mp3 ou wav.
O correio de voz também permite a configuração de contextos, muito útil para

implementações de um único servidor para vários clientes.
197
198
7
\\A atividade tem por objetivo explorar as funcionalidades do Asterisk.

\\Ao final desta prática o aluno será capaz de realizar configurações de serviços
complementares no Asterisk.

Requisitos
\\Esta prática envolve atividades em dupla ou mais alunos.
Atividade 1 – Transferência de chamadas (Blind transfer)
Nesta atividade iremos criar uma configuração para que seja possível efetuar
transferência de chamadas.
Passo 1: abra o arquivo sip.conf e verifique se todos os clientes estão com a opção
canreinvite=no habilitada.
Passo 2: edite o arquivo extensions.conf e coloque as opções “t” e “T” na aplicação

Dial(). Ex: Dial(SIP/${EXTEN},20,rtT)
Passo 3: abra o arquivo features.conf e localize a seção [featuremap],

certificando-se de que as variáveis blindxfer e atxfer estejam comentadas.
199
Passo 4: reinicie o serviço Asterisk:
Passo 5: abra o cliente X-Lite, e efetue uma chamada para um ramal; após atender,
transfira a chamada para outro ramal utilizando a tecla #.
Anotações:
Atividade 2 – Estacionamento de chamadas
Nesta atividade executaremos uma configuração para que seja possível efetuar o
estacionamento das chamadas.
Passo 1: edite o arquivo features.conf e localize a linha que possui a variável

parkext=>, alterando seu valor para 500.
Passo 2: localize a linha que possui a variável parkpos=>, e altere seu valor para
501-503.
Passo 3: salve e feche o arquivo.
Passo 4: edite o arquivo extensions.conf e inclua o contexto responsável pelo

estacionamento de chamadas: include=>parkedcalls.
Passo 6: teste o estacionamento das chamadas, discando para um ramal e estacione

a chamada discando #500; para recuperar a chamada disque 501, 502 ou 503.
200
Anotações:

Atividade 3 – Captura de chamadas
Nesta atividade iremos efetuar uma configuração para capturar as chamadas

destinadas a outro usuário. Esta atividade requer três ou mais alunos cadastrados
em um servidor SIP.
Passo 1: edite o arquivo sip.conf e defina o valor 1 para callgroup e pickupgroup:

callgroup=1 e pickupgroup=1 em todos os ramais definidos.
Passo 3: neste passo podemos testar a captura de chamadas; um usuário deverá

ligar para um ramal e um terceiro irá capturar a chamada teclando “*8”. Esta
sequência é default do Asterisk e está definida no arquivo features.conf, no
parâmetro pickupexten.
Anotações:
201
Atividade 4 – Música em espera
Nesta atividade efetuaremos uma configuração para que seja possível ouvir a música
de espera.
Passo 1: edite o arquivo de configuração musiconhold.conf, localize a seção

[default], adicione o suporte ordenado aleatório random=yes.
Passo 2: edite o arquivo de configuração extensions.conf e adicione uma extensão

de teste para a música em espera.
Como ficaria o arquivo extensions.conf?
Atividade 5 – Correio de voz
Nesta atividade efetuaremos uma configuração para que seja possível ouvir a música
de espera.
Passo 1: edite o arquivo voicemail.conf, localize a seção [default] e acrescente alguns

contextos para os ramais definidos no arquivo sip.conf, seguindo o padrão abaixo:
Extensão=> senha, nome do usuário, e-mail, pager, opções.
1001=>1111,Aluno1 Voip,root@localhost
1002=>1111,Aluno2 Voip,root@localhost
202
Passo 2: edite o arquivo extensions.conf para tratar o voicemail. Coloque a

aplicação Voicemail() no lugar da aplicação Playback(), que trata as situações busy
e nobodyavail.
Abaixo temos um modelo de plano de discagem:
exten=>9,1,Answer()
exten=>9,2,Background(vm-enter-num-to-call)
exten=>_10XX,1,Playback(transfer)
exten=>_10XX,3, VoiceMail(u${EXTEN}@default)
exten=>_10XX,103, VoiceMail(b${EXTEN}@default)
exten=>_10XX,104, Hangup()
exten=>i,1,Playback(pbx-invalid)
exten=>i,2,Goto(cursovoip,9,1)
exten=>t,1,Playback(vm-goodbye)
exten=>t,2,Hangup()
Passo 3: acrescente uma extensão para que o usuário possa acessar sua caixa de
correio.
exten=>500,1,VoiceMailMain()
Passo 4: reinicie o serviço Asterisk: /etc/init.d/asterisk restart
Passo 5: faça testes com o X-Lite, o Telefone IP e o ATA e verifique o funcionamento

das aplicações relacionadas ao voicemail.
203
204
8
Distribuição de chamadas
►► Sumário
Discagem por diretório . . . . . . . . . . . . . . . . . . . . 206
Distribuição automática de chamadas . . . . . . . . . . . . . . . 207

Atividade 1 – Discagem por diretório . . . . . . . . . . . . . . . 209
Atividade 2 – Distribuição automática de chamadas . . . . . . . . . . 210
205
Discagem por diretório
\\O correio de voz fornece suporte para outra funcionalidade: a discagem por
diretório;
\\O serviço de diretório de nomes do Asterisk utiliza os nomes definidos nas

extensões do arquivo voicemail.conf para associar nomes a extensões;
\\O serviço de discagem por diretório é fornecido pela aplicação Directory().
\\Default se refere à seção do voicemail.conf, onde definimos as caixas de correio.
\\cursovoip é a seção do plano de discagem.
\\Sintaxe:
\\Directory(vm-context[|dial-context[|options]])
\\Anuncia ao usuário uma lista de ramais que podem ser selecionados pelo
nome:
\\Esta característica é conhecida com “discagem por nome” (dial by name)
nos sistemas tradicionais.
\\A lista de nomes e ramais é declarada no arquivo voicemail.conf;
\\O primeiro argumento vm-context define o contexto no qual os ramais devem

ser interpretados;
\\O segundo argumento é usado para definir o plano de discagem.
Fluxo:
\\Toca o arquivo de introdução (dir-intro) e espera 5 segundos para os 3 dígitos;
\\O arquivo de introdução toca a mensagem Please enter the first three letters of
the persons last name...;
\\Nome é a última palavra encontrada no campo <name> em voicemail.conf;
\\Toca a mensagem em (dir-instr) com as instruções para conexão ao ramal

desejado;
\\Também toca o “nome” como gravado na mailbox do usuário. Se a gravação não

existir, ele tocará as letras do nome (bee-oh-bee-space-ess-em-aye-tee-aich) Bob Math;
\\Se mais de um nome for encontrado, é possível escolher entre os nomes encontrados;
\\Se nenhum nome for encontrado, a mensagem de introdução é repetida;
\\Pressione “*” para sair;
\\Pressione “1” para ir ao ramal desejado.
206
Capítulo 8 – Distribuição de chamadas
Distribuição automática de chamadas
\\A distribuição automática de chamadas é possibilitada pelo uso de filas, e
funciona da seguinte forma:
\\As chamadas entram e são colocadas em fila;
\\Clientes autenticados como agentes atendem as chamadas;
\\Uma estratégia é usada para distribuir as chamadas.
\\Agentes são atendentes com ramais definidos no arquivo agents.conf, onde são
definidas as filas de atendentes;
\\Um agente pode pertencer a mais de uma fila:

\\agents.conf
[agents]
agent => 1001,4321,Wayne Kerr
\\queues.conf
[queue1]
member => Agent/1001
\\extensions.conf
exten => 28,1,AgentLogin(1001)
exten => 29,1,Queue(queue1)
Esta função permite que as chamadas sejam atendidas assim que chegam e
inteligentemente direcionadas aos agentes disponíveis, como em um call center. A
distribuição automática de chamadas também auxilia a gerenciar redirecionamentos
de transbordo, redirecionamento de chamadas baseado em estatísticas de fila,
recuperação de chamadas abandonadas e encaminhamento de chamadas entre
múltiplas localidades. O encaminhamento baseado nas habilidades dos agentes
(skills-based routing) define o agente mais apropriado para atender cada chamada;
o encaminhamento baseado em regras aplica um único conjunto de regras de
negócio para todos os canais de contato; e a funcionalidade Specific Agent Recall
direciona clientes que estejam retornando chamadas para o mesmo agente que fez
o contato original.
207
208
8

\\Ao final desta atividade prática o aluno será capaz de realizar configurações
avançadas no Asterisk.

\\Uma a duas horas, entre atividades individuais e em grupo.
Atividade 1 – Discagem por diretório
Passo 1: edite o arquivo extensions.conf e acrescente as seguintes extensões:
exten=>7,1,Directory(default,cursovoip,f)
exten=>7,2,Directory(default,cursovoip,f)
Passo 2: reinicie o serviço Asterisk executando o comando:
Passo 3: teste o resultado ligando para a extensão.
Anotações:
209
Atividade 2 – Distribuição automática de chamadas
Passo 1: edite o arquivo agents.conf e adicione uma nova seção [fila], que definirá
a nossa fila.
[general]
persistentagents=yes
[agents]
autologoff=15
musiconhold => default
group=1
agent => 300,300, atendente 1
agent => 301,301, atendente 2
Passo 2: edite o arquivo queues.conf e adicione uma nova seção [fila]. Esta seção
definirá a nossa fila.
[fila]
music = default ;classe da "music on hold"
strategy= ringall ;estratégia para distribuir as chamadas
maxlen = 0 ;Comprimento máximo da fila (0 = infinito)
member => Agent/300 ;Inclusão de um agente
member => Agent/301 ;Inclusão de outro agente
Passo 3: edite o arquivo extensions.conf para configurar o acesso à fila no plano de

discagem.
exten => 0800,1,Answer ;atende chamadas para a fila

exten => 0800,2,Queue(fila) ;aciona a fila
exten => 6000,1,AgentCallbackLogin(||${CALLERIDNUM}@cursovoip)
exten => 6001,1,AgentLogin(||${CALLERIDNUM}@cursovoip)
Passo 4: disque do X-Lite para uma das extensões de login (6001 ou 6000) e siga
as instruções.
\\ Disque 300# para informar o login
\\ Disque 300# para confirmar a senha
\\ Disque o número da extensão que está usando (1001)
210
Passo 5: utilizando outro softphone, disque para a fila 0800.
Capítulo 8 – Distribuição de chamadas

Anotações:
211
212
9
Unidade de Resposta Audível
(URA)
►► Sumário
Hora do sistema. . . . . . . . . . . . . . . . . . . . . . . 214
Unidade de Resposta Audível (URA). . . . . . . . . . . . . . . . 215

Atividade 1 – Gerando mensagens personalizadas . . . . . . . . . . . 219
Atividade 2 – Criando plano de discagem para uma empresa de serviço VoIP . 220
213
Hora do sistema
\\Serviço adicional – data e hora:

\\Implementado pela função SayUnixTime();
\\SayUnixTime([unixtime][|[timezone][|format]]):
\\Unixtime – tempo em segundos desde 1° de janeiro de 1970;

\\Timezone – abreviação do timezone para data/hora; se vazio, utilizará os
parâmetros do sistema;
\\Format – formato em que data e hora serão reproduzidas.
\\Todos os parâmetros são opcionais.
\\SayUnixTime([unixtime][|[timezone][|format]]) – a hora e a data informados

deverão ser o primeiro argumento em segundos desde 1° de janeiro de 1970.
\\Todos os parâmetros são opcionais; se nada for informado, os parâmetros padrão

serão utilizados.
\\O propósito desta aplicação de plano de discagem é informar data e hora em

segundos, após 1° de janeiro de 1970.
\\Unixtime – hora em segundos após 1° de janeiro de 1970. Pode ser negativa

(segundos antes de 1° de 1970). O valor padrão é o timestamp atual.
\\Timezone – abreviação do timezone para data/hora. Maiores informações sobre

timezones podem ser encontradas em /usr/share/zoneinfo. O valor padrão é a
hora em que o computador está configurado.
\\Format – formato em que data e hora são reproduzidos. Os formatos abreviados são:
\\A ou a – dia da semana;
\\B ou b ou h – nome do mês;
\\d ou e – dia do mês numérico;
\\Y – ano;
\\I ou i – hora, relógio em 12 horas;
\\H – hora, relógio em 24 horas;
\\k – hora, relógio em 24 horas;
\\M – minuto;
\\P ou p – AM ou PM;
\\Q – today, yesterday ou ABdY;
\\q – for today, yesterday, weekday ou ABdY;
\\R – relógio em 24 horas, incluindo minutos; o valor padrão é ABdYIMp.
214
Capítulo 9 – Unidade de Resposta Audível (URA)
\\Serviço adicional – Data e Hora:
; Hora
exten => 102,1,Ringing
exten => 102,2,Wait(1)
exten => 102,3,SayUnixTime(,America/Sao_Paulo,IMp)
exten => 102,4,Hangup
; Data
exten => 103,1,Ringing
exten => 103,2,SayUnixTime(,America/Sao_Paulo, ABdY)
exten => 103,3,Hangup
\\Hora – IMP: hora, minuto, AM/PM.
\\Data – ABdY: dia da semana, nome do mês, dia do mês numérico, ano.
Unidade de Resposta Audível (URA)

\\Serviço adicional – Interactive Voice Response (IVR):
\\ou Unidade de Resposta Audível (URA);
\\Recurso que permite detectar voz e tons utilizando uma chamada normal de
telefonia;
\\Muito útil para permitir que o sistema de telefonia utilize a rede VoIP;
\\Também utilizado para criar uma lista de menus para endereçar ramais sem
DDR ou fornecer algum tipo de serviço de call center, como:
\\“Bem-vindo ao suporte de vendas, em breve você será atendido... Sua
ligação é importante para nós... Disque 1 para esperar mais um pouco,
2 para falar com o Luiz etc...”.
Interactive Voice Response (IVR) automatiza algumas ou todas as interações dos

seus clientes, utilizando recursos de conversão de texto em voz (text-to-speech) e de
reconhecimento de voz (voice recognition) integrados para obter informações do
cliente e fazer a comparação com os sistemas de informação para,
automaticamente, atender às questões e solicitações dos clientes. As
funcionalidades de URA e DAC podem ser utilizadas em conjunto para obter
informações do cliente e encaminhar a chamada para o agente mais habilitado. Nas
campanhas ativas via Unidade de Resposta Audível, a URA disca para os clientes e
toca uma mensagem assim que eles atendem ao telefone; responde
automaticamente algumas perguntas pré-definidas, e encaminha o cliente para um
agente humano, se necessário.
215
\\Serviço adicional – IVR:

\\Criar a extensão [IVR]:
[IVR]
exten => 9999,n,Wait(2)
exten => 9999,n,Background(teste-ivr)
exten => 1,1,Goto(opcao-1,s,1)

exten => 2,1,Goto(opcao-2,s,1)

\\Crie duas extensões para completar o menu da IVR:
\\[opcao-1]
\\[opcao-2]
[opcao-1]
exten => s,1,Dial(SIP/6331@openser)
exten => s,2,Hangup()
[opcao-2]
exten => s,1,Dial(SIP/7531@openser)
exten => s,2,Hangup()
\\ Opção 1 – será encaminhado para o canal SIP um invite para 6331@openser

(o OpenSER neste exemplo é a conta SIP definida em sip.conf).
\\ Opção 2 – será encaminhado para o canal SIP um invite para 7531@openser.

\\Gravando um prompt de áudio:
\\Com o Asterisk é possível gravar as mensagens de áudio que serão
utilizadas no menu do IVR;
\\A aplicação Record() pode ser utilizada para essa finalidade:
exten => 100,1,Wait(2)
exten =>
00,n,Record(/var/lib/asterisk/sounds/
minhaGravacao:gsm)
exten => 100,n,NoOp(${RECORDED_FILE})
exten => 100,n,Playback(/var/lib/asterisk/sounds/
minhaGravacao)
exten => 100,n,NoOp(${PLAYBACKSTATUS})
exten => 100,n,Hangup()
216
Gravando mensagens de áudio

Para utilizar um IVR, normalmente é necessário gravar algumas mensagens de áudio
utilizando o Asterisk.
Para esse propósito, você poderá adicionar uma extensão no extension.conf para
gravar a mensagem. Neste exemplo, você pode discar 100 e depois do beep
começar a gravação e terminar com #.
As mensagens são gravadas no formato GSM e chamadas de minhagravacao.gsm,

no diretório /var/lib/asterisk/sounds/.
Depois de pressionar #, após dois segundos, o Asterisk tocará a mensagem gravada.
Neste exemplo são utilizadas as aplicações Wait(), Record(), Playback() e Hangup().
Você poderá ver as descrições dessas aplicações digitando no console do Asterisk

1.4 core show application <aplicações> ou, no formato antigo, show application
<aplicações>; este formato será removido em implementações futuras.

\\Gravando um prompt de áudio:
\\Após gravar a mensagem, copie-a para o lugar definitivo, como por
exemplo:
# cd /var/lib/asterisk/sounds
# cp minhaGravacao.gsm teste-ivr.gsm
\\Esta etapa está pronta;
\\Agora falta encaminhar as mensagens de/para o Asterisk.
É possível também na IVR chamar os ramais que estão no OpenSER; para isso
poderia ser implementada uma extensão conforme abaixo:
exten: _XXXX,1,Dial(SIP/${EXTEN}@openser)
exten: _XXXX,2,Hangup()
217
218
9

\\Ao final desta prática o aluno será capaz de realizar configurações avançadas
no Asterisk.

\\2h30 minutos a 3 horas (trabalho individual e em grupo).
Atividade 1 – Gerando mensagens personalizadas
Nesta atividade iremos gerar mensagens para serem utilizadas como atendimento.
Sintaxe da Record(filename:format,silence[,maxiduration][,options]) (no

aplicação Asterix 1.0.X)
Record() Record(filename:format,silence[,maxiduration][,options]) (no
Asterix 1.2.X)
Opções
Filename Nome do arquivo que será gerado na gravação. Se o arquivo

existir ele será substituído
Format Especifica o tipo de formato que o arquivo será gravado. Os formatos

válidos incluem: g723, g729, gsm, h263, ulaw, alaw, vox, wav.
Silence Especifica o tempo máximo de gravação em segundos de silêncio.
Maxduration Especifica o tempo máximo de gravação em segundos. este campo

Tabela 9.1 vazio ou com 0 (zero), implica a ausência de tempo máximo.
219
1. Descreva um plano de discagem que permita a gravação das mensagens, onde os
arquivos gerados estejam no formato gsm e armazenados no diretório /tmp.
2. Crie uma mensagem de saudação com nome “atende”, com a mensagem a

seguir: Você ligou para a central VoIP; disque 1 para suporte, 2 para financeiro e
3 para vendas.
3. Crie uma mensagem para suporte, uma para o departamento financeiro e outra
para vendas, onde em cada contexto vamos tocar uma gravação como Você foi
redirecionado para o departamento xxxx.
Atividade 2 – Criando plano de discagem para uma empresa de serviço VoIP
Forme grupos de quatro pessoas, onde três representarão setores da empresa e a

quarta representará o cliente que efetuará a chamada. Crie uma regra de discagem
conforme abaixo:
1. Ao chamar o ramal 9000, a mensagem que atende deverá ser tocada em

Background;
2. Ao discar a opção desejada, a ligação será transferida para o ramal

correspondente. Faça o tratamento das opções inválidas.
220
Anote o plano de discagem do grupo:
221
222
10
Qualidade de Serviço em VoIP
►► Sumário
Situação atual . . . . . . . . . . . . . . . . . . . . . . . 224
Provisão de QoS . . . . . . . . . . . . . . . . . . . . . . 225
Estabelecimento de contratos de serviços . . . . . . . . . . . . . . 226
Service Level Agreement (SLA). . . . . . . . . . . . . . . . . . 227
Provisão centralizada. . . . . . . . . . . . . . . . . . . . . 228
Provisão distribuída. . . . . . . . . . . . . . . . . . . . . . 229
Manutenção . . . . . . . . . . . . . . . . . . . . . . . . 230
Término do contrato. . . . . . . . . . . . . . . . . . . . . 231
Modelos de QoS . . . . . . . . . . . . . . . . . . . . . . 231
Protocolo de sinalização – RSVP . . . . . . . . . . . . . . . . . 233
Rotina de controle de admissão . . . . . . . . . . . . . . . . . 234
Classificador . . . . . . . . . . . . . . . . . . . . . . . . 235
Escalonador de pacotes . . . . . . . . . . . . . . . . . . . . 235
Escalonador FIFO (First In First Out) . . . . . . . . . . . . . . . 235
Escalonador WFQ (Weighted Fair Queuing) . . . . . . . . . . . . . 236
Escalonador PQ (Priority Queying) . . . . . . . . . . . . . . . . 237
IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . 237
DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . 238
DiffServ no pacote IP . . . . . . . . . . . . . . . . . . . . . 239
DiffServ – DSCP. . . . . . . . . . . . . . . . . . . . . . . 240
Considerações sobre DiffServ . . . . . . . . . . . . . . . . . . 240
Encaminhamento . . . . . . . . . . . . . . . . . . . . . . 241
Serviços Integrados sobre Diferenciados . . . . . . . . . . . . . . 241
Multi-Protocol Label Switching – MPLS . . . . . . . . . . . . . . 242
Modelo básico de rede MPLS . . . . . . . . . . . . . . . . . . 243
Real-time Transport Protocol – RTP . . . . . . . . . . . . . . . . 244
Real-time Transport Control Protocol – RTCP . . . . . . . . . . . . 247

Atividade 1 – Qualidade de Serviço (QoS). . . . . . . . . . . . . . 253
223
Situação atual
\\A internet disponibiliza um serviço de melhor esforço;
\\O congestionamento da rede causa atrasos e perdas;
\\Não há garantia de tempo de entrega;
\\Não há garantia nas perdas;
\\Novos cenários de tráfego e aplicações necessitam de requisitos de perdas,

retardo e taxa de transmissão;
\\Novas tecnologias, novas demandas:

\\Voz sobre IP (VoIP);
\\Educação à distância;
\\Teleconferência;
\\Simulação interativa distribuída;

\\Telemedicina;
\\Vídeo sob demanda.
A internet faz “o melhor possível” para entregar os pacotes, mas sem garantia
alguma. Pacotes podem ser perdidos, atrasados ou entregues fora de ordem.
Durante o congestionamento (comutadores e roteadores recebendo mais quadros/

pacotes do que a capacidade de encaminhar/rotear), quadros e pacotes sofrem
atrasos, aguardando na fila a oportunidade de serem colocados na interface de saída
ou de serem excluídos.
As aplicações atuais, de voz e vídeo principalmente, exigem garantias de QoS para

que satisfaçam as necessidades dos usuários.
Os parâmetros que definem a qualidade de serviço são intrinsecamente ligados às

aplicações suportadas, diferindo se a comunicação é em tempo real ou não.
\\Aplicações de voz demandam pouca banda, mas não toleram alto atraso ou jitter.
\\Aplicações de imagem podem exigir grande banda e não toleram alto atraso ou
jitter, embora tolerem alguma perda.
\\Voz e dados nas redes de circuitos exigiam taxas de erro distintas e, em última
instância, parâmetros de qualidade diferentes.
\\Nas redes de pacotes, os fatores a considerar são a criticidade do serviço em

relação ao transporte em tempo real ou não, delay e perda de pacotes suportada.
Uma vez definidos os valores dos parâmetros, como monitorá-los? Via web em
tempo real? Através de relatórios recebidos da operadora em períodos a serem
acordados? São perguntas importantes que deverão ser respondidas ao longo
desta sessão de aprendizagem.
224
Provisão de QoS
Capítulo 10 – Qualidade de Serviço em VoIP

\\A rede de comunicação deve prover funções para QoS:
\\As funções atuam em diferentes fases do ciclo de vida de um serviço:

\\Solicitação de serviços;
\\Estabelecimento de contratos de serviços;
\\Manutenção dos contratos;
\\Término do contrato.
\\Mecanismos estáticos:
\\Ex.: solicitação ao administrador de rede.
\\Mecanismos dinâmicos:
\\Ex.: uso de protocolos de sinalização.
\\Mecanismos estáticos e dinâmicos demandam:

\\Alocação de recursos;
\\Caracterização de tráfego;
\\Especificação da QoS a ser aplicada.
1. Para prover QoS, a rede deve possuir ferramentas de controle e monitoração do

QoS ou, simplesmente, estar superdimensionada, sem a ocorrência de
congestionamentos;
2. Ao solicitar um serviço, o usuário deve descrever os parâmetros exigidos pela

sua aplicação;
3. Ao atender a solicitação do usuário, o fornecedor do serviço oferece uma

determinada qualidade de serviço, podendo ou não ser a qualidade esperada
pelo usuário, que poderá ter que diminuir um pouco a qualidade do resultado
final de sua aplicação, seja por motivos econômicos (custo do serviço maior que o
esperado) ou técnicos (a operadora não tem como oferecer a QoS solicitada);
4. Na assinatura de contratos de serviços, devem ser considerados os parâmetros

de QoS, que responderão pela qualidade do serviço. Neste ponto é importante
que o usuário verifique se a qualidade esperada é a que está sendo oferecida, e
da parte do provedor checar se os parâmetros de serviço estão aderentes à
expectativa do usuário;
5. Na manutenção dos contratos, será avaliada no dia a dia a qualidade do serviço,

que poderá ser a esperada, inferior ou até superior. É importante definir as
características da aplicação, procedimentos de emergência, e principalmente
como o cliente pode monitorar os parâmetros da aplicação;
6. É importante que haja cláusulas de multa que forcem a operadora a manter a

QoS dentro dos padrões contratados;
225
7. Ao término do contrato, após a liberação dos recursos, é importante fazer uma
avaliação geral do comportamento da qualidade, isto é, se o que foi oferecido era

o esperado pelo usuário e os cuidados de qualidade necessários para novas
solicitações de serviço. Ao responder, o provedor de rede poderá atender a novas
solicitações de serviço com qualidade mais robusta.
Nos mecanismos estáticos, normalmente a configuração é realizada manualmente

por um administrador de rede, sendo esta mantida até o fim do serviço ou até que
seja realizado um pedido de mudança da configuração.
Nos mecanismos dinâmicos, protocolos de sinalização respondem automaticamente

a mudanças na rede, através de informações recebidas de sistemas de
monitoramento, procurando sempre manter o serviço dentro de limites contratados
entre o usuário e a operadora.
A provisão de QoS necessita da caracterização do tráfego — detalhamento do perfil

do tráfego: taxa média, taxa de pico, tamanho máximo da rajada —, para que a QoS
possa ser especificada para a aplicação e a operadora aloque um mínimo de recursos
em sua rede (filas em roteadores, banda, LSPs) para provimento da QoS exigida. Para
provisão de QoS, é necessário conhecer as características do serviço a ser prestado.
Há uma série de fatores que contribuem para a qualidade na prestação de um

serviço, entre eles:
\\Disponibilidade do serviço;
\\Medição de atrasos;
\\Desempenho dos serviços.
Os parâmetros podem ser configurados de duas maneiras:
\\Estaticamente – configuração por comandos de um operador;
\\Dinamicamente – quando a rede nota alguma mudança de estado e ajusta seus

parâmetros conforme as necessidades da aplicação e as possibilidades da rede.
Estabelecimento de contratos de serviços

\\Comprometimento entre a aplicação e a rede:
\\Aplicação gera tráfego como especificado no contrato;
\\A rede assegura o transporte dos fluxos com a QoS solicitada.
\\Esse acordo recebe o nome de Service Level Agreement (SLA).
Os contratos de serviços devem estar em conformidade com exigências contratuais

ou normas regulatórias do setor (Anatel, ITU, IEEE). O SLA é o contrato de garantias
de serviço estabelecendo não apenas garantias ao tráfego do cliente, mas também
definindo limites. Assim, um tráfego gerado pelo cliente acima do perfil descrito na
caracterização, não obrigatoriamente deverá receber as garantias contratadas.
226
Esse tráfego fora da caracterização poderá ter pacotes perdidos ou atrasados, sem

que a operadora tenha que indenizar o cliente.
Ao elaborar uma SLA, algumas perguntas deverão ser respondidas:
1. Quais as características do serviço?
2. Quem e quantos são os usuários do serviço?
3. Qual o impacto deste serviço para os usuários?
4. Qual o custo associado à interrupção do serviço?
5. Quanto o cliente quer pagar pelo serviço?
6. Qual o processo para a execução deste serviço?
7. Quais os pontos críticos deste processo?
8. Como monitorar este processo?
9. Como detectar a falha e medir a sua ocorrência?
10. Como estabelecer penalidades para a falha?
11. Como cobrar multas geradas pela penalidade?
12. Quem fará o acompanhamento do processo?
13. Como as futuras divergências serão dirimidas (em casos sob judice)?
14. Qual será o fórum para decisão?
Tais perguntas deverão ser respondidas pelo contratante e pelo contratado ou

provedor do serviço.
Service Level Agreement (SLA)

\\Estabelecimento de contratos de serviços;
\\Para garantir o SLA, é preciso orquestrar recursos de forma a:

\\Quantificar os recursos disponíveis;
\\Prover um controle de admissão;
\\Classificar e escalonar pacotes.
\\O SLA pode ser configurado de forma:

\\Estática:
\\Recursos reservados pelo administrador de rede.
227
\\Dinâmica:
\\Efetuada por um protocolo de sinalização;

\\Podendo ser:
\\Centralizada;
\\Descentralizada ou distribuída.
Para garantir o SLA, é necessário conhecer os recursos totais da rede e os recursos

já reservados para que o controle de admissão conheça o limite para a garantia de
recursos aos usuários. Acima deste limite os pacotes trafegarão sem garantia ou
serão descartados.
A classificação é a função normalmente exercida na borda da rede, onde o

equipamento descobre a qual classe (definida em conjunto com o cliente) pertence
cada pacote, fazendo sua marcação e colocando-o na fila adequada. No caso do
cliente extrapolar os valores combinados com o provedor, os pacotes podem ser
classificados com uma prioridade mais baixa ou simplesmente descartados. Durante
o escalonamento, o nó da rede (comutador ou roteador) colocará os quadros ou
pacotes nas filas adequadas e selecionará os próximos a serem encaminhados/
roteados conforme a QoS estabelecida para cada classe.
Na forma estática, o SLA é definido por um período de tempo e recursos pré-determinados,

sendo essa configuração mantida até que o administrador faça outra intervenção.
Na forma dinâmica, ao contrário do modelo anterior, a reserva de recursos é

realizada por protocolos específicos, que podem alterar parâmetros durante o
período em que a aplicação está sendo realizada.
Na configuração centralizada, um único equipamento recebe informações de toda a

rede, toma as decisões necessárias e as envia aos equipamentos da rede. Como
exemplo, podemos citar a engenharia de tráfego em uma rede MPLS, onde as
definições dos LPS podem ser realizadas por um servidor centralizado. Já a configuração
descentralizada ocorre quando todos os nós da rede participam da definição.
Provisão centralizada
\\Bandwidth Broker (BB) ou negociador de recursos é o responsável pela
reversão e configuração dos recursos.
\\O BB disponibiliza:
\\Interface de solicitação e configuração de serviços;
\\Comunicação das decisões.
228
\\Exemplos de BB:
\\Common Open Policy Server (COPS) – RFC 2748;
\\Diameter (RFC 3588).
Os negociadores de recursos (Bandwidth Broker – BB) são agentes que possuem

conhecimento dos recursos disponíveis, recursos reservados e das necessidades das
aplicações, além do nível de utilização da rede e do fluxo de pacotes marcados como
prioritários, entre outros, para assim interpretar com maior inteligência e coerência
as novas requisições de banda. Os negociadores de recursos facilitam, orientam e
disciplinam as alterações de recursos desejados, facilitando a administração da rede,
a QoS e o SLA. Cada domínio deverá possuir o seu BB.
Common Open Policy Server (COPS), especificado na RFC 2748, é um modelo cliente/
servidor para efetivar o controle e o policiamento da QoS para determinada aplicação.
Para a parte de autenticação e billing, é utilizado o RADIUS (Remote Authentication

Dial In User Service). Diameter (RFC 3588) é um protocolo para autenticação e
billing, em uma versão mais robusta que o RADIUS, com o acesso seguro sendo
feito via IPsec ou TLS, na porta 3868 TCP.
Provisão distribuída
\\Estações e roteadores na rede são dotados de um negociador próprio;
\\Negociadores trocam informações de controle via protocolo de sinalização e

determinam a reserva de recursos;
\\Exemplo:
\\Resource ReSerVation Protocol – RSVP (RFC 2205).
A alocação do recurso é feita para todo o período em que a aplicação será utilizada,
não podendo o recurso ser compartilhado com outras aplicações. Ao término da
aplicação, os recursos deverão ser liberados para que outras aplicações possam
utilizá-los. O RSVP é o protocolo utilizado no modelo de QoS, conhecido como
IntServ ou Integrated Services (Serviços Integrados).
Antes do estabelecimento da comunicação entre dois pontos, cada roteador por onde
o fluxo de dados irá passar deve alocar os recursos necessários para garantir a
qualidade da comunicação. Se qualquer roteador negar a solicitação, o fluxo em
questão não poderá trafegar pela rede.
229
Manutenção
\\A manutenção garante que as aplicações não ultrapassem a cota de utilização

dos recursos;
\\Necessidade de policiamento:
\\A rede deve reagir prontamente a degradações ocasionais.
\\Falhas de componentes de rede:

\\Dimensionamento conversativo dos recursos.
\\Acionar funções de sintonização;
\\Manter o SLA contratado:

\\Realocar recursos;
\\Escolher subredes e roteadores alternativos.
\\Renegociação do SLA:
\\Tentativa de manter o novo SLA contratado.
O policiamento tem a função de verificar se o tráfego gerado pelo cliente encontra-se

dentro do combinado com a operadora. Estando o tráfego fora dos padrões
combinados, o policiamento pode reagir, marcando o pacote para um possível
descarte, mudando a sua classe ou prioridade ou simplesmente descartando-o. O
policiamento deve levar em conta as características para tráfego de tempo real,
como voz e tráfego sensível a perdas, que é o caso de tráfego de dados. Os
parâmetros a serem atendidos são providos pela QoS nos roteadores de acesso.
O dimensionamento conversativo dos recursos deve fornecer uma política de decisão

para policiamento (por exemplo “perdas são admissíveis”), cuja gestão poderá estar
no Bandwidth Broker.
Para manter o SLA contratado, são importantes algumas premissas:
1. Estabelecer os limites para a aplicação;
2. Estabelecer garantias específicas de desempenho para a aplicação contratada;
3. Avaliar os relatórios periódicos de acompanhamento de QoS;
4. Criar uma política de compensação adequada em caso de não conformidade em

alguns dos itens contratados;
5. Utilizar sempre métricas quantificáveis.
230
Renegociação do SLA

Se for o caso de negociar ajustes nos indicadores do SLA, um período de avaliação
e conformidade, aberto a alterações, é necessário para a renegociação do
documento. No caso das metas e parâmetros não serem atingidos, antes da
renegociação é importante verificar possíveis obstáculos, como:
\\Metas inatingíveis nos prazos negociados;
\\Metas definidas pela tecnologia e não pelo negócio;
\\SLA entendido pela organização como um overhead, e não como um diferencial

competitivo;
\\Equipe de SLM sem a devida senioridade/autoridade para negociar com as

partes envolvidas (clientes e fornecedores);
\\Contratos de SLA inadequados;
\\As diversas áreas envolvidas não perceberem que o acordo é um “construtor”, e

não um “destruidor” de relacionamentos;
\\Falta de recursos (pessoas, processos e tecnologia);
\\Divulgação inadequada de metas e reportes.
Término do contrato
\\A aplicação informa à rede a intenção de finalizar o contrato;
\\A rede libera os recursos alocados;
\\Especificado o período do contrato, a liberação dos recursos poderá ocorrer de

forma automática.
É necessário ter cautela e ferramentas de avaliação sobre a disponibilidade dos

recursos. A gerência da rede deve estar familiarizada com esses recursos para evitar
surpresas de recursos alocados indevidamente. Liberar recursos de forma
automática pode ser um problema quando a área técnica não está integrada ou
bem alinhada com a área de pós-vendas das empresas.
Modelos de QoS
\\Existem diferentes tipos de modelos propostos pelo Internet Engineering Task
Force (IETF);
\\Esses modelos se adaptam de acordo com o tipo de aplicação e de arquitetura

da rede:
\\Integrated Services (IntServ);
\\Differentiated Services (DiffServ).
231
\\IntServ:
\\Utilizado para designar um modelo de serviços que acrescenta ao serviço de

melhor esforço oferecido na internet;
\\Categorias de serviços com diferentes graus de comprometimento de
recursos (banda e memória) e níveis (ou classes) de QoS;
\\Um fluxo é identificado na arquitetura IntServ pela tupla IP Origem e Porta
TCP ou UDP de origem.
\\IntServ oferece, além do best effort, as seguintes categorias de serviços:

\\Serviços garantidos:
\\Para aplicações que necessitam de um atraso constante.
\\Serviços de carga controlada:
\\Para aplicações que necessitam de segurança e limite de variação de
atraso (jitter).
\\Aplicações que exigem esses tipos de serviço devem configurar caminhos e

reservar recursos antes da transmissão dos dados;
\\A implementação do IntServ é feita por quatro componentes:

\\Protocolo de sinalização (RSVP);
\\Rotina de controle de admissão;
\\Classificador;
\\Escalonador de pacotes.
Integrated Services (IntServ) é um protocolo caracterizado pela reserva prévia de

recursos para atender determinada aplicação. O conceito simula um circuito, uma
vez que a comunicação só é realizada se houver recursos disponíveis nos roteadores
antes do início da conversação, seja ela de dados ou de voz. Um fator que pode ser
considerado negativo neste caso é que os recursos dos roteadores ficam
comprometidos durante todo o tempo em que a aplicação estiver ativa,
independente de naquele exato momento a aplicação estar utilizando os recursos de
rede. Além disso, é de difícil escalabilidade, pois é um protocolo complexo e
consome muitos recursos computacionais, especialmente memória para manter os
estados de todas as conexões.
O Differentiated Services (DiffServ) foi desenvolvido pelo IETF para resolver os

problemas do protocolo anterior em relação ao comprometimento dos recursos, seja
para o controle das conexões ou para o tráfego de dados propriamente dito. Os
pacotes são marcados de acordo com características do serviço e, em cada roteador,
são encaminhados de acordo com sua prioridade. Não há necessidade de
estabelecimento de circuito.
O modelo IntServ está descrito na RFC 1633. A sinalização deste modelo de QoS é
provida pelo protocolo de reserva de recursos, o RSVP (Resource Reservation
Protocol), descrito na RFC 2205.
232
De forma simplificada, um fluxo é identificado na arquitetura IntServ pelo IP e a

porta TCP ou UDP de origem. É possível fazer a reserva de recursos e garantir o
atraso constante ou, através de carga controlada, manter o atraso dentro de
determinados limites de variação. A primeira categoria é muito mais onerosa em
termos dos recursos utilizados.
Os dois serviços estão descritos em RFCs:
\\RFC 2211 – Controlled-Load Network Element Service;
\\RFC 2212 – Guaranteed Quality of Service.
A definição do caminho a ser percorrido pelo fluxo, assim como a reserva de

recursos, antecederá o início do fluxo propriamente dito, o que gera um atraso maior
do primeiro pacote. O controle de admissão é essencial para que o sistema não se
comprometa com uma carga superior ao que pode realmente transportar. A
arquitetura IntServ causa dois problemas principais:
\\Processa cada fluxo individualmente nos roteadores do centro da internet,

gerando problemas de escala;
\\Falta de políticas de controle.
Uma rede que implemente o modelo IntServ precisa garantir que seus roteadores
sejam capazes de executar as seguintes tarefas:
\\Controle de admissão – determina que um fluxo pode ser encaminhado com o

grau de qualidade requerido, sem interferir em fluxos já em curso;
\\Classificação – reconhece pacotes que necessitam de níveis específicos de QoS;
\\Policiamento – age quando o tráfego não está em conformidade com o

especificado, inclusive descartando pacotes;
\\Enfileiramento e escalonamento – encaminha os pacotes de acordo com os

requisitos de QoS.
Protocolo de sinalização – RSVP

\\RSVP (Resource reSerVation Protocol) é um protocolo de sinalização que
gerencia recursos ao longo do caminho no qual se quer utilizar aplicações que
necessitem de QoS;
\\O processo de sinalização ocorre antes da transmissão dos dados e é renovado

sempre que necessário.
O protocolo RSVP, descrito na RFC 2205, é o protocolo de sinalização utilizado

pelo modelo IntServ para reserva de recursos nos roteadores envolvidos na
comunicação. É o responsável pela sinalização no domínio IntServ, estabelecendo e
desfazendo caminhos confiáveis na rede. Se apenas um dos roteadores envolvidos
233
no trânsito dos dados não tiver disponível o recurso solicitado, a transmissão dos
dados não ocorre. Para alocar recursos, as mensagens PATH e RESV são trocadas
entre o receptor e o transmissor.
Nuvem RSVP
PATH(1) PATH(2) PATH(3)
Figura 10.1
RESV(6) RESV(5) RESV(4)
Origem solicita reserva de recursos tais como banda, delay e jitter, para determinada
aplicação através da mensagem PATH, que pode ser unicast ou multicast. Cada roteador
consultado que atender à solicitação passa ao estado de “reserva dos recursos”, e
encaminha a mensagem até o destino, que retorna a mensagem RES pelos mesmos
roteadores, confirmando a reserva do caminho. Desta maneira é estabelecido um
caminho prévio, semelhante ao conceito dos recursos solicitados ao longo circuito.
No RSVP, um fluxo de dados é uma sequência de mensagens com a mesma origem

(endereço IP e porta), o mesmo destino e a mesma qualidade de serviço.
Principais problemas deste protocolo:
\\Estabelecida a conexão e no caso de queda de um roteador no caminho (path),

todo o procedimento tem que ser refeito;
\\Comprometimento de recursos durante todo o tempo da conexão, exigindo alto

desempenho da rede;
\\Quando o caminho é desfeito, é preciso se certificar de que todos os recursos

sejam liberados, evitando comprometimentos desnecessários;
\\Problema de escala, pois conforme aumenta a quantidade de fluxos das

aplicações, aumenta o consumo dos recursos, causando problemas aos
backbones das grandes redes.
Rotina de controle de admissão

\\O controle de admissão tem apenas a função de determinar se um fluxo de
dados poderá ser aceito ou não, de acordo com a banda disponível;
\\Este componente é requisitado de forma que sua decisão não interfira nos
fluxos previamente aceitos pelo roteador.
A rotina de controle de admissão deve conhecer os recursos totais da rede, os

recursos alocados, e consequentemente os recursos livres. Deve verificar se é
possível aceitar o tráfego solicitado pela aplicação do cliente, podendo aceitar, negar
ou negociar parâmetros menos rígidos. Algumas tecnologias permitem que um novo
fluxo retire os recursos de fluxos já estabelecidos, mas de menor prioridade.
234
Classificador

\\Marca os pacotes para possibilitar a reserva de banda para determinado fluxo;
\\O fluxo é atendido de acordo com sua prioridade na fila dentro do roteador;
\\As prioridades da fila são tratadas pelo escalonador, que implementa algoritmos
que selecionam os pacotes.
O classificador identifica a classe a qual os pacotes pertencem, conforme o endereço

IP, endereço MAC, porta etc., para que os pacotes recebam o tratamento contratado
para a classe. O classificador mapeia os pacotes desses fluxos nas diferentes classes
de serviço, usando a classificação gerada como parâmetro do algoritmo no
tratamento dos pacotes.
Escalonador de pacotes
\\Estabelece políticas de enfileiramento e prevenção de congestionamento;
\\O escalonador trabalha com algoritmos que fazem implementações de acordo

com a necessidade de QoS para determinados serviços, tais como:
\\First In First Out (FIFO);
\\Weighted Fair Queuing (WFQ);
\\Priority Queuing (PQ).
O escalonador de pacotes gerencia os buffers das filas de saída dos roteadores e

estações, usando alguma política de atendimento com a finalidade básica de
selecionar os primeiros pacotes a serem colocados na interface de saída, lembrando
que aguardar na fila representa aumento do atraso e da possibilidade de descarte.
Escalonador FIFO (First In First Out)

\\Pacotes de diferentes fluxos são transmitidos na ordem em que são recebidos
FIow 1 5
FIow 2 2
FIow 3 4
FIFO Queue
FIow 4 6 Multiplexer
6 5 4 3 2 1 Port
FIow 5
FIow 6
FIow 7 3
FIow 8 1
Figura 10.2
235
É a política mais simples, normalmente utilizada para aplicações que não
necessitam de QoS.
FIFO (o primeiro a chegar é o primeiro a sair) é uma implementação de escalonador

que apenas faz o armazenamento e o repasse dos pacotes, sem nenhum tipo de
classificação ou prioridades. A ordem de chegada dos pacotes é respeitada,
determinando a alocação da banda. Algumas aplicações podem sofrer muito com o
tráfego em rajada, causando grandes atrasos para aplicações sensíveis ao tempo.
Escalonador WFQ (Weighted Fair Queuing)

\\Pacotes são classificados e designados a uma fila
Transmit Outgoing
Incoming packets queue packets
Classify
Weighted fair scheduling
Configurable
number of queues
Queueing buffer resources
Flow-based classification: Weight determined by:

Source and destination adress Required QoS (IP Precedence, RSVP)
Protocol Flow throughput inversely proportional
Session identifier Frame Relay FECN, BECN, DE
(port/socket) (for Frame Relay traffic) Figura 10.3
Weighted Fair Queuing (enfileiramento justo e ponderado) é uma implementação de

escalonador que utiliza um algoritmo que estabelece pesos diferenciados para
determinados tipos de pacotes (classes). Cada classe corresponderá a uma fila onde
pode ser estabelecido, por exemplo, que para cada pacote transmitido da fila A,
serão transmitidos dois pacotes da fila B e três pacotes da fila C. Na verdade, a
abordagem de pesos normalmente é implementada sem a utilização de pacotes
como unidade de medida; a quantidade de dados medida em bytes de cada fila é a
unidade de medida. Então, envia-se a quantidade de pacotes que coincida com a
quantidade de bytes a serem enviados. Caso a fila não tenha pacotes para
transmitir, o algoritmo buscará imediatamente os pacotes na próxima fila, sem
perder o tempo de transmissão dos pacotes a que tinha direito a primeira fila. É
uma forma de garantir bandas mínimas para os fluxos.
236
Escalonador PQ (Priority Queying)

\\O roteador mantém várias filas com diferentes prioridades
High
Mediun Transmit Outgoing

Incoming packets queue packets
Classify
Normal
Low
Length defined
by queue limit
Queueing buffer resources
Classification by: Interface hardware:

Protocol (IP, IPX, AppleTalk, Ethernet
SNA, DECnet, bridge, and so on) Frame Relay
Source interface ATM
Figura 10.4 (EO, SO, and so on) Serial link (and others)
Priority Queuing (enfileiramento prioritário) é um algoritmo desenhado para aplicações

de tempo real. A fila com maior prioridade é checada e se houver algum pacote ele
é enviado. Quando a fila SP (Strict Priority, Prioridade Estrita), a fila de maior
prioridade, 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 LLQ (Low Latency Queue) ou fila de baixa latência.
A desvantagem deste método é a possibilidade das outras filas sofrerem um fenômeno

chamado de starvation (morrer de fome), pois elas podem nunca ser atendidas pela
possibilidade de sempre haver pacotes em uma fila de maior prioridade.
IntServ
\\Escalabilidade:
\\Informações de estado podem sobrecarregar os elementos centrais da rede;

\\Inadequado para redes de backbone.
\\Complexidade:
\\Todos os roteadores devem implementar RSVP, controle de admissão,

classificação e escalonador de pacotes.
O IntServ é pouco escalável, uma vez que trata de cada fluxo individualmente. Em
uma grande rede, armazenar informações e tratar individualmente de cada fluxo
pode comprometer o espaço de armazenamento e o processamento dos nós
intermediários, assim como o esforço de gerenciamento. Os roteadores devem
237
obrigatoriamente implementar funções mais sofisticadas, trazendo maior necessidade de
processamento, memória, upgrade de softwares e, consequentemente, maiores custos.
DiffServ
\\Differentiated Service:
\\Introduzido pelo Internet Engineering Task Force (IETF) para resolver os
problemas encontrados com a implantação do IntServ;
\\Neste modelo, os pacotes são previamente marcados de acordo com os
tipos de serviços desejados;
\\O DiffServ possibilita a criação de classes de serviços dentro de um domínio:
\\Ex.: ISP, Teleco.
\\Quando o cliente contrata um “serviço diferenciado”, o campo TOS (Type Of
Service) é marcado com a classe correspondente.
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 de prover
tratamentos adequados 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:
\\Classificador – seleciona um pacote do fluxo baseado no conteúdo de alguma

porção do cabeçalho;
\\Medidor – checa se os parâmetros do tráfego estão de acordo e passa os

resultados para o marcador e modelador;
\\Marcador – escreve ou reescreve o campo DSCP;
\\Modelador – atrasa ou descarta alguns pacotes para que o tráfego fique em

conformidade com o projeto.
238
DiffServ no pacote IP

\\Formato do datagrama IP
0 4 8 16 19 31
Version HLen Type of service Total lenght
Identification Flags Fragment offset
Time to live Protocol Header checksun
Source IP address
Destination IP address
Options Padding
Data
Figura 10.5
Inicialmente, a classificação de pacotes utilizava o campo TOS (Type Of Service).

Este procedimento é popularmente conhecido como “marcação de pacotes”. Quando
um pacote IP é marcado, significa que o campo foi preenchido com determinado
valor. Este campo indica o tipo de serviço que está sendo transportado pela rede IP.
A RFC 3260 redefine o campo TOS, modificando o significado de alguns bits. Agora,
este octeto é conhecido como DS (Differentiated Services). São utilizados 6 bits para
a marcação dos pacotes, e os outros dois estão reservados e não são utilizados. Na
prática, os pacotes são marcados com valores que definem a classe de serviço a que
pertencem, fornecendo uma indicação aos roteadores da prioridade com que esses
fluxos devem ser tratados.
No IPv6, o campo DSCP foi mapeado como o octeto “Classe de tráfego”.
239
DiffServ – DSCP
\\Valores DSCP
PBH DSCP Precedência IP
Default 000000 0
Low Drop Medium Drop High Drop

Probability Probability Probability
Classe 1 001010 – AF11 001100 – AF12 001110 – AF13 1

Assured
Forwarding Classe 2 010010 – AF21 010100 – AF22 010110 – AF23 2
Classe 3 011010 – AF31 011100 – AF32 011110 – AF33 3
Classe 4 100010 – AF41 100100 – AF42 100110 – AF43 4
Expedited 101110 – EF 5
Forwarding
Tabela 10.1
Pacotes com prioridade EF (Expedit Forwarding) são imediatamente enviados para a
rede. A classe EF está descrita na RFC 2598.
Pacotes com prioridade AF (Assured Forwarding) possuem 4 classes distintas, são

enfileirados 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 define a probabilidade de descartar pacotes dentro de cada fila.
Assim, existem 12 classes AF distintas, que vão desde AF41 até AF13. As classes
AF estão descritas na RFC 2597. Os pacotes com prioridade BE (Best Effort)
possuem a menor prioridade e serão encaminhados depois de todas as outras
classes, se houver recursos para isto. Esta classe está descrita na RFC 2474.
Considerações sobre DiffServ

\\Em cada roteador que trabalhe com diferenciação de serviços, o código contido
no sub-campo DSCP é mapeado em um Per-Hop Behavior (PHB) –
Comportamento por enlace;
\\O PHB define o tratamento a ser dado ao pacote:

\\Os dois principais PHBs definidos pelo IETF são:
\\Encaminhamento Expresso (Expedited Forwarding – EF);
\\Encaminhamento Assegurado (Assured Forwarding – AF).
Uma vez que os pacotes foram 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, conforme
240
descrito. Cada roteador decide como o pacote deve ser encaminhado. Por isso a

expressão Per Hop Behavior (PHB), que significa que a cada salto (hop) é possível
tratar o tráfego de forma independente do salto anterior. Desta forma não é necessário
manter o estado das conexões em cada roteador por onde um fluxo passa.
Encaminhamento
\\Expresso (EF – Express Forward):
\\Objetivo é diminuir o tempo de permanência nas filas dos pacotes em trânsito;
\\Garante prioridade nos pacotes com esta marcação em relação a qualquer outro;
\\Garante tempos de atraso e perdas de pacotes máximos aceitáveis.
\\Assegurado (AF – Assured Forward):

\\Forneceapenas uma expectativa de serviço quando a rede passa por
momentos de congestionamento;
\\O contratante do serviço possui garantias mínimas de QoS.
O encaminhamento expresso “garante” que o pacote atravessará a rede sem

descarte e com um mínimo de atraso. É adequado a serviços prioritários com
requisitos rígidos quanto ao tempo de entrega dos pacotes, como sinalização da
rede, controles de processos em tempo real e telefonia.
O encaminhamento assegurado garante que o fluxo encontrar-se-á dentro de limiares

pré-estabelecidos, podendo haver perdas e variações de atraso (dentro de limites
pré-estabelecidos). É uma boa escolha para serviços que precisam de alguma
prioridade em relação a outros, mas não tem compromisso rígido com o tempo de
entrega dos pacotes.
Serviços Integrados sobre Diferenciados

\\Emprega a arquitetura IntServ nas redes de acesso e a arquitetura DiffServ nas
redes de backbone;
\\O IntServ trata de fluxos, enquanto o DiffServ agrega os diversos fluxos em

classes dentro de um domínio DS;
\\Vantagens da integração:
\\Possibilidade de se implementar serviços de policiamento por fluxo e
autenticação de usuários individuais;
\\Melhor uso de recursos e custo, obtidos com a reserva por fluxo.
Serviços Integrados sobre Serviços Diferenciados são utilizados para racionalizar o

uso de recursos em um modelo de QoS que equilibra a vantagem de alocação de
recursos com a simplicidade do PHB. Essa combinação aplica as arquiteturas onde
241
elas são mais adequadas: IntServ no acesso (próximo ao usuário), onde há uma
quantidade menor de fluxos, sem problemas de escalabilidade; e DiffServ nos

backbones, onde a quantidade de fluxos é muito grande e o processamento de cada
pacote não pode ser alto, para que as altas taxas de transmissão necessárias no
backbone não sejam comprometidas. Mesmo sendo bem diferentes, as duas
arquiteturas podem ser combinadas para criar uma solução fim-a-fim.
NE (Host)
NE (Link) Network Edge

NE (Router)
IntServ
NE (Link)
NE (Router)
DiffServ Transit
Network
NE (Virtual Link)
Fonte: ARMITAGE, Greenville. Quality of Service in IP Networks. New Riders Publishing, 2000.
Figura 10.6
Na figura, os elementos de rede estão indicados com a sigla NE (Network Elements).
Uma ou mais redes IntServ podem ser construídas em volta de uma rede DiffServ.
Podemos conseguir isso tratando a borda da rede (NE – Network Edge) DiffServ
como uma ponta de um link virtual.
Multi-Protocol Label Switching – MPLS

\\O modelo tradicional de roteamento IP pode ser melhorado em redes de backbone:
\\O roteamento é feito pacote a pacote, e dois pacotes com os mesmos
destino e origem podem seguir rotas diferentes;
\\A ideia do MPLS é criar um caminho virtual na entrada da rede MPLS,
permitindo a determinação prévia da sequência de roteadores que
compõem a rota.
\\Vantagens do MPLS:
\\Permite prover QoS;
\\Reduz a carga nos roteadores.
242
O IP foi desenhado para encaminhar pacotes de um ponto a outro da rede, sem

preocupações com descarte ou tempo de entrega. O objetivo principal é o roteamento
inter-redes. Dessa forma, não há preocupação com QoS ou qualquer outra garantia.
Por esse motivo, implementar QoS em redes IP não é uma tarefa trivial.
O IP possui algumas dificuldades, como a necessidade do tratamento individual de

cada pacote (ao invés de fluxos ou de classes) e a possibilidade dos pacotes
chegarem fora da sequência, pois podem seguir caminhos diferentes na rede.
A princípio, a comutação de pacotes, executada pelo MPLS, exige menos

processamento do que o roteamento, executado pelo IP, tornando a rede mais eficiente
e eliminando a possibilidade dos pacotes chegarem fora da sequência correta.
Modelo básico de rede MPLS
Costumer 1 MPLS Core Costumer 2

Label = 10 17
Label =
Label = 35
Costumer 2 Costumer 3
La
Costumer 1 17 Costumer 1
be
l=
l=
e
Lab
20
0
Costumer 3 Costumer 2
Label = 17
MPLS MPLS
Edge Edge
Physical links Segments of LSP 1 Segments of LSP 2
Fonte: ARMITAGE, Greenville. Quality of Service in IP Networks. New Riders Publishing, 2000.
Figura 10.7 O Multi-Protocol Label Switching é em alguns aspectos semelhante ao DiffServ:
\\É um protocolo independente, situado entre a camada de enlace e a camada de

rede (camada 2,5);
\\Normalmente utilizado no núcleo da rede;
\\O pacote recebe um rótulo (label) ao entrar na rede MPLS;
\\Roteamento nas bordas e comutação no núcleo;
\\Dentro da rede o QoS contratado é atendido.
243
Real-time Transport Protocol – RTP
\\Protocolo que oferece funções de transporte de rede fim-a-fim:

\\Áudio e vídeo interativos.
\\Desempenho versus Confiabilidade.
UDP
RTP
Performance
TCP
Reliability
Fonte: Analog Devices: Analog Dialogue: Blackfin Voip; Acessado em 22/02/07. Figura 10.8
O Real-time Transport Protocol (RTP) é um protocolo que oferece funções

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

\\Identificação do tipo payload;
\\Numeração sequencial;
\\Marcas temporais (timestamping);
\\Monitoração da entrega de dados:
\\Permite interpolação.
\\Não trata da reserva de recursos e não garante qualidade de serviço (QoS) em

tempo real.
244
Funcionando sobre o UDP, soma-se a este algumas informações de sequenciamento

e de timestamp necessárias para a sincronização de imagem e áudio e para
possibilitar o sequenciamento correto pela aplicação. O RTP possibilita à aplicação
identificar perdas e avaliar quanto tempo uma amostra pode permanecer
armazenada em um buffer aguardando a chegada do próximo pacote.
A recomendação Secure RTP (RFC 3711) permite uso de criptografia e autenticação

das mensagens RTP e RTCP.
\\Formato do pacote RTP:

\\Os doze primeiros octetos estão presentes em todos os pacotes de um fluxo
de dados de uma sessão RTP;
0 8 16 24 32
V P X #CS M PT Sequence
Timestamp
Syncronization Source (SSRC)
Countributing Source (CSRS)
Header Extention
Payload (áudio, vídeo etc)
Figura 10.9
\\V (Version);
\\P (Padding);
\\X (Extention);
\\CC (CSRC Counter);
\\M (Marker Bit);
\\PT (Payload Type);
\\Sequence Number;
\\Timestamp;
\\SSRC (Synchronization Source) Identifier;

\\CSRC (Contributing Source) Identifiers.
\\V (Version) – versão do RTP;
\\P (Padding) – indica a presença ou não de preenchimento das posições finais do

pacote com um ou mais bytes que não fazem parte da carga;
\\X (Extention) – indica presença ou não de extensão de cabeçalho;
\\CC (CSRC Counter) – contador do número de identificadores CSRC após o

cabeçalho fixo;
245
\\M (Marker Bit) – delimita um conjunto de dados relacionados, o início de uma
rajada de áudio ou o fim de um quadro de vídeo;
\\PT (Payload Type) – indica o formato da carga do RTP e determina sua

interpretação pela aplicação;
\\Sequence Number – incrementado em cada pacote RTP e utilizado pelo receptor

para detectar perda de pacote ou para restaurar a própria sequência;
\\Timestamp – utilizado pelo receptor para sincronização e cálculo do jitter;
\\SSRC (Synchronization Source) Identifier – utilizado para identificar um fluxo

específico em uma sessão RTP. Necessário para o receptor agrupar pacotes com
o mesmo SSRC para a reprodução;
\\CSRC (Contributing Source) Identifiers – lista de identificadores CSRC inseridos

por mixers.
\\V – versão: 2 (RFC 3550);
\\p – padding = 1, se o pacote contém enchimento para completar múltiplos de

32 bytes;
\\x - 1, se houver extensão de cabeçalho;
\\PT (payload type) – tipo de aplicação (codec), definido na RFC 1890 e 3551
(PT=200/RTCP);
\\cc (CSRC COUNT) – número de fontes de mídia contribuintes;
\\m (marker) – depende do PT (igual a 1), por exemplo quando houver supressão
de silêncio;
\\Número de sequência – de 0 a 65535, é inicializado aleatoriamente e

incrementado de um, a cada pacote transmitido;
\\Timestamp – 32 bits, utilizado para calcular o jitter;
\\Synchronization source (SSRC) – identificador da fonte e sincronismo;
\\Contributing source (CSRC) – identifica as fontes contribuintes para mixagem.
Exemplo de uma sessão RTP
Cada fluxo de voz contém uma sessão RTP e uma RTCP.
RTP RTCP RTCP RTP
UDP UDP
Figura 10.10
IP IP
Sessão RTP
Sessão RTP
246
Quando pacotes RTP relativos a um fluxo chegam ao seu destino, o número de

sequência de cada pacote é examinado para determinar a sequência correta dos
dados, e também para registrar a fração de dados (por exemplo, amostras de áudio
ou quadros de vídeo) perdidos.
O valor do timestamp (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 transmissor do fluxo no momento do envio dos dados. Conforme os pacotes do
fluxo chegam ao receptor, a variação no espaçamento entre pacotes (variação do atraso
ou jitter) pode ser examinada, e durante a reprodução, essa informação pode ser
utilizada para cálculo de um buffer dinâmico, com a finalidade de eliminar a variação
do atraso e, ao mesmo tempo impor o menor atraso possível, de forma que o
decodificador possa reproduzir a mídia mantendo uma boa experiência de interatividade.
Real-time Transport Control Protocol – RTCP

\\Protocolo que complementa o transporte de dados feito pelo RTP;
\\Permite o monitoramento da entrega de dados de forma escalável em redes

multicast;
\\Oferece funcionalidades mínimas de controle e identificação;
\\Baseado na transmissão periódica de pacotes de controle para todos os

participantes de uma sessão RTP;
\\Utilizao mesmo mecanismo de distribuição definido para os pacotes que

compõem os fluxos de dados das aplicações;
\\Desempenha 4 funções:
\\Prover informação a respeito da qualidade da distribuição dos dados de
um fluxo;
\\Transportar um identificador de nível de transporte persistente para um
transmissor em uma sessão RTP:
\\Nome canônico (canonical name ou CNAME);
\\As funções anteriores requerem que todos os participantes enviem
pacotes periodicamente;
\\Transportar informações mínimas de controle de sessão.
\\Informações geradas pelo RTPC:

\\Sender Report (SR);
\\Receiver Report (RR);
\\Source Description (SDES);
\\BYE;
\\APP.
247
A frequência de transmissão de pacotes de controle pode variar com a quantidade
de participantes em uma sessão, uma vez que, em caso de uma quantidade muito
alta, o fluxo de dados de controle pode comprometer os fluxos de dados.
Uma das melhorias que a atualização da RFC traz é justamente o desempenho do

protocolo RTCP com um novo algoritmo para cálculo do tempo de transmissão dos
pacotes deste 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 streammings, como voz e vídeo.
O RTCP controla a taxa que os participantes devem enviar informações de controle

para que o fluxo de dados não seja prejudicado. Provê um mínimo de informações
de controle. Informações mais detalhadas, necessárias para algumas aplicações
devem ser providas por nível superior.
\\Sender Report (SR) – para estatísticas de transmissão e recepção de

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

são transmissores ativos em uma sessão;
\\Source Description (SDES) – itens que descrevem um transmissor em uma

sessão, como o CNAME;
\\BYE – para indicar o fim da participação de uma aplicação em uma sessão;
\\APP – para funções específicas da aplicação;
V P IC PT Length
Format-specific information
Padding if P = 1
V = Version number
P = padding
IC = item count Figura 10.11
PT = packet type
Estrutura do
Fonte: PERKINS, Colin. RTP: Audio and Video for the Internet. Boston: Addison Wesley, 2003. RTCP.
248
Há 5 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 estrutura comum, ilustrada na figura.
O cabeçalho dos pacotes RTCP tem em comum 5 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. Este tipo de expediente é necessário quando são utilizados alguns
algoritmos de criptografia 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 5 tipos;
5. Comprimento (Length) – indica o tamanho do conteúdo do pacote contido após

este cabeçalho comum.
Os pacotes RTCP nunca são transmitidos individualmente. Eles são sempre

agrupados para a transmissão, formando pacotes compostos.
V P RC PT=201 Length
Reporter SSRC
Reportee SSRC
First report block

Loss fraction Cumulative number of packets lost
Extended highest sequence number received
Interarrival jitter
Timestamp of last sender report received (LSR)
Delay since last sender report received (DLSR)
Figura 10.12
Next receiver report block
Pacote RR
(Receiver Report)
Utilizado principalmente para reportar sobre a qualidade de recepção, o Receiver

Report é identificado pelo tipo de pacote 201. Podemos ter um total de 31
blocos de reports em cada pacote RR.
\\Reporter SSRC (Reporter Synchronization Source) – fonte de sincronização do

participante que envia o reporte;
249
\\Reportee SSRC (Reportee Synchronization Source) – identifica o participante e
o destinatário deste report. Assim, o destinatário pode saber a qualidade do RTP

recebido pelo emissor;
\\Loss fraction – definido como a fração entre o número de pacotes perdidos no

intervalo de reporte dividido pelo número esperado;
\\Cumulative number of packets lost – representa o número de pacotes esperado,

subtraído o número de pacotes realmente recebidos;
\\Extended highest sequence number received – identifica os pacotes recebidos

para possibilitar a identificação da perda de pacotes;
\\Interarrival jitter – estimativa do jitter dos pacotes;
\\Timestamp of last sender report received (LSR) – Timestamp NTP (Network

Time Protocol) que identifica o tempo do mais recente pacote RTCP SR recebido;
\\Delay since last sender report received (DLSR) – é o delay entre o recebimento
do último pacote SR e o envio do RR.
Reporter SSRC
NTP timestamp
RTP timestamp
Sender’s packet count
Sender’s octet count

Figura 10.13
Receiver report block Pacote SR
(Sender Report)
Além dos relatórios de qualidade dos receptores, o RTCP também possui

relatórios do emissário. Esse relatório fornece informações sobre a mídia enviada.
É identificado pelo tipo de pacote 200.
\\Reporter SSRC (Reporter Synchronization Source) – fonte de sincronização do

participante que envia o reporte;
\\NTP timestamp – corresponde ao tempo de envio do SR;
\\RTP timestamp – corresponde ao tempo de envio do último pacote RTP;
\\Sender’s packet count – número de pacotes de dados gerados pela fonte de

sincronização na seção;
\\Sender’s octet count – número de octetos contido no payload dos pacotes de

dados, incluindo os cabeçalhos e o padding;
250
SSRC / CSRC 1
List of SDES items
SSRC / CSRC 2
List of SDES items

Figura 10.14
Pacote SDES
(Source
Description)
V = Version number
P = padding
SC = number of SDES items
PT = packet type
Figura 10.15
Pacote SDES Type Length Value (not null-terminated)
- Item
O pacote de descrição de fontes é composto basicamente de uma lista de itens
separados pela identificação de fontes individuais de sincronização. É identificado
pelo tipo de pacote 202.
As entradas são armazenadas nos pacotes de uma maneira contínua, sem separação
ou padding. O fim da lista é indicado por um item de tipo zero.
V P SC = 1 PT = 202 Length = 10
SSRC
Type = 1 (CNAME) Length = 15 c s
p @ 1 0
. 7 . 4
2 . 1 6
9 Type = 2 (NAME) Length = 13 C
o l i n
P e r
Figura 10.16 k i n s
Exemplo de
Type = 0 i 0 0
SDES
\\Type 1 (CNAME) – nome canônico, obtido para identificar os participantes;
\\Type 2 (Name) – nome do participante, utilizado basicamente para listar o nome

dos participantes na interface de usuário;
251
\\Type 3 – e-mail do participante;
\\Type 4 (Phone) – telefone do participante;
\\Type 5 (LOC) – localização do participante (normalmente configurado pelo

usuário em sua aplicação);
\\Type 6 (TOOL) – indica a implementação utilizada pelo participante;
\\Type 7 (NOTE) – permite ao participante fazer uma breve nota informando

qualquer mensagem arbitrária;
\\Type 8 (PRIV items) – utilizado para especificar extensões privadas e para criar
extensões experimentais ou específicas para determinadas aplicações.
V P RC PR = 203 Lenght
SSRC 1
SSRC 2
...
SSRC n
Figura 10.17
Optional length Optional reason for leaving
Pacote BYE
V = Version number
P = padding
RC = number of SSRC headers
PT = packet type
V P Subtype PR = 204 Lenght
SSRC
Application-defined packet name
Application-defined data
Figura 10.18
Pacote BYE
\\O BYE é identificado pelo tipo de pacote 203, e mostra que os participantes
indicados deixaram a transmissão.
\\É identificado pelo tipo de pacote 204.
A última classe de pacotes RTCP permite extensões específicas para aplicações, sendo
útil para utilizar extensões RTCP fora dos padrões ou para testar novas funcionalidades.
252
10
\\Conceitos sobre QoS.

\\Ao final desta prática o aluno saberá solicitar QoS para o serviço VoIP que
implementará.

Atividade 1 – Qualidade de Serviço (QoS)
Em se tratando de Qualidade de Serviço na internet, o IETF propôs dois modelos

que se adaptam de acordo com o tipo de aplicação e de arquitetura.
1. Quais são os modelos e suas respectivas RFCs?
2. Quais são as suas vantagens e desvantagens?
253
3. Na figura a seguir, o usuário do PC1 da empresa 2 quer estabelecer uma
comunicação de Voz sobre IP com o usuário do PC2 da empresa 1. Baseando-se no

modelo DiffServ, descreva o processo para classificação de tráfego e escalonamento
de pacotes nos equipamentos de rede mostrados na figura a seguir.
Figura 10.19
4. Com suas palavras, descreva o que é uma rotina de controle de admissão.
5. Qual a função do classificador?
6. Qual a função do escalonador de pacotes?
254
7. Qual o objetivo do Multi Protocol Label Switching (MPLS)?

8. O que é Real-time Transport Protocol (RTP)?
9. Qual o objetivo do Real-Time Transport Control Protocol (RTCP)? Quais as suas

principais funções?
10. Analisando o pacote RTP, observamos o campo Payload Type (PT), que indica o
formato da carga do pacote e como será sua interpretação pela aplicação.
Quantos são os valores para este campo, quais são e o que representam?
255
256
Bibliografia
\\ARMITAGE, Grenville. Quality of Service in IP Networks. New Riders Publishing, 2000.
\\BRANDL, Margit; DASKOPOULUS, Dimitris; DOBBELSTEIJN, Erik; GARROPPO,

Rosario Giuseppe; JANAK, Jan; Kuthan, Jiri; NICCOLINI, Saverio; OTT, Jorg;
PRELLE, Stefan; UBIK, Sven e VERHAREN, Egon. IP Telephony Cookbook.
Terena, 2004.
\\COLCHER, Sérgio; GOMES, Antônio Tadeu; OLIVEIRA, Anderson; GUIDO, L. E.

VoIP: Voz sobre IP. Editora Campus/Elsevier, 2005.
\\DEMPSTER, Barrie; GARRISON, Kerry. TrixBox Made Easy. Packt Publishing, 2006.
\\GOMILLION, David; DEMPSTER, Barrie. Building Telephony Systems with Asterisk.

Packt Publishing, 2006.
\\LOVELL, David; VEIBELL, Scott. Cisco IP Telephony. Cisco Press, 2004.
\\MADSEN, Leif; SMITH, Jarred; MEGGELEN, Jim Van. Asterisk: The Future of
Telephony. O’Reilly, 2005. Disponível em: http://www.asteriskdocs.org/modules/
tinycontent/index.php?id=11. Acessado em 16/08/2006.
\\PERKINS, Colin. RTP: Audio and Video for the Internet. Boston: Addison Wesley, 2003.
\\SINNREICH, Henry e JOHNSTON, Alan B. Internet Communications Using SIP.

Wiley, 2006.
\\SPENCER, Mark; ALLISON, Mack; RHODES, Cristhopher. The Asterisk Handbook

– Version 2.
\\TANENBAUM, Andrew S. Redes de computadores. Editora Campus, 2003.
\\TODD, John. Asterisk: A Bare-Bones VoIP Example. O’Reilly.
\\ITU-T: H.323 Packet-based multimedia communications systems.
\\RFC – 3261
\\Recomendação ITU – G.711
\\Apostila VoIP e Telefonia IP UFF 2009
257
\\www.voip.nce.ufrj.br. Acessado em 22/11/2006, com informações retiradas
sobre o serviço fone@RNP.
\\www.babooforum.com.br. Acessado em 20/08/2006, com informações retiradas

sobre redes de computadores.
\\www.maxrouter.com. Acessado em 12/04/2007, com informações retiradas

sobre codecs.
\\www.speex.org. Acessado em 12/04/2007, com informações retiradas sobre o

codec Speex.
\\www.brasiltelecom.com.br. Acessado em 15/08/2006, com informações retiradas

sobre a história da telefonia.
\\en.wikipedia.org. Acessado em 10/4/2007, com informações retiradas sobre

codecs e evolução das redes e da telefonia.
\\www.anatel.gov.br. Acessado em 15/08/2006, com informações retiradas sobre

a história da telefonia.
\\www.clubedohardware.com.br. Acessado em 15/08/2006, com informações

retiradas sobre redes de dados.
\\www.sobresites.com/telefonia/historiadotelefone.htm. Acessado em 22/08/2006,

com informações retiradas sobre telefonia.
\\www.ilbcfreeware.org. Acessado em 12/04/2007, com informações retiradas

sobre o codec iLBC.
\\www.rnp.br/voip/.Acessado em 22/11/2006, com informações retiradas sobre o

serviço fone@RNP e o projeto VoIP4All.
\\www.cornfed.com/iax.pdf. Acessado em 26/04/07, com informações retiradas

sobre IAX.
\\www.voip.nce.ufrj.br/courses/rnp/Interconexao_Gateways_parte_1_3tr.pdf.
Acessado em 03/05/2007.
\\CISCO. Guia do primeiro ano, segunda edição.
\\Recomendação ITU – G.711
\\www.digium.com
\\Quality of Service, diff serv code point, IP precedence. Acessado em

25/12/2006. Disponível em: www.rhyshaden.com/qos.htm
\\Analog Devices: Analog Dialogue: Blackfin VoIP. Acessado em 22/02/07. Disponível

em: www.analog.com/library/analogDialogue/archives/40-04/blackfin_voip.html
\\www.voip.nce.ufrj.br/courses/rnp/Interconexao_Gateways_parte_1_3tr.pdf.
Utilizado como fonte de fotos.
\\Apostilas do curso VoIP4All
\\www.voip-info.org
258
\\www.packetizer.com
Bibliografia
\\www.asterisk.org
\\www.networksocerty.com/enp/protocol/sip.htm
259
260
Aprenda na prática
a configurar uma rede VoIP
com Asterisk, telefones IP e ATA
O curso capacita o aluno na utilização da tecnologia

VoIP, permitindo o entendimento dos elementos e
benefícios desta solução. Serão vistos seus principais
codecs e protocolos de sinalização e transporte,
as diferenças em relação ao sistema de telefonia
tradicional e o diferencial da aplicação da qualidade
de serviço (QoS) à rede VoIP. Nas atividades
práticas, o aluno montará uma rede VoIP de pequeno
porte utilizando o protocolo SIP e configurará uma
rede de ramais VoIP e um ambiente com softphones,
telefones IP e adaptadores ATA; e aprenderá a
instalar e configurar o Asterisk.
esr.rnp.br

Introduao A Voz Sobre Ip e Asterisk PDF

Enviado por

Dados do documento

Título original

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

Introduao A Voz Sobre Ip e Asterisk PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Mídias de suporte

Introdução à Voz sobre

Introdução à Voz sobre

Todos os direitos reservados, no Brasil, por

Os cursos da ESR são baseados em atividades práticas que desenvolvem no aluno a

ADS4 Virtualização ADR3

Legenda Administração e projeto de redes

A separação entre o que o usuário digita e o retorno do computador é indicada

\\Parágrafo de texto com fundo laranja fonte em branco

Utilizado para destacar os enunciados das atividades ao longo do capítulo.

Atividade 1 – Instalando o cliente X-Lite. . . . . . . . . . . . . . . 34

Capítulo 1 – Histórico e conceitos básicos

A evolução das tecnologias de comunicação e a redução dos custos constituem os

No entanto, as atuais tecnologias de redes restringem o número de dispositivos

A arquitetura TCP/IP é composta de um conjunto de protocolos e foi pioneira na

O TCP/IP é de aplicação universal, com especificações que seguem um padrão e são

Em um ambiente TCP/IP, estações comunicam-se com servidores ou outras

Camadas da arquitetura TCP/IP

Segundo as RFCs, a arquitetura TCP/IP possui 4 camadas:

1. Aplicação – nesta camada estão os protocolos das aplicações suportadas por

2. Transporte – nesta camada existem dois protocolos: TCP (orientado à conexão) e

4. Enlace de dados – nesta camada temos as subredes suportadas pelo IP.

TCP UDP Transporte

ICMP IP IGMP Rede

A arquitetura TCP/IP, conforme já vimos, é constituída de 4 camadas de protocolos.

A camada de aplicação monta a sua PDU com os dados da aplicação e o respectivo

Evidentemente a subrede não entende o endereçamento IP e tem seu próprio

Transporte dos pacotes

O host envia o pacote para o roteador, colocando o endereço físico do roteador

próximo nó e mantendo o endereço de rede do host de destino. Se não tiver a rota

Para: Destino (Endereço rede)

Roteador1 Para: Destino (Endereço rede)

Para: Destino (Endereço rede)

Para: Destino (Endereço rede)

Capítulo 1 – Histórico e conceitos básicos

\\Host é qualquer equipamento com capacidade de transmitir e receber pacotes

\\Hosts são interconectados por uma ou mais redes;

\\O endereço IP é composto por:

\\Tamanho de 32 bits (4 octetos) representados por 4 números decimais

\\Exemplo: 200.201.152.93 (notação decimal pontuada).

Um endereço IP é composto de um identificador de rede acrescido de um

Por exemplo, dado o endereço IP: 00000011.00000111.00001111.00000001,

\\Os primeiros bits do primeiro octeto definem a classe do endereço;

\\N = número da rede (network) dado pelo NIC;

\\H = número da estação (host) dado pelo administrador da rede.

32 Bits 8 Bits 8 Bits 8 Bits 8 Bits

Rede Host 131 108 122 204

O endereço IP tem tamanho de 32 bits e possui duas partes:

O formato do endereço é conhecido como notação decimal pontuada, que é

Exemplo de endereço: 131.108.122.204.

A alocação dos endereços é gerenciada por uma autoridade central. Números de

Para facilidade de administração, os endereços IP são divididos em classes:

\\Classe A – utiliza somente o primeiro octeto para identificar a rede. Os outros 3

Capítulo 1 – Histórico e conceitos básicos

\\Classe C – utiliza somente os três primeiros octetos para identificar a rede. O

O(s) bit(s) mais significativo(s) do primeiro octeto determina(m) a classe do

\\Quantidade de endereços de hosts: 16.777.214.

\\Quantidade de endereços de hosts: 65.534.

\\Quantidade de endereços de hosts: 254.

Classes A, B e C são as classes mais comuns de endereço IP, mas endereços de

\\10.0.0.1 10.255.255.254 (10/8 prefix)

\\172.16.0.1 172.31.255.254 (172.16/12 prefix)

\\192.168.0.1 192.168.255.254 (192.168/16 prefix)