MX2008006661A - Manejo de mensajes en un subsistema multimedios ip - Google Patents

Abstract

Un servidor de aplicaciones de protocolo de iniciación de sesión de un subsistema de multimedios IP que tiene medios de procesamiento para manejar un mensaje recibido desde una Función llamada de servicio/control de estado, el medio siendo acomodado para manejar el mensaje basado en un encabezado de mensaje que contiene el URI del usuario servido, este encabezado habiendo sido introducido por la Función llamada de servicio/control de estado y siendo diferente de la Identidad P-Asserted y el R-URI.

Description

MANEJO DE MENSAJES EN UN SUBSISTEMA MULTIMEDIOS IP CAMPO DE LA INVENCIÓN La presente invención se refiere al manejo de un mensaje de Protocolo de iniciación de Sesión en una Subsistema multimedios IP (IMS), y en particular, aunque no necesariamente, a un método y aparato para manejar mensajes de Protocolo De Iniciación De Sesión relacionados con el envío de llamadas a una Función Llamada de Servicio/ Control de Función dentro del IMS.

ANTECEDENTE DE LA INVENCIÓN Los Servicios multimedios IP proporcionan una combinación dinámica de voz, video, mensajes, datos, etc. dentro de la misma sesión. Al crecer el número de aplicaciones básicas y los medios que es posible combinar, el número de servicios ofrecidos a los usuarios finales crecerá, y la experiencia de comunicación interpersonal será enriquecida. Esto dará como resultado una nueva generación de servicios de comunicación multimedios rica, personalizada incluyendo los llamados servicios multimedios IP combinados que se considerarán en más detalle abajo.

