Codificação e Transmissão de Voz na Internet: um Estudo de Caso sobre o Software SKYPEs

Rogério B. Lourenço

Escola de Engenharia – Universidade Federal Fluminense (UFF) Rua Passos da Pátria, 156. Bloco D, 5o Andar – 24.210-240 – Niterói – RJ – Brasil

Laboratório de Pesquisas em Comunicação de Dados Multimídia

Mestrado em Telecomunicações rogerio@ieee.org

Resumo. Esta monografia tem como motivação o entendimento técnico do software mais popular de telefonia em redes de pacotes, o Skype, onde o grande desafio é compreender os fatores técnico-econômicos que fazem da aplicação de voz sobre IP (VoIP) a mais utilizada no mundo atualmente. O objetivo é apresentar suas características tais como: o processo de login e estabelecimento de chamadas, sua pretensão em trabalhar com o protocolo NAT e seu comportamento quando na utilização de firewalls nas redes domésticas ou empresariais, abordaremos seus codificadores de voz (codecs), seu acesso a banco de dados dos usuários, além da abordagem de transferência de mídia e conferência. Ao longo de todo o texto estaremos fazendo breves comparações com seus poderosos concorrentes, destacando MSN e Yahoo Messenger para avaliarmos imparcialmente a melhor qualidade de voz entre eles e apresentaremos uma conclusão a partir da análise desenvolvida no decorrer do texto. No apêndice A podem ser encontrados dados práticos dos testes realizados.

1. Skype: Um Caso de Sucesso Skype é uma aplicação VoIP baseada em redes Peer-to-Peer (P2P), desenvolvida pelo Skype Technologies S.A.[25]. A companhia foi fundada por Janus Friis e Niklas Zennstrom, os mesmos empresários que desenvolveram o software de troca de arquivos KaZaa, em 2003. Porém, ao contrário de seu antecessor, que gerava receita através de anúncios e propagandas, Skype não tem a intenção de atuar da mesma forma, sendo completamente livre de propagandas, e hoje vende serviços de chamadas telefônicas através da integração da rede de dados com a telefonia convencional analógica (PSTN) e telefonia móvel, sob contratos de interconexão com as operadoras locais, de longa distância e celulares, utilizando um provedor proprietário de telefonia IP como gateway para integração entre as operadoras. Estes serviços são conhecidos como SkypeOut[22], que permite através da compra de créditos, realizar ligações do seu micro para qualquer telefone do mundo, fixo ou móvel, com tarifas extremamente reduzidas, o SkypeIn[22], o qual fornece um número de telefone fixo, através do pagamento de uma pequena anuidade, para que os usuários possam receber no Skype chamadas originadas de

telefones comuns e ainda há o serviço pago de secretária eletrônica. As ligações de micro para micro são gratuitas.

O modelo de computação Peer-to-Peer bem característico da rede Skype e amplamente implementado na Internet possui várias diferenças em relação ao esquema cliente-servidor. No padrão de comunicação cliente-servidor o fluxo de transmissão é assimétrico, pois a maioria do tráfego ocorre no sentido servidor-cliente, sendo o cliente, na maioria das vezes, um participante passivo na transmissão. Nos sistemas P2P todos os integrantes da rede possuem o mesmo programa (código-fonte) e cada membro da rede pode atuar como cliente e servidor de recursos.

As redes P2P são sistemas distribuídos sem controle centralizado, nos quais o programa que é executado em cada integrante da rede é equivalente em funcionalidade. Os participantes do sistema Peer-to-Peer podem agir como clientes ou servidores de recursos. Eles constroem uma rede virtual sobre a rede física (geralmente a Internet) e colaboram uns com os outros em tarefas específicas, como o compartilhamento de arquivos, responsável pela ampla popularização dos softwares Napster e Kazaa. Assim a rede P2P de telefonia tornou-se um próximo passo natural da evolução e teve um impacto significante com a empresa Skype, que foi fundada para desenvolver a primeira rede de telefonia P2P. Esse tipo de computação representa uma alternativa ao modelo cliente-servidor largamente conhecido e possui um potencial ainda não explorado em sua totalidade.

Cada tipo de aplicação P2P possui seus próprios requisitos de segurança. Entre os requisitos fundamentais de segurança, está o controle de acesso, permitindo que cada nó ou comunidade coloque em prática sua própria política de autorização. Assim, cada participante pode estabelecer quem são as entidades que podem acessar os seus recursos e quais as condições que elas devem cumprir para terem esse direito.

Além dos requisitos de segurança, o êxito de uma rede Peer-to-Peer depende de fatores como o protocolo de comunicação utilizado, a possibilidade de operar em ambientes protegidos como, por exemplo, aqueles que adotam firewalls, a arquitetura de distribuição empregada que pode ser totalmente descentralizada ou não, o tempo decorrido desde uma solicitação até o recebimento de respostas, o número de usuários participantes do sistema e o suporte a ambientes que utilizam a tradução de endereços de rede (NAT) para possibilitar a comunicação entre elementos com endereços IP privados e endereços IP válidos na Internet.

1.1. Arquitetura e Conexão Todas as características das redes P2P são válidas para o Skype, apesar de haver certas particularidades em alguns aspectos que fazem do software uma rede P2P não totalmente pura, isto é, sua infra-estrutura conta com um servidor central de autenticação para validação de usuários na rede e atualizações de software, que são assinados digitalmente pela chave privada RSA1 embutida em seus executáveis.

Outra característica de sua arquitetura é ser composta por apenas dois tipos de nós sendo que os próprios clientes rodam localmente a aplicação, chamado de cliente Skype (CS), onde alguns deles podem atuar como super usuários ou super nós (SN), que podem ser entendidos como ponto de borda da nuvem Skype, atuando como proxy para os nós/usuários comuns da rede, como pode ser observado na Figura 1.

