4.3 Servidor Gateway
4.3.2 Transformação de média WebRTC
Para processar a média produzida pelos browsers com suporte para WebRTC, permitindo assim que as apli- cações Web comuniquem com clientes sem este suporte, vários protocolos foram estudados e analisados para se perceber o que seria necessário suportar na Gateway.
Como primeiro ponto de análise, os dados de média WebRTC transportados pelo protocolo DTLS-SRTP são os mesmos que os transportados pelo protocolo RTP, usado pelo mais simples e banal cliente VoIP, se estiverem a utilizar o mesmo Codec. Portanto, para além das novas técnicas de encriptação, transporte e negociação dos
canais por onde a média é enviada, os dados a transportar são os mesmos e a implementação do componente da transformação de média no Gateway foi baseada neste facto.
Tal como explicado na secção 2.4.2, os vários mecanismos definidos pela Google como obrigatórios na im- plementação, têm como objetivo a melhoria da segurança e do estabelecimento das ligações entre dois pontos na rede para a troca de dados. Todos estes mecanismos são negociados através do SDP trocado durante a sinalização de uma chamada, e um exemplo disto pode ser encontrado na Listagem 2.6.
Alguns dos campos encontrados no SDP são oscandidates, que representam os conjuntos ordenados de IP/portos onde o cliente estará à espera de receber os dados. Para ter acesso aos IPs públicos bem como aos portos disponíveis, obrowser precisa de consultar um servidor STUN, que irá responder com estas infor- mações. Ao contrário de um servidor com capacidades TURN que tem de fazer deproxy de média, a informação dada por um servidor de STUN é fácil de fornecer, e por isso existem alguns servidores de acesso público (e.g stun.ekiga.net:3478) que podem ser utilizados livremente para obter estas informações.
No entanto, para não depender de serviços externos, foi implementado no servidor da empresa um módulo para funcionar como servidor de STUN para que possa ser utilizado pelas aplicações a desenvolver. Esta im- plementação foi feita utilizando a bibliotecaice4j9passando assim o servidor a receber pedidos dosbrowsers e
respondendo com a informação visível no exterior das redes onde estes se encontram. Este processo é iniciado numa fase anterior ao envio do INVITE inicial para a chamada, dado que são informações que este pedido já deve conter.
A ligação entre a lógica sobre a qual o servidor esteja a correr e o processador de média foi criada sobre a forma de mapeamentos, em que esta apenas é utilizada quando existe a necessidade de tradução. Através de configuração, é possível definir entre que tipos de clientes é necessária a tradução e entre quais o servidor não serve de intermediário. Assim, de uma forma geral, consegue-se definir por exemplo que entre dois clientes que utilizem WebSockets, o SDP não deve ser alterado pelo componente transformador de média, e sempre que seja para interoperar estes com outro qualquer cliente, é necessário haver a simplificação dos protocolos.
Quando é necessária a transformação de média WebRTC em média através de protocolos standard, a lógica do servidor passa o SDP do INVITE inicial da chamada para o componente de processamento de média representado na Figuras 4.5 e 4.4. Aí o SDP é processado utilizando a bibliotecajain-sip que ajuda a fazer a desconstrução textual para uma representação em objetos mais facilmente utilizáveis na aplicação. É então utilizada toda a informação recebida para criar um tradutor responsável por comunicar com a aplicação cliente que está a iniciar a chamada usando os IPs, portos, chaves de autenticação e detalhes sobre os Codecs e formas de transporte.
Em seguida o SDP é transformado de acordo com o tipo de aplicação cliente que o destinatário da chamada estiver a usar e é criado um outro tradutor que será responsável por tratar da comunicação da média entre este componente e o cliente destino. Este tradutor é já criado com base nos IPs do servidor, pois será com este que a aplicação destino irá trocar a média. Após ser alterado, o SDP é enviado no protocolo que cada aplicação estiver a usar.
Quando a chamada é aceite outro SDP é transmitido, desta vez com os dados que a aplicação destino decidiu utilizar, baseados na oferta inicial. O SDP desta resposta faz o percurso inverso do pedido, começando por definir no tradutor que vai trocar média com o destinatário quais os IPs e portos deste, bem como quais os protocolos a usar para autenticação e transporte. Em seguida o SDP é alterado pelo tradutor do iniciador da chamada, definindo os detalhes para a troca de média com o tradutor responsável, sendo em seguida enviada a resposta final para a aplicação que começou a chamada.
9https://code.google.com/p/ice4j/
Figura 4.6: Esquema da tradução de média WebRTC
Neste processo, um dos clientes pode ser um cliente com suporte para WebRTC e outro sem suporte, não sendo importante qual inicia a chamada, pela forma simétrica como foram implementados os tradutores. Após esta negociação estar completa, ambos os clientes começam a comunicar através do servidor.
Para iniciar esta comunicação com o cliente standard SIP, o tradutor começa por abrir os portos negociados para os pacotes RTP e, se tiver sido negociado, os portos para os pacotes RTCP. Assim, os dados são recebidos e enviados para este cliente através da utilização da bibliotecaefflux10, que facilita na transformação entre pacotes
RTP e a sua representação em objetos.
No tradutor de um cliente WebRTC, é necessário dar alguns passos extra, para garantir segurança e as melho- rias definidas pela Google. Ao iniciar a comunicação, após a negociação dos valores na sinalização, o tradutor inicia o processo de ICE, tentando estabelecer uma ligação com o cliente num dos IPs e transportes negociados. Este mecanismo foi implementado com os requisitos de segurança necessários, e para facilitar o processo foi utilizada a bibliotecaice4j novamente, dado que a verificação de conectividade definida pelo protocolo é baseada em pedidos STUN autenticados.
Após a descoberta do canal onde obrowser está contactável, a transmissão de média é iniciada e é ativado o mecanismo que utiliza um codificador e um descodificador de pacotes baseado em DTLS-SRTP. Estes com- ponentes inicializados com as chaves de encriptação negociadas foram construídos com recurso à biblioteca libjitsi11.
Foi também implementado um mecanismo que respeita a especificação BUNDLE criada pela Google, para ser possível enviar e receber os dados de áudio e de vídeo e as respectivas sessões de RTCP dentro da mesma stream usando a mesma ligação. Como mostra a Figura 4.6, do lado dos clientes WebRTC todos os dados são passados dentro do mesmo canal, dispensando apenas uma porta para a chamada. Do lado dos clientes standard, é necessário criar um canal para cada tipo de dados.
10https://github.com/brunodecarvalho/efflux 11https://jitsi.org/Projects/LibJitsi
Capítulo 5
Testes e Integrações
Após a implementação dos vários componentes já referidos, foram feitos vários testes e demonstrações do trabalho realizado. A aplicação foi demonstrada em vários locais a diferentes entidades, e foram feitas diversas integrações em diferentes modos de funcionamento. Em seguida são descritas algumas destas operações com a finalidade de mostrar o grau de usabilidade do sistema alcançado.
Foram também realizados testes com o intuito de saber quais as limitações de cada componente e de que forma esta solução é comparável com outras soluções já desenvolvidas usando a mesma ou outras tecnologias.
5.1 Integrações e demonstrações
Há medida que foi sendo implementado, todo o sistema foi sendo mostrado em vários pontos do mundo, sendo que o primeiro lançamento teve lugar no Congresso Mundial de Comunicações Móveis (MWC1), de 25 a 28 de
Fevereiro de 2013 em Barcelona, Espanha. Além de outras novidades2, a WIT mostrou a nova versão de um
cliente Web todo baseado em Javascript e HTML5 com suporte para chamadas utilizando WebRTC3.
Esta versão do cliente foi demonstrada já com suporte para a troca de capacidades suportadas e chat re- speitando as regras definidas pela GSMA nas especificações RCS. A aplicação tinha também a capacidade de carregar e mostrar uma lista de contatos a partir do servidor. A integração deste cliente foi criada num servidor em modostandalone (como apresentado na figura da secção 3.2.2), onde os outros clientes da empresa tam- bém eram demonstrados, conseguindo a interoperabilidade com estes. O servidor estava registado através de SIP na rede VoIP de um operador móvel, através do qual era possível fazer ou receber chamadas para qualquer número de telefone mundial, tendo sido esta uma das demonstrações mais vistas nostand da empresa durante a feira. A UI da aplicação utilizada para esta demonstração foi a apresentada na Figura 4.1.
À semelhança da versão para demonstrações, foi também criada uma página Web parabrowsers de disposi- tivos móveis, apenas com as capacidades de carregamento da lista de contatos, troca de capacidades suportadas entre aplicações e chat, já que até à data nenhumbrowser para dispositivos móveis tinha suporte estável WebRTC. Após esta apresentação inicial, todo o ecossistema foi colocado num servidor público para ser possível o acesso a partir de qualquer parte do mundo. Assim, usando um servidor com uma configuração idêntica à mostrada no MWC, a aplicação foi demonstrada em reuniões com a várias operadoras de todo o mundo, incluindo países como Canadá, Brasil, Austrália, América do Norte e vários países da Europa, sempre usando as mesmas UIs de demonstrações.
1http://www.mobileworldcongress.com/
2http://callcenterinfo.tmcnet.com/news/2013/02/20/6935463.htm 3http://cisco-news.tmcnet.com/news/2013/02/22/6942135.htm
Para uma operadora do Reino Unido foi realizado um Proof Of Concept (POC) em que era essencial provar a possibilidade de integração da capacidade de chamadas na página Web da marca. Assim, foi ignorado o UI de demonstrações e utilizando apenas a SDK Javascript existente, a integração das chamadas na página foi simples e a demonstração da funcionalidade foi possível.
Em todas estas demonstrações foi possível demonstrar as chamadas de vídeo utilizando dois clientes Web, sendo a chamada feita entre doisbrowsers devido à falta de suporte do Codec VP8 na generalidade dos clientes SIP. Nestas chamadas, o modo de utilização do servidor foi semelhante ao apresentado na secção 3.2.1, sendo a transmissão de média feita diretamente entre os doisbrowsers.
Foi também realizada uma demonstração utilizando o cenário 3, apresentado na Figura 3.3, demonstração essa que foi importante para a conclusão dos cenários de integração necessários. Para demonstrar o suporte para o tratamento de média WebRTC, a Acme-Packet pediu uma integração do novo cliente Web da WIT com a versão mais recente do seu SBC, para poderem demonstrar na sua feira anual Acme INTERCONNECT 20134
que aconteceu em Las Vegas, de 24 a 26 de Abril. Esta integração exigiu testes que ainda não tinham sido necessários, em que a aplicação Web necessita de integrar com uma rede de um operador externo. Mais ainda, o cenário que interessava mostrar era a capacidade que o novo SBC tem no tratamento da média WebRTC. Foi por isso necessário dar utilidade à modularidade do Gateway desenvolvido, e configurar o mesmo para a utilização de uma rede remota com a particularidade de a média não ser tratada pelo Gateway, pois pela primeira vez o endpoint SIP com o qual íamos integrar tinha a capacidade de trocar a média diretamente com um browser.
Assim, o componente de transformação de média foi configurado para não interferir nos SDPs, sendo este apenas transmitido entre os dois pontos. Para esta integração o servidor foi instanciado numa máquina virtual daAmazon EC2, para uma alta disponibilidade com o intuito de evitar problemas nas demonstrações durante a feira. A UI disponibilizada para este evento foi a mesma apresentada no MWC, mas com as funcionalidades RCS desativadas, já que o único objetivo era a demonstração de chamadas de áudio.
De 25 a 27 de Junho de 2013, a Acme-Packet voltou a demonstrar as capacidades da aplicação e do Gateway em Atlanta, noGlobal WebRTC Ecosystem Event5. O sistema foi utilizado com a mesma configuração, mas desta
vez já com suporte para a partilha de ficheiros com outras aplicações, segundo a especificação RCS.