El Subsistema multimedios IP (IMS) es la tecnología definida por el Proyecto De Sociedad De Tercera Generación (3GPP) para proporcionar servicios multimedios IP sobre las redes de comunicación móvil (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.328, y TS 29.329 Versiones 5 a 7. IMS proporciona características claves para enriquecer la experiencia de comunicación persona a persona del usuario final a través del uso de Habilitadores de Servio IMS normalizados, los cuales facilitan nuevos servicios de comunicación persona a persona (cliente a cliente) , ricos así como servicios persona a contenido (cliente a servidor) sobre las redes basadas en IP. El IMS hace uso del Protocolo de iniciación de Sesión (SIP) para establecer y controlar llamadas y sesiones entre terminales de usuario (o terminales de usuario y servidores de aplicación) . El Protocolo de Descripción de Sesión (SDP) , trasportado por la señalización SIP, se usa para describir y negociar los componentes medios de la sesión. Aunque el SIP fue creado como un protocolo usuario a usuario, el IMS permite a los operadores y proveedores del servicio controlar el acceso del usuario a los servicios y cargar a los usuarios lo correspondiente.

La Figura 1 demuestra esquemáticamente como el IMS ajusta en la arquitectura de red móvil en el caso de una red de acceso GPRS/PS. Las funciones Llamada/Control de Función (CSCF) operan como apoderados SIP dentro del IMS. La arquitectura 3GPP define tres tipos de CSCF: El Apoderado CSCF (P-CSCF) que es el primer punto de contacto dentro del IMS para una terminal SIP; El CSCF de servicio (S-CSCF) que proporciona servicios al usuario a los que está suscrito el usuario; y el CSCF Interrogante (I-CSCF) cuyo papel es identificar el S-CSCF correcto y enviar a ese S-CSCF una solicitud recibida desde una terminal SIP por medio de un P-CSCF.

Un usuario registrado con el IMS usando el método de REGISTRO SIP especificado. Esto es un mecanismo para unirse al IMS para anunciar al IMS la dirección en la cual una identidad de usuario SIP puede ser alcanzada. El usuario recibe un URI único desde el S-CSCF que usará cuando inicie un dialogo. En 3GPP, cuando una terminal SIP realiza un registro, El IMS autentica al usuario, y asigna un S-CSCF a ese usuario desde la serie de S-CSCF disponibles. Mientras que los criterios para asignar un S-CSCF no estén especificados por el 3GPP, estos pueden incluir requerimientos de servicio y compartición de carga. Se debe observar que la asignación de un S-CSCF es clave para controlar (y para cargar) el acceso del usuario a los servicios basados en IMS. El operador puede proporcionar un mecanismo para evitar sesiones SIP usuario a usuario, directas que de otro modo derivan el S-CSCF.

Durante el proceso de registro, es responsabilidad del I-CSCF seleccionar un S-CSCF si no está seleccionado uno todavía. EL I-CSCF recibe las capacidades S-CSCF requeridas de la red local del Servidor Subscriptor Doméstico (HSS) , y selecciona un S-CSCF adecuado basado en las capacidades recibidas. [SE observa que la asignación S-CSCF es también trasportada por un usuario mediante el I-CSCF en el caso donde el usuario es llamado por otra parte, y el usuario no tiene actualmente asignado un S-CSCF.] Cuando un usuario registrado subsecuentemente envía una solicitud de sesión (por ejemplo SIP INVITE) al IMS, la solicitud incluirá el P-CSCF y S-CSCF URI de manera que el P-CSCF es capaz de enviar la solicitud al S-CSCF seleccionado. Esto aplica en ambos lados, lado de origen y lado terminación (del IMS) . [Para la terminación de llamada la solicitud incluirá la dirección P-CSCF y la dirección UE.] Dentro de la red de servicio IMS, se proporcionan los Servidores de Aplicación (AS) para poner en práctica la funcionalidad del servicio IMS. Los Servidores de Aplicación proporcionan servicios a LOS usuarios finales en un sistema IMS, y pueden estar conectados a puntos terminales sobre el 3GPP definido en Interfaz MR, o "enlazados en" por medio de un S-CSCF sobre el 3GPP definido en la interfaz ISC. En el ultimo caso, los Criterios de Filtro Inicial (IFC) son usados por un S-CSCF para determinar que Servidores de Aplicación deben estar "enlazados en" durante el establecimiento de una sesión SIP. Se puede aplicar diferentes IFC a diferentes casos de llamada. Los IFC son recibidos mediante el S-CSCF desde un HSS durante el procedimiento de registro IMS como parte de un Perfil De Usuario del usuario. Ciertos Servidores de Aplicación realizarán acciones dependientes de las entidades suscriptoras (ya sea suscriptor llamado o que llama, cualquiera que sea "propiedad de" la red que controla los Servidores de Aplicación) . Por ejemplo, en el caso de llamadas enviadas, el servidor de aplicación adecuado (terminal) determinará la nueva parte terminal a la cual será enviada una llamada a un suscriptor dado.

El trabajo de grupo conocido como ETSI TISPAN es desarrollado para usar el IMS para accesos de banda ancha fija. Una de sus tareas es desarrollar servicios suplementarios basados en el IMS definido mediante el 3GPP. Estos servicios suplementarios serán definidos en especificaciones separadas aunque ellos impactarán las especificaciones de núcleo como pueden ser TS24.229. La Figura 2 demuestra esquemáticamente el flujo de mensaje dentro del IMS para una SIP INVITE, en el lado de origen de la llamada, de acuerdo con TS24.229 (capitulo 5.4.3.2). En el paso 1), la INVITE es enviada desde el Equipo de Usuario de origen (UE) al P-CSCF. Esta INVITE incluye en su encabezado una identidad llamada P-Preferred, así como incluye el URI del P-CSCF en el nivel más alto del encabezado de ruta SIP y el URI del S-CSCF como la entrada secundaria. El UE también incluye la identidad del socio de comunicación en el URI de Solicitud. Tras recibir la INVITE, el P-CSCF verifica que el UE de origen tenga permitido usar la identidad incluida como identidad P-Preferred, y si es así la incluye como la Identidad P-Asserted en la INVITE de salida. La Identidad P-Asserted es una identidad que se usa entre entidades SIP confiables, típicamente intermediarias, para trasportar la identidad del usuario, enviando un mensaje SIP a medida que es verificada por autenticación. El P-CSCF identifica el S-CSCF asignado al UE de origen asegurándolo en el Encabezado de Ruta, y en el paso 2) envía la INVITE corregida a ese S-CSCF.

