Média VoIP

Outro dos campos onde se efetuaram testes foi na capacidade do componente criado para a tradução da média WebRTC em média standard.

Neste caso, não foram realizados testes de carga, mas tentou-se perceber qual o impacto que a tradução da média tem na qualidade dastream quando esta chega ao seu destino. Para isso foram definidos dois cenários onde a média é transmitida de forma diferente.

Num primeiro caso apresentado na Figura 5.4a, a média foi passada diretamente entre 2browsers, usando a capacidade que estes têm de criar estas ligações, sendo este o caso mais simples de utilização do WebRTC. O servidor apenas tem de deixar passar o SDP tal como chegou para o outro utilizador, fazendo assim com que os IPs e portas partilhadas sejam as dos clientes.

Na Figura 5.4b é apresentado o segundo cenário de testes que foi utilizado. Neste último caso, o sistema é muito mais complexo, incluindo os dois componentes de tradução de média e de sinalização em dois servidores distintos.

Um primeiro ponto é composto por um Gateway, através do qual as aplicações Web se ligam a um outro servidor, utilizando os protocolos standard, nomeadamente o SIP para a sinalização e o RTP simples para a

7_{Java NIO foi um novo método deinput/output de rede criado no Java 1.4, que veio permitir uma nova forma de tratamento dos}

pacotes na rede. Na versão anterior do Java, cada ligação tinha associada a si umathread responsável por processar os dados recebidos. Com o NIO, é possível criar umapool de threads para tratar de todos os pedidos, independentemente da ligação da qual chegam.

média das chamadas. Por sua vez, este segundo servidor foi também configurado com os módulos construídos neste projeto, permitindo assim que clientes Web se liguem ao servidor diretamente.

(a) Média transmitida ponto-a-ponto

(b) Média transmitida através do Gateway

Figura 5.4: Cenários usados para testar a qualidade da re transmissão de média

Desta forma, para o servidor (WIT Application Server), os pedidos que chegam a partir do WIT Gateway são indiferenciados de pedidos que cheguem a partir de aplicações VoIP genéricas, que suportam apenas os pro- tocolos standard. Da mesma forma, o Gateway foi utilizado para ligar um cliente que utiliza WebSockets a um servidor SIP, e por isso vai fazer a tradução de todas as especificidades próprias do cliente construído utilizando WebRTC, para os protocolos típicos de uma aplicação VoIP.

Existem assim duas traduções de sinalização e de média, em cada percurso completo de um cliente até ao outro, permitindo testar todos os componentes de envio e recepção numa só chamada.

Nestes testes foram realizadas várias chamadas e analisados vários valores em cada um dosbrowsers, através da ferramentawebrtc-internals8_{, que fornece estatísticas sobre as chamadas a decorrer no Google Chrome. As}

análises foram realizadas usando diferentes valores para a transmissão destreams de áudio e de vídeo. Os Codecs utilizados nas chamadas foram o Opus para o áudio e o VP8 para o vídeo.

Resultados

No áudio os valores analisados foram o Round-Trip Time (RTT)9_{, ojitter}10_{e a perda de pacotes, por serem três}

parâmetros representativos da qualidade da média em VoIP[6].

8_{Ferramenta disponibilizada pela Google no Chrome para permitir saber várias informações sobre os objetos Peer Connection instan-}

ciados nobrowser. Está acessível nas versões mais recentes emchrome://webrtc-internals

9_{Tempo que demora a chegar ao seu destino um pacote de dados a ser enviado na rede, mais o tempo que o pacote de confirmação}

demora a atingir o ponto inicial. No protocolo RTP este valor é calculado desde que um pacote é enviado até ao momento em que chega o pacote RTCP respectivo.

10_{Variância dos tempos entre pacotes transmitidos na rede, na chegada à aplicação que os pretende utilizar, e o tempo em que devem}

ser reproduzidos. No contexto VoIP, para resolver o problema causado pela inconstante cadência de pacotes de média a serem recebidos e também pela possível chegada desordenada, é usado umjitter buffer para ordenar os pacotes à sua chegada para serem reproduzidos pela ordem correta, nos tempos devidos.

Os testes do cenário ponto-a-ponto apresentado em a) da Figura 5.4, onde os dois browsers comunicam diretamente entre si foram realizados primeiro, para se ter uma percepção dos valores no melhor caso possível, dado que neste cenário a média faz um menor percurso sem ter nenhum componente a alterar protocolos na rede.

Figura 5.5: Áudio transmitido de ponto-a-ponto

