ALEX GALHANO R OBERTSON

I MPLANTANDO UM SERVIO DE TELEFONIA IP

EM EMPRESAS DE GRANDE E MDIO PORTE

NITERI, RJ MARO/ 2010

ALEX GALHANO R OBERTSON

I MPLANTANDO UM SERVIO DE T ELEFONIA IP

EM EMPRESAS DE GRANDE E MDIO PORTE

Dissertao de Mestrado apresentada ao Departamento de Engenharia de Telecomunicaes da Escola de Engenharia da Universidade Federal Fluminense como requisito para obteno do ttulo de Mestre em Engenharia de Telecomunicaes. rea de concentrao: Sistemas de Telecomunicaes: Engenharia de Redes de Telecomunicaes.

Orientador: Professor Doutor Carlos Alberto Malcher Bastos

NITERI, RJ MARO/ 2010

ii

iii

iv

DEDICATRIA

Dedico este trabalho minha famlia. minha esposa, Tatiane, que compreendeu a importncia dos momentos em que a submetia solido, mesmo estando sempre ao meu lado. minha filha, Ana Lusa, que, apesar de sempre desviar minha ateno durante o trabalho, renovava minhas energias.

Ao meu filho, Ian, que, desde que estava no ventre da me, fez aumentar o estmulo para terminar e defender a dissertao o quanto antes.

AGRADECIMENTO
Primeiramente agradeo a Deus e seus anjos.

Agradeo minha famlia. Minha esposa Tatiane, minha filha Ana Lusa e meu filho Ian. Eles so meu alicerce, minha fora, minha energia. Sem o apoio, a participao e a compreenso da famlia nada seria possvel. Agradeo minha me, Dulcimara, que, alm da tima educao que deu, cumpriu bem o papel da me-coruja. Contava orgulhosa para as pessoas que o filho estava no Mestrado. No poderia decepcion-la. Agradeo minha sogra Roseli e a minha tia Maira, que sempre ajudaram muito, em todos os aspectos, proporcionando-me a tranqilidade para escrever. Agradeo minha irm, Aline, que mesmo participando com certa distncia, me inspirava a ser um exemplo positivo. Agradeo ao meu orientador, Carlos Alberto Malcher Bastos, que se props a direcionar minha caminhada neste trecho da jornada. Agradeo FIRJAN e RNP por permitirem utilizar o trabalho realizado em suas dependncias como estudo de caso nesta dissertao. Por ltimo, mas no menos importante, agradeo a todos os professores, amigos e colegas de trabalho e de estudo que sempre me apoiaram na hora certa.

vi

SUMRIO

LIS TA D E FIGURAS ..........................................................................................................x LIS TA D E TABELAS ....................................................................................................... xii LIS TA D E ABREVIATURAS E S IGLAS

............................................................................ xiii

RESUMO ..................................................................................................................... xv ABSTRACT ................................................................................................................ xvi Captulo 1 Introduo...................................................................................................... 17 Por que implantar Telefonia sobre IP?............................................................................. 19 Por que nas grandes e mdias empresas e no nas pequenas? ......................................... 21 Por que este trabalho importante?............................................................................... 21 Objetivo ........................................................................................................................ 22 Estruturao do trabalho................................................................................................ 22 Captulo 2 Evoluo e tecnologia de suporte..................................................................... 24 Mundo tradicional ......................................................................................................... 24 Telefonia Analgica .................................................................................................... 24 Telefonia Digital ......................................................................................................... 31 Mais sobre telefonia e padronizao ........................................................................... 32 Circuitos Vs. Pacotes ...................................................................................................... 33 Comunicao com comutao de circuitos................................................................... 33 Comunicao com comutao de pacotes.................................................................... 34 Redes IP (Internet Protocol)............................................................................................ 34 Captulo 3 Entendendo VoIP ............................................................................................ 38 VoIP vs. ToIP .................................................................................................................. 38 Protocolos para VoIP...................................................................................................... 38 H.323......................................................................................................................... 39

vii

SIP............................................................................................................................. 44 Comparao SIP x H.323 ............................................................................................. 48 Transporte da mdia....................................................................................................... 49 O que RTP?.............................................................................................................. 49 Digitalizao e codificao da voz ................................................................................... 50 CODECs...................................................................................................................... 50 Outras Consideraes .................................................................................................... 59 Fornecimento de energia eltrica................................................................................ 59 IAX2: Um novo protocolo ............................................................................................ 61 Captulo 4 QoS para Telefonia sobre IP ............................................................................. 65 O que QoS?................................................................................................................. 65 Parmetros importantes ............................................................................................. 66 Sobre enlaces congestionados..................................................................................... 67 Modelos de QoS ............................................................................................................ 70 IntServ Integrated Services....................................................................................... 70 DiffServ Differentiated Services ................................................................................ 71 Medindo o QoS.............................................................................................................. 76 Mean Opinion Score ................................................................................................... 76 O modelo-E................................................................................................................ 77 Qualidade dos CODECs................................................................................................... 78 Ensaio sobre a relao entre CODECs e perda de pacotes ............................................. 79 Captulo 5 Medies, Monitoramento e Gerncia de Redes............................................... 83 Introduo .................................................................................................................... 83 Medies ...................................................................................................................... 83 Medies Ativas ......................................................................................................... 84 Medies Passivas...................................................................................................... 85

viii

Monitoramento............................................................................................................. 86 O que monitorar ........................................................................................................ 87 O que monitorar VoIP .............................................................................................. 88 Sistemas de monitoramento........................................................................................... 88 SNMP............................................................................................................................ 89 Gerncia........................................................................................................................ 91 Modelos de Gerncia.................................................................................................. 92 Sistemas de Gerncia de Redes ................................................................................... 94 Algumas caractersticas dos NMS ................................................................................ 94 Que ferramenta utilizar .............................................................................................. 99 Captulo 6 Adotando a Telefonia sobre IP ........................................................................103 Introduo ...................................................................................................................103 Antes de comear .........................................................................................................104 VoIP realmente necessrio? ....................................................................................104 Consideraes iniciais................................................................................................104 Planejamento ...............................................................................................................105 Definio do escopo ..................................................................................................105 Dimensionamento.....................................................................................................106 Fornecedores de conectividade..................................................................................107 Parceiros...................................................................................................................108 Plano de numerao e discagem ................................................................................108 Recursos humanos ....................................................................................................109 Preparao da infra-estrutura ....................................................................................109 Tecnologia e fornecedores .........................................................................................110 Novas aquisies.......................................................................................................111 Gerncia da rede .......................................................................................................112

ix

Problemas em ToIP .......................................................................................................113 Evite problemas desde o planejamento ......................................................................113 Problemas da fase de operao..................................................................................115 Captulo 7 Casos prticos................................................................................................122 Projeto Piloto FIRJAN GTECCOM / UFF.........................................................................122 Apresentao............................................................................................................122 O ambiente ...............................................................................................................123 O Projeto Piloto.........................................................................................................126 Descrio das solues dos fornecedores ...................................................................127 Testes do Projeto Piloto.............................................................................................128 Estudo sobre a homogeneidade da rede .....................................................................131 O plano de Migrao .................................................................................................136 Problemas encontrados e lies aprendidas................................................................139 O contra-ataque da operadora de telefonia ................................................................139 Concluso .................................................................................................................140 Servios Digitais para Sade RNP.................................................................................141 Apresentao............................................................................................................141 O servio fone@MS...................................................................................................141 O ambiente ...............................................................................................................142 Proposta de soluo ..................................................................................................145 Treinamento .............................................................................................................152 ltimas consideraes...............................................................................................152 Captulo 8 Concluso......................................................................................................154 Prximos trabalhos .......................................................................................................155 Referncias ..................................................................................................................156

LISTA DE FIGURAS Figura 1: Representao do circuito telefnico. .................................................................... 25 Figura 2: Ilustrao bem humorada do antes e depois da rede telefnica. ............................... 25 Figura 3: Cabeamento telefnico em St. Louis, Missouri, em 1900........................................ 26 Figura 4: Centrais de comutao operadas manualmente. ..................................................... 27 Figura 5: Telefonista em central de pegas. ........................................................................... 27 Figura 6: Topologia da rede telefnica atual. ....................................................................... 28 Figura 7: Central de comutao automtica dos anos 50. ...................................................... 29 Figura 8: Detalhe de um comutador eletro-mecnico de barras cruzadas. ............................... 29 Figura 9: Rede mundial de cabos submarinos e satlites. ..................................................... 30 Figura 10: Primeiro telefone mvel russo. ........................................................................... 30 Figura 11: Evoluo dos aparelhos mveis. ......................................................................... 30 Figura 12: Telefone digital. ................................................................................................ 31 Figura 13: Arquitetura OSI x Arquitetura TCP/IP ................................................................ 36 Figura 14: Zona H.323 e seus elementos.............................................................................. 40 Figura 15: Exemplo de chamada H.323 ............................................................................... 42 Figura 16: Exemplo de arquitetura SIP. ............................................................................... 45 Figura 17: Exemplo de chamada SIP. .................................................................................. 47 Figura 18: Encapsulamento da voz codificada...................................................................... 50 Figura 19: Codificao PCM .............................................................................................. 53 Figura 20: Compresso de cabealho .................................................................................. 68 Figura 21: Fragmentao e interposio .............................................................................. 69 Figura 22: Bloco de Condicionamento de Trfego (TBC Traffic Conditioner Block) ............ 72

xi

Figura 23: Cabealho IP antes e depois do DiffServ. ............................................................ 73 Figura 24: Relao entre DSCP e IP Precedence, em ordem crescente de prioridade............... 74 Figura 25: Esquema do laboratrio de tolerncia a perda de pacotes. ..................................... 81 Figura 26: MIB: rvore de objetos ..................................................................................... 91 Figura 27: Associao entre ITIL e NMS ............................................................................ 93 Figura 28: Viso do todo (overview), histrico e alguns detalhes .......................................... 95 Figura 29: Alarmes correlacionados .................................................................................... 96 Figura 30: Rede de dados separada da rede de voz antes da convergncia. ............................124 Figura 31: Redes de dados e voz durante o processo de convergncia. ..................................125 Figura 32: Rede de voz e dados aps a convergncia. ..........................................................126 Figura 33: Fluxo financeiro do plano de migrao: arquitetura homognea. ..........................137 Figura 34: Fluxo Financeiro do Plano de Migrao: Arquitetura Heterognea. ......................138 Figura 35 Rede Infosus, do Datasus. ..................................................................................143 Figura 36 Firewall entre sede e LAN nas unidades ..............................................................144 Figura 37 Soluo de arquitetura do servio fone@MS .......................................................146 Figura 38 Ligao com PABX digital.................................................................................147 Figura 39 Ligao com PABX analgico. ...........................................................................147 Figura 40 Ligao com PABX virtual. ...............................................................................148 Figura 41 Ligao sem PABX. ..........................................................................................148 Figura 42 Ligao para as secretarias. ................................................................................149 Figura 43 Detalhamento do ambiente local redundante ........................................................150 Figura 44 Exemplo da interface de gerncia do sistema. Viso geral. ...................................151

xii

LISTA DE TABELAS Tabela 1: Comparao entre CODECs. ............................................................................... 58 Tabela 2: Tamanho do fragmento de acordo com a velocidade do acesso............................... 70 Tabela 3: Escala de qualidade/degradao ........................................................................... 77 Tabela 4: Relao entre Fator-R, MOS e a satisfao do usurio ........................................... 78 Tabela 5: Atraso (em milissegundos) para traduo entre CODECs....................................... 79 Tabela 6: Taxa de perda de pacotes em que a voz torna-se incompreensvel........................... 82 Tabela 7: Comparao entre NMS'es de cdigo aberto ........................................................101 Tabela 8: Problemas, causas e solues em VoIP ................................................................116 Tabela 9: Tabela comparativa de ambientes quanto a heterogeneidade. ................................134

xiii

LISTA DE ABREVIATURAS E SIGLAS AF BE ATA ATM CDMA COBIT CODEC CPA CRM DCR DECT DNS DMZ DTMF EF EMS ERP ETSI FCAPS GK GPRS GPS GW HMM IAX IP ISDN ISF ITIL ITSP ITU LAN LDAP LLQ MCU MFC MIB MOS NMS NTP PABX PoE POTS Assured Forward Best Effort Analog Telephone Adapter Asynchronous Transfer Mode Code Division Multiple Access Control Objectives for Information an related Technology COder-DECoder Central de Programa Armazenado Customer Relationship Management Degradation Category Rating Digital Enhanced Cordless Telecommunications Domain Name System DeMilitarized Zone Dual-Tone Multi Frequency Expedit Forward Enterprise Management Systems Enterprise Relationship European Telecommunications Standards Institute Fault, Configuration, Accounting, Performance, Security Gatekeeper General Packet Radio Service Global Positioning System Gateway Hora de Maior Movimento InterAsterisk Exchange Internet Protocol Integrated Services Digital Network Information Security Forum Information Technology Infrastructure Library Internet Telephony Service Provider International Telecommunications Union Local Area Network Lightweight Directory Access Protocol Low Latency Queue Multipoint Control Unit Multifrequencial Compelida Management Information Base Mean Option Score Network Management System Network Time Protocol Public Automatic Branch Exchange Power over Ethernet Public Old Telephony System

xiv

PPP PSTN QoS RAM RDSI RFC RR RTP SDP SIP SLA SMS SNMP SoGP SP STFC TDM TEF TIC TMN ToIP UPS URI VAD VoIP VPN WAN WFQ WRR WWW

Point-to-Point Protocol Public Switched Telephony Network Quality of Service Random Access Memory Rede Digital de Servios Integrados Request for Comments Round Robin Real-time Transport Protocol Session Description Protocol Session Initiation Protocol Service Level Agreement Short Message Service Simple Network Management Protocol Standards of good Practices Strict Priority Sistema de Telefonia Fixa Comutada Time Division Multiplexing Transferncia Eletrnica de Fundos Tecnologia da Informao e Comunicao Telecommunications Management Network Telephony over IP Uninterruptible Power System Uniform Resource Identifier Voice Activity Detection Voice over IP Virtual Private Network Wide Area Network Weighted Fair Queuing Weighted Round Robin World Wide Web

xv

RESUMO
Esta dissertao trata da implantao do servio de telefonia IP em empresas de mdio e grande porte. Traz informaes sobre a evoluo do servio de telefonia, contextualizando o servio de telefonia IP com a evoluo da tecnologia. Trata de assuntos fundamentais ao entendimento do servio, tais como VoIP e seus protocolos, QoS, medio, monitoramento e gerncia de redes e servios IP. Tambm apresenta dois estudos de caso de projetos de implantao de telefonia IP em grandes redes. Apresenta tambm uma metodologia de planejamento que pretende auxiliar profissionais a implantar e manter um servio de telefonia IP de qualidade. Palavras-chave: Telefonia sobre IP, Voz sobre IP, Grande empresa, Mdia empresa, Telefonia, VoIP

xvi

ABSTRACT
This dissertation is about IP telephony service deployment in medium and large companies. It brings information about the telephony service evolution in the context of IP telephony service and technological evolution. It deals with fundamentals issues for the service comprehension, as VoIP and its protocols, QoS, measurement, mo nitoring and managing IP services networks. It also shows two cases of IP telephony deployment projects in huge IP networks. It also presents a planning methodology that intends to help professionals to deploy and maintain IP telephony services with good acceptable quality.

Keywords: Telephony over IP, Voice over IP, Large Business, Medium Business, Telephony, VoIP

17

Captulo 1 Introduo
No mais novidade que os servios de telecomunicaes esto convergindo e, em grande parte, j esto funcionando sobre a rede IP. Voz, vdeo e mensagens instantneas j trafegam sobre a rede de pacotes h algum tempo na Internet. Entretanto, o pblico alvo era o usurio residencial e o enfoque era simples: bastava que o servio funcionasse, no importando muito a qualidade das chamadas. Aos poucos, esses mesmos usurios residenciais comearam a levar para as empresas o hbito de falar com outras pessoas utilizando o computador, uma ferramenta comum em qualquer ambiente hoje em dia. Empresas de todos os tamanhos comearam a entender que a rede IP no serve apenas para navegar na Internet, trocar emails e acessar o servidor de arquivos. Elas descobriram que possvel reduzir custos de tecnologia da informao e telecomunicaes (TIC), agregando novos servios em uma infra-estrutura comum, especialmente servios de voz. Prova disso, so as vrias reportagens publicadas freqentemente em revistas especializadas. Com forte apelo na reduo de custos, a tecnologia de Voz sobre IP vem ganhando espao nas empresas de forma vertiginosa. No entanto, as promessas de ligaes a custo zero, normalmente sem muito compromisso com a qualidade e continuidade do servio, acabaram causando um efeito colateral que faz crescer a idia que a tecnologia VoIP ruim, trazendo alguma resistncia a sua adoo. Ainda assim, a economia gerada com a implantao de um sistema de telefonia IP muito atraente e o interesse pela tecnologia no cessou. Outro fator que provocou um aumento da popularidade da tecnologia IP foi a cultura de Cdigo Aberto, cuja premissa conseguir melhor qualidade, melhor confiabilidade, mais flexibilidade, menor custo e fim da dependncia de fabricantes (1). Existe hoje disponvel para qualquer pessoa uma infinidade de programas e sistemas computacionais para os mais diversos propsitos. De acordo com a GPL (General Public License), a Licena do Cdigo Aberto (2) e com a definio de Cdigo Aberto (3), possvel adaptar os programas para utiliz-los de acordo com as necessidades individuais de cada pessoa ou empresa, desde que acompanhado de seu cdigo- fonte. A gama de programas enorme e passa por editores de texto, planilhas eletrnicas,

18

servidores http, web browsers, servidores e clientes de email, Sistemas de Gerncia de Projetos, Sistemas de Documentao, CRMs, ERPs e muitos outros 1 . Mais especificamente como alvos desta dissertao, notveis softwares livres so os PABX IP e os programas de telefones IP, os softphones. Eles esto alavancando o mercado de Telefonia IP. O crescimento de interesse na rea de Voz sobre IP gera oportunidades para muitas empresas. Por exemplo, os fabricantes de PABX tradicionais agora vem no IP uma forma de conquistar (e reconquistar) mais clientes. Todos oferecem modelos de PABX hbridos ou totalmente IP. Neste contexto, surgem tambm pequenos fabricantes de hardware. Dispositivos como ATAs (Analog Telephony Adapter), gateways e telefones IP esto sendo produzidos por diversos fabricantes em todo o mundo. A boa quantidade de fabricantes gera concorrncia, que pressiona os preos para baixo. E como numa bola de neve, a popularidade da tecnologia faz aumentar o interesse nela. Os fabricantes, por sua vez, enxergam o interesse como oportunidade de negcio e produzem mais dispositivos. A quantidade de dispositivos no mercado faz diminuir os preos e o custo de implantao de um sistema de voz sobre IP. O baixo custo faz aumentar ainda mais o interesse e a popularidade do VoIP. Neste processo, o grande interesse pela tecnologia faz aumentar tambm a necessidade de servios de implantao e migrao para VoIP. Para suprir essa demanda, surgem profissionais e pequenas empresas de consultoria, mas, infelizmente, muitos esto despreparados tanto tecnicamente quanto administrativamente. Visto de outra forma, existe hoje uma grande demanda por mo-de-obra qualificada e realmente especializada em Voz sobre IP, o que pode ser entendido como mais uma oportunidade. O fraco preparo tcnico de profissionais e empresas um componente negativo e faz fora em sentido contrrio ao movimento de adoo da telefonia IP. O despreparo de alguns profissionais faz com que as empresas que demandam seus servios desacreditem da tecnologia. A promessa de fazer tudo por um preo relativamente irrisrio e com retorno muito rpido deixa de ser um atrativo e comea a passar a idia

Um exemplo de repositrio de softwares de cdigo aberto SourceF orge.net, em http://sourceforge.net/

1

19

de amadorismo e falta de qualidade. De fato, possvel fazer quase tudo com sistemas abertos de telefonia e hardware adequado. Entretanto, esses profissionais despreparados negligenciam caractersticas de extrema importncia para um Sistema de Telefonia IP: qualidade, segurana, gerncia, interoperabilidade e continuidade do servio. Felizmente o mercado est amadurecendo. As empresas esto mais atentas e aprendendo a diferenciar os profissionais atuantes nesta rea. A iluso do custo zero comea a dar lugar a implementaes mais estruturadas e concisas, que contemplam as condies necessrias para um servio de qualidade e que permitem a modernizao e o crescimento sustentvel do servio de telecomunicaes nas empresas.

Por que implantar Telefonia sobre IP?

A implantao da telefonia sobre IP, ou simplesmente telefonia IP, pode trazer grandes vantagens para uma empresa, mas seu custo de implantao pode ser relativamente alto. Telefones IP so bem mais caros que telefones convencionais. Algumas vezes, pode ser necessrio adquirir novos equipamentos de rede. No basta mais que a rede IP funcione; ela precisa funcionar bem. A gerncia da rede IP pode se tornar mais complexa. necessrio contratar profissionais que conheam a tecnologia ou treinar os funcionrios atuais. preciso investir na alimentao dos telefones, seja com switches com Power over Ethernet, injetores centralizados ou simplesmente instalando mais uma tomada em cada estao de trabalho. Por outro lado, a telefonia IP pode reduzir drasticamente o custo com telecomunicaes. As opes variam desde contratar um tronco com um Provedor de Servios de Telefonia (ITSP Internet Telephony Service Provider), at migrar completamente o parque de equipamentos de telefonia. A alternativa mais comum modernizar o ncleo da rede de telefonia adotando a tecnologia VoIP para as ligaes de longa distncia entre filiais distantes e manter os PABX locais e os ramais j existentes com telefones analgicos. Esta abordagem garante economia nas ligaes de longa distncia e desonera a empresa dos altos custos dos telefones IP e outros itens da infraestrutura de redes, aproveitando ainda o ltimo investimento realizado no parque

20

de telefonia de cada localidade. No entanto, as vantagens da adoo da telefonia IP vo alm da questo econmica. Aps a adoo desta tecnologia, mesmo que parcialmente como descrito anteriormente, possvel realizar ligaes entre as localidades da empresa como se todos estivessem no mesmo prdio, no importa se a localidade remota e st em outra cidade, estado ou pas. Basta digitar o ramal de 4 ou 6 dgitos do colega de trabalho. Somado a reduo de custos, a telefonia IP facilita muito a criao de novas funcionalidades e servios como correio de voz, secretria eletrnica, integrao com banco de dados, etc. Se for utilizado um PABX proprietrio, h de se incluir nas despesas os altos preos das licenas de cada funcionalidade. Se a opo for por um PABX de cdigo aberto, possvel utilizar toda a tecnologia disponvel sem os altos custos das licenas, implantao e manuteno. A utilizao de telefonia IP facilita o tele-trabalho, trabalho remoto a partir de casa ou de qualquer outro ambiente conectado a Internet. O tele-trabalho uma tendncia hoje em dia. No importa onde o profissional esteja, ele sempre est virtualmente na empresa. Alm das facilidades das aplicaes, como acessar servios de dados da empresa como se estive l, ele recebe e faz ligaes normalmente, tambm como se estivesse em sua mesa de trabalho. No importa se est em seu escritrio, em casa ou numa viajem para outro pas, o tele-trabalhador estar sempre na empresa. No caso da utilizao de telefones IP, quando no se aproveita a infra-estrutura de telefonia j instalada, possvel mover seu ramal simplesmente tirando seu telefone da tomada e religando-o em outra. No mais necessrio reconfigurar a central telefnica ou trocar fios no bastidor. Mais que isso, o profissional pode at se tornar um tele-trabalhador sem a necessidade de reconfigurao da central. Cada empresa possui suas particularidades. Assim, funcionalidades que so imprescindveis para um tipo de negcio podem ser totalmente dispensveis para outro. preciso conhecer as necessidades de cada empresa e, principalmente, conhecer a tecnologia de Telefonia sobre IP para poder avaliar e adequar as necessidades de cada um s capacidades da tecnologia.

21

Nesta dissertao so apresentadas as caractersticas da tecnologia VoIP. Cabe ao interessado na adoo da tecnologia associar as caractersticas ao seu negcio e avaliar a possibilidade de implantao.

Por que nas grandes e mdias empresas e no nas pequenas?

Implementaes mais simples conseguem atender s necessidades das micro e pequenas empresas que utilizam a tecnologia de voz sobre IP. Alm disso, por serem pequenas, muitas dessas empresas no so totalmente beneficiadas pela tecnologia por no possurem filiais ou por no investirem adequadamente na sade de suas redes, causando problemas nas ligaes. Infelizmente, as pequenas empresas que procuram solues de Voz sobre IP tambm apresentam pouca preocupao com qualidade nas chamadas, seja pela incapacidade de financiar um projeto mais robusto, ou por simples negligncia. Por outro lado, as mdias e grandes empresas, normalmente possuem es critrios geograficamente distribudos, s vezes em mais de um pas. Alm disso, a despesa com comunicao interna delas justifica o investimento em uma soluo robusta de comunicao, quase sempre utilizando a rede IP que elas j possuem para integrao das solues de voz, vdeo, texto e dados. As grandes empresas normalmente apresentam preocupaes com qualidade e disponibilidade do servio e tendem a procurar solues proprietrias e, para sua segurana, contratam SLAs (Service Level Agreement) rgidos. As mdias empresas procuram o mximo de economia com o mnimo de investimento, mas tambm se preocupam com um servio estvel. Essas esto mais receptivas a solues de cdigo aberto e procuram contratar profissionais capacitados.

Por que este trabalho importante?

Este trabalho documenta a experincia prtica, tcnica e gerencial em execuo de diagnsticos e projetos de implantao de servio de telefonia IP de casos reais, normalmente guardados a sete chaves como informao estratgica das empresas. Ele tambm trata de forma acessvel o embasamento terico que justifica as

22

escolhas feitas para a construo do roteiro. Aponta equvocos freqentemente cometidos nos projetos de implantao de Telefonia IP e indica aes corretivas e preventivas. Portanto, o trabalho importante porque unifica os conhecimentos conceituais com a expericia prtica. Alm disso, organiza as lies aprendias e as melhores prticas conhecidas em indicaes que podem ser utilizadas por profissionais interessados em implantar e gerenciar um sistema de Telefonia IP.

Objetivo
O objetivo especfico e principal deste trabalho construir uma metodologia acerca da implantao e operao de servios de Telefonia IP em empresas de grande e mdio porte. Este roteiro visa auxiliar gestores e administradores de rede a instalar e manter um servio competitivo, sustentvel e de qualidade, mantendo uma infraestrutura de redes adequada, de forma a garantir a continuidade do servio. A construo desta metodologia baseada em conhecimentos tericos e prticos e em experincias realizadas no decorrer do curso de Mestrado. A metodologia ser confrontada e validada com o auxlio de 2 casos prticos apresentados aqui. Esta dissertao ainda possui um objetivo geral, que sensibilizar profissionais e empresas sobre a necessidade da prestao de um servio de qualidade, mesmo sem os altos custos de solues proprietrias. No decorrer do texto so apresentados fatos e experincias que mostram que possvel prestar um servio de qualidade e com baixo custo utilizando programas de cdigo aberto.

Estruturao do trabalho
Este documento est disposto conforme a descrio a seguir. O captulo 1, Introduo, contextualiza a problemtica dos servios de Telefonia IP e apresenta a motivao e o objetivo deste trabalho, bem como sua estrutura. O captulo 2, Evoluo e tecnologia de suporte, contextualiza tecnicamente a proposta de trabalho. Apresenta de forma sucinta a evoluo do servio de telefonia.

23

Explica a diferena entre as redes tradicionais orientadas a circuitos e as redes IP orientadas a pacotes. O captulo 3, Entendendo VoIP trata dos protocolos de Voz sobre IP e toda teoria necessria para seu funcionamento, apresentando CODECs, protocolos e servios complementares para a viabilizao da Telefonia IP. O captulo 4, QoS para Telefonia IP, trata a questo da qualidade nas redes IP e especificamente a qualidade em VoIP, informando sobre maneiras de se qualificar objetiva e subjetivamente as chamadas. Apresenta tambm um ensaio prtico sobre CODECs realizado no decorrer do curso. O captulo 5, Medies, Monitoramento e Gerncia, aborda questes relativas a manuteno e operao do servio de telefonia IP e indica o que deve ser feito para se garantir a continuidade na prestao de um servio de qualidade. O captulo 6, Adotando a Telefonia IP, a materializao do objetivo desta dissertao, tratando da metodologia para planejamento da implantao e manuteno do Sistema de Telefonia IP. Aborda alguns equvocos comuns e como evit-los. O captulo 7, Casos Prticos, apresenta dois estudos de caso sobre a adoo do servio de telefonia IP em grandes ambientes: um com cerca de 50 unidades remotas no estado do Rio de janeiro, outro com alcance nacional. Traz informaes desde o estudo de viabilidade at a estratgia de migrao e implantao. O objetivo dos estudos de caso validar a metodologia apresentada no captulo anterior. Finalmente, o captulo 8 faz a concluso do trabalho, indicando os resultados e enumerando possveis prximos trabalhos nesta linha.

24

Captulo 2 Evoluo e tecnologia de suporte

Este captulo apresenta alguns fatos histricos para contextualizao e conceitos bsicos do ambiente de telefonia tradicional. Apresenta algumas diferenas notveis entre redes de circuitos e de pacotes e apresenta os desafios a serem enfrentados por sistemas de Telefonia IP.

