ES2233590T3

ES2233590T3 - Estructura de ejecucion de servicios.

Info

Publication number: ES2233590T3
Application number: ES01610120T
Authority: ES
Inventors: Rico Werni Steenfeldt; Henry Gerard Smith
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2001-05-07
Filing date: 2001-11-22
Publication date: 2005-06-16
Anticipated expiration: 2021-11-22
Also published as: EP1257129B1; EP1257129A1; ATE288658T1; DE60108725D1; DE60108725T2

Abstract

Un método de gestión de una pluralidad de servicios (309, 310, 311; 1305; 1611, 1612, 1613) activados por un mensaje (1306; 1609) de un protocolo de sesión que controla una sesión de comunicaciones, cuyo método comprende las operaciones de: obtener un número de módulos de reglas, cada uno de los cuales comprende un número de reglas (308; 401, 402; 1606, 1607, 1608) de ejecución, cada una de las cuales especifica una condición (403, 404, 405) para invocar un servicio; procesar un primer módulo (1216) de dicho número de módulos de reglas, comprendiendo dicho procesamiento el procesamiento de al menos una parte de las reglas de ejecución del primer módulo de reglas en un orden predeterminado, haciendo una primera regla (1606) de ejecución que sea invocado un primer servicio (1611), si el mensaje cumple una primera condición, obteniéndose como resultado un primer mensaje modificado (1615), y haciendo una segunda regla (1607) de ejecución que sea invocado un segundo servicio (1612) con el primermensaje modificado como entrada, si el primer mensaje modificado cumple una segunda condición; dando lugar dicho procesamiento del primer módulo de reglas a un primer mensaje (1206) modificado acumulativamente; e invocar un segundo módulo (1217) de reglas de dicho número de módulos de reglas suministrando el primer mensaje modificado acumulativamente como entrada; caracterizado porque el primer módulo de reglas tiene asignado un privilegio indicativo de una autoridad para alterar una marca indicadora de bloqueo relacionada con una parte predeterminada del mensaje modificado acumulativamente, especificando dicha marca de bloqueo si dicha parte predeterminada del mensaje modificado acumulativamente puede ser modificada por servicios invocados desde al menos el segundo módulo de reglas.

Description

Estructura de ejecución de servicios.

Este invento se refiere a la gestión de una pluralidad de servicios relacionados con una sesión de comunicaciones que es controlada por un protocolo de sesión que proporciona información de sesión relativa a dicha sesión de comunicaciones.

Existe una demanda creciente de sesiones de comunicaciones interactivas a través de Internet, tales como las sesiones de telefonía IP, sesiones multimedia, reproducción directa de video en tiempo real, etc. Las sesiones de comunicaciones interactivas pueden ser controladas por protocolos de sesión, tales como el Session Initiation Protocol (SIP) que controla la iniciación, terminación y modificación de sesiones entre usuarios. El protocolo SIP no está relacionado con el tipo de sesión a iniciar, es decir con el contenido real de los mensajes SIP, sino más bien con la gestión de una sesión. Esta gestión incluye tareas tales como determinar donde reside realmente un usuario a contactar, proporcionar una descripción de la sesión a la que está invitado el usuario, negociar un formato común para describir las sesiones, etc.

El protocolo SIP está basado en el paradigma solicitud-respuesta. Por ejemplo, cuando se inicia una sesión, un usuario que llama envía una solicitud dirigida al usuario al que desea llamar, es decir al usuario llamado. El mensaje de solicitud es enviado al usuario llamado, típicamente a través de varios servidores proxy responsables de canalizar y entregar los mensajes. El usuario llamado envía entonces una respuesta, aceptando o rechazando la invitación. La respuesta es cursada en retorno a través de la secuencia de servidores proxy en el orden inverso.

Además de la gestión de sesiones estándar proporcionada por un protocolo de sesión, tal como el protocolo SIP, pueden implementarse servicios adicionales en el lado del usuario que llama, en el lado del usuario llamado, o en cualquiera de los servidores proxy intermedios.

En el presente contexto, el término "servicio" comprende una unidad funcional que puede ser añadida incrementalmente a un sistema base y que da lugar a una salida que es perceptible por un usuario, tal como un abonado, un administrador, etc. Por tanto, un servicio, por ejemplo la transmisión de una llamada, correo de voz, videoconferencia, etc, es una extensión modular de un sistema base, tal como un sistema para gestionar sesiones, por ejemplo un sistema SIP. El proceso de añadir y habilitar características específicas en un sistema base se denominará despliegue de características.

Durante una sesión, las características específicas pueden ser activadas por ciertos eventos. La activación, es decir el acto de invocar una aplicación dada al producirse un evento dado, está basado usualmente en relaciones contractuales entre abonados y proveedores de servicios. Si se despliega más de una característica en una red de servicios, y pueden activarse uno o más servicios simultáneamente para uno o más usuarios, entonces se producen interacciones entre características. En este contexto, los términos "interacción entre características" se refieren a la influencia o modificación de una característica por otra. La interacción entre características es un subproducto inevitable de las características modulares. Puede haber interacciones entre características deseables y no deseables. Sin embargo, constituye un problema que el comportamiento global de una red de servicios pueda volverse incontrolable si no se gestionan adecuadamente las interacciones entre características. Consiguientemente, la interacción entre características es un problema creciente, toda vez que el número y complejidad de una aplicación de servicios aumenta al surgir nuevas tecnologías, tales como la UMTS, que imponen demandas exigentes a las capacidades de las redes de servicios. Estos servicios pueden haber sido desarrollados independientemente y es necesario que los proveedores de servicios sean capaces de especificar como han de resolverse las instrucciones en conflicto asociadas a estos servicios y mediar en el conflicto en relación con el comportamiento por defecto del protocolo de comunicaciones utilizado.

Con el fin de evitar la interacción entre características, el comportamiento de características múltiples puede ser probado ad hoc o sistemáticamente, cuando se añade un nuevo servicio a una red de servicios, por ejemplo probando pares de características. Si se detectan casos de interacciones entre características durante pruebas o después del despliegue, el problema detectado puede ser corregido, por ejemplo rediseñando una o más de las aplicaciones de servicio implicadas.

La anterior aproximación requiere una cantidad considerable de recursos, en particular a medida que aumenta el número y complejidad de los servicios. Por tanto, constituye un problema que la técnica anterior no permita un escalado correcto acorde con el número y complejidad de las aplicaciones de servicio.

El artículo "Programming SIP Services" de Anders Kristensen y otros, publicado en IP Telephony Workshop 2000, describe una interfaz basada en JAVA entre servicios y un servidor SIP.

El artículo "An Architecture for Three Challenging Features" de Pamela Zave, publicado en Internet Telephony Workshop 2001, describe una arquitectura para tres características específicas dentro del contexto de la telefonía IP, a saber "Localización de Identificación", "Conmutación y Conferencia Espontánea" y "Correo". El diseño de estas características tiene en consideración los problemas de interacción entre características. Este artículo se refiere adicionalmente a una arquitectura Distributed Feature Composition (composición de características distribuidas) (DFC) y describe un sistema en términos de cajas de interfaz y cajas de características que son procesos concurrentes.

Sin embargo, es un problema para el sistema de la técnica anterior proporcionar mecanismos mejorados para evitar interacciones entre características debido al cambio de contexto de un servicio provocado por otro servicio.

De acuerdo con el invento, los anteriores y otros problemas son resueltos por un método de gestión de una pluralidad de servicios activados por un mensaje de un protocolo de sesión que controla una sesión de comunicaciones, como se define en la reivindicación 1ª.

En consecuencia, la invocación de servicios activados durante una sesión de comunicaciones es controlada por un número de reglas de ejecución que son procesadas en un orden predeterminado, controlando así el orden de servicios a invocar. Por consiguiente, se crea un mecanismo para activar aplicaciones basado en reglas de ejecución de servicios, que evita un comportamiento global arbitrario debido a un orden de ejecución incontrolado. Adicionalmente, editando las reglas de ejecución, pueden implementarse fácilmente estrategias de despliegue, creando así una infraestructura de despliegue de servicios flexible y de alta resolución, que proporciona una gran flexibilidad en la ordenación de la cadena de servicios, lo cual permite optimizar las prestaciones de la red de servicios.

Por tanto, de acuerdo con el invento, se crea una infraestructura flexible de despliegue de servicios que permite evitar sistemáticamente interacciones entre características cuando se gestiona un gran número de servicios complejos, por ejemplo cuando se añaden, eliminan, suspenden, reactivan o reubican servicios dentro de una red de servicios.

Se crea un marco normalizado para definir la ejecución de servicios que permite la distribución del problema de gestión de servicios entre participantes interesados independientes, creando así un método que es escalable con el número de servicios.

Una regla de ejecución incluye una o más condiciones para realizar una o más acciones, tales como invocar una aplicación de servicio.

Los términos "sesión de comunicaciones" se refieren a sesiones de comunicaciones entre usuarios de una red de comunicaciones, tal como una red TCP/IP, una red de área local, una red de área extensa, Internet, etc. Son ejemplos de sesiones de comunicaciones las sesiones de voz sobre Internet, telefonía IP, videoconferencia, reproducción directa de video en tiempo real a través de la red, etc.

Los términos "protocolo de sesión" se refieren a un protocolo que controla la sesión de comunicaciones, y en particular a la iniciación, terminación y modificación de sesiones. Preferiblemente, el protocolo de sesión está basado en mensajes de solicitud/respuesta transmitidos a través de los nodos de la red de comunicaciones entre los usuarios participantes de una sesión de comunicaciones. Un ejemplo de tal protocolo de sesión es el protocolo de iniciación de sesión (SIP). Otros ejemplos incluyen el conjunto de protocolos H.323, MGCP y protocolos relacionados, tales como los protocolos IPDC, SGCP, H.248, etc.

El término "servicio" se refiere a una unidad de funcionalidad que puede ser añadida incrementalmente a un sistema base. Un servicio puede ofrecer servicios a abonados, pero puede ofrecer también otros servicios, como tareas administrativas, al administrador de red. Son ejemplos de tales servicios la transmisión de llamadas, la llamada en espera, correo de voz, funciones estadísticas, retorno de llamadas, videoconferencia, video bajo demanda, servicios de ocultación de identidad, respuesta automática, etc. Puede implementarse un servicio utilizando diversas tecnologías, por ejemplo OSA, JAVA, CGI, PERL, C++, CPL, XML, etc.

En el contexto del protocolo SIP, un servicio es una aplicación o un número de aplicaciones ejecutadas localmente sobre un servidor SIP, por ejemplo CGI-Script o CPL-Script, o remotamente sobre un servidor de aplicaciones contactado por el servidor SIP. En el último caso, puede accederse e invocarse el servicio utilizando algún convenio de nominación estándar, es decir utilizando interfaces SIP Request-URI. Alternativamente, los servicios pueden autorregistrarse realmente en el servidor SIP utilizando, por ejemplo, un marco 3GPP OSA API. Los servicios SIP pueden agruparse en servicios de origen y de terminación, es decir los asociados con el usuario que llama y con el usuario llamado.

Los servicios pueden ser activados según condiciones en una cabecera de mensaje, un cuerpo de mensaje, etc.

Las capacidades funcionales del servidor SIP que se ofrecen a aplicaciones de servicio se denominan características de servicio, tales como acceder a una interfaz de programación para aplicaciones (API), por ejemplo a una interfaz OSA API en el lado del servidor, acceder a funciones estadísticas, etc. Las características de servicio pueden ser aplicaciones de servicio que se registran en el servidor SIP y ofrecen subsiguientemente su servicio a otras aplicaciones de servicio para su uso.

Una ventaja adicional del invento es que es independiente de la tecnología utilizada para la implementación de los servicios, del protocolo de transmisión de señales y de la plataforma. Por tanto, un operador de red no necesita saber anticipadamente los tipos de servicios que serán desplegados en la red de servicios, creándose así una infraestructura de despliegue de servicios robusta y susceptible de expansión.

A medida que se hace muy grande el número de participantes que desean registrar sus propios servicios, surge la necesidad de la escalabilidad. Adicionalmente, el número de abonados asociados con un dominio puede ser muy grande, haciendo así crítico el problema de la escalabilidad. Los servicios pueden ser activados e invocados por muchos tipos diferentes de eventos en base a una pluralidad de condiciones diferentes, tales como la concordancia de direcciones de origen y destino, sesiones dependientes del tiempo, o algunas otras condiciones preestablecidas. Adicionalmente, pueden invocarse servicios no relacionados con el protocolo SIP al producirse eventos SIP, por ejemplo si se cumplen ciertas condiciones en un instante dado. Pueden utilizarse diferentes tecnologías de servicio, tales como la tecnología CPL. Pueden invocarse servicios relacionados con el protocolo SIP al producirse eventos no relacionados con SIP, por ejemplo eventos HTTP. Pueden existir decenas de miles de servicios que pueden ofrecerse a decenas de millones de abonados, desde decenas de miles de proveedores de servicio de tercer participante. En consecuencia, la tarea de gestionar servicios e interacciones entre servicios es una tarea que puede adquirir una gran magnitud y complejidad para que la gestione un administrador.

De acuerdo con el invento, dichas reglas de ejecución están agrupadas en varios módulos de reglas, incluyendo cada módulo de reglas un número de reglas de ejecución; y el método comprende adicionalmente las operaciones de:

-: procesar un primer módulo de dicho número de módulos de reglas, resultando un primer mensaje modificado acumulativamente; e

-: invocar el procesamiento de un segundo módulo de dicho número de módulos de reglas proporcionando el primer mensaje modificado acumulativamente como entrada.

En consecuencia, agrupando las reglas de ejecución en módulos de reglas, es decir grupos de reglas de ejecución, el problema de la interacción entre características se divide en el problema de interacción entre características invocadas dentro del mismo módulo de reglas, y el problema de las interacciones entre módulos de reglas. Consiguientemente, una ventaja del invento es que se crea un método de gestión de interacciones entre características con capacidad de escalado en función del número de servicios. En particular, cuando son ofrecidos diferentes servicios por diferentes proveedores de servicios, es decir por diferentes compañías o diferentes organizaciones dentro de una compañía, un solo proveedor no puede acceder o puede no ser capaz de ensayar todos los servicios proporcionados. Por tanto, una ventaja del invento es que la tarea de analizar la interacción entre características puede dividirse de acuerdo con módulos de reglas y distribuirse a diferentes proveedores. Esto implica adicionalmente que los costes de la gestión de servicios puede delegarse en participantes independientes a medida que crece el número de abonados y servicios.

Los participantes comerciales que desean cargar/registrar y administrar servicios en un servidor SIP podrían ser el propietario, proveedor o administrador del servidor SIP, operadores de red, etc. Podrían también existir diferentes tipos de pequeños proveedores, por ejemplo operadores virtuales de telecomunicaciones, proveedores de servicios de internet, etc. Podrían también existir diferentes tipos de proveedores de servicios, tales como proveedores de servicios de aplicación, proveedores de servicios de contenido, proveedores de servicios/características especiales, etc. También podrían ser posibles participantes las organizaciones privadas, empresas y abonados.

Consiguientemente, de acuerdo con el invento, se consigue una gestión flexible, ampliable y escalable de relaciones contractuales entre los participantes con interés comercial, incluyendo la gestión de carga, estipulaciones, políticas y seguridad.

Una ventaja adicional del invento es que proporciona una estructura modular de reglas de ejecución, permitiendo así la incorporación de perfiles de servicio para usuarios, grupos de usuarios, abonados, etc. Una ventaja adicional de la modularidad es que permite la reutilización de módulos de reglas, facilitando así adicionalmente el mantenimiento del ambiente de servicios.

Cuando cada módulo de reglas tiene asociada una prioridad indicativa de un orden de tratamiento de dicho número de módulos de reglas, el orden de ejecución del módulo de reglas está determinado por un parámetro sencillo, proporcionando así un control fácil y transparente en relación con el orden de ejecución de módulos de reglas.

Cuando cada módulo de reglas corresponde a un propietario de módulo de reglas autorizado para editar el módulo de reglas, la autoridad administrativa para un módulo de reglas puede ser establecida fácilmente, facilitando así adicionalmente la delegación de dicha autoridad, por ejemplo para editar módulos de reglas, para análisis de interacción entre características dentro de un módulo de reglas, etc.

De acuerdo con el invento, el primer módulo de reglas tiene asignado un privilegio indicativo de una autoridad para alterar una marca indicadora de bloqueo relacionada con una parte predeterminada del mensaje modificado acumulativamente y especificar si dicha parte predeterminada del mensaje modificado acumulativamente puede ser modificada por servicios invocados desde al menos el segundo módulo de reglas. En consecuencia, se crea un mecanismo para permitir explícitamente o evitar alteraciones de atributos individuales o grupos de atributos de los mensajes por servicios subsiguientes. Por tanto, se crea una herramienta eficiente para evitar interacciones entre características debidas al cambio del contexto de un servicio por otro servicio. Este tipo de interacción entre características se denominará violación de supuesto de característica, que puede causar un comportamiento ambiguo o conflictivo de los servicios. Dado que la autoridad para bloquear y/o desbloquear ciertos atributos está vinculada a privilegios predeterminados asignados a módulos de reglas, el operador de red puede detectar el uso incorrecto de privilegios y evitar así un comportamiento no autorizado, aumentando de este modo la seguridad del método. La violación de privilegios puede ser detectada y resuelta sobre la marcha, por ejemplo mediante notificación y/o desactivación de servicios.

De acuerdo con una realización preferida adicional del invento, la operación de invocar el tratamiento del segundo módulo de reglas comprende adicionalmente la operación de activar dicha marca indicadora de bloqueo para evitar la modificación de la parte predeterminada del mensaje modificado acumulativamente por servicios invocados desde el segundo módulo de reglas, a no ser que la marca indicadora de bloqueo hubiese sido marcada como no activada por el primer módulo de reglas. Consiguientemente, por defecto, los atributos de mensaje están bloqueados para cambios subsiguientes cuando el control es transferido desde un módulo de reglas a otro. Por tanto, el segundo módulo de reglas puede modificar solamente atributos de mensaje que el primer módulo de reglas ha marcado explícitamente como desbloqueados, mejorando así adicionalmente el control de posibles interacciones entre características entre módulos de reglas y confinando la tarea de análisis de características a los módulos de reglas individuales. Esto da lugar a una escalabilidad mejorada adicionalmente.

Cuando la operación de obtener un número de reglas de ejecución comprende adicionalmente la operación de detectar una relación contractual predeterminada en base a la información de cabecera del mensaje, y seleccionar un número de módulos de reglas en base a dicha relación contractual detectada, se crea un método modular y escalable que permite ofrecer soporte a operadores para alojar servicios de terceras partes y servicios definidos por usuario. Al detectarse relaciones contractuales en base a la información de cabecera, estos servicios de terceras partes o definidos por usuario que son relevantes para un mensaje dado pueden ser identificados en base a las relaciones contractuales detectadas.

De acuerdo con otra realización preferida del invento, la operación de procesamiento del primer módulo de reglas comprende adicionalmente la operación de invocar un tercer módulo de reglas predeterminado. Consiguientemente, un módulo de reglas puede invocar a otros módulos de reglas, creándose así una herramienta poderosa para crear una jerarquía de módulos de reglas y mejorar adicionalmente la escalabilidad y flexibilidad de la infraestructura de despliegue. Una ventaja del invento es que permite la delegación de un módulo de reglas, del que es propietario un participante, en otro módulo de reglas del que es propietario otro participante. Un participante puede invocar aplicaciones en un orden que se considera adecuado por dicho participante, y transferir a continuación el control a otro participante que puede invocar entonces diferentes aplicaciones. El primer participante puede volver a obtener subsiguientemente el control para comprobar la salida del segundo participante. Cuando se realiza esta delegación, el primer participante puede decidir las propiedades de mensajes en las aplicaciones subsiguientes del mensaje cursado que puede cambiar dicho participante indicando qué propiedades de mensaje no pueden ser sobreinscritas para realizar una acción concreta.

Una ventaja del invento es que permite una delegación jerárquica de la autoridad administrativa en base a la capacidad para activar módulos de reglas desde otros módulos de reglas y para bloquear propiedades de mensaje.

Cuando el primer y segundo módulos de reglas están relacionados con una primera y una segunda listas de control de acceso respectivas que especifican derechos de acceso al primer o segundo módulo de reglas correspondiente, la violación de derechos de acceso puede ser detectada y resuelta, aumentando así adicionalmente la seguridad del método.

Cuando el primer y segundo módulos de reglas comprenden un primer y un segundo programas respectivos de ejecución inmediata (en adelante programas sript), se crea un lenguaje sencillo para escribir módulos de reglas. Por tanto, es fácil para un administrador comprender como expresar reglas y cual es el significado de las mismas, creándose así un mecanismo sencillo para ampliar la definición básica del lenguaje de reglas con funciones propietarias. Un ejemplo de tal definición de lenguaje es el XML.

