ES2347278T3

ES2347278T3 - Distribucion de un servicio de flujo continuo de datos unidifusion ip.

Info

Publication number: ES2347278T3
Application number: ES06793223T
Authority: ES
Inventors: Torbjorn Cagenius
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2006-09-05
Filing date: 2006-09-05
Publication date: 2010-10-27
Anticipated expiration: 2026-09-05
Also published as: US20100005177A1; EP2060119A1; ATE471037T1; DE602006014887D1; WO2008028515A1; US8326942B2; EP2060119B1

Abstract

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.

Description

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 que selecciona el Localizador Universal de Recursos apropiado en base a sus propias propiedades.

En una realización alternativa, el servidor de aplicaciones puede incluir en dicho INVITE una parte del Protocolo de Descripción de Sesiones que identifica la información de direccionamiento de la fuente para el medio que se va a distribuir. La Parte de Descripción de Sesiones también puede contener las propiedades de los medios, por ejemplo los formatos del códec de audio y vídeo. El segundo terminal cliente entonces devuelve la información de direccionamiento del destino en una parte del Protocolo de Descripción de Sesiones en la respuesta 200 OK. La parte del Protocolo de Descripción de Sesiones del INVITE puede incluir las propiedades de una o más secuencias de datos de los medios.

Breve descripción de los dibujos

La Figura 1 ilustra esquemáticamente una arquitectura de la topología de IPTV;

La Figura 2 ilustra esquemáticamente un IPTV MW AS de la red ilustrada en la Figura 1;

La Figura 3 ilustra esquemáticamente una estación móvil de la red de la Figura 1;

La Figura 4 ilustra un proceso para ordenar remotamente la distribución de una secuencia de datos de los medios unidifusión de acuerdo con una primera realización de la invención; y

La Figura 5 ilustra un proceso para ordenar remotamente la distribución de una secuencia de los medios unidifusión de acuerdo con una segunda realización de la invención.

Descripción detallada

Una breve descripción de la arquitectura y el funcionamiento del Subsistema Multimedia IP (IMS) ayudará en la comprensión de las realizaciones de la presente invención.

Las Funciones de Control de Llamada/Sesión (CSCF) funcionan como intermediarios SIP dentro del IMS. La arquitectura 3GPP define tres tipos de CSCF: el Intermediario CSCF (P-CSCF) que es el primer punto de contacto dentro del IMS para un cliente SIP (que reside típicamente en unos terminales cliente); la CSCF de Servicio (S-CSCF) que proporciona los servicios al usuario a los que el usuario está abonado; y la CSCF de Interrogación (I-CSCF) cuyo papel es identificar la S-CSCF correcta y enviar a esa S-CSCF una solicitud recibida desde un terminal SIP a través de una P-CSCF.

Un usuario se registra con el IMS usando el método especificado SIP REGISTER. Este es un mecanismo para adjuntar al IMS y anunciar al IMS la dirección (IP) en la que se puede alcanzar una identidad de usuario SIP. El usuario recibe un Identificador Uniforme de Recursos (URI) único de la S-CSCF que va a ser usada cuando inicia un diálogo. En 3GPP, cuando un cliente SIP realiza un registro, el IMS autentifica al usuario (usando el procedimiento AKA), y asigna una S-CSCF a ese usuario desde el conjunto de S-CSCF disponibles. Aunque los criterios para asignar una S-CSCF no se especifican por 3GPP, éstos pueden incluir la compartición de carga y los requerimientos del servicio. Cabe señalar que la asignación de una S-CSCF es clave para el control (y para la facturación) del acceso del usuario a los servicios basados en IMS.

Durante el proceso de registro, es responsabilidad de la I-CSCF seleccionar una S-CSCF si no está ya seleccionada una. La I-CSCF recibe las capacidades S-CSCF requeridas desde el Servidor Local de Abonado (HSS) de la red local, y selecciona una S-CSCF apropiada en base a las capacidades recibidas. (Cabe señalar que la asignación de la S-CSCF también se lleva a cabo para un usuario por la I-CSCF en el caso en el que el usuario es llamado por otra parte, y el usuario no está asignado actualmente a una S-CSCF.) Cuando un usuario registrado envía más tarde una petición de sesión (por ejemplo una SIP INVITE) al IMS, la petición incluirá los URI de la P-CSCF y la S-CSCF de manera que la P-CSCF es capaz de enviar la petición a la S-CSCF seleccionada. Esto aplica tanto en el lado de origen como en el de destino (del IMS). (Para una llamada que termina la petición incluirá la dirección P-CSCF y la dirección del Equipo de Usuario (UE).)