Para atuar com estas características, os nós devem possuir alguns pré-requisitos, como, por exemplo, possuir um endereço IP público, não possuir restrições quanto a firewall, CPU e memória suficientes e uma determinada banda mínima de acesso à Internet, entre outras.

Outra importante entidade da rede é o servidor de login Skype, que é único, se constituindo no único elemento de rede centralizado e localizado em Amsterdam, Holanda. Quando recursos como SkypeIn ou SkypeOut são utilizados, a comunicação passa necessariamente através de servidores localizados em vários países e áreas de discagem.

Figura 1: Ilustração da arquitetura de rede Skype.

O processo de conexão é simples e se encontra ilustrado no Apêndice A. A aplicação cliente (CS) efetua o login na rede se registrando no servidor de logins, cujo endereço foi informado por outros hosts pertencentes à rede.

_____________________________________________________________________________________________ 1RSA

A criptografia RSA é um sistema de criptografia onde a chave de codificação é pública, permitindo então que qualquer pessoa codifique mensagens, e a chave de decodificação é privada. A impossibilidade de se quebrar o sistema de criptografia RSA ocorre em razão da não existência de algoritmos eficientes para o processo de divisão de inteiros. Atualmente são utilizados números com 150 algarismos, para os quais, com a capacidade de computação atual, o processo de fatoração levaria milhares de anos[30].

Por se tratar de uma rede descentralizada, após o login cada CS deve construir e manter atualizada uma tabela para identificar os super nós conhecidos, a esta tabela damos o nome de host cache (HC), que contém o endereço IP e o respectivo número da porta dos super nós que estiverem on line e está localizada no registro do sistema

operacional2. Pelo menos uma entrada válida deve existir nos CS e um máximo de 200 entradas, caso contrário o CS não poderá se conectar a rede e irá reportar um erro do tipo login failure.

Skype também mantém outra listagem local criptografada armazenada no registro do sistema operacional, que é a lista de contatos. Caso o usuário se conecte com sua conta em outro computador, ele terá que reconstruir manualmente sua lista de contatos, pois esta não se encontra armazenadas em servidores na rede. A estratégia de utilizar o máximo possível o hardware do usuário também pode ser entendida como um grande fator de sucesso, pois podemos perceber que a rede só é responsável pelas informações de login, ficando a cargo dos nós todo o processamento e armazenamento das informações.

O seu suporte a redes locais com IPs não válidos e com firewall em seus roteadores são pontos importantes de seu funcionamento, onde as referências nos sugerem a utilização dos protocolos STUN[17] e TURN [18] ou variações instaladas localmente em cada nó e não ao uso de um servidor NAT. Isso acontece, pois o excesso de tráfego relacionados às informações de controle intercambiadas entre o cliente e o servidor NAT seria decisivo para a qualidade final da chamadas telefônicas, sem contar com as trocas devido ao refresh entre as conexões.

1.2. Protocolos e Codecs Em relação à codificação de suas chamadas, Skype utiliza codecs de banda larga e banda estreita, permitindo freqüências entre 50 – 8000 Hz. Podemos observar a utilização dos codecs iLBC[10], iSAC[15] e iPCM-wb[14] e Enhanced G.711[29] desenvolvidos pela empresa Global IP Sound [23], que é parceira do Skype e desenvolve codecs para diversos softwares e hardwares de diversos fabricantes mundiais, apenas o primeiro deles é padronizado. Skype decide qual codec utilizar automaticamente em tempo real de acordo com a disponibilidade de banda e condições de tráfego. Não há supressão de silêncio no principal codec do Skype (iLBC), conforme pudemos comprovar através dos testes práticos (Figura 13).

_____________________________________________________________________________________________

2No sistema operacional Windows 98 a tabela host cache se localiza em HKEY_CURRENT_USER / SOFTWARE /

SKYPE / PHONE / LIB / CONNECTION / HOSTCACHE.

Seus protocolos da camada de transporte são o TCP para sinalização e TCP e UDP para o transporte de mídia, e portas distintas são utilizadas para trafego de sinalização e informação útil propriamente dita, sendo que esta última pode ser configurada pelo usuário na caixa de diálogo na aba de configuração do programa. Caso

o usuário não configure, o CS define aleatoriamente o número da porta durante a instalação, diferentemente do protocolo SIP que possui portas TCP e UDP default e bem definidas. Além disso, o CS disponibiliza a porta 80 (HTTP) e a porta 443 (HTTPS) por default. Para a realização dos testes nesse trabalho, estas duas portas foram desabilitadas para fazer melhor a distinção e obter maior controle sobre a comunicação.

1.3. Funções As funções do Skype[7] podem ser classificadas em startup, login, procura de usuário, estabelecimento de chamadas e fim da conexão, além de transferência de arquivos e mensagens, sendo descritas a seguir.

1.3.1. Startup Quando o CS roda pela primeira vez depois da instalação, ele envia uma mensagem de requisição HTTP 1.1 GET para o servidor Skype. A primeira linha do pedido contém a palavra código installed. Os próximos startups serão apenas para verificar se há atualizações do programa, onde a primeira linha do comando GET passará a ter a palavra código getlatestversion.

1.3.2. Login O processo de login talvez seja a função mais crítica de todas as operações e a mais difícil de ser mapeada, como pode ser visto pelo Apêndice A. A autenticação ocorre, como sabemos, no servidor de login, sendo notificada a presença do nó na rede. Além disso, ocorre o processo de determinação do tipo de NAT e firewall que se encontra no lado do cliente e ainda, verifica-se todo o processo de descoberta dos nós da rede com endereços IP públicos que estão on line, isto é, os super nós, com objetivo dar continuidade a conexão com a rede Skype.

