“innovacion y servicios en ip ... - telematica… · el trabajo presentado a continuacion...

UNIVERSIDAD TECNICA FEDERICO SANTA MARIADEPARTAMENTO DE ELECTRONICA

VALPARAISO - CHILE

“INNOVACION Y SERVICIOS EN IP MULTIMEDIASUBSYSTEM (IMS)”

DANIELA ARANCIBIA TAVRA

MEMORIA DE TITULACION PARA OPTAR AL TITULO DEINGENIERO CIVIL TELEMATICO

PROFESOR GUIA: REINALDO VALLEJOS

PROFESOR CORREFERENTE: MARCELO MARABOLI

DICIEMBRE - 2010

Agradecimientos

Son muchas las personas que me han ayudado a desarrollar esta memoria.

Primero, les agradezco a los profesores del departamento de electronica por estar siempre

dispuestos a ayudarme. Al profesor Marcelo Maraboli, por su simpatıa y ayuda en la correc-

cion de esta memoria. Tambien le agradezco en especial al profesor Reinaldo Vallejos por su

apoyo incondicional y por la ayuda que siempre me brindo para poder cumplir el sueno de

estudiar en Francia.

Este mismo sueno fue posible tambien por el apoyo de la Oficina de Asuntos Interna-

cionales, gracias Karol y Katie por su ayuda.

En Francia son muchas las personas que conocı, y muchas las experiencias que vivı. Ami-

gos que se convirtieron en mi familia, gracias por acompanarme en los buenos y malos mo-

mentos.

A mis amigos en Chile, gracias por su apoyo en todo momento, por su carino y preocu-

pacion, los llevo siempre en el corazon. Ustedes saben que los lazos de amistad ni la distancia

no los puede romper.

Le doy las gracias a Alberto, por toda su paciencia y por su carino.

Finalmente, le agradezco a mi familia. A mi Papa, porque de ti aprendı a ser rigurosa,

perfeccionista y a que ningun problema es demasiado grande. A mi Mama, por ensenarme a

luchar por mis suenos, a ser inteligente en el recreo y a que la mejor profesion y la mas difıcil

es formar una linda familia. A mi hermano, por demostrarme su carino aun estando en la mitad

del mar. A mi hermana, por ser mi mejor ejemplo de hija, madre y profesional. A todos mis

tıos, primos y a mi querida abuela, por su carino y preocupacion infinita. Esta memoria es de

ustedes.

I

Resumen

IP Multimedia Subsystem (IMS) es una red de nueva generacion que tiene por

objetivo hacer converger las diferentes redes de acceso, ya sean fijas o moviles, para

proveer diferentes servicios multimedia (voz, datos, vıdeo, imagen) con calidad de

servicio.

Es estrategico para los operadores de telecomunicaciones innovar para poder en-

contrar estos nuevos servicios y aplicaciones de valor anadido para sus clientes, e

incrementar de esta manera su salida al mercado y por consecuencia disminuir los

costos.

Este documento detalla el trabajo realizado para uno de los mayores operadores

de telecomunicaciones en Europa en el proceso de innovacion en torno a IMS. Es-

to incluye dos tareas mayores. La primera es el analisis de la arquitectura y de los

estandares que definen IMS y sus principales servicios. La segunda, un estudio de-

tallado del ciclo de innovacion, donde se definen sus etapas y los diferentes trabajos

realizados en torno a este; primero, el analisis de nuevas tecnologıas, con la imple-

mentacion de un Core IM y de un servidor de aplicaciones, ambos Open Source;

segundo, los trabajos directamente entregador al operador: el estudio detallado del

estandar Rich Communications Suite (RCS), que sera implementado en el ano 2011

por los tres operadores en Francia, y un test de calidad de servicio de una solucion

Push-to-X.

Palabras claves: IMS, Innovacion de Servicios, Servicios IMS.

II

Abstract

IP Multimedia Subsystem (IMS) is the next generation core architecture for voice

and data convergent services. IMS implements multiple access technologies and sets

the baseline for convergent network services including both wireless and wired access.

Innovation as a strategy towards new services and applications allows telecom op-

erators to offer their customers novel and value added products. This allows operators

to enlarge their market and therefore reduce costs.

This document details the work carried out for a major European telecom operator

in the context of the innovation cycle of IMS. This includes two main tasks. The

first one was the analysis of architecture and the standards of IMS and main IMS

services. The second task, a comprehensive study of the innovation cycle, in particular:

first, the analysis of new technologies, the implementation of an IMS Core and an

Application Server, in an Open Source. Secondly, the development work carried out

for the operator: a study of the standard Rich Communication Suite (RCS), that will be

implemented by 2011 in France, and a test of quality of service (QoS) of a Push-to-X

solution.

Keywords: IMS, Services Innovation, IMS Services.

III

Glosario

2

2G Second Generation Wireless Telephone Technology.

3

3G Third Generation Wireless Telephone Technology.

3GPP Third Generation Partnership Project.

A

AAA Authentication, Authorisation and Accounting.

ADSL Asymmetric Digital Subscriber Line.

AS Application Server.

B

B2BUA Back to Back User Agent.

BAC Bussines Application Consulting.

C

CAPEX Capital Expenditures.

IV

CSCF Call Session Control Function.

E

EAB Enhanced Address Book.

ETSI European Telecommunications Standards Institute.

G

GPL General Public Licence.

H

HSS Home Subscriber Server.

I

I-CSCF Interrogating Call Session Control Function.

IETF Internet Engineering Task Force.

iFC Initial Filter Criteria.

IM Instant Messaging.

IMS IP Multimedia Subsystem.

IP Internet Procotol.

ITMS IT Managed Services.

ITT IT Transformation.

IVR Interactive Voice Recorder.

V

J

JAIN Java APIs for Integrated Networks.

L

LGPL Lesser General Public License.

M

MG Media Gateway.

MMS Multimedia Messaging Service.

MPLS Multiprotocol Label Switching.

N

NAB Network Address Book.

NEO New Offers.

NGN Next Generation Networks.

O

OAMP Operations, Administration, Management and Provisioning.

OMA Open Mobile Alliance.

OPEX Operational Expenditures.

P

P-CSCF Proxy Call Session Control Function.

VI

PC Personal Computer.

PoC Push-to-Talk Over Cellular.

PSTN Public Switched Telephone Network.

PTT Push-to-Talk.

PTX Push-to-X.

Q

QoS Quality of service.

R

RCS Rich Communications Suite.

RFC Request for Comments.

S

S-CSCF Serving Call Session Control Function.

S-IMS Services IMS.

SBC Session Border Control.

SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions.

SIP Session Initiation Protocol.

SLEE Service Logic Execution Environment.

SMS Short Message Service.

VII

T

TISPAN Telecoms and Internet converged Services and Protocols for Advanced

Networks.

TMD Telecom Media Defense.

V

VoIP Voice over IP.

X

XCAP XML Configuration Access Protocol.

XDMS XML Data Management Server.

XML Extensible Markup Language.

XMPP Extensible Messaging and Presence Protocol.

VIII

Indice general

1. Introduccion 4

2. Contexto de Trabajo 6

2.1. Capgemini Telecom Media Defense . . . . . . . . . . . . . . . . . . 6

2.2. Skill Center New Offers (NEO) . . . . . . . . . . . . . . . . . . . . . 7

2.3. Proyecto Servicios IMS (S-IMS) . . . . . . . . . . . . . . . . . . . . 8

3. IP Multimedia Subsystem 9

3.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1. Servicios Multimedia con QoS . . . . . . . . . . . . . . . . . 10

3.1.2. Independencia de la Red de Acceso . . . . . . . . . . . . . . 10

3.1.3. Reduccion del Time-to-Market . . . . . . . . . . . . . . . . . 10

3.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1. Capa de Transporte . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2. Capa de Control . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.3. Capa de Servicios . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1. Presencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.2. Push-to-Talk (PTT) . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.3. Mensajerıa Instantanea . . . . . . . . . . . . . . . . . . . . . 16

3.4. Estandares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1. Rich Communications Suite . . . . . . . . . . . . . . . . . . 17

1

4. Gestion de la Innovacion 20

4.1. Ciclo de Innovacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5. Trabajos Realizados 24

5.1. Analisis y Experimentacion de Nuevas Tecnologıas . . . . . . . . . . 24

5.1.1. Core IMS Open Source . . . . . . . . . . . . . . . . . . . . . 24

5.1.2. Servidor de Aplicaciones Open Source . . . . . . . . . . . . 29

5.2. Contribucion directa al cliente . . . . . . . . . . . . . . . . . . . . . 40

5.2.1. Estudio de Call-Flows RCS 2.0 . . . . . . . . . . . . . . . . 40

5.2.2. Test de solucion Push-to-Talk . . . . . . . . . . . . . . . . . 43

6. Conclusiones 49

Bibliografıa 51

A. Aplicacion Facebook 54

A.1. SipPresenceHandlerServlet.java . . . . . . . . . . . . . . . . . . . . 54

A.2. HttpSubscribeInitiationServlet.java . . . . . . . . . . . . . . . . . . . 61

B. Licencias GPL y LGPL 65

B.1. GPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

B.2. LGPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2

Indice de figuras

2.1. Skill Centers TMD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1. Arquitectura IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2. Core IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3. Servicio de Presecia . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4. Network Address Book . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5. GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6. Intercambio multimedia durante una llamada, Fuente GSMA [9] . . . 18

3.7. Agenda de Contactos y Mensajerıa Enriquecida, Fuente GSMA [9] . . 19

4.1. Ciclo de Innovacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1. Diagrama de Red de servidor OpenIMS en lab Capgemini . . . . . . 26

5.2. Estructura de directorios de Servidor Mobicents . . . . . . . . . . . . 31

5.3. Diagrama de Red de servidor Mobicents y OpenIMS en lab Capgemini 32

5.4. Servicio de Presencia, Fuente Mobicents [13] . . . . . . . . . . . . . 34

5.5. Aplicacion Facebook C2C . . . . . . . . . . . . . . . . . . . . . . . 36

5.6. Ejemplo de Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.7. Diagrama de red de solucion PTT en sitio lab Capgemini . . . . . . . 44

5.8. Escenarios de Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.9. Resultados globales test QoS . . . . . . . . . . . . . . . . . . . . . . 47

3

Capıtulo 1

Introduccion

En la actualidad, muchos factores influyen en el mercado de las telecomunica-

ciones: una fuerte competencia entre los diferentes actores de la industria debido a

la desregulacion del mercado, la explosion del uso de las diferentes redes de acce-

so (internet, telefonıa movil), la llegada de redes de alta velocidad y el creciente uso

de trafico multimedia, entre otros, provocan una mutacion progresiva de las redes de

comunicaciones en redes de nueva generacion (NGN: Next-Generation Networks).

El objetivo entonces es hacer converger las diferentes redes de acceso, ya sean

fijas o moviles, de alta o baja velocidad. Para esto es necesario definir un nuevo sub-

sistema, independiente de la red de acceso, que pueda proveer diferentes servicios

multimedia (voz, datos, vıdeo, imagen) a los usuarios. A este nuevo sub-sistema se le

llamo IP Multimedia Susbystem, y tiene por objetivo implementar rapidamente nuevos