El S-CSCF maneja la llamada de acuerdo con un procedimiento de caso de llamada de origen. El S-CSCF usa la identidad P-Asserted para verificar si cualquier restricción relevante a sido colocada en el UE de origen, por ejemplo es el UE al que se le impide el uso del servicio solicitado. El S-CSCF también usa la identidad P-Asserted y caso de llamada para determinar los IFC para el UE. En el ejemplo de la Figura 2, se supone que los IFC necesitan que el S-CSCF envíe (paso 3)) la INVITE a un AS particular. EL S-CSCF incluye en el nivel más alto del Encabezado de Ruta SIP el URI del AS. También incluye en el nivel subsecuente su propio URI, junto con un Identificador de Dialogo de Origen (ODI) . El ODI es generado por el S-CSCF y únicamente identifica la llamada al S-CSCF. El AS realizará por sí mismo la autenticación basada en la Identidad P-Asserted contenida en el mensaje (el caso de origen) . El caso adecuado es identificado al AS por medio del S-CSCF (por ejemplo enviando el mensaje a un puerto adecuado del AS) . Cuando el AS regresa la INVITE (paso 4)) al S-CSCF, el AS al que se le quita el URI del AS desde el encabezado de ruta, dejando el URI del S-CSCF junto con la etiqueta ODI . La etiqueta ODI permite al S-CSCF determinar que la INVITE se refiere a un dialogo anterior.

Es posible para la lógica AS necesitar el establecimiento de una sesión nueva, en cuyo caso será necesario proporcionar un mecanismo que permita al AS remplazar el R-URI de origen con el URI del nuevo usuario terminal (el TS existente no proporciona escenario para este re-enrutamiento) en este caso, la identidad del origen, es decir, la identidad P-Asserted de la INVITE en el paso 4), puede ser la identidad del UE de origen, la identidad del AS, o una identidad de una tercera parte en cuyo favor el AS está estableciendo la nueva sesión. En este caso, el S-CSCF repetirá la revisión de restricción de llamada y determinará los IFC basados en la identidad P-Asserted contenida en la "nueva" INVITE, suponiendo que se utiliza el caso de origen. Sin embargo, es posible que el AS pueda señalar al S-CSCF que el caso de terminación se va usar, en cuyo caso la verificación es llevada a cabo usando el R-URI de la INVITE. Suponiendo que ningún AS adicional tenga que ser enlazado basado en los IFC, el S-CSCF envía la INVITE al URI Solicitante (R-URI) contenido en la INVITE. Este puede ser el R-URI contenido en la INVITE de origen, o un R-URI nuevo contenido en la nueva INVITE si es diferente.

La Figura 3 demuestra esquemáticamente el flujo de mensajes dentro del IMS para una INVITE SIP, en el lado terminal de llamada (TS24.229: capitulo 5.4.3.3) en el paso 1), la INVITE llega desde el I-SCSF (no se muestra) incluyendo el R-URI indicando la parte llamada. El S-CSCF utiliza este R-URI para verificar las restricciones colocadas en la parte llamada, y para obtener los IFC. En este caso, los IFC no indican que se necesita contactar un AS. El S-CSCF adquirirá los Encabezados de Ruta pre cargados para la parte llamada, basados en el R-URI, y envía la INVITE hacia el UE basado en estas entradas de Encabezado de Ruta. La INVITE es recibida por el P-CSCF de acuerdo con la ruta precargada en el S-CSCF, y el P-CSCF envía la INVITE al UE de acuerdo con el encabezado de contacto.

