DECLARAÇÃO. Nome: André Manuel Rodrigues da Silva Endereço Electrónico: pg17619 <at> alunos.uminho.pt Nº do Bilhete de Identidade:

Transcrição

1

2

3

4 DECLARAÇÃO Nome: André Manuel Rodrigues da Silva Endereço Electrónico: pg17619 <at> alunos.uminho.pt Nº do Bilhete de Identidade: Título da Dissertação: Novas Arquiteturas Web para aplicações VoIP Orientadores: Professor António Duarte Costa Professora Maria João Nicolau Ano de conclusão: 2013 Designação do Mestrado: Mestrado em Engenharia Informática DE ACORDO COM A LEGISLAÇÃO EM VIGOR, NÃO É PERMITIDA A REPRODUÇÃO DE QUALQUER PARTE DESTA TESE. Universidade do Minho, 2013/06/27 Assinatura:.

5 Agradecimentos Aos meus pais acima de tudo, pelo apoio em todos os momentos, mas mais que isso, por todo o esforço e apoio incondicional que permitiu que hoje eu consiga viver a fazer aquilo que gosto. Às mulheres da minha vida Elsa, Teresa e Catarina pelo apoio e paciência de sempre e para sempre. À Ana, minha mais que tudo, pela motivação, amor, amizade, paciência e compreensão durante este projeto. Aos orientadores desta dissertação Professor António Duarte Costa e Professora Maria João Nicolau por toda a disponibilidade e atenção dispensadas. À WIT-Software por me dar estas oportunidades de investigação que me fazem crescer. Aos amigos... A todos a minha gratidão. iii

6

7 Resumo Com o aparecimento de dispositivos de áudio e vídeo a preços baixos, da sua inclusão em qualquer computador, e com o aumento da velocidade das ligações à Internet, surgiu o interesse em criar sistemas capazes de fazer chamadas através desta rede (Voice over IP (VoIP)). Motivada pela migração das aplicações do desktop para o browser, a Google decidiu criar uma nova tecnologia para permitir aos browsers o acesso nativo a câmaras e microfones, bem como a capacidade de comunicação direta de áudio e vídeo entre browsers. Esta tecnologia designa-se por Web Real Time Communication (WebRTC) e tem como principal objetivo permitir que todo um leque de aplicações, nomeadamente aplicações VoIP possam também ser migradas para páginas Web sem a necessidade de utilizar plugins externos, que podem não ser compatíveis com os diferentes browsers e sistemas operativos. A WIT-Software S.A. (WIT), empresa especialista em aplicações móveis e em soluções que convergem vídeo, áudio, serviços de mensagens e de transferências de conteúdos, disponibiliza versões destas soluções para PC, Android, iphone, ipad, Symbian e Web. Esta última foi criada usando a framework Flex e recorrendo ao plugin Adobe Flash. Com o aparecimento de tecnologias emergentes como o WebRTC e o HyperText Markup Language 5 (HTML5), surgiu um novo desafio para a definição de uma nova arquitetura para os produtos VoIP web-based, incluindo a criação de um cliente que cumpra as normas Rich Communications Services (RCS). No contexto deste projeto foi criada uma aplicação Web que dispensa a instalação de qualquer plugin adicional, com capacidade de fazer e receber chamadas de áudio e vídeo baseadas em WebRTC, e com algumas funcionalidades RCS. A aplicação final foi construída numa arquitetura escalável e future-proof e é capaz de interoperar com as restantes aplicações da empresa, e mesmo com outros sistemas standard VoIP. O sistema construído foi demonstrado em vários eventos por todo o mundo.

8

9 Abstract The appearance of cheap audio and video devices and the fact that they are already included in almost all computers, added to the availability of higher speed Internet connections, have increased the interest in the creation of a system capable of establishing calls in this network (VoIP). Lately, the number of applications that are being migrated from desktop to browsers have increased and so, Google decided to create a technology proposal to allow browsers native access to microphones and cameras, and also the capability to exchange multimedia data between browsers. The created technology is called WebRTC and its main purpose is to allow that a whole new segment of applications, namely VoIP applications, can also be migrated to Web pages without the use of external plugins, that bring problems when dealing with different Operative Systems and different browsers. WIT it s a Portuguese company focused in mobile applications and solutions that converge video, audio, instant messages and content transfer, offers several applications with such capabilities for PC, Android, iphone, ipad, Symbian and Web. This last one was built using Flex framework based on Adobe Flash plugin. With the emergence of technologies such as WebRTC and HTML5, a new challenge appeared for the definition of a new architecture for web-based VoIP products, including the creation of a client that follows the RCS specifications. A new Web application was developed in the context of this project, that does not need the installation of any external plugin in the browser, and has the capability to start and receive WebRTC audio and video calls and also some RCS capabilities. The final application was built under a scalable and future-proof architecture and is able to inter-operate with all the current applications of the company and with other standard systems. The built system was demonstrated in several events all over the world.

10

11 Índice Índice Índice de Imagens Índice de Tabelas Índice de Listagens Acrónimos ix xi xiii xv xvii 1 Introdução Motivação Tecnologia Empresa e Produto Objetivos Contribuições Estrutura da dissertação Voz sobre IP - Estado atual da tecnologia Session Initiation Protocol (SIP) Sessões de média VoIP em contexto WEB Tecnologias para construção de Rich Internet Application (RIA)s Tecnologia WebRTC Sinalização Média Projetos relacionados Produtos Concorrentes Discussão e Conclusões Requisitos e Arquitectura da solução Requisitos de aplicações RCS Requisitos dos cenários de integração Cenário 1: Servidor standalone com clientes Web Cenário 2: Servidor standalone com vários clientes Cenário 3: Clientes Web interligados com a Public Switched Telephone Network (PSTN) 54 ix

12 3.3 Sinalização - possíveis soluções RCS Representational State Transfer (REST) Application Programming Interface (API) SIP através de WebSockets API privada através de WebSockets ou Hypertext Transfer Protocol (HTTP) Média Discussão da solução Arquitetura dos componentes Servidor Aplicação Web Implementação Comunicação aplicação - servidor WIT API WebSockets HTTP - Long Polling Aplicação Web Software Development Kit (SDK) Interface gráfica - User Interface (UI) Servidor - Gateway Tradução de sinalização Transformação de média WebRTC Testes e Integrações Integrações e demonstrações Testes e resultados Sinalização e média Message Session Relay Protocol (MSRP) Média VoIP Testes futuros Conclusão Síntese do trabalho realizado Processo e decisões tomadas Trabalho futuro Notas finais Bibliografia 101 A API Javascript 105 B Código necessário para fazer chamadas 109 x

13 Índice de Imagens 1.1 Visão do objetivo geral Esquema do estabelecimento de uma sessão SIP Arquitetura dos Websockets Esquema da arquitetura WebRTC a definir nos browsers Esquema do enquadramento do WebRTC na rede Clientes web standalone Clientes standalone Clientes web numa rede operador Esquema do gateway de transformação necessário para a RCS REST API Esquema da utilização de SIP através de WebSockets Esquema do Gateway de tradução de uma API privada Soluções a criar para cumprir os cenários requeridos Arquitetura dos componentes do Gateway / Servidor Arquitetura da aplicação Web Aplicação após registo Aplicação durante uma sessão de chat Aplicação durante uma chamada de vídeo Esquema da tradução da WIT API no servidor da empresa Esquema da tradução da WIT API para protocolos standard em VoIP Esquema da tradução de média WebRTC Disponibilização do Gateway em produção utilizando WebSockets Utilização do Central Processing Unit (CPU) em teste de carga Níveis de utilização de memória em teste de carga Cenários usados para testar a qualidade da re transmissão de média Áudio transmitido de ponto-a-ponto Áudio transmitido através do servidor Vídeo transmitido de ponto-a-ponto Vídeo transmitido através do servidor xi

14

15 Índice de Tabelas 2.1 Utilização de cada tecnologia em páginas Web Tabela comparativa de algumas soluções atuais Comparação das soluções para a sinalização Análise da integrabilidade da média em cada cenário xiii

16

17 Índice de Listagens 2.1 Exemplo de um pedido SIP REGISTER e respectiva resposta [1] Exemplo de um pedido SIP com o Session Description Protocol (SDP) para negociar uma chamada de áudio [1] Esquema do funcionamento das notificações Exemplo de uma mensagem instantânea enviada com o comando MESSAGE [2] Exemplo da negociação de uma sessão MSRP[3] Exemplo de um SDP gerado pelo Google Chrome Exemplo de um objeto JavaScript Object Notation (JSON) para iniciar uma chamada (pedido cliente-servidor) Exemplo de um objeto JSON com resposta provisória do servidor Exemplo de um objeto JSON com um pacote de média Exemplo de um objeto JSON com um pacote com uma resposta de média Exemplo de utilização da SDK na criação de uma sessão xv

18

19 Acrónimos 3GPP 3rd Generation Partnership Project Ajax Asynchronous JavaScript + XML AMF Action Message Format ASCII American Standard Code for Information Interchange API Application Programming Interface Codec Compression/Decompression Module CPIM Common Presence and Instant Messaging CPU Central Processing Unit CU-RTC-Web Customizable, Ubiquitous Real Time Communication over the Web DOM Document Object Model DTLS Datagram Transport Layer Security GSMA Groupe Speciale Mobile Association HTML5 HyperText Markup Language 5 HTML HyperText Markup Language HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure ICE Interactive Connectivity Establishment IMAP Internet Message Access Protocol IETF Internet Engineering Task Force IAX2 Inter-Asterisk exchange v2 IE Internet Explorer xvii

20 ilbc Internet Low Bitrate Codec IMS IP Multimedia Subsystem IP Internet Protocol isac Internet Speech Audio Codec ITU International Telecommunication Union JVM Java Virtual Machine JSEP JavaScript Session Establishment Protocol JSON JavaScript Object Notation JSON-RPC JSON-Remote Procedure Call (RPC) LGPL Lesser General Public License MSRP Message Session Relay Protocol MVC Model View Controller MWC Mobile World Congress NAT Network Address Translation NAT-T Network Address Translation - Traversal NIO New Input/Output OMA Open Mobile Alliance OTT Over-The-Top PC PeerConnection POC Proof Of Concept PCMA Pulse Code Modulation A-law PCMU Pulse Code Modulation U-law PSTN Public Switched Telephone Network QoE Quality of Experience QoS Quality of Service RCS Rich Communications Services xviii

21 REST Representational State Transfer RIA Rich Internet Application ROAP RTCWeb Offer/Answer Protocol RPC Remote Procedure Call RTT Round-Trip Time RTP Real Time Protocol RTCP Real Time protocol Control Protocol RTMP Real Time Messaging Protocol SBC Session Border Controller SDK Software Development Kit SDP Session Description Protocol SIP Session Initiation Protocol SMS Short Message Service SRTP Secure Real Time Protocol STUN Session Traversal Utilities for Network Address Translation (NAT) SyncML Synchronization Markup Language TCP Transmission Control Protocol TLS Transport Layer Security TURN Traversal Using Relays around NAT UDP User Datagram Protocol UI User Interface URI Uniform Resource Identifier VoIP Voice over IP W3C World Wide Web Consortium WebRTC Web Real Time Communication WHATWG Web Hypertext Application Technology Working Group xix

22 WIT WIT-Software S.A. WLM Windows Live Messenger WMS Wowza Media Server XCAP XML Configuration Access Protocol XML extensible Markup Language XMPP extensible Messaging and Presence Protocol xx

23 Capítulo 1 Introdução Nos últimos anos tem-se verificado uma crescente migração das aplicações nativas de Desktop para aplicações Web. Também a comunicação em tempo real tem sofrido uma grande evolução com o recurso às chamadas Voice over IP (VoIP), existindo já várias aplicações integradas nas redes sociais que permitem chamadas de áudio e vídeo gratuitas, tanto a partir da Web como de aplicações para dispositivos móveis. Acompanhando esta tendência, e com o aparecimento de novas tecnologias emergentes, surge a necessidade de definir novas arquiteturas para aplicações Web. Este projeto faz uma análise sobre estas novas ferramentas e mostra como estas podem ser utilizadas na construção de novas aplicações Web capazes de fazer chamadas para outras aplicações VoIP genéricas ou mesmo para telefones fixos ou móveis. 1.1 Motivação Hoje em dia, para um browser poder efetuar chamadas necessita de recorrer às capacidades de alguns plugins externos. Um dos mais utilizados é o Adobe Flash que permite o acesso a câmaras e microfones do dispositivo, e disponibiliza facilmente a criação de streams através das quais se pode transmitir áudio e vídeo. Este plugin, apesar de estar presente em grande parte dos dispositivos, já foi alvo de muitas críticas e criou alguns inimigos ao longo do seu desenvolvimento. É o caso da Apple que não dá suporte nem inclui este plugin nos seus dispositivos e que causa por isso uma quebra de compatibilidade com um número já grande de utilizadores. Em 2010 numa carta aberta 1, Steve Jobs explicou as razões pelas quais achava que o Flash não era a tecnologia ideal para mostrar conteúdos na Web, baseando os seus argumentos no largo consumo de recursos que o plugin exige, no facto de ser uma plataforma fechada em contraste com o HyperText Markup Language 5 (HTML5) que a Apple apoia e por ser construído para Desktop, não estando preparado para os novos paradigmas de interação através de toque. Uma das limitações do Adobe Flash é a necessidade de se enviar os dados de média para um servidor para que este possa traduzir o protocolo de transporte, no caso de se querer integrar com outros clientes que utilizem os protocolos standard de aplicações VoIP, forçando assim a que seja necessária uma maior infra-estrutura de servidores maior no caso de colocação em produção de um sistema destes. Vários standards estão a ser definidos no contexto do HTML5, convergindo para as capacidades que são alcançáveis atualmente através de plugins. A procura por soluções alternativas e normalizadas tem motivado a comunidade científica a investigar novas formas de permitir comunicações em tempo real através dos browsers

24 1.1.1 Tecnologia A Google criou no início de 2011 uma proposta de especificação de uma tecnologia que dotasse os browsers das mesmas capacidades de um cliente VoIP, revolucionando assim este sector de negócio. A especificação Web Real Time Communication (WebRTC) criada desde então envolve 3 grandes objetivos: 1. Permitir que os browsers tenham acesso nativo aos microfones e câmaras dos dispositivos; 2. Dotar os browsers da capacidade de comunicação independente de áudio e vídeo de forma segura através do protocolo Secure Real Time Protocol (SRTP); 3. Disponibilizar uma implementação de um canal de dados através do qual dois browsers possam trocar dados diretamente de forma a permitir a criação de aplicações de comunicação interativa. Ao mesmo tempo que a especificação está a ser criada, esta está também a ser implementada pelos browsers, sendo que se pode já desde há algum tempo usar e desenvolver aplicações com esta tecnologia utilizando versões dos browsers para programadores. Para um utilizador comum estas capacidades começam a ficar acessíveis, tendo a Google lançado na versão oficial do Chrome já o primeiro e segundo objetivos implementados num estado funcional, apesar de a especificação ainda não ser final (Maio 2013). Também já implementado pelas versões mais recentes dos browsers e em estado de maturação está o HTML5, que veio permitir entre muitas coisas, a reprodução nativa de áudio e de vídeo. Esta nova versão do HyperText Markup Language (HTML) vem tentar corrigir as divergências existentes nas várias implementações das versões anteriores, tentando assim criar uma ferramenta muito poderosa para a criação de páginas Web interativas e muito completas, com a possibilidade de manipulação de objetos gráficos, som e vídeo Empresa e Produto A WIT-Software S.A. (WIT) é uma empresa especialista em aplicações móveis e em soluções que convergem vídeo, áudio, serviços de mensagens e de transferência de conteúdos, disponibilizando versões destas soluções para PC, Android, iphone, ipad, Symbian e Web. A aplicação Web foi criada usando a framework Flex e recorrendo ao plugin Adobe Flash, permitindo atualmente fazer chamadas de áudio e vídeo e enviar SMS/MMS, bem como todo o leque de funcionalidades referidas na especificação da Groupe Speciale Mobile Association (GSMA). Em 2011 a WIT foi selecionada mundialmente como fornecedora das aplicações Rich Communications Services (RCS) oficiais e está desenvolver as mesmas segundo as especificações da GSMA. Todos os produtos deste ecossistema da WIT comunicam através do protocolo Session Initiation Protocol (SIP) que é bastante utilizado hoje em dia nas aplicações VoIP. Para que o cliente Web pudesse também comunicar com clientes SIP, foi necessária a construção de um Gateway que conseguisse traduzir pedidos recebidos do cliente Flash por Real Time Messaging Protocol (RTMP) em pacotes SIP e vice-versa. A WIT está atenta aos desenvolvimentos e atualizações das tecnologias na área das comunicações, e com o aparecimento da tecnologia WebRTC, pretende naturalmente redesenhar a arquitetura do seu produto Web de forma a que tenha os seus clientes VoIP compatíveis com as novas tendências de mercado. Este projeto enquadra-se neste âmbito, sendo do interesse da empresa que seja analisada a tecnologia emergente WebRTC e a possibilidade de construção de aplicações Web com as capacidades das restantes aplicações da empresa sem o recurso a plugins. 22

25 As aplicações RCS têm hoje em dia um crescente interesse comercial e como tal, é também preocupação da empresa que o resultado da nova arquitetura não comprometa a totalidade da solução, ao acesso a terceiros, dada a natureza aberta das linguagens utilizadas na Web (HTML5 e Javascript). 1.2 Objetivos O objetivo deste trabalho foi a definição de uma nova arquitetura para um cliente Web que utilize a tecnologia WebRTC. Para isso, foi necessário cumprir vários objetivos de investigação e desenvolvimento inicialmente propostos, que são descritos em seguida. Figura 1.1: Visão do objetivo geral Analisar o estado atual dos desenvolvimentos na área das aplicações VoIP, incluindo a nova tecnologia WebRTC; Estudar o protocolo SIP de forma a poder criar uma arquitetura que interligue um cliente Web com qualquer cliente SIP genérico; Fazer um levantamento das várias possibilidades de transporte de sinalização e comparar todas as possibilidades encontradas analisando as vantagens e desvantagens da sua utilização, justificando a decisão tomada; Investigar quais os protocolos para o transporte de média e soluções para ultrapassar problemas de Network Address Translations (NATs). Conceber uma possível arquitetura e implementar uma biblioteca Javascript que utilize a tecnologia WebRTC, de forma a permitir a fácil criação de aplicações Web com capacidades VoIP; Preparar a arquitetura para uma futura integração com as funcionalidades definidas nas normas RCS, definidas pela GSMA; Disponibilizar um novo cliente Web que cumpra as normas RCS baseado na tecnologia WebRTC e HTML5 para utilizar em demonstrações; 23

26 Garantir a interoperabilidade entre o sistema obtido e as restantes aplicações da WIT; Comparar o resultado obtido com os possíveis concorrentes e com as soluções atuais; 1.3 Contribuições Como resultado final deste projeto foram dados vários passos que permitiram cumprir os objetivos propostos. A construção de vários componentes para a disponibilização final de uma aplicação Web deu origem aos seguintes contributos: Foi construído um Gateway capaz de processar uma Application Programming Interface (API) genérica através de vários protocolos de transporte, usando um componente de tradução da sinalização capaz de aceitar clientes Flash, WebSockets ou Hypertext Transfer Protocol (HTTP) Long Polling; Foi definida uma biblioteca Javascript capaz de abstrair a lógica de estabelecimento de chamadas WebRTC, bem como das funcionalidades RCS; Foi elaborada uma interface gráfica para permitir demonstrar as capacidades implementadas na Gateway e biblioteca Javascript. Foram feitas várias integrações e demonstrações em congressos mundiais (Mobile World Congress (MWC) 2013 e ACME INTERCONNECT 2013) e a operadores telefónicos de várias partes do mundo. Mostrou-se a capacidade de reutilização da biblioteca construída com a criação de novas interfaces gráficas específicas para um operador. Foi feita a integração da Gateway com serviços externos para permitir o estabelecimento de chamadas de e para a Public Switched Telephone Network (PSTN). 1.4 Estrutura da dissertação Este primeiro capítulo dá a conhecer o contexto da investigação, com uma descrição dos temas em que se insere, o contexto em que surge e qual a motivação para o fazer. São também descritos os objetivos que se pretendia cumprir com este trabalho, e quais as contribuições conseguidas com a sua realização. No Capítulo 2 é apresentado o estado atual das tecnologias inerentes a sistemas VoIP dentro e fora do contexto Web, mostrando em detalhe as que são mais relevantes para o trabalho a realizar. É também descrita com detalhe a tecnologia WebRTC, cada um dos seus componentes e capacidades bem como a integração que é possível conseguir com a sua utilização. O capítulo termina com a apresentação de vários projetos em desenvolvimento que focam pontos semelhantes aos desta investigação, e é apresentada uma análise dos problemas que surgem com a tentativa de interoperar a tecnologia WebRTC com o mundo VoIP e mesmo com a rede mundial de telefones(pstn). Após estes passos, no Capítulo 3 apresenta-se a discussão dos requisitos e a análise de cada uma das possíveis soluções. Após esta análise, é definida a arquitetura da solução a implementar, enumerando os componentes necessários para o cumprimento dos objetivos propostos. 24