Mundo tradicional
Telefonia Analgica
Alexander Graham Bell solicitou a patente do telefone 2 em 20 de janeiro de 1876 (4). No entanto, existem controvrsias a respeito do real inventor do aparelho. J em 26 de agosto de 1854, portanto mais de 20 anos antes, foi publicado o primeiro artigo sobre telefonia intitulado A transmisso eltrica da fala, escrito por Charles Bourseul. Deixando de lado as discusses sobre a paternidade da telefonia, desde sua inveno at a era digital, no houve muitas mudanas na forma de transportar a voz de um ponto ao outro. O esquema bsico para que um aparelho telefnico pudesse se comunicar com outro aparelho sempre foi modelado com um circuito eltrico. De fato, o conjunto de telefones e fios realmente forma um circuito eltrico fechado, conforme ilustrado na figura 1.

Uma cpia da patente, pode ser encontrada no site About.com, no endereo http://inventors.about.com/ od/tstartinventions/ss/TelephonePatent.htm
2

25

Figura 1: Representao do circuito telefnico. http://www.privateline.com/archive/howteleworks.gif Inicialmente, um par de fios ligava dois telefones. Se um destes quisesse falar com outro ponto, outro par de fios era lanado entre ele e o novo participante. Logo se percebeu que esta arquitetura de rede no era adequada, pois era de difcil expanso. A figura 2 mostra de forma bem humorada uma rua hipottica de Nova York em 1910 e vinte anos depois. Vale ressaltar que nesta poca o cabeamento telefnico j estava no subsolo.

Figura 2: Ilustrao bem humorada do antes e depois da rede telefnica. http://www.uh.edu/engines/nycandwires.jpg

26

A figura 3 uma fotografia real, tirada em 1900, e mostra como era a estrutura de cabeamento telefnica em St. Luis, Missouri, nos Estados Unidos.

Figura 3: Cabeamento telefnico em St. Louis, Missouri, em 1900. http://www.corbisimages.com/Enlargement/Enlargement.aspx?id=IH158454&tab=det ails&caller=search

A topologia da rede integralmente em malha mostrou-se no escalvel. Ento, foram desenvolvidas as primeiras centrais de comutao (ou mesas telefnicas), operadas pelo homem, conforme ilustrado nas figuras 4 e 5. Os terminais telefnicos se ligavam a esta central, que se ligava com outros telefones e a outras centrais.

27

Figura 4: Centrais de comutao operadas manualmente. http://www.siongboon.com/projects/2006-06-19_switch/1910telephoneexchange.jpg

Figura 5: Telefonista em central de pegas. http://www.jackson.army.mil/Museum/History/pix/image305.jpg

A nova topologia era um misto de malha no ncleo e estrela nas bordas, prximo aos terminais telefnicos. A arquitetura na Figura 6 ilustra esta arquitetura mista, onde possvel identificar um ncleo em malha formando uma estrela de novas malhas

28

intermedirias que, no acesso, volta a formar estrelas para alcanar o usurio final.

Figura 6: Topologia da rede telefnica atual. http://www.inetdaemon.com/tutorials/telecom/pstn/visual_guide.shtml Depois de algum tempo e algumas idias intermedirias, os telefones ganharam teclas que podiam ser usadas para alcanar endereos especficos na rede de telefonia e as centrais foram se tornando automticas, com comutao dos circuitos sendo executadas por rels. Ao mesmo tempo em que as telefonistas iam perdendo seus empregos, maior quantidade de telefones podia usar o sistema. A seguir a Figura 7 ilustra a comparao de tamanho entre uma central dos anos 50 em relao altura de um homem. A Figura 8 mostra o detalhe de um comutador de barras cruzadas.

29

Figura 7: Central de comutao automtica dos anos 50. http://www.international-phonecard.info/images/telephone_history/lewisxy.jpg

Figura 8: Detalhe de um comutador eletromecnico de barras cruzadas. http://people.seas.harvard.edu/~jones/csci e129/nu_lectures/lecture11/switching/xbar/ xbar_7a.jpg

Para tornar a automao de ligaes telefnicas possvel, era necessrio criar um cdigo que todos os telefones e centrais entendessem. Algumas tentativas de construir um protocolo de sinalizao foram experimentadas. Algumas usavam 8 ou 7 fios que foram deixadas de lado para dar lugar a protocolos que utilizam 2 fios por assinante. Normalmente, a sinalizao analgica utiliza a janela de freqncias que o ouvido humano capaz de perceber e pode ser realizada utilizando os mesmos fios que a voz utiliza. Por isso possvel ouvir os tons de controle como ocupado e chamando, os pulsos produzidos ao se discar um nmero em telefones mais antigos e, mais atualmente, o DTMF (Dual Tone Multi-Frequency), utilizado para enviar para a central os dgitos de 0 a 9 mais * e #. Em 1927, a primeira chamada de voz transatlntica foi feita utilizando ondas de rdio. Inovaes durante as duas Grandes Guerras fizeram surgir os primeiros telefones mveis.

30

Figura 9: Rede mundial de cabos submarinos e satlites. http://meiobit.com/wp-content/uploads/teleglobe_large_2.gif Nos anos 60, os telefones passavam a ser endereados apenas por caracteres numricos e os primeiros cabos transatlnticos eram lanados para possibilitar as ligaes intercontinentais. Tambm em 1962, foi lanado o primeiro satlite para telefonia. A Figura 9 detalha um mapa com cabos submarinos e o posicionamento de satlites em rbita na Terra. Ainda na era analgica, surgiu tambm a telefonia celular. Assim como no incio do surgimento dos telefones fixos, os telefones celulares eram caros e pouco eficientes. A seguir, as Figuras 10 e 11 ilustram exemplos de telefones mveis.

Figura 10: Primeiro telefone mvel russo. http://englishrussia.com/images/ce llular1.jpg

Figura 11: Evoluo dos aparelhos mveis. http://jurmo.us/log/wpcontent/uploads/2007/02/ancient_mobile_p hones.jpg

31

Hoje em dia, na maior parte do Brasil, apenas as ligaes entre o assinante residencial e a central da rede fixa analgica. Nas empresas, semelhante situao do assinante residencial, a ligao dos ramais ao PABX tambm feita de forma analgica na grande maioria das vezes.

Telefonia Digital
Aps alguns anos, a tecnologia digital evoluiu e se mostrou mais confivel, mais econmica e mais eficiente que a analgica. A transmisso digital de dados comeo u a substituir a tecnologia analgica. Hoje, para ligao entre centrais telefnicas, normalmente se utiliza tecnologia digital. Os tons de controle, mensagens de linha, os dgitos e at a voz so agora enviados entre as centrais utilizando bits. No co mum no Brasil, mas tambm possvel utilizar comunicao digital entre um telefone residencial e a sua central. Nas empresas, a situao semelhante: telefones digitais so usados para um nmero reduzido de funcionrios, pois eles so mais caros e poucas pessoas realmente precisam das funcionalidades adicionais suportadas por esses telefones.

Figura 12: Telefone digital. http://mz.abeltronica.com/shop_image_pt /product/c1373c31b534bb31ca581321180 f4d5d.jpg

A rede de telefonia cresceu e a tecnologia avanou. As centrais deixaram de ser

32

eletro- mecnicas e surgiram as CPAs, ou Centrais de Programa Armazenado, que so como computadores especializados em realizar a comutao das ligaes.

Conseqentemente, protocolos de sinalizao mais adequados foram desenvolvidos. Dentre eles pode-se destacar o Sistema de Sinalizao n 7, SS7 (da famlia ITU Q.7xx) muito utilizado entre as centrais das operadoras de telefonia e a Rede Digital de Servios Integrados, RDSI (ITU Q.931), ou ISDN em ingls, mais utilizado nas comunicaes entre centrais e PABX digitais dos assinantes. No Brasil, a sinalizao definida como padro para a comunicao entre a operadora e o assinante de tronco digital a R2-D/MFC-5C (Multi- frequencial Compelida) Prtica Telebrs SDT 210.110.703. Entretanto, vrias operadoras de telefonia oferecem para seus assinantes de troncos digitais o protocolo ISDN, que mais moderno e mais rpido. Tambm a rede de telefonia celular evoluiu para uma rede digital. No Brasil, a ANATEL, Agncia Nacional de Telecomunicaes, chegou a marcar data, 30/06/2008, para o fim das operaes com celulares analgicos. Entretanto, a Agncia resolveu suspender a deciso. Em junho de 2008, aproximadamente 11 mil assinantes dos 130 milhes possuam celulares analgicos (5).

Mais sobre telefonia e padronizao

Independente da tecnologia (se analgico ou digital, se fixo ou mvel) algumas caractersticas devem ser observadas para garantir o mnimo de conforto para o usurio do sistema de telefonia. A ITU, International Telecommunications Union ou Unio Internacional de Telecomunicaes, especifica modelos e parmetros rgidos para o bom funcionamento da rede. Particularmente, a srie E trata da operao geral da rede, servio de telefonia, operao de servio e fatores humanos. A lista completa de recomendaes desta srie pode ser encontrada no endereo http://www.itu.int/rec/T-REC-E/e . Por exemplo, a conexo internacional de referncia se encontra na

recomendao E.830 (6). O pior caso do modelo apresentado neste documento admite a participao de at 15 centrais entre os participantes, sendo 5 centrais internacionais, 4

33

centrais nacionais e 2 centrais locais, uma de cada assinante. Idealmente, uma ligao internacional deveria ser composta de 1 central local, 1 central nacional e 1 central internacional para cada participante da ligao, totalizando 6 centrais entre os assinantes. O melhor caso prev apenas 6 equipamentos, sendo 1 central local, 1 nacional e 1 internacional para cada assinante.

Circuitos Vs. Pacotes

Comunicao com comutao de circuitos
Em uma comunicao entre dois pontos orientada a circuitos estabelecido um caminho nico e virtualmente contnuo entre os participantes. Em outras palavras, todos os recursos necessrios para a chamada so alocados antes do atendimento. Isso garante que uma chamada estabelecida em uma rede determinstica orientada a circuitos no corre o risco de sofrer degradao na qualidade da converso uma vez que esta tenha sido estabelecida. Na poca das redes analgicas e centrais de comutao operadas a rels, a ligao entre os dois pontos era, de fato, um circuito eltrico fechado entre os participantes. Hoje em dia, na era digital, pode-se dizer que, nessas redes determinsticas, para cada ligao estabelecido um circuito lgico entre os interlocutores. Ainda sobre redes digitais, uma vez que essas transportam bits, possvel fazer a primeira associao entre ligao telefnica e consumo de banda de transmisso como se fosse uma rede de dados. Na verdade, uma ligao telefnica no consome banda; ela ocupa um circuito de determinada velocidade. Por hora, basta saber que cada circuito alocado para uma ligao telefnica ocupa o equivalente a 64kbps de taxa de transmisso na rede TDM 3,4 . No prximo captulo, essa afirmao tecnicamente
Redes TDM tam bm designam as redes de Telefonia Digital. TDM (Time Division Multiplexing) - Multiplexao por Diviso de Tempo um a tcnica para transportar 30 ligaes digitais utilizando um nico meio de transmisso.
3 4

34

esclarecida.

Comunicao com comutao de pacotes

A maioria dos servios de dados da rede celular e a rede IP so orientados a pacotes. Isto significa que elas so redes estatsticas e se beneficiam dos longos perodos de silncio na comunicao. Redes orientadas a pacotes maximizam sua eficincia possibilitando que vrios usurios compartilhem os mesmos recursos de rede ao mesmo tempo. Ao contrrio, como j vimos anteriormente, uma rede orientada a circuitos aloca recursos de comunicao para apenas uma conversao. Por exemplo, quando algum est visitando uma pgina na Internet, s h dados trafegando na rede no momento em que a pessoa faz a requisio ao servidor web com trfego no sentido cliente para servidor e quando a pgina est sendo carregada com trfego no sentido servidor para cliente. Durante todo o tempo de leitura da pgina no existe trfego IP, permanecendo a rede desocupada, podendo ser utilizada por outros usurios. Da mesma forma, em uma conversao, enquanto um interlocutor fala, normalmente o outro permanece em silncio, escutando o primeiro. Este tempo de silncio pode ser utilizado para o trfego de outra ligao. Uma ligao telefnica tradicional manteria o circuito ocupado durante todo o tempo da chamada, mesmo que seus usurios estivessem em silncio.

Redes IP (Internet Protocol)

Tambm no mundo tecnolgico, a seleo natural exerce sua influncia. A criao do Computador Pessoal (PC) impulsionou a indstria de telecomunicaes e com isso a tecnologia de redes sofreu uma rpida evoluo. Novos materiais e novos protocolos surgiram e alguns desapareceram rapidamente. Por conta da combinao de alguns desses fatores externos e obviamente por suas caractersticas tcnicas, as redes IP se tornaram o padro para comunicao de dados, retirando do mercado outras tecnologias menos eficazes. Hoje em dia, a rede de pacotes mais utilizada sem dvida a rede IP.

35

O protocolo IP foi descrito pela RFC-791 (7) Internet Protocol em setembro de 1981. Foi atualizado pela RFC-1349 (8) Type of Service in the Internet Protocol suite que trata do Tipo de Servio de um pacote IP, utilizado para fins de QoS5 . A principal funo do protocolo IP o roteamento inter-redes, isto , interligar vrias redes diferentes. Sua arquitetura foi desenvolvida para ser independente da infraestrutura fsica ou lgica de outras redes e funcionar sobre elas, por exemplo, Ethernet, Frame Relay, ATM (Asynchronous Transfer Mode), PPP (Point-to-Point Protocol), etc. O protocolo IP completado por uma srie de outros protocolos que definem vrios servios suportados pela rede (web, email, troca de arquivos, telefonia IP, etc) e outras funes especiais como roteamento e controle da rede. Ele prov a capacidade de comunicao fim-a-fim entre cada elemento da rede IP atravs de um servio sem conexo e no confivel. A confiabilidade da comunicao e o estabelecimento de conexes fim-a- fim deve ser executado por protocolos de nveis superiores, como o TCP, protocolo da camada de transporte. Algumas vezes, o protocolo IP confundido com a arquitetura TCP/IP, que define o modelo de funcionamento da Internet, a rede pblica mundial de computadores. A Figura 13, a seguir, compara as arquiteturas OSI e TCP/IP. Note que o Protocolo IP se encontra na camada de Inter-rede e o TCP na camada de Transporte.

QoS significa Quality of Service e ser estudado no captulo 4.

36

Figura 13: Arquitetura OSI x Arquitetura TCP/IP http://www.softpanorama.org/Net/Images/tcp_ip_layers.gif

Hoje, o alcance das redes IP muito amplo chegando at aos aparelhos de celular. possvel baixar jogos, msica, vdeos, enviar emails, navegar na web e tudo mais a partir do telefone. O sucesso do protocolo IP to grandioso que j existem iniciativas como o Cloud Computing ou, se for possvel uma traduo direta, Computao em Nuvem. A computao em nuvem transfere para a rede IP (ou nuvem IP) a carga de processamento de diversas aplicaes que originalmente consumiriam recursos dos PCs. Na realidade no a rede em si, mas os servidores que compem a rede que executam o processamento das informaes. Um exemplo a sute de aplicativos da Google, totalmente acessvel pela Internet. Entretanto, a tecnologia que talvez tenha mais crescido junto com a exploso das redes IP foi o VoIP, Voz sobre IP, que utiliza a rede IP para transportar a voz, antes encaminhada por uma rede comutada a circuitos. Aliado a este crescimento, a utilizao de computadores na rede telefnica para criao de novos servios ganhou fora. As CPAs, Centrais de Programa Armazenado,

37

evoluram e as aplicaes que elas rodavam comearam a ser desenvolvidas principalmente em software, sendo necessrio apenas um hardware genrico, um servidor. Isto propiciou a utilizao de PCs comuns e sistemas embarcados com aplicaes de telefonia, que faz com que computado res executem aes de centrais telefnicas e possibilite a criao de diversas aplicaes que integram as redes telefnicas com a rede de dados. Naturalmente, surgiu a Telefonia sobre IP (ToIP), ou seja, funes da rede de telefonia passam a ser executadas por computadores e os dados passam a sem transportados pela rede IP. Este o assunto do prximo captulo.

38

Captulo 3 Entendendo VoIP

Com o sucesso das redes de pacotes, mais especificamente de redes IP, era inevitvel a idia de aproveitar a rede de dados para transporte de voz e vdeo. A tcnica de digitalizar sons, incluindo a voz humana, j era conhecida. Era preciso uma forma eficiente de transportar a voz sobre a rede de pacotes. exatamente isso que os protocolos de Voz sobre IP fazem. Este captulo trata do alicerce tcnico indispensvel para a compreenso do servio de Voz sobre IP, apresentando os principais protocolos de suporte a tecnologia VoIP.

VoIP vs. ToIP

Primeiramente, necessrio esclarecer a diferena entre VoIP (voz sobre IP) e ToIP (telefonia sobre IP). De forma muito simplificada, VoIP a tecnologia que permite a transmisso da voz digitalizada sobre a rede de pacotes IP e ToIP o servio de telefonia, incluindo tudo o que se espera do servio convencional, mas que se utiliza da tecnologia de VoIP. Um dispositivo qualquer (PDA, computador, smartphone, etc) que consegue realizar chamadas pela rede IP simplesmente utiliza a tecnologia VoIP. J o servio de telefonia sobre IP, ou simplesmente telefonia IP, traz embutido em sua definio a possibilidade de dispor de servios como secretria eletrnica, integrao computadortelefone (CTI), mensagens unificadas, transferncia, conferncia, etc. Agora, o PABX IP passa a se chamar servidor de voz ou servidor de telefonia, pois ele no mais um mero PABX. Ele acumula funes mais nobres e mais complexas. De forma direta e conclusiva, Voz sobre IP (VoIP) a tecnologia que d suporte aos servios oferecidos pela Telefonia sobre IP (ToIP).

Protocolos para VoIP

A comunicao de voz sobre redes de pacotes teve incio na ARPANET, em 1973, com a implementao do NVP Network Voice Protocol (9). Mais tarde, em

39

1979, o protocolo experimental ST Internet Stream Protocol foi definido pelo Internet Engineering Note IEN-119 e revisado pelas RFCs 1190 (10) e 1819 (11). Atualmente, dois protocolos de voz sobre IP se destacam. O H.323, desenvolvido pela ITU, possui caractersticas rgidas e bem definidas. O SIP Session Initiation Protocol desenvolvido pelo IETF mais simples e flexvel e est em franca utilizao, podendo ser considerado o padro atual para VoIP.

H.323
O primeiro protocolo de Voz sobre IP a se estabelecer no mercado foi o H.323 (12). Sua primeira verso datada de Novembro de 1996. A verso mais atual, aprovada em dezembro de 2009, conhecida como H323v7 pois ele se encontra na stima verso. Uma das mudanas mais importantes ocorreu no H.460.23 e H.460.24, que garantem maior facilidade para atravessar Firewalls e implementaes de NAT. O H.323 define no apenas o estabelecimento das conexes de voz e vdeo, mas tambm vrios servios suplementares requeridos pelas empresas. Na verdade, o H.323 um conjunto de outros protocolos que estabelecem procedimentos para autenticao, contabilidade, abertura e encerramento de seo, estabelecimento e fechamento de canal de mdia e controle da chamada. Dentre as recomendaes utilizadas em conjunto com o H.323 destacam-se H.225 RAS (Registro, Admisso e Status) e estabelecimento da chamada (13) Q.931 Sinalizao da chamada (14) H.245 Protocolo de controle para comunicao multimdia (15) H.235 Trata de questes de segurana. Foi desmembrada em H.235.1 at .7 na reviso de 1995. (16) H.450 Descreve os servios suplementares. Desmembrado de H.450.1 at .12. (17) T.120 Padro para conferncia de dados e controle de conferncias para comunicao interativa. (18)

40

RTP/RTCP Realtime Transport Protocol e Realtime Transport Control Protocol, Protocolo de transporte em tempo-real, utilizado para transporte da mdia, definido na RFC-1889. (19)

Arquitetura e componentes
O conjunto dos elementos que se encontram sob a mesma administrao, ilustrados na figura 14, conhecido como Zona H.323.

Figura 14: Zona H.323 e seus elementos. ITU-T Recomendao H.323(v6)

Uma rede H.323 formada por 4 componentes:

Terminal (Tn) o componente bsico da arquitetura. Pode ser um telefone IP, com ou sem suporte a vdeo, um ponto de vdeo conferncia, ou um programa de computador.

Gatekeeper (GK) o responsvel pela admisso de chamadas na rede. Ele controla quem pode realizar ligaes, responsvel pela autenticao dos usurios, faz tradues de nomes e nmeros para endereos IP (possibilitando que no seja necessrio conhecer o endereo IP dos participantes), controla requisitos de QoS para cada chamada, etc.

Gateway (GW) o responsvel pela interconexo de diferentes redes. o ponto de encontro entre sua rede H.323, redes de telefonia e outros protocolos VoIP.

41

Multipoint Control Unit (MCU) o responsvel pelas conferncias com mais de 3 terminais ou gateways H.323. Ele gerencia e controla as sees de conferncia de voz ou vdeo e ainda mistura participantes com capacidades distintas como a participao a partir de um telefone da STFC em uma vdeoconferncia de alta definio.

Exemplo de chamada H.323

A figura 15, a seguir, ilustra um exemplo de ligao entre dois terminais H.323 utilizando um gatekeeper para controle e admisso das chamadas.

42

Figura 15: Exemplo de chamada H.323 http://www.en.voipforo.com/images/H323-communication.gif.

43

Inicialmente, o usurio A (situado a esquerda) solicita permisso para fazer uma chamada ao GK enviando-o uma mensagem RAS-ARQ (Admission Request). O GK por sua vez, permite a ligao com uma mensagem RAS-ACF (Admission Confirm), com o endereo IP do usurio B. possvel configurar o GK para forar a ligao de A para B atravs dele, ou seja, toda a troca de mensagens entre A e B dever ser encaminhada atravs do GK. Depois o usurio A envia para B uma mensagem H.225 SETUP, para estabelecimento da chamada, que respondida por B, indicando que este recebeu a requisio e est processando o que necessrio. Logo aps, B envia a requisio para falar com A ao GK, que o responde afirmativamente, permitindo que B responda a requisio de A com o sinal ALERTING, indicando que o telefone est chamando. Assim que o usurio B atende, seu terminal envia a mensagem CONNECT. Agora, os dois terminais trocam mensagens informando suas capacidades, negociando seus papis na chamada e iniciam a abertura dos canais lgicos, um em cada direo, por onde ir trafegar a mdia. Assim que o canal lgico aberto, a mdia encaminhada entre os terminais encapsulada no protocolo RTP. Ao final da conversao, quando o usurio B coloca o telefone no gancho, inicia-se o processo de desconexo com o fechamento dos canais lgicos, a liberao da chamada e o aviso para o GK que a chamada foi finalizada. Note que foram necessrias 3 sesses distintas para que a mdia pudesse ser transmitida entre os participantes da conversao. importante ressaltar que, normalmente, as conexes de RAS e de estabelecimento da chamada, representadas respectivamente pelas cores vermelha e azul, so conexes TCP e, o estabelecimento do canal lgico e o transporte da mdia so fluxos UDP. A utilizao do protocolo TCP para troca de mensagens sugere que o H.323 um protocolo relativamente lento para estabelecimento de conexes, pois obviamente

44

realizam o three-way handshake e retornam um syn para todos os pacotes trocados. Alm disso, em comparao com o protocolo SIP, h um relativo excesso de mensagens no estabelecimento do canal lgico que poderiam ser evitadas. Apesar do H.323 ser largamente utilizado pelas empresas, essas caractersticas contriburam para a gradual reduo do uso do H.323 como protocolo de telefonia IP.

SIP
SIP significa Session Initiation Protocol, em portugus, Protocolo de Iniciao de Sesso. Como seu nome indica, utilizado para iniciar uma sesso de comunicao. Tambm usado para modificar as sesses em andamento, incluindo ou retirando participantes e modificando as mdias utilizadas na conexo. O SIP foi desenvolvido pelo IETF e est descrito na RFC-3261 (20). Utiliza o SDP, Session Description Protocol Protocolo de Descrio de Sesso, especificado na RFC-2327 (21) para descrever as sesses e o RTP/RTCP para transporte da mdia. um protocolo baseado em texto e foi desenvolvido em conformidade com servios oferecidos para Internet. o protocolo de Voz sobre IP mais utilizado atualmente. Ele mais simples e moderno. Est presente em quase todos os softwares de comunicao instantnea na Internet. Alm disso, muitos (se no todos) os fabricantes de PABX IP j produzem aparelhos com o protocolo SIP.

Arquitetura e componentes
Uma rede SIP formada por 2 componentes bsicos: o User Agent e o SIP Server. User Agent (UA) User Agent Client (UAC) e User Agent Server (UAS) O UA a parte lgica de um dispositivo SIP. O UAC envia pacotes contento as mensagens e requisies SIP que so atendidas por um UAS, a parte lgica de um dispositivo SIP que ouve por requisies. Um telefone SIP, por exemplo, possui os dois tipos de UA. SIP Server Podem ser de trs tipos diferentes

45

Proxy Server Atuam como procuradores intermediando transaes, traduzem nomes ou nmeros em endereos IP e encaminham a chamada para os verdadeiros destinos. Um servidor Proxy pode ser de dois tipos:

Proxy Stateful que mantm o estado das conexes que ele trata, permitindo a utilizao de bilhetadores.

Proxy Stateless no mantm o estado das conexes, sendo mais rpidos e suportando mais ligaes simultneas.

Registar Server Autentica os participantes da rede SIP e mantm uma tabela de correspondncia entre nomes ou nmeros e endereos IP dos telefones.

Redirect Server Apenas redireciona as requisies para outro servidor Proxy.

Figura 16: Exemplo de arquitetura SIP. http://www.ucb.br/prg/professores/maurot/RA/RA_arqs/conteud o_web/SIP/SIP_arquivos/image001.gif

As mensagens SIP so divididas entre Mtodos e Respostas. O UAC de um dispositivo SIP, por exemplo, um telefone IP, precisa implementar 6 mtodos bsicos:

46

REGISTER Usado para registro em um SIP Registar Server. INVITE Usado para estabelecer uma chamada. ACK Para confirmar uma transao. BYE Para desligar uma chamada em curso. CANCEL Para cancelar o processamento de uma requisio em curso. OPTION Solicita informaes sobre as capacidades do servidor.

As mensagens de Resposta so envidas pelos UAS aps a recepo dos mtodos. Elas possuem cdigos que seguem a mesma idia usada por outras aplicaes da Internet, como HTTP ou SMTP.

Exemplo de chamada SIP

No exemplo de chamada SIP ilustrado na figura 17 considere a linha vertical a esquerda como sendo o usurio A (chamador), a linha central sendo o proxy stateful e a linha a direita sendo o usurio B (chamado).

47

Figura 17: Exemplo de chamada SIP. http://www.en.voipforo.com/SIP/SIP_example.php Inicialmente ambos os usurios se registram no Proxy, que acumula a funo de Registar Server, ou servidor de registro. A chamada comea com o INVITE, enviado do UAC do usurio A para o UAS do Proxy, que responde imediatamente com um TRYING 100, indicando que a mensagem anterior foi recebida. Este encaminha a mensagem para o usurio B, que responde tambm responde com um TRYING 100, para o Proxy. O telefone de B comea a tocar e este envia a mensagem RINGING 180 para o Proxy, que a encaminha para o telefone A, fazendo com que este gere o tom de chamando para o chamador. Quando o usurio B atende a chamada, o telefone envia um OK 200 para o Proxy, que o encaminha para o usurio A e responde com um ACK. Neste momento, os telefones enviam pacotes RTP contendo a mdia em questo, por exemplo, a voz. Quando o usurio A coloca o telefone no gancho, o telefone envia a mensagem BYE para o proxy, que a encaminha para B.

48

Algumas implementaes no esperam o ACK em resposta ao BYE. Algumas nem o enviam. Pode-se notar pela troca de mensagens que o protocolo SIP bem mais simples que o H.323, no sendo necessrias as diversas sesses diferentes para o estabelecimento de chamadas. Normalmente, o SIP utiliza a porta UDP 5060 para ouvir as requisies. possvel, mas no comum utilizar o protocolo TCP para troca das mensagens de controle. Assim como no H.323, o RTP/RTCP utiliza o protocolo UDP para transporte da mdia.

Comparao SIP x H.323

Ao se comparar o SIP e o H.323, nota-se claramente as tendncias dos grupos que os definiram. O H.323, definido pela ITU, foi desenhado tendo em mente os requisitos para comunicaes multimdia sobre redes IP, incluindo conferncia de udio, vdeo e de dados. Foi concebido como uma evoluo do RDSI/ISDN. Ele define um sistema unificado completo. ideal para quem espera o mesmo nvel de robustez e interoperabilidade encontrados na STFC hoje. Ele foi desenhado para possibilitar a incluso de novas funcionalidades. usado principalmente para voz sobre IP e conferncias. um protocolo rgido e possui diversos controles que garantem um servio estvel. O SIP, desenvolvido pelo IETF, foi desenhado para estabelecer uma sesso entre dois pontos e para ser um componente modular e flexvel da arquitetura da Internet. Ele especifica apenas o necessrio como um protocolo de sinalizao. O SIP independente da rede sobre a qual ele roda. Com o grande crescimento da Internet e devido a sua flexibilidade e liberdade, o SIP vem se tornando cada vez mais popular e, dessa forma, vem sendo aprimorado constantemente. A popularizao tal que todos os grandes fabricantes de PABX IP j produzem solues baseadas em SIP.

