UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMTICA
CURSO DE ESPECIALIZAO EM TECNOLOGIAS, GERNCIA E SEGURANA
DE REDES DE COMPUTADORES

SIMONE HARFF

Requisitos e Proposta para Implantao de um Servidor VoIP

Trabalho de Concluso apresentado

como requisito parcial para a obteno
de grau de Especialista

Prof. Dr. Joo Csar Netto

Orientador

Prof. Dr. Srgio Luis Cechin

Prof. Dr. Luciano Paschoal Gaspary
Coordenadores do Curso

Porto Alegre, outubro de 2008.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitor: Prof. Carlos Alexandre Netto
Vice-Reitor: Prof. Rui Vicente Oppermann
Pr-reitoria de Ps-Graduao: Prof. Aldo Bolten Lucion
Diretor do Instituto de Informtica: Prof. Flvio Rech Wagner
Coordenadores do curso: Profs. Srgio Luis Cechin e Luciano Paschoal Gaspary
Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro

SUMRIO
LISTA DE ABREVIATURAS E SIGLAS ................................................. 06
LISTA DE FIGURAS ............................................................................... 09
LISTA DE TABELAS .............................................................................. 11
RESUMO ................................................................................................. 12
ABSTRACT ............................................................................................. 13
1 INTRODUO ......................................................................................14
2 VoIP: UMA VISO GERAL ................................................................. 16
3 CENRIOS

DE

COMUNICAO

VoIP,

PROTOCOLOS DE

SINALIZAO E TRANSPORTE ...................................................... 19

3.1 Cenrios de Comunicao VoIP .................................................... 19
3.1.1 VoIp de Terminal IP para Terminal IP ............................................ 19
3.1.2 VoIp de Terminal IP para Telefone ................................................ 21
3.1.3 VoIP de Telefone para Telefone .................................................... 22
3.2 Protocolos de Sinalizao .............................................................. 23
3.2.1 H.323 .............................................................................................. 23
3.2.2 SIP .................................................................................................. 25
3.2.3 Diferenas entre H.323 e SIP ......................................................... 26
3.3 Protocolos de Transporte ............................................................... 27
3.3.1 RTP ............................................................................................. 27
3.3.2 RTCP .............................................................................................. 28
4 CODECs ............................................................................................... 29
4.1 Codificao de Voz .......................................................................... 29
4.2 G.711 ................................................................................................. 32
4.3 G.722 ................................................................................................. 32
4.4 G.723.1 .............................................................................................. 32
4.5 G.726 ................................................................................................. 33
4.6 G.728 ....... 33
4.7 G.729 33
5 NAT/FIREWALL E PRIVACIDADE/AUTENTICIDADE EM VoIP..... 34

5.1 NATs e Firewalls em VoIP34

5.1.1 Universal Plug and Play.. 36
5.1.2 Simple Traversal of UDP Trought Netware Address Translators .37
5.1.3 Traversal Using Relay NAT.38
5.1.4 Application Layer Gateway..39
5.1.5 Configurao Manual....................................................................40
5.1.6 Tcnicas de Tunelamento................................................................41
5.1.7 Automatic Channel Mapping............................................................42
5.2 Privacidade/Autenticidade em VoIP................................................45
5.2.1 IP Security........................................................................................45
5.2.2 SRTP................................................................................................49
5.2.3 zRTP.................................................................................................50
5.2.4 VoIp sobre SSL.................................................................................51
6 QoS em VoIP.........................................................................................52
6.1 Mtricas de QoS................................................................................ 52
6.2 Proviso de QoS............................................................................... 53
6.3 Mecanismos de QoS..........................................................................53
6.3.1 Tratamento de Filas..........................................................................53
6.3.2 Controle de Admisso.......................................................................54
6.3.3 Escalonamento de Filas....................................................................54
6.3.4 Controle de Congestionamento........................................................56
6.3.5 Conformao de Trfego..................................................................56
6.3.6 Policiamento de Trfego...................................................................57
6.4 Arquiteturas de QoS..........................................................................58
6.4.1 IntServ...........................................................................................58
6.4.2 DiffServ.............................................................................................59
7 ASTERISK..............................................................................................61
7.1 PBX-IP.................................................................................................61
7.2 Funcionalidades.................................................................................62
7.3 Arquitetura..........................................................................................63
7.4 Componentes do Asterisk.................................................................64
7.4.1 Interfaces de Hardware.....................................................................64
7.4.2 Interfaces de Software......................................................................66
7.5 Asterisk X OpenSer....67
8 PROPOSTA DE IMPLEMENTAO.....................................................68
8.1 Escopo................................................................................................68
8.2 Estrutura da Rede..............................................................................68
8.3 Implementao...................................................................................70
8.3.1 Protocolos de Sinalizao e Transporte...........................................70
8.3.2 CODECs...........................................................................................71
8.3.3 NAT/Firewall.....................................................................................71
8.3.4 Privacidade e Autenticidade.............................................................72
8.3.5 QoS...................................................................................................72
8.3.6 Asterisk.............................................................................................74

8.3.7 Guia de Implementao....................................................................75

9 CONCLUSO.........................................................................................77
REFERNCIAS.........................................................................................79

LISTA DE ABREVIATURAS E SIGLAS

ACELP

Algebraic Code Excited Linear Prediction

ACM

Automatic Channel Mapping

ADPCM

Adaptative Diferencial PCM

AES

Advanced Encryption Standard

AH

Authentication Header

ALG

Application Layer Gateway

AS

Assured Forwarding

ATA

Adaptador para Telefone Analgico

ATM

Asynchronous Transfer Mode

CAR

Commited Access Rate

CODEC

Codificador / Decodificador

CS-ACELP

Conjugate Structure ACELP

DiffServ

Differentiated Services

DSCP

Differentiated Service Code Point

DSP

Digital Signal Processor

EF

Expedited Forwarding

ESP

Encapsulating Security Payload

IETF

Internet Engineering Task Force

IntServ

Integrated Services

IP

Internet Protocol

ITU

International Telecommunications Union

ITU-T

ITU Telecom Standardization Sector

LDAP

Lightweight Directory Access Protocol

LD-CELP

Low-Delay Code Excited Linear Prediction

MC

Controlador Multiponto

MCU

Unidade de Controle Multiponto

MGC

Media Gateway Controller

MGCP

Media Gateway Control Protocol

MIKEY

Multimdia Internet Keying

MIME

Multipurpouse Internet Mail Extensions

MKI

Master Key Identifier

MOS

Mean Option Scores

MP

Processador Multiponto

MP-MLQ

Multi-Pulse Multi-Level Quantization

MPLS

MultiProtocol Label Switching

NAT

Network Address Translation

PBX

Private Branch Exchange

PCM

Pulse Code Modulation

PHB

Per Hop Behaviours

QoS

Quality of Service

RSVP

Resource ReSerVation Protocol

RTCP

Real Time Control Protocol

RTP

Real Time Transport Protocol

RTPC

Rede Telefnica Pblica Comutada

RTSP

Real Time Streaming Protocol

SBADPCM

Sub-band Adaptive Diferencial PCM

SDP

Session Description Protocol

SIP

Session Initiation Protocol

SLA

Service Level Agreement

SLS

Service Level Specification

SRTCP

Secure RTP Control Protocol

SRTP

Secure Real-Time Transport Protocol

SSL

Secure Sockets Layer

STUN

Simple Traversal of UDP Trought NAT

TCP

Transfer Control Protocol

TCS

Traffic Conditioning Specification

TOS

Type of Service

TRIP

Telephony Routing Over IP

TURN

Traversal Using Relay NAT

UA

User Agent

UDP

User Datagram Protocol

UPnP

Universal Plug and Play

VoIP

Voice Over Internet Protocol

LISTA DE FIGURAS
Figura 2.1:

Comunicao VoIP....................................................................... 17

Figura 3.1:

Comunicao de voz de terminal IP para terminal IP....................20

Figura 3.2:

Comunicao de voz de terminal IP para telefone........................ 22

Figura 3.3:

Comunicao de voz de telefone para telefone usando redes IP....23

Figura 5.1:

NAT bloqueia fluxo de mdia fim-a-fim....................................... 35

Figura 5.2:

O probema do firewall................................................................... 36

Figura 5.3:

STUN............................................................................................. 38

Figura 5.4:

TURN..............................................................................................39

Figura 5.5:

ALG................................................................................................40

Figura 5.6:

Configurao manual......................................................................41

Figura 5.7:

Tunneling....................................................................................... 42

Figura 5.8:

Newport Networks 1460 session border controller... 42

Figura 5.9:

Signalling proxy..... 43

Figura 5.10:

Garantindo o fluxo de mdia fim-a-fim.......................................... 44

Figura 5.11:

Protocolo IPSec.............................................................................. 46

Figura 5.12:

Operao de NAT com IP e IPSec................................................. 47

Figura 5.13:

UDP Encapsulando IPSec.............................................................. 48

Figura 5.14:

SRTP Header................................................................................. 50

Figura 7.1:

Arquitetura do Asterisk...................................................................64

Figura 7.2:

Interfaces do Asterisk.................................................................... 65

Figura 7.3:

Integrao com PBX Existente...................................................... 66

Figura 8.1:

Estrutura Atual da Rede................................................................. 69

Figura 8.2:

Estrutura Proposta.......................................................................... 70

Figura 8.3:

Fluxo de Dados Utilizando TURN................................................ 72

Figura 8.4:

QoS na Estrutura da Rede.............................................................. 74

LISTA DE TABELAS
Tabela 4.1: Comparativo entre CODECS............................................................... 31
Tabela 4.2: Relao entre Fator R e MOS ............................................................. 32
Tabela 7.1: Comparao entre PBX Convencional e PBX-IP................................ 61
Tabela 8.1: Etapas para Implantao do Servidor VoIP......................................... 75
Tabela 9.1: Etapas para Implantao do Servidor VoIP......................................... 77

RESUMO
Este trabalho apresenta um estudo sobre os diversos aspectos envolvidos na
implementao de um servidor VoIP. Protocolos de sinalizao e transporte, CODECs,
travessia de NAT e firewall, QoS, softwares VoIP so analisados e para cada item so
apresentadas diferentes solues.
Considerando uma empresa e sua atual estrutura de rede, o trabalho prope ainda
uma soluo de implantao, atendendo necessidades como integrao com a central
telefnica tradicional e ampliao do nmero de ramais, sem deixar de considerar a
viabilidade tcnica e financeira da mesma.
Palavras-chave: VoIP, NAT, firewall e QoS.

Requirements and Proposal of VoIP Server Implementation

ABSTRACT
This monograph presents the study of various features involved in a VoIP
implementation. Signaling protocols, transport protocols, CODECs, NAT traversal and
firewall, QoS, VoIP softwares are analysed and, for each case, we present different
solutions.
Regarding a company and its real network, this monograph suggest a solution of
implementation, considering the necessary integration with the PBX, the increasing of
extensions lines, the technical viability and the cost of that.
Keywords: VoIP, NAT, firewall and QoS.

14

1 INTRODUO
A tecnologia VoIP vem sendo largamente utilizada nas corporaes, buscando a
expanso da rede telefnica existente, fugir da dependncia da telefonia tradicional ou
diminuir os custos, cada vez maior o nmero de empresas que adotam esta tecnologia,
utilizando a estrutura fsica j existente para dispor de novos servios.
Este trabalho tem por objetivo levantar e analisar os requisitos necessrios para
implantao de um servidor VoIP, buscando a incluso deste numa rede j existente e
tambm sua integrao com o sistema de telefonia convencional.
O trabalho est dividido em sete captulos sendo que o segundo abordar um pouco
da histria da telefonia, sua evoluo at os dias atuais, a tecnologia VoIP, seus desafios e
tendncias para o futuro.
O terceiro captulo definir os diferentes cenrios de comunicao VoIP, entre
terminais IPs, entre terminal IP e telefone convencional e entre telefones convencionais
utilizando a rede IP. Alm disso, far uma comparao entre os protocolos de sinalizao
H.323 e SIP e apresentar os protocolos de transporte RTP/RTCP.
O quarto captulo discorrer sobre a importncia da utilizao dos CODECs, far
uma breve descrio dos mais utilizados e um comparativo considerando os modelos MOS
e E.
O quinto captulo tratar sobre a importncia e os diversos aspectos que precisam
ser considerados para utilizao de um servidor VoIP ultrapassando NAT e firewall,
diversas tcnicas so abordadas com o intuito de permitir a comunicao visando ao no
comprometimento da segurana da rede. Sero levantados tambm alguns aspectos
referentes privacidade e autenticidade, requisitos necessrios em qualquer comunicao.
O sexto captulo abordar a QOS em comunicaes VoIP, requisito extremamente
importante quando se busca qualidade nas conversaes. Sero analisadas as mtricas que
devem ser consideradas para obteno da qualidade, vazo, atraso, jitter e perdas, os
parmetros necessrios para elaborao de uma SLA e os mecanismos e arquiteturas que
podem ser implementados buscando a melhor qualidade.

15

O stimo captulo far um estudo sobre o Asterisk, software livre que possui as
funcionalidades de um PBX completo, definindo sua arquitetura, interfaces e fazendo uma
comparao com o OpenSer, software que atua como um SIP Proxy.
O oitavo captulo apresentar uma proposta de implementao considerando uma
rede previamente existente, abordando as necessidades de mudanas fsicas e demais
aspectos analisados nos captulos anteriores. Esta proposta se baseia num escopo definido
no incio do oitavo captulo, considerando as necessidades de integrao com os servios
existentes, como por exemplo, a central telefnica convencional.
Espera-se com o exposto acima, atingir todos os pontos que devem ser considerados
na implementao de um servidor VoIP e apresentar tambm diferentes alternativas para
cada necessidade.

16

2 VoIP: UMA VISO GERAL

Desde 1876, quando Alexander Graham Bell patenteou o primeiro aparelho
telefnico, que utilizava o eletromagnetismo para a transmisso de voz distncia, at os
dias de hoje, a telefonia vem se desenvolvendo continuamente.
Passando pela criao da primeira central telefnica (1877); utilizao da primeira
central telefnica automtica (1892); utilizao da primeira central digital e sistema de
discagem direta distncia (1958); utilizao de fibra tica, multiplicando a capacidade de
trfego de sinais telefnicos (1970); telefonia celular (1983), chegamos, em 1995, ao
advento do VoIP (Voice Over Internet Protocol).
A tecnologia VoIP surgiu neste ano em Israel, quando um grupo desenvolveu um
sistema que permitia utilizar os recursos multimdia de um PC domstico para iniciar
conversas de voz pela Internet. Apesar da qualidade no ser muito boa, este foi o primeiro
passo para que outros pesquisadores se interessassem pelo assunto.
Neste mesmo ano, a empresa Vocaltec Inc lanou o primeiro software dedicado
comunicao VoIP, este software fazia a compresso do sinal de voz, traduo em pacotes
de dados e o envio pela rede. Chamado Internet Phone Software, foi o precursor de
softwares como Skype e Messenger, utilizados atualmente.
Em 1998 algumas companhias passam a oferecer servio VoIP com certa qualidade,
interligando-o ao servio de telefonia convencional.
Portanto, VoIP uma tecnologia que permite a comunicao telefnica utilizando a
rede de dados como meio de transmisso da voz, como representado na figura abaixo:

17

