Construindo Redes de Voz sobre IP

Captulo 1: Construo de Redes de Voz sobre IP
11
Captulo
1
Construo de Redes de Voz sobre IP
Arthur Callado, Gabriel Fernandes, Auristela Silva, Rodrigo Barbosa, Djamel Sadok, Judith Kelner.
Abstract The VoIP technology is becoming more and more common in the world market. In Brazil, many companies already adopted VoIP, although with a more timid advancement and besides regulation problems. After nearly 2 decades of improvement, one can say that all technological problems of implementing VoIP are solved, but the market still refuses to adopt the technology completely, due to the need for QoS. This mini-course details all the many technologies needed to prepare (infrastructure), implement (coding and signaling) and evaluate (metrics and methodologies) a VoIP network, along with citations of many free open-source tools that help this implementation.
Resumo A tecnologia de VoIP est ganhando preponderncia no mercado mundial. No Brasil, embora com avano mais tmido do mercado e apesar dos problemas regulatrios, muitas empresas j a adotaram. Aps quase 2 dcadas de amadurecimento, pode-se dizer que todos os problemas tecnolgicos para a implantao de VoIP foram resolvidos, mas ainda tem-se o problema do mercado querer adotar a tecnologia completamente, devido necessidade de QoS. Este minicurso trata das diversas tecnologias para preparar (infra-estrutura), implantar (codificar e sinalizar) e avaliar (metricas e metodologias) uma rede de VoIP, alm de citar diversas ferramentas livres e de cdigo aberto que auxiliam nessa implantao.
12
Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos
1.1 Introduo
Desde o sculo XIX, transmite-se voz humana distncia com uma qualidade razoavelmente inteligvel. Ao longo de mais de cem anos, o servio de telefonia evoluiu e atingiu um bom padro de qualidade e um nvel de confiabilidade que faz com que haja uma expectativa de que, em 99,999% do tempo, a rede de telefonia pblica esteja funcional [1]. Com a apario e popularizao das redes de computadores e da Internet, surgiu uma grande variedade de inovaes que revolucionaram a maneira como pessoas e empresas encaram a comunicao. Uma dessas inovaes cresce nos ltimos anos e conhecida como VoIP. VoIP, que significa voz sobre o protocolo IP, denota voz transmitida por uma rede de computadores, especificamente uma rede IP. A idia essencial da tecnologia VoIP utilizar tanto redes privadas como a Internet - uma rede concebida para conduzir dados para transportar voz e dessa forma, efetuar a convergncia nos servios de transferncia de voz e dados em uma mesma rede. Mas por que se preocupar em conduzir voz sobre uma rede IP, ou sobre a Internet, se j existe a PSTN, uma infra-estrutura pronta e confivel para a comunicao de voz? Existem vrios argumentos [2], o primeiro que as pessoas desejam se comunicar de uma maneira mais interativa e de diversas formas por exemplo, atravs de e-mail, mensagens instantneas, vdeo alm disso h uma necessidade de integrar aplicaes de voz e de dados. Outro motivo reside na popularidade da Internet e do IP, onde aplicaes IP residem no somente em estaes de trabalho, como por exemplo, tambm em dispositivos sem fio e PDAs. Finalmente, a reduo de custos com telefonia, barateamento de telefones e de infra-estrutura constituem mais uma motivao para utilizao de VoIP. Entretanto, no cenrio atual, h empecilhos para se inserir com eficcia o servio de voz sobre IP na Internet. O primeiro obstculo que o servio de voz sobre IP requer condies especiais de rede para funcionar satisfatoriamente. Conforme discutido em [3], [4] e [5], um alto valor no atraso de transmisso dos pacotes, na variao do atraso, ou na taxa de perda de pacotes da fonte ao destino prejudicam a qualidade de uma sesso de voz sobre IP. Portanto, para a Internet constituir uma alternativa atrativa rede de telefonia pblica tradicional, deveria prover mecanismos que garantam a qualidade de servio (QoS) para as aplicaes VoIP. Vrias tcnicas e metodologias foram propostas para resolver direta ou indiretamente os problemas relacionados QoS, mas o maior problema no tecnolgico, mas a necessidade de adoo dessas tecnologias parte da Internet, de forma a no deixar o trfego de voz ser prejudicado com os congestionamentos do trfego de dados. Isso visa trazer um pouco de injustia a uma rede (Internet) que justa demais e acaba penalizando os servios que tm requisitos fortes para ter desempenho aceitvel. Outra barreira para a difuso da tecnologia de voz sobre IP est relacionada ao crescimento da Internet e implantao de mecanismos de segurana nas redes de acesso. Esses fatos impulsionaram mudanas na Internet, violando seu argumento fim-afim [6], que determina que a rede deve executar apenas tarefas muito simples. Como se percebe atravs de medies realizadas [7], entre essas mudanas est a disseminao de
13
sistemas intermedirios como NAT e firewall nas redes de acesso que, de acordo com Shieh [8], prejudicam os servios e aplicaes de voz sobre IP. As aplicaes e servios VoIP no figuravam entre os mais populares da Internet at 2003, quando a empresa Skype1 disponibilizou sua aplicao VoIP gratuitamente. Apesar de se basear na Internet - uma rede que no oferece garantias de QoS - uma chamada do Skype alcana boa qualidade de voz ao utilizar codificadores de udio proprietrios e projetados para funcionar em ambientes com elevadas taxas de atraso, variao do atraso e perda de pacotes. Alm disso, o Skype implementa mecanismos para transpor as barreiras de comunicao impostas por firewalls e NATs. Seguindo a mesma linha do Skype, em 2005 o Google disponibilizou sua aplicao VoIP gratuita, o GTalk2. A grande participao de Voz sobre IP (VoIP) nos mercados hoje considerado um grande motivo para a reduo de custos do servio de telefonia. Infelizmente, essa reduo no perceptvel ainda no Brasil para quem no adotou alguma tecnologia VoIP. Problemas de regulamentao tambm impedem uma maior adoo da tecnologia no Brasil, o que nos torna meros seguidores atrasados das tendncias mundiais. Para que seja possvel implantar uma rede de VoIP, necessrio utilizar alguma tcnica de avaliao de qualidade do servio oferecido por essa rede. O MOS (Mean Opinion Score) a metodologia mais conhecida, mas j no mais utilizada em funo de sua dificuldade de utilizao. O PESQ (Perceptual Evaluation of Speech Quality), a metodologia que tem ganho preponderncia atualmente, junto com o Modelo-E, que mais simples de implementar em alguns aspectos. Existem diversos softwares, muitos de cdigo aberto, que podem ser utilizados para a implantao de VoIP em grandes redes, mesmo em redes de operadoras mundiais. O mais importante deles, o Asterisk, considerado um PBX livre (Private Branch eXchange ou central telefnica privada), um software de cdigo aberto que implementa boa parte dos algoritmos de sinalizao de diversas redes de voz (analgicas, digitais de comutadas e mesmo de VoIP). Como funciona com diversas placas de telefonia, tambm freqentemente usado para implantao de servios de VoIP em locais que tm infra-estrutura analgica, funcionando como um Gateway de converso da comunicao e da sinalizao entre as redes. Por ser livre e ter o cdigo fonte disponvel, cada vez mais usado pelas empresas que desejam utilizar servios VoIP. Com tudo isso, a implantao de uma rede de VoIP uma tarefa difcil e custosa, que requer um grande planejamento e ateno, por requerer a implantao de muitas tecnologias simultaneamente. A seo 1.2 a seguir trata da tecnologia da telefonia pblica tradicional e a seo 1.3 trata das tcnicas utilizadas para a codificao da voz para uso em VoIP. A seo 1.4 trata dos mais importantes protocolos de sinalizao e controle de VoIP e de seus problemas. A seo 1.5 trata das tecnologias de qualidade de servio que permitem uma convivncia no-igualitria, mas harmoniosa de diversos servios na Internet. A seo 1.6 traz as metodologias utilizadas para aferio de qualidade em redes VoIP e a seo 1.7 traz alguns estudos de caso realizados com o
1 2
http://www.skype.com http://www.google.com/talk
14
uso de tecnologias de VoIP. Finalmente, a seo 1.7 tece algumas concluses acerca da implantao da tecnologia e a seo 1.8 traz as referncias utilizadas nesse texto.
1.2 A Rede de Telefonia Pblica Tradicional

Antes de apresentar o funcionamento de voz sobre IP, interessante conhecer o seu concorrente e predecessor. A rede de telefonia pblica (PSTN Public Switched Telephone Network) foi projetada com o objetivo de transmitir a voz humana, diferentemente da Internet, que tem o objetivo de transportar dados. O sistema telefnico utiliza a tcnica de comutao por circuitos [9]. Nessa tcnica, durante uma ligao, um circuito reservado do telefone que chama ao telefone chamado, estabelecendo-se um caminho fim-a-fim entre as partes antes de se comunicarem. Com utiliza uma linha dedicada, durante uma ligao no ocorre o problema de congestionamento, existente na Internet. O sistema telefnico organizado hierarquicamente em vrios nveis [9] [10] e formado por centrais telefnicas. Cada telefone est ligado a uma central local, que obtm o sinal analgico do telefone, o digitaliza e o transmite para uma central no ncleo da PSTN, chamada de central tandem. A conversa digitalizada segue pelas centrais do ncleo at retornar central local do outro telefone, onde o sinal novamente convertido para analgico e entregue. Em sistemas de voz sobre IP, os roteadores da Internet desempenham uma funo anloga s centrais da PSTN. Em ambientes corporativos, a estrutura do sistema de telefonia ligeiramente alterada para fornecer alguns servios complementares como o de ramais, transferncia de chamadas e conferncia. Alm disso, empresas necessitam possuir sua prpria rede de telefonia, para a comunicao interna. Ao contrrio de telefones residenciais, onde um telefone se liga diretamente a uma estao local, em ambientes corporativos, os telefones se ligam a um PABX (private automatic branch exchange), que basicamente uma central privada. O PABX responsvel por promover reduo de custos, fornecendo as funes descritas acima e permitindo que os usurios internos empresa compartilhem um nmero limitado de linhas telefnicas externas. A Figura 1 mostra uma chamada telefnica entre um usurio domstico e um usurio corporativo utilizando a PSTN. O advento das centrais telefnicas digitais, conhecidas como CPA (Central por Programa Armazenado), trouxe um novo rumo para o mercado. Equipamentos compactos, com processador central e programao atravs de software levaram a telefonia para o mundo da informtica. Todo acesso ao equipamento passou a ser feito atravs de um computador com um software proprietrio, o qual permitiu executar toda a programao do equipamento (roteamento, criao de novos assinantes/ramais, criao de novos links) e trouxe novas facilidades para os assinantes. A programao tornou-se flexvel, mas os protocolos de sinalizao entre equipamentos e a forma de estabelecimento das chamadas continuaram os mesmos.
15
PSTN
Ambiente Corporativo
Central tandem Central local Central tandem Central local Telefone Analgico
PABX
Figura 1. Chamada entre um usurio domstico e um usurio corporativo na PSTN A maioria das empresas possui sua rede de dados interligada Internet atravs de enlaces dedicados das concessionrias de telecomunicaes, utilizando o protocolo IP. Em paralelo a essa rede, as empresas mantm uma rede de telefonia privada, tambm ligada rede pblica atravs de links digitais ou linhas analgicas. Essa rede bastante onerosa, tanto no que diz respeito ampliao e manuteno dos equipamentos, quanto ao custo mensal das ligaes geradas. A grande vantagem da tecnologia VoIP a reduo dos custos telefnicos, aproveitando uma infra-estrutura de rede j existente.
1.3 Transmisso da Voz