49

O endereo http://www.en.voipforo.com/H323vsSIP.php apresenta uma extensa tabela comparativa entre os dois protocolos. Como o site acima sugere, no h um vencedor entre SIP e H.323. O H.323 mais maduro e confivel, mas pouco flexvel. O SIP no prev todas as situaes possveis, definindo menos coisas que o H.323, mas por isso mesmo altamente flexvel permitindo novas aplicaes e de fcil escalabilidade, exatamente como devem ser as aplicaes da Internet.

Transporte da mdia
Tanto SIP quanto H.323 utilizam o mesmo protocolo para transportar a mdia, voz ou vdeo, de um participante para o outro. Ambos fazem uso do RTP, que funciona sobre o UDP. A primeira observao que deve ser feita sobre a escolha do UDP como protocolo de transporte da mdia. O UDP um protocolo de transporte que funciona sobre o IP. Ele no aumenta a confiabilidade dos datagramas IP. Tambm no faz nenhum controle de fluxo, seqncia ou perda de pacotes. A principal caracterstica do UDP que ele oferece ao IP a capacidade de multiplexar aplicaes que so executadas em um mesmo computador.

O que RTP?
RTP o acrnimo de Real-time Transport Protocol ou Protocolo de Transporte em tempo-real. A RFC-1889 (19), documento que o descreve, afirma que ele prov funes de transporte fim-a- fim, ideais para aplicaes que transmitem dados em tempo-real, tais como udio, vdeo ou dados de simulao. O RTP acrescido pelo RTCP (Real-time Transport Control Protocol), o protocolo de controle do RTP, que permite o monitoramento e o controle da entrega dos dados. As aplicaes de vdeo e voz sobre IP utilizam o RTP para acrescentar controle ao transporte da voz codificada. O cabealho RTP prov informaes como um timestamp para cada pacote, nmero de seqncia, fontes de sincronismo, etc. Essas informaes so utilizadas pelos dispositivos para, por exemplo, calcular o tamanho do

50

buffer de jitter. Elas tambm podem ser utilizadas pelo administrador de redes para obter informaes acerca da qualidade das ligaes que esto em curso na rede IP. A Figura 18, a seguir, ilustra como a voz codificada transportada na rede.

Figura 18: Encapsulamento da voz codificada. http://www.networkworld.com/subnets/cisco/chapters/1587052695/graphics/04fi g03.jpg

Digitalizao e codificao da voz

CODECs
Um CODEC um dispositivo ou um programa capaz de executar a codificao e a decodificao de um fluxo de dados ou sinal digital. A palavra CODEC pode ser a combinao de COder-DECoder ou COmpress-DECompress. CODECs codificam um fluxo ou um sinal para transmisso, armazenamento ou criptografia e o decodifica para edio ou leitura. CODECs so freqentemente utilizados em vdeoconferncias e aplicaes de fluxo de mdia.

Perda de informao
A principal funo dos CODECs comprimir os dados de um arquivo de udio ou vdeo para armazenamento ou transmisso. Como os mtodos mais utilizados de compresso so baseados em encontrar padres e repeties, sons e vdeos no possuem uma boa taxa de compresso, pois os dados so na sua grande maioria muito caticos. Isto se deve a natureza complexa das formas de onda de udio, que normalmente so muito difceis de simplificar sem uma converso (necessariamente com perdas) para informaes de freqncia.

51

Muitos CODECs causam alguma perda de informao (lossy CODECS) para conseguir uma maior taxa de compresso e, conseqentemente, um tamanho de arquivo ou uma largura de banda de transmisso adequada para uma aplicao especfica. Essa perda calculada para ser imperceptvel, ou pelo menos para que no prejudique o entendimento da informao a ser transmitida ou armazenada. Esses CODECs so vastamente utilizados hoje em dia nas mais diversas aplicaes e vo desde telefonia IP a tocadores de msica e aparelhos de DVD. Existem CODECs que no causam perda de dados (lossless CODECs). Eles so utilizados principalmente por engenheiros de som, apaixonados por msica, ou pessoas que queiram preservar uma cpia idntica do arquivo (som ou vdeo) original. Entretanto, para a maioria dos casos mais vantajoso economizar no tamanho do arquivo ou no consumo de banda acarretando uma quase imperceptvel perda na qualidade, do que manter ou transmitir uma cpia fiel do arquivo ou fluxo.

Como funcionam os CODECs

Os CODECs so desenhados levando em considerao alguns aspectos da mdia a ser comprimida ou codificada. Por exemplo, um vdeo digital de algum jogo de futebol, voley, baseball, etc. precisa codificar muito bem o movimento dos quadros, mas no precisam ter cores perfeitas. Por outro lado, um vdeo de uma exposio de quadros precisa codificar muito bem as cores e texturas das telas, mas no precisa lidar com movimento de forma exata. A mesma analogia pode ser feita para CODECs de udio quando se compara um som codificado de uma pera, onde este deve ser muito mais fiel ao original, ou a fala humana em conversaes telefnicas, que precisam apenas ter qualidade suficiente para que seja possvel reconhecer o interlocutor do outro lado da linha. Em udio, CODECs sem perda como o FLAC, Shorten e TTA utilizam predio linear para estimar o espectro do sinal. No codificador, o inverso do estimador usado para clarear o sinal eliminando picos espectrais. O estimador utilizado para reconstruir o sinal original no decodificador. CODECs com perda se utilizam de uma inovao chamada psico-acstica6 (psychoacoustics) que consegue distinguir os dados em um fluxo de udio que no so captados ou percebidos pela audio humana (22). Mas a verdadeira compresso vem de um fenmeno

Psico-acstica o estudo da percepo hum ana subjetiva dos sons. Tam bm pode ser

descrita com o os correlatos psicolgicos dos parmetros fsicos da acstica.

52

complementar chamado noise shapping supresso do rudo. Reduzir o nmero de bits para codificar um sinal faz aumentar o rudo neste sinal. Na compresso com perdas baseada em psico-acstica, o segredo est em esconder o rudo gerado pela economia de bits das reas que no podem ser percebidas. Isto feito, por exemplo, utilizando pouqussimos bits para codificar as altas freqncias dos sinais. Como o ouvido humano s percebe sinais muito altos nesta regio, este rudo escondido simplesmente no escutado. A codificao e compresso da voz humana podem sofrer mais perdas do que as utilizadas para a compresso de msica, por exemplo. Sabendo que, comparado a outros sons na natureza, as freqncias alcanadas pela voz humana esto compreendidas num intervalo bem menor e, que a complexidade dos sinais produzidos pela voz normalmente menor, os parmetros de perda so reajustados sendo possvel comprimir a voz com qualidade utilizando taxas de bits relativamente baixas.

Mtodos de codificao
PCM Pulse-Code Modulation

Pulse-Code Modulation a representao digital de um sinal analgico, onde a magnitude do sinal amostrada em intervalos regulares de tempo que ento quantizada e representada por uma srie de smbolos digitais, normalmente um cdigo binrio. Este formato utilizado pelas redes telefnicas digitais tradicionais. O padro G.711 (23) utiliza o PCM para digitalizao da voz e as leis de compresso lei- A, utilizada na Europa e no Brasil, e Lei- , mais utilizada nos Estados Unidos. Na amostragem, como o prprio nome diz so retiradas amostras do sinal de voz em intervalos regulares de tempo, o intervalo de amostragem. A quantidade de amostras no tempo a freqncia de amostragem, que para a voz definida em 8kHz. A quantizao o processo de converso da altura da amostra obtida na etapa anterior em valores discretos pr-definidos. Aqui entram em cena os procedimentos de compresso. So utilizados 256 intervalos de quantizao no G.711. A codificao a maneira como os nveis quantizados so representados de forma binria. Para representar os 256 nveis de quantizao, so necessrios 8 bits.

53

As 8000 amostras por segundo vezes 8 bits por amostra significam uma taxa de bits de 64000 bits por segundo (64kbps) para o CODEC G.711. A figura 19 ilustra as fases do processo de digitalizao do PCM.

Figura 19: Codificao PCM http://fartura.fortunecity.com/sdh1.gif O PCM possui duas variaes, o DPCM e o ADPCM. DPCM (Diferencial PCM) codifica os valores como as diferenas entre o valor atual e o anterior. Para o udio, este tipo de codificao reduz o nmero de bits necessrios por amostra em cerca de 25% em comparao com o PCM. ADPCM (Adaptive DPCM) uma variante do DPCM que varia o tamanho do passo de quantizao para permitir maiores redues na banda para uma dada relao sinal-rudo. Este mtodo utilizado pelo CODEC G.726, padronizado pela ITU-T. A utilizao do ADPCM reduz a utilizao da rede em 50%, em relao ao G.711, o PCM padro, e utilizado nos sistemas DECT (Digital Enhanced Cordless Telecommunications) de telefonia sem fio.
FLAC Free Lossless Audio CODEC

FLAC um formato popular de arquivo para compresso de udio. Como outros

54

mtodos de compresso, a principal vantagem do FLAC a reduo dos requerimentos de espao e banda, mas sem sacrificar a integridade dos dados. Ele foi desenhado para ser eficiente na compresso de udio. Assim, uma msica com qualidade de CD que, comprimida com o algoritmo ZIP consegue taxas de 10% a 20%, utilizando o FLAC pode atingir taxas de 30% a 50%. FLAC utiliza Predio Linear para converter as amostras de udio em uma srie de pequenos nmeros no correlatos (conhecida como resduo), que so armazenadas eficientemente utilizando a codificao Golomb-Rice 7. Ela tambm utiliza a codificao run-length para blocos de amostras idnticas, tais como passagens de silncio. A grande vantagem do FLAC sobre outras tcnicas de compresso sem perda est na habilidade de poder ser transmitido e no rpido tempo de decodificao, que independente do nvel de compresso. Mais informaes sobre o FLAC pode ser encontradas na pgina

http://flac.sourceforge.net/ .
CELP Code Excited Linear Prediction

Junto com suas variantes ACELP (Algebraic CELP), RCELP (Relaxed CELP), LD-CELP (Low Delay CELP; utilizado pelo CODEC G.728) e VSELP (Vector Sum ELP; foi utilizado com o padro IS-54, nas primeiras redes TDM de celular), ele atualmente o algoritmo de codificao de voz mais utilizado. O acrnimo CELP agora utilizado com um termo genrico para designar uma classe de algoritmos e no um CODEC em particular. utilizado, por exemplo, nas redes GSM. Predio linear uma operao matemtica onde valores futuros de um sinal tempo-discreto so estimados como uma funo linear dos valores anteriores. O algoritmo CELP baseado em quatro idias principais:
Modelo fonte-filtro para produo de voz utilizando a predio linear;

A codificao de Golomb tima para alfabetos que seguem uma distribuio geomtrica,

quando valores pequenos so muito mais comuns que valores altos. A codificao de Rice um caso especial da anterior, quando o parmetro uma potncia de 2.

55

utilizar um cdigo adaptativo e fixo como entrada do modelo de predio linear executar uma procura em um loop finito em um domnio de percepo com pesos aplicar a quantizao vetorial

O modelo filtro- fonte para produo de voz modela a fala como uma combinao de fontes de sinal (como as cordas vocais) e um filtro (como o trato vocal). Quantizao vetorial uma tcnica de quantizao onde a idia bsica codificar ou substituir com uma chave, valores de um espao vetorial multidimensional por valores de um subespao discreto de menor dimenso. Exemplos de CODECs baseados em CELP so G.729 (24) e G.723.1 (25) e o Speex (26), de cdigo aberto. Dentre estes, o G.729 o CODEC mais utilizado em implementaes de Voz sobre IP por apresentar o menor consumo de banda com uma boa qualidade da voz. Vale ressaltar que h diferentes verses do G.729.
G.729: a verso original G.729A ou anexo A: uma simplificao da verso original e compatvel com esta. G.729B ou anexo B: a verso original com supresso de silncio e no compatvel com verses anteriores. G.729AB: o G.729A com supresso de silncio e s compatvel com G.729B. Todas essas verses tm bitrate de 8kbps, mas existem verses de 6.4 kbps (anexo D) e de 11.4 kbps (anexo E).

Lista de CODECs
Uma variedade de CODECs podem ser implementados com relativa facilidade em PCs e equipamentos eletrnicos. Tambm possvel e freqente que vrios CODECs estejam disponveis no mesmo dispositivo. A lista de CODECs mais completa encontrada durante a pesquisa pode ser acessada na pgina <http://en.wikipedia.org/wiki/List_of_codecs>. A seguir

56

apresentada uma breve lista de CODECs comuns utilizados em udio. CODECs de udio.
Formatos sem compresso

AIFF Audio InterchangeFile Formatos RIFF Resource Interchange File Format WAV Formato WAVE da Microsoft. Suporta compresso, mas raramente utilizado.
Formatos com compresso sem perda

ALS (Audio lossless coding (MPEG-4 ALS)) FLAC (Free LosslessAudio Codec) RealAudio Lossless WMA Lossless (Windows Media Audio 9 Lossless)
Formato de compresso com perda

Utilizao Geral (taxa de bit mdia a alta) ADPCM AAC e AAC+ Advanced Audio Coding (MPEG-2 e MPEG-4) MP1, MP2 e MP3 MPEG audio layer-'X' HILN MPEG-4 Parametric audio coding TwinVQ Ogg Vorbis WMA (Windows Media Audio) Utilizado para Voz (Baixa taxa de bits, otimizado para fala) AMR, AMR-WB, AMR-WB+

57

G.711 (PCM Lei-a e Lei-) G.726 (ADPCM) G.728 (LD-CELP) G.729 (CS-ACELP) G.729a, G.729.1 GSM Enhanced Full Rate, GSM Full Rate, GSM Half Rate CELP (Code Excited Linear Prediction) iLBC (internet Low Bitrate Codec) Speex Cdigo livre

CODECs em VoIP
Em Voz sobre IP, os CODECs exercem uma importncia mpar porque eles definem a qualidade das chamadas telefnicas e a quantidade de banda necessria. As caractersticas de cada CODEC definem sua taxa de bits, sua qualidade, sua complexidade e o atraso associado ao seu processamento. Por exemplo, o CODEC G.711 possui alta qualidade, funciona a uma taxa de bits de 64kbps, de baixa complexidade e gera um atraso prximo a zero. Entretanto, quando utilizado na rede IP, uma conversao utilizando este CODEC consome mais banda do que sua taxa de bits. Isto se deve ao fato de que a voz codificada transportada utilizando o protocolo RTP, que por sua vez, utiliza o protocolo de transporte UDP, que funciona sobre o protocolo IP. E o IP tambm funciona sobre uma camada de enlace, por exemplo, Ethernet ou Frame Relay. Portanto, para calcular a banda necessria para Voz sobre IP preciso levar em considerao os cabealhos de todos os protocolos envolvidos na comunicao. Clculo de banda necessria Para fins de exemplificar o clculo de banda, utilizado o CODEC G.711. J se sabe que o CODEC G.711 possui taxa de bit de 64kbps. Entretanto, ainda

58

preciso acrescentar os cabealhos das diversas camadas (enlace, rede, transporte e rtp) e levar em considerao a quantidade de pacotes por segundo para se conseguir um nmero mais realista. Quando somados, as taxas passam de 85 kbps. As contas so feitas da seguinte forma: Tamanho do Pacote = (Cabealhos Ethernet(+trailer)/IP/UDP/RTP) + (tamanho do payload de voz) x 8 bits Banda total = Tamanho do pacote (em bits) x Pkt/Seg (16+4+20+8+12 + 160) x8 x 50 = 88000 = 88 kbps

A Tabela 1 a seguir mostra valores medidos na prtica. Informaes sobre o CODEC

Codec & Tamanho Bit Rate (Kbps) da amostra (Bytes) Intervalo de (ms) Mean Score (MOS)

Clculos de consumo de banda

Tamanho do Tamanho payload de voz (Bytes) de voz (ms) Pacotes segundo (PPS) Banda para Banda para FRF.12 (Kbps) FRF.12 com compresso de cabealho (Kbps) Banda Ethernet (Kbps)

amostragem Opinion

do payload por

G.711 64Kbps G.729 8Kbps G.723.1 5.3Kbps G.726 32Kbps G.726 24Kbps

80 Bytes

10 ms

4.1

160 Bytes

20 ms

50

82.8 Kbps

67.6 Kbps

87.2 Kbps

10 Bytes

10 ms

3.92

20 Bytes

20 ms

50

26.8 Kbps

11.6 Kbps

31.2 Kbps

20 Bytes

30 ms

3.8

20 Bytes

30 ms

34

17.9 Kbps

7.7 Kbps

20.8 Kbps

20 Bytes

5 ms

3.85

80 Bytes

20 ms

50

50.8 Kbps

35.6 Kbps

55.2 Kbps

15 Bytes

5 ms

60 Bytes

20 ms

50

42.8 Kbps

27.6 Kbps

47.2 Kbps

Tabela 1: Comparao entre CODECs. Baseada em tabela da cisco disponvel em http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094a e2.shtml

59

Existem programas e sites que calculam o consumo de banda. Dois exemplos so: http://site.asteriskguide.com/bandcalc/handle_calc.php http://www.asteriskguru.com/tools/bandwidth_calculator.php
VAD Voice Activity Detection

Para tentar economizar banda e aumentar o aproveitamento do link, utiliza-se a tecnologia de deteco de voz ou VAD (Voice Activity Detection), o supressor de silncio. Resumidamente, este procedimento faz com que no se transmita pacotes enquanto o usurio estiver em silncio em pequenas pausas durante seu discurso ou aguardando seu interlocutor falar. Este tempo de silncio pode chegar a 60% da conversao em cada direo, entretanto, como rudos do ambiente no so diferenciados da voz, em mdia, o tempo sem transmisso de som de 40% da conversao. Para economia de banda, a utilizao do VAD s faz sentido em redes com vrias ligaes simultneas, pois a probabilidade de algum estar em silncio em alguma ligao num universo de uma ligao menor que em vrias ligaes. Quanto mais ligaes simultneas, mais percebida as vantagens da utilizao do VAD. Assim, pode-se dimensionar a velocidade do enlace para um nmero maior de ligaes simultneas do que ele suportaria se no estivesse utilizando a deteco de voz. Para este clculo devem ser utilizadas as tcnicas utilizadas na telefonia tradicional para clculo do Grau de Servio 8 , sendo levado em considerao o perfil do ambiente onde o sistema est sendo instalado.

Outras Consideraes
Fornecimento de energia eltrica
Uma caracterstica marcante do sistema de telefonia tradicional que todos os
Grau de Servio a probabilidade de um usurio no encontrar recursos disponveis no sistema de telefonia durante a HMM (Hora de Maior Movim ento) para que sua chamada seja completada.
8

60

recursos necessrios para um telefone funcionar so providos pela central de telefonia. Para se utilizar um terminal telefnico s necessrio o par de fios de cobre que vem da central telefnica e do aparelho de telefone. Assim, quando falta luz, o telefone no pra, j que a central garante o fornecimento de energia necessrio para seu funcionamento. Mesmo aparelhos digitais, normalmente ligados por quatro fios de cobre, funcionam neste regime. Na Telefonia IP isso bem diferente. O terminal no mais um mero transdutor que transforma som em sinais eltricos. Na Telefonia IP, o terminal um minicomputador especializado e precisa de energia para funcionar. A princpio, a nica opo seria instalar um ponto de energia prximo ao telefone e lig- lo ali. Esta forma de alimentar os telefones no era prtica, pois se houvesse falha no fornecimento de energia, os telefones tambm parariam. Para resolver es se problema, poderia ser utilizado um no-break, mas esta soluo tambm no era prtica, pois exigiria um nobreak para cada telefone ou um gerador central, que praticamente impossvel de se obter para pequenas e mdias instalaes. O padro 802.3af (27) trata este problema, garantindo a alimentao dos telefones e outros dispositivos de baixo consumo utilizando o mesmo cabo por onde os dados trafegam. Esse padro popularmente conhecido como Power over Ethernet, ou PoE. Apesar de o nome sugerir a utilizao da rede Ethernet para alimentao dos dispositivos, a energia transmitida utilizando os pares do cabo ethernet que no so utilizados para comunicao. Hoje existe uma srie de equipamentos capazes de prover a energia necessria para telefones e outros dispositivos. Vo de simples injetores de energia a switches com diversas densidades de equipamentos. A utilizao desses dispositivos garante maior confiabilidade e robustez rede de Telefonia IP das empresas no mesmo passo que encarece sua implementao. Pequenas e mdias empresas devem verificar o custo-benefcio de possuir uma rede alimentada por esses dispositivos. Elas raramente possuem infra-estrutura adequada ou simplesmente no economicamente vivel, o que os faz aceitar um nvel mais baixo de qualidade em relao continuidade e qualidade do servio.

61

IAX2: Um novo protocolo

IAX o acrnimo de InterAsterisk eXchange. o protocolo desenvolvido pela Digium 9 para o PABX IP Asterisk, tambm desenvolvido por essa empresa. O IAX se encontra na verso 2, por isso o nome IAX2 (28). Ele est descrito na RFC-5456 e sua ltima atualizao data de fevereiro de 2009. IAX capaz de multiplexar a sinalizao e a mdia de vrios fluxos de chamadas telefnicas sobre a mesma comunicao UDP entre dois computadores. Ele utiliza a porta UDP 4569 para todos os tipos de trfego (controle das chamdas e transporte de mdia). Assim, ele reduz drasticamente o overhead do transporte da mdia e transparente a implementaes de NAT, diferentemente do SIP e H.323. Como foi abordado nos itens anteriores, SIP e H.323 utilizam um canal para sinalizao e, durante o estabeleciemnto da chamada, negociam outros canais para o transporte de mdia, um em cada direo. Isto faz aumentear consideravelmetne a complexidade de firewalls e implementaes de NAT, podendo at inviabilizar a comunicao em alguns casos. Alm disso, para transportas a mdia esses protocolos utilizam um cabealho IP/UDP/RTP para cada chamada, resultando em um grande overhead no trfego. O IAX no transporta a mdia sobre o protocolo RTP e ele pode utilizar apenas um cabealho IP/UDP/IAX para todas as chamadas em curso. IAX2 utiliza uma codificao binria que confere ao protocolo melhor utilizao de banda. Ele acrescenta 4 bytes de overhead para um fluxo de voz. Apenas o cabealho RTP possui 12 bytes. Sua forma de multiplexar as chamadas simultneas notadamente a principal vantagem deste protocolo. Para cada chamada SIP ou H.323 necessrio um cabealho RTP (12 bytes), UDP (8 bytes) e IP (20 bytes). A soma destes cabealhos igual a 40 bytes. O CODEC G.729 tem um payload de 20 bytes. Para aumentar a eficincia da comunicao, normalmente transporta-se 2 payloads por pacote. Tem-se ento um pacote de 40 bytes
A Digium a em presa que lanou o Asterisk, um PABX de cdigo aberto. Ela tambm fabrica placas PCI para telefonia com interfaces analgicas e digitais. Na realidade, o Asterisk funciona como um a grande vitrine das placas Digium.
9

62

de cabealho mais 40 bytes de dados, para cada chamada simultnea, sem contar o cabealho de nvel 2.
IP UDP RTP PAYLOAD1 IP UDP RTP PAYLOAD2 IP UDP RTP PAYLOAD_N

Para N chamadas, tem-se N vezes 40 bytes de cabealho mais N vezes 40 bytes de carga, tudo isso vezes 50 pacotes por segundo. Aproximadamente, essa conta chega ao consumo de banda igual a N vezes a ocupao de uma chamada. { (N x 40 Bytes) + (N x 40 Bytes) } x8 bits x 50 pps = N x 80 x 8 x 50 = N x 32 kbps Note que o cabealho aumenta na mesma velocidade que o payload.

J o protocolo IAX acrescenta 4 bytes a cada chamada, mas em apenas um pacote, ou seja, apenas um cabealho IP e um UDP.
IP UDP IAX PAYLOAD1 PAYLOAD2 PAYLOAD_N

Para N chamadas tem-se 1 cabealho de 28 bytes (IP+UDP), mais N vezes 4 bytes, mais N vezes 40 bytes do CODEC vezes 50 pacotes por segundo. {(28bytes + Nx4bytes) + (N x 40bytes)} x8 bits x 50 pps = ( 28 +N x 44 ) x 8 x 50 = (11,2 + N x 17,6) kbps ~= N x 32 x 0,55 kbps , quando N Note que o cabealho aumenta 10 vezes mais devagar que o payload conforme o nmero de chamadas aumenta. Assim, quanto maior o nmero de chamadas simultneas, maior a eficincia do protocolo, fazendo com que o consumo de banda se aproxime da metade do que seria consumido se fosse utilizado o SIP ou H.323. Para exemplificar o clculo anterior, um tronco SIP ou H.323 utilizando o CODEC G.729 com 30 chamadas simultneas consumiria 960 kbps. Um tronco IAX utilizando o CODEC G.729 com 30 chamadas consumiria 539,2 kbps, apenas 12,33% alm da metade do consumo do SIP. Em relao ao consumo total, o IAX2 consome

63

56,16% da banda que o SIP consome. Para 60 ligaes simultneas a diferena do consumo cai para 55,58%, sendo o consumo do SIP igual a 1.920 kbps e do IAX2 igual a 1.067,2 kbps. E a relao entre IAX2 e a metade do consumo do SIP cai para 11,17%. As contas anteriores so feitas desconsiderando o cabealho de nvel 2, Ethernet ou Frame Relay. Essa caracterstica permite que sejam estabelecidas mais chamadas por mbps quando se utiliza o protocolo IAX. Enquanto o SIP ou H.323 consegue transportar aproximadamente 30 canais G.729 por Mbps, o IAX consegue transportar quase 60 canais por Mbps.

Porque considerar o IAX2 em uma rede VoIP?

O IAX traz grandes vantagens para implementaes de redes de telefonia onde h a necessidade de interligar dois ou mais PABX atravs de enlaces de velocidade limitada. Ele otimiza o consumo de banda utilizado nas ligaes, podendo oferecer economia da ordem de 55% em relao ao SIP ou H.323. Quando configurado para operar em modo tronco, o protocolo utiliza apenas um cabealho para transportar dados de todas as ligaes que esto ocorrendo naquele instante. Todos os outros protocolos de Voz sobre IP utilizam um cabealho RTP (mais UDP e IP) para cada uma das ligaes em curso. Outra vantagem que pode ser aproveitada por tele-trabalhadores a facilidade de operao do IAX2 com implementaes de NAT. O IAX2 transparente a NAT e no sofre nenhum problema, diferentemente do SIP e do H.323.

Porque no considerar o IAX2 em uma rede VoIP?

Apenas o PABX da Digium, o Asterisk, implementa este protocolo. At o momento da escrita desta dissertao, no h conhecimento de nenhum grande fabricante que utilize o IAX em suas redes. Alm disso, apenas poucas empresas fabricam dispositivos como ATAs (Analog Telephone Adapter) de pequena densidade

64

com este protocolo. Portanto, a real desvantagem do protocolo a falta de produtos e equipamentos que o utilizam.

65

Captulo 4 QoS para Telefonia sobre IP

A rede IP , desde sua origem, uma rede de melhor esforo. Isto significa que a rede faz o possvel para que os pacotes que por ela trafegam alcancem seu destino, mas ela no garante o tempo de entrega, a ordem de entrega, a integridade o pacote ou mesmo se a entrega desses pacotes ir ocorrer. A rede IP simplesme nte faz o melhor possvel. Para melhorar o servio da rede IP, existem protocolos de camadas superiores, por exemplo, o TCP que resolve boa parte dos problemas do IP. Entretanto, para manter a qualidade das chamadas em uma rede de pacotes semelhante s da rede determinstica, tcnicas de QoS (Qualidade de Servio) so aplicadas na rede. Dessa forma, servios com requisitos rgidos de atraso, banda e outros parmetros possam utilizar a rede IP sem perder qualidade. Este captulo apresenta consideraes sobre Qualidade de Servio em redes IP com foco no servio de Voz sobre IP.

O que QoS?
QoS o acrnimo para Quality of Service, ou Qualidade de Servio. De forma geral, diz-se que uma rede possui QoS, quando o trfego que passa por ela tratado de forma a priorizar os fluxos crticos, mantendo uma boa experincia de uso das aplicaes que exigem intensa interatividade, como telefonia. A implementao de QoS em uma rede abrange aes que vo desde a simples ateno para que um enlace no fique congestionado at a aplicao de regras de descarte. Normalmente aplicadas em enlaces de baixa velocidade, as tcnicas mais comuns consistem de classificao de pacotes, enfileirame nto e encaminhamento de acordo com prioridades pr-estabelecidas e descarte de pacotes que no esto em conformidade com as polticas estabelecidas. Em telefonia, QoS definido no padro ITU X.902 como um conjunto de requisitos de qualidade no comportamento coletivo de um ou mais objetos. Na prtica, o termo QoS causa alguma confuso. Uma interpretao mais

66