Figura 2.1: Comunicao VoIP (IZU et al., 2008)

Em 1998 surgiram os primeiros gateways, equipamentos capazes de interligar

aparelhos telefnicos convencionais ou centrais telefnicas rede de dados, para a
comunicao entre estes sistemas utilizando VoIP.
Em seguida, surgiram gateways especializados e dispositivos chamados ATA
(Adaptador para Telefone Analgico) para interligar dois sistemas convencionais e/ou
centrais, utilizando como meio de transmisso a rede IP.
Com a utilizao de VoIP e os equipamentos desenvolvidos possvel atualmente
fazer a interligao entre centrais telefnicas e redes de dados, permitindo que sejam feitas
ligaes para telefones convencionais utilizando o computador e vice-versa. Da mesma
forma, o aumento das taxas de transmisso permitiu que usurios domsticos tambm
passassem a usufruir desta tecnologia.
VoIP uma tecnologia que digitaliza, comprime e converte sinais de voz
(analgico) em pacotes de dados e os transmite utilizando qualquer rede TCP/IP. Assim que
estes pacotes so recebidos no destino, so convertidos em sinal analgico novamente,
utilizando qualquer meio no qual seja possvel reproduzir o som.
Protocolos de sinalizao so utilizados para estabelecer, desconectar chamadas e
transportar informaes necessrias para localizar usurios e negociar funcionalidades.
Esquemas de compresso (CODECs), habilitados nas extremidades das conexes, assim
como protocolos de transporte (RTP e RTCP) tambm so necessrios.
O grande desafio do VoIP estabelecer a mesma qualidade e confiabilidade
encontrada na telefonia convencional. Problemas como latncia, jitter, congestionamento,
firewalls, NATs e segurana so desafios tcnicos a serem superados. Padres de QoS, por

18

exemplo, podem ser negociados quando utilizamos uma rede privada, onde se tem total
controle, porm, ao utilizarmos a Internet no temos este mesmo controle, o que pode
tornar uma aplicao de voz em tempo real de baixa qualidade.
Nos prximos anos, a tecnologia VoIP deve se tornar um dos principais setores de
crescimento no mercado de telecomunicaes. Muitas empresas vm utilizando a
tecnologia VoIP em PBX (Private Branch Exchange), diminuindo desta forma os gastos
com centrais telefnicas e fazendo uma melhor utilizao da infra-estrutura de rede
existente. Vrias ligaes podem ser executadas simultaneamente, nos perodos de
inatividade de uma conexo a banda pode ser utilizada por outra aplicao, diferentemente
da comutao por circuitos onde o meio de transmisso permanece ocupado durante todo o
perodo da ligao. Alm disso, a utilizao do VoIP nos oferece mobilidade, permitindo ao
usurio atender uma ligao em qualquer lugar que esteja.
A tecnologia VoIP e o oferecimento de novos servios que englobam diversos tipos
de informao vm se mostrando um atrativo para as empresas de telecomunicaes e
tambm para toda a indstria ligada computao. Percebe-se que as tecnologias utilizadas
nos sistemas telefnicos e nas redes de computadores convergem para um ponto em
comum.
Apesar de poucos ambientes utilizarem uma infra-estrutura puramente de telefonia
IP, h um aumento gradual nesta utilizao. Alguns analistas de mercado sugerem que o
avano do VoIP ocasionar a extino por completo do modelo atual de ligaes de longa
distncia pela RTPC (rede telefnica pblica comutada) ou at a erradicao dos sistemas
convencionais de telefonia.

19

3 CENRIOS DE COMUNICAO VoIP, PROTOCOLOS DE

SINALIZAO E TRANSPORTE

3.1 Cenrios de Comunicao VoIP

Em pouco tempo, diversas tecnologias de comunicao de voz sobre redes IP
surgiram como soluo para integrao dos servios de telefonia convencionais e as redes
comutadas por pacotes. Novos equipamentos, protocolos e servios so oferecidos visando
a esta integrao, sempre utilizando o protocolo IP como foco. Neste tpico, apresentamos
os diversos cenrios de comunicao VoIP, evidenciando suas diferenas e o que cada um
necessita para seu funcionamento.
3.1.1 VoIP de Terminal IP para Terminal IP
Na comunicao entre terminais IPs necessrio que os interlocutores utilizem
telefones IP, algum software no computador, os chamados softphones, ou adaptadores de
telefones analgicos (ATAs). Estes softwares e equipamentos so denominados terminais
ou agentes de usurios.
Os telefones IPs tm a capacidade de codificar e decodificar sinais de voz em fluxo
de udio digital e tambm envi-los ou receb-los atravs de uma rede IP. Os softwares
utilizam APIs de captura e reproduo de udio e de comunicao via IP providas pelo
sistema operacional para transmitir e receber as amostras de udio digitalizadas
empacotadas em datagrama IP.
Os adaptadores de telefones analgicos permitem conectar um telefone
convencional ao PC, efetuando a converso analgico-digital.
Os equipamentos utilizados possuem CODECs de udio e uma interface de rede
conectada a uma rede IP para que a conversao seja estabelecida.
Uma comunicao deste tipo necessita apenas do protocolo de transporte
RTP/RTCP para que seja feita a sincronizao das amostras que trafegam na rede IP entre
os agentes. Porm, se forem utilizados servios como redirecionamento de conversaes

20

necessrio a utilizao de protocolos de sinalizao que estabeleam chamadas ou sesses

entre os terminais, como H.323 ou SIP.
Alm disso, caso se deseje que algumas funes estejam disponveis mesmo quando
os agentes no esto operando, como se espera numa central telefnica convencional,
utiliza-se um gateway de gerncia que centraliza as seguintes funes:
-

Controle de acesso: controla o estabelecimento de novas chamadas, verificando

o limite de chamadas simultneas e os privilgios de cada agente, assim como
tambm mantm informaes sobre bilhetagem;
Gerncia de banda passante: controla a utilizao da banda passante, limita o
nmero de chamadas simultneas, restringindo o nmero de chamadas quando
necessrio, utilizando mecanismos de QoS;
Roteamento de chamadas: efetua o roteamento de chamadas com base na
disponibilidade de banda passante.

A figura a seguir apresenta os elementos necessrios para a comunicao entre

terminais IPs:

Figura 3.1: Comunicao de voz de terminal IP para terminal IP (COLCHER

et al., 2005)

21

3.1.2 VoIP de Terminal IP para Telefone

Para que a comunicao entre um terminal IP e um telefone convencional se
estabelea so necessrios, alm dos mesmos elementos utilizados na comunicao entre
terminais IPs, o uso do gateway de voz e do gateway de sinalizao.
O gateway de voz, tambm chamado gateway de mdia, responsvel pela
transmisso dos fluxos de udio entre a rede IP e a RTPC. O gateway de voz tem as
seguintes funes:
-

Codificao e decodificao digital da voz, quando a RTPC analgica;

Transcodificao entre formatos digitais, quando a codificao utilizada na rede
IP difere daquela utilizada na RTPC;
Terminao de chamadas telefnicas na RTPC; e
Transmisso e recepo de amostras de udio digital encapsulados em
datagramas IP.

Os terminais de rede IP vem o gateway de voz como mais um terminal.

J as centrais telefnicas vem o gateway de voz da seguinte forma:
-

Gateway residencial: interligao com interfaces analgicas tradicionais;

Gateway de acesso: interligao com centrais privadas de comutao telefnica
analgica ou digital;
Gateway de trunking: interligao com grande nmero de troncos analgicos ou
digitais da RTPC;
Gateways de voz sobre ATM (Asynchronous Transfer Mode): interligao com
redes de voz sobre redes ATM.

O gateway de sinalizao, tambm chamado controlador de gateway de mdia

(MGCs), controla os pedidos de estabelecimento de chamada que partem tanto da RTPC
para a rede IP como o inverso.
O gateway de sinalizao executa as seguintes funes:
-

Converso de sinalizao: traduz as mensagens ou tons utilizados na RTPC para

a sinalizao VoIP;
Controle de gateway de mdia: efetua o controle da lgica de funcionamento dos
gateways de mdia, requisita a gerao de sinais nas linhas telefnicas ou
notificado a respeito dos eventos iniciados na mesma.

A figura a seguir apresenta os elementos necessrios para a comunicao entre

terminais IP e telefone convencional:

22

Figura 3.2: Comunicao de voz de terminal IP para telefone (COLCHER et al.,

2005)

3.1.3 VoIP de Telefone para Telefone

A comunicao entre dois telefones convencionais se d, normalmente, entre duas
centrais telefnicas distintas. Neste caso, a utilizao de gateways de sinalizao permite
que as centrais utilizem a rede IP para se interligarem. Pode ser utilizado um gateway de
sinalizao para cada central telefnica ou apenas um nico gateway, o que elimina a
necessidade de sinalizao entre os gateways.
Os demais elementos presentes no cenrio terminal IP para telefone tambm so
necessrios neste modelo.
A figura a seguir ilustra o cenrio de comunicao de voz de telefone para telefone,
utilizando um gateway de sinalizao para cada central telefnica:

23

Figura 3.3: Comunicao de voz de telefone para telefone usando redes IP

(COLCHER et al., 2005)

3.2 Protocolos de Sinalizao

Protocolos de sinalizao estabelecem as chamadas ou sesses entre os terminais. A
fora do H.323 est em sua interoperabilidade com a RTPC, enquanto que o SIP (Session
Initiation Protocol) um protocolo desenvolvido especificamente para a Internet, com
grande escalabilidade e flexibilidade. Estes protocolos esto descritos a seguir:
3.2.1 H.323
O ITU-T (International Telecommunication Union Telecommunication
Standardization Sector) definiu a Recomendao H.323 com o objetivo principal de
padronizar a transmisso de dados em sistemas de conferncia audiovisual por meio de
redes comutadas por pacotes, que no provem garantia de QoS. (COLCHER et al., 2005)
Esta recomendao determina os padres a serem utilizados para sinalizao,
estabelecimento de sesses, controle de chamadas, gerenciamento de largura de banda,
controle de admisso, CODECs para transferncia de udio e vdeo e protocolos de
transferncia de dados.
Basicamente, num sistema baseado em H.323, so definidos quatro componentes:
- Terminais: So estaes clientes da rede de onde so originados ou destinados
os fluxos de informao em tempo real. O sistema H.323 especifica quais os
padres de codificao para captura e apresentao de mdias aos quais os
terminais devem dar suporte;
- Gateways: So utilizados quando se quer estabelecer a comunicao entre
terminais de diferentes tipos de rede, um gateway , ao mesmo tempo, de voz e
sinalizao. O gateway efetua a converso do formato de codificao de mdias

24

e a traduo dos procedimentos de estabelecimento e encerramento de

chamadas. Eles garantem a interoperabilidade entre terminais H.323 e a rede
telefnica comutada por circuitos;
Gatekeepers: um gateway de gerncia, o componente mais importante de uma
rede H.323. Permite o controle centralizado do sistema. Nele so registrados
todos os pontos finais e efetuado o controle de admisso de chamadas para as
estaes registradas, controle de largura de banda e a traduo de endereos dos
apelidos dos terminais de rede e gateways para endereos IPs. O gatekeeper
tambm pode efetuar o roteamento de mensagens de sinalizao e controle;
MCU (unidade de controle multiponto): Permite o estabelecimento de
conferncia entre trs ou mais pontos finais. formado por um controlador
multiponto (MC) e processadores multiponto (MP). O MC centraliza o processo
de estabelecimento de chamadas multiponto negociando parmetros de
comunicao entre os pontos finais. J o MP responsvel pelo
encaminhamento de fluxos de udio, vdeo e dados textuais entre os pontos
finais.

Terminais, gateways e MCUs administrados por um nico gatekeeper formam uma

zona de gerncia H.323, existe apenas um gatekeeper ativo em cada zona de gerncia.
Dentre os protocolos utilizados pelo H.323 esto os seguintes:
-

RTP/RTPC: utilizados para o empacotamento de amostras de udio e vdeo

assim tambm como para transmisso e sincronismo de redes comutadas por
pacotes;
H.225: para sinalizao de chamada;
H.245: para controle de mdia; e
H.225.0 RAS: para registro, controle de admisso e determinao de estado de
chamadas, acontecem sempre dos terminais H.323 para o gatekeeper.

Mensagens de sinalizao H.225.0 devem ser transportadas na rede comutada por

pacotes por meio de um servio de entrega fim a fim confivel.
O estabelecimento de uma chamada entre pontos finais sempre necessrio antes de
qualquer comunicao quando se utiliza H.323.
Quando no se utiliza um gatekeeper as mensagens de estabelecimento de chamadas
so trocadas diretamente entre os pontos finais.
Existem dois modos de operao entre os terminais H.323:
-

Modo Direct Routed: O gatekeeper recebe a chamada e prov ao terminal H.323

o endereo IP do terminal chamado, neste ponto, a sinalizao de
estabelecimento de chamada prossegue entre os terminais H.323;
Modo Gatekeeper Routed: O gatekeeper intermedia a sinalizao de
estabelecimento de chamada e de negociao de mdia como se fosse o terminal
chamador.

25

3.2.2 SIP
Proposto pelo IETF (Internet Engineering Task Force) o SIP tem mobilizado muitos
fabricantes da rea de telefonia e dados, por causa de sua flexibilidade, integrao a
aplicaes Internet e de arquitetura aberta.
SIP um protocolo de sinalizao de nvel de aplicao. Ele negocia os termos e as
condies de uma sesso. Estabelece, modifica e finaliza chamadas telefnicas, definindo
os tipos de mdia, padres de codificao utilizados, requisitos de largura de banda e
auxiliando na localizao dos participantes da sesso.
O protocolo SIP baseado no HTTP e no SMTP, suportando o transporte de
qualquer tipo de dados em seus pacotes, utilizando MIME-Types (multipurpose internet
mail extensions), similar ao e-mail, que transporta qualquer tipo de dados em seus anexos.
Por utilizar uma arquitetura cliente/servidor, suas operaes envolvem apenas mtodos de
requisio e respostas, como ocorre tambm no HTTP.
Num sistema SIP, so definidos os seguintes componentes:
-

User Agent (UA): o user agent formado por uma parte cliente (UAC), capaz de
iniciar requisies SIP e uma parte servidor (UAS), capaz de receber e
responder requisies SIP. O UA faz chamadas a endereos parecidos com os
utilizados em e-mail, como por exemplo SIP:user@proxysip.com.br. Agentes de
usurios podem enviar e receber chamadas de outros agentes sem a necessidade
de componentes adicionais do SIP;
Servidos proxy: efetua requisies para outros clientes que no podem fazer
requisies diretamente, o proxy passa adiante as requisies de um UA para
outro servidor SIP, atua tanto como servidor como cliente. O servidor proxy
tambm retm informaes para faturamento;
Servidor de redirecionamento: mapeia um endereo nos diversos endereos
associados a um cliente, fornece informaes ao UA sobre o endereo
solicitado, possibilitando ao UA conect-lo diretamente. Geralmente opera
como um cliente de algum tipo de servio de localizao, normalmente um
banco de dados que mantm as informaes necessrias;
Servidor de registro (registrar): um gateway de gerncia, armazena
informaes sobre as UAs, para fornecer um servio de localizao e traduo
de endereos do domnio que controla. Trabalha em conjunto com o servidor
proxy e o servidor de redirecionamento.

