Construção de Redes de Voz sobre IP

Transcrição

1 Capítulo 1: Construção de Redes de Voz sobre IP 11 Capítulo 1 Construção 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 preponderância no mercado mundial. No Brasil, embora com avanço mais tímido do mercado e apesar dos problemas regulatórios, muitas empresas já a adotaram. Após quase 2 décadas de amadurecimento, pode-se dizer que todos os problemas tecnológicos para a implantação 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, além de citar diversas ferramentas livres e de código aberto que auxiliam nessa implantação.

2 12 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 1.1 Introdução Desde o século XIX, transmite-se voz humana à distância com uma qualidade razoavelmente inteligível. Ao longo de mais de cem anos, o serviço de telefonia evoluiu e atingiu um bom padrão de qualidade e um nível de confiabilidade que faz com que haja uma expectativa de que, em 99,999% do tempo, a rede de telefonia pública esteja funcional [1]. Com a aparição e popularização das redes de computadores e da Internet, surgiu uma grande variedade de inovações que revolucionaram a maneira como pessoas e empresas encaram a comunicação. Uma dessas inovações 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 idéia 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 convergência nos serviços de transferência 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 confiável para a comunicação de voz? Existem vários argumentos [2], o primeiro é que as pessoas desejam se comunicar de uma maneira mais interativa e de diversas formas por exemplo, através de , mensagens instantâneas, vídeo além disso há uma necessidade de integrar aplicações de voz e de dados. Outro motivo reside na popularidade da Internet e do IP, onde aplicações IP residem não somente em estações de trabalho, como por exemplo, também em dispositivos sem fio e PDAs. Finalmente, a redução de custos com telefonia, barateamento de telefones e de infra-estrutura constituem mais uma motivação para utilização de VoIP. Entretanto, no cenário atual, há empecilhos para se inserir com eficácia o serviço de voz sobre IP na Internet. O primeiro obstáculo é que o serviço de voz sobre IP requer condições especiais de rede para funcionar satisfatoriamente. Conforme discutido em [3], [4] e [5], um alto valor no atraso de transmissão dos pacotes, na variação do atraso, ou na taxa de perda de pacotes da fonte ao destino prejudicam a qualidade de uma sessão de voz sobre IP. Portanto, para a Internet constituir uma alternativa atrativa à rede de telefonia pública tradicional, deveria prover mecanismos que garantam a qualidade de serviço (QoS) para as aplicações VoIP. Várias técnicas e metodologias foram propostas para resolver direta ou indiretamente os problemas relacionados à QoS, mas o maior problema não é tecnológico, mas a necessidade de adoção dessas tecnologias parte da Internet, de forma a não deixar o tráfego de voz ser prejudicado com os congestionamentos do tráfego de dados. Isso visa trazer um pouco de injustiça a uma rede (Internet) que é justa demais e acaba penalizando os serviços que têm requisitos fortes para ter desempenho aceitável. Outra barreira para a difusão da tecnologia de voz sobre IP está relacionada ao crescimento da Internet e à implantação de mecanismos de segurança nas redes de acesso. Esses fatos impulsionaram mudanças na Internet, violando seu argumento fim-afim [6], que determina que a rede deve executar apenas tarefas muito simples. Como se percebe através de medições realizadas [7], entre essas mudanças está a disseminação de

3 Capítulo 1: Construção de Redes de Voz sobre IP 13 sistemas intermediários como NAT e firewall nas redes de acesso que, de acordo com Shieh [8], prejudicam os serviços e aplicações de voz sobre IP. As aplicações e serviços VoIP não figuravam entre os mais populares da Internet até 2003, quando a empresa Skype 1 disponibilizou sua aplicação VoIP gratuitamente. Apesar de se basear na Internet - uma rede que não oferece garantias de QoS - uma chamada do Skype alcança boa qualidade de voz ao utilizar codificadores de áudio proprietários e projetados para funcionar em ambientes com elevadas taxas de atraso, variação do atraso e perda de pacotes. Além disso, o Skype implementa mecanismos para transpor as barreiras de comunicação impostas por firewalls e NATs. Seguindo a mesma linha do Skype, em 2005 o Google disponibilizou sua aplicação VoIP gratuita, o GTalk 2. A grande participação de Voz sobre IP (VoIP) nos mercados hoje é considerado um grande motivo para a redução de custos do serviço de telefonia. Infelizmente, essa redução não é perceptível ainda no Brasil para quem não adotou alguma tecnologia VoIP. Problemas de regulamentação também impedem uma maior adoção da tecnologia no Brasil, o que nos torna meros seguidores atrasados das tendências mundiais. Para que seja possível implantar uma rede de VoIP, é necessário utilizar alguma técnica de avaliação de qualidade do serviço oferecido por essa rede. O MOS (Mean Opinion Score) é a metodologia mais conhecida, mas já não é mais utilizada em função de sua dificuldade de utilização. O PESQ (Perceptual Evaluation of Speech Quality), é a metodologia que tem ganho preponderância atualmente, junto com o Modelo-E, que é mais simples de implementar em alguns aspectos. Existem diversos softwares, muitos de código aberto, que podem ser utilizados para a implantação 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 telefônica privada), é um software de código aberto que implementa boa parte dos algoritmos de sinalização de diversas redes de voz (analógicas, digitais de comutadas e mesmo de VoIP). Como funciona com diversas placas de telefonia, também é freqüentemente usado para implantação de serviços de VoIP em locais que têm infra-estrutura analógica, funcionando como um Gateway de conversão da comunicação e da sinalização entre as redes. Por ser livre e ter o código fonte disponível, é cada vez mais usado pelas empresas que desejam utilizar serviços VoIP. Com tudo isso, a implantação de uma rede de VoIP é uma tarefa difícil e custosa, que requer um grande planejamento e atenção, por requerer a implantação de muitas tecnologias simultaneamente. A seção 1.2 a seguir trata da tecnologia da telefonia pública tradicional e a seção 1.3 trata das técnicas utilizadas para a codificação da voz para uso em VoIP. A seção 1.4 trata dos mais importantes protocolos de sinalização e controle de VoIP e de seus problemas. A seção 1.5 trata das tecnologias de qualidade de serviço que permitem uma convivência não-igualitária, mas harmoniosa de diversos serviços na Internet. A seção 1.6 traz as metodologias utilizadas para aferição de qualidade em redes VoIP e a seção 1.7 traz alguns estudos de caso realizados com o

