Mídias de suporte à colaboração digital

Introdução à Voz sobre IP e Asterisk

Mídias de Suporte à Colaboração Digital

Introdução à Voz sobre IP e Asterisk

Mídias de Suporte à Colaboração Digital

Introdução à Voz sobre 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

u esto QUI A

Introdução ao Linux
MID2
40h

ADR4

Introdução à Voz sobre IP e Asterisk
40h

Interconexão de Redes de Computadores
40h

SEG1

ADS2

Introdução à Segurança de Redes
40h

Administração de Sistemas Linux
40h

ADR1

ADS3

Arquitetura e Protocolos de Rede TCP-IP
40h

ADR6

Adm. Sistemas Linux: Redes e Segurança
40h

Tecnologias de Redes Sem Fio
40h

SEG2

Segurança de Redes e Sistemas
40h

ADS5 ADS4

Adm. Sistemas Linux: Serviços para Internet
40h

Virtualização de Servidores
40h

ADR3

Roteamento Avançado
40h

SEG6

Segurança em Redes Sem Fio
40h

ADR7 ADR5

IPv6 Básico
40h

Gerência de Redes de Computadores
40h

Grade curricular da Escola Superior de Redes
esr.rnp.br

GTI10

Planejamento e Projeto de Infraestrutura para Datacenter
GTI6
40h

i Bás

co
GTI2

Gerenciamento de Projetos de TI Fundamentos de Governança de TI
16h 24h

GTI1 GTI8

Gestão da Segurança segurança da Informação informação
NBR 27001 eNBR27002 27001, NBR 27002

Planejamento e Gestão Estratégica de TI
24h

GTI3

Inte

di rme

ário
GTI4

Gerenciamento de Serviços de TI
24h

40h

GTI9 SEG4 SEG3

Governança de TI
24h

Gestão de Riscos de TI
NBR 27005

Análise Forense
40h

Tratamento de Incidentes de Segurança
40h

40h

nç Ava
GTI5

ado

GTI7

ITIL

Information Technology Infrastructure Library

COBIT
Control Objectives for Information and Related Technology

16h

Engenharia Reversa de Código Malicioso
40h

SEG8

16h

Áreas temáticas Mídias de suporte à colaboração digital Administração de sistemas

Legenda
Todos os cursos da ESR requerem inglês para leitura e noções de informática e Internet. Conhecimento prévio recomendado Curso

Administração e projeto de redes Segurança Governança de TI
v

Mídias de Suporte à Colaboração Digital
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?
\\Profissionais

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

\\Itálico

\\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. 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. 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 [ ].

\\Texto

\\Largura constante

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. de texto com fundo laranja fonte em branco

\\Parágrafo

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 . . . . . Arquitetura TCP/IP . . . . . . . . Camadas da arquitetura TCP/IP . . . Endereçamento IP . . . . . . . . Classes de endereçamento . . . . . Endereços especiais . . . . . . . Roteamento . . . . . . . . . . Comunicação VoIP . . . . . . . . Evolução do VoIP . . . . . . . . VoIP ≠ ToIP . . . . . . . . . . Vantagens e desvantagens do VoIP . . Benefícios do VoIP . . . . . . . . Existem três formas de comunicação via Padronização . . . . . . . . . . Princípios de codificação de áudio . . Codificação da mídia de voz. . . . . Codec . . . . . . . . . . . . Codificação de forma de onda . . . . Codificação paramétrica . . . . . . Codificação híbrida . . . . . . . . Padrões de codificação de voz . . . . G.711 . . . . . . . . . . . . G.729 . . . . . . . . . . . . G.723.1 . . . . . . . . . . . iLBC . . . . . . . . . . . . . Arquitetura VoIP . . . . . . . . . Projetos VoIP no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 .3 .4 .7 .8 .9 10 12 12 13 13 14 17 20 21 24 25 25 26 26 27 28 28 29 29 30 31

1

Introdução à Voz sobre IP e Asterisk

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 33 Atividade Atividade Atividade Atividade Atividade Atividade Atividade Atividade Atividade 1 2 3 4 5 6 7 8 9 – – – – – – – – – Instalando o cliente X-Lite . . . . . . Configurando o X-Lite . . . . . . . . Configurando o Telefone IP . . . . . . Configurando o ATA . . . . . . . . . Efetuando chamadas com ATA, Telefone IP Verificando codecs de áudio . . . . . . Conhecendo o Wireshark . . . . . . . Efetuando capturas com Wireshark . . . Capturando pacotes na rede . . . . . . . . . . . . . . . . . . e X-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 34 36 37 39 39 43 44 46

2

\\Conceitos

básicos de rede: TCP/IP; dos pacotes; IP; da arquitetura TCP/IP;

\\Arquitetura \\Camadas

\\Transporte

\\Endereçamento \\Classes

de endereçamento; especiais;

\\Endereços

\\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; universal.

\\Arquitetura

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.

Capítulo 1 – Histórico e conceitos básicos 3

Conceitos básicos de rede

Introdução à Voz sobre IP e Asterisk

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 & Rlogin

FTP TCP

HTTP

SMTP

DNS

TFTP

SNMP

NFS & RPC

Aplicação Transporte Rede Enlace de dados

UDP IP
Hardware Interface

ICMP ARP

IGMP RARP

Figura 1.2

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

Capítulo 1 – Histórico e conceitos básicos 5

Introdução à Voz sobre IP e Asterisk

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) Router2 (Endereço físico)

Roteador2

Roteador3

Para: Destino (Endereço rede) Router3 (Endereço físico)

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

Pacote Destino

Figura 1.3

6

\\Endereços \\Host

IP são baseados nos conceitos de rede e host;

é qualquer equipamento com capacidade de transmitir e receber pacotes IP em uma rede; são interconectados por uma ou mais redes;

\\Hosts \\O

endereço IP é composto por: da rede; do host na rede.

\\Identificação \\Identificação \\Tamanho

de 32 bits (4 octetos) representados por 4 números decimais separados por um ponto; 200.201.152.93 (notação decimal pontuada).

\\Exemplo:

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.

Capítulo 1 – Histórico e conceitos básicos 7

Endereçamento IP

Introdução à Voz sobre IP e Asterisk

Classes de endereçamento
\\Os \\N \\H

primeiros bits do primeiro octeto definem a classe do endereço;

= número da rede (network) dado pelo NIC; = número da estação (host) dado pelo administrador da rede.
32 Bits 8 Bits 8 Bits 8 Bits 8 Bits

Rede

Host Classe A Classe B Classe C

131 N N N

108 H N N

122 H H N

204 H H H
Figura 1.4

O endereço IP tem tamanho de 32 bits e possui duas partes:
\\Número \\Número

de rede; 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

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; de endereços de hosts: 16.777.214.

\\Quantidade

Endereços classe B
\\Faixa

dos números das redes: 128.1.0.0 até 191.254.0.0; de endereços de hosts: 65.534.

\\Quantidade

Endereços classe C
\\Faixa

dos números das redes: 192.0.1.0 até 223.255.254.0; de endereços de hosts: 254.

\\Quantidade

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.255.255.254 172.31.255.254 192.168.255.254 (10/8 prefix) (172.16/12 prefix) (192.168/16 prefix)

\\10.0.0.1 \\172.16.0.1 \\192.168.0.1 \\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

Capítulo 1 – Histórico e conceitos básicos 9

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

Introdução à Voz sobre IP e Asterisk

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

Origem

Destino

Figura 1.5

Protocolos de transporte
\\Dois

protocolos de comunicação fim-a-fim são definidos: – User Datagram Protocol; – Transmission Control Protocol.

\\UDP \\TCP

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ãoconfiá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.

Capítulo 1 – Histórico e conceitos básicos 11

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.

Introdução à Voz sobre IP e Asterisk

Comunicação VoIP
\\O

VoIP pode utilizar os protocolos de transporte UDP e TCP; ideal hoje:

\\Ambiente \\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 \\1998: \\Surgem

Israel, a empresa VocalTec lança o primeiro software comercial de VoIP .

os primeiros sistemas que integram VoIP e telefones convencionais, disseminando a tecnologia; os primeiros padrões relacionados a VoIP .

\\Aparecem \\Criados

por: Engineering Task Force (IETF); Internacional de Telecomunicações (ITU).

\\Internet \\União \\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

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 \\VoIP: \\Refere-se

(Voz sobre IP) versus ToIP (Telefonia sobre IP);

à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. IP:

\\Telefonia

\\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; ao seu investimento; de utilizar a infraestrutura existente; simplificada;

\\Proteção

\\Possibilidade \\Infraestrutura

\\Portabilidade; \\Funcionalidades

acrescidas.

Capítulo 1 – Histórico e conceitos básicos 13

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.

Introdução à Voz sobre IP e Asterisk

Desvantagens:
\\Alto

custo inicial (para redes totalmente IP); de nova aparelhagem; da aparelhagem já existente;

\\Aquisição

\\Modernização \\Escassez

de mão de obra especializada; da rede / problemas relacionados a QoS.

\\Limitação

Benefícios do VoIP
\\Custos \\Alto

reduzidos nas comunicações;

retorno sobre o investimento (ROI); simplificada;

\\Infraestrutura \\Portabilidade;

\\Funcionalidades \\Mão

acrescidas;

de obra especializada; da rede / QoS;

\\Limitações

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

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 \\Um

a integração telefônica de instalações separadas fisicamente.;

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; 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; de call center que utilizam telefones VoIP podem trabalhar de qualquer local que tenha uma boa conexão com a internet.

\\Ao

\\Agentes

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.

Capítulo 1 – Histórico e conceitos básicos 15

Portabilidade

Introdução à Voz sobre IP e Asterisk

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; Flood – negação de serviço, que consiste no envio de uma grande quantidade de mensagens SIP forjadas para um componente da rede VoIP; 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; 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.

\\SIP

\\SIP-Cancel/Bye

\\Manipulação

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

\\VoIP

via softphone:

\\Utilizando

um software adequado, um computador pode ser utilizado facilmente para a comunicação via VoIP . via ATA: em usar um Adaptador de Telefone Analógico (ATA);

\\VoIP

\\Consiste

\\Exemplo:

pluga-se um telefone comum ao ATA e este ao computador, permitindo assim o uso do sistema VoIP . via telefones IP:

\\VoIP

\\Possuem \\Também

a mesma aparência de um telefone comum, mas utilizam conectores RJ-45 Ethernet; 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.

Capítulo 1 – Histórico e conceitos básicos 17

Existem três formas de comunicação via VoIP

Introdução à Voz sobre IP e Asterisk

Telefonia tradicional X telefonia IP
\\Telefonia

tradicional: rede hierárquica;

\\PSTN:

\\Baseada \\Os \\O \\O

em grandes centrais telefônicas ligadas entre si de forma hierárquica; terminais não possuem inteligência; endereçamento depende da região de abrangência da rede; codec utilizado nas redes digitais era o G.711; são muito controlados, com cerca de 40 ms.

\\Atrasos \\Telefonia \\Rede \\Os \\O

IP: não hierárquica (sob a óptica do serviço de voz);

terminais são diferentes dos usados na telefonia fixa;

telefone IP pode ser um software executando em um computador ou hardware dedicado. de voz precisam passar por filas;

\\Pacotes \\Jitter

e perdas de pacotes comprometem a qualidade da ligação; de QoS são desejáveis.

\\Mecanismos

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

Voz analógica sobre par trançado

roteador PBX voz pacotizada

assinante Telefone IP Rede comutada (Multiplexação TDM)

Internet

Internet

PBX assinante Voz analógica sobre par trançado Telefone IP voz pacotizada roteador

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

Capítulo 1 – Histórico e conceitos básicos 19

Introdução à Voz sobre IP e Asterisk

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: Standardization Sector do International Telecommunications

\\Telecomunication

Union – ITU-T;
\\Internet \\Os

Engineering Task Force – IETF.

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; padrões opcionais que também podem ser utilizados nos sistemas de videoconferência; disso, cada fabricante pode adicionar padrões proprietários às suas soluções: mínimo + padrões opcionais + padrões proprietários.

\\Há

\\Além

\\Conjunto

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

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); converter áudio analógico em digital? minimizar o erro de quantização (duas formas)? taxa de amostragem deve ser utilizada, supondo que:

\\Como

\\Como \\Que

\\Frequência \\Frequência \\Qual

da voz humana: 20 Hz – 6.000 Hz (banda de 4 kHz fornece inteligibilidade perfeita). do ouvido humano: 20 Hz – 20.000 Hz; 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).

Capítulo 1 – Histórico e conceitos básicos 21

Padrões de videoconferência

Introdução à Voz sobre IP e Asterisk

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 000

Figura 1.8
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

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 \\Voz

do sinal;

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

Capítulo 1 – Histórico e conceitos básicos 23

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.

Introdução à Voz sobre IP e Asterisk

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:
\\Tutorial

de VoIP disponível em: www.teleco.com.br/tutoriais/tutorialtelip/pagina_1.asp de diversos codificadores de vídeo: en.wikipedia.org/wiki/Comparison_of_audio_codecs

\\Resumo/Comparação

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; de forma de onda:

\\Codificadores \\Melhor \\Vocoders: \\Menor

qualidade, menor atraso, maior taxa de bits.

taxa de bits, pior qualidade, grande atraso e jitter. híbridos:

\\ Codificadores \\Boa

taxa de bits, boa qualidade, atraso e jitter razoáveis.

24

\\Codec

é uma abreviação de codificador-decodificador;

\\Codecs

especificam como os sinais analógicos da voz devem ser codificados em dados digitais; permitem compressão dos dados;

\\Codecs \\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ógicadigital, 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 \\No \\O

origem: conversão A/D -> Analógico-Digital; destino: conversão D/A -> Digital-Analógico;

esquema mais utilizado é o Adaptive Differential Pulse Code Modulation (ADPCM); em predição linear.

\\Baseada

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

Capítulo 1 – Histórico e conceitos básicos

Codec

Introdução à Voz sobre IP e Asterisk

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 \\ A

denominados vocoders (voice coders):

classe de vocoders mais utilizada é a dos vocoders LPC (Linear Predictive Coding); 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.

\\Utilizam,

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 \\ A

características dos codificadores de forma de onda e dos vocoders;

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 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 G.711 G.722 G.722.1 G.722.2 G.723.1 G.726 G.728 G.729 ILBC Faixa de frequência 300 Hz – 3.4 kHz 50 Hz – 7 kHz 14 kHz 50 Hz – 7 kHz 8 kHz 8 kGz 300 Hz – 3.4 kHz 8 kHz 300 Hz – 3.4 kHz Taxa de transmissão 64 kbit/s 48, 56 ou 64 kbit/s 24-32 kbit/s 6.6 – 23.85 kbit/s 5.3 ou 6.3 kbit/s 16 – 40 kbits/s 16 kbit/s 8 kbits/s 13,33 ou 15,20 kbit/s Latência <1 <2 100 60 <2 25 – 35 30 – 20 Razoável a boa Boa a razoável Boa Boa Boa Tabela 1.1 Boa Qualidade Excelente

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.

Capítulo 1 – Histórico e conceitos básicos 27

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.

Introdução à Voz sobre IP e Asterisk

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 \\ Representa \\Comprime

padrão ITU-T de larga aplicação; os sinais de voz usando o formato PCM;

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; o algoritmo Conjugate Structure Algebraic Code Excited Linear Prediction (CS-ACELP), baseado no modelo de codificação Code Excited Linear Prediction (CELP); originalmente para uso na telefonia fixa com comutação de circuito.

\\Utiliza

\\Desenvolvido

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

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; taxas de 5,3 kbps, usa o algoritmo ACELP (Algebraic Code Excited Linear Prediction); taxas de 6,3 kbps, usa o algoritmo MP-MLQ (Multipulse Maximum Likelihood Quantization).

\\Para

\\Para

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; para propiciar comunicação robusta em VoIP com tolerância a , perdas e recuperação de erros;

