ES2365743T3 - Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as. - Google Patents

Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as. Download PDF

Info

Publication number
ES2365743T3
ES2365743T3 ES06254341T ES06254341T ES2365743T3 ES 2365743 T3 ES2365743 T3 ES 2365743T3 ES 06254341 T ES06254341 T ES 06254341T ES 06254341 T ES06254341 T ES 06254341T ES 2365743 T3 ES2365743 T3 ES 2365743T3
Authority
ES
Spain
Prior art keywords
sip request
user
sip
request
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES06254341T
Other languages
English (en)
Inventor
Yajuan Wu
Fenqin Zhu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2365743T3 publication Critical patent/ES2365743T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Telephonic Communication Services (AREA)

Abstract

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).

Description

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 Llamada–Servidor (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 SCSCF 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:
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
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<AS-URI;>; <Orig-DIALOG ID@S-CSCF1;>;….
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 SCSCF recibirá una petición que incluye la cabecera de Ruta siguiente:
Ruta<Orig-DIALOG ID @SCCF1;>;….
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 mensaje de sesión de comunicación. El sistema comprende un servidor de protocolo de iniciación de sesión SIP que responde al mensaje de sesión para identificar una de entre una pluralidad de programas de aplicación ejecutados por un servidor (servlets), proporcionando cada uno de los programas servlets un servicio predefinido a un usuario y un contenedor de servlets.
SUMARIO DE LA INVENCIÓN
La presente invención da a conocer un método para procesar peticiones SIP en una red IMS, de modo que cuando el servidor de aplicación (AS) actúa como el B2BUA e inicia un nuevo diálogo en la red IMS, puede proseguir correctamente el proceso de la lógica de servicio.
El método para el procesamiento de las peticiones del Protocolo de Iniciación de Sesión (SIP) en una red de Subsistema de IP Multimedia (IMS) comprende las etapas siguientes:
la recepción, por un servidor de aplicación (AS), en la red de IMS, de una primera petición SIP reenviada por una Función de Control de Sesión de Llamada-Servidor (S-CSCF) y la generación de una segunda petición SIP de conformidad con la primera petición SIP;
la determinación, por el servidor AS, de si se necesita, o no, asociar la segunda petición SIP con la primera petición SIP en la S-CSCF, si se necesita asociar las 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; de no ser así, la construcción, por el servidor AS, de la cabecera de Ruta de la segunda petición SIP en un modo de comportamiento del Agente de Usuario (UA) origen.
La presente invención da a conocer, además, el servidor de aplicación (AS) en una red de IMS que comprende:
una primera unidad de procesamiento de lógica de servicio para procesar una primera petición SIP;
una segunda unidad de procesamiento de lógica de servicio, para generar una segunda petición SIP, determinando 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 la construcción de la cabecera de Ruta de la segunda petición SIP en un modo de comportamiento del Agente de Usuario (UA) origen, si se determina que no conviene asociar la primera petición SIP con la segunda petición SIP.
La presente invención da a conocer, además, el equipo de red para el control de servicio en una red de IMS, que comprende:
una primera unidad de procesamiento, para determinar si una segunda petición SIP recibida incluye, o no, un identificador de diálogo asociado, la búsqueda de una primera petición SIP que corresponda con la segunda petición SIP si la segunda petición SIP incluye el identificador de diálogo asociado y el procesamiento de la segunda petición SIP de tal modo que se realice el procesamiento de un nuevo diálogo si la segunda petición SIP no incluye el identificador de diálogo asociado;
una segunda unidad de procesamiento, para determinar si la información relacionada con el usuario de la primera petición SIP es la misma, o no, que la información relacionada con el usuario de la segunda petición SIP y proporcionando, a la salida, la determinación a una tercera unidad de procesamiento;
la tercera unidad de procesamiento, para realizar un procesamiento subsiguiente a 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 o procesar la segunda petición SIP de tal modo que se realice el procesamiento de un nuevo diálogo 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.
Se puede deducir de la disposición técnica descrita que los efectos ventajosos de la presente invención son como sigue:
Cuando el servidor AS genera la segunda petición SIP al recibir la primera petición SIP, el servidor AS genera la cabecera de Ruta de la segunda petición SIP decidiendo si la segunda petición SIP y la primera petición SIP necesitan, o no, asociarse en función de la lógica de servicio y si estas dos peticiones no necesitan asociarse, el servidor AS regenera la cabecera de Ruta de la segunda petición SIP. En la técnica anterior, sin embargo, parte de la cabecera de Ruta de la primera petición SIP se copia como la cabecera de Ruta de la segunda petición SIP sin importar que las dos peticiones necesiten, o no, asociarse. Como puede deducirse de la comparación anterior, la presente invención tiene como objetivo principal la situación en la que el nuevo diálogo y el diálogo antiguo no necesitan asociarse en la función S-CSCF, lo que no se considera en la técnica anterior, por ejemplo, el nuevo diálogo y el diálogo antiguo pueden estar en correspondencia con diferentes usuarios y el contenido de la cabecera de Ruta del nuevo diálogo debe ser diferente del que tiene el diálogo antiguo, evitando, de este modo, la confusión con respecto a la detección y proceso de la S-CSCF.
Además, la presente invención adopta una regla de correspondencia de carácter de sustitución para comparar varios identificadores URI, con lo que se evita el posible problema de ser incapaces de procesar correctamente la lógica de servicio debido al hecho de que el carácter de sustitución no se tiene en cuenta en la técnica anterior.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1A es un diagrama esquemático de un servidor AS que actúa como un originador en la técnica anterior.
La Figura 1B es un diagrama esquemático de un servidor AS que actúa como un agente B2BUA en la técnica anterior.
La Figura 2 es un diagrama de flujo del proceso de peticiones cuando un servidor AS actúa como un agente B2BUA según una forma de realización de la presente invención.
La Figura 3A es un diagrama de flujo de determinación de la asociación de lógica de servicio cuando un servidor AS está en el lado llamante según una forma de realización de la presente invención.
La Figura 3B es un diagrama de flujo de determinación de la asociación de la lógica de servicio cuando un servidor AS está en el lado llamado según una forma de realización de la presente invención.
La Figura 4 es un diagrama de flujo de una S-CSCF que procesa la petición del B2BUA según una forma de realización de la presente invención.
La Figura 5 es un diagrama de flujo de la correspondencia de dos identificadores URI en una red IMS, según una forma de realización de la presente invención.
La Figura 6 es un diagrama esquemático de la estructura de un servidor AS según una forma de realización de la presente invención.
La Figura 7 es un diagrama esquemático de la estructura de una S-CSCF según una forma de realización de la presente invención.
La Figura 8 es un diagrama esquemático de la estructura de un sistema para procesar peticiones SIP en una red IMS según una forma de realización de la presente invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
La presente invención se ilustrará a continuación, en detalle, haciendo referencia a los dibujos adjuntos y a una forma de realización específica.
En la red de IMS, las dos cabeceras principales relacionadas estrechamente con el proceso de la lógica de servicio, son la cabecera P-Asserted-Identity y la cabecera Request-URI. Cuando un servidor AS actúa como un agente B2BUA, si no existe ninguna asociación entre la primera petición SIP enviada desde una S-CSCF al servidor AS y la segunda petición SIP generada por el servidor AS en términos de la lógica de servicio, el servidor AS puede modificar las dos cabeceras en la segunda petición SIP. Para conseguir que la S-CSCF detecte correctamente y procese la segunda petición SIP reenviada por el servidor AS, el servidor AS genera una cabecera de Ruta de la segunda petición SIP decidiendo si la nueva petición SIP y las antiguas peticiones SIP están asociadas, o no, en función de la lógica de servicio.
Conviene señalar que los términos “primera” y “segunda” se utilizan en esta descripción solamente para distinguir las dos peticiones y no para definir la secuencia real de las dos peticiones.
La Figura 2 ilustra el procedimiento principal del proceso de peticiones cuando el servidor AS actúa como el Agente B2BUA. Debe entenderse que el siguiente proceso no incluye todas las etapas del proceso de las peticiones cuando el servidor AS actúa como el Agente B2BUA. Según se representa en la Figura 2, el procedimiento principal de proceso de peticiones, cuando el servidor AS actúa como el agente B2BUA, comprende las etapas siguientes:
Etapa 100: El servidor AS recibe la primera petición SIP reenviada por la entidad S-CSCF y procesa esta petición SIP en función de la lógica de servicio.
Etapa 110: El servidor AS genera la segunda petición SIP en función de la lógica de servicio y, durante el procedimiento de generar la segunda petición SIP, decide si la primera petición SIP y la segunda petición SIP necesitan, o no, asociarse en términos de la lógica de servicio en la entidad S-CSCF y si la respuesta es afirmativa, prosigue con la etapa 120 y en caso contrario, prosigue con la etapa 130.
Etapa 120: El servidor AS suprime el AS URI de la cabecera de Ruta de la primera petición SIP y procede a copiar el resto de la cabecera de Ruta en la segunda petición SIP como la cabecera de Ruta de dicha segunda petición SIP y luego, prosigue con la etapa 140.
Etapa 130: El servidor AS regenera la cabecera de Ruta de la segunda petición SIP en un modo de comportamiento del agente UA en origen.
Etapa 140: El servidor AS envía la segunda petición SIP a la entidad S-CSCF.
Como para un diálogo, el servidor AS puede procesar una petición desde el lado llamante, es decir, el servidor AS está en el lado llamante y el servidor AS puede procesar una petición desde el lado llamado, es decir, el servidor AS está en el lado llamado. El servidor AS puede decidir si la identidad Pública IP Multimedia (IMPU) procesada por el servidor AS es la parte llamante o la parte llamada, en función de los datos de suscripción de iFC y por lo tanto, el servidor AS puede decidir si está en el lado llamante o en el lado llamado a la recepción de la petición SIP reenviada por la entidad S-CSCF. Por ejemplo, el servidor AS marca un ORIG-AS en el registro de iFC suscrito y cuando la S-CSCF necesita encaminar una petición SIP que contenga el ORIG-AS al servidor AS, en función del proceso de iFC, el servidor AS conoce que está en el lado llamante y necesita procesar el nombre del usuario como la P-Asserted-Identity indicada. De no ser así, si el servidor AS recibe una petición SIP sin el ORIG-AS, el servidor AS conoce que está en el lado llamado y necesita procesar el nombre del usuario como la Request-URI indicada. Evidentemente, la presente invención no está limitada por la descripción anterior y se puede adoptar también la identificación especial o un puerto especial en una AS URI para decidir si el proceso del AS está en el lado llamante o en el lado llamado.
Existen dos métodos para decidir si la primera y segunda peticiones SIP están asociadas en función de la lógica de servicio:
El primer método consiste en que el servidor AS decide si modificar, o no, la cabecera P-Asserted-Identity o la cabecera Request-URI según la lógica de servicio ejecutada. Cuando se designa la lógica de servicio, se ha tenido ya en cuenta que algunos tipos de lógica de servicio necesitan modificar la cabecera mientras que otros tipos de lógica de servicio no lo necesitan. Si el servidor AS encuentra que la lógica de servicio ejecutada modificará la cabecera, el servidor AS determina que la primera petición SIP y la segunda petición SIP no están asociadas; si el servidor AS encuentra que la lógica de servicio ejecutada no modificará la cabecera, el servidor AS determina que la primera petición SIP y la segunda petición SIP están asociadas.
Se puede deducir de lo anterior que el servidor AS puede decidir si la primera petición SIP y la segunda petición SIP están asociadas mientras se selecciona el servicio y procesar el diálogo en función de la decisión, es decir, si el servicio anterior y el servicio último necesitan, o no, asociarse se define por el diseñador de la lógica de servicio.
El segundo método consiste en que el servidor AS decide si la primera petición SIP y la segunda petición SIP necesitan asociarse en la entidad S-CSCF según el resultado de la ejecución de la lógica de servicio que se utiliza para procesar la petición SIP.
El procesamiento subsiguiente de los dos métodos anteriores, que se utilizan para determinar si el servicio anterior y el servicio último necesitan asociarse, son esencialmente los mismos entre sí y por lo tanto, el proceso será ilustrado a continuación tomando como ejemplo el segundo método.
Por ejemplo, durante el procedimiento de generar la segunda petición SIP, la lógica de servicio genera información relacionada con el usuario para la segunda petición SIP y el servidor AS puede decidir si la segunda petición SIP y la primera petición SIP necesitan, o no, asociarse en la entidad S-CSCF, en función de la información relacionada con el usuario generada para la segunda petición SIP y la información relacionada con el usuario de la primera petición SIP y generar la cabecera de Ruta de la segunda petición SIP en función de dicha decisión. Durante el proceso de la toma de decisión, si el servidor AS está en el lado llamante, la decisión se realiza principalmente en función de la cabecera P-Asserted-Identity de la primera petición SIP y la cabecera P-Asserted-Identity de la segunda petición SIP; si el servidor AS está en el lado llamado, la decisión se realiza principalmente en función de la cabecera Request-URI de la primera petición SIP y la cabecera Request-URI de la segunda petición SIP. Durante el proceso de toma de decisión, se puede utilizar también la regla de correspondencia de carácter de sustitución para la comparación. La aplicación del carácter de sustitución en la red IMS se ilustrará antes de introducir el proceso específico.
En las redes de telecomunicaciones tradicionales, existe un tipo de números de teléfonos especiales, tales como 114/100. Estos números de teléfonos especiales no suelen representar a usuarios reales, por lo que no existe ningún proceso tal como registro de usuario o autenticación en consecuencia. La red de IMS introduce, además, una identidad especial similar que se denomina identidad de servicio público (PSI). Dos tipos de PSI se introducen en la red IMS, que es diferente de la identidad especial tradicional. Un tipo se denomina el PSI específico que representa los usuarios especiales y el otro tipo se denomina PSI de carácter de sustitución que representa un cierto tipo de usuarios que no son usuarios especiales.
La PSI de carácter de sustitución puede representar múltiples identidades PSIs específicas diferentes y cuando el formato de la PSI de carácter de sustitución adopta el formato de SIP URI, la USER-INFO puede incluir el formato de expresión canónica extensivo que está limitado por “!” y definido por la norma IEEE 1003.1-2004 Parte 1. Por ejemplo, “sip:chatlist!*!@example.com” se puede hacer corresponder con:
sip:chatlist1@example.com
sip:chatlist2@example.com,
sip:chartist42@example.com,
sip:chartistAbC@example.com.
cuando se adopta el formato del TEL URI, la parte de teléfono del usuario puede incluir el formato de expresión canónica extensiva que está limitada por “!” y definida por la norma IEEE 1003.1-2004 Parte 1. Por ejemplo “TEL:123456 ¡.*!” se puede hacer corresponder con:
TEL: 1234561;
TEL:1234567; TEL: 123456789.
Según el método de comparación SIP URI existente, si el servidor AS cambia un determinado identificador de carácter de sustitución en un identificador específico, a partir del aspecto del proceso de la lógica de servicio, debe continuar el proceso de servicio original. Por ejemplo, el usuario no puede determinar el número de la chart room (sala de conversación) disponible, por lo que la llamada inicial es una PSI de carácter de sustitución de la chart room, que se procesa por el servidor AS en el modo del agente B2BUA y se trasforma en una PSI específica por el servidor AS. En función del método de comparación de SIP URI existente, estas dos identidades URIs se considerarán como diferentes y no se continuará el proceso de iFC incompleto original. La nueva petición SIP será considerada como una llamada nueva y se procesará con un nuevo iFC. Evidentemente, no es razonable, en términos del proceso de lógica de servicio, utilizar la nueva petición SIP como una llamada nueva. Según la presente invención, la regla de correspondencia de carácter de sustitución se introduce para superar la limitación antes citada de la técnica anterior, mediante la cual las dos identidades URIs que son en teoría diferentes, pero esencialmente la misma, se utilizan como la URI idéntica continuando, de este modo, el proceso de iFC incompleto original en el nuevo diálogo.
Con referencia a la Figura 3A, cuando el servidor AS está en el lado llamante, el procedimiento principal de decidir si la primera petición SIP y la segunda petición SIP están, o no, asociadas en términos de la lógica de servicio comprende las etapas siguientes:
Etapa 200: Obtención de la cabecera P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP.
Etapa 210: Decidir si son idénticas, o no, la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP; si las dos son idénticas, se prosigue con la etapa 240 y de no ser así, se prosigue con la etapa 220.
Etapa 220: Decidir si la P-Asserted-Identity incluye cualquier carácter de sustitución; si la respuesta es afirmativa, se prosigue con la etapa 230 y de no ser así, se prosigue con la etapa 250.
Etapa 230: Decidir si la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP están en correspondencia, o no, entre sí en función de la regla de correspondencia del carácter de sustitución predefinido; si la respuesta es afirmativa se prosigue con la etapa 240 y de no ser así, se prosigue con la etapa 250.
Etapa 240: El servidor AS determina que la primera petición SIP y la segunda petición SIP están asociadas en términos de la lógica de servicio.
Etapa 250: El servidor AS determina que la primera petición SIP y la segunda petición SIP no están asociadas en términos de la lógica de servicio.
En función del requerimiento del proceso de la lógica de servicio, la base de la toma de decisión realizada por el servidor AS puede ser también la combinación de P-Asserted-Identity y de Request-URI de la primera petición SIP y la de la segunda petición SIP. Dicho de otro modo, después de determinar que P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP son idénticas, el servidor AS puede decidir, además, si la Request-URI de la primera petición SIP y la de la segunda petición SIP son idénticas. Si las identidades P-Asserted-Identity de las dos peticiones son idénticas, mientras que la Request-URIs de las dos peticiones no lo son, se puede determinar que la primera petición SIP y la segunda petición SIP no necesitan asociarse en términos de la lógica de servicio.
Debe entenderse que, cuando se compara la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP, es factible desechar el carácter de sustitución y solamente decidir si las identidades P-Asserted-Identity de las dos peticiones son idénticas; si la respuesta es afirmativa, se determina que las dos peticiones están asociadas y de no ser así, las dos peticiones no están asociadas. La introducción de la correspondencia del carácter de sustitución se utiliza para optimizar, todavía más, el sistema básico de la presente invención.
Con referencia a la Figura 3B, cuando el servidor AS está en el lado llamado, el procedimiento principal para decidir si la primera petición SIP y la segunda petición SIP están, o no, asociadas en términos de la lógica de servicio, comprende las etapas siguientes:
Etapa 300: Obtención de la Request-URI de la primera petición SIP y la de la segunda petición SIP.
Etapa 310: Decidir si la Request-URI de la primera petición SIP y la de la segunda petición SIP son, o no, idénticas; si las dos son idénticas, se prosigue con la etapa 340 y de no ser así, se prosigue con la etapa 320.
Etapa 320: Decidir si la Request-URI incluye, o no, cualquier carácter de sustitución; si la respuesta es afirmativa se prosigue con la etapa 330 y de no ser así, se prosigue con la etapa 350.
Etapa 330: Decidir si la Request-URI de la primera petición SIP y la de la segunda petición SIP están en correspondencia entre sí, o no, en función de la regla de correspondencia de carácter de sustitución predefinida; si la respuesta es afirmativa se prosigue con la etapa 340 y de no ser así, se prosigue con la etapa 350.
Etapa 340: El servidor AS determina que la primera petición SIP y la segunda petición SIP están asociadas en términos de la lógica de servicio.
Etapa 350: El servidor AS determina que la primera petición SIP y la segunda petición SIP no están asociadas en términos de la lógica de servicio.
Del mismo modo, después de determinar que las Request-URI de las dos peticiones son idénticas, el servidor AS puede decidir, además, si la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP son idénticas.
Además, el servidor AS puede añadir información a la segunda petición SIP o modificar la información de la segunda petición SIP, modificando análogamente la Request-URI o la P-Asserted-Identity para solicitar a la entidad S-CSCF que prosiga, o no, el proceso de iFC subsiguiente.
Debe entenderse que, durante el procedimiento de la comparación de la Request-URI de la primera petición SIP y la de la segunda petición SIP, es factible desechar el carácter de sustitución y solamente decidir si las Request-URIs de las dos peticiones son idénticas; si las dos Request-URIs son diferentes, se determina que las dos peticiones están asociadas; de no ser así, se determina que las dos peticiones no están asociadas. La introducción de la correspondencia de carácter de sustitución se utiliza para optimizar, todavía más, el sistema según la presente invención.
En cuanto a la entidad S-CSCF, a la recepción de la segunda petición SIP transmitida por el servidor AS, si la entidad SCSCF detecta que la petición recibida transmite un identificador Orig-DIALOG ID, la entidad S-CSCF realizará la búsqueda de la primera petición SIP (el diálogo antiguo) directamente en cuanto a su correspondencia en función del identificador Orig-DIALOG ID con esta petición. A continuación, la entidad S-CSCF realiza el proceso en función de la información de si continuar, o no, el proceso de iFC subsiguiente transmitido por la segunda petición SIP. Si la entidad SCSCF no detecta ningún identificador Orig-DIALOG ID en la segunda petición SIP, esta petición se considerará como una nueva petición SIP y se procesará directamente según el método existente de la normalización.
A la recepción de la segunda petición SIP generada por el servidor AS, según el método antes citado, la entidad S-CSCF puede realizar directamente la detección de iFC subsiguiente y procesar la segunda petición SIP en función de la cabecera de Ruta de la petición SIP, puesto que la cabecera de Ruta de la primera petición SIP no será copiada como la cabecera de Ruta de la segunda petición SIP hasta que el servidor AS haya determinado que la primera petición SIP y la segunda petición SIP necesitan estar asociadas. Sin embargo, con el fin de hacer la entidad S-CSCF compatible con los servidores ASs que no tengan la capacidad de procesamiento antes citada, después de encontrar la primera petición SIP en correspondencia con la segunda petición SIP en función del identificador Orig-DIALOG ID, la entidad S-CSCF puede determinar, además, si proseguir, o no, el proceso de iFC subsiguiente decidiendo si la información añadida o modificada por el servidor AS, como P-Asserted-Identity o Request-URI, en la primera petición SIP y la existente en la segunda petición SIP son idénticas, o no, en función de la regla de correspondencia de SIP URI o de TEL-URL. Debe entenderse que al comparar la P-Asserted-Identity o la Request-URI, en la primera petición SIP y en la segunda petición SIP es factible desechar el carácter de sustitución y solamente decidir si las identidades P-Asserted-Identity o Request-URIs de las dos peticiones son idénticas; si las dos Request-URIs son diferentes, se determina que las dos peticiones están asociadas; de no ser así, se determina que las dos peticiones no están asociadas. La introducción de la correspondencia del carácter de sustitución se utiliza para optimizar, todavía más, el sistema según la presente invención.
A la recepción de la petición SIP, la entidad S-CSCF decide si es la primera vez, o no, que esta petición SIP llega en esta entidad S-CSCF decidiendo si esta petición comprende, o no, un identificador ORIG-DIALOG ID. En cuanto a la primera petición SIP, la entidad S-CSCF puede decidir si está procesando la petición SIP en el lado llamante o la petición SIP en el lado llamado, en función de la información de la primera petición SIP. En cuanto a una petición SIP que no llegue a la entidad S-CSCF la primera vez, la S-CSCF determina si la primera petición SIP está en correspondencia con la petición SIP en primer lugar y luego, decide si esta petición SIP es la petición SIP en el lado llamante o la del lado llamado. Si se determina que la petición es una petición SIP en el lado llamante, la entidad S-CSCF decidirá si realizar, o no, la detección de iFC y procesar la segunda petición SIP reenviada por el servidor AS principalmente decidiendo si la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP son idénticas; si se determina que la petición es una petición SIP en el lado llamado, la entidad S-CSCF decidirá si realizar, o no, la detección de iFC y procesar la segunda petición SIP reenviada por el servidor AS principalmente decidiendo si la Request-URI de la primera petición SIP y la de la segunda petición SIP son, o no, idénticas. Durante el procedimiento de comparación de la P-Asserted-Identity y de Request-URI de la primera petición SIP y las de la segunda petición SIP, se puede tener en cuenta el carácter de sustitución.
Con referencia a la Figura 4, cuando la entidad S-CSCF está en el lado llamante, el procedimiento principal de procesar la segunda petición SIP reenviada por el servidor AS comprende las etapas siguientes:
Etapa 400: La entidad S-CSCF recibe la segunda petición SIP.
Etapa 410: La entidad S-CSCF decide si la cabecera de Ruta incluye, o no, un identificador ORIG-DIALOG ID; si la respuesta es afirmativa se prosigue con la etapa 420 y de no ser así, se prosigue con la etapa 480.
Etapa 420: La entidad S-CSCF encuentra que la primera petición SIP que está en correspondencia con la segunda petición SIP en función del identificador Orig-DIALOG ID.
Etapa 430: La entidad S-CSCF decide si la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP son, o no, idénticas; si la respuesta es afirmativa se prosigue con la etapa 460; de no ser así, se prosigue con la etapa
440.
Etapa 440: La entidad S-CSCF decide si la P-Asserted-Identity incluye, o no, cualquier carácter de sustitución y si la respuesta es afirmativa se prosigue con la etapa 450 y de no ser así, se prosigue con la etapa 470.
Etapa 450: La entidad S-CSCF decide si la P-Asserted-Identity de la primera petición SIP y la de la segunda petición SIP están en correspondencia entre sí y si la respuesta es afirmativa se prosigue con la etapa 460; de no ser así, se prosigue con la etapa 470.
Etapa 460: La entidad S-CSCF determina que la primera petición SIP y la segunda petición SIP están asociadas en términos de la lógica de servicio y realiza la detección de iFC subsiguiente y procesa la segunda petición SIP.
Etapa 470: La entidad S-CSCF determina que la primera petición SIP y la segunda petición SIP no están asociadas en términos de la lógica de servicio y, en lugar de realizar la detección de iFC subsiguiente y el proceso de la segunda petición SIP, determina el siguiente salto operativo en función de la cabecera de Ruta y de la cabecera de Request-URI de la segunda petición SIP y luego, reenvía la segunda petición SIP al siguiente salto operativo.
Etapa 480: La entidad S-CSCF procesa la segunda petición SIP en el modo de procesamiento de un nuevo diálogo.
Cuando la entidad S-CSCF está en el lado llamado y procesa la segunda petición SIP reenviada por el servidor AS, los procesos son básicamente los mismos que los procesos que cuando la entidad S-CSCF está en el lado llamante, exceptuado el procedimiento de decidir si la Request-URI de la primera petición SIP y la Request-URI de la segunda petición SIP son idénticas, o no, cuando la entidad S-CSCF está en el lado llamante, que no se describirán con detalle en adelante en esta descripción.
Debe entenderse que, durante el procedimiento de la comparación de las identidades P-Asserted-Identity de las dos peticiones, es factible desechar el carácter de sustitución y solamente decidir si las identidades P-Asserted-Identity de las dos peticiones son, o no, idénticas; si la respuesta es afirmativa se determina que las dos peticiones están asociadas y de no ser así, se determina que las dos peticiones no están asociadas. La introducción de la correspondencia del carácter de sustitución se utiliza para optimizar el sistema según la presente invención.
Con referencia a la descripción representada en la Figura 3A, Figura 3B y Figura 4, se puede deducir que el método para la correspondencia de las identidades URIs según una forma de realización de la presente invención se puede aplicar a cualquier entorno de red IMS para la comparación de las identidades URIs. Según se representa en la Figura 5, el procedimiento principal para la correspondencia de las identidades URIs comprende las etapas siguientes:
Etapa 500: Decidir si las dos identidades URIs son, o no, idénticas; si la respuesta es afirmativa se prosigue con la etapa 530; de no ser así, se prosigue con la etapa 510.
Etapa 510: Decidir, además, si al menos una de las identidades URIs incluye, o no, cualquier carácter de sustitución y si no lo es, se prosigue con la etapa 540 y en caso contrario, se prosigue con la etapa 520.
Etapa 520: Decidir si las dos identidades URIs se corresponden, o no, entre sí, en función de la regla de correspondencia de carácter de sustitución predefinida; si la respuesta es afirmativa se prosigue con la etapa 530; de no ser así, se prosigue con la etapa 540.
Etapa 530: Determinación de que las dos identidades URIs están en correspondencia entre sí y proseguir el procesamiento subsiguiente en función del estado operativo de correspondencia.
Etapa 540: Determinación de si las dos identidades URIs no están en correspondencia entre sí y proseguir el procesamiento subsiguiente en función del estado operativo de no correspondencia.
Con referencia a la Figura 6, el servidor AS 60 es una forma de realización para poner en práctica el método antes descrito que incluye la primera unidad de procesamiento de lógica de servicio 600 y la segunda unidad de procesamiento de lógica de servicio 601. Conviene señalar que otros módulos funcionales para la puesta en práctica de las funciones básicas existentes no están representados en la Figura 6.
La primera unidad de procesamiento de lógica de servicio 600 se utiliza para procesar la primera petición SIP reenviada por la entidad S-CSCF.
La segunda unidad de procesamiento de lógica de servicio 601 está conectada, por medios lógicos, a la primera unidad de procesamiento de lógica de servicio 600 y se utiliza para generar la segunda petición SIP y, mientras se genera la segunda petición SIP, se genera la cabecera de Ruta para la segunda petición SIP en función de la decisión de si se necesita, o no, asociar la primera petición SIP con la segunda petición SIP en términos de la lógica de servicio. Más concretamente, si se necesita asociar las dos peticiones SIP, la identidad AS URI será suprimida de la cabecera de Ruta de la primera petición SIP y el resto de la cabecera de Ruta se considerará como la cabecera de Ruta de la segunda petición SIP, de no ser así, la cabecera de Ruta de la segunda petición SIP será construida en un modo de comportamiento de UA en origen.
La segunda unidad de procesamiento de la lógica de servicio 601 comprende el primer módulo 6010, el segundo módulo 6011 y el tercer módulo 6012.
El primer módulo 6010 se utiliza para decidir si la información pertinente de la primera petición SIP y la de la segunda petición SIP son idénticas o no, o determinar si se necesita asociar la primera petición SIP con la segunda petición SIP en la entidad S-CSCF, en función de la lógica de servicio seleccionada; si la información pertinente de las dos peticiones son idénticas o se necesita asociar las dos peticiones, se proporciona a la salida la decisión para el segundo módulo 6011; de no ser así, se proporciona a la salida la decisión al tercer módulo 6012. La información pertinente puede ser información relacionada con el usuario incluyendo la cabecera P-Asserted-Identity y/o la cabecera Request-URI.
El tercer módulo 6012 está lógicamente conectado al primer módulo 6010; cuando la información pertinente de la primera petición y la de la segunda petición son diferentes y cuando cada una de las dos peticiones no incluye ningún carácter de sustitución, el tercer módulo 6012 se utiliza para decidir si la información pertinente de la primera petición SIP y la de la segunda petición SIP están en correspondencia entre sí y proporciona a la salida la decisión al segundo módulo 6011.
El segundo módulo 6011 está lógicamente conectado al primer módulo 6010 y al tercer módulo 6012 y se utiliza para generar la cabecera de Ruta en función de la decisión del primer módulo 6010 y la del tercer módulo 6012.
Conviene señalar que el tercer módulo 6012 es opcional y se puede excluir. Dicho de otro modo, el proceso de decidir si la información pertinente de la primera petición SIP y la de la segunda petición SIP están en correspondencia, o no, en función de la regla de correspondencia del carácter de sustitución que se puede excluir. En este caso, el primer módulo 6010 proporciona a la salida directamente la decisión al segundo módulo 6011.
Con referencia a la Figura 7, la entidad S-CSCF 70, en una forma de realización de la presente invención, para poner en práctica el método antes citado incluye la primera unidad de procesamiento 700, la segunda unidad de procesamiento 701, la tercera unidad de procesamiento 702 y la cuarta unidad de procesamiento 704, mientras que los otros módulos funcionales para realizar las funciones básicas existentes no están representados en la Figura 7.
La primera unidad de procesamiento 700 decide si la segunda petición SIP recibida incluye, o no, el identificador de diálogo asociado relacionado y, cuando se determine que la segunda petición SIP comprende el identificador de diálogo asociado, determina si la primera petición SIP está en correspondencia con la segunda petición SIP.
La segunda unidad de procesamiento 701 está lógicamente conectada a la primera unidad de procesamiento 700 y se utiliza para decidir si la información pertinente de la primera petición SIP y la de la segunda petición SIP son idénticas; si la respuesta es afirmativa se proporciona a la salida la decisión para la tercera unidad de procesamiento 702 y de no ser así, se proporciona a la salida la decisión a la cuarta unidad de procesamiento 703.
La cuarta unidad de procesamiento 703 está conectada, por medios lógicos, a la segunda unidad de procesamiento 701; cuando la información pertinente de la primera petición y la de la segunda petición son diferentes y cada una de las dos peticiones no incluye un carácter de sustitución, la cuarta unidad de procesamiento 703 se utiliza para decidir si la información pertinente de la primera petición SIP y la de la segunda petición SIP están en correspondencia entre sí y proporcionan a la salida la decisión a la tercera unidad de procesamiento 702. La información pertinente puede ser información relacionada con el usuario que incluye a la cabecera de P-Asserted-Identity y/o la cabecera de Request-URI.
La tercera unidad de procesamiento 702 está conectada, por medios lógicos, a la segunda unidad de procesamiento 701 y la cuarta unidad de procesamiento 703, respectivamente, y se utiliza para procesar la segunda petición SIP en función de la decisión de la segunda unidad de procesamiento 701 o la de la cuarta unidad de procesamiento 703.
La cuarta unidad de procesamiento 703 es opcional y se puede excluir. Dicho de otro modo, el proceso de decidir si la información pertinente de la primera petición SIP y de la segunda petición SIP están en correspondencia, o no, en función de la regla de correspondencia del carácter de sustitución se puede excluir. En este caso, la segunda unidad de procesamiento 701 proporciona a la salida, directamente la decisión a la tercera unidad de procesamiento 702.
La presente invención da a conocer, además, un sistema para procesar peticiones SIP en la red IMS, que incluye un servidor AS y una entidad S-CSCF. Según se representa en la Figura 8, la estructura del servidor AS en la Figura 8 es completamente la misma que la del servidor AS representado en la Figura 6 y por ello son funciones del mismo, y no se describirán con detalle en la presente; la estructura de la entidad S-CSCF en la Figura 8 es completamente la misma que la de la entidad S-CSCF representada en la Figura 6 y por ello son funciones de la misma y no se describirán en detalle a continuación.
La presente invención se ilustrará, además, haciendo referencia a un ejemplo, que solamente enumera segmentos de peticiones SIP que están relacionadas con la presente invención.
Otros detalles de cada petición se pueden obtener haciendo referencia a las normas pertinentes.
1. El servidor AS está en el lado llamante y determina que no se necesita asociar la petición SIP original y la nueva petición SIP en términos de la lógica de servicio en la entidad S-CSCF. En la primera etapa, la entidad S-CSCF recibe una petición SIP entrante (segmento) que es como sigue: …. INVITE sip:bob@biloxi.com SIP/2.0 Para: Bob<sip:bob@biloxi.com> De: Alice<sip:alice@atlanta.com>; tag= 1928301774 Call-ID: a84b4c76e66710 Ruta: s-cscf1@biloxi.com P-Asserted-Identity: “John Doe” <sip:user1_public1@home1.net>
…. A la recepción de la petición SIP, la entidad S-CSCF ejecuta la lógica de servicio pertinente y decide reenviar la petición SIP al servidor AS, utilizando la petición SIP como la primera petición SIP.
En la segunda etapa, el servidor AS recibe la primera petición SIP (segmento) desde la entidad S-CSCF, que es como sigue: …. INVITE sip:bob@biloxi.com SIP/2.0 Para: Bob<sip:bob@biloxi.com> De: Alice<sip:alice@atlanta.com>; tag= 1928301774 Call-ID: a84b4c76e66710 Ruta: <AS@biloxi.com>, <ORIG_DILAG ID@biloxi.com> P-Asserted-Identity: “John Doe” <sip:user1_public1@home1.net>
…. En la tercera etapa, el servidor AS determina, en función de la lógica de servicio, que se debe modificar la P-Asserted-Identity y por ello, no se necesita asociar la primera petición SIP con la segunda petición SIP en la entidad S-CSCF y la cabecera de Ruta de la segunda petición SIP será construida y se podrá modificar también el identificador Call ID. La segunda petición SIP (segmento) generada por el servidor AS es como sigue:
…. INVITE sip:bob@biloxi.com SIP/2.0 Para: Bob2<sip:bob@biloxi.com>
De: Alice2<sip:alice@atlanta.com>; tag= 1928301774 Call-ID: a84b4c76e66721 Ruta: <S-CSCF@biloxi.com; Orig> P-Asserted-Identity: “TOM” <sip:user2_public1@home1.net> …. En la cuarta etapa, a la recepción de la segunda petición SIP enviada por el servidor AS, la entidad S-CSCF no
detectada ningún identificador Orig-DIALOG ID, por lo que la segunda petición SIP se utilizará como un nuevo diálogo llamante y se procesará sobre la base de una nueva iFC. La petición SIP (segmento) después de ser procesada es como sigue:
…. INVITE sip:bob@biloxi.com SIP/2.0 Para: Bob2<sip:bob@biloxi.com> De: Alice2<sip:alice@atlanta.com>; tag= 1928301774 Call-ID: a84b4c76e66721 P-Asserted-Identity: “TOM” <sip:user2_public1@home1.net>
2. El servidor AS está en el lado llamante y decide si se necesita, o no, asociar la petición SIP original y la nueva petición SIP en términos de la lógica de servicio en la entidad S-CSCF. En la primera etapa, la petición SIP (segmento) recibida por la S-CSCF es como sigue: …. INVITE sip:bob@biloxi.com SIP/2.0 Para: Bob<sip:bob@biloxi.com> De: Alice<sip:alice@atlanta.com>; tag= 1928301774 Call-ID: a84b4c76e66710 Ruta: s-cscf1@biloxi.com P-Asserted-Identity: “John Doe” <sip:user1_public1@home1.net>
…. La entidad S-CSCF ejecuta la lógica de servicio pertinente y decide reenviar la petición al servidor AS, utilizando la petición como la primera petición SIP.
En la segunda etapa, la primera petición SIP (segmento) recibida por el servidor AS, desde la entidad S-CSCF, es como sigue: …. INVITE sip:bob@biloxi.com SIP/2.0 Para: Bob<sip:bob@biloxi.com> De: Alice<sip:alice@atlanta.com>; tag= 1928301774 Call-ID: a84b4c76e66710 Ruta: <AS@biloxi.com>, <ORIG_DILAG ID@biloxi.com>
P-Asserted-Identity: “John Doe” <sip:user1_public1@home1.net> …. En la tercera etapa, el servidor AS determina no modificar P-Asserted-Identity en función de la lógica de servicio y por
ello, se necesita asociar la primera petición SIP con la segunda petición SIP en la entidad S-CSCF y la cabecera de Ruta
de la primera petición SIP será copiada. La segunda petición SIP generada por el servidor AS es como sigue:
….
INVITE sip:bob@biloxi.com SIP/2.0
Para: Bob2<sip:bob@biloxi.com>
De: Alice2<sip:alice@atlanta.com>; tag= 1928301774
Call-ID: a84b4c76e66721
Ruta: <ORIG_DILAG ID@biloxi.com>
P-Asserted-Identity: “John Doe” <sip:user1_public1@home1.net>
…. En la cuarta etapa, a la recepción de la segunda petición SIP, la entidad S-CSCF detecta un identificador Orig-DIALOG ID, determina que la segunda petición SIP está asociada con la primera petición SIP y encuentra que la P-Asserted- Identity no está modificada, por lo que se continuará el proceso de iFC incompleto original. La petición SIP (segmento) después de procesarse es como sigue:
….
INVITE sip:bob@biloxi.com SIP/2.0
Para: Bob<sip:bob@biloxi.com>
De: Alice2<sip:alice@atlanta.com>; tag= 1928301774
Call-ID: a84b4c76e66721
P-Asserted-Identity: “John Doe” <sip:user1_public1@home1.net>
….
Lo anterior es solamente las formas de realización preferidas de la presente invención y no están previstas para limitar el
alcance de protección de la presente invención. Cualquier modificación, sustitución equivalente o mejora realizada sin
desviarse del principio de la presente invención debe estar cubierta por el alcance de protección establecido en las
reivindicaciones adjuntas.

Claims (14)

  1. REIVINDICACIONES
    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. 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. 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. 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. 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. 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. 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;
  8. 8.
    El método, según cualquiera de las reivindicaciones 1 a 7, que comprende además:
    si el servidor AS está en un lado llamado, la información relacionada con el usuario comprende la cabecera Request–URI y/o la P-Asserted-Identity;
    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. 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. 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. 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. 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. 13. El servidor AS, según la reivindicación 12, en donde la segunda unidad de procesamiento de lógica de servicio comprende:
    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);
    5 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. 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:
    10 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)..