Dentro de la red de servicio del IMS, se proporcionan los Servidores de Aplicaciones (AS) para la implementación de la funcionalidad de servicio del IMS. Los AS proporcionan servicios a los usuarios finales en un sistema IMS, y se pueden conectar o bien como puntos finales sobre el interfaz Mr definido 3GPP, o bien "enlazar" por una S-CSCF sobre el interfaz ISC definido 3GPP. En el último caso, se usan los Criterios Iniciales de Filtro (IFC) por la S-CSCF para determinar qué AS se deberían "enlazar" durante un establecimiento de la Sesión SIP. Se pueden aplicar distintos IFC a distintos casos de llamada. Los IFC se reciben por la S-CSCF desde un HSS durante el procedimiento de registro IMS como parte del Perfil de Usuario (UP) del Usuario. Ciertos AS realizarán acciones dependiendo de las identidades de los abonados (ya sea el abonado llamado o el que llama, que es "propiedad" de la red que controla el AS). Por ejemplo, en el caso del desvío de llamadas, el servidor de aplicaciones apropiado (el de terminación) determinará la nueva parte de terminación a la que se enviará una llamada a un abonado dado.

Además de tener los interfaces SIP (ISC o Mr), un AS puede tener uno o más interfaces que no sean SIP. En particular, el interfaz Ut permite a un AS comunicar directamente con un terminal cliente usando, por ejemplo, los protocolos RTSP o HTTP.

La Figura 1 presenta una vista general de la arquitectura IPTV/IMS que ilustra el aparato/funcionalidad proporcionada dentro de una red de local de cliente (CPN) 1 (es decir una casa o una habitación de hotel) y por una Estación Móvil (MS) 2, que se adjuntan respectivamente al IMS 3 a través de una red de acceso fija 4 y una red de acceso inalámbrico 5/red IMS de operador Móvil 6. Los elementos de la red de interés aquí son:

MTRX - Parte de Transmisión/Recepción de los Medios 7, 8; Las funcionalidades "tradicionales" del Receptor Multimedia Digital en un Receptor Multimedia Digital habilitado IMS 9, por ejemplo la recepción de secuencias de datos MPEG2 y/o MPEG4 y la conversión de tales secuencias de datos para la distribución a una TV 10.

IMOD - Módulo IMS e Identidad 11,12; La parte de un Receptor Multimedia Digital habilitado IMS que contiene la lógica básica del servicio del IMS y el ISIM, así como un cliente de aplicaciones. El IMOD también se podría implementar en otros dispositivos en el hogar, por ejemplo la Pasarela Residencial (RGW) 13. El IMOD también se podría implementar en un teléfono móvil, permitiendo el acceso remoto a los servicios de TV.

IPTV MW AS - El Servidor de Aplicaciones SIP de Soporte Lógico Intermedio de IPTV 14; La función que interactúa entre el STB habilitado del IMS y el IMS (y otros dispositivos de usuario IMS) y los servidores de vídeo de IPTV. El IPTV MW AS también recibe y procesa los mensajes HTTP y RTSP.

Servidor de Flujo Continuo de Datos de Vídeo - el servidor de flujo continuo de datos de vídeo 15. Este es la fuente de los medios (flujo continuo de datos) unidifusión.

VoD - Servidor (control) de vídeo bajo demanda 16. Este servidor controla el acceso y la emisión desde los servidores unidifusión de vídeo distribuido.

nPVR - Grabador de Vídeo Personal basado en la red 17. Este servidor permite a los abonados almacenar los medios, por ejemplo programas, dentro de la red. La reproducción se controla a través del IPTV MW AS.

EPG - Guía Electrónica de Programación 18. El servidor EPG almacena los detalles de los medios futuros y disponibles actualmente. Un abonado típicamente descarga la EPG a través del IPTV MW AS y usa éste para seleccionar o programar la distribución de los medios (disponibles en los servidores unidifusión de vídeo/VoD).

