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
[email protected]
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.
_____________________________________________________________________________________________
RSA
1
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).
_____________________________________________________________________________________________
2
No 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.
_____________________________________________________________________________________________
3
Global 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.
______________________________________________________________________
4
LPC
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.
_____________________________________________________________________________________________
5
MOS
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, KPhone, 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.p
df
[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
[email protected] para serem visualizas com maior riqueza de detalhes no software
Ethereal.