\\Desenvolvido

Capítulo 1 – Histórico e conceitos básicos 29

voz de entrada já convertido para o formato PCM uniforme, com 16 bits/amostra e taxa de amostragem de 8 kHz.

Introdução à Voz sobre IP e Asterisk

\\Baseado \\Opera

em predição linear; não usa o modelo CELP .

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
TM GC MCU GK GK MCU GC

Zona 2
TM

Tel IP

Tel IP

Rede IP

GW

GW

Visão geral dos diversos elementos que podem interagir dentro da arquitetura VoIP:
\\Gatekeeper

...
PABX

...

STFC

PABX

...

...
Figura 1.10

(GK) – permite o controle centralizado do sistema;

30

\\Unidades

de Controle Multiponto (MCU) – permitem o estabelecimento de conferências entre três ou mais pontos finais; (GW) – necessário quando se deseja estabelecer comunicação entre terminais em diferentes tipos de redes.

\\Gateway

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 \\ Aparelhos

IP; telefônicos em seus departamentos.

Capítulo 1 – Histórico e conceitos básicos 31

\\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;

Introdução à Voz sobre IP e Asterisk

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 Gatekeeper H.323 + VQCDR Server para coleta de CDR VQOpenPhone Suporte ao envio de CDR com informação de qualidade

Asterisk Gateway SIP/H.323 Gateway VOIP/PSTN

PSTN
lid a de

Arm a de i zenam n e de c formaç nto õ onta bilid es ade

Cliente SIP Ambiente SIP
A e ut nt ic a

o çã

e

co

a nt

bi

Autenticação e contabilidade

e ão aç tic ten Au bil nta co de ida

Consulta Apache para disponibilização de estatísticas + Nagios para gerência do serviço

Consulta FreeRadius LDAP Diretório para identificação e autenticação e usuários

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 \\Análise

e configuração dos clientes VoIP X-Lite, Telefone IP e ATA;

do tráfego da rede com ferramenta de captura de tráfego.

Competências técnicas desenvolvidas
\\Aprendizado \\Identificação

sobre as funcionalidades dos clientes X-Lite, Telefone IP e ATA; 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 \\Senha

= root;

= 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

Introdução à Voz sobre IP e Asterisk

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

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

Capítulo 1 – Histórico e conceitos básicos 35

Caso seja a primeira vez que você esteja configurando, este passo não é necessário.

Introdução à Voz sobre IP e Asterisk

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

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>

Capítulo 1 – Histórico e conceitos básicos 37

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:

Introdução à Voz sobre IP e Asterisk

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; Name: entre com seu nome completo;

\\Display \\User

ID: 30XX; voip;

\\Password: \\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

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

Capítulo 1 – Histórico e conceitos básicos 39

Passo 6: clique no botão Save Settings.

Introdução à Voz sobre IP e Asterisk

Na página abaixo, clique em Audio Processing:

Figura 1.23

40

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

Capítulo 1 – Histórico e conceitos básicos 41

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.

Introdução à Voz sobre IP e Asterisk

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

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

Capítulo 1 – Histórico e conceitos básicos 43

Atividade 7 – Conhecendo o Wireshark

Introdução à Voz sobre IP e Asterisk

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

Figura 1.31

Figura 1.32 Complete a tabela abaixo conforme os dados obtidos na captura: Pacote TCP No campo “Ethernet II” informe: MAC e “IG bit” No campo “Internet Protocol” Version Header length Total length Source Tabela 1.2 Do pacote TCP: Transmission Control Protocol Source Port Destination Port Flags Version Header length Total length Destination Src Dst Pacote UDP Src Dst

Do pacote UDP: User Datagram Protocol Source Port Data Destination Port TCP Length UDP

Tabela 1.3

Capítulo 1 – Histórico e conceitos básicos 45

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 .

Introdução à Voz sobre IP e Asterisk

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

\\Camada \\Camada \\Camada \\Camada

física; de enlace de dados; de rede; 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:

Capítulo 1 – Histórico e conceitos básicos 47

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:

Introdução à Voz sobre IP e Asterisk

48

2
Protocolo SIP

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

49

Introdução à Voz sobre IP e Asterisk

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 85 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

\\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. a comunicação possível com outros protocolos, como: Time Protocol / Real Time Control Protocol (RTP/RTCP); Description Protocol (SDP); Time Streaming Protocol (RTSP); Gateway Control Protocol (MGCP).

\\Tornar

\\Real

\\Session \\Real

\\Media

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;

Capítulo 2 – Protocolo SIP 51

Protocolo de iniciação de sessão – SIP

Introdução à Voz sobre IP e Asterisk

\\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); Initiation Proposal Investigation (SIPPING); Multimedia Session Control (MMUSIC);

\\Session

\\Multiparty \\IP

Telephony (IPTEL); Interworking (PINT).

\\PSTN-Internet

\\SIMPLE

– grupo que foca seu trabalho nas aplicações relacionadas ao protocolo SIP conhecidas como instant messages e presence; , – 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; – grupo responsável por desenvolver protocolos que suportem teleconferência e comunicações multimídia; – 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;

\\SIPPING

\\MMUSIC

\\IPTEL

52

Características do protocolo SIP
\\Simples; \\Independente \\Baseado

do protocolo de transporte;

em texto; ponto-a-ponto:

\\Sinalização \\Toda

lógica está armazenada nos clientes, exceto mensagens de roteamento. ao Session Description Protocol (SDP): para transportar descrições dos parâmetros de cada sessão.

\\Associado \\Usado \\Trabalha \\O

com IPv4 e IPv6;

que o SIP não é e não faz: é um protocolo de transferência de dados; pequenas mensagens, mas não grande quantidade de dados; fornece suporte para QoS; tem a finalidade de substituir todas as características da telefonia; é um protocolo de reserva de recurso;

\\Não

\\Transporta \\Não \\Não \\Não \\Não \\Não

é um protocolo para controle de dispositivos ou procedimento para chamadas remotas (Remote Procedure Calls – RPC); substituirá o protocolo da PSTN; juntamente com a PSTN através de gateways, mas esta não é sua função principal.

\\Trabalha

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; em relação ao protocolo de transporte;

\\Independência \\Baseado \\Assim

em texto;

como o HTTP o SIP leva os controles da aplicação para o terminal, , eliminando a necessidade de uma central de comutação.

Capítulo 2 – Protocolo SIP 53

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

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.

Introdução à Voz sobre IP e Asterisk

Elementos de uma rede SIP
\\Rede

SIP simples:

\\Apenas

para comunicação entre dois user agents, enviando mensagens SIP diretamente. SIP típica: mais de dois tipos de elementos SIP: agents; Servers:

\\Rede

\\Contém \\User

\\Proxy

\\Stateful; \\Stateless. \\Redirect

server;

\\Registrar. \\User

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

\\Terminais \\Dentro

\\User \\User \\User

Agent Client (UAC): do UA que envia as requisições e recebe as respostas.

\\Parte \\User

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

\\Parte \\UAC

e UAS são entidades lógicas.

54

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; (User Agent Server) – o Usuário Agente Servidor é a parte com função de servidor e permanece “ouvindo” a rede, aguardando requisições.

\\UAS

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. Stateful mantêm o estado das chamadas. Podem se encarregar de tarefas como bilhetagem e contabilização.

\\Proxies

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.

Capítulo 2 – Protocolo SIP 55

Arquitetura do SIP

Introdução à Voz sobre IP e Asterisk

Callee A UAC Caller UAC Stateful Forking Proxy
Invite

UAS

Invite
UAS

UAC Callee B

UAS

UAC

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 \\Tem

intermediária que atua como servidor e cliente;

o propósito de fazer requisições em nome de outros clientes; dois tipos de servidores proxy:

\\Existem

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

\\Entidade \\Mais

lógica que mantém o estado de todas as transações de clientes e servidores: complexo do que o servidor stateless; limitada; com forking;
\\Performance \\Trabalha \\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; todas as requisições e respostas recebidas;

\\Repassa \\Não

se importa com o que acontece com as transações, apenas as repassa; rápido do que o servidor stateful, entre outras funções podendo servir de: de mensagens;

\\Mais

\\Tradutor

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

Capítulo 2 – Protocolo SIP 57

Servidor Stateful

Introdução à Voz sobre IP e Asterisk

Utilização do servidor proxy
\\Comunicação

entre duas empresas com servidor Proxy.
DNS Server

2. SIP SRV for b.com Company A Joe 1. Invite proxy.a.com

3. proxy.b.com Company B proxy.b.com 4. Invite

5. In
5.6.7.8
6. Bye

vite

Bob

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; respostas do tipo 3xx para as requisições feitas.

\\Gera

58

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

nv ite

M

2. 3 ov 02 ed Te

Figura 2.3

User Agent A

m

po ra rily

1. I

3. Invite 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 \\Recebe \\Extrai

especial SIP;

os registros dos usuários;

a informação de sua localização atual: IP;

\\Endereço \\Porta;

\\Username. \\Armazena \\Caso

informações em um banco de dados;

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

Capítulo 2 – Protocolo SIP

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.

Introdução à Voz sobre IP e Asterisk

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
UA
2. Store

Registrar Register Store Location 200 OK

Location Database

sip:jan@iptel.org 1. Register

3. 200 OK 1.2.3.4:5060

Registrar

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); SIP: username@domain nome do usuário; domínio utilizado pelo usuário.

\\Sintaxe

\\Username: \\Domain: \\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

\\A

comunicação SIP determina a troca de várias mensagens: mensagem pode ser: do cliente para o servidor; do servidor para o cliente.

\\Uma

\\Requisição \\Resposta \\As \\Há \\SIP

mensagens podem ser transportadas via UDP ou TCP; dois tipos de mensagens SIP: Requests:

\\Uma

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

\\SIP

\\Quando

um User Agent ou um servidor proxy recebe uma requisição e envia uma resposta. de requisição (SIP Request):

\\Mensagem \\Linha

de requisição como linha de início:

\\Método; \\Endereço: \\Formato

definido como uma Universal Resource Identifier (URI). da versão SIP:

\\Identificação \\SIP/2.0. \\São

especificados seis métodos para a versão corrente do SIP: métodos foram definidos por extensões do SIP .

\\Outros

Mensagens SIP possuem a seguinte estrutura:
\\Mensagem \\Cabeçalho \\CRLF

genérica: = linha de início; da mensagem;

(Carrige Return Line Feed); da mensagem];

\\[corpo \\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.

Capítulo 2 – Protocolo SIP 61

Mensagens SIP

Introdução à Voz sobre IP e Asterisk

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 INVITE ACK BYE CANCEL REGISTER OPTIONS Funcionalidade Usado para convidar um UA a estabelecer uma sessão. Confirma convite do INVITE. Termina a sessão multimídia. Cancela a sessão, mas não por inteiro. Registra a informação do contato. 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; – pode corresponder às mensagens Alerting ou Connect no DSS-1/Q. sig/H.323 ou ACM, Call progress ou ANM (atendimento) na ISUP; – corresponde à mensagem Release (REL) no DSS-1/Q.sig, Releasecomplete (RLC) no H.323 e REL na ISUP;

\\ACK

\\BYE

62

\\REGISTER

– semelhante ao procedimento RAS no H.323, e manual nas sinalizações telefônicas; – não existe correspondente exato nas sinalizações telefônicas.

\\OPTIONS

Métodos de requisições estendidos Método INFO MESSAGE NOTIFY PRACK PUBLISH REFER SUBSCRIBE UPDATE RFC 2976 3428 3265 3262 3903 3515 3265 3311 Funcionalidade Carrega informações de controle geradas durante a sessão. Permite a transferência de mensagens instantâneas. Permite a notificação de eventos específicos. Confirma a recepção de uma mensagem de resposta informativa. Publica o estado de um evento. Solicita que um receptor faça contato com um terceiro participante. Permite que se subscreva para um estado particular em um recurso. Permite a atualização dos parâmetros de uma sessão.

Tabela 2.2

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.

Capítulo 2 – Protocolo SIP 63

\\CANCEL

– corresponde à mensagem notify no DSS-1/Q.sig/H.323;

Introdução à Voz sobre IP e Asterisk

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-84a0d56e91fe104f 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, da versão SIP;

formada por:
\\Identificação \\Código \\Código \\Frase \\Muito

de status numérico; de resultado com três dígitos;

textual.

similares às requisições, exceto pela primeira linha.

64

\\Existem \\1xx \\2xx \\3xx \\4xx \\5xx \\6xx

seis classes do tipo SIP Responses:

– Resposta informativa; – Respostas de sucesso; – Respostas de redirecionamento; – Respostas de falha de requisição; – Respostas de falha em servidor; – 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 \\Status

do SIP – 2.0 (atual); 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; 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.

\\SIP

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.

Capítulo 2 – Protocolo SIP 65

Introdução à Voz sobre IP e Asterisk

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
100 180 181 182 183 Trying Ringing Call forwarded Queued Session Progress

Success
200 OK 300 301 302 380

Redirection
Multiple Choices Moved Perm. Moved Temp. Alternative Serv.

Request Failure
400 401 403 404 405 415 420 486 Bad Request Unauthorized Forbidden Not Found Bad Method Unsupp. Content Bad Extencions Busy Here 600 603 604 606 Busy Everwhe Decline Doesn’t Exist Not Acceptable

500 501 503 504

Server Error Not Implemented Unavailable Timeout

Server Failure

Global Failure

Figura 2.5

\\1xx \\2xx \\3xx \\4xx

– informativo, pedido recebido, sessão em progresso; – sucesso, ação recebida, entendida e aceita com sucesso; – Rrdirecionamento, ação adicional deve ser tomada para completar a sessão;

– erro de cliente, sintaxe inválida ou por algum motivo a sessão não pode prosseguir (os motivos são listados); – erro de servidor (os motivos são listados); – falha global (os motivos são listados);

\\5xx \\6xx

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

\\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” da mensagem: estruturada de campos de cabeçalho (header fields) após a linha aos campos do cabeçalho das mensagens HTTP;

\\Cabeçalho

\\Sequência

de início;
\\Semelhantes \\Podem

ser incluídos em mensagens de:

\\Requisição; \\Resposta. \\Dependendo

da mensagem, os campos podem ser:

\\Obrigatórios; \\Opcionais; \\Não \\Cada

aplicáveis.

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 \\Nome \\ = \\Valor

por: do parâmetro

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

Capítulo 2 – Protocolo SIP

Exemplo de SIP Response

Introdução à Voz sobre IP e Asterisk

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 To From Call-ID CSeq ou Command Sequence Obs.: Descrição completa dos campos que compõem o cabeçalho na RFC 3261, sessão 20.
\\Via

Contact Max-Forwards Content-Type Content-Length

Tabela 2.3

– 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; – especifica o destinatário que deve receber a requisição; – indica quem irá fazer a requisição; – informa o identificador único específico para uma sessão;

\\To

\\From

\\Call-ID

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

\\Max-Forwards

– serve para limitar o número de proxies ou gateways que podem enviar requisições para um próximo servidor; – contém a descrição do corpo da mensagem, indicando o tipo de mídia do corpo da mensagem enviada ao destinatário; – indica o tamanho do corpo da mensagem. Campos para requisições Authorization Hide In-Reply-To Max-Forwards Priority ProxyAuthorization Proxy-Require Route Subject Response-Key Campos para respostas Authorization-Info Error-Info Min-Expires Proxy-Authenticate Retry-After Server Unsupported Warning WWWAuthenticate Campos para entidades

\\Content-Type

\\Content-Length

Campos gerais

Accept AcceptEncding AcceptLanguage Alert-Info Call-ID Call-Info Contact Cseq Date Encryption From MIME-Version Organization Record-Route Reply-To Require Supported Tabela 2.4 Categoria dos campos Timestamp To

Allow Content-Disposition Content-Encoding Content-Language Content-Length Content-Type Expires

Capítulo 2 – Protocolo SIP 69

\\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;

Introdução à Voz sobre IP e Asterisk

Campos gerais

Campos para requisições

Campos para respostas

Campos para entidades

User-Agent Via
\\Campos

gerais – possuem as informações básicas para tratamento das requisições e respostas; 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; para respostas – específicos para mensagens de resposta, oferecendo mais informações sobre o status indicado nessas mensagens; 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.

\\Campos

\\Campos

\\Campos

Exemplo de fluxo de mensagens:
Atlanta.com proxy Alice softfone Invite F1 100 Trying F3 Invite F2 100 Trying F5 180 Ringing F7 180 Ringing F8 200 OK F10 200 OK F11 ACK F12 Sessão de mídia Bye F13 200 OK F14 Invite F4 180 Ringing F6 200 OK F9 Biloxi.com proxy Bob SIP Phone

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): pela RFC 2327; para descrever sessões;