27 No Capítulo 4 descreve-se como foi abordada a implementação dos diferentes componentes do projeto, começando por explicar como foi realizada a comunicação cliente servidor, e explicando depois quais os passos dados na implementação do servidor e da aplicação Web. Neste capítulo são apresentados alguns diagramas explicativos e também imagens com o aspecto final da aplicação. Após a descrição da implementação, são apresentadas no Capítulo 5 algumas integrações e demonstrações em que o projeto foi utilizado. São também descritos os testes realizados ao sistema final, bem como a discussão dos resultados, antevendo algumas conclusões comparativas com as soluções anteriores. Ainda neste Capítulo, é apresentada uma secção onde futuros testes são descritos, como continuação do trabalho realizado. O documento termina com a Conclusão no Capitulo 6 onde é analisado o trabalho desenvolvido e os planos para o futuro. São também apresentadas algumas notas finais sobre a tecnologia WebRTC e é feita uma comparação com as tecnologias anteriores, seguido pela bibliografia utilizada na produção deste documento e como auxílio de todo o projeto. 25

28

29 Capítulo 2 Voz sobre IP - Estado atual da tecnologia VoIP é a tecnologia que permite estabelecer chamadas telefónicas através da Internet ou seja, que possibilita a transmissão de sinais de voz através de uma rede de dados. A voz é convertida de sinais analógicos em digitais, que são depois transmitidos utilizando a rede Internet Protocol (IP). Hoje em dia várias aplicações VoIP são utilizadas para estabelecer chamadas de áudio e vídeo gratuitas através da Internet. Aplicações como o Google Talk, Windows Live Messenger (WLM), Skype entre outras, são utilizadas em massa tanto para trocar mensagens instantâneas como para fazer chamadas entre computadores. Cada uma das aplicações referidas anteriormente utiliza o seu protocolo, sendo que o único que é aberto é o utilizado pelo Google Talk. Este utiliza o protocolo extensible Messaging and Presence Protocol (XMPP) tanto para a troca de mensagens como para a negociação de chamadas no serviço Google Hangout, onde é usada a extensão Jingle com algumas modificações para suportar a negociação de chamadas[4]. Tanto o WLM como o Skype trocam também mensagens instantâneas e estabelecem chamadas mas utilizando protocolos proprietários, o que torna bastante difícil ou mesmo impossível a criação de aplicações que consigam interagir com estes. Ao contrário das outras aplicações, o Skype oferece a possibilidade de estabelecer chamadas para a rede telefónica mundial (PSTN), conseguindo cobrar valores mais baixos que as chamadas dos operadores desta rede.[5] Para que estas aplicações tenham um bom desempenho e para que consigam transmitir os dados de voz e vídeo com boa qualidade, é necessário que estas utilizem vários mecanismos para ultrapassar os problemas que possam encontrar na rede. Precisam também de ter em atenção o estado da rede e de escolher o Compression/Decompression Module (Codec) mais apropriado a cada situação. Estes elementos responsáveis por codificar e descodificar os sinais analógicos de voz em sinais digitais são cruciais na qualidade das chamadas[6], pois existem várias implementações e que obtêm melhores ou piores resultados em diferentes situações[7]. O Skype é um exemplo de um cliente que cresceu bastante com as chamadas VoIP e em grande parte devido à boa qualidade conseguida através do seu sistema, contituído por vários componentes que fazem com que a Quality of Experience (QoE) resultante da utilização da aplicação seja bastante boa. Esses elementos vão desde os Codec s utilizados (e.g. Silk 1, Opus 2 3 ) aos nós de rede espalhados pelo mundo, para garantir que existem sempre pontos de retransmissão próximos de quem está a fazer uma chamada[5, 8]. O mecanismo de VoIP independentemente do protocolo utilizado, divide-se em 2 camadas distintas: Sinalização Parte da comunicação que permite efetuar a negociação dos parâmetros em que se vai estabelecer uma chamada, e através da qual o destinatário recebe a informação de que o iniciador da chamada está

30 a tentar estabelecer uma chamada. Esta negociação é feita usando um protocolo próprio para o efeito. Média Após o destinatário ter aceite a chamada, é estabelecida a ligação através da qual os dados serão trocados. Esta é normalmente criada sobre uma ligação User Datagram Protocol (UDP). Antes de se trocar áudio ou vídeo entre dois pontos, vários protocolos têm de ser usados, tanto para permitirem a localização do dispositivo em questão, como para o transporte e negociação dos parâmetros necessários para estabelecer a chamada. Além dos protocolos usados pelas aplicações próprias de alguns serviços (e.g. Skype, Inter-Asterisk exchange v2 (IAX2) 4 )[5, 9], existem vários protocolos que poderão ser usados para sinalização, no entanto os mais usados são o H.323 e o SIP[7, 10]. Ambos começaram a ser criados em 1995 mas a International Telecommunication Union (ITU) lançou um primeiro standard do H.323 muito rapidamente em Desde aí a ITU tem lançado novas versões do standard sendo que a última foi a versão 7 em A Internet Engineering Task Force (IETF) lançou no mesmo ano um draft sobre o SIP, mas o standard apenas foi aceite em 1999 com o RFC2543[11]. Após algumas revisões, foi relançado o standard em 2002 no RFC3261[1] que é usado hoje em dia. Ao longo dos anos inúmeros artigos e discussões foram criadas sobre qual o melhor dos dois protocolos, sendo que ambos servem o mesmo propósito: estabelecer uma comunicação multimédia. Os argumentos são muitas vezes relacionados com os apoiantes de cada uma das comunidades: ITU vs IETF. O H.323 é um protocolo binário e que permite uma boa integração com a PSTN. O protocolo SIP é representado em American Standard Code for Information Interchange (ASCII), e por isso torna-se mais simples de implementar e de resolver problemas com uma simples captura de rede. O H.323 é o protocolo mais utilizado principalmente para telefones de conferência e por ter regras mais rígidas, fornece uma melhor interoperabilidade entre implementações. O protocolo SIP é mais utilizado na criação de sistemas VoIP fechados, devido à simplicidade da sua construção e facilidade de depuração[12]. 2.1 SIP Tal como o H.323, o protocolo SIP funciona sobre TCP ou UDP mas é mais usual encontrar implementações sobre UDP, e por isso foi pensado com alguns mecanismos para tornar a troca de mensagens mais fiável, como é o exemplo da inclusão de uma forma de confirmação de uma resposta final no estabelecimento de uma sessão (método ACK). Apesar do protocolo SIP permitir que duas aplicações comuniquem diretamente sem a necessidade de existir um servidor ou proxy, esta não é a utilização mais usual, pois para além de na maior parte dos casos ser necessário resolver problemas de Firewall e NAT, normalmente existe um serviço associado que necessita de faturar ou contar as ligações. A existência de um servidor é importante por exemplo para que um utilizador se possa registar nele para que este saiba a sua localização quando houver um pedido que lhe seja direcionado[12]. O protocolo SIP foi desenvolvido à semelhança do protocolo HTTP, sendo por isso constituído por um verbo que define a ação e o recurso a aceder. Em seguida aparecem os vários headers usados para enviar mais detalhes sobre o pedido, tais como a identificação, autenticação ou informações sobre o conteúdo. Opcionalmente, cada 4 Protocolo VoIP utilizado na comunicação entre os servidores Open source Asterisk

31 pedido pode também conter um corpo para poder transportar conteúdos em vários formatos. As respostas são também compostas por um código representativo de um estado, e que facilita a identificação do tipo de resposta entre todas as aplicações. Estas contêm também vários headers com informações que permitem enriquecer a resposta com informação e podem também conter um corpo, para transportar dados em vários formatos. REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hg4bknashds7 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag= Call-ID: @998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@ > Expires: 7200 Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hg4bknashds7 ;received= To: Bob <sip:bob@biloxi.com>;tag=2493k59kd From: Bob <sip:bob@biloxi.com>;tag= Call-ID: @998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@ > Expires: 7200 Content-Length: 0 Listagem 2.1: Exemplo de um pedido SIP REGISTER e respectiva resposta [1] Os pedidos SIP seguem o modelo de pedido/resposta, em que por cada pedido existe pelo menos uma resposta final e poderão existir várias respostas provisórias. Estas últimas podem trazer informação sobre o progresso do pedido efetuado, até que o destino tenha uma resposta definitiva. À semelhança do HTTP, existem vários métodos que podem ser usados em SIP e também as respostas podem ter vários códigos de resposta. Alguns destes foram aproveitados do protocolo HTTP e estão distribuídos por categorias [13, 1] 7 : 1xx: Provisional Pedido recebido, a continuar o ser processamento; 2xx: Success A ação pedida foi recebida, percebida e aceite; 3xx: Redirection Mais ações necessitam de ser tomadas para completar o pedido; 4xx: Client Error O pedido contém erros de sintaxe ou não pode ser realizado neste servidor; 5xx: Server Error O servidor falhou ao executar a ação apesar de o pedido estar aparentemente correto; 6xx: Global Failure O pedido não pode ser realizado em nenhum servidor

32 Inicialmente o protocolo foi criado para estabelecer chamadas e para isso, foram criados os métodos necessários ao registo e ao estabelecimento de uma sessão [1]. Comandos base: REGISTER, INVITE, CANCEL, BYE, ACK, OPTIONS Todos os comandos podem ser direcionados a diferentes pontos, e para isso podem ser usados os headers To e From que permitem identificar um utilizador inequivocamente no servidor. Estes headers levam como valores Uniform Resource Identifier (URI) s que podem ser SIP URI ou outro tipo de URI s, como por exemplo os TEL URI s definidos no RFC2806[14]. Todas as aplicações SIP têm de suportar os URI s do schema SIP que têm o formato schema:user@domain em que o schema pode ser sips ou sip, consoante a ligação seja sobre Transport Layer Security (TLS) ou não, respectivamente[15]. O user deve identificar o utilizador inequivocamente e é comummente usado o número de telefone ou username registado no serviço e o domain identifica o serviço no qual o utilizador está registado sendo que por vezes, o domain é o conjunto de host:port onde o serviço é encontrado. É possível fazer por exemplo chamadas anónimas, enviando para isso o header From com o valor sip:anonymous@anonymous.invalid e enviando a identidade do utilizador que está a efetuar o pedido no header Prefered-Identity. Desta forma o servidor irá conseguir identificar o originador da chamada mas não irá enviar esta identidade para o destinatário. O comando REGISTER é enviado para o servidor com a informação do utilizador que se está a registar. O registo num servidor é sempre um registo temporário, que é válido durante o número de segundos enviado no header Expires, como mostra o exemplo da Listagem 2.1, em que o utilizador terá um registo no servidor válido durante duas horas (7200 segundos). Antes desse tempo terminar, se a aplicação ainda quiser manter o seu registo, deve enviar novamente um pedido REGISTER, renovando assim por mais outro intervalo de tempo a disponibilidade no servidor. Numa resposta a um REGISTER o servidor pode devolver uma resposta de sucesso informando assim a aplicação do sucesso do registo ou pode devolver outras respostas de erro que devem ser analisadas caso a caso. A título de exemplo, se for necessário autenticar o pedido (e.g. mecanismo Digest), o servidor responde com uma resposta 401 UNAUTHORIZED e adiciona o header com o chalenge necessário para o envio de um novo REGISTER autenticado com as credenciais do utilizador em questão. O protocolo SIP não define o conjunto mínimo de métodos, formatos ou funcionalidades que um cliente ou servidor SIP deve suportar e por isso, torna-se necessário um método para dar a conhecer as capacidades de cada ponto na rede. Após estar autenticada, uma aplicação pode enviar pedidos para outros utilizadores através do servidor, mas antes de o fazer esta consegue saber se o pedido vai ser entendido enviando um pedido OPTIONS. Estes pedidos podem ser enviados para os servidores ou mesmo para outros clientes, dependendo do header To inserido no pedido. Visto que podem existir vários proxies na rede através dos quais um pedido tenha de passar, é possível com este método fazer uma espécie de traceroute 8 alterando com o header Max-Forwards, e obtendo assim as capacidades de cada nó na rede até chegar ao cliente destino. Em resposta a um pedido de OPTIONS, um nó na rede deverá responder com as suas capacidades, colocando nos headers Allow, Accept, Accept-Encoding, Accept-Language, e Supported os valores que coincidem com a sua implementação. 8 Traceroute é um mecanismo utilizado para descobrir o percurso que um pacote faz na rede. É criado com recurso ao mecanismo de definição do número máximo de saltos que um pacote pode dar na rede, e através do envio consecutivo de pacotes com este valor incrementado, consegue-se descobrir qual o ponto na rede a uma dada distância 30

33 Figura 2.1: Esquema do estabelecimento de uma sessão SIP O método INVITE é utilizado para iniciar uma sessão e transporta a informação sobre o destinatário com o qual se deseja estabelecer a mesma e as propriedades da sessão a criar. Ao criar por exemplo uma chamada com outro utilizador, a aplicação deve enviar um pedido com o método INVITE colocando headers From e To respetivos e juntar no corpo da mensagem a descrição da chamada que pretende criar, no formato Session Description Protocol (SDP) definido em RFC4566[16]. Este formato define para cada stream audio ou video, as portas onde o cliente estará à espera de receber dados, os Codecs e as respectivas taxas de transmissão. O corpo de um INVITE pode transportar muitos outros elementos e até vários ao mesmo tempo, utilizando para isso o MIME type multipart definido pelo RFC5621[17]. Para estabelecer uma ligação segura para transferência dos dados SRTP, devem ser partilhadas as chaves necessárias também no corpo da mensagem SDP.[18] Após a aplicação do cliente destino ter recebido o INVITE para uma chamada, esta envia uma resposta provisória com o código 180 RINGING, informando assim o remetente de que o utilizador está a ser alertado para a chamada. Consoante a resposta do utilizador ou falta dela, uma resposta final será enviada com a respetiva informação. Caso a resposta seja positiva e o utilizador queira atender a chamada, o código de resposta enviado é o 200 OK e no corpo da resposta é enviado novamente um SDP desta vez com as informações relativas às capacidades da aplicação destino, em que IP e portas esta vai estar à espera de receber os dados, e que Codecs escolheu para transmitir. Após a recepção de uma resposta final, a aplicação que enviou o INVITE envia um comando ACK para informar a outra aplicação de que a resposta foi recebida, e a transmissão de dados vai prosseguir. Caso o iniciador de uma chamada a queira terminar antes do o outro utilizador devolver uma resposta definitiva, um pedido com o comando CANCEL tem de ser enviado com um Call-Id igual ao enviado no INVITE para o cancelar. 31

34 INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Max-Forwards: 70 Date: Thu, 21 Feb :02:03 GMT Contact: Content-Type: application/sdp v=0 o=alice IN IP4 pc33.atlanta.com s=session SDP t=0 0 c=in IP4 pc33.atlanta.com m=audio 3456 RTP/AVP a=rtpmap:0 PCMU/8000 Listagem 2.2: Exemplo de um pedido SIP com o SDP para negociar uma chamada de áudio [1] Se a chamada for estabelecida está criado um diálogo SIP e para ser terminado, tem de ser enviado um pedido BYE com o mesmo Call-Id enviado no INVITE inicial. Ambas as partes da ligação podem enviar o BYE, assim que quiserem terminar a sessão estabelecida. Extensões: PRACK, UPDATE, SUBSCRIBE, NOTIFY, PUBLISH, INFO, MESSAGE, REFER No RFC3261[1] foi descrito o protocolo SIP como base de um protocolo de comunicação, que pode ser expandido através da manipulação e adição de novos headers e também através da criação de novos métodos. Hoje em dia, vários outros mecanismos são usados para auxiliar as sessões criadas e disponibilizar outras funcionalidades extra usando o SIP. Como foi referido acima, quando uma resposta final a um INVITE é recebida, um comando ACK relativo à resposta recebida é enviado de volta. Enquanto a aplicação que enviou a resposta não receber este comando, deve continuar a enviar a resposta repetidamente em intervalos de tempo crescentes. Este mecanismo serve para garantir que a resposta é recebida por quem iniciou o diálogo. Além destas respostas, também se começou a sentir a necessidade de obter uma confirmação da recepção das respostas provisórias. Isto acontece quando as respostas provisórias transportam mais informação relevante que apenas um simples código de resposta, que apenas dá algum feedback ao utilizador. Um exemplo da utilização de respostas provisórias para o transporte de alguns dados extra, pode ser visto hoje em dia quando ligamos para alguém e a chamada é redirecionada para o gravador ou quando alguém ativa os serviços de música enquanto a chamada não é atendida (e.g. Vodafone RingDing, TMN WaitingRing). O que acontece nestes casos, quando uma chamada é iniciada a partir de um cliente SIP e é depois passada para a PSTN, enquanto o utilizador não atende ou rejeita a chamada, o servidor do serviço em questão envia uma resposta provisória com o código 183 SESSION PROGRESS, em que o conteúdo inclui o SDP para que a aplicação que enviou o INVITE possa estabelecer uma ligação de um sentido, onde vai receber dados de áudio respetivos à mensagem a transmitir. 32

35 Nestes casos pode ser necessário que o servidor receba uma confirmação de que pode começar a enviar o áudio, e para isso foi criado o comando PRACK, que é semelhante ao BYE, por ter também uma resposta, mas tem a mesma função de um ACK. As aplicações ficam a saber da necessidade de suportar ou não esta funcionalidade através da inclusão do valor 100rel no header Require, e devem ser enviadas para todas as respostas com códigos entre 101 e 199 (o código 100 TRYING está excluído, por ser enviado por nós de rede)[19]. O comando INVITE é utilizado para a criação de um diálogo, onde se podem depois trocar dados num ou nos dois sentidos, até que um BYE seja enviado. No entanto, após uma aplicação ter enviado um pedido destes, esta pode querer fazer alterações ao seu conteúdo, antes mesmo de receber uma resposta final. Para isto foi criada uma extensão definida no RFC3311[20] que cria o comando UPDATE. Este é usado por exemplo para alterar o SDP que foi enviado, de forma a completar com informação mais atual ou mesmo para que duas aplicações consigam estabelecer uma ligação para trocar dados antes do pedido ser aceite. Normalmente esta operação de atualização dos parâmetros de uma sessão é realizada enviando um novo INVITE, mas apenas pode ser realizada após o diálogo estar estabelecido. O UPDATE vem colmatar essa falha. Outro tipo de necessidade foi a obtenção de notificações quando algo acontecia no servidor e para isso foram criados os comandos SUBSCRIBE e NOTIFY. O comando SUBSCRIBE é enviado por um cliente para o servidor, subscrevendo um tipo de eventos para um recurso em particular. Se for possível e permitido ao utilizador em questão receber notificações do recurso pedido o servidor enviará uma resposta final com o código 200 OK, e passará a partir daí a enviar comandos NOTIFY com as atualizações que aconteceram no recurso em questão. Uma subscrição, tal como os comandos REGISTER, são válidos durante um intervalo de tempo enviado no header Expires, e devem ser renovados pelo cliente, caso este ainda pretenda receber notificações. Quando um cliente não desejar receber mais comandos NOTIFY sobre um recurso, deve enviar um novo SUBSCRIBE com o header Expires com o valor 0, informando assim o servidor de que não deseja estar durante mais tempo a receber notificações [21]. Subscriber Notifier -----SUBSCRIBE----> Request state subscription < Acknowledge subscription <------NOTIFY----- Return current state information > <------NOTIFY----- Return current state information > Listagem 2.3: Esquema do funcionamento das notificações Um exemplo de utilização deste mecanismo é a obtenção de notificações sobre os utilizadores numa conversa de grupo, em que a informação sobre a disponibilidade de cada utilizador pode ser fornecida por notificações do servidor. Desta forma, quando um utilizador entra ou sai, os restantes utilizadores recebem essa informação através de um extensible Markup Language (XML) e podem atualizar a lista de utilizadores presentes na sala de conversação ou atualizar o seu estado [22]. Uma outra extensão ao protocolo SIP foi estabelecida em 2004 com o RFC3909[23], que está também relacionada com os dois comandos apresentados anteriormente. O propósito deste standard foi a criação do comando PUBLISH para permitir a publicação de novos eventos para o servidor, para que este pudessem gerar novas notificações. Este mecanismo surge como consequência dos comandos SUBSCRIBE e NOTIFY, e surgiu para permitir a implementação de um sistema de presença, através do qual um utilizador pudesse alterar o seu estado (e.g. Disponível, Ocupado, Ausente...). Por cada vez que o utilizador alterasse o seu estado, um 33

