La Plataforma Telcoblocks De Despliegue Y Desarrollo De Servicios Voip

Transcript

La Plataforma Telcoblocks de Despliegue y Desarrollo de Servicios VoIP Jonathan Gonz´ lez a Carlos A. Iglesias Felipe Echanique Depto Ingenier´a de Sistemas Telem´ ticos ı a Divisi´ n de I+D+i o Depto Ingenier´a de Sistemas Telem´ ticos ı a Universidad Polit´ cnica de Madrid e Germinus XXI (Grupo Gesfor) Universidad Polit´ cnica de Madrid e Ciudad Universitaria s/n 28040 Madrid Avda Manoteras, 32 28050 Madrid Ciudad Universitaria s/n 28040 Madrid [email protected] [email protected] [email protected] Resumen—Este art´culo presenta el entorno de desarrollo y ı despliegue de servicios VoIP propuesto dentro del proyecto TelcoBlocks. En concreto, se detalla el componente de personalizaci´ n o propuesto que facilita la personalizaci´ n de servicios construidos o con tecnolog´as JAIN SLEE o SIP Servlets. El componente ha ı sido aplicado al desarrollo de un servicio de personalizaci´ n de o tonos, as´ como a un servicio de personalizaci´ n de anuncios en ı o un servicio de Click to Dial. Palabras Clave—Telcoblocks, personalizaci´ n, VoIP, Java, SIP, o SIP Servlets, JAIN SLEE I. ´ I NTRODUCCI ON La convergencia de las redes de telefon´a tradicional e ı Internet [21] est´ proporcionando una nueva arquitectura para a el desarrollo de servicios telco en las as´ llamadas Redes ı de Nueva Generaci´ n (Next Generation Networks; NGN [3]). o Una de las principales caracter´sticas de NGNs [2] es el desı acoplamiento de redes y servicios, permitiendo que se ofrezca de forma separada y que evolucionen independientemente. Los principales retos para esta nueva arquitectura NGN son por una parte, proporcionar un entorno de ejecuci´ n o de servicios tolerante a fallos y con calidad de operadora (carrier grade), que sea al menos tan robusto y seguro como la actual Red de Telefon´a Conmutada (RTC); por ı otra parte, debe ofrecer un entorno flexible y abierto que ´ permita desarrollar nuevos servicios de forma agil, dado que la alta competitividad del entorno telco est´ demandando esta a flexibilidad. Para conseguir esta flexibilidad. Moyer [21] se˜ ala que n NGN debe ser m´ s abierta que RTC a los desarrolladores de a servicios, ofreciendo APIs abiertas y facilitando bloques de servicios primitivos que los desarrolladores puedan reutilizar. En esta l´nea, el software de telecomunicaciones NGN ha ı seguido tres enfoques: JAIN SLEE [16], Parlay [7] y SIP Servlets [22]. El desarrollo de aplicaciones web 2.0 complementa [13] los servidores de aplicaciones h´bridos JavaEE / SIP ofrecidos ı en los modelos de arquitectura orientados a servicios, y cuestiona si la capa de servicios IMS debe seguir siendo una capa separada, orientada a aplicaciones telco, o integrada con las aplicaciones web 2.0. Esta convergencia de servicios telco y web se est´ comenzando a denominar mashups telco a web2.0 [13]. En esta misma l´nea, la tecnolog´a web de ı ı mashups est´ comenzando a usarse para la construcci´ n de a o servicios telco por parte de los usuarios [9]. A pesar de disponer de estas facilidades, el desarrollo de aplicaciones en entornos telco a´ n no se ha popularizado, u debido a la complejidad de las tecnolog´as involucradas, ı as´ como a la falta de entornos que faciliten su adopci´ n. ı o El objetivo del proyecto Telcoblocks [8] es el desarrollo de una plataforma abierta que facilite el desarrollo, despliegue, prueba e integraci´ n de servicios VoIP, tanto en operadoras o como en empresas que disponen de una centralita VoIP. Telcoblocks es un proyecto orientado a los desarrolladores, con el fin de reducir dr´ sticamente los tiempos de desarrollo a y despliegue de nuevos servicios. Uno de los pilares del proyecto es la reutilizaci´ n de componentes y servicios para o la construcci´ n de nuevos servicios. o El resto del art´culo se estructura como sigue. La secci´ n II ı o presenta el contexto de esta investigaci´ n, que se enmarca o en el proyecto TelcoBlocks, detallando la plataforma de ejecuci´ n y desarrollo de servicios definida. A continuaci´ n, o o la secci´ n III detalla el componente de personalizaci´ n, o o objeto principal de este art´culo, que facilita la integraci´ n ı o de funcionalidades de personalizaci´ n en la construcci´ n o o de un servicio (anuncios, facturaci´ n, tarificaci´ n, etc.). La o o secci´ n IV presenta un caso de estudio del componente de o personalizaci´ n presentado en la secci´ n III y desplegado o o ´ en la infraestructura presentada en la secci´ n II. Por ultimo, o se presentan conclusiones del trabajo realizado y las l´neas ı actuales de trabajo en la secci´ n V. o II. T ELCOBLOCKS : UN ENTORNO PARA DESARROLLO , ´ EJECUCI ON Y PRUEBA DE SERVICIOS VO IP Telcoblocks nace con el objetivo de proveer una plataforma abierta para el desarrollo y ejecuci´ n de servicios de teleo comunicaci´ n para la Red de Nueva Generaci´ n (NGN[3]) o o empleando tecnolog´as JAIN SLEE [16], SIP Servlets [22] y ı Parlay [7]. El proyecto investiga en el desarrollo de herramientas de software libre para entornos telco que cumplan con los fuertes requisitos de disponibilidad y fiabilidad de estas redes. Como resultado, la plataforma resultante se liberar´ como c´ digo a o abierto con licencia GPL, lo cual supone un cambio de mentalidad frente el uso exclusivo de software propietario en este tipo de entornos. El proyecto tambi´ n innova en la aplicaci´ n de sistemas e o inteligentes a las telecomunicaciones. Frente el fen´ meno o emergente de la sobre-comunicaci´ n potenciado por el auge o de las comunicaciones personales, el proyecto investiga en la integraci´ n de t´ cnicas inteligentes para gestionar dichas coo e municaciones seg´ n las preferencias de los usuarios, as´ como u ı para facilitar la personalizaci´ n de servicios. o Figura 1. Plataforma de Despliegue de Servicios VoIP de Telcoblocks Telcoblocks enmarca los aspectos mencionados dentro de ´ procesos de desarrollo agil de servicios telco basados en tecnolog´as abiertas y est´ ndares, cuyo ahorro en costes y menor ı a time-to-market abre interesantes oportunidades de negocio a las PYMES para proporcionar servicios de telecomunicaci´ n o a usuarios finales. Telcoblocks desarrolla dos plataformas: la plataforma para despliegue de servicios (secci´ n II-A) y la plataforma de o desarrollo de servicios (secci´ n II-B). o II-A. Plataforma de Despliegue de Servicios VoIP ´ En los ultimos a˜ os, la gran aceptaci´ n que ha tenido la n o VoIP como soluci´ n a las comunicaciones corporativas de las o empresas ha favorecido al nacimiento de algunos proyectos de software abierto que permiten implementar la mayor´a de las ı caracter´sticas que ofrecen algunas de las PBX comerciales ı (Avaya, Cisco...) que desde el nacimiento de esta tecnolog´a ı han sido utilizadas por las grandes y medianas empresas. En la actualidad existen diferentes soluciones de software abierto para del despliegue de una infraestructura VoIP basada en el protocolo SIP [18]. TelcoBlocks pretende investigar en la integraci´ n de estas soluciones para crear una arquitectura o integrada que permita generar un entorno de pruebas y despliegue de servicios de forma sencilla utilizando diferentes elementos. El entorno b´ sico de despliegue de servicios VoIP de a Telcoblocks se ilustra en la figura 1 y consta de los siguientes elementos, que ser´ n descritos en la siguiente secci´ n: a o Centralita VoIP (PBX) (secci´ n II-A1). o Proxy SIP - Servidor de Registro (secci´ n II-A2). o Servidor Multimedia (secci´ n II-A3). o Servidor Telco de Aplicaciones (secci´ n II-A4). o II-A1. Centralita VoIP (PBX): Una PBX (Private Branch Exchange) es una central telef´ nica conectada directamente o a la red p´ blica de tel´ fono por medio de l´neas troncales u e ı para gestionar, adem´ s de las llamadas internas, las entrantes a y/o salientes con autonom´a sobre cualquier otra central ı telef´ nica. Los usuarios de una PBX no tienen asociada o ninguna central de tel´ fono p´ blica, ya que es el mismo PBX e u que act´ a como tal, an´ logo a una central p´ blica que da u a u cobertura a todo un sector mientras que un PBX lo ofrece a las instalaciones de una compa˜ ´a generalmente. nı Una centralita VoIP (PBX) ofrece: Salida a la Red Telef´ nica Conmutada (RTC): Los usuao rios registrados en el sistema podr´ n realizar llamadas a a la RTC. Llamadas a bajo coste: Una PBX es capaz de conectarse a diferentes proveedores de servicios de VoIP, permitiendo as´ la realizaci´ n de llamadas que ser´ n tarificadas a ı o a la plataforma por el proveedor con el que se realice la llamada. ´ La soluci´ n de c´ digo abierto m´ s empleada en el ambito o o a profesional es Asterisk [5]. Asterisk es una aplicaci´ n de o software libre que implementa las funciones de una central telef´ nica (PBX). La aplicaci´ n es compatible con diversos o o sistemas operativos (Linux, MacOS, Solaris y Microsoft Windows) aunque es mejor soportada en sistemas Linux. Como toda PBX, Asterisk permite la interconexi´ n de dio ferentes tel´ fonos que pueden ser registrados en la aplicaci´ n e o y ser localizados entre s´ mediante la marcaci´ n de diferentes ı o extensiones definidas en un plan de llamadas. Adem´ s, pera mite conectarse con proveedores de llamadas VoIP de forma que un tel´ fono registrado en Asterisk es capaz de realizar e llamadas a n´ meros de la RTC a bajo precio. u Una de las caracter´sticas m´ s importantes de Asterisk es ı a el hecho de que puede ser usado con diferentes protocolos de se˜ alizaci´ n de VoIP; entre ellos destacar H.323 y SIP aunque n o tambi´ n es muy utilizado el protocolo IAX (propietario de e Asterisk) [19] para comunicaci´ n entre diferentes PBX de este o tipo. El hecho de ser una aplicaci´ n de software libre la hace o realmente atractiva, debido a las mejoras que se van a˜ adiendo n en las nuevas versiones que son publicadas cada poco tiempo. Actualmente se encuentra publicada la versi´ n 1.4.x de o Asterisk a la espera de que la versi´ n de 1.6.x sea publicada o en los pr´ ximos meses. o Un proyecto que ha sido analizado por su sencillez de configuraci´ n es Elastix [27] que incluye junto con un Asterisk o configurable desde una interfaz web (FreePBX) un sistema de facturaci´ n muy sencillo de configurar. o II-A2. Proxy SIP - Servidor de Registro: Cada usuario tiene una direcci´ n l´ gica que es invariable o o respecto de la ubicaci´ n f´sica del usuario. Una direcci´ n o ı o l´ gica del protocolo SIP es de la forma usuario@dominio o es decir tiene la misma forma que una direcci´ n de correo o electr´ nico. La direcci´ n f´sica (denominada ”direcci´ n de o o ı o contacto”) es dependiente del lugar en donde el usuario est´ conectado (de su direcci´ n IP). a o Cuando un usuario inicializa su terminal (por ejemplo conectando su tel´ fono o softphone SIP), el agente de usuario e SIP que reside en dicho terminal env´a una petici´ n con el ı o m´ todo REGISTER a un Servidor de Registro, informando e a qu´ direcci´ n f´sica debe asociarse la direcci´ n l´ gica del e o ı o o usuario. El servidor de registro realiza entonces dicha asociaci´ n. Esta asociaci´ n tiene un per´odo de vigencia y si no o o ı es renovada, caduca. Tambi´ n puede terminarse mediante un e desregistro. La forma en que dicha asociaci´ n es almacenada o en la red no es determinada por el protocolo SIP, pero es vital que los elementos de la red SIP accedan a dicha informaci´ n. o Adem´ s, en el caso de la arquitectura propuesta, este a servidor act´ a tambi´ n como servidor proxy o de redirecci´ n. u e o Para encaminar un mensaje entre un agente de usuario cliente y un agente de usuario servidor normalmente se recurre estos servidores. Estos servidores pueden actuar de dos maneras: 1. Como Proxy, encaminando el mensaje hacia destino. 2. Como servidor de Redirecci´ n generando una respuesta o que indica al originante la direcci´ n del destino o de o otro servidor que lo acerque al destino. La principal diferencia es que el servidor proxy queda formando parte del camino entre los extremos de la comunicaci´ n, o mientras que el servidor de redirecci´ n una vez que o indica al llamante c´ mo encaminar el mensaje ya no o interviene m´ s. a En el marco del proyecto Telcoblocks, se han estudiado las posibles soluciones de c´ digo abierto que se pod´an emplear o ı en esta arquitectura entre las que destacan: SER (SIP Express Router) [4], OpenSER [6] (OpenSIPS, Kamailio). Tras un an´ lisis de cada uno de los proyectos se opt´ por el uso de a o ´ OpenSIPS, ya que parte de la ultima versi´ n de OpenSER) y o ´ es de las soluciones m´ s utilizadas en el ambito profesional a junto con Asterisk. OpenSIPS es una aplicaci´ n que implementa un servidor o SIP. Originalmente pertenec´a a otro proyecto que sigue esı tando activo llamado SER (Sip Express Router). La principal diferencia entre ambos proyectos es el hecho de que OpenSER est´ llevado por una comunidad en lugar de una empresa, a lo que hace que r´ pidamente se implementen mejoras en el a servidor y las empresas se inclinen por la opci´ n de uso de o OpenSER. OpenSIPS es muy vers´ til para su implantaci´ n, a o permitiendo su instalaci´ n en sistemas con recursos limitados o as´ como en grandes servidores. Est´ escrito completamente ı a en C y orientado principalmente a equipos Linux/Unix. Esta aplicaci´ n tiene muchas caracter´sticas interesantes, entre las o ı que podemos destacar las siguientes: Location Service, registrar, servidor Proxy, servidor de redirecci´ n de llamadas, o gateway hacia otras redes que no son SIP. Al igual que Asterisk, OpenSIPS permite la interconexi´ n con diferentes o terminales y llamadas a trav´ s de la RTC. e II-A3. Servidor Multimedia: Un Servidor Multimedia (Media Server) permite la implementaci´ n de muchos de los o servicios mencionados en la descripci´ n de la centralita VoIP, o la diferencia fundamental es que no registra usuarios sino que solo se encarga del tr´ fico RTP. a De entre las soluciones que implementan un servidor multimedia, han sido consideradas la soluci´ n de Mobicents o (Mobicents Media Server [28]) y la soluci´ n del proyecto o SER, llamada SEMS [26]. Por facilidad de integraci´ n con el o ´ servidor SIP escogido se ha optado por esta ultima opci´ n. o SEMS es un servidor de aplicaciones y recursos multimedia para servicios VoIP basados en SIP. Presenta muy buenas prestaciones realizando algunos servicios b´ sicos como anuncios, a conferencia combin´ ndose, en algunos casos, con servidores a de aplicaciones externos. Gracias a su facilidad de uso y su framework de aplicaciones flexible, as´ como de su soporte ı Agentes de Usuario extremo a extremo, se puede unir en un mismo proceso la l´ gica de la aplicaci´ n con los recursos o o servidos por el servidor. Suele ser empleado con algunos de los servidores SIP analizados anteriormente (SER, OpenSER, OpenSIPS) de tal manera que se obtiene as´ un servicio de ı VoIP completo. Las principales funcionalidades de SEMS son las siguientes: Servicio de Conferencia: Permite conversaciones telef´ nicas por m´ s de dos usuarios simult´ neamente. o a a Servicio de Videoconferencia. Anuncio: Reproduce un recurso solicitado. Servicio de Voicemail: Servicio que almacena mensajes destinados a usuarios que en el momento de la recepci´ n de los mismos no pudieron atender la llamada. o Estos mensajes son enviados posteriormente al correo electr´ nico del usuario. o II-A4. Servidor Telco de Aplicaciones: Ejecuta la l´ gica o de negocio del servicio (ClickToDial, tarificaci´ n de llamadas, o personalizaci´ n de servicios) Telcoblocks actualmente soporta o dos tecnolog´as: JAIN SLEE [16] y SIP Servlets [22]. Como ı servidor JAIN SLEE, se ha escogido Mobicents [24], que soporta JAIN SLEE y SIP Servlets. Como servidor de SIP Servlets se ha escogido Sailfin [1], que soporta SIP Servlets, gracias a sus facilidades de desarrollo integradas con el IDE Netbeans. Una vez analizadas cada una de las soluciones escogidas para la arquitectura se puede concluir afirmando que las principales ventajas de esta arquitectura son: 1. Escalabilidad de servicios, gracias al uso de un Servidor Telco de aplicaciones 2. Soporte al protocolo AAA [25]: Integraci´ n Rao dius [12], Diameter [23], LDAP [20], gracias a la integraci´ n de OpenSIPS. o 3. Facturaci´ n y conectividad a RTC ofrecidas por Asteo risk. La plataforma de despliegue se ha empaquetado como una m´ quina virtual con VmWare [29], para que los desaa rrolladores puedan disponer de un entorno donde puedan probar r´ pidamente los servicios desarrollados. Dicha m´ quia a na virtual, contiene todos los elementos mencionados en la arquitectura, adeacuadamente configurados, para que el desarrollador s´ lo deba estar pendiente del nuevo servicio que o est´ implementando. e II-B. Plataforma de Desarrollo de Servicios VoIP Actualmente, el desarrollo de servicios telco manifiesta ciertas deficiencias, como son la baja productividad, el elevado tiempo dedicado al desarrollo as´ como las altas habilidades ı que necesitan los desarrolladores para conocer e integrar los actuales frameworks y componentes. Para resover estas deficiencias, Telcoblocks pretende abordar dos direcciones: mejorar la prueba de los servicios, y reducir el tiempo de desarrollo mediante la reutilizaci´ n de o componentes, que redundar´ n en una mejora de su calidad. a La plataforma de desarrollo requiere que se facilite el desarrollo con dos tecnolog´as, JAIN SLEE y SIP Servlets, ı que se presentan a continuaci´ n brevemente. o II-B1. JAIN SLEE: JAIN SLEE [16] es un modelo de componentes definido para un servidor de aplicaciones dise˜ ado espec´ficamente para aplicaciones telco. Est´ concebin ı a do como una plataforma de procesamiento de eventos de altas prestaciones y tolerante a fallos. Frente a las aplicaciones de empresa y web, s´ncronas e intensivas en datos por naturaleza, ı y que pueden ser modeladas e implementadas de forma adecuada con la tecnolog´a JEE (Java Enterprise Edition), ı SLEE est´ dirigido a aplicaciones as´ncronas, como son las a ı aplicaciones telco, y a procesar eventos de red combinando m´ ltiples protocolos. En la actualidad JAIN SLEE es el u est´ ndar Java para entornos de ejecuci´ n de l´ gicas de servicio a o o (Service Logic Execution Environment) [30]. La principal ventaja de JAIN SLEE es la estandarizaci´ n o del desarrollo y ejecuci´ n de servicios, de modo que se o cubran los diferentes niveles y, muy especialmente, la capa de acceso a los elementos de telecomunicaciones. A pesar de la estandarizaci´ n en el acceso a las capacidades de red ofrecida o por protocolos como INAP o CAP, los cuales permiten la interconexi´ n de redes, la complejidad de la implementaci´ n o o de servicios de forma directa y los requerimientos de las telcos de implementaci´ n (rendimiento, distribuci´ n, confiabilidad, o o etc.) hacen del desarrollo de servicios una actividad muy compleja, que cuenta con tan s´ lo un reducido grupo de o profesionales con la competencia adecuada. JAIN SLEE, por el contrario, ofrece un alto nivel de abstracci´ n para el acceso o a las capacidades de red, simplificando en gran medida la complejidad existente y, al mismo tiempo, ofreciendo Java como lenguaje de implementaci´ n. Paralelamente, JAIN SLEE o incorpora los conceptos tradicionales de la arquitectura Java (reutilizaci´ n de componentes, facilidades de administraci´ n o o y concurrencia, distribuci´ n, etc.). o JAIN SLEE, como paradigma de los entornos de nueva generaci´ n, rompe con la tradicional distinci´ n entre servicios o o de inteligencia de red y servicios IP. El concepto de adaptadores de recursos (RA) permite la integraci´ n entre diferentes o tecnolog´as en servicios innovadores y de nueva generaci´ n, ı o as´ como el despliegue de servicios tradicionales basados ı en se˜ alizaci´ n, como la gesti´ n de enrutado de llamadas. n o o ´ No existe un unico campo de servicios adecuado para JAIN SLEE; por el contrario, una de las principales ventajas es su gran alcance, el cual es adem´ s ampliable mediante la a incorporaci´ n de adaptadores de nuevos protocolos. Otra de o las ventajas es su definici´ n abierta, que elimina las barreras o tradicionales de integraciones propietarias. II-B2. SIP Servlets: SIP Servlets [22] proporcionan un modelo de desarrollo espec´fico del protocolo SIP, dado su ı papel fundamental en las nuevas arquitecturas IMS. Es una tecnolog´a alternativa a JAIN SLEE, que ofrece un modelo ı de desarrollo m´ s sencillo, aunque no permite manejar otros a protocolos diferentes de SIP y no es transaccional. Telcoblocks va a contemplar una l´nea de investigaci´ n ı o basada en el uso de una biblioteca de componentes, el cual ayudar´ a los ingenieros software a la selecci´ n e integraci´ n a o o de bloques para la creaci´ n de nuevos servicios. o La plataforma de desarrollo de telcoblocks, est´ formada a por los siguientes elementos: Plugins para Eclipse y Netbeans, que facilitan el desarrollo de forma gr´ fica de nuevos servicios. Actualmente se a ha implementado un diagrama de despliegue para definir y configurar la plataforma de despliegue de servicios, y un diagrama de bloques de servicio, para combinar m´ dulos desarrollados previamente. o Herramientas de prueba y simulaci´ n. El proyecto ino Figura 2. Arquitectura del Componente de Personalizaci´ n o tegrar´ el desarrollo de pruebas autom´ ticas as´ como a a ı la integraci´ n de pruebas que faciliten el desarrollo de o servicios. Biblioteca de componentes. A trav´ s del desarrollo de e casos de uso, se han identificado algunos componentes b´ sicos que se reutilizan en numerosos servicios. El a primero que se ha implementado es el componente de personalizaci´ n, que se presenta a continuaci´ n. o o III. ´ C OMPONENTE DE P ERSONALIZACI ON El objetivo del componente de personalizaci´ n es facilitar o la externalizaci´ n de la l´ gica del negocio de un servicio de o o telecomunicaciones. La personalizaci´ n [17] es un elemento o clave para tanto el descubrimiento de nuevos servicios, como la adaptaci´ n de los servicios existentes a las caracter´sticas o ı de los usuarios. La figura 2 muestra la arquitectura del componente de personalizaci´ n propuesto, que consta de los siguientes eleo mentos: Servidor de Conocimiento: es el encargado de gestionar la base de conocimiento, ofreciendo una interfaz para su acceso remoto La base de conocimiento define las reglas y hechos de la l´ gica de servicio. El servidor o est´ integrado con otro componente, llamado BRMS a (Business Rule Management System) que permite la edici´ n de la base de conocimiento mediante una interfaz o web. Se ha seleccionado la plataforma Drools [11] para su implementaci´ n. Ofrece diferentes interfaces para su o ´ acceso (clase Java en local, util para desarrollo, Servlet para acceso remoto, o bien JSON para las capa de presentaci´ n).Para el acceso remoto de este servidor o de conocimiento, los clientes emplean RuleAgents, que son clases Java que hacen de proxy del servidor de conocimiento, encapsulado toda la l´ gica de acceso. o Interfaz para tecnolog´a SIP Servlets. Los sip servlets ı atienden las peticiones SIP, haciendo peticiones al ser´ vidor de conocimiento cuando de el precisa algo, por ejemplo; en el servicio de anuncio personalizado, realiza una petici´ n al servidor de conocimiento, para saber o el anuncio a reproducir, antes de solicitar el anuncio a reproducir al servidor multimedia. Los SIP Servlets usan los componentes RuleAgent directamente. Interfaz para tecnolog´a JAIN SLEE. Para los comı ponentes JAIN SLEE, la integraci´ n se ha realizado o mediante un adaptador de recursos Rules-RA [10], que Figura 3. Secuencia Acciones Servicio Figura 4. Interfaz Web Click To Dial permite cargar realizar consultas a los componentes SBB. En este caso, es el adaptador de recurso el que emplea un componente RuleAgent para acceder al gestor de conocimiento, que es configurable mediante la interfaz de gesti´ n con JMX. o IV. ´ C ASO DE ESTUDIO : P ERSONALIZACI ON DE A NUNCIOS PARA EL LLAMANTE El servicio seleccionado consiste en la personalizaci´ n o de anuncios a un llamante combinado con un servicio de llamadas a trav´ s de la web (clickToDial, figura 4). Los e usuarios se registran en un portal web, especifican una serie de datos en su perfil, y pueden realizar llamadas pinchando en un bot´ n (servicio ClickToDial). En el momento en el o que se cursa la llamada, el sistema selecciona un anuncio auditivo, que es escuchado por el usuario, y una vez que termina el anuncio se cursa la llamada al destinatario. A cambio de escuchar la llamada, el usuario puede recibir alguna promoci´ n, tales como descuentos o minutos gratis. o La figura 3 muestra el diagrama de servicio desarrollado con el plugin para diagramas de bloques de Telcoblocks para Eclipse, desarrollado con Graphical Modeling Framework (GMF) [15] Primeramente, intentaremos abordar el problema desde el punto de vista de SIP. En el escenario de este servicio debe haber, al menos, dos clientes SIP registrados en nuestro servidor (llamante y destinatario de la llamada). El intercambio completo de mensajes durante la reproducci´ n de anuncio y o durante la conversaci´ n se muestra en la figura 5. o Una vez registrados ambos terminales, se procede a la realizaci´ n de la llamada. La petici´ n SIP de llamada(INVITE) o o es dirigida al registrar, que va a dirigir dicha petici´ n al o servidor multimedia (SEMS [26]) que reproducir´ el anuncio a solicitado. La cabecera de la petici´ n enviada por el registrar o al media server tiene un formato especificado en la RFC 4240 [14]. En la cabecera de esta petici´ n debe ir especificado el o anuncio que debe ser reproducido por el servidor multimedia, en un par´ metro llamado ”play=”. Una vez finalizada la a reproducci´ n del anuncio, se finaliza la sesi´ n para negociar o o la sesi´ n con el destinatario de la llamada. o Para realizar la selecci´ n del anuncio, se emplea el como ponente de personalizaci´ n previamente descrito. La base de o conocimiento consta de tres inferencias como se muestra en el diagrama de inferencias (figura 6: segmentaci´ n de la o poblaci´ n, clasificaci´ n de anuncios y selecci´ n del anuncio. o o o Tal como se indica, actualmente las dos primeras inferencias se realizan en la fase de registro, mientras que la selecci´ n o del anuncio se realiza en tiempo real con cada llamada. La segmentaci´ n de la poblaci´ n, consiste en clasificar o o cada uno de los usuarios de la plataforma en cada uno de los segmentos de poblaci´ n que se han definido a partir o de criterios de edad y estudio/trabajo. Esta segmentaci´ n se o realizar´ cada vez que un usuario se registra en el sistema, o a modifica uno de los campos que afecta a la segmentaci´ n. No o es necesario hacer una segmentaci´ n de la poblaci´ n entera o o cada vez que se modifica un usuario, sino que basta con solo insertar a ese usuario en la base de conocimiento, partiendo del hecho de que los perfiles de usuario son est´ ticos en este a caso. La clasificaci´ n de los anuncios sigue criterios parecidos, o clasific´ ndolos en categor´as de contenidos y precios cuando a ı los anuncios son dados de alta o modificados. Asi pues la clasificaci´ n de los anuncios atiende a los siguientes criterios: o ponentes desarrollados y simplemente definiendo una nueva base de conocimiento. Por otra parte, la misma base de conocimiento puede ser usada por varios servicios programados con tecnolog´as diferentes, gracias al uso de un servidor de ı conocimiento. El caso de estudio presentado ha mostrado la facilidad para integrar, por ejemplo, la RFC 4240 en el desarrollo del servicio de anuncios personalizados. Actualmente, se est´ trabajando en el uso del componente a ´ de personalizaci´ n en otros ambitos. Se ha desarrollado su o integraci´ n con un GoogleTalk mediante componentes JAIN o SLEE, lo que muestra la flexibilidad del componente desarrollado. Otra l´nea de trabajo actual es el entorno de desarrollo de ı Telcoblocks, para el que se est´ n desarrollado plugins para a Eclipse, realizados con EPF, como se han mostrado en este art´culo. ı AGRADECIMIENTOS Este proyecto ha sido cofinanciado por el Ministerio de Industria, Turismo y Comercio mediante el proyecto TelcoBlocks (TSI-020302-2008-16) bajo el programa Avanza I+D 2008. R EFERENCIAS [1] Sailfin - contenedor de sip servlets. Technical report, sun. [2] Conclusions from the ngn-sg. Technical report, ETSI 38th General Assembly meeting Nice, November 2001. [3] Definition of next generation network. Technical report, ITU, 2004. [4] Sip express router (ser. Technical report, iptel.org, 2004. [5] Asterisk the future of telephony. Technical report, asterisk.org, 2005. [6] Open sip express router (ser). Technical report, openser.org, 2007. [7] Osa parlay x 3.0 specifications. Technical report, ETSI, 2007. [8] Proyecto telcoblocks, 2008. Disponible en http://telcoblocks.germinus.com. [9] A. Alvaro Mart´nez Reol, C. Baladr´ n Zorita, A. Le´ n Mart´n, ı o o ı C. Garc´a Morch´ n, L. Calavia Dom´nguez, J. Aguiar P´ rez, and ı o ı e J. Caetano. Nuevos modelos de negocio: Servicios generados por el usuario. In XVIII Jornadas Telecom I+D, ISBN-13: 978-84-9860-1350, Octubre 2008, Bilbao, 2008. [10] A. Bhayani. Mobicents rules-ra, disponible en http://groups.google.com/group/mobicents-public/web/mobicentsrules-ra, 2007. [11] P. Browne. JBoss Drools Business Rules. PACKT Publishing, 2009. [12] A. R. C. Rigney, S. Willens. Remote authentication dial in user service (radius). Technical report, IETF - RFC 2865, 2000. [13] C. Chappell. IMS’s web 2.0 problem. Light Reading’s Services Software Insider, 2007. [14] A. S. E. Burger, J. Van Dyke. Basic network media services with sip. Technical report, ietc - RFC 4240, 2005. [15] Eclipse. Graphical modeling framework tutorial, disponible en http://wiki.eclipse.org/index.php/gmf tutorial. Technical report, 2006. [16] D. Ferry and S. Lim. JSR 22. JAIN SLEE API Specification. Technical report, Java Community Process, Mar. 2004. [17] R. Guarneri, A. M. Sollund, D. Marston, E. Fossbak, B. Berntsen, ˜ G.Nygreen, G. Gylterud, R. Bars, and A. Kerdraon. Report on the state of the art in personalisation, common framework. Technical report, ePerSpace - IST Integrated Project, 2004. [18] G. J.Rosenberg, H.Schulzrinne. Sip: Session initiation protocol. Technical report, ietf, 2002. [19] F. M. M. Spencer, B. Capouch. Iax: Inter-asterisk exchange version. Technical report, ietf - RFC 5456, 2009. [20] S. K. M. Wahl, T. Howes. Lightweight directory access protocol. Technical report, IETF - RFC 2251, 1997. [21] A. Moyer, S.Umar. The impact of network convergence on telecommunications software. Communications Magazine, 2001. [22] P. O’Doherty. Jsr 289 - sip servlet v1.1. Technical report, Java Community Process, 2008. [23] E. G. P. Calhoun, J. Loughney. Diameter base protocol. Technical report, IETF - RFC 3588, 2003. Figura 5. Diagrama de Trazas SIP en el servicio de anuncio personalizado Figura 6. Flujo de Inferencias para la personalizaci´ n de un anuncio o Edad, diferenciando si van dirigidos a mayores de edad o no. Tem´ tica (Ocio, Cultura, Evento...) a Precio, distinguiendo si va dirigido a un p´ blico con un u poder adquisitivo elevado o no. ´ La ultima fase es la fase de elecci´ n del anuncio emplea o una t´ cnica de puntuaci´ n (scoring) de los anuncios seg´ n su e o u afinidad al perfil del llamante (por edad, por aficiones, por nivel social (trabajo), regi´ n, etc) y a algunas caracter´sticas que o ı tengan en com´ n llamante, usuario llamado y anuncio. Una u vez puntuados todos los anuncios siguiendo estos criterios, se elige el de mayor puntuaci´ n que ser´ reproducido por el o a servidor multimedia para posteriormente cursarse la llamada solicitada. V. C ONCLUSIONES Y F UTUROS T RABAJOS El art´culo ha presentado las plataformas de despliegue y ı desarrollo para servicios VoIP de Telcoblocks, que facilitan y reducen el tiempo de desarrollo de nuevos servicios VoIP. El componente de personalizaci´ n facilita su reutilizaci´ n o o en varios niveles. Por una parte, facilita la inclusi´ n de o personalizaci´ n en nuevos servicios, reutilizando los como [24] L. Red HatMiddleware. Mobicents. the open source slee and sip server. disponbile en http://www.mobicents.org/index.html, 2009. [25] P. C. S. Farrell, J. Vollbrecht. Aaa authorization requirements. Technical report, ietf - RFC 2906, 2000. [26] S. Sayer. Sems-ng design overview inside the media server. Technical report, iptego GmbH, 2006. [27] B. Sharif. Elastix without tears. Technical report, PaloSanto Solutions, 2008. [28] D. Silas. Mobicents media server guide. Technical report, JBoss, 2008. [29] VMware Inc. P´ gina web de VMware, disponible en a http://www.vmware.com, 2009. ´ [30] Angel Cruz. Una nueva convergencia: ¿java en la red? Technical report, 2005.