FR2971658A1

FR2971658A1 - Systeme de controle de mise en œuvre d'un service multimedia

Info

Publication number: FR2971658A1
Application number: FR1151166A
Authority: FR
Inventors: Herve Gerard
Original assignee: ALTERVOICE
Current assignee: ALTERVOICE
Priority date: 2011-02-14
Filing date: 2011-02-14
Publication date: 2012-08-17

Abstract

Un système contrôle la mise en œuvre d'un service multimédia impliquant un dispositif de traitement de données multimédias. Un serveur d'application du système génère des messages selon un protocole de contrôle pour contrôler le dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia. Le système comporte un serveur fournisseur d'un scénario décrit dans un format de description de contrôle d'appel avec balises à appliquer par le serveur d'application pour mettre en œuvre le service multimédia. Le serveur d'application reçoit (4.1) les données au format de description de contrôle d'appel avec balises pour détecter des balises prédéterminées, les interprète (4.3) et génère (4.8) les messages, en ce qui concerne le protocole de contrôle et le protocole de gestion de session multimédia, en fonction de balises détectées.

Description

La présente invention concerne le contrôle de la mise en oeuvre d'un service multimédia dans un réseau de communication multimédia. De manière à fournir des services multimédias à des terminaux fixes et mobiles, les acteurs de la téléphonie ont développé des architectures appelées IMS (IP Multimedia Subsystem en anglais) basé sur le protocole IP (Internet Protocol en anglais) permettant de faire converger l'Internet et le monde de la téléphonie, et notamment de la téléphonie cellulaire. Ces architectures IMS utilisent typiquement le protocole de signalisation SIP (Session Initiation Protocol en anglais) tel que défini par le standard RFC-3261, afin de créer, modifier et terminer des sessions de communication multimédia entre serveurs et terminaux, qu'ils soient mobiles ou fixes. Ces architectures IMS comportent trois composantes pour la mise en oeuvre de services : un ou plusieurs serveurs SIP AS (SIP Application Server en anglais), un ou plusieurs serveurs S-CSCF (Serving Call State Control Function en anglais) et un ou plusieurs serveurs MRF (Media Resource Function en anglais). Les serveurs SIP AS hébergent la logique de mise en oeuvre des services multimédias et sont en charge de leur exécution. Les serveurs S-CSCF sont en charge du routage de la signalisation jusqu'aux terminaux des usagers et de l'invocation des services auprès des serveurs SIP AS. Les serveurs MRF comportent des fonctions de transmission de données multimédias. En d'autres termes, les serveurs MRF fournissent typiquement le contenu multimédia des services invoqués. Plus généralement, les serveurs MRF comportent des fonctions de traitement de données multimédias. Lorsqu'un service multimédia est requis par un usager via son terminal, mobile ou fixe, le serveur S-CSCF qui lui est associé invoque typiquement le service requis auprès du serveur SIP AS concerné. Le serveur SIP AS met ensuite en relation le serveur MRF concerné et ce serveur S-CSCF, afin de fournir le service multimédia à l'usager. Les données multimédias sont alors typiquement échangées entre le serveur MRF et le serveur S-CSCF par utilisation du protocole de transport temps-réel RTP (Real-time Transport Protocol en anglais) tel que défini par le standard RFC 3550. Les scénarii relatifs à ces services multimédias sont ainsi développés et mis en oeuvre de manière intégrée aux serveurs SIP AS. Ils sont ainsi dépendants, dans leur conception, des plateformes matérielles et logicielles sur lesquelles les serveurs SIP AS sont implémentés. Une telle architecture manque ainsi de flexibilité pour faire évoluer les services multimédias.

Il est souhaitable de pallier ces différents inconvénients de l'état de la technique. Il est notamment souhaitable de rendre la conception de tels services multimédias indépendante du contrôle du réseau de communication multimédia nécessaire pour leur mise en oeuvre.

