Un servidor de aplicaciones para uso en un Subsistema Multimedia IP para controlar la distribución de medios unidifusión a terminales cliente,

el servidor de aplicaciones que comprende:

un receptor (19) para recibir una petición desde un primer terminal cliente para distribuir medios unidifusión a un segundo terminal cliente;

el servidor de aplicaciones caracterizado porque además comprende:

un procesador y transmisor (20) para enviar un mensaje INVITE del Protocolo de Inicio de Sesiones a dicho segundo terminal cliente, el mensaje INVITE que incluye un Localizador Universal de Recursos, URL, de los medios que identifica una fuente de los medios, y los medios para negociar la identidad de dicho segundo terminal cliente con dicho primer terminal cliente, los medios para negociar que comprenden:

un transmisor para enviar al primer terminal una lista de segundos terminales cliente permitidos; y

un receptor para recibir una selección desde esta lista desde el primer terminal cliente

Distribución de un servicio de flujo continuo de datos unidifusión IP.

Campo técnico

La presente invención se refiere a la distribución de un servicio de flujo continuo de datos unidifusión IP y es aplicable en particular, aunque no necesariamente, para distribuir servicios de IPTV.

Antecedentes

Televisión IP o IPTV es el nombre dado a una gama de servicios que permiten que la televisión sea distribuida sobre una red IP. Debido a la naturaleza flexible de una red IP, IPTV permitirá un servicio mucho más personalizado a los usuarios, por ejemplo vídeo bajo demanda, con la información distribuida a los usuarios sobre secuencias de datos IP unidifusión. No obstante, para ordenar y controlar estos servicios específicos de usuario, el usuario normalmente esperaría usar su control remoto mientras está sentado frente a un receptor multimedia digital (STB)/TV. Actualmente la forma predominante de controlar estas secuencias de datos unidifusión es usar el protocolo de flujo continuo de datos en tiempo real (RTSP). RTSP no especifica un protocolo de transporte pero se puede usar, por ejemplo, para establecer y controlar las secuencias de datos de los medios del protocolo de transporte en tiempo real (RTP). RTSP es en muchas maneras similar al protocolo HTTP usado para solicitar e intercambiar información sobre la Web, pero está adaptado para el flujo continuo de datos de los medios tales como audio y vídeo. RTSP permite a un cliente solicitar secuencias de datos de los medios particulares desde un servidor de flujo continuo de datos, y especifica comandos tales como REPRODUCCIÓN y PAUSA. RTSP es muy adecuado para el caso de uso del receptor multimedia digital convencional.

Se espera que los usuarios de los terminales móviles tales como los teléfonos móviles desearán aprovechar ellos mismos los servicios IPTV. Verdaderamente, esto es probablemente clave para los modelos de negocio de los operadores de red que instalan actualmente redes celulares de alta capacidad tales como las redes 3G. Dentro de las redes celulares, IPTV es un servicio que probablemente se facilitará por el denominado Subsistema Multimedia IP (IMS). IMS es la tecnología definida por el Proyecto de Cooperación de Tercera Generación (3GPP) para proporcionar los servicios Multimedia IP sobre las redes de comunicaciones móviles (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 y TS 29.329 Comunicados 5 a 7), aunque la arquitectura IMS es tal que se puede controlar y acceder a sus servicios a través de otros interfaces, por ejemplo Internet. IMS hace uso del Protocolo de Inicio de Sesiones (SIP) para establecer y controlar las llamadas o sesiones entre los terminales cliente, o los terminales cliente y los servidores de aplicaciones. El Protocolo de Descripción de Sesiones (SDP), transportado por la señalización SIP, se usa para describir y negociar los componentes del medio de la sesión. Mientras que SIP fue creado como un protocolo usuario a usuario, el IMS permite a los operadores y proveedores de servicios controlar el acceso del usuario a los servicios y facturar a los usuarios en consecuencia.

