TÉCNICA PARA REALIZAR LA CONVERSIÓN DE SEÑALIZACIÓN ENTRE LOS DOMINIOS HTTP Y SIP.

Un método para realizar la conversión de señalización entre una sesión de estado del Protocolo de Transferencia Hipertexto,

o HTTP, y un diálogo del Protocolo de Inicio de Sesiones, o SIP, caracterizado por: - recibir desde una entidad habilitada con HTTP un primer mensaje de petición HTTP, el primer mensaje de petición HTTP que incluye la información de estado HTTP; - crear un primer mensaje SIP en respuesta a la recepción del primer mensaje de petición HTTP, el primer mensaje SIP que pertenece a un diálogo SIP; - enviar el primer mensaje SIP a una entidad habilitada con SIP; y - establecer una asignación entre la información de estado HTTP y el diálogo SIP

Tecnica para realizar la conversi6n de senalizaci6n entre los dominios HTTP y SIP

Campo tecnico La presente invenci6n se refiere de manera general a la conversi6n de senalizaci6n entre los dominios HTTP y SIP. 5 En particular, la invenci6n se dirige a una tecnica de conversi6n que permite una comunicaci6n de estado entre los dos dominios.

Antecedentes En la actualidad, el Protocolo de Transporte de HiperTexto (HTTP) constituye el medio principal para la entrega de contenido en la Web a nivel Mundial (WWW) . El HTTP es un protocolo de capa de aplicaciones sin estado, basado en texto que define un mecanismo de intercambio de mensajes basado en petici6n/respuesta entre un cliente HTTP y un servidor HTTP. En el modelo cliente-servidor HTTP, una petici6n HTTP se emite por un Cliente de Agente de Usuario HTTP, mientras que la respuesta HTTP a la petici6n llega desde un Servidor de Agente de Usuario HTTP.

La demanda creciente de servicios WWW personalizados ha llevado al desarrollo de sesiones de estado HTTP que comprenden dos o mas (nominalmente independientes) parejas de mensajes de petici6n y respuesta HTTP.

Actualmente, los planteamientos dominantes para la administraci6n de sesi6n HTTP son las cookies, los parametros en los Localizadores de Recursos Universales (URL) HTTP y los denominados URL gruesos.

En cuanto a las cookies, el memorando RFC2965 publicado por el Grupo de Trabajo de Ingenieria de Internet (IETF) y titulado "Mecanismo de Gesti6n de Estado HTTP" propone varias cabeceras HTTP capaces de transportar la informaci6n de estado entre los puntos finales de un intercambio de mensajes de petici6n-respuesta HTTP. Las 20 cookies se definen como Pares de Valores de Atributos (AVP) de nombres y valores arbitrarios que se pueden acompanar por una gama de parametros predefinidos como se describe en la RFC2965. En un mensaje de petici6n o respuesta HTTP unico, se pueden incluir una o mas cookies segun se requiera.

Un ejemplo de una petici6n HTTP que contiene cookies es el siguiente:

GET URI HTTP/1.1

Cookie: dialog-id=ali2alice1;method=bye Esta petici6n HTTP contiene dos cookies que identifican colectivamente el estado actual de una sesi6n. La primera cookie define el atributo 'dialog-id' como 'ali2alice1', mientras que la segunda cookie asigna al atributo 'method' el valor 'bye'.

Otra posibilidad para conservar la informaci6n de estado HTTP son los parametros HTTP y los componentes de consulta. Es bien conocido que los esquemas URL basan su sintaxis URL en un formato general de nueve partes (ver RFC2396) :

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<quer y >#<frag>

Usando este formato, es posible transportar la informaci6n de estado de sesi6n a aplicaciones de red remotas o bien como parametros o bien como componentes de consulta. Los listados de c6digo siguientes ilustran dos peticiones HTTP de un cliente HTTP para entregar la informaci6n de estado de sesi6n a un servidor HTTP.

Senalando la informaci6n de estado de sesi6n como parametros HTTP:

GET path;dialog-id=ali2alice1;method=bye HTTP/1.1 host: URI

Senalando la informaci6n de estado como componentes de consulta HTTP:

GET path?dialog-id=ali2alice1&amp;method=bye HTTP/1.1 host: URI