A figura 2 representa um esquemático do processo de login. Primeiramente, a tabela HC se encontra vazia e logo após a primeira instalação o CS recebe uma atualização de endereços IP e pares de portas bem conhecidos dos super nós, para que o CS possa se conectar na rede. O CS tenta estabelecer uma comunicação através de pacotes UDP e caso não tenha resposta satisfatória, tenta se conectar através do protocolo TCP utilizando a mesma tabela inicial HC e seu endereço IP e sua porta 80 (HTTP). Em caso de nova falha, o CS tenta conectar-se através do IP contido em HC e porta 443 (HTTPS). O CS aguarda por mais 6 segundos e caso a conexão não seja estabelecida, todo o processo entra em loop por mais quatro vezes até que ao final a falha no login é reportada caso não ocorra sucesso, podendo esta falha ser devido ao fato de não haver uma tabela HC válida. No caso da utilização de um firewall, o CS pode estar bloqueado para tráfego UDP e habilitado para TCP. Mesmo assim, o programa irá funcionar normalmente, com a vantagem de não trocar pacotes UDP, reduzindo, portanto, o número de passos para efetuar a conexão e, conseqüentemente, o fluxo de bits.

Figura 2: Diagrama de estados do algoritmo de login.

A autenticação com o servidor de login não foi demonstrada.

1.4. Comunicação

1.4.1. Primeira Conexão Após inserir login e senha no programa, o CS estabelece a comunicação com o(s) super nó(s), a partir da tabela HC. O CS envia pacotes UDP para pelo menos quatro endereços de SN contidos na tabela HC, e os SN que responderem passam a trocar mensagens TCP com o CS, embora necessite de apenas um SN para manter a conexão. Após a troca de alguns pacotes TCP com o SN, o CS adquire o endereço do servidor de login, que também é bem conhecido 80.160.91.11, e cujo nome é ui.skype.com, localizado aparentemente em Amsterdam. Após o processo de validação de nome e senha, o CS mantém a conexão com o SN até que um dos dois encerre a sessão, caso o SN seja desconectado, CS estabelece outra conexão TCP com outro SN baseado em sua tabela HC. Esse processo é demonstrado no Apêndice A.

Para clientes Skype que estejam inseridos em ambiente com NAT, todo o processo é transparente para o usuário e todo o processo de conexão segue as mesmas regras que clientes com IP válidos na Internet.

Como a rede Skype é por definição muito dinâmica, CS deve manter atualizada sua “tabela de roteamento” ou tabela de SNs que estão on line. Para isso, após o processo de login, o CS envia pacotes UDP para um número em torno de 22 nós distintos e provavelmente atualiza sua tabela HC com aqueles nós que reponderam a solicitação, desde que sua conexão não esteja impedindo tráfego UDP devido a um firewall.

1.4.2. Busca de Contatos Outra funcionalidade que pode ser considerada importante no Skype é a busca de contatos, o que torna o software mais flexível e fundamental quando um usuário deseja procurar alguma pessoa que esteja cadastrada na rede pelo mundo, mesmo que esta esteja utilizando NAT. O Skype utiliza a tecnologia Global Index3 [16] (GI) para pesquisar novos usuários na rede, que se apresenta como capaz de localizar qualquer usuário conectado na rede nas últimas 72 horas.

Para os clientes localizados em endereços públicos, são enviados pacotes TCP para seu SN, que informa inicialmente quatro outros SN que possam saber a localização do CS procurado. Desta forma, o CS se cominuca com estes quatro novos SNs através de mensagens UDP, caso a busca não seja bem sucedida, o SN que mantinha contato com o CS lhe envia oito novos SNs que possam conhecer o CS procurado, que por sua vez, pode não ser reconhecido por estes novos SNs. Então o SN envia outros SNs para o CS que está procurando seu contato até que o CS de destino seja alcançado ou a busca seja encerrada por timeout. A única diferença para CS protegidos por firewall e utilizando NAT é que as mensagens de busca são enviadas sobre TCP. O Apêndice A também apresenta o teste de busca de contatos.

1.4.3. Chamadas As chamadas são sempre criptografadas fim-a-fim, utilizando AES[19] (Advanced Encryption Standard) e chave de 256 bits. Skype mantém varias conexões abertas para a mesma chamada e determina dinamicamente a melhor conexão a ser utilizada naquele instante. Isso tem grande efeito na redução da latência, principalmente, e também na percepção da qualidade da voz na rede.

_____________________________________________________________________________________________

3Global Index

A tecnologia define uma rede multi-camadas onde super nós se comunicam de tal modo que todos os nós na rede têm o total conhecimento de todos os usuários disponíveis e recursos.

Durante a conversação propriamente dita, as duas pontas da rede que possuem endereços válidos trocam informações TCP diretamente sem a presença do SN, assim como nas mensagens de sinalização. Dentre elas podemos citar mensagens de sincronização (SYNC) e reconhecimento (ACK). Caso necessite mudar de SN, mensagens UDP são enviadas. Nos casos em que um dos dois nós esteja utilizando NAT, as mensagens de voz e de sinalização não seguem diretamente entre os terminais, e ao invés disso, o nó chamador envia mensagens TCP de sinalização para um ou mais de um SN, que encaminha a chamada para o nó de destino também sobre TCP. Este SN também auxilia no encaminhamento dos pacotes de voz para o destino sobre UDP e vice-versa. Para o caso em que os dois nós utilizam NAT, o processo é análogo ao anterior.

Também foi observado que mensagens de refresh são enviadas pelo CS sobre TCP a cada 60s quando o software estava sendo utilizado. O encerramento das conversações segue a mesma idéia da descrita no parágrafo anterior para nós em endereços públicos ou privados.

