wit communications application server plataforma...

WIT Communications Application Server

Plataforma interoperável para a convergência

das telecomunicações WIT Software

2010 / 2011

21160264 Luís Gonçalo Henriques de Matos

Mestrado em Informática e Sistemas

Ramo de Desenvolvimento de Software

Setembro 2011

Orientador ISEC: Professor Doutor João Cunha

Supervisor Externo: Engenheiro Frederico Lopes

v

“Bem aventurado o homem que encontra a sabedoria, e o homem

que adquire conhecimento, pois ela é mais proveitosa do que a

prata, e dá mais lucro do que o ouro.”

Provérbios 3:13 e 14

vii

À minha querida Mãe, Maria, em especial, que me tem

encaminhado e acompanhado ao longo da vida e dos momentos,

a quem devo tudo aquilo que hoje sou, pelos seus exemplos de

coragem e perseverança, à minha namorada, Ilanna, pelo amor,

paciência, compreensão, carinho e apoio durante esta jornada.

A vocês,

dedico

WCAS - Plataforma interoperável para a convergência das telecomunicações

ix

Agradecimentos

À minha família, pelo amor incondicional, apoio e incentivo na realização deste

projecto.

À minha namorada Ilanna, pelo seu amor, compreensão e paciência durante essa

jornada.

Aos meus amigos, que durante todo este tempo me acompanharam e me transmitiram

força e confiança.

Ao Professor Doutor João Cunha, o meu especial agradecimento, pela orientação,

acompanhamento e pelos excelentes conselhos que sempre me deu.

Ao Bruno Carvalho e ao Nuno Campos, pela paciência e dedicação na passagem de

conhecimento para que pudesse prosseguir com este projecto.

Ao Frederico Lopes, pelas orientações de gestão e pelo acompanhamento dado ao

longo de todo o projecto.

Ao Pedro Pereira, pelas instruções técnico-estratégicas dadas nos momentos

decisivos.

À WIT Software, por ter aceitado, apostado e confiado no meu trabalho.

E por último, mas não menos importante, a toda a família WIT que, de um modo

geral, criou todas as condições para que este projecto fosse possível.


xi

Resumo

Este documento descreve o trabalho realizado por Luís Matos no âmbito do estágio do

Mestrado em Informática e Sistemas, Ramo de Desenvolvimento de Software. O

estágio decorreu na WIT Software e teve duração de 10 meses.

O Rich Communication Suite (RCS) é uma iniciativa da GSM Association (GSMA)

que conta com o esforço colaborativo da indústria de telecomunicações, com mais de

100 operadoras, fornecedores de equipamentos e empresas de telecomunicações, com

o objectivo de facilitar a introdução no mercado de aplicações móveis e a prestação de

serviços que forneçam uma experiência de comunicação avançada, interoperável e

convergente. O RCS define serviços e aplicações que introduzem listas de contactos

que mostram dinamicamente a mudança de status de presença e as possibilidades de

comunicação, e dispõe de diferentes opções de conversação.

A WIT Software desenvolveu o WIT Communications Application Server (WCAS),

um servidor inserido no WIT Communications Suite (WCS), destinado a fornecer

serviços tanto a aplicações cliente como outros servidores na rede de uma operadora

de telecomunicações. Devido à sua flexibilidade e modos de funcionamento pode

integrar-se com a rede de telecomunicações bem como com os serviços já existentes

na rede, estabelecendo e garantindo todas as comunicações necessárias entre

aplicações cliente e servidores.

Para garantir a interoperabilidade do WCAS com clientes e servidores numa rede de

telecomunicações que siga os standards do RCS, foi necessário desenvolver e evoluir

diversos módulos do WCAS para que este fique dotado dos meios necessários para

poder ser integrado com quaisquer servidores e clientes de outras empresas que

respeitem os mesmos standards. Foram realizados os testes de interoperabilidade

definidos pelo RCS com recurso a servidores externos que seguem o mesmo standard

e a clientes tanto do WCS como de outras empresas.

Palavras Chave (Tema): RCS, Telecomunicações Móveis, Interoperabilidade

Palavras Chave (Tecnologias): Java, Spring, Netty, SailFin, OCCAS, Wowza


xiii

Abstract

This document introduces the work done by Luís Matos within the scope of the Master

in Informatics and Systems, Software Development Branch. The internship took place

at WIT Software during the past 10 months.

The Rich Communication Suite (RCS) is a GSM Association (GSMA) initiative,

which relies on the collaborative effort of the telecommunications industry, with over

100 mobile operators, device manufacturers and telecommunications companies,

which aims to facilitate the rapid adoption of mobile applications and services

providing an interoperable, convergent and rich communication experience. RCS

defines services and applications that introduce contact lists showing dynamically

changing of status and on-line capabilities and offers different messaging options.

WIT Software developed the WIT Communications Application Server (WCAS), a

server platform included in the WIT Communications Suite (WCS), intended to

provide services to both client applications and other servers on a network of a

telecom operator. Due to its flexibility and operating modes, it can be integrated with

the telecommunications network and with existing services, providing and ensuring

all the necessary communications between clients and servers.

To ensure WCAS interoperability with clients and servers in a telecommunications

network that follows the RCS standards, it was necessary to develop and fit out

various WCAS modules so that it is endowed to be integrated with any server and

client from other companies that comply with the same standards. The interoperability

tests defined by RCS were performed using external servers that follow the same

standards, and by application clients both from WCS and from other companies.

Keywords (Subject): RCS, Mobile Telecommunications, Interoperability

Keywords (Technologies): Java, Spring, Netty, SailFin, OCCAS, Wowza


xv

Índice

Agradecimentos ............................................................................................................ ix

Resumo ......................................................................................................................... xi

Abstract .......................................................................................................................xiii

Índice ........................................................................................................................... xv

Índice de Figuras ....................................................................................................... xix

Índice de Tabelas ....................................................................................................... xxi

Notação e Glossário .................................................................................................xxiii

1 Capítulo I - Introdução ......................................................................................... 1

1.1 Enquadramento ..................................................................................................... 1

1.2 Objectivos .............................................................................................................. 3

1.3 Motivação ............................................................................................................... 6

1.4 Riscos ...................................................................................................................... 6

1.4.1 Projecto ......................................................................................................................... 7

1.4.2 Negócio ......................................................................................................................... 8

1.5 Organização do relatório ...................................................................................... 8

2 Capítulo II - Rich Communication Suite ............................................................. 9

2.1 Introdução.............................................................................................................. 9

2.2 O que é o RCS ...................................................................................................... 10

2.3 A motivação ......................................................................................................... 12

2.4 Como está organizado ......................................................................................... 12

2.4.1 Release 1 ..................................................................................................................... 12

2.4.2 Release 2 ..................................................................................................................... 17

2.4.3 RCS-e .......................................................................................................................... 20

2.5 Empresas intervenientes ..................................................................................... 23


xvi

2.6 Concorrentes ........................................................................................................ 25

3 Capítulo III - Requisitos ..................................................................................... 29

3.1 Módulo de Chat ................................................................................................... 30

3.1.1 Enhanced Messaging ................................................................................................... 30

3.1.2 File Transfer................................................................................................................ 30

3.1.3 Image Share ................................................................................................................ 30

3.2 Módulo de Capabilities ........................................................................................ 32

3.3 Outros requisitos ................................................................................................. 32

3.3.1 High Availability ......................................................................................................... 32

3.3.2 Integração na plataforma existente ............................................................................... 33

3.4 Roadmap ............................................................................................................... 33

4 Capítulo IV - Metodologia de trabalho .............................................................. 37

4.1 Processo ................................................................................................................ 37

4.2 Sprints ................................................................................................................... 37

4.3 Monitorização ...................................................................................................... 37

4.4 Planeamento ........................................................................................................ 40

4.5 Equipa de projecto .............................................................................................. 41

4.6 Validação e Testes ............................................................................................... 42

4.7 Gestão da Informação ......................................................................................... 43

5 Capítulo V - Tecnologia e Protocolos ................................................................. 45

5.1 Tecnologia ............................................................................................................ 45

5.2 Protocolos ............................................................................................................. 47

6 Capítulo VI - Arquitectura .................................................................................. 49

7 Capítulo VII - Resultados ................................................................................... 51

8 Capítulo VIII - Conclusões ................................................................................. 53

8.1 Objectivos realizados .......................................................................................... 53

8.2 Trabalho futuro ................................................................................................... 55

8.3 Lições aprendidas ................................................................................................ 55


xvii

Bibliografia .................................................................................................................. 57

Anexo 1 Competitors Analysis ............................................................................... 61

Anexo 2 WCAS Detailed Design ........................................................................... 63

Anexo 3 WCAS Chat Protocol .............................................................................. 65

Anexo 4 WCAS Chat Module Performance Report ............................................. 67


xix

Índice de Figuras

Figura 1 - Cenário WWC ↔ WCAS ↔ WWC. _____________________________________________4

Figura 2 - Cenário WWC ↔ WCAS ↔ Servidor SIP Externo ↔ WPC. _________________________5

Figura 3 - Cenário WWC ↔ WCAS ↔ WPC. _____________________________________________5

Figura 4 - Gráfico Hours Burndown with Cumulative Flow._________________________________38

Figura 5 - Gráfico Workitem Cumulative Flow.___________________________________________39

Figura 6 - Product Backlog. __________________________________________________________40

Figura 7 - Sprint Backlog. ___________________________________________________________41

Figura 8 – Branch, merge e tag (release) do projecto. _____________________________________43


xxi

Índice de Tabelas

Tabela 1 - Concorrentes do WCAS. ____________________________________________________26

Tabela 2 - Roadmap das etapas e iterações do projecto. ____________________________________33

Tabela 3 - Features implementadas por release. __________________________________________36

Tabela 4 - Equipa de projecto. ________________________________________________________41


xxiii

Notação e Glossário

3GPP 3rd Generation Partnership Project

API Application Programming Interface

BANIF Banco Internacional do Funchal

BCP Banco Comercial Português

CDMA Code Division Multiple Access

CGD Caixa Geral de Depósitos

CPIM Common Presence and Instant Messaging

EAB Enhanced Address Book

EDP Energias de Portugal

F2S Flash To SIP

GSMA Global System for Mobile Communications Association

HTTP Hypertext Transfer Protocol

I&D Investigação e Desenvolvimento

IDE Integrated Development Environment

IM Instant Messaging

IMS IP Multimedia Subsystem

IP Internet Protocol

IPTV Internet Protocol Television

J2ME Java Platform Micro Edition

JAIN Java APIs for Integrated Networks

JDBC Java DataBase Connectivity

JSR Java Specification Request

LTS Long Term Support


xxiv

MMS Multimedia Messaging Service

MMSC Multimedia Messaging Service Center

MSISDN Mobile Subscriber Integrated Services Digital Network Number

MSRP Message Session Relay Protocol

NAB Network Address Book

NIO New Input Output

OCCAS Oracle Communications Converged Application Server

OMA Open Mobile Alliance

PC Personal Computer

PSTN Public Switched Telephone Network

RCE Rich Communication Ecosystem

RCS Rich Communication Suite

RDBMS Relational DataBase Management System

RIA Rich Internet Application

SDP Session Description Protocol

SIMPLE Session Initiation Protocol for Instant Messaging and Presence

Leveraging Extensions

SIP Session Initiation Protocol

SMS Short Message Service

SMSC Short Message Service Center

SVN Subversion

SWQ Software Quality

TCP Transmission Control Protocol

TV Television

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunications System


xxv

WCAS WIT Communications Application Server

WCS WIT Communications Suite

WMC WIT Mobile Communicator

WPC WIT PC Communicator

WWC WIT Web Communicator

XCAP XML Configuration Access Protocol

XDMS XML Document Management Server

XML Extensible Markup Language

Z2M2 Zero Bugs, Zero Delays, Maximum Productivity, Maximum

Customer Satisfaction


Luís Gonçalo Henriques de Matos 1

1 Capítulo I - Introdução

Este capítulo faz um enquadramento do estágio, apresentando os objectivos, a

motivação para realizar este projecto e um breve resumo sobre a WIT Software, o

Rich Communication Suite e o WIT Communications Application Server.

1.1 Enquadramento

O estágio a que o presente relatório se refere foi realizado no WIT-Lab -

departamento de I&D da WIT Software [1]. A WIT Software é uma empresa de

software que desenvolve aplicações e serviços avançados na área das

telecomunicações móveis. A empresa foi criada em 2001, tem Headquarters em

Coimbra, dois centros de desenvolvimento, no Porto e Leiria, um escritório em Lisboa

e uma filial em San Jose (California, US) para desenvolvimento de negócio.

A empresa está organizada em 3 unidades de negócio:

1. Telco - Esta unidade faz desenvolvimento de software para operadoras de

telecomunicações móveis e tem clientes na Europa, Estados Unidos e África.

A unidade é ainda responsável pelo produto WIT Communications Suite, uma

solução de software para convergência das comunicações móveis,

comunicações fixas e da Internet;

2. Mobile - Esta unidade dedica-se ao desenvolvimento de aplicações para

terminais móveis nas seguintes plataformas: iPhone/iPad, Android,

Blackberry, J2ME, Symbian. A unidade tem vários clientes na área da banca

(BCP, CGD, BANIF), na área dos media (Impresa e Controlinveste) assim