En ambos casos el servidor HTTP es informado de que los valores actuales para los atributos 'dialog-id' y 'method' son 'ali2alice1' y 'bye', respectivamente.

Los URL gruesos son versiones extendidas de los URL, anadidos sufijos con informaci6n usada para identificar el estado actual de una sesi6n HTTP. La siguiente petici6n HTTP ilustra c6mo se puede incluir la informaci6n de estado en la indicaci6n del trayecto en un URL:

45 GET path/dialog-id=ali2alice1/method=bye HTTP/1.1 host: URI

En el ejemplo anterior, el cliente HTTP emite una petici6n a un servidor HTTP que es consciente de que los ultimos dos segmentos del trayecto corresponden a la informaci6n de estado de sesi6n. En este caso particular, el atributo 'dialog-id' es equivalente a 'ali2alice1' y el atributo 'method' es equivalente a 'bye'.

Mientras que HTTP constituye el medio principal para la distribuci6n de contenido en la WWW, el Protocolo de Inicio de Sesiones (SIP) es el protocolo de senalizaci6n principal en el plano de control del IMS (Subsistema Multimedia del Protocolo Internet) y otras redes de aprovisionamiento de servicios. SIP es un protocolo basado en texto usado para autorizar el acceso de usuario asi como establecer, controlar y terminar las sesiones de medios entre las aplicaciones alojadas por los puntos finales habilitados SIP.

Similar a HTTP, SIP se basa en la transmisi6n de mensajes de petici6n y respuesta. Estos mensajes se intercambian entre los Agentes de Usuario instalados en los puntos finales SIP de comunicaci6n. Un Agente de Usuario SIP puede actuar o bien como un Cliente de Agente de Usuario (cuando envia un mensaje de petici6n) o bien como un Servidor de Agente de Usuario (cuando responde al mensaje de petici6n con un mensaje de respuesta) .

SIP define que solamente se puedan establecer una o mas sesiones de medios entre dos puntos finales SIP dentro del contexto de un dialogo SIP. El dialogo es una relaci6n conceptual entre los puntos finales SIP implicados que se mantiene por la Capa de Usuario de Transacci6n de las Capas de Protocolo SIP. En la practica, un dialogo se manifiesta como una colecci6n de informaci6n que refleja el estado actual del dialogo para cada punto final. Como se entiende aqui dentro, cada dialogo SIP comprende una o mas transacciones SIP, y cada transacci6n SIP implica uno o mas mensajes (tipicamente un mensaje de petici6n y uno o mas mensajes de respuesta) . En este sentido, cada mensaje SIP se puede ver como parte de una transacci6n SIP.

Cada dialogo SIP se identifica por un identificador (el denominado ID de dialogo) que esta formado por una serie de atributos negociados entre los puntos finales SIP durante el inicio de una sesi6n y que permanecen validos durante el tiempo de vida del dialogo. Especificamente, el ID del dialogo de un dialogo entre un Cliente de Agente de Usuario y un Servidor de Agente de Usuario (los dos puntos finales de un dialogo SIP) se definen como:

Dialog (-ID) - call-ID, local tag (To-header tag of dialog response) , remote tag (From-header tag of dialog request)

El SIP y los Identificadores de Recursos Universales (URI) de SIP siguen las pautas fijadas por la RFC2396. La forma general de un URI SIP como se define en la RFC3261 tiene la siguiente sintaxis:

sip:user:password@host:port;uri-parameters?headers La estructura URI SIP permite la inclusi6n de varios parametros y cabeceras dentro de su forma generica.

Mientras que HTTP es el protocolo estandar para la entrega de contenido en la WWW, no existe actualmente soluci6n documentada o implementada que permitiria al equipo de usuario habilitado con HTTP iniciar, conducir y terminar sesiones con un Agente de Usuario SIP.