Dentre os protocolos que o SIP utiliza esto os citados abaixo:

-

RTP: para transportar os dados por uma rede comutada por pacotes;
RTCP: para fornecer informaes de controle e tambm QoS;
RTSP (real time streaming protocol): para controlar a entrega de fluxos de
distribuio de mdia;

26

MGCP (media gateway control protocol) e Megaco/H248: para controlar

gateways de mdia;
SDP (session description protocol): para descrever sesses multimdia;
DNS: para determinao do destinatrio dos pedidos;
LDAP: para o acesso direto base de dados de um servidor de localizao;
TRIP (Telephony Routing Over IP): para troca de informaes de
encaminhamento entre domnios administrativos de telefonia;
RSVP: para estabelecer a reserva de recursos.

O SIP opera das seguintes formas:

-

Modo direto (peer to peer): permite um agente SIP enviar requisies

diretamente a outro agente. Um UAC troca mensagens diretamente com um
UAS, negociando parmetros de sesso e estabelecendo comunicao de voz.
Apesar de ser o modo mais simples para estabelecer uma sesso vrios recursos
e servios podem no ser suportados;
Modo indireto (via proxy): h a necessidade de outros servidores que integram a
infra-estrutura baseada em SIP. Neste caso, o agente envia as mensagens de
sinalizao para o servidor proxy, responsvel por encaminh-las e controlar a
entrada e sada de mensagens do sistema. O servidor proxy pode estar integrado
ao servidor de registro e servidor de redirecionamento, evitando o acesso direto
aos mesmos;
Outbound proxy: o proxy recebe pedidos de um terminal, mesmo no sendo ele
o destinatrio. Esta configurao utilizada quando existe um firewall, o UA
configurado para receber e enviar pedidos atravs deste servidor.

Quando utilizamos um servidor proxy, tambm podemos definir de que forma ser
feito o encaminhamento das mensagens:
-

Stateless (sem estado): nenhuma informao sobre a mensagem mantida pelo

proxy;
Stateful (com estado): informaes sobre a mensagem encaminhada so
mantidas pelo proxy, facilitando o encaminhamento de outras mensagens da
mesma sesso.

3.2.3 Diferenas entre H.323 e SIP

Comparando os protocolos H.323 e SIP, podemos chegar as seguintes
consideraes:
-

O H.323 tem sua abordagem voltada para os servios terminais enquanto que a
abordagem do SIP voltada para os usurios de servios integrados na Internet;
Ambos os protocolos utilizam RTP/RTCP para o transporte e controle dos
dados;
O H.323 muito mais extenso que o SIP, tornando-se mais complexa sua
implementao, h a necessidade de um maior esforo do desenvolvedor para
entendimento da especificao;

27

As mensagens H.323 utilizam representao binria enquanto que o SIP utiliza

texto para representao, tornando mais fcil o entendimento deste protocolo;
O suporte a novos CODECs livre no SIP, enquanto que no H.323 os CODECs
devem ser padronizados pelo ITU, dificultando a incluso de CODECs de
terceiros;
Os gateways SIP podem trabalhar tanto no modo stateful como no modo
stateless, enquanto o H.323 trabalha apenas no modo stateful, mantendo sempre
o controle da chamada. Isto pode acarretar perda de performance quando existir
uma grande quantidade de chamadas simultneas.

3.3 Protocolos de Transporte

Os protocolos de transporte RTP/RTCP so definidos pela RFC 3550 do IETF.
3.3.1 RTP
O protocolo RTP permite servios de entrega fim a fim para a transmisso de dados
em tempo real, como por exemplo, transmisso de udio e vdeo, pode ser utilizado
tambm em comunicaes multicast, utiliza o protocolo UDP. O RTP no implementa
solues de QoS, mas permite a aplicao destes mtodos, como IntServ e DiffServ que
sero discutidos mais frente.
Mesmo que faam parte de uma mesma comunicao, diferentes tipos de mdia,
como udio e vdeo, so enviados em sesses diferentes de RTP.
O protocolo oferece as seguintes funes:
-

Padding: sinaliza a adio de octetos em preenchimento adicional ao contedo

da carga (payload) sem fazer parte da mesma. Este preenchimento adicional
normalmente utilizado na transmisso de pequenos pacotes ou quando so
utilizados algoritmos de encriptao que necessitam um tamanho fixo de blocos;
Sequence number (nmero sequencial): esta numerao pe em ordem os
diversos pacotes RTP. Este ordenamento serve para o receptor detectar os
pacotes perdidos e tambm restaurar a sequncia dos pacotes;
Timestamp: indica o instante em que o primeiro octeto de dados foi gerado.
Quando um pacote de fluxo de mdia chega ao destinatrio, o nmero de
sequncia analisado para determinar a sequncia correta dos dados e tambm
para registrar a frao de dados perdidos. O valor do timestamping utilizado
para determinar o espaamento de tempo entre os pacotes. Com estas
informaes o receptor pode reproduzir o udio, observando a taxa na qual o
fluxo foi codificado;
SSRC: identifica a fonte de sincronizao. Cada participante de uma sesso RTP
utiliza um identificador SSRC, este ir identific-lo de forma nica dentro da
sesso;
CSRC: identifica as fontes que contriburam para a formao dos dados contidos
no pacote. Aplica-se a pacotes gerados por mixers. O mixer posicionado perto

28

de locais com banda passante reduzida. Ele resincroniza os pacotes que chegam
neste ponto, gerando um nico pacote, mantendo uma identificao das fontes
que contriburam para esta comunicao, deste modo, as informaes so
recebidas corretamente no destino.
3.3.2 RTCP
O RTPC um protocolo de controle e monitoramento empregado nas conexes
RTP. baseada na transmisso peridica de pacotes de controle a todos os participantes da
sesso, monitorando a qualidade do servio e transportando informaes dos participantes.
(COLCHER et al., 2005)
O RTCP realiza as seguintes funes:
-

Feedback sobre a qualidade do servio: Os receptores indicam a qualidade da

recepo relativa a cada emissor (nmero de pacotes perdidos, jitter e roud-trip
delay), estas informaes so utilizadas pelos emissores para ajustar parmetros;
Sincronizao entre meios: pacotes de udio e vdeo so transportados muitas
vezes em streams separados e necessitam ser sincronizados no receptor;
Identificao dos participantes da sesso: o RTCP responsvel por distribuir o
nome cannico dos participantes (CNAME), este garantir que diferentes mdias
sejam reconhecidas como parte de uma nica comunicao;
Controle da sesso: o perodo entre pacotes RTCP deve ser ajustado
dinamicamente dimenso do grupo (participantes da sesso), procurando que o
percentual de trfego RTCP seja constante no trfego total, evitando
sobrecarregar a rede.

29

4 CODECs
Este captulo apresenta os CODECs de voz que podem ser utilizados na
comunicao VoIP, diferenciando-os e comparando-os em diversos aspectos.
A palavra CODEC uma contrao de codificador e
decodificador e significa um dispositivo que digitaliza
sinais de voz ou vdeo para transmisso por servios
de dados digitais e os converte de volta na outra
ponta. (CHOWDHURY, 2002, p.263)

4.1 Codificao de Voz

Um CODEC converte sinais analgicos para digitais, esta converso feita por
amostragem, desta forma, um fluxo contnuo de informaes (analgico), dividido em um
conjunto de amostras (digital) que sero posteriormente transmitidas e decodificadas na
outra extremidade.
Quanto mais amostras forem utilizadas no tempo, maior ser a fidelidade da amostra
reproduzida logo, quanto maior a amostra, melhor a reproduo. Para compensar, os
CODECs normalmente efetuam a tarefa de compresso de voz, buscando otimizar a
utilizao da largura de banda, estes mtodos de compresso permitem a reproduo com a
mesma fidelidade. Os CODECs podem ser de alta ou baixa complexidade de acordo com o
nmero de ciclos de CPU utilizados nos DSP (Digital Signal Processor).
Os codificadores de voz podem ser classificados da seguinte forma:
-

Baseados na forma do sinal (waveform codecs):

Recuperam o sinal de entrada sem modelar o processo que gerou o sinal;
Podem replicar o som gerado para qualquer tipo de fonte;
No esto otimizados para baixas taxas de bit nem para determinados tipos de
fonte sonora;
Qualidade de sinal elevada;
Largura de banda utilizada elevada;
Delay do algoritmo muito baixo.

Baseados na fonte do sinal (vocoders):

30

O sinal assumido como sendo unicamente voz e no qualquer forma de onda

possvel;
Codificam apenas o suficiente para inteligibilidade e identificao do
interlocutor;
Tentam reproduzir o sinal de acordo com modelos matemticos;
Usam um modelo do aparelho de voz humano para imitar o sinal de origem;
Transmitem os parmetros utilizados no modelo, ao invs do sinal amostrado;
Utilizam pouca largura de banda;
Qualidade de voz baixa;
Voz reproduzida parece sinttica.
-

Hbridos:
Utilizam uma combinao de anlise da forma do sinal e modelagem da fonte;
Boa qualidade;
Baixa largura de banda;
Mais complexos.

Os algoritmos de codificao/digitalizao so padronizados pelo ITU-T, atravs de

recomendaes da srie G.7XX. Cada um destes algoritmos possui caractersticas de
desempenho que devem ser consideradas na escolha de um CODEC:
- Qualidade de voz: medida utilizando uma metodologia chamada MOS (Mean
Option Scores), o MOS varia de uma escala de 1 (qualidade ruim) a 5 (qualidade
excelente);
- Compensao: tambm conhecida como ocultao perda de pacotes. CODECs
que possuem esta caracterstica conseguem compensar a perda de algum pacote
de voz, fazendo com que o usurio no a perceba;
- Silncio e rudo: alguns CODECs detectam silncio ou intervalo sem presena
de voz, no o transmitindo, gerando economia de banda;
- Atraso de compresso de voz: tempo necessrio para compresso da voz;
- Taxa de produo de amostras digitais: medida em kbit/s.
O ITU-T especificou padres recomendados para a codificao de voz. A tabela a
seguir demonstra a utilizao em ambientes de teste, no considerando jitter, atraso, perda
de pacotes ou pacotes desordenados.

31

Tabela 4.1: Comparativo entre CODECs

Padro

Algoritmo

G.711

PCM

G.722

SBC/DPCM
MP-MLQ ou
G.723.1
ACELP

Taxa de
Compresso
(Kbps)
48, 56, 64
(sem
compresso)
64

Recursos de
Processamento
Necessrio

Qualidade de
Voz

Nenhum

Excelente

5.3, 6.4

Moderado

Moderado

G.726

ADDPCM

16, 24, 32, 40

Baixo

G.728
G.729

LD-CELP
CS-ACELP

16
8

Muito Alto
Alto

Atraso
MOS
Adicionado Estimado
Nenhum

4,2

Excelente
Alto
Boa (6.4)
3,9 (6.4)
Alto
Moderada (5.3)
3,7 (5.3)
Boa (40)
Muito Baixo
4,3
Moderada (24)
Boa
Baixo
4,3
Boa
Baixo
4

Fonte: ITU-T

Em comparao com o modelo MOS, podemos tambm utilizar o Modelo E. Este

modelo computacional complexo avalia e quantifica a degradao da qualidade das
ligaes, para tal, considera:
-

Taxa de transmisso;
Relao bsica sinal-rudo;
Fator degenerativo simultneo;
Fator degenerativo de atraso;
Fator degenerativo de equipamentos;
Fator de expectativa.

O E-model resulta em um nmero chamado de fator R, derivado de atrasos e fatores

de deteriorizao causados pelos equipamentos. O fator R medido pode ser mapeado por
um MOS estimado, varia de 100 (excelente) a 0 (no recomendado). Este modelo
recomendado para avaliao da qualidade das chamadas VoIP.
Para que uma rede possibilite uma boa qualidade da chamada VoIP recomendado
que o atraso fim-a-fim seja menor que 150 ms, um limite mximo de 50 ms para a variao
do atraso e taxa de perda limitada a 3%. O no respeito a estes limites gera degradaes de
qualidade de voz perceptveis ao usurio.
A seguir, a tabela comparativa entre MOS e Modelo E:

32

Tabela 4.2: Relao entre Fator R e MOS

Fator R

MOS

Satisfao

90 R 100

4,3 4,5

tima

80 R 90

4 4,3

Boa

70 R 80

3,6 4

Mediana

60 R 70

3,1 3,6

Pobre

50 R 60

2,6 3,10

Ruim

00 R 50

1 2,6

Pssima

Fonte: ITU-T
As solues disponveis no mercado permitem a utilizao de diferentes CODECs
de acordo com a rede em questo ou at mesmo alterao do CODEC depois de
estabelecida a comunicao.

4.2 G.711
O CODEC G.711 a escolha natural para redes locais. Baseado em forma de onda,
segundo HERSENT, 2002, utiliza uma escala semi-logartmica chamado de PCM (Pulse
Code Modulation), aumentando desta forma os sinais de baixa amplitude enquanto que os
de alta amplitude so tratados de forma proporcional, operando de forma anloga ao ouvido
humano. Existem dois mtodos de compactao para codificar um sinal PCM: -law e Alaw. Como exemplo, temos um sinal analgico de 4000 Hz (voz) que amostrado,
quantizado e codificado, gerando um fluxo digital com 8000 amostras por segundo, com 8
bits cada, consumindo 64 kbit/s. O espectro acima de 4000 Hz cortado na utilizao do
G.711.

4.3 G.722
O CODEC G.722 oferece uma tima qualidade de udio e necessita pouco esforo
de processamento, porm, ainda pouco sensvel a erros de transmisso, tambm baseado
em forma de onda. Permite a codificao de 7000 Hz do espectro de voz, consumindo 48,
56 ou 64 kbit/s, utilizando o mtodo de compresso SBADPCM (Sub-band Adaptive
Diferencial Pulse Code Modulation).

4.4 G.732.1
Baseado em vocoders, este CODEC pode apresentar problemas de sincronismo caso
haja perda de pacotes, podendo necessitar de quadros extras para o reestabelecimento do
sincronismo. Possui deteco de presena de voz, transmisso descontinuada e gerao de
rudo de conforto. Utiliza comprimento de quadro de 30 ms e necessita de 7,5 ms de
previso. Utiliza-se de dois mtodos de compresso: MP-MLQ (Multi-Pulse, Multi-Level
Quantization), operando a 64 kbit/s ou ACELP (Algebraic Code Excited Linear Prediction),
operando a 5,3 kbit/s.

33

4.5 G.726
Este CODEC, tambm baseado em forma de onda, utiliza o mtodo de compresso
ADPCM (Adaptative Diferencial Pulse Code Modulation) para codificar um fluxo G.711
em palavras de 2, 3 ou 4 bits, resultando em taxas de 16, 24 e 32 kbit/s. Quando utilizado a
32 Kbps atinge a pontuao MOS de 4.3, sendo utilizado como referncia para qualidade
telefnica.

4.6 G.728
Utilizando o mtodo de compresso LD-CELP (Low-Delay Code Excited Linear
Prediction), um codificador otimizado para voz, baseado em vocoders. Sua pontuao
MOS de 4.3 com uma taxa de apenas 16 kbit/s. Este CODEC modela especificamente
sons de voz e funciona comparando a forma da onda a ser codificada com um conjunto de
modelos de forma de onda e busca aquele que seja mais parecido. Faz-se ento necessrio a
transmisso apenas do ndice da onda mais parecida, da freqncia fundamental da voz e
mais alguns parmetros. A utilizao de modems de baixa velocidade obteve bons
resultados com a utilizao deste CODEC.