como alguns clientes internacionais, como é o caso da TomTom e da Real

Networks;

3. Digital TV - Esta unidade é responsável pelo desenvolvimento de uma

plataforma de widgets para TV cujo target são operadoras de cabo e IPTV.

Tem clientes na Europa e Estados Unidos e tem expertise em desenvolvimento

de software para Microsoft Mediaroom e OpenTV.

A empresa tem uma forte ligação à Universidade de Coimbra e por este motivo é uma

empresa com grande competência para actividades de I&D. O WIT-Lab é responsável



por inovar, idealizar e exceder as expectativas para gerar novas soluções que possam

trazer valor para o mercado.

O WIT Communications Suite é um dos produtos desenvolvidos na empresa. Esta

suite é composta por diferentes aplicações para diferentes plataformas:

WIT PC Communicator;

WIT Web Communicator;

WIT Mobile Communicator;

WIT Toolbar Communicator.

As aplicações acima listadas são as aplicações clientes. A juntar a estas existe o WIT

Communications Application Server (WCAS) que é um servidor de telecomunicações

e é onde este estágio se foca. Este servidor é composto por um conjunto de módulos

que permite fornecer serviços às aplicações do WIT Communications Suite (WCS)

assim como a outras que sigam os mesmos standards. O desenvolvimento do servidor

WCAS foi feito tendo em conta as normas existentes para que fosse possível

integrá-lo com outros sistemas, como por exemplo, Short Message Service Center

(SMSC), Multimedia Messaging Service Center (MMSC), Media Gateway,

Authentication Server e Billing Systems.

O Rich Communication Suite (RCS) é uma iniciativa da GSM Association (GSMA)

que conta com o esforço colaborativo da indústria de telecomunicações, com mais de

100 operadoras, fornecedores de equipamentos e empresas de telecomunicações, com

o objectivo de facilitar a introdução no mercado de aplicações móveis e a prestação de

serviços que forneçam uma experiência de comunicação avançada, interoperável e

convergente. O RCS define serviços e aplicações que introduzem listas de contactos

que mostram dinamicamente a mudança de status de presença e as possibilidades de

comunicação, e dispõe de diferentes opções de conversação. A GSMA baseia-se nas

normas definidas pela Open Mobile Alliance (OMA), uma organização de

normalização que desenvolve open standards para a indústria de telecomunicações

móveis. A partir destes standards foram adoptadas um conjunto de features,

simplificadas outras e excluídas as restantes, criando assim as várias versões do RCS.

Com o aparecimento do RCS houve a intenção de tornar o WCAS compliant com

este. Para isso foi necessário implementar novos módulos e adaptar alguns já



existentes de modo a garantir a interoperabilidade do WCAS com clientes e

servidores numa rede de telecomunicações que siga os standards descritos na

iniciativa RCS. O WCAS ficou dotado dos meios necessários para poder ser integrado

com quaisquer outros servidores e clientes de outras empresas que respeitem os

mesmos standards. Foram realizados os testes de interoperabilidade definidos pelo

RCS com recurso a servidores externos que seguem o mesmo standard e a clientes

tanto do WCS como de outras empresas.

1.2 Objectivos

O objectivo da WIT Software é tornar o WCAS compliant com o RCS, do mesmo

modo que algumas aplicações do WCS já o são. Como para alcançar este objectivo

era necessária a implementação de diversos módulos e a modificação de alguns já

implementados, para este estágio foi definido como objectivo a implementação do

Módulo de Chat. Este módulo representava uma importante meta a atingir pela WIT

Software e já abrangia diversas features do RCS (Enhanced Messaging, File Transfer

e Image Share), além de que permitia que o WCAS pudesse suportar mais um

protocolo de media, o protocolo Message Session Relay Protocol (MSRP), que é um

dos protocolos utilizados nas comunicações entre aplicações cliente e servidores RCS.

No decorrer do estágio foi adicionado aos objectivos a implementação do Módulo de

Capabilities. Este módulo, que é bastante mais simples que o Módulo de Chat, iria

tratar uma feature que está definida no RCS-e (uma extensão ao RCS). Este objectivo

foi introduzido dado o grande interesse da WIT em ser também compliant com o

RCS-e e por as tendências das operadoras de telecomunicações estarem a convergir

primeiro para RCS-e e só depois para RCS.

O WCAS tem a capacidade de comunicar com todas as aplicações da WCS e de

colocá-las a comunicar umas com as outras. Nem todas elas usam os mesmos

protocolos, pelo que o fluxo de comunicação de uma aplicação até à outra passa por

diversas camadas de tradução dentro do WCAS. A aplicação WIT Web Communicator

(WWC) é um softphone1 e o protocolo de comunicação é diferente dos restantes, neste

caso proprietário da WIT, pois foi desenvolvido internamente (consultar Anexo 3 -

1 Um softphone é um software que permite fazer chamadas através da Internet, utilizando um

computador em vez de utilizar hardware dedicado (telefone).



WCAS Chat Protocol). Dado que esta aplicação é totalmente dependente do WCAS

e sendo também intenção de torná-la compliant com o RCS, o protocolo de

comunicação devia ser desenvolvido considerando os requisitos definidos pelo RCS.

O WCAS tem dois modos de funcionamento:

F2S - Flash-to-SIP, onde o WCAS funciona como uma gateway e permite que

o WWC comunique com clientes SIP, nomeadamente clientes RCS. O WCAS

assume o comportamento de um “cliente” para outros servidores SIP;

Standalone - O WCAS assume o comportamento de um servidor

independente, aceitando ligações de clientes RCS ou outro tipo de clientes que

implementem as normas definidas no servidor.

O grande módulo que faltava no WCAS e que devia ser implementado era o Módulo

de Chat, que seguia a especificação OMA SIMPLE IM session mode. Este módulo foi

o ponto central do estágio e devia ser implementado de modo a permitir a

comunicação entre todas as aplicações do WCS. Isto implicava a implementação de

várias camadas de tradução para que o WCAS pudesse operar tanto no modo F2S

como Standalone. Dada a combinação destas possibilidades o trabalho foi dividido

em três cenários:

Comunicação WWC ↔ WCAS ↔ WWC - Desenvolvimento do Módulo de

Chat apenas orientado para clientes WWC. Implementação da camada de

tradução para clientes Flash e as funcionalidades necessárias no core do

WCAS;

RTMP

RTMP

WIT Web CommunicatorWIT Web Communicator WCASWCAS

WIT Web CommunicatorWIT Web Communicator

WIT Software Domain

Figura 1 - Cenário WWC ↔ WCAS ↔ WWC.



Comunicação WWC ↔ WCAS ↔ Servidor SIP Externo ↔ WPC -

Implementação de uma camada de tradução para o WCAS se poder comportar

como “cliente” para um servidor SIP (modo WCAS F2S). Esta camada de

tradução incluía SIP e MSRP;

SIPMSRP

SIPMSRP

External SIP ServerExternal SIP Server

RTMP


WIT PC CommunicatorWIT PC Communicator

WIT Software Domain

Figura 2 - Cenário WWC ↔ WCAS ↔ Servidor SIP Externo ↔ WPC.

Comunicação WWC ↔ WCAS ↔ WPC - Implementação de uma camada

de tradução para o WCAS poder aceitar ligações de clientes SIP directamente

a ele (modo WCAS Standalone).

SIPMSRP

RTMP


WIT PC CommunicatorWIT PC Communicator

WIT Software Domain

Figura 3 - Cenário WWC ↔ WCAS ↔ WPC.

Este módulo devia ser preparado para funcionar tendo em conta um subsistema de

High Availability, que iria permitir que o Módulo de Chat estivesse preparado para

uma instalação numa rede onde estariam presentes outras instâncias do WCAS a

funcionar em cluster. Isto iria tornar o WCAS mais robusto, escalável e tolerante a

falhas.



1.3 Motivação

A iniciativa RCS teve início a 16 Maio de 2007 e é apoiada pelos principais players

da indústria de telecomunicações. Estes incluem operadoras de telecomunicações,

fornecedores de serviços de rede e de dispositivos móveis (consultar capítulo 2.5 -

Empresas intervenientes para ver a lista de empresas).

Estando o mercado a convergir para esta iniciativa e tendo a WIT já uma linha de

produtos que abrange as mais diversas opções de comunicação, isso representa a

oportunidade de alargar e consolidar a sua presença no mercado das

telecomunicações, tanto a nível nacional como internacional. Nesta linha de produtos

está presente o WCAS que já cumpre alguns dos requisitos definidos pelo RCS, no

entanto segue algumas especificações diferentes. Seguir as especificações definidas

pelo RCS representa a oportunidade de estar de acordo com uma iniciativa a nível

mundial e onde ainda existem poucas soluções a nível de servidores RCS.

Ser compliant com o RCS permite que o WCAS possa servir não só qualquer

aplicação cliente que siga a mesma norma, mas também representa a possibilidade de

poder ser integrado numa rede IP Multimedia Subsystem (IMS) de uma operadora. O

WCAS foi desenhado desde o início para poder funcionar tanto em standalone como

numa rede IMS, que seguem protocolos específicos para que todos os sistemas

presentes sejam interoperáveis.

1.4 Riscos

Como qualquer projecto de software também este esteve sujeito a alguns riscos. Esta

secção apresenta aquilo que representava um risco para o projecto e que, de certo

modo, poderia afectar ou comprometer o seu desenrolar. São apresentadas também as

estratégias adoptadas para gerir e lidar com cada um dos riscos.

Os riscos foram divididos em duas categorias: Projecto e Negócio. No projecto serão

considerados os riscos que estão directamente relacionados com o projecto e com o

estágio. No negócio serão considerados os riscos que afectariam directamente os

objectivos estratégicos da empresa.



1.4.1 Projecto

Área das telecomunicações

A área das telecomunicações é relativamente complexa e lida com diversas situações

para garantir o bom funcionamento do fluxo de uma comunicação. Como o projecto

insidia directamente nesta área e como ela era praticamente desconhecida por mim, no

início do projecto isto representou um risco considerável. Durante o projecto procurei

aprender alguns temas e práticas relacionadas com o desenvolvimento deste tipo de

servidores. À medida que o tempo passou e o projecto avançou este risco acabou por

se dissipar.

Definição de requisitos

A especificação RCS é composta por uma documentação extensa e complexa de ler e

compreender. Depreender os requisitos para os clientes já é uma tarefa difícil, deduzir

o que é necessário para o servidor é ainda mais. É necessário além de perceber a

comunicação com as aplicações cliente, perceber a implementação do requisito na

arquitectura do servidor. No início do projecto foi de facto complicado e apenas com

alguma ajuda de pessoas mais experientes foi possível perceber melhor os requisitos e

assim defini-los claramente.

Estimativas

Estimar é uma tarefa difícil, estimar aquilo que ainda não se conhece, além de difícil

está sujeito a uma taxa de erro muito grande. Mais uma vez esta foi uma tarefa difícil

que se manteve durante grande parte do projecto. De modo a minimizar o erro,

sempre procurei decompor uma tarefa em tudo aquilo que era necessário fazer para

ela estar concluída, só que nem sempre isto era possível fazer sem antes começar a

implementar algo, pois apenas aí era possível determinar as restantes tarefas que eram

necessárias fazer. Apesar disso os prazos dados inicialmente não foram muito

diferentes daquilo que foi estimado inicialmente, apesar de em determinadas alturas

ocorrer algum overwork.



1.4.2 Negócio

Time-to-market

O tempo que um software leva a ser introduzido no mercado pode ser determinante

para o seu sucesso, pois se esse tempo for muito longo pode haver o risco de ser

ultrapassado pela concorrência. No início dos projectos os concorrentes são poucos,

mas com o passar do tempo o número de concorrentes tende a aumentar e torna-se

mais complicado ganhar uma posição. Durante o projecto foi sempre partilhada muita

informação entre a equipa WCS. Esta informação muitas vezes incluía novidades

sobre o RCS e sobre os concorrentes. Isto foi muito útil, pois permitiu ter

conhecimento de como estava a evoluir o mercado e a concorrência.

Dinâmica do mercado

Este risco acaba por afectar mais o estágio do que o próprio projecto. Os mercados

são dinâmicos e a empresa onde foi feito o estágio também. Isto representa um risco

porque nem sempre o objectivo que se tem agora é igual daqui a uns meses, fazendo

com que a empresa ajuste o seu foco. Isto de facto verificou-se, no entanto, o foco da

empresa não mudou radicalmente, apenas ficou mais direccionado, como foi o caso da

inclusão do RCS-e no roadmap, que não estava previsto inicialmente.

1.5 Organização do relatório

Este relatório encontra-se organizado em oito capítulos, focando cada um deles um

assunto específico do estágio. O Capítulo I (o presente capítulo) faz uma introdução

do âmbito do estágio e resume do que este se trata. No Capítulo II é feita a

apresentação do RCS e da convergência das telecomunicações. No Capítulo III são

apresentados os requisitos do RCS e do estágio e é apresentado o roadmap. O

Capítulo IV detalha a metodologia e os processos seguidos ao longo do estágio. O

Capítulo V fala sobre toda a tecnologia e protocolos que foram utilizados no estágio.

No Capítulo VI é apresentada a arquitectura do WCAS, sendo apresentada não só uma

