ES2507571T3

ES2507571T3 - Correlacionador de aplicaciones de IMS - no de IMS

Info

Publication number: ES2507571T3
Application number: ES09717791.9T
Authority: ES
Inventors: George Foti
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2008-03-05
Filing date: 2009-03-02
Publication date: 2014-10-15
Anticipated expiration: 2029-03-02
Also published as: AU2009220890B2; TWI462551B; EP2255514A1; JP5379167B2; JP2011524095A; WO2009109901A1; KR101717297B1; CN101960822B; KR20100126789A; AU2009220890A1; CA2717755C; CN101960822A; CA2717755A1; EP2255514B1; US20090225760A1; US8831032B2; BRPI0910427A2; TW200943873A

Abstract

Un método para correlacionar información de aplicación entre una red del Subsistema de Multimedios de Protocolo de Internet, IP, IMS (10) y un nodo no de IMS (2), caracterizado por: - recibir (1102), en una puerta de enlace (4), un primer mensaje que utiliza un primer servicio de señalización desde la citada red de IMS (10); - asociar (1106) el primer mensaje recibido con una de una pluralidad de aplicaciones que se ejecutan sobre el citado nodo no de IMS (2) basándose en la correlación de la información extraída del citado primer mensaje con la información previamente almacenada que asocia mensajes que utilizan el primer protocolo de señalización con una de la pluralidad de aplicaciones, donde la citada información previamente almacenada incluye Localizadores de Recurso Uniforme, URLs (Uniform Resource Locators, en inglés), identificadores de Servicio de Comunicación de IMS, ICSIs (IMS Communication Service Identifiers, en inglés), e IDs de aplicación; y - transmitir (1108) un segundo mensaje hacia el citado nodo no de IMS (2) que utiliza un segundo protocolo de señalización que es diferente del citado primer protocolo de señalización, donde el citado segundo mensaje incluye información asociada con la citada una de una pluralidad de aplicaciones que se ejecutan en el citado nodo no de IMS (2) que está asociado con el citado primer mensaje.

Description

5

10

15

20

25

30

35

40

45

50

55

E09717791

26-09-2014

DESCRIPCIÓN

Correlacionador de aplicaciones de IMS – no de IMS

Campo técnico

La presente invención se refiere en general a sistemas de telecomunicaciones y a mejorar el servicio en los mismos.

Antecedentes

A medida que el nivel de la tecnología aumenta, las opciones para las comunicaciones resultan ser más variadas. Por ejemplo, en los últimos 30 años en la industria de las telecomunicaciones, las comunicaciones personales han evolucionado de una casa que tiene un solo teléfono de dial giratorio a una casa que tiene múltiples líneas de teléfono por cable y/o por fibra óptica que soportan tanto voz como datos. Adicionalmente, los teléfonos móviles y la Wi - Fi han añadido un elemento móvil a las comunicaciones. De manera similar, en la industria del entretenimiento, hace 30 años había sólo un formato para la televisión y este formato era transmitido de manera inalámbrica y recibido a través de antenas situadas en las casas. Esto ha evolucionado en varios estándares de calidad de imagen diferentes tales como, TV de definición estándar (SDTV – Standard Definition TeleVision, en inglés), TV de definición mejorada (EDTV – Enhanced Definition TeleVision, en inglés) y TV de alta definición (High Definition TeleVision, en inglés), y más sistemas para proporcionar estos formatos de visualización de televisión diferentes tales como por cable y por satélite. Adicionalmente, los servicios han llegado a superponerse entre estas dos industrias. A medida que estos sistemas continúan evolucionando en ambas industrias, las ofertas de servicios continuarán fundiéndose y puede esperarse que nuevos servicios estén disponibles para un consumidor. También, estos servicios estarán basados en la capacidad técnica de procesar y proporcionar más información, por ejemplo como se ve en las mejoras en la calidad de la imagen de programas que se ven en las televisiones, y por lo tanto se espera que los requisitos de suministro de servicios continuarán basándose en la mayor disponibilidad de ancho de banda disponible en la red, incluyendo la “última milla” hasta el usuario final.

Otra tecnología relacionada que impacta tanto en las industrias de las comunicaciones como de los entretenimientos es la Internet. Un protocolo que ha sido utilizado con la Internet desde principios de los años 1990 es el Protocolo de Transferencia de Hiper Texto (HTTP – Hyper Text Transfer Protocol, en inglés). Este protocolo es un protocolo basado en la transacción que fue inicialmente diseñado en primer lugar para acceder a páginas de Lenguaje de Marcado de Hiper Texto (HTML – Hyper Text Markup Language, en inglés) y no necesariamente fue diseñado para manejar las estructuras físicas de la Internet y los flujos de comunicación asociados que han evolucionado para manejar un mayor flujo de datos. Por ejemplo, los servidores tienen más memoria que nunca anteriormente, existen enlaces de comunicaciones que tienen un mayor ancho de banda que en el pasado, los procesadores son más rápidos y más capaces y existen protocolos para aprovechar estos elementos. A medida que el uso de la Internet por parte de los consumidores se expande, las empresas de servicios se han vuelto hacia la Internet (y hacia otras redes de Protocolo de Internet (IP – Internet Protocol, en inglés)) como mecanismo para proporcionar servicios tradicionales. Las evoluciones al HTTP, por ejemplo, HTTP 1.1, han mejorado sus capacidades con vistas a esto y varios proveedores de hardware están familiarizados con la integración del HTTP con sus equipos. Existen ahora servicios más nuevos que aprovechan las mejoras previas que incluyen, por ejemplo, televisión sobre IP (IPTV, que se refiere a sistemas o servicios que emiten programas de televisión sobre una red que utiliza paquetes de datos de IP), video bajo demanda (VOD – Video On Demand, en inglés), voz sobre IP (VoIP – Voice over IP, en inglés), y otros servicios relacionados con la web recibidos de manera individual o empaquetados entre sí.

El documento WO 2007/071263 A1 describe la interoperabilidad entre dominios no de IMS y de IMS.

Para soportar las nuevas y diferentes maneras en las cuales se están utilizando las redes de IP para proporcionar varios servicios, se están desarrollando y estandarizando nuevas arquitecturas de red. El Subsistema de Multimedios de IP (IMS – IP Multimedia Subsystem, en inglés) es un marco de arquitectura utilizado para proporcionar servicios de multimedios sobre IP a un usuario final. La arquitectura de IMS ha evolucionado a una topología independiente del servicio que utiliza protocolos de IP, por ejemplo, señalización de Protocolo de Iniciación de Sesión (SIP – Session Initiation Protocol, en inglés) que opera de una manera de igual a igual, para proporcionar un mecanismo de convergencia para sistemas dispares. En parte esto se consigue por medio del suministro de una capa de control horizontal que aísla la red de acceso de la capa de servicio. Entre otras cosas, las arquitecturas de IMS pueden proporcionar una plataforma útil para el despliegue de sistemas y servicios de IPTV.

De acuerdo con esto, las realizaciones de ejemplo que se describen a continuación abordan la necesidad de entidades de red y de métodos que faciliten las comunicaciones entre dispositivos que utilizan diferentes protocolos de señalización.

Compendio

Los sistemas y métodos de acuerdo con la presente invención abordan esta necesidad y otras proporcionando técnicas que facilitan las comunicaciones entre dispositivos que utilizan diferentes protocolos.

Las realizaciones de la invención están definidas por las reivindicaciones adjuntas.

5

10

15

20

25

30

35

40

45

50

E09717791

26-09-2014

Breve descripción de los dibujos

Los dibujos que se acompañan ilustran realizaciones de ejemplo, en las cuales:

la Figura 1 muestra la señalización entre una red del Subsistema de Multimedios de Protocolo de Internet (IMS -Internet Protocol (IP) Multimedia Subsystem, en inglés) y una Función de Terminal de Televisión de Protocolo de Internet (ITF – Internet Protocol Television Terminal Function, en inglés) de acuerdo con las realizaciones de ejemplo;

la Figura 2 representa una ITF que está ejecutando múltiples aplicaciones en comunicaciones con una puerta de enlace de IMS de acuerdo con las realizaciones de ejemplo;

la Figura 3 muestra una puerta de enlace de IMS de acuerdo con las realizaciones de ejemplo;

la Figura 4 muestra una puerta de enlace de IMS que transmite diferentes tipos de mensajes a una ITF de acuerdo con las realizaciones de ejemplo;

la Figura 5(a) muestra una tabla de identificación de aplicación para almacenar información de acuerdo con las realizaciones de ejemplo;