servicios, reduciendo los costos.

Los operadores pueden beneficiarse de manera significativa de esta arquitectura

dado que la mayorıa de los componentes de IMS son independientes de la red de tele-

comunicaciones subyacente y entonces, con la utilizacion de los gateways apropiados,

IMS puede proveer servicios no importando el tipo de red de acceso utilizada.

El trabajo presentado a continuacion consiste en la participacion a la concepcion,

desarrollo y validacion de inicio a fin de servicios IMS innovadores en un proyecto

4

colaborativo con uno de los tres operadores de telefonıa movil en Francia.

La primera parte del documento describe brevemente la sociedad y el proyecto

donde se lleva a cabo este trabajo. Luego se desarrolla el estado del arte de IMS,

describiendo su arquitectura, los servicios principales y los estandares que lo definen.

Una vez esta introduccion realizada, se describe el proceso de innovacion en torno a

los servicios IMS en el capitulo siguiente. En el capıtulo 5 se describen los trabajos

realizados divididos en dos tipos: analisis de nuevas tecnologıas y trabajos de aporte

directos al cliente. Las conclusiones son expresadas en el ultimo capıtulo.

5

Capıtulo 2

Contexto de Trabajo

Este trabajo de tesis es el fruto de un trabajo realizado durante 6 meses en la

empresa Capgemini Telecom Media Defense, como requisito para obtener el tıtulo de

ingeniero en telecomunicaciones en Francia.

En este capıtulo se describe brevemente la empresa, el departamento y el proyecto

en el cual se llevo a cabo este trabajo.

2.1. Capgemini Telecom Media Defense

El grupo Capgemini es uno de los lıderes mundiales en Servicios de Consultorıa

y Servicios Tecnologicos. Su mision es de ayudar al desarrollo, a la transformacion

y a la evolucion de sus clientes aconsejandoles la tecnologıa mas adaptada segun sus

necesidades.

Presente en mas de 30 paıses, Capgemini realizo un volumen de ventas de 8,3

miles de millones de euros en 2009 y posee una plantilla de mas de 90000 personas

en el mundo.

Telecom Media Defense es una rama del grupo dedicada hace mas de 30 anos al

mercado de las telecomunicaciones y multimedia. Sus experiencias cubren las areas

de consultorıa, integracion de sistemas y externalizacion para los proveedores de ser-

vicios de telecomunicaciones y las empresas de comunicacion.

6

Apoyandose en alianzas estrategicas, Capgemini Telecom Media Defense (TMD)

desarrolla soluciones en las areas de gestion de la relacion cliente, plataformas de

servicios, facturacion, soporte y servicios destinados a los proveedores de contenido.

La division Telecom Media Defense interviene a mas de 70 clientes, fijos y moviles,

y proveedores de Internet en Francia y el extranjero. Ellos conciben, desarrollan y re-

alizan sistemas de informacion dedicados.

Telecom Media Defense esta organizado en 4 Skill Centers como muestra la Figura

2.1.

Figura 2.1: Skill Centers TMD

ITMS (IT Managed Services)

ITT (IT Transformation)

BAC (Bussines Application Consulting)

NEO (NEw Offers)

2.2. Skill Center New Offers (NEO)

El Skill Center NEO tiene por objetivo desarrollar la actividad ligada a las ofertas

innovadoras y de la diversificacion de TMD con respecto los actores de las telecomu-

nicaciones y multimedia, en Francia o el extranjero.

Las actividades principales realizadas por el grupo son:

7

Skill Group (( Portales, Mobilidad y Multimedia )) reagrupa todos los proyectos

de portales web incluyendo la nocion de gestion de contenidos y los de motores

de busqueda, los proyectos de movilidad y los proyectos en torno de la actividad

Multimedia.

Skill Group (( Facturacion)) Contiene el conjunto de proyectos de todos los sec-

tores que integran el aspecto de valorizacion y de facturacion.

Skill Group (( Seguridad )) reagrupa los proyectos que tratan la estrategia y do-

minio de la seguridad y en el desarrollo de soluciones adaptadas.

Skill Group “CRM Agil y Mediacion”, reagrupa proyectos de mediacion para

los operadores de telecomunicaciones, proyectos del tipo (( Wireless )) y proyec-

tos de plataformas de servicios.

Skill Group (( Plateformas de Servicios y Centros de Contactos )) gestiona los

proyectos de Centro de contactos, proyectos de desarrollo de usos de datos y

proyectos de mensajerıa.

2.3. Proyecto Servicios IMS (S-IMS)

El proyecto Servicios IMS pertenece al Skill Group “Plataformas de Servicios y

Centros de Contacto” y tiene por objetivo acompanar a los Operadores de telefonıa

Movil en la innovacion en torno a la arquitectura IMS. Nuevos servicios innovadores

son analizados desde un punto de vista tecnico y tambien de mercado. Todos los tra-

bajos presentados en esta memoria forman parte de este proyecto.

8

Capıtulo 3

IP Multimedia Subsystem

Como fue explicado anteriormente, este proyecto se basa en la arquitectura IMS,

por lo que es esencial describirla para luego comprender como se innova en torno a

ella. Este capıtulo tiene por objetivo entonces describir IMS, analizando sus ventajas,

la arquitectura, los servicios y los estandares que la definen.

IMS es un grupo de especificaciones que describen la arquitectura de redes de

nueva generacion (NGN) que permite la introduccion progresiva de aplicaciones de

voz y datos multimedia en las redes de comunicaciones fijas y moviles, basadas en el

protocolo IP.

Esta tecnologıa fue introducida en la 5ta version de (( 3rd Generation Partnership

Projet )) (3GPP) [2], una vez que el Protocolo de Inicio de Sesion (SIP), definido por

la IETF, fue elegido como el protocolo principal para IMS. Luego fue extendido por

las versiones 6 y 7 de 3GPP y el grupo de trabajo TISPAN de la ETSI.

3.1. Ventajas

IMS fue concebido en un principio como una plataforma de desarrollo de servicios

de nueva generacion, pero se ha convertido en una de las plataformas preferidas para

el desarrollo de servicios de valor agregado en numerosas redes existentes.

9

3.1.1. Servicios Multimedia con QoS

Servicios Multimedia (voz, datos, texto y video) son disponibles para los usuarios

independientemente de su conexion de red, limitado solamente por las capacidades

del aparato de origen. IMS permite nuevas funcionalidades como la presencia, push-

to-talk o mensajerıa instantanea, entre otras, que permiten enriquecer la experiencia

de comunicacion.

Ademas, se habla de servicios con QoS porque actualmente todas las aplicaciones

multimedia basadas en IP solo ofrecen una calidad ”best effort”, la cual no garantiza

una buena experiencia de comunicacion del usuario. IMS en cambio, ofrece mecanis-

mos para la gestion de los niveles de calidad de servicio.

3.1.2. Independencia de la Red de Acceso

Los usuarios pueden estar conectados a la red de comunicaciones por diferentes

interfaces cableadas o no. En efecto, un usuario puede acceder a la red con su PC (via

ADSL o fibra optica), su telefono movil, su telefono IP o incluso con su telefono fijo,

todo gracias a los gateways que realizan la conversion de los diferentes protocolos de

entrada en los protocolos utilizados en IMS.

3.1.3. Reduccion del Time-to-Market

El desarrollo de la arquitectura IMS otorga a los proveedores de servicios la opor-

tunidad de ser primeros en el mercado (first-to-market) con una gama de servicios

adaptables a las necesidades especıficas del mercado.

Esta caracterıstica es de gran importancia sobre todo si se considera la gran compe-

tencia que existe en el mercado de las telecomunicaciones. Ser los primeros en ofrecer

un servicio permite aprovechar de una parte especıfica del mercado, como los “early

adopters” 1 . En cambio, los operadores que desarrollan los servicios con retraso se

1Los “early adopters” son aquellas personas que se acercan a nuevas tecnologıas antes que el resto:intentan hacer uso de nuevos programas/servicios antes que la mayorıa.

10

enfrentan a una competencia mas grande, con un mayor costo de adquisicion y una

gran presion sobre los precios, lo que provoca una baja rentabilidad.

Con IMS, un operador puede considerablemente reducir los tiempos necesarios

para el desarrollo, la estandarizacion, la integracion y los tests de cada nuevo servicio

antes de que sea lanzado, permitiendole ası presentar servicios con anticipacion. [7]

3.2. Arquitectura

La arquitectura puede ser dividida en tres capas: La capa de transporte, la capa de

control y la capa de servicios como se observa en la Figura 3.1.

Figura 3.1: Arquitectura IMS

3.2.1. Capa de Transporte

Los usuarios de IMS pueden conectarse usando diferentes redes y tecnologıas,

cableadas o no. Cada una de las conexiones es facilitada por entidades logicas en la

capa de transporte, ya sea routers, gateways o conmutadores.

El objetivo es de proteger las capas superiores de IMS de tecnologıas de acceso de

red implicadas en el envıo y la recepcion de multimedia. Las entidades de red en la

11

capa de transporte proveen una interface comun para la capa de control independiente-

mente de la red de acceso. Estas entidades son las responsables de la traduccion de los

protocolos de la red de conexion en los protocolos de red necesarios para interactuar

con el nucleo de la red IMS.

3.2.2. Capa de Control

La capa de control realiza la conmutacion de base y el control de sesion al interior

de una red IMS. Esta compuesta de servidores de control de red para la gestion de

llamadas o de sesiones. El mas importante entre ellos es el (( CSCF )) (Call Session

Control Function), un servidor SIP que establece, acompana sostiene y comunica las

sesiones multimedia. El puede jugar tres roles diferentes:

(( Serving-CSCF )) (S-CSCF): conmuta las sesiones hacia las aplicaciones, el

servicio o la red demandada.

(( Proxy-CSCF )) (P-CSCF): Es el primer punto de contacto para la senalizacion

de trafico en IMS.

(( Interrogating-CSCF )) (I-CSCF): provee una pasarela hacia los otros dominios.

Es esencialmente utilizado para esconder la topologıa de red o en el caso en que

existan varios S-CSCF en el mismo dominio.

Esta capa consta tambien de un Home Subscriber Server (HSS) que es una base

de datos centralizada que contiene las informaciones de la cuenta de cada usuario.

Esta informacion es principalmente accedida por el S-CSCF para la validacion de los

usuarios y para determinar las capacidades de los servicios autorizados. El I-CSCF y

los servidores de aplicaciones tienen tambien acceso a la base de datos.

Como muestra la Figura 3.2, todos los elementos descritos anteriormente forman

juntos el nucleo IMS (Core IMS).

12

Figura 3.2: Core IMS

Existe tambien una serie de funciones de soporte como la autentificacion, la autor-

izacion y la tarificacion (AAA), ası como la operacion, la administracion, la gestion y

el aprovisionamiento (OAMP)

El protocolo de Inicio de Sesion (SIP) es utilizado como el protocolo de control de

sesion a traves de la capa de control, y para las conexiones establecidas con las capas

de transporte y de servicios.

3.2.3. Capa de Servicios

La capa de servicios esta compuesta de servidores de aplicaciones(AS) o de con-

tenido que proveen todos los servicios de valor agregado en la red. Existen muchos

