DECLARAO

Nome: Andr Manuel Rodrigues da Silva

Endereo Electrnico: pg17619 alunos.uminho.pt

N do Bilhete de Identidade: 13001004

Ttulo da Dissertao: Novas Arquiteturas Web para aplicaes VoIP

Orientadores:

Professor Antnio Duarte Costa

Professora Maria Joo Nicolau

Ano de concluso: 2013

Designao do Mestrado: Mestrado em Engenharia Informtica

DE ACORDO COM A LEGISLAO EM VIGOR, NO PERMITIDA A REPRODUO DE QUALQUER PARTE

DESTA TESE.

Universidade do Minho, 2013/06/27

Assinatura:.

Agradecimentos

Aos meus pais acima de tudo, pelo apoio em todos os momentos, mas mais que isso, por todo o esforo e apoioincondicional que permitiu que hoje eu consiga viver a fazer aquilo que gosto.

s mulheres da minha vida Elsa, Teresa e Catarina pelo apoio e pacincia de sempre e para sempre.

Ana, minha mais que tudo, pela motivao, amor, amizade, pacincia e compreenso durante este projeto.

Aos orientadores desta dissertao Professor Antnio Duarte Costa e Professora Maria Joo Nicolau por toda adisponibilidade e ateno dispensadas.

WIT-Software por me dar estas oportunidades de investigao que me fazem crescer.

Aos amigos...

A todos a minha gratido.

iii

Resumo

Com o aparecimento de dispositivos de udio e vdeo a preos baixos, da sua incluso em qualquer computa-dor, e com o aumento da velocidade das ligaes Internet, surgiu o interesse em criar sistemas capazes defazer chamadas atravs desta rede (Voice over IP (VoIP)).

Motivada pela migrao das aplicaes do desktop para o browser, a Google decidiu criar uma nova tecnologiapara permitir aos browsers o acesso nativo a cmaras e microfones, bem como a capacidade de comunicaodireta de udio e vdeo entre browsers. Esta tecnologia designa-se por Web Real Time Communication (WebRTC)e tem como principal objetivo permitir que todo um leque de aplicaes, nomeadamente aplicaes VoIP possamtambm ser migradas para pginas Web sem a necessidade de utilizar plugins externos, que podem no sercompatveis com os diferentes browsers e sistemas operativos.

A WIT-Software S.A. (WIT), empresa especialista em aplicaes mveis e em solues que convergem vdeo,udio, servios de mensagens e de transferncias de contedos, disponibiliza verses destas solues para PC,Android, iPhone, iPad, Symbian e Web. Esta ltima foi criada usando a framework Flex e recorrendo ao pluginAdobe Flash.

Com o aparecimento de tecnologias emergentes como o WebRTC e o HyperText Markup Language 5 (HTML5),surgiu um novo desafio para a definio de uma nova arquitetura para os produtos VoIP web-based, incluindo acriao de um cliente que cumpra as normas Rich Communications Services (RCS). No contexto deste projetofoi criada uma aplicao Web que dispensa a instalao de qualquer plugin adicional, com capacidade de fazere receber chamadas de udio e vdeo baseadas em WebRTC, e com algumas funcionalidades RCS. A aplicaofinal foi construda numa arquitetura escalvel e future-proof e capaz de interoperar com as restantes aplicaesda empresa, e mesmo com outros sistemas standard VoIP. O sistema construdo foi demonstrado em vrioseventos por todo o mundo.

Abstract

The appearance of cheap audio and video devices and the fact that they are already included in almost allcomputers, added to the availability of higher speed Internet connections, have increased the interest in thecreation 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 WebRTCand its main purpose is to allow that a whole new segment of applications, namely VoIP applications, can alsobe migrated to Web pages without the use of external plugins, that bring problems when dealing with differentOperative Systems and different browsers.

WIT its a Portuguese company focused in mobile applications and solutions that converge video, audio, instantmessages 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 definitionof a new architecture for web-based VoIP products, including the creation of a client that follows the RCS specifi-cations. A new Web application was developed in the context of this project, that does not need the installation ofany external plugin in the browser, and has the capability to start and receive WebRTC audio and video calls andalso some RCS capabilities. The final application was built under a scalable and future-proof architecture and isable to inter-operate with all the current applications of the company and with other standard systems. The builtsystem was demonstrated in several events all over the world.

ndice

ndice ix

ndice de Imagens xi

ndice de Tabelas xiii

ndice de Listagens xv

Acrnimos xvii

1 Introduo 211.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.1.1 Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.1.2 Empresa e Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.3 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.4 Estrutura da dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Voz sobre IP - Estado atual da tecnologia 272.1 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2 Sesses de mdia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3 VoIP em contexto WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3.1 Tecnologias para construo de Rich Internet Application (RIA)s . . . . . . . . . . 372.4 Tecnologia WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.4.1 Sinalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.4.2 Mdia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.5 Projetos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.5.1 Produtos Concorrentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.6 Discusso e Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Requisitos e Arquitectura da soluo 513.1 Requisitos de aplicaes RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Requisitos dos cenrios de integrao . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.1 Cenrio 1: Servidor standalone com clientes Web . . . . . . . . . . . . . . . . . 533.2.2 Cenrio 2: Servidor standalone com vrios clientes . . . . . . . . . . . . . . . . 533.2.3 Cenrio 3: Clientes Web interligados com a Public Switched Telephone Network (PSTN) 54

ix

3.3 Sinalizao - possveis solues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.3.1 RCS Representational State Transfer (REST) Application Programming Interface (API) 543.3.2 SIP atravs de WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.3 API privada atravs de WebSockets ou Hypertext Transfer Protocol (HTTP) . . . . . . 58

3.4 Mdia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.5 Discusso da soluo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.6 Arquitetura dos componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.6.2 Aplicao Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Implementao 694.1 Comunicao aplicao - servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.1 WIT API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.1.2 WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.1.3 HTTP - Long Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2 Aplicao Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.2.1 Software Development Kit (SDK) . . . . . . . . . . . . . . . . . . . . . . . . . 764.2.2 Interface grfica - User Interface (UI) . . . . . . . . . . . . . . . . . . . . . . . 78

4.3 Servidor - Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3.1 Traduo de sinalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3.2 Transformao de mdia WebRTC . . . . . . . . . . . . . . . . . . . . . . . . 81

5 Testes e Integraes 855.1 Integraes e demonstraes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2 Testes e resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.2.1 Sinalizao e mdia Message Session Relay Protocol (MSRP) . . . . . . . . . . . . 875.2.2 Mdia VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.3 Testes futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6 Concluso 956.1 Sntese do trabalho realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.1.1 Processo e decises tomadas . . . . . . . . . . . . . . . . . . . . . . . . . . 966.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.3 Notas finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Bibliografia 101

A API Javascript 105

B Cdigo necessrio para fazer chamadas 109

x

ndice de Imagens

1.1 Viso do objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1 Esquema do estabelecimento de uma sesso SIP . . . . . . . . . . . . . . . . . . . . . 312.2 Arquitetura dos Websockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.3 Esquema da arquitetura WebRTC a definir nos browsers . . . . . . . . . . . . . . . . . . 402.4 Esquema do enquadramento do WebRTC na rede . . . . . . . . . . . . . . . . . . . . . 42

3.1 Clientes web standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2 Clientes standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.3 Clientes web numa rede operador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4 Esquema do gateway de transformao necessrio para a RCS REST API . . . . . . . . . . 553.5 Esquema da utilizao de SIP atravs de WebSockets . . . . . . . . . . . . . . . . . . . 563.6 Esquema do Gateway de traduo de uma API privada . . . . . . . . . . . . . . . . . . . 583.7 Solues a criar para cumprir os cenrios requeridos . . . . . . . . . . . . . . . . . . . 613.8 Arquitetura dos componentes do Gateway / Servidor . . . . . . . . . . . . . . . . . . . . 653.9 Arquitetura da aplicao Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.1 Aplicao aps registo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.2 Aplicao durante uma sesso de chat . . . . . . . . . . . . . . . . . . . . . . . . . . 794.3 Aplicao durante uma chamada de vdeo . . . . . . . . . . . . . . . . . . . . . . . . . 794.4 Esquema da traduo da WIT API no servidor da empresa . . . . . . . . . . . . . . . . . 814.5 Esquema da traduo da WIT API para protocolos standard em VoIP . . . . . . . . . . . . 814.6 Esquema da traduo de mdia WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.1 Disponibilizao do Gateway em produo utilizando WebSockets . . . . . . . . . . . . . . 875.2 Utilizao do Central Processing Unit (CPU) em teste de carga . . . . . . . . . . . . . . . 895.3 Nveis de utilizao de memria em teste de carga . . . . . . . . . . . . . . . . . . . . . 905.4 Cenrios usados para testar a qualidade da re transmisso de mdia . . . . . . . . . . . . 915.5 udio transmitido de ponto-a-ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.6 udio transmitido atravs do servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.7 Vdeo transmitido de ponto-a-ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.8 Vdeo transmitido atravs do servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

xi

ndice de Tabelas

2.1 Utilizao de cada tecnologia em pginas Web . . . . . . . . . . . . . . . . . . . . . . . 382.2 Tabela comparativa de algumas solues atuais . . . . . . . . . . . . . . . . . . . . . . 49

3.1 Comparao das solues para a sinalizao . . . . . . . . . . . . . . . . . . . . . . . 603.2 Anlise da integrabilidade da mdia em cada cenrio . . . . . . . . . . . . . . . . . . . 62

xiii

ndice de Listagens

2.1 Exemplo de um pedido SIP REGISTER e respectiva resposta [1] . . . . . . . . . . . . . . . 292.2 Exemplo de um pedido SIP com o Session Description Protocol (SDP) para negociar uma

