ES2550949T3 - Gestión de canal de medios - Google Patents
Gestión de canal de medios Download PDFInfo
- Publication number
- ES2550949T3 ES2550949T3 ES10165338.4T ES10165338T ES2550949T3 ES 2550949 T3 ES2550949 T3 ES 2550949T3 ES 10165338 T ES10165338 T ES 10165338T ES 2550949 T3 ES2550949 T3 ES 2550949T3
- Authority
- ES
- Spain
- Prior art keywords
- media
- channel
- request
- content
- user terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 claims abstract description 76
- 230000032258 transport Effects 0.000 claims description 27
- 230000005540 biological transmission Effects 0.000 claims description 23
- 230000004044 response Effects 0.000 description 57
- 238000010586 diagram Methods 0.000 description 20
- 238000004891 communication Methods 0.000 description 16
- 230000011664 signaling Effects 0.000 description 13
- 230000008569 process Effects 0.000 description 11
- 230000007723 transport mechanism Effects 0.000 description 9
- 238000013459 approach Methods 0.000 description 8
- 238000007726 management method Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000007704 transition Effects 0.000 description 5
- 230000003466 anti-cipated effect Effects 0.000 description 3
- 238000010420 art technique Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000005465 channeling Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 230000003292 diminished effect Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000030279 gene silencing Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000033764 rhythmic process Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
- H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
- H04N21/4383—Accessing a communication channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
- H04N21/4383—Accessing a communication channel
- H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6408—Unicasting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
- H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
Abstract
Un método realizado en un terminal de usuario (100), de conmutación de canal de medios en una sesión de medios basada en unidifusión que implica a dicho terminal de usuario (100) que recibe un primer contenido de medios de un primer canal de medios desde un servidor de medios (200) que proporciona dicho primer canal de medios y un segundo canal de medios, caracterizado por dicho terminal de usuario (100) que transmite, a dicho servidor de medios (200), una petición de representación de contenido específico en forma de una petición REPRODUCIR del Protocolo de Difusión de Forma Continua en Tiempo Real, RSTP, para un segundo contenido de medios de dicho segundo canal de medios durante dicha sesión de medios basada en unidifusión en curso, en donde dicha petición REPRODUCIR de RTSP comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios.
Description
10
15
20
25
30
35
40
45
50
55
60
E10165338
22-10-2015
DESCRIPCIÓN
Gestión de canal de medios
CAMPO TÉCNICO La presente invención se refiere de manera general a gestión de sesiones de medios en sistemas de comunicaciones y en particular a reducir el tiempo percibido por el usuario de conmutación de canales de medios en tales sesiones de medios.
ANTECEDENTES Ha llegado a haber una tendencia de ofrecer y proporcionar una vasta gama de nuevos servicios en redes móviles y sistemas de comunicaciones móviles existentes. Hay actualmente, un interés muy grande en usar redes móviles para contenido multimedia o de TV. Esto se conoce a menudo como TV Móvil en la técnica. La meta para las aplicaciones de TV Móvil es ofrecer una experiencia de tipo TV donde el usuario puede elegir y zapear fácilmente entre diferentes canales multimedia o de TV.
Los canales de TV normales se difunden a muchos usuarios y típicamente el usuario puede elegir qué canal recibir y ver. La TV Móvil es similar acerca de entregar un conjunto de flujos de medios o multimedia (en directo) a varios usuarios finales. Cada flujo multimedia corresponde a un canal de TV y cada usuario será capaz de elegir qué canal ver. En este momento, los métodos de entrega de difusión/multidifusión para TV Móvil están bajo desarrollo. Ejemplos de tales esfuerzos de estandarización son los Servicios de Difusión/Multidifusión Multimedia (MBMS) del 3GPP y la Difusión de Vídeo Digital-De Mano (DVB-H) del Instituto Europeo de Estándares de Telecomunicaciones (ETSI). Estos serán similares a la TV tradicional, en su forma de distribución de difusión.
Mientras tanto, hasta que la TV Móvil basada en multidifusión/difusión esté disponible, hay una necesidad de solución que se pueda implementar sobre canales de transporte móvil existentes. También será más tarde de gran interés para las celdas con pocos usuarios y para redes con bastante capacidad, donde el transporte unidifusión es el medio de distribución preferido.
Un servicio de tipo TV Móvil que usa difusión de forma continua sobre redes basadas en Protocolo de Internet (IP) se puede implementar en redes móviles existentes. Un ejemplo es el Servicio de Difusión de Forma Continua de Paquetes Conmutados (PS) (PSS) desarrollado en el 3GPP. A fin de iniciar tal sesión multimedia o de TV, un usuario típicamente navega a una página o portal web y pulsa sobre o selecciona un enlace para ver un canal de difusión en forma continua en directo.
También existen varias soluciones de difusión de forma continua propietarias que se podrían usar para TV Móvil, por ejemplo, RealNetworks, Quicktime de Apple y media player de Microsoft. Estas también tienen típicamente un portal
o página web donde se pulsa un enlace para comenzar a recibir un cierto canal.
Una de las metas de servicios de TV Móvil es hacer posible zapear entre canales, como uno puede hacer para canales de TV difundidos comunes. Si todos los canales se difunden, el receptor puede elegir localmente entre canales eligiendo el canal de transporte adecuado y usando un demultiplexor adecuado. Este es el caso para televisión por cable, por satélite o terrestre estándar así como los próximos estándares móviles MBMS y DVB-H. No obstante, para sesiones unidifusión, el cliente debe influir en su lugar en un “servidor” o proveedor multimedia para enviar el canal deseado.
La forma tradicional de hacer difusión de forma continua móvil basada en IP es elegir un contenido especificado en un navegador. Esto inicia la descarga de un fichero de Protocolo de Descripción de Sesiones (SDP) o uno de Lenguaje de Integración Multimedia Sincronizado (SMIL), lo cual a su vez inicia una sesión de difusión de forma continua de Protocolo de Difusión de Forma Continua en Tiempo Real (RTSP) en un reproductor de medios de un terminal de usuario. El tiempo aproximado que lleva hasta que un usuario ve el contenido en la pantalla del terminal de usuario es típicamente de alrededor o ligeramente superior a diez segundos de los cuales quizás cinco segundos es la configuración de aplicación y el resto es señalización (alrededor de dos segundos) y almacenamiento temporal (alrededor de tres a cuatro segundos). Si el usuario quiere conmutar a otro “canal multimedia o de TV”, debe detener el flujo de datos actual y volver al navegador donde elige otro canal pulsando un enlace. Entonces, se inicia una nueva sesión RTSP, el reproductor de medios inicia y comienza a almacenar temporalmente y hay un nuevo retardo de alrededor de diez segundos.
Yendo más allá de los enlaces de navegador para elegir un canal de unidifusión, el planteamiento más simple es hacer una aplicación que configura una nueva sesión de difusión de forma continua a un nuevo URI (Identificador Universal de Recursos) cada vez que uno conmuta un canal. Esto es bastante general, pero es bastante lento por que debe tener lugar un proceso de señalización RTSP completamente nuevo así como un almacenamiento temporal de contenido.
10
15
20
25
30
35
40
45
50
55
60
65
E10165338
22-10-2015
A fin de remediar este lento proceso, se ha desarrollado una solución mucho más rápida [1], donde cada usuario tiene una sesión continua de difusión en forma continua y puede iniciar una conmutación de canal mediante señalización separada sobre HTTP (Protocolo de Transferencia Hipertexto) u otro protocolo.
El documento [6] describe un sistema informático para ver y conmutar datos de AV. Una unidad de control operada por el usuario da instrucciones de conmutación entre audio o vídeo de tal forma que una conmutación entre señales de audio ocurre sin alterar las señales de vídeo y una conmutación entre señales de vídeo ocurre sin alterar las señales de audio.
El documento [7] se refiere a difundir de forma continua multimedia para proporcionar conmutación de flujo sin discontinuidad. Un cliente se prevé que codifique un subconjunto de los flujos que tienen varias tasas de bit y proporcionado desde un servidor. El cliente está configurado de manera que puede decodificar todos los flujos desde el servidor, reproduciendo todos los flujos y silenciando todos los flujos excepto el subconjunto de flujos.
El documento [8] describe un protocolo de difusión de forma continua pasivo que soporta operación de difusión de forma continua de vídeo subjetivo en la que el servido juega un papel pasivo. El control del proceso de difusión de forma continua entero se produce para el sistema cliente. Un programador en el cliente acciona la difusión de forma continua y controla el ritmo.
COMPENDIO Una limitación del procedimiento sugerido en el documento [1] es que todos los canales se deben codificar de una manera similar a fin de hacer posible hacer una sesión RTP (Protocolo de Transporte en Tiempo Real) continua para cada flujo de medios.
La presente invención supera estos y otros inconvenientes de las disposiciones de la técnica anterior.
Es un objeto un general de la presente invención proporcionar una gestión de sesión de medios eficiente.
Es un objeto particular de la invención proporcionar gestión de sesión de medios que permita tiempos de conmutación de canal cortos.
Estos y otros objetos se cumplen por la invención como se define por las reivindicaciones de patente anexas.
Se proporciona un método, realizado en un terminal de usuario, de conmutación de canal de medios en una sesión de medios basada en unidifusión que implica un terminal de usuario tal que recibe un primer contenido de medios de un primer canal de medios desde un servidor de medios que proporciona dicho primer canal de medios y un segundo canal de medios, caracterizado por dicho terminal de usuario que transmite, a dicho servidor de medios, una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión de Forma Continua en Tiempo Real, RTSP, para un segundo contenido de medios de dicho segundo canal de medios durante dicha sesión de medios basada en unidifusión en curso, en donde dicha petición de REPRODUCIR de RTSP comprende un identificador de recursos de contenido de medios único asociado con dicho segundo contenido de medios.
También se proporciona un terminal de usuario caracterizado por: un conmutador de canal para conmutar desde un primer canal de medios que transporta un primer contenido de medios a un segundo canal de medios que transporta un segundo contenido de medios durante una sesión de medios basada en unidifusión en curso, dicho conmutador de canal se dispone para generar una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión en Forma Continua en Tiempo Real, RTSP, para dicho segundo canal de medios y que comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios; y un transmisor para transmitir dicha petición REPRODUCIR de RTSP a un servidor de medios que proporciona dicho primer canal de medios a dicho terminal de usuario y que tiene acceso a dicho segundo canal de medios.
Además se proporciona un servidor de medios que proporciona múltiples canales de medios, cada canal de medios que transporta un contenido de medios respectivo, dicho servidor de medios que comprende un transmisor y se caracteriza por un receptor y un gestor de medios. El transmisor es para transmitir, a un terminal de usuario, un primer contenido de medios de un primer canal de medios de dichos múltiples canales de medios. El receptor es para recibir, desde dicho terminal de usuario, una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión en Forma Continua en Tiempo Real, RTSP, para un segundo contenido de medios de un segundo canal de medios de dichos múltiples canales de medios y que comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios. El gestor de medios es para identificar dicho segundo canal de medios en base a dicha dicho identificador de recursos de contenido de medios único y conmutar la entrega de contenido de medios a dicho transmisor desde dicho primer contenido de medios a dicho segundo contenido de medios para transmisión a dicho terminal de usuario durante una sesión de medios basada en unidifusión en curso.
15
25
35
45
55
65
E10165338
22-10-2015
Aún además se proporciona un método, realizado en un servidor de medios, de conmutación de canal de medios en una sesión de medios basada en unidifusión que implica un servidor de medios que transmite un primer contenido de medios de un primer canal de medios a un terminal de usuario y que proporciona dicho primer canal de medios y un segundo canal de medios, caracterizado por: dicho servidor de medios que recibe, desde dicho terminal de usuario, una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión en Forma Continua en Tiempo Real, RTSP, para un segundo contenido de medios de dicho segundo canal de medios durante dicha sesión de medios basada en unidifusión en curso, en donde dicha petición REPRODUCIR de RTSP comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios; dicho servidor de medios que identifica dicho segundo canal de medios en base a dicho identificador de recurso de contenido de medios único; dicho servidor de medios que conmuta la transmisión de contenido de medios a dicho terminal usuario desde dicho primer contenido de medios a dicho segundo contenido de medios para transmisión a dicho terminal de usuario durante dicha sesión de medios basada en unidifusión en curso.
En pocas palabras, algunas realizaciones de la presente solicitud implican gestión de una sesión de medios basada en unidifusión que implica un terminal de usuario y un servidor de medios que tiene acceso a múltiples canales de medios basados en unidifusión. Un procedimiento de configuración de sesión de canal transparente, genérico se inicia por la transmisión de una petición de sesión de canal transparente, genérica desde el terminal de usuario al servidor de medios. El procedimiento de configuración implica intercambio de información en forma de peticiones y respuestas de canal transparente entre el terminal de usuario y el servidor. No obstante, no se selecciona ningún canal de medios durante este procedimiento de configuración. Esto significa que el servidor de medios aún no es consciente de qué canal le gustaría escuchar al terminal y qué contenido de medios debería enviar el servidor al terminal de usuario.
Primero cuando se completa el procedimiento de configuración, el terminal notifica al servidor de medios del canal de medios solicitado en forma de una petición de representación de canal específico para ese canal. El servidor entonces puede comenzar la entrega de contenido de medios del canal usando el mecanismo de transporte y los puertos negociados durante el procedimiento de configuración de canal transparente previo.
Si el usuario quisiera posteriormente conmutar a un nuevo canal basado en unidifusión en el servidor, el terminal simplemente transmite una nueva petición de representación de canal específico pero para el nuevo canal al servidor durante la sesión en curso. Esto significa que la conmutación de canal está teniendo lugar dentro de la sesión sin ningún requisito de terminar primero la sesión actual y luego configurar una nueva sesión de medios. El mecanismo de transporte y los puertos por lo tanto se utilizarán también para el nuevo canal. Esto reducirá marcadamente el tiempo de conmutación de canal ya que se requieren menos viajes de ida y vuelta y procesamiento de datos en el servidor y el terminal.
Las realizaciones de la presente solicitud también permiten una conmutación sin discontinuidad o casi sin discontinuidad entre una entrega unidifusión y de difusión. El terminal de usuario simplemente transmite una petición de hacer una pausa de representación al servidor de medios causando una parada temporal en la entrega de contenido de medios del canal basado en unidifusión actual. El terminal ahora puede escuchar un canal de difusión. Si el usuario quisiera escuchar de nuevo el canal basado en unidifusión previo u otro canal basado en unidifusión, el terminal transmite una nueva petición de representación de canal específico para ese canal. El canal de medios por lo tanto se reanuda sin ningún nuevo procedimiento de configuración de sesión.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención junto con los objetos y ventajas adicionales de la misma, se puede entender mejor haciendo referencia a la siguiente descripción tomada junto con los dibujos anexos, en los cuales:
Las Figura 1A y 1B son diagramas de señal que ilustran un procedimiento de configuración de canal y un procedimiento de conmutación de canal según la técnica anterior; La Figura 2 es un diagrama de flujo que ilustra un método de gestión de una sesión de medios basada en unidifusión según la presente invención; La Figura 3 es un diagrama de señal que ilustra un procedimiento de configuración de sesión de canal transparente según una realización de la presente invención; La Figura 4 es un diagrama de señal que ilustra un procedimiento de configuración de sesión de canal transparente según otra realización de la presente invención; La Figura 5 es un diagrama de señal que ilustra un procedimiento de configuración de sesión de canal transparente según una realización adicional la presente invención; La Figura 6 es un diagrama de señal que ilustra un procedimiento de petición de canal y un procedimiento conmutación de canal según una realización de la invención; La Figura 7 es un diagrama de señal que ilustra un procedimiento para hacer una pausa temporalmente y un procedimiento para finalizar una sesión de medios basada en unidifusión de la presente invención; La Figura 8 es una vista general esquemática de una parte de un sistema de comunicación, al cual se pueden aplicar las enseñanzas de la presente invención; La Figura 9 es un diagrama de bloques esquemático de un terminal de usuario según la presente invención;
15
25
35
45
55
65
E10165338
22-10-2015
La Figura 10 es un diagrama de bloques esquemático de un gestor de configuración de sesión según la presente invención que se puede implementar en el terminal usuario de la Figura 9; La Figura 11 es un diagrama de bloques esquemático de un servidor de medios según la presente invención; y La Figura 12 es un diagrama de bloques esquemático de un gestor de configuración de sesión según la presente invención que se puede implementar en el servidor de medios de la Figura 11.
DESCRIPCIÓN DETALLADA En todos los dibujos, los mismos caracteres de referencia se usarán para elementos correspondientes o similares.
La presente invención se refiere a gestión de sesión de medios y en particular a gestionar una sesión de medios basada en unidifusión. La gestión de sesión de la invención reduce el número de viajes de ida y vuelta requeridos para conmutar canales de medios basados en unidifusión o para conmutar entre canales de unidifusión y multidifusión/difusión comparado con las técnicas de la técnica anterior.
Como consecuencia de esta reducción en los números de viajes de ida y vuelta, el tiempo percibido por el usuario de conmutación de canales de medios llega a ser disminuido, acercándose a niveles de zapeo “auténtico”. La presente invención por lo tanto proporciona una experiencia de tipo TV similar al sistema de TV común actual y la TV móvil basada en multidifusión/difusión venidera pero en un sistema de comunicaciones basado en unidifusión. Las enseñanzas de la presente invención se pueden aplicar a cualquier sistema de unidifusión tal y en particular a sistemas de comunicaciones inalámbricas particulares que emplean el Protocolo de Internet, IP, para comunicación de datos. Un ejemplo típico de tal sistema de comunicaciones es un sistema de paquetes conmutados (PS) que proporciona datos multimedia a usuarios conectados a través de difusión en forma continua de PS (PSS). Para más información de PSS se hace referencia al documento [2].
Un canal de medios según la presente invención puede, por ejemplo, transportar medios “en directo” o constar de contenido pregrabado que consta de uno o más fragmentos.
La conmutación de canal de la invención, desde el punto de vista del usuario, se experimentará mucho más suavemente, se realizará en un periodo de tiempo más corto y no requiere visitar una página Web del proveedor multimedia y configurar una nueva sesión de medios, como requieren las soluciones unidifusión de la técnica anterior.
Los datos de medios o multimedia según la presente invención incluyen cualquier forma y tipo de medios que se pueden representar y mostrar en un terminal de usuario. Esto incluye, pero no se limita a, imágenes, video, audio y otros tipos de medios que son capaces de ser percibidos, durante la representación, por un usuario.
A fin de simplificar la comprensión de la presente invención y los méritos de la misma, un breve repaso de las técnicas de la técnica anterior de configuración de una sesión de medios basada en unidifusión y conmutación de canales de medios sigue primero en conexión con las Figura 1A y 1B. Estas figuras ilustran la señalización realizada durante la configuración y gestión de una sesión de Protocolo de Difusión en Forma Continua en Tiempo Real (RTSP). Como es conocido en la técnica, RTSP es un protocolo a nivel de aplicaciones para controlar por encima la entrega de datos de medios con propiedades en tiempo real. Hoy en día, están disponibles diferentes versiones de RTSP, incluyendo RTSP 1.0 y RTSP 2.0. La presente invención se puede usar en conexión tanto con estas versiones como con cualquier otra versión.
La sesión se puede iniciar por la compilación y transmisión de una petición DESCRIBIR en el terminal usuario. En respuesta a la petición DESCRIBIR, el servidor de medios compila y devuelve una respuesta (mensaje 200 OK) que comprende una descripción del contenido de medios solicitado. La respuesta típicamente comprende una Localización Universal de Recursos (URL) de la descripción de medios en el servidor de medios. Esta respuesta contiene toda la información de inicialización de medios para el contenido de medios solicitado. En una implementación típica, la descripción está en forma de un fichero del Protocolo de Descripción de Sesiones (SDP). Este fichero SDP comprende, entre otros, el nombre de los medios seleccionados, la dirección de transporte y los códec disponibles para los medios además del URI de la información de descripción.
Un ejemplo típico de respuesta de DESCRIBIR con un fichero SDP podría ser como:
RTSP/1.0 200 OK
CSeq: “número de secuencia única de sesión”
Date: “fecha y hora de creación”
Content-Type: “tipo de contenido de fichero contenido en respuesta”
Content-Length: “longitud de fichero”
Las cuatro líneas anteriores constituyen cabeceras en la respuesta RTSP. Las siguientes líneas ilustran un contenido ejemplo del fichero SDP:
15
25
35
45
55
65
E10165338
22-10-2015
v=0 “inicio de fichero SDP” o= “creador” s= “nombre de sesión” i= “información de sesión” u= “URI de descripción” e= “dirección de correo electrónico” c= “información de conexión” t= “tiempo que está activa la sesión” a=control:* “línea de control usada a nivel de sesión, * especifica que el URI de control es el mismo que se usó para DESCRIBIR” a=control:audiotrack “línea de control para medios de audio con un URI relativo” m=audio 3456 RTP/AVP 0 a=control:vídeotrack “línea de control para medios de vídeo con un URI relativo” m=video 2232 RTP/AVP 31
Un ejemplo típico de la comunicación entre el terminal de usuario (UE) y el servidor de medios (MS) podría ser entonces:
UE → petición de MS:
DESCRIBIR rtsp://mediaserver.com/movie.test
RTSP/1.0
CSeq: 1
MS → respuesta de UE:
RTSP/1.0 200 OK
CSeq: 1
Date: 28 de febrero de 2016 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 435
v=0 o=-950814089 950814089 IN IP4144.132.134.67 s=Ejemplo de control agregado de habla AMR y vídeo H.263 e=foo@bar.com c=IN IP4 192.168.30.29 b=AS:77 t=0 0 a=range:npt=0-59.3478 a=control:* b=AS:13 a=fmtp:97 mode-set=0,2,5,7; maxptime=200 a=control;streamID=0 m=video 0 RTP/AVP 98 b=AS:64f a=rtpmap:98 H263-200/90000 a=fmtp:98 profile=3; level=10 a=control;streamID=1
Para más información del fichero SDP, se hace referencia al documento [3].
El terminal de usuario a partir de entonces compila y transmite una petición CONFIGURAR para el Identificador Universal de Recursos (URI) del contenido de medios deseado. Una sesión de medios típica implica tanto contenido de vídeo como de audio trasmitido sobre un canal de medios de unidifusión. En tal caso, el procedimiento CONFIGURAR se realiza por pasos para los dos tipos de contenido. Por ejemplo, la petición CONFIGURAR vídeo se puede transmitir primero, comprendiendo el URI del contenido de vídeo. La petición también comprende una indicación de los parámetros de transporte aceptables al terminal de usuario para la transmisión de datos de medios. Estos parámetros incluyen en particular los puertos de entrada del cliente usados para el contenido de vídeo. El servidor de medios genera, en respuesta a la petición CONFIGURAR, un identificador de sesión a ser usado de aquí en adelante como un identificador de la sesión de medios actual. Este identificador de señal se devuelve junto con los parámetros de transporte seleccionados por el servidor y los puertos de salida de vídeo del servidor.
Una petición y respuesta CONFIGURAR audio correspondiente se comunican entre el terminal de usuario y el servidor de medios para negociar parámetros de transporte de audio. En claro contraste al mensaje CONFIGURAR vídeo, la petición CONFIGURAR audio comprende el identificador de sesión notificada.
15
25
35
45
55
65
E10165338
22-10-2015
La sesión RTSP se configura ahora con éxito y se puede iniciar la entrega de contenido real. El terminal de usuario por lo tanto compila una petición REPRODUCIR que dice al servidor que empiece a enviar el contenido de medios notificado a través del mecanismo de transporte negociado durante la configuración de sesión. La petición REPRODUCIR puede especificar un intervalo donde el tiempo de reproducción normal debería comenzar o un parámetro de tiempo que especifica una hora a la que debería comenzar la reproducción o representación de los medios. El servidor de medios procesa esta petición REPRODUCIR y responde con un parámetro o intervalo de tiempo reconocido e información de sincronización, tal como en términos de rtptime en el campo de información de rpt de la respuesta.
Los medios solicitados se pueden entregar entonces en el canal de medios basado en unidifusión usando el mecanismo de transporte determinado.
Si el usuario posteriormente quisiera conmutar a un segundo canal basado en unidifusión, la sesión RTSP actual se debe terminar primero. Esto se puede implementar transmitiendo una petición HACER UNA PAUSA que comprende el URI de medios y el identificador de sesión al servidor de medios. Esto causa una interrupción temporal del flujo de medios entregado. No obstante no se liberan recursos asignados para el flujo en este punto. El terminal de usuario continua transmitiendo una petición DESMONTAR para detener la entrega de flujo para el URI dado, liberando los recursos asociados con él. Esto termina la sesión de medios actual. Para más información de RTSP, se hace referencia al documento [4].
El terminal de usuario entonces es forzado a configurar una nueva sesión RTSP excepto para el nuevo canal de medios como se ilustra en la Figura 1B. De esta manera, el mismo procedimiento que fue descrito en lo precedente se dirige una vez más pero con el URI del nuevo contenido de medios y con un nuevo identificador de sesión. El conmutador de canal, de esta manera, implica señalización extensa tomando seis viajes de ida y vuelta así como algún retardo de procesamiento en el servidor de medios y el terminal de usuario antes de ser capaz de representar el contenido de medios del nuevo canal de medios.
La presente invención reduce esta señalización extensiva en conexión con conmutación de canal eligiendo un canal de medios a través de una petición de representación de canal específico (petición REPRODUCIR de RTSP) y un procedimiento de configuración de sesión de canal transparente, genérico.
La Figura 2 es un diagrama de flujo de un método de gestión de una sesión de medios basada en unidifusión que implica un terminal de usuario (cliente) y un servidor de medios que proporciona múltiples, es decir, al menos dos, canales de medios diferentes. Comienza en el paso S1, donde el terminal de usuario genera y transmite una petición de sesión de canal transparente, genérica al servidor de medios. Esta petición de sesión por ello no selecciona un contenido de medios o canal de medios específico. De esta manera, en este punto el servidor de medios no es informado aún de qué contenido de medios solicita el terminal de usuario. Tras la recepción de la petición de sesión de canal transparente, el servidor de medios y el terminal de usuario realizan un procedimiento de configuración de sesión de medios de canal transparente, genérico en un siguiente paso S2. Este procedimiento de configuración se dirige en base a la petición de sesión generada y transmitida previamente. De esta manera, este paso S2 básicamente implica configurar una sesión RTSP entre el terminal de usuario y el servidor. No obstante, en claro contraste con la técnica anterior, este procedimiento de configuración de sesión no implica ninguna especificación del contenido de medios a ser entregado posteriormente al terminal de usuario. De esta manera, se intercambia información entre el terminal de usuario y el servidor de medios, tal como negociación de parámetros de transporte y notificación de identificador de sesión. No obstante, este intercambio de información se realiza sin ninguna selección explícita o implícita de canal de medios a usar para la sesión de medios. Esto significa que el contenido de medios real/selección de canal se pospone hasta que se ha terminado el procedimiento de configuración de sesión.
La notificación del canal y contenido de medios deseado está teniendo lugar primero una vez que la sesión de medios de canal transparente, genérica ha sido configurada con éxito. En este punto, el terminal de usuario genera y transmite una petición de representación de canal específico para el canal deseado al servidor de medios en el paso S3. Ahora primero el servidor llega a ser consciente de qué contenido de medios particular solicita el terminal de usuario y por lo tanto inicia la entrega de datos de medios del canal solicitado usando el mecanismo de transporte negociado. A medida que el terminal recibe los datos de medios su reproductor de medios comienza a representar o reproducir el contenido en el terminal para su usuario en el paso S4. Esta representación de datos típicamente implica visualizar contenido de vídeo en una pantalla de visualización de o conectada al terminal de usuario y reproducir contenido de audio en altavoces de o conectados al terminal.
El método entonces termina. En los diferentes escenarios siguientes que describen el procedimiento de configuración de sesión de canal transparente, genérico se describirán en más detalle en conexión con los diagramas de señal de las Figura 3 a 5. En estos diagramas, la sesión de medios se realiza como una sesión RTSP y por lo tanto la terminología de tales peticiones y respuestas RTSP se han empleado en las figuras. Las enseñanzas de la presente invención se podrían aplicar sin embargo a otros protocolos usados para configurar y gestionar una sesión de medios basada en unidifusión.
15
25
35
45
55
65
E10165338
22-10-2015
La Figura 3 es un diagrama de señal que ilustra la realización del procedimiento de configuración de sesión de medios de canal transparente, genérico según una realización de la invención. La configuración se inicia por la transmisión del mensaje de petición de sesión de canal transparente, genérico al servidor de medios. Este mensaje de petición podría ser una petición DESCRIBIR, si se emplea o una petición CONFIGURAR. En esta y las siguientes figuras, se han empleado peticiones y respuestas DESCRIBIR pero la invención también se podría aplicar a un procedimiento sin estas peticiones y respuestas.
La petición DESCRIBIR no especifica el canal real como en la técnica (rtsp://tv.com/channel1.sdp en la Figura 1A y rtsp://tv.com/channel2.sdp en la Figura 1B). En claro contraste, la petición es genérica en términos de aquella que solicita descripción de múltiples, preferiblemente, todos los contenidos de medios disponibles a través de entrega basada en unidifusión desde el servidor de medios.
El servidor de medios genera un mensaje de descripción o trae un mensaje generado previamente tal en base a la petición DESCRIBIR recibida. Esta respuesta DESCRIBIR es preferiblemente en forma de un fichero SDP o algún otro formato de mensaje. Este fichero SDP comprende un anuncio de los canales de medios disponibles de sus contenidos de medios. En línea con el ejemplo enumerado previamente del fichero SDP de la técnica anterior, el fichero SDP devuelto en la respuesta DESCRIBIR podría ser en forma de:
RTSP/2.0 200 OK
CSeq: 1
Date: “fecha y hora de creación”
Content-Type: allchannels/sdp
Content-Length: “longitud de fichero”
v=0 o= “creador” i= “información de sesión” u= “URI de descripción” t= “tiempo que está activa la sesión” a= control:tv.com/allchannels.sdp/channel1 a= control:tv.com/allchannels.sdp/channel2 ... a= control:tv.com/allchannels.sdp/channelN
Esto significa que la descripción SDP se complementa con múltiples líneas de control de sesión, donde cada línea tal anuncia uno de los canales de medios disponibles. En un planteamiento alternativo, se introduce un nuevo atributo “altcontrol” en el fichero SDP. Esto significa que el atributo de control se mantiene para compatibilidad hacia atrás.
La línea de medios correspondiente en el fichero SDP entonces puede parecer:
a= altcontrol:list channel1 a= altcontrol:list channel2 ... a= altcontrol:list channelN
En ambas de estas realizaciones, los anuncios de canal de medios podrían ser en forma de los denominados URI de control agregado (AC). Tal URI de AC se refiere tanto a contenido de vídeo como el contenido de audio asociado a ser representados juntos en un terminal de usuario. En un planteamiento alternativo para contenido de medios que comprende tanto vídeo como audio, los URI separados se podrían usar en las líneas de control y altcontrol para los dos tipos de medios por cada canal de medios disponible.
En el caso de compatibilidad hacia atrás, el fichero SDP se puede complementar con una línea de atributo de control además del atributo altcontrol, es decir
a= control:defaultchannel a= altcontrol:list channel1 a= altcontrol:list channel2 ... a= altcontrol:list channelN
El canal por defecto entonces podría ser un canal por defecto predefinido seleccionado por el servidor de medios y usado como un canal de medios inicial para aquellos terminales de usuario que no soportan el atributo altcontrol. En tal caso, estos terminales de usuario pueden continuar el procedimiento de configuración de sesión según la técnica anterior con este canal por defecto.
15
25
35
45
55
65
E10165338
22-10-2015
A fin de dar a la señalización una alternativa, la petición de sesión puede incluir una petición de soporte si el servidor de medios soporta el procedimiento de configuración de canal transparente, genérico. Esto se puede implementar usando una etiqueta de característica con la cabecera requerida en la primera petición DESCRIBIR transmitida por el terminal de usuario. Esta cabecera entonces podría incluir un nuevo atributo multiple-control-uris:
DESCRIBIR rtsp://tv.com/allchannels.sdp RTSP/2.0
Require: multiple-control-uris
Si el servidor no soporta el procedimiento de configuración genérico, puede responder con un mensaje de error, tal como Opción 551 no soportada.
Una vez que el terminal de usuario ha recibido el mensaje de descripción con los URI de AC preferidos, genera un mensaje de petición de transporte o configuración de canal transparente, genérico. En línea con la discusión en conexión con la Figura 1A, si un canal de medios comprende tanto contenido de vídeo como de audio, una petición de configuración de canal transparente, genérica se compila y transmite preferiblemente para ambos tipos de contenido como se muestra en la Figura 3. Una primera petición de canal transparente genérica tal podría ser para el contenido de vídeo (audio), mientras que la segunda petición entonces se dedica para contenido de audio (vídeo). Las peticiones preferiblemente especifican los parámetros de transporte aceptables para el terminal de usuario para la transmisión de medios posterior. Por ejemplo, incluyen las notificaciones de los puertos de vídeo y audio de entrada del terminal de usuario y otros parámetros de transporte requeridos para configurar la sesión de medios.
Este mensaje de petición de configuración genérica típicamente desencadena, tras la recepción en el servidor de medios, una negociación de mecanismo de transporte (procedimiento oferta-respuesta) y generación de identificador de sesión. El servidor de medios, de esta manera, incluye información de los parámetros de transporte seleccionados por el servidor, el identificador de sesión generado y los puertos de vídeo y audio de salida, respectivamente, a ser usados para la entrega de medios posterior, en las respuestas.
Este procedimiento, de esta manera, se repite preferiblemente para el contenido de audio si la primera petición y respuesta CONFIGURAR se relaciona con contenido de vídeo. Como se señaló en lo precedente, una vez que el identificador de sesión se ha generado y notificado al terminal de usuario, se incluye preferiblemente en todas las comunicaciones posteriores entre el terminal de usuario y el servidor de medios.
La sesión de medios de canal transparente, genérica de la invención se configura ahora. Esto significa que se han seleccionado y notificado puertos de entrada y salida requeridos, se han negociado parámetros de transporte y se han generado identificadores de sesión. Todos estos procedimientos se han dirigido sin embargo sin ninguna especificación o selección del canal de medios particular a usar en la sesión.
En la realización descrita anteriormente en conexión con la Figura 3, los URI de AC de los diferentes canales de medios se notifican al terminal de usuario en el mensaje de descripción (fichero SDP de respuesta DESCRIBIR). No obstante, podría ser posible que estos URI, es decir, identificadores de canal de medios, no se conozcan cuando se creó el fichero SDP. Además, la disponibilidad de los canales de medios puede depender de la hora del día o puede ser diferente en diferentes días. El uso de un fichero SDP predefinido fijo por lo tanto será demasiado inflexible para hacer frente a esta situación. Una solución posible entonces podría ser generar un nuevo fichero SDP en el servidor de medios cada vez y todas las veces que recibe una respuesta DESCRIBIR. No obstante, esto aumenta los requisitos de procesamiento de datos del servidor de medios e introduce retardos adicionales en el procedimiento de configuración de sesión de medios.
Un planteamiento alternativo es usar en su lugar plantillas genéricas en el fichero SDP y entonces informar al terminal de usuario de los URI de canal de medios pertinentes en un punto posterior en el procedimiento de configuración. Este planteamiento se ha tomado en las Figura 4 y 5.
La Figura 4 es un diagrama de señal que ilustra la realización del procedimiento de configuración de sesión de medios de canal transparente, genérico según otra realización de la invención. La configuración se inicia por la transmisión del mensaje de petición (DESCRIBIR) de sesión de canal transparente, genérico al servidor de medios. Tras la recepción de este mensaje, el servidor de medios proporciona un fichero SDP u otro mensaje de descripción que comprende un anuncio genérico de los canales de medios disponibles. Este anuncio se puede usar en conexión con el atributo de control:
a= control:tv.com/allchannels/*
o el nuevo atributo altcontrol: a= altcontrol:dynamic
Esto señala que la lista de los URI de AC alternativos es dinámica o desconocida en el momento particular y se proporcionará por otros medios. En sintaxis de forma Backus-Naur aumentada (ABNF), ver documento [5], la parte de sesión del fichero SDP se puede escribir como:
15
25
35
45
55
65
E10165338
22-10-2015
altcontrol-line = “a=altcontrol:” control-type [sp rtsp-URI]
control-type = “list” / “dynamic” /token
rtsp-URI = “especificado como en RTSP 2.0”
El significado real de cada línea de control también se puede proporcionar en el fichero SDP pero se puede definir mejor en una tabla de canal completa que describe canales unidifusión o tanto canales de unidifusión como de difusión.
La señalización de petición y respuesta CONFIGURAR restante se realiza de la misma manera de canal transparente, genérica que se describió anteriormente en conexión con la Figura 3.
El terminal de usuario entonces compilará y transmitirá una petición para los URI de AC que se anunciaron dinámicamente/genéricamente en el fichero SDP. Esta petición se puede enviar al servidor de medios o incluso a otro servidor o nodo en el sistema de comunicaciones que tenga acceso a información de los canales de medios unidifusión disponibles actualmente en el servidor de medios y sus URI respectivos. La petición podría ser por ejemplo en forma de una petición HTTP habitual o una petición de una tabla de canal completa. El servidor de medios o el otro servidor/nodo responde a esta petición devolviendo información de los URI de los canales de medios basados en unidifusión disponibles actualmente en el servidor de medios.
En otro planteamiento, la notificación de URI se realiza a través de una transmisión de difusión o de multidifusión desde el servidor de medios o algún otro servidor o nodo. Esta situación se ilustra esquemáticamente en la Figura 5. En este diagrama de señal, un controlador de servidor separado realiza la notificación de los URI de AC en forma de una descripción de servicio de usuario (USD) de difusión/multidifusión.
El servidor de medios ha informado previamente al controlador del servidor de sus diferentes canales basados en unidifusión de su disponibilidad y sus URI.
Como se describió en lo precedente, el procedimiento de configuración de sesión de medios de canal transparente, genérico de la invención no necesariamente tiene que ser iniciado por la transmisión de la petición DESCRIBIR. Esto se ilustra además en la presente figura ya que se pueden omitir las líneas discontinuas. Como consecuencia, el procedimiento de configuración se puede iniciar directamente por la transmisión de un mensaje de petición CONFIGURAR de canal transparente, genérico desde el terminal de usuario. La siguiente señalización hasta la última respuesta CONFIGURAR es similar a la que se ha descrito previamente en conexión con la Figura 3.
El terminal de usuario aquí es informado de los URI de AC de los canales de medios disponibles actualmente en el servidor de medios a través de la USD difundida y multidifundida desde el controlador del servidor. El mensaje de USD no tiene necesariamente que ser enviado después de la terminación del procedimiento de configuración de canal transparente. Esto significa que el terminal de usuario puede haber recibido en su lugar la USD (brevemente) antes de la iniciación del procedimiento de configuración o en algún momento durante el procedimiento de configuración. En tal caso, el controlador del servidor se podría configurar para difusión o multidifusión periódica de la USD en intervalos de tiempo adecuados.
Se anticipa por la presente invención que una combinación de la señalización descrita en cualquiera de las Figura 3 a 5 se puede usar y está dentro del alcance de la invención. Por ejemplo, es posible combinar una notificación de URI en el fichero SDP con difusión de URI, en el caso de que sea eminente una actualización de los canales de medios disponibles.
La sesión de medios ahora se ha configurado de la manera de canal transparente, genérica sin ninguna selección de canal de medios al que el terminal de usuario debería escuchar realmente durante la sesión. El canal de medios y por lo tanto la selección de contenido de medios de la invención está teniendo lugar primero en la compilación y transmisión de una petición de representación, por ejemplo, petición REPRODUCIR de RTSP como se ilustra en la Figura 6. Esta petición REPRODUCIR comprende un identificador del canal de medios seleccionado. La petición se genera preferiblemente en base al identificador de recursos de medios (URI) único asociado con el canal de medios seleccionado y recibido previamente en el terminal de usuario. Preferiblemente, la petición de representación comprende el URI de AC del canal de medios seleccionado.
El servidor de medios procesa la petición REPRODUCIR y responde con un parámetro o intervalo de tiempo reconocido e información de sincronización, tal como en términos de rtptime en el campo de información rtp de la respuesta.
El contenido de medios del canal solicitado entonces se transmite usando el mecanismo de transporte, los puertos de entrada y salida determinados en el procedimiento de configuración de canal transparente, genérico, al contenido de medios.
Si el terminal de usuario quisiese posteriormente conmutar a cualquiera de los otros canales de medios basados en unidifusión proporcionados por el servidor de medios y anteriormente notificados al terminal en conexión con la
E10165338
22-10-2015
configuración, el terminal simplemente compila y transmite una nueva petición de representación, es decir, una petición REPRODUCIR, para el nuevo canal de medios. Esta petición REPRODUCIR de canal específico se genera preferiblemente en base al URI de AC del nuevo canal y más preferiblemente comprende el URI de AC o algún otro identificador del nuevo canal. La petición REPRODUCIR se genera además en base a una entrada de usuario, tal
5 como la presión de una tecla, pantalla sensible al tacto o alguna otra activación de entrada, en el terminal.
El servidor de medios contesta con una respuesta de representación que incluye información de sincronización y de tiempo. Como la respuesta REPRODUCIR proporciona la información de sincronización así como valores para los campos SSRC, el decodificador en el terminal puede comenzar la reproducción del nuevo canal e identificar los
10 paquetes de datos. El contenido de medios del nuevo canal se transmite usando los mismos puertos de salida del servidor a los mismos puertos de entrada del terminal de usuario que se emplearon para los canales previos. Los otros parámetros de transporte determinados durante el procedimiento de configuración de canal transparente se mantienen típicamente.
15 Se anticipa por la invención que esta segunda petición REPRODUCIR comprende preferiblemente, como hizo la primera petición REPRODUCIR preferiblemente, el identificador de sesión asignado durante el procedimiento de configuración de sesión genérico.
En una implementación preferida, se envían nuevos valores de sincronización (SSRC) para todos los flujos de 20 medios y canales. La respuesta REPRODUCIR desde el servidor de medios entonces podría tener la siguiente disposición:
RTSP/2.0 200 OK RTSP-Info: URI= “rtsp://tv.com/allchannels.sdp/audiotrack” ssrc= 0D12F123: seq=5712; rtptime= 93407921, 25 URI= “rtsp://tv.com/allchannels.sdp/videotrack” ssrc=789DAF12: seq=57654; rtptime=2792482193
La conmutación de canal rápida de la presente invención, de esta manera, utiliza una petición de representación, tal como una petición REPRODUCIR de RTSP, dentro de una sesión de medios en curso, tal como una sesión RTSP, para solicitar un nuevo canal. Como consecuencia, todos aquellos parámetros negociados y determinados durante la 30 configuración de canal transparente, genérica de la invención se pueden mantener también para la entrega del nuevo contenido de medios. Esto se debería comparar con la conmutación de la técnica anterior, donde la sesión RTSP actual primero tiene que ser detenida y desmontada y se debe configurar una sesión RTSP de canal específico completamente nueva antes de que se pueda entregar el contenido de medios del nuevo canal a y representar en el terminal de usuario. Comparando la Figura 6 con la situación en las Figura 1A y 1B está claro que
35 alrededor de seis viajes de ida y vuelta y el procesamiento en conexión con esa señalización ya no es necesario para conmutar los canales de medios. Como consecuencia, la conmutación de canal de la invención llega a ser mucho más rápida que la conmutación de la técnica anterior.
El diseño real de la petición de representación de la invención no es decisivo. Un ejemplo podría ser como:
40 REPRODUCIR rtsp://tv.com/allchannels.sdp/channel2 RTSP/2.0 donde “tv.com/allchannels.sdp/channel2” es el URI de AC del número de canal de medios 2.
Un planteamiento alternativo es usar:
45 REPRODUCIR rtsp://tv.com/allchannels.sdp?channel=2 RTSP/2.0 donde se usa una parte de consulta al URI base “tv.com/allchannels.sdp” y “2” es un identificador del canal solicitado.
50 En lugar de usar un URI único, preferiblemente el URI de AC, por canal de medios, podría ser posible usar URI idénticos para todos los canales de medios basados en unidifusión pero añadir alguna información para distinguir entre los canales. Por ejemplo, se puede introducir una nueva cabecera. En tal caso, una petición REPRODUCIR podría ser como:
55 REPRODUCIR rtsp://tv.com/allchannels.sdp RTSP/2.0 x-channel: “identificador de canal solicitado”
El identificador podría simplemente ser una serie numérica, 1, 2, 3 y así sucesivamente o algún otro nombre o identificador, incluyendo un identificador de servicio de usuario MBMS.
60 La conmutación de canal de la presente invención tiene una ventaja adicional comparada con la técnica anterior además del tiempo de conmutación reducido y menos viajes de ida y vuelta y procesamiento en conexión con la conmutación. La presente invención se puede usar para proporcionar una transición entre un canal de unidifusión y un canal de difusión/multidifusión y viceversa.
65
15
25
35
45
55
65
E10165338
22-10-2015
Si el usuario quisiera conmutar desde el canal basado en unidifusión actual a un canal de difusión, la entrega del contenido de medios actual se detiene temporalmente. La Figura 7 es un diagrama de señal de una realización de la invención que proporciona tal oportunidad de transición de unidifusión-difusión.
Una vez que el terminal de usuario recibe una entrada de usuario para conmutar a un canal de difusión, el terminal compila una petición de hacer una pausa de representación, tal como una petición HACER UNA PAUSA de RTSP. Esta petición es una petición HACER UNA PAUSA tradicional como se describió en conexión con la Figura 1A. El servidor de medios responde haciendo una pausa en la transmisión de datos de medios del canal basado en unidifusión actual y preferiblemente contesta con una contestación o respuesta HACER UNA PAUSA.
El terminal de usuario entonces comienza a escuchar el canal de difusión y recibe los datos de medios de ese canal. Este canal de difusión se puede proporcionar por el mismo servidor de medios o algún otro servidor de medios en el sistema de comunicaciones.
Si el usuario posteriormente quisiera volver a escuchar el canal de medios basado en unidifusión previo o escuchar otro canal basado en unidifusión proporcionado por el servidor de medios, el terminal de usuario compila y transmite una nueva petición de representación de canal específico, es decir, una petición REPRODUCIR, al servidor de medios. El servidor de medios contesta con una respuesta REPRODUCIR y los datos de medios del canal basado en unidifusión seleccionado se transmiten al terminal de usuario usando el mecanismo y los puertos de transporte negociados previamente.
Esto significa que la sesión de medios basada en unidifusión no se termina durante la conmutación temporal al canal de difusión. Por el contrario, la sesión está latente y llega a estar activa de nuevo tras una nueva petición de representación.
La conmutación de acceso unidifusión a difusión o viceversa para el mismo contenido se puede hacer sin discontinuidad si, para un corto instante durante la conmutación, el terminal de usuario recibe dos flujos de datos de medios en paralelo. Esto significa que durante este corto periodo de tiempo, el terminal de usuario recibe contenido de medios tanto desde el canal antiguo (unidifusión o difusión) como desde el canal nuevo (difusión o unidifusión). El terminal de usuario entonces conmutará la fuente antes del almacenador temporal RTP.
A fin de hacer tal transición sin discontinuidad fiable, el retardo de transporte es preferiblemente pequeño entre unidifusión y difusión. Óptimamente, los dos flujos serían idénticos o estarían completamente sincronizados. En tal caso, la conmutación se puede hacer en cualquier sitio en el flujo. De otro modo, el contenido de medios de ambos flujos se recibe típicamente en paralelo durante un corto periodo de tiempo en el terminal de usuario y la conmutación está teniendo lugar dentro de una trama. Esto reduce el riesgo de perder paquetes de datos que contienen datos de medios.
Los diferentes canales de unidifusión y difusión proporcionados por el servidor de medios podrían usar diferentes codificaciones y configuraciones de códec. Esto se puede resolver, por ejemplo, describiendo las diferentes codificaciones/configuraciones en el fichero de descripción (fichero SDP) y darlas diferentes valores de tipo carga útil. Tras una conmutación de canal, el terminal de usuario conmutará la configuración del decodificador sobre la marcha al recibir los paquetes de datos del nuevo canal. También es posible utilizar diferentes codificaciones para diferentes canales basados en unidifusión.
La invención también es muy flexible ya que hace posible usar el mismo flujo de medios tanto para unidifusión como para difusión sin cambiar ningún campo de cabecera RTP. Esto simplifica la transición sin discontinuidad de unidifusión a difusión durante la sesión de medios en curso, en particular en combinación con el uso del mismo cifrado de los flujos.
El procedimiento de configuración de canal transparente, genérico de la invención se puede realizar incluso si el usuario quisiera escuchar primero un canal de difusión. Esto significa que la sesión de medios unidifusión se configura pero entonces llega a estar latente hasta que el terminal de usuario deja de escuchar el canal de difusión y transmite una petición REPRODUCIR al servidor de medios. Esto significa que la primera petición de representación de canal específico de la invención no tiene que ser transmitida necesariamente directamente a continuación de la terminación del procedimiento de configuración de canal transparente. En su lugar la petición de representación se transmite primero una vez que el usuario quiere conmutar desde canales de difusión a unidifusión.
Si el terminal de usuario quisiera posteriormente terminar la sesión de medios actual, se realiza el procedimiento descrito previamente con peticiones y respuestas HACER UNA PAUSA y DESMONTAR.
El identificador de sesión que genera preferiblemente el servidor de medios en conexión con la recepción de la (primera) petición CONFIGURAR canal transparente, genérica se usa preferiblemente tanto por el servidor de medios como el terminal de usuario en todas las peticiones y respuestas comunicadas posteriormente. Esto significa que el identificador de sesión se incluye preferiblemente en una petición de representación posterior usada para conmutar canales de unidifusión. Además, la petición de representación que reactiva la sesión de medios a
15
25
35
45
55
65
E10165338
22-10-2015
continuación de una escucha temporal, en el terminal de usuario, de un canal de difusión también comprende preferiblemente este identificador de sesión.
El procedimiento de configuración de sesión de canal transparente, genérico de la invención no tiene que seguir necesariamente la señalización descrita en conexión con las Figura 3-6. En un planteamiento alternativo podría ser posible una canalización de las peticiones y contestaciones de RTSP. En tal caso, el terminal de usuario compila y transmite las peticiones CONFIGURAR vídeo y audio de canal transparente seguidas por la petición de REPRODUCIR canal específico. Esto significa que el terminal no espera ninguna contestación a la petición transmitida previamente antes de transmitir la siguiente. El servidor de medios responde enviando la respuesta CONFIGURAR vídeo, la respuesta CONFIGURAR audio y la respuesta REPRODUCIR una después de la otra o ciertamente juntas. Los datos de medios del canal de medios solicitado primero en la petición REPRODUCIR entonces se pueden entregar al terminal de usuario.
En esta realización de canalización, el identificador de sesión se notificará al terminal de usuario primero después de que se haya finalizado el procedimiento de configuración de canal transparente y se haya solicitado el canal de medios solicitado. A fin de identificar el terminal de usuario y la sesión actual, el terminal genera preferiblemente un identificador temporal único y lo incluye en las peticiones CONFIGURAR y REPRODUCIR. Esto permite al servidor de medios determinar que estas peticiones se originan desde uno y el mismo terminal de usuario. Una vez que el terminal ha recibido el identificador de sesión desde el servidor de medios, típicamente en la primera contestación CONFIGURAR, usará este identificador de sesión en lugar del identificador temporal en cualquier petición REPRODUCIR posterior cuando se conmutan los canales de medios.
La Figura 8 es una vista general esquemática de un sistema de comunicaciones inalámbricas basado en unidifusión 1 según una realización de la presente invención. El sistema de comunicaciones 1 comprende una estación base o nodo de red 20 que transmite contenido de medios a los terminales de usuario conectados 10, 100. Esta estación base 20 comprende o está conectada a un servidor de medios 200 de la invención que tiene múltiples canales de medios basados en unidifusión disponibles. En la figura, el primer terminal de usuario 100 escucha a uno de estos canales de medios basados en unidifusión. Otros dos terminales de usuario 10, no obstante, escuchan un canal de difusión también que está disponible en el servidor de medios 200.
La Figura 9 es un diagrama de bloques esquemático de un terminal de usuario 100 según una realización de la presente invención. Este terminal de usuario 100 comprende un transmisor y receptor o transceptor 110, ilustrado esquemáticamente como una unidad única en la figura. La unidad 110 incluye una funcionalidad de transmisor/receptor tradicional, tal como un modulador/demodulador, codificador/decodificador, etc.
El transmisor 110 está adaptado para transmitir, a un servidor de medios, las peticiones de canal transparente, genéricas durante el procedimiento de configuración de sesión de canal transparente y la petición de reproducción de canal específico que señala el inicio de entrega de medios y/o una conmutación de canal. El receptor 110 está adaptado para recibir las respuestas a las peticiones transmitidas por la cadena de transmisor 110 y, por supuesto, los datos de medios difundidos de forma continua desde el servidor de medios.
El terminal de usuario 100 comprende un gestor de configuración de sesión 140 que constituye un medio para realizar un procedimiento de configuración de sesión basado en unidifusión de canal transparente con el servidor de medios. Este gestor de configuración 140 de esta manera compila los mensajes de petición de canal transparente que se transmiten por el transmisor 110 al servidor de medios y procesa los mensajes de respuesta correspondientes recibidos por el receptor 110. El procedimiento de configuración de canal transparente implica intercambio de información entre el terminal de usuario 100 y el servidor pero no una selección explícita del canal de medios a usar hasta que se configura la sesión. El gestor 140 realiza este procedimiento de configuración con el servidor de medios en base a la petición de sesión de canal transparente, genérica (petición DESCRIBIR o CONFIGURAR) transmitida por el transmisor.
Un generador de petición de representación o reproducción 135 se implementa en el terminal de usuario para compilar una respuesta de representación de canal específico una vez que el gestor de configuración 140 ha completado el procedimiento de configuración de canal transparente con el servidor de medios. Este mensaje de petición comprende un identificador del canal de medios seleccionado, tal como un URI de AC u otro identificador de canal. La petición de representación compilada se reenvía al transmisor 110 que la reenvía al servidor de medios para iniciar la entrega de medios.
El gestor de configuración 140 y el generador de petición 135 se activan típicamente a través de una entrada de usuario (no ilustrada) del terminal 100. Esto causará la generación de los mensajes de petición de la invención y su transmisión al servidor de medios.
El generador de petición 135 también se activa, por el desencadenamiento o activación de una entrada de usuario, durante una conmutación a otro canal basado en unidifusión o tras volver a escuchar un canal basado en unidifusión a continuación de un periodo temporal de escucha del canal de difusión. De esta manera, en una conmutación de canal durante la sesión en curso, el generador de petición 135 compila una petición de representación para un
10
15
20
25
30
35
40
45
50
55
60
65
E10165338
22-10-2015
nuevo canal de medios, cuya petición preferiblemente comprende un identificador de ese canal. De la misma manera, en una conmutación a escucha de difusión, el generador de petición de reproducción 135 compila una petición de hacer una pausa de representación que se transmite por el transmisor 110 al servidor de medios. Si el usuario quiere volver de nuevo al canal basado en unidifusión previo u otro canal de medios basado en unidifusión tal, el generador de petición 135 compone una petición de representación de canal específico con un identificador de ese canal de medios.
El generador de petición 135 se puede implementar en un reproductor multimedia o de medios 130 del terminal de usuario 100. Este reproductor de medios 130 está preferiblemente en comunicación con una pantalla de visualización 120 y un altavoz 160 del terminal 100 para mostrar y reproducir los medios en el mismo.
Un almacenador temporal de medios opcional 150 se puede implementar en el terminal de usuario 100 para almacenar temporalmente datos de medios recibidos antes de que se presenten por el reproductor de medios 130 en la pantalla 120 y/o el altavoz 160. El almacenador temporal 150 es útil en el caso de conmutación de canal y en particular para conmutación de unidifusión a difusión o de difusión a unidifusión ya que los dos flujos de medios se pueden recibir en paralelo y almacenar en el almacenador temporal 150 para permitir una transición de canal sin discontinuidad.
Las unidades 110, 130, 135 y 140 del terminal de usuario 100 se pueden proporcionar como software, hardware o una combinación de los mismos. El generador de petición de reproducción 135 se puede implementar en el reproductor de medios 130 como se ilustra en la figura o en otra ubicación en el terminal 100.
La Figura 10 es un diagrama de bloques esquemático de una realización del gestor de configuración de sesión 140 del terminal de usuario en la Figura 9. El gestor de configuración 140 opcionalmente, pero preferiblemente, comprende una unidad 141 para generar una petición de descripción de canal transparente. Este generador de petición DESCRIBIR 141 compila la petición DESCRIBIR canal transparente discutida previamente que podría constituir el mensaje de petición de sesión de canal transparente, genérico de la invención.
La respuesta DESCRIBIR resultante se procesa por un procesador de mensaje de descripción opcional pero preferido 142. Este procesador 142 en particular recupera el anuncio de los múltiples canales de medios disponibles en el servidor de medios. En el caso que los URI u otros identificadores de los canales se incluyan en el mensaje de descripción, el procesador 142 recupera estos identificadores y los reenvía al generador de petición de representación del terminal de usuario.
Un generador de petición de configuración de vídeo 143 se proporciona en el gestor de configuración 140 para componer la petición CONFIGURAR de vídeo de canal transparente de la invención. Esta petición CONFIGURAR preferiblemente comprende información de aquellos parámetros de transporte (vídeo) que son aceptables por el terminal de usuario, incluyendo los puertos de vídeo de entrada del terminal. En una realización, esta petición CONFIGURAR vídeo constituye la petición de sesión de canal transparente, genérica de la invención.
El gestor de configuración 140 también comprende un procesador de mensaje o respuesta de configuración de vídeo 144 para procesar la respuesta CONFIGURAR vídeo desde el servidor de medios. Esto significa que el procesador 144 recupera información de los puertos de salida de vídeo del servidor de medios y aquellos parámetros de transporte de vídeo que ha seleccionado el servidor de medios. Esta información se reenvía a la unidad de transmisor/receptor del terminal para uso durante la recepción de datos de medios posterior.
Un generador de petición de configuración de audio correspondiente 145 se implementa preferiblemente en el gestor de configuración 140 para generar una petición CONFIGURAR audio de canal transparente. Esta petición de configuración comprende información de aquellos parámetros de transporte (audio) que son aceptables por el terminal de usuario, incluyendo los puertos de audio de entrada del terminal. En una realización, esta petición CONFIGURAR audio constituye la petición de sesión de canal transparente, genérica de la invención.
El gestor 140 comprende un procesador de respuesta o mensaje de configuración de audio 146. Este procesador 146 procesa la respuesta CONFIGURAR audio recibida por el receptor del terminal y generada en respuesta al generador de petición CONFIGURAR audio por el generador 145 y transmitida por el transmisor del terminal. El procesador 146 en particular recupera información del parámetro de transporte de audio seleccionado por el servidor de medios y los puertos de salida para el contenido de audio. También esta información se reenvía al receptor del terminal para usar durante la recepción de medios.
Se anticipa por la presente invención, que el generador de configuración de vídeo 143 y el procesador 144 del generador de configuración de audio 145 y el procesador 146 se podrían omitir del gestor de configuración 140. En tal caso, el contenido de medios solamente contendrá contenido de audio o contenido de vídeo. No obstante, para las implementaciones más típicas tanto los generadores/procesadores de vídeo como de audio 143, 144, 145, 146 se requieren e implementan en el gestor de configuración 140.
15
25
35
45
55
65
E10165338
22-10-2015
En caso de que los identificadores de canal no estuvieran incluidos en el mensaje de descripción procesado por el procesador de contestación describir 142 o no se haya recibido tal respuesta describir, el gestor de configuración 140 preferiblemente utiliza un generador de petición de identificador opcional pero preferido 147. Este generador 147 compone un mensaje de petición para los identificadores de los canales basados en unidifusión disponibles en el servidor de medios. El mensaje generado se transmite típicamente al servidor pero se podría transmitir alternativamente a algún otro nodo de red que tenga acceso a esta información.
El mensaje de respuesta desde el servidor de medios u otro nodo se reenvía desde el receptor del terminal a un procesador de respuesta de identificador 148 del gestor de configuración 140. Este procesador 148 recupera la información de los canales de medios, típicamente en forma de URI y preferiblemente en forma de unos URI de AC, incluidos en la contestación. La información de identificador entonces se reenvía al generador de petición de representación y se usa por el generador cuando se compone la petición de representación de canal específico.
Si los identificadores de canal se notifican a través de transmisión de difusión o multidifusión, el procesador de mensaje de identificador 148 se configura para procesar la información de difusión/multidifusión recibida y recuperar la información de identificador de canal a partir de la misma.
Las unidades 141 a 148 del gestor de configuración de sesión 140 se pueden proporcionar como software, hardware
o una combinación de los mismos. Las unidades 141 a 148 se pueden implementar juntas en el gestor de configuración 140. También es posible una implementación distribuida con algunas de las unidades proporcionadas en otra parte en el terminal de usuario.
La Figura 11 es un diagrama de bloques esquemático de un servidor de medios 200 según la presente invención. El servidor de medios 200 comprende una unidad de transmisor y receptor 210 dispuesta para dirigir la comunicación con unidades externas y procesar mensajes entrantes y salientes. El transmisor 210 en particular se implementa para transmitir mensajes de respuesta y paquetes de datos que comprenden datos de medios a un terminal de usuario. El receptor 210 en particular se implementa para recibir mensajes de petición desde el terminal de usuario.
El servidor de medios 200 comprende o tiene acceso a múltiples canales de medios 400, 410. Esto significa que el servidor 200 podría comprender o estar conectado a un banco de datos que almacena contenido de medios pregrabado. Alternativamente o además, la fuente de medios podría estar en forma de contenido de medios en directo recibido en el servidor de medios 200 para transmisión adicional a terminales solicitantes. Un gestor de medios 230 del servidor 200 se implementa para cuidar del correcto procesamiento de medios, tal como seleccionando el contenido de medios correcto para diferentes terminales, generando los paquetes de datos con el contenido de medios.
El servidor de medios 200 además incluye un gestor de configuración de sesión 220 que constituye un medio para realizar un procedimiento de configuración de sesión de medios basado en unidifusión de canal transparente, genérico con un terminal de usuario. Este gestor de configuración 220 se desencadena tras la recepción por el receptor de una petición de sesión de canal transparente, genérica que se origina desde el terminal. El gestor de configuración 220 genera mensajes de respuesta de canal transparente y procesa mensajes de petición de canal transparente que se transmiten por el transmisor 210 al terminal de usuario y reciben por el receptor 210 desde el terminal respectivamente.
Una vez que se ha completado el procedimiento de configuración de sesión de canal transparente y el receptor 210 recibe una petición de representación de canal específico, esta petición se lleva al gestor de medios 230. El gestor de medios 230 identifica el canal de medios correcto en base a un identificador de canal en la petición y reenvía el contenido de medios de ese canal al transmisor 210. El transmisor usa el mecanismo de transporte negociado por el gestor de configuración de sesión 220 para reenviar el contenido de datos al terminal.
Si el receptor 210 recibe posteriormente una nueva petición de representación de canal específico desde el terminal, el gestor de medios 230 conmutará, después de procesar la petición, la entrega de contenido de medios desde el canal de medios previo al canal recién solicitado.
La recepción de una petición de pausa disparará el gestor de medios 230 para dejar de proporcionar temporalmente el contenido de medios al terminal que envió la petición. Si una nueva petición de representación de canal específico se recibe más tarde, el gestor 230 proporcionará contenido de datos de medios de ese canal al transmisor 210 para entrega al terminal de usuario durante la sesión en curso.
La Figura 5 ilustra esquemáticamente el uso de un controlador de servidor separado 300 que se puede usar en el sistema de comunicación basado en radio, inalámbrico para transmitir identificadores del canal unidifusión (y de difusión) disponible desde el servidor de medios 200. Este controlador 300 se ha indicado en la Figura 11. En tal caso, este controlador 300 comprende preferiblemente un gestor de identificador 320 para generar mensajes que comprenden esta información de identificador. Un transmisor 310 del controlador 300 entonces transmite el mensaje, típicamente en forma de una transmisión multidifusión o de difusión, a los terminales pertinentes.
E10165338
22-10-2015
El gestor de identificador 320 también podría, por medio del transmisor 310, interrogar al servidor de medios 200 para información de los canales de medios, incluyendo sus identificadores y disponibilidad.
El controlador del servidor 300 se podría conectar a e incluir información de canal desde varios servidores de medios 5 200 distintos dispuestos en el sistema de comunicación.
Las unidades 210 a 230 del servidor de medios 200 se pueden proporcionar como software, hardware o una combinación de los mismos. Las unidades 210 a 230 se pueden implementar juntas en el servidor 200 en un nodo de red único. También es posible una implementación distribuida con algunas de las unidades proporcionadas en
10 diferentes nodos en la red. La misma discusión con respecto a implementación software/hardware también se aplica a las unidades 310 a 320 del controlador del servidor 300.
La Figura 12 es un diagrama de bloques esquemático de un gestor de configuración de sesión 220 del servidor de medios en la Figura 11. El gestor de configuración 220 opcionalmente pero preferiblemente comprende un 15 procesador de petición de descripción 221 para procesar una petición de canal transparente desde un terminal de usuario. El procesador 221 típicamente identifica el terminal desde el cual se origina la petición y notifica un generador de respuesta o mensaje de descripción 222 opcional pero preferido. El generador compila la respuesta DESCRIBIR discutida previamente que comprende un anuncio de los canales de medios disponibles en el servidor de medios. Este anuncio podría ser los identificadores reales o los URI de los canales o una notificación de que se
20 podrían seleccionar múltiples canales por el terminal, en cuyo caso sus identificadores se notificarán separadamente.
Un procesador de petición de configuración de vídeo 223 y un procesador de petición de configuración de audio 225 procesan peticiones CONFIGURAR vídeo y audio recibidas. Los procesadores 223, 225 seleccionan parámetros de 25 transporte, incluyendo puertos de vídeo y audio de salida a usar para la sesión. Esta información se reenvía tanto al transmisor del servidor de medios para uso en la próxima entrega de medios como a un generador de respuesta de configuración de vídeo respectivo 224 y un generador de respuesta de configuración de audio 226. Los generadores 224 compilan las respuestas CONFIGURAR vídeo y audio respectivas que comprenden los parámetros de transporte de entrada para transmisión al terminal. El generador de respuesta CONFIGURAR vídeo 224
30 preferiblemente incluye también un identificador de sesión generado en el servidor de medios e incluido en todas las respuestas y peticiones posteriores intercambiadas entre el servidor y el terminal de usuario.
En el caso de que el generador de respuesta describir 222 no incluyese los identificadores de canales de medios en la respuesta describir, el gestor de configuración 220 podría utilizar un generador de mensaje de identificador
35 opcional 228. Este generador 228 compone un mensaje que comprende identificadores, tales como los URI de AC, de los canales de medios basados en unidifusión disponibles actualmente en el servidor. El generador 228 se podría operar tras la recepción de una petición explícita desde el terminal de usuario. Alternativamente, el mensaje generado se podría difundir o multidifundir por el servidor a múltiples terminales.
40 Las unidades 221 a 228 del gestor de configuración de sesión 220 se pueden proporcionar como software, hardware
o una combinación de los mismos. Las unidades 221 a 228 se pueden implementar juntas en el gestor de configuración 220. También es posible una implementación distribuida con algunas de las unidades proporcionadas en otra parte en el servidor de medios.
45 Se entenderá por un experto en la técnica que se pueden hacer diversas modificaciones y cambios a la presente invención sin apartarse del alcance de la misma, el cual se define por las reivindicaciones adjuntas.
REFERENCIAS
[1] WO 2006/096104
50 [2] TS 26.234 v7.1.0 del 3GPP; Proyecto de Cooperación de 3ª Generación; Aspectos de Servicios y Sistemas del grupo de Especificación Técnica; Servicio de Difusión de Forma Continua de Paquetes Conmutados (PSS) extremo a extremo Transparente; Protocolos y códec, diciembre de 2006
[3] Grupo de Trabajo de Red, Petición de Comentarios: 2327, abril de 1998, SDP: Protocolo de Descripción de Sesiones
55 [4] Grupo de Trabajo de Red, Petición de Comentarios: 2326, abril de 1998, SDP: Protocolo de Difusión de Forma Continua en Tiempo Real (RTSP)
[5] Grupo de Trabajo de Red, Petición de Comentarios: 4234, octubre de 2005, SDP: BNF Aumentada para Especificaciones de Sintaxis: ABNF
[6] US 2002/0101442 60 [7] WO 2004/021668
[8] WO 01/72041
Claims (8)
- 5101520253035404550556065REIVINDICACIONES
- 1.
- Un método realizado en un terminal de usuario (100), de conmutación de canal de medios en una sesión de medios basada en unidifusión que implica a dicho terminal de usuario (100) que recibe un primer contenido de medios de un primer canal de medios desde un servidor de medios (200) que proporciona dicho primer canal de medios y un segundo canal de medios, caracterizado por dicho terminal de usuario (100) que transmite, a dicho servidor de medios (200), una petición de representación de contenido específico en forma de una petición REPRODUCIR del Protocolo de Difusión de Forma Continua en Tiempo Real, RSTP, para un segundo contenido de medios de dicho segundo canal de medios durante dicha sesión de medios basada en unidifusión en curso, en donde dicha petición REPRODUCIR de RTSP comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios.
-
- 2.
- El método según la reivindicación 1, caracterizado por que dicho paso de transmisión comprende dicho terminal de usuario (100) que transmite, a dicho servidor de medios (200), dicha petición REPRODUCIR de RTSP que comprende un identificador de sesión asociado con dicha sesión de medios basada en unidifusión en curso y asignado durante la configuración de dicha sesión de medios basada en unidifusión.
-
- 3.
- El método según la reivindicación 1 o 2, caracterizado por dicho terminal de usuario (100) que recibe contenido de medios de dicho segundo canal de medios en los mismos puertos de entrada que fueron usados por dicho terminal de usuario (100) para recibir contenido de medios de dicho primer canal de medios.
-
- 4.
- Un terminal de usuario (100), caracterizado por:
un conmutador de canal (135) para conmutación desde un primer canal de medios que transporta un primer contenido de medios a un segundo canal de medios que transporta un segundo contenido de medios durante una sesión de medios basada en unidifusión en curso, dicho conmutador de canal (135) está dispuesto para generar una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión en Forma Continua en Tiempo Real, RTSP, para dicho segundo canal de medios y que comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios; y un transmisor (110) para transmitir dicha petición REPRODUCIR de RTSP a un servidor de medios (200) que proporciona dicho primer canal de medios a dicho terminal de usuario (100) y que tiene acceso a dicho segundo canal de medios. -
- 5.
- El terminal de usuario según la reivindicación 4, caracterizado por que dicho transmisor (110) está configurado para transmitir, a dicho servidor de medios (200), dicha petición REPRODUCIR de RTSP que comprende un identificador de sesión asociado con dicha sesión de medios basada en unidifusión en curso y asignada durante la configuración de dicha sesión de medios basada en unidifusión.
-
- 6.
- El terminal de usuario según la reivindicación 4 o 5, caracterizado por un receptor (110) para recibir contenido de medios de dicho segundo canal de medios en los mismos puertos de entrada que se usaron por dicho terminal de usuario (100) para recibir contenido de medios de dicho primer canal de medios.
-
- 7.
- Un servidor de medios (200) que proporciona múltiples canales de medios, cada canal de medios que transporta un contenido de medios respectivo, dicho servidor de medios (200) comprende:
un transmisor (210) para transmitir, a un terminal de usuario (100), un primer contenido de medios de un primer canal de medios de dichos múltiples canales de medios, caracterizado por:un receptor (210) para recibir, desde dicho terminal de usuario (100), una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión de Forma Continua en Tiempo Real, RTSP, para un segundo contenido de medios de un segundo canal de medios de dichos múltiples canales de medios y que comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios; y un gestor de medios (230) para identificar dicho segundo canal de medios en base a dicho identificador de recurso de contenido de medios único y conmutar la entrega de contenido de medios a dicho transmisor (210) desde dicho primer contenido de medios a dicho segundo contenido de medios para transmisión a dicho terminal de usuario (100) durante una sesión de medios basada en unidifusión en curso. - 8. Un método, realizado en un servidor de medios (200), de conmutación de canal de medios en una sesión de medios basada en unidifusión que implica un servidor de medios (200) que transmite un primer contenido de medios de un primer canal de medios a un terminal de usuario (100) y que proporciona dicho primer canal de medios y un segundo canal de medios, caracterizado por:17dicho servidor de medios (200) que recibe, desde dicho terminal de usuario (100), una petición de representación de contenido específico en forma de una petición REPRODUCIR de Protocolo de Difusión en Forma Continua en Tiempo Real, RTSP, para un segundo contenido de medios de dicho segundo canal de medios durante dicha sesión de medios basada en unidifusión en curso, en donde dicha petición5 REPRODUCIR de RTSP comprende un identificador de recurso de contenido de medios único asociado con dicho segundo contenido de medios; dicho servidor de medios (200) que identifica dicho segundo canal de medios basado en dicho identificador de recurso de contenido de medios único; y dicho servidor de medios (200) que conmuta la transmisión de contenido de medios a dicho terminal de10 usuario (100) desde dicho primer contenido de medios a dicho segundo contenido de medios para transmisión a dicho terminal de usuario (100) durante dicha sesión de medios basada en unidifusión en curso.18
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US80511206P | 2006-06-19 | 2006-06-19 | |
| US805112P | 2006-06-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2550949T3 true ES2550949T3 (es) | 2015-11-13 |
Family
ID=38833676
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES10165338.4T Active ES2550949T3 (es) | 2006-06-19 | 2007-05-04 | Gestión de canal de medios |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US8230044B2 (es) |
| EP (2) | EP2227017B1 (es) |
| KR (1) | KR101375454B1 (es) |
| CN (1) | CN101473654B (es) |
| DK (1) | DK2227017T3 (es) |
| ES (1) | ES2550949T3 (es) |
| HK (1) | HK1134874A1 (es) |
| RU (1) | RU2494562C2 (es) |
| WO (1) | WO2007149029A1 (es) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9008598B2 (en) * | 2006-06-16 | 2015-04-14 | Core Wireless Licensing S.A.R.L | Broadcast channel identification |
| CA2691085C (en) | 2007-06-20 | 2016-12-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for improved media session management |
| KR20090017351A (ko) * | 2007-08-14 | 2009-02-18 | (주)씨디네트웍스 | 프로그램 제어장치, 프로그램 제어방법 및 그 기록 매체 |
| US9553911B1 (en) | 2007-09-04 | 2017-01-24 | Arris Enterprises, Inc. | System, method and computer readable medium for managing program switch requests |
| CN101471902A (zh) * | 2007-12-29 | 2009-07-01 | 华为技术有限公司 | 一种实现信号暂停的方法及设备 |
| CN101227745B (zh) | 2008-02-02 | 2011-02-09 | 华为软件技术有限公司 | 移动多媒体业务的网络切换方法、装置和系统 |
| US7979557B2 (en) * | 2008-04-11 | 2011-07-12 | Mobitv, Inc. | Fast setup response prediction |
| US7921222B2 (en) | 2008-05-06 | 2011-04-05 | Vantrix Corporation | Method and system for fast channel switching using standard RTSP messages |
| US9197690B2 (en) * | 2008-09-25 | 2015-11-24 | Arris Enterprises, Inc. | Method and system for transmitting content |
| US8082351B1 (en) * | 2009-05-26 | 2011-12-20 | Adobe Systems Incorporated | Software load balancing for session requests that maintain state information |
| CN101964716B (zh) * | 2009-07-21 | 2015-04-29 | 华为技术有限公司 | 一种实现流业务的方法及通信系统以及相关设备 |
| EP2293524A1 (en) * | 2009-09-07 | 2011-03-09 | Nxp B.V. | Set-up of media stream transmission and server and client for media stream transmission |
| KR101541197B1 (ko) * | 2009-12-21 | 2015-08-05 | 한국전자통신연구원 | 스트리밍 서버군에서 서비스 중인 콘텐츠의 정보를 갱신하는 방법 |
| CN101969431B (zh) * | 2010-09-28 | 2013-06-12 | 广东威创视讯科技股份有限公司 | 一种实现流媒体播放单播、多播无缝切换的方法 |
| CN102075976B (zh) * | 2011-01-11 | 2013-07-24 | 中国联合网络通信集团有限公司 | 移动流媒体播放器和移动流媒体播放方法 |
| US8775664B2 (en) * | 2011-02-16 | 2014-07-08 | Sony Corporation | Method and apparatus for use in tracking playback of media streams while in stand-by mode |
| CN102857478B (zh) * | 2011-06-30 | 2016-09-28 | 华为技术有限公司 | 媒体数据控制方法及装置 |
| US8819264B2 (en) * | 2011-07-18 | 2014-08-26 | Verizon Patent And Licensing Inc. | Systems and methods for dynamically switching between unicast and multicast delivery of media content in a wireless network |
| US8837488B2 (en) * | 2011-07-29 | 2014-09-16 | Blackfire Research Corporation | Two tier multiple sliding window mechanism for multidestination media applications |
| WO2013052490A2 (en) * | 2011-10-04 | 2013-04-11 | Google Inc. | System and method for obtaining video streams |
| US8787726B2 (en) | 2012-02-26 | 2014-07-22 | Antonio Rossi | Streaming video navigation systems and methods |
| US9712580B2 (en) * | 2012-04-03 | 2017-07-18 | Netflix, Inc. | Pipelining for parallel network connections to transmit a digital content stream |
| CN102662598A (zh) * | 2012-04-25 | 2012-09-12 | 深圳市中兴移动通信有限公司 | 基于手势滑动的会话查看方法及装置、触屏智能终端 |
| WO2013172626A1 (ko) * | 2012-05-14 | 2013-11-21 | 엘지전자 주식회사 | 미디어 제어 장치, 미디어 렌더러 장치, 미디어 서버 장치 및 이들의 동작 방법 |
| WO2014117775A1 (en) * | 2013-01-31 | 2014-08-07 | Codemate A/S | Network content delivery method using a delivery helper node |
| US10560514B2 (en) * | 2014-03-29 | 2020-02-11 | Samsung Electronics Co., Ltd. | Apparatus and method for transmitting and receiving information related to multimedia data in a hybrid network and structure thereof |
| KR102249147B1 (ko) * | 2014-03-29 | 2021-05-07 | 삼성전자주식회사 | 복합 네트워크에서 멀티미디어 데이터 관련 정보를 송수신하기 위한 장치 및 방법과 그 구조 |
| US10375528B2 (en) * | 2015-07-09 | 2019-08-06 | At&T Intellectual Property I, L.P. | Dynamically switching between broadcast and unicast services for service continuity between wireless networks |
| CN105516115B (zh) * | 2015-12-02 | 2019-06-18 | 华为软件技术有限公司 | 一种频道快速播放的方法及用户设备ue |
| US10123226B2 (en) * | 2015-12-02 | 2018-11-06 | At&T Intellectual Property I, L.P. | Detection of active listeners and dynamic provisioning of cell sites for broadcast |
| CN109151614B (zh) * | 2017-06-19 | 2023-05-16 | 中兴通讯股份有限公司 | 一种降低hls直播播放延迟的方法及装置 |
| CN110167190B (zh) * | 2018-02-14 | 2021-02-12 | 华为技术有限公司 | 会话建立方法和设备 |
| US11489603B2 (en) * | 2019-09-23 | 2022-11-01 | Nbcuniversal Media, Llc | Media essence library |
| US11638040B2 (en) | 2020-08-24 | 2023-04-25 | Schmied Enterprises LLC | Eco-friendly codec-based system for low latency transmission |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997028505A1 (en) * | 1996-01-31 | 1997-08-07 | Ipsilon Networks, Inc. | Improved method and apparatus for dynamically shifting between routing and switching packets in a transmission network |
| JP3770831B2 (ja) * | 1999-08-18 | 2006-04-26 | 富士通株式会社 | ネットワークの負荷分散を行うコンピュータ、監視装置、その方法およびそのためのプログラムを記録した記録媒体 |
| WO2001072041A2 (en) * | 2000-03-24 | 2001-09-27 | Reality Commerce Corporation | Method and system for subject video streaming |
| WO2002007440A2 (en) | 2000-07-15 | 2002-01-24 | Filippo Costanzo | Audio-video data switching and viewing system |
| TW561374B (en) | 2000-07-26 | 2003-11-11 | Cool Partners Inc | Method and apparatus for selecting streaming media in real-time |
| US6973081B1 (en) * | 2000-10-12 | 2005-12-06 | Realnetworks, Inc. | System and method for seamlessly joining multicast session |
| GB2368224B (en) * | 2000-10-17 | 2004-08-25 | Hewlett Packard Co | Content provider entity for communication session |
| US20030048808A1 (en) * | 2001-09-12 | 2003-03-13 | Stahl Thomas Anthony | Method and apparatus for changing received streaming content channels |
| US7296074B2 (en) * | 2002-03-20 | 2007-11-13 | Scientific-Atlanta, Inc. | Media on demand session re-use |
| US8397269B2 (en) * | 2002-08-13 | 2013-03-12 | Microsoft Corporation | Fast digital channel changing |
| AU2003255983A1 (en) * | 2002-08-28 | 2004-03-19 | Koninklijke Philips Electronics N.V. | Method of streaming multimedia data |
| KR100487124B1 (ko) * | 2002-11-12 | 2005-05-03 | 삼성전자주식회사 | 세션 이니세이션 프로토콜 시스템의 세션 정보 처리 방법및 그 기록매체 |
| KR100476457B1 (ko) * | 2003-02-13 | 2005-03-18 | 삼성전자주식회사 | 네트워크 디지털 방송 서비스를 위한 제어 방법 |
| US20040260827A1 (en) * | 2003-06-19 | 2004-12-23 | Nokia Corporation | Stream switching based on gradual decoder refresh |
| ES2276348T3 (es) * | 2003-07-21 | 2007-06-16 | France Telecom | Control de admision de sesion multimedia sobre un criterio de recursos de red. |
| US7162533B2 (en) * | 2004-04-30 | 2007-01-09 | Microsoft Corporation | Session description message extensions |
| US7720983B2 (en) | 2004-05-03 | 2010-05-18 | Microsoft Corporation | Fast startup for streaming media |
| SE0402876D0 (sv) * | 2004-11-25 | 2004-11-25 | Ericsson Telefon Ab L M | TV-like standards-compliant unicast streaming over IP |
| US8522293B2 (en) * | 2004-12-15 | 2013-08-27 | Time Warner Cable Enterprises Llc | Method and apparatus for high bandwidth data transmission in content-based networks |
| EP1675343A1 (en) * | 2004-12-23 | 2006-06-28 | Siemens S.p.A. | Method and system to minimize the switching delay between two RTP multimedia streaming sessions |
| US7500133B2 (en) * | 2004-12-28 | 2009-03-03 | Sap Ag | Connection manager for handling message oriented protocol-based requests |
| US7567565B2 (en) * | 2005-02-01 | 2009-07-28 | Time Warner Cable Inc. | Method and apparatus for network bandwidth conservation |
| US8452885B2 (en) * | 2005-02-23 | 2013-05-28 | Cisco Technology, Inc. | Playout-dependent unicast streaming of digital video content |
| US20090222873A1 (en) | 2005-03-07 | 2009-09-03 | Einarsson Torbjoern | Multimedia Channel Switching |
| US7609700B1 (en) * | 2005-03-11 | 2009-10-27 | At&T Mobility Ii Llc | QoS channels for multimedia services on a general purpose operating system platform using data cards |
| US8028322B2 (en) * | 2005-03-14 | 2011-09-27 | Time Warner Cable Inc. | Method and apparatus for network content download and recording |
| US20070168523A1 (en) * | 2005-04-11 | 2007-07-19 | Roundbox, Inc. | Multicast-unicast adapter |
| US8347341B2 (en) * | 2006-03-16 | 2013-01-01 | Time Warner Cable Inc. | Methods and apparatus for centralized content and data delivery |
| US20070245391A1 (en) * | 2006-03-27 | 2007-10-18 | Dalton Pont | System and method for an end-to-end IP television interactive broadcasting platform |
| US7921222B2 (en) * | 2008-05-06 | 2011-04-05 | Vantrix Corporation | Method and system for fast channel switching using standard RTSP messages |
-
2007
- 2007-05-04 CN CN2007800225925A patent/CN101473654B/zh active Active
- 2007-05-04 RU RU2009101322/07A patent/RU2494562C2/ru active
- 2007-05-04 DK DK10165338.4T patent/DK2227017T3/en active
- 2007-05-04 EP EP10165338.4A patent/EP2227017B1/en active Active
- 2007-05-04 WO PCT/SE2007/000438 patent/WO2007149029A1/en active Application Filing
- 2007-05-04 EP EP07748102.6A patent/EP2036350B1/en active Active
- 2007-05-04 US US12/305,161 patent/US8230044B2/en active Active
- 2007-05-04 ES ES10165338.4T patent/ES2550949T3/es active Active
-
2008
- 2008-12-19 KR KR1020087030891A patent/KR101375454B1/ko active IP Right Grant
-
2009
- 2009-12-18 HK HK09111973.9A patent/HK1134874A1/xx not_active IP Right Cessation
-
2012
- 2012-05-31 US US13/484,908 patent/US20120239779A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| DK2227017T3 (en) | 2015-10-26 |
| RU2009101322A (ru) | 2010-07-27 |
| RU2494562C2 (ru) | 2013-09-27 |
| CN101473654A (zh) | 2009-07-01 |
| US8230044B2 (en) | 2012-07-24 |
| KR101375454B1 (ko) | 2014-03-25 |
| EP2227017A1 (en) | 2010-09-08 |
| EP2036350B1 (en) | 2015-07-22 |
| US20100223357A1 (en) | 2010-09-02 |
| WO2007149029A1 (en) | 2007-12-27 |
| KR20090039682A (ko) | 2009-04-22 |
| EP2227017B1 (en) | 2015-07-22 |
| US20120239779A1 (en) | 2012-09-20 |
| HK1134874A1 (en) | 2010-05-14 |
| CN101473654B (zh) | 2011-08-03 |
| EP2036350A4 (en) | 2010-05-05 |
| EP2036350A1 (en) | 2009-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2550949T3 (es) | Gestión de canal de medios | |
| US9003041B2 (en) | Multimedia session management | |
| US8046479B2 (en) | Media channel management | |
| JP6310111B2 (ja) | 放送システムにおける制御メッセージ構成装置 | |
| GB2515931B (en) | Combined broadcast and unicast delivery | |
| CN101485170B (zh) | 通过网络呈现用流传输的可重复的数据对象 | |
| JP2003304511A (ja) | 通信端末、サーバ装置、中継装置、放送通信システム、放送通信方法及びプログラム | |
| KR20070027803A (ko) | Ｉｐ기반 방송의 채널변경시 지연시간의 개선 방법 | |
| US11831702B2 (en) | Method for broadcasting DASH/HLS hybrid multimedia streams | |
| JP2004282233A (ja) | メディア配信装置、メディア受信装置、メディア配信方法及びメディア受信方法 | |
| JP2004252884A (ja) | コンテンツ配信変換装置及びコンテンツ配信変換方法 | |
| WO2017047433A1 (ja) | 送信装置、受信装置、およびデータ処理方法 | |
| Mayer et al. | 001930 BROADWAN Deliverable D25 Summarised conclusions from trials and final recommendations for full coverage | |
| JP2004304271A (ja) | データ送信装置およびデータ受信装置 |