Se apreciará que el IMS y el RTSP tradicionalmente se han considerado como los planteamientos alternativos para el establecimiento y control de las sesiones de flujo continuo de datos unidifusión. Mientras que el IMS proporciona un mecanismo para controlar la QoS y cargar, así como la negociación del transcodificador, el RTSP soporta comandos básicos orientados a vídeo y reproducción de truco.

Un número de sistemas están actualmente en el mercado los cuales permiten a un usuario controlar remotamente un STB sobre Internet. Estos incluyen LocationFreeTV^TM de la Corporación Sony y Slingbox^TM de Sling Media. Ambos de estos sistemas permiten a un usuario instruir la distribución de los medios desde el STB de la casa a un terminal remoto.

La técnica relacionada dentro de este campo además se describe por ejemplo en CAGENIUS T: "Una Pasarela del IMS para la Convergencia de Servicios en Hogares Conectados" 45º CONGRESO DE LA FEDERACIÓN DE INGENIEROS DE TELECOMUNICACIONES DE LA COMUNIDAD EUROPEA (FITCE), 2 de septiembre de 2006, páginas 1-16, EP 1 288 913, revelando una Pasarela del IMS para el Hogar (HIGA) para la convergencia de servicios en una casa conectada, para adaptar la señalización interna, por ejemplo usando el UPnP, para interactuar con el Núcleo del IMS. Otra técnica relacionada se revela en Whitehead y otros: "Una evaluación del Protocolo de Inicio de Sesiones para el uso en Aplicaciones de Flujo Continuo de Datos de los Medios", BORRADOR DE TRABAJO DE ESTÁNDAR IETF, IETF, CH, Febrero de 2006.

Resumen de la invención

Los sistemas actuales disponibles comercialmente tales como LocationFreeTV y Slingbox se diseñan para permitir a un usuario de un terminal remoto, por ejemplo un dispositivo conectado a Internet tal como un teléfono móvil, PDA, u ordenador portátil, para ordenar la distribución de los medios desde el STB del hogar al terminal remoto. No están diseñados para permitir al usuario ordenar la distribución de los medios a algún terminal distinto al que se está usando actualmente, sea en la casa o en otra parte. Incluso si esto fuera posible, implicaría necesariamente el encaminamiento de los medios a través del STB de la casa que provocaría calidad de servicio y elementos de escalabilidad.

Es deseable, por ejemplo, permitir a un usuario hacer uso de un teléfono móvil para ordenar la distribución de los medios a un terminal en la habitación del hotel del usuario u otra ubicación actual, pero esta funcionalidad no se facilita por los sistemas del estado actual de la técnica.

En un primer aspecto de la presente invención hay provisto un servidor de aplicaciones de acuerdo con la reivindicación 1.

De acuerdo con una realización de la invención, el servidor de aplicaciones comprende los medios para terminar un canal de control seguro establecido con dicho segundo terminal cliente. Además se proporcionan los medios para usar dicho canal de control para proporcionar la información de la dirección fuente y destino, para distribuir dichos medios unidifusión, a dicho segundo terminal cliente y a una fuente de medios unidifusión. Preferentemente, dichos medios adicionales usan el Protocolo de Flujo Continuo de Datos en Tiempo Real (RTSP). Dichos medios adicionales se pueden disponer para recibir desde dicho segundo terminal cliente un mensaje RTSP DESCRIBE direccionado a dicho URL de los medios, y entregar este mensaje a las fuentes de los medios.

De acuerdo con una segunda realización de la invención, dicho procesador y transmisor se pueden disponer para incluir en dicha INVITE del Protocolo de Inicio de Sesión una parte del Protocolo de Descripción de Sesión (SDP) que contiene la secuencia de datos de los medios. Además, la parte del SDP puede contener las propiedades de los medios, por ejemplo los formatos de los códec de audio y vídeo. El servidor de aplicaciones comprende los medios para recibir desde el segundo terminal cliente la información del direccionamiento destino para la secuencia de datos de los medios contenida en una parte del Protocolo de Descripción de Sesión de una respuesta 200 OK.