simples diz que a rede sem QoS presta um servio de melhor esforo, isto , sem garantias de tempo ou de entrega. Por outro lado, uma rede com QoS prioriza os servios de quem contrata QoS, ou seja, de quem contrata um certo nvel de servio, que lhe assegura que alguns parmetros so mantidos dentro de valores acordados. QoS, neste caso, tratado como um produto ou servio prestado pela operadora que garante uma boa experincia de uso da rede. Um aspecto importante que muitos leigos desconhecem que para ser possvel adotar polticas de QoS necessrio ter controle sobre a rede e seus dispositivos. Portanto, como conseqncia da afirmao anterior, pode-se inferir que a Internet uma rede sem QoS, ou seja, no h priorizao de pacotes, classificao de servios ou nada que garanta que fluxos de voz tero maior prioridade que fluxos de dados. A Internet uma rede de melhor esforo. De forma geral, para links de Internet, operadoras e clientes minimizam problemas relacionados qualidade simplesmente mantendo a banda disponvel em seus enlaces sempre acima da demanda de utilizao do mesmo. Contudo, contratar mais banda invariavelmente significa aumentar custos com telecomunicaes. Por outro lado, em comparao com adoo de regras de QoS, essa abordagem reduz a necessidade de recursos computacionais nos ns da rede e reduz consideravelmente a complexidade na configurao e manuteno dos equipamentos.

Parmetros importantes
Em Voz sobre IP, os parmetros que mais degradam a qualidade da conversao so o atraso, a perda de pacotes, o jitter (variao do atraso) e a banda disponvel para as chamadas. constantemente. Todos concordam sobre os parmetros que causam problemas em VoIP, mas muitos discordam sobre os valores limites que a rede deve apresentar. Cada fabricante ou pesquisador sugere nmeros que diferem levemente, mas h um consenso em torno dos valores a seguir: Esses quatro parmetros devem ser medidos e monitorados

67

Perda de pacotes Atraso fim-a- fim Jitter (variao de atraso) Banda (margem de segurana)

< 5% < 150 ms (em um sentido apenas) < 30 ms 10% do trfego real

Manter estes parmetros dentro dos intervalos indicados condio necessria para manter a qualidade das ligaes realizadas pela rede IP.

Sobre enlaces congestionados

Todos os parmetros mencionados sofrem degradao principalmente devido a congestionamento em algum ponto da rede. Na verdade, se h congestionamento, no h mais margem de segurana de banda disponvel. O congestionamento se apresenta para o usurio como ligaes de baixa qualidade e picotes na voz, pois faz extrapolar os nveis aceitveis de perda, jitter e latncia. Quando o congestionamento ocorre por insuficincia de banda, nas situaes de sub-dimensionamento do circuito ou crescimento da taxa de chamadas simultneas, pode-se facilmente contornar o problema contratando mais banda da operadora. Es sa a nica forma de resolver o problema. Quando o congestionamento ocorre por conta de rajadas de trfego de dados, sendo este um trfego legtimo e indispensvel, possvel definir regras de QoS que priorizam o trfego de voz. Neste caso, dependendo da quantidade e intensidade das rajadas, o trfego de dados pode experimentar atrasos e taxas de perda maiores para que a qualidade da voz se mantenha aceitvel. Provavelmente, isto ir aumentar a sensao de congestionamento para os usurios dos servios de dados. Caso o enlace em questo seja um acesso com a Internet, s faz sentido priorizar o trfego de voz na sada da rede para Internet. No h como controlar o trfego de entrada na rede interna, pois no se tem administrao sobre os roteadores da Internet. Uma anlise inicial poderia afirmar que regras de policiamento aplicadas na entrada da Internet no surtem efeito. Entretanto, como boa parte das conexes de dados realizada utilizando o protocolo de transporte TCP, o controle ou policiamento de trfego de entrada pode sim surtir efeito positivo, j que o TCP possui controle de fluxo

68

embutido em seu mecanismo de transporte de dados. Infelizmente, este raciocnio no se aplica ao trfego UDP, que no possui controle de fluxo. De qualquer forma, se este for o caso, a indicao para resolver o problema tambm contratar mais banda da operadora. Para enlaces Frame Relay, ainda muito comuns no Brasil, que estejam com ocupao prxima saturao existem duas recomendaes principais: 1) compresso de cabealho (29; 30) (31) e; 2) fragmentao e interposio de pacotes (32).

Compresso de cabealho
A compresso de cabealho consiste em uma tcnica que associa cabealhos IP+UDP+RTP a cdigos que variam de 2 a 5 bytes. Assim, dependendo do CODEC utilizado, a economia de banda facilmente chega muito prximo dos 50%, conforme mostrado na Figura 20.

Figura 20: Compresso de cabealho http://www.trainsignaltraining.com/wpnew/wpcontent/uploads/2008/03/Stelios_VoIP/2.jpg.

A tcnica parte do princpio que em um determinado fluxo de dados, as informaes nesses cabealhos praticamente no se modificam, repetindo-se vrias vezes. Assim, possvel montar uma tabela com informaes de cada fluxo que atravessa o roteador. A compresso de cabealho precisa ser estabelecida a cada salto (hop), o que faz

69

aumentar o tempo de processamento total na transmisso fim-a- fim do pacote. Seu uso indicado para enlaces prximos da saturao ou onde o aumento da banda no possvel.

Fragmentao e interposio de quadros

A fragmentao e interposio de pacotes (LFI) utilizada em enlaces de baixa velocidade para diminuir o atraso na serializao dos dados. Por exemplo, um pacote de 1500 bytes, leva 214 ms para ser inserido em um enlace de 56 kbps, ou seja, se cada pacote de voz precisasse aguardar um pacote de dados de 1500 bytes, a conversao seria impossvel, pois o intervalo entre os pacotes ultrapassa o valor de 150 ms, estabelecido como limite para uso em telefonia. 1500 x 8 bits / 56000 bps = 214 ms

Figura 21: Fragmentao e interposio http://www.cisco.com/en/US/prod/collateral/modules/ps2033/images/0900aecd 8056d3cb_null_null_null_11_09_06-05.jpg.

A interposio dos pacotes de voz entre os fragmentos do pacote de dados, mostrada na Figura 21, diminui o tempo de espera de cada pacote, contribuindo para diminuio do atraso fim-a- fim e do jitter. Uma vez fragmentado, o fragmento precisa de um novo cabealho, fazendo

70

aumentar a quantidade de dados a ser transportado pelo link, ou seja, a fragmentao acarreta o aumento do overhead. Por esse motivo, existem valores timos para o tamanho do fragmento em relao banda do enlace. Esses valores dependem do atraso de serializao desejado e so calculados teoricamente, mas tambm podem ser medidos empiricamente. A Tabela 2 a seguir mostra uma relao de valores timos para tamanho do fragmento de acordo com a velocidade do enlace, para atraso de serializao de 10 ms. Taxa da porta 64 kbps 128 kbps 256 kbps 512 kbps 1536 kbps (full T1) 2048 kbps (full E1) Tamanho recomendado do fragmento (10 ms) 80 bytes 160 bytes 320 bytes 640 bytes 1600 bytes 1600 bytes

Tabela 2: Tamanho do fragmento de acordo com a velocidade do acesso Baseado na tabela encontrada em http://cisco.com/en/US/tech/tk652/tk698/technologies_configuration_example09186a00 80094af9.shtml.

Modelos de QoS
Os recursos da rede para encaminhamento dos pacotes so limitados. Para minimizar os efeitos dessa limitao ou para garantir que determinado fluxo atravesse uma rede e chegue do outro lado com a qualidade desejada existem alguns modelos de QoS.

IntServ Integrated Services

O modelo de Servios Integrados, descrito na RFC-1633 (30), garante que o fluxo ter plenas condies de atravessar a rede com qualidade por requisitar e alocar recursos em todos os roteadores no domnio IntServ antes mesmo de comear a transmitir os dados. Dessa forma, a comunicao s acontece se todos os ns

71

responderem positivamente requisio de recurso. Se no houver recurso disponvel, no haver comunicao. O protocolo RSVP (Resource Reservation Protocol) descrito na RFC-2205 (33) o responsvel pela sinalizao no domnio IntServ, estabelecendo e desfazendo caminhos confiveis na rede. Uma rede que implemente IntServ precisa garantir que seus roteadores sejam capazes de executar as seguintes tarefas: Controle de Admisso: Determina que um fluxo pode ser encaminhado com o grau de qualidade requerido sem interferir em fluxos j em curso; Classificao: Reconhece pacotes que necessitam de nveis especficos de QoS; Policiame nto: Age, inclusive descartando pacotes, quando o trfego no est em conformidade com o especificado; Enfileirame nto e escalonamento: encaminha os pacotes de acordo com os requisitos de QoS. O modelo IntServ possui uma sria desvantagem. O RSVP requer muita memria nos roteadores. necessrio manter o estado de diversas conexes simultaneamente. A consequncia desse problema a dificuldade em escalar para redes muito grandes tornando-se impraticvel na Internet.

DiffServ Differentiated Services

O modelo de Servios Diferenciados, descrito na RFC-2475 (34) e atualizado pela RFC-3260 (35), foi criado pela necessidade de um mtodo relativamente simples de prover tratamentos adequados para os fluxos das diferentes aplicaes de redes. Era preciso diferenciar os fluxos em classes de servios distintas e tratar os pacotes de acordo com suas necessidades. Os roteadores que implementam DiffServ precisam possuir 4 blocos lgicos, ilustrados da figura 23:

Classificador: Seleciona um pacote do fluxo baseado no contedo de alguma poro do cabealho;

72

Medidor: checa se os parmetros do trfego esto de acordo e passa os resultados para o marcador e modelador;

Marcador: Escreve (ou rescreve) o campo DSCP; Modelador: Atrasa ou descarta alguns pacotes para que o trfego fique em conformidade com o projeto.

Figura 22: Bloco de Condicionamento de Trfego (TBC Traffic Conditioner Block) http://www.cisco.com/en/US/technologies/tk543/tk766/images/09186a008050b26c_ ee-us-Cisco_IOS_Software_Releases-Product_White_Paper-guest_4_2_2_2_2_2_25.jpg

Mecanismos de condicionamento de trfego

Policiamento (Policing): O policiamento consiste em descartar todo o trfego que excede determinada taxa. Modelagem (Shaping): A modelagem tenta no descartar o trfego excedente, enfileirando e distribuindo as rajadas de dados que excedem determinado limite, amortecendo o efeito da rajada no enlace.

Para alcanar o objetivo de encaminhar pacotes de diferentes classes e, portanto, com diferentes prioridades, so necessrias duas aes principais: 1) marcao dos pacotes, usando o campo ToS do cabealho IP e; 2) PHB (Per Hop Behavior), que

73

define um comportamento diferente a cada salto do pacote, ou seja, a cada roteador.

Marcao de pacotes
O campo ToS (Type of Service) do cabealho IP foi redefinido na RFC-2474 e agora chamado de DS (Differentiated Services). Consiste de 6 bits utilizados para classificao do fluxo e mais 2 bits reservados e no utilizados. Os 6 bits substituem os 3 bits que antes era chamado de IP Precedence e passa a ter o nome de DSCP (DiffServ Code Point). Este campo utilizado para marcar um pacote de acordo com sua classificao, que pode assumir at 64 (26 ) valores distintos. A Figura 23 mostra o exposto.

Figura 23: Cabealho IP antes e depois do DiffServ. http://blog.ccna.com.br/wp-content/uploads/2008/08/blog_ccna_qos_ii_tos.jpeg

Per Hop Behavior

Uma vez que os pacotes so marcados, os roteadores devem encaminh- los de

74

acordo com regras pr-estabelecidas. Dependendo de suas classes, um pacote ter maior ou menor prioridade na fila de sada de cada interface de rede. Pacotes com prioridade EF (Expedit Forwarding) so imediatamente enviados para rede. A classe EF est descrita na RFC-2598 (36). Pacotes com prioridade AF (Assured Forwarding) possuem 4 classes distintas, so enfileirados e encaminhados de acordo com a poltica de enfileiramento. Pacotes da classe AF4 tm maior prioridade que pacotes da classe AF1. Dentro de cada classe, ainda existe uma marcao conhecida como three colour marking ou marcao de trs cores, que definem a probabilidade de descartar pacotes dentro de cada fila. Assim, existem 12 classes AF distintas, que vo desde a AF41 at AF13. As classes AF esto descritas na RFC-2597 (37). Pacotes com prioridade padro, tambm chamado de BE (Best Effort), possuem a menor prioridade e sero encaminhados depois de todas os outras classes, se houver recursos para isto. A classe BE est descrita na RFC-2474 (38). A Figura 24 a seguir ilustra a relao entre as diferentes classes de servio, o campo DSCP e a correspondncia com o antigo campo IP Precedence e com o campo equivalente em redes MPLS. A figura ainda mostra trs possibilidades de se obter uma classe de servio menor que o Best Effort.

Figura 24: Relao entre DSCP e IP Precedence, em ordem crescente de prioridade. http://www.cantore.com/images/DSCP-Equivalents.jpg

75

Enfileiramento
As tcnicas de enfileiramento so utilizadas para encaminhar os pacotes na interface de sada do roteador de acordo com as marcaes do pacote. FIFO First In, First Out: Este o mais simples dos algoritmos de enfileiramento. Como o prprio nome sugere, o primeiro pacote que entra na fila o primeiro a sair dela. SP Strict Priority: Prioridade Estrita Este algoritmo foi desenhado para aplicaes de tempo-real. A fila com maior prioridade checada e se houver algum pacote ele enviado. Quando a fila SP estiver vazia, o algoritmo procura por pacotes na prxima fila. Assim que chega um pacote na fila SP, o algoritmo volta a esvaziar esta fila e repete o processo. Tambm conhecido como LLQ, Low Latency Queue ou fila de baixa latncia. A desvantagem deste mtodo a possibilidade das outras filas sofrerem um fenmeno chamado de starvation, quando elas podem nunca ser atendidas por sempre haver pacotes na fila SP. WRR Weighted Round-Robin: Este algoritmo escalona todas as filas e quando chega ao final volta para a primeira, mas como as filas tm pesos, o algoritmo envia uma quantidade de dados maior ou menor de acordo com o peso de cada fila. Tambm conhecido como WFQ, Weighted Fair Queuing ou enfileiramento justo com pesos.

De forma geral, uma maneira comum de se modelar as classes de servio em uma rede utilizar a fila LLQ ou prioridade estrita para trfegos marcados com DSCP EF, normalmente trfego de voz, mais algumas filas WFQ ou WRR para pacotes com marcao DSCP AFxy para vdeo, sinalizao e outros servios importantes e BE para o trfego comum de internet.

76

Medindo o QoS
No inteno do trabalho se estender sobre mtodos de medio de QoS, entretanto se faz necessrio uma apresentao mnima dos padres de medio mais comuns.

Mean Opinion Score

O MOS, Mean Opinion Score, ou tentando uma traduo direta pontuao da opinio mdia, um modelo subjetivo para medio da qualidade, ou seja, baseado na experincia das pessoas que qualificam os fluxos. Assim, so necessrios muitos avaliadores para que a medida seja validada. A preparao do ambiente de teste deve seguir rigorosas diretrizes. Dessa forma, muito difcil, trabalhoso e dispendioso conseguir a medida da qualidade utilizando o MOS. O MOS comumente conhecido pela escala de qualificao padronizada pela ITU-T, que pode ser baseada na qualidade ou na degradao do fluxo a ser qualificado. A escala de qualidade, a metodologia e a preparao do ambiente para determinao do MOS est descrita na recomendao ITU-T P.800 (39), que tambm descreve os testes recomendados. A Tabela 3 a seguir mostra a pontuao sugerida de dois mtodos de avaliao utilizados em testes de listening-opinion para os nveis de qualidade (mtodo ACR Absolute Category Rating) ou de degradao (mtodo DCR Degradation Category Rating).

77

MOS 5 4 3 2 1

Qualidade Excelente Bom Aceitvel Pobre Ruim

Degradao Imperceptvel Perceptvel, mas no incomoda Incomoda um pouco Incomoda Incomoda muito

Tabela 3: Escala de qualidade/degradao

O modelo-E
Obviamente, a qualidade (ou a falta dela) na comunicao digital causada por parmetros mensurveis. Dentre os fatores que definem a qualidade de um fluxo multimdia pode-se destacar o CODEC utilizado, a perda de pacotes, a latncia, o jitter, a vazo e ocupao do enlace e o poder de processamento do servidor e do receptor. O Modelo-E, apresentado pelo ETSI na proposio ETR250 e padronizado pela ITU-T G.107 (40), um mtodo de medida de qualidade que leva em considerao parmetros da rede e do ambiente para inferir a qualidade das ligaes, expressas pelo valor do Fator R, que varia de 0 (pssimo) a 100 (timo). De acordo com a recomendao G.113 (41), profissionais que planejam redes e servios preocupados com desempenho fim-a- fim da transmisso da voz podem usar os fatores de degradao com o Modelo-E para definir os efeitos da introduo das tecnologias de processamento da voz.

A seguir apresentada a relao entre fator R e MOS, da recomendao G.107. For R < 0: For 0 < R < 100: For R > 100: MOS = 1 MOS = 1 + 0.035R + R(R 60)(100 R) x 7 x 106 MOS = 4.5

78

A Tabela 4 a seguir relaciona o Fator-R, MOS e a satisfao do usurio Fator-R 90 80 70 60 50 MOS 4,35 4,03 3,6 3,1 2,58 Satisfao do usurio Muito satisfeito Satisfeito Alguns usurios satisfeitos Muitos usurios insatisfeitos Quase todos insatisfeitos

Tabela 4: Relao entre Fator-R, MOS e a satisfao do usurio

Qualidade dos CODECs

QoS no conseguido simplesmente com um arranjo de configuraes na rede. A escolha do CODEC adequado tambm importante e faz parte das boas prticas para uma tima Qualidade de Servio. A qualidade de um CODEC pode ser medida subjetivamente, atravs de mtodos que utilizam a sensibilidade humana para julgar sobre a clareza e fidelidade de sons e vdeos. Outro parmetro relevante que contribui para o atraso fim-a-fim o tempo que um CODEC leva para codificar e decodificar fluxos de vdeo ou udio. Os tempos de (de)codificao esto fortemente ligados capacidade de processamento das mquinas em que eles esto sendo executados. A Tabela 5 apresenta uma anlise comparativa dos tempos (em milissegundos) que se leva para traduzir CODECs de voz em um servidor Asterisk, Pentium IV 2,26 GHz e 512 MB de memria RAM.

79

g723 g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 ilbc 12 12 12 12 12 11 13 13 24

gsm 14 4 4 4 4 3 5 5 16

ulaw 12 2 1 2 2 1 3 3 14

alaw 12 2 1 2 2 1 3 3 14

g726 adpcm 14 4 4 4 4 3 5 5 16 12 2 2 2 2 1 3 3 14

slin lpc10 11 1 1 1 1 1 2 2 13 17 7 7 7 7 7 6 8 19

g729 20 10 10 10 10 10 9 11 22

ilbc 28 18 18 18 18 18 17 19 19 -

Tabela 5: Atraso (em milissegundos) para traduo entre CODECs.

Formato Fonte (Linhas) Formato Destino (Colunas)

Esta tabela, alm de ilustrar os tempos que cada CODEC precisa, tambm mostra que determinado CODEC 'A' precisa de mais tempo para traduzir para 'B' que para outro 'C', e que o tempo de traduo de um CODEC 'A' para um CODEC 'B' no necessariamente o mesmo tempo da traduo de 'B' para 'A'. Por exemplo, para traduzir de ulaw (G.711, Lei- ) para G.729, so necessrios 10 ms; para traduzir de G.729 para ulaw o tempo necessrio de 3 ms.

Ensaio sobre a relao entre CODECs e perda de pacotes

Aps o estudo da recomendao P.800, verificou-se grande dificuldade em segui- la devido a limitaes como quantidade de classificadores e ambiente adequado para realizao dos ensaios. Decidiu-se ento, realizar um teste alternativo, adaptado do Anexo D dessa recomendao.

Objetivo
O objetivo deste ensaio medir a tolerncia a perda de pacotes de CODECs com

80

perda (lossy) em relao a CODECs sem perda (lossless). Os testes foram realizados utilizando os CODECs G.711, G.729, G.723 e G.723.

Metodologia
Inicialmente, foi gravada a leitura de um texto em formato mp3. O arquivo foi armazenado em um servidor de voz. Quando os analisadores ligavam para um nmero de telefone neste servidor, uma aplicao atendia a ligao e executava a gravao. Eles ouviam a leitura do texto, que funcionou como fluxo de udio de referncia. O teste consiste em ligar para o servidor e ouvir a leitura do texto com uma perda aleatria distribuda uniformemente (no em rajadas), mas que aumentava gradativamente em passos de 0.5%, a cada 3 segundos. Quando a qualidade do udio alcana um nvel inaceitvel para uma conversao, o analisador para o teste. O valor de perda anotado significa que desse ponto em diante no mais possvel realizar uma conversa. Note que o ponto de parada no um nvel de perda onde a conversao se mantm confortvel, como na recomendao de nveis bons para uso de voz sobre IP. O ponto em questo aquele em que no mais possvel compreender o interlocutor, neste caso, simulado pela leitura do texto.

Implementao
Os testes foram implementados utilizando um servidor de voz, responsvel por armazenar e executar o fluxo de udio de referncia; um roteador Linux, que cumpriu papel de emulador de WAN, inserindo a perda controlada de pacotes e um PABX de onde as chamadas eram originadas. O emulador de WAN utilizado foi o netem <http://linux-

net.osdl.org/index.php/Netem>, que j compe o kernel do Linux e ativado utilizando a aplicao 'tc', para controle de banda e QoS. No teste, faz-se uma ligao para o servidor de voz. Este atende e coloca a chamada em espera. A msica de espera configurada a leitura do texto de referncia. O fluxo de udio transportado utilizando o CODEC especificado na configurao daquela instncia do teste.

81

Participaram dos testes apenas 6 pessoas para qualificar os fluxos. Cada uma delas ouviu o texto de referncia com cada um dos CODECs testados e em cada um dos PABX utilizados. A Figura 25 mostra um esquema deste ensaio.

Figura 25: Esquema do laboratrio de tolerncia a perda de pacotes.

Resultados
Foram obtidos resultados inesperados com a utilizao do roteador Cisco 1751 IOS 12.4, funcionando como PABX. Este modelo/verso possui uma funcionalidade que preenche os intervalos de pacotes perdidos, calculando uma amostra estimada de acordo com a interpolao das amostras vizinhas. Este processo aumenta

consideravelmente a tolerncia perda de pacotes de todos os CODECs testados. Foram realizados os mesmos testes com ligaes originadas em telefones analgicos ligados ao Cisco 1751 (IOS 12.4), ao PABX IP MX-One, da Ericsson, ao PABX IP HiPath 3800, da Siemens, e ao PABX de cdigo aberto, Asterisk. A Tabela 6 a seguir apresenta os resultados obtidos. CODEC G711 (u-Law) G729 G723 (6.3kbps) G729 (3.2kbps) Cisco 41,5 32,0 27,0 42,0 MX-One 25,0 21,5 18,5 HP 3800 43,5 39,5 25,5 Asterisk 28,0 27,0 23,0 29,0

Indisponvel Indisponvel

82

Tabela 6: Taxa de perda de pacotes em que a voz torna-se incompreensvel

Concluso do ensaio
Os CODECs G.711 e G.726 so mais tolerantes a perda de pacotes. O CODEC G729 vem em seguida com boa tolerncia a perda. Por ltimo, o G.723 o menos tolerante a perda de pacotes. Observa-se que o roteador Cisco e o PABX Siemens apresentam maiores valores para tolerncia a perda de pacotes para todos os CODECs. Isto se deve ao fato destes equipamentos possurem um mecanismo que tenta amenizar os efeitos da perda de pacotes, estimando um valor para as amostras perdidas.

83

Captulo 5 Medies, Monitoramento e Gerncia de Redes

Este captulo apresenta conceitos, ferramentas e sugestes para medir, monitorar e gerenciar uma rede IP. Tambm faz uma comparao entre softwares para gerncia de redes. Outro importante objetivo demonstrar a necessidade um sistema de gerncia com as caractersticas adequadas para garantir a continuidade do servio.

Introduo
Mesmo entre administradores com boa experincia tcnica, comum utilizar as expresses Monitorar uma rede e Gerenciar uma rede indiscriminadamente, como se elas fossem sinnimas. Entretanto, isto um equvoco. Monitorar e gerenciar tm significado bastante distinto. O primeiro passa idia de passividade; como se o gerente estivesse assistindo os parmetros da rede. J o segundo denota ao; uma situao onde o gerente encaminha as solues para a direo desejada. Infelizmente, muitos gerentes dizem que gerenciam suas redes, mas na verdade, eles apenas a monitoram e apagam incndios, resolvendo os problemas que os alarmes avisam. Neste captulo, pretende-se ressaltar a importncia da utilizao de boas prticas para gerncia de rede, bem com incentivar a adequao e aplicao das mesmas, considerando sempre as particularidades de cada caso.

Medies
Medir significa comparar grandezas de mesma natureza de acordo com alguma referncia ou padro. Por exemplo, para medir a distncia entre dois pontos, pode-se comparar a distncia com o metro, a polegada ou o p, padres conhecidos mundialmente. As pessoas fazem medies o tempo todo, sem mesmo se dar conta disso. Os resultados das medies servem de entrada para tomada de deciso de se executar ou no determinada ao. Ao atravessar a rua, as pessoas medem a velocidade dos carros e a distncia entre as caladas; ao se levar o garfo boca calculado a posio da boca

84

em relao ao prato; at ao fazer uma brincadeira, as pessoas medem (ou deveriam medir) se ser conveniente ou inoportuno. Deve-se fazer o mesmo com as redes. Medir parmetros importantes a prestao de servio deve se tornar algo corriqueiro e natural. O objetivo de se medir alguma grandeza ou parmetro conhecer o seu estado atual; seu estado instantneo. Ao comparar a medida com limites mximos e mnimos tem-se a informao de que determinado pr-requisito est ou no de acordo com nveis aceitveis. Assim, pode-se decidir que ao tomar. Em redes, preciso medir principalmente tempos e taxas. Por exemplo, tempo de propagao entre dois pontos, tempo de processamento de determinado dado, taxa de erro de uma interface, vazo de um enlace, etc. Tambm preciso medir quantidades: quantidade de memria, de espao em disco, de registros em tabelas, etc. Levando-se em considerao um escopo mais gerencial, deve-se medir, direta ou indiretamente, disponibilidade de enlaces e servios, qualidade percebida, tempo para correo de um problema, tempo entre falhas, tempo de recuperao de falhas, tempo de atendimento, grau de satisfao de clientes, custos associados s atividades de manuteno, operao, pesquisa e desenvolvimento e tudo mais que for relevante a prestao do servio. possvel classificar medies em redes em dois grandes grupos: Medies Ativas e Medies Passivas.

Medies Ativas
Medies Ativas so aquelas que precisam gerar algum tipo de trfego na rede para que seja possvel obter os resultados. Ferramentas de Medies Ativas geram fluxos de diversos tipos para que eles atravessem a rede e, ao receb- los de volta (ou no), realizam clculos e apresentam resultados. Ferramentas mais agressivas, ou seja, aquelas que foram desenhadas para gerar a maior quantidade de trfego possvel, podem congestionar enlaces e alterar o perfil de utilizao da rede. Medies Ativas tm uma ampla utilidade e podem ser empregadas em simples medies de tempo de ida e volta ou at em simulaes de trfego multimdia. Ping (ICMP Echo Request / Response) e traceroute (ou tracert, no Windows),

85

apesar de simples e praticamente no invasivas, so ferramentas de medies ativas. Mgen, Iperf e pktgen tambm so ferramentas de medies ativas, mas essas so muito mais complexas e podem ocupar toda a banda disponvel em uma rede. Inclusive, a banda disponvel um parmetro que essas ferramentas medem. O SIPp uma ferramenta de medio ativa que gera ligaes SIP e pode medir, por exemplo, tempo de estabelecimento de chamadas, quantidade de chamadas simultneas e qualidade das chamadas. Utilizando uma chamada gerada pelo SIPp possvel dizer se a rede est preparada para entregar o servio de voz sobre IP. Solues de ferramentas para medies ativas que geram trfego sinttico simulam fluxos reais e normalmente requerem um mdulo gerador, um mdulo receptor e um mdulo de anlise, que nem sempre se encontra na mesma mquina. Nesses casos, que no so raros, necessrio que os relgios das mquinas do gerador e do receptor estejam rigorosamente sincronizados. O sincronismo pode ser conseguido utilizando aparelhos ligados as redes GPS (Global Positioning System) ou CDMA (Code Division Multiple Access), ou ainda utilizando a prpria rede IP, atravs do NTP (Network Time Protocol), mais simples e mais barato, mas com preciso suficiente para a maioria das situaes. O NTP est descrito da RFC-1305 (42).

Medies Passivas
Entende-se por Medies Passivas aquelas que no necessitam gerar qualquer tipo de trfego para conseguir a informao desejada. Ferramentas de medies passivas extraem a informao necessria diretamente dos equipamentos que esto sendo medidos. O trfego gerado por este tipo de medio, quando ele existe, utilizado para transportar a informao do ponto de medio at uma base de dados que armazena, processa e apresenta os dados capturados. O ntop, uma ferramenta para medio passiva, captura todo o trfego que passa por suas interfaces de rede, armazena as informaes localmente, processa e apresenta os resultados com diversos grficos atravs de uma aplicao web. O tcpdump, iptraf e wireshark tambm capturam trfego das interfaces de rede,

86

