Após o levantamento dos requisitos do produto sobre os ambientes em que deverá funcionar, e de uma discussão das possíveis abordagens a seguir, a análise ponderada destes dados é essencial para a obtenção de uma arquitetura mais adequada e expansível.
No campo da sinalização, a escolha é mais variada mas também mais critica a decisão sobre o caminho a seguir. Desde o protocolo até ao transporte, a escolha pode ser limitativa e fazer a diferença na altura das empresas escolherem o produto a comprar. No entanto, muitas são também as razões para escolher cada uma das combinações, e prova disso são as diferentes possibilidades que cada uma das empresas concorrentes está a implementar.
RCS REST API SIPstack WIT API
Protocolo de transporte HTTP WebSockets HTTP + WebSockets
Standard definido Sim (GSMA) Sim,draft (IETF) Não (WIT)
Cliente independente em redes de operadores Sim, em servidores com suporte Sim, em servidores com suporte Não, necesidade de Gateway Expansibilidade para
outros protocolos Não Não Sim
Complexidade no cliente Média Muita Média
Complexidade no
servidor Muita Pouca Média
Exposição de código fonte Exposto, reutilizável noutros servidores Exposto, reutilizável noutros servidores Não exposto, dependente do Gateway Tabela 3.1: Comparação das soluções para a sinalização
Ao nível do transporte a usar, é um facto que os WebSockets são muito mais rápidos e leves que a simulação de uma ligação bidirecional através de Long-polling, mas para suportar osbrowsers mais antigos, terá de se usar uma alternativa a esta recente tecnologia. Uma possibilidade é a utilização de um canalRTMP criado através do Flash Player, e possibilitando assim que os dados sejam enviados numa ligação bidirecional semelhante aos WebSockets. No entanto, se a ideia do WebRTC é a eliminação da necessidade deplugins, usar um plugin para uma tarefa tão importante seria prender o produto desde o início ao passado e ir contra aquilo que se pretende evitar. Ao contrário do Flash, que não é suportado em algunsbrowsers tais como os dos dispositivos móveis, os pedidos HTTP através de mecanismos de Ajax só não são suportados por uma muito pequena parte dos browsers.
A implementação da RCS REST API é complexa e mais indicada para a construção de clientes que precisem de algumas capacidades em particular, incluindo a integração em serviços de terceiros das capacidades de um cliente RCS. Apesar de esta utilizar os pedidos HTTP como transporte da sinalização e isso ser um ponto positivo no suporte de um grande número debrowsers, a implementação necessária de um mecanismo de autenticação e autorização de aplicações baseado em OAuth está fora do âmbito da criação de clientes Web que a empresa pretende alcançar com este projeto.
Um dos problemas das aplicações Web baseadas em Javascript é que apesar da possibilidade de minificação e ofuscação do código, existem também ferramentas que fazem parte do processo inverso e que permitem que o código seja mais facilmente lido por humanos[56]. Esta é uma grande preocupação quando se pretende criar um produto comercial baseado em Javascript e não se tem como objetivo a disponibilização do código.
Ao analisar as aplicações apresentadas no capitulo anterior, pode-se perceber que as que optaram pela se- gunda solução, utilizando uma implementação de SIP em Javascript e enviando os dados através de WebSockets, têm em comum o facto de serem projetos de código aberto. Assim, também desta forma a segunda opção,
apesar de trazer a vantagem de no futuro poder integrar diretamente com servidores que tenham suporte para Sip over WebSockets, e de funcionar num protocolo mais rápido e bidirecional, tem alguns problemas quando o objetivo é a construção de produtos comerciais.
Além disso, por ser baseado em WebSockets, esta solução traz o problema das versões dos browsers que suportam a tecnologia, e também o facto de se criar um cliente Javascript que não depende em nada do servidor onde se liga. Seguindo a implementação da solução apresentada na secção 3.3.2, a implementação do cliente estará toda disponível nobrowser permitindo assim a cópia dos ficheiros para que possam ser consultados como fonte ou mesmo após uma inspeção do código, a alteração para funcionar noutros serviços. Usando um outro servidor que implemente o protocolo WebSockets como transporte válido para SIP, é possível que o código seja utilizado por terceiros para a criação de clientes Web.
Além do SIP para sinalização de chamadas, é objectivo da empresa que o cliente no futuro possa continuar o seu desenvolvimento e ter muitas outras capacidades, desde o suporte para interação com servidores de sincronização de contatos através de XCAP ou SyncML até à sincronização do histórico de mensagens de uma dada conversa através do protocolo IMAP, como define a versão 5.1 da especificação RCS.
Assim sendo, a implementação de um cliente completo em Javascript que não exija a presença de um Gateway para tradução de protocolos, fica limitado ao que se puder implementar na aplicação Web. A utilização de protocolos que não funcionem sobre WebSockets ou HTTP estão assim limitados às capacidades dosbrowsers, visto que um aplicação Web não consegue atualmente gerir ligações TCP ou UDP para poder criar livremente pacotes na rede sem o recurso aplugins. Mesmo sem considerar estes protocolos, um dos mais utilizados na transferência de conteúdos entre aplicações RCS é o MSRP, que terá nesta solução de ser implementado através de WebSockets e não está descrita a forma de o fazer, havendo a possibilidade de várias empresas o fazerem de forma diferente e surgir assim um problema de interoperabilidade.
(a) Integração com redes de terceiros
(b) Integração com servidor da empresa
Ambas as soluções já mencionadas cumprem casos específicos de utilização das aplicações, sendo que estão limitados por não poderem depender de um ponto na rede que consiga implementar com mais facilidade qualquer protocolo que se pretenda incluir. Assim, e analisando as vantagens e desvantagens de cada uma das hipóteses de sinalização descritas em 3.3, a implementação de um Gateway capaz uma traduzir uma API parece ser o mais adequado, pois permite que se use um transporte à escolha.
Para que um Gateway de tradução de protocolos seja escalável, num cenário em que se encontre em produção numa rede com um grande número de utilizadores, este deve ser equilibrado para que não contenha muita lógica de negócio de cada uma das capacidades do cliente mas também permita que a tradução dos pedidos não ocupe muitos recursos. Ora este objetivo começa com a definição da API, que analisando as duas primeiras soluções deve tentar encontrar um meio termo para que não coloque toda a carga no Gateway (i.e. RCS {REST API) nem que sirva apenas para a troca de transporte deixando a carga toda no cliente (i.e. SIP over WebSockets).
Para permitir a criação de aplicações mais dinâmicas, que suportem as tecnologias mais recentes para uma melhor performance quando estas estiverem disponíveis (i.e. WebSockets) e que suportem osbrowsers antigos através de pedidos standard HTTP, permitindo também a criação de clientes mais leves, a implementação de um Gateway para tradução de uma API proprietária parece ser a escolha mais sensata para esta arquitetura, pela flexibilidade que permite dar às aplicações.
Atualmente a WIT tem um cliente Web todo baseado em Flash e que utiliza uma API para comunicação com o servidor, mas esta não é baseada em JSON mas sim em variáveis passadas em objetos Action Message Format (AMF) que são transmitidos por RTMP. Neste momento o Gateway que a empresa possui está muito dependente da utilização de clientes Flash, até porque esta depende do WMS, que permite a comunicação com o Flash Player. No entanto esta API pode ser melhorada e transformada numa linguagem genérica que permita a integração de outros protocolos de transporte como o HTTP, WebSockets ou outros que possam surgir no futuro. Apesar desta solução ficar sempre dependente da existência de um componente na rede onde se pretender colocar em produção os clientes, este também será o caso mais comum na medida em que será necessário que os clientes Web também tenham capacidades que precisam de outros protocolos não implementáveis em Javascript atualmente. No entanto a arquitetura a definir para os clientes Web deve também ter em conta que no futuro pode haver interesse em implementar um dos standards, devendo por isso ser modular o suficiente para que a integração com outros sistemas não seja o processo penoso de não reaproveitar nada do trabalho já realizado.
Para a média, o protocolo está definido e será SRTP com todas as especificidades que o WebRTC define, não deixando margem para dúvidas nesse aspecto. Assim, a discussão neste campo cinge-se apenas ao local onde se vão implementar as novas especificações usadas pelo WebRTC.
Cenário 1 Cenário 2 Cenário 3
Com que servidor integra
o cliente? WIT Application Server WIT Application Server
Rede do Operador ou Servidor IMS Com que clientes
necessita de interoperar? Apenas clientes Web
Clientes Web + Clientes SIP/VoIP
Clientes Web + Clientes SIP/VoIP + PSTN Onde implementar o
suporte para a média WebRTC?
Não é necessário WIT Server ou Clientes SIP/VoIP
Gateway ou Rede do Operador Tabela 3.2: Análise da integrabilidade da média em cada cenário
Para cumprir os vários cenários em que as outras aplicações da empresa integram, é necessária a implemen- tação do processamento da média produzida pelosbrowsers. Mas esperar que todos os produtores de aplicações e de servidores com que se pretende integrar, implementem as novas especificações quando estas estiverem prontas, não é a solução ideal. Além disso, faz parte dos objetivos deste trabalho conseguir a interoperabilidade entre as aplicações atuais e as aplicações Web que utilizem WebRTC sendo que para isso é necessário dar o primeiro passo.
A implementação pode ser feita nas aplicações cliente mas, apesar de ser sempre positivo ter suporte para os protocolos mais recentes, o esforço das equipas seria muito grande e seria avançar com a implementação de uma especificação que está ainda na sua fase de criação. Para a integração com redes de operadores ou outros servidores atuais sem este suporte, é necessário que se implemente esta especificação no Gateway para permitir uma tradução para os standards atuais. Se esta tarefa for feita de forma a que o Gateway torne transparente para os clientes e servidores SIP que os dados de média estão de facto a vir de umbrowser, não será necessário implementar em mais nenhum ponto da rede, sendo toda a média redirecionada pelo Gateway.
Na Tabela 3.2 pode-se ver uma comparação dos cenários de integração apresentados anteriormente, e anal- isando os componentes onde é necessária a implementação dos protocolos de média, conclui-se que é possível cumprir todos os cenários implementando apenas no servidor da WIT/Gateway.