servicios en IMS como la Presencia, Push-to-Talk over Celullar (PoC), Chat en Grupo,

Publicidad Multimedia, Mensajerıa Instantanea, Mensajerıa Unificada, Videostream-

ing, Audio/Web/Videoconferencia, IPTV, Servicios de voz, Telefonıa sobre IP (ToIP),

entre otros.

3.3. Servicios

Armonizando los servicios, IMS permite a los usuarios finales combinar varios

multimedia en una sola sesion: elegir el medio mas apropiado para enriquecer su co-

municacion (video, voz, texto, imagenes o mensajes instantaneos), todo disponible

13

simultaneamente y en tiempo real.

IMS hace posible tambien los nuevos servicios entre perifericos moviles y fijos.

Ejemplos de tales servicios pueden ser el compartir contenidos o servicios de men-

sajerıa entre un terminal movil y un PC.

Innumerables son los servicios disponibles actualmente en IMS, entre ellos los

mas utilizados la Presencia, el Push-to-talk, la Mensajerıa Instantanea (IM), el Inter-

active Voice Response (IVR), Audio/Voice/Videoconference y Voz sobre IP (VoIP).

Los tres primeros, en relacion directa con el proyecto, seran detallados a continuacion.

3.3.1. Presencia

La presencia es uno de los servicios mas conocidos y utilizados en las aplicaciones

multimedia en tiempo real y tiene un rol de servicio de base (en ingles “enabler”) para

otras aplicaciones como Instant Messaging, Push-to-Talk over Cellular, entre otras.

Este servicio permite a un grupo de usuarios estar informados de la disponibilidad

y de los medios de comunicacion de otros usuarios del grupo, ver Figura 3.3.

Figura 3.3: Servicio de Presecia

La funcion de presencia tambien conoce en que terminales el usuario puede ser

ubicado (ya sea fijo o movil). Diferentes reglas pueden ser definidas por el usuario

para decidir quien puede ver que tipo de informaciones.

Para visualizar el estado de presencia de un usuario es necesario agregar como

contacto a otro usuario en su Agenda de Contactos (Address Book). Una Agenda de

14

Contactos en Red (en ingles Network Address Book, NAB) es una agenda de contactos

centralizada y sincronizada que permite al usuario administrar y acceder a todos sus

contactos guardados (ademas de los eventos calendarizados, las tareas y las notas)

en el correo electronico, mensajerıa instantanea Web, y la agenda del telefono movil,

como muestra la Figura 3.4.

Figura 3.4: Network Address Book

3.3.2. Push-to-Talk (PTT)

El servicio Push-to-talk permite a un usuario utilizar su telefono movil como un

walkie-talkie. Se basa sobre la comunicacion en un canal half-duplex (un solo senti-

do), entonces mientras un usuario transmite, el otro escucha.

En la actualidad existen evoluciones de este servicio en tres direcciones:

Soporte de otros multimedia

• Push to Video : Video Real Time

• Push to Send : Foto, Video, Informaciones de contacto (vCard), weblink,

archivos

• Push to Locate : transmitir datos de la ubicacion GPS

15

Hacia otras destinaciones, distintas que un grupo de contactos

• Push to Voicemail: depositar un mensaje de Audio, Video o Texto en un

servidor

• Push to Email : enviar un email con o sin datos adjuntos

• Push to Messaging :enviar SMS / MMS

Como servicio de base de otras tecnologıas innovadoras

• Push to Media Services: IVR, robots, servicios USSD-like, sitios de redes

comunitarias

• Servicio de broadcast audio / video, servicio de publicacion de informa-

ciones o de alertas.

El grupo de servicios descritos anteriormente son llamados Push-to-X (PTX).

3.3.3. Mensajerıa Instantanea

La mensajerıa instantanea es un servicio de comunicacion que permite a los usuar-

ios enviar y recibir mensajes en tiempo real. Este servicio es bastante conocido en in-

ternet (MSN, googletalk, yahoo) pero con IMS el mismo servicio es disponible para el

mundo movil, e interoperable con el mundo fijo con el uso de clientes estandarizados.

Los mensajes pueden contener texto, imagenes, audio, video, datos o una combi-

nacion de ellos. El mensaje es enviado por la red de datos a la plataforma IMS, quien

se encarga de localizar al destinatario y lo dirige hacia el.

3.4. Estandares

Los componentes y servicios de la arquitectura IMS son definidos y estandarizados

por diferentes forums.

16

“3rd Generation Partnership Project” (3GPP) y el 3GPP2 especificaron las necesi-

dades y definieron la arquitectura global.

“Open Mobile Alliance” (OMA) [14] esta principalmente concentrado en la

definicion de aplicaciones y de servicios en la capa superior de la infraestructura

IMS.

“Internet Engineering Task Force” (IETF) [10] trabaja en la definicion y de-

scripcion de protocolos de comunicacion de red.

“GSM Association” (GSMA) [8] describe tambien estandares de servicios us-

ando la arquitectura IMS, especıficamente Rich Communication Suite, que es

detallado a continuacion.

3.4.1. Rich Communications Suite

RCS es un estandar definido por la GSMA [8], consorcio mundial que reune mas

de 750 empresas que trabajan en torno a la telefonıa movil en 219 paıses, y 200 empre-

sas de aereas mas extensas, como sociedades de concepcion de software, proveedores

de equipos de red, sociedades de Internet y organizaciones de multimedia y entreten-

imiento. LA GSMA busca a innovar, a hacer madurar y a crear nuevas oportunidades

para sus miembros, todo esto con el objetivo de estimular el crecimiento del sector de

la telecomunicaciones moviles.

Figura 3.5: GSMA

17

Rich Communication Suite aspira a unificar la experiencia de comunicacion jun-

tando la presencia, voz, chat y servicios multimedia sobre IMS, en un principio para

redes moviles y posteriormente para las redes fijas. Las funcionalidades mayores de

RCS incluyen los siguientes servicios (GSMA, 2008) :

(( Enriched Call )) : Comunicacion enriquecida que permite el intercambio de

contenidos multimedia (foto o video), tomados en directo o que estaban guarda-

dos desde antes en el telefono, durante una conversacion telefonica.

Figura 3.6: Intercambio multimedia durante una llamada, Fuente GSMA [9]

(( Enhanced Phonebook )): Se trata de un agenda de contactos enriquecida que

permite al usuario compartir su estado de presencia, un mensaje de humor, una

foto o incluso un vınculo a su sitio de internet favorito y que sera automatica-

mente sincronizado en los telefonos de las personas con las que el comparte su

“perfil”, su ficha de contacto.

(( Enhanced Messaging )) : Mensajerıa enriquecida que autoriza una gran var-

iedad de opciones, especialmente el chat y el historial de mensajes, con fun-

cionalidades de envıo de archivos.

La Figura 3.7 ejemplifica estos dos servicios

18

Figura 3.7: Agenda de Contactos y Mensajerıa Enriquecida, Fuente GSMA [9]

Para los clientes, se trata de descubrir la convergencia: todos los servicios de co-

municacion son disponibles sin importar en que red ni en que tipo de terminal.

No es la intencion del programa RCS de crear nuevas normas, sino que precisar un

grupo de funcionalidades de base que pueden ser implementadas utilizando normas

y directivas ya existentes, definidas por otras instancias (por ejemplo, 3GPP, ETSI,

OMA, et la GSMA).

Una de las principales ventajas de RCS es que aumenta el atractivo de los ser-

vicios ofrecidos por el operador integrando la presencia y otros nuevos servicios de

comunicacion. La explotacion de las capacidades de servicio otorga igualmente a los

operadores la flexibilidad necesaria para desarrollar progresivamente los servicios de

comunicacion a su propio ritmo y la publicidad de los nuevos servicios a los clientes.

Ademas, RCS refuerza el modelo economico del operador, logrando responder a

la demanda de los clientes de personalizacion y de poder de expresion a traves de

los nuevos medios de comunicacion. Esto permite al cliente de beneficiarse de una

experiencia de comunicacion enriquecida.

En resumen, RCS permite a los operadores de acercar sus servicios para ofrecer

una experiencia de comunicacion realmente integrada e interoperable a sus usuarios

finales.

19

Capıtulo 4

Gestion de la Innovacion

En el contexto del proyecto Servicios IMS, la innovacion esta en el centro del

trabajo. Es esencial para el operador poder diferenciarse de la competencia desarrol-

lando nuevas aplicaciones atractivas y productivas. Capitalizar sobre la infraestructura

de servicios existente e identificar los buenos aliados son tambien factores claves para

el exito. Una vez que un servicio innovador es identificado, definir los casos de uso,

experimentar y definir una arquitectura son los pasos a seguir.

Luego de una evaluacion tecnica del servicio, experimentaciones comerciales son

realizadas para definir el mercado al cual sera dirigido el servicio, determinar el mod-

elo de negocios y analizar la rentabilidad del proyecto.

Cuando las etapas anteriores son completadas, el lanzamiento comercial del servi-

cio al mercado es el paso siguiente. Evaluaciones y evoluciones constantes son hechas

para que el servicio sea prospero.

El objetivo del trabajo realizado en el proyecto S-IMS es entonces ayudar a los

operadores a acelerar sus ciclos de innovacion: probar servicios IMS sin hacer inver-

siones en infraestructura y con tiempos de implementacion cortos.

20

4.1. Ciclo de Innovacion

Todas las etapas en el modelo del proceso de innovacion son importantes para la

comprension global del proceso. El ciclo puede ser esquematizado como muestra la

Figura 4.1.

Figura 4.1: Ciclo de Innovacion

Inicialmente, los analisis de ecosistemas, dirigidos en el proyecto S-IMS, tienen

como objetivo principal la identificacion de:

Normas, y tambien estandares que definen los servicios o las arquitecturas.

Nuevos usos, como integraciones entre el mundo web (como redes sociales) y

el mundo SIP, mensajerıa unificada a la voz sobre IP, pasarelas XMPP para in-

teractuar entre telefono SIP y clientes de mensajerıa instantanea (por ejemplo

MSN o Google Talk), servicios de tipo RCS, servicios de presencia y multime-

dia, entre otros.

Soluciones, de editores de software u Open Source analizando el estado del arte,

la madurez, capacidades, QoS, los riesgos.

21

Arquitecturas, analizando el compromiso entre costos, seguridad, fiabilidad y

escalabilidad.

Cuando una alternativa es seleccionada, un estudio detallado de la arquitectura,

las especificaciones tecnicas y la conformidad a las normas, es realizado para efectuar

eventualmente una experimentacion tecnica.

Los trials internos, con el personal del Operador, son realizados para probar las

funcionalidades, las ventajas, los defectos y la calidad de servicio (QoS). Estos trials

permiten realizar modificaciones al servicio y mejorarlo si es necesario.

Es hasta esta etapa que el proyecto S-IMS interviene en el proceso de innovacion

para el cliente Operador. Luego es el quien toma a cargo todas las informaciones para

continuar con el ciclo de lanzamiento del servicio. Es ası como el equipo de S-IMS

continua buscando nuevas aplicaciones y vuelve al inicio del ciclo de innovacion.

Por otro lado, los resultados de los trials internos son presentados al departamento