visão de alto nível, mas também os detalhes de implementação. O Capítulo VII

apresenta os testes de performance realizados ao WCAS. Por último, o Capítulo VIII

apresenta as conclusões sobre o estágio.



2 Capítulo II - Rich Communication Suite

As informações apresentadas neste capítulo foram obtidas através de pesquisas

efectuadas na Internet, leitura de notícias e artigos relacionadas com a convergência

das telecomunicações e leitura da documentação disponível sobre o RCS.

2.1 Introdução

A área das telecomunicações passou por diversas fases de evolução ao longo do

tempo e nos últimos anos revolucionou principalmente com aquilo que oferecia [2].

No início das telecomunicações existia um número reduzido de dispositivos que

permitia realizar comunicações simples, as comunicações eram apenas de voz e com

uma qualidade reduzida [3]. Como tudo era feito com base na mesma feature, as

normas e os standards utilizados eram reduzidos, o que permitia uma fácil

interligação e entendimento entre os diversos dispositivos existentes. À medida que os

dispositivos foram evoluindo a qualidade das features existentes foi sendo melhorada

e foram aparecendo outras features [4]. Esta evolução trouxe a necessidade de

interoperabilidade entre os diferentes tipos de dispositivos, com diferentes

capacidades, para que pudessem ser utilizados em simultâneo e realizassem

comunicações entre si.

Esta evolução também tem feito com que a forma como se queira iniciar uma

comunicação passe a ser de maneira diferente e a partir de algo diferente. Os

utilizadores querem ser capazes de comunicar, aceder e partilhar informação em

qualquer lugar, a qualquer hora e a partir de qualquer dispositivo ligado a uma rede de

telecomunicações [2] [5]. Têm aparecido novos dispositivos ao longo de diversas

gerações e muitos deles têm-se mantido até aos dias de hoje, permitindo a

coexistência de várias tecnologias de comunicação. Isto obrigou a que houvesse um

entendimento entre fornecedores de equipamentos e operadoras de telecomunicações

para permitir o funcionamento em simultâneo de diversos dispositivos distintos.

Com o passar do tempo e com a disponibilidade da banda larga móvel e a

convergência das telecomunicações, surgiram dispositivos mais poderosos e com

capacidade de executar funções como voz e vídeo de alta qualidade. Um conjunto de

opções de comunicação que anteriormente estavam limitadas à interface de um

computador estão agora disponíveis nos dispositivos móveis e em outros dispositivos



de comunicação, como por exemplo, uma TV [4] [6]. Aplicações multimédia, troca de

ficheiros, mensagens instantâneas, presença e redes sociais estão a tornar-se tão

comuns nos dispositivos móveis como o SMS e o MMS.

Estes dispositivos trouxeram novas formas de entendimento de modo a poderem

interagir com os já existentes. A componente multimédia destes dispositivos fez com

que a utilização das suas funcionalidades se expandisse para todos os dispositivos

com ligação a uma rede de comunicações. O mercado das telecomunicações evoluiu

para dimensões que vão para além das tradicionais comunicações com telefones e

telemóveis. Hoje em dia as comunicações podem ser feitas tanto a partir de um

telefone tradicional, um softphone ou mesmo uma TV [7]. Por detrás destas soluções

está um circuito de servidores que, de segmento em segmento de rede, vai

convertendo tecnologias de modo a tornar a comunicação possível.

2.2 O que é o RCS

O Rich Communication Suite é uma iniciativa da GSMA que conta com o esforço de

um grupo de players da indústria de telecomunicações com um objectivo comum: a

rápida adopção de aplicações móveis e prestação de serviços que forneçam uma

experiência de comunicação avançada, interoperável e convergente. A iniciativa RCS

inclui operadoras de telecomunicações, fornecedores de serviços de rede e de

dispositivos móveis. Esta iniciativa usa uma metodologia iterativa para disponibilizar

um conjunto de features coerentes, normas de implementação, casos de uso,

demonstrações e experimentações, tendo em conta as implementações de referência

para a interoperabilidade, baseada nos actuais standards e especificações. Os

resultados do RCS destinam-se a ser fornecidos como inputs para as entidades do

sector, de forma a serem considerados como uma especificação de referência.

O RCS define um conjunto de features avançadas que podem ser iniciadas a partir do

Enhanced Address Book (EAB). O EAB (uma evolução do livro de endereços

tradicional) permite saber as possibilidades de comunicação de um contacto e

juntamente com a informação de presença que também está disponível no EAB

consegue-se melhorar a experiência do utilizador e promover a utilização das features.

A abordagem do RCS não comtempla a definição de novas features, mas sim a

agregação e exploração de features standard de modo que possa ser feita uma oferta

mais eficiente e equilibrada.



O RCS utilizada a arquitectura IP Multimedia Subsystem para possibilitar a integração

das features e para que estas sejam interoperável entre diferentes fornecedores de

serviços. As features RCS podem ser utilizadas tanto em dispositivos móveis como

fixos e são interoperáveis entre estes dois ambientes de rede. Das várias features

existentes, a presença é aquela que desempenha o papel fundamental no RCS, pois é

ela que permite determinar as possibilidades de comunicação de um contacto e isso é

um factor essencial para despoletar o uso das restantes features.

A interoperabilidade é vital para o RCS, pois sem features que funcionem

transversalmente aos dispositivos e às redes os utilizadores terão pouco incentivo para

as utilizar. A interoperabilidade comercial entre fornecedores e operadoras de

telecomunicações é um dos objectivos a serem alcançados com esta iniciativa. Outro

objectivo do RCS é proporcionar uma framework comum para um serviço que é

interoperável entre operadoras de telecomunicações e dispositivos. O RCS não define

as suas próprias especificações, mas explora as especificações standard existentes,

por exemplo, a 3rd Generation Partnership Project (3GPP) e a Open Mobile Alliance

(OMA). Desde o início que o RCS deu prioridade à interoperabilidade tanto entre

dispositivos como entre redes. Somente com esta abordagem se consegue assegurar

uma interoperabilidade plena de comunicação.

Para acelerar e facilitar a introdução das features, os participantes da iniciativa RCS

agiram das seguintes formas:

Definiram um conjunto features, aproveitando os standards e normas de

implementação existentes, criando assim um conjunto de comunicações

interoperáveis baseadas em IMS. O IMS é uma arquitectura importante para

trazer estas features para o consumidor de forma interoperável;

Desenvolveram implementações de referência do RCS para dispositivos

comerciais e validaram os requisitos base e as especificações técnicas para

garantir a interoperabilidade de serviços;

Criaram testes de interoperabilidade, realizados entre múltiplos fornecedores,

para garantir e verificar a maturidade das features RCS.

O RCS não especifica a implementação da interface dos dispositivos, apenas se centra

nos requisitos de interconexão e interoperabilidade necessários de modo a definir as

features para um conjunto de comunicações avançadas. Não é intenção do RCS criar



novos standards, em vez disso pretende especificar um conjunto de features que

podem ser implementadas utilizando standards já existentes.

2.3 A motivação

Hoje em dia os utilizadores precisam de saber qual a plataforma de conversação que

os seus contactos utilizam (Windows Live Messenger, Skype, etc.) e para estabelecer

contacto com eles é necessário utilizar credenciais específicas da aplicação. O RCS

permite conversações apenas com base na informação do número de telefone, que já

está armazenada no livro de endereços e faz com que os utilizadores possam

interligar-se de forma mais fácil.

Serviços e aplicações que introduzem listas de contactos que mostram dinamicamente

a mudança de status de presença e as possibilidades de comunicação, diferentes

opções de conversação e a possibilidade de agregar conteúdos, são apenas alguns

exemplos desta experiência de comunicação. Os consumidores podem ter a certeza de

que estes recursos não estão disponíveis apenas num PC, mas também num

dispositivo móvel e que existe uma comunicação plena entre dispositivos e redes.

Com o RCS as operadoras de telecomunicações podem satisfazer as expectativas dos

clientes e continuar a apresentar serviços cada vez mais evoluídos com base nas

exigências dos consumidores.

2.4 Como está organizado

O trabalho da iniciativa RCS está dividido numa sequência de esforços

progressivamente publicados como releases. De seguida são apresentadas a release 1,

a release 2 e uma evolução do RCS, o RCS-e (enhanced),

2.4.1 Release 1

Na release 1 estão definidas as features base que fazem parte do RCS. Cada uma

destas features dispõe de um conjunto de características que aprimoram a interacção

com o utilizador. Esta release é composta pelas seguintes features:

Enhanced Address Book;

Content Sharing;

o Video Share;



o Image Share;

File Transfer;

Enhanced Messaging.

2.4.1.1 Enhanced Address Book

O Enhanced Address Book (EAB) é uma evolução do livro de endereços tradicional.

Com base na informação tradicional de um contacto (por exemplo, nome e MSISDN),

fornece informação avançada sobre os contactos existentes. O EAB é um elemento

fundamental do RCS e permite que os utilizadores façam uso das seguintes features:

Saber informações das possibilidades de comunicação dos contactos;

Iniciar comunicações;

Efectuar chamadas de voz e vídeo;

Efectuar transferência de ficheiros;

Enviar mensagens;

Publicar as informações de presença com atributos de texto e multimédia;

Emitir um alerta de hyper-availability com tempo limitado aos contactos

autorizados;

Capacidade de incluir elementos multimédia, por exemplo, uma fotografia do

contacto;

Publicar informação de presença para contactos autorizados;

Convidar e autorizar utilizadores a partilhar as informações de presença de

forma recíproca;

Permitir aos utilizadores adicionar um contacto a uma lista de contactos

bloqueados (blacklist) para evitar a partilha de informações de presença com

esses contactos e deixar de receber novos convites para a partilha de

informações de presença;

Permitir aos utilizadores aceder facilmente aos contactos avançados;

Mostrar informações de presença e conteúdos relacionados a cada um dos

contactos avançados;



Ser notificado das actualizações das informações de presença e alertas de

hyper-availability feitos pelos contactos avançados;

Beneficiar de um histórico por contacto incluindo todos os tipos de

comunicação;

Permitir efectuar pesquisas tanto localmente no livro de endereços pessoal

como em outros recursos externos;

Assegurar o backup e sincronização do Address Book com o Network Address

Book, que pode ser executada automaticamente, permitindo uma sincronização

transparente em diferentes dispositivos do utilizador.

O Network Address Book (NAB) é fundamental para oferecer as features do EAB,

uma vez que oferece um repositório para armazenar os contactos do utilizador, que é

acessível a partir de múltiplos dispositivos.

O EAB dispõe das seguintes features:

Presença;

Enriched Contacts List;

Service Capability Indication.

Presença

A presença é vista como um pedaço de informação para os contactos, para que eles

possam saber o que o utilizador está a fazer, o seu estado de espírito, a

disponibilidade, entre outras informações relacionadas com o utilizador. Ao utilizador

é dada a possibilidade de publicar informações pessoais que formam a sua informação

de presença. Como ilustração, o grupo de contactos com os quais foi estabelecida uma

relação de presença pode ser visto como os contactos mais próximos de um

determinado utilizador (amigos, familiares, colegas, etc.).

A informação de presença não substitui o contacto vCard2 do livro de endereços

tradicional. O nome do contacto e outras informações não sofrerão qualquer impacto e

toda a informação de presença é controlada pelo utilizador.

2 vCard é um formato standard para cartões de visita electrónicos. Costumam estar associados às

mensagens de e-mail, mas podem ser enviados pela Internet ou através de IM. Contêm informações de



Tendo sido estabelecida uma relação de presença com um determinado contacto, a

informação de presença passará a ser visível a partir do EAB. Também é visível a

partir de outros lugares do dispositivo, por exemplo, nos logs de comunicações

efectuadas ou pastas de mensagens.

Enriched Contacts List

De modo a facilitar o controlo sobre os contactos que têm acesso à informação de

presença do utilizador, é possível ter um acesso directo e diferenciado aos contactos

com os quais foi estabelecida uma relação de presença. Há um acesso aprimorado no

EAB que exibe tanto a presença dos contactos avançados como dos contactos

tradicionais. Os contactos com presença são claramente identificados, por exemplo,

apresentando alguns atributos da presença, como a fotografia, free text, etc. É possível

ter uma visão detalhada de um contacto com presença, onde os atributos relevantes

das informações de presença são exibidos.

Service Capability Indication

As possibilidades de comunicação que podem ser mostradas para o utilizador são:

Video Call;

Image Sharing;

Video Sharing;

File Transfer;

Chat.

A indicação das possibilidades de comunicação pode ser disponibilizada para todos os

contactos no livro de endereços, sem a necessidade de estabelecer uma relação de

presença. Por exemplo, um contacto no livro de endereços pode não ser de uma

pessoa conhecida, mas se ele tiver um dispositivo RCS, as possibilidades de

comunicação podem ser conhecidas de modo a poder estabelecer uma comunicação

avançada com esse contacto. Esta informação também permite que os utilizadores

saibam que contactos podem ser convidados a partilhar informações de presença.

contacto como nome, morada, números de telefone, endereços de e-mail, URLs, logotipos, fotografias

e clipes de áudio.



2.4.1.2 Content Sharing

É a capacidade que os utilizadores têm de trocar diferentes tipos de conteúdo durante