1.5. Segurança Outro fator importante é a questão da segurança em relação às contas de usuário, quando estes realizam chamadas destinadas a rede telefônica convencional ou mesmo entre a rede de pacotes e também no que se refere à transferência de arquivos. A segurança das chamadas tem muitos aspectos envolvidos e é difícil de ser analisada como um todo, pois o Skype não publica seu algoritmo de troca de chaves, seu protocolo e o básico do desenho de seus certificados. Outros fatores também influenciam, como a segurança da máquina que roda o software em relação a sua conexão com a Internet, a existência de programas do tipo spyware, o fato de que estamos utilizando redes não centralizadas, etc. Não podemos saber, portanto, a precisão e o grau de segurança e a que tipos de ataques a rede e a aplicação podem suportar.

A segurança dos dados enviados sobre uma conexão criptografada depende de muitos fatores, incluindo o tipo de algoritmo de embaralhamento, como as chaves são determinadas e trocadas, como o algoritmo é implementado, o protocolo que transporta o algoritmo e sua implementação. Pesquisas acreditam que, através de analisadores de tráfego, uma combinação de protocolos é utilizada para o registro na rede, na busca de contatos on line e na própria chamada telefônica.

Portanto, a conclusão é que o nível de segurança implementado pela Empresa pode ser pobre ou altamente complexo, principalmente porque não sabemos muito sobre seu protocolo de comunicação, diferentemente de outras aplicações VoIP que são bem conhecidas. Porém, ainda não há registros sobre clonagens de contas de usuários, e sabe-se que a segurança é um aspecto mais poderoso quando comparado com redes PSTN, entretanto são mais vulneráveis quando comparado com sistemas de VoIP sobre VPNs.

Outras preocupações com relação às questões de segurança na implementação do software propriamente dito podem ser: o default do programa é guardar um histórico do áudio das conversas em arquivo; podemos saber quando outros usuários estão conectados a um dado instante por default; não se sabe ao certo se os SNs que encaminham as mensagens podem interceptá-las, pois o tráfego é processado localmente

e por fim, os serviços SkypeIn e SkypeOut podem ser vulneráveis em pontos onde a chamada trafega pelas redes convencionais de telefonia, pois nestes pontos as chamada são desencriptadas.

1.6. Resiliência As redes de pacotes possuem uma extraordinária capacidade de se auto-recuperarem de diversos tipos de falhas, devido a seu imenso conjunto de nós e a rápida convergência dos algoritmos de roteamento. Em muitos casos a conexão no Skype pode ser restaurada mais rapidamente que nas redes de telefonia existentes. A rede Skype mantém seu serviço mesmo em constantes mudanças físicas e lógicas da rede, independente da localização e do endereço IP do usuário.

1.7. Outros Serviços

Skype permite que um usuário esteja conectado em sua conta em mais de uma máquina simultaneamente, assim as chamadas para este usurário são roteadas para todas as localidades, e ao ser atendida em um determinado terminal, as chamadas para os demais pontos de login são canceladas. No caso das mensagens instantâneas, o processo é o mesmo. Ao contrário do MSN Messenger, que possui um sistema de registro que permite o login em apenas um computador.

1.7.1. Chamada em Espera A chamada em espera é mais um recurso do software, tecnicamente CS envia mensagens periódicas sobre TCP para SN para manter a conexão.

1.7.2. Audioconferência A audioconferência suporta até quatro pessoas conversando ao mesmo tempo em qualquer lugar do mundo com acesso Internet e o Skype, que utiliza codecs de banda estreita e banda larga, sendo este último utilizado com sérias restrições pelo software, entraremos em detalhe a partir da próxima seção. Este serviço também é gratuito, mas não foi motivo de teste deste documento.

2. CODIFICAÇÃO DE VOZ COM iLBC Com o objetivo de alcançar uma baixa taxa de transmissão, uma técnica de compressão de voz é utilizada. O principal objetivo na configuração de um codificador de voz é alcançar a melhor qualidade possível com a menor taxa de bits, com reservas em relação à complexidade e ao delay. O caminho mais óbvio para oferta de baixa taxa de bits é determinar uma baixa freqüência de amostragem. De longe, as duas mais populares escolhas em relação à freqüência de amostragem são 8 e 16 KHz. Codificadores que utilizam 8 KHz como freqüência de amostragem são denominados codificadores de banda estreita e aqueles que utilizam 16 KHz como freqüência de amostragem são chamados de codificadores de banda larga.

Diminuindo a taxa de bits, pelo emprego de técnicas de codificação mais poderosas, resulta numa maior distorção. Porém explorando as características do ouvido

humano, técnicas de mascaramento desta distorção podem ser utilizadas para alcançar um alto percentual de qualidade a baixa taxas de bits.

As soluções de telefonia tradicional são de banda estreita, limitada em 300 – 3400 Hz (VoIP não está limitada obrigatoriamente à codificação em banda estreita). Além disso, a telefonia tradicional sofre sérios limites de qualidade, como distorções provocadas pela má qualidade dos fios de par trançado entre a operadora até a casa do assinante, ruídos devido ao uso de telefones sem fio analógicos, além de outras fontes significantes de distorção de qualidade. Essas penalidades não são observadas em implementações VoIP. Iremos discutir agora como codificadores VoIP evitam tais distorções e ainda podem alcançar uma qualidade muito melhor do que estamos acostumados pelas limitações da PSTN.

Os três principais fatores associados a redes de pacotes que possuem impacto significativo na percepção da qualidade da voz são delay, jitter e perda de pacotes. Os codificadores devem prever tratamento a estes parâmetros, além de outros como ruído no canal, condições de tráfego, eco e outros fatores de qualidade.