36 novo comando seria enviado para o servidor transportando no conteúdo um documento XML com a informação respetiva. Os utilizadores que tivessem subscrito a presença desse utilizador (através de um pedido SUBSCRIBE com o header Event com o valor presence ), receberiam um comando NOTIFY com o novo documento. Outra extensão criada foi o comando INFO, que foi tornado standard em 2000 com o RFC2976[24] e que foi revisto e republicado em 2011, no RFC6086[25]. Este método foi criado para transportar dados referentes a um diálogo já estabelecido, mas que não alteram em nada as propriedades do mesmo, ao contrário de um re-invite ou de um UPDATE, que podem alterar por exemplo os Codecs a serem usados na sessão. Este comando transporta normalmente conteúdo com informação para o utilizador. Uma das utilizações conhecidas é o transporte de sinais DTMF, em que o pedido leva informação sobre qual a tecla pressionada e durante quanto tempo ocorreu. Para que se pudesse adicionar suporte para mensagens instantâneas entre clientes SIP, foi criada uma nova extensão [2] que define o método MESSAGE. Este foi criado para poder enviar conteúdos genéricos dentro ou fora do diálogo de uma sessão iniciada com o comando INVITE. No entanto é mais utilizado fora do contexto de uma sessão, facilitando o desenvolvimento de um sistema de mensagens instantâneas entre dispositivos. Este método é denominado de conversação em PAGE MODE, em contraste com a conversação em SESSION MODE, que é definido através de uma sessão iniciada com um INVITE em que o SDP deste faz a negociação de uma sessão Message Session Relay Protocol (MSRP)[3]. Através desta são depois transmitidos dados das mensagens entre os utilizadores. MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hg4bk776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@ CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. Listagem 2.4: Exemplo de uma mensagem instantânea enviada com o comando MESSAGE [2] Outra extensão criada em 2003, foi a definição do método REFER para permitir que uma aplicação dê instruções a outro cliente ou servidor na rede sobre o que fazer no contexto de um diálogo.[26] Incluindo o header Refer-To num pedido REFER, um utilizador pode por exemplo iniciar uma transferência de chamada, informando a aplicação de uma pessoa com a qual esteja em chamada que deve iniciar uma chamada para a pessoa referida. Essa aplicação deve, com a autorização do utilizador, enviar um INVITE para o contacto referenciado, iniciando assim uma nova chamada. Outra utilização deste método é a inclusão de mais pessoas numa sessão de conversação, em que uma aplicação cliente pode enviar um comando REFER para o servidor que esteja a gerir a sessão, informando-o do contacto para o qual deve enviar um INVITE para inserir essa pessoa na conversa. 2.2 Sessões de média Quando um utilizador aceita a criação da sessão que foi proposta, ambas as aplicações envolvidas estabelecem sessões de média utilizando para isso os IP s e portas negociados. Estas sessões não têm de ser necessaria- 34

37 mente para a transmissão de voz ou vídeo, mas este foi o objectivo inicial da criação deste protocolo, e é essa a utilização que mais aplicações lhe dá. Qualquer que seja o tipo de sessão a criar, a sua negociação é feita através da inclusão de SDP[16] nos comandos usados na fase da sinalização. Este formato foi definido inicialmente para a negociação de Codecs e portas a utilizar numa chamada de voz, mas é hoje em dia utilizado por exemplo para a criação de sessões MSRP[3]. INVITE sip:bob@biloxi.example.com SIP/2.0 To: <sip:bob@biloxi.example.com> From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=in IP4 atlanta.example.com m=message 7654 TCP/MSRP * a=accept-types:text/plain a=path:msrp://atlanta.example.com:7654/jsha7weztas;tcp SIP/ OK To: <sip:bob@biloxi.example.com>;tag=087js From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=in IP4 biloxi.example.com m=message TCP/MSRP * a=accept-types:text/plain a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp ACK sip:bob@biloxi SIP/2.0 To: <sip:bob@biloxi.example.com>;tag=087js From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU Listagem 2.5: Exemplo da negociação de uma sessão MSRP[3] O protocolo MSRP baseia-se na troca de pequenos pacotes de dados de qualquer tipo entre aplicações. É normalmente usado para a troca de ficheiros ou mensagens de texto, mas pode ser usado para troca de dados estruturados proprietários de uma dada entidade. Ao contrário do SIP, o protocolo MSRP não tem obrigatoriamente respostas relacionadas com um dado pedido. Estas podem existir dependendo daquilo que cada pacote pedir, e no caso de existir resposta, esta pode ser respetiva a um ou a vários pacotes enviados. Existem dois tipos de respostas sendo que os ACKs servem para informar que um dado pacote chegou ao ponto de rede seguinte, e os REPORTs informam sobre a chegada ou não de um pacote ou de um conjunto de pacotes ao destino. 35

38 Média em chamadas Há vários protocolos que podem ser usados na implementação de um serviço VoIP sendo que para o transporte de média, o protocolo usado é o Real Time Protocol (RTP) que serve para trocar pacotes de áudio e vídeo entre os dispositivos. Este é um protocolo definido[27] pelo IETF e é capaz de criar um transporte de rede ponto-a-ponto para transmitir dados em tempo real, tais como áudio e vídeo para estabelecer desde simples chamadas de voz até vídeo-conferências. Devido à natureza do Transmission Control Protocol (TCP), por este ser um protocolo que garante a entrega ordenada de pacotes na rede e que implementa um mecanismo de controlo de congestão, tem um grande overhead na ligação, não sendo por isso o protocolo mais indicado para o transporte de dados em tempo real. Ao contrário deste, o protocolo UDP não garante a entrega dos pacotes nem a sua ordem, o que faz com que possibilite comunicações com um menor overhead e por isso, mais indicado para dados em tempo real como áudio ou vídeo em chamadas[7]. Dada esta diferença, o protocolo RTP apesar de poder funcionar sobre os dois protocolos de comunicação, é normalmente utilizado sobre UDP. O principal objetivo do RTP é a implementação de números de sequência para os pacotes IP para que se possa formar novamente a informação de áudio e vídeo, se estes forem trocadas durante a transmissão. Os pacotes RTP permitem identificar o tipo de informação transportada e as marcas temporais sobre quando devem ser reproduzidos os dados. O RTP permite que os dados sejam enviados em multicast, permitindo assim que seja recebido por vários destinatários[7]. Nativamente as redes telefónicas convencionais que interligam todos os telefones fixos e móveis do mundo (PSTN), foram desenvolvidas para transportar este tipo de dados, tendo por isso bons resultados neste serviço. Com o surgimento do VoIP, os dados da comunicação são transferidos em redes IP estando assim sujeitos às mesmas condições que todos os outros dados. No entanto, os dados de voz de uma chamada tem de ser transmitidos em tempo real para manter os níveis de Quality of Service (QoS) em valores aceitáveis, de forma a que os intervenientes na chamada tenham uma simulação de uma conversa real, tal como se obtém nos serviços de telefonia na rede PSTN. Visto que o RTP pode ser transmitido sobre protocolos de baixo nível que permitem o atraso e mesmo a perda de pacotes sem que o emissor tenha o conhecimento, foi criado o protocolo Real Time protocol Control Protocol (RTCP) para os receptores poderem dar feedback sobre os pacotes que estão a receber.[7, 27] O RTP pode ser usado independentemente do RTCP vindo este adicionar a possibilidade de os utilizadores que estão a receber uma dada stream de áudio ou vídeo informarem a fonte emissora para que possa reajustar o Codec, se se tratar de um Codec adaptativo[28], ou mesmo renegociar a chamada para que se possa trocar o Codec a ser utilizado. Em caso de chamadas de conferência negociadas ou não 9 o protocolo RTCP pode transmitir também a informação sobre os participantes presentes bem como informação que possa ser mostrada na Interface da aplicação que identifique o utilizador. Quando isto acontece, o RTCP tem mecanismos para ajustar o número de pacotes enviados por cada utilizador, mecanismo que foi revisto numa correção ao standard no RFC 3550[27]. Estes mecanismos são especialmente necessários dada a crescente utilização de redes sem fios, onde a qualidade da rede pode alterar rapidamente.[6] 9 Por chamadas não negociadas entenda-se por exemplo casos em que existe uma conferência pública em que qualquer utilizador se pode juntar. 36

39 2.3 VoIP em contexto WEB Nos últimos anos tem-se assistido a uma crescente migração das aplicações Desktop para a Web, e mesmo com o recente aparecimento das aplicações móveis, também neste segmento algumas empresas optam por criar aplicações Web, o que permite que a mesma aplicação funcione em qualquer dispositivo e em qualquer sistema operativo. As aplicações Web deixaram de ser apenas páginas com conteúdo estático e são agora capazes de fazer operações tipicas de aplicações Desktop e são denominadas de Rich Internet Application (RIA)s. Há uns anos a Internet era povoada por páginas estáticas e a interação existente era apenas através de novos links que carregavam outra página com conteúdos HTML simples ou alteravam o conteúdo de uma tabela da página. Hoje em dia são construídas páginas com muitas mais capacidades, com conteúdos carregados em segundo plano (Asynchronous JavaScript + XML (Ajax)) e com muito mais programação na aplicação cliente.[29] Tecnologias para construção de RIAs Estas aplicações podem ser construídas usando Javascript, ou recorrendo a plugins instalados nos browsers. Com o recurso a plugins tais como o Adobe Flex 10, Adobe Flash ou OpenLaszlo 11 conseguem-se construir aplicações mais completas por estes correrem o código nativo, com mais capacidades que o Javascript simples. Podem também ser instalados plugins no sistema operativo que permitem a utilização de páginas que interligam com aplicações Desktop ou que se têm as mesmas capacidades que estas (Adobe AIR 12, JavaFx 13 )[29, 30]. Para criar aplicações Web que permitam fazer chamadas VoIP é necessário que as aplicações possam aceder a alguns recursos, que normalmente os browsers não disponibilizam sem o recurso a alguns plugins que facilitem estes acessos. As capacidades mínimas necessárias são o acesso a microfones, câmaras e um meio de transmissão dos dados obtidos destes dispositivos para um servidor ou diretamente para o destinatário.[31] Plugins Adobe Flash é uma tecnologia proprietária da Adobe que permite a criação e a visualização de conteúdos multimédia tais como vídeos, animações e jogos em páginas Web, sendo que na maioria das vezes são encontradas utilizações embebidas em páginas Web, e não tanto como aplicação Web completa. É bastante utilizado para aplicações com necessidades de streaming de multimédia e animações mais completas. Para que os browsers possam mostrar conteúdos criados com esta tecnologia precisam de ter o plugin instalado e este adiciona a possibilidade de aceder à câmara e microfone do dispositivo, havendo também a possibilidade recepção ou envio dos dados capturados através de RTMP[32] para um servidor que suporte este protocolo [33]. É assim possível criar todo um leque de aplicações, que suportam desde a gravação de voz/vídeo, até mesmo a chamadas para outra aplicação que suporte o mesmo protocolo. Atualmente o plugin está na versão 11 e suporta vários Codecs que são comummente usados em chamadas VoIP. Para codificar voz, são suportados os Codecs G.711 (Pulse Code Modulation A-law (PCMA) e Pulse Code Modulation U-law (PCMU)) e Speex. Para codificação de vídeo são suportados os Codecs H.263 Sorenson Spark e H

40 Estas propriedades indicam que é um plugin bom para interoperabilidade com sistemas de VoIP, visto que existem alguns servidores (e.g. Wowza Media Server (WMS) 14 ) capazes de fazer a tradução entre os pacotes RTMP e RTP, facilitando o processo. No entanto, apesar de ser suportado pela maioria dos browsers, o plugin criou alguma inércia em alguns setores do mercado. A Apple em 2010 declarou que o iphone e o ipad não teriam suporte para Flash e recentemente, também a Google anunciou que a partir do Android 4.1 Jelly Bean também não haveria suporte para o plugin[34]. Estes retrocessos afetam as decisões de quem produz software, ou de quem pensa comprar um produto baseado nesta framework. Silverlight é uma tecnologia criada pela Microsoft para competir com o Adobe Flash que permite a criação de aplicações RIA. A versão mais recente é a 5, e oferece basicamente as mesmas capacidades que o Flash, mas com uma aceitação pública menor como mostra a Tabela Também através da utilização de servidores na rede (e.g. Media Suite 15 ), é possível obter voz e vídeo em vários Codecs transmitidos sobre RTP. O Silverlight corre em todos os Sistemas Operativos na maioria dos browsers desktop. No segmento das aplicações móveis, o Silverlight funciona em Windows Phone 7 e em no Symbian mais recente. Ainda não há suporte para Android nem iphone. Nenhuma 7.3% JavaScript 92.5% Flash 20.7% Silverlight 0.2% Java 0.2% Tabela 2.1: Utilização de cada tecnologia em páginas Web 16 Outra hipótese para criar aplicações RIA é usando o JavaFx, que foi criado para fornecer uma camada mais leve do Java para criar interfaces Web que permitam aproveitar todas as capacidades do sistema que uma aplicação Java consegue. Uma das vantagens de usar esta tecnologia é a possibilidade de reusar código de outras aplicações Java através da instalação do plugin. Atualmente na versão 2.2, este plugin tem a capacidade de aceder aos dispositivos multimédia usando algumas bibliotecas externas, e suporta alguns Codecs tais como o H.264 e o MP3. No entanto, outros podem ser adicionados com recurso a bibliotecas externas. HTML5 e WebSockets A última versão standardizada do HTML é a versão 4.1 que foi definida em Desde aí a Internet mudou bastante, e como tal uma união entre o World Wide Web Consortium (W3C) e o Web Hypertext Application Technology Working Group (WHATWG) foi criada com o intuito de definir o HTML5. Este está já a ser implementado pelas versões mais recentes dos browsers apesar de ainda estar a ser definido. Nos principais objetivos inclui-se entre outras coisas, a reprodução nativa de áudio e de vídeo, com a adição de novas tags para o efeito. Esta nova versão do HTML vem tentar corrigir as divergências existentes nas várias Acedido a 27/01/

41 implementações das versões anteriores, tentando assim criar uma ferramenta muito poderosa para a criação de páginas Web interativas e muito completas, com a possibilidade de manipulação de objetos gráficos, som e vídeo. Animações que eram anteriormente apenas possíveis de construir recorrendo a plugins, passam agora a ser possíveis de criar apenas recorrendo ao uso de HTML, usando o Canvas que permite a criação de objetos livres incluindo em 3 dimensões. Um dos objetivos gerais é a redução da necessidade de plugins para a criação de RIAs. Também incluído no pacote de melhorias que o HTML5 traz está a implementação de um novo protocolo de transporte: os WebSockets. O objetivo é a criação de um meio de transmissão de dados full-duplex bi-direcional entre browsers e servidores, para permitir a criação de aplicações ainda mais interativas e para reduzir o overhead criado por mecanismos como o Long-pooling 17. Alguns browsers têm já este mecanismo implementado, havendo também já vários projetos opensource que permitem a criação de um servidor capaz de processar pedidos deste protocolo. 2.4 Tecnologia WebRTC Figura 2.2: Arquitetura dos Websockets No início de 2011 a Google criou uma proposta de especificação de uma tecnologia que dotasse os browsers das mesmas capacidades de um cliente VoIP, podendo assim fazer com que todo um novo leque de aplicações pudesse ser migrado para a Web sem a necessidade de instalação de plugins. Nesta proposta alguns objetivos teriam de ser obrigatoriamente implementados para que o resultado pudesse ser inovador e proveitoso para a comunidade. Foram então definidos três requisitos gerais daquilo que os browsers deveriam passar a suportar com a implementação do WebRTC: 1. Permitir que os browsers tenham acesso nativo aos microfones e câmaras dos dispositivos; 2. Dotar os browsers da capacidade de comunicação independente de áudio e vídeo de forma segura através do protocolo SRTP; 3. Disponibilizar a implementação de um canal de dados através do qual dois browsers possam trocar dados livres diretamente de forma a permitir a criação de aplicações de comunicação interativa. 17 Long-pooling é um mecanismo de comunicação baseado em pedidos do cliente que ficam pendentes no servidor, até que esta tenha algo para enviar para o cliente. Nessa altura o servidor responde ao pedido com o que tiver para enviar. Quando isto acontece ou o pedido expira, o cliente envia um novo pedido. 39

42 Para se poder definir a especificação como proposta de standard do IETF, foi criada uma equipa de trabalho 18 para definir quais os protocolos e standards usar e uma mailing-list pública para que qualquer pessoa interessada pudesse participar na discussão da criação do standard. Foi também criado um grupo de trabalho do W3C para definir a especificação e APIs do WebRTC. Ainda antes de serem iniciados os documentos, já bastantes pessoas tinham aderido à discussão, o que mostrava um grande interesse da comunidade nesta especificação. Figura 2.3: Esquema da arquitetura a definir nos browsers 19 Como primeiro passo foi definido com mais pormenor qual o trabalho que estes grupos iriam realizar[35]: Definir um modelo de comunicação incluindo como será feita a gestão das sessões; Definir um modelo de segurança e privacidade bem como os protocolos e mecanismos de segurança necessários para cumprir os requisitos; Definir os protocolos e requisitos da API para a solução funcionar com Firewall e Network Address Translation - Traversal (NAT-T); Definir que extensões serão utilizadas para tratar dos dados de média, incluindo os mecanismos a usar para adaptação e controlo de congestão de rede;