la Figura 5(b) muestra una tabla de tráfico de acuerdo con las realizaciones de ejemplo;

las Figuras 6(a), 6(b), 7, 8(a), 8(b) y 9 son diagramas de señalización para ilustrar la señalización de SIP en una puerta de enlace de IMS para acceder a una aplicación de acuerdo con las realizaciones de ejemplo;

la Figura 10 muestra un nodo de comunicaciones de acuerdo con las realizaciones de ejemplo; y

la Figura 11 muestra un diagrama de flujo del método para correlacionar información de aplicación entre una red de IMS y un nodo no de IMS de acuerdo con las realizaciones de ejemplo.

Descripción detallada

La siguiente descripción detallada de las realizaciones de ejemplo se refiere a los dibujos que se acompañan. Los mismos números de referencia identifican a los mismos o similares elementos. Además, la siguiente descripción detallada no limita la invención. Al contrario, el alcance de la invención está definido por las reivindicaciones adjuntas.

El Protocolo de Transferencia de Hiper Texto (HTTP - Hyper Text Transfer Protocol, en inglés) y el Protocolo de Iniciación de Sesión (SIP – Session Initiation Protocol, en inglés) son protocolos que pueden ser utilizados en soporte del suministro de servicios sobre una red o redes. En algunos casos, los proveedores de hardware, por ejemplo, fabricantes de funciones de terminal de televisión sobre Protocolo de Internet (ITFs – Internet Protocol TeleVision (IPTV) Terminal Functions, en inglés) y otros, pueden utilizar HTTP en sus productos, mientras que los proveedores de servicios que utilizan la arquitectura de red del Subsistema de Multimedios de Protocolo de Internet (IMS – Internet Protocol Multimedia Subsystem, en inglés) para el suministro de servicios, por ejemplo, IPTV, pueden utilizar Protocolo de Iniciación de Sesión (SIP – Session Initiation Protocol, en inglés) en sus productos. El HTTP es un protocolo basado en la transacción, mientras que el SIP es un protocolo basado en la sesión que permite las comunicaciones entre dispositivos que tienen puntos de extremo de SIP. Aunque los sistemas que utilizan HTTP son capaces de recibir algunos servicios asociados a IMS, por ejemplo, que utilizan señalización de HTTP para transportar señalización de IPTV, estos sistemas típicamente no son capaces de utilizar ciertos protocolos que son utilizados en arquitecturas más nuevas, tales como el SIP, que se utiliza en la arquitectura de red de IMS mencionada anteriormente. Los dispositivos que utilizan señalización de SIP y los dispositivos que utilizan señalización de HTTP necesitarán una interfaz, por ejemplo, una puerta de enlace de IMS, para transferir información de un protocolo a otro para un posterior transporte. Este concepto puede ser considerado a un nivel alto con respecto a los componentes de ejemplo mostrados en la Figura 1.

La Figura 1 incluye una ITF 2, una puerta de enlace de IMS 4 y una Red de IMS 10. La ITF 2, que puede ser, por ejemplo, cualquier ITF que cumpla los requisitos de ITF Abierta (OITF - Open ITF, en inglés) tal como los que se encuentran en www.openiptvforum.org y la puerta de enlace de IMS 4 están situadas en el mismo lugar general, por ejemplo, una casa, y se comunican entre sí utilizando señalización de HTTP. La puerta de enlace de IMS 4 se comunica con la red de IMS 10 utilizando señalización de SIP. En esta realización de ejemplo, la red de IMS 10 se muestra con una función de control de sesión de llamada (CSCF – Call Session Control Function, en inglés) 6 que lleva a cabo autenticación y gestión de sesión, y dos servidores de aplicación, por ejemplo, un habilitador de comunicación de igual a igual (P2P – Peer to Peer, en inglés) 14 para intercambio de mensajes y un servidor de red 8 que está asociado con un único localizador de recurso uniforme (URL – Uniform Resource Locator, en inglés). La puerta de enlace de IMS 4 tiene la capacidad de utilizar tanto señalización de HTTP como señalización de SIP así como la capacidad de correlacionar solicitudes de señalización de cualquier lado. De manera más específica, la puerta de enlace de IMS 4 recibe mensajes de SIP y transmite la información utilizando señalización no de SIP, por ejemplo, señalización de HTTP, a las aplicaciones correctas que se están ejecutando en la ITF 2 como se describirá

10

15

20

25

30

35

40

45

50

55

60

E09717791

26-09-2014

en lo que sigue de acuerdo con las realizaciones de ejemplo. Más información relativa a señalización de HTTP puede encontrarse en la Solicitud de Comentarios (RFC – Request For Comments, en inglés) 2616 de fecha Junio de 1999. La red de IMS 10 se muestra en un formato simplificado sólo con ciertos nodos representados para ilustrar el proceso de señalización en las realizaciones de ejemplo que se describen en lo que sigue, no obstante se encuentran típicamente más nodos en una red de IMS 10 y puede encontrarse más detalle relativo a la arquitectura de IMS en general y a la señalización de SIP en la Especificación Técnica (TS – Technical Specification, en inglés)

23.228 de Versión 8 de fecha de Marzo de 2007 del Proyecto de Colaboración de Tercera Generación (3GPP – Third Generation Partnership Project, en inglés) y en la RFC 3261 de fecha de Junio de 2002, respectivamente.

De acuerdo con las realizaciones de ejemplo, como se muestra en la Figura 2, la ITF 2 puede estar correlacionando múltiples aplicaciones, por ejemplo, la aplicación 1 basada en navegador 202, la aplicación 2 basada en navegador 204 y la aplicación 1 basada en nativo 210, así como múltiples instancias de la misma aplicación, por ejemplo, la instancia 1 de la aplicación 3 basada en navegador 206 y la instancia 2 de la aplicación 3 basada en navegador 208. Las aplicaciones basadas en navegador pueden operar en un entorno de aplicación distribuido (DAE – Distribute Application Environment, en inglés) e incluyen, por ejemplo, aplicaciones tales como de presencia y de chat / intercambio de mensajes. Las aplicaciones basadas en nativo pueden operar en aplicaciones integradas en la ITF tales como, registro y gestión de perfil. No obstante, estos ejemplos de aplicación asociados aquí tanto con los basados en navegador como con los basados en nativo son puramente ilustrativos y resultará evidente para los expertos en la materia que nada impide a una aplicación ser desarrollada bien como basada en navegador o como basada en nativo. También como se muestra en la Figura 2, la puerta de enlace de IMS 4 recibe mensajes de SIP 214 que incluyen información que posiblemente pertenece a una de las aplicaciones que se ejecutan en la ITF 2. La puerta de enlace de IMS 4 transmite esta información como notificaciones 212 a la ITF 2 mientras que las notificaciones llegan a las aplicaciones deseadas tal como se describe en lo que sigue.

La puerta de enlace de IMS 4 de ejemplo se describirá ahora con respecto a la Figura 3. La puerta de enlace de IMS 4 hace coincidir mensajes de SIP entrantes 214 de la red de IMS 10 con aplicaciones que se ejecutan en la ITF 2. La puerta de enlace de IMS 4 incluye un encaminador de notificación 302 que es responsable de asegurar esos mensajes de SIP entrantes 214, que están destinados a la ITF 2, son despachados a la aplicación adecuada de la ITF 2. En soporte de esta función, el encaminador de notificación 302 incluye una función de autenticación / gestión de sesión 306, una puerta de enlace de IMS (IG – IMS Gateway, en inglés) - servidor de ITF 304 y un registro 308 de acuerdo con esta realización de ejemplo. La función de autenticación / gestión de sesión 306 se utiliza para la autorización y la gestión de sesión con la red de IMS 10, tanto para ella como para la ITF 2 que incluye sus aplicaciones asociadas. El servidor de IG - ITF 304 transmite mensajes a la ITF 2. El registro 308 incluye información relativa a aplicaciones soportadas en la ITF 2, información de sesión de SIP, información de localizador de recurso uniforme (URL – Uniform Resource Locator, en inglés), por ejemplo, información preconfigurada por la red del operador, que se utiliza para identificar de manera única una aplicación que se ejecuta en la ITF 2 para una correcta correspondencia de los mensajes de SIP entrantes 214 con sus respectivas aplicaciones de ITF. Tanto la función de autenticación / gestión de sesión 306 como el servidor de IG - ITF 304 se comunican con el registro 308 cuando se determina la relación del mensaje de SIP / aplicación de ITF para la transmisión del mensaje. Adicionalmente estas funciones pueden ser utilizadas en rellenar el registro 308 con información según sea necesario. La puerta de enlace de IMS 4 de acuerdo con esta realización de ejemplo es un dispositivo con vigilancia continua que guarda el conocimiento de las aplicaciones que se están ejecutando en la ITF 2 y la información de diálogo de SIP asociada según sea necesario. También, la puerta de enlace de IMS 4 guarda tales estados en su memoria (no mostrada en la Figura 3, pero mostrada en la Figura 10 que se describe a continuación) siempre que la ITF 2 esté alimentada. Aplicaciones, tanto desde el punto de vista de una ITF 2 como de una puerta de enlace de IMS 4, se describirán con más detalle en lo que sigue.

