FR 2915651 A1 20081031 FR 0754737 A 20070427 L'invention concerne un procédé pour assurer la continuité du flux d'une session média dans un réseau IMS lors de la commutation d'un premier terminal média à un deuxième terminal média. L'invention concerne également un réseau de type IMS comprenant une application permettant l'accès à un flux média par l'intermédiaire d'au moins un premier et un deuxième terminal média, ladite application permettant d'assurer la continuité du flux média entre les terminaux. Le développement des télécommunications a permis à un nombre croissant de clients de disposer d'un ou plusieurs terminaux média, tels que des téléphones portables, des ordinateurs ou des assistants personnels numériques, via lesquels ils peuvent consulter des sessions média telles que des films. Pour permettre la communication entre des réseaux opérant sous différents protocoles, une architecture standardisée dite IMS (pour Internet Protocol Multimedia Subsystem) a été développée. IMS est une architecture multimédia ouverte qui utilise le protocole SIP (Session Initiation Protocol). Par mise en place de la méthode REFER , la continuité des sessions est assurée dans le réseau IMS. En effet, la méthode REFER du protocole SIP est une méthode offrant des capacités optimisées de transfert de flux au sein dudit protocole. Par ailleurs, on connait le protocole RTSP (Real Time Streaming Protocol, ou protocole de fluidité en temps réel), un protocole de communication destiné aux systèmes de flux média qui permet de contrôler un serveur média à distance, offrant des fonctionnalités typiques d'un lecteur vidéo et permettant un accès en fonction de la position temporelle. Toutefois, le protocole SIP ne supporte pas les caractéristiques de signalisation du protocole RTSP. En outre, le protocole RTSP ne supporte pas de commutation du flux d'une session média d'un premier terminal à un deuxième terminal en raison d'un défaut de caractéristique dans l'interaction Client/Serveur. Par conséquent, il n'existe pas de mode d'exécution permettant d'assurer la continuité du flux d'une session d'un premier terminal media à un deuxième terminal au sein d'un réseau IMS. L'utilisateur final qui est détenteur de plusieurs terminaux média et qui souhaite commuter une session en cours par transfert du flux média sur un autre terminal doit activer manuellement une ~o nouvelle session. Ainsi, la session média redémarre du début. Il en résulte pour l'utilisateur final un constat négatif en termes de qualité et une déception du fait de l'absence de commutation fluide de la session média. 15 L'invention a pour but de pallier les problèmes de l'art antérieur en proposant un procédé assurant la continuité du flux d'une session média dans un réseau IMS lors de la commutation d'un premier terminal média à un deuxième terminal média. 20 A cet effet, et selon un premier aspect, l'invention propose un procédé pour assurer la continuité du flux d'une session media dans un réseau IMS lors de la commutation d'un terminal media à un terminal media, lesdits terminaux étant connectables au serveur de la session media par l'intermédiaire de respectivement un serveur proxy, ledit procédé prévoyant : 25 de mettre en place et d'assurer une requête en commutation du flux ; - d'utiliser, un protocole de gestion en continu du flux media entre le terminal media et le serveur de media ; - d'implanter, dans chaque terminai, un composant, ledit composant étant apte à recevoir la requête en commutation du flux media et, en cas de 30 réception de ladite requête, à interagir avec le serveur media et avec l'autre composant pour contrôler la commutation de la session media afin d'assurer sa continuité. Selon un deuxième aspect, l'invention propose un réseau de type IMS comprenant une application permettant l'accès à un serveur de flux média par l'intermédiaire d'au moins un premier et un deuxième terminal média, lesdits terminaux étant connectés au serveur média par l'intermédiaire de respectivement un serveur proxy, ladite application comprenant une requête en commutation du flux média entre les terminaux, ladite application étant apte à communiquer ladite requête à un composant de respectivement un terminal média, pour contrôler la commutation en continu de la session média vers le terminal. D'autres particularités et avantages de l'invention apparaîtront dans la description qui suit, faite en relation avec les figures jointes dans lesquelles : la figure 1 représente une architecture générale de mise en place du 15 procédé de commutation du flux média selon l'invention ; la figure 2 représente un diagramme de séquence de la mise en oeuvre de ce procédé. L'invention concerne un procédé pour assurer la continuité du flux d'une 20 session média lors de la commutation d'un premier terminal média T1 à un deuxième terminal média T2 dans un réseau IMS 1. En relation avec la figure 1, il est décrit une architecture dans laquelle le procédé peut être mis en oeuvre de façon avantageuse. 25 Cette architecture comprend deux terminaux média T1, T2, par exemple sous la forme d'un ordinateur, d'un téléphone portable ou d'un assistant personnel numérique. Ces terminaux sont destinés à être connectés à un serveur média 6 émettant la session média à visualiser, par l'intermédiaire de respectivement un 30 serveur proxy. Chaque terminal média T1, T2 comprend trois composants principaux : - une interface SIP client 3 qui est à l'écoute des requêtes en commutation provenant soit de l'application 2 du réseau IMS 1, soit du client en cas de commutation manuelle ; - un lecteur de media 5, 8 de visualisation, par exemple du type Windows 5 Media Player ou Real Player ; une interface RTSP proxy client 4, 7 dans laquelle passent toutes les demandes RTSP qui partent du lecteur de media 5, 8. Le réseau IMS comprend une application 2 permettant l'accès au serveur de 10 flux média 6 par l'intermédiaire des terminaux média Ti, T2. L'application 2 comprenant une requête en commutation du flux média entre les terminaux Ti, T2 pour, en cas de détection de la présence d'un terminal T2, inviter à la commutation le terminal Ti en cours d'utilisation, de sorte à contrôler la commutation en continu de la session média vers l'autre terminal média T2. 15 En relation avec la figure 2, on décrit les séquences de mise en oeuvre d'un procédé pour assurer la continuité du flux d'une session média lors de la commutation d'un premier terminal média Ti à un deuxième terminal média T2 dans l'architecture décrite ci-dessus. Le lecteur de média 5 est connecté au serveur média 6 de sorte à visualiser un flux média lors d'une session A, par exemple une vidéo ou un enregistrement audio, sur un terminal média Ti par l'intermédiaire d'un serveur proxy. 25 Pour ce faire, le protocole de communication RTSP est employé afin d'assurer la gestion en continu du flux média entre le terminal média Ti en cours d'utilisation et le serveur média 6. Le protocole RTSP est apte à recevoir les requêtes en commutation du flux 30 média émises par le composant d'entrée RTSP/SIP 4, 7 implanté au niveau de chaque terminal Ti, T2. 205 Lorsque le client souhaite commuter manuellement le flux média vers le terminal média T2, il émet une requête en commutation B depuis le premier terminal T1. Pour ce faire, l'interface SIP client 3 envoie une requête en commutation vers son homologue 3 du deuxième terminal T2. En variante, la requête en commutation du flux média peut être émise automatiquement par l'application 2 après détection d'une donnée de présence lors de la connexion du terminal média T2 dans le réseau IMS. 10 La requête en commutation du flux média B est traitée par le composant d'entrée RTSP/SIP 4. Après réception de la requête en commutation du flux média, le composant 4 transmet une requête C à fins de commutation au composant 7 afin d'être informé sur les possibilités de commutation du flux média vers le terminal média T2. 15 Après avoir obtenu du composant 7 une information positive D quant à la commutation du flux média vers le terminal média T2, le composant 4 transmet au serveur média 6 une requête de Pause E de la session média en cours. 20 Le composant 4 émet ensuite une requête F auprès du serveur média 6 afin d'extraire l'index de temps de la session média en cours au niveau du terminal média T1 et afin d'obtenir les données relatives à la session média actuellement en cours au niveau du premier terminal média T1, à savoir, notamment : 25 l'adresse IP du terminal média T1 en cours d'utilisation ainsi que celle du terminal média T2 objet de la requête en commutation, l'URL du flux média à commuter, l'identification de la session média en cours au niveau du terminal média 30 Ti, - le champ Cseq (utilisé pour identifier un message faisant partie d'une négociation d'invitation) contenant les séquences de chiffres correspondant à la requête en commutation émise.5 Après réception des informations relatives audit index de temps et audites données dans la réponse G, le composant 4 émet une requête H de coupure de flux auprès du serveur média 6 qui lui répond I. Ensuite, le composant 4 transmet J lesdites données au composant 7. Le composant 7 échange ensuite avec le lecteur de média 8 une requête de Play K qui lui renvoie la requête de Play L avec un index de temps nul. 10 Le composant 7 transmet alors au serveur média 6 une requête M de Play de la session média comprenant au moins certaines des données transférées par le serveur média 6. Concomitamment à l'émission de cette requête de Play , le composant 7 remplace l'index de temps par celui en cours au niveau du terminal média TI lors de l'émission de la requête de Pause 15 Le serveur média 6 commute alors la session média vers le lecteur 8 du terminal média T2, ladite session démarrant en N au temps indiqué lorsque la session média initiale avait été arrêtée du fait de la requête de Pause . REVENDICATIONS 1. Procédé pour assurer la continuité du flux d'une session media dans un réseau IMS (1) lors de la commutation d'un terminal media (T1) à un terminal media (T2), lesdits terminaux étant connectables au serveur (6) de la session media par l'intermédiaire de respectivement un serveur proxy, ledit procédé prévoyant : - de mettre en place et d'assurer une requête en commutation du flux 10 media ; d'utiliser un protocole de gestion en continu du flux media entre le terminal media (T1, T2) et le serveur de media (6) ; - d'implanter, dans chaque terminal, un composant (4), ledit composant étant apte à recevoir la requête en commutation du flux media et, en cas 15 de réception de ladite requête, à interagir avec le serveur media (6) et avec l'autre composant (7) pour contrôler la commutation de la session media afin d'assurer sa continuité. 2. Procédé selon la revendication 1, dans lequel la requête en commutation 20 du flux média est émise par le client du terminal média (T1). 3. Procédé selon la revendication 1, dans lequel la requête en commutation du flux média est automatiquement émise par une donnée de présence lors de la connexion du terminal média (T2) dans le réseau IMS (1). 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel, après réception de la requête en commutation, le composant (4) transmet une requête à fins de commutation au composant (7) afin d'être informé sur les possibilités de commutation du flux média vers le terminal média (T2). 30 5. Procédé selon la revendication 4, dans lequel, en cas d'information positive transmise par le composant (7) quant à la commutation du terminal media (T2), le composant (4) extrait auprès du serveur média (6) les données relatives à la 25session en cours au niveau du terminal média (T1), lesdites données étant transférées au composant (7). 6. Procédé selon la revendication 5, dans lequel les données extraites sont choisies dans le groupe comprenant les adresses IP des terminaux media, l'URL du flux média à commuter, l'identification de la session média en cours, le champ Cseq, l'index de temps de la session média en cours. 7. Procédé selon la revendication 5 ou 6, dans lequel, préalablement au transfert des données au composant (7), le composant (4) transmet au serveur de média (6) une requête de Pause de la session de média en cours. 8. Procédé selon l'une quelconque des revendications 5 à 7, dans lequel, après transfert des données, le composant (7) intercepte la première requête 15 de Play émise par le terminal média (T2) et introduit dans ladite requête au moins certaines données transférées avant de communiquer ladite requête au serveur média (6). 9. Réseau de type IMS comprenant une application permettant l'accès à un 20 serveur de flux média (6) par l'intermédiaire d'au moins un premier et un deuxième terminal média (T1, T2), lesdits terminaux étant connectés au serveur média (6) par l'intermédiaire de respectivement un serveur proxy, ladite application comprenant une requête en commutation du flux média entre les terminaux, ladite application étant apte à communiquer ladite requête à un 25 composant (4, 7) de respectivement un terminal média, pour contrôler la commutation en continu de la session média vers le terminal.