Apesar da utilização de buffers pelas aplicações, as maiores penalidades provocadas pelo alto delay são o surgimento de eco e crosstalk, que podem causar uma redução de qualidade para o sistema. Nenhum dos padrões atuais de codificadores de voz da UIT foi desenvolvido para tratamento de perdas de pacotes e, portanto são muito sensíveis a esse fenômeno. A presença de jitter em redes de pacotes complica o processo de decodificação porque o decodificador necessita ter pacotes de dados prontamente disponíveis em intervalos regulares para produzir a continuidade suavizada da voz. Um buffer tem que ser empregado para garantir que o pacote estará disponível quando necessário.

2.1. O Codec Os principais codificadores de voz da UIT como o G.729 e o G.723.1, por exemplo, são baseados em Code Excited Linear Prediction (CELP), onde se observa uma boa qualidade da voz a baixas taxas[12]. Seu princípio básico se destaca como sendo eficiente, pois utiliza amostras anteriores da voz para codificar a amostra atual, isto é, há uma interdependência entre a codificação das amostras no tempo. Portanto, sua performance é extremamente dependente do histórico de amostras e isso pode se tornar maléfico na medida em que erros são propagados pela rede comutada de pacotes, resultando em amostras equivocadas e perdas de pacotes. Concluímos que o CELP foi projetado para se recuperar de erros de bits e não da perda de pacotes.

O codec iLBC foi aceito em março de 2002 pelo Internet Engineering Task Force (IETF) como o primeiro codec de áudio/voz a ser padronizado[4], e hoje o codec está em processo final de padronização pelo IETF, como parte do IETF Audio Visual Transport (AVT) Working Group, e passa a ser livre de patentes.

iLBC é o codificador mais utilizado pelo Skype durante as chamadas e trata cada pacote de voz independente, ou seja, qualquer erro no pacote atual não influencia na decodificação dos demais, visto que estamos trafegando pacotes de voz em um ambiente com relativo número de perdas e erros de pacotes. A métrica mais relevante para um codificador de voz utilizado em cenários onde perda de pacotes está presente é o numero de frames que o algoritmo leva para se recuperar a partir de um pacote perdido. No caso

do iLBC este numero é zero, ou seja, o primeiro pacote seguido de um outro que foi perdido é sempre decodificado exatamente como pretendido.

iLBC é um codificador de voz de banda estreita. Utiliza por completo seus 4 KHz de banda disponíveis, enquanto que a maioria dos codificadores de banda estreita utiliza apenas a faixa padrão de 300 Hz até 3400 KHz, aumentando, portanto, a inteligibilidade da voz, pois pode reproduzir um som mais próximo do real. É amostrado em 8 kHz e seu algoritmo utiliza codificação preditiva linear4 (LPC) com bloco independente. Se o bloco é recebido corretamente, LPC apenas registra o estado do bloco atual para ser usado por uma possível perda de pacotes no futuro. No caso de uma perda, o decodificador recebe um aviso correspondente e, para estes blocos, se utiliza do Packet Loss Cancealment (PLC), método de mascarar a perda de pacotes simplesmente repetindo o último pacote recebido com sucesso, ao invés de reproduzir o som de silêncio no lugar do pacote perdido, para se criar um sinal decodificado suavizado, que mascara o efeito da perda de pacotes.

iLBC tem suporte a dois comprimentos básicos de frames: 20 ms a uma taxa de 15.2 kbit/s e 30 ms com taxas de 13.33 kbit/s, isto é, quando o codec opera em blocos de comprimento de 20 ms, produz 304 bits por bloco. Similarmente, em blocos de comprimento 30ms produz 400 bits por bloco. Os dois modos para os diferentes tamanhos de pacotes operam de forma muito similar.

Nos resultados da descrição do algoritmo nos sistemas de codificação de voz, observa-se uma resposta ao controle de perda de pacotes similar ao conhecido pulse code modulation (PCM) com cancelamento de perda de pacotes (PLC) como nos padrões da ITU-T G.711 standard, que opera a uma taxa fixa de 64 kbit/s. E ao mesmo tempo, o algoritmo habilita a codificação à taxa fixa de bits com o limiar de qualidade versus taxa de bits muito próximo aos codecs que implementam o CELP.

Testes da AT&T[12] no seu Voice Quality Assessment Lab também mostram que não há diferença significante de performance entre os modos 20 ms e 30 ms no iLBC, exceto sob condições de perda de pacotes, onde o frame de 20 ms pareceu ser mais robusto.

______________________________________________________________________ 4LPC

Técnica Linear Predictive Coding que se baseia num modelo do trato vocal. O codificador analisa um bloco de sinal de voz, tipicamente 20 ms, e produz um modelo temporal da excitação do trato vocal e da função de transferência. Os parâmetros do modelo e da especificação da excitação para o bloco de sinal são transmitidos e usados no decodificador por um sintetizador que reproduz a voz fazendo passar a excitação recebida por um modelo matemático do trato vocal. A codificação conduz a um débito de 16 Kbit/s. Esta é uma técnica de codificação de fonte.

As figuras a seguir são úteis na avaliação do seu desempenho e utilizam a classificação MOS5 como padrão de medida. Podemos visualizar que o algoritmo iLBC provê um excelente limiar de qualidade versus taxa de bits. Na figura 3 o MOS do iLBC

em 15% de perda está perto do G.729 sob 8% de perda, apesar da taxa de bits do iLBC ser um pouco mais alta, já que codifica todo frame independentemente.

Figure 3. Comparação de performance do iLBC, G.729A e G.723.1 pela Dynastat,

Inc.