Os gráficos apresentados na Figura 5.5 mostram a taxa de pacotes enviados num dosbrowsers e a respectiva taxa de pacotes recebidos no outrobrowser. Pode-se verificar que os valores são idênticos, não existindo uma grande variação nos pacotes recebidos por segundo. No browser que se encontra a enviar a stream a ser analisada foram observados valores médios de RTT de 8ms, e os valores de jitter medidos no browser que recebia astream mostram uma média de 4ms. A perda de pacotes nesta chamada esteve na ordem dos 0.1%.

Figura 5.6: Áudio transmitido através do servidor

Para o cenário b) onde a média dos browsers é transformada para o protocolo RTP e depois novamente encriptada para DTLS-SRTP, estão apresentados os valores analisados nos gráficos da Figura 5.6.

Desde logo observando a taxa de pacotes enviados e a taxa de pacotes recebidos, se pode verificar uma maior variação que no cenário anterior, apesar de em média continuar a receber 50 pacotes por segundo. Isto acontece

por causa dos pacotes estarem a ser processados entre os dois pontos, mas pode-se verificar que apesar de em alguns segundos ser mais baixo, nos segundos contíguos verifica-se um valor superior à média de 50 pacotes. Isto mostra que apesar de chegarem mais cedo ou mais tarde, os pacotes não se perderam na rede, sendo que nesta chamada a perda de pacotes foi igualmente de 0.1%.

Este facto de os pacotes chegarem atrasados e não influenciarem a taxa de pacotes perdidos está diretamente ligada com ojitter obtido neste teste. O valor médio de jitter obtido foi de 13ms, e o RTT ficou com um valor médio de 34ms. O facto do RTT ter aumentado é facilmente explicado com o tamanho do percurso que um pacote tem de percorrer neste cenário. Ojitter ter aumentado é perceptível analisando a diferença entre a taxa de pacotes enviados e de pacotes recebidos, sendo que o mesmo conjunto de pacotes enviado num segundo não chegaram no mesmo segundo ao destino. No entanto, os valores continuaram muito baixos não permitindo que ojitter subisse para valores que forcem a que pacotes sejam descartados.

As aplicações VoIP têm normalmentebuffers de jitter com valores entre os 60ms e os 100ms[7]. Estes são valores aceitáveis e portanto obter o jitter abaixo de 60ms é naturalmente um excelente resultado. A Google implementou um buffer de jitter dinâmico no Chrome, que permite que seja alterado automaticamente o seu tamanho consoante os valores dejitter calculados. Este mecanismo permite balancear o delay com que se ouve o som recebido com o tamanho dobuffer, de forma a obter um melhor resultado.

Para asstreams de vídeo foram comparados os valores de RTT e os seus efeitos na taxa de frames recebidas.

Figura 5.7: Vídeo transmitido de ponto-a-ponto

Na Figura 5.7 são apresentados os gráficos obtidos na chamada em que os dados foram transmitidos de ponto a ponto, e pode-se verificar que a taxa deframes enviada e a taxa de frames recebida tem um padrão muito semelhante sendo que apenas algumas pequenas variações são visíveis. O RTT médio durante a chamada foi de 9ms.

Figura 5.8: Vídeo transmitido através do servidor

Tal como no caso do áudio, no segundo cenário onde a transmissão é feita através do servidor, o valor do RTT na transmissão de vídeo foi superior ao primeiro cenário, tendo o valor médio de 38ms.

Ao analisar astream de dados de vídeo no cenário b) da Figura 5.4, verifica-se uma variância muito semelhante à do cenário a). Estas variações são notadas nos dois cenários principalmente onde a taxa deframes enviados

é constante durante um período de tempo, como existem vários exemplos na linha dos 15frames por segundo. Ao fazer uma comparação com os respetivos valores nos gráficos deframes recebidas, verifica-se que a receção não é constante e que alguns dados são descartados ao longo de toda a chamada, não afetando no entanto a qualidade visível do vídeo.

Apesar de o RTT ser superior no segundo cenário, como mostra o terceiro gráfico da Figura-5.8, este é o comportamento esperado dado o processamento extra que é necessário na tradução de protocolos.

Após esta análise, verifica-se que apesar dos protocolos necessitarem de ser alterados, as taxas deframes recebidas não parece ter uma diferença notável quando comparada com o cenário onde os dados são trocados diretamente entrebrowsers. Estes são resultados muito positivos na medida em que permitem concluir que o componente de transmissão de média está a tratar os pacotes de forma rápida e sem afetar a sua qualidade.