De acuerdo con aplicaciones de ejemplo, múltiples aplicaciones pueden estar operando a la vez en la ITF 2. Como se ha descrito anteriormente, estas aplicaciones pueden ser segregadas en dos categorías generales, por ejemplo, las aplicaciones basadas en DAE y las aplicaciones integradas en ITF, de aplicaciones que ejecutan lógica de servicio en la ITF 2. Desde la perspectiva de la puerta de enlace de IMS 4 (tal como interactúa con la red de IMS 10 que utiliza SIP), estas aplicaciones interactúan con las comunicaciones de SIP de tres maneras diferentes de acuerdo con esta realización de ejemplo dependiendo, por ejemplo, de la existencia de (o de la necesidad de) un diálogo de SIP y de información de estado.

La primera manera de hacer que las aplicaciones interactúen con comunicaciones de SIP de acuerdo con estas realizaciones de ejemplo está asociada con aplicaciones que requieren un diálogo de SIP, por ejemplo, presencia y establecimiento de sesión. Un diálogo de SIP se produce cuando dos entidades con puntos finales de SIP, por ejemplo, la puerta de enlace de IMS 4 y el nodo de IMS, se acoplan en comunicaciones que utilizan SIP. Otras aplicaciones no requieren un diálogo de SIP; son en primer lugar un tipo de transacción independiente de aplicación (intercambio de mensajes instantáneo o registro) en el que no hay necesidad de un diálogo de SIP. Un mensaje de SIP entrante para la puerta de enlace de IMS 4 puede ser considerado como uno de tres tipos de mensajes, por ejemplo, un nuevo mensaje, un mensaje para un diálogo de SIP existente o una respuesta de mensaje a una solicitud iniciada desde una aplicación de la ITF 2, con el propósito del manejo de eventos de acuerdo con una aplicación de ejemplo. Un nuevo mensaje puede, por ejemplo, ser un MENSAJE DE SIP para el cual no existe ningún diálogo de SIP. Un mensaje existente puede, por ejemplo, ser una NOTIFICACIÓN DE SIP que pertenece a un diálogo de SIP existente. Una respuesta de mensaje puede, por ejemplo, ser un SIP 200 OK a una solicitud

10

15

20

25

30

35

40

45

50

55

60

E09717791

26-09-2014

iniciada por la puerta de enlace de IMS 4, por ejemplo, un mensaje de solicitud de servicio originado por la ITF 2 y correctamente modificado / transmitido por la puerta de enlace de IMS 4. Estos tres eventos de notificación manejados de manera diferente se describirán con más detalle en lo que sigue.

De acuerdo con las realizaciones de ejemplo, la puerta de enlace de IMS 4 se comunica con la ITF 2 para proporcionar diferentes tipos de notificaciones sobre la base del tipo de evento de notificación a las aplicaciones apropiadas como se muestra en la Figura 4. Inicialmente, la puerta de enlace de IMS 4 recibe un mensaje de SIP entrante 214. El encaminador de notificación 302 determina qué tipo de evento ha sido recibido. El encaminador de notificación 302 a continuación crea y envía bien una notificación de sesión 414 ó una notificación de terceros 416 a la ITF 2. Típicamente se utilizan las notificaciones en sesión cuando hay una comunicación en curso entre una aplicación activa en la ITF 2 y la puerta de enlace de IMS 4. Las notificaciones de terceros se utilizan típicamente para nuevos mensajes que iniciarán una comunicación con una aplicación de ITF 2 no activa. Si la notificación es una notificación en sesión 414, entonces la notificación es enviada a la aplicación de DAE apropiada, por ejemplo, la Ap 1 de DAE 408 ó la Ap 2 de DAE 412, que se está actualmente ejecutando en la sección de navegador 404 de la ITF 2. Si la notificación es una notificación de terceros 416, entonces la notificación es enviada al agente encargado de notificaciones de terceros 420, que actúa de manera similar a una función de encaminador, en la ITF 2.

El agente encargado de notificaciones de terceros 420 determina a continuación si la notificación recibida necesita ir a una aplicación basada en navegador 402 de DAE, o a una aplicación integrada en ITF 406. Si la notificación tiene que dirigirse a una aplicación basada en navegador 402 de DAE se envía un localizador de recurso uniforme (URL – Uniform Resource Locator, en inglés) al cual el navegador 404 puede acceder para la aplicación basada en navegador 402 de DAE. Si la notificación recibida tiene que ir a una aplicación integrada en ITF 406, la notificación es enviada a través de una interfaz de programación de aplicación (API – Application Programming Interface, en inglés) a la aplicación integrada en ITF 406 para su uso. Adicionalmente, aunque no se muestra en la Figura 4, mensajes, tales como solicitudes de servicio inicial, pueden originarse desde la ITF 2 y ser enviadas a la puerta de enlace de IMS 4 para su transmisión a la red de IMS 10.

Tal como se ha descrito anteriormente, la ITF 2 puede transmitir solicitudes desde aplicaciones activas a la puerta de enlace de IMS 4 utilizando señalización de HTTP. De acuerdo con las realizaciones de ejemplo, para facilitar un correcto rastreo de las aplicaciones, particularmente para la coordinación de mensajes de SIP recibidos en la puerta de enlace de IMS 4, una sola identificación (ID) de aplicación, por aplicación, es insertada en el mensaje de solicitud de HTTP desde la ITF 2 a la puerta de enlace de IMS 4. Estas solicitudes pueden ser generadas tanto para aplicaciones de DAE 408, 412 como para aplicaciones integradas en ITF 406 que se ejecutan en la ITF 2. Para las aplicaciones de DAE 408, 412 y las aplicaciones integradas en ITF 406, la escritura de la Asociación de Fabricantes de Ordenadores Europea (ECMA – European Computer Manufacturers Association, en inglés) puede ser utilizada para insertar la ID de aplicación única en una cabecera o extensión de cabecera de un mensaje de solicitud de HTTP. Estas IDs de aplicación pueden o pueden no estar estandarizadas, pero deben ser únicas para facilitar un apropiado encaminamiento de los mensajes. Un método para asegurar la unicidad incluye que la ID de la aplicación esté representada por un nombre de recurso uniforme de servicio (URN – Uniform Resource Name, en inglés) con ciertas propiedades que describen unicidad. Para más información relativa a los URNs el lector interesado es dirigido hacia la RFC 2141, de fecha de Mayo de 1997. Adicionalmente, podría añadirse un nuevo campo al mensaje de solicitud de HTTP para contener esta ID de aplicación única, tal como se ha indicado anteriormente.

De acuerdo con las realizaciones de ejemplo, una vez que la solicitud de HTTP desde la ITF 2 es recibida por la puerta de enlace de IMS 4, la ID de aplicación única es guardada en la puerta de enlace de IMS 4 junto con el correspondiente diálogo de SIP, y el estado almacenado donde sea aplicable. Adicionalmente, a la recepción de la solicitud de HTTP y la creación del diálogo de SIP, la puerta de enlace de IMS 4 guarda la información dinámica relativa al tipo de notificación para ser utilizado, por ejemplo, notificación de terceros o notificación en sesión, para el diálogo de SIP para el reporte de un evento en curso.