comercial del operador quien se encarga de tomar la decision de continuar o no con

el lanzamiento comercial del producto. Para esto, el se apoya en experimentaciones

comerciales (o trials externos). Estos consisten en probar el servicio con verdaderos

clientes del operador, tambien llamados en ingles (( Friendly User )).

Estos clientes son inducidos a dar su opinion, responder preguntas y solicitaciones

diversas sobre los servicios en fase de concepcion o de desarrollo. Aplicaciones o

servicios podrıan de esta manera enriquecerse de estas sugerencias para responder

mejor a las expectativas de los futuros usuarios.

En la fase de lanzamiento comercial el servicio es finalmente disponible para todo

el mundo. Es durante esta etapa que todos los medios deben ser puestos en marcha

para optimizar el valor agregado del servicio innovador propuesto: campana de comu-

nicacion, publicidad, demostraciones varias, entre otras.

Luego de esto, la explotacion del servicio permite al operador aprovechar al maxi-

mo los esfuerzos hechos en investigacion y en terminos financieros.

El servicio debe ser objeto de una constante busqueda de mejora en su productivi-

22

dad y sus caracterısticas. Esta evolucion comprende principalmente dos niveles:

Nuevas funcionalidades, generadas por estudios de marketing que toman en

cuenta las nuevas necesidades de los usuarios

Nuevas capacidades, impulsadas por el departamento tecnico, quien propone el

uso de nuevas tecnologıas

Por ultimo, la ventaja sobre la competencia conferida por el servicio innovador

debe emplearse para explorar todas las vıas que le permitan maximizar su ventaja

competitiva.

23

Capıtulo 5

Trabajos Realizados

Los trabajos realizados dentro del proyecto Servicios IMS son variados, pero sep-

arables en dos aspectos:

Trabajos de analisis de nuevas tecnologıas, especialmente la implementacion de

un Core IMS y de un S de Aplicaciones, ambos Open Source, en un principio

para tener un plataforma propia de experimentacion, y con el objetivo tambien

de evaluar sus capacidades y considerarlas como posibles soluciones alternati-

vas a las soluciones propietarias.

Estudios y experimentaciones tecnicas para el cliente, tareas propias del ciclo

de innovacion.

5.1. Analisis y Experimentacion de Nuevas Tecnologıas

5.1.1. Core IMS Open Source

La implementacion de un Core IMS fue uno de los trabajos realizados en este

proyecto. Se trata de una solucion Open Source, donde el objetivo principal es de

permitir a Capgemini convertirse en un proveedor virtual de servicios en IMS.

24

La ventaja de tener un Nucleo IMS es de principalmente poder probar aplicaciones

y servicios para el cliente sin que el tenga que ponerlas en marcha en su propia red.

De esta manera, la experimentacion es mucho mas rapida y facil de realizar.

Open IMS Core es una solucion Open Source que realiza las funciones ((Call Ses-

sion Control Fonctions)) (CSCF) y Home Subscriber Server (HSS) de una red IMS,

que juntos forman los elementos de base para la arquitectura IMS especificada actual-

mente. Los cuatro componentes son todos basados en programas y librerıas de codigo

abierto, por ejemplo SIP Express Router (SER) o MySQL.[15]

5.1.1.1 Instalacion y configuracion

Gracias a la guıa de instalacion proporcionada por la comunidad de OpenIMS, la

instalacion de la plataforma fue realizada rapidamente. Los problemas de compilacion

y de configuracion fueron resueltos con la ayuda de los forums y las listas de correo.

OpenIMS fue instalado en una maquina virtual con un sistema operativo De-

bian/Ubuntu.La mayor parte de la plataforma fue desarrollada en lenguaje C (En-

rutamiento de servidores CSCF), en java (Servidor HSS) y en sql(la base de datos

Mysql), por lo tanto existen varios paquetes a instalar en el servidor antes de la insta-

lacion de OpenIMS. Entre ellos se encuentra: make, gcc-4.3, ant, JDK6, bison, flex,

subversion, libxml2, libxml2-dev, mysql, libmysql, bind9.

Para descargarlos directamente y luego instalarlos fue utilizado el comando #apt-

get install nombre paquete. Una vez que los pre-requisitos ya estaban listos, se proce-

dio a descargar la plataforma desde el sitio de OpenIMS con la herramienta SVN.

Para las funciones de CSCFs :

#mkdir ser_ims

#svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_ims

Para el HSS :

#mkdir FHoSS

#svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS

25

Con esto se obtienen las versiones actualizadas de la plataforma.

Un vez que la plataforma fue instalada, la configuracion de la direccion IP, de los

puertos y del cortafuegos fue realizada para que ella pudiese funcionar sin problemas

en el lab Capgemini, como muestra el diagrama de red de la figura 5.1.

Figura 5.1: Diagrama de Red de servidor OpenIMS en lab Capgemini

Los valores predeterminados del dominio fueron cambiados a ”sims2.net” con la

direccion IP @IPprivada. Los archivos importantes cambiados fueron:

Todos los archivos en el directorio /opt/OpenIMSCore/ser ims/cfg

/opt/OpenIMSCore/FHoSS/deploy/DiameterPeerHSS.xml

/opt/OpenIMSCore/FHoSS/deploy/hss.properties

/opt/OpenIMSCore/FHoSS/deploy/hss db.sql

/opt/OpenIMSCore/FHoSS/scritps/userdata.sql

26

La plataforma provee una interfaz de configuracion Web para el aprovisionamiento

de usuarios, la definicion de los servidores de aplicaciones, las reglas de enrutamiento

(iFC), los triggers points, entre otros elementos.

El primer trabajo fue entonces comprender el funcionamiento de todos elementos

que componen la plataforma y de las alternativas de configuracion necesarias para

brindar el servicio necesario a cada usuario.

Una guıa de instalacion y de utilizacion fue desarrollada para detallar las fun-

cionalidades y las configuraciones hechas durante este proyecto. Este documento ex-

plica en un principio los conceptos tecnicos para comprender el funcionamiento de la

plataforma y luego describe las etapas de instalacion y configuracion de esta.

La etapa siguiente fue de probar la plataforma con clientes PC y luego interconec-

tarla con un servidor de presencia.

5.1.1.2 Tests

Para probar el sistema, clientes IMS fueron conectados a la plataforma. Una de

las primeras dificultades fue de encontrar un cliente adecuado para probar todas las

funcionalidades de esta. Luego de una busqueda exhaustiva de clientes IMS, uno de

ellos fue elegido por ser el que satisfacıa la mayor parte de los requerimientos, normas

y funcionalidades para probar la presencia y la lista de contactos (agenda), que son

los servicios con mayor interes por el momento para el cliente Operador. Este fue el

cliente ”Mercuro IMS Client”[12].

El primer trabajo realizado fue ingresar usuarios a la base de datos del HSS. Para

esto se debıan proveer los diferentes identificadores de usuarios a traves de la pagina

web:

Subscripcion en IMS(IMSU), es una por usuario, para identificarlo en el sis-

tema. A esta subscripcion se le debe asociar a lo menos un IMPI y un IMPU.

Identificacion Privada (IMPI), es a lo menos una por usuario y almacenada en el

HSS de manera permanente. El del tipo [email protected] y es usada para

la identificacion y autentificacion del usuario en la red y no para enrutamiento.

27

Identificacion Publica (IMPU), es una o mas por cada usuario y sirven par el en-

rutamiento de las llamadas SIP. Son de la forma SIP URI sip:[email protected]

o tel URI tel:+56322010203

Tambien se proporcionaba la contrasena para la autentificacion.

La primera fase de las pruebas fue de simplemente registrar un usuario en la

plataforma. Una vez que este test fue realizado con exito, el paso a seguir fue in-

terconectar al sistema un servidor de Presencia.

Para esto, se definio un filtro de enrutamiento (iFC),realizado por el S-CSCF, para

que analizara las expresiones regulares de los paquetes SIP donde todos los paquetes

que tuvieran una cabecera con el evento (Event) de presencia (presence), se enviaran

al servidor de Presencia.

Todos los paquetes fueron enviados correctamente al servidor de presencia, com-

probado a traves de Wireshark (sniffer), el cual estaba configurado para escuchar el

trafico SIP sobre los puertos:

4060 (P-CSCF)

5060 (I-CSCF)

6060 (S-CSCF)

5060 (Servidor de Presencia)

La plataforma responde bien a las expectativas, y como la escala de pruebas no es

muy grande (como maximo una decena de usuarios registrados), ningun problema de

sobrecarga de red fue observado y el servicio fue rendido rapidamente. Para el caso

de una experimentacion, el nucleo IMS satisface largamente las necesidades tecnicas.

5.1.1.3 Evoluciones Posibles

Existen otras funciones de control adicional de la arquitectura IMS para completar

las funciones del nucleo recientemente implementado, en especial el Session Border

Controller (SBC).

28

Session Border Controller maneja el control de la senalizacion y de los flujos mul-

timedia necesarios en la definicion, conexion y desconexion de sesiones en IMS. Per-

mite controlar las llamadas que pueden situarse a traves de una red privada que genera

ciertos problemas de cortafuegos y de NAT (Network Address Translation).

La implementacion de esta funcion es fundamental sobre todo si se considera que

el acceso a la plataforma se hace desde una red privada, que es generalmente lo mas

usado.

5.1.2. Servidor de Aplicaciones Open Source

Los servidores de aplicaciones como fue explicado anteriormente, son un elemen-

to clave en la arquitectura IMS. Tener AS conectados al nucleo IMS para proveer

servicios y evaluar sus capacidades es uno de los trabajos que fue realizado poste-

riormente en el proyecto S-IMS. El Servidor de Presencia y Servidor XDM fueron

evaluados por su rol fundamental en la utilizacion del estandar RCS.

Luego de una busqueda de diferentes soluciones existentes en el mercado, una

solucion de servidor de aplicaciones Open Source atrajo la atencion del equipo.

Este ultimo fue instalado para evaluar su madurez y que tan conforme es con re-

specto a las normas (OMA 1.0, OMA 2.0). El objetivo es de considerarlo como una

alternativa a las soluciones de editores, porque el tiene la ventaja de un costo de licen-

cia nulo, lo que permite invertir la diferencia en otros servicios asociados. Ademas, la

evolucion de los programas de codigo abierto es mucho mas rapida y dinamica gracias

a la contribucion activa de todos los usuarios que pertenecen a la comunidad.

Mobicents es el servidor de aplicaciones SIP de codigo abierto sobre la plataforma

Java mas conocido. Facilita la implementacion de nuevos servicios de manera simple y

rapida. Diferentes funcionalidades son provistas por este servidor, dentro de las cuales

se puede destacar [13]:

JAIN SLEE: La plataforma Mobicents tiene un servidor conforme a la norma

JSLEE (Java 1.0 que utiliza ciertas caracterısticas propuestas por JAIN SLEE

29

1.1). JAIN es un conjunto de APIs (Application Program Interfaces) JAVA que

facilita el desarrollo de nuevos servicios para las redes de telecomunicaciones de

voz o datos, independientemente de los servicios utilizados (material). Ademas,

como JAIN esta basada en la plataforma JAVA, introduce la portabilidad de

servicios entre sistemas y permite el acceso seguro a los diferentes recursos de