Una ventaja adicional del invento es que crea un marco ampliable, es decir que es fácil añadir protocolos, tecnologías de servicio y propiedades de mensaje, por ejemplo si se añade un nuevo método al protocolo SIP.

Una ventaja adicional del invento es que crea un marco escalable, es decir es posible utilizar el mismo modo de expresar reglas en grandes redes ISP y en pequeños dispositivos de usuario final, por ejemplo teléfonos celulares
3G.

De acuerdo con otra realización preferida del invento, el mensaje comprende un primer y un segundo conjuntos de atributos; las reglas de ejecución están agrupadas en al menos una primera y una segunda clases de procesamiento de reglas de ejecución de acuerdo con restricciones correspondientes, en cuyo sistema la segunda clase de procesamiento está limitada solamente a modificar atributos del segundo conjunto de atributos; y la operación de procesamiento de las reglas de ejecución comprende adicionalmente la operación de procesar las reglas de ejecución de la primera clase antes de procesar cualquier regla de ejecución de la segunda clase. Consiguientemente, los servicios están divididos en grupos con comportamientos predeterminados en lo que se refiere a las partes de los mensajes de señalización que actualizan. Por tanto, los servicios pueden confiar en que el primer conjunto de atributos de mensaje no será alterado después de la ejecución de la primera clase de procesamiento. Esto crea un mecanismo adicional para dividir la tarea del análisis de interacción entre características en subtareas gestionables. En lo que sigue, se hará referencia también a las clases de procesamiento como puntos de procesamiento. Los conjuntos de atributos pueden comprender información de cabecera de mensaje y un cuerpo de mensaje que incluye el contenido real de la sesión. Los atributos pueden dividirse adicionalmente en diferentes tipos de datos de información de cabecera, por ejemplo atributos de señalización, etc.

Una ventaja adicional del invento es que crea medios para especificar como se permite la interacción entre aplicaciones.

Preferiblemente, las clases de procesamiento son tratadas en un orden predeterminado para solicitudes y respuestas y aplicadas a servicios de origen, de terminación y "cursado por".

De acuerdo con una realización preferida adicional del invento, el mensaje comprende un primer y un segundo conjuntos de atributos; las reglas de ejecución están agrupadas en al menos una primera y una segunda clases de procesamiento de reglas de ejecución de acuerdo con restricciones correspondientes, donde la segunda clase de procesamiento está limitada solamente a modificar atributos del segundo conjunto de atributos; y el método comprende adicionalmente la operación de repetir las operaciones de procesamiento del primer módulo de reglas e invocación del procesamiento del segundo módulo de reglas, donde en cada repetición el procesamiento del primer y segundo módulos de reglas está limitado a reglas de ejecución de una clase de procesamiento correspondiente, y en donde cada repetición da lugar a un mensaje modificado acumulativamente correspondiente que es utilizado como entrada para una repetición subsiguiente. En consecuencia, se crea una combinación de la división en módulos de reglas con el concepto de clases de procesamiento, proporcionándose así un marco de alta resolución para dividir los servicios de acuerdo con la propiedad administrativa y restricciones impuestas a los servicios.

Cuando las clases de procesamiento están definidas independientemente para reglas de ejecución activadas por solicitudes y respuestas del protocolo de sesión, la división de servicios en clases de procesamiento se divide adicionalmente de acuerdo con el tipo de mensaje, proporcionándose así una división más fina.

De acuerdo con una realización preferida, las clases de procesamiento corresponden a posiciones predeterminadas en un flujo de mensaje de recorrido circular de acuerdo con el protocolo de sesión, simplificándose así el análisis de interacción entre características.

Preferiblemente, las clases de procesamiento incluyen una primera clase de procesamiento de reglas de ejecución que inciden en propiedades de señalización del mensaje, una segunda clase de procesamiento de reglas de ejecución que inciden en el contenido del cuerpo de mensaje sin información de señalización del mensaje, y una tercera clase de procesamiento de reglas de ejecución que no inciden en las propiedades de señalización ni en el contenido del cuerpo de mensaje sin información de señalización del mensaje. En este caso, los términos "propiedades de señalización" comprenden propiedades de mensaje según los protocolos SIP y SDP que pueden hacerse coincidir en una condición de módulo de reglas para invocar un servicio.

Cuando se genera un mensaje modificado resultante cuando son procesadas todas las reglas de ejecución de la primera y segunda clases de procesamiento, la eficiencia del método aumenta adicionalmente, toda vez que pueden retornarse respuestas sin tener que esperar a servicios de la tercera clase de procesamiento.

De acuerdo con otra realización preferida del invento, la invocación del primer servicio genera adicionalmente un segundo mensaje modificado; y el método comprende adicionalmente las operaciones de procesar reglas de ejecución subsiguientes con el primer mensaje modificado como entrada; y procesar reglas de ejecución subsiguientes con el segundo mensaje modificado como entrada. Por tanto, dado que un servicio puede retornar salidas diferentes, cada una de las cuales es una entrada a una cadena de servicios subsiguientes, puede implementarse un árbol de cadenas de servicios en cascada.

De acuerdo con otra realización preferida adicional del invento, el método comprende además las operaciones de:

-: almacenar información relativa a los servicios que se ejecutan, e información relativa al orden en que se ejecutan los servicios:

-: recibir del primer servicio una solicitud para retornar una notificación al primer servicio, si se produce un evento predeterminado;

-: almacenar la solicitud en relación con la información almacenada; y

-: al producirse el evento, notificar el primer servicio de acuerdo con la información almacenada.

Por tanto, se crea un mecanismo eficiente para solicitar notificación de eventos futuros por parte de una aplicación de servicio, haciendo así posible la monitorización de aplicaciones, etc.

Cuando los módulos de ejecución comprenden programas script legibles por computador y el orden predeterminado de procesamiento de las reglas de ejecución está determinado por el orden de las reglas de ejecución en dichos programas script, se crea un mecanismo sencillo para controlar el orden de ejecución de servicios y el orden de notificación en lo que se refiere a eventos futuros por parte de un administrador de un módulo de reglas.

Preferiblemente, el orden de servicios en cascada está determinado por el orden de las reglas de ejecución dentro de un módulo de reglas y por el orden de módulos de reglas.

Cuando las reglas de ejecución están preparadas para ser actualizadas dinámicamente, es decir durante el funcionamiento de la red de servicios, se proporciona una gestión de servicio en tiempo real.

El invento se refiere adicionalmente a un sistema de procesamiento de datos que comprende un módulo de ambiente de ejecución de servicios destinado a invocar una pluralidad de servicios activados por un mensaje de un protocolo de sesión que controla una sesión de comunicaciones; caracterizado porque el sistema de procesamiento de datos comprende adicionalmente un medio de almacenamiento para almacenar una pluralidad de reglas de ejecución, cada una de las cuales especifica una condición para invocar un servicio; y porque el módulo de ambiente de ejecución de servicios comprende un módulo de motor de reglas destinado a: recuperar un número de reglas de ejecución; y procesar las reglas de ejecución en un orden predeterminado, provocando una primera regla de ejecución la invocación de un primer servicio, si el mensaje cumple una primera condición, lo cual da como resultado un primer mensaje modificado; y provocando una segunda regla de ejecución la invocación de un segundo servicio con el primer mensaje modificado como entrada, si el primer mensaje modificado cumple una segunda condición.

El invento se refiere adicionalmente, en un sistema de procesamiento de datos, a un módulo de ambiente de ejecución de servicios destinado a invocar una pluralidad de servicios activados por un mensaje de un protocolo de sesión que controla una sesión de comunicaciones; caracterizado porque el módulo de ambiente de ejecución de servicios comprende un módulo de motor de reglas destinado a: recuperar un número de reglas de ejecución, cada una de las cuales especifica una condición para invocar un servicio; y procesar las reglas de ejecución en un orden predeterminado, haciendo una primera regla de ejecución que se invoque un primer servicio, si el mensaje cumple una primera condición, que da lugar a un primer mensaje modificado; y haciendo una segunda regla de ejecución que se invoque un segundo servicio con el primer mensaje modificado como entrada, si el primer mensaje modificado cumple una segunda condición.

El invento se refiere adicionalmente a un programa que comprende medios de código destinados a realizar, cuando se ejecutan en un sistema de procesamiento de datos, las operaciones del método descrito anteriormente ya continuación.

El programa puede realizarse en un medio legible por computador. Los términos "medio legible por computador" pueden incluir una cinta magnética, un disco óptico, un disco de video digital (DVD), un disco compacto (CD o CD-ROM), un minidisco, un disco duro, un disco flexible, una memoria ferroeléctrica, una memoria de solo lectura programable eléctricamente borrable (EEPROM), una memoria rápida, una memoria de solo lectura programable eléctricamente (EPROM), una memoria de solo lectura (ROM), una memoria estática de acceso aleatorio (SRAM), una memoria dinámica de acceso aleatorio (DRAM), una memoria dinámica de acceso aleatorio síncrona (SDRAM), una memoria ferromagnética, un medio de almacenamiento óptico, dispositivos acoplados por carga, tarjetas inteligentes, una tarjeta PCMCIA, etc.

El invento se refiere adicionalmente a un método de gestión del despliegue de un servicio en una red de servicios, que comprende las operaciones de:

-: especificar en un programa script legible por computador un número de privilegios y derechos a conceder al servicio durante el funcionamiento;

-: analizar causas potenciales de interacción entre características; y

-: especificar una estrategia de despliegue como un conjunto de reglas de ejecución almacenadas como programa script de módulo de reglas legible por computador.

El invento se refiere adicionalmente a un registro de datos que comprende un módulo de reglas para ser utilizado en el método descrito anteriormente ya continuación.

Estos y otros aspectos del invento se pondrán de manifiesto con referencia a las realizaciones y con referencia a los dibujos, en los cuales:

La figura 1 ilustra diferentes tipos de interacciones entre características en una red de servicios de protocolo
SIP;

La figura 2 ilustra los elementos de red implicados en una arquitectura de servidor SIP de ambiente de servicios de acuerdo con una realización del invento;

La figura 3 ilustra esquemáticamente una arquitectura de sistema de un servidor SIP que soporta un mecanismo de reglas de ejecución de servicio de acuerdo con una realización del invento;

La figura 4 ilustra la estructura de un módulo de reglas de acuerdo con una realización del invento;

La figura 5 ilustra la agrupación de servicios en conjuntos de servicios restringidos de acuerdo con una realización del invento;

La figura 6 ilustra la agrupación de servicios en conjuntos de servicios restringidos correspondientes a posiciones en el flujo de mensajes SIP de recorrido circular de acuerdo con una realización preferida del invento;

La figura 7 ilustra el flujo de tratamiento entre servicios que pertenecen a diferentes puntos de procesamiento de acuerdo con una realización del invento;

La figura 8 ilustra la agrupación de servicios en módulos de reglas correspondientes a una autoridad administrativa de acuerdo con una realización del invento;

La figura 9 ilustra una realización del invento en la que los servicios están agrupados tanto de acuerdo con puntos de procesamiento, como de acuerdo con la autoridad administrativa;

La figura 10 ilustra el mecanismo de procesamiento de la realización de la figura 9 en el caso de varios módulos de reglas y varios puntos de procesamiento;

La figura 11 ilustra otros ejemplos de las reglas de procesamiento descritas en relación con la figura 9;

La figura 12 ilustra un tratamiento jerárquico de módulos de reglas de acuerdo con una realización preferida del invento;

La figura 13 muestra un ejemplo del flujo de contextos de evento de mensaje SIP y conjuntos de instrucciones de acuerdo con una realización del invento;

La figura 14 ilustra un mecanismo para gestionar varios conjuntos de instrucciones de acuerdo con una realización preferida del invento;

La figura 15 ilustra un árbol de cadenas de aplicaciones de servicio en cascada de acuerdo con una realización del invento;

La figura 16 muestra los componentes de programa de un ambiente de soporte de servicios de acuerdo con una realización del invento;

La figura 17 muestra operaciones realizadas por el módulo de interacción de servicios entre el procesamiento del módulo de reglas y el procesamiento de la aplicación de servicio en la realización de la figura 16;

La figura 18 ilustra la estructura de árbol del procesamiento de módulos de reglas de acuerdo con una realización del invento;

La figura 19 ilustra el procesamiento recursivo de módulos de reglas en una situación en la que aplicaciones de servicio generan nuevos contextos de evento de acuerdo con una realización del invento; y

La figura 20 ilustra un mecanismo de imposición de control de acceso en relación con módulos de reglas de acuerdo con una realización del invento.

La figura 1 ilustra diferentes tipos de interacciones entre características en una red de servicios SIP. Con la introducción del protocolo SIP, está surgiendo en Internet una nueva gama de servicios de conversación y en tiempo real. Estos servicios 101-105 pueden ser gestionados por terminales 106-108 de usuario final, también denominados agentes de usuario, o en uno o varios servidores intermedios 109 de red. Los servidores intermedios 109 de red pueden proporcionar servicios 102-103 de valor añadido a agentes de usuario de origen y/o terminación, pero también a los clientes de medios asociados y aplicaciones de servidor. Estos servidores intermedios pueden ser servidores proxy, servidores de redirección, servidores de aplicaciones dedicados, o incluso agentes de usuario.

Mensajes de comunicaciones enviados entre los agentes de usuario son canalizados por el servidor intermedio 109 a Internet 110 u otra red de comunicaciones. Un problema fundamental gestionado por un servidor intermedio 109 de protocolo SIP es cumplir las expectativas a nivel de servicio del usuario, mantener unas buenas prestaciones de red y permitir una definición flexible y escalable de nuevos servicios. Puesto que las prestaciones constituyen un tema clave, la arquitectura deberá permitir a algunos servicios ejecutarse en el servidor SIP. Puesto que puede no ser factible o posible ejecutar ciertos servicios en el servidor SIP, la arquitectura deberá permitir la ejecución de servicios también en servidores remotos.

Existe la necesidad de disponer de flexibilidad en la definición de servicios, porque la funcionalidad del servidor SIP no deberá definirse anticipadamente. En particular, pueden cargarse/registrarse continuamente servicios procedentes de una gama de fuentes, incluyendo proveedores de servicios y abonados.

El propietario del servidor SIP puede ser al mismo tiempo el proveedor de servicios SIP, el administrador y el proveedor de abonos. Se hará referencia a este participante con interés comercial como operador de red; puede ser un tipo de agente Telco o ISP. El operador de red puede poseer el nombre de dominio del servidor SIP y ofrecer características específicas de servicio a proveedores de servicios de tercera entidad. El operador de red instala aplicaciones de servicio y módulos de reglas en el servidor SIP, y ofrece servicios a abonados. En este caso, el operador de red actúa como proveedor de servicios y administrador de servicios. Un abonado tiene una relación contractual con el operador de red, con el fin de tener un abono y recibir los servicios de abonado ofrecidos por el servidor SIP. El abonado puede disponer de un servicio que le permita cargar aplicaciones de servicio y módulos de reglas en el servidor SIP. El abonado es propietario de estos servicios para uso privado, es decir se trata de servicios personalizados. Por simplicidad, todas las partes diferentes del operador u operadores de red y los abonados se denominarán proveedores de servicios de tercera entidad que tienen una relación contractual con el operador de red. Los propietarios de servidores de red, proveedores de servidores de red, administradores de servidores de red, proveedores de servicios de tercera entidad y abonados, consideran los servidores SIP intermedios como una plataforma potencial para desplegar servicios que no pueden o no podrían ser desplegados en agentes de usuario de punto final por una razón u otra.

Existe una gama de protocolos normalizados (por ejemplo, SIP, SDP, SOAP), lenguajes (por ejemplo, el CPL) y sistemas de interfaz (por ejemplo, SIP-CGI, 3GPP OSA API) que tratan diferentes aspectos del control de servicios. También, es posible que los servicios apliquen sus protocolos múltiples de control, componentes de red, lenguajes y sistemas de interfaz. El servidor SIP deberá ser ampliable para soportar todos estos aspectos según se requiera. Estas aplicaciones de servicios pueden ser poseídas por diferentes participantes, que tienen diferentes niveles de autorización y diferentes relaciones contractuales con el propietario del servidor SIP. Las aplicaciones de servicio pueden añadir valor al procesamiento por defecto de solicitudes y respuestas SIP (pero no están limitadas a hacer esto) en diferentes puntos de procesamiento de llamada/sesión especificados, bajo diferentes condiciones, etc.

El siguiente ejemplo ilustra que es posible la invocación de varios servicios en base a un evento SIP. Considérese un ejemplo en el que un abonado, por ejemplo Bob, tiene un abono SIP con algún proveedor de servicios SIP, por ejemplo Telco. Bob tiene una gama de servicios que le gustaría situar en la red. En este caso se trataría de servicios tales como servicios independientes del terminal o servicios adaptados a cualquier terminal que esté utilizando usualmente Bob. Pueden existir también servicios que proporcionen seguridad, privacidad y fiabilidad a Bob. También, Bob no desea gestionar sus propios servicios. Supóngase además que Bob trabaja en una compañía, por ejemplo Corp. Los servicios que son invocados para gestionar un mensaje de invitación entrante para Bob pueden tener este aspecto: Telco puede ser propietario y administrador del servidor SIP. El proveedor Telco proporciona también servicios SIP a abonados y soporta servicios de terceras entidades. El proveedor Telco reconoce que Bob es un abonado en el mensaje de invitación entrante. El primer servicio es una aplicación Telco Call Barring, para comprobar si Bob ha pagado su última factura. El segundo servicio es un servicio proporcionado por el proveedor Telco. Simplemente comprueba que los programas de codificación de medios del participante que llama pueden ser manejados por el punto/terminal que está utilizando en ese momento Bob. Si no es así, la aplicación invitará a un convertidor de reproducción de medios en tiempo real en el flujo de cadena de medios (utilizando control de llamadas de tercera entidad). Esta conversación es transparente para Bob y la aplicación vigilará las respuestas de Bob y actualizará las descripciones de sesión según sea necesario. El tercer servicio se refiere a preferencias del propio Bob como abonado llamado, por ejemplo un programa script en lenguaje CPL. Esta aplicación vigila las respuestas a la solicitud de servidor proxy, y posiblemente canaliza el mensaje de invitación a varios destinos en base a esta acción. Por ejemplo, el mensaje de invitación está dirigido a la cuenta SIP URL privada actual de Bob. Al producirse un estado de "no respuesta", el mensaje de invitación es enviado por proxy a su esposa Alicia. En algunos casos, Bob desea desviar todas las llamadas privadas a su cuenta SIP URL de la empresa. El cuarto servicio es también un servicio de Telco, pero proporcionado a Telco por un proveedor de servicios de aplicaciones de tercera entidad, por ejemplo besafe.com. Este servicio comprueba tipos de contenido de cuerpo de mensaje y proporciona comprobación de virus cuando es necesario, por ejemplo si se incluye una tarjeta animada. El quinto servicio es un servicio ISP que ofrece al participante que llama anuncios multimedia en compensación del reembolso de las cantidades cargadas por Telco. Si la sesión se establece y si es una sesión de videoconferencia, Bob recibe una pequeña barra de información de reproducción de video en tiempo real en el fondo de la imagen de video. Este servicio es una aplicación de monitorización y utiliza control de llamadas de tercera entidad. El servicio ISP tiene una cuenta en el servidor SIP de Telco y puede ofrecer servicios directamente a la base de abonados de la que es propietaria Telco. Bob se ha abonado a este servicio directamente con la entidad ISP, sin implicar al proveedor Telco. El sexto servicio es un servicio gestionado por la compañía en la que trabaja Bob. Si la llamada está dirigida al localizador SIP URL de la empresa de Bob en ese momento, entonces la llamada es cursada a Bob, en base a datos conocidos solamente dentro de la red de área local privada de la empresa. El séptimo y último servicio está previsto para fines de administración, dado que Telco podría desear alguna comprobación de contraseñas.

El ejemplo anterior ilustra la diversidad de relaciones contractuales asociadas con los diferentes servicios activados por un evento. Los servicios pueden ser soportados por diferentes participantes comerciales como propietarios, y pueden ser implementados utilizando diferentes tecnologías.

Diferentes servicios desplegados en una red de servicios pueden interaccionar entre sí. Estas interacciones pueden producirse entre servicios relacionados con un solo usuario, con varios usuarios o entre servicios de clientes y servicios de sistema. La interacción puede producirse además entre servicios que corren en el mismo componente de red o en un componente de red diferente. En la figura 1 se ilustran diferentes tipos de interacciones: usuario individual - componentes múltiples (SUMC), cliente - sistema (CUSY), usuarios múltiples - componente individual (MUSC), usuarios múltiples - componentes múltiples (MUMC), y usuario individual - componentes múltiples (SUMC).