Os testes acima mostram que iLBC não apenas tem performance melhor que os outros padrões de codecs atuais (G.723.1, G.728, G.729, GSM, etc) em relação à perda de pacotes, mas também se apresenta com igualdade de condições, ou melhor, que padrões sobre canais sem congestionamento, isto é, sem perda de pacotes, como pode ser demonstrado na Figura 4. _____________________________________________________________________________________________ 5MOS

Em comunicações de voz, particularmente em telefonia através da internet, o Mean Opinion Score (MOS) fornece uma medida numérica da qualidade da voz humana do circuito. Este esquema faz uso de testes subjetivos através de opiniões que são matematicamente computados e que pela sua média são obtidos indicadores de qualidade da performance do sistema.

Para determinar o MOS, um número de ouvintes percebem a qualidade da voz através da leitura em voz alta de sentenças ao longo do circuito de homens e mulheres. O ouvinte fornece as notas de cada sentença como o seguinte: (1) ruim; (2) pobre; (3) razoável; (4) bom; (5) excelente. MOS é a média aritmética de todas as notas individuais e pode variar de 1 (pior) a 5 (melhor).

Figura 4 – Performance baseada em MOS do iLBC, G.729 (8 kb/s) e G.723.1 (6.3 kb/s) em canal livre e sob perda de pacotes.

2.2. PAYLOAD RTP O codec iLBC usa frames de 20 ou 30 ms e um clock de 8 KHz, de forma que o timestamp do RTP tem que estar em unidades de 1/8000 segundos. O payload do RTP para iLBC tem o formato apresentado na figura 5. Não é necessário nenhum cabeçalho adicional.

Este formato foi constituído para situações onde os dois lados da comunicação enviam um ou mais frames por pacotes.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP Header |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| |+ One or more frames of iLBC || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5 - Formato do pacote RTP.

O uso dos bits no RTP Header deve ser como o especificado na RFC do padrão[28]. O padrão do protocolo define o bit M em seu cabeçalho, que deve ser utilizado dentro do perfil RTP, por exemplo, a RFC 3551 especifica que se o transmissor não estiver utilizando supressão de silencio, o bit M sempre será zero. Quando mais de um frame do codec iLBC está presente em um único pacote RTP, o timestamp é, como sempre, o mais antigo frame de dados representado no pacote RTP.

O transmissor deve seguir algumas restrições que são: não deve incluir mais frames iLBC em um único pacote RTP que caiba na MTU do protocolo de transporte do RTP; os frames não podem ser divididos entre pacotes RTP e frames de diferentes modos (20 ms e 30 ms) não podem ser incluídos no mesmo pacote.

Há recomendações que o número de frames contidos num pacote RTP deve ser consistente com a aplicação, isto é, no caso da voz, quanto menos frames por pacotes RTP tiver na transmissão, menos sensível será o delay e a sensibilidade a perda de pacotes ou também a restrições quanto à banda, por exemplo. Porém, a informação do número de frames contidos no pacote RTP não está prevista no payload. A forma de contar o número de frames é contabilizando o número total de octetos dentro do pacote RTP, e dividir o octeto pelo número de octetos por frame esperado (32/50 por frame).

2.3. BITSTREAM Na definição do bitstream, os bits são distribuídos em três classes de acordo com sua sensibilidade a perdas. Os bits mais sensíveis pertencem à classe 1 e são alocados primeiro no bitstream de cada frame. Os bits menos sensíveis são aqueles pertencentes à

classe 2, alocados em seguida aos bits de classe 1. A menor parcela dos bits sensíveis é alocada na classe 3 e no final do bitstream de cada quadro.

Analisando as classes de bits em função dos dois comprimentos de quadro (20/30 ms) temos: os bits da classe 1 ocupam um total de 6/8 bytes (48/64 bits), os bits de classe 2 ocupam 8/12 bytes (64/96 bits) e os de classe 3, 24/30 bytes (192/240 bits). Esta distribuição de bits proporciona um maior nível de proteção, já que os bits estão posicionados no pacote de forma a serem menos penalizados por erros (Uneven Level Protection - ULP). Quando um índice de quantização é distribuído entre mais classes, os bits mais significativos pertencem às classes mais baixas.

Nas próximas seções, destacaremos os outros codecs menos utilizados pelo Skype, sendo estes proprietários da GIPS e resumidos na figura 6.

Figura 6 – Codecs utilizados pelo Skype

2.4. GIPS iPCM-wb iPCM-wb™ [14] é um codec de banda larga que provê uma qualidade de som mais alta que PSTN, por isso também pode ser utilizado em caso de necessidades especiais, tais como videoconferência e áudio conferências. É extremamente tolerante a perda de pacotes e quando utilizado em conjunto com NetEQ™ 6 [13] proporciona uma grande redução do delay em comparação com soluções alternativas.

_____________________________________________________________________________________________ 6 NetEQ™ é uma solução proprietária no processamento de voz, pode atuar como codificador de banda larga e banda estreita. É compatível com todos os padrões de codecs de áudio. O objetivo é atuar em conjunto com outros codecs e realizar maior controle sobre jitter através de buffers dinâmicos e tratamento de perda de pacotes.

iPCM-wb foi construído baseado na funcionalidade denominada Voice Activity Detection (VAD), que reduz a taxa de bits aproximadamente em 36 kbit/s devido à supressão do silencio, ou seja, o canal só transmite, ou o codec só codifica quando há informação útil, isso é, a voz dos interlocutores. A figura 7 demonstra sua robustez a perda de pacotes quando comparado com outros codecs. A Tabela 1 resume as especificações técnicas do codificador.

Figura 7 – Performance do Codificador iPCM-wb™. Fonte: Comsat

Tabela 1 – Especificações Técnicas do Codificador iPCM-wb™.