\\Definido \\Utilizado

\\Especifica

apenas o formato para a descrição das informações trocadas entre entidades SIP . a ser utilizada; para a transmissão da mídia: de controle para transmissão.

\\Mídia

\\Informações \\Padrão

do codec;

\\Protocolo \\Para

a mídia, o SDP inclui as seguintes informações: de mídia (vídeo, áudio); de transporte (RTP / UDP / IP H.320); , da mídia (H.261 vídeo, MPEG vídeo).

\\Tipo

\\Protocolo \\Formato

Capítulo 2 – Protocolo SIP 71

Introdução à Voz sobre IP e Asterisk

\\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 pontomultiponto (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 \\Permite

a portabilidade; 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; textuais e valores dos atributos podem utilizar todo o conjunto de caracteres do UTF-8.

\\Campos

\\Uma

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

\\Os \\A

\\Tipo \\A

descrição de uma sessão consiste de: do nível de sessão:
\\Detalha

\\Descrição

informações que devem ser aplicadas à sessão como um todo e a todos os fluxos de mídia. ou mais descrições do nível de mídia: informações que devem ser aplicadas a um fluxo de mídia específico.

\\Zero

\\Detalha

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 campo v o s i u e p c b Valor do campo Versão do protocolo Originador ou criador da sessão e identificador da sessão Nome da sessão Informação sobre a sessão URI da descrição Endereço de e-mail Número do telefone Informação sobre a conexão Informação sobre largura de banda Presença obrigatória Sim Sim Sim Não Não Não Não Não Não Sim Não Não

Uma ou mais descrições de horário Tabela 2.5 Descrição da sessão z k Ajustes do time zone Chave de encriptação

Capítulo 2 – Protocolo SIP 73

Introdução à Voz sobre IP e Asterisk

Tipo do campo a

Valor do campo Zero ou mais linhas de atributo da sessão

Presença obrigatória Não Não

Zero ou mais descrições de mídia

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. Tipo do campo t r Tipo do campo m i c b k a Valor do campo Horário em que a sessão está ativa Zero ou mais horários repetidos Valor do campo Nome da mídia e endereço de transporte Título da mídia Informação sobre a conexão Informação sobre a largura de banda Chave de encriptação Zero ou mais linhas de atributo da mídia Presença obrigatória Sim Não Presença obrigatória Sim Não Não Não Não Não Tabela 2.7 Descrição da mídia Tabela 2.6 Descrição do horário

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

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 \\o \\s \\u \\c \\t

– versão; – originador, ID sessão, versão, tipo de rede, tipo de endereço, endereço; – nome da sessão; – URI de descrição; – informação sobre a conexão;

– 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); – outros atributos sobre mídia, tais como modulação, portas UDP e codec.

\\a

Modos de comunicação SIP
\\Existem

dois modos de comunicação: direto: que um agente SIP envie requisições para outro agente.

\\Modo

\\Peer-to-peer; \\Permite \\Modo

indireto: servidor proxy;

\\Via

\\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;

Capítulo 2 – Protocolo SIP 75

Exemplo de Sessão SDP

Introdução à Voz sobre IP e Asterisk

\\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 1. Invite 2. 180 Ringing 3. 200 OK 4. ACK 5. Voz ( RTP ) 6. Bye 7. 200 OK Comunicação peer-to-peer Agente B

Figura 2.7

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

INVITE sip: claudio@ rnp.br SIP/2.0 Via:SIP/2.0/UDP proxy. pop-rj.rnp.br; branch=4 Via:SIP/2.0/UDP proxy. pop-rj.rnp.br; branch=2 Via:SIP/2.0/UDP proxy. unb.br From:Daniel <sip:daniel@unb.br> To:Claudio <sip:claudio@rnp.br> Call-ID:12345@proxy. unb.br Cseq:2 INVITE Subject: Projeto fone@ RNP Contact: <sip:daniel@ proxy.unb.br> Record-Route: <sip:claudio@proxy. pop-rj.rnp. br;maddr=10.0.0.1>, <sip:claudio@proxy. pop-df.rnp.br; maddr=10.0.0.1> ...

SIP/2.0 100 Trying Via:SIP/2.0/UDP proxy. pop-rj.rnp.br; branch=4 Via:SIP/2.0/UDP proxy. pop-rj.rnp.br; branch=2 Via:SIP/2.0/UDP proxy. unb.br From:Daniel <sip:daniel@unb.br> To:Claudio <sip:claudio@rnp.br> Call-ID:12345@proxy. unb.br Cseq:2 INVITE Subject: Projeto fone@ RNP Contact: <sip:daniel@ proxy.unb.br> Record-Route: <sip:claudio@proxy. pop-rj.rnp.br; maddr=10.0.0.1>, <sip:claudio@proxy. pop-df.rnp.br; maddr=10.0.0.1> ...

ACK sip:claudio@rnp.br SIP/2.0 Via: SIP/2.0/UDP Proxy.unb.br From: Daniel sip:daniel@unb.br Call-ID: 12345@proxy. unb.br Cseq: 2 INVITE Subjet: Projeto fone@RNP Contact: sip:daniel@ proxy.unb.br Route: <sip:claudio@ proxy.pop-df.rnp.br; maddr=10.0.0.1>, <sip:claudio@proxy. pop-rj.rnp.br> ...

Requisição INVITE recebida pelo agente servidor
\\INVITE \\Via

Conteúdo da resposta 100 Trying enviada pelo agente servidor

Conteúdo da requisição ACK enviada pelo agente cliente

SIP – destino, versão 2.0.;

– 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; – campo utilizado para identificar a transação, inserido pela rede;

\\Branch=4

\\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; – utilizado para comunicação multicast;

\\Maddr \\SIP

2.0 Trying – mensagem informativa e provisória em resposta ao INVITE. Equivalente à chamada em progresso; parâmetros são similares ao INVITE;

\\Outros

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.

Capítulo 2 – Protocolo SIP 77

Comunicação via proxy

Introdução à Voz sobre IP e Asterisk

Transações e diálogos SIP
\\SIP

Transactions: de mensagens trocada entre os elementos de uma rede SIP; zero ou mais respostas provisórias e uma ou mais respostas finais; de: requisição; respostas para a requisição feita.

\\Sequência \\Inclui

\\Consiste \\Uma

\\Várias \\Entidades \\SIP

com noção de transações são chamadas de stateful;

Dialogs: de transações; uma relação SIP P2P (peer-to-peer) entre dois user agents;

\\Sequência

\\Representa \\Facilita \\São

o sequenciamento e o roteamento das mensagens entre os terminais SIP; identificados por Call-ID, From tag, To tag; esses campos com o mesmo valor quando pertencem ao mesmo

\\Possuem

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

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: Invitation; Termination; Messages.

\\Registration; \\Session \\Session \\Instant

\\Registration

– processo em que um User Agent (UA) se registra via rede em um proxy de registro;

Capítulo 2 – Protocolo SIP 79

Exemplo:

Introdução à Voz sobre IP e Asterisk

\\Session

Invitation – usuário Agente Cliente (UAC) solicita o estabelecimento de uma sessão a um Usuário Agente Servidor (UAS); Termination – término da sessão por iniciativa do UAS ou UAC, por temporização, destino não acessível, congestionamento na rede etc.; Messages – durante uma sessão, UAC e UAS podem enviar mensagens sem encerrar a sessão.

\\Session

\\Instant

SIP Registration
\\Tem \\Se

a finalidade de registrar um user agent;

não houver registro, usuários com intenção de se comunicar não poderão se comunicar; registro compreende: REGISTER enviada pelo user agent;

\\Um

\\Mensagem \\Mensagem \\Mensagem

200 OK enviada pelo servidor de registro, se o registro for bem-sucedido; 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

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 From: < sip:claudio@bsb.com.br> To: < sip:claudio@bsb.com.br> Call-ID: 12345@cxo.bsb.com.br Cseq : 1 REGISTER Contact: < sip:claudio@cxo.bsb.com.br> Expire: 3600 Content-Length: 0

1. Register 2. 100 Trying 3. Register 4. 200 OK 5. 200 OK

Figura 2.9 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 \\O

em uma requisição INVITE, geralmente enviada ao proxy;

proxy imediatamente envia uma resposta com a mensagem 100 Trying; acabar com as retransmissões;

\\Finalidade: \\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 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 Chamado

Figura 2.10
81

Capítulo 2 – Protocolo SIP

Exemplo:

Introdução à Voz sobre IP e Asterisk

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; dois tipos de término de sessão:

\\Possui

\\Direta; \\Envia

uma requisição BYE para o outro UA envolvido, e este responde com uma mensagem 200 OK. proxy.

\\Via

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

UA1 1. BYE Forma direta

SIP proxy

UA2

2. 200 OK

1. Bye 2. Bye

Figura 2.11

Forma indireta 4. 200 OK

3. 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; deste tipo não estabelecem diálogos;

\\Mensagens \\O

texto da IM é transportado no corpo (body) da requisição SIP .

UA1

SIP proxy 1. Message 3. 200 OK 4. 200 OK 6. Message 5. Message 2. Message

UA2

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.

Capítulo 2 – Protocolo SIP 83

Exemplo:

Introdução à Voz sobre IP e Asterisk

84

2
Roteiro de Atividades
Tópicos e conceitos
\\Instalação \\Análise

do servidor OpenSER.

do tráfego de pacotes SIP na rede utilizando uma ferramenta de captura de tráfego.

Competências técnicas desenvolvidas
\\Capacidade

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

Tempo previsto para as atividades
\\1

hora a 1h30 minutos (trabalho em grupo).

Preparando o ambiente
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

Introdução à Voz sobre IP e Asterisk

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

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?

Capítulo 2 – Protocolo SIP 87

Atividade 2 – Captura e identificação da troca de mensagens entre os clientes SIP e o OpenSER

Introdução à Voz sobre IP e Asterisk

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

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?

Capítulo 2 – Protocolo SIP 89

Atividade 3 – Captura e identificação da troca de mensagens entre os clientes SIP

Introdução à Voz sobre IP e Asterisk

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?

Capítulo 2 – Protocolo SIP 91

92

3
Recomendação H.323

Sumário
Introdução à recomendação H.323 . . . . . . . . . . . Componentes da arquitetura H.323 . . . . . . . . . . . Pilha de protocolos H.323 . . . . . . . . . . . . . . Fluxos de controle e sinalização . . . . . . . . . . . . Recomendação H.225.0 . . . . . . . . . . . . . . . Mensagens RAS . . . . . . . . . . . . . . . . . . Controle de mídia . . . . . . . . . . . . . . . . . Modos de operação . . . . . . . . . . . . . . . . Estabelecimento de chamadas . . . . . . . . . . . . Chamada direta entre pontos finais . . . . . . . . . . . Chamada entre pontos finais registrados no mesmo gatekeeper . Chamada entre pontos finais em que somente um é registrado em Chamada entre pontos finais registrados em gatekeepers distintos Estabelecimento de canal de controle H.245 . . . . . . . . Uso dos serviços da chamada . . . . . . . . . . . . . Recomendações H.235 . . . . . . . . . . . . . . . Recomendação H.460 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . gatekeeper . . . . . . . . . . . . . . . . . . . . . 94 . 96 . 98 . 99 . 99 . 101 . 103 . 105 . 106 . 107 . 108 . 110 . 113 . 115 . 116 . 117 . 118

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 119 Atividade 1– Instalando o GnuGK . . . . . . . . . . . . . . . . . 119 Atividade 2 – Analisando a captura feita pelo Wireshark . . . . . . . . 124

93

Introdução à Voz sobre IP e Asterisk

Introdução à recomendação H.323
\\H.323

é uma série de recomendações produzidas pelo ITU-T para sistemas de conferência audiovisual; recomendações são projetadas para: interoperabilidade entre elas; que usuários de sistemas de conferências possam se comunicar e usar diferentes tecnologias de rede. recomendações: para conferências sobre RDSI-FL; para conferências sobre RDSI-FE; para conferências sobre LANs que proveem garantias de QoS; para conferências sobre RTPC. ponto-a-ponto e multiponto: H.323 podem ser estabelecidas entre dois ou mais usuários.
\\Permitir

\\As

\\Possibilitar

\\Outras

\\H.310, \\H.320, \\H.322, \\H.324, \\Provê

suporte a:

\\Conferências

\\Chamadas

\\Heterogeneidade: \\Um

equipamento em um sistema H.323 deve dar suporte obrigatório à comunicação de áudio. e gerência: H.323 podem ser bloqueadas com base no número de chamadas já estabelecidas, limitações na banda ou restrições de tempo.

\\Contabilidade \\Chamadas

\\Provê

suporte a: à autenticação de usuários e para a privacidade e não-repúdio de dados trocados entre eles. suplementares; a elaboração e o desenvolvimento de serviços adicionais.

\\Segurança: \\Suporte \\Serviços \\Permite

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 \\V.2

– provisória, possuía muitas deficiências e não foi implementada;

– melhoramento da V.1, introduzia as facilidades Fast Connect, Tunelamento e Overlap; – permitia escolha de língua, serviços suplementares até 450.7;

\\V.3 \\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; – tunelamento DSS-1, Série 460.x (portabilidade, status do enlace etc.);

\\V.5

94

A última versão do protocolo H.323 (V.6), de junho de 2006, administra:
\\Registro

de usuários; de destinos em endereços URI, IPv4, IPv6 ou telefônicos via gateway;

\\Localização \\Largura

de banda e escolha de codecs; de chamadas, conexão e desconexão; multimídia centralizadas e descentralizadas;

\\Controle

\\Conferências \\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 \\Chaves

de algoritmos;

de autenticação; de mensagens.

\\Autenticação

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 \\450.3

(Call Transfer) – transferência de chamadas; (Call Diversion) – desvio de chamada;

Capítulo 3 – Recomendação H.323 95

\\V.6

– as versões anteriores só permitiam codec ITU que necessitavam de licença. A nova versão permitiu codecs de fonte aberta, tais como iLBC e GSM.

Introdução à Voz sobre IP e Asterisk

\\450.4 \\450.5 \\450.6 \\450.7 \\450.8 \\450.9

(Call Hold) – retenção de chamada; (Call Park e Call Pickup) – retenção e retomada; (Call Waiting) – chamada em espera; (Message Call Waiting) – mensagem de chamada em espera; (Call Completion) – procedimentos no caso de ocupado;

(Display) – também conhecido por bina, permite exibir no telefone de destino o número do chamador; (Call Intrusion) – intrusão na chamada.

\\450.10

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. (GK): utilizado para controlar acesso às redes de comunicação.

\\Gatekeeper

\\Normalmente \\Multipoint \\Realiza

Control Unit (MCU):

as funções de controle e autorização de novos participantes para conferências.

Intranet/Intranet

ISDN H.320

H.323 Terminal H.323 Gatekeeper H.323 MCU H.323 Gateway H.323 Terminal Internet/Intranet SIP
ATM H.310. H.321 PSTN H.324

Figura 3.1

O gatekeeper (GK) é responsável por:
\\Resolução

de nomes; do destino, já que possui o banco de endereços dos seus usuários;