las diferentes redes.

SIP SERVLET: Mobicents SIP Servlets es la primera implementacion de Codi-

go Abierto certificada conforme a la especificacion de Servlet SIP 1.1 (JSR 289

Spec). Estas permiten el desarrollo rapido de aplicaciones SIP.

MEDIA SERVER: Este servidor se encarga de la difusion, el registro y la ini-

cializacion de conferencias entre diferentes tipos flujos multimedia.

Presence Server: El servicio de Presencia de Mobicents esta desarrollado sobre

Jboss y contiene un servidor de Presencia y un servidor XDM (servidor que

permite manejar la agenda de contactos).

5.1.2.1 Instalacion y Configuracion

Existen diferentes versiones disponibles de la plataforma Mobicents. Es posible

instalar ya sea un servicio (Presence Service, Media Server, Sip Servlet) en modo

estadalone o el conjunto de servicios con la version integrada.

Para probar las diferentes funcionalidades y no solo el de la presencia fue instalada

la version integrada de Mobicents (( mobicents-all-1.2.1.GA-jboss-4.2.3.GA )) que in-

cluye mobicents JAIN SLEE, mobicents Sip-Servlets, Sip-Presence Service et Media

Server.

La guıa de usuario desarrollada por la comunidad fue utilizada para instalar y luego

configurar el servidor. Los forums y las listas de correo fueron muy utiles tambien para

resolver los problemas, sobre todo en el proceso de instalacion.

La plataforma fue instalada en un maquina con el sistema operativo Red Hat En-

treprise 5 Linux 2.6.18-128.el5 procesador x86 64. Como toda esta escrito en Java, el

30

unico pre-requisito es instalar java en version 1.5 o superior.Luego de descargar la version a instalar, se descomprime el paquete para instalar

Mobicents:

#mkdir /mobicents-all-1.2.1

#cd /mobicents-all-1.2.1

#jar {xvf mobicents-all-1.2.1.GA-jboss-4.2.3.GA.zip

La estructura de los directorios es la que muestra la figura 5.2.

Figura 5.2: Estructura de directorios de Servidor Mobicents

Donde:

Jboss-4.2.3.GA contiene JBossAS, JAIN SLEE, Sip Servlets, Media Server y

otros servicios de base.

Resources contiene varios Resource Adaptors para diferentes protocolos (SIP,

HTTP, XMPP, etc)

Sip-presence contiene todos los scripts para el Servicio ”Sip-Presence”

Examples contiene algunos scripts de ejemplo para probar los servicios

Documentation contiene toda la documentacion del Servidor

La familiarizacion con nuevas plataformas de desarrollo, especialmente Jboss, fue

fundamental para la completa comprension del funcionamiento y de la configuracion

de Mobicents.

31

Una guıa de instalacion y de utilizacion fue desarrollada para detallar la arquitec-

tura de la solucion; los conceptos mas importantes y la configuracion utilizada en el

lab Capgemini, como muestra el diagrama de red de la figura 5.3.

Figura 5.3: Diagrama de Red de servidor Mobicents y OpenIMS en lab Capgemini

5.1.2.2 Informacion de debugging

Para realizar los tests y analizar bien el funcionamiento de esta plataforma, fue

necesaria la configuracion de la informacion de debugging mostrada y almacenada por

el sistema. Para esto se configuro el archivo ((/mobicents-all-1.2.1/jboss-4.2.3.GA/

server/default/conf/jboss-log4j.xml)).Inicialmente, para que Jboss no muestre todas las informaciones en la pantalla, se

comento la lınea que hace referencia al apendice CONSOLE:

<root>

<level value="INFO"/>



<appender-ref ref="FILE"/>

</root>

32

Luego, para generar los archivos de log especıficos para cada servicio se crearon

nuevos appenders y loggers.Por ejemplo, para activar el nivel de debug del servidor XDM el appender es el

siguiente:

<appender name="XDM" class="org.jboss.logging.appender.DailyRollingFileAppender">

<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>

<param name="File" value="${jboss.server.log.dir}/xdm.log"/>

<param name="Append" value="false"/>

<param name="DatePattern" value="’.’yyyy-MM-dd"/>

<layout class="org.apache.log4j.PatternLayout">

<param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>

</layout>

</appender>

El nuevo appender se llama XDM y guarda las informaciones en el archivo local

((/mobicents-all-1.2.1/jboss-4.2.3.GA/server/default/log/xdm.log)).Luego fue creado el logger quien define cuales informaciones van a ser guardadas

en el appender referenciado.

<logger name="org.openxdm.xcap.server">

<level value="DEBUG"/>

<appender-ref ref="XDM" />

</logger>

<logger name="org.mobicents.slee.xdm.server">

<level value="DEBUG"/>

<appender-ref ref="XDM" />

</logger>

Las clases org.openxdm.xcap.server y org.mobicents.slee.xdm.server incluyen to-

das las informaciones del servicio XDMS, entonces todas las informaciones de debug-

ging seran guardadas en el appender XDM. El mismo metodo fue usado para guardar

las informaciones de otros servicios como el de Presencia o SIP-Servlets.

La etapa siguiente fue de probar los servicios de Presencia y la agenda de con-

tactos con clientes PC conectados a la plataforma OpenIMS. Luego, algunos demos

fueron instalados para probar Sip-Servlet, Media Server y algunos servicios (o aplica-

ciones) en JAIN SLEE. Para terminar, las herramientas de desarrollo fueron instaladas

y usadas para modificar y desarrollar nuevas aplicaciones, en especial, la aplicacion

Click-to-Call y Presencia en Facebook.

33

5.1.2.3 Tests de aplicaciones

El objetivo de estas pruebas fue evaluar las aplicaciones y los usos disponibles

sobre la plataforma Mobicents.

5.1.2.3.1 Presencia-XDMS

El servicio de Presencia en Mobicents esta compuesto de tres servidores: Presence

Server, Resource List Server y XDM Server.

Los tres servidores son independientes, pero juntos trabajan para ofrecer el servi-

cio completo de Presencia [13].

Figura 5.4: Servicio de Presencia, Fuente Mobicents [13]

El servidor de Presencia es la entidad que acepta, guarda y distribuye las informa-

ciones de presencia. El servidor XDM es un elemento funcional de nueva generacion

de comunicaciones sobre IP y es el responsable de manejar los documentos XML de

los usuarios que son guardados en la red, como las reglas de autorizacion de presen-

cia, les informaciones permanentes de presencia, la agenda de contactos y la lista de

grupos de contactos ((( resource lists ))), entre otras. Finalmente, el servidor Resource

List es quien gestiona las suscripciones a la lista de contactos.

Las pruebas consistieron entonces en primer lugar en la creacion de una cuenta

en el servidor XDM para acceder con un cliente IMS registrado sobre la plataforma

34

OpenIMS.

Esto fue hecho a traves de la interfaz web, ingresando el IMSI del usuario y su

contrasena.

Agregar/eliminar/bloquear contactos y luego ver el cambio de estado de presencia

de estos fueron enseguida los tests realizados en la plataforma, a traves del cliente

Mercuro IMS Client.

La solucion propuesta por Mobicents parece muy robusta, pero faltan todavıa al-

gunas evoluciones para ser conforme a los estandares mas evolucionados (RCS1.0,

RCS2.0), sin embargo, estas si son consideradas en la roadmap (plan de accion) del

proyecto, y algunas seran integradas a finales del ano 2010.

5.1.2.3.2 Aplicacion Facebook

Entre los demos desarrollados por Mobicents el que llamo mas la atencion por su

interaccion con el mundo de las redes sociales fue el Click-to-Call en Facebook.

Click-to-Call (C2C) es una aplicacion bastante utilizada donde el objetivo es re-

alizar una llamada entre dos usuarios SIP una vez que un objeto (boton, imagen, texto)

es clickeado desde una interfaz Web.

La aplicacion Facebook C2C crea entonces una llamada entre dos cuentas SIP que

estan registradas en la plataforma desde el sitio Facebook. El abonado que utiliza esta

aplicacion debe asociar un numero de telefono o cuenta SIP a su cuenta de Facebook

y luego el puede hacer una llamada a alguno de sus contactos.

35

Figura 5.5: Aplicacion Facebook C2C

Para utilizar este demo fue necesario instalar el paquete sobre la plataforma Mo-

bicents y luego crear una aplicacion Facebook y configurarla para que ella pudiese

funcionar con la aplicacion C2C.

La aplicacion es bastante basica y su objetivo principal es de ilustrar la interaccion

de los SIP-Servlets y los HTTP-Servlets. De todas maneras fue bastante util para con-

siderar otros usos utilizando la red social, por ejemplo, mostrar toda la lista de amigos

con su estado de presencia para que el abonado seleccione a quien desea llamar.

La primera dificultad encontrada fue que, por razones de seguridad, Facebook blo-

quea todas las informaciones de contacto de cada cuenta (telefono, correo electronico,

cuenta de mensajerıa instantanea), por lo tanto es necesario pedirle a cada usuario que

ingrese una cuenta SIP o un numero de telefono para que sea asociado a su cuenta.

El segundo problema aparece cuando se desea realizar la llamada con el amigo

seleccionado de la lista: la aplicacion no tiene acceso a la informacion de contacto de

la cuenta seleccionada. En este caso existen dos soluciones concretas posibles:

36

Asociar manualmente un numero de telefono o cuenta SIP a cada contacto de

la lista de amigos de Facebook, cosa factible, pero poco transparente (para el

usuario) y costoso en cuando a memoria en el servidor;

Asociar automaticamente el numero de telefono o cuenta SIP de contacto de

un amigo cuando este tambien utiliza la aplicacion, mejor opcion en cuanto a

optimizacion de recursos, pero limitante ya que el usuario podrıa llamar solo a

aquellos amigos que tienen la aplicacion en su cuenta.

Estas dos soluciones son de facil implementacion, en incluso se pueden usar ambas

para un servicio mas completo.

Luego, se desarrollo la base de la aplicacion llamada “Facebook Presence” para

estudiar la factibilidad y estimar el tiempo necesario para desarrollar una aplicacion

que mostrara el estado de presencia del usuario conectado.

Una de las primeras tareas fue familiarizarse con las herramientas de desarrollo en

Java provistas por esta red social para comprender el funcionamiento y configuracion

de la aplicacion.

La aplicacion se basa en dos clases principales:

HttpSubscribeInitiationServlet.java : Este metodo es un http Servlet que definelos procesos a realizar cuando se realiza un GET. En este caso, se obtienen lasinformaciones del usuario, como cuenta y contrasena, y crea un mensaje SIPque inicia una sesion de presencia:

public void doGet (HttpServletRequest request,HttpServletResponse response)

throws ServletException, IOException

{

// Create app session and request

SipApplicationSession appSession = sipFactory.createApplicationSession();

SipServletRequest req =

sipFactory.createRequest(appSession, "SUBSCRIBE", from,to);

// Set some attribute

req.setHeader("Expires","60000");

req.setHeader("Event","presence");

req.setHeader("Supported","eventlist");

req.setHeader("Accept","multipart/related");

req.addHeader("Accept","application/rlmi+xml");

37

req.addHeader("Accept","application/pidf+xml");

req.setHeader("P-Asserted-Identity",fromAddr);

req.getSession().setAttribute("FromAddr",

sipFactory.createAddress(fromAddr));

req.getSession().setAttribute("user",

getServletContext().getInitParameter("user1"));

req.getSession().setAttribute("pass",

getServletContext().getInitParameter("pass1"));

logger.info("Sending request" + req);

// Send the INVITE request

req.send();

}