Esta subseo expe o processo de manipulao do som em um sistema VoIP [11], desde sua entrada no sistema (um emissor enviando um sinal analgico) at sua sada em um terminal VoIP remoto. O processo ilustrado na Figura 2 e descrito em seguida.
Rede buffer digitalizao empacotamento desempacotamento decodificao
Figura 2. Tratamento dado ao som em um sistema VoIP 1.3.1 Digitalizao do Sinal
A voz humana um sinal analgico de udio que possui amplitudes variveis no tempo. Para que esse sinal analgico possa ser utilizado em ambientes digitais necessrio transform-lo num sinal discreto. A esse processo de converso de um sinal analgico num sinal digital chamamos de digitalizao, estando as etapas desse processo representadas na Figura 3. O processo de digitalizao de um sinal consiste de trs etapas: amostragem do sinal analgico, quantizao e codificao. Na amostragem retirada parte do sinal
16
analgico, de forma que no haja perdas de informao na reconstituio desse sinal. Para tanto, usado o Teorema de Nyquist [12], o qual especifica que a freqncia de amostragem (fa) deve ser maior que duas vezes a maior freqncia contida no sinal analgico (fs): fa > 2fs.
Filtro 300Hz a 3400Hz Etapa de Amostragem Etapa de Quantizao Etapa de Codificao
111001
Figura 3. Processo de digitalizao de um sinal de voz Para a faixa de freqncia de 300 Hz a 3400 Hz, usada na telefonia convencional, foi fixada, internacionalmente, uma freqncia de amostragem (fa) de 8000 Hz, o que resulta num intervalo de amostragem (ta) de 125 s. O sinal resultante dessa amostragem ainda um sinal analgico, o qual transformado num sinal digital aps a quantizao e codificao. Aps a quantizao, o sinal codificado e enviado ao meio de transmisso. Do lado do receptor, o sinal decodificado, ou seja, feita a converso de sinal discreto para sinal analgico, inteligvel aos ouvidos humanos. 1.3.1.1. Algoritmos de Codificao Segundo Monteiro [13], os codificadores tm como principal objetivo a reduo da taxa de transmisso de bits (compresso do sinal), o que influencia diretamente no espao de memria e na largura de banda necessria para a transmisso. Em contrapartida, tm como desvantagens o aumento do atraso e a perda da qualidade do sinal, devido ao processamento do algoritmo de codificao e decodificao, conforme mostrado na Figura 4.
Conversor
origem
A/D
Rede Digital
Conversor
D/A
Destino
sinal analgico
Amostras digitais aplicao
voz comprimida rede
voz comprimida
Amostras digitais
sinal analgico
aplicao Atraso de descompresso, converso analgica
Atraso de captura, digitalizao e c ompresso
Atraso de transmisso
Figura 4. Atrasos na transmisso de um sinal Os codecs possuem caractersticas que determinam a escolha para o seu uso: taxa de bits, atraso, complexidade do algoritmo, qualidade. Esta diz respeito ao nvel mximo de qualidade a ser obtida pelo receptor. Nesse sentido, o PCM Linear fornece a melhor qualidade, embora utilize uma banda maior.
17
Existem codificadores de udio que foram desenvolvidos especificamente para a compresso da voz humana [14]. Esses algoritmos exploram redundncias e relevncias (sinais fora de freqncia produzida pela voz) encontradas nos sinais, ou at propriedades do ouvido humano como aproximaes e preenchimento de seqncias incompletas. Esses codificadores, tambm conhecidos como codificadores hbridos, foram projetados a partir dos codificadores de forma de onda e dos vocoders. Os codificadores de forma de onda possuem a vantagem de apresentarem melhor qualidade, embora utilizem uma maior largura de banda (64 kbps). Um exemplo o G.711 [15]. Os vocoders so codificadores que tentam modelar a forma de onda da voz, comparando o sinal original com valores j gravados no seu sistema. Tentam imitar o sistema de reproduo de voz humana. Esses codificadores usam pequena largura banda, em torno de 4.8 kbps, mas possuem baixa qualidade na reproduo da voz, que resulta numa voz sinttica (robtica). Existem algumas entidades responsveis por normalizar codificadores de udio e vdeo, tais como a International Telecommunication Union (ITU-T), Telecommunication Industries Association (TIA) e United States Federal Standards (USFS). Para codificar o sinal udio em tempo real alguns dos codificadores mais conhecidos so ITU-T G.711, ITU-T G.722, ITU-T G.726, ITU-T G.723, ITU-T G.729, GSM, iLBC e MPEG-Audio e para a codificao de vdeo em tempo real os codificadores H.261, H.262, H.263 e JPEG. Esse ltimo, muito conhecido como um formato para fotos, um codificador para compresso de imagens estticas. No codec G.711 a quantificao da voz feita numa escala logartmica. Esse codec o padro da telefonia convencional, apresentando uma excelente qualidade na reproduo da voz, porm requer uma largura de banda maior para a transmisso (64kbps). A digitalizao do sinal e a quantidade de canais utilizados nessa transmisso determinam a quantidade de bytes requeridos para se armazenar o sinal e a largura de banda para se transmitir essa seqncia de udio. O G.729 [16] e G.723.1 [17] pertencem classe de algoritmos que utilizam o modelo CELP (Code Excited Linear Prediction), que o modelo de codificao utilizado pela telefonia mvel. O modelo CELP foi projetado para operar em redes de circuitos chaveados, levando em considerao perda de bits e no perdas de pacotes. Esses codecs trabalham com um sinal digital convertido em um sinal analgico, obtido por filtragem, conforme recomendao G.712 [18]. Aps 8.000 amostragens por segundo, o sinal convertido para um PCM linear de 16 bits, servindo de entrada para o codificador. A sada do decodificador convertida para analgica de forma muito parecida. Os filtros do G.729 utilizam coeficientes gerados pelo mtodo de autocorrelao com janelas de observao de 30ms. A cada 80 amostragens a 10ms os coeficientes so atualizados e feito o deslizamento da janela, realizando assim a anlise destes valores levando em conta as 120 amostras dos 4 quadros passados, as 80 amostras do quadro atual e 40 amostras do prximo quadro, onde se pode observas os 5ms de look-ahead.
18
Na Tabela 1, temos os tipos de codecs mais utilizados, com as respectivas caractersticas: tcnica de compresso utilizada, taxa de gerao do sinal, atraso de empacotamento e qualidade do sinal (MOS). O parmetro MOS (Mean Opinion Score), est definida pela ITU-T nas recomendaes P.800 [19] e P.830 [20]. O MOS uma avaliao subjetiva, obtida atravs de testes, em que um conjunto de ouvintes avaliam a qualidade da voz numa escala de1(ruim) a 5(excelente). Tabela 1. Caractersticas de alguns codecs Codec Tcnica de Compresso Taxa de bit (Kbps) 128 64 6.3 5.3 Atraso de Codificao (ms) 0,125 0,125 30 30 0,125 3-5 10 MOS 4,5 4,1 3,6 3,1 3,8 3,6 3,7
Linear Linear Sem compresso G.711 PCM - Pulse Code Modulation G.723.1 MP MLQ G.723.1 ACELP - Algebraic Code Excited Linear Prediction
G.726 ADPCM Adaptive Diferencial 16,24,32,40 PCM (16, 24, 32, 40 Kbps) G.728 LD CELP Low Delay Code Excited Linear Prediction G.729A CS-ACELP Conjugate Structure Algebraic Code Excited Linear Prediction GSM Regular Pulse Excitation Long Term Predictor (RPE-LTP) 16 8
13
10
3,8
Conforme podemos observar, ainda na Tabela 1, os codecs G.729A e o G.723.1 utilizam uma reduzida largura de banda, porm tm uma menor qualidade, traduzida em valores de MOS menores, apresentando tambm, tempos de codificao mais elevados. Com o desenvolvimento de aplicaes de VoIP, uma nova gerao de codecs, tolerante a perdas de pacotes, foi desenvolvida para atender as novas necessidades do mercado, tais como: iLBC, iPCM e iSAC. Segundo [21], o Skype utiliza o iLBC como um dos seus codecs. O iLBC [22] um codec projetado para trabalhar com canais de 15,2 Kbit/s para um quadro de 20 ms e 13,33 Kbit/s para um quadro de 30 ms. No seu algoritmo usa o mtodo Linear Predictive Code (LPC) para a compresso da voz. adequado para aplicaes em tempo real, tais como: telefonia, vdeo-conferncia. No projeto no XVoice foi utilizado o codec GSM 06.10 RPE-LTP (Regular Pulse Excitation Long-Term Prediction), tambm conhecido como GSM FULL RATE. A principal caracterstica do codec GSM o modelo matemtico que modela o sistema vocal humano, utilizando o mtodo de compresso LPC. O LPC um mtodo
19
de compresso digital projetado especificamente para voz. Ele adapta o sinal de voz por um modelo matemtico para transmisso, e depois decodifica para gerar uma voz sinttica similar a original. Esse algoritmo usa a informao da amostra anterior para predizer a amostra atual. O sinal amostrado dividido em blocos de 20ms, com taxa de 13kbps, formando quadros de 260 bits. 1.3.2 Empacotamento e Transmisso
Em um sistema ideal, os quadros ou amostras provenientes do codec seriam transmitidos na medida em que fossem processados. O codec G.711, por exemplo, possui uma taxa de amostragem de 8000Hz e seria necessrio enviar um pacote (que contm uma amostra) a cada 125 microssegundos, saturando a rede de informaes relacionadas aos protocolos que carregam os pacotes, subutilizando a carga til da rede. Portanto, interessante esperar um certo tempo para enviar uma determinada quantidade de amostras em um mesmo pacote. O empacotamento consiste em inserir as amostras ou quadros processados pelo codec em pacotes. Conforme discutido anteriormente, utiliza-se o IP para encaminhamento de dados em uma rede, tornando possvel a comunicao entre as mquinas. Entretanto, para que as aplicaes residentes nas mquinas se comuniquem, essencial a utilizao de um protocolo de transporte, como o TCP [23] e o UDP [24], usados na Internet. Abreviao para Protocolo de Controle de Transmisso, o TCP [23] reenvia os pacotes perdidos e garante a entrega dos dados na ordem que foram enviados. O TCP orientado a conexo, o que significa que antes de realmente transmitir os dados, necessrio estabelecer uma conexo entre as aplicaes, com um processo conhecido como three-way-handshaking. O TCP realiza o controle de fluxo, um mecanismo para proteger o remetente de saturar o destinatrio, ou seja, evita que o remetente envie informaes em uma taxa alm daquela que o destinatrio possa processar. Finalmente, o TCP implementa o controle de congestionamento, que tem a funo de reduzir a taxa de transmisso de acordo com o nvel de congestionamento da rede. O UDP [24] um protocolo no orientado conexo onde os pacotes podem ser entregues fora de ordem ou at perdidos. Ao contrrio do TCP, o UDP no prov controle de fluxo nem congestionamento. Em resumo, a idia por trs do UDP transmitir dados com o maior velocidade possvel, sem confiabilidade, ao contrrio do TCP, onde a confiabilidade o aspecto mais importante. Informaes de voz so geralmente transmitidas usando UDP como protocolo de transporte. As principais motivaes para se usar UDP, ao invs de TCP, em VoIP so: Caso um pacote no incio de uma seqncia seja perdido, mesmo que os subseqentes cheguem ao destino, o TCP espera a retransmisso do primeiro pacote para entregar todo o restante da seqncia aplicao. Esse aspecto adiciona um atraso determinado pelo prprio protocolo TCP, prejudicando a interatividade. O three-way-handshaking do TCP adiciona latncia ao incio da comunicao; Devido aos mecanismos de controle de fluxo e de congestionamento do TCP, a taxa de transmisso do TCP no controlada pela aplicao, mas pelo prprio protocolo.
20
No entanto, certas aplicaes de voz sobre IP, como por exemplo, o GTalk e o Skype, em algumas ocasies, utilizam TCP na comunicao. No se encontrou na literatura e nos sites das aplicaes o motivo para tal comportamento. 1.3.2.1. RTP/RTCP Para aplicaes VoIP apenas o servio de entrega de pacotes provido pelo UDP no suficiente. So necessrios outros servios, como, por exemplo, saber a ordem e tempo de gerao de pacotes alm de possuir o conhecimento acerca da qualidade da conexo. Essas atividades competem ao RTP e ao RTCP. Esses protocolos se propem a melhorar a entrega de dados que devem ser transmitidos pelos aplicativos em tempo real. O RTP (Real-Time Transport Protocol) tem como objetivo dispor servios essenciais para aplicaes de tempo real, alm de obviamente transportar a mdia (e.g. voz, vdeo) dessas aplicaes. O RTCP (Real Time Control Protocol) obtm informaes da rede (quantidade de jitter, perda mdia de pacotes, etc.), permitindo que medidas corretivas apropriadas possam ser adotadas, tais como: uso de redundncia, codecs a taxas mais baixas. O projeto do RTP/RTCP permite que esses protocolos sejam usados principalmente em cima do UDP, uma vez que o esquema de retransmisso do TCP no traria nenhum benefcio para a transmisso de aplicaes em tempo real. O RTP um dos protocolos mais importantes da arquitetura VoIP. Conforme descrio em [25], o RTP um protocolo que prov servios de entrega fim-a-fim para aplicaes com caracterstica de tempo real, como udio e vdeo interativos. Suporta transferncia de dados para servios multicast e tambm possui caractersticas de reconstruo de sincronismo, deteco de perda de datagramas, segurana, dentre outras. No entanto, o RTP no oferece nenhuma reserva de recurso na banda, nem recuperao dos pacotes e no garante qualidade de servio (QoS). A qualidade de servio definida pelo ITU-T como "o efeito coletivo de desempenho que determina o grau de satisfao do usurio deste servio especfico". Os parmetros de QoS se relacionam com mtricas de controle de chamada, de transferncia de informao e de qualidade da rede. Sendo assim, o RTP utiliza o RTCP para monitorar QoS e transportar informaes em uma sesso contnua. O RTCP tem como objetivo o monitoramento da qualidade de servio e o transporte de informaes teis numa transmisso RTP. Esse monitoramento conseguido atravs de relatrios que so gerados tanto pelos transmissores como pelos receptores dos pacotes RTP. um protocolo que pode ser usado juntamente com o RTP, porm sua utilizao no necessria para que o RTP funcione. Os relatrios utilizados pelo RTCP contm informaes tais como: nmero de pacotes enviados, nmero de pacotes perdidos, jitter. Embora essas informaes no informem onde determinado problema est ocorrendo, elas podem servir como ferramenta para localizar o problema. Para que no haja excesso de trfego RTCP, o ritmo de gerao deste tipo de relatrio alterado dinamicamente, para que no ultrapasse 5% do trfego total na sesso, segundo recomendao do IETF. Esta situao de trfego elevado poderia ocorrer facilmente devido ao uso de multicast, onde muitos clientes enviam relatrios para o mesmo servidor.
21
O pacote VoIP formado pelo cabealho IP, pelo cabealho UDP, pelo cabealho RTP, num total de 40 bytes, e finalmente pela carga til (payload), que representa amostras de voz. A carga til varia de 20 bytes at 160 bytes para o fluxo de voz. Para uma carga til de 20 bytes, temos que o cabealho do pacote VoIP o dobro da carga til. Conclumos que a transmisso de pouca informao por pacote bastante ineficiente. Para aumentar a eficincia da transmisso de voz, pode-se utilizar uma tcnica de compresso que reduz o tamanho do cabealho para 2 bytes, se no existir checksum, ou para 4 bytes para o envio de checksum UDP. Essa tcnica, muito utilizada nas linhas de baixa velocidade, designada cRTCP (Compressed RTP), sendo definida na RFC 2508 [26]. 1.3.3 Problemas Relacionados Transmisso de Voz
As aplicaes VoIP so aplicaes em tempo real, possuindo requisitos bem mais exigentes que as aplicaes que rodam normalmente na Internet.
Transmisso Recepo
Figura 5. Exemplifica o fator atraso numa rede de pacotes Existem diversos fatores que podem prejudicar a qualidade da comunicao, sendo os mais crticos o atraso, o jitter e a perda de pacotes. O atraso refere-se ao tempo entre o envio da mensagem do transmissor e o recebimento desta mensagem pelo receptor (ver Figura 5). O jitter a variao no atraso da transmisso, conforme mostrado na Figura 6. As perdas de pacotes podem ocorrer porque as redes baseadas no protocolo IP no garantem a entrega dos mesmos, ou por um grande atraso na entrega dos pacotes, fazendo com que a aplicao descarte os mesmos.
Transmisso Recepo
Figura 6. Exemplifica o fator jitter numa rede de pacotes Segundo [27], as recomendaes sobre atraso, jitter e perda de pacotes para que uma rede possibilite uma boa qualidade de chamadas VoIP so: atraso fim-a-fim menor
22
que 150 ms, limite mximo de 50 ms para jitter, taxa de perda de pacotes mxima de 3% (recomendvel que seja inferior a 0,50%). O no cumprimento desses limites compromete a inteligibilidade do sinal entregue ao receptor, podendo inviabilizar a aplicao. 1.3.4 Uso de Buffers
Na recepo do udio de um sistema VoIP, a mdia deve ser reproduzida medida que o receptor recebe os dados e da mesma maneira que foi gerado. Portanto, o processo de envio dos dados pelo emissor est sincronizado com o processo de reproduo. Contudo, como visto anteriormente, o servio de entrega dos dados na Internet no fornece um atraso determinstico, ou seja, o atraso varivel devido a diferentes condies de rede enfrentadas por pacotes consecutivos. Com isso, o sincronismo necessrio no garantido. Logo, necessria uma memria temporria (buffer) que minimize ou elimine os problemas que a variao do atraso causa execuo do udio. Para ilustrar a importncia da buferizao, considere a Figura 7.
Pacotes gerados e recebidos
emissor
receptor
tempo
Figura 7. Envio e recepo de pacotes contendo voz [28] No emissor, ocorre o empacotamento e transmisso, onde pacotes contendo amostras de udio so periodicamente enviados. Entretanto, os pacotes chegam no receptor com um atraso no-determinstico. Com o intuito de suavizar essa variao do atraso, o receptor pode retardar a execuo do udio recebido armazenando os quadros mais recentes em um buffer. Na Figura 7, se o receptor retardasse a execuo do udio at t2, todos os pacotes teriam sido reproduzidos, mas se t1 fosse utilizado, os pacotes 6, 7 e 8 teriam sido descartados pelo receptor.
1.4 Sinalizao e Controle de VoIP