\\Identificação

96

\\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 Uma zona é uma região H.323 formada pelo conjunto de terminais, gateways e MCUs controlados por um único gatekeeper. Uma zona pode abranger redes distintas.

Todos os usuários de uma zona devem ser registrados no GK que a controla. No caso de necessidade de controle da chamada, o GK pode solicitar, durante o processo RAS, que todas as mensagens Q.931 e H.245 utilizadas para o estabelecimento da chamada sejam feitas através dele. Tal processo é realizado com o GK enviando para o telefone ou gateway de origem o seu próprio endereço e porta, com destino. A mensagem recebida é encaminhada pelo GK para o destino, que pode ser outro GK ou o telefone de destino, a depender da negociação durante o processo RAS (Registro, Admissão e Status). O controle de admissão de chamadas é feito através do protocolo H.225 RAS. A gerência da banda é feita através das 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.

Capítulo 3 – Recomendação H.323 97

\\Realização

de controle de chamadas;

Introdução à Voz sobre IP e Asterisk

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; 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. Descrição Transporte de dados (texto, imagem, fax, sinais de modem)

\\O

Padrões T.38 T.120 V.150.1 RTP RTCP (IETF) H.245 H.225.0 H.246 H.248 H.235 H.450.x H.460.x H.501 H.510 H.530

Transporte de áudio e vídeo Protocolos de controle e sinalização Interoperabilidade com redes telefônicas comutadas por circuitos Segurança em sistemas baseados no protocolo de controle H.245 Serviços suplementares Extensões aos serviços de sinalização do protocolo H.255.0 Gerência e segurança de usuários, terminais e serviços em ambientes móveis 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: (ITU T.120); para intercâmbio de dados (textos e imagens estáticas);

\\T.120

\\Padrão

\\Depende

de um conjunto de outros padrões e recomendações: T.122, T.124, T.125, T.126 e T.127. e vídeo: RTP e RTCP .

\\Áudio

\\Protocolos

98

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: RAS;

\\H.225.0; \\H.225.0 \\H.245. \\O

protocolo H.225.0 é utilizado para o estabelecimento de chamada entre dois dispositivos H.323. protocolo H.225.0 RAS é utilizado com um gatekeeper para controle de admissão e resolução de endereços. protocolo H.245, por sua vez, é utilizado para controlar a comunicação entre os dispositivos. padrão H.225.0 RAS utiliza a porta TCP 1718 para conexões multicast e a porta TCP 1719 para conexões unicast. padrão H.225 Q.931 utiliza a porta TCP 1920. padrão H.245 utiliza portas TCP dinâmicas.

\\O

\\O

\\O

\\O \\O

Recomendação H.225.0
\\Sinalização \\H.323 \\O

de chamadas:

utiliza o protocolo H.225.0 para a sinalização das chamadas;

protocolo H.225.0 utiliza um subconjunto das mensagens definidas nas recomendações:
\\Q.931; \\Q.932.

\\Mensagens

de sinalização H.225.0: de chamadas:

\\Estabelecimento \\Setup;

\\CallProceeding; \\Alerting; \\Progress;

Capítulo 3 – Recomendação H.323 99

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.

Introdução à Voz sobre IP e Asterisk

\\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; proceding (O) – mensagem enviada pelo destino informando que todos os dados relativos à chamada foram recebidos e nenhuma informação adicional será aceita; (O) – mensagem enviada pela origem com informações complementares, por exemplo, para envio de dígitos por OverLap após a mensagem Setup; (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; (M) – mensagem enviada pelo destino informando que a chamada foi aceita pelo usuário chamado; Complete (M) – mensagem enviada pela origem ou pelo destino informando que a chamada foi desconectada e que o canal está livre; (M) – mensagem enviada em ambas as direções para relatar condições de erro;

\\Call

\\Information

\\Alerting

\\Connect

\\Release

\\Status \\Notify

(O) – mensagem enviada em ambos os sentidos com informações sobre uma chamada, tal como usuário suspenso; (O) – mensagem enviada para a origem para indicar inter-funcionamento;

\\Progress \\Facility

(M) – utilizada para serviços suplementares, tal como redirecionamento de uma chamada.

Tipos de mensagens:
\\M \\O

(mandatório); (Opcional); restantes (F) não são utilizadas no H.323.

\\Mensagens

O protocolo Q.932 provê mensagens para suporte aos serviços suplementares:
\\Facility \\Hold

– mensagem utilizada para requisitar uma facilidade de serviço suplementar;

(Ack/Rej) – facilidade de retenção;

100

\\Register \\Notify

(Ack/Rej) – registro de um evento;

(Ack/Rej) – notificação de evento.

Mensagens RAS
\\Registro, \\As

Admissão e Status;

funções de RAS (Registration Admission Status) incluem: de gatekeepers; de pontos finais; de pontos finais; de banda e notificação de estado.

\\Descoberta \\Registro

\\Localização \\Gerência \\Mensagens

H.225.0 RAS: (GatekeeperReQuest); (GatekeeperConFirm); (GatekeeperReJect). (RegistrationReQuest); (RegistrationConfirm); (RegistrationReJect); (UnRegistrationReQuest); (UnRegistrationConfirm); (UnRegistrationReJect). H.225.0 RAS: (LocationReQuest); (LocationConFirm); (LocationReJect). de admissão: (AdmissionReQuest); (AdmissionConfirm); (AdmissionReject). de banda: (BandwidthReQuest); (BandwidthConfirm); (BandwidthReject).

\\Descoberta: \\GRQ \\GCF \\GRJ

\\Registro: \\RRQ \\RCF \\RRJ \\URQ \\UCF \\URJ \\Mensagens

\\Localização: \\LRQ \\LCF \\LRJ

\\Controle \\ARQ \\ACF \\ARJ

\\Alteração \\BRQ \\BCF \\BRJ

101

Capítulo 3 – Recomendação H.323

\\Retrieve

(Ack/Rej) – facilidade de recuperação;

Introdução à Voz sobre IP e Asterisk

\\Mensagens \\Informação \\IRQ \\IRR

H.225.0 RAS; de estado: (InfoReQuest);

(InfoReQuestResponse); (InfoReQuestAck); (InfoReQuestNak). (DisengageReQuest); (DisengageConfirm); (DisengageReject).

\\IACK \\INAK

\\Desengajamento: \\DRQ \\DCF \\DRJ

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

\\GW

\\Location

\\Call

102

Controle de mídia
\\Sistemas

H.323 usam mensagens de controle de mídia definidas na recomendação H.245; recomendação H.245 define as seguintes funções: de capacidades; e encerramento de canais lógicos; de mestre e escravo;

\\A

\\Troca

\\Estabelecimento \\Determinação \\Notificações. \\Mensagens

de controle H.245: mestre e escravo:

\\Determinação

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

Capítulo 3 – Recomendação H.323

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.

Introdução à Voz sobre IP e Asterisk

\\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; de retardo.

\\Determinação

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

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; – informações sobre terminais e canais de mídia, porta, banda, codecs, criptografia, entre outras; – encerramento da conexão e liberação dos terminais;

\\TerminalCapabilitySet

\\EndSessionCommand \\Sinalização

dos canais lógicos; – abertura do canal, porta UDP tipo de mídia; ,

\\LogicalChannelOpen \\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: da chamada do canal H.245 da conexão entre os canais lógicos dos serviços da chamada da chamada

\\Início

\\Controle

\\Estabelecimento \\Utilização

\\Encerramento

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

Capítulo 3 – Recomendação H.323

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.

Introdução à Voz sobre IP e Asterisk

Encerramento da chamada
As mensagens a seguir encerram a chamada:
\\Encerramento \\Comando

do canal lógico H.245 – mensagem CLC;

de fim de sessão H.245 – comando ESC; de liberação do canal de sinalização Q.931 – mensagem RLC; do GK RAS – mensagem DRQ.

\\Mensagem \\Atualização

Estabelecimento de chamadas
\\Chamada

entre pontos finais em que somente um é registrado em gatekeeper

Terminal 1
Setup

GK
Cellproceeding ARQ ACF/ARJ Alerting Connect

Terminal 2

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

Chamada direta entre pontos finais
Terminal 1
Setup Callproceeding Alerting Connect

Terminal 2

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

Capítulo 3 – Recomendação H.323

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.

Introdução à Voz sobre IP e Asterisk

Chamada entre pontos finais registrados no mesmo gatekeeper
\\Sinalização

direta

Terminal 1
ARQ ACF/ARJ Setup

GK

Terminal 2

Cellproceeding ARQ ACF/ARJ Alerting Connect

Mensagens de sinalização H.225.0

Mensagens de RAS

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

Terminal 1
ARQ ACF/ARJ Setup Cellproceeding

GK

Terminal 2

Setup Cellproceeding ARQ ACF/ARJ Alerting Connect

Alerting 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

Capítulo 3 – Recomendação H.323

Introdução à Voz sobre IP e Asterisk

Chamada entre pontos finais em que somente um é registrado em gatekeeper
\\Sinalização

direta com ponto final chamador registrado

Terminal 1
ARQ ACF/ARJ Setup

GK

Terminal 2

Cellproceeding Alerting Connect

Mensagens de sinalização H.225.0

Mensagens de RAS

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

Terminal 1
ARQ ACF/ARJ Setup Cellproceeding Alerting Connect

GK

Terminal 2

Setup Cellproceeding Alerting Connect

Mensagens de sinalização H.225.0

Mensagens de RAS

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

Capítulo 3 – Recomendação H.323

\\Sinalização

roteada pelo gatekeeper com ponto final chamador registrado

Introdução à Voz sobre IP e Asterisk

\\Sinalização

roteada pelo gatekeeper com ponto final chamado registrado

Terminal 1
Setup

GK
Cellproceeding ARQ ARJ Facility Release Complete Setup Cellproceeding Setup Cellproceeding ARQ Alerting Cellproceeding ACF/ARJ Alerting
Connect

Terminal 2

Mensagens de sinalização H.225.0

Mensagens de RAS

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

\\Sinalização

entre pontos finais registrados em gatekeepers distintos.

Terminal 1
ARQ ACF/ARJ

GK

GK

Terminal 2

Setup Callproceeding ARQ Facility ReleaseComplete ARJ

ARQ DRQ DCF ACF/ARJ Setup Callproceeding Setup Callproceeding ARQ ACF/ARJ Alerting Connect Alerting 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

Capítulo 3 – Recomendação H.323

Chamada entre pontos finais registrados em gatekeepers distintos

Introdução à Voz sobre IP e Asterisk

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
ARQ ACF Setup Callproceeding

GK
ARQ LCF Setup Callproceeding

GK

Terminal 2

Setup Callproceeding ARQ ACF Alerting

Alerting Connect

Alerting Connect

Connect

Mensagens de sinalização H.225.0

Mensagens de RAS

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

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

Figura 3.11

Chamada em uso

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

Capítulo 3 – Recomendação H.323

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;

Introdução à Voz sobre IP e Asterisk

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 MestreEscravo; 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 H.450.2 H.450.3 H.450.4 H.450.5 H.450.6 H.450.7 H.450.8 H.450.9 H.450.10 H.450.11

Arcabouço geral Transferência Redirecionamento Retenção Atendimento Chamada em espera Indicação de mensagem Identificação de chamador Notificação de encerramento Oferta de chamada Intrusão de chamada Tabela 3.2

116

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: serviços envolvem três aspectos principais: de pontos finais dos fluxos de informação dos fluxos

\\Os

\\Autenticação \\Privacidade \\Integridade

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 \\Fases

H.225.0 segura

de autenticação de capacidades criptográficas

\\Trocas \\Uso

de chaves criptográficas nos canais de mídia

117

Capítulo 3 – Recomendação H.323

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.

Introdução à Voz sobre IP e Asterisk

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 \\H.460.2 \\H.460.3 \\H.460.4 \\H.460.7 \\H.460.8 \\H.460.9

– arcabouço geral; – portabilidade de número; – informação de capacidade; – prioridade de chamada; – recursos de numeração; – consulta a rotas alternativas; – monitoração de QoS; – retardo de chamada; – indicação de controle de colisão de chamada; – liberação de chamada pelo ponto final chamado.

\\H.460.11 \\H.460.12 \\H.460.13

118

3
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade prática tem como objetivo instalar o servidor GnuGK e analisar o protocolo H.323.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\1

hora a 1h30 minutos (trabalho em grupo).

Requisitos
\\Esta

prática envolve atividades individuais e em grupo.

Preparando o ambiente
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

Introdução à Voz sobre IP e Asterisk

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

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

Capítulo 3 – Recomendação H.323

### Permite que o gatekeeper aceite chamadas dos seus vizinhos;

Introdução à Voz sobre IP e Asterisk

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

\\Verifique

Figura 3.14 Clique em OK.
\\No

menu Options/Gatekeeper;

Figura 3.15

122

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

Capítulo 3 – Recomendação H.323

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

Introdução à Voz sobre IP e Asterisk

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 . . . . . . Projeto Zapata . . . . . . . . . Asterisk . . . . . . . . . . . . Asterisk e Linux . . . . . . . . . Asterisk e a GNU General Public License Asterisk versus PABX . . . . . . . O que o Asterisk não é e não faz . . . Hardware e interfaces para Asterisk . . Zaptel Pseudo TDM interfaces . . . . Non-Zaptel hardware interfaces . . . Packet voice protocol . . . . . . . Protocolos usados pelo Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 . 126 . 128 . 129 . 131 . 131 . 134 . 136 . 136 . 137 . 138 . 140

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 147 Atividade 1 – Instalando o Asterisk . . . . . . . . . . . . . . . . 147 Atividade 2 – Configurando e testando os clientes X-Lite, Telefone IP e ATA . . 149

125

Introdução à Voz sobre IP e Asterisk

Apresentação do Asterisk
\\Digium: \\Criada

em 1999 e localizada em Huntsville, Alabama (EUA); e desenvolvedora primária do Asterisk; patrocinadora do Asterisk; em: de código-fonte; de telefonia a baixo custo.

\\Criadora \\Principal

\\Investimento

\\Desenvolvimento \\Hardware

A Digium, localizada em Huntsville, Alabama, é a criadora e desenvolvedora primária do Asterisk, o primeiro PABX de código aberto da indústria. Usado em conjunto com as placas de telefonia PCI, ele oferece uma abordagem estratégica com excelente relação custo/benefício para o transporte de voz e dados sobre arquiteturas TDM, comutadas e redes Ethernet. A Digium é hoje a principal patrocinadora do Asterisk e uma das líderes na indústria do PABX em código aberto, sendo Mark Spencer o criador e principal mantenedor do Asterisk. Na verdade, o Asterisk funciona como uma poderosa vitrine das placas de telefonia fabricadas pela Digium, que também investe em versões comerciais do Asterisk, serviços de consultoria e suporte profissional.

TDM A arquitetura TDM pode ser entendida como as redes digitais tradicionais de telefonia, que utilizam o TDM (Time Division Multiplexing) para transportar várias ligações em um mesmo enlace.

Projeto Zapata
\\Projeto

de hardware aberto (OpenSource); hardware para telefonia com interfaces E1 / T1;

\\Desenvolve \\As

placas são produzidas por diversas empresas:
\\Digium; \\Sangoma; \\Varion.

\\Exemplos:

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

Capítulo 4 – Asterisk

Introdução à Voz sobre IP e Asterisk

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; conectividade em tempo real entre redes PSTN e redes VoIP; PABX de código aberto do mercado: pela a Digium Inc.

\\Permite \\Primeiro

\\Criado

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

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; para plataforma Linux;

\\Desenvolvido \\Kernel

2.4 ou superior; para Solaris, FreeBSD e OpenBSD; de alteração de código de acordo com o cliente.

\\Portado

\\Possibilidade

Asterisk e Linux
\\Por

que utilizar o Linux? são soluções Open Source (Asterisk e Linux); para acesso a PSTN; toda a implementação do Asterisk é voltada para a plataforma Linux; duplo:
\\GPL; \\LGPL.

\\Ambos

\\Hardware

\\Licenciamento

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

Capítulo 4 – Asterisk

especializado e, principalmente, em hardware de telefonia de baixo custo, também aberto, que funciona com o Asterisk.

Introdução à Voz sobre IP e Asterisk

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 \\De

executar o programa para qualquer propósito (liberdade nº0);

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; redistribuir cópias de modo a ajudar o próximo (liberdade nº2);

\\De \\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

\\Existem

algumas formas para se contribuir com a evolução do Asterisk: de código; de bugs;

\\Desenvolvimento \\Conserto \\Relato \\Novas

de melhorias; aplicações; IRC e mailing list.

\\Documentação; \\Canal

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; há dificuldade para a adoção de novas funcionalidades:

\\Tradicionalmente \\Novas

funcionalidades significam novos custos; de instalação;

\\Dificuldades \\Em

geral implica a compra de novo hardware. do Asterisk em relação a PABXs: um leque superior de funcionalidades: serviços são adicionados ao código-fonte. funcionalidades não implicam a compra de novos equipamentos; de seu sistema de telefonia;

\\Vantagens \\Custo

mais atrativo;

\\Possui

\\Novos \\Novas

\\Controle

131

Capítulo 4 – Asterisk

Asterisk e a GNU General Public License

Introdução à Voz sobre IP e Asterisk

\\Ambiente \\Plano

de desenvolvimento fácil e rápido;

de discagem flexível e poderoso; aberto.

\\Código \\Funções \\Voice

básicas: mail (mensagem de voz por e-mail); em espera (mp3); (estacionamento de chamadas); de conferência; ID; de chamadas.

\\Música \\Salas

\\Parking \\Caller

\\Siga-me; \\Transferência

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

Funções do Asterisk
Algumas funções e serviços complementares suportados pelo Asterisk:
\\Identificador \\Siga-me; \\Transferência \\Pêndulo; \\Desvios

de chamada;

assistida ou cega;

baseados no chamador; eletrônica (com envio da mensagem por e-mail);

\\Secretária \\Música

em espera (configurável por contextos);

\\Conferência; \\Estacionamento \\Funções

de chamadas;

avançadas: Interativa por Voz (IVR);

\\Resposta \\Billing \\Queue \\Fax

(tarifação) utilizando o registro detalhado das chamadas (CDR); (filas de chamadas);

over IP; de conversas ou conferências;

\\Gravação \\Entrega \\Call

automática de chamadas (ACD);

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

Capítulo 4 – Asterisk

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.

Introdução à Voz sobre IP e Asterisk

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 \\SIP

comum de telefonia;

Proxy:

\\OpenSER. \\Gatekeeper \\GnuGK. \\Não

H.323:

executa nativo no Windows;

134

\\Todos \\Qualquer \\Não

os seus arquivos são configuráveis. alteração em um de seus arquivos terá efeito em todo o sistema:

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

Capítulo 4 – Asterisk

\\O

Asterisk possui como principal característica a flexibilidade:

Introdução à Voz sobre IP e Asterisk

Hardware e interfaces para Asterisk
\\Tecnologias \\O

suportadas:

Asterisk foi desenvolvido para permitir a adição de novas tecnologias e interfaces com facilidade; objetivo é suportar todo tipo possível de tecnologia de telefonia; geral, as interfaces podem ser divididas em três: hardware; hardware; voice.

\\Seu \\Em

\\Zaptel

\\Non-Zaptel \\Packet

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: uma variedade de interfaces de rede: POTS;

\\Para

\\PSTN, \\T1,

E1; PRA: Single Span T1 ou PRI connections; Quad Span T1 ou PRI connections.

\\PRI,

\\T100P \\T400P

136

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 \\Exemplo

a outros tipos de interfaces;

de hardware suportado pelo Asterisk para conexão a PSTN: – TDM400P .

\\Zaptel

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

Capítulo 4 – Asterisk

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.

Introdução à Voz sobre IP e Asterisk

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 IAX2 MGCP H323 Interface de rede (Ethernet ...) Placas de comunicação Linhas Digitais E1 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 \\AGI; \\EAGI; \\Dead \\Fast \\Os

padrão:

AGI;

AGI.

scripts são utilizados em lógica avançada.

\\AGI

permite também comunicação com bancos de dados relacionais:

138

\\MySQL: \\Acesso \\Scripts

a outros recursos externos.

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; AGI – permite acesso ao canal morto após um hangup*, tendo sido descontinuado após o Asterisk 1.6; 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.

\\Dead

\\Fast

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

Capítulo 4 – Asterisk

\\PostgreSQL;

Introdução à Voz sobre IP e Asterisk

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

CD

Ca R(

ll D

eta

e il R

cor

d)

CDRs

Asterisk

Dia

lpla

nC

ont

rol
Programa externo

C / C++ Java / .Net Python Bash [ ... ]

Figura 4.5 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: as conexões; o ponto de destino; questões relacionadas à sinalização de telefonia, como: de chamada;

\\Estabelecer \\Determinar \\Estabelecer

\\Indentificador \\Desconexão. \\IAX

e o Asterisk: aberto;

\\Protocolo \\Histórico:

\\Desenvolvido \\Protocolo

pela Digium com o propósito de comunicação com outros servidores Asterisk; de transporte;

140

\\Canais

de sinalização; de mídia.

\\Tansporte \\No

IAX, usuários são autenticados de três formas: text; hashing;

\\Plain \\MD5 \\RSA.

\\Facilidades \\Fornece \\Utiliza

do IAX: controle e transmissão de voz sobre redes IP;

qualquer tipo de mídia, como:

\\Voz; \\Vídeo. \\Características \\Derivado \\SIP; \\MGCP . \\Utiliza

do IAX:

da experiência dos protocolos:

o mesmo protocolo para sinalização e mídia em uma mesma porta do protocolo IAX: o uso de banda; de uso na presença de firewalls; de transmitir informações sobre plano de discagem. transparência à NAT;

UDP .
\\Objetivos

\\Minimizar \\Prover

\\Facilidade

\\Possibilidade

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

Capítulo 4 – Asterisk

\\Utiliza

porta UDP (4569):

Introdução à Voz sobre IP e Asterisk

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); (padrão definido pela ITU);