Existen muchas causas de interacción entre características, incluyendo las de "violación de privilegios de característica" y "violación de supuestos de característica".

Violación de privilegios de característica: se violan privilegios de características si se invocan características redundantemente o por participantes no autorizados. El principal problema causado por la violación de privilegios de característica es el consumo redundante de recursos, o el acceso no autorizado a recursos. Esto puede ser intencionado o malicioso por naturaleza. Cuando se produce una violación de privilegios de característica, existe una pugna entre características, autorizadas o no autorizadas, para acceder a los recursos. Si se invocan características redundantemente o por participantes no autorizados, esto puede ser subsiguientemente la causa de una violación de supuestos de característica. Claramente, es deseable evitar la violación de privilegios de característica.

Como se describirá posteriormente, de acuerdo con el invento, las violaciones de privilegios de característica se resuelven mediante filtrado sobre contexto, sobre relaciones contractuales, sobre condiciones, sobre listas de control de acceso, o en relación con privilegios y derechos.

El filtrado sobre contexto se refiere a la necesidad de interpretar un evento en un cierto contexto. Esta necesidad se pone de manifiesto cuando se gestionan servicios multimedia en red que funcionan en una red de convergencia.

El filtrado sobre relaciones contractuales se refiere a la necesidad de relacionar un evento con un conjunto de características específicas por obligación contractual para procesar ese evento. Este tema es particularmente importante en un mercado sin legislar en el que no solamente el proveedor de la infraestructura de red y servicios de control de sesión puede ofrecer servicios de valor añadido a abonados, sino que terceras partes tienen derecho legal a presentar también dicha oferta.

El filtrado sobre políticas de control de acceso asegura que un evento provoca solamente un comportamiento autorizado en el nodo.

El filtrado sobre condiciones asegura que no se invoca redundantemente una característica cuando se produce un evento, y que son detectadas las características a invocar en base al contexto, de acuerdo con relaciones contractuales y privilegios de acceso. Estas condiciones pueden depender, por ejemplo, de las propiedades del evento, propiedades del sistema o propiedades de la red.

Violación de supuestos de características: se violan los supuestos relativos al comportamiento de características si es modificado el contexto de una característica por otra característica, de tal modo que la característica no puede funcionar como está previsto. Una violación de supuestos de característica puede provocar un comportamiento ambiguo o conflictivo.

Las características representan el comportamiento visible de la ejecución de una aplicación de servicio. Una instrucción emitida por la aplicación de servicio para controlar el comportamiento de valor añadido del nodo SIP se denomina instrucción de característica. Sin embargo muchas características pueden aplicar su comportamiento a un mensaje antes de enviarse la instrucción de control en retorno al nodo SIP. La instrucción o conjunto de instrucciones de control que se retornan al nodo SIP se denomina instrucción de control de servicio. Dicha instrucción contiene un contexto de evento resultante, es decir las propiedades de un mensaje SIP que ha de enviarse ascendente o descendentemente en respuesta al contexto de evento original que activó las aplicaciones de servicio. Se produce un comportamiento ambiguo cuando la instrucción de control de servicio es diferente dependiendo de la secuencia en la cual las características obtienen control sobre el contexto de evento en curso. Las instrucciones ambiguas no son necesariamente exclusivas mutuamente.

Como ejemplo, supóngase que un cuerpo de mensaje SIP contiene una imagen en color en formato gif. Sea S1 una aplicación de servicio que es activada en el contenido del cuerpo de mensaje de formato gif. Sea S1 una aplicación de servicio que convierte el formato gif en formato jpg. Adicionalmente, sea S2 una aplicación de servicio que se activa también en el contenido del cuerpo de mensaje de formato gif. Supóngase que S2 es una aplicación de servicio que convierte la imagen gif en una imagen en blanco y negro.

Sea S1 la primera aplicación a invocar, activada por el contenido gif. La aplicación S1 convertirá la imagen gif en una imagen jpg y la inscribirá en el contexto de evento en curso. La aplicación S2 nunca será invocada. El contexto de evento resultante contendrá una imagen jpg en color.

Supóngase ahora que S2 es la primera aplicación a invocar, activada por el contenido gif. La aplicación S2 convertirá la imagen gif en color en una imagen en blanco y negro y la inscribirá en el contexto de evento en curso. La aplicación S1 será invocada subsiguientemente en base al contenido gif como especifica el contexto de evento en curso. La aplicación S1 convertirá la imagen gif en una imagen jpg y la inscribirá en el contexto de evento en curso. El contexto de evento resultante contendrá una imagen jpg en blanco y negro.

Claramente, las aplicaciones S1 y S2 producen un comportamiento ambiguo, porque el contexto de una característica es modificado por la otra.

Son instrucciones con características conflictivas las que son mutuamente exclusivas. Las instrucciones conflictivas intentarán sobreponerse mutuamente. En este caso, las instrucciones conflictivas son también la causa de comportamiento ambiguo.

Adicionalmente, todas las instrucciones de características son conjuntos de instrucciones potencialmente no autorizadas, a no ser que estén autorizadas explícitamente. Las instrucciones de característica no autorizadas pueden tener una naturaleza maliciosa o ser el resultado de una aplicación de servicio descontrolada. En cualquier caso, pueden dañar la seguridad e integridad del sistema y deberán ser detectadas.

Las aplicaciones de servicio de vigilancia pueden causar problemas adicionales a los ya comentados. Las aplicaciones de servicio de vigilancia pueden emitir instrucciones de característica asíncronas hacia el nodo SIP en cualquier momento, dado que están funcionando continuamente. Puesto que están vigilando la aparición de eventos futuros, pueden procesar estos eventos y crear más instrucciones de característica. Si se trata de aplicaciones de servicio de vigilancia múltiples simultáneas, sus instrucciones de característica generadas pueden depender del orden en el cual se notifican en relación con el evento. Esto incrementa la complejidad de los problemas comentados anteriormente.

La detección y resolución de violaciones de supuestos de característica es mucho más complicada que la resolución de la violación de privilegios de característica. Como se describirá posteriormente, de acuerdo con el invento, se crean medios para especificar como resolver el comportamiento ambiguo, medios para dividir la gestión de interacción entre características en grupos de características independientes y dominios de administración, y una regla sencilla por defecto para resolver la interferencia de interacción entre características detectada durante el funcionamiento. Las violaciones de supuestos de característica se resuelven por ordenación de características en base al principio de cadena en cascada y activación condicional, y teniendo en cuenta prioridades de característica en el mecanismo de bloqueo/desbloqueo. Esto se describirá con más detalle posteriormente.

Otras causas de interacción entre características incluyen limitaciones del soporte de red, por ejemplo funcionalidad de protocolo limitada o sistemas de interfaz de usuario limitados, problemas intrínsecos en sistemas distribuidos, tales como la contención de recursos, coordinación de características, temporización, u operaciones no atomizadas, violación de la seguridad del sistema, mensajes fraudulentos de intromisión, interacciones no cooperativas por parte de características con intereses conflictivos, etc.

En general, pueden distinguirse tres tipos diferentes de soluciones a los problemas de interacción entre características:

Infraestructura: El desarrollo de infraestructuras para el desarrollo de características que integran gestión de interacción entre características, es decir que tratan las causas de algunas interacciones entre características definidas. Las interacciones entre características son gestionadas tanto antes (especificación) como después (gestión forzada) del momento de despliegue de características, es decir durante la especificación o la definición forzada de políticas basadas en reglas, etc. De acuerdo con el invento, los programas script de módulo de reglas componen una infraestructura para el despliegue de características que crea un marco para la gestión de interacción entre características.

Creación de servicios: El diseño de características en lo que respecta a las causas de interacciones entre características, es decir a la detección de interacciones entre características durante la fase de diseño. De este modo, las interacciones entre características pueden gestionarse antes del despliegue de características, por ejemplo mediante explicitación, análisis de causas de interacción entre características, comprobaciones de verificación, etc. De acuerdo con el invento, se imponen requerimientos sobre la creación de servicios y la especificación de la estrategia de despliegue de características.

Sobre la marcha: La resolución de interacciones entre características a medida que se producen. Dado que no todas las interacciones entre características pueden ser identificadas antes del despliegue de características, han de ser detectadas sobre la marcha, por ejemplo por autentificación criptográfica, autorización y cualificación como secreto, políticas basadas en reglas, algoritmos de resolución, negociación AI, etc. De acuerdo con el invento, se crean reglas sencillas para la resolución de interacciones entre características detectadas sobre la marcha. Estas reglas incluyen la comprobación de listas de control de acceso asociadas con módulos de reglas, la resolución de violaciones de acceso por notificación de alarmas y la puesta fuera de servicio de los módulos de reglas que producen la violación, la comprobación de programas script que especifican privilegios y derechos, y la resolución de violaciones de privilegios y derechos mediante notificación de alarmas y puesta en fuera de servicio de las características que provocan la violación.

El proceso de gestión general de acuerdo con el invento incluye las siguientes operaciones:

1. Especificación de diseño de característica, independientemente de otras características: un servicio se diseña y especifica sin considerar interacciones con otras características. Sin embargo, de acuerdo con una realización del invento, el servicio se diseña con respecto al modelo de puntos de procesamiento que se describe posteriormente.

2. Negociación de contrato: la parte que desea desplegar un servicio en la red de servicios negocia con el administrador de la red de servicios los privilegios y derechos que pueden concederse al servicio. De acuerdo con una realización del invento, se crea un programa script de privilegios y derechos asociados con el servicio.

3. Análisis de interacción entre características: las posibles interacciones entre características son investigadas en base a la experiencia y el posible conocimiento sobre algunas de las características desplegadas en la red de servicios.

4. Especificación de estrategia de despliegue de características: el autor de un módulo de reglas, que va a desplegar el servicio, adquiere un dominio administrativo. Tomando como base el análisis de interacción entre características y el conocimiento sobre el servicio, abonados y usuarios, se especifica la estrategia de despliegue de características en un programa script de módulo de reglas.

5. Implementación de características.

6. Comprobación de verificación.

7. Instalación y activación de características.

8. Comportamiento y gestión de características sobre la marcha.

9. Desactivación y desinstalación de características.

De acuerdo con el invento, se crea un marco para la gestión de interacción entre características que

-: permite fácilmente la conversión de la etapa de análisis en reglas de especificación creando un lenguaje y un marco sencillo con principios de fácil comprensión,

-: define límites claros entre las agrupaciones de características que son conocidas para una entidad de análisis dada, así como las que no lo son,

-: crea reglas sencillas, y así fácilmente comprensibles, para la transferencia del control entre estos grupos de características. Cuando se transfiere el control de un grupo de características a otro, existe un mecanismo para asegurar que un grupo subsiguiente de características no compromete al grupo anterior, y

-: simplifica la etapa de análisis especificando puntos de procesamiento en el tratamiento de eventos, en los cuales se garantizan condiciones previas y en los cuales se permite solamente a las aplicaciones proporcionar ciertas instrucciones al servidor.

La figura 2 ilustra los elementos de red implicados en una arquitectura de servidor SIP de ambiente de servicios de acuerdo con una realización del invento. El cliente SIP anterior 203 representa cualquier cliente, tal como un computador personal habilitado para protocolo SIP, un terminal inalámbrico, un servidor proxy hop anterior, una pasarela SIP/PSTN, etc. El cliente solicita servicios de sesión mediante solicitudes entrantes al servidor SIP 202. El servidor SIP 202 representa el servidor proxy, de redirección o SIP dedicado de aplicación activada, en el que está implementado el ambiente 201 de soporte de servicios. Alternativamente, puede existir cualquier otra entidad habilitada para SIP que active servicios de valor añadido, tal como un agente de usuario, un agente de registro, etc. Los servicios ubicados en el ambiente 201 de soporte de servicios de servidor SIP están definidos por aplicaciones de servicio, tales como programas script SIP-CGI, módulos de reglas y características de servicio. El nodo 202 de servidor SIP puede transferir el control al ambiente 201 de soporte de servicios al producirse la recepción de un evento. El ambiente 201 de soporte de servicios puede invocar subsiguientemente una aplicación de servicio pertinente de acuerdo con ciertos criterios de filtrado y en base a ese evento. La aplicación de servicio retorna una instrucción o conjunto de instrucciones de características. Este ambiente 201 de soporte de servicios devuelve el control al nodo 202 de servidor SIP, junto con instrucciones de control de servicio que informan al nodo 202 de servidor SIP sobre como procesar el evento. El nodo 202 de servidor SIP cursa la solicitud al cliente siguiente SIP 204. Serán canalizadas respuestas a la solicitud en la dirección opuesta desde el cliente siguiente SIP 204, a través del nodo 202 de servidor SIP, al cliente anterior SIP 203, activando posiblemente servicios adicionales. El cliente siguiente SIP 204 representa cualquier servidor, como por ejemplo un computador personal habilitado para SIP, un terminal inalámbrico, un servidor proxy hop siguiente, una pasarela SIP/PSTN, etc. El servidor trata solicitudes entrantes. El servidor remoto 206 ofrece ejecución remota de servicios, es decir en otro ambiente de soporte de servicios. En base, por ejemplo, a criterios de prestaciones, el ambiente 201 de soporte de servicios puede iniciar el procesamiento en el servidor remoto 206, por ejemplo utilizando protocolos de solicitud/respuesta. De este modo, pueden invocarse y gestionarse en diferentes anfitriones diferentes categorías de servicios. El protocolo utilizado en la transferencia hacia el servidor remoto puede ser cualquier protocolo que soporte diálogos de solicitud/respuesta, por ejemplo los protocolos SIP, ICAP, http, OSA API, etc. El servidor 205 de administración realiza tareas administrativas en el ambiente de servicios. Es el responsable de configurar el ambiente 201 de soporte de servicios, que está asociado con el dominio del nodo 202 de servidor SIP. Por tanto, el entorno del ambiente 201 de soporte de servicios incluye un nodo SIP, aplicaciones de servicio, anfitriones remotos y una entidad de administración.

La figura 3 ilustra esquemáticamente una arquitectura de sistema de un servidor SIP que soporta un mecanismo de reglas de ejecución de servicio de acuerdo con una realización del invento. El ambiente 301 de soporte de servicios fuerza la infraestructura de despliegue, es decir define como una característica interacciona con otra. Por tanto, el ambiente 301 de soporte de servicios proporciona la funcionalidad en el servidor SIP de que soporte servicios de valor añadido. El ambiente 301 de soporte de servicios comprende un motor 303 de reglas para gestionar los módulos 308 de reglas almacenados en una base 307 de reglas de ejecución. El motor 303 de reglas comprende adicionalmente un módulo 314 de ejecución de módulo de reglas que responde para el procesamiento de módulos de reglas. El motor de reglas puede invocar servicios 309-311 a través del gestor 302 de motor de ejecución de servicios. El gestor 312 de definición de servicios proporciona funcionalidad para la administración de los módulos de reglas. El servidor SIP implementa adicionalmente una pila 304 de protocolos SIP que incluye la funcionalidad 306 por defecto y un analizador 305 de mensajes SIP. El analizador 305 de mensajes SIP soporta el protocolo SIP y extrae propiedades de mensaje que pueden ser interpretadas por el motor 303 de reglas. El servidor 313 de administración realiza tareas administrativas en el ambiente de servicios.

Un mecanismo importante para la implementación de políticas de despliegue de servicios de acuerdo con el invento es la especificación de reglas de despliegue como reglas de ejecución de servicio especificadas en módulos de reglas. Las reglas de ejecución de servicio especifican condiciones y acciones que es necesario realizar, si se cumplen las condiciones. De acuerdo con el invento, se define un lenguaje de programación para especificar estas reglas, al que se hará referencia como Service Execution Rule Language (SERL) (lenguaje de reglas de ejecución de servicio).

Los módulos 308 de reglas son gestionados y ejecutados por el motor 303 de reglas. El motor 303 de reglas es la entidad funcional principal que implementa el mecanismo de activación e interacción entre características. Y es parte del ambiente 301 de soporte de servicios. Cuando se produce un evento, el analizador de mensajes invoca al motor 303 de reglas y transfiere el tratamiento del evento al motor 303 de reglas. El motor 303 de reglas encuentra y carga los módulos 308 de reglas y procesa los que son pertinentes para el evento recibido en el orden correcto. El filtrado incluye una detección de obligaciones contractuales. Los eventos definen el contexto en el cual se procesan los módulos de reglas, es decir las condiciones se evalúan de acuerdo con las propiedades de los eventos de mensaje SIP. El motor 303 de reglas invoca las acciones correspondientes cuando el patrón de reglas coincide con las propiedades de mensaje dadas. Tomando como base el contenido de estas acciones, el motor 303 de reglas puede emitir instrucciones de invocación para el gestor 302 de motor de ejecución de aplicaciones u otra entidad adecuada dentro del sistema de soporte de servicios. Los programas en lenguaje SERL no tienen conocimiento sobre los servicios que invocan y gestionan, a no ser el conocimiento sobre como invocar estos servicios y gestionar características en general. Las instrucciones de control recibidas de las aplicaciones de servicio invocadas son retornadas a la pila 304 de protocolo SIP cuando ha sido procesado el último módulo de reglas.

El motor 303 de reglas gestiona adicionalmente la información que es enviada entre diferentes servicios. Cuando se produce un evento, se establece un contexto de evento que contiene las propiedades pertinentes del evento de un modo normalizado. Las propiedades de mensaje tienen un nombre y un valor. El valor puede ser determinado por el mensaje. Son ejemplos de propiedades de mensaje SIP los siguientes:

Nombre: sipRequest.Request-URI, Value: sip:bob@corp.com

Nombre: sipRequest.To, Value: Bob Smith <sip:bob@corp.com>

Nombre: sipResponse.Status-Code, Value: 301

Un ejemplo de una propiedad de mensaje SDP es el siguiente:

Nombre: sdp.m, Value: video 48232 RTP/AVP 0

El motor 303 de reglas soporta varias interfaces internas de programación de aplicaciones (API) a las que pueden acceder las entidades funcionales de interfaz. Estas interfaces API incluyen:

-: una interfaz API de notificación de mensaje utilizada por la pila 304 de protocolos SIP para la notificación de mensajes desde el analizador 305 de mensajes SIP hasta el motor 303 de reglas,

-: una interfaz API de definición de base de reglas, utilizada por el gestor 312 de definición de servicios,

-: una interfaz API de instrucción de servicio utilizada por el gestor 302 de motor de ejecución de aplicaciones para transferir instrucciones al motor 303 de reglas en representación de las aplicaciones 309-311 de servicio,

-: una interfaz API de armado utilizada por el gestor 302 de motor de ejecución de aplicaciones para solicitar el armado de activaciones y eventos de transacción en representación de las aplicaciones 309-311 de servicio.

El gestor 302 de motor de ejecución de aplicaciones incorpora y gestiona varios motores 315 de ejecución de aplicaciones para diferentes tipos de aplicaciones de servicio, por ejemplo un motor OSA, un motor CPL, un intérprete CPL, un motor CGI y/o un motor Servlet. El gestor soporta la interfaz inducida por el motor 303 de reglas y establece una asociación entre la interfaz API de aplicación y el motor API de reglas. Desde el punto de vista del motor 303 de reglas, todos los motores 315 de ejecución de aplicaciones parecen una sola entidad, es decir el gestor 302 de motor de ejecución de aplicaciones. El gestor 312 de definición de servicios puede proporcionar funcionalidad adicional a los motores 315 de ejecución de aplicaciones.

Los programas de interfaz API creados por el gestor 302 de motor de ejecución de aplicaciones incluyen:

-: una interfaz API de invocación utilizada por el motor 303 de reglas para instrucciones de invocación transferidas desde el módulo de reglas hasta el gestor 302 de motor de ejecución de aplicaciones, y

-: una interfaz API de notificación utilizada por el motor 303 de reglas para la notificación de instrucciones desde el módulo de reglas hasta el gestor 302 de motor de ejecución de aplicaciones.

El comportamiento 306 de servidor SIP por defecto comprende la funcionalidad de un servidor proxy, un servidor de redirección, un servidor de aplicaciones o incluso un agente de usuario. Puede incluir adicionalmente una entidad de registro o funciones IM&P. Proporciona una interfaz a la que puede acceder el motor 303 de reglas para situar instrucciones. Alternativamente, una aplicación de servicio puede implementar el comportamiento de servidor SIP. Por consiguiente, es posible que el módulo de reglas invoque solamente partes de cada una de las anteriores funciones según sea requerido por las aplicaciones de servicio.

