Brevet FR2877791A1 — publié le 20060512

PROCEDE DE PRODUCTION ET/OU DE COMMANDE AUTOMATIQUE D'UNE CONFERENCE DE TELECOMMUNICATION AVEC UNE PLURALITE D'ABONNES, TERMINAL DE CONFERENCE DE TELECOMMUNICATION ET SERVEUR DE CONFERENCE DE T.ELECOMMUNICATION L'invention concerne un procédé de production et/ou de commande automatique d'une conférence de télécommunication avec une pluralité de participants, un terminal de conférence de télécommunication, ainsi qu'un serveur de conférence de télécommunication. Le service désigné par Push-to-Talk over Cellular (PoC) permet à un utilisateur ou à un émetteur, après sélection d'un ou de plusieurs récepteurs et après avoir poussé une touche spéciale Push-to-Talk over Cellular (touche PoC), de transmettre É de la parole É à plusieurs récepteurs simultanément É suivant le procédé demi-duplex, c'est-à-dire que seul l'émetteur peut parler, tandis que les 20 récepteurs ne peuvent pas l'interrompre lorsqu'il parle. Dans ce service, les données vocales sont réparties habituellement pendant que l'émetteur parle déjà sur le réseau de télécommunication. Cela est désigné aussi par "streaming". Le Push-to-Talk over Cellular ressemble ainsi, du point de vue de l'utilisateur, au CB-radio habituel, avec toutefois l'élargissement que l'émetteur peut parler dans le monde entier à des récepteurs qui peuvent être atteints par la technique de commutation d'au moins un réseau de télécommunication, de préférence d'un réseau de communication de téléphonie mobile. Mais cela suppose que ceux-ci sont en ligne aussi à l'instant de l'établissement de la liaison de communication dans le réseau de télécommunication, cela signifiant, dans un réseau de communication de téléphonie mobile, qu'ils sont entrés en communication ou autrement dit qu'ils sont "online". Push-to-Talk over Cellular a été spécifié dans une première version dans un consortium d'industrie et est décrit dans [1]. D'autres activités se trouvent dans la commission de normalisation Open Mobile Alliance (OMA) et dans le 3e Generation Partnership Project (3GPP). Le Push-to-Talk over Cellular est, dans ce que l'on appelle le Packet-Switched-Domain (PS Domain, c'est-à-dire dans la partie à transmission par paquet du réseau de télécommunication; comme protocole de réseau de communication, il est réalisé sur le plan de la couche de transmission qui utilise l'Internet Protocol (IP). Il y a par session de groupe Push-to-Talk over Cellular (session de groupe Push-to-Talk over Cellular) un serveur Push-to-Talk over Cellular, ce que l'on appelle le Controlling-PoC-Server. Les dispositifs PoC-Client ont, pendant une session de groupe PoC, respectivement, par l'intermédiaire de ce que l'on appelle un Participating-Server qui l'aurait affecté, une liaison avec le Controlling-PoCServer. Pour la liaison de communication de signalisation entre un PoC-Client et un Participating-PoC-Server ou entre un Participating-PoC-Server et un Controlling-PoC-Server, on utilise, par exemple, le IP Multimedia Subsystem (IMS) qui utilise comme protocole de communication de signalisation ce que l'on appelle le Session Initiation Protocol (SIP), comme cela est décrit dans [2]. Pour la liaison de communication de transmission de données entre le PoC-Client et le Participating-PoC- Server ou entre le Participating-PoC-Server 15 20 25 30 et le Controlling-PoC-Server, on utilise ce que l'on appelle le Transport Protocol for Real Time Applications (RTP). Dans le Push-to-Talk, il y a de nos jours trois types différents de groupes PoC (groupes Push-to-Talk over Cellular) qui se distinguent essentiellement par la structure de la session de groupe PoC: É Ad-hoc-PoC-Group Session (session de groupes Ad-hoc-PoC) . Avant l'établissement d'une session de groupe Ad-hoc-PoC, l'initiateur de la session de groupe Ad-hoc-PoC dresse une liste d'utilisateurs PoC (PoC Usern), y compris leurs adresses, par exemple un numéro de téléphone sous la forme de SIP-URL (Session Initiation Protocol Unique Resource Locator) ou d'une adresse SIP sous la forme de SIP-URL. On notera à cet égard que la liste d'utilisateurs PoC peut être constituée aussi de seulement une personne. La liste est envoyée lors de l'établissement de la session de groupe Ad-hoc-PoC par le client PoC initiateur au Controlling-PoC-Server qui invite alors tous les utilisateurs PoC contenus dans la liste à la session de groupe Ad-hoc-PoC. Les utilisateurs PoC invités peuvent accepter cette invitation, la décliner ou même ne pas en tenir compte. É Pre-arranged-PoC-Group Session (session de groupe PoC pre-arranged) . Dans le cas où l'on souhaite toujours mener à nouveau avec les mêmes utilisateurs PoC une session de groupe PoC, un utilisateur PoC peut définir ses groupes fixes personnels et les faire connaître au Controlling-PoC-Server. Ce sont ce que l'on appelle les Pre-arranged-PoC-Groups (groupes PoC Pre- arranged). C'est ainsi, par exemple, qu'un utilisateur PoC peut définir un groupe Pre-arranged PoC "ami" ayant les utilisateurs PoC correspondants, y compris leurs adresses, par exemple un numéro de téléphone SIP-URL ou une adresse SIP sous la forme SIP-URL. Le groupe PoC-Pre-arranged reçoit alors une adresse de groupe propre, par exemple un SIP-URL, affectée. Cette adresse de groupe est envoyée lors de l'établissement de la session de groupe Pre-arranged PoC par le client PoC initiateur au Controlling-PoCServer qui invite alors tous les utilisateurs PoC appartenant au groupe Pre-arranged PoC à cette session de groupe Pre-arranged-PoC. Les utilisateurs PoC invités peuvent accepter cette invitation, la décliner ou même ne pas en tenir compte. É Chat-PoC-Group Session (session de groupe Chat-PoC) : Les groupes ChatPoC sont également définis de manière fixe, connue du Controlling-PoCServer, et se rapportent, par exemple, à un thème de discussion déterminé. Dans ce type de groupe PoC, il est prévu en général qu'un utilisateur PoC qui y est autorisé s'invite de soi-même dans une session de groupe Chat-PoC et puisse mener une session de groupe PoC avec les autres utilisateurs PoC qui participent également en tant que participants PoC à cette session de groupe Chat-PoC. Cette session de groupe fonctionne ainsi de la même façon que ce qui est prévu dans ce que l'on appelle le "Chatroom" de l'Internet. Dans le Push-to-Talk over Cellular, il y a ainsi deux possibilités différentes sur la façon dont un utilisateur PoC peut devenir un participant PoC dans une session de groupe PoC. Soit il s'invite de soimême dans une session de groupe PoC (c'est la voie habituelle dans une session de groupe Chat- PoC), soit il accepte une invitation (c'est la voie habituelle dans une session de groupe Ad-hoc-PoC ou dans une session de groupe Pre-arranged- PoC). On connaît par [4] comme caractéristique de service (feature) dans le Push-to-Talk over Cellular ce que l'on appelle un service de "Session Status Notification" (notification de statut de session), par l'utilisation duquel un utilisateur PoC est informé du statut qu'a actuellement une session de groupe PoC. Peut faire partie, par exemple, d'un statut de ce genre celui qui est précisément participant PoC dans la session de groupe PoC. Lorsqu'un utilisateur PoC se présente pour un service de ce genre, il reçoit à tout instant un rapport sur le nombre et sur ceux des participants PoC qui participent dans l'instant à une session de groupe PoC. Cette caractéristique de service facultative est réalisée par l'élargissement type SUBSCRIBE/NOTIFY, comme cela est décrit dans [ 5] . Lorsqu'un utilisateur PoC souhaite participer à une discussion dans une certaine session de groupe Chat-PoC, cet utilisateur PoC peut alors exprimer le souhait de ne participer que dans des conditions déterminées. L'utilisateur PoC peut ne vouloir participer à cette session de groupe Chat-PoC que si au moins trois personnes y participent déjà puisqu'il pense que sinon rien d'intéressant ne peut sortir de la discussion. Afin de pouvoir assurer de satisfaire à une condition de ce genre, l'utilisateur PoC pourrait demander la caractéristique de service mentionnée ci-dessus "Session Status Notification" et observer en permanence, c'est-à-dire continuellement, le statut instantané concernant la session de groupe Chat-PoC auquel il s'intéresse. Dès qu'il constate, au moyen des messages de Session Status Notification qui lui sont transmis, que la condition qu'il a posée soi-même dans cet exemple donc qu'il y ait déjà au moins trois participants PoC à la session de groupe PoC qui l'intéresse est satisfaite, il choisit de soi- même d'entrer dans la session correspondante de groupe Chat-PoC. On peut songer à un autre scénario dans une session 5 de groupe Ad-hocPoC ou dans une session de groupe Prearranged-PoC. Lorsque l'utilisateur PoC est invité à une session de groupe Ad-hoc-PoC de ce genre ou à une session de groupe Prearranged-PoC, il pourrait d'abord décliner l'invitation par une condition choisie par lui et s'imposant de soi-même, par exemple que son chef doit participer aussi déjà à cette session de groupe PoC, n'est pas satisfaite. Il observe alors, en outre, le statut de cette session de groupe PoC qui l'intéresse, par exemple également en demandant la caractéristique de service "Session Status Notification" et dès que son chef participe aussi en tant que participant PoC à la session de groupe PoC qui l'intéresse, il choisit d'entrer soi-même aussi dans cette session de groupe PoC. L'inconvénient des deux scénarios décrits ci-dessus est notamment que l'utilisateur PoC doit observer soi-même constamment le statut instantané d'une session de groupe PoC déterminée et ne peut demander que lorsque la condition qu'il impose est satisfaite d'entrer dans une session de groupe PoC qui l'intéresse. L'inconvénient des façons de procéder décrites cidessus est aussi que dans le cas où la condition n'est jamais satisfaite, l'utilisateur a perdu beaucoup de temps et d'énergie pour observer constamment le statut de la session de groupe PoC correspondante. Il est aussi possible, suivant les façons de procéder décrites ci-dessus, que l'utilisateur, bien que la condition soit satisfaite, n'entre, en raison d'une notification retardée que la condition est satisfaite, dans la session de groupe PoC qu'avec retard ou même trop tard et qu'il ne reçoive pas ainsi des informations qui l'intéressent éventuellement et qui ont été données ou échangées dans la session de groupe PoC. [6] décrit un message SIP UPDATE et [7] décrit un message SIP INFO. On connaît par [8] ce que l'on appelle le Session 5 Description Protocol (SDP). On décrit dans [9] le message SIP MESSAGE. Le problème décrit ci-dessus se pose aussi dans d'autres conférences de télécommunication, par exemple dans un système de conférence de télécommunication de l'Internet qui a été décrit, par exemple, dans [10] et qui est désigné par "Conferencing Framework". En se fondant sur ce système de conférence de télécommunication, on a spécifié en outre, dans le comité de normalisation 3GPP, le service IMS Conferencing. Le système de conférence de télécommunication décrit dans [10] procure, outre un procédé de commande des droits d'accès à des ressources de conférence de télécommunication multimédia (désigné aussi par Floor Control) et d'établissement de règles de conférence (désigné aussi par Conference Policy), des procédures reposant sur Session Initiation Protocol (SIP) entre autres pour produire, pour gérer, pour entrer et pour quitter des conférences de télécommunication. Il est contenu en outre, dans ce système des procédés pour faire part aux participants à la conférence (désignés aussi par Conference Notification Service) d'informations et d'événements (Events) spécifiques concernant la conférence de télécommunication. L'un de ces procédés d'avertissement est, par exemple, ce que l'on appelle la "Session Status Notification". Dans le système de conférence de télécommunication, on peut échanger n'importe quel type de support de transmission entre les participants et le système de conférence de télécommunication est désigné pour cette raison, dans ce qui suit, également comme étant un système de conférence de télécommunication multimédia. Pour définir des règles différentes, il est défini dans le cadre du système de conférence de télécommunication multimédia décrit dans [10] ce que l'on appelle le Conference Policy Control Protocol (CPCP), comme cela est décrit dans [11]. On décrit dans [12] un procédé dans lequel un utilisateur envoie à un serveur une liste de participants, en demandant de préparer une conférence avec les participants mentionnés par la liste de participants. Le serveur contrôle alors notamment s'il y a déjà une conférence avec les participants et ajoute l'utilisateur, le cas échéant, ultérieurement à la conférence. Le fascicule [13] décrit un procédé pour acheminer des informations se rapportant au service à un utilisateur de réseau. Un terminal de l'utilisateur du réseau demande à cet effet des paquets d'événements et l'utilisateur du réseau est informé ensuite, par exemple par des configurations de service. Dans [14], on décrit un système de gestion d'une conférence dans lequel une conférence est configurée au moyen d'une application client, une unité serveur gère les réglages de conférence et configure une unité de conférence, de sorte que l'unité de conférence prépare la conférence à l'instant prévu. L'invention vise à produire et/ou à commander d'une façon simple pour un utilisateur une conférence de télécommunication en tenant compte de conditions spécifiques à l'utilisateur. Le problème est résolu par un procédé de production et/ou de commande automatique d'une conférence de télécommunication avec une pluralité de participants, dans lequel on mémorise dans un fichier de conditions de conférence électronique au moins une condition de conférence définie pour l'utilisateur du point de vue de la production de la conférence de télécommunication et/ou du point de vue de la participation d'un ou de plusieurs participants à la conférence de télécommunication, caractérisé en ce que É on contrôle en utilisant le fichier de conditions de conférence si au moins une condition de conférence mémorisée est satisfaite, et É dans lequel, dans le cas où au moins une condition de conférence mémorisée est satisfaite, on produit la conférence de télécommunication et/ou on ajoute le participants ou les participants à la conférence de télécommunication. De préférence - Il est utilisé dans une conférence de télécommunication multimédia. - Il est utilisé télécommunication du réseau conférence de télécommunication du réseau fixe fondé sur Internet, ou dans une conférence de télécommunication en téléphonie mobile, notamment dans une conférence de télécommunication en téléphonie mobile reposant sur des cellules. - Il est utilisé dans une conférence de télécommunication en téléphonie mobile 3GPP, notamment dans une conférence de télécommunication en téléphonie mobile UMTS. - Il est utilisé dans une conférence de télécommunication mobile Push-toTalk over Cellular, notamment de l'un des types suivants: É conférence de télécommunication de téléphonie mobile ad hoc; É conférence de télécommunication de téléphonie mobile Pre-arranged; É conférence de télécommunication de téléphonie mobile chat. Le fichier de conditions de conférence est mémorisé dans une conférence de fixe, notamment dans une dans un terminal d'un participant. - On transmet une information de statut par la conférence de télécommunication à un terminal de participant, et - on effectue le contrôle par le terminal de participant en utilisant l'information de statut reçue. - On transmet une information de statut par la conférence de télécommunication à un terminal de participant lorsque survient un événement donné à l'avance. - On transmet une information de statut par la conférence de télécommunication à un terminal de participant lorsque survient une variation de statut de la conférence de télécommunication. - On mémorise le fichier de conditions de conférence 15 dans un serveur de conférence de télécommunication. - On contrôle les demandes de conférence de télécommunication reçues pour une multiplicité de demandes de conférence de télécommunication reçues par le serveur de conférence de télécommunication si la condition de conférence est satisfaite en satisfaisant les demandes de conférence de télécommunication, et - dans le cas où, en satisfaisant les demandes de conférence de télécommunication, on satisfait la condition de conférence, on produit la conférence de télécommunication et/ou on ajoute le participant ou les participants à la conférence de télécommunication. - On tient compte, comme condition de conférence, d'une ou de plusieurs des conditions de conférence suivantes: É un nombre donné à l'avance, notamment un nombre minimum et/ou un nombre maximum, de participants intéressés ou participant à la conférence de télécommunication; É une identité de participant intéressé ou participant à la conférence de télécommunication; É un instant de la production d'une conférence de télécommunication; É un instant où il est mis fin à une conférence de 5 télécommunication; É une durée d'une conférence de télécommunication; É le contenu d'une conférence de télécommunication; É l'intensité de communication dans une conférence de télécommunication, notamment la proportion de temps dans laquelle on parle et/ou la fréquence de changement de celui qui est autorisé à parler. Dans le cas où une condition de conférence mémorisée n'est pas satisfaite, il peut être prévu des actions différentes et, par exemple, la conférence peut ne pas être produite, on peut continuer sans modification une conférence, un utilisateur qui a demandé à entrer dans une conférence peut être informé que la condition n'est pas satisfaite, par exemple par un message de notification correspondante, ou on peut informer les utilisateurs sur le fait qu'une condition imposée est éventuellement satisfaite en effectuant une ou plusieurs actions qui peuvent être prescrites. L'invention a aussi pour objet un terminal de conférence de télécommunication, caractérisé en ce qu'il 25 comprend É une unité de conférence de télécommunication qui est conçue pour la communication avec d'autres terminaux de conférence de télécommunication et/ou avec un serveur de conférence de télécommunication dans une conférence de télécommunication, É une mémoire de mémorisation d'un fichier de conditions de conférence électronique, dans lequel au moins une condition de conférence définie pour l'utilisateur du point de vue de la production de la conférence de télécommunication et/ou du point de vue de la participation d'un ou de plusieurs participants à la conférence de télécommunication est contenue, É une unité de contrôle de conférence de télécommunication couplée à la mémoire et conçue pour contrôler, en utilisant le fichier de conditions de conférence, si au moins une condition de conférence mémorisée est satisfaite, É une unité de production de messages de conférence de télécommunication qui est conçue de façon à ce que, dans le cas où elle contient une information provenant de l'unité de contrôle de conférence de télécommunication suivant laquelle au moins une condition de conférence mémorisée est satisfaite, elle produit l'un des messages suivants: É un message de demande de production de conférence par lequel la production d'une conférence de télécommunication est demandée, É un message d'entrée en conférence par lequel il est fait part de l'entrée du terminal de conférence de télécommunication dans la conférence de télécommunication. L'invention a enfin pour objet un serveur de conférence de télécommunication, caractérisé en ce qu'il comprend É une unité de conférence de télécommunication qui est conçue pour la communication avec d'autres terminaux de conférence de télécommunication et/ou avec un serveur de conférence de télécommunication dans une conférence de télécommunication, 10 20 É une mémoire de mémorisation d'un fichier de conditions de conférence électronique, dans lequel au moins une condition de conférence définie pour l'utilisateur du point de vue de la production de la conférence de télécommunication et/ou du point de vue de la participation d'un ou de plusieurs participants à la conférence de télécommunication est contenue, É une unité de contrôle de conférence de télécommunication couplée à la mémoire et conçue pour contrôler, en utilisant le fichier de conditions de conférence, si au moins une condition de conférence mémorisée est satisfaite, É une unité de production/commande d'une conférence de télécommunication qui est conçue de manière à ce que, dans le cas où au moins une condition de conférence mémorisée est satisfaite, elle produit la conférence de télécommunication et/ou ajoute un participant ou plusieurs participants à la conférence de télécommunication. Les caractéristiques concernant le procédé valent aussi pour le terminal et le serveur suivant l'invention. Les participants à la conférence de télécommunication transmettent et/ou reçoivent des données de préférence par un système de communication de téléphonie mobile, d'une manière particulièrement préférée suivant un système de communication de téléphonie mobile 3GPP, d'une manière particulièrement préférée suivant UMTS. Autrement dit, cela signifie que, de préférence, le serveur de conférence de télécommunication est conçu pour une télécommunication par un système de téléphonie mobile, notamment de préférence suivant un système de téléphonie mobile 3GPP et, en l'occurrence, d'une manière particulièrement préférée, suivant UMTS. L'invention convient ainsi notamment pour être utilisée dans un système de communication de téléphonie mobile, de préférence reposant sur des cellules. Autrement dit, cela signifie que le serveur de conférence de télécommunication fait ainsi partie de préférence d'un système de communication de téléphonie mobile, d'une manière particulièrement préférée d'un système de communication de téléphonie mobile 3GPP, et d'une manière particulièrement préférée du sous-système dit IP-Multimedia Core Network (IMS) du système de communication de téléphonie mobile UMTS. Suivant l'architecture du réseau de conférence de télécommunication, le serveur de conférence de télécommunication peut être intégré aussi à un terminal de conférence de télécommunication. En outre, dans une conférence de télécommunication entièrement maillée, en utilisant exclusivement des terminaux de conférence de télécommunication, un terminal de conférence de télécommunication parmi ceux-ci peut être constitué en un serveur de conférence de télécommunication et activer et mettre à disposition la ou les fonctionnalités correspondantes. On indiquera à cet égard que, dans le cadre de cette description, on entend par l'expression "produire une conférence de télécommunication" également l'invitation d'un participant à produire une conférence de télécommunication, c'est-à-dire une invitation d'un participant futur éventuel de la conférence de télécommunication à produire la conférence de télécommunication. En outre, par l'expression "commander une conférence de télécommunication", on entend, dans cette invention, également l'invitation d'un nouveau participant éventuel à entrer dans une conférence de télécommunication déjà produite. Les unités fonctionnelles décrites dans ce qui suit peuvent être mises en oeuvre dans des unités de matériel distinctes les unes des autres, par exemple des ordinateurs autonomes ou des terminaux de télécommunication autonomes, de préférence des terminaux de téléphonie mobile, ou être mis en oeuvre au moins en partie dans des logiciels, c'est-à-dire au moyen de programmes d'ordinateur qui sont mis en oeuvre dans des unités informatiques distinctes ou communes. L'invention convient notamment en vue d'être utilisée dans une conférence de télécommunication multimédia, c'est-à-dire dans une conférence de télécommunication dans laquelle des types de médias différents, par exemple des données audio, des données vidéo et d'autres données de texte, sont échangés et transmis entre les participants à la conférence de télécommunication. Le procédé est mis en oeuvre, de préférence, dans une conférence de télécommunication du réseau fixe, notamment dans une conférence de télécommunication du réseau fixe reposant sur Internet, en variante de préférence dans une conférence de télécommunication de téléphonie, notamment dans une conférence de télécommunication de téléphonie mobile reposant sur des cellules et notamment, d'une manière particulièrement préférée, dans une conférence de télécommunication de téléphonie mobile 3GPP, notamment dans une conférence de télécommunication de téléphonie mobile UMTS. Un domaine d'utilisation particulièrement préféré est la conférence de télécommunication de téléphonie mobile Push- to-Talk over Cellular, notamment l'un des types suivants: É conférence de télécommunication de téléphonie mobile ad hoc; É conférence de télécommunication de téléphonie 30 mobile Pre-arranged; É conférence de télécommunication de téléphonie mobile chat. Notamment dans une conférence de télécommunication de téléphonie mobile Push-to-Talk over Cellular, se posent les problèmes décrits dans l'introduction du présent mémoire de l'observation manuelle continuelle d'une conférence de télécommunication existante, du point de vue de savoir si des conditions éventuelles sont remplies ou ne le sont pas. Par l'invention, on décrit de nouveaux mécanismes pour des sessions de conférences de télécommunication, notamment pour des sessions de groupes PoC par lesquelles un utilisateur de conférence, par exemple un utilisateur PoC, n'est lié comme participant à une session de groupe de télécommunication, notamment à une session de groupe PoC, que s'il s'est produit un certain événement fixé par cet utilisateur. C'est ainsi, par exemple, qu'un utilisateur de conférence, par exemple un utilisateur PoC, n'est lié, en tant que participant à une session de groupe Chat-PoC, que si au moins deux autres participants PoC participent à cette session de groupe Chat-PoC. Il est ainsi possible, suivant l'invention, pour la première fois, de transmettre des conditions automatisées d'entrée dans une conférence de télécommunication sur une unité adéquate pour produire ou pour commander une conférence de télécommunication par laquelle elle peut être traitée de manière automatisée et être contrôlée de manière continue. En variante, le contrôle peut avoir lieu aussi dans le terminal de télécommunication et l'utilisateur peut être informé que la condition est satisfaite dans la conférence de télécommunication en même temps ou à un instant très proche sans que l'utilisateur ait à surveiller lui-même manuelle constamment le statut de la conférence de télécommunication auquel il s'intéresse. Il est aussi assuré par l'invention que l'utilisateur peut, en un temps très rapproché, c'est-à-dire plus ou moins directement après que la condition de la conférence de télécommunication a été satisfaite, entrer dans cette conférence ou la produire. On évite ainsi une perte de temps sansnécessité concernant la participation d'un utilisateur à la conférence de télécommunication. On augmente ainsi la convivialité pour l'utilisateur d'un système de conférence de télécommunication d'une manière 5 considérable. Le fichier de conditions de conférence peut être mémorisé dans un terminal d'un participant. Dans ce cas, il est préféré que l'on transmette une information de statut par la conférence de télécommunication à un terminal de participant, et que l'on effectue le contrôle par le terminal de participant en utilisant l'information de statut reçue. Suivant ce mode de réalisation de l'invention, on obtient un contrôle automatisé du côté du terminal de la conférence de télécommunication et, par une information très rapprochée dans le temps de l'utilisateur sur le fait que la condition prescrite est satisfaite, une production et/ou une commande d'une conférence de télécommunication elle aussi très rapprochée dans le temps. Suivant le mode de réalisation de l'invention, il est prévu que l'information de statut soit transmise par la conférence de télécommunication à un terminal de participant lorsque survient un événement donné à l'avance, par exemple en utilisant le service "Session Status Notification", comme décrit dans [4]. Il est préféré, à cet égard, que l'information de statut soit transmise par la conférence de télécommunication à un terminal de participant lorsque survient une modification du statut de la conférence de télécommunication, par exemple lorsqu'un participant entre dans la conférence de télécommunication ou en sort. En variante, le fichier de conditions de conférence de télécommunication peut être mémorisé dans un serveur de conférence de télécommunication. Dans ce cas, il est prévu, de préférence, de 25 contrôler pour une pluralité de demandes de conférences de télécommunication reçues par le serveur de conférence de télécommunication si, en satisfaisant les demandes de conférence de télécommunication, la condition de conférence d'un utilisateur est satisfaite. Dans le cas où en satisfaisant les demandes de conférences de télécommunication, la condition de conférence est satisfaite, la conférence de télécommunication est produite et/ou le participant ou les participants sont ajoutés à la conférence de télécommunication. Il est ainsi possible de façon centralisée, même dans le cas où pour une conférence de télécommunication existante ou n'existant pas encore du point de vue d'une considération isolée d'une condition adéquate de demande, celle-ci ne serait pas en soi satisfaite, qu'en traitant ou en analysant et en évaluant plusieurs demandes et plusieurs conditions de participants différents, une condition respective puisse être satisfaite lors de la production d'une conférence de télécommunication pour tous les participants. On augmente ainsi considérablement le confort de service. Comme condition de conférence, on tient compte, de préférence, de l'une ou plusieurs des conditions de conférence suivantes: É un nombre donné à l'avance, notamment un nombre minimum et/ou un nombre maximum, de participants intéressés ou participant à la conférence de télécommunication; É une identité de participant intéressé ou 30 participant à la conférence de télécommunication; É un instant de la production d'une conférence de télécommunication; É un instant où il est mis fin à une conférence de 19 télécommunication; É une durée d'une conférence de télécommunication; É le contenu d'une conférence de télécommunication; É l'intensité de communication dans une conférence de télécommunication, notamment la proportion de temps dans laquelle on parle et/ou la fréquence de changement de celui qui est autorisé à parler. Des exemples de réalisation de l'invention sont représentés aux figures et sont expliqués d'une manière plus précise dans ce qui suit. Dans les figures, des éléments identiques ou analogues sont munis habituellement des mêmes signes de référence. Aux dessins. la Figure 1 est un schéma fonctionnel qui représente le système de communication Push-to-Talk over Cellular suivant les exemples de réalisation pour le système de communication Push-to-Talk over Cellular; la Figure 2 est un organigramme de flux de messages dans lequel sont représentés les stades de procédé suivant un premier exemple de réalisation de l'invention; la Figure 3 est un organigramme de flux de messages dans lequel sont représentés les stades de procédé suivant une première variante de réalisation d'un deuxième exemple de réalisation de l'invention; la Figure 4 est un organigramme de flux de messages dans lequel sont représentés les stades de procédé suivant une deuxième variante de réalisation du deuxième exemple de réalisation de l'invention; la Figure 5 est un organigramme de flux de messages dans lequel sont représentés les stades de procédé suivant un troisième exemple de réalisation de l'invention; et la Figure 6 représente un système de conférence de télécommunication suivant un autre exemple de réalisation de l'invention. La Figure 1 représente l'architecture de base d'un système 100 de conférence de télécommunication de téléphonie mobile Push-to-Talk over Cellular suivant plusieurs exemples de réalisation de l'invention. Push-to-Talk over Cellular est réalisé dans le domaine Packet-Switched (domaine PS), c'est-à-dire dans la partie à transmission de paquets d'un système de télécommunication de téléphonie mobile. Comme protocole de réseau de communication, on utilise dans le Push-toTalk over Cellular sur le plan de la couche de commutation le protocole Internet (IP). Du côté du réseau, le système 100 de communication a, dans une zone 101 du réseau fixe pour chaque session de groupe PoC (Push-to-Talk over Cellular-Group Session), c'est-à-dire pour chaque liaison de communication de groupe dans le cadre d'une conférence PoC, un serveur PoC central, ce que l'on appelle le Controlling PoC-Server 102. Il est prévu, en outre, et affecté à chaque terminal de communication PoC pour chaque client PoC respectivement un dispositif serveur ParticipatingPoC affecté à ce client PoC (Participating-PoC-Server) 103, 104, 105. Les clients PoC, de préférence des terminaux de téléphonie mobile, dans lesquels sont réalisés les protocoles de communication correspondants et les programmes pour la communication reposant sur PoC, sont désignés à la Figure 1 par les signes de références 106, 107 et 108. Pour la liaison de communication de signalisation entre un client PoC 106, 107, 108 et le Participating -PoC- Server 103, 104 ou 105 correspondant et le Controlling-PoCServer 102, on utilise, dans ces exemples de réalisation de l'invention, Internet Protocol Multimedia Subsystem (IMS) qui utile comme protocole de communication de signalisation le Session Initiation Protocol (SIP), comme cela est décrit dans [2] . Le système 100 de conférence de télécommunication de téléphonie mobile Push-to-Talk over Cellular est conçu suivant [1], à l'exception des caractéristiques supplémentaires, telles qu'elles seront explicitées d'une manière plus précise dans ce qui suit. Pour la liaison de communication de transmission de données entre les clients PoC 106, 107, 108 et les Participating-PoC-Server 103, 104 et 105 ou le Controlling- PoC-Server 102, on utilise le protocole RTP suivant [3]. Dans le Push-to-Talk, il y a actuellement trois types différents de groupes PoC (Push-to-Talk over Cellular Groups) qui se distinguent essentiellement par l'établissement de la session de groupe PoC: É Ad-hoc-PoC-Group Session (session de groupes Ad- hoc-PoC) : Avant l'établissement d'une session de groupe Ad-hoc-PoC, l'initiateur de la session de groupe Ad-hoc-PoC dresse une liste d'utilisateurs PoC (PoC Usern), y compris leurs adresses, par exemple un numéro de téléphone sous la forme de SIP-URL (Session Initiation Protocol Unique Resource Locator) ou d'une adresse SIP sous la forme de SIP-URL. On notera à cet égard que la liste d'utilisateurs PoC peut être constituée aussi de seulement une personne. La liste est envoyée lors de l'établissement de la session de groupe Ad-hoc-PoC par le client PoC initiateur au Controlling-PoC-Server qui invite alors tous les utilisateurs PoC contenus dans la liste à la session de groupe Ad-hoc-PoC. Les utilisateurs PoC invités peuvent accepter cette invitation, la décliner ou même ne pas en tenir compte. É Pre-arranged-PoC-Group Session (session de groupe PoC pre-arranged) . 25 30 Dans le cas où l'on souhaite toujours mener à nouveau avec les mêmes utilisateurs PoC une session de groupe PoC, un utilisateur PoC peut définir ses groupes fixes personnels et les faire connaître au Controlling-PoC-Server. Ce sont ce que l'on appelle les Pre-arranged-PoC-Groups (groupes PoC Pre- arranged). C'est ainsi, par exemple, qu'un utilisateur PoC peut définir un groupe Pre-arranged PoC "ami" ayant les utilisateurs PoC correspondants, y compris leurs adresses, par exemple un numéro de téléphone SIP-URL ou une adresse SIP sous la forme SIP-URL. Le groupe PoC-Pre-arranged reçoit alors une adresse de groupe propre, par exemple un SIP-URL, affectée. Cette adresse de groupe est envoyée lors de l'établissement de la session de groupe Pre-arranged PoC par le client PoC initiateur au Controlling-PoCServer qui invite alors tous les utilisateurs PoC appartenant au groupe Pre-arranged PoC à cette session de groupe Pre-arranged-PoC. Les utilisateurs PoC invités peuvent accepter cette invitation, la décliner ou même ne pas en tenir compte. É Chat-PoC-Group Session (session de groupe Chat- PoC) . Les groupes Chat-PoC sont également définis de manière fixe, connue du Controlling-PoC-Server, et se rapportent, par exemple, à un thème de discussion déterminé. Dans ce type de groupe PoC, il est prévu en général qu'un utilisateur PoC qui y est autorisé s'invite de soi-même dans une session de groupe Chat-PoC et puisse mener une session de groupe PoC avec les autres utilisateurs PoC qui participent également en tant que participants PoC à cette session de groupe Chat-PoC. Cette session de groupe fonctionne ainsi de la même façon que ce qui est prévu dans ce que l'on appelle le "Chatroom" de l'Internet. Les clients PoC 106, 107, 108 ont ainsi respectivement une interface, de préférence une interface 109, 110, 111 radio, pour mettre à disposition une liaison de communication de téléphonie mobile vers leurs Participating-PoC-Server 103, 104 ou 105 respectifs qui, à leur tour, ont une liaison de communication vers le Controlling-PoC-Server 102 central. Il est prévu en outre, facultativement, une unité de décision Floor Control (Chair) 112 qui est couplée au Controlling-PoC-Server 102. Le Chair 112 est une unité logique qui est prévue pour la caractéristique de service élargie "Floor Control-Entscheidung par un Chair". Le Chair 112 peut être réalisé dans un Client-PoC 106, 107, 108 soi-même ou également dans un serveur dans la zone 101 du réseau. L'interface d'un client PoC 106, 107, 108 au Participating-PoC-Server 103, 104 et 105 respectif peut être réalisée, par exemple, par UMTS par l'intermédiaire du Radio Access Network (RAN), du Core Network (CN), c'est-à-dire du réseau de coeur et par le IP Multimedia Subsystem (IMS). D'autres réalisations, par exemple au moyen d'un réseau habituel de postcommunication (PSTN), sont prévues également dans une variante de réalisation. Suivant l'invention, il est prévu essentiellement deux solutions différentes pour résoudre les problèmes décrits et on les décrira notamment en liaison avec le système 100 de conférence de télécommunication de téléphone mobile Push-to- Talk over Cellular d'une manière plus précise, tous les exemples de réalisation décrits dans ce qui suit ayant en commun que les conditions décrites dans ce qui suit sont contrôlées automatiquement par un terminal ou par un serveur. Toutes les solutions décrites dans ce qui suit sont théoriquement utilisables dans tous les types décrits ci-dessus de sessions de groupes PoC. C'est pourquoi on parlera dans ce qui suit souvent, d'une manière générale, de sessions de groupes PoC et on ne fera plus la différence entre les trois types différents de sessions de groupes PoC. Dans ce cas, les exemples de réalisation décrits peuvent être utilisés sur les trois sessions de groupes PoC décrites ci-dessus. Suivant une première solution, on utilise le service décrit ci-dessus "Session Status Notification". Dans le client PoC 106, 107, 108 respectif (ou dans une application, c'est-à-dire un programme d'application qui est mis en oeuvre sur le terminal PoC qui reçoit les informations nécessaires du client PoC 106), l'utilisateur PoC peut fixer une ou plusieurs ou également une combinaison de plusieurs conditions qui doivent être satisfaites dans une certaine session de groupe PoC donnée à l'avance. Les conditions données à l'avance sont mémorisées 20 dans un fichier de conditions de conférence qui sont accessibles aux clients PoC 106, 107, 108. Le client PoC 106, 107, 108 contrôle, au moyen du fichier de conditions de conférence, pour chaque variation annoncée du statut de la session de groupe PoC correspondante à laquelle est affecté le fichier de conditions de conférence respectif si cette ou ces conditions est ou sont remplies. Dès que cela est le cas, le client PoC 106, 107, 108 s'introduit automatiquement dans la session de groupe PoC respective et en avise de manière correspondante l'utilisateur PoC, par exemple au moyen de l'émission d'une tonalité de signal ou d'une indication correspondante sur le dispositif d'affichage du terminal PoC. L'avantage de la première solution réside notamment dans le fait que l'utilisateur PoC ne doit plus observer soi- même constamment le statut de la session de groupe PoC correspondante mais qu'il y a un mécanisme adéquat dans le client PoC 106, 107, 108 qui se comporte suivant le souhait de l'utilisateur PoC et qui contrôle automatiquement en continu la session de groupe PoC respective. Suivant une deuxième solution, la fonctionnalité suivant l'invention est mise en oeuvre en revanche principalement dans le Controlling-PoC-Server 102. L'utilisateur PoC entre "sous conditions", c'est-à- dire en se soumettant à des conditions d'entrée, dans une session de groupe PoC déterminée, envoie avec le message d'entrée suivant l'invention, en outre, une, plusieurs ou une combinaison de plusieurs conditions au Controlling-PoC-Server 102. Dans le cas où la ou les conditions mentionnées est ou sont satisfaites, l'utilisateur PoC devient immédiatement, grâce au Controlling-PoC-Server 102, un participant PoC à la session de groupe respective. Si la ou les conditions ne sont pas satisfaites, l'utilisateur PoC est mémorisé dans un fichier de participants éventuels (liste de participants éventuels) dans le Controlling-PoC-Server 102 et est inscrit en tant que participant PoC potentiel, c'est-à-dire que le participant PoC potentiel ne reçoit pas de messages vocaux de cette session de groupe PoC (s'il y en a) et n'a pas non plus de possibilité d'envoyer soi-même des messages vocaux à la session de groupe PoC. Le Controlling-PoC-Server 102 contrôle alors constamment, c'est-à-dire en continu, en variante à des intervalles de temps prescrits, si est ou sont satisfaites les conditions qui ont été prescrites par le client respectif. Dès que cela est le cas, le participant PoC potentiel est introduit automatiquement dans la session de groupe PoC et devient ainsi un participant PoC tout à fait "normal". Une signalisation correspondante est envoyée à cet effet par le Controlling-PoC- Server 102 aux clients PoC 106, 107, 108 correspondants. Suivant la deuxième solution, on obtient notamment les avantages supplémentaires suivants: É suivant la deuxième solution, il n'est pas absolument nécessaire que le client PoC 106, 107, 108 utilise le service "Session Status Notification", d'une manière générale un service qui informe le client de la modification de statut dans une session de groupe PoC. On fait ainsi l'économie d'une signalisation supplémentaire (éventuellement même très fréquente) du statut de la session de groupe PoC respective, ce qui permet de gagner tant des ressources sur l'interface radio qu'également des taxes pour l'utilisateur PoC. É Comme la fonctionnalité est prévue principalement dans le ControllingPoC-Server 102, celle-ci peut être mise en oeuvre une seule fois centralement et n'a pas à être prévue sur chaque client PoC 106, 107, 108 ou à y être mise en oeuvre. Un entretien aussi, notamment une mise à jour, c'est-à-dire une actualisation du logiciel correspondante, est ainsi très simple et peu coûteuse à effectuer. É On connaît à tout instant dans le Controlling-PoC-Server 102 qui et combien d'utilisateurs PoC sont dans une session de groupe PoC déterminée des participants PoC potentiels. On peut ainsi résoudre des conditions qui dépendent mutuellement de divers participants PoC potentiels. Un exemple est celui dans lequel il n'y a pas, dans un certain groupe Chat-PoC, dans le moment de participant, il entre toutefois trois 10 utilisateurs PoC sous la condition qu'au moins deux autres participants PoC participent à cette session de groupe Chat-PoC. Comme le ControllingPoC-Server 102 a connaissance de toutes les conditions des trois participants PoC potentiels, il peut faire entrer les trois participants PoC potentiels dans la session de groupe Chat-PoC, toutes les autres conditions étant alors ainsi satisfaites. Une variante de la deuxième solution telle qu'elle a été décrite cidessus est que l'utilisateur PoC puisse mettre une information dans le réseau de communication du réseau fixe en indiquant dans quelles conditions il souhaiterait être invité à une session de groupe PoC déterminée. Il pourrait aussi fixer des conditions pour un groupe de session de groupes PoC ou également pour toutes les sessions de groupes PoC à venir auxquelles l'utilisateur PoC est invité. L'avantage supplémentaire d'une variante de ce genre est notamment qu'il ne serait pas nécessaire d'avoir une signalisation supplémentaire puisque la condition n'aurait pas à être envoyée chaque fois pour une entrée sous condition ou pour une acceptation potentielle d'une invitation. On explicite dans ce qui suit certains concepts mentionnés ci-dessus, tel qu'il faut les entendre dans cette 25 description: É un utilisateur PoC est un utilisateur d'un terminal de communication qui a un client PoC sur son terminal de télécommunication et qui demande un service PoC. Il est donc en principe apte à mener une session de groupe PoC. É Un participant PoC est un utilisateur PoC qui a réussi à entrer dans une session de groupe PoC (il est entré de soi-même ou il a accepté une invitation), c'est-à-dire qu'il reçoit toutes les données vocales des autres participants PoC de cette session de groupe PoC et qu'il a aussi en général la possibilité d'introduire lui-même des données vocales dans la session de groupe PoC. É Un participant PoC potentiel est un utilisateur qui n'est "qu'associé" à une session de groupe PoC, c'est-à-dire qu'il n'est choisi par le Controlling-PoC-Server 102 que sous condition pour entrer dans une session de groupe PoC, la condition (pour l'instant) n'étant toutefois pas satisfaite. Ce n'est donc pas encore un participant PoC, il le deviendrait dès que la condition serait satisfaite. En se reportant à un organigramme 200 de flux de messages de la Figure 2, on explicitera d'une façon plus précise un premier exemple de réalisation de l'invention qui est mis en oeuvre dans sa structure suivant la première solution décrite ci-dessus. On part du fait qu'un utilisateur PoC a envie de 20 participer à une session de groupe Chat-PoC ayant le titre "Michael Jackson". Toutefois, il ne souhaite y participer que si son ami "Peter" est également un participant PoC de cette session de groupe Chat-PoC; en outre, il n'a le temps de la faire que le soir de 19 heures à 20 heures. Il indique ces deux conditions dans une application qui est mise en oeuvre sur le premier client PoC 106 et les deux conditions sont memorisées dans une syntaxe correspondante, de préférence suivant XML (Extensible Markup Language), dans un fichier de conditions de conférence qui n'est pas représenté. On part du fait, dans les exemples de réalisation, que chaque client PoC 106, 107, 108 est mis en oeuvre dans un terminal de téléphonie mobile qui est conçu suivant l'UMTS. 10 L'entrée et la mémorisation de la condition par l'utilisateur dans le premier client PoC 106 est symbolisée à la Figure 2 par un premier bloc 201. A 19 heures, l'application qui est mise en oeuvre dans le premier client PoC 106 atteint le premier client PoC 106, suivant laquelle il doit demander le service "Session Status Notification" à ce groupe Chat-PoC mentionné auprès du Controlling-PoC-Server 102. A cet effet, le premier client PoC 106 envoie un 10 message 202 SIPSUBSCRIBE correspondant ayant le "Conference Status Event Package" au Contolling-PoC-Server 102. En outre, il doit acheminer à l'application dans le premier client PoC 106 toutes les informations de statut reçues qu'il obtient sous la forme d'un message 203 SIP- NOTIFY. Il est représenté à la Figure 2 le cas d'espèce suivant lequel tout d'abord, après avoir reçu le premier message 203 SIP-NOTIFY, il est effectué un contrôle de la ou des conditions (stade de contrôle 204) et celui-ci s'avère négatif puisqu'à cet instant, le client PoC de l'utilisateur PoC "Peter" n'est pas encore participant PoC à la session de groupe PoC. A un instant suivant, l'utilisateur PoC "Peter" entre dans la session de groupe Chat-PoC (bloc 205) au moyen d'un premier message 206 SIP-INVITE, qui contient comme paramètre un identificateur du groupe Chat respectif dans lequel le deuxième client PoC 107 souhaite entrer et qui est envoyé par le deuxième client PoC 107 qui est mis en oeuvre sur le terminal de téléphonie mobile de l'utilisateur PoC "Peter" au Controlling-PoC-Server 102. Le Controlling-PoC-Server 102 produit la session de groupe Chat souhaitée ou ajoute l'utilisateur PoC "Peter" à la session de groupe Chat souhaitée déjà produite et confirme cela au deuxième client PoC 107 qui a envoyé la demande pour la production ou la participation à la session de groupe PoC au moyen d'un premier message 207 SIP-200-OK. En raison de la variation de statut de la conférence de télécommunication ou des sessions de groupes PoC, le Controlling-PoC-Server 102 envoie au client PoC 106 ayant souscrit un deuxième message 208 SIP-NOTIFY dans lequel est contenue l'information que l'ami "Peter" est entré dans la session Chat-PoC en tant que participant. Sur la base de cette information nouvelle, le premier client PoC 106 contrôle maintenant, en utilisant le fichier de conditions de conférence et le deuxième message 208 SIPNOTIFY, si la condition est satisfaite (stade de contrôle 209), et comme dans les conditions mentionnées cidessus la condition est maintenant satisfaite, le premier client PoC 106 produit et émet un deuxième message 210 SIP-INVITE ayant l'indication d'identification du groupe Chat et l'envoie au Controlling-PoC-Server 102. Le Controlling-PoC-Server 102 ajoute le premier client PoC 106 à la session de groupe Chat mentionnée dans le message 210 SIP-INVITE et confirme cela au premier client PoC 106 par un deuxième message 211 SIP-200-0K. Maintenant, tant le premier client 106 qu'également le deuxième client 107 sont des participants PoC à la session de groupe PoC souhaitée. Les Figures 3 et 4 représentent deux variantes de réalisation différentes d'un deuxième exemple de réalisation de l'invention suivant la deuxième solution décrite ci-dessus. Suivant ce deuxième exemple de réalisation, on suppose qu'un utilisateur PoC a envie de participer à une session de groupe Chat-PoC sur le thème "Michael Jackson". Toutefois, il ne souhaite y participer que si son ami "Peter" ou son collègue "Paul" participe également en tant que participant PoC à cette session de groupe PoC. Il indique ces conditions dans une application mise en oeuvre sur son terminal de téléphonie mobile sur lequel est mis en oeuvre aussi le premier client PoC 106 et commence ainsi son entrée sous condition dans la session de groupe Chat-PoC correspondante (bloc 301). Le premier client PoC 106 envoie ensuite un premier message 302 SIPINVITE dans lequel sont contenus comme paramètres l'indication de la session de groupe Chat-PoC et les conditions que l'utilisateur PoC a entrées, c'est-à-dire a imposées. Le premier message 302 SIP-INVITE est transmis par le premier client PoC 106 au Controlling-PoC-Server 102 qui enregistre les conditions reçues dans un fichier de conditions de conférence mémorisées dans une mémoire du Controlling-PoCServer 102. Dans ce qui suit, on représente une structure à titre d'exemple d'un message 302 SIP-INVITE suivant cet exemple de 15 réalisation de l'invention en format XML: INVITE sip:michael.jackson.chat@ptt.umts.de SIP/2.0 Content-Type: application/dial in conditions+xml Content-Length: (...) 30 Les informations supplémentaires suivant SIP qui représentent les conditions imposées sont, par rapport à un message INVITE habituel, soulignées dans l'exemple XML ci-dessus en caractères gras. Après avoir reçu le premier message 302 SIP-INVITE, le Controlling-PoCServer 102 contrôle si est satisfaite la condition que l'utilisateur PoC "sip:my.friend.peter@umts.de" ou que l'utilisateur PoC "sip:my.colleague. paul@umts.de" est participant PoC pour l'instant dans la session de groupe PoC correspondante, comme cela est indiqué par le paramètre "Chat- Group" dans le message 302 SIP-INVITE. Dans le cas donné en exemple où l'ami Peter participe pour l'instant à la session de groupe PoC, le Controlling-PoCServer 102 envoie un premier message 303 SIP-200-OK au premier client 106 PoC, le message 303 SIP-200OK étant agrandi comme représenté dans ce qui suit (l'agrandissement est repéré par une impression en gras), de sorte que l'utilisateur PoC devient un participant PoC: sip:poc.user@infineon.com SIP/2.0 Content- Type: application/dial_in_conditions_status+xml Content-Length: (...) Au moyen de l'agrandissement ci-dessus, on peut faire part à l'utilisateur PoC de la condition ou des conditions 25 30 suivant lesquelles cette entrée dans la session de groupe Chat-PoC a eu effectivement lieu. Cela est particulièrement intéressant lorsqu'une combinaison logique OU est effectuée par l'utilisateur PoC, comme dans l'exemple indiqué ci-dessus. Dans le cas où, dans l'instant, ni l'ami "Peter" ni le collègue "Paul" ne participe à la session de groupe PoC, il y a deux variantes de réalisation, c'est-à-dire deux façons de procéder. La première façon de procéder (voir la Figure 3) consiste en ce que, lors d'un contrôle des conditions mentionnées de la part du Controlling-PoCServer 102 qui est négatif (bloc 303), le Controlling-PoC-Server 102 produit un premier message 304 SIP-200-OK et le transmet au premier client PoC 106. Dans le premier message 304 SIP-200-OK, les médias correspondants (notamment vocaux) sont, en utilisant le Session Description Protocol(SDP) décrit dans [8], mis sur "inactif", c'est-à- dire que l'utilisateur ne reçoit pas de messages vocaux et ne peut pas non plus en envoyer (cela est symbolisé à la Figure 3 par le bloc 305). L'établissement d'un message (SDP) de ce genre s'effectue suivant [8]. Le premier message 304 SIP-200-0K est ainsi conformé de la manière suivante. sip:poc.user@infineon.com SIP/2.0 Content-Type: application/sdp ContentLength: (III) m=audio 49170 RTP/AVP 0 30 a=inactive Content-Type: application/dial_in_ conditions status+xml Content-Length: (...) Les informations supplémentaires suivant SIP qui représentent le résultat du contrôle des conditions mentionnées sont, par rapport à un message 200-0K habituel, soulignées en caractères gras dans l'exemple XML ci-dessus. Autrement dit, cela signifie que l'utilisateur PoC est maintenant un participant PoC potentiel dans cette session de groupe PoC, donc ne peut ni recevoir ni envoyer de données vocales. Lorsque, à un instant ultérieur, la condition contenue dans le premier message 302 SIP-INVITE est satisfaite, le Controlling-PoC-Server 102 envoie un message SIP correspondant (par exemple un message SIP UPDATE) comme décrit dans [6], un message SIP INFO comme décrit dans [7] ou un message SIP RE-INVITE) dans lequel la parole est mise alors à l'aide de SDP sur "active". L'utilisateur PoC devient ainsi alors un participant PoC "normal". Ce message peut aussi alors, comme décrit ci- dessus en liaison avec le premier message 304 SIP-200-OK, être agrandi du résultat du contrôle de condition (bloc 303). Cette façon de procéder est explicitée encore une fois à la Figure 3, en supposant à la Figure 3 qu'à un instant postérieur à la transmission du premier message 304 SIP-200-0K au premier client PoC 106, l'utilisateur PoC "Peter" est entré dans la session PoC à laquelle on s'intéresse, c'est-à-dire dans la session de groupe Chat-PoC ayant le thème "Michael Jackson" (bloc 306), par le fait que le deuxième client PoC 107, qui est mis en oeuvre dans le terminal de téléphonie mobile de l'utilisateur PoC "Peter", produit un deuxième message 307 SIP-INVITE et l'envoie au Controlling-PoC-Server 102. Dans le deuxième message 307 SIP-INVITE, le groupe PoCChat correspondant est indiqué, ce qui identifie la session de groupe Chat-PoC intéressante dans laquelle le deuxième client PoC 107 souhaite entrer en tant que participant PoC. Le Controlling-PoC-Server 102 ajoute le deuxième client PoC 107 à la session de groupe PoC comme participant et confirme cela au deuxième client PoC 107 au moyen d'un deuxième message 308 SIP-200-OK. Le deuxième client PoC 107, et ainsi l'utilisateur PoC "Peter", est ainsi participant PoC à la session de groupe Chat-PoC. En raison de la modification de l'état de la session de groupe Chat-PoC "Michael Jackson", le Controlling-PoCServer 102 recontrôle si les conditions indiquées dans le premier message 302 SIP-INVITE sont satisfaites (stade de contrôle 309). Comme cela est maintenant le cas parce que l'utilisateur PoC "Peter" est devenu participant PoC à cette session de groupe PoC, le Controlling-PoCServer 102 ajoute le premier client PoC 106 à la session de groupe ChatPoC "Michael Jackson" comme participant, produit un message 310 SIP-UPDATE et l'envoi au premier client PoC 106. Dans le message 310 SIP-UPDATE, est contenu un paramètre (SDP) par lequel la parole est mise sur "active" et, en outre, il est contenu dans ce message le résultat du contrôle de condition. Le premier client PoC 106, qui est maintenant également participant PoC à la session de groupe PoC, confirme la réception du message 310 SIP-UPDATE par production d'un troisième message 311 SIP-200-OK qui est transmis au Controlling-PoC-Server 102. Tant le premier client PoC 106 qu'également le client PoC 107 sont maintenant des participants PoC à la session de groupe PoC souhaitée. Suivant la deuxième variante de réalisation représentée à la Figure 4 du deuxième exemple de réalisation, il est prévu dans un contrôle de condition négatif (bloc 303) que le Controlling-PoC-Server 102 transmette sur le premier message 302 SIP-INVITE un premier message 401 SIP-200-0K ayant le résultat du contrôle comme paramètre de message au premier client PoC 106 et immédiatement après, c'est-à-dire tout de suite après, produise un message 402 SIP-BYE et l'envoie également au premier client PoC 106. En variante aux messages SIP 401, 402, le Controlling-PoC- Server 102 envoie un message d'annonce d'erreur SIP "4XX" (cela n'est pas représenté) au premier client PoC 106. Tous ces messages SIP peuvent contenir également le résultat du contrôle de condition (bloc 303). Cela signifie que le Controlling-PoC-Server 102 n'établit pas de liaison au plan de signalisation avec le premier client 106 PoC. Le Controlling-PoC-Server 102 continue toutefois à suivre pour le premier client PoC 106 si les conditions que le premier client PoC 106 a transmises dans le premier message 302 SIP-INVITE au Controlling-PoCServer 102 et que celui-ci a mémorisées dans le fichier de conditions de conférence mémorisé dans le Controling-PoC-Server 102 sont devenues satisfaites entre-temps. L'utilisateur PoC est donc aussi, dans ce cas, un participant PoC potentiel. Dès que la condition est satisfaite, le Controlling-PoC-Server 102 envoie un message SIP-INVITE au premier client PoC 106 pour accepter l'utilisateur PoC dans la session de groupe PoC souhaitée maintenant comme participant PoC "normal". Lorsque le premier client PoC 106, dans l'intervalle (donc tant que les conditions n'ont pas encore été satisfaites et donc que le premier client PoC 106 ne participe pas à la session de groupe PoC) , souhaite revenir sur son choix sous condition d'entrée telle qu'exprimée dans le premier message 302 SIP-INVITE, le premier client PoC 106 envoie un message SIP-MESSAGE 409 comme cela été décrit en soi dans [9] au Controlling-PoC-Server 102, le message SIP-MESSAGE 409 contenant une indication correspondante. Cela pourrait se réaliser de la façon suivante: 10 MESSAGE sip:michael. jackson.chat@ptt.umts.de SIP/2.0 Content-Type: application/conditioned dial in cancellation+xml Content-Length: 0 Les informations supplémentaires suivant SIP qui représentent les demandes de revenir sur le choix conditionnel d'entrée sont, par rapport à un message habituel MESSAGE, soulignées en impression grasse dans l'exemple XML ci-dessus. A la Figure 4, est représenté, pour une explication plus précise suivant un organigramme 44 de flux de messages, qu'à un instant ultérieur, c'està-dire après que le Controlling-PoC-Server 102 a fait part au premier client PoC 106 que les conditions ne sont pas satisfaites, que l'utilisateur PoC "Peter" est entré dans la session de groupe Chat-PoC mentionnée (bloc 403). Cela s'effectue par le fait que le deuxième client PoC 107 produit un deuxième message 404 SIP-INVITE contenant l'indication du groupe de Chat et le transmet au Controlling-PoC-Server 102. Le Controlling-PoCServer 102 ajoute le deuxième client PoC 107, et ainsi à l'utilisateur PoC "Peter" de la session de groupe Chat-PoC mentionné comme participant PoC, et confirme cela au deuxième client PoC 107 au moyen d'un deuxième message 405 SIP-200-OK. En raison de la modification d'état dans la session de groupe PoC "Michael Jackson", le Controlling-PoC-Server 102 contrôle à nouveau si les conditions contenues dans le fichier de conditions de conférence pour les clients PoC respectifs sont maintenant satisfaites (stade 406). Dans ce cas, la condition du premier client PoC 106 est satisfaite par l'entrée de l'utilisateur PoC "Peter" dans la session du groupe Chat-PoC. Le Controlling-PoC-Server 102 ajoute ainsi ou invite en variante, comme représenté à la Figure 4, le premier client PoC 106 et ainsi fait entrer l'utilisateur PoC correspondant dans la session de groupe PoC au moyen d'un troisième message 407 SIP-INVITE que le Controlling-PoC-Server 102 transmet au premier client PoC 106. Si le premier client PoC 106 accepte l'invitation, le premier client PoC 106 produit un troisième message 408 SIP-200-OK et l'envoie au Controlling-PoC-Server 102 qui, à réception de ce message 408, ajoute le premier client PoC 106, et ainsi l'utilisateur PoC correspondant à la session de groupe PoC. Tant le premier client PoC 106 qu'également le deuxième client PoC 107 et ainsi l'utilisateur PoC du premier client PoC 106 et l'utilisateur PoC "Peter" sont ainsi participants à la session de groupe PoC souhaitée. Suivant un troisième exemple de réalisation de l'invention qui est réalisé selon la deuxième solution (cela n'est pas représenté aux figures) , on suppose que, dans une certaine session de groupe Chat-PoC, il n'y a pour l'instant pas de participant PoC. Suivant cet exemple de réalisation de l'invention, un premier utilisateur PoC choisit au moyen de son client PoC, suivant le procédé décrit cidessus, conformément au deuxième exemple de réalisation de l'invention, d'entrer sous la condition qu'au moins deux autres participants PoC participent à la session de groupe Chat-PoC. Mais comme, pour l'instant, le participant PoC serait tout seul, il n'est donc considéré par le Controlling-PoC-Server 102 que comme un participant PoC potentiel à cette session de groupe Chat-PoC. Le message SIPINVITE correspondant suivant cet exemple de réalisation de l'invention pourrait se présenter de la manière suivante: INVITE sip:michael.jackson.chat@ptt.umts.de SIP/2.0 Content-Type: application/dial in conditions+aanl 10 Content-Length: (...) Les informations supplémentaires qui représentent les conditions imposées sont, par rapport à un message INVITE habituel suivant SIP, soulignées en caractères gras dans l'exemple XML ci-dessus. Ensuite, un deuxième utilisateur PoC choisit d'entrer sous la même condition dans la même session de groupe Chat-PoC. Lui aussi n'est considéré que comme un participant PoC potentiel dans cette session de groupe Chat-PoC, ce qui continue à valoir aussi pour le premier utilisateur PoC. Or, un troisième utilisateur PoC choisit d'entrer sous condition avec la même condition dans la même session de groupe Chat-PoC. Comme le Controlling-PoC-Server 102 connaît toutes les conditions et toutes les demandes d'accéder à la session de groupe PoC et les a mémorisées dans son fichier des conditions de conférence, il contrôle et il voit que pour tous les trois utilisateurs PoC, la condition a été satisfaite lorsque tous les trois utilisateurs PoC ont souhaité entrer dans la session de groupe Chat-PoC en tant que participants. Suivant cet exemple de réalisation de l'invention, le Controlling-PoCServer 102 commence donc, selon le procédé représenté dans le deuxième exemple de réalisation, à accepter tous les trois utilisateurs PoC en tant que participants PoC à la session de groupe PoC. Tous les trois utilisateurs PoC sont ainsi des participants PoC dans la session de groupe Chat-PoC souhaitée. Dans les exemples précédents, on n'a parlé que de groupes Chat-PoC dans lesquels un client PoC en règle générale choisit d'entrer soi-même. Dans les exemples suivants, on considérera le cas dans lequel un client PoC est invité à une session de groupe PoC (par exemple à une session de groupe Adhoc-PoC ou à une session de groupe Pre-arranged). Suivant un quatrième exemple de réalisation de l'invention, selon la deuxième solution décrite ci-dessus, une session de groupe préarrangée est définie pour un groupe de travail qui doit avoir comme participants un chef et deux de ses collaborateurs. Le premier collaborateur a un terminal de téléphonie mobile dans lequel est mis en oeuvre le premier client PoC 106, le deuxième collaborateur a un terminal de téléphonie mobile dans lequel est mis en oeuvre le deuxième client PoC 107 et le chef a un terminal de téléphonie mobile dans lequel est mis en oeuvre le troisième client PoC 108. Le quatrième exemple de réalisation est représenté dans un organigramme 500 de flux de messages à la Figure 5. Le groupe de travail est défini par une identité de groupe de travail (croup Identity) au moyen d'une SIP-Group-Identity "sip:arbeitsgruppell@Infineon.com" et peut donc être adressé de manière univoque. Suivant cet exemple de réalisation, le premier collaborateur initie une session de groupe PoC par ce groupe en transmettant, au moyen du premier PoC-Clients 106, au Controlling-PoC-Server 102 un message 501 SIP-INVITE avec la SIP-Group-Identity précitée du groupe de travail comme paramètre. A la réception du premier message 501 SIP-INVITE, tous les autres participants au groupe de travail, donc le chef et le deuxième collaborateur, sont invités par le Controlling-PoC-Server 102 au moyen d'un deuxième message 502 SIP-INVITE, qui est transmis au deuxième PoCClient 107, et au moyen d'un troisième message 503 SIP-INVITE, qui est transmis au troisième PoC-Client 108. Si un participant à ce groupe de travail souhaite accepter cette invitation à la session du groupe PoC, il émet ou son PoC-Client 107, 108 émet un message SIP-200-OK comme réponse à destination du Controlling-PoC- Server. Suivant cet exemple de réalisation, le deuxième PoCClient 107 envoie un premier message 504 SIP-200-OK dans lequel est contenue une condition suivant laquelle est décrit le cas que le deuxième collaborateur ne souhaite participer à la session de groupe PoC que sous une certaine condition. Dans ce cas, le deuxième collaborateur ne souhaite accepter l'invitation à la session de groupe PoC que si le chef participe aussi (déjà) à la session de groupe PoC en tant que participant PoC. C'est pourquoi il ajoute au premier message 504 SIP-200-OK la condition correspondante dans un champ de message prévu à cet effet et il émet cette acceptation conditionnelle à destination du Controlling-PoC-Server 102. Un exemple d'un message SIP de ce genre en XML est représenté dans ce qui suit par l'extension symbolisée en gras: sip:arbeitsgruppell@infineon.com SIP/2.0 Content-Type: application/accept conditions+xml Content-Length: (. ) Si le chef est déjà un participant PoC à la session de groupe PoC, le deuxième participant est immédiatement inscrit comme participant PoC à la session de groupe PoC...DTD: Si ce n'est pas le cas, ce qui est représenté de manière symbolique par l'étape de vérification (bloc 505), il est procédé de manière analogue à ce qui a déjà été décrit en relation avec l'exemple deux. Il y a donc aussi, suivant le quatrième exemple de réalisation, deux possibilités alternatives de réalisation. Suivant une première variante de réalisation, le Controlling-PoC-Server 102 émet un message 506 SIP-UPDATE à destination du premier PoC-Client 107, en variante un message SIP-INFO ou un message SIP-RE-INVITE, par lequel, en utilisant des SDP, il met les médias correspondants (notamment la voix) sur "inactif". Le résultat de la vérification peut être aussi contenu comme information supplémentaire dans le message 506 SIP-UPDATE (ou le message SIP-INFO ou le message SIP-REINVITE). Dès que le chef a été inscrit à la session de groupe PoC comme participant PoC, le Controlling-PoC-Server 102 émet à nouveau un message SIP, par exemple un message SIP-UPDATE, à l'aide duquel, en utilisant des SDP, il met alors à nouveau sur "actif" les médias correspondants (notamment la voix). Le deuxième collaborateur ou le deuxième PoC-Client 107 a alors maintenant aussi la valeur de participant PoC "normal". Cette variante est représentée à la Figure 5, le deuxième PoC-Client 107 produisant à la réception du message 506 SIP-UPDATE un deuxième message 507 SIP-200-OK et le transmettant au Controlling-PoC-Server 102. On fait l'hypothèse dans ce qui suit que, sur incitation de l'utilisateur PoC "chef", le troisième PoCClient 108 qui souhaite entrer dans la session de groupe PoC produit un troisième message 508 SIP-200-OK et le transmet au Controlling-PoC-Server 102. Sur la base de la modification d'état dans la session de groupe PoC, le Controlling-PoC-Server 102 vérifie à nouveau toutes les conditions enregistrées dans le fichier de conditions de conférence pour les clients PoC associés (étape de vérification 509). Dans ce cas, la condition du deuxième PoC-Client 107, indiquée dans le premier message 504 SIP-200-OK est remplie, et le deuxième PoC-Client 107 reçoit un deuxième message 510 SIP-UPDATE dans lequel, en utilisant des SDP, les médias correspondants sont mis sur "actif". En outre, il est contenu dans le message 510 SIP-UPDATE le résultat de la vérification de l'étape 509 de vérification précitée avec un résultat de vérification positif. Le deuxième PoC-Client 107 produit, à la réception du deuxième message 510 UPDATE, un quatrième message 511 SIP-200-OK et le transmet au Controlling-PoC-Server 102. Les trois PoC-Clients 106, 107, 108 ou les PoC utilisateurs correspondants sont maintenant des PoC participant à la session de groupe PoC pour le groupe de travail. Suivant une deuxième variante de réalisation du quatrième exemple de réalisation, il est prévu que le Controlling-PoC-Server 102 émet, sur un résultat de vérification négatif, un message SIP-BYE qui continue de surveiller cependant les conditions, c'est-à-dire les vérifie en continu. Le deuxième collaborateur vaut ainsi comme un PoC participant potentiel. Dès que le chef est inscrit à la session de groupe PoC comme participant PoC, le Controlling-PoC-Server 102 émet alors à nouveau un message SIPINVITE, en option avec le résultat de la vérification des conditions. Sur la base de la réception du message SIP-INVITE correspondant, le PoC-Client émet à nouveau le SIP-200-0K étendu suivant l'invention, décrit ci-dessus, par lequel le client PoC est alors inscrit comme participant PoC à la session de groupe PoC, car la condition est maintenant bien remplie. Suivant un cinquième exemple de réalisation de l'invention, il est prévu, en utilisant une variante prévue pour OMA "Pre- established Sessions" pour le cas où l'utilisateur PoC n'a d'abord qu'une liaison avec le Participating-PoC-Server 103, 104 ou 105, sans qu'il soit inscrit à une session de groupe PoC, qu'il est aussi tard qu'il le veut si une liaison au Controlling-PoC-Server 102 dès qu'il s'inscrit dans une session de groupe PoC. Dans ce cas, toutes les fonctionnalités suivant l'invention sont réalisées dans les Participating-PoC-Server 103, 104, 105 au lieu du Controlling-PoC-Server 102. De plus, les messages SIP-INVITE associés sont à remplacer par un message SIP-REFER correspondant. La Figure 6 représente un système 600 de conférence de télécommunication multimédia par radiotéléphone mobile suivant un exemple de réalisation supplémentaire préféré de l'invention. On indique, dans une réalisation en variante, qu'il ne doit pas s'agir nécessairement d'un système de conférence de télécommunication multimédia par radiotéléphone mobile. Les procédés décrits dans ce qui suit et ci-dessus peuvent être réalisés aussi dans un système de conférence de télécommunication multimédia par réseau fixe, par exemple dans un système de conférence de télécommunication multimédia par réseau fixe sur base Internet. Dans ce mode de réalisation en variante, au moins une partie des terminaux de télécommunication sont installés comme terminaux de télécommunication de réseau fixe, qui sont installés notamment pour la réalisation d'une conférence de télécommunication à base Internet. 15 Le système 600 est, pour tous les exemples de réalisation, qui sont explicités plus en détail dans ce qui suit, identique, à l'exception des différentes configurations du serveur focus qui est prévu chaque fois de manière à mettre en oeuvre les fonctionnalités des exemples de réalisation associés. Le système 600 de communication est configuré suivant les modes de réalisation de l'invention, comme décrit dans [10], à l'exception des modifications décrites ci-dessous. Le "Conferencing Framework" décrit dans [10] et représenté à la Figure 6 met à disposition des utilisateurs, notamment des terminaux 601, 602, 603, 604 de radiotéléphone mobile, différents services de conférence de télécommunication multimédia. Il est prévu notamment, comme cela est décrit en détail dans [10], un service pour commander les droits d'accès à des ressources de conférence de télécommunication, aussi désigné comme Floor Control, un service pour établir des règles de conférence (qui est aussi désigné comme ConferencePolicy-Control), ainsi que, sous forme de procédure basée sur le Session Initiation Protocol (SIP), des services supplémentaires pour produire, pour gérer, pour entrer dans et pour quitter une conférence de télécommunication multimédia. De plus, le système 600 de communication met à disposition, comme cela est décrit également dans [10], des procédés pour informer les participants 601, 602, 603, 604 à une conférence, aussi désignés comme Conference-Notification-Service, sur des informations et des événements (Events) spécifiques concernant une conférence de télécommunication multimédia associée. Le système 600 de conférence est prévu de manière que des genres de médias quelconques puissent être échangés entre les participants, c'est-à-dire entre les terminaux 601, 602, 603, 604 de radiotéléphone mobile. Des exemples de genres de médias qui peuvent être transmis et traités dans le cadre du système 600 de conférence sont des données audio, des données vidéo, des données Instant-Messaging et des données de jeux Multiplayer dans le cadre d'une conférence de gaming. La Figure 6 représente, comme décrit ci-dessus, le système 600 de conférence de télécommunication multimédia suivant les exemples de réalisation de l'invention, avec ses composants individuels et l'interaction entre les composants. Le système 600 de conférence de télécommunication multimédia a une architecture de conférence en forme d'étoile dans laquelle tous les participants à la conférence (aussi désignés comme User Agents), suivant cet exemple de réalisation les terminaux 601, 602, 603, 604 de radiocommunication mobile, sont reliés au dispositif 605 serveur de conférence, aussi désigné comme focus 605, au moyen de liaisons 606 de communication de signalisation SIP. Mais la Figure 6 ne représente qu'à titre d'exemple une de ces liaisons 606 de communication de signalisation SIP. Il est associé à une conférence de télécommunication par radiocommunication mobile déterminée, qui est associée à un ordinateur 605 serveur de conférence déterminé, c'est-à-dire à un focus déterminé, ou qui est réalisée, une adresse de conférence univoque, dite Conference- Unique Resource Identifier (C-URI). La C-URI représente et adresse la conférence associée de manière univoque. Le focus 605 a, entre autres, accès indirect à la Conference-Policy. Le fichier Conference-Policy, désigné dans ce qui suit aussi comme fichier 608 de règles de conférence, se compose habituellement de façon logique de deux zones partielles, une MembershipPolicy 609, ainsi qu'une Media-Policy 610. Mais le fichier 608 ConferencePolicy peut, dans certaines circonstances, être mis en mémoire de manière subdivisée physiquement sur plusieurs sous-fichiers. Outre la séparation physique, il peut y être effectué aussi une subdivision logique du fichier 608 Conference-Policy. Le fichier 608 de règles de conférence est produit par un serveur 111 de règles de conférence (Conference-Policy Server) de manière exclusive pour une conférence associée, symbolisé à la Figure 6 par une flèche 612. Le focus 605 est informé par l'intermédiaire du serveur 611 de règles de conférence du contenu de chaque modification du fichier Conference-Policy. On peut aussi imaginer que le focus 605 ait un accès direct au fichier 608 Conference-Policy. En plus de la modification de ces règles de conférence mémorisées dans le fichier 608 de règles de conférence, le focus 605 a pour tâche d'assurer pour la conférence des distributions spécifiques des courants de données de médias. Pour distribuer les courants de données de médias, le focus 605 utilise ce que l'on appelle des mixers 613, autrement dit des dispositifs de mélange de courants de données qui, en utilisant les règles de médias mémorisées dans la Media-Policy 610, réalisent la réunion et la distribution des courants de données de médias sur les terminaux 601, 602, 603, 604 de radiocommunication mobile participant à la conférence, ce qui est symbolisé à la Figure 6 au moyen des doubles flèches 614, 615, 616, 617. La liaison de communication entre le focus 605 et le mixer 613 est symbolisée au moyen d'une flèche 607. Dans les terminaux 601, 602, 603, 604 de radiocommunication mobile, il est mis en oeuvre pour les changements du service de conférence quelques procédures, protocoles de communication et fonctionnalités supplémentaires, il est mis en oeuvre notamment de nouvelles procédures SIP supplémentaires, et il est mis en oeuvre du côté du serveur ce que l'on appelle le Binary Floor Control Protocol (BFCP) dans un Floor Control Server 618, et le Conference Policy Control Protocol (CPCP) et les unités associées, qui sont en mesure de réaliser les protocoles de communication correspondants. La liaison de communication Binary Floor Control Protocol entre un premier terminal 601 de radiocommunication mobile et le Floor Control Server 618 est symbolisée par une flèche 619 à la Figure 1. Le Conference Policy Control Protocol (CPCP) décrit dans [11] offre la possibilité de définir différentes règles pour une conférence de télécommunication multimédia. Il peut être indiqué au moyen du CPCP, par exemple, des règles de conférence générales, comme par exemple le nombre maximum des participants à la conférence, à l'intérieur du fichier 608 de règles de conférence (Conference-Policy). Le fichier 608 de règles de conférence contient de plus, par exemple, ce que l'on appelle une liste "Dial-out" ( -élément de données), qui indique les utilisateurs ou les terminaux de télécommunication qui, lors d'une activation d'une conférence, doivent y être invités. La Conference-Policy contient de plus des éléments de données d'autorisation au moyen desquels il est indiqué les utilisateurs que d'autres utilisateurs peuvent entrer dans la liste "Dial-out" ( -élément de données). Pour fixer qui doit traiter les éléments de données d'autorisation, il est prévu suivant CPCP un élément de donnée d'autorisation de rang supérieur qui règle l'accès à tous les autres éléments de données d'autorisation ( -élément de données). Le fichier 608 de règles de conférence est indiqué au moins sous la forme d'un document XML (fichier Extensible- Markup-Language). Sur la base de l'utilisation de XML pour décrire le fichier 608 de règles de conférence, il est possible d'étendre, d'une manière générale de modifier, de manière simple le fichier de règles de conférence. Pour transmettre les fichiers XML, c'est-à-dire notamment le fichier 608 de règles de conférence, ou pour lire des données dans le fichier 608 de règles de conférence et/ou pour écrire des données dans le fichier 608 de règles de conférence, on utilise le Hypertext Transport-Protocol (HTTP). L'écriture d'un fichier 608 de règles de conférence ou l'écriture dans un fichier 608 de règles de conférence s'effectue au moyen d'une HTTP Put Request, tandis que pour lire un fichier 608 de règles de conférence ou une partie d'un fichier 608 de règles de conférence, on utilise une HTTP Get Request et, pour effacer tout un fichier 608 de règles de conférence ou une partie du fichier 608 de règles de conférence, on utilise une HTTP Read Request. Le CPCP permet, de plus, d'adresser des éléments individuels, des attributs ou des valeurs d'attribut d'un document XML et donc du fichier 608 de règles de conférence, suivant cet exemple de réalisation de l'invention, au moyen du HTTP Unique Resource Locators (HTTP URL). Suivant cet exemple de réalisation de l'invention, il peut être mis en mémoire dans le fichier 608 de règles de conférence, défini en XML, les conditions correspondantes qui sont transmises par un terminal de radiocommunication mobile et, à l'aide du fichier 608 de règles de conférence, les terminaux de radiocommunication mobile peuvent être ajoutés ou non à une conférence. Les opérations de communication associées peuvent s'effectuer de manière analogue aux flux de messages décrits ci-dessus. Dans ces exemples de réalisation, qui sont basés sur le "Conference Framework" décrit dans [10], on peut aussi réaliser les unités réalisant la vérification des conditions associées dans des terminaux de communication, dans le serveur focus, dans le Conference-Policy-Server ou dans un autre dispositif serveur de manière centrale. Pour résumer, on appréhendera comme avantageux les aspects suivants de l'invention: 20 É L'utilisateur PoC peut fixer des conditions dans le PoC-Client, dans le Participating-PoC-Server ou dans le Controlling-PoC-Server, qui doivent être satisfaites avant qu'il ne devienne un participant PoC à une session de groupe PoC déterminée. É Le PoC client observe à l'aide du service de "Session Status Notification" le statut instantané d'une session de groupe PoC. É Dans le cas où la ou les conditions sont remplies, le PoC-Client s'inscrit automatiquement à la session de groupe PoC, l'utilisateur PoC est informé en conséquence. É Le PoC-Client s'inscrit dans une session de groupe PoC et envoie conjointement des conditions au Controlling-PoC-Server (inscription conditionnelle). É Le PoC-Client est invité à une session de groupe PoC et envoie des conditions avec la confirmation au Controlling-PoC-Server (acceptation conditionnelle). É Le Controlling-PoC-Server observe en permanence si la ou les conditions est ou sont remplies; dès que cela est le cas, le participant PoC potentiel devient participant PoC. Dans ce mémoire descriptif, on cite les publications suivantes. [1] Push to Talk over Cellular (PoC) ; PoC Release 2.0 http://www. motorcla.com/content/0,,2647-4398,00.html [2] RFC 3261 "SIP: Session Initiation Protocol" [3] RFC 3550 "RTP: A Transport Protocol for Real-Time Applications" [4] Internet Draft "A Session Initiation Protocol (SIP) Event Package for Conference State" [5] RFC 3265 "Session Initiation Protocol (SIP)-Specific Event Notification" [6] RFC 3311 "The Session Initiation Protocol (SIP) UPDATE Method" [7] RFC 2976 "The SIP INFO Method" [8] RFC 2327 "SDP: Session Description Protocol" [9] RFC 3428 "Session Initiation Protocol (SIP) Extension for Instant Messaging" [10] J. Rosenberg, A framework for conferencing with the session initiation protocol, SIP Internet-Draft, IETF SIPPING working group: Draft-IETF-SIPPING-conferencingframework-02, Juni 2004 [11] H. Khartabil et al., The Conference Policy Control Protocol (CPCP), XCON, Internet Draft, IETF XCON Working Group: Draft IETF-XCON-CPCP-XCAP- 01, Juli 2004 [12] US 2003/0153339 Al [13] US 2004/0205212 Al [14] US 2004/0199580 Al Enumération des signes de référence Système de conférence de télécommunication PoC 101 Réseau de communication du réseau fixe 102 Controlling-PoC-Server 103 Participating-PoC-Server 104 Participating-PoC-Server Participating-PoC-Server 106 Client PoC 107 Client PoC 108 Client PoC 109 Interface radio Interface radio 111 Interface radio 112 Chair Organigramme de flux de messages 201 Bloc 202 Message SIP-SUBSCRIBE 203 Premier message SIP-NOTIFY 204 Stade de contrôle 205 Bloc 206 Premier message SIP-INVITE 207 Premier message SIP-200-OK 208 Deuxième message SIP-NOTIFY 209 Stade de contrôle 210 Deuxième message SIP-INVITE 211 Deuxième message SIP-200-OK 300 Organigramme de flux de messages 301 Bloc 302 Premier message SIP-INVITE 303 Stade de contrôle 304 Premier message SIP-200-OK 305 Bloc 306 Bloc 307 Deuxième message SIP-INVITE 308 Deuxième message SIM-200-OK 309 Stade de contrôle 310 Message SIP-UPDATE 311 Troisième message SIP-200-OK 400 Organigramme de flux de messages 401 Premier message SIP-200-OK 402 Message SIP-BYE 403 Bloc 404 Deuxième message SIP-INVITE 405 Deuxième message SIP-200-OK 406 Stade de contrôle 407 Troisième message SIP-INVITE 408 Troisième message SIP-200-OK 409 Message SIP-MESSAGE 500 Organigramme de flux de messages 501 Premier message SIP-INVITE 502 Deuxième message SIP-INVITE 503 Troisième message SIP-INVITE 504 Premier message SIP-200-OK 505 Stade de contrôle 506 Message SIP-UPDATE 507 Deuxième message SIP-200-OK 508 Troisième message SIP-200-OK 509 Stade de contrôle 510 Message SIP-UPDATE 511 Quatrième message SIP-200-OK 600 Système de conférence de télécommunication multimédia 601 Terminal de téléphonie mobile 602 Terminal de téléphonie mobile 603 Terminal de téléphonie mobile 604 Terminal de téléphonie mobile 605 Focus 606 Liaison de communication de signalisation SIP 607 Flèche 608 Fichier de régulation de conférence 609 Membership-Policy 610 Media-Policy 611 Serveur de réglage de conférence 612 Flèche 613 Dispositif de mélange de flux de données 614 Flèche double 615 Flèche double 616 Flèche double 617 Flèche double 618 Floor Control Server 619 Flèche 20 REVENDICATIONS 1. Procédé de production et/ou de commande automatique d'une conférence de télécommunication avec une pluralité de participants, dans lequel on mémorise dans un fichier de conditions de conférence électronique au moins une condition de conférence définie pour l'utilisateur du point de vue de la production de la conférence de télécommunication et/ou du point de vue de la participation d'un ou de plusieurs participants à la conférence de télécommunication, caractérisé en ce que É on contrôle en utilisant le fichier de conditions de conférence si au moins une condition de conférence mémorisée est satisfaite, et É dans lequel, dans le cas où au moins une condition de conférence mémorisée est satisfaite, on produit la conférence de télécommunication et/ou on ajoute le participants ou les participants à la conférence de télécommunication. 2. Procédé suivant la revendication 1, caractérisé en ce qu'il est utilisé dans une conférence de télécommunication multimédia. 3. Procédé suivant la revendication 1 ou 2, caractérisé en ce qu'il est utilisé dans une conférence de télécommunication du réseau fixe, notamment dans une conférence de télécommunication du réseau fixe fondé sur Internet, ou dans une conférence de télécommunication en téléphonie mobile, notamment dans une conférence de télécommunication en téléphonie mobile reposant sur des cellules. 4. Procédé suivant la revendication 1 ou 2, caractérisé en ce qu'il est utilisé dans une conférence de télécommunication en téléphonie mobile 3GPP, notamment dans une conférence de télécommunication en téléphonie mobile UMTS. 5. Procédé suivant la revendication 1 ou 2 ou 4, caractérisé en ce qu'il est utilisé dans une conférence de télécommunication mobile Push-to-Talk over Cellular, notamment de l'un des types suivants: É conférence de télécommunication de téléphonie mobile ad hoc; É conférence de télécommunication de téléphonie 10 mobile Pre-arranged; É conférence de télécommunication de téléphonie mobile chat. 6. Procédé suivant l'une des revendications 1 à 5, caractérisé en ce que le fichier de conditions de conférence est mémorisé dans un terminal d'un participant. 7. Procédé suivant la revendication 6, caractérisé É en ce qu'on transmet une information de statut par la conférence de télécommunication à un terminal de participant, et É en ce qu'on effectue le contrôle par le terminal de participant en utilisant l'information de statut reçue. 9. Procédé suivant la revendication 7, caractérisé en ce que l'on transmet une information 25 de statut par la conférence de télécommunication à un terminal de participant lorsque survient un événement donné à l'avance. 10. Procédé suivant la revendication 8, caractérisé en ce que l'on transmet une information de statut par la conférence de télécommunication à un terminal de participant lorsque survient une variation de statut de la conférence de télécommunication. 11. Procédé suivant l'une des revendications 1 à 5, caractérisé en ce que l'on mémorise le fichier de conditions de conférence dans un serveur de conférence de télécommunication. il. Procédé suivant la revendication 10, caractérisé É en ce qu'on contrôle les demandes de conférence de télécommunication reçues pour une multiplicité de demandes de conférence de télécommunication reçues par le serveur de conférence de télécommunication si la condition de conférence est satisfaite en satisfaisant les demandes de conférence de télécommunication, et É en ce que, dans le cas où, en satisfaisant les demandes de conférence de télécommunication, on satisfait la condition de conférence, on produit la conférence de télécommunication et/ou on ajoute le participant ou les participants à la conférence de télécommunication. 12. Procédé suivant l'une des revendications 1 à 11, caractérisé en ce que l'on tient compte, comme condition de conférence, d'une ou de plusieurs des conditions de conférence suivantes: É un nombre donné à l'avance, notamment un nombre minimum et/ou un nombre maximum, de participants intéressés ou participant à la conférence de télécommunication; É une identité de participant intéressé ou participant à la conférence de télécommunication; É un instant de la production d'une conférence de télécommunication; É un instant où il est mis fin à une conférence de télécommunication; É une durée d'une conférence de télécommunication; É le contenu d'une conférence de télécommunication; 20 25 É l'intensité de communication dans une conférence de télécommunication, notamment la proportion de temps dans laquelle on parle et/ou la fréquence de changement de celui qui est autorisé à parler. 13. Terminal de conférence de télécommunication, caractérisé en ce qu'il comprend É une unité de conférence de télécommunication qui est conçue pour la communication avec d'autres terminaux de conférence de télécommunication et/ou avec un serveur de conférence de télécommunication dans une conférence de télécommunication, É une mémoire de mémorisation d'un fichier de conditions de conférence électronique, dans lequel au moins une condition de conférence définie pour l'utilisateur du point de vue de la production de la conférence de télécommunication et/ou du point de vue de la participation d'un ou de plusieurs participants à la conférence de télécommunication est contenue, É une unité de contrôle de conférence de télécommunication couplée à la mémoire et conçue pour contrôler, en utilisant le fichier de conditions de conférence, si au moins une condition de conférence mémorisée est satisfaite, É une unité de production de messages de conférence de télécommunication qui est conçue de façon à ce que, dans le cas où elle contient une information provenant de l'unité de contrôle de conférence de télécommunication suivant laquelle au moins une condition de conférence mémorisée est satisfaite, elle produit l'un des messages suivants: É un message de demande de production de conférence par lequel la production d'une 10 conférence de télécommunication est demandée, É un message d'entrée en conférence par lequel il est fait part de l'entrée du terminal de conférence de télécommunication dans la conférence de télécommunication. 14. Serveur de conférence de télécommunication, caractérisé en ce qu'il comprend É une unité de conférence de télécommunication qui est conçue pour la communication avec d'autres terminaux de conférence de télécommunication et/ou avec un serveur de conférence de télécommunication dans une conférence de télécommunication, É une mémoire de mémorisation d'un fichier de conditions de conférence électronique, dans lequel au moins une condition de conférence définie pour l'utilisateur du point de vue de la production de la conférence de télécommunication et/ou du point de vue de la participation d'un ou de plusieurs participants à la conférence de télécommunication est contenue, É une unité de contrôle de conférence de télécommunication couplée à la mémoire et conçue pour contrôler, en utilisant le fichier de conditions de conférence, si au moins une condition de conférence mémorisée est satisfaite, É une unité de production/commande d'une conférence de télécommunication qui est conçue de manière à ce que, dans le cas où au moins une condition de conférence mémorisée est satisfaite, elle produit la conférence de télécommunication et/ou ajoute un participant ou plusieurs participants à la conférence de télécommunication.