4 14 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos uso de tecnologias de VoIP. Finalmente, a seção 1.7 tece algumas conclusões acerca da implantação da tecnologia e a seção 1.8 traz as referências utilizadas nesse texto. 1.2 A Rede de Telefonia Pública Tradicional Antes de apresentar o funcionamento de voz sobre IP, é interessante conhecer o seu concorrente e predecessor. A rede de telefonia pública (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 telefônico utiliza a técnica de comutação por circuitos [9]. Nessa técnica, durante uma ligação, 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 ligação não ocorre o problema de congestionamento, existente na Internet. O sistema telefônico é organizado hierarquicamente em vários níveis [9] [10] e formado por centrais telefônicas. Cada telefone está ligado a uma central local, que obtém o sinal analógico do telefone, o digitaliza e o transmite para uma central no núcleo da PSTN, chamada de central tandem. A conversa digitalizada segue pelas centrais do núcleo até retornar à central local do outro telefone, onde o sinal é novamente convertido para analógico e entregue. Em sistemas de voz sobre IP, os roteadores da Internet desempenham uma função análoga às centrais da PSTN. Em ambientes corporativos, a estrutura do sistema de telefonia é ligeiramente alterada para fornecer alguns serviços complementares como o de ramais, transferência de chamadas e conferência. Além disso, empresas necessitam possuir sua própria rede de telefonia, para a comunicação interna. Ao contrário de telefones residenciais, onde um telefone se liga diretamente a uma estação local, em ambientes corporativos, os telefones se ligam a um PABX (private automatic branch exchange), que é basicamente uma central privada. O PABX é responsável por promover redução de custos, fornecendo as funções descritas acima e permitindo que os usuários internos à empresa compartilhem um número limitado de linhas telefônicas externas. A Figura 1 mostra uma chamada telefônica entre um usuário doméstico e um usuário corporativo utilizando a PSTN. O advento das centrais telefônicas digitais, conhecidas como CPA (Central por Programa Armazenado), trouxe um novo rumo para o mercado. Equipamentos compactos, com processador central e programação através de software levaram a telefonia para o mundo da informática. Todo acesso ao equipamento passou a ser feito através de um computador com um software proprietário, o qual permitiu executar toda a programação do equipamento (roteamento, criação de novos assinantes/ramais, criação de novos links) e trouxe novas facilidades para os assinantes. A programação tornou-se flexível, mas os protocolos de sinalização entre equipamentos e a forma de estabelecimento das chamadas continuaram os mesmos.

5 Capítulo 1: Construção de Redes de Voz sobre IP 15 Ambiente Corporativo PSTN Central tandem PABX Central local Central tandem Central local Telefone Analógico Figura 1. Chamada entre um usuário doméstico e um usuário corporativo na PSTN A maioria das empresas possui sua rede de dados interligada à Internet através de enlaces dedicados das concessionárias de telecomunicações, utilizando o protocolo IP. Em paralelo a essa rede, as empresas mantêm uma rede de telefonia privada, também ligada à rede pública através de links digitais ou linhas analógicas. Essa rede é bastante onerosa, tanto no que diz respeito à ampliação e manutenção dos equipamentos, quanto ao custo mensal das ligações geradas. A grande vantagem da tecnologia VoIP é a redução dos custos telefônicos, aproveitando uma infra-estrutura de rede já existente. 1.3 Transmissão da Voz Esta subseção expõe o processo de manipulação do som em um sistema VoIP [11], desde sua entrada no sistema (um emissor enviando um sinal analógico) até sua saída em um terminal VoIP remoto. O processo é ilustrado na Figura 2 e descrito em seguida. Rede digitalização empacotamento buffer desempacotamento decodificação Figura 2. Tratamento dado ao som em um sistema VoIP Digitalização do Sinal A voz humana é um sinal analógico de áudio que possui amplitudes variáveis no tempo. Para que esse sinal analógico possa ser utilizado em ambientes digitais é necessário transformá-lo num sinal discreto. A esse processo de conversão de um sinal analógico num sinal digital chamamos de digitalização, estando as etapas desse processo representadas na Figura 3. O processo de digitalização de um sinal consiste de três etapas: amostragem do sinal analógico, quantização e codificação. Na amostragem é retirada parte do sinal

6 16 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos analógico, de forma que não haja perdas de informação na reconstituição desse sinal. Para tanto, é usado o Teorema de Nyquist [12], o qual especifica que a freqüência de amostragem (fa) deve ser maior que duas vezes a maior freqüência contida no sinal analógico (fs): fa > 2fs. Filtro 300Hz a 3400Hz Etapa de Amostragem Etapa de Quantização Etapa de Codificação Figura 3. Processo de digitalização de um sinal de voz Para a faixa de freqüência de 300 Hz a 3400 Hz, usada na telefonia convencional, foi fixada, internacionalmente, uma freqüência 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 analógico, o qual é transformado num sinal digital após a quantização e codificação. Após a quantização, o sinal é codificado e enviado ao meio de transmissão. Do lado do receptor, o sinal é decodificado, ou seja, é feita a conversão de sinal discreto para sinal analógico, inteligível aos ouvidos humanos Algoritmos de Codificação Segundo Monteiro [13], os codificadores têm como principal objetivo a redução da taxa de transmissão de bits (compressão do sinal), o que influencia diretamente no espaço de memória e na largura de banda necessária para a transmissão. Em contrapartida, têm como desvantagens o aumento do atraso e a perda da qualidade do sinal, devido ao processamento do algoritmo de codificação e decodificação, conforme mostrado na Figura 4. origem Conversor A/D Rede Digital Conversor D/A Destino sinal analógico Amostras digitais voz comprimida voz comprimida Amostras digitais sinal analógico aplicação Atraso de captura, digitalização e c ompressão rede Atraso de transmissão aplicação Atraso de descompressão, conversão analógica Figura 4. Atrasos na transmissão de um sinal Os codecs possuem características que determinam a escolha para o seu uso: taxa de bits, atraso, complexidade do algoritmo, qualidade. Esta diz respeito ao nível máximo de qualidade a ser obtida pelo receptor. Nesse sentido, o PCM Linear fornece a melhor qualidade, embora utilize uma banda maior.

7 Capítulo 1: Construção de Redes de Voz sobre IP 17 Existem codificadores de áudio que foram desenvolvidos especificamente para a compressão da voz humana [14]. Esses algoritmos exploram redundâncias e relevâncias (sinais fora de freqüência produzida pela voz) encontradas nos sinais, ou até propriedades do ouvido humano como aproximações e preenchimento de seqüências incompletas. Esses codificadores, também conhecidos como codificadores híbridos, 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 são 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 reprodução de voz humana. Esses codificadores usam pequena largura banda, em torno de 4.8 kbps, mas possuem baixa qualidade na reprodução da voz, que resulta numa voz sintética (robótica). Existem algumas entidades responsáveis por normalizar codificadores de áudio e vídeo, 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 são 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 codificação de vídeo 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 compressão de imagens estáticas. No codec G.711 a quantificação da voz é feita numa escala logarítmica. Esse codec é o padrão da telefonia convencional, apresentando uma excelente qualidade na reprodução da voz, porém requer uma largura de banda maior para a transmissão (64kbps). A digitalização do sinal e a quantidade de canais utilizados nessa transmissão determinam a quantidade de bytes requeridos para se armazenar o sinal e a largura de banda para se transmitir essa seqüência de áudio. O G.729 [16] e G [17] pertencem à classe de algoritmos que utilizam o modelo CELP (Code Excited Linear Prediction), que é o modelo de codificação utilizado pela telefonia móvel. O modelo CELP foi projetado para operar em redes de circuitos chaveados, levando em consideração perda de bits e não perdas de pacotes. Esses codecs trabalham com um sinal digital convertido em um sinal analógico, obtido por filtragem, conforme recomendação G.712 [18]. Após amostragens por segundo, o sinal é convertido para um PCM linear de 16 bits, servindo de entrada para o codificador. A saída do decodificador é convertida para analógica de forma muito parecida. Os filtros do G.729 utilizam coeficientes gerados pelo método de autocorrelação com janelas de observação de 30ms. A cada 80 amostragens a 10ms os coeficientes são atualizados e é feito o deslizamento da janela, realizando assim a análise destes valores levando em conta as 120 amostras dos 4 quadros passados, as 80 amostras do quadro atual e 40 amostras do próximo quadro, onde se pode observas os 5ms de look-ahead.

8 18 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Na Tabela 1, temos os tipos de codecs mais utilizados, com as respectivas características: técnica de compressão utilizada, taxa de geração do sinal, atraso de empacotamento e qualidade do sinal (MOS). O parâmetro MOS (Mean Opinion Score), está definida pela ITU-T nas recomendações P.800 [19] e P.830 [20]. O MOS é uma avaliação subjetiva, obtida através de testes, em que um conjunto de ouvintes avaliam a qualidade da voz numa escala de1(ruim) a 5(excelente). Tabela 1. Características de alguns codecs Codec Técnica de Compressão Taxa de bit (Kbps) Atraso de Codificação (ms) MOS Linear Linear Sem compressão 128 0,125 4,5 G.711 PCM - Pulse Code Modulation 64 0,125 4,1 G MP MLQ ,6 G ACELP - Algebraic Code Excited Linear Prediction G.726 ADPCM Adaptive Diferencial 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) ,1 16,24,32,40 0,125 3, , , ,8 Conforme podemos observar, ainda na Tabela 1, os codecs G.729A e o G utilizam uma reduzida largura de banda, porém têm uma menor qualidade, traduzida em valores de MOS menores, apresentando também, tempos de codificação mais elevados. Com o desenvolvimento de aplicações de VoIP, uma nova geração 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 método Linear Predictive Code (LPC) para a compressão da voz. É adequado para aplicações em tempo real, tais como: telefonia, vídeo-conferência. No projeto no XVoice foi utilizado o codec GSM RPE-LTP (Regular Pulse Excitation Long-Term Prediction), também conhecido como GSM FULL RATE. A principal característica do codec GSM é o modelo matemático que modela o sistema vocal humano, utilizando o método de compressão LPC. O LPC é um método

9 Capítulo 1: Construção de Redes de Voz sobre IP 19 de compressão digital projetado especificamente para voz. Ele adapta o sinal de voz por um modelo matemático para transmissão, e depois decodifica para gerar uma voz sintética similar a original. Esse algoritmo usa a informação 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 Empacotamento e Transmissão 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 necessário enviar um pacote (que contém uma amostra) a cada 125 microssegundos, saturando a rede de informações 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 possível a comunicação entre as máquinas. Entretanto, para que as aplicações residentes nas máquinas se comuniquem, é essencial a utilização de um protocolo de transporte, como o TCP [23] e o UDP [24], usados na Internet. Abreviação para Protocolo de Controle de Transmissão, o TCP [23] reenvia os pacotes perdidos e garante a entrega dos dados na ordem que foram enviados. O TCP é orientado a conexão, o que significa que antes de realmente transmitir os dados, é necessário estabelecer uma conexão entre as aplicações, com um processo conhecido como three-way-handshaking. O TCP realiza o controle de fluxo, um mecanismo para proteger o remetente de saturar o destinatário, ou seja, evita que o remetente envie informações em uma taxa além daquela que o destinatário possa processar. Finalmente, o TCP implementa o controle de congestionamento, que tem a função de reduzir a taxa de transmissão de acordo com o nível de congestionamento da rede. O UDP [24] é um protocolo não orientado à conexão onde os pacotes podem ser entregues fora de ordem ou até perdidos. Ao contrário do TCP, o UDP não provê controle de fluxo nem congestionamento. Em resumo, a idéia por trás do UDP é transmitir dados com o maior velocidade possível, sem confiabilidade, ao contrário do TCP, onde a confiabilidade é o aspecto mais importante. Informações de voz são geralmente transmitidas usando UDP como protocolo de transporte. As principais motivações para se usar UDP, ao invés de TCP, em VoIP são: Caso um pacote no início de uma seqüência seja perdido, mesmo que os subseqüentes cheguem ao destino, o TCP espera a retransmissão do primeiro pacote para entregar todo o restante da seqüência à aplicação. Esse aspecto adiciona um atraso determinado pelo próprio protocolo TCP, prejudicando a interatividade. O three-way-handshaking do TCP adiciona latência ao início da comunicação; Devido aos mecanismos de controle de fluxo e de congestionamento do TCP, a taxa de transmissão do TCP não é controlada pela aplicação, mas pelo próprio protocolo.

10 20 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos No entanto, certas aplicações de voz sobre IP, como por exemplo, o GTalk e o Skype, em algumas ocasiões, utilizam TCP na comunicação. Não se encontrou na literatura e nos sites das aplicações o motivo para tal comportamento RTP/RTCP Para aplicações VoIP apenas o serviço de entrega de pacotes provido pelo UDP não é suficiente. São necessários outros serviços, como, por exemplo, saber a ordem e tempo de geração de pacotes além de possuir o conhecimento acerca da qualidade da conexão. Essas atividades competem ao RTP e ao RTCP. Esses protocolos se propõem 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 serviços essenciais para aplicações de tempo real, além de obviamente transportar a mídia (e.g. voz, vídeo) dessas aplicações. O RTCP (Real Time Control Protocol) obtém informações da rede (quantidade de jitter, perda média de pacotes, etc.), permitindo que medidas corretivas apropriadas possam ser adotadas, tais como: uso de redundância, 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 retransmissão do TCP não traria nenhum benefício para a transmissão de aplicações em tempo real. O RTP é um dos protocolos mais importantes da arquitetura VoIP. Conforme descrição em [25], o RTP é um protocolo que provê serviços de entrega fim-a-fim para aplicações com característica de tempo real, como áudio e vídeo interativos. Suporta transferência de dados para serviços multicast e também possui características de reconstrução de sincronismo, detecção de perda de datagramas, segurança, dentre outras. No entanto, o RTP não oferece nenhuma reserva de recurso na banda, nem recuperação dos pacotes e não garante qualidade de serviço (QoS). A qualidade de serviço é definida pelo ITU-T como "o efeito coletivo de desempenho que determina o grau de satisfação do usuário deste serviço específico". Os parâmetros de QoS se relacionam com métricas de controle de chamada, de transferência de informação e de qualidade da rede. Sendo assim, o RTP utiliza o RTCP para monitorar QoS e transportar informações em uma sessão contínua. O RTCP tem como objetivo o monitoramento da qualidade de serviço e o transporte de informações úteis numa transmissão RTP. Esse monitoramento é conseguido através de relatórios que são gerados tanto pelos transmissores como pelos receptores dos pacotes RTP. É um protocolo que pode ser usado juntamente com o RTP, porém sua utilização não é necessária para que o RTP funcione. Os relatórios utilizados pelo RTCP contêm informações tais como: número de pacotes enviados, número de pacotes perdidos, jitter. Embora essas informações não informem onde determinado problema está ocorrendo, elas podem servir como ferramenta para localizar o problema. Para que não haja excesso de tráfego RTCP, o ritmo de geração deste tipo de relatório é alterado dinamicamente, para que não ultrapasse 5% do tráfego total na sessão, segundo recomendação do IETF. Esta situação de tráfego elevado poderia ocorrer facilmente devido ao uso de multicast, onde muitos clientes enviam relatórios para o mesmo servidor.