Este mensaje es enviado al servidor de presencia y es tratado por el SipServlet.

SipPresenceHandlerServer.java: Este es el SipServlet que define las accionesa realizar una vez que se recibe un subscribe, notify u otro mensaje SIP enel servidor. Para establecer una sesion, el servidor de presencia debe recibirinicialmente el mensaje SUBSCRIBE enviado por el http Servlet, para luegoenviar un NOTIFY con todas las informaciones de presencia. Este NOTIFYes analizado por el SipServlet para encontrar el estado de presencia y luegoenviarlo como respuesta a la pagina web.

protected void doNotify(SipServletRequest req) throws ServletException,

IOException {

//Definition of namespaces uses in the pidf xml

context.registerNamespace("ns0", "urn:ietf:params:xml:ns:pidf");

context.registerNamespace("ns4", "urn:ietf:params:xml:ns:pidf:data-model");

context.registerNamespace("ns2", "urn:oma:xml:prs:pidf:oma-pres");

context.registerNamespace("ns3", "urn:ietf:params:xml:ns:pidf:rpid");

context.registerNamespace("cp", "urn:ietf:params:xml:ns:pidf:cipid");

context.registerNamespace("caps", "urn:ietf:params:xml:ns:pidf:caps");

//get the status of the client "mercuro"

//first node "activities"

Element status2 = (Element) context.selectSingleNode("//ns3:activities");

//first node child of node "activities"

String status1= status2.getFirstChild().getNodeName();

status= status1.split(":")[1];

logger.info("******************presence status : " + status);

// Create a URLConnection object for a URL

URL url =

new URL("http://10.2.3.48:5080/presence-servlet-1.0/presence?presence="+status);

URLConnection conn = url.openConnection();

38

(HttpURLConnection)conn).setRequestMethod("GET");

// Send the request to the server

conn.connect();

Con esto, se obtiene la informacion de presencia del usuario conectado a la

aplicacion.

Estas modificaciones muestran un nivel basico de lo que podrıa ser mas adelante

una lista de amigos con su estado de presencia a traves de una de las redes sociales mas

usadas actualmente. Para generalizar esto y lograr visualizar el estado de presencia

de todos los contactos es necesario asociar el estado de presencia la cuenta y luego

recuperar esta informacion desde los otros usuarios conectados cada cierto intervalo

de tiempo para tener el estado actualizado.

En resumen se puede decir que el desarrollo fue bastante rapido, sobre todo gracias

a las herramientas de programacion y plugs-in puestos a disposicion por el servidor

Mobicents y tambien a la facilidad de desarrollo entorno al sitio de red social Face-

book.

5.1.2.4 El futuro de las aplicaciones IMS Open Source

Uno de los retos principales para los operadores de telefonıa movil hoy en dıa

consiste en encontrar los medios de monetizar las redes de nueva generacion para

asegurar la rentabilidad de las inversiones a largo plazo. Como las ganancias generadas

por las aplicaciones IMS es largamente incierto, el costo de inversion (CAPEX) y

luego los gastos de explotacion (OPEX) deben ser lo mas bajo posible.

Las soluciones disponibles actualmente en el mercado que realizan las funciones

del nucleo IMS y servidores de aplicaciones tienen un costo de licencia proporcional

al numero de usuario, entonces una implementacion para un operador puede significar

una inversion demasiado alta.

Una alternativa es utilizar soluciones Open Source, teniendo como ventaja un cos-

to de licencia nulo, lo que permite invertir la diferencia en servicios asociados.

Los trabajos realizados en torno a los servicios de presencia han permitido famil-

iarizarse con el producto, conocer sus ventajas e identificar los servicios que no son

39

aun conformes con el estandar RCS, principalmente para considerarla como una al-

ternativa en el caso de una posible integracion con la plataforma del cliente operador

para el lanzamiento comercial de RCS.

Se trata de una decision estrategica utilizar estas soluciones, ya que ellas no tienen

costo de licencia pero si son modificadas, estas modificaciones estaran disponibles

para la comunidad, por lo tanto, disponibles libremente para todos los usuarios (in-

cluyendo a la competencia). Esto es debido a que la mayorıa de los programas de

Codigo Abierto estan escritos con librerıas que tienen licencias del tipo GPL o LGPL

(ver Apendice B), y el derecho que tiene una empresa para modificar las fuentes y

luego su difusion depende directamente de estas licencias.

Posiblemente de aquı a algunos meses estas soluciones estaran mas completas,

debido a la velocidad que los programas libres evolucionan, entonces su utilizacion

sera mas viable.

En contra parte, eligiendo soluciones de editores conocidos que ofrecen servicios

maduros y completos (en especial los servidores de aplicaciones), el costo de licencia

y de mantencion es elevado.

Sea cual sea la solucion elegida, hay que encontrar un compromiso entre la cal-

idad de servicio, extensibilidad, interoperabilidad, seguridad, soporte y costo de la

solucion.

5.2. Contribucion directa al cliente

5.2.1. Estudio de Call-Flows RCS 2.0

El objetivo de este estudio fue describir los principales flujo de mensajes (Call

Flow) al usar el servicio (( Enhanced Address Book )) (EAB) como es descrito en las

especificaciones de GSMA RCS 2.0.

Un Call Flow muestra los mensajes SIP y XCAP intercambiados en la comuni-

cacion entre un usuario y uno o varios servidores, como muestra la Figura 5.6.

40

Figura 5.6: Ejemplo de Call Flow

La gestion global de la informacion de presencia de EAB en RCS se apoya prin-

cipalmente en los estandares:

OMA Presence SIMPLE 1.1

OMA XML Document Management 1.1

Ademas RCS se apoya sobre ciertos ıtemes especıficos descritos en versiones su-

periores del estandar OMA:

OMA Presence SIMPLE 2.0

41

OMA XML Document Management 2.0

Los ıtemes concernidos por estas ultimas especificaciones son los siguientes:

Gestion del icono del usuario (especificado desde la version RCS 1.0)

Gestion de las informaciones de presencia permanentes (novedad de la version

RCS 2.0)

Para realizar los flujos de mensajes fueron realizadas pruebas con equipos RCS y

clientes PC conectados a un servidor de presencia y XDMS integrados de una solu-

cion de editor de software. Diferentes escenarios fueron recreados y los paquetes in-

tercambiados fueron capturados, luego analizados y contrastados con la norma que

especifican EAB para finalmente detallar los flujos.Por ejemplo, un flujo de mensajes para subscribirse a la presencia de la lista de

contactos es:

SUBSCRIBE sip:[email protected];user=phone;pres-list=rcs SIP/2.0

To: < sip:[email protected];user=phone;pres-list=rcs>

From: sip:[email protected];user=phone;tag=userA01

Contact: <sip:10.67.1.132:5060>;+g.oma.sip-im;+g.3gpp.cs-voice;description="<UA-Test>"

P-Preferred-Identity: sip:[email protected]

CSeq: 1001 SUBSCRIBE

Expires:72000

Call-ID: sub01

Via: SIP/2.0/UDP 10.67.119.132:5060;branch=z9hG4bK9ff5604f19c85b1

Route: <sip:10.67.112.48:5060;lr>,<sip:[email protected]:5060;orig>;lr

Max-Forwards: 70

Event: presence

Accept: application/pidf+xml,application/rlmi+xml,multipart/related

Supported: eventlist

Privacy: none

Content-Length: 0

SIP/2.0 200 OK

To: <sip:[email protected];user=phone;pres-list=rcs>;tag=rcslistA01

From: <sip:[email protected];user=phone>;tag=userA01

Contact: <sip:192.168.0.1:5050;transport=udp>

CSeq: 1001 SUBSCRIBE

Expires: 360

Call-ID: subpres01

42

Via: SIP/2.0/UDP 10.67.119.132:5060;branch=z9hG4bK9ff5604f19c85b1

Record-Route: <sip:10.67.112.48:5060;lr;oai=001aa03ced96-1420992233-1-104-148-8nyu1>

Allow-Events: reg, presence, presence.winfo

Require: eventlist

Content-Length: 0

El documento entregado al cliente que contiene todos los Call Flow RCS 2.0 es un

documento de gran utilidad para el operador ya que en primer lugar permite conocer de

manera esquematica, sintetica y practica como el estandar RCS es puesto en marcha

y en segundo lugar permite al operador especificar a los proveedores de terminales

moviles las funcionalidades necesarias a fin de que los terminales sean conformes al

estandar RCS 2.0.

5.2.2. Test de solucion Push-to-Talk

En el proceso de innovacion previamente descrito, fue realizada una evaluacion

tecnica de una solucion del servicio Push-to-Talk.

Luego de un analisis exhaustivo del mercado de las soluciones PTT, una de ellas

fue seleccionada por ser la mas atractiva, madura y completa segun las necesidades

expresadas por el operador. Luego fue realizada una experimentacion tecnica de esta

solucion. Esta evaluacion incluye:

Evaluacion cualitativa del servicio (QoS) Push-to-Talk sobre la plataforma al-

bergada por el proveedor de la solucion.

Instalacion de la plataforma en el sitio de Capgemini y realizacion de pruebas de

QoS sobre esta. El objetivo es tambien de integrar posteriormente esta solucion

en la arquitectura IMS, e interoperar con un servidor de Presencia externo, ver

figura 5.7.

43

Figura 5.7: Diagrama de red de solucion PTT en sitio lab Capgemini

5.2.2.1 Metodologıa

Las pruebas tiene el objetivo de evaluar cualitativamente la QoS de la solucion

Push-to-Talk, especıficamente con respecto a:

Tiempo en controlar la llamada o ((grant the floor)): tiempo que toma el sistema

para dar el control de la sesion PTT al usuario, para que este pueda transmitir la

voz.

Tiempo en liberar la llamada o (( release the floor)): tiempo que toma el sistema

para liberar y dejar a la disposicion de otros usuarios el control de la sesion PTT.

Retardo del flujo de voz: retraso de la transmision de la voz entre el emisor y el

receptor.

Las pruebas realizadas son el resultado de la combinacion de diferentes escenarios.

44

Acceso : tipo de conexion a la red movil, 3G o 2G

Terminales: las sesiones PTT fueron establecidas entre dos terminales del mis-

mo tipo, y entre dos terminales diferentes T1 y T2.

Calidad de recepcion: 2/3 de las pruebas fueron hechas con una buena calidad

de recepcion radio (condiciones nominales) y el otro tercio fueron realizadas

en condiciones de recepcion bastante degradadas (una sola barra de recepcion

presente en el terminal).

La combinacion de las pruebas realizadas puede ser esquematizada como muestra

la Figura 5.8.

Figura 5.8: Escenarios de Tests

Se realizaron en total 520 tests, donde la evaluacion de cada criterio de tiempo fue

hecha sobre una escala de 5 valores, como muestra la tabla 5.1.