mas eles se destinam a finalidades diferentes. Normalmente, so destinados a anlises pontuais, mais relacionadas a aplicaes e protocolos. Tambm foram desenvolvidos alguns protocolos para medies passivas como o NetFlow da Cisco, ltima verso descrita na RFC-3954, o SFlow da InMon, descrito na RFC-3176, e o SNMP, comentado adiante. O sincronismo em medies passivas no um req uisito to rgido quanto para medies ativas. Entretanto, no deixa de ser importante ter todos os equipamentos da rede funcionando com seus relgios sincronizados. Se no estiverem, os resultados apresentados podero conter desde pequenos erros de horrio at valores completamente inconsistentes.

Monitoramento
Monitorar significa acompanhar, avaliar. Aproveitando o contexto do item anterior, monitorar significa medir e comparar continuamente, de forma a criar um histrico do parmetro monitorado. Por exemplo, um mdico monitora seus pacientes realizando medies de batimentos cardacos e temperatura corporal em intervalos regulares. Aps algumas medies o mdico verifica que a temperatura est subindo, administra um antitrmico e continua a monitor- lo. Aps algumas medies ele consegue inferir se o medicamento est ou no fazendo o efeito desejado e, de posse desse histrico, pode tomar uma deciso mais acertada quanto a nova administrao e dosagem ou se ele deve trocar ou suspender o medicamento. Em redes, o monitoramento tambm pode ser definido como o conjunto de mecanismos que permitem ao administrador conhecer o estado instantneo e tendncias de curto prazo da rede de comunicao e de seus componentes. Monitorar amplia o conceito de Medio no instante em que se acrescenta o armazenamento dos dados medidos anteriormente, possibilitando a criao das sries histricas. O monitoramento facilita o diagnstico de problemas, permite o clculo de tendncias e ajuda o administrador e sua equipe a tomar dec ises mais rpidas e acertadas. A maioria das ferramentas de monitoramento de redes possui uma representao

87

grfica dos parmetros que esto sendo medidos. Boa parte delas tambm pode ser configurada para monitorar servios, como WWW, email, VPNs, e outros. Analisando seus arquivos de log, pode-se facilmente obter o perfil de utilizao de qualquer servio monitorado, como por exemplo, identificar a HMM (Hora de Maior Movimento) e o nvel de ocupao dos circuitos de voz; ou ainda verificar o trfego de spam durante o dia, semana, ms ou ano.

O que monitorar
De forma geral, devem-se monitorar os mesmos parmetros que um administrador de redes deve medir: tempos, taxas e quantidades, e os parmetros mais complexos e subjetivos como grau de satisfao, experincia do usurio, tempos de atendimento e resoluo de problema e outros parmetros relevantes a prestao do servio. A seguir apresentada uma lista de parmetros importantes para se monitorar em uma rede de telecomunicaes. Os itens enumerados no esgotam as possibilidades. Tambm no significa que todos os itens so obrigatrios. Os parmetros a serem medidos devem ser ajustados s necessidades de cada caso.
Servio

Tempo entre falhas, tempo at resoluo de uma falha, tempo de atendimento a chamados, disponibilidade, reclamaes e satisfao do usurio.
Elementos de Rede

Roteadores, firewalls, brigdes, switches, etc Ocupao de enlaces, tipos de fluxos, classificao de servios, compresso, fragmentao, filas, utilizao de regras de FW e ACLs, etc.
Servidores

Processos e servios oferecidos, aplicaes, vulnerabilidades, memria, espao em disco, processos, arquivos abertos, conexes ativas e parmetros particulares dos diversos servios como impresses, acessos a sites, SMS enviados/recebidos, etc.
A Rede

88

Atraso, jitter e perdas entre pontos estratgicos e ocupao de enlaces.

Estaes de usurios

Status, utilizao de CPU e memria, espao em disco, processos, arquivos e programas utilizados, arquivos copiados de/para unidades de discos mveis, etc.
Ambiente

Temperatura, umidade, quantidade e horrio de acessos a salas especiais, partculas em suspenso no ar, etc.

O que monitorar VoIP

Tambm devem ser considerados os itens a seguir.
Servidor de bilhetagem

Sincronismo, tamanho de tabelas, quantidade de registros, etc, status do sistema, utilizao de CPU e memria,
Proxies

Desempenho, tempo de ocupao de canais, motivos de desconexo, quantidade de ligaes simultneas, etc.
A experincia do usurio

Clculo de MOS e Fator-R.

Sistemas de monitoramento
Qualquer sistema que busque informaes na rede, que armazene os dados e que os apresente de forma inteligvel um sistema de monitoramento. Basta que a informao medida fique disponvel ao longo do tempo, formando uma srie histrica. Existem diversos sistemas de monitoramento disponveis com vrias nfases diferentes. Por exemplo, na rea de segurana, pode-se citar o SNORT, que se utiliza de medies passivas para capturar e analisar fluxos de comunicao, e o NESSUS, que utiliza medies ativas para verificar vulnerabilidades conhecidas nos servidores da rede.

89

A Rede Nacional de Ensino e Pesquisa (RNP), em parceria com diversas universidades, est desenvolvendo um servio de monitorao de sua rede, a rede Ip. Ainda como um servio experimental, o MonIP (43) utiliza o perfSONAR (44), uma infra-estrutura de monitoramento de redes, que combina idias de outros sistemas de monitorao e os integra para fornecer informaes detalhadas para pesquisadores sobre a utilizao dos recursos da rede de pesquisa.

SNMP
SNMP significa Simple Network Management Protocol ou Protocolo simples para gerncia de redes. Como o nome diz, SNMP um protocolo utilizado na gerncia de redes, resgatando dados de diversos dispositivos na rede IP. Ele no um sistema de monitoramento, pois sua funo no apresentar dados. Entretanto, o SNMP o principal suporte dos sistemas de gerncia de redes. Atualmente o protocolo est na verso 3, definidas nos documentos RFC-3411 (45) e RFC-3418 (46), que define as MIBs. Outro documento importante a RFC-3584 (47), que trata da interoperabilidade entre as diferentes verses do SNMP. Sua arquitetura bsica formada por 3 componentes: Master Agent: (Agente mestre) um software executado em um dispositivo monitorado com suporte a SNMP que interage com uma estao de monitoramento. o equivalente a um servidor e faz a integrao entre os subagentes e as estaes de gerncia. Subagent: (Subagente) um software que trata de monitorar recursos especficos do dispositivo, por exemplo, erros na interface de rede ou quantidade de memria utilizada, e repassa a informao para o agente mestre. Os subagentes tambm modificam parmetros especficos e so responsveis por gerar alarmes (TRAPs). Management Station: (Estao de gerncia) essa entidade que envia requisies em intervalos regulares de tempo e armazena as informaes para formao das sries histricas e para posterior anlise. Ele tambm recebe alarmes (TRAPs) gerados nos dispositivos monitorados.

90

O SNMP possui 3 comandos ou mtodos bsicos: GET, SET e TRAP. GET: enviado pela estao de gerncia para os agentes para solicitar alguma informao sobre o dispositivo monitorado. SET: enviado pela estao de gerncia aos agentes para estabelecer algum parmetro no dispositivo monitorado. TRAP: enviado pelo agente no dispositivo monitorado para informar a estao de gerncia sobre alguma condio adversa, previamente configurada.

O SNMP prov uma forma para resgatar informaes nos dispositivos, mas no define que informaes devem ser resgatadas. As informaes a serem medidas so chamadas de objetos e so definidas pelas MIBs, Managemant Information Bases. Existem MIBs padres, por exemplo, para medir parmetros comuns de redes, mas cada fabricante deve desenvolver sua base de objetos e especificar que itens so passveis de monitoramento em seu dispositivo ou servio. As MIBs representam os objetos em uma estrutura de rvore. Cada objeto nico em toda rvore, conforme ilustrado na Figura 26.

91

Figura 26: MIB: rvore de objetos http://www.cisco.com/en/US/docs/ios/internetwrk_solutions_guides/splob/guides/dial/dial_ nms/snmpover.html

Entretanto, o SNMP sozinho no til. preciso apresentar os dados e tomar decises. Os programas que executam tais tarefas so chamados de NMS, Network Management Systems. Eles so mais bem descritos adiante.

Gerncia
Gerenciar significa aplicar conhecimentos, habilidades e tcnicas na elaborao de atividades relacionadas para atingir um conjunto de objetivos pr-definidos. Resumidamente, e de forma mais direta, gerenciar significa controlar aes. Antes de qualquer coisa, preciso conhecer o ambiente a ser gerenciado e saber como evolui as diversas atividades inerentes aos processos do que se precisa gerenciar. Da a

92

necessidade de se manter sries histricas dos eventos e estados dos objetos a serem gerenciados. Em redes, preciso tomar decises sobre atividades relacionadas ao bom funcionamento da mesma. Pode-se definir gerncia de redes como sendo as aes de monitoramento e controle dos equipamentos e servios de uma rede de comunicao, incluindo aes de carter mais administrativo como controle de inventrio e monitoramento de mudanas. Dessa forma, alm de realizar medies e monitorar enlaces e equipamentos, procedimentos de gerncia de redes incluem executar aes de controle e correo para manter a rede funcionando de acordo com parmetros pr-estabelecidos. Esses parmetros pr-estabelecidos podem assumir valores acordados

internamente, como metas a serem alcanadas, ou tambm podem ser os requisitos mnimos de prestao de servio contratados de uma operadora ou mesmo ofertado a um cliente. Nesse ltimo caso, os tais parmetros tambm so conhecidos como SLA, ou Service Level Agreement.

Modelos de Gerncia
A gerncia de redes de telecomunicaes tem sido alvo de estudos desde que as primeiras redes comearam a existir. Ao longo do tempo foram desenvolvidas metodologias que auxiliam nessa tarefa. Embora a formalizao desses modelos tenha acontecido h relativamente pouco tempo, a gerncia de redes sempre foi um grande problema a ser resolvido. Os trs principais modelos de gerncia so: TMN Telecommunications Management Network: desenvolvido pela ITU em maio de 1996 na recomendao M.3010 (48). O foco principal deste modelo est na prestao do servio e nos negcios. FCAPS Fault, Configuration, Accouting, Performance, Security: desenvolvido tambm pelo ITU em 1997 na recomendao M.3400 (49). O foco principal do FCAPS est na tecnologia que suporta o servio.

93

ITIL Information Technology Infrastructure Libarary 10 : um conjunto de conceitos e tcnicas para gerncia de infra-estrutura, operaes e desenvolvimento em tecnologia da informao. Foi desenvolvido pelo UK Central Computer and Telecommunication Center. Teve sua adoo em massa em meados dos anos 90. O ITIL est focado em processos e na eficincia das atividades. A Figura 27 a seguir mostra como o modelo de gerncia ITIL se relaciona a um sistema de gerncia de redes.

ITIL v3 Service Strategy Service Design Service Transition Service Operation Continual Service Improvement

NMS Viso do todo (da rede e de cada servio) Perfis e tendncias Documentao e Histricos Alarmes, diagnsticos e aes corretivas em tempo real Conjunto de solues + outras ferramentas de medio

Figura 27: Associao entre ITIL e NMS Alm dos modelos de gerncia, ainda existem as recomendaes de boas prticas para gerncia de redes, servios e recursos de TI. Normalmente desenvolvidos por entidades e organizaes especializadas, elas no pretendem ser um padro rgido e imutvel. Pelo contrrio, esto em constante evoluo e possuem a capacidade de se adaptar ao modelo de negcio de quem as adota e a tendncias da poca. Dois bons exemplos so: COBIT Control Objectives for Information and related Technology: um conjunto de melhores prticas formulado como um framework para gerncia de tecnologia da informao. Foi desenvolvido pelo ISACA, Information Systems Audit
10

Mais informaes sobre ITIL em http://www.itil-officialsite.com/home/home.asp .

94

and Control Association. SoGP Standard of Good Practices: uma documentao detalhada de boas prticas com foco em segurana da informao. A primeira publicao foi em 1996 e a cada dois anos o padro revisado e publicado pelo ISF, Information Security Forum.

Sistemas de Gerncia podem e devem seguir essas recomendaes. E quanto mais esses sistemas implementam essas recomendaes, mais eles se aproximam da administrao do negcio. Assim, esses sistemas so capazes de integrar os objetivos do administrador de redes e da equipe de TI com os objetivos da prpria empresa, levando em considerao o negcio em questo. Esses sistemas mais evoludos so chamados de EMS Enterprise Management Systems ou Sistemas de Gerncia de Empresas.

Sistemas de Gerncia de Redes

Sistemas de gerncia de redes, do ingls Network Management Systems (NMS), so sistemas capazes de monitorar, armazenar, apresentar e processar informaes. Sistemas mais elaborados so capazes de executar algumas aes corretivas na rede. A maioria deles capaz de enviar alarmes por email ou SMS. Os sistemas de gerncia devem integrar todas as informaes necessrias para a gerncia do servio prestado, tanto a nvel operacional quanto a nvel administrativo. Eles devem apresentar uma viso geral da rede e ao mesmo tempo ser capazes de exibir detalhes de cada um dos servios e dispositivos da rede.

Algumas caractersticas dos NMS

Algumas das principais caractersticas dos sistemas de gerncia de redes so relacionadas a seguir.
Viso geral da rede e dos servios (overview)

importante que o administrador da rede seja capaz de rapidamente determinar se existe ou no um problema na rede. Um grfico geral do estado da rede imprescindvel em um NMS.

95

Ele ajuda o gerente a ter uma viso instantnea completa de como a rede est respondendo naquele momento. Um exemplo dessa funcionalidade pode ser observada na Figura 28.

Figura 28: Viso do todo (overview), histrico e alguns detalhes http://www.rnp.br/ceo/trafego/panorama.php (As informaes so atualizadas constantemente)
Histricos

Manter um histrico do que acontece com a rede e nos dispositivos, mais do que possibilitar a investigao de acontecimentos passados, permite calcular tendncias futuras e assim prevenir falhas simples e evitar a escassez de recursos. No menos importante que o histrico o estabelecimento de Linhas de Base para todos os servios e parmetros que sero monitorados. Com a associao do histrico com as linhas de base, torna-se possvel o clculo da disponibilidade dos recursos. Assim, pode-se verificar, por exemplo, se os acordos de SLA esto sendo cumpridos.

Acompanhamento de aes (Trouble-Ticket)

96

Deve-se tambm manter histrico de todas as decises e aes tomadas sobre a rede. Se algum parmetro for modificado, necessrio registrar quem requisitou a mudana, quando, porque, quem executou e em que circunstncias ele foi modificado. Essas aes so executadas por sistemas conhecidos como Trouble-Tickets. Assim possvel saber, por exemplo, quanto tempo levou entre o pedido de mudana ser feito at a execuo completa da tarefa. Este acompanhamento, entre outros parmetros, pode ser uma medida de qualidade interna.
Alarmes

Basicamente, todas as ferramentas recebem alarmes baseados no protocolo SNMP. Os alarmes podem ser reconhecidos e associados a um responsvel pela resoluo do problema. possvel disparar determinadas aes de acordo com a ocorrncia, seja o envio de mensagens via email ou SMS, ou mesmo um comando para algum servidor. O recebimento de alarmes ajuda muito na identificao de problemas, mas ainda possvel melhorar o diagnstico utilizando o correlacionamento de alarmes. Correlacionamento de alarmes , na prtica, o estabelecimento de uma interdependncia entre eventos e outros parmetros. O correlacionamento de

alarmes faz com que um aviso no dependa apenas de um evento, mas de uma seqncia lgica de eventos e outras condies da rede, diminuindo assim a quantidade de alarmes inexpressivos para o administrador. Por exemplo, Figura 29, um Figura 29: Alarmes correlacionados

problema em A no deve disparar alarmes de R2, S1 e S2. Tambm, os

servios S1 e S2 podem ser relacionados de tal forma que, se apenas um deles para de responder, um alarme amarelo, de mdia severidade, deve ser acionado. O alarme

97

amarelo indica que h um problema, mas o servio continua operando. Mas se os dois atingirem determinado nvel em algum parmetro especfico deve ser acionado o alarme vermelho, de alta severidade, que significa que o servio est inoperante. Um sistema de gerncia de alarmes pode ser inteligente ao ponto de perceber que determinado elemento ou servio da rede est falhando com freqncia e, ao invs de permanecer enviando mensagens para informar que o elemento/servio est com problemas e logo depois avisando que est resolvido repetidamente, possvel correlacionar estes acontecimentos e acionar novo alarme atentando para este fato, indicando a intermitncia do elemento ou servio. Alm disso, os alarmes precisam ser tratados, ou seja, algum profissional deve assumir a responsabilidade de resolver o problema apresentado. Quando ele resolver ou se precisar de outros recursos, isto deve ser relatado e documentado. Da a necessidade de um mdulo de gerncia de alarmes.
Relatrios

Os relatrios so imprescindveis para que o corpo gerencial da instituio saiba, em termos gerais, o que est acontecendo com sua infra-estrutura de rede. Devem ser emitidos regularmente e sob demanda. Eles so uma ferramenta importantssima que deve facilitar a compresso, principalmente por funcionrios no tcnicos, da situao da rede. Alguns relatrios importantes para um gerente (administrao) so: disponibilidade de servios prestados por terceiros para a empresa; disponibilidade de servios prestados pela empresa para terceiros; as 'N' maiores causas de indisponibilidade.

Relatrios importantes para o responsvel pela operao da rede so os relatrios anteriores mais: circuitos com ocupao de banda acima de um nvel seguro; servidores com ocupao de disco e memria acima de um nvel seguro;

98

os 'N' problemas mais comuns.

Comunicao e apresentao

Os dados capturados na rede ou alimentados por profissionais por si s no dizem nada. preciso que eles sejam organizados e apresentados com objetividade e clareza. Os relatrios precisam trazer informaes relevantes e os grficos precisam traduzir com clareza o que eles pretendem expor. Mesmo para os casos de se delegar alguma tarefa a um profissional, a instruo e documentao devem ser objetivas, de forma a evitar erros e retrabalho.
Operador virtual

Sistemas de gerncia podem ser to sofisticados ao ponto de tomarem decises sozinhos. No apenas enviar emails quando algum parmetro extrapola seus limites. possvel desenvolver rotinas que, baseado em sries histricas e o perfil do trfego naquele momento, seja possvel prever uma situao de risco iminente rede e, antes mesmo do problema ocorrer, o sistema (operador virtual) tome alguma ao. As aes tomadas sem a interveno humana podem ser to simples como bloquear o trfego de algum usurio infectado ou at mudanas de rotas e caminhos virtuais em redes MPLS. Por segurana e para manter um histrico das aes tomadas, cada deciso do sistema deve ser documentada.
Recursos Humanos

To fundamental quanto o software de gerncia o administrador/operador do sistema. Mais que isso, pode-se afirmar que este profissional parte integrante da soluo. De nada adianta um super sistema de gerncia se no houver a lgum capacitado a oper- lo. Independente da soluo adotada necessrio que exista um profissional capacitado a operar e administrar as ferramentas que compe a soluo de gerncia de rede. Ele poder ser o responsvel desde a instalao e configurao de elementos do

99

sistema at a emisso de relatrios personalizados. Os sistemas de gerncia so to complexos que existem cursos especficos para habilitar profissionais na sua operao. Administrar e operar o conjunto de ferramentas que iro formar o Siste ma de Gerncia podem ser tarefas executadas por um ou mais funcionrios. Por exemplo, possvel alocar uma pessoa para cada software componente da soluo de gerncia.

Que ferramenta utilizar

A ferramenta completa para gerncia de redes no existe. Principalmente se a inteno extrapolar os limites da operao de redes e perseguir o controle tambm do setor administrativo do servio prestado. A soluo ideal deve ser composta por um conjunto de ferramentas e procedimentos prprios para cada caso especfico. Foi realizada uma pesquisa dos principais sistemas de gerncia de redes de cdigo aberto disponveis na Internet. Os sistemas de cdigo fechado no foram estudados, pois, por terem objetivos comercias, normalmente seus representantes aceitam encomendas para personalizao e desenvolvimento de mdulos especficos para vrias tarefas. Os sistemas de cdigo aberto normalmente so gratuitos. Algumas empresas cobram por servios especializados relacionados a esses softwares. Engana-se quem acredita que estes softwares, por serem gratuitos, no so confiveis. Eles so utilizados por uma grande variedade de empresas e possuem relatos de casos de sucesso publicados em suas pginas na Internet. Os seguintes sistemas foram contemplados na pesquisa: Nagios http://www.nagios.org OpenNMS http://www.opennms.org Zabbix http://www.zabbix.com Zenoss http://www.zenoss.com GroundWork http://www.groundworkopensource.com/

100

Resultados
A escolha de um ou outro sistema depende das necessidades e capacidade financeira de cada empresa. Portanto, no indicado nenhum desses como soluo ideal. Todos devem ser encarados como solues possveis. Ao invs disso, a sugesto estudar, testar e confrontar com as necessidades e possibilidades de cada caso. O Nagios , sem dvida, o NMS de cdigo aberto mais utilizado. Todos em congressos e reunies usam ou conhecem algum que usa o Nagios. o mais antigo e bem sucedido NMS de cdigo aberto. Existem empresas de consultoria em redes e integradores de soluo que oferecem suporte e treinamento no Brasil. O OpenNMS mostra preocupaes mais gerenciais e procura seguir o FCAPS. Seu manuseio no parece ser muito fcil, mas um timo sistema. No h verso paga, mas tambm no h suporte no Brasil. Entre os sistemas analisados o que mais se aproxima de um EMS. Zabbix est sendo bastante comentado e comea a aparecer com alguma fora. Parece ser mais simples e tem uma apresentao agradvel. No h parceiros no Brasil, portanto no h suporte oficial. Zenoss e GroundWork so os sistemas de cdigo aberto com maior apelo comercial. Talvez isso faa deles os mais completos j que, assim como os grandes players, quando algum cliente precisa de uma nova funcionalidade eles cobram para implement-la. preciso ter ateno com as verses livres, pois elas so limitadas. Existem empresas que prestam suporte na soluo Zenoss no Brasil. O Groundwork baseado em outros aplicativos de cdigo aberto, inclusive o Nagios e no esconde este fato. Ao contrrio, usa essa situao como propaganda favorvel, tentando se promover como um integrador de solues consagradas. Tambm possui um forte apelo comercial, mas no h suporte no Brasil. Entretanto, a Unisys parceira do Groundwork. Todos os sistemas permitem a criao de mdulos que ainda no tenham sido implementados para monitorao de novos servios. A seguir, a Tabela 7 sintetiza resultado da pesquisa.

101

Nagios Verso Gratuita e/ou Comercial Gratuita

OpenNMS Gratuita No No Muito boa No Sim Sim No

Zabbix Gratuita No No Boa Sim Sim Sim No

Zenoss

Groundwork

Gratuita e Comercial Gratuita (3 verses) Sim No Muito boa Sim Sim Sim 1 parceiro No No Pobre No Sim Sim No, mas a Unisys parceira

Comercializa dispositivo especfico Sim para gerncia de redes? Comercializa servio de monitoramento remoto? Documentao e suporte on-line (aberto) Possui suporte on site? Possui servio de consultoria? Possui treinamento? No Muito boa Sim Sim No

Possui parceiros/representao no 2 parceiros Brasil?

Sistema Operacional Interface Calcula disponibilidade Calcula tendncias Gerncia de inventrio Auto-discovery

Linux e *nix Web No No No

Linux, Windows, PPC, BSD e Solaris Web Sim No No

Linux, AIX, *BSD, HPLinux, VMWare UX, MacOS, Solaris Web Sim Sim No Sim Sim, utilizando complementos Sim No informado Sim Sim Web Sim Sim Sim Sim Sim, utilizando ZemPacks. Sim Automtico Sim Sim No

Linux, VMWare Web Sim Sim Sim Sim Sim Sim Automtico No Sim No

Sim, por software de Sim terceiros Sim, configuraes especficas. Sim No. Trabalho em progresso. No Sim

Monitora dispositivos novos ou de Sim, utilizando terceiros plugins Reconhece TRAPs SNMP nativamente Desenha mapa lgico da rede (automtico ou manual) Localiza dispositivos geograficamente Correlacionamento de eventos Suporte a NetFlow Sim, com aplicao de Patches. Automtico No No No

Sim. Integrao com No outro software.

Tabela 7: Comparao entre NMS'es de cdigo aberto

Concluso NMS e VoIP

Apesar de alguns sistemas como o Zabbix j oferecerem mdulos para

102

monitoramento de alguns telefones IP e do Asterisk, um PABX IP de cdigo aberto muito utilizado atualmente, nenhum desses softwares possuam solues completas especficas para VoIP na poca da anlise. Ainda no possvel, por exemplo, medir ou calcular o MOS de ligaes. Se essa funo for necessria em algum projeto, ser preciso implement- la. Felizmente, essa tarefa possvel para profissionais capacitados j que os sistemas apresentados so de cdigo aberto.

103

Captulo 6 Adotando a Telefonia sobre IP

Todos os requisitos para implementao e gerncia de um servio de telefonia IP foram apresentados nos captulos anteriores. A prxima tarefa organizar o contedo apresentado de forma a planejar a implantao ou migrao do servio de telefonia IP. Este captulo apresenta uma metodologia para implantao, operao e gerncia do servio de telefonia IP em mdias e grandes empresas, aplicando prticas que podem ajudar a garantir o sucesso e a continuidade do servio.

Introduo
No novidade que VoIP (Voz sobre IP) a palavra do momento. As promessas de grandes economias e rpidas implantaes seduzem a todos, mas pode provocar algumas situaes indesejveis. A convergncia entre voz e dados (utilizao da rede de dados pr-existente para trfego de voz e imagens) e seu forte apelo reduo de custos esconde algumas armadilhas e as empresas que decidem migrar seus sistemas legados de voz precisam estar atentas a elas. Quando se planeja uma nova rede baseada na tecnologia de voz sobre IP, as dificuldades so mais amenas, pois no haver impactos em servios pr-existentes, nem necessidade de adaptao de funcionrios. Simplesmente, as operaes iniciam da forma como foram planejadas. J no caso de uma migrao de tecnologia, necessrio avaliar todos os impactos dessa modernizao, principalmente se o ambiente for heterogneo, quanto a protocolos e fornecedores. Para se conseguir qualidade e confiabilidade do novo sistema de voz, necessrio avaliar todas as alternativas, seus pr-requisitos e implicaes nas reas afetadas por elas. Dentre essas reas, pode-se citar: 1) os investimentos, a economia gerada e o tempo de retorno; 2) os servios de rede agregados ou perdidos; 3) adaptao e aceitao dos usurios do sistema e; 4) reavaliar os procedimentos e as equipes de gerncia e manuteno da nova rede. A relevncia tcnica e as dificuldades encontradas no trabalho de modernizao de sistemas de voz se mostram interessantes do ponto de vista acadmico devido a

104

diversidade de softwares, protocolos e fornecedores envolvidos e ao compromisso com a eficincia na implantao, gerncia e manuteno. Tudo isso culmina e m um roteiro de anlise e implantao que garantir o sucesso de projetos futuros.

Antes de comear
VoIP realmente necessrio?
O projeto para adoo de VoIP nem sempre comea com a aplicao da tecnologia. Principalmente, se o objetivo do projeto for reduo de custo. Antes de qualquer outra coisa, a pergunta a ser respondida se realmente necessrio instalar um ambiente de telefonia IP. Existem casos que mostram que nem sempre vantajoso implantar VoIP. importante verificar que benefcios ela pode trazer e considerar os riscos da adoo da nova tecnologia. Alm disso, existem aes que pode m reduzir significativamente o custo com telefonia em uma empresa. Renegociao de contratos, contrata o de troncos celulares, criao de uma poltica interna de uso, capacitao e simplesmente uma campanha para mudana (re-educao) de hbitos podem trazer resultados excelentes. Contudo, supe-se que a resposta ao ttulo da seo seja afirmativa. Ento, inicia-se efetivamente a fase do planejamento do projeto.

Consideraes iniciais
A implantao do servio de telefonia IP uma tarefa complexa, merecedora de toda ateno. Deve ser tratada como um projeto, como de fato ela ; e no como uma tarefa. Tudo comea com um bom planejamento. Deve-se utilizar tcnicas e conceitos de gerncia de projetos para comear a trabalhar na implantao. H de se considerar tempo para execuo, recursos humanos e financeiros, riscos, mudanas ao longo da implantao e tudo mais que existe em um projeto qualquer. Procurar ajuda de profissionais especializados quando estiver definindo as caractersticas do projeto muito til, independente da formao de quem est implantando o servio. Se for um

105

gerente, deve procurar auxlio de um especialista em VoIP; se for um profissional de formao essencialmente tcnica, deve procurar um gerente de projetos. Aps a implantao, recomendvel mapear os processos inerentes a prestao do servio, gerncia de redes, gerncia de TI, tratamento de incidentes e tudo mais que diz respeito a operao do sistema. Aqui cabem as sugestes de boas prticas vistas anteriormente. importante que se conduza todo o processo, do planejamento do projeto de implantao at a operao e gesto da rede, orientando-se pelos padres tcnicos e recomendaes de boa prtica de gesto e de segurana. preciso ter sempre preocupaes com segurana e continuidade dos processos. No final, isso que importa.

Planejamento
Definio do escopo Pblico alvo
preciso definir quem ser o pblico alvo atingido pelo servio de telefonia: todos os funcionrios, uma parte deles, apenas tele- funcionrios, parceiros, o pblico em geral.

Alcance das ligaes