11 Capítulo 1: Construção de Redes de Voz sobre IP 21 O pacote VoIP é formado pelo cabeçalho IP, pelo cabeçalho UDP, pelo cabeçalho 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 cabeçalho do pacote VoIP é o dobro da carga útil. Concluímos que a transmissão de pouca informação por pacote é bastante ineficiente. Para aumentar a eficiência da transmissão de voz, pode-se utilizar uma técnica de compressão que reduz o tamanho do cabeçalho para 2 bytes, se não existir checksum, ou para 4 bytes para o envio de checksum UDP. Essa técnica, muito utilizada nas linhas de baixa velocidade, é designada crtcp (Compressed RTP), sendo definida na RFC 2508 [26] Problemas Relacionados à Transmissão de Voz As aplicações VoIP são aplicações em tempo real, possuindo requisitos bem mais exigentes que as aplicações que rodam normalmente na Internet. Transmissão Recepção Figura 5. Exemplifica o fator atraso numa rede de pacotes Existem diversos fatores que podem prejudicar a qualidade da comunicação, sendo os mais críticos 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 variação no atraso da transmissão, conforme mostrado na Figura 6. As perdas de pacotes podem ocorrer porque as redes baseadas no protocolo IP não garantem a entrega dos mesmos, ou por um grande atraso na entrega dos pacotes, fazendo com que a aplicação descarte os mesmos. Transmissão Recepção Figura 6. Exemplifica o fator jitter numa rede de pacotes Segundo [27], as recomendações sobre atraso, jitter e perda de pacotes para que uma rede possibilite uma boa qualidade de chamadas VoIP são: atraso fim-a-fim menor

12 22 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos que 150 ms, limite máximo de 50 ms para jitter, taxa de perda de pacotes máxima de 3% (recomendável que seja inferior a 0,50%). O não cumprimento desses limites compromete a inteligibilidade do sinal entregue ao receptor, podendo inviabilizar a aplicação Uso de Buffers Na recepção do áudio de um sistema VoIP, a mídia 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 reprodução. Contudo, como visto anteriormente, o serviço de entrega dos dados na Internet não fornece um atraso determinístico, ou seja, o atraso é variável devido a diferentes condições de rede enfrentadas por pacotes consecutivos. Com isso, o sincronismo necessário não é garantido. Logo, é necessária uma memória temporária (buffer) que minimize ou elimine os problemas que a variação do atraso causa à execução do áudio. Para ilustrar a importância da buferização, considere a Figura 7. Pacotes gerados e recebidos emissor receptor tempo Figura 7. Envio e recepção de pacotes contendo voz [28] No emissor, ocorre o empacotamento e transmissão, onde pacotes contendo amostras de áudio são periodicamente enviados. Entretanto, os pacotes chegam no receptor com um atraso não-determinístico. Com o intuito de suavizar essa variação do atraso, o receptor pode retardar a execução do áudio recebido armazenando os quadros mais recentes em um buffer. Na Figura 7, se o receptor retardasse a execução do áudio até t 2, todos os pacotes teriam sido reproduzidos, mas se t 1 fosse utilizado, os pacotes 6, 7 e 8 teriam sido descartados pelo receptor. 1.4 Sinalização e Controle de VoIP Da mesma forma que na telefonia tradicional, ao se contactar alguém, 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 alguém deseja se comunicar. Esse procedimento é conhecido como sinalização, que

13 Capítulo 1: Construção de Redes de Voz sobre IP 23 consiste no processo de estabelecimento e desligamento da sessão 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, é responsável por iniciar, gerenciar e finalizar sessões voz. Na seqüência, com o propósito de apresentar de forma mais concreta a sinalização em voz sobre IP, serão apresentados os protocolos mais comuns no contexto: H.323, SIP, IAX2, SCCP, MGCP e MEGACO H.323 O protocolo H.323 [29][30] é usado para a transmissão de áudio, vídeo e dados sobre redes baseadas em pacotes (ver Figura 8). Ele especifica os componentes, os protocolos, e procedimentos para o tráfego de multimídia. O H.323 pode ser usado para uma variedade de aplicações: Telefonia IP, Videofone, áudio e dados e áudio, vídeo e dados. H.323 também pode ser aplicado a comunicações multiponto (conferência). Figura 8. Terminais H.323 em uma rede puramente de pacotes O padrão H.323 foi especificado pelo grupo de estudo 16 da divisão de Telecom Standardization (ITU-T) da International Telecommunication Union 3 (ITU), um órgão das Nações Unidas para a padronização e regulamentação de telecomunicações. A versão 1 da recomendação H.323, aceita em Outubro de 1996, era voltada para os sistemas e equipamentos de videofone para redes locais (LANs). Esta versão não tratava de qualidade de serviço. Todas as mensagens são codificadas usando a sintaxe Abstract Syntax Notation 1 (ASN.1), também definida pela ITU. O aparecimento de aplicações de Voz sobre IP (VoIP) e de telefonia IP forçou uma revisão da especificação H.323. A ausência de um padrão de Voz sobre IP resultou em produtos incompatíveis. Com o desenvolvimento de VoIP, as novas exigências apareceram, como fornecer uma comunicação entre um telefone baseado em PC (softphone) e um telefone em uma rede de comutação de circuito tradicional (Switched Circuit Network - SCN). Tais exigências aumentaram a necessidade de um padrão para telefonia IP. As versões seguintes do H.323 foram criadas para acomodar estas exigências adicionais, além de transmissão de fac-símile (FAX), conversação de texto, segurança, controle de serviços baseado em HTTP, sinais de modem, controle de câmera, redirecionamento e restabelecimento de sinalização. A última versão do protocolo H.323 é de Junho de

14 24 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Entidades do H.323 O protocolo H.323 especifica quatro componentes que, interligados em rede, provêem os serviços de multimídia 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 aplicação multimídia ou um dispositivo dedicado a uma aplicação específica. O terminal deve suportar comunicação de áudio e pode suportar comunicação de vídeo e dados, opcionalmente. Terminais H.323 podem ser usados em conferência multiponto. Um dos principais objetivos do H.323 é a interoperabilidade com outras redes de serviços multimídia. Essa interoperabilidade é alcançada com o uso de um gateway. Um gateway H.323 provê conectividade entre uma rede H.323 e uma rede não-h.323 (SIP, PSTN, etc), realizada atrevés da tradução de protocolos para realização e liberação de chamada e pela conversão de mídia entre as diferentes redes. É importante notar que um gateway não é relevante para a interconexão entre dois terminais em uma rede H.323. Um gatekeeper pode ser considerado o cérebro de uma rede H.323. É o ponto mais importante para as chamadas entre equipamentos de uma ou mais redes H.323. Embora não sejam requeridos para comunicação, gatekeepers provêem serviços como endereçamento, autenticação e autorização de terminais e gateways; gerenciamento de banda; contabilidade; e cobrança. Também podem prover roteamento de chamadas. MCUs provêem suporte a conferência de três ou mais terminais H.323. Todos os terminais participando da conferência estabelecem uma conexão com o MCU. O MCU gerencia recursos da conferência, negocia com os terminais para determinar os codificadores/decodificadores (CODECs) de áudio ou vídeo que serão usados e pode se encarregar de tratar a transmissão. Observa-se que os gatekeepers, gateways e MCUs são elementos lógicos distintos na arquitetura do H.323, mas podem ser implementados no mesmo dispositivo físico Componentes do H.323 Uma zona H.323 (ver Figura 9) é uma coleção 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 múltiplos segmentos de rede que são conectados usando roteadores e outros dispositivos. Os principais protocolos utilizados pelo H.323 estão listados abaixo. A especificação independe da rede e dos protocolos de transporte utilizados. CODECs de áudio e vídeo H.225: registro, admissão e estado (RAS) e sinalização de chamadas H.245: sinalização de controle Real-Time Transport Protocol (RTP) e Real-Time Control Protocol (RTCP)

15 Capítulo 1: Construção de Redes de Voz sobre IP 25 Terminais zona 1 GK D-GK rede IP GK zona 2 Terminais GW GW PSTN Figura 9. Gateway, Gatekeeper e Terminais em uma arquitetura H.323 Registro, admissão e estado (RAS) [31] é o protocolo usado entre endpoints (terminais e gateways) e gatekeepers. O RAS é usado para realizar registro, controle de admissão, mudança de banda, mudança de estado e procedimentos de desconexão entre endpoints e gatekeepers. Um canal RAS é usado para trocar mensagens RAS. Esse canal de sinalização é aberto entre um endpoint e um gatekeeper antes do estabelecimento de qualquer outro canal. A sinalização de chamada [31] é usada para estabelecer uma conexão. Isso é alcançado através da troca de mensagens H.225 no canal de sinalização de chamada, que pode ser aberto entre dois endpoints ou entre um endpoint e um gatekeeper. A sinalização de controle [32] é usada para trocar mensagens de controle fim-afim e governar o funcionamento do endpoint H.323. As mensagens de controle trazem informações relativas a troca de Capacidade, abertura e fechamento de canais lógicos (transporte de mídia), mensagens de controle de fluxo, indicações e comandos. SETUP CALL PROCEEDING ALERTING CONNECT H.245 Fluxo de Mídia RELEASE COMPLETE Figura 10. Sinalização de chamada usando H.323 sem Gatekeeper