L'invention concerne un système destiné à être utilisé dans un réseau de communication multimédia pour contrôler la mise en oeuvre d'un service multimédia impliquant un dispositif de traitement de données multimédias dudit système, ledit système comportant un serveur d'application comportant des moyens de génération d'au moins un message selon un protocole de contrôle pour contrôler ledit dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia. Ledit système est tel qu'il comporte un serveur fournisseur d'un scénario à appliquer par le serveur d'application pour mettre en oeuvre ledit service multimédia, ledit scénario étant décrit sous la forme d'au moins une page, dans un format de description de contrôle d'appel avec balises. De plus, ledit serveur d'application comporte des moyens de réception de ladite ou desdites page(s), en provenance dudit serveur fournisseur du scénario ; des moyens d'interprétation (2.7) de données au format de description de contrôle d'appel avec balises, adaptés pour détecter des balises prédéterminées dans la ou les page(s) reçue(s), afin de mettre en oeuvre ledit scénario. De plus, lesdits moyens de génération sont adaptés pour générer ledit ou lesdits messages, en ce qui concerne ledit protocole de contrôle et ledit protocole de gestion de session multimédia, en fonction de balises détectées. Ainsi, de par le format de description du scénario qui est un de contrôle d'appel avec balises et les moyens d'interprétation du serveur d'application, un concepteur peut développer un service multimédia sur le serveur fournisseur de scénario, et le faire évoluer, de manière externe au serveur application. Le concepteur s'abstrait en outre de la gestion effective des ressources réseau pour mettre en oeuvre le service multimédia, alors que le format de contrôle d'appel avec balises permet à la fois de décrire le scénario tant au niveau des connexions ou sessions à établir que des commandes à transmettre.

L'invention concerne également un dispositif, dit serveur d'application, destiné à être utilisé dans un réseau de communication multimédia pour contrôler la mise en oeuvre d'un service multimédia impliquant un dispositif de traitement de données multimédias dudit réseau, ledit serveur d'application comportant des moyens de génération d'au moins un message selon un protocole de contrôle pour contrôler ledit dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia. Le serveur d'application est tel qu'il comporte des moyens de réception d'au moins une page, dans un format de description de contrôle d'appel avec balises, décrivant un scénario à appliquer par le serveur d'application pour mettre en oeuvre ledit service multimédia ; des moyens d'interprétation de données au format de description de contrôle d'appel avec balises, adaptés pour détecter des balises prédéterminées dans la ou les page(s) reçue(s), afin de mettre en oeuvre ledit scénario. De plus, lesdits moyens de génération sont adaptés pour générer ledit ou lesdits messages, en ce qui concerne ledit protocole de contrôle et ledit protocole de gestion de session multimédia, en fonction de balises détectées. Selon un mode de réalisation particulier, des balises dans la ou les page(s) reçue(s) étant associées à des attributs, lesdits moyens de génération sont en outre adaptés pour générer ledit ou lesdits messages en fonction des attributs associés aux balises détectées lorsque les balises détectées sont associées à des attributs. Ainsi, la conception de service est rendue plus flexible. Selon un mode de réalisation particulier, le serveur d'application comportant des moyens de mise en oeuvre d'un automate à états en fonction dudit scénario, il comporte en outre : des moyens de réception de messages représentatifs d'événements respectifs, en provenance dudit dispositif de traitement de données multimédias, selon le protocole de contrôle embarqué dans le protocole de gestion de session multimédia ; des moyens d'extraction d'au moins un attribut de l'événement à partir de chaque message reçu ; des moyens de création d'un événement au format de description de contrôle d'appel avec balises, en fonction dudit ou desdits attribut(s) extrait(s), ledit événement créé étant destiné à être traité par lesdits moyens de mise en oeuvre de l'automate à états. Ainsi, l'ensemble des interactions avec le dispositif de traitement de données peut être pris en compte par le concepteur directement selon le format de description du scénario. Selon un mode de réalisation particulier, le serveur d'application comportant des moyens de mise en oeuvre d'un automate à états en fonction dudit scénario, il comporte en outre : des moyens de transmission d'une requête à un serveur dudit réseau en vue de l'exécution d'un traitement de données ; des moyens de réception d'une réponse à la requête transmise ; des moyens d'extraction d'un résultat relatif à l'exécution du traitement de données par ledit serveur ; des moyens de création d'un événement au format de description de contrôle d'appel avec balises, en fonction dudit résultat extrait, ledit événement créé étant destiné à être traité par lesdits moyens de mise en oeuvre de l'automate à états. Ainsi, le concepteur peut, directement selon le format de description du scénario, requérir que le serveur d'application délègue un traitement. Selon un mode de réalisation particulier, le format de description de contrôle d'appel avec balises est le format CCXML. CCXML (Cal/ Control eXtensible Markup Language en anglais) défini dans le document W3C « Voice Browser Call Control: CCXML Version 1.0 », par exemple dans sa version du 1" avril 2010.