43 Definir quais os Codecs e mecanismos de segurança usar, bem como de que forma a aplicação poderá aplicar extensões posteriormente e definindo os formatos de média obrigatórios para garantir a interoperabilidade ente os browsers que implementem a especificação; Definir como serão transferidos os dados de outros tipos que não áudio ou vídeo entre os clientes de forma segura; Fornecer feedback sobre as APIs que vão sendo criadas para o modelo de comunicação e ter em conta durante todo o processo os atuais sistemas de VoIP para facilitar a interoperabilidade. Ao mesmo tempo que a especificação está a ser criada, está também a ser implementada pelos browsers, pelo que se pode já desde há algum tempo usar e desenvolver aplicações com esta tecnologia utilizando versões não oficiais dos browsers. Nem todos os fabricantes dos principais browsers avançaram com a implementação da nova especificação. O Chrome e o Opera foram os primeiros a avançar com desenvolvimentos assim que os primeiros drafts foram ganhando forma. O browser Opera que tem ganho terreno no segmento dos Smartphones, apostou mais nesta versão do browser mas também na versão OperaLabs é possível testar algumas das capacidades WebRTC 20. Em seguida o Firefox 21 começou também os desenvolvimentos e aquando da escrita deste documento (Janeiro de 2013), os três browsers já suportavam parte da especificação nas versões oficiais para os utilizadores. A Microsoft rejeitou desde o início a implementação do WebRTC no Internet Explorer (IE)[36], dizendo que seria implementado mais tarde, o que levou a Google a criar o plugin Google Frame 22, juntamente com os desenvolvimentos que iam sendo feitos no Google Chrome. Este plugin quando instalado no IE permite que as aplicações Web que usam as capacidades do WebRTC também funcionem no IE a partir da versão 6. Em Abril de 2012, baseados nas propostas de emprego nas páginas da Microsoft que pediam pessoas para implementar uma versão do Skype na Web, surgiram rumores de que a Microsoft estaria a pensar criar uma especificação para o WebRTC para poder criar uma versão Web do produto recentemente adquirido. Em Agosto de 2012, durante estes desenvolvimentos, a Microsoft anunciou a proposta de uma nova especificação (Customizable, Ubiquitous Real Time Communication over the Web (CU-RTC-Web) 23 ) para trazer as mesmas capacidades aos browsers que o WebRTC, alegando que a especificação sugerida pela Google era demasiado limitativa e não dava muita liberdade ao programador para gerir a média gerada[37]. O WebRTC disponibiliza uma API através de Javascript para que se possam construir aplicações com mais capacidades. Para cumprir o requisito 1 (Listagem 2.4) foi implementado o elemento GetUserMedia que permite pedir acesso ao utilizador para utilizar as câmaras e/ou microfones na aplicação. Após o utilizador ceder permissão de acesso a aplicação recebe MediaStreams que pode usar para atribuir às tags HTML5 audio ou video, podendo assim mostrar na página o resultado da captura. A outra hipótese de utilização das MediaStreams é a atribuição destas a um PeerConnection (PC), que é o segundo elemento criado no WebRTC e que permite estabelecer a ligação ponto-a-ponto com outros browsers. Assim que exista uma ligação estabelecida, os dados da stream que for atribuída a este elemento são enviados para os outros pontos na rede que estejam na sessão. Quando começam a chegar dados de outros browsers, a aplicação recebe a informação de que foram Na versão 18.0 do Firefox foi adicionado suporte parcial para WebRTC - firefox/18.0/releasenotes/

44 adicionadas mais MediaStreams, e pode então atribui-las a tags audio ou video para poder reproduzir os dados que chegam Sinalização Tal como nos protocolos comummente usados em sistemas VoIP atrás mencionados, também a camada de sinalização em WebRTC deve transportar os dados necessários para que as diferentes aplicações em diferentes pontos na rede consigam estabelecer ligações por onde recebam e enviem os dados de média. Figura 2.4: Esquema do enquadramento do WebRTC na rede[38] Na especificação do WebRTC não consta a definição de um protocolo de sinalização a utilizar, ficando essa decisão a cargo de cada implementação. Desta forma pretende-se dar liberdade para que qualquer canal de comunicação e protocolo possam ser utilizados, de forma a ser possível usar protocolos já existentes, ou mesmo incentivar a criação de novas formas de comunicação. A única exigência do WebRTC para estabelecer uma chamada é que o SDP obtido a partir do PC seja partilhado entre as duas aplicações, sendo que a partir daí os browsers têm já a informação necessária para estabelecer a transmissão de média[39]. Como se pode ver no esquema mostrado na Figura 2.4, a comunicação da aplicação com os servidores é feita por HTTP ou por Websockets e representa a comunicação dos dados de sinalização. Esta é a sugestão deixada na documentação da especificação[35], no entanto qualquer forma de comunicação que se consiga suportar num browser pode ser usada. Para criar uma chamada entre dois browsers usando os componentes WebRTC, a aplicação começa por iniciar uma instância do PC e por pedir ao utilizador acesso aos dispositivos de captura de média (getusermedia()). Após o utilizador permitir o acesso, a aplicação atribui a MediaStream recebida ao PC e em seguida obtém deste um SDP com o método createoffer(), enviando-o para o outro browser através da camada de sinalização. Quando a aplicação no browser do destinatário recebe o SDP com a oferta, inicia também uma instância do PC e pede acesso aos dispositivos de média e, após inserir o SDP recebido (setremotedescription()) e a MediaStream a que entretanto o utilizador der acesso (addstream()), cria também agora uma resposta para poder enviar para o iniciador da chamada com o método createanswer().[35, 38] Desta forma a aplicação Web que está no browser destinatário obtém também um SDP que inclui os Codecs já negociados com o SDP recebido. Este SDP é depois enviado também utilizando o protocolo de sinalização 42

45 e assim que é recebido pela aplicação que começou o processo, é injetado no browser, completando assim o processo de sinalização.[35, 39] Média Tal como qualquer aplicação VoIP, um browser para ser capaz de comunicar diretamente com outras aplicações tem de ter mecanismos de NAT-T que permitam que a aplicação seja contactável a partir de qualquer ponto do mundo. Com este objetivo, definiu-se na especificação que os browsers teriam de implementar um mecanismo de Interactive Connectivity Establishment (ICE)[40] para estabelecerem as sessões de média. Este protocolo foi criado para ajudar que duas aplicações estabeleçam ligações ponto-a-ponto, mesmo que ambas estejam dentro de uma NAT. O processo de ICE é iniciado através do acesso a um servidor de Session Traversal Utilities for NAT (STUN) 24 ou Traversal Using Relays around NAT (TURN) 25 para a obtenção dos candidatos a colocar no SDP a partilhar na sinalização. Estes candidatos são linhas que definem os vários conjuntos IP/porta onde o dispositivo em que a aplicação se encontra pode ser contactado, e que a aplicação destino irá percorrer ordenadamente para tentar estabelecer a ligação.[41](ver linhas a candidate na Listagem 2.6) Tipicamente, numa aplicação a correr dentro de uma NAT que obtenha os seus candidatos a partir de um servidor TURN, são gerados candidatos com 3 IPs distintos: O IP privado dentro da NAT onde se encontra, o IP público e o IP do servidor TURN. Isto permite que a aplicação comece a tentar estabelecer as ligações por ordem, começando pela rede local e terminando no servidor de TURN, permitindo assim que se duas aplicações estiverem dentro da mesma rede consigam comunicar sem usar os IP s externos. Para além destas técnicas usadas para facilitar a comunicação dos browsers, também foi definido que o protocolo usado para o transporte de média seria o SRTP, de forma a que os dados fossem protegidos e encriptados ponto a ponto. Em relação ao protocolo de gestão e controlo das streams de dados, a especificação define a utilização de RTCP utilizando o perfil SAVPF[42], que acrescenta mais informação sobre os dados recebidos por cada ponto da chamada, possibilitando uma melhor qualidade da média.[38] Na Listagem 2.6 pode-se verificar a presença das linhas a crypto com chaves para se poder encriptar a stream de dados. Uma outra funcionalidade acrescentada ao WebRTC tenta minimizar o número de portas utilizadas por uma aplicação VoIP, dado que normalmente é usada uma porta para cada stream de dados (RTP) e uma para cada stream de controlo RTCP, o que em chamadas com áudio e vídeo dá um total de 4 portas alocadas. A especificação define que os browsers devem juntar os dados de controlo e de média numa só stream, ou pelo menos oferecer essa possibilidade às outras aplicações, segundo o RFC 5761[43]. O RFC 3550[27] define na secção 5.2 que diferentes streams de dados não devem ser unidas numa só devido a vários problemas. No entanto, a especificação do WebRTC define que seja usada uma nova extensão (BUNDLE)[44] para que, além de se juntar os dados RTCP com os dados de média de cada stream, se junte também os dados de áudio e vídeo para que seja utilizada apenas uma porta durante a comunicação. 24 STUN é o mecanismo que permite que um dispositivo dentro de uma rede local tenha informação sobre qual o seu IP externo e porta que está a usar. Este mecanismo é muito usado em VoIP para permitir por exemplo que a aplicação saiba qual o endereço a registar no servidor SIP. 25 Um servidor TURN permite que uma aplicação que esteja dentro de uma rede NAT possa usar o IP do servidor para poder comunicar com outras aplicações. Neste caso, o servidor irá fazer relay dos dados para o cliente. 43

46 Codecs Uma das partes mais importantes de um sistema VoIP é a escolha dos Codecs a usar, pois determinará a qualidade das chamadas e também a taxa de interoperabilidade com outras aplicações e sistemas. Como se pode ver na Listagem 2.6(linhas a rtpmap do pacote m audio), os Codecs de áudio escolhidos para os browsers WebRTC suportarem incluem os Codecs mais usados em VoIP (PCMU e PCMA)[12], o Codec opensource Opus e também o Internet Speech Audio Codec (isac). v=0\r\n o= IN IP \r\n s=-\r\n t=0 0\r\n a=group:bundle audio video\r\n m=audio RTP/SAVPF \r\n c=in IP \r\n a=rtcp:49157 IN IP \r\n a=candidate: udp typ host generation 0\r\n a=candidate: udp typ srflx generation 0\r\n a=candidate: udp typ host generation 0\r\n a=candidate: udp typ srflx generation 0\r\n a=ice-ufrag:hf6pywllmlig5yb6\r\n a=ice-pwd:hq28bt4ukj5g2+ygziapl25m\r\n a=ice-options:google-ice\r\n a=sendrecv\r\n a=mid:audio\r\n a=rtcp-mux\r\n a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bpodcq8mhujuwup\r\n a=rtpmap:103 ISAC/16000\r\n a=rtpmap:111 opus/48000\r\n a=rtpmap:0 PCMU/8000\r\n a=rtpmap:8 PCMA/8000\r\n a=rtpmap:106 CN/32000\r\n a=rtpmap:126 telephone-event/8000\r\n m=video RTP/SAVPF \r\n c=in IP \r\n a=rtcp:49157 IN IP \r\n a=candidate: udp typ host generation 0\r\n a=candidate: udp typ srflx generation 0\r\n a=candidate: udp typ host generation 0\r\n a=candidate: udp typ srflx generation 0\r\n a=ice-ufrag:hf6pywllmlig5yb6\r\n a=ice-pwd:hq28bt4ukj5g2+ygziapl25m\r\n a=ice-options:google-ice\r\n a=sendrecv\r\n a=mid:video\r\n a=rtcp-mux\r\n a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bpodcq8mhujuwup\r\n a=rtpmap:100 VP8/90000\r\n a=rtpmap:101 red/90000\r\n a=rtpmap:102 ulpfec/90000\r\n Listagem 2.6: Exemplo de um SDP gerado pelo Google Chrome 44

47 Também o Internet Low Bitrate Codec (ilbc) 26 foi incluído na lista a suportar que, em conjunto com o isac, são dois Codecs comprados pela Google aquando da compra da Global IP Solutions. Desde então o ilbc foi tornado opensource sendo possível a sua inclusão em qualquer aplicação livremente e acredita-se que estes dois Codecs sejam usados pelo Skype[45]. O Opus é também um Codec de áudio opensource e royalty-free baseado no Codec Silk do Skype que permite obter resultados de boa qualidade.[46] Como Codec de vídeo a Google escolheu para a implementação nos browsers o VP8, que é um projeto da Google que integra o WebM. WebM é um formato que integra uma stream de audio e uma de vídeo, codificada com VP8. A qualidade do VP8 equipara-se à do H.264, outro Codec bastante usado no mundo das telecomunicações hoje em dia. No entanto ao contrário deste, o VP8 foi disponibilizado pela Google como opensource e royalty-free.[47] 2.5 Projetos relacionados Assim que começaram a surgir os primeiros drafts da especificação, foram criados vários projetos diferentes que começaram a testar as primeiras versões do Chrome Canary. Desde o início que se pôde ver bastante movimento e interesse nos grupos de discussão criados pela Google para o efeito, e aí assistiu-se à partilha de inúmeras páginas Web a tentarem implementar algo funcional, na esperança de obter ajuda. Como qualquer especificação que está a ser criada, também o WebRTC tem neste momento pouca produção científica disponível, por estar ainda na fase de criação do standard. Das imensas amostras de aplicações criadas, algumas são produtos de empresas conhecidas a tentar inovar e outras que tentam desde já entrar no mercado das aplicações VoIP com um produto muito atual. Mas além de clientes VoIP, outros projetos foram criados para ajudar na criação destas novas aplicações ou mesmo para adicionar suporte aos browsers. Uma das áreas onde se criaram projetos foi na sinalização; A Google criou a API de forma a que qualquer protocolo de sinalização pudesse ser usado e nessa perspectiva, e visto que um dos protocolos com que há interesse em interoperar é o SIP, algumas equipas começaram a traduzir complexas implementações de camadas SIP opensource para Javascript, para que fosse possível num cliente Web criar pacotes exatamente iguais aos criados por clientes SIP já existentes. A diferença sempre presente nestes pacotes é causada por uma limitação das aplicações Web não poderem utilizar ligações UDP ou TCP nativamente, que são os protocolos válidos para transportar SIP. Como a única ligação semelhante que as aplicações podem criar é utilizando Websockets, uma equipa da Acme-Packet e a Versatica 27, empresa criada com este projeto, começaram a criar em Maio de 2012 um draft[48] com o intuito de tornar standard o ws como protocolo válido para o transporte destes pacotes. Em seguida são apresentados alguns dos projetos relacionados com estas problemáticas: sip-js 28 Neste projeto foi migrado o código Python do projeto 39Peers 29 para código Javascript. Este projeto já cumpria alguns dos RFC s base do protocolo SIP e o código está sobre a licença Lesser General Public License (LGPL);

48 jssip 30 Biblioteca capaz de simular uma stack SIP em Javascript, e já com suporte para o estado atual da especificação para servidores acima mencionada. Este projeto implementa também uma abstração da lógica das APIs do WebRTC, permitindo a criação de chamadas de áudio e vídeo. O código está sobre a licença MIT License; sipml5 31 Cliente WebRTC que suporta chamadas de áudio e vídeo usando como protocolo de sinalização SIP sobre WebSockets. A biblioteca SIP foi criada através da tradução do projeto opensource ReSIProcrate 32 e o código dos clientes está sobre a licença GPL v3; Para que estas bibliotecas possam comunicar através de SIP, precisam de um ponto na rede capaz de receber estes dados através de Websockets e tranformá-los em UDP ou TCP. Para isso foram também criando projetos para este efeito. OverSIP 33 Servidor criado para servir de Gateway para as aplicações que criem SIP em Websockets para outras aplicações ou servidores que usem SIP nos protocolos standard. Este projeto tal como o jssip, foi criado pela empresa Versatica e código está sobre a licença MIT License; webrtc2sip 34 Servidor criado pela empresa Doubango para servir de Gateway para o cliente sipml5 poder comunicar através de SIP em Websockets para outras aplicações ou servidores que usem SIP nos protocolos standard. O código deste projeto tal como o sipml5, encontra-se na licença GPL v3; Asterisk O servidor de VoIP opensource implementou o suporte para Websockets e também para WebRTC, suportando a partir da versão 11 chamadas para clientes WebRTC baseados em Websockets; Além deste projetos orientados para o SIP em browsers, existe também o plugin webrtc4all 35 criado também pela Doubango, para permitir que outros browsers como o IE, o Opera, o Firefox e o Safari tenham capacidades as WebRTC. Além disso, este componente adiciona também mais Codecs às capacidades do browser, o que permite que haja uma maior interoperabilidade com outros sistemas Produtos Concorrentes Além destes projetos que trazem algo de novo à tecnologia criada pela Google, existem já várias empresas a criar clientes baseados em WebRTC e que utilizam arquiteturas distintas. Em seguida é apresentada uma lista não extensiva de clientes e alguns detalhes sobre os mesmos. Na Tabela é apresentada uma análise resumida das propriedades das aplicações apresentadas, incluindo a informação sobre se estas incluem funcionalidades RCS

49 Bistri Bistri 36 é um serviço Web que fornece aos seus utilizadores a possibilidade de partilharem um endereço web como se fosse o seu número de telefone. Quando se acede a esse link o utilizador recebe uma chamada que pode incluir áudio e vídeo, em que a média da chamada é tratada pelo WebRTC. O serviço tem integração com Facebook, Gtalk, Windows Live e Yahoo e pode também funcionar através do plugin Flash. É utilizado o protocolo XMPP através de HTTP na comunicação cliente-servidor. TenHands TenHands 37 é uma plataforma que fornece a capacidade de estabelecer comunicações em tempo real entre browsers, estando integrado com algumas redes sociais e redes de empresas como Jive, Box, Salesforce, Facebook e Yahoo. A média das chamadas é transmitida usando WebRTC, no entanto para já (Fevereiro 2013) a utilização deste sistema ainda necessita da instalação de um plugin proprietário que permite a comunicação com os servidores através de uma API proprietária utilizando HTTP. Connect Connect é um serviço disponibilizado pela empresa Utribo 38 direcionado para a criação de páginas Web em que o utilizador possa através de um clique, fazer uma chamada para a empresa que contratou o serviço. Desta forma as empresas podem ter os seus clientes a ligar por exemplo para o centro de apoio a clientes gratuitamente e através do browser. A versão atual usa WebRTC e para browsers que não suportem, o suporte é feito através da instalação de uma aplicação no computador do cliente. opentok opentok 39 é uma API desenvolvida pela empresa tokbox que permite a criação de aplicações fornecendo a possibilidade de integração com os seus serviços. A API permite a realização de chamadas entre browsers, ios e Android, sendo que na versão anterior a integração com páginas Web dependia do plugin Adobe Flash, e atualmente suporta chamadas através de WebRTC. O código fonte da aplicação Javascript não está disponibilizado abertamente, mas os projetos dos vários componentes de servidores para integração com a Software Development Kit (SDK) são públicos e estão sobre a licença MIT. Clientless Web Softphone Clientless Web Softphone é o novo produto da empresa dedicada a soluções de telecomunicações e VoIP Thrupoint 40. Este novo produto a ser construído depende de um Gateway também criado pela empresa para garantir a interoperabilidade entre o mundo SIP com o seu protocolo proprietário enviado através de HTTP. A média é

50 baseada na tecnologia WebRTC e para permitir a integração com clientes SIP criaram o componente Thrupoint Fusion Media Broker para conseguir a tradução entre os protocolos de média. sipml5 Como já foi referido acima, sipml5 é um cliente Web que permite o estabelecimento de chamadas VoIP através de WebRTC e a troca de mensagens instantâneas. Faz parte de um ecossistema de clientes da empresa Doubango 41, que disponibiliza vários componentes VoIP incluindo versões de clientes para Android e para Desktop, bem como alguns componentes para servidores para permitir a tradução de média WebRTC e a tradução de SIP através de WebSockets para TCP ou UDP. Este cliente disponibiliza também implementadas de algumas funcionalidades básicas da especificação RCS. O código está disponibilizado sobre a licença GPL v3. frisb FrisB 42 é um serviço criado para enviar convites de chamadas para a números de telefone reais da PSTN, evitando assim custos para o utilizador que envia o convite. Quando a chamada é devolvida, o utilizador pode atendê-la na página Web. A aplicação usa WebRTC para o transporte dos dados de média, e não pondera a inclusão de vídeo nestas chamadas, estando a empresa preocupada em criar uma aplicação simples e de boa qualidade. Zingaya Zingaya 43 é um produto com funcionalidades semelhantes ao Connect acima referido. O principal objetivo é a capacidade de os utilizadores poderem usar a página Web para contactarem gratuitamente os subscritores do serviço, usando WebRTC. Além destes serviços, a aplicação tem também outras funcionalidades que podem ser acrescentadas como o serviço de correio de voz e o histórico de chamadas. Twelephone Twelephone 44 acrescenta capacidades de voz, vídeo, presença e mensagens instantâneas à rede social Twitter. Através da instalação de um plugin no Chrome, a interface da página Web da rede social fica alterada, aparecendo as opções de presença dos outros utilizadores desta aplicação, permitindo a realização de chamadas através de WebRTC e a troca de mensagens com estes utilizadores. JsSIP tryit JsSIPhttp:// é um cliente criado pela empresa Versatica para demonstrar a utilização da biblioteca JsSIP. A aplicação utiliza SIP através de WebSockets e permite o estabelecimento de chamadas de voz e de vídeo através de WebRTC

