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


Mídias de Suporte à Colaboração Digital


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 [email protected]. 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 ADR4

40h

MID2

Interconexão de Redes de Computadores


40h

ADS2

40h

Administração de Sistemas Linux

ADR1

Arquitetura e Protocolos de Rede TCP-IP

ADS3

ADR6

Tecnologias de Redes Sem Fio

40h

Adm. Sistemas Linux: Redes e Segurança

40h

Adm. Sistemas Linux: Serviços para Internet

Segurança de Redes e Sistemas

ADR3

Virtualização de Servidores

Roteamento Avançado

40h

SEG6

Segurança em Redes Sem Fio

40h

40h

40h

ADR7 ADR5

IPv6 Básico 40h

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

SEG2

40h

ADS5 ADS4

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

40h

40h

SEG1

Gerência de Redes de Computadores 40h

GTI10

Planejamento e Projeto de Infraestrutura para Datacenter 40h

GTI6

i Bás

Gerenciamento de Projetos de TI

co GTI2

GTI1

Fundamentos de Governança de TI

Planejamento e Gestão Estratégica de TI

GTI8

Gestão da segurança da Segurança informação Informação

GTI3

16h

Inte

24h

NBR 27001 27001,eNBR27002 NBR 27002

40h

GTI9

Análise Forense

di rme

ário

Gerenciamento de Serviços de TI

GTI4

24h

NBR 27005

Tratamento de Incidentes de Segurança

24h

Governança de TI

Gestão de Riscos de TI

SEG4 SEG3

24h

nç Ava

40h

ado

GTI5

40h

GTI7

ITIL

Information Technology Infrastructure Library

COBIT

40h

16h

Control Objectives for Information and Related Technology

16h

SEG8

Engenharia Reversa de Código Malicioso 40h

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

Todos os cursos da ESR requerem inglês para leitura e noções de informática e Internet.

Legenda

Administração e projeto de redes

Conhecimento prévio recomendado Curso

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

\\Itálico

Quando em títulos e parágrafos de texto, indica estrangeirismos, comandos e suas opções, nomes de arquivos e referências a outras seções ou bibliografias. Quando em largura constante, denota os parâmetros que serão indicados pelo usuário. \\Texto

em azul Indica URLs acessíveis na internet ou no ambiente do laboratório. Podem ser endereços de páginas, locais de rede ou endereços eletrônicos.

\\Texto

em laranja Sempre que constar nos parágrafos de texto indica uma entrada de glossário, cuja definição deve ser vista na lateral do texto, próxima ao termo.

\\Largura constante

Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Quando utilizados para indicar comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\). A separação entre o que o usuário digita e o retorno do computador é indicada pelo caractere ↵ , em alusão à tecla Enter. Quando houver parâmetros opcionais em exemplos, estes podem entrar entre colchetes [ ].

vi

Parágrafo de texto com fundo laranja e ícone. Representa notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

\\

\\Parágrafo

de texto com fundo laranja fonte em branco

Utilizado para destacar os enunciados das atividades ao longo do capítulo.

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

vii

viii

u

Sumário

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

1

Capítulo 2 Protocolo SIP. . . . . . . . . . . . . . . . . . . . . . . . 49 Capítulo 3 Recomendação H.323. . . . . . . . . . . . . . . . . . . . . 93 Capítulo 4 Asterisk. . . . . . . . . . . . . . . . . . . . . . . . . . 125 Capítulo 5 Arquitetura do Asterisk . . . . . . . . . . . . . . . . . . . .

151

Capítulo 6 Plano de discagem. . . . . . . . . . . . . . . . . . . . . . 175 Capítulo 7 Serviços complementares. . . . . . . . . . . . . . . . . . . . 193 Capítulo 8 Distribuição de chamadas. . . . . . . . . . . . . . . . . . .

205

Capítulo 9 Unidade de Resposta Audível (URA). . . . . . . . . . . . . . . . 213 Capítulo 10 Qualidade de Serviço em VoIP. . . . . . . . . . . . . . . . . . 223 Bibliografia. . . . . . . . . . . . . . . . . . . . . . . . . 257

ix

x

1 Histórico e conceitos básicos ►►

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

1

Introdução à Voz sobre IP e Asterisk 2

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 e X-Lite. . . . . . Verificando codecs de áudio. . . . . . . . . . . . . . Conhecendo o Wireshark. . . . . . . . . . . . . . . Efetuando capturas com Wireshark . . . . . . . . . . . . Capturando pacotes na rede. . . . . . . . . . . . . .

34 34 36 37 39 39 43 44 46

\\Conceitos

básicos de rede:

\\Arquitetura \\Camadas

TCP/IP;

da arquitetura TCP/IP;

\\Transporte

dos pacotes;

\\Endereçamento \\Classes

IP;

de endereçamento;

\\Endereços

especiais;

\\Roteamento; \\Protocolo

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

Conceitos básicos de rede

de transporte.

A evolução das tecnologias de comunicação e a redução dos custos constituem os principais fatores para a ampla adoção das redes de computadores nas organizações. Tais redes são projetadas, essencialmente, para compartilhar recursos de hardware e software e viabilizar a troca de informações entre usuários. No entanto, as atuais tecnologias de redes restringem o número de dispositivos conectados, e são geralmente incompatíveis entre si. Dispositivos conectados a uma rede local que adota a tecnologia Ethernet, por exemplo, não interagem diretamente com outros que utilizam outras tecnologias. Isso dificulta a comunicação de grandes grupos de usuários e impede que usuários de redes distintas se comuniquem entre si. Para viabilizar essa comunicação, a única alternativa é adotar mecanismos que permitam a interoperabilidade, interconectando e compatibilizando as múltiplas redes heterogêneas. A interconexão destas várias redes é denominada inter-rede.

Arquitetura TCP/IP \\Conjunto

pioneiro de protocolos;

\\Arquitetura

universal.

A arquitetura TCP/IP é composta de um conjunto de protocolos e foi pioneira na concepção de conectar qualquer máquina Unix (ou que utilize TCP/IP) a qualquer outra, através de subredes interconectadas por gateways (roteadores). O TCP/IP é de aplicação universal, com especificações que seguem um padrão e são de conhecimento público (Request for Comments – RFC). Em um ambiente TCP/IP, estações comunicam-se com servidores ou outras estações. Isso é possível porque cada nó que usa o protocolo TCP/IP tem um único endereço de rede lógico, de 32 bits.

3


O Transmission Control Protocol (TCP) é o protocolo de transporte responsável pela entrega confiável dos dados no destino. Na RFC 793 que o define, ele é chamado de Host to Host Protocol, porque é um protocolo residente somente nos hosts e não nos gateways.

TCP Host to Host Internet

IP

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

Figura 1.1

FTP

HTTP

SMTP

DNS

TCP

Figura 1.2

TFTP

SNMP

NFS & RPC

Aplicação

UDP

Transporte

ICMP

IP

IGMP

Rede

ARP

Hardware Interface

RARP

Enlace de dados

A arquitetura TCP/IP, conforme já vimos, é constituída de 4 camadas de protocolos. Cada camada trata seus dados e monta a sua Unidade de Dados do Protocolo (Protocol Data Unit – PDU).


Telnet & Rlogin

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

Transporte dos pacotes Algoritmos de comutação são relativamente simples e basicamente os mesmos para a maioria dos protocolos de roteamento. Tipicamente, um host determina que precisa enviar um pacote para outro host. Para isso ele tem que saber, de alguma forma, o endereço do roteador que fará a ação (se não souber, não há como enviar o pacote). O host envia o pacote para o roteador, colocando o endereço físico do roteador (normalmente estão na mesma rede local, portanto o endereço físico será o MAC address) e o endereço do protocolo de rede do host de destino. O roteador então examina o pacote e tenta encaminhá-lo para o host de destino, baseado no seu endereço de rede. Se o roteador tiver na sua tabela de rotas a rota adequada, ele

5


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

Pacote Roteador1

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

Roteador2

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

Roteador3

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

Pacote Destino

6

Figura 1.3

\\Endereços

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

\\Host

é qualquer equipamento com capacidade de transmitir e receber pacotes IP em uma rede;

\\Hosts \\O

são interconectados por uma ou mais redes;

endereço IP é composto por:

\\Identificação

da rede;

\\Identificação

do host na rede.

\\Tamanho

de 32 bits (4 octetos) representados por 4 números decimais separados por um ponto;

\\Exemplo:


Endereçamento IP

200.201.152.93 (notação decimal pontuada).

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

7


Classes de endereçamento \\Os

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

\\N

= número da rede (network) dado pelo NIC;

\\H

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

Rede

8 Bits

8 Bits

8 Bits

8 Bits

Host

131

108

122

204

Classe A

N

H

H

H

Classe B

N

N

H

H

Classe C

N

N

N

H

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

de rede;

\\Número

de host.

O formato do endereço é conhecido como notação decimal pontuada, que é separada por pontos. Exemplo de endereço: 131.108.122.204. Cada bit no octeto tem um peso conforme sua posição, como (128, ..., 4, 2, 1). O valor mínimo para um octeto é 0; ele tem todos os bits 0. O valor máximo para um octeto é 255; ele tem todos os bits 1. Portanto, todos os endereços IP no intervalo de 0.0.0.0 a 255.255.255.255 são endereços válidos. A alocação dos endereços é gerenciada por uma autoridade central. Números de rede são administrados pelo Internet Network Information Center (InterNIC). O NIC também é o principal arquivo de RFCs (padrões dos protocolos da arquitetura TCP/ IP). No Brasil, a delegação de endereços IP é feita pela Fundação de Amparo à Pesquisa de São Paulo (FAPESP), órgão credenciado pelo InterNIC. Para facilidade de administração, os endereços IP são divididos em classes: \\Classe

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

8

Figura 1.4

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

\\Classe

C – utiliza somente os três primeiros octetos para identificar a rede. O octeto restante identifica o host e pode ser usado pelo administrador da rede. Atende tipicamente à faixa das redes locais. Como estas são bastante numerosas, são reservados 24 bits para a identificação das redes (os três bits mais significativos valem 1, 1 e 0), e apenas 8 bits para a identificação das estações.

O(s) bit(s) mais significativo(s) do primeiro octeto determina(m) a classe do endereço e também quantos bits representam a porção correspondente à rede.


\\Classe

Endereços classe A \\Faixa

dos números das redes: 1.0.0.0 até 126.0.0.0;

\\Quantidade

de endereços de hosts: 16.777.214.

Endereços classe B \\Faixa


\\Quantidade

de endereços de hosts: 65.534.

Endereços classe C \\Faixa


\\Quantidade

de endereços de hosts: 254.

Classes A, B e C são as classes mais comuns de endereço IP, mas endereços de classes D e E estão também definidos. Endereços de classe D começam em 224.0.0.0 e são usados para multicast, enquanto endereços de classe E começam em 240.0.0.0 e são reservados para propósitos experimentais.

Endereços especiais \\RFC

1918 – Endereços privados:

\\10.0.0.1

10.255.255.254

(10/8 prefix)

\\172.16.0.1

172.31.255.254

(172.16/12 prefix)

\\192.168.0.1

192.168.255.254

(192.168/16 prefix)

\\Somente

endereços IP públicos globais têm acesso à internet;

\\Empresas

que usam endereços IP privados terão que usar servidor proxy para traduzir endereços privados para públicos.

A RFC 1918 (Address Allocation for Private Internets) define as faixas de endereços que somente podem ser usados em redes privadas, os ditos endereços privados. Esses endereços não podem ser roteados na internet. Os endereços que podem ser

9

9


roteados são os demais endereços das classes A, B e C, denominados endereços globais ou endereços públicos, que não podem ser repetidos dentro da internet. A utilização dos endereços públicos é controlada pelo InterNIC. Os endereços privados, como são usados no âmbito de uma organização, não precisam ser únicos na internet, podendo ser repetidos de uma organização para outra. Assim, cada organização tem liberdade para usar como quiser as faixas acima definidas, sem a necessidade de obter permissão do InterNIC para isso. Por outro lado, esses endereços não poderão ser usados para acesso à internet, sendo necessário fazer uma tradução desses endereços privados para públicos através de um servidor chamado Proxy Server, que faz a função Network Address Translation (NAT). A utilização de endereços IP públicos no âmbito de uma organização é desencorajada por causa da escassez de endereços IP e principalmente de segurança (vulnerável a ataques de hackers). De maneira geral, podemos classificar os hosts que usam endereços IP dentro de uma organização nas seguintes categorias: 1. Hosts que não precisam acessar a internet; 2. Hosts que precisam acessar um limitado conjunto de serviços da internet (e-mail, FTP, www), que podem ser ajudados por gateways de aplicação; 3. Hosts que precisam de acesso irrestrito à internet, normalmente servidores disponibilizados para a internet. Os hosts das categorias 1 e 2 podem usar endereços privados, mas não os da categoria 3. Nos endereços privados relacionados acima, o prefixo indica o número de bits reservados para identificar a rede, do total de 32 bits. O primeiro bloco é uma classe A (10.0.0.0), o segundo bloco representa 16 classes B contíguas (todas as 16 classes têm os 12 bits de rede iguais) e o terceiro bloco representa 256 classes C contíguas (todas têm os 16 bits de rede iguais). Os bits que restam para hosts em cada bloco são denominados respectivamente de “bloco de 24 bits”, “bloco de 20 bits” e “bloco de 16 bits”.

Roteamento \\Roteamento

é a transferência de informação da origem até o destino através de

uma rede. Roteamento é a transferência de informação da fonte até o destino através de uma rede. Ao longo do caminho, tipicamente teremos pelo menos um nó intermediário. De acordo com esta definição, a função do roteador parece ser a mesma que a de uma ponte (switch/bridge). A principal diferença entre ambos é que a ponte opera

10

Origem

Destino


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.

Figura 1.5

Protocolos de transporte \\Dois

protocolos de comunicação fim-a-fim são definidos:

\\UDP

– User Datagram Protocol;

\\TCP

– Transmission Control Protocol.

Ambos são responsáveis pela utilização de múltiplas aplicações de redes entre duas máquinas. A aplicação determina o protocolo que vai ser utilizado.

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

UDP (User Datagram Protocol) O Protocolo de Datagrama do Usuário não possui mecanismos de controle de fluxo e não mantém a ordem de transmissão dos dados. É um protocolo sem conexão e nã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.

11


Comunicação VoIP \\O

VoIP pode utilizar os protocolos de transporte UDP e TCP;

\\Ambiente \\VoIP

ideal hoje:

+ UDP + RTP/RTCP + QoS.

A comunicação entre dispositivos VoIP pode ser realizada utilizando qualquer um dos protocolos de transporte (TCP ou UDP). Em aplicações de tempo real é comumente utilizado o UDP. Como o UDP não é numerado, não tem controle de sequência, como a aplicação vai reconstituir a informação de voz no destino? Neste caso é necessário um protocolo auxiliar que numere os pacotes para que os mesmos possam ser reconstituídos corretamente no destino. Esta nova ferramenta é o Protocolo de Tempo Real (RTP), que será visto adiante.

Evolução do VoIP \\1995: \\Em

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

\\1998: \\Surgem

os primeiros sistemas que integram VoIP e telefones convencionais, disseminando a tecnologia;

\\Aparecem \\Criados

os primeiros padrões relacionados a VoIP.

por:

\\Internet \\União

Engineering Task Force (IETF);

Internacional de Telecomunicações (ITU).

\\Hoje: \\VoIP

difundido no mercado, de diversas formas: PC-PC, PC-telefonia, telefonia-telefonia.

Nos anos 90, a voz era digitalizada e comprimida para então ser transmitida pela rede. A qualidade era ruim e só era possível a transmissão entre dois computadores. Como a partir desse período houve um grande desenvolvimento de redes de dados, com ênfase no protocolo TCP/IP e no aparecimento dos gateways, então muitas empresas passaram a desenvolver aplicativos para permitir o transporte de voz através das redes de dados, tendo em vista o pouco consumo de banda para voz.

12

As redes de nova geração que estão substituindo as redes de circuitos permitem o transporte de aplicações de tempo real, entre elas a voz, com qualidade similar ao celular. O protocolo de sinalização mais eficaz é o SIP, desenvolvido pelo IETF.

VoIP ≠ ToIP \\VoIP

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


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.

\\VoIP: \\Refere-se

às técnicas de empacotamento e transmissão de amostras de voz sobre redes IP e a mecanismos de sinalização para estabelecer as chamadas.

\\Telefonia

IP:

\\Refere-se

à aplicação das tecnologias VoIP na transmissão e na sinalização, com o oferecimento de um serviço similar ao serviço convencional de telefonia.

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

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

Vantagens e desvantagens do VoIP Vantagens: \\Custos

reduzidos nas comunicações;

\\Proteção

ao seu investimento;

\\Possibilidade

de utilizar a infraestrutura existente;

\\Infraestrutura

simplificada;

\\Portabilidade; \\Funcionalidades

acrescidas.

13


Desvantagens: \\Alto

custo inicial (para redes totalmente IP);

\\Aquisição

de nova aparelhagem;

\\Modernização \\Escassez

da aparelhagem já existente;

de mão de obra especializada;

\\Limitação

da rede / problemas relacionados a QoS.

Benefícios do VoIP \\Custos \\Alto

reduzidos nas comunicações;

retorno sobre o investimento (ROI);

\\Infraestrutura

simplificada;

\\Portabilidade; \\Funcionalidades \\Mão

acrescidas;

de obra especializada;

\\Limitações

da rede / QoS;

\\Segurança*; \\Integração

com a PSTN*.

* Itens não abordados neste curso

Custos reduzidos nas comunicações O serviço telefônico VoIP, quando bem planejado, tende a ser mais econômico que os serviços telefônicos tradicionais, liberando o usuário de utilizar as operadoras telefônicas tradicionais.

Alto retorno sobre o investimento (ROI) Os PBX IP são baseados em softwares, permitindo atualização com novos protocolos e funcionalidades. Há a possibilidade de utilizar a infraestrutura existente na empresa tanto de rede quanto de telefonia, utilizando os telefones, aparelhos de fax, o cabeamento e até a central em uso podem ser aproveitados para o serviço VOIP.

Infraestrutura simplificada Todos os serviços de comunicação (telefone, fax e internet) estão centralizados numa única infraestrutura. A voz correrá na infraestrutura de dados, ou seja, na rede IP.

14

Não importa onde você esteja. Desde que haja uma rede IP conectada à internet, você sempre poderá efetuar ligações através do seu ramal utilizando o softfone instalado no seu computador, também é possível utilizar telefones IP pequenos, leves e fáceis de transportar.

Funcionalidades acrescidas Por ser praticamente baseada em software, VoIP possibilita a implementação de funcionalidades que seriam difíceis ou impossíveis em redes tradicionais de telefone: \\Permite

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

\\Um

telefone IP não está limitado em termos de numeração referente à localização geográfica nem a nenhum prefixo, o que permite total mobilidade;


Portabilidade

\\Ao

receber uma chamada, esta é imediatamente redirecionada para o telefone VoIP, onde quer que ele esteja ligado na rede. Qualquer localidade onde exista internet pode receber e fazer chamadas de seu telefone VoIP, como se você estivesse no escritório;

\\Agentes

de call center que utilizam telefones VoIP podem trabalhar de qualquer local que tenha uma boa conexão com a internet.

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

Limitações da rede / QoS Esta é uma característica que pode ser encontrada em implementações que não tiveram o devido cuidado com a preparação da infraestrutura de rede. Para uma rede de dados suportar o transporte de voz é necessário possuir qualidade para tal. As desvantagens estão sendo reduzidas. A tradicional interface E-1 de 32 canais, com uma taxa de transmissão de 2 Mbits/seg, que nos anos 90 custava cerca de dois mil dólares, hoje custa em torno de 700 dólares. Já uma interface Ethernet de 10 Gbits/ seg custa entre mil e dois mil dólares. Em um E-1 é possível transportar 30 canais de voz, enquanto que em uma interface 10 Gbits/seg são milhares de chamadas.

15


A limitação da rede está rapidamente sendo ultrapassada, tendo em vista que aumenta a necessidade de fazer um upgrade nas redes ou até substituir os modelos mais antigos. As novas soluções são aderentes aos serviços de VoIP e Telefonia IP e já possuem QoS nativo.

Segurança Hoje em dia, é uma das questões mais discutidas na comunidade VoIP. Alguns ataques específicos no contexto da tecnologia VoIP: \\Call

Hijack – sequestro de chamada, que ocorre quando o intruso consegue desviar uma chamada e se fazer passar por um dos participantes dela;

\\SIP

Flood – negação de serviço, que consiste no envio de uma grande quantidade de mensagens SIP forjadas para um componente da rede VoIP;

\\SIP-Cancel/Bye

DoS – forma de negação de serviço em que o intruso simula uma mensagem de sinalização SIP do tipo cancel ou bye, evitando que chamadas sejam iniciadas ou causando a interrupção das ligações em andamento;

\\Manipulação

de registros – forma de spoofing na qual um usuário se registra como outro, permitindo o recebimento ou realização de chamadas de outros usuários.

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

(Session Initiation Protocol);

\\ H.323; \\ IAX

(Inter-Asterisk eXchange).

Pode-se utilizar o Asterisk como um gateway, para que redes VoIP com comunicação distinta possam se entender.

16

\\VoIP

via softphone:

\\Utilizando

um software adequado, um computador pode ser utilizado facilmente para a comunicação via VoIP.

\\VoIP

via ATA:

\\Consiste

em usar um Adaptador de Telefone Analógico (ATA);

\\Exemplo:

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

\\VoIP

via telefones IP:


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

\\Possuem

a mesma aparência de um telefone comum, mas utilizam conectores RJ-45 Ethernet;

\\Também

precisam de energia para funcionar.

VoIP via Softphone Forma de comunicação VoIP que utiliza softphone, isto é, software que emula o funcionamento de telefones convencionais para uma comunicação direta computador-computador. Skype, MSN, Paltalk e ICQ são exemplos de softwares que utilizam VoIP e permitem a comunicação por voz sobre a internet.

VoIP via ATA O ATA (Analog Telephone Adapter) permite a conexão de aparelhos do tipo analógico, decádico ou MF. É necessário programar o ATA para conectá-lo à rede. Todos os ATAs necessitam de uma fonte de alimentação, que pode ser local ou através de PoE (Power over Ethernet). Hoje existem no mercado ATAs para 2, 4, 8, 16, 24 e 30 aparelhos telefônicos.

VoIP via Telefone IP Similar ao ATA, o telefone IP deve ser configurado previamente para ser conectado na rede. Os telefones IP também precisam de energia para funcionar. Podem ter alimentação local ou por PoE. Não é uma solução trivial, como nos telefones analógicos ou digitais, para os quais bastava a conexão na tomada telefônica do tipo RJ-11. Algumas soluções de aprovisionamento já permitem que os telefones equipados com estes recursos sejam capazes de receber da rede toda a sua configuração, bastando ligá-lo na rede; para isso, a informação de cada telefone deve estar previamente armazenada em algum servidor da rede.

17


Telefonia tradicional X telefonia IP \\Telefonia

tradicional:

\\PSTN:

rede hierárquica;

\\Baseada

em grandes centrais telefônicas ligadas entre si de forma hierárquica;

\\Os

terminais não possuem inteligência;

\\O

endereçamento depende da região de abrangência da rede;

\\O

codec utilizado nas redes digitais era o G.711;

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

são muito controlados, com cerca de 40 ms.

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

terminais são diferentes dos usados na telefonia fixa;

\\O

telefone IP pode ser um software executando em um computador ou hardware dedicado.

\\Pacotes \\Jitter

de voz precisam passar por filas;

e perdas de pacotes comprometem a qualidade da ligação;

\\Mecanismos

de QoS são desejáveis.

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

18

PBX voz pacotizada

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

Internet

Internet


roteador

Voz analógica sobre par trançado

PBX assinante

Voz analógica sobre par trançado

voz pacotizada roteador Telefone IP

Figura 1.6 Na telefonia TDM, cada canal ou circuito fica alocado para uma chamada, com uma velocidade máxima de 64 Kbits/seg. Caso ocorra uma ociosidade do canal durante a chamada, ele não poderá ser compartilhado com outra chamada. Na telefonia VoIP, não existem os conceito de canal e circuito de transporte de pacote. Sua velocidade não está limitada a 64 Kibts/seg, onde a velocidade permitida pela tecnologia pode chegar a 10 Gbits/seg se for uma rede Ethernet. Na telefonia tradicional, a voz tem uma via expressa, sem congestionamentos. Em VoIP, a voz vai disputar espaço com todas as outras aplicações que trafegam na rede, como outros pacotes de voz, de dados, de gerência de rede etc. Se não houver um tratamento adequado para os pacotes de voz, eles poderão ser perdidos ou chegar com atrasos ou fora de ordem. Para resolver estes problemas, as redes de pacotes devem oferecer tratamento especial para os pacotes de voz. As ferramentas que permitem esse tratamento são os protocolos de qualidade de serviço (QoS), protocolos RTP e RTCP, entre outros, sem os quais uma rede de pacotes é incompatível para o transporte de voz. Imagine uma reunião: para que haja uma comunicação efetiva entre os participantes, é necessário que os participantes se façam entender, dominando um mesmo idioma e vocabulário. Sem o estabelecimento de uma linguagem comum, não haverá entendimento entre os participantes da conversa. Imaginemos agora a mesma situação, só que com computadores distribuídos em rede, em vez de pessoas. Nesse caso, além da infraestrutura de redes, é necessária uma linguagem padronizada para que haja uma comunicação efetiva entre os computadores. Para garantir que os computadores “falem a mesma língua”, existem diversos padrões e protocolos que regem essa comunicação, que são objetos de estudo de

19


diversas organizações que trabalham em sua manutenção e desenvolvimento. Dentre estas organizações, as mais notáveis em relação a padrões de videoconferência são: ITU-T, IETF e MPEG.

Padronização \\Organizações

que estabelecem normas e protocolos:

\\Telecomunication

Standardization Sector do International Telecommunications

Union – ITU-T; \\Internet

Engineering Task Force – IETF.

\\Os

padrões ITU-T de videoconferência exigem dos fabricantes a implementação de um conjunto mínimo de padrões de compressão de áudio e vídeo;

\\Há

padrões opcionais que também podem ser utilizados nos sistemas de videoconferência;

\\Além

disso, cada fabricante pode adicionar padrões proprietários às suas soluções:

\\Conjunto

mínimo + padrões opcionais + padrões proprietários.

A International Telecommunication Union (ITU) atua no desenvolvimento de padrões reconhecidos internacionalmente, no intuito de viabilizar a interação entre computadores e outros equipamentos de telecomunicações. Esse órgão internacional, responsável por estabelecer recomendações para telecomunicações, divide-se em grupos de estudo onde cada grupo é incumbido de investigar um conjunto de questões, cujos resultados definem as recomendações estabelecidas pela ITU-T. Um desses grupos, responsável pela família ITU H.3xx, é responsável por estabelecer recomendações para colaboração de dados e videoconferência, ou seja, pela formalização de padrões para comunicação multimídia sobre redes IP. A Internet Engineering Task Force (IETF) é uma comunidade internacional aberta, constituída de administradores, operadores e pesquisadores concentrados em padronizar a evolução da arquitetura da internet e a operação da rede. A IETF está aberta a qualquer indivíduo interessado. O trabalho técnico da IETF também é realizado em grupos de estudo, organizados por tópicos de interesse em diversas áreas, como distribuição, transporte e segurança. Outra preocupação de padronização diz respeito às estratégias de compressão e transmissão de dados multimídia. Hoje em dia, existem cada vez mais aplicações que envolvem áudio, vídeo e dados à disposição de um público distribuído e crescente. A explosão da internet na década de 1990 levou milhares de usuários a utilizarem esses serviços com intuito profissional, comercial ou doméstico. Assim, a internet agrega um volume de dados multimídia cada vez maior, o que eleva a demanda de banda e a necessidade de estratégias eficientes para transmissão desses dados. Nesse sentido, uma organização aborda mecanismos para codificação e transmissão de áudio e vídeo. 20

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.


Padrões de videoconferência

Princípios de codificação de áudio \\PCM

(Pulse Code Modulation);

\\Como

converter áudio analógico em digital?

\\Como \\Que

minimizar o erro de quantização (duas formas)?

taxa de amostragem deve ser utilizada, supondo que:

\\Frequência

da voz humana: 20 Hz – 6.000 Hz (banda de 4 kHz fornece inteligibilidade perfeita).

\\Frequência \\Qual

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

21


A imagem abaixo mostra um exemplo de um sinal de áudio analógico que será convertido para digital:

Figura 1.7

O eixo y do gráfico mostra a magnitude do sinal e o eixo x do gráfico denota o tempo. A linha azul representa a onda sonora, enquanto as linhas verticais ao longo do gráfico marcam os momentos em que serão obtidas amostras da onda sonora, ou seja, os momentos onde a magnitude da onda será representada por um número binário. O próximo gráfico mostra o resultado da aplicação do PCM sobre a primeira parte da onda:

111 110 101 100 011 010

Figura 1.8

001

111

110

101

011

011

100

011

000

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.


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.

Já o ouvido humano é capaz de perceber sons entre 20 Hz e 20 kHz, aproximadamente, ou seja, sons com frequências acima de 20 kHz não podem ser ouvidos. Este conhecimento costuma ser utilizado na digitalização de sons mais complexos que a voz, onde se deseja a capacidade de representação de todo o espectro de frequências que pode ser ouvido pelo homem. Em CDs de áudio, por exemplo, é utilizada a taxa de amostragem de 44.1 kHz, pouco mais que o dobro da frequência máxima ouvida pelo homem. Outro parâmetro que influencia diretamente na qualidade do sinal digital é o número de bits utilizado em cada amostra. No exemplo anterior foram utilizados 3 bits por motivos didáticos. Com um número maior de bits é possível representar mais fielmente o sinal analógico (mais linhas horizontais no gráfico), reduzindo a diferença entre os sinais, o que é chamado de erro de quantização. Em CDs de áudio, são utilizados 16 bits para cada amostra. Em telefonia se trabalha com 8 bits por amostra.

\\Compansão

do sinal;

\\Voz

pode variar 10.000 vezes, pois o ser humano pode falar baixinho ou gritando e o outro lado deve ouvir perfeitamente. Como lidar com isso?

Outra técnica aplicada durante a digitalização de sinais sonoros é a compansão do sinal, representada na figura a seguir. Este processo é necessário, pois a amplitude dos sinais sonoros pode variar muito. A voz humana pode variar 10.000 vezes, pois o ser humano pode falar muito baixo ou gritando, e em ambos os casos deve ser totalmente entendido no destino. Isso cria um problema para a digitalização, pois seriam necessários muitos bits para representar cada amostra (o ideal seriam 13 bits por amostra, mas comercialmente são usados 8).

23


No processo de compansão, os sinais mais fracos são elevados e os mais fortes são reduzidos, e assim todos podem ser representados por um número fixo de bits, pois o sinal analógico da voz é “homogeneizado”. Dessa forma, se a pessoa fala baixo, sua voz é amplificada antes da digitalização, e se fala alto, não é amplificada. Assim, todos os sinais podem ser representados com os 8 bits, economizando na taxa de transmissão via rede. As duas formas mais utilizadas de compansão são chamadas de “lei A” (mais usada na Europa) e “lei μ” (mais usada nos Estados Unidos e Japão).

Vs

Compansão segundo lei A ou μ (analógico) Usar 13 bits e comprimir segundo lei A ou μ (digital)

Ve

Mais informações: \\Tutorial

de VoIP disponível em: www.teleco.com.br/tutoriais/tutorialtelip/pagina_1.asp

\\Resumo/Comparação

de diversos codificadores de vídeo: en.wikipedia.org/wiki/Comparison_of_audio_codecs

Codificação da mídia de voz \\Técnicas: \\Codificação

de forma de onda;

\\Paramétrica; \\Híbrida. \\Comparação

entre técnicas de codificação;

\\Codificadores \\Melhor

de forma de onda:

qualidade, menor atraso, maior taxa de bits.

\\Vocoders: \\Menor

taxa de bits, pior qualidade, grande atraso e jitter.

\\ Codificadores \\Boa

24

híbridos:

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

Figura 1.9

\\Codec

é uma abreviação de codificador-decodificador;

\\Codecs

