“innovacion y servicios en ip ... - telematica… · el trabajo presentado a continuacion...
Post on 30-Sep-2018
219 Views
Preview:
TRANSCRIPT
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 username@sims2.net 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:username@sims2.net
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="CONSOLE"/-->
<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:+33601020304@example.com;user=phone;pres-list=rcs SIP/2.0
To: < sip:+33601020304@example.com;user=phone;pres-list=rcs>
From: sip:+33601020304@example.com;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:+33601020304@example.com
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:homeproxy@10.67.112.48: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:+33601020304@example.com;user=phone;pres-list=rcs>;tag=rcslistA01
From: <sip:+33601020304@example.com;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
[consulta: 29 Julio 2010]
51
[8] GSMA. About-us Communications.
http://www.gsmworld.com/about-us/index.htm
[consulta: 28 Julio 2010]
[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/
[consulta: Abril 2010]
[13] Mobicents. The Open Source SLEE and SIP Server, 2008.
http://www.jboss.org/
[consulta: Abril 2010]
[14] Open Mobile Alliance, 2010.
http://www.openmobilealliance.org/
[consulta: Abril 2010]
[15] Open IMS. The Open Source IMS Core, 2008.
http://www.openimscore.org/
[consulta: Abril 2010]
[16] Soleo Communications. Operator Services in IP Multimedia Subsystem (IMS)
White Paper, 2006.
[17] Sun Microsystems. JAIN SLEE Specification-JSR 22, 2002.
52
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)
throws ServletException, IOException {
logger.info("SimpleProxyServlet: Got response:\n" + response);
super.doResponse(response);
}
@Override
protected void doErrorResponse(SipServletResponse response)
throws ServletException, IOException {
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
top related