45

Percepcion Valor Nota

Inmediato menos de 1 segundo 5

Rapido entre 1 y 2 segundos 4

Medio entre 2 y 4 segundos 3

Lento mas de 4 segundos 2

Sin servicio Fallo del test 1

Cuadro 5.1: Notacion para cada criterio de evaluacion

Los pasos seguidos para realizar los test fueron:

1. Lanzar la aplicacion PTT en cada movil

2. Conectar el usuario a la plataforma

3. Apoyar sobre el boton PTT para obtener el control de la sesion y evaluar tiempo

de demora en obtener el control

4. Hablar y evaluar tiempo de retraso de la voz

5. Soltar el boton PTT para liberar la sesion y evaluar el tiempo de demora en

liberar el control.

5.2.2.2 Resultados

Con el conjunto de resultados obtenidos se construyeron graficos comparativos

entre los escenarios mas interesantes para el operador. Cada uno de estos graficos fue

comentado para dar una impresion general de la QoS percibida.

En forma global, y comparando las condiciones de la calidad de la recepcion de

senal, los resultados son los mostrados en la figura 5.9.

46

Figura 5.9: Resultados globales test QoS

En general, los resultados muestran que logicamente la QoS es menos buena si la

calidad de la recepcion esta degradada. A diferencia de un ambiente con buena recep-

cion donde mas de la mitad de los tests tuvo una nota 5 (sensacion de inmediatez), en

el ambiente con calidad de recepcion desfavorables mas de un 39 % de los resultados

tuvo una nota de 3 o menos, indicando que el retardo es bastante grande, perceptible

por el usuario. Aparecen tambien casos donde el servicio no es rendido, dado a las

malas condiciones de senal.

Un documento con el analisis de las pruebas de QoS y una evaluacion del proce-

so de instalacion de la plataforma en el lab Capgemini fue entregado al cliente, con

graficos comparativos entre diferentes escenarios.

La fase siguiente para el operador es probar directamente sobre la plataforma al-

bergada por Capgemini todos los servicios y los casos de uso interesantes para ellos.

Los usuarios fueron aprovisionados sobre la plataforma para que el operador pueda

hacer las pruebas tecnicas en un ambiente controlado, y pruebas comerciales, anal-

izando los casos de utilizacion mas atractivos para los futuros usuarios del servicio.

La etapa siguiente para el proyecto S-IMS es probar el interoperabilidad de la solu-

47

cion PTT con el nucleo IMS y el Servidor de Presencia. Los resultados seran tambien

el objeto de un analisis y posterior redaccion de un documento que sera entregado al

cliente.

48

Capıtulo 6

Conclusiones

IMS nace como respuesta a la necesidad de evolucion de las redes de comuni-

cacion actuales. La convergencia de Internet, la telefonıa movil y la telefonıa fija,

emerge para ofrecer una comunicacion fluida y transparente, mezclando los datos mul-

timedia, en tiempo real.

Como fue visto anteriormente, esta arquitectura proporciona a los operadores las

armas necesarias para poder intervenir en el mercado de Internet y de la informatica

ofreciendo servicios y aplicaciones que antes estaban reservadas solo para las in-

fraestructuras y redes informaticas.

Los trabajos presentados anteriormente responden a las necesidades y servicios

actuales, pero como las tecnologıas evolucionan rapidamente, reaccionar a estos cam-

bios es uno de los desafıos del proyecto S-IMS. Es por esto que las investigaciones y

experimentaciones estan enfocadas siempre en identificar las nuevas necesidades de

los usuarios y encontrar los nuevos usos de las tecnologıas.

Para los meses que siguen, la implementacion del estandar RCS en los telefonos

moviles es uno de temas que llama mas la atencion de los operadores. Los servidores

de aplicaciones que proveen los servicios descritos por el estandar, como el servidor

de Presencia y Servidor XDM, seran evaluados para encontrar aquella solucion que

ofrezca la mayor rentabilidad y la mejor escalabilidad del sistema.

49

En cuanto a los nuevos servicios, la convergencia Web 2.0 – IMS esta en fuerte

desarrollo debido a las oportunidades que ofrecen a los operadores en cuanto a:

Diseminar el soporte de servicios multimedia basados en IMS en paginas Web.

Posicionar IMS como una verdadera opcion para ofrecer servicios IP sobre tec-

nologıas tradicionales como Internet.

Sin duda alguna, el desarrollo de todas estas nuevas aplicaciones y servicios traen

consigo muchos desafıos en terminos de estandarizacion. A nivel tecnico, IMS de-

fine y asegura la convergencia en las capas de red y de servicios. Cumplir con los

estandares que definen las aplicaciones en IMS asegurara la interoperabilidad con

otros servicios, pero esto no garantiza el exito a nivel comercial de la aplicacion. Es

de vital importancia entonces considerar durante el desarrollo de estos servicios la vi-

abilidad, la complejidad, el modelo economico y de gestion para crear una verdadera

oportunidad para el operador ofreciendo un servicio atractivo y competitivo en el mer-

cado.

50

Bibliografıa

[1] 3G Americas. IMS Overview and Applications , Julio 2004.

[2] 3rd Generation Partnership Projet

http://www.3gpp.org

[consulta: Abril 2010]

[3] Bertrand, G. The IP Multimedia Subsystem in Next Generation Networks, 30 de

Mayo 2007.

[4] Eclipse. Open Source IDE

http://www.eclipse.org

[consulta: Junio 2010]

[5] Ericsson. IMS White Paper - The value of Using IMS, Octubre 2004

[6] Ericsson. Rich Communications Suite:Interoperabilite Avant Tout!, Noviembre

2010

http://www.blog-ericssonfrance.com/2009/11/rich-communication-suite-

interoperabilite-en-avant-toute

[consulta: 30 Julio 2010]

[7] European Communications. IMS Benefits, 20 Junio 2006

http://www.eurocomms.com/features/111230/IMS-benefits.html


51

[8] GSMA. About-us Communications.

http://www.gsmworld.com/about-us/index.htm


[9] GSMA. Rich Communications Suite White Paper v1.0, Octubre 2008.

[10] Internet Engineering Task Force.

http://www.ietf.org/rfc.html

[consulta: 20 Abril 2010]

[11] Jboss community.

http://www.jboss.org/

[consulta: Mayo 2010]

[12] Mercuro IMS Client

http://www.mercuro.net/


[13] Mobicents. The Open Source SLEE and SIP Server, 2008.

http://www.jboss.org/


[14] Open Mobile Alliance, 2010.

http://www.openmobilealliance.org/


[15] Open IMS. The Open Source IMS Core, 2008.

http://www.openimscore.org/


[16] Soleo Communications. Operator Services in IP Multimedia Subsystem (IMS)

White Paper, 2006.

[17] Sun Microsystems. JAIN SLEE Specification-JSR 22, 2002.

52

[18] The IMS Lantern Blog, 2004.

http://theimslantern.blogspot.com/


53

Apendice A

Aplicacion Facebook

A.1. SipPresenceHandlerServlet.java/*

* This is free software; you can redistribute it and/or modify it

* under the terms of the GNU Lesser General Public License as

* published by the Free Software Foundation; either version 2.1 of

* the License, or (at your option) any later version.

*

* This software is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

* Lesser General Public License for more details.

*

* You should have received a copy of the GNU Lesser General Public

* License along with this software; if not, write to the Free

* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA

* 02110-1301 USA, or see the FSF site: http://www.fsf.org.

*/

package org.mobicents.servlet.sip.example;

import java.io.IOException;

import java.io.ByteArrayInputStream;

import java.net.HttpURLConnection;

import java.net.MalformedURLException;

import java.net.URL;

import java.net.URLConnection;

import java.util.HashMap;

54

import java.util.Properties;

import java.util.Map;

import java.util.Collections;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;

import javax.servlet.Servlet;

import javax.servlet.ServletConfig;

import javax.servlet.ServletException;

import javax.servlet.sip.Address;

import javax.servlet.sip.AuthInfo;

import javax.servlet.sip.SipApplicationSession;

import javax.servlet.sip.SipErrorEvent;

import javax.servlet.sip.SipErrorListener;

import javax.servlet.sip.SipFactory;

import javax.servlet.sip.SipServlet;

import javax.servlet.sip.SipServletRequest;

import javax.servlet.sip.SipServletResponse;

import javax.servlet.sip.SipSession;

import javax.servlet.sip.SipURI;

import org.apache.log4j.Logger;

import org.apache.commons.jxpath.JXPathContext;

import org.apache.commons.jxpath.xml.DOMParser;

import org.apache.commons.jxpath.xml.XMLParser;

import org.w3c.dom.Element;

public class SipPresenceHandlerServlet extends SipServlet implements SipErrorListener,