51 Apesar do cliente permitir a integração direta com servidores que já tenham implementado o draft criado pela Acme, a empresa também criou o Gateway OverSIP para permitir a comunicação com outros servidores. O código fonte está disponível e encontra-se sobre a licença MIT. Client Company Protocol Transport License Audio Video RCS Bistri Bistri Engineering XMPP HTTP Not Released Yes Yes No TenHands TenHands Proprietary HTTP Not Released Yes Yes No Connect Utribo Proprietary HTTP Not Released Yes Yes No opentok tokbox Proprietary HTTP MIT Yes Yes No Clientless Thrupoint Proprietary HTTP Not Released Yes Yes No Sipml5 Doubango Telco SIP WebSockets GPL v3 Yes Yes Yes FrisB FrisB Proprietary HTTP Not Released Yes No No Zingaya Zingaya Proprietary RTMP Not Released Yes No No Twelephone GetVocal inc Proprietary WebSockets Not Released Yes Yes No Phono Voxeo Labs XMPP HTTP Not Released Yes Yes No jssip tryit Versatica SIP WebSockets MIT Yes Yes No Tabela 2.2: Tabela comparativa de algumas soluções atuais 2.6 Discussão e Conclusões Hoje em dia existem já vários projetos opensource ou proprietários que implementam stacks SIP e que permitem a criação de aplicações VoIP com um custo de implementação reduzido. No entanto, devido a todas as alterações e extensões que vão sendo criadas na metodologia de criação de standards do IETF, torna-se complicado quando dois clientes criados por diferentes empresas tentam interoperar. Na minha experiência de desenvolvimento destas aplicações e da necessidade de interoperar com diferentes servidores e aplicações SIP, constato que diferentes empresas tiram diferentes significados ao analisar os mesmos documentos. Muitas vezes os mesmos headers (SIP ou SDP) são utilizados erradamente tornando a interoperabilidade um processo complicado. O objectivo inicial do protocolo SIP foi a criação de uma sessão para se conseguir fazer simples chamadas de voz, e neste caso de uso, a maioria das aplicações são interoperáveis sem problemas. Há medida que se vão criando novas funcionalidades, ou adicionando suporte para melhorar as capacidades das chamadas, torna-se mais complicado cumprir este objetivo. Para se ter noção da complexidade que se acrescentou ao SDP de criação de uma chamada, pode-se comparar o SDP mostrado na Listagem 2.5 que representa o exemplo dado no RFC original do SIP, com o da Listagem 2.6 que representa o SDP que se obtém hoje em dia do Chrome. É natural que os protocolos evoluam e é indiscutível que é necessário que acompanhem a evolução da tecnologia e também que se acrescentem medidas de segurança aos protocolos. No entanto é visível a dificuldade que estas alterações trazem quando se pretende criar uma aplicação que consiga comunicar com todos os clientes SIP. Nas escolhas da Google para esta nova tecnologia, a decisão de não forçar um protocolo de sinalização, e o facto de ter feito um esforço evidente[49] para que a API funcionasse de forma a permitir uma fácil integração com o protocolo SIP foi um bom passo neste percurso para a interoperabilidade. Numa primeira versão da 49

52 especificação foi criado o protocolo RTCWeb Offer/Answer Protocol (ROAP), que não era facilmente integrável com o protocolo SIP, dada a necessidade de as aplicações negociarem os SDPs num conjunto de 4 comunicações (o SIP apenas fornece 2 que são o INVITE e a sua resposta). Devido ao feedback dado pelos programadores, essa implementação foi deixada de lado, sendo hoje usado o protocolo JavaScript Session Establishment Protocol (JSEP) na implementação atual do WebRTC. A indefinição de um protocolo de sinalização permite também a abstração do browser da máquina de estados da chamada, permitindo que os criadores das aplicações tenham o controlo total de como pretendem que a negociação seja feita, e permitindo assim inúmeras possibilidades de arquiteturas, desde a ausência de servidores ou Gateways, até à interoperabilidade com protocolos e sistemas já existentes. O facto de ter escolhido o Codec VP8 como Codec de vídeo obrigatório, não ajuda este propósito. Grande parte dos serviços VoIP suportam H.264 e H.263 mas não este novo Codec que a Google está a tentar impor por ser seu e por ser gratuito.[13] Hoje em dia o Codec H.264 apesar de ser pago, está em grande expansão, sendo já possível encontrar vários dispositivos que suportam a sua codificação e descodificação nativamente através de hardware[50]. Quando comparado com o VP8 que está a dar os primeiros passos, onde este é suportado, ainda requer que seja tratado através de software estando assim em desvantagem perante o H.264. Este assunto já causou várias discussões e mesmo alguns artigos lançados com comparações e opiniões sobre este passo da Google[51]. 50

53 Capítulo 3 Requisitos e Arquitectura da solução Baseado nos problemas de interoperabilidade descritos na secção anterior, e de forma a cumprir os objetivos iniciais de definir uma arquitetura e implementar os componentes necessários, para que seja possível o estabelecimento de chamadas entre browsers e aplicações VoIP e a PSTN, devem ser analisados os protocolos a utilizar na solução. Dado que o protocolo de sinalização não é definido pela especificação do WebRTC, as várias possibilidades devem ser pesadas para uma decisão ponderada e justificada. A solução passa por definir formas de trocar a sinalização mas também os protocolos utilizados para a média devem ser analisados para se perceber onde é necessária a sua implementação ou tradução. Visto este trabalho estar a ser criado no contexto do produto de uma empresa e que o objetivo será a integração com os outros elementos do sistema, o produto deve ser analisado para que se identifiquem os requisitos e se possam tomar decisões com o contexto necessário. A implementação de um novo cliente Web deve cumprir os requisitos dos outros clientes já existentes da empresa para que as possibilidades de integrações com outros sistemas sejam as mesmas. 3.1 Requisitos de aplicações RCS A GSMA é a associação responsável pela criação de grande parte dos standards que se encontram implementados no mundo das telecomunicações móveis. Os grandes operadores móveis mundiais e também os maiores fabricantes de dispositivos móveis têm representação nesta entidade, permitindo assim que estejam alinhados os interesses de ambas as partes para produzir melhores especificações. Nos últimos anos a GSMA tem vindo a desenvolver a especificação RCS, que consiste na definição da forma standard de criar aplicações que permitam a um utilizador de dispositivos móveis ter capacidades adicionais. O principal objetivo da especificação é a criação de serviços extra aos oferecidos atualmente pelos operadores de redes móveis, permitindo nativamente na rede a implementação de sistemas baseados em IP Multimedia Subsystems (IMSs), fomentando também a interoperabilidade entre utilizadores de diferentes operadoras. A especificação atual encontra-se na versão 5.1, e define como as aplicações e redes dos operadores devem implementar capacidades como a troca de mensagens instantâneas, a transferência de ficheiros, partilha de conteúdos multimédia durante chamadas, partilha de localizações geográficas ou mesmo a partilha de presença. Para além destas capacidades extra, para que seja possível ter as mesmas capacidades que um dispositivo móvel, é também definido como se devem implementar aplicações cliente que possam correr em dispositivos sem serviços de telefone tais como um computador, tablet ou um simples browser. Para isso é definido como devem estas aplicações fazer chamadas VoIP de áudio e vídeo.[33] 51

54 Este esforço das operadoras faz hoje mais sentido e mostra mais a sua necessidade com a existência de cada vez mais aplicações Over-The-Top (OTT), que permitem a realização de chamadas e troca de conteúdos através dos telemóveis, mas sem usar os serviços nativos da operadora. Usando um smartphone ligado a uma rede sem fios é possível fazer chamadas gratuitas ou trocar mensagens através aplicações como o Skype, Viber 1, WhatsApp 2, Gtalk entre outras. Estas aplicações fazem com que o número de chamadas e Short Message Services (SMSs) nativas pela rede operadora diminuam muito, o que motivou a criação da especificação RCS para permitir também os serviços extra nativamente e entre os diferentes operadores como forma de combate a este fenómeno. As implementações das aplicações e dos servidores dos operadores são baseadas no protocolo SIP, e juntam e redefinem vários standards já existentes criados pela Open Mobile Alliance (OMA) e pela 3rd Generation Partnership Project (3GPP).[52] Para facilitar a criação de aplicações Web que cumpram os requisitos RCS, foi proposta e encontra-se a ser definida uma API[53] baseada em Representational State Transfer (REST), que utiliza o protocolo HTTP como comunicação e baseia-se já na utilização de WebRTC para a média das chamadas. A RCS REST API foi definida para que a disponibilização dos serviços RCS seja simplificada à utilização de simples chamadas a recursos HTTP. A título de exemplo, a troca de mensagens instantâneas na especificação RCS é feita através do estabelecimento de uma sessão MSRP, usando SIP para a sua negociação. Na REST API o cliente tem de enviar uma mensagem através de um pedido HTTP POST que leva apenas a informação da mensagem e destinatário. Toda a lógica necessária tem de ser gerida por um Gateway na rede, que verifica se o utilizador em questão já tem alguma sessão ativa para o destinatário, criando uma nova caso não exista. A especificação deste Gateway define também uma forma de se poderem integrar serviços RCS em páginas de terceiros, através de autenticação OAuth, criando assim um serviço que controle permissões para que aplicações de terceiros se possam registar e usar o serviço 3. O principal produto da WIT é um ecossistema composto por aplicações VoIP para várias plataformas e dispositivos e por um servidor que as interliga. Estas aplicações além de capacidades VoIP, cumprem também as especificações RCS. Assim sendo, os clientes Web a desenvolver devem também ser projetados para suportarem estas funcionalidades de modo a poderem integrar o ecossistema atual. Deverá ser tida em conta portanto a necessidade de integração com os vários protocolos que esta especificação exige (e.g SIP, SRTP, MSRP, XML Configuration Access Protocol (XCAP), Synchronization Markup Language (SyncML), Internet Message Access Protocol (IMAP)). 3.2 Requisitos dos cenários de integração As possibilidades de utilização deste produto são várias e dependendo do cliente final, as especificidades da colocação em produção variam bastante consoante o objetivo que se pretende atingir. Estas possibilidades aliadas aos clientes Web podem ser divididas em três diferentes arquiteturas que são listadas e descritas em A autenticação e autorização OAuth baseia-se na disponibilização de uma forma dos utilizadores de um serviço poderem dar autenticar-se e dar permissões de um outro serviço, sem nunca ter de providenciar as suas credenciais no serviço onde pretende a integração. Um exemplo muito utilizado hoje em dia é quando alguma página na Internet permite que se use como método de autenticação o Facebook ou Google. 52

55 seguida, para que possam servir como base de discussão para as próximas secções. Os requisitos que a empresa considera fundamentais, passam pela integração do cliente Web a ser desenvolvido nestes três cenários possíveis Cenário 1: Servidor standalone com clientes Web Esta primeira possibilidade de colocação em produção cinge-se apenas à utilização de clientes Web que comuniquem entre si no contexto de uma dada empresa. Um exemplo de utilização de um sistema destes é a disponibilização de clientes Web para integrar as páginas Web de Intranet de uma dada empresa, criando uma plataforma de comunicação interna em que os funcionários podem usar para comunicar entre si. Outro exemplo de aplicação é a integração num serviço de centro de apoio a clientes em que as chamadas podem ser feitas pelo utilizador a partir das páginas Web. Neste caso, para permitir que as aplicações comuniquem entre si e que os utilizadores se possam registar e contactar outros utilizadores, é necessário que o servidor standalone funcione como intermediário dos clientes Web mas apenas Figura 3.1: Clientes web standalone para sinalização e outros protocolos que não a média das chamadas, dado que esta é trocada diretamente entre os browsers. Este caso distingue-se dos restantes por não haver necessidade de interoperar a média entre dispositivos que não utilizem WebRTC Cenário 2: Servidor standalone com vários clientes Uma segunda possibilidade de colocação em produção dos clientes Web, é uma situação semelhante à primeira, mas com a particularidade de se incluírem também clientes SIP. Exemplo da utilização de um sistema deste tipo é a colocação em produção numa empresa que queira implementar uma rede interna de comunicações baseada em VoIP, permitindo que se use qualquer dispositivo físico com capacidades SIP, os clientes WIT instaláveis para PC e dispositivos móveis ou então o cliente Web. Figura 3.2: Clientes standalone Neste caso, é necessário que as aplicações incluindo as web-based se registem no servidor da WIT e que, dependendo da configuração, a média das chamadas seja trocada entre aplicações ou então através do próprio servidor. 53

56 3.2.3 Cenário 3: Clientes Web interligados com a PSTN Por fim, existe a possibilidade de integrar as aplicações cliente da WIT com a PSTN, em redes de operadores ou em servidores de outras empresas. Um exemplo da utilização deste sistema é a colocação em produção das aplicações como clientes RCS em que a sua utilização normal é integrada com uma rede de um operador de comunicações móveis, para permitir a substituição das aplicações OTT, como descrito na Secção 3.1. Outra possível utilização é a disponibilização por parte de uma operadora de aplicações que permitam ao utilizador fazer e receber chamadas que seriam para o seu telemóvel no PC ou na página Web da sua área de clientes, como é o caso da Vodafone Portugal. Para esta integração pode-se excluir a utilização do servidor da WIT como servidor standalone, já que as aplicações se vão registar num servidor na rede do operador. No entanto é necessário garantir que os clientes Web conseguem comunicar com o sistema que estiver implementado dentro dessa rede, utilizando por isso todos os protocolos stan- Figura 3.3: Clientes web numa rede operador dard típicos dos operadores. 3.3 Sinalização - possíveis soluções Tal como foi mostrado no capítulo anterior, várias empresas estão já a preparar os seus produtos baseados em WebRTC e consequentemente, estão também a definir o protocolo de sinalização a usar. Existem várias possibilidades que se resumem em três diferentes categorias. Cada uma delas será analisada em seguida, mostrando os pontos fortes e fracos de cada uma das soluções, para permitir uma discussão e escolha de solução, tendo em conta os requisitos de arquiteturas mostrados acima RCS REST API Uma primeira possibilidade de protocolo de sinalização a utilizar é a implementação de um RCS REST API Gateway que siga a definição da RCS REST API[53] aprovada pela GSMA como sendo uma possível forma standard de clientes Web se ligarem a redes IMS. A comunicação é feita através de HTTP e são definidos vários parâmetros enviados nos pedidos que são depois transformados em comandos SIP para permitir a integração com outros serviços. Um dos problemas do protocolo HTTP é que não permite pedidos servidor-cliente, que são necessários para definir algumas das capacidades que um cliente VoIP necessita. Para contornar este problema é utilizado um mecanismo de Long-polling que tem de ser implementado no Gateway como método de comunicação com os clientes. 54

57 Figura 3.4: Esquema do gateway de transformação necessário para a RCS REST API Para cumprir os requisitos da secção anterior usando esta solução, é necessário implementar a especificação da RCS REST API no servidor da WIT para cumprir os dois primeiros cenários, e para cumprir o terceiro é necessário que a rede do operador tenha suporte para esta especificação, ou então é necessária a implementação de um Gateway intermédio como mostra a Figura 3.4. Vantagens Utilizar esta alternativa de sinalização tem a vantagem de se estar seguir uma especificação standard, sendo sempre este um ponto positivo. A implementação deste mecanismo tem também a vantagem de utilizar pedidos HTTP que são suportados por grande parte dos browsers há vários anos, visto que são usados os métodos de Ajax. Este método permite também a simples integração com formas de autenticação já bem divulgadas e bastante usadas em HTTP, baseadas em Cookies de autenticação, permitindo que as capacidades de aplicações RCS sejam facilmente integradas em páginas Web variadas, utilizando pedidos que podem já estar autenticados pelo utilizador no browser. Um dos objetivos da RCS REST API é a criação de uma forma genérica de se poder integrar facilmente serviços RCS em páginas de terceiros, através da autenticação por OAuth, o que possibilita a fácil expansão deste tipo de clientes. A empresa Acme Packet já referida no capitulo anterior, está também a ponderar a implementação desta especificação nos seus servidores[54], permitindo assim que um dia seja possível ligar clientes com estas capacidades diretamente às redes de operadores. Desvantagens A utilização de Long-polling implica o sucessivo estabelecimento de ligações TCP o que causa um grande overhead na rede quando comparado com a utilização de Websockets[55]. A REST API define comandos HTTP que não são diretamente mapeados para os respectivos pedidos em SIP, o que implica que o Gateway tenha uma complexidade acrescida de implementação. Exemplo disso é a transferência de ficheiros, que para o cliente é feito através de um POST do ficheiro a transferir para o servidor, e este tem depois de fazer a tradução e criar toda a lógica necessária para a criação de uma sessão SIP e de partição do ficheiro, para poder enviar o mesmo em pacotes MSRP. Esta lógica própria de um cliente torna o Gateway pesado, para a utilização em produção com o número de utilizadores que um operador móvel pode ter. 55

58 O sistema de autenticação que permita ao utilizador autorizar que páginas de terceiros acedam a cada uma das capacidades que a aplicação precise através de OAuth, tem um custo de implementação muito elevado e apesar de ser necessário para que se cumpra os requisitos do standard, não é uma forma acessível de criar aplicações simples dada a complexidade do RCS REST API Gateway. A integração com outros protocolos é também uma limitação, pois apesar de ser possível adicionar novos comandos no caso de se construir também o Gateway responsável pela lógica de cada funcionalidade, perdia-se assim a vantagem de seguir um standard e não seria possível integrar com o RCS REST API Gateway de outra empresa SIP através de WebSockets Uma segunda possibilidade de definir a sinalização é construindo pacotes SIP diretamente na aplicação Web, usando Javascript. Tal como foi mostrado na secção 2.5, várias empresas optaram por criar bibliotecas baseadas em projetos open-source que implementam a lógica do protocolo SIP em Javascript. A utilização de uma destas bibliotecas para construir os comandos SIP força a necessidade de existir mais um elemento na rede capaz de perceber o protocolo Websockets. No entanto tal como foi mencionado atrás, há uma proposta[48] criada pela empresa Acme Packet para tornar os WebSockets num protocolo válido para o transporte de pacotes SIP. Como produtores de Session Border Controllers (SBCs) 4, a Acme Packet está a desenvolver já a sua proposta de standard no seu produto, possibilitando que estes clientes se liguem a uma rede IMS tal como qualquer outro cliente que use TCP ou UDP. Figura 3.5: Esquema da utilização de SIP através de WebSockets À semelhança da solução anterior, para cumprir os requisitos usando esta especificação é necessário implementar o suporte para Websockets no servidor da WIT e no caso de um operador não ter presente na sua rede um servidor com estas capacidades, é necessário que seja implementado um Gateway de tradução, tal como no caso do REST. Vantagens Esta possibilidade tem a vantagem de permitir a ligação direta de clientes aos servidores sem a necessidade de pontos de tradução na rede, se for usado um servidor com suporte para a especificação criada pela Acme Packet. 4 Software próprio para ser o primeiro ponto de entrada de uma rede de operadores, que é normalmente capaz de gerir as sessões SIP e fazer re-encaminhamento da média entre clientes 56