\\H.323 \\IAX

(Inter-Asterisk eXchange Protocol) v1 e v2; (Media Gateway Control Protocol);

\\MGCP \\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. (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.

\\RSA

142

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

Capítulo 4 – Asterisk

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.

Introdução à Voz sobre IP e Asterisk

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; vários tipos de frames: completo;

\\Existem

\\Frame

\\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 OSeqno ISeqno Frame Type C Subclasse

Figura 4.6 Frame completo 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

Figura 4.7 Miniframe do IAX

Número originador da chamada Dados

Timestamp

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 F Source Call Number R Destination Call Number Timestamp OSeqno ISeqno Tabela 4.1 Campos do frame completo do IAX Frame Type C Subclasse

Descrição Marcado para 1 indica que é um frame completo. Número de chamada originador do lado de transmissão. Marcado para 1 indica que o frame está sendo retransmitido e o valor de 0 para a transmissão inicial. Número de chamada de destino do lado receptor do frame. Timestamp completo, 32 bits. Número de sequência do fluxo de saída. Número de sequência do fluxo de entrada. Tipo de frame. Formato do valor da subclasse. Subclasse.

145

Capítulo 4 – Asterisk

Introdução à Voz sobre IP e Asterisk

Campo F Source Call Number Timestamp Dados

Descrição Marcado para 0 indica que é um frame incompleto Número de chamada originador do lado de transmissão do frame completo Timestamp completo, 16 bits. Dados Tabela 4.2 Campos do Miniframe do IAX

SIP Vantagens Largamente implementado pelas operadoras VoIP; Padrão de fato para a telefonia IP no momento. Problemas com NAT e FW.

IAX Uso eficiente da banda; Transparente a implementações de NAT; Simples e rápido.

H.323 Larga adoção pelo mercado; Padrão de videoconferência; Essencial na conectividade com projetos mais antigos. Arquitetura complexa Problemas com NAT e FW. Tabela 4.3 Comparativo entre IAX, SIP e H.323.

Desvantagens

Protocolo ainda pouco difundido, implementado em poucos dispositivos.

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

\\H.323

\\SIP

146

4
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade tem por objetivo instalar e configurar o Asterisk.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\1

hora a 1h30 minutos (trabalho individual).

Requisitos
\\Esta

prática envolve atividades individuais.

Preparando o ambiente
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

Introdução à Voz sobre IP e Asterisk

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

;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

Capítulo 4 – Asterisk

No fim do arquivo, adicione os novos ramais:

Introdução à Voz sobre IP e Asterisk

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 600 # Para maiores informações Para teste de eco (excelente para teste de atraso) Para retornar ao menu Tabela 4.4

150

5
Arquitetura do Asterisk

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

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 171 Atividade 1 – Configurando um novo ramal . . . . . . . . . . . . . 171

151

Introdução à Voz sobre IP e Asterisk

Arquitetura do Asterisk
\\O

Asterisk possui uma arquitetura simples, diferente da maioria dos produtos de telefonia; como um intermediador entre: de telefonia:
Internet e Telephony applications

\\Atua

\\Tecnologias \\IAX; \\SIP; \\H.323. \\Aplicações

Asterisk
da telefonia: de voz; de chamadas.
Internet e Telephony technologies

\\Conferência \\Secretária

eletrônica;

Figura 5.1

\\Estacionamento \\Limitações \\Usa

da arquitetura do Asterisk: muito dependente da performance da CPU;

a CPU do servidor para processar os canais de voz; acesso de alta prioridade frequente para a CPU.

\\Sistema \\Requer \\Canais

do Asterisk: lógicas para a trajetória das sinalizações e transmissões;

\\Conexões \\As

conexões podem ser: em software.

\\Físicas; \\Baseadas \\As \\Os

regras para os canais são definidas no plano de discagem.

canais têm vários tipos de formatos: físicos:
\\FXO \\FXS \\PRI \\BRI

\\Circuitos

– Foreign eXchange Office; – Foreign eXchange Station; – Primary Rate Interface; – Basic Rate Interface. em software: – Session Initiation Protocol; – Inter-Asterisk eXchange Protocol.

\\Baseados \\SIP \\IAX \\Canais

internos do Asterisk:

\\Agent; \\Local; \\TDMoE

– TDM over Ethernet.

152

Asterisk Application API Codec Translator

Application Laucher PBX Switching Core

Scheduler and I/O Manager

Dinamic Module Loader

Figura 5.2

Asterisk Channel API

Dynamic Module Loader
Módulo responsável por carregar e inicializar todos os drivers necessários, providos por:
\\Drivers

de canal (channel drivers); de arquivos (file formats); de chamadas gravadas (call detail records);

\\Formato \\Detalhe \\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.

Asterisk File Format API

Codec Translator API

153

Capítulo 5 – Arquitetura do Asterisk

Em essência, o Asterisk atua como um mediador, conectando as tecnologias de 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.

Introdução à Voz sobre IP e Asterisk

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; ao correio de voz;

\\Conectar-se \\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; (Foreing Exchange Station) – interfaces analógicas para ligação de ramais tradicionais; (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; (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;

\\FXS

\\PRI

\\BRI

154

\\IAX

(Inter Asterisk eXchange) – protocolo utilizado na telefonia IP proprietário , do Asterisk; – canal proxy de distribuição de chamadas em fila para atendentes, muito utilizado em implementações para centrais de atendimento; – utilizado na lógica de programação do Asterisk, faz loops com as chamadas dentro do plano de discagem, em contextos diferentes; – 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). Detalhe Um canal de agente ACD. Cliente de console do Linux, driver para placas de som (OSS ou ALSA). Um dos protocolos mais antigos de VoIP . O próprio protocolo do Asterisk. Outro protocolo de VoIP . Usados para linhas ISDN e não modem. Usado para broadcast de som. Canal de telefonia do Linux. Protocolo mais comum em VoIP . Um driver para o protocolo dos telefones IP da Cisco. Voz sobre Frame Relay. Linhas telefônicas para placas da Voicetronix. Para conectar telefones e linhas com placas da Digium. Também usado para TDMoE e para Asterisk ZPHFC (ISDN em modo NT).

\\Agent

\\Local

\\TDMoE

Canais Agent Console H.323 IAX e IAX2 MGCP Modem NBS Phone SIP Skinny VOFR Tabela 5.1 Canais que o Asterisk suporta VPB ZAP

Outros canais do Asterisk:
\\H.323 \\MGCP

– protocolo de voz sobre IP do ITU; – protocolo de voz sobre IP; – utilizado em linhas ISDN (Integraded Services Digital Network);

\\Modem \\NBS

– utilizado para broadcast de som; – utilizado para telefonia no Linux; – protocolo de voz sobre IP utilizado nos telefones da Cisco;

\\Phone \\Skinny \\VOFR

– voz sobre Frame Relay;

155

Capítulo 5 – Arquitetura do Asterisk

\\SIP

(Session Initiation Protocol) – protocolo utilizado na telefonia IP;

Introdução à Voz sobre IP e Asterisk

\\VPB \\ZAP

– canais de voz das placas Voicetronix;

– 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 \\A

dos conceitos de telefonia

maior parte das implementações de telefonia usa fios metálicos:

\\Tip; \\Ring. \\Loop

fechado: recebe o tom de discagem da central telefônica: do tipo loop-start; do tipo ground-start: utilizada na telefonia analógica.

\\Telefone

\\Sinalização \\Sinalização

\\Sinalização

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: de supervisão: (no gancho); (fora do gancho); de endereçamento; de informação.

\\Sinalização \\On-hook \\Off-hook \\Ringing

(tocando);

\\Sinalização \\Sinalização \\Ajustes

de tons deve ser realizado no arquivo indications.conf..

156

\\Sinalização

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

\\Sinalização

\\Sinalização

de informação – indica se o telefone chamado está ocupado, se o número marcado está errado etc. Podemos destacar os seguintes eventos: de discagem; de ocupado;

\\Tom

\\Sinal \\Tom

de retorno (ringback); (congestion);

\\Congestionamento \\Número \\Tom

inválido;

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

TIP

Telefone

RING Bateria

ON-Hook

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

Capítulo 5 – Arquitetura do Asterisk

De forma muito resumida pode-se dizer que:

Introdução à Voz sobre IP e Asterisk

Off-hook (fora do gancho)
Telefone inicia chamada

PBX

TIP corrente elétrica RING

Telefone

OFF-Hook

Bateria

Detector de corrente
O usuário que deseja fazer uma chamada telefônica deve passar para o estado offhook, 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.

Figura 5.4 Telefone inicia chamada

158

\\Teclado

de discagem altas e baixas para a central o número discado
1209 1336 1477 1633 697 770 852

\\Frequencias \\Indica

1 4 7

2 5 8 0

3 6 9 #

A B C D

Figura 5.5

941

*

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; de ocupado – tom intermitente, intercalado com 250ms de silêncio, indica que o destino está off-hook; – semelhante ao tom de ocupado, indica falta de recurso na rede para completar a chamada.

\\Sinal

\\Congestionamento

Outros sinais menos comuns:
\\Tom

de retorno; inválido;

\\Número \\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

Capítulo 5 – Arquitetura do Asterisk

Dual Tone Multi Frequency (DTMF)

Introdução à Voz sobre IP e Asterisk

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): analógicas;

\\Interfaces \\O

termo “Foreign eXchange” é aplicado para troncos; interfaces: (Foreign eXchange Office); (Foreign eXchange Station).

\\Duas

\\FXO \\FXS

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
\\FXO

Companhia telefônica

Figura 5.6

(Foreign eXchange Office): utilizada para comunicação com Central Office ou PABX; interfaces conectam um PABX a outro: pública.

\\Interface \\Estas

\\PABX: \\Rede

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

\\FXS

(Foreign eXchange Station): as conhecidas linhas residenciais padrão; para conectar dispositivos básicos:

\\São

\\Utilizadas

\\Telefones; \\Modem; \\Fax. \\Deve

prover: “ringing”; “off-hook”; chamadas em processo.

\\Voltagem; \\Gerar

\\Detectar \\Indicar

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: analógicas;

\\Interfaces \\E&M

“Ear (receive) and Mouth (transmit)”; em ligações entre PABXs ou entre Net-Net Switches; no mercado como tie-lines analógicas;

\\Usadas \\Não

estão disponíveis para o Asterisk; comunicação bidirecional.

\\Conhecidas \\Permitem

161

Capítulo 5 – Arquitetura do Asterisk

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

Introdução à Voz sobre IP e Asterisk

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 \\Loop

nos troncos: start;

start; start; (não serão abordados): Wink Start; Immediate Start; Delay Start.

\\Ground \\Kewl

\\Outros

\\E&M \\E&M \\E&M

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; ao telefone indicar os estados de:

\\Permite

\\On-hook; \\Off-hook. \\Indica

ao switch os estados de: ring.

\\Ring; \\No \\É

uma linha aberta; chamada entrante é sinalizada por 100 V “ring voltage”.

\\Uma

162

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 \\No

ao loop start;

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 \\Incorpora

o que o outro lado está fazendo; 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.

Channel B

PRI

Figura 5.7

D Channel

163

Capítulo 5 – Arquitetura do Asterisk

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.

Introdução à Voz sobre IP e Asterisk

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: sobre R2;

\\Vantagens \\Uso

Flexível possibilitando uso simultâneo de dados de voz; E1 com possibilidade de 30 canais de voz, conhecida como T123 com canais de voz +1;

\\Interface

30B+D;
\\Interface

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 \\Usada \\Utiliza \\R2

definida pela ITU-T;

principalmente na América Latina e na Ásia; CAS (Channel Associated Signaling): Digital Brasil: variações específicas para cada país.

\\Possui

164

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); arquivos estão em formato ASCII, divididos em seções: das seções entre [ ].