La Figura 4 demuestra un escenario de flujo de mensaje de INVITE alternativa, donde una llamada desde una terminal de origen (UE-O) a una terminal semejante (UE-F) es enviada a una terminal de terminación (UE-T) . La acción de enviar la llamada es realizada por medio de un Servidor de Aplicación (AS-F) . El flujo de llamada es como sigue: 1) La INVITE es enviada desde un UE-0 dirigida a UE- F(R-URI) . El S-CSCF O realiza el procedimiento de llamada en el lado de origen como se describe con referencia en la Figura 2. 2) Después de la interacción con el AS-0 (no se hace cambio al R-URI en esta etapa) el S-CSCF O envía la INVITE al I-CSCF (no se muestra) de la red domestica UE-F. El I-CSCF adquirirá la dirección del S-CSCF donde el UE-F está registrado desde el HSS. La INVITE es enviada al S-CSCF, es decir al S-CSCF F. El S-CSCF F revisará el requerimiento de restricción y obtendrá los IFC como se describe anteriormente (para el caso del lado terminal) con referencia a la Figura 3, es decir basado en el R-URI contenido en la INVITE. En el escenario que se demuestra en la Figura 4, la INVITE se enviará al AS-F donde se activará el envió de llamada. 3) El AS-F autorizara el proceso basado en el R-URI (suponiendo el caso de terminación) . 4) El AS-F cambiará entonces el R-URI en el encabezado de la INVITE desde el UE-F al UE-T. La INVITE modificada regresara al S-CSCF F. 5) El S-CSCF F enviará la INVITE al I-CSCF de la red UE-T, y el I-CSCF (no se muestra) interrogará al HSS para obtener la dirección del S-CSCF T del UE-T, y enviará la INVITE al S-CSCF T. 6) El S-CSCF T realizara el procedimiento de terminación como se describe con referencia a la Figura 3, con base en el R-URI contenido en la INVITE (esto es el R-URI del UE-T) .

COMPENDIO DE LA INVENCIÓN Refiriéndonos nuevamente a la Figura 4, en el paso 5) , adicionalmente será necesario para el S-CSCF F si hay alguna restricción en el Usuario que envía, UE F. Para hacer esto, el S-CSCF típicamente usará el procedimiento del lado de origen de la Figura 2. Sin embargo, en ausencia de cual procedimiento especial puesto en práctica mediante el AS-F, la INVITE regresada al S-CSCF F mediante el AS-F incluirá en el campo de identidad P-Asserted la identidad del UE-O. Si el S-CSCF F va a realizar una revisión en el lado de origen en la INVITE utilizando la identidad P-Asserted, el SC-CSCF F será incapaz de localizar un registro para esta identidad ya que no "pertenece" al S-CSCF F (más bien pertenece al S-CSCF O) .

Una solución a este problema podría ser que el AS-F reemplace la identidad P-Asseted del UE-0 con la del UE-F. Sin embargo, es improbable que esto sea aceptado por los operadores que preferirán dejar la identidad P-Asserted sin cambio de extremo a extremo. Desde el punto de vista de los operadores, el campo de identidad P-Asserted es semejante a la identidad de línea de llamada tradicional (PSTN) . Por lo tanto deben buscarse otras soluciones a este problema.

Mientras el usuario que envía típicamente será considerado como un Usuario de origen en el escenario de envío de llamada, no necesita ser el caso, y puede ser considerado como un Usuario terminante. En este caso, cuando el Sc-CSCF F recibe la INVITE desde el AS-F, el S-CSCF querrán realizar una verificación en el lado terminal en la INVITE. (El mensaje enviado desde el AS-F al S-CSCF contendrá un parámetro para indicar al S-CSCF si el mensaje va a ser manejado de acuerdo con el caso terminal o el caso de origen) . Sin embargo, esta revisión también fallará cuando el R-URI contenido en la INVITE identifica el UE-T, y ese R-URI pertenece al S-CSCF T en lugar de al S-CSCF F. Cambiar la identidad P-Asserted por supuesto no solucionará este problema.

Estos problemas surgen con mensajes diferentes a la INVITE, que incluyen, por ejemplo, otros mensajes de solicitud inicial y mensajes independientes.