Como se ha descrito anteriormente, la puerta de enlace de IMS 4 almacena la información relativa a las aplicaciones que se ejecutan en la ITF 2 y la información del diálogo de SIP. De acuerdo con las realizaciones de ejemplo, la información de identificación es almacenada en el registro 308 de manera que la información de los mensajes de SIP entrantes 214 puede ser transmitida a la aplicación correcta que se está ejecutando en la ITF 2. Las tablas de ejemplo 500 y 520 se muestran en las Figuras 5(a) y 5(b) respectivamente, para almacenar la información de identificación en el registro 308. La tabla de identificación de aplicación de ejemplo 500 en el registro 308 puede, por ejemplo, ser utilizada por la puerta de enlace de IMS 4 para manejar notificaciones de terceros. De manera más específica, en este ejemplo, la tabla de identificación de aplicación 500 es preconfigurada, típicamente por el proveedor de servicios (SP – Service Provider, en inglés) de manera remota, con las IDs de aplicación para las aplicaciones de DAE proporcionadas por el proveedor de servicios y el URL para ser utilizado para su respectiva aplicación de DAE. Las aplicaciones integradas en ITF, que no necesitan utilizar un URL, se registran en la puerta de enlace de IMS 4 durante el arranque sobre la interfaz de red local – interfaz de puerta de enlace de IMS (HNI -IGI – Home Network Interface – IMS Gateway Interface, en inglés) (no mostrada). El despliegue de ITF 2 incluye una capacidad de visualización y capacidades de interacción del usuario.

Para cada aplicación puede definirse un identificador de servicio de comunicación de IMS (ICSI – IMS Communication Service Identifier, en inglés), que es utilizado por la puerta de enlace de IMS 4 de acuerdo con esta

15

25

35

45

55

E09717791

26-09-2014

realización de ejemplo para asistir a la concordancia de mensajes de SIP entrantes 214 con las aplicaciones y para comprobar si los mensajes de SIP salientes cumplen los requisitos de IMS. En algunos casos, múltiples instancias de la misma aplicación pueden estar operando en la ITF 2 simultáneamente. En soporte de esto, la tabla de tráfico 520 de ejemplo almacena información que permite a la puerta de enlace de IMS 4 distinguir diferentes instancias de una aplicación. Utilizando, en diferentes tiempos, estos diferentes trozos de la información de identificación almacenada en las tablas 500 y 520, la puerta de enlace de IMS 4 puede identificar qué notificaciones o mensajes deben ser encaminados hacia qué aplicaciones (o instancias de aplicaciones) de la ITF 2. La tabla de identificación de aplicación 500 de ejemplo y la tabla de tráfico 520 se describen con más detalle en lo que sigue. También, aunque la tabla de identificación de aplicación 500 y la tabla de tráfico 520 se muestran como dos tablas separadas, podrían estar almacenadas en una única tabla o alternativamente la información podría ser también distribuida, aunque sigue estando asociada, sobre más de dos tablas.

Como se muestra en la Figura 5(a), la tabla de identificación de aplicación 500 guarda una asociación, como se muestra leyendo a través de una fila 502, entre la ID de aplicación 504, los URLs 508 utilizados en la notificación del terceros para una aplicación de DAE y los ICSIs 506 según sea necesario. Adicionalmente, se muestra una aplicación de DAE por defecto que utiliza un URL por defecto, que puede ser utilizado cuando los mensajes de SIP entrantes no incluyen un ICSI o una ID de aplicación (como se muestra mediante la entrada ‘no definido’ en la tabla de identificación de aplicación 500). La tabla de identificación de aplicación 500 proporciona información para utilizar el encaminador de notificación 308 cuando se manejan eventos en los que el mensaje de SIP entrante incluye el ICSI, el ID de aplicación, tanto el ICSI como el ID de aplicación y ni el ICSI ni el ID de aplicación. Esta información junto con otra información es utilizada por la puerta de enlace de IMS 4 para manejar eventos.

De acuerdo con las realizaciones de ejemplo, tal como se muestran en la Figura 5(b), la tabla de tráfico 520 guarda una asociación entre un diálogo de SIP, o información identificativa de una aplicación en cabeceras de SIP específicas de mensajes de SIP entrantes 214 y una instancia de aplicación. Cada asociación se representa en la tabla 520 tal como se muestra mediante cada Entrada 522, 524, 526 donde la Entrada 1 522 podría representar un diálogo de SIP (o información de identificación de una aplicación) asociado a una primera instancia de una aplicación, la Entrada 2 524 podría representar una segunda instancia de la misma aplicación, o una primera instancia de una aplicación diferente y la Entrada 3 526 podría representar una tercera instancia de la misma aplicación, o una primera instancia de una aplicación diferente que actualmente opera en la ITF 2. Una vez que se selecciona una Entrada 522, 524, 526 para el manejo de cualquier mensaje de SIP entrante 214, la Entrada 522, 524, 526 debe contener suficiente información de estado para permitir que la puerta de enlace de IMS 4 identifique de manera única el TCP para ser utilizado para tráfico entrante destinado a la instancia de aplicación asociada. Adicionalmente, utilizar el TCP de esta manera también permite que la puerta de enlace de IMS 4 sepa cuándo ha terminado la instancia de la aplicación, por ejemplo, la conexión de TCP finaliza de una manera apropiada, y permita la recuperación de un error si múltiples enlaces de TCP para diferentes instancias de la misma aplicación finalizan de manera inapropiada, por ejemplo, si múltiples enlaces de TCP se caen de manera abrupta al mismo tiempo. También, de acuerdo con las realizaciones de ejemplo, una información de estado adicional puede ser almacenada en cada Entrada 522, 524, 526 tal como se desee mediante la tabla de tráfico 520.

De acuerdo con las realizaciones de ejemplo, diferentes escenarios de tráfico pueden generar la necesidad de que una Entrada 522, 524, 526 sea creada y almacenada en la tabla de tráfico 520. En un primer escenario, mensajes de tráfico, por ejemplo, y/o de señalización, se originan desde una aplicación en la ITF 2 y son enviados a la puerta de enlace de IMS 4 que requiere que se mantenga un diálogo de SIP. La puerta de enlace de IMS 4 envía una solicitud a la red de IMS 10 para que establezca una sesión y se crea y mantiene un diálogo de SIP. Una Entrada 522, 524, 526 es a continuación creada y almacenada en la tabla de tráfico 520 que asocia la instancia de aplicación con el diálogo de SIP y almacena cualquier otra información de estado deseada, por ejemplo, información de TCP.

De acuerdo con las realizaciones de ejemplo, en un segundo escenario de tráfico, se origina tráfico desde una aplicación de la ITF 2, es enviado a la puerta de enlace de IMS 4 y no requiere la creación y el mantenimiento de un diálogo de SIP. En este escenario, no necesita realizarse una Entrada 522, 524, 526 en la tabla de tráfico 520. Por el contrario, dependiendo de la aplicación de origen en la ITF 2, se crea y almacena un estado de SIP en la memoria en la puerta de enlace de IMS 4 si, por ejemplo, la aplicación de origen es una aplicación de registro (o similar), o bien no se guarda ningún estado después de que se complete con éxito la interacción con la red de IMS 10 si, por ejemplo, la aplicación de origen es una aplicación de intercambio de mensajes instantáneos, una aplicación de transacción independiente (o similar).

De acuerdo con otra realización de ejemplo, en un tercer escenario de tráfico, un mensaje de SIP 214 es recibido por la puerta de enlace de IMS 4 desde la red de IMS 10 para el cual no hay ninguna entrada en la tabla de tráfico. En este escenario, la puerta de enlace de IMS 4 utiliza la tabla de identificación de aplicación 500 para identificar una aplicación apropiada y envía la solicitud a la aplicación apropiada de la ITF 2 como se explica con más detalle en lo que sigue. Dependiendo de la aplicación identificada puede realizarse una Entrada 522, 524, 526 en la tabla de tráfico 520. Por ejemplo, si la aplicación identificada requiere que se mantenga un diálogo de SIP, entonces se crea una Entrada 522, 524, 526 a continuación de la recepción de una respuesta correcta por parte de la puerta de enlace de IMS 4 desde la ITF 2. En otro ejemplo, si la aplicación identificada no requiere que se mantenga un diálogo de SIP, entonces una Entrada 522, 524, 526 no es creada y almacenada en la tabla de tráfico 520. Por el contrario, la transacción se completa y la puerta de enlace de IMS 4 permanece con vigilancia continua hasta el

10

15

20

25

30

35

40

45

50

55

60

E09717791

26-09-2014

momento en que toda la transacción se ha completado correctamente. En otro ejemplo más, si la aplicación identificada no requiere un diálogo de SIP pero le gustaría permanecer activa para mensajes entrantes, puede indicarlo manteniendo su conexión de TCP y entonces se crea y guarda una Entrada 522, 524, 526 en la tabla de tráfico 520.