2.5. GIPS iSAC iSAC™[15] é um codificador de voz adaptativo, por isso é capaz de equalizar a qualidade da voz em taxas típicas de banda larga e banda estreita de acordo com a velocidade de conexão existente a partir da taxa oferecida por modem dial-up. Quantitativamente, sua taxa de transmissão pode varia desde de 10 kbps até um máximo de 32 kbps.

iSAC suporta não apenas conversação, mas também transmissão de músicas e som ambiente, variando a sua banda e taxa de transmissão. Também pode ser utilizado em conjunto com NetEQ™, alcançando alta qualidade em ambientes não controlados, com alto jitter e perda de pacotes. A Tabela 2 resume as especificações técnicas do codificador.

Tabela 2 – Especificações Técnicas do Codificador iSAC™.

2.6. GIPS Enhanced G.711

GIPS Enhanced G.711[29] é uma versão aprimorada do padrão G.711, procurando manter a alta qualidade de voz sob redes altamente sobrecarregadas. Seu verdadeiro ganho em relação ao G.711se refere à robustez a perda de pacotes.

GIPS Enhanced G.711 pode ser combinado com NetEQ™ para prover qualidade de voz a PSTN em taxas de perdas de pacotes de até 10%, e pequena degradação em taxas de perdas de pacotes de até 30%. E prevê suporte ao VAD.

A Figura 8 apresenta um gráfico comparativo do desempenho do codificador e a Tabela 2 resume as especificações técnicas do codificador.

Figura 8 – Performance do Codificador Enhanced G.711

Tabela 3 – Especificações Técnicas do Codificador Enhanced G.711

3. CONCLUSÃO Skype é o primeiro cliente baseado em redes ponto-a-ponto a utilizar telefonia sobre redes de comutação IP, não utiliza protocolo de padrão aberto e suas mensagens são criptografadas, de modo que sua análise e descrição torna-se um pouco mais difícil. Porém, conseguimos mapear algumas de suas principais funções e componentes através de documentação técnica e a partir da própria análise de seu funcionamento, apesar de algumas de suas técnicas de comunicação não terem sido ainda totalmente mapeadas, como o fato de não sabermos por completo o conteúdo das mensagens trocadas entre o cliente e o servidor de nomes, nem as informações por ele guardadas, por exemplo.

O propósito deste trabalho foi identificar os motivos técnicos pelos quais fazem do Skype um software tão especial em comparação com outros operadores de telefonia IP, capaz de na sua primeira semana de operação computar mais de 60 mil downloads (Agosto de 2003). Pela primeira vez na história da internet, protocolos que trabalham em complexos ambientes de rede sobreviveram e tornaram-se amplamente difundidos. Não comparamos diretamente, mas o protocolo de padrão aberto Session Initiation

Protocol (SIP) ainda tem suas limitações, como o fato de ter muita dificuldade de trabalhar com NAT[9].

Hoje temos um cenário em que o tráfego na Internet é grande, porém os rendimentos são ainda baixos. Com isso o investimento em hardware se torna um investimento sem retorno e o Skype obtém a funcionalidade da sua rede baseada nos microcomputadores de usuários, sendo a Empresa responsável pelo controle de acesso através de servidores de autenticação com certa redundância, desenvolvimento de software e uma pequena dose de marketing.

Sua popularização se deve ao fato do software e de sua rede serem gratuitos, da excepcional qualidade da voz na maior parte do tempo de conexão quando comparado com a rede de telefonia analógica tradicional e aos seus concorrentes diretos MSN e Yahoo IM, demonstrado pelo uso de seus codecs. Além disso, também não é necessário possuir um endereço público na Internet e a instalação, que por sua simplicidade (não precisa ser configurado) também se destaca como fator de sucesso. Sem contar com sua facilidade de instalação e difusão nos players de voz que acabaram por absorver o software, como:

� Applications/Soft phones: Skype, Nortel, Webex, Hotsip, Marratech, Gatelinx, K-Phone, XTen;

� IP Phones: WorldGate, Grandstream, Pingtel;

� Chip: Audiocodes, TI Telogy, LeadTek, Mindspeed.

� Sistemas Operacionais: Windows 9x ou superior, Pocket PC, Linux, Mac OS X.

Skype também soma outros recursos como mensagem instantânea, busca, e transferência de arquivos, de modo que não há necessidade de se utilizar mais de um software para comunicação pela Internet.

4.1. FUTURO O futuro é uma das questões mais interessantes e intrigantes deste mundo, todos queremos saber o rumo a ser tomado. Com relação ao Skype, a empresa tem planos de embutir seu software em terminais telefônicos móveis através de parcerias com fabricantes de hardware, possibilitando seus usuários estarem conectados a todo o instante e realizar chamadas quase que gratuitas entre os sistemas móveis. Certamente irá causar uma revolução no âmbito das operadoras de telefonia celular, sendo obrigadas a rever seu planejamento estratégico. Outra possibilidade é a integração da conectividade do SIP com o Skype, possibilitando a interoperabilidade com outros sistemas VoIP, criando, portanto, um cenário de interconexão similar ao existente hoje na telefonia convencional e na celular. Dessa forma, a telefonia pela Internet pode alcançar status de a mais ampla rede de telecomunicações existentes, com a coexistência das redes legadas.

Porém, antes de tudo é necessário que a Skype consiga manter as suas fontes de receita; manter a liderança frente à concorrência que aumenta exponencialmente; competir com os padrões abertos de telefonia IP, visto que seu algoritmo ainda é

desconhecido; superar questões de regulamentação; lidar com as questões regionais e expandir sua base de clientes com novos serviços que de certo surgirão.

4. REFERÊNCIAS [1] Davidson, J. e Peters, J., “Voice of IP Fundamentals”, Cisco Press, Indianapolis, 2000.