Es un objetivo de la presente invención superar los problemas identificados anteriormente, mientras evita la necesidad de cambiar la Identidad P-Asserted contenida dentro de un mensaje SIP. Este y otros objetivos se logran introduciendo un nuevo encabezado en los mensajes SIP en el S-CSCF antes de enviarlos a un Servidor de Aplicación, el nuevo encabezado conteniendo el URI del Usuario servido por el S-CSCF y al cual se refiere el mensaje.

De acuerdo con un primer aspecto de la presente invención se proporciona un método de manejo de comunicación de Protocolo de Iniciación de Sesión dentro de un Subsistema Multimedios IP, el método consiste en: recibir un mensaje de Protocolo de Iniciación de Sesión en una Función llamada de servicio/control de estado, sirviendo a un usuario identificado mediante UN R-URI del mensaje; en la Función llamada de servicio/control de estado adicionando al mensaje un encabezado más, este encabezado identificando explícitamente el URI del Usuario servido mediante la Función llamada de servicio/control de estado; enviar el mensaje a un Servidor de Aplicación; y en el Servidor de Aplicación, manejar el mensaje en base a los criterios definidos por el usuario identificado en ese encabezado adicional.

Ese paso de manejar el mensaje en el Servidor de Aplicación puede incluir el cambio del R-URI en el mensaje a un URI de un Usuario al cual está re-enrutado el mensaje, y regresa el mensaje a la Función llamada de servicio/control de estado.

Ese mensaje puede ser enviado directamente a ese Servidor de Aplicación mediante el S-CSCF, o subsiguiente a intercambios del mensaje entre el S-SCSF y uno o otros más Servidores de Aplicación. Los intercambios anteriores pueden introducir modificaciones a los encabezados del mensaje.

Ese paso de manejar el mensaje en base a criterios definidos para el Usuario identificado en ese encabezado adicional puede consistir en obtener criterios de re-enrutamiento para el Usuario Identificado en ese encabezado adicional.

Preferiblemente, el método además consiste en recibir el mensaje en el S-CSCF e identificar el R-URI de origen en base al Identificador de Dialogo de Origen contenido en el mensaje regresado, y determinado los IFC para el Usuario servido en base a ese R-URI . Alternativamente, en el caso de que el mensaje regresado contenga ese encabezado adicional, el S-CSCF puede determinar los IFC basado en el Usuario identificado en el encabezado adicional .

Mientras que la invención es aplicable a cualquier proceso (es decir, Servidor de Aplicación) que maneje el re-enrutamiento de un mensaje, una aplicación particular es que el SIP para enviar llamadas.

Ese encabezado adicional es identificado mediante un identificador de encabezado es entendido tanto por el S- CSCF como por el AS. Típicamente, este encabezado es un prefijo, por ejemplo "P-Served-User Identity".

Preferiblemente, la Identidad P-Asserted es la misma en ambos, el mensaje inicialmente recibido en el S-CSCF y el mensaje regresado desde el servidor de Aplicación al S-CSCF, esta identidad identificando el Usuario de origen.

Ese paso de manejar el mensaje recibido en el Servidor de Aplicación puede consistir en manejar el mensaje de acuerdo con uno de los casos, caso de origen o caso terminal, el caso apropiado siendo identificado en el mensaje recibido en el Servidor de Aplicación desde el S-CSCF, por ejemplo en ese encabezado adicional.

Ese paso de autenticar el Usuario servido en el S-CSCF puede consistir en manejar el mensaje de acuerdo con uno de los casos, caso de origen o caso terminal, el caso apropiado siendo identificado en el mensaje recibido por el S-CSCF desde el Servidor de Aplicación.

De acuerdo con un segundo aspecto de la presente invención se proporciona un Servidor de Aplicación de Protocolo de Iniciación de Sesión de un Subsistema Multimedios IP que tenga medios de procesamiento para manejar el mensaje recibido desde una Función llamada de servicio/control de estado, el medio siendo acomodado para manejar el mensaje basado en encabezado de mensaje que contiene el URI del usuario servido, este encabezado habiendo sido introducido por la Función llamada de servicio/control de estado y siendo diferente de la Identidad P.Asserted y el R-URI .