Da mesma forma que na telefonia tradicional, ao se contactar algum, a pessoa que realiza a chamada (chamador) precisa ser informada se o telefone da pessoa chamada est tocando ou ocupado. No outro lado, o telefone deve sinalizar com um toque que algum deseja se comunicar. Esse procedimento conhecido como sinalizao, que
23
consiste no processo de estabelecimento e desligamento da sesso VoIP entre a pessoa que realiza a chamada e a pessoa que recebe a chamada. A primeira etapa de uma chamada de voz sobre IP, responsvel por iniciar, gerenciar e finalizar sesses voz. Na seqncia, com o propsito de apresentar de forma mais concreta a sinalizao em voz sobre IP, sero apresentados os protocolos mais comuns no contexto: H.323, SIP, IAX2, SCCP, MGCP e MEGACO. 1.4.1 H.323
O protocolo H.323 [29][30] usado para a transmisso de udio, vdeo e dados sobre redes baseadas em pacotes (ver Figura 8). Ele especifica os componentes, os protocolos, e procedimentos para o trfego de multimdia. O H.323 pode ser usado para uma variedade de aplicaes: Telefonia IP, Videofone, udio e dados e udio, vdeo e dados. H.323 tambm pode ser aplicado a comunicaes multiponto (conferncia).
Figura 8. Terminais H.323 em uma rede puramente de pacotes O padro H.323 foi especificado pelo grupo de estudo 16 da diviso de Telecom Standardization (ITU-T) da International Telecommunication Union3 (ITU), um rgo das Naes Unidas para a padronizao e regulamentao de telecomunicaes. A verso 1 da recomendao H.323, aceita em Outubro de 1996, era voltada para os sistemas e equipamentos de videofone para redes locais (LANs). Esta verso no tratava de qualidade de servio. Todas as mensagens so codificadas usando a sintaxe Abstract Syntax Notation 1 (ASN.1), tambm definida pela ITU. O aparecimento de aplicaes de Voz sobre IP (VoIP) e de telefonia IP forou uma reviso da especificao H.323. A ausncia de um padro de Voz sobre IP resultou em produtos incompatveis. Com o desenvolvimento de VoIP, as novas exigncias apareceram, como fornecer uma comunicao entre um telefone baseado em PC (softphone) e um telefone em uma rede de comutao de circuito tradicional (Switched Circuit Network - SCN). Tais exigncias aumentaram a necessidade de um padro para telefonia IP. As verses seguintes do H.323 foram criadas para acomodar estas exigncias adicionais, alm de transmisso de fac-smile (FAX), conversao de texto, segurana, controle de servios baseado em HTTP, sinais de modem, controle de cmera, redirecionamento e restabelecimento de sinalizao. A ltima verso do protocolo H.323 de Junho de 2006.
http://www.itu.int
24
1.4.1.1. Entidades do H.323 O protocolo H.323 especifica quatro componentes que, interligados em rede, provem os servios de multimdia ponto-a-ponto e ponto-a-multiponto: Terminais, Gateways, Gatekeepers e Unidades de Controle Multiponto (Multipoint Control Unit - MCU). Um terminal H.323 pode ser um computador pessoal rodando uma aplicao multimdia ou um dispositivo dedicado a uma aplicao especfica. O terminal deve suportar comunicao de udio e pode suportar comunicao de vdeo e dados, opcionalmente. Terminais H.323 podem ser usados em conferncia multiponto. Um dos principais objetivos do H.323 a interoperabilidade com outras redes de servios multimdia. Essa interoperabilidade alcanada com o uso de um gateway. Um gateway H.323 prov conectividade entre uma rede H.323 e uma rede no-H.323 (SIP, PSTN, etc), realizada atrevs da traduo de protocolos para realizao e liberao de chamada e pela converso de mdia entre as diferentes redes. importante notar que um gateway no relevante para a interconexo entre dois terminais em uma rede H.323. Um gatekeeper pode ser considerado o crebro de uma rede H.323. o ponto mais importante para as chamadas entre equipamentos de uma ou mais redes H.323. Embora no sejam requeridos para comunicao, gatekeepers provem servios como endereamento, autenticao e autorizao de terminais e gateways; gerenciamento de banda; contabilidade; e cobrana. Tambm podem prover roteamento de chamadas. MCUs provem suporte a conferncia de trs ou mais terminais H.323. Todos os terminais participando da conferncia estabelecem uma conexo com o MCU. O MCU gerencia recursos da conferncia, negocia com os terminais para determinar os codificadores/decodificadores (CODECs) de udio ou vdeo que sero usados e pode se encarregar de tratar a transmisso. Observa-se que os gatekeepers, gateways e MCUs so elementos lgicos distintos na arquitetura do H.323, mas podem ser implementados no mesmo dispositivo fsico. 1.4.1.2. Componentes do H.323 Uma zona H.323 (ver Figura 9) uma coleo de terminais, gateways e MCUs gerenciados por um nico gatekeeper. Uma zona inclui pelo menos um terminal e pode incluir gateways e MCUs. Uma zona tem somente um gatekeeper. Uma zona pode ser independente da topologia de rede e pode consistir dos mltiplos segmentos de rede que so conectados usando roteadores e outros dispositivos. Os principais protocolos utilizados pelo H.323 esto listados abaixo. A especificao independe da rede e dos protocolos de transporte utilizados. CODECs de udio e vdeo H.225: registro, admisso e estado (RAS) e sinalizao de chamadas H.245: sinalizao de controle Real-Time Transport Protocol (RTP) e Real-Time Control Protocol (RTCP)
25
Terminais
GK
D-GK
Terminais
GK
rede IP zona 1
GW
zona 2
GW
PSTN
Figura 9. Gateway, Gatekeeper e Terminais em uma arquitetura H.323 Registro, admisso e estado (RAS) [31] o protocolo usado entre endpoints (terminais e gateways) e gatekeepers. O RAS usado para realizar registro, controle de admisso, mudana de banda, mudana de estado e procedimentos de desconexo entre endpoints e gatekeepers. Um canal RAS usado para trocar mensagens RAS. Esse canal de sinalizao aberto entre um endpoint e um gatekeeper antes do estabelecimento de qualquer outro canal. A sinalizao de chamada [31] usada para estabelecer uma conexo. Isso alcanado atravs da troca de mensagens H.225 no canal de sinalizao de chamada, que pode ser aberto entre dois endpoints ou entre um endpoint e um gatekeeper. A sinalizao de controle [32] usada para trocar mensagens de controle fim-afim e governar o funcionamento do endpoint H.323. As mensagens de controle trazem informaes relativas a troca de Capacidade, abertura e fechamento de canais lgicos (transporte de mdia), mensagens de controle de fluxo, indicaes e comandos.
SETUP CALL PROCEEDING ALERTING CONNECT H.245 Fluxo de Mdia RELEASE COMPLETE
Figura 10. Sinalizao de chamada usando H.323 sem Gatekeeper
26
A Figura 10 ilustra as mensagens trocadas em um processo normal de sinalizao utilizando H.323 sem a participao de gateways e gatekeepers. Primeiramente, iniciado contato com terminal remoto (mensagem SETUP), em seguida, o terminal remoto sinaliza que est processando a chamada (CALL PROCEEDING) e que seu telefone est tocando (ALERTING). O atendimento de chamada sinalizado atravs da mensagem CONNECT e o trmino de chamada sinalizado atravs da mensagem RELEASE COMPLETE. 1.4.1.3. Problemas Conforme discutido anteriormente, H.323 um protocolo que aproveitou esforos j realizados na definio de recomendaes da telefonia pblica. Embora adotado pela indstria, o H.323 possui diversos inconvenientes. Sabe-se que H.323 conhecido pela sua alta complexidade, onde sua recomendao tem aproximadamente 1400 pginas de documentao essencial e cobre um nmero maior de servios do que necessrio para telefonia IP. Outra dificuldade, principalmente enfrentada pelos programadores, que os protocolos de H.323 so especificados usando uma notao complexa, a ASN.1, que dificulta o desenvolvimento e depurao das aplicaes. Outro inconveniente a grande quantidade de mensagens trocadas, alm do nmero excessivo de conexes que devem ser abertas para iniciar uma sesso de udio. A complexidade do H.323 encareceu equipamentos e fez com que a maioria dos fabricantes no o implementasse completamente. Embora ainda em grande utilizao, essa recomendao vem perdendo espao para o SIP, um protocolo mais simples que tenta solucionar os inconvenientes do H.323. 1.4.2 SIP
O SIP foi desenvolvido pelo grupo MMUSIC (Multiparty Multimedia Session Control) da IETF com a RFC 2543 em 1996, sendo publicada a RFC 3261 em 2002 [33], tornando a anterior obsoleta. Faz parte de uma arquitetura de protocolos de Conferncia Multimdia Internet, em desenvolvimento na IETF. Esses protocolos, mostrados na Figura 11, so partes independentes, mas so utilizados em conjunto numa aplicao VoIP. Temos como exemplo o SIP, que usa o SDP (Session Description Protocol) [34] para especificar as caractersticas da mdia utilizada, o RTP para o transporte da mdia e o RTCP para o monitoramento da conexo. O SIP um protocolo baseado em texto, assim como o SMTP e o HTTP, enviando requisies e esperando respostas. um protocolo da camada de aplicao projetado para controlar o estabelecimento de ligaes telefnicas, de vdeoconferncias e outras aplicaes multimdia, possuindo as seguintes caractersticas: Oferece recursos de controle de chamada como: chamada em espera, encaminhamento, transferncia, mudanas de mdia, etc; Aceita a infra-estrutura da Web, por exemplo, segurana, cookies, etc; orientado para Web e independente do protocolo de rede; Pode oferecer notificao de eventos e listas de companheiros;
27
Figura 11. Arquitetura de Protocolos de Conferncia Multimdia Internet
Suporta ligaes ponto-a-ponto, multiponto e multicast; Suporta servios como: localizao de um terminal, determinao da capacidade do terminal, sinalizao para estabelecimento e trmino de chamadas; Na rea de segurana suporta encriptao e autorizao de usurio.
1.4.2.1. Arquitetura Bsica do SIP As entidades SIP se comunicam usando transaes. O SIP chama cada transao de pedido, e cada pedido provoca uma ou mais respostas, at que ocorra uma resposta final. O iniciador de um pedido SIP chamado de cliente SIP e a entidade que responde chamada de servidor SIP. A fase inicial de uma conexo SIP consiste em abrir uma conexo de sinalizao entre os pontos de origem e destino da chamada. Pontos finais SIP podem usar UDP ou TCP, uma vez que as sintaxes das mensagens independem do protocolo de transporte usado. Quando se usa TCP, a mesma conexo pode ser usada para todos os pedidos e respostas SIP (exceto dos dados de mdia), ou pode-se usar uma conexo para cada transao. Para o caso do UDP, o endereo e a porta a serem usados para as respostas a pedidos SIP estaro no parmetro via do pedido SIP. A porta 5060 utilizada para ambos os protocolos de transporte, a no ser que outra porta seja especificada. 1.4.2.2. Endereamento SIP Os usurios SIP so definidos por URIs (Universal Resource Identifiers), parecidos com endereos de e-mails, que podem conter endereos IPv4, IPv6, nmeros de telefones ou nomes. O padro de endereamento SIP user@host. O user pode ser o nome do usurio, o nmero do telefone ou um nome qualquer. O host poder ser o nome de um
28
domnio ou um endereo de rede. Exemplos de endereos sip:21268999@ufpe.br, sip: gprt@ufpe.br, sip:maria@192.168.0.179. 1.4.2.3. Mensagens SIP
SIP
so:
As mensagens SIP so classificadas em requisies e respostas. Na verso atual (SIP 2.0), h seis tipos de requisies, conforme descrio a seguir: INVITE: Sinaliza um convite para uma sesso. Em VoIP, um campo SDP sempre est anexo ao INVITE. ACK: Confirma que o cliente recebeu uma resposta final para um INVITE. OPTIONS: Solicita informaes sobre capacidades (e.g. codecs disponveis). BYE: Finaliza uma chamada CANCEL: Cancela mtodos/pedidos pendentes. REGISTER: Usado para se registrar em um servidor SIP.
INVITE + (SDP) 180 Ringing 200 OK + (SDP) ACK RTP - RTCP BYE 200 OK
Figura 12. Troca de mensagens numa chamada com SIP As repostas aos mtodos esto agrupadas em seis classes de cdigo. A classe 1XX (Infomation) representa as respostas provisrias. A mensagem 180 Ringing, por exemplo, sinaliza campainha. A classe 2XX (Success) indica sucesso. A classe 3XX (Redirection) usada para redirecionamento de chamada. Finalmente, as classes 4XX (Request Failure), 5XX (Server Failure) e 6XX (Global Failure) servem para reportarem falhas. A Figura 12 mostra uma ligao VoIP bem sucedida, sinalizada com SIP. 1.4.2.4. Componentes SIP Na arquitetura SIP h dois tipos de componentes: agente usurio e servidores de rede. O agente usurio composto pelos User Agent Client (UAC) e User Agent Server (UAS). O UAC usado para iniciar uma requisio SIP, enquanto o UAS recebe requisies e retorna respostas aos clientes.
29
proxy server
redirect server
INVITE 100 Trying INVITE 100 Trying 180 Ringing 180 Ringing 200 OK 200 OK 100 ACK 100 ACK RTP - RTCP
INVITE 3xx Redirect ACK INVITE 180 Ringing 200 OK ACK RTP - RTCP
(a) Proxy Server
(b) Redirect Server
Figura 13. Exemplos de proxy server e redirect server em uma sesso SIP H dois tipos de servidores de rede: Servidor de Proxy e Servidor de Redirecionamento (ver Figura 13). O Servidor de Proxy atua como cliente e servidor com o objetivo de fazer pedidos para outros clientes. Os pedidos so atendidos internamente ou encaminhados para outros servidores, aps serem traduzidos. Assim, um Proxy interpreta, e se necessrio, reescreve uma mensagem antes de reenviar. O Servidor de Redirecionamento aceita um pedido SIP, convertendo, se necessrio, em novos endereos e devolvendo esses endereos ao cliente. Os Servidores de Proxy e de Redirecionamento utilizam outros servidores denominados Servidores de Localizao para obter informao sobre a localizao de um determinado cliente SIP. Porm os Servidores de Localizao no fazem parte da especificao SIP. 1.4.3 IAX2
O IAX2 (Inter-Asterisk eXchange) a segunda verso do protocolo de VoIP especificado para comunicao entre servidores de PBX Asterisk e outros servidores/clientes e dispositivos VoIP. Quando citado somente como IAX, normalmente podemos tomar por referncia segunda verso do protocolo [35], j que sua primeira verso caiu em desuso, em prol do IAX2. Assim como o SIP e outros protocolos para controle e sinalizao de sesses multimdia, o IAX2 suporta os tipos mais comuns de mdias, mas otimizado para chamadas VoIP, onde importante diminuir a sobrecarga causada pelo protocolo e consumir pouca largura de banda. Este aspecto torna o IAX2 mais eficiente que outros protocolos que incorporam possibilidades bem alm das que hoje existem. Alm disso, o IAX2 utiliza uma mesma porta UDP para sinalizao e mensagens de mdia, facilitando seu uso com firewalls e NATs [36]. Outro esforo para aumentar a eficincia no uso da largura de banda foi tornar o IAX2 um protocolo de codificao binria.
30
O elemento atmico de comunicao do IAX2 o Frame. Existem vrias classes de Frames, como os Full Frames, que transmitem dados de sinal e controle, os Meta Frames, que so usados para roteamento de chamadas e transmisso de fluxos de vdeo, e os Mini Frames so usados para transmisso do fluxo de dados de mdias. Full Frames podem conter Information Elements (IEs), que descrevem tipos de usurios ou dados especficos da chamada. Uma chamada realizada com IAX2 pode ser composta por vrios segmentos, sendo possvel implement-los usando diferentes protocolos. O IAX2 responsvel por configurar um ou mais segmentos do caminho percorrido pela chamada, no necessariamente todos. Por ser um protocolo otimizado para uso ponto-a-ponto, ele pode supervisionar mudanas no caminho da chamada, at que o melhor caminho para a chamada seja configurado e estabelecido pelos participantes. O IAX2 suporta funcionalidades de segurana atravs de diferentes mtodos de autenticao, e prov um framework genrico para uso de encriptao. 1.4.4 SCCP
O Skinny Client Control Protocol (SCCP) um protocolo da Cisco, que era usado pelos primeiros equipamentos de VoIP da Cisco. O SCCP prov uma interface simples entre equipamentos VoIP, baseada em comandos e respostas, e usa RTP para transporte de mdia. Estre protocolo considerado obsoleto e ainda usado para interoperabilidade VoIP com antigos telefones Cisco que no implementam outros protocolos. 1.4.5 Controle de Gateways
Redes de VoIP muito grandes necessitam de uma forma automatizada de configurar e controlar seus equipamentos. Diversas redes de VoIP provem acesso telefonia convencional, utilizando muitos gateways. Pensando nessas redes, foram propostos protocolos com o objetivo de controlar gateways de maneira automtica, diminuindo o esforo de configurar e gerenciar uma quantidade muito grande de gateways de um por um. Um desses protocolos o Media Gateway Control Protocol (MGCP), definido pela IETF. Outro protocolo muito usado o Gateway Control Protocol (MEGACO/H.248.1), um esforo conjunto entre a IETF e a International Telecommunication Union4. Ambos so explicados a seguir. 1.4.6 MGCP
A arquitetura do MGCP [37] define trs elementos: Call Agent (CA, tambm chamado de Media Gateway Controller), Media Gateways (MGs) e Signalling Gateways (SGs). Os MGs so gateways propriamente ditos, isto , provem acesso a outras redes, como a rede de telefonia convencional. Comumente, os servios de MG e SG so implementados no mesmo equipamento. O CA informa aos Media Gateways que eventos devem ser reportados ao CA, como linhas devem se conectar umas s outras e que sinais devem ser tocados nas
4
http://www.itu.int
31
linhas. Tambm h mensagens de auditoria, para que o CA verifique o estado atual das ligaes. As mensagens definidas pelo MGCP, trocadas entre o CA e os MGs so divididas em duas categorias: comandos e respostas. Uma notificao de um MG para o CA um comando. O MGCP voltado para o gerenciamento de MGs que utilizam o protocolo SIP ou o H.323. Uma implementao livre do MGCP o OpenMGCP5, de cdigo aberto. 1.4.7 MEGACO/H.248.1
O MEGACO [38] uma proposta de implementao concorrente do MGCP e foi definido em conjunto pela IETF e a ITU como uma evoluo do MGCP. Ele baseado em mensagens com a sintaxe ASN.1, que tambm utilizada em H.323. Apesar disso, foi proposto para ser utilizando tanto em conjunto com uma infra-estrutura VoIP que utilize o protocolo SIP quanto uma que utilize o H.323. Em sua arquitetura so consideradas as interaes entre os Media Gateways (MGs) e o Media Gateway Controller (MGC). voltado para conexes de voz e de fax entre redes PSTN-IP e IP-IP. 1.4.8 Dificuldades de Implantao e Firewall
O texto abaixo se refere ao uso de VoIP com Firewalls e NATs (Network Address Translator), e foi extrado da dissertao de mestrado intitulada Avaliao de Desempenho de Aplicaes VoIP P2P, redigida por Rodrigo Barbosa [39]. Na arquitetura original da Internet, cada n possui ao menos um endereo IP nico e pode se comunicar diretamente com qualquer outro n. Devido ao crescimento da Internet e a conseqente escassez de endereos IPs, essa arquitetura foi substituda por um novo esquema [40]. Nessa nova estrutura, alm dos ns alcanveis publicamente, h ns com endereos privados (no roteveis), apenas visveis pelos ns de sua prpria rede. O acesso dos ns privados Internet realizado atravs de um intermedirio denominado NAT [41], que de maneira transparente, altera o endereo IP de origem do n privado para um endereo IP de origem diferente, que seja rotevel na Internet. Para se obter uma idia da disseminao dos sistemas intermedirios NAT, o grupo illuminati, em Julho de 2006, a partir de traces coletados de diferentes localidades da Internet, em sua anlise reportou a estatstica que 73,46% dos ns analisados estavam atrs de NAT [42]. A maior parte dos NATs implementam mecanismos de rastreamento de conexes (connection tracking) e de filtragem 6. Esses mecanismos trabalham em conjunto para garantir que o NAT apenas encaminhe pacotes de um fluxo (5-tupla formada por IPs origem e destino, portas origem e destino, protocolo) proveniente da rede pblica para rede privada quando houve anteriormente pelo menos um pacote desse fluxo saindo da rede privada para rede pblica. Dessa forma a comunicao de uma mquina na rede pblica com uma mquina na rede privada s possvel quando esta inicia o processo de comunicao.
5 6
http://sourceforge.net/projects/openmgcp Website do Netfilter/iptables, http://www.netfilter.org/
32
A forma como os protocolos de voz sobre IP foram projetados prejudica a comunicao entre mquinas que se ligam Internet atravs de NATs. Em SIP e H.323, as entidades envolvidas na comunicao devem possuir IPs roteveis, caso contrrio a chamada efetivamente no ocorre. Entretanto, com a evoluo dos aplicativos de compartilhamento de arquivos em redes peer-to-peer [43], como o KaZaA7, vieram novas formas de romper a dificuldade da comunicao impostas pelos NATs. Os aplicativos avaliados neste trabalho utilizam as tcnicas que seguem. O mtodo mais simples para comunicao atravs de NATs chamado de conexo reversa [44], podendo ser usado quando apenas uma das entidades est atrs de NAT. Suponha um cenrio em que o n N esteja atrs de um NAT e o n P possua um IP pblico. Para efetivar a comunicao, o n N inicia a comunicao com n P e dessa forma, devido aos mecanismos de filtragem e conexo reversa, torna-se possvel o envio de pacotes nos dois sentidos. Outro mtodo com o intermdio de um servidor remoto, que realiza a triangulao do trfego (relay server) [44]. Suponha um cenrio em que dois ns A e B desejam se comunicar utilizando UDP e estejam atrs de NATs distintos. Para efetivar a comunicao, o n A envia o fluxo de mdia para uma estao com IP pblico, que por sua vez encaminha o fluxo para B e vice-versa. Atualmente, o grupo de trabalho behave 8 da IETF trabalha na definio do protocolo TURN (Traversal Using Relay NAT) [45], que tem o objetivo de realizar a triangulao de trfego conforme apresentado. Apesar de ser mais confivel, esse mtodo eleva o atraso na rede e prejudica a interatividade. Para tratar desse problema, as novas aplicaes VoIP P2P possuem mecanismos de contorno de NAT que permitem a comunicao direta entre usurios. A tcnica de Hole Punching, exaustivamente discutida no trabalho de Ford [44], permite que dois ns atrs de NATs distintos estabeleam uma comunicao direta. A idia fundamental da tcnica que os dois ns atrs de NAT primeiramente se conectem a um terceiro, visvel na Internet, conhecido como rendevouz server. Uma vez que as informaes de estado das conexes estejam estabelecidas, os dois ns passam a se comunicar diretamente, esperando que os dispositivos que realizam NAT guardem os estados das conexes UDP, apesar do fato de os pacotes virem de mquinas diferentes ao rendevouz server. Esse mecanismo s possvel quando os NATs so do tipo cone, que sempre mapeiam uma 2-tupla (IP privado, porta privada) na mesma 2-tupla (IP pblico, porta pblica). Para melhorar o mecanismo de travessia de NAT, Algumas aplicaes usam a tcnica de Hole Punching associada a protocolos que permitem s aplicaes descobrirem a presena e tipos de NATs entre elas e a Internet pblica. O mais conhecido o STUN (Simple Traversal of UDP through NATs) [46], tambm definido pelo grupo de trabalho behave da IETF. Outro problema comumente enfrentado pelas aplicaes so as barreiras de controle e proteo que inspecionam o trfego de dados entre os usurios finais e a Internet, denominado de firewalls. Seu objetivo permitir somente a transmisso e a
Website do KaZaA, http://www.kazaa.com Website do Behavior Engineering http://www.ietf.org/html.charters/behave-charter.html
8 7
for
Hindrance
Avoidance
(behave),
33
recepo de dados autorizados. A fim de passar pelo bloqueio desses mecanismos, as aplicaes VoIP tentam burlar a barreira simulando o comportamento de aplicaes toleradas pelo firewall. O Skype, por exemplo, permite utilizar a porta 80 na comunicao, reservada para servios web, geralmente permitida pelos firewalls.
1.5 Gerenciamento de Qualidade de Servio