Deve-se definir o alcance das ligaes. Sero somente internas, locais, interurbanas, internacionais, e se recebe ligaes a cobrar. De ve-se definir tambm se havero grupos de ramais com pe rmisses distintas dos outros.

Servios complementares
importante conhecer os servios complementares suportados pelo sistema: transferncia, conferncia, captura de ligaes, caixas postal de voz, envio de recados por email, envio de fax, gateway de fax para email e de email para fax, gravao de ligaes, grupos de chamadas, reconhecimento de voz, integrao com banco de dados, etc. necessrio defini- los na fase de planejamento.

106

Dimensionamento Perfil de trfego

muito importante saber qual ser a demanda do servio, tanto interna quanto externa, ou seja, as ligaes dentro da empresa, as ligaes para fora da empresa e quais seus destinos e, as ligaes de fora para dentro da empresa. Tambm importante conhecer o tempo de cada chamada. Uma das anlises mais importantes no planejamento de uma rede de telefonia IP consiste em conhecer o interesse de trfego de dados e de voz de seus usurios. A combinao dos dois permite dizer se possvel utilizar a rede de dados para transportar todos os fluxos de voz demandados pelos usurios sem realizar upgrades nos enlaces, se existirem. A anlise dos resultados ir dizer se necessrio aumentar a velocidade dos enlaces ou se necessrio a implantao de regras de QoS como priorizao de pacotes de voz. Para as ligaes realizadas de dentro para fora da empresa, a anlise de trfego ir apontar quantos canais de voz so necessrios para atender a demanda. O estudo tambm deve indicar onde esses canais devem ser instalados, no caso de haver unidades distribudas geograficamente. No se deve deixar de considerar a demanda reprimida. A tecnologia de Voz sobre IP est associada a ligaes com custo muito baixo. Isto pode motivar os usurios do sistema a realizar mais ligaes e ligaes de durao maiores do que as que vm ocorrendo no momento da medio, antes da implantao. Estimar a demanda reprimida no uma tarefa fcil. Cada caso deve ser analisado cuidadosamente. Se os canais de sada j esto ocupados e existem ligaes sendo descartadas por falta de recursos, necessrio verificar nos relatrios dos PABX e/ou das operadoras quantas ligaes esto sendo perdidas por falta de recursos. Se ainda no existem chamadas sendo descartadas por falta de recursos, a demanda reprimida ser funo exclusivamente de caractersticas comportamentais dos usurios. Neste caso, deve ser

107

levada em considerao a cultura dos usurios do sistema em questo, se haver divulgao da mudana, o que ser divulgado e como ser divulgado.

CODEC
A banda total a ser utilizada deve ser funo da demanda de chamadas e do CODEC utilizado nas conversaes, mais a banda utilizada pelas aplicaes de dados. Cada chamada VoIP consome normalmente entre 30kbps e 90kbps da rede IP, dependendo do CODEC utilizado nas ligaes. O CODEC livre (sem custo) que consome menos banda e ainda mantm boa qualidade o GSM, consumindo cerca de 35 kbps na rede IP para cada ligao. Infelizmente, nem todos os fabricantes incluem o GSM em seus equipamentos. O CODEC de melhor custo-benefcio e o padro de fato adotado pelo mercado o G.729, com qualidade muito boa e consumo de banda de cerca de 30 kbps. O CODEC padro G.711 possui o melhor MOS, mas consome cerca de 90 kbps e seu uso s recomendado quando a banda abundante, como em uma LAN.

Fornecedores de conectividade
De acordo com a demanda projetada na fase de dimensionamento, define-se agora a quantidade de fornecedores, quais sero contratados e a tecnologia utilizada nos troncos de voz. recomendvel definir os parmetros desejados de SLA neste momento. A estratgia de escolha de fornecedores muito pessoal e pode variar consideravelmente. A opo de apenas um fornecedor pode ser til para conseguir descontos por conta do volume de negcios concentrados e a ttulo de fidelizao. Por outro lado, possuir vrios fornecedores pode favorecer uma competio entre eles, forando a queda nos preos. preciso lembrar que quanto mais fornecedores, mais contratos devero ser gerenciados. Alm disso, possuir muitos fornecedores tambm implicar em vrias regras para confrontao de medies no caso de descumprimento dos SLAs acordados. Se for o caso, tambm deve se definir os fornecedores de acesso a Internet e os fornecedores de links WAN, que ligaro os pontos remotos. Se estes enlaces j

108

existirem e for preciso algum upgrade, recomendvel rever as condies do contrato e redefinir os parmetros de SLA desejados.

Parceiros
Algumas empresas que possuem um relacionamento num grau que configure um grande interesse de trfego de voz entre elas, podem querer interligar seus servios de telefonia. Dessa forma, as ligaes entre elas no passariam pela rede pblica e no seriam tarifadas. Se houver parceiros para troca ou encaminhamento de trfego de voz, faz-se necessrio definir as condies do acordo de parceria e como o encaminhamento das ligaes e a interligao das redes sero executados.

Plano de numerao e discagem

O plano de numerao uma parte importante do planejamento porque pode definir a como o novo sistema se integrar com o sistema legado, se ele existir. O plano de numerao deve ser planejado de tal forma que no oferea resistncia ao crescimento do servio de telefonia. Deve ser levada em considerao a localidade dos ramais, a quantidade de ramais, os servios oferecidos pela rede, o bloco de numerao DDR se ele existir, etc. Nem sempre trivial conseguir organizar ramais em coincidncia com a numerao pr-existente, principalmente se a empresa est distribuda geograficamente. Se h inteno de contratar blocos DDR, bom conhec- los antes de planejar a numerao dos ramais, se for possvel. O plano de numerao tambm define como sero acessados os servios oferecidos pela rede e o acesso s redes parceiras, se for o caso. Uma estratgia comum utilizar nmeros de 4 a 6 dgitos e dar significado a estes dgitos. Por exemplo, num nmero de 6 dgitos, PQ MCDU, os dois primeiros dgitos PQ poderiam designar o cdigo de rea da cidade onde a filial de uma empresa hipottica se encontra, o dgito M poderia significar o setor da empresa onde o ramal se encontra ou o acesso a servios e os trs ltimos dgitos, CDU, poderiam designar o ramal propriamente dito.

109

Recursos humanos
Para por em prtica o projeto, pode ser necessrio contratar profissionais, capacitar os que so da casa ou ainda contratar servios especializados. A participao de pessoas realmente capacitadas imprescindvel para o sucesso do projeto. Possuir ferramentas que atendam a todas as necessidades da empresa, mas no ter um profissional que saiba utiliz- las desperdcio e produz o mesmo efeito de no possuir as tais ferramentas.

Preparao da infra-estrutura Redes locais

necessrio homologar a rede IP que dar suporte ao servio de telefonia. Se a rede j existe, deve-se verificar se ela suporta a nova demanda de trfego. Podem ser utilizados geradores e medidores de trfego de cdigo aberto. necessrio verificar tambm as instalaes fsicas, cabos, conectores, dutos de passagens, etc. necessrio que se certifique que a rede IP ir suportar o servio de telefonia. recomendvel a utilizao de switches gerenciveis que suportem PoE, VLAN e priorizao de frames ethernet, principalmente nos casos onde intenso o trfego de dados.

Enlaces WAN
Independente da anlise das demandas de voz e dados, recomendvel considerar a adoo de regras de QoS como priorizao dos pacotes de voz para os enlaces de longa distncia de menor velocidade. Mesmo que haja banda suficiente, nunca se sabe quando um ataque ir acontecer, um vrus ir se manifestar ou um funcionrio far o download daquele lanamento. Caso o enlace WAN esteja prximo da saturao, deve-se considerar a utilizao de compresso de cabealho e fragmentao e interposio. Caso o interesse de trfego entre as localidades ligadas seja maior do que duas ligaes simultneas, pode ser til considerar a utilizao do protocolo IAX2, desde que a soluo se utilize do PABX Asterisk.

110

Fornecimento de energia
necessrio verificar se h condies de fornecer energia para todos os novos equipame ntos. Se forem utilizados telefones IP, necessrio certificar-se que havero tomadas extras nas mesas. Se utilizar PoE, o sistema deve suportar a nova demanda de energia dos switches ou injetores nos racks. O sistema ininterrupto de fornecimento de energia deve ser revisto e redime nsionado. A demanda por energia ir aumentar, logo o tempo que o UPS ir suportar pode diminuir consideravelmente. Recomenda-se verificar a qualidade do aterramento e do sistema de proteo de surto. Com mais equipamentos ligados na rede, maior ser o prejuzo caso haja algum sinistro.

Tecnologia e fornecedores
Trs tecnologias utilizadas em servios de telefonia IP so discutidas nesta dissertao. O H.323 e o SIP so apresentados por serem os protocolos mais utilizados e por possurem amplo suporte dos mais variados fornecedores. O IAX apresentado por suas vantagens quanto economia de banda e transparncia a implementaes de NAT e por ser o protocolo nativo do PABX IP de cdigo aberto mais utilizado atualmente, o Asterisk. Para a aquisio do PABX e dos telefones, levando em considerao os itens abordados nos tpicos anteriores e ponderando a respeito de fornecedores, suporte oferecido, custos envolvidos em contratao, manuteno e treinamento e da orientao adotada e a cultura da empresa onde a implantao do sistema de telefonia IP est ocorrendo, definem-se agora a tecnologia, os equipamentos e os fornecedores que sero utilizados. Para os enlaces de dados e de voz, necessrio considerar a contratao de redundncias e o planejame nto de alte rnativas contra falhas dos links . Para os enlaces de voz, ainda possvel considerar as tecnologias tradicionais e contratar um link TDM ou j possvel contratar um link SIP, H.323 ou at IAX2. J existem empresas que oferecem este servio.

111

recomendvel evitar o uso de diferentes protocolos, a no ser em casos especiais como troncos VoIP. Alm das vantagens e desvantagens a serem consideradas em uma rede heterognea, as tradues de protocolos nos gateways contribuem para aumentar o tempo de estabelecimento das chamadas e podem aumentar o consumo de recursos nos gateways. Tambm recomendvel evitar as converses de CODECs. As tradues aumentam o atraso fim-a- fim, degradam a qualidade do som e ainda aumentam consideravelmente a consumo da capacidade de processamento dos gateways.

Novas aquisies Aquisies de atualizaes

Se a implantao estiver sendo realizada em uma rede pr-existente, possvel aproveitar os equipamentos legados, evitando o desperdcio do ltimo investimento feito neles. Se este for o caso, ser necessrio verificar quais so as partes adicionais e atualizaes necessrias ao sistema legado. Deve-se atentar para os custos da atualizao e de novas licenas. Em algumas situaes pode ser mais vantajoso substituir a infra-estrutura de telefonia existente. Em outras, pode ser melhor manter os equipamentos e interligar as redes como sugerido.

Aquisies de equipamentos novos

necessrio homologar os novos equipamentos que sero adquiridos. Se for possvel, deve ser feito um teste antes de efetivar a compra, optando pela modalidade trial-buy, j mencionada anteriormente. Recomenda-se adquirir equipamentos que sejam robustos e tenham uma vida til longa, mas que tambm sejam flexveis o bastante para se adaptarem as novas tecnologias vindouras. No se devem esquecer as peas menores, principalmente se no for contratada uma empresa para executar a implantao. Conectores, cabos, baluns 11 , adaptadores, ferramentas, instrumentos de medio e outros insumos que normalmente no entram
BALUN vem do acronim o BALanced/UNbalance. um equipamento que tem a funo de adaptar meios de transmisso balanceados para meios no balanceados, resolvendo problemas de casamento de im pedncia e reflexo de sinal.
11

112

no detalhamento do projeto. preciso considerar a compra de peas, placas e servidores sobressalentes. Telefonia um servio crtico e no pode parar. Ter peas reservas pode diminuir consideravelmente o tempo de falhas.

Gerncia da rede
A gerncia da rede deve estar em sintonia com os objetivos da empresa. Para facilitar este trabalho, recomenda-se a adoo de algum modelo de gerncia consagrado como o ITIL para gerncia do servio ou COBIT para governana de TI, com viso mais ampla do negcio. Alm disso, cada dispositivo na rede IP, incluindo o PABX e os telefones, so alvos em potencial de ataques externos e internos. Garantir a segurana e a sanidade da rede atribuio do gerente da rede. Ento, recomenda-se tambm a adoo de boas prticas de segurana como o SoGP. Um Sistema de Gerncia de Rede adequado necessidade e capacidade da empresa deve ser escolhido. Deve-se considerar sistemas complementares para auxiliar a gerncia ou devem ser consideradas adies e modificaes em sistemas fechados. A gerncia da rede pode ser executada por empresas terceirizadas, entretanto no recomendvel delegar a terceiros algo to importante para manter a qualidade do sistema. Se ainda assim for um desejo do gestor manter a terceirizao dessa tarefa, h de se calcular os custos de aquisio de software e treinamento e compar- los ao custo da terceirizao em longo prazo. Assumindo que a terceirizao no uma opo e a gerncia ser feita internamente, necessrio capacitar os funcionrios na plataforma escolhida. No adianta ter um sistema que no se pode controlar. Alm disso, para tirar vantagem de todo o potencial do sistema ser preciso conhec-lo profundamente. A implantao da rede de telefonia no reduz a necessidade de se conhecer o perfil de trfego de voz. Pelo contrrio, agora o histrico de ligaes pode apontar tendncias e revelar onde necessrio contratar mais recursos de rede e onde estes recursos esto superdimensionados. Portanto, recomenda-se manter uma base de dados com o detalhamento de todas as chamadas da rede, mesmo no havendo a necessidade

113

de cobrana. Por analogia, o mesmo princpio pode ser dito a respeito do trfego de dados. importante analisar os relatrios que o sistema de gerncia capaz de emitir. Eles existem por algum motivo. E o motivo que eles oferecem uma forma rpida e prtica de conhecer o que est acontecendo com o servio e com a rede. Eles ajudam a corrigir falhas e a prever tendncias, possibilitando a adaptao s novas demandas antes mesmo delas se concretizarem.

Problemas em ToIP
Deve sempre haver uma alternativa ao plano principal. Mesmo se tudo o que foi planejado falhar, o servio de telefonia crtico e no pode parar. O plano alternativo deve ser de conhecimento de todos os responsveis para que ele seja rapidamente implementado e o servio possa ser reestabelcido.

Evite problemas desde o planejamento

To importante quanto conhecer as foras de uma tecnolo gia, conhecer as fraquezas. As prximas recomendaes tratam de problemas ligados a alguma fraqueza do VoIP.

Ateno com firewall e NAT

Dependendo da tecnologia adotada, implementaes de NAT e firewall podem representar a inoperncia do servio de telefonia. Como foi verificado nos captulos anteriores, SIP e H.323 utilizam um canal de controle, com portas conhecidas, para negociar os canais de transporte da voz, com portas aleatrias. recomendvel evitar que o trfego de voz passe por esses equipamentos. Se no for possvel, necessrio estudar as alternativas e, antes de colocar o servio em produo, deve-se test- lo e homolog-lo.

VoIP est longe de ser um meio adequado de enviar e receber fax.

Grande parte dos problemas reportados por usurios da tecnologia de voz sobre IP a respeito da troca de fax. possvel conseguir resultados razoveis para pessoas e

114

empresas que usam pouco o fax. Mas para quem faz uso intensivo deste recurso recomendvel utilizar uma linha telefnica tradicional. Uma alternativa utilizar solues como gateway fax-email e email- fax.

O mesmo pode-se dizer de mquinas de carto de crdito.

Os CODECs utilizados em VoIP foram desenhados para comprimir a voz e no para transmitir sinais analgicos. Neste caso, tambm possvel obter algum sucesso em implementaes menos exigentes. Mas tambm bom evitar o uso das mquinas de TEF (Transferncia eletrnica de Fundos), as mquinas de carto de crdito, com VoIP. Existem duas alternativas bvias para este problema: utilizar uma mquina com interface Ethernet ou uma com interface GPRS, muito comum hoje em dia.

Alguns sistemas de alarmes tambm utilizam a linha telefnica para dados

Alguns sistemas de alarmes utilizam a linha telefnica para enviar dados para a central de alarmes. Novamente encontra-se a tentativa de enviar dados por um meio que foi desenhado para transportar voz digitalizada. preciso verificar as alternativas com a operadora do sistema de alarmes ou utilizar uma linha exclusiva para o sistema.

VoIP precisa de energia!

Quando falta energia, o telefone tradicional no para. VoIP precisa de energia para manter ligado os equipamentos de rede e para o prprio telefone. Alm disso, o acesso com a Internet ou enlace com as reas remotas da empresa precisam estar funcionando corretamente. A utilizao de no-breaks e geradores manter o sistema ligado por muito mais tempo. Um bom UPS essencial para essas situaes.

As operadoras no so perfeitas
Sobre a estabilidade das conexes de rede, recomendvel manter um acordo de SLA com o fornecedor. Na verdade, isto no garante que o enlace no fique indisponvel, mas a multa pode estimular a operadora a manter os enlaces disponveis.

115

No caso de acionamento do contrato de SLA, o pagamento da multa por parte da operadora pode ajudar a cobrir eventuais prejuzos. Portanto, tenha um plano B para o caso de falha nos enlaces de dados.

No espere que a rede tenha um bom desempenho 100% do tempo

Problemas acontecem! E normalmente no h nenhum aviso. Um ataque ou vrus que congestione seu link de dados pode prejudicar bastante a qualidade da voz. Um conector mal encaixado pode causar problemas para as ligaes, mesmo que ainda se consiga navegar na Internet. recomendvel considerar a utilizao de regras de QoS (priorizao de pacotes), tanto para LAN quanto para WAN, mesmo quando existir banda disponvel. Alm disso, preciso seguir os padres e as melhores prticas na execuo de qualquer tarefa. Tambm recomendvel a realizao de revises peridicas na rede fsica.

Problemas da fase de operao

A Tabela 8 apresenta uma lista de problemas comuns encontrados em redes de Voz sobre IP. Usurio percebe Possvel causa Possvel ao corretiva

Dificuldade para entender a Congestionamento na rede, Priorizao de trfego e voz. Voz falhando o u gerando perda de pacotes contratao de mais banda. ou alto jitter. Alta latncia e m isolao Utilizao de canceladores acstica do fone do de eco; No utilizar viva-voz. picotando. Ouve a prpria voz.

interlocutor. Uso de viva-voz. Chamada SIP ou H.323 Possvel completa, ouve nada. mas bloqueio

para O

administrador bloqueio

deve ou

ningu m canais de mdia.

remover o

instalar mdulo adequado no firewall.

116

Chamada SIP ou H.323 Quem

no

ouve

seu Instalar mdulo no firewall

completa, mas apenas um interlocutor pode estar atrs que reconhea chamadas ouve a voz do outro. de NAT. SIP e H.323.

Chamada no se estabelece. Problema de conectividade Caso no seja encontrado ou firewall. problema de conectividade, o administrador bloqueios deve no

verificar firewall. Palavras truncadas,

mas M regulagem do VAD, Regule os nveis de corte o u e m rode aplicativo que orienta as configuraes de udio.

quando o som chega, te m normalmente boa qualidade. softphones.

Tabela 8: Problemas, causas e solues em VoIP

O roteiro
Aps uma exposio mais extensa dos itens relevantes a instalao de sistemas de telefonia IP, com comentrios e sugestes, conclui-se esta seo com o roteiro para implantao do servio de telefonia, apresentado de forma mais direta e objetiva. Este roteiro pode ser utilizado como um checklist a ser seguido. Obviamente, procurou-se abranger situaes diversas que vo desde novas instalao a upgrade de sistemas prexistentes. As caractersticas particulares de cada caso devem ser observadas.

1. Antes de qualquer coisa, VoIP mesmo necessrio? Se objetivo apenas reduzir custos, ento verifique se h alternativas. 1.1. possvel renegociar os contratos de fornecedores? 1.1.1. Revise os contratos com operadora de telefonia fixa 1.1.2. Revise os contratos com operadora de telefonia mvel Se no existirem, considere ouvir suas propostas para grupos

1.1.3. Revise os contrato com operadora de dados 1.2. Existem abusos no uso dos recursos de comunicao? 1.2.1. Faa uma Campanha de conscientizao e reeducao

117

1.2.2. A poltica de uso dos recursos de comunicao est sendo descumprida? Faa conhecer a poltica de uso Se ainda no existe, providencie

2. Implantao ou upgrade da estrutura de telefonia 2.1. Crie um projeto para a implantao 2.2. Forme uma equipe com as competncias necessrias ao desenho e execuo do projeto 2.3. Desenhe os processos inerentes a prestao do servio 2.4. Procure orientar-se por padres e boas prticas conhecidas 2.5. Defina o escopo de atuao 2.5.1. Quem sero os usurios? 2.5.2. Quais os destinos possveis das ligaes? 2.5.3. Existiro grupos com permisses distintas? 2.5.4. Alm das chamadas, que outros servios de voz sero oferecidos aos usurios? Caixa postal, aviso por email, fax, integrao com banco de dados, bilhetagem, etc 2.6. Dimensione o sistema 2.6.1. Analise relatrios dos PABX prprios e da operadora. Determine a demanda esperada para as chamadas: De dentro para fora da empresa De fora para dentro da empresa Dentro da empresa, entre as unidades remotas, se houver

2.6.2. Se houver gravao das chamadas, importante estimar o tempo mdio de reteno para dimensionamento do sistema de armazenamento. 2.6.3. Analise a ocupao dos enlaces de dados, se for utiliz-los para transporte da voz. Decida sobre priorizao de pacotes e/ou contratao de mais banda para os enlaces. 2.6.4. Considere a demanda reprimida e decida onde os canais de voz de entrada e sada devem ser instalados.

118

2.6.5. Procure utilizar apenas um CODEC no sistema. Se no for possvel, procure minimizar a quantidade de tradues necessrias nos proxies. 2.7. Defina o plano de numerao do sistema considerando: 2.7.1. O plano de numerao do sistema legado, se houver 2.7.2. Os servios adicionais que sero disponibilizados na rede e 2.7.3. A faixa DDR que ser disponibilizada pela operadora, se for o caso 2.8. Contratao dos servios de telefonia fixo, mvel e de dados 2.8.1. Defina os SLAs dos contratos 2.8.2. Defina como ser feita a medio dos parmetros contemplados 2.8.3. Contrate os fornecedores 2.8.4. Casos j existam fornecedores, reveja e renegocie os contratos e SLAs. 2.9. Identifique parceiros que possuam interesse em troca de trfego de voz 2.9.1. Defina as condies dos acordos, se for o caso. 2.10. Verifique se sua equipe est capacitada para operar e gerenciar o servio de telefonia. Dependendo da necessidade e estratgia da empresa: 2.10.1. Capacite os recursos atuais 2.10.2. Contrate recursos capacitados a operar os sistemas existentes 2.10.3. Contrate empresas especializadas 2.11. Ateno especial para o SLA, neste caso. Prepare a infraestrutura para suportar adequadamente o novo servio

3. Homologue a rede. 3.1.1. Antes de iniciar o novo servio, verifique se a rede atual o suporta. 3.1.2. Verifique cabos, conectores, switches, fornecimento de energia, polticas de QoS e tudo mais que interfere no transporte dos dados. 3.1.3. Reavalie os enlaces de longa distncia, que unem seus pontos remotos Considere a utilizao de tcnicas que otimizam o uso de banda Considere a utiliza do protocolo IAX2 para uso otimizado de banda para mais de 2 ligaes simultneas Se houver problemas com NAT e Firewalls, considere o uso do protocolo IAX2 3.1.4. Caso se opte por utilizar telefones IP, revise o fornecimento de energia para os mesmos. D preferncia para telefones e switches PoE.

119

3.2. Dependendo da necessidade, considere a contratao de enlaces de voz e dados redundantes . 3.2.1. Para enlaces de voz baseado em IP, pode ser interessante contratar redundncia com tecnologia tradicional TDM. 3.2.2. Tanto para rede interna, quanto para fornecedores, evite utilizar vrios protocolos diferentes, assim como evite utilizar CODECs diferentes. 3.3. Para o caso de reaproveitamento dos equipamentos existentes 3.3.1. Verifique a necessidade de upgrade dos mesmos 3.3.2. Verifique os custos com novas peas e com novas licenas, se for o caso 3.4. Para o caso de novas aquisies de equipamentos 3.4.1. Homologue-os. Faa testes antes de efetivar a compra. 3.5. Caso no se contrate uma empresa especializada para executar a nova instalao, lembre-se das pequenas peas como cabos, conectores e baluns.

4. Sobre a gerncia da rede 4.1. Caso no se contrate uma empresa especializada para operar e gerenciar o novo servio, assegure-se de adquirir tambm equipamentos e peas sobressalentes. 4.2. Assegure-se de instalar um sistema de gerncia adequado necessidade e capacidade da empresa 4.3. Assegure-se tambm de ter recursos humanos adequados para operar e gerenciar o sistema

5. Faa a divulgao do novo servio de acordo com o que se espera dos usurios 5.1. Caso seja o sistema interno de uma empresa, lembre da limitao do recurso 5.2. Caso seja um servio comercial, reforce todas as vantagens.

6. Evite problemas conhecidos 6.1. Firewall e NAT: 6.1.1. Verifique o equipamento suporta SIP e H.323 6.2. Fax:

120

6.2.1. No utilize FAX com implementaes de VoIP. Procure utilizar um gateway emailfax-email 6.3. TEF: 6.3.1. No utilize VoIP com mquinas de pagamento eletrnico 6.4. Alarmes: 6.4.1. Procure no utilizar alarmes com em sua estrutura VoIP. Verifique alternativas. 6.5. Fornecimento de energia: 6.5.1. Procure utilizar um bom UPS 6.5.2. Procure utilizar PoE 6.6. Operadoras: 6.6.1. Tenha um SLA e o utilize, quando necessrio 6.6.2. Tenha redundncias 6.7. Rede IP: 6.7.1. Prepare-se para eventuais problemas de rede Ataques, vrus, falha em rotas, perda de pacotes, etc

121

122

Captulo 7 Casos prticos

Este captulo traz dois estudos de caso relevantes para esta dissertao. Foi possvel aprimorar a metodologia apresentada a partir destes estudos. Alm disso, essas experincias possibilitaram a criao de sugestes a serem aplicadas em projetos de instalao e/ou migrao para VoIP e Telefonia IP. Os dois casos apresentados aqui validam a metodologia descrita no captulo anterior. importante ressaltar que a exposio de ambos os casos foi autorizada pelos ento diretores dessas empresas responsveis pelos projetos. igualmente importante informar que nomes de marcas e modelos de equipamentos aqui citados esto presentes nesse documento para esclarecer e descrever os fatos, experincias e teses realizados. Alm disso, preciso enfatizar que no h nenhum envolvimento comercial do autor ou seu orientador com quaisquer marcas citadas nessa dissertao.

Projeto Piloto F IRJAN GTECCOM / UFF

Apresentao
Este projeto teve por objetivo diagnosticar e planejar a implantao de telefonia IP na instituio. Ele foi dividido em 2 fases: diagnstico e planejamento. O trabalho contemplou um estudo terico dos protocolos e tecnologias envolvidas, considerando caractersticas genricas das solues propostas pelos fornecedores; executaram-se ensaios prticos que objetivaram encontrar a melhor soluo tcnica e econmica para as questes de transparncia de servios e reao a falhas da rede e; props-se um modelo de gerncia de redes e um plano de migrao inteligente, que visava, entre outras coisas, o menor desembolso possvel para a modernizao do parque de equipamentos. A fase de diagnstico cuidou da verificao da rede IP. O trfego de todos os enlaces foi analisado ao nvel de aplicao. Aps os estudos foi possvel afirmar que enlaces precisavam ser aumentados e, principalmente, que estratgia de QoS deveria ser aplicada rede. Os estudos apontaram para a utilizao de DiffServ, definindo-se

123

classes para servios que j existiam e os que iriam ser acrescentados na rede. A fase de planejamento da implantao da rede de telefonia sobre IP, contou co m estudos de interoperabilidade entre diversos equipamentos e protocolos, considerando solues proprietrias e de cdigo aberto. Na segunda fase tambm foi realizado a anlise dos contratos das prestadoras de servio de telecomunicaes, incluindo o operador de telefonia mvel. Tambm foi realizado um estudo que considerava a implantao da soluo de acordo com a economia que esta proporcionava para que ocorresse o menor desembolso possvel durante o processo de migrao. De forma geral, o projeto proporcionou economia da ordem de 60% dos custos com telecomunicaes dessa empresa.

O ambiente
Os equipamentos utilizados no projeto foram:

Ericsson MX-One Opo da Ericsson para substituio do PABX atual (50); Ericsson MD-110 verso BC-09 PABX existente na Sede (51); Siemens HiPath 3800 com interface IP HG-1500 funcionando como gateway na Sede e como PABX nas Unidades remotas (52);

Asterisk representando o software livre, funcionando ora como ora como gateway, ora como cliente, simulando unidade remota com ramais analgicos e softphones (53);

Cisco 1751 com IOS 12.1(5)T10 Portas FXS ligadas a posies de tronco de PABX analgico em Unidades remotas (54);

PABX legados, como Monytel, Alcatel, Digitro e Intelbrs. Estes devero ser substitudos no decorrer do tempo. A FIRJAN tem sua Sede localizada na cidade do Rio de Janeiro e cerca de 50