Así, de acuerdo con las realizaciones de ejemplo, una puerta de enlace de IMS 4 maneja diferentes mensajes de SIP entrantes desde la red de IMS 10 que requieren el envío de una notificación al ITF 2 de diferentes maneras dependiendo de la información disponible para la puerta de enlace de IMS 4. En una primera realización de ejemplo, la puerta de enlace de IMS 4 determina si hay un diálogo de SIP existente previamente asociado con un mensaje de SIP entrante consultando la tabla de tráfico 520. Si hay un diálogo de SIP existente previamente asociado con el mensaje de SIP entrante entonces una sesión de notificación es enviada por la puerta de enlace de IMS 4 sobre el enlace de TCP a la instancia de aplicación apropiada. La notificación enviada incluye la porción de carga útil (o una versión encapsulada) del mensaje de SIP recibido, incluyendo las cabeceras de SIP pertinentes.

La segunda manera de hacer que las aplicaciones interactúen con comunicaciones de SIP está asociada con aplicaciones que no requieren un diálogo de SIP, pero que tienen un estado guardado en el registro de la puerta de enlace de IMS 4, por ejemplo. En otra realización de ejemplo, la puerta de enlace de IMS 4 recibe un mensaje de SIP desde la red de IMS 10 para el cual no hay un diálogo de SIP preexistente. No obstante, en este caso, existe una información de estado almacenada en la tabla de tráfico 520 que permite a la puerta de enlace de IMS 4 identificar la instancia de aplicación prevista, y enviar la notificación a la instancia de aplicación correcta de la ITF 2 sobre el enlace de TCP apropiado utilizando una notificación en sesión para ese propósito. La notificación enviada incluye la porción de carga útil (o una versión encapsulada) del mensaje de SIP recibido, incluyendo las cabeceras de SIP pertinentes.

Esta tercera manera de hacer que las aplicaciones interactúen con comunicaciones de SIP, desde la perspectiva de la puerta de enlace de IMS 4, está asociada con aplicaciones que no requieren un diálogo de SIP y que no requieren un intercambio de mensajes de estado, por ejemplo, e identificación de llamante. En otra realización de ejemplo, la puerta de enlace de IMS 4 recibe un mensaje de SIP desde la red de IMS 10 para el cual no existe ningún diálogo de SIP correspondiente y no existe ninguna información de estado guardada actualmente en la tabla de tráfico 520, por ejemplo, el caso para nuevos mensajes de SIP entrantes desde la red de IMS 10. En este caso, identificar una ID de aplicación requiere consultar la tabla 500 y también depende de los contenidos del mensaje entrante, típicamente los contenidos en la cabecera de SIP de Aceptar – Contacto. De acuerdo con las realizaciones de ejemplo, el campo de Aceptar - Contacto en la cabecera de SIP puede incluir información que permitiría a la puerta de enlace de IMS 4 hacer coincidir el mensaje de SIP con una aplicación que se está ejecutando en la ITF 2. Por ejemplo, el campo de Aceptar – Contacto en una cabecera de SIP podría incluir un URL, una ID de aplicación o un ICSI. Para más información relativa al campo de Aceptar – Contacto en los mensajes de SIP, la cabecera interesada es dirigida a la RFC 3841 de fecha de 2004. Utilizando esta información, la puerta de enlace de IMS 4 entonces conecta el mensaje de SIP a una aplicación en la ITF 2 y envía la notificación utilizando la notificación de terceros para ese propósito. La notificación enviada incluye, además de información seleccionada de la entrada coincidente en la tabla 500, la porción de carga útil (o una versión encapsulada) del mensaje de SIP recibido, incluyendo las cabeceras de SIP pertinentes.

De acuerdo con otra realización de ejemplo más, la puerta de enlace de IMS 4 recibe un mensaje de SIP desde la red de IMS 10 que explícitamente incluye sólo un ICSI, entonces la puerta de enlace de IMS 4 asume y utiliza una ID de aplicación por defecto. La tabla de identificación de aplicación 500 está típicamente rellena con una ID de aplicación por defecto para su uso con cualquier ICSI según sea necesario. Por ejemplo, como se muestra en las filas 514 y 516 de la Figura 5(a), el ICSI1 y el ICSI2 están asociados a una ID de aplicación por defecto. Utilizando esta ID de aplicación por defecto, la puerta de enlace de IMS 4 envía la notificación recibida a la ID de aplicación por defecto de la ITF 2. Adicionalmente, en el caso en el que el mensaje de SIP entrante desde la red de IMS 10 no incluya ni un ICSI ni una ID de aplicación, entonces se utiliza el URL por defecto.

De acuerdo con otra realización de ejemplo, la puerta de enlace de IMS 4 recibe un mensaje de SIP desde la red de IMS 10 que explícitamente incluye tanto un ICSI como una ID de aplicación, entonces la función de encaminador 302 es capaz de ligar la notificación recibida a una aplicación que opera en la ITF 2 consultando la tabla de identificación de aplicación 500. En este caso, la puerta de enlace de IMS 4 envía entonces un mensaje, por ejemplo, notificación de terceros, a la ITF 2 que incluye la información de notificación para enviar a la aplicación identificada. La notificación enviada incluye, además de información seleccionada de la entrada que coincide en la tabla 500, la porción de carga útil (o una versión encapsulada) del mensaje de SIP recibido que incluye las cabeceras de SIP pertinentes.

Después de que la puerta de enlace de IMS 4 recibe un mensaje de SIP y determina si es una notificación en sesión

o una notificación de terceros, la puerta de enlace de IMS 4 transmite la notificación apropiadamente, Por ejemplo, si el mensaje de SIP es una notificación en sesión, tal como es determinado típicamente por la información de estado, la puerta de enlace de IMS 4 envía la información de notificación, utilizando señalización de HTTP u otros esquemas de señalización, a la aplicación apropiada que se está ejecutando en la ITF 2. Si se determina que la notificación es una notificación de terceros la información de notificación es transmitida al agente encargado de notificación de terceros 420 en la ITF 2 que la envía a la aplicación correcta, por ejemplo, una aplicación integrada en la ITF 406 ó

10

15

20

25

30

35

40

45

50

55

60

E09717791

26-09-2014

una aplicación de navegador de DAE 402. El agente encargado de notificación de terceros 420 realiza esta determinación sobre la base de la información recibida en el mensaje de notificación de terceros 416. Inicialmente, el agente encargado de notificación del terceros 420 busca una ID de la aplicación en el mensaje de notificación de terceros 416. Si la ID de la aplicación existe, y no es reconocida por el agente encargado de notificación del terceros 420, entonces se utiliza el URL incluido para buscar una DAE de aplicación de red para manejar la solicitud. En el caso en el que el agente encargado de notificación de terceros 420 reconozca la ID de la aplicación, entonces considera que la aplicación deseada es una aplicación integrada en la ITF 406 y envía la notificación de acuerdo con esto utilizando un API apropiado.

De acuerdo con otras realizaciones de ejemplo, pueden generarse solicitudes desde la ITF 2 que resultan en que un tráfico saliente es transmitido desde la puerta de enlace de IMS 4 a la red de IMS 10. Pueden utilizarse varios métodos para identificar de manera única la aplicación de origen de manera que subsiguientes mensajes de SIP entrantes recibidos puedan ser hechos coincidir con la aplicación deseada. Por ejemplo, si una aplicación de DAE 408, 412, o una aplicación integrada en la ITF 406 origina un mensaje, puede integrar la ID de la aplicación en una nueva cabecera de HTTP que será entonces extraída por la puerta de enlace de IMS 4. Alternativamente, la aplicación de DAE 408, 412, y la aplicación integrada en la ITF 406, pueden incluir un ICSI en una nueva cabecera de extensión de HTTP que puede entonces ser utilizada, junto con información adicional en las cabeceras de SIP, por la puerta de enlace de IMS 4 junto con la tabla de identificación de aplicación 500 para localizar la ID de la aplicación.

Se describirán ahora diagramas de señalización de ejemplo con respecto a las Figuras 6 – 9, que están basados en los sistemas y métodos de ejemplo descritos anteriormente. La Figura 6(a) muestra un diagrama de señalización de ejemplo para la recepción de un mensaje de SIP para iniciar una aplicación de intercambio de mensajes para la cual no hay ninguna aplicación de intercambio de mensajes actualmente activa en la ITF 2. Inicialmente un MENSAJE DE SIP 602, que incluye la información ‘appid = INTERCAMBIO DE MENSAJES' en la cabecera de aceptar – contacto, es transmitido desde el Habilitador de Comunicación P2P 12 a la CSCF 6 que envía el MENSAJE DE SIP 602 a la función de gestión de autenticación / sesión 306 dentro de la puerta de enlace de IMS 4. La puerta de enlace de IMS 4 consulta la tabla de tráfico 520 y ve que no hay ninguna entrada que coincida con el mensaje de SIP entrante. La puerta de enlace de IMS entonces consulta la tabla de identificación de aplicación 500 y localiza la ID de la aplicación basándose en la información de la cabecera de Aceptar – Contacto, por ejemplo, ‘appid = INTERCAMBIO DE MENSAJES', y en la información de la tabla 500 según sea necesario. La función de autenticación / gestión de sesión 306 transmite a continuación un mensaje 604 para invocar la notificación de terceros al servidor de IG - ITF 304. El servidor de IG - ITF 304 entonces envía un mensaje 606 para invocar la notificación de terceros incluyendo una ID de la aplicación (‘appid’) y un URL (obtenidos de la tabla de identificación de aplicación 500) a la ITF 2.