La EP 1093281 describe metodos para la conversi6n del Lenguaje de Marcado de Hipertexto (HTML) -SIP. En un metodo para convertir HTML a SIP, un Agente de Usuario SIP recibe un mensaje HTML, analiza sintacticamente el mensaje HTML para la clase y contenido, y analiza la clase y contenido para crear una senal SIP a partir del mensaje HTML. La senal SIP se envia a un intermediario SIP. Igualmente, se describe un metodo de conversi6n de una senal SIP en un mensaje HTML. Un Agente de Usuario SIP recibe la senal SIP desde un intermediario SIP, analiza sintacticamente la senal SIP para el tipo de mensaje y extrae el contenido, la parte que llama, y la parte llamada. Usando la informaci6n extraida, el Agente de Usuario SIP genera un mensaje HTML y envia el mensaje HTML a la parte llamada.

Resumen Por consiguiente, hay una necesidad para permitir una conversi6n de senalizaci6n eficiente entre los dominios HTTP y SIP que preserve el concepto de sesi6n.

De acuerdo con un primer aspecto, se proporciona un metodo de realizar la conversi6n de senalizaci6n entre una sesi6n de estado HTTP y un dialogo SIP, que comprende recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP; crear un primer mensaje SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje SIP que... [Seguir leyendo]

1. Un metodo para realizar la conversi6n de senalizaci6n entre una sesi6n de estado del Protocolo de Transferencia Hipertexto, o HTTP, y un dialogo del Protocolo de Inicio de Sesiones, o SIP, caracterizado por: -recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP; -crear un primer mensaje SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje SIP que pertenece a un dialogo SIP;

- enviar el primer mensaje SIP a una entidad habilitada con SIP; y -establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP.

2. El metodo de la reivindicaci6n 1, que ademas comprende devolver un primer mensaje de respuesta HTTP a la entidad habilitada con HTTP.

3. El metodo de la reivindicaci6n 1 o 2, que ademas comprende:

- recibir un segundo mensaje SIP;

- determinar el dialogo SIP al cual pertenece el segundo mensaje SIP.

15. determinar la informaci6n de estado HTTP asociada con el dialogo SIP;

- generar un segundo mensaje de petici6n HTTP que incluye o que referencia la informaci6n de estado HTTP determinada de esta manera; y -enviar el segundo mensaje de petici6n HTTP a la entidad habilitada con HTTP.

4. El metodo de la reivindicaci6n 3, que ademas comprende recibir un segundo mensaje de respuesta HTTP en 20 respuesta al segundo mensaje de respuesta HTTP desde la entidad habilitada con HTTP.

5. El metodo de cualquiera de las reivindicaciones precedentes, en el que basado en la informaci6n de estado HTTP la pareja de primeros mensajes de petici6n y respuesta HTTP asi como la pareja de segundos mensajes de petici6n y respuesta HTTP se agrupan en la sesi6n de estado HTTP y/o en el que el primer mensaje de petici6n HTTP ademas incluye informaci6n de direcci6n indicativa de un Agente de Usuario SIP de la entidad habilitada con SIP, y en el que la informaci6n de la direcci6n se usa para dirigir el primer mensaje SIP al Agente de Usuario SIP y/o en el que el primer mensaje de petici6n HTTP ademas incluye informaci6n de dialogo HTTP, y en el que la informaci6n de dialogo HTTP se asigna a la informaci6n de dialogo SIP y/o en el que el primer mensaje de petici6n HTTP ademas incluye informaci6n de descripci6n de sesi6n, y que ademas comprende insertar la informaci6n de descripci6n de sesi6n incluida en el primer mensaje de petici6n HTTP en el primer mensaje SIP.

6. El metodo de la reivindicaci6n 5, en el que la informaci6n de descripci6n de sesi6n se envia en un contexto de ofrecimiento/contestaci6n del Protocolo de Descripci6n de Sesiones, o SDP.

7. El metodo de cualquiera de las reivindicaciones precedentes, en el que la informaci6n de estado se incluye en al menos uno del primer mensaje de petici6n HTTP y el segundo mensaje de petici6n HTTP en forma de al menos uno de una cookie HTTP, un Localizador de Recursos Universal grueso, o URL grueso, un parametro HTTP y una componente de consulta y/o en el que el primer mensaje de petici6n HTTP incluye una indicaci6n de mensaje SIP indicativa de al menos uno de un metodo SIP, un c6digo SIP y un c6digo de estado HTTP.