59 O facto de ser um cliente completo, permite a isenção de um Gateway extra quando o objetivo for a integração com redes de operadores que suportem WebSockets. A utilização de WebSockets como transporte disponibiliza uma comunicação bi-direcional cliente-servidor à semelhança do que conseguem obter os clientes VoIP convencionais capazes de transmitir pacotes através de TCP ou UDP. Desvantagens Seguindo esta alternativa, os clientes ficam bastante pesados por terem toda a lógica de criação de pacotes SIP, implementada em Javascript, sendo também obrigatório que o servidor onde o cliente se liga implemente um draft[48] que está ainda a ser definido. A utilização de bibliotecas que estão ainda numa fase inicial do seu desenvolvimento para suportar a criação de pacotes SIP em Javascript é também um risco, por estar em constante desenvolvimento e não ser um produto amplamente utilizado e testado. A utilização deste método vai também fazer com que o cliente tenha um pior desempenho em dispositivos com menos capacidades de processamento e memória. Outro dos pontos negativos está associado à utilização de WebSockets, que por serem uma tecnologia recente, não está disponível em todos os browsers mais utilizados atualmente. 5 Desta forma não são suportados todos os browsers mais comuns, falhando num dos requisitos, pois ainda que os browsers mais antigos não suportem WebRTC, podem continuar a ter suporte para as restantes funcionalidades RCS, se outro protocolo de comunicação for suportado, como o HTTP. Assim, este é um grave problema na utilização desta solução. Com esta solução, a aplicação é disponibilizada com todo o código fonte necessário para integrar qualquer servidor que suporte WebSockets como transporte válido para SIP. Este é um problema se pensarmos na possibilidade de replicação do código, que ainda que protegido, está disponível e pode ser alterado e usado em outros projetos sem o consentimento da empresa. No caso de se fazer uma integração com um operador que não tenha suporte para esta especificação, é necessária a presença de um Gateway de tradução, sendo que os pedidos SIP passam a ser construídos duas vezes desnecessariamente. O suporte para outros protocolos fica também limitado, pois esta solução baseia-se na ideia de que os pedidos são construídos no browser e sendo assim, para além de uma stack SIP, será também necessário que existam stacks MSRP, IMAP, XCAP, SyncML, entre outras construídas em Javascript. Estes protocolos continuam a precisar também de um Gateway de tradução por necessitarem de ligações TCP ou UDP. No caso de se construir componentes no servidor para estes protocolos, o cliente não estará a implementar o standard que está a ser definido, não podendo integrar com outros servidores que sigam este documento. 5 A Microsoft apenas adicionou suporte para WebSockets ao browser Internet Explorer na versão 10, que está a ser disponibilizado com o novo Windows 8 e que foi adicionado ao Windows 7 apenas em Fevereiro de Apesar de já não ser o browser mais utilizado, ainda contempla uma grande fatia de utilizadores (13,5%) sendo que a maior parte dos utilizadores do IE ainda utilizam as versões 8 e 9 (11,5%)(Dados de Fevereiro de Fonte:browsers browsers_explorer.asp). 57

60 3.3.3 API privada através de WebSockets ou HTTP A terceira possibilidade de protocolo a utilizar para a sinalização dos clientes Web, é a criação de uma API privada transportada através de WebSockets. Como mostra a Figura 3.6, a solução passa pela implementação de um Gateway capaz de fazer a tradução de um conjunto pré-definido de parâmetros estruturados em objetos JavaScript Object Notation (JSON), para comandos dos protocolos SIP, XCAP, MSRP entre outros. Quando a aplicação tiver de correr num browser que não tenha suporte para WebSockets, deve ser utilizado o protocolo HTTP com uma implementação de Long-polling. A única alteração seria a forma como os objetos JSON são transportados, sendo que em vez de ser apenas enviado na ligação TCP WebSockets, é transmitido como corpo de um pedido HTTP POST. Figura 3.6: Esquema do Gateway de tradução de uma API privada Quanto aos requisitos definidos acima, esta solução obriga à implementação da tradução desta API no servidor da WIT e da implementação de um Gateway para interoperar com redes de operadoras. A supressão do Gateway neste caso é impossível, dado que o protocolo utilizado é proprietário. Vantagens Com esta aproximação, é possível criar clientes mais leves por haver um Gateway responsável por suportar os protocolos necessários à integração com as redes dos operadores ou outras aplicações VoIP. Com a implementação de um Gateway baseado num protocolo próprio, não existe o limite dos protocolos definidos nos standards das soluções anteriores, podendo no futuro ser implementado o suporte para mais protocolos facilmente, sem a necessidade de implementação destas lógicas em Javascript. O facto de serem usados WebSockets como protocolo de transporte, e por estes criarem uma ligação TCP permanente, torna a implementação dos clientes mais simples por poder facilmente haver comunicações nos dois sentidos. A utilização de pedidos HTTP quando WebSockets não for suportado é um ponto muito positivo na medida em que a aplicação é compatível com mais browsers e consequentemente cobre um maior número de utilizadores. A API pode ser criada de forma a que os comandos passados para o Gateway sejam facilmente mapeáveis para o protocolo para o qual se pretende traduzir. A utilização de uma API privada é uma vantagem por ser sempre necessário ter o componente de rede capaz de o traduzir, tornando o acesso e alteração indevida do código fonte um problema com menor impacto. 58

61 Desvantagens Ao implementar esta solução, não estará a ser seguido nenhum dos standards que se estão a definir para este tipo de clientes e que as duas soluções anteriores utilizam. Esta solução obriga a que haja sempre um Gateway de tradução na rede, ao contrário das soluções anteriores. 3.4 Média Como já foi explicado anteriormente, a média que um browser com suporte para WebRTC produz, implementa algumas novas medidas de segurança e de NAT-T, que não são compatíveis com a maior parte das aplicações e servidores atuais, até porque parte desses novos protocolos estão a ser definidos a par com a especificação do WebRTC. Assim, de forma a conseguir a interoperabilidade com outros sistemas para além dos browsers, é necessário que se implementem os novos protocolos num ponto na rede, sendo que os requisitos de cenários descritos acima devem ser tidos em conta para se ter uma ideia dos casos de uso que se pretendem cumprir. No primeiro cenário apresentado na secção em que apenas existem aplicações Web, o servidor responsável pela sinalização pode apenas passar o SDP entre as aplicações de forma a que os browsers troquem entre si a média. Assim sendo, não é exigida a implementação dos protocolos nas aplicações ou servidores ao contrário do segundo cenário apresentado na Figura 3.2, em que as aplicações Web têm de interoperar com outras aplicações VoIP standard. Neste caso os mecanismos de ICE, BUNDLE, Datagram Transport Layer Security (DTLS)-SRTP tem de ser implementados ou nas aplicações ou no servidor a utilizar para que se consiga comunicar com os browsers. No caso do terceiro cenário, as aplicações Web a construir serão utilizadas para comunicar com as redes de operadores e estas poderão integrar as chamadas nos vários serviços disponíveis, como mostra a Figura 3.3. O reencaminhamento de e para a rede mundial de telecomunicações, para outras aplicações VoIP ou mesmo o desvio para o correio de voz são possíveis casos de utilização da média de aplicações VoIP numa rede de operadores. Para isto é necessário que existam componentes na rede capazes de processar e traduzir a média enviada por clientes WebRTC. Os já referidos SBCs desenvolvidos pela Acme Packet estão a ganhar suporte para este tipo de média, o que faz com que seja possível uma fácil integração em operadores que tenham este componente como ponto mais externo da rede. No entanto nem todas as operadoras terão este suporte em breve e para que seja possível uma utilização com os sistemas atuais, uma menor dependência de terceiros, e mesmo um time-to-market mais reduzido no produto a criar, a implementação terá de ser passar pelos componentes atuais da empresa. Com esta análise é possível perceber que para cumprir os requisitos é necessária a implementação de um Gateway capaz de fazer a tradução de média WebRTC. A implementação nas aplicações cliente pode também ser uma possibilidade, mas será mais trabalhoso pelo número de implementações necessárias. 3.5 Discussão da solução 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. 59

62 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 SIP stack 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 os browsers mais antigos, terá de se usar uma alternativa a esta recente tecnologia. Uma possibilidade é a utilização de um canal RTMP 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 de plugins, 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 alguns browsers 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 de browsers, 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 segunda 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, 60

63 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 no browser 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 dos browsers, 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 a plugins. 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 Figura 3.7: Soluções a criar para cumprir os cenários requeridos 61

64 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 os browsers 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. Com que servidor integra o cliente? Com que clientes necessita de interoperar? Onde implementar o suporte para a média WebRTC? Cenário 1 Cenário 2 Cenário 3 WIT Application Server WIT Application Server Rede do Operador ou Servidor IMS Apenas clientes Web Clientes Web + Clientes Clientes Web + Clientes SIP/VoIP SIP/VoIP + PSTN 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 62

65 Para cumprir os vários cenários em que as outras aplicações da empresa integram, é necessária a implementação do processamento da média produzida pelos browsers. 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 um browser, 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 analisando 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. 3.6 Arquitetura dos componentes Em resumo, os componentes a desenvolver segundo estas decisões baseiam-se na definição da API, num Gateway que permita a tradução desta e mas mais que isso, permita também a integração desta tradução no servidor da WIT de forma a que seja possível cumprir os vários cenários de integração. O outro componente a desenvolver é o cliente Javascript que consiga comunicar através dos protocolos de transporte já referidos usando a API a definir. Tendo como ponto de partida a atual API que existe para os clientes Flash, esta tem de ser melhorada e generalizada. O módulo de tradução deve também ser redesenhado para que permita a tradução da API de comunicação independentemente dos protocolos de transporte utilizados, e para que, seja qual for o cenário de integração, o módulo possa ser reutilizado, como mostra a Figura Servidor Tanto para integrações com o ecossistema da WIT como com sistemas de terceiros que permitam apenas os protocolos standard de aplicações RCS e VoIP, será necessário traduzir os vários comandos da WIT API para um formato engérico, que possa depois ser usado para ser transformado para o protocolo da aplicação destino. Para isto, deve ser criado um componente genérico que possa ser incluído no servidor, qualquer que seja o modo em que esteja a correr (i.e. Gateway ou Servidor standalone). Também para resolver os problemas da interoperabilidade da média dos clientes WebRTC, será necessário que o servidor tenha um módulo para tratar desta tradução, quando for necessário. Estes módulos devem respeitar algumas regras de implementação para que cumpram todos os requisitos e para que sejam expansíveis e modulares, de forma a criar componentes future-proof. WIT API Translator Nas versões atuais do servidor da WIT, sempre que um pedido chega ao servidor, é 63

66 transformado no comando que a aplicação destino percebe. No entanto, os pedidos apenas podem entrar no servidor por SIP ou através de RTMP com as variáveis enviadas pelo cliente Flash. Apenas existem estas duas vertentes de protocolos e por isso toda a implementação atual está limitada a este tipo de clientes. Quando o servidor necessita de enviar um pedido ou uma resposta para um dado utilizador, o seu pedido é sempre construído assumindo que a camada de comunicação apenas tem um destes clientes. Para que se possa adicionar suporte para mais protocolos, a implementação da lógica central do servidor deve ser completamente agnóstica ao tipo de cliente que enviou ou que irá receber o pedido que está a ser tratado. Apenas quando o pedido ou resposta tiver mesmo de deixar o servidor, este deve ser traduzido para o protocolo respectivo que o cliente em questão suporte. Para isso, e também para que os clientes Flash continuem a ser suportados, devem ser usados componentes para suportar o trasporte específico (e.g. RTMP, HTTP com Long Polling, WebSockets), e assim que o comando chegue às camadas de tradução, devem ser construídos comandos genéricos tal como os comandos que resultam de um pedido ou resposta SIP. Media relay server Para a média terá de ser feito algo semelhante à sinalização, dado que se está a lidar com clientes que utilizam protocolos não standard no mundo VoIP. Para ser possível atualmente integrar as aplicações Web (Flash ou WebRTC), é necessário com que o servidor a desenvolver suporte também a retransmissão de média em formatos mais amigáveis para a maioria das aplicações atuais. A utilização de RTMP como transporte de áudio e vídeo passa obrigatoriamente pela tradução do protocolo de transporte para RTP. No entanto, o que o servidor atualmente faz é a receção dos pacotes de áudio e vídeo que chegam através do WMS e criar um pacote RTP com estes para enviar para o utilizador em questão. No caso do DTLS-SRTP vários mecanismos têm de ser implementados para permitir o processamento da média enviada pelos browsers. Atualmente mecanismos tais como o BUNDLE, o DTLS e o ICE não são suportados, e devem ser implementados para permitir que a média seja processada no servidor e depois traduzida para cada um dos clientes destino. Para que a média possa ser trocada entre cada um dos clientes, deve ser implementada uma forma de mapear quais os componentes a serem utilizados numa dada chamada, pois ao contrário da sinalização, a média não precisa de ser tratada na lógica do servidor, e deve apenas ser re-encaminhada para o cliente em questão. A título de exemplo, se um cliente Flash estabelecer uma chamada para outro cliente Flash, não fará sentido que a média seja descodificada para voltar a ser codificada da mesma forma, e deve então ser selecionado um componente que trate deste caso especifico, em que a única coisa que terá de fazer é receber de uma ligação RTMP e enviar para a outra. Quanto à média entre dois clientes WebRTC, o caso é semelhante por ambos usarem os mesmos protocolos, no entanto, deve ser passível de configuração se o servidor deve tratar a média entre dois browsers ou se deve deixar que estes comuniquem entre si diretamente, já que é uma das vantagens que a tecnologia criada pela Google traz. No entanto, se a média tiver de passar no servidor, ambas as sessões de média devem ser estabelecidas com o servidor, e para ambos os lados terá de ser utilizada a média encriptada para cada cliente. 64

67 Figura 3.8: Arquitetura dos componentes do Gateway / Servidor A troca de média entre uma aplicação VoIP normal com um cliente WebRTC terá também de ser bem gerida de forma a que de um lado existam por exemplo streams de média separadas e sem um transporte seguro, e do lado do WebRTC, a média seja junta na mesma stream (i.e. usando BUNDLE) e encriptada usando o mecanismo de DTLS. Toda esta lógica tem de ser implementada, de forma a que este componente tenha mecanismos para conseguir interoperar as diferentes aplicações e protocolos transparentemente Aplicação Web Hoje em dia as aplicações Web não estão limitadas aos browsers, havendo já várias entidades que estão a dar força à ideia da criação de aplicações nativas baseadas em aplicações Web, como é o caso da Mozilla com o Firefox OS ou da Microsoft com o Windows 8. Para facilitar o desenvolvimento de aplicações para várias plataformas, é essencial a criação de uma API em Javascript que permita abstrair as diferenças de implementações de cada um dos browsers ou plataformas e também a lógica da implementação de cada uma das funcionalidades de forma a que seja apenas necessário implementar a camada visual própria de cada plataforma, para cada nova versão de uma aplicação Web. Assim, a implementação do cliente em Javascript, para além de uma arquitetura Model View Controller (MVC), deve também estar dividida em duas partes: A SDK e a User Interface (UI). A SDK deve só por si estar dividida em várias camadas representadas na Figura 3.9 para permitir uma maior modularidade tanto ao nível da comunicação como de uma possível implementação futura. API pública Para a UI deve ser disponibilizada uma API com métodos simples Javascript, que serão usados 65

68 Figura 3.9: Arquitetura da aplicação Web pelos programadores para abstrair a complexidade das funcionalidades. Aqui deve existir uma forma de a UI configurar as camadas abaixo, de forma a que estas funcionem de acordo com o que a plataforma permite e o utilizador pretende. Para o caso em que um cliente esteja interessado apenas na API Javascript, os métodos existentes nesta camada são os únicos que serão documentados e distribuídos em conjunto com todo o código minificado e protegido. Lógica de negócio - SDK Toda a lógica de negócio própria de cada funcionalidade RCS, o estabelecimento de chamadas usando WebRTC entre outras capacidades devem estar definidas nesta camada. Esta deve ser dividida em módulos independentes de forma a que a remoção e adição de funcionalidades seja transparente e dependa apenas da configuração do utilizador ou do programador. Cada um destes módulos deverá disponibilizar os métodos necessários para a interação da API pública com a lógica de negócio. Além da implementação de cada um dos módulos para disponibilizar funcionalidades, esta camada deve conter mais dois elementos na sua arquitetura: Um módulo de configuração e outro de eventos. O módulo de configuração deve estar acessível a cada um dos módulos de implementação das funcionalidades, para que estes possam agir em conformidade com a configuração recebida. As configurações incluídas neste módulo, para além das básicas sobre a plataforma em que estejam a correr, e as informações sobre o utilizador que esteja a utilizar a aplicação, devem também ser geridas todas as configurações próprias de uma aplicação RCS, tal como definido na secção 2.2 da especificação[57]. A UI terá também acesso a esta configuração para que possa agir de forma correta, tal como por exemplo se deve 66

69 ou não mostrar os componentes para uma dada funcionalidade. O outro módulo que deve fazer parte desta camada é um gestor de eventos para permitir a comunicação transparente com a camada da UI. Seguindo o design pattern Observer[58], a forma da aplicação receber eventos tais como novas chamadas, mensagens, ou mudanças de estado de um dado contexto, é através do registo de funções para serem chamadas quando algo acontece. Todos os módulos podem lançar eventos quando algo acontece e deve ser passado para a UI, e quer tenham sido registados observadores para um dado evento, isto é transparente para cada módulo e a alteração é sempre passada para o gestor de eventos. Este por sua vez vai chamar cada função observadora que tiver sido registada para aquele evento em particular, se existir alguma. Desta forma pretende-se dar liberdade à UI para que possa receber os eventos da SDK em diferentes partes da aplicação e que possa registar apenas os eventos desejados. Camada de comunicação Para permitir que a aplicação utilize mais que um protocolo de transporte dependendo do suporte de cada plataforma ou browser, a camada de comunicação deve implementar um mecanismo de pedido-resposta em que cada módulo de cada funcionalidade possa enviar pedidos para o servidor abstraindo-se da comunicação. Independentemente de esta camada estar a utilizar WebSockets ou HTTP, os pedidos recebidos e respostas devolvidas devem ser iguais, por forma a tornar esta melhoria completamente autónoma desta camada. 67

70

71 Capítulo 4 Implementação Após a análise da arquitetura, os componentes propostos foram implementados de forma a obter um ambiente funcional e que permitisse fazer as demonstrações e integrações necessárias para promover o produto da empresa. O desenvolvimento pode-se dividir em duas grandes partes sendo uma delas a aplicação cliente e a outra os componentes do servidor. No entanto, todo o processo começou pela definição dos protocolos que seriam utilizados para unir os dois componentes. Assim, em seguida é apresentado o percurso de todo o desenvolvimento da solução que se inicia com esta análise e com a posterior descrição dos desenvolvimentos nos componentes em particular. 4.1 Comunicação aplicação - servidor A comunicação entre os dois componentes foi feita usando dois protocolos de transporte para que pudessem ser suportados os browsers mais recentes com uma melhor performance (i.e WebSockets) e os browsers mais antigos usando tecnologias mais abrangentes (i.e HTTP). Para a comunicação foi criado um conjunto de comandos e respostas para serem transmitidos entre aplicações e servidor substituindo os protocolos standard WIT API Através do protocolo de transporte selecionado (WebSockets ou HTTP Long Polling), são transportados dados formatados que levam informação sobre o comando standard que deve ser usado e quais os seus parâmetros. Este conjunto de comandos foi definido para simplificar a lógica na aplicação Web, não obrigando assim a que o cliente tenha de implementar na totalidade alguns protocolos necessários, tal como o SIP. Os clientes baseados na tecnologia Flash já eram baseados numa API privada transmitida através de RTMP, mas esta era muito reduzida e limitada, deixando pouca liberdade à aplicação. Exemplo desta limitação residia precisamente nas chamadas, em que a aplicação não tinha forma de informar o servidor sobre qual o Codec que iria usar, dado que estes eram sempre negociados pelo mesmo. Outra limitação na arquitetura anterior estava relacionada com a identidade nos pedidos SIP (valor transportado no header From), onde esta era sempre forçada pelo servidor, não permitindo que a aplicação a definisse por pedido. Várias limitações começaram a surgir devido a esta dependência que o cliente tinha do componente de rede, quando outras funcionalidades começaram a ser implementadas, tais como a chamada em espera ou as chamadas anónimas, em que a aplicação tem de definir uma entidade anónima no pedido SIP. 69