uma sessão, normalmente uma chamada de voz, mas não exclusivamente. Os

conteúdos partilhados durante uma chamada de voz podem ter um outro fluxo em

transmissão ao mesmo tempo. Cada vez que uma chamada de voz for estabelecida o

utilizador tem a possibilidade de partilhar conteúdos.

Esta feature pode ser iniciada por ambas as partes, tanto quem iniciou como quem

recebeu a chamada. Quando um utilizador inicia a partilha de conteúdos é enviado um

convite para o outro contacto, que pode ser aceite ou rejeitado. Caso seja aceite, esta

aceitação persistirá para todos os conteúdos partilhados durante a chamada. O

receptor tem a possibilidade de guardar o conteúdo partilhado no dispositivo. Os

conteúdos partilhados podem ser tanto de imagem como vídeo.

2.4.1.3 File Transfer

É a capacidade que os utilizadores têm de trocar diferentes tipos de ficheiros, durante

uma sessão em curso ou sem ter uma sessão em curso. As sessões podem ser

chamadas de voz ou chat. Esta feature pode ser iniciada tanto por quem inicia como

por quem recebe a chamada ou o pedido de chat. O receptor pode aceitar ou rejeitar os

ficheiros oferecidos e, caso aceite, tem a possibilidade de guardar os ficheiros que são

transferidos no dispositivo.

2.4.1.4 Enhanced Messaging

O Enhanced Messaging tira partido dos números de identificação única (MSISDN),

ao contrário dos serviços de mensagens típicos de Internet. Além de serviços de SMS

e MMS um dispositivo RCS também oferece ao utilizador um serviço de chat.

Os MMS e principalmente os SMS são serviços já muito bem estabelecidos e que

existem no dia-a-dia dos utilizadores. O chat não é um substituto destes serviços de

mensagens, mas sim um serviço paralelo com os seus próprios valores. Esses valores

podem ser exemplificados por meio de conference chats, alertas vibratórios,

conteúdos multimédia, informação de “is typing” e incorporando a transferência de

ficheiros.



Chat

Um dispositivo compatível com RCS, além do suporte para os métodos de mensagens

tradicionais, oferece ao utilizador um serviço de chat. O serviço de chat pode ser

usado no modo um para um, em que apenas dois utilizadores estão em conversação,

ou no modo de conference chat, com vários utilizadores ao mesmo tempo em

conversação entre si.

Em termos de RCS só é possível utilizar o chat com dispositivos RCS ou com outros

dipositivos que suportem OMA SIMPLE IM session mode. As mensagens que são

trocadas entre os utilizadores podem conter texto ou conteúdo multimédia.

2.4.2 Release 2

A release 2 explora e melhora as features da versão anterior, possibilitando a

utilização das mesmas a partir de vários de dispositivos. Enquanto a release 1 definia

apenas um dispositivo em utilização ao mesmo tempo, a release 2 define a utilização

de vários dispositivos pelo mesmo utilizador ao mesmo tempo. Estes dispositivos

podem ser, por exemplo, um telemóvel e um computador.

As features que fazem parte da release 2 são:

Broadband Access to RCS features;

Multi-device environment;

Network Address Book;

Provisioning and configuration of RCS devices/clients.

2.4.2.1 Broadband Access to RCS features

Os utilizadores RCS poderão utilizar as features de comunicação avançada em

dispositivos que utilizem ligações de banda larga, por exemplo, um PC ou um portátil.

Um utilizador poderá ter diferentes tipos de clientes RCS ligados simultaneamente e

que utilizem diferentes tipos de acesso à rede (banda larga ou a rede da operadora) e

pode iniciar uma feature RCS a partir de qualquer um deles. Clientes RCS de

diferentes operadoras poderão comunicar entre si. Aqui é necessário que a

infra-estrutura de rede das operadoras seja interoperável. Um cliente RCS release 1

também conseguirá realizar comunicações com um cliente RCS release 2.



2.4.2.2 Multi-device environment

Como a release 2 introduz o suporte para dispositivos de acesso através de banda

larga, permite que os utilizadores usem as features RCS, por exemplo, a partir de um

PC. A combinação habitual para utilizar as features RCS pode ser o cliente ter um

dispositivo móvel e um dispositivo de acesso através de banda larga. Além desta

combinação outras serão possíveis no futuro, como por exemplo, uma TV.

O ambiente Multi-device permite ao utilizador:

Atender uma chamada ou responder a uma mensagem a partir do dispositivo

que melhor se adapte ao efeito;

Ter uma única lista de contactos partilhada entre os vários dispositivos;

Ser capaz de autorizar convites para partilhar informações de presença a partir

de cada dispositivo;

Ter uma única informação de presença que pode ser vista e mantida a partir de

cada dispositivo que o utilizador tiver.

O modo de funcionamento geral será quando um utilizador tiver vários dispositivos

em utilização e for feita uma chamada ou enviada uma mensagem. Esta chamada ou

mensagem será enviada para todos os dispositivos e cada um irá alertar para esse

acontecimento. O utilizador poderá então responder a partir do dispositivo que melhor

lhe convier. Quando o utilizador aceitar ou rejeitar num dos dispositivos, todos os

restantes irão terminar o alerta.

2.4.2.3 Network Address Book

O objectivo do Network Address Book (NAB) é fornecer um mecanismo centralizado

e uniforme para os utilizadores administrarem as informações dos contactos numa

rede RCS. No geral o NAB é um repositório de contactos que é implementado e

administrado na rede da operadora.

A partir do Enhanced Address Book os utilizadores podem criar informações de

contactos nos dispositivos móveis RCS e depois fazer upload dos dados para o NAB.

Estas informações são propriedade do utilizador, são mantidas por este e somente ele

pode modificar ou apagar as informações dos contactos. Depois de um utilizador fazer



upload destas informações para o NAB, pode mais tarde sincronizar com outro

dispositivo RCS, como um PC ou outro dispositivo com acesso de banda larga.

2.4.2.4 Provisioning and configuration of RCS devices/clients

Não se espera que o utilizador final tenha de configurar manualmente as definições

para poder utilizar as features RCS num dispositivo. Assim que o dispositivo for

ligado será registado na rede e todas as features RCS estarão disponíveis sem

qualquer acção do utilizador. Isto aplica-se a dispositivos móveis e fixos, incluindo

aqueles com acesso através de banda larga. Também se aplica tanto às features da

release 1 como às da release 2.

São transparentes para o utilizador as configurações relacionadas com a IMS, pontos

de acesso, tamanho máximo permitido para File Transfer, etc. Na verdade, estes

parâmetros devem ser configurados pela operadora e, geralmente, bloqueados a

alterações por parte do utilizador final a fim de evitar erros de configuração

indesejados nas features RCS. No entanto, deve haver a possibilidade de configurar

algumas definições (SIP, XDMS) que podem ser necessárias para aceder a alguma

feature quando, por exemplo, se mudar de operadora.

De modo a permitir que as features RCS sejam de certa forma transparentes para o

utilizador, as seguintes definições são configuradas no dispositivo:

Definições de IMS Core/SIP para registo na rede e realização de

comunicações básicas;

Definições de XDMS;

Definições de presença;

Configurações do Network Address Book para efectuar backups, restauro e

sincronização de contactos;

Definições de IM para o chat;

Configurações de File Transfer;

Parâmetros RCS específicos, por exemplo, tamanho máximo permitido para

File Transfer;

Parâmetros específicos de dispositivos de acesso à rede através de banda larga,

por exemplo, o MSISDN do utilizador.



Algumas das configurações listadas acima têm uma influência directa na experiência

do utilizador. Por exemplo, os parâmetros específicos de RCS incluem o número

máximo de caracteres do free text nas informações de presença. Desta forma o

utilizador irá ser sempre informado sobre esse limite ao digitar o conteúdo do free

text, evitando assim que o texto seja truncado quando for entregue a outro contacto.

Outros exemplos são o tamanho máximo permitido para o Portrait icon, também nas

informações de presença, ou para um ficheiro a ser transferido. A interface do

utilizador deve incluir informações sobre esse limite, fazendo com que o utilizador

saiba que nem todo o conteúdo multimédia pode ser usado nesses contextos.

2.4.3 RCS-e

O RCS-e (enhanced) é uma optimização das features de voz e texto da release 1 e 2,

que permite aos utilizadores enviar mensagens instantâneas, efectuar chamadas,

partilhar vídeo e fazer transferência de ficheiros em tempo real, de modo simples e

interoperável.

Apesar do desenvolvimento interessante do RCS, cinco das principais operadoras

europeias, a Deutsche Telekom, a Orange, a Telecom Italia, a Telefonica e a Vodafone

anunciaram no Mobile World Congress de Fevereiro de 2011, planos para lançar uma

versão melhorada do RCS, conhecido como RCS-e, no final de 2011 ou início de

2012. Com base nos princípios de interoperabilidade estabelecidos dentro do

ecossistema das operadoras móveis, a especificação RCS-e, chamada RCS-e

Advanced Communications, proporciona uma optimização das especificações da

release 1 e 2, de modo a acelerar o tempo de entrada no mercado e simplificar a oferta

ao cliente. Resumidamente, o RCS-e proporciona uma “simples e interoperável

extensão para voz e texto hoje em dia" [8].

Este novo foco no RCS é baseado nos resultados dos testes com clientes em features

RCS, de modo a compreender melhor onde as operadoras podem aumentar a sua

oferta de serviços oferecendo assim mais valor aos clientes.

O aparecimento do RCS-e trouxe consigo uma nova designação para toda a iniciativa

RCS, que foi o RCE (Rich Communication Ecosystem), que pretende representar o

RCS 2.0 e o RCS-e, e a interoperabilidade entre ambos.



2.4.3.1 Princípios RCS-e

O mecanismo fundamental do RCS-e é a feature Capability Discovery. Por exemplo,

quando um utilizador percorre os seus contactos e selecciona um contacto RCS-e, a

aplicação cliente realiza uma verificação das possibilidades de comunicação do

contacto, sendo assim capaz de mostrar as features que estão disponíveis para

comunicar.

Este pedido é encaminhado para o destinatário e pode ter dois tipos de resposta:

1. O contacto está registado e as possibilidades de comunicação, no momento em

que é efectuado o pedido, são guardadas pelo utilizador que efectuou o pedido;

2. O contacto não está registado ou não existe.

Este mecanismo para determinar as possibilidades de comunicação é importante na

medida em que permite que um utilizador saiba quais os serviços que estão

disponíveis antes de serem utilizados.

2.4.3.2 Conformidade

A conformidade do dispositivo com a especificação RCS-e pode resumir-se no

seguinte:

Suporte para registo na rede da operadora;

Obtenção das possibilidades de comunicação de um utilizador através dos

mecanismos de SIP OPTIONS e ANONYMOUS fetch;

Suporte para chat;

Suporte opcional para File Transfer, Image Share e Video Share.

A razão para fazer do File Transfer, Image Share e Video Share opcionais é facilitar a

penetração das features RCS-e em todos os tipos de dispositivos. Posteriormente um

dispositivo RCS-e suportará todas as features RCS-e que sejam viáveis, tendo em

conta as limitações de hardware e software. De qualquer modo uma operadora de

rede que implemente a especificação RCS-e deve suportar File Transfer, Image Share

e Video Share ao nível da rede.



2.4.3.3 Chat

O chat permite aos utilizadores trocar mensagens entre um ou mais utilizadores

instantaneamente. No RCS-e o chat é uma feature de referência, disponível para

qualquer utilizador registado e usa o OMA SIMPLE IM session mode como

especificação base. À medida que foram introduzidas novas features foram feitos

alguns ajustes e modificações necessárias na especificação base do RCS.

O RCS-e trouxe as seguintes alterações a nível de features relativamente às releases 1

e 2 do RCS:

Remoção da Presença - Nas releases 1 e 2 do RCS as features só podiam ser

utilizadas se fosse possível saber a presença de um contacto. Com o RCS-e

esta feature foi retirada e passa a ser possível utilizar qualquer feature mesmo

desconhecendo a presença do contacto;

Capability discovery - É uma nova feature que permite determinar quais as

possibilidades de comunicação de um contacto antes de iniciar qualquer tipo

de comunicação. Na release 1 e 2 apenas era determinar as possibilidades de

comunicação quando um contacto tinha presença;

Store and Forward - É uma nova feature mas que a sua implementação é

critério da operadora. Requer que o Chat Server tenha a capacidade de

armazenar uma mensagem quando o utilizador de destino não está online e

enviá-la para ele quando ele voltar a estar novamente online;

Displayed Message Disposition - Esta nova feature permite que o remetente

seja notificado quando uma mensagem que enviou for exibida no dispositivo

do utilizador que a recebeu. Esta notificação não garante que a mensagem

tenha sido lida pelo utilizador, apenas indica que a mensagem foi exibida no

dispositivo do destinatário;

Local Black List - Uma nova feature que define que o dispositivo deve

permitir armazenar localmente uma lista de contactos bloqueados;

Conversation History - Uma nova feature que define que o dispositivo deve

permitir armazenar localmente o histórico de uma conversação;



User Alias - É uma nova feature que permite que o utilizador defina um nome

que pode ser enviado enquanto se estabelece uma comunicação com outro

utilizador.

2.5 Empresas intervenientes

A iniciativa RCS já conta com mais de 100 operadoras, fornecedores de equipamentos