En este ejemplo, el agente encargado de la notificación de terceros 420 en la ITF 2 no reconoce el appid recibido, y en su lugar, la ITF 2 utiliza el URL recibido para buscar la aplicación como se muestra en el mensaje 614. Cuando el servidor de red 8 recibió el mensaje de Obtener URL de HTTP 614, un mensaje de 200 OK que incluye un agente encargado de aplicación de DAE genérico con escritura de ECMA es devuelto a la ITF 2 como se muestra en el mensaje 616. Aproximadamente al mismo tiempo, el servidor de IG – ITF 304 devuelve un resultado de operación 608 da la función de autenticación / gestión de sesión 306. Sobre la base del resultado 608 de la operación, la función de autenticación / gestión de sesión 306 transmite un mensaje de 202 ACEPTADO a la CSCF 6 que a continuación transmite un mensaje de 202 ACEPTADO 612 al habilitador de comunicación P2P 12. Si la aplicación de intercambio de mensajes permanece activa, mantiene la conexión de TCP. La puerta de enlace de IMS 4 crea a continuación una entrada en la tabla de tráfico 520 y guarda una información de estado relativa al SIP y a la aplicación adicional. Esto permite que la aplicación de intercambio de mensajes sea invocada más tarde, utilizando una notificación de sesión en oposición a la utilización de una notificación de terceros en este caso, si un mensaje de SIP entrante está destinado a esa aplicación.

De acuerdo con las realizaciones de ejemplo, la Figura 6(b) muestra un diagrama de señalización de ejemplo para recibir un mensaje de SIP relativo a una aplicación de intercambio de mensajes cuando un DAE de intercambio de mensajes está actualmente activo y se está ejecutando en la ITF 2 y tiene una conexión de TCP permanente con el servidor de IG – ITF 304. Inicialmente un MENSAJE DE SIP 618 que incluye la información ‘appid = INTERCAMBIO DE MENSAJES' en la cabecera de Aceptar – Contacto es transmitido desde el habilitador de comunicación P2P 12 a la CSCF 6 que transmite el MENSAJE DE SIP 618 a la función de autenticación / gestión de sesión 306 dentro de la puerta de enlace de IMS 4. La puerta de enlace de IMS 4 consulta la tabla de tráfico 520 y localiza una entrada en la tabla de tráfico 520 que puede manejar el mensaje de SIP entrante sobre la base de la cabecera de Aceptar – Contacto en el MENSAJE DE SIP 618. Adicionalmente, sobre la base de su capacidad de vigilancia continua, la puerta de enlace de IMS 4 se da cuenta de que la aplicación de mensajes de DAE está actualmente ejecutándose en la ITF 2 y por ello debe utilizarse una notificación en sesión. La función de autenticación / gestión de sesión 306 transmite entonces un mensaje 620 para invocar una notificación en sesión al servidor de IG - ITF 304. El servidor de IG - ITF 304 envía a continuación un mensaje 622 para invocar una notificación en sesión a la ITF 2 que puede utilizar un lenguaje de marcado extensible (XML – eXtensible Markup Language, en inglés). Un mensaje de resultado de operación 624 es entonces enviado desde el servidor de IG - ITF 304 a la función de autenticación / gestión de sesión 306. La función de autenticación / gestión de sesión 306 transmite a continuación un mensaje de

10

15

20

25

30

35

40

45

50

55

60

E09717791

26-09-2014

202 Aceptado 626 a la CSCF 6, la cual transmite a continuación un mensaje de 202 Aceptado 628 al habilitador de comunicación P2P 12.

De acuerdo con las realizaciones de ejemplo, la Figura 7 muestra una señalización de ejemplo cuando la ITF 2 está ejecutando una aplicación de presencia. Inicialmente, un usuario inicia una aplicación de presencia que ha sido previamente buscada y que establece una conexión de TCP con el servidor de IG–ITF 304 para notificaciones de presencia. Esto resulta en una entrada creada en la tabla de tráfico 520, que la puerta de enlace de IMS 4 puede utilizar para hacer coincidir los mensajes de notificación de presencia de SIP relativos al mismo diálogo, que además permite a la puerta de enlace de IMS 4 utilizar una notificación en sesión para transferir mensajes de notificación depresencia entrantes a la aplicación de presencia de la ITF 2. Cuando recibe un mensaje de NOTIFICACIÓN DE SIP 702 que incluye información de presencia desde el habilitador de comunicación P2P 12 a través de la CSCF 6, la puerta de enlace de IMS 4 hace coincidir el mensaje 702 con el diálogo de SIP apropiado de la tabla de tráfico 520, y selecciona la instancia de aplicación apropiada. Adicionalmente, la puerta de enlace de IMS 4 comprende que debe utilizar una notificación en sesión en este caso. La función de autenticación / gestión de sesión 306 asocia entonces un mensaje 704 para invocar una notificación en sesión al servidor de IG – ITF 304. El servidor de IG – ITF 304 envía a continuación un mensaje 706 a la ITF 2 para invocar una notificación en sesión que incluye la NOTIFICACIÓN entrante que puede estar en XML. Un mensaje de resultado de operación 708 es entonces enviado desde el servidor de IG - ITF 304 a la función de autenticación / gestión de sesión 306. La función de autenticación / gestión de sesión 306 a continuación transmite un mensaje de 200 OK 710 a la CSCF 6 que a continuación transmite un mensaje de 200 OK 712 al habilitador de comunicación P2P 12.

De acuerdo con las realizaciones de ejemplo, la Figura 8(a) muestra señalización de ejemplo para un caso de intercambio de mensajes que incluye una aplicación integrada en la ITF. Inicialmente, el habilitador de comunicación P2P 12 transmite un MENSAJE DE SIP 802 que incluye ‘ICSI = INTERCAMBIO DE MENSAJES' en la cabecera de aceptar – contacto a la CSCF 6 que envía el MENSAJE DE SIP 802 a la función de autenticación / gestión de sesión 306 en la puerta de enlace de IMS 4. La puerta de enlace de IMS 4 toma la información en la Aceptar – Contacto, consulta la tabla de tráfico 520 y ve que no hay ninguna entrada que coincida con el mensaje de SIP entrante. La puerta de enlace de IMS consulta entonces la tabla de identificación de aplicación 500 y hace coincidir el ICSI recibido con un ICSI almacenado en la tabla 500 que está asociada a una ID de la aplicación, por ejemplo, encontrada en la misma fila 511 de la tabla 500. La función de autenticación / gestión de sesión 306 transmite un mensaje 804 al servidor de IG - ITF 304 con información para que la ITF 2 invoque la notificación de terceros. El servidor de IG - ITF 304 transmite a continuación un mensaje 806 para invocar la notificación de terceros que incluye una ID de la aplicación a la ITF 2. El agente encargado de la notificación de terceros 420 en la ITF 2 recibe el mensaje 806 y reconoce la ID de la aplicación y la ITF 2 a continuación lanza la aplicación de intercambio de mensajes integrada, por ejemplo, una aplicación integrada en la ITF 406 para el intercambio de mensajes es lanzada en lugar de una aplicación basada en navegador de DAE 402 para el intercambio de mensajes. Un mensaje de resultado de operación 808 es a continuación enviado desde el servidor de IG - ITF 304 a la función de autenticación / gestión de sesión 306. La función de autenticación / gestión de sesión 306 a continuación transmite un mensaje de 202 Aceptado 810 a la CSCF 6 que a continuación transmite un mensaje de 202 Aceptado 812 al habilitador de comunicación P2P 12. La aplicación integrada en la ITF 406 puede elegir permanecer activa y mantener la conexión de TCP, en cuyo caso la puerta de enlace de IMS 4 crea una entrada en la tabla de tráfico 520 que permite que subsiguientes mensajes entrantes destinados a esa aplicación sean entregados utilizando una notificación en sesión.