El gestor 312 de definición de servicios crea una interfaz O&M API utilizada por el servidor 313 de administración, por las aplicaciones 309-311 de servicio y por la pila 304 de protocolos SIP. La interfaz API proporciona funcionalidad para:

-: Autentificación y autorización manual de nuevos módulos de reglas y aplicaciones de servicio.

-: Configuración manual de derechos y privilegios de módulos de reglas y aplicaciones de servicio.

-: Carga manual de módulos de reglas y aplicaciones de servicio.

-: Activación/desactivación manual de módulos de reglas y aplicaciones de servicio.

-: Validación manual de módulos de reglas.

-: Validación manual de aplicaciones de servicio implementadas utilizando lenguajes de programa script.

-: Eliminación manual de módulos de reglas y aplicaciones de servicio.

-: Listado manual de todos los módulos de reglas y aplicaciones de servicio junto con sus estados.

-: Modificación manual de módulos de reglas.

El gestor 312 de definición de servicios puede crear adicionalmente una interfaz que soporta un tratamiento automático de algunas de las funciones manuales anteriores y/o características adicionales, tales como el listado de características de servicio disponibles, obtención de la interfaz y/o versión de una característica de servicio, listado de motores de ejecución y lenguajes de programación script soportados, tales como JVM, CPL, Perl, etc, instalación/desinstalación de características de servicio, activación/desactivación de características de servicio, registro de aplicaciones de servicio que proporcionen servicios como características de servicio a otra aplicación de servicio, abono a características de servicio, invocación/terminación de características de servicio, operaciones estadísticas como "vigilar carga de procesador", "llamadas en horas de ocupación", operaciones de contabilidad, activación/desactivación, lectura, reposición de registros contables, etc.

En este contexto, los términos "características de servicio" se refieren a funciones que son ofrecidas a aplicaciones de servicio. Las características de servicio se consideran como integradas en el ambiente 301 de soporte de servicios y en la pila 304 de protocolo SIP. El gestor 302 de motor de ejecución de aplicaciones y el gestor 312 de definición de servicios proporcionan ambos características de servicio a las aplicaciones 309-311 de servicio, aunque algunas de las características ofrecidas por el gestor 302 de motor de ejecución de aplicaciones son mediadas a través del motor 303 de reglas y la pila 304 de protocolo SIP.

Las aplicaciones 309-311 de servicio son programas, compilados o interpretados, que se ejecutan en el ambiente 301 de soporte de servicios del servidor SIP, o en un servidor remoto. Su finalidad puede estar relacionada o no relacionada con las funciones básicas del servidor SIP. Las aplicaciones de servicio pueden implementar secuencias de comportamiento de servidor SIP. Las aplicaciones de servicio pueden ofrecer servicios a otras aplicaciones de servicio, es decir pueden ser características de servicio. Por ejemplo, una aplicación de servicio puede contener algún convertidor del tipo MIME, y ofrecerlo como una característica de servicio a otras aplicaciones de servicio. Otras aplicaciones de servicio pueden entonces utilizar esta función para realizar un servicio. Preferiblemente, las aplicaciones de servicio deberán ser transferibles entre servidores SIP y pueden ser ejecutadas en servidores remotos. Las aplicaciones de servicio pueden acceder u ofrecer acceso a través de un convenio de nominación global o local, a un espacio nominal local o normalizado, utilizando vías de ficheros especificadas hacia las aplicaciones, etc, abrir una interfaz API normalizada, por ejemplo SIP-CGI, OSA API, HTTP, ICAP, servlets,
etc.

Un mecanismo estandarizado de acceso a aplicaciones de servicio es una ventaja para proveedores de servicios de tercera entidad.

El servidor SIP no gestiona necesariamente aplicaciones de servicio ubicadas remotamente, dado que puede no tener conocimiento de ellas. En este caso, el servidor SIP o el gestor 302 de motor de ejecución de aplicaciones pueden requerir información de posición proporcionada por la información de activación.

El analizador 305 de mensajes SIP es responsable de interpretar mensajes recibidos, aislar elementos bien definidos como propiedades de mensajes, y hacer que se activen acciones cuando sea adecuado. Cuando se produce un evento, se establece un objeto de mensaje que contiene las propiedades pertinentes aisladas por el analizador 305 de mensajes SIP.

Preferiblemente, cualquier protocolo soportado tiene un analizador de mensajes correspondiente. Un analizador puede contener analizadores subordinados que corresponden a protocolos subordinados, es decir embebidos en otros protocolos como el protocolo SIP. Por ejemplo, dentro de un analizador de mensajes SIP puede haber analizadores independientes para el tratamiento de diferentes tipos de medios, tales como SDP, HTML, XML y XHTML. Desde el punto de vista del módulo de reglas, todos los analizadores parecen un único motor. La interfaz API para el analizador de mensajes deberá estar definida preferiblemente de tal modo que puedan añadirse modularmente analizadores para nuevos protocolos y contenidos.

Para cualquier protocolo que haya de soportar el ambiente 301 de soporte de servicios, la interfaz entre el analizador de mensajes de ese protocolo y el motor de reglas cubre:

-: el conjunto de propiedades definidas por el analizador de mensajes, incluyendo el nombre de propiedad, su relación con el mensaje que caracteriza, y la capacidad de una acción para su modificación, y

-: los puntos de procesamiento en los cuales pueden activarse las reglas.

En una realización del invento, el ambiente 301 de soporte de servicios, o cada una de las entidades funcionales dentro del ambiente 301 de soporte de servicios, puede estar situado en anfitriones independientes que dan servicio a múltiples servidores, por ejemplo SIP, Web, WAP, I-Mode, Servidores RTSP, etc, y acceder a varios servidores de aplicaciones, por ejemplo relacionados con bases de datos, OSA, Web, SIP, etc.

Por ejemplo, el motor 303 de reglas, el gestor 302 de motor de ejecución de aplicaciones y el gestor 312 de definición de servicios pueden estar situados en cada uno de sus sistemas de anfitrión, posiblemente mediante acoplamiento de interfaz vía IP. Las entidades de interfaz entre el motor de reglas y los diversos servidores pueden ser normalizadas o propietarias. Las entidades de interfaz entre el motor de reglas, el gestor 302 de motor de ejecución de aplicaciones y el gestor 312 de definición de servicios deberán ser, preferiblemente, propietarias y compactadas. Las entidades de interfaz entre los servidores de aplicación de servicio y el ambiente de soporte de servicios son preferiblemente normalizadas, tales como la interfaz OSA API, HTTP, SIP o alguna interfaz API de base de datos como alguna interfaz API basada en SQL. En tal configuración distribuida, se pone de manifiesto una ventaja adicional, toda vez que el motor de reglas es capaz de gestionar muchos tipos de eventos, no solamente eventos SIP, sino también eventos HTTP, eventos SMTP, eventos Wap, eventos de núcleos de codificación de medios, como eventos MPEG 7, o eventos de objetos de juego o de realidad virtual en tres dimensiones, etc.

Aun con referencia a la figura 3, el mecanismo de activación de acuerdo con una realización del invento puede ilustrarse mediante un ejemplo sencillo en el que se supone que solamente es relevante para un evento recibido un solo módulo de reglas. En la figura 3, los números rodeados por un círculo se refieren a las siguientes operaciones de un ejemplo de activación:

1.: Es recibida una solicitud SIP en el analizador 305 de mensajes SIP.

2.: El analizador 305 de mensajes SIP genera un objeto de mensaje SIP. El motor 303 de reglas convierte este objeto en un contexto de evento SIP.

3.: Los módulos 308 de reglas pertinentes se sitúan en la base 307 de reglas de ejecución en base al contexto de evento, puntos de procesamiento y relaciones contractuales. Se describirá posteriormente una realización de este mecanismo.

4.: El motor 303 de reglas transfiere el módulo 308 de reglas encontrado desde la base 307 de reglas de ejecución hasta el módulo 314 de ejecución de módulo de reglas y lo ejecuta. Como ejemplo, supóngase que el módulo de reglas cargado contiene la siguiente funcionalidad, es decir una regla que especifica criterios de activación y acciones de invocación para las aplicaciones 310 y 311 de servicio:

1

5.: Se produce una activación, y la aplicación Y (310) de servicio especificada es invocada enviando una orden de invocación al gestor 302 de motor de ejecución de aplicaciones.

6.: El gestor 302 de motor de ejecución de aplicaciones localiza la aplicación Y (310).

7.: El gestor 302 de motor de ejecución de aplicaciones carga la pertinente aplicación Y (310) de servicio en un motor 315 de ejecución de aplicaciones y subsiguientemente activa el programa para ejecución.

8.: La instrucción resultante de la aplicación 310 es transferida en retorno al motor 303 de reglas.

9.: El motor 303 de reglas reanuda el procesamiento del módulo de reglas y lanza otra aplicación Z (311). Es dada una orden de invocación al gestor 302 de motor de ejecución de aplicaciones.

10.: El gestor 302 de motor de ejecución de aplicaciones localiza la aplicación Z (311).

11.: El gestor 302 de motor de ejecución de aplicaciones carga la aplicación Z (311) pertinente en un motor 315 de ejecución de aplicaciones que puede correr el programa de aplicación, y subsiguientemente lo activa.

12.: La instrucción resultante de la aplicación 311 es transferida en retorno al motor 303 de reglas.

13.: El motor 303 de reglas reanuda el tratamiento del módulo de reglas y encuentra que el módulo de reglas no tiene más reglas que ejecutar y que no hay más módulos de reglas que cargar. Subsiguientemente, el motor 303 de reglas envía el resultado final de los servicios al módulo 306 de comportamiento SIP por defecto.

14.: El módulo 306 de comportamiento SIP por defecto mezcla la salida del motor 303 de reglas con la posible salida por defecto y envía el mensaje SIP al analizador/convertidor 305 de mensajes SIP.

15.: El mensaje SIP es transferido, por ejemplo, a través de servidores proxy.

En el caso de varios módulos de reglas, las operaciones anteriores 13 y 14 pueden modificarse del modo siguiente:

13.: El motor 303 de reglas reanuda el tratamiento del módulo de reglas y encuentra que el módulo de reglas no tiene más reglas que ejecutar. El motor 303 de reglas busca módulos de reglas con prioridad inferior a la del módulo de reglas ejecutado anteriormente.

14.: Ir al punto 3 del ejemplo anterior. Si se encuentra un motor de reglas, se hará funcionar como en el ejemplo anterior, posiblemente invocando otras aplicaciones, por ejemplo la aplicación 309.

Cuando no existen módulos de reglas o servicios instalados para controlar una sesión, el motor 303 de reglas transfiere el control al servidor SIP y especifica una salida vacía. El servidor SIP puede mezclar posiblemente la salida vacía con el comportamiento 306 por defecto del servidor como en una vinculación SIP-CGI, de acuerdo con el comportamiento SIP por defecto para servidores de registro, servidores de redirección y servidores proxy.

La figura 4 ilustra la estructura de un módulo de reglas de acuerdo con una realización del invento. De acuerdo con el invento, un módulo 401 de reglas es conceptualmente un árbol que comprende un número de reglas 401-402 de ejecución de servicio, especificando cada regla un número de condiciones 403-404 y 405, respectivamente, y un número de acciones 406-407 y 408, respectivamente, que es necesario realizar si se cumplen las condiciones correspondientes. En lo que sigue, se hará también referencia a las condiciones como patrones. En alto nivel, un módulo de reglas comprende adicionalmente:

-: información 409 de propietario que especifica el propietario del módulo de reglas, es decir una parte identificable con interés en el nodo SIP. Esta parte puede poseer varios módulos de reglas. La información de propietario puede incluir adicionalmente información relativa a relaciones contractuales.

-: información 410 de protocolo que especifica el contexto en el cual se han de interpretar las reglas en el módulo de reglas. Son ejemplos de protocolos los protocolos SIP, SDP, HTTP, H.323, etc. Preferiblemente, existiría solamente un solo protocolo definido para cada módulo de reglas. En otro caso, algún solapamiento puede proporcionar una interpretación ambigua. Por ejemplo, ambos protocolos SIP y HTTP tienen campos de cabecera del tipo de contenido.

-: información 411 de control de acceso que especifica los participantes que tienen derecho a invocar, administrar y leer el módulo de reglas.

-: un identificador 412 de módulo de reglas, preferiblemente un solo identificador. Adicionalmente, un módulo de reglas puede incluir varios nombres alternativos.

Un módulo de reglas puede comprender adicionalmente información auxiliar 413 que proporciona información de contexto adicional para un módulo de reglas, e información 414 de índice.

Un patrón 403-405 es una expresión que puede ser evaluada con respecto a las propiedades de mensaje en un contexto de evento, e indistintamente las reglas se adaptarán o no se adaptarán a las propiedades contenidas en el contexto. Acciones 506-408 pueden identificar aplicaciones, características de servicio incorporadas, servidores remotos, anfitriones de carga compartida, o servidores SIP siguientes a invocar. Pueden identificar adicionalmente objetos de acción descargados y situados externamente, etc. Reglas, condiciones y acciones pueden tener parámetros que describen su comportamiento, y constituyen los atributos de los nudos del árbol de secuencia. Las ramas tienen una ponderación que indica cual de ellas deberá procesarse en primer lugar.

Preferiblemente, cada módulo de reglas tiene una prioridad de ordenación explícita asignada, es decir la prioridad de orden especifica la secuencia en la cual son cargados los módulos de reglas por el motor de reglas.

De acuerdo con una realización preferida del invento, los nudos del árbol en la representación gráfica están representados por elementos XML. La bifurcación de un nudo a los nudos siguientes está representada encerrando el elemento que representa el nudo o nudos siguientes dentro del elemento que representa el nudo de la bifurcación. La ponderación de las ramas está dada por el orden en el cual están representadas en el programa script. Esta ponderación proporciona el orden en el cual han de procesarse los elementos cuando se recibe un evento. En otras palabras, el programa se ejecuta de arriba abajo. De este modo, en esta realización no existen bucles dentro de un programa SERL. Preferiblemente, el formato de un módulo de reglas está especificado como un esquema XML DTD o XML.

Una ventaja de esta realización es que está basada en un lenguaje normalizado y ampliable para especificar lenguajes adicionales.

En una realización del invento, pueden asociarse políticas con reglas que especifican privilegios y derechos. Cada nudo del módulo de reglas puede tener un nudo de política asociado, que puede contener listas de control de acceso.

El siguiente es el ejemplo de un caso de un módulo de reglas especificado como programa script en lenguaje SERL:

2

3

La figura 5 ilustra la agrupación de servicios en conjuntos de servicios restringidos de acuerdo con una realización del invento. De acuerdo con esta realización, los servicios 501-508 están agrupados en un conjunto de grupos 509- 510 de características. En el ejemplo ilustrado en la figura 5, el grupo 509 de características contiene características 501-504, y el grupo 510 de características contiene características 505-508. Para cada grupo de características se imponen ciertas restricciones a los servicios de ese grupo, es decir se les permite solamente emitir tipos de instrucciones bien definidos. Los grupos de características no especifican como se permite a características individuales interaccionar con un grupo de características, mientras no violen la restricción impuesta al comportamiento del grupo. Los grupos de características están ordenados secuencialmente, por ejemplo por numeración de los grupos de características. En el ejemplo de la figura 5, el grupo 509 de características es el grupo de características de orden K en una secuencia de grupos de características, y el grupo 510 de características es el grupo de orden K + 1. La ordenación de grupos de características impone un orden de ejecución, de tal modo que las características del grupo 509 de características se ejecutan antes que las características del grupo 510. Preferiblemente, la definición de un grupo de características comprende una especificación de la ordenación del grupo, que especifica, por ejemplo, un índice de grupo, un grupo de características anterior y siguiente, etc. Preferiblemente, la definición de un grupo de características comprende adicionalmente una especificación de precondiciones, es decir condiciones en las cuales pueden basarse las características de ese grupo de características, y una especificación de restricciones forzadas sobre el comportamiento de los servicios de ese grupo de características. Por tanto, los grupos de características constituyen un mecanismo de ordenación que formaliza un tipo fundamental de interacción entre características creando una secuencia ordenada en la cual son invocadas las aplicaciones de servicio. Por consiguiente, este mecanismo proporciona un marco para agrupar el problema de la interacción entre características en conjuntos restringidos de características. El mecanismo resuelve realmente las interacciones entre características entre estos grupos de características, porque, debido a las restricciones impuestas a los grupos de características, los supuestos de característica cuando se transfiere el control de un grupo al siguiente corresponden a una función determinista y bien definida. Una ventaja de esta agrupación es que proporciona un mecanismo para descomponer el problema del análisis de interacción entre características en problemas independientes menos complejos, haciendo así el problema más fácil de gestionar. Adicionalmente, es una ventaja la posibilidad de delegar áreas de problema formalizadas en partes independientes, haciendo el problema más escalable. El mecanismo de formación de grupos de características proporciona al administrador y proveedor de servicios la capacidad de categorizar las aplicaciones de servicio para diferentes puntos en lo que respecta al tiempo de procesamiento, donde deberán invocarse las aplicaciones de servicio.

La figura 6 ilustra la agrupación de servicios en conjuntos restringidos de servicios correspondientes a posiciones en el flujo de mensajes SIP de recorrido circular de acuerdo con una realización preferida del invento. De acuerdo con esta realización, los grupos de características están relacionados con las posiciones P1-P6 en el flujo de mensajes de recorrido lógico circular de solicitud/respuesta que tienen ciertas precondiciones garantizadas para el contexto de evento, y en cuyo sistema puede invocarse una aplicación de servicio en base a las restricciones relativas al comportamiento que se admite en esa posición. Se hará referencia a estos grupos de características como puntos de procesamien-
to.

Los seis puntos P1-P6 de procesamiento constituyen una agrupación general de servicios. Los puntos P1-P3 y P4-P6 de procesamiento cubren lógicamente problemas correspondientes. Los puntos P1-P3 de procesamiento incluyen servicios que son activados en base a solicitudes 607, y los puntos P4-P6 de procesamiento incluyen servicios que son activados en base a respuestas 608. Lógicamente, los puntos P1 y P4, los puntos P2 y P5, y los puntos P3 y P6 de procesamiento corresponden a restricciones correspondientes.

Un mensaje SIP puede dividirse en general en dos partes, a saber las propiedades de señalización, es decir propiedades relativas a protocolos SIP, SDP, etc, y el contenido del cuerpo de mensaje que no está relacionado con la señalización, tal como un documento gif, html, etc. Los servicios invocados en base a un evento SIP pueden agruparse consiguientemente en tres clases:

-: los que inciden en las propiedades de señalización,

-: los que inciden solamente sobre el contenido del cuerpo de mensaje que no tiene información de señalización, y

-: los que no inciden sobre las propiedades de señalización ni sobre el contenido del cuerpo de mensaje que no tiene información de señalización.

Esto proporciona la agrupación básica de servicios en tres grupos 601-603 asociados con los tres puntos P1-P3 de procesamiento, respectivamente. Similarmente, en el paso de respuesta, los grupos correspondientes 604-606 están relacionados con los puntos P4-P6 de procesamiento, respectivamente.

En este contexto, los términos "propiedades de señalización" se refieren a propiedades de mensaje SIP y SDP que pueden adaptarse a una condición de módulo de reglas para invocar un servicio. Consiguientemente, las aplicaciones que modifican una propiedad de señalización pueden provocar la invocación de otra aplicación, que podría aun invocar otra aplicación, y así sucesivamente. La ventaja de desplazar el tratamiento de aplicaciones de servicio que no cambian las propiedades de señalización a un punto de procesamiento después de haberse producido todos los cambios en las propiedades de señalización, es que el administrador tiene una tarea más fácil para ordenar las aplicaciones en los puntos P2 y P5 de procesamiento.

En una realización del invento, los puntos P1-P6 de procesamiento pueden definirse del modo siguiente:

-: Punto P1 de procesamiento - Solicitud de Cliente de Conexión Intermedia Anterior: se ha recibido una solicitud 607 SIP de un cliente de conexión intermedia anterior. Para esta solicitud particular y para este abonado particular no se han invocado módulos de reglas en ningún punto de procesamiento anterior. Este punto de procesamiento comprende servicios que inciden en las propiedades de señalización del mensaje o mensajes resultantes, pero no en el contenido del cuerpo de mensaje.