[2] Collins Daniel, “Carrier Grade Voice over IP”, Second Edition, Mc Graw Hill, USA, 2003.

[3] Malher, Paul,”VoIP Telephony with Asterisk”, USA, 2004

[4] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004. http://www.ietf.org/rfc/rfc3951.txt

[5] Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech. , RFC 3952, December 2004

http://www.ietf.org/rfc/rfc3952.txt

[6] Simson L. Garfinkel, “VoIP and Skype Security”, January 26, 2005

[7] S. A. Baset and H. Schulzrinne, “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol.”, Columbia University, September 15, 2004

[9] Tapio, Antti, “Future of telecommunication – Internet telephony operator Skype”, Helsinki University of Technology, April 26, 2005.

[10] iLBC codec.

http://www.globalipsound.com/pdf/gips_iLBC.pdf

[11] S. V. Andersen et. al., “iLBC - A Linear Predictive Coder with Robustness to Packet Losses," in IEEE Speech Coding Workshop, (Tsukuba, Japan), October 2002.

[12] ILBC , “ILBC – Designed For The Future”, iLBC White Paper, October 15, 2004

[13] Global IP Sound, “GIPS NetEQ – A Combined Jitter Buffer Control/Error Concealment Agorithm for VoIP Gateways”

[14] GIPS iPCM-wb

http://www.globalipsound.com/datasheets/iPCM-wb.pdf

[15] GIPS iSAC codec.

http://www.globalipsound.com/pdf/gips_iSAC.pdf

[16] Global Index (GI):

http://www.skype.com/skype_p2pexplained.html

[17] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy. STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). RFC 3489,

IETF, Mar. 2003.

[18] J. Rosenberg, R. Mahy, C. Huitema. TURN: traversal using relay NAT. Internet draft, Internet Engineering Task Force, July 2004. Work in progress.

[19] Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS). RFC 3268, IETF, Jun 2002.

[20] http://www.skype.com/skype_p2pexplained.html

[21] http://www.ilbcfreeware.org/

[22] http://en.wikipedia.org/wiki/Skype

[23] http://www.globalipsound.com/

[24] http://www.skypejournal.com/

[25] http://www.skype.com/

[26] Ethereal

http://www.ethereal.com

[27] Skype conferencing white paper by PowerModeling: http://www.powermodeling.com/files/whitepapers/Conference%20Test%20feb%2009.pdf

[28] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[29] GIPS Enhanced G.711

http://www.globalipsound.com/datasheets/EG711.pdf

[30] http://www.rsasecurity.com/

APÊNDICE A Esta monografia envolve características práticas, de forma que não poderíamos realizá-la sem apresentar qualquer resultado experimental. O principal objetivo é apresentar alguns estados durante o processo de comunicação do software.

Foram feitos alguns testes ainda que simples com o software Skype com a seguinte configuração:

� Computador Pentium III, 128 Mb de RAM e IP dinâmico 192.168.1.253.

� Sistemas Operacionais utilizados: Windows XP/ Linux Conectiva 10

� Roteador Linksys IP 192.168.1.250

� Modem e conexão ADSL 300Kbps

� Skype versão 1.4.0.84, com apenas porta 60103 habilitada para o tráfego.

� Ethereal[26] versão 0.10.13

� Firewall ZoneAlarm

Os testes foram medidos através do analisador de protocolos Ethereal a partir da

rede local com as especificações acima descritas, e o nó chamado utilizando Windows XP, Virtua 300Kbps com NAT. As figuras a seguir demonstram o tráfego referente as etapas de login, busca de contatos, conversação, chat, chat com transferência de arquivos e logout, respectivamente. Os gráficos apresentam legendas, para o tráfego UDP utilizamos a cor vermelha, TCP verde e a curva na cor preta representa o total de tráfego. Outros protocolos também foram mapeados, mas não representam o tráfego do Skype e mostra todos os protocolos identificados na conexão.

O teste da busca de contatos foi realizado duas vezes, na primeira o usuário não foi localizado e o outro a busca foi realizada com sucesso ( três registros foram retornados e apenas um foi adicionado aos meus contatos). Este teste foi proposital para se observar o comportamento do dois eventos. Há uma maior geração de tráfego para o último caso, onde o buscador e o contato localizado trocam informações TCP e UDP.

Login

Figura 9 – Notificação do firewall do pedido de login do Skype

Figura 10 – Gráfico do volume tráfego de login com legenda.

Figura 11 – Tráfego de rede do login.

Busca de contatos

Figura 12 - Tráfego requisitado pela busca de contatos sem sucesso e com sucesso, respectivamente.

Conversação Utiliza uma média de 3 a 16 KB/s dependendo das condições dos pontos da rede e dos computadores.

Figura 13 – tráfego do áudio com momento proposital de completo silêncio

Chat

Figura 14 – Gráfico contínuo do bate-papo

Figura 15– Gráfico contínuo do bate-papo com variação de escala.

Chat com Transferência de Arquivos Foram transferidos dois arquivos de 4 KB e outro de 2 MB, respectivamente. Não havia conversação no momento das transferências.

Figura 16 – Gráfico com o volume de tráfego da transferência de arquivos

Logout

Figura 17 – Tráfego de Logout

Observação1: A tabela HC não foi acompanhada e nem demonstrada, porque utilizamos o sistema operacional Windows XP, onde não sabemos ao certo a nova localização da tabela no registro do sistema, apesar das tentativas de busca.

Observação2: Os arquivos com os detalhes dos gráficos contendo todas as estatísticas, tempo de conexão, intervalo entre comunicação, origem e destino da comunicação, protocolos, e outras informações podem ser solicitadas através do e-mail lroger@starone.com.br para serem visualizas com maior riqueza de detalhes no software Ethereal.