De acuerdo con un tercer aspecto de la presente invención se proporciona un nodo de Función llamada de servicio/control de estado de un Subsistema Multimedios IP, el nodo de Función llamada de servicio/control de estado contiene medios para recibir un mensaje SIP y para aplicar Criterios de Filtro Inicial al mensaje, y, en el caso de que los Criterios de Filtro Inicial necesitan enviar el mensaje a un Servidor de Aplicación, para adicionar un encabezado al mensaje enviado conteniendo un identidad de un Usuario servido al cual se refiere el mensaje.

De acuerdo con otro aspecto de la presente invención se proporciona un código de programa de computación para llevar a cabo el método del primer aspecto de la invención.

La invención es aplicable en particular a mensajes de solicitud inicial de Protocolo de Iniciación de Sesión, por ejemplo, INVITE, y a mensajes de Protocolo de Iniciación de Sesión independientes, por ejemplo, mensajes relacionados con servicios de presencia.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 demuestra esquemáticamente la integración de un Subsistema Multimedios IP en un Sistema de Comunicaciones Móvil 3G; La Figura 2 demuestra el flujo de una SIP INVITE en el lado de llamada de origen del IMS; La Figura 3 demuestra el flujo de una SIP INVITE en el lado de terminación de llamada del IMS; Y La Figura 4 demuestra el flujo de una SIP INVITE en un escenario de llamada enviada dentro del IMS; La Figura 5 muestra la estructura del encabezado del mensaje para un mensaje de SIP INVITE enviado desde un S-CSCF a un Servidor de Aplicación.

La Figura 6 muestra la estructura del encabezado del mensaje para un mensaje de SIP INVITE enviado desde un Servidor de Aplicación a un S-CSCF; La Figura 7 muestra la estructura del encabezado del mensaje para un mensaje de SIP INVITE enviado desde un S-CSCF a un segundo Servidor de Aplicación; y La Figura 8 demuestra un intercambio de señalización entre las entidades IMS involucradas en la estructura del mensaje de la Figura 7.

DESCRIPCIÓN DETALLADA DE CIERTAS MODALIDADES Los problemas involucrados en el manejo de un escenario "de envío" dentro del Subsistema Multimedios IP se han descrito anteriormente. Es deseable ser capaz de proporcionar un mecanismo para manejar el envío de llamadas que permita tanto al Servidor de Aplicación (AS) como al S-CSCF para autorizar, revisar los requerimientos de restricción, y/o determinar los IFC para el usuario apropiado, es decir, el usuario que es servido por el S-CSCF, y que trata con ambos casos, el caso de terminación y el caso de origen para asegurar la flexibilidad apropiada.

Consideren ahora una INVITE al llegar al S-CSCF F desde algún usuario de origen (UE_0) . La INVITE incluirá en su encabezado un R-URI apuntando a uno de los S-CSCF F de los usuarios registrados (UE-F) , llamado userf_publicl@home2.net. La INVITE también incluye la Identidad P-Asserted del usuario de origen, llamado "John Doe" sip:userl_publicl@homel.net, tel : +1-212-555-1111. El S-CSCF maneja este mensaje usando el caso terminal (identificado por el mensaje que es recibido en un número de puerto particular en la ausencia de una indicación específica dentro del mensaje) , y por lo tanto obtendrán los IFC apropiado basado en el R-URI del mensaje. Uno de estos IFC indicará que el mensaje debe ser enviado a un Servidor de Aplicación.

Tras determinar que el mensaje va a ser enviado a un Servidor se Aplicación, el S-CSCF agregará un encabezado adicional a la INVITE. Este encabezado es mencionado aquí como la "P-Served-User-Identity" y contiene la identidad, SIP-URI, o TEL URL del usuario que es servido mediante EL S-CSCF y del cual el S-CSCF tiene conocimiento. El encabezado también contiene el caso de llamada que se debe aplicar por medio del Servidor de Aplicación. Los ejemplos de encabezados son como sigue: P-Served-User-Identity: sip: alice@homel .net;orig P-Served-User-Identity: sip:bob@home2.net; termunreg P-Served-User-Identity:sip:bob@home2.net; termreg Típicamente, en el caso de llamada enviada, el caso de origen será aplicado. El encabezado P-Served-User-Identity siempre será adicionado al mensaje, sin importar el Servidor de Aplicación al que se va a enviar el mensaje.