-: Punto P2 de tratamiento - Punto de Contenido de Solicitud: las propiedades de señalización del mensaje o mensajes SIP/SDP resultantes han sido generadas y memorizadas, es decir esta parte del mensaje SIP está lista para ser enviada. No deberán producirse actualizaciones adicionales de las propiedades de señalización de control de llamada/medios, a no ser que esté autorizado explícitamente. Los servicios 602 invocados en el punto P2 de procesamiento no inciden en las propiedades de señalización SIP/SDP generadas en el punto P1 de procesamiento. Sin embargo, pueden existir excepciones a esta regla. Por ejemplo, los servicios pueden incidir sobre cabeceras de mensaje SIP, como Alert-Info, Call-Info, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type y Require. Deberán adoptarse precauciones especiales si se cambian estas propiedades de señalización en ambos puntos P1 y P2 de procesamiento. Son ejemplos de tipos de contenido de medios que pueden ser procesados en este punto de procesamiento los siguientes: SOAP. HTML, vXML, SMIL, gif, mpeg7, au, etc.

-: Punto P3 de procesamiento - Punto de Lote de Solicitud: se ha generado y enviado el mensaje o mensajes SIP resultantes. No pueden producirse más actualizaciones del mensaje o mensajes resultantes. Este punto de procesamiento corresponde a servicios 603 que necesitan invocarse pero no generan una salida que es necesaria para procesar la solicitud. Estos servicios pueden solamente leer el mensaje o mensajes resultantes, pero no pueden actualizarlos.

Los puntos de procesamiento

-: P4 - Respuesta de Servidor de Conexión Intermedia Anterior

-: P5 - Punto de Contenido de Respuesta, y

-: P6 - Punto de Lote de Respuesta

Pueden definirse para mensajes 608 de respuesta de un modo análogo a los puntos P1-P3 de procesamiento, respectivamente.

Alternativamente o adicionalmente, pueden definirse otros puntos de procesamiento. Por ejemplo, puede definirse un punto P0 de procesamiento adicional (no representado) sin restricciones sobre las características y que se activa al producirse cualquier evento, es decir al producirse la recepción tanto de solicitudes 607 como de respuestas 608.

Preferiblemente, pueden asociarse puntos de procesamiento adicionales con uno de los puntos de procesamiento de alto nivel. Por ejemplo, pueden definirse puntos de subprocesamiento para el punto P1 de procesamiento, que pueden denominarse P1.1, P1.2, P1.2.1, P1.2.2, etc. Preferiblemente, deberán definirse nuevos puntos de procesamiento solamente si definen un grupo lógico de servicios que pueden ser beneficiosos para invocación de acuerdo con precondiciones especificadas.

La siguiente tabla incluye algunos ejemplos de servicios que pueden definirse en los diferentes puntos de procesamiento en un servidor SIP de origen y terminación, respectivamente:

4

5

La figura 7 ilustra el flujo de procesamiento entre servicios que pertenecen a puntos de procesamiento diferentes de acuerdo con una realización del invento. En la realización descrita en relación con la figura 6, los servicios que inciden sobre partes diferentes de un mensaje SIP están agrupados en puntos de procesamiento diferentes. Esto puede ser utilizado para proporcionar un procesamiento de servicio eficiente. Los servicios que inciden en las propiedades de señalización SIP de un mensaje entrante 701 están incluidos en el punto P1 de procesamiento. Por consiguiente, la salida del punto P1 de procesamiento comprende las instrucciones finales 702 de control de llamada/medios. Esta disposición puede fundirse inmediatamente con el posible comportamiento por defecto del servidor SIP y transferirse al convertidor 705 de mensajes, que prepara el mensaje SIP 703 saliente. Adicionalmente, los servicios invocados en el punto P2 de procesamiento pueden confiar en que ya no pueden cambiar las propiedades de señalización; por ejemplo pueden solicitar servicios con confianza que dependen de la dirección de destino final genera-
da.

Concentrando lo servicios que inciden solamente en el contenido del cuerpo de mensaje SIP sin información de señalización (y posiblemente los campos de cabecera de contenido relacionados) en el punto P2 de procesamiento, la salida 704 del punto P2 de procesamiento es suficiente para que el servidor envíe realmente el mensaje o mensajes 703 SIP salientes resultantes. La salida 704 del punto P2 de procesamiento es transferida al convertidor 705 de mensajes, y mezclada con la salida 702 del punto P1 de procesamiento, y se envía el mensaje 703.

Cuando la salida de los puntos P1 y P2 de procesamiento está preparada, se alcanza el punto P3 de procesamiento. Los servicios correspondientes al punto P3 de procesamiento no afectan al contenido del mensaje SIP 703 resultante. Por tanto, preferiblemente, el mensaje SIP generado por los puntos P1 y P2 puede ser enviado antes de esperar a la ejecución de los servicios del punto P3 de procesamiento, aumentando así la eficiencia del sistema.

Por tanto, la agrupación de servicios de acuerdo con puntos de procesamiento tiene las siguientes ventajas: los puntos de procesamiento simplifican el problema de la interacción entre características; los puntos de procesamiento hacen más escalable el problema de interacción entre características; y los puntos de procesamiento mejoran la latencia del procesamiento de mensajes cuando se utiliza procesamiento en paralelo, es decir varios procesadores. Las respuestas o solicitudes proxy pueden ser transferidas en retorno a la red de un modo más rápido, porque las aplicaciones de servicio que no especifican instrucciones para el servidor SIP están ubicadas en el punto P3 de procesamiento. Por tanto, la respuesta o solicitud proxy no necesita esperar a que sean invocadas las aplicaciones de servicio en el punto P3 de procesamiento.

La figura 8 ilustra la agrupación de servicios en módulos de reglas correspondientes a la autoridad administrativa de acuerdo con una realización del invento. Dado que los módulos de reglas tienen un propietario de módulo de reglas asociado, corresponden a un dominio administrativo en el que un administrador, es decir el propietario del módulo de reglas, puede especificar políticas de despliegue de servicios. Dentro de un módulo de reglas, el orden de acciones es asignado por el propietario del módulo de reglas, es decir el autor del programa script en lenguaje SERL.

De acuerdo con esta realización del invento, cada módulo de reglas tiene una prioridad asignada. La prioridad especifica la relación entre módulos de reglas. Cuanto más alta es la prioridad del módulo de reglas, antes se aplican las reglas del mismo. La figura 9 muestra esquemáticamente dos módulos de reglas (801 y 802). El módulo 801 de reglas tiene como propietario al administrador A, mientras que el módulo 802 de reglas tiene como propietario al administrador B. Las prioridades de módulo de reglas de los módulos 801-802 de reglas están indicadas por un orden de módulo de reglas, donde un orden bajo corresponde a una prioridad alta, y viceversa. Por ejemplo, el orden 1 de regla puede definirse para tener la prioridad más alta. En el ejemplo de la figura 8, el módulo 801 de reglas tiene un orden h de módulo de reglas y el módulo 802 de reglas tiene un orden h+1. En consecuencia, los servicios 803-804 invocados por el módulo 801 de reglas son ejecutados antes que el servicio 805 del módulo 802 de reglas.

Los módulos de reglas con el mismo propietario pueden tener la misma prioridad de ordenación. Preferiblemente, en ese caso deberán tener diferentes contextos de evento (por ejemplo, SIP, HTTP, ...), evitándose así que sea invocado más de un módulo de reglas con la misma prioridad en el mismo contexto de evento. En otras palabras, los módulos de reglas que pueden ser invocados en base a la misma propiedad de mensaje desde un contexto de evento dado deberán tener prioridades diferentes.

Cada dominio administrativo depende de otros dominios administrativos. Esto significa que un dominio administrativo no necesita tener conocimiento de los servicios desplegados en otros dominios. Cada administrador es responsable de analizar y especificar políticas de despliegue de servicios en un dominio dado.

Si se invoca más de un módulo de reglas o más de una aplicación de servicio en un evento dado, cada uno proporcionará un conjunto de instrucciones de característica que especificarán como ha de ser procesado este evento, por ejemplo si el evento deberá ser cursado o finalizado. Claramente, tales instrucciones de características no deberán ser procesadas simultáneamente, y algunas instrucciones de característica pueden dejar sin efecto otras. Sin embargo, en algunos casos podría no ser importante el orden en que se aplican las instrucciones de características o si se aplican simultáneamente.

De acuerdo con el invento, se crea un mecanismo para permitir a los dominios administrativos proteger sus instrucciones de características cuando transfieren el control a otro dominio administrativo. Esto significa que cada dominio administrativo puede limitar la transferencia del control a propiedades que no son importantes para el comportamiento correcto de sus características. El objeto que es transferido de un servicio a otro es el contexto 806-807 de evento en curso. Preferiblemente, cuando se transfiere el control del contexto 806 de evento entre aplicaciones de servicio que pertenecen al mismo dominio administrativo, la regla por defecto es que no se protegen las propiedades del contexto en curso. Si ha de protegerse algo, ha de hacerse explícitamente. Entre dominios administrativos, sin embargo, todas las propiedades de un contexto 807 de evento son protegidas por defecto. Si no es necesario proteger alguna información entre dominios administrativos, ha de marcarse explícitamente como no protegida. Preferiblemente, el derecho a marcar propiedades protegidas y/o no protegidas deberá ser gobernado por un privilegio asociado con un módulo de reglas.

En otras palabras, los módulos de reglas de prioridad más alta pueden bloquear propiedades de mensaje si tienen los privilegios para hacerlo, y las propiedades de mensaje bloqueadas no pueden ser desbloqueadas por módulos de reglas a no ser que tengan los privilegios para hacerlo.

El siguiente ejemplo de un fragmento de un módulo de reglas ilustra el bloqueo/desbloqueo de propiedades de mensaje después de haber sido ejecutada una característica F1:

6

En una realización del invento, una salida de acción puede finalizar la ejecución del módulo de reglas, es decir no se invocan las aplicaciones en sentido descendente. Adicionalmente, las acciones pueden fijar explícitamente privilegios sobre propiedades de mensaje en el contexto de evento en curso, si tienen los privilegios para hacerlo. Una ventaja de esta realización es que los dominios administrativos son independientes una vez que se les ha asignado una prioridad.

De acuerdo con esta realización, un administrador general asigna las prioridades o rangos de prioridades de los módulos de reglas en base a relaciones contractuales con cada uno de los propietarios de módulos de reglas. El administrador general de dominios sería también naturalmente el propietario del módulo de reglas de prioridad más alta. Por ejemplo, en el nivel más alto de la jerarquía está el proveedor de servicios SIP que posee el nombre de dominio y dirección IP del sistema anfitrión. El proveedor de servicios SIP puede proporcionar muchos servicios a muchos participantes. Puede también correr aplicaciones para sus propios fines, por ejemplo control de contraseñas, contabilidad, acopio de datos estadísticos, detección de fraudes, anuncios, etc. Puede situar uno o más módulos de reglas en el servidor.

Por ejemplo, el proveedor de servicios SIP puede situar un módulo de reglas para cada uno de sus abonados. Cuando se ha recibido un evento SIP en el servidor SIP, el módulo de reglas principal de proveedores de servicios SIP puede invocar alguno de sus propios servicios y entregar a continuación el control al módulo de reglas para el abonado adecuado. En este módulo de reglas pueden existir reglas para activar servicios adaptados al abonado específico. Estos servicios pueden ser proporcionados por el propio proveedor de servicios SIP o ser transferidos por el proveedor de servicios SIP de propiedades de señalización de tercera entidad. El proveedor de servicios SIP sería responsable de analizar los problemas de interacción entre características entre estos servicios y especificar prioridades de orden y prioridades de instrucciones entre las aplicaciones de servicio, preferiblemente utilizando el lenguaje SERL. En este caso, el módulo de reglas principal y el módulo de reglas de abonado tienen ambos como propietario y administrador al proveedor de servicios SIP. Se dice que están en un dominio administrativo. En algún punto en la prioridad de orden, el proveedor de servicios SIP puede decidir entregar el control a un módulo de reglas del que es propietario el propio abonado. Obsérvese que abonados individuales pueden ser capaces de escribir sus propios programas script SERL, o pueden ser capaces solamente de actualizar preferencias, por ejemplo a través de un formato HTML, a partir del cual puede ser generado un programa script SERL. El módulo de reglas del abonado puede invocar un programa script CPL, o puede invocar a su vez otro módulo de reglas, algún módulo de reglas del proveedor de servicios de tercera entidad, etc. Si el módulo de reglas del abonado incluye más de una acción, el abonado tiene que especificar la acción que deberá realizarse en primer lugar. Igualmente, en el módulo de reglas de terceras entidades las acciones deberán ordenarse de acuerdo con los deseos de la tercera entidad.

En otro escenario, el abonado puede ser un empleado de un cliente corporativo. En este caso, el módulo de reglas de los proveedores de servicios SIP puede entregar el control primero al módulo de reglas del cliente de empresa que podría invocar algunas aplicaciones, y transferir a continuación el control al módulo de reglas del abonado individual.

El administrador de nivel máximo puede preferir entremezclar el orden de prioridad con varios módulos de reglas. Sin embargo, puede ser problemático entremezclar módulos de reglas con módulos de reglas de prioridad más baja de otros abonados. Una solución a este problema es separar las prioridades de módulo de reglas con suficientes márgenes de reserva que pueden ser utilizados posteriormente. Alternativamente, puede aplicarse un modelo de dominio administrativo jerárquico, como se describirá en relación con la figura 12.

Preferiblemente, el ambiente de soporte de servicios soporta un mecanismo para notificar a los administradores cuando una aplicación intenta alterar una propiedad protegida. Preferiblemente, una aplicación que intenta alterar una propiedad protegida es puesta fuera de servicio.

Es de observar que son posibles modificaciones del esquema anterior. Por ejemplo, en una jerarquía de dominios administrativos, cada administrador de niveles de prioridad puede tener una visión completa para disponer módulos de reglas en niveles con prioridad más baja, dentro de un margen de prioridades asignado. El administrador de nivel superior delegaría este ámbito funcional.

Una ventaja de esta realización es que crea un mecanismo escalable para gestionar e implementar políticas de despliegue de servicios. De acuerdo con esta realización, el ambiente de soporte de servicios es capaz de asumir políticas de despliegue de servicios de terceras partes sin un trabajo adicional considerable para el administrador de dominio. Una ventaja adicional es que se imponen limitaciones al número de partes interesadas o al número de relaciones contractuales entre ellas.

Una ventaja adicional de esta realización es que la tarea de análisis de interacción entre características se divide en dominios administrativos, permitiendo así una distribución del problema entre las partes interesadas.

La figura 9 ilustra una realización del invento en la que los servicios están agrupados tanto de acuerdo con puntos de procesamiento, como de acuerdo con la autoridad administrativa. La figura 9 muestra esquemáticamente un módulo 901 de reglas con orden h de prioridad y un módulo 902 de reglas con orden h+1 de prioridad. El módulo 901 de reglas invoca servicios F1, F2, F5 y F6, mientras que el módulo 902 de reglas invoca servicios F3, F4, F7 y F8. Los servicios F1-F8 están relacionados adicionalmente con puntos 903 y 904 de procesamiento. El punto 903 de procesamiento incluye los servicios F1-F4, y el punto 904 de procesamiento incluye los servicios F5-F8. Los puntos 903-904 de procesamiento están numerados de tal modo que el punto 903 de procesamiento tiene el índice K y el punto 904 de procesamiento tiene el índice K+1, indicando que el punto 903 de procesamiento es procesado antes que el punto 904 de procesamiento.

De acuerdo con esta realización, se aplican reglas en la secuencia de los puntos de procesamiento. En consecuencia, cuando se procesan módulos de reglas, solamente se ejecutan las reglas de ejecución de servicio que pertenecen al punto de procesamiento en curso.

Para cada punto de procesamiento existen conjuntos de módulos de reglas que están agrupados de acuerdo con niveles de prioridad y que pueden ser invocados en ese punto de procesamiento. Todos los módulos de reglas de prioridad 1 están agrupados en el conjunto 1, todos los módulos de reglas de prioridad 2 están agrupados en el conjunto 2, y así sucesivamente. Sin embargo, dado un contexto de evento, a lo sumo se invoca un módulo de reglas en cada uno de estos conjuntos. Un módulo de reglas puede estar distribuido en varios puntos de procesamiento. En el ejemplo de la figura 9, se procesan primero los servicios de acuerdo con su prioridad de módulo de reglas, es decir los servicios F1 y F2 antes que los servicios F3 y F4. Subsiguientemente, se invocan las características F5 y F6 del punto 904 de procesamiento y la prioridad de nivel h, antes que los servicios F7 y F8.

Los módulos 901 y 902 de reglas, que están ilustrados esquemáticamente en la figura 9, pueden expresarse como se indica en los siguientes ejemplos de módulos de reglas:

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

(Esquema pasa a página siguiente)

7

8

La figura 10 ilustra el mecanismo de tratamiento de realización de la figura 9 en caso de existir varios módulos de reglas y varios puntos de procesamiento. De acuerdo con esta realización, existen cuatro puntos de procesamiento numerados de P0 a P3 y cinco módulos RM A a RM E de reglas con prioridades 1 a 5, respectivamente. De acuerdo con las reglas de procesamiento descritas en relación con la figura 9, los servicios se procesan como se indica por los círculos que aparecen en la figura 10, que están numerados de 1 a 20 y unidos por flechas. Cada círculo numerado puede representar un conjunto de reglas que invocan varias acciones.

La figura 10 ilustra otro ejemplo de las reglas de procesamiento descritas en relación con la figura 9. La figura 11 ilustra casos 1111a-1115a de módulos RM A a RM E de reglas en el lado izquierdo 1101, y casos 1111b-1115b de módulos RM A a RM E de reglas en el lado derecho 1102 de la figura, respectivamente. Los módulos RM A a RM E de reglas comprenden reglas correspondientes a los puntos P0 a P6 de procesamiento. Por tanto, los casos de módulos de reglas ilustrados en el lado izquierdo 1101 pueden representar secciones de los mismos módulos de reglas respectivos diferentes de las de los módulos de reglas ilustrados en el lado derecho 1102. Como se describió en relación con la figura 6, los puntos P1- P3 de procesamiento son activados por solicitudes SIP, mientras que los puntos P4-P6 de procesamiento son activados por respuestas. El punto P0 de procesamiento es activado tanto por solicitudes como por respuestas. Por tanto, en este ejemplo, una solicitud 1103 SIP entrante, por ejemplo una solicitud de invitación, activa servicios de los módulos RM A a RM E de reglas que están relacionados con puntos P0-P3 de procesamiento, en el orden indicado por las flechas que aparecen en el lado izquierdo 1101 en la figura 11. En el ejemplo de la figura 11, se supone adicionalmente que un servicio 1104 emite una instrucción que provoca una respuesta 1105. Esta respuesta, a su vez, activa el procesamiento de las reglas de los módulos RM A (111b) a RM E (1115b) de reglas que están relacionados con los puntos P0 y P4-P6 de procesamiento, como se indica al lado derecho 1102 de la figura 11, partiendo del servicio o servicios 1106, y resultando un mensaje saliente 1108, por ejemplo una respuesta provisional generada. El procesamiento de los servicios del lado izquierdo 1101 da lugar además a un mensaje saliente 1107, por ejemplo una solicitud proxy de invitación.