e empresas de telecomunicações. Abaixo encontra-se a lista de empresas que já

aderiram a esta iniciativa.

Mobile Operators

AT&T

Bell Mobility

Bouygues Telecom

China Mobile

China Unicom

China Telecom

E-Mobile

France

Telecom/Orange

KDDI

KTF

Mobilkom Austria

NTT

NTT DoCoMo

Optus SingTel

SFR

SK Telecom

Smart

SoftBank

Swisscom

Telecom Italia Mobile

Telecom New Zealand

Telefonica O2

Telekom Srbija

Telenor

Tele2 Sweden

TeliaSonera

Telstra

TMN

T-Mobile

Verizon Wireless

Videotron

Wind

Messaging Operators

Belgacom International

Carrier Services

Mach

Sybase

Syniverse Technologies

Infrastructure

suppliers

Acision

Aicent

Acme Packet

Airwide Solutions

Alcatel-Lucent

Almira Labs

Aylus

Broadsoft

Cicero Networks

Comverse

Ericsson

Fujitsu

Gemalto



Genband

Huawei

IBM

IntelliNet Technologies

Iwatsu Electric

Mavenir

Nable Communications

NeuStart

Nokia Siemens

Networks

OKI Electric Industry

Openmind Networks

OptiMobile

Sonus Networks

Starent

Tatara Systems

Tekelec

uReach

ZTE

724 Solutions

Handset manufacters

Hitachi

LG

Motorola

NEC

Nokia

Sagem Wireless

Samsung

Sony Ericsson

Toshiba

Software developers

Be Tomorrow

Colibria

CommuniGate Systems

Comneon

Ecrio

Eyeball

EyeP Media

Genaker

Inexbee

Inspirit

MailVision

OnMobile (Voxmobili)

NeuSoft Mobile

Solutions

Smith Micro Software

Summit Tech

Solaiemes

Telcoware

WIT Software

Test laboratories

Fraunhofer Institute

Fokus

Mera Networks

Octopus Network

Setcom Wireless

Products

Other

Symbian



2.6 Concorrentes

As informações sobre este tipo de servidores não são de conhecimento público,

principalmente quando são soluções comerciais. Estas são habitualmente transmitidas

e negociadas directamente com as operadoras que pretendem adquirir um produto

deste tipo, pelo que a informação pública é muito escassa.

Como o WCAS se encontra inserido dentro do WCS não faria sentido analisar apenas

os concorrentes do servidor, deste modo, foi conduzido um estudo inicial sobre os

concorrentes dos principais produtos do WIT Communications Suite (WCS): WIT PC

Communicator (WPC), WIT Web Communicator (WWC) e WIT Mobile

Communicator (WMC), que facilitou a identificação dos concorrentes do WCAS. Os

concorrentes foram identificados com base na solução apresentada e nas features que

os produtos do WCS também têm ou que está previsto virem a ter. Com base nisto

foram identificados dois tipos de concorrentes:

Concorrentes directos - Empresas que têm objectivos comuns ou soluções

que apresentam as mesmas features que os produtos do WCS e que concorrem

no mesmo mercado;

Concorrentes indirectos - Empresas ou soluções que não concorrem

directamente com os produtos do WCS, pois têm um público-alvo diferente,

mas que poderão concorrer quando os produtos do WCS forem integrados nas

operadoras, estando a concorrer também com as operadoras.

O facto de o WCAS poder operar tanto no modo F2S como no modo Standalone, faz

com que encontre vários concorrentes distintos. Há empresas que desenvolveram

soluções que operam de modo semelhante ao WCAS F2S e outras de modo

semelhante ao WCAS Standalone. Há algumas que têm uma solução conjunta,

agregando tudo num só produto, sendo estas fortes concorrentes do WCAS, pois

também ele é uma solução conjunta. Apesar de existirem diversas soluções que

possam de certo modo concorrer com o WCAS, pelo menos a nível de Web

Softphones, nem todas elas estão vocacionadas para a incitava RCS, no entanto, são

considerados concorrentes dado que apresentam soluções semelhantes.

Na Tabela 1 encontram-se listadas, por ordem de importância, as soluções que devido

às suas características se aproximam do objectivo do WCAS ou que estão de certo



modo ligadas à iniciativa RCS. Para uma lista completa dos concorrentes do WCS

deve ser consultado o Anexo 1 - Competitors Analysis.

Tabela 1 - Concorrentes do WCAS.

Empresa Solução

Sta

ndalo

ne

F2S

Ericsson IMS Multimedia Telephony ●

Nokia Siemens Networks MSC Server System ●

Alcatel Lucent 5400 IMS Application Server ●

Huawei IP Telephony Solution ●

Colibria RCS Application Servers ●

Summit Summit ● ●

Solaiemes RCS Thin Client Server ●

Solaiemes RCS Solution Gateway ●

Aylus Media Platform ●

Microsoft Lync ●

Telepo Business Communication Server ● ●

CommuniGate Systems CommuniGate Pro Server ●

British Telecom Ribbit ● ●

De seguida é apresentada uma breve descrição de cada uma das soluções listadas na

Tabela 1.



Ericsson - IMS Multimedia Telephony [9]

Solução IMS que oferece serviços tanto de telecomunicações tradicionais como de

telecomunicações multimédia. Possui uma arquitectura escalável que permite

adicionar novos serviços aos já existentes.

Nokia Siemens Networks - MSC Server System [10]

Solução que apresenta uma arquitectura distribuída e que faz o controlo de chamadas,

sinalização e media. Permite que cada um dos serviços seja direccionado para

entidades dedicadas e de alto débito optimizando assim o fluxo das comunicações.

Alcatel Lucent - 5400 IMS Application Server [11]

Application Server que oferece um ambiente configurável para fornecer serviços de

convergência entre as telecomunicações tradicionais e a Internet. Pode ser instalado

tanto numa rede IMS como não IMS.

Huawei - IP Telephony Solution [12]

Solução unificada para voz, vídeo e dados numa rede IMS. Permite fazer a transição e

agregação entre as telecomunicações tradicionais e as telecomunicações IP.

Colibria - RCS Application Servers [13]

Solução que dispõe de diversos serviços independentes, altamente escaláveis e

modulares para Presence, Messaging e Address Book.

Summit - Summit [14]

Solução bastante completa que permite a integração com redes IMS e RCS e tem uma

solução idêntica a cada um dos produtos do WCS. Compete com o WCAS nos dois

modos de funcionamento.

Solaiemes - RCS Thin Client Server [15]

Plataforma RCS que permite a criação de clientes RCS em diferentes plataformas sem

necessidade de implementar protocolos de telecomunicações específicos, utilizando

apenas protocolos de Internet e API. Pode ser integrado com redes IMS e RCS.

Solaiemes - RCS Solution Gateway [16]

Plataforma de convergência entre soluções para a web e infra-estruturas de

telecomunicações. É interoperável com redes IMS e RCS.



Aylus - Media Platform [17]

Plataforma de media que é compatível com HTTP, SIP, IMS e RCS. Permite media

transcoding em tempo real.

Microsoft - Lync [18]

Plataforma corporativa que permite a interligação transparente de diversas tecnologias

e utiliza várias features e protocolos definidos pelo RCS.

Telepo - Business Communication Server [19]

Solução muito completa, apresentando uma solução idêntica a cada um dos produtos

do WCS, quer a nível de clientes quer a nível de servidor.

CommuniGate Systems - CommuniGate Pro Server [20]

É uma gateway que direcciona os pedidos vindos de diversos tipos de clientes para

servidores específicos. Suporta protocolos específicos do RCS.

British Telecom - Ribbit [21]

Solução que começou por ser apenas uma plataforma e neste momento oferece

soluções tanto a nível de clientes como de servidor. Compete com o WCAS nos dois

modos de funcionamento.



3 Capítulo III - Requisitos

Os requisitos deste projecto incidiram principalmente sobre as features da release 1

do RCS e um pouco sobre as do RCS-e. O objectivo de alto nível do projecto era a

implementação de um novo módulo, o Módulo de Chat. Este módulo iria comtemplar

a maioria das features que estão definidas na release 1, no entanto, tem alguns ajustes

na release 2. No decorrer do estágio foi introduzindo nos objectivos a implementação

do Módulo de Capabilities, que iria comtemplar algumas das features do RCS-e.

Os requisitos detalhados do Módulo de Chat encontram-se na documentação oficial

do RCS e da OMA. Esta documentação define tanto os requisitos funcionais como os

técnicos. Neste capítulo será apresentado um resumo dos requisitos que faziam parte

dos objectivos numa vertente mais funcional e um resumo do que foi necessário

implementar no WCAS para desenvolver o Módulo de Chat e o Módulo de

Capabilities.

A documentação oficial do RCS e da OMA pode ser consultada nos seguintes

endereços:

RCS (RCS Release 1 Updates e RCS Release 2 Updates - February 2011)

http://www.gsmworld.com/our-work/mobile_lifestyle/rcs/rcs_release_docs.htm

RCS-e

http://www.gsmworld.com/documents/rcse_spec_v1.1_final.zip

OMA (Instant Messaging using SIMPLE)

http://www.openmobilealliance.org/Technical/release_program/simple_im_v1_0.aspx

http://www.gsmworld.com/our-work/mobile_lifestyle/rcs/rcs_release_docs.htm


http://www.openmobilealliance.org/Technical/release_program/simple_im_v1_0.aspx



3.1 Módulo de Chat

Dada a semelhança entre as features do Enhanced Messaging, File Transfer e Image

Share, todas elas foram agregadas no Módulo de Chat.

3.1.1 Enhanced Messaging

Este serviço implica a implementação de um novo módulo no WCAS, o Módulo de

Chat. O serviço de chat deve poder ser usado tanto no modo de um para um, em que

apenas dois utilizadores estão em conversação, como no modo de conference chat,

com vários utilizadores em simultâneo. O RCS define a utilização do protocolo MSRP

para a transferência de dados e para a sinalização define o protocolo SIP.

3.1.2 File Transfer

Deve ser possível a transferência de ficheiros durante uma sessão de chat ou chamada

ou mesmo sem ter uma sessão em curso, sendo também possível o envio de vários

ficheiros em simultâneo entre os mesmos utilizadores. Também aqui devem ser

usados os protocolos SIP e MSRP.

3.1.3 Image Share

O serviço de Image Share permite que os utilizadores partilhem imagens durante uma

chamada de voz ou vídeo que está em curso. Este requisito tem algumas semelhanças

com o anterior, no entanto, apenas pode ser usado durante uma chamada. Usa os

mesmos protocolos que o File Transfer.

Para a implementação destas features no WCAS são necessários os seguintes

desenvolvimentos:

Definição de um protocolo de comunicação entre WWC e o WCAS e a sua

implementação no WCAS;

Implementação do core do serviço de Chat, File Transfer e Image Share;

Implementação de uma camada de tradução para Flash;

Implementação de extensões à camada de tradução SIP, no modo F2S (RFC

3261, 3265, 3515, 4028, 4353, 4488, 4566, 4575, 4579, 5366, 5368);



Implementação de uma camada de tradução para SIP Servlets, no modo

Standalone (RFC 3261, 3265, 3515, 4028, 4353, 4488, 4566, 4575, 4579,

5366, 5368);

Implementação de uma stack de MSRP e do conceito de MSRP Switch para

utilização tanto no modo F2S como no modo Standalone (RFC 3862, 4975,

4976);

Implementação dos seguintes tipos de sinalização:

o Local - Para utilização com clientes ligados directamente ao WCAS;

o Proxied - Para utilização no modo F2S;

o Conference - Para utilização em Conference Chats.

Implementação dos seguintes tipos de media:

o Flash para Flash - Para transferência de dados apenas entre clientes

WWC;

o Flash para MSRP e MSRP para Flash - Para transferência de dados

entre clientes WWC e clientes WPC ou WMC;

o MSRP para MSRP - Para transferência de dados apenas entre clientes

WPC e WMC;

o Bypass MSRP - Para permitir que os clientes WPC e WMC possam

estabelecer sessões de transferência de dados em peer-to-peer, ou seja,

sem utilizar o WCAS como intermediário;

o Conference - Para utilização quando se estiver perante uma sessão de

Conference Chat, entre qualquer tipos de cliente;

o Flash para Flash em internode - Para permitir a transferências de

dados entre clientes Flash que estejam ligados em nodes diferentes,

quando estiver a ser utilizado o subsistema de High Availability.



3.2 Módulo de Capabilities

Este módulo é o responsável por gerir a feature Capability discovery, uma vez que

determina as possibilidades de comunicação de um contacto independentemente de

este ter presença ou não. Utiliza o protocolo SIP para a sua implementação e apenas

deve ser usado entre cliente WPC e WMC.

A implementação deste serviço implicou os seguintes desenvolvimentos no WCAS:

Implementação do core do serviço de Capabilities;

Implementação de uma camada de tradução para SIP Servlets, no modo

Standalone (3261, 3265, 4028, 4566);

Implementação de mecanismos de relay para determinação das possibilidades

de comunicação.

3.3 Outros requisitos

3.3.1 High Availability

De modo a preparar o WCAS para um cenário de crescimento, mantendo a sua

confiabilidade, este deve ser suficientemente escalável, tolerante a falhas e totalmente