Unidades Remotas espalhadas pelo estado do Rio de Janeiro. Sua rede de dados baseada no protocolo Frame Relay, onde o n central fica na Sede. Possui roteadores Cisco em todas as unidades. Nas Unidades Remotas, o modelo do roteador 1751 IOS 12.1(5)T10 que possui duas interfaces FXS. A gerncia da rede de dados est

124

centralizada na Sede. A exceo de uma unidade que possui um Tie-Line E1 (R2D) interligando seu MD-110 ao PABX MD-110 da Sede e de um um prdio prximo (chamado de PRDIO1) que possui algumas LPs para ramais fisicamente distantes da Sede, no existe uma rede de voz corporativa. Cerca de 10 Unidades Remotas possuem PABX Siemens HiPath 3800 com placa HG, q ue possibilita a implementao de VoIP, entretanto, na verso atual, apenas com protocolo proprietrio. Outras 20 Unidades possuem PABX grandes, com uma interface E1, algumas linhas analgicas e diversos ramais, mas sem interface IP. Ainda existem unidades com PABX pequenos, sem interface E1, e outras sem PABX, contando apenas com linhas analgicas da operadora local. A Figura 30 ilustra as redes de dados e voz antes da convergncia, como foi descrito nos dois pargrafos anteriores.

Figura 30: Rede de dados separada da rede de voz antes da convergncia.

Fonte: Relatrio interno

Na poca do estudo, no havia gerncia da rede de voz. Cada unidade era responsvel pela poltica de utilizao de seus recursos de voz. Entretanto, a Sede era responsvel pela manuteno das redes locais e dos equipamentos. Com este projeto,

125

pretende-se aumentar o controle da sede sobre os equipamentos das unidades, possibilitando sugestes de melhores prticas para utilizao da rede. A Figura 31, a seguir, mostra uma etapa intermediria do processo de modernizao. Pode se observar que os diferentes ambientes (PABX Siemens co m interface IP, PABX legados sem interface IP e telefones comuns) esto integrados, utilizando a rede IP para o trfego de voz. Esta figura evidencia os roteadores funcionando como ATAs (Analog Telephone Adapter) em todas as localidades onde no h PABX com interface IP. importante atentar para a presena do Dispositivo Inteligente, um novo equipamento inserido no sistema que auxilia o usurio no caso de falhas na rede de dados. Este dispositivo melhor apresentado no decorrer do texto.

Figura 31: Redes de dados e voz durante o processo de convergncia.

Fonte: Relatrio interno

Ainda na Figura 31, apresentado um ambiente alternativo formado por um

126

servidor Asterisk, portanto de cdigo aberto, que pode funcionar como um ATA, um gateway ou ainda como o prprio PABX de alguma localidade. A Figura 32 ilustra como as unidades devero se integrar aps a implantao completa da modernizao da rede de voz. Note que todas as unidades remotas estaro equipadas com PABX Siemens. O gateway tambm dever ser do mesmo fabricante, garantindo que todos os servios suplementares previstos funcionem. Opcionalmente, possvel ter no sistema, um ou mais ambientes baseados em cdigo aberto. Vantagens e desvantagens so discutidas ao longo do captulo.

Figura 32: Rede de voz e dados aps a convergncia.

Fonte: Relatrio interno

O Projeto Piloto
O objetivo do Projeto Piloto foi demonstrar a viabilidade e a melhor forma de uso da tecnologia de Voz sobre IP para a integrao da rede de voz das unidades remotas com a Sede. So propostos a topologia da rede, plano de numerao, mtodos e equipe de gerncia e recomendaes de uso da rede, conseqentemente, conduzindo a uma

127

reduo de custos de telefonia para todas as Unidades. Deve-se saber que um dos fatores que nortearam a pesquisa foi a manuteno de qualidade das redes, garantindo que uma interrupo na rede de dados no pudesse afetar as comunicaes de voz, bem como manter a clareza nas conversaes. A anlise tcnica contemplou a verificao de compatibilidade dos equipamentos dos diferentes fabricantes operando com protocolos abertos SIP e H323. Consideraramse chamadas bsicas e alguns Servios Suplementares, sendo avaliada a transpar ncia de facilidades e a capacidade de expanso da rede. Por fim, como produto desta pesquisa, foi definido o Plano de Migrao da nova rede. Esse Plano de Migrao foi uma soluo em que, com um investimento inicial relativamente baixo, programou-se a renovao do parque de PABX reaproveitando ao mximo o investimento h pouco realizado para adquiri- lo.

Descrio das solues dos fornecedores

Os fornecedores e equipamentos escolhidos para as alternativas de soluo dos testes pilotos so os que na poca formavam a plataforma da rede de voz da associao, alm de uma soluo adotando software aberto. So eles: Siemens, Damovo e um Gateway baseado em software aberto (Asterisk). A Damovo disponibilizou o seu novo produto, o MX-One, que suporta SIP e pretende substituir o MD-110 da Sede. A principal vantagem no necessitar de gateway, possibilitando que as Unidades Remotas sejam configuradas como extenses deste PABX. A principal desvantagem desta soluo, para este caso especfico, o elevado custo de implantao e licenas. Alm disso, demandaria upgrade de todos os PABX das Unidades com equipamento Siemens para que eles suportassem protocolo aberto de Voz sobre IP, e ainda assim o sistema no suportaria Servios Suplementares. Constatou-se tambm que no foi possvel estabelecer uma ligao VoIP entre os equipamentos MX-One e os roteadores Cisco, com a verso de IOS especfica existente nos equipamentos da associao. A soluo da falta de comunicao entre esses equipamentos seria o upgrade do sistema operacional dos roteadores. Entretanto, esta no era uma opo naquele momento, pois tambm implicava em upgrade do hardware

128

do roteador (aumento da memria), que era propriedade da operadora de telecomunicaes. A soluo Siemens foi baseada em um gateway multi-protocolo ligado ao MD110 por interface ISDN. Dispensava qualquer atualizao do PABX atual da Sede e dos PABX das Unidades Remotas que j possuam placa HG. a soluo que, a princpio, seria a ideal, pois alm das questes internas e no relevantes nesta dissertao, trazia mais servios suplementares a um custo aceitvel, ou seja, melhor relao custobenefcio. A soluo com cdigo aberto utilizava um servidor baseado em arquitetura x86. A plataforma contou com sistema operacional Linux e software Asterisk como PBX. Ele funcionou como um gateway multi-protocolo para rede IP sempre utilizando padres abertos para garantir a interoperabilidade com equipamentos de diversos fabricantes. Esta soluo tambm dispensava atualizaes no PABX da sede, mas requeria atualizaes nos PABX das Unidades. Alm do baixo custo de implantao, a vantagem que este servidor poderia atuar como Servidor de Aplicaes da rede de Voz, servindo informaes armazenadas na rede de Dados, sem custos adicionais com licenas de nenhuma espcie. A desvantagem que ele no suportaria Servios Suplementares. Alm disso, as equipes de TI, Telecom e Telefonia necessitariam de treinamento nesta nova soluo.

Testes do Projeto Piloto

As chamadas telefnicas realizadas durante o teste foram contabilizadas e monitoradas no ponto da rede onde se encontram os gateways.

Testes preliminares
O teste preliminar consistiu simplesmente em realizar chamadas entre os equipamentos de telefonia e realizar uma transferncia para outro ramal no equipamento de destino. O objetivo era verificar que os ramais nos diferentes ambientes e fabricantes se comunicam via IP. Nesta etapa no foi necessrio aplicao de QoS na rede de dados. Como citado anteriormente, os equipamentos da Ericsson (PABX MX-One) e da Cisco (roteador 1751 com a verso de IOS instalada) no conseguiram estabelecer uma

129

chamada VoIP utilizando o protocolo aberto SIP. A equipe de engenharia da Ericsson e da Damovo do Brasil verificou que o PABX MX-One capaz de se comunicar com roteadores Cisco, porm com verses mais atuais de IOS. No se determinou qual a menor verso compatvel de IOS. Realizar atualizao nos roteadores que atendiam a instituio no era uma opo. Assim, a soluo de utilizao do MX-One tornou-se invivel naquele momento.

Testes de Facilidades (Servios Suplementares)

O objetivo principal dos testes de facilidades foi verificar a transparncia dos servios suplementares utilizados atualmente no ambiente da FIRJAN e outros que seus funcionrios manifestaram interesse. Tomou-se como referncia, os servios

suplementares previstos pelo protocolo Q.SIG, para redes particulares TDM. Nestes testes, tambm foi analisada a ocorrncia de loops quando uma chamada retorna para o PABX de origem. Por exemplo, quando um ramal A do PABX A chama o ramal B do PABX B e este transfere a chamada para um terceiro ramal C tambm no PABX A. Neste caso, o PABX A deveria desocupar os canais IP e fechar o circuito internamente entre os ramais A e C. O nome desta caracterstica chama-se Loop Avoidance. Esta anlise foi realizada capturando o trfego de voz na rede IP, verificando a desconexo, ou no, do canal de voz. Nenhum teste deste tipo evitou a criao do loop na rede IP. Em todos os testes, cada transferncia ou redirecionamento das ligaes para PABX distintos visto pela rede IP como uma nova chamada.

Teste de Reao a Falhas na Rede de Dados

Nestes testes foram simuladas condies adversas da rede de dados para verificar como a rede e o PABX reagiriam. Foram realizados testes de tolernc ia a perda de pacotes, utilizando diferentes CODECs, e de interrupo total da comunicao junto placa de rede dos PABX e na nuvem IP. Os testes mostraram que os roteadores Cisco e o PABX Siemens conseguem suportar maiores taxas de perda de pacotes devido a algoritmo de predio, que estima

130

valores de pacotes perdidos. Os PABX Siemens e Asterisk so capazes de re-encaminhar as chamadas pela rede TDM no caso de interrupo da rede IP, em qualquer ponto e por qualquer motivo. O roteador Cisco, por estar associado a um PABX analgico, no capaz de identificar interrupes na rede de dados e re-encaminhar as chamadas para rede TDM. Para solucionar tal problema, seria necessrio acrescentar alguma inteligncia neste ambiente, por exemplo, atravs de um servidor Asterisk que monitoraria o enlace e apresentaria ao usurio uma mensagem de orientao.

Testes de aceitao dos usurios

O principal objetivo dos testes de aceitao dos usurios avaliar como os verdadeiros usurios do sistema percebem a qualidade das ligaes e as mudanas na forma de utiliz- lo. Infelizmente, a avaliao no foi realizada. Ainda assim, segue sua descrio para que haja a possibilidade de ser realizada em outra ocasio. Esta avaliao deveria ser efetuada aps a rede de dados ter sido preparada, ou seja, no momento da realizao dos testes as regras de QoS devem estar configuradas. A avaliao composta por um teste espontneo, onde o usurio realiza ligaes de acordo com sua demanda, sem alterar sua rotina e; por um teste controlado, onde so escolhidos pela empresa 5 (cinco) funcionrios que tm a tarefa de, durante o mnimo de duas semanas, realizarem chamadas para qualquer ramal das outras Unidades em horrios aleatrios, mas distribudas no incio, no meio e no fim do dia. Essas chamadas so contabilizadas e graduadas com notas de 0 (no foi possvel completar) at 5 (qualidade muito boa). Aps a realizao destes procedimentos, ser enviado por email um questionrio simples para as pessoas que utilizaram o novo sistema de modo a avaliarem o mesmo.

131

Estudo sobre a homogeneidade da rede Arquitetura homognea

Definio Aplicando o conceito de homogeneidade apenas no ambiente IP da rede de voz, arquitetura homognea aquela onde o gateway e as centrais remotas utilizam o mesmo protocolo e so do mesmo fabricante. Para a FIRJAN, a nica possibilidade para se ter um ambiente IP homogneo seria utilizar um gateway Siemens, j que a maior parte dos PABX remotos era deste fornecedor, sendo economicamente invivel a substituio destes por qualquer outro. O protocolo a ser utilizado neste ambiente seria o HFA, proprietrio e desenhado para suportar transparncia de facilidades. Do lado TDM, o Gateway continuaria ligado ao MD-110 utilizando ISDN. A homogeneidade total s seria conseguida se os PABX Ericsson fossem substitudos por PABX Siemens, que eliminaria a necessidade do Gateway entre o MD110 da sede e os PABX remotos, proposta que na prtica se mostrou invivel. Vantagens Mais do que poder contar com as solues corporativas disponveis na soluo do fabricante, as maiores vantagens de se ter um ambiente homogneo (transparncia de facilidades, mesma equipe, mesma gerncia, manuteno, impacto reduzido nos custos, etc.) a estabilidade do sistema e a uniformidade e centralizao do gere nciamento da rede. Desvantagens e Limitaes Em um ambiente homogneo, as limitaes se resumem s solues que o fabricante programou. Porm, essas limitaes no so crticas, pois todos os recursos desejveis como contingenciamento de falhas, gerenciamento centralizado da rede, entre outros, esto implementados no sistema da Siemens. Outra desvantagem o alto custo dos equipamentos, servios e licenas.

132

Expanso Caso seja adotada a soluo Siemens, h plena possibilidade de expanso, tanto para manter-se o ambiente homogneo, como para migrar para um ambiente heterogneo, com a utilizao de tecnologias abertas (SIP) e outros fabricantes. A expanso para ambiente heterogneo se traduz em uma grande vantagem deste sistema, alm de uma possvel reduo nos custos. Neste caso, pelo menos o gateway precisa ter instalado a verso de software com protocolos abertos, SIP ou H.323. Gerncia A gerncia da rede de voz pode ser realizada de forma centralizada, mas disponibilizada a todas as localidades via WEB, pela rede interna de dados. Os PABX monitoram o estado dos enlaces garantindo que, no caso de falhas da rede de dados, o sistema de voz no para, encaminhando as chamadas por rotas alternativas. Para tal, existe uma ferramenta proprietria, mas tambm pode ser utilizado qualquer agente SNMP para monitoramento.

Arquitetura heterognea
Definio Arquitetura heterognea, tambm levando em considerao apenas o ambiente IP, aquela onde os equipamentos so de diferentes fabricantes. Podem ser utilizados diferentes protocolos de voz sobre IP. No lado TDM, o Gateway tambm estar ligado ao MD110 pela interface ISDN. Vantagens Entre as vantagens do ambiente heterogneo est a liberdade para escolha de fabricantes e tecnologias. Utilizando tecnologias abertas, o usurio no se prende a um ou outro fabricante, podendo recorrer a solues mais econmicas, inclusive livres de licenas de utilizao. Outra grande vantagem a facilidade para criao de novos servios como URAs multi- nveis, integrao a banco de dados quaisquer, reconhecimento de voz e leitura de textos (text-to-speech).

133

Desvantagens e Limitaes As limitaes de uma rede heterognea podem variar bastante em funo das tecnologias e fabricantes envolvidos. Podem inclusive permitir simplesmente as chamadas bsicas. Os testes do Projeto Piloto apontaram as limitaes especificamente para este caso: sem transparncia de facilidades e requer upgrade de software das centrais Siemens das unidades remotas. Expanso A expanso de uma rede de voz heterognea tambm facilitada, justamente pela liberdade de escolha que o usurio possui. A capacidade de agregar novas tecnologias tambm um fator positivo, que contribui para aumentar a flexibilidade dessa arquitetura. Entretanto, h de se ter cuidado redobrado quando da aquisio de novos equipamentos para se certificar que o novo dispositivo compatvel com a rede. Recomenda-se a modalidade de compra conhecida como trial-buy, onde o fornecedor cede o equipamento por um determinado perodo e a compra s efetivada caso o comprador ateste seu correto funcionamento. No caso contrrio, o produto devolvido. Gerncia O gerenciamento de uma rede heterognea um ponto crtico do sistema. Devido s diferentes tecnologias e fabricantes, as interfaces de configurao e gernc ias dos sistemas tambm so diferentes. Isto requer um maior esforo das equipes de gerncia, que precisam dominar os produtos e solues dos diversos fabricantes existentes em sua rede. Isto implica em um procedimento de recuperao de falhas para cada fabricante. Entretanto, todos os equipamentos utilizados neste projeto possuem suporte a SNMP, que facilita, centraliza e, em algum grau, uniformiza o monitoramento e gerncia da rede. A Tabela 8 a seguir apresenta uma sntese da comparao entre ambientes homogneos e heterogneos.

134

Homogneo Vantagens

Heterogneo para escolha de

Transparncia de facilidades e Liberdade uniformidade na

operao, protocolos e fabricantes. Facilidade para criao de novos servios.

gerncia e manuteno.

Desvantagens

Alto custo de equipamentos e Pode licenas.

restringir

servios

suplementares. escalvel, inclusive Facilidade para agregar expanso, novas

Expanso

Soluo

podendo migrar para ambiente podendo heterogneo. Gerncia tecnologias.

Centralizada, mas disponibilizada possvel centralizar, mas dever para gestores via web. haver um procedimento para cada fabricante/soluo.

Tabela 9: Tabela comparativa de ambientes quanto a heterogeneidade.

Fonte: Relatrio interno

Redundncia e Tolerncia a Falhas (Contingncia)

A proposta de encaminhar o trfego de voz sobre a rede de dados deixa subentendido que uma falha na rede IP pode provocar interrupo na comunicao telefnica. Felizmente, alm dessas falhas serem relativamente raras, existem fo rmas de contornar vrias delas. Naturalmente, a contingncia seria executada desviando o trfego que cursaria pela rede de dados de volta pela rede de telefonia pblica. O impacto econmico deste desvio remete a situao atual, onde a empresa deixa de economizar nas ligaes internas. O desafio, portanto, tornar este desvio automtico. Os testes mostraram que os gateways Siemens e Asterisk desviam as chamadas automaticamente em caso de falha.

135

O monitoramento da rede de dados, imprescindvel para que aes de contingncia sejam tomadas rapidamente, pode ser feito utilizando as ferramentas de SNMP j existentes na empresa. Aes de contingncia, quando necessrias, podem ser diferentes para cada equipamento, mas todas podem ser disparadas pela ferramenta de gerncia existente hoje (utilizando Traps SNMP) e iro modificar a rota de encaminhamento das chamadas para a rede de telefonia pblica tradicional. Ateno especial para os PABX analgicos, pois no possvel modificar automaticamente as regras de encaminhamento de chamadas dos mesmos. Para localidades onde existe PABX analgico ligado a roteadores Cisco, foi proposta uma soluo utilizando um dispositivo inteligente baseado em software livre e utilizando um hardware de baixo custo, contendo mensagens de orientao para o usurio do sistema. Os testes de contingncia mostraram que, alm do desvio automtico de chamadas (sem necessidade de interveno da gerncia da rede) quando h descontinuidade na rede de dados, os PABX Siemens tambm apresentam maior tolerncia a perda de pacotes nos fluxos de voz.

Evoluo da Rede
A Rede de Dados Na poca da realizao da pesquisa, a tecnologia de rede adotada pela empresa era Frame-Relay com topologia em estrela, ou seja, as ligaes de seus enlaces remotos esto concentradas em apenas um ponto, a sede. A tendncia tecnolgica indica que este tipo de soluo est sendo substitudo por protocolos com maior capacidade de transferncia de dados e arquitetura baseada em malhas, tambm conhecida como redes mesh, onde um ponto da rede se comunica com mais de um ponto. Quando cada localidade se comunica com todas as outras, chama-se esta arquitetura de full-mesh. A rede em full- mesh tem maior tolerncia a falhas por possuir diversos caminhos. Alm disso, as novas tecnologias que possibilitam a arquitetura em malha, tambm possuem eficientes mecanismos de QoS. Portanto, tecnicamente no existem impactos negativos para a rede de dados quando da migrao da atual tecnologia para uma em malha.

136

Entretanto, a substituio de uma rede em operao nem sempre economicamente vantajosa. preciso levar em considerao os custos envolvidos na migrao, pois benefcios tcnicos podem no justificar o possvel aumento nos custos. A Rede de Voz A rede de voz, hoje independente em cada localidade, passar a funcionar sobre a rede de dados Frame-Relay. Isto significa que o fluxo de voz de ligaes entre duas localidades remotas ter obrigatoriamente que passar pelo n central, na Sede. Ento, do ponto de vista da economia de banda no enlace de dados da Sede, no importa se o gateway est configurado como um Proxy Stateless ou Statefull, j que todos os fluxos precisam passar pelo n central. Os gateways Siemens, MX-One e Asterisk podem ser configurados para manter o controle das chamadas, mas no precisam estar no caminho da mdia. Isto significa que apenas o controle das chamadas de Voz sobre IP passa por eles, sendo a mdia (voz) encaminhada diretamente para o participante de destino. Essa caracterstica tambm reduz o nvel de processamento do gateway. Entretanto, a utilizao do gateway Asterisk com os PABX Siemens s foi possvel quando o Asterisk era configurado para se manter no caminho da mdia, fazendo com que a voz passasse pelo gateway. Tecnicamente, a rede de voz sempre ir se benefic iar das caractersticas da arquitetura em malha, seja por economia de banda no n central ou pela redundncia nas rotas.

O plano de Migrao
Foi proposto um plano de migrao baseado em arquitetura homognea onde a empresa investiria inicialmente um valor relativamente baixo. O estudo do trfego telefnico indica que o retorno deste investimento se daria em poucos meses. Deste ponto em diante, com a economia gerada mensalmente possvel reinvestir na modernizao da rede. A partir do incio da implantao, dentro de aproximadamente 38 meses todas as 50 Unidades Remotas estariam equipadas com PABX Siemens e ainda se teria uma economia acumulada da ordem de R$ 200.000, com valores da poca do

137

estudo. As vantagens desta proposta so: 1) a modernizao caminha na direo de um ambiente homogneo e; 2) parte da economia acumulada durante os meses no utilizada, efetivamente gerando gastos menores no decorrer do processo de modernizao. A desvantagem o longo tempo necessrio para migrar toda a rede. A Figura 33 ilustra o fluxo financeiro para modernizao da rede de acordo com o Plano de Migrao sugerido.
Flux o Financeiro
R$ 200,00 R$ 175,00 R$ 150,00

R$ (x1000)

R$ 125,00 R$ 100,00 R$ 75,00 R$ 50,00 R$ 25,00 R$ 0,00 -R$ 25,00 -R$ 50,00 0 1 23 4 56 7 89 11 1 11 1 11 1 12 22 2 22 2 22 23 3 33 3 33 3 33 44 4 01 2 34 5 67 8 90 12 3 45 6 78 90 1 23 4 56 7 89 01 2
De se m b olso d e cad a ao Econ om ia Me n sal d as ae s som ad as Dif e r e n a

Meses

Figura 33: Fluxo financeiro do plano de migrao: arquitetura homognea.

Fonte: Relatrio interno

possvel acelerar o processo de migrao em 4 meses a partir do oitavo ms. Sendo a economia mensal maior que os gastos, possvel redistribuir a escala de atualizao e substituio de PABX etapa de renovao do parque de forma que a economia efetiva no final de 34 meses seja completamente revertida na renovao dos equipamentos. Uma alternativa a este plano a adoo de um ambiente heterogneo, utilizando Servidores de voz baseado em cdigo aberto, juntamente com PABX Siemens. Neste caso, seria utilizado um gateway Asterisk na Sede e nas unidades que possuem PABX legados (cerca de 18 unidades), sendo os PABX atuais utilizados como banco de canais, simplesmente para aproveitar a estrutura de ramais. A adoo do gateway Asterisk

138

nessas unidades geraria uma economia em relao ao gateway Siemens de aproximadamente R$ 35.000,00 em cada Unidade, totalizando a quantia de R$ 630.000,00. A plataforma onde o Asterisk deve ser instalado depende dos requisitos de processamento de cada local. Na Sede e em mais trs Unidades onde haver maior traduo TDM-IP, o sistema contar com servidores convencionais. Nas outras 18 Unidades, onde os requisitos de processamento so menores, o sistema poderia ser instalado em placas prprias para sistemas embutidos fabricadas pela Soekris, que aumentam consideravelmente a economia com hardware. As grandes vantagens dessa opo em relao ao Plano anterior so a economia total de tempo reduzido para menos de um ano e de recursos financeiros necessrios para renovao dos equipamentos. Pode-se considerar uma pequena desvantagem, dependendo da forma com que a empresa lida com esta situao, a questo do suporte e manuteno da rede heterognea, que dever ser executado internamente por uma equipe especializada. Empresas terceirizadas que prestam suporte em sistemas de voz de cdigo aberto costumam atender apenas a solues instaladas por elas mesmas. Assim, qualquer empresa que queira adotar solues abertas deve tratar com ateno a questo de treinamento e capacitao de funcionrios. A Figura 34 a seguir mostra o Fluxo Financeiro da alternativa de cdigo aberto.
Fluxo Financeiro
R$ 50,00 R$ 40,00 R$ 30,00 R$ 20,00 R$ 10,00 R$ 0,00 -R$ 10,00 -R$ 20,00 -R$ 30,00 -R$ 40,00 -R$ 50,00 -R$ 60,00 -R$ 70,00 -R$ 80,00 -R$ 90,00 0 1 2 3 4 5 6 7 8 9 10 11 12

R$ (x1000)

Desemb olso d e cad a ao Econ om ia Men sal d as aes so m ad as Diferen a

Meses

Figura 34: Fluxo Financeiro do Plano de Migrao: Arquitetura Heterognea.

Fonte: Relatrio interno

139

Problemas encontrados e lies aprendidas

importante identificar os problemas encontrados para que pesquisas semelhantes tenham a chance de evitar as adversidades encontradas neste trabalho. A escolha do hardware correto para abrigar o servidor de voz Asterisk importante. necessrio, alm de dimension- lo corretamente, verificar a lista de incompatibilidades conhecidas no site da Digium, caso alguma placa TDM deste fabricante seja adquirida. sabido que alguns chipsets de placas- me no funcionam corretamente com as placas Digium. Entretanto, a pgina no site da Digium que continha as informaes sobre incompatibilidade no pode mais ser encontrada. Uma opo utilizar placas TDM de outros fabricantes. Especificamente para o caso do Brasil, existem empresas que produzem placas analgicas e digitais com DSPs com suporte ao CODEC GSM e j so preparadas para o protocolo R2-Digital, sem necessidade de aplicar patches nos sistema. Isto reduz significativamente o processamento no servidor. No h documentao sobre casos de incompatibilidade dessas placas com qualquer outro hardware. Outra preocupao que se deve ter em mente a alocao de recursos humanos para a realizao dos testes. O ambiente de testes excedia os limites fsicos do laboratrio, envolvendo funcionrios de algumas unidades remotas que estavam produzindo em seus horrios de trabalho. Isso dificultava a comunicao entre a equipe e os funcionrios, o que prejudicava o andamento dos testes, mesmo que em grau reduzido. Alm disso, como os testes utilizavam fornecedores que no liberam manuais para manuteno ou configurao de seus equipamentos, era necessrio haver um tcnico a disposio sempre que se desejava efetuar alguma modificao. Infelizmente, nem sempre era possvel t- los acompanhando os testes em perodo integral. Foi necessrio planejar as etapas dos testes levando em considerao essa (falta de) disponibilidade.

O contra-ataque da operadora de telefonia

Quando o projeto se encaminhava para fase de implantao, a operadora local

140

fornecedora dos enlaces de voz e dados percebeu que perderia gra nde parte de sua receita com a adoo da Telefonia sobre IP por este cliente. Ento foram oferecidos planos e descontos que contemplavam descontos significativos na assinatura mensal de todos os troncos E1 e outros benefcios. Somando as vantagens, foi economicamente mais vantajoso aceitar a proposta da operadora. Assim, a rede foi preparada para suportar o trfego VoIP, mas o servio de Telefonia sobre IP no foi implantado nesta ocasio. Este fato prova que nem sempre a adoo da tecnologia VoIP a soluo de menor custo.

Concluso
perfeitamente possvel utilizar software livre para ligar reas geograficamente separadas, integrando a rede de voz com a rede de dados, a um baixo custo obtendo um rpido retorno do investimento. Entretanto, preciso cautela. Em um ambiente heterogneo como o encontrado nesta pesquisa, poucas facilidades de redes se mostram compatveis com todos os fornecedores. Em alguns casos, mesmo para realizao das chamadas bsicas, necessrio investir em upgrade das plataformas proprietrias para que elas suportem os protocolos abertos. Se capital para investimento no for problema e a empresa necessitar de facilidades alm das chamadas bsicas, a implantao de uma rede homognea traz mais vantagens por conta da quantidade de servios oferecidos pela rede a seus usurios. Seja qual for a orientao seguida pela empresa, preciso levar em considerao as tendncias tecnolgicas para que, no futuro, uma possvel mudana de tecnologia de rede no afete a qualidade das ligaes que estaro cursando por ela. Finalmente, um bom plano de migrao imprescindvel para garantir um investimento seguro e um rpido retorno de capital.

141

Servios Digitais para Sade RNP Projeto Piloto Min. da Sade / RNP Servio fone@MS
Apresentao
A iniciativa Servios Digitais para Sade 12 uma decorrncia das aes de cooperao entre os ministrios da Cincia e Tecnologia (MCT), Educao (MEC) e Sade (MS). Seu objetivo disponibilizar servios de tecnologia de redes, inovao e educao com mais dinamismo, abrangncia e melhores resultados no atendimento pblico de sade. A iniciativa Servios Digitais para Sade compreende aes de implantao de servios pela RNP13 , Rede Nacional de Ensino e Pesquisa, para prover infra-estrutura de hardware e software, treinamento de profissionais e conexes de rede para desenvolvimento e manuteno de aplicaes de colaborao a distncia em sade. As atividades esto organizadas em trs frentes: Datasus, Qualisus e Telessade. Nas duas primeiras frentes, foi previsto a instalao de servio de videoconferncia e Voz sobre IP, integrando as unidades do Datasus, atravs de sua rede prpria, chamada de Infosus, e mais oito secretarias de sade, sendo cinco secretarias estaduais e trs secretarias municipais. Nesta dissertao so detalhadas as aes referentes instalao do fone@MS, o servio experimental de telefonia IP.