8. Un metodo para realizar la conversi6n de senalizaci6n entre un dialogo de Protocolo de Inicio de Sesiones, o SIP, y una sesi6n de estado del Protocolo de Transferencia de Hipertexto, o HTTP, caracterizado por: -recibir desde una entidad habilitada con SIP un primer mensaje SIP, el primer mensaje SIP que pertenece a un 40 dialogo SIP;

- establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP; -crear un primer mensaje de petici6n HTTP indicativo de un contenido del primer mensaje SIP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP asignada en el dialogo SIP; y

- enviar el primer mensaje de petici6n HTTP a una entidad habilitada con HTTP.

45 9. El metodo de la reivindicaci6n 8, que ademas comprende recibir un primer mensaje de respuesta HTTP en respuesta al primer mensaje de respuesta HTTP desde la entidad habilitada con HTTP.

10. El metodo de la reivindicaci6n 8 o 9, que ademas comprende

- recibir un segundo mensaje de petici6n HTTP, el segundo mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP y una indicaci6n opcional de un segundo mensaje SIP que va a ser creado;

- determinar el dialogo SIP asignado en la informaci6n de estado HTTP;

- crear un segundo mensaje SIP en respuesta a la recepci6n del segundo mensaje de petici6n HTTP en base a la indicaci6n opcional en el segundo mensaje de petici6n HTTP y el dialogo SIP determinado; y

- enviar el segundo mensaje SIP a la entidad habilitada con SIP.

11. El metodo de la reivindicaci6n 10, que ademas comprende devolver un segundo mensaje de respuesta HTTP a la entidad habilitada con HTTP.

12. El metodo de las reivindicaciones 8 a 11, en el que en base a la informaci6n de estado HTTP la pareja de primeros mensajes de petici6n y respuesta HTTP asi como la pareja de segundos mensajes de petici6n y respuesta HTTP se agrupan en la sesi6n de estado HTTP y/o el metodo que ademas comprende generar la informaci6n de estado HTTP en respuesta a la recepci6n del primer mensaje SIP.

13. El metodo de cualquiera de las reivindicaciones precedentes, en el que la entidad habilitada con HTTP es un equipo de usuario y/o en el que la entidad habilitada con SIP es una entidad del Subsistema Multimedia de Protocolo de Internet (IMS) y/o en el que el dialogo SIP se realiza en uno de un contexto de registro de usuario, un contexto de inicio de sesi6n y un contexto de terminaci6n de sesi6n.

14. Un producto de programa informatico que comprende partes de c6digo de programa para realizar los paso de cualquiera de las reivindicaciones precedentes cuando el producto de programa informatico se ejecuta en un dispositivo informatico.

15. El producto de programa informatico de la reivindicaci6n 14, almacenado en un medio de grabaci6n legible por ordenador.

16. Un aparato (108) para realizar la conversi6n de senalizaci6n entre una sesi6n de estado del Protocolo de Transferencia Hipertexto, o HTTP, y un dialogo del Protocolo de Inicio de Sesiones, o SIP, caracterizado por:

- un Agente de Usuario HTTP (130) adaptado para recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP;

- un Agente de Usuario SIP (132) adaptado para crear y enviar un primer mensaje SIP a una entidad habilitada con SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje SIP que pertenece a un dialogo SIP; y

- una l6gica de asignaci6n (134) adaptada para establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP.

17. El aparato de la reivindicaci6n 16, en el que el aparato se adapta para realizar los pasos de cualquiera de las reivindicaciones 2 a 7.

18. Un aparato (130) para realizar la conversi6n de senalizaci6n entre un dialogo del Protocolo de Inicio de Sesiones, o SIP, y una sesi6n de estado del Protocolo de Transferencia Hipertexto, o HTTP, caracterizado por:

- un Agente de Usuario SIP (132) adaptado para recibir desde una entidad habilitada con SIP un primer mensaje SIP, el primer mensaje SIP que pertenece a un dialogo SIP;

- una l6gica de asignaci6n (134) adaptada para establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP;

- un Agente de Usuario HTTP (130) adaptado para crear y enviar un primer mensaje de petici6n HTTP indicativo de un contenido del primer mensaje SIP a una entidad habilitada con HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP asignado en el dialogo SIP.

19. El aparato de la reivindicaci6n 18, en el que el aparato se adapta para realizar los pasos de cualquiera de las reivindicaciones 9 a 13.