transparente para os utilizadores, ou seja, o módulo de chat deve estar preparado para

ser instalado num cenário de High Availability. Para que este módulo esteja preparado

para isso deve ser desenvolvido um subsistema que permita que uma instância do

WCAS possa interagir com outras instâncias do WCAS. Para o seu funcionamento

são necessários os seguintes desenvolvimentos:

Implementação de um subsistema de High Availability para o módulo de chat;

Implementação dos seguintes tipos de sinalização no módulo de chat;

o Internode - Para sinalização entre servidores WCAS.

Implementação dos seguintes tipos de media no módulo de chat;

o Flash para Flash - Para transferência de dados apenas entre clientes

WWC em nodes diferentes.



3.3.2 Integração na plataforma existente

Este projecto não ia ser desenvolvido de raiz, era a continuação de um projecto já

existente. Devido a isso, os novos módulos implementados bem como todos os

desenvolvimentos efectuados devem ser perfeitamente integráveis com o sistema já

existente. O módulo de chat deve seguir a arquitectura existente nos restantes

módulos e utilizar, sempre que possível, os mesmos protocolos, as mesmas

tecnologias e as mesmas API já utilizadas no projecto.

3.4 Roadmap

Este projecto culminou com a release 3 do WCAS e o seu desenvolvimento foi

dividido em três grandes etapas, tendo cada etapa várias iterações. Estas etapas foram

definidas de acordo com os objectivos estratégicos da empresa. Na Tabela 2 está o

roadmap e as várias etapas e iterações do projecto.

Tabela 2 - Roadmap das etapas e iterações do projecto.

Etapa Iteração Comple

xidade

Data de

Início e

Fim

WW

C ↔

WC

AS

↔ W

WC

# 1 - Análise

Análise das features RCS, priorização e atribuição

de estimativas.

Média 25-10-2010

05-11-2010

# 2 - Protótipo MSRP

Criação de um protótipo MSRP standalone, segundo

os RFC 4975 e 4976.

Alta 08-11-2010

19-11-2010

# 3 - Conceito Chat Manager

Definição da arquitectura do Módulo de Chat e dos

interfaces de sinalização.

Alta 22-11-2010

22-11-2010

# 4 - Comunicação Chat 1-1

Implementação das interfaces de media para

comunicação entre WWC.

Média 06-12-2010

06-12-2010



WW

C ↔

WC

AS

↔ S

ervid

or

SIP

Exte

rno ↔

WP

C

# 5 - Sinalização Proxied

Implementação da interface de sinalização proxied e

de um SIP User Agent.

Alta 20-12-2010

20-12-2010

# 6 - Inicialização da Stack MSRP

Implementação dos mecanismos necessários para

estabelecer uma sessão de media MSRP.

Alta 03-01-2011

14-01-2011

# 7 - Integração da Stack MSRP

Integração do protótipo MSRP no WCAS e a sua

ligação com a camada de media.

Alta 17-01-2011

28-01-2011

# 8 - Comunicação chat 1-1

Implementação dos comandos necessários para

inicialização de uma comunicação.

Média 31-01-2011

11-02-2011

# 9 - File Transfer

Adaptação das interfaces de sinalização e media

para suporte de File Transfer.

Média 14-02-2011

25-02-2011

# 10 - File Transfer

Adaptação da camada de SIP e suporte para

interpretação e criação do protocolo SDP (RFC

4566).

Média 28-02-2011

11-03-2011

# 11 - Image Share

Adaptação das interfaces de sinalização e media e

do SDP para suporte de Image Share.

Baixa 14-03-2011

25-03-2011

# 12 - Conference Chat

Adaptação das interfaces de sinalização para

inicialização de um conference chat.

Alta 28-03-2011

08-04-2011


Implementação de comandos para actualização do

estado do conference chat.

Alta 11-04-2011

21-04-2011



WW

C ↔

WC

AS

↔ W

PC

# 14 - RCS-e compliance

Definição da arquitectura do Módulo de Capabilities

e da camada de tradução de SIP Servlets.

Alta 26-04-2011

06-05-2011

# 15 - MSRP Switch

Implementação da camada de tradução de SIP

Servlets para o Módulo de Chat e adaptação da

camada de media e MSRP para funcionamento

como um MSRP Switch.

Baixa 09-05-2011

20-05-2011

# 16 - High Availability

Preparação do Módulo de Chat para suportar o

subsistema de High Availability.

Alta 23-05-2011

03-06-2011

# 17 - Testes e estabilização

Revisão de todos os desenvolvimentos efectuados,

realização de testes e correcção de bugs.

Baixa 06-06-2011

17-06-2011

# 18 - Testes de Performance

Preparação de cenários e realização de testes de

performance à camada de media do WCAS.

Média 20-06-2011

01-07-2011

# 19 - Testes de Performance

Realização de testes de performance à camada de

sinalização do WCAS.

Baixa 05-07-2011

15-07-2011


Adaptação da arquitectura para suportar múltiplos

participantes.

Média 01-08-2011

12-08-2011


Adaptação das interfaces de media para estabelecer

um sessão de conference chat.

Baixa 16-08-2011

26-08-2011



Na Tabela 3 encontram-se as várias features da release 1 e 2 do RCS e do RCS-e.

Para cada feature encontra-se indicada a participação efectuada neste projecto.

Tabela 3 - Features implementadas por release.

Release Feature Desenvolvimento

Rel

ease

1

Enhanced Address Book (XDMS) Já desenvolvido

Content Sharing

Video Share Não desenvolvido

Image Share Desenvolvido

File Transfer Desenvolvido

Enhanced Messaging Desenvolvido

Rel

ease

2 Broadband Access to RCS features Não aplicável

Multi-device environment Desenvolvido

Network Address Book Já desenvolvido

Provisioning and configuration of RCS

devices/clients Não aplicável

RC

S-e

Remoção da Presença Não aplicável

Capabilities Discovery Desenvolvido

Store and Forward Participação no

desenvolvimento

Displayed Message Disposition Participação no

desenvolvimento

Local Black List Não aplicável

Conversation History Não aplicável

User Alias Participação no

desenvolvimento



4 Capítulo IV - Metodologia de trabalho

Este capítulo descreve a metodologia, os processos, as práticas e a organização

seguida durante todo o projecto, mostrando as interacções e divisão de

responsabilidades entre a equipa de gestão e a equipa de desenvolvimento.

4.1 Processo

As características do projecto e o facto de, tanto o projecto como a área das

telecomunicações serem totalmente novas para mim, cedo permitiram perceber que

muitas das tarefas apenas conseguiam ser determinadas ao longo do tempo e depois de

realizar algum trabalho. Apesar dos requisitos funcionais serem claros, a sua definição

em termos técnicos era relativamente complexa e por vezes estava dependente da

realização de outros requisitos, o que dificultava a determinação e previsão antecipada

de um roadmap detalhado. Deste modo, as fases de architecture design não eram tão

formais e por vezes ocorriam após as fases de development.

Dadas estas particularidades, foi usada a metodologia Scrum. Esta abordagem ágil é

uma prática comum na WIT Software, nomeadamente no departamento de I&D, pois

permite que o projecto esteja actualizado não só com as tecnologias mas também com

os propósitos estratégicos da empresa e do mercado.

4.2 Sprints

Os Sprints tiveram a duração de 15 dias e no último dia de cada Sprint eram

realizadas as actividades comuns do Scrum: Review; Demo; Planning; Retrospective.

Era feito um overview sobre os objectivos do Sprint e apresentado o trabalho

concretizado, realizando demonstrações práticas. Após isso eram definidos os

objectivos do Sprint seguinte e por fim, e apenas com os developers, eram discutidos

pormenores técnicos de implementação. Durante cada Sprint eram realizadas as

tarefas planeadas no Sprint Backlog e eram registadas as horas dedicadas a cada

tarefa.

4.3 Monitorização

O projecto era monitorizado utilizando duas ferramentas, o Timetracker [22] e o

próprio Sprint Backlog. Para o registo das horas de trabalho diárias era utilizada a

ferramenta Timetracker e semanalmente eram submetidas para a plataforma Weekly



Reports para serem posteriormente analisadas e aprovadas. Durante o Sprint eram

também registadas no Sprint Backlog as horas dedicadas a cada tarefa, sendo para isto

utilizado um ficheiro Excel. A granularidade deste ficheiro era maior do que a do

Timetracker, oferecendo a possibilidade de fazer uma análise de como evoluiu o

trabalho ao longo do Sprint, através dos seguintes gráficos:

Hours Burndown with Cumulative Flow - Este gráfico permite efectuar duas

análises: a típica de um Burndown Chart (progresso do trabalho realizado e o

tempo restante para o fim do Sprint); e a de um Cumulative Flow, que permite

apurar como as tarefas estão a evoluir através dos vários estados (Pending e In

Progress) até estarem terminadas (Complete);

Workitem Cumulative Flow - Este gráfico permite fazer a mesma análise de

um Cumulative Flow, mas é mais específico, focando-se apenas no número de

tarefas terminadas tendo em conta o número que estava inicialmente previsto.

Durante o Sprint Review estes gráficos eram analisados para procurar compreender

como correu o Sprint.

As horas de esforço diárias eram calculadas para 7 horas por dia em vez de 8 horas, o

que perfazia 70 horas por Sprint (considerando 10 dias úteis de trabalho). Esta prática

permitia ter uma margem de segurança de 10 horas para eventuais deslizes nas tarefas

previstas e outras tarefas rotineiras (reuniões, demos pontuais, etc.).

Na Figura 4 pode ser observado um exemplo do gráfico Hours Burndown with

Cumulative Flow de um Sprint com 10 dias úteis de trabalho.

Figura 4 - Gráfico Hours Burndown with Cumulative Flow.



Ao observarmos o gráfico da Figura 4 é possível perceber a evolução do trabalho

realizado ao longo dos dias. Do ponto de vista do Burndown Chart o trabalho restante

andou sempre muito perto do linear, ocorrendo apenas pequenas oscilações, no

entanto, o trabalho não ficou todo terminado. Podemos também verificar que o

número de horas inicialmente previstas não foram as mesmas que as finais, isto

deve-se ao facto de algumas tarefas terem demorado mais tempo do que o estimado e

de terem aparecido novas tarefas que não estavam inicialmente previstas.

Na perspectiva do Cumulative Flow pode-se observar que durante a maior parte do

Sprint houve uma considerável percentagem de tarefas em curso (amarelo) e apenas

ficaram terminadas mais para o fim do Sprint, embora com algum overwork. Esta

quantidade de tarefas em curso, deve-se ao facto de algumas tarefas poderem ser

iniciadas isoladamente, mas para serem terminadas já necessitavam de outras serem

terminadas primeiro. Apesar de o Sprint ter terminado sem nenhuma tarefa em curso,

houve tarefas que não foram sequer iniciadas (cinzento), pelo que transitaram para o

Sprint seguinte. Podemos observar também que o esforço (linha azul) não foi linear ao

longo do Sprint, tendo ocorrido ligeiras oscilações principalmente nos últimos dias.

Na Figura 5 pode ser observado um exemplo do gráfico Workitem Cumulative Flow,

do mesmo Sprint.

Figura 5 - Gráfico Workitem Cumulative Flow.

Observando o gráfico da Figura 5, tem-se uma visão rápida e simples do número de

tarefas Pending (cinzento), In Progress (amarelo) e Complete (verde). Neste Sprint

em particular, houve uma pequena percentagem de tarefas que ficou terminada logo



no início do Sprint, no entanto houve algumas que ficaram em curso durante grande

parte do Sprint, ficando apenas concluídas nos últimos dias. Apesar de não haver

nenhuma tarefa que ficou a meio, houve um pequeno número de tarefas que não

foram realizadas e que transitaram para o Sprint seguinte.

4.4 Planeamento

O planeamento do projecto era feito por duas fases. Na primeira fase os membros da

equipa de gestão definiam as features ao nível do roadmap geral, com um nível de

detalhe muito reduzido e mais orientadas para objectivos estratégicos e de negócio.

Aqui era dada uma estimativa inicial (no Sprint Planning Meeting) para avaliar a

viabilidade das features que se pretendiam realizar. A segunda etapa era mais isolada

e pertencia apenas a quem ia desenvolver. As features eram analisadas em maior

detalhe, sendo divididas em tarefas mais pequenas e mais técnicas. Por vezes era

redefinida a estimativa dada na primeira etapa.

O roadmap geral consistia num ficheiro Microsoft Project, que era acessível a toda a

equipa do WCS. Para analisar as features em maior detalhe era consultado Product

Backlog e o Sprint Backlog. O Microsoft Project era mantido pela equipa de gestão, o

Product Backlog pela equipa de desenvolvimento, mas sob a orientação do Scrum

Master e do Product Owner e o Sprint Backlog era apenas mantido pela equipa de

desenvolvimento.

Na Figura 6 e na Figura 7 encontram-se um exemplo do Product Backlog e do Sprint

Backlog, respectivamente.

Figura 6 - Product Backlog.



Figura 7 - Sprint Backlog.

4.5 Equipa de projecto

Por se tratar de um estágio este projecto funcionou de certo modo isolado (para não

afectar os projectos já em produção) e apenas existiu um developer. Apesar disso,

existiu um conjunto de pessoas que fizeram parte da equipa do projecto, conforme se