chamada de udio [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3 Esquema do funcionamento das notificaes . . . . . . . . . . . . . . . . . . . . . . . 332.4 Exemplo de uma mensagem instantnea enviada com o comando MESSAGE [2] . . . . . . 342.5 Exemplo da negociao de uma sesso MSRP[3] . . . . . . . . . . . . . . . . . . . . . 352.6 Exemplo de um SDP gerado pelo Google Chrome . . . . . . . . . . . . . . . . . . . . . 44

4.1 Exemplo de um objeto JavaScript Object Notation (JSON) para iniciar uma chamada (pedidocliente-servidor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Exemplo de um objeto JSON com resposta provisria do servidor . . . . . . . . . . . . . . 714.3 Exemplo de um objeto JSON com um pacote de mdia . . . . . . . . . . . . . . . . . . . 724.4 Exemplo de um objeto JSON com um pacote com uma resposta de mdia . . . . . . . . . 724.5 Exemplo de utilizao da SDK na criao de uma sesso . . . . . . . . . . . . . . . . . . 77

xv

Acrnimos

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

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

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

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

Captulo 1

Introduo

Nos ltimos anos tem-se verificado uma crescente migrao das aplicaes nativas de Desktop para aplicaesWeb. Tambm a comunicao em tempo real tem sofrido uma grande evoluo com o recurso s chamadasVoice over IP (VoIP), existindo j vrias aplicaes integradas nas redes sociais que permitem chamadas de udioe vdeo gratuitas, tanto a partir da Web como de aplicaes para dispositivos mveis.

Acompanhando esta tendncia, e com o aparecimento de novas tecnologias emergentes, surge a necessidadede definir novas arquiteturas para aplicaes Web. Este projeto faz uma anlise sobre estas novas ferramentase mostra como estas podem ser utilizadas na construo de novas aplicaes Web capazes de fazer chamadaspara outras aplicaes VoIP genricas ou mesmo para telefones fixos ou mveis.

1.1 Motivao

Hoje em dia, para um browser poder efetuar chamadas necessita de recorrer s capacidades de alguns pluginsexternos. Um dos mais utilizados o Adobe Flash que permite o acesso a cmaras e microfones do dispositivo,e disponibiliza facilmente a criao de streams atravs das quais se pode transmitir udio e vdeo. Este plugin,apesar de estar presente em grande parte dos dispositivos, j foi alvo de muitas crticas e criou alguns inimigosao longo do seu desenvolvimento.

o caso da Apple que no d suporte nem inclui este plugin nos seus dispositivos e que causa por isso umaquebra de compatibilidade com um nmero j grande de utilizadores. Em 2010 numa carta aberta1, Steve Jobsexplicou as razes pelas quais achava que o Flash no era a tecnologia ideal para mostrar contedos na Web,baseando os seus argumentos no largo consumo de recursos que o plugin exige, no facto de ser uma plataformafechada em contraste com o HyperText Markup Language 5 (HTML5) que a Apple apoia e por ser construdopara Desktop, no estando preparado para os novos paradigmas de interao atravs de toque.

Uma das limitaes do Adobe Flash a necessidade de se enviar os dados de mdia para um servidor paraque este possa traduzir o protocolo de transporte, no caso de se querer integrar com outros clientes que utilizemos protocolos standard de aplicaes VoIP, forando assim a que seja necessria uma maior infra-estrutura deservidores maior no caso de colocao em produo de um sistema destes.

Vrios standards esto a ser definidos no contexto do HTML5, convergindo para as capacidades que soalcanveis atualmente atravs de plugins. A procura por solues alternativas e normalizadas tem motivado acomunidade cientfica a investigar novas formas de permitir comunicaes em tempo real atravs dos browsers.

1http://www.apple.com/hotnews/thoughts-on-flash/

21

http://www.apple.com/hotnews/thoughts-on-flash/

1.1.1 Tecnologia

A Google criou no incio de 2011 uma proposta de especificao de uma tecnologia que dotasse os browsers dasmesmas capacidades de um cliente VoIP, revolucionando assim este sector de negcio. A especificao WebReal Time Communication (WebRTC) criada desde ento envolve 3 grandes objetivos:

1. Permitir que os browsers tenham acesso nativo aos microfones e cmaras dos dispositivos;

2. Dotar os browsers da capacidade de comunicao independente de udio e vdeo de forma segura atravsdo protocolo Secure Real Time Protocol (SRTP);

3. Disponibilizar uma implementao de um canal de dados atravs do qual dois browsers possam trocardados diretamente de forma a permitir a criao de aplicaes de comunicao interativa.

Ao mesmo tempo que a especificao est a ser criada, esta est tambm a ser implementada pelos browsers,sendo que se pode j desde h algum tempo usar e desenvolver aplicaes com esta tecnologia utilizando versesdos browsers para programadores. Para um utilizador comum estas capacidades comeam a ficar acessveis,tendo a Google lanado na verso oficial do Chrome j o primeiro e segundo objetivos implementados numestado funcional, apesar de a especificao ainda no ser final (Maio 2013).

Tambm j implementado pelas verses mais recentes dos browsers e em estado de maturao est o HTML5,que veio permitir entre muitas coisas, a reproduo nativa de udio e de vdeo. Esta nova verso do HyperTextMarkup Language (HTML) vem tentar corrigir as divergncias existentes nas vrias implementaes das versesanteriores, tentando assim criar uma ferramenta muito poderosa para a criao de pginas Web interativas emuito completas, com a possibilidade de manipulao de objetos grficos, som e vdeo.

1.1.2 Empresa e Produto

A WIT-Software S.A. (WIT) uma empresa especialista em aplicaes mveis e em solues que convergemvdeo, udio, servios de mensagens e de transferncia de contedos, disponibilizando verses destas soluespara PC, Android, iPhone, iPad, Symbian e Web.

A aplicao Web foi criada usando a framework Flex e recorrendo ao plugin Adobe Flash, permitindo atualmentefazer chamadas de udio e vdeo e enviar SMS/MMS, bem como todo o leque de funcionalidades referidas naespecificao da Groupe Speciale Mobile Association (GSMA). Em 2011 a WIT foi selecionada mundialmentecomo fornecedora das aplicaes Rich Communications Services (RCS) oficiais e est desenvolver as mesmassegundo as especificaes da GSMA.

Todos os produtos deste ecossistema da WIT comunicam atravs do protocolo Session Initiation Protocol (SIP)que bastante utilizado hoje em dia nas aplicaes VoIP. Para que o cliente Web pudesse tambm comunicarcom clientes SIP, foi necessria a construo de um Gateway que conseguisse traduzir pedidos recebidos docliente Flash por Real Time Messaging Protocol (RTMP) em pacotes SIP e vice-versa.

A WIT est atenta aos desenvolvimentos e atualizaes das tecnologias na rea das comunicaes, e com oaparecimento da tecnologia WebRTC, pretende naturalmente redesenhar a arquitetura do seu produto Web deforma a que tenha os seus clientes VoIP compatveis com as novas tendncias de mercado.

Este projeto enquadra-se neste mbito, sendo do interesse da empresa que seja analisada a tecnologia emer-gente WebRTC e a possibilidade de construo de aplicaes Web com as capacidades das restantes aplicaesda empresa sem o recurso a plugins.

22

As aplicaes RCS tm hoje em dia um crescente interesse comercial e como tal, tambm preocupao daempresa que o resultado da nova arquitetura no comprometa a totalidade da soluo, 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 definio de uma nova arquitetura para um cliente Web que utilize a tecnolo-gia WebRTC. Para isso, foi necessrio cumprir vrios objetivos de investigao e desenvolvimento inicialmentepropostos, que so descritos em seguida.

Figura 1.1: Viso do objetivo geral

Analisar o estado atual dos desenvolvimentos na rea das aplicaes VoIP, incluindo a nova tecnologiaWebRTC;

Estudar o protocolo SIP de forma a poder criar uma arquitetura que interligue um cliente Web com qualquercliente SIP genrico;

Fazer um levantamento das vrias possibilidades de transporte de sinalizao e comparar todas as possi-bilidades encontradas analisando as vantagens e desvantagens da sua utilizao, justificando a decisotomada;

Investigar quais os protocolos para o transporte de mdia e solues para ultrapassar problemas deNetwork Address Translations (NATs).

Conceber uma possvel arquitetura e implementar uma biblioteca Javascript que utilize a tecnologiaWebRTC, de forma a permitir a fcil criao de aplicaes Web com capacidades VoIP;

Preparar a arquitetura para uma futura integrao 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 HTML5para utilizar em demonstraes;

23

Garantir a interoperabilidade entre o sistema obtido e as restantes aplicaes da WIT;

Comparar o resultado obtido com os possveis concorrentes e com as solues atuais;

1.3 Contribuies

Como resultado final deste projeto foram dados vrios passos que permitiram cumprir os objetivos propostos. Aconstruo de vrios componentes para a disponibilizao final de uma aplicao Web deu origem aos seguintescontributos:

Foi construdo um Gateway capaz de processar uma Application Programming Interface (API) genricaatravs de vrios protocolos de transporte, usando um componente de traduo da sinalizao capaz deaceitar clientes Flash, WebSockets ou Hypertext Transfer Protocol (HTTP) Long Polling;

Foi definida uma biblioteca Javascript capaz de abstrair a lgica de estabelecimento de chamadas WebRTC,bem como das funcionalidades RCS;

Foi elaborada uma interface grfica para permitir demonstrar as capacidades implementadas na Gatewaye biblioteca Javascript.

Foram feitas vrias integraes e demonstraes em congressos mundiais (Mobile World Congress (MWC)2013 e ACME INTERCONNECT 2013) e a operadores telefnicos de vrias partes do mundo.

Mostrou-se a capacidade de reutilizao da biblioteca construda com a criao de novas interfaces grfi-cas especficas para um operador.

Foi feita a integrao da Gateway com servios externos para permitir o estabelecimento de chamadasde e para a Public Switched Telephone Network (PSTN).

1.4 Estrutura da dissertao

Este primeiro captulo d a conhecer o contexto da investigao, com uma descrio dos temas em que seinsere, o contexto em que surge e qual a motivao para o fazer. So tambm descritos os objetivos que sepretendia cumprir com este trabalho, e quais as contribuies conseguidas com a sua realizao.

No Captulo 2 apresentado o estado atual das tecnologias inerentes a sistemas VoIP dentro e fora do con-texto Web, mostrando em detalhe as que so mais relevantes para o trabalho a realizar. tambm descrita comdetalhe a tecnologia WebRTC, cada um dos seus componentes e capacidades bem como a integrao que possvel conseguir com a sua utilizao. O captulo termina com a apresentao de vrios projetos em desenvolvi-mento que focam pontos semelhantes aos desta investigao, e apresentada uma anlise dos problemas quesurgem com a tentativa de interoperar a tecnologia WebRTC com o mundo VoIP e mesmo com a rede mundialde telefones(PSTN).

Aps estes passos, no Captulo 3 apresenta-se a discusso dos requisitos e a anlise de cada uma das possveissolues. Aps esta anlise, definida a arquitetura da soluo a implementar, enumerando os componentesnecessrios para o cumprimento dos objetivos propostos.

24

No Captulo 4 descreve-se como foi abordada a implementao dos diferentes componentes do projeto,comeando por explicar como foi realizada a comunicao cliente servidor, e explicando depois quais os passosdados na implementao do servidor e da aplicao Web. Neste captulo so apresentados alguns diagramasexplicativos e tambm imagens com o aspecto final da aplicao.

Aps a descrio da implementao, so apresentadas no Captulo 5 algumas integraes e demonstraesem que o projeto foi utilizado. So tambm descritos os testes realizados ao sistema final, bem como a discussodos resultados, antevendo algumas concluses comparativas com as solues anteriores. Ainda neste Captulo, apresentada uma seco onde futuros testes so descritos, como continuao do trabalho realizado.

O documento termina com a Concluso no Capitulo 6 onde analisado o trabalho desenvolvido e os planospara o futuro. So tambm apresentadas algumas notas finais sobre a tecnologia WebRTC e feita uma com-parao com as tecnologias anteriores, seguido pela bibliografia utilizada na produo deste documento e comoauxlio de todo o projeto.

25

Captulo 2

Voz sobre IP - Estado atual da tecnologia

VoIP a tecnologia que permite estabelecer chamadas telefnicas atravs da Internet ou seja, que possibilita atransmisso de sinais de voz atravs de uma rede de dados. A voz convertida de sinais analgicos em digitais,que so depois transmitidos utilizando a rede Internet Protocol (IP).

Hoje em dia vrias aplicaes VoIP so utilizadas para estabelecer chamadas de udio e vdeo gratuitas atravsda Internet. Aplicaes como o Google Talk, Windows Live Messenger (WLM), Skype entre outras, so utilizadasem massa tanto para trocar mensagens instantneas como para fazer chamadas entre computadores. Cadauma das aplicaes referidas anteriormente utiliza o seu protocolo, sendo que o nico que aberto o utilizadopelo Google Talk. Este utiliza o protocolo eXtensible Messaging and Presence Protocol (XMPP) tanto para a trocade mensagens como para a negociao de chamadas no servio Google Hangout, onde usada a extensoJingle com algumas modificaes para suportar a negociao de chamadas[4]. Tanto o WLM como o Skypetrocam tambm mensagens instantneas e estabelecem chamadas mas utilizando protocolos proprietrios, oque torna bastante difcil ou mesmo impossvel a criao de aplicaes que consigam interagir com estes. Aocontrrio das outras aplicaes, o Skype oferece a possibilidade de estabelecer chamadas para a rede telefnicamundial (PSTN), conseguindo cobrar valores mais baixos que as chamadas dos operadores desta rede.[5]

Para que estas aplicaes tenham um bom desempenho e para que consigam transmitir os dados de voze vdeo com boa qualidade, necessrio que estas utilizem vrios mecanismos para ultrapassar os proble-mas que possam encontrar na rede. Precisam tambm de ter em ateno o estado da rede e de escolhero Compression/Decompression Module (Codec) mais apropriado a cada situao. Estes elementos respon-sveis por codificar e descodificar os sinais analgicos de voz em sinais digitais so cruciais na qualidade daschamadas[6], pois existem vrias implementaes e que obtm melhores ou piores resultados em diferentessituaes[7].

O Skype um exemplo de um cliente que cresceu bastante com as chamadas VoIP e em grande parte devido boa qualidade conseguida atravs do seu sistema, contitudo por vrios componentes que fazem com que aQuality of Experience (QoE) resultante da utilizao da aplicao seja bastante boa. Esses elementos vo desdeos Codecs utilizados (e.g. Silk1, Opus2 3) aos ns de rede espalhados pelo mundo, para garantir que existemsempre pontos de retransmisso prximos de quem est a fazer uma chamada[5, 8].

O mecanismo de VoIP independentemente do protocolo utilizado, divide-se em 2 camadas distintas:

Sinalizao Parte da comunicao que permite efetuar a negociao dos parmetros em que se vai estabeleceruma chamada, e atravs da qual o destinatrio recebe a informao de que o iniciador da chamada est

1https://developer.skype.com/silk2http://www.opus-codec.org/3http://blogs.skype.com/en/2012/09/skype_and_a_new_audio_codec.html

27

https://developer.skype.com/silkhttp://www.opus-codec.org/http://blogs.skype.com/en/2012/09/skype_and_a_new_audio_codec.html

a tentar estabelecer uma chamada. Esta negociao feita usando um protocolo prprio para o efeito.

Mdia Aps o destinatrio ter aceite a chamada, estabelecida a ligao atravs da qual os dados serotrocados. Esta normalmente criada sobre uma ligao User Datagram Protocol (UDP).

Antes de se trocar udio ou vdeo entre dois pontos, vrios protocolos tm de ser usados, tanto para permitirema localizao do dispositivo em questo, como para o transporte e negociao dos parmetros necessrios paraestabelecer a chamada. Alm dos protocolos usados pelas aplicaes prprias de alguns servios (e.g. Skype,Inter-Asterisk eXchange v2 (IAX2)4)[5, 9], existem vrios protocolos que podero ser usados para sinalizao,no entanto os mais usados so o H.323 e o SIP[7, 10]. Ambos comearam a ser criados em 1995 mas aInternational Telecommunication Union (ITU) lanou um primeiro standard do H.323 muito rapidamente em19965. Desde a a ITU tem lanado novas verses do standard sendo que a ltima foi a verso 7 em 20096. AInternet Engineering Task Force (IETF) lanou no mesmo ano um draft sobre o SIP, mas o standard apenas foiaceite em 1999 com o RFC2543[11]. Aps algumas revises, foi relanado o standard em 2002 no RFC3261[1]que usado hoje em dia.

Ao longo dos anos inmeros artigos e discusses foram criadas sobre qual o melhor dos dois protocolos,sendo que ambos servem o mesmo propsito: estabelecer uma comunicao multimdia. Os argumentos somuitas vezes relacionados com os apoiantes de cada uma das comunidades: ITU vs IETF. O H.323 umprotocolo binrio e que permite uma boa integrao com a PSTN. O protocolo SIP representado em AmericanStandard Code for Information Interchange (ASCII), e por isso torna-se mais simples de implementar e de resolverproblemas com uma simples captura de rede. O H.323 o protocolo mais utilizado principalmente para telefonesde conferncia e por ter regras mais rgidas, fornece uma melhor interoperabilidade entre implementaes. Oprotocolo SIP mais utilizado na criao de sistemas VoIP fechados, devido simplicidade da sua construoe facilidade de depurao[12].

2.1 SIP

Tal como o H.323, o protocolo SIP funciona sobre TCP ou UDP mas mais usual encontrar implementaessobre UDP, e por isso foi pensado com alguns mecanismos para tornar a troca de mensagens mais fivel, como o exemplo da incluso de uma forma de confirmao de uma resposta final no estabelecimento de uma sesso(mtodo ACK).

Apesar do protocolo SIP permitir que duas aplicaes comuniquem diretamente sem a necessidade de exis-tir um servidor ou proxy, esta no a utilizao mais usual, pois para alm de na maior parte dos casos sernecessrio resolver problemas de Firewall e NAT, normalmente existe um servio associado que necessita de fat-urar ou contar as ligaes. A existncia de um servidor importante por exemplo para que um utilizador se possaregistar nele para que este saiba a sua localizao quando houver um pedido que lhe seja direcionado[12].

O protocolo SIP foi desenvolvido semelhana do protocolo HTTP, sendo por isso constitudo por um verbo quedefine a ao e o recurso a aceder. Em seguida aparecem os vrios headers usados para enviar mais detalhessobre o pedido, tais como a identificao, autenticao ou informaes sobre o contedo. Opcionalmente, cada

4Protocolo VoIP utilizado na comunicao entre os servidores Open source Asterisk5http://www.itu.int/rec/T-REC-H.323-199611-S/en/6http://www.itu.int/rec/T-REC-H.323-200912-I/en

28

http://www.itu.int/rec/T-REC-H.323-199611-S/en/http://www.itu.int/rec/T-REC-H.323-200912-I/en

pedido pode tambm conter um corpo para poder transportar contedos em vrios formatos. As respostas sotambm compostas por um cdigo representativo de um estado, e que facilita a identificao do tipo de respostaentre todas as aplicaes. Estas contm tambm vrios headers com informaes que permitem enriquecer aresposta com informao e podem tambm conter um corpo, para transportar dados em vrios formatos.

REGISTER sip:registrar.biloxi.com SIP/2.0Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7Max-Forwards: 70To: Bob From: Bob ;tag=456248Call-ID: 843817637684230@998sdasdh09CSeq: 1826 REGISTERContact: Expires: 7200Content-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

;received=192.0.2.4To: Bob ;tag=2493k59kdFrom: Bob ;tag=456248Call-ID: 843817637684230@998sdasdh09CSeq: 1826 REGISTERContact: Expires: 7200Content-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 umaresposta final e podero existir vrias respostas provisrias. Estas ltimas podem trazer informao sobre oprogresso do pedido efetuado, at que o destino tenha uma resposta definitiva.

semelhana do HTTP, existem vrios mtodos que podem ser usados em SIP e tambm as respostaspodem ter vrios cdigos de resposta. Alguns destes foram aproveitados do protocolo HTTP e esto distribudospor categorias [13, 1]7:

1xx: Provisional Pedido recebido, a continuar o ser processamento;

2xx: Success A ao pedida foi recebida, percebida e aceite;

3xx: Redirection Mais aes necessitam de ser tomadas para completar o pedido;

4xx: Client Error O pedido contm erros de sintaxe ou no pode ser realizado neste servidor;

5xx: Server Error O servidor falhou ao executar a ao apesar de o pedido estar aparentemente correto;

6xx: Global Failure O pedido no pode ser realizado em nenhum servidor.

7https://tools.ietf.org/html/rfc3261#section-7.2

29

https://tools.ietf.org/html/rfc3261##section-7.2

Inicialmente o protocolo foi criado para estabelecer chamadas e para isso, foram criados osmtodos necessriosao registo e ao estabelecimento de uma sesso [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 headersTo e From que permitem identificar um utilizador inequivocamente no servidor. Estes headers levam comovalores Uniform Resource Identifier (URI)s que podem ser SIP URI ou outro tipo de URIs, como por exemploos TEL URIs definidos no RFC2806[14]. Todas as aplicaes SIP tm de suportar os URIs do schema SIP quetm o formato schema:user@domain em que o schema pode ser sips ou sip, consoante a ligao seja sobreTransport Layer Security (TLS) ou no, respectivamente[15]. O user deve identificar o utilizador inequivocamentee comummente usado o nmero de telefone ou username registado no servio e o domain identifica o serviono qual o utilizador est registado sendo que por vezes, o domain o conjunto de host:port onde o servio encontrado. possvel fazer por exemplo chamadas annimas, enviando para isso o header From com o valorsip:anonymous@anonymous.invalid e enviando a identidade do utilizador que est a efetuar o pedido no headerPrefered-Identity. Desta forma o servidor ir conseguir identificar o originador da chamada mas no ir enviaresta identidade para o destinatrio.

O comando REGISTER enviado para o servidor com a informao do utilizador que se est a registar. Oregisto num servidor sempre um registo temporrio, que vlido durante o nmero de segundos enviado noheader Expires, como mostra o exemplo da Listagem 2.1, em que o utilizador ter um registo no servidor vlidodurante duas horas (7200 segundos). Antes desse tempo terminar, se a aplicao ainda quiser manter o seuregisto, deve enviar novamente um pedido REGISTER, renovando assim por mais outro intervalo de tempo adisponibilidade no servidor.

Numa resposta a um REGISTER o servidor pode devolver uma resposta de sucesso informando assim aaplicao do sucesso do registo ou pode devolver outras respostas de erro que devem ser analisadas caso acaso. A ttulo de exemplo, se for necessrio autenticar o pedido (e.g. mecanismo Digest), o servidor respondecom uma resposta 401 UNAUTHORIZED e adiciona o header com o chalenge necessrio para o envio de umnovo REGISTER autenticado com as credenciais do utilizador em questo.

O protocolo SIP no define o conjunto mnimo de mtodos, formatos ou funcionalidades que um cliente ouservidor SIP deve suportar e por isso, torna-se necessrio um mtodo para dar a conhecer as capacidades decada ponto na rede.

Aps estar autenticada, uma aplicao pode enviar pedidos para outros utilizadores atravs do servidor, masantes de o fazer esta consegue saber se o pedido vai ser entendido enviando um pedido OPTIONS. Estes pedidospodem ser enviados para os servidores ou mesmo para outros clientes, dependendo do header To inserido nopedido. Visto que podem existir vrios proxies na rede atravs dos quais um pedido tenha de passar, possvelcom este mtodo fazer uma espcie de traceroute8 alterando com o header Max-Forwards, e obtendo assim ascapacidades 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, colocandonos headers Allow, Accept, Accept-Encoding, Accept-Language, e Supported os valores que coincidem com a suaimplementao.

8Traceroute um mecanismo utilizado para descobrir o percurso que um pacote faz na rede. criado com recurso ao mecanismode definio do nmero mximo de saltos que um pacote pode dar na rede, e atravs do envio consecutivo de pacotes com estevalor incrementado, consegue-se descobrir qual o ponto na rede a uma dada distncia

30

Figura 2.1: Esquema do estabelecimento de uma sesso SIP

O mtodo INVITE utilizado para iniciar uma sesso e transporta a informao sobre o destinatrio com oqual se deseja estabelecer a mesma e as propriedades da sesso a criar. Ao criar por exemplo uma chamadacom outro utilizador, a aplicao deve enviar um pedido com o mtodo INVITE colocando headers From e Torespetivos e juntar no corpo da mensagem a descrio da chamada que pretende criar, no formato SessionDescription Protocol (SDP) definido em RFC4566[16]. Este formato define para cada stream audio ou video, asportas onde o cliente estar espera de receber dados, os Codecs e as respectivas taxas de transmisso.

O corpo de um INVITE pode transportar muitos outros elementos e at vrios ao mesmo tempo, utilizando paraisso oMIME type multipart definido pelo RFC5621[17]. Para estabelecer uma ligao segura para transfernciados dados SRTP, devem ser partilhadas as chaves necessrias tambm no corpo da mensagem SDP.[18]

Aps a aplicao do cliente destino ter recebido o INVITE para uma chamada, esta envia uma resposta pro-visria com o cdigo 180 RINGING, informando assim o remetente de que o utilizador est a ser alertado paraa chamada. Consoante a resposta do utilizador ou falta dela, uma resposta final ser enviada com a respetivainformao. Caso a resposta seja positiva e o utilizador queira atender a chamada, o cdigo de resposta enviado o 200 OK e no corpo da resposta enviado novamente um SDP desta vez com as informaes relativas scapacidades da aplicao destino, em que IP e portas esta vai estar espera de receber os dados, e que Codecsescolheu para transmitir.

Aps a recepo de uma resposta final, a aplicao que enviou o INVITE envia um comando ACK para informara outra aplicao de que a resposta foi recebida, e a transmisso 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 ocancelar.

31

INVITE sip:bob@biloxi.com SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8To: Bob From: Alice ;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 INVITEMax-Forwards: 70Date: Thu, 21 Feb 2002 13:02:03 GMTContact:

Content-Type: application/sdp

v=0o=alice 53655765 2353687637 IN IP4 pc33.atlanta.coms=Session SDPt=0 0c=IN IP4 pc33.atlanta.comm=audio 3456 RTP/AVP 0 1 3 99a=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 dilogo SIP e para ser terminado, tem de ser enviado um pedidoBYE com o mesmo Call-Id enviado no INVITE inicial. Ambas as partes da ligao podem enviar o BYE, assimque quiserem terminar a sesso estabelecida.

Extenses: PRACK, UPDATE, SUBSCRIBE, NOTIFY, PUBLISH, INFO, MESSAGE, REFER

No RFC3261[1] foi descrito o protocolo SIP como base de um protocolo de comunicao, que pode ser expandidoatravs da manipulao e adio de novos headers e tambm atravs da criao de novos mtodos. Hoje em dia,vrios outros mecanismos so usados para auxiliar as sesses criadas e disponibilizar outras funcionalidadesextra 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 aplicao que enviou a resposta no receber este comando,deve continuar a enviar a resposta repetidamente em intervalos de tempo crescentes. Este mecanismo servepara garantir que a resposta recebida por quem iniciou o dilogo. Alm destas respostas, tambm se comeoua sentir a necessidade de obter uma confirmao da recepo das respostas provisrias. Isto acontece quandoas respostas provisrias transportam mais informao relevante que apenas um simples cdigo de resposta,que apenas d algum feedback ao utilizador.

Um exemplo da utilizao de respostas provisrias para o transporte de alguns dados extra, pode ser vistohoje em dia quando ligamos para algum e a chamada redirecionada para o gravador ou quando algumativa os servios de msica enquanto a chamada no atendida (e.g. Vodafone RingDing, TMN WaitingRing).O que acontece nestes casos, quando uma chamada iniciada a partir de um cliente SIP e depois passadapara a PSTN, enquanto o utilizador no atende ou rejeita a chamada, o servidor do servio em questo enviauma resposta provisria com o cdigo 183 SESSION PROGRESS, em que o contedo inclui o SDP para que aaplicao que enviou o INVITE possa estabelecer uma ligao de um sentido, onde vai receber dados de udiorespetivos mensagem a transmitir.

32

Nestes casos pode ser necessrio que o servidor receba uma confirmao de que pode comear a enviaro udio, e para isso foi criado o comando PRACK, que semelhante ao BYE, por ter tambm uma resposta,mas tem a mesma funo de um ACK. As aplicaes ficam a saber da necessidade de suportar ou no estafuncionalidade atravs da incluso do valor 100rel no header Require, e devem ser enviadas para todas asrespostas com cdigos entre 101 e 199 (o cdigo 100 TRYING est excludo, por ser enviado por ns de rede)[19].

O comando INVITE utilizado para a criao de um dilogo, onde se podem depois trocar dados num ou nosdois sentidos, at que um BYE seja enviado. No entanto, aps uma aplicao ter enviado um pedido destes, estapode querer fazer alteraes ao seu contedo, antes mesmo de receber uma resposta final. Para isto foi criadauma extenso definida no RFC3311[20] que cria o comando UPDATE. Este usado por exemplo para alterar oSDP que foi enviado, de forma a completar com informao mais atual ou mesmo para que duas aplicaesconsigam estabelecer uma ligao para trocar dados antes do pedido ser aceite. Normalmente esta operao deatualizao dos parmetros de uma sesso realizada enviando um novo INVITE, mas apenas pode ser realizadaaps o dilogo estar estabelecido. O UPDATE vem colmatar essa falha.

Outro tipo de necessidade foi a obteno de notificaes quando algo acontecia no servidor e para isso foramcriados 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 possvel e permitido ao utilizador emquesto receber notificaes do recurso pedido o servidor enviar uma resposta final com o cdigo 200 OK, epassar a partir da a enviar comandos NOTIFY com as atualizaes que aconteceram no recurso em questo.Uma subscrio, tal como os comandos REGISTER, so vlidos durante um intervalo de tempo enviado no headerExpires, e devem ser renovados pelo cliente, caso este ainda pretenda receber notificaes. Quando um clienteno desejar receber mais comandos NOTIFY sobre um recurso, deve enviar um novo SUBSCRIBE com o headerExpires com o valor 0, informando assim o servidor de que no deseja estar durante mais tempo a recebernotificaes [21].

Subscriber Notifier|-----SUBSCRIBE---->| Request state subscription|

novo comando seria enviado para o servidor transportando no contedo um documento XML com a informaorespetiva. Os utilizadores que tivessem subscrito a presena desse utilizador (atravs de um pedido SUBSCRIBEcom o header Event com o valor presence), receberiam um comando NOTIFY com o novo documento.

Outra extenso criada foi o comando INFO, que foi tornado standard em 2000 com o RFC2976[24] e quefoi revisto e republicado em 2011, no RFC6086[25]. Este mtodo foi criado para transportar dados referentesa um dilogo j estabelecido, mas que no alteram em nada as propriedades do mesmo, ao contrrio de umre-INVITE ou de um UPDATE, que podem alterar por exemplo os Codecs a serem usados na sesso. Estecomando transporta normalmente contedo com informao para o utilizador. Uma das utilizaes conhecidas o transporte de sinais DTMF, em que o pedido leva informao sobre qual a tecla pressionada e durante quantotempo ocorreu.

Para que se pudesse adicionar suporte para mensagens instantneas entre clientes SIP, foi criada uma novaextenso [2] que define o mtodo MESSAGE. Este foi criado para poder enviar contedos genricos dentro oufora do dilogo de uma sesso iniciada com o comando INVITE. No entanto mais utilizado fora do contexto deuma sesso, facilitando o desenvolvimento de um sistema de mensagens instantneas entre dispositivos. Estemtodo denominado de conversao em PAGE MODE, em contraste com a conversao em SESSION MODE,que definido atravs de uma sesso iniciada com um INVITE em que o SDP deste faz a negociao de umasesso Message Session Relay Protocol (MSRP)[3]. Atravs desta so depois transmitidos dados das mensagensentre os utilizadores.

MESSAGE sip:user2@domain.com SIP/2.0Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkseMax-Forwards: 70From: sip:user1@domain.com;tag=49583To: sip:user2@domain.comCall-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 18

Watson, come here.

Listagem 2.4: Exemplo de uma mensagem instantnea enviada com o comando MESSAGE [2]

Outra extenso criada em 2003, foi a definio do mtodo REFER para permitir que uma aplicao d in-strues a outro cliente ou servidor na rede sobre o que fazer no contexto de um dilogo.[26] Incluindo o headerRefer-To num pedido REFER, um utilizador pode por exemplo iniciar uma transferncia de chamada, informandoa aplicao de uma pessoa com a qual esteja em chamada que deve iniciar uma chamada para a pessoa referida.Essa aplicao deve, com a autorizao do utilizador, enviar um INVITE para o contacto referenciado, iniciandoassim uma nova chamada. Outra utilizao deste mtodo a incluso de mais pessoas numa sesso de con-versao, em que uma aplicao cliente pode enviar um comando REFER para o servidor que esteja a gerir asesso, informando-o do contacto para o qual deve enviar um INVITE para inserir essa pessoa na conversa.

2.2 Sesses de mdia

Quando um utilizador aceita a criao da sesso que foi proposta, ambas as aplicaes envolvidas estabelecemsesses de mdia utilizando para isso os IPs e portas negociados. Estas sesses no tm de ser necessaria-

34

mente para a transmisso de voz ou vdeo, mas este foi o objectivo inicial da criao deste protocolo, e essaa utilizao que mais aplicaes lhe d.

Qualquer que seja o tipo de sesso a criar, a sua negociao feita atravs da incluso de SDP[16] noscomandos usados na fase da sinalizao. Este formato foi definido inicialmente para a negociao de Codecse portas a utilizar numa chamada de voz, mas hoje em dia utilizado por exemplo para a criao de sessesMSRP[3].

INVITE sip:bob@biloxi.example.com SIP/2.0To: From: ;tag=786Call-ID: 3413an89KUContent-Type: application/sdp

c=IN IP4 atlanta.example.comm=message 7654 TCP/MSRP *a=accept-types:text/plaina=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp

SIP/2.0 200 OKTo: ;tag=087jsFrom: ;tag=786Call-ID: 3413an89KUContent-Type: application/sdp

c=IN IP4 biloxi.example.comm=message 12763 TCP/MSRP *a=accept-types:text/plaina=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp

ACK sip:bob@biloxi SIP/2.0To: ;tag=087jsFrom: ;tag=786Call-ID: 3413an89KU

Listagem 2.5: Exemplo da negociao de uma sesso MSRP[3]

O protocolo MSRP baseia-se na troca de pequenos pacotes de dados de qualquer tipo entre aplicaes. normalmente usado para a troca de ficheiros ou mensagens de texto, mas pode ser usado para troca de dadosestruturados proprietrios de uma dada entidade.

Ao contrrio do SIP, o protocolo MSRP no 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 serrespetiva a um ou a vrios pacotes enviados. Existem dois tipos de respostas sendo que os ACKs servem parainformar que um dado pacote chegou ao ponto de rede seguinte, e os REPORTs informam sobre a chegada ouno de um pacote ou de um conjunto de pacotes ao destino.

35

Mdia em chamadas

H vrios protocolos que podem ser usados na implementao de um servio VoIP sendo que para o transportede mdia, o protocolo usado o Real Time Protocol (RTP) que serve para trocar pacotes de udio e vdeo entre osdispositivos. Este um protocolo definido[27] pelo IETF e capaz de criar um transporte de rede ponto-a-pontopara transmitir dados em tempo real, tais como udio e vdeo para estabelecer desde simples chamadas de vozat vdeo-conferncias.

Devido natureza do Transmission Control Protocol (TCP), por este ser um protocolo que garante a entregaordenada de pacotes na rede e que implementa um mecanismo de controlo de congesto, tem um grandeoverhead na ligao, no sendo por isso o protocolo mais indicado para o transporte de dados em tempo real.Ao contrrio deste, o protocolo UDP no garante a entrega dos pacotes nem a sua ordem, o que faz com quepossibilite comunicaes com um menor overhead e por isso, mais indicado para dados em tempo real comoudio ou vdeo em chamadas[7]. Dada esta diferena, o protocolo RTP apesar de poder funcionar sobre os doisprotocolos de comunicao, normalmente utilizado sobre UDP.

O principal objetivo do RTP a implementao de nmeros de sequncia para os pacotes IP para que sepossa formar novamente a informao de udio e vdeo, se estes forem trocadas durante a transmisso. Ospacotes RTP permitem identificar o tipo de informao transportada e as marcas temporais sobre quando devemser reproduzidos os dados. O RTP permite que os dados sejam enviados em multicast, permitindo assim queseja recebido por vrios destinatrios[7].

Nativamente as redes telefnicas convencionais que interligam todos os telefones fixos e mveis do mundo(PSTN), foram desenvolvidas para transportar este tipo de dados, tendo por isso bons resultados neste servio.

Com o surgimento do VoIP, os dados da comunicao so transferidos em redes IP estando assim sujeitoss mesmas condies que todos os outros dados. No entanto, os dados de voz de uma chamada tem de sertransmitidos em tempo real para manter os nveis de Quality of Service (QoS) em valores aceitveis, de forma aque os intervenientes na chamada tenham uma simulao de uma conversa real, tal como se obtm nos serviosde telefonia na rede PSTN.

Visto que o RTP pode ser transmitido sobre protocolos de baixo nvel que permitem o atraso e mesmo aperda de pacotes sem que o emissor tenha o conhecimento, foi criado o protocolo Real Time protocol ControlProtocol (RTCP) para os receptores poderem dar feedback sobre os pacotes que esto a receber.[7, 27] O RTPpode ser usado independentemente do RTCP vindo este adicionar a possibilidade de os utilizadores que estoa receber uma dada stream de udio ou vdeo 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 Codeca ser utilizado. Em caso de chamadas de conferncia negociadas ou no 9 o protocolo RTCP pode transmitirtambm a informao sobre os participantes presentes bem como informao que possa ser mostrada naInterface da aplicao que identifique o utilizador. Quando isto acontece, o RTCP tem mecanismos para ajustaro nmero de pacotes enviados por cada utilizador, mecanismo que foi revisto numa correo ao standard noRFC 3550[27]. Estes mecanismos so especialmente necessrios dada a crescente utilizao de redes semfios, onde a qualidade da rede pode alterar rapidamente.[6]

9Por chamadas no negociadas entenda-se por exemplo casos em que existe uma conferncia pblica em que qualquer utilizador sepode juntar.

36

2.3 VoIP em contexto WEB

Nos ltimos anos tem-se assistido a uma crescente migrao das aplicaes Desktop para a Web, e mesmo como recente aparecimento das aplicaes mveis, tambm neste segmento algumas empresas optam por criaraplicaes Web, o que permite que a mesma aplicao funcione em qualquer dispositivo e em qualquer sistemaoperativo. As aplicaes Web deixaram de ser apenas pginas com contedo esttico e so agora capazes defazer operaes tipicas de aplicaes Desktop e so denominadas de Rich Internet Application (RIA)s. H unsanos a Internet era povoada por pginas estticas e a interao existente era apenas atravs de novos links quecarregavam outra pgina com contedos HTML simples ou alteravam o contedo de uma tabela da pgina. Hojeem dia so construdas pginas com muitas mais capacidades, com contedos carregados em segundo plano(Asynchronous JavaScript + XML (Ajax)) e com muito mais programao na aplicao cliente.[29]

2.3.1 Tecnologias para construo de RIAs

Estas aplicaes podem ser construdas usando Javascript, ou recorrendo a plugins instalados nos browsers.Com o recurso a plugins tais como o Adobe Flex10, Adobe Flash ou OpenLaszlo11 conseguem-se construir apli-caes mais completas por estes correrem o cdigo nativo, com mais capacidades que o Javascript simples.Podem tambm ser instalados plugins no sistema operativo que permitem a utilizao de pginas que interligamcom aplicaes Desktop ou que se tm as mesmas capacidades que estas (Adobe AIR12, JavaFx13)[29, 30].

Para criar aplicaes Web que permitam fazer chamadas VoIP necessrio que as aplicaes possam acedera alguns recursos, que normalmente os browsers no disponibilizam sem o recurso a alguns plugins que fa-cilitem estes acessos. As capacidades mnimas necessrias so o acesso a microfones, cmaras e um meio detransmisso dos dados obtidos destes dispositivos para um servidor ou diretamente para o destinatrio.[31]

Plugins

Adobe Flash uma tecnologia proprietria da Adobe que permite a criao e a visualizao de contedos multi-mdia tais como vdeos, animaes e jogos em pginas Web, sendo que na maioria das vezes so encontradasutilizaes embebidas em pginas Web, e no tanto como aplicao Web completa. bastante utilizado paraaplicaes com necessidades de streaming de multimdia e animaes mais completas.

Para que os browsers possam mostrar contedos criados com esta tecnologia precisam de ter o plugin in-stalado e este adiciona a possibilidade de aceder cmara e microfone do dispositivo, havendo tambm apossibilidade recepo ou envio dos dados capturados atravs de RTMP[32] para um servidor que suporte esteprotocolo [33]. assim possvel criar todo um leque de aplicaes, que suportam desde a gravao de voz/vdeo,at mesmo a chamadas para outra aplicao que suporte o mesmo protocolo.

Atualmente o plugin est na verso 11 e suporta vrios Codecs que so comummente usados em chamadasVoIP. Para codificar voz, so suportados os Codecs G.711 (Pulse Code Modulation A-law (PCMA) e Pulse CodeModulation U-law (PCMU)) e Speex. Para codificao de vdeo so suportados os Codecs H.263 Sorenson Sparke H.264.

10www.adobe.com/products/flex11http://www.openlaszlo.org/12www.adobe.com/products/air13http://www.oracle.com/technetwork/java/javafx/overview/index.html

37

www.adobe.com/products/flexhttp://www.openlaszlo.org/www.adobe.com/products/airhttp://www.oracle.com/technetwork/java/javafx/overview/index.html

Estas propriedades indicam que um plugin bom para interoperabilidade com sistemas de VoIP, visto queexistem alguns servidores (e.g. Wowza Media Server (WMS)14) capazes de fazer a traduo entre os pacotesRTMP e RTP, facilitando o processo.

No entanto, apesar de ser suportado pela maioria dos browsers, o plugin criou alguma inrcia em algunssetores do mercado. A Apple em 2010 declarou que o iPhone e o iPad no teriam suporte para Flash e recen-temente, tambm a Google anunciou que a partir do Android 4.1 Jelly Bean tambm no haveria suporte parao plugin[34]. Estes retrocessos afetam as decises de quem produz software, ou de quem pensa comprar umproduto baseado nesta framework.Silverlight uma tecnologia criada pela Microsoft para competir com o Adobe Flash que permite a criao de

aplicaes RIA. A verso mais recente a 5, e oferece basicamente as mesmas capacidades que o Flash, mascom uma aceitao pblica menor como mostra a Tabela 2.3.1. Tambm atravs da utilizao de servidores narede (e.g. Media Suite15), possvel obter voz e vdeo em vrios Codecs transmitidos sobre RTP.

O Silverlight corre em todos os Sistemas Operativos na maioria dos browsers desktop. No segmento dasaplicaes mveis, o Silverlight funciona em Windows Phone 7 e em no Symbian mais recente. Ainda no hsuporte para Android nem iPhone.

Nenhuma 7.3%JavaScript 92.5%Flash 20.7%Silverlight 0.2%Java 0.2%

Tabela 2.1: Utilizao de cada tecnologia em pginas Web16

Outra hiptese para criar aplicaes RIA usando o JavaFx, que foi criado para fornecer uma camada maisleve do Java para criar interfaces Web que permitam aproveitar todas as capacidades do sistema que umaaplicao Java consegue. Uma das vantagens de usar esta tecnologia a possibilidade de reusar cdigo deoutras aplicaes Java atravs da instalao do plugin. Atualmente na verso 2.2, este plugin tem a capacidadede aceder aos dispositivos multimdia usando algumas bibliotecas externas, e suporta alguns Codecs tais comoo H.264 e o MP3. No entanto, outros podem ser adicionados com recurso a bibliotecas externas.

HTML5 e WebSockets

A ltima verso standardizada do HTML a verso 4.1 que foi definida em 1999. Desde a a Internet mudoubastante, e como tal uma unio entre o World Wide Web Consortium (W3C) e o Web Hypertext Application Tech-nology Working Group (WHATWG) foi criada com o intuito de definir o HTML5. Este est j a ser implementadopelas verses mais recentes dos browsers apesar de ainda estar a ser definido.

Nos principais objetivos inclui-se entre outras coisas, a reproduo nativa de udio e de vdeo, com a adiode novas tags para o efeito. Esta nova verso do HTML vem tentar corrigir as divergncias existentes nas vrias

14http://www.wowza.com15http://www.streamcoders.com/products/msnet.html16http://w3techs.com/technologies/overview/client_side_language/all - Acedido a

27/01/2013

38

http://www.wowza.comhttp://www.streamcoders.com/products/msnet.htmlhttp://w3techs.com/technologies/overview/client_side_language/all

implementaes das verses anteriores, tentando assim criar uma ferramenta muito poderosa para a criaode pginas Web interativas e muito completas, com a possibilidade de manipulao de objetos grficos, som evdeo. Animaes que eram anteriormente apenas possveis de construir recorrendo a plugins, passam agora aser possveis de criar apenas recorrendo ao uso de HTML, usando o Canvas que permite a criao de objetoslivres incluindo em 3 dimenses. Um dos objetivos gerais a reduo da necessidade de plugins para a criaode RIAs.

Tambm includo no pacote de melhorias que o HTML5 traz est a implementao de um novo protocolo detransporte: os WebSockets. O objetivo a criao de um meio de transmisso de dados full-duplex bi-direcionalentre browsers e servidores, para permitir a criao de aplicaes ainda mais interativas e para reduzir o overheadcriado por mecanismos como o Long-pooling17. Alguns browsers tm j este mecanismo implementado, havendotambm j vrios projetos opensource que permitem a criao de um servidor capaz de processar pedidos desteprotocolo.

Figura 2.2: Arquitetura dos Websockets

2.4 Tecnologia WebRTC

No incio de 2011 a Google criou uma proposta de especificao de uma tecnologia que dotasse os browsersdas mesmas capacidades de um cliente VoIP, podendo assim fazer com que todo um novo leque de aplicaespudesse ser migrado para a Web sem a necessidade de instalao de plugins. Nesta proposta alguns objetivosteriam de ser obrigatoriamente implementados para que o resultado pudesse ser inovador e proveitoso para acomunidade. Foram ento definidos trs requisitos gerais daquilo que os browsers deveriam passar a suportarcom a implementao do WebRTC:

1. Permitir que os browsers tenham acesso nativo aos microfones e cmaras dos dispositivos;

2. Dotar os browsers da capacidade de comunicao independente de udio e vdeo de forma segura atravsdo protocolo SRTP;

3. Disponibilizar a implementao de um canal de dados atravs do qual dois browsers possam trocar dadoslivres diretamente de forma a permitir a criao de aplicaes de comunicao interativa.

17Long-pooling um mecanismo de comunicao baseado em pedidos do cliente que ficam pendentes no servidor, at que esta tenhaalgo para enviar para o cliente. Nessa altura o servidor responde ao pedido com o que tiver para enviar. Quando isto acontece ouo pedido expira, o cliente envia um novo pedido.

39

Para se poder definir a especificao como proposta de standard do IETF, foi criada uma equipa de trabalho18

para definir quais os protocolos e standards usar e umamailing-list pblica para que qualquer pessoa interessadapudesse participar na discusso da criao do standard. Foi tambm criado um grupo de trabalho do W3C paradefinir a especificao e APIs do WebRTC. Ainda antes de serem iniciados os documentos, j bastantes pessoastinham aderido discusso, o que mostrava um grande interesse da comunidade nesta especificao.

Figura 2.3: Esquema da arquitetura a definir nos browsers19

Como primeiro passo foi definido com mais pormenor qual o trabalho que estes grupos iriam realizar[35]:

Definir um modelo de comunicao incluindo como ser feita a gesto das sesses;

Definir um modelo de segurana e privacidade bem como os protocolos e mecanismos de segurananecessrios para cumprir os requisitos;

Definir os protocolos e requisitos da API para a soluo funcionar com Firewall e Network Address Trans-lation - Traversal (NAT-T);

Definir que extenses sero utilizadas para tratar dos dados de mdia, incluindo os mecanismos a usarpara adaptao e controlo de congesto de rede;

18http://tools.ietf.org/wg/rtcweb/charters19https://sites.google.com/site/webrtc/reference/architecture

40

http://tools.ietf.org/wg/rtcweb/chartershttps://sites.google.com/site/webrtc/reference/architecture

Definir quais os Codecs e mecanismos de segurana usar, bem como de que forma a aplicao poderaplicar extenses posteriormente e definindo os formatos de mdia obrigatrios para garantir a interoper-abilidade ente os browsers que implementem a especificao;

Definir como sero transferidos os dados de outros tipos que no udio ou vdeo entre os clientes deforma segura;

Fornecer feedback sobre as APIs que vo sendo criadas para o modelo de comunicao e ter em contadurante todo o processo os atuais sistemas de VoIP para facilitar a interoperabilidade.

Ao mesmo tempo que a especificao est a ser criada, est tambm a ser implementada pelos browsers,pelo que se pode j desde h algum tempo usar e desenvolver aplicaes com esta tecnologia utilizando versesno oficiais dos browsers. Nem todos os fabricantes dos principais browsers avanaram com a implementaoda nova especificao. O Chrome e o Opera foram os primeiros a avanar com desenvolvimentos assim queos primeiros drafts foram ganhando forma. O browser Opera que tem ganho terreno no segmento dos Smart-phones, apostou mais nesta verso do browsermas tambm na verso OperaLabs possvel testar algumas dascapacidades WebRTC20. Em seguida o Firefox21 comeou tambm os desenvolvimentos e aquando da escritadeste documento (Janeiro de 2013), os trs browsers j suportavam parte da especificao nas verses oficiaispara os utilizadores.

A Microsoft rejeitou desde o incio a implementao do WebRTC no Internet Explorer (IE)[36], dizendo queseria implementado mais tarde, o que levou a Google a criar o plugin Google Frame22, juntamente com osdesenvolvimentos que iam sendo feitos no Google Chrome. Este plugin quando instalado no IE permite que asaplicaes Web que usam as capacidades do WebRTC tambm funcionem no IE a partir da verso 6. Em Abrilde 2012, baseados nas propostas de emprego nas pginas da Microsoft que pediam pessoas para implementaruma verso do Skype na Web, surgiram rumores de que a Microsoft estaria a pensar criar uma especificaopara o WebRTC para poder criar uma verso Web do produto recentemente adquirido. Em Agosto de 2012,durante estes desenvolvimentos, a Microsoft anunciou a proposta de uma nova especificao (Customizable,Ubiquitous Real Time Communication over the Web (CU-RTC-Web)23) para trazer as mesmas capacidades aosbrowsers que o WebRTC, alegando que a especificao sugerida pela Google era demasiado limitativa e no davamuita liberdade ao programador para gerir a mdia gerada[37].

O WebRTC disponibiliza uma API atravs de Javascript para que se possam construir aplicaes com maiscapacidades. Para cumprir o requisito 1 (Listagem 2.4) foi implementado o elemento GetUserMedia que per-mite pedir acesso ao utilizador para utilizar as cmaras e/ou microfones na aplicao. Aps o utilizador cederpermisso de acesso a aplicao recebe MediaStreams que pode usar para atribuir s tags HTML5 audio ouvideo , podendo assim mostrar na pgina o resultado da captura. A outra hiptese de utilizao das MediaS-

treams a atribuio destas a um PeerConnection (PC), que o segundo elemento criado no WebRTC e quepermite estabelecer a ligao ponto-a-ponto com outros browsers. Assim que exista uma ligao estabelecida, osdados da stream que for atribuda a este elemento so enviados para os outros pontos na rede que estejam nasesso. Quando comeam a chegar dados de outros browsers, a aplicao recebe a informao de que foram

20http://my.opera.com/chooseopera/blog/2012/01/11/try-out-the-all-new-camera-browser21Na verso 18.0 do Firefox foi adicionado suporte parcial para WebRTC - https://www.mozilla.org/en-US/

firefox/18.0/releasenotes/22http://www.google.com/chromeframe23http://html5labs.interopbridges.com/prototypes/cu-rtc-web/cu-rtc-web/info

41

http://my.opera.com/chooseopera/blog/2012/01/11/try-out-the-all-new-camera-browserhttps://www.mozilla.org/en-US/firefox/18.0/releasenotes/https://www.mozilla.org/en-US/firefox/18.0/releasenotes/http://www.google.com/chromeframehttp://html5labs.interopbridges.com/prototypes/cu-rtc-web/cu-rtc-web/info

adicionadas mais MediaStreams, e pode ento atribui-las a tags audio ou video para poder reproduzir osdados que chegam.

2.4.1 Sinalizao

Tal como nos protocolos comummente usados em sistemas VoIP atrs mencionados, tambm a camada desinalizao em WebRTC deve transportar os dados necessrios para que as diferentes aplicaes em diferentespontos na rede consigam estabelecer ligaes por onde recebam e enviem os dados de mdia.

Figura 2.4: Esquema do enquadramento do WebRTC na rede[38]

Na especificao do WebRTC no consta a definio de um protocolo de sinalizao a utilizar, ficando essadeciso a cargo de cada implementao. Desta forma pretende-se dar liberdade para que qualquer canal decomunicao e protocolo possam ser utilizados, de forma a ser possvel usar protocolos j existentes, ou mesmoincentivar a criao de novas formas de comunicao. A nica exigncia do WebRTC para estabelecer umachamada que o SDP obtido a partir do PC seja partilhado entre as duas aplicaes, sendo que a partir da osbrowsers tm j a informao necessria para estabelecer a transmisso de mdia[39].

Como se pode ver no esquema mostrado na Figura 2.4, a comunicao da aplicao com os servidores feitapor HTTP ou por Websockets e representa a comunicao dos dados de sinalizao. Esta a sugesto deixadana documentao da especificao[35], no entanto qualquer forma de comunicao que se consiga suportarnum browser pode ser usada.

Para criar uma chamada entre dois browsers usando os componentes WebRTC, a aplicao comea por iniciaruma instncia do PC e por pedir ao utilizador acesso aos dispositivos de captura de mdia (getUserMedia()).Aps o utilizador permitir o acesso, a aplicao atribui a MediaStream recebida ao PC e em seguida obtm desteum SDP com o mtodo createOffer(), enviando-o para o outro browser atravs da camada de sinalizao. Quandoa aplicao no browser do destinatrio recebe o SDP com a oferta, inicia tambm uma instncia do PC e pedeacesso aos dispositivos de mdia e, aps inserir o SDP recebido (setRemoteDescription()) e a MediaStream aque entretanto o utilizador der acesso (addStream()), cria tambm agora uma resposta para poder enviar parao iniciador da chamada com o mtodo createAnswer().[35, 38]

Desta forma a aplicao Web que est no browser destinatrio obtm tambm um SDP que inclui os Codecsj negociados com o SDP recebido. Este SDP depois enviado tambm utilizando o protocolo de sinalizao

42

e assim que recebido pela aplicao que comeou o processo, injetado no browser, completando assim oprocesso de sinalizao.[35, 39]

2.4.2 Mdia

Tal como qualquer aplicao VoIP, um browser para ser capaz de comunicar diretamente com outras aplicaestem de ter mecanismos de NAT-T que permitam que a aplicao seja contactvel a partir de qualquer ponto domundo. Com este objetivo, definiu-se na especificao que os browsers teriam de implementar um mecanismode Interactive Connectivity Establishment (ICE)[40] para estabelecerem as sesses de mdia. Este protocolo foicriado para ajudar que duas aplicaes estabeleam ligaes ponto-a-ponto, mesmo que ambas estejam dentrode uma NAT.

O processo de ICE iniciado atravs do acesso a um servidor de Session Traversal Utilities for NAT (STUN)24

ou Traversal Using Relays around NAT (TURN)25 para a obteno dos candidatos a colocar no SDP a partilhar nasinalizao. Estes candidatos so linhas que definem os vrios conjuntos IP/porta onde o dispositivo em que aaplicao se encontra pode ser contactado, e que a aplicao destino ir percorrer ordenadamente para tentarestabelecer a ligao.[41](Ver linhas a candidate na Listagem 2.6)

Tipicamente, numa aplicao a correr dentro de uma NAT que obtenha os seus candidatos a partir de umservidor TURN, so gerados candidatos com 3 IPs distintos: O IP privado dentro da NAT onde se encontra, oIP pblico e o IP do servidor TURN. Isto permite que a aplicao comece a tentar estabelecer as ligaes porordem, comeando pela rede local e terminando no servidor de TURN, permitindo assim que se duas aplicaesestiverem dentro da mesma rede consigam comunicar sem usar os IPs externos.

Para alm destas tcnicas usadas para facilitar a comunicao dos browsers, tambm foi definido que o proto-colo usado para o transporte de mdia seria o SRTP, de forma a que os dados fossem protegidos e encriptadosponto a ponto. Em relao ao protocolo de gesto e controlo das streams de dados, a especificao define autilizao de RTCP utilizando o perfil SAVPF[42], que acrescenta mais informao sobre os dados recebidos porcada ponto da chamada, possibilitando uma melhor qualidade da mdia.[38] Na Listagem 2.6 pode-se verificara presena das linhas a crypto com chaves para se poder encriptar a stream de dados.

Uma outra funcionalidade acrescentada ao WebRTC tenta minimizar o nmero de portas utilizadas por umaaplicao VoIP, dado que normalmente usada uma porta para cada stream de dados (RTP) e uma paracada stream de controlo RTCP, o que em chamadas com udio e vdeo d um total de 4 portas alocadas. Aespecificao define que os browsers devem juntar os dados de controlo e de mdia numa s stream, ou pelomenos oferecer essa possibilidade s outras aplicaes, segundo o RFC 5761[43]. O RFC 3550[27] define naseco 5.2 que diferentes streams de dados no devem ser unidas numa s devido a vrios problemas. Noentanto, a especificao do WebRTC define que seja usada uma nova extenso (BUNDLE)[44] para que, almde se juntar os dados RTCP com os dados de mdia de cada stream, se junte tambm os dados de udio evdeo para que seja utilizada apenas uma porta durante a comunicao.

24STUN o mecanismo que permite que um dispositivo dentro de uma rede local tenha informao sobre qual o seu IP externo eporta que est a usar. Este mecanismo muito usado em VoIP para permitir por exemplo que a aplicao saiba qual o endereoa registar no servidor SIP.

25Um servidor TURN permite que uma aplicao que esteja dentro de uma rede NAT possa usar o IP do servidor para poder comunicarcom outras aplicaes. Neste caso, o servidor ir fazer relay dos dados para o cliente.

43

Codecs

Uma das partes mais importantes de um sistema VoIP a escolha dos Codecs a usar, pois determinar aqualidade das chamadas e tambm a taxa de interoperabilidade com outras aplicaes e sistemas. Como sepode ver na Listagem 2.6(linhas a rtpmap do pacotem audio), os Codecs de udio escolhidos para os browsersWebRTC suportarem incluem os Codecs mais usados em VoIP (PCMU e PCMA)[12], o Codec opensource Opuse tambm o Internet Speech Audio Codec (iSAC).

v=0\r\no=- 4101753164 3 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\nm=audio 49157 RTP/SAVPF 103 111 0 8 106 126\r\nc=IN IP4 188.82.26.82\r\na=rtcp:49157 IN IP4 188.82.26.82\r\na=candidate:3969702325 1 udp 21139 192.168.1.2 49157 typ host generation 0\r\na=candidate:3969702325 1 udp 16777 88.82.26.82 49157 typ srflx generation 0\r\na=candidate:3969702325 2 udp 21139 192.168.1.2 49157 typ host generation 0\r\na=candidate:3969702325 2 udp 16777 88.82.26.82 49157 typ srflx generation 0\r\na=ice-ufrag:Hf6PYwLLMLIg5yb6\r\na=ice-pwd:hQ28bT4ukJ5g2+YgzIaPL25M\r\na=ice-options:google-ice\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bPODcq8MHUJuWUp\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:111 opus/48000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:126 telephone-event/8000\r\nm=video 49157 RTP/SAVPF 100 101 102\r\nc=IN IP4 188.82.26.82\r\na=rtcp:49157 IN IP4 188.82.26.82\r\na=candidate:3969702325 1 udp 21139 192.168.1.2 49157 typ host generation 0\r\na=candidate:3969702325 1 udp 16777 88.82.26.82 49157 typ srflx generation 0\r\na=candidate:3969702325 2 udp 21139 192.168.1.2 49157 typ host generation 0\r\na=candidate:3969702325 2 udp 16777 88.82.26.82 49157 typ srflx generation 0\r\na=ice-ufrag:Hf6PYwLLMLIg5yb6\r\na=ice-pwd:hQ28bT4ukJ5g2+YgzIaPL25M\r\na=ice-options:google-ice\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bPODcq8MHUJuWUp\r\na=rtpmap:100 VP8/90000\r\na=rtpmap:101 red/90000\r\na=rtpmap:102 ulpfec/90000\r\n

Listagem 2.6: Exemplo de um SDP gerado pelo Google Chrome

44

Tambm o Internet Low Bitrate Codec (iLBC)26 foi includo na lista a suportar que, em conjunto com o iSAC,so dois Codecs comprados pela Google aquando da compra da Global IP Solutions. Desde ento o iLBC foitornado opensource sendo possvel a sua incluso em qualquer aplicao livremente e acredita-se que estes doisCodecs sejam usados pelo Skype[45].

O Opus tambm um Codec de udio opensource e royalty-free baseado no Codec Silk do Skype que permiteobter resultados de boa qualidade.[46]

Como Codec de vdeo a Google escolheu para a implementao nos browsers o VP8, que um projeto daGoogle que integra o WebM. WebM um formato que integra uma stream de audio e uma de vdeo, codificadacom VP8. A qualidade do VP8 equipara-se do H.264, outro Codec bastante usado no mundo das telecomu-nicaes hoje em dia. No entanto ao contrrio deste, o VP8 foi disponibilizado pela Google como opensource eroyalty-free.[47]

2.5 Projetos relacionados

Assim que comearam a surgir os primeiros drafts da especificao, foram criados vrios projetos diferentes quecomearam a testar as primeiras verses do Chrome Canary. Desde o incio que se pde ver bastante movimentoe interesse nos grupos de discusso criados pela Google para o efeito, e a assistiu-se partilha de inmeraspginas Web a tentarem implementar algo funcional, na esperana de obter ajuda. Como qualquer especificaoque est a ser criada, tambm o WebRTC tem neste momento pouca produo cientfica disponvel, por estarainda na fase de criao do standard.

Das imensas amostras de aplicaes criadas, algumas so produtos de empresas conhecidas a tentar inovare outras que tentam desde j entrar no mercado das aplicaes VoIP com um produto muito atual. Mas almde clientes VoIP, outros projetos foram criados para ajudar na criao destas novas aplicaes ou mesmo paraadicionar suporte aos browsers.

Uma das reas onde se criaram projetos foi na sinalizao; A Google criou a API de forma a que qualquerprotocolo de sinalizao pudesse ser usado e nessa perspectiva, e visto que um dos protocolos com que h in-teresse em interoperar o SIP, algumas equipas comearam a traduzir complexas implementaes de camadasSIP opensource para Javascript, para que fosse possvel num cliente Web criar pacotes exatamente iguais aoscriados por clientes SIP j existentes.

A diferena sempre presente nestes pacotes causada por uma limitao das aplicaes Web no poderemutilizar ligaes UDP ou TCP nativamente, que so os protocolos vlidos para transportar SIP. Como a nicaligao semelhante que as aplicaes podem criar utilizando Websockets, uma equipa da Acme-Packet e aVersatica27, empresa criada com este projeto, comearam a criar em Maio de 2012 um draft[48] com o intuitode tornar standard o ws como protocolo vlido para o transporte destes pacotes.

Em seguida so apresentados alguns dos projetos relacionados com estas problemticas:

sip-js28 Neste projeto foi migrado o cdigo Python do projeto 39Peers29 para cdigo Javascript. Este projeto jcumpria alguns dos RFCs base do protocolo SIP e o cdigo est sobre a licena Lesser General PublicLicense (LGPL);

26http://www.webrtc.org/ilbc-freeware27http://www.versatica.com/28http://code.google.com/p/sip-js/29http://39peers.net/

45

http://www.webrtc.org/ilbc-freewarehttp://www.versatica.com/http://code.google.com/p/sip-js/http://39peers.net/

jsSIP30 Biblioteca capaz de simular uma stack SIP em Javascript, e j com suporte para o estado atual daespecificao para servidores acima mencionada. Este projeto implementa tambm uma abstrao dalgica das APIs do WebRTC, permitindo a criao de chamadas de udio e vdeo. O cdigo est sobre alicena MIT License;

sipml531 Cliente WebRTC que suporta chamadas de udio e vdeo usando como protocolo de sinalizao SIPsobre WebSockets. A biblioteca SIP foi criada atravs da traduo do projeto opensource ReSIProcrate32

e o cdigo dos clientes est sobre a licena GPL v3;

Para que estas bibliotecas possam comunicar atravs de SIP, precisam de um ponto na rede capaz de receberestes dados atravs de Websockets e tranform-los em UDP ou TCP. Para isso foram tambm criando projetospara este efeito.

OverSIP33 Servidor criado para servir de Gateway para as aplicaes que criem SIP emWebsockets para outrasaplicaes ou servidores que usem SIP nos protocolos standard. Este projeto tal como o jsSip, foi criadopela empresa Versatica e cdigo est sobre a licena MIT License;

webrtc2sip34 Servidor criado pela empresa Doubango para servir de Gateway para o cliente sipml5 poder co-municar atravs de SIP em Websockets para outras aplicaes ou servidores que usem SIP nos protocolosstandard. O cdigo deste projeto tal como o sipml5, encontra-se na licena GPL v3;

Asterisk O servidor de VoIP opensource implementou o suporte para Websockets e tambm para WebRTC,suportando a partir da verso 11 chamadas para clientes WebRTC baseados em Websockets;

Alm deste projetos orientados para o SIP em browsers, existe tambm o plugin webrtc4all35 criado tambmpela Doubango, para permitir que outros browsers como o IE, o Opera, o Firefox e o Safari tenham capacidadesas WebRTC. Alm disso, este componente adiciona tambm mais Codecs s capacidades do browser, o quepermite que haja uma maior interoperabilidade com outros sistemas.

2.5.1 Produtos Concorrentes

Alm destes projetos que trazem algo de novo tecnologia criada pela Google, existem j vrias empresas a criarclientes baseados em WebRTC e que utilizam arquiteturas distintas. Em seguida apresentada uma lista noextensiva de clientes e alguns detalhes sobre os mesmos. Na Tabela 2.5.1 apresentada uma anlise resumidadas propriedades das aplicaes apresentadas, incluindo a informao sobre se estas incluem funcionalidadesRCS.

30http://www.jssip.net/31http://sipml5.org/32http://www.resiprocate.org/33http://oversip.net/34http://webrtc2sip.org/35http://code.google.com/p/webrtc4all/

46

http://www.jssip.net/http://sipml5.org/http://www.resiprocate.org/http://oversip.net/http://webrtc2sip.org/http://code.google.com/p/webrtc4all/

Bistri

Bistri36 um servio Web que fornece aos seus utilizadores a possibilidade de partilharem um endereo webcomo se fosse o seu nmero de telefone. Quando se acede a esse link o utilizador recebe uma chamada quepode incluir udio e vdeo, em que a mdia da chamada tratada pelo WebRTC. O servio tem integrao comFacebook, Gtalk, Windows Live e Yahoo e pode tambm funcionar atravs do plugin Flash. utilizado o protocoloXMPP atravs de HTTP na comunicao cliente-servidor.

TenHands

TenHands37 uma plataforma que fornece a capacidade de estabelecer comunicaes em tempo real entrebrowsers, estando integrado com algumas redes sociais e redes de empresas como Jive, Box, Salesforce, Face-book e Yahoo. A mdia das chamadas transmitida usando WebRTC, no entanto para j (Fevereiro 2013) autilizao deste sistema ainda necessita da instalao de um plugin proprietrio que permite a comunicaocom os servidores atravs de uma API proprietria utilizando HTTP.

Connect

Connect um servio disponibilizado pela empresa Utribo38 direcionado para a criao de pginas Web em que outilizador possa atravs de um clique, fazer uma chamada para a empresa que contratou o servio. Desta formaas empresas podem ter os seus clientes a ligar por exemplo para o centro de apoio a clientes gratuitamente eatravs do browser. A verso atual usa WebRTC e para browsers que no suportem, o suporte feito atravs dainstalao de uma aplicao no computador do cliente.

opentok

opentok39 uma API desenvolvida pela empresa tokbox que permite a criao de aplicaes fornecendo apossibilidade de integrao com os seus servios. A API permite a realizao de chamadas entre browsers,iOS e Android, sendo que na verso anterior a integrao com pginas Web dependia do plugin Adobe Flash, eatualmente suporta chamadas atravs de WebRTC.

O cdigo fonte da aplicao Javascript no est disponibilizado abertamente, mas os projetos dos vrios com-ponentes de servidores para integrao com a Software Development Kit (SDK) so pblicos e esto sobre alicena MIT.

Clientless Web Softphone

Clientless Web Softphone o novo produto da empresa dedicada a solues de telecomunicaes e VoIP Thru-point40. Este novo produto a ser construdo depende de um Gateway tambm criado pela empresa para garantira interoperabilidade entre o mundo SIP com o seu protocolo proprietrio enviado atravs de HTTP. A mdia

36https://bistri.com/37https://www.tenhands.net/38http://www.utribo.com/39http://www.tokbox.com/opentok/api40http://www.thrupoint.com/

47

https://bistri.com/https://www.tenhands.net/http://www.utribo.com/http://www.tokbox.com/opentok/apihttp://www.thrupoint.com/

baseada na tecnologia WebRTC e para permitir a integrao com clientes SIP criaram o componente ThrupointFusion Media Broker para conseguir a traduo entre os protocolos de mdia.

sipml5

Como j foi referido acima, sipml5 um cliente Web que permite o estabelecimento de chamadas VoIP atravs deWebRTC e a troca demensagens instantneas. Faz parte de um ecossistema de clientes da empresa Doubango41,que disponibiliza vrios componentes VoIP incluindo verses de clientes para Android e para Desktop, bem comoalguns componentes para servidores para permitir a traduo de mdia WebRTC e a traduo de SIP atravs deWebSockets para TCP ou UDP.

Este cliente disponibiliza tambm implementadas de algumas funcionalidades bsicas da especificao RCS.O cdigo est disponibilizado sobre a licena GPL v3.

frisB

FrisB42 um servio criado para enviar convites de chamadas para a nmeros de telefone reais