16 26 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos A Figura 10 ilustra as mensagens trocadas em um processo normal de sinalização utilizando H.323 sem a participação 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 através da mensagem CONNECT e o término de chamada é sinalizado através da mensagem RELEASE COMPLETE Problemas Conforme discutido anteriormente, H.323 é um protocolo que aproveitou esforços já realizados na definição de recomendações da telefonia pública. Embora adotado pela indústria, o H.323 possui diversos inconvenientes. Sabe-se que H.323 é conhecido pela sua alta complexidade, onde sua recomendação tem aproximadamente 1400 páginas de documentação essencial e cobre um número maior de serviços do que é necessário para telefonia IP. Outra dificuldade, principalmente enfrentada pelos programadores, é que os protocolos de H.323 são especificados usando uma notação complexa, a ASN.1, que dificulta o desenvolvimento e depuração das aplicações. Outro inconveniente é a grande quantidade de mensagens trocadas, além do número excessivo de conexões que devem ser abertas para iniciar uma sessão de áudio. A complexidade do H.323 encareceu equipamentos e fez com que a maioria dos fabricantes não o implementasse completamente. Embora ainda em grande utilização, essa recomendação vem perdendo espaço para o SIP, um protocolo mais simples que tenta solucionar os inconvenientes do H 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 Conferência Multimídia Internet, em desenvolvimento na IETF. Esses protocolos, mostrados na Figura 11, são partes independentes, mas são utilizados em conjunto numa aplicação VoIP. Temos como exemplo o SIP, que usa o SDP (Session Description Protocol) [34] para especificar as características da mídia utilizada, o RTP para o transporte da mídia e o RTCP para o monitoramento da conexão. O SIP é um protocolo baseado em texto, assim como o SMTP e o HTTP, enviando requisições e esperando respostas. É um protocolo da camada de aplicação projetado para controlar o estabelecimento de ligações telefônicas, de vídeoconferências e outras aplicações multimídia, possuindo as seguintes características: Oferece recursos de controle de chamada como: chamada em espera, encaminhamento, transferência, mudanças de mídia, etc; Aceita a infra-estrutura da Web, por exemplo, segurança, cookies, etc; É orientado para Web e independente do protocolo de rede; Pode oferecer notificação de eventos e listas de companheiros ;

17 Capítulo 1: Construção de Redes de Voz sobre IP 27 Figura 11. Arquitetura de Protocolos de Conferência Multimídia Internet Suporta ligações ponto-a-ponto, multiponto e multicast; Suporta serviços como: localização de um terminal, determinação da capacidade do terminal, sinalização para estabelecimento e término de chamadas; Na área de segurança suporta encriptação e autorização de usuário Arquitetura Básica do SIP As entidades SIP se comunicam usando transações. O SIP chama cada transação 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 conexão SIP consiste em abrir uma conexão de sinalização 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 conexão pode ser usada para todos os pedidos e respostas SIP (exceto dos dados de mídia), ou pode-se usar uma conexão para cada transação. Para o caso do UDP, o endereço e a porta a serem usados para as respostas a pedidos SIP estarão no parâmetro via do pedido SIP. A porta 5060 é utilizada para ambos os protocolos de transporte, a não ser que outra porta seja especificada Endereçamento SIP Os usuários SIP são definidos por URIs (Universal Resource Identifiers), parecidos com endereços de s, que podem conter endereços IPv4, IPv6, números de telefones ou nomes. O padrão de endereçamento SIP é user@host. O user pode ser o nome do usuário, o número do telefone ou um nome qualquer. O host poder ser o nome de um

18 28 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos domínio ou um endereço de rede. Exemplos de endereços SIP são: sip: @ufpe.br, sip: gprt@ufpe.br, sip:maria@ Mensagens SIP As mensagens SIP são classificadas em requisições e respostas. Na versão atual (SIP 2.0), há seis tipos de requisições, conforme descrição a seguir: INVITE: Sinaliza um convite para uma sessão. Em VoIP, um campo SDP sempre está anexo ao INVITE. ACK: Confirma que o cliente recebeu uma resposta final para um INVITE. OPTIONS: Solicita informações sobre capacidades (e.g. codecs disponíveis). BYE: Finaliza uma chamada CANCEL: Cancela métodos/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 métodos estão agrupadas em seis classes de código. A classe 1XX (Infomation) representa as respostas provisórias. 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 ligação VoIP bem sucedida, sinalizada com SIP Componentes SIP Na arquitetura SIP há dois tipos de componentes: agente usuário e servidores de rede. O agente usuário é composto pelos User Agent Client (UAC) e User Agent Server (UAS). O UAC é usado para iniciar uma requisição SIP, enquanto o UAS recebe requisições e retorna respostas aos clientes.

19 Capítulo 1: Construção de Redes de Voz sobre IP 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 sessão 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 são atendidos internamente ou encaminhados para outros servidores, após serem traduzidos. Assim, um Proxy interpreta, e se necessário, reescreve uma mensagem antes de reenviar. O Servidor de Redirecionamento aceita um pedido SIP, convertendo, se necessário, em novos endereços e devolvendo esses endereços ao cliente. Os Servidores de Proxy e de Redirecionamento utilizam outros servidores denominados Servidores de Localização para obter informação sobre a localização de um determinado cliente SIP. Porém os Servidores de Localização não fazem parte da especificação SIP IAX2 O IAX2 (Inter-Asterisk exchange) é a segunda versão do protocolo de VoIP especificado para comunicação entre servidores de PBX Asterisk e outros servidores/clientes e dispositivos VoIP. Quando citado somente como IAX, normalmente podemos tomar por referência à segunda versão do protocolo [35], já que sua primeira versão caiu em desuso, em prol do IAX2. Assim como o SIP e outros protocolos para controle e sinalização de sessões multimídia, o IAX2 suporta os tipos mais comuns de mídias, 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 além das que hoje existem. Além disso, o IAX2 utiliza uma mesma porta UDP para sinalização e mensagens de mídia, facilitando seu uso com firewalls e NATs [36]. Outro esforço para aumentar a eficiência no uso da largura de banda foi tornar o IAX2 um protocolo de codificação binária.

20 30 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos O elemento atômico de comunicação do IAX2 é o Frame. Existem várias classes de Frames, como os Full Frames, que transmitem dados de sinal e controle, os Meta Frames, que são usados para roteamento de chamadas e transmissão de fluxos de vídeo, e os Mini Frames são usados para transmissão do fluxo de dados de mídias. Full Frames podem conter Information Elements (IEs), que descrevem tipos de usuários ou dados específicos da chamada. Uma chamada realizada com IAX2 pode ser composta por vários segmentos, sendo possível implementá-los usando diferentes protocolos. O IAX2 é responsável por configurar um ou mais segmentos do caminho percorrido pela chamada, não necessariamente todos. Por ser um protocolo otimizado para uso ponto-a-ponto, ele pode supervisionar mudanças no caminho da chamada, até que o melhor caminho para a chamada seja configurado e estabelecido pelos participantes. O IAX2 suporta funcionalidades de segurança através de diferentes métodos de autenticação, e provê um framework genérico para uso de encriptação 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 mídia. Estre protocolo é considerado obsoleto e ainda é usado para interoperabilidade VoIP com antigos telefones Cisco que não implementam outros protocolos Controle de Gateways Redes de VoIP muito grandes necessitam de uma forma automatizada de configurar e controlar seus equipamentos. Diversas redes de VoIP provêem acesso à telefonia convencional, utilizando muitos gateways. Pensando nessas redes, foram propostos protocolos com o objetivo de controlar gateways de maneira automática, diminuindo o esforço 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 esforço conjunto entre a IETF e a International Telecommunication Union 4. Ambos são explicados a seguir MGCP A arquitetura do MGCP [37] define três elementos: Call Agent (CA, também chamado de Media Gateway Controller), Media Gateways (MGs) e Signalling Gateways (SGs). Os MGs são gateways propriamente ditos, isto é, provêem acesso a outras redes, como a rede de telefonia convencional. Comumente, os serviços de MG e SG são 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