pode observar na Tabela 4.

Tabela 4 - Equipa de projecto.

Alias Nome Função Responsabilidades

LM Luís Matos Developer Planeamento de baixo nível e

implementação das features pretendidas.

NC Nuno Campos Tutor Técnico Orientações de modo a garantir que o

projecto alcançava os objectivos.

FL Frederico

Lopes

WCS Product

Owner

Proprietário dos produtos do WCS e

responsável por priorizar as features a

serem implementadas.

PP Pedro Pereira CTO Orientações estratégicas de modo a

alcançar os objectivos de negócio.



4.6 Validação e Testes

Entre apresentações a operadoras, parceiros e congressos, o WCAS esteve presente

em mais de 20 demonstrações. Antes de cada demonstração existia um conjunto de

testes que eram realizados, tanto pela equipa de desenvolvimento como pela equipa de

Software Quality (SWQ) da WIT Software, o que fazia com que periodicamente o

trabalho desenvolvido fosse testado, permitindo que o mesmo estivesse livre de bugs.

Sempre que estava disponível uma nova versão era enviado um Test Request para a

equipa de testes contendo os Test Cases a serem realizados. A equipa de testes

realizava testes funcionais, seguindo uma abordagem do tipo Black Box, até porque

também os Test Specifications3 do RCS assim estavam definidos. Apesar disso, foi

passado algum conhecimento técnico à equipa de testes, principalmente a nível

protocolar, para que esta pudesse ter maior sensibilidade na realização dos testes e

validasse que, além dos requisitos funcionais, também a especificação protocolar

estava a ser respeitada.

Depois de terminados os testes realizados pela equipa de testes, era enviado para os

responsáveis do projecto um Test Report com os resultados obtidos e a lista de bugs

encontrados. Estes bugs eram também disponibilizados na plataforma de Bug

Tracking, o MantisBT [23]. Depois de terminados os testes eram analisados os logs do

servidor pela equipa de desenvolvimento, de modo a compreender o motivo dos bugs

e após a sua correcção o Test Request era novamente executado pela equipa de testes.

Testes unitários

Apesar de o processo de desenvolvimento seguido não ter sido Test-driven, foram

realizados um conjunto de testes unitários às partes mais críticas do projecto, de modo

a garantir que estavam a funcionar correctamente. Foram também testadas as classes

que eram usadas transversalmente ao projecto (helpers), pois apesar de não

interagirem com componentes externos eram utilizados em todo o projecto. Para a

realização dos testes foi utilizada a framework JUnit 4 [24].

3 Os Test Specifications são os testes de interoperabilidade definidos pelo RCS para garantir que um

sistema cumpre todos os standards e que pode funcionar correctamente dentro de um ecossistema RCS.



4.7 Gestão da Informação

Como qualquer outro projecto também este produziu informação que precisava de ser

gerida, organizada e versionada. A plataforma onde era guardada toda a informação

era SVN [25], quer seja para artefactos quer seja para código. No caso do código foi

criado um branch específico para este projecto, de modo a evitar que qualquer

problema pudesse afectar a versão estável do produto. Apenas quando os

desenvolvimentos efectuados neste projecto atingiram maturidade suficiente é que

foram novamente integrados na versão estável do produto. O circuito que o projecto

seguiu pode ser observado na Figura 8.

WCAS 3.0.10

WCAS 3.0.10 + rcse

WCAS 3.1.0

WCAS 3.0.10 + chat

WCAS 3.1.0 - Release

Figura 8 – Branch, merge e tag (release) do projecto.



5 Capítulo V - Tecnologia e Protocolos

Para tornar possível a implementação de todas as features e alcançar os objectivos

pretendidos foi necessário utilizar várias tecnologias distintas, cada uma delas com

uma função específica. Neste capítulo encontram-se listadas as tecnologias e os

protocolos usados e uma explicação sobre cada um.

5.1 Tecnologia

SailFin [26]

É um SIP container baseado na tecnologia SIP Servlets e integrado com o servidor

Java Enterprise Edition GlassFish. Ao estender as funcionalidades deste servidor é

possível atender a funcionalidades de comunicação SIP e aplicações multimédia.

Utiliza o GlassFish como base e dispõe de recursos de configuração, High

Availability, clustering e escalabilidade.

Este SIP Container foi utilizado para fazer a gestão das ligações e das sessões

requests/response com os clientes SIP, e para fazer o parsing dos pedidos SIP para os

objectos Java definidos na SIP Servlet API 1.1.

OCCAS [27]

É um Application Server baseado em SIP, projectado especificamente para ambientes

de grande escala e serviços de comunicação de missão crítica. É a mais poderosa

plataforma de convergência de serviços para operadoras de telecomunicações e

integradores de sistemas.

É uma alternativa ao SailFin, no entanto, no projecto foi utilizado exactamente com os

mesmos propósitos.

Wowza [28]

É um servidor de streaming de áudio e vídeo para RIA que funciona tanto sobre redes

públicas como privadas. O Wowza pode fazer stream com diversos tipos de clientes

em simultâneo, estando entre os mais conhecidos o Adobe Flash, Microsoft Silverlight

e Apple QuickTime.

Foi utilizado de forma semelhante ao SailFin e ao OCCAS mas neste caso para

clientes RTMP. É o responsável por gerir as ligações RMTP entre o WCAS e os



clientes, e as streams de dados dentro de cada ligação. Não faz a gestão de sessões

requests/response nem o parsing para objectos, sendo isso já feito pelo próprio

WCAS.

Netty [29]

O projecto Netty é uma framework baseada em Java NIO que auxilia no

desenvolvimento de aplicações de rede de alto desempenho e de alta escalabilidade.

Fornece uma API event-driven assíncrona, que pode funcionar tanto em TCP/IP como

em UDP/IP e permite a criação de CoDecs serializáveis personalizados, bem como a

compressão de dados e ligações seguras.

O Netty é largamente utilizado devido à sua facilidade de utilização e desempenho

[30], permitindo que o developer se concentre unicamente na implementação dos

requisitos em vez de estar a lidar com implementações comuns de NIO.

Esta framework foi utilizada na implementação do protocolo de media MSRP para

gerir as ligações TCP/IP entre o WCAS e os clientes SIP/MSRP e para fazer o parsing

dos pacotes de dados de MSRP para objectos Java do WCAS.

JUnit [24]

É uma framework que suporta a criação de testes unitários automatizados, facilitando

a criação de código e a apresentação dos resultados dos testes. Com ela consegue-se

garantir que cada método e cada classe funcionam da forma esperada.

Foi utilizado para a criar de testes unitários automatizados às estruturas mais criticas

do WCAS e a classes que eram usadas transversalmente ao projecto.

Spring [31]

É uma framework que simplifica o desenvolvimento de aplicações oferecendo um

conjunto de capacidades para criar e configurar servidores Java, servidores web ou

aplicações empresariais. O core é relativamente pequeno e leve representando assim

um overhead praticamente insignificante. Inclui diversos módulos e funcionalidades,

sendo Dependency Injection, Aspect Oriented e Inversion of Control as mais

importantes.

Esta framework foi utilizada transversalmente no projecto para configurar,

parametrização e garantir a inicialização correcta do WCAS.



JetBrains IntelliJ IDEA [32]

É um dos mais robustos IDE que suporta diversas tecnologias. Pode ser integrado com

vários servidores e sistemas de controlo de versão.

Foi utilizado no desenvolvimento, configuração, testes e sincronização de features do

WCAS.

Wireshark [33]

É um packet analyzer muito usado para examinar pacotes de dados, solucionar

problemas de rede e desenvolver aplicações com protocolos de comunicação.

Foi utilizado para examinar os dados que eram transmitidos entre o WCAS e os

clientes SIP e MSRP.

5.2 Protocolos

SIP/SDP

Session Initiation Protocol e Session Description Protocol são os protocolos

utilizados para a sinalização entre o WCAS e os clientes RCS e redes IMS.

MSRP

Message Session Relay Protocol é o protocolo utilizado para transferir informação

(media) entre o WCAS e os clientes RCS e redes IMS.

CPIM

Common Presence and Instant Messaging é o protocolo utilizado para encapsular as

mensagens transmitidas entre o WCAS e os clientes RCS quando se está num

conference chat.

RTMP

Real Time Messaging Protocol é o protocolo utilizado para transferir informação

(sinalização e media) entre um Flash Media Server (Wowza) e o WCAS.

XCAP

XML Configuration Access Protocol é o protocolo utilizado para armazenar as listas

de contactos dos clientes RCS no WCAS.



6 Capítulo VI - Arquitectura

Este capítulo apresentada a arquitectura do WIT Communications Application Server,

tanto da perspectiva conceptual como técnica. É apresentada a arquitectura modular

que compõe todo o sistema e a forma como o WCAS consegue colocar diferentes

tipos de clientes a comunicar entre si.

O conteúdo deste capítulo contém informações confidenciais e materiais com direitos

de autor pertencentes à WIT Software SA. Por esse motivo, este capítulo encontra-se

exclusivamente no Anexo 2 - WCAS Detailed Design, com acesso restrito.



7 Capítulo VII - Resultados

Este capítulo apresenta e descreve os testes de desempenho realizados ao Módulo de

Chat do WIT Communications Application Server. O objectivo é apresentar as

conclusões dos testes de desempenho, tanto em single node como em multi node

(internode), de modo a fornecer uma referência para dimensionar uma solução para

um ambiente de produção.

O conteúdo deste capítulo contém informações confidenciais e materiais com direitos

de autor pertencentes à WIT Software SA. Por esse motivo, este capítulo encontra-se

exclusivamente no Anexo 4 - WCAS Chat Module Performance Report, com

acesso restrito.



8 Capítulo VIII - Conclusões

8.1 Objectivos realizados

Do ponto de vista do estágio pode-se dizer que os objectivos inicialmente propostos

foram alcançados. Na perspectiva da empresa e do produto ainda há um longo

trabalho pela frente, pois o estágio apenas se concentrou efectivamente na release 1

do RCS e no RCS-e. Apesar disso, foi adicionada uma mais-valia no WCAS e em

todo o WCS, pois a única feature que antes tornava qualquer produto do WCS

dependente de um servidor externo agora está desenvolvida no WCAS, podendo este

agora dar total suporte aos produtos do WCS e tornar esta suite totalmente

independente.

Todo o trabalho que foi desenvolvido é perfeitamente integrável com o já existente e é

útil e proveitoso, tanto que já existe interesse de diversos clientes. Olhando para este

projecto, mais do que um estágio, é seguro dizer que cumpriu os objectivos da

WIT Software: Zero Bugs, Zero Delays, Maximum Productivity, Maximum Customer

Satisfaction (Z2M2).

Zero Bugs

Pode ser demasiado pretensioso dizer que não existiram bugs no trabalho

desenvolvido, porque de facto existiram, mas num número notavelmente reduzido e

que provocaram um impacto muito residual. Todo o software tem bugs e durante a

fase de desenvolvimento eles existiram e deram bastante trabalho para resolver, mas

uma vez dada como finalizada uma feature e disponibilizada para utilização e testes,

os bugs reportados foram de facto poucos.

Zero Delays

Isto podia ser um dos pontos que podia não cumprir os objectivos da WIT Software,

devido à grande dificuldade em dar estimativas, tanto mais que foi referido como um

risco. Apesar de algumas tarefas transitarem entre Sprints por não terem sido

terminadas a tempo, isto representou um impacto pequeno na feature acabando por

não afectar o roadmap geral. Mais do que cumprir o prazo da feature era preciso

cumprir o roadmap, pois era esse que era visível para os clientes. Sempre houve um

grande esforço para cumprir os prazos e para isso também houve um grande cuidado



na altura de dar estimativas, para não criar expectativas e depois correr o risco de não

conseguir cumprir os prazos ou então de entregar uma feature não testada e muito

susceptível de conter bugs.

O WCAS esteve presente em mais de 20 demonstrações sendo que cerca de 90%

foram internacionais. Em todas elas ficou terminado o que estava previsto para a

demonstração e apenas em uma das demonstrações, a primeira, não foi possível estar

presente pois não estava concluído a tempo. De facto era praticamente impossível

estar presente, dado que o prazo era irrealista e estaria fora desse prazo por um largo

período de tempo.

Maximum Productivity

É um pouco mais complicado e subjectivo avaliar esta métrica, no entanto, ela está

directamente relacionada com as anteriores. De um modo geral considero que ela foi

cumprida, mas apenas a partir de uma determinada fase do projecto. Nos primeiros

meses a produtividade foi realmente baixa, pois foi uma fase de adaptação ao

projecto, à empresa e aos costumes e tudo isso requer tempo e não tem qualquer

retorno útil. O facto de ser uma área nova para mim, envolvida por uma

documentação complexa e difícil de ler e de ser a continuação de um projecto grande

e altamente estruturado, fez com que os primeiros meses no projecto servissem apenas

para “aprender” e não para produzir.

Com o passar do tempo a produtividade começou a equilibrar e a partir de certa altura

considero que ela se encontrava em padrões bastante aceitáveis, até porque as duas

métricas anteriores falam por si e apesar de o overwork ser uma constante ao longo do

projecto (típico na área de desenvolvimento de software), sempre foi possível ter o

que estava previsto no momento que estava previsto.