\\Os

\\Nomes \\Em

seguida aos pares de colchetes: separado por (=) ou (=>).

\\ Valor \\(

; ) 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

Capítulo 5 – Arquitetura do Asterisk

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.

Introdução à Voz sobre IP e Asterisk

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

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 : e scripts: astman astgenkey safe_asterisk

\\/etc/asterisk \\Executáveis

\\/usr/sbin/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

Capítulo 5 – Arquitetura do Asterisk

da opção1 para “int”. O objeto2 é criado com sua opção1 como “int” e sua opção2 permanecendo “adv”.

Introdução à Voz sobre IP e Asterisk

\\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 \\Cada

fundamentais do Asterisk;

aplicação executa uma ação específica no canal em questão: sons; dígitos; uma chamada.

\\Emitem \\Aceitam

\\Desligam \\No

CLI (Command Line Interface) é utilizado o comando show applications.

168

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 Answer ( ) AbsoluteTimeout( ) Background( ) Congestion ( ) Descrição Responde a um canal que está chamando. Define o limite de tempo de uma chamada em segundos. Reproduz o(s) arquivo(s) de áudio especificado(s) enquanto espera que o usuário comece a inserir um ramal. 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. Permite que você conecte todos os tipos de canal. Incondicionalmente desliga o canal atual. Toca um arquivo de som previamente gravado sobre um canal. Define uma variável global. As variáveis globais estão disponíveis para todos os canais. Deixa mensagens de voz em determinada caixa postal.

Dial( ) Hangup( ) Playback( ) SetGlobalVar ( ) Tabela 5.2 VoiceMail ( )

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

Capítulo 5 – Arquitetura do Asterisk

Aplicações

Introdução à Voz sobre IP e Asterisk

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 exten exten exten exten exten exten => => => => => => => 100,1,Answer() 100,2,Playback(welcome) 100,3,Playback(demo-echotest) 100,4,Echo() 100,5,Playback(demo-echodone) 100,6,Playback(vm-goodbye) 100,7,Hangup()

Plano de discagem para teste de eco
exten => 100,1,Answer()

Atende a chamada.
exten => 100,2,Playback(welcome)

A mensagem padrão welcome é reproduzida.
exten => 100,3,Playback(demo-echotest)

A mensagem padrão de eco demo teste é reproduzida.
exten => 100,4,Echo()

Executa a função de teste de eco. Para terminar tecle ‘#’.
exten => 100,5,Playback(demo-echodone)

Reproduz o que foi gravado no teste de eco anterior.
exten => 100,6,Playback(vm-goodbye)

Reproduz a mensagem padrão goodbye (voicemail).
exten => 100,7,Hangup()

Desconecta a chamada, liberando a linha.

170

5
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade tem por objetivo compreender e analisar os arquivos de configurações do Asterisk.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\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

Introdução à Voz sobre IP e Asterisk

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 ;RAMAL PARA O ATA [30XX] type=friend secret=voip Host=dynamic canreinvite=no
Dialplan O dialplan define o modo como o Asterisk PBX irá lidar com chamadas de entrada e de saída, e também contém todos os números de extensão. O dialplan é dividido em seções chamadas de contextos. Cada quadro é composto de mais de uma extensão. Extensão A extensão é o número de telefone, podendo ser composto de números, letras ou ambos. Qualquer prorrogação tem uma prioridade e uma aplicação. Com a ajuda de contextos é possível organizar o dialplan.

Salve o arquivo e reinicie o Asterisk executando o comando:
# /etc/init.d/asterisk restart

Tente efetuar chamadas de um softphone para o outro. A chamada não poderá ser completada porque ainda não definimos nenhuma regra de discagem. Passo 4: faça um backup do arquivo de configuração extensions.conf executando o comando:
# cp extensions.conf extensions.conf.bak

O arquivo extensions.conf é o mais importante arquivo de configuração no PBX Asterisk, contendo o dialplan e as extensões. Na maioria das distribuições ele fica localizado em /etc/asterisk. Abra o arquivo utilizando o comando:
# vi /etc/asterisk/extensions.conf

172

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() exten=>_20XX,1,Dial(SIP/${EXTEN},20,r) exten=>_20XX,2,Hangup() exten=>_30XX,1,Dial(SIP/${EXTEN},20,r) exten=>_30XX,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

Capítulo 5 – Arquitetura do Asterisk

Passo 5: neste passo iremos configurar o arquivo extensions.conf.

174

6
Plano de discagem

Sumário
O plano de discagem . Contextos . . . . . Extensões . . . . . Prioridades . . . . . Aplicações . . . . . extensions.conf . . . Variáveis . . . . . Variáveis predefinidas . Expressões . . . . . Operadores. . . . . Padrões de extensão . Aplicação Background() Aplicação Goto() . . . Aplicação Dial() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 . 176 . 178 . 179 . 179 . 180 . 181 . 183 . 183 . 184 . 185 . 186 . 186 . 187

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 189 Atividade Atividade Atividade Atividade 1 2 3 4 – – – – Primeiro plano de discagem . . . . . Configuração do plano de discagem com Tratamento de erros . . . . . . . Aperfeiçoamento do plano de discagem . . . . . Background e . . . . . . . . . . . . Goto . . . . . . . . . 190 . 191 . 191 . 192

175

Introdução à Voz sobre IP e Asterisk

O plano de discagem
\\O \\O

plano de discagem é a parte mais importante de um sistema Asterisk;

arquivo extensions.conf, localizado no diretório etc/asterisk, especifica o plano de discagem; plano de discagem é composto por quatro elementos:

\\O

\\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; de chamadas e os fatores sobre os quais as decisões serão

\\Roteamento

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. um contexto definindo um cabeçalho: seu nome entre colchetes [ ];

\\Especificamos \\Colocamos \\Exemplo:

\\[meu_contexto] \\Exemplo: \\[gerente] \\Dois

e [funcionário]

contextos com permissões diferentes.

176

\\Usamos

contextos para implementar um número importante de recursos, como: solicitar senha para certas extensões;

\\Autenticação: \\Segurança:

podemos evitar que determinados usuários tenham acesso a certas funções que são vetadas a outros; bloquear certas pessoas, por exemplo.

\\Privacidade:

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

Capítulo 6 – Plano de discagem

Introdução à Voz sobre IP e Asterisk

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; declaração de uma extensão possui o seguinte formato: número, prioridade, aplicação: ou nome da extensão;
\\Número

\\A

\\exten=>

\\Prioridade; \\Aplicação. \\As

extensões seguem a forma: nome, prioridade, aplicação()

\\exten=> \\Um

exemplo prático de uma extensão poderia ser: exemplo, o nome da extensão é 1001, a prioridade é 1 e a aplicação é answer.

\\exten=1001,1,Answer() \\Neste

\\A

extensão especial “s”: uma ligação entra em um contexto, sem estar destinada a uma extensão específica, ela é tratada automaticamente pela extensão “s”.

\\Quando

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; – extensão chamada após o desligamento; – extensão inválida; – extensão do Operador, usada para saída do voicemail ao pressionar 0 (zero); – start ou extensão de início em cada contexto; – extensão de timeout;

\\h \\i \\o \\s \\t

178

\\failed \\fax

– usado se uma chamada auto-dial falhar;

– usado para detecção de fax em canais zap; – usado conjuntamente com BackgroundDetect.

\\talk

Fonte: www.voip-info.org/wiki/view/Asterisk+standard+extensions

Prioridades
\\As

extensões podem ter vários passos; estes passos de prioridades;

\\Chamamos \\Exemplo \\exten \\exten \\A

de extensão que atende a uma chamada e em seguida a desliga: => 1001,1,Answer() => 1001,2,Hangup()

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:
exten => 1001,1,Answer() exten => 1001,2,Hangup()

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; de aplicações:

\\Exemplos

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

Capítulo 6 – Plano de discagem

\\T

– extensão chamada após o AbsoluteTimeout();

Introdução à Voz sobre IP e Asterisk

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; que encontramos no arquivo:

\\Seções

