Presentación de la arquitectura propuesta para el sistema iCom Centrex IP

Hoy llevé a cabo una presentación de la arquitectura que estamos definiendo para el sistema iCom Centrex IP.
En la reunión estuvieron:
Rodrigo Pérez. Gerente técnico del consorcio Sixlabs
Frank Sonnleitner. Product Manager
Víctor . Preventa
Mauricio. Gerente de productos
Luis. Arquitecto SixTrak
Ricardo Lara. Consultor Senior
xx. Consultor Senior

De la reunión surgió lo siguiente:

- La comunicación de la aplicación CaaS con los sistema OSS/BSS debe hacerse a través de un adaptador externo, que reciba de la aplicación CaaS los mensajes de manera estándar, y que los traduzca para el sistema del proveedor específico sobre el que se desplegará cada sistema. En la práctica, los sistemas OSS/BSS son legacy y tienen interfaces propietarias.

- Está bien hacer la composición en dos niveles, uno relacionado con las operaciones de telefonía, que en Sixlabs lo hacen con CCXML y otro sobre las aplicaciones del negocio, como el charging del producto, el rating, el portafolio de planes, aplicaciones externas, etc. En el segundo caso, la orquetación se hace a través de la interpretación de un script JavaScript en un motor java, que llama a los servicios de negocio, que son clases planas de java (POJO), principalmente por razones de despempeño.

- La arquitectura propuesta para el sistema iCom Centrex puede comprometer el desempeño para altos volúmenes de tráfico, sin embargo, en comparación con la de Sixlabs, hace énfasis en la reusabilidad y la facilidad de desarrollo y despliegue de nuevos servicios, gracias a la adopción de la especificación SIP Servlet.

- Vendrán más...

Prueba 1

Establecimiento de sesión entre 2 clientes SIP RFC 3261, usando el SigAS como outbound proxy.

Resultado: Los clientes su pudieron comunicar, sin embargo, el SigAS permaneció en la ruta permanentemente, posiblemente actuando no como proxy, sino como b2bua.

Interoperabilidad de los sistemas de Sixlabs con IMS

El plan de pasantía para la 3a y 4a semana consiste en probar la interoperabilidad de las aplicaciones o infraestructura de Sixlabs con IMS, usando Open IMS Core.

Sixlabs está construyendo una plataforma que se ubica en la capa de servicios de IMS, la cual está compuesta de dos partes principales:

Signaling Application Server (SigAS)
Es el encargado de manejar las comunicaciones SIP, usando un stack propietario de Sixlabs.

Business Application Server (BAS)
Gestiona la lógica del negocio para servicios de valor agregado, como sistemas prepago, incluyendo un sistema de charging.

Presentación del ambiente implantado

Hoy hice una presentación para todas las personas de Sixabs, incluyendo a los profesores Patricio Inostroza y Luis Guerrero de la Universidad de Chile.
Por solicitud del señor Rodrigo Pérez, gerente técnico del consorcio Sixlabs, hice una introducción a IMS antes de pasar a mostrar los resultados de la segunda semana del plan de trabajo, es decir, del ambiente completo para desarrollo de servicios IMS.
La presentación puede descargase de aquí

Integración del AS Sailfin con el core de IMS

IMS define la interacción con el servidor de aplicaciones a través de la interfaz ISC en conjunto con el aprovisionamiento de configuraciones en el HSS. Para comprender en detalle se puede ver el documento TS 29.228 del 3GPP.

El servidor de aplicaciones está conectado al core de IMS, a través de un Service Profile o de una Public Service Identity (PSI).

El service profile se configura a través de la interfaz de administración del HSS.

Inicialmente se crea el servidor de aplicaciones. Indicando la IP y el puerto.
Luego, el Trigger Point junto con el Service Point Trigger. Indicando la condición que debe cumplirse para que el core de IMS decida redirigir un diálogo al servidor de aplicaciones.
Después se crea el Initial Filter Criteria (IFC).
Luego, se crea el Service Profile.
Finalmente, se asocia el Service Profile creado al usuario que requiere el servicio.

Test de Open IMS Core

Bien, ayer hice pruebas sobre el core de IMS.

Por defecto OpenIMSCore acepta peticiones únicamente de la interfaz de loopback (127.0.0.1), así que, dado que instalé clientes en otras máquinas, fue necesario cambiar la configuración.

La IP de la máquina openimscore.ope-ims.test es 172.30.1.145, así que usé el script configurator.sh que viene con las fuentes para hacer la configuración de la nueva IP. Para esto puede ser de ayuda http://www.openimscore.org/installation_guide#annexc y http://letsgoustc.spaces.live.com/Blog/cns!89AD27DFB5E249BA!181.entry

Como clientes usé UCT IMS Client que instalé en máquinas separadas (2)

En un cliente registré a Alice y en el otro a Bob.

Primero probé en envío de mensajes instantáneos. Ok

Luego probé una llamada con audio. Ok

Instalación de Netbeans 6.1

Una buena combinación para montar un escenario de pruebas, es adicionar en la misma máquina del servidor de aplicaciones, un IDE que automatice la tarea del despliegue de aplicaciones y suministre herramientas para testing.

En este caso, se usará Netbeans 6.1.

Se descarga de www.netbeans.org (la versión Web y Java EE) y se siguen las instrucciones de instalación en http://www.netbeans.org/community/releases/61/install.html

Es indispensable tener instalado el jdk 5 o 6.

Con la instalación se crea en ubuntu un acceso en el menú Aplicaciones, Programación.