Dicha fuente de medios puede ser cualquier fuente de medios adecuada, por ejemplo un nPVR, un servidor de vídeo bajo demanda, etc.

De acuerdo con un segundo aspecto de la presente invención hay provisto un método como en la reivindicación 9.

En una primera realización, la recepción de INVITE en dicho segundo terminal desencadena una negociación RTSP entre el segundo terminal y una fuente de los medios, a través del servidor de aplicaciones, para establecer la información de direccionamiento fuente y destino para la secuencia de datos de los medios que va a ser entregada. Esta negociación implica el envío de un mensaje RTSP DESCRIBE desde el segundo terminal al servidor de aplicaciones en dicho Localizador Universal de Recursos. El mensaje se distribuye por el servidor de aplicaciones a la fuente de los medios, y la fuente de los medios devuelve una respuesta 200 OK al segundo terminal cliente a través del servidor de aplicaciones. Los mensajes RTSP se pueden enviar sobre un canal de control IP seguro establecido entre el segundo terminal cliente y el servidor de aplicaciones.

El INVITE puede contener una pluralidad de Localizadores Universales de Recursos, que corresponden a las distintas propiedades de los medios. El intercambio de DESCRIBE y 200 OK separado se puede conducir para cada URL, con el segundo terminal cliente...

1. Un servidor de aplicaciones para uso en un Subsistema Multimedia IP para controlar la distribución de medios unidifusión a terminales cliente, el servidor de aplicaciones que comprende:

un receptor (19) para recibir una petición desde un primer terminal cliente para distribuir medios unidifusión a un segundo terminal cliente;

el servidor de aplicaciones caracterizado porque además comprende:

un procesador y transmisor (20) para enviar un mensaje INVITE del Protocolo de Inicio de Sesiones a dicho segundo terminal cliente, el mensaje INVITE que incluye un Localizador Universal de Recursos, URL, de los medios que identifica una fuente de los medios, y los medios para negociar la identidad de dicho segundo terminal cliente con dicho primer terminal cliente, los medios para negociar que comprenden:

un transmisor para enviar al primer terminal una lista de segundos terminales cliente permitidos; y

un receptor para recibir una selección desde esta lista desde el primer terminal cliente.

2. Un servidor de aplicaciones de acuerdo con cualquiera de las reivindicaciones precedentes y que comprende los medios para terminar un canal de control seguro establecido con dicho segundo terminal cliente.

3. Un servidor de aplicaciones de acuerdo con la reivindicación 2 y que además comprende los medios para usar dicho canal de control para proporcionar la información de direcciones fuente y destino para distribuir dichos medios unidifusión, a dicho segundo terminal cliente y a una fuente de medios unidifusión.

4. Un servidor de aplicaciones de acuerdo con la reivindicación 3, dichos medios que además usan el Protocolo de Flujo Continuo de Datos en Tiempo Real, RTSP.

5. Un servidor de aplicaciones de acuerdo con la reivindicación 4, dichos medios que además se disponen para recibir de dicho segundo terminal cliente un mensaje RTSP DESCRIBE direccionado a dicho URL de los medios, y entregar este mensaje a la fuente de los medios.

6. Un servidor de aplicaciones de acuerdo con la reivindicación 4, dicho procesador y transmisor que se disponen a incluir en dicho INVITE del Protocolo de Inicio de Sesiones una parte del Protocolo de Descripción de Sesiones que contiene el flujo continuo de datos de los medios.

7. Un servidor de aplicaciones de acuerdo con la reivindicación 6, dicha parte del Protocolo de Descripción de Sesiones que contiene las propiedades de los medios.

