ARQUITECTURA

Uma solução capaz de juntar a esta nova e mais sofisticada web os sistemas em tempo real, onde aplicações são embebidas nos browsers, começa por considerar a existência de duas entidades, vulgarmente conhecidas por peers ou pares. A web até então encontrava-se desenhada para que quando dois peers pretendessem comunicar um com o outro, as suas mensagens passassem por um servidor web. Recorrendo a um exemplo clássico, quando a Alice queria enviar uma mensagem ao Bob, estabelecia uma ligação com um determinado servidor, o Bob por sua vez também estabelecia uma ligação idêntica e a mensagem era enviada primeiro para o servidor e posteriormente do servidor para o Bob. O exemplo apresentado é facilmente compreendido por todos nós dado que o comportamento do servidor se assemelha em muito ao de um carteiro. Porém, facilmente conseguimos compreender que a este processo está associado um maior atraso do que quando decidimos entregar uma carta pessoalmente a um determinado individuo.

Protocolo UDP

Protocolo de transporte, descrito no RFC768 como um protocolo simples, sem estado e sem garantias, onde os seus pacotes (datagramas) carregam nada mais do que a informação necessária para a sua entrega. A ausência de garantias providenciadas pelo protocolo UDP apresenta-se assim como uma mais-valia na redução da latência, definindo uma base sólida para a construção de sistemas de partilha de voz e vídeo. A sua presença nos web browsers sem recorrer a nenhum plugin não era até recentemente uma realidade.

Protocolo ICE

Este baseia-se na criação de um agente ICE que tem como objetivo avaliar diferentes pares candidatos endereço ip, porto de modo a poder providenciar ao outro peer um endereço público no qual estará acessível.

Protocolos orientados à partilha multimédia

Não sendo o UDP um protocolo orientado à partilha de streams de multimédia, capaz de ter em consideração fatores como a sincronização ou a monitorização do tráfego, de modo a garantir uma determinada Qualidade de Serviço, ou mesmo a segurança da mesma comunicação, torna-se fundamental escolher/definir o protocolo indicado.
Descreveremos brevemente três:
Secure Real-Time Transport Protocol (SRTP);
Stream Control Transmission Protocol (SCTP);
Secure Real-Time Media Flow Protocol (SRTMFP).

Codecs

A definição dos codecs multimédia a implementar nos web browsers foi um passo importante rumo à garantia de ter sistemas interoperáveis.
Assim, após duras negociações, em Novembro de 2014, o IETF definiu quais os codecs de voz/ áudio e vídeo Mandatory to Implement (MTI). Para voz e áudio os codecs G.711 e Opus, respetivamente e para vídeo o H.264 e VP8 (que devem ser ambos implementados pelos web browsers e as outras aplicações nativas podem escolher apenas um).

Plugin? (S/N)

Adobe Flash based
Skype plugin
WebRTC
ORTC
OpenWebRTC

Aplicações

Simulação Local Simulação Remota

Apenas disponível em Firefox

Futuro

Conforme apresentado anteriormente, a busca de uma solução normativa tem, como sempre nestas situações, originado disputas pela sobreposição de interesses. Considerando três dos principais players do mercado: Google, Microsoft e Apple, o consenso não tem sido fácil de alcançar. Vejamos, quando a Google propõe uma solução as outras duas demoram a responder, até que se começam a envolver no processo e apenas muito tempo depois buscam fazer parte da solução ou desenvolver a sua “própria solução normativa”. A Apple, aqui referida, acaba por ser praticamente excluída da totalidade do documento uma vez que se tem autoexcluído da discussão. O principal motivo para esta atitude é a existência da aplicação nativa, principalmente vocacionada para o Universo Apple, disponível tanto em MacOS como nas plataformas móveis iOS, o FaceTime.
Por outro lado existe o mundo das operadoras de telecomunicações. Estas, sentido o foco do seu negócio a migrar da voz para os dados móveis, temem tornar-se gestores de uma mera rede de transporte de dados, tal como existe por exemplo no mercado da Energia. O aparecimento de soluções desenvolvidas pelo Skype, Google, Facebook, etc., vulgarmente designadas de Over-the-Top (OTT) fez com que algum valor acrescentado fosse-se dissipando.
Peculiarmente, as operadoras de telecomunicações acabam por procurar no WebRTC e noutros esforços de normalização uma nova afirmação, uma tentativa de antecipação e consequente tentativa de ganhar terreno para as ditas OTTs. Por exemple, o projeto europeu reThink, que tem por objetivos desenhar as redes de comunicação do futuro, propõe a criação de várias instâncias de servidores TURN na rede, capazes de direcionar tráfego especifico e desse modo cobrar um novo conjunto de serviços.
Por fim existe o problema do peer-to-peer. Dado o seu historial de uso para fins menos lícitos, existe uma grande apreensão por parte dos produtores de conteúdos quando surge uma solução deste tipo. Surge assim a necessidade de prova do real valor de uma solução como a apresentada, mesmo que por vezes o seu uso possa não ser o mais indicado.