Caso uma infra-estrutura de rede IP seja compartilhada entre aplicaes VoIP e aplicaes de outros tipos de servio (e.g., dados), importante utilizar algum mecanismo que garanta o bom desempenho da rede para a aplicao de VoIP. Por este motivo, abordaremos aqui solues de qualidade de servio para a infrestrutura de rede. 1.5.1 Arquiteturas de Qualidade de Servio
A Internet foi criada para ser uma rede militar onde interoperabilidade e confiabilidade eram os principais problemas a serem resolvidos [47]. A rede deveria ser capaz de recuperar-se rapidamente de problemas (como um roteador desligado/quebrado ou parte da rede inoperante devido a um ataque nuclear), mas no foi criada para lidar com altas taxas de congestionamento nem garantias de servio. Com o crescimento da Internet como uma rede comercial mundial, diversos esforos foram feitos para resolver questes como contabilidade e previsibilidade do servio. Algumas arquiteturas foram propostas para lidar com qualidade de servio (QoS). Um servio na Internet pode ser definido de acordo com o nvel requerido de algumas mtricas para obter o funcionamento desejvel. As mtricas mais comumente usadas so as seguintes: Atraso o tempo que um pacote leva para ir da origem ao destino. Pode ser definido como atraso mximo, atraso mdio ou ainda como atraso mximo para uma determinada porcentagem dos pacotes. Jitter a variao no atraso. Alguns servios (especialmente aqueles de streamimg de mdia, e.g., rdio na Internet) no so significativamente afetado pelo atraso, mas sofrem bastante perda de qualidade com a variao desde atraso. Taxa a taxa (erroneamente chamada de largura de banda) requerida pelo servio. Pode ser definida pelo mnimo necessrio, pelo mximo que ser usado (taxa de pico) e/ou pela mdia. Algumas categorias comumente usadas para definir a taxa derivam das classes de QoS das redes ATM [48]: taxa fixa de bits (Constant Bit Rate - CBR), taxa varivel de bits (Variable Bit Rate - VBR), taxa disponvel de bits (Available Bit Rate - ABR) e taxa desconhecida de bits (Unspecified Bit Rate - UBR). Perda a taxa de perda que aceitvel para o servio, normalmente calculada como uma porcentagem dos pacotes com erro/perdidos no caminho (Path Error Rate - PER).
34
Essas so as mtricas mais relevantes usadas para qualidade de servio, mas muitas propostas usam apenas um subconjunto delas e algumas no as usam explicitamente, fazendo apenas uma garantia genrica. O grupo de trabalho IP Performance Metrics (IPPM) da IETF9 discutiu e documentou essas e outras mtricas e como elas podem ser medidas [48][49][50]. O servio padro oferecido pela Internet sem suporte a QoS conhecido como Melhor Esforo (Best-Effort BE). Este servio no traz nenhuma garantia baseada em qualquer mtrica; somente a garantia implcita de que os roteadores faro todo o possvel para entregar os pacotes. Assim, todos os pacotes recebem o mesmo tratamento, e pacotes transportando qualquer tipo de informao, de qualquer conexo, pode ser descartado devido a congestionamento ou falha na camada fsica. 1.5.1.1. Servios Integrados Como a primeira proposta feita pelo Grupo de Trabalho de Rede (Network Working Group) da IETF, a arquitetura de Servios Integrados (IntServ) [51] foi criada para ser bastante eficaz para prover QoS para fluxos individualmente, fazendo a reserva de recursos de rede em cada roteador no caminho daquele fluxo. A idia por trs do IntServ que no possvel dar garantias de QoS sem fazer uma reserva de recursos explcita. Alm de oferecer o servio BE (melhor esforo), a arquitetura IntServ tambm oferece dois outros tipos de servio: Servio de QoS Garantido [52] prov garantias firmes de taxa e atraso de uma conexo, desde que a conexo respeite o perfil de trfego solicitado. Uma conexo desse tipo s pode ser aceita aps a verificao de que a rede capaz de implementar o servio (controle de admisso). Este comportamento comparvel ao servio de linha dedicada, e cada conexo requer gerenciamento de informao de estado em cada roteador. Portanto, foi considerado impossvel escalar a arquitetura IntServ para implantao em toda a Internet, onde alguns roteadores servem milhes de conexes simultaneamente, tornando o processamento de tantas informaes de estado algo muito caro, se no impossvel. Servio de Carga Controlada [53] no prov garantias firmes, os pacotes so tratados como se em uma rede de melhor esforo com baixa carga. A maioria dos pacotes ser entregue com sucesso e no sofrer atraso maior que o mnimo possvel, desde que o trfego submetido pela conexo esteja de acordo com o perfil acordado. Este servio foi criado para suportar muitas aplicaes na Internet que no precisam de garantias firmes, mas que no funcionam em uma rede altamente congestionada. Assim como no servio de QoS garantido, cada conexo precisa usar informao de estado nos roteadores ao longo do caminho. Protocolo de Sinalizao um protocolo usado para fazer a reserva de recursos no caminho desejado. Intserv foi projetado para trabalhar em
O IntServ um arcabouo de implementao com quatro componentes:
http://www.ietf.org
35
conjunto com qualquer protocolo de reserva, mas todos os experimentos realizados utilizaram o Resource Reservation Protocol (RSVP) [54] para a reserva de recursos. Como foi criado para ser usado com a arquitetura de Servios Integrados, a literatura freqentemente se refere arquitetura IntServ/RSVP. Rotina de Controle de Admisso responsvel pela verificao de recursos suficientes para garantir um servio requisitado e deve ser utilizada somente durante o estabelecimento da conexo ou durante sua reconfigurao. Classificador de Pacotes classifica cada pacote que passa por um roteador para decidir que servio o pacote deve receber. Agendador de Pacotes um algoritmo usado para garantir que pacotes recebam corretamente a QoS requisitada, agendando-os corretamente.
O RSVP foi criado para o IntServ e o nico protocolo de reserva de recursos especificado para isso. RSVP um protocolo soft-state guiado pelo receptor, i.e., as reservas so feitas pelo receptor e so vlidas for um tempo limitado, sendo continuamente refeitas at o final da conexo.
Sender Data traffic Receiver
PATH PATH PATH PATH PATH PATH PATH
PATH
RESV
RESV
RESV RESV RESV RESV RESV RESV
Figura 14. Troca de mensagens para reserva de caminho A troca de mensagem feita como mostrado na Figura 14 [55]. Aps o receptor requisitar uma transmisso do emissor, o emissor manda de volta uma mensagem PATH, que ir descrever o perfil de trfego necessrio e gravar informao de roteamento reverso em cada roteador ao longo do caminho (escolhido pelo protocolo de roteamento em uso, independente do IntServ e do RSVP) at o receptor. Quando da recepo da mensagem, o receptor manda de volta uma mensagem RESV, que ir transitar pelo caminho reverso (e no pelo caminho escolhido pelo protocolo de roteamento), reservando recursos da conexo. A mensagem RESV enviada roteador por roteador, de forma a seguir o caminho inverso e fazer as reservas corretas. Considerando que a reserva soft-state e portanto deve ser requerida novamente de tempos em tempos, a reserva deve ser feita com uma freqncia tal que a perda de uma mensagem no ir permitir, erroneamente, a remoo da conexo [51].
36
1.5.1.2. Servios Diferenciados A arquitetura de Servios Diferenciados (DiffServ) [56] foi proposta pelo Grupo de Trabalho de Rede quatro anos aps o IntServ com o objetivo principal de resolver os problemas de escalabilidade do mesmo. Aqui, roteadores no guardam estado de conexes nem trocam informaes de sinalizao. Assim, os requisitos de memria e processamento dos roteadores e de carga de controle da rede so muito menores e mais fceis de se lidar. A idia principal do DiffServ que os servios podem ser definidos em classes, e todas as aplicaes que requerem um determinado servio sero tratadas da mesma forma. Os pacotes so marcados utilizando um campo que no era utilizado no cabealhos IP (o campo Type of Service TOS [57] agora chamado de DiffServ Code Point DSCP [58]), o que no ir alterar o cabealho do protocolo nem afetar sistemas legados que ignoram o campo. O tratamento dado aos pacotes chamado Per Hop Behavior (PHB). Alm do uso do PHB de melhor esforo (PHB BE), o DiffServ tem duas definies oficiais de PHB: O grupo de PHBs de Encaminhamento Assegurado (Assured Forwarding AF) [59] foi definido para tratar diferentes tipos de trfego com garantias relativas entre si. So quatro classes AF, cada uma com trs precedncias (total de 12 combinaes). Foi desenvolvido para o uso de um mesmo servio dentro de uma classe, onde os pacotes mais importantes tm uma prioridade maior sobre os pacotes menos importantes e so diferenciados pela marcao. As classes no tm ordem precedncia entre si. O PHB de Encaminhamento Expresso (Expedited Forwarding EF) [60] garante que pacotes nesta classe no sero descartados e que o seu atraso e jitter sero muito prximos ao mnimo possvel, caso o trfego submetido esteja de acordo com o perfil configurado. Deve funcionar como uma linha dedicada.
O PHB de melhor esforo, embora no oficialmente especificado, representa o servio j em funcionamento na Internet e s vezes chamado de PHB padro. No DiffServ, nenhuma garantia feita para o PHB BE, exceto a garantia de que os roteadores faro todo o possvel para entregar os pacotes corretamente e que todas as conexes deste tipo sero tratadas igualmente, sem diferenciao. A arquitetura DiffServ tem os seguintes elementos: O Domnio DiffServ uma rede com o DiffServ habilitado. O Roteador de Ncleo (Core Router CR) um roteador com DiffServ configurado e que pode tratar os pacotes de acordo com PHBs seguindo a marcao DSCP deles. O Roteador de Borda (Edge Router ER) tem as mesmas funcionalidades do CR, alm de classificao, marcao, reforamento de poltica e moldagem de trfego (shaping). Um ER deve ser usado na
37
borda de um Domnio DiffServ para a troca de trfego com outras redes (sejam DiffServ ou no). O Corretor de Banda (Bandwidth Broker BB mais uma vez o termo banda utilizado incorretamente) faz contratos de servio com usurios finais e com BBs de outros Domnios DiffServ para requerer servio. No obrigatrio para um Domnio DiffServ e no foi totalmente especificado. No h protocolo padro para a comunicao dos BBs, apenas uma sugesto que limita o uso de DiffServ a alguns poucos servios [61].
Um Contrato de Nvel de Servio (Service Level Agreement SLA) um contrato feito entre duas redes com donos diferentes. Pode ser um contrato fsico (documento em papel) ou virtual (documento assinado digitalmente usando um BB). Um SLA deve definir garantias de servio, mtodo de cobrana, contingncias e penalidades (em caso de quebra de contrato por uma das partes). 1.5.1.3. Multiprotocol Label Switching (MPLS) Embora no seja uma arquitetura de QoS, o Multiprotocol Label Switching (MPLS) pode ser usado para trazer algum nvel de QoS para a rede com a comutao de rtulos. O MPLS um esquema de encaminhamento de pacotes que quebra e melhora a estratgia de encaminhamento n-a-n usada na Internet, criando uma separao clara entre roteamento e encaminhamento. Ele trabalha entre a camada dependente do meio fsico (ou camada de enlace, no modelo de referncia OSI [41]), acrescentando um cabealho aos pacotes e atribuindo um rtulo neste cabealho para permitir o encaminhamento.
MPLS domain
Change label
Add label
Remove label
FTN mapping FEC