especificam como os sinais analógicos da voz devem ser codificados em dados digitais;

\\Codecs

permitem compressão dos dados;

\\Grande

parte dos padrões usa técnicas baseadas na codificação da forma de onda (PCM – Pulse Code Modulation).

O codec comprime os dados, eliminando informações redundantes e previsíveis, tanto em áudio como em vídeo. Os dados passam por uma conversão analó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.


Codec

O codec realiza 8 mil amostras por segundo (125µsec/amostra), devido ao teorema de Nyquist, que diz que essa medida é suficiente para capturar toda a informação em um canal telefônico com largura de banda de 4 KHz. Em uma amostragem menor, a informação transmitida seria perdida; já em uma amostragem maior, nenhuma informação adicional seria acrescentada. Esta técnica, também conhecida como Pulse Code Modulation (PCM), é o coração do sistema moderno de telefonia. Como consequência, todos os intervalos de tempo dentro do sistema telefônico são múltiplos de 125 µsec. O processo de codificação envolve uma transformação conhecida como conversão analógico-digital ou conversão A/D. Durante o processo de reprodução, deve ser adotada uma transformação no sentido inverso, conhecida como conversão digital analógica, ou simplesmente D/A. O processo A/D consiste em capturar amostras da informação original em pequenos intervalos de tempo, criando uma representação para cada uma das amostras, com base em um código de representação bem conhecido. Na conversão D/A, com base no mesmo código de representação, cada amostra é restaurada em seu formato original e reproduzida.

Codificação de forma de onda \\Na

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

\\No

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

\\O

esquema mais utilizado é o Adaptive Differential Pulse Code Modulation (ADPCM);

\\Baseada

em predição linear.

A codificação de forma de onda de sinais de voz é baseada principalmente na predição linear, e o esquema mais utilizado é o Adaptive Differential Pulse Code 25


Modulation (ADPCM). Os codificadores de forma de onda são os que propiciam voz de melhor qualidade, mas são os que despendem a maior taxa de bits, em geral com taxas superiores a 30 kbps.

Codificação paramétrica \\Também

denominados vocoders (voice coders):

\\ A

classe de vocoders mais utilizada é a dos vocoders LPC (Linear Predictive Coding);

\\Utilizam,

no decodificador, um modelo de produção da voz, onde os parâmetros são estimados e transmitidos pelo codificador em intervalos de tempo entre 10 e 30 ms.

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

Codificação híbrida \\Combinam

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

\\ A

maioria dos codificadores híbridos utiliza o modelo de codificação Code Excited Linear Predictive (CELP).

Usa conceitos das duas outras formas de codificação (codificação paramétrica e codificação em forma de onda), procurando um balanço entre qualidade e taxa de compressão. Os codificadores híbridos são esquemas que combinam características dos codificadores de forma de onda e dos vocoders. Atualmente, a maioria dos codificadores híbridos utiliza o modelo de codificação Code Excited Linear Predictive (CELP), com taxas de bits entre 4 e 16 kbps, proporcionando qualidade muito melhor do que a dos vocoders. Alguns deles propiciam qualidade muito próxima da obtida com os codificadores de forma de onda. Com base nos tipos de codificação citados, concluímos que os codificadores de forma de onda são os que proporcionam voz com melhor qualidade, mas despendem maior taxa de bits. Em geral, taxas superiores a 30 kbps. Como vimos, um fator a ser considerado é o delay inserido pelo codificador, onde de maneira geral quanto menor for a taxa do codec, maior será seu delay. 26


Em uma rede de pacote, onde os pacotes de voz podem sofrer grandes delays, a escolha do codec em função do atraso do mesmo pode ser um diferencial do projeto em enlaces onde o delay é crítico, como em uma conexão via satélite. Em redes com grande disponibilidade de banda, um codec indicado é o G.711, que possui taxa de transmissão a 64 Kbits/seg, mas com delay próximo de zero, boa qualidade e livre de licença.

Padrões de codificação de voz \\Principais

padrões:

\\G.711; \\G.729; \\G.723.1; \\iLBC.

A tabela abaixo mostra um resumo da faixa de frequência, taxas de transmissão e latência utilizada nos principais padrões de codificação de áudio. Padrão

Faixa de frequência

Taxa de transmissão

Latência

Qualidade

G.711

300 Hz – 3.4 kHz

64 kbit/s

<1

Excelente

G.722

50 Hz – 7 kHz

48, 56 ou 64 kbit/s

<2

G.722.1

14 kHz

G.722.2

50 Hz – 7 kHz

6.6 – 23.85 kbit/s

-

G.723.1

8 kHz

5.3 ou 6.3 kbit/s

100

Razoável a boa

G.726

8 kGz

16 – 40 kbits/s

60

Boa a razoável

G.728

300 Hz – 3.4 kHz

16 kbit/s

<2

Boa

G.729

8 kHz

8 kbits/s

25 – 35

Boa

ILBC

300 Hz – 3.4 kHz

13,33 ou 15,20 kbit/s

30 – 20

Boa

24-32 kbit/s

-

Boa

Tabela 1.1

O padrão G.711 é um dos melhores oferecidos pelo mercado, com delay próximo de zero, embora sua taxa de transmissão de bits seja muito alta (64 Kbits/seg), consumindo muita banda em comparação com os demais codecs. Seu grande diferencial é que está livre de licença, sendo um fator a considerar para projetos com disponibilidade de banda. Outro fator a considerar é que este codec não comprime, sendo utilizado em transmissão de fax.

27


O padrão G.729 possui taxa de 8 Kbits/seg e é muito utilizado no mercado. É um codec ITU com a necessidade de compra de licença. Existem as versões G729a, menos complexa que a G729, e a versão G729b, com capacidade de inserir ruído de conforto nas ligações que utilizam VAD (detecção de atividade de voz). O padrão G 723.1 possui taxas menores que o G.729, é um codec ITU e também necessita de pagamento de licença. Possui taxas de 6,3 ou 5,3 Kbits/seg e seu atraso é da ordem de 37,5 mseg. O codec iLBC tem fonte aberta, sem exigência de pagamento de licença, sendo uma boa opção de solução de fonte aberta. Sua taxa é da ordem de 13,3 Kbits/seg.

G.711 \\Codificador \\ Representa

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

\\Comprime

amostras PCM com 13 ou 14 bits em 8 bits usando escala logarítmica, gerando 64 kbps.

A função básica do algoritmo é codificar a voz utilizando 8 bits por amostra; a banda de entrada de voz é amostrada a 8 kHz, mantendo a largura de banda de 300 a 3400 Hz. Com isso, cada canal de voz precisa de 64 kbps. Dois algoritmos foram definidos no padrão ITU-T G.711: U (ulaw) e A (alaw); o primeiro é utilizado na América do Norte e no Japão, o segundo, na Europa e no resto do mundo. O princípio do codificador G.711 é que se deve utilizar a quantização com escala logarítmica para obter uma relação sinal/ruído independente da intensidade. Isso foi possível duplicando o passo de quantização a cada vez que a intensidade do sinal era duplicada; deste modo obteve-se uma constante.

G.729 \\Padrão

ITU-T para codificação de sinais de voz a uma taxa de 8 kbps, com quadros de 2 ou 8 bytes a cada 10 ms;

\\Utiliza

o algoritmo Conjugate Structure Algebraic Code Excited Linear Prediction (CS-ACELP), baseado no modelo de codificação Code Excited Linear Prediction (CELP);

\\Desenvolvido

originalmente para uso na telefonia fixa com comutação de circuito.

O codificador G.729 codifica sinais de voz a uma taxa de 8 kbps usando o modelo CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Prediction), que é baseado no modelo de codificação CELP. Ele é projetado para operar com o sinal de

28

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.


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

G.723.1 \\Padrão

ITU-T para taxas de bits muito baixas (5,3 ou 6,3 kbps), desenvolvido para uso em telefonia por redes de pacotes;

\\Para

taxas de 5,3 kbps, usa o algoritmo ACELP (Algebraic Code Excited Linear Prediction);

\\Para

taxas de 6,3 kbps, usa o algoritmo MP-MLQ (Multipulse Maximum Likelihood Quantization).

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

iLBC \\Internet

Low Bit Rate Codec (iLBC) se encontra em caráter experimental, a ser padronizado pela IETF;

\\Desenvolvido

para propiciar comunicação robusta em VoIP, com tolerância a perdas e recuperação de erros;

29


\\Baseado

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

\\Opera

a taxas de 13,33 kbps (399 bits em quadros de 30 ms) ou 15,20 kbps (303 bits em quadros de 20 ms).

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

Arquitetura VoIP Zona 1

GK MCU

TM

Zona 2

GK MCU

GC

TM GC

Tel IP

Tel IP

Rede IP

GW

GW

...

... PABX

STFC

...

PABX

... Figura 1.10

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

30

(GK) – permite o controle centralizado do sistema;

Branch eXchange (PBX) – centro de distribuição telefônica pertencente a uma empresa que não inclui como sua atividade o fornecimento de serviços telefônicos ao público em geral;

\\Unidades

de Controle Multiponto (MCU) – permitem o estabelecimento de conferências entre três ou mais pontos finais;

\\Gateway

(GW) – necessário quando se deseja estabelecer comunicação entre terminais em diferentes tipos de redes.

Projetos VoIP no Brasil \\Projeto

VoIP4All:


\\Private

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

31

Terminal H.323 Ambiente H.323 Postgre SQL GnuGK Gatekeeper H.323 + VQCDR Server para coleta de CDR

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

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

de ida

bil nta co

VQOpenPhone Suporte ao envio de CDR com informação de qualidade

e ão aç tic ten Au

Asterisk Gateway SIP/H.323 Gateway VOIP/PSTN

Consulta

PSTN

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

FreeRadius a

lid

bi

a nt

Cliente SIP Ambiente SIP

e

co

a

ic

nt

e ut

o çã

de

A

Autenticação e contabilidade


A ilustração abaixo é referente à estrutura básica de uma instituição participante do fone@RNP.

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

32

SIP/H.323.

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

sobre as funcionalidades dos clientes X-Lite, Telefone IP e ATA;

\\Identificação

do tráfego da rede TCP/IP.

Tempo previsto para as atividades \\1

hora a 1h30 minutos (trabalho em grupo).

Preparando o ambiente Antes do início das atividades, o instrutor irá iniciar a máquina virtual que contém o software Asterisk e efetuar dois passos importantes para estabelecer usuário e senha de acesso para a máquina virtual: \\Usuário \\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


A linha bindaddr=0.0.0.0 deverá ser alterada para: bindaddr=ip_da_máquina_ virtual

Inicie o Asterisk com o comando: # asterisk –vvvv &

Atividade 1 – Instalando o cliente X-Lite Passo 1: no ambiente Windows, execute o aplicativo localizado no desktop e instale o cliente X-Lite. O aplicativo também poderá ser encontrado no site do fabricante: www.counterpath.com/x-lite.html

Figura 1.12 Não há necessidade de reiniciar o sistema.

Atividade 2 – Configurando o X-Lite Passo 1: execute o X-Lite. Para entrar no modo de configuração, aponte o mouse sobre o telefone e clique com o botão da direita. Feito isso, agora selecione a opção SIP Account Settings..., como indicado na próxima imagem.

34


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

Figura 1.13 Passo 2: configure a sua conta de acordo com o plano de ramais. Substitua o XX pelo número da sua estação. A senha para autenticação no servidor é voip, devendo ser inserida no campo Password.

Figura 1.14

35


Se a configuração da conta foi efetuada corretamente, a mensagem Ready será exibida na tela do X-Lite, conforme ilustra a figura seguinte.

Figura 1.15

Atividade 3 – Configurando o Telefone IP Passo 1: acesse no seu browser o endereço http://. Em seguida são solicitados usuário e senha para autenticação, conforme abaixo:

Figura 1.16 O nome do usuário é Polycom e a senha 456. Após o sucesso na autenticação a seguinte página será apresentada:

Figura 1.17

36


Passo 2: clique no link Lines. Nesta página devemos configurar as contas SIP que serão utilizadas pelo telefone. Nesta atividade iremos configurar apenas a Linha 1. A página abaixo apresenta as sessões Line 1 e Serve 1:

Figura 1.18 A Linha 1 será utilizada configurando apenas alguns dos campos existentes nas sessões Identification e Server 1. Na sessão Identification os campos Display Name, Address, Auth User ID, Auth Password e Label são configurados. Somente os campos Address e Port são configurados na sessão Server 1. Substitua o XX pelo número da sua estação. Passo 3: para finalizar , clique no botão Submit e aguarde o telefone ser reiniciado. Em seguida, o telefone está pronto para ser utilizado.

Atividade 4 – Configurando o ATA Passo 1: precisamos do IP do adaptador. Para descobrir o IP recebido pelo adaptador, ligue-o a um telefone convencional e digite **** (quatro asteriscos), e em seguida digite 110#. Uma mensagem com o número do IP será anunciada. Passo 2: acesse no seu browser o endereço http://

37


Passo 3: no canto superior direito da página abaixo clique em Admin Login:

Figura 1.19 Passo 4: na página seguinte clique em Line 1:

Figura 1.20 Passo 5: na página mostrada na próxima figura configure apenas os parâmetros abaixo: \\Proxy:

IP fornecido pelo instrutor;

\\Display \\User

Name: entre com seu nome completo;

ID: 30XX;

\\Password: \\Register

voip;

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:

38

Figura 1.21

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.


Passo 6: clique no botão Save Settings.

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://. Em seguida, na página apresentada abaixo clique no link General:

Figura 1.22

39


Na página abaixo, clique em Audio Processing:

Figura 1.23

40


Em seguida troque a ordem dos codecs de áudio apresentados na página abaixo, clique em Submit, espere o telefone reiniciar e efetue chamadas com todos os codecs, anotando as suas observações.

Figura 1.24

ATA Passo 1: acesse no seu browser o endereço http://. Em seguida, na página apresentada abaixo clique no link Line 1:

Figura 1.25

41


Passo 2: na parte de baixo da página troque os codecs, efetue chamadas com todos os codecs e anote as suas observações.

Figura 1.26

42

Passo 1: inicialize o software Wireshark instalado no desktop. Observe as opções destacadas na imagem abaixo.


Atividade 7 – Conhecendo o Wireshark

Figura 1.27 Passo 2: escolha a interface de rede com a qual iniciaremos a captura; para isso, selecione o botão List the available capture interfaces. A interface com a qual trabalharemos deverá apresentar uma contagem crescente de pacotes, conforme destacado na imagem a seguir. Passo 3: conhecendo as opções de configuração da interface de rede.

Figura 1.28

43


Figura 1.29

Figura 1.30

Atividade 8 – Efetuando capturas com Wireshark Inicie a captura de pacotes com a interface em modo promíscuo, e logo depois inicie sem ativar o modo promíscuo. Descreva suas observações.

44

Figura 1.31


Com a interface em modo promíscuo, inicie a captura de pacotes e observe o campo Protocol. Após exibir os protocolos TCP e UDP, pare a captura e observe os detalhes na tela de Árvore de protocolos. Navegue e veja as características do protocolo TCP e do protocolo UDP.

Figura 1.32 Complete a tabela abaixo conforme os dados obtidos na captura:

No campo “Ethernet II” informe:

Pacote TCP

Pacote UDP

Src

Src

Dst

Dst

Version

Version

Header length

Header length

Total length

Total length

Source

Destination

MAC e “IG bit” No campo “Internet Protocol”

Tabela 1.2 Do pacote TCP: Transmission Control Protocol Source Port

Destination Port

Flags

Do pacote UDP: User Datagram Protocol

Tabela 1.3

Source Port

Destination Port

Length

Data

TCP

UDP

45


Com os dados obtidos, podemos observar algumas diferenças entre os pacotes TCP e UDP. Liste-as e comente.

Atividade 9 – Capturando pacotes na rede Para exemplificar a interação dos protocolos e o processo de encapsulamento, vamos analisar um quadro capturado numa rede local Ethernet, durante uma sessão de um host com um servidor web que usa o protocolo HTTP de aplicação e o protocolo TCP de transporte. Neste caso, ambos estão na mesma rede local. O programa utilizado para isso é o analisador de rede Wireshark. Wireshark pode ser obtido em www.wireshark.org. A figura a seguir mostra a tela principal do Wireshark. Na parte superior estão os menus suspensos e logo abaixo a barra de ferramentas. Para abrir o arquivo de captura chamado Atividade1.cap utilizamos o ícone da barra de ferramentas que representa uma pasta (sexto da esquerda para a direita). Para esta análise selecionamos o pacote no 258, que foi enviado do servidor web para o host do usuário.

Figura 1.33 Quadro capturado em rede local Ethernet

46

\\Camada

física;

\\Camada

de enlace de dados;

\\Camada

de rede;

\\Camada

de transporte.

Cada camada, quando selecionada, faz com que os bytes correspondentes fiquem destacados na janela inferior.


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:

Usando o Wireshark: 1. Determine o tamanho do cabeçalho do protocolo IP:

2. Determine o tamanho do cabeçalho do protocolo TCP e o tamanho dos dados da aplicação:

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

47

48


2 Protocolo SIP ►►

Sumário Protocolo de iniciação de sessão – SIP . . . . . . . . . . . . . . . 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 50

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

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

Capítulo 2 – Protocolo SIP

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

\\Bate-papo.

O protocolo de iniciação de sessão (Session Initiation Protocol – SIP) foi desenvolvido pela Internet Engineering Task Force (IETF) na década de 90. Sua primeira versão, lançada em 1996, foi chamada inicialmente de Session Invitation Protocol, onde sua função era basicamente estabelecer a sessão. Outras funcionalidades, como controles para conferências, foram introduzidas na versão 2.0, lançada em 1997. Em fevereiro de 1999, o SIP foi proposto como um padrão e publicado na RFC 2543. Sua última versão (SIPv2) foi publicada na RFC 3261 em 2002, substituindo a versão anterior. O SIP é utilizado para estabelecer, manter e encerrar conferências multimídia em uma arquitetura cliente/servidor — o originador é o usuário cliente e o destino é o usuário servidor. Existem as versões SIP-T IETF, SIP-I ITU e SIP-I ANSI, similares ao SIP, mas com diferenças sutis, utilizadas para tunelar mensagens ISUP ou outras sinalizações telefônicas através de redes IP. Em uma sessão SIP, um servidor e um cliente terão total controle sobre a sessão, podendo ser de transmissão de voz, vídeo ou bate-papo.

Objetivos básicos do protocolo SIP \\Contemplar

a criação e o gerenciamento de sessões para troca de fluxos multimídia entre aplicações.

\\Tornar

a comunicação possível com outros protocolos, como:

\\Real

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

\\Session \\Real

Description Protocol (SDP);

Time Streaming Protocol (RTSP);

\\Media

Gateway Control Protocol (MGCP).

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

de dado transportado;

51


\\Timestamps; \\Número

de sequência, entre outras informações.

O protocolo de controle de transporte em tempo real (Real Time Control Protocol – RTCP) foi projetado para trabalhar em conjunto com o RTP. Em uma sessão RTP, os participantes enviam periodicamente pacotes RTCP para receberem informações sobre a qualidade da entrega dos dados, sobre os membros, jitter e perda de pacotes. O protocolo de descrição de sessão (Session Description Protocol – SDP), definido pela IETF na RFC 2317, é utilizado em conjunto com o protocolo SIP para definir as sessões, tipo de mídia, codecs, portas de mídia e criptografia. O Real Time Streaming Protocol (RTSP), ou protocolo de fluxo contínuo em tempo real, é utilizado para transmissão de áudio e vídeo, ou seja, streams sincronizados de mídias contínuas em tempo real pela internet. Foi definido peIa IETF na RFC 2326. O Media Gateway Control Protocol (MGCP) assume modelo de inteligência centralizada, facilita a tarifação e barateia os terminais e gateways. Utiliza os protocolos RTP/ RTCP para o transporte de mídia, funcionando como sinalização por canal comum nº 7 ISUP e outras sinalizações. É a junção do Internet Protocol Device Control (IPDC), protocolo para controle de dispositivos de mídia, com o Simple Gateway Control Protocol (SGCP). Foi definido pela IETF nas RFCs 2705 e 3435.

Extensões ao protocolo SIP \\SIP

for Instant Messaging and Presence Leveraging Extensions (SIMPLE);

\\Session

Initiation Proposal Investigation (SIPPING);

\\Multiparty \\IP

Multimedia Session Control (MMUSIC);

Telephony (IPTEL);

\\PSTN-Internet

Interworking (PINT).

\\SIMPLE

– grupo que foca seu trabalho nas aplicações relacionadas ao protocolo SIP, conhecidas como instant messages e presence;

\\SIPPING

– grupo responsável por documentar o uso do SIP relacionado às aplicações de telefonia e multimídia e por desenvolver requerimentos para futuras atualizações;

\\MMUSIC

– grupo responsável por desenvolver protocolos que suportem teleconferência e comunicações multimídia;

\\IPTEL

– grupo com serviços focados nos problemas que dizem respeito à resolução de nomes (URI) e ao roteamento para os protocolos de voz sobre IP;

52

– grupo designado para estudar a arquitetura e os protocolos necessários para suportar serviços para os quais um usuário localizado na internet faz a requisição de uma ligação telefônica, através de um terminal PSTN.

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

ponto-a-ponto:

lógica está armazenada nos clientes, exceto mensagens de roteamento.

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

do protocolo de transporte;

em texto;

\\Sinalização \\Toda


\\PINT

ao Session Description Protocol (SDP): para transportar descrições dos parâmetros de cada sessão.

com IPv4 e IPv6;

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

\\Não

é um protocolo de transferência de dados;

\\Transporta

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

\\Não

fornece suporte para QoS;

\\Não

tem a finalidade de substituir todas as características da telefonia;

\\Não

é um protocolo de reserva de recurso;

\\Não

é um protocolo para controle de dispositivos ou procedimento para chamadas remotas (Remote Procedure Calls – RPC);

\\Não

substituirá o protocolo da PSTN;

\\Trabalha

juntamente com a PSTN através de gateways, mas esta não é sua função principal.

O Protocolo de Iniciação de Sessão é um protocolo de aplicação que utiliza o modelo “requisição-resposta”, similar ao HTTP, para iniciar sessões de comunicação interativa entre usuários. Sua rápida adoção talvez esteja relacionada principalmente às características listadas abaixo: \\Simplicidade;

possui apenas seis métodos;

\\Independência \\Baseado

em relação ao protocolo de transporte;

em texto;

\\Assim

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

53


O SIP não é um protocolo milagroso desenvolvido para solucionar todos os problemas da comunicação. Não tem o objetivo de substituir todas as características e serviços providos pela rede comutada de telefonia com serviços idênticos. Não é um protocolo de transferência como o HTTP, que foi desenvolvido para transportar uma quantidade grande de dados. O SIP transporta uma pequena quantidade de dados requerida para configurar comunicações iterativas (pequenas mensagens de texto). Também não age como um dispositivo de reserva de recursos, por não prover QoS, apenas interagindo com protocolos desenvolvidos para suportar QoS. Não é um protocolo que substituirá a PSTN, sendo bem diferente dos modelos de chamadas telefônicas e dos protocolos de sinalização de telecomunicação. O SIP pode interagir com a PSTN por meio de gateways, mas esta não é sua função principal.

Elementos de uma rede SIP \\Rede

SIP simples:

\\Apenas

para comunicação entre dois user agents, enviando mensagens SIP diretamente.

\\Rede

SIP típica:

\\Contém \\User

mais de dois tipos de elementos SIP: agents;

\\Proxy

Servers:

\\Stateful; \\Stateless. \\Redirect

server;

\\Registrar. \\User

Agents (UA):

\\Terminais \\Dentro

dos UA temos:

\\User

Agent Client (UAC);

\\User

Agent Server (UAS).

\\User

Agent Client (UAC):

\\Parte \\User

\\UAC

do UA que envia as requisições e recebe as respostas.

Agent Server (UAS):

\\Parte

54

que usam SIP para se encontrar e negociar características da sessão;

do UA que recebe as requisições e envia as respostas.

e UAS são entidades lógicas.

O User Agent (UA) é uma entidade lógica da arquitetura SIP. Pode atuar como um User Agent Client (UAC) ou como um User Agent Server (UAS), ou seja, cada User Agent contém um UAC e um UAS. \\UAC

(User Agent Client) – o Usuário Agente Cliente executa a função de cliente da aplicação e é responsável por iniciar uma chamada SIP;

\\UAS

(User Agent Server) – o Usuário Agente Servidor é a parte com função de servidor e permanece “ouvindo” a rede, aguardando requisições.


Arquitetura do SIP

Os terminais que usam SIP para se encontrar e negociar características da sessão são user agents, que podem ser telefones celulares, gateways, PDAs. Proxy servers são usados para traduzir nomes e números de identificação dos UA para o endereço IP em que eles estão instalados. Também são chamados de SIP Proxy. Podem ser de dois tipos: \\Proxies

Stateless não mantêm o estado das chamadas. Eles simplesmente reencaminham as mensagens para o destino ou para outro proxy. São mais simples e mais rápidos.

\\Proxies

Stateful mantêm o estado das chamadas. Podem se encarregar de tarefas como bilhetagem e contabilização.

Registar server é a entidade lógica responsável por manter os registros dos usuários. Ela extrai informação sobre sua localização atual, armazena-a em um banco de dados e mapeia nomes e números em endereços IP. Redirect server é um tipo de servidor da arquitetura SIP que, ao receber uma mensagem, envia de volta uma resposta com um redirecionador, o endereço de outro servidor proxy para quem o UAC deve reenviar a requisição original. Um user agent chamador atua como UAC quando envia uma mensagem de requisição INVITE e recebe resposta das requisições feitas. Um user agent chamado se comporta como um UAS quando este recebe a requisição INVITE e retorna uma resposta. Esta situação muda quando a pessoa chamada decide enviar um BYE e terminar a sessão. Neste caso, o user agent chamado (que envia BYE) se comporta como um UAC e o user agent chamador atua como um UAS.

55


Callee A UAC Caller

Stateful Forking Proxy Invite

Invite

UAC

UAS

UAC UAS UAC

UAS

Callee B

Invite UAS

Bye

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;

\\Existem

dois tipos de servidores proxy:

\\Stateful; \\Stateless.

Servidores stateful são indicados para o controle de terminação, pois possuem capacidade para controlar todas as transações, mantêm o estado das chamadas e são capazes de produzir informações que possibilitam a bilhetagem (cobrança) das ligações. Servidores stateless são similares às “centrais tandem” da velha telefonia. Armazenam poucas informações e são indicados para implementação de centrais trânsito, a fim de evitar congestionamentos.

56

Figura 2.1 UAS e UAC

\\Entidade

lógica que mantém o estado de todas as transações de clientes e servidores: \\Mais

complexo do que o servidor stateless;

\\Performance \\Trabalha \\Pode

limitada;

com forking;


Servidor Stateful

aplicar métodos mais sofisticados para buscar usuários.

Um servidor stateful mantém o estado das chamadas, do estabelecimento (INVITE) até sua finalização (BYE), podendo implementar formas mais complexas para encontrar um usuário. Por exemplo, pode tentar encontrar um cliente em seu telefone do escritório e, se não atender, pode redirecionar a chamada para seu celular.

Servidor Stateless \\Entidade

lógica que não mantêm o estado das transações feitas pelo cliente ou pelo servidor;

\\Repassa \\Não

todas as requisições e respostas recebidas;

se importa com o que acontece com as transações, apenas as repassa;

\\Mais

rápido do que o servidor stateful, entre outras funções podendo servir de:

\\Tradutor

de mensagens;

\\Roteador.

Um servidor stateless não mantém o estado das chamadas, repassando as requisições recebidas. Não se importa com o que acontece com as transações, apenas as repassa. É mais rápido do que o servidor stateful e pode servir como: \\Tradutor

de mensagens;

\\Roteador; \\Balanceador

de carga.

57


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

entre duas empresas com servidor Proxy. DNS Server

2. SIP SRV for b.com

3. proxy.b.com Company B

Company A proxy.a.com

Joe 1. Invite

proxy.b.com 4. Invite

5. In

vite

Bob

5.6.7.8 6. Bye

1.2.3.4

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:[email protected]” 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:[email protected]” está em uma companhia diferente, então irá procurar servidor SIP proxy da companhia B e enviar o convite para lá. Os servidores proxy da companhia B podem estar pré-configurados no “proxy.a.com”, ou o proxy utilizará os registros DNS SRV para encontrar os servidores proxy de B. O convite chega até “proxy.b.com”, que sabe que Bob tem condições de atender a chamada em seu telefone. Então o proxy envia o convite para o endereço do telefone IP de Bob, 1.2.3.4.

Servidor de redirecionamento (Redirect Server) \\Servidor

que recebe uma requisição e retorna uma resposta contendo uma lista da localização atual do cliente;

\\Gera

58

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

Figura 2.2

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.


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.

M

2. 3 ov 02 ed Te

m

1. I

po ra rily

nv ite

Redirect Server

3. Invite User Agent A

Figura 2.3

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:

\\Endereço

IP;

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


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:[email protected] is reachable at sip:[email protected]:5060

CDRs Registrar

UA 2. Store

Location Database

Register

sip:[email protected]

Store Location

1. Register

3. 200 OK

Registrar

200 OK

1.2.3.4:5060

Figura 2.4

Este cenário demonstra um exemplo de um servidor de registro (registrar), no qual uma mensagem REGISTER contendo o endereço de registro “sip:[email protected]” e o endereço de contato “sip:[email protected]:5060”, em que 1.2.3.4 é o endereço IP do telefone enviado ao servidor de registro, que extrai a informação e a armazena em um banco de dados local. Se tudo correr bem, o servidor de registro envia uma mensagem de resposta 200 OK ao telefone e o processo de registro termina corretamente.

SIP URI \\As

entidades SIP são identificadas utilizando SIP URI (Uniform Resource Identifier);

\\Sintaxe

SIP: username@domain

\\Username: \\Domain:

nome do usuário;

domínio utilizado pelo usuário.

\\Exemplo: \\SIP:

[email protected]

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:

\\Uma

mensagem pode ser:

\\Requisição \\Resposta

do cliente para o servidor;

do servidor para o cliente.

\\As

mensagens podem ser transportadas via UDP ou TCP;

\\Há

dois tipos de mensagens SIP:

\\SIP

Requests:


Mensagens SIP

\\Uma

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

\\SIP

Responses:

\\Quando

um User Agent ou um servidor proxy recebe uma requisição e envia uma resposta.

\\Mensagem \\Linha

de requisição (SIP Request):

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

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

definido como uma Universal Resource Identifier (URI).

\\Identificação

da versão SIP:

\\SIP/2.0. \\São

especificados seis métodos para a versão corrente do SIP:

\\Outros

métodos foram definidos por extensões do SIP.

Mensagens SIP possuem a seguinte estrutura: \\Mensagem

genérica: = linha de início;

\\Cabeçalho

da mensagem;

\\CRLF

(Carrige Return Line Feed);

\\[corpo \\Linha

da mensagem];

de início = linha de requisição / linha de status.

SIP Requests são mensagens enviadas por um Usuário Agente Cliente (UAC) solicitando uma sessão a um Usuário Agente Servidor (UAS). SIP Responses são respostas à solicitação do UAC, podendo ser enviados por servidor proxy ou pelo UAS final.

61


Nas sinalizações telefônicas CAS e CCS era possível identificar a causa da desconexão ou da perda da chamada através de um código. As chamadas desconectadas por Release (REL) no DSS-1, na telefonia (ISUP) ou no Q. SIG possuíam um código numérico indicativo da causa, como por exemplo a causa 16, que significava uma desconexão normal de uma chamada que teve atendimento e bilhetagem. As causas de desconexão estão definidas na recomendação Q.850 do ITU, e discutidas entre as operadoras fixas e móveis no Fórum Nacional de Completamento de Chamadas (FNCC). O H.323 também permite relacionar a causa de liberação do canal de sinalização através da mensagem RealeseComplete (RLC). É possível realizar uma comparação das “SIP Responses” com as causas no H.323, na ISUP e em outras sinalizações. Este acompanhamento é importante para profissionais que administram redes corporativas conectadas com redes públicas, sejam de ISUP, sejam de nova geração (SIP-T, SIP-I, MGCP ou H.248/Megaco). Por exemplo, uma resposta SIP 486, corresponde a uma causa na ISUP/H323/DSS-1 17, com destino ocupado. Para mais informações, consulte a RFC 3398 da IETF e a recomendação Q.850 do ITU. O formato de uma requisição SIP é caracterizado pela utilização de uma linha de requisição como uma linha de início. Cada linha de requisição é formada por um método (tipo de operação de requisição), um endereço e pela identificação da versão SIP utilizada. São especificados seis métodos para a versão corrente do SIP. Porém, outros métodos foram definidos por extensões do SIP. Com relação ao endereço, o formato é definido como uma URI SIP, uma SIPS ou uma URI genérica. Métodos de requisições no SIP/2.0 Método