4.7 G.729
O CODEC G.729 utiliza o mtodo de compresso CS-ACELP (Conjugate-Structure
Algebraic Code-Excited Linear Prediction), produzindo quadros de 80 bits codificando 10
ms de fala a uma taxa de 8 Kbps, exigindo um esquema de previso de 5 ms. Este CODEC,
baseado em vocoders, bastante popular em aplicaes que utilizam voz sobre frame-relay.
Permite o envio de rudo de conforto evitando o envio de pacotes normais contendo apenas
silncio.

34

5 NAT/Firewall e Privacidade/Autenticidade em VoIP

Segurana e eficincia so muitas vezes requisitos conflitantes. Apesar de haver
reas na Internet onde o impacto desses mecanismos de segurana menor, as aplicaes
em tempo real como VoIP podem ser seriamente afetadas. A introduo de uma outra
camada para garantir a segurana, pode tornar mais lentas as transmisses de pacotes,
muitas vezes no sendo aceitveis para transmisses em tempo real, como alguns
mecanismos de criptografia. Logo, vrios aspectos devem ser analisados quando se tenta
transmitir esses tipos de mdia atravs de canais seguros. (PASSITO et al., apud
BARBIERI, 2002)
Este captulo ir abordar alguns aspectos de extrema importncia e que muito
afetaro a implementao proposta mais adiante, como prover a segurana e permitir a
comunicao VoIP em redes distintas que utilizam NAT e firewall e tambm como garantir
a privacidade e autenticidade dos dados quando necessrio. Verificaremos os problemas
que esta estrutura apresenta e possveis solues para a mesma.

5.1 NATs e Firewalls em VoIP

Com a utilizao de aplicaes VoIP, encontramos vrios problemas para
ultrapassar NATs e firewalls visto que a operao normal destes baseada em trfego que
pode ser determinado por um conjunto de regras estticas, o que no ocorre com os
protocolos utilizados em VoIP.
O NAT faz a traduo de endereos IPs e portas da rede local, invlidos, para
endereos vlidos utilizados na Internet. Ou seja, um pacote enviado ou a ser recebido por
uma estao de trabalho da rede local passa por um servidor que o traduz num endereo
vlido quando enviado para a Internet e no endereo correto da rede interna quando este
est sendo encaminhado da Internet para uma estao de trabalho.
Como os principais protocolos de transporte (TCP e UDP) utilizam o conceito de
multiplexao atravs de portas de origem e destino, podemos utilizar apenas um endereo
IP pblico para traduzir vrios endereos privados, utilizando portas diferentes e
armazenando estas informaes em uma tabela de conexes.
Apesar de efetuar esta traduo de endereos e permitir a comunicao da rede
interna com a Internet, o NAT apresenta os seguintes problemas:

35

No possvel efetuar a traduo de endereos para chamadas iniciadas de fora

da rede, no solicitadas. Mesmo que o usurio tenha conhecimento do endereo
a que deseja chamar, este no rotevel na rede pblica;
Mensasgens SIP fim-a fim entre clientes tambm no so roteveis. As
mensagens SIP contm o endereo IP e porta originais, que sero utilizados
pelos fluxos de mdia logo, a comunicao fim-a-fim entre os clientes falha
porque estes endereos no so roteveis na Internet;
Aps algum tempo, o NAT encerra qualquer conexo UDP caso nenhum pacote
esteja sendo transmitido, se um dos lados est apenas ouvindo e no transmite
nenhum pacote, esta conexo ser encerrada, considerada pelo NAT uma
conexo inativa.

Figura 5.1: NAT bloqueia fluxo de mdia fim-a-fim (Newport Networks, 2006)

O firewall tem como objetivo proteger a rede privada de ser acessada por fontes no
autorizadas. Este controle feito atravs do bloqueio de trfego baseado em trs
parmetros: fonte, destino e tipo de trfego. Basicamente, o firewall permite que pacotes
vindos da rede privada alcancem a rede pblica e controla os pacotes vindos da rede
pblica, permitindo normalmente a passagem de pacotes associados a uma conexo iniciada
internamente.
Enquanto que um firewall capaz de abrir e fechar portas dinamicamente, como a
sinalizao VoIP requer, ela fica sem efeito para fluxos de mdia que chegam de redes
externas.
Muitos administradores so relutantes em modificar esta poltica, permitindo
comunicao irrestrita nos dois sentidos, devido a srios riscos criados. Qualquer soluo

36

deve fornecer segurana na comunicao em ambos os sentidos, sem afetar em grandes

modificaes nas regras e sem reduzir o nvel de segurana existente.

Figura 5.2: O problema do firewall (Newport Networks, 2006)

Qualquer abordagem para solucionar os problemas anteriormente listados, deve

permitir uma comunicao segura nos dois caminhos, incluindo chamadas no solicitadas e
tambm minimizar dependncias na atualizao de NATs e firewalls.
As aplicaes VoIP precisam descobrir e utilizar o endereo e porta externo que
selecionado pelo NAT na sinalizao. O cliente VoIP, de posse dessas informaes pode
coloc-los dentro da sinalizao para estabelecer a chamada, assegurando a conectividade
fim-a-fim, porm, precisa encontrar um meio de utiliz-lo tambm na transmisso dos
fluxos de mdia.
Sero descritos a seguir alguns mecanismos para resolver estes problemas.
5.1.1 Universal Plug and Play (UPnP)
Esta tecnologia foi desenvolvida para pequenos usurios de escritrios e
domsticos.
Ela foi projetada para tratar vrias questes, no apenas VoIP. UPnP permite que
aplicaes cliente descubram e configurem componentes de rede, mapeando portas internas
para portas externas.
Um cliente pode perguntar ao NAT um endereo particular IP e porta, que o NAT
selecionou para sinalizao e transmisso, atravs do protocolo chamado UPnP. Obtendo

37

esta informao, o cliente VoIP pode utiliz-la na sinalizao e estabelecer a chamada,

utilizando endereos e portas pblicas roteveis, efetuando assim conexes fim-afim.
No entanto, esta abordagem no resolve o problema de segurana de forma
satisfatria, existe um pequeno nmero de fabricantes comprometidos em usar UPnP,
muitos User Agents e NATs no o suportam.
um mtodo que pode ser implementado em pequenas redes.
5.1.2 Simple Traversal of UDP Trought Network Address Translators (STUN)
Este protocolo permite que o cliente descubra se est atrs de um NAT e determine
o tipo de NAT que a rede possui.
A proposta deste protocolo define um servidor especial para informar o cliente SIP
STUN-enabled, na rede privada, qual o endereo utilizado na rede pblica para cada sesso,
este endereo ser utilizado na mensagem de estabelecimento da chamada.
O servidor STUN efetua este processo examinando as mensagens que chegam ao
servidor, mas no se preocupa com sinalizao ou transmisso de dados.
O STUN confia que uma vez mapeada a porta pelo servidor STUN, qualquer
trfego de entrada ou sada ser capaz de usar o mapeamento na direo reversa e atingir a
porta de recepo do cliente. Com isso, o NAT fica susceptvel a ataques e cria problemas
de segurana, introduzindo riscos adicionais ao firewall.
O STUN recebeu uma ateno, como uma tcnica, pelo IETF, porm, alguns
problemas foram identificados. O STUN no funciona com NAT simtrico, que o tipo de
configurao mais comum encontrado nas corporaes e tambm no trata a necessidade de
suportar dispositivos SIP baseados em TCP.

38

Figura 5.3: STUN (Newport Networks, 2006)

5.1.3 Traversal Using Relay NAT (TURN)

O IETF props um mecanismos adicional, TURN, com o objetivo de resolver o
problema de NATs simtricos, problema este no resolvido pelo STUN.
O TURN se baseia num servidor que inserido no caminho da sinalizao e mdia,
localizado na DMZ ou no provedor de servios de rede, este prov um endereo externo
que atua como relay e garante que o trfego alcanar o endereo interno, ele atua como um
intermedirio entre o endereo origem e destino.
O cliente SIP TURN-enabled envia um pacote exploratrio para o servidor TURN,
que responde informando o IP e porta pblica utilizada pelo NAT, utilizando-se desta
informao no estabelecimento da chamada SIP e na transferncia de dados. Neste caso,
no h como o NAT ver o endereo de destino, podendo ento ser utilizado o NAT
simtrico. Alm disso, alguns itens de segurana foram associados ao TURN, aumentando
sua aceitao.
O TURN aumenta o consumo de banda uma vez que os dados so transmitidos duas
vezes, da origem ao servidor TURN e do servidor TURN ao destino.
Este mtodo adiciona uma complexidade, logo, requer que os softphones dos
clientes sejam atualizados pelos desenvolvedores para suporta-los, o que gera sempre uma
relutncia na utilizao.

39

Figura 5.4: TURN (Newport Networks, 2006)

5.1.4 Application Layer Gateway (ALG)

Esta tcnica se baseia na instalao de um novo NAT/firewall, chamado ALG que
entende as mensagens de sinalizao SIP e as altera para permitir a comunicao VoIP fima-fim.
Esta tcnica processa a sinalizao e o trfego, alterando a sinalizao de forma a
refletir o endereo IP e porta pblica utilizados para a sinalizao e posterior trfego de
mdia. ALG tem a vantagem de ser transparente para User Agents e servidores VoIP.
Como dito anteriormente, esta tcnica requer a substituio do NAT/firewall,
alternativamente, alguns fabricantes provm atualizaes de software para suportar as
funcionalidades do ALG.
O ALG requer prtica para configuraes e administrao de NAT e firewall,
indicando que upgrades ou atualizaes no so simples. ALG deve ser implementado de
forma cautelosa em grandes corporaes que possuam suporte adequado.

40

Figura 5.5: ALG (Newport Networks, 2006)

5.1.5 Configurao Manual

Esta tcnica recomendada apenas para pequenas redes, em virtude de ser manual e
necessitar configuraes fixas.
O cliente neste caso configurado com detalhes de endereo IP e porta pblica que
o NAT utilizar para sinalizao e trfego de mdia e tambm ter IP e porta fixo para
receber as mesmas informaes.
O NAT tambm configurado manualmente com mapeamento esttico para cada
cliente.

41

Figura 5.6: Configurao Manual (Newport Networks, 2006)

5.1.6 Tcnicas de Tunelamento

Este mtodo utiliza tunelamento para atravessar NAT e firewall. Ele requer a
existncia de um servidor dentro da rede privada e outro na rede pblica, criando um tnel
no criptografado entre eles, transportando todo o trfego SIP por um firewall
reconfigurado. Este mtodo pode ocasionar atrasos, reduzindo desta forma a qualidade da
voz.
O servidor externo modifica o sinal para refletir a porta de sada permitindo ao
sistema VoIP efetuar e receber chamadas.
Este mtodo produz pequenas mudanas nas polticas de segurana, mas pode criar
riscos adicionais por possuir um servidor externo, vulnervel e que pode ser utilizado para
acessar a rede interna.

42

Figura 5.7: Tunneling (Newport Networks, 2006)

5.1.7 Automatic Channel Mapping (ACM)

O Newport Networks 1460 session border controller, equipado com a aplicao
ACM especificamente desenvolvido para resolver problemas de NAT e firewall, sem
necessitar alteraes nas regras de segurana. Ele habilita tradues de endereos de rede
(NAT) e firewall para acesso seguro rede.

Figura 5.8: Newport Networks 1460 session border controller (Newport Networks,
2006)

43

Para resolver o problema de traduo de endereos so utilizados os seguintes

componentes: Signalling Proxy e Media Proxy.
O signalling proxy tem como funo fazer com que endereos no roteveis da rede
privada sejam repassados rede pblica. O signalling proxy age como um B2BUA (back to
back user agent) de alta performance. Este proxy configurado como um ponto de
transio para mensagens de sinalizao SIP entre o cliente e o servidor, garantindo que
todas as mensagens passem por ele.
As mensagens de sinalizao SIP destinadas ao signalling proxy deixam a rede
privada utilizando IP e porta alocados pelo NAT. Quando o signalling proxy recebe a
mensagem inicial (User Agent) , um endereo de origem no signalling proxy alocado para
as mensagens de sinalizao deste cliente. Uma mensagem de registro modificado
encaminhada para o Call Agent, indicando o signalling proxy como origem.

Figura 5.9: Signalling Proxy (Newport Networks, 2006)

O media proxy opera por baixo do controle do signalling proxy para prover um
ponto de trnsito para streams RTP e RTCP entre agentes.
Para garantir que o provedor de servio tenha total visibilidade e controle do stream
de mdia, garantindo qualidade de servio, toda a mdia direcionada para o media proxy.
O media proxy usa NAT dinmico para esconder detalhes da rede, ajudando a
prover proteo contra DoS, negao de servio.

44

Na utilizao de NAT as portas alocadas para fluxos de mdia para cada cliente so
imprevisveis. Utilizando o Newport Network o signalling proxy manipula as mensagens de
sinalizao, garantindo desta forma que os streams de mdia sejam direcionados para portas
alocadas dinamicamente no media proxy.
O signalling proxy e o media proxy utilizam o protocolo interno MEGACO/H.248
para troca de informaes.
Quando o User Agent inicia uma chamada, o signalling proxy recebe uma
mensagem e se comunica com o media proxy para obter informaes do NAT. O IP de
origem e o campo SDP so ento modificados, definindo o signalling proxy como caminho
de retorno para sinalizao e o media proxy como caminho de retorno da mdia.
O endereo IP e porta utilizados pelo NAT so facilmente determinados lendo-se os
detalhes do stream de mdia. Logo, todos os fluxos de sinalizao passam pelo signalling
proxy enquanto que todos os fluxos de mdia passam pelo media proxy, permitindo ao
provedor de servio todo o controle da conexo.
Resolver o problema do firewall significa prover segurana na entrada de mdias
no solicitadas, IPs e portas desconhecidas.
No Newport Network, o media proxy age como um ponto de transio entre as
sesses de mdias, que so sempre iniciadas dentro do firewall, enviadas por IP e porta do
media proxy dinamicamente alocados para a sesso. O media proxy aprende ento o
endereo pblico de origem, retornando o stream de entrada para o mesmo endereo e
porta.

Figura 5.10: Garantindo o fluxo de mdia fim-a-fim (Newport Networks, 2006)

45

5.2 Privacidade/Autenticidade em VoIP

Alm dos problemas mencionados nas sesses anteriores, nos deparamos muitas
vezes tambm com a necessidade de prover privacidade e/ou autenticidade dos dados.
Confidencialidade ou privacidade a garantia que a informao no estar
disponvel a pessoas no autorizadas, normalmente este processo feito com utilizao de
criptografia.
J a autenticidade a garantia da origem da informao e juntamente com a
integridade garantem que a mesma tambm no sofreu alteraes.
A seguir, sero descritas quatro formas de prover privacidade e autenticidade em
VoIP. importante salientar que, exceto em VoIP sobre SSL, os demais protocolos
provem apenas segurana de mdia e no na sinalizao.
5.2.1 IP Security
O protocolo IPSec amplamente utilizado para prover segurana em ambientes
corporativos, uma vez que o protocolo IP no possui nenhuma caracterstica de segurana.
O IPSec introduziu criptografia, autenticao, validao de integridade e anti-replay.
Pode ser utilizado para proteger uma comunicao fim-a-fim ou entre dois sistemas
intermedirios, chamados gateways de segurana, conectados aos sistemas finais.
O IPSec oferece criptografia e autenticidade, sendo necessrio a utilizao do
mesmo algoritmo e chaves criptogrficas pelas partes comunicantes. O IPSec utiliza uma
associao segura (AS) para gerenciar as particularidades da sesso.
O IPSec utiliza os seguintes protocolos:
-