21 Capítulo 1: Construção de Redes de Voz sobre IP 31 linhas. Também há mensagens de auditoria, para que o CA verifique o estado atual das ligações. As mensagens definidas pelo MGCP, trocadas entre o CA e os MGs são divididas em duas categorias: comandos e respostas. Uma notificação 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 implementação livre do MGCP é o OpenMGCP 5, de código aberto MEGACO/H O MEGACO [38] é uma proposta de implementação concorrente do MGCP e foi definido em conjunto pela IETF e a ITU como uma evolução do MGCP. Ele é baseado em mensagens com a sintaxe ASN.1, que também é 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 são consideradas as interações entre os Media Gateways (MGs) e o Media Gateway Controller (MGC). É voltado para conexões de voz e de fax entre redes PSTN-IP e IP-IP Dificuldades de Implantação e Firewall O texto abaixo se refere ao uso de VoIP com Firewalls e NATs (Network Address Translator), e foi extraído da dissertação de mestrado intitulada Avaliação de Desempenho de Aplicações VoIP P2P, redigida por Rodrigo Barbosa [39]. Na arquitetura original da Internet, cada nó possui ao menos um endereço IP único e pode se comunicar diretamente com qualquer outro nó. Devido ao crescimento da Internet e a conseqüente escassez de endereços IPs, essa arquitetura foi substituída por um novo esquema [40]. Nessa nova estrutura, além dos nós alcançáveis publicamente, há nós com endereços privados (não roteáveis), apenas visíveis pelos nós de sua própria rede. O acesso dos nós privados à Internet é realizado através de um intermediário denominado NAT [41], que de maneira transparente, altera o endereço IP de origem do nó privado para um endereço IP de origem diferente, que seja roteável na Internet. Para se obter uma idéia da disseminação dos sistemas intermediários NAT, o grupo illuminati, em Julho de 2006, a partir de traces coletados de diferentes localidades da Internet, em sua análise reportou a estatística que 73,46% dos nós analisados estavam atrás de NAT [42]. A maior parte dos NATs implementam mecanismos de rastreamento de conexões (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 pública para rede privada quando houve anteriormente pelo menos um pacote desse fluxo saindo da rede privada para rede pública. Dessa forma a comunicação de uma máquina na rede pública com uma máquina na rede privada só é possível quando esta inicia o processo de comunicação Website do Netfilter/iptables,

22 32 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos A forma como os protocolos de voz sobre IP foram projetados prejudica a comunicação entre máquinas que se ligam à Internet através de NATs. Em SIP e H.323, as entidades envolvidas na comunicação devem possuir IPs roteáveis, caso contrário a chamada efetivamente não ocorre. Entretanto, com a evolução dos aplicativos de compartilhamento de arquivos em redes peer-to-peer [43], como o KaZaA 7, vieram novas formas de romper a dificuldade da comunicação impostas pelos NATs. Os aplicativos avaliados neste trabalho utilizam as técnicas que seguem. O método mais simples para comunicação através de NATs é chamado de conexão reversa [44], podendo ser usado quando apenas uma das entidades está atrás de NAT. Suponha um cenário em que o nó N esteja atrás de um NAT e o nó P possua um IP público. Para efetivar a comunicação, o nó N inicia a comunicação com nó P e dessa forma, devido aos mecanismos de filtragem e conexão reversa, torna-se possível o envio de pacotes nos dois sentidos. Outro método é com o intermédio de um servidor remoto, que realiza a triangulação do tráfego (relay server) [44]. Suponha um cenário em que dois nós A e B desejam se comunicar utilizando UDP e estejam atrás de NATs distintos. Para efetivar a comunicação, o nó A envia o fluxo de mídia para uma estação com IP público, que por sua vez encaminha o fluxo para B e vice-versa. Atualmente, o grupo de trabalho behave 8 da IETF trabalha na definição do protocolo TURN (Traversal Using Relay NAT) [45], que tem o objetivo de realizar a triangulação de tráfego conforme apresentado. Apesar de ser mais confiável, esse método eleva o atraso na rede e prejudica a interatividade. Para tratar desse problema, as novas aplicações VoIP P2P possuem mecanismos de contorno de NAT que permitem a comunicação direta entre usuários. A técnica de Hole Punching, exaustivamente discutida no trabalho de Ford [44], permite que dois nós atrás de NATs distintos estabeleçam uma comunicação direta. A idéia fundamental da técnica é que os dois nós atrás de NAT primeiramente se conectem a um terceiro, visível na Internet, conhecido como rendevouz server. Uma vez que as informações de estado das conexões estejam estabelecidas, os dois nós passam a se comunicar diretamente, esperando que os dispositivos que realizam NAT guardem os estados das conexões UDP, apesar do fato de os pacotes virem de máquinas diferentes ao rendevouz server. Esse mecanismo só é possível quando os NATs são do tipo cone, que sempre mapeiam uma 2-tupla (IP privado, porta privada) na mesma 2-tupla (IP público, porta pública). Para melhorar o mecanismo de travessia de NAT, Algumas aplicações usam a técnica de Hole Punching associada a protocolos que permitem às aplicações descobrirem a presença e tipos de NATs entre elas e a Internet pública. O mais conhecido é o STUN (Simple Traversal of UDP through NATs) [46], também definido pelo grupo de trabalho behave da IETF. Outro problema comumente enfrentado pelas aplicações são as barreiras de controle e proteção que inspecionam o tráfego de dados entre os usuários finais e a Internet, denominado de firewalls. Seu objetivo é permitir somente a transmissão e a 7 Website do KaZaA, 8 Website do Behavior Engineering for Hindrance Avoidance (behave),

23 Capítulo 1: Construção de Redes de Voz sobre IP 33 recepção de dados autorizados. A fim de passar pelo bloqueio desses mecanismos, as aplicações VoIP tentam burlar a barreira simulando o comportamento de aplicações toleradas pelo firewall. O Skype, por exemplo, permite utilizar a porta 80 na comunicação, reservada para serviços web, geralmente permitida pelos firewalls. 1.5 Gerenciamento de Qualidade de Serviço Caso uma infra-estrutura de rede IP seja compartilhada entre aplicações VoIP e aplicações de outros tipos de serviço (e.g., dados), é importante utilizar algum mecanismo que garanta o bom desempenho da rede para a aplicação de VoIP. Por este motivo, abordaremos aqui soluções de qualidade de serviço para a infrestrutura de rede Arquiteturas de Qualidade de Serviço 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 não foi criada para lidar com altas taxas de congestionamento nem garantias de serviço. Com o crescimento da Internet como uma rede comercial mundial, diversos esforços foram feitos para resolver questões como contabilidade e previsibilidade do serviço. Algumas arquiteturas foram propostas para lidar com qualidade de serviço (QoS). Um serviço na Internet pode ser definido de acordo com o nível requerido de algumas métricas para obter o funcionamento desejável. As métricas mais comumente usadas são as seguintes: Atraso o tempo que um pacote leva para ir da origem ao destino. Pode ser definido como atraso máximo, atraso médio ou ainda como atraso máximo para uma determinada porcentagem dos pacotes. Jitter a variação no atraso. Alguns serviços (especialmente aqueles de streamimg de mídia, e.g., rádio na Internet) não são significativamente afetado pelo atraso, mas sofrem bastante perda de qualidade com a variação desde atraso. Taxa a taxa (erroneamente chamada de largura de banda) requerida pelo serviço. Pode ser definida pelo mínimo necessário, pelo máximo que será usado (taxa de pico) e/ou pela média. 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 variável de bits (Variable Bit Rate - VBR), taxa disponível de bits (Available Bit Rate - ABR) e taxa desconhecida de bits (Unspecified Bit Rate - UBR). Perda a taxa de perda que é aceitável para o serviço, normalmente calculada como uma porcentagem dos pacotes com erro/perdidos no caminho (Path Error Rate - PER).

24 34 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Essas são as métricas mais relevantes usadas para qualidade de serviço, mas muitas propostas usam apenas um subconjunto delas e algumas não as usam explicitamente, fazendo apenas uma garantia genérica. O grupo de trabalho IP Performance Metrics (IPPM) da IETF 9 discutiu e documentou essas e outras métricas e como elas podem ser medidas [48][49][50]. O serviço padrão oferecido pela Internet sem suporte a QoS é conhecido como Melhor Esforço (Best-Effort BE). Este serviço não traz nenhuma garantia baseada em qualquer métrica; somente a garantia implícita de que os roteadores farão todo o possível para entregar os pacotes. Assim, todos os pacotes recebem o mesmo tratamento, e pacotes transportando qualquer tipo de informação, de qualquer conexão, pode ser descartado devido a congestionamento ou falha na camada física Serviços Integrados Como a primeira proposta feita pelo Grupo de Trabalho de Rede (Network Working Group) da IETF, a arquitetura de Serviços 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 idéia por trás do IntServ é que não é possível dar garantias de QoS sem fazer uma reserva de recursos explícita. Além de oferecer o serviço BE (melhor esforço), a arquitetura IntServ também oferece dois outros tipos de serviço: Serviço de QoS Garantido [52] provê garantias firmes de taxa e atraso de uma conexão, desde que a conexão respeite o perfil de tráfego solicitado. Uma conexão desse tipo só pode ser aceita após a verificação de que a rede é capaz de implementar o serviço (controle de admissão). Este comportamento é comparável ao serviço de linha dedicada, e cada conexão requer gerenciamento de informação de estado em cada roteador. Portanto, foi considerado impossível escalar a arquitetura IntServ para implantação em toda a Internet, onde alguns roteadores servem milhões de conexões simultaneamente, tornando o processamento de tantas informações de estado algo muito caro, se não impossível. Serviço de Carga Controlada [53] não provê garantias firmes, os pacotes são tratados como se em uma rede de melhor esforço com baixa carga. A maioria dos pacotes será entregue com sucesso e não sofrerá atraso maior que o mínimo possível, desde que o tráfego submetido pela conexão esteja de acordo com o perfil acordado. Este serviço foi criado para suportar muitas aplicações na Internet que não precisam de garantias firmes, mas que não funcionam em uma rede altamente congestionada. Assim como no serviço de QoS garantido, cada conexão precisa usar informação de estado nos roteadores ao longo do caminho. O IntServ é um arcabouço de implementação com quatro componentes: Protocolo de Sinalização um protocolo usado para fazer a reserva de recursos no caminho desejado. Intserv foi projetado para trabalhar em 9

25 Capítulo 1: Construção de Redes de Voz sobre IP 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 Serviços Integrados, a literatura freqüentemente se refere à arquitetura IntServ/RSVP. Rotina de Controle de Admissão é responsável pela verificação de recursos suficientes para garantir um serviço requisitado e deve ser utilizada somente durante o estabelecimento da conexão ou durante sua reconfiguração. Classificador de Pacotes classifica cada pacote que passa por um roteador para decidir que serviço 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 são feitas pelo receptor e são válidas for um tempo limitado, sendo continuamente refeitas até o final da conexão. 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]. Após o receptor requisitar uma transmissão do emissor, o emissor manda de volta uma mensagem PATH, que irá descrever o perfil de tráfego necessário e gravar informação 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 recepção da mensagem, o receptor manda de volta uma mensagem RESV, que irá transitar pelo caminho reverso (e não pelo caminho escolhido pelo protocolo de roteamento), reservando recursos da conexão. 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 freqüência tal que a perda de uma mensagem não irá permitir, erroneamente, a remoção da conexão [51].

26 36 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Serviços Diferenciados A arquitetura de Serviços Diferenciados (DiffServ) [56] foi proposta pelo Grupo de Trabalho de Rede quatro anos após o IntServ com o objetivo principal de resolver os problemas de escalabilidade do mesmo. Aqui, roteadores não guardam estado de conexões nem trocam informações de sinalização. Assim, os requisitos de memória e processamento dos roteadores e de carga de controle da rede são muito menores e mais fáceis de se lidar. A idéia principal do DiffServ é que os serviços podem ser definidos em classes, e todas as aplicações que requerem um determinado serviço serão tratadas da mesma forma. Os pacotes são marcados utilizando um campo que não era utilizado no cabeçalhos IP (o campo Type of Service TOS [57] agora chamado de DiffServ Code Point DSCP [58]), o que não irá alterar o cabeçalho do protocolo nem afetar sistemas legados que ignoram o campo. O tratamento dado aos pacotes é chamado Per Hop Behavior (PHB). Além do uso do PHB de melhor esforço (PHB BE), o DiffServ tem duas definições oficiais de PHB: O grupo de PHBs de Encaminhamento Assegurado (Assured Forwarding AF) [59] foi definido para tratar diferentes tipos de tráfego com garantias relativas entre si. São quatro classes AF, cada uma com três precedências (total de 12 combinações). Foi desenvolvido para o uso de um mesmo serviço dentro de uma classe, onde os pacotes mais importantes têm uma prioridade maior sobre os pacotes menos importantes e são diferenciados pela marcação. As classes não têm ordem precedência entre si. O PHB de Encaminhamento Expresso (Expedited Forwarding EF) [60] garante que pacotes nesta classe não serão descartados e que o seu atraso e jitter serão muito próximos ao mínimo possível, caso o tráfego submetido esteja de acordo com o perfil configurado. Deve funcionar como uma linha dedicada. O PHB de melhor esforço, embora não oficialmente especificado, representa o serviço já em funcionamento na Internet e às vezes é chamado de PHB padrão. No DiffServ, nenhuma garantia é feita para o PHB BE, exceto a garantia de que os roteadores farão todo o possível para entregar os pacotes corretamente e que todas as conexões deste tipo serão tratadas igualmente, sem diferenciação. A arquitetura DiffServ tem os seguintes elementos: O Domínio DiffServ é uma rede com o DiffServ habilitado. O Roteador de Núcleo (Core Router CR) é um roteador com DiffServ configurado e que pode tratar os pacotes de acordo com PHBs seguindo a marcação DSCP deles. O Roteador de Borda (Edge Router ER) tem as mesmas funcionalidades do CR, além de classificação, marcação, reforçamento de política e moldagem de tráfego (shaping). Um ER deve ser usado na