O servio fone@MS
Alm de fornecer a estrutura de interconexo entre as secretarias e a rede do Datasus e entre as unidades de novos embries de telessade, a RNP a responsvel pela gerncia deste projeto. O objetivo geral dessa frente do projeto piloto implantao de um servio piloto de telefonia IP para o Ministrio da Sade, utilizando protocolo SIP. O servio tem como objetivo interligar a sede do Datasus no Distrito Federal s suas 26 unidades nos estados da Unio, cinco secretarias estaduais de sade (AM, GO, MG, PE e SC) e
12

Site do Projeto Piloto RNP/MS: http://saude.rnp. br

142

mais trs secretarias municipais de sade (Belo Horizonte, Florianpolis e Recife). As premissas deste projeto previram um plano de numerao compatvel como servio fone@RNP 14 para que fosse possvel a comunicao direta entre eles. O plano de numerao tambm foi o mais integrado possvel a numerao dos ramais em cada localidade, de forma a possibilitar que os telefones IP recebessem chamadas DDR, sempre que a infra-estrutura local permitia. A respeito das chamadas, o servio possibilita chamadas entre telefones IP e telefones convencionais da unidade, bem como a realizao de chamadas para a rede de telefonia pblica. Para isso, o PABX IP interligado ao PABX local, quando ele existe. Quando no h PABX na localidade, o PABX IP ligado diretamente STFC. Assim, chamadas entre qualquer localidade participante do projeto piloto, a partir de qualquer telefone IP ou convencional, pode ser realizada utilizando-se a rede IP, eliminando-se os custos das chamadas convencionais para o Ministrio da Sade.

O ambiente
O servio fone@MS a implementao de um servio piloto que interliga todas as 27 unidades do Datasus, uma em cada estado do Brasil, mais 8 secretarias de sade que no so atendidas pela rede Infosus, a rede de dados do Datasus. A comunicao dessas secretarias com a rede do Datasus realizada utilizando-se a rede Ip, o backbone nacional de dados da RNP. A Figura 35 ilustra a rede Infosus, onde possvel verificar o n central, em Braslia, onde se encontra a sada para Internet; o n do Rio de Janeiro onde est outra sada de redundncia para Internet; e os outros ns, um em cada estado. Pode-se notar tambm a existncia de duas tecnologias diferentes de rede, Frame Relay e ATM. A rede possui duas sadas para Internet de 20Mbps, um enlace de 34Mbps, um de 10Mbps, um de 8Mbps, sete de 4Mbps, trs de 2Mbps e treze de 1Mbps. Os nmeros se referem banda garantida em cada enlace. Na verdade, a capacidade mxima da rede maior.
13 14

Site da RNP: http://www.rnp.br Site do servio fone@ RNP: http://www.rnp.br/voip

143

Figura 35 Rede Infosus, do Datasus.

Fonte: Relatrio interno

A administrao central para a rede de dados exercida pelo prprio Datasus, porm cada local responsvel por manter e administrar sua prpria infraestrutura de telefonia. A rede local de cada unidade bem definida e sempre apresenta um firewall entre a WAN e a LAN. A Figura 36 ilustra o ambiente local das unidades.

144

Figura 36 Firewall entre sede e LAN nas unidades

Fonte: Relatrio interno

A rede local das secretarias no se interconecta rede Infosus. A RNP foi responsvel pela ligao de suas redes locais at a rede do Datasus, utilizando a rede Ip. Trs secretarias foram atendidas por redes metropolitanas, j ligadas ao PoP de seu estado. So elas: SES/AM, SES/SC e SMS/Florianpolis. Para as demais secretarias foi contratado um enlace de 2Mbps interligando-as aos PoP de seus estados. Observando o ambiente de telefonia de todas as localidades, foi encontrado uma situao extremamente heterognea no que diz respeito a marcas, modelos e funcionalidades dos PABX tradicionais. Algumas possuem PABX com interfaces digitais, outros apenas com interfaces analgicas. Outras unidades possuem PABX virtuais, um servio oferecido pela operadora de telefonia local que simula um PABX, mas fisicamente s existem as linhas telefnicas. Outras unidades no possuem nada alm de algumas linhas telefnicas.

Sobre QoS
Foi realizado um estudo de trfego para implantao do servio de Voz sobre IP. Foi utilizada a ferramenta de monitorao de trfego existente na rede do Datasus, o CACTI (55), que apresentava um histrico de utilizao da cada enlace entre a sede e as

145

unidades. A anlise dos grficos mostrou que seus enlaces possuem banda suficiente para prestar o servio de voz, estando sua utilizao abaixo dos 60% da banda disponvel na grande maioria dos casos. Tambm foi medida a latncia entre a sede e as unidades utilizando a ferramenta ping. Apenas duas unidades apresentaram alta latncia (em torno de 600ms de RTT) mesmo com baixa utilizao da rede. Isto caracterizava a utilizao de links de satlites para estas duas localidades, Datasus/RR, em Boa Vista e Datasus/AP, em Macap. Mesmo no possuindo este requisito dentro de valores aceitveis para telefonia IP, estes locais foram contemplados no projeto. Apesar da abundncia de recursos da rede, o Datasus foi instrudo a configurar regras de QoS com o propsito de evitar possveis problemas de qualidade. A recomendao da equipe de implantao foi a adoo do modelo DiffServ, priorizando pacotes de voz sobre os pacotes de dados.

Proposta de soluo
A arquitetura proposta para o servio fone@MS foi desenhada contemplando uma rede em estrela, com servidores proxy em cada unidade e mais dois proxies centrais em Braslia e Rio de Janeiro. A equipe de implementao os chamou de DSIP. A ligao com os proxies do servio fone@RNP e com as secretarias feita pelos mesmos ns centrais de Braslia e Rio. A ligao com a Rede de Telefonia Pblica feita em cada unidade pelos PABX locais. Cada unidade decide se entrega ou no ligaes para STFC. J que a infra-estrutura de rede j era modelada como uma estrela, a arquitetura mais adequada neste caso era sobrepor uma estrela na camada de aplicao exatamente sobre a camada inferior, de rede e transporte. Cada localidade responsvel pela administrao dos ramais locais e de seus proxies. A administrao central continua cuidando apenas da infra-estrutura de redes. O ambiente de telefonia continua sob a administrao local, sem interferncia da sede. A Figura 37 a seguir ilustra a proposta do servio.

146

Figura 37 Soluo de arquitetura do servio fone@MS

Fonte: Relatrio interno

A soluo proposta para cada unidade sempre contemplou a interligao do PABX IP a rede de telefonia tradicional, no importando como o ambiente local se apresentava com relao ao PABX tradicional. Cada unidade recebeu dois servidores para soluo de alta disponibilidade. Entretanto, apenas uma placa de telefonia para cada local foi disponibilizada, mas no momento da escrita desta dissertao, esto sendo providenciadas placas E1 para todas as unidades que podem utilizar esta tecnologia, oito no total. As unidades receberam de 8 a 40 telefones IP, dependendo da densidade de

147

ramais existente em cada uma delas. A figura 38 mostra o ambiente VoIP ligado ao PABX da unidade atravs de enlace digital E1, que pode variar entre os protocolos ISDN ou R2.

Figura 38 Ligao com PABX digital. Fonte: Relatrio interno A figura 39 mostra o ambiente VoIP ligado ao PABX atravs de canais analgicos, atravs de ligaes entre um ramal no PABX tradicional e uma porta FXO no PABX IP.

Figura 39 Ligao com PABX analgico. Fonte: Relatrio interno A figura 40 mostra o ambiente VoIP ligado a unidade atravs de PABX Virtual,

148

um servio da operadora local que simula um PABX. Na prtica, no existe PABX na unidade; apenas linhas telefnicas . A operadora agrupa essas linhas permitindo ligaes a 4 dgitos entre elas, e a um custo muito reduzido.

Figura 40 Ligao com PABX virtual. Fonte: Relatrio interno Em alguns locais no havia nenhuma soluo de PABX, nem mesmo virtual. A figura 41 mostra o ambiente VoIP ligado diretamente a linhas telefnicas das unidades.

Figura 41 Ligao sem PABX. Fonte: Relatrio interno Para as secretarias, o ambiente muda consideravelmente, conforme ilustrado na

149

Figura 42.

Figura 42 Ligao para as secretarias. Fonte: Relatrio interno Como os endereos IP utilizados nas secretarias no so publicveis (RFC-1918) (56), foi necessrio criar outra DMZ 15 , fazendo com que os PABX IP participassem de duas redes: uma rede interna, onde esto ligados os telefones IP e softphones; e uma rede externa, com IPs da RNP, roteveis e acessveis a partir da Internet. A soluo lgica constituda de vrios softwares de cdigo aberto. Entre eles destacam-se Asterisk (53), OpenSIPs (57) (antigo OpenSER), Media Proxy (58), OpenLDAP (59), Mysql (60) e o servidor web Apache (61). O OpenSIPs faz toda a lgica de autenticao e encaminhamento das chamadas enquanto o Asterisk atua como gateway para telefonia tradicional e de outros servios de telefonia. O Media Proxy a soluo de encaminhamento de udio, utilizada para contornar o problema do NAT, no encontro das redes interna e externa. O OpenLDAP trata de armazenar as informaes dos usurios e suas permisses e o Mysql cuida da persistncia das informaes e armazena o detalhamento das chamadas, o CDR. O servidor apache foi utilizado para suportar a interface de configurao do sistema, totalmente desenvolvida pela equipe de
DMZ (Zona Desmilitarizada) um term o ligado a segurana da informao. uma pequena rede separada da rede e de servios internos onde se localizam servidores que devem ser acessados por computadores na Internet.
15

150

implementao. Todo o ambiente estava instalado em dois servidores locais que atuam em conjunto para prover alta disponibilidade ao sistema. O plano de encaminhamento de chamadas foi implementado utilizando a tecnologia ENUM (57) e a recomendao E.164 (63) para numerao telefnica, que utiliza o servio de DNS para traduzir nmeros de telefones em endereos de Internet, do tipo URIs. A Figura 43 mostra um esquema lgico da soluo de redundncia adotada.

Figura 43 Detalhamento do ambiente local redundante

Fonte: Relatrio interno

A Figura 44 o exemplo da interface de gerncia e configurao desenvolvida pela equipe de implementao. Alm da viso geral dos servidores e de como estavam sincronizados, ela tambm permite a configurao de ramais e a visualizao do detalhamento das chamadas realizadas e recebidas neste local.

151

Figura 44 Exemplo da interface de gerncia do sistema. Viso geral.

Fonte: Relatrio interno

Alguns nmeros
A seguir apresentam-se alguns nmeros do projeto. 70 servidores de voz; 2 servidores centrais (DSIP); 1 servidor para o CDR; 415 telefones IP; 32 placas AEX800, de 8 interfaces analgicas; 7 placas TE121, de 1x E1; 2 placas TE212, de 2x E1; 64 mdulos X400, de 4 FXOs; 32 mdulos de cancelamento de eco para AEX800 e TE121; 2 mdulos de eco para TE212; 244 licenas G.729; 92 tcnicos treinados.

152

Treinamento
Dada a complexidade da soluo adotada, a equipe do Ministrio da Sade recebeu treinamento bsico que contemplava noes bsicas de VoIP; introduo a SIP; noes sobre cada componente da soluo como Asterisk, OpenSIPs, LDAP e Mysql e como tudo se integrava para compor o sistema de telefonia; e sobre a ferramenta de gerncia desenvolvida. Este treinamento foi ministrado para 2 tcnicos de cada unidade do Datasus e das secretarias envolvidas. Tambm foi oferecido um treinamento avanado que aprofundava o

conhecimento do desenvolvimento da soluo. O pblico deste curso foram os tcnicos mais experientes da sede e da unidade do Rio de Janeiro.

ltimas consideraes Homologao do ambiente

Para homologao do ambiente aps a instalao do sistema, foi desenvolvida uma srie de testes simples que visam atestar o funcionamento da soluo. No momento da escrita da dissertao, algumas localidades j estavam homologadas. Outras ainda se encontravam adequando sua infra-estrutura, mas todos j se encontravam com telefones e servidores instalados, j sendo possvel ligar entre os telefones IP.

Placas com problemas

J na fase final de implantao do sistema, quando todo o material j havia sido distribudo, foram encontrados problemas com algumas placas. Era uma situao que havia sido descoberta h pouco tempo e na poca do dimensionamento da soluo ainda no havia sido documentada pelo fabricante. A nota no site do fabricante (58) dava conta de que placas dos modelos adquiridos pela RNP para o projeto poderiam apresentar problemas aleatoriamente. E apresentaram. Todas as placas que possuem uma porta E1 foram substitudas neste momento. Elas foram recolhidas e enviadas ao fornecedor que as trocou por modelos mais atuais sem maiores transtornos.

153

Algumas placas de 8 portas FXO tambm apresentaram problemas e foram encaminhadas para o laboratrio da UFSC para anlise e possvel troca.

Equipes divididas
No Datasus as equipes de Telefonia, normalmente associada a equipe de infraestrutura, de TI e de Redes so distintas. A natureza experimental deste projeto no contemplou um plano de unificao das equipes. Tambm no considerou a criao de uma equipe especfica para VoIP. Os participantes dos treinamentos oferecidos foram, essencialmente, tcnicos das equipes locais de redes, o que fortalece a idia de que o servio de telefonia IP caminha para ser mais uma responsabilidade da rea de redes das empresas.

154

Captulo 8 Concluso
A tecnologia de Voz sobre IP complexa e pressupe o acmulo de conhecimento nas reas de telefonia, transmisso, tratamento de contedo multimdia, redes IP (LAN e WAN), qualidade de servio e segurana em redes. Muito contedo terico necessrio para o total entendimento da tecnologia. Experincias prticas tambm so imprescindveis para fixar o conhecimento tcnico adquirido, para aprimorar a capacidade de comparar e poder discernir entre bons e maus resultados, diagnosticar problemas e, principalmente, adquirir mais conhecimento. Apesar de parecer ter um cunho gerencial acentuado, no pretenso desse trabalho fazer recomendaes sobre gerncia de projetos ou servios. Entretanto, as recomendaes feitas aqui esto repletas de conhecimento compilados de toda teoria e prtica sobre redes e telefonia IP acumulados durante 7 anos. Esta dissertao tratou da implantao do servio de telefonia IP em empresas de mdio e grande porte. Os captulos 1 e 2 apresentaram o assunto conte xtualizando histrica e tecnicamente o problema de transmitir voz em redes de pacotes. O captulo 3 tratou do embasamento terico da tecnologia de Voz sobre IP. O captulo 4 tratou da qualidade do servio de telefonia e como garantir que a qualidade perceb ida pelo usurio seja satisfatria. O captulo 5 tratou da gerncia da rede e do servio, contribuindo para alicerar conhecimentos que ajudam a garantir a continuidade do servio. O captulo 6 traz o roteiro de implantao e as consideraes pertinentes a cada ponto, principal objetivo deste trabalho. O captulo 7 documenta experincias prticas de alta relevncia no assunto tratado por esta dissertao. E o captulo 8 a concluso. Esta dissertao atendeu aos objetivos inicialmente propostos. O objetivo especfico desta dissertao foi atingido. O roteiro para implementao do servio de telefonia IP foi materializado no captulo 6 e foi construdo com base nos argumentos tericos e prticos descritos nos captulos anteriores. O objetivo geral, de sensibilizar os profissionais quanto forma da prestao do servio mantendo um compromisso com a qualidade e satisfao do usurio, no depende apenas do texto. Espera-se que seja alcanado quando algum profissional ler, concordar e aplicar as recomendaes que aparecem em vrias partes do texto. preciso sempre reforar

155

a idia de que seguir as recomendaes tcnicas e procedimentos consagrados (como ITIL e COBIT, entre outros) podem ajudar a alcanar o sucesso, pois essas recomendaes foram estudadas e depuradas por grupos de profissionais experientes e especializados.

Prximos trabalhos
Esta dissertao de forma alguma esgota o assunto e, ao contrrio, cria oportunidades de diversos trabalhos relacionados com a implantao e continuidade do servio de telefonia IP. A seguir, apresenta-se uma lista no exaustiva de sugestes de trabalhos futuros. Depurao e aperfeioamento do roteiro apresentado nesta dissertao de forma a transform- la em uma efetiva metodologia para implantao e gerncia de servio de telefonia IP. Suporte a VoIP nas ferramentas de gerncia de redes, criando meios de medir e apresentar os parmetros relevantes ao servio, criando inventrios especficos para VoIP, entre outros, gerenciando inclusive equipamentos de VoIP antigos e sem suporte a gerncia. Desenvolvimento de dispositivo de medio passiva que, capturando o trfego de um n da rede, separa o trfego VoIP e qualifica a rede quanto a qualidade das ligaes em curso por aquele n.

156

Referncias
1. opensource.org. Open Source Initiative. Open Source Initiative. [Online] Maro 13, 2007. http://www.opensource.org. 2. Free Software Foundation, Inc. GNU GENERAL PUBLIC LICENSE. GNU Operating System. [Online] 3, Junho 29, 2007. http://www.gnu.org/licenses/gpl.html. 3. Coar, Ken. The Open Source Definition. Open Source Initiative. [Online] Julho 07, 2006. http://www.opensource.org/docs/osd. 4. Bell, Alexander Graham. Alexander Graham Bell - First Telephone Patent. 174465 Estados Unidos, 1876. 5. IT WEB. Vida longa aos telefones analgicos. [Online] 07 01, 2008. http://www.itweb.com.br/noticias/index.asp?cod=49258. 6. ITU-T. E.830 - Models for the specification, evaluation and allocation of serveability and service integrity. International Telecommunication Union. [Online] 10 1992. http://www.itu.int/rec/T-REC-E.830/en. 7. Information Sciences Institute - University of Southern California. RFC-791 -. ietf.org. [Online] 09 1981. http://www.ietf.org/rfc/rfc791.txt. 8. Almquist, P. RFC-1349 - Type of Service in the Internet Protocol Suite. ietf.org. [Online] 07 1992. http://www.ietf.org/rfc/rfc1349.txt. 9. Cohen, Danny. RFC-741 - Specifications for the Network Voice Protocol - NVP. ietf.org. [Online] 11 22, 1977. http://tools.ietf.org/html/rfc741. 10. CIP Working Group. RFC-1190 - Experimental Internet Stream Protocol, Version 2 (ST-II). ietf.org. [Online] 10 1990. http://www.ietf.org/rfc/rfc1190.txt. 11. ST2 Working Group. RFC-1819 - Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+. ietf.org. [Online] 08 1995. http://www.ietf.org/rfc/rfc1819.txt. 12. ITU-T. H.323 - Packet-based multimedia communications systems. International Telecommunication Union. [Online] 06 2006. http://www.itu.int/rec/T-REC-H.323/e. 13. . H.225 - Call signalling protocols and media stream packetization for packet-based multimedia communication systems. international Telecommunication Union. [Online] 05 2006. http://www.itu.int/rec/T-REC-H.225.0/en.

157

14. . Q.931 - ISDN user-network interface layer 3 specification for basic call control. International Telecommunication Union. [Online] 05 1998. http://www.itu.int/rec/T-RECQ.931/en. 15. . H.245 - Control protocol for multimedia communication. Inernational Telecommunications Union. [Online] 06 2008. http://www.itu.int/rec/T-REC-H.245/en. 16. . H.235.1 - H.323 security framework: Baseline security profile. International Telecommunications Union. [Online] 09 1995. http://www.itu.int/rec/T-REC-H.235.1/en. 17. . H.450.1 - Generic functional protocol for the support of supplementary services in H.323. International Telecommunication Union. [Online] 02 1998. http://www.itu.int/rec/TREC-H.450.1/en. 18. . T.120 - Data protocols for multimedia conferencing. International Telecommunication Union. [Online] 01 2007. http://www.itu.int/rec/T-REC-T.120/en. 19. Group, Audio-Video Transport Working; Schulzrinne, H.; Casner, S.; Frederick, R.; Jacobson, V. RFC-1889 - RTP: A Transport Protocol for Real-Time Applications. ietf.org. [Online] 01 1996. http://tools.ietf.org/html/rfc1889. 20. Rosenberg, J., et al. RFC-3261 - SIP: Session Initiation Protocol. ietf.org. [Online] 07 2002. http://tools.ietf.org/html/rfc3261. 21. Handley, M. and Jacobson, V. RFC-2327 - SDP: Session Description Protocol. ietf.org. [Online] 04 1998. http://tools.ietf.org/html/rfc2327. 22. Vergara, Victor and Davis, Christopher. How audio codecs work - Psycoacoustics. Audio DesignLine. [Online] 02 01, 2006. http://www.audiodesignline.com/howto/audioprocessing/175800470. 23. ITU-T. G.711 - Pulse code modulation (PCM) of voice frequencies. International Telecommunications Union. [Online] 11 1988. http://www.itu.int/rec/T-REC-G.711/en. 24. . G.729 - Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP). International Telecommunication Union. [Online] 01 2007. http://www.itu.int/rec/T-REC-G.729/en. 25. . G.723.1 - Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s. International Telecummunication Union. [Online] 05 2006. http://www.itu.int/rec/T-REC-G.723.1/en. 26. Valin, Jean-Marc. Speex: A Free Codec For Free Speech. people.xiph.org. [Online] 2002. http://people.xiph.org/~jm/papers/speex_lca2006.pdf. 27. DTE Power via MDI Study Group. IEEE P802.3af - DTE Power via MDI Task Force. IEEE802.org. [Online] 06 2003. http://www.ieee802.org/3/af/index.html.

158

28. Spencer, M., et al. RFC-5456 - IAX: Inter-Asterisk eXchange Version 2. rfc-editor. [Online] 02 2009. http://www.rfc-editor.org/authors/rfc5456.txt. 29. Degermark, M., Nordgren, B. and Pink, S. RFC-2507 - IP Header Compression. ietf.org. [Online] 02 1999. http://www.ietf.org/rfc/rfc2507.txt. 30. Braden, R., Clark, D. and Shenker, S. RFC-1633 - Integrated Services in the Internet Architecture: an Overview. ietf.org. [Online] 06 1994. http://www.ietf.org/rfc/rfc1633.txt. 31. Casner, S. and Jacobson, V. RFC-2508 - Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. ietf.org. [Online] 02 1999. http://www.ietf.org/rfc/rfc2508.txt. 32. cisco. Link Efficiency Mechanisms Overview. cisco. [Online] 2009. http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcflem.html#wpxref19 484. 33. R. Braden, Ed., et al. RFC-2205 - Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. ietf.org. [Online] 09 1997. http://www.ietf.org/rfc/rfc2205.txt. 34. Blake, S., et al. RFC-2475 - An Architecture for Differentiated Services. ietf.org. [Online] 12 1998. http://www.ietf.org/rfc/rfc2475.txt. 35. Grossman, D. RFC-3260 - New Terminology and Clarifications for Diffserv. ietf.org. [Online] 04 2002. http://www.ietf.org/rfc/rfc3260.txt. 36. Jacobson, V., Nichols, K. and Poduri, K. RFC-2598 - An Expedited Forwarding PHB. ietf.org. [Online] 06 1999. http://www.ietf.org/rfc/rfc2598.txt. 37. Heinanen, J., et al. RFC-2597 - Assured Forwarding PHB Group. ietf.org. [Online] 06 1999. http://www.ietf.org/rfc/rfc2597.txt. 38. Nichols, K., et al. RFC-2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. ietf.org. [Online] 12 1998. http://www.ietf.org/rfc/rfc2474.txt. 39. ITU-T. P.800 - Methods for subjective determination of transmission quality. International Telecommunication Union. [Online] 08 1996. http://www.itu.int/rec/T-REC-P.800/en. 40. . G.107 - The E-model: a computational model for use in transmission planning. International Telecommunication Union. [Online] 08 2008. http://www.itu.int/rec/T-RECG.107/en. 41. . G.113 - Transmission impairments due to speech processing. International Telecommunication Union. [Online] 11 2007. http://www.itu.int/rec/T-REC-G.113/en. 42. Mills, David L. RFC-1305 - Network Time Protocol (Version 3). ietf.org. [Online] 03 1992. http://www.ietf.org/rfc/rfc1305.txt.

159

43. MonIP - Servio de Monitoramento da Rede Ip. MonIP. [Online] 2008. http://wiki.nuperc.unifacs.br/portalmonipe/. 44. RNP; GEANT; Internet2; ESNET. perfSONAR. perfSONAR. [Online] http://www.perfsonar.net/. 45. Harrington, D., Presuhn, R. and Wijnen, B. RFC-3411- An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. ietf.org. [Online] 12 2002. http://www.ietf.org/rfc/rfc3411.txt. 46. Case, J., et al. RFC-3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). ietf.org. [Online] 12 2002. http://www.ietf.org/rfc/rfc3418.txt. 47. Frye, R., et al. RFC-3584 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. ietf.org. [Online] 08 2003. http://www.ietf.org/rfc/rfc3584.txt. 48. ITU-T. M.3010 - Principles for a telecommunications management network. International Telecommunication Union. [Online] 02 2000. http://www.itu.int/rec/T-REC-M.3010/en. 49. . M.3400 - TMN management functions. InternationalTelecommunication Union. [Online] 02 2000. http://www.itu.int/rec/T-REC-M.3400/en. 50. Ericsson. MX-ONE Version 3 the take-off into unified communications. Ericsson. [Online] 05 08, 2007. http://www.ericsson.com/solutions/news/2007/q2/20070508_mxone.shtml. 51. . Solutions for medium and large enterprises. Ericsson. [Online] 02 2009. http://www.ericsson.com/developer/sub/enterprise/subpages/ip_and_mobility_solutions_for _medium_and_large_enterprises. 52. Siemens. HiPath 3000. Siemens. [Online] 2009. http://www.siemens.com.br/templates/produto.aspx?channel=1485&produto=11281. 53. Asterisk. Asterisk. The Open Source PBX & Telephony Platform. [Online] 2009. http://www.asterisk.org/. 54. Cisco. Cisco 1751 Modular Access Router. Cisco. [Online] 2009. http://www.cisco.com/en/US/products/hw/routers/ps221/ps226/index.html. 55. CACTI. CACTI - The complete RRDTool-based graphing solution. CACTI. [Online] 2009. http://www.cacti.net/. 56. Rekhter, Y., et al. RFC-1918 - Address Allocation for Private Internets. ietf.org. [Online] 02 1996. http://www.ietf.org/rfc/rfc1918.txt. 57. OpenSipS. The breed of communication engine. [Online] http://www.opensips.org/.

160

58. Dan Pascu, Ruud Klaver, Sal Ibarra. Media Proxy. SIP NAT Trasversal Solution. [Online] http://mediaproxy.ag-projects.com/. 59. OpenLDAP. comunity developed LDAP solution. [Online] http://www.openldap.org. 60. MySQL. Home Page. [Online] http://www.mysql.com. 61. Apache. The apache software foundation. [Online] http://www.apache.org. 62. IETF Enum Working Group. Telephone Number Mapping (enum). ietf.org Working Groups. [Online] 03 2009. http://www.ietf.org/html.charters/enum-charter.html. 63. ITU-T. E.164 . The international public teleccomunication numbering plan. [Online] 11 2010. http://www.itu.int/rec/T-REC-E.164-201011-P. 64. Burcham, Steve. Potential Performance Issue on PCI Express Telephony Cards. Digium Technical Bulletin. [Online] 11 13, 2008. http://www.digium.com/en/docs/tech_bulletins/20081113.php. 65. Lemen, Dick. Telephone Poles and Wires. St. Louis, Missouri, USA : s.n., 1900. 66. Andersen, S., et al. iLBC - Internet Low Bit Rate Codec. ietf.org. [Online] 12 2004. http://www.ietf.org/rfc/rfc3951.txt. 67. ITU-T. X.902 - Information technology - Open Distributed Processing - Reference Model: Foundations. Internationonal Telecommunication union. [Online] 11 1995. http://www.itu.int/rec/T-REC-X.902/en. 68. Wikipedia. Timeline of the telephone. Wikipedia. [Online] 03 05, 2009. http://en.wikipedia.org/wiki/Timeline_of_the_telephone. 69. VoIPForo.com. SIP Vs. H.323 - Comparative. VoIPForo.com. [Online] http://www.en.voipforo.com/H323vsSIP.php. 70. ST2 Working Group. RFC-1819 - Internet Stream Protocol Version 2 (ST2). ietf.org. [Online] 08 1995. http://tools.ietf.org/html/rfc1819. 71. CIP Working Group. RFC-1190 - Experimental Internet Stream Protocol, Version 2 (ST-II). ietf.org. [Online] 10 1990. http://tools.ietf.org/html/rfc1190. 72. iLBC - internet Low Bitrate Codec. iLBC Freeware. [Online] 2007. http://www.ilbcfreeware.org/. 73. Free Software Foundation, Inc. Free Software Foundation. [Online] 2009. http://www.fsf.org/. 74. FLAC - Free Lossless Audio Codec. Free Lossless Audio Codec. [Online] 2008. http://flac.sourceforge.net/.

161