DECLARAÇÃO
Nome: André Manuel Rodrigues da Silva
Endereço Electrónico: pg17619 <at> alunos.uminho.pt Nº do Bilhete de Identidade: 13001004
Título da Dissertação: Novas Arquiteturas Web para aplicações VoIP
Orientadores:
Professor António Duarte Costa Professora Maria João Nicolau Ano de conclusão: 2013
Designação do Mestrado: Mestrado em Engenharia Informática
DE ACORDO COM A LEGISLAÇÃO EM VIGOR, NÃO É PERMITIDA A REPRODUÇÃO DE QUALQUER PARTE DESTA TESE.
Universidade do Minho, 2013/06/27
Agradecimentos
Aos meus pais acima de tudo, pelo apoio em todos os momentos, mas mais que isso, por todo o esforço e apoio incondicional que permitiu que hoje eu consiga viver a fazer aquilo que gosto.
Às mulheres da minha vida Elsa, Teresa e Catarina pelo apoio e paciência de sempre e para sempre. À Ana, minha mais que tudo, pela motivação, amor, amizade, paciência e compreensão durante este projeto. Aos orientadores desta dissertação Professor António Duarte Costa e Professora Maria João Nicolau por toda a disponibilidade e atenção dispensadas.
À WIT-Software por me dar estas oportunidades de investigação que me fazem crescer. Aos amigos...
Resumo
Com o aparecimento de dispositivos de áudio e vídeo a preços baixos, da sua inclusão em qualquer computa-dor, e com o aumento da velocidade das ligações à Internet, surgiu o interesse em criar sistemas capazes de fazer chamadas através desta rede (Voice over IP (VoIP)).
Motivada pela migração das aplicações dodesktop para o browser, a Google decidiu criar uma nova tecnologia para permitir aosbrowsers o acesso nativo a câmaras e microfones, bem como a capacidade de comunicação direta de áudio e vídeo entrebrowsers. Esta tecnologia designa-se por Web Real Time Communication (WebRTC) e tem como principal objetivo permitir que todo um leque de aplicações, nomeadamente aplicações VoIP possam também ser migradas para páginas Web sem a necessidade de utilizar plugins externos, que podem não ser compatíveis com os diferentesbrowsers e sistemas operativos.
A WIT-Software S.A. (WIT), empresa especialista em aplicações móveis e em soluções que convergem vídeo, áudio, serviços de mensagens e de transferências de conteúdos, disponibiliza versões destas soluções para PC, Android, iPhone, iPad, Symbian e Web. Esta última foi criada usando aframework Flex e recorrendo ao plugin Adobe Flash.
Com o aparecimento de tecnologias emergentes como o WebRTC e o HyperText Markup Language 5 (HTML5), surgiu um novo desafio para a definição de uma nova arquitetura para os produtos VoIPweb-based, incluindo a criação de um cliente que cumpra as normas Rich Communications Services (RCS). No contexto deste projeto foi criada uma aplicação Web que dispensa a instalação de qualquerplugin adicional, com capacidade de fazer e receber chamadas de áudio e vídeo baseadas em WebRTC, e com algumas funcionalidades RCS. A aplicação final foi construída numa arquitetura escalável efuture-proof e é capaz de interoperar com as restantes aplicações da empresa, e mesmo com outros sistemas standard VoIP. O sistema construído foi demonstrado em vários
Abstract
The appearance of cheap audio and video devices and the fact that they are already included in almost all computers, added to the availability of higher speed Internet connections, have increased the interest in the creation of a system capable of establishing calls in this network (VoIP).
Lately, the number of applications that are being migrated from desktop to browsers have increased and so, Google decided to create a technology proposal to allow browsers native access to microphones and cameras, and also the capability to exchange multimedia data between browsers. The created technology is called WebRTC and its main purpose is to allow that a whole new segment of applications, namely VoIP applications, can also be migrated to Web pages without the use of external plugins, that bring problems when dealing with different Operative Systems and different browsers.
WIT it’s a Portuguese company focused in mobile applications and solutions that converge video, audio, instant messages and content transfer, offers several applications with such capabilities for PC, Android, iPhone, iPad, Symbian and Web. This last one was built using Flex framework based onAdobe Flash plugin.
With the emergence of technologies such as WebRTC and HTML5, a new challenge appeared for the definition of a new architecture for web-based VoIP products, including the creation of a client that follows the RCS specifi-cations. A new Web application was developed in the context of this project, that does not need the installation of any external plugin in the browser, and has the capability to start and receive WebRTC audio and video calls and also some RCS capabilities. The final application was built under a scalable and future-proof architecture and is able to inter-operate with all the current applications of the company and with other standard systems. The built
Índice
Índice ix
Índice de Imagens xi
Índice de Tabelas xiii
Índice de Listagens xv Acrónimos xvii 1 Introdução 21 1.1 Motivação . . . 21 1.1.1 Tecnologia . . . 22 1.1.2 Empresa e Produto . . . 22 1.2 Objetivos . . . 23 1.3 Contribuições . . . 24 1.4 Estrutura da dissertação . . . 24
2 Voz sobre IP - Estado atual da tecnologia 27 2.1 Session Initiation Protocol (SIP) . . . 28
2.2 Sessões de média . . . 34
2.3 VoIP em contexto WEB . . . 37
2.3.1 Tecnologias para construção de Rich Internet Application (RIA)s . . . 37
2.4 Tecnologia WebRTC . . . 39 2.4.1 Sinalização . . . 42 2.4.2 Média . . . 43 2.5 Projetos relacionados . . . 45 2.5.1 Produtos Concorrentes . . . 46 2.6 Discussão e Conclusões . . . 49
3 Requisitos e Arquitectura da solução 51 3.1 Requisitos de aplicações RCS . . . 51
3.2 Requisitos dos cenários de integração . . . 52
3.2.1 Cenário 1: Servidorstandalone com clientes Web . . . 53
3.2.2 Cenário 2: Servidorstandalone com vários clientes . . . 53 3.2.3 Cenário 3: Clientes Web interligados com a Public Switched Telephone Network (PSTN) 54
3.3 Sinalização - possíveis soluções . . . 54
3.3.1 RCS Representational State Transfer (REST) Application Programming Interface (API) 54 3.3.2 SIP através de WebSockets . . . 56
3.3.3 API privada através de WebSockets ou Hypertext Transfer Protocol (HTTP) . . . 58
3.4 Média . . . 59
3.5 Discussão da solução . . . 59
3.6 Arquitetura dos componentes . . . 63
3.6.1 Servidor . . . 63
3.6.2 Aplicação Web . . . 65
4 Implementação 69 4.1 Comunicação aplicação - servidor . . . 69
4.1.1 WIT API . . . 69
4.1.2 WebSockets . . . 73
4.1.3 HTTP - Long Polling . . . 73
4.2 Aplicação Web . . . 74
4.2.1 Software Development Kit (SDK) . . . 76
4.2.2 Interface gráfica - User Interface (UI) . . . 78
4.3 Servidor - Gateway . . . 80
4.3.1 Tradução de sinalização . . . 80
4.3.2 Transformação de média WebRTC . . . 81
5 Testes e Integrações 85 5.1 Integrações e demonstrações . . . 85
5.2 Testes e resultados . . . 86
5.2.1 Sinalização e média Message Session Relay Protocol (MSRP) . . . 87
5.2.2 Média VoIP . . . 90
5.2.3 Testes futuros . . . 94
6 Conclusão 95 6.1 Síntese do trabalho realizado . . . 95
6.1.1 Processo e decisões tomadas . . . 96
6.2 Trabalho futuro . . . 97
6.3 Notas finais . . . 97
Bibliografia 101
A API Javascript 105
B Código necessário para fazer chamadas 109
Índice de Imagens
1.1 Visão do objetivo geral . . . 23
2.1 Esquema do estabelecimento de uma sessão SIP . . . 31
2.2 Arquitetura dos Websockets . . . 39
2.3 Esquema da arquitetura WebRTC a definir nos browsers . . . 40
2.4 Esquema do enquadramento do WebRTC na rede . . . 42
3.1 Clientes webstandalone . . . 53
3.2 Clientesstandalone . . . 53
3.3 Clientes web numa rede operador . . . 54
3.4 Esquema do gateway de transformação necessário para a RCS REST API . . . 55
3.5 Esquema da utilização de SIP através de WebSockets . . . 56
3.6 Esquema do Gateway de tradução de uma API privada . . . 58
3.7 Soluções a criar para cumprir os cenários requeridos . . . 61
3.8 Arquitetura dos componentes do Gateway / Servidor . . . 65
3.9 Arquitetura da aplicação Web . . . 66
4.1 Aplicação após registo . . . 75
4.2 Aplicação durante uma sessão de chat . . . 79
4.3 Aplicação durante uma chamada de vídeo . . . 79
4.4 Esquema da tradução da WIT API no servidor da empresa . . . 81
4.5 Esquema da tradução da WIT API para protocolos standard em VoIP . . . 81
4.6 Esquema da tradução de média WebRTC . . . 83
5.1 Disponibilização do Gateway em produção utilizando WebSockets . . . 87
5.2 Utilização do Central Processing Unit (CPU) em teste de carga . . . 89
5.3 Níveis de utilização de memória em teste de carga . . . 90
5.4 Cenários usados para testar a qualidade da re transmissão de média . . . 91
5.5 Áudio transmitido de ponto-a-ponto . . . 92
5.6 Áudio transmitido através do servidor . . . 92
5.7 Vídeo transmitido de ponto-a-ponto . . . 93
Índice de Tabelas
2.1 Utilização de cada tecnologia em páginas Web . . . 38
2.2 Tabela comparativa de algumas soluções atuais . . . 49
3.1 Comparação das soluções para a sinalização . . . 60
Índice de Listagens
2.1 Exemplo de um pedido SIP REGISTER e respectiva resposta [1] . . . 29
2.2 Exemplo de um pedido SIP com o Session Description Protocol (SDP) para negociar uma chamada de áudio [1] . . . 31
2.3 Esquema do funcionamento das notificações . . . 33
2.4 Exemplo de uma mensagem instantânea enviada com o comando MESSAGE [2] . . . 34
2.5 Exemplo da negociação de uma sessão MSRP[3] . . . 35
2.6 Exemplo de um SDP gerado pelo Google Chrome . . . 44
4.1 Exemplo de um objeto JavaScript Object Notation (JSON) para iniciar uma chamada (pedido cliente-servidor) . . . 70
4.2 Exemplo de um objeto JSON com resposta provisória do servidor . . . 71
4.3 Exemplo de um objeto JSON com um pacote de média . . . 72
4.4 Exemplo de um objeto JSON com um pacote com uma resposta de média . . . 72
Acrónimos
3GPP 3rd Generation Partnership Project Ajax Asynchronous JavaScript + XML AMF Action Message Format
ASCII American Standard Code for Information Interchange API Application Programming Interface
Codec Compression/Decompression Module CPIM Common Presence and Instant Messaging CPU Central Processing Unit
CU-RTC-Web Customizable, Ubiquitous Real Time Communication over the Web DOM Document Object Model
DTLS Datagram Transport Layer Security GSMA Groupe Speciale Mobile Association HTML5 HyperText Markup Language 5 HTML HyperText Markup Language HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure ICE Interactive Connectivity Establishment IMAP Internet Message Access Protocol IETF Internet Engineering Task Force IAX2 Inter-Asterisk eXchange v2 IE Internet Explorer
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
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
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
Capítulo 1
Introdução
Nos últimos anos tem-se verificado uma crescente migração das aplicações nativas de Desktop para aplicações Web. Também a comunicação em tempo real tem sofrido uma grande evolução com o recurso às chamadas Voice over IP (VoIP), existindo já várias aplicações integradas nas redes sociais que permitem chamadas de áudio e vídeo gratuitas, tanto a partir da Web como de aplicações para dispositivos móveis.
Acompanhando esta tendência, e com o aparecimento de novas tecnologias emergentes, surge a necessidade de definir novas arquiteturas para aplicações Web. Este projeto faz uma análise sobre estas novas ferramentas e mostra como estas podem ser utilizadas na construção de novas aplicações Web capazes de fazer chamadas para outras aplicações VoIP genéricas ou mesmo para telefones fixos ou móveis.
1.1 Motivação
Hoje em dia, para umbrowser poder efetuar chamadas necessita de recorrer às capacidades de alguns plugins externos. Um dos mais utilizados é oAdobe Flash que permite o acesso a câmaras e microfones do dispositivo, e disponibiliza facilmente a criação destreams através das quais se pode transmitir áudio e vídeo. Este plugin, apesar de estar presente em grande parte dos dispositivos, já foi alvo de muitas críticas e criou alguns inimigos ao longo do seu desenvolvimento.
É o caso da Apple que não dá suporte nem inclui esteplugin nos seus dispositivos e que causa por isso uma quebra de compatibilidade com um número já grande de utilizadores. Em 2010 numa carta aberta1, Steve Jobs
explicou as razões pelas quais achava que o Flash não era a tecnologia ideal para mostrar conteúdos na Web, baseando os seus argumentos no largo consumo de recursos que oplugin exige, no facto de ser uma plataforma fechada em contraste com o HyperText Markup Language 5 (HTML5) que a Apple apoia e por ser construído para Desktop, não estando preparado para os novos paradigmas de interação através de toque.
Uma das limitações do Adobe Flash é a necessidade de se enviar os dados de média para um servidor para que este possa traduzir o protocolo de transporte, no caso de se querer integrar com outros clientes que utilizem os protocolos standard de aplicações VoIP, forçando assim a que seja necessária uma maior infra-estrutura de servidores maior no caso de colocação em produção de um sistema destes.
Vários standards estão a ser definidos no contexto do HTML5, convergindo para as capacidades que são alcançáveis atualmente através deplugins. A procura por soluções alternativas e normalizadas tem motivado a comunidade científica a investigar novas formas de permitir comunicações em tempo real através dosbrowsers.
1.1.1 Tecnologia
A Google criou no início de 2011 uma proposta de especificação de uma tecnologia que dotasse osbrowsers das mesmas capacidades de um cliente VoIP, revolucionando assim este sector de negócio. A especificação Web Real Time Communication (WebRTC) criada desde então envolve 3 grandes objetivos:
1. Permitir que osbrowsers tenham acesso nativo aos microfones e câmaras dos dispositivos;
2. Dotar osbrowsers da capacidade de comunicação independente de áudio e vídeo de forma segura através do protocolo Secure Real Time Protocol (SRTP);
3. Disponibilizar uma implementação de um canal de dados através do qual doisbrowsers possam trocar dados diretamente de forma a permitir a criação de aplicações de comunicação interativa.
Ao mesmo tempo que a especificação está a ser criada, esta está também a ser implementada pelosbrowsers, sendo que se pode já desde há algum tempo usar e desenvolver aplicações com esta tecnologia utilizando versões dosbrowsers para programadores. Para um utilizador comum estas capacidades começam a ficar acessíveis, tendo a Google lançado na versão oficial do Chrome já o primeiro e segundo objetivos implementados num estado funcional, apesar de a especificação ainda não ser final (Maio 2013).
Também já implementado pelas versões mais recentes dosbrowsers e em estado de maturação está o HTML5, que veio permitir entre muitas coisas, a reprodução nativa de áudio e de vídeo. Esta nova versão do HyperText Markup Language (HTML) vem tentar corrigir as divergências existentes nas várias implementações das versões anteriores, tentando assim criar uma ferramenta muito poderosa para a criação de páginas Web interativas e muito completas, com a possibilidade de manipulação de objetos gráficos, som e vídeo.
1.1.2 Empresa e Produto
A WIT-Software S.A. (WIT) é uma empresa especialista em aplicações móveis e em soluções que convergem vídeo, áudio, serviços de mensagens e de transferência de conteúdos, disponibilizando versões destas soluções para PC, Android, iPhone, iPad, Symbian e Web.
A aplicação Web foi criada usando aframework Flex e recorrendo ao plugin Adobe Flash, permitindo atualmente fazer chamadas de áudio e vídeo e enviar SMS/MMS, bem como todo o leque de funcionalidades referidas na especificação da Groupe Speciale Mobile Association (GSMA). Em 2011 a WIT foi selecionada mundialmente como fornecedora das aplicações Rich Communications Services (RCS) oficiais e está desenvolver as mesmas segundo as especificações da GSMA.
Todos os produtos deste ecossistema da WIT comunicam através do protocolo Session Initiation Protocol (SIP) que é bastante utilizado hoje em dia nas aplicações VoIP. Para que o cliente Web pudesse também comunicar com clientes SIP, foi necessária a construção de um Gateway que conseguisse traduzir pedidos recebidos do cliente Flash por Real Time Messaging Protocol (RTMP) em pacotes SIP e vice-versa.
A WIT está atenta aos desenvolvimentos e atualizações das tecnologias na área das comunicações, e com o aparecimento da tecnologia WebRTC, pretende naturalmente redesenhar a arquitetura do seu produto Web de forma a que tenha os seus clientes VoIP compatíveis com as novas tendências de mercado.
Este projeto enquadra-se neste âmbito, sendo do interesse da empresa que seja analisada a tecnologia emer-gente WebRTC e a possibilidade de construção de aplicações Web com as capacidades das restantes aplicações da empresa sem o recurso aplugins.
As aplicações RCS têm hoje em dia um crescente interesse comercial e como tal, é também preocupação da empresa que o resultado da nova arquitetura não comprometa a totalidade da solução, ao acesso a terceiros, dada a natureza aberta das linguagens utilizadas na Web (HTML5 e Javascript).
1.2 Objetivos
O objetivo deste trabalho foi a definição de uma nova arquitetura para um cliente Web que utilize a tecnolo-gia WebRTC. Para isso, foi necessário cumprir vários objetivos de investigação e desenvolvimento inicialmente propostos, que são descritos em seguida.
Figura 1.1: Visão do objetivo geral
• Analisar o estado atual dos desenvolvimentos na área das aplicações VoIP, incluindo a nova tecnologia WebRTC;
• Estudar o protocolo SIP de forma a poder criar uma arquitetura que interligue um cliente Web com qualquer cliente SIP genérico;
• Fazer um levantamento das várias possibilidades de transporte de sinalização e comparar todas as possi-bilidades encontradas analisando as vantagens e desvantagens da sua utilização, justificando a decisão tomada;
• Investigar quais os protocolos para o transporte de média e soluções para ultrapassar problemas de Network Address Translations (NATs).
• Conceber uma possível arquitetura e implementar uma biblioteca Javascript que utilize a tecnologia WebRTC, de forma a permitir a fácil criação de aplicações Web com capacidades VoIP;
• Preparar a arquitetura para uma futura integração com as funcionalidades definidas nas normas RCS, definidas pela GSMA;
• Disponibilizar um novo cliente Web que cumpra as normas RCS baseado na tecnologia WebRTC e HTML5 para utilizar em demonstrações;
• Garantir a interoperabilidade entre o sistema obtido e as restantes aplicações da WIT; • Comparar o resultado obtido com os possíveis concorrentes e com as soluções atuais;
1.3 Contribuições
Como resultado final deste projeto foram dados vários passos que permitiram cumprir os objetivos propostos. A construção de vários componentes para a disponibilização final de uma aplicação Web deu origem aos seguintes contributos:
• Foi construído um Gateway capaz de processar uma Application Programming Interface (API) genérica através de vários protocolos de transporte, usando um componente de tradução da sinalização capaz de aceitar clientes Flash, WebSockets ou Hypertext Transfer Protocol (HTTP) Long Polling;
• Foi definida uma biblioteca Javascript capaz de abstrair a lógica de estabelecimento de chamadas WebRTC, bem como das funcionalidades RCS;
• Foi elaborada uma interface gráfica para permitir demonstrar as capacidades implementadas na Gateway e biblioteca Javascript.
• Foram feitas várias integrações e demonstrações em congressos mundiais (Mobile World Congress (MWC) 2013 e ACME INTERCONNECT 2013) e a operadores telefónicos de várias partes do mundo.
• Mostrou-se a capacidade de reutilização da biblioteca construída com a criação de novas interfaces gráfi-cas específigráfi-cas para um operador.
• Foi feita a integração da Gateway com serviços externos para permitir o estabelecimento de chamadas de e para a Public Switched Telephone Network (PSTN).
1.4 Estrutura da dissertação
Este primeiro capítulo dá a conhecer o contexto da investigação, com uma descrição dos temas em que se insere, o contexto em que surge e qual a motivação para o fazer. São também descritos os objetivos que se pretendia cumprir com este trabalho, e quais as contribuições conseguidas com a sua realização.
No Capítulo 2 é apresentado o estado atual das tecnologias inerentes a sistemas VoIP dentro e fora do con-texto Web, mostrando em detalhe as que são mais relevantes para o trabalho a realizar. É também descrita com detalhe a tecnologia WebRTC, cada um dos seus componentes e capacidades bem como a integração que é possível conseguir com a sua utilização. O capítulo termina com a apresentação de vários projetos em desenvolvi-mento que focam pontos semelhantes aos desta investigação, e é apresentada uma análise dos problemas que surgem com a tentativa de interoperar a tecnologia WebRTC com o mundo VoIP e mesmo com a rede mundial de telefones(PSTN).
Após estes passos, no Capítulo 3 apresenta-se a discussão dos requisitos e a análise de cada uma das possíveis soluções. Após esta análise, é definida a arquitetura da solução a implementar, enumerando os componentes necessários para o cumprimento dos objetivos propostos.
No Capítulo 4 descreve-se como foi abordada a implementação dos diferentes componentes do projeto, começando por explicar como foi realizada a comunicação cliente servidor, e explicando depois quais os passos dados na implementação do servidor e da aplicação Web. Neste capítulo são apresentados alguns diagramas explicativos e também imagens com o aspecto final da aplicação.
Após a descrição da implementação, são apresentadas no Capítulo 5 algumas integrações e demonstrações em que o projeto foi utilizado. São também descritos os testes realizados ao sistema final, bem como a discussão dos resultados, antevendo algumas conclusões comparativas com as soluções anteriores. Ainda neste Capítulo, é apresentada uma secção onde futuros testes são descritos, como continuação do trabalho realizado.
O documento termina com a Conclusão no Capitulo 6 onde é analisado o trabalho desenvolvido e os planos para o futuro. São também apresentadas algumas notas finais sobre a tecnologia WebRTC e é feita uma com-paração com as tecnologias anteriores, seguido pela bibliografia utilizada na produção deste documento e como auxílio de todo o projeto.
Capítulo 2
Voz sobre IP - Estado atual da tecnologia
VoIP é a tecnologia que permite estabelecer chamadas telefónicas através da Internet ou seja, que possibilita a transmissão de sinais de voz através de uma rede de dados. A voz é convertida de sinais analógicos em digitais, que são depois transmitidos utilizando a rede Internet Protocol (IP).
Hoje em dia várias aplicações VoIP são utilizadas para estabelecer chamadas de áudio e vídeo gratuitas através da Internet. Aplicações como oGoogle Talk, Windows Live Messenger (WLM), Skype entre outras, são utilizadas em massa tanto para trocar mensagens instantâneas como para fazer chamadas entre computadores. Cada uma das aplicações referidas anteriormente utiliza o seu protocolo, sendo que o único que é aberto é o utilizado peloGoogle Talk. Este utiliza o protocolo eXtensible Messaging and Presence Protocol (XMPP) tanto para a troca de mensagens como para a negociação de chamadas no serviço Google Hangout, onde é usada a extensão Jingle com algumas modificações para suportar a negociação de chamadas[4]. Tanto o WLM como o Skype trocam também mensagens instantâneas e estabelecem chamadas mas utilizando protocolos proprietários, o que torna bastante difícil ou mesmo impossível a criação de aplicações que consigam interagir com estes. Ao contrário das outras aplicações, oSkype oferece a possibilidade de estabelecer chamadas para a rede telefónica mundial (PSTN), conseguindo cobrar valores mais baixos que as chamadas dos operadores desta rede.[5]
Para que estas aplicações tenham um bom desempenho e para que consigam transmitir os dados de voz e vídeo com boa qualidade, é necessário que estas utilizem vários mecanismos para ultrapassar os proble-mas que possam encontrar na rede. Precisam também de ter em atenção o estado da rede e de escolher o Compression/Decompression Module (Codec) mais apropriado a cada situação. Estes elementos respon-sáveis por codificar e descodificar os sinais analógicos de voz em sinais digitais são cruciais na qualidade das chamadas[6], pois existem várias implementações e que obtêm melhores ou piores resultados em diferentes situações[7].
OSkype é um exemplo de um cliente que cresceu bastante com as chamadas VoIP e em grande parte devido à boa qualidade conseguida através do seu sistema, contituído por vários componentes que fazem com que a Quality of Experience (QoE) resultante da utilização da aplicação seja bastante boa. Esses elementos vão desde os Codec’s utilizados (e.g. Silk1, Opus2 3) aos nós de rede espalhados pelo mundo, para garantir que existem
sempre pontos de retransmissão próximos de quem está a fazer uma chamada[5, 8].
O mecanismo de VoIP independentemente do protocolo utilizado, divide-se em 2 camadas distintas:
Sinalização Parte da comunicação que permite efetuar a negociação dos parâmetros em que se vai estabelecer
uma chamada, e através da qual o destinatário recebe a informação de que o iniciador da chamada está
1https://developer.skype.com/silk 2http://www.opus-codec.org/
a tentar estabelecer uma chamada. Esta negociação é feita usando um protocolo próprio para o efeito.
Média Após o destinatário ter aceite a chamada, é estabelecida a ligação através da qual os dados serão
trocados. Esta é normalmente criada sobre uma ligação User Datagram Protocol (UDP).
Antes de se trocar áudio ou vídeo entre dois pontos, vários protocolos têm de ser usados, tanto para permitirem a localização do dispositivo em questão, como para o transporte e negociação dos parâmetros necessários para estabelecer a chamada. Além dos protocolos usados pelas aplicações próprias de alguns serviços (e.g. Skype, Inter-Asterisk eXchange v2 (IAX2)4)[5, 9], existem vários protocolos que poderão ser usados para sinalização,
no entanto os mais usados são o H.323 e o SIP[7, 10]. Ambos começaram a ser criados em 1995 mas a International Telecommunication Union (ITU) lançou um primeiro standard do H.323 muito rapidamente em 19965. Desde aí a ITU tem lançado novas versões do standard sendo que a última foi a versão 7 em 20096. A
Internet Engineering Task Force (IETF) lançou no mesmo ano um draft sobre o SIP, mas o standard apenas foi aceite em 1999 com o RFC2543[11]. Após algumas revisões, foi relançado o standard em 2002 no RFC3261[1] que é usado hoje em dia.
Ao longo dos anos inúmeros artigos e discussões foram criadas sobre qual o melhor dos dois protocolos, sendo que ambos servem o mesmo propósito: estabelecer uma comunicação multimédia. Os argumentos são muitas vezes relacionados com os apoiantes de cada uma das comunidades: ITU vs IETF. O H.323 é um protocolo binário e que permite uma boa integração com a PSTN. O protocolo SIP é representado em American Standard Code for Information Interchange (ASCII), e por isso torna-se mais simples de implementar e de resolver problemas com uma simples captura de rede. O H.323 é o protocolo mais utilizado principalmente para telefones de conferência e por ter regras mais rígidas, fornece uma melhor interoperabilidade entre implementações. O protocolo SIP é mais utilizado na criação de sistemas VoIP “fechados”, devido à simplicidade da sua construção e facilidade de depuração[12].
2.1 SIP
Tal como o H.323, o protocolo SIP funciona sobre TCP ou UDP mas é mais usual encontrar implementações sobre UDP, e por isso foi pensado com alguns mecanismos para tornar a troca de mensagens mais fiável, como é o exemplo da inclusão de uma forma de confirmação de uma resposta final no estabelecimento de uma sessão (método ACK).
Apesar do protocolo SIP permitir que duas aplicações comuniquem diretamente sem a necessidade de exis-tir um servidor ou proxy, esta não é a utilização mais usual, pois para além de na maior parte dos casos ser necessário resolver problemas de Firewall e NAT, normalmente existe um serviço associado que necessita de fat-urar ou contar as ligações. A existência de um servidor é importante por exemplo para que um utilizador se possa registar nele para que este saiba a sua “localização” quando houver um pedido que lhe seja direcionado[12].
O protocolo SIP foi desenvolvido à semelhança do protocolo HTTP, sendo por isso constituído por um verbo que define a ação e o recurso a aceder. Em seguida aparecem os váriosheaders usados para enviar mais detalhes sobre o pedido, tais como a identificação, autenticação ou informações sobre o conteúdo. Opcionalmente, cada
4Protocolo VoIP utilizado na comunicação entre os servidores Open sourceAsterisk 5http://www.itu.int/rec/T-REC-H.323-199611-S/en/ 6http://www.itu.int/rec/T-REC-H.323-200912-I/en
pedido pode também conter um corpo para poder transportar conteúdos em vários formatos. As respostas são também compostas por um código representativo de um estado, e que facilita a identificação do tipo de resposta entre todas as aplicações. Estas contêm também váriosheaders com informações que permitem enriquecer a resposta com informação e podem também conter um corpo, para transportar dados em vários formatos. REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4
To: Bob <sip:bob@biloxi.com>;tag=2493k59kd From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4> Expires: 7200
Content-Length: 0
Listagem 2.1: Exemplo de um pedido SIP REGISTER e respectiva resposta [1]
Os pedidos SIP seguem o modelo de pedido/resposta, em que por cada pedido existe pelo menos uma resposta final e poderão existir várias respostas provisórias. Estas últimas podem trazer informação sobre o progresso do pedido efetuado, até que o destino tenha uma resposta definitiva.
À semelhança do HTTP, existem vários métodos que podem ser usados em SIP e também as respostas podem ter vários códigos de resposta. Alguns destes foram aproveitados do protocolo HTTP e estão distribuídos por categorias [13, 1]7:
1xx: Provisional Pedido recebido, a continuar o ser processamento; 2xx: Success A ação pedida foi recebida, percebida e aceite;
3xx: Redirection Mais ações necessitam de ser tomadas para completar o pedido;
4xx: Client Error O pedido contém erros de sintaxe ou não pode ser realizado neste servidor;
5xx: Server Error O servidor falhou ao executar a ação apesar de o pedido estar aparentemente correto; 6xx: Global Failure O pedido não pode ser realizado em nenhum servidor.
Inicialmente o protocolo foi criado para estabelecer chamadas e para isso, foram criados os métodos necessários ao registo e ao estabelecimento de uma sessão [1].
Comandos base: REGISTER, INVITE, CANCEL, BYE, ACK, OPTIONS
Todos os comandos podem ser direcionados a diferentes pontos, e para isso podem ser usados os headers To e From que permitem identificar um utilizador inequivocamente no servidor. Estesheaders levam como valores Uniform Resource Identifier (URI)’s que podem ser SIP URI ou outro tipo de URI’s, como por exemplo os TEL URI’s definidos no RFC2806[14]. Todas as aplicações SIP têm de suportar os URI’s doschema SIP que têm o formatoschema:user@domain em que o schema pode ser sips ou sip, consoante a ligação seja sobre Transport Layer Security (TLS) ou não, respectivamente[15]. Ouser deve identificar o utilizador inequivocamente e é comummente usado o número de telefone ouusername registado no serviço e o domain identifica o serviço no qual o utilizador está registado sendo que por vezes, odomain é o conjunto de host:port onde o serviço é encontrado. É possível fazer por exemplo chamadas anónimas, enviando para isso oheader From com o valor sip:anonymous@anonymous.invalid e enviando a identidade do utilizador que está a efetuar o pedido no header Prefered-Identity. Desta forma o servidor irá conseguir identificar o originador da chamada mas não irá enviar esta identidade para o destinatário.
O comando REGISTER é enviado para o servidor com a informação do utilizador que se está a registar. O registo num servidor é sempre um registo temporário, que é válido durante o número de segundos enviado no header Expires, como mostra o exemplo da Listagem 2.1, em que o utilizador terá um registo no servidor válido durante duas horas (7200 segundos). Antes desse tempo terminar, se a aplicação ainda quiser manter o seu registo, deve enviar novamente um pedido REGISTER, renovando assim por mais outro intervalo de tempo a disponibilidade no servidor.
Numa resposta a um REGISTER o servidor pode devolver uma resposta de sucesso informando assim a aplicação do sucesso do registo ou pode devolver outras respostas de erro que devem ser analisadas caso a caso. A título de exemplo, se for necessário autenticar o pedido (e.g. mecanismo Digest), o servidor responde com uma resposta 401 UNAUTHORIZED e adiciona oheader com o chalenge necessário para o envio de um novo REGISTER autenticado com as credenciais do utilizador em questão.
O protocolo SIP não define o conjunto mínimo de métodos, formatos ou funcionalidades que um cliente ou servidor SIP deve suportar e por isso, torna-se necessário um método para dar a conhecer as capacidades de cada ponto na rede.
Após estar autenticada, uma aplicação pode enviar pedidos para outros utilizadores através do servidor, mas antes de o fazer esta consegue saber se o pedido vai ser entendido enviando um pedido OPTIONS. Estes pedidos podem ser enviados para os servidores ou mesmo para outros clientes, dependendo doheader To inserido no pedido. Visto que podem existir váriosproxies na rede através dos quais um pedido tenha de passar, é possível com este método fazer uma espécie detraceroute8alterando com oheader Max-Forwards, e obtendo assim as
capacidades de cada nó na rede até chegar ao cliente destino.
Em resposta a um pedido de OPTIONS, um nó na rede deverá responder com as suas capacidades, colocando nos headers Allow, Accept, Accept-Encoding, Accept-Language, e Supported os valores que coincidem com a sua implementação.
8Traceroute é um mecanismo utilizado para descobrir o percurso que um pacote faz na rede. É criado com recurso ao mecanismo
de definição do número máximo de saltos que um pacote pode dar na rede, e através do envio consecutivo de pacotes com este valor incrementado, consegue-se descobrir qual o ponto na rede a uma dada distância
Figura 2.1: Esquema do estabelecimento de uma sessão SIP
O método INVITE é utilizado para iniciar uma sessão e transporta a informação sobre o destinatário com o qual se deseja estabelecer a mesma e as propriedades da sessão a criar. Ao criar por exemplo uma chamada com outro utilizador, a aplicação deve enviar um pedido com o método INVITE colocandoheaders From e To respetivos e juntar no corpo da mensagem a descrição da chamada que pretende criar, no formato Session Description Protocol (SDP) definido em RFC4566[16]. Este formato define para cadastream audio ou video, as portas onde o cliente estará à espera de receber dados, os Codecs e as respectivas taxas de transmissão.
O corpo de um INVITE pode transportar muitos outros elementos e até vários ao mesmo tempo, utilizando para isso oMIME type “multipart” definido pelo RFC5621[17]. Para estabelecer uma ligação segura para transferência dos dados SRTP, devem ser partilhadas as chaves necessárias também no corpo da mensagem SDP.[18]
Após a aplicação do cliente destino ter recebido o INVITE para uma chamada, esta envia uma resposta pro-visória com o código 180 RINGING, informando assim o remetente de que o utilizador está a ser alertado para a chamada. Consoante a resposta do utilizador ou falta dela, uma resposta final será enviada com a respetiva informação. Caso a resposta seja positiva e o utilizador queira atender a chamada, o código de resposta enviado é o 200 OK e no corpo da resposta é enviado novamente um SDP desta vez com as informações relativas às capacidades da aplicação destino, em que IP e portas esta vai estar à espera de receber os dados, e que Codecs escolheu para transmitir.
Após a recepção de uma resposta final, a aplicação que enviou o INVITE envia um comando ACK para informar a outra aplicação de que a resposta foi recebida, e a transmissão de dados vai prosseguir.
Caso o iniciador de uma chamada a queira terminar antes do o outro utilizador devolver uma resposta definitiva, um pedido com o comando CANCEL tem de ser enviado com um Call-Id igual ao enviado no INVITE para o cancelar.
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp
v=0
o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com s=Session SDP
t=0 0
c=IN IP4 pc33.atlanta.com m=audio 3456 RTP/AVP 0 1 3 99 a=rtpmap:0 PCMU/8000
Listagem 2.2: Exemplo de um pedido SIP com o SDP para negociar uma chamada de áudio [1] Se a chamada for estabelecida está criado um diálogo SIP e para ser terminado, tem de ser enviado um pedido BYE com o mesmo Call-Id enviado no INVITE inicial. Ambas as partes da ligação podem enviar o BYE, assim que quiserem terminar a sessão estabelecida.
Extensões: PRACK, UPDATE, SUBSCRIBE, NOTIFY, PUBLISH, INFO, MESSAGE, REFER
No RFC3261[1] foi descrito o protocolo SIP como base de um protocolo de comunicação, que pode ser expandido através da manipulação e adição de novosheaders e também através da criação de novos métodos. Hoje em dia, vários outros mecanismos são usados para auxiliar as sessões criadas e disponibilizar outras funcionalidades extra usando o SIP.
Como foi referido acima, quando uma resposta final a um INVITE é recebida, um comando ACK relativo à resposta recebida é enviado de volta. Enquanto a aplicação que enviou a resposta não receber este comando, deve continuar a enviar a resposta repetidamente em intervalos de tempo crescentes. Este mecanismo serve para garantir que a resposta é recebida por quem iniciou o diálogo. Além destas respostas, também se começou a sentir a necessidade de obter uma confirmação da recepção das respostas provisórias. Isto acontece quando as respostas provisórias transportam mais informação relevante que apenas um simples código de resposta, que apenas dá algumfeedback ao utilizador.
Um exemplo da utilização de respostas provisórias para o transporte de alguns dados extra, pode ser visto hoje em dia quando ligamos para alguém e a chamada é redirecionada para o gravador ou quando alguém ativa os serviços de música enquanto a chamada não é atendida (e.g. Vodafone RingDing, TMN WaitingRing). O que acontece nestes casos, quando uma chamada é iniciada a partir de um cliente SIP e é depois passada para a PSTN, enquanto o utilizador não atende ou rejeita a chamada, o servidor do serviço em questão envia uma resposta provisória com o código 183 SESSION PROGRESS, em que o conteúdo inclui o SDP para que a aplicação que enviou o INVITE possa estabelecer uma ligação de um sentido, onde vai receber dados de áudio respetivos à mensagem a transmitir.
Nestes casos pode ser necessário que o servidor receba uma confirmação de que pode começar a enviar o áudio, e para isso foi criado o comando PRACK, que é semelhante ao BYE, por ter também uma resposta, mas tem a mesma função de um ACK. As aplicações ficam a saber da necessidade de suportar ou não esta funcionalidade através da inclusão do valor 100rel no header Require, e devem ser enviadas para todas as respostas com códigos entre 101 e 199 (o código 100 TRYING está excluído, por ser enviado por nós de rede)[19]. O comando INVITE é utilizado para a criação de um diálogo, onde se podem depois trocar dados num ou nos dois sentidos, até que um BYE seja enviado. No entanto, após uma aplicação ter enviado um pedido destes, esta pode querer fazer alterações ao seu conteúdo, antes mesmo de receber uma resposta final. Para isto foi criada uma extensão definida no RFC3311[20] que cria o comando UPDATE. Este é usado por exemplo para alterar o SDP que foi enviado, de forma a completar com informação mais atual ou mesmo para que duas aplicações consigam estabelecer uma ligação para trocar dados antes do pedido ser aceite. Normalmente esta operação de atualização dos parâmetros de uma sessão é realizada enviando um novo INVITE, mas apenas pode ser realizada após o diálogo estar estabelecido. O UPDATE vem colmatar essa falha.
Outro tipo de necessidade foi a obtenção de notificações quando algo acontecia no servidor e para isso foram criados os comandos SUBSCRIBE e NOTIFY. O comando SUBSCRIBE é enviado por um cliente para o servidor, subscrevendo um tipo de eventos para um recurso em particular. Se for possível e permitido ao utilizador em questão receber notificações do recurso pedido o servidor enviará uma resposta final com o código 200 OK, e passará a partir daí a enviar comandos NOTIFY com as atualizações que aconteceram no recurso em questão. Uma subscrição, tal como os comandos REGISTER, são válidos durante um intervalo de tempo enviado noheader Expires, e devem ser renovados pelo cliente, caso este ainda pretenda receber notificações. Quando um cliente não desejar receber mais comandos NOTIFY sobre um recurso, deve enviar um novo SUBSCRIBE com oheader Expires com o valor 0, informando assim o servidor de que não deseja estar durante mais tempo a receber notificações [21].
Subscriber Notifier
|---SUBSCRIBE---->| Request state subscription |<---200---| Acknowledge subscription
|<---NOTIFY--- | Return current state information |---200--->|
|<---NOTIFY--- | Return current state information |---200--->|
Listagem 2.3: Esquema do funcionamento das notificações
Um exemplo de utilização deste mecanismo é a obtenção de notificações sobre os utilizadores numa conversa de grupo, em que a informação sobre a disponibilidade de cada utilizador pode ser fornecida por notificações do servidor. Desta forma, quando um utilizador entra ou sai, os restantes utilizadores recebem essa informação através de um eXtensible Markup Language (XML) e podem atualizar a lista de utilizadores presentes na sala de conversação ou atualizar o seu estado [22].
Uma outra extensão ao protocolo SIP foi estabelecida em 2004 com o RFC3909[23], que está também rela-cionada com os dois comandos apresentados anteriormente. O propósito deste standard foi a criação do co-mando PUBLISH para permitir a publicação de novos eventos para o servidor, para que este pudessem gerar novas notificações. Este mecanismo surge como consequência dos comandos SUBSCRIBE e NOTIFY, e surgiu para permitir a implementação de um sistema de presença, através do qual um utilizador pudesse alterar o seu estado (e.g. Disponível, Ocupado, Ausente...). Por cada vez que o utilizador alterasse o seu estado, um
novo comando seria enviado para o servidor transportando no conteúdo um documento XML com a informação respetiva. Os utilizadores que tivessem subscrito a presença desse utilizador (através de um pedido SUBSCRIBE com oheader Event com o valor “presence”), receberiam um comando NOTIFY com o novo documento.
Outra extensão criada foi o comando INFO, que foi tornado standard em 2000 com o RFC2976[24] e que foi revisto e republicado em 2011, no RFC6086[25]. Este método foi criado para transportar dados referentes a um diálogo já estabelecido, mas que não alteram em nada as propriedades do mesmo, ao contrário de um re-INVITE ou de um UPDATE, que podem alterar por exemplo os Codecs a serem usados na sessão. Este comando transporta normalmente conteúdo com informação para o utilizador. Uma das utilizações conhecidas é o transporte de sinais DTMF, em que o pedido leva informação sobre qual a tecla pressionada e durante quanto tempo ocorreu.
Para que se pudesse adicionar suporte para mensagens instantâneas entre clientes SIP, foi criada uma nova extensão [2] que define o método MESSAGE. Este foi criado para poder enviar conteúdos genéricos dentro ou fora do diálogo de uma sessão iniciada com o comando INVITE. No entanto é mais utilizado fora do contexto de uma sessão, facilitando o desenvolvimento de um sistema de mensagens instantâneas entre dispositivos. Este método é denominado de conversação emPAGE MODE, em contraste com a conversação em SESSION MODE, que é definido através de uma sessão iniciada com um INVITE em que o SDP deste faz a negociação de uma sessão Message Session Relay Protocol (MSRP)[3]. Através desta são depois transmitidos dados das mensagens entre os utilizadores.
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18
Watson, come here.
Listagem 2.4: Exemplo de uma mensagem instantânea enviada com o comando MESSAGE [2]
Outra extensão criada em 2003, foi a definição do método REFER para permitir que uma aplicação dê in-struções a outro cliente ou servidor na rede sobre o que fazer no contexto de um diálogo.[26] Incluindo oheader Refer-To num pedido REFER, um utilizador pode por exemplo iniciar uma transferência de chamada, informando a aplicação de uma pessoa com a qual esteja em chamada que deve iniciar uma chamada para a pessoa referida. Essa aplicação deve, com a autorização do utilizador, enviar um INVITE para o contacto referenciado, iniciando assim uma nova chamada. Outra utilização deste método é a inclusão de mais pessoas numa sessão de con-versação, em que uma aplicação cliente pode enviar um comando REFER para o servidor que esteja a gerir a sessão, informando-o do contacto para o qual deve enviar um INVITE para inserir essa pessoa na conversa.
2.2 Sessões de média
Quando um utilizador aceita a criação da sessão que foi proposta, ambas as aplicações envolvidas estabelecem sessões de média utilizando para isso os IP’s e portas negociados. Estas sessões não têm de ser
mente para a transmissão de voz ou vídeo, mas este foi o objectivo inicial da criação deste protocolo, e é essa a utilização que mais aplicações lhe dá.
Qualquer que seja o tipo de sessão a criar, a sua negociação é feita através da inclusão de SDP[16] nos comandos usados na fase da sinalização. Este formato foi definido inicialmente para a negociação de Codecs e portas a utilizar numa chamada de voz, mas é hoje em dia utilizado por exemplo para a criação de sessões MSRP[3].
INVITE sip:bob@biloxi.example.com SIP/2.0 To: <sip:bob@biloxi.example.com>
From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU
Content-Type: application/sdp c=IN IP4 atlanta.example.com m=message 7654 TCP/MSRP * a=accept-types:text/plain a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp SIP/2.0 200 OK To: <sip:bob@biloxi.example.com>;tag=087js From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp c=IN IP4 biloxi.example.com m=message 12763 TCP/MSRP * a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
ACK sip:bob@biloxi SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU
Listagem 2.5: Exemplo da negociação de uma sessão MSRP[3]
O protocolo MSRP baseia-se na troca de pequenos pacotes de dados de qualquer tipo entre aplicações. É normalmente usado para a troca de ficheiros ou mensagens de texto, mas pode ser usado para troca de dados estruturados proprietários de uma dada entidade.
Ao contrário do SIP, o protocolo MSRP não tem obrigatoriamente respostas relacionadas com um dado pedido. Estas podem existir dependendo daquilo que cada pacote pedir, e no caso de existir resposta, esta pode ser respetiva a um ou a vários pacotes enviados. Existem dois tipos de respostas sendo que os ACKs servem para informar que um dado pacote chegou ao ponto de rede seguinte, e os REPORTs informam sobre a chegada ou não de um pacote ou de um conjunto de pacotes ao destino.
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
![Figura 2.4: Esquema do enquadramento do WebRTC na rede[38]](https://thumb-eu.123doks.com/thumbv2/123dok_br/17753150.834637/44.892.285.553.371.588/figura-esquema-do-enquadramento-do-webrtc-na-rede.webp)