NHLFE NHLFE NHLFE
ILM mapping label

NHLFE NHLFE NHLFE
Figura 15. Encaminhamento de pacotes e troca de rtulos em MPLS O MPLS usa Label Switched Paths (LSP), o que resulta num maior controle de para onde os pacotes esto sendo encaminhados. Os roteadores MPLS so chamados de Label Switched Routers (LSR). O LSR mantm alguma informao de estado sobre os caminhos, mas nenhuma informao sobre as conexes passantes, o que torna o protocolo bem mais escalvel que o IntServ. Os rtulos so definidos por enlace e
38
podem ser agrupados em classes de equivalncia (Forwarding Equivalence Classes FECs). Assim, as tabelas de encaminhamento no crescem muito. Novos rtulos podem ser definidos aps uma requisio de engenharia de trfego ou de mudanas de roteamento e tambm podem ser definidos sob demanda devido a um novo caminho solicitado por uma nova conexo. As tabelas de encaminhamento consistem de entradas de prximo n (Next-Hop Label Forwarding Entries NHLFEs). Estas mapeiam rtulos de entrada em interfaces de sada e novos rtulos; e so chamadas de Incoming Label Mapping (ILM). Domnios MPLS interagem com domnios no-MPLS atravs do uso de mapas FEC-to-NHLFE (FTN) para rotular pacotes ainda no rotulados e para remover os rtulos desnecessrios nos LSRs de borda (veja a Figura 15). 1.5.2 Uso de QoS para Redes VoIP e Redes Hbridas
O servio de VoIP foi pensado para auxiliar na convergncia de redes. Dessa forma, imagina-se que o natural seja que com o tempo os servios de voz iro passar de redes de comutao de circuito para redes IP, compartilhando a infra-estrutura com outros servios (inclusive de acesso Internet). Tal rede convergente tem duas abordagens para uma implementao adequada: ou utiliza alguma estratgia de QoS, de forma a garantir que o trfego prioritrio receber o devido tratamento, ou utiliza a estratgia de superprovisionamento, garantindo assim que no haver congestionamento capaz de deixar um trfego noprioritrio influenciar na qualidade de um trfego prioritrio. No se v, entretanto, nenhuma rede adotando uma arquitetura de QoS. O software Netmeeting da Microsoft (que acompanha as verses mais recentes do Windows), utiliza o RSVP para mensagens de reserva de servio. Essas mensagens, entretanto, so ignoradas pela maioria dos roteadores em uso atualmente. Algumas aplicaes de usurio utilizam a marcao de pacotes requerida para o DiffServ, mas tambm os roteadores no esto configurados para trat-las. Por fim, o MPLS bastante usado em backbones, mas somente para auxiliar a engenharia de trfego, sem diferenciao entre as aplicaes. A rede FastWeb10, na Itlia, j utiliza comercialmente, desde outubro de 2000 [62] uma infra-estrutura nica para oferecer servios de acesso Internet (por ADSL e por FTTH), VoIP e VoD (IPTV). Esta rede utiliza a estratgia de superprovisionamento. Um estudo foi realizado para verificar a qualidade das conexes de voz da rede FastWeb, e o resultado foi satisfatrio [62]. Entretanto, a rede tem caractersticas bastante limitadas, este estudo no significa que o problema de utilizar VoIP em redes convergentes j est resolvido. Em primeiro lugar, porque a rede s tem alcance nacional na Itlia, e portanto no tem enlaces muito distantes (o que poderia acarretar num maior atraso). Em segundo, porque o trfego de VoIP no passa para outras redes, toda comunicao destinada a telefones fora da rede atravessam gateways que convertem o sinal para comutao de circuito (telefonia tradicional) e assim permanecem at o destino.
10
http://www.fastweb.it
39
1.6 Medio e Monitoramento