Authentication Header (AH): prov autenticao da origem, checagem de

integridade da mensagem e anti-replay. O payload no encriptado, apenas h
modificao no cabealho;
Encapsulating Security Payload (ESP): prov checagem da integridade da
mensagem, confidencialidade dos dados, anti-replay e autenticao.

E tambm possui dois modos de conexo:

-

Modo tnel (TS 33.210 interconexo e ncleo): este modo utilizado para
interconexo de redes, o trfego capturado por um gateway de segurana e
criptografado;
Modo transporte (TS 33.203 acesso): este modo utilizado para garantir
segurana em comunicaes fim-a-fim, somente o segmento da camada de
transporte criptografado e autenticado.

46

No modo transporte AH, o payload e o cabealho IP so protegidos com a insero

de um novo cabealho entre o original e o payload. No modo tnel, todo o pacote IP
encapsulado dentro do AH e de um novo cabealho IP, contendo, por exemplo, o endereo
do gateway de segurana.
O cabealho AH permite a deteco de pacotes fora de seqncia, autenticao do
remetente e tambm protege a integridade do cabealho e do payload. Ao receber o pacote,
o destinatrio recalcula o hash e verificando diferenas, descarta o pacote.
Desta forma, IPSec AH incompatvel com NAT, j que o NAT altera o cabealho
do pacote e o destinatrio, verificando esta alterao, descartar o pacote.
J no modo de conexo ESP em modo transporte e tnel os dados so encapsulados
e anexados ao cabealho IP original. No modo transporte apenas o payload do pacote TCP
ou UDP encapsulado, enquanto que no modo tnel todo o pacote encapsulado. Neste
caso, no checado se a parte criptografada est de acordo com a parte no criptografada,
permitindo assim atravessar o NAT.

Figura 5.11: Protocolo IPSec (Newport Networks, 2006)

O ESP com autenticao prov a segurana necessria para prover um caminho

seguro para aplicaes de sinalizao VoIP.

47

O problema na utilizao do NAT com IPSec consiste em que NATs so utilizados

para mapear vrios dispositivos numa rede privada, alterando o protocolo de transporte
TCP e UDP. Ocorre que quando o NAT encontra um pacote IPSec ESP ele ir traduzir o IP
privado para um IP pblico. O problema ocorre quando vrios IPSec precisam se
comunicar com o mesmo servidor, pois o IPSec encapsula e esconde a informao da porta
que o NAT necessita para criar ligaes nicas, ocasionando que vrias conexes tentaro
acessar o mesmo servidor, utilizando o mesmo IP e porta, desta forma, no h como
retornar o trfego para o telefone correto.

Figura: 5.12: Operao de NAT com IP e IPSec (Newport Networks, 2006)

O TISPAN (Telecoms & Internet Converged Services & Protocols for Advanced
Networks) oferece uma soluo alternativa para garantir segurana na sinalizao do
telefone ao servidor numa rede. Ele reconhece que transpor o NAT no possvel com as
solues de segurana do IMS security framework (TS 33.203) e prope a utilizao de
UDP encapsulando IPSec, de acordo com a RFC 3948.

48

Este encapsulamento ocorre em dois estgios, primeiro, a mensagem original

encapsulada utilizando IPSec ESP, que encapsulado em outro cabealho UDP. Esta
mensagem ento enviada utilizando-se a porta 4500. O NAT pode trocar o IP de origem e
a porta sem afetar o payload do IPSec. O processo inverso chamado de Deencapsulamento.
Desta forma, o NAT pode ser ultrapassado, efetuando a traduo de endereo e
porta de forma normal. Sendo uma extenso do IMS security framework, outros
mecanismos, como troca de chaves, permanecem inalterados.

Figura 5.13: UDP encapsulando IPSec (Newport Networks, 2006)

Alm das questes expostas acima, o IPSEC necessita introduzir novos cabealhos
no datagrama IP para oferecer os servios de segurana, aumentando consideravelmente o
tamanho do datagrama. (HERSENT, 2002)
Uma conseqncia desse aumento que a taxa do tamanho atual do payload em
relao ao tamanho total do pacote se degrada, diminuindo a carga til transportada na
banda. Esse aumento do pacote no reflete negativamente apenas na banda, mas tambm
impacta nos atrasos de transmisso, roteadores, enfileiramentos, enfim, no atraso total dos
pacotes. (PASSITO et al., apud BARBIERI, 2002)

49

5.2.2 SRTP
Com a ausncia de definio de meios para implantar segurana em RTP/RTCP, o
IETF elaborou a RFC 3711, de maro de 2004, que definiu os protocolos SRTP (Secure
Real-Time Transport Protocol) e o SRTCP (Secure RTP Control Protocol).
O SRTP oferece confidencialidade, autenticidade e proteo contra replays dos
pacotes RTP, prevenindo desta forma ataques como escuta do RTP, manipulao do SSRC
(Synchronization Source) e manipulao do CODEC. Assim como o RTP, o RTCP possui
tambm um protocolo para prover segurana, o SRTCP, que possui as mesmas
caractersticas de segurana do SRTP.
Para evitar a manipulao dos protocolos de sinalizao e tambm a utilizao do
trfego de udio por terceiros, faz-se necessrio a utilizao de criptografia, desta forma,
mesmo capturados por terceiros, os dados sero inteis, no sendo possvel ouvir a
conversa.
O SRTP utiliza o protocolo Multimdia Internet Keying (MIKEY) para
gerenciamento das chaves, este utiliza um sistema de chaves pr-compartilhadas, infraestrutura de chave pblica e o algoritmo Diffie-Hellman para troca das chaves.
A RFC define a utilizao do algoritmo AES (Advanced Encryption Standard), de
128 bits, de chave simtrica para criptografia de mdia, proporcionando um nvel de
segurana elevado para o trfego de udio e define a utilizao do HMAC-SHA1 para
autenticao e integridade.
O payload do RTP encriptado e encapsulado em um pacote SRTP, este se baseia
em uma chave de encriptao, uma funo hash para autenticao da mensagem e no
nmero seqencial do RTP, no efetuando nenhuma alterao no cabealho do RTP. O
SRTP inclui no cabealho um campo adicional chamado Authentication Tag, que possui
dados de autenticao da mensagem e um campo chamado MKI (Master Key Identifier),
ambos opcionais.

50

Figura 5.14: SRTP Header (Snom VoIP Phones, 2006)

Acima est representado o cabealho do pacote SRTP, desta forma garantido

confidencialidade ao payload e integridade para todo pacote RTP.
Apesar da implantao da segurana, o SRTP prov uma alta vazo com pouco
overhead adicional nos pacotes dos fluxos de dados, sendo desta forma adequado para
ambientes heterogneos.
5.2.3 zRTP
O zRTP um protocolo para criptografia de udio que utiliza o algoritmo DiffieHellman para troca de chaves seguras, ele prov confidencialidade e proteo contra
ataques Man in the Middle.
Este protocolo gera um segredo compartilhado que ser utilizado posteriormente
para gerar as chaves, passando assim para uma sesso SRTP. Este procedimento efetuado
durante a chamada e transportado na mesma porta utilizada pelo stream de mdia RTP,
esta sesso estabelecida normalmente por um protocolo de sinalizao, por exemplo, SIP.
(Zfone Project, 2008)
O protocolo no requer um segredo compartilhado anteriormente, infra-estrutura de
chave pblica ou autoridades certificadoras, as chaves Diffie-Hellman so geradas no
estabelecimento de cada sesso. (Zfone Project, 2008)
O algoritmo Diffie-Hellman sozinho no prov segurana contra ataques Man in the
Middle, para autenticar a troca de chaves o zRTP utiliza o Short Authentication String
(SAS), que um hash de dois valores Diffie-Hellman. Este valor distribudo para os dois

51

pontos finais da chamada e conferido durante a conexo para garantir autenticao. A

alterao deste valor indica ataque Man in the Middle e a no alterao indica uma alta
probabilidade do ataque no ter ocorrido. (STALLINGS, 2003)
O zRTP prov um segundo nvel de autenticao contra ataques Man in the Middle
utilizando um hash da chamada anterior juntamente com o segredo compartilhado da
prxima chamada, portanto, se no h ataque na primeira chamada, este tambm no dever
ocorrer nas subseqentes.
O IETF pretende adicionar ainda proteo de integridade nas informaes da sesso
SIP e esta proteo utilizar a infra-estrutura de chave pblica, adicionando assim mais
proteo contra ataques Man in the Middle.
5.2.4

VoIP sobre SSL

O SSL (Secure Sockets Layer) um protocolo que visa estabelecer uma

comunicao segura entre dois pontos na Internet, provendo autenticidade, integridade e
confidencialidade dos dados. O SSL ajuda a prevenir que intermedirios tenham acesso
indevido ou alterem os dados que esto sendo transmitidos.
O protocolo composto de trs fases:
-

Handshake: estabelecimento da conexo;

Clculo de chaves: autenticao
Transferncia de dados: utilizando criptografia.

SSL necessita de certificados, emitidos por autoridades certificadoras, que possuem

informaes como o nome da entidade que o forneceu e o time stamp. Alm do certificado,
dois tipos de chaves so utilizadas pelo protocolo, chaves privadas so utilizadas pelos
servidores e nunca so distribudas e chaves pblicas so distribudas para os clientes.
Dados criptografados com a chave pblica s podem ser decriptografados com a chave
privada.
Chamadas VoIP normalmente no so criptografadas, a utilizao do protocolo SSL
pode ser utilizado quando a confidencialidade se faz necessria. Desenvolvedores VoIP
podem integrar o protocolo SSL em suas aplicaes, o mais fcil utilizar o SSL nos
protocolos de sinalizao.

52

6 QoS EM VoIP
Este captulo ir tratar dos problemas e dos mecanismos necessrios para se obter a
qualidade de servio desejada nas aplicaes VoIP. Sero verificados os parmetros que
devem ser considerados para obteno de qualidade, os mecanismos utilizados para
obteno de QoS e como as principais arquiteturas, IntServ e DiffServ, provm QoS e
buscam um melhor desempenho no encaminhamento de pacotes em uma rede IP.
preciso definir claramente os parmetros de vazo, atraso, jitter e perda quando se
espera a obteno de qualidade de servio (QoS) em uma aplicao VoIP.
O desafio construir um sistema de comunicao genrico que d suporte s
diversas mdias e s caractersticas de trfego por elas impostas, de acordo com os nveis de
qualidade almejados pelas aplicaes. (COLCHER et al., 2005)

6.1 Mtricas de QoS

Para que obtenhamos QoS necessrio considerar os seguintes parmetros:
-

Vazo: o parmetro bsico de QoS, qualquer aplicao necessita de banda para

operar adequadamente;
Atraso: a soma dos atrasos impostos pela rede e equipamentos utilizados na
comunicao, este atraso ou latncia implica em um tempo de resposta da
aplicao. Os principais fatores que influenciam na latncia da rede so o atraso
de propagao, velocidade de transmisso e processamento nos equipamentos.
Jitter: a variao no atraso, pode se dar em funo da variao do tempo ou at
da sequncia de entrega de pacotes, em aplicaes VoIP necessrio que as
informaes sejam processadas em perodos de tempo bem definidos e que os
pacotes sejam entregues na ordem correta;
Perdas: as perdas de pacotes ocorrem por erro e congestionamento (descarte),
em aplicaes VoIP preciso garantir limites razoveis de perda para que a voz
digitalizada tenha uma qualidade aceitvel.

53

A garantia de QoS implica na atuao em todos os equipamentos envolvidos na

comunicao fim-a-fim, garantindo a entrega da informao do host de origem at o host de
destino. Quando tratamos de QoS em VoIP, precisamos considerar principalmente atraso,
jitter e perda de pacotes.

6.2 Proviso de QoS

A solicitao de QoS da aplicao expressa e solicitada por um contrato de servio
chamado de SLA, Service Level Agreement. Ela garantida pela rede, seus componentes e
equipamentos. A SLA deve definir claramente os requisitos necessrios para obteno da
qualidade.
A proviso de QoS efetuada em diferentes fases do ciclo de vida de um servio:
-

Solicitao do servio: caracterizao do trfego e especificao da QoS a ser

aplicada, implica na alterao do estado interno da rede;
Estabelecimento de contratos de servios: aplicao gera fluxos em
conformidade com o que foi especificado na solicitao do servio;
Manuteno do contrato de servio: a rede deve empregar mecanismos
apropriados de forma a manter o nvel de QoS solicitado pela aplicao;
Trmino do contrato de servio: aplicao informa rede a inteno de finalizar
o controle estabelecido, liberando os recursos.

6.3 Mecanismos de QoS

Uma vez identificadas as mtricas para obteno de QoS, verificaremos os
mecanismos, algoritmos e protocolos utilizados na implementao da qualidade de servio.
Numa rede IP, a garantia de QoS consiste num mecanismo fim-a-fim, atuando em todos os
equipamentos envolvidos e garantido a entrega da informao. Os mecanismos que sero
implementados nos equipamentos devem atuar de forma integrada e cabe ao gerente de TI a
escolha e implementao dos mecanismos adequados.
6.3.1 Tratamento de Filas
Para que haja controle de admisso e escalonamento dos pacotes necessrio que o
trfego seja classificado conforme algum critrio, possibilitando um tratamento
diferenciado nas demais etapas. A classificao deve ser efetuada o mais prximo possvel
da origem.
Algoritmos de prioridade so mecanismos utilizados pelo equipamento de rede para
garantia de QoS, tipicamente implementados em roteadores. A definio de prioridades
prev diferentes tempos de espera para o processamento de informaes.
A priorizao de pacotes em aplicaes VoIP prov largura de banda, evitando ou
diminuindo atraso, jitter ou perda de pacotes. Um problema deste mecanismo que pacotes
de baixa prioridade podem ter muito atraso ou nunca serem processados.

54

O tratamento das filas se d baseado na classificao feita anteriormente, que pode