De acuerdo con las realizaciones de ejemplo, la Figura 8(b) muestra una señalización de ejemplo para recibir un mensaje de SIP relativo a una aplicación de intercambio de mensajes cuando una aplicación de mensajes integrada activa está actualmente ejecutándose en la aplicación de ITF 2 que tiene una conexión de TCP con el servidor de IG

- ITF 304. Inicialmente, un MENSAJE DE SIP 814 que incluye la información ‘ICSI = INTERCAMBIO DE MENSAJES' en la cabecera de Aceptar – Contacto es transmitido desde el Habilitador de Comunicación P2P 12 a la CSCF 6 que envía el MENSAJE DE SIP 814 a la función de autenticación / gestión de sesión 306 dentro de la puerta de enlace de IMS 4. La puerta de enlace de IMS 4 a continuación consulta la tabla de tráfico 520 y localiza una entrada que puede manejar los mensajes entrantes basándose en la información en la cabecera de Aceptar – Contacto en el MENSAJE DE SIP 814. Basándose en su capacidad de vigilancia continua, la puerta de enlace de IMS 4 se da cuenta de que debe utilizarse una notificación en sesión. La función de autenticación / gestión de sesión 306 a continuación transmite un mensaje 816 para invocar la notificación en sesión al servidor de IG - ITF 304. El servidor de IG - ITF 304 entonces envía un mensaje 818 a la ITF 2 para invocar una notificación en sesión que incluye información que puede estar en XML. Un mensaje de resultado de operación 820 es a continuación enviado desde el servidor de IG - ITF 304 a la función de autenticación / gestión de sesión 306. La función de autenticación / gestión de sesión 306 a continuación transmite un mensaje de 202 Aceptado a la CSCF 6 que entonces transmite un mensaje de 202 Aceptado 822 a la CSCF 6 que a continuación transmite un mensaje de 202 Aceptado al habilitador de comunicación P2P 12.

De acuerdo con las realizaciones de ejemplo, la Figura 9 muestra señalización de ejemplo para recibir un mensaje de SIP que no incluye una ID de aplicación o un ICSI en la puerta de enlace de IMS 4. Inicialmente, un habilitador de comunicación P2P 12 transmite un mensaje de PUBLICAR SIP 902 a la CSCF 6 que envía el mensaje de PUBLICAR SIP 902 a la función de autenticación / gestión de sesión 306 en la puerta de enlace de IMS 4. La puerta de enlace de IMS 4 se da cuenta de que el mensaje de PUBLICAR SIP 902 recibido carece tanto de una ID de

15

25

35

45

55

E09717791

26-09-2014

aplicación como de un ICSI en la cabecera de Aceptar – Contacto, y por ello no consulta la tabla de tráfico 520, y en su lugar consulta la tabla de identificación de aplicación 500, y toma la aplicación de la tabla 500 que tiene el URL por defecto. La función de autenticación / gestión de sesión 306 transmite un mensaje 904 para invocar la notificación de terceros al servidor de IG - ITF 304. El servidor de IG - ITF 304 a continuación envía un mensaje 906 para invocar la notificación de terceros que incluye el URL por defecto obtenido de la tabla 500. La ITF 2 recibe el mensaje 906 y el agente encargado de la notificación de terceros 420 no ve una ID de aplicación y por el contrario utiliza el URL suministrado para buscar una aplicación de DAE para manejar esta solicitud tal como se muestra en el mensaje de Obtener URL de HTTP 908 que es enviado al servidor de red 8. El servidor de red 8 responde a la ITF 2 con un mensaje de 200 OK 910 que incluye un agente encargado de aplicación por defecto de DAE (que típicamente incluye algún lenguaje de marcado de hiper texto extensible (XHTML – eXtensible Hyper Text Markup Language, en inglés) e instrucciones en escritura de ECMA). Un mensaje de resultado de operación 912 es a continuación enviado desde el servidor de IG - ITF 304 a la función de autenticación / gestión de sesión 306. La función de autenticación / gestión de sesión 306 a continuación transmite un mensaje de 200 OK 914 a la CSCF 6 que a continuación transmite un mensaje de 200 OK 916 al habilitador de comunicación P2P 12.

De acuerdo con las realizaciones de ejemplo que utilizan los sistemas y métodos descritos anteriormente, la puerta de enlace de IMS 4 puede tener la capacidad de llevar a cabo una recuperación de error para varios errores, tales como, la pérdida de múltiples enlaces de TCP con la ITF 2. En este caso, en el que múltiples instancias de aplicación están actualmente activas en la ITF 2, cada instancia de la aplicación tendrá un enlace de TCP diferente listo para comunicación con la puerta de enlace de IMS 4. Estos enlaces de TCP serán siempre que la instancia de la aplicación esté activa y ejecutándose. Cuando un enlace de TCP se cae. La puerta de enlace de IMS 4 detecta la pérdida del enlace de TCP y espera, por ejemplo, durante aproximadamente 40 – 60 segundos, basándose en un temporizador configurable a que la instancia de aplicación restablezca un nuevo enlace para permitir que la puerta de enlace de IMS 4 actualice la Entrada 522, 524, 526 adecuada en la tabla de tráfico 520.

De acuerdo con las realizaciones de ejemplo, si el temporizador asociado con el restablecimiento del enlace de TCP expira, la puerta de enlace de IMS 4 asume que la instancia de la aplicación ha terminado y procede a terminar las correspondientes comunicaciones del lado de la red y a eliminar esa Entrada 522, 524, 526 de la tabla de tráfico

520. Si la instancia de la aplicación no ha terminado, típicamente enviará a su pareja, como parte del restablecimiento del enlace de TCP, que es equivalente a una ACTUALIZACIÓN DE SIP, que no cambia ninguna información de estado de SIP sino que por el contrario permite que la puerta de enlace de IMS 4 maneje la recuperación de error en el caso de múltiples fallos de enlace. En este caso de múltiples fallos de enlace para múltiples instancias de la misma aplicación, la puerta de enlace de IMS 4 puede utilizar información en un mensaje de ACTUALIZACIÓN DE SIP junto con la información de estado almacenada en la tabla de tráfico 520 para identificar de manera única la instancia de aplicación prevista y permitir una correcta recuperación del error.

Las realizaciones de ejemplo descritas anteriormente proporcionan mensajes y protocolos que implican las comunicaciones de persona a persona. Se describirá ahora con respecto a la Figura 10 un nodo de comunicaciones 1000 de ejemplo que puede realizar las funciones de una puerta de enlace de IMS 4. El nodo de comunicaciones 1000 puede contener un procesador 1002 (o múltiples núcleos de procesador), una memoria 1004, uno o más dispositivos de almacenamiento secundario 1006 y una unidad de interfaz 1008 para facilitar las comunicaciones entre el nodo de comunicaciones 1000 y otras redes y dispositivos. La memoria 1004 y/o los dispositivos de almacenamiento secundario 1006 pueden ser utilizados para almacenar tanto información de estado como también las tablas 500 y 520. Lógica y protocolos pueden ser también contenidos dentro del nodo de comunicaciones 1000 para ser utilizados con el procesador 1002 para determinar el tipo de notificación así como todas las demás funciones de ejemplo descritas anteriormente llevadas a cabo por la puerta de enlace de IMS 4.

Utilizando los sistemas de ejemplo descritos anteriormente de acuerdo con las realizaciones de ejemplo, un método para facilitar las comunicaciones entre dispositivos que utilizan diferentes protocolos se muestra en el diagrama de flujo de la Figura 11. Inicialmente, un método para correlacionar información de aplicación entre una red del Subsistema de Multimedios de Internet (IMS – Internet Multimedia Subsystem, en inglés) y un nodo no de IMS incluye: recibir, en una puerta de enlace, un primer mensaje utilizando un primer protocolo de señalización en una puerta de enlace de una red de IMS en la etapa 1102; leer la información del primer mensaje en la etapa 1104; correlacionar la información con la información previamente almacenada con el fin de determinar cuál de una pluralidad de aplicaciones que se están ejecutando en el nodo no de IMS está asociada con el primer mensaje en la etapa 1106; y transmitir un segundo mensaje hacia el nodo no de IMS utilizando un segundo protocolo de señalización que es diferente del primer protocolo de señalización, donde el segundo mensaje incluye información asociada con la una de una pluralidad de aplicaciones que se están ejecutando en el nodo no de IMS que está asociado con el primer mensaje de la etapa 1108.