Funcionalidade

INVITE

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

ACK

Confirma convite do INVITE.

BYE

Termina a sessão multimídia.

CANCEL

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

REGISTER

Registra a informação do contato.

OPTIONS

Faz consulta ao servidor para saber suas capacidades.

Noções sobre o funcionamento de SIP com outras sinalizações: \\INVITE

– corresponde à mensagem Setup no DSS-1/Q.sig/H.323 e à mensagem IAM (mensagem de endereçamento inicial) na ISUP;

\\ACK

– pode corresponder às mensagens Alerting ou Connect no DSS-1/Q. sig/H.323 ou ACM, Call progress ou ANM (atendimento) na ISUP;

\\BYE

– corresponde à mensagem Release (REL) no DSS-1/Q.sig, Releasecomplete (RLC) no H.323 e REL na ISUP;

62

Tabela 2.1

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

\\REGISTER

– semelhante ao procedimento RAS no H.323, e manual nas sinalizações telefônicas;

\\OPTIONS

– não existe correspondente exato nas sinalizações telefônicas.

Métodos de requisições estendidos

Tabela 2.2

Método

RFC

Funcionalidade

INFO

2976

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

MESSAGE

3428

Permite a transferência de mensagens instantâneas.

NOTIFY

3265

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

PRACK

3262

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

PUBLISH

3903

Publica o estado de um evento.

REFER

3515

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

SUBSCRIBE

3265

Permite que se subscreva para um estado particular em um recurso.

UPDATE

3311

Permite a atualização dos parâmetros de uma sessão.


\\CANCEL

A definição dos métodos nas RFCs não impede que muitos pontos continuem vagos, permitindo que fornecedores implementem soluções proprietárias ou até versões diferentes, ainda que a RFC seja atendida. É uma diferença importante entre as RFCs da IETF e as recomendações do ITU, que são extremamente detalhadas, deixando poucas opções para soluções proprietárias distintas, no caso de atendimento da recomendação. Portanto, é necessário cautela na interconexão de redes com fornecedores diferentes. Uma boa sugestão é um teste prévio avaliando a utilização de todos os métodos disponíveis e a compatibilidade entre eles. O mercado tem apresentado diversos casos de perda de funcionalidades com impacto nos custos, quando são utilizados fornecedores diferentes sem um estudo prévio de interfuncionamento e testes das facilidades e métodos.

63


Exemplo de SIP Request INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 195.37.77.100:5060;rport Max-Forwards: 10 From: "jiri" ;tag=76ff7a07-c091-4192-84a0d56e91fe104f To: sip:[email protected] Call-ID: [email protected] 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:[email protected]", 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 “[email protected] SIP/2.0” é chamada de Request URI e contém a URI da pessoa chamada. Um SIP request pode conter um ou mais cabeçalhos Via, que são usados para guardar o endereço dos servidores por onde passa a requisição. Eles são utilizados para o roteamento de SIP Responses (respostas SIP). Esta mensagem INVITE contém apenas um cabeçalho Via criado pelo user agent que enviou a requisição. Sobre o campo Via podemos dizer que o user agent está executando no endereço 195.37.77.100, na porta 5060. Nos campos do cabeçalho To e From identifica-se quem irá receber o convite e de quem está sendo recebida a mensagem para determinada sessão. Também possui um campo Tag que serve como um identificador de diálogo.

Mensagem de resposta (SIP Response) \\Caracterizada

pela utilização de uma linha de status como linha de início,

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

de status numérico;

\\Código

de resultado com três dígitos;

\\Frase \\Muito

64

da versão SIP;

textual.

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

seis classes do tipo SIP Responses:

\\1xx

– Resposta informativa;

\\2xx

– Respostas de sucesso;

\\3xx

– Respostas de redirecionamento;

\\4xx

– Respostas de falha de requisição;

\\5xx

– Respostas de falha em servidor;

\\6xx

– Respostas de falha global.


\\Existem

A mensagem SIP Response é composta de Versão do SIP (SIP Version), Código de estado (Status code) e Motivo (Reason phrase): \\Versão

do SIP – 2.0 (atual);

\\Status

code – informacional, Sucesso, Erro no Cliente ou Falha Global;

\\Reason

phrase – frase resumida explicando o significado do código de estado, podendo ser uma informação ou uma resposta final.

Exemplos: \\SIP

2.0 – 486 – busy here ou destino ocupado; neste caso é uma resposta final, já que o destino não está disponível;

\\SIP

2.0 – 180 – ringing ou chamando; neste caso não é uma resposta final, apenas um aviso para a origem de que a chamada está em processo de recebimento pelo destino.

Conforme foi visto, quando existe interfuncionamento com outras sinalizações, é necessário estar atento à correspondência entre as mensagens de resposta SIP e as mensagens com causa nas outras sinalizações. No primeiro exemplo, a mensagem “SIP 2.0 – 486 – usuário ocupado” corresponde à mensagem RLC (17) no H.323, e REL (17) na ISUP e no DSSI. Já no segundo exemplo, a mensagem “SIP 2.0 – 180 – chamado” corresponde à mensagem alerting no H.323 e no DSS-1, e à mensagem ACM (mensagem de endereço completo) na ISUP. 1xx Respostas provisórias, que dizem ao receptor que a requisição feita foi recebida, mas o resultado ainda está em processo. 2xx Respostas finais de sucesso, que o originador da requisição sempre receberá. Também terminam transações.

65


3xx Respostas usadas para redirecionamento do chamador. Fornecem informações sobre a nova direção do usuário ou sobre um serviço alternativo que o chamador precisa usar para satisfazer a ligação. 4xx Resposta de falha de requisição, utilizada para indicar que houve erro da parte de quem enviou a requisição, erro na sintaxe ou devido ao mau preenchimento pelo servidor. 5xx Resposta de falha no servidor, utilizada para indicar erro da parte do servidor. 6xx Resposta de falha global, indicando que a resposta não pode ser completada em nenhum servidor. Exemplo: Informational 100 180 181 182 183

Trying Ringing Call forwarded Queued Session Progress

Success 200 OK

Redirection 300 301 302 380

Multiple Choices Moved Perm. Moved Temp. Alternative Serv.

500 501 503 504

Request Failure 400 401 403 404 405 415 420 486

Bad Request Unauthorized Forbidden Not Found Bad Method Unsupp. Content Bad Extencions Busy Here

Server Error Not Implemented Unavailable Timeout

Server Failure

600 603 604 606

Busy Everwhe Decline Doesn’t Exist Not Acceptable

Global Failure

\\1xx

– informativo, pedido recebido, sessão em progresso;

\\2xx

– sucesso, ação recebida, entendida e aceita com sucesso;

\\3xx

– Rrdirecionamento, ação adicional deve ser tomada para completar a sessão;

\\4xx

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

\\5xx

– erro de servidor (os motivos são listados);

\\6xx

– falha global (os motivos são listados);

No caso de interfuncionamento via gateway com redes telefônicas (ISUP) é necessário estar atento à RFC 3398. As mensagens de respostas SIP são parcialmente baseadas no HTTP.

66

Figura 2.5

\\SIP/2.0