72 A nova API definida foi construída a pensar nos vários protocolos de comunicação que podem vir a ser utilizados, e por isso criaram-se os comandos baseados em objetos JSON, de forma a obter uma API que seja expansível no futuro. Vendo a análise feita na secção 2.1 sobre o protocolo SIP, criaram-se os comandos baseados também numa lógica pedido-resposta, que podem ser enviados e recebidos nos dois sentidos. { method : request, command : CALL_INVITE, params :{ from :{ alias : My alias, uri : sip: @wcas.wit-software.com, gruu : urn:uuid:b92fc700-d18d-b990-ea59-bdd852805a70 }, to :{ uri : tel: }, mediatype : VOICE, mediaoffer : v=0\r\n o= IN IP \r\n s=-\r\n t=0 0\r\n a=group:bundle audio video\r\n m=audio RTP/SAVPF \r\n c=in IP \r\n a=rtcp:49157 IN IP \r\n a=candidate: udp typ host generation 0\r\n a=candidate: udp typ srflx generation 0\r\n a=ice-ufrag:hf6pywllmlig5yb6\r\n a=ice-pwd:hq28bt4ukj5g2+ygziapl25m\r\n a=ice-options:google-ice\r\n a=sendrecv\r\n a=mid:audio\r\n a=rtcp-mux\r\n a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bpodcq8mhujuwup\r\n a=rtpmap:0 PCMU/8000\r\n a=rtpmap:8 PCMA/8000\r\n a=rtpmap:126 telephone-event/8000\r\n }, tid :264 } Listagem 4.1: Exemplo de um objeto JSON para iniciar uma chamada (pedido cliente-servidor) Para isso, à semelhança da especificação JSON-Remote Procedure Call (RPC) (JSON-RPC) 1, foi definido o 1 JSON-RPC é a especificação de um mecanismo leve para utilização em sistemas informáticos, para a execução remota de código. Este mecanismo é agnóstico ao transporte, sendo que os objetos JSON transportam toda a informação necessária para que a aplicação destino saiba quais os métodos a correr com que parâmetros. Os dados enviados resumem-se a um objeto JSON com as três propriedades method, params e id, levando cada uma respetivamente a função a chamar, os parâmetros que devem ser passados para a função e um valor que identifica o pedido para poder ser relacionado com as respostas. - jsonrpc.org/ 70

73 campo method no objeto JSON que define qual a função a chamar no destino e o campo command que define como um dado pedido deve ser traduzido. E adição a estes, o campo params transporta o corpo do pedido através de elementos chave-valor e o tid um valor aleatório que identifica o pedido. No caso do pedido exemplificado na Listagem 4.1, o método chamado no servidor será o request e dentro deste, o pedido será tratado por tradutores que processem os comandos CALL_INVITE com os respetivos parâmetros. Desta forma a aplicação ou o servidor ao receber um pacote consegue distinguir como tratar os seus dados. Tal como foi explicado no secção 2.1, no protocolo SIP cada pedido pode ter mais que uma resposta e estas são todas relacionadas com o respetivo pedido através do valor do header Call-ID. Para simular este comportamento, ou mesmo quando não está a ser usado SIP em que se pretende relacionar o resultado com o respetivo pedido, é utilizado o parâmetro tid que é preenchido com um valor aleatório, cada vez que um pedido é criado, e adicionado novamente em cada resposta. { } type : response tid :264, request : CALL_INVITE, response : WCAS_100_TRYING, params :{ callid : 5f5cbe3a1ae3c40a02afb a3a, to :{ uri : tel: } } Listagem 4.2: Exemplo de um objeto JSON com resposta provisória do servidor Uma resposta para além do campo tid a identificar o pedido a que corresponde, transporta também um campo type com o valor response, para poder ser distinguido dos pedidos recebidos no mesmo canal. Além disso este contém sempre o campo request com o comando do pedido original, para poder ser tratado numa primeira fase por tradutores próprios para o tipo de pedido em questão. Restam os campos params com os parâmetros que compõe o corpo da resposta e o campo response com um código de resposta mapeável para as respostas possíveis no protocolo SIP apresentadas na secção 2.1. Para a média das chamadas os browsers criam um canal novo e enviam os dados através de SRTP, mas para suportar a média através de MSRP, visto os browsers não suportarem este protocolo, foi definida uma forma de transmitir estes pacotes através desta API. Dado que o protocolo MSRP não tem obrigatoriamente respostas relacionadas com um dado pedido, e os dados transmitidos podem ser simplesmente passados num sentido sem nunca haver uma confirmação no sentido contrário, os objetos JSON definidos foram mais simples. Um incentivo para uma API mais leve na parte de média é também a motivação para que esta seja rápida na transmissão de pacotes por exemplo numa transferência de ficheiros. Um pacote MSRP pode ser de um de três tipos, sendo que o principal é o tipo MESSAGE, que é o pacote que transporta os dados. Os outros dois tipos existem em resposta a este quando pedidos pela aplicação emissora dos dados, e podem ser do tipo ACKNOWLEDGEMENT transportando informação sobre o estado da entrega do pacote de dados no ponto de rede seguinte ou do tipo REPORT que informa a aplicação que enviou os dados sobre a sua entrega na aplicação destino. 71

74 À semelhança dos objetos que representam pacotes SIP, os objetos com dados de média têm também um campo method para ser chamado remotamente, sendo que neste caso é a função data, e o comando indica depois que componentes devem processar os dados. { } method : data, command : MESSAGE, params :{ sessionid : EEBC2B3E69AFEDE4D9E67B4C9C262DDF_of1_if1, imsessionid : , transactionid : 2af965a762104bed9061ea07ca51467f, messageid : 1f098efa15a948f2aad1cf9206f437ed, content : RnJvbTogIkFub255bW91cyIgPHNpcDphbm9u ew1vdxnad2nhcy53axqtc29mdhdhcmuuy29t XBvc2luZyI+PHN0YXRlPmFjdGl2ZTwvc3Rhd GU+PC9pc0NvbXBvc2luZz4=, contenttype : message/cpim, chunkstart :1, chunkend :458, chunklength :458, failurereport : no, successreport : no } Listagem 4.3: Exemplo de um objeto JSON com um pacote de média Os parâmetros necessários para a construção de um pacote MSRP são enviados no campo params, variando com o tipo de pacote em questão. Ao contrário dos objetos anteriores, estes não têm o campo tid por não necessitarem de relacionar respostas aos pacotes. Quando uma aplicação pede uma resposta ao enviar um pacote com dados, esta deve tratar do mapeamento dos identificadores de cada pacote para processar as respostas. { } method : data, command : ACKNOWLEDGMENT, params :{ imsessionid : , messageid : 31AC4D766D4FBC5B77287B4CE36D503D, transactionid : 393D13D812DCF230EBD07B4CE36D6C48, status : 200 } Listagem 4.4: Exemplo de um objeto JSON com um pacote com uma resposta de média O pacote mostrado na Listagem 4.3 mostra a transmissão de dados com a informação sobre os bytes que representa, os tipos de respostas que pretende receber, o content-type e os identificadores que vão ajudar a relacionar possíveis respostas e mensagens. Uma resposta do tipo REPORT traz também informação sobre o estado de uma dada parte dos dados, enquanto que uma resposta do tipo ACKNOWLEDGEMENT transporta apenas os identificadores e um campo status com um código de resposta semelhante aos do protocolo SIP. 72

75 4.1.2 WebSockets Para a transmissão dos objetos definidos na API entre o servidor e as aplicações Web, foram utilizados Web- Sockets. Para incluir a tecnologia no contexto da aplicação foi necessária a integração desta num componente do servidor da empresa, e portanto utilizando Java. Os browsers vão ganhando suporte nativo para WebSockets, mas dado que o protocolo serve para uma comunicação cliente-servidor, o suporte para o protocolo tem de ser implementado em outros componentes que não os browsers, para se poder integrar em servidores. Para além do estabelecimento da ligação bidirecional, a implementação do protocolo de comunicação através de WebSockets deveria também permitir alguma abstração tanto no servidor como no cliente. Tarefas como a identificação e junção de pedidos da mesma aplicação já com a informação relevante do cliente, e a possibilidade de obter já um objeto de sessão a partir do qual se possa interagir de forma genérica para a receção e envio de pacotes para uma dada ligação, são mais valias interessantes e necessárias para a implementação do canal. A tecnologia é recente mas já vários projetos estão a utilizar o mecanismo tais são as vantagens que traz às aplicações Web, em termos de funcionalidades em tempo real. Uma biblioteca que atualmente abstrai a complexidade e ajuda na criação de aplicações que utilizem WebSockets é a jwebsocket 2. Esta biblioteca opensource foi utilizada para simplificar a criação dos componentes do servidor, permitindo que através da inclusão desta se obtivesse uma simples API através do qual os pedidos e as sessões dos clientes chegassem ao servidor. Com esta biblioteca problemas como a limitação do acesso a aplicações disponíveis em dados domínios ficam resolvidos. Uma vasta lista de configurações fica acessível para facilmente configurar a forma como o acesso por WebSockets ao servidor deve ser feito. Mas o projeto onde esta biblioteca Java se insere tem também uma pequena biblioteca em Javascript para facilitar a integração com o componente do servidor. Parte deste código foi também utilizado na aplicação Web para simplificar a criação do canal de comunicação. A inclusão da biblioteca Javascript permite que se adicionem funções para serem chamadas na resposta de um dado pedido, e abstrai as diferenças entre browsers nas funcionalidades dos WebSockets HTTP - Long Polling Para ser possível suportar os browsers mais antigos, foi implementada a comunicação baseada em HTTP, utilizando um mecanismo de Long Polling para a transmissão de pedidos iniciados pelo servidor para o cliente. A arquitetura deste componente foi baseada no módulo de WebSockets, no sentido em que os mesmos campos dos objetos JSON são utilizados para o mapeamento de pedidos e respostas. No entanto a lógica do processamento de pedidos, as diferenças entre cada browser e o relacionamento entre cada pedido e as suas respostas foram construídos de raiz, ao contrário do módulo de WebSockets, que é baseado numa biblioteca. Na aplicação Web, na camada de comunicação foram utilizados pedidos assíncronos XMLHttpRequest 3 para suportar a comunicação nos dois sentidos. No Gateway, a implementação foi baseada no Grizzly WebServer 4 por ser um componente leve e que permite a recepção de pedidos HTTP sem um grande overhead associado a cada pedido, por possibilitar a não utilização O componente XMLHttpRequest foi especificado pelo W3C para ser implementado nativamente pelos browsers de forma a que as aplicações Web possam fazer pedidos assíncronos ao servidor. Apesar do nome conter XML por motivos de retrocompatibilidade, este componente suporta o transporte de qualquer tipo de dados textuais através de HTTP ou Hypertext Transfer Protocol Secure (HTTPS)

76 de sessões. Desta forma os pedidos podem ser tratados dentro do contexto de uma sessão apenas quando chegam à aplicação. Inerente ao Long Polling foi implementado o canal de notificações, que é criado a partir de um pedido que o cliente envia para o servidor, e que este guarda sem responder até ter algo para enviar para o cliente. Para cada pedido que tenha de sair da aplicação Web, é criado um novo pedido HTTP com o conteúdo do comando a enviar. Na forma de funcionamento do SIP, cada pedido pode ter várias respostas e isto não é mapeável para um simples pedido-resposta HTTP, dado este protocolo ser baseado numa resposta por pedido. No entanto, dada a ineficiência associada ao mecanismo de Long Polling quando comparada com WebSockets[55], a implementação foi feita na tentativa de utilizar todos os pedidos possíveis para transportar dados relevantes para a aplicação. Um dos pontos onde é possível melhorar o mecanismo é no aproveitamento da resposta de um pedido normal, para transportar dados que seriam enviados pelo canal de notificações, diminuindo assim o número de vezes que o canal tem de ser re-estabelecido. Em SIP a resposta provisória 100 Trying é enviada sempre que o pedido INVITE chega a um ponto na rede capaz de processar SIP. Isto significa que se o cliente apenas recebesse dados do servidor através do canal de notificações, assim que enviasse um pedido INVITE, o canal de notificações seria disparado logo de seguida para enviar a resposta provisória. No caso de envio, após um pedido genérico ser recebido pela camada de comunicação, este é transformado no objeto JSON e enviado através de um pedido HTTP. Quando chega ao servidor, este pedido é guardado durante breves instantes para aguardar por qualquer dado que tenha de ser enviado para o cliente. Assim, desta forma foi criado tanto no cliente como no servidor uma forma abstrata de comunicação, em que sempre que o cliente deseja enviar algo para o servidor cria um novo pedido HTTP. Para receber dados do servidor, a aplicação está preparada para os receber a partir de qualquer uma das respostas, ou de um pedido feito para o envio de pacotes, ou do canal de notificações. Para o servidor, os dados podem ser recebidos através de novos pedidos enviados pelo cliente, mas quando tem alguma informação para entregar, verifica primeiro se existe algum pedido pendente para utilizar, e em caso negativo utiliza o canal de notificações. Uma possibilidade de implementação com um menor número de ligações TCP poderia passar pela utilização de mecanismos de respostas incrementais, em que o servidor não envia uma resposta definitiva durante algum tempo, mas vai escrevendo na ligação criada os dados que tem para enviar para a aplicação. No entanto, este mecanismo de processamento de respostas parciais em pedidos Ajax está ainda a ser definido e apenas as versões mais recentes dos browsers têm suporte para este mecanismo. A título de exemplo, o IE suporta este mecanismo a partir da versão 10, sendo portanto a mesma versão a partir da qual suporta WebSockets. Perdia-se assim a grande vantagem de utilizar HTTP Long Poling, para suportar os browsers mais antigos com o suporte para pedidos HTTP simples. 4.2 Aplicação Web Após a definição das formas de comunicação entre a aplicação Web e o servidor, foi definida a estrutura da aplicação baseada em HTML5 e Javascript de forma a respeitar a arquitetura referida no capítulo anterior. A implementação foi dividida em dois grandes componentes para permitir a reutilização de uma grande parte do código na construção de uma interface para diferentes browsers e dispositivos. 74

77 O primeiro componente implementado foi a SDK que trata da lógica de negócio de cada uma das funcionalidades e da comunicação com o servidor, abstraindo toda a complexidade da nova tecnologia WebRTC e também as diferenças entre cada browser. O segundo componente a ser criado foi a interface gráfica baseada em HTML5 e que foi implementada seguindo um padrão MVC, utilizando a SDK na disponibilização de cada uma das funcionalidades. As primeiras páginas Web eram baseadas em páginas estáticas que eram obtidas do servidor prontas a mostrar, e a navegação era feita através do acesso a um novo link, que traria outra página pronta do servidor. Hoje em dia as aplicações Web seguem outra metodologia de desenvolvimento, carregando a página base em HTML, e utilizando pedidos Ajax para obter os dados a mostrar. As aplicações Web deste tipo têm a lógica da aplicação no cliente, dependendo assim muito mais dos browsers e menos dos servidores. Figura 4.1: Aplicação após registo Esta alteração de paradigmas trouxe a necessidade de se criarem ferramentas tanto para facilitar a implementação de aplicações em Javascript, como para que se consiga obter código modular e facilmente e testável. Uma das maiores preocupações a ter nestas aplicações é a disponibilidade do código fonte, dada a natureza do código Javascript, por não ser compilado. Assim, uma das primeiras preocupações na elaboração da aplicação foi a análise de ferramentas para ofuscar e minimizar o código fonte. Para simplificar a implementação da aplicação, foi utilizada a ferramenta Yeoman 5 que através da instalação 5 Yeoman é um conjunto de ferramentas para ajudar na construção rápida de aplicações Web. Existe por exemplo a possibilidade da disponibilização de um servidor Web muito leve baseado em Noje.js, que permite testes locais e instantâneos, através da execução automática de scripts. O programador tem à sua disponibilidade inúmeros plugins que pode instalar, para depois construir a lista de tarefas a fazer quando se verifica um dado evento, diminuindo assim todo um leque de ações repetitivas associadas ao desenvolvimento Web

78 de alguns plugins, possibilitou que a aplicação fosse construída em diferentes módulos, sendo sempre o ficheiro final produzido pela junção de todos os elementos da aplicação. Durante o desenvolvimento, esta ferramenta permitiu atualizar a página Web automaticamente após ter construído todo o código, sempre que se verificassem alterações num dos ficheiros. Para colocar o código em produção a utilidade deste componente foi ainda mais evidente, na medida em que além de juntar os vários ficheiros de CSS, Javascript e HTML, cumpria tarefas como a remoção de todos os comentários e linhas de logs, a compressão e ofuscação do código, a cópia das imagens e outros recursos para uma mesma pasta e o renomeamento dos ficheiros com valores aleatórios para evitar que os browsers façam cache no próximo acesso SDK Para definir a SDK, começou-se pela separação de cada uma das funcionalidades globais que se pretendia implementar, para se conseguir sintetizar quais os métodos que estariam disponíveis para cada uma delas. Os métodos para algumas das funcionalidades estão apresentadas no Anexo A. O código representa aquilo que fica disponível para a UI poder utilizar, sendo que o código interno da lógica de negócio não fica acessível externamente. O resultado final da SDK é um ficheiro que apenas disponibiliza o construtor para um objecto, que quando chamado com a configuração inicial como parâmetro, retorna uma instância desta com a configuração recebida. Este objecto retornado inclui os vários módulos e os métodos respectivos e permite a interação da UI específica do dispositivo com o servidor, usando a lógica da funcionalidade em questão. A arquitetura apresentada na Figura 3.9 foi respeitada nesta implementação, e por isso para além dos módulos dependentes de cada funcionalidade, são inicializados também a camada de comunicação, o gestor dos eventos e um módulo de configuração. Estes três estão sempre presentes na instância devolvida, pois são globais a todos os outros módulos e estes utilizam-nos no seu interior. A lógica de cada módulo está definida em objetos denominados de Managers, que contém toda a lógica e mapeamentos necessários para cumprir os requisitos de cada funcionalidade. Todos estes têm em comum o método handlerequest(request) que é chamado pela camada de comunicação, quando um pedido é recebido do servidor. Assim, para uma integração com esta camada, após a criação da instância de cada Manager, estes são registados na camada de comunicação através do método registerrequesthandler(), que guardará o objecto como um componente interessado em receber os pedidos que chegam do servidor. Esta forma de implementar o tratamento de pedidos através de uma distribuição sincronizada das chamadas a funções foi criada com base no design pattern Reactor[59]. Desta forma é possível que se adicionem e se removam funcionalidades retirando apenas o ficheiro respectivo à mesma, sem que seja necessário alterar o código da SDK. Isto é possível devido à automatização da construção do ficheiro final através da ferramenta Yeoman, que permite que toda a aplicação seja construída em vários ficheiros Javascript em diferentes pastas para uma melhor organização do projeto. No Anexo A é possível ver nos comentários que o código é proveniente de vários ficheiros diferentes (e.g. call.js, session.js,...). Na Listagem 4.5 é possível ver um exemplo de como se utiliza a SDK para iniciar uma sessão SIP num dado servidor, com os métodos que ficam disponíveis externamente. Como parâmetro para o construtor é passado um objeto com informações sobre o servidor destino, e após esta inicialização, é chamado o método connect() seguido pelo registo no servidor com as credenciais do utilizador. 76