Como resultará evidente para los expertos en la materia, métodos tales como los ilustrados en la Figura 11 pueden ser implementados completa o parcialmente en software. Así, los sistemas y métodos para el procesamiento de datos de acuerdo con las realizaciones de ejemplo de la presente invención pueden ser ejecutados mediante uno o más procesadores que ejecutan secuencias de instrucciones contenidas en un dispositivo de memoria. Tales instrucciones pueden ser leídas en el dispositivo de memoria 1004 de otros medios legibles por ordenador tales como dispositivo o dispositivos de almacenamiento de datos secundarios, que pueden ser medios fijos, extraíbles o remotos (almacenamiento en red). La ejecución de las secuencias de instrucciones contenidas en el dispositivo de

E09717791

26-09-2014

memoria hace que el procesador opere, por ejemplo, como se ha descrito anteriormente. En realizaciones alternativas, pueden utilizarse circuitos de hardware en lugar de o en combinación con instrucciones de software para implementar realizaciones de ejemplo.

Las realizaciones de ejemplo descritas anteriormente pretenden ser ilustrativas en todos los aspectos, en lugar de

5 restrictivas, de la presente invención. Por ejemplo, múltiples ITFs 2 pueden estar en comunicación con la puerta de enlace de IMS 4 en una única vivienda y en este caso la puerta de enlace de IMS 4 es aún capaz de identificar de manera única las aplicaciones de cualquier ITF 2 que esté en comunicación con ella mediante, por ejemplo, el almacenamiento de información adicional en las tablas 500 y 520 que referencian la ITF sobre la cual se está ejecutando una aplicación. Adicionalmente, los servicios de ejemplo descritos anteriormente son puramente

10 ilustrativos y otros servicios de IMS pueden ser soportados mediante los sistemas y métodos descritos anteriormente. Ningún elemento, acto o instrucción debe ser considerado como crítico o esencial para la invención a menos que se describa explícitamente como tal. Además, tal como se utiliza en esta memoria, los artículos “un” o “una” pretenden incluir uno o más elementos.

Claims

5

10

15

20

25

30

35

40

45

50

E09717791

26-09-2014

REIVINDICACIONES

1. Un método para correlacionar información de aplicación entre una red del Subsistema de Multimedios de Protocolo de Internet, IP, IMS (10) y un nodo no de IMS (2), caracterizado por:

-

recibir (1102), en una puerta de enlace (4), un primer mensaje que utiliza un primer servicio de señalización desde la citada red de IMS (10);

-

asociar (1106) el primer mensaje recibido con una de una pluralidad de aplicaciones que se ejecutan sobre el citado nodo no de IMS (2) basándose en la correlación de la información extraída del citado primer mensaje con la información previamente almacenada que asocia mensajes que utilizan el primer protocolo de señalización con una de la pluralidad de aplicaciones, donde la citada información previamente almacenada incluye Localizadores de Recurso Uniforme, URLs (Uniform Resource Locators, en inglés), identificadores de Servicio de Comunicación de IMS, ICSIs (IMS Communication Service Identifiers, en inglés), e IDs de aplicación; y

-

transmitir (1108) un segundo mensaje hacia el citado nodo no de IMS (2) que utiliza un segundo protocolo de señalización que es diferente del citado primer protocolo de señalización, donde el citado segundo mensaje incluye información asociada con la citada una de una pluralidad de aplicaciones que se ejecutan en el citado nodo no de IMS (2) que está asociado con el citado primer mensaje.
2.

El método de la reivindicación 1, en el que la citada puerta de enlace (4) utiliza diálogo de SIP para la citada una de una pluralidad de aplicaciones que se ejecutan en el citado nodo no de IMS (2) que está asociada con el citado primer mensaje.
3.

El método de la reivindicación 2, que comprende además:

-

recibir un subsiguiente mensaje que es para la citada una de una pluralidad de aplicaciones que se ejecutan en el citado nodo no de IMS (2) que está asociado con el citado primer mensaje; y

-

transmitir un mensaje de notificación en sesión hacia el citado nodo no de IMS (2).
4.

El método de la reivindicación 1, en el que la citada puerta de enlace (4) tiene un estado guardado en una memoria para la citada una de una pluralidad de aplicaciones que se ejecutan en el citado nodo no de IMS (2) que está asociado con el citado primer mensaje.
5.

El método de la reivindicación 1, en el que la citada puerta de enlace (4) no tiene vigilancia continua para la citada una de una pluralidad de aplicaciones que se ejecutan en el citado nodo no de IMS (2) que está asociado con el citado primer mensaje.
6.

El método de la reivindicación 1, en el que el citado primer mensaje es un mensaje de Protocolo de Iniciación de Sesión, SIP (Session Initiation Protocol, en inglés), que incluye la citada información en una cabecera de contacto

– aceptación.
7.

El de acuerdo con de la reivindicación 6, en el que la citada información es al menos uno de un Localizador de Recurso Uniforme, URL. (Uniform Resource Locator, en inglés), y un Identificador de Servicio de Comunicación de IMS, ICSI (IMS Communication Service Identifier, en inglés).
8.

El método de la reivindicación 1, en el que el citado segundo protocolo de señalización es el Protocolo de Transferencia de Hiper Texto, HTTP (Hyper Text Transfer Protocol, en inglés).
9.

El de acuerdo con de la reivindicación 1, que comprende además:

- recibir un segundo mensaje que utiliza el citado segundo protocolo de señalización desde el citado nodo no de IMS

(2) que incluye una identificación de aplicación, ID, en la que el citado segundo mensaje es un mensaje de solicitud de HTTP.
10.

El método de la reivindicación 1, en el que cada instancia de la citada una de una pluralidad de aplicaciones está identificada de manera única.
11.

El método de la reivindicación 10, en el que la citada identificación única se crea a partir de una concatenación de una identificación de la aplicación con un troceado (hashing, en inglés) de un protocolo de control de transmisión, TCP (Transmission Control Protocol, en inglés).
12.

El método de la reivindicación 10, en el que se crean entradas para la citada tabla mediante al menos uno de recibir un mensaje que se origina desde una primera aplicación que requiere que se mantenga un diálogo de SIP y se reciba un mensaje de SIP que está asociado con una segunda aplicación que requiere que se mantenga un diálogo de SIP.
13.

El método de la reivindicación 1, que comprende además:

12

E09717791

26-09-2014

-

establecer un diálogo de SIP tras recibir el citado primer mensaje;

-

almacenar información adicional que conecta el citado diálogo de SIP y la citada aplicación; y

-

utilizar una notificación en sesión para mensajes subsiguientemente recibidos desde la citada red de IMS que son asociados con la citada aplicación sobre la base de la citada información adicional almacenada.

5 14. El método de la reivindicación 1, que comprende además;

-

establecer un protocolo de control de transmisión, TCP (Transmission Control Protocol, en inglés), en conexión con el citado nodo no de IMS tras la iniciación de la citada aplicación; y

-

terminar la citada conexión de TCP con el citado nodo no de IMS después de que la citada aplicación es desactivada.

10 15. El método de la reivindicación 1, en el que el ciado nodo no de IMS es una función de terminal de televisión de Protocolo de Internet, ITF (Internet Protocol Television Terminal Function.
16.

El método de la reivindicación 1, en el que la citada aplicación es al menos una de una aplicación de entorno de aplicación distribuida, DAE, y una aplicación de ITF integrada.
17.

Un dispositivo de puerta de enlace (4; 1000) que comprende:

15 - una interfaz de comunicación (1008) para transmitir y recibir mensajes, caracterizada porque un primer mensaje recibido que utiliza un primer protocolo de señalización de una red de IMS (10) incluye información asociada con una aplicación;

- una memoria (308; 1004) para almacenar información que incluye identificaciones, IDs, de aplicación,

Localizadores de Recurso Uniforme, URLs (Uniform Resource Locators, en inglés), información por defecto e 20 identificadores de Servicio de Comunicación de IMS, ICSIs (IMS Communication Service Identifiers, en inglés); y

- un procesador (1002) para correlacionar el citado primer mensaje recibido que utiliza el citado primer protocolo de señalización con la información almacenada en la memoria para asociar el mensaje con una de una pluralidad de aplicaciones que se ejecutan en un nodo no de IMS (2) a la cual encaminar un segundo mensaje que utiliza un segundo protocolo de señalización diferente del citado primer protocolo de señalización, donde el citado segundo

25 mensaje que utiliza el citado segundo protocolo de señalización incluye información asociada con la citada una de una pluralidad de aplicaciones.

13