As mtricas utilizadas para avaliar a qualidade da voz na telefonia convencional j se encontram consolidadas e so especificadas na recomendao G.712 [18], baseada na relao sinal-rudo. Entretanto, o novo cenrio onde VoIP est inserido traz a necessidade de se adotarem novas metodologias e mtricas para se avaliar a qualidade da voz, uma vez que numa rede de pacotes h outros parmetros que influenciam o desempenho das aplicaes em tempo real, tais como: atraso, jitter, eco, perda de pacotes e codecs diferentes. Esta subseo apresenta, em primeiro lugar, mtodos para inferir qualidade de voz. Por fim, so discutidas tcnicas e ferramentas para monitorar e contabilizar chamadas. 1.6.1 Medindo Qualidade de Voz
Uma forma de avaliao da qualidade da conversao o MOS (Mean Opinion Score). Esta uma avaliao subjetiva, resultante da opinio de usurios de um sistema de conversao em um ambiente controlado. Nos ltimos anos, fizeram-se esforos com a finalidade de desenvolver modelos que quantifiquem a qualidade da voz percebida pelo ser humano utilizando recursos computacionais. Essa uma avaliao objetiva, cuja implementao mais rpida, barata e simplificada, quando comparada metodologia subjetiva, que ser detalhada no texto que segue. 1.6.1.1. MOS (P.800) Uma das primeiras abordagens para avaliao da qualidade da voz foi a utilizao do MOS (Mean Opinion Score), mtodo subjetivo definido nas Recomendaes ITU-T P.800 [19] e ITU-T P.830 [20], pelo qual um conjunto de avaliadores ouvintes atribuem uma pontuao de 1 (pobre) a 5 (excelente) qualidade da fala reproduzida pelo sistema de comunicao em teste. A P.800 contm sugestes para conduo de testes subjetivos de qualidade de transmisso da voz em laboratrio. Os mtodos indicados tm aplicaes genricas, qualquer que sejam os fatores presentes de degradao. Exemplos desses fatores so: perda, rudo de circuito, erros de transmisso, rudo de ambiente, eco, distoro no linear, tempo de propagao. Combinaes de dois ou mais desses fatores tambm so considerados. H trs mtodos descritos na recomendao P.800 para obteno do MOS: testes de opinio por conversao, testes de opinio por escuta e testes por entrevistas e inspeo. Os testes de conversao pretendem, na medida do possvel, reproduzir as condies dos atuais servios de telefonia, experimentados pelos usurios. importante
40
que as condies simuladas nos testes sejam corretamente especificadas, configuradas e medidas de forma acurada, antes e depois de cada experimento. Facilidades de discagem e toque da campainha do telefone devem ser providenciadas, alm de registros de sada fidedignos, para cada teste. Para execuo desse tipo de teste, duas pessoas so colocadas em cabines distintas a prova de som, prximas do ponto onde o experimento controlado. O volume do local no deve ser menor que 20 m3, com um tempo de reverberao11 menor que 500 ms (normalmente na faixa de 200-300 ms), para os casos de uso de sistemas do tipo aparelho telefnico. Para sistemas handsfree, a sala no deve ser menor que 30 m3. As cabines devem ser decoradas recriando um ambiente natural. Os participantes desse tipo de teste devem ser pessoas usurias de telefone, escolhidas ao acaso. No podem estar envolvidas com atividades de medida de desempenho de sistemas telefnicos, ou trabalharem com assuntos relacionados codificao de voz. Alm disso, essas pessoas no podem ter participado de testes subjetivos h pelo menos seis meses, e em testes de conversao h pelo menos um ano. Os participantes pontuam a experincia seguindo os valores: Excelente = 5; Bom = 4; Regular = 3; Pobre = 2 e Ruim = 1. A mdia aritmtica dos valores atribudos denominada pontuao de opinio de conversao, e representada pela simbologia MOS. Os testes de opinio por escuta tm uso direto na qualificao de sistemas de transmisso que sejam essencialmente unidirecionais. Os resultados obtidos por esse tipo de teste podem ser usados, com alguma reserva, na qualificao de conversaes sobre sistemas bidirecionais, como a rede pblica telefnica. Nesses testes de opinio por escuta no esperado obter o mesmo padro de realismo como o alcanado nos testes de conversao. O mtodo de teste mais recomendado para opinio em escuta o ACR (Absolute Category Rating), sendo bastante estvel e com aplicao em conexes telefnicas analgicas e digitais. Outros mtodos como DCR (Degradation Category Rating), Quantal-Response Detectability Method, CCR (Comparison Category Rating) e Threshold Method, tambm so usados. No mtodo ACR so descritos os diversos procedimentos para gravao e escuta que devem ser seguidos. A fim de eliminar variaes indesejveis na fonte da fala, as amostras devem ser obtidas respeitando-se os seguintes critrios: ambiente de gravao, sistema de envio, sistema de gravao, fala (sentenas curtas e simples) e o procedimento de gravao. A reproduo das escuta tambm segue alguns critrios: ambiente de escuta, sistema de escuta, ouvintes, escala de opinio utilizada. No mtodo de testes por entrevistas e inspeo a qualidade de transmisso pode ser determinada por observao de servio, quando o grande esforo imputado a este tipo de teste vivel, em face de importncia do caso considerado. Recomendaes de como proceder, incluindo os tipos de perguntas aos usurios, so indicadas na Recomendao P.82. Para obter um alto grau de preciso so necessrias o mnimo de 100 entrevistas. A desvantagem desse mtodo o pequeno controle que possvel ter,
O tempo de reverberao indica a demora verificada entre a emisso de um determinado som e esse som tornar-se inaudvel
11
41
por vrios aspectos, sobre detalhes das caractersticas das conexes telefnicas testadas. Entretanto, consegue-se ter uma apreciao global sobre o desempenho do sistema num ambiente real. 1.6.1.2. Modelo-E Embora o resultado obtido pelo MOS seja bastante significativo, a dificuldade de realizar tal avaliao em larga escala motivou o desenvolvimento de tcnicas objetivas para o clculo do MOS. Um dos mtodos objetivos o Modelo-E [63][64], desenvolvido pela ITU em 1998. O Modelo-E implementa um mecanismo baseado na soma de termos que representam distores na qualidade da voz, tais como atrasos de transmisso, eco e distores introduzidas pelos equipamentos utilizados. O resultado do modelo o fator escalar R, variando de 0(pssimo) a 100(excelente). O fator R pode ser convertido para escala de pontuao MOS atravs das seguintes expresses: Para R < 0: MOS = 1 Para 0 R 100: MOS = 1+ 0,035 R + 7.10-6 R (R-60) (100-R) Para R > 100: MOS = 4,5 Normalmente, o fator R descrito em categorias de valores, tal como pode ser consultado no Tabela 1. Sistemas cuja qualidade da fala seja avaliada em R 60 no so recomendveis, sendo desejvel obter R > 70. TABELA 1. Converso entre o Fator R e o MOS Fator R 90 R < 100 80 R < 90 70 R < 80 60 R < 70 0 R < 60 MOS 4,34 4,50 4,03 4,34 3,60 4,03 3,10 3,60 1,00 3,10 Satisfao do usurio Muito satisfeitos Satisfeitos Alguns insatisfeitos Muitos insatisfeitos Quase todos insatisfeitos
1.6.1.3. PESQ (P.862) Conforme discutido, para se obter o fator R, do Modelo-E, necessrio a coleta de diversas informaes tcnicas relacionadas chamada, como por exemplo, detalhes do codec e condies de rede. Uma vez que em diversas situaes, esse detalhes no so conhecidos, existe a necessidade de se calcular a qualidade de voz com base na comparao entre o udio falado ou transmitido e o escutado ou recebido. No mesmo ano do Modelo-E, a ITU props o Perceptual Speech Quality Measurement (PSQM) [65], que estima o MOS de uma comunicao com base na
42
comparao entre o udio original (transmitido) e o degradado (recebido). Em paralelo, a British Telecom desenvolveu o Perceptual Analysis Measurement System (PAMS) [66], com os mesmos objetivos. Posteriormente, a ITU desenvolveu o Perceptual Evaluation of Speech Quality (PESQ) [67], combinando caractersticas do PSQM e do PAMS e melhorando os algoritmos de forma a atender uma gama maior de cenrios (como cenrios com ocorrncia de jitter). A medida de qualidade objetiva do PESQ obtida apenas em testes de escuta ACR. Este mtodo apresenta preciso aceitvel em seus resultados, quando a clareza da voz afetada pelos seguintes processos ou parmetros: Codecs de forma de onda (exemplos: G.711, G.726 e G.727); Codecs paramtricos e hbridos (a partir de 4 kbps) incluindo aqueles de mltiplas taxas de transmisso (exemplos: G.728, G.729 e G.723.1); Transcodificaes (converso de um formato digital para outro); Nvel do sinal de entrada no codec; Erros no canal de transmisso; Efeitos da variao do atraso em testes apenas de escuta; Perda de pacotes/clulas com codecs paramtricos e hbridos Rudo ambiente no lado transmissor; Taxa de transmisso nos casos de codecs com mais de um modo de operao; Deformaes temporais do sinal de udio.
No PESQ no se pretende mensurar o impacto ou no existe preciso nas medidas afetadas pelos seguintes processos ou parmetros: atraso (cancelado pelo alinhamento de tempo), nveis de escuta e ganho/atenuao total no sistema ( cancelado pelo alinhamento de nvel), eco percebido pelo orador e o som da prpria voz do orador ouvido por retorno no fone. Por outro lado, no se conhece o impacto dos itens abaixo, nos resultados medidos pelo PESQ: perda de pacotes/clulas com codecs de forma de onda, cortes (clipping) temporal e de nvel, dependncia de orador, mltiplos oradores simultneos, diferena entre as taxas de transmisso do codificador e do decodificador, msica como sinal de entrada, eco percebido pelo ouvinte e codecs paramtricos ou hbridos com taxa inferior a 4 kbps. 1.6.2 Medindo jitter e perdas de pacotes
As definies utilizadas de jitter e perda de pacotes esto conforme as elaboradas pelo IP Performance Metrics Working Group (IPPM)12 e so apresentadas na RFC 3393 [68] e RFC 2680 [69], respectivamente. O IPPM um grupo de trabalho da IETF que produz documentos que definem mtricas especficas, assim como procedimentos para medilas. Resumidamente, a perda de pacotes calculada como uma taxa de pacotes perdidos entre os pacotes enviados e o jitter calculado como sendo a variao (mdia e mxima) no atraso dos pacotes.
12
http://www.ietf.org/html.charters/ippm-charter.html
43
Para o clculo de mtricas em funo do tempo necessrio verificar a qualidade dos mecanismos de operao do relgio nas mquinas usadas para capturar o trfego. Cada relgio possui um erro intrnseco, que como o comportamento do relgio difere de um relgio de referncia (ideal). Esse erro pode ser em fase (e.g., um determinado relgio est 2,54s atrasado em relao a um relgio de referncia, em um dado instante) ou em freqncia (e.g., a cada dia um determinado relgio atrasa 4.50s em relao a um relgio de referncia) [70]. Em princpio, dado que os atrasos da rede so imprevisveis, supe-se que absolutamente necessrio garantir que os relgios das mquinas que coletam o trfego estejam sincronizados. Entretanto, utilizando o mtodo proposto por Barbosa [71], o clculo do jitter independe da sincronizao de relgios. 1.6.3 Monitoramento e Contabilizao
Assim como ocorre com telefonia tradicional, a telefonia VoIP tambm necessita de mecanismos de monitoramento das chamadas, seja para avaliao da qualidade da aplicao VoIP ou para contabilizao de uso dos servios. Nesse contexto, temos a utilizao do protocolo Radius (Remote Authentication Dial-In User Service) [72], o qual um padro do IETF para autenticao de usurios em um servio de acesso discado, e para a contabilizao dos recursos consumidos durante as conexes. Ao surgir a necessidade de se contabilizar as chamadas VoIP, o Radius passou a ser utilizado por alguns fabricantes para este fim. Em alguns equipamentos essas informaes so disponibilizadas tambm em MIBs (Management Information Base), as quais podem ser coletadas atravs do protocolo SNMP (Simple Network Management Protocol). Outra opo a transmisso direta para um banco de dados SQL. A CESNET13 , rede de ensino e pesquisa da Repblica Tcheca, implementou uma infra-estrutura de monitorao e contabilizao de chamadas VoIP por meio de utilizao de servidores RADIUS [73], e coleta de CDRs (call detail record) emitidos por gateways de voz . Um CDR um arquivo contendo informaes sobre uma chamada, tais como: origem, destino, durao de cada chamada, total de tempo taxado, entre outras. O formato do CDR varia de acordo com o tipo da chamada e os equipamentos envolvidos. Alguns programas permitem que o CDR seja configurado pelo usurio. Em [74], apresentada uma arquitetura denominada Enterprise Call Analysis System (ECAS), tambm baseada na coleta e anlise de CDRs gerados por gateways de voz. AS duas solues apresentadas no permitem a monitorao da qualidade das chamadas realizadas entre telefones IP. Em [75], assim como em diversos produtos comerciais [76][77][78], foi adotada uma soluo de monitoramento passivo, conforme descrito no item 1.5.2. Os resultados dessas anlises so apresentados na forma de relatrios com o nvel de qualidade atingida pelo sistema. Esta soluo nem sempre aplicvel, seja pelo uso de criptografia
13
http://www.ces.net/
44
que impede a anlise das chamadas, ou pela natureza de trfego de voz, que pode ser ponto-a-ponto (peer-to-peer), dificultando assim a captura das chamadas.
1.7 Estudos de Caso

