MÉTODOS Y APARATOS PARA PROCESAR PETICIONES SIP EN UNA RED IMS COMPRENDIENDO UN AS.

Métodos y aparatos para procesar peticiones SIP en una red IMS comprendiendo un AS CAMPO DE LA TECNOLOGÍA La presente invención se refiere a una red de Subsistema de IP Multimedia (IMS) en el campo de la comunicación y más en particular, a un método y equipo para procesar Peticiones de Protocolo de Iniciación de Sesión (SIP) en una red IMS cuando un Servidor de Aplicación (AS) se utiliza como un Agente de Usuario back-to-back (B2BUA). ANTECEDENTES DE LA INVENCIÓN En una red IMS, las entidades de Función de Control de Sesión de LlamadaServidor (S-CSCF) no suelen ejecutar un servicio específico y la lógica de servicio está situada en el servidor AS. A la recepción de una petición SIP, la S-CSCF busca el perfil de usuario (UP) descargado durante el registro del usuario para la correspondencia del criterio de filtro inicial (iFC) con la petición SIP y reenvía la petición SIP al servidor AS pertinente sobre la base de la regla de iFC. El servidor AS puede desempeñar diferentes funciones para los diálogos de IMS. Si el servidor AS sirve como el originador del diálogo, según se representa en la Figura 1A, el servidor AS origina un diálogo y envía este diálogo a la S-CSCF y la S-CSCF no cambiará la información pertinente de este diálogo. Si el servidor AS sirve como el B2BUA, según se representa en la Figura 1B, el servidor AS recibe la petición SIP enviada por la S-CSCF, finaliza ese diálogo e inicia un nuevo diálogo y la asociación entre los dos diálogos se realiza por el servidor AS, pero a partir del aspecto de S-CSCF, puesto que los dos diálogos son diferentes, la información pertinente, tal como un identificador de llamada Call-ID y desde/a la etiqueta, de un diálogo es diferente de la del otro. En el modo en que el servidor AS sirve como el B2BUA, sin embargo, la S-CSCF suele necesitar conocer la asociación entre los dos diálogos, puesto que el usuario puede esperar todavía adoptar la iFC del diálogo original para el nuevo diálogo. Debido a que los dos diálogos son diferentes, dichos dos diálogos deben asociarse utilizando otros identificadores en las peticiones SIP, tal como Orig-DIALOG ID en la cabecera de Ruta en lugar de utilizar directamente los identificadores de diálogo SIP tales como Call-ID, identificador de llamada. Varias cabeceras de la petición SIP, estrechamente relacionadas con la presente invención, se describirán brevemente a continuación: Cabecera de Ruta: indica la siguiente entidad de encaminamiento, es decir, el siguiente salto operativo de la petición SIP y puede comprender el identificador Orig-DIALOG ID que se utiliza para prestar asistencia a la función S-CSCF en el aprendizaje de la correspondiente relación entre el nuevo diálogo y el diálogo original; Cabecera de P-Asserted-Identity: un identificador de usuario insertado por una entidad de red y que identifica el usuario que origina la petición; Cabecera Request-URI: indica el destino final de la petición. Cuando el servidor AS actúa como el agente B2BUA, el AS decide si el diálogo nuevo y original necesita asociarse basándose en la lógica de servicio específica. Además, el servidor AS puede modificar también la cabecera de Request- URI o la cabecera P-Asserted-Identity incluida en la petición SIP sobre la base de la lógica de servicio específica. Según la especificación del protocolo existente, cuando la función S-CSCF está enviando una petición SIP al AS, la función S-CSCF debe insertar el Identificador Uniforme de Recursos (URI) de la función S-CSCF que contiene un identificador Orig-DIALOG ID en la cabecera de Ruta, detrás del identificador AS URI. De este modo, al recibir la petición SIP, el servidor AS suprime la parte más elevada de la cabecera de Ruta, es decir, AS URI y por lo tanto, S-CSCF URI es la parte más elevada de la cabecera de Ruta. El servidor AS transmite la petición SIP basada en la información de cabecera de Ruta, de modo que la petición SIP será transmitida a la S-CSCF. Al recibir la petición SIP, la función S­ CSCF decide si se inicia, o no, la petición SIP por el servidor AS o se ha procesado por la S-CSCF antes de transmitirse juzgando si la cabecera de Ruta incluye, o no, un identificador Orig-DIALOG ID y si se determina que la petición SIP es procesada por la S-CSCF antes de la transmisión, la S-CSCF determina el diálogo original al que se asocia el diálogo actual en función del identificador Orig-DIALOG ID transmitido en la cabecera de Ruta de la petición SIP y realiza, además, el proceso de iFC incompleto para el diálogo actual. El proceso específico de asociar el nuevo diálogo y el diálogo original se puede describir, con más detalle, describiendo las operaciones de la S-CSCF y las del servidor AS, respectivamente. Operaciones de la S-CSCF: ES 2 365 743 T3 1. Al recibir una petición SIP, si la función S-CSCF encuentra que esta petición comprende un identificador Orig-DIALOG ID, la S-CSCF determina que esta petición ha sido procesada por la S-CSCF con anterioridad. En función del identificador Orig-DIALOG ID, la S-CSCF encuentra el diálogo original y, cuando se confirma que el identificador de 2 usuario relacionado no está modificado, es decir, en la lado llamante no se ha modificado la P-Asserted-Identity o en el lado llamado, no se ha modificado la Request-URI y continúa la ejecución del proceso iFC incompleto. 2. Al recibir la petición SIP, si la S-CSCF encuentra que esta petición no incluye ningún identificador Orig-DIALOG ID, la S-CSCF determina que esta petición corresponde a un nuevo diálogo originado por el servidor AS. La S-CSCF decide cómo procesar la petición según la iFC que corresponde a esta petición. Si la S-CSCF necesita reenviar esta petición al servidor AS, la S-CSCF rellena el AS URI y la S-CSCF URI en la cabecera de Ruta en secuencia y la S-CSCF URI incluye un identificador ORIG-DIALOG ID. Un ejemplo es como sigue: ROUTE; ;. En donde, el identificador Orig-DIALOG ID se puede indicar también por otra identificación tal como un puerto específico. Operaciones del servidor AS: 1. Al recibir la petición SIP y ejecutar las operaciones pertinentes, el servidor AS determina su propia función a desempeñar durante este diálogo según la lógica de servicio y determina cómo generar nuevas peticiones SIP. Si el servidor AS actúa como el B2BUA, el servidor AS debe suprimir su propia AS URI desde la cabecera de Ruta de la petición SIP original, copiar el resto de la cabecera de Ruta en la nueva petición como la cabecera de Ruta de la nueva petición y encaminar esta nueva petición según la cabecera de Ruta. Por lo tanto, una URI en la nueva petición, que corresponde a la S-CSCF, e incluye el identificador Orig-DIALOG ID, se insertará en la parte superior de la cabecera de Ruta. Por lo tanto, la AS URI se suprime de la cabecera de Ruta en la nueva petición por el servidor AS, de modo que la S­ CSCF recibirá una petición que incluye la cabecera de Ruta siguiente: Ruta;. De este modo, al recibir la petición SIP reenviada desde el servidor AS, la S-CSCF puede determinar el diálogo original al que se asocia la petición SIP recibida en función del identificador Orig-DIALOG ID y puede ejecutar el proceso de iFC subsiguiente después de confirmar que no está modificado el identificador de usuario pertinente. En resumen, cuando el servidor AS actúa como el agente B2BUA, con el fin de garantizar que la detección de iFC incompleta hacia el diálogo original se realiza sobre el nuevo diálogo asociado con el antiguo diálogo en la S-CSCF, cuando se inicia el nuevo diálogo, el servidor AS copiará directamente parte de la cabecera de Ruta del diálogo original como la cabecera de Ruta del nuevo diálogo en lugar de regenerar una nueva cabecera de Ruta para el nuevo diálogo. Dicho proceso plantea los problemas siguientes: si el servidor AS espera que la S-CSCF ejecute un nuevo proceso de iFC, el servidor AS debe regenerar una nueva cabecera de Ruta para el nuevo diálogo en lugar de copiar parte de la cabecera de Ruta del diálogo original como la cabecera de Ruta del nuevo diálogo. Según la técnica anterior, el servidor AS sólo puede copiar la cabecera de Ruta del diálogo original como la cabecera del nuevo diálogo, dando lugar a la incapacidad por S-CSCF de realizar el proceso de detección según el nuevo iFC y por lo tanto, no se puede procesar correctamente el proceso de lógica de servicio. La norma 3GPP TS 23.218 V.6.3.0 Versión 6 especifica el modelo de llamada de IP Multimedia (IM) para gestionar el origen y terminación de una sesión IP multimedia para un abonado de IP multimedia. El documento comprende interacciones entre un servidor de aplicación y sesiones de IP multimedia. La solicitud de patente internacional WO 2005/055549 A1 da a conocer un sistema para desarrollar al menos un servicio en respuesta a un... [Seguir leyendo]