La figura 12 ilustra una secuencia de procesamiento jerárquico de módulo de reglas de acuerdo con una realización preferida del invento. Cuando el motor 1200 de reglas recibe un evento 1201, identifica los módulos 1216-1219 de reglas pertinentes de diferentes prioridades para este evento en la base de reglas. El motor 1200 de reglas genera un contexto 1202 de evento en curso, inicia el procesamiento del módulo 1216 de reglas de prioridad más alta, y transfiere el control a ese módulo 1216 de reglas en base al contexto 1202 de evento en curso generado. Cuando se ha completado el procesamiento del módulo 1216 de reglas de prioridad más alta, el motor 1200 de reglas invoca el módulo 1217 de reglas subsiguiente de acuerdo con la prioridad de módulos de reglas y transfiere el contexto 1206 de evento en curso modificado al siguiente módulo 1214 de reglas. Similarmente, los módulos 1218-1219 de reglas subsiguientes son invocados y se transfiere a ellos el control sobre los respectivos contextos 1207 y 1214 de evento en curso. Finalmente, el contexto 1215 de evento resultante es retornado al motor 1200 de reglas. De acuerdo con esta realización del invento, cada módulo de reglas invocado puede invocar subsiguientemente a uno o más de otros módulos de reglas. De acuerdo con una realización preferida, los módulos de reglas están divididos en dos tipos: módulos 1216-1219 de reglas que pueden ser invocados por el motor 1200 de reglas de acuerdo con su prioridad de orden, y módulos 1220-1225 de reglas que pueden ser invocados solamente por otros módulos de reglas. El último tipo de módulos de reglas puede ser identificado formalmente por una prioridad de orden especial, por ejemplo la prioridad 0 de ordenación. De acuerdo con esta realización, los módulos de reglas con esta prioridad tienen restricciones especiales asociadas: los módulos de reglas con esta prioridad de orden no deberán ser invocados por el procedimiento de procesamiento de base de reglas del motor 1200 de reglas, sino que son invocados por otro módulo de reglas con privilegios explícitos para hacerlo. Los módulos de reglas con prioridad de ordenación diferente de 0 no son invocados desde otro módulo de reglas, sino solamente por el motor de reglas. Los módulos de reglas que tienen el mismo propietario pueden tener la misma prioridad de ordenación (diferente de 0), pero en ese caso deberán tener contextos de evento diferentes, por ejemplo SIP, HTTP, etc. Esto significa que no deberán ser invocados sobre el mismo contexto de evento. Los módulos de reglas con propietarios diferentes pueden tener la misma prioridad de ordenación, pero en ese caso no deberán ser invocados en relación con la misma propiedad en el mismo evento. En otras palabras, los módulos de reglas que pueden ser invocados sobre la misma propiedad de mensaje desde un contexto de evento dado deberán tener prioridades diferentes, a no ser que tengan prioridad 0. El primer módulo 1216 de reglas es invocado por el motor de reglas, antes de que sea invocado cualquier módulo de reglas con prioridad 0 de ordenación. Este módulo de reglas se denomina módulo de reglas raíz. Cuando el módulo 1216 de reglas raíz invoca módulos de reglas de prioridad 0, estos pueden invocar nuevamente otros módulos de reglas de prioridad 0. Estas relaciones entre módulos de reglas se denominan jerarquía de módulos de reglas. Este mecanismo de invocación de módulos de reglas desde dentro de módulos de reglas proporciona una distribución jerárquica de dominios administrativos, denominada también modelo jerárquico de dominios administrativos. Las ventajas de este modelo consisten en que es fácil de administrar y permite un control muy riguroso de los módulos de reglas maestros. Una ventaja adicional es que pueden añadirse módulos de reglas adicionales a una jerarquía existente sin tener que reasignar un gran número de prioridades a módulos de reglas subsiguientes. Las anteriores reglas evitan que los módulos de reglas sean invocados dos veces por accidente en el procedimiento de procesamiento de base de reglas.

En el ejemplo ilustrado en la figura 12, el módulo 1216 de reglas invoca los módulos 1221 y 1222 de reglas en ese orden, transfiere el control de los contextos 1203-1204 de evento correspondientes, y recibe el contexto 1205 de evento en curso resultante. Similarmente, el módulo 1218 de reglas invoca los módulos 1222-1223 de reglas con los contextos 1208-1209 de evento correspondientes y el contexto 1213 de evento resultante. Finalmente, el módulo 1223 de reglas invocado por el módulo 1218 de reglas invoca adicionalmente los módulos 1224-1225 de reglas con los contextos 1210-1211 de evento correspondientes y el contexto 1212 de evento resultante.

Por tanto, se realiza un proceso de invocación jerárquico, que genera una secuencia de contextos de evento indicada por la numeración de los contextos 1202-1215 de evento.

Se observa que, si existe más de un punto de procesamiento definido, la anterior descripción del procesamiento de módulos de reglas deberá entenderse con referencia a cada punto de procesamiento, es decir para cada punto de procesamiento se procesa una jerarquía correspondiente de módulos de reglas.

Una tarea importante del procedimiento de procesamiento de la base de reglas del motor 1200 de reglas es establecer la relación entre eventos SIP y módulos de reglas pertinentes. Este proceso depende en alto grado de las relaciones contractuales definidas en el dominio en cuestión. Un evento SIP incluye varias propiedades de mensaje que pueden ser utilizadas para detectar una posible relación contractual. Estas propiedades incluyen siprequest.from, siprequest.to, siprequest.RequestURI, sipresponse.from, siprespopnse.to, sipresponse.contact, y sipresponse.via. En particular, las propiedades From y Request-Uri de un mensaje SIP son propiedades importantes en un evento utilizadas para detectar una relación contractual con un operador de red o proveedor de servicios de tercera entidad. Sin embargo, pueden tenerse en cuenta otras propiedades de mensaje, por ejemplo cabeceras de contacto y cabeceras de vía de transmisión. Se hará referencia a una propiedad de mensaje que puede ser utilizada para detectar una relación contractual y activar así un módulo de reglas, como propiedad de activación de módulo de reglas (RMTrigger).

Cuando llega un mensaje de solicitud SIP a un servidor SIP, al menos una de las propiedades de mensaje From o Request-URI deberá especificar un abonado que tiene una relación contractual con uno de los operadores de red del servidor SIP. Las propiedades de mensaje From o Request-URI pueden contener un nombre de dominio, como netopX.com, o una dirección IP de uno de los operadores de red, como 123.123.123.000. Adicionalmente, las propiedades de mensaje From o Request-URI incluyen un identificador de abonado, tal como un nombre o número de teléfono. Este identificador está contenido en los localizadores SIP URL o TEL URL. El localizador SIP-URL tiene también parámetros como "transport-param" (parámetro de transporte), "user-param" (parámetro de usuario) y "other-param" (otro parámetro). Estos parámetros pueden incluir información específica sobre un operador de red, como el identificador IMSI, para identificar abonados de terminal y terminales móviles.

Por ejemplo, utilizando las propiedades anteriores, un evento SIP puede ser relacionado con un solo operador de red, si se cumplen varios requerimientos, por ejemplo si cada uno de los operadores de red del servidor SIP tiene un nombre de dominio singular, como netopX.com u netopY.com, y si tienen direcciones IP diferentes. Si comparten la misma dirección IP, las resoluciones de relaciones contractuales pueden ser ambiguas, dado que las propiedades de mensaje From o Request-URI pueden contener una dirección IP y no un nombre de dominio.

Los proveedores de servicios de tercera entidad que cargan/registran aplicaciones de servicio en el servidor SIP tienen una relación contractual con el operador de red que puede ser detectada. Por ejemplo, el proveedor de servicios de tercera entidad puede recibir del operador de red con el que el proveedor de servicios de tercera entidad tiene una relación contractual, un código de identificación asignado. Si el operador de red tiene un nombre de dominio, por ejemplo netopX.com, y una dirección IP asociada, el proveedor de servicios de tercera entidad que tiene el nombre singular partyZ, puede recibir identificadores asignados después de un convenio de denominación, por ejemplo "partyZ.netopX.com". Ahora las propiedades de mensaje From o Request-URI pueden adaptarse a módulos de reglas pertinentes. Dado que deberán invocarse ambos identificadores netopX.com y partyZ.netopX.com al producirse un evento que contiene las palabras netopX.com en cualquiera de las propiedades de mensaje From o Request-URI, deberán tener prioridades de ordenación explícitas diferentes. Se entiende que pueden introducirse otros convenios de denominación en vez de los comentados.

Se entiende que los mecanismos de prioridad de orden y jerarquía de módulos de reglas pueden aplicarse independientemente entre sí o combinados, como se ha descrito en relación con la figura 12.

La figura 13 muestra un ejemplo del flujo de mensajes SIP y conjuntos de instrucciones de acuerdo con una realización del invento. El analizador 1304 de mensajes convierte el mensaje SIP 1306 original en un objeto 1303 de mensaje SIP original. Esto se utiliza para invocar el módulo 1301 de reglas inicial y, por tanto, la primera secuencia de aplicaciones de servicio. Cuando se carga un módulo 1301 de reglas en el motor 1302 de reglas y se ejecuta, se realizan una o más acciones, dependiendo del objeto 1303 de mensaje de señalización que fue recibido del analizador 1304 de mensajes y sobre la base del módulo 1301 de reglas que fue identificado, por ejemplo como se ha descrito en relación con la figura 12. Cuando se realiza una acción, se invoca la aplicación 1305 de servicio asociada con la acción, es decir se activa, posiblemente con parámetros y posiblemente con acceso al objeto 1303 completo de mensaje de señalización que activó la aplicación. Los privilegios de acceso a la totalidad del mensaje de señalización dependen de la funcionalidad y ámbito del acceso API de servicio utilizado, por ejemplo CGI API frente a OSA API, así como de los privilegios del propietario del módulo 1301 de reglas y de los privilegios de la aplicación 1305 de servicio invocada. El objeto 1303 de mensaje de señalización inicial representa el conjunto completo de propiedades de mensaje embebidas en el mensaje SIP original 1306, que pueden incluir varios tipos de medios. La aplicación 1305 de servicio invocada realiza algún procesamiento en base al mensaje 1303 de señalización y devuelve el resultado 1307 al motor 1302 de reglas. Se hace referencia a este resultado como conjunto de instrucciones, dado que puede contener potencialmente varias instrucciones, por ejemplo instrucciones CGI, instrucciones OSA API, etc. Cuando se invocan varios servicios en base a un mensaje de señalización, el procesador de módulo de reglas finalizará su secuencia con varios conjuntos de instrucciones. Este conjunto de conjuntos de instrucciones se denomina "base de conjuntos de instrucciones".

El motor 1302 de reglas y el motor de ejecución de aplicaciones determinan las instrucciones que mediarán en el comportamiento 1308 por defecto del servidor SIP. El conjunto de instrucciones puede ser filtrado en base a privilegios y a la resolución de interacciones entre características, antes de mediar en el comportamiento 1308 por defecto del servidor SIP que puede mezclar adicionalmente el conjunto de instrucciones con un conjunto 1312 de instrucciones SIP por defecto. El conjunto de instrucciones resultante se denomina "conjunto de instrucciones resultante". El objeto u objetos 1309 de mensaje SIP representa o representan los mensajes SIP actuales, que han de ser enviados descendente o ascendentemente. Por tanto, esto conduce a uno o más objetos 1309 de mensaje SIP resultante que son enviados al convertidor 1310 de mensajes que, subsiguientemente, transforma los mismos en uno o más mensajes SIP 1311 a enviar.

La figura 14 ilustra un mecanismo para gestionar varios conjuntos de instrucciones de acuerdo con una realización preferida del invento. De acuerdo con esta realización, un contexto de evento es una representación de un objeto de mensaje SIP, pero puede contener información adicional, tal como información sobre interacción entre características y también los tipos MIME incluidos en el cuerpo de mensaje del mensaje SIP. El contexto 1401 de evento original representa el objeto 1402 de mensaje SIP original. El contexto 1403a-b de evento en curso es un contexto de evento basado en el conjunto de instrucciones generado por las aplicaciones 1404-1405 de servicio. En cualquier instante dado, una aplicación de servicio asume el control del contexto de evento en curso. Incluso cuando están corriendo concurrentemente varias aplicaciones de servicio y están controlando el tratamiento de la transacción, solamente una de ellas tiene el control del contexto de evento en curso en cualquier momento. En el ejemplo de la figura 14, se muestran dos aplicaciones 1404-1405 de servicio. Inicialmente, la aplicación 1404 de servicio tiene el control sobre el contexto 1403a de evento en curso. Cuando el programa 1404 de aplicación ha completado su procesamiento, el control sobre el contexto de evento en curso es transferido al programa 1405 de aplicación de servicio. En esta situación, el programa 1405 de aplicación de servicio controla el contexto de evento en curso (1403b), es decir tiene el derecho de leer y escribir datos en el mismo. En una realización del invento, otras aplicaciones de servicio pueden tener el derecho de leer el contexto 1403b de evento en curso.

Por tanto, la activación de aplicaciones de servicio subsiguientes está basada en el contexto de evento en curso. El contexto de evento en curso es depurado adicionalmente de posibles problemas de interacción entre características, de modo que las aplicaciones de servicio invocadas subsiguientemente pueden confiar en el mismo. Cuando se transfiere el control de una aplicación de servicio a la siguiente mediante el mecanismo de invocación proporcionado por el motor de reglas, la propiedad del contexto de evento en curso es transferida. De este modo, cuando todas las aplicaciones de servicio han sido invocadas y se han aplicado sus instrucciones, se consigue el contexto 1406 de evento resultante final. De este modo, el contexto 1406 de evento resultante representa el objeto u objetos 1407 de mensaje SIP resultantes. Obsérvese que este mecanismo no excluye el procesamiento en paralelo, puesto que las aplicaciones 1404 y 1405 de servicio pueden ser ejecutadas en paralelo. Sin embargo, de acuerdo con esta realización, se impone una secuencia de actualización del contexto de evento en curso.

Es de observar adicionalmente que una aplicación de servicio puede desviar simultáneamente una solicitud a varios destinos. Esto da lugar a la generación de varios contextos de evento en curso.

La figura 15 ilustra un árbol de cadenas en cascada de aplicaciones de servicio de acuerdo con una realización del invento. Cuando se ejecutan servicios en diferentes servidores SIP y aplican el control a una sesión, proporcionan una ordenación natural de servicios, incluso si no existe conocimiento mutuo. Puede decirse que esta ordenación es ascendente o descendente. Una ordenación descendente es la ordenación de servicios que se produce a medida que son invocados en sentido descendente desde el cliente de origen hasta el cliente de destino. Una ordenación ascendente es la ordenación de servicios que tiene lugar a medida que son invocados ascendentemente desde el servidor de destino hasta el cliente de origen. Cuando son invocados en un orden dado servicios que aplican el control a un caso de una sesión en el mismo servidor SIP, los servicios pueden considerarse como organizados en cascada de acuerdo con el mismo principio de ordenación. Este principio de ordenación se denomina ordenación de servicios en cascada, y la cadena de servicios se denomina cadena de servicios en cascada.

Cuando es recibida una solicitud, cuanto antes se invoca un servicio en base a este evento, se considera que está más arriba en sentido lógico ascendente en la cadena de servicios en cascada. Cuando se recibe una respuesta, entonces cuanto antes se invoca el servicio en base a este evento, se considera que está más abajo en sentido lógico descendente en la cadena de servicios en cascada. Por tanto, las aplicaciones son tratadas como si se activasen en anfitriones diferentes.

Este modelo es conceptualmente simple y proporciona un algoritmo natural para resolver conflictos entre las instrucciones de varias aplicaciones de servicio en el mismo evento SIP.

Al recibirse un evento SIP, las acciones se ejecutan según su orden de prioridad del modo siguiente:

1): El control se transfiere a la primera aplicación.

2): Se recibe alguna respuesta de la primera aplicación.

3): El control se transfiere a la segunda aplicación.

4): Se recibe alguna respuesta de la segunda aplicación, y así sucesivamente.

Sin embargo, si la primera aplicación finaliza el tratamiento de la solicitud, no se invoca la segunda aplicación.

De este modo, una decisión sobre si ha de invocarse una aplicación subsiguiente puede depender de la salida de la aplicación anterior. Adicionalmente, las prioridades de instrucción asociadas con acciones son ordenadas por defecto de acuerdo con el principio de organización en cascada.

Si una aplicación bifurca una solicitud, no existe una cadena sencilla de servicios en cascada, sino más bien un árbol de servicios en cascada. Se hará referencia a este como "árbol de solicitudes". Un árbol de solicitudes representa varias cadenas de aplicaciones en cascada. Cada camino desde la raíz del árbol hasta una de sus hojas representa una cadena en cascada.

La figura 15 muestra un ejemplo de un árbol de solicitudes, en el que es invocada una aplicación APP1 de servicio por el módulo 1501 de ejecución de módulo de reglas con el contexto OEC de evento original como entrada. Cuando el control es transferido desde la aplicación APP1 hasta la aplicación subsiguiente APP2, la aplicación APP2 obtiene el control sobre el contexto EC2 de evento en curso. La aplicación APP2 bifurca la solicitud creando un contexto EC3 de evento y un contexto EC4 de evento. Una acción de prioridad inferior invoca la aplicación APP3 debido a una o más propiedades del contexto EC3 de evento. Otra acción de prioridad inferior invoca otra aplicación APP4 debido a una o más propiedades del contexto EC4 de evento. Esto conduce a una estructura en forma de árbol que representa la estela de las aplicaciones invocadas. En este árbol las ramas son representaciones de contextos de evento. Los nudos son representaciones de activaciones. La raíz del árbol es el contexto OEC de evento original. Las hojas del árbol son los contextos REC1 y REC2 de evento resultantes.

Cuando no existen más acciones en un módulo de reglas, todos los contextos de evento en curso son realimentados al procedimiento 1502 de procesamiento de la base de reglas. Este procedimiento puede invocar otro módulo de reglas que construirá una parte adicional del árbol de solicitudes. En consecuencia, el árbol de solicitudes se hace muy grande con muchos nudos y ramas, dependiendo de los servicios que se han activado.

Es de observar que en algunos casos un programa de aplicación puede enviar una instrucción de característica asíncrona al ambiente de soporte de servicios, es decir una instrucción no relacionada con una transacción existente. En este caso la aplicación ha iniciado una nueva transacción y se considera que está situada en la raíz de un nuevo árbol de cadenas en cascada.

Con el fin de hacer posible el procesamiento de servicios en paralelo, el ambiente de soporte de servicios puede ser capaz de transferir el control a más de un servicio simultáneamente. Esto no está en contradicción con el modelo de servicios en cascada, porque las instrucciones derivadas de los servicios invocados en paralelo deberán aplicarse en el orden de la disposición en cascada. Si el servicio situado más bajo en sentido descendente responde antes que el servicio situado más alto en sentido ascendente, el motor de reglas espera que responda el servicio más alto en sentido ascendente, antes de que pueda mediar en las instrucciones. Las instrucciones son mediadas como si los servicios fuesen invocados uno por uno. El administrador deberá ser capaz de especificar si un grupo de acciones se aplicará simultáneamente de este modo.

La figura 16 muestra los componentes de programa de un motor de reglas de acuerdo con una realización del invento. El procedimiento 1601 de procesamiento de base de reglas invoca los módulos 1602 de reglas almacenados en la base 1603 de reglas en el orden correcto. El procedimiento 1604 de procesamiento de motor de reglas ejecuta las reglas del módulo de reglas. El módulo 1605 de interacción de servicios cubre un conjunto de funciones 1700 que incluyen la imposición de la activación, interacción entre características, privilegios y derechos. Las funciones 1700 se describirán con más detalle en relación con la figura 17.

Cuando es reportado un evento SIP al módulo de reglas en la forma de un contexto 1609 de evento original, se ejecuta el procedimiento 1601 de procesamiento de base de reglas con el fin de encontrar y ejecutar los módulos de reglas correctos en el orden correcto. El procedimiento 1601 de procesamiento de base de reglas transfiere los módulos de reglas a procesar y el contexto 1610 de evento original al procedimiento 1604 de procesamiento de módulo de reglas. La ordenación de los módulos de reglas junto con la ordenación de las reglas incluidas en cada módulo de reglas determina la ordenación de patrones y acciones 1606-1608 procesadas por el procedimiento 1604 de procesamiento de módulo de reglas. Las acciones invocan aplicaciones 1611-1613 de servicio correspondientes. Cuando se invoca la aplicación 1611 de servicio, el contexto de evento original es transferido como contexto CEC1 de evento en curso al módulo 1605 de interacción de servicios que, a su vez, transfiere el contexto EC1 de evento a la aplicación 1611 de servicio. La aplicación 1611 de servicio genera un conjunto de instrucciones 1614 de característica que hacen que sea actualizado el contexto de evento en curso por el módulo 1605 de interacción de servicios. El contexto 1615 de evento en curso resultante es devuelto al procedimiento 1604 de procesamiento de módulo de reglas. Las aplicaciones 1612 y 1613 de servicio son invocadas de un modo similar, resultando conjuntos 1616- 1617 de instrucciones correspondientes que son convertidos por el módulo 1605 de interacción de servicios en contextos correspondientes 1618-1618 de evento en curso. Durante esta conversión, el módulo 1605 de interacción de servicios realiza comprobaciones de autorización y, si una aplicación 1613 de servicio retorna un conjunto 1617 de instrucciones sin autorización, las instrucciones no autorizadas no son convertidas. Por tanto, el contexto 1619 de evento en curso no difiere del contexto 1620 de evento entrante. Preferiblemente, la aplicación de servicio es notificada de este fallo (1621). Es de observar que un servicio puede dar lugar a la generación de múltiples contextos de evento en curso, como se describe en relación con las figuras 15 y 18. Cuando un módulo de reglas finaliza el procesamiento de patrones y acciones 1606-1608, el conjunto final de contextos 1622 de evento en curso es retornado al procedimiento 1601 de procesamiento de base de reglas. Las invocaciones subsiguientes de módulos de reglas dependerán de este conjunto de contextos de evento en curso. Se observa que una aplicación de servicio puede armar/desarmar eventos y activaciones para eventos futuros, como se describirá con más detalle posteriormente. Por tanto, una aplicación de servicio puede retornar adicionalmente una solicitud 1623 de armado.