ser das seguintes formas:
- IP Precedence:
A priorizao de pacotes se d com a utilizao do campo TOS (type of service) do
cabealho IP, especificando desta forma, uma classe de servio para cada pacote. So
utilizados trs bits para marcar um pacote com a classe desejada, quando este entra na rede.
O tratamento associado classe identificada, para cada tipo de trfego definido um
valor especfico.
Os roteadores que suportam este mecanismo devem utiliz-lo em qualquer ponto
cujo processamento esteja relacionado com a alocao de recursos finitos como buffers.
- Priority Queueing:
A priorizao dos pacotes feita de forma rgida, o pacote de maior prioridade
sempre ser enviado primeiro. O mecanismo permite atribuir nveis diferentes de prioridade
para trfego com diferentes importncias.
Existem quatro filas neste mecanismo, alta, mdia, normal e baixa sendo que
pacotes no classificados so colocados na fila normal.
Trfego de voz, devido baixa tolerncia a perda de pacotes e atrasos devem ser
colocados em uma PQ. preciso ter cuidado pois, em casos extremos, se o fluxo prioritrio
ocupar toda a banda, o trfego de menor prioridade pode sofrer um grande atraso ou nunca
ser atendido.
6.3.2 Controle de Admisso
Para que no ocorram congestionamentos, deve-ser considerado tambm o descarte
de pacotes quando necessrio, proporcionando a igualdade na distribuio de banda e
processamento.
Os mecanismos de controle de admisso determinam se um novo fluxo de dados
ser aceito ou no, procurando no comprometer os fluxos previamente aceitos.
Congestionamentos ocorrem normalmente por falta de buffer em algum ponto da rede.
Estes mecanismos no agem de forma pr-ativa e podem ser parte integrante dos
mecanismos de escalonamento.
Os controles so implementados com a utilizao de mtodos como Token Bucket e
suas demais variaes.
6.3.3 Escalonamento de Filas
Este mecanismo utilizado para que a banda e o processamento sejam distribudos
de forma justa entre os fluxos, procurando garantir que cada stream obtenha os recursos que
lhe foi alocado.

55

A funo bsica do escalonamento implementar uma poltica para servir os

pacotes na fila de sada.
Abaixo esto descritos alguns dos algoritmos de escalonamento:
- FIFO (First In First Out):
Este algoritmo apenas um mecanismo de armazenamento e repasse (store and
forward), no implementando nenhum tipo de QoS. Tratamento default nos roteadores,
pacotes so enviados estritamente na ordem em que so recebidos.
- RR (Round Robin):
Este algoritmo atende ciclicamente cada fila, transferindo um pacote por vez, no
utilizando pesos para tal.
- WRR (Weighted Round Robin):
Este algoritmo utiliza como parmetro de prioridade o peso das filas. Este peso
utilizado quando ocorre congestionamento, neste mecanismo atribudo um peso alto para
o trfego prioritrio, porm, sem esquecer o trfego de baixa prioridade. Quando h largura
de banda suficiente e no h congestionamento todas as filas so atendidas da mesma
forma. Este mecanismo pode ser utilizado em VoIP, de preferncia com um nmero
pequeno de filas com buffers maiores.
- GPS (Generalized Processor Sharing):
Este algortmo utiliza pesos atribudos a cada conexo, existe uma fila para cada
fluxo.
A implementao deste mtodo torna-se invivel pois, assume-se que a capacidade
do enlace pode ser dividida infinitamente.
- CBQ (Class Based Queueing):
Os pacotes so enquadrados em diversas classes, organizando de forma a criar um
esquema de prioridades entre os fluxos de sada.
- FQ (Fair Queueing):
O trfego ordenado em sesses e para cada uma das sesses alocado um canal.
Este algoritmo prov uma alocao mais justa entre os fluxos de dados.
- WFQ (Weighted Fair Queueing):
Este algoritmo distribui pesos aos fluxos de sada, possibilitando ponderar
determinados tipos de fluxos. O algoritmo escalona o trfego prioritrio (interativo) para
frente da fila e compartilha o restante da banda de forma justa entre os demais fluxos. O
WFQ dinmico e se adapta automaticamente s mudanas das condies de trfego.

56

6.3.4 Controle de Congestionamento

Este mecanismo prov a inibio dos fluxos sempre que houver congestionamento,
fazendo com que os geradores de fluxo reduzam a carga sobre a rede e, conseqentemente,
o congestionamento.
Abaixo so apresentados trs mecanismos para controle de congestionamento:
- RED (Random Early Detection):
Mecanismo de preveno e inibio de congestionamento, efetua o descarte
randmico quando o congestionamento detectado.
A idia central de funcionamento do algoritmo , ao invs de esperar que uma fila
FIFO encha para comear a descartar pacotes, e talvez descartar pacotes importantes, que
se inicie o descarte sempre que a fila exceda um determinado nvel. (REZENDE, 1999)
O mecanismo descarta pacotes aleatoriamente indicando para a fonte que esta deve
diminuir a taxa de transmisso, porm, sempre que um determinado nvel alcanado o
pacote descartado. A probabilidade de que um pacote seja descartado proporcional a
parcela de banda alocada para aquele fluxo.
- WRED (Weighted Random Early Detection):
Este mecanismo combina as funcionalidades do RED com a classificao dos
pacotes por precedncia IP. O WRED descarta pacotes de forma seletiva, levando em conta
as informaes de prioridade do campo TOS do pacote IP, descartando inicialmente os
pacotes de menor prioridade.
utilizado geralmente em roteadores centrais de backbones (core routers).
- ECN (Explicit Congestion Notification):
Este mtodo permite a notificao fim-a-fim de congestionamento na rede sem o
descarte de pacotes. apenas utilizado quando as duas pontas sinalizam a necessidade de
sua utilizao.
Quando h congestionamento um bit setado no cabealho IP ao invs do pacote
ser descartado, indicando desta forma o incio do congestionamento. Ao receber o pacote
sinalizado, um aviso enviado origem para que seja tomada uma atitude antes que
pacotes passem a ser descartados.
6.3.5 Conformao de Trfego
A conformao prov mecanismos para controle de trfego utilizando filtros
conhecidos como tocken bucket, limitando o trfego de sada a uma determinada taxa.
A conformao de trfego limita o trfego de rajada, no prejudicando desta forma o
trfego prioritrio.

57

Existem dois mtodos utilizados para a conformao de trfego:

- Leak Bucket (balde vazado):
Neste modelo o trfego que chega de uma fila depositado em um balde de
capacidade B, que possui um ourifcio, permitindo o trfego fluir a uma taxa de vazamento
r.
O trfego que chega a uma taxa menor que r diretamente encaminhado e o que
chega a uma taxa maior que r ir sendo acumulado no balde.
Caso a taxa de chegada seja muito maior que r, o baldo ir enchendo at que pacotes
sejam descartados.
Este modelo suaviza o trfego de rajadas que distribudo na rede.
- Token Bucket (balde com fichas):
Este modelo define uma taxa de transmisso varivel com atraso limitado.
Consiste em um balde de capacidade B que representa a capacidade de armazenar
fichas (tockens), estas fichas so repostas atravs de uma taxa constante de reposio R.
Quando um pacote chega, verifica-se se h ficha no balde, se existir, o pacote
marcado como in e uma ficha consumida, caso contrrio, marcado como out.
Este mtodo possui um parmetro chamado TSPEC que especifica o trfego (taxa e
profundidade do balde) e outro chamado RSPEC que especifica as garantias que o trfego
necessita.
Este modelo permite aplicao vazar rajadas para a rede at a profundidade do
balde, enquanto limita a taxa mdia em r.
6.3.6 Policiamento de trfego
O mtodo Committed Access Rate (CAR) utilizado para controle e policiamento
de trfego IP, ele gerencia a banda com limitao de taxa de acesso, controlando a taxa
mxima de recepo ou transmisso dos dados.
Os pacotes so classificados atravs de precedncia IP ou grupos de QoS e podem
ser descartados ou reclassificados sempre que os limites determinados so excedidos.
O mecanismo tocken bucket tambm utilizado no CAR, o trfego examinado,
comparado com os parmetros do tocken bucket e a partir destes uma ao tomada em
relao ao pacote. Neste mtodo possvel limitar o trfego por aplicao, priorizando, por
exemplo, o trfego VoIP.

58

6.4 Arquiteturas de QoS

6.4.1 IntServ
A qualidade de servio nesta arquitetura garantida atravs de mecanismos de
reserva na rede, a aplicao reserva os recursos necessrios antes de iniciar o envio dos
dados.
Esta arquitetura acrescenta ao servio de melhor esforo, categorias de servios com
diferentes graus de comprometimento de recursos (banda passante e buffer) e com
diferentes nveis de QoS para fluxos de transporte distintos na rede IP. (COLCHER et al.,
2005)
preciso definir como as aplicaes fazem suas solicitaes e como os elementos
da rede devem proceder para garantir o QoS.
Cada fluxo identificado por IP e porta de origem e IP e porta de destino,
permitindo que os recursos para fluxo de transporte sejam alocados individualmente.
As solicitaes de QoS so feitas atravs do protocolo de sinalizao RSVP, este
atua sobre o trfego de pacotes.
Os principais componentes deste modelo so:
-

Controle de admisso: determina se um novo fluxo pode ser admitido sem

interferir nos fluxos admitidos anteriormente;
Escalonador de pacotes: gerencia os buffers das filas de sada dos roteadores e
estaes, utiliza alguma poltica de atendimento para tal;
Classificador: reconhece e mapeia os pacotes dos fluxos nas diferentes
categorias de servios, notifica a funo de policiamento e os coloca no buffer
da fila de sada;
Policiamento: determina se os pacotes notificados pelo classificador esto em
conformidade com os parmetros de trfego e QoS negociados para o fluxo.

Na arquitetura IntServ trs categorias de servio so definidas pelo IETF:

-

Best Effort: esta a categoria tradicional, utiliza as rotas de menor atraso,

trocando informaes entre os roteadores. Os pacotes passam a ser descartados
quando os buffers esto cheios, este descarte detectado pelo TCP, reduzindo
assim a taxa de transmisso. Na verdade, nesta categoria, no h QoS;
Servio de Carga Controlada: esta categoria de servio aproxima-se do best
effort sob condies de baixa carga. No fornece limite mximo para o atraso de
pacotes de um fluxo, porm, garante que grande parte dos pacotes tenha um
atraso mnimo. No h garantias contra perdas por descarte devido a
enfileiramento de pacotes. Reserva uma parcela dos recursos disponveis na rede
aos fluxos que usam este servio e limita o nmero de servios no controle de

59

admisso. Os servios compartilham entre si essa parcela de recursos da rede.

H uma alta taxa de entrega, baixssima perda nas filas;
Servio Garantido: nvel de comprometimento garantido de banda passante para
fluxo de transporte. Impede o descarte de pacotes nesses fluxos por falta de
espao no buffer do roteador, porm, podem ocorrer perdas devido falha na
rede ou alteraes de rota. Os fluxos devem estar em conformidade com os
parmetros de QoS indicados pela aplicao, durante o controle de admisso.
Alm disso, fornece um limite mximo para o retardo de transferncia dos
pacotes. Se uma aplicao indica com preciso as caractersticas de trfego do
seu fluxo, a QoS almejada por ela pode ser mantido na rede.

A solicitao destes servios normalmente emprega procedimentos dinmicos e

estes dependem de protocolos de sinalizao especficos. Atravs de APIs, a aplicao
informa ao protocolo de sinalizao a categoria de servio desejada e a estrutura
flowspec, esta descreve os parmetros de QoS de servios integrados (Tspec traffic
specification e Rspec request specification).
Uma SLA IntServ define os aspectos tcnicos que caracterizam um servio, como
nvel de garantia desejado, a descrio do fluxo e os parmetros de QoS.
Nesta arquitetura h pouca escalabilidade, para cada sesso RSVP conhecida pelo
roteador, este tem que manter informaes de estado de reserva sobre ela, estas so
atualizadas periodicamente, tornando difcil a gerncia de todas as reservas.
6.4.2 DiffServ
A qualidade de servio nesta arquitetura garantida atravs de mecanismos de
priorizao de pacotes na rede.
Esta arquitetura no utiliza nenhum mecanismo de reserva de recursos, os pacotes
so classificados, marcados e processados de acordo com seu rtulo (DSCP).
A arquitetura DiffServ no padroniza servios, apenas especifica comportamentos
de encaminhamento, chamados Per Hop Behaviors (PHB), eles descrevem o
comportamento de cada classe em cada roteador. So definidas poucas classes de servios,
classes essas definidas em funo da QoS especificada para cada fluxo, reduzindo o nvel
de processamento necessrio nos roteadores. (COLCHER et al., 2005)
Na arquitetura DiffServ duas categorias de servio so definidas pelo IETF:
-

Expedited Forwarding (EF): esta classe prov o maior nvel de QoS. A idia
emular uma linha dedicada convencional minimizando atraso, perda e jitter para
os pacotes, h garantia de banda. EF utiliza mecanismos de traffic shaping,
buferizao e priorizao de filas;
Assured Forwarding (AF): esta classe emula um comportamento semelhante a
uma classe com pouca carga mesmo durante a ocorrncia de congestionamento.
H garantia de banda, porm, no h garantia de atraso ou jitter. Pode ocorrer

60

perda de pacotes. Esta categoria define quatro classes de prioridade de trfego

(ouro, prata, bronze e best effort), cada classe possui trs nveis de precedncia
de descarte. AF utiliza mecanismos de traffic shaping e o algoritmo RED.
Esta arquitetura especifica comportamentos de encaminhamento, ela no padroniza
servios e desta forma, tambm no os limita.
Uma SLA DiffServ define caractersticas como forma de tarifao, penalidades em
caso de interrupo e o SLS (Service Level Specification), que especifica a parte tcnica.
Um SLS define:
-

Disponibilidade do servio;
Mecanismos de autenticao e criptografia;
Restries de rotas;
Monitorao e auditoria de QoS;
TCS (Traffic Conditioning Specification):
- Caracterizao do trfego;
- Aes de policiamento;
- Parmetros de QoS;
- Escopo do servio.

Uma vantagem desta arquitetura que a classificao dos pacotes realizada nos
limites da nuvem DiffServ, possibilitando aos demais roteadores operarem normalmente,
sem a preocupao das complexidades de contabilizao dos pagamentos e imposio dos
acordos realizados.

61

7 ASTERISK
Desenvolvido inicialmente pela Digium, o Asterisk um software de PBX-IP
completo, possuindo todas as caractersticas de uma central telefnica de grande porte.
Permite a adio de vrios componentes de telefonia, tanto hardware e software,
possibilitando ao usurio modelar seu PBX da forma que preferir. (SPENCER et al., 2003)
A seguir, so descritas as caractersticas mais importantes do Asterisk e feitas
tambm algumas comparaes com outro software.

7.1 PBX-IP
Um PBX-IP baseia-se num sistema de comunicao de voz sobre IP e funciona com
um software especfico capaz de gerenciar toda a comunicao de voz, substituindo dessa
forma um sistema de telefonia tradicional.
Um PBX-IP oferece uma srie de vantagens em relao a uma central convencional:
-

Mobilidade: o ramal pode estar disponvel em qualquer lugar;

Flexibilidade: o ramal pode ser conectado em qualquer ponto de rede desde que
haja acesso Internet;
Escalabilidade: o nmero de ramais pode ser expandido sem a necessidade de
hardware adicional;
Reduo de custos com ligaes;
Integrao com centrais convencionais.

A seguir feita uma comparao entre uma central telefnica convencional e um

PBX-IP:
Tabela 7.1: Comparao entre PBX Convencional e PBX-IP
Tipo
Arquitetura
Instalao
Eltrica
Capacidade

PBX Convencional
Comutao de circuito
Centralizada
Cada ponto (telefone) necessita de
um par de fios
Depende do hardware

PBX-IP
Comutao de pacotes
Distribuda
Cada ponto (telefone) necessita
estar ligado a Internet TCP/IP
Depende da velocidade do link

62