Selon un mode de réalisation particulier, le protocole de gestion de session multimédia est le protocole SIP et le protocole de contrôle est le protocole MSCML, le protocole MSML ou le protocole NETANN. MSCML (Media Server Control Markup Language en anglais) est défini dans le standard RFC 5022 et MSML (Media Server Markup Language en anglais) dans le standard RFC 5707 NETANN dans le standard RFC 4240, et dans le standard RFC 5552 en ce qui concerne le support d'instructions de type VoiceXML. Selon un mode de réalisation particulier, le protocole de contrôle étant le protocole MSCML ou le protocole MSML, lesdits moyens d'interprétation sont adaptés pour détecter des balises identifiant au moins une commande selon ledit protocole de contrôle incluse dans la ou les page(s) reçue(s) et lesdits moyens de génération sont adaptés pour générer au moins un message incluant respectivement ladite commande ou lesdites commandes. Ainsi, il est possible d'inclure dans la description CCXML des commandes ou instructions comprises de manière native par des serveurs MRF.

L'invention concerne également un procédé de contrôle de mise oeuvre d'un service multimédia par un dispositif, dit serveur d'application, d'un réseau de communication multimédia, ledit service multimédia impliquant un dispositif de traitement de données multimédias dudit réseau, ledit procédé comportant une étape de génération d'au moins un message selon un protocole de contrôle pour contrôler ledit dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia. Le procédé est tel que le serveur d'application effectue des étapes de réception d'au moins une page, dans un format de description de contrôle d'appel avec balises, décrivant un scénario à appliquer par le serveur d'application pour mettre en oeuvre ledit service multimédia ; interprétation des données de la ou les page(s) reçue(s), afin de mettre en oeuvre ledit scénario ; détection de balises prédéterminées dans les données interprétées. De plus, ladite étape de génération est telle que ledit ou lesdits messages sont générés, en ce qui concerne ledit protocole de contrôle et ledit protocole de gestion de session multimédia, en fonction de balises détectées. L'invention concerne également un programme d'ordinateur comportant des instructions pour permettre à un processeur d'implémenter le procédé mentionné ci-dessus. L'invention concerne également des moyens de stockage comportant un tel programme d'ordinateur.

Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : - la Fig. 1 illustre schématiquement un réseau de communication multimédia, 15 dans lequel la présente invention peut être mise en oeuvre ; - les Figs. 2 et 3 illustrent respectivement, de manière schématique, des premier et second modes de réalisation d'un serveur d'application dudit réseau ; - les Figs. 4 et 5 illustrent respectivement, de manière schématique, des premier et second algorithmes mis en oeuvre par le serveur d'application. 20 La Fig. 1 illustre schématiquement un réseau de communication multimédia, dans lequel la présente invention peut être mise en oeuvre. Le réseau selon la Fig. 1 comporte un système 1.0 basé sur une architecture IMS. Le système 1.0 comporte un serveur SIP AS 1.2, un serveur S-CSCF 1.3 et un serveur MRF 1.4. Le système 1.0 peut comporter un ou plusieurs de ces serveurs. Le 25 serveur SIP AS 1.2 est en relation avec le serveur S-CSCF 1.3 et le serveur MRF 1.4 dans le cadre de la mise en oeuvre d'un service multimédia, et contrôle le serveur MRF 1.4 grâce à un protocole de contrôle tel que le protocole NETANN, MSCML ou MSML. Le serveur SIP AS 1.2 utilise un protocole de gestion de session multimédia, tel que le protocole SIP, pour mettre en relation le serveur S-CSCF 1.3 et le serveur 30 MRF 1.4 pour échanger des données multimédias, par exemple selon le protocole RTP. Le protocole de gestion de session multimédia encapsule le protocole de contrôle pour permettre le contrôle du serveur MRF 1.4 dans le cadre de la mise en oeuvre du service multimédia.