200 OK Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68 From: sip:[email protected] To: sip:[email protected];tagi=794fe65c16edfdf45da4fc39a5d2867c.b713 Call-ID: [email protected] CSeqi: 63629 REGISTER Contact: Msip:[email protected]:5060;transport=udp>;q=0.00;expi res=120 Server: Sip EXpress router (0.8.11pre21xrc (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 “Noisy feedback tells: pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org out_uri=sip:iptel.org via_cnt==1”

\\Cabeçalho


Exemplo de SIP Response

da mensagem:

\\Sequência

estruturada de campos de cabeçalho (header fields) após a linha

de início; \\Semelhantes \\Podem

aos campos do cabeçalho das mensagens HTTP;

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

por: do parâmetro

\\ = \\Valor

do parâmetro

\\Exemplo: \\Contact:

;expires=3600

Este exemplo de SIP Response mostra que as respostas são bem similares às requisições, exceto na primeira linha, que contém a versão do protocolo (SIP/2.0), o código da resposta e a frase textual. Os códigos têm a intenção de serem 67


processados pelas máquinas, não sendo muito amigáveis aos humanos, mas facilitando para que as máquinas façam o parse deles. Já a frase textual é legível aos humanos, descrevendo o resultado do processo. \\As

mensagens SIP são codificadas usando a sintaxe HTTP v1 (RFC 2068);

\\Todas

as solicitações de um usuário que deseja estabelecer uma sessão (por exemplo uma chamada telefônica) são chamadas de Requisição. Uma Requisição deve obrigatoriamente ter uma resposta, como a mensagem 486 (destino ocupado). Neste caso é uma resposta final, já que o destino está ocupado.

Alguns campos podem estar nas mensagens de requisição e de respostas. Neste caso, são partes do cabeçalho único. Caso o tempo definido por ‘expires’ não seja suficiente, um proxy pode rejeitar a mensagem, informando o seu tempo, e o UAC enviará uma nova mensagem com a nova temporização. Caso isso não ocorra, a mensagem ficaria presa no proxy aguardando tratamento, e a sessão seria encerrada por estouro de temporização (session expires). Exemplo: se uma mensagem chegar a um proxy com “expires=50” e o tempo de espera é de 3600, o proxy poderá enviar uma resposta solicitando a alteração do campo “expires=50” para “expires=3600”. Neste caso o UAC enviará um novo INVITE com o parâmetro alterado. Alguns campos do cabeçalho Via

Contact

To

Max-Forwards

From

Content-Type

Call-ID

Content-Length

CSeq ou Command Sequence Obs.: Descrição completa dos campos que compõem o cabeçalho na RFC 3261, sessão 20. \\Via

– indica o endereço para o qual a requisição deve seguir e o endereço que as respostas devem tomar no momento da volta no roteamento das mensagens;

\\To

– especifica o destinatário que deve receber a requisição;

\\From

– indica quem irá fazer a requisição;

\\Call-ID

– informa o identificador único específico para uma sessão;

\\Command

Sequence (Cseq) – ordena transações dentro de um diálogo, para prover uma identificação única das transações e diferenciar entre novas requisições e retransmissões de requisições;

68

Tabela 2.3

– provê uma URI em que o significado depende do tipo de requisição ou de resposta em que está. Pode conter o nickname de um usuário, uma URI com parâmetros e parâmetros do cabeçalho;

\\Max-Forwards

– serve para limitar o número de proxies ou gateways que podem enviar requisições para um próximo servidor;

\\Content-Type

– contém a descrição do corpo da mensagem, indicando o tipo de mídia do corpo da mensagem enviada ao destinatário;

\\Content-Length


\\Contact

– indica o tamanho do corpo da mensagem.

Campos gerais

Campos para requisições

Campos para respostas

Campos para entidades

Accept

Authorization

Authorization-Info

Allow

AcceptEncding

Hide

Error-Info

Content-Disposition

AcceptLanguage

In-Reply-To

Min-Expires

Content-Encoding

Alert-Info

Max-Forwards

Proxy-Authenticate

Content-Language

Call-ID

Priority

Retry-After

Content-Length

Call-Info

ProxyAuthorization

Server

Content-Type

Contact

Proxy-Require

Unsupported

Expires

Cseq

Route

Warning

Date

Subject

WWWAuthenticate

Encryption

Response-Key

From MIME-Version Organization Record-Route Reply-To Require Supported Tabela 2.4 Categoria dos campos

Timestamp To

69


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;

\\Campos

para requisições – específicos para requisições, possibilitando prover informações adicionais para o servidor a respeito da própria requisição ou do cliente;

\\Campos

para respostas – específicos para mensagens de resposta, oferecendo mais informações sobre o status indicado nessas mensagens;

\\Campos

para entidades – indicam o tipo e o formato das informações presentes no corpo da mensagem, possibilitando que a aplicação apropriada para tratar a informação seja executada.

Exemplo de fluxo de mensagens: Atlanta.com proxy

Biloxi.com proxy

Alice softfone

Bob SIP Phone Invite F1 100 Trying F3

Invite F2 100 Trying F5 180 Ringing F7

180 Ringing F8

Invite F4 180 Ringing F6 200 OK F9

200 OK F10 200 OK F11 ACK F12 Sessão de mídia Bye F13 200 OK F14

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

Figura 2.6


servidor de DNS para encontrar o servidor SIP que serve ao domínio “biloxi.com”. Como resultado, este obtém o endereço IP do servidor proxy “biloxi.com” e envia a requisição INVITE para lá. Antes de enviar a requisição, o servidor proxy “atlanta. com” inclui um campo Via adicional, que contém seu próprio endereço. O servidor proxy “biloxy.com” recebe a requisição INVITE e responde com 100 (trying) ao servidor proxy “atlanta.com”, indicando que recebeu a requisição INVITE e a está processando. O servidor proxy consulta o banco de dados, geralmente chamado de “location service”, que contém o endereço IP atual do Bob. O servidor proxy “biloxi. com” adiciona outro campo Via no cabeçalho com o seu endereço para a requisição INVITE, e a envia ao telefone SIP do Bob. O telefone SIP do Bob recebe a requisição INVITE e alerta ao Bob que existe uma chamada de Alice, indicando essa ação com uma mensagem de resposta 180 (ringing), que é roteada pelos dois proxies na direção reversa. Cada proxy utiliza o campo Via do cabeçalho para saber para onde enviar a resposta, depois disso eliminado-as do topo da mensagem. Quando o softphone da Alice recebe a resposta 180 (ringing), a informação é passada para Alice, talvez utilizando tom de áudio “ringback” ou mostrando uma mensagem na tela do softphone dela. Quando Bob atende à ligação, o seu telefone SIP envia uma mensagem 200 (OK) para indicar que a ligação foi atendida. A mensagem 200 (OK) contém o corpo da mensagem juntamente com a descrição de mídia SDP (Session Description Protocol) do tipo de sessão que Bob está esperando estabelecer com Alice. Se Bob não atendesse à chamada, uma mensagem de erro seria retornada em vez da mensagem 200 (OK), e a sessão de mídia não existiria.

Protocolo SDP \\Session

Description Protocol (SDP):

\\Definido

pela RFC 2327;

\\Utilizado

para descrever sessões;

\\Especifica

apenas o formato para a descrição das informações trocadas entre entidades SIP.

\\Mídia

a ser utilizada;

\\Informações \\Padrão

para a transmissão da mídia:

do codec;

\\Protocolo \\Para

de controle para transmissão.

a mídia, o SDP inclui as seguintes informações:

\\Tipo

de mídia (vídeo, áudio);

\\Protocolo \\Formato

de transporte (RTP / UDP / IP, H.320);

da mídia (H.261 vídeo, MPEG vídeo).

71


\\As

mensagens SDP podem ser transportadas mediante diferentes protocolos:

\\SIP; \\SAP; \\RTSP; \\Correio

eletrônico com aplicações MIME ou protocolos como HTTP.

Session Description Protocol (SDP) ou Protocolo de Descrição de Sessão é um formato para a descrição dos parâmetros de inicialização de mídia streaming (conteúdo visto ou ouvido durante um envio de dados). Foi publicado pela IETF como RFC 2327 e substituído pela RFC 4566. Durante o processo de estabelecimento de uma sessão, é necessário negociar a mídia a ser utilizada (voz, vídeo ou dados) e as respectivas informações para a transmissão da mesma, como o padrão do codec e o protocolo de controle para transmissão. Enquanto o SIP especifica o processo para o anúncio da descrição das informações de uma sessão, o SDP especifica apenas o formato para descrição das informações. No campo mídia, o SDP usa um código para listar os codecs que poderão ser utilizados na sessão. Os códigos correspondentes aos codecs para os diversos tipos de mídia são detalhados na RFC 3551. m=áudio 3456 RTP/AVP 0, 3, 4 e 5 (0=PCM G711, 3=GSM, 4=G.723 e 5=DVI4) Neste caso a mídia é áudio, utiliza a porta UDP 3456, perfil “áudio e vídeo” e aceita os codecs 0, 3, 4 e 5. Para identificar os codecs é necessário consultar a RFC 3551. As mensagens SDP podem ser utilizadas para conexões ponto a ponto ou 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

a portabilidade;

\\Permite

uma variedade de formas de transporte;

\\Possibilita

que ferramentas baseadas em texto possam gerar e processar as descrições das sessões: \\Codificação

72

UTF-8;

dos campos e atributos restritos ao subconjunto US-ASCII do UTF-8;

\\Campos

textuais e valores dos atributos podem utilizar todo o conjunto de caracteres do UTF-8.

\\Uma

mensagem SDP é composta por uma série de linhas denominadas campos:

\\Os \\A

nomes são abreviados por uma só letra;

formatação das linhas de texto está descrita da seguinte forma:

\\Tipo \\A


\\Nomes

do campo = valor do campo.

descrição de uma sessão consiste de:

\\Descrição

do nível de sessão:

\\Detalha

informações que devem ser aplicadas à sessão como um todo e a todos os fluxos de mídia.

\\Zero

ou mais descrições do nível de mídia:

\\Detalha

informações que devem ser aplicadas a um fluxo de mídia específico.

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

Tabela 2.5 Descrição da sessão

Tipo do campo

Valor do campo

Presença obrigatória

v

Versão do protocolo

Sim

o

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

Sim

s

Nome da sessão

Sim

i

Informação sobre a sessão

Não

u

URI da descrição

Não

e

Endereço de e-mail

Não

p

Número do telefone

Não

c

Informação sobre a conexão

Não

b

Informação sobre largura de banda

Não

Uma ou mais descrições de horário

Sim

z

Ajustes do time zone

Não

k

Chave de encriptação

Não

73


Tipo do campo

Valor do campo


a

Zero ou mais linhas de atributo da sessão

Não

Zero ou mais descrições de mídia

Não

O SDP é um protocolo que permite fácil leitura. Portanto, em uma missão crítica é necessária a criptografia e a autenticação de suas informações. O processo de proteção para o protocolo SDP é definido no cabeçalho SIP, no campo Encryption. O SDP utiliza caracteres ASCII e pode utilizar textos livres como informativos. A chave de criptografia utilizada neste protocolo para os canais de mídia é definida na RFC 2327. O processo de criptografia e autenticação poderá ser UAC-UAS ou Proxy-UAS. Tipo do campo

Valor do campo


t

Horário em que a sessão está ativa

Sim

r

Zero ou mais horários repetidos

Não

Tipo do campo

Valor do campo


m

Nome da mídia e endereço de transporte

Sim

i

Título da mídia

Não

c

Informação sobre a conexão

Não

b

Informação sobre a largura de banda

Não

k

Chave de encriptação

Não

a

Zero ou mais linhas de atributo da mídia

Não

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

Tabela 2.6 Descrição do horário

Tabela 2.7 Descrição da mídia

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

\\V

– versão;

\\o

– originador, ID sessão, versão, tipo de rede, tipo de endereço, endereço;

\\s

– nome da sessão;

\\u

– URI de descrição;

\\c

– informação sobre a conexão;

\\t

– tempo que a sessão está ativa (tempo de início e tempo de parada, em segundos);


Exemplo de Sessão SDP

\\m

– nome da mídia, endereço de transporte (porta), padrão (RTP/Áudio e vídeo), tipos de codecs aceitos (RFC 3551);

\\a

– outros atributos sobre mídia, tais como modulação, portas UDP e codec.

Modos de comunicação SIP \\Existem

dois modos de comunicação:

\\Modo

direto:

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

que um agente SIP envie requisições para outro agente.

indireto:

\\Via

servidor proxy;

\\Normalmente

requer a presença de outros servidores de apoio que integram a infraestrutura de um sistema de telefonia baseado em SIP.

\\Modo

direto – quando um cliente SIP já conhece o endereço do telefone SIP de interesse. Assim, é possível chamar diretamente para um número IP;

75


\\Modo

indireto – quando é necessário um servidor que conheça o endereço IP do usuário de interesse. Assim, as ligações precisam de um servidor proxy para alcançarem seus destinos.

Comunicação peer-to-peer (Protocolo SDP) Agente A

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

1. Invite – mensagem de requisição com todos os dados da origem para a conexão; 2. 180 ringing – mensagem informativa de que o destino está recebendo chamada; 3. 200 OK – mensagem final de que o destino atendeu, com o campo SDP definindo as mídias; 4. ACK – resposta a uma mensagem final, que só existe para a mensagem 200 OK, confirmando as mídias; 5. Mudança de mídia pode ser realizada por “re-invites”, ou seja, novos invites na sessão; 6. Voz (RTP) – troca de streams de áudio utilizando os protocolos RTP/RTCP; 7. BYE – requisição de desconexão pelo destino. Na telefonia tradicional PCM/TDM, a desconexão pelo destino temporiza no ponto de bilhetagem por 90 segundos. Aqui não existe nenhuma temporização, pois a desconexão é imediata; 8. 200 OK – mensagem final, em resposta a uma requisição de desconexão.

76

Figura 2.7

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 To:Claudio Call-ID:12345@proxy. unb.br Cseq:2 INVITE Subject: Projeto fone@ RNP Contact: Record-Route: , ...

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 To:Claudio Call-ID:12345@proxy. unb.br Cseq:2 INVITE Subject: Projeto fone@ RNP Contact: Record-Route: , ...

ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP Proxy.unb.br From: Daniel sip:[email protected] Call-ID: 12345@proxy. unb.br Cseq: 2 INVITE Subjet: Projeto fone@RNP Contact: sip:daniel@ proxy.unb.br Route: , ...

Requisição INVITE recebida pelo agente servidor

Conteúdo da resposta 100 Trying enviada pelo agente servidor

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

\\INVITE


Comunicação via proxy

SIP – destino, versão 2.0.;

\\Via

– campo que marca o trajeto da mensagem e para onde a resposta ser enviada. O objetivo é indicar o caminha de volta. Facilita o controle da chamada, evita loops e auxilia a bilhetagem;

\\Branch=4

– campo utilizado para identificar a transação, inserido pela rede;

\\Record-Route

– cabeçalho utilizado pelos proxies, que precisa estar no caminho da sinalização durante todo o tempo da chamada, para fins de bilhetagem, por exemplo;

\\Maddr

– utilizado para comunicação multicast;

\\SIP

2.0 Trying – mensagem informativa e provisória em resposta ao INVITE. Equivalente à chamada em progresso;

\\Outros

parâmetros são similares ao INVITE;

Note que o campo Route da mensagem ACK é construído com base no campo Record-Route da mensagem TRYING. Veja os detalhes na RFC 3261.

77


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

Transactions:

\\Sequência \\Inclui

zero ou mais respostas provisórias e uma ou mais respostas finais;

\\Consiste \\Uma

de: requisição;

\\Várias \\Entidades \\SIP

de mensagens trocada entre os elementos de uma rede SIP;

respostas para a requisição feita.

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

Dialogs:

\\Sequência

de transações;

\\Representa

uma relação SIP P2P (peer-to-peer) entre dois user agents;

\\Facilita

o sequenciamento e o roteamento das mensagens entre os terminais SIP;

\\São

identificados por Call-ID, From tag, To tag;

\\Possuem

esses campos com o mesmo valor quando pertencem ao mesmo

diálogo.

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

78


Exemplo: Primeira transação

Invite 100 Trying 200 OK ACK

Bye 200 OK Segunda transação

Figura 2.8

Cliente

Servidor

1. INVITE – contém as informações de origem e destino (no H.323 são as informações contidas na mensagem setup) e o campo SDP com as informações de mídia (no H.323 são as informações H.245); 2. 100 Trying – chamada em progresso (na ISUP seria a mensagem Call Progress); 3. 200 OK – mensagem final de atendimento; 4. ACK – confirmação da mensagem e das mídias a serem utilizadas; 5. BYE – requisição de desconexão; 6. 200 OK – requisição aceita. Note que neste exemplo não foi enviada a mensagem RINGING.

Cenários SIP \\Alguns

cenários SIP:

\\Registration; \\Session

Invitation;

\\Session

Termination;

\\Instant

Messages.

\\Registration

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

79


\\Session

Invitation – usuário Agente Cliente (UAC) solicita o estabelecimento de uma sessão a um Usuário Agente Servidor (UAS);

\\Session

Termination – término da sessão por iniciativa do UAS ou UAC, por temporização, destino não acessível, congestionamento na rede etc.;

\\Instant

Messages – durante uma sessão, UAC e UAS podem enviar mensagens sem encerrar a sessão.

SIP Registration \\Tem

a finalidade de registrar um user agent;

\\Se

não houver registro, usuários com intenção de se comunicar não poderão se comunicar;

\\Um

registro compreende:

\\Mensagem

REGISTER enviada pelo user agent;

\\Mensagem

200 OK enviada pelo servidor de registro, se o registro for bem-sucedido;

\\Mensagem

407 em caso contrário.

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

80

Agente A

Servidor de proxy

Servidor de registro

REGISTER sip:registrar.bsb.com.br SIP/2.0 Via: SIP/2.0/UDP cxo.bsb.com.br

1. Register

From: To:

2. 100 Trying

Call-ID: [email protected]

3. Register

Cseq : 1 REGISTER


Exemplo:

Contact:

4. 200 OK 5. 200 OK

Expire: 3600

Figura 2.9

Content-Length: 0

1. O cliente solicita o registro; 2. Servidor proxy repassa a solicitação de registo para o servidor de registro; 3. Servidor de registro verifica os dados e autentica ou nega a autenticação; 4. Neste exemplo, o registro foi aceito e confirmado pela mensagem 200 OK.

Session Invitation \\Consiste \\O

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

proxy imediatamente envia uma resposta com a mensagem 100 Trying;

\\Finalidade: \\Todas

acabar com as retransmissões;

as respostas geradas pelo UA chamado são devolvidas ao UA chamador.

O convite (Invitation) talvez seja a mensagem mais comum no SIP, e deve ser respondido imediatamente com um “100 Trying” para indicar ao chamador que o convite foi recebido e está sendo tratado. Chamador

Servidor proxy

Chamado

1. Invite 2. 100 Trying

3. Invite 4. 100 Trying 5. 180 Ringing

6. 180 Ringing 7. 200 OK 8. 200 OK 9. ACK RTP Streams

Figura 2.10 81


1. Como o chamador geralmente não tem a informação do endereço de destino, solicita ao servidor proxy o encaminhamento da requisição INVITE para o chamado; 2. O servidor proxy envia mensagem informativa de chamada em progresso, indicando que está tratando a chamada; 3. O servidor localiza o endereço do destino e envia o INVITE. O servidor poderia ter vários endereços do destino, caso em que seriam enviados diversos INVITES, um para cada destino; 4. O usuário chamado envia ao servidor a informação de que está processando a chamada (100 Trying); 5. Na sequência, informa para o proxy que o telefone está chamando e aguardando atendimento; 6. O servidor proxy repassa ao chamador a informação de que o destino está recebendo (Ring). Neste momento, o telefone do chamador começa a tocar; 7. O atendimento acontece e a mensagem 200 OK é enviada ao proxy; 8. O proxy envia para o chamador a resposta 200 OK, para que retire o tom de controle e abra os canais de áudio RTP/RTCP; 9. Uma última confirmação é enviada do chamador para o chamado através da mensagem ACK; 10. É dado o início ao transporte da mídia, voz ou vídeo.

Session Termination \\Tem

a finalidade de terminar uma sessão;

\\Possui

dois tipos de término de sessão:

\\Direta; \\Envia

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

\\Via

proxy.

Assim como o INVITE, a terminação da chamada pode ser realizada de forma direta ou indireta, ou seja, a mensagem utilizada para desconexão da chamada (BYE) pode ser enviada diretamente para o usuário na outra ponta da chamada ou através do proxy. Em ambientes em que é necessário ter controle total das chamadas, por exemplo para fins de bilhetagem (cobrança das chamadas), é imprescindível que o BYE seja enviado para o proxy, para que este possa registrar o final das chamadas.

82

UA1

SIP proxy

UA2

1. BYE Forma direta

2. 200 OK


Exemplo:

1. Bye 2. Bye Forma indireta

Figura 2.11

3. 200 OK

4. 200 OK

A figura ilustra duas situações de como pode ocorrer o término de uma sessão. A primeira mostra a forma direta, na qual os dois users agents negociam o término da sessão diretamente. A segunda mostra a forma indireta, onde um SIP proxy está no meio da comunicação entre os dois clientes, roteando as mensagens.

Instant Messages (IM) \\Instant

Messages são enviadas utilizando requisições do tipo MESSAGE;

\\Mensagens \\O

deste tipo não estabelecem diálogos;

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

UA1

SIP proxy 1. Message

UA2

2. Message

3. 200 OK 4. 200 OK 6. Message

5. Message

7. 200 OK

Figura 2.12

8. 200 OK

Segundo a figura, UA1 envia mensagem para o proxy, pois não possui o endereço de UA2 ou por programação da rede, para que o proxy tenha o controle da chamada. \\O

envio das mensagens instantâneas está definido na RFC 3428.

83

84


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

do servidor OpenSER.

\\Análise

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.



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


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: Domain Proxy:


Atividade 2 – Captura e identificação da troca de mensagens entre os clientes SIP e o 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: Display Name: Entre com o seu nome completo User ID: 30XX Password: voip Register Expires: 3600

Passo 4: volte para a máquina virtual e certifique-se de que os clientes foram registrados visualizando a lista de peers no OpenSER, utilizando o comando: # openserctl ul show

Passo 5: encerre o X-Lite. Inicie o Wireshark com modo promíscuo desabilitado e insira um filtro para o protocolo SIP. Reinicie o X-Lite novamente, usando a nova configuração, e observe a autenticação do cliente com o servidor. No término da autenticação, pare e salve a captura de pacotes como registrando.pcap. Passo 6: no Wireshark, abra o arquivo salvo registrando.pcap. Com base nas informações capturadas, responda ao questionário abaixo: 1. Sobre qual protocolo de transporte o protocolo SIP trafega na rede?

2. Quais as portas de comunicação entre cliente SIP e gatekeeper?

87


3. Detalhe o Status-Line do protocolo SIP e informe a sua versão.

4. Em Status-Code, informe a sequência obtida durante a autenticação.

5. Durante o processo de autenticação entre cliente e servidor, qual o comportamento observado?

Passo 7: crie uma tabela de estatística utilizando o Wireshark, clique em Statistics>SIP e em seguida em Create Stat, e preencha o quadro abaixo de acordo com o resultado obtido na captura.

Figura 2.14

88

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.


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

Passo 2: no Wireshark abra o arquivo ligando.pcap, acesse o menu Statistics e em seguida selecione a opção Flow Graph. Com as informações exibidas, responda ao questionário a seguir: 1. Quais os endereços de origem e destino durante a ligação?

2. Por que a primeira requisição INVITE foi negada?

3. Qual a sequência de pacotes durante o encerramento de uma ligação?

89


Atividade 4 – Decodificando os pacotes capturados para escutar a conversa entre os clientes Inicie o Wireshark, abra o arquivo ligando.pcap, acesse o menu Statistics e em seguida selecione VoIP Calls. Selecione a captura e execute o Player, conforme ilustra a figura a seguir. Em seguida será exibida uma tela onde deverá ser executado o Decode. A partir deste instante escutaremos a conversa realizada entre os clientes.

Figura 2.15 Na tela a seguir você poderá selecionar o canal que escutará ou ambos os canais.

Figura 2.16 1. Quais as opções de codecs anunciadas?

90


2. Existem mensagens provisórias antes de 200 OK?

3. Qual o codec de áudio utilizado durante a ligação?

4. Qual a porta utilizada para o transporte de áudio?

91

92

3 Recomendação H.323 ►►

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

93


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

é uma série de recomendações produzidas pelo ITU-T para sistemas de conferência audiovisual;

\\As

recomendações são projetadas para:

\\Permitir

interoperabilidade entre elas;

\\Possibilitar

que usuários de sistemas de conferências possam se comunicar e usar diferentes tecnologias de rede.

\\Outras

recomendações:

\\H.310,

para conferências sobre RDSI-FL;

\\H.320,

para conferências sobre RDSI-FE;

\\H.322,

para conferências sobre LANs que proveem garantias de QoS;

\\H.324,

para conferências sobre RTPC.

\\Provê

suporte a:

\\Conferências

ponto-a-ponto e multiponto:

\\Chamadas

H.323 podem ser estabelecidas entre dois ou mais usuários.

\\Heterogeneidade: \\Um

equipamento em um sistema H.323 deve dar suporte obrigatório à comunicação de áudio.

\\Contabilidade

e gerência:

\\Chamadas

H.323 podem ser bloqueadas com base no número de chamadas já estabelecidas, limitações na banda ou restrições de tempo.

\\Provê

suporte a:

\\Segurança: \\Suporte

à autenticação de usuários e para a privacidade e não-repúdio de dados trocados entre eles.

\\Serviços \\Permite

suplementares; a elaboração e o desenvolvimento de serviços adicionais.

O protocolo H.323 teve seu desenvolvimento iniciado pelo ITU na década de 90 e ao longo do período foram desenvolvidas diversas versões. \\V.1

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

\\V.2

– melhoramento da V.1, introduzia as facilidades Fast Connect, Tunelamento e Overlap;

\\V.3

– permitia escolha de língua, serviços suplementares até 450.7;

\\V.4

– introdução de serviços suplementares 450.8 a 450.11, possibilidade de gatekeeper alternativo, tunelamento Q.SIG e ISUP, URL, capacidade de chamadas pré-pagas, DTMF via RTP;

\\V.5

94

– tunelamento DSS-1, Série 460.x (portabilidade, status do enlace etc.);

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

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

de usuários;

\\Localização \\Largura

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

de banda e escolha de codecs;

\\Controle

de chamadas, conexão e desconexão;

\\Conferências \\Banco

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

\\V.6

multimídia centralizadas e descentralizadas;

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;

\\Autenticação

de mensagens.

Grande parte das aplicações de segurança são proprietárias, dificultando o interfuncionamento com redes de fornecedores diferentes, sendo um ponto impactante nos projetos que necessitam de segurança pela sua criticidade.

Serviços suplementares e adicionais Os serviços suplementares definidos nas recomendações são limitados. Para suprir as necessidades do mercado, algumas empresas desenvolvem serviços adicionais na maioria das vezes proprietários, sendo outro fator impactante a considerar no caso de redes com diversos fornecedores. Principais serviços suplementares: \\450.2

(Call Transfer) – transferência de chamadas;

\\450.3

(Call Diversion) – desvio de chamada;

95


\\450.4

(Call Hold) – retenção de chamada;

\\450.5

(Call Park e Call Pickup) – retenção e retomada;

\\450.6

(Call Waiting) – chamada em espera;

\\450.7

(Message Call Waiting) – mensagem de chamada em espera;

\\450.8

(Call Completion) – procedimentos no caso de ocupado;

\\450.9

(Display) – também conhecido por bina, permite exibir no telefone de destino o número do chamador;

\\450.10

(Call Intrusion) – intrusão na chamada.

Componentes da arquitetura H.323 \\Terminais: \\Podem

ser um telefone IP ou uma aplicação executada em um computador com recursos multimídia.

\\Gateways: \\São

necessários no momento em que dois terminais desejam estabelecer comunicação entre diferentes tipos de rede.

\\Gatekeeper

(GK):

\\Normalmente \\Multipoint

utilizado para controlar acesso às redes de comunicação.

Control Unit (MCU):

\\Realiza

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

Intranet/Intranet

ISDN H.320

H.323 Terminal H.323 Gatekeeper

PSTN H.324

H.323 Gateway

ATM H.310. H.321

H.323 MCU

H.323 Terminal Internet/Intranet SIP

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

de nomes;

\\Identificação

96

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

Figura 3.1

de controle de chamadas;

\\Mobilidade

pessoal.

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


\\Realização

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.

97


A MCU é formada por dois elementos básicos: \\O

Controlador Multiponto (MC), parte obrigatória da MCU, é responsável pela negociação do protocolo H.245 para determinação das características de áudio e vídeo dos terminais. Se houver algum participante utilizando transmissão multicast, o MC também fica responsável por este controle;

\\O

Processador Multiponto (MP), parte opcional da MCU, trata os fluxos de áudio, vídeo e dados de uma conferência. Os fluxos de mídia não passam pelo MC.

Padrões

Descrição

T.38 T.120 V.150.1

Transporte de dados (texto, imagem, fax, sinais de modem)

RTP RTCP (IETF)

Transporte de áudio e vídeo

H.245 H.225.0

Protocolos de controle e sinalização

H.246 H.248

Interoperabilidade com redes telefônicas comutadas por circuitos

H.235

Segurança em sistemas baseados no protocolo de controle H.245

H.450.x

Serviços suplementares

H.460.x

Extensões aos serviços de sinalização do protocolo H.255.0

H.501 H.510 H.530

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:

\\T.120

(ITU T.120);

\\Padrão

para intercâmbio de dados (textos e imagens estáticas);

\\Depende

de um conjunto de outros padrões e recomendações: T.122, T.124, T.125, T.126 e T.127.

\\Áudio

e vídeo:

\\Protocolos

98

RTP e RTCP.

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


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.

três padrões de protocolos utilizados para controle e sinalização:

\\H.225.0; \\H.225.0

RAS;

\\H.245. \\O

protocolo H.225.0 é utilizado para o estabelecimento de chamada entre dois dispositivos H.323.

\\O

protocolo H.225.0 RAS é utilizado com um gatekeeper para controle de admissão e resolução de endereços.

\\O

protocolo H.245, por sua vez, é utilizado para controlar a comunicação entre os dispositivos.

\\O

padrão H.225.0 RAS utiliza a porta TCP 1718 para conexões multicast e a porta TCP 1719 para conexões unicast.

\\O

padrão H.225 Q.931 utiliza a porta TCP 1920.

\\O

padrão H.245 utiliza portas TCP dinâmicas.

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

de chamadas:

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

\\O

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

\\Mensagens

de sinalização H.225.0:

\\Estabelecimento

de chamadas:

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

99


\\Connect. \\Encerramento

de chamadas:

\\ReleaseComplete. \\Outros: \\Status/StatusEnquiry; \\Facility.

O protocolo Q.931 é utilizado para estabelecer o canal de sinalização. A seguir suas principais mensagens: \\Setup

(M) – mensagem enviada com a finalidade de estabelecer uma conexão, podendo ser enviada diretamente do terminal de origem para o terminal ou gatekeeper de destino, ou via gatekeeper;

\\Call

proceding (O) – mensagem enviada pelo destino informando que todos os dados relativos à chamada foram recebidos e nenhuma informação adicional será aceita;

\\Information

(O) – mensagem enviada pela origem com informações complementares, por exemplo, para envio de dígitos por OverLap após a mensagem Setup;

\\Alerting

(M) – mensagem enviada do destino para a origem, indicando que o terminal de destino está iniciando o toque de campainha e que o terminal de origem deve iniciar o envio do tom de controle da chamada;

\\Connect

(M) – mensagem enviada pelo destino informando que a chamada foi aceita pelo usuário chamado;

\\Release

Complete (M) – mensagem enviada pela origem ou pelo destino informando que a chamada foi desconectada e que o canal está livre;

\\Status

(M) – mensagem enviada em ambas as direções para relatar condições de erro;

\\Notify

(O) – mensagem enviada em ambos os sentidos com informações sobre uma chamada, tal como usuário suspenso;

\\Progress

(O) – mensagem enviada para a origem para indicar inter-funcionamento;

\\Facility

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

Tipos de mensagens: \\M

(mandatório);

\\O

(Opcional);

\\Mensagens

restantes (F) não são utilizadas no H.323.

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

100

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

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

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

\\Register

(Ack/Rej) – registro de um evento;

\\Notify

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

Mensagens RAS \\Registro, \\As

Admissão e Status;

funções de RAS (Registration Admission Status) incluem:

\\Descoberta \\Registro

de gatekeepers;


\\Retrieve

de pontos finais;

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

de pontos finais;

de banda e notificação de estado.

H.225.0 RAS:

\\Descoberta: \\GRQ

(GatekeeperReQuest);

\\GCF

(GatekeeperConFirm);

\\GRJ

(GatekeeperReJect).

\\Registro: \\RRQ

(RegistrationReQuest);

\\RCF

(RegistrationConfirm);

\\RRJ

(RegistrationReJect);

\\URQ

(UnRegistrationReQuest);

\\UCF

(UnRegistrationConfirm);

\\URJ

(UnRegistrationReJect).

\\Mensagens

H.225.0 RAS:

\\Localização: \\LRQ

(LocationReQuest);

\\LCF

(LocationConFirm);

\\LRJ

(LocationReJect).

\\Controle

de admissão:

\\ARQ

(AdmissionReQuest);

\\ACF

(AdmissionConfirm);

\\ARJ

(AdmissionReject).

\\Alteração

de banda:

\\BRQ

(BandwidthReQuest);

\\BCF

(BandwidthConfirm);

\\BRJ

(BandwidthReject).

101


\\Mensagens

H.225.0 RAS;

\\Informação

de estado:

\\IRQ

(InfoReQuest);

\\IRR

(InfoReQuestResponse);

\\IACK

(InfoReQuestAck);

\\INAK

(InfoReQuestNak).

\\Desengajamento: \\DRQ

(DisengageReQuest);

\\DCF

(DisengageConfirm);

\\DRJ

(DisengageReject).

As mensagens RAS podem ser trocadas entre os terminais e o GW, entre GW e GK ou entre terminais e GK, dependendo da configuração da rede. \\GK

Discovery (Descobrindo GK) – processo utilizado pelo terminal ou GW para descobrir o seu GK: o terminal envia mensagem GRQ (GatekeeperRequest), onde um ou mais GKs podem responder com as mensagens GCF ou GRJ. O GK procurado responde com GCF e os demais respondem com GRJ; para as demais mensagens o procedimento é semelhante.

\\GW

Registration (Registrando no GK) – executado após o terminal identificar o seu GK; o terminal envia mensagem RRQ (RegistrationRequest) para o GK, e a mensagem RRQ deve possuir o endereço e o pseudônimo a ser registrado. Caso não seja especificado, o GK adicionará um na mensagem RCF. O GK pode a qualquer momento cancelar a RRQ.

\\Location

Request (Localizando GK) – executado quando um GK deseja descobrir o GK que controla o terminal de destino, e envia a mensagem LRQ para os GKs mais próximos, com o campo TTL=1 e com informações de quem se deseja conectar. Caso o destino não esteja nas zonas verificadas, recebendo LRJ dos GKs consultados, o GK iniciará uma busca em nuvem crescente, aumentando progressivamente o campo TTL, até que receba a mensagem LCF com o endereço do GK procurado do próprio terminal de destino.

\\Call

Admission (Admissão de uma chamada) – deve ser executado para cada chamada que for realizar. Um terminal solicita permissão ao GK para encaminhar uma chamada através da mensagem ARQ (AdmissionRequest), informando o tipo de comunicação, endereço, banda e tipo de codec. O GK responderá com a mensagem ACF, definindo banda, endereço de destino e obrigatoriamente determinando se a chamada feita diretamente (entre os gateways ou terminais) ou se será via GK. A alteração de banda é realizada de maneira similar: uma alteração de banda poderá ser solicitada por qualquer uma das partes, através da mensagem BRQ (BandwidthRequest). O terminal remoto só realizará a mudança de banda após enviar uma mensagem BRQ ao seu GK de controle e receber uma BCF. Por exemplo, um terminal poderá solicitar largura de banda adicional para abrir canal de vídeo através da mensagem BRQ.

102

Controle de mídia


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.

\\Sistemas

H.323 usam mensagens de controle de mídia definidas na recomendação H.245;

\\A

recomendação H.245 define as seguintes funções:

\\Troca

de capacidades;

\\Estabelecimento \\Determinação

e encerramento de canais lógicos;

de mestre e escravo;

\\Notificações. \\Mensagens

de controle H.245:

\\Determinação

mestre e escravo:

\\MasterSlaveDetermination; \\MasterSlaveDeterminationAck; \\MasterSlaveDeterminationReject; \\MasterSlaveDeterminationRelease. \\Troca

de capacidades:

\\TerminalCapabilitySet; \\TerminalCapabilitySetAck; \\TerminalCapabilitySetReject; \\TerminalCapabilitySetRelease. \\Comando: \\EndSessionCommand. \\Sinalização

de canais lógicos:

\\OpenLogicalChannel; \\OpenLogicalChannelAck; \\OpenLogicalChannelReject; \\OpenLogicalChannelConfirm; \\CloseLogicalChannelAck; \\RequestChannelClose; \\RequestChannelCloseAck;

103


\\RequestChannelCloseReject; \\RequestChannelCloseRelease.

Em relação às capacidades dos pontos finais, há demanda por um procedimento que permita determinar configurações compatíveis entre eles antes que fluxos de áudio, vídeo e dados textuais sejam criados. Sistemas H.323 usam mensagens definidas na recomendação H.245 para proceder com o controle de mídias. Em relação à troca de capacidades, os pontos finais informam uns aos outros suas capacidades de transmissão e recepção em termos de: codecs, tipos de mídia aceitos e taxa de bits toleráveis. As mensagens H.245 controlam a abertura e o fechamento dos canais lógicos de uma chamada, determinam as figuras do mestre e do escravo e estabelecem mensagens em caso de conflitos entre pontos finais. Definem uma série de outras mensagens que permitem a notificação entre pontos finais. Por exemplo: \\Problemas

de comunicação;

\\Determinação

de retardo.

Fast Start Considerando o tempo de ida e volta de cada mensagem gasto durante o processo de admissão (ARQ/ACF), descrito basicamente nas mensagens abaixo: 1. Utilizando o protocolo de transporte UDP na troca de mensagens setup e Connect no tempo de ida mais o de volta; 2. Utilizando o protocolo de transporte TCP na abertura de canais lógicos H.245 no tempo de ida mais o de volta; 3. Utilizando o protocolo de transporte TCP durante o tempo de ida e de volta para procedimento Mestre-Escravo em conferências. Logo, a soma desses tempos é um valor muito elevado, prejudicando o estabelecimento das chamadas H.323. Para reduzir o tempo do processo de estabelecimento de uma chamada e habilitar os canais de mídia imediatamente após o envio da mensagem Setup, a mensagem H.245 fast start é inserida na mensagem Setup enviada. Caso o destino aceite, retornará nas próximas mensagens Q.931 o elemento fast start em 1 (verdadeiro); caso contrário, o parâmetro será mantido em 0 (falso) e será retornado o procedimento normal. Este método é denominado de Fast Connect.

Tunelamento O processo chamado tunelamento (tunneling) é similar ao anterior. O tunelamento das mensagens H.245 ocorre nos elementos US-US (H.245 tunneling) das mensagens Q.931, Call Proceding, Alerting ou Connect. Na mensagem Setup, o parâmetro tunneling é configurado em 1 (verdade), para que a origem solicite a facilidade de tunelamento H.245; o restante é similar ao processo Fast Connect. 104

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;


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.

\\TerminalCapabilitySet

– informações sobre terminais e canais de mídia, porta, banda, codecs, criptografia, entre outras;

\\EndSessionCommand \\Sinalização

– encerramento da conexão e liberação dos terminais;

dos canais lógicos;

\\LogicalChannelOpen

– abertura do canal, porta UDP, tipo de mídia;

\\LogicalChannelClose

– encerramento do canal de mídia, sem encerrar a conexão realizada através do comando ESC.

Modos de operação \\A

comunicação entre pontos finais H.323 é dividida em 5 fases:

\\Início

da chamada

\\Controle

do canal H.245

\\Estabelecimento \\Utilização

da conexão entre os canais lógicos

dos serviços da chamada

\\Encerramento

da chamada

A comunicação entre dispositivos H.323 consiste em estabelecer uma chamada e encerrá-la. Para estabelecer a chamada, mensagens Q.931 são enviadas através da porta 1920 TCP (utilizando os métodos fast start ou tunneling; caso um dos terminais não aceite um dos procedimentos, será executado o procedimento normal). Um canal de controle H.245 é estabelecido através de uma porta TCP dinâmica. Em seguida conexões entre canais lógicos são estabelecidas através da porta de voz UDP dinâmica e os tipos de codecs são informados. Para o transporte da voz é utilizado o protocolo RTP/UDP.

105


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

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

de fim de sessão H.245 – comando ESC;

\\Mensagem \\Atualização

de liberação do canal de sinalização Q.931 – mensagem RLC; do GK RAS – mensagem DRQ.

Estabelecimento de chamadas \\Chamada

entre pontos finais em que somente um é registrado em gatekeeper

GK

Terminal 1

Terminal 2

Setup Cellproceeding ARQ ACF/ARJ Alerting Connect

Sinalização direta com o ponto final chamado registrado Mensagens de sinalização H.225.0

Mensagens de RAS

Figura 3.2 1. Setup – mensagem direta entre os dois terminais finais (definidos anteriormente pelo GK no procedimento RAS). A mensagem contém número de destino e de origem (números telefônicos) podendo levar no campo US-US informações sobre URIs e H.245, método fast start, tunelling ou procedimento normal; 2. Call Proceeding – aviso do destino de que todas as informações foram recebidas com sucesso e a chamada está em progresso; 3. ARQ (Admission Request) – mensagem de registro da chamada pelo terminal de destino no GK. Solicitação para completar a chamada; 4. ACF/ARJ (Admission Confirm/Reject) – mensagem do GK ao terminal, autorizando ou não o prosseguimento da chamada; 5. Alerting – mensagem informando que o destino está sendo chamado, equivalente ao ringing, no SIP; 6. Connect – mensagem que informa que o destino atendeu a chamada, podendo conter as informações H.245 no campo US-US. Quaisquer mensagens anteriores também poderiam conter informações H.245 no campo US-US, procedimentos fast start ou tunelling;

106

Chamada direta entre pontos finais Terminal 1

Terminal 2 Setup Callproceeding


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.

Alerting Connect

Sinalização entre pontos finais não registrados em gatekeepers

Figura 3.3

Mensagens de sinalização H.225.0

1. Mensagem Setup com os números de origem e destino. O terminal 1 já possuía o endereço do destino; 2. Call Proceeding – informação de que todos os dados foram recebidos para prosseguimento da chamada; 3. Alerting – informação de que o destino está livre e sendo chamado. Ao receber o alerting, a origem deve enviar tom de controle para o handset; 4. Connect – informação de que o destino atendeu e poderá ser iniciada a negociação dos canais lógicos de mídia. Connect ou qualquer mensagem para a origem irá conter o endereço no qual o terminal 2 receberá as mensagens de abertura de canal de mídia (campo US-US).

107


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

direta

GK

Terminal 1

Terminal 2

ARQ ACF/ARJ Setup Cellproceeding ARQ ACF/ARJ Alerting Connect


Mensagens de RAS

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

Figura 3.4

roteada pelo gatekeeper

GK

Terminal 1

Terminal 2

ARQ ACF/ARJ Setup Cellproceeding

Setup Cellproceeding


\\Sinalização

ARQ ACF/ARJ Alerting Connect

Figura 3.5


Alerting Connect

Mensagens de RAS

Neste caso, todas as chamadas Q.931 obrigatoriamente realizam trânsito no GK. O procedimento foi definido pelo GK durante o processo RAS e solicitado na mensagem ACF, em que o endereço de destino é o do próprio GK. Este procedimento é realizado quando for necessário ao GK ter todo o controle da chamada, para facilitar o billing ou quando o terminal 2 pertencer a outra zona, controlada por outro GK.

109


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

direta com ponto final chamador registrado

GK

Terminal 1

Terminal 2

ARQ ACF/ARJ Setup Cellproceeding Alerting Connect


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

roteada pelo gatekeeper com ponto final chamador registrado

GK

Terminal 1

Terminal 2

ARQ ACF/ARJ Setup Cellproceeding Alerting Connect


Setup


\\Sinalização

Cellproceeding Alerting Connect

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


\\Sinalização

roteada pelo gatekeeper com ponto final chamado registrado

GK

Terminal 1

Terminal 2

Setup Cellproceeding ARQ ARJ Facility Release Complete Setup Cellproceeding

Setup Cellproceeding ARQ

Alerting Cellproceeding


ACF/ARJ Alerting Connect

Mensagens de RAS

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

Figura 3.8

\\Sinalização

entre pontos finais registrados em gatekeepers distintos.

GK

Terminal 1

GK

Terminal 2

ARQ ACF/ARJ

Setup Callproceeding


Chamada entre pontos finais registrados em gatekeepers distintos

ARQ ARJ

Facility ReleaseComplete ARQ DRQ DCF ACF/ARJ Setup Callproceeding

Setup Callproceeding ARQ ACF/ARJ Alerting

Alerting

Connect Connect

Figura 3.9


Mensagens de RAS

1. Mensagem RAS ao GK solicitando permissão para usar a rede. Neste caso o destino está em outro GK; 2. Mensagem Setup enviada diretamente para o terminal 2. Como não existe nenhuma troca de sinalização entre os GKs, fica pressuposto que já ocorreu outra chamada para o terminal 2, e o GK de destino passou o endereço do terminal 2 para o GK que controla o terminal 1, ficando fora do controle das mensagens de sinalização. Como o GK que controla o terminal 1 já possui a informação do terminal 2, esta é enviada ao terminal na mensagem ACF.; 3. Terminal 2 realiza procedimentos de RAS e recebe uma rejeição, com uma solicitação para encaminhar a chamada; 4. A mensagem Facility é encaminhada ao terminal 1 com a solicitação do GK 2; 5. Terminal 1 encerra a conexão com a mensagem RLC;

113


6. Terminal 1 envia a mensagem DRQ (Disengage Request) ao seu GK, e a seguir envia nova mensagem ACF (Admission Confirm) com as solicitações contidas na mensagem Facility, recebendo mensagem ACF para prosseguimento da chamada. Possivelmente a solicitação da mensagem Facility foi atendida pelo GK na mensagem ACF, já que a capacidade do terminal é limitada; 7. Terminal 1 envia mensagem Setup com o endereço do GK que controla o terminal 2 (esta foi a solicitação contida na mensagem Facility); 8. Terminal 2 envia mensagem Call Proceeding e realiza procedimentos de RAS; 9. Terminal 2 envia mensagem Alerting para a origem, solicitando tom de controle para o terminal 1, e envia ring para o seu terminal; 10. Terminal 2 verifica o atendimento e envia a mensagem Connect para o terminal 1, para iniciar os procedimentos H.245.

\\Sinalização

entre pontos finais com consulta entre gatekeepers

GK

Terminal 1

GK

ARQ

ARQ LCF

ACF Setup Callproceeding

Terminal 2

Setup Callproceeding

Setup Callproceeding ARQ ACF Alerting

Alerting Connect

Alerting

Connect

Connect


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;


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;

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


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.

116

H.450.1

Arcabouço geral

H.450.2

Transferência

H.450.3

Redirecionamento

H.450.4

Retenção

H.450.5

Atendimento

H.450.6

Chamada em espera

H.450.7

Indicação de mensagem

H.450.8

Identificação de chamador

H.450.9

Notificação de encerramento

H.450.10

Oferta de chamada

H.450.11

Intrusão de chamada

Tabela 3.2

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.


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.

Além disso, ainda existem os casos de algumas empresas que forçam a utilização de seus equipamentos, como estratégia de mercado. Assim como os telefones digitais só funcionam com PABX de mesmo fabricante, algumas empresas fabricam telefones IP que funcionam apenas com seus PABX (que normalmente incorporam as funções de gatekeeper e gateway). Ou seja, nem mesmo uma simples ligação é realizada quando mais de um fabricante é utilizado.

Recomendações H.235 \\Definidas

com o propósito de prover um arcabouço para serviços de segurança em sistemas que usam protocolos de controle:

\\Os

serviços envolvem três aspectos principais:

\\Autenticação

de pontos finais

\\Privacidade

dos fluxos de informação

\\Integridade

dos fluxos

As recomendações H.235.0 e H.235.1 do ITU definem os perfis básicos de segurança, prevendo a possibilidade de autenticação e integridade ou só autenticação utilizando criptografia e uso de chaves. É necessário dar atenção especial a este item, porque muitas soluções de segurança são desenvolvimentos proprietários que podem sofrer os mesmo problemas relatados anteriormente.

\\Sistemas

H.323 com suporte para a recomendação H.235 possuem as seguintes características: \\Sinalização \\Fases

de autenticação

\\Trocas \\Uso

H.225.0 segura

de capacidades criptográficas

de chaves criptográficas nos canais de mídia

117


As recomendações H.235.0 e H.235.1 do ITU definem os perfis básicos de segurança, para as mensagens RAS, H.225, Q.931, Q.932 e H.245, ou seja, nos canais de controle das chamadas. O uso de criptografia nos canais de mídia (voz e vídeo) é definido no protocolo RTP, cuja última recomendação é a RFC 3550. O uso de criptografia aumenta o consumo de banda em pelo menos 10%.

Recomendação H.460 \\Define

um arcabouço que permite a negociação de várias facilidades entre pontos finais, por meio de mensagens de sinalização: \\H.225.0; \\Mensagens

RAS.

H.460 é um padrão ITU que define uma extensão opcional do H.323. Entre outras funções, é utilizado para resolver problemas com NAT e firewalls. Sua estrutura completa está descrita em uma série de documentos:

118

\\H.460.1

– arcabouço geral;

\\H.460.2

– portabilidade de número;

\\H.460.3

– informação de capacidade;

\\H.460.4

– prioridade de chamada;

\\H.460.7

– recursos de numeração;

\\H.460.8

– consulta a rotas alternativas;

\\H.460.9

– monitoração de QoS;

\\H.460.11

– retardo de chamada;

\\H.460.12

– indicação de controle de colisão de chamada;

\\H.460.13

– liberação de chamada pelo ponto final chamado.

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.



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


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;


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

rule=allow

Reinicie o gatekeeper com o comando: # /etc/init.d/gnugk restart

Passo 5: o GnuGK utiliza a porta TCP/7000 como console de monitoração da operação do gatekeeper. Dê um telnet na porta 7000 a partir do Windows para verificar se o serviço está respondendo. Se conectado com sucesso, execute o comando rv e deixe a sessão telnet aberta. Passo 6: inicie o Wireshark, desative o modo promíscuo e inicie a captura. Passo 7: configure o cliente OpenPhone, no menu Options/General.

Figura 3.13

\\No

campo Username, insira seu nome;

121


\\Para

que você fique sabendo se tem alguém te ligando, clique em Browser e escolha o arquivo ringback.wav que veio dentro do arquivo OpenPhone.rar. Caso contrário, o OpenPhone não emitirá nenhum som;

\\Verifique

se a opção marcada é DTMF as H.245 String. Não marque nenhuma das seguintes opções: Auto-Answer, Disable Fast-Start, Disable H.245Tunneling e Disable H.245 in Setup. Abaixo de Call Intrusion Protection Level, verifique se a opção Full está marcada.

Figura 3.14 Clique em OK. \\No

menu Options/Gatekeeper;

Figura 3.15

122

as opções Use Gatekeeper e Require Gatekeeper. Verifique se a opção Static Host está marcada. Digite o IP do gatekeeper nesse campo.;

\\Deixe

o campo H.235 Password em branco.


\\Marque

Figura 3.16 Clique em OK. Seu registro está feito. Observe que na janela do OpenPhone está escrito que você está registrado no gatekeeper.

Figura 3.17 Caso a mensagem mostrada acima não apareça, confira os valores de configuração e tente novamente. Passo 8: Em dupla, usuários deverão se registrar em um gatekeeper e efetuar chamadas entre a dupla, finalizando a chamada e salvando a captura feita pelo Wireshark como sip.pcap.

123


Atividade 2 – Analisando a captura feita pelo Wireshark 1. Em que modo o gatekeeper está operando?

2. Identifique os endereços IP, protocolos de transporte e portas utilizadas para a sinalização RTP e RTCP? Descreva suas observações.

3. Visualize o gráfico gerado pelo Wireshark e descreva o que ele exibe.

124

4 Asterisk ►►

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


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

em 1999 e localizada em Huntsville, Alabama (EUA);

\\Criadora

e desenvolvedora primária do Asterisk;

\\Principal

patrocinadora do Asterisk;

\\Investimento

em:

\\Desenvolvimento \\Hardware

de código-fonte;

de telefonia a baixo custo.

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.

Projeto Zapata \\Projeto

de hardware aberto (OpenSource);

\\Desenvolve \\As

hardware para telefonia com interfaces E1 / T1;

placas são produzidas por diversas empresas:

\\Exemplos: \\Digium; \\Sangoma; \\Varion.

O projeto Zapata foi conduzido por Jim Dixon, o responsável pelo desenvolvimento de hardware da Digium. O hardware também é aberto e pode ser produzido por qualquer empresa. Hoje, as placas com E1/T1 (circuitos de telefonia digital) são produzidas por empresas como Digium, Sangoma e Varion, entre outras. Jim Dixon é um engenheiro consultor de telefonia inspirado pelos incríveis avanços alcançados pela indústria de computadores em relação à velocidade de CPU. A crença de Dixon era que sistemas de telefonia muito mais econômicos podiam ser criados se houvesse um cartão em que fossem implantados nada mais do que os componentes eletrônicos básicos necessários para fazer interface com um circuito de 126

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.

Capítulo 4 – Asterisk

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


Pessoalmente, nunca havia visto o Linux rodar antes, mas fui correndo ao Fry’s (uma loja enorme de produtos eletrônicos, famosa nos EUA) e comprei uma cópia do Linux Red Hat 6.0. Dei uma olhada nos drivers e usei o Vídeo Spigot como base para traduzir o driver de BSD para Linux. De qualquer forma, minha experiência com Linux não era grande e comecei a ter problemas para desenvolver o módulo do kernel na forma de módulos carregáveis. Ainda assim, liberei-o na web sabendo que algum guru em Linux iria rir dele e talvez me ajudasse a reformá-lo em “linuquês” apropriado. Em 48 horas, recebi um e-mail de um cara do Alabama (Mark Spencer), que se ofereceu para fazer exatamente isto. Ele disse que tinha algo que seria perfeito para a coisa toda (o Asterisk). Nesse momento, o Asterisk era um conceito funcional, desprovido de um funcionamento prático e útil. O casamento do sistema de telefonia Zapata e o desenho da biblioteca de hardware/driver e interface permitiram que ele crescesse para ser um PABX real que poderia falar com telefones reais e linhas. Mark era brilhante em VoIP e em redes na parte interna do sistema, com grande interesse por telefonia, mas sua experiência com o funcionamento de sistemas de telefonia era limitada, particularmente na área de interfaces de hardware. Desde o início eu estava e sempre estive lá para ajudá-lo nessas áreas, fornecendo informações e implementando códigos nos drivers e no switch (PABX). Nós, e mais recentemente outros, fazemos um bom time trabalhando no objetivo comum de levar o melhor da tecnologia de telecomunicações ao público por um custo realista. A partir do cartão ISA, desenhei o “Tormenta 2 PCI Quad T1/E1”, que Mark vende como Digium T400P e E400P, e que agora a Varion está vendendo como V400P (ambos T1 e E1). Todos os arquivos do projeto (incluindo fotos e arquivos de plotagem) estão disponíveis em zaptelephony.org (www.zaptelephony.org) para uso público. Como qualquer um pode ver, com o trabalho dedicado de Mark (assim como o meu e o de outras pessoas) nos drivers da Saptel e no software do Asterisk, as tecnologias crescem e melhoram a cada dia”.

Asterisk \\É

um PABX (Private Automatic Branch eXchange) implementado em software;

\\Permite \\Primeiro

conectividade em tempo real entre redes PSTN e redes VoIP; PABX de código aberto do mercado:

\\Criado

pela a Digium Inc.

O Asterisk é um software (um programa de computador) que implementa funções de PABX. Foi desenvolvido de acordo com a filosofia do código livre e é disponibilizado livremente sob os termos da GPL (General Public License). Foi criado pela Digium Inc. e tem uma base de usuários em contínuo crescimento. A Digium investe no desenvolvimento do código-fonte do Asterisk, em serviço de consultoria e suporte 128

O Asterisk roda em distribuições Linux e outras plataformas Unix. Não é necessário adquirir as placas da Digium ou de outro fabricante para que o Asterisk funcione. Mas se essas placas forem utilizadas, é possível criar um gateway interligando a Rede Pública de Telefonia Comutada (PSTN – Public Switched Telephony Network) a uma rede de telefonia IP. Também será possível construir novas aplicações de voz para o sistema de telefonia tradicional. \\Escrito

totalmente na linguagem C;

\\Desenvolvido \\Kernel


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

para plataforma Linux;

2.4 ou superior;

\\Portado

para Solaris, FreeBSD e OpenBSD;

\\Possibilidade

de alteração de código de acordo com o cliente.

Asterisk e Linux \\Por

que utilizar o Linux?

\\Ambos

são soluções Open Source (Asterisk e Linux);

\\Hardware

para acesso a PSTN; toda a implementação do Asterisk é voltada para a plataforma Linux;

\\Licenciamento

duplo:

\\GPL; \\LGPL.

O Asterisk foi escrito originalmente utilizando a linguagem de programação C, amplamente conhecida na comunidade de desenvolvedores. Isso garante que praticamente qualquer pessoa no mundo com alguma experiência em programação possa contribuir aprimorando seu código-fonte. Foi desenvolvido sobre o sistema operacional Linux e, por isso mesmo, este é o sistema operacional de suporte nativo do Asterisk. Também funciona em OpenBSD, FreeBSD e MAC OS X. Portar o Asterisk para outros sistemas baseados no Unix deve ser uma tarefa relativamente fácil para pessoas com tempo e habilidade com estes sistemas. GNU General Public License (Licença Pública Geral), GNU GPL ou simplesmente GPL, é a designação da licença para software livre idealizada por Richard Stallman no final da década de 90, no âmbito do projeto GNU da Free Software Foundation.

129


A GPL é a licença com maior utilização por parte de projetos de software livre, em grande parte devido à sua adoção para o Linux. Em termos gerais, a GPL se baseia em 4 liberdades: \\De

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

\\De

estudar o funcionamento do programa e adaptá-lo para suas necessidades (liberdade nº1). O acesso ao código-fonte é um pré-requisito para esta liberdade;

\\De

redistribuir cópias de modo a ajudar o próximo (liberdade nº2);

\\De

aperfeiçoar o programa e liberar os aperfeiçoamentos de modo que toda a comunidade seja beneficiada por eles (liberdade nº 3). O acesso ao código-fonte é um pré-requisito para esta liberdade.

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

130

\\Existem

algumas formas para se contribuir com a evolução do Asterisk:

\\Desenvolvimento \\Conserto

de código;

de bugs;

\\Relato

de melhorias;

\\Novas

aplicações;


Asterisk e a GNU General Public License

\\Documentação; \\Canal

IRC e mailing list.

O Asterisk é distribuído mediante os termos da licença GPL (GNU General Public License). Esta licença permite a distribuição do Asterisk em forma de código ou em forma binária, com ou sem modificações. Sendo você um desenvolvedor, é possível contribuir com o código-fonte do Asterisk, consertando eventuais bugs, relatando melhorias, novas aplicações e drivers para os canais. Geralmente essas contribuições são disponibilizadas no CVS (Concurrent Version System), para que outros desenvolvedores possam testar e aprimorar os novos códigos. Caso não seja um desenvolvedor, pode-se contribuir com a evolução do Asterisk de uma maneira muito importante, escrevendo toda a sua experiência em configuração de ambientes e aplicações de voz utilizando o Asterisk. A documentação sobre o Asterisk pode facilitar o aprendizado de pessoas interessadas. Também é possível contribuir com o projeto através da participação de discussões e depois repassar o conhecimento obtido a outros usuários em um canal IRC (Internet Relay Chat): irc.freenode.net, ou em uma lista de e-mail (http://lists.digium.com).

Asterisk versus PABX \\As

soluções de telefonia encontradas no mercado normalmente têm custo elevado;

\\Tradicionalmente \\Novas

funcionalidades significam novos custos;

\\Dificuldades \\Em

há dificuldade para a adoção de novas funcionalidades:

de instalação;

geral implica a compra de novo hardware.

\\Vantagens \\Custo

do Asterisk em relação a PABXs:

mais atrativo;

\\Possui

um leque superior de funcionalidades:

\\Novos \\Novas

serviços são adicionados ao código-fonte.

funcionalidades não implicam a compra de novos equipamentos;

\\Controle

de seu sistema de telefonia;

131


\\Ambiente \\Plano

de discagem flexível e poderoso;

\\Código \\Funções

de desenvolvimento fácil e rápido;

aberto.

básicas:

\\Voice

mail (mensagem de voz por e-mail);

\\Música \\Salas

de conferência;

\\Parking \\Caller

em espera (mp3); (estacionamento de chamadas);

ID;

\\Siga-me; \\Transferência

de chamadas.

A definição do Asterisk na página oficial do programa diz que ele é um software livre e de código aberto, que transforma um computador comum em um rico servidor de comunicações de voz. O Asterisk é uma plataforma de desenvolvimento de aplicações de voz. Assim, é possível criar quase qualquer tipo de serviço envolvendo aplicações de voz sem os altos custos das licenças cobradas pelos fabricantes tradicionais de PABX e desenvolvedores de soluções de telefonia. O modelo de negócios adotado há muitos anos pela indústria da telefonia torna sua implementação proibitiva em muitos casos, principalmente para pequenas empresas. Para cada novo serviço, era preciso realizar upgrade no sistema com a aquisição de novo hardware, com a necessidade de comprar mais uma licença. Mesmo quando o PABX já estava preparado para o crescimento, não sendo necessário adquirir novo hardware, para cada novo canal de voz era preciso comprar uma nova licença. O Asterisk e a filosofia de código aberto vêm democratizar a utilização de aplicações de voz, pois cada novo serviço no Asterisk é implementado por software normalmente aberto e livre de licenças. Ter controle do seu próprio sistema de telefonia é um dos benefícios que o Asterisk oferece. Ao invés de esperar e pagar para alguém configurar seu PABX proprietário (a maioria não fornece nem a senha para o cliente final), o Asterisk dá toda a liberdade de configurá-lo e programá-lo. Em relação à adição de novas funcionalidades, com Asterisk basta adicionar os programas adequados. Já com soluções convencionais é muito provável que seja necessário adquirir novas licenças e novo hardware. É possível desenvolver todas as funcionalidades presentes em sistemas tradicionais no Asterisk, em que mesmo aplicações especializadas são programáveis, como as utilizadas em call centers. Por outro lado, cada nova funcionalidade em sistemas convencionais exige a aquisição de nova licença e, quase sempre de novo hardware. Além de tudo, o Asterisk suporta protocolos de Voz sobre IP, isto é, possibilita a fácil integração das redes de voz e dados. Na verdade, o Asterisk pode ser entendido como um sistema de voz sobre IP que pode ser interligado ao sistema de telefonia 132


convencional com a instalação de placas especiais. Assim, já traz embutidas as vantagens das soluções de telefonia IP, como a possibilidade de aproveitar a infraestrutura de dados para o tráfego de voz e mobilidade dos ramais, entre outras vantagens. O Asterisk não é apenas um PABX, porque faz muito mais que unir um conjunto de ramais e ligá-los à rede de telefonia pública.

Funções do Asterisk Algumas funções e serviços complementares suportados pelo Asterisk: \\Identificador

de chamada;

\\Siga-me; \\Transferência

assistida ou cega;

\\Pêndulo; \\Desvios

baseados no chamador;

\\Secretária \\Música

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

em espera (configurável por contextos);

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

de chamadas;

avançadas:

\\Resposta

Interativa por Voz (IVR);

\\Billing

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

\\Queue

(filas de chamadas);

\\Fax

over IP;

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

de conversas ou conferências;

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


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

H.323:

\\GnuGK. \\Não

134

executa nativo no Windows;

Asterisk possui como principal característica a flexibilidade:

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

O Asterisk não é um sistema comum de telefonia, porque para utilizá-lo é necessário algum conhecimento, mesmo que mínimo, em Linux, redes e telefonia. Não basta ligá-lo na tomada e conectar os fios dos ramais e da linha telefônica. É preciso configurá-lo antes de utilizá-lo. O Asterisk não é um SIP Proxy, mas um Back-to-Back User Agent (B2BUA). Isto significa que se trata de um User Agent (dispositivo SIP), que em uma conversa entre dois telefones SIP simula um SIP Proxy. Na verdade, é visto como um telefone SIP para cada perna da chamada. Na prática, é visto como um SIP Proxy. Da mesma forma, utilizando o protocolo H.323, o Asterisk não é um gatekeeper, mas simula ser um gatekeeper, uma espécie de B2BUA. Essa característica faz com que o Asterisk não seja a melhor ferramenta para lidar com grande quantidade de telefones IP. Dois exemplos de softwares de código aberto para grande instalações VoIP são OpenSIPS, que funciona como SIP Proxy, e GnuGK, que funciona como gatekeeper. Em grandes redes, o Asterisk deve trabalhar em conjunto com outras ferramentas mais apropriadas para esta finalidade, exercendo o papel de gateway (traduzindo protocolos ou interfaceando com sistema de telefonia convencional) ou de servidor de aplicações de voz. O Asterisk é altamente flexível, com configuração totalmente baseada em arquivos texto e sintaxe facilmente compreendida. A estratégia de manter comentários nos arquivos de configuração facilita muito a configuração do sistema, mesmo para usuários iniciantes que nunca viram o sistema. Existe um arquivo de configuração para cada parte do sistema: SIP, H.323, filas, música em espera, interface com banco de dados, CDR (Call Detail Record) etc. Cada módulo possui um arquivo separado e de fácil entendimento. Além disso, utilizando AGI (Asterisk Gateway Interface) ainda é possível criar novos programas em qualquer linguagem de programação para interação com a rede de dados. Por exemplo, é possível construir uma aplicação que, ao receber uma chamada, o sistema peça para digitar um número de matrícula. Após o recebimento do número, o sistema procura o status do cliente em um banco de dados e, dependendo da informação retornada, decide a ação a ser executada.

135


Hardware e interfaces para Asterisk \\Tecnologias

suportadas:

\\O

Asterisk foi desenvolvido para permitir a adição de novas tecnologias e interfaces com facilidade;

\\Seu

objetivo é suportar todo tipo possível de tecnologia de telefonia;

\\Em

geral, as interfaces podem ser divididas em três:

\\Zaptel

hardware;

\\Non-Zaptel \\Packet

hardware;

voice.

O Asterisk é desenvolvido para permitir que novas interfaces e tecnologias sejam agregadas facilmente. Essa meta visa suportar qualquer tipo de tecnologia telefônica possível. A lista dos últimos protocolos e hardwares compatíveis pode ser encontrada em http://www.digium.com ou em http://www.asterisk.org. De forma geral, as interfaces são divididas em três categorias: Hardware Zaptel, Hardware não-Zaptel e pacotes de voz. ISDN4Linux – Basic rate ISDN Interface for Linux OSS/Alsa – Sound card interfaces Linux Telephony Interface (LTI) – Quicknet internet ihonejac/Linejack Dialogic hardware1 – Full-duplex Intel/Dialogic hardware

Figura 4.1 Session Initiation Protocol (SIP) Inter-Asterix eXchange (IAX) versions 1 and 2 Media Gateway Control Protocol (MGCP) ITU H.3232 Voice over Frame Relay (VOFR)

Zaptel Pseudo TDM interfaces \\Zaptel

Pseudo TDM interfaces, disponíveis em: www.digium.com:

\\Para

uma variedade de interfaces de rede:

\\PSTN, \\T1,

E1;

\\PRI,

136

POTS;

PRA:

\\T100P

Single Span T1 ou PRI connections;

\\T400P

Quad Span T1 ou PRI connections.

Figura 4.2

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.


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.

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:

\\Zaptel

– TDM400P.

As interfaces não-Zaptel proveem conectividade a outros tipos de interfaces. Essas interfaces dão acesso a outros dispositivos, como a placa de som do computador, interfaces BRI (ISDN), JACK, ou outras placas de telefonia não baseadas na tecnologia Zaptel. TDM400P é uma placa base de 4 entradas que permite a inserção de até 4 cartões irmãos, que admitem portas FXO (módulo vermelho) e FXS (módulo verde), sendo os módulos FXO e FXS intercambiáveis para criação de várias combinações de interface.

Figura 4.3 Zaptel TDM400P 137


Atualmente existem outras placas para telefonia analógica que possibilitam uma série de combinações de interfaces FXSs (para ligação de ramais analógicos comuns) e FXOs para ligação de uma linha telefônica comum. Para mais informações, visite: www.digium.com. Fabricantes como Sangoma e os nacionais Khomp e DigiVoice possuem placas e soluções com densidades diferentes. Também possuem placas com DSP (Digital Signal Processor), provendo integração dos codecs mais utilizados e assim aliviando consideravelmente a carga de processamento no servidor. Protocolos de Telefonia IP SIP

Interface de rede (Ethernet ...)

IAX2 MGCP

Linhas Digitais Placas de comunicação

H323

E1 T1 BRI ...

PC / Servidor

Linhas Analógicas

Esta figura mostra um esquema conceitual do Asterisk utilizando uma placa de rede (Ethernet) para sua comunicação com a rede IP, uma placa digital e uma analógica para comunicação com a rede de telefonia. Neste exemplo, o Asterisk pode funcionar como um gateway entre as redes de telefonia IP e a tradicional (TDM).

Packet voice protocol \\Únicas

interfaces que não requerem um hardware específico Asterisk Gateway Interface (AGI): \\Interface

padrão:

\\AGI; \\EAGI; \\Dead \\Fast \\Os \\AGI

138

AGI;

AGI.

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

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

Figura 4.4

\\MySQL: \\Acesso

a outros recursos externos.

\\Scripts

AGI podem ser escritos em quase todas as linguagens de programação moderna, como:


\\PostgreSQL;

\\Perl; \\PHP; \\Python.

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

– pode controlar o plano de discagem;

\\EAGI

– possibilidade de acessar e controlar o canal de som, além da interação com o plano de discagem;

\\Dead

AGI – permite acesso ao canal morto após um hangup*, tendo sido descontinuado após o Asterisk 1.6;

\\Fast

AGI – permite que o script AGI seja chamado pela rede, para que múltiplos servidores Asterisk possam chamar scripts AGI de um local centralizado. * Neste caso, mesmo que a ligação tenha sido desligada e um comando hangup tenha sido executado, o canal continuará no estado UP até que o programa termine, criando um canal morto. Isto pode gerar inconsistências diversas na aplicação, por exemplo no CDR que continuará contabilizando a chamada até o canal ser fechado propriamente.

Normalmente, scripts AGI são utilizados na lógica avançada, na comunicação com bancos de dados relacionais e no acesso a outros recursos externos. Passar o

139


controle do plano de discagem para um script AGI externo permite que o Asterisk execute facilmente tarefas que de outra forma seriam difíceis ou impossíveis. O AGI funciona fazendo com que o programa se comunique com o Asterisk por meio do standard input (em um programa normal seria o teclado, no AGI é o Asterisk que envia estes dados) e do standard output (em um programa normal seria a tela do computador, no AGI o programa envia comandos como se estivesse escrevendo na tela). Base de Dados

eta

ll D

Ca R(

d)

cor

e il R

CDRs

CD

Dia

lpla

Asterisk

nC

ont

rol Programa externo

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

Esta figura ilustra os conceitos apresentados em slides anteriores, onde temos um programa externo que nos dá controle do plano de discagem do Asterisk, permitindo também ter acesso a seu banco de dados para uma coleta de CDRs com o intuito de que seja realizada alguma operação (billing, tempo gasto em uma ligação por um cliente etc.).

Protocolos usados pelo Asterisk \\Uso

de protocolos VoIP no Asterisk:

\\Estabelecer

as conexões;

\\Determinar

o ponto de destino;

\\Estabelecer

questões relacionadas à sinalização de telefonia, como:

\\Indentificador

de chamada;

\\Desconexão. \\IAX

e o Asterisk:

\\Protocolo

aberto;

\\Histórico: \\Desenvolvido

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

\\Protocolo

140

de transporte;

Figura 4.5 Exemplos de uso AGI

porta UDP (4569):

\\Canais

de sinalização;

\\Tansporte \\No

de mídia.

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

\\Plain

text;

\\MD5

hashing;


\\Utiliza

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

do IAX:

da experiência dos protocolos:

\\SIP; \\MGCP. \\Utiliza

o mesmo protocolo para sinalização e mídia em uma mesma porta

UDP. \\Objetivos

do protocolo IAX:

\\Minimizar \\Prover

o uso de banda;

transparência à NAT;

\\Facilidade

de uso na presença de firewalls;

\\Possibilidade

de transmitir informações sobre plano de discagem.

O protocolo é um conjunto de regras. Fazendo uma analogia, imagine que você encontra uma pessoa na rua e a cumprimenta com um “bom-dia”. No mínimo você espera um “bom-dia” de resposta. Mas imagine que você não recebeu de volta a sua resposta. Então você repete o “bom-dia”. Desta vez você recebe a sua resposta e inicia uma conversa. Durante a conversa, enquanto a outra pessoa fala, de vez em quando você balança a cabeça afirmativamente para demonstrar que está acompanhando seu interlocutor. No final, vocês se despedem dizendo “tchau”. Essas ações fazem parte de um protocolo de comunicação pessoal. Nada foi declarado, escrito ou documentado para fazer desses gestos e frases um protocolo formal, mas a prática aprendida no cotidiano faz este conjunto de ações definirem o início da conversação (bom-dia), o acompanhamento (“uhum”) e o término (tchau) da conversa.

141


Note que, mesmo quando a informação é perdida, quando no início da conversa você não recebe a resposta do seu interlocutor, existe uma “regra” que o faz tentar novamente o estabelecimento da conversa. Esta regra diz: caso não haja resposta em um tempo adequado, repita o “bom-dia”. A mesma coisa pode-se dizer das comunicações de dados. A forma como uma página da internet é solicitada e transferida faz parte de protocolos como HTTP, TCP, UDP, RTP, IP, FTP, exemplos de protocolos para transferência de informação. Em VoIP não é diferente; H.323, SIP, MCGP e IAX são protocolos de Voz sobre IP suportados pelo Asterisk, e todos eles possuem uma forma de estabelecer, controlar e finalizar chamadas, além de uma forma de lidar com a perda de mensagens importantes. Mesmo na telefonia tradicional, digital ou analógica, existem meios de estabelecer, controlar e finalizar chamadas. Principais protocolos de Voz sobre IP suportados pelo Asterisk: \\SIP

(Session Initiation Protocol);

\\H.323 \\IAX

(padrão definido pela ITU);

(Inter-Asterisk eXchange Protocol) v1 e v2;

\\MGCP \\SCCP

(Media Gateway Control Protocol);

(Cisco Skinny), protocolo proprietário da Cisco.

Protocolo IAX O IAX (Inter Asterisk eXchange) foi desenvolvido pela Digium com o propósito de comunicação eficiente com outros servidores Asterisk. A versão 2 do protocolo (IAX2) está definida na RFC 5456. É um protocolo aberto, isto é, qualquer pessoa pode baixá-lo da internet e aprimorá-lo. De acordo com o texto da RFC, ele não é um padrão do IETF e deve ser utilizado com cautela. O Asterisk utiliza apenas uma porta UDP conhecida e fixa (4569), para tráfego de sinalização e mídia. Esta estratégia cria uma boa vantagem sobre os outros protocolos de VoIP, pois não sofre com implementações de NAT. Além disso, também facilita o tratamento dos pacotes em firewalls, sem a necessidade da instalação de módulos específicos para VoIP. O protocolo IAX2 permite a autenticação de dispositivos utilizando: \\MD5

Message-Digest (conforme a RFC 1321) – neste caso, a senha não trafega pela rede, mas sim a resposta a um desafio calculado, utilizando uma combinação com o domínio e um número aleatório. Forma utilizada pelo SIP, com base na autenticação www.

\\RSA

(de acordo com a RFC 3447) – utiliza par de chaves pública e privada. A chave pública deve ser criptografada como algoritmo 3DES, descrito na RFC 1851.

142

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.


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.

Ele aproveita ideias do SIP, do H323 e de outros protocolos. Por exemplo, evita fortemente o envio de informação redundante e já conhecida, que não seria aproveitada. Também utiliza códigos ao invés de descrever textualmente a informação. Estas características tornam o IAX um protocolo mais rápido e eficiente para tratamento de chamadas. NAT (Network Address Translation) é um recurso de tradução de endereço de rede muito comum, usado quando é necessário ligar mais de um dispositivo de rede a internet, mas só há um endereço roteável pela grande rede. O NAT causa problemas com protocolos como H.323 e SIP, porque eles utilizam um canal (par de portas origem e destino) para o controle das chamadas e, durante o estabelecimento da chamada, negociam dinamicamente outros dois canais para mídia, um em cada sentido. O que acontece é que o roteador que implementa o NAT fica “perdido” e não consegue saber o par de portas através do qual o canal de mídia será transmitido. Esta alocação dinâmica dos canais de mídia representa um problema adicional para os firewalls que, da mesma forma que no NAT, não conseguem saber que portas devem ser abertas para as ligações estabelecidas.

Já existem implementações de firewall e NAT que conseguem identificar os canais de mídia porque, ao perceberem um pacote com características de uma ligação SIP ou H.323, analisam o pacote completamente até a camada 7 (de aplicação) e verificam os endereços e portas que serão utilizadas para o tráfego de mídia. Obviamente, este artifício consome recursos computacionais do firewall e deve ser evitado quando possível. O protocolo IAX resolve facilmente estes problemas, porque utiliza apenas a porta UDP 4569 para controle e transmissão de todas as chamadas entre os dois servidores. Outra vantagem do protocolo IAX é o modo trunk (tronco) para transmissão das chamadas entre servidores. Quando configurados para operar neste modo, dois servidores Asterisk são capazes de otimizar o consumo de banda quando houver mais de uma chamada em curso entre eles. O IAX consegue utilizar o mesmo cabeçalho IP e UDP para transmitir várias ligações simultaneamente em um só pacote, aumentando apenas 4 bytes de cabeçalho para cada chamada no “tronco”. Por exemplo, para 30 chamadas utilizando SIP ou H.323 com codec G.729, para cada pacote de voz seria necessário um cabeçalho IP+UDP+RTP. Como cada cabeçalho 143


possui 40 bytes e cada payload (carga útil do pacote de voz) também possui 40 bytes, teremos 30 x (40+ 40) bytes trafegando na rede 50 vezes por segundo. O resultado da conta revela um consumo de banda de aproximadamente 960 kbps. Por outro lado, se for utilizado o IAX2 em modo tronco com as mesmas 30 ligações e codec G.729, teremos um cabeçalho IP + UDP de 28 bytes mais 30 vezes 4 bytes, mais 30 vezes o payload de 40 bytes: 28 + 30 x (4 + 40). O resultado desta conta indica um consumo de banda de 539,2 kbps, pouco mais que a metade dos protocolos consagrados.

\\As

mensagens IAX são chamadas de frames;

\\Existem

vários tipos de frames:

\\Frame

completo;

\\Miniframe.

As mensagens IAX são chamadas de frames. Existem vários tipos de frames. Um bit F é usado para indicar se o frame é completo (full) ou não. O valor 0 indica que é completo. Um número de chamada de 15 bits é usado para identificar o ponto final do fluxo de mídia. Valor 0 indica que o ponto final não é conhecido. Uma chamada tem dois números de chamada associados a ele em qualquer uma das direções. O horário (timestamp) pode ser um campo de 32 ou 16 bits. De qualquer forma, o campo ocupa 32 bits. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 F

Número originador da chamada

R

Número de destino da chamada

Timestamp OSeqno

ISeqno

Frame Type

C

Subclasse

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

Figura 4.6 Frame completo do IAX

Figura 4.7 Miniframe do IAX

F

Número originador da chamada

Timestamp Dados


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

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

Tabela 4.1 Campos do frame completo do IAX

Campo

Descrição

F

Marcado para 1 indica que é um frame completo.

Source Call Number

Número de chamada originador do lado de transmissão.

R

Marcado para 1 indica que o frame está sendo retransmitido e o valor de 0 para a transmissão inicial.

Destination Call Number

Número de chamada de destino do lado receptor do frame.

Timestamp

Timestamp completo, 32 bits.

OSeqno

Número de sequência do fluxo de saída.

ISeqno

Número de sequência do fluxo de entrada.

Frame Type

Tipo de frame.

C

Formato do valor da subclasse.

Subclasse

Subclasse.

145


Campo

Descrição

F

Marcado para 0 indica que é um frame incompleto

Source Call Number

Número de chamada originador do lado de transmissão do frame completo

Timestamp

Timestamp completo, 16 bits.

Dados

Dados

Tabela 4.2 Campos do Miniframe do IAX

SIP

IAX

H.323

Vantagens

Largamente implementado pelas operadoras VoIP; Padrão de fato para a telefonia IP no momento.

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

Larga adoção pelo mercado; Padrão de videoconferência; Essencial na conectividade com projetos mais antigos.

Desvantagens

Problemas com NAT e FW.

Protocolo ainda pouco difundido, implementado em poucos dispositivos.

Arquitetura complexa Problemas com NAT e FW.

Este quadro resume as qualidades e defeitos dos dois principais protocolos, confrontando-os com o IAX, o protocolo feito para o Asterisk.

Resumo \\IAX

– protocolo eficiente, que procura economizar ao máximo os recursos da rede, reduzindo o consumo de banda da rede, o consumo de processamento em roteadores e, por ser bem simples, também reduz o consumo de recursos para o processamento das chamadas no PABX.

\\H.323

– mais antigo e maduro protocolo de VoIP. Completo e bem consolidado, é o protocolo mais utilizado para videoconferência. Por outro lado, é relativamente lento e complexo, além de apresentar problemas com implementações de NAT.

\\SIP

– protocolo da vez na internet, é o mais utilizado para chamadas VoIP, talvez sendo o mais adequado para uma implementação em larga escala. Mais flexível que o H.323, porém menos eficiente que o IAX.

146

Tabela 4.3 Comparativo entre IAX, SIP e H.323.


atividade tem por objetivo instalar e configurar o Asterisk.


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


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


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


No fim do arquivo, adicione os novos ramais:

;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: Domain Proxy:

149


Telefone IP Line 1 Display Name: 20XX Address: 20XX Auth User ID: 20XX Auth Password: voip Server 1 Address: Port: 5060 Transport: DNSnaptr

ATA Proxy: 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

150

200

Para maiores informações

600

Para teste de eco (excelente para teste de atraso)

#

Para retornar ao menu

Tabela 4.4

5 Arquitetura do Asterisk ►►

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

171

151


Arquitetura do Asterisk \\O

Asterisk possui uma arquitetura simples, diferente da maioria dos produtos de telefonia;

\\Atua

como um intermediador entre:

\\Tecnologias

Internet e Telephony applications

de telefonia:

\\IAX; \\SIP;

Asterisk

\\H.323. \\Aplicações

da telefonia:

\\Conferência \\Secretária

de voz;

eletrônica;

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

da arquitetura do Asterisk:

a CPU do servidor para processar os canais de voz;

\\Sistema \\Requer \\Canais

muito dependente da performance da CPU;

acesso de alta prioridade frequente para a CPU.

do Asterisk:

\\Conexões \\As

de chamadas.

Internet e Telephony technologies

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

conexões podem ser:

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

em software.

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

canais têm vários tipos de formatos:

\\Circuitos

físicos:

\\FXO

– Foreign eXchange Office;

\\FXS

– Foreign eXchange Station;

\\PRI

– Primary Rate Interface;

\\BRI

– Basic Rate Interface.

\\Baseados

em software:

\\SIP

– Session Initiation Protocol;

\\IAX

– Inter-Asterisk eXchange Protocol.

\\Canais

internos do Asterisk:

\\Agent; \\Local; \\TDMoE

152

– TDM over Ethernet.

Figura 5.1

Codec Translator API

Codec Translator Scheduler and I/O Manager

Application Laucher PBX Switching Core

Dinamic Module Loader

Asterisk File Format API

Asterisk Application API

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.

Asterisk Channel API

Figura 5.2

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

de canal (channel drivers);

\\Formato

de arquivos (file formats);

\\Detalhe

de chamadas gravadas (call detail records);

\\Codecs; \\Aplicações.

Tradutor de codec (codec translator) Conversão transparente entre canais utilizando diferentes codecs, realizada para obter o máximo de chamadas possíveis em uma rede de dados em que haja necessidade de converter os codecs.

153


Núcleo de comutação PBX (PBX switching core) Começa aceitando chamadas vindas das interfaces, depois as encaminha para a aplicação adequada, conforme descrito no plano de discagem para: \\Fazer

um telefone tocar;

\\Conectar-se \\Discagem

ao correio de voz;

para a rede pública.

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

(Foreing Exchange Office) – interfaces analógicas utilizadas para a comunicação com a operadora ou posição de ramal de um PABX;

\\FXS

(Foreing Exchange Station) – interfaces analógicas para ligação de ramais tradicionais;

\\PRI

(Primary Rate Interface) – serviço RDSI (Redes Digitais de Serviços Integrados) que provê 30 canais do tipo B (Bearer) de 64 Kbps para voz e um canal do tipo D (Data) para controle e sinalização, também conhecido como 30B+D. Utilizam interfaces digitais E1. Nos EUA, é utilizada a interface T1 e, neste caso, a quantidade de canais para voz diminui para 24;

\\BRI

(Basic Rate Interface) – interface RDSI desenvolvida para pequenos negócios. Contém apenas dois canais do tipo B e um canal do tipo D, também conhecido como 2B+D;

154

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

\\IAX

(Inter Asterisk eXchange) – protocolo utilizado na telefonia IP, proprietário do Asterisk;

\\Agent

– canal proxy de distribuição de chamadas em fila para atendentes, muito utilizado em implementações para centrais de atendimento;

\\Local

– utilizado na lógica de programação do Asterisk, faz loops com as chamadas dentro do plano de discagem, em contextos diferentes;

\\TDMoE

– canal especial do Asterisk que simula conexões TDM (Time Division Multiplexing) na camada de enlace da rede local, útil para interligar dois ou mais servidores Asterisk na mesma LAN (Local Area Network).

Tabela 5.1 Canais que o Asterisk suporta

Canais

Detalhe

Agent

Um canal de agente ACD.

Console

Cliente de console do Linux, driver para placas de som (OSS ou ALSA).

H.323

Um dos protocolos mais antigos de VoIP.

IAX e IAX2

O próprio protocolo do Asterisk.

MGCP

Outro protocolo de VoIP.

Modem

Usados para linhas ISDN e não modem.

NBS

Usado para broadcast de som.

Phone

Canal de telefonia do Linux.

SIP

Protocolo mais comum em VoIP.

Skinny

Um driver para o protocolo dos telefones IP da Cisco.

VOFR

Voz sobre Frame Relay.

VPB

Linhas telefônicas para placas da Voicetronix.

ZAP

Para conectar telefones e linhas com placas da Digium. Também usado para TDMoE e para Asterisk ZPHFC (ISDN em modo NT).


\\SIP

Outros canais do Asterisk: \\H.323

– protocolo de voz sobre IP do ITU;

\\MGCP

– protocolo de voz sobre IP;

\\Modem \\NBS

– utilizado em linhas ISDN (Integraded Services Digital Network);

– utilizado para broadcast de som;

\\Phone

– utilizado para telefonia no Linux;

\\Skinny

– protocolo de voz sobre IP utilizado nos telefones da Cisco;

\\VOFR

– voz sobre Frame Relay;

155


\\VPB

– canais de voz das placas Voicetronix;

\\ZAP

– canais de voz das placas baseadas no projeto Zapata (placas digitais da Digium).

Conforme mais empresas desenvolvem soluções para Asterisk, esta lista cresce. Os parâmetros de configuração dos canais dependem de cada fabricante. Portanto, não há uma regra única para configurar os diversos canais do Asterisk.

Introdução a canais analógicos e digitais \\Revisão \\A

dos conceitos de telefonia

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

\\Tip; \\Ring. \\Loop

fechado:

\\Telefone

recebe o tom de discagem da central telefônica:

\\Sinalização

do tipo loop-start;

\\Sinalização

do tipo ground-start:

\\Sinalização

utilizada na telefonia analógica.

A maior parte das implementações de telefonia analógica usa um par de fios metálicos (tip and ring). Quando um loop é fechado, o telefone recebe o tom de discagem da central telefônica, seja ela pública (operadora) ou privada (PABX). Nos primeiros telefones, a discagem era feita por meio de um disco que gerava uma sequência de pulsos na linha telefônica. Ao ocupar a linha, o laço (loop) era fechado e, ao efetuar a discagem, ocorriam aberturas periódicas deste laço, tantas vezes quanto o número discado. Dizemos que este tipo de sinalização é do tipo loop start. Existem outras sinalizações menos comuns, como ground start. \\Loop

start – técnica para sinalização de chamada telefônica usada por praticamente todas as linhas analógicas;

\\Ground

start – técnica de sinalização de telefonia utilizada geralmente em linhas telefônicas conectadas a um PABX.

\\Existem

basicamente três tipos de sinalização:

\\Sinalização \\On-hook

(no gancho);

\\Off-hook

(fora do gancho);

\\Ringing

(tocando);

\\Sinalização

de endereçamento;

\\Sinalização

de informação.

\\Ajustes

156

de supervisão:

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

\\Sinalização

de supervisão – indica se o telefone está no gancho (On-hook), fora do gancho (Off-hook) ou tocando (Ringing);

\\Sinalização

de endereçamento – indica os números que foram marcados pelo usuário;

\\Sinalização

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

\\Tom

de discagem;

\\Sinal \\Tom

de ocupado;

de retorno (ringback);

\\Congestionamento \\Número \\Tom


De forma muito resumida pode-se dizer que:

(congestion);

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

RING

Telefone

ON-Hook

Bateria

Figura 5.3 IDLE State

Detector de corrente Quando o usuário deixa o telefone no gancho, o circuito elétrico é interrompido e não permite que a corrente seja transmitida. Neste caso, o circuito está em estado on-hook. Quando o telefone está nesta posição, apenas a campainha (ringer) está ativa. A figura ilustra a sinalização loop start. A sinalização ground start não é usada com frequência.

157


Off-hook (fora do gancho) Telefone inicia chamada

PBX

TIP corrente elétrica

Bateria

Telefone

OFF-Hook

RING

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.

158

Figura 5.4 Telefone inicia chamada

\\Teclado

de discagem

\\Frequencias \\Indica

altas e baixas

para a central o número discado 1209 1336 1477 1633

Figura 5.5

697

1

2

3

A

770

4

5

6

B

852

7

8

9

C

941

*

0

#

D


Dual Tone Multi Frequency (DTMF)

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

de discagem – normalmente um tom contínuo, que indica que a linha está disponível;

\\Sinal

de ocupado – tom intermitente, intercalado com 250ms de silêncio, indica que o destino está off-hook;

\\Congestionamento

– semelhante ao tom de ocupado, indica falta de recurso na rede para completar a chamada.

Outros sinais menos comuns: \\Tom

de retorno;

\\Número \\Tom

inválido;

de confirmação.

As frequências e tempos também podem variar ligeiramente de acordo com o padrão adotado. Os padrões podem ser configurados no Asterisk no arquivo /etc/asterisk/indications.conf. 159


Os padrões utilizados no Brasil estão descritos na prática Telebras para telefonia, e podem ser encontrados no site da Anatel, www.anatel.gov.br. \\Interfaces

FX (Foreign eXchange):

\\Interfaces \\O

analógicas;

termo “Foreign eXchange” é aplicado para troncos;

\\Duas

interfaces:

\\FXO

(Foreign eXchange Office);

\\FXS

(Foreign eXchange Station).

Interfaces FX (Foreign eXchange) são interfaces analógicas. O termo “Foreign eXchange” é aplicado para troncos, para o acesso à operadora de telefonia.

Resumo Um canal da central da operadora é ligado em uma porta FXO (linha telefônica tradicional). Um telefone analógico convencional é ligado em uma porta FXS. Então, é possível ligar uma porta FXO em uma porta FXS, assim como é possível ligar um telefone à linha da operadora. Dito de outra forma, um telefone analógico possui uma porta FXO, e um tronco na operadora telefônica é uma porta FXS.

Gateway de voz sobre IP Tom de discagem

FXO \\FXO

Companhia telefônica

(Foreign eXchange Office):

\\Interface \\Estas

utilizada para comunicação com Central Office ou PABX;

interfaces conectam um PABX a outro:

\\PABX: \\Rede

pública.

As interfaces FXO são normalmente utilizadas para ligação com a central da operadora telefônica ou com a posição de ramal de um PABX comum. Esta porta espera receber o tom de discagem ou de linha (dialtone) e a indicação de que está chamando o destino (ringing). A porta FXO deve prover indicadores de chamadas em progresso.

160

Figura 5.6

\\FXS

(Foreign eXchange Station):

\\São

as conhecidas linhas residenciais padrão;

\\Utilizadas

para conectar dispositivos básicos:

\\Telefones;


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

\\Modem; \\Fax. \\Deve

prover:

\\Voltagem; \\Gerar

“ringing”;

\\Detectar \\Indicar

“off-hook”;

chamadas em processo.

As interfaces FXS (Foreign eXchange Station) são as conhecidas linhas residenciais padrão. Podem ser utilizadas para conectar dispositivos básicos como telefones, aparelhos de modem e fax. Também é possível conectar uma porta FXO nessas linhas. As portas FXS devem prover voltagem para acionar a campainha, ou seja, 88V AC a 20Hz. O sinal ringing, deve detectar o estado off-hook do telefone e indicar chamadas em progresso. O termo E&M é proveniente de “Ear and Mouth” (Ouvido e Boca) e indica a analogia de uma orelha para receber sinais e de uma boca para transmitir sinais. Interfaces E&M também são interfaces analógicas, usadas principalmente nas ligações entre PABXs ou entre Net-Net Switches.

\\Interfaces

E&M:

\\Interfaces \\E&M

“Ear (receive) and Mouth (transmit)”;

\\Usadas \\Não

analógicas;

em ligações entre PABXs ou entre Net-Net Switches;

estão disponíveis para o Asterisk;

\\Conhecidas \\Permitem

no mercado como tie-lines analógicas;

comunicação bidirecional.

161


As placas E&M são conhecidas no mercado de telefonia como “tie-lines” analógicas, e não estão disponíveis para Asterisk. A maioria das centrais não vem com este tipo de interface, muito embora as centrais de marcas conhecidas possuam E&M como um componente opcional. As placas E&M permitem uma comunicação bidirecional, podendo dar ou receber tom. Se você precisar usar uma interface E&M com o Asterisk, a melhor opção é a integração com um gateway de voz. A Cisco possui interfaces E&M para a maioria de seus roteadores de voz, que podem ser integradas ao Asterisk.

\\Sinalização \\Loop

nos troncos:

start;

\\Ground \\Kewl

start;

start;

\\Outros

(não serão abordados):

\\E&M

Wink Start;

\\E&M

Immediate Start;

\\E&M

Delay Start.

Kewl start é o mesmo que loop start, exceto por ter uma inteligência maior e por isso maior capacidade para detectar desconexões remotas. Desta forma, recomenda-se a utilização da sinalização kewl start com interfaces analógicas no Asterisk. E&M é uma forma de sinalização de supervisão analógica utilizada entre PABXs. Também pode ser utilizada em linhas digitais, em versões adaptadas para isso. Entretanto, a sinalização E&M está obsoleta. Esta sinalização não será abordada no curso, pois placas E&M não estão disponíveis para o Asterisk.

Loop start \\Usado

por praticamente todas as linhas analógicas;

\\Permite

ao telefone indicar os estados de:

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

ao switch os estados de:

\\Ring; \\No \\É

uma linha aberta;

\\Uma

162

ring.

chamada entrante é sinalizada por 100 V “ring voltage”.

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.


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.

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

o que o outro lado está fazendo;

\\Incorpora

vantagens do loop start e do ground start.

Adiciona inteligência à habilidade dos circuitos em monitorar o estado do dispositivo remoto. É a supervisão de desconexão. Desde que o kewl start incorporou as vantagens do loop start e ground start, sendo superior a ambos, você provavelmente irá utilizá-lo. Kewl start tornou-se, informalmente, o padrão para o uso com o Asterisk. Nova forma de conexão, completamente digital.

Channel B

Figura 5.7

PRI

D Channel

163


Com a evolução tecnológica surgiram as linhas digitais, interfaces capazes de carregar mais informação de modo mais confiável. Assim, quando a demanda por troncos de voz é relativamente alta (mais que 8 canais simultâneos), utilizar canais digitais é uma opção mais vantajosa. A tecnologia utilizada nos enlaces digitais da telefonia divide o meio de transporte em fatias de tempo, também conhecidas como time slots. Cada fatia é um canal de transmissão de dados. Esta tecnologia é conhecida como TDM (Time Division Multiplexing – Multiplexação por Divisão do Tempo). No Brasil, assim como na Europa, a interface digital mais utilizada é a E1, composta por 32 canais de 64 kbps, comumente chamado de canal ou link de 2 Mbps. Nos Estados Unidos é utilizado o padrão T1, composto por 24 canais de 64 kbps. A Telebrás estipulou que o protocolo digital padrão para comunicação dos PABX dos assinantes com as operadoras deveria ser E&M pulsada, E&M contínua ou R2D/ MFC-5C. O protocolo R2 é o mais utilizado, e juntamente com a interface E1, pode endereçar até 30 canais de voz; já as sinalizações E&M caíram em desuso. Junto com o protocolo de sinalização de linha, é utilizada a sinalização de registro Multifrequencial Compelida, que significa que cada sinal só pode ser enviado após a resposta do sinal anterior ter sido recebida. O Brasil utiliza os tipos de sinalização de registro MFC 5C terrestre (compelida), e MFC 5S (não compelida), embora mantenha a sigla MFC.

\\Integrated

Services Digital Network (ISDN) apresenta:

\\Vantagens \\Uso

sobre R2;

Flexível possibilitando uso simultâneo de dados de voz;

\\Interface

E1 com possibilidade de 30 canais de voz, conhecida como

30B+D; \\Interface

T123 com canais de voz +1;

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

\\MFC/R2: \\Sinalização

definida pela ITU-T;

\\Usada

principalmente na América Latina e na Ásia;

\\Utiliza

CAS (Channel Associated Signaling):

\\R2

Digital Brasil:

\\Possui

164

variações específicas para cada país.

Estrutura dos arquivos de configuração \\O


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.

Asterisk é controlado por meio de arquivos de configuração:

\\/etc/asterisk; \\O

formato dos arquivos de configuração do Asterisk é semelhante ao formato dos arquivos Windows (.ini);

\\Os

arquivos estão em formato ASCII, divididos em seções:

\\Nomes \\Em

seguida aos pares de colchetes:

\\ Valor \\(

das seções entre [ ].

separado por (=) ou (=>).

; ) usado para comentário.

O Asterisk é controlado por meio de arquivos de configuração localizados no diretório padrão /etc/asterisk. O formato dos arquivos de configuração do Asterisk é semelhante ao dos arquivos (.ini) do Windows. Os arquivos estão em um formato ASCII, em texto plano.

Sintaxe Os arquivos de configuração são divididos em seções designadas pelo nome entre [colchetes]. O ponto e vírgula (;) é o caractere de comentário. Dentro de cada seção, seguem os atributos e seus valores, separados por um sinal de igual (=) ou por um sinal de igual seguido de maior (=>). Uma forma de distinguir a utilização dos sinais de atribuição pode ser adotada como no exemplo, onde é usado o sinal ‘=’ para atribuição de valores a variáreis e o sinal ‘=>’ para instanciação de objetos, muito embora possam ser utilizados indistintamente. Exemplo: ; ; A primeira linha sem ser comentário deve ser um título de sessão. [sessao1] chave = valor ; Designação de variável [sessao2] objeto => valor ; Declaração de objeto

165


Grupo simples Formato mais básico, usado por arquivos de configuração em que os objetos são declarados com todas as opções na mesma linha. Os arquivos extensions.conf, meetme.conf e voice.conf seguem este formato. No exemplo a seguir, o objeto1 é criado com as opções op1, op2 e op3, enquanto o objeto2 é criado com as opções op1b, op2b e op3b. [sessao] objeto1 => op1, op2, op3 objeto2 => op1b, op2b, op3b

Entidades individuais Sintaxe usada por arquivos de configuração em que objetos são declarados com muitas opções, raramente compartilhadas com outros objetos, de modo que uma seção é associada a cada objeto. Existe normalmente uma seção [general] para as configurações globais. No exemplo seguinte, a seção geral define duas variáveis globais. Em seguida, dois objetos são criados: [objeto1] e [objeto2]. [general] globalop1=valorglobal1 globalop2=valorglobal2 [objeto1] op1=valor1 op2=valor2 [objeto2] op1=valor3 op2=valor4

Formato de objeto com herança de opções Este formato é usado por: phone.conf, mgcp.conf, zapata.conf e outras interfaces onde há muitas opções. Na classe de arquivo de configuração, existem, tipicamente, uma ou mais seções que contêm declarações de um ou mais canais ou objetos. As opções para o objeto são especificadas acima da declaração do objeto e podem ser mudadas para a declaração de outro objeto. Considere o exemplo abaixo: [sessao] op1 = bas op2 = adv objeto => 1 op1 = int objeto => 2

As duas primeiras linhas configuram o valor das opções op1 e op2 para “bas” e “adv”, respectivamente. Quando o objeto1 é instalado, é criado com sua opção1 como “bas” e sua opção2 sendo “adv”. Após declarar o objeto1, mudamos o valor 166

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:


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

[entidade1] op1=valor1 op2=valor2 [entidade2] op1=valor3 op2=valor4

A entidade [entidade1] tem valores valor1 e valor2 para as opções op1 e op2, respectivamente. A entidade [entidade2] tem valores valor3 e valor4 para as opções op1 e op2.

Organização dos arquivos de configuração \\Os

arquivos de configuração do Asterisk são comumente organizados nos diretórios abaixo: \\Arquivos

de configuração :

\\/etc/asterisk \\Executáveis

e scripts:

\\/usr/sbin/asterisk \\Bibliotecas

astman astgenkey safe_asterisk

e módulos:

\\/usr/lib/asterisk/modules

Os arquivos de configuração do Asterisk são comumente instalados nos diretórios listados a seguir. Para facilitar a administração do sistema, recomenda-se que a estrutura original seja mantida. Se for alterada, deverá ser escrita uma documentação bem estruturada, para facilitar a manutenção do sistema. Alguns destes locais podem ser personalizados no arquivo de configuração /etc/asterisk/ asterisk.conf. Outros podem ser modificados durante a compilação do programa. \\Arquivos

de configuração:

\\/etc/asterisk

167


\\Executáveis

e scripts:

\\/usr/sbin/asterisk \\/usr/sbin/astman \\/usr/sbin/astgenkey \\/usr/sbin/safe_asterisk \\Bibliotecas

e módulos:

\\/usr/lib/asterisk \\/usr/lib/asterisk/modules \\Arquivos

(headers) para criação de aplicativos, drivers e módulos:

\\/usr/include/asterisk \\PID

do processo:

\\/var/run/asterisk \\Arquivos

VoiceMail e chamadas outbounds:

\\/var/spool/asterisk \\Área

de dados:

\\/var/lib/asterisk \\Scripts

usados pelo AGI:

\\/var/lib/asterisk/agi-bin \\Banco

de dados:

\\/var/lib/asterisk/astdb

Introdução às aplicações \\Partes \\Cada

fundamentais do Asterisk;

aplicação executa uma ação específica no canal em questão:

\\Emitem

sons;

\\Aceitam

dígitos;

\\Desligam \\No

168

uma chamada.

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

As aplicações são partes fundamentais do Asterisk, funcionando como comandos. Elas tratam o canal de voz, tocam sons, aceitam dígitos, atendem e desligam uma chamada. As aplicações normalmente são utilizadas com opções que afetam a sua forma de 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.


Aplicações

Exemplos de aplicações:

Tabela 5.2

Aplicações

Descrição

Answer ( )

Responde a um canal que está chamando.

AbsoluteTimeout( )

Define o limite de tempo de uma chamada em segundos.

Background( )

Reproduz o(s) arquivo(s) de áudio especificado(s) enquanto espera que o usuário comece a inserir um ramal.

Congestion ( )

Solicita que o canal indique o congestionamento e então espera que o usuário desligue ou que o tempo de expiração (em segundos) acabe.

Dial( )

Permite que você conecte todos os tipos de canal.

Hangup( )

Incondicionalmente desliga o canal atual.

Playback( )

Toca um arquivo de som previamente gravado sobre um canal.

SetGlobalVar ( )

Define uma variável global. As variáveis globais estão disponíveis para todos os canais.

VoiceMail ( )

Deixa mensagens de voz em determinada caixa postal.

Exemplo: [incoming] Exten=>s,1,Answer Exten=>s,2,Background(enter-ext-of-person) Exten=>1,1,Playback(digits/1) Exten=>1,2,Goto(incoming,s,1) Exten=>2,1,Playback(digits/2) Exten=>2,2,Goto(incoming,s,1)

Neste exemplo, as ligações que chegam no contexto incoming são recebidas pela primeira linha, a extensão especial ‘s’. A primeira aplicação associada, ou seja, o primeiro comando executado, é o Answer, que responde a chamada e prepara o 169


ambiente para tratá-la. Em seguida, a chamada é colocada em segundo plano, pela aplicação background. Este comando toca o arquivo inter-ext-of-person e aguarda que o chamador digite uma opção. Caso ele digite 1, a extensão 1, prioridade 1 (exten => 1,1) é executada tocando o arquivo digits/1. Quando o arquivo termina, a ligação passa para a prioridade 2 (exten => 1,2), que envia o fluxo para o contexto incoming (o mesmo em que a ligação se encontra), extensão ‘s’, prioridade ‘1’, ou seja, para o início. A outra opção válida neste exemplo é o dígito 2, que executará as prioridades 1 e 2.Qualquer outra opção será inválida. Exemplo: Aplicação echo() Não são necessários parâmetros adicionais. exten 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


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


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


minutos a 1 hora (trabalho individual).

Requisitos \\Esta

prática envolve atividades individuais e em dupla.

Atividade 1 – Configurando um novo ramal Passo 1: inicie a máquina virtual localizada no diretório Asterisk, e efetue login com usuário root e a senha rnpesr. Passo 2: abra para edição o arquivo executando o comando: # vim /etc/asterisk/sip.conf

171


Passo 3: no fim do arquivo adicione o ramal incluindo as linhas conforme o exemplo abaixo, onde XX será o número do ramal da sua dupla. ;RAMAL PARA O X-LITE [10XX] type=friend secret=voip Host=dynamic canreinvite=no ;RAMAL PARA O TELEFONE IP [20XX] type=friend secret=voip Host=dynamic canreinvite=no ;RAMAL PARA O ATA [30XX] type=friend secret=voip Host=dynamic canreinvite=no

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

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.

Na seção [general], altere os parâmetros abaixo: [general] writeprotect=yes static=yes

Na seção default localizada no fim do arquivo, insira os parâmetros abaixo: [default] exten=>_10XX,1,Dial(SIP/${EXTEN},20,r) exten=>_10XX,2,Hangup()


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

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

174

6 Plano de discagem ►►

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

1 2 3 4

– – – –

Primeiro plano de discagem. . . . . . . . . . . . . . 190 Configuração do plano de discagem com Background e Goto . . 191 Tratamento de erros . . . . . . . . . . . . . . . . 191 Aperfeiçoamento do plano de discagem . . . . . . . . . 192

175


O plano de discagem \\O

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

\\O

arquivo extensions.conf, localizado no diretório etc/asterisk, especifica o plano de discagem;

\\O

plano de discagem é composto por quatro elementos:

\\Contextos; \\Extensões; \\Prioridades; \\Aplicações.

O plano de discagem é considerado por muitos a parte mais importante de uma implementação de PABX. Nele são definidos a lógica de atendimento, os perfis e como cada chamada deve ser tratada. No Asterisk, o plano de discagem é definido no arquivo extensions.conf. Portanto, este é considerado o arquivo de configuração mais importante do Asterisk. Pode-se considerar que o plano de discagem consiste em uma lista de instruções que deverão ser seguidas pelo Asterisk. No plano de discagem são implementadas instruções para: \\Perfis

dos ramais usuários do sistema;

\\Roteamento

de chamadas e os fatores sobre os quais as decisões serão

baseadas; \\Variar

o comportamento do sistema de acordo com o horário;

\\Auto-atendimento; \\URA

(Unidade de Resposta Audível) e filas para atendimento.

É possível separar o plano de discagem em quatro elementos: contextos, extensões, prioridades e aplicações.

Contextos \\Os

planos de discagem são divididos em seções chamadas contextos.

\\Especificamos \\Colocamos

um contexto definindo um cabeçalho: seu nome entre colchetes [ ];

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

176

e [funcionário]

contextos com permissões diferentes.

contextos para implementar um número importante de recursos, como:

\\Autenticação:

solicitar senha para certas extensões;

\\Segurança:

podemos evitar que determinados usuários tenham acesso a certas funções que são vetadas a outros;

\\Privacidade:

bloquear certas pessoas, por exemplo.

O plano de discagem é organizado de acordo com contextos. Os contextos são responsáveis por parte da segurança do plano de discagem. Com eles é possível definir diferentes perfis de utilização do sistema. Por exemplo, um gerente poderá fazer chamadas internacionais. Já um funcionário não poderá.

Capítulo 6 – Plano de discagem

\\Usamos

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

Os contextos servem principalmente para organizar o fluxo de cada chamada no plano de discagem. É possível configurar comportamentos diferentes para um mesmo número, dependendo de quem liga ou de que canal uma ligação é recebida. Também é possível controlar as permissões e perfis distintos para grupos de ramais ou usuários. Com a separação do plano de discagem em contextos, consegue-se criar ambientes virtualmente separados. Por exemplo, com apenas uma implementação de Asterisk, é possível emular uma série de PABXs virtuais, cada um com seus ramais e troncos específicos. Implementações deste tipo são importantes para uma utilização mais eficiente de recursos.

177


Extensões \\Os

contextos são formados por extensões;

\\Uma

extensão é uma instrução que o Asterisk segue, acionada por uma chamada de entrada ou por dígitos discados em um canal;

\\A

declaração de uma extensão possui o seguinte formato:

\\exten=>

número, prioridade, aplicação:

\\Número

ou nome da extensão;

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

extensões seguem a forma:

\\exten=> \\Um

nome, prioridade, aplicação()

exemplo prático de uma extensão poderia ser:

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

exemplo, o nome da extensão é 1001, a prioridade é 1 e a aplicação é answer.

\\A

extensão especial “s”:

\\Quando

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

Dentro de cada contexto se encontram as extensões. Uma extensão é uma regra ou instrução que deve ser seguida pelo Asterisk. Ações como atender ou desligar o canal, tocar um arquivo de áudio ou executar o tratamento de variáveis são instruções típicas das extensões. A declaração de uma extensão possui o seguinte formato: exten => EXTENSÃO, PRIORIDADE, APLICAÇÃO(OPÇÕES)

Os termos em letras maiúsculas serão abordados adiante. Os outros são fixos e fazem parte da sintaxe da declaração. O Asterisk possui uma série de extensões especiais pré-definidas. São elas: \\a

– chamada quando o usuário pressiona * (asterisco) durante a mensagem do voicemail;

\\h \\i

178

– extensão chamada após o desligamento; – extensão inválida;

\\o

– extensão do Operador, usada para saída do voicemail ao pressionar 0 (zero);

\\s

– start ou extensão de início em cada contexto;

\\t

– extensão de timeout;

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

\\failed \\fax

– usado se uma chamada auto-dial falhar;

– usado para detecção de fax em canais zap;

\\talk

– usado conjuntamente com BackgroundDetect.

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

Prioridades \\As

extensões podem ter vários passos;

\\Chamamos \\Exemplo

estes passos de prioridades;

de extensão que atende a uma chamada e em seguida a desliga:

\\exten

=> 1001,1,Answer()

\\exten

=> 1001,2,Hangup()

\\A


\\T

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;

\\Exemplos

de aplicações:

\\Answer(); \\Playback() \\Hangup()

As aplicações são como os comandos das extensões. Elas indicam as ações a serem executadas durante o fluxo da chamada no plano de discagem, como emitir sons, aceitar entradas ou desligar chamadas. 179


Answer() A aplicação Answer() é utilizada para responder a um canal que está tocando. Ela faz a configuração inicial para que o canal receba uma ligação. É uma das aplicações mais importantes, pois boa parte das outras aplicações necessita que o canal tenha sido configurado por Answer() para operar corretamente, por exemplo para executar um arquivo de som no canal. Esta aplicação não recebe argumentos.

Playback() Utilizada para reproduzir um arquivo de som sobre o canal. Recebe o nome do arquivo de som como argumento. Para facilitar o uso desta aplicação, existe um diretório padrão, var/lib/asterisk/sounds/, onde todos os sons do Asterisk se encontram. Assim não precisamos especificar o caminho completo ao utilizar a aplicação. Este caminho pode ser modificado no arquivo asterisk.conf.

Hangup() Simplesmente desliga um canal ativo e desaloca os recursos computacionais que estavam sendo utilizados na chamada. Não recebe argumentos.

extensions.conf \\Os

dois primeiros cabeçalhos que encontramos no arquivo extensions.conf — [general] e [globals] — são especiais e chamados de seções;

\\Seções

que encontramos no arquivo:

\\[general] \\[globals]

Os dois primeiros contextos do arquivo extensions.conf são seções especiais.

[general] São declaradas opções gerais sobre o plano de discagem. Por enquanto, duas opções importantes são static e writeprotect, que especificam se o arquivo extensions.conf pode ser modificado pelo plano de discagem dinamicamente no Asterisk. É uma boa escolha trocar o parâmetro para writeprotect=yes, que evita que o plano de discagem seja modificado pelo comando save dialplan, na linha de comando do Asterisk.

[globals] Na seção [globals] podemos definir e iniciar as variáveis globais com seus respectivos valores. Da mesma forma que em programas de computadores, normalmente as variáveis globais são utilizadas para simplificar mudanças na configuração do sistema. Na prática, estas variáveis são utilizadas como constantes.

180

\\Valores

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

\\${nomedavariavel} \\Variáveis

podem ser:

\\Globais; \\De

ambiente;

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

a um canal.


Variáveis

globais:

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

\\Uma \\Variáveis

vez definidas, podem ser referenciadas a qualquer momento. de ambiente:

\\Servem

para acessar as variáveis de ambiente do sistema operacional;

\\Podemos

fazer referência às variáveis de ambiente da seguinte forma:

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

de canal:

\\Configuradas

com o comando Set(), antigo SetVar;

\\Têm

um escopo local restrito ao canal em que foram criadas. São destruídas quando o canal é encerrado, para liberar memória;

\\Algumas

variáveis de canal são predefinidas e podem ser referenciadas no plano de discagem.

As variáveis são declaradas e têm seus valores atribuídos como abaixo: RINGTIME=>3

Define quanto tempo (em segundos) vai tocar antes de executar a próxima aplicação. VMANNOUCE=>mysounds/my-vm-annouce

Define qual arquivo de áudio usar quando anunciar o voicemail. RAMAL01=>Zap/2

Define o canal associado à extensão. As variáveis globais não são “case sensitive”. A utilização de caixa-alta é mera convenção. Para resgatar o valor de uma variável no plano de discagem, é preciso acessá-la da seguinte forma: ${VARIÁVEL}

181


Exemplo: exten => 1,1, answer() exten => 1,n, Dial(${RAMAL01}) exten => 1,n, hangup()

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

Asterisk ${ENV(RECORDED_FILE)}: Último arquivo gravado com o comando Record

O Asterisk pode usar uma série de variáveis como argumentos das aplicações ou comandos. Podem ser do tipo Global, Compartilhada, De canal ou De ambiente. Variáveis também podem ser manipuladas (cortadas, somadas, concatenadas). Variáveis de ambiente oferecem um meio de resgatar via Asterisk as variáveis de ambiente Unix. Mais informações sobre as variáveis do Asterisk em: www.voip-info.org/wiki/view/Asterisk+variables Cada canal no Asterisk possui seu próprio espaço para variáveis. Elas podem ser definidas dinamicamente através do plano de discagem, pelo comando Set() — antigo SetVar. Variáveis de canal são destruídas e seu espaço na memória é desalocado quando a chamada termina, quando o comando Hangup() é executado. Algumas variáveis de canal predefinidas no Asterisk podem ser utilizadas pelo plano de discagem, como veremos a seguir.

182

\\Exemplos

de variáveis de canal predefinidas:

\\${ACCOUNTCODE}:

código de contabilização;

\\${ANSWERDTIME}:

horário em que a chamada foi atendida;

\\${CALLERID}:

identificador da chamada;

\\${CHANNEL}:

nome do canal atual;

\\${CONTEXT}:

nome do contexto atual;

\\${DIALEDPEERNAME}:

nome de quem foi chamado;

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


Variáveis predefinidas

número de quem foi chamado;

hora em que o número foi discado;

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

\\${PRIORITY}:

prioridade atual.

A variável ${EXTEN} é talvez a variável de canal mais utilizada nos planos de discagem. Ela contém o número da extensão corrente e pode simplificar e facilitar significativamente a configuração do Asterisk. Existem diversas variáveis no Asterisk. O aluno pode visitar a documentação on-line para conhecer a lista completa.

Expressões \\As

expressões utilizam variáveis, valores e operadores para retornar resultados que são utilizados no plano de discagem;

\\Uma

expressão segue a seguinte sintaxe:

\\$[expressão] \\Um

exemplo de expressão poderia ser:

\\$[${nomedavariavel}+200]

Os argumentos dos comandos podem ser calculados dinamicamente na hora em que serão utilizados. O Asterisk suporta que sejam realizados cálculos durante a execução do plano de discagem. Portanto, é possível utilizar uma expressão matemática ou manipulação de strings como argumentos de comandos.

183


Por exemplo, a linha exten => 2112345678,n, dial(ZAP/g1/${EXTEN:2})

Irá chamar o número 12345678 no canal ZAP/g1, cortando os dois primeiros algarismos: “21”. No exemplo abaixo temos uma variável referenciada com seu valor somado ao valor 200. $[${nomedavariavel}+200]

Operadores \\Existem

basicamente três tipos de operadores que podem ser utilizados nas expressões: \\Matemáticos: \\+ \\\\/ \\% \\Lógicos: \\& \\| \\Operador \\“:”

para expressões regulares:

(dois pontos)

Funções dos operadores apresentados: \\+

– soma um número a outro

\\-

– subtrai um número de outro

\\/

– retorna o resultado da divisão de dois números

\\%

– retorna o resto da divisão de dois números

\\&

– “E” lógico

\\|

– “OU” lógico

\\:

– utilizado para produzir substrings. ${STRING:início:comprimento}

Mais informações em: www.voip-info.org/wiki/view/Asterisk+Expressions

184

\\Os

seguintes caracteres são exemplos de padrões:

\\X

– dígitos de 0 até 9;

\\Z


\\N


\\[1237-9]

– qualquer dígito entre as chaves e o intervalo 7-9, neste caso 1, 2, 3, 7, 8, 9;

\\“.”


Padrões de extensão

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

\\Apenas

o número de 8 dígitos é discado pelo tronco “meuTroncoSip”:

exten => _NZ[2-5]XXXXXX,1,Answer() exten => _NZ[2-5]XXXXXX,n,Dial(SIP/meuTroncoSip/${EXTEN:2}) exten => _NZ[2-5]XXXXXX,n,Hangup() \\Qualquer \\É

número de qualquer tamanho que comece com zero;

passado para o tronco SIP apenas o número, sem o zero inicial:

exten => _0.,1,Answer() exten => _0.,n,Dial(SIP/meuTroncoSip/${EXTEN:1}) exten => _0.,n,Hangup()

185


Aplicação Background() \\Uma

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

\\Diferentemente

da aplicação Playback(), a aplicação Background() reproduz um arquivo de áudio: \\Porém,

quando o usuário digita alguma coisa em seu softphone, a ligação é redirecionada para o ramal especificado.

A aplicação Background() é essencial para a construção de URAs. Ela reproduz um arquivo de áudio para o chamador, mas fica aguardando que ele digite alguma tecla. Assim podemos tocar um arquivo que diz “Por favor, digite 1 para compras ou 2 para vendas” e teremos um menu de voz interativo. A aplicação Background() possui a mesma sintaxe da aplicação Playback(). Então, seu argumento é o nome do arquivo de áudio a ser reproduzido, também com referência ao diretório padrão dos arquivos de áudio do Asterisk.

Aplicação Goto() \\Útil

para direcionar a ligação para diferentes extensões, prioridades e até mesmo contextos;

\\Possibilita \\Sintaxe: \\Há

programação do fluxo de uma ligação pelo plano de discagem;

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

literalmente para discar para algum destino:


Mais informações:

\\A

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

\\Recebe

quatro argumentos:

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

(pouco usual).

\\Exemplo: \\exten

=> 123,1,Dial(Zap/1/33072022,10,r);

\\Disca

para o número 3307 2022 no canal Zap/1;

\\Espera \\Dá

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

\\Não \\Outro

10 segundos;

especificamos nenhum URL.

exemplo:

\\exten

=> 123,1,Dial(SIP/1001,20,t);

\\Disca

para o ramal SIP 1001;

\\Espera

20 segundos;

\\Permite \\Mais

transferência de chamadas com a opção “t”.

um exemplo:

\\exten

=> 123,1,Dial(SIP/1001,,rt);

\\Disca

para o ramal SIP 1001;

\\Não \\Dá

foi especificado o tempo de espera;

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

\\Não

foi especificado nenhum URL.

A aplicação Dial() é, talvez, a mais importante de todas. Ela é responsável por estabelecer uma conexão com o canal desejado e ligá-lo ao canal solicitante. Recebe como argumento pelo menos o nome do canal de destino, mas existem opções que podem ser passadas no momento da “discagem”.

187

De forma simplificada, pode ser utilizada de acordo com a sintaxe Dial (tipo/ identificador, timeout, opções, URL), onde: \\Type

– tipo do canal (SIP, H.323, Zap, Agent etc);

\\Identifier

– identificador do canal, especificado no arquivo de configuração apropriado;

\\Timeout

– tempo durante o qual o canal deve ser chamado até desistir;

\\URL–

envia este URL para o dispositivo destino quando ele suporta, mas raramente é utilizado;

\\Options

– opções que adicionam funcionalidades ao comando Dial.

A lista de opções é grande. Confira no link abaixo: \\http://www.voip-info.org/wiki/view/Asterisk+cmd+dial

Deve-se notar que os argumentos da aplicação Dial() não são obrigatórios, podendo ser passadas várias opções como argumento.

188


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


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



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

Uma extensão completa é composta por três componentes: 1. Nome ou número da extensão; 2. Prioridade; 3. Aplicação ou comando a ser executado na chamada. 189


Os três componentes são separados por vírgulas. Exemplo: exten => nome, prioridade, aplicação( ) \\Nome

– é o número que será digitado para executar a aplicação;

\\Prioridade

– cada prioridade é numerada sequencialmente, iniciando a partir do número 1, onde cada prioridade executa uma aplicação específica.

Exemplo: exten => 123,1,Answer( ) exten => 123,2,Hangup( )

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

A extensão especial start (representada pela letra “s”) é utilizada quando uma ligação entra em um contexto sem estar destinada a uma extensão específica. Nesta atividade o aluno aprenderá e entenderá o uso e a sintaxe dos parâmetros de configuração do arquivo, para o funcionamento adequado do Asterisk.

Dicas \\No

arquivo sip.conf, altere o parâmetro context=default para context=cursovoip.

\\No

fim do arquivo extensions.conf insira a seção [cursovoip]; os parâmetros das atividades deverão ser incluídos dentro desta seção.

Inicie a máquina virtual localizada no diretório Asterisk, e efetue login com usuário root e a senha rnpesr.

Atividade 1 – Primeiro plano de discagem Começaremos a editar nosso plano de discagem utilizando uma das maiores tradições existentes na computação. Criaremos um “Hello Word!” com o que foi visto até agora. Os arquivos de áudio estão localizados no diretório /usr/share/asterisk/sound.

190


Anote as linhas inseridas:

Atividade 2 – Configuração do plano de discagem com Background e Goto Vamos criar agora um plano de discagem mais complexo utilizando as aplicações Background e Goto, onde deveremos chamar o ramal 9 no cliente X-Lite e escutar uma gravação; ao digitar 1 e 2, o Asterisk confirmará o número digitado, e ao digitarmos 3 a ligação deverá ser encerrada. 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


1. Acrescente um tratamento de erro para um canal ocupado.

2. Podemos acrescentar variáveis para simplificar o plano de discagem. Adicione as variáveis “RAMAL01=SIP/1001” e “RAMAL02=SIP/1002” em [globals]. [globals]

[cursovoip]

3. Disque 9 e depois os números dos ramais definidos no plano de discagem.

Atividade 4 – Aperfeiçoamento do plano de discagem O último plano de discagem realizado na atividade 3 tem um grande defeito: para cada novo ramal, precisamos modificar o plano de discagem. Qual seria a sua proposta de solução?

192

7 Serviços complementares ►►

Sumário Transferência de chamadas . . . . . . . . . . . . . . . . . . . 194 Estacionamento de chamadas . . . . . . . . . . . . . . . . . . 194 Captura de chamadas. . . . . . . . . . . . . . . . . . . . . 196 Música em espera. . . . . . . . . . . . . . . . . . . . . . 196 Correio de voz (voicemail). . . . . . . . . . . . . . . . . . . 197 Roteiro de Atividades . . . . . . . . . . . . . . . . . . . . . 199 Atividade Atividade Atividade Atividade Atividade

1 2 3 4 5

– – – – –

Transferência de chamadas (Blind transfer). . . . . . . . 199 Estacionamento de chamadas . . . . . . . . . . . . . 200 Captura de chamadas . . . . . . . . . . . . . . . 201 Música em espera. . . . . . . . . . . . . . . . . 202 Correio de voz . . . . . . . . . . . . . . . . . . 202

193


Transferência de chamadas \\A

transferência de chamadas é habilitada de forma bastante simples no Asterisk;

\\ A

transferência de chamadas pode ser feita de duas formas:

\\Transferência

cega (blind transfer);

\\Transferência

assistida.

Permite que chamadas sejam encaminhadas para outros ramais. Quando um usuário recebe uma ligação e decide transferi-la para outra pessoa, pode fazê-lo de duas formas: \\Transferência

cega (blind transfer) – o usuário pode simplesmente passar a ligação para a segunda pessoa, sem antes falar com ela. Neste caso, o primeiro usuário disca o segundo ramal e, quando ouve o sinal de chamando, pode desligar o telefone;

\\Transferência

assistida – o primeiro usuário pode conversar com o segundo enquanto a ligação aguarda em hold e, apenas quando o primeiro desliga o telefone é que a chamada é repassada para o segundo;

Estacionamento de chamadas \\Funcionalidade

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

\\Serve

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

\\Parâmetros

de configuração:

\\parkext; \\parkpos; \\context; \\parkingtime.

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

194

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

Capítulo 7 – Serviços complementares

Parâmetros de configuração

context Nome do contexto de estacionamento. Para estacionar chamadas, precisamos incluir este contexto no plano de discagem (include =>parkedcalls).

parkingtime Permite que uma chamada em andamento não precise ser desligada quando um dos usuários tiver que se deslocar para outro ramal. Quando configurada, esta opção controla o tempo (em segundos) que uma chamada pode ficar estacionada. Se não for recuperada no tempo fornecido, a extensão que estacionou a chamada voltará a tocar. Além do arquivo features.conf, também precisamos fazer alterações no extensions. conf para habilitar o uso do estacionamento de chamadas. Para habilitar o estacionamento de chamadas, devemos fazer a inclusão do contexto para estacionamento de chamadas. include=>parkedcalls

Figura 7.1 195


A chamada fica estacionada até que o lado que a colocou em espera se conecte novamente. Exemplo: em chamada entre os ramais 101 e 102, o usuário que está falando no ramal 101 deseja ir até a sala em que se encontra o ramal 103 e continuar a ligação de lá. Ao digitar #700, ele recebe do Asterisk um número associado à chamada estacionada. Ao discar para esse número a chamada é capturada.

Captura de chamadas \\A

captura de chamadas (call pickup) permite que o usuário atenda a chamadas direcionadas a outros usuários que estejam em um mesmo grupo;

\\ É

outro velho conhecido dos usuários de PABX convencionais;

\\Evita

que tenhamos que levantar para atender ao telefone de outro colega.

Permite que um usuário capture a chamada de outro ramal que ainda não tenha sido atendida. No Asterisk, o código padrão para captura de ligações é *8. Este código pode ser modificado no arquivo features.conf pelo parâmetro pickupexten. Além disso, para habilitar a captura, devemos configurar grupos de chamadas nos arquivos que correspondem a cada tecnologia utilizada: \\sip.conf; \\iax.conf; \\zapata.conf

/ chan_dahdi.conf.

O usuário do ramal 101 está ligando para o usuário do ramal 103. O usuário do ramal 102, ao escutar o ramal 103 tocando na sala ao lado, sem que ninguém atenda, disca *8 em seu próprio telefone e captura a chamada, sem precisar se levantar e ir até a sala ao lado onde o ramal está tocando.

Música em espera \\A

música em espera é utilizada em diversas situações, como estacionamento de chamadas, filas e transferências;

\\A

música em espera é controlada pelo arquivo musiconhold.conf;

\\Podemos

definir várias classes para organizar as músicas;

\\Podemos

utilizar a variável mohsuggest para definir classes-padrão de música em espera para os diversos canais.

Permite que um usuário em espera escute uma música de fundo. É possível utilizar quase qualquer tipo de mídia como música de espera do Asterisk, de arquivos wav até streams mms://. 196

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

A funcionalidade music on hold permite que um usuário em espera escute uma música de fundo para que não ache que a chamada foi terminada. Exemplo: existe uma chamada entre os ramais 101 e 102, e o usuário do ramal 103 faz uma chamada para o ramal 102. Ao receber a notificação de uma nova chamada, o usuário do ramal 102 avisa ao ramal 101 que vai deixá-lo em espera, sendo disponibilizada uma música de fundo para o usuário do ramal 101.

Correio de voz (voicemail) \\Mais

do que uma simples secretária eletrônica, ele pode aprimorar a experiência do usuário com uma interface simples e funcional;

\\Utilizamos

a aplicação VoiceMail() para direcionar ligações para o correio de voz;

\\Utilizamos

a aplicação VoiceMailMain() para acessar nossa caixa de correio.

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

197

198


atividade tem por objetivo explorar as funcionalidades do Asterisk.


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



Requisitos \\Esta

prática envolve atividades em dupla ou mais alunos.

Atividade 1 – Transferência de chamadas (Blind transfer) Nesta atividade iremos criar uma configuração para que seja possível efetuar transferência de chamadas. Passo 1: abra o arquivo sip.conf e verifique se todos os clientes estão com a opção canreinvite=no habilitada. Passo 2: edite o arquivo extensions.conf e coloque as opções “t” e “T” na aplicação Dial(). Ex: Dial(SIP/${EXTEN},20,rtT) Passo 3: abra o arquivo features.conf e localize a seção [featuremap], certificando-se de que as variáveis blindxfer e atxfer estejam comentadas.

199


Passo 4: reinicie o serviço Asterisk: # /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


Anotações:

Atividade 3 – Captura de chamadas Nesta atividade iremos efetuar uma configuração para capturar as chamadas destinadas a outro usuário. Esta atividade requer três ou mais alunos cadastrados em um servidor SIP. Passo 1: edite o arquivo sip.conf e defina o valor 1 para callgroup e pickupgroup: callgroup=1 e pickupgroup=1 em todos os ramais definidos. Passo 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


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

Passo 3: acrescente uma extensão para que o usuário possa acessar sua caixa de correio. exten=>500,1,VoiceMailMain()

Passo 4: reinicie o serviço Asterisk: /etc/init.d/asterisk restart Passo 5: faça testes com o X-Lite, o Telefone IP e o ATA e verifique o funcionamento das aplicações relacionadas ao voicemail.

203

204

8 Distribuição de chamadas ►►

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

209 210

205


Discagem por diretório \\O

correio de voz fornece suporte para outra funcionalidade: a discagem por diretório;

\\O

serviço de diretório de nomes do Asterisk utiliza os nomes definidos nas extensões do arquivo voicemail.conf para associar nomes a extensões;

\\O

serviço de discagem por diretório é fornecido pela aplicação Directory().

\\Default

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

\\cursovoip

é a seção do plano de discagem.

\\Sintaxe: \\Directory(vm-context[|dial-context[|options]]) \\Anuncia

ao usuário uma lista de ramais que podem ser selecionados pelo

nome: \\Esta

característica é conhecida com “discagem por nome” (dial by name) nos sistemas tradicionais.

\\A

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

\\O

primeiro argumento vm-context define o contexto no qual os ramais devem ser interpretados;

\\O

segundo argumento é usado para definir o plano de discagem.

Fluxo: \\Toca

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

\\O

arquivo de introdução toca a mensagem Please enter the first three letters of the persons last name...;

\\Nome

é a última palavra encontrada no campo em voicemail.conf;

\\Toca

a mensagem em (dir-instr) com as instruções para conexão ao ramal desejado;

\\Também

toca o “nome” como gravado na mailbox do usuário. Se a gravação não existir, ele tocará as letras do nome (bee-oh-bee-space-ess-em-aye-tee-aich) Bob Math;

206

\\Se

mais de um nome for encontrado, é possível escolher entre os nomes encontrados;

\\Se

nenhum nome for encontrado, a mensagem de introdução é repetida;

\\Pressione

“*” para sair;

\\Pressione

“1” para ir ao ramal desejado.

\\A

distribuição automática de chamadas é possibilitada pelo uso de filas, e funciona da seguinte forma: \\As

chamadas entram e são colocadas em fila;

\\Clientes \\Uma

autenticados como agentes atendem as chamadas;

estratégia é usada para distribuir as chamadas.

\\Agentes

são atendentes com ramais definidos no arquivo agents.conf, onde são definidas as filas de atendentes;

\\Um

Capítulo 8 – Distribuição de chamadas

Distribuição automática de chamadas

agente pode pertencer a mais de uma fila:

\\agents.conf

[agents] agent => 1001,4321,Wayne Kerr \\queues.conf

[queue1] member => Agent/1001 \\extensions.conf

exten => 28,1,AgentLogin(1001) exten => 29,1,Queue(queue1)

Esta função permite que as chamadas sejam atendidas assim que chegam e inteligentemente direcionadas aos agentes disponíveis, como em um call center. A distribuição automática de chamadas também auxilia a gerenciar redirecionamentos de transbordo, redirecionamento de chamadas baseado em estatísticas de fila, recuperação de chamadas abandonadas e encaminhamento de chamadas entre múltiplas localidades. O encaminhamento baseado nas habilidades dos agentes (skills-based routing) define o agente mais apropriado para atender cada chamada; o encaminhamento baseado em regras aplica um único conjunto de regras de negócio para todos os canais de contato; e a funcionalidade Specific Agent Recall direciona clientes que estejam retornando chamadas para o mesmo agente que fez o contato original.

207

208




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


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.

210

\\

Disque 300# para informar o login

\\

Disque 300# para confirmar a senha

\\

Disque o número da extensão que está usando (1001)

Anotações:

Capítulo 8 – Distribuição de chamadas

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

211

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


Hora do sistema \\Serviço

adicional – data e hora:

\\Implementado

pela função SayUnixTime();

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

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

\\Timezone

– abreviação do timezone para data/hora; se vazio, utilizará os parâmetros do sistema;

\\Format \\Todos

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

\\Todos

os parâmetros são opcionais; se nada for informado, os parâmetros padrão serão utilizados.

\\O

propósito desta aplicação de plano de discagem é informar data e hora em segundos, após 1° de janeiro de 1970.

\\Unixtime

– hora em segundos após 1° de janeiro de 1970. Pode ser negativa (segundos antes de 1° de 1970). O valor padrão é o timestamp atual.

\\Timezone

– abreviação do timezone para data/hora. Maiores informações sobre timezones podem ser encontradas em /usr/share/zoneinfo. O valor padrão é a hora em que o computador está configurado.

\\Format

214

– formato em que data e hora são reproduzidos. Os formatos abreviados são:

\\A

ou a – dia da semana;

\\B

ou b ou h – nome do mês;

\\d

ou e – dia do mês numérico;

\\Y

– ano;

\\I

ou i – hora, relógio em 12 horas;

\\H

– hora, relógio em 24 horas;

\\k

– hora, relógio em 24 horas;

\\M

– minuto;

\\P

ou p – AM ou PM;

\\Q

– today, yesterday ou ABdY;

\\q

– for today, yesterday, weekday ou ABdY;

\\R

– relógio em 24 horas, incluindo minutos; o valor padrão é ABdYIMp.

adicional – Data e Hora:

; Hora exten => 102,1,Ringing exten => 102,2,Wait(1) exten => 102,3,SayUnixTime(,America/Sao_Paulo,IMp) exten => 102,4,Hangup ; Data exten => 103,1,Ringing exten => 103,2,SayUnixTime(,America/Sao_Paulo, ABdY) exten => 103,3,Hangup

\\Hora

– IMP: hora, minuto, AM/PM.

\\Data

– ABdY: dia da semana, nome do mês, dia do mês numérico, ano.

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

\\Serviço

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

adicional – Interactive Voice Response (IVR):

Unidade de Resposta Audível (URA);

\\Recurso

que permite detectar voz e tons utilizando uma chamada normal de telefonia;

\\Muito

útil para permitir que o sistema de telefonia utilize a rede VoIP;

\\Também

utilizado para criar uma lista de menus para endereçar ramais sem DDR ou fornecer algum tipo de serviço de call center, como: \\“Bem-vindo

ao suporte de vendas, em breve você será atendido... Sua ligação é importante para nós... Disque 1 para esperar mais um pouco, 2 para falar com o Luiz etc...”.

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

215


\\Serviço

adicional – IVR:

\\Criar

a extensão [IVR]:

[IVR] exten => 9999,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:

\\Gravando

um prompt de áudio:

\\Com

o Asterisk é possível gravar as mensagens de áudio que serão utilizadas no menu do IVR;

\\A

aplicação Record() pode ser utilizada para essa finalidade:

exten => 100,1,Wait(2) exten => 00,n,Record(/var/lib/asterisk/sounds/ minhaGravacao:gsm) exten => 100,n,NoOp(${RECORDED_FILE}) exten => 100,n,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().


Gravando mensagens de áudio

Você poderá ver as descrições dessas aplicações digitando no console do Asterisk 1.4 core show application ou, no formato antigo, show application ; este formato será removido em implementações futuras.

\\Serviço

adicional – IVR:

\\Gravando

um prompt de áudio:

\\Após

gravar a mensagem, copie-a para o lugar definitivo, como por exemplo: # cd /var/lib/asterisk/sounds # cp minhaGravacao.gsm teste-ivr.gsm

\\Esta

etapa está pronta;

\\Agora

falta encaminhar as mensagens de/para o Asterisk.

É possível também na IVR chamar os ramais que estão no OpenSER; para isso poderia ser implementada uma extensão conforme abaixo: exten: _XXXX,1,Dial(SIP/${EXTEN}@openser) exten: _XXXX,2,Hangup()

217

218





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

Tabela 9.1

Filename

Nome do arquivo que será gerado na gravação. Se o arquivo existir ele será substituído

Format

Especifica o tipo de formato que o arquivo será gravado. Os formatos válidos incluem: g723, g729, gsm, h263, ulaw, alaw, vox, wav.

Silence

Especifica o tempo máximo de gravação em segundos de silêncio.

Maxduration

Especifica o tempo máximo de gravação em segundos. este campo vazio ou com 0 (zero), implica a ausência de tempo máximo. 219


1. Descreva um plano de discagem que permita a gravação das mensagens, onde os arquivos gerados estejam no formato gsm e armazenados no diretório /tmp.

2. Crie uma mensagem de saudação com nome “atende”, com a mensagem a seguir: Você ligou para a central VoIP; disque 1 para suporte, 2 para financeiro e 3 para vendas.

3. Crie uma mensagem para suporte, uma para o departamento financeiro e outra para vendas, onde em cada contexto vamos tocar uma gravação como Você foi redirecionado para o departamento xxxx.

Atividade 2 – Criando plano de discagem para uma empresa de serviço VoIP Forme grupos de quatro pessoas, onde três representarão setores da empresa e a quarta representará o cliente que efetuará a chamada. Crie uma regra de discagem conforme abaixo: 1. Ao chamar o ramal 9000, a mensagem que atende deverá ser tocada em Background; 2. Ao discar a opção desejada, a ligação será transferida para o ramal correspondente. Faça o tratamento das opções inválidas.

220


Anote o plano de discagem do grupo:

221

222

10 Qualidade de Serviço em VoIP ►►

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


Situação atual \\A

internet disponibiliza um serviço de melhor esforço;

\\O

congestionamento da rede causa atrasos e perdas;

\\Não

há garantia de tempo de entrega;

\\Não

há garantia nas perdas;

\\Novos

cenários de tráfego e aplicações necessitam de requisitos de perdas, retardo e taxa de transmissão;

\\Novas \\Voz

tecnologias, novas demandas: sobre IP (VoIP);

\\Educação

à distância;

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

interativa distribuída;

\\Telemedicina; \\Vídeo

sob demanda.

A internet faz “o melhor possível” para entregar os pacotes, mas sem garantia alguma. Pacotes podem ser perdidos, atrasados ou entregues fora de ordem. Durante o congestionamento (comutadores e roteadores recebendo mais quadros/ pacotes do que a capacidade de encaminhar/rotear), quadros e pacotes sofrem atrasos, aguardando na fila a oportunidade de serem colocados na interface de saída ou de serem excluídos. As aplicações atuais, de voz e vídeo principalmente, exigem garantias de QoS para que satisfaçam as necessidades dos usuários. Os parâmetros que definem a qualidade de serviço são intrinsecamente ligados às aplicações suportadas, diferindo se a comunicação é em tempo real ou não. \\Aplicações

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

\\Aplicações

de imagem podem exigir grande banda e não toleram alto atraso ou jitter, embora tolerem alguma perda.

\\Voz

e dados nas redes de circuitos exigiam taxas de erro distintas e, em última instância, parâmetros de qualidade diferentes.

\\Nas

redes de pacotes, os fatores a considerar são a criticidade do serviço em relação ao transporte em tempo real ou não, delay e perda de pacotes suportada. Uma vez definidos os valores dos parâmetros, como monitorá-los? Via web em tempo real? Através de relatórios recebidos da operadora em períodos a serem acordados? São perguntas importantes que deverão ser respondidas ao longo desta sessão de aprendizagem.

224

\\A

rede de comunicação deve prover funções para QoS:

\\As

funções atuam em diferentes fases do ciclo de vida de um serviço:

\\Solicitação

de serviços;

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

estáticos:

solicitação ao administrador de rede.

\\Mecanismos \\Ex.:

dos contratos;

do contrato.

\\Mecanismos \\Ex.:

de contratos de serviços;

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

Provisão de QoS

dinâmicos:

uso de protocolos de sinalização.

\\Mecanismos \\Alocação

estáticos e dinâmicos demandam: de recursos;

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

de tráfego;

da QoS a ser aplicada.

1. Para prover QoS, a rede deve possuir ferramentas de controle e monitoração do QoS ou, simplesmente, estar superdimensionada, sem a ocorrência de congestionamentos; 2. Ao solicitar um serviço, o usuário deve descrever os parâmetros exigidos pela sua aplicação; 3. Ao atender a solicitação do usuário, o fornecedor do serviço oferece uma determinada qualidade de serviço, podendo ou não ser a qualidade esperada pelo usuário, que poderá ter que diminuir um pouco a qualidade do resultado final de sua aplicação, seja por motivos econômicos (custo do serviço maior que o esperado) ou técnicos (a operadora não tem como oferecer a QoS solicitada); 4. Na assinatura de contratos de serviços, devem ser considerados os parâmetros de QoS, que responderão pela qualidade do serviço. Neste ponto é importante que o usuário verifique se a qualidade esperada é a que está sendo oferecida, e da parte do provedor checar se os parâmetros de serviço estão aderentes à expectativa do usuário; 5. Na manutenção dos contratos, será avaliada no dia a dia a qualidade do serviço, que poderá ser a esperada, inferior ou até superior. É importante definir as características da aplicação, procedimentos de emergência, e principalmente como o cliente pode monitorar os parâmetros da aplicação; 6. É importante que haja cláusulas de multa que forcem a operadora a manter a QoS dentro dos padrões contratados;

225


7. Ao término do contrato, após a liberação dos recursos, é importante fazer uma avaliação geral do comportamento da qualidade, isto é, se o que foi oferecido era o esperado pelo usuário e os cuidados de qualidade necessários para novas solicitações de serviço. Ao responder, o provedor de rede poderá atender a novas solicitações de serviço com qualidade mais robusta. Nos mecanismos estáticos, normalmente a configuração é realizada manualmente por um administrador de rede, sendo esta mantida até o fim do serviço ou até que seja realizado um pedido de mudança da configuração. Nos mecanismos dinâmicos, protocolos de sinalização respondem automaticamente a mudanças na rede, através de informações recebidas de sistemas de monitoramento, procurando sempre manter o serviço dentro de limites contratados entre o usuário e a operadora. A provisão de QoS necessita da caracterização do tráfego — detalhamento do perfil do tráfego: taxa média, taxa de pico, tamanho máximo da rajada —, para que a QoS possa ser especificada para a aplicação e a operadora aloque um mínimo de recursos em sua rede (filas em roteadores, banda, LSPs) para provimento da QoS exigida. Para provisão de QoS, é necessário conhecer as características do serviço a ser prestado. Há uma série de fatores que contribuem para a qualidade na prestação de um serviço, entre eles: \\Disponibilidade \\Medição

do serviço;

de atrasos;

\\Desempenho

dos serviços.

Os parâmetros podem ser configurados de duas maneiras: \\Estaticamente

– configuração por comandos de um operador;

\\Dinamicamente

– quando a rede nota alguma mudança de estado e ajusta seus parâmetros conforme as necessidades da aplicação e as possibilidades da rede.

Estabelecimento de contratos de serviços \\Comprometimento \\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?


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

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

garantir o SLA, é preciso orquestrar recursos de forma a:

\\Quantificar \\Prover

os recursos disponíveis;

um controle de admissão;

\\Classificar \\O

de contratos de serviços;

e escalonar pacotes.

SLA pode ser configurado de forma:

\\Estática: \\Recursos

reservados pelo administrador de rede.

227


\\Dinâmica: \\Efetuada

por um protocolo de sinalização;

\\Podendo

ser:

\\Centralizada; \\Descentralizada

ou distribuída.

Para garantir o SLA, é necessário conhecer os recursos totais da rede e os recursos já reservados para que o controle de admissão conheça o limite para a garantia de recursos aos usuários. Acima deste limite os pacotes trafegarão sem garantia ou serão descartados. A classificação é a função normalmente exercida na borda da rede, onde o equipamento descobre a qual classe (definida em conjunto com o cliente) pertence cada pacote, fazendo sua marcação e colocando-o na fila adequada. No caso do cliente extrapolar os valores combinados com o provedor, os pacotes podem ser classificados com uma prioridade mais baixa ou simplesmente descartados. Durante o escalonamento, o nó da rede (comutador ou roteador) colocará os quadros ou pacotes nas filas adequadas e selecionará os próximos a serem encaminhados/ roteados conforme a QoS estabelecida para cada classe. Na forma estática, o SLA é definido por um período de tempo e recursos pré-determinados, sendo essa configuração mantida até que o administrador faça outra intervenção. Na forma dinâmica, ao contrário do modelo anterior, a reserva de recursos é realizada por protocolos específicos, que podem alterar parâmetros durante o período em que a aplicação está sendo realizada. Na configuração centralizada, um único equipamento recebe informações de toda a rede, toma as decisões necessárias e as envia aos equipamentos da rede. Como exemplo, podemos citar a engenharia de tráfego em uma rede MPLS, onde as definições dos LPS podem ser realizadas por um servidor centralizado. Já a configuração descentralizada ocorre quando todos os nós da rede participam da definição.

Provisão centralizada \\Bandwidth

Broker (BB) ou negociador de recursos é o responsável pela reversão e configuração dos recursos.

\\O

BB disponibiliza:

\\Interface

de solicitação e configuração de serviços;

\\Comunicação

228

das decisões.

de BB:

\\Common

Open Policy Server (COPS) – RFC 2748;

\\Diameter

(RFC 3588).

Os negociadores de recursos (Bandwidth Broker – BB) são agentes que possuem conhecimento dos recursos disponíveis, recursos reservados e das necessidades das aplicações, além do nível de utilização da rede e do fluxo de pacotes marcados como prioritários, entre outros, para assim interpretar com maior inteligência e coerência as novas requisições de banda. Os negociadores de recursos facilitam, orientam e disciplinam as alterações de recursos desejados, facilitando a administração da rede, a QoS e o SLA. Cada domínio deverá possuir o seu BB.


\\Exemplos

Common Open Policy Server (COPS), especificado na RFC 2748, é um modelo cliente/ servidor para efetivar o controle e o policiamento da QoS para determinada aplicação. Para a parte de autenticação e billing, é utilizado o RADIUS (Remote Authentication Dial In User Service). Diameter (RFC 3588) é um protocolo para autenticação e billing, em uma versão mais robusta que o RADIUS, com o acesso seguro sendo feito via IPsec ou TLS, na porta 3868 TCP.

Provisão distribuída \\Estações

e roteadores na rede são dotados de um negociador próprio;

\\Negociadores

trocam informações de controle via protocolo de sinalização e determinam a reserva de recursos;

\\Exemplo: \\Resource

ReSerVation Protocol – RSVP (RFC 2205).

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

229


Manutenção \\A

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

\\Necessidade \\A

de policiamento:

rede deve reagir prontamente a degradações ocasionais.

\\Falhas

de componentes de rede:

\\Dimensionamento

conversativo dos recursos.

\\Acionar

funções de sintonização;

\\Manter

o SLA contratado:

\\Realocar

recursos;

\\Escolher

subredes e roteadores alternativos.

\\Renegociação \\Tentativa

do SLA:

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

inatingíveis nos prazos negociados;

\\Metas

definidas pela tecnologia e não pelo negócio;

\\SLA

entendido pela organização como um overhead, e não como um diferencial competitivo;

\\Equipe

de SLM sem a devida senioridade/autoridade para negociar com as partes envolvidas (clientes e fornecedores);

\\Contratos


Renegociação do SLA

de SLA inadequados;

\\As

diversas áreas envolvidas não perceberem que o acordo é um “construtor”, e não um “destruidor” de relacionamentos;

\\Falta

de recursos (pessoas, processos e tecnologia);

\\Divulgação

inadequada de metas e reportes.

Término do contrato \\A

aplicação informa à rede a intenção de finalizar o contrato;

\\A

rede libera os recursos alocados;

\\Especificado

o período do contrato, a liberação dos recursos poderá ocorrer de forma automática.

É necessário ter cautela e ferramentas de avaliação sobre a disponibilidade dos recursos. A gerência da rede deve estar familiarizada com esses recursos para evitar surpresas de recursos alocados indevidamente. Liberar recursos de forma automática pode ser um problema quando a área técnica não está integrada ou bem alinhada com a área de pós-vendas das empresas.

Modelos de QoS \\Existem

diferentes tipos de modelos propostos pelo Internet Engineering Task Force (IETF);

\\Esses

modelos se adaptam de acordo com o tipo de aplicação e de arquitetura da rede: \\Integrated

Services (IntServ);

\\Differentiated

Services (DiffServ).

231


\\IntServ: \\Utilizado

para designar um modelo de serviços que acrescenta ao serviço de melhor esforço oferecido na internet;

\\Categorias

de serviços com diferentes graus de comprometimento de recursos (banda e memória) e níveis (ou classes) de QoS;

\\Um

fluxo é identificado na arquitetura IntServ pela tupla IP Origem e Porta TCP ou UDP de origem.

\\IntServ

oferece, além do best effort, as seguintes categorias de serviços:

\\Serviços \\Para \\Serviços

garantidos: aplicações que necessitam de um atraso constante. de carga controlada:

\\Para

aplicações que necessitam de segurança e limite de variação de atraso (jitter).

\\Aplicações

que exigem esses tipos de serviço devem configurar caminhos e reservar recursos antes da transmissão dos dados;

\\A

implementação do IntServ é feita por quatro componentes:

\\Protocolo \\Rotina

de sinalização (RSVP);

de controle de admissão;

\\Classificador; \\Escalonador

de pacotes.

Integrated Services (IntServ) é um protocolo caracterizado pela reserva prévia de recursos para atender determinada aplicação. O conceito simula um circuito, uma vez que a comunicação só é realizada se houver recursos disponíveis nos roteadores antes do início da conversação, seja ela de dados ou de voz. Um fator que pode ser considerado negativo neste caso é que os recursos dos roteadores ficam comprometidos durante todo o tempo em que a aplicação estiver ativa, independente de naquele exato momento a aplicação estar utilizando os recursos de rede. Além disso, é de difícil escalabilidade, pois é um protocolo complexo e consome muitos recursos computacionais, especialmente memória para manter os estados de todas as conexões. O Differentiated Services (DiffServ) foi desenvolvido pelo IETF para resolver os problemas do protocolo anterior em relação ao comprometimento dos recursos, seja para o controle das conexões ou para o tráfego de dados propriamente dito. Os pacotes são marcados de acordo com características do serviço e, em cada roteador, são encaminhados de acordo com sua prioridade. Não há necessidade de estabelecimento de circuito. O modelo IntServ está descrito na RFC 1633. A sinalização deste modelo de QoS é provida pelo protocolo de reserva de recursos, o RSVP (Resource Reservation Protocol), descrito na RFC 2205. 232

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

2211 – Controlled-Load Network Element Service;

\\RFC

2212 – Guaranteed Quality of Service.

A definição do caminho a ser percorrido pelo fluxo, assim como a reserva de recursos, antecederá o início do fluxo propriamente dito, o que gera um atraso maior do primeiro pacote. O controle de admissão é essencial para que o sistema não se comprometa com uma carga superior ao que pode realmente transportar. A arquitetura IntServ causa dois problemas principais:


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.

\\Processa

cada fluxo individualmente nos roteadores do centro da internet, gerando problemas de escala;

\\Falta

de políticas de controle.

Uma rede que implemente o modelo IntServ precisa garantir que seus roteadores sejam capazes de executar as seguintes tarefas: \\Controle

de admissão – determina que um fluxo pode ser encaminhado com o grau de qualidade requerido, sem interferir em fluxos já em curso;

\\Classificação

– reconhece pacotes que necessitam de níveis específicos de QoS;

\\Policiamento

– age quando o tráfego não está em conformidade com o especificado, inclusive descartando pacotes;

\\Enfileiramento

e escalonamento – encaminha os pacotes de acordo com os requisitos de QoS.

Protocolo de sinalização – RSVP \\RSVP

(Resource reSerVation Protocol) é um protocolo de sinalização que gerencia recursos ao longo do caminho no qual se quer utilizar aplicações que necessitem de QoS;

\\O

processo de sinalização ocorre antes da transmissão dos dados e é renovado sempre que necessário.

O protocolo RSVP, descrito na RFC 2205, é o protocolo de sinalização utilizado pelo modelo IntServ para reserva de recursos nos roteadores envolvidos na comunicação. É o responsável pela sinalização no domínio IntServ, estabelecendo e desfazendo caminhos confiáveis na rede. Se apenas um dos roteadores envolvidos 233


no trânsito dos dados não tiver disponível o recurso solicitado, a transmissão dos dados não ocorre. Para alocar recursos, as mensagens PATH e RESV são trocadas entre o receptor e o transmissor. Nuvem RSVP PATH(1)

PATH(2)

PATH(3)

Figura 10.1 RESV(6)

RESV(5)

RESV(4)

Origem solicita reserva de recursos tais como banda, delay e jitter, para determinada aplicação através da mensagem PATH, que pode ser unicast ou multicast. Cada roteador consultado que atender à solicitação passa ao estado de “reserva dos recursos”, e encaminha a mensagem até o destino, que retorna a mensagem RES pelos mesmos roteadores, confirmando a reserva do caminho. Desta maneira é estabelecido um caminho prévio, semelhante ao conceito dos recursos solicitados ao longo circuito. No RSVP, um fluxo de dados é uma sequência de mensagens com a mesma origem (endereço IP e porta), o mesmo destino e a mesma qualidade de serviço. Principais problemas deste protocolo: \\Estabelecida

a conexão e no caso de queda de um roteador no caminho (path), todo o procedimento tem que ser refeito;

\\Comprometimento

de recursos durante todo o tempo da conexão, exigindo alto desempenho da rede;

\\Quando

o caminho é desfeito, é preciso se certificar de que todos os recursos sejam liberados, evitando comprometimentos desnecessários;

\\Problema

de escala, pois conforme aumenta a quantidade de fluxos das aplicações, aumenta o consumo dos recursos, causando problemas aos backbones das grandes redes.

Rotina de controle de admissão \\O

controle de admissão tem apenas a função de determinar se um fluxo de dados poderá ser aceito ou não, de acordo com a banda disponível;

\\Este

componente é requisitado de forma que sua decisão não interfira nos fluxos previamente aceitos pelo roteador.

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

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


Classificador

Escalonador de pacotes \\Estabelece

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

\\O

escalonador trabalha com algoritmos que fazem implementações de acordo com a necessidade de QoS para determinados serviços, tais como: \\First

In First Out (FIFO);

\\Weighted \\Priority

Fair Queuing (WFQ);

Queuing (PQ).

O escalonador de pacotes gerencia os buffers das filas de saída dos roteadores e estações, usando alguma política de atendimento com a finalidade básica de selecionar os primeiros pacotes a serem colocados na interface de saída, lembrando que aguardar na fila representa aumento do atraso e da possibilidade de descarte.

Escalonador FIFO (First In First Out) \\Pacotes

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

FIow 1

2

FIow 2

4

FIow 3 FIow 4

FIFO Queue

6

Multiplexer

6

5

4

3

2

1

Port

FIow 5 FIow 6 FIow 7

Figura 10.2

FIow 8

3 1

235


É a política mais simples, normalmente utilizada para aplicações que não necessitam de QoS. FIFO (o primeiro a chegar é o primeiro a sair) é uma implementação de escalonador que apenas faz o armazenamento e o repasse dos pacotes, sem nenhum tipo de classificação ou prioridades. A ordem de chegada dos pacotes é respeitada, determinando a alocação da banda. Algumas aplicações podem sofrer muito com o tráfego em rajada, causando grandes atrasos para aplicações sensíveis ao tempo.

Escalonador WFQ (Weighted Fair Queuing) \\Pacotes

são classificados e designados a uma fila

Incoming packets

Transmit queue

Classify

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)

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

Figura 10.3

\\O

roteador mantém várias filas com diferentes prioridades

High Incoming packets

Mediun Classify

Transmit queue

Outgoing packets

Normal Low Length defined by queue limit


Escalonador PQ (Priority Queying)

Queueing buffer resources Classification by: Protocol (IP, IPX, AppleTalk, SNA, DECnet, bridge, and so on) Source interface (EO, SO, and so on)

Figura 10.4

Interface hardware: Ethernet Frame Relay ATM Serial link (and others)

Priority Queuing (enfileiramento prioritário) é um algoritmo desenhado para aplicações de tempo real. A fila com maior prioridade é checada e se houver algum pacote ele é enviado. Quando a fila SP (Strict Priority, Prioridade Estrita), a fila de maior prioridade, estiver vazia, o algoritmo procura por pacotes na próxima fila. Assim que chega um pacote na fila SP, o algoritmo volta a esvaziar esta fila e repete o processo. Também é conhecido como LLQ (Low Latency Queue) ou fila de baixa latência. A desvantagem deste método é a possibilidade das outras filas sofrerem um fenômeno chamado de starvation (morrer de fome), pois elas podem nunca ser atendidas pela possibilidade de sempre haver pacotes em uma fila de maior prioridade.

IntServ \\Escalabilidade: \\Informações

de estado podem sobrecarregar os elementos centrais da rede;

\\Inadequado

para redes de backbone.

\\Complexidade: \\Todos

os roteadores devem implementar RSVP, controle de admissão, classificação e escalonador de pacotes.

O IntServ é pouco escalável, uma vez que trata de cada fluxo individualmente. Em uma grande rede, armazenar informações e tratar individualmente de cada fluxo pode comprometer o espaço de armazenamento e o processamento dos nós intermediários, assim como o esforço de gerenciamento. Os roteadores devem 237


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

DiffServ \\Differentiated

Service:

\\Introduzido

pelo Internet Engineering Task Force (IETF) para resolver os problemas encontrados com a implantação do IntServ;

\\Neste

modelo, os pacotes são previamente marcados de acordo com os tipos de serviços desejados;

\\O

DiffServ possibilita a criação de classes de serviços dentro de um domínio:

\\Ex.:

ISP, Teleco.

\\Quando

o cliente contrata um “serviço diferenciado”, o campo TOS (Type Of Service) é marcado com a classe correspondente.

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

– seleciona um pacote do fluxo baseado no conteúdo de alguma porção do cabeçalho;

\\Medidor

– checa se os parâmetros do tráfego estão de acordo e passa os resultados para o marcador e modelador;

\\Marcador

– escreve ou reescreve o campo DSCP;

\\Modelador

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

238

\\Formato

0

do datagrama IP

4 Version

8 HLen

16 Type of service

31

Total lenght

Identification Time to live

19 Flags

Protocol

Fragment offset

Header checksun

Source IP address Destination IP address Options

Padding


DiffServ no pacote IP

Data Figura 10.5 Inicialmente, a classificação de pacotes utilizava o campo TOS (Type Of Service). Este procedimento é popularmente conhecido como “marcação de pacotes”. Quando um pacote IP é marcado, significa que o campo foi preenchido com determinado valor. Este campo indica o tipo de serviço que está sendo transportado pela rede IP. A RFC 3260 redefine o campo TOS, modificando o significado de alguns bits. Agora, este octeto é conhecido como DS (Differentiated Services). São utilizados 6 bits para a marcação dos pacotes, e os outros dois estão reservados e não são utilizados. Na prática, os pacotes são marcados com valores que definem a classe de serviço a que pertencem, fornecendo uma indicação aos roteadores da prioridade com que esses fluxos devem ser tratados. No IPv6, o campo DSCP foi mapeado como o octeto “Classe de tráfego”.

239


DiffServ – DSCP \\Valores

DSCP

PBH

DSCP

Default

Precedência IP

000000

Assured Forwarding

0

Low Drop Probability

Medium Drop Probability

High Drop Probability

Classe 1

001010 – AF11

001100 – AF12

001110 – AF13

1

Classe 2

010010 – AF21

010100 – AF22

010110 – AF23

2

Classe 3

011010 – AF31

011100 – AF32

011110 – AF33

3

Classe 4

100010 – AF41

100100 – AF42

100110 – AF43

4

Expedited Forwarding

101110 – EF

Pacotes com prioridade EF (Expedit Forwarding) são imediatamente enviados para a rede. A classe EF está descrita na RFC 2598. Pacotes com prioridade AF (Assured Forwarding) possuem 4 classes distintas, são enfileirados e encaminhados de acordo com a política de enfileiramento. Pacotes da classe AF4 têm maior prioridade que pacotes da classe AF1. Dentro de cada classe, ainda existe uma marcação conhecida como “three colour marking” ou marcação de três cores, que define a probabilidade de descartar pacotes dentro de cada fila. Assim, existem 12 classes AF distintas, que vão desde AF41 até AF13. As classes AF estão descritas na RFC 2597. Os pacotes com prioridade BE (Best Effort) possuem a menor prioridade e serão encaminhados depois de todas as outras classes, se houver recursos para isto. Esta classe está descrita na RFC 2474.

Considerações sobre DiffServ \\Em

cada roteador que trabalhe com diferenciação de serviços, o código contido no sub-campo DSCP é mapeado em um Per-Hop Behavior (PHB) – Comportamento por enlace;

\\O

PHB define o tratamento a ser dado ao pacote:

\\Os

dois principais PHBs definidos pelo IETF são:

\\Encaminhamento

Expresso (Expedited Forwarding – EF);

\\Encaminhamento

Assegurado (Assured Forwarding – AF).

Uma vez que os pacotes foram marcados, os roteadores devem encaminhá-los de acordo com regras pré-estabelecidas. Dependendo de suas classes, um pacote terá maior ou menor prioridade na fila de saída de cada interface de rede, conforme 240

5

Tabela 10.1

Encaminhamento \\Expresso

(EF – Express Forward):

\\Objetivo

é diminuir o tempo de permanência nas filas dos pacotes em trânsito;

\\Garante

prioridade nos pacotes com esta marcação em relação a qualquer outro;

\\Garante \\Assegurado

tempos de atraso e perdas de pacotes máximos aceitáveis.


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.

(AF – Assured Forward):

\\Fornece

apenas uma expectativa de serviço quando a rede passa por momentos de congestionamento;

\\O

contratante do serviço possui garantias mínimas de QoS.

O encaminhamento expresso “garante” que o pacote atravessará a rede sem descarte e com um mínimo de atraso. É adequado a serviços prioritários com requisitos rígidos quanto ao tempo de entrega dos pacotes, como sinalização da rede, controles de processos em tempo real e telefonia. O encaminhamento assegurado garante que o fluxo encontrar-se-á dentro de limiares pré-estabelecidos, podendo haver perdas e variações de atraso (dentro de limites pré-estabelecidos). É uma boa escolha para serviços que precisam de alguma prioridade em relação a outros, mas não tem compromisso rígido com o tempo de entrega dos pacotes.

Serviços Integrados sobre Diferenciados \\Emprega

a arquitetura IntServ nas redes de acesso e a arquitetura DiffServ nas redes de backbone;

\\O

IntServ trata de fluxos, enquanto o DiffServ agrega os diversos fluxos em classes dentro de um domínio DS;

\\Vantagens

da integração:

\\Possibilidade

de se implementar serviços de policiamento por fluxo e autenticação de usuários individuais;

\\Melhor

uso de recursos e custo, obtidos com a reserva por fluxo.

Serviços Integrados sobre Serviços Diferenciados são utilizados para racionalizar o uso de recursos em um modelo de QoS que equilibra a vantagem de alocação de recursos com a simplicidade do PHB. Essa combinação aplica as arquiteturas onde 241


elas são mais adequadas: IntServ no acesso (próximo ao usuário), onde há uma quantidade menor de fluxos, sem problemas de escalabilidade; e DiffServ nos backbones, onde a quantidade de fluxos é muito grande e o processamento de cada pacote não pode ser alto, para que as altas taxas de transmissão necessárias no backbone não sejam comprometidas. Mesmo sendo bem diferentes, as duas arquiteturas podem ser combinadas para criar uma solução fim-a-fim. NE (Host)

NE (Link)

Network Edge NE (Router) IntServ NE (Link)

NE (Router) DiffServ Transit Network NE (Virtual Link)

Fonte: ARMITAGE, Greenville. Quality of Service in IP Networks. New Riders Publishing, 2000.

Na figura, os elementos de rede estão indicados com a sigla NE (Network Elements). Uma ou mais redes IntServ podem ser construídas em volta de uma rede DiffServ. Podemos conseguir isso tratando a borda da rede (NE – Network Edge) DiffServ como uma ponta de um link virtual.

Multi-Protocol Label Switching – MPLS \\O

modelo tradicional de roteamento IP pode ser melhorado em redes de backbone:

\\O

roteamento é feito pacote a pacote, e dois pacotes com os mesmos destino e origem podem seguir rotas diferentes;

\\A

ideia do MPLS é criar um caminho virtual na entrada da rede MPLS, permitindo a determinação prévia da sequência de roteadores que compõem a rota.

\\Vantagens

do MPLS:

\\Permite \\Reduz

242

prover QoS;

a carga nos roteadores.

Figura 10.6

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.


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.

Modelo básico de rede MPLS Costumer 1

MPLS Core

Label = 10

Label =

Label = 35

Costumer 2

17

Costumer 2

Costumer 3

Costumer 1

l= 0

20

L

17

be

l=

e ab

La

Costumer 1 Costumer 3

Costumer 2 Label = 17

MPLS Edge

Physical links

Segments of LSP 1

MPLS Edge

Segments of LSP 2

Fonte: ARMITAGE, Greenville. Quality of Service in IP Networks. New Riders Publishing, 2000.

Figura 10.7

O Multi-Protocol Label Switching é em alguns aspectos semelhante ao DiffServ: \\É

um protocolo independente, situado entre a camada de enlace e a camada de rede (camada 2,5);

\\Normalmente \\O

utilizado no núcleo da rede;

pacote recebe um rótulo (label) ao entrar na rede MPLS;

\\Roteamento \\Dentro

nas bordas e comutação no núcleo;

da rede o QoS contratado é atendido.

243

\\Protocolo \\Áudio

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

\\Desempenho

versus Confiabilidade.

UDP RTP

Performance


Real-time Transport Protocol – RTP

TCP

Reliability Fonte: Analog Devices: Analog Dialogue: Blackfin Voip; Acessado em 22/02/07.

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

\\O

serviço inclui:

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

sequencial;

temporais (timestamping);

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

do tipo payload;

da entrega de dados:

interpolação.

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

244

Figura 10.8

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

\\Formato

do pacote RTP:

\\Os

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

0

8 V

P

X

#CS

16 M

PT

24


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.

32

Sequence

Timestamp Syncronization Source (SSRC) Countributing Source (CSRS) Header Extention Payload (áudio, vídeo etc)

Figura 10.9 \\V

(Version);

\\P

(Padding);

\\X

(Extention);

\\CC \\M

(CSRC Counter);

(Marker Bit);

\\PT

(Payload Type);

\\Sequence

Number;

\\Timestamp;

\\V

\\SSRC

(Synchronization Source) Identifier;

\\CSRC

(Contributing Source) Identifiers.

(Version) – versão do RTP;

\\P

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

\\X

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

\\CC

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

245


\\M

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

\\PT

(Payload Type) – indica o formato da carga do RTP e determina sua interpretação pela aplicação;

\\Sequence

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

\\Timestamp

– utilizado pelo receptor para sincronização e cálculo do jitter;

\\SSRC

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

\\CSRC

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

\\V

– versão: 2 (RFC 3550);

\\p

– padding = 1, se o pacote contém enchimento para completar múltiplos de 32 bytes;

\\x

- 1, se houver extensão de cabeçalho;

\\PT

(payload type) – tipo de aplicação (codec), definido na RFC 1890 e 3551 (PT=200/RTCP);

\\cc

(CSRC COUNT) – número de fontes de mídia contribuintes;

\\m

(marker) – depende do PT (igual a 1), por exemplo quando houver supressão de silêncio;

\\Número

de sequência – de 0 a 65535, é inicializado aleatoriamente e incrementado de um, a cada pacote transmitido;

\\Timestamp

– 32 bits, utilizado para calcular o jitter;

\\Synchronization \\Contributing

source (SSRC) – identificador da fonte e sincronismo;

source (CSRC) – identifica as fontes contribuintes para mixagem.

Exemplo de uma sessão RTP Cada fluxo de voz contém uma sessão RTP e uma RTCP.

RTP

RTCP

RTCP

UDP

UDP

IP

IP Sessão RTP

246

RTP

Figura 10.10 Sessão RTP

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.


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.

Real-time Transport Control Protocol – RTCP \\Protocolo

que complementa o transporte de dados feito pelo RTP;

\\Permite

o monitoramento da entrega de dados de forma escalável em redes multicast;

\\Oferece

funcionalidades mínimas de controle e identificação;

\\Baseado

na transmissão periódica de pacotes de controle para todos os participantes de uma sessão RTP;

\\Utiliza

o mesmo mecanismo de distribuição definido para os pacotes que compõem os fluxos de dados das aplicações;

\\Desempenha

4 funções:

\\Prover

informação a respeito da qualidade da distribuição dos dados de um fluxo;

\\Transportar

um identificador de nível de transporte persistente para um transmissor em uma sessão RTP:

\\Nome

canônico (canonical name ou CNAME);

\\As

funções anteriores requerem que todos os participantes enviem pacotes periodicamente;

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

geradas pelo RTPC:

Report (SR);

\\Receiver \\Source

informações mínimas de controle de sessão.

Report (RR);

Description (SDES);

\\BYE; \\APP.

247


A frequência de transmissão de pacotes de controle pode variar com a quantidade de participantes em uma sessão, uma vez que, em caso de uma quantidade muito alta, o fluxo de dados de controle pode comprometer os fluxos de dados. Uma das melhorias que a atualização da RFC traz é justamente o desempenho do protocolo RTCP com um novo algoritmo para cálculo do tempo de transmissão dos pacotes deste protocolo em conferências. O RTCP provê o feedback da qualidade da distribuição, útil para codecs adaptativos e para a detecção de problemas locais ou globais. O identificador CNAME é utilizado para associar múltiplos streammings, como voz e vídeo. O RTCP controla a taxa que os participantes devem enviar informações de controle para que o fluxo de dados não seja prejudicado. Provê um mínimo de informações de controle. Informações mais detalhadas, necessárias para algumas aplicações devem ser providas por nível superior. \\Sender

Report (SR) – para estatísticas de transmissão e recepção de participantes que são transmissores ativos em uma sessão;

\\Receiver

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

\\Source

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

\\BYE

– para indicar o fim da participação de uma aplicação em uma sessão;

\\APP

– para funções específicas da aplicação;

V

P

IC

PT

Length

Format-specific information

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

248

Figura 10.11 Estrutura do RTCP.

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;


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

3. Contagem de itens (IC) – indica o número de itens contidos em um pacote. Normalmente utilizado para indicar o número de receiver reports contido no pacote; 4. Tipo do pacote (PT) – identifica o tipo de informação contida no pacote. Atualmente existem 5 tipos; 5. Comprimento (Length) – indica o tamanho do conteúdo do pacote contido após este cabeçalho comum. Os pacotes RTCP nunca são transmitidos individualmente. Eles são sempre agrupados para a transmissão, formando pacotes compostos. V

P

RC

PT=201

Length Reporter SSRC

Loss fraction

Cumulative number of packets lost Extended highest sequence number received Interarrival jitter

First report block

Reportee SSRC

Timestamp of last sender report received (LSR) Delay since last sender report received (DLSR)

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


\\Reportee

SSRC (Reportee Synchronization Source) – identifica o participante e o destinatário deste report. Assim, o destinatário pode saber a qualidade do RTP recebido pelo emissor;

\\Loss

fraction – definido como a fração entre o número de pacotes perdidos no intervalo de reporte dividido pelo número esperado;

\\Cumulative

number of packets lost – representa o número de pacotes esperado, subtraído o número de pacotes realmente recebidos;

\\Extended

highest sequence number received – identifica os pacotes recebidos para possibilitar a identificação da perda de pacotes;

\\Interarrival

jitter – estimativa do jitter dos pacotes;

\\Timestamp

of last sender report received (LSR) – Timestamp NTP (Network Time Protocol) que identifica o tempo do mais recente pacote RTCP SR recebido;

\\Delay

since last sender report received (DLSR) – é o delay entre o recebimento do último pacote SR e o envio do RR.

V

P

RC

PT=200

Length Reporter SSRC

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

Além dos relatórios de qualidade dos receptores, o RTCP também possui relatórios do emissário. Esse relatório fornece informações sobre a mídia enviada. É identificado pelo tipo de pacote 200. \\Reporter

SSRC (Reporter Synchronization Source) – fonte de sincronização do participante que envia o reporte;

\\NTP

timestamp – corresponde ao tempo de envio do SR;

\\RTP

timestamp – corresponde ao tempo de envio do último pacote RTP;

\\Sender’s

packet count – número de pacotes de dados gerados pela fonte de sincronização na seção;

\\Sender’s

octet count – número de octetos contido no payload dos pacotes de dados, incluindo os cabeçalhos e o padding;

250

Figura 10.13 Pacote SR (Sender Report)

P

RC

PT=202


V

Length SSRC / CSRC 1

List of SDES items SSRC / CSRC 2

List of SDES items

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

Figura 10.15 Pacote SDES - 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

Length = 10 SSRC

Type = 1 (CNAME)

Figura 10.16 Exemplo de SDES

Length = 15

c

s

p

@

1

0

.

7

.

4

2

.

1

6

9

Type = 2 (NAME)

Length = 13

C

o

l

i

n

P

e

r

k

i

n

s

Type = 0

i

0

0

\\Type

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

\\Type

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

\\Type

3 – e-mail do participante;

\\Type

4 (Phone) – telefone do participante;

\\Type

5 (LOC) – localização do participante (normalmente configurado pelo usuário em sua aplicação);

\\Type

6 (TOOL) – indica a implementação utilizada pelo participante;

\\Type

7 (NOTE) – permite ao participante fazer uma breve nota informando qualquer mensagem arbitrária;

\\Type

8 (PRIV items) – utilizado para especificar extensões privadas e para criar extensões experimentais ou específicas para determinadas aplicações.

V

P

RC

PR = 203

Lenght SSRC 1 SSRC 2 ... SSRC n

Optional length

Optional reason for leaving

Figura 10.17 Pacote BYE

V = Version number P = padding RC = number of SSRC headers PT = packet type

V

P

Subtype

PR = 204

Lenght SSRC

Application-defined packet name

Application-defined data

Figura 10.18 Pacote BYE \\O

BYE é identificado pelo tipo de pacote 203, e mostra que os participantes indicados deixaram a transmissão.

\\É

identificado pelo tipo de pacote 204.

A última classe de pacotes RTCP permite extensões específicas para aplicações, sendo útil para utilizar extensões RTCP fora dos padrões ou para testar novas funcionalidades.

252

10 Roteiro de Atividades Tópicos e conceitos \\Conceitos

sobre QoS.


final desta prática o aluno saberá solicitar QoS para o serviço VoIP que implementará.



Atividade 1 – Qualidade de Serviço (QoS) Em se tratando de Qualidade de Serviço na internet, o IETF propôs dois modelos que se adaptam de acordo com o tipo de aplicação e de arquitetura. 1. Quais são os modelos e suas respectivas RFCs?

2. Quais são as suas vantagens e desvantagens?

253


3. Na figura a seguir, o usuário do PC1 da empresa 2 quer estabelecer uma comunicação de Voz sobre IP com o usuário do PC2 da empresa 1. Baseando-se no modelo DiffServ, descreva o processo para classificação de tráfego e escalonamento de pacotes nos equipamentos de rede mostrados na figura a seguir.

Figura 10.19

4. Com suas palavras, descreva o que é uma rotina de controle de admissão.

5. Qual a função do classificador?

6. Qual a função do escalonador de pacotes?

254

8. O que é Real-time Transport Protocol (RTP)?


7. Qual o objetivo do Multi Protocol Label Switching (MPLS)?

9. Qual o objetivo do Real-Time Transport Control Protocol (RTCP)? Quais as suas principais funções?

10. Analisando o pacote RTP, observamos o campo Payload Type (PT), que indica o formato da carga do pacote e como será sua interpretação pela aplicação. Quantos são os valores para este campo, quais são e o que representam?

255

256

Bibliografia \\ARMITAGE,

Grenville. Quality of Service in IP Networks. New Riders Publishing, 2000.

\\BRANDL,

Margit; DASKOPOULUS, Dimitris; DOBBELSTEIJN, Erik; GARROPPO, Rosario Giuseppe; JANAK, Jan; Kuthan, Jiri; NICCOLINI, Saverio; OTT, Jorg; PRELLE, Stefan; UBIK, Sven e VERHAREN, Egon. IP Telephony Cookbook. Terena, 2004.

\\COLCHER,

Sérgio; GOMES, Antônio Tadeu; OLIVEIRA, Anderson; GUIDO, L. E. VoIP: Voz sobre IP. Editora Campus/Elsevier, 2005.

\\DEMPSTER,

Barrie; GARRISON, Kerry. TrixBox Made Easy. Packt Publishing, 2006.

\\GOMILLION,

David; DEMPSTER, Barrie. Building Telephony Systems with Asterisk. Packt Publishing, 2006.

\\LOVELL,

David; VEIBELL, Scott. Cisco IP Telephony. Cisco Press, 2004.

\\MADSEN,

Leif; SMITH, Jarred; MEGGELEN, Jim Van. Asterisk: The Future of Telephony. O’Reilly, 2005. Disponível em: http://www.asteriskdocs.org/modules/ tinycontent/index.php?id=11. Acessado em 16/08/2006.

\\PERKINS, Colin. RTP: Audio and Video for the Internet. Boston: Addison Wesley, 2003. \\SINNREICH,

Henry e JOHNSTON, Alan B. Internet Communications Using SIP.

Wiley, 2006. \\SPENCER,

Mark; ALLISON, Mack; RHODES, Cristhopher. The Asterisk Handbook – Version 2.

\\TANENBAUM, \\TODD, \\ITU-T: \\RFC

Andrew S. Redes de computadores. Editora Campus, 2003.

John. Asterisk: A Bare-Bones VoIP Example. O’Reilly.

H.323 Packet-based multimedia communications systems.

– 3261

\\Recomendação \\Apostila

ITU – G.711

VoIP e Telefonia IP UFF 2009

257


\\www.voip.nce.ufrj.br.

Acessado em 22/11/2006, com informações retiradas sobre o serviço fone@RNP.

\\www.babooforum.com.br.

Acessado em 20/08/2006, com informações retiradas sobre redes de computadores.

\\www.maxrouter.com.

Acessado em 12/04/2007, com informações retiradas

sobre codecs. \\www.speex.org.

Acessado em 12/04/2007, com informações retiradas sobre o

codec Speex. \\www.brasiltelecom.com.br.

Acessado em 15/08/2006, com informações retiradas sobre a história da telefonia.

\\en.wikipedia.org.

Acessado em 10/4/2007, com informações retiradas sobre codecs e evolução das redes e da telefonia.

\\www.anatel.gov.br.

Acessado em 15/08/2006, com informações retiradas sobre a história da telefonia.

\\www.clubedohardware.com.br.

Acessado em 15/08/2006, com informações

retiradas sobre redes de dados. \\www.sobresites.com/telefonia/historiadotelefone.htm.

Acessado em 22/08/2006,

com informações retiradas sobre telefonia. \\www.ilbcfreeware.org.


sobre o codec iLBC. \\www.rnp.br/voip/.

Acessado em 22/11/2006, com informações retiradas sobre o serviço fone@RNP e o projeto VoIP4All.

\\www.cornfed.com/iax.pdf.


sobre IAX. \\www.voip.nce.ufrj.br/courses/rnp/Interconexao_Gateways_parte_1_3tr.pdf.

Acessado em 03/05/2007. \\CISCO.

Guia do primeiro ano, segunda edição.

\\Recomendação

ITU – G.711

\\www.digium.com \\Quality

of Service, diff serv code point, IP precedence. Acessado em 25/12/2006. Disponível em: www.rhyshaden.com/qos.htm

\\Analog

Devices: Analog Dialogue: Blackfin VoIP. Acessado em 22/02/07. Disponível em: www.analog.com/library/analogDialogue/archives/40-04/blackfin_voip.html

\\www.voip.nce.ufrj.br/courses/rnp/Interconexao_Gateways_parte_1_3tr.pdf.

Utilizado como fonte de fotos. \\Apostilas

do curso VoIP4All

\\www.voip-info.org

258

\\www.asterisk.org \\www.networksocerty.com/enp/protocol/sip.htm

Bibliografia

\\www.packetizer.com

259

260

Aprenda na prática a configurar uma rede VoIP com Asterisk, telefones IP e ATA O curso capacita o aluno na utilização da tecnologia VoIP, permitindo o entendimento dos elementos e benefícios desta solução. Serão vistos seus principais codecs e protocolos de sinalização e transporte, as diferenças em relação ao sistema de telefonia tradicional e o diferencial da aplicação da qualidade de serviço (QoS) à rede VoIP. Nas atividades práticas, o aluno montará uma rede VoIP de pequeno porte utilizando o protocolo SIP e configurará uma rede de ramais VoIP e um ambiente com softphones, telefones IP e adaptadores ATA; e aprenderá a instalar e configurar o Asterisk.

esr.rnp.br

Introdução à Voz sobre IP e Asterisk

Recommend Documents