Escalabilidade Complexo
(depende
do Simples
equipamento)
Convergncia Voz e dados so duas redes
Tudo via TCP/IP
Flexibilidade Pouca, adicionar ou mover ramais Grande, um ramal funciona
requer mudana fsica
qualquer ponto de rede e
Internet
Limitao
Limitado aos recursos tradicionais Aplicaes
baseadas
(aplicao)
de voz
software
Novas
Necessita de interfaces ou placas Fcil expanso, baseado
aplicaes
adicionais
software e link
Redundncia No existe, necessrio outro PBX Backup de software
reinstalao
Configurao Complicada
Simples
Interligao
No suporta interligao com Interligao
simples
outro PBX
Internet
Integrao
Pequena ou inexistente
Ligados via rede ou Internet
com PCs
Fonte: Interlize

em
via
em
em
ou

via

7.2 Funcionalidades
O Asterisk licenciado atravs de uma licena do tipo GPL Gnu Public License e
roda sobre Linux e outras plataformas Unix, possuindo as seguintes funcionalidades:
-

Gateway VoIP;
Gateway de mdia: entre a rede IP e a RTPC, traduz protocolos de sinalizao e
CODECs;
Private Branch eXchange (PBX): efetua controle de encaminhamento de
chamadas intra e inter-terminais;
Servidor URA: toca mensagens pr-programadas;
Softswitch: computadores que comutam circuitos de hardware na forma de
interfaces padres de telefonia;
Discador automtico;
Correio de voz: semelhante a uma secretria eletrnica ou caixa de mensagem
do celular;
Sistema de mensagens unificadas: todas as mensagens de um mesmo usurio so
direcionadas para um mesmo local, como uma caixa de mensagens;
Distribuidor automtico de chamadas e fila de atendimento;
Registro detalhado de chamadas: para integrao com sistemas de tarifao;
Servidor de msica em espera: para clientes esperando na fila, com suporte a
streaming de media, bem como msica em formato MP3;
Servidor de conferncia.

63

7.3 Arquitetura
O Asterisk possui uma arquitetura simples, conectando tecnologias de telefonia no
nvel mais baixo at softwares de telefonia no nvel mais alto, criando um ambiente
consistente para construir um ambiente misto de telefonia. (SPENCER et al., 2003)
Os componentes bsicos da arquitetura do Asterisk so:
-

Canais: So equivalentes linha telefnica do sistema comutado na forma de

um circuito digital de voz. Um canal pode ser uma conexo a um telefone
analgico tradicional, ou a uma linha telefnica PSTN, ou uma chamada lgica,
como uma chamada via Internet. No h distino se um telefone ou uma linha
telefnica, tudo visto como CANAL. Cada chamada originada ou recebida
em um canal distinto;
- CODECS: So responsveis pela converso da voz analgica para sinal digital e
seu transporte pela rede. Permite a execuo de vrias chamadas telefnicas em
uma mesma rede, a quantidade de chamadas depende do CODEC
implementado. O Asterisk possui tambm tradutores de CODECs, o que permite
que canais que utilizem diferentes CODECs, com diferentes taxas de
compresso de dados possam se comunicar. (SPENCER et al., 2003)
O captulo 4 trata especificamente sobre este assunto;
- Protocolos: So responsveis pela sinalizao das chamadas, estabelecendo
sesses entre os terminais e tambm pelo transporte, efetuando entrega fim-afim de dados em tempo real, o captulo 3 trata sobre protocolos de sinalizao e
transporte;
- Aplicaes: So as funcionalidades encontradas no Asterisk, como servidor
URA, correio de voz e conferncias, descritas na seo 7.2.

A figura a seguir mostra a arquitetura bsica do Asterisk:

64

Figura 7.1: Arquitetura do Asterisk (Gonalves, 2007)

7.4 Componentes do Asterisk

Os componentes do Asterisk podem ser divididos em interfaces de hardware e
software, abaixo esto descritas ambas interfaces.
7.4.1 Interfaces de Hardware
Para a conexo fsica com o Asterisk podemos utilizar vrias interfaces, entre elas
podemos citar:
-

Interfaces analgicas (linha de telefone e telefone analgico);

Circuitos digitais (linhas T1 e E1);
Protocolos VoIP (SIP, H.323, MGCP, etc).

Abaixo um exemplo de como o Asterisk pode ser implementado, utilizando as

interfaces de hardware descritas acima:

65

Figura 7.2: Interfaces do Asterisk (Gonalves, 2007)

O Asterisk pode ser conectado utilizando softphones sem a necessidade de uma

interface de hardware adicional, atravs de telefones IP, ou, simplesmente roteando as
chamadas pela Internet para um provedor de servios de telefonia.
A forma mais simples de criar um PBX utilizando placas FXO e FXS. As placas
FXO permitem a conexo a uma linha de telefone analgico e no geram tom de discagem,
apenas aceitam. J as placas FXS permitem a conexo a um telefone analgico, fornecem o
tom de discagem e tambm sinalizam quando uma ligao recebida.
Embora a porta FXO no gere tom de discagem, ambas as interfaces fornecem
comunicao bidirecional.
Um dos cenrios mais comuns para aplicaes VoIP o exposto na figura
apresentada a seguir, onde procura-se aproveitar a estrutura j existente, habilitando uma
central antiga para chamadas VoIP.

66

Figura 7.3: Integrao com PBX existente (Gonalves, 2007)

preciso verificar as necessidades de integrao com outras centrais e o nmero de

canais que sero utilizados para especificar o hardware que ser utilizado.
O Asterisk faz o processamento dos canais de voz, utilizando de forma intensiva o
processador e no requer muito espao em disco, aproximadamente 100 Mb.
Caso apenas VoIP seja utilizado, nenhum hardware adicional se faz necessrio.
7.4.2 Interfaces de Software
As diversas tecnologias e interfaces suportadas pelo Asterisk so divididas em trs
grupos. (SPENCER et al., 2003)
As seguintes interfaces de software podem ser adicionadas ao Asterisk:
-

Interface Pseudo TDM Zaptel: Permite a integrao com o sistema digital e

analgico e possui suporte Pseudo-TDM switching, permitindo a realizao de
vdeo conferncia. O pseudo-tdm simula o processamento TDM feito em
hardware, o suporte a TDM adicionado ao Asterisk, deixando o processamento
de vdeo conferncia e outras aplicaes para o software;
Interface no Zaptel: Tambm permite a integrao com o sistema digital e
analgico, porm, no permite a realizao de vdeo conferncia;
Protocolos de pacotes de voz: So os protocolos padres para comunicao
VoIP e no necessitam de hardware adicional.

67

7.5 Asterisk X OpenSER

A seguir, ser feita uma comparao entre o Asterisk e o OpenSER, SIP Proxy
licenciado pela licena GNU como software livre.
Um SIP Proxy efetua requisies para agentes que no podem faz-las diretamente,
efetuando a comunicao com outro servidor SIP e retendo informaes que podem ser
usadas posteriormente, como informaes de faturamento.
O OpenSER no exatamente um concorrente do Asterisk, ele pode ser utilizado
como um provedor VoIP, como soluo para travessia de NAT e tambm para
balanceamento de carga.
A travessia de NAT mais fcil no Open SER, a mdia pode ser enviada
diretamente do cliente ao provedor, a no ser que NAT no simtrico esteja sendo utilizado.
Enquanto que a arquitetura do Asterisk um B2BUA, back to back user agent, o
Open SER, sendo apenas um SIP Proxy, possui uma arquitetura mais leve, apresentando
um melhor desempenho na implementao, considerando vazo ou nmero de canais
atendidos. (GONALVES, 2008)
Em compensao, a arquitetura do Asterisk, embora mais pesada, gerencia a mdia e
possui diversos recursos no encontrados num SIP Proxy, como por exemplo, traduo de
CODECs e URA. (GONALVES, 2008)
Enquanto que o Asterisk possui uma srie de funcionalidades listadas anteriormente,
o OpenSER no capaz de efetuar nenhum servio relacionado mdia, necessrio
integrar a ele um servidor de mdia.
O OpenSER necessita de um gateway para se comunicar com a rede pblica,
enquanto que o Asterisk pode ser utilizado como gateway, efetuando ele prprio a
comunicao com a rede pblica. (GONALVES, 2008)
Considerando os aspectos citados acima, podemos concluir que os dois softwares
podem ser utilizados em conjunto, o OpenSER atuando como SIP Proxy, mais robusto, e o
Asterisk efetuando uma srie de outras funcionalidades necessrias a um PBX-IP,
aproveitando, desta forma, o que cada um tem de melhor.
importante salientar, porm, que o Asterisk mais simples de configurar e
gerencia volumes pequenos a moderados, enquanto que o OpenSER mais robusto, capaz
de gerenciar um grande volume de chamadas.
Portanto, cabe ao gerente de TI analisar suas necessidades e os aspectos citados
acima para determinar a necessidade ou no de recursos adicionais.

68

8 PROPOSTA DE IMPLEMENTAO
Baseado na estrutura de rede existente numa empresa e todas as conexes com suas
filiais, este captulo tem por finalidade elaborar uma proposta de implementao VoIP
considerando todos os aspectos estudados nos captulos anteriores.

8.1 Escopo
Permitir a comunicao telefnica utilizando a rede de dados, atingindo os seguintes
objetivos:
-

Comunicao VoIP entre a matriz e as filiais;

Interligao da central telefnica tradicional existente com o sistema VoIP;
Aumento do nmero de ramais existentes na matriz;
Qualidade e confiabilidade semelhantes telefonia convencional;
Privacidade dos dados;
Implementao dos seguintes servios: servidor URA, correio de voz, registro e
transferncia de chamadas e vdeo conferncia.

8.2 Estrutura da Rede

A rede atual da matriz possui as seguintes caractersticas que devem ser
consideradas:
-

Existem duas formas de acesso rede interna, pela Internet ou atravs de uma
rede MPLS (voz e dados), esta conecta todas as filiais e utiliza H.323 para
garantir a interoperabilidade com a central telefnica;
O firewall e NAT esto configurados no roteador que d acesso Internet;
A estrutura possui uma DMZ, os equipamentos da DMZ esto separados da rede
interna por um switch nvel 3;
A estrutura possui tambm uma central telefnica, conectada atravs de um
canal E1 ao roteador que d acesso rede MPLS.

A figura a seguir representa a estrutura atual da rede:

69

Figura 8.1: Estrutura atual da rede (o Autor)

Baseado na estrutura existente e no que se deseja implementar, as seguintes

modificaes devem ser efetuadas:
-

Configurao do NAT e firewall no switch 01, possibilitando a colocao de um

servidor para ultrapassar o NAT na DMZ e aumentando a segurana, atualmente
no existe um firewall isolando a rede local da DMZ, tornando-a vulnervel;
Incluso de um servidor Asterisk na DMZ, com um canal E1 fazendo a ligao
entre ele e a central telefnica existente, possibilitando a ligao de ramais do
Asterisk (SIP) para a central telefnica (H.323) e vice-versa. As funes de
gateway de mdia, gerncia e proxy sero executadas pelo Asterisk. No h a
necessidade de nenhuma configurao especial para a rede MPLS, sendo a
mesma tranparente para este tipo de aplicao;
Incluso de um segundo servidor na DMZ, utilizando Transversal Using Relay
NAT (TURN) para ultrapassar o NAT, existe tambm a possibilidades da
utilizao de tunelamento, mas isto acarretaria na incluso de mais um servidor;
Utilizao do roteador 01 como um segundo firewall, protegendo a DMZ;
Incluso de adaptadores ATA, telefones IP e softphones na rede local de acordo
com a necessidade.

A figura a seguir representa a estrutura da rede com as modificaes propostas

anteriormente:

70

Figura 8.2: Estrutura Proposta (o Autor)

8.3 Implementao
Baseado na nova estrutura proposta e no escopo que se pretende atingir, ser
necessria a implementao do que segue.
8.3.1 Protocolos de Sinalizao e Transporte
Para estabelecimento das sesses entre os terminais dever ser utilizado o protocolo
de sinalizao SIP, em virtude de que ele foi desenvolvido especificamente para a Internet,
possuindo grande escalabilidade e flexibilidade. O protocolo possui suporte a novos
CODECs o que facilita alteraes futura caso um CODEC mais apropriado seja
desenvolvido.
Embora a central telefnica opere com o protocolo de sinalizao H.323, no exiete
problema na utilizao dos dois protocolos simultaneamente, cabendo ao gateway de
sinalizao a converso de um para outro quando necessrio.
O modo de operao a ser utilizado dever ser o modo indireto, obrigando o agente
ao envio de mensagens de sinalizao atravs do proxy e possibilitando a manuteno
destas informaes, o tipo de encaminhamento dever ser statefull, facilitando desta forma
o envio de outras mensagens da mesma sesso.

71

Os protocolos RTP e RTCP devero ser utilizados em conjunto, permitindo o

servio de entrega fim-a-fim e monitoramento das conexes, efetuando a sincronizao das
amostras que trafegam na rede.
Embora o RTP no implemente QoS, ele permite que mtodos como IntServ e
DiffServ sejam aplicados, o que ser tratado mais adiante.
8.3.2 CODECs
Para a converso de sinais analgicos para digitais, considerando os modelos MOS
e modelo E e tambm as caractersticas de cada CODEC, dever ser utilizado o CODEC
G.711 ou, como segunda opo o CODEC G.726.
Segundo o modelo E, a satisfao obtida pelo G.726 se enquadraria como tima,
enquanto que o G.711 se enquadra como boa.
Apesar do G.711 possuir um MOS estimado de 4,2, abaixo do valor estimado para o
G.726 que de 4,3, ele considerado a opo natural para redes locais, possui excelente
qualidade de voz, no necessita recursos de processamento e tambm no adiciona nenhum
atraso na compresso de voz.
J o G.726 possui uma qualidade de voz que varia entre moderada a boa, necessita
poucos recursos de processamento e adiciona pouco atraso na compresso de voz.
8.3.3 NAT/ Firewall
Considerando os aspectos abordados no captulo 5, dois mecanismos seriam
indicados para ultrapassar NAT/firewall, Traversal Using Relay NAT (TURN) ou
Tunelamento.
Em virtude do mtodo de tunelamento necessitar um servidor adicional, o que
aumentaria os custos de implantao, dever ser utilizado o mtodo TURN para resolver os
problemas de NAT e firewall.
Para que este mtodo possa ser implementado, ser includo um servidor na DMZ
para execuo desta tarefa e as funes de NAT e firewall passaro a ser implementadas no
switch 01.
A utilizao do mtodo TURN se justifica por este tratar NAT simtrico, ele prov
um endereo externo que atuar como relay e servir como um intermedirio entre origem e
destino.
Um inconveniente deste mtodo que ele aumenta o consumo de banda, pois os
dados so transmitidos da origem ao servidor e do servidor ao destino.
preciso utilizar softphones com suporte a TURN, caso contrrio h a necessidade
de um proxy.

72

A figura abaixo demonstra os fluxos de dados de um cliente da rede local,

ultrapassando o NAT com a utilizao do TURN, atingindo um cliente externo:

Figura 8.3: Fluxo de dados utilizando TURN (o Autor)

8.3.4 Privacidade e Autenticidade