El S-CSCF también realizara las operaciones normales para adicionar el SIP URI del AS en el URI mas elevado del Encabezado de Ruta, es decir, sip: asi .ho el .net; Ir, e incluye su propio SIP URI debajo del AS URI en el encabezado de ruta junto con el "identificador de dialogo de origen" (ODI) . La estructura del mensaje de INVITE ejemplar resultante de la Figura 5, donde el URI de el S-CSCF F adicionado al Encabezado de Ruta es "scscf1.homel .net; Ir" y el ODI es ?,cb03a0s09a2sdfglkj 490333" . El mensaje se envía entonces al Servidor de Aplicación sobre la interfaz ISC. EL S-CSCF F mantiene información de estado para la sesión a la cual se refiere la INVITE. Esta información incluye el ODI y la identidad del usuario servido F.

Tras recibir el mensaje de INVITE desde el S-CSCF, el Servidor de Aplicación siempre realizará la autorización basado en la P-Served-User-Identity, de acuerdo con el caso (de origen o terminación) identificado en el mensaje. En el caso en que la llamada enviada se va a realizar, basado en el R-URI contenido en la INVITE, el Servidor de Aplicación remplazará el R-URI de origen con el URI del usuario al cual se va enviar la llamada (UE-T) . En adición, el Servidor de Aplicación adicionará el parámetro "orig" en el encabezado de ruta para indicar que la INVITE va a ser tratada usando el procedimiento tipo llamada de origen. El encabezado de ruta más elevado, es decir el URI del Servidor de Aplicación, es quitado del mensaje, y el mensaje es enviado de regreso al S-CSCF. El mensaje regresado retiene el encabezado de P-Served-User-Identity.

La operación predeterminada del S-CSCF cuando recibe un mensaje conteniendo un encabezado P-Served-User-Identity es realizar la verificación °IFC basada en el Usuario servido contenido en la información de estado correspondiente al ODI del mensaje recibido. (Mientras que la identidad de usuario contenida en el encabezado P-Served-User-Identity puede ser usada para este propósito, es preferible evitar cambiar los procedimientos existentes lo más posible) . El S-CSCF aplicará el caso de terminación o de origen dependiendo del caso identificado en el encabezado de ruta (o basado en el número de puerto en el cual es recibida la INVITE desde el AS) . Típicamente, una INVITE enviada será manejada de acuerdo con el tipo de llamada de origen. (En este ejemplo, el caso contenido en el encabezado P-Served-User-Identity no es usado por el S-CSCF, aunque esto es posible.) En ausencia de un ODI en un mensaje recibido sobre el ISC, el S-CSCF realizará las verificaciones necesarias basadas ya sea en la identidad P-Asserted o en el'R-URI.

Después de terminar la verificación IFC, el S-CSCF procesará la INVITE de acuerdo con los IFC identificados .Esto puede involucrar enviar el mensaje directamente al usuario terminal UE-T, o posiblemente enviarlo a otro Servidor de Aplicación.

En algunos casos, la verificación IFC llevada a cabo en el S-CSCF en respuesta a la recepción de un mensaje SIP (INVITE) sobre la interfaz ISC puede necesitar que el mensaje sea enviado a otro Servidor de Aplicación. Un mensaje de ejemplo enviado a un segundo AS se demuestra en la Figura 7. Otra vez, el encabezado P-Served-User-Identity contiene el URI del Usuario F nombrado userf_publicl@home2.net, mientras que la identidad P-Asserted es la del usuario de origen y el R-URI es el del nuevo usuario terminal. La Figura 8 demuestra el intercambio del mensaje entre el S-CSCF F y dos servidores AS, AS-F 1 y AS-F 2.