Maximum Customer Satisfaction

O WCAS não é fácil de “ver” pelos clientes, dado que a maior parte deles estão

centrados nas aplicações ligadas ao WCAS e não no próprio WCAS e avaliam pelo

que estas lhes oferecem. Neste momento o WCAS está a começar a despertar o

interesse de diversos clientes, tanto nacionais como internacionais e será mais fácil

avaliar a longo prazo, mas o ponto de partida já está dado e é seguro dizer que, tal

como agradou internamente e nas demonstrações a que foi sujeito, tem tudo para

agradar num cenário de produção real.



8.2 Trabalho futuro

Para estar fully compliant com o Rich Communication Suite ainda vão ser precisos

grandes desenvolvimentos no WCAS. Os próximos passos serão abordar fortemente o

que está em falta da release 2 e a partir daí ir progressivamente tornando o WCAS

compliant com as releases 3 e 4. Estas releases apesar de não trazerem nada de

radicalmente novo focam-se sempre num conjunto de features das versões anteriores,

de modo a consolidá-las e acrescentar-lhes melhorias que tragam valor para o cliente.

Um outro desenvolvimento que estará próximo é a criação de um MSRP Relay.

Apesar de ser completamente transparente para uma aplicação cliente estar ligada a

um MSRP Switch, um MSRP Relay ou em peer-to-peer, do lado do WCAS representa

a sobrecarga de o mesmo servidor ter que lidar tanto com tráfego de sinalização como

com tráfego de media. A divisão de responsabilidades faz com que toda a arquitectura

do servidor, tanto a nível lógico como físico, seja mais simples, elegante, modular e

escalável.

8.3 Lições aprendidas

A realização deste estágio teve um retorno muito grande a vários níveis. Apesar de eu

já ter uma experiência de trabalho de alguns anos, a WIT Software foi a empresa com

maior dinamismo e onde pude participar das mais diversas formas no

desenvolvimento de um produto de software. Isto permitiu-me consolidar e colocar na

prática muitos conhecimentos por mim adquiridos no passado e também durante o

mestrado.

O facto de estar a desenvolver software que tem a ambição de conquistar clientes de

renome nacional e internacional e que concorre directamente com algumas das

maiores empresas de telecomunicações que existe é, sem dúvida, altamente motivador

e gratificante. Não é simplesmente uma aplicação que será usada por algumas dezenas

de pessoas numa empresa, mas sim um produto que vai ser utilizado por milhares ou

até milhões de pessoas em todo o mundo. É aqui que o desenvolvimento de software

passa a ter outro sentido.

Durante todo o projecto o WCAS foi sujeito a diversas demonstrações a clientes

revelando o quanto é importante que tudo esteja pronto e a funcionar na data prevista,

pois representa a oportunidade de angariar ou perder o cliente. Isto cria um sentido de



responsabilidade muito grande tanto na atribuição de estimativas como no

cumprimento das estimativas dadas, sempre focado na satisfação do cliente.

Este projecto incidia sobre uma área de desenvolvimento na qual não tinha

propriamente experiência, o verdadeiro Server-side Programming. As páginas Web

são consideradas semelhantes a este paradigma, no entanto, não têm rigorosamente

nada ver com o paradigma deste projecto. Enquanto as páginas Web são meras

aplicações client-side que são executadas do lado do servidor, este projecto é a

programação de um servidor que vai receber pedidos de aplicações client-side e vai

executar operações em server-side, e é aqui que está toda a diferença. Apesar de já ter

efectuado alguns desenvolvimentos no paradigma server-side, estes eram meramente

académicos e com dimensões praticamente insignificantes. Assim, com este projecto

aprendi o quão importante é este trabalho e o quanto ele deve ser bem feito, robusto e

confiável.

Este projecto foi cheio de decisões do princípio ao fim. Desde o início do projecto que

sempre fui incentivado a tomar e fundamentar as minhas próprias decisões, sempre

com a consciência de que eram elas que determinavam o sucesso ou insucesso de um

projecto. No fim do estágio e tendo em conta os resultados obtidos acho que, no geral,

as decisões tomadas foram boas. Fazendo uma retrospectiva, naturalmente tomaria

outras decisões, não que as que tomei não foram boas, mas sim porque com o

conhecimento que tenho agora e que tive após as decisões que tomei percebi que

podia ter tomado decisões ainda melhores.

Agora no final do estágio, mesmo não sendo o final do projecto, consigo olhar para

trás com muito orgulho no trabalho desenvolvido e com a sensação de que a

WIT Software teve o retorno esperado daquilo em que apostou no início do estágio.

Mesmo sabendo que foi um projecto extremamente difícil e trabalhoso, que fez com

que muito tempo extra tenha sido dedicado ao projecto, chego ao fim com a noção de

que não foi apenas um “estágio”, mas sim um projecto com as ambições típicas de

uma empresa como a WIT Software. Apesar de todo este esforço e dedicação é

extremamente gratificante ter trabalhado num projecto que desde o início demonstrou

ter um potencial enorme para ser um sucesso.



Bibliografia

1. WIT Software (2011) WIT Software Website. Disponível em: http://www.wit-

software.com (Acedido em: 19 de Julho de 2011)

2. Directory of Schools ‘Telecommunications College'. Disponível em:

http://www.directoryofschools.com/Education-

Articles/Telecommunications/Telecommunications-College.htm (Acedido em:

19 de Julho de 2011)

3. Webdesigner Depot The Evolution of Cell Phone Design Between 1983-2009

Disponível em: http://www.webdesignerdepot.com/2009/05/the-evolution-of-

cell-phone-design-between-1983-2009 (Acedido em: 19 de Julho de 2011)

4. Lillian Goleniewski (2001) ‘Understanding the Telecommunications

Revolution’ informIT [Online]. Disponível em:

http://www.informit.com/articles/article.aspx?p=24667 (Acedido em: 19 de

Julho de 2011)

5. T. Van Landegem e H. Viswanathan (2008) ‘Anywhere, Anytime, Immersive

Communications’ Enriching Communications, vol. 2: p. 1-6 [Online].

Disponível em http://www.alcatel-

lucent.com/enrich/v2i12008/pdf/ECv2i1_AnywhereAnytimeImmersive_en.pd

f (Acedido em 19 de Julho de 2011)

6. BBC (1999) Convergence: Three into one. Business: The Economy.

Disponível em: http://news.bbc.co.uk/2/hi/business/474995.stm (Acedido em:


7. WIT Software (2011) WIT Connected TV Suite. Disponível em:

http://www.wit-software.com/products/connected-tv-suite (Acedido em: 19 de

Julho de 2011)

8. GSMA (2011) RCS-e - Advanced Communications: Services and Client

Specification p.15 Disponível em:

http://www.gsmworld.com/documents/rcse_spec_v1.1_final.zip (Acedido em:


http://www.wit-software.com/

http://www.wit-software.com/

http://www.directoryofschools.com/Education-Articles/Telecommunications/Telecommunications-College.htm

http://www.directoryofschools.com/Education-Articles/Telecommunications/Telecommunications-College.htm

http://www.webdesignerdepot.com/2009/05/the-evolution-of-cell-phone-design-between-1983-2009

http://www.webdesignerdepot.com/2009/05/the-evolution-of-cell-phone-design-between-1983-2009

http://www.informit.com/articles/article.aspx?p=24667

http://www.alcatel-lucent.com/enrich/v2i12008/pdf/ECv2i1_AnywhereAnytimeImmersive_en.pdf



http://news.bbc.co.uk/2/hi/business/474995.stm

http://www.wit-software.com/products/connected-tv-suite




9. Ericsson (2005) IMS Multimedia Telephony. Disponível em:

http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-

FGB101335&Lang=EN (Acedido em: 22 de Julho de 2011)

10. Nokia Siemens Networks (2009) MSC Server System. Disponível em:

http://www.nokiasiemensnetworks.com/sites/default/files/document/Serve_at

Once_Traffica_for_NSN_MSC_Serverbasednetworks.pdf (Acedido em: 22 de

Julho de 2011)

11. Alcatel-Lucent (2009) 5400 IMS Application Server Disponível em:

http://www.alcatel-

lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Re

source_Ctr&LMSG_CONTENT_FILE=Brochures/5400_IMS_Application_S

erver_Bro.pdf (Acedido em: 22 de Julho de 2011)

12. Huawei IP Telephony Solution. Disponível em:

http://www.huawei.com/products/datacomm/detailitem/view.do?id=1849&rid

=436 (Acedido em: 22 de Julho de 2011)

13. Colibria (2009) RCS Application Servers. Disponível em:

http://colibria.com/solutions/rcs (Acedido em: 22 de Julho de 2011)

14. Summit Summit. Disponível em: http://www.summit-tech.ca (Acedido em: 22

de Julho de 2011)

15. Solaiemes RCS Thin Client Server. Disponível em:

http://www.solaiemes.com/index.php?id=100 (Acedido em: 23 de Julho de

2011)

16. Solaiemes RCS Solution Gateway. Disponível em:

http://www.solaiemes.com/index.php?id=93 (Acedido em: 23 de Julho de

2011)

17. Aylus Media Platform. Disponível em: http://www.aylus.com/platform.html

(Acedido em: 23 de Julho de 2011)

18. Microsoft Lync. Disponível em: http://office.microsoft.com/en-us/lync/lync-

2010-FX102004552.aspx

http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-FGB101335&Lang=EN

http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-FGB101335&Lang=EN

http://www.nokiasiemensnetworks.com/sites/default/files/document/Serve_atOnce_Traffica_for_NSN_MSC_Serverbasednetworks.pdf

http://www.nokiasiemensnetworks.com/sites/default/files/document/Serve_atOnce_Traffica_for_NSN_MSC_Serverbasednetworks.pdf

http://www.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=Brochures/5400_IMS_Application_Server_Bro.pdf




http://www.huawei.com/products/datacomm/detailitem/view.do?id=1849&rid=436

http://www.huawei.com/products/datacomm/detailitem/view.do?id=1849&rid=436

http://colibria.com/solutions/rcs

http://www.summit-tech.ca/

http://www.solaiemes.com/index.php?id=100

http://www.solaiemes.com/index.php?id=93

http://www.aylus.com/platform.html

http://office.microsoft.com/en-us/lync/lync-2010-FX102004552.aspx

http://office.microsoft.com/en-us/lync/lync-2010-FX102004552.aspx



19. Telepo Business Communication Server. Disponível em:

http://www.telepo.com/telepo-business-communication-solution/telepo-

business-communication-server (Acedido em: 22 de Julho de 2011)

20. CommuniGate Systems CommuniGate Pro Server. Disponível em:

http://www.communigate.com/main/platform/client-server.html (Acedido em:


21. Ribbit Ribbit. Disponível em: http://www.ribbit.com (Acedido em: 23 de Julho

de 2011)

22. 0xff Timetracker. Disponível em: http://0xff.net (Acedido em: 24 de Julho de

2011)

23. Mantis MantisBT. Disponível em: http://www.mantisbt.org (Acedido em: 24

de Julho de 2011)

24. Gamma E., Beck K. JUnit. Disponível em: http://www.junit.org (Acedido em:


25. Apache Subversion. Disponível em: http://subversion.apache.org (Acedido

em: 24 de Julho de 2011)

26. Oracle SailFin. Disponível em: http://sailfin.java.net (Acedido em: 24 de Julho

de 2011)

27. Oracle Oracle Communications Converged Application Server Disponível em:

http://www.oracle.com/technetwork/middleware/ccas (Acedido em: 24 de

Julho de 2011)

28. Wowza Media Systems Wowza Media Server. Disponível em:

http://www.wowzamedia.com (Acedido em: 24 de Julho de 2011)

29. JBoss Netty. Disponível em: http://www.jboss.org/netty (Acedido em: 24 de

Julho de 2011)

30. JBoss Netty - Performance Test Reports. Disponível em:

http://www.jboss.org/netty/performance (Acedido em: 24 de Julho de 2011)

31. Johnson R. Spring. Disponível em: http://www.springsource.org (Acedido em:


http://www.telepo.com/telepo-business-communication-solution/telepo-business-communication-server

http://www.telepo.com/telepo-business-communication-solution/telepo-business-communication-server

http://www.communigate.com/main/platform/client-server.html

http://www.ribbit.com/

http://0xff.net/

http://www.mantisbt.org/

http://www.junit.org/

http://subversion.apache.org/

http://sailfin.java.net/

http://www.oracle.com/technetwork/middleware/ccas

http://www.wowzamedia.com/

http://www.jboss.org/netty

http://www.jboss.org/netty/performance

http://www.springsource.org/



32. JetBrains IntelliJ IDEA.Disponível em: http://www.jetbrains.com/idea

(Acedido em: 24 de Julho de 2011)

33. Wireshark Wireshark. Disponível em: http://www.wireshark.org (Acedido em:


http://www.jetbrains.com/idea

http://www.wireshark.org/



Anexo 1 Competitors Analysis

O conteúdo deste anexo contém informações confidenciais e materiais com direitos de

autor pertencentes à WIT Software SA. Por esse motivo o seu acesso é restrito.



Anexo 2 WCAS Detailed Design





Anexo 3 WCAS Chat Protocol





Anexo 4 WCAS Chat Module

Performance Report



wit communications application server plataforma...

Documents