FR2979785A1 - Procedes, programmes d'ordinateur et dispositifs de controle d'execution d'applications utilisant des identifiants d'utilisateurs mises en oeuvre apres etablissement de sessions de communication - Google Patents

Abstract

L'invention a notamment pour objet le contrôle d'exécution d'applications utilisant des identifiants d'utilisateurs mises en oeuvre après établissement de sessions de communication. A ces fins, au moins un message de contrôle d'exécution d'un traitement est échangé (415) entre un système de contrôle de traitements et un système de gestion de média lors de la mise en oeuvre dudit traitement, ledit traitement ayant été requis par un dispositif client auprès dudit système de contrôle de traitements, ladite requête de traitement déclenchant un établissement d'une session de communication entre ledit dispositif client et ledit système de gestion de média, permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média. Ledit au moins un message comporte un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication.

Description

La présente invention concerne la mise en oeuvre d'applications utilisant des identifiants d'utilisateurs, après établissement de sessions de communication, et plus particulièrement des procédés, des programmes d'ordinateur et des dispositifs de contrôle d'exécution d'applications utilisant des identifiants d'utilisateurs mises en oeuvre après établissement de sessions de communication.

Pour favoriser le développement d'applications multimédia visant les communications vocales, les communications audio et vidéo, les conférences vidéo et plus généralement les échanges de flux multimédia dans des réseaux de communication, notamment les réseaux de communication hétérogènes, une architecture connue sous le nom d'IMS (sigle d'Intemet protocol Multimedia Subsystem en terminologie anglo-saxonne) a été développée.

Comme illustré sur la figure 1, l'architecture IMS 100 peut être représentée par couches : une couche accès (notée Acc. sur la figure 1) pour permettre à des dispositifs clients 105-1 et 105-2 d'accéder à des applications et/ou services proposés. La couche accès est par exemple du type UTRAN (acronyme d'UMTS Terrestrial Radio Access Network, UMTS étant le sigle d'Universal Mobile Telecommunications System, en terminologie anglo-saxonne), xDSL (sigle de Digital Subscriber Line en terminologie anglo-saxonne) ou WiFi (WiFi est une marque) ; une couche transport (notée Trans. sur la figure 1) qui représente ici un réseau IP (sigle d'Intemet Protocol en terminologie anglo-saxonne). Cette couche consiste typiquement en des routeurs reliés par des réseaux de communication ; une couche contrôle (notée Ctrl sur la figure 1) qui est notamment utilisée pour contrôler les sessions de communication, en particulier, leur initiation. La couche de contrôle met généralement en oeuvre le protocole SIP (sigle de Session Initiation Protocol en terminologie anglo-saxonne) ; et, une couche application (notée Appl. sur la figure 1) qui contient des applications et services pouvant être appelés par des clients. La couche d'applications consiste typiquement en des serveurs d'applications 110, notés AS (sigle d'Application Server en terminologie anglo-saxonne), et des serveurs de média 115, notés MRF (sigle de Media Resource Function en terminologie anglo-saxonne). Plus précisément, les serveurs de média comprennent une composante MRFC dans la couche application et une composante MRFP dans la couche transport. Il est noté ici que la couche contrôle permet d'agréger plusieurs services.

Comme illustré sur la figure 1 par la flèche en trait continu, une telle architecture permet de transférer des données multimédia directement entre des dispositifs clients via des serveurs de média (MRF) après que des sessions de communication aient été établies. Typiquement, une session de communication est établie entre chaque dispositif client et un serveur de média. Ainsi, par exemple, pour connecter les dispositifs clients 105-1 et 105-2 entre eux, deux sessions de communication sont établies. A ces fins, un flux de signalisation (représenté par des flèches en trait pointillé sur la figure 1) est établi entre les dispositifs clients et au moins un serveur d'applications. En outre, des liens de communication (non représentés) sont établis entre des serveurs d'applications et des serveurs de média pour permettre un contrôle d'exécution des applications et des services appelés. De tels liens de communication sont généralement mis en oeuvre à l'aide du protocole SIP. L'architecture IMS peut notamment être utilisée pour mettre en oeuvre des services tels que des services de conférence selon lesquels plusieurs personnes se connectent à un même service qui est alors partagé entre elles. Un tel exemple est illustré sur la figure 2.

Les solutions de conférence qui existent aujourd'hui génèrent un identifiant unique, généralement appelé Participant ID, pour chaque participant, afin de les identifier dans le service de conférence invoqué. Cet identifiant est utilisé dans tout échange entre le serveur d'applications et le serveur de média impliqués concernant le participant. De tels échanges ont typiquement pour objet de contrôler des fonctions devant être exécutées dans le cadre du service, par exemple jouer une annonce ou terminer un appel, et contrôler la transmission de données entre le dispositif client et le serveur de média. Selon la configuration de l'architecture IMS utilisée, les identifiants Participant ID sont générés par un serveur d'applications (qui gère la logique applicative) ou par un serveur de média qui traite la conférence en elle-même.

A titre d'illustration et comme représenté sur la figure 2, les identifiants Participant ID sont générés par les serveurs d'applications. Lorsqu'un utilisateur souhaite lancer un service de conférence, une requête est émise par son dispositif 105 à destination d'un serveur d'applications pour lancer le service. Cette requête initie l'établissement d'une session de communication entre le dispositif 105 et un serveur d'applications et entre ce serveur d'applications et un serveur de média, constituant une session de communication entre le dispositif 105 et ce serveur de média, pour permettre la transmission de données multimédia entre le dispositif 105 et ce serveur de média. A ces fins, une requête SIP (notée SIP(Call_ID) sur la figure 2) est ici transmise au serveur d'applications (AS) 110 contrôlant l'exécution du service de conférence. Il est rappelé ici que conformément au standard SIP, la requête d'établissement d'une session de communication comprend un identifiant de session unique, généralement appelé Cali ID. Une requête similaire (également notée SIP(Call_ID) sur la figure 2) est transmise à un serveur de média (MRF) 115 identifié par un répartiteur de charge (aussi appelé LoadBalancer en terminologie anglo-saxonne), pour permettre l'établissement d'une session de communication entre le serveur d'applications 110 et ce serveur de média. A nouveau, le protocole utilisé ici pour transmettre la requête est le protocole SIP. Suite à la réception par le serveur d'applications 110 de la requête SIP et parallèlement à son traitement, le serveur d'applications génère un identifiant Participant ID lié au dispositif de l'utilisateur duquel est issue la requête (noté Gen. ID appl. sur la figure 2). Comme indiqué précédemment, cet identifiant est utilisé par le serveur d'applications pour contrôler l'exécution de la conférence sur le serveur de média. Ce contrôle est effectué par un échange de messages via un lien de commande établi entre le serveur d'applications 110 et le serveur de média 115.

Un lien de commande correspond ici à une session de communication spécifique établie entre un serveur d'applications et un serveur de média, dédiée au pilotage d'un serveur de média par un serveur d'applications (pour tous les utilisateurs et tous les services). Le serveur d'applications mémorise la correspondance entre l'identifiant Participant ID généré et l'identifiant Call ID correspondant (noté Mem. ID SIP/appl. sur la figure 2).

Après avoir généré l'identifiant applicatif Participant ID, le serveur d'applications 110 le transmet au serveur de média 115 pour permettre le contrôle ultérieur de la conférence via un lien de commande. Généralement, le serveur d'applications 110 utilise le protocole SIP pour transmettre l'identifiant applicatif Participant ID en transmettant la requête d'établissement d'une session de communication entre le serveur de média et le dispositif client.

Comme le serveur d'applications, le serveur de média mémorise la correspondance entre l'identifiant Participant ID généré et l'identifiant Cali ID correspondant (noté Mem. ID SIP/appl. sur la figure 2). S'il n'existe pas de lien de commande entre le serveur d'applications 110 et le serveur de média 115, un tel lien de commande est établi.

Ainsi, en utilisant l'identifiant applicatif Participant ID et le lien de commande (noté LCmd sur la figure 2) établi entre le serveur d'applications 110 et le serveur de média 115, le serveur d'applications 110 peut contrôler le serveur de média 115, vis-à-vis du service appelé, en particulier pour exécuter des fonctions prédéterminées telles que jouer une annonce ou terminer un appel. L'identifiant de session Cali ID est utilisé par le serveur d'applications et le serveur de média pour faire le lien entre le dispositif client et le service appelé auquel est associé, pour le client considéré, l'identifiant applicatif Participant ID. Lorsqu'une session de communication est établie entre le dispositif client 105 et le serveur d'applications 110 et entre le serveur d'applications 110 et le serveur de média 115, formant une session de communication entre le dispositif client 105 et le serveur de média 115 et permettant au serveur d'applications 110 de contrôler le serveur de média 115, des données multimédia peuvent être échangées entre le dispositif client 105 et le serveur de média 115 (noté data sur la figure 2). Ainsi, en d'autres termes, le serveur d'applications génère un identifiant Participant ID qui est transmis au serveur de média en transmettant la requête SIP d'établissement d'une session de communication entre le serveur de média, le serveur d'applications et le dispositif client. Le serveur d'application corrèle, de façon interne, la session SIP ayant l'identifiant Call ID et le lien de commande applicatif ayant l'identifiant Participant ID pour permettre la gestion de plusieurs identifiants. Le serveur de média doit également réaliser la corrélation entre la session SIP et le lien de commande applicatif correspondant.

Cette solution est aujourd'hui couramment utilisée dans les services de conférence car elle offre une certaine flexibilité et une certaine liberté aux serveurs d'applications dans la gestion de leurs identifiants. En outre, elle fait abstraction du protocole de signalisation utilisé (typiquement le protocole SIP). Néanmoins, cette solution présente des limitations, notamment en ce qui concerne la gestion des identifiants. En effet, les serveurs d'applications doivent s'assurer qu'ils ne génèrent pas deux identifiants identiques pour deux participants différents. Le problème se pose en particulier lors de l'utilisation d'un seul serveur de média par deux serveurs d'applications (ou plus). En outre, une telle mise en oeuvre implique une tâche particulière de corrélation entre la session SIP (Cali ID) et le lien de commande applicatif (Participant ID) qui nécessite des ressources et représente une source potentielle d'erreur. Par ailleurs, une telle mise en oeuvre rend très difficile l'utilisation d'un répartiteur de charge entre les serveurs d'applications et les serveurs de média, car il doit aussi gérer la corrélation entre les sessions SIP et les liens applicatifs. Un des objets de l'invention est d'apporter des améliorations par rapport à l'état de. la technique. L'invention a notamment pour objet un procédé d'échange de messages entre un système de contrôle de traitements et un système de gestion de média lors de la mise en oeuvre d'un traitement, ledit traitement ayant été requis par un dispositif client auprès dudit système de contrôle de traitements, ladite requête de traitement déclenchant un établissement d'une session de communication entre ledit dispositif client et ledit système de gestion de média, permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média, ledit procédé d'échange comprenant une étape d'émission d'au moins un message de contrôle d'exécution dudit au moins un traitement entre ledit système de contrôle de traitements et ledit système de gestion de média, ledit au moins message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication. Le procédé selon l'invention permet ainsi, notamment, l'échange de messages de contrôle d'exécution de traitements, basés sur des identifiants de session (échangés lors de l'établissement de sessions), ne nécessitant pas la génération ni le transfert d'identifiants applicatifs particuliers. Par conséquent, moins de messages sont transmis via le réseau reliant le système de contrôle de traitements et le système de gestion de média impliqués, optimisant l'utilisation de ce dernier. En outre, le procédé selon l'invention permet d'optimiser les codes sources utilisés pour contrôler l'exécution de traitements, ainsi que leurs performances, en ce qu'il n'est plus nécessaire de générer des identifiants applicatifs particuliers, de les transmettre ni de les corréler avec des identifiants de session. Par conséquent, les serveurs mettant en oeuvre ces codes sources sont également optimisés. Le procédé selon l'invention permet également de faciliter et optimiser l'utilisation de répartiteurs de charge utilisés pour identifier des systèmes de gestion de média devant être utilisés. Selon un mode de réalisation particulier, ledit au moins un message est une commande dudit système de gestion de média par ledit système de contrôle de traitements, ladite commande permettant audit système de contrôle de traitements de piloter au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client.

Le procédé selon l'invention ne nécessite donc pas, pour ledit système de contrôle de traitements, la génération ni le transfert d'identifiants applicatifs particuliers. Moins de messages sont transmis par ce dernier, optimisant l'utilisation du réseau utilisé. Il en résulte que les codes sources utilisés pour contrôler l'exécution de traitements sont optimisés, ainsi que leurs performances.

Toujours selon un mode de réalisation particulier, ledit au moins un message est une notification dudit système de contrôle de traitements par ledit système de gestion de média concernant au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client. Le procédé selon l'invention ne nécessite donc pas, pour ledit système de gestion de média, la réception d'identifiants applicatifs particuliers ni la corrélation de ces derniers avec des identifiants de sessions. Moins de messages étant reçus par ce système, l'utilisation du réseau utilisé est optimisée. Il en résulte que les codes sources utilisés pour contrôler l'exécution de traitements sont optimisés, ainsi que leurs performances. L'invention a également pour objet un dispositif de pilotage pour transmettre au moins une commande sous forme d'au moins un message d'un système de contrôle de traitements à un système de gestion de média lors de la mise en oeuvre d'un traitement, ledit système de contrôle de traitements comprenant des moyens pour recevoir d'un dispositif client une requête de traitement et initier un établissement d'une session de communication entre ledit dispositif client et ledit système de gestion de média permettant, durant la mise en oeuvre dudit traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média, ledit dispositif de pilotage comprenant des moyens pour transmettre audit système de gestion de média au moins un message de contrôle dudit au moins un traitement, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication, ledit au moins un message étant au moins une commande permettant audit système de contrôle de traitements de piloter au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client. L'invention a aussi pour objet un dispositif de notification pour transmettre au moins une notification sous forme d'au moins un message d'un système de gestion de média à un système de contrôle de traitements lors de la mise en oeuvre d'un traitement, ledit système de gestion de média comprenant des moyens pour recevoir dudit système de contrôle de traitements une requête d'établissement d'une session de communication entre un dispositif client et ledit système de gestion de média permettant, durant la mise en oeuvre dudit traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média, ledit dispositif de notification comprenant des moyens pour transmettre audit système de contrôle de traitements au moins un message de contrôle dudit traitement, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication, ledit au moins un message étant au moins une notification dudit système de contrôle de traitements par ledit système de gestion de média concernant au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client. L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé d'échange de messages décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. Les avantages procurés par ces dispositifs et ce programme d'ordinateur sont similaires à ceux évoqués précédemment. L'invention a également pour objet un procédé de mise en oeuvre d'un traitement requis par un dispositif client à un système de contrôle de traitements, ledit procédé de mise en oeuvre dudit traitement comportant une exécution d'une partie dudit traitement pour ledit dispositif client en réponse à un message de contrôle dudit système de contrôle de traitements audit système de gestion de média, ledit message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à une session de communication entre le dispositif client et ledit système de gestion média, ladite session de communication établie suite à la requête de traitement permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média.

Le procédé selon l'invention permet ainsi, notamment, l'exécution de traitements en réponse à la réception de messages de contrôle d'exécution de traitements, basés sur des identifiants de session (échangés lors de l'établissement de sessions), ne nécessitant pas la réception d'identifiants applicatifs particuliers ni leur corrélation avec des identifiants de session. Moins de messages étant reçus, l'utilisation du réseau utilisé est optimisée. Il en résulte que les codes sources utilisés pour l'exécution de traitements sont optimisés, ainsi que leurs performances. A nouveau, le procédé selon l'invention permet de faciliter et optimiser l'utilisation de répartiteurs de charge utilisés pour identifier les systèmes de gestion de média devant être utilisés. Selon un mode de réalisation particulier, le procédé comprend en outre, en réponse à ladite exécution de ladite partie dudit traitement, une étape de transmission d'un message de notification dudit système de contrôle de traitements par ledit système de gestion de média, ledit message de notification comprenant ledit identifiant unique de session. Une telle notification permet au système de contrôle de traitements de surveiller et contrôler l'exécution du traitement et/ou de ses éléments.

L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé de mise en oeuvre d'un traitement décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. L'invention a aussi pour objet un dispositif de mise en oeuvre d'un traitement comprenant des moyens pour recevoir d'un dispositif client une requête dudit traitement, ledit dispositif comportant des moyens pour contrôler l'exécution d'une partie dudit traitement dans un système de gestion de média par une transmission d'au moins un message audit système de gestion de média, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à une session de communication entre le dispositif client et ledit système de gestion média, ladite session de communication établie suite à la réception de ladite requête de traitement permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média. L'invention a aussi pour objet un dispositif de mise en oeuvre d'un traitement requis par un dispositif client à un système de contrôle de traitements, ledit dispositif comprenant des moyens pour recevoir des messages dudit système de contrôle de traitements et des moyens pour exécuter une partie dudit traitement en réponse à un message reçu dudit système de contrôle de traitements, ledit message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à une session de communication entre le dispositif client et un système de gestion média, ladite session de communication établie suite à la requête de traitement permettant, durant la mise en oeuvre dudit traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média. Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour transmettre un message de notification de ladite exécution audit système de contrôle de traitements, ledit message de notification comprenant ledit identifiant unique de session L'invention a également pour objet un système de contrôle de traitements comportant le dispositif de pilotage décrit précédemment, ledit système de contrôle de traitements pouvant être un serveur d'applications, ainsi qu'un système de gestion de média comportant le dispositif de notification décrit précédemment.

Les avantages procurés par ce programme d'ordinateur, ces dispositifs et ces systèmes sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un exemple d'architecture de type IMS ; - la figure 2 illustre la mise en oeuvre standard d'une application de type conférence dans une architecture telle que celle illustrée sur la figure 1 ; - la figure 3 illustre la mise en oeuvre d'une application de type conférence dans une architecture telle que celle illustrée sur la figure 1, conformément à l'invention ; - la figure 4 illustre un exemple simplifié de chronogramme pour appeler, conformément à l'invention, une application ou un service permettant le transfert de données multimédia entre un dispositif client et un serveur de média ; et, - la figure 5 représente un exemple d'architecture matérielle adaptée à mettre en oeuvre certaines étapes de l'invention. Conformément à l'invention, des identifiants de session générés pour l'établissement de sessions de communication sont également utilisés comme identifiants applicatifs pour le contrôle d'exécution de traitements, typiquement d'applications, entre systèmes de contrôle d'applications et systèmes de gestion de média, typiquement entre serveurs d'applications (AS) et serveurs de média (MRF). Il n'est ainsi pas nécessaire de générer des identifiants applicatifs spécifiques, de les transmettre, ni de les corréler avec des identifiants de session. Il est tout d'abord rappelé que, lors de l'établissement d'une session de communication utilisant un protocole tel que SIP, le module de contrôle de protocole (aussi appelé, en terminologie anglo-saxonne, pour le protocole SIP, stack SIP) génère un identifiant de réseau unique, appelé identifiant de session et noté Cali ID. L'identifiant de session généré est requis dans tous les messages échangés. En outre, il est conforme à un format prédéterminé. Conformément à l'invention, cet identifiant de session est utilisé par le serveur d'applications et le serveur de média pour contrôler l'exécution du traitement (application ou service) demandé, faisant l'objet de l'établissement de la session de communication, via des messages de contrôle (commande et/ou notification) échangés entre le serveur d'applications et le serveur de média. En d'autres termes, lorsqu'un serveur d'applications est sollicité par un client pour lancer un traitement, il associe à l'instance de ce traitement, propre à ce client, cet identifiant de session. Ce dernier étant transmis aux serveurs de média impliqués via ce serveur d'applications, tous les serveurs impliqués dans l'exécution du traitement appelé sont en mesure de faire le lien entre le client et l'instance de ce traitement ainsi qu'entre les parties de cette dernière exécutées dans ce serveur d'applications et ce serveur de média en utilisant l'identifiant de session qui est propre au client considéré. Ainsi, l'invention réside notamment dans le fait que l'identifiant de participant utilisé dans des messages de contrôle échangés entre un serveur d'applications et un serveur de média est un identifiant d'appelant/requérant, c'est-à-dire celui utilisé par la session de communication pour le dispositif client. Par conséquent, un seul identifiant est utilisé pour chaque dispositif client pour gérer la fonction d'accès à un traitement et la fonction liée au traitement lui-même. Les messages échangés entre un serveur d'applications et un serveur de média pour contrôler l'exécution du traitement sont typiquement des commandes de pilotage du serveur d'applications vers le serveur de média pour commander l'envoi et/ou la réception de données multimédia par le serveur de média au dispositif client, des notifications d'accusé réception du serveur de média au serveur d'applications d'une commande de pilotage permettant par exemple au serveur d'applications de passer à une étape suivante dans le traitement et des notifications d'état du traitement ou du dispositif client déclenchant, par exemple, la clôture de la session de communication du participant ou des sessions de communication associées au traitement.

Le serveur d'applications ou le serveur de média recevant de tels messages peut simplement, en consultant l'identifiant contenu dans le message, transmettre dans une session de communication ayant le même identifiant, des données multimédia de ou à destination du dispositif client associé à cette session de communication ou piloter une future session de communication avec le même identifiant client. La figure 3 illustre la mise en oeuvre d'une application de type conférence dans une architecture telle que celle illustrée sur la figure 1, conformément à l'invention. Lorsqu'un utilisateur souhaite appeler un service tel qu'un service de conférence à l'aide d'un dispositif client 305 comme un dispositif pourvu d'un téléphone logiciel (couramment appelé softphone), une session de communication est initiée par ce dernier (notée SIP(Call_ID) sur la figure 3). A ces fins, une requête d'initiation de session de communication est transmise du dispositif client 305 à un serveur d'applications 310 (ce dernier étant typiquement identifié par un identifiant du service appelé, par exemple un numéro de téléphone, et éventuellement choisi parmi plusieurs par un module de répartition de charge). Si la requête reçue par l'appelant ne comprend pas d'identifiant de session (Cali ID), cet identifiant est généré par le module de contrôle de protocole (ici le stack SIP). Cette requête ou une requête similaire est ensuite transmise par le serveur d'applications 310 à un serveur de média 315, ce dernier étant typiquement identifié parmi plusieurs par un module de répartition de charge. Cette requête (notée SIP(Call_ID) sur la figure 3) contient toujours l'identifiant de session Cali ID précédemment reçu ou généré. Conformément à l'invention, cet identifiant est notamment utilisé dans des messages de contrôle d'exécution du service appelé. Ces messages de contrôle d'exécution sont transmis via un lien de commande (noté LCmd(Call_ID)) sur la figure 3) établi entre le serveur d'applications 310 et le serveur de média 315 et utilisé par le serveur d'applications 310 pour contrôler l'exécution de traitements, applications et/ou services dans le serveur de média 315. S'il n'existe pas de lien de commande entre le serveur d'applications 310 et le serveur de média 315, un tel lien de commande est établi en initiant une session de communication spécifique. L'utilisation de l'identifiant de session pour échanger des messages de contrôle via le lien de commande, c'est-à-dire comme identifiant applicatif, permet d'éviter la génération et l'échange entre le serveur d'applications et le serveur de média d'un identifiant applicatif spécifique. En outre, le même identifiant étant utilisé comme identifiant de session et comme identifiant applicatif, il n'est pas nécessaire d'établir une correspondance entre ces deux identifiants dans le serveur d'applications et le serveur de média, ce qui simplifie également la fonction de répartition de charge. L'établissement d'une session de communication entre le dispositif client 305 et le serveur d'applications 310 et entre le serveur d'applications 310 et le serveur de média 315 forme une session de communication (correspondant à l'identifiant Cali ID) entre le dispositif client 305 et le serveur de média 315.

Ensuite, lorsqu'une telle session de communication est établie et qu'un lien de commande existe entre le serveur d'applications 310 et le serveur de média 315 pour échanger des messages de contrôle, des données multimédia (notées data sur la figure 3) peuvent être échangées entre le dispositif 305 et le serveur de média 315.

La figure 4 illustre un exemple simplifié de chronogramme pour appeler, conformément à l'invention, une application ou un service permettant le transfert de données multimédia entre un dispositif client 305, par exemple un dispositif pourvu d'un téléphone logiciel, et un serveur de média 315. Comme illustré, une première étape consiste ici, pour le dispositif client 305 pourvu d'un téléphone logiciel, à transmettre une requête d'exécution d'un traitement, d'une application ou d'un service à un serveur d'applications (étape 400), par exemple une requête conforme au protocole SIP, initiant l'établissement d'une session de communication. Le serveur d'applications auquel est adressée cette requête est par exemple déterminé selon un identifiant prédéterminé connu de l'utilisateur du téléphone logiciel du dispositif client 305, par exemple un numéro de téléphone, et, le cas échéant, un module de répartition de charge. Cet identifiant prédéterminé est ici propre au traitement, à l'application ou au service appelé. Comme indiqué précédemment, un identifiant de session (Cali ID) est associé à la requête. Il peut être déterminé par le module de contrôle de protocole du dispositif client 305 pourvu d'un téléphone logiciel, du serveur d'applications 310 ou d'un équipement intermédiaire.

Une requête similaire à celle reçue par le serveur d'applications est alors transmise à un serveur de média 315 (étape 405), le serveur de média étant identifié, dans un ensemble de serveurs de média, par un module de répartition de charge. Cette requête contient le même identifiant de session que celui reçu ou généré par le serveur d'applications (Cali ID) et permet l'établissement d'une session de communication entre le serveur d'applications 310 et le serveur de média 315 pour former une session de communication entre le dispositif client 305 et le serveur de média 315 ayant l'identifiant de session reçu ou généré. S'il n'existe pas de lien de commande entre le serveur d'applications 310 et le serveur de média 315, un tel lien de commande est établi (étape 410) en initiant une session de communication spécifique.

L'identifiant de session, reçu ou généré par le serveur d'applications, est alors utilisé pour échanger des messages de contrôle propres au service ou à l'application appelé et au dièpositif client 305, entre le serveur de média 315 et le serveur d'applications 310, via le lien de commande (LCmd) (étape 415). Ces messages permettent au serveur d'applications 310 de piloter l'exécution de l'application ou du service appelé sur le serveur de média 315, permettant notamment le transfert de données multimédia entre le dispositif client 305 pourvu d'un téléphone logiciel et le serveur de média 315 (étape 420). Ils permettent également au serveur de média 315 de notifier au serveur d'applications 310 des événements ou des états propres au service ou à l'application appelé. Comme décrit précédemment, l'utilisation d'un même identifiant comme identifiant de session et comme identifiant applicatif permet d'éviter la génération et l'échange entre le serveur d'applications et le serveur de média d'un identifiant applicatif spécifique ainsi que l'établissement d'une correspondance entre ces deux identifiants dans le serveur d'applications et le serveur de média. Naturellement d'autres dispositifs clients peuvent appeler le même service pour pe'rmettre l'échange de données multimédia entre plusieurs dispositifs clients. Par ailleurs, il est observé ici que si le service visé dans l'exemple décrit est un service de conférence, l'invention peut être mise en oeuvre pour l'exécution de tout traitement, application et service nécessitant l'utilisation d'un identifiant unique d'utilisateur, qui sont mis en oeuvre dans un premier système et contrôlée par un second système, après établissement d'une session de communication entre ce premier système et dispositif client. De même, si, pour des raisons de clarté, le contrôle d'exécution d'applications requises par des dispositifs client ainsi que la transmission de messages de contrôle sont ici mis en oeuvre par des serveurs d'applications et des serveurs de média, il est observé qu'un tel contrôle d'exécution et qu'une telle transmission de messages de contrôle peuvent être mis en oeuvre dans des dispositifs et/ou systèmes distincts de ces serveurs et reliés à eux, notamment dans des répartiteurs de charges. La figure 5 illustre un exemple d'architecture matérielle d'un dispositif 500 adapté à mettre en oeuvre certaines étapes de l'invention. Cette architecture peut être celle du dispositif 305 comprenant un téléphone logiciel, du serveur d'applications 310 et/ou du serveur de média 315. Il comporte ici un bus de communication 505 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 510 (CPU) ; - une mémoire morte 515 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter des programmes (prog) nécessaires à la mise en oeuvre de ; - une mémoire vive ou mémoire cache 520 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 550 (Interface comm.) adaptée à transmettre et à recevoir des données.

Le dispositif 500 dispose également, de préférence, d'un disque dur 535 (DD) pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention et d'un lecteur de cartes mémoires 540 (Lec. C) adapté à recevoir une carte mémoire 545 (C) et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 535 ou en mémoire morte 515.

Selon une variante, la carte mémoire 545 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 500, est stocké dans le disque dur 535. Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 550, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés.

L'unité centrale 510 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 535 ou dans la mémoire morte 515 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 535 ou la mémoire morte 515, sont transférés dans la mémoire vive 520 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (15)

1. REVENDICATIONS1. Procédé d'échange de messages entre un système de contrôle de traitements (310) et un système de gestion de média (315) lors de la mise en oeuvre d'un traitement, ledit traitement ayant été requis par un dispositif client (305) auprès dudit système de contrôle de traitements, ladite requête de traitement déclenchant un établissement d'une session de communication entre ledit dispositif client et ledit système de gestion de média, permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média, ledit procédé d'échange comprenant une étape d'émission d'au moins un message de contrôle d'exécution (415) dudit au moins un traitement entre ledit système de contrôle de traitements et ledit système de gestion de média, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication.
2. 2. Procédé d'échange selon la revendication 1 selon lequel ledit au moins un message est une commande dudit système de gestion de média par ledit système de contrôle de traitements, ladite commande permettant audit système de contrôle de traitements de piloter au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client.
3. 3. Procédé d'échange selon la revendication 1 selon lequel ledit au moins un message est une notification dudit système de contrôle de traitements par ledit système de gestion de média concernant au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client.
4. 4. Dispositif de pilotage pour transmettre au moins une commande sous forme d'au moins un message d'un système de contrôle de traitements (310) à un système de gestion de média (315) lors de la mise en oeuvre d'un traitement, ledit système de contrôle de traitements comprenant des moyens pour recevoir d'un dispositif client (305) une requête de traitement et initier un établissement d'une session de communication entre ledit dispositif client et ledit système de gestion de média permettant, durant la mise en oeuvre dudit traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média, ledit dispositif de pilotage comprenant des moyens pour transmettre audit système de gestion de média au moins un message de contrôle dudit au moins un traitement, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication, ledit au moins un message étant au moins une commande permettant audit système de contrôle de traitements de piloter au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client.
5. 5. Dispositif de notification pour transmettre au moins une notification sous forme d'au moins un message d'un système de gestion de média (315) à un système de contrôle de traitements (310) lors de la mise en oeuvre d'un traitement, ledit système de gestion de médiacomprenant des moyens pour recevoir dudit système de contrôle de traitements une requête d'établissement d'une session de communication entre un dispositif client (305) et ledit système de gestion de média permettant, durant la mise en oeuvre dudit traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média, ledit dispositif de notification comprenant des moyens pour transmettre audit système de contrôle de traitements au moins un message de contrôle dudit traitement, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à ladite session de communication, ledit au moins un message étant au moins une notification dudit système de contrôle de traitements par ledit système de gestion de média concernant au moins une partie dudit traitement mis en oeuvre par ledit système de gestion de média pour ledit dispositif client.
6. 6. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé d'échange de messages selon la revendication 1 lorsque ledit programme est exécuté sur un ordinateur.
7. 7. Procédé de mise en oeuvre d'un traitement requis par un dispositif client (305) à un système de contrôle de traitements (310), ledit procédé de mise en oeuvre dudit traitement comportant une exécution d'une partie dudit traitement pour ledit dispositif client en réponse à un message de contrôle dudit système de contrôle de traitements audit système de gestion de média, ledit message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à une session de communication entre le dispositif client et ledit système de gestion média, ladite session de communication établie suite à la requête de traitement permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média.
8. 8. Procédé selon la revendication 7 comprenant en outre, en réponse à ladite exécution de ladite partie dudit traitement, une étape de transmission d'un message de notification dudit système de contrôle de traitements par ledit système de gestion de média, ledit message de notification comprenant ledit identifiant unique de session.
9. 9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé de mise en oeuvre d'un traitement selon la revendication 7 lorsque ledit programme est exécuté sur un ordinateur.
10. 10.Dispositif de mise en oeuvre d'un traitement comprenant des moyens pour recevoir d'un dispositif client (305) une requête dudit traitement, ledit dispositif comportant des moyens pour contrôler l'exécution d'une partie dudit traitement dans un système de gestion de média par une transmission d'au moins un message audit système de gestion de média, ledit au moins un message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à une session de communication entre le dispositif client et ledit système de gestion média, ladite session de communication établie suite à la réception de ladite requête de traitement permettant, durant la mise en oeuvre du traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média.
11. 11. Dispositif de mise en oeuvre d'un traitement requis par un dispositif client (305) à un système de contrôle de traitements (310), ledit dispositif comprenant des moyens pour recevoir des messages dudit système de contrôle de traitements et des moyens pour exécuter une partie dudit traitement en réponse à un message reçu dudit système de contrôle de traitements, ledit message comportant un identifiant de traitement correspondant à un identifiant unique de session associé à une session de communication entre le dispositif client et un système de gestion média (315), ladite session de communication établie suite à la requête de traitement permettant, durant la mise en oeuvre dudit traitement, au moins une transmission de données multimédia entre ledit dispositif client et ledit système de gestion de média.
12. 12.Dispositif selon la revendication 11 comprenant en outre des moyens pour transmettre un message de notification de ladite exécution audit système de contrôle de traitements, ledit message de notification comprenant ledit identifiant unique de session
13. 13.Système de contrôle de traitements comportant le dispositif de pilotage selon la revendication 4 et le dispositif de traitement selon la revendication 10.
14. 14.Système de contrôle selon la revendication 13 selon lequel ledit système de contrôle de traitements est un serveur d'applications.
15. 15.Système de gestion de média comportant le dispositif de notification selon la revendication 5 et le dispositif de traitement selon la revendication 11.20