79 Os métodos são chamados com recurso à biblioteca Q 6 que permite uma inversão do controlo através da chamada assíncrona de código para os casos de sucesso ou falha da função chamada. Esta biblioteca permite uma apresentação mais limpa do código, com a garantia que o resultado será chamado assincronamente, sem a necessidade de mapeamento de funções para cada pedido. Cada método da API tornado público devolve para a UI uma promise para ser usada para tratar os casos de resposta do pedido feito. Desta forma é também garantido que a aplicação não é bloqueada pela espera síncrona do resultado de um dado pedido, e que o código da UI é sempre executado a partir do código da biblioteca, não permitindo assim que terceiros que utilizem esta SDK possam parar a execução do seu código e verificar o seu percurso até ali, descobrindo assim a estrutura do código. server = { name : WCAS-LAB, serverhost : wcas.wit-software.com, serverport : 8077, proxyserverhost :, proxyserverport :, iceservers : [{ url : stun:stun.ekiga.net:3478 }], serverdomain : wcas.wit-software.com }; var wwc = new WWC(server); wwc.session.connect().then(function () { wwc.session.register(username, password).then( // registered handling ).then( // get addressbook addressbooksvc.getaddressbook ).then( // start processing capabilities capabilitiessvc. processaddressbook(addressbooksvc.addressbook);).then( function (value) { // login complete -> change UI to show logged in view deferred.resolve(); }).fail(function (params) { // login failed -> show error messages in login view deferred.reject(); }); }).fail(function (params) { // failed to connect to server -> show error messages in login view deferred.reject(); }); Listagem 4.5: Exemplo de utilização da SDK na criação de uma sessão No exemplo é possível ver o funcionamento desta biblioteca e a forma como é utilizada para fazer o registo de um dado utilizador, seguido de todas as tarefas que seguem este passo. O carregamento da lista de contactos, o processamento das capacidades de cada utilizador, ou mesmo simples alterações visuais que devem acontecer quando o registo é feito, são exemplos das ações que se pretende que a aplicação faça, e que com as chamadas consecutivas do método then() podem ser encadeadas com a certeza de que serão chamadas por ordem e cada uma numa chamada assíncrona. O método fail() é usado para definir a função que deve ser chamada no caso do resultado ser uma resposta negativa, uma excepção ou algum dos then() falhar

80 Para receber os pedidos recebidos do servidor, novas mensagens, ou novos eventos que aconteçam na SDK, a API Pública disponibiliza os métodos bind(name, listener) e unbindall(name) para gerir a subscrição de eventos. A camada da interface gráfica deve registar os eventos através da primeira função passando como parâmetros o nome do evento que deseja seguir e a função que deve ser chamada quando este acontecer. Os eventos são lançados pelo EventManager se tiver sido adicionado algum objeto interessado nos mesmos, e os métodos são sempre chamados assincronamente para que não se consiga seguir a execução do código até ao código interno da SDK. Como está representado na Figura 3.9, a camada de comunicação foi criada com dois módulos distintos e independentes para funcionarem usando diferentes protocolos permitindo o funcionamento numa maior gama de browsers. Esta camada ao ser inicializada verifica se são suportados WebSockets, e em caso positivo carrega o modo de comunicação através desta tecnologia. Caso contrário, é carregado um módulo de comunicação através de pedidos HTTP, sendo que esta alteração é transparente para a camada da lógica de negócio. Os pedidos que precisam de ser enviados ou recebidos do servidor são trocados entre a SDK e a camada de comunicação através de objetos genéricos, para que qualquer que seja o módulo carregado para tratar do protocolo de trasporte, o pedido sejam enviado no mesmo formato JSON para o servidor Interface gráfica - UI A UI para a aplicação de demonstrações foi criada utilizando HTML5 e JavaScript, tendo como objectivo a utilização de cada uma das funcionalidades implementadas na SDK, tais como as chamadas, a descoberta de capacidades de outros utilizadores ou mesmo a troca de mensagens instantâneas. Para produzir aplicações Web mais interativas e dinâmicas são normalmente usadas frameworks JavaScript que facilitem a criação de componentes mais ricos com um menor esforço. Uma das limitações que sempre acompanhou a linguagem HTML foi a necessidade de alterar os elementos HTML que compõe a página para ver alterações simples. A simples inclusão de uma variável dentro de um destes elementos não faz com que o seu valor seja sempre atualizado na página que está a ser vista. O mesmo acontece no sentido contrário, em que não se consegue definir uma variável num dado elemento HTML editável de forma a que quando o utilizador altere (e.g. escrevendo numa caixa de texto) o campo, o valor da variável tenha automaticamente o valor correto e atualizado. No entanto, existem várias frameworks construídas em JavaScript que adicionam estas capacidades ao HTML5 através da simples inclusão da biblioteca na página. Na construção desta aplicação foi utilizada a biblioteca AngularJS 7 construída pela Google. Esta framework permite a criação de páginas dinâmicas através da extensão dos elementos HTML, permitindo o binding bi-direcional de uma dada variável com um dado componente visual. Um exemplo da grande utilidade desta biblioteca é visível na utilização de listas. Exemplo disso nesta aplicação são a lista de contactos ou mesmo as mensagens de uma determinada conversa, em que através do binding com um vector de contactos ou mensagens respetivamente, a vista é atualizada automaticamente mostrando os detalhes de cada um dos elementos, sempre que a lista seja alterada. Também a criação de novos elementos HTML potencia a criação de elementos ajudam a que menos código seja repetido. Esta capacidade deve-se à possibilidade de criação de diretivas, que permitem também a fácil

81 Figura 4.2: Aplicação durante uma sessão de chat integração de funcionalidades como o acesso a ficheiros de propriedades, útil por exemplo na implementação da internacionalização das aplicações. A utilização desta biblioteca força a utilização de uma arquitetura baseada em MVC, forçando a existência de um Controlador por cada uma das Vistas, e dando liberdade para que a lógica da interface seja implementada como o programador quiser, mas dando a possibilidade da criação de serviços que existem enquanto a aplicação estiver a correr. Os controladores apenas existem enquanto as vistas estiverem construídas. Na Figura 4.1 pode-se ver o aspecto final da aplicação construída para as demonstrações, mostrando o utilizador e a sua lista de contactos presentes no servidor. No centro da aplicação é possível o utilizador inserir um número de telefone e após breves momentos ficará com a informação sobre as capacidades que esse dado número tem. Na aplicação é possível identificar visualmente as capacidades e utilizar as que estiverem disponíveis. Figura 4.3: Aplicação durante uma chamada de vídeo Do lado direito e em baixo da aplicação é possível encontrar imagens de algumas redes sociais que vão rodando 79

82 automaticamente, apenas para demonstrar a possibilidade de integração com as mesmas. Na versão atual (Maio/2013), a aplicação é capaz de fazer e receber chamadas de voz e de vídeo (Figura 4.3), obter a lista de contactos a partir do servidor, obter as capacidades de um dado utilizador através do comando SIP OPTIONS e iniciar sessões SIP para trocar mensagens instantâneas segundo a especificação RCS (Figura 4.2). Como explicado na secção 2.4, para fazer chamadas utilizando WebRTC a aplicação deve aceder aos dispositivos de média para obter os objetos MediaStream, tanto para poder reproduzir o conteúdo na própria aplicação como para utilizar na ligação com o outro utilizador. Para isto, a lógica necessária para aceder a estes recursos foi deixada do lado da interface gráfica, e esta deve passar o objeto obtido para dentro da SDK tanto ao iniciar uma nova chamada como ao aceitar uma chamada que esteja a ser recebida. No Anexo B é mostrado um exemplo do código necessário para iniciar uma chamada utilizando a SDK, mostrando a obtenção do acesso aos dispositivos de média (getusermedia) e a utilização da SDK com a passagem da stream obtida. É também exemplificada a forma como uma aplicação deve registar um dado tipo de eventos, neste caso para receber informações sobre alterações de estado em chamadas. 4.3 Servidor - Gateway Como mostra a arquitetura apresentada na Figura 3.8, a solução implementada foi baseada em dois componentes separados para tratarem respectivamente da sinalização e da média WebRTC nas chamadas. Os elementos implementados foram criados de forma a conseguirem integrar o servidor da empresa nos dois modos de funcionamento: o modo de servidor standalone e o modo de Gateway responsável por transformar os clientes Web em clientes SIP standard. A implementação dos componentes de tradução da sinalização e de processamento de média WebRTC é descrita em seguida Tradução de sinalização Após chegar ao servidor através de um dos meios implementados descritos na secção 4.1, os objetos JSON são transformados em comandos genéricos que representam qual a ação que a aplicação pretende executar no servidor. Estes comandos genéricos são os mesmos que são criados quando um cliente SIP se liga ao servidor a correr em modo standalone e por isso, uma camada de tradução para estes comandos vem permitir que os clientes Web consigam ter as mesmas capacidades que um cliente SIP standard sem a necessidade de suportar o protocolo, tornando todo o processo mais simples e leve. O módulo de tradução da sinalização foi implementado de forma a permitir que independentemente do protocolo de transporte utilizado, o comando final seja facilmente construído, usando para isso os campos dos objetos JSON para escolher os tradutores a usar. Dependendo do modo em que o servidor esteja a correr, o comando interno resultante de um objeto JSON enviado pelo cliente Web é processado por diferentes componentes. No caso de estar num modo standalone, o pedido chega ao centro do processamento no próprio servidor, que está a controlar as sessões de todos os utilizadores registados, bem como as capacidades suportadas de cada um. Desta forma o servidor cria as respostas e/ou comandos genéricos e envia novamente para as camadas de tradução, independentemente do tipo de protocolo que o cliente esteja a usar. Para os clientes SIP, os pedidos são enviados usando os 80

83 Figura 4.4: Esquema da tradução da WIT API no servidor da empresa componentes já existentes. Para clientes Web, é utilizada a camada de tradução implementada no contexto desta dissertação, como mostra a Figura 4.4. No caso em que o cliente tenha de integrar com outros serviços através dos protocolos standard, o servidor estará a funcionar num modo de Gateway. Para estas integrações o funcionamento e a utilidade do componente de tradução da sinalização são mantidos intactos, produzindo estes os mesmos comandos genéricos. No entanto, esses comandos não são entregues à lógica final de um típico servidor, mas sim à lógica de um cliente SIP implementada no Gateway. Para o processamento e criação de pedidos SIP no esquema apresentado na Figura 4.5 foi utilizada a biblioteca jain-sip 8, que implementa uma stack SIP para ser utilizada na construção tanto de servidores como de clientes. A utilização desta biblioteca na criação de clientes tem a grande vantagem de na mesma instância se conseguir iniciar várias sessões para diferentes utilizadores, com diferentes configurações. Toda a lógica de criação de cada pedido e resposta SIP bem como o processamento destas foi implementado na lógica central do Gateway, dado que a biblioteca usada fornece as classes que ajudam a criar os pedidos, e abstraem o seu envio e processamento. Figura 4.5: Esquema da tradução da WIT API para protocolos standard em VoIP Transformação de média WebRTC Para processar a média produzida pelos browsers com suporte para WebRTC, permitindo assim que as aplicaçõ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

84 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 implementaçã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 os candidates, 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, o browser precisa de consultar um servidor STUN, que irá responder com estas informações. Ao contrário de um servidor com capacidades TURN que tem de fazer de proxy 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 implementação foi feita utilizando a biblioteca ice4j 9 passando assim o servidor a receber pedidos dos browsers 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 biblioteca jain-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

85 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 biblioteca efflux 10, 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 melhorias 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 biblioteca ice4j novamente, dado que a verificação de conectividade definida pelo protocolo é baseada em pedidos STUN autenticados. Após a descoberta do canal onde o browser 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 componentes inicializados com as chaves de encriptação negociadas foram construídos com recurso à biblioteca libjitsi 11. 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

86

87 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 (MWC 1 ), de 25 a 28 de Fevereiro de 2013 em Barcelona, Espanha. Além de outras novidades 2, a WIT mostrou a nova versão de um cliente Web todo baseado em Javascript e HTML5 com suporte para chamadas utilizando WebRTC 3. Esta versão do cliente foi demonstrada já com suporte para a troca de capacidades suportadas e chat respeitando 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 modo standalone (como apresentado na figura da secção 3.2.2), onde os outros clientes da empresa també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 no stand 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 para browsers de dispositivos 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 nenhum browser 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

88 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 dois browsers 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 dois browsers. 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 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 da Amazon 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, no Global WebRTC Ecosystem Event 5. 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. 5.2 Testes e resultados Após a finalização dos desenvolvimentos foram efetuados vários testes aos componentes para uma melhor percepção dos seus limites e capacidades. Neste processo obtiveram-se algumas medidas e consequentemente algumas conclusões que são em seguida apresentadas. Para além de testes funcionais na aplicação Web construída para as demonstrações, foram realizados testes unitários na biblioteca Javascript para validar cada uma das funcionalidades implementadas. Foram criados testes simples para verificar tanto a lógica de algumas funções locais com alguma complexidade (e.g. codificador/descodificador de mensagens Common Presence and Instant Messaging (CPIM) 6 ), como as funcionalidades que exigem ligação ao servidor. Para estas últimas foram definidos scripts da utilização que a parte da UI de uma aplicação deve dar à SDK, começando por iniciar a sessão e utilizando em seguida as restantes Formato standard definido no RFC3862 para a criação de mensagens instantâneas 86

89 funcionalidades. Estes testes focaram várias possibilidades de má utilização da biblioteca para verificar a sua resiliência e proteção contra parâmetros errados Sinalização e média MSRP O Gateway desenvolvido é responsável pela tradução da WIT API em protocolos standard tais como o SIP ou o MSRP, e deve ser capaz de o fazer para um número elevado de clientes Web. O comportamento normal de uma aplicação RCS é iniciado com o registo na rede através de um pedido REGISTER SIP, e em seguida são enviados pedidos OPTIONS cada vez que é necessário saber as capacidades de um dado utilizador. Tanto os chats como as chamadas ou mesmo as partilhas de conteúdo são criados através de um pedido INVITE com os respectivos conteúdos a serem transferidos em sessões de MSRP ou SRTP. O Cenário 3 apresentado na secção foi o escolhido para os testes por ser o mais completo, sendo que a parte da tradução da sinalização para comandos genéricos é igual em qualquer um dos cenários, e este tem a vantagem de ainda ter o posterior tratamento desses comandos na interface SIP ou MSRP. O Gateway criado numa situação de produção, estará replicado na rede, onde um balanceador de pedidos irá dividir todos os pedidos pelos diferentes nós. Neste cenário o Gateway não necessita de partilhar as sessões entre os vários nós, dado que o servidor que está a controlar todos os registos é aquele ao qual o Gateway está a ligar os clientes Web. A única exigência é que o balanceador de rede permita que a ligação do mesmo cliente seja sempre feita no mesmo nó. Figura 5.1: Disponibilização do Gateway em produção utilizando WebSockets Para se testar quais os limites do Gateway, foi criada uma aplicação que aproveita o facto de a SDK poder ser independente da interface gráfica, criando assim várias instâncias contidas através das quais se podem fazer as ações de um dado utilizador em diferentes sessões. 87

90 A aplicação criada para efetuar estes testes foi desenhada para ir dando informação sobre o sucesso de cada um dos pedidos, em cada uma das sessões. A interface é composta apenas por um botão através do qual se inicia o teste, com a criação de 10 novas instâncias da SDK, uma lista onde são adicionadas cada uma das sessões e um contador a mostrar o número de sessões ativas. Após iniciada, a cada 5 segundos a aplicação cria 10 novas instâncias em que cada uma é adicionada à lista e cada uma delas vai ter o comportamento pré-definido seguinte: 1. Estabelecer a ligação ao Gateway; 2. Enviar um pedido de registo; 3. Enviar um pedido OPTIONS a cada 2 segundos; 4. Iniciar um chat e enviar mensagens aleatórias a cada 3 segundos por MSRP após o INVITE ser aceite. Caso a sessão seja terminada, um nova é iniciada. O número de mensagens por MSRP que estas ações forçam é extremamente elevado para simular uma situação extrema, pois um utilizador não envia mensagens de 3 em 3 segundos continuamente durante vários minutos, e mesmo que envie, seria pouco provável que todos os utilizadores num dos nós o fizessem. Também os pedidos de OPTIONS são excessivos, pois pode acontecer que a primeira vez que um utilizador se ligue ao servidor a lista seja toda percorrida enviando um pedido a cada 2 segundos, mas a partir daí, para chegar a este número numa utilização normal, seria necessário que o utilizador passasse minutos a selecionar contatos diferentes a cada 2 segundos. Mais uma vez, mesmo que exista um cliente com este comportamento, era necessário que todos os utilizadores num dado nó fizessem o mesmo para chegar ao caso que está a ser testado. Atendendo a isto, efetuaram-se os mesmos testes com uma configuração diferente, alterando o número de segundos entre cada pedido de OPTIONS para 4 segundos e colocando apenas uma de cada 10 sessões a fazer o teste de chat. A cada momento na interface gráfica, e para cada sessão, é possível saber quantos pedidos OPTIONS foram enviados e quantas mensagens foram enviadas com sucesso. O processamento em cada uma das instâncias da SDK não se mostrou problemático até porque todas as respostas eram apenas analisadas como sucedidas ou não, sem haver um processamento próprio dos seus conteúdos. Após a conclusão da aplicação de testes, foram executados testes de onde se tiraram algumas conclusões sobre as capacidades do Gateway. Este estava em execução numa máquina com um processador Intel Core - 64 bits com 8 GB de memória. No entanto a Java Virtual Machine (JVM) foi limitada para usar 4GB de memória, para ser possível ver a utilização com alguma memória mas também analisar o comportamento do servidor quando começa a ocupar toda memória disponível. Com um intervalo de 5 segundos entre cada aumento de 10 novas instâncias, foram assim criadas 120 sessões por minuto, e nesse intervalo de tempo foi-se tirando notas dos valores de memória e de Central Processing Unit (CPU) que o processo estava a utilizar. Estes testes foram realizados usando a comunicação por WebSockets e para se conseguir estabelecer um número grande de ligações, o número máximo de ligações TCP foi aumentado no sistema operativo. Os testes foram executados 5 vezes para cada uma das configurações e os valores médios estão representados nas Figuras 5.2 e

91 Resultados Numa análise rápida de ambos os gráficos apresentados, pode-se verificar que no pior caso, tanto o nível de CPU como a memória utilizada esgotam mais rapidamente, sendo que o limite máximo de sessões simultâneas é quase metade. Para encontrar o limite de sessões, foi utilizado o número de sessões falhadas. Ao longo de todo o processo, sempre que eram enviados 10 pedidos de sessões, estas eram todas estabelecidas, mas quando a memória começava a chegar ao limite estabelecido, algumas sessões falhavam por timeout. Quando isto acontecia por 3 vezes consecutivas, o teste era dado por terminado, e considerava-se o número de sessões estabelecidas como sendo o limite máximo. Figura 5.2: Utilização do CPU em teste de carga Em ambas as configurações se pode verificar que a limitação para o número de sessões foi a memória, sendo que o processador em nenhum dos casos passou os 50%. No entanto verificou-se também que a utilização de CPU aumentou substancialmente quando o limite de memória começou a ser atingido. Este facto é normal em aplicações Java, e deve-se ao facto de ser necessário fazer mais esforço para correr o Garbage collector, na tentativa de conseguir ter memória para prosseguir. Também em ambas as configurações foram tiradas várias medidas nos primeiros momentos para se perceber qual o impacto inicial do teste. Verificou-se que o servidor após ter arrancado e estar pronto para receber pedidos, gasta uma média de 145MB de memória e 0% de CPU. No entanto, notou-se que com as primeiras sessões o aumento da memória é superior ao equivalente em número de sessões após as primeiras. Este facto deve-se ao facto de alguns componentes não serem criados no servidor até que chegue a primeira sessão. Resumindo, na configuração do pior caso conseguiu-se ter 1589 sessões simultâneas com uma utilização de 42% do CPU a consumir 4GB de memória. Com uma configuração normal, com a mesma memória conseguiramse ter ao mesmo tempo 3143 sessões com uma utilização de 27% do CPU. O processamento de WebSockets mostrou acompanhar bem todo o teste, permitindo sempre as ligações até 89

92 Figura 5.3: Níveis de utilização de memória em teste de carga ao Gateway. A biblioteca foi configurada para utilizar Java New Input/Output (NIO) 7 como forma de processar os pedidos, mostrando atingir limites mais altos que usando os Sokets primitivos TCP, neste tipo de utilização da rede 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 da stream 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 2 browsers, 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 de input/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 uma thread responsável por processar os dados recebidos. Com o NIO, é possível criar uma pool de threads para tratar de todos os pedidos, independentemente da ligação da qual chegam. 90

93 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 protocolos 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 dos browsers, através da ferramenta webrtc-internals 8, que fornece estatísticas sobre as chamadas a decorrer no Google Chrome. As análises foram realizadas usando diferentes valores para a transmissão de streams 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, o jitter 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 instanciados no browser. Está acessível nas versões mais recentes em chrome://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 um jitter buffer para ordenar os pacotes à sua chegada para serem reproduzidos pela ordem correta, nos tempos devidos. 91