ES06254341T 2005-08-19 2006-08-18 Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as. Active ES2365743T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200510090919 2005-08-19
CN200510090919 2005-08-19
CN200510119756 2005-11-03

Publications (1)

Publication Number Publication Date
ES2365743T3 true ES2365743T3 (es) 2011-10-10

Family

ID=44654587

Family Applications (1)

Application Number Title Priority Date Filing Date
ES06254341T Active ES2365743T3 (es) 2005-08-19 2006-08-18 Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as.

Country Status (1)

Country Link
ES (1) ES2365743T3 (es)

Similar Documents

Publication Publication Date Title
US7835352B2 (en) Method, system and equipment for processing SIP requests in IMS network
US10038794B2 (en) System for communicating with an internet protocol multimedia subsystem network
ES2337836T3 (es) Encaminamiento de llamadas ims utilizando identificadores de recursos uniformes de telefonos (tel-uris).
ES2393952T3 (es) Proporcionar servicios de empresa en una red de abastecimiento de servicios
US9026663B2 (en) Method, apparatus and program product for merging communication sessions in an IMS
EP1461965B1 (en) Communication node architecture
ES2773546T3 (es) Sistema y método para determinar la confianza para mensajes de SIP
US8213425B2 (en) Method for matching initial request message in the IP multimedia subsystem service triggering process
US8325707B2 (en) Session initiation from application servers in an IP multimedia subsystem
ES2373458T3 (es) Método para registrar dispositivos multicontacto.
US8423652B2 (en) Service templates for an IP multimedia subsystem
WO2007085154A1 (fr) Procédé et système pour la mise en oeuvre de service de réseau numérique à intégration de services (rnis) dans le réseau de commutation par paquets
EP2587777A1 (en) Method and system for implementing color ring back tone and multimedia ring alert tone service.
US20130060954A1 (en) Enabling set up of a connection from a non-registered ue in ims
US9055083B2 (en) Interworking method and interworking control unit, method and system for implementing simulation services
US20190089832A1 (en) Initiation of conference and transfer call in internet protocol multimedia subsystem based emergency services network
US9032082B2 (en) Method and device configured for processing an SDP request in a media path optimization process
ES2365743T3 (es) Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as.
ES2551415T3 (es) Método y dispositivo para procesamiento del anidamiento de servicios de banda ancha
US20080186956A1 (en) Method and system for processing call change request in an internet protocol multimedia subsystem
JP2023540063A (ja) 合法的傍受のためのパケットのルーティングのための方法、システムおよびコンピュータ読取可能媒体
US8560700B2 (en) IMS media codec negotiation method and system
CN101448316A (zh) 叠加注册的实现方法
CN101170558A (zh) 呼叫会话控制器在会话过程中确定私有用户标识的方法
JP2012165286A (ja) ネットワーク制御方法、及びセッション処理装置