\\[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

\\Valores

de variáveis são obtidos com a seguinte sintaxe:

\\${nomedavariavel} \\Variáveis

podem ser:

\\Globais; \\De

ambiente; a um canal.

\\Associadas \\Variáveis \\São

globais: vez definidas, podem ser referenciadas a qualquer momento. de ambiente: para acessar as variáveis de ambiente do sistema operacional; fazer referência às variáveis de ambiente da seguinte forma:

configuradas na classe [globals] ou utilizando o comando SetGlobalVar;

\\Uma \\Variáveis

\\Servem

\\Podemos

\\${ENV(nomedavariavel)} \\Variáveis

de canal: com o comando Set(), antigo SetVar;

\\Configuradas \\Têm

um escopo local restrito ao canal em que foram criadas. São destruídas quando o canal é encerrado, para liberar memória; variáveis de canal são predefinidas e podem ser referenciadas no plano de discagem.

\\Algumas

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

Capítulo 6 – Plano de discagem

Variáveis

Introdução à Voz sobre IP e Asterisk

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

\\Exemplos

de variáveis de canal predefinidas: código de contabilização; horário em que a chamada foi atendida;

\\${ACCOUNTCODE}: \\${ANSWERDTIME}: \\${CALLERID}: \\${CHANNEL}: \\${CONTEXT}:

identificador da chamada; nome do canal atual; nome do contexto atual; nome de quem foi chamado; número de quem foi chamado;

\\${DIALEDPEERNAME}:

\\${DIALEDPEERNUMBER}: \\${DIALEDTIME}: \\${EXTEN}:

hora em que o número foi discado;

extensão atual (nome da extensão atual); prioridade atual.

\\${PRIORITY}:

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; expressão segue a seguinte sintaxe:

\\Uma

\\$[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

Capítulo 6 – Plano de discagem

Variáveis predefinidas

Introdução à Voz sobre IP e Asterisk

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

\\Os

seguintes caracteres são exemplos de padrões: – dígitos de 0 até 9; – dígitos de 1 até 9; – dígitos de 2 até 9;

\\X \\Z \\N

\\[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 \\Código

de 8 dígitos + 2 de código de área;

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; o número de 8 dígitos é discado pelo tronco “meuTroncoSip”:

\\Apenas

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

Capítulo 6 – Plano de discagem

Padrões de extensão

Introdução à Voz sobre IP e Asterisk

Aplicação Background()
\\Uma

das peças chave para interação no Asterisk;

\\Diferentemente \\Porém,

da aplicação Playback(), a aplicação Background() reproduz um arquivo de áudio: 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()
\\Útil

para direcionar a ligação para diferentes extensões, prioridades e até mesmo contextos; programação do fluxo de uma ligação pelo plano de discagem;

\\Possibilita \\Sintaxe: \\Há

exten=> extensão, prioridade, Goto (contexto, extensão, prioridade);

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

\\www.voip-info.org/wiki/view/Asterisk+cmd+Goto \\www.voip-info.org/wiki/view/Asterisk+cmd+GotoIf

Aplicação Dial()
\\Utilizada \\A

literalmente para discar para algum destino:

aplicação Dial() é útil, pois permite que usuários que estejam usando métodos de comunicação distintos possam se comunicar. quatro argumentos:

\\Recebe

\\Destino; \\Timeout; \\Opções; \\URL

(pouco usual).

\\Exemplo: \\exten \\Disca

=> 123,1,Dial(Zap/1/33072022,10,r); para o número 3307 2022 no canal Zap/1; 10 segundos;

\\Espera \\Dá

o tom de chamada para quem está discando pela opção “r”; especificamos nenhum URL.

\\Não \\Outro

exemplo: => 123,1,Dial(SIP/1001,20,t); para o ramal SIP 1001; 20 segundos; transferência de chamadas com a opção “t”.

\\exten \\Disca

\\Espera

\\Permite \\Mais

um exemplo: => 123,1,Dial(SIP/1001,,rt); para o ramal SIP 1001;

\\exten \\Disca \\Não \\Dá

foi especificado o tempo de espera; foi especificado nenhum URL.

o tom de chamada para quem está discando pela opção “r”;

\\Não

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

Capítulo 6 – Plano de discagem

Mais informações:

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; – tempo durante o qual o canal deve ser chamado até desistir;

\\Timeout \\URL–

envia este URL para o dispositivo destino quando ele suporta, mas raramente é utilizado; – opções que adicionam funcionalidades ao comando Dial.

\\Options

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
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade tem por objetivo compreender e analisar os arquivos de configurações do Asterisk.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\1

hora a 1h30 minutos (trabalho individual).

Requisitos
\\Esta

prática envolve atividades individuais

Preparando o ambiente
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

Introdução à Voz sobre IP e Asterisk

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. fim do arquivo extensions.conf insira a seção [cursovoip]; os parâmetros das atividades deverão ser incluídos dentro desta seção.

\\No

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

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. Anote as linhas inseridas:

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. Anote as linhas inseridas:

Atividade 3 – Tratamento de erros
De acordo com o plano de discagem abaixo, faça as atividades propostas.
[cursovoip] exten => 9,1,Answer() exten => 9,2,Background(vm-enter-num-to-call) exten => 1001,1,Dial(SIP/1001,10,r) exten => 1001,2,Hangup() exten => 1002,1,Dial(SIP/1002,10,r) exten => 1002,2,Hangup()

191

Capítulo 6 – Plano de discagem

Anote as linhas inseridas:

Introdução à Voz sobre IP e Asterisk

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 . Estacionamento de chamadas Captura de chamadas . . . Música em espera . . . . Correio de voz (voicemail) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 . 194 . 196 . 196 . 197

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 199 Atividade Atividade Atividade Atividade Atividade 1 2 3 4 5 – – – – – Transferência de chamadas (Blind transfer) Estacionamento de chamadas . . . . . Captura de chamadas . . . . . . . Música em espera . . . . . . . . . Correio de voz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 . 200 . 201 . 202 . 202

193

Introdução à Voz sobre IP e Asterisk

Transferência de chamadas
\\A

transferência de chamadas é habilitada de forma bastante simples no Asterisk; transferência de chamadas pode ser feita de duas formas: cega (blind transfer); assistida.

\\ A

\\Transferência \\Transferência

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 \\Serve

muito útil e conhecida dos usuários de PABX convencionais;

para estacionar uma chamada enquanto o usuário se locomove de um terminal para outro; de configuração:

\\Parâmetros \\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

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

Capítulo 7 – Serviços complementares

Parâmetros de configuração

Introdução à Voz sobre IP e Asterisk

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; que tenhamos que levantar para atender ao telefone de outro colega.

\\ É

\\Evita

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; música em espera é controlada pelo arquivo musiconhold.conf; definir várias classes para organizar as músicas;

\\A

\\Podemos \\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

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; a aplicação VoiceMail() para direcionar ligações para o correio de voz; a aplicação VoiceMailMain() para acessar nossa caixa de correio.

\\Utilizamos \\Utilizamos

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

Capítulo 7 – Serviços complementares

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.

198

7
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade tem por objetivo explorar as funcionalidades do Asterisk.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\1

hora a 2h30 minutos (trabalho individual).

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

Introdução à Voz sobre IP e Asterisk

Passo 4: reinicie o serviço Asterisk:
# /etc/init.d/asterisk restart

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 5: reinicie o serviço Asterisk:
# /etc/init.d/asterisk restart

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

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 2: reinicie o serviço Asterisk:
# /etc/init.d/asterisk restart

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

Capítulo 7 – Serviços complementares

Anotações:

Introdução à Voz sobre IP e Asterisk

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. Passo 3: reinicie o serviço Asterisk:
# /etc/init.d/asterisk restart

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

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,2,Dial(SIP/${EXTEN},5,r) exten=>_10XX,3, VoiceMail(u${EXTEN}@default) exten=>_10XX,4,Hangup() 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

Capítulo 7 – Serviços complementares

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.

204

8
Distribuição de chamadas

Sumário
Discagem por diretório . . . . . . . . . . . . . . . . . . . . 206 Distribuição automática de chamadas . . . . . . . . . . . . . . . 207 Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 209 Atividade 1 – Discagem por diretório . . . . . . . . . . . . . . . 209 Atividade 2 – Distribuição automática de chamadas . . . . . . . . . . 210

205

Introdução à Voz sobre IP e Asterisk

Discagem por diretório
\\O

correio de voz fornece suporte para outra funcionalidade: a discagem por diretório; 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; serviço de discagem por diretório é fornecido pela aplicação Directory().

\\O

\\O

\\Default

se refere à seção do voicemail.conf, onde definimos as caixas de correio. é a seção do plano de discagem.

\\cursovoip

\\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 \\O

lista de nomes e ramais é declarada no arquivo voicemail.conf;

primeiro argumento vm-context define o contexto no qual os ramais devem ser interpretados; segundo argumento é usado para definir o plano de discagem.

\\O

Fluxo:
\\Toca \\O

o arquivo de introdução (dir-intro) e espera 5 segundos para os 3 dígitos;

arquivo de introdução toca a mensagem Please enter the first three letters of the persons last name...; é a última palavra encontrada no campo <name> em voicemail.conf;

\\Nome \\Toca

a mensagem em (dir-instr) com as instruções para conexão ao ramal desejado; 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; mais de um nome for encontrado, é possível escolher entre os nomes encontrados; nenhum nome for encontrado, a mensagem de introdução é repetida; “*” para sair; “1” para ir ao ramal desejado.

\\Também

\\Se \\Se

\\Pressione \\Pressione

206

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; autenticados como agentes atendem as chamadas; estratégia é usada para distribuir as chamadas.

\\Clientes \\Uma \\Agentes

são atendentes com ramais definidos no arquivo agents.conf, onde são definidas as filas de atendentes; agente pode pertencer a mais de uma fila:

\\Um

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

Capítulo 8 – Distribuição de chamadas

208

8
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade tem por objetivo explorar as funcionalidades do Asterisk.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\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:
# /etc/init.d/asterisk restart

Passo 3: teste o resultado ligando para a extensão. Anotações:

209

Introdução à Voz sobre IP e Asterisk

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 strategy= ringall maxlen = 0 member => Agent/300 member => Agent/301 ;classe da "music on hold" ;estratégia para distribuir as chamadas ;Comprimento máximo da fila (0 = infinito) ;Inclusão de um agente ;Inclusão de outro agente

Passo 3: edite o arquivo extensions.conf para configurar o acesso à fila no plano de discagem.
exten exten exten exten => => => => 0800,1,Answer ;atende chamadas para a fila 0800,2,Queue(fila) ;aciona a fila 6000,1,AgentCallbackLogin(||${CALLERIDNUM}@cursovoip) 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

Anotações:

211

Capítulo 8 – Distribuição de chamadas

Passo 5: utilizando outro softphone, disque para a fila 0800.

212

9
Unidade de Resposta Audível (URA)

Sumário
Hora do sistema . . . . . . . . . . . . . . . . . . . . . . . 214 Unidade de Resposta Audível (URA) . . . . . . . . . . . . . . . . 215 Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 219 Atividade 1 – Gerando mensagens personalizadas . . . . . . . . . . . 219 Atividade 2 – Criando plano de discagem para uma empresa de serviço VoIP . 220

213

Introdução à Voz sobre IP e Asterisk

Hora do sistema
\\Serviço

adicional – data e hora: pela função SayUnixTime();

\\Implementado

\\SayUnixTime([unixtime][|[timezone][|format]]): \\Unixtime \\Timezone \\Format \\Todos

– tempo em segundos desde 1° de janeiro de 1970;

– abreviação do timezone para data/hora; se vazio, utilizará os parâmetros do sistema; – formato em que data e hora serão reproduzidas. 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. os parâmetros são opcionais; se nada for informado, os parâmetros padrão serão utilizados. propósito desta aplicação de plano de discagem é informar data e hora em segundos, após 1° de janeiro de 1970. – 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. – 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. – formato em que data e hora são reproduzidos. Os formatos abreviados são:

\\Todos

\\O

\\Unixtime

\\Timezone

\\Format \\A \\B \\d \\Y \\I

ou a – dia da semana; ou b ou h – nome do mês; ou e – dia do mês numérico; – ano; ou i – hora, relógio em 12 horas; – hora, relógio em 24 horas; – hora, relógio em 24 horas; – minuto; ou p – AM ou PM; – today, yesterday ou ABdY; – for today, yesterday, weekday ou ABdY; – relógio em 24 horas, incluindo minutos; o valor padrão é ABdYIMp.

\\H \\k

\\M \\P \\Q \\q \\R

214

\\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 \\Data

– IMP: hora, minuto, AM/PM. – ABdY: dia da semana, nome do mês, dia do mês numérico, ano.

Unidade de Resposta Audível (URA)
\\Serviço \\ou

adicional – Interactive Voice Response (IVR):

Unidade de Resposta Audível (URA);

\\Recurso \\Muito

que permite detectar voz e tons utilizando uma chamada normal de telefonia; útil para permitir que o sistema de telefonia utilize a rede VoIP; 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

\\Também

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

Capítulo 9 – Unidade de Resposta Audível (URA)

Introdução à Voz sobre IP e Asterisk

\\Serviço

adicional – IVR: a extensão [IVR]:

\\Criar

[IVR] exten => 9999,1,Answer() 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)
\\Serviço \\Crie

adicional – IVR: 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.

\\

\\Serviço

adicional – IVR: um prompt de áudio:

\\Gravando \\Com \\A

o Asterisk é possível gravar as mensagens de áudio que serão utilizadas no menu do IVR; 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,Wait(2) exten => 100,n,Playback(/var/lib/asterisk/sounds/ minhaGravacao) exten => 100,n,NoOp(${PLAYBACKSTATUS}) exten => 100,n,Wait(1) exten => 100,n,Hangup()

216

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.

\\Serviço

adicional – IVR: um prompt de áudio:

\\Gravando \\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; falta encaminhar as mensagens de/para o Asterisk.

\\Agora

É 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

Capítulo 9 – Unidade de Resposta Audível (URA)

Gravando mensagens de áudio

Introdução à Voz sobre IP e Asterisk

218

9
Roteiro de Atividades
Tópicos e conceitos
\\A

atividade tem por objetivo explorar as funcionalidades do Asterisk.

Competências técnicas desenvolvidas
\\Ao

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

Tempo previsto para as atividades
\\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 aplicação Record() Record(filename:format,silence[,maxiduration][,options]) (no Asterix 1.0.X) Record(filename:format,silence[,maxiduration][,options]) (no Asterix 1.2.X) Opções Filename Format Silence Tabela 9.1 Maxduration Nome do arquivo que será gerado na gravação. Se o arquivo existir ele será substituído Especifica o tipo de formato que o arquivo será gravado. Os formatos válidos incluem: g723, g729, gsm, h263, ulaw, alaw, vox, wav. Especifica o tempo máximo de gravação em segundos de silêncio. Especifica o tempo máximo de gravação em segundos. este campo vazio ou com 0 (zero), implica a ausência de tempo máximo.
219

Introdução à Voz sobre IP e Asterisk

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

221

Capítulo 9 – Unidade de Resposta Audível (URA)

Anote o plano de discagem do grupo:

222

10
Qualidade de Serviço em VoIP

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

Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 253 Atividade 1 – Qualidade de Serviço (QoS) . . . . . . . . . . . . . . 253
223

Introdução à Voz sobre IP e Asterisk

Situação atual
\\A \\O

internet disponibiliza um serviço de melhor esforço; congestionamento da rede causa atrasos e perdas; há garantia de tempo de entrega; há garantia nas perdas;

\\Não \\Não

\\Novos

cenários de tráfego e aplicações necessitam de requisitos de perdas, retardo e taxa de transmissão; tecnologias, novas demandas: sobre IP (VoIP); à distância; interativa distribuída;

\\Novas \\Voz

\\Educação

\\Teleconferência; \\Simulação

\\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 \\Aplicações

de voz demandam pouca banda, mas não toleram alto atraso ou jitter.

de imagem podem exigir grande banda e não toleram alto atraso ou jitter, embora tolerem alguma perda. e dados nas redes de circuitos exigiam taxas de erro distintas e, em última instância, parâmetros de qualidade diferentes. 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.

\\Voz

\\Nas

224

\\A

rede de comunicação deve prover funções para QoS: funções atuam em diferentes fases do ciclo de vida de um serviço: de serviços; de contratos de serviços; dos contratos;

\\As

\\Solicitação

\\Estabelecimento \\Manutenção \\Término

do contrato. estáticos:

\\Mecanismos \\Ex.:

solicitação ao administrador de rede. dinâmicos:

\\Mecanismos \\Ex.:

uso de protocolos de sinalização. estáticos e dinâmicos demandam: de recursos; de tráfego; da QoS a ser aplicada.

\\Mecanismos \\Alocação

\\Caracterização \\Especificação

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

Capítulo 10 – Qualidade de Serviço em VoIP

Provisão de QoS

Introdução à Voz sobre IP e Asterisk

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 \\Medição

do serviço;

de atrasos; dos serviços.

\\Desempenho

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 \\Aplicação \\A \\Esse

entre a aplicação e a rede:

gera tráfego como especificado no contrato;

rede assegura o transporte dos fluxos com a QoS solicitada. 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

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 \\Para

de contratos de serviços;

garantir o SLA, é preciso orquestrar recursos de forma a: os recursos disponíveis; um controle de admissão; e escalonar pacotes.

\\Quantificar \\Prover

\\Classificar \\O

SLA pode ser configurado de forma:
\\Recursos

\\Estática:

reservados pelo administrador de rede.

227

Capítulo 10 – Qualidade de Serviço em VoIP

Esse tráfego fora da caracterização poderá ter pacotes perdidos ou atrasados, sem que a operadora tenha que indenizar o cliente.

Introdução à Voz sobre IP e Asterisk

\\Dinâmica: \\Efetuada \\Podendo

por um protocolo de sinalização; 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. BB disponibiliza: de solicitação e configuração de serviços; das decisões.

\\O

\\Interface

\\Comunicação

228

\\Exemplos

de BB: Open Policy Server (COPS) – RFC 2748; (RFC 3588).

\\Common \\Diameter

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

Capítulo 10 – Qualidade de Serviço em VoIP

Introdução à Voz sobre IP e Asterisk

Manutenção
\\A

manutenção garante que as aplicações não ultrapassem a cota de utilização dos recursos; de policiamento:

\\Necessidade \\A

rede deve reagir prontamente a degradações ocasionais. de componentes de rede: conversativo dos recursos.

\\Falhas

\\Dimensionamento \\Acionar \\Manter

funções de sintonização; o SLA contratado: recursos; subredes e roteadores alternativos. do SLA:

\\Realocar \\Escolher

\\Renegociação \\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

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 \\Metas \\SLA

inatingíveis nos prazos negociados; definidas pela tecnologia e não pelo negócio;

entendido pela organização como um overhead, e não como um diferencial competitivo; de SLM sem a devida senioridade/autoridade para negociar com as partes envolvidas (clientes e fornecedores); de SLA inadequados;

\\Equipe

\\Contratos \\As

diversas áreas envolvidas não perceberem que o acordo é um “construtor”, e não um “destruidor” de relacionamentos; de recursos (pessoas, processos e tecnologia); inadequada de metas e reportes.

\\Falta

\\Divulgação

Término do contrato
\\A \\A

aplicação informa à rede a intenção de finalizar o contrato; 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); modelos se adaptam de acordo com o tipo de aplicação e de arquitetura da rede:
\\Integrated

\\Esses

Services (IntServ); Services (DiffServ).

\\Differentiated

231

Capítulo 10 – Qualidade de Serviço em VoIP

Renegociação do SLA

Introdução à Voz sobre IP e Asterisk

\\IntServ: \\Utilizado

para designar um modelo de serviços que acrescenta ao serviço de melhor esforço oferecido na internet; de serviços com diferentes graus de comprometimento de recursos (banda e memória) e níveis (ou classes) de QoS; fluxo é identificado na arquitetura IntServ pela tupla IP Origem e Porta TCP ou UDP de origem. oferece, além do best effort, as seguintes categorias de serviços: garantidos: aplicações que necessitam de um atraso constante. de carga controlada:

\\Categorias \\Um

\\IntServ

\\Serviços \\Para \\Serviços \\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; implementação do IntServ é feita por quatro componentes: de sinalização (RSVP); de controle de admissão; de pacotes.

\\A

\\Protocolo \\Rotina

\\Classificador; \\Escalonador

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

Os dois serviços estão descritos em RFCs:
\\RFC \\RFC

2211 – Controlled-Load Network Element Service; 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; de políticas de controle.

\\Falta

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; – reconhece pacotes que necessitam de níveis específicos de QoS;

\\Classificação \\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; processo de sinalização ocorre antes da transmissão dos dados e é renovado sempre que necessário.

\\O

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

Capítulo 10 – Qualidade de Serviço em VoIP

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.

Introdução à Voz sobre IP e Asterisk

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; de recursos durante todo o tempo da conexão, exigindo alto desempenho da rede; o caminho é desfeito, é preciso se certificar de que todos os recursos sejam liberados, evitando comprometimentos desnecessários; de escala, pois conforme aumenta a quantidade de fluxos das aplicações, aumenta o consumo dos recursos, causando problemas aos backbones das grandes redes.

\\Comprometimento

\\Quando

\\Problema

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; componente é requisitado de forma que sua decisão não interfira nos fluxos previamente aceitos pelo roteador.

\\Este

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

\\Marca \\O

os pacotes para possibilitar a reserva de banda para determinado fluxo;

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 \\O

políticas de enfileiramento e prevenção de congestionamento;

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); Fair Queuing (WFQ); Queuing (PQ).

\\Weighted \\Priority

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
FIow 1 FIow 2 FIow 3 FIow 4 FIow 5 FIow 6 FIow 7 FIow 8

