Continuité des services multimédias dans l’IMS

Implémentation

 Cette fois encore, un prototype a été implémenté sur la plateforme ims d’AlcatelLucent (solution 5400 ias). Nous avions également à notre disposition des clients ims pour terminaux fixes et mobiles que nous pouvions modifier afin d’adapter les interfaces graphiques pour déclencher les mécanismes de transfert. Cependant l’objectif reste de proposer des solutions intégrables dans des environnements définis et non modifiables (pour des raisons d’interopérabilité), que ce soit l’infrastructure, les clients ou les protocoles impliqués. C’est pour cela que nous préfèrerons toujours les approches compatibles ou à défaut celles qui ont le moins d’impact sur les environnements existants. Les travaux ont porté spécifiquement sur les protocoles mms et rtsp, l’ensemble des mécanismes décrits ici étant indifféremment applicables (sauf mention contraire). Le protocole http quant à lui s’est révélé peu intéressant pour cette étude de par son aspect non standard, nous aurons cependant l’occasion de nous y intéresser dans le chapitre suivant. Le serveur de média utilisé est Windows Media Server et le lecteur multimédia est Windows Media Player, l’objectif conforme à notre stratégie (cf. 4.1) étant de proposer une solution transparente pour les clients comme pour les serveurs multimédias existants. Nous considérons dans cette section le scas dans sa globalité (continuité des communications et des flux multimédias) mais plus particulièrement les relations entre les différents composants pour offrir la continuité des services multimédias dans l’ims. Le scas tient le même rôle que précédemment, c’est à dire une application ims assurant la continuité des services de communications mais aussi maintenant celle des services multimédias et ce via un proxy média (cf. Figure 4.1) 

Scénario 

Le scénario est assez simple et n’implique maintenant plus qu’un seul utilisateur. Bob regarde une bande annonce de film sur son téléphone mobile ims doté d’un lecteur multimédia. Une fois arrivé chez lui, il préfèrerait continuer de regarder le média sur son ordinateur de bureau doté d’un écran bien plus large. Il déclenche alors le transfert (manuel ou automatique), une confirmation est requise sur le terminal destination puis la vidéo reprend à l’endroit même où il l’avait laissée (cf. Figure 4.2). Il est important de noter que les terminaux de Bob, que ce soit son mobile ou son ordinateur possèdent chacun un client ims, comme pour un transfert de service de communication.

 Architecture 

Les acteurs du scénario sont les suivants : – le terminal origine de Bob (téléphone mobile ims doté d’une lecteur multimédia), – le terminal destination de Bob (ordinateur de bureau avec client ims et lecteur multimédia), – infrastructure ims + serveur de présence (pour le mode automatique), – un serveur de médias qui délivre les flux vidéos, – le scas doté d’un proxy média. Nous allons nous intéresser maintenant aux mécanismes qui entrent en jeu dans cet environnement et plus particulièrement au scas et au proxy média lors de la mise en œuvre d’un transfert de service multimédia entre deux terminaux ims. Le service offert par le scas doit être a priori souscrit par Bob auprès de son opérateur ims afin que les mécanismes de continuité soient correctement mis en œuvre, exactement comme pour la continuité des services de communications (cf. 3.3.2).

Traçage des sessions

 Le scas trace et stocke les informations relatives aux abonnés du service de continuité. Comme pour les services de communications (cf. 3), ce mécanisme qui traite les informations des messages sip (sessions et états de présence) est initié lors de l’enregistrement du client ims auprès de son domaine, cf. Figure 3.6. Cependant les informations enregistrées dans les Logs ne se limitent pas à l’ims, le Media Proxy intervient également. C’est la « patte » du scas qui permet de tracer les informations relatives aux sessions multimédias échangées entre le lecteur et le serveur de médias. Ce composant doit obligatoirement jouer le rôle de proxy auprès du lecteur multimédia de l’utilisateur ims pour pouvoir intercepter les messages de signalisation. En effet, le Media Proxy doit être positionné entre le lecteur et le serveur de médias, cela peut se traduire par un composant réseau supplémentaire nécessitant une configuration du terminal (possible aujourd’hui avec la plupart des applications de ce type) ou une fonction spécifique intégrée au client. Cette deuxième approche est cependant plus complexe car elle requiert une 91 modification du client et l’instauration d’un interface supplémentaire entre celui-ci et l’infrastructure (le scas). Une fois en place en position de proxy, le Media Proxy joue plusieurs rôles. En premier lieu il reçoit l’ensemble des requêtes d’initiation des sessions multimédias provenant des terminaux utilisateurs abonnés au service scas (messages setup rtsp par exemple), cf. Figure 4.3. Un contrôle d’accès via le composant Access Control est alors réalisé afin de limiter l’utilisation du service aux seuls abonnés. En effet, si l’ims garantit ce contrôle, nous nous trouvons ici à l’extérieur de l’infrastructure, il est donc nécessaire d’implémenter un mécanisme similaire. Comme peu d’informations sont disponibles à partir des messages de signalisation du média et que le client ims est décorrélé du lecteur, nous avons choisi d’effectuer un contrôle d’accès par adresse ip, cf. 4.2.3. Lors de l’enregistrement ims de l’abonné, l’adresse réseau est collectée par le Session Logger du scas (cf. 3.3.2) puis transmise au Media Proxy pour être autorisée. Inversement, lorsque le client ims se désenregistre, l’adresse ip n’est plus autorisée et le lecteur média correspondant ne peut plus bénéficier des mécanismes de continuité du scas (il peut cependant lire des flux médias dans la mesure où il n’utilise plus le scas en tant que proxy.

Déclenchement

 Nous ne rentrerons pas dans le détail du déclenchement qui est tout à fait comparable à celui décrit dans le chapitre précédent (cf. 3.3.2) étant donné qu’il est réalisé depuis le client ims. Nous noterons simplement la difficulté de la désignation de la session multimédia. En effet si une session de communication est caractérisée par deux interlocuteurs clairement identifiés, ici ce n’est pas le cas : le lecteur n’est pas identifié et le serveur correspond généralement à une adresse Web (url), particulièrement illisible pour l’Homme. On pourra alors simplement supposer que l’association réalisée à partir de l’adresse ip permettant d’identifier l’utilisateur (cf. 4.2.3) est suffisante dans le mesure où il est fort probable qu’il ne regarde qu’un flux média à la fois. Le déclenchement est donc réalisé depuis la couche ims et aura pour conséquence d’initier le mécanisme de transfert directement par le Switch Processor du Media Proxy, cf. Figure 4.4. Des informations sont également envoyées vers le client ims qui déclenchera les mécanismes de handover relatifs au terminal (cf. section 4.3.3). Comme vu dans le chapitre précédent, des messages non standards doivent être transmis au client ims, ceci peut s’effectuer via des informations de présence spécifiques ou des requêtes sip de type message, dans tous les cas le client devra être capable de les interpréter.