27 Capítulo 1: Construção de Redes de Voz sobre IP 37 borda de um Domínio DiffServ para a troca de tráfego com outras redes (sejam DiffServ ou não). O Corretor de Banda (Bandwidth Broker BB mais uma vez o termo banda é utilizado incorretamente) faz contratos de serviço com usuários finais e com BBs de outros Domínios DiffServ para requerer serviço. Não é obrigatório para um Domínio DiffServ e não foi totalmente especificado. Não há protocolo padrão para a comunicação dos BBs, apenas uma sugestão que limita o uso de DiffServ a alguns poucos serviços [61]. Um Contrato de Nível de Serviço (Service Level Agreement SLA) é um contrato feito entre duas redes com donos diferentes. Pode ser um contrato físico (documento em papel) ou virtual (documento assinado digitalmente usando um BB). Um SLA deve definir garantias de serviço, método de cobrança, contingências e penalidades (em caso de quebra de contrato por uma das partes) Multiprotocol Label Switching (MPLS) Embora não seja uma arquitetura de QoS, o Multiprotocol Label Switching (MPLS) pode ser usado para trazer algum nível de QoS para a rede com a comutação de rótulos. O MPLS é um esquema de encaminhamento de pacotes que quebra e melhora a estratégia de encaminhamento nó-a-nó usada na Internet, criando uma separação clara entre roteamento e encaminhamento. Ele trabalha entre a camada dependente do meio físico (ou camada de enlace, no modelo de referência OSI [41]), acrescentando um cabeçalho aos pacotes e atribuindo um rótulo neste cabeçalho para permitir o encaminhamento. MPLS domain Add label Change label Remove label FTN mapping ILM mapping FEC NHLFE NHLFE NHLFE label NHLFE NHLFE NHLFE Figura 15. Encaminhamento de pacotes e troca de rótulos em MPLS O MPLS usa Label Switched Paths (LSP), o que resulta num maior controle de para onde os pacotes estão sendo encaminhados. Os roteadores MPLS são chamados de Label Switched Routers (LSR). O LSR mantém alguma informação de estado sobre os caminhos, mas nenhuma informação sobre as conexões passantes, o que torna o protocolo bem mais escalável que o IntServ. Os rótulos são definidos por enlace e

28 38 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos podem ser agrupados em classes de equivalência (Forwarding Equivalence Classes FECs). Assim, as tabelas de encaminhamento não crescem muito. Novos rótulos podem ser definidos após uma requisição de engenharia de tráfego ou de mudanças de roteamento e também podem ser definidos sob demanda devido a um novo caminho solicitado por uma nova conexão. As tabelas de encaminhamento consistem de entradas de próximo nó (Next-Hop Label Forwarding Entries NHLFEs). Estas mapeiam rótulos de entrada em interfaces de saída e novos rótulos; e são chamadas de Incoming Label Mapping (ILM). Domínios MPLS interagem com domínios não-mpls através do uso de mapas FEC-to-NHLFE (FTN) para rotular pacotes ainda não rotulados e para remover os rótulos desnecessários nos LSRs de borda (veja a Figura 15) Uso de QoS para Redes VoIP e Redes Híbridas O serviço de VoIP foi pensado para auxiliar na convergência de redes. Dessa forma, imagina-se que o natural seja que com o tempo os serviços de voz irão passar de redes de comutação de circuito para redes IP, compartilhando a infra-estrutura com outros serviços (inclusive de acesso à Internet). Tal rede convergente tem duas abordagens para uma implementação adequada: ou utiliza alguma estratégia de QoS, de forma a garantir que o tráfego prioritário receberá o devido tratamento, ou utiliza a estratégia de superprovisionamento, garantindo assim que não haverá congestionamento capaz de deixar um tráfego nãoprioritário influenciar na qualidade de um tráfego prioritário. Não se vê, entretanto, nenhuma rede adotando uma arquitetura de QoS. O software Netmeeting da Microsoft (que acompanha as versões mais recentes do Windows), utiliza o RSVP para mensagens de reserva de serviço. Essas mensagens, entretanto, são ignoradas pela maioria dos roteadores em uso atualmente. Algumas aplicações de usuário utilizam a marcação de pacotes requerida para o DiffServ, mas também os roteadores não estão configurados para tratá-las. Por fim, o MPLS é bastante usado em backbones, mas somente para auxiliar a engenharia de tráfego, sem diferenciação entre as aplicações. A rede FastWeb 10, na Itália, já utiliza comercialmente, desde outubro de 2000 [62] uma infra-estrutura única para oferecer serviços de acesso à Internet (por ADSL e por FTTH), VoIP e VoD (IPTV). Esta rede utiliza a estratégia de superprovisionamento. Um estudo foi realizado para verificar a qualidade das conexões de voz da rede FastWeb, e o resultado foi satisfatório [62]. Entretanto, a rede tem características bastante limitadas, este estudo não significa que o problema de utilizar VoIP em redes convergentes já está resolvido. Em primeiro lugar, porque a rede só tem alcance nacional na Itália, e portanto não tem enlaces muito distantes (o que poderia acarretar num maior atraso). Em segundo, porque o tráfego de VoIP não passa para outras redes, toda comunicação destinada a telefones fora da rede atravessam gateways que convertem o sinal para comutação de circuito (telefonia tradicional) e assim permanecem até o destino. 10

29 Capítulo 1: Construção de Redes de Voz sobre IP Medição e Monitoramento As métricas utilizadas para avaliar a qualidade da voz na telefonia convencional já se encontram consolidadas e são especificadas na recomendação G.712 [18], baseada na relação sinal-ruído. Entretanto, o novo cenário onde VoIP está inserido traz a necessidade de se adotarem novas metodologias e métricas para se avaliar a qualidade da voz, uma vez que numa rede de pacotes há outros parâmetros que influenciam o desempenho das aplicações em tempo real, tais como: atraso, jitter, eco, perda de pacotes e codecs diferentes. Esta subseção apresenta, em primeiro lugar, métodos para inferir qualidade de voz. Por fim, são discutidas técnicas e ferramentas para monitorar e contabilizar chamadas Medindo Qualidade de Voz Uma forma de avaliação da qualidade da conversação é o MOS (Mean Opinion Score). Esta é uma avaliação subjetiva, resultante da opinião de usuários de um sistema de conversação em um ambiente controlado. Nos últimos anos, fizeram-se esforços com a finalidade de desenvolver modelos que quantifiquem a qualidade da voz percebida pelo ser humano utilizando recursos computacionais. Essa é uma avaliação objetiva, cuja implementação é mais rápida, barata e simplificada, quando comparada à metodologia subjetiva, que será detalhada no texto que segue MOS (P.800) Uma das primeiras abordagens para avaliação da qualidade da voz foi a utilização do MOS (Mean Opinion Score), método subjetivo definido nas Recomendações ITU-T P.800 [19] e ITU-T P.830 [20], pelo qual um conjunto de avaliadores ouvintes atribuem uma pontuação de 1 (pobre) a 5 (excelente) à qualidade da fala reproduzida pelo sistema de comunicação em teste. A P.800 contém sugestões para condução de testes subjetivos de qualidade de transmissão da voz em laboratório. Os métodos indicados têm aplicações genéricas, qualquer que sejam os fatores presentes de degradação. Exemplos desses fatores são: perda, ruído de circuito, erros de transmissão, ruído de ambiente, eco, distorção não linear, tempo de propagação. Combinações de dois ou mais desses fatores também são considerados. Há três métodos descritos na recomendação P.800 para obtenção do MOS: testes de opinião por conversação, testes de opinião por escuta e testes por entrevistas e inspeção. Os testes de conversação pretendem, na medida do possível, reproduzir as condições dos atuais serviços de telefonia, experimentados pelos usuários. É importante

30 40 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos que as condições 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, além de registros de saída fidedignos, para cada teste. Para execução desse tipo de teste, duas pessoas são colocadas em cabines distintas a prova de som, próximas do ponto onde o experimento é controlado. O volume do local não deve ser menor que 20 m 3, com um tempo de reverberação 11 menor que 500 ms (normalmente na faixa de ms), para os casos de uso de sistemas do tipo aparelho telefônico. Para sistemas handsfree, a sala não deve ser menor que 30 m 3. As cabines devem ser decoradas recriando um ambiente natural. Os participantes desse tipo de teste devem ser pessoas usuárias de telefone, escolhidas ao acaso. Não podem estar envolvidas com atividades de medida de desempenho de sistemas telefônicos, ou trabalharem com assuntos relacionados à codificação de voz. Além disso, essas pessoas não podem ter participado de testes subjetivos há pelo menos seis meses, e em testes de conversação há pelo menos um ano. Os participantes pontuam a experiência seguindo os valores: Excelente = 5; Bom = 4; Regular = 3; Pobre = 2 e Ruim = 1. A média aritmética dos valores atribuídos é denominada pontuação de opinião de conversação, e representada pela simbologia MOS. Os testes de opinião por escuta têm uso direto na qualificação de sistemas de transmissão que sejam essencialmente unidirecionais. Os resultados obtidos por esse tipo de teste podem ser usados, com alguma reserva, na qualificação de conversações sobre sistemas bidirecionais, como a rede pública telefônica. Nesses testes de opinião por escuta não é esperado obter o mesmo padrão de realismo como o alcançado nos testes de conversação. O método de teste mais recomendado para opinião em escuta é o ACR (Absolute Category Rating), sendo bastante estável e com aplicação em conexões telefônicas analógicas e digitais. Outros métodos como DCR (Degradation Category Rating), Quantal-Response Detectability Method, CCR (Comparison Category Rating) e Threshold Method, também são usados. No método ACR são descritos os diversos procedimentos para gravação e escuta que devem ser seguidos. A fim de eliminar variações indesejáveis na fonte da fala, as amostras devem ser obtidas respeitando-se os seguintes critérios: ambiente de gravação, sistema de envio, sistema de gravação, fala (sentenças curtas e simples) e o procedimento de gravação. A reprodução das escuta também segue alguns critérios: ambiente de escuta, sistema de escuta, ouvintes, escala de opinião utilizada. No método de testes por entrevistas e inspeção a qualidade de transmissão pode ser determinada por observação de serviço, quando o grande esforço imputado a este tipo de teste é viável, em face de importância do caso considerado. Recomendações de como proceder, incluindo os tipos de perguntas aos usuários, são indicadas na Recomendação P.82. Para obter um alto grau de precisão são necessárias o mínimo de 100 entrevistas. A desvantagem desse método é o pequeno controle que é possível ter, 11 O tempo de reverberação indica a demora verificada entre a emissão de um determinado som e esse som tornar-se inaudível