de diferentes fluxos são transmitidos na ordem em que são recebidos
5 2 4

FIFO Queue Multiplexer

6

6

5

4

3

2

1

Port

3 1

Figura 10.2

235

Capítulo 10 – Qualidade de Serviço em VoIP

Classificador

Introdução à Voz sobre IP e Asterisk

É 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

Incoming packets

Classify

Transmit queue

Outgoing packets

Weighted fair scheduling Configurable number of queues Queueing buffer resources Flow-based classification: Source and destination adress Protocol Session identifier (port/socket) Weight determined by: Required QoS (IP Precedence, RSVP) Flow throughput inversely proportional Frame Relay FECN, BECN, DE (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

\\O

roteador mantém várias filas com diferentes prioridades

High Incoming packets Mediun Classify Normal Low Length defined by queue limit Transmit queue Outgoing packets

Queueing buffer resources Classification by: Protocol (IP IPX, AppleTalk, , SNA, DECnet, bridge, and so on) Source interface (EO, SO, and so on) Interface hardware: Ethernet Frame Relay ATM Serial link (and others)

Figura 10.4

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 \\Inadequado \\Complexidade: \\Todos

de estado podem sobrecarregar os elementos centrais da rede; para redes de backbone.

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

Capítulo 10 – Qualidade de Serviço em VoIP

Escalonador PQ (Priority Queying)

Introdução à Voz sobre IP e Asterisk

obrigatoriamente implementar funções mais sofisticadas, trazendo maior necessidade de processamento, memória, upgrade de softwares e, consequentemente, maiores custos.

DiffServ
\\Differentiated

Service:

\\Introduzido \\Neste \\O

pelo Internet Engineering Task Force (IETF) para resolver os problemas encontrados com a implantação do IntServ; modelo, os pacotes são previamente marcados de acordo com os tipos de serviços desejados; DiffServ possibilita a criação de classes de serviços dentro de um domínio: ISP Teleco. ,
\\Ex.:

\\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; – checa se os parâmetros do tráfego estão de acordo e passa os resultados para o marcador e modelador; – escreve ou reescreve o campo DSCP;

\\Medidor

\\Marcador

\\Modelador

– atrasa ou descarta alguns pacotes para que o tráfego fique em conformidade com o projeto.

238

\\Formato

do datagrama IP

0 Version

4 HLen

8
Type of service

16 Flags Source IP address Destination IP address Options Data

19 Total lenght Fragment offset Header checksun

31

Identification Time to live Protocol

Padding

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

Capítulo 10 – Qualidade de Serviço em VoIP

DiffServ no pacote IP

Introdução à Voz sobre IP e Asterisk

DiffServ – DSCP
\\Valores

DSCP

PBH Default 000000 Low Drop Probability Assured Forwarding Classe 1 Classe 2 Classe 3 Classe 4 Expedited Forwarding 001010 – AF11 010010 – AF21 011010 – AF31 100010 – AF41 101110 – EF

DSCP

Precedência IP 0

Medium Drop Probability 001100 – AF12 010100 – AF22 011100 – AF32 100100 – AF42

High Drop Probability 001110 – AF13 010110 – AF23 011110 – AF33 100110 – AF43 1 2 3 4 5

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.

Tabela 10.1

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; PHB define o tratamento a ser dado ao pacote: dois principais PHBs definidos pelo IETF são: Expresso (Expedited Forwarding – EF); Assegurado (Assured Forwarding – AF).
\\Encaminhamento \\Encaminhamento

\\O

\\Os

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

Encaminhamento
\\Expresso

(EF – Express Forward): é diminuir o tempo de permanência nas filas dos pacotes em trânsito; prioridade nos pacotes com esta marcação em relação a qualquer outro; tempos de atraso e perdas de pacotes máximos aceitáveis. (AF – Assured Forward):

\\Objetivo \\Garante \\Garante \\Assegurado \\Fornece \\O

apenas uma expectativa de serviço quando a rede passa por momentos de congestionamento; 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; IntServ trata de fluxos, enquanto o DiffServ agrega os diversos fluxos em classes dentro de um domínio DS; da integração:

\\O

\\Vantagens

\\Possibilidade \\Melhor

de se implementar serviços de policiamento por fluxo e autenticação de usuários individuais; 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

Capítulo 10 – Qualidade de Serviço em VoIP

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.

Introdução à Voz sobre IP e Asterisk

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: roteamento é feito pacote a pacote, e dois pacotes com os mesmos destino e origem podem seguir rotas diferentes; 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. do MPLS: prover QoS; a carga nos roteadores.

\\O \\A

\\Vantagens

\\Permite \\Reduz

242

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 Costumer 2
MPLS Core
Label = 35
17

Label = 10

Label =

Costumer 2 Costumer 3

Costumer 1
L

e ab

l=

17

Costumer 1
0

Costumer 3
MPLS Edge

Costumer 2
Label = 17

MPLS 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); utilizado no núcleo da rede;

\\Normalmente \\O

pacote recebe um rótulo (label) ao entrar na rede MPLS; nas bordas e comutação no núcleo;

\\Roteamento \\Dentro

da rede o QoS contratado é atendido.

243

Capítulo 10 – Qualidade de Serviço em VoIP

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.

La be l= 20

Introdução à Voz sobre IP e Asterisk

Real-time Transport Protocol – RTP
\\Protocolo \\Áudio

que oferece funções de transporte de rede fim-a-fim: e vídeo interativos. versus Confiabilidade.

\\Desempenho

UDP Performance RTP

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: do tipo payload; sequencial; da entrega de dados:

\\Identificação \\Numeração \\Marcas

temporais (timestamping); interpolação.

\\Monitoração \\Permite \\Não

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

244

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

\\Formato \\Os

do pacote RTP:

doze primeiros octetos estão presentes em todos os pacotes de um fluxo de dados de uma sessão RTP;

0
V P X #CS

8
M PT

16
Timestamp Syncronization Source (SSRC) Countributing Source (CSRS) Header Extention

24
Sequence

32

Figura 10.9
\\V \\P \\X

Payload (áudio, vídeo etc)

(Version); (Padding); (Extention); (CSRC Counter); (Payload Type); Number; (Marker Bit);

\\CC \\M

\\PT

\\Sequence

\\Timestamp; \\SSRC \\CSRC

(Synchronization Source) Identifier; (Contributing Source) Identifiers.

\\V \\P

(Version) – versão do RTP;

(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; (Extention) – indica presença ou não de extensão de cabeçalho;

\\X

\\CC

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

245

Capítulo 10 – Qualidade de Serviço em VoIP

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.

Introdução à Voz sobre IP e Asterisk

\\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; (Payload Type) – indica o formato da carga do RTP e determina sua interpretação pela aplicação; Number – incrementado em cada pacote RTP e utilizado pelo receptor para detectar perda de pacote ou para restaurar a própria sequência; – utilizado pelo receptor para sincronização e cálculo do jitter;

\\PT

\\Sequence

\\Timestamp \\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; (Contributing Source) Identifiers – lista de identificadores CSRC inseridos por mixers. – versão: 2 (RFC 3550);

\\CSRC

\\V \\p

– padding = 1, se o pacote contém enchimento para completar múltiplos de 32 bytes; - 1, se houver extensão de cabeçalho;

\\x

\\PT

(payload type) – tipo de aplicação (codec), definido na RFC 1890 e 3551 (PT=200/RTCP); (CSRC COUNT) – número de fontes de mídia contribuintes;

\\cc \\m

(marker) – depende do PT (igual a 1), por exemplo quando houver supressão de silêncio; de sequência – de 0 a 65535, é inicializado aleatoriamente e incrementado de um, a cada pacote transmitido; – 32 bits, utilizado para calcular o jitter; source (SSRC) – identificador da fonte e sincronismo;

\\Número

\\Timestamp

\\Synchronization \\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 UDP IP Sessão RTP

RTCP UDP IP

RTP

Figura 10.10 Sessão RTP

246

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 \\Permite

que complementa o transporte de dados feito pelo RTP;

o monitoramento da entrega de dados de forma escalável em redes multicast; funcionalidades mínimas de controle e identificação;

\\Oferece

\\Baseado

na transmissão periódica de pacotes de controle para todos os participantes de uma sessão RTP; o mesmo mecanismo de distribuição definido para os pacotes que compõem os fluxos de dados das aplicações; 4 funções:

\\Utiliza

\\Desempenha \\Prover

informação a respeito da qualidade da distribuição dos dados de um fluxo; um identificador de nível de transporte persistente para um transmissor em uma sessão RTP: canônico (canonical name ou CNAME);
\\As

\\Transportar \\Nome

funções anteriores requerem que todos os participantes enviem pacotes periodicamente; informações mínimas de controle de sessão.

\\Transportar \\Informações \\Sender

geradas pelo RTPC: Report (RR);

Report (SR); Description (SDES);

\\Receiver \\Source \\BYE; \\APP .

247

Capítulo 10 – Qualidade de Serviço em VoIP

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.

Introdução à Voz sobre IP e Asterisk

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; Report (RR) – para estatísticas de recepção de participantes que não são transmissores ativos em uma sessão; Description (SDES) – itens que descrevem um transmissor em uma sessão, como o CNAME; – para indicar o fim da participação de uma aplicação em uma sessão; – para funções específicas da aplicação;
IC PT Length

\\Receiver

\\Source

\\BYE \\APP

V

P

Format-specific information

Padding if P = 1
V = Version number P = padding IC = item count PT = packet type Fonte: PERKINS, Colin. RTP: Audio and Video for the Internet. Boston: Addison Wesley, 2003.

Figura 10.11 Estrutura do RTCP .

248

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 Reporter SSRC Reportee SSRC 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)
First report block

Length

Figura 10.12 Pacote RR (Receiver Report)

Next receiver report block

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

Capítulo 10 – Qualidade de Serviço em VoIP

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

Introdução à Voz sobre IP e Asterisk

\\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; fraction – definido como a fração entre o número de pacotes perdidos no intervalo de reporte dividido pelo número esperado; number of packets lost – representa o número de pacotes esperado, subtraído o número de pacotes realmente recebidos; highest sequence number received – identifica os pacotes recebidos para possibilitar a identificação da perda de pacotes; jitter – estimativa do jitter dos pacotes;

\\Loss

\\Cumulative

\\Extended

\\Interarrival \\Timestamp

of last sender report received (LSR) – Timestamp NTP (Network Time Protocol) que identifica o tempo do mais recente pacote RTCP SR recebido; since last sender report received (DLSR) – é o delay entre o recebimento do último pacote SR e o envio do RR.
P RC PT=200 Reporter SSRC Length

\\Delay

V

NTP timestamp RTP timestamp Sender’s packet count Sender’s octet count Receiver report block

Figura 10.13 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; timestamp – corresponde ao tempo de envio do SR; timestamp – corresponde ao tempo de envio do último pacote RTP;

\\NTP \\RTP

\\Sender’s

packet count – número de pacotes de dados gerados pela fonte de sincronização na seção; octet count – número de octetos contido no payload dos pacotes de dados, incluindo os cabeçalhos e o padding;

\\Sender’s

250

V

P

RC

PT=202 SSRC / CSRC 1

Length

List of SDES items SSRC / CSRC 2

Figura 10.14 Pacote SDES (Source Description)
V = Version number P = padding SC = number of SDES items PT = packet type

List of SDES items

Figura 10.15 Pacote SDES - Item

Type

Length

Value (not null-terminated)

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 SSRC

Length = 10

Type = 1 (CNAME) p . 2 9 o

Length = 15 @ 7 . Type = 2 (NAME) l P

c 1 . 1 Length = 13 i e n 0

s 0 4 6
C

n r s 0

Figura 10.16 Exemplo de SDES

k Type = 0

i i

\\Type \\Type

1 (CNAME) – nome canônico, obtido para identificar os participantes;

2 (Name) – nome do participante, utilizado basicamente para listar o nome dos participantes na interface de usuário;
251

Capítulo 10 – Qualidade de Serviço em VoIP

\\Type \\Type \\Type

3 – e-mail do participante; 4 (Phone) – telefone do participante;

5 (LOC) – localização do participante (normalmente configurado pelo usuário em sua aplicação); 6 (TOOL) – indica a implementação utilizada pelo participante;

\\Type \\Type

7 (NOTE) – permite ao participante fazer uma breve nota informando qualquer mensagem arbitrária; 8 (PRIV items) – utilizado para especificar extensões privadas e para criar extensões experimentais ou específicas para determinadas aplicações.
P RC PR = 203 SSRC 1 SSRC 2 ... SSRC n Optional length Optional reason for leaving Lenght

\\Type

V

Figura 10.17 Pacote BYE

V = Version number P = padding RC = number of SSRC headers PT = packet type

V

P

Subtype

PR = 204 SSRC Application-defined packet name

Lenght

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
Roteiro de Atividades
Tópicos e conceitos
\\Conceitos

sobre QoS.

Competências técnicas desenvolvidas
\\Ao

final desta prática o aluno saberá solicitar QoS para o serviço VoIP que implementará.

Tempo previsto para as atividades
\\1

hora a 1h30 minutos (trabalho individual).

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

Introdução à Voz sobre IP e Asterisk

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

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

Capítulo 10 – Qualidade de Serviço em VoIP

7. Qual o objetivo do Multi Protocol Label Switching (MPLS)?

256

Bibliografia
\\ARMITAGE, \\BRANDL,

Grenville. Quality of Service in IP Networks. New Riders Publishing, 2000.

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. Sérgio; GOMES, Antônio Tadeu; OLIVEIRA, Anderson; GUIDO, L. E. VoIP: Voz sobre IP. Editora Campus/Elsevier, 2005. Barrie; GARRISON, Kerry. TrixBox Made Easy. Packt Publishing, 2006.

\\COLCHER,

\\DEMPSTER, \\GOMILLION,

David; DEMPSTER, Barrie. Building Telephony Systems with Asterisk. Packt Publishing, 2006. David; VEIBELL, Scott. Cisco IP Telephony. Cisco Press, 2004.

\\LOVELL,

\\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. Andrew S. Redes de computadores. Editora Campus, 2003.

\\TANENBAUM, \\TODD, \\ITU-T: \\RFC

John. Asterisk: A Bare-Bones VoIP Example. O’Reilly.

H.323 Packet-based multimedia communications systems.

– 3261 ITU – G.711

\\Recomendação \\Apostila

VoIP e Telefonia IP UFF 2009

257

Introdução à Voz sobre IP e Asterisk

\\www.voip.nce.ufrj.br.

Acessado em 22/11/2006, com informações retiradas sobre o serviço fone@RNP . Acessado em 20/08/2006, com informações retiradas sobre redes de computadores. Acessado em 12/04/2007, com informações retiradas sobre codecs.

\\www.babooforum.com.br.

\\www.maxrouter.com.

\\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. Acessado em 15/08/2006, com informações retiradas sobre a história da telefonia. Acessado em 15/08/2006, com informações Acessado em 22/08/2006, retiradas sobre redes de dados.

\\www.anatel.gov.br.

\\www.clubedohardware.com.br.

\\www.sobresites.com/telefonia/historiadotelefone.htm.

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. Acessado em 26/04/07, com informações retiradas sobre IAX.

\\www.cornfed.com/iax.pdf.

\\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. ITU – G.711

\\Recomendação

\\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 Devices: Analog Dialogue: Blackfin VoIP Acessado em 22/02/07. Disponível . em: www.analog.com/library/analogDialogue/archives/40-04/blackfin_voip.html Utilizado como fonte de fotos.

\\Analog

\\www.voip.nce.ufrj.br/courses/rnp/Interconexao_Gateways_parte_1_3tr.pdf.

\\Apostilas

do curso VoIP4All

\\www.voip-info.org

258

\\www.asterisk.org \\www.networksocerty.com/enp/protocol/sip.htm

259

Bibliografia

\\www.packetizer.com

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

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.