Brevet FR2865598A1 — publié le 20050729

SYSTEME DE TRANSMISSION NUMERIQUE DE SEQUENCES MULTIMEDIA VIA UN RESEAU DE COMMUNICATION DU TYPE INTERNET Introduction au streaming audio et vidéo. Etat de l'art Explicitation de certains sigles ci-après utilisés: RTSP: real time streaming protocol HTTP: hypertext transfer protocol IRE: internet key exchange SSL: secure socket layer TLS: transport layer security IP: internet protocol ATM: asynchronous transfer mode ISDN: integrated services digital network DVB: digital video broadcasting Le terme streaming désigne l'ensemble des techniques destinées à transmettre des séquences multimedia (audio, vidéo et éventuellement autres) sous forme numérique d'un émetteur vers un récepteur, le récepteur commençant à traiter la séquence avant de l'avoir reçue complètement. Typiquement, une installation comporte des streamers, ou serveurs de flux, ou serveurs, qui transmettent des flux audio ou vidéo depuis un disque dur local, une antenne satellite, un récepteur de télévision numérique terrestre, une 10 camera, ou tout autre moyen vers des récepteurs dédiés appelés set-top boxes ou des micro ordinateurs. Dans la suite de la description, ces récepteurs (set-top boxes ou micro ordinateurs) seront appelés clients. _ Une telle installation s'accompagne fréquemment d'un site web permettant aux utilisateurs d'accéder aux différents contenus multimedia depuis leur set-top box ou micro ordinateur de manière simple et conviviale. D'un point de vue pratique, ce site contient le plus souvent des liens vers les différents streamers, avec lesquels les clients dialoguent directement, en utilisant le protocole standard RTSP (Real Time Streaming Protocol) pour accéder aux différents flux. Mise en oeuvre du streaming vidéo selon l'invention L'invention concerne un système de transmission numérique de séquences multimédia via un réseau de communication, notamment du type Internet ou ASM. Le système comprend: - des serveurs connectés à des émetteurs, notamment du type disque dur, antenne satellite, caméra vidéo, câble, - des récepteurs, notamment du type récepteurs dédiés ou équipements informatiques connectés à des écrans de visualisation de type téléviseur. Les serveurs et les récepteurs sont connectés au réseau de communication du type Internet. Le système est caractérisé en ce qu'il comprend un serveur gestionnaire connecté aux serveurs. Le serveur gestionnaire comporte des moyens de traitement informatiques destinés à : - interpréter et traiter des requêtes d'accès aux séquences multimédia de type RTSP, analyser et contrôler les requêtes d'accès aux séquences multimédia de type RTSP, provenant des récepteurs, - déterminer et contrôler en temps réel des niveaux d'activité des serveurs, - sélectionner au moins un serveur parmi les serveurs 35 en fonction des requêtes et des niveaux d'activité des serveurs, - commander aux serveurs ainsi sélectionnés la diffusion des séquences multimédia vers les récepteurs, via le réseau de communication du type Internet. Ainsi, le serveur gestionnaire assure le contrôle et la continuité de la diffusion des séquences multimédia. Le serveur gestionnaire comporte en outre des moyens informatiques de chiffrement, permettant de chiffrer les séquences multimédia et les requêtes au moyen de protocoles, notamment de type IPsec, SSL et TLS. Les moyens informatiques de chiffrement sont destinés à : - assurer la confidentialité et l'intégrité de la réception des requêtes et de la diffusion des séquences multimédia, - accélérer les temps de transition entre des 15 séquences multimédia émises par des serveurs différents. Le manager La solution de streaming selon l'invention comporte une différence par rapport à cette approche classique: un système pilotant l'ensemble des streamers, connu sous le nom de manager, fait partie intégrante de la solution. Au lieu de dialoguer directement avec les streamers, les clients ne s'adressent qu'à ce manager unique (également en utilisant le protocole standard RTSP), et c'est le manager qui à son tour pilote les streamers en employant un protocole plus simple pour que les flux multimedia soient émis vers les clients qui en font la demande. Le manager est un logiciel qui remplit d'une part la fonction de serveur RTSP (Real Time Streaming Protocol) et d'autre part la fonction de serveur HTTP. La différence par rapport à l'approche traditionnelle est double: d'une part, ce logiciel est le seul à remplir à la fois les fonctions de serveur RTSP et de serveur HTTP, d'autre part, le manager ne se contente pas d'orienter le client vers le bon streamer, mais dialogue avec lui et pilote le streamer selon les instructions du client. À aucun moment, le client ne donne d'ordres au streamer sans passer par le manager. La figure 1 représente l'architecture classique d'une transmission de séquences multimédia selon l'art antérieur: une requête 1 est émise depuis un récepteur 2 vers des streamer 3 connectés à des émetteurs de type antenne satellite 4a, télévision numérique terrestre 4b ou câble 4c. En réponse à la requête 1, les streamers 3 transmettent en retour au récepteur 2 un flux de séquences multimédia 5, via un réseau informatique 7, destiné à être diffusé sur un écran de visualisation 6. La figure 2 représente l'architecture d'une transmission de séquences multimédia selon l'invention: une requête 1 est émise depuis un récepteur 2 vers un serveur gestionnaire manager 8. Le serveur gestionnaire manager 8 adresse des instructions de pilotage 9 à des streamers 3 connectés à des émetteurs de type antenne satellite 4a, télévision numérique terrestre 4b ou câble 4c. Les streamers 3, en fonction des instructions de pilotage 9, transmettent au récepteur 2 un flux de séquences multimédia 5, via un réseau informatique 7, destiné à être diffusé sur un écran de visualisation 6. Avantages de cette approche Un premier avantage de ce mode de fonctionnement est que le manager constitue un point central de passage de toutes les requêtes d'accès aux contenus. Ainsi, il est aisé de mettre en place un système de facturation, de statistiques, et de contrôle d'accès (c'est-à-dire d'éditer des factures individualisées pour chaque client, calculées en fonction des medias auxquels ils ont accédé, et de décider d'accorder ou non l'accès à certaines ressources à un client, en fonction, par exemple, de sa formule d'abonnement). En outre, le manager est capable de connaître à tout moment l'état des différents streamers, et peut donc prendre en charge les opérations de répartition de charge et de haute disponibilité. Autrement dit, il est à même d'assurer la continuité de service en cas de défaillance ou de surcharge de l'un des streamers, opération beaucoup plus délicate à réaliser et beaucoup moins fiable dans le cas de streamers autonomes. Enfin, l'intégration d'un serveur HTTP au manager assure sa capacité à échanger plus d'informations que ne le permet le seul protocole RTSP, ainsi, le site web accompagnant souvent les solutions de streaming vidéo peut-il être intégré au manager et a alors accès à toutes ses variables internes, ce qui permet de développer aisément et à moindre coût un site présentant à l'utilisateur final une vue de l'ensemble des opérations qu'il réalise ou peut réaliser. Par exemple, des playlists personnelles peuvent très facilement prendre place sur le manager, même si elles font appel à des flux répartis sur des streamers différents. Enfin, la solution dans son ensemble est pilotée par l'administrateur du réseau en ne manipulant que le manager, ce qui réduit considérablement le coût d'administration et le temps de diagnostic des pannes. Protection de contenu L'un des problèmes fréquemment rencontrés lors du déploiement de solutions de streaming est celui du contrôle d'accès aux flux diffusés. Les flux sont émis sur un réseau informatique en unicast (c'est-à-dire vers un seul client) et/ou en multicast (auquel cas tout client en faisant la demande reçoit le flux, alors que le serveur n'émet ce dernier qu'une seule fois). Dans le cas de l'unicast, il existe cependant des méthodes pouvant permettre à un client malveillant de recevoir le flux destiné à un autre client. Dans le cas de l'unicast, un client n'a presque rien à faire pour pouvoir obtenir le flux. Il est donc utile de chiffrer le flux, et de ne communiquer la clef nécessaire à le déchiffrer qu'à ses destinataires légitimes. Cas du réseau IP Cette partie traite de la solution de protection de contenu selon l'invention destinée aux réseaux où peut être déployé le protocole IP. Celle-ci consiste à chiffrer les flux n'étant pas destinés à tous en s'appuyant sur le standard IPsec, qui fait partie du protocole IP. Ce standard est bien connu et permet de chiffrer tout paquet IP. Cependant, il n'est pas du ressort d'IPsec de spécifier comment les participants à une communication échangent leurs clefs de chiffrement. Un protocole complémentaire d'IPsec, IKE (Internet Key Exchange), permet cet échange, mais uniquement dans le cas de flux émis en unicast (alors que ce n'est pas pour ce type de flux que le problème de sécurité est le plus important). En outre, sa mise en oeuvre est délicate. La solution selon l'invention repose sur l'association d'IPsec et de deux autres protocoles, eux aussi bien connus SSL et TLS. Ces deux protocoles permettent d'encapsuler la communication entre les clients (set-top boxes ou micro ordinateurs) et le serveur RTSP (donc le manager) dans une communication chiffrée. Ainsi, la confidentialité du dialogue entre le client et le manager est assurée. Le protocole RTSP est donc légèrement étendu, de manière à permettre au manager de fournir aux clients qui en ont besoin les clefs nécessaires au déchiffrement des flux auxquels ils ont légitimement accès. Ces clefs sont générées aléatoirement par les streamers, et le manager peut interroger les streamers pour les connaître quand il doit les communiquer aux clients. Ceci permet de changer régulièrement de clef. Ainsi, une approche classique du streaming chiffré sur réseaux IP serait que les clients, lorsqu'ils se connectent à chaque streamer (l'approche classique ne comprend pas de manager), émettent leurs requêtes RTSP, échangent les clefs nécessaires avec le streamer à l'aide d'IKE, et reçoivent les flux chiffrés en IPsec et les déchiffrent. Cette approche présente deux inconvénients: les clefs ne peuvent pas être échangés de cette manière pour les flux multicast, et le processus d'échange de clefs IKE étant assez long, le passage d'une chaîne à l'autre, si les deux chaînes ne sont pas émises par un même streamer, prend beaucoup de temps. La solution selon l'invention reposant sur un manager unique, ce problème de latence est éliminé. En outre, l'échange de clefs n'ayant pas lieu en IKE mais en RTSP étendu et encapsulé dans SSL ou TLS, les flux multicast peuvent également être protégés à l'aide d'IPsec et déchiffrés par leurs récepteurs légitimes. En outre, l'utilisation du protocole IPsec permet non seulement de garantir la confidentialité des flux (seuls les utilisateurs autorisés peuvent lire les données), mais également leur intégrité (le flux n'a pas été corrompu en chemin par suite à une erreur ou à un acte malveillant). Cas des réseaux non-IP Sur les réseaux ne pouvant pas accueillir le protocole IP, ou sur les réseaux dont les opérateurs ne souhaitent pas déployer ce protocole, le principe de la solution d'échange de clefs reste applicable tel quel. Ainsi, des clefs de chiffrement peuvent être échangées à l'aide du protocole RTSP étendu et encapsulé dans SSL ou TLS, et ce, quel que soit le type de réseau sous-jacent. Cependant, le standard IPsec ne peut être utilisé sur de tels réseaux, aussi, le chiffrement réalisé à l'aide des clefs échangées de cette manière sera-t- il encapsulé dans un autre protocole, dépendant du réseau sous-jacent, ou éventuellement un protocole non standard. Le point délicat de cette méthode de protection de contenu est l'échange de clefs. Déplacement, visualisation rapide et/ou inversée Le déplacement est la fonctionnalité qui permet à un client de demander à un streamer (ou au manager) d'émettre un flux à partir d'une position précise, par exemple jouer un film à partir de la douzième minute. Quant à la visualisation rapide et la visualisation inversée, elles correspondent aux fonctions d'avance et de retour rapide des magnétoscopes analogiques traditionnels. Déplacement Une notion importante à prendre en compte lors de la 35 prise en charge du déplacement par un streamer est celle de groupe d'images. Dans un flux vidéo numérique compressé, les images sont regroupées en séquences logiques, commençant par une image autonome, pouvant être décodée et affichée sans données supplémentaires, tandis que les autres images du groupe sont calculées en fonction de cette image de référence. L'implémentation du déplacement dans la solution selon l'invention prend cette particularité en compte, toute demande de déplacement est donc approchée et aboutit à un déplacement vers l'image autonome la plus proche de la cible du déplacement. Ainsi, un déplacement est-il réalisé plus rapidement du point de vue du client, dans la mesure où il peut commencer son travail de décodage dès qu'il reçoit les données émises à la suite du déplacement. Visualisation rapide et inversée Ces deux modes de visualisation sont réalisés en effectuant des déplacements à la fin de l'émission de chaque groupe d'images, en respectant le principe selon lequel l'émission à la suite d'un déplacement commence toujours avec une image autonome. Ces déplacements ont lieu en avant ou en arrière, et sont plus ou moins long en fonction de la vitesse de lecture. Une conséquence directe en est que seule une partie des groupes d'images est envoyée vers le client, les blocs d'images intermédiaires étant complètement ignorés. Cette technique correspond à la méthode indiquée par la RFC 2326 régissant le protocole RTSP. Conclusion L'invention permet donc la mise en place d'un serveur RTSP modulaire, capable de piloter différents streamers, et incluant un serveur http. L'invention permet en outre la protection de contenu. L'invention procure également une méthode de déplacement et de visualisation rapide mettant en oeuvre le protocole RTSP. REVENDICATIONS 1. Système de transmission numérique de séquences multimédia via un réseau de communication (7), notamment du type Internet ou ASM; ledit système comprenant: - des serveurs (3) connectés à des émetteurs (4a, 4b, 5 4c), notamment du type disque dur, antenne satellite, caméra vidéo, câble, des récepteurs (2), notamment du type récepteurs dédiés ou équipements informatiques connectés à des écrans de visualisation (6) de type téléviseur; lesdits serveurs (3) et lesdits récepteurs (2) étant connectés audit réseau de communication (7), notamment du type Internet ou ASM; ledit système étant caractérisé en ce qu'il comprend un serveur gestionnaire (8) connecté auxdits serveurs (3) ; ledit serveur gestionnaire (8) comportant des moyens de traitement informatiques destinés à : - interpréter et traiter des requêtes d'accès auxdites séquences multimédia (1) de type RTSP, - analyser et contrôler lesdites requêtes d'accès auxdites séquences multimédia de type RTSP, provenant desdits 20 récepteurs (2), - déterminer et contrôler en temps réel des niveaux d'activité desdits serveurs (3), - sélectionner au moins un serveur (3) parmi lesdits serveurs (3) en fonction desdites requêtes (1) et desdits 25 niveaux d'activité desdits serveurs, - commander auxdits serveurs ainsi sélectionnés la diffusion (5) desdites séquences multimédia vers lesdits récepteurs (2), via ledit réseau de communication (7), notamment du type Internet ou ASM, de sorte que le serveur gestionnaire assure le contrôle et la continuité de la diffusion des séquences multimédia; ledit serveur gestionnaire (8) comportant en outre des moyens informatiques de chiffrement, permettant de chiffrer lesdites séquences multimédia et lesdites requêtes au moyen de protocoles, notamment de type IPsec, SSL, TLS; lesdits moyens informatiques de chiffrement étant destinés à : - assurer la confidentialité et l'intégrité de la 5 réception desdites requêtes et de la diffusion desdites séquences multimédia, accélérer les temps de transition entre des séquences multimédia émises par des serveurs (3) différents.