O Grupo de Pesquisa em Redes e Telecomunicaes14 (GPRT) do Centro de Informtica15 (CIn) da Universidade Federal de Pernambuco j realizou diversas atividades prticas com algumas tecnologias de VoIP. Nesta seo descreveremos as mais importantes. 1.7.1 Implementao de Protocolos H.323 e SIP
O GPRT, em parceria com uma empresa brasileira fabricante de equipamentos de telefonia, fez a implementao do protocolo H.323 para uso em PCs e do protocolo SIP para uso em um mdulo de uma central telefnica, tornando-a capaz de fazer ligaes de VoIP. Estas implementaes trouxeram um grande conhecimento sobre os protocolos e permitiram ententer diversos aspectos de interoperabilidade entre equipamentos de fabricantes diferentes. 1.7.1.1. H.323 No caso da implementao de H.323, as diferentes verses do protocolo trazem algumas incompatibilidades, de forma que nem todas so compatveis entre si. Posto isto, um software que pretende ser compatvel com os mais diversos equipamentos que implementam o protocolo H.323 precisa implementar diversas verses de algumas partes do mesmo protocolo. Isto aumenta bastante a complexidade do protocolo, o custo e o tempo de desenvolvimento. interessante observar que diversos equipamentos implementam somente um subconjunto do protocolo, o que dificulta a interoperabilidade. Utilizando verses de protocolo e informaes sobre que partes esto implementadas, possvel inferir a compatibilidade entre equipamentos. Mas como essa informao no disponibilizada pelos fabricantes, na prtica, s h como garantir a interoperabilidade de um equipamento com outros com testes reais. O H.323 totalmente baseado em mensagens ASN.1, o que torna o seu uso bastante complexo. A forma de se lidar com o ASN.1 criando um compilador (em tempo de execuo) de ASN.1 ou criando um cdigo que acessa diretamente os bits das mensagens para interpretar seus campos. Embora isso torne o cdigo mais eficiente, tambm torna-o avesso a atualizao do protocolo. Ao implementar o H.323 fundamental implementar o H.225 (a parte de sinalizao de chamada e, se necessrio, comunicar-se com um Gatekeeper, a parte RAS), o H.245 (para sinalizao de controle) e parte do Q.931 (originalmente criado para redes ISDN). Alm, obviamente, dos protocolos RTP/RTCP e de mtodos para lidar com problemas de rede (e.g., jitter , buffer, interpretao do RTCP)
14 15
http://www.gprt.ufpe.br http://www.cin.ufpe.br
45
A biblioteca de cdigo aberto OpenH32316, criada pela comunidade internacional, implementa diversas verses do protocolo H.323, com o objetivo de ser o mais completa possvel. Sua implementao, que inclui um compilador de ASN.1 embutido na biblioteca PWlib, feita com diversas metodologias de software que tornam o produto bastante complexo e gastador de memria e processamento. Dessa forma, esta biblioteca no usada para sistemas embarcados (telefone IP, placa de telefonia, etc), somente para PCs. Uma outra biblioteca de cdigo aberto, a OOH323c17, implementa o compilador ASN.1 e uma pequena mquina de estados de H.323. Uma verso inicial desta biblioteca mais eficiente para uso em sistemas embarcados, mas as verses posteriores foram criadas j de forma menos eficiente, aumentando o consumo de memria e processamento, mudando o foco para tambm ser mais completa. A verso inicial, por sua vez, no implementa diversas partes importantes (mas opcionais para uma ligao VoIP simples) do protocolo. 1.7.2 Asterisk
O Asterisk um Software Livre, portanto de cdigo aberto, que implementa em software os recursos encontrados em um PABX convencional, utilizando tecnologia de VoIP. Inicialmente desenvolvido pela empresa Digium, hoje recebe contribuies de programadores ao redor de todo o mundo. O Asterisk utiliza protocolos como SIP, MGCP, IAX e H.323 para realizar a sinalizao das chamadas telefnicas na rede IP. possvel utilizar o Asterisk como Media Gateway, entre a rede de telefonia pblica e a rede IP (com auxlio de hardware especial), como Unidade de Resposta Audvel (URA) ou Media Server, tocando mensagens pr-programadas ou com interatividade via DTMF, como msica de espera ou sistema de auto-atendimento. Pode ser utilizado tambm como Correio de Voz ou PABX IP, realizando encaminhamento de chamadas. Este PBX faz uso do conceito de Canais, que o equivalente a uma linha telefnica na forma de um circuito de voz digital, possibilitando o uso de vrias combinaes de codecs e protocolos de comunicao. Entre os canais que o Asterisk suporta podemos encontrar os seguintes [79]: Agent: Um canal de agente Distribuio Automtica de Chamadas. Console: Cliente de console do Linux, driver para placas de som (OSS ou ALSA). H323: Um dos protocolos mais antigos de VoIP, usado em muitas implementaes. IAX e IAX2: Inter-Asterisk Exchange Protocol, o prprio protocolo do Asterisk. MGCP: Media Gateway Control Protocol, outro protocolo de VOIP. Modem: Usado para linhas ISDN.
16 17
http://www.openh323.org http://www.obj-sys.com/open/index.shtml
46
NBS: Usado para broadcast de som. Phone: Canal de telefonia do Linux. SIP: Session Initiation Protocol, o protocolo de VoIP mais comum. Skinny: Um driver para o protocolo dos telefones IP da Cisco. VOFR: voz sobre frame-relay da Adtran. VPB: Linhas telefnicas para placas da Voicetronix. ZAP: Para conectar telefones e linhas com placas da Digium. Tambm usado para TDMoE (TDM sobre Ethernet) e para o Asterisk zphfc (ISDN em modo NT). Unicall: Usado para linhas digitais com sinalizao E1/R2.
A licena utilizada pelo Asterisk dupla, sendo a primeira a GNU General Public License (GPL), para a parte do software gratuito, e a segunda a licena de softwares proprietrios, de forma a permitir o uso de cdigo fechado e patenteado, como o codec G.729, em conjunto com o sistema. Originalmente desenvolvido para executar sobre o Linux, o Asterisk atualmente suporta vrios outros sistemas operacionais, como OpenBSD, FreeBSD, Mac OS e Solaris, alm de hoje ser possvel execut-lo em Windows.
Figura 16. Arquitetura do Asterisk [79]. Algumas funcionalidades disponveis no Asterisk esto disponveis apenas em PBXs proprietrios bastante caros, alm de ser possvel a criao de novas funcionalidades escrevendo scripts de planos de discagem na linguagem do Asterisk ou scripts da Asterisk Gateway Interface escritos em outras linguagens como Perl. Tambm possvel adicionar mdulos escritos em linguagem C para vrias das APIs disponveis, como pode ser visto na Figura 16, que descreve a arquitetura do Asterisk.
47
Para acoplar telefones comuns ou conectar linhas telefnicas da rede pblica (e troncos) a um servidor Asterisk, necessrio o uso de hardware adicional. A Digium e outras empresas especializadas fabricam placas no padro PCI que podem ser usadas para conectar linhas E1, T1 ou servios telefnicos digitais e analgicos. Capaz de operar com a maioria dos telefones SIP, atuando como servidor de registro ou gateway, o Asterisk tambm suporta uma vasta gama de protocolos de Voz sobre IP, e tem se tornado referncia da indstria de telefonia VoIP para testes de interoperabilidade. Os desenvolvedores do Asterisk tambm desenvolveram um novo protocolo, denominado IAX (Inter-Asterisk eXchange) para aumentar a eficincia do roteamento de chamadas em PBXs Asterisk. Com esta mescla de suporte a servios de telefonia tradicional e VoIP, o Asterisk permite que provedores de solues telefnicas migrem de PBXs proprietrios, alm de facilitar a adio de servios e possibilitar reduo de custos, principalmente para chamadas de longa distncia. 1.7.3 SER
O SER (SIP Express Router) um servidor freeware, desenvolvido pelo instituto nacional de pesquisa alemo Fraunhofer Fokus18 . Suas principais caractersticas so a implementao do protocolo SIP (Session Initiation Protocol), a alta performance, ser configurvel e rodar nos sistemas Linux, BSD e Solaris. Alm disso, anuncia a presena de usurios, envia e recebe mensagens e mantm qualquer tipo de sesso, incluindo jogos e chat. Inclui tambm suporte para atuar como servidor de registro, proxy e redirecionamento. O SER foi desenhado para implementar infra-estruturas de telefonia IP em larga escala, assegurando uma flexibilidade que lhe permite atuar de forma distinta a satisfazer implementaes de servios variados. Por exemplo, pode atuar como registro de utilizadores e servidor de localizao para prover mobilidade aos usurios. Pode tambm ser utilizado como elemento de controle de acesso, o qual armazena informaes sobre gateways PSTN ou outros recursos SIP mais reservados. Pode ser facilmente estendido usando a sua configurao de lnguas e suporte para mdulos plugin embutidos. Tem vrios plug-ins disponveis, entre eles, gateways SMS (Short Message Service), gateways SIMPLE2Jabber, autenticao e contabilizao via RADIUS, LDAP (Lightweight Directory Access Protocol) [80], ENUM [81], entre outros. Possui ainda uma interface de aplicao que permite um fcil acoplamento com outras aplicaes que no funcionam com SIP. 1.7.4 fone@RNP (GT-VoIP RNP)
Em 2003 foi aprovado um projeto piloto da UFRJ para pesquisar a possibilidade de implantao de VoIP na Rede Nacional de Pesquisa (RNP), interligando instituies conectadas RNP. Um dos objetivos do projeto era utilizar parte da capacidade ociosa da rede para permitir s instituies a realizao de chamadas VoIP entre si, de forma a
18
www.fokus.gmd.de/home
48
economizar custos com telefonia. A idia era que as instituies pudesse tambm fazer ligaes para a rede pblica (PSTN) de outros estados atravs da RNP. Para isto, a RNP solicitou uma licena especial da ANATEL que permitisse RNP implementar tal servio. Esta licena, porm, no permitia RNP completar uma ligao originada na PSTN e destinada PSTN de outra cidade, de forma a no concorrer com as operadoras de longa distncia e o uso ser somente acadmico. O projeto foi aprovado e o servio fone@RNP19 est em pleno funcionamento. J conta com diversas instituies conectadas, atingindo (em Maro/2007) 16 das 26 capitais e tambm o distrito federal. O fone@RNP est tambm interligado com instituies em outros pases (e.g.: Austrlia, Estados Unidos, Mxico e Repblica Tcheca), de forma que as instituies podem ligar entre si e algumas instituies permitem que outras completem ligaes para a rede pblica de sua cidade. Neste caso, a instituio responsvel pelos custos da interligao com a rede pblica a instituio que faz a terminao da ligao, no a que inicia a chamada. Embora esse modelo de cobrana parece injusto e completar ligaes para a rede pblica uma opo da instituio, no obrigatrio. Ainda assim, todas as instituies que o adotaram esto satisfeitas com o mesmo, pois a economia de custos com as ligaes de longa distncia realizadas, em todas elas, muito superior ao custo gerado por completar ligaes locais para as outras instituies. O servio baseado em H.323 e cada instituio tem a opo de utilizar infraestrutura SIP (ou qualquer outra) internamente (algumas o fazem). A comunicao entre as instituies utiliza, obrigatoriamente, o H.323. O plano de discagem foi criado para contemplar ligaes em todos os nveis (institucional, local, nacional e internacional). Assim, cada instituio conectada tem um Gatekeeper para fazer a autenticao e a autorizao dos usurios da instituio e a RNP tem um Directory Gatekeeper (DGK), que consiste em um gatekeeper cujos usurios so outros gatekeepers. Os codecs recomendados no fone@RNP so os do protocolo G.711. O G.729 tambm usado em alguns equipamentos, mas seu atraso faz com que a qualidade da ligao seja varivel quando utilizado. 1.7.5 XVoice (GT-P2P RNP)
O XVoice um aplicativo de VoIP, sendo um dos resultados do Grupo de Trabalho GTP2P20 da Rede Nacional de Pesquisa(RNP), sendo projetado para avaliar o trfego de voz na rede da RNP. O objetivo inicial do GT-P2P foi desenvolver uma infra-estrutura P2P, testar aplicativos para essa infra-estrutura e avaliar o impacto dessas aplicaes no trfego da RNP. O resultado do projeto, que foi denominado de X-Peer, sendo o XVoice o aplicativo de VoIP desse projeto.
19 20
http://www.rnp.br/voip http://www.gprt.ufpe.br/gtp2p/. ltimo acesso em 15 de Fevereiro de 2006.
49
O X-Peer [82] pode ser considerado uma rede, quando se observam apenas os ns, uma arquitetura P2P, quando se considera a infra-estrutura e um middleware, quando se considera a infra-estrutura oferecida para o desenvolvimento de aplicaes P2P. Utiliza o conceito de super-ns, os quais se comunicam atravs de uma rede estruturada baseada em DHT (Distributed Hash Table), o que lhe permite acessar as informaes de qualquer outro n X-Peer em no mximo log(n) saltos, onde n o nmero de super-ns que compem a rede X-Peer. Essa garantia de localizao em uma rede distribuda e hierrquica um dos grandes diferenciais dessa soluo. Alm disso, o X-Peer capaz de suportar vrias aplicaes P2P em uma nica infra-estrutura de rede. 1.7.5.1. Caractersticas tcnicas O levantamento de requisitos para desenvolver o XVoice demandou um estudo sobre o Skype e os protocolos e codecs que so utilizados em aplicaes de Voz sobre IP. O XVoice um aplicativo VoIP que usa a tecnologia peer-to-peer pura. Peer-to-peer um modelo de comunicao no qual cada n tem as mesmas capacidades e responsabilidades, e ambos podem iniciar uma sesso de comunicao, contrastando com o modelo cliente/servidor. O XVoice utilizou o SIP como protocolo de sinalizao. O SIP tem como principal vantagem a forma simples e compacta das mensagens, sendo baseado no modelo requisio-resposta, similar ao protocolo HTTP (HyperText Tranfer Protocol). O codec utilizado no XVoice foi o GSM FULL RATE, o qual apresentou melhor desempenho. O GSM foi um codec desenvolvido na Europa para trabalhar com a telefonia celular. Utiliza um modelo de gerao de sons e rudos similares ao sistema de reproduo da voz humana. Possui uma taxa de transmisso de 13 kbps e uma avaliao MOS de 3,8. 1.7.5.2. Arquitetura do XVoice A rede na qual o XVoice funciona a X-Peer, uma rede peer-to-peer pura, a qual utiliza os recursos tecnolgicos da Rede Nacional de Pesquisa (RNP).
Ns Usurios
POPs
Figura 17. Rede XVoice
50
Os componentes dessa rede so os ns usurios e os POPs (Pontos de Presena) da RNP, que funcionam com o conceito de super-ns, conforme mostrado na Figura 17.
1.7.5.3. Conexo ao XVoice Para acessar o servio XVoice o usurio precisa se conectar na rede X-Peer. Para tanto, necessrio executar o aplicativo XVoice.jar, e preencher os campos login, senha, Host Xpeer e porta, conforme mostrado na Figura 18. No campo Host Xpeer pode ser digitado o IP dos Pontos de Presena ou o endereo service.pop-xx.rnp.br, onde xx o Ponto de Presena, podendo ser: pe, mg, pr, sp. Caso o usurio no esteja cadastrado, aps executar o aplicativo XVoice.jar, o mesmo dever preencher seu login e senha, marcando a caixa Registrar, conforme mostrado na Figura 18.
Figura 18. Interface inicial para conexo ao X-Peer
1.7.6
Skype
O Skype21 um aplicao VoIP numa rede P2P hbrida, que permite a comunicao telefnica ilimitada entre dois computadores sem nenhuma taxao. um software free que vem ganhando mercado, principalmente entre usurios que buscam economia em chamadas telefnicas de longa distncia nacionais e internacionais. O nome do produto confunde-se com o nome da empresa, que foi desenvolvido pelos criadores do KaZaa22 em 2003. O sucesso do Skype teve nos usurios domsticos o seu grande pblico. Essa grande massa passou a utilizar a telefonia via Internet em ambientes at ento s utilizados para a comunicao atravs de chats. Segundo Vollenweider [83] 30% dos usurios domsticos usam o Skype em seus ambientes de trabalho. O Skype possui as mesmas funes de outros aplicativos j consagrados (MSN, Yahoo! IM), tais como: troca de mensagens de texto, chamadas de voz e conferncia,
21 22
http://www.skype.com/intl/pt/helloagain.html. ltimo acesso em 15 de Fevereiro de 2007. http://www.kazaa.com/us/index.htm. ltimo acesso em 15 de Fevereiro de 2007.
51
mas chama a ateno pela qualidade dos codificadores de voz utilizados e por trabalhar atravs de NATs e firewalls. Possui, ainda, acesso a rede pblica de telefonia atravs do SkypeOut e SkypeIN, que so funes taxadas. 1.7.6.1. Arquitetura do Skype O Skype adotou uma arquitetura peer-to-peer hbrida, utilizando um servidor central (Servidor de Login) apenas para fazer o login e autenticao dos usurios. Nesse servidor so armazenados apenas os nomes e senhas dos usurios. Aps a autenticao, os clientes trocam informaes diretamente entre os pares, segundo artigo tcnico de Baset [21].
Figura 19. Rede Skype Este aplicativo possui dois tipos de ns: Hosts Ordinrios e Super-Ns, os quais em conjunto com o Servidor de Login, formam a rede do Skype (Figura 19). Outra funo importante do Skype a determinao do tipo de NAT ou firewall que est entre um cliente e a rede Skype. Segundo Baset acredita-se que cada cliente usa uma variao do protocolo STUN [46] para determinao do tipo de NAT ou firewall que est entre o cliente e a rede do Skype. 1.7.6.2. Aspectos de Segurana Na conferncia do Black Hat Europe 2006, Bondi e Desclaux [84] discutiram detalhadamente como o Skype procede para implantar a segurana da sua rede e do cdigo de sua aplicao, a fim de torn-la menos susceptvel engenharia reversa e a ataques. Primeiramente, trechos do cdigo binrio do Skype so cifrados usando operaes xor com uma chave forte e decifrados para memria apenas em tempo de execuo. Alm disso, o Skype interrompe seu processo quando detecta o uso de depuradores. A integridade do seu prprio cdigo verificada periodicamente, logo,
52
caso um breakpoint seja inserido ou qualquer outra modificao seja efetuada no cdigo a aplicao tambm deixa de funcionar. Toda a informao que trafega na rede Skype dissimulada. A sinalizao cifrada, entretanto se sabe que a chave construda a partir de elementos do cabealho do protocolo de transporte. Conseqentemente, pode-se afirmar que a sinalizao somente ofuscada. Entretanto, o fluxo de mdia tambm segue com criptografia, onde apenas o emissor e o receptor tm a chave. O processo de autenticao centralizado e envolve uma autoridade cuja chave pblica acompanha a aplicao desde sua distribuio. 1.7.7 GTalk
O GTalk foi lanado em agosto de 2005 e, apesar de no oferecer tantos recursos como o Skype, uma aplicao VoIP. Atualmente, alm dos codecs da GIPS, o GTalk suporta os seguintes codecs: G.711, G.723 e iLBC. Outra semelhana com o Skype, que, embora tenha um cdigo fonte aberto, o Google tambm possui uma API, chamada de Libjingle. A Libjingle um conjunto de componentes escritos em C++ para que outras aplicaes VoIP possam ser construdas e utilizem a rede do Google. Ao contrrio do Skype, o GTalk adota um protocolo padro Jabber -, de forma que seus usurios no esto presos ao GTalk para se comunicarem. O fundamento do Jabber foi adotado pela IETF como padro sob o nome XMPP (The Extensible Messaging and Presence Protocol) [85][86] e baseado em XML. A rede do GTalk prov interoperabilidade com outras redes VoIP e de mensagens instantneas. Entre elas est o Gizmo Project23 . O servio est hospedado no google.com e pode ser acessado pela porta 5222. O GTalk, em seu stio oficial afirma que no futuro suportar SIP. Para transportar mdia, o protocolo RTP utilizado. Finalmente, no se encontrou em nenhuma referncia registro de uma rede sobreposta do Google. O nico aspecto P2P implementado pelo GTalk a comunicao direta, mesmo atravs de NATs. Os trabalhos de Barbosa et al [87][88] realizam uma comparao entre o Skype e o GTalk sob o aspecto de qualidade de voz.
1.8 Concluses
A entrada no mercado de VoIP das empresas de telefonia por comutao de circuitos s se dar por presso do mercado (clientes) ou por concorrncia (atualmente, quase inexistente) com outras operadoras que ofeream servios de VoIP. Como no h ainda regulamentao para o setor no Brasil, as operadoras no se esforaro para implantar a tecnologia, o que poder acarretar na diminuio de suas margens de lucro. Atualmente, qualquer uso de telefonia que chegue na rede pblica requer licena especfica da Anatel. Ainda assim, muitas empresas esto adotando o VoIP para interligao com suas filiais e mesmo para comunicao com o exterior (usos que no so ilegais). No caso
23
Website do GTalk, http://www.google.com/talk, ltimo acesso em maro de 2007.
53
das ligaes nacionais de longa distncia entre filiais de uma mesma empresa (sem passar pela/para a rede pblica), a economia de custos de empresas mdias e grande bastante significativa e j justifica o investimento. J existem diversos programas livres que podem ser usados para implantar uma infra-estrutura de VoIP: da mais simples, uma ligao entre duas pessoas na Internet, mais complexa, de uma operadora mundial de VoIP. Entretanto, sem qualidade de servio a qualidade da ligao instvel, pode estar muito boa em um momento e muito ruim no momento seguinte. Este ainda o maior impedimento real para a adoo em larga escala de VoIP por todas as empresas: os provedores de Internet no oferecem servios com QoS a seus clientes (embora os roteadores atuais j tenham essa tecnologia implementada). H ainda o problema de segurana de VoIP, pois quando no se usa criptografia (a maioria dos casos) a ligao pode ser interceptada facilmente, sem conhecimento dos participantes da conversa. Isto no , porm, um problema grave por dois motivos: a telefonia tradicional muito mais fcil de ser interceptada que a VoIP e a migrao para um servio com criptografia j algo resolvido tecnologicamente, ento quem precisar de um nvel de segurana maior, poder implement-lo. Uma forte tendncia das tecnologias de VoIP a integrao com outras tecnologias. Imagina-se que em poucas dcadas o modelo padro de telefonia adotado no ser parecido com o modelo atual, de um aparelho para fazer ligaes conectado por fio a um prestador de servio de telefonia, mas de um aparelho multi-funcional que, entre outros recursos, ter o de ligaes telefnicas, onde VoIP ser apenas a tecnologia que torna isso possvel, sem estar aparente para o usurio.
1.9 Referncias
[1] John Q. Walker, Jeffrey T. Hicks, "The Essential Guide to VoIP Implementation and Management", NetIQ Corporation, 2002. [2] Daniel Collins, "Carrier Grade Voice Over IP", McGraw-Hill, 2001. [3] Cisco Systems, "Quality of Service for Voice over IP.", http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/qossol/qosvoip.htm , 2001, ltimo acesso em Fevereiro de 2007. [4] Miras, D. "A survey on network QoS needs of advanced internet applications", Working document, Internet2 QoS Working Group, 2002. [5] Opticom GmbH, "State of the art voice quality testing," White Paper, Erlangen, Alemanha, 2000. [6] Kamienski, C., Mariz, D., Sadok, D. &.Fernandes, S., "Arquiteturas de Rede para a Prxima Gerao da Internet", SBRC 2005, Maio 2005. [7] Illuminating the Shadows, Opportunistic network and web measuremen, http://illuminati.coralcdn.org/stats/, ltimo acesso em Fevereiro de 2007.
54
[8] Shiuh-Pyng Shieh Fu-Shen Ho Yu-Lun Huang Jia-Ning Luo, "Network address translators: effects on security protocols and applications in the TCP/IP stack", IEEE Internet Computing, Vol. 4, No. 6, Novembro/Dezembro de 2000. [9] Andrew S. Tanenbaum, "Computer Networks", 4th Ed, Prentice-Hall, 2003. [10] John Q. Walker, Jeffrey T. Hicks, "The Essential Guide to VoIP Implementation and Management", NetIQ Corporation, 2002. [11] Athina P. Markopoulou, Fouad A. Tobagi, Mansour J. Karam, "Assessment of VoIP Quality over Internet Backbones", IEEE INFOCOM 2002, Junho de 2002. [12] HEATH, S., Multimedia & Communications Technology, Focal Press, 1996. [13] MONTEIRO, Rafael F, Implementao de Transporte Robusto de Voz em Redes Baseadas em Protocolo IP, Setor de Cincias Tecnolgicas, Universidade Federal de Minas Gerais, 2000. [14] SCHINITZLER, Jrgen, Speech Coding, Institut fr Nachrichtengerte und Datenverarbeitung, RWTH Aachen, 2001. [15] International Telecommunication Union. Pulse code modulation (PCM) of voice frequencies. Recommendation G.711, Telecommunication Standardization Sector of ITU, Geneva, Sua, Novembro de 1998. [16] International Telecommunication Union. Coding of speech at 8kbit/s using conjugate structure algebraic-code-excited linear-prediction. Recommendation G.729, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Maro de 1996. [17] International Telecommunication Union. Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3kbit/s. Recommendation G.723.1, Telecommunication Standardization Sector of ITU, Geneva, Sua, Maro de 1996. [18] International Telecommunication Union. "Performance Characteristics of PCM Channels Between 4-Wire Interfaces at Voice Frequencies". Recommendation G.712, Telecommunication Standardization Sector of ITU, Geneva, Sua, 1972. [19] ITU-T Recommendation P.800. Methods for Subjective Determination of Transmission Quality. Geneva, Sua, Agosto de 1996. [20] ITU-T Recommendation P.830. Subjective Performance Assessment of TelephoneBand and Wideband Digital Codecs. Geneve, Fevereiro de 1996. [21] BASET, Salman A. and SCHULZRINNE, Henning, An Analysis of the Peer-toPeer Internet Telephony Protocol, Setembro de 2004. [22] Andersen, S., Duric, A., Astrom, H., Hagem, R., Kleijn, W. and Linden, J. (2004). Internet low bit rate codec (iLBC), Request For Comments 3951, Internet Engineering Task Force, Dezembro de 2004. [23] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, Setembro de 1981. [24] Postel, J., "User Datagram Protocol", STD 6, RFC 768, Agosto de 1980.
55
[25] Schulzrine, H., Casner, S., Frederick, R. and Jacobson, V.,RTP: A Transport Protocol for Real-Time Applications, Request For Comments 1889, Internet Engineering Task Force, Janeiro de 1996. [26] Casner, S. and Jacobson, V., Compressing IP/UDP/RTP Header for Low-Speed Serial Links. Request For Comments 2508, Internet Engineering Task Force, Setembro de 1999. [27] Walker, J. Q. and Hicks, J. T. (2002): The Essential Guide to VoIP Implementation and Management, NeqIQ Corporation. [28] Ramjee, Ramachandran; Kurose, James F.; Towsley, Donald F.; Schulzrinne, Henning; "Adaptive Playout Mechanisms for Packetized Audio Applications in Wide-Area Networks", IEEE INFOCOM '94, pp. 680-688, Junho de 1994. [29] Implementers Guide for Recommendations of the H.323 System (Packet-based multimedia communications systems): H.323, H.225.0, H.245, H.246, H.283, H.235, H.341, H.450 Series, H.460 Series, and H.500 Series, Novembro de 2004. [30] International Telecommunications Union. Packet-based multimedia communications systems, Recommendation H.323, Fevereiro de 1998. [31] International Telecommunications Union. Call Signalling protocols and media stream packetization for packet-based multimedia communication systems, Recommendation H.225, Fevereiro de 1998. [32] International Telecommunications Union. Control Protocol for multimedia communication, Recommendation H.245, Setembro de 1998. [33] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and Schoooler, E, SIP: Session Initiation Protocol, Request For Comments 3261, Internet Engineering Task Force, Junho de 2002. [34] Handley, M. and Jacobson, V., SDP: Session Description Protocol. Request For Comments 2327, Internet Engineering Task Force, Setembro de 1998. [35] Inter-Asterisk eXchange, http://en.wikipedia.org/wiki/Inter-Asterisk_eXchange, ltimo acesso em Maro de 2007. [36] M. Spencer, B. Capouch, E. Guy, F. Miller, K. Shumard, IAX2: Inter-Asterisk eXchange Version 2, Internet-Draft (Work in Progress), Outubro de 2006. [37] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S. Media Gateway Control Protocol. Request For Comments 2705, Internet Engineering Task Force, Outubro de 1999. [38] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., Segers, J. Megaco Protocol Version 1.0. Request For Comments 3015, Internet Engineering Task Force, Novembro de 2000. [39] Barbosa, R., Avaliao de Desempenho de Aplicaes VoIP P2P; 2007. Dissertao (Mestrado em Cincia da Computao) - Universidade Federal de Pernambuco, Pernambuco, 2007. [40] Kamienski, C., Mariz, D., Sadok, D. &.Fernandes, S., Arquiteturas de Rede para a Prxima Gerao da Internet, SBRC 2005, Maio de 2005.
56
[41] TANENBAUM, Andrew S. Computer Networks, 3rd edition. Prentice Hall. 2001. [42] Illuminating the Shadows, Opportunistic network and web measuremen, http://illuminati.coralcdn.org/stats/, ltimo acesso em Agosto de 2006. [43] Rocha, J., Domingues, M. A., Callado, A., Souto, E., Silvestre G., Kamienski, C. A., Sadok, D. "Peer-to-Peer: Computao Colaborativa na Internet" Minicursos SBRC2004 p. 3-46, Maio de 2004.. [44] Ford, B., Srisuresh, P., Kegel, D., Peer-to-Peer Communication Across Network Address Translators, USENIX Annual Technical Conference, Abril de 2005. [45] J. Rosenberg, C. Huitema, R. Mahy, "Traversal using relay NAT (TURN)", InternetDraft (Work in Progress), Setembro de 2005. [46] J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy, "STUN - simple traversal of user datagram protocol (UDP) through network address translators (NATs)", RFC 3489, Maro de 2003. [47] KAMIENSKI, C. A., SADOK, D., Qualidade de Servio na Internet, minicurso, 18o SBRC, Belo Horizonte/MG, Maio de 2000. [48] PAXSON, V. et al. Framework for IP Performance Metrics. RFC 2330. Maio de 1998. [49] ALMES, G.; KALIDINDI, S.; ZEKAUSKA, M. A One-way Delay Metric for IPPM. RFC 2679. Setembro de 1999. [50] ALMES, G.; KALIDINDI, S.; ZEKAUSKA, M. A One-way Packet Loss Metric for IPPM. RFC 2680. Setembro de 1999. [51] BRADEN, R. et al. Integrated Services in the Internet Architecture: an Overview. RFC 1633. Junho de 1994. [52] SHENKER, S. et al. Specification of Guaranteed Quality of Service. RFC 2212. Setembro de 1997. [53] WROCLAWSKI, J. Specification of the Controlled-Load Network Element Service. RFC 2211. Setembro de 1997. [54] BRADEN, R. et al. Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. RFC 2205. Setembro de 1997. [55] XIAO, X.; NI, L. M. Internet QoS: A Big Picture. IEEE Network. Maro de 1999. [56] BLAKE, S. et al. An Architecture for Differentiated Services. RFC 2475. Dezembro de 1998. [57] POSTEL, J. Internet Protocol. RFC 791. Setembro de 1981. [58] NICHOLS, K. et al. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474. Dezembro de 1998. [59] HEINANEN, J. et al. Assured Forwarding PHB Group. RFC 2597. Junho de 1999. [60] JACOBSON, V. et al. An Expedited Forwarding PHB. RFC 2598. Junho de 1999.
57
[61] NICHOLS, K.; JACOBSON, V.; ZHANG, L. A Two-bit Differentiated Services Architecture for the Internet. RFC 2638. July 1999. [62] Birke, R.; Mellia, M.; Petracca, M.; Understanding VoIP from Backbone Measurements, 26th Annual Conference on Computer Communications (INFOCOM 2007), Maio de 2007. [63] International Telecommunications Union. The E-model, a computational model for use in transmission planning, Recommendation G.107, Dezembro de 1998. [64] Lustosa, L.C.G., Carvalho, L.S.G., Rodrigues, P.H.A., Mota, S. E, Utilizao do Modelo E para avaliao da qualidade da fala em sistemas de comunicao baseados em voz sobre IP, in: Anais do XXII Simpsio Brasileiro de Redes de Computadores. Gramado, Maio de 2004. [65] International Telecommunications Union. Objective quality measurement of telephone-band (300-3400 Hz) speech codecs, Recommendation P.861, Fevereiro de 1998. [66] Rix, A. W. and Hollier , M. P. The perceptual analysis measurement system for robust end-to-end speech quality assessment. IEEE ICASSP, Junho de 2000. [67] International Telecommunications Union. Recommendation P.862, Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs. Geneve, 2001. [68] Demichelis, C., Chimento, P., IP Packet Delay Variation Metric for IP Performance Metrics (IPPM), RFC 3393, Novembro de 2002. [69] Almes, G., et al, A One-way Packet Loss Metric for IPPM, RFC 2680, Setembro de 1999. [70] Millis, D., Network Time Protocol (Version 3) Specification, Implementation and Analysis, RFC 1305, Maro de 1992. [71] Barbosa, R., Sadok, D., Calculando Mtricas Unidirecionais na Internet. Trabalho de Graduao do Centro de Informtica da UFPE, Maro 2005. [72] Rigney, C. RADIUS Accounting. IETF RFC 2866. Junho de 2000. [73] Rigney, C., Willens, S., Rubens, A., Simpson, W., Remote Authentication Dial In User Service (RADIUS). RFC 2865. Junho de 2000. [74] Lin, M., Lo, C. and W., S.: Design and Implementation of an Enterprise Call Analysis System for VoIP Deployments.2003 Australian Telecommunications Networks and Applications Conference (ATNAC). Dezembro de 2003. [75] Broom, S., Hollier, M., Speech Quality Measurement Tools for Dynamic Network Management. Measurement of Speech and Audio Quality in Networks (MESAQIN) 2003. Maio de 2003. [76] Telchemy, Sqmon, Service Quality Monitoring for Voice over IP. Disponvel em: http://www.telchemy.com/sqmon.html. ltimo acesso em Fevereiro de 2007.
58
[77] Empirix, Hammer XMS. Disponvel emhttp://www.empirix.com/Empirix/Network+IP+Storage+Test/hammer+xms.html. ltimo acesso em Fevereiro de 2007. [78] Brix Networks, Advanced VoIP Test Suites. Disponvel em http://www.brixnet.com/products/voip_testsuite.html. ltimo acesso em Fevereiro de 2007. [79] Gonalves, F., "Asterisk - Guia de Configurao", 2 edio, V. Office, 2006. [80] Wahl, M., Howes, T. and Kille, S. "Lightweight Directory Access Protocol (v3)," IETF RFC 2251, Dezembro de 1997. [81] Faltstrom, P. E.164 number and DNS. IETF RFC 2916, Setembro de 2000. [82] Rocha Jnior, Joo Batista, Fidalgo, Joseane, Dantas, Ramide, Oliveira, Luciana, Kamienski, Carlos, Kelner, Judith and Sadok, Djamel F, X-Peer: Um Middleware para Aplicaes Peer-to-Peer. (SBRC2005), Fortaleza-CE, Brasil, Maio de 2005. [83] Vollenweider, Marc and Shetty, Sameer:Impact of Skype on Telecom Service Providers, Janeiro de 2005. [84] Biondi, Philippe and Desclaux, Fabrice: Silver Needle in the Skype, BlackHat Europe, Maro de 2006 [85] Saint-Andre, P., Extensible Messaging and Presence Protocol (XMPP): Core. RFC 3920, Outubro de 2004 [86] Saint-Andre, P., Extensible Messaging and Presence Protocol (XMPP: Instant Messaging and Presence, RFC 3921, Outubro de 2004. [87] Barbosa, R., Callado, A., Kamienski, C., Fernandes, S., Sousa, D., Kelner, J., Sadok, D., Avaliao do Desempenho de Aplicaes VoIP P2P, XXIV Simpsio Prasileiro de Redes de Computadores, Maio de 2006. [88] Rodrigo Barbosa, Carlos Kamienski, Denio Mariz, Arthur Callado, Stenio Fernandes, Djamel Sadok, Performance evaluation of P2P VoIP application, Proceedings of the 17th International workshop on Network and Operating Systems Support for Digital Audio & Video, Junho de 2007.