MTRX y las entidades IMOD se presentarán dentro de los STB que se usan para acceder al servicio IPTV a través del IMS. Además, y como se ilustra en la Figura 1, estas entidades se presentan dentro de una Estación Móvil (MS) o terminal cliente, que podría ser por ejemplo un teléfono celular. Se apreciará que la MS puede estar presente dentro de una red IMS de un operador que no es el operador del servicio de IPTV.

La Figura 2 ilustra esquemáticamente los elementos funcionales dentro del IPTV MW AS 14. Estos incluyen un receptor 19 acoplado a la red IMS del Operador Móvil 6 y un procesador/transmisor 20 acoplado a la red de acceso fija. La Figura 3 ilustra esquemáticamente los elementos funcionales dentro del IMOD 12 de la MS 2, a saber un transmisor 21 para enviar las peticiones al IPTV MW AS, un receptor 22 para recibir las listas MTRX autorizadas desde el IPTV MW AS, y un procesador/transmisor 23 para aceptar una selección de usuario desde la lista MTRX y enviar ésta al IPTV MW AS.

Un proceso para permitir a un usuario de la MS ordenar la distribución de los medios a algún terminal de tercera parte, situado en la CPN 1, se describirá ahora. Como ya se describió, una entidad IMOD, IMOD1, está presente en la MS. Una segunda entidad IMOD, IMOD2, está presente dentro del STB en la CPN.

Se asume que el usuario se ha registrado en su propia red IMS y ha establecido un canal de control IP seguro con el IPTV MW AS, por ejemplo usando la Seguridad de Capa de Transporte (TLS). Se asume también que el STB de la CPN se registra en la misma o una red IMS distinta y tiene su propio canal de control de seguridad del mismo. Adicionalmente se asume que no se requiere la Traducción de Direcciones de Red (NAT) y la denegación del cortafuegos.

La Figura 4 ilustra un flujo de proceso de acuerdo con un ejemplo ilustrativo. En el paso 1, usando el canal de control de seguridad ya establecido y un interfaz HTTP, el cliente de las aplicaciones dentro del IMOD1 en la MS envía una petición al IPTV MW AS para obtener una lista de grabación del PVR. Esta lista se obtiene por el IPTV MW AS desde el servidor del nPVR, y se devuelve a la MS en el paso 4. En el paso 5 el usuario de la MS selecciona el contenido del PVR requerido y distribuye esta selección al IPTV MW AS.

El IPTV MW AS mantiene o tiene acceso a una lista controlada de usuario de las entidades MTRX aprobadas que pueden recibir los medios a partir de una suscripción IPTV particular. El usuario puede añadir entradas o eliminar entradas desde esta lista usando el canal de control establecido, o sin conexión posible, por ejemplo usando un interfaz web. La lista se distribuye a la MS en el paso 7. El usuario selecciona entonces una entidad MTRX, en este caso el MTRX que corresponde al STB en la CPN, y distribuye ésta al IPTV MW AS en el paso 8 y 9. Los pasos 9 y 10 se refieren a notificar a la MS del coste asociado con el servicio, si tiene alguno, y la aceptación del coste por el usuario de la MS. En el paso 11, se distribuye una página (web) de información a la MS que confirma los detalles de la orden del usuario. Esto finaliza la participación de la MS.

En los pasos 12 y 13, el IPTV MW AS obtiene la URL de vídeo de los medios requeridos desde el nPVR. El IPTV MW AS conoce la entidad de la MTRX a la que los medios van a ser entregados, y envía un SIP INVITE que contiene el URL de vídeo a la MTRX en el paso 14. El INVITE se dirige al IMOD2. El IMOD2 responde en el paso 15 con la respuesta estándar 200 OK. En el paso 16, el IMOD2 distribuye el URL de vídeo a la MTRX del STB, por ejemplo usando el protocolo de transporte UPnP AV donde la MTRX y el IMOD2 están separados físicamente. Asumiendo que el IMOD ya conoce la dirección IP del IPTV MW AS también pasará esta dirección a la MTRX en el paso 16.

En los pasos 16a y 16b, la MTRX envía un RTSP DESCRIBE al servidor del nPVR (a través del IPTV MW AS dado que el canal de control finaliza en el IPTV MW AS) para recuperar las propiedades de los medios del enlace URL de vídeo recibido en el paso previo. El nPVR devuelve un 200 OK a través del IPTV MW AS en los pasos 16c y 16d. El 200 OK contiene las propiedades de los medios requeridas, por ejemplo los formatos de compresión de audio y de vídeo (por ejemplo MPEG2).