La figura 17 muestra las operaciones realizadas por el módulo de interacción de servicios entre el procesamiento del módulo de reglas y el procesamiento de la aplicación de servicio en la realización de la figura 16. Esta funcionalidad 1700 incluye gestión de interacciones entre características y comprobación de privilegios, operaciones realizadas por el motor 1702 de reglas y el motor 1703 de ejecución de aplicaciones. Cuando es recibida la orden de invocación y el contexto CECa de evento en curso procedentes del procesador 1601 de módulo de reglas, los privilegios del módulo de reglas son comprobados en la operación 1704. Los privilegios del módulo de reglas están especificados en una lista ACL2 de control de acceso asociada con el módulo de reglas. Si el módulo de reglas tiene los privilegios para emitir órdenes de invocación, en la operación 1705 el motor 1702 de reglas envía la orden de invocación al motor 1703 de ejecución de aplicaciones a través del gestor de motor de ejecución de aplicaciones (no representado). Puede ser necesario solamente enviar parte del contexto de evento en curso al motor 1703 de ejecución de aplicaciones, como se indica por f (CECa).

En la operación 1706, el motor 1703 de ejecución de aplicaciones convierte el contexto f (CECa) de evento recibido a un formato de datos adecuado para que sea invocada la aplicación 1707 de servicio. Esta operación puede incluir la conversión a un espacio de nombres adecuado para la invocación de esa aplicación de servicio. Adicionalmente, en la operación 1708, el motor 1703 de ejecución de aplicaciones comprueba privilegios y derechos. Una lista ACL3 de control de acceso asociada con la aplicación 1707 de servicio puede especificar los privilegios de dicha aplicación para acceder al valor del contexto f (CECa) o a parte del mismo. Adicionalmente, el módulo de reglas tiene acceso a la aplicación 1707 de servicio dependiendo de otra lisa ACL4 de control de acceso, asociada también con la aplicación 1707 de servicio. Si el acceso es concedido, la aplicación 1707 de servicio es invocada en la operación 1709, y son proporcionadas como entradas las partes pertinentes del contexto g (ECa) de evento. Subsiguientemente, la aplicación 1707 de servicio devuelve el control al motor 1702 de reglas a través del motor 1703 de ejecución de aplicaciones enviando el conjunto 1710 de instrucciones o una representación interna de dicho conjunto. En la operación 1711, son comprobados los privilegios y derechos de la aplicación 1707 de servicio para emitir estas instrucciones, por ejemplo en base a una lista ACL5 de control de acceso asociada con la aplicación 1707 de servicio. Si la aplicación 1707 de servicio tiene los privilegios para emitir estas instrucciones, las instrucciones son convertidas a partir de la representación interna (operación 1712), y las instrucciones convertidas 1713 son transferidas al motor de reglas. Adicionalmente, se transfiere también cualquier solicitud 1716 de armado. En la operación 1714, se resuelven posibles problemas de interacción entre características con instrucciones emitidas anteriormente por aplicaciones de servicio autorizadas e invocadas previamente. Esta resolución está basada en la condición de que las aplicaciones invocadas anteriormente tengan propiedades de mensaje protegidas en el contexto de evento en curso. El siguiente contexto de evento en curso (CECb) es generado y retornado al procesador 1601 de módulo de reglas. Finalmente, en la operación 1715, el motor de reglas almacena en memoria información relativa al servicio invocado, por ejemplo construyendo el árbol de solicitudes descrito en la figura 14. El árbol de solicitudes es utilizado en relación con el reporte de eventos futuros.

Como se ha mencionado anteriormente, algunos servicios, por ejemplo la vigilancia de programas de aplicación, tienen interés para eventos futuros. Con el fin de informar al motor de reglas sobre este interés en eventos futuros, la aplicación de servicio tiene que solicitar reportes de evento, lo que se denomina también armado dinámico para reportes de evento.

De acuerdo con una realización preferida del invento, el armado dinámico de eventos de transacción está ligado al procesamiento de una transacción SIP, operación que está limitada en tiempo. Las aplicaciones pueden durar típicamente desde algunos milisegundos hasta unos pocos minutos dependiendo de la configuración del servidor SIP. Puesto que el armado dinámico de eventos de transacción se aplica solamente al tiempo de ejecución de una transacción, este tipo de armado no es permanente y se desactiva implícitamente cuando finaliza la transacción, proporcionando así un mecanismo rápido. Si una aplicación arma eventos que pertenecen a la transacción que fue activada, la aplicación conserva su posición en el modelo de servicios en cascada. Son reportadas respuestas a todas las aplicaciones que han armado eventos, partiendo de la hoja del árbol, es decir de la aplicación extrema en sentido descendente. Durante el tiempo de ejecución de una transacción, el árbol de solicitudes existe en la memoria del motor de reglas. Los eventos subsiguientes relacionados con la misma transacción están así relacionados con el árbol de solicitudes. Los eventos relativos al árbol de solicitudes pueden proceder de aplicaciones, de servidores en sentido descendente y de clientes en sentido ascendente.

Los eventos procedentes de clientes ascendentes entran en el árbol de solicitudes por la raíz. Esto significa que son reportados primero a la aplicación en la raíz del árbol. Esta aplicación puede terminar o redirigir el evento, en cuyo caso no será enviada adicionalmente en el árbol original, sino que puede construirse un nuevo árbol de solicitudes. Una solicitud puede también necesitar ser transferida a todos los mismos destinos que la solicitud original, o puede ser necesario enviar la solicitud a uno de los destinos a los cuales fue cursada la solicitud original. Los eventos procedentes de programas de aplicación entran en el árbol de solicitudes en el nudo adecuado. Los eventos procedentes de servidores en sentido descendente entran en el árbol de solicitudes en una de las hojas.

Esto conduce al mecanismo de recorrido del árbol de solicitudes, en el cual el motor de reglas recuerda el orden en el que fueron invocadas las aplicaciones, es decir el árbol de solicitudes. Una ventaja de esta realización es que proporciona una regla clara para el orden en el cual son reportados los eventos dentro del contexto de una transacción. La regla clara corresponde al modelo de servicios en cascada y aporta una regla conceptualmente simple que puede ser comprendida fácilmente por administradores y diseñadores de aplicaciones. Esto simplifica también la interfaz API a través de la cual los motores de ejecución de aplicaciones añaden reglas a la base de reglas. En vez de tener que preparar la cancelación de una rama específica en un módulo de reglas, este sistema puede preparar simplemente la cancelación de la vía de llamada concreta.

Existen diversos modos de implementar el recorrido del árbol de solicitudes.

Por ejemplo, el motor de reglas puede conseguir este recorrido utilizando la cabecera VIA y un parámetro de rama. En realidad, esto significaría la creación de un caso independiente del módulo de reglas cada vez que es cambiada la dirección de destino cursando la solicitud al servidor SIP. La búsqueda DNS realizada por la pila SIP determinaría entonces si la solicitud es devuelta para ser procesada por el servidor una segunda vez. Cuando es recibida una solicitud del servidor SIP, sería tratada como una nueva solicitud. Este motor de reglas deberá tener un mecanismo para asegurar que los servicios, por ejemplo los activados en el campo FROM, no serían invocados erróneamente otra vez.

Alternativamente, en una realización preferida, el evento es tratado en el sistema anfitrión para el árbol de solicitudes completo, es decir incluyendo todas las transferencias hasta que todas las hojas del árbol de solicitudes representan destinos en cualquier lugar de la red. Esta realización tiene la ventaja de ser más eficiente, toda vez que se requieren menos casos de máquinas de estados de señalización y clases de gestores. Por ejemplo, el árbol de solicitudes puede ser implementado de modo que tenga, para cada activación de una aplicación, una representación casual de un objeto de nudo que puede tener punteros hacia los nudos anterior y siguiente en el árbol. El siguiente fragmento de pseudocódigo muestra como puede incorporarse la construcción de un árbol de solicitudes a los algoritmos para el procesamiento de la base de reglas y el procesamiento de módulos de reglas. La idea es asociar cada contexto de evento con un nudo del árbol de solicitudes (RequestTreeNode). Este es el nudo en el cual se creó el contexto de evento. Cada nudo está indistintamente asociado con la raíz del árbol o con una ejecución de una acción:

9

10

Considerando el modelo de una disposición lógica en cascada de aplicaciones de servicio, pueden formularse las siguientes reglas generales para el ambiente de ejecución de servicios:

-: Los eventos que se propagan ascendentemente deberán ser reportados primero a las aplicaciones extremas en sentido lógicamente descendente.

-: Los eventos que se propagan descendentemente deberán ser reportados primero a las aplicaciones extremas en sentido lógicamente ascendente.

El orden de disposición lógica en cascada de servicios se mantiene cuando se distribuyen notificaciones de evento para evitar la situación altamente compleja e inmanejable en la que pueden reportarse eventos a servicios en cascada en cualquier orden.

Preferiblemente, las aplicaciones que arman tales eventos son invocadas en los puntos 1 o 4 de procesamiento y sus puntos de subprocesamiento. Preferiblemente, el operador de red puede especificar en la lista de reglas para el punto 4 de procesamiento un punto en el cual deberán reportarse las activaciones armadas dinámicamente. Esto significa que la cadena de disposición lógica en cascada de servicios establecida para la solicitud se mantiene y se activan nuevos servicios indistintamente antes o después de esta cadena. La misma regla puede aplicarse para solicitudes subsiguientes que están relacionadas con una transacción existente. Será este el momento en el que en el punto 1 de procesamiento el administrador puede especificar cuando reportar eventos armados dinámicamente.

Alternativa o adicionalmente, puede utilizarse otro tipo de sistema de armado, al que se hará referencia como activación armada dinámicamente, que se añade en la forma de reglas a un módulo de reglas adecuado en la base de reglas. Las activaciones armadas dinámicamente proporcionan un mecanismo menos costoso en términos de potencia de procesamiento y memoria de ejecución para el reporte de eventos que no pertenecen a la transacción en la cual se activó la aplicación. Preferiblemente, estas solicitudes de reporte de eventos deberán almacenarse en medios de almacenamiento persistentes, es decir se convierten en reglas en la base de reglas. Estas reglas pueden ser no permanentes especificando un plazo de expiración, o pueden ser permanentes. En el último caso, la aplicación de servicio deberá desarmar explícitamente la solicitud de reportes de evento para eliminarla. Alternativamente, pueden armarse también en un modo de "reportar una vez y desarmar a continuación". Adicionalmente, si no se ha especificado ningún tiempo de caducidad, puede aplicarse a la regla un tiempo de vigencia por defecto, por ejemplo una hora. Cuando ha transcurrido este tiempo, la regla es eliminada. Esto tiene la ventaja de evitar que el servidor desborde su capacidad de almacenamiento de datos.

Preferiblemente, se añaden reglas de activación a un módulo de reglas para el cual la aplicación tiene los privilegios y derechos de actualización. Será normalmente el mismo módulo de reglas desde el cual se activó la aplicación. Exactamente el lugar en que deberán añadirse estas reglas en el orden de prioridad dentro de un módulo de reglas, puede ser determinado por un orden de prioridad de reglas implícito, es decir por un número entero que representa donde deberá colocarse la regla dentro del módulo de reglas existente. Cuando se añade primero un programa script en lenguaje SELR, las reglas se ordenan en el orden que aparecen en dicho programa. Si existen N reglas, los números enteros 1 a N se asocian implícitamente con las reglas. Una regla puede ser eliminada haciendo referencia a estos números. Una regla puede ser añadida haciendo referencia a la regla después de la cual deberá situarse la nueva regla. Esto tiene la ventaja de que se reduce la cantidad de datos que es necesario intercambiar cuando se añade una regla a un módulo de reglas de gran capacidad.

Si no se especifica ninguna posición, entonces el motor de módulo de reglas puede seguir el siguiente algoritmo cuando se añaden estas activaciones: buscar el módulo de reglas con el mismo patrón de propiedades válido para la nueva regla. Si se encuentra un patrón, buscar cualquier subpatrón, y así sucesivamente. Si no se encuentra ningún subpatrón, insertar la regla como regla de prioridad más alta en la lista cerrada de acciones. Si no se encuentra ya un patrón similar en el módulo de reglas, insertarlo como primer patrón. Este algoritmo proporciona una situación de la regla ventajosa desde el punto de vista lógico. Por ejemplo, asegura que las acciones para la entidad que llama donde TARGET = FROM no se mezclan con acciones para entidades llamadas en las que TARGET = RequestURI. Significa también que las reglas añadidas al final son las que primero se encuentran cuando se produce un evento. Este es el comportamiento por defecto más simple.

Puede ser posible indicar si una regla de activación es permanente o deberá eliminarse automáticamente una vez que se reporta el evento. El tipo de reglas que puede añadir dinámicamente un programa de aplicación puede estar vinculado a los privilegios y derechos asignados a la aplicación.

En otra realización alternativa, el árbol de solicitudes en cascada se mantiene solamente mientras dura un evento. En este caso, cuando la última aplicación de la cadena ha terminado su procesamiento y el evento SIP ha sido enviado, entonces la cadena en cascada ya no es relevante. Hasta ese punto, puede ser útil que el motor de reglas retenga una representación de la cadena en cascada en memoria. Esto se debe a que las aplicaciones pueden correr en servidores independientes y puede necesitarse algún tiempo para responder a la invocación. Mientras el motor de reglas está esperando una respuesta, una aplicación anterior en la cadena puede cancelar la solicitud. Si ocurre esto, el motor de reglas necesitará informar al motor de ejecución de aplicaciones sobre la aplicación que está esperando. Esto significa que el motor de reglas deberá recordar cual fue la siguiente aplicación de la cadena. En el momento en que el evento SIP ha sido cursado, todas las aplicaciones de la cadena deberán tener preparadas reglas para los eventos de su interés, y de este modo ya no es necesario que el motor de reglas recuerde la cadena en cascada. La ventaja de esta solución es que el propio motor de reglas es simple. Reporta precisamente eventos basados en módulos de reglas en los puntos de procesamiento pertinentes. Sin embargo, esta solución es compleja de administrar y transfiere la complejidad de ordenación de los eventos a las aplicaciones, es decir las aplicaciones necesitan decidir la posición de prioridad en la cual deberá añadirse la regla en un módulo de reglas.

La figura 18 ilustra la estructura de árbol del procesamiento de módulos de reglas de acuerdo con una realización del invento. Cuando se recibe un evento, el procesamiento de la base de reglas despliega un patrón de procesamiento al que se hará referencia como árbol de base de reglas. Cuando llega una solicitud al servidor SIP correspondiente a un contexto 1801 de evento original, los abonados asociados pueden ser la parte de origen (es decir, la entidad que llama) y/o la parte de terminación (es decir, la entidad llamada). La entidad que llama es identificada por el campo de cabecera From. La entidad llamada (o entidad llamada en curso) es identificada por la información Request-URI. El campo de cabecera From y el campo Request-URI deberán identificar singularmente a un abonado en el servidor SIP en el que estos abonados tienen una relación contractual con el operador de red y los proveedores de servicios. A continuación del principio de disposición en cascada, los servicios 1802 de origen son invocados antes que los servicios 1803 de terminación, incluso si las partes de origen y terminación están situadas en el mismo sistema anfitrión. Puede también invocarse una tercera categoría de servicios. Estos se denominan servicios "cursados por" (no representados). Esta categoría de servicios se invoca si es cursada una solicitud a un nuevo destino que pertenece a otro abonado. En este caso, puede ser necesario invocar servicios de origen en representación de la entidad llamada. Para cada parte, los servicios se invocan en base a la posición de los módulos de reglas a medida que se sitúan en los diferentes puntos 1804-1809 de procesamiento. Para cada punto de procesamiento, se examinan los conjuntos de prioridades 1810-1814 de módulo de reglas para encontrar coincidencias. Dentro de cada prioridad, al menos se invoca un módulo 1815-1817 de reglas, respectivamente. Sin embargo, un módulo 1817 de reglas puede ser la raíz de una jerarquía 1818 de módulos de reglas, como se ha descrito en relación con la figura 12. Por simplicidad, tal jerarquía de módulos de reglas podría considerarse como un solo módulo de reglas. Por tanto, la función del procesamiento 1601 de módulo de reglas, las funciones 1700 del módulo de interacción de servicios, y las aplicaciones 1819 de servicio invocadas por los módulos de reglas, pueden considerarse como hojas del árbol de base de reglas. En base al contexto CEC de evento en curso, el módulo 1817 de reglas es invocado y retorna un contexto REC de evento resultante. Este contexto RCE de evento resultante se considera el contexto CEC de evento en curso para el siguiente módulo de reglas que se invoca. Cuando todos los módulos de reglas han sido invocados y el último de ellos ha retornado el contexto de evento resultante, entonces el contexto de evento resultante constituye el conjunto de mensajes de señalización SIP que será enviado ascendente y/o descendentemente, como respuesta al mensaje SIP entrante original.

La anterior estructura de procesamiento, que se ilustra gráficamente en la figura 18, puede ser ilustrada adicionalmente por el siguiente fragmento de pseudocódigo:

11

12

Se observa que una aplicación de servicio puede cambiar el campo de cabecera From o el campo Request-URI. Adicionalmente, el campo de cabecera FROM resultante o el campo Request-URI resultante pueden pertenecer a otro abonado, que puede incluso ser desconocido para el servidor SIP que procesa el evento. Si el campo de cabecera FROM y/o el campo Request-URI resultantes corresponden a un nuevo abonado, pero conocido en el servidor SIP, los servicios asociados con este abonado son también invocados. En este caso, el procedimiento de procesamiento de la base de reglas puede ser invocado recursivamente generándose una estructura jerárquica de árboles de base de reglas.

El procesamiento de un módulo de reglas comprende la operación de realizar cada acción según su orden de prioridad, evaluar si los patrones incorporados coinciden con el contexto de evento en curso y, si es así, aplicar la acción. En lo que sigue, se describirá con mayor detalle un método de acuerdo con una realización del invento.

El siguiente fragmento de pseudocódigo proporciona una descripción de alto nivel de un algoritmo para el procesamiento de un módulo de reglas:

13

En este caso, el método enclosingPatternsTrue retorna una variable booleana que indica si los patrones que incorporan las acciones son ciertos. El método processAction puede ser implementado como se indica en el siguiente segmento de pseudocódigo:

14

Donde EC[] es el conjunto de informaciones cursadas del contexto de evento. Si está vacío, el servicio ha terminado la solicitud o respuesta.

La aplicación de servicio puede emitir adicionalmente instrucciones que no sirven para cursar el contexto de evento. Estas no se muestran en el algoritmo anterior. Tales instrucciones pueden ser procesadas por el gestor de base de reglas.

Cuando se ejecutan acciones según un orden de prioridad, el resultado de la acción puede ser cambiar el contexto de evento en curso. Después de tal acción, continúa el procesamiento del módulo de reglas en curso. Después de ejecutar el módulo de reglas en curso, pueden ejecutarse módulos de reglas adicionales de acuerdo con el procedimiento de procesamiento de la base de reglas. Las acciones de orden de prioridad inferior se ejecutan solamente si el patrón o patrones que las incluyen coincide con las nuevas propiedades de mensaje, como especifica el contexto de evento en curso. Esto se ilustra mediante el siguiente ejemplo de un fragmento de pseudocódigo script que describe dos acciones delimitadas por dos patrones:

15

Las dos acciones están delimitadas por dos patrones que indican que las acciones deberán aplicarse solamente si la solicitud corresponde a una invitación y el campo RequestURI contiene el nombre xcorp.com de dominio. La primera acción invoca un programa script en lenguaje CPL suministrado por un usuario. Si el programa script CPL del usuario no cambia el destino de la solicitud, es invocado el comportamiento proxy estándar para localizar al usuario y procesar por proxy la solicitud. Si el programa script CPL cambia el destino de modo que dicho destino revierte a otro sistema anfitrión, no es necesario invocar el comportamiento proxy estándar.

Si la propiedad de mensaje que activó el módulo de reglas cambia de modo que representa un nuevo usuario, el procesamiento de ese módulo de reglas se interrumpe. La finalidad de esto es que los módulos de reglas pueden considerarse procesados por parte de un solo usuario. Esto simplifica el procesamiento de módulos de reglas y la autoría de programas script.

La figura 19 ilustra el procesamiento recursivo de módulos de reglas en una situación en la que aplicaciones de servicio generan nuevos contextos de evento de acuerdo con una realización del invento. Los nuevos contextos de evento pueden modificar la activación del módulo de reglas original y, en este caso, pueden invocarse recursivamente nuevos módulos de reglas. Por ejemplo, un conjunto de preferencias del abonado llamado, por ejemplo contenidas en un programa script CPL, puede cursar la solicitud a un nuevo destino asociado con otro abonado en el mismo servidor SIP. En este caso, deberán invocarse también las preferencias del abonado llamado al que ha sido cursada la solicitud, por ejemplo mediante otro programa script CPL.