31 Capítulo 1: Construção de Redes de Voz sobre IP 41 por vários aspectos, sobre detalhes das características das conexões telefônicas testadas. Entretanto, consegue-se ter uma apreciação global sobre o desempenho do sistema num ambiente real Modelo-E Embora o resultado obtido pelo MOS seja bastante significativo, a dificuldade de realizar tal avaliação em larga escala motivou o desenvolvimento de técnicas objetivas para o cálculo do MOS. Um dos métodos objetivos é o Modelo-E [63][64], desenvolvido pela ITU em O Modelo-E implementa um mecanismo baseado na soma de termos que representam distorções na qualidade da voz, tais como atrasos de transmissão, eco e distorções introduzidas pelos equipamentos utilizados. O resultado do modelo é o fator escalar R, variando de 0(péssimo) a 100(excelente). O fator R pode ser convertido para escala de pontuação MOS através das seguintes expressões: Para R < 0: MOS = 1 Para 0 R 100: MOS = 1+ 0,035 R 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 não são recomendáveis, sendo desejável obter R > 70. TABELA 1. Conversão entre o Fator R e o MOS Fator R MOS Satisfação do usuário 90 R < 100 4,34 4,50 Muito satisfeitos 80 R < 90 4,03 4,34 Satisfeitos 70 R < 80 3,60 4,03 Alguns insatisfeitos 60 R < 70 3,10 3,60 Muitos insatisfeitos 0 R < 60 1,00 3,10 Quase todos insatisfeitos PESQ (P.862) Conforme discutido, para se obter o fator R, do Modelo-E, é necessário a coleta de diversas informações técnicas relacionadas à chamada, como por exemplo, detalhes do codec e condições de rede. Uma vez que em diversas situações, esse detalhes não são conhecidos, existe a necessidade de se calcular a qualidade de voz com base na comparação entre o áudio falado ou transmitido e o escutado ou recebido. No mesmo ano do Modelo-E, a ITU propôs o Perceptual Speech Quality Measurement (PSQM) [65], que estima o MOS de uma comunicação com base na

32 42 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos comparação 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 características do PSQM e do PAMS e melhorando os algoritmos de forma a atender uma gama maior de cenários (como cenários com ocorrência de jitter). A medida de qualidade objetiva do PESQ é obtida apenas em testes de escuta ACR. Este método apresenta precisão aceitável em seus resultados, quando a clareza da voz é afetada pelos seguintes processos ou parâmetros: Codecs de forma de onda (exemplos: G.711, G.726 e G.727); Codecs paramétricos e híbridos (a partir de 4 kbps) incluindo aqueles de múltiplas taxas de transmissão (exemplos: G.728, G.729 e G.723.1); Transcodificações (conversão de um formato digital para outro); Nível do sinal de entrada no codec; Erros no canal de transmissão; Efeitos da variação do atraso em testes apenas de escuta; Perda de pacotes/células com codecs paramétricos e híbridos Ruído ambiente no lado transmissor; Taxa de transmissão nos casos de codecs com mais de um modo de operação; Deformações temporais do sinal de áudio. No PESQ não se pretende mensurar o impacto ou não existe precisão nas medidas afetadas pelos seguintes processos ou parâmetros: atraso (cancelado pelo alinhamento de tempo), níveis de escuta e ganho/atenuação total no sistema (é cancelado pelo alinhamento de nível), eco percebido pelo orador e o som da própria voz do orador ouvido por retorno no fone. Por outro lado, não se conhece o impacto dos itens abaixo, nos resultados medidos pelo PESQ: perda de pacotes/células com codecs de forma de onda, cortes (clipping) temporal e de nível, dependência de orador, múltiplos oradores simultâneos, diferença entre as taxas de transmissão do codificador e do decodificador, música como sinal de entrada, eco percebido pelo ouvinte e codecs paramétricos ou híbridos com taxa inferior a 4 kbps Medindo jitter e perdas de pacotes As definições utilizadas de jitter e perda de pacotes estão conforme as elaboradas pelo IP Performance Metrics Working Group (IPPM) 12 e são apresentadas na RFC 3393 [68] e RFC 2680 [69], respectivamente. O IPPM é um grupo de trabalho da IETF que produz documentos que definem métricas específicas, 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 variação (média e máxima) no atraso dos pacotes. 12

33 Capítulo 1: Construção de Redes de Voz sobre IP 43 Para o cálculo de métricas em função do tempo é necessário verificar a qualidade dos mecanismos de operação do relógio nas máquinas usadas para capturar o tráfego. Cada relógio possui um erro intrínseco, que é como o comportamento do relógio difere de um relógio de referência (ideal). Esse erro pode ser em fase (e.g., um determinado relógio está 2,54s atrasado em relação a um relógio de referência, em um dado instante) ou em freqüência (e.g., a cada dia um determinado relógio atrasa 4.50s em relação a um relógio de referência) [70]. Em princípio, dado que os atrasos da rede são imprevisíveis, supõe-se que é absolutamente necessário garantir que os relógios das máquinas que coletam o tráfego estejam sincronizados. Entretanto, utilizando o método proposto por Barbosa [71], o cálculo do jitter independe da sincronização de relógios Monitoramento e Contabilização Assim como ocorre com telefonia tradicional, a telefonia VoIP também necessita de mecanismos de monitoramento das chamadas, seja para avaliação da qualidade da aplicação VoIP ou para contabilização de uso dos serviços. Nesse contexto, temos a utilização do protocolo Radius (Remote Authentication Dial-In User Service) [72], o qual é um padrão do IETF para autenticação de usuários em um serviço de acesso discado, e para a contabilização dos recursos consumidos durante as conexões. 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 informações são disponibilizadas também em MIBs (Management Information Base), as quais podem ser coletadas através do protocolo SNMP (Simple Network Management Protocol). Outra opção é a transmissão direta para um banco de dados SQL. A CESNET 13, rede de ensino e pesquisa da República Tcheca, implementou uma infra-estrutura de monitoração e contabilização de chamadas VoIP por meio de utilização de servidores RADIUS [73], e coleta de CDRs (call detail record) emitidos por gateways de voz. Um CDR é um arquivo contendo informações sobre uma chamada, tais como: origem, destino, duração 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 usuário. Em [74], é apresentada uma arquitetura denominada Enterprise Call Analysis System (ECAS), também baseada na coleta e análise de CDRs gerados por gateways de voz. AS duas soluções apresentadas não permitem a monitoração da qualidade das chamadas realizadas entre telefones IP. Em [75], assim como em diversos produtos comerciais [76][77][78], foi adotada uma solução de monitoramento passivo, conforme descrito no item Os resultados dessas análises são apresentados na forma de relatórios com o nível de qualidade atingida pelo sistema. Esta solução nem sempre é aplicável, seja pelo uso de criptografia 13

34 44 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos que impede a análise das chamadas, ou pela natureza de tráfego 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 Telecomunicações 14 (GPRT) do Centro de Informática 15 (CIn) da Universidade Federal de Pernambuco já realizou diversas atividades práticas com algumas tecnologias de VoIP. Nesta seção descreveremos as mais importantes Implementação de Protocolos H.323 e SIP O GPRT, em parceria com uma empresa brasileira fabricante de equipamentos de telefonia, fez a implementação do protocolo H.323 para uso em PCs e do protocolo SIP para uso em um módulo de uma central telefônica, tornando-a capaz de fazer ligações de VoIP. Estas implementações trouxeram um grande conhecimento sobre os protocolos e permitiram ententer diversos aspectos de interoperabilidade entre equipamentos de fabricantes diferentes H.323 No caso da implementação de H.323, as diferentes versões do protocolo trazem algumas incompatibilidades, de forma que nem todas são compatíveis entre si. Posto isto, um software que pretende ser compatível com os mais diversos equipamentos que implementam o protocolo H.323 precisa implementar diversas versões 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 versões de protocolo e informações sobre que partes estão implementadas, é possível inferir a compatibilidade entre equipamentos. Mas como essa informação não é disponibilizada pelos fabricantes, na prática, 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 execução) de ASN.1 ou criando um código que acessa diretamente os bits das mensagens para interpretar seus campos. Embora isso torne o código mais eficiente, também torna-o avesso a atualização do protocolo. Ao implementar o H.323 é fundamental implementar o H.225 (a parte de sinalização de chamada e, se necessário, comunicar-se com um Gatekeeper, a parte RAS), o H.245 (para sinalização de controle) e parte do Q.931 (originalmente criado para redes ISDN). Além, obviamente, dos protocolos RTP/RTCP e de métodos para lidar com problemas de rede (e.g., jitter, buffer, interpretação do RTCP)

35 Capítulo 1: Construção de Redes de Voz sobre IP 45 A biblioteca de código aberto OpenH323 16, criada pela comunidade internacional, implementa diversas versões do protocolo H.323, com o objetivo de ser o mais completa possível. Sua implementação, 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 memória e processamento. Dessa forma, esta biblioteca não é usada para sistemas embarcados (telefone IP, placa de telefonia, etc), somente para PCs. Uma outra biblioteca de código aberto, a OOH323c 17, implementa o compilador ASN.1 e uma pequena máquina de estados de H.323. Uma versão inicial desta biblioteca é mais eficiente para uso em sistemas embarcados, mas as versões posteriores foram criadas já de forma menos eficiente, aumentando o consumo de memória e processamento, mudando o foco para também ser mais completa. A versão inicial, por sua vez, não implementa diversas partes importantes (mas opcionais para uma ligação VoIP simples) do protocolo Asterisk O Asterisk é um Software Livre, portanto de código aberto, que implementa em software os recursos encontrados em um PABX convencional, utilizando tecnologia de VoIP. Inicialmente desenvolvido pela empresa Digium, hoje recebe contribuições de programadores ao redor de todo o mundo. O Asterisk utiliza protocolos como SIP, MGCP, IAX e H.323 para realizar a sinalização das chamadas telefônicas na rede IP. É possível utilizar o Asterisk como Media Gateway, entre a rede de telefonia pública e a rede IP (com auxílio de hardware especial), como Unidade de Resposta Audível (URA) ou Media Server, tocando mensagens pré-programadas ou com interatividade via DTMF, como música de espera ou sistema de auto-atendimento. Pode ser utilizado também 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 telefônica na forma de um circuito de voz digital, possibilitando o uso de várias combinações de codecs e protocolos de comunicação. Entre os canais que o Asterisk suporta podemos encontrar os seguintes [79]: Agent: Um canal de agente Distribuição Automática 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 implementações. IAX e IAX2: Inter-Asterisk Exchange Protocol, o próprio protocolo do Asterisk. MGCP: Media Gateway Control Protocol, outro protocolo de VOIP. Modem: Usado para linhas ISDN