Un procedimiento estándar RTSP SETUP se inicia para intercambiar la información de la dirección IP de los medios y el puerto entre el cliente y el servidor. En el paso 17 la MTRX envía el comando RTSP SETUP al IPTV MW AS, que incluye en el comando su dirección IP y los puertos RTP y RTCP donde se espera recibir los medios. En el paso 18, el IPTV MW AS envía la petición al nPVR en base al URL de vídeo en el mensaje RTSP SETUP. En los pasos 19 y 20 la MTRX recibe la confirmación de su información de puerto de los medios y también la dirección IP y los números de puertos en el nPVR donde se originarán los medios.

Los pasos 21 a 29 describen la señalización de control RTSP estándar para la emisión y la terminación de los medios solicitados.

En el paso 14 de la Figura 4 es posible incluir en el SIP INVITE una pluralidad de URL de vídeo cada una que corresponde a un conjunto distinto de propiedades de codificación de vídeo para el mismo contenido. La MTRX debe enviar entonces múltiples mensajes RTSP DESCRIBE (paso 16a) para descubrir qué URL tiene la mejor adaptación. La MTRX seleccionará el URL más apropiado antes de enviar el RTSP SETUP en el paso 17.

La Figura 5 ilustra una realización de la invención que implica la distribución de los medios a un STB tras la petición por una MS y que tiene la ventaja de SIP para negociar los medios antes de proporcionar el URL específico, en base a qué tipo de MTRX está requiriendo un vídeo. Este planteamiento evita la necesidad del intercambio de RTSP DESCRIBE (pasos 16a a 16d de la Figura 4). Los pasos 1 a 11 son como se describieron anteriormente con referencia a la Figura 4. No obstante, en los pasos 12 y 13 el IPTV MW AS recupera del nPVR los detalles del contenido de vídeo seleccionado por el usuario. Estos detalles incluyen el URL de vídeo RTSP así como las propiedades de los medios del contenido de vídeo en la forma del SDP que asume que el nPVR soporta el método RTSP DESCRIBE (de otro modo el nPVR proporcionará los detalles en una forma de lista y el IPTV MW AS construirá un SDP apropiado). Si el contenido de vídeo está disponible en los múltiples formatos de codificación o si el nPVR es capaz de distribuir el contenido de vídeo en múltiples formatos de codificación a través de la transcodificación, esa información también se proporciona, incluyendo múltiples URL de vídeo si es necesario. Una manera de recuperar las propiedades de los medios para cada URL de vídeo es usar el método RTSP DESCRIBE, es decir el nPVR distribuye múltiples URL al IPTV MW AS y el AS devuelve múltiples mensajes DESCRIBE. Alternativamente la información se distribuye en una lista adecuada [URL de vídeo 1: los parámetros de los medios, URL de vídeo 2: los parámetros de los medios, ...] usando por ejemplo HTTP.

En el paso 14, el IPTV MW AS envía un SIP INVITE al IMOD2 que incluye el URL de vídeo y el SDP propuesto, que incluye cualesquiera variaciones de codificación disponibles para el contenido específico. El IMOD2 responde en el paso 15 con un 200 OK que contiene sus propiedades de los medios preferentes en base a las capacidades de la MTRX adaptadas a las opciones en el SDP recibido en el paso 15. El paso 14/15 puede necesitar ser reiterado, específicamente con cualquier nuevo URL de vídeo en base a las propiedades de los medios solicitados. [Por supuesto se asume que el IMOD2 conoce las capacidades de la MTRX para ser capaz de negociar las propiedades de los medios en su nombre].

En el paso 16, solamente se proporciona el URL de vídeo (negociado) a la MTRX. No necesita ser proporcionada la descripción de los medios ya que el URL ha sido seleccionado en base a las propiedades de la MTRX. De nuevo, el protocolo de Transporte UPnP AV se puede usar en el paso 16. El procedimiento estándar RTSP SETUP se lleva a cabo para intercambiar la información de la dirección IP de los medios y del puerto entre el cliente y el servidor. Esto es como se describió anteriormente con referencia a la Figura 5. Los procesos posteriores de reproducción y terminación de los medios también han sido descritos.

Se apreciará por la persona experta en la técnica que se pueden hacer varias modificaciones a las realizaciones descritas anteriormente sin apartarse del alcance del presente invención.

Claims

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.

\newpage

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.