Como ser ilustra mediante el ejemplo de la figura 19, un contexto 1901 de evento inicial genera una secuencia de invocaciones de módulo de reglas cuando es cursado un mensaje de solicitud SIP a varios nuevos destinos asociados con otras cuentas de abonado. En el ejemplo de la figura 19, el programa 1914 de aplicación es activado por un módulo 1903 de reglas por parte del abonado A. El módulo 1903 de reglas es activado por el contexto 1901 de evento original. La aplicación 1914 genera tres contextos 1904-1906 de evento, donde la activación del módulo de reglas ha cambiado en los dos contextos 1905-1906 de evento que están asociados con las nuevas cuentas de abonado. El contexto 1904 de evento es un contexto de evento actualizado pero asociado con el mismo abonado cuyo módulo de reglas invocó inicialmente la aplicación 1914. En este caso, los módulos 1907-1908 de reglas de abonado asociados con los nuevos contextos 1905-1906 de evento, respectivamente, son también invocados. El módulo 1907 de reglas, a su vez, invoca la aplicación 1915 que genera dos nuevos contextos 1909 y 1910 de evento, y así sucesivamente. En consecuencia, se crea una estructura de procesamiento en árbol en la cual las hojas corresponden al conjunto de contextos 1910-1913 de evento resultantes. Subsiguientemente, los contextos 1910-1913 de evento resultantes hacen que el servidor SIP envíe mensajes SIP en sentido ascendente, en sentido descendente, o en ambos sentidos. Es de observar que el ejemplo de la figura 19 muestra un caso sencillo en el que se supone que los módulos de reglas contienen solamente una acción cada uno.

Si las cinco aplicaciones 1914-1918 de la figura 19 han solicitado ser notificadas sobre respuestas subsiguientes a los mensajes SIP resultantes, de acuerdo con el principio de organización en cascada, se notifican respuestas primero a la aplicación extrema en sentido lógicamente descendente. En la figura 19, las respuestas al contexto 1910 de evento resultante son notificadas primero a la aplicación 1918, a continuación a la aplicación 1915, y finalmente a la aplicación 1914, como se indica por la línea 1919. Para el contexto 1911 de evento resultante, la secuencia correspondiente se refiere a la aplicación 1915 y a la aplicación 1914, como se indica por la línea 1920. Para el contexto 1912 de evento resultante, la secuencia se define para la aplicación 1916 y a continuación para la aplicación 1014, como se indica por la línea 1921. Finalmente, para el contexto 1913 de evento resultante, la secuencia corresponde a la aplicación 1917 y a continuación a la aplicación 1914.

La figura 20 ilustra un mecanismo de imposición del control de acceso en relación con módulos de reglas de acuerdo con una realización del invento. Se imponen dos tipos de control de acceso. El acceso a módulos de reglas deberá ser admitido solamente para participantes autentificados y autorizados, y el acceso a características de servicio deberá ser concedido solamente a módulos de reglas autentificados y autorizados. De acuerdo con una realización, este control de acceso puede implementarse utilizando las denominadas listas de control de acceso (ACL). Tales listas pueden ser un documento XML posiblemente embebido en el módulo de reglas o situado en el mismo directorio que el módulo de reglas, o en otro directorio asociado con el mismo. Las listas de control de acceso incluyen reglas de control de acceso. La lista de control de acceso puede enumerar cada uno de los individuos o grupos a los que se concede acceso al módulo de reglas. El mecanismo puede ser utilizado también para especificar explícitamente privilegios y derechos de los módulos de reglas, por ejemplo las características de servicio que puede utilizar el módulo de reglas. Por consiguiente, permite al administrador gestionar privilegios y derechos de módulos de reglas.

Adicionalmente, el mecanismo puede ser utilizado para gestionar privilegios y derechos de aplicaciones de servicio. Si un abonado carga un programa script CPL, puede existir un módulo de reglas asociado que invoca ese servicio en el momento correcto. En este caso, el módulo de reglas deberá tener privilegios y derechos específicos para actuar así. Esto puede ser gestionado asociando listas de control de acceso con el programa script CPL. El mecanismo puede ser utilizado adicionalmente para especificar explícitamente privilegios y derechos de la aplicación de servicio, por ejemplo con características de servicio, sistemas de interfaz API, etc, que puede utilizar la aplicación de servicio. Por tanto, el sistema permite al administrador gestionar privilegios y derechos de aplicaciones de servicio.

Con referencia a los círculos numerados en la figura 20, pueden comprobarse los siguientes privilegios:

1): Es enviado un contexto 2001 de evento original al motor de reglas después de una autentificación correcta de abonados (A es el abonado que llama, B es el abonado llamado). Los módulos de reglas y aplicaciones de servicio son todos autentificados, y se les han dado privilegios y derechos.

2): El procesador 2002 de base de reglas intenta acceder a módulos de reglas en la base 2003 de reglas, que están asociadas con el abonado A o el abonado B autentificados, o con ambos. El procesador 2002 de base de reglas deberá tener prohibido el acceso a módulos de reglas asociados con otros abonados cuando se procesa este evento. La base 2003 de reglas puede estar situada en un servidor remoto, en cuyo caso el motor de reglas deberá autentificarse a sí mismo.

3): Si está permitido de acuerdo con la lista 2005 de control de acceso, el procesador 2002 de base de reglas puede invocar el módulo 2004 de reglas cargado, es decir el módulo 1 de reglas del que es propietario el abonado A.

4): Si se permite de acuerdo con la lista 2006 de control de acceso, el módulo 2004 de reglas puede intentar invocar otro módulo 2007 de reglas asociado con otro propietario B.

5): Si se permite de acuerdo con la lista 2008 de control de acceso, el procesador 2002 de base de reglas puede invocar el módulo 2007 de reglas cargado.

6): Si se permite de acuerdo con las listas 2005 y 2012 de acceso, el módulo 2004 de reglas puede intentar invocar la aplicación 2010 de servicio si está permitido. La aplicación 2010 de servicio puede acceder al contexto 2013 de evento de acuerdo con la lista 2011 de control de acceso.

7): La aplicación 2010 de servicio puede retornar un conjunto 2014 de instrucciones que es devuelto al procesador de módulos de reglas, si se permite de acuerdo con la lista 2015 de control de acceso.

8): La aplicación 2010 de servicio puede armar/desarmar eventos, si se permite de acuerdo con la lista 2015 de control de acceso.

9): La aplicación 2010 de servicio puede intentar dar instrucciones a un módulo 2007 de reglas diferente del que invocó, si se permite de acuerdo con la lista 2012 de control de acceso.

El control de acceso a módulos de reglas puede ser forzado por nudos de política en un módulo de reglas. Un ejemplo de una lista de control de acceso de módulos de reglas embebida en un módulo de reglas puede corresponder a un fragmento de pseudocódigo como el siguiente:

16

17

Estos criterios podrían aplicarse a todo el módulo de reglas, en cuyo caso establecen que, por ejemplo, la abonada Alicia puede invocar este módulo de reglas, pero no puede leer ni escribir en el mismo.

Tales programas script XML pueden estar embebidos en módulos de reglas, pero pueden ser también elementos de datos asociados. Por ejemplo, el operador de red puede vincular un programa script XML de política al módulo de reglas de un abonado, especificando los privilegios concedidos por el operador de red al propietario del módulo de reglas. Estos privilegios podrían especificar los servicios o características de servicio que se le permite invocar al módulo de reglas, como se ilustra mediante el siguiente ejemplo de tal lista de control de acceso a servicios:

18

19

Es de observar que un ambiente de soporte de servicios de servidor SIP puede estar preparado adicionalmente para generar registros contables, por ejemplo para cargar contenidos, cargar aplicaciones, cargar usos, etc. Por ejemplo, los registros pueden ser proporcionados a través de entradas en línea de programas script SERL o programas script CPL, gestionados a través de funciones de librería o una aplicación de servicio, etc.

Adicionalmente, un sistema que implementa procedimientos de activación de servicios de acuerdo con el invento, preferiblemente implementa medidas de seguridad con el fin de preservar la seguridad e integridad del nodo SIP, incluso aunque se les permita a abonados y proveedores de servicios de tercera entidad cargar en la red no solamente aplicaciones de servicio, sino también instrucciones sobre como y cuando invocarles, incluyendo algún grado de resolución de interacciones entre características. Entre las posibles medidas de seguridad, se incluyen la configuración de privilegios y derechos de módulos de reglas, aplicaciones de servicio, políticas de convenio de espacio de nombres, mecanismos de autentificación, protección de acceso, autentificación y validación de módulos de reglas cargados en red, identificación por contraseña y vigilancia, etc.

Es de observar que el invento ha sido descrito fundamentalmente en relación con servicios de red. Sin embargo, es aplicable también para ser utilizado en equipos de usuario final.

Adicionalmente, es de observar que el invento, aunque se ha descrito principalmente en relación con el protocolo SIP, puede abarcar también otros protocolos de transmisión de señales. El lenguaje SERL no está limitado a invocar servicios basados en eventos SIP, sino que puede invocar cualquier tipo de aplicación de servicio basada en cualquier tipo de evento, en el contexto de cualquier tipo de modelo comercial. El invento puede aplicarse para gestionar servicios para cualquier nodo habilitado para protocolo SIP. Utilizando programas script en lenguaje SERL, pueden invocarse servicios de nodos que implementan agentes de usuario, entidades de registro, servidores de redirección o servidores proxy.

Finalmente, es de observar que en la arquitectura 3GPP todos los datos de abonado son administrados en el denominado servidor de abonado doméstico (HSS). Las aplicaciones relacionadas con el protocolo SIP son invocadas desde un nodo denominado función de control de estado de llamadas de servicio (S-CSCF). Cuando un abonado se conecta a una red, su equipo de usuario (UE) realiza un descubrimiento de función de control de estado de llamadas para seleccionar un nodo S-CSCF adecuado. El nodo S-CSCF coincide con el servidor HSS que está dando servicio al abonado en cuestión. Las activaciones de servicio podrían ser transportadas desde el servidor HSS hasta el nodo S-CSCF en la forma de reglas de ejecución de servicio en el formato SERL. El servidor HSS podría también utilizar las reglas de ejecución de servicio asociadas con un abonado para decidir la asignación de un nodo S-CSCF diferente, cuyo nodo tiene instalados los servicios correctos. Por tanto, puede utilizarse una realización del invento para que el servidor HSS sitúe las actuaciones en base a abonados en el punto de procesamiento correcto y con la prioridad correcta, y de este modo en el orden de prioridad correcto con servicios permanentes instalados en el nodo S-CSCF. Por tanto, un mecanismo de acuerdo con el invento puede estar embebido en el dominio 3GPP IPMM.

Claims

1. Un método de gestión de una pluralidad de servicios (309, 310, 311; 1305; 1611, 1612, 1613) activados por un mensaje (1306; 1609) de un protocolo de sesión que controla una sesión de comunicaciones, cuyo método comprende las operaciones de: obtener un número de módulos de reglas, cada uno de los cuales comprende un número de reglas (308; 401, 402; 1606, 1607, 1608) de ejecución, cada una de las cuales especifica una condición (403, 404, 405) para invocar un servicio; procesar un primer módulo (1216) de dicho número de módulos de reglas, comprendiendo dicho procesamiento el procesamiento de al menos una parte de las reglas de ejecución del primer módulo de reglas en un orden predeterminado, haciendo una primera regla (1606) de ejecución que sea invocado un primer servicio (1611), si el mensaje cumple una primera condición, obteniéndose como resultado un primer mensaje modificado (1615), y haciendo una segunda regla (1607) de ejecución que sea invocado un segundo servicio (1612) con el primer mensaje modificado como entrada, si el primer mensaje modificado cumple una segunda condición; dando lugar dicho procesamiento del primer módulo de reglas a un primer mensaje (1206) modificado acumulativamente; e invocar un segundo módulo (1217) de reglas de dicho número de módulos de reglas suministrando el primer mensaje modificado acumulativamente como entrada; caracterizado porque el primer módulo de reglas tiene asignado un privilegio indicativo de una autoridad para alterar una marca indicadora de bloqueo relacionada con una parte predeterminada del mensaje modificado acumulativamente, especificando dicha marca de bloqueo si dicha parte predeterminada del mensaje modificado acumulativamente puede ser modificada por servicios invocados desde al menos el segundo módulo de reglas.

2. Un método de acuerdo con la reivindicación 1ª, caracterizado porque cada módulo de reglas tiene asociada una prioridad indicativa de un orden de procesamiento de dicho número de módulos de reglas.

3. Un método de acuerdo con cualquiera de las reivindicaciones 1ª o 2ª, caracterizado porque cada módulo de reglas corresponde a un primer propietario (409) de módulo de reglas autorizado para editar el módulo de reglas.

4. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 3ª, caracterizado porque la operación de invocar el procesamiento del segundo módulo de reglas comprende adicionalmente la operación de activar dicha marca indicadora de bloqueo para evitar la modificación de la parte predeterminada del mensaje modificado acumulativamente por servicios invocados desde el segundo módulo de reglas, a no ser que la marca indicadora de bloqueo no haya sido activada por el primer módulo de reglas.

5. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 4ª, caracterizado porque la operación de obtener un número de reglas de ejecución comprende adicionalmente la operación de detectar una relación contractual predeterminada en base a información de cabecera del mensaje, y seleccionar un número de módulos de reglas en base a dicha relación contractual detectada.

6. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 5ª, caracterizado porque la operación de procesar el primer módulo (1216) de reglas comprende adicionalmente la operación de invocar un tercer módulo (1220) de reglas predeterminado.

7. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 6ª, caracterizado porque el primer y segundo módulos de reglas están relacionados con una primera y una segunda listas (411) de control de acceso respectivas que especifican derechos de acceso al primer y segundo módulos de reglas correspondientes.

8. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 7ª, caracterizado porque el primer y segundo módulos de reglas comprenden un primer y un segundo programas script respectivos en un lenguaje de marcación predeterminado.

9. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 8ª, caracterizado porque el mensaje comprende un primer y un segundo conjuntos de atributos; las reglas de ejecución están agrupadas en al menos una primera y una segunda clases (903, 904) de procesamiento de reglas de ejecución de acuerdo con restricciones correspondientes, donde la segunda clase de procesamiento está limitada solamente a modificar atributos del segundo conjunto de atributos; y el método comprende adicionalmente la operación de repetir las operaciones de procesamiento del primer módulo (901) de reglas e invocar el procesamiento del segundo módulo (902) de reglas, donde en cada repetición el procesamiento del primer y segundo módulos de reglas está limitado a reglas de ejecución de una clase de procesamiento correspondiente, y en el que cada repetición da lugar a un mensaje modificado acumulativamente correspondiente que es utilizado como entrada para una repetición subsiguiente.

10. Un método de acuerdo con la reivindicación 9ª, caracterizado porque las clases de procesamiento están definidas independientemente para reglas de ejecución activadas por solicitudes (607) y respuestas (608) del protocolo de sesión.

11. Un método de acuerdo con cualquiera de las reivindicaciones 9ª o 10ª, caracterizado porque el primer conjunto de atributos comprende propiedades de señalización del mensaje.

12. Un método de acuerdo con cualquiera de las reivindicaciones 9ª a 11ª, caracterizado porque las clases de procesamiento corresponden a posiciones predeterminadas en un flujo de mensajes de recorrido circular de acuerdo con el protocolo de sesión.

13. Un método de acuerdo con cualquiera de las reivindicaciones 9ª a 12ª, caracterizado porque las clases de procesamiento incluyen una primera clase de procesamiento (P1) de reglas de ejecución que inciden en propiedades (702) de señalización del mensaje, una segunda clase de procesamiento (P2) de reglas de ejecución que inciden en el contenido (704) del cuerpo de mensaje que no contiene información de señalización, y una tercera clase de procesamiento (P3) de reglas de ejecución que no inciden en las propiedades de señalización ni en el contenido de cuerpo de mensaje que no contiene información de señalización.

14. Un método de acuerdo con la reivindicación 13ª, caracterizado porque es generado un mensaje modificado resultante (703) cuando se han procesado todas las reglas de ejecución de la primera y segunda clases de procesamiento.

15. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 14ª, caracterizado porque la invocación del primer servicio da lugar adicionalmente a un segundo mensaje modificado; y el método comprende adicionalmente las operaciones de procesar reglas de ejecución subsiguientes con el primer mensaje modificado como entrada, y procesar reglas de ejecución subsiguientes con el segundo mensaje modificado como entrada.

16. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 15ª, caracterizado porque comprende adicionalmente las operaciones de: almacenar información relativa a los servicios que son ejecutados e información relativa al orden en que son ejecutados los servicios; recibir del primer servicio una solicitud para retornar una notificación al primer servicio si se produce un evento predeterminado; almacenar la solicitud en relación con la información almacenada; y, al producirse el evento, notificar este hecho al primer servicio de acuerdo con la información almacenada.

17. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 16ª, caracterizado porque los módulos de ejecución comprenden programas script legibles por computador, y el orden predeterminado de procesamiento de las reglas de ejecución está determinado por el orden de reglas de ejecución en dichos programas script.

18. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 17ª, caracterizado porque la sesión está relacionada con un número de abonados que incluye un abonado que llama y un abonado llamado; porque un servicio está destinado a ser activado por una solicitud procedente de un abonado; y porque el método comprende adicionalmente la operación de invocar servicios solicitados por el abonado que llama antes de invocar cualquier servicio solicitado por el abonado llamado.

19. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 18ª, caracterizado porque el protocolo de sesión es un protocolo de iniciación de sesión.

20. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 19ª, caracterizado porque la sesión de comunicaciones es una sesión multimedia.

21. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 20ª, caracterizado porque las reglas de ejecución están adaptadas para ser actualizadas dinámicamente.

22. Un sistema de procesamiento de datos que comprende un módulo (201; 301) de ambiente de ejecución de servicios preparado para invocar una pluralidad de servicios (309, 310, 311) activados por un mensaje de un protocolo de sesión que controla una sesión de comunicaciones; cuyo sistema de procesamiento de datos comprende adicionalmente un medio (307) de almacenamiento destinado a almacenar una pluralidad de módulos de reglas, cada uno de los cuales comprende un número de reglas de ejecución, especificando cada regla de ejecución una condición para invocar un servicio; y en el que el módulo de ambiente de ejecución de servicios comprende un módulo (303) de motor de reglas destinado a: recuperar un número de módulos de reglas; procesar un primer módulo de reglas de dicho número de módulos de reglas, comprendiendo dicho procesamiento el procesamiento de al menos una parte de las reglas de ejecución del primer módulo de reglas en un orden predeterminado, haciendo una primera regla de ejecución que sea invocado un primer servicio, si el mensaje cumple una primera condición, obteniéndose como resultado un primer mensaje modificado, y haciendo una segunda regla de ejecución que sea invocado un segundo servicio con el primer mensaje modificado como entrada, si el primer mensaje modificado cumple una segunda condición, dando lugar dicho procesamiento del primer módulo de reglas a un primer mensaje modificado acumulativamente; e invocar un segundo módulo (1217) de reglas de dicho número de módulos de reglas suministrando el primer mensaje modificado acumulativamente como entrada; caracterizado porque el primer módulo de reglas tiene asignado un privilegio indicativo de una autoridad para alterar una marca indicadora de bloqueo relacionada con una parte predeterminada del mensaje modificado acumulativamente, especificando dicha marca de bloqueo si dicha parte predeterminada del mensaje modificado acumulativamente puede ser modificada por servicios invocados desde al menos el segundo módulo de reglas.

23. Un sistema de procesamiento de datos de acuerdo con la reivindicación 22ª, caracterizado porque el módulo de motor de reglas está destinado a interpretar un lenguaje de especificación de ejecución de reglas predeterminado.

24. Un sistema de procesamiento de datos de acuerdo con cualquiera de las reivindicaciones 22ª o 23ª, caracterizado porque el módulo de motor de reglas comprende adicionalmente un módulo (1601) de procesador de base de reglas destinado a recuperar las reglas de ejecución; y un módulo (314; 1604, 1605) de procesamiento de módulo de reglas destinado a procesar las reglas de ejecución.

25. Un programa que comprende medios de código destinados a realizar, cuando el programa se ejecuta en un sistema de procesamiento de datos, las operaciones del método de acuerdo con cualquiera de las reivindicaciones 1ª a 21ª.

26. Un programa de acuerdo con la reivindicación 25ª, caracterizado porque está realizado en un medio legible por computador.

27. Un registro de datos que comprende un módulo de reglas para ser utilizado en un método de acuerdo con cualquiera de las reivindicaciones 1ª a 21ª.