36 46 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 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 telefônicas para placas da Voicetronix. ZAP: Para conectar telefones e linhas com placas da Digium. Também usado para TDMoE (TDM sobre Ethernet) e para o Asterisk zphfc (ISDN em modo NT). Unicall: Usado para linhas digitais com sinalização E1/R2. A licença utilizada pelo Asterisk é dupla, sendo a primeira a GNU General Public License (GPL), para a parte do software gratuito, e a segunda a licença de softwares proprietários, de forma a permitir o uso de código fechado e patenteado, como o codec G.729, em conjunto com o sistema. Originalmente desenvolvido para executar sobre o Linux, o Asterisk atualmente suporta vários outros sistemas operacionais, como OpenBSD, FreeBSD, Mac OS e Solaris, além de hoje ser possível executá-lo em Windows. Figura 16. Arquitetura do Asterisk [79]. Algumas funcionalidades disponíveis no Asterisk estão disponíveis apenas em PBXs proprietários bastante caros, além de ser possível a criação 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. Também é possível adicionar módulos escritos em linguagem C para várias das APIs disponíveis, como pode ser visto na Figura 16, que descreve a arquitetura do Asterisk.

37 Capítulo 1: Construção de Redes de Voz sobre IP 47 Para acoplar telefones comuns ou conectar linhas telefônicas da rede pública (e troncos) a um servidor Asterisk, é necessário o uso de hardware adicional. A Digium e outras empresas especializadas fabricam placas no padrão PCI que podem ser usadas para conectar linhas E1, T1 ou serviços telefônicos digitais e analógicos. Capaz de operar com a maioria dos telefones SIP, atuando como servidor de registro ou gateway, o Asterisk também suporta uma vasta gama de protocolos de Voz sobre IP, e tem se tornado referência da indústria de telefonia VoIP para testes de interoperabilidade. Os desenvolvedores do Asterisk também desenvolveram um novo protocolo, denominado IAX (Inter-Asterisk exchange) para aumentar a eficiência do roteamento de chamadas em PBXs Asterisk. Com esta mescla de suporte a serviços de telefonia tradicional e VoIP, o Asterisk permite que provedores de soluções telefônicas migrem de PBXs proprietários, além de facilitar a adição de serviços e possibilitar redução de custos, principalmente para chamadas de longa distância SER O SER (SIP Express Router) é um servidor freeware, desenvolvido pelo instituto nacional de pesquisa alemão Fraunhofer Fokus 18. Suas principais características são a implementação do protocolo SIP (Session Initiation Protocol), a alta performance, ser configurável e rodar nos sistemas Linux, BSD e Solaris. Além disso, anuncia a presença de usuários, envia e recebe mensagens e mantém qualquer tipo de sessão, incluindo jogos e chat. Inclui também 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 implementações de serviços variados. Por exemplo, pode atuar como registro de utilizadores e servidor de localização para prover mobilidade aos usuários. Pode também ser utilizado como elemento de controle de acesso, o qual armazena informações sobre gateways PSTN ou outros recursos SIP mais reservados. Pode ser facilmente estendido usando a sua configuração de línguas e suporte para módulos plugin embutidos. Tem vários plug-ins disponíveis, entre eles, gateways SMS (Short Message Service), gateways SIMPLE2Jabber, autenticação e contabilização via RADIUS, LDAP (Lightweight Directory Access Protocol) [80], ENUM [81], entre outros. Possui ainda uma interface de aplicação que permite um fácil acoplamento com outras aplicações que não funcionam com SIP fone@rnp (GT-VoIP RNP) Em 2003 foi aprovado um projeto piloto da UFRJ para pesquisar a possibilidade de implantação de VoIP na Rede Nacional de Pesquisa (RNP), interligando instituições conectadas à RNP. Um dos objetivos do projeto era utilizar parte da capacidade ociosa da rede para permitir às instituições a realização de chamadas VoIP entre si, de forma a 18

38 48 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos economizar custos com telefonia. A idéia era que as instituições pudesse também fazer ligações para a rede pública (PSTN) de outros estados através da RNP. Para isto, a RNP solicitou uma licença especial da ANATEL que permitisse à RNP implementar tal serviço. Esta licença, porém, não permitia à RNP completar uma ligação originada na PSTN e destinada à PSTN de outra cidade, de forma a não concorrer com as operadoras de longa distância e o uso ser somente acadêmico. O projeto foi aprovado e o serviço fone@rnp 19 está em pleno funcionamento. Já conta com diversas instituições conectadas, atingindo (em Março/2007) 16 das 26 capitais e também o distrito federal. O fone@rnp está também interligado com instituições em outros países (e.g.: Austrália, Estados Unidos, México e República Tcheca), de forma que as instituições podem ligar entre si e algumas instituições permitem que outras completem ligações para a rede pública de sua cidade. Neste caso, a instituição responsável pelos custos da interligação com a rede pública é a instituição que faz a terminação da ligação, não a que inicia a chamada. Embora esse modelo de cobrança parece injusto e completar ligações para a rede pública é uma opção da instituição, não é obrigatório. Ainda assim, todas as instituições que o adotaram estão satisfeitas com o mesmo, pois a economia de custos com as ligações de longa distância realizadas, em todas elas, é muito superior ao custo gerado por completar ligações locais para as outras instituições. O serviço é baseado em H.323 e cada instituição tem a opção de utilizar infraestrutura SIP (ou qualquer outra) internamente (algumas o fazem). A comunicação entre as instituições utiliza, obrigatoriamente, o H.323. O plano de discagem foi criado para contemplar ligações em todos os níveis (institucional, local, nacional e internacional). Assim, cada instituição conectada tem um Gatekeeper para fazer a autenticação e a autorização dos usuários da instituição e a RNP tem um Directory Gatekeeper (DGK), que consiste em um gatekeeper cujos usuários são outros gatekeepers. Os codecs recomendados no fone@rnp são os do protocolo G.711. O G.729 também é usado em alguns equipamentos, mas seu atraso faz com que a qualidade da ligação seja variável quando utilizado XVoice (GT-P2P RNP) O XVoice é um aplicativo de VoIP, sendo um dos resultados do Grupo de Trabalho GT- P2P 20 da Rede Nacional de Pesquisa(RNP), sendo projetado para avaliar o tráfego 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 aplicações no tráfego da RNP. O resultado do projeto, que foi denominado de X-Peer, sendo o XVoice o aplicativo de VoIP desse projeto Último acesso em 15 de Fevereiro de 2006.

39 Capítulo 1: Construção de Redes de Voz sobre IP 49 O X-Peer [82] pode ser considerado uma rede, quando se observam apenas os nós, uma arquitetura P2P, quando se considera a infra-estrutura e um middleware, quando se considera a infra-estrutura oferecida para o desenvolvimento de aplicações P2P. Utiliza o conceito de super-nós, os quais se comunicam através de uma rede estruturada baseada em DHT (Distributed Hash Table), o que lhe permite acessar as informações de qualquer outro nó X-Peer em no máximo log(n) saltos, onde n é o número de super-nós que compõem a rede X-Peer. Essa garantia de localização em uma rede distribuída e hierárquica é um dos grandes diferenciais dessa solução. Além disso, o X-Peer é capaz de suportar várias aplicações P2P em uma única infra-estrutura de rede Características técnicas O levantamento de requisitos para desenvolver o XVoice demandou um estudo sobre o Skype e os protocolos e codecs que são utilizados em aplicações de Voz sobre IP. O XVoice é um aplicativo VoIP que usa a tecnologia peer-to-peer pura. Peer-to-peer é um modelo de comunicação no qual cada nó tem as mesmas capacidades e responsabilidades, e ambos podem iniciar uma sessão de comunicação, contrastando com o modelo cliente/servidor. O XVoice utilizou o SIP como protocolo de sinalização. O SIP tem como principal vantagem a forma simples e compacta das mensagens, sendo baseado no modelo requisição-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 geração de sons e ruídos similares ao sistema de reprodução da voz humana. Possui uma taxa de transmissão de 13 kbps e uma avaliação MOS de 3, Arquitetura do XVoice A rede na qual o XVoice funciona é a X-Peer, uma rede peer-to-peer pura, a qual utiliza os recursos tecnológicos da Rede Nacional de Pesquisa (RNP). Nós Usuários POPs Figura 17. Rede XVoice

40 50 Minicursos: 25º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Os componentes dessa rede são os nós usuários e os POPs (Pontos de Presença) da RNP, que funcionam com o conceito de super-nós, conforme mostrado na Figura Conexão ao XVoice Para acessar o serviço XVoice o usuário precisa se conectar na rede X-Peer. Para tanto, é necessário 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 Presença ou o endereço service.pop-xx.rnp.br, onde xx é o Ponto de Presença, podendo ser: pe, mg, pr, sp. Caso o usuário não esteja cadastrado, após 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 conexão ao X-Peer Skype O Skype 21 é um aplicação VoIP numa rede P2P híbrida, que permite a comunicação telefônica ilimitada entre dois computadores sem nenhuma taxação. É um software free que vem ganhando mercado, principalmente entre usuários que buscam economia em chamadas telefônicas de longa distância nacionais e internacionais. O nome do produto confunde-se com o nome da empresa, que foi desenvolvido pelos criadores do KaZaa 22 em O sucesso do Skype teve nos usuários domésticos o seu grande público. Essa grande massa passou a utilizar a telefonia via Internet em ambientes até então só utilizados para a comunicação através de chats. Segundo Vollenweider [83] 30% dos usuários domésticos usam o Skype em seus ambientes de trabalho. O Skype possui as mesmas funções de outros aplicativos já consagrados (MSN, Yahoo! IM), tais como: troca de mensagens de texto, chamadas de voz e conferência, 21 Último acesso em 15 de Fevereiro de Último acesso em 15 de Fevereiro de 2007.