Servlet {

private static Logger logger = Logger.getLogger(SipPresenceHandlerServlet.class);

private static final String CONTACT_HEADER = "Contact";

private SipFactory sipFactory;

public static String status = null;

public static final HashMap<String, String> presenceStates = new HashMap<String, String>();

static {

presenceStates.put("closed", "closed");

presenceStates.put("open", "open");

presenceStates.put("stepout", "stepout");

55

presenceStates.put("working", "working");

presenceStates.put("meeting", "meeting");

presenceStates.put("break", "break");

presenceStates.put("meal", "meal");

presenceStates.put("gohome", "gohome");

presenceStates.put("away", "away");

presenceStates.put("biztrip", "biztrip");

presenceStates.put("secret_on", "secret_on");

}

public SipPresenceHandlerServlet() {

}

@Override

public void init(ServletConfig servletConfig) throws ServletException {

super.init(servletConfig);

logger.info("the simple sip servlet has been started");

try {

// Getting the Sip factory from the JNDI Context

Properties jndiProps = new Properties();

Context initCtx = new InitialContext(jndiProps);

Context envCtx = (Context) initCtx.lookup("java:comp/env");

sipFactory = (SipFactory) envCtx.lookup("sip/FacebookPresence/SipFactory");

logger.info("Sip Factory ref from JNDI : " + sipFactory);

} catch (NamingException e) {

throw new ServletException("Uh oh -- JNDI problem !", e);

}

}

@Override

protected void doInvite(SipServletRequest req) throws ServletException,

IOException {

logger.info("Click2Dial don’t handle INVITE. Here’s the one we got : " + req.toString());

}

@Override

protected void doNotify(SipServletRequest req) throws ServletException,

IOException {

logger.info("Got NOTIFY");

logger.info("initial: "+req.isInitial());

int length = req.getContentLength();

if(length == 0){

logger.info("doNotify ContentLength 0");

56

}

if(length == 0){

logger.info("doNotify ContentLength 0");

SipServletResponse res = req.createResponse(SipServletResponse.SC_OK);

res.send();

return;

}else{

if(length > 0 /*&& type.equals("application/pidf+xml") */){

logger.info("doNotify ContentLength: " + length);

Address fromAddr = req.getFrom();

SipURI fromUri = (SipURI)fromAddr.getURI();

logger.info("presence fromUri : " + fromUri);

try{

byte[] content = null;

content = req.getRawContent();

logger.info("getRawContent");

ByteArrayInputStream bis = new ByteArrayInputStream(content);

XMLParser parser = new DOMParser();

Object obj = parser.parseXML(bis);

logger.info("parseXML");

JXPathContext context = JXPathContext.newContext(obj);

//Definition of namespaces uses in the pidf xml

context.registerNamespace("ns0", "urn:ietf:params:xml:ns:pidf");

context.registerNamespace("ns4", "urn:ietf:params:xml:ns:pidf:data-model");

context.registerNamespace("ns2", "urn:oma:xml:prs:pidf:oma-pres");

context.registerNamespace("ns3", "urn:ietf:params:xml:ns:pidf:rpid");

context.registerNamespace("cp", "urn:ietf:params:xml:ns:pidf:cipid");

context.registerNamespace("caps", "urn:ietf:params:xml:ns:pidf:caps");

//get the status of the client "mercuro"

//first node "activities"

Element status2 = (Element) context.selectSingleNode("//ns3:activities");

//first node child of node "activities"

String status1= status2.getFirstChild().getNodeName();

status= status1.split(":")[1];

logger.info("******************presence status : " + status);

}catch(Exception e){

SipServletResponse res = req.createResponse(SipServletResponse.SC_SERVER_INTERNAL_ERROR);

res.send();

return;

57

}

try

{

// Create a URLConnection object for a URL

URL url = new URL("http://10.2.3.48:5080/presence-servlet-1.0/presence?presence="+ status);

URLConnection conn = url.openConnection();

((HttpURLConnection)conn).setRequestMethod("GET");

// Send the request to the server

conn.connect();

logger.info("***********************CONNECTION ");

} catch (MalformedURLException e) {

logger.info("***********************Exception1 ");

} catch (IOException e) {

logger.info("***********************Exception2 ");

}

SipServletResponse res = req.createResponse(SipServletResponse.SC_OK);

res.send();

}else{

SipServletResponse res = req.createResponse(SipServletResponse.SC_BAD_REQUEST);

res.send();

log("doNotify end....");

return;

}

}

logger.info("doNotify ContentLength : " + length);

}

@Override

protected void doOptions(SipServletRequest req) throws ServletException,

IOException {

logger.info("Got : " + req.toString());

req.createResponse(SipServletResponse.SC_OK).send();

}

@Override

protected void doSuccessResponse(SipServletResponse resp)

throws ServletException, IOException {

logger.info("Got OK");

}

@Override

protected void doBye(SipServletRequest request) throws ServletException,

IOException {

58

logger.info("Got bye");

SipSession session = request.getSession();

SipSession linkedSession = (SipSession) session

.getAttribute("LinkedSession");

if (linkedSession != null) {

SipServletRequest bye = linkedSession.createRequest("BYE");

logger.info("Sending bye to " + linkedSession.getRemoteParty());

bye.send();

}

SipServletResponse ok = request

.createResponse(SipServletResponse.SC_OK);

ok.send();

}

/**

* {@inheritDoc}

*/

@Override

protected void doResponse(SipServletResponse response)


logger.info("SimpleProxyServlet: Got response:\n" + response);

super.doResponse(response);

}

@Override

protected void doErrorResponse(SipServletResponse response)


logger.info("Got response: " + response);

SipFactory sipFactory = (SipFactory) getServletContext().getAttribute(SIP_FACTORY);

if(response.getStatus() == SipServletResponse.SC_UNAUTHORIZED ||

response.getStatus() == SipServletResponse.SC_PROXY_AUTHENTICATION_REQUIRED) {

// Avoid re-sending if the auth repeatedly fails.

if(!"true".equals(response.getApplicationSession().getAttribute("FirstResponseRecieved")))

{

SipApplicationSession sipApplicationSession = response.getApplicationSession();

sipApplicationSession.setAttribute("FirstResponseRecieved", "true");

AuthInfo authInfo = sipFactory.createAuthInfo();

authInfo.addAuthInfo(

response.getStatus(),

response.getChallengeRealms().next(),

(String)response.getSession().getAttribute("user"),

59

(String)response.getSession().getAttribute("pass"));

SipServletRequest challengeRequest = response.getSession().createRequest(

response.getRequest().getMethod());

challengeRequest.addAuthHeader(response, authInfo);

logger.info("Sending the challenge request " + challengeRequest);

try {

logger.info("sending challenge request " + challengeRequest);

challengeRequest.send();

} catch (IOException e) {

logger.error("An unexpected exception occured while sending the request", e);

}

}

} else {

/*if(response.getStatus() == SipServletResponse.SC_SERVER_INTERNAL_ERROR){

SipServletRequest endSubscribe = response.getSession().createRequest("SUBSCRIBE");

endSubscribe.setExpires(0);

endSubscribe.send();

}*/

}

}

/**

* {@inheritDoc}

*/

public void noAckReceived(SipErrorEvent ee) {

logger.info("SimpleProxyServlet: Error: noAckReceived.");

}

/**

* {@inheritDoc}

*/

public void noPrackReceived(SipErrorEvent ee) {

logger.info("SimpleProxyServlet: Error: noPrackReceived.");

}

protected void doRegister(SipServletRequest req) throws ServletException, IOException {

logger.info("Received register request: " + req.getTo());

int response = SipServletResponse.SC_OK;

SipServletResponse resp = req.createResponse(response);

60

HashMap<String, String> users =

HashMap<String, String>) getServletContext().getAttribute("registeredUsersMap");

if(users == null) users = new HashMap<String, String>();

getServletContext().setAttribute("registeredUsersMap", users);

Address address = req.getAddressHeader(CONTACT_HEADER);

String fromURI = req.getFrom().getURI().toString();

int expires = address.getExpires();

if(expires < 0) {

expires = req.getExpires();

}

if(expires == 0) {

users.remove(fromURI);

logger.info("User " + fromURI + " unregistered");

} else {

resp.setAddressHeader(CONTACT_HEADER, address);

users.put(fromURI, address.getURI().toString());

logger.info("User " + fromURI +

" registered with an Expire time of " + expires);

}

resp.send();

}

public String getStatus(){

return status;

}

}

A.2. HttpSubscribeInitiationServlet.java

/*

*/

package org.mobicents.servlet.sip.example;

import java.io.IOException;

import java.io.PrintWriter;

import java.util.Iterator;

import java.util.Properties;

61

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;

import javax.servlet.ServletConfig;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.sip.ConvergedHttpSession;

import javax.servlet.sip.SipApplicationSession;

import javax.servlet.sip.SipFactory;

import javax.servlet.sip.SipServletRequest;

import javax.servlet.sip.SipSession;

import javax.servlet.sip.URI;

import org.apache.log4j.Logger;

public class HttpSubscribeInitiationServlet extends HttpServlet

{

private static Logger logger = Logger.getLogger(HttpSubscribeInitiationServlet.class);

private SipFactory sipFactory;

@Override

public void init(ServletConfig config) throws ServletException {

super.init(config);

logger.info("the servlet has been started");

try {

// Getting the Sip factory from the JNDI Context

Properties jndiProps = new Properties();

Context initCtx = new InitialContext(jndiProps);

Context envCtx = (Context) initCtx.lookup("java:comp/env");

sipFactory = (SipFactory) envCtx.lookup("sip/FacebookPresence/SipFactory");

logger.info("Sip Factory ref from JNDI : " + sipFactory);

} catch (NamingException e) {

throw new ServletException("Uh oh -- JNDI problem !", e);

}

}

/**

* Handle the HTTP GET method by building a simple web page.

*/

public void doGet (HttpServletRequest request,

HttpServletResponse response)

62

throws ServletException, IOException

{

String access = request.getParameter("access");

String callAuthCode = getServletContext().getInitParameter("call.code");

if (callAuthCode.equals(access)) {

String toAddr = "sip:" + getServletContext().getInitParameter("user1").trim() + "@"

+ getServletContext().getInitParameter("domain.name");

String fromAddr = "sip:" + request.getParameter("user").trim() + "@"

+ getServletContext().getInitParameter("domain.name");

//String secondParty = "sip:" + request.getParameter("from").trim()

// + "@" + getServletContext().getInitParameter("domain.name");

URI to = toAddr == null ? null : sipFactory.createAddress(toAddr)

.getURI();

URI from = fromAddr == null ? null : sipFactory.createAddress(

fromAddr).getURI();

// Create app session and request

SipApplicationSession appSession =

// ((ConvergedHttpSession)request.getSession()).getApplicationSession();

sipFactory.createApplicationSession();

SipServletRequest req = sipFactory.createRequest(appSession,

"SUBSCRIBE", from, to);

// Set some attribute

//req.getSession().setAttribute("SecondPartyAddress",

// sipFactory.createAddress(secondParty));

req.setHeader("Expires","3600");

req.setHeader("Event","presence");

req.setHeader("Accept","application/pidf+xml");

req.setHeader("P-Asserted-Identity",fromAddr);

req.getSession().setAttribute("FromAddr",

sipFactory.createAddress(fromAddr));

req.getSession().setAttribute("user",

getServletContext().getInitParameter("user1"));

req.getSession().setAttribute("pass",

getServletContext().getInitParameter("pass1"));

logger.info("Sending request" + req);

63

// Send the INVITE request

req.send();

}

// Write the output html

PrintWriter out;

response.setContentType("text/html");

out = response.getWriter();

// Just redirect to the index

out.println

("<HTML><META HTTP-EQUIV=\"Refresh\"CONTENT=\"0; URL=index.jsp\"><HEAD><TITLE></HTML>");

out.close();

}

}

64

Apendice B

Licencias GPL y LGPL

B.1. GPL

La Licencia Publica General de GNU (en ingles General Public License) es la

licencia que cubre mas de la mitad del grupo de programas libres que existen en el

mercado.

Esta licencia autoriza a cualquier persona o empresa a estudiar el funcionamiento

de un software libre y de adaptarlo a las necesidades especıficas si es necesario, mod-

ificando el codigo fuente. Es posible tambien distribuirlo, gratuitamente o no, mientas

que la licencia no sea alterada ni eliminada, y la integralidad de fuentes sea igualmente

distribuida.

El interes de utilizar esta licencia es garantizar la no-confiscacion de software libre,

al contrario de un software de dominio publico que puede verse transformado en un

software propietario.

Si una empresa modifica los codigos fuentes, ella no esta obligada a difundir los

cambios si estos son utilizados en forma privada, pero si la version modificada se

vuelve publica, la GPL exige que el codigo fuente modificado sea puesto a disposicion

de los usuarios bajo una licencia GPL.

65

B.2. LGPL

La Licencia Publica General Reducida de GNU (en ingles Lesser General Public

Licence) es utilizada por algunas bibliotecas, en especial en el caso de Mobicentes y

de OpenIMS.

Esta se parece a la GPL, pero la diferencia es que autoriza a enlazar la bibliote-

ca con un software propietario. La idea principal de esta licencia es de permitir la

difusion de bibliotecas libres para que estas puedan imponerse en lugar de las bib-

liotecas propietarias.

Es posible entonces utilizar estas bibliotecas y mejorarlas a traves de “exten-

siones”, pero en el caso que la biblioteca sea modificada (en su codigo fuente) estos

cambios tienen que ser distribuidos en la comunidad.

66

“innovacion y servicios en ip ... - telematica… · el trabajo presentado a continuacion...

Documents