Las personas que cuentan con experiencia en la técnica apreciarán que se pueden hacer varias modificaciones a las modalidades descritas anteriormente sin salir del alcance de la presente invención.

Claims (1)

1. REIVINDICACIONES Un método manejar una comunicación de Protocolo de Iniciación de Sesión dentro de un Subsistema Multimedios de IP, el método consiste en: recibir u mensaje de Protocolo de Iniciación de Sesión en una función llamada de Servicio/Control de Estado sirviendo a un usuario identificado por medio de un R-URI del mensaje; en la función llamada de Servicio/Control de Estado, agrega al mensaje un encabezado adicional, este encabezado identifica explícitamente el URI del Usuario servido por medio de la función llamada de Servicio/Control de Estado; enviar el mensaje a un Servidor de Aplicación; y en el Servidor de Aplicación, manejar el mensaje en base a los criterios definidos por el usuario identificado en ese encabezado adicional. El método de acuerdo a la reivindicación 1, en donde el paso para manejar el mensaje en el Servidor de Aplicación incluye cambiar el R-URI en el mensaje a un URI de un usuario al cual el mensaje va a ser re-enrutado, y regresar el mensaje a la función llamada de Servicio/Control de Estado. El método de acuerdo con la reivindicación 1 o 2, en donde el mensaje es enviado directamente a ese Servidor de Aplicación mediante el S-CSCF, o subsiguiente a los intercambios del mensaje entre el S-CSCF y uno o más de otros Servidores de Aplicación. El método de acuerdo con cualquiera de las reivindicaciones precedentes, en donde el paso para manejar el mensaje en base a criterios definidos por el Usuario Identificado en ese encabezado adicional consiste en obtener criterios para re-enrutar para él usuario identificado en ese encabezado adicional. El método de acuerdo con cualquiera de las reivindicaciones anteriores y consiste en recibir el mensaje en el S-CSCF desde el Servidor de Aplicación e identificar el R-URI de origen en base a un Identificador de Dialogo de Origen contenido en el mensaje regresado, y determinar los IFC para el usuario servido en base a ese R-URI . El método de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el manejo del mensaje en el Servidor De Aplicación consiste en poner en práctica un proceso para enviar llamadas. El método de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el encabezado adicional es identificado mediante un identificador de encabezado que es entendido por ambos, el S-CSCF y el AS. El método de acuerdo con cualquiera de las reivindicaciones anteriores y que consiste en regresar el mensaje desde el Servidor De Aplicación al S-CSCF, en donde la identidad P-Asserted en el mensaje inicialmente recibido en el S-CSCF y el mensaje regresado desde el Servidor de Aplicación al S-CSCF es la misma, esta identidad identificando al Usuario de origen. El método de acuerdo con cualquiera de las reivindicaciones anteriores, el paso para manejar el mensaje recibido en el Servidor De Aplicación consiste en manejar el mensaje de acuerdo con un caso, caso de origen o caso de terminación, el caso apropiado siendo identificado en ese encabezado adicional . Un Servidor de Aplicación de Protocolo de Iniciación de Sesión de un Subsistema Multimedios IP tiene medios de procesamiento para manejar un mensaje recibido desde una función llamada de Servicio/Control de Estado, el medio siendo acomodado para acomodar el mensaje basado en un encabezado de mensaje que contiene el URI del usuario servido, este encabezado habiendo sido introducido por la función llamada de Servicio/Control de Estado y siendo diferente de la identidad P-Asserted y el R-URI . Un nodo de Función Llamada de Servicio/Control de Estado de un Subsistema Multimedios IP, la Función Llamada de Servicio/Control de Estado contiene medios para recibir un mensaje SIP y para aplicar Criterios De Filtro Inicial al mensaje, y, en el caso de que los Criterios de Filtro Inicial necesiten enviar el mensaje a un Servidor de Aplicación, para adicionar un encabezado al mensaje enviado conteniendo una identidad de un usuario servido al cual se refiere al mensaje.