Continuité des services multimédias dans le Web

Architecture 

Les différents acteurs de ce scénario sont les suivants : – le terminal de Lionel doté de : – un navigateur Web, – un lecteur multimédia (application dédiée ou plug-ins), – le client GGMedia (dans son environnement Google desktop) ; – le site du fournisseur Web de contenu multimédia (joue le rôle de serveur média), – le Media Proxy positionné entre le client et le site Web, – le Bookmark Server, serveur Web associé au Media Proxy. Nous allons nous intéresser à présent aux mécanismes clés qui entrent en jeu parmi ces acteurs représentés de manière schématique en Figure 5.2.

Identification

Le service de continuité est ici aussi uniquement fourni aux utilisateurs qui y ont souscrit, il est donc nécessaire d’identifier les clients pour assurer un contrôle d’accès permettant la commercialisation du service, la protection de la vie privée ou encore la mise en œuvre de mécanismes adéquats. L’identification est réalisée entre le client GGMedia et le Bookmark Server via un secret partagé délivré à la souscription. Des échanges via le protocole http transportant des messages de signalisation propriétaires (nous contrôlons le client et le serveur) permettent au client de communiquer l’adresse ip du terminal qui est alors stockée par le User Manager (dans la base de données utilisateurs User data) et autorisée au niveau du proxy, cf. Figure 5.3. Le Media Proxy pourra par la suite associer les sessions multimédias destinées à cette adresse ip à l’utilisateur en question. Une fois le client identifié, l’interface GGMedia-Bookmark Server permet le transfert de différentes informations concernant les sessions ou les bookmarks..

Traçage des sessions

Le Media Proxy joue toujours son rôle de proxy transparent entre le client et le serveur de médias. Or ici le client est double, il est à la fois le navigateur Web mais aussi le lecteur multimédia. Il doit donc savoir analyser plusieurs protocoles : http, mais aussi rtsp, mms, les messages de signalisation propriétaires (lecteurs basés sur la technologie Flash) et enfin les flux médias (rtp). Lorsqu’un flux média est requis par le navigateur Web, les requêtes correspondantes doivent passer par le proxy, il est donc nécessaire que le navigateur soit configuré de manière appropriée (disponible sur toutes les applications de ce type). Le Stream Logger et le Switch Processor présentés précédemment (cf. 4.3.3) doivent assurer différentes fonctions spécifiques à chaque protocole afin de capturer les informations permettant un transfert futur. Devant la multitude de solutions multimédias propriétaires présentes dans le Web, la continuité ne pourra être réalisée que pour un nombre limité de protocoles dont les mécanismes sont connus a priori. Nous avons étudié et implémenté les mécanismes de transfert pour les principales solutions rtsp, mms, Youtube, Google Video et Dailymotion afin de couvrir la large majorité des services existants, cependant l’implémentation du proxy a requis une attention particulière afin qu’il se comporte ne manière transparente vis à vis des protocoles non supportés. En effet, si la continuité n’est pas réalisable, il est indispensable que les mécanismes de mobilité restent imperceptibles pour l’expérience utilisateur. L’étude des protocoles propriétaires de Youtube, Dailymotion et Google Video a requis l’analyse des échanges http entre le client et le serveur. Ainsi c’est par un premier travail de reverse engineering qu’il a été possible de retrouver dans les échanges protocolaires la position courante d’un flux ou la manière de démarrer la lecture à une position précise. Maîtriser ces paramètres identifiés dans le chapitre précédent (url, position, etc) est la condition d’un transfert de session réalisable dans le cas des services multimédias. L’objectif final étant l’évaluation de la faisabilité de la continuité dans un environnement où coexistent de nombreux acteurs hétérogènes (en terme de mécanismes et de signalisation). 

Déclenchement

Le déclenchement du transfert est manuel, asynchrone et réalisé en deux temps. Tout d’abord l’utilisateur marque une session à une position spécifique en créant un bookmark depuis l’interface graphique du GGMedia. Il a alors la possibilité d’ajouter des informations (métadonnées) qu’il considère pertinentes : un titre, des commentaires, des tags, une image . . . dans un pur style Web 2.0. À noter que les métadonnées peuvent également être ajoutées par le Bookmark Manager, cf. 5.3.2 ; la Figure 5.4 présente un exemple de bookmark enrichi. La demande de création du marque-page média et les métadonnées sont envoyées vers le Bookmark Manager qui récupère l’url de la session et le timestamp correspondant à la position actuelle via le Media Proxy, cf. Figure 5.6. Le Session Manager stocke ensuite le bookmark ainsi créé et le communique à tous les clients GGMedia afin qu’il soit affiché à l’utilisateur, la Figure 5.5 présente un exemple de message envoyé aux clients décrivant les sessions et les bookmarks de l’utilisateur. Cette première étape marque la session comme « continuable » un peu comme la commande Switch dans le chapitre 3, mais cette fois-ci la position de reprise du service est définie a priori. La seconde partie du déclenchement n’est pas nécessairement immédiate, c’est l’utilisateur qui décide de l’initier quand il le souhaite. Il peut alors réaliser d’autres actions : marquer de nouveau la session et créer un bookmark supplémentaire, partager le bookmark avec des amis via divers canaux de communication (courrier électronique, réseau social, blog, Bookmark Manager, etc). Le bookmark permet ainsi de préparer le transfert mais est également un prétexte d’échange entre utilisateurs.L’utilisateur active la deuxième phase du déclenchement en exécutant un bookmark depuis l’interface graphique de son client GGMedia (cf. Figure 5.7). Le bookmark peut lui appartenir ou avoir été créé et partagé par un tiers. Quoi qu’il en soit, le Session Controller exécute l’application correspondant au type d’url (connu grâce à son préfixe associé par le se à une application spécifique). Le lecteur multimédia ou le navigateur Web charge directement l’url pour rétablir le média à la position indiquée dans le bookmark. 

Désignation

 Cependant le déclenchement en mode manuel pose ici un problème de désignation des sessions. en effet, celles-ci sont identifiées au niveau du système par leur url, unique pour un média donné. Mais cette information n’est pas satisfaisante pour l’utilisateur : trop longue et inintelligible. La nomination des bookmarks par l’utilisateur lors de la première phase du déclenchement est une action contraignante mais acceptable dans le cadre des bookmarks qui sont créés occasionnelles ment et ont un intérêt particulier pour l’utilisateur. Les sessions ne peuvent être gérées de la même manière, l’utilisateur serait sollicité à chaque établissement d’un flux, nuisant considérablement à son expérience du service offrant tout sauf de la continuité. . . Nous avons proposé un mécanisme qui permet de résoudre ce problème grâce à l’aspect collaboratif de la nomination des bookmarks. Tous les utilisateurs peuvent enrichir leurs bookmarks avec des métadonnées, une manière de les reconnaître et de leur apporter du sens dans la liste qu’ils constituent sur leur GGMedia. Ces informations sont spécifiques à un flux, lui-même identifié par une url. L’url correspond donc à un (ou plusieurs) sujet/thème qui apparaîtra naturellement dans les métadonnées des utilisateurs qui marqueront ce flux. Or il se trouve que les url des médias d’un fournisseur de contenus présentent des parties similaires, correspondant par exemple au diffuseur ou au type de programme. Ainsi, il est possible de donner du sens à ces parties d’url en détectant les zones communes qui génèrent les mêmes métédonnées, cf. Figure 5.1.