1. Un método para procesar peticiones de Protocolo de Iniciación de Sesión, SIP, en una red de subsistema IP multimedia, IMS, caracterizado porque comprende: la recepción, por un servidor de aplicación AS, en la red IMS, de una primera petición SIP reenviada por una Función de Control de Sesión de Llamada- Servidor, S-CSCF (100) y la generación de una segunda petición SIP en función de la primera petición SIP (110), en donde el servidor AS actúa como un Agente de Usuario Back-to-Back B2BUA; la determinación, por el servidor AS, de si es necesario, o no, asociar la segunda petición SIP con la primera petición SIP al nivel de la función S-CSCF, si es necesario asociar la dos peticiones, la supresión de un identificador uniforme de recursos URI del servidor AS desde una cabecera de Ruta de la primera petición SIP y la utilización del resto de la cabecera de Ruta de la primera petición SIP como una cabecera de Ruta de la segunda petición SIP (120); si no es así, la construcción, por el servidor AS, de la cabecera de Ruta de la segunda petición SIP como en un modo de comportamiento de Agente de Usuario UA en origen (130). 2. El método, según la reivindicación 1, en donde la etapa que consiste en determinar por el servidor AS si es necesario, o no, asociar la segunda petición SIP con la primera petición SIP al nivel de la función S-CSCF, comprende: la determinación por el servidor AS de asociar, o no, la segunda petición SIP con la primera petición SIP, al nivel de la función S-CSCF, en función de una lógica de servicio seleccionada. 3. El método, según la reivindicación 1, en donde la etapa que consiste en determinar, por el servidor AS, si es necesario, o no, asociar la primera petición SIP con la segunda petición SIP, al nivel de la función S-CSCF comprende: la determinación, por el servidor AS, de asociar, o no, la segunda petición SIP con la primera petición SIP, al nivel de la función S-CSCF, en función de un resultado de ejecución de una lógica de servicio seleccionada. 4. El método, según la reivindicación 3, en donde la etapa que consiste en determinar si asociar, o no, la primera petición SIP con la segunda petición SIP en función del resultado de ejecución de la lógica de servicio seleccionada, comprende: la determinación de asociar, o no, la primera petición SIP con la segunda petición SIP comparando la información relacionada con el usuario, que se genera por la lógica de servicio para la segunda petición SIP, y la información relacionada con el usuario de la primera petición SIP. 5. El método, según la reivindicación 4, en donde la etapa que consiste en determinar si asociar, o no, la primera petición SIP con la segunda petición SIP comparando la información relacionada con el usuario, que se genera por la lógica de servicio para la segunda petición SIP, y la información relacionada con el usuario de la primera petición SIP comprende: la determinación de si la información relacionada con el usuario de la primera petición SIP es la misma, o no, que la de la segunda petición SIP y si la respuesta es afirmativa, la determinación de si asociar, o no, las dos peticiones; y de no ser así, la determinación de no asociar las dos peticiones. 6. El método, según la reivindicación 5, que comprende además: si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP son diferentes, la determinación, por el servidor AS, de si la información relacionada con el usuario de la primera petición SIP o la información relacionada con el usuario de la segunda petición SIP comprende un carácter de sustitución; si la información relacionada con el usuario de la primera petición SIP ni la información relacionada con el usuario de la segunda petición SIP comprende el carácter de sustitución, la determinación de no asociar las dos peticiones; si la información relacionada con el usuario de la primera petición SIP o la información relacionada con el usuario de la segunda petición SIP comprende un carácter de sustitución, la determinación de si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP corresponden, o no, entre sí en función de una regla de correspondencia de carácter de sustitución predefinida, si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP se corresponden entre sí en función de la regla de correspondencia de carácter de sustitución predefinida, la determinación de asociar las dos peticiones y de no ser así, determinar la no asociación de las dos peticiones. 7. El método, según la reivindicación 4, en donde si el servidor AS se encuentra en un lado llamante, la información relacionada con el usuario comprende un campo P-Asserted-Identity; si el servidor AS está en un lado llamado, la información relacionada con el usuario comprende la cabecera RequestURI y/o la P-Asserted-Identity; 14 ES 2 365 743 T3 8. El método, según cualquiera de las reivindicaciones 1 a 7, que comprende además: a la recepción de la segunda petición SIP (400), la determinación, por la función S-CSCF, de si la segunda petición SIP contiene, o no, un identificador de diálogo asociado (410), y si la segunda petición SIP no contiene el identificador de diálogo asociado, el procesamiento por la función S-CSCF de la segunda petición SIP en un modo de procesamiento de un nuevo diálogo (480); si la segunda petición SIP contiene el identificador de diálogo asociado, la búsqueda, por la función S-CSCF, de la primera petición SIP que está asociada con la segunda petición SIP, en función del identificador de diálogo asociado (420) y la realización de un procesamiento subsiguiente sobre la segunda petición SIP en función del hecho de que la primera petición SIP y la segunda petición SIP están asociadas en función de la lógica de servicio. 9. El método, según la reivindicación 8, en donde la realización, por la función S-CSCF, de un procesamiento subsiguiente si la primera petición SIP y la segunda petición SIP están asociadas en función de la lógica de servicio comprende: la realización por la función S-CSCF de un procesamiento iFC subsiguiente sobre la segunda petición SIP (460). 10. El método, según la reivindicación 8, que comprende además: después de encontrar la primera petición SIP asociada con la segunda petición SIP en función del identificador de diálogo asociado (420), la comparación, por la función S-CSCF, si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP (430) son las mismas, si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP son diferentes, la determinación, por la función S-CSCF, de si la información relacionada con el usuario de la primera petición SIP o la información relacionada con el usuario de la segunda petición SIP comprende, o no, un carácter de sustitución (440), si la información relacionada con el usuario de la primera petición SIP ni la información relacionada con el usuario de la segunda petición SIP comprende el carácter de sustitución, la determinación de que la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP no están en correspondencia y el procesamiento, por la función S-CSCF, de la segunda petición SIP como el procesamiento de un nuevo diálogo (470); si la información relacionada con el usuario de la primera petición SIP o la información relacionada con el usuario de la segunda petición SIP comprende un carácter de sustitución, la determinación de si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP están en correspondencia, o no, en función de una regla de correspondencia de carácter de sustitución (450), si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP se corresponden entre sí en función de la regla de correspondencia de carácter de sustitución, la realización de un procesamiento subsiguiente en función del hecho de que la primera petición SIP y la segunda petición SIP están asociadas en función de la lógica de servicio (460); si no es así, la realización del procesamiento subsiguiente en función del hecho de que la primera petición SIP y la segunda petición SIP no están asociadas en función de la lógica de servicio (470). 11. El método, según la realización 8, en donde si la función S-CSCF está en un lado llamante, la información relacionada con el usuario comprende un campo P-Asserted-Identity y si la función S-CSCF está en un lado llamado, la información relacionada con el usuario comprende una cabecera Request-URI y/o una P-Asserted-Identity. 12. Un servidor de aplicación AS destinado a procesar las peticiones SIP en una red de Subsistema IP Multimedia, IMS, en donde el servidor AS está adaptado para actuar como Agente de Usuario back-to-back B2BUA, caracterizado porque comprende: una primera unidad de procesamiento de lógica de servicio (600), adaptada para procesar una primera petición SIP reenviada por una entidad de función de Control de Sesión de Llamada-Servidor, S-CSCF; una segunda unidad de procesamiento de lógica de servicio (601), adaptada para generar una segunda petición SIP, la determinación de si es necesario, o no, asociar la primera petición SIP y la segunda petición SIP en función de la lógica de servicio; la supresión de un Identificador Uniforme de Recursos, URI, del servidor AS desde una cabecera de Ruta de la primera petición SIP y utilizar el resto de la cabecera de Ruta de la primera petición SIP como la cabecera de Ruta de la segunda petición SIP, si se determina asociar la primera petición SIP con la segunda petición SIP o construir la cabecera de Ruta de la segunda petición SIP como en un modo de comportamiento de agente de usuario UA en origen si se determina no asociar la primera petición SIP con la segunda petición SIP. 13. El servidor AS, según la reivindicación 12, en donde la segunda unidad de procesamiento de lógica de servicio comprende: ES 2 365 743 T3 un primer módulo (6010), para decidir si la información relacionada con el usuario de la primera petición SIP y la de la segunda petición SIP son las mismas o decidir si es necesario, o no, asociar la primera petición SIP con la segunda petición SIP en la entidad S-CSCF en función de una lógica de servicio seleccionada y proporcionar a la salida la decisión para un segundo módulo (6011); el segundo módulo (6011), para generar la cabecera de Ruta de la segunda petición SIP en función de la decisión. 14. El servidor AS, según la reivindicación 13, en donde la segunda unidad de procesamiento de lógica de servicio comprende además: un tercer módulo (6012), para decidir si la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP están en correspondencia entre sí cuando la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP son diferentes y la información relacionada con el usuario de al menos una de las dos peticiones 15 comprende un carácter de sustitución, si la información relacionada con el usuario de al menos una de la primera petición SIP y de la segunda petición SIP comprende el carácter de sustitución y la información relacionada con el usuario de la primera petición SIP y la información relacionada con el usuario de la segunda petición SIP se corresponden entre sí en función de una regla de correspondencia de carácter de sustitución, la determinación de si es necesario, o no, asociar la primera petición SIP con la segunda petición SIP y proporcionar a la salida la decisión para el segundo módulo (6011).. 16 Desde: X A: Y Call-ID: Z Diálogo 1 Figura 1A Desde: X A: Y Call-ID: Z Diálogo 1 Desde: X A: Y Call-ID: Z Diálogo 1 Diálogo 2 Desde: P A: Q Call-ID: R Diálogo 1 Diálogo 2 Desde: X A: Y Call-ID: Z ES 2 365 743 T3 Figura 1B 17 Desde: P A: Q Call-ID: R Regeneración de la cabecera Ruta de la segunda petición SIP en un modo comportamiento UA en iniciación La primera petición SIP y la segunda petición SIP no necesitan asociarse ES 2 365 743 T3 Recepción de la primera petición SIP Generación segunda petición SIP y decidir si se asocian las dos peticiones S Eliminación de AS URI desde cabecera Ruta y tomar la parte restante de la cabecera Ruta como la cabecera Ruta de la segunda petición Enviar la segunda petición SIP a la S-CSCF Figura 2 Obtener la P-Asserted-Identity de la primera petición SIP y de la segunda petición SIP Son idénticas la P-Asserted- Identity de la primera y segunda petición SIP? Incluye la P-Asserted-Identity un carácter de sustitución? S Están en correspondencia las P-Asserted-Identity de la primera y segunda petición SIP? S La primera petición SIP y la segunda petición SIP necesitan asociarse Figura 3A 18 S La primera petición SIP y la segunda petición SIP no necesitan asociarse Realizar proceso subsiguiente en un modo de procesamiento de un nuevo diálogo No realizar detección iFC subsiguiente ni procesar ES 2 365 743 T3 Obtención de la cabecera Request-URI de la primera petición SIP y de la segunda petición SIP Son idénticas las Request- URI de la primera y de la segunda petición SIP? S Incluye la Request-URI un carácter de sustitución? S Están en correspondencia las Request-URI de la primera y segunda petición SIP? S La primera petición SIP y la segunda petición SIP necesitan asociarse Figura 3B La entidad S-CSCF recibe la segunda petición SIP Incluye la cabecera Ruta un ORIG-DIALOG ID? S Encontrar si la primera petición SIP está en correspondencia con la segunda petición SIP en función del ORIG-DIALOG ID Son idénticas las Asserted- Identity de la primera y segunda petición SIP? Incluye la P-Asserted-Identity un carácter de sustitución? S Están en correspondencia las Asserted-Identity de la primera y segunda petición SIP? S Realizar detección de iFC subsiguiente y procesar la segunda petición SIP Figura 4 19 S Las dos identidades URI no están en correspondencia Primera unidad procesamiento lógica servicio ES 2 365 743 T3 Figura 5 Figura 6 Inicio Son idénticas las dos identidades URI? Incluye la URI un carácter de sustitución? S Están en correspondencia las dos URI en función de la regla de correspondencia de carácter de sustitución? S Las dos identidades URI están en correspondencia Segunda unidad procesamiento lógica servicio Primer módulo Tercer módulo Segundo módulo S Primera unidad procesamiento lógica servicio ES 2 365 743 T3 Primera unidad de procesamiento Segunda unidad de procesamiento Cuarta unidad de procesamiento Tercera unidad de procesamiento Segunda unidad procesamiento lógica servicio Primer módulo Tercer módulo Segundo módulo Figura 7 Figura 8 21 Primera unidad de procesamiento Segunda unidad de procesamiento Cuarta unidad de procesamiento Tercera unidad de procesamiento