Le serveur SIP AS 1.2 est en outre en relation avec au moins un serveur fournisseur d'application, dit serveur Web 1.1, sur lequel le concepteur du service multimédia met à disposition une description de scénario de mise en oeuvre du service. Ainsi, pour mettre en oeuvre le service multimédia, le serveur SIP AS 1.2 obtient cette description auprès du serveur Web 1.1, interprète cette description et met en oeuvre le service multimédia en suivant le scénario décrit. La description peut correspondre à un automate à états spécifiant le comportement que doit avoir le serveur SIP AS 1.2 pour mettre en oeuvre le service multimédia. La description du scénario est mise à disposition par le serveur Web 1.1 sous forme d'au moins une page selon un format de description avec balises. Ce format est préférentiellement le format CCXML. L'utilisation faite par le serveur SIP AS 1.2 de cette description de scénario est plus amplement détaillée ci-après en relation avec les Figs. 4 et 5. La Fig. 2 correspond à une réalisation particulière sous forme matérielle du serveur SIP AS 1.2, qui peut être alors sous la forme d'une machine ou d'un composant dédié, tel qu'un FPGA (Field-Programmable Gate Array en anglais) ou un ASIC (Application-Specific Integrated Circuit en anglais). Le serveur SIP AS 1.2 comporte alors : un gestionnaire de session 2.1 ; un module de formatage SIP 2.5 ; un module de formatage HTTP (Hypertext Transfer Protocol en anglais) 2.6, tel que défini par le standard RFC-2616 ; un module de transport UDP (User Datagram Protocol en anglais) 2.3, tel que défini par le standard RFC 768 ; un module de transport TCP (Transport Control Protocol en anglais) 2.4, tel que défini par le standard RFC 793 ; un module de formatage IP 2.2, tel que défini par le standard RFC 791. Le gestionnaire de session 2.1 peut échanger des messages SIP avec les dispositifs du réseau, via le module de formatage SIP 2.5, le module de transport UDP 2.3 et le module de formatage IP 2.2. Le gestionnaire de session 2.1 peut échanger des messages HTTP avec les dispositifs du réseau, via le module de formatage HTTP 2.6, le module de transport TCP 2.4 et le module de formatage IP 2.2. Le serveur SIP AS 1.2 comporte en outre, un interpréteur XML (eXtended Markup Language en anglais) 2.7, tel que défini dans le document W3C «XML 1.0 Specification » dans sa version du 26 novembre 2008 ; un interpréteur CCXML 2.8 ; et un moteur exécutant des instructions au format ECMAScript 2.9, tel que défini dans le standard ISO/IEC-16262 «ECMAScript Language Specification » du 1" juin 2002, connecté à l'interpréteur CCXML 2.8. Le gestionnaire de session 2.1 utilise les fonctions des interpréteurs XML 2.7 et CCXML 2.8, tel que décrit ci-après en relation avec les Figs. 4 et 5. La Fig. 3 correspond à une mise en oeuvre sous forme logicielle du serveur SIP AS 1.2, par exécution d'un ensemble d'instructions par une machine programmable, tel qu'un DSP (Digital Signal Processor en anglais) ou un processeur. Le serveur SIP AS 1.2 comporte alors, reliés par un bus de communication 3.1 : un processeur 3.2 ; une mémoire RAM (Random Access Memory en anglais) 3.3 ; une mémoire ROM (Read Only Memory en anglais) 3.4 ; un lecteur 3.5 de support de stockage, tel qu'un disque dur ; et des moyens d'interface 3.6 avec les autres dispositifs du réseau. Le processeur 3.2 est capable d'exécuter des instructions chargées dans la mémoire RAM 3.3 à partir de la mémoire ROM 3.4, d'un support de stockage ou d'un réseau de communication (non représenté). A la mise sous tension du serveur SIP AS 1.2, le processeur 3.2 lit des instructions de la mémoire RAM 3.3 et les exécute. Ces instructions forment un programme d'ordinateur causant la mise en oeuvre, par le processeur 3.2, de tout ou partie des algorithmes décrits ci-après en relation avec les Figs. 4 et 5. La Fig. 4 illustre schématiquement un algorithme, mis en oeuvre par le serveur SIP AS 1.2, suite à l'invocation du service multimédia par le serveur S-CSCF 1.3. Dans une étape 4.1, le serveur SIP AS 1.2 reçoit le scénario, associé au service multimédia invoqué, de la part du serveur Web 1.1. Le scénario est reçu sous la forme d'au moins une page au format CCXML. Le serveur SIP AS 1.2 peut recevoir une première page au format CCXML, puis au fil de l'exécution du scénario comme décrit ci-après, le serveur SIP AS 1.2 peut avoir à requérir une nouvelle page auprès du serveur Web 1.1. Une arborescence de pages est ainsi utilisée et chaque page est transférée en fonction des besoins du scénario. Dans une étape 4.2 suivante, le serveur SIP AS 1.2 commence l'interprétation CCXML, au moyen du module interpréteur CCXML 2.8. Le gestionnaire de session 2.1 crée le contexte, paramètres et variables, de la session de mise en oeuvre du service invoqué. Dans une étape 4.3 suivante, le serveur SIP AS 1.2 effectue l'interprétation CCXML pour mettre en oeuvre le scénario décrit, qui prend fin dans une étape 4.12. L'étape 4.3 peut être schématiquement décomposée comme suit, en focalisant sur la gestion du serveur MRF 1.4. Dans une étape 4.4, le serveur SIP AS 1.2 effectue des actions en fonction du scénario décrit, comme par exemple l'envoi de messages à destination d'autres dispositifs du réseau ou l'exécution locale de traitement de données, et ce en fonction des balises interprétées dans les pages CCXML reçues. Lors de la détection de la balise CCXML appropriée, telle que la balise <dialogstart> ou <createconference>, le serveur SIP AS 1.2 ouvre une session SIP avec le serveur MRF 1.4 grâce à un message SIP INVITE. Le serveur SIP AS 1.2 peut effectuer d'autres actions, suite à cette ouverture de session, en suivant le scénario décrit en CCXML. Dans une étape 4.5 suivante, le serveur SIP AS 1.2 se met en attente d'un événement. Cette mise en attente est représentative d'un fonctionnement en automate d'états préférentiellement identifiés par une balise <eventprocessor>. Un tel événement peut être local, tel que lié à l'expiration d'une temporisation préprogrammée, ou externe, tel que lié à la réception d'un message, comme décrit ci-après en relation avec la Fig. 5. Selon le type d'événement détecté tel que décrit dans le scénario, le serveur SIP AS 1.2 effectue soit une étape 4.6, dans laquelle il effectue une action locale, comme par exemple initialiser une temporisation, soit il effectue une étape 4.7, 4.9 ou 4.11. Lorsque l'événement indique une fin de mise en oeuvre du service, suite par exemple à la détection de la balise <dialogterminate> ou <destroyconference>, dans l'étape 4.11, le serveur SIP AS 1.2 met fin à la session ouverte à l'étape 4.4 et transmet un message SIP BYE au serveur MRF 1.4. Lors de l'étape 4.7, le serveur SIP AS 1.2 convertit au moins une balise CCXML, et les attributs qui lui sont éventuellement associés, en un message SIP INFO. En outre, le message SIP encapsule des commandes au format MSCML ou MSML. Ces commandes sont incorporées directement dans les données CCXML et préférentiellement marquées par la balise <send>. Les commandes au format MSCML ou MSML sont alors incorporées telles quelles dans le message SIP INFO. Il est aussi possible que l'ensemble de la description de scénario soit au format CCXML et que le serveur SIP AS 1.2 convertisse les balises dédiées, et leurs éventuels attributs, en commandes MSCML ou MSML. Lors d'une étape 4.8 suivante, le serveur SIP AS 1.2 transmet le message SIP créé au serveur MRF 1.4. L'étape 4.5 est à nouveau exécutée. Dans une variante de réalisation, le serveur SIP AS 1.2 convertit au moins une balise CCXML, et les attributs qui lui sont éventuellement associés, en un message SIP INVITE encapsulant le protocole NETANN. Le message SIP INVITE sert alors à la fois à créer la session avec le serveur MRF 1.4 et à lui transmettre une commande de traitement de données multimédias, telle que la commande play (lecture en français) pour une annonce (service annc) ou une réponse vocale interactive (service ivr). Une fois le traitement effectué, le serveur SIP AS 1.2 reçoit un message SIP BYE du serveur MRF 1.4 mettant fin à la session. Lors de l'étape 4.9, le serveur SIP AS 1.2 convertit au moins une balise CCXML, et les attributs qui lui sont associés, en un message HTTP correspondant. Ce type de message permet de faire appel à des fonctions sur des serveurs accessibles via l'Internet, et permet ainsi au serveur SIP AS 1.2 de déléguer des traitements de données, comme par exemple la vérification d'un code d'authentification reçu du serveur MRF 1.4 selon l'algorithme de la Fig. 5. Le serveur SIP AS 1.2 transmet, lors d'une étape 4.10 suivante, le message HTTP créé et reçoit en retour le résultat du traitement aussi selon l'algorithme de la Fig. 5. L'étape 4.5 est à nouveau exécutée. La représentation de la Fig. 4 est schématique, en ce sens que les étapes 4.6, 4.7 et 4.8, et 4.9 et 4.10 peuvent être agencées différemment en fonction de l'interprétation des pages CCXML reçues. Par exemple, les étapes 4.7 et 4.8 peuvent être effectuées séquentiellement avec les étapes 4.8 et 4.9 si le scénario le requiert, sans qu'un événement soit spécifiquement généré. La Fig. 5 illustre schématiquement un algorithme, mis en oeuvre par le serveur SIP AS 1.2, suite à une détection de messages en provenance du serveur MRF 1.4 ou d'un serveur auquel un traitement a été délégué à l'étape 4.10. Dans une étape 5.1, un message SIP INFO comportant des données au format MSCML ou MSML est reçu, s'il est en provenance du serveur MRF 1.4, ou un message HTTP est reçu, s'il est en provenance du serveur auquel un traitement a été délégué. Dans une étape 5.2 suivante, le corps du message est interprété par l'interpréteur XML 2.7 qui crée en conséquence au moins un objet au format ECMAScript dans une étape suivante 5.3. Cet objet ECMAScript est alors mis en correspondance avec un événement CCXML, tel que décrit dans le scénario, au moyen du moteur 2.9. Un événement CCXML, tel que dialog.user.notification ou dialog.user.response, est alors généré dans une étape 5.4 suivante, pour être traité par le serveur SIPAS 1.2 au cours de l'étape 4.5. Il est à noter que le format ECMAScript est orienté objet, qui convient particulièrement pour transposer au format CCXML des données au format MSCML ou MSML, qui sont alors sous forme de liste d'attributs.

