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.
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 menoroverhead 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 emmulticast, 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 darfeedback 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 dadastream 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ão9 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]
9Por 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
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 erapovoada 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]
2.3.1 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 aplugins tais como o Adobe Flex10,Adobe Flash ou OpenLaszlo11conseguem-se construir apli-
cações mais completas por estes correrem o código nativo, com mais capacidades que o Javascript simples. Podem também ser instaladosplugins 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 AIR12, JavaFx13)[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 fa- cilitem 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 multi- mé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 destreaming 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 in- stalado 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 oplugin 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 CodecsG.711 (Pulse Code Modulation A-law (PCMA) e Pulse Code Modulation U-law (PCMU)) eSpeex. Para codificação de vídeo são suportados os Codecs H.263 Sorenson Spark eH.264.
10www.adobe.com/products/flex 11http://www.openlaszlo.org/ 12www.adobe.com/products/air
Estas propriedades indicam que é umplugin 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 dosbrowsers, o plugin criou alguma inércia em alguns setores do mercado. AApple em 2010 declarou que o iPhone e o iPad não teriam suporte para Flash e recen- temente, também a Google anunciou que a partir doAndroid 4.1 Jelly Bean também não haveria suporte para oplugin[34]. Estes retrocessos afetam as decisões de quem produz software, ou de quem pensa comprar um produto baseado nestaframework.
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 oFlash, mas com uma aceitação pública menor como mostra a Tabela 2.3.1. Também através da utilização de servidores na rede (e.g. Media Suite15), é possível obter voz e vídeo em vários Codecs transmitidos sobre RTP.
OSilverlight corre em todos os Sistemas Operativos na maioria dos browsers desktop. No segmento das aplicações móveis, o Silverlight funciona emWindows Phone 7 e em no Symbian mais recente. Ainda não há suporte paraAndroid 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 Web16
Outra hipótese para criar aplicações RIA é usando oJavaFx, 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 doplugin. 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 1999. Desde aí a Internet mudou bastante, e como tal uma união 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 implementado pelas versões mais recentes dosbrowsers 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 novastags para o efeito. Esta nova versão do HTML vem tentar corrigir as divergências existentes nas várias
14http://www.wowza.com
15http://www.streamcoders.com/products/msnet.html
16http://w3techs.com/technologies/overview/client_side_language/all - Acedido a
27/01/2013 38
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 aplugins, passam agora a ser possíveis de criar apenas recorrendo ao uso de HTML, usando oCanvas que permite a criação de objetos livres incluindo em 3 dimensões. Um dos objetivos gerais é a redução da necessidade deplugins 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 dadosfull-duplex bi-direcional entrebrowsers e servidores, para permitir a criação de aplicações ainda mais interativas e para reduzir o overhead criado por mecanismos como oLong-pooling17. Algunsbrowsers têm já este mecanismo implementado, havendo
também já vários projetosopensource que permitem a criação de um servidor capaz de processar pedidos deste protocolo.
Figura 2.2: Arquitetura dos Websockets
2.4 Tecnologia WebRTC
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 deplugins. 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.
17Long-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.
Para se poder definir a especificação como proposta de standard do IETF, foi criada uma equipa de trabalho18
para definir quais os protocolos e standards usar e umamailing-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 browsers19
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 comFirewall e Network Address Trans- lation - 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;
18http://tools.ietf.org/wg/rtcweb/charters
19https://sites.google.com/site/webrtc/reference/architecture
• 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 interoper- abilidade 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 dosbrowsers. 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 primeirosdrafts foram ganhando forma. O browser Opera que tem ganho terreno no segmento dos Smart- phones, apostou mais nesta versão dobrowser mas também na versão OperaLabs é possível testar algumas das capacidades WebRTC20. Em seguida o Firefox21começou também os desenvolvimentos e aquando da escrita
deste documento (Janeiro de 2013), os trêsbrowsers 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 Frame22, juntamente com os
desenvolvimentos que iam sendo feitos no Google Chrome. Esteplugin 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 per- mite 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 àstags HTML5 audio ou video , podendo assim mostrar na página o resultado da captura. A outra hipótese de utilização das MediaS- treams é 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 outrosbrowsers. Assim que exista uma ligação estabelecida, os dados dastream 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 outrosbrowsers, a aplicação recebe a informação de que foram
20http://my.opera.com/chooseopera/blog/2012/01/11/try-out-the-all-new-camera-browser 21Na versão 18.0 do Firefox foi adicionado suporte parcial para WebRTC - https://www.mozilla.org/en-US/
firefox/18.0/releasenotes/
22http://www.google.com/chromeframe
adicionadas mais MediaStreams, e pode então atribui-las atags audio ou video para poder reproduzir os dados que chegam.
2.4.1 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 numbrowser pode ser usada.
Para criar uma chamada entre doisbrowsers 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étodocreateOffer(), enviando-o para o outro browser através da camada de sinalização. Quando a aplicação nobrowser 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étodocreateAnswer().[35, 38]
Desta forma a aplicação Web que está nobrowser 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
e assim que é recebido pela aplicação que começou o processo, é injetado no browser, completando assim o processo de sinalização.[35, 39]
2.4.2 Média
Tal como qualquer aplicação VoIP, umbrowser 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 osbrowsers teriam de implementar um mecanismo de Interactive Connectivity Establishment (ICE)[40] para estabelecerem as sessões de média. Este protocolo foi