8. Un servidor de aplicaciones de acuerdo con la reivindicación 6 o 7 y que comprende los medios para recibir desde el segundo terminal cliente la información de direccionamiento destino para la secuencia de datos de los medios contenida en una parte del Protocolo de Descripción de Sesiones de una respuesta 200 OK.

9. Un método de ordenar la distribución de una secuencia de datos de los medios unidifusión a un segundo terminal cliente acoplado a una red del Subsistema Multimedia IP, el método que comprende:

enviar una orden de medios unidifusión (paso 8) desde un terminal cliente a un servidor de aplicaciones de dicha red del Subsistema Multimedia IP; y caracterizado por:

enviar un mensaje INVITE del Protocolo de Inicio de Sesiones (paso 14) desde dicho servidor de aplicaciones a dicho segundo cliente en respuesta a la recepción de dicha orden, el mensaje INVITE que contiene un Localizador Universal de Recursos de medios que identifica una fuente de medios;

usar (pasos 16a a 29) dicho Localizador Universal de Recursos para intercambiar la señalización del Protocolo de Flujo Continuo de Datos en Tiempo Real entre dicho segundo terminal cliente y el servidor de aplicaciones para iniciar y controlar la distribución de los medios, y el servidor de aplicaciones y el primer terminal cliente que lleva a cabo un procedimiento de negociación inicial para identificar al servidor de aplicaciones el segundo terminal cliente, en donde el servidor de aplicaciones envía al primer terminal cliente una lista del segundo terminal candidato, y el primer terminal cliente devuelve una selección al servidor de aplicaciones.

10. Un método de acuerdo con la reivindicación 9, en donde la recepción del INVITE en dicho segundo terminal desencadena una negociación RTSP entre el segundo terminal y una fuente de medios, a través del servidor de aplicaciones, para establecer la información de direccionamiento de la fuente y destino para la secuencia de datos de los medios que va a ser entregada.

11. Un método de acuerdo con la reivindicación 10, en donde dicha negociación implica la distribución de un mensaje RTSP DESCRIBE desde el segundo terminal al servidor de aplicaciones en dicho Localizador Universal de Recursos.

12. Un método de acuerdo con la reivindicación 11, en donde el mensaje RTSP DESCRIBE se distribuye por el servidor de aplicaciones a la fuente de los medios, y la fuente de los medios devuelve una respuesta 200 OK al segundo terminal cliente a través del servidor de aplicaciones.

13. Un método de acuerdo con cualquiera de las reivindicaciones 11 a 12, en donde los mensajes RTSP se envía sobre un canal de control IP seguro establecido entre el segundo terminal cliente y el servidor de aplicaciones.

14. Un método de acuerdo con cualquiera de las reivindicaciones 9 a 13, en donde dicho INVITE contiene una pluralidad de Localizadores Universales de Recursos, que corresponden a distintas propiedades de los medios.

15. Un método de acuerdo con la reivindicación 14 cuando se adjunta a la reivindicación 11 y que comprende conducir un intercambio DESCRIBE y 200 OK separado para cada URL, con el segundo terminal cliente que selecciona el Localizador Universal de Recursos apropiado en base a sus propias propiedades.

16. Un método de acuerdo con cualquiera de las reivindicaciones 9 a 14, en donde el servidor de aplicaciones incluye en dicho INVITE una parte del Protocolo de Descripción de Sesiones que identifica la información de direccionamiento fuente para los medios que van a ser distribuidos.

17. Un método de acuerdo con la reivindicación 15, la Parte de Descripción de Sesiones que contiene las propiedades de los medios.

18. Un método de acuerdo con la reivindicación 16 o 17, en donde el segundo terminal cliente devuelve la información de direccionamiento destino en una parte del Protocolo de Descripción de Sesiones en la respuesta 200 OK.

19. Un método de acuerdo con la reivindicación 18, en donde la parte del Protocolo de Descripción de Sesiones del INVITE incluye las propiedades de uno o más secuencias de datos de los medios.