Considerando que o escopo especificado anteriormente exige que haja privacidade
dos dados que trafegam pela rede, faz se necessrio que os protocolos RTP e RTCP sejam
substitudos pelos protocolos SRTP e SRTCP.
Os protocolos SRTP/SRTCP oferecem confidencialidade, autenticidade e proteo
contra replay.
Como descrito no captulo 5, o SRTP utiliza criptografia, garantindo que mesmo
que os dados sejam capturados, no ser possvel decifr-los. A RFC 3711, que define o
protocolo, define tambm que seja utilizado o algoritmo AES, de 128 bits, proporcionando
desta forma um nvel de segurana elevado para o trfego de udio e tambm a utilizao
de HMAC-SHA1 para autenticao e integridade.
Desta forma, embora no definido no escopo, pode-se garantir, alm da privacidade,
tambm a autenticidade dos dados.
8.3.5 QoS
A qualidade de servio em redes IP um aspecto fundamental para o desempenho
fim-a-fim das aplicaes VoIP, considerando os aspectos abordados no captulo 6, ser
definido o que segue para obteno de QoS.

73

A proposta consiste na utilizao do modelo de rede DiffServ, garantindo a

priorizao de determinados pacotes na rede, sem no entanto utilizar mecanismos de
reserva de recursos.
Nesta arquitetura, os pacotes sero marcados, campo DSCP, criando classes de
pacotes que em conjunto com uma estratgia de encaminhamento, chamada PHB, cria
classes de servios com tratamento diferenciado. Devem ser definidas poucas classes de
servios na estrutura da rede reduzindo o nvel de processamento nos roteadores.
Uma vez classificado o pacote, o trfego dever ser encaminhado utilizando a
categoria de servio AF, Assured Forwarding. Esta categoria prov banda, mas no garante
atraso ou jitter, porm, oferece uma melhor utilizao da mesma.
Como esta arquitetura baseia-se na priorizao de pacotes, dever ser utilizado o
algoritmo Priority Queueing, priorizando de forma rgida o trfego de voz em relao aos
demais trfegos, diminuindo atraso e perda de pacotes.
Em virtude da utilizao desta arquitetura, tambm dever ser utilizado o
mecanismo de conformao de trfego tocken bucket, especificando as garantias que o
trfego VoIP necessita, diminuindo a probabilidade de descarte, maior liberao de banda e
menor tempo na fila.
O algoritmo RED dever ser utilizado para controle de congestionamento, inibindo
o fluxo de pacotes na origem quando necessrio, evitando o descarte de pacotes de alta
prioridade.
Para o escalonamento das filas nas interfaces de sada dever ser utilizado o
algoritmo WRR, atribuindo-se um peso alto para o trfego VoIP. recomendada a
utilizao de um nmero pequeno de filas com buffers maiores, conforme descrito na seo
6.3.3.
Conforme a recomendao G.114 do ITU-T, o atraso mximo no deve ser maior
que 400 ms, sendo que entre 150 e 400 ms pode ocorrer impacto em algumas aplicaes e
at 150 ms o atraso considerado ideal. Alm disso, a taxa de perda no deve ser superior a
10% e recomenda-se uma tcnica de buffering para que o jitter seja evitado.
A figura a seguir demonstra onde sero implementados os mecanismos de QoS:

74

Figura 8.4: QoS na Estrutura da Rede (o Autor)

8.3.6 Asterisk
Para que se atinja os objetivos formulados no escopo, dever ser instalado um
servidor Asterisk na DMZ.
O servidor Asterisk utiliza a tecnologia VoIP com diversos protocolos, possibilita a
integrao com vrios equipamentos de telefonia e a conexo com a rede pblica, bem
como a interligao entre a matriz e as filiais atravs da Internet, permitindo a comunicao
direta a custo zero.
Este servidor ser conectado ao switch 01 e ter tambm um canal E1 efetuando a
ligao entre o mesmo e a central telefnica.
O Asterisk efetuar as seguintes funes:
-

Gateway de gerncia: efetuando a comunicao entre terminais IP, controlando

o estabelecimento de novas chamadas, roteamento das mesmas e banda
passante;
Gateway de mdia: transmitindo fluxos de udio entre a rede IP e a central
telefnica, efetuando codificao e decodificao da voz e transcodificao
entre formatos digitais diferentes;
Gateway de sinalizao: controlando os pedidos de chamada entre a rede IP e a
central telefnica e efetuando a converso de mensagens ou tons entre e rede IP
e a central telefnica;
Servidor URA: servidor de mensagens pr-programadas;

75

Correio de voz;
Plano de numerao de chamadas;
Registro de chamadas;
Vdeo conferncia: necessrio que a interface Pseudo TDM Zaptel seja
instalada para dar suporte realizao de vdeo conferncia.

Com a definio dos servios a serem executados pelo Asterisk, as modificaes

propostas na estrutura fsica e as implementaes propostas acima, torna-se vivel a
utilizao de VoIP para a comunicao entre matriz e filiais e interligao com a central
telefnica existente, objetivo principal deste projeto.
8.3.7 Guia de Implementao
A tabela a seguir descreve, de forma sucinta, o que e como dever ser implementado
a proposta definida anteriormente, esta implementao est prevista para uma segunda
etapa, posterior a este trabalho.

Etapas

Aquisies

Mudanas na
Estrutura
Atual

Instalao
Servidores

Tabela 8.1: Etapas para Implantao do Servidor VoIP

Implementao
Descrio
Servidor com capacidade para rodar o Asterisk
Servidor Asterisk
e ligao com a central telefnica utilizando
um canal E1.
Servidor com capacidade para rodar o TURN,
Servidor TURN
possibilitando a travessia do NAT.
Adaptadores ATA,
De acordo com a necessidade, preferncia para
telefones IP e headsets
utilizao de softphones com headsets.
Regras do roteador 01 implementadas no
Configurao do NAT
switch 01.
Configurao do firewall Incluso de regras no switch 01.
Execuo de funes de gateway de mdia,
gerncia e proxy.
Protocolo de sinalizao: SIP
Protocolo de transporte: SRTP/SRTCP
Asterisk
CODEC: G.711
Instalao da interface Pseudo TDM Zaptel.
Servios: servidor URA, correio de voz,
registro de chamadas, vdeo conferncia e
plano de numerao de ramais.
Configurao do TURN fazendo ligao entre
a rede interna e o Asterisk (sinalizao) ou
TURN
cliente (mdia).

76

DiffServ

Configurao
de QoS

Mecanismos

Definio de uma classe com prioridade sobre

as demais.
Marcao do campo DSCP dos pacotes de
sinalizao e transporte que provm da
Internet ou da rede MPLS, executadas nos
roteadores 01 e 02 respectivamente, os
roteadores devem verificar se h marcao e
refazerem a mesma caso haja necessidade. Os
roteadores 01 e 02 tambm devem efetuar a
classificao e policiamento destes pacotes.
Para os pacotes provenientes dos clientes da
rede local a marcao deve ser efetuada pelo
softphone ou, caso o software no suporte,
pelo switch 01.
O Asterisk dever efetuar a marcao dos
pacotes de sinalizao, no necessariamente
na classe de mais alta prioridade, mas numa
classe que oferea alguma garantia de vazo.
Os mecanismos de QoS devero ser
implementados nos roteadores de borda caso
se necessite tratar QoS fora da rede local.
Priorizao de pacotes PQ
Conformao de trfego Tocken Bucket
Controle de congestionamento RED
Escalonamento das filas WRR
Fonte: o Autor

77

9 CONCLUSO
No decorrer deste trabalho, procurou-se levantar todos os aspectos pertinentes
implementao de um servidor VoIP. Foram apresentadas solues para cada necessidade,
protocolos de transporte, QoS, NAT entre outros, permitindo a anlise e opo pela soluo
considerada mais vivel.
Percebe-se que a implementao pode ser executada de diversas formas, utilizando
um grande nmero de tcnicas, protocolos, servios e tambm diferentes combinaes dos
mesmos.
Com o intuito de definir uma nica proposta, procurou-se indicar os protocolos,
arquiteturas, tcnicas e servios que mais se adaptam estrutura da rede existente e onde as
alteraes necessrias sejam viveis, considerando aspectos tcnicos e tambm a
necessidade de aquisies.
Percebe-se ainda que a tarefa de implantao trabalhosa, requer conhecimentos
tcnicos para execuo e tambm um estudo sobre os impactos que as mudanas podem
causar na estrutura da rede.
A tabela a seguir apresenta todos os passos necessrio para a implantao do
servidor VoIP:
Tabela 9.1: Etapas para Implantao do Servidor VoIP
Etapas
Implementao
Descrio
Servidor com capacidade para rodar o Asterisk
Servidor Asterisk
e ligao com a central telefnica utilizando
um canal E1.
Aquisies
Servidor com capacidade para rodar o TURN,
Servidor TURN
possibilitando a travessia do NAT.
Adaptadores ATA,
De acordo com a necessidade, preferncia para
telefones IP e headsets
utilizao de softphones com headsets.
Mudanas na
Regras do roteador 01 implementadas no
Configurao do NAT
Estrutura
switch 01.
Atual
Configurao do firewall Incluso de regras no switch 01.

78

Asterisk
Instalao
Servidores

TURN

DiffServ

Configurao
de QoS

Mecanismos

Execuo de funes de gateway de mdia,

gerncia e proxy.
Protocolo de sinalizao: SIP
Protocolo de transporte: SRTP/SRTCP
CODEC: G.711
Instalao da interface Pseudo TDM Zaptel.
Servios: servidor URA, correio de voz,
registro de chamadas, vdeo conferncia e
plano de numerao de ramais.
Configurao do TURN fazendo ligao entre
a rede interna e o Asterisk (sinalizao) ou
cliente (mdia).
Definio de uma classe com prioridade sobre
as demais.
Marcao do campo DSCP dos pacotes de
sinalizao e transporte que provm da
Internet ou da rede MPLS, executadas nos
roteadores 01 e 02 respectivamente, os
roteadores devem verificar se h marcao e
refazerem a mesma caso haja necessidade. Os
roteadores 01 e 02 tambm devem efetuar a
classificao e policiamento destes pacotes.
Para os pacotes provenientes dos clientes da
rede local a marcao deve ser efetuada pelo
softphone ou, caso o software no suporte,
pelo switch 01.
O Asterisk dever efetuar a marcao dos
pacotes de sinalizao, no necessariamente
na classe de mais alta prioridade, mas numa
classe que oferea alguma garantia de vazo.
Os mecanismos de QoS devero ser
implementados nos roteadores de borda caso
se necessite tratar QoS fora da rede local.
Priorizao de pacotes PQ
Conformao de trfego Tocken Bucket
Controle de congestionamento RED
Escalonamento das filas WRR
Fonte: o Autor

Espera-se que o que foi levantado e estudado ao longo deste trabalho e com a
proposta de implementao apresentada no captulo anterior, seja possvel, numa segunda
etapa, implementar o servidor em sua totalidade.

79

REFERNCIAS
ARCOMANO,
R.
VoIP
How
To.
[S.
l.],
2002.
Disponvel
<http://tldp.org/HOWTO/VoIP-HOWTO.html>. Acesso em: jan. 2008.

em:

CHOWDHURY, D. D. Projetos Avanados de Redes IP. Rio de Janeiro: Campus, 2002.

380p.
COLCHER, S. et al. VoIP. Rio de Janeiro: Campus, 2005. 288p.
E-MODEL
Tutorial.
Disponvel
em:
<http://itu.int/ITU-T/study/groups/com12/
emodelv1/introduction.html>. Acesso em: mar. 2008.
GONALVES, F. Comparing Asterisk and OpenSER. [S. l.], 2008. Disponvel em: <
http://www.packtpub.com/article/comparing-asterisk-and-openser>. Acesso em: jul. 2008.
GONALVES, F. Guia de Configurao para o Asterisk PBX . Florianpolis: Ttulo
Independente, 2007. 358p.
HERSENT, O.; GUIDE, D.; PETIT, J. Telefonia IP. So Paulo: Prentice Hall, 2002. 451p.
IPSEC in VoIP Networks. [S.l.], 2006. Disponvel em: <http://www.newportnetworks.com/whitepapers/IPSec-1.html>. Acesso em: maio 2008.
IZU, A.; MAGUITA, W. VoIP e a Revoluo na Telefonia: Segunda Parte. [S.l.], 2005.
p.01-03. Disponvel em: <http://conhecimento.incubadora.fapesp.br/portal/trabalhos/2005/
VoIPEARevoluaoNaTelefoniaSegundaParte/>. Acesso em: jan. 2008.
KHLIFI, H.; GRGOIRE, J.; PHILLIPS, J. VoIP and NAT/Firewalls: Issues, Traversal
Techniques and a Real-World Solution. IEEE Communications Magazine, New York,
v.44, p. 93-99, July 2006.
MEGGELEN, J. SMITH, J.;MADSEN, L. Asterisk: O Futuro da Telefonia. Rio de janeiro:
Alta Books, 2005. 332p.
NAT Traversal for Multimidia Over IP. [S.l.], 2006. Disponvel em: <http://www.newportnetworks.com/whitepapers/nat-traversal.html>. Acesso em: maio 2008.

80

OpenSER - The Open Source SIP Server. [S.l.], 2005. Disponvel em: <
http://www.openser.org>. Acesso em: jul. 2008.
PABX
Virtual.
Rio
de
Janeiro,
2008.
Disponvel
http://www.interlize.com.br/?id_menu=19>. Acesso em: jul.2008.

em:

<

PASSITO, A.et al. Anlise de Desempenho de Trfego VoIP Utilizando o Protocolo IP

Security. In: BARBIERI, R. Voice over IPsec: Analysis and Solutions. Milano:
Dipartimento di Scienze dellInformazione: Universit degli Studi di Milano, 2002.
PINHEIRO, C. Especificao ITU H.323: Tutorial. Porto Alegre, 2000. Disponvel em:
<http://penta2.ufrgs.br/h323/indice.htm>. Acesso em: fev. 2008.
REZENDE, J. F.; ZIVIANI A. Trfego de Voz em um ambiente de diferenciao de
servios na Internet. Rio de Janeiro, 1999. Disponvel em: <http://www.gta.ufrj.br>.
Acesso em: jun. 2008.
SAADE,
D.
Fundamentos
de
Sistemas
Multimdia.
Disponvel
<http://www.midiacom.uff.br/~debora/fsmm/pdf/parte5.pdf>. Acesso em: mar. 2008.

em:

SECURITY
in
VoIP
Environments.
[S.l.],
2006.
Disponvel
em:
<
http://wiki.snom.com/Security_in_VoIP_environments#Media_Encryption_.28SRTP.29>.
Acesso em: jun. 2008.
SILVA, A. Qualidade de Servio VoIP: Parte I. 2000. Disponvel
<http://www.rnp.br/newsgen/0005/qos-voip1.html>. Acesso em: mar. 2008.

em:

SPENCER, M.; ALLISON, M.; RHODES, C. The Asterisk Handbook. 2003. Disponvel
em: <http://www.digium.com/handbook-draft.pdf>. Acesso em: jul. 2008.
STALLINGS, W. Cryptography and Network Security: Principles and Practice. 3rd ed.
[S.l.]: Prentice-Hall, 2003.
TANENBAUM, A. Redes de Computadores. Rio de Janeiro: Elsevier, 2003. 945p.
ZRTP: Media Path Key Agreement for Secure RTP. [S.l.], 2008. Disponvel em:
<http://zfoneproject.com/docs/ietf/draft-zimmermann-avt-zrtp-07.html>. Acesso em: jun.
2008.