Claims

REVENDICATIONS1) Système destiné à être utilisé dans un réseau de communication multimédia pour contrôler la mise en oeuvre d'un service multimédia impliquant un dispositif de traitement de données multimédias (1.4) dudit système, ledit système comportant un serveur d'application comportant des moyens de génération (2.1,2.5) d'au moins un message selon un protocole de contrôle pour contrôler ledit dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia, caractérisé en ce que ledit système comporte un serveur (1.1) fournisseur d'un scénario à appliquer par le serveur d'application pour mettre en oeuvre ledit service multimédia, ledit scénario étant décrit sous la forme d'au moins une page, dans un format de description de contrôle d'appel avec balises ; et en ce que ledit serveur d'application comporte : - des moyens de réception (2.2,2.4,2.6) de ladite ou desdites page(s), en provenance dudit serveur fournisseur du scénario ; - des moyens d'interprétation (2.7) de données au format de description de contrôle d'appel avec balises, adaptés pour détecter des balises prédéterminées dans la ou les page(s) reçue(s), afin de mettre en oeuvre ledit scénario ; et en ce que lesdits moyens de génération sont adaptés pour générer ledit ou lesdits messages, en ce qui concerne ledit protocole de contrôle et ledit protocole de gestion de session multimédia, en fonction de balises détectées.
2) Dispositif, dit serveur d'application (1.2), destiné à être utilisé dans un réseau de communication multimédia pour contrôler la mise en oeuvre d'un service multimédia impliquant un dispositif de traitement de données multimédias (1.4) dudit réseau, ledit serveur d'application comportant des moyens de génération (2.1,2.5) d'au moins un message selon un protocole de contrôle pour contrôler ledit dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia, caractérisé en ce qu'il comporte : - des moyens de réception (2.2,2.4,2.6) d'au moins une page, dans un format de description de contrôle d'appel avec balises, décrivant un scénario à appliquer par le serveur d'application pour mettre en oeuvre ledit service multimédia ;- des moyens d'interprétation (2.7) de données au format de description de contrôle d'appel avec balises, adaptés pour détecter des balises prédéterminées dans la ou les page(s) reçue(s), afin de mettre en oeuvre ledit scénario ; et en ce que lesdits moyens de génération sont adaptés pour générer ledit ou lesdits messages, en ce qui concerne ledit protocole de contrôle et ledit protocole de gestion de session multimédia, en fonction de balises détectées.
3) Dispositif selon la revendication 2, des balises dans la ou les page(s) reçue(s) étant associées à des attributs, caractérisé en ce que lesdits moyens de génération sont en outre adaptés pour générer ledit ou lesdits messages en fonction des attributs associés aux balises détectées lorsque les balises détectées sont associées à des attributs.
4) Dispositif selon l'une quelconque des revendications 2 et 3, caractérisé en ce que, le dispositif comportant des moyens (2.1) de mise en oeuvre d'un automate à états en fonction dudit scénario, il comporte en outre : - des moyens de réception (2.2,2.3,2.5) de messages représentatifs d'événements respectifs, en provenance dudit dispositif de traitement de données multimédias, selon le protocole de contrôle embarqué dans le protocole de gestion de session multimédia ; - des moyens d'extraction (2.8) d'au moins un attribut de l'événement à partir de chaque message reçu ; - des moyens de création (2.9) d'un événement au format de description de contrôle d'appel avec balises, en fonction dudit ou desdits attribut(s) extrait(s), ledit événement créé étant destiné à être traité par lesdits moyens de mise en oeuvre de l' automate à états.
5) Dispositif selon l'une quelconque des revendications 2 à 4, caractérisé en ce que, le dispositif comportant des moyens (2.1) de mise en oeuvre d'un automate à états 30 en fonction dudit scénario, il comporte en outre : - des moyens de transmission (2.2,2.4,2.6) d'une requête à un serveur dudit réseau en vue de l'exécution d'un traitement de données ; - des moyens de réception (2.2,2.4,2.6) d'une réponse à la requête transmise ;- des moyens d'extraction (2.8) d'un résultat relatif à l'exécution du traitement de données par ledit serveur ; - des moyens de création (2.9) d'un événement au format de description de contrôle d'appel avec balises, en fonction dudit résultat extrait, ledit événement créé étant destiné à être traité par lesdits moyens de mise en oeuvre de l'automate à états.
6) Dispositif selon l'une quelconque des revendications 2 à 5, caractérisé en ce que le format de description de contrôle d'appel avec balises est le format CCXML.
7) Dispositif selon l'une quelconque des revendications 2 à 6, caractérisé en ce que le protocole de gestion de session multimédia est le protocole SIP, et en ce que le protocole de contrôle est le protocole MSCML, le protocole MSML ou le protocole NETANN.
8) Dispositif selon les revendications 6 et 7, caractérisé en ce que, le protocole de contrôle étant le protocole MSCML ou le protocole MSML, lesdits moyens d'interprétation sont adaptés pour détecter des balises identifiant au moins une commande selon ledit protocole de contrôle incluse dans la ou les page(s) reçue(s) et lesdits moyens de génération sont adaptés pour générer au moins un message incluant respectivement ladite commande ou lesdites commandes.
9) Procédé de contrôle de mise oeuvre d'un service multimédia par un dispositif (1.2), dit serveur d'application, d'un réseau de communication multimédia, ledit service multimédia impliquant un dispositif de traitement de données multimédias (1.4) dudit réseau, ledit procédé comportant une étape de génération d'au moins un message selon un protocole de contrôle pour contrôler ledit dispositif de traitement de données multimédias, ledit protocole de contrôle étant encapsulé dans un protocole de gestion de session multimédia, caractérisé en ce que le serveur d'application effectue des étapes de : - réception (4.1) d'au moins une page, dans un format de description de contrôle d'appel avec balises, décrivant un scénario à appliquer par le serveur d'application pour mettre en oeuvre ledit service multimédia ; - interprétation (4.2,4.3,4.12) des données de la ou les page(s) reçue(s), afin de mettre en oeuvre ledit scénario ; 5- détection de balises prédéterminées dans les données interprétées ; et en ce que ladite étape de génération (4.8) est telle que ledit ou lesdits messages sont générés, en ce qui concerne ledit protocole de contrôle et ledit protocole de gestion de session multimédia, en fonction de balises détectées.
10) Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour mettre en oeuvre, par un serveur d'application (1.2), le procédé selon la revendication 9, lorsque ledit programme est exécuté par un processeur (3.2) dudit serveur d'application. 10