Construindo Redes de Voz sobre IP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Construindo Redes de Voz sobre IP

Enviado por

Direitos autorais:

Formatos disponíveis

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

1.2 A Rede de Telefonia Pblica Tradicional

Captulo 1: Construo de Redes de Voz sobre IP

1.3 Transmisso da Voz

Figura 2. Tratamento dado ao som em um sistema VoIP 1.3.1 Digitalizao do Sinal

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Amostras digitais aplicao

voz comprimida rede

aplicao Atraso de descompresso, converso analgica

Atraso de captura, digitalizao e c ompresso

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Pacotes gerados e recebidos

1.4 Sinalizao e Controle de VoIP

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Figura 10. Sinalizao de chamada usando H.323 sem Gatekeeper

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Figura 11. Arquitetura de Protocolos de Conferncia Multimdia Internet

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

(a) Proxy Server

(b) Redirect Server

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

http://sourceforge.net/projects/openmgcp Website do Netfilter/iptables, http://www.netfilter.org/

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

1.5 Gerenciamento de Qualidade de Servio

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

O IntServ um arcabouo de implementao com quatro componentes:

Captulo 1: Construo de Redes de Voz sobre IP

RESV RESV RESV RESV RESV RESV

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

FTN mapping FEC

ILM mapping label

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

1.6 Medio e Monitoramento

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

1.7 Estudos de Caso

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

Captulo 1: Construo de Redes de Voz sobre IP

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos

http://www.rnp.br/voip http://www.gprt.ufpe.br/gtp2p/. ltimo acesso em 15 de Fevereiro de 2006.

Captulo 1: Construo de Redes de Voz sobre IP

Figura 17. Rede XVoice

Minicursos: 25 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos