Planejamento Capacidade Voip

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO
EDUARDO MAROAS MONKS
Planejamento de Capacidade em Redes
Corporativas para Implementao de
Servios VoIP
Dissertao apresentada como requisito parcial
para a obteno do grau de
Mestre em Cincia da Computao
Prof. Dr. Antnio Carlos da Rocha Costa
Orientador
Prof. Dr. Juergen Rochol
Co-orientador
Porto Alegre, maio de 2006
OUTROSTRABALHOSEM:
www.projetoderedes.com.br
CIP CATALOGAO NA PUBLICAO
Monks, Eduardo Maroas
Planejamento de Capacidade em Redes Corporativas para Im-
plementao de Servios VoIP / Eduardo Maroas Monks.
Porto Alegre: PPGC da UFRGS, 2006.
115 f.: il.
Dissertao (mestrado) Universidade Federal do Rio Grande
do Sul. Programa de Ps-Graduao em Computao, Porto Ale-
gre, BRRS, 2006. Orientador: Antnio Carlos da Rocha Costa;
Co-orientador: Juergen Rochol.
1. VoIP. 2. QoS. 3. Planejamento de Capacidade. I. Rocha
Costa, Antnio Carlos da. II. Rochol, Juergen. III. Ttulo.
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
Reitor: Prof. Jos Carlos Ferraz Hennemann
Vice-Reitor: Prof. Pedro Cezar Dutra Fonseca
Pr-Reitora de Ps-Graduao: Prof
a
. Valquria Linck Bassani
Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux
Coordenador do PPGC: Prof. Flvio Rech Wagner
Bibliotecria-chefe do Instituto de Informtica: Beatriz Regina Bastos Haro
I have always wished that my computer would be as easy to use as my
telephone.
My wish has come true.
I no longer know how to use my telephone.
PROFESSOR BJARNE STROUSTRUP
HTTP://WWW.RESEARCH.ATT.COM/ BS/HOMEPAGE.HTML
AGRADECIMENTOS
Este trabalho s se tornou possvel graas a oportunidade a mim dada pelo professor
Antnio Carlos da Rocha Costa. Muito obrigado e jamais esquecerei, professor Rocha.
Agradeo ao professor Juergen Rochol, pela amizade, convvio e pela orientao. Ao
professor Lisandro Granville, pela fora e a oportunidade de utilizar o Labcom. E a todos
os professores com os quais tive contato e aos funcionrios do instituto que sempre se
mostraram prestativos e atenciosos.
Aos colegas Weldson, Evandro, Michele, Oscar Mori, Jos Antnio, Oscar, Aurlio,
Rodrigo Sanger e Jamile pelo convvio, amizade e fora em todos os momentos.
A UCPel (Universidade Catlica de Pelotas), em especial, a Paula Pruski Yamim,
minha chefe e segunda me.
Aminha famlia, especialmente a meus pais, Pedro e Maria, que no mediramesforos
para eu conseguir terminar este trabalho. A eles, dedico esta dissertao.
Um agradecimento especial a minha mulher, Vanessa, que sempre esteve do meu lado,
desde as primeiras tentativas de contato como instituto. Uma pessoa que foi compreensiva
e companheira, que me ajudou nos momentos mais difceis. A ela, a qual soube entender
a minha ausncia, as minhas preocupaes e frustaes. A ela, dedico o meu ttulo.
SUMRIO
LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 8
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Organizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 VOZ SOBRE IP (VOIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Telefonia Convencional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Comunicao Telefnica . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Breve Histrico de VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Tipos de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Padres e protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Protocolos de Sinalizao . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Protocolos de Mdia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Codicadores (Codecs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6 Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6.1 Ponto a Ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.2 Com gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.3 Hbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7 Equipamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.1 Terminais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.2 Centrais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8 Numerao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.9 Exemplos de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.9.1 Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.9.2 Gizmo Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3 QUALIDADE DE SERVIO (QOS) . . . . . . . . . . . . . . . . . . . . 47
3.1 QoS em Telefonia Convencional . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.1 Taxa de bloqueio (GOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.2 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.3 Metas de Qualidade - ANATEL (Agncia Nacional de Telecomunicaes) 48
3.2 Fatores de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Variao do Atraso (Jitter) . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3 Fatores que afetam QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1 Eco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.2 Trfego Concorrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.3 Convergncia de Rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4 Garantias de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.1 Equipamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.2 Mecanismos de QoS Nvel 2 e 3 . . . . . . . . . . . . . . . . . . . . . . 57
3.4.3 Buffer de Jitter (Equalizador de Jitter) . . . . . . . . . . . . . . . . . . . 62
3.4.4 Redundncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.5 Fragmentao de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.6 Compresso de cabealhos . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.7 Alimentao de Energia . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.8 Planejamento de Capacidade da Rede . . . . . . . . . . . . . . . . . . . 64
3.5 Formas de Medio da Qualidade da Voz . . . . . . . . . . . . . . . . . 64
3.5.1 MOS - (Mean Opinion Score) . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.2 Modelo E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 PLANEJAMENTO DE CAPACIDADE EM REDES PARA SERVIOS
VOIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1 Planejamento de Capacidade em Redes . . . . . . . . . . . . . . . . . . 68
4.1.1 Fases do Planejamento de Capacidade . . . . . . . . . . . . . . . . . . . 71
4.2 Mtodos de Planejamento de Capacidade em Telefonia Convencional . . 72
4.2.1 Breve Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.2 Mtodos de Erlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2.3 Frmulas de Teletrfego . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2.4 Frmula de Erlang B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Aplicao da Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.1 Coleta de Trfego Telefnico . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.2 Clculo da Hora de Maior Movimento . . . . . . . . . . . . . . . . . . . 80
4.3.3 Denio do GoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.4 Aplicao da frmula de Erlang B . . . . . . . . . . . . . . . . . . . . . 82
4.4 Metodologia Adaptada para VoIP . . . . . . . . . . . . . . . . . . . . . . 82
4.4.1 Tipo de Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.2 Amostras por Pacote . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4.3 Supresso de Silncio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4.4 Compresso de Cabealhos . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.5 Recursos de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.5.1 Largura de Banda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.5.2 Mecanismos de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5.3 Metodologia Adaptada para VoIP . . . . . . . . . . . . . . . . . . . . . . 87
5 ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1 Cenrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 Rede de Telefonia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3 Rede de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.1 Trfego de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.2 Mecanismos de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4 Planejamento de Capacidade da Rede . . . . . . . . . . . . . . . . . . . 91
5.4.1 Clculo de HMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.2 Denio do GoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4.3 Aplicao da Frmula de Erlang B . . . . . . . . . . . . . . . . . . . . . 92
5.4.4 Tipo de Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4.5 Nmero de Amostras por pacote . . . . . . . . . . . . . . . . . . . . . . 93
5.4.6 Supresso de Silncio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4.7 Compresso de Cabealhos . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4.8 Clculo da Largura de Banda . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Medies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5.1 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5.2 Procedimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.3 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.6.1 Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
APNDICE A GRFICOS POR SEGMENTO . . . . . . . . . . . . . . . . 112
LISTA DE ABREVIATURAS E SIGLAS
ACELP Algebraic Code Excited Linear Prediction
ADSL Assymetric Digital Subscriber Line
ANATEL Agncia Nacional de Telecomunicaes
ATA Analog Telephone Adapter
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
CELP Code Excited Linear Prediction
CRC Cyclic Redundancy Check
CoS Class of Services
DHCP Dynamic Host Control Protocol
DNS Domain Naming System
DSL Digital Subscriber Line
DSP Digital Signal Processor
DTMF Dual-Tone Multiple Frequency
DiffServ Differentiated Services
ENUM Eletronic Number
GOS Grade of Service
HTTP Hyper Text Transfer Protocol
IETF Internet Engineering Task Force
ITU International Telecommunication Union
LAN Local Area Network
MEGACO Media Gateway Control
MGCP Media Gateway Control Protocol
MIME Multipurpose Internet Mail Extensions
MRTG Multi Router Trafc Grapher
NAPTR Naming Authority Pointer
OSI Open Systems Interconnection
P2P Peer to Peer
PABX Private Automatic Branch Exchange
PBX Private Branch Exchange
PCM Pulse Code Modulation
PGQM Plano Geral de Metas de Qualidade
PPP Point to Point Protocol
PSTN Public Switched Telephone Network
QoS Quality of Service
RFC Request for Comments
RNP Rede Nacional de Pesquisa
RPTC Rede Pblica de Telefonia Comutada
RTCP Real Time Transport Control Protocol
RTP Real Time Transport Protocol
SCTP Streaming Control Transmission Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TDM Time Division Multiplexing
TLS Transport Layer Security
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
URA Unidade de Resposta Audvel
URI Uniform Resource Identier
VAD Voice Activity Detection
VLAN Virtual Local Area Network
VPN Virtual Private Network
VoDSL Voice over DSL
cRTP Compressed Real Time Transport Protocol
VOIP Voice over IP
LISTA DE FIGURAS
Figura 2.1: Representao do experimento de Graham Bell (MORTON, 1999). . 18
Figura 2.2: Operadora de mesa de chaveamento (1936) (AT&T, 2005). . . . . . . 19
Figura 2.3: Processo PCM de digitalizao da voz. . . . . . . . . . . . . . . . . 20
Figura 2.4: Grco comparativo entre trfego de voz e dados. . . . . . . . . . . . 22
Figura 2.5: Transmisso da voz atravs de rede de pacotes. . . . . . . . . . . . . 23
Figura 2.6: Comutao de Circuitos (TDM). . . . . . . . . . . . . . . . . . . . . 24
Figura 2.7: Comutao de Pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 2.8: Esquema de alto nvel dos protocolos VoIP. . . . . . . . . . . . . . . 26
Figura 2.9: Ligao com SIP usando um servidor proxy. . . . . . . . . . . . . . 28
Figura 2.10: Funes dos servidores SIP. . . . . . . . . . . . . . . . . . . . . . . 29
Figura 2.11: Componentes da recomendao H.323. . . . . . . . . . . . . . . . . 33
Figura 2.12: Pilha de protocolos H.323. . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 2.13: Cabealho do protocolo RTP. . . . . . . . . . . . . . . . . . . . . . . 36
Figura 2.14: Cabealho de um pacote RTP com voz, capturado com o software
Ethereal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 2.15: Tempos de converso entre codecs. . . . . . . . . . . . . . . . . . . 37
Figura 2.16: Arquiteturas de VoIP mais comuns. . . . . . . . . . . . . . . . . . . 41
Figura 2.17: Telefone IP Cisco modelo 7970. . . . . . . . . . . . . . . . . . . . . 41
Figura 2.18: Tela do softphone Xlite. . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 2.19: Conexes do Cisco 186 ATA (Analog Telephone Adapter). . . . . . . 43
Figura 2.20: Tela do cliente do servio Skype. . . . . . . . . . . . . . . . . . . . . 45
Figura 2.21: Tela do cliente do Gizmo. . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 3.1: Efeito do atraso no sinal de voz. . . . . . . . . . . . . . . . . . . . . 52
Figura 3.2: Diagrama de insero de atrasos na transmisso. . . . . . . . . . . . 53
Figura 3.3: Efeito do jitter no sinal de voz. . . . . . . . . . . . . . . . . . . . . . 55
Figura 3.4: Esquema de uso dos mecanismos de Qos e Cos. . . . . . . . . . . . . 61
Figura 3.5: Posicionamento do buffer de jitter. . . . . . . . . . . . . . . . . . . . 63
Figura 3.6: Cabealho com compresso do protocolo RTP. . . . . . . . . . . . . 64
Figura 4.1: Relao entre capacidade, trfego e desempenho. . . . . . . . . . . . 70
Figura 4.2: Fases do Planejamento de Capacidade de Rede. . . . . . . . . . . . . 72
Figura 4.3: A.K. Erlang (MILLENNIUM MATHEMATICS PROJECT, 1997). . 73
Figura 4.4: Parte de uma tabela de Erlang. . . . . . . . . . . . . . . . . . . . . . 77
Figura 4.5: Metodologia para o planejamento de capacidade da rede telefnica
convencional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figura 4.6: Tabela de Erlang para GoS 0,01 e HMM 2,7e. . . . . . . . . . . . . . 83
Figura 4.7: Diagrama da rede da captura com o Ethereal. . . . . . . . . . . . . . 83
Figura 4.8: Clculo da largura de banda do codec G.711. . . . . . . . . . . . . . 84
Figura 4.9: Overhead dos pacotes de voz (codec G.711). . . . . . . . . . . . . . 85
Figura 4.10: Exemplo de medio de trfego com o MRTG. . . . . . . . . . . . . 86
Figura 4.11: Metodologia para o planejamento de capacidade da rede para servios
VoIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figura 5.1: Diagrama da rede com a distribuio dos ramais . . . . . . . . . . . 89
Figura 5.2: Topologia de rede simplicada. . . . . . . . . . . . . . . . . . . . . 89
Figura 5.3: Nmero de servidores para trfego de 0,67e e GoS 1% . . . . . . . . 93
Figura 5.4: Diagrama da distribuio de ramais e a largura de banda . . . . . . . 94
Figura 5.5: Tela da ferramenta Ethereal para anlise de uxos RTP . . . . . . . . 96
Figura 5.6: Ambiente de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figura 5.7: Anlise de uxos do segmento da Reitoria. . . . . . . . . . . . . . . 99
Figura 5.8: Grco das ligaes com volume de trfego e o nmero de ramais
atuais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figura 5.9: Grco das ligaes com 50% a mais de volume de trfego e o n-
mero de ramais atuais. . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figura 5.10: Grco das ligaes com 50% a mais de volume de trfego e de n-
mero de ramais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
LISTA DE TABELAS
Tabela 2.1: Caractersticas dos Codecs. . . . . . . . . . . . . . . . . . . . . . . . 39
Tabela 3.1: Perodos de Maior Movimento (PMM). . . . . . . . . . . . . . . . . 49
Tabela 3.2: Origem dos atrasos usando o codec G.729 (GOODE, 2002). . . . . . 54
Tabela 3.3: Classes de servios do IEEE 802.1p. . . . . . . . . . . . . . . . . . . 59
Tabela 3.4: Classes de servios dos switches HP. . . . . . . . . . . . . . . . . . . 60
Tabela 3.5: Mapeamento entre valores de CoS (802.1p) e DSCP (DiffServ). . . . 60
Tabela 4.1: Modelos de Trfego Telefnico. . . . . . . . . . . . . . . . . . . . . 76
Tabela 4.2: Levantamento de trfego telefnico UCPel e UFRGS (Campus do Vale). 80
Tabela 4.3: Intensidade do trfego telefnico na UCPel e na UFRGS. . . . . . . . 81
Tabela 4.4: Valores medidos e calculados dos codecs. . . . . . . . . . . . . . . . 84
Tabela 4.5: Largura de banda para quantidade de amostras de voz por pacote (co-
dec G.711). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Tabela 5.1: Levantamento do trfego de dados. . . . . . . . . . . . . . . . . . . 90
Tabela 5.2: Intensidade de trfego por segmento. . . . . . . . . . . . . . . . . . 92
Tabela 5.3: Nmero de linhas por segmento. . . . . . . . . . . . . . . . . . . . 93
Tabela 5.4: Largura de banda por segmento. . . . . . . . . . . . . . . . . . . . . 95
Tabela 5.5: Total de chamadas por segmento. . . . . . . . . . . . . . . . . . . . 96
Tabela 5.6: Nmero de ramais e largura de banda por segmento, com 50% de
acrscimo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Tabela 5.7: Resultados das medies para intensidade de trfego atual. . . . . . 100
Tabela 5.8: Resultados das medies para intensidade de trfego de rede com
50% acrscimo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Tabela 5.9: Resultados das medies para intensidade de trfego e nmero de
ramais com 50% de acrscimo. . . . . . . . . . . . . . . . . . . . . 101
RESUMO
Este trabalho tem como objetivo o estudo da tecnologia VoIP (Voz sobre IP) e a sua
aplicao em redes corporativas, enfocando o planejamento de capacidade da rede de
dados para absorver servios VoIP. Sero apresentados tpicos sobre a fundamentao
terica de VoIP (Voz sobre IP), os requisitos de arquitetura de rede e QoS (Qualidade
de Servio) exigidos pelo servio. Mostra-se tambm como a metodologia para plane-
jamento de capacidade usado em telefonia convencional pode ser adaptada aos servios
VoIP em uma rede corporativa. Foi aplicada a metodologia adaptada atravs de um estudo
de caso em uma rede corporativa real.
Palavras-chave: VoIP, QoS, Planejamento de Capacidade.
ABSTRACT
Corporate Network Capacity Planning to VoIP Services Implementation
This work has as objective the study of capacity planning in corporate networks for
the implementation of VoIP (Voice over IP) services. We will presents topics about the
theorical background of VoIP, the requirements of architecture of network and QoS (Qual-
ity of Service) demanded by the service. It will also reveal how the methodology used for
planning capacity in conventional telephony, could be adjusted to the VoIP services in a
corporate network. The adjusted methodology was applied in a real corporate network.
Keywords: VoIP, QoS, Capacity Planning.
15
1 INTRODUO
As telecomunicaes experimentaram uma grande revoluo nos ltimos anos. A
antiga promessa de uma rede convergente (voz, dados e vdeo) comeou a acontecer. A
convergncia se deu em redes baseadas na pilha de protocolos TCP/IP, que possibilitou
o oferecimento de servios avanados, a um custo baixo, para todos os tipos de usurios
sejam eles residenciais, corporativos ou provedores de servios. Uma das tecnologias
para a convergncia est sendo a voz sobre IP (VoIP), (GOODE, 2002).
Os servios de VoIP so suportados por redes baseadas em TCP/IP, tanto para a sinali-
zao de chamadas telefnicas como para a transmisso de trfego de voz, com possibili-
dade de integrao com a rede de telefonia pblica. Servios de VoIP, tais como o Skype
(SKYPE, 2005) e o FWD (Free World Dialup) (FWD: FREE WORLD DIALUP, 2005),
que oferecem comunicao de voz ponto a ponto atravs da Intenet de forma gratuita,
esto se tornando cada vez mais populares entre usurios residenciais.
O mercado para servios VoIP tem crescido de forma considervel nos ltimos anos
(VARSHNEY et al., 2002). Este crescimento motivado pela reduo de custos e ao
maior aproveitamento da infra-estrutura existente. Na rea acadmica, projetos tais como
o fone@RNP (2005) no Brasil e SIP@Edu (SIP.EDU: VOICE OVER IP WORKGROUP,
2005) nos EUA, estudam os detalhes da tecnologia VoIP fazendo uso de aplicaes avan-
adas na infra-estrutura da rede Internet2 (INTERNET2, 2005).
Para os servios de VoIP obterem maior aceitao junto aos usurios, alguns aspectos
devem ser levados em considerao. O mais importante aspecto a comparao com a
telefonia convencional em relao qualidade de servio das chamadas. Para garantir
a qualidade da telefonia convencional em redes TCP/IP deve-se fazer uso de planeja-
mento de capacidade, de conguraes de QoS (Quality of Service) e de uma adequada
arquitetura de rede com redundncia de equipamentos, aplicaes e servios. Para desta
forma, tentar chegar disponibilidade de 99,999% tipicamente oferecida pela rede de te-
lefonia convencional (VARSHNEY et al., 2002). Alm disto, o quesito de GoS (Grade
of Service), que dene a probabilidade de bloqueio de chamadas, deve seguir os mes-
mos parmetros da rede de telefonia convencional, ou seja, cerca de 1% probabilidade de
bloqueios (CONWAY, 2000).
A garantia da qualidade do servio de VoIP de vital importncia para a aceitao da
tecnologia. Embora em servios gratuitos como o Skype e o FWD no exista qualquer
garantia de qualidade da chamada, em redes corporativas isto se faz necessrio. No caso
dos servios gratuitos, grande parte dos usurios so domsticos fazendo uso da Internet
para as ligaes. Para este tipo de usurio a economia nas ligaes acaba compensando
a qualidade do servio recebido. Entretanto, mesmo na Internet pblica sem QoS, prin-
cipalmente nos EUA, a qualidade das chamadas no to prejudicada conforme estudos
publicados em (MARKOPOULOU; TOBAGI; KARAM, 2003) e (JI; SCHULZRINNE,
16
2003).
No ambiente corporativo, as empresas dependem do bom funcionamento dos seus ser-
vios de telefonia para o encaminhamento dos seus negcios. No caso do uso de servios
VoIP em redes corporativas, no aceitvel que as ligaes sejam prejudicadas por tr-
fego de outros servios, tais como acesso a pginas ou download de arquivos. Para isto,
devem haver garantias de QoS na rede corporativa e, principalmente, um planejamento de
capacidade da rede para absorver os servios de VoIP com qualidade e sem prejuzo para
os outros servios j existentes.
1.1 Objetivos
O uso de servios VoIP em redes corporativas demandam estratgias peculiares de
implantao. Devido grande diversidade de equipamentos e aplicaes existentes nestas
redes e dependncia, cada vez maior, do negcio das corporaes na disponibilidade dos
servios de comunicao faz com que a agregao de mais um servio deva ser cuidado-
samente analisado. E sendo o servio de VoIP dependente de requisitos crticos de QoS,
os cuidados devem ser ainda maiores. A implantao de servios VoIP necessita de um
planejamento de capacidade da rede e a determinao do impacto nos recursos de rede
disponveis. Para isto, deve ser feito o levantamento de requisitos do servio. Um dos
requisitos mais importantes a intensidade do trfego telefnico convencional, que deve
ser considerado quando da sua utilizao em redes TCP/IP. Portanto, necessrio obede-
cer a uma metodologia que determine os requisitos necessrios para implantar o servio
de VoIP em redes corporativas com qualidade equivalente telefonia convencional.
Pretende-se, atravs deste estudo, denir uma metodologia para o planejamento da ca-
pacidade de rede, levando-se em conta os parmetros de QoS (Quality of Service) prprios
dos servios VoIP.
1.2 Organizao
Este trabalho divide-se em 6 captulos, sendo este, a introduo, o primeiro deles.
Em seguida, no captulo 2, mostrado as especicidades da tecnologia VoIP, os pro-
tocolos, arquiteturas e aplicaes.
No captulo 3, feita uma reviso de qualidade de servio (QoS) em telefonia con-
vencional e em servios VoIP.
O captulo 4, trata da fundamentao terica sobre planejamento de capacidade de
rede, mtodos de planejamento de capacidade de rede em telefonia convencional e a apre-
sentao da metodologia para planejamento de capacidade de rede para servios VoIP.
No captulo 5 apresentado o estudo de caso para a aplicao da metodologia desen-
volvida no captulo 4, juntamente com os resultados do experimento.
Este trabalho nda no captulo 6, com as sugestes de trabalhos futuros e as conclu-
ses do autor.
17
2 VOZ SOBRE IP (VOIP)
A tecnologia de VoIP baseada no funcionamento da telefonia convencional. Embora
o objetivo nal, a comunicao entre os usurios, seja o mesmo, algumas tcnicas so
particulares para cada uma das tecnologias. Portanto, sero revistos alguns conceitos e
apresentados os mecanismos de funcionamento da telefonia convencional e na seqncia
do captulo, os conceitos e funcionamento da tecnologia de VoIP.
2.1 Telefonia Convencional
Em 10 de Maro de 1876, em Boston, Massachussets, nos Estados Unidos, Alexander
Graham Bell inventou o telefone (gura 2.1). Desde ento, a forma de se comunicar
mudou. O advento do telefone tornou as comunicaes mais simples e de acesso ao
cidado comum, algo que no tinha acontecido at ento. Mas o servio de telefonia
obteve sua preeminente posio entre os servios de comunicao de forma gradativa. Por
exemplo, mesmo nos Estados Unidos no foi antes de 1910 que os ganhos da indstria de
telefonia excederam os ganhos do sistema postal. Na maioria dos pases, este tempo foi
ainda maior (FARLEY, 2005).
A principal razo para esta demora foi que o telefone teve que criar sua prpria infra-
estrutura. E almdisto, teve que competir como telgrafo, que era o servio mais utilizado
na poca. Em muitos pases, a telefonia foi boicotada em prol dos servios de correio
e telgrafos estatais. No caso de empresas, por exemplo, a Western Union, aps um
curto perodo de anlise, decidiu a favor de continuar usando o telgrafo para as suas
comunicaes, ao invs da telefonia (FARLEY, 2005). Esta deciso foi tomada baseada
nos problemas econmicos e tecnolgicos os quais a telefonia sofria na poca.
Em relao a custo, por exemplo, em Nova Iorque, no ano de 1900, uma assinatura
mensal para os servios de telefonia residencial era de U$ 20,00 (U$ 2000 nos valores
de hoje) e U$ 40,00 (U$ 4000 em valores atuais) para uso comercial, restringindo o uso
apenas para usurios corporativos ou usurios domsticos com grande poder aquisitivo
(ODLYZKO, 2000). O custo do servio comeou a baixar de forma mais acentuada a
partir da automatizao das centrais telefnicas entre 1945 e 1969, e do uso de sistemas
digitais na dcada de 80. A partir da dcada de 90, com o aumento da concorrncia
entre as empresas de telefonia e a ampliao do uso das redes de dados, principalmente
a Internet, as empresas de telefonia passaram a prover um grande volume de servios
de dados. O volume de dados passou o de ligaes telefnicas e forou as empresas de
telecomunicaes, no mais chamadas de empresas de telefonia como antes, a adaptarem
suas infra-estruturas. Com isto, a convergncia das comunicaes passou a ser possvel,
incentivando o uso de servios de VoIP no aproveitamento dos recursos j existentes e a
conseqente reduo de custos para as empresas de telecomunicaes.
18
Figura 2.1: Representao do experimento de Graham Bell (MORTON, 1999).
2.1.1 Comunicao Telefnica
A primeira transmisso de voz, feita por Alexander Graham Bell, se deu atravs de
um o interconectando dois dispositivos. No havia sinal de chamada e muito menos
discagem, era basicamente uma ligao ponto a ponto do tipo half-duplex. No decorrer
do tempo, o desenvolvimento da tecnologia permitiu a transmisso full-duplex tornando
possvel a conversao telefnica. Na forma mais bsica, a transmisso de voz atravs
dos os necessita de um microfone de carvo, uma bateria, um eletrom e um diafragma
de ferro. Alm disto, requer um meio fsico entre as duas localidades que desejem se
comunicar (o conceito de discagem, inicialmente, no existia). A pouca escalabilidade
desta estratgia, e o alto custo, impossibilitaram a expanso do sistema telefnico. A
expanso do sistema foi avanando com o o uso de comutadores (switches). Com o uso
de comutadores, no foi mais necessrio a ligao fsica direta entre os telefones dos
usurios.
No comeo, o mecanismo de comutao era exercido por operadores humanos (-
gura 2.2). Desta forma, o telefone do usurio necessitava apenas de uma ligao com o
comutador, ao invs de uma ligao direta com outro telefone. O primeiro comutador au-
tomtico foi inventado por um usurio de telefone, por sua prpria necessidade. Por achar
que estava sendo prejudicado no seu negcio de pompas fnebres, o americano Almon
Strowger criou um prottipo que eliminava a necessidade de usar operadores humanos na
distribuio das chamadas. Ele foi motivado a inventar o comutador automtico porque
um competidor da sua cidade estava recebendo todas as chamadas de servio de pompas
fnebres e ele nenhuma. O motivo era que a lha e a mulher do competidor faziam parte
de grupo de operadoras do comutador (FARLEY, 2005).
A discagem para encontrar o destino das ligaes comeou a ser utilizada quando
19
Figura 2.2: Operadora de mesa de chaveamento (1936) (AT&T, 2005).
os comutadores se tornaram automticos, e j havia um grande volume de ligaes, o
que tornava a operao manual impraticvel. Estes comutadores evoluram passando de
eletromecnicos para eletrnicos com grande capacidade de processamento. A automa-
tizao, a digitalizao e as tcnicas de amplicao de sinal permitiram a expanso dos
servios de telefonia e a escalabilidade necessria para prover, com qualidade, a comuni-
cao ao redor do mundo.
Existem duas formas de transmisso do sinal de voz em telefonia, a forma analgica
e a forma digital.
Na origem do telefone, toda a comunicao era analgica. Por este motivo, a quali-
dade da voz era prejudicada na transmisso em grandes distncias e era necessrio am-
plicar o sinal. O problema era que a amplicao tambm era feita no rudo da linha de
transmisso. Isto acarretava em uma qualidade pssima da voz, inutilizando, na maioria
das vezes, a chamada. Atualmente, a maioria dos terminais residenciais so analgicos.
Portanto, a transmisso feita de forma analgica at a central telefnica. Em casos de
uso de PABX (Private Automatic Branch Exchange), os ramais so na maioria analgicos
existindo alguns ramais digitais dependendo dos recursos da central.
A transmisso digital foi introduzida para reduzir o problema da amplicao sofrida
na transmisso analgica. Alm disto, possibilitou que a voz fosse transferida em redes de
pacotes. A digitalizao da voz feita atravs de codecs (codicadores/decodicadores)
de voz. As transmisses digitais so feitas entre as centrais telefnicas, ou seja, no back-
bone das empresas provedoras de servios. Os comutadores devem fazer a converso
digital/analgico quando o sinal for em direo ao assinante. O codec mais utilizado
o PCM (Pulse Code Modulation). As tcnicas de amostragem so baseadas no teorema
de Nyquist (SOARES; LEMOS; COLCHER, 1995), onde denido que o nmero de
amostras devem ser duas vezes maior, do que a maior freqncia do sinal, o que no caso
da voz de 8000 vezes por segundo (a maior freqncia 4KHz numa linha de voz),
para representar com maior delidade o sinal original. O processo de digitalizao da voz
usando PCM o seguinte (gura 2.3):
As formas de onda analgicas so passadas por um ltro de voz para eliminar qual-
quer freqncia acima de 4000 Hz. Estas freqncias so ltradas at 4000 Hz para
limitar a quantidade de crosstalk (interferncia entre linhas) na rede de voz.
20
feita a amostragem do sinal analgico na taxa de 8000 vezes por segundo.
Aps a amostragem, o sinal convertido em um formato digital discreto. A amostra
representada por um cdigo que indica a amplitude da forma de onda no instante
da amostragem. O PCM utilizado em telefonia usa 8 bits em cada amostra.
A largura de banda utilizada com o PCM nas chamadas de 64kbits, o que corres-
ponde a frames de 8 bits sendo amostrados 8000 vezes por segundo. Os 8 bits de cada
amostra representam, um bit para sinal, 3 bits para uma faixa logartmica e 4 bits para um
intervalo dentro da faixa logartmica.
Existem duas variaes da codicao PCM comumente usadas, a mu-law padro
na Amrica do Norte e Japo e a a-law que o padro usado na Europa e em outros
pases. No Brasil o padro adotado o a-law. Estes mtodos so similares no processo de
compresso logartmica para conseguir colocar de 12 a 13 bits em 8 bits, mas diferem em
alguns detalhes. Por exemplo, o mtodo mu-law possui ligeira vantagem sobre o a-law
em termos de relao ao desempenho sinal/rudo (DAVIDSON; JAMES, 2000). Quando
so feitas ligaes de longa distncia entre pases com padres diferentes, quem possuir
o mtodo mu-law car responsvel pela converso do sinal.
Figura 2.3: Processo PCM de digitalizao da voz.
2.1.1.1 Infra-estrutura
A infra-estrutura de telefonia comea com os pares de os conectados ao terminal
telefnico, chamado local loop. Estes pares de os so conectados a uma central telef-
nica, seja ela do provedor de servios de telefonia ou uma central particular, tal como um
PABX. A comunicao entre comutadores centrais ou entre PABXs chamado de trunk
(tronco).
A sinalizao feita em dois sentidos, usurio-rede telefnica e rede telefnica-rede
telefnica. No primeiro caso, a forma de como o usurio nal se comunica com a rede
telefnica, normalmente atravs de um terminal analgico. O mtodo de sinalizao mais
comum o DTMF (Dual Tone Multi-Frequency) que possibilita atravs da variao da
freqncia representar dgitos e comandos no terminal telefnico. chamado de sinaliza-
o inband, pois sua transmisso ocorre no mesmo caminho da voz. No caso do sentido
rede telefnica-rede telefnica, a sinalizao ocorre entre centrais telefnicas.
Existem protocolos de sinalizao inband e outband. Os protocolos inband entre
centrais foram abolidos nos anos 70, por limitaes tcnicas e por serem suceptveis a
fraudes, tais como o uso do apito de cereais do Captain Crunch (DRAPER, 2005). O
protocolo Signaling System 7 (SS7) um caso de protocolo de sinalizao outband, pois
21
possui um caminho independente da voz. Este protocolo reserva um canal de 64kbits
para controle das chamadas e atravs de pacotes controla as conexes na central e entre
centrais. Funes como identicao do telefone chamador e diminuio no tempo de
complemento de chamadas so conseguidas usando este protocolo. o padro usado
atualmente.
2.2 Breve Histrico de VoIP
A transmisso de voz digitalizada atravs de redes vem sendo arquitetada h bastante
tempo. Em 1962, atravs do artigo (BARAN, 1962) foi comentado o uso de redes para
trfego multimdia. Em 1977, foi proposta pelo IETF (Internet Engineering Task Force)
atravs de uma RFC (Request for Comments) (COHEN, 1977) a criao de um proto-
colo para transmisso de voz em forma de pacotes para uso militar. Em 1995, a empresa
Net2Phone (NET2PHONE, 2005) anunciou planos para o lanamento do primeiro servio
de comunicao entre computadores pessoais e a telefonia convencional. Pouco depois,
em 1996, o ITU (International Telecommunication Union) disponibilizou a primeira ver-
so da recomendao H.323 (ITU-T, 1997) sendo considerado o primeiro padro para
VoIP. O protocolo SIP (Session Initiation Protocol) foi apresentado em 1999 pelo IETF
atravs da RFC 2543.
Com o aumento de largura de banda e custo cada vez menor dos enlaces de dados
propiciou-se a retomada do interesse de voz sobre redes de pacotes. Outro fator impor-
tante foi a padronizao dos protocolos de VoIP, sendo o pioneiro a recomendao H.323
do ITU-T. Os servios de VoIP podem ser utilizados por provedores de servios, corpora-
es e usurios domsticos.
Os provedores de servios de telefonia convencional passaram a usar a tecnologia de
VoIP para diminuir os custos das ligaes entre as centrais. Fazendo uso de pacotes ao
invs de circuitos, os provedores conseguiram utilizar de forma mais eciente os recursos
das suas redes. Portanto, o uso de voz em redes de pacotes bastante utilizado em pro-
vedores de servios, e para aproveitar a estrutura dos backbones de dados existentes, que
trafegam TCP/IP (gura 2.4).
A tecnologia de VoIP no novidade no ambiente corporativo. As empresas esto
usando servios VoIP para aproveitar os enlaces de dados com pouco uso, eliminar os
altos custos de centrais telefnicas convencionais e, principalmente, diminuir os custos
de ligaes entre liais e matrizes. Embora os custos das ligaes sejam baixos usando
VoIP, o custo do investimento inicial alto. O custo de um telefone IP, por exemplo,
cerca de dez vezes maior do que um telefone convencional. Para reduzir o custo com os
telefones podem ser usados softphones, que so telefones por software, juntamente com
headsets (conjunto de fone de ouvido e microfone). O problema deste tipo de aborgadem
a inconvenincia criada para o usurio, que dever mudar a sua forma de interagir com
o telefone. Os headsets de boa qualidade possuem um custo maior do que um telefone
convencional, mas menor do que um telefone IP. Alm do custo, alguns problemas tais
como a disponibilidade e a qualidade do servio, zeram com que muitas empresas no
aderissem em massa aos servios VoIP. A disponibilidade do servio de telefonia conven-
cional o "cinco 9s" ou seja 99.999% de tempo do servio em funcionamento, cerca
de 5 minutos de parada em um ano, o que bastante complicado de atingir em redes de
dados (VARSHNEY et al., 2002). Em relao a qualidade do servio, as redes de pacotes
so mais susceptveis a fatores tais como atraso, jitter e perdas, que afetam diretamente a
qualidade da voz. Existem medidas para a qualidade da voz em VoIP e formas de garantia
22
Figura 2.4: Grco comparativo entre trfego de voz e dados.
que sero mostradas com mais detalhes no captulo 3.
Em se tratando de usurios domsticos, o uso dos servios de VoIP foram alavancados
pela popularizao dos servios de acesso por banda larga tais como ADSL (Assymetric
Digital Subscriber Line), acessos via rdio e cabo. Com mais banda para acesso aos
usurios, novos servios e aplicaes surgiram. Um dos servios de maior sucesso o
de compartilhamento de arquivos. Este tipo de servio permite que usurios troquem in-
formaes de forma ponto a ponto (P2P - Peer to Peer), bastando apenas alguma forma
de indexao para encontrar o arquivo desejado. Um dos servios deste tipo de maior
sucesso o Kazaa (KAZAA, 2005). Baseado nesta estrutura, os mesmos criadores do
Kazaa criaram o servio Skype (SKYPE, 2005). Com o mesmo princpio, de no ter um
ponto central, os usurios poderiam achar uns aos outros e conversar atravs da Internet.
Embora j existissem pioneiros neste tipo de servio tais como Net2Phone e Microsoft
Messenger (MESSENGER, 2005), o Skype aproveitou a popularizao dos servios de
banda larga e a similaridade de uso das aplicaes de compartilhamento de arquivos, para
atingir mais de 100 milhes de usurios (SKYPE, 2005). Devido a esta popularidade, v-
rios outros servios surgiram tais como FWD, Gizmo Project (GIZMO PROJECT, 2005)
e Sipphone (SIPPHONE, 2005a), fornecendo qualidade e funcionalidade iguais ou su-
periores ao Skype, com facilidade semelhante de uso. Os outros servios fazem uso de
padres e protocolos abertos, tais como SIP (Session Initiation Protocol), para a sinali-
zao e transporte dos uxos de udio, ao contrrio do Skype que faz uso de protocolos
proprietrios. Com isto, os servios abertos podem fazer uso de um grande nmero de
equipamentos e softwares j existentes. O autor acredita que o Skype perder em breve
sua posio de liderana incontestvel nos servios VoIP para usurios domsticos, sendo
os usurios distribudos nos servios que fazem uso de protocolos abertos.
2.3 Fundamentos
A transmisso da voz sobre redes de pacotes requer uma srie de tcnicas e protoco-
los. Para transformar as ondas sonoras de voz em cdigos binrios so necessrios o uso
23
de codicadores/decodicadores (codecs). Aps a captao do sinal da voz por meio de
um microfone, as amostras do sinal devem passar por processos de quantizao, codica-
o e compresso para poderem ser transportados de forma eciente em redes de pacotes
(gura 2.5). Os processos so dependentes das tcnicas usadas pelos diversos tipos de co-
dicadores de voz existentes. Na gura 2.3 demonstrado um esquema da transformao
da voz para cdigo binrio. A tcnica de digitalizao da voz atravs de codicadores de
udio usada em telefonia pblica h bastante tempo, usando o mtodo PCM. A voz co-
dicada repassada para as camadas responsveis pelo transporte na pilha de protocolos
TCP/IP, os protocolos RTP (Real-Time Transport Protocol) e UDP (User Datagram Pro-
tocol). Desta forma, a voz codicada assume o papel dos dados fazendo analogia com o
modelo de referncia OSI-RM (Open Systems Interconnection - Reference Model). O pro-
cesso de decodicao da voz acontece no receptor que deve possuir o codec apropriado.
Para a chamada ser realizada com sucesso deve haver um mecanismo de sinalizao, ou
seja, uma forma de controlar o uxo de pacotes. Os principais mecanismos de sinalizao
esto representados na recomendao H.323 e o protocolo SIP. Alm disto, os problemas
observados em redes TCP/IP, tais como atraso, perdas e jitter so fatores determinantes
na qualidade da chamada.
Figura 2.5: Transmisso da voz atravs de rede de pacotes.
2.3.1 Tipos de Redes
Os tipos de redes mais comuns so as baseadas em circuitos e as baseadas em pacotes.
2.3.1.1 Redes Baseadas em Circuitos
A tecnologia tradicional de rede empregada para carregar voz a comutao de cir-
cuitos. Por ser uma tecnologia orientada a conexo, utiliza tcnicas de multiplexao para
concentrar muitas conversaes em um nico tronco fsico. A tcnica de multiplexao
TDM (Time Divison Multiplexing) no requer funes complexas de controle de trfego.
Os usurios so assinalados a intervalos xos de tempo, tornando a qualidade do servio
determinstica e previsvel (exceto por erros de transmisso e bloqueio de conexo) e os
usurios no podem afetar a qualidade de servio de outro usurio. No h conteno por
banda ou recurso, a no ser pelo nmero de intervalos de tempo disponveis para estabe-
lecer conexes. Entretanto, o esquema TDM no permite atingir o importante objetivo de
maximizar a utilizao da banda utilizada. Muitas aplicaes, como transferncia de ar-
quivo e vdeo conferncia, requerem banda varivel durante suas transmisses. Alocao
de banda acima do necessrio leva a uma severa inecincia, pois a banda no utilizada
por transmisses lentas ou intermitentes poderia ser utilizada por outra conexo. Em
TDM, as fatias de tempo so alocadas para uma conexo independentemente se o usurio
est ou no transmitindo algo (gura 2.6). A forma de alocao garante a qualidade, mas
propicia o desperdcio de recursos. Por causa de sua esttica alocao dos intervalos de
tempo, o TDM no eciente para suportar trfego com caractersticas de rajada. Por
24
outro lado eciente para suportar trfego de voz (GONCALVES, 2000).
Figura 2.6: Comutao de Circuitos (TDM).
2.3.1.2 Redes Baseadas em Pacotes
A nalidade da rede de comunicao de dados conectar e transportar informaes
entre computadores remotos, chamados usurios da rede. A ecincia est em transmi-
tir o mais rpido possvel quantidades de informaes vlidas entre o maior nmero de
usurios. O parmetro de desempenho bsico utilizado em redes de computadores a
vazo (throughput) medida em bits por segundo ou octetos por segundo. A vazo da rede
afetada pelo congestionamento, ou seja, pela sobrecarga temporria de recursos. So os
congestionamentos que geralmente causam o aumento de retransmisso das informaes
e as perdas de pacotes.
Estas variaes de sobrecarga sobre a rede so percebidas pelos usurios atravs do
aumento do tempo de resposta, gerando insatisfaes quanto qualidade de servio pres-
tada. Oideal seria a rede ter umcomportamento transparente, como se os usurios estives-
sem interligados sem o compartilhamento de recursos. Dessa forma no haveria nenhum
tipo de conteno de trfego causado pela rede. Aproximar a realidade das redes de da-
dos a este ideal uma meta a ser perseguida. A tecnologia tradicional de rede projetada
para carregar dados a comutao de pacotes. Os pacotes podem ser comutados sem
estabelecer uma conexo prvia. o que acontece com o protocolo IP. Os pacotes so
roteados em cada n da rede e nenhuma banda pr-alocada para a transferncia de da-
dos. Esta tecnologia tem a capacidade de maximizar o uso da rede, mas no pode garantir
a qualidade de servio porque no h qualquer tipo de alocao de recurso (gura 2.7).
Esta situao caracteriza uma rede de melhor esforo (best effort) onde a largura de banda
ocupada pelo usurio varia de acordo com a carga da rede a cada instante.
A Internet, foi projetada como rede de melhor esforo, e originalmente no previa
qualquer mecanismo para garantia de qualidade. A losoa de melhor esforo torna-se
inaceitvel, pois a qualidade degrada rapidamente quando a demanda da rede cresce. Sim-
plesmente aumentar a capacidade dos enlaces e dos equipamentos no garante a qualidade
indenidamente. Propostas de mecanismos de identicao de prioridades e alocao de
recursos tm sido apresentadas para suprir QoS em redes TCP/IP. Pode-se citar os pro-
tocolos DIFFerentiated SERVices (DiffServ) e MPLS (Multiprotocol Label Switching)
25
como alternativas para implementar QoS.
Figura 2.7: Comutao de Pacotes.
2.4 Padres e protocolos
Existem basicamente dois tipos de protocolos em VoIP: os proprietrios e os abertos.
Dentre os proprietrios esto o Skinny da empresa Cisco, o usado no servio Skype e as
variaes aos protocolos abertos, como no caso do SIP no Microsoft Messenger. Exis-
tem ainda protocolos utilizados por fabricantes de centrais telefnicas que fazem uso de
software e hardware proprietrios. Embora exista ainda uma grande base destes protoco-
los proprietrios, cada vez mais os protocolos e padres abertos esto sendo utilizados e
adotados pelos fabricantes de equipamentos, principalmente o protocolo SIP.
Os protocolos abertos mais utilizados e difundidos so o SIP e a recomendao H.323.
OSIP foi concebido pelo IETF e possui caractersticas similares ao protocolo HTTP. um
protocolo simples e exvel, usado em VoIP para o controle (sinalizao) das chamadas.
O controle das caractersticas da mdia feito pelo protocolo SDP (Session Description
Protocol), que funciona em conjunto com o protocolo SIP.
A recomendao H.323 uma recomendao guarda-chuva, pois abrange sinaliza-
o, codicao, segurana, udio, vdeo e gerenciamento das chamadas. Criada pelo
ITU-T em 1996 fortemente baseada na arquitetura de telefonia convencional o que a
torna bastante completa. Em quesitos tcnicos de recursos, o H.323 mais completo do
que o SIP. Devido complexidade do H.323, o protocolo SIP, que mais simples e base-
ado no paradigma da Internet, tem recebido a preferncia de usurios e fabricantes. Por
ser ligado a um rgo de padronizao no to aberto e dinmico quanto o IETF, o H.323
acaba levando mais tempo para ser atualizado e revisado. Existem tambm os protocolos
de controle de gateways, como o MGCP (Media Gateway Controller Protocol).
Os protocolos responsveis pelo trfego da mdia so o RTP e o protocolo auxiliar
RTCP (Real-Time Transport Control Protocol). Ambos os protocolos so transportados
sobre os protocolos UDP e IP. Na gura 2.8, um esquema de alto nvel dos protocolos
mais comuns de VoIP.
Os protocolos VoIP podem ser categorizados em protocolos de sinalizao e em pro-
tocolos de mdia.
26
Figura 2.8: Esquema de alto nvel dos protocolos VoIP.
2.4.1 Protocolos de Sinalizao
2.4.1.1 SIP (Session Initiation Protocol)
O SIP (Session Initiation Protocol), denido em (ROSENBERG et al., 2002), um
protocolo de sinalizao do nvel de aplicao que tem funes de iniciar, modicar e ter-
minar, em tempo real, sesses entre participantes sobre uma rede IP. O SIP pode suportar
qualquer tipo de mdia. O protocolo um dos componentes do conjunto de protocolos e
servios necessrios no suporte troca de dados multimdia na Internet. A sinalizao do
SIP possibilita que sejam feitas chamadas entre participantes, chamadas telefnicas por
exemplo, e a negociao dos parmetros da sesso. O contedo das sesses, sejam eles
udio, vdeo ou outro contedo multimdia, so trafegados entre os participantes da ses-
so usando um protocolo de transporte. Na maioria dos casos, o protocolo de transporte
usado o RTP (Real-Time Transport Control). Protocolos de acesso a diretrios e pro-
cura de endereos tambm so necessrios, mas so independentes do protocolo SIP. A
grande aplicao do protocolo SIP no servio de VoIP, embora possa ser usado emoutros
servios tais como troca de mensagens (Instant Messaging) e videoconferncia. Existe a
tendncia na indstria de que o SIP ser o mecanismo de sinalizao para servios de voz,
tanto nos provedores de servios quanto nos usurios corporativos e domsticos (STAL-
LINGS, 2003).
O SIP possui cinco passos bsicos em relao ao estabelecimento e o trmino da
comunicao:
Localizao do Usurio: determinar a localizao do usurio na rede. Os usurios
podem se mover para outros locais e acessar o seu telefone e funcionalidades de
aplicaes remotamente. Por exemplo, em uma rede corporativa o usurio receber
chamadas para o seu ramal no importando onde esteja dentro da empresa.
Disponibilidade do Usurio: verica se o usurio deseja ou est, disponvel para
comunicao.
Capacidade do Usurio: determina os parmetros e o formato da mdia a serem
usados na sesso. A negociao depender da capacidade dos equipamentos envol-
vidos.
27
Congurao da Sesso: chamadas ponto a ponto ou em conferncia devem ser
estabelecidas, com os parmetros negociados.
Gerenciamento da Sesso: incluem-se neste a transferncia e terminao de ses-
ses, a modicao de parmetros da sesso e o carregamento de novos servios.
O SIP emprega em seu projeto elementos desenvolvidos em protocolos anteriores.
baseado no modelo de transao requisio/resposta do HTTP (Hyper Text Transfer
Protocol). Cada transao consiste na requisio de um cliente, que invoca um mtodo
particular ou funo no servidor e recebe ao menos uma resposta. O SIP usa grande parte
dos campos de cabealho, regras de codicao e cdigos de status do HTTP. Com isto, as
trocas de mensagens do SIP so em texto legvel. Para determinar o contedo da sesso,
utilizado o protocolo SDP, que ser descrito posteriormente.
Um sistema SIP pode ser visto como componentes distintos: cliente/servidor e ele-
mentos individuais de rede. Em (ROSENBERG; SCHULZRINNE, 2002a), so denidos
cliente e servidor desta forma:
Cliente: um cliente qualquer elemento de rede que envia requisies SIP e recebe
respostas SIP. Os clientes podem ou no interagir diretamente com o usurio. O
User Agent e os Proxies so considerados clientes.
Servidor: um servidor um elemento de rede que recebe requisies e as responde.
Exemplos de servidores so os Proxies, os servidores User Agent, servidores de
redirecionamento (Redirect) e de registro (Registrar).
Os elementos individuais de uma congurao SIP padro incluem (gura 2.9):
User Agent (Agente do Usurio): deve existir em qualquer estao de terminao
SIP. Atua de duas formas:
User Agent Client (UAC) (Agente do Usurio modo Cliente): trata das requisi-
es SIP.
User Agent Server (UAS)(Agente do Usurio modo Servidor): recebe as requi-
sies SIP e gera uma resposta que pode ser de aceitao, rejeio ou redireciona-
mento da requisio.
Redirect Server (Servidor de Redirecionamento): o servidor de redirecionamento
usado durante a iniciao da sesso para determinar o endereo do dispositivo que
est sendo chamado. Esta informao retornada para o dispositivo que originou
a chamada, direcionando o UAC para contatar um endereo alternativo no formato
URI (Universal Resource Identier) (BERNERS-LEE; FIELDING; MASINTER,
1998). Um URI um identicador genrico usado para nomear qualquer recurso
na Internet. Por exemplo, uma URL (Uniform Resource Location) utilizada para
endereo de pginas um tipo de URI.
Proxy Server (Servidor de Procurao): o servidor de procurao um entidade
intermediria que atua tanto como servidor ou cliente. No modo cliente, tem o
propsito de fazer as requisies por outros clientes. No modo servidor, um proxy
temcomo funo principal o roteamento, fazendo comque a requisio seja enviada
para uma outra entidade mais prxima do dispositivo nal. Os proxies tambm so
teis para reforar polticas de uso, como por exemplo vericar se determinado
28
usurio tem direitos de estabelecer uma chamada. Alm disto, o proxy interpreta
e, se for necessrio, reescreve partes especcas da mensagem de requisio antes
de repass-la adiante. Na gura 2.10, um exemplo de chamada SIP utilizando um
servidor proxy.
Figura 2.9: Ligao com SIP usando um servidor proxy.
Registrar (Servidor de Registro): este servidor tem a funo de aceitar requisies
do tipo REGISTER e repassar as informaes recebidas, que so o endereo SIP e o
endereo IP associado, para o servio de localizao (Location Service) do domnio.
Location Service (Servio de Localizao): este servio utilizado atravs de men-
sagens de redirecionamento (redirect) ou atravs de um servidor de procurao para
obter informaes sobre a possvel localizao do destino sendo chamado. Para este
propsito, o servio de localizao mantm um banco de dados como mapeamento
do endereo SIP e o endereo IP. Estas informaes so fornecidas pelo servidor de
registro. Normalmente, o servidor de registro e o servio de localizao se encon-
tram no mesmo host.
Os vrios servidores e servios so denidos na RFC 3261 do protocolo como dis-
positivos lgicos. Eles podem ser implementados separadamente ou em conjunto, por
exemplo, um mesmo host pode servir como proxy e redirecionador de chamadas. Ser-
vidores proxies podem atuar como servidores redirecionadores quando preciso. Se um
redirecionamento feito, o proxy necessita consultar o banco de dados do servio de
localizao, que pode estar junto com o servidor de proxy ou no.
O servio de DNS (Domain Name System) uma importante parte da operao do
SIP. Tipicamente, o UAC requisita atravs do DNS, o nome do UAS, e no o endereo IP.
O servidor de procurao necessita consultar o servidor de DNS para achar o servidor de
procurao do domnio destino. Por exemplo, a URI sip:emmonks@voip.com.br ser tra-
duzida pelo servio de DNS para o endereo do servidor de proxy do domno voip.com.br,
algo como sip.atlanta.com e o IP correspondente.
O SIP, freqentemente, utilizado sobre UDP por razes de desempenho e deve pro-
ver seus prprios mecanismos de garantia de entrega, embora o protocolo possa ser uti-
lizado sobre TCP (Transmission Control Protocol). Se for necessrio um mecanismo de
29
Figura 2.10: Funes dos servidores SIP.
transporte seguro, as mensagens SIP poder ser utilizadas de forma criptografada sobre o
protocolo TLS (Transport Layer Security) ou atravs de tunelamento, com VPN (Virtual
Private Network), por exemplo.
Existem dois tipos diferentes de mensagens SIP, a tipo requisio (request) e a tipo
resposta (response). A diferena de formato entre os dois tipos de mensagens iden-
ticado na primeira linha da mensagem. Na primeira linha de uma requisio tem um
mtodo denindo a natureza da requisio e a URI, indicando para onde a requisio
deve ser enviada.
J na primeira linha da resposta est contido um cdigo. Todas as mensagens incluem
um cabealho, consistindo em linhas comeando com uma identicao de cabealho.
Uma mensagem pode conter tambm um corpo, descrevendo o formato da mdia trans-
portada.
Os mtodos das requisies SIP denidos em(ROSENBERG; SCHULZRINNE, 2002a)
so os seguintes:
REGISTER: usado pelo agente usurio para noticar o endereo IP e a URL a qual
deseja receber chamadas.
INVITE: usado para estabelecer sesses de mdia entre os agentes.
ACK: usado para conrmar a entrega das mensagens.
CANCEL: usado para terminar requisies pendentes.
BYE: usado para terminar sesses.
OPTIONS: usado para solicitar informaes sobre as capacidades do destino da
chamada.
Exemplo de uma mensagem SIP do tipo requisio:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 12.26.17.91:5060
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
30
From: Emmonks <sip:emmonks@voip.com.br;tag=1928301774
Call-ID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:emmonks@voip.com.br>
Content-Type: application/sdp
Content-Length: 142
A primeira linha contm um mtodo (INVITE), uma URI (sip:bob@biloxi.com) e o
nmero da verso do SIP (2.0). As linhas seguintes so campos do cabealho. O cabea-
lho Via mostra o caminho que a requisio percorreu, e usado para rotear as respostas
pelo mesmo caminho. Alm disto, contm o endereo IP (12.26.17.91), o protocolo de
transporte (UDP) e a porta (5060) a qual o receptor dever enviar a resposta. O cabealho
Max-Forwards limita o nmero de hops que uma requisio pode fazer no caminho at
o destino. Este valor decrementado a cada passagem de hop. O cabealho To contm
o destino da mensagem e o campo From o originador da mensagem. O campo From
tambm possui uma tag (etiqueta) que um valor randmico identicador da sesso, que
gerado pelo UAC.
O campo Call-ID contm um identicador global nico para esta chamada, gerado
pela combinao de uma string randmica e o nome ou o endereo IP do host. A combi-
nao dos campos To, From e Call-ID denem completamente uma relao SIP ponto a
ponto entre Emmonks e Bob, como no exemplo acima. A relao entre dois agentes de-
nida como sendo um dilogo. O campo CSeq (Command Sequence) contm um inteiro
e um nome de mtodo. O nmero do CSeq inicializado no comeo da chamada e in-
crementado para cada nova requisio dentro do dilogo, sendo um contador seqencial.
Este campo usado para distinguir uma retransmisso de uma nova requisio. O campo
Contact contm a URI para comunicao direta entre os agentes. O campo Content-
Type indica o tipo de formatao do corpo da mensagem. O campo Content-Length
mostra o tamanho, em octetos, do corpo da mensagem.
Os cdigos das respostas SIP denidas em (ROSENBERG; SCHULZRINNE, 2002a)
so as seguintes:
Provisional (1xx): a requisio foi recebida e est sendo processada.
Exemplos: 100 Trying (tentando a conexo), 180 Ringing (tocando no destino).
Success (2xx): a ao foi recebida, entendida e aceita com sucesso.
Exemplo: 200 OK (procedimento executado com sucesso).
Redirection (3xx): outras aes so necessrias para a requisio ser completada.
Exemplos: 301 Moved Permanently (Movido permanentemente), 302 Moved Tem-
porarily (movido temporariamente).
Client Error (4xx): a requisio contm sintaxe errada ou no pode ser completada
pelo servidor.
Exemplos: 403 Forbidden (no permitido), 404 Not Found (no encontrado).
Server Error (5xx): o servidor falhou em processar uma requisio aparentemente
vlida.
Exemplos: 500 Internal Server Error (erro interno do servidor), 505 SIP Version
Not Supported (verso do protocolo SIP no suportada).
Global Failure (6xx): a requisio no foi completada em nenhum servidor.
Exemplos: 600 Busy Everywhere (todas a localidades ocupadas), 604 Does Not
Exist Anywhere (no existe a requisio em nenhum lugar conhecido)
31
Exemplo de uma mensagem SIP do tipo resposta:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
Via: SIP/2.0/UDP 12.26.17.91:5060
To: Bob <sip:bob@biloxi.com;tag=a6c85cf
From: Emmonks <sip:emmonks@voip.com.br;tag=1928301774
Call-ID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:bob@biloxi.com>
Content-Length: 131
No cabealho de uma resposta SIP, a primeira linha contm o nmero da verso do
protocolo SIP, o cdigo e o nome da resposta. As linhas seguintes correspondem ao
campos do cabealho. Os campos Via, To, From, Call-ID e CSeq so copiados da
requisio INVITE. No exemplo, o campo Via, foi modicado porque foram adicionados
ao caminho o UAC de Emmonks, o proxy do domnio atlanta.com e o proxy do domnio
biloxi.com. O agente Bob adicionou uma etiqueta (tag) no campo To. Esta etiqueta
incorporada por ambos os participantes no dilogo e includa em todas as requisies e
respostas futuras da chamada.
2.4.1.2 SDP (Session Description Protocol)
O protocolo SDP denido em (HANDLEY; JACOBSON, 1998) tem como funo
principal descrever o contedo das sesses. No caso de VoIP, usado em conjunto com o
protocolo de sinalizao SIP para descrever a formatao das chamadas telefnicas.
O SDP possui indicadores que descrevem informaes sobre:
Fluxo de mdias: uma sesso pode incluir mltiplos uxos de mdia com conte-
dos diferentes. O SDP atualmente dene udio, vdeo, dados, controle e aplicaes
como tipos de uxos, similar aos tipos MIME (Multipurpose Internet Mail Exten-
sions) utilizados no servio de e-mail.
Endereamento: indica os endereos de destino, os quais podem ser endereos de
multicast, para o uxo de mdia.
Portas: para cada uxo, as portas UDP para envio e recebimento so especicadas.
Diferente dos protocolos de sinalizao SIP ou H.323, que possuem portas xas
para a comunicao, os uxos de mdias usam faixas de portas altas UDP. Devido
ao uso de rewalls e NAT (Network Address Translation) esta caracterstica diculta
a comunicao entre os terminais, principalmente em redes corporativas.
Tipos de Contedo: para cada tipo de uxo, o tipo de contedo indica quais os
formatos que podem ser utilizados durante a sesso. No caso de SIP, so indicados
os tipos de codicadores que podem ser utilizados pelos agentes envolvidos no
dilogo.
Tempos de Incio e Parada: so aplicados para sesses em broadcast, por exem-
plo, um programa de rdio ou televiso, para indicar os tempos de incio, parada e
nmero de repeties.
Originador: para sesses do tipo broadcast, o originador especicado, com infor-
maes para contato. Isto pode ser importante para o receptor reportar problemas
tcnicos a fonte da transmisso.
32
Embora na primeira verso do protocolo SDP fosse possvel descrever o contedo
multimdia, faltavammecanismos de negociao das capacidades entre os participantes da
sesso, como ocorre na recomendao H.323. Este problema foi resolvido em (ROSEN-
BERG; SCHULZRINNE, 2002b), onde foi denido um modelo de pergunta/resposta, no
qual as partes da sesso trocam mensagens SDP para negociar a natureza do contedo
multimdia a ser transmitido. Este mecanismo permite que haja a negociao do tipo de
codec e capacidades avanadas entre os agentes envolvidos na sesso.
Abaixo, uma captura do corpo de uma mensagem SDP, apresentando os codecs dis-
ponveis para a conversao entre os usurios dos ramais 18 e 1003:
INVITE sip:18@200.17.170.37 SIP/2.0
Via: SIP/2.0/UDP 192.168.200.200:5060
From: Eduardo Monks <sip:1003@200.17.170.37>;tag=2786616179
To: <sip:18@200.17.170.37>
Contact: <sip:1003@192.168.200.200:5060>
Call-ID: 519C8A6B-4ADB-44F6-AF0A-BD579B0A4F36@192.168.200.200
CSeq: 12705 INVITE
Max-Forwards: 70
User-Agent: X-Lite release 1105x
Content-Length: 313
v=0
o=1003 27735444 27735459 IN IP4 192.168.200.200
s=X-Lite
c=IN IP4 192.168.200.200
t=0 0
m=audio 8000 RTP/AVP 0 8 3 98 110 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:3 gsm/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:110 speex/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
2.4.1.3 H.323
A recomendao H.323 do ITU composta por protocolos de conferncia multim-
dia, que incluem voz, vdeo e dados para uso sobre rede de pacotes (ITU-T, 1997). Sua
primeira verso foi aprovada em fevereiro de 1996, no mesmo ms do primeiro draft do
protocolo SIP. Projetada para operar sobre redes complexas, teve como foco inicial o uso
em LANs (Local Area Network) e foi extendida para redes WANs (Wide Area Network)
nas verses seguintes. Embora na congurao bsica seja requerida somente a voz, o
vdeo dominou as implementaes iniciais e continua sendo o ponto forte do H.323. Foi
o primeiro padro para VoIP, sendo amplamente adotado pela indstria.
A recomendao composta de uma srie de documentos que descrevem as funcio-
nalidades dos componentes e mecanismos que so utilizados para:
sinalizao;
estabelecimento de sesses;
controle de chamadas;
gerenciamento de largura de banda;
controle de admisso de chamadas;
determinao dos codecs para transferncia de udio e vdeo;
uso de protocolos de transferncia de dados.
Os componentes de um sistema H.323 so os seguintes (gura 2.11):
33
Terminais: so entidades do H.323 das extremidades de uma rede de transmisso
multimdia. A comunicao feita em duplo sentido e em tempo real com outros
terminais H.323, atravs da transmisso e recepo de sinais de controle, udio,
vdeo e dados (isoladamente ou em conjunto).
Multipoint Control Units (MCUs): so componentes H.323 que fornecem a capaci-
dade de suportar conferncia multiponto com mais de dois terminais e/ou gateways.
Gateways: so componentes opcionais em um sistema de conferncia H.323. Eles
fornecem muitos servios, sendo que o mais comum a traduo de formatos de
sinais entre terminais H.323 e terminais de outros tipos ou tecnologias. Normal-
mente, tem a funo de fazer a interconexo do servio de VoIP com a rede pblica
de telefonia.
Gatekeeper: fornece servios de controle de chamadas para os terminais H.323
presentes na zona (zone). A zona um conjunto de terminais, gateways e MCUs
gerenciados por um nico gatekeeper ou domnio administrativo. Suas funes so:
Controle de acesso (autorizao de chamadas);
Traduo de endereos;
Gerenciamento de largura de banda;
Localizao de gateways;
Gerenciamento de zona;
Sinalizao de controle de chamada (no modo de conferncia roteado);
Gerenciamento de chamadas.
Figura 2.11: Componentes da recomendao H.323.
Os vrios padres e protocolos denidos na recomendao H.323 abrangem desde
os codecs utilizados at a segurana da ligao, sendo os mais importantes para VoIP
relacionados abaixo (gura 2.12):
34
H.323 - um documento que representa como os vrios componentes se encaixam
no sistema.
H.225.0 - dene a sinalizao entre os terminais e o gatekeeper.
RTP/RTCP - so usados para transmitir a mdia, udio e vdeo, em redes IP. Estes
protocolos so denidos pelo IETF, mas fazem parte da recomendao H.323.
H.245 - o protocolo usado para o controle do estabelecimento e fechamento dos
canais de transferncia de mdia e para o controle de conferncias.
H.450.x - uma srie de protocolos de servio suplementares (chamadas em espera,
transferncias de chamadas).
T.120 - especica como tratar dados em conferncias.
T.38 - dene como tratar o sinal de fax.
H.235 - dene a segurana do sistema.
Figura 2.12: Pilha de protocolos H.323.
2.4.1.4 MGCP e Megaco/H.248
Os protocolos MCGP (Media Gateway Control Protocol) do IETF e a recomendao
H.248 do ITU-T, tambm conhecida como Megaco (Media Gateway Control), so uti-
lizados nos gateways para controle da mdia e sinalizao. O Megaco um protocolo
desenvolvido em conjunto entre o IETF e o ITU-T, sendo que na nomenclatura do ITU
chamado de H.248.
O gateway tem a funo de interconectar a rede de telefonia pblica com os servios
de VoIP. Para isto so necessrias converses para que os protocolos de sinalizao da
telefonia convencional sejam adaptados aos de VoIP e vice-versa. Alm disto, existe a
necessidade de converter os diversos tipos de codicadores que podem ser utilizados em
VoIP, para o codicador padro PCM (mu-law ou a-law) da telefonia convencional. O
gateway pode ser um simples ATA (Analog Telephone Adapter) ou um equipamento que
permita a interconexo de chamadas VoIP atravs de vrios troncos de linhas integradas
com a rede pblica.
35
Originalmente, os gateways eram vistos como dispositivos monolticos que faziam
o controle das chamadas atravs de H.323 ou SIP e necessitavam de um hardware para
interfacear com a rede pblica de telefonia. Em 1998, a idia de separar o gateway em
duas partes lgicas foi proposta (DAVIDSON; JAMES, 2000). A parte que continha
o controle da lgica da chamada passou a ser denominada de MGC (Media Gateway
Controller), controlador de mdia do gateway, ou agente de chamadas. A outra parte, que
faz a conexo com a rede pblica, cou denominada MG (Media Gateway), ou gateway
de mdia. Com esta diviso, surgiu uma nova interface entre o MG e MGC. Para resolver
as interaes entre as duas partes do gateway foram denidos o protocolo MGCP e a
recomendao H.248/Megaco. Os Media Gateways fornecem as seguintes funes de
alto nvel (DAVIDSON; JAMES, 2000):
Terminao de troncos TDM oriundos da rede de telefonia pblica ou de PABXs.
Cancelamento de eco.
Balanceamento dos buffers de jitter.
Voice Activity Detection (VAD), supresso de silncio e gerao de rudo de con-
forto.
Compresso da voz usando codecs tais como: G.711, G.723.1, e G.729.
Gerao de tons, que originam os tons de discagem, ocupado e congestionamento.
Transporte de DTMF (Dual-Tone Multi-Frequency), que habilitam o uso de tons de
toque para aplicaes, tais como caixa postal de voz com codecs que suportam a
deteco/transporte de DTMF.
Converso entre os codecs mu-law e a-law quando necessrio.
Suporte para Quality of Service (QoS).
2.4.2 Protocolos de Mdia
2.4.2.1 RTP/RTCP (Real-Time Transport Protocol/Real-Time Transport Control Proto-
col)
O RTP (Real-Time Transport Protocol) denido em (SCHULZRINNE et al., 1996)
fornece funes de transporte de rede m-a-m adequado a aplicaes que transmitem
contedos de tempo real, tais como udio e vdeo, sobre servios de rede unicast ou
multicast. O RTP no fornece reserva de recursos e no garante QoS para servios de
tempo real. Omonitoramento da transmisso dos dados atravs de feedback do andamento
da transmisso pode ser realizada pelo RTCP (Real-Time Transport Control Protocol)
que funciona em conjunto ao RTP, embora no seja obrigatrio a sua implementao.
Ambos os protocolos, RTP e RTCP, usam o UDP como transporte. No caso de VoIP,
o RTP responsvel pela transmisso dos pacotes de voz. O protocolo RTCP tem a
funo de passar estatsticas ao emissor e ao receptor da chamada, tais como atraso, jitter
(variao do atraso) e perdas de pacotes. Tais estatsticas ajudam a determinar a qualidade
da chamada.
O cabealho do RTP ilustrado na gura 2.13. Ele consiste em trs palavras de 32
bits e, potencialmente, algumas extenses. A primeira palavra contm o campo Version,
36
Figura 2.13: Cabealho do protocolo RTP.
atualmente na verso 2. O bit P indica que o pacote foi completado at chegar a um
mltiplo de 4 bytes. O ltimo byte de preenchimento informa quantos bytes foram acres-
centados. O bit X indica que um cabealho de extenso est presente. O formato e o
signicado do cabealho de extenso no so denidos na RFC, deixando o cabealho
exvel para expanses. O campo CC informa quantas origens de contribuio esto pre-
sentes, de 0 a 15. O bit M um bit marcador especco da aplicao, pode servir para
marcar o incio de uma quadro de vdeo ou o comeo de uma palavra em um canal de
udio. O campo Payload Type informa o tipo de codec que est sendo utilizado na trans-
misso. O campo Sequence Number um contador incrementado a cada pacote RTP
enviado e tem a funo de detectar a perda de pacotes. O timbre de hora, representado
pelo campo timestamp, produzido pela origem do uxo para anotar quando a primeira
amostra do pacote foi realizada. Atravs da diferena entre os valores deste campo na
origem e no destino pode ser calculado o jitter e ajustado o buffer de jitter. O campo
Synchronization source identier informa a que uxo o pacote pertence. Este mtodo
usado para multiplexar e demultiplexar vrios uxos de dados em um nico uxo de
pacotes UDP. Os campos Contributing source identiers, se estiverem presentes, sero
usados quando houverem misturadores (mixers) de udio. Neste caso, o misturador ser a
origem de sincronizao, e os uxos que esto sendo mixados sero listados nesse campo.
Na gura 2.14, um exemplo de um pacote RTP capturado com o analisador de pacotes
Ethereal (ETHEREAL: A NETWORK PROTOCOL ANALYZER, 2005).
Figura 2.14: Cabealho de um pacote RTP com voz, capturado com o software Ethereal.
37
2.5 Codicadores (Codecs)
O termo codec um acrnimo de codicador/decodicador (coder/decoder). Basica-
mente, um codec um algoritmo que faz a digitalizao e a quantizao do sinal de vdeo
ou udio reduzindo o nmero de bytes gerados e, conseqentemente, diminuindo a lar-
gura de banda necessria para a transmisso ou o espao para o armazenamento. No caso
de VoIP, so usados vocodecs (voice codecs), que so codecs especcos para o espectro
de freqncia do sinal de voz.
O processo de digitalizao da voz tem como principais vantagens a transmisso em
longas distncias e a multiplexao entre voz e dados. Em transmisses de longa distn-
cia, o sinal sofre atenuao e perdas inerentes ao meio de propagao. Com isto, o sinal
sofre a ao de rudo. O processo de remoo dos rudos mais complexo em sinais ana-
lgicos do que em sinais digitais (MINOLI; MINOLI, 1998). Alm disto, a amplicao
que o sinal analgico sofre no decorrer da transmisso no diferencia o rudo do sinal
de voz. No sinal digital, a ltragem do rudo mais simples, pois antes da amplicao
o sinal regenerado pelos repetidores. Existem dois mtodos bsicos de digitalizao
e quantizao: um baseado em amplitude do sinal no decorrer do tempo (waveform), e
outro na anlise do espectro de freqncias (source codecs).
A qualidade da voz obtida atravs dos codecs funo do nvel de compresso, da
complexidade do algoritmo e do atraso no processamento. Usualmente, existe uma forte
interdependncia entre os fatores e devem ser balanceados para no prejudicar a quali-
dade da voz. No caso de VoIP, comum a converso entre diferentes tipos de codecs.
Isto ocasionado pelos diferentes tipos de terminais e pela integrao com a RPTC. A
converso adiciona atraso na conversao e perda de qualidade da voz, devido s perdas
de caractersticas do sinal no processo de codicao. Na gura 2.15 esto representados
os tempos de converso entre codecs em um servidor Asterisk (DIGIUM, 2005). Neste
caso, o maior tempo de converso entre codecs acontece entre o iLBC e o Speex, cerca de
58ms.
Figura 2.15: Tempos de converso entre codecs.
Atualmente, a maioria dos codecs de voz trabalham com largura de banda xa, no
dependendo das caractersticas do sinal de entrada. Entretanto, existem codecs que fazem
uso de largura de banda varivel, usando mecanismos de supresso de silncio (silence
supression) ou VAD(Voice Activity Detection) que no geramtrfego quando no h ativi-
dade de conversao. O desempenho do algoritmo de supresso de silncio crtico para
38
a qualidade da voz. Se existirem poucos intervalos de silncio na conversao, os ganhos
com a supresso de silncio no se concretizam. Normalmente, a porcentagem mdia
de atividade de conversao de aproximadamente 40% do tempo da chamada(JIANG;
SCHULZRINNE, 2000). Os problemas da tcnica de supresso de silncio so os rudos
do ambiente que confundem o algoritmo e a retomada da conversao, para resolver estes
problemas podem ser utilizados codecs diferentes para envio da voz e para envio do rudo.
Por exemplo, o rudo vai ser enviado com um codec que consuma menos largura de banda
e com qualidade pior do que o codec usado para a voz. Se houver demora na deteco
da retomada da conversao, o incio da conversa pode ser prejudicado. Dependendo do
codec utilizado e do terminal, o recurso pode ser ativado ou no. Outro recurso utilizado
para melhoria da qualidade da chamada a gerao de rudo de conforto (Comfort Noise
Generation). O rudo de conforto gerado no receptor da chamada para reconstruir o
rudo de fundo natural da telefonia, ao invs do silncio total. Este mecanismo tem a
funo principal de indicar ao receptor que a chamada continua ativa, e uma herana do
sistema telefnico convencional.
A ocultao de pacotes perdidos (Packet Loss Concealment) um mecanismo utiliza-
dos pelos codecs visando a diminuio do efeito da perda de pacotes. A perda de pacotes
pode se dar por um atraso excessivo ou por problemas no meio fsico. As perdas repre-
sentam queda de qualidade na conversao, tornando-a muitas vezes inteligvel. O meca-
nismo de ocultao de pacotes perdidos utilizado no codec do destino, o qual preencher
as falhas no sinal de voz. O preenchimento se d atravs da repetio do ltimo frame
recebido ou a gerao de um trecho de voz articial baseado nos frames recentemente
recebidos. Tal compensao de falhas no sinal de voz podem reduzir consideravelmente
os efeitos da perda de pacote para o usurio (HARDY, 2003).
Uma das principais caractersticas dos codecs o fator MOS (Mean Objective Score).
O MOS um processo subjetivo de classicao da qualidade da voz realizado pelo ITU.
A classicao vai de 1 a 5, sendo o valor 5 a melhor qualidade. Os codecs so classi-
cados pelo fator MOS. O fator MOS ser abordado com maiores detalhes no captulo
3.
Diferente do que acontece na rede de telefonia pblica, vrios tipos diferentes de
codecs podem ser utilizados em VoIP. Dependendo do mtodo de compresso utilizado, a
qualidade da voz e a largura de banda utilizada na chamada podem variar. Os mtodos de
compresso mais comuns so os seguintes:
PCM (Pulse Code Modulation):
- Utilizado na rede telefnica convencional;
- Possui a melhor qualidade entre os vocodecs por no usar compresso.
ADPCM (Adaptative Differential Pulse Code Modulation):
- Verso com compresso do PCM;
- Faz o clculo da diferena entre duas amostras, reduzindo a banda para at
16kbits.
CELP (Code Excited Linear Prediction):
- Faz uso de codebooks que geram ndices do padro da voz;
- So transmitidos apenas os ndices das amostras;
- Usa mais CPU, alm do aumento no atraso m a m entre 50 e 100ms.
39
LD-CELP (Low Delay Code Excited Linear Predction):
- Variao do CELP;
- Atrasos bem menores, na ordem de 2ms.
CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Prediction):
- Um dos mtodos mais utilizados;
- Possui tima qualidade de voz e baixo consumo de banda.
ACELP (Algebraic Code Excited Linear Prediction):
- Possui um algoritmo de look-ahead, de 7,5 ms;
- Adiciona atraso de 37,5 ms pois analisa 3 amostras de 10ms antes de formar
um pacote;
Diversos codecs so padronizados pelo ITU e pelo IETF, mas existem codecs padro-
nizados pela indstria e outros de cdigo-fonte aberto. Os mais comumente encontrados
nas aplicaes de VoIP so o G.711 (mu-law e a-law), GSM, G.729 e iLBC. Na tabela
2.1, so elencadas as caractersticas destes e de outros codecs.
Tabela 2.1: Caractersticas dos Codecs.
Codec Mtodo de
Codica-
o
Tamanho
da Amostra
(bytes)
Intervalo
da Amostra
(ms)
Banda
(kbits)
MOS
GSM RPE/LT 33 20 13,2 3,54
G.729a CS-ACELP 10 10 8 3,92
G.711 PCM 80 10 64 4,1
G.723.1 MP MLQ 24 30 6,3 3,9
G.723.1 ACELP 20 30 5,3 3,8
G.726 ADPCM 15 5 24 no dispo-
nvel
G.728 LD-CELP 10 5 16 3,61
iLBC LPC 50 ou 38 20 ou 30 13,33 e 15 3,92
Speex-8k CELP 20 20 2,15 a 24,6 no dispo-
nvel
2.6 Arquiteturas
Existem trs arquiteturas bsicas para implementao de servios VoIP. So elas:
Ponto a Ponto
Com gateway
Hbrida
40
2.6.1 Ponto a Ponto
Nesta arquitetura, os pontos terminais fazendo uso de softphones, telefones IP ou
clientes de servios (Skype, FWD) conectam-se diretamente entre si (gura 2.16c). Para
encontrar os pares da comunicao, so usados contatos externos ao servio, tais como
e-mail ou pginas web, ou pode ser usado algum recurso de procura. O recurso de procura
usado em servios como o Skype de forma distribuda ou no caso do FWD de forma
centralizada. O usurio faz a busca pelo nome ou nmero do par com o qual deseja falar.
A numerao gerada em cada servio e, no necessariamente, corresponde a alguma
forma de endereamento similar ao encontrado na rede de telefonia pblica. De posse
do endereo do par, pode-se fazer a conexo com o destino. Normalmente, este tipo de
arquitetura no possui tarifao.
2.6.2 Com gateway
O gateway tem a funo de integrar os servios VoIP com a rede de telefonia pblica.
Esta arquitetura utilizada para trafegar as ligaes atravs de servios VoIP sem modi-
car o servio de telefonia convencional nos terminais (gura 2.16b). Com isto, o trfego
de ligaes entre as localidades conectadas com gateways, no ser roteada pela rede de
telefonia pblica. Esta arquitetura comumente encontrada em empresas que possuem
unidades separadas geogracamente e interconectadas com enlaces de dados. Aprovei-
tando a estrutura de enlaces de dados, possvel fazer o roteamento das chamadas entre as
unidades sem passar pela rede pblica de telefonia. Desta forma, economiza-se no custo
das ligaes telefnicas.
2.6.3 Hbrida
Neste caso, os pares da comunicao podem estar em uma rede de dados, o origina-
dor na rede de dados e o receptor na rede pblica de telefonia e vice-versa, ou ambos na
rede de telefonia pblica sendo o trfego transferido atravs de uma rede de dados (gura
2.16a). Portanto, devem haver converses de codicadores e a numerao deve corres-
ponder a numerao utilizada na rede de telefonia pblica, pois os usurios de servios
VoIP devem poder enviar e receber ligaes da rede pblica.
2.7 Equipamentos
Os equipamentos utilizados nas arquiteturas de servios VoIP so basicamente termi-
nais e sistemas de controle. As funes realizadas pelos sistemas de controle recebem
nomenclaturas diferentes e diferem em funcionalidades quando utilizadas com o proto-
colo SIP ou a recomendao H.323. Os equipamentos foram divididos de acordo com as
suas funcionalidades. So eles Terminais, Centrais e Gateways.
2.7.1 Terminais
Os terminais tm como funes principais coletar a voz, codic-la e transmiti-la.
Devem obedecer aos protocolos e recomendaes para a sinalizao de chamadas. Os
terminais podem ser em hardware ou software. Nos terminais podem ser conguradas as
caractersticas dos codecs, tais como a nmero de amostras de udio por pacote, pode ser
ativado o recurso de VAD (Voice Activity Detection) e tamanho do buffer de jitter.
Em hardware, os telefones IP so os equipamentos mais comuns (gura 2.17). Exis-
tem diversos tipos de telefones IP, que so compatveis com SIP, H.323 e protocolos pro-
41
Figura 2.16: Arquiteturas de VoIP mais comuns.
prietrios. O custo destes telefones bem maior do que os telefones convencionais, alm
de possurem a necessidade de alimentao externa. Isto pode causar problemas em caso
de interrupo de energia eltrica. Alguns telefones IP permitem a congurao de QoS,
sendo possvel congurar a marcao de quadros ethernet no padro IEEE 802.1p e do
campo ToS (Type of Service) do protocolo IP.
Figura 2.17: Telefone IP Cisco modelo 7970.
Em software, so chamados softphones (gura 2.18) e possuem, normalmente, mais
funcionalidades do que os telefones IP, tais como maior nmero de tipos de codecs, ca-
pacidade maior de agenda e integrao com browsers. Alm da compatibilidade com os
protocolos padro, existem softphones que obedecem a protocolos proprietrios.
Para a interao com os usurios so necessrios microfones, fones de ouvido e placas
de som com capacidade full-duplex. Por ser executado em uma estao, todos os proble-
mas que podem ocorrer na estao afetam o funcionamento dos softphones, tais como
incidncia de vrus, uso excessivo de processamento e reinicializaes inesperadas do sis-
tema operacional. Seu custo muito menor do que um telefone IP, inclusive existindo
vrios softphones gratuitos.
42
Figura 2.18: Tela do softphone Xlite.
2.7.2 Centrais
As centrais tm a funo de controlar e gerenciar as ligaes entre os terminais. Po-
dem ser equipamentos especcos, tais como PABXs IP, ou softwares que podem ser
instalados em um PC comum de forma gratuita, tal como o Asterisk (DIGIUM, 2005).
As funes de tarifao, polticas de uso, redirecionamento de chamadas, caixa postal,
menu interativo e etc. so executadas nas centrais. No caso da recomendao H.323, o
Gatekeeper o responsvel por estas funes. No caso do protocolo SIP, o Proxy Server
tem estas funes.
2.7.3 Gateways
A funo principal dos gateways converter a sinalizao de controle e o formato da
mdia das chamadas telefnicas. Normalmente, tem a funo de converter a sinalizao
e a mdia das chamadas entre a rede pblica de telefonia e o servio de VoIP. usado
tambm para adaptar a conversao entre SIP e H.323, convertendo a sinalizao e se ne-
cessrio, o formato da mdia atravs do processo de transcodicao. Os adaptadores para
telefones convencionais chamados ATA (Analog Telephone Adapter) so gateways com a
funo de adaptar os telefones convencionais para uso com servios VoIP. A inteligncia
da comunicao est embutida no ATA, tendo o telefone como a interface com o usurio
(Figura 2.19).
2.8 Numerao
Cada terminal do sistema telefnico convencional, seja ele xo ou celular, tem associ-
ado um conjunto de nmeros ou cdigos de acesso que permitem que ele seja identicado
de forma exclusiva em todo o mundo. Para que isto fosse possvel, o ITU-T estabeleceu
a recomendao E.164 (ITU-T, 2005) que dene a estrutura e a distribuio dos cdigos
telefnicos no mundo. A numerao composta de 15 dgitos decimais, precedidos por
um sinal de "+", que identicam unicamente cada terminal telefnico, seja xo ou m-
vel. Estes nmeros so gerenciados dentro dos diferentes planos de numerao nacionais,
regionais ou globais. O ITU responsvel pela distribuio dos nmeros e cdigos de
cada pas, por exemplo 55 para o Brasil ou 1 para os EUA, para as regies, por exemplo
43
Figura 2.19: Conexes do Cisco 186 ATA (Analog Telephone Adapter).
3883 para Europa e nmero globais, por exemplo 00800 que dene um nmero de ligao
gratuita em todo o mundo.
Para integrar servios VoIP de forma transparente no plano de numerao existente,
foi criado o protocolo ENUM (FALTSTROM; MEALLING, 2004). O ENUM foi desen-
volvido como soluo para as questes de como elementos de rede poderiam usar servios
na Internet usando apenas nmeros telefnicos e como telefones convencionais poderiam
acessar servios na Internet usando um teclado de 20 teclas. O ENUM, basicamente,
tem a funo de tornar transparente a convergncia entre redes IP e a rede de telefonia
pblica fazendo o mapeamento de nmeros telefnicos convencionais para as funciona-
lidades da Internet. O ENUM faz uso do servio de DNS para transformar nmeros no
padro E.164 em formato URI (HUSTON, 2002). Desta forma, o uso de endereos nu-
mricos podem ser usados para representar qualquer tipo de servio, atravs do registro
de servios ENUM, tais como e-mail ou endereos de pginas (IANA, 2005). Quando
for digitado um endereo telefnico, ele ir ser mapeado para uma URI da seguinte forma
(ENUM.ORG, 2005):
1. O endereo telefnico traduzido para um nmero completo E.164, adicionado os
cdigos de rea e do pas.
Exemplo: O nmero 3316-6835 sendo discado em Porto Alegre, torna-se +55-51-
33166835. Onde o "55" representa o cdigo do pas (Brasil), o "51" representa
o cdigo que representa uma rea do estado do Rio Grande do Sul e o smbolo de
"+" identica um nmero E.164.
2. Todos os caracteres so removidos, exceto os dgitos.
Exemplo: 555133166835.
3. A ordem dos dgitos invertida.
Exemplo: 538661331555
4. Pontos so colocados entre cada dgito.
Exemplo: 5.3.8.6.6.1.3.3.1.5.5.5
5. O domnio e164.arpa acrescentado como suxo.
Exemplo: 5.3.8.6.6.1.3.3.1.5.5.5.e164.arpa
44
Aps esta transformao, o ENUM faz uma consulta ao servidor de DNS do dom-
nio. Quando o servidor de nomes responsvel (authoritative name server) encontrado,
o ENUM recupera informaes relevantes atravs da entradas nos registros NAPTR (Na-
ming Authority Pointer). Os registros NAPTR apontam para os servios que esto con-
gurados para o nmero telefnico cadastrado na base da dados do DNS. Abaixo um
exemplo de entrada NAPTR:
$ORIGIN 5.3.8.6.6.1.3.3.1.5.5.5.e164.arpa.
NAPTR 10 100 "u" "E2U+sip" "!^.
*
$!sip:emmonks@inf.ufrgs.br!".
NAPTR 10 101 "u" "E2U+h323" "!^.
*
$!h323:info@inf.ufrgs.br".
NAPTR 10 102 "u" "E2U+msg" "!^.
*
$!mailto:emmonks@inf.ufrgs.br!".
Este registro tema funo de descrever que o domnio 5.3.8.6.6.1.3.3.1.5.5.5.e164.arpa.
preferencialmente contatado por voz primeiramente atravs de SIP, e aps por H.323.
Em caso de no haver sucesso em nenhum destes contatos, ser tentado o contato por
e-mail atravs do protocolo SMTP (Simple Mail Transfer Protocol). O cdigo E2U deter-
mina que a entrada uma regra de reescrita ENUM e as diretivas sip, h323 e msg so tipos
de servios registrado pelo IANA para determinar o servio a ser acessado (IANA, 2005).
So usados mecanismos de expresses regulares para reescrever as regras. No exemplo
acima, o trecho "!^.*$!sip:emmonks@inf.ufrgs.br! faz com que seja substitudo o n-
mero telefnico 5.3.8.6.6.1.3.3.1.5.5.5.e164.arpa, pelo endereo sip:emmonks@inf.ufrgs.br.
Sendo assim, possvel utilizar a estrutura existente da Internet atual para integrar
o plano de numerao da rede de telefonia pblica com o servios de VoIP de forma
consistente.
2.9 Exemplos de Aplicao
2.9.1 Skype
Com quase 250 milhes de downloads do cliente, o Skype um servio de VoIP bas-
tante utilizado atualmente (SKYPE, 2005). Baseado em protocolos P2P (Peer to Peer), o
Skype um servio gratuito para comunicao de voz atravs da Internet entre os usu-
rios. Possui integrao com a rede de telefonia pblica, atravs dos servios SkypeOut e
SkypeIn. O primeiro um servio que possibilita aos usurios do Skype fazerem ligaes
para usurios localizados na rede de telefonia pblica. O segundo servio tem a funo
de possibilitar que usurios localizados na rede pblica de telefonia faam ligaes para
usurios no Skype. Ambos os servios so tarifados, embora o custo seja bem abaixo dos
praticados pelas empresas de telefonia convencional
Para usar o servio, o usurio deve baixar o cliente e fazer um cadastro. O ende-
reo para a localizao do usurio no sistema no possui relao com a numerao em
telefonia convencional. O usurio encontrado por um endereo alfanumrico, tal como
emmonks_123. No caso do uso do servio SkypeIn, fornecido um nmero para o usurio
ser contatado.
Os protocolos e os codecs usados pelo Skype so proprietrios e no so divulgados.
Ocialmente, as informaes pblicas a respeito dos codecs utilizados reportam que o
consumo de largura de banda ca entre 24 e 64 kbits, dependendo das condies da rede
e processamento. Em (BASET; SCHULZRINNE, 2004) foi feito um levantamento do
funcionamento do protocolo do Skype, onde foi relatado que os codecs utilizados so o
iLBC e iSAC. Neste estudo, no foi possvel determinar as trocas de mensagens porque
so utilizados mecanismos de criptograa tanto na sinalizao quanto nos uxos de mdia.
45
Figura 2.20: Tela do cliente do servio Skype.
2.9.2 Gizmo Project
O projeto Gizmo baseado em padres abertos, os quais so crticos para desenvolver
o potencial de VoIP. Segundo a empresa SIPphone, responsvel pelo projeto, as chama-
das telefnicas atravs da Internet devem ser gratuitas tais como as pginas web, e-mail e
mensagens instantneas. E para atingir o maior nmero de usurios foi adotado o proto-
colo SIP para a sinalizao (GIZMO PROJECT, 2005).
Para usar o servio necessrio o download do cliente (softphone) e o cadastro do
usurio. Aps o cadastro, o usurio receber um nmero de identicao no padro 1-
747-XXX-XXXX. O nmero determinante para a integrao com a rede de telefonia
pblica. Os servios adicionais CallOut e CallIn, permitem fazer e receber ligaes da
rede pblica de telefonia, respectivamente. A gura 2.21 apresenta o balano dos crditos
para as ligaes com o servio de CallOut. Estes servios adicionais so pagos, mas as
taxas so bem menores dos que as praticadas pelas empresas de telefonia convencionais.
Para os usurios domsticos obterem uma boa qualidade nas chamadas, necessrio
possuir uma conexo de banda larga, embora um acesso discado possa ser usado. A
largura de banda utilizada vai depender dos codecs utilizados. Abaixo o codecs usados
pelo Gizmo:
GSM
iLBC
iSAC
G.711 (mulaw e alaw)
EG711
iPCM
Uma opo interessante para redes corporativas o recurso de peering. Desta forma,
usando um servidor SIP pode-se habilitar que os nmeros internos da empresa sejam
46
Figura 2.21: Tela do cliente do Gizmo.
acessveis externamente. Se for desejvel, podem-se colocar placas para acesso a rede
de telefonia convencional. Com isto, um ramal convencional teria a capacidade de fazer
uma ligao para outro ramal convencional em outra empresa ou instituio. Todo o
trfego da chamada seria repassado pela Internet. Esta soluo de baixo custo e de fcil
implementao (SIPPHONE, 2005b).
47
3 QUALIDADE DE SERVIO (QOS)
O QoS (Qualidade de Servio) uma medida coletiva de nvel de servio apresentado
ao usurio. Pode ser considerado como sendo o nvel de conana na rede por deter-
minada aplicao para atingir os requisitos necessrios para o seu funcionamento (COL-
LINS, 2003). O QoS pode ser caracterizado por vrios critrios de desempenho tais como
disponibilidade, vazo, tempo de conexo, porcentagem de transmisses com sucesso e a
velocidade da deteco e correo de falhas. O uso de QoS para servios VoIP um fator
fundamental para garantia de qualidade da voz. A falta de mecanismos de QoS uma das
razes para que muitos dos servios de VoIP pela Internet sejam, atualmente, gratuitos.
A losoa que se baseia esta estratgia que dicilmente os usurios vo reclamar da
qualidade das chamadas, se elas forem gratuitas. Entretanto, a qualidade das chamadas
realizadas atravs de servios como o Skype e o Gizmo Project so muito boas na maior
parte das vezes, embora no exista garantia nenhuma de qualidade. Em uma rede cor-
porativa, possvel e desejvel garantir a qualidade das chamadas atravs de tcnicas de
QoS nos equipamentos de rede.
As medies da qualidade de servio em telefonia convencional possuem caracters-
ticas particulares, que sero descritas neste captulo e a seguir as caractersticas de QoS
para servios VoIP.
3.1 QoS em Telefonia Convencional
3.1.1 Taxa de bloqueio (GOS)
A taxa de bloqueio (Grade of Service ou GoS) a probabilidade de que uma nova
tentativa de chamada seja bloqueada ou perdida. Na rede pblica de telefonia a relao
do nmero de usurios no igual ao nmero de linhas disponveis, portanto os bloqueios
iro acontecer inevitavelmente. Em geral, esperado que cerca de 5 a 8% dos usurios
de uma central faam ligaes simultneas nos perodos de maior movimento, sendo que
cada telefone est ocupado de 10 a 16% do tempo (IVERSEN et al., 2005).
Em VoIP, o GoS um fator de QoS quando existe um gateway envolvido na chamada
VoIP ou est sendo usada alguma forma de controle de admisso de chamadas (call ad-
mission control). O controle de admisso de chamadas tem a funo de limitar o nmero
de ligaes simultneas na rede. Desta forma, o planejamento de capacidade da rede
garantido e os recursos da rede no so esgotados. No caso da arquitetura SIP, o controle
feito nos proxies, embora no exista nenhum mecanismo padronizado para tal. No caso
do H.323, o controle de admisso de chamadas denido na recomendao H.323 e est
presente nas funcionalidades do Gatekeeper. O GoS representado na forma de um fator
de bloqueio P.xx, onde xx a porcentagem das chamadas que sero bloqueadas ou per-
48
didas em determinado sistema. Por exemplo, um fator de P.01 dene a probabilidade de
que 1% das chamadas dos usurios possam ser bloqueadas.
Um fator de P.00 em telefonia convencional raramente requisitado e raramente acon-
tecer porque 100 % de no existncia de bloqueio, siginica dizer que o projeto da rede
deve manter a razo de 1:1 entre usurios e linhas. J em redes de pacotes, esta relao
passa a ser possvel. Devido ao compartilhamento dos canais de transmisso entre os
usurios, apenas a limitao dos recursos da rede, principalmente a largura de banda, so
os fatores limitantes para as chamadas serem realizadas.
A contabilidade do GoS no leva em conta as ligaes que no foram completadas em
razo do usurio estar ocupado ou no estar disponvel. So contabilizados somente os
bloqueios originados por falhas ou congestionamento na rede.
O fator GoS tem papel fundamental no planejamento de capacidade de um sistema
telefnico.
3.1.2 Disponibilidade
O sistema de telefonia pblica convencional considerado robusto e convel. Os
usurios de telefonia esto habituados a retirar o fone do gancho e quase invariavelmente
escutar o tom de discagem. A real porcentagem de disponibilidade do servio de telefonia
de 99,999 %. Isto signica que o servio ca indisponvel para uso por apenas 5 minutos
ao ano. Pode-se creditar estas taxas de disponibilidade, a simplicidade do sistema e a
preocupao dos fabricantes em produzirem equipamentos conveis.
J as redes de dados obtm valores de disponibilidade bem piores. Devido com-
plexidade do uso de mltiplos protocolos, e diversidade de fabricantes, provedores de
servios, sistemas operacionais, sistemas de gerenciamento de redes e outros, quase im-
possvel para as redes de dados alcanarem o nvel de conabilidade e disponibilidade da
telefonia convencional. Alm disto, problemas de segurana tais como vrus e ataques
de negao de servio afetam a disponibilidade de forma negativa. As melhores redes
privadas esto disponveis cerca de 94 % do tempo, em mdia. Isto signica que os usu-
rios cam sem acesso aos servios na rede de dados 22 dias durante o ano (CHONG;
MATTHEWS, 2004).
Em se tratando da Internet pblica com um todo, a disponibilidade chega a apenas
61%do tempo, o que emumano representa 142 dias indisponveis (CHONG; MATTHEWS,
2004).
3.1.3 Metas de Qualidade - ANATEL (Agncia Nacional de Telecomunicaes)
O Plano Geral de Metas de Qualidade (PGMQ) (ANATEL, 1998) foi criado pela
ANATEL para garantir a qualidade dos servios de telefonia xa e aplicvel s opera-
doras de telefonia xa no Brasil. O PGQM estabelece que 65% das chamadas originadas
por usurio tm que ser completadas. A chamada considerada completada quando, aps
a discagem, a chamada resulta em comunicao com o destino desejado. As razes para
no completar uma chamada podem ser:
O terminal chamado no atende a chamada.
O terminal chamado est ocupado.
O nmero discado no existe ou foi discado incorretamente.
Congestionamento na rede.
49
O PGMQ estabelece como meta que o nmero de chamadas no completadas por con-
gestionamento na rede seja menor que 4%, GOS de P.04, das chamadas em cada um dos
seguintes Perodos de Maior Movimento (PMM) conforme a tabela 3.1:
Tabela 3.1: Perodos de Maior Movimento (PMM).
PMM Intervalo
Matutino 9hs s 11hs
Vespertino 14hs s 16hs
Noturno 20hs s 22hs
Alm do monitoramento do complemento de chamadas, o PGMQ dene os seguintes
indicadores de qualidade (ANATEL, 1998):
Indicadores de Complemento de Chamadas Locais e Longa Distncia
- Devem ser completadas pelo menos 60% das chamadas locais e de longa
distncia, nos perodos matutino, vespertino e noturno.
- No pode ultrapassar 4% o nmero de chamadas (locais e de longa distncia)
no completadas por congestionamento na rede de telecomunicaes. Isso vale para
os perodos matutino, vespertino e noturno.
Indicadores de Mudana de Endereo
As solicitaes de servio de mudana de endereo dentro de uma mesma rea
local devem obedecer s seguintes metas de cumprimento de prazo:
- Usurios residenciais: pelo menos 95% das solicitaes atendidas em at 3
dias teis;
- Usurios no-residenciais: pelo menos 95% das solicitaes atendidas em at
24 horas;
- Usurios prestadores de servios de utilidade pblica: pelo menos 98% das
solicitaes atendidas em at 6 horas.
Indicadores de Atendimento ao Cliente
- Pelo menos 92% das chamadas de usurios devero ser atendidas em at 10
segundos pelos servios de auto-atendimento ou pela interveno de telefonistas.
Isso vale para os perodos matutino, vespertino e noturno.
- Devero ser respondidos em at 30 segundos pelo menos 95% dos pedidos
de informao de nmeros de telefone. Essa regra vale para as solicitaes feitas
atravs do auxlio lista, tambm conhecido como 102.
- Toda correspondncia dos usurios deve ser atendida em at cinco dias teis
aps seu registro de entrada na operadora.
- Pelo menos 95% dos clientes que se dirigirem aos postos de atendimento
devem ser atendidos no prazo mximo de 10 minutos.
Indicadores de Reparo de Telefone Convencional
- Para cada 100 linhas em servio numa localidade, no pode haver mais do que
trs solicitaes de reparos no ms.
50
- Os prazos para atendimento das solicitaes de reparos so os seguintes:
- Usurios residenciais: pelo menos 95% das solicitaes atendidas em at 24
horas.
- Usurios no-residenciais: pelo menos 95% das solicitaes atendidas em at
oito horas;
- Usurios prestadores de servios de utilidade pblica: pelo menos 98% das
solicitaes atendidas em at duas horas.
Indicadores de Reparo de Telefone de Uso Pblico
- Para cada 100 telefones de uso pblico em servio numa localidade, no pode
haver mais do que 15 solicitaes de reparos no ms.
- Os prazos para atendimento das solicitaes de reparos de telefone de uso
pblico so os seguintes: pelo menos 95% das solicitaes atendidas em at oito
horas.
Indicadores de Erro em Conta
- A cada mil contas emitidas (local e longa distncia), no mximo quatro podem
apresentar reclamao de erro.
- Pelo menos 95% das contas contestadas (local e longa distncia) que tenham
direito a crdito devero ter ressarcimento antes da emisso da prxima conta, em
forma de crdito.
Indicador de Sinal de Discar
- O tempo mximo de espera pelo sinal de discar deve ser de apenas trs se-
gundos em pelo menos 98% das ligaes. Isso vale para os perodos matutino,
vespertino e noturno.
Indicador de Modernizao da Rede
- Pelo menos 75% da rede local dever estar digitalizada.
Estes indicadores e os resultados atuais das operadoras de telefonia xa podem ser
visualizados em (ANATEL, 2005). No caso de servios VoIP, os seguintes indicadores da
PGMQ seriam aplicveis:
Indicadores de Complemento de Chamadas Locais e Longa Distncia
Indicador de Sinal de Discar
No existe legislao especca da ANATEL para os servios VoIP em relao a qua-
lidade de servio. Existe um anexo (ANATEL, 2001), que trata de servios de comunica-
o multimdia, mas no especica nenhum indicador de qualidade de servio. Portanto,
os indicadores de qualidade usados na telefonia xa comutada podem ser usados como
parmetros para o planejamento da capacidade da rede com servios VoIP.
51
3.2 Fatores de QoS
Em redes de pacotes, os fatores de QoS so diferentes dos encontrados na telefonia
convencional. Devido multiplexao do trfego, a concorrncia por recursos de rede po-
der ocorrer de forma imprevisvel. Diferente do que acontece na telefonia convencional,
onde so alocados recursos exclusivos para cada chamada.
A QoS oferecida pelas redes de pacotes pode ser representada atravs de parmetros
que indicam o comportamento do trfego. Portanto, a garantia de servios oferecida por
redes de pacotes medida atravs de parmetros de qualidade de servio. Os principais
parmetros de QoS do ponto de vista da rede so:
Atraso
Variao de Atraso (Jitter)
Perdas de Pacotes
3.2.1 Atraso
O atraso em VoIP caracterizado como sendo a quantidade de tempo que leva para a
fala sair da boca de um interlocutor e chegar ao ouvido do receptor (DAVIDSON; JAMES,
2000). O ITU atravs da recomendao G.114 especica que para se obter boa qualidade
de voz, no mais de 150ms deve ser o atraso m a m de um participante da conversao.
Na especicao tambm denido que no pode ser ultrapassado os 400ms de atraso m
a m de um participante. Se ultrapassado este limite, a conversao ser excessivamente
prejudicada. A recomendao G.114 do ITU-T dene trs faixas de aceitao para o
atraso:
0-150 ms: aceitvel para a maioria das aplicaes.
150-400 ms: aceitvel, desde que o administrador tenha conhecimento do tempo de
transmisso e seu impacto na qualidade da transmisso para aplicaes do usurio.
Acima de 400 ms: inaceitvel para propsitos gerais, entretanto, em alguns casos
excepcionais este limite pode ser excedido.
Umpacote de voz movido atravs da rede a umponto destino. Os tempos dos proces-
sos de codicao e empacotamento na origem e os tempos dos processos de eliminao
de jitter e decodicao no destino, somados, formam o atraso m a m ou atraso boca ao
ouvido (mouth-to-ear). So contabilizados no atraso m a m os tempos de propagao
do sinal na rede. Na gura 3.1, uma comparao entre o sinal original da voz e o sinal
resultante da chegada ao destino.
Existem dois tipos de atraso, o xo e o varivel (CISCO, 2005). Os componentes
do atraso xo so adicionados diretamente ao atraso total da conexo (gura 3.2). Os
atrasos variveis so originados nos atrasos da las dos roteadores, switches e gateways e
no tempo de propagao dos pacotes atravs da rede.
Tipos de atrasos xos:
Atraso de processamento do codec - o tempo gasto pelo processador de sinais
digitais (DSP - Digital Signal Processor) para comprimir um bloco de amostras
PCM. O tempo varia de acordo com o tipo de codec e o processador utilizado.
52
Figura 3.1: Efeito do atraso no sinal de voz.
Por exemplo, algoritmos do tipo ACELP (Algebraic Code Excited Linear Predic-
tion) analisam blocos de 10ms de amostras PCM, e aps realizada a compresso.
O tempo de compresso usado no algoritmo CS-ACELP (Conjugate Structure Al-
gebraic Code Excited Linear Prediction) varia de 2,5ms a 10ms dependendo da
carga no processador DSP. Normalmente, utilizado o pior caso nos clculos de
atraso. O tempo de descompresso corresponde aproximadamente a 10% do tempo
de compresso para cada bloco de amostras. Entretanto, o tempo de descompresso
proporcional ao nmero de amostras por frames. Conseqentemente, o pior caso
de descompresso para um frame com trs amostras, com o algoritmo CS-ACELP,
3ms (3 x 1ms). Usualmente, de dois ou trs blocos comprimidos com o codec
G.729 so colocados em um frame enquanto no caso do codec G.723.1 colocada
apenas uma amostra por frame.
Atraso de Algoritmo - em codecs do tipo vocoders, os algoritmos de compresso
baseiam-se em caractersticas conhecidas da voz para processar corretamente as
amostras de um determinado bloco. O algoritmo deve ter algum conhecimento do
que est contido no bloco seguinte para reproduzir com delidade o bloco atual. O
processo de conhecer o bloco posterior antes do envio do bloco atual denominado
look-ahead. Este processo, que acontece repetidamente, gera atraso adicional cha-
mado atraso de algoritmo. Por exemplo, no caso do codec G.729 de 5ms e no
caso do G.723.1 de 7,5ms.
Atraso de Empacotamento - o tempo gasto para preencher os dados (payload)
dos pacotes com voz codicada e comprimida. Este atraso funo do tamanho
do bloco de amostra requerido pelo codec e do nmero de blocos alocados em
um nico frame. O atraso de empacotamento tambm chamado de atraso de
acumulao, pois as amostras de voz so acumuladas em um buffer antes de serem
enviadas. Segundo (CISCO, 2005), como regra geral o atraso de empacotamento
no deve ultrapassar os 30ms.
Atraso de Serializao - o tempo utilizado para o frame contendo voz ou dados ser
repassado para a interface de rede. diretamente relacionado com a velocidade do
enlace. Devido s velocidades dos enlaces utilizados atualmente, o impacto deste
53
atraso mnimo. Para enlaces superiores a 768kbits o atraso desprezvel.
Figura 3.2: Diagrama de insero de atrasos na transmisso.
Atraso de Enleiramento/Acumulao - aps a voz ser comprimida, um cabealho
adicionado e o frame vai para la de transmisso na conexo de rede. O trfego
de voz deve ter prioridade absoluta nas las dos roteadores, gateways e switches.
Por isto, um frame de voz s deve esperar na la em casos em que um frame de
dados j estar sendo transmitido ou aguardar que outros frames de voz sejam trans-
mitidos. Essencialmente, o frame de voz espera o tempo de serializao de outros
frames prvios na la de sada. O atraso de enleiramento um atraso varivel e
dependente da velocidade do enlace e do estado da la. Um frame de voz deve ter
a garantia (prioridade) de no esperar mais de um frame de dados para ser enviado
ao meio fsico.
Atraso de eliminao de Jitter - o buffer de jitter tem a funo de transformar o
atraso varivel em um atraso xo. um buffer que armazena a primeira amostra
recebida por um certo perodo, at que um bloco de amostras seja formado e s
aps ser liberada a reproduo. O perodo de armazenamento chamado de atraso
inicial de reproduo. Este tempo essencial para o funcionamento eciente e para
eliminao do jitter. Se as amostras forem armazenadas por um curto perodo de
tempo, as variaes no atraso podem causar falhas na fala porque o buffer no ser
preenchido. Se as amostras forem armazenadas por um perodo muito longo, o buf-
fer pode esgotar, e as amostras sero descartadas causando falhas na fala. Quando
o perodo de armazenamento for muito longo, o tempo de atraso total m a m
poder atingir nveis inaceitveis e tornar a qualidade da chamada ruim. O valor
timo de tempo que um buffer deve armazenar o tempo total do atraso varivel na
conexo. O valor do tempo de buffer pode ser adaptativo, mas o atraso mximo
xo. Quando so congurados buffers adaptativos, o atraso ser torna varivel. En-
tretanto, o atraso mximo pode ser usado como pior caso para propsito de projeto.
Na tabela 3.2, esto tabulados os atrasos resultantes de uma transmisso utilizando o
codec G.729. O atraso denominado Rede corresponde latncia inserida no trfego do
pacote atravs da rede, que varivel.
54
Tabela 3.2: Origem dos atrasos usando o codec G.729 (GOODE, 2002).
Origem Atraso (ms)
Captura da amostra pelo dispositivo 0,1
Codicao 17,5
Empacotamento 20
Enleiramento (Emissor) 0,5
Acesso ao meio (Emissor) 10
Transmisso Rede
Acesso ao meio (Receptor) 10
Enleiramento (Receptor) 0,5
Equalizao de Jitter 60
Decodicao 2
Reproduo 0,5
Total 121,1+Rede
Rede Local 121,1+<10
3.2.2 Variao do Atraso (Jitter)
O atraso (latncia) representado como um valor de mdia. Entretanto, o servio de
VoIP sensvel a picos de atraso, o que torna o valor mdio no muito apropriado para
medir o efeito do atraso na qualidade da chamada.
Quando um uxo de pacotes transmitido atravs de uma rede IP, no existe garantia
de que cada pacote realizar o mesmo trajeto pela rede. Isto ocorre devido s rotas alter-
nativas que podem ser dinmicas e variar de acordo com as condies da rede. Por no
seguirem o mesmo caminho, os intervalos entre as chegadas dos pacotes podem variar.
Quando um pacote percorrer mais passagens por roteadores (hops) do que os outros do
mesmo uxo, pode ser ocasionado um atraso considervel e uma latncia maior. Alm
disto, partes da rede podem estar momentaneamente congestionadas, por exemplo, um
roteador pode estar sobrecarregado devido ao trfego intenso.
Caminhos alternativos e sobrecarga na rede, tanto em trfego quanto em equipamen-
tos, fazem com que a latncia torne-se irregular, e estes atrasos irregulares so chamados
de jitter. O efeito do jitter em VoIP corresponde diminuio da qualidade da voz, uma
vez que os intervalos irregulares tornam a conversao prejudicada. O jitter torna-se mais
signicativo quando utilizada a Internet para trafegar servios de VoIP, principalmente
em horrios de maior trfego. Para minimizar este efeito usado o recurso de buffer de
jitter, que ser abordado na seo 3.4.3.
O mximo jitter para os pacotes serem entregues de forma apropriada de 75ms
(CHONG; MATTHEWS, 2004). Na gura 3.3, o trecho de sinal de voz analisado est
com 10ms de jitter, pois o Atraso1 de aproximadamente 58ms e o Atraso2 de 68ms.
3.2.3 Perda de Pacotes
As redes de pacotes sem recursos de QoS no tratam os pacotes de voz de forma di-
ferenciada. Portanto, em casos de congestionamento e trfego intenso os pacotes de voz
sero descartados sem distino dos pacotes de dados. No caso dos pacotes de dados,
a retransmisso resolve o problema das perdas sem maiores prejuzos para a aplicao.
Mas, quando h perda de pacotes de voz a retransmisso no vivel. Cada pacote de
voz pode carregar de 10 a 80ms de voz, e dependendo da parte da conversao onde ocor-
55
Figura 3.3: Efeito do jitter no sinal de voz.
rem as perdas, pode inutilizar o dilogo entre os usurios. At mesmo 1% de perdas de
pacotes, no caso de uso do codec G.711, podem signicativamente degradar a qualidade
da conversao (COLE; ROSENBLUTH, 2001). Outros codecs podem causar maior de-
gradao da conversao devido compresso por eles imposta. A compresso deixa
os pacotes com maior tempo de sinal de voz e cada pacote perdido corresponder a um
trecho maior da conversao.
Os pacotes perdidos so ignorados no clculo do valor de jitter, j que podem ser
considerados pacotes com atraso innito e prejudicariam o resultado. A taxa mxima
de perdas de pacotes aceitvel de 3% (CHONG; MATTHEWS, 2004), mas codecs,
tais como iLBC (ILBCFREEWARE.ORG, 2005) e Speex (SPEEX.ORG, 2005) possuem
maior tolerncia a perdas.
A perda de pacotes na rede ocorre quando os pacotes so enviados, mas no so rece-
bidos no destino devido problemas ocorridos na rede. Detectar exatamente os problemas
de perdas de pacotes difcil de fazer porque cada codec possui o seu mtodo de oculta-
o de erros. Portanto, possvel que a qualidade da voz seja melhor usando um codec
com compresso, tal como o G.729A, do que um codec que no use, como no caso do
G.711 na mesma taxa de perdas.
Diversos fatores fazem com que os efeitos dos pacotes perdidos nas chamadas sejam
variveis. Entre eles esto (AVAYA, 2002):
Os efeitos so mais sentidos em pequenas rajadas de perdas do que em perdas
randmicas no decorrer do tempo. A perda de 10 pacotes contguos causa maior
prejuzo a conversao do que a perda de 10 pacotes distribudos durante certo pe-
rodo de tempo.
A perda de pacotes sentida com maior intensidade para pacotes com reas de
dados maiores do que em pacotes com reas menores. Isto ocorre porque mais
trechos da fala so perdidos com reas de dados maiores. O tamanho das reas de
dados so denidos nas conguraes dos codecs.
O efeito da perda de pacotes varia de acordo com a tolerncia de cada codec.
Segundo (WALLINGFORD, 2005), o mximo de perda de pacotes entre dois pontos
devem ser menor de 1%, para garantir que as chamadas tenham qualidade similar telefo-
56
nia convencional. Entre 1% e 3% a qualidade da voz ser similar qualidade da telefonia
celular. Mais de 3% de perdas pode at ser aceitvel para voz, mas poder interferir na
sinalizao da chamadas.
3.3 Fatores que afetam QoS
Existem fatores que afetam o QoS de servios VoIP. Estes fatores so oriundos das
caractersticas e dos equipamentos utilizados na estrutura da rede onde os servios de
VoIP esto sendo utilizados. Os fatores mais importantes que afetam o QoS em servios
VoIP, alm do atraso, jitter e perdas de pacotes, so:
3.3.1 Eco
O eco torna-se um incmodo medida que o atraso aumenta. Ecos com pouco atraso
so mascarados pela fala e so at mesmo agradveis de se ouvir durante a conversao,
dando a impresso de que o ouvinte est escutando bem o que est sendo dito e que a linha
no est muda. Mas quando o atraso aumenta, de tal forma que ao terminar a fala o usurio
percebe a prpria voz, o eco passa a degradar a qualidade da ligao. Por exemplo, se o
tempo de round-trip delay (atraso de ida e volta) da rede de aproximadamente 250ms, o
eco se torna bastante irritante mesmo com um nvel bastante baixo (RACHID, 2004).
Os dois tipos principais de eco so o acstico e de impedncia, embora existam outras
fontes de eco (RACHID, 2004). Ser sentido o eco quando uma chamada VoIP sair de
uma LAN atravs de um tronco analgico com problemas e ir para a rede de telefonia
pblica. Outro fator causador de eco o no casamento de impedncias entre sistema
telefnicos de 2 e 4 os. Circuitos de longa distncia necessitam de um ganho elevado
no sinal, por este motivo, so utilizados circuitos de quatro os que permitem o uso deste
ganho sem aparecer rudos na linha. Em casos de linhas de assinantes, so utilizados 2
os devido s distncias serem menores e para a diminuio do custo (RACHID, 2004).
Alm disto, o eco pode ser sentido quando o no casamento de impedncias ocorre na
converso entre o barramento TDM (Time Division Multiplexing) e a LAN, ou entre o
headset e seu adaptador (AVAYA, 2002).
O no casamento de impedncias causa inecincia na transferncia de energia. O
desbanlaceamento de energia deve ir para algum lugar e acaba sendo reetido de volta em
forma de eco. Usualmente, o participante da conversa que est falando escuta o eco, mas o
participante receptor no. Uma fonte bastante comum de eco com o uso de microfones e
caixas de som para ligaes telefnicas. O som recebido nas caixas de som captado pelo
microfone, retornado o sinal da voz para o emissor. Por isto, recomendvel a utilizao
de headsets.
Para amenizar o problema do eco so utilizados canceladores de eco. Os canceladores
de eco comparam a voz recebida com os padres recentes da voz. Se o padro combinar,
o cancelador atenua o eco. Canceladores de eco no so perfeitos. Sob algumas circuns-
tncias, o eco consegue passar o cancelador. O problema potencializado em sistemas
de VoIP. Se o atraso de um sentido do caminho one-way entre dois pontos for maior do
que a memria do cancelador, o cancelador de eco no ir nem achar o padro para o
cancelamento.
Na dissertao de mestrado de (RACHID, 2004) so discutidas vrias formas de can-
celar eco em redes com servios VoIP.
57
3.3.2 Trfego Concorrente
O trfego concorrente ao trfego da voz pode aumentar o jitter e o atraso considera-
velmente. A soluo para garantir a qualidade do pacotes de voz prioriz-los em relao
aos demais tipos de pacotes. Alm disto, deve ser reservada largura de banda para uso
exclusivo do trfego de voz. Isto nem sempre possvel devido ao custo, principalmente
em linhas dedicadas alugadas de provedores de servios de telecomunicaes. Neste caso,
pode-se usar codecs de menor qualidade e compresso dos cabealhos RTP, diminuindo
a necessidade de reserva de largura de banda para a voz.
3.3.3 Convergncia de Rotas
O tempo de convergncia de rotas pode ser tornar um problema para redes TCP/IP
usando servios de VoIP. Por exemplo, o protocolo de roteamento dinmico BGP (Border
Gateway Protocol) possui tempos de convergncia de rotas de vrios minutos, levando
cerca de 2 minutos para restabelecer as rotas e 30 minutos para anunci-las. No perodo
de tempo at a convergncia de rotas, os sistemas autnomos envolvidos caro inalcan-
veis impossibilitando a comunicao de rede com os mesmos.
3.4 Garantias de QoS
Para se garantir a qualidade dos servios de VoIP, alguns fatores devem ser levados em
conta. Estes fatores, tais como os equipamentos e mecanismos de QoS, so determinantes
para a garantia do nvel de servio e da disponibilidade do servio VoIP.
3.4.1 Equipamentos
A qualidade da conversao telefnica sofre inuncia direta dos equipamentos uti-
lizados. No caso de telefones convencionais, a qualidade do aparelho telefnico exerce
grande inuncia na qualidade da conversao. Entretanto em telefonia convencional,
os problemas mais comuns so relativamente simples, tais como problemas com o alto-
falante ou com o microfone. Os equipamentos intermedirios so geralmente bastante
robustos e planejados em estruturas que garantem os nveis de QoS desejados. Em ser-
vios VoIP, tanto os equipamentos utilizados nos terminais (softphones, telefones IP, he-
adsets, microfones, placas de som) quanto no equipamentos intermedirios (gateways,
servidores, switches, roteadores) esto sujeitos a vrios tipos de problemas. No caso de
terminais VoIP, o atraso inserido no tratamento do sinal de voz pode comprometer a qua-
lidade da conversao, principalmente em softphones (JIANG; KOGUCHI; SCHULZ-
RINNE, 2003). A qualidade dos equipamentos intermedirios pode afetar os fatores de
QoS negativamente, principalmente em relao ao atraso. Isto ocorre devido ao tempo
de converso entre codecs e tratamento dos pacotes de udio em roteadores, switches e
gateways. Alm disto, os softwares embarcados nos equipamentos esto sujeitos a bugs
e a incompatibilidades. Devido ao aumento dos pontos de falhas, torna-se necessrio o
uso de equipamentos redundantes. Atualmente, existem diversos fabricantes de equipa-
mentos VoIP, existindo modelos com os mais diferentes tipos de funcionalidades, preos
e qualidades.
3.4.2 Mecanismos de QoS Nvel 2 e 3
Na estrutura da Internet atual, garantir os nveis de QoS desejveis para VoIP pratica-
mente impossvel. Embora alguns experimentos mostremser possvel obter boa qualidade
58
em conversaes usando VoIP na Internet (BIYANI et al., 2003) e (JI; SCHULZRINNE,
2003), as garantias de qualidade so inexistentes. A disponibilidade do servio deve ser
semelhante encontrada na telefonia convencional, e para atingir esta meta o uso da In-
ternet sem QoS deve ser descartada. Entretanto, em redes corporativas possvel montar
uma estrutura que possibilite as garantias de QoS necessrias para a disponibilidade dos
servios VoIP. Os mecanismos de garantia de qualidade se dividem em dois tipos, os
mecanismos de QoS (Quality of Service) e os mecanismos de CoS (Class of Services).
Os mecanismos de QoS garantem os nveis necessrios de servio m a m, tais como
largura de banda e atraso, para a garantia de qualidade de uma aplicao. Para uma aplica-
o de misso crtica, o QoS signica largura de banda garantida sem nenhuma perda de
pacotes. Existe uma diculdade maior para a implantao de QoS na rede devido ao maior
controle necessrio para a congurao. Por exemplo, no caso do protocolo IntServ (In-
tegrated Services) cada dispositivo deve possuir uma entrada em tabela registrando cada
uxo. Em uma grande rede corporativa, os dispositivos podem car saturados com milha-
res de uxos simultneos. As redes ATM, Frame Relay e MPLS (Multi-Protocol Label
Switching) so exemplos de redes que fornecem nvel de servio por uxo de aplicao. O
RSVP (Resource Reservation Protocol) um protocolo que possui mecanismos de QoS.
Este protocolo prov QoS atravs da reserva de largura de banda e de recursos ao longo
de todo o caminho do uxo. O RVSP implementado em alguns roteadores, switches de
nvel 3 e no Windows 2000 Server ou superior (INTEL, 1999).
Os mecanismos de CoS (Class of Services) fornecem a priorizao de trfego em um
simples enlace de dados. Enquanto os mecanismos de QoS tratam de redes mais comple-
xas, o CoS trata de apenas um enlace de dados. Portanto, um switch ethernet pode prover
priorizao de pacotes atravs de CoS para um nico host, enquanto um grupo de roteado-
res pode participar de um esquema mais elaborado de QoS. Os sistemas de CoS denem
um comportamento por hop, isto , por dispositivo que trata o pacote. Desta forma, no
possvel garantir o nvel de servio em termos de capacidade ou velocidade m a m. Os
sistemas CoS utilizam os recursos para entregar os pacotes marcados como prioritrios de
acordo com o comportamento congurado em cada dispositivo. As solues com siste-
mas CoS so ecientes onde menos de 30% do trfego composto por pacotes de voz, o
que ocorre na maioria das redes corporativas atualmente (WALLINGFORD, 2005). Dois
esquemas, que suportam CoS, podem ser utilizados para garantir a prioridade de VoIP em
redes corporativas. So eles:
Nvel 2 - IEEE 802.1Q/802.1p/ToS
Nvel 3 - DiffServ
3.4.2.1 Nvel 2 - IEEE 802.1Q e IEEE 802.1p
O padro IEEE 802.1Q, denido em 1998, modicou o cabealho do quadro ethernet
para disponibilizar o uso de VLANs e prioridades em redes locais. As VLANs provm a
criao por software de domnios de difuso (broadcast) limitados, atravs da criao de
subredes virtualmente separadas. Os broadcasts, em se tratando de redes padro ether-
net, so normais. Este mecanismo utilizado por protocolos para a realizao de vrias
funes, tais como o anncio de servios. Ao se criar uma rede VLAN separada para o
trfego de voz, ocorrer a diminuio da quantidade de trfego de broadcast que um host
receber. O uso de VLANs separadas resulta em uma utilizao mais efetiva da largura
de banda e a reduo do uso de processador no caso de telefones IP, pois no haver a
59
necessidade de analisar trfego broadcast irrelevante. Outra vantagem das VLANs a
segurana, pois o trfego de nvel 2 car contido dentro da VLAN.
Para usar efetivamente o conceito de VLAN, os switches e as placas de rede devem
seguir o padro IEEE 802.1Q. Normalmente, so os switches os responsveis por mo-
dicar os quadros entrantes na portas, mas cada vez mais comum as placas de rede
reconhecerem o padro IEEE 802.1Q (TANENBAUM, 2003).
Os hosts so identicados pelos endereos fsicos e indexados a uma VLAN. Existe
pelo menos uma VLAN, a VLAN 0, que padro na congurao de switches. Podem
ser criadas VLANs de 0 a 4096 e o quadros cam marcados com o nmero da VLAN
qual pertencem. Por exemplo, se um quadro marcado como VLAN 4 chegar na porta
3, ento alguma mquina da VLAN 4 est na porta 3. Com isto possvel montar de
forma transparente a tabela de endereos fsicos indexada pela identicao da VLAN.
Em redes com servios VoIP, recomendvel que se tenha pelo menos duas VLANs, uma
para o trfego de voz e outra para o trfego restante.
O padro IEEE 802.1p foi denido juntamente com o 802.1Q e permitiu o uso de
mecanismos de qualidade de servio em redes ethernet. Este padro utiliza 3 bits do
cabealho ethernet para classicar cada quadro em um nvel particular de precedncia.
Cada nvel de precedncia dene o tratamento que o quadro vai obter em cada switch,
pois a quantidade e os tipos de las em cada switch podem variar. O campo ToS (Type
of Service) do protocolo IP utilizado para marcar o valor da precedncia do pacote e
interpretado nos roteadores. Normalmente, existe um mapeamento do 802.1p para o
campos ToS. Muitos fabricantes chamam esta soluo de ToS IP Precedence. J que so
alocados 3 bits para classicao dos quadros, existem 8 tipos de classes de servios e
so apresentadas na tabela 3.3. Quanto maior o valor, maior a prioridade. O valor 5
padronizado para o trfego de voz. Podem ser utilizadas at 8 las no switches, mas o
mais comum o uso de 2 las por porta, sendo uma para trfego com prioridade, nmero
de classe diferente de 0, e outra para o restante do trfego.
Tabela 3.3: Classes de servios do IEEE 802.1p.
Nmero da Classe Tipo de Trfego
0 Melhor esforo (padro)
1 Mais baixa prioridade
2 Indenido
3 Mdia prioridade
4 Carga Controlada
5 Crtico (padro para voz)
6 Roteamento
7 Gerenciamento (mais alta prioridade)
As prioridades da classes de servios podem ser modicadas pelos fabricantes. Por
exemplo, nos switches da HP modelos ProCurve Switch 5300xl, ProCurve Switch 3400cl
e ProCurve Switch 2650 existem quatro las de prioridade por porta e a denio das
classes de servio est representada na tabela 3.4 (HP, 2005).
O padro 802.1p um recurso cada vez mais comum em switches, at mesmo em
switches de baixo custo tais como os modelos Baseline da empresa 3Com (3COM, 2005).
60
Tabela 3.4: Classes de servios dos switches HP.
Nmeros da Classe Prioridade
1 e 2 Baixa
0 e 3 Normal
4 e 5 Mdia
6 e 7 Alta
3.4.2.2 Nvel 3 - DiffServ
O esquema de priorizao com DiffServ (Differentiated Services), (NICHOLS et al.,
1998; BLAKE et al., 1998), redene o byte do campo TOS (Type of Service) do cabealho
do protocolo IP em uma maneira mais elaborada do que no 802.1p. Enquanto o 802.1p
usado em switches ethernet, o DiffServ usado em enlaces ponto a ponto entre roteadores.
Quando um pacote recebido no roteador, de um n da rede ou de outro roteador, o Diff-
Serv marca o campo ToS do cabealho do pacote baseado na poltica associada natureza
do pacote em questo. Uma vez marcado o pacote, os demais roteadores do caminho de-
vem obedecer marcao. Sendo os pacotes marcados nos roteadores mais prximos dos
terminais, os demais roteadores somente repassam os pacotes, no necessitando refazer a
marcao. O DiffServ no garante reserva de recursos, mas sim a priorizao dos pacotes
baseado em polticas. Normalmente, as marcaes denidas no 802.1p e no DiffServ po-
dem ser relacionadas atravs de tabelas. Na tabela 3.5, um exemplo do mapeamento entre
marcaes 802.1p e DiffServ, em destaque os valores atribudos para o trfego de voz.
Tabela 3.5: Mapeamento entre valores de CoS (802.1p) e DSCP (DiffServ).
CoS (802.1p) 0 1 2 3 4 5 6 7
DSCP 0 8 16 24 32 40 48 56
Os DSCP (DiffServ Code Points) so 6 bits do campos ToS do cabealho do protocolo
IP que denem os nveis de servio. Embora a maioria das implementaes suportem ape-
nas 3 bits, substituindo os 3 bits do campo ToS original. Os outros 3 bits so reservados
para extenses do padro DiffServ (WALLINGFORD, 2005). O comportamento dos va-
lores de DSCP so divididos em trs grupos, chamados classes PHB (Per-Hop Behavior),
classes de trfego ou classes DSCP e so elas:
AF (Assured Forwarding) - classe DSCP para rpida vazo dos pacotes, usada prin-
cipalmente para a sinalizao das chamadas VoIP.
EF (Expedited Forwarding) - a classe DSCP voltada para a vazo mais rpida dos
pacotes, usada para a marcao dos pacotes que contm voz.
BE (Best Effort) - a classe DSCP utilizada para trfego de melhor esforo.
Quando os pacotes so analisados pelos roteadores com DiffServ ativo, o roteador de-
cide que tipo marcao ser usada baseado em qual classe de DSCP o pacote estar inse-
rido. Pacotes com alta prioridade recebero uma marcao AF ou EF, enquanto os pacotes
com mais baixa prioridade recebero uma marcao BE ou nenhuma. As classes DSCP
so compatveis com as classes ToS, portanto o DiffServ pode fazer uso da priorizao
com 802.1p em redes locais distintas. Um exemplo de uso do DiffServ com roteadores
61
utilizado o sistema operacional GNU/Linux com kernel 2.4 ou mais atual. Atravs do uso
da ferramenta iptables possvel congurar a marcao de pacotes com classes DSCP,
como no exemplo:
iptables -A PREROUTING -p udp -D 0.0.0.0/0.0.0.0 --dport 8000 \
-j DSCP --set-dscp-class EF
Com a linha de comando acima, os pacotes do protocolo UDP com destino a porta
8000 sero marcado no campo DSCP como sendo do tipo EF. A marcao ocorrer antes
do roteamento (PREROUTING). A porta 8000 UDP dever ser congurada nos terminais
para o envio dos uxos de udio RTP.
Na gura 3.4, esto representados os mecanismos de QoS e CoS em uma rede corpo-
rativa hipottica.
Figura 3.4: Esquema de uso dos mecanismos de Qos e Cos.
3.4.2.3 Melhores Prticas
Algumas prticas para garantir a qualidade de servio na rede para servios VoIP, so
listadas a seguir (WALLINGFORD, 2005):
Se o trfego de rede para pacotes de voz for menor do que 30%, eciente o uso
das tcnicas de DiffServ e IEEE 802.1p;
Em conguraes com DiffServ, utilizar a classicao de uxos RTP de udio
como EF (Expedited Forwarding);
Em conguraes com 802.1p, utilizar a classicao do trfego de voz como mar-
cao 5 (em alguns casos o valor 160, pois so os 3 bits mais signicantes de 8
bits. Exemplo 10100000 em binrio corresponde a 160 em decimal).
62
Utilizar, se possvel, uma VLAN exclusiva para o trfego de voz;
Utilizar las de baixa latncia (LLQ - Low Latency Queuing) nos roteadores para
os uxos de udio RTP;
Quanto maior a largura de banda, menores as chances de ocorrerem problemas
com atrasos, jitter e perdas no pacotes de voz. Embora no resolva o problema da
garantia do servio, o aumento da largura de banda diminui bastante os problemas
atrelados ao VoIP;
Utilizar o codec G.711 sempre que possvel. um dos codecs com melhor resis-
tncia a perdas e com o menor atraso de codicao;
Para minimizar o atraso, pode-se diminuir o tamanho por pacote. Em redes locais,
onde o atraso de propagao baixo, o aumento do nmero do tamanho do pacote
diminui o overhead e conseqentemente a largura de banda. Em enlaces onde o
atraso maior, a diminuio de amostras por pacote torna o atraso m a m menor.
Evitar ao mximo a transcodicao. Os atrasos e a perda de qualidade na conver-
so de codecs no so desejveis.
Manter a porcentagem de perdas de pacotes nos segmentos de rede abaixo de 1%;
Quando existe limite de largura de banda, recomendada a utilizao de tcnicas
de QoS tais como RVSP e MPLS.
3.4.3 Buffer de Jitter (Equalizador de Jitter)
O buffer de jitter ou equalizador de jitter transforma uma atraso varivel em um atraso
xo. Sua funo armazenar as amostras de udio por um determinado tempo, com a
funo de sincroniz-las. Este tempo de armazenamento chamado de atraso inicial de
reproduo (initial play out delay). essencial a durao do tempo de armazenamento das
amostras no buffer. Se as amostras forem armazenadas por muito pouco tempo, variaes
no atraso podem causar falhas na conversao. Se as amostras forem armazenadas por
muito tempo, o buffer pode estourar, e os pacotes descartados tambm podem causar
falhas na conversao. Alm disto, um tempo de armazenamento extenso pode elevar
muito o atraso total da conversao. O valor timo para o tempo inicial de reproduo
igual ao tamanho do atraso varivel ao longo da conexo (CISCO, 2005). O valor
do buffer pode ser adaptativo, mas o valor mximo de atraso xado. Quando buffers
adaptativos so utilizados, o atraso torna-se varivel. Entretanto, o valor mximo de atraso
pode ser usado com o pior caso para clculos de projeto. Na gura 3.5, uma representao
do mecanismo de equalizao de buffer.
3.4.4 Redundncia
Tradicionalmente os PABXs so sistemas extremamente conveis e muitos fabrican-
tes garantem 99,999% por ano de disponibilidade. A arquitetura tradicional dos PABXs
chega a este nvel de disponibilidade devido a componentes conveis e redundncia
prevista no projeto (BRANDL et al., 2004).
Um grande problema do servio de VoIP prover o mesmo nvel de disponibilidade
da telefonia convencional. Uma das formas de garantir a disponibilidade fazer com
que os gateways e os terminais possam se registrar em mltiplos servidores. Se um dos
63
Figura 3.5: Posicionamento do buffer de jitter.
servidores car inoperante, o registro passa a ser feito por um servidor sobressalente.
Dependendo de como isto feito e da inteligncia atrelada ao telefone e ao gateway,
o novo registro pode ou no afetar a conexo ativa (o caminho do uxo de voz). Se o
servidor principal e o de backup compartilharem informaes de controle de chamadas,
ento, aps o novo registro, os usurios podem continuar as conversaes. A continuidade
da ligaes pode ser crtica em call centers onde importante no desconectar usurios
que esto na la para serem atendidos. Redes TCP/IP podem ser projetadas para serem
altamente redundantes com mltiplos caminhos entre os dispositivos. Embora, em muitos
casos, exista apenas umenlace entre o servidor de controle e o gateway. Se o enlace falhar,
toda a rea servida pelo gateway car sem o servio. O problema pode ser resolvido
utilizando enlaces alternativos e inteligncia no controle dos servidores de controle e dos
gateways (COFFMAN, 2004).
3.4.5 Fragmentao de pacotes
A fragmentao de pacotes em enlaces de baixa velocidade, abaixo de 1Mbits, pode
ser usada quando o atraso de envio dos pacotes for signicante. Por exemplo, um pacote
de 768 bytes leva 48ms para ser transferido em um enlace de 128Kbits. Se existir um
pacote de voz esperando na la para ser transmitido, ser adicionado um atraso de 48ms
na chamada. Sendo que os tamanhos dos pacotes podem variar, o jitter ser aumentado.
Para diminuir o problema, podem-se usar tcnicas de fragmentao e intercalamento de
pacotes entre os roteadores dos enlaces de baixa velocidade. Fragmentando os pacotes, o
tempo de transferncia menor, conseqentemente, os tempos de espera de transferncia
sero menores, e poder haver maior vazo dos pacotes prioritrios de voz.
3.4.6 Compresso de cabealhos
Alargura de banda necessria para transmisso de voz pode ser reduzida se o overhead
de cabealho for reduzido. Em (CASNER; JACOBSON, 1999) descrito o protocolo
cRTP (Compressed RTP) para compresso dos cabealhos dos protocolos RTP/UDP/IP.
Normalmente, a soma dos cabealhos RTP/UDP/IP possuem 40 bytes (12 bytes RTP, 8
bytes UDP e 20 bytes IP). Utilizando a compresso, o cabealho poder ser reduzido para
2 ou 4 bytes (gura 3.6). A compresso para 2 bytes no usa o campo checksum do pro-
tocolo UDP, enquanto a compresso com 4 bytes utiliza, diminuindo signicativamente o
overhead.
Embora seja reduzida a largura de banda consumida, adicionado um atraso pelo uso
64
Figura 3.6: Cabealho com compresso do protocolo RTP.
da compresso dos cabealhos pelos roteadores. Portanto, deve haver um balanceamento
destes fatores. Alm disto, as compresses usadas com o RTP sofrem de problemas de
incompatibilidade entre as implementaes dos fabricantes e s podem ser usadas em
enlaces ponto a ponto.
3.4.7 Alimentao de Energia
A alimentao de energia uma fator importante para aumentar a disponibilidade
dos servios de VoIP. Na telefonia convencional, a alimentao dos terminais fornecida
pelas centrais telefnicas. Os equipamentos intermedirios devem estar alocados em uma
infra-estrutura que garanta o fornecimento de energia constante, atravs de no-breaks e
geradores de energia. O problema maior encontrado no fornecimento de energia para os
terminais. Em caso de softphones, o computador deve estar conectado a um no-break, por
exemplo. No caso de telefones IP, existe a possibilidade de usar o mecanismo de Power
over Ethernet (PoE) (IEEE, 2003), no qual o fornecimento de energia feito atravs do
cabeamento de rede.
3.4.8 Planejamento de Capacidade da Rede
Oplanejamento de capacidade de rede de suma importncia para garantir a qualidade
do servio de VoIP, pois dimensiona o volume de servios a quantidade de recursos da
rede.
Ser visto em maiores detalhes no captulo 4.
3.5 Formas de Medio da Qualidade da Voz
A medio da qualidade da voz em sistemas de comunicao tende a ser subjetiva e
de difcil mensurao. Ao longos dos anos, foram desenvolvidas vrias tcnicas com o
objetivo de analisar a qualidade percebida pelo usurio. As tcnicas so de dois tipos:
objetivas e subjetivas.
O critrio principal para denir a qualidade do udio em conversaes telefnicas
a percepo do usurio, portanto, um critrio subjetivo. A qualidade pode ser medida
atravs de mtodos subjetivos. Embora os mtodos subjetivos sejam os mtodos mais
conveis, eles tambm so de alto custo e demorados. Desta forma, mtodos que possam
65
utilizar parmetros fsicos so desejveis. Os mtodos que podem analisar a qualidade do
servio de voz atravs de parmetros de rede so chamados mtodos objetivos.
Uma das primeiras abordagens para avaliao da qualidade da voz foi a utilizao da
Pontuao de Opinio Mdia, ou MOS (Mean Opinion Score), mtodo subjetivo denido
nas recomendaes ITU-T P.800 e ITU-T P.830 , pelo qual um conjunto de avaliado-
res ouvintes atribuem uma pontuao de 1 (pobre) a 5 (excelente) qualidade da fala
reproduzida pelo sistema de comunicao em teste. Como expressa diretamente a opi-
nio mdia dos usurios, o MOS representa um ndice de referncia para avaliao da
qualidade da fala em sistemas de comunicao. Dentre os mtodos objetivos, destaca-se
o Modelo E, originalmente proposto pelo ETSI (European Telecomunications Standards
Institute), e posteriormente padronizado pelo ITU-T (International Telecommunications
Union-Telecommunications Standard Sector), atravs da Recomendao G.107. Outros
exemplos de mtodos objetivos so o PSQM (Perceptual Speech Quality Measure), o
PAMS (Perceptual Analysis Measurement System) e o PESQ (Perceptual Evaluation of
Speech Quality). Estes mtodos fazem uso do conhecimento do sistema auditivo humano
para comparar um sinal de referncia (trecho de voz previamente gravado) com um sinal
degradado (sinal de referncia submetido ao sistema de transmisso a ser avaliado), a m
de compor uma medida de distoro do sinal de voz (LUSTOSA, 2005).
Os mtodos MOS e Modelo E so descritos a seguir.
3.5.1 MOS - (Mean Opinion Score)
O mtodo subjetivo mais usado o fator MOS (Mean Opinion Score) denido pelo
ITU-T na recomendao P.800. O fator MOS um valor entre 1 e 5 que dene a quali-
dade da conversao. O valor 5 a melhor qualidade, enquanto o valor 1 a pior. Para
determinar este nmero, uma srie de oraes faladas so transmitidas aos ouvintes por
um sistema de compresso de voz (codec). Para cada orao, os ouvintes devem alocar
um nmero de acordo com uma escala de valores, onde a mdia aritmtica dos resultados
de todos os ouvintes dene a pontuao MOS para o sistema de compresso de voz em
questo. Abaixo a escala de valores utilizada nos testes para obteno do fator MOS:
5 - Excelente - o usurio no percebe degradaes no sinal.
4 - Bom - o usurio percebe degradaes mnimas no sinal.
3 - Razovel - o usurio percebe degradaes no sinal, mas com esforo, consegue
entender a mensagem.
2 - Ruim - o sinal possui interrupes devido as degradaes e o usurio deve fazer
esforo para entender trechos da mensagem.
1 - Pssimo - initeligvel, o usurio no entende nada da mensagem, mesmo com
esforo.
O valor 4 do fator MOS dene a qualidade da voz em telefonia xa convencional, en-
quanto que valores entre 3,5 e 4 caracterizam a qualidade da voz em telefonia celular. Os
valores dependem, principalmente, dos codecs utilizados. O codec com o melhor fator de
MOS o G.711 (tabela 2.1).
66
3.5.2 Modelo E
Os mtodos subjetivos de medio de qualidade da voz so caros e demorados e no
consideram os prejuzos ocasionados pela transmisso atravs de uma rede de pacotes.
So necessrios mtodos para estimar a qualidade subjetiva da voz, medindo os par-
metros da rede e dos equipamentos envolvidos na comunicao. Todos os mtodos que
fazem estimativas da qualidade da voz atravs de parmetros de rede e de equipamentos
so chamados de mtodos objetivos.
Os mtodos objetivos podem ser categorizados em vrios grupos do ponto de vista de
objetivos, procedimentos de medio, entradas de dados e estimativa de MOS. Segundo
(TAKAHASHI; YOSHINO; KITAWAKI, 2004), existem trs grupos principais de m-
todos objetivos: os modelos de opinio (opinion models), os modelos de nvel de voz
(speech-layer models) e os modelos de nvel de pacote (packet-layer models). Os mode-
los de opinio utilizam as caractersticas da rede e dos equipamentos para estimar o fator
MOS. Os modelos de nvel de voz utilizam sinais de voz como entrada e executam ltros
para estimar o fator MOS. O mtodo dos modelos de nvel de pacote utilizam parmetros
dos pacotes IP para estimar o fator MOS.
O modelo E, denido na recomendao G.107 do ITU-T de 1998, e adotado pelo
European Telecommunications Standards Institute (ETSI) e pelo Telecommunications In-
dustry Association (TIA) como uma ferramenta de planejamento de rede o modelo de
opinio mais usado no mundo (TAKAHASHI; YOSHINO; KITAWAKI, 2004). O mo-
delo E possui 20 parmetros de entrada que representam o terminal, a rede e fatores de
qualidade do ambiente. O resultado do clculo dos 20 parmetros chamado de fator R.
Inicialmente, os graus de degradao de qualidade devido a fatores tais como eco, atraso e
distoro, so calculados e diminudos do valor de referncia. A degradao da qualidade
introduzida pelos codecs e perdas de pacotes so tratadas como um fator de degradao
de equipamento (equipment impairment factor).
A recomendao G.107 fornece um conjunto de valores padro, os quais podem ser
usados quando assumido que os terminais e o uso do ambiente de rede so padres
(TAKAHASHI; YOSHINO; KITAWAKI, 2004).
O modelo E avalia o desempenho dos efeitos das variaes de parmetros de trans-
misso que afetam a qualidade de conversao em telefonia de banda estreita. O princpio
do modelo E baseado em pressupostos de que os prejuzos de uma transmisso podem
ser transformados em elementos matemticos. A principal sada do modelo E o fator de
transmisso R:
R = Ro Is Id Ie + A (1)
Onde:
Ro representa a razo entre sinal-rudo;
Is representa os prejuzos simultneos ocorridos com o sinal de voz;
Id representa os prejuzos causados por atrasos;
Ie representa os prejuzos causados na compresso dos codecs;
O fator de vantagem A pode ser usado para compensao quando existem outras
vantagens de acesso para o usurio, por exemplo mobilidade.
67
O resultado nal do cmputo dos fatores de perda um fator escalar R, que varia de 0
(pior caso) a 100 (excelente). O fator R pode ser convertido para escala de pontuao
MOS atravs da seguinte expresso de terceiro grau (ITU-T, 2003):
MOS =
1 R < 0
1 + 0.035R + R(R 60)(100 R).7.10
6
0 < R < 100 (2)
4.5 R > 100.
Normalmente, o fator R descrito em categorias de valores. Sistemas cujo a qualidade
da fala seja avaliada em R=60 no so recomendveis (LUSTOSA et al., 2004), sendo
desejvel obter valores acima de R=70.
As principais vantagens do Modelo E, em relao aos outros mtodos de medio de
qualidade de voz so a capacidade de medio em tempo real, j que no h necessidade
de comparao entre os sinais de referncia e degradado, e a contabilizao em separado
de cada um dos fatores responsveis pela degradao da qualidade da voz, como perdas,
atraso m-a-m, distores inerentes a codicadores de alta compresso, entre outros.
Estas funcionalidades permitem a avaliao da origem e do grau de inuncia de cada
um destes fatores separadamente, tornando o diagnstico de problemas de transmisso
mais precisos. Em (COLE; ROSENBLUTH, 2001), foi proposta uma simplicao para
a frmula do modelo E usando valores padro para o clculo do fator R. Foram utilizados
valores padro para os parmetros que no esto relacionados diretamente com o trans-
porte atravs de pacotes, eliminando o fator de vantagem. Em (LUSTOSA et al., 2004) e
(LUSTOSA, 2005) so discutidas extenses para o modelo E, tal como o efeito da perda
de pacotes em rajadas.
68
4 PLANEJAMENTO DE CAPACIDADE EM REDES PARA
SERVIOS VOIP
O planejamento de capacidade da rede de suma importncia para atingir os nveis de
QoS necessrios para as aplicaes funcionarem de forma eciente. Os recursos de rede
so nitos e custosos, portanto deve-se fazer o planejamento de capacidade da rede para
se obter os nveis de QoS necessrios para as aplicaes, com o menor custo possvel.
Em servios VoIP, para se obter uma boa qualidade das ligaes deve-se manter os fatores
de QoS dentro dos valores esperados. Para alcanar este objetivo, deve-se otimizar ao
mximo o uso dos recursos de rede, determinando a demanda dos servios e a capacidade
dos recursos existentes.
Este captulo apresenta uma viso geral do planejamento de capacidade em redes, os
mtodos utilizados em redes telefnicas convencionais e uma metodologia para adaptao
dos mtodos tradicionais de planejamento de capacidade de rede para os servios VoIP
em uma rede corporativa.
4.1 Planejamento de Capacidade em Redes
Devido ao comprometimento com a qualidade dos servios transportados e limita-
o fsica dos recursos, como a capacidade de transmisso dos enlaces, as redes possuem
um ponto utuante de saturao dos recursos. Neste estado de saturao, a rede impede
o ingresso de novos servios ou comea a sofrer queda de desempenho devido a con-
gestionamentos. O ponto de saturao utuante, pois depende de fatores externos
congurao dos recursos da rede. Os trs fatores externos so a quantidade de trfego,
os requisitos de desempenho e a topologia de conexes. A combinao desses fatores
especica a carga de servio que submetida rede.
A carga de servios distinta aplicada sobre determinada rede resulta em diferentes
quantidades possveis de atendimento a servios. Portanto, o projeto de uma rede deve
considerar a carga de servio fundamental para o dimensionamento dos recursos da rede.
Procurando sempre identicar os fatores externos com o maior detalhamento possvel
para adequar a rede aos servios previstos.
Outros fatores que inuenciam na capacidade de atendimento da rede so os fatores
internos referentes congurao da rede. Parte desses so os diferentes recursos que
podem ser reunidos na congurao fsica da rede, como capacidade dos enlaces, capaci-
dade de comutao, quantidade de buffers, topologia de enlaces e outros. So intrnsecos
aos equipamentos utilizados ou caracterizam uma soluo de congurao adotada para
a rede. A outra parte dos fatores internos so referentes congurao lgica dos meca-
nismos adotados para o controle de trfego. Novamente, combinando valores para estes
69
fatores, tm-se modicaes na capacidade da rede. Enquanto os fatores externos conso-
mem recursos, os fatores internos os disponibilizam. O levantamento desses fatores e a
avaliao de equilbrio entre eles o incio da garantia de sucesso do projeto de uma rede.
Superada a etapa de levantamento e qualicao dos tipos de trfegos a serem suporta-
dos, resta avaliar o impacto desta carga sobre a estrutura de recursos da rede. Sendo os re-
cursos limitados, a rede possui um ponto de saturao que depende de suas caractersticas
e tcnicas utilizadas para atender os servios demandados. Partindo de uma determinada
carga de servio, o comportamento de desempenho da rede depende exclusivamente das
caractersticas dos fatores internos fsicos e de controle. O conjunto de caractersticas f-
sicas envolve, entre outros elementos, topologia de rede, taxa de transmisso dos enlaces,
capacidade de comutao e quantidade de memria. So recursos limitados geralmente
pelo custo ou inviabilidade tcnica, porm quanto maior for o nmero de recursos, melhor
ser o desempenho da rede. Os elementos de controle so representados por algoritmos
que implementamos mecanismos de gerenciamento de trfego, tais como admisso de co-
nexes e tratamento de congestionamento. Os fatores de controle so fundamentais e as
suas conguraes determinam as caractersticas de utilizao da rede. Aperfeioamentos
dos elementos de controle otimizam a utilizao dos recursos fsicos e conseqentemente
aumentam a capacidade de servio suportada pela rede.
Como qualquer outro sistema, as redes de comunicao tm medidas de desempenho
para avaliar sua ecincia. As questes referentes a desempenho so importantes pois in-
uenciam diretamente na quantidade e na qualidade dos servios prestados. Tem-se como
exemplo a largura de banda (vazo) que restringe a quantidade de bits que so transferidos
por segundo em um meio fsico. Se um usurio ou um grupo de usurios demandar um
desempenho de largura de banda superior disponvel, ocorrer uma conteno e en-
leiramento para utilizao do meio fsico, impactando a vazo de informao pretendida
pelo usurio. Os recursos de rede disponibilizados de forma compartilhada so aloca-
dos temporariamente pelos usurios. Aps a utilizao, o recurso liberado, tornando-o
disponvel para outro usurio. A quantidade mxima de usurios atendidos simultanea-
mente dada pela quantidade de recursos da rede. Ultrapassando este limite haver um
congestionamento e o usurio dever aguardar a liberao do recurso para estabelecer
a comunicao, ou seja, haver perda de qualidade de servio (disponibilidade). Como
existe a alternncia de usurios utilizando a rede, o compartilhamento disponibiliza o ser-
vio de comunicao para uma quantidade maior de usurios. Desta forma, aproveita-se
melhor a estrutura da rede reduzindo o custo por usurio.
Os recursos utilizados em uma rede de comunicao so limitados e, por questes de
viabilidade, compartilhados pelos usurios. Como citado anteriormente, recursos limita-
dos signicam uma capacidade de atendimento restrita de usurios. A capacidade est
relacionada com a quantidade de recursos alocados por usurio. As exigncias de quali-
dade do servio determinam a quantidade necessria e a forma de alocao dos recursos.
Portanto, qualidade de servio e capacidade de atendimento esto inter-relacionados. O
aumento da exigncia de qualidade impacta na capacidade de oferecer servio, e vice-
versa. O ideal buscar o equilbrio entre garantir a qualidade dos servios e maximizar
a utilizao dos recursos da rede. A tecnologia adotada na rede dene a relao entre
qualidade de servio e capacidade de atendimento. Nas redes telefnicas, o desempenho
avaliado utilizando parmetros como: tempo para obter sinal para discar, tempo para
estabelecer a ligao, disponibilidade de troncos, qualidade da voz e conabilidade da li-
gao. Estes parmetros determinam a qualidade de servio (QoS) prestado, denominado
como grade de servio (GoS), j abordado no captulo 2.
70
Em resumo, uma rede prov a habilidade de transmitir informaes entre usurios,
com o objetivo de prover um servio efetivo a custos razoveis. No eciente manter
recursos permanentemente dedicados aos usurios. Existe a necessidade de compartilhar
e prover aos usurios meios de acessar estes recursos quando requisitados. Uma rede
composta por elementos fsicos (switches, equipamentos terminais, enlaces de transmis-
so), cada qual com sua capacidade nita de transmisso de informaes. Se a capacidade
no adequada para suportar a carga de servios demandada pelos usurios, o desempe-
nho da rede em transmitir as informaes ser prejudicado. Existe uma relao de de-
pendncia entre carga, capacidade e desempenho de uma rede (gura 4.1). A carga a
quantidade de trfego a ser carregada na rede. A capacidade da rede dada pelos recursos
que a constituem. E o desempenho representa a qualidade de servio oferecida pela rede
aos usurios.
Figura 4.1: Relao entre capacidade, trfego e desempenho.
Alteraes em qualquer um destes trs elementos inuenciam o comportamento dos
outros dois. Pode-se xar um elemento em determinada quantidade para avaliar o com-
portamento dos outros dois elementos entre si. Por exemplo, pode-se xar a capacidade
(quantidade de recursos) de uma rede de comunicao. Aumentando continuamente a
quantidade de carga (trfego) sobre a rede, ser atingido em determinado momento o
esgotamento dos recursos ocasionando a reduo no desempenho da rede percebido em
questes de tempo de resposta, congestionamento e indisponibilidade do servio. Os
usurios percebem e avaliam os servios de rede atravs dos nveis de servio. Associado
ao nvel de servio est o custo a ser pago pelo usurio. Portanto, de comum acordo com
os usurios, a instalao deve denir quais so os nveis de servio desejveis e quais so
intolerveis. Exemplos de outros procedimentos que utilizam este relacionamento so:
Dimensionamento de recursos: para especicar a capacidade requerida da rede
necessrio avaliar a carga demandada e os nveis de desempenho esperados;
Avaliao de desempenho: para determinar o desempenho da rede medido o com-
portamento da carga sobre determinada capacidade de rede. Analisar o desempenho
de um particular projeto de rede tem como nfase variar o trfego e medir o desem-
penho para dada capacidade de rede;
Admisso de chamadas: para determinar a carga suportada pela rede avaliado
se a quantidade de recursos disponveis permite alcanar o desempenho desejado.
No caso de VoIP, o acrscimo de mais uma ligao na rede pode comprometer a
qualidade de todas as outras ligaes.
Os usurios, em geral, percebem os servios de informtica atravs do tempo de res-
posta, da disponibilidade do sistema e da facilidade de uso. A ltima est associada ao
71
software utilizado, enquanto as outras duas esto relacionadas ao dimensionamento de
recursos, isto , ao planejamento de capacidade da rede.
O planejamento de capacidade baseado no relacionamento entre estes trs elementos
bsicos: carga (trfego), capacidade (recursos) e desempenho (QoS).
4.1.1 Fases do Planejamento de Capacidade
Um sistema de computao atende s solicitaes dos usurios com um certo de-
sempenho, que pode ser denido quantitativamente atravs de vrias medidas, como por
exemplo, tempo de resposta, taxa de processamento, ndice de disponibilidade, e outros.
O desempenho de um sistema de computao resulta da interao da carga de trabalho
com os recursos que compem o sistema. A capacidade de um sistema de computao
denida como sendo a carga de trabalho que o sistema pode processar , sem ultrapassar
os limites de desempenho estabelecidos pelos nveis de servio da instalao (GONCAL-
VES, 2000). O planejamento de capacidade um processo para determinar, no tempo
preciso, a quantidade adequada de recursos para atender a carga de trabalho dentro de
nveis de servios propostos.
O processo de planejamento de capacidade para congurao de uma rede pode ser
decomposto em quatro fases (gura 4.2):
Caracterizao da carga de trabalho;
Denio dos nveis de servio (QoS);
Previso de desempenho sobre os recursos disponveis;
Se necessrio, adequao dos recursos.
O processo de dimensionar os recursos de uma rede consiste em utilizar tcnicas que
permitam prever o desempenho desse sistema frente a novas situaes de carga e servios.
Uma vez de posse das estimativas de cargas e dos nveis de servio desejveis, deve-se
estimar quando as demandas por recursos excedero a capacidade instalada da rede. O
ponto de exausto do sistema ocorrer quando, em funo das demandas previstas, o
nvel de servio for considerado insatisfatrio. A fase de previso de desempenho deve
relacionar o impacto da carga prevista sobre os nveis de servios e a utilizao corrente
dos recursos. A questo nal do planejamento de capacidade estimar o ponto em que
a demanda de recursos exceder a capacidade instalada de recursos. O processo requer
uma ferramenta para a previso de desempenho. A avaliao de um sistema pode ser a
combinao de diversas medidas de desempenho alcanadas durante a realizao de suas
atividades. Mtodos para a avaliao de desempenho esto divididos em duas categorias:
tcnicas de medio e tcnicas de previso.
As tcnicas de medio so utilizadas quando possvel fazer medies sobre a rede
nas condies de trfego que se deseja. A tcnica de medio requer que redes reais se-
jam avaliadas por experimentao. A vantagem da medio direta da rede que nenhum
detalhe da rede excludo: a real utilizao da rede est sendo monitorada e medida.
Existem inconvenientes no caso de redes em produo, onde no possvel interromper
os servios para fazer experimentos de carga . Portanto, a rede no pode ser exercitada no
seu limite de carga sem impactar em queda de desempenho para os usurios que a esto
utilizando. Neste caso, o tipo de trfego usual disponvel restringe as condies de expe-
rimento da rede. Em situaes de projeto de rede, onde se deseja avaliar o desempenho
72
Figura 4.2: Fases do Planejamento de Capacidade de Rede.
da futura rede ou em situaes futuras de trfego, as tcnicas de medio real no so
possveis. Isto acontece porque a rede no est implementada ou porque a carga ainda
no existe para ser avaliada. Utilizam-se ento tcnicas de previso que podem ser por
modelo analticos ou simulados. Comparando modelo analtico e simulao, os princi-
pais fatores a considerar so a preciso dos resultados, o tempo para obt-los e o custo
de utilizar o mtodo. A vantagem das solues analticas que elas podem ser usadas de
forma razoavelmente rpida. Entretanto, a necessidade para resolver o modelo restringe
a abrangncia do sistema ou as caractersticas de trfego que podem ser includas. Por-
tanto a soluo analtica utilizada com freqncia para produzir uma aproximao de
um sistema, com resultados sendo produzidos de forma relativamente rpida e barata.
As redes de maior complexidade podem ser investigadas usando simulao. Sistemas
podem ser modelados no nvel de preciso desejado permitindo analisar as alternativas de
congurao, levando-se em conta os aspectos de custos, as consideraes de conabili-
dade, a carga projetada e os nveis de servio. Muitas vezes a simulao o mtodo mais
adequado devido natureza do problema e porque tcnicas analticas tornam-se muito di-
fceis de serem tratadas. Entretanto simulao pode ter um alto custo para desenvolver e
executar. Simulaes de eventos raros, tais como perda de pacotes em redes locais, podem
consumir um tempo considervel de execuo do simulador (GONCALVES, 2000).
4.2 Mtodos de Planejamento de Capacidade em Telefonia Conven-
cional
4.2.1 Breve Histrico
Os mtodos modernos para otimizao de redes telefnicas tm as suas razes no tra-
balho feito por Agner Krarup Erlang (1878-1929), um cientista dinamarqus que ingres-
sou na companhia telefnica Copenhagen Telephone Company em 1908 (gura 4.3). Ele
iniciou a soluo do problema chave no projeto de uma rede telefnica: quantos troncos
so necessrios para transportar um determinado volume de ligaes?
Por exemplo, em um pequeno vilarejo onde cada casa tem um telefone conectado a
uma central local. Quantos troncos a companhia telefnica deveria instalar entre a central
73
Figura 4.3: A.K. Erlang (MILLENNIUM MATHEMATICS PROJECT, 1997).
local e a central do prximo vilarejo? Erlang observou que no existia uma resposta
nica para o problema. Em vez disto, existia sempre um balanceamento entre servio e
custo. No caso do vilarejo, existiam duas opes extremas, sendo que nenhuma delas era
aceitvel:
Disponibilizar somente um tronco, e deixar os usurios esperando at o tronco car
disponvel. O custo seria baixo, mas disponibilidade do servio seria inaceitvel.
Disponibilizar um tronco para cada linha de usurio local, tornando a disponibili-
dade do servio extremamente alta. O servio seria excelente, mas o custo tornaria
esta soluo improvvel.
O problema consistia em converter em nmeros o balanceamento entre custo e servio
de forma a permitir que os projetistas de rede pudessem avaliar as melhores possibilida-
des. Para isto, Erlang conduziu os primeiros estudos sobre trfego telefnico, e desen-
volveu metdos matemticos para avaliar o balanceamento de servio e custo. Sua maior
descoberta foi provar que a distribuio das chamadas seguia o modelo de distribuio de
Poisson (BROCKMEYER; HALSTRM; JENSEN, 1948). O trabalho teve repercusso
mundial, ao ponto de um cientista dos laboratrios Bell Labs aprender o idioma dina-
marqus para ler os artigos de Erlang no formato original (MILLENNIUM MATHEMA-
TICS PROJECT, 1997). Em 1946, o CCITT (International Consultative Committee on
Telephones and Telegraphs) adotou o nome de erlang para a unidade bsica de trfego
telefnico em homenagem ao cientista.
4.2.2 Mtodos de Erlang
4.2.2.1 Conceitos Bsicos
At recentemente, para se utilizar as tcnicas de teletrfego era necessrio ter um bom
embasamento matemtico ou aprender a usar livros de tabelas com valores previamente
calculados. Com a disseminao dos computadores pessoais e Internet, surgiram pro-
gramas especcos para os clculos e disponveis para utilizao, em pginas como (ER-
LANG.COM, 2005), (ICT, 2005) e (ERLANG.CO.UK, 2005), facilitando as aplicaes
74
das frmulas. Os parmetros que sero aplicados s frmulas deniro a ecincia do pla-
nejamento de capacidade da rede. Para poder aplicar os mtodos de Erlang necessrio
que alguns conceitos bsicos sejam observados, tais como:
Erlang: a unidade bsica de intensidade de teletrfego. A intensidade de trfego
denida como o nmero de recursos ocupados em um conjunto, em um dado
instante. O conjunto de recursos pode ser um grupo de servidores ou troncos.
Um erlang uma unidade sem dimenso, representando o uso contnuo de um cir-
cuito (tronco). Entretanto, j que um nico circuito usado continuamente transporta
60 minutos de chamadas em uma hora, um erlang usualmente denido como
sendo 60 minutos de trfego. Por exemplo, se forem recebidas 300 ligaes de 2
minutos de durao durante uma hora, foram recebidos 600 minutos, ou 10 erlangs
de trfego naquela hora. Nos EUA e Canad a medio de trfego feita em CCS
(Centil Call Seconds) ou 100 segundos de conversao telefnica. Para se converter
os valores em CCS para erlangs basta dividir por 36.
Tipos de trfego:
Trfego Efetivamente Utilizado (Carried Trafc): corresponde ao trfego ser-
vido aos usurios do servio. O Trfego Oferecido (Offered Trafc) corresponde
real demanda de trfego do sistema. Quanto maior for a porcentagem de bloqueio
(GoS), maior ser a diferena entre os dois tipos de trfego. A diferena entre os
dois tipos de trfego est demonstrada na frmula:
T
eu
=
T
o
1 GoS
(3)
Onde:
T
eu
= trfego efetivamente utilizado
T
o
= trfego oferecido
GoS = fator de bloqueio
Trfego Oferecido - em modelos tericos, o conceito de trfego oferecido
usado. Este o trfego que seria transportado se nenhuma das ligaes fosse rejei-
tada por falta de capacidade da rede (a capacidade da rede seria innita). O trfego
oferecido um valor hipottico e no pode ser medido (IVERSEN et al., 2005).
Ele pode ser estimado atravs da frmula 4, equivalente intensidade de trfego
e medido em erlangs.
T
o
= .s (4)
Onde:
: corresponde a mdia do nmero de chamadas
s: corresponde ao tempo mdio das chamadas
Exemplo:
Se um grupo de usurios faz 30 chamadas em uma hora, e cada chamada tem o
75
tempo de durao mdio de 5 minutos, ento a intensidade de trfego calculada
da seguinte forma:
Minutos de trfego em uma hora = nmero de chamadas x durao
Minutos de trfego em uma hora = 30 x 5
Minutos de trfego em uma hora = 150
Horas de trfego em uma hora = 150 / 60
Horas de trfego em uma hora = 2.5
Intensidade de trfego = 2.5 erlangs
A intensidade de trfego somente uma medida da utilizao mdia durante um
intervalo de tempo e no reete o relacionamento entre a quantidade e a durao das
chamadas. Portanto, muitas chamadas curtas podem produzir a mesma intensidade
de trfego do que poucas chamadas longas.
Hora de Maior Movimento (Busy Hour): o trfego medido na hora de maior mo-
vimento (HMM) representa a mxima carga de trfego que a rede produz (CISCO,
2001). Quando no for possvel fazer a medio, podem ser feitas estimativas de
quantas chamadas so realizadas por dia. Em um ambiente padro comercial, a hora
de maior movimento do dia corresponde a entre 15 e 20% do total de trfego dirio.
Geralmente, so utilizados nos clculos o valor de 17% do total de trfego dirio
para saber a HMM (CISCO, 2001). Para o tempo de chamada, quando no existe
possibilidade de medio, podem ser utilizados valores entre 180 e 210 segundos
como valor de referncia (CISCO, 2001). Um telefone residencial, tipicamente,
possui trfego na HMM que est entre 0,05 e 0,1 erlangs. Sendo o tempo mdio das
ligaes entre 3 e 4 minutos, ento um telefone residencial realiza de uma a duas
chamadas durante a HMM (CASTRO, 2002).
Servidor: algum dispositivo que manipula as chamadas (troncos, grupos de tron-
cos, linhas). Por exemplo, no caso de um call center existem dois tipos de servido-
res, os troncos que transportam as chamadas e os agentes que atendem as chamadas.
Com o uso de caixa postal de voz (voice mail) ou URA (Unidade de Resposta Au-
dvel) os servidores podem ser considerados como portas.
GoS (Grade of Service) (Grade de Servio): dene a probabilidade de que todos os
servidores estaro ocupados quando uma tentativa de chamada for feita. Por exem-
plo, em um grupo de troncos com GoS de P.02 signica que existe 2% de probabi-
lidade de uma tentativa de chamada receber um sinal de ocupado (ser bloqueada).
Em um call center este mesmo GoS signica dizer que existir uma probabilidade
de 2% de esperar para falar com um atendente.
4.2.3 Frmulas de Teletrfego
Existem muitas frmulas de teletrfego, apropriadas para as mais diferentes situaes.
Cada uma delas se adapta a uma modelo de trfego especco. Os modelos de trfego
telefnico so denidos por (CISCO, 2001):
Padro de Chegada das Chamadas: a considerao mais fundamental da anlise
de trfego clssica que as solicitaes de chamadas so independentes umas das
outras. O fato de assumir a chegada das chamadas como aleatrias prov uma
76
formulao matemtica que pode ser ajustada para produzir solues aproximadas
a problemas que seriam, de outra forma, matematicamente intratveis (CASTRO,
2002). Os padres de chegada de chamadas so:
Pouca variao: no existe grande variao na quantidade de chamadas no de-
correr do tempo.
Picos: existem grandes variaes de quantidade, sendo caracterizado por tr-
fego de exceo, como por exemplo em feriados.
Aleatrio: conhecido como distribuio de Poisson, normalmente observado
em PABXs.
Tipo de Bloqueio das Chamadas: uma chamada bloqueada aquela que no ime-
diatamente servida. Os principais tipos so:
Lost Calls Held (LCH): as chamadas bloqueadas so perdidas, no retornando
novamente.
Lost Calls Cleared (LCC): as chamadas bloqueadas so rejeitadas pela rede.
Lost Calls Delayed (LCD): as chamadas bloqueadas continuamna rede a espera
da disponibilidade do sistema. Normalmente, so utilizadas las de espera at as
chamadas bloqueadas serem atendidas.
Lost Calls Retried (LCR): quando uma chamada bloqueada, uma porcenta-
gem dos usurios faro uma nova tentativa.
Nmero de Origens das Chamadas: se o nmero de fontes de origem for grande e a
sua atividade mdia relativamente baixa, fontes ocupadas no reduzem de forma
aprecivel a taxa de chamadas. Por exemplo, considerando uma central local que
serve a 10000 assinates com 0,1 erlang de atividade cada um. Normalmente, haver
1000 circuitos ativos e 9000 assinantes disponveis para gerar novas chamadas. Se o
nmero de usurios ativos aumentar por um fator de 50%, passando a 1500 circuitos
ativos, o nmero de assinantes inativos reduzido para 8500, uma mudana de
apenas 5%. Portanto, pode-se considerar o nmero de origens como innita, pois a
taxa de chamadas relativamente constante (CASTRO, 2002).
Tempo de Durao das Chamadas: o tempo de durao das chamadas exponen-
cial. Geralmente, as chamadas possuem tempo de durao curtos, ao invs de tem-
pos longos signicando que a distribuio exponencial negativa.
Na tabela 4.1 esto algumas caractersticas dos modelos de trfego mais utilizados em
telefonia (CISCO, 2001):
Tabela 4.1: Modelos de Trfego Telefnico.
Modelo Origem Padro de Chegada Bloqueio Durao
Poisson Innita Aleatria LCH Exponencial
Erlang B Innita Aleatria LCC Exponencial
Extended Erlang B Innita Aleatria LCR Exponencial
Erlang C Innita Aleatria LCD Exponencial
Engset Finita Pouca Variao LCC Exponencial
77
As frmulas s funcionam, com ecincia, se existirem um grande nmero de origens
independentes de trfego. Por exemplo, se 10 usurios zerem chamadas externas, sem
recebimento de chamadas entrantes, nunca sero necessrios mais do de 10 troncos, no
importando o resultado do clculo da frmula. Matematicamente, estas frmulas necessi-
tam de fontes innitas, mas na prtica elas funcionam bem se existirem, pelo menos, 10
vezes mais origens (usurios) do que servidores (troncos e agentes) (ANGUS, 2002).
A frmula mais amplamente adotada em clculo de planejamento de teletrfego a
de Erlang B. Embora nos EUA, seja usada a frmula de Poisson, que retorna valores
semelhantes a frmula de Erlang B (ANGUS, 2002);(CISCO, 2001).
4.2.4 Frmula de Erlang B
A frmula de Erlang B utilizada quando uma chamada bloqueada realmente blo-
queada, por exemplo, quando algum liga para uma linha telefnica e recebe o sinal de
ocupado ou tenta acessar um tronco e o encontra em uso. A frmula composta de trs
variveis: servidores (linhas), intensidade de trfego e GoS. Se duas variveis forem co-
nhecidas possvel calcular a outra varivel. Para facilitar a busca dos resultados, existem
tabelas prontas com a relao da taxa de bloqueio, intensidade de trfego e nmero de li-
nhas. Na gura 4.4, um exemplo da tabela (BROCKMEYER; HALSTRM; JENSEN,
1948).
Figura 4.4: Parte de uma tabela de Erlang.
A frmula de Erlang B pode ser utilizada em grupos de troncos primrios, onde no
levado em conta o nmero de repeties, porque os usurios so repassadas para ou-
tro grupo de troncos, ou quando esperado uma taxa muito baixa de bloqueios (CISCO,
2001). No caso de PABXs, normalmente, a taxa de bloqueio muito baixa, sendo aplic-
vel a frmula de Erlang B.
A frmula de Erlang B a seguinte:
B(c, a) =
a
c
c!
c
k=0
a
k
k!
(5)
Onde:
B(c,a) a probabilidade de bloqueio de uma chamada
78
c o nmero de circuitos
a a intensidade de trfego (em erlangs)
So 4 etapas necessrias para a coleta de parmetros a serem aplicados na frmula de
Erlang B. As etapas so as seguintes:
1. Coletar o trfego telefnico: necessrio saber quanto trfego ser submetido para
o grupo de troncos, a cada hora, por pelo menos 5 ou 10 dias teis. possvel
utilizar contas telefnicas, relatrios detalhados das chamadas gerados pelo PABX,
estudos da empresa de telefonia e at mesmo contagem manual, ou fazer suposi-
es baseadas em alguns fatores conhecidos da natureza do trfego telefnico. O
objetivo produzir uma planilha contendo o nmero de chamadas e mostrando a
quantidade de minutos utilizados em chamadas em cada hora. Com estes dados,
ser possvel calcular o trfego oferecido.
importante ressaltar que o trfego nos troncos pode ser bem maior do que o tempo
real de conversao, pois o tempo de uso para chamadas externas e para as chama-
das entrantes podem usar os mesmos troncos.
2. Determinar a hora de maior movimento (HMM) (Average Busy Hour (ABH)): ana-
lisar os registros de PABX ou estimar a intensidade de trfego mdio mais alto
durante dias teis. importante utilizar um perodo que represente o trfego mdio
anual de telefonia.
3. Denir um fator de GoS: na maioria dos casos, um fator de P.05 aceitvel, P.10
ruim e P.001 to bom que a maioria dos usurios nunca receberiam um sinal de
ocupado. O padro de GoS denido pela Anatel P.05 ou menor, para telefonia
comercial xa (ANATEL, 2005).
4. Aplicar a frmula: calcular o nmero de troncos necessrios para transportar a
quantidade de trfego dentro do fator de GoS determinado. Neste clculo pre-
ciso denir qual resultado satisfatrio. Normalmente, o resultado satisfatrio vai
depender do que se dispe para investir em troncos. Se no existir condies nan-
ceira para arcar com o custo, pode-se diminuir o nmero de troncos aumentando a
taxa de GoS havendo assim, diminuio da qualidade do servio.
Para o entendimento de planejamento de capacidade em sistemas telefnicos impor-
tante o conhecimento dos mtodos de Erlang. Entretanto, o levantamento dos parmetros
a serem aplicados s frmulas devem ser corretos para o resultado ser eciente. Alm
disso, as frmulas fazem simplicaes da realidade, tal como a frmula de Erlang B
que assume que os usurios que receberem sinal de ocupado no tentaro imediatamente
uma nova ligao. Todas as frmulas de teletrfego calculam probabilidades, no valores
absolutos. Os resultados prevm o que ir acontecer, em mdia, durante horas de trfego
similar. As horas com trfego de exceo, no sero representadas integralmente nos re-
sultados das frmulas (ANGUS, 2002). Estas excees podem ocorrer em feriados, como
no dia das mes, ou emergncias em grande escala.
4.2.5 Metodologia
Na gura 4.5, est o uxograma da metodologia necessria para o planejamento da
capacidade de rede telefnica convencional.
79
Figura 4.5: Metodologia para o planejamento de capacidade da rede telefnica convenci-
onal.
4.3 Aplicao da Metodologia
4.3.1 Coleta de Trfego Telefnico
Para fazer o levantamento da demanda de trfego telefnico necessrio conhecer o
comportamento dos usurios e a natureza do negcio da instituio. Por exemplo, em caso
de uma empresa com vrias liais espalhadas geogracamente, a tendncia que hajam
chamadas entre a matriz e as liais e liais com liais. Os dados do histrico de ligaes
pode ser obtido atravs dos registros do PABX local ou de um conta telefnica detalhada.
Entretanto, para se obter o registro das ligaes internas, ramal para ramal, somente os
registros do PABX local podem mostrar isto. Este tipo de medio no comumente mo-
nitorado em empresas por ter um alto volume de dados, o que diculta o armazenamento
e o processamento nos PABXs. A diculdade se encontra no custo elevado de disposi-
tivos de armazenamento para os PABXs, que possuem padres fechados ou devem ser
homologados pela empresa fabricante. Na falta de um registro mais detalhado, podem-se
fazer estimativas baseadas nos valores padro para chamadas telefnicas comerciais.
Para se obter o tempo de durao das chamadas, pode-se dividir o nmero de ligaes
pelo tempo total das chamadas. Caso no haja a possibilidade de obter esses dados, o valor
usado como padro emdurao de chamadas comerciais locais entre 180 e 210 segundos
(CISCO, 2001). Em medies realizadas no Campus do Vale da UFRGS, os valores
caram bem prximos do padro, cerca de 204s em mdia, para ligaes locais, nacionais
e internacionais. Em medies de ligaes entre ramais feitas na rea administrativa da
UCPel (Universidade Catlica de Pelotas) o tempo de durao das chamadas foi de 54s
em mdia.
Estes dados foram obtidos dos PABXs das instituies atravs de arquivos de registros
(CDR - Calls Details Records) fornecidos pelo software tarifador Informatec da empresa
STI (STI, 2005) em PABXs do fabricante Ericsson. A ltragem dos arquivos foi feita uti-
lizando as ferramentas grep, sort e uniq rodando no ambiente Cygwin (CYGWIN, 2005)
e o Microsoft Excel. Abaixo, um trecho do arquivo de registro do PABX da UCPel, repre-
80
sentando as chamadas feitas pelo ramal 8015:
Ramal:8015 Nome:NUCLEO CIDADANIA
8015 0 30/06/2005 10:29 INT 8220 Interna 00:00:12
8015 0 30/06/2005 10:31 INT 8206 Interna 00:00:30
8015 0 30/06/2005 10:34 INT 8245 Interna 00:01:06
8015 0 30/06/2005 11:15 INT 8249 Interna 00:00:42
8015 0 30/06/2005 13:43 INT 8258 Interna 00:01:06
8015 0 30/06/2005 13:50 INT 8217 Interna 00:01:00
Os registros apresentam o ramal originador, a data, a hora, a natureza da ligao (INT
- Interna), o ramal destino e o tempo da ligao.
Na tabela 4.2, esto resumidos os registros coletados dos PABXs das instituies.
Tabela 4.2: Levantamento de trfego telefnico UCPel e UFRGS (Campus do Vale).
Resumo UCPel UFRGS (Cam-
pus do Vale)
Perodo da Coleta 13/06/2005 a
13/07/2005
01/05/2005 a
31/05/2005
Origem Interna (Ramal-
Ramal)
Externa (Local,
DDD e DDI)
Nmero de Ramais 149 2400
Perodos de Maior Movimento
(PMM)
08hs s 11hs e
14hs s 17hs
09hs s 12hs e
14hs s 17hs
Hora de Maior Movimento (HMM) 14hs s 15hs 10hs s 11hs
Mdia de durao das chamadas 0:54s 03:24min
Chamadas total (perodo) 29826 187717
Chamadas total (perodo, sem ns
de semana)
29762 183295
Chamadas total (PMM) 25650,36 150173,6
Chamadas total (HMM) 4130 9952,68
Dias teis do perodo 23 21
Horas teis do perodo 7hs s 23hs 7hs s 23hs
Chamadas por ramal total (perodo) 199,74 76,37
Chamadas por ramal por hora (pe-
rodo)
0,54 0,23
Chamadas por ramal por hora
(PMM)
0,94 0,37
Chamadas por ramal por hora
(HMM)
1,21 0,19
Concentrao de chamadas (PMM) 86% 80%
Concentrao de chamadas (HMM) 16,1% 6,63%
4.3.2 Clculo da Hora de Maior Movimento
Para realizar o clculo da hora de maior movimento necessrio identicar os pero-
dos com o maior nmero de chamadas durante o dia. Devido natureza do negcio das
duas instituies (universidades) o perodo utilizado para o clculo da HMM foi entre 7hs
e 23hs. As ligaes que foram geradas fora deste perodo representaram menos de 0,3%
do total de ligaes.
As horas de maior movimento so importantes para denir os valores mximos de
trfego. No caso da UCPel, os perodos de maior movimento foram na parte da manh
81
das 8hs as 11hs e na parte da tarde das 14hs as 17hs, sendo a tera-feira o dia de maior
movimento. Houve uma concentrao de 86% das chamadas nesses perodos. A hora
de maior movimento foi entre 14hs e 15hs e concentrou 16,1% das ligaes realizadas
no perodo. No Campus do Vale da UFRGS, houve apenas uma variao no perodo da
manh em relao a UCPel, cando das 9hs as 12hs o intervalo de maior movimento. Na
parte da tarde, foi o mesmo da UCPel. O dia de maior movimento foi a tera-feira e as
horas de maior movimento concentraram 80% do total das chamadas do intervalo medido.
A hora de maior movimento foi entre 10hs e 11hs e concentrou 6,63% das ligaes.
Outro fator importante a intensidade do trfego. O nmero de ligaes geradas
por cada ramal um dos fatores principais para o clculo de intensidade de trfego. No
monitoramento feito no Campus do Vale da UFRGS a intensidade de trfego por ramal
cou em torno de 0,011 erlangs por ramal na hora de maior movimento. No caso da
UCPel, a intensidade de trfego cou em torno de 0,018 erlangs por ramal.
Para fazer o clculo do nmero de linhas (circuitos) necessrios para absorver o tr-
fego medido, deve-se totalizar a demanda de trfego total. A frmula 6 demonstra o
clculo de intensidade de trfego na HMM da UCPel.
T
HMM
= ((n
chamadas
.t
chamada
)/3600).n
ramais
T
HMM
= ((1, 21.54s)/3600).149 (6)
T
HMM
= 2, 7erlangs
Onde:
T
HMM
- intensidade de trfego na HMM
n
chamadas
- nmero de chamadas realizadas por cada ramal na HMM
t
chamada
- durao mdia das ligaes
n
ramais
- nmero de ramais
Na tabela 4.3, esto os resultados dos clculos de intensidade de trfego no perodo da
coleta de informaes, nos perodos de maior movimento e na hora de maior movimento.
Tabela 4.3: Intensidade do trfego telefnico na UCPel e na UFRGS.
Resumo UCPel UFRGS (Campus do
Vale)
Intensidade de trfego por ramal (pe-
rodo)
0,0081e 0,013e
Intensidade de trfego por ramal (PMM) 0,0141e 0,0209e
Intensidade de trfego por ramal (HMM) 0,018e 0,011e
Intensidade de trfego total (perodo) 2,69e 31,2e
Intensidade de trfego total (PMM) 2,09e 120e
Intensidade de trfego total (HMM) 2,7e 26,4e
4.3.3 Denio do GoS
A denio do GoS baseada na qualidade desejada para o servio de telefonia. O
GoS pode ser medido atravs da porcentagem de ligaes que sofreram bloqueios pela
rede, devido a todas as linhas estarem ocupadas, em relao s ligaes realizadas com
sucesso. Os registros podem ser coletados dos arquivos de registro dos PABXs. Como
82
padro, den-se o GoS com P.01, ou seja, 1% de probabilidade de bloqueio (COLLINS,
2003).
4.3.4 Aplicao da frmula de Erlang B
A frmula de Erlang B necessita de pelo menos dois parmetros para determinar o
terceiro. A intensidade de trfego j foi determinada e o GoS tambm. Basta agora
aplicar a frmula para obter-se o nmero de linhas necessrias para o trfego telefnico.
A aplicao da frmula simplicada pelo uso de tabelas com valores j calculados.
Por ser uma frmula com recursividade a sua resoluo bastante complexa. Portanto,
existem algoritmos que permitem a resoluo do clculo. Um dos algoritmos que est em
formato de uma macro para o Microsoft Excel, CircuitErlB, est listado abaixo:
Public Function CircuitErlB(Aoffered, Pblock As Double) As Long
Dim Ion As Double
Dim m, Flag As Long
Flag = 0
Ion = 1
m = 1 Contador do nmero de linhas
Se o trfego ou a probabilidade for menor que zero, seta em 0
If (Aoffered <= 0) Or (Pblock <= 0) Then
Flag = 1
m = 0
End If
Mximo de 20 milhes de linhas
While (m < 20000000) And (Flag = 0)
Ion = 1 / (1 + (m / (Ion
*
Aoffered)))
If (Ion <= Pblock) Then
Flag = 1
Else
m = m + 1
End If
Wend
CircuitErlB = m Retorna o nmero de circuitos
End Function
Os parmetros da macro so o GoS e o trfego da HMM em Erlangs, sendo o resultado
o nmero de troncos (servidores). A utilizao da macro a seguinte:
CircuitErlB(trfego HMM em erlangs;GOS)
CircuitErlB(2,7;0,01)
CircuitErlB=8 linhas
Na gura 4.6, est ilustrada a utilizao da tabela de Erlang, para os mesmos parme-
tros. Observa-se que a aproximao feita para cima, utilizando o nmero de circuitos
para uma intensidade de trfego de 3,13e, maior que o valor calculado anteriormente de
2,7e.
Portanto, 8 linhas suportariam a intensidade de trfego telefnico gerado por 149 ra-
mais na hora de maior movimento na UCPel.
4.4 Metodologia Adaptada para VoIP
A partir do levantamento do trfego telefnico, possvel fazer o clculo da largura de
banda necessria para absorver os servios de VoIP. Para isto, devem ser denidos os tipos
de codecs a serem utilizados, a quantidade de amostras por pacotes, utilizao ou no de
supresso de silncio e compresso de cabealhos. Com isto, ser possvel elaborar uma
metodologia para adaptar o planejamento de capacidade de rede da telefonia convencional
para os servios VoIP.
83
Figura 4.6: Tabela de Erlang para GoS 0,01 e HMM 2,7e.
4.4.1 Tipo de Codec
Para fazer o clculo da largura de banda necessria para cada ligao, o tipo de codec
a ser utilizado deve ser denido. Alm do consumo de largura de banda, o tipo de codec
inuencia diretamente na qualidade da voz. Em uma rede corporativa, aconselhvel a
utilizao do codec G.711 (WALLINGFORD, 2005). Em casos de enlaces com pouca
largura de banda disponvel, aconselhvel a utilizao de codecs com menos consumo
de banda, tais como GSM ou Speex, ou a compresso de cabealhos RTP. Para fazer o
clculo, foram medidas as larguras de banda utilizadas pelos principais codecs gratuitos
atravs do softphone Xlite da empresa Counterpath (COUNTERPATH, 2005) registrado
em um proxy SIP Asterisk. Este softphone tem disponveis os codecs G.711, GSM, iLBC
e Speex. Foi medida a largura de banda de cada codec, fazendo a captura do trfego
utilizando o software Ethereal (ETHEREAL: A NETWORK PROTOCOL ANALYZER,
2005), em uma rede padro ethernet conforme a gura 4.7.
Figura 4.7: Diagrama da rede da captura com o Ethereal.
O consumo de largura de banda de cada codec pode ser calculado somando os cabe-
alhos e a carga til por pacote e multiplicando pelo nmero de pacotes por segundo. Na
gura 4.8, o exemplo do clculo para o codec G.711 com carga til de 160 bytes (duas
amostras de voz por pacote).
O clculo de consumo de largura de banda e os resultados da medio e dos clculos
esto na tabela 4.4.
Os valores da tabela 4.4 correspondem a um sentido da chamada, por exemplo do
84
Figura 4.8: Clculo da largura de banda do codec G.711.
Tabela 4.4: Valores medidos e calculados dos codecs.
Codec Banda Medida (kbits) Banda Calculada (kbits)
G.711 81,6 95,2
GSM 29,7 44,2
iLBC 24,4 34,13
Speex 35,9 39,2
usurio chamado para o chamador. Portanto, a largura de banda consumida igual a duas
vezes o valor medido. A variao ocorrida no clculo devido forma como feita a
captura no software Ethereal em relao aos quadros ethernet. Na captura, so considera-
dos apenas 14 bytes para os cabealhos dos quadros (ETHEREAL: WIKI, 2005). No so
considerados no clculo os 4 bytes do campo FCS (Frame Check Sequence) que contm o
valor do CRC (Cyclic Redundancy Check), os 8 bytes do prembulo e os 12 bytes do IFG
(InterFrame Gap) correspondente ao intervalo entre os quadros. Ooverhead do cabealho
do quadro ethernet de 38 bytes (SPURGEON, 2000). Para aplicao no planejamento
de capacidade do cenrio exemplo, ser utilizado o pior caso, que o valor calculado.
4.4.2 Amostras por Pacote
A largura de banda utilizada diretamente afetada pelo nmero de amostras de voz
que so transportadas em cada pacote. Devido ao excessivo overhead, aumentando o
nmero de amostras por pacote, aumenta-se a carga til dos pacotes fazendo com que o
overhead diminua (gura 4.9). O aumento do nmero de amostras por pacote faz com que
o atraso, m a m, aumente devido ao tempo de montagem dos pacotes que ir aumentar.
O nmero de amostras por pacote denido nas conguraes dos codecs e pode ser feito
nos terminais ou nos servidores.
A tabela 4.5, mostra a relao entre largura de banda, atraso, overhead e nmero de
amostras de voz por pacote para o codec G.711 em uma rede ethernet.
O atraso e as perdas de pacotes em redes comutadas so mnimos em uma rede local
corporativa, mesmo no utilizando mecanismos de QoS. Portanto pode-se usar a estratgia
de vrias amostras de voz em um mesmo pacote, em LANs.
4.4.3 Supresso de Silncio
Uma conversao telefnica tpica pode conter de 35 a 50% de perodos de silncio
(COLLINS, 2003). Todos os pacotes, inclusive os que contm silncio, so transmitidos
85
Figura 4.9: Overhead dos pacotes de voz (codec G.711).
Tabela 4.5: Largura de banda para quantidade de amostras de voz por pacote (codec
G.711).
Amostras por pacote Largura de Banda (kbits) Atraso (ms) Overhead (%)
1 126,4 10 97,5
2 95,2 20 48,75
3 84,8 30 32,5
4 79,6 40 24,38
consumindo maior largura de banda nas ligaes. Com a utilizao da tcnica de supres-
so de silncio, pode-se estimar ganhos de at 35% na banda consumida (CISCO, 2001).
Alguns codecs, como por exemplo o G.729 Annex-B e o G.723 Annex-A, possuem me-
canismos de supresso de silncio embutidos no prprio codec. A supresso de silncio
pode ser uma funcionalidade dos terminais, sendo ativada opcionalmente, embora a qua-
lidade das ligaes possa car prejudicada, pois podem ocorrer perdas nos recomeos das
conversaes dos usurios que estavam em silncio. Portanto, embora possa haver eco-
nomia de largura de banda a qualidade da conversao pode ser prejudicada utilizando
o mecanismo de supresso de silncio. Em LANs, este mecanismo no recomendado
(WALLINGFORD, 2005).
4.4.4 Compresso de Cabealhos
Em enlaces ponto a ponto, possvel a utilizao de compresso de cabealhos. Desta
forma, a largura de banda necessria para as conversaes diminui bastante, devido ao
alto overhead dos pacotes de voz. Por exemplo, no caso de um enlace utilizando o pro-
tocolo PPP (Point to Point Protocol), sem compresso de cabealhos a largura de banda
utilizando o codec G.711, com duas amostras por pacote, de 82,4kbits. Com o uso de
compresso, a largura de banda seria de 67,2kbits, portanto um ganho de cerca de 18%.
4.5 Recursos de Rede
Para fazer o levantamento de requisitos do planejamento de capacidade em redes cor-
porativas para a absoro de servios VoIP, necessrio seguir uma metodologia. Caso
86
contrrio, podem surgir diversos problemas no processo de implantao do servio. O
levantamento destes requisitos devem ser feitos antes da compra de equipamentos e con-
tratao de servios. Em uma rede corporativa, a maior diculdade de como adaptar os
servios de VoIP nos recursos de rede existentes. Aps fazer o levantamento do trfego
telefnico e a da largura de banda necessria, deve-se avaliar os recursos de rede existen-
tes. Portanto, o trfego da rede, sem os servios de VoIP, deve ser analisado previamente,
tanto para os valores mdios quanto para os valores de pico de trfego. Os perodos de
maior trfego devem ser identicados. Alm disto, os mecanismos de QoS que esto
disponveis na rede devem ser congurados para garantir a qualidade do servio de voz.
4.5.1 Largura de Banda
A largura de banda em redes corporativas, geralmente, excedente para as aplicaes
e servios de rede. Embora possam existir perodos de pico devido a backups, a incidncia
de vrus, leitura de e-mail no incio da manh ou relatrios de nal de ms. Ento, im-
portante mapear os picos e os horrios onde o trfego mais intenso. O trfego existente
na rede, antes da implementao de servios VoIP, pode ser medido nas interfaces dos
switches ou roteadores que possurem o protocolo SNMP (Simple Network Management
Protocol) ou alguma outra forma de gerenciamento. Podem ser usadas nas medies a
ferramenta de cdigo-fonte aberto MRTG (Multi Router Trafc Grapher) (MRTG: THE
MULTI ROUTER TRAFFIC GRAPHER, 2005), que apresenta de forma grca o trfego
de entrada e sada das interfaces (gura 4.10) ou em formato texto atravs de arquivos de
logs.
Figura 4.10: Exemplo de medio de trfego com o MRTG.
Utilizando os arquivos de logs, pode-se ltrar os dias e os horrios atravs de uma
planilha de clculos. Desta forma, torna-se possvel achar os horrios e os dias de maior
movimento. Abaixo, um trecho de um arquivo de log do MRTG.
1138644930 52257 33277 52257 33277
1138644630 12942 27968 12942 27968
1138644600 13272 28617 16138 34253
1138644300 14875 32775 16138 34253
1138644000 5922 21025 23898 30665
O primeiro campo contm o nmero de segundos desde 01/01/1970 (Unix Epoch
Time), o segundo campo mostra a mdia de octetos de entrada na interface, o terceiro
campo mostra a mdia de octetos de sada, o quarto campo mostra o valor mximo (pico)
de entrada nos ltimos cinco minutos e o quinto campo mostra o valor mximo (pico) de
sada nos ltimos cinco minutos na interface monitorada.
87
4.5.2 Mecanismos de QoS
Os equipamentos de rede devem possuir mecanismos de QoS que garantam, ao me-
nos, a priorizao do trfego de voz em relao ao restante do trfego. O padro 802.1p
uma funcionalidade comum nos switches atuais. Os switches mais simples possuem
apenas duas las para diferenciao do trfego, enquanto os switches mais completos e
de maior custo possuem mais las. Os roteadores baseados em Linux e os roteadores
dedicados, tais como os da empresa Cisco, possuem o protocolo DiffServ e mapeamento
entre DSCPs e CoS. Algumas placas de rede atuais possuem drivers que permitem a mar-
cao de quadros atravs do padro 802.1p, mas no so o padro em redes corporativas.
Normalmente, os ATAs e os telefones IP possuem o padro 802.1p para a marcao e
priorizao de quadros em todos os tipos de modelos atuais.
4.5.3 Metodologia Adaptada para VoIP
Na gura 4.11, est representado um diagrama da metodologia para o planejamento
de capacidade de rede para implementao de servios VoIP em redes corporativas.
Figura 4.11: Metodologia para o planejamento de capacidade da rede para servios VoIP.
88
5 ESTUDO DE CASO
A aplicao da metodologia denida no captulo 4 ser realizada como estudo de
caso na rede administrativa da UCPel. Baseado nos levantamentos de trfego telefnico
convencional, j realizados neste trabalho, foram feitas simulaes das chamadas VoIP
utilizando a ferramenta Callgen323 (OPENH323, 2005). O objetivo das simulaes foi
medir a qualidade das ligaes telefnicas, atravs de VoIP, em um ambiente real. Os pa-
rmetros de QoS, atraso, jitter e perdas, das chamadas foram analisados com a ferramenta
Ethereal. O trfego de rede foi analisado para identicar a hora e o dia de maior movi-
mento. Nas medies, para gerar o trfego de rede da HMM foi utilizada a ferramenta
Iperf (NLANR/DAST : IPERF 1.7.0 - THE TCP/UDP BANDWIDTH MEASUREMENT
TOOL, 2005). A descrio do ambiente, os procedimentos e os resultados das medies
sero apresentados e analisados a seguir.
5.1 Cenrio
O cenrio utilizado para a aplicao da metodologia de planejamento de capacidade
foi a rede administrativa da Universidade Catlica de Pelotas (UCPel). A partir do levan-
tamento de intensidade de trfego telefnico feito na instituio, foi possvel determinar
quantas ligaes so realizadas na hora de maior movimento, e desta forma, os dados
foram aplicados no clculo para os servios de VoIP. Neste cenrio, o objetivo eliminar
a telefonia convencional, fazendo com que todos os servios de telefonia internos, ramal
para ramal, sejam em VoIP. Por exemplo, a utilizao de um PABX IP em software, tal
como o Asterisk, substituindo o PABX convencional.
5.2 Rede de Telefonia
Na UCPel, os servios internos de telefonia so fornecidos por um PABX da empresa
Ericsson modelo MD110, interligando cerca de 149 ramais. Conforme medies realiza-
das no capttulo 4, os dados resumidos nas tabelas 4.2 e 4.3 sero utilizados no estudo de
caso. Na gura 5.1, mostrada a distribuio da quantidade dos ramais nos segmentos da
rede administrativa da UCPel.
5.3 Rede de Dados
A rede de dados da rea administrativa da UCPel composta de um backbone funcio-
nando na velocidade de 100Mbits atravs de switches padro ethernet, sendo segmentada
por bras ticas. Em cada ponta das bras existem switches e hubs, na maioria a 10Mibts,
89
Figura 5.1: Diagrama da rede com a distribuio dos ramais
servindo de acesso para as estaes. So cerca de 600 hosts, com mais de 5000 usurios
entre alunos, funcionrios e professores. Alm disto, existem trs localidades remotas que
utilizam servios de linhas dedicadas (Assistncia Judiciria) e de frame relay (Hospital
e Campus Sade) para conexo com a rede administrativa. Os sites remotos possuem
independncia dos servios telefnicos, e no sero considerados no estudo de caso.
Em um futuro prximo, sero disponibilizados access points para a comunicao sem
o. As particularidades das redes sem os com o uso de servios VoIP so discutidos em
(ELAOUD; FAMOLARI; GHOSH, 2005), onde abordado o planejamento de capaci-
dade de redes.
A gura 5.2, apresenta a ilustrao da topologia simplicada da rede.
Figura 5.2: Topologia de rede simplicada.
90
5.3.1 Trfego de Rede
Atualmente, o trfego de rede medido atravs da ferramenta MRTG, fazendo leitura
das interfaces dos switches e roteadores. As estatsticas so coletadas de 5 e 5 minutos e
so gerados grcos com o trfego de entrada e de sada. Portanto, pode-se saber o trfego
mdio e os perodos de maior movimento durante o dia, a semana, o ms e o ano. Os picos
de trfego curtos so de difcil anlise com a ferramenta MRTG. Embora, dependendo do
tempo de amostragem, ainda seja possvel identicar picos de trfego, mesmo em coletas
peridicas de 5 minutos.
Atravs de arquivos de log e utilizando planilhas de clculos, possvel descobrir as
horas e os dias de maior movimento e o trfego mdio da HMM, Na tabela 5.1, esto
relacionados os valores de trfego mdio de cada segmento e a hora de maior trfego
coletados atravs dos logs da ferramenta MRTG.
Tabela 5.1: Levantamento do trfego de dados.
Segmento Mdia de Trfego
em HMM (kbits)
HMM Dia de Maior
Movimento
Reitoria 541,47 19hs Tera
Campus II 486,56 19hs Tera
Escola de Informtica 1121,35 17hs Quinta
Prdio dos DAs 284,6 17hs Tera
Central de Atendimento 400,33 21hs Quarta
Contabilidade 866,37 15hs Tera
Backbone 9307,96 19hs Tera
5.3.2 Mecanismos de QoS
Em relao as garantias de QoS, os switches do backbone possuem os padres IEEE
802.1p e 802.1Q, o que torna possvel separar o trfego em VLANs e priorizar os pacotes
de voz. Atualmente, no so usadas mltiplas VLANs e nenhum mecanismo de QoS para
o trfego de rede.
Os switches principais do backbone so da empresa 3COM modelo SuperStack III
4400SE, e possuem o padro 802.1p ativado automaticamente, fazendo distino entre os
quadros marcados na origem. O switch possui duas las para priorizao de trfego, uma
de alta e outra de baixa prioridade, mas nenhuma forma de congurao das polticas das
las.
Entre os roteadores, so usados servidores com o sistema operacional Linux. Neste
caso, podem ser usados mecanismos de DiffServ com auxlio da ferramenta IPTables
(NETFILTER, 2005) para a priorizao do trfego de voz. Nos roteadores dos sites re-
motos, Hospital, Campus Sude e Assistncia Judiciria, so utilizados equipamentos da
empresa Cisco com capacidade para DiffServ e IP Precedence.
As questes de congurao de QoS em switches e roteadores no sero abordados
no cenrio do estudo de caso, sendo o planejamento de capacidade da rede o foco princi-
pal. Nas simulaes de chamadas, a ferramenta geradora de chamadas, Callgen323, no
permite a marcao dos quadros com o padro 802.1p. Portanto, os resultados dos testes
correspondem a um rede sem mecanismos de QoS ou CoS.
91
5.4 Planejamento de Capacidade da Rede
Ser aplicada a metodologia, denida no captulo 4, para implantar servios VoIP na
rede administrativa da UCPel. Com os valores resultantes da aplicao da metodologia,
ser possvel realizar a simulao das chamadas e a medio da qualidade das ligaes.
5.4.1 Clculo de HMM
A intensidade de trfego medida atravs da coleta de registros do PABX, mostra que
cada ramal telefnico na parte administrativa da UCPel possui 0,018 erlangs em hora de
maior movimento. O clculo demonstrado abaixo:
AUCPel
=
Nchamadas
.
Tchamada
/
Nramais
/3600
AUCPel
= (179, 57).54/149/3600 (7)
AUCPel
= 0, 018e
Onde:
N
chamadas
- corresponde a mdia do nmero de chamadas na hora de maior movi-
mento. Conforme dados da tabela 4.2, foram feitas 4130 ligaes em cada hora de
maior movimento durante 23 dias. Portanto, o nmero mdio de ligaes igual a
4130/23, o que resulta em 179,57 ligaes por HMM;
T
chamada
- corresponde a durao mdia das chamadas (54 segundos);
N
ramais
- corresponde ao nmero total de ramais;
3600 - para obter o resultado em Erlangs.
Sabendo a intensidade de trfego de cada ramal, possvel calcular o trfego total
oferecido na hora de maior movimento, da seguinte forma:
Traf
Oferecido
= Traf
Ramal
. Ramais
Traf
Oferecido
= 0, 018.149 (8)
Traf
Oferecido
= 2, 7e
A intensidade de trfego total de 2,7e, no corresponde a distribuio dos ramais den-
tro da rede administrativa da UCPel. O valor s seria vlido se todos os ramais estivessem
disputando o mesmo grupo de linhas, por exemplo um gateway com um grupo de linhas
convencionais.
No caso de VoIP, a segmentao da rede tem a funo de criar vrios grupos de linhas.
No caso especco da rede administrativa da UCPel, os segmentos conectados por bras
poderiam ser considerados como grupo de linhas (troncos). Sendo assim, a intensidade de
trfego deve ser calculada para cada um destes segmentos. No est sendo considerado
o trfego entre ramais dentro do mesmo segmento. Observa-se que se um mesmo grupo
de linhas respondesse por todo o trfego, com GoS de 1%, seriam necessrias apenas 8
linhas. Fazendo o clculo por segmento, o nmero de linhas necessrias passaria a ser
de 22. Isto ocorre devido ao nmero de fontes originadoras de trfego. Na aplicao da
frmula de Erlang B, quanto maior o nmero de fontes originadoras, maior ser a taxa de
ocupao das linhas (IVERSEN et al., 2005).
Oclculo da intensidade de trfego para o segmento da Reitoria mostrado na frmula
9. O clculo para os outros segmentos segue o mesmo procedimento e na tabela 5.2 so
apresentados os resultados.
92
Traf
Oferecido
= Traf
Ramal
. Ramais
Traf
Oferecido
= 0, 018.37 (9)
Traf
Oferecido
= 0, 67e
Tabela 5.2: Intensidade de trfego por segmento.
Segmento Intensidade de Trfego
Reitoria 0,67e
Campus II 0,41e
Escola de Informtica 0,09e
Prdio dos DAs 0,09e
Central de Atendimento 0,49e
Contabilidade 0,72e
Backbone 0,22e
5.4.2 Denio do GoS
Foi denido que o GoS ser de P0.01, ou seja, que 1% de probabilidade que alguma
ligao seja bloqueada. Embora o conceito de bloqueio em uma rede de pacotes no
seja o mesmo do que em uma rede baseada em circuitos, pode-se usar um mecanismo
de controle de admisso de chamadas (Call Admission Control). Este mecanismo de
controle deve estar localizado no SIP proxy ou no H.323 gatekeeper. Com isto, ao ser
detectado o nmero mximo de ligaes simultneas, calculado previamente, no sero
mais permitidas novas ligaes. Por exemplo, o acrscimo de mais uma ligao pode
tornar a qualidade de todas as outras ligaes inaceitvel, devido ao esgotamento dos
recursos de rede.
Em arquiteturas que utilizam gateways, o GoS vai ser dependente do nmero de tron-
cos disponveis. Por exemplo, o mecanismo de controle de admisso de chamadas no
proxy SIP Asterisk, atravs da diretiva de congurao call_limit, que limita o nmero
de ligaes simultneas.
5.4.3 Aplicao da Frmula de Erlang B
A aplicao da frmula de Erlang B torna possvel descobrir quantas linhas so neces-
srias para comportar determinada intensidade de trfego telefnico. Como exemplo, ser
usado o segmento da Reitoria. O trfego oferecido de 0,66e, com GoS de 1%. Portanto,
aplicando a frmula, atravs da macro do Excel CircuitErlB apresentada no captulo 4,
poder ser obtido o nmero de linhas necessrias para o trfego telefnico calculado, da
seguinte forma:
CircuitErlB(trfego HMM em erlangs;GOS)
CircuitErlB(0,67e;0,01)
CircuitErlB=4 linhas
Pode-se usar tambm a tabela de erlang para saber o nmero de linhas, como est
demonstrado na gura 5.3.
Este procedimento foi aplicado em todos os segmentos da rede e os resultados esto
listados na tabela 5.3.
93
Figura 5.3: Nmero de servidores para trfego de 0,67e e GoS 1%
Tabela 5.3: Nmero de linhas por segmento.
Segmento Intensidade de Trfego Linhas
Reitoria 0,67e 4
Campus II 0,41e 3
Escola de Informtica 0,09e 2
Prdio dos DAs 0,09e 2
Central de Atendimento 0,49e 4
Contabilidade 0,72e 4
Backbone 0,22e 3
5.4.4 Tipo de Codec
O pior caso de consumo de largura de banda acontece quando da utilizao do codec
G.711. Em contrapartida, o G.711 possui a melhor qualidade de voz, sendo prefervel
em casos onde a largura de banda no problema, como em redes locais. Alm disto, o
codec G.711 tem um bom desempenho em relao a perdas de pacotes e possui tempo de
codicao e processamento muito baixo. Portanto, para efeito de projeto ser utilizado
o referido codec.
5.4.5 Nmero de Amostras por pacote
O nmero de amostras por pacote dependente da incidncia de erros e do atraso da
rede. Como visto na captulo 4, quanto maior o nmero de amostras de voz por pacote,
maior o atraso e maior o prejuzo para a conversao em caso de perdas. Em uma rede
local comutada, as perdas so desprezveis e o atraso normalmente baixo, podendo ser
controlado com mecanismos de QoS. Portanto, sero utilizadas 3 amostras por pacote,
possuindo cada pacote 240 bytes de carga til (voz) com o uso do codec G.711. Com 3
amostras por pacote, cada ligao ocupar 169,6kbits.
5.4.6 Supresso de Silncio
A supresso de silncio pode ser ativada nos terminais para diminuir a largura de
banda utilizada. A ferramenta utilizada na simulao das chamadas, Callgen323, no
permite a utilizao deste mecanismo e portanto no foi utilizado nos testes.
5.4.7 Compresso de Cabealhos
A compresso de cabealhos s pode ser utilizada em enlaces ponto a ponto, o que no
foi aplicvel nas medies efetuadas. No estudo de caso, poderia ser aplicada nos enlaces
entre o backbone e as redes locais remotas da Assistncia Judiciria, Campus Sade e
94
Hospital.
5.4.8 Clculo da Largura de Banda
Para realizar o clculo do consumo de largura de banda necessria para absorver os
servios de VoIP na rede administrativa da UCPel, deve-se fazer o clculo do nmero de
linhas necessrias para absorver o trfego telefnico na HMM , multiplicado pela largura
de banda de cada chamada. Se fossem utilizados todos os ramais em um mesmo seg-
mento, a largura de banda necessria para absorver todo o trfego telefnico seria de 1,37
MBits conforme a frmula 10.
Banda
Total
= troncos . banda
chamada
.2
Banda
Total
= 8.84, 8kbits.2 (10)
Banda
Total
= 678, 4kbits.2
Banda
Total
= 1, 37Mbits
Mas no estudo de caso, o clculo deve ser aplicado para cada segmento em separado.
O resultado do clculo para o segmento da Reitoria est demonstrado na frmula 11.
Banda
Total
= troncos . banda
chamada
.2
Banda
Total
= 4.84, 8kbits.2 (11)
Banda
Total
= 339, 2kbits.2
Banda
Total
= 678, 4kbits
O resultado nal para todos os segmentos est representado na tabela 5.4 e no dia-
grama da gura 5.4:
Figura 5.4: Diagrama da distribuio de ramais e a largura de banda
95
Tabela 5.4: Largura de banda por segmento.
Segmento Ramais Trfego (erlangs) Troncos Banda (kbits)
Reitoria 37 0,67 4 678,4
Campus II 23 0,41 3 508,8
Escola de Informtica 5 0,09 2 339,2
Prdio dos DAs 5 0,09 2 339,2
Central de Atendimento 27 0,49 4 678,4
Contabilidade 40 0,72 4 678,4
Backbone 12 0,22 3 508,8
5.5 Medies
Foram feitas medies utilizando a ferramenta Callgen323, para simulao de chama-
das e os dados levantados e calculados conforme a metodologia aplicada na rede admi-
nistrativa da UCPel. Os valores de atraso, perdas e jitter foram avaliados.
5.5.1 Ferramentas
As ferramentas Callgen323, Tcpdump, IPerf e Ethereal foram utilizadas para os
testes.
5.5.1.1 Callgen323
A ferramenta CallGen323 faz parte do projeto OpenH323 (OPENH323, 2005) e tem
como funo gerar chamadas utilizando codecs de voz e os protocolos RTP e UDP. Ori-
ginalmente, foi criada para testar a implementao de gatekeepers H.323, mas pode ser
aplicada em qualquer ambiente que necessite testar uxos de udio RTP. uma ferra-
menta de cdigo-fonte aberto e pode ser utilizada em vrias plataformas, tais como Linux
e Windows. possvel, atravs dos arquivos de log gerados pela ferramenta, analisar os
valores de atraso, jitter e perda de pacotes das chamadas. Tambm possvel salvar o
arquivo de udio recebidos para posterior comparao com o udio original. A verso
utilizada foi a 1.2.26.
5.5.1.2 Tcpdump
A ferramenta Tcpdump a ferramenta padro para a captura de trfego de rede em
sistemas operacionais Unix e Linux. Baseada na biblioteca libpcap (TCPDUMP, 2005),
possui ltros que permitem a captura seletiva de pacotes provendo a gravao em arquivo
para posterior anlise.
5.5.1.3 Iperf
A ferramenta Iperf possibilita gerar trfego UDP e medir a mxima largura de banda
TCP (NLANR/DAST : IPERF 1.7.0 - THE TCP/UDP BANDWIDTH MEASUREMENT
TOOL, 2005). Permite ajustar vrios parmetros do protocolo TCP, tal como tamanho de
buffer, e vrias caractersticas do protocolo UDP, tal como largura de banda, para gerar
trfego de rede. O Iperf pode gerar relatrios de largura de banda, atraso, jitter e perdas
de pacotes. A verso utilizada foi a 2.0.2.
96
5.5.1.4 Ethereal
A ferramenta Ethereal permite capturar e analisar o trfego de rede, reconhecendo
mais de 400 protocolos (ETHEREAL: WIKI, 2005). Possui interpretadores, chamados
(dissectors,) para os protocolos de VoIP, tais como SIP, H.323 e RTP. Para as medies
realizadas foram utilizados recursos de anlise de uxos de udio RTP, para medir atraso,
perdas e jitter nos pacotes capturados (gura 5.5). OEthereal uma ferramenta de cdigo-
fonte aberto e est disponvel para vrias plataformas. A verso utilizada foi a 0.10.14.
Figura 5.5: Tela da ferramenta Ethereal para anlise de uxos RTP
5.5.2 Procedimentos
Para realizar os testes necessrio saber o nmero de ligaes que cada ramal realiza
em HMM. De acordo com a tabela 4.2, so realizadas 1,21 chamadas por ramal em HMM.
O nmero de linhas necessrios para a intensidade de trfego, corresponde a simultanie-
dade das chamadas. Por exemplo, no caso do segmento da Reitoria so 37 ramais, que
geram um total de 44,77 chamadas (37 ramais x 1,21 chamadas por ramal). O nmero
de linhas necessrias para absorver o trfego, utilizando um GoS de 1%, de 4 linhas.
Portanto, existiro 4 chamadas simultneas (4 linhas ocupadas) durante a HMM.
Na tabela 5.5, o total de chamadas por segmento em HMM.
Tabela 5.5: Total de chamadas por segmento.
Segmento Ramais Chamadas Simultneas Total de Chamadas
Reitoria 37 4 44,77
Campus II 23 3 27,83
Escola de Informtica 5 2 6,05
Prdio dos DAs 5 2 6,05
Central de Atendimento 27 4 32,67
Contabilidade 40 4 48,4
Backbone 12 3 14,52
Em cada segmento, foram utilizados dois hosts para simular as chamadas e o trfego.
Um dos hosts executou a ferramenta Iperf, gerando trfego, e o outro host gerou o nmero
97
de chamadas correspondentes ao volume de chamadas da HMM, utilizando a ferramenta
CallGen323. Os dois hosts utilizaram as ferramentas na plataforma Windows.
Abaixo, os parmetros utilizados nas ferramentas como clientes para o segmento da
Reitoria:
Linha de comando:
callgen323 -n -m 4 -r 11 -O teste.wav --tmincall 54
--tmaxcall 54 --tminwait 1 --tmaxwait 4 200.17.170.37
-n: ignorar a presena de um gatekeeper H.323
-m: nmero de chamadas simultneas
-r: nmero de repeties (4 simultneas x 11)
-O: arquivo com udio
--tmincall: tempo mnimo de durao da chamada
--tmaxcall: tempo mximo da durao da chamada
--tminwait: tempo mnimo de espera entre as chamadas
--tmaxwait: tempo mximo de espera entre as chamadas
Linha de comando:
iperf -u -c 200.17.170.152 -b 541,47K -d -t 2400
-u: utilizar o protocolo UDP
-c: endereo do ponto de conexo (servidor)
-b: valor da largura de banda (541,47K)
-d: bi-direcional
-t: tempo de durao do trfego em segundos
O arquivo teste.wav foi criado atravs da ferramenta Audacity (AUDACITY: FREE
AUDIO EDITOR AND RECORDER, 2005) e contm um trecho de conversao telef-
nica pr-gravada de 60 segundos. O formato do arquivo 16 bits, 8000Hz e mono, cor-
respondendo a voz humana. A ferramenta CallGen323 utiliza o arquivo para simular uma
chamada real.
Os hosts receptores do trfego e das chamadas utilizaram as ferramentas como ser-
vidores (modo de escuta). No caso do host que rodou a ferramenta CallGen323 como
servidor, a ferramenta Tcpdump cou rodando no mesmo host para capturar o trfego das
chamadas. O trfego capturado serviu para a posterior anlise na ferramenta Ethereal.
Abaixo, as linhas de comando e os parmetros utilizados para as ferramentas utilizadas
no modo servidor:
Linha de comando:
callgen323 -l -n -ttt -o reitoria.trace
-n: ignorar a presena de um gatekeeper H.323
-l: ficar em estado de espera (recepo)
-ttt: nvel de detalhamento do arquivo de log
-o: arquivo para gravao do log
Linha de comando:
tcpdump -i eth0 -w reitoria.dump udp
-i: interface para captura
-w: arquivo para gravao da captura
98
udp: filtro para capturar somente o pacotes
com o protocolo UDP.
Linha de comando:
iperf -u -s -i 30
-u: utilizar o protocolo UDP
-s: ficar em estado de espera (recepo)
-i: gerao de relatrios a cada 30s
5.5.3 Ambiente de Testes
Os testes foram realizados em horrio fora do expediente de funcionamento da UC-
Pel. Para gerar o trfego correspondente ao da HMM, foi utilizada a ferramenta Iperf.
Para gerar o trfego, foi posicionado um gerador de trfego Iperf em cada segmento e
um servidor, localizado no segmento Backbone, para a terminao dos uxos. O tr-
fego mdio de cada segmento foi gerado de forma constante durante a durao dos testes
com as chamadas. Desta forma, pode-se fazer uma aproximao do trfego real de rede
em HMM. A plataforma utilizada foi o Windows para os geradores de trfego e Linux
para as terminaes. Para a recepo das chamadas, foi utilizado um servidor Linux ro-
dando a verso 9 do RedHat, em um segmento de 100Mbits comutado. Este servidor fez
o papel equivalente ao do PABX IP. A ferramenta CallGen323 cou rodando em estado
de espera, recebendo as chamadas e gerando estatsticas. No mesmo servidor, cou ro-
dando o utilitrio Tcpdump para coletar o trfego UDP na interface de rede. O trfego
foi armazenado em arquivo para posterior anlise na ferramenta Ethereal. Nos clientes
foi utilizada a ferramenta CallGen323 para Windows para gerar as ligaes, nos perodos
pr-determinados. Na gura 5.6, o ambiente de testes representado.
Os arquivos capturados pelo tcpdump foram analisador atravs da ferramenta Ethe-
real. Os uxos de RTP foram ltrados e as informaes sobre jitter, atraso e perdas,
foram exportados, atravs de arquivos texto, para planilhas de clculo no Microsoft Ex-
cel. Ento, os valores de jitter mdio, jitter mximo, perdas mximas, atraso mdio,
atraso mximo, desvio padro do jitter e do atraso foram calculados para cada conjunto
de chamadas por segmento. Os atrasos correspondem somente a um caminho da ligao,
sendo equivalente ao atraso entre o emissor e o receptor, sem o atraso de retorno da liga-
o. Para determinar o atraso total da ligao, basta multiplicar por dois o valor do atraso
medido.
Na gura 5.7, a tela da ferramenta Ethereal com a anlise dos uxos RTP do segmento
da Reitoria. Em destaque, a funo para a exportao dos dados para arquivo texto.
Foram realizados testes com a intensidade de trfego de rede e de chamadas atuais,
com um volume adicional de 50% no trfego de rede e com um aumento de 50% no tr-
fego de rede e de telefonia, projetando um crescimento da demanda de servios, conforme
a tabela 5.6. Os resultados das medies sero apresentados a seguir.
5.6 Resultados
Na tabela 5.6, so apresentados os resultados das medies feitas no ambiente de teste
para a intensidade de trfego atual. Na tabela 5.7, os resultados das medies com um
acrscimo de 50% no trfego de rede. Na tabela 5.8, os resultados das medies com um
acrscimo de 50% no trfego de rede e no nmero de ramais.
99
Figura 5.6: Ambiente de testes.
Figura 5.7: Anlise de uxos do segmento da Reitoria.
100
Tabela 5.6: Nmero de ramais e largura de banda por segmento, com 50% de acrscimo.
Segmento Ramais Trfego (erlangs) Troncos Trfego (kbits)
Reitoria 55 1 5 812,21
Campus II 34 0,62 4 729,84
Escola de Informtica 7 0,14 2 1682,03
Prdio dos DAs 7 0,14 2 426,90
Central de Atendimento 40 0,73 4 600,50
Contabilidade 40 1,08 5 1299,56
Backbone 18 0,32 3 13961,94
Tabela 5.7: Resultados das medies para intensidade de trfego atual.
Segmento Jitter
mx.
(ms)
Perdas
mx.
(%)
Atraso
mx.
(ms)
Jitter
md.
(ms)
Atraso
md.
(ms)
Desv.
Padro
Jitter
(ms)
Desv.
Padro
Atraso
(ms)
Reitoria 10,73 0 67,29 2,47 59,28 0,06 6,28
Campus II 2,9 0 121,11 2,51 72,27 0,21 20,71
Escola de Informtica 8,15 0 78,97 2,47 70,23 0,06 8,78
Prdio dos DAs 2,44 0 84,3 2,44 62,35 0,05 16,03
Central de Atendimento 2,69 0 99,27 2,54 70,79 0,07 14,56
Contabilidade 3,27 0 143,43 2,62 74,98 0,17 22,8
Backbone 14,95 0 116,48 2,62 75,17 0,19 15,71
Tabela 5.8: Resultados das medies para intensidade de trfego de rede com 50% acrs-
cimo.
Segmento Jitter
mx.
(ms)
Perdas
mx.
(%)
Atraso
mx.
(ms)
Jitter
md.
(ms)
Atraso
md.
(ms)
Desv.
Padro
Jitter
(ms)
Desv.
Padro
Atraso
(ms)
Reitoria 9,51 0 81,44 2,46 59,87 0,07 9,96
Campus II 2,51 0 109,69 2,78 84,52 0,96 21,86
Prdio dos DAs 2,39 0 77,3 2,39 55,41 0,02 13,30
Contabilidade 2,74 0 120,55 2,58 73,44 0,08 18,52
Backbone 14,44 0 132,55 2,69 79,9 0,12 22,25
5.6.1 Anlise dos Resultados
No estudo de caso, os resultados das medies demonstraram a viabilidade do uso de
servios VoIP, mesmo sem a utilizao de mecanismos de Qos ou CoS. Segundo (WAL-
LINGFORD, 2005), os valores de referncia para um boa qualidade de chamadas VoIP
so:
Atraso: o atraso mximo deve car abaixo dos 150ms em um sentido da ligao.
Na prtica, o valor mximo aceitvel, pode car em torno de 400ms.
Perdas: abaixo de 1%, com o limite de 3% de perdas de pacotes. O efeito do nvel
101
Tabela 5.9: Resultados das medies para intensidade de trfego e nmero de ramais com
50% de acrscimo.
Segmento Jitter
mx.
(ms)
Perdas
mx.
(%)
Atraso
mx.
(ms)
Jitter
md.
(ms)
Atraso
md.
(ms)
Desv.
Padro
Jitter
(ms)
Desv.
Padro
Atraso
(ms)
Reitoria 10,81 0 76,23 2,49 62,68 0,06 10,13
Campus II 3,67 0 110,37 2,98 84,32 0,32 14,13
Prdio dos DAs 2,46 0 85,44 2,46 69,96 0,07 11,38
Contabilidade 2,81 0 113,21 2,61 76,27 0,09 16,23
Backbone 19,16 0 216,68 2,8 92,84 0,18 35,33
de perdas vai depender do codec utilizado e do nmero de amostras por pacote. No
estudo de caso, foi utilizado o codec G.711 com trs amostras por pacote. Com
duas amostras por pacote, o codec G.711 mantm a qualidade da chamadas com
perdas de at 3% dos pacotes. Com trs amostras, o nvel de perdas de pacotes deve
ser menor.
Jitter: o jitter mximo recomendado cerca de 75ms. O valor mximo pode variar
de acordo com o tipo de algoritmo utilizado no equalizador (buffer) de jitter do
receptor.
Nas medies realizadas, das 600 ligaes, 99% das ligaes caram dentro dos limi-
tes de referncia para atraso, perdas e jitter.
Em relao a perdas, foi perdido apenas 1 pacote de um total de 789871 pacotes
gerados em todas a ligaes. Por se tratar de uma LAN, so valores considerados normais.
No caso do atraso, cerca de 1% das ligaes apresentaram valores acima dos 150ms,
mas o atraso nestas ligaes cou abaixo dos 220ms. De acordo com os valores de re-
ferncia denidos pelo ITU na recomendao G.114, o atraso seria aceitvel, mas com
algum prejuzo de qualidade. Alm disto, as chamadas com atrasos acima de 150ms
foram originadas dos testes com 50% de acrscimo de trfego e 50% de acrscimo de
ramais. De acordo com o desvio padro calculado, o atraso no obteve grande variao
nos testes realizados.
Os valores de jitter mximo e mdio se mantiveram bem abaixo dos 75ms em todas
as ligaes, sendo o valor mximo de 19,22ms. A variao do jitter foi bastante baixo,
cando abaixo dos 1ms.
Nas guras 5.8, 5.9 e 5.10 esto plotados os valores de atraso mximo e jitter mximo
para todas as ligaes realizadas no diversos segmentos, variando o volume de trfego e
o nmero de ramais.
De acordo com o resultado das medies realizadas, a rede do estudo de caso suporta-
ria a intensidade de trfego telefnico ramal para ramal, atual e com um aumento de 50%,
no trfego e no nmero de ramais.
102
Figura 5.8: Grco das ligaes com volume de trfego e o nmero de ramais atuais.
Figura 5.9: Grco das ligaes com 50% a mais de volume de trfego e o nmero de
ramais atuais.
103
Figura 5.10: Grco das ligaes com 50% a mais de volume de trfego e de nmero de
ramais.
104
6 CONCLUSO
Os servios de VoIP esto em amplo crescimento, tanto para usurios domsticos
quanto para usurios corporativos. A tendncia que haja um crescimento ainda maior
nos prximos anos. Embora a popularidade dos servios VoIP tenha se dado em servios
sem garantias de qualidade, a substituio do sistema telefnico convencional por ser-
vios VoIP s ser possvel com as garantias da mesma qualidade de voz. Para isto, o
planejamento de capacidade de rede desempenha papel fundamental.
O trabalho teve como objetivo principal mostrar uma metodologia para o planeja-
mento de capacidade de rede para implantao de servios VoIP. Foram realizados estudos
sobre o planejamento de capacidade de redes telefnicas convencionais e a possibilidade
de adaptao destes mtodos para os servios VoIP.
Como objetivos secundrios, os fundamentos de VoIP foram abordados, principal-
mente o protocolo SIP, resultando em uma referncia para aproveitamento em estudos
futuros. Os quesitos de QoS utilizados para a implementao de servios VoIP em redes
corporativas foram apresentados e discutidos.
O estudo de caso possibilitou a aplicao da metodologia em um ambiente real. Foram
utilizadas ferramentas gratuitas e de cdigo-fonte aberto para a gerao de chamadas e de
trfego de rede e anlise dos uxos de udio. Os resultados demonstram a possibilidade
de utilizar servios de VoIP, com boa qualidade, mesmo em redes corporativas sem me-
canismos de QoS ou CoS. Entretanto, para garantir a qualidade oferecida pela telefonia
convencional, indispensvel a utilizao de mecanismos de QoS. Em redes corporativas,
podem ser utilizados mecanismos de CoS, tais como DiffServ e IEEE 802.1p, em switches
e roteadores para a priorizao de trfego. Em casos de largura de banda excedente, como
em LANs comutadas, os mecanismos de CoS podem garantir a qualidade das chamadas.
Em enlaces ponto a ponto, podem ser utilizados mecanismos de reserva de banda, tal
como RVSP, ou de reduo de largura de banda, tal como a utilizao de compresso de
cabealhos.
A aplicao, no estudo de caso, da metodologia de planejamento de capacidade de
rede desenvolvida demonstra a sua utilidade como uma ferramenta na implantao de
servios VoIP em redes corporativas.
Como trabalhos futuros, sugere-se:
Aplicao da metodologia elaborada neste trabalho em outros ambientes de rede;
Aplicao e medio dos mecanismos de garantia de QoS e CoS na rede com ser-
vios VoIP;
Elaborao de uma metodologia para planejamento de capacidade em redes mistas,
como o uso de servios VoIP e telefonia convencional atravs de gateways;
105
Adaptao das ferramentas utilizadas para o clculo do fator de qualidade R do
Modelo E;
Aplicao da metodologia desenvolvida neste trabalho e a implantao do servios
VoIP em um ambiente com usurios.
106
REFERNCIAS
3COM. Disponvel em: <http://www.3com.com/>. Acesso em: set. 2005.
ANATEL. Resoluo n
o
30, de 29 de junho de 1998.
Disponvel em: <http://www.anatel.gov.br/index.asp?link=
/biblioteca/resolucao/1998/res_030_1998.PDF>. Acesso em: ago. 2005.
ANATEL. Anexo Resoluo n.
o
272, de 9 de agosto de 2001
- Regulamento do Servio de Comunicao Multimdia. Dis-
ponvel em: <http://www.anatel.gov.br/index.asp?link=/biblioteca/
resolucao/2001/res_272_2001.pdf?Cod=1944>. Acesso em: ago. 2005.
ANATEL. Plano Geral de Metas de Qualidade (PGMQ) - janeiro a dezembro
de 2005. Disponvel em: <http://sistemas.anatel.gov.br/saci/Relatorios /PgmqConso-
lidado/Tela.asp?acao=Conrmar &codTipoConsolidado=2&AnoInicial=2005>. Acesso
em: ago. 2005.
ANGUS, I. An Introduction to Erlang B and Erlang C. Telemanagement Journal, [S.l.],
n.187, June 2002. Disponvel em :<http://www.angustel.ca/>. Acesso em: ago. 2005.
AT&T. AT&T - History of Network Switching. Disponvel em:
<http://www.att.com/history/nethistory/switching.html>. Acesso em: set. 2005.
AUDACITY: free audio editor and recorder. Disponvel em:
<http://audacity.sourceforge.net/>. Acesso em: set. 2005.
AVAYA. Avaya - IP Voice Quality Network Requirements - Version 2.0. Dispo-
nvel em: <http://www1.avaya.com/enterprise/whitepapers/lb1894.pdf>. Acesso em:
ago. 2005.
BARAN, P. On Distributed Communications Networks. In: CONGRESS OF THE IN-
FORMATION SYSTEMS SCIENCES, 1., 1962. Proceedings. . . [S.l.: s.n.], 1962.
BASET, S. A.; SCHULZRINNE, H. An Analysis of the Skype Peer-to-Peer Internet
Telephony Protocol. New York - USA: Department of Computer Science, Columbia
University, 2004.
BERNERS-LEE, T.; FIELDING, R.; MASINTER, L. Uniform Resource Identiers
(URI): generic syntax: RFC 2396. [S.l.]: Internet Engineering Task Force, Network Wor-
king Group, 1998.
107
BIYANI, P. et al. Early Estimation of Voice over IP quality. In: NORDUNET NETWORK
CONFERENCE, 21., 2003. Proceedings. . . [S.l.: s.n.], 2003.
BLAKE, S.; BLACK, D.; CARLSON, M.; DAVIES, E.; WANG, Z.; WEISS, W. An
Architecture for Differentiated Services: RFC 2475. [S.l.]: Internet Engineering Task
Force, Network Working Group, 1998.
BRANDL, M. et al. IP Telephony Cookbook - TERENA Report. Amsterd - Holanda:
Trans-European Research and Education Networking Association (TERENA), 2004.
BROCKMEYER, E.; HALSTRM, H.; JENSEN, A. The Life and Works of A.K.
Erlang. Transactions of the Danish Academy of Technical Sciences, [S.l.], n.2,
1948. Disponvel em :<http://http://oldwww.com.dtu.dk/teletrafc/erlangbook/pp001-
278.pdf>. Acesso em: nov. 2005.
CASNER, S.; JACOBSON, V. Compressing IP/UDP/RTP Headers for Low-Speed Se-
rial Links: RFC 2508. [S.l.]: Internet Engineering Task Force, Network Working Group,
1999.
CASTRO, M. C. F. de. Planejamento de Redes Comutadas: notas de aula. Disponvel
em: <http://www.ee.pucrs.br/ decastro/pdf/Redes_Comutadas_Cap4.pdf>. Acesso em:
maio 2005.
CHONG, H. M.; MATTHEWS, H. S. Comparative Analysis of Traditional Telephone
and Voice-over-Internet Protocol (VoIP) Systems. IEEE International Symposium on
Electronics and the Environment, [S.l.], p.106111, May 2004.
CISCO. Trafc Analysis for Voice over IP. Disponvel em:
<http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/ta_isd.pdf>.
Acesso em: maio 2005.
CISCO. Cisco - Understanding Delay in Packet Voice Networks. Disponvel em:
<http://www.cisco.com/warp/public/788/voip/delay-details.pdf>. Acesso em: ago. 2005.
COFFMAN, J. E. Not Your Fathers PBX. ACM Queue, [S.l.], Sept. 2004.
COHEN, D. Specications for the Network Voice Protocol (NVP): RFC 471. [S.l.]:
Internet Engineering Task Force, Network Working Group, 1977.
COLE, R. G.; ROSENBLUTH, J. H. Voice over IP performance monitoring. SIGCOMM
Comput. Commun. Rev., New York, NY, USA, v.31, n.2, p.924, 2001.
COLLINS, D. Carrier Grade Voice over IP. 2nd.ed. [S.l.]: McGraw-Hill, 2003.
CONWAY, A. E. A Performance Monitoring System for VoIP Gateways. In:
WORKSHOP ON SOFTWARE AND PERFORMANCE, 2., 2000. Proceedings. . .
[S.l.: s.n.], 2000. p.3843.
COUNTERPATH. Counterpath. Disponvel em: <http://www.xten.net/>. Acesso em:
out. 2005.
CYGWIN. Disponvel em: <http://www.cygwin.com/>. Acesso em: out. 2005.
DAVIDSON, J.; JAMES, P. Voice over IP Fundamentals. [S.l.]: Cisco Press, 2000.
108
DIGIUM. Asterisk - the Open Source PBX. Disponvel em: <http://www.asterisk.org>.
Acesso em: ago. 2005.
DRAPER, J. T. Capn Crunch in Cyberspace. Disponvel em:
<http://www.webcrunchers.com/crunch/>. Acesso em: ago. 2005.
ELAOUD, M.; FAMOLARI, D.; GHOSH, A. Experimental VoIP Capacity Measurements
for 802.11b WLANs. In: IEEE CONSUMER COMMUNICATIONS & NETWORKING
CONFERENCE, 2005. Proceedings. . . [S.l.: s.n.], 2005.
ENUM.ORG. ENUM - FAQ. Disponvel em: <http://www.enum.org/
information/faq.cfm>. Acesso em: out. 2005.
ERLANG.COM. Erlang Calculator. Disponvel em: <http://www.erlang.com>. Acesso
em: out. 2005.
ERLANG.CO.UK. Erlang for Excel. Disponvel em:
<http://www.erlang.co.uk/excel.htm>. Acesso em: maio 2005.
ETHEREAL: a network protocol analyzer. Disponvel em: <http://www.ethereal.com/>.
Acesso em: out. 2005.
ETHEREAL: wiki. Disponvel em: <http://wiki.ethereal.com/Ethernet/>. Acesso em:
set. 2005.
FALTSTROM, P.; MEALLING, M. The E.164 to Uniform Resource Identiers (URI)
Dynamic Delegation Discovery System (DDDS) Application (ENUM): RFC 3761.
[S.l.]: Internet Engineering Task Force, Network Working Group, 2004.
FARLEY, T. Tom Farleys Telephone History Series. Disponvel em:
<http://www.privateline.com/TelephoneHistory/History1.htm>. Acesso em: ago. 2005.
FWD: free world dialup. Disponvel em: <http://www.pulver.com/fwd/>. Acesso em:
maio 2005.
GIZMO Project. Disponvel em: <http://www.gizmoproject.com>. Acesso em:
maio 2005.
GONCALVES, A. R. Mtodo para Planejamento de Capacidade de Redes ATM ba-
seado em Simulao. 2000. Dissertao (Mestrado em Cincia da Computao) Pro-
grama de Ps-Graduao em Computao, UFRGS, Porto Alegre, Brasil.
GOODE, B. Voice Over Internet Protocol (VoIP). Proceedings of the IEEE, [S.l.], v.90,
n.9, Sept. 2002.
HANDLEY, M.; JACOBSON, V. SDP: session description protocol: RFC 2327. [S.l.]:
Internet Engineering Task Force, Network Working Group, 1998.
HARDY, W. C. VoIP Service Quality - Measuring and Evaluating Packet-Switched
Voice. [S.l.]: McGraw-Hill, 2003.
HP. VoIP Solutions Cookbook Conguring a ProCurve Voice-over-IP Solution. Dis-
ponvel em: <http://www.hp.com/rnd/pdfs/VoIP_Cookbook.pdf>. Acesso em: jan. 2005.
109
HUSTON, G. ENUM - Mapping the E.164 Number Space into the
DNS. The Internet Protocol Journal, [S.l.], v.5, n.2, June 2002. Dis-
ponvel em :<http://www.cisco.com/application/ pdf/en/us/guest/about
/about/c644/ccmigration09186a008020eba4.pdf>. Acesso em: ago. 2005.
IANA. Enumservice Registrations. Disponvel em:
<ftp://ftp.iana.org/assignments/enum-services>. Acesso em: out. 2005.
ICT. ICT (Information and Communication Theory Group) - The
Power of the Erlang Formula. Disponvel em: <http://ict.ewi.tudelft.nl
/index.php?option=com_sections&id=164&Itemid=286>. Acesso em: maio 2005.
IEEE. IEEE Std 802.3af - Part 3: carrier sense multiple access with collision detection
(csma/cd) access method and physical layer specications. [S.l.: s.n.], 2003.
ILBCFREEWARE.ORG. Disponvel em: <http://www.ilbcfreeware.org/>. Acesso em:
out. 2005.
INTEL. Differentiated Services - Moving towards Quality of Service on the
Ethernet. Disponvel em: <http://www.intel.com/network/connectivity/resources/doc_
library/white_papers/solutions/diff_serv/diffserv.pdf>. Acesso em: jan. 2005.
INTERNET2. Projeto Internet2. Disponvel em: <http://www.internet2.edu/>. Acesso
em: jul. 2005.
ITU-T. ITU-T Recommendation H.323: packetd-based multimedia communications
systems. [S.l.: s.n.], 1997.
ITU-T. ITU-T Recommendation G.107. The E-Model, a computational model for use
in transmission planning. [S.l.: s.n.], 2003.
ITU-T. ITU-T Recommendation E.164: the international public telecommunication
numbering plan. [S.l.: s.n.], 2005.
IVERSEN, V. B. et al. Teletrafc Engineering Handbook. Genebra - Suia: ITU (Inter-
national Telecommunication Union), ITC (International Teletrafc Congress), 2005.
JI, W.; SCHULZRINNE, H. Assessment of VoIP Service Availability in
the Current Internet. In: PASSIVE AND ACTIVE MEASUREMENT
WORKSHOP, 2003. Proceedings. . . [S.l.: s.n.], 2003. Disponvel em:
<http://moat.nlanr.net/PAM2003/PAM2003papers/3897.pdf>. Acesso em: maio 2005.
JIANG, W.; KOGUCHI, K.; SCHULZRINNE, H. QoS Evaluation of VoIP End-points.
In: IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS, 2003. Proce-
edings. . . [S.l.: s.n.], 2003. p.19171921.
JIANG, W.; SCHULZRINNE, H. Analysis of on-off patterns in VoIP and their effect
on voice trafc aggregation. In: IEEE INT. CONF. COMPUTER COMMUNICATION
NETWORKS, 2000. Proceedings. . . [S.l.: s.n.], 2000. p.8287.
KAZAA. Kazaa File Sharing. Disponvel em: <http://www.kazaa.com>. Acesso em:
ago. 2005.
110
LUSTOSA, L. C. G. Arquitetura de Monitorao de Qualidade de Chamadas Telef-
nicas IP. 2005. Dissertao (Mestrado em Cincia da Computao) UFRJ, Instituto de
Matemtica, Ncleo de Computao Eletrnica, Rio de Janeiro, Brasil.
LUSTOSA, L. C. G. et al. Utilizao do Modelo E para avaliao da qualidade da fala
em sistemas de comunicao baseados em voz sobre IP. In: SIMPSIO BRASILEIRO
DE REDES DE COMPUTADORES, SBRC, 22., 2004, Gramado: II/UFRGS. Anais. . .
[S.l.: s.n.], 2004.
MARKOPOULOU, A. P.; TOBAGI, F. A.; KARAM, M. J. Assessing the Quality of Voice
Communications Over Internet Backbones. IEEE/ACM Transactions on Networking,
[S.l.], v.11, n.5, p.747759, Oct 2003.
MESSENGER. Pgina do servio Microsoft Messenger. Disponvel em:
<http://messenger.msn.com>. Acesso em: set. 2005.
MILLENNIUM MATHEMATICS PROJECT, B. from. Agner Krarup Erlang (1878 -
1929). Disponvel em: <http://pass.maths.org.uk/issue2/erlang/>. Acesso em: out. 2005.
MINOLI, D.; MINOLI, E. Delivering Voice over IP Networks. [S.l.]: John Wiley Sons,
1998.
MORTON, D. The Electrical Century - A Snapshot of Telephony at the Turn of the Cen-
tury. Proceedings of the IEEE, [S.l.], v.87, n.4, Apr. 1999.
MRTG: the multi router trafc grapher. Disponvel em:
<http://people.ee.ethz.ch/etiker/webtools/mrtg/>. Acesso em: out. 2005.
NET2PHONE. Disponvel em: <http://www.net2phone.com/>. Acesso em: jul. 2005.
NETFILTER. Disponvel em: <http://www.netlter.org/>. Acesso em: out. 2005.
NICHOLS, K. et al. Denition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers: RFC 2474. [S.l.]: Internet Engineering Task Force, Network
Working Group, 1998.
NLANR/DAST : iperf 1.7.0 - the tcp/udp bandwidth measurement tool. Disponvel em:
<http://dast.nlanr.net/Projects/Iperf/>. Acesso em: set. 2005.
ODLYZKO, A. The history of communications and its implications
for the Internet. [S.l.]: AT&T Labs - Research, 2000. Disponvel em:
<http://www.dtc.umn.edu/ odlyzko/doc/history.communications0.pdf>. Acesso em:
maio 2005.
OPENH323. Disponvel em: <http://www.openh323.org>. Acesso em: jul. 2005.
PROJETO Fone@RNP. Disponvel em: <http://www.voip.nce.ufrj.br/foneatrnp/>.
Acesso em: maio 2005.
RACHID, E. M. Cancelamento de Eco em Telefonia IP. 2004. Dissertao (Mestrado
em Cincia da Computao) DECOM/Ps-Graduao em Engenharia Eltrica, UNI-
CAMP, Campinas, Brasil.
111
ROSENBERG, J. et al. SIP: session initiation protocol: RFC 3261. [S.l.]: Internet Engi-
neering Task Force, Network Working Group, 2002.
ROSENBERG, J.; SCHULZRINNE, B. SIP: session initiation protocol v.2.0: RFC 3261.
[S.l.]: Internet Engineering Task Force, Network Working Group, 2002.
ROSENBERG, J.; SCHULZRINNE, H. An Offer/Answer Model with the Session Des-
cription Protocol: RFC 3264. [S.l.]: Internet Engineering Task Force, Network Working
Group, 2002.
SCHULZRINNE, H. et al. RTP: a transport protocol for real-time applications: RFC
1889. [S.l.]: Internet Engineering Task Force, Network Working Group, 1996.
SIP.EDU: voice over ip workgroup. Disponvel em: <http://voip.internet2.edu/SIP.edu/>.
Acesso em: jul. 2005.
SIPPHONE. University Peering Program. Disponvel em:
<http://www.sipphone.com/university/>. Acesso em: out. 2005.
SIPPHONE. Disponvel em: <http://www.sipphone.com>. Acesso em: maio 2005.
SKYPE. Disponvel em: <http://www.skype.com>. Acesso em: mai. 2005.
SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de Computadores - Das LANs,
MANs e WANs s Redes ATM. [S.l.]: Campus, 1995.
SPEEX.ORG. Speex a free codec for free speech. Disponvel em:
<http://www.speex.org/>. Acesso em: out. 2005.
SPURGEON, C. E. Ethernet - O Guia Denitivo. [S.l.]: Campus, 2000.
STALLINGS, W. The Session Initiation Protocol. The Internet Protocol Jour-
nal, [S.l.], v.6, n.1, Mar. 2003. Disponvel em :<http://www.cisco.com/application/
pdf/en/us/guest/about/about/c644/ccmigration_09186a008044af45.pdf>. Acesso em:
ago. 2005.
STI. Disponvel em: <http://www.informatec-sp.com/>. Acesso em: out. 2005.
TAKAHASHI, A.; YOSHINO, H.; KITAWAKI, N. Perceptual QoS Assessment Techno-
logies for VoIP. IEEE Communications Magazine, [S.l.], July 2004.
TANENBAUM, A. S. Redes de Computadores. 4.ed. [S.l.]: Campus, 2003.
TCPDUMP. TCPDUMP public repository. Disponvel em:
<http://www.tcpdump.org/>. Acesso em: set. 2005.
VARSHNEY, U. et al. Voice over IP. ACM Communications, [S.l.], v.45, n.1, Jan. 2002.
WALLINGFORD, T. Switching to VoIP. [S.l.]: OReilly, 2005.
112
APNDICE A GRFICOS POR SEGMENTO
Grcos por segmento, dos resultados das medies com 50% de acrscimo no vo-
lume de trfego e 50% de acrscimo no nmero de ramais.
Figura A.1: Grco das ligaes do segmento da Reitoria, com 50% a mais de trfego e
de ramais.
113
Figura A.2: Grco das ligaes do segmento do Campus II, com 50% a mais de trfego
e de ramais.
Figura A.3: Grco das ligaes do segmento da Escola de Informtica, com 50% a mais
de trfego e de ramais.
114
Figura A.4: Grco das ligaes do segmento do Prdio dos DAs, com 50% a mais de
trfego e de ramais.
Figura A.5: Grco das ligaes do segmento da Central de Atendimento, com 50% a
mais de trfego e de ramais.
115
Figura A.6: Grco das ligaes do segmento da Contabilidade, com 50% a mais de
trfego e de ramais.
Figura A.7: Grco das ligaes do segmento do Backbone, com 50% a mais de trfego
e de ramais.

Planejamento Capacidade Voip

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Planejamento Capacidade Voip

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

S-ar putea să vă placă și