Brevet FR2889900A1 — publié le 20070223

PROCÉDÉ POUR LA CRÉATION ASSISTÉE PAR ORDINATEUR D'UN MESSAGE DE VOTE, PROCÉDÉ POUR LA DÉTERMINATION ASSISTÉE PAR ORDINATEUR D'AU MOINS UN RÉSULTAT DE VOTE, PROCÉDÉ POUR LE TRAITEMENT ASSISTÉ PAR ORDINATEUR D'UN MESSAGE DE VOTE, UNITÉ DE PROTOCOLE DE COMMANDE DE PROTOCOLE DE TRANSPORT, UNITÉ D'ÉVALUATION DE VOTE DE CONFÉRENCE, UNITÉ FORMANT SERVEUR DE CONFÉRENCE ET TERMINAL DE COMMUNICATION L'invention concerne un procédé pour la création assistée par ordinateur d'un message de vote, un procédé pour la détermination assistée par ordinateur d'au moins un résultat de vote, un procédé pour le traitement assisté par ordinateur d'un message de vote, des unités de protocole de commande de protocole de transport, une unité d'évaluation de vote de conférence, une unité formant serveur de conférence et un terminal de communication. Dans un système de communication moderne, il est souvent souhaitable de proposer une conférence entre plusieurs abonnés, c'est-à-dire entre plusieurs terminaux de communication, dans le cadre du système de communication. Un système de communication qui propose un système de conférence de ce type permet une communication entre plusieurs utilisateurs en utilisant des terminaux de communication. Il faut comprendre ci-dessous par système de conférence par exemple un système de conférence basé sur l'Internet Protocol ou un système appelé Push-to-Talk, de manière générale tout système dans lequel des terminaux de communication peuvent communiquer entre eux à l'intérieur d'une conférence de communication dans le cadre d'un système de communication c'est-à-dire que des données peuvent être transmises entre les terminaux de communication. Il faut comprendre par système de communication Push- to-Talk (système de communication PTT) par exemple le système de communication "Direct Connect" de la société Nextel aux États-unis ou le système de communication Pushto-Talk over Cellular (PoC) de Open Mobile Alliance (OMA), un système de communication PTT étant un système de communication à plusieurs abonnés pour des terminaux de radiocommunication mobile, par exemple pour des téléphones de radiocommunication mobile. Comme lors de la manipulation d'un talkie-walkie, un locuteur actionne en général une touche spéciale sur son terminal de radiocommunication mobile pour demander une autorisation de parler puis pour transmettre des messages vocaux à d'autres terminaux de radiocommunication mobile dans le cadre de la session de communication PPT. La transmission de messages d'autres utilisateurs d'autres terminaux de radiocommunication mobile est bloquée pendant ce temps. Le système de communication PTT est donc généralement un système de communication en semi-duplex. Dans un système de conférence selon une proposition de l'IETF (Internet Engineering Task Force) tel qu'il est décrit dans [1] ou dans un système de communication Pushto-Talk actuel, les données multimédia à transmettre, par exemple des données audio et/ou des données vidéo et/ou des données d'images et/ou des données de textes, sont transmises au moyen du protocole appelé Real-Time Transport Protocol (RTP) (cf. [1], [2]). Les flux de données multimédia sont contrôlés au moyen du protocole appelé Real-Time Transport Control Protocol (RTCP) comme c'est décrit par exemple dans [3]. Le système de conférence selon [1] et le système de communication Push-toTalk ont une architecture décentralisée (cf. [1], [2]). En d'autres termes, les abonnés d'un système de conférence de ce type ne communiquent pas directement entre eux mais la communication s'effectue au moyen d'une unité centrale formant serveur. L'unité centrale formant serveur, aussi appelée unité formant serveur de conférence, est placée dans un système de radiocommunication mobile dans la partie non mobile du réseau de communication, par exemple dans le réseau d'infrastructure (Core Network) pour l'UMTS (Universal Mobile Telecommunications System). [4] décrit un système de communication pour plusieurs abonnés dans lequel une fonction de vote est fournie pour le vote via une question pouvant être prescrite. Les fonctions de vote sont réalisées selon [4] avec un protocole spécial pour des messages de vote. En variante, on sait selon [5] émettre des messages de vote en utilisant RTP. On sait aussi selon [6] réaliser des votes en exploitant des compteurs qui sont utilisés en commun et qui sont aussi appelés compteurs partagés ou "Shared Counter". Par ailleurs, [7] décrit un format pour la présentation d'une indication temporelle absolue, aussi appelée Network Time Protocol. [8] décrit la forme dite Backus Naur Form (BNF). De plus, on peut utiliser dans un système de communication Push-to-Talk le bouton de demande des terminaux de communication d'abonnés pour un vote simple (à deux valeurs). La publication [9] décrit un système de communication avec plusieurs terminaux de communication. Chaque terminal de communication peut être configuré de telle sorte qu'un utilisateur peut entrer une réponse dans le cadre d'un événement de communication. Selon une variante, les terminaux de communication peuvent être configurés comme des stations de base. On obtient de cette manière une grande flexibilité et il n'est pas nécessaire d'avoir une station de base dédiée pour un événement de communication. [10] révèle un serveur multimédia qui est installé pour gérer une conférence multimédia et qui comporte une mémoire pour mémoriser des demandes d'actions. Il est aussi prévu des terminaux d'utilisateurs avec lesquels des utilisateurs peuvent entrer des appels d'actions, par exemple au moyen d'une entrée vocale ou d'une entrée de texte, à la suite desquels des demandes d'actions associées sont déclenchées. L'invention vise à permettre facilement la mise en uvre d'un vote assisté par ordinateur dans un système de 5 conférence. Le problème est résolu par un procédé pour la création assistée par ordinateur d'un message de vote, par un procédé pour la détermination assistée par ordinateur d'au moins un résultat de vote, par un procédé pour le traitement assisté par ordinateur d'un message de vote, par des unités de protocole de commande de protocole de transport, par une unité d'évaluation de vote de conférence, par une unité formant serveur de conférence et par un terminal de communication, tous ces éléments ayant les caractéristiques présentées ci-dessous. Dans un procédé pour la création assistée par ordinateur d'un message de vote dans une conférence entre plusieurs terminaux de communication, on code le message de vote selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé, une information qui identifie au moins une question de vote ou au moins une réponse de vote étant adjointe au message de vote. Dans un procédé pour la détermination notamment assisté par ordinateur d'au moins un résultat de vote d'au moins un vote dans une conférence entre plusieurs terminaux de communication, on décode au moins un message de réponse de vote reçu qui est codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, avec lequel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé, le message de réponse de vote contenant au moins une réponse à la au moins une question du vote. On détermine la au moins une réponse à partir du message de réponse de vote décodé et, en utilisant la au moins une réponse déterminée, on détermine le au moins un résultat de vote. Dans un procédé pour le traitement, notamment assisté par ordinateur, d'un message de vote dans une conférence entre plusieurs terminaux de communication, on reçoit un message de vote codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé et on détermine à partir du message de vote une information qui identifie au moins une question de vote et/ou au moins une réponse de vote et qui est contenue dans le message de vote. La au moins une question de vote et/ou au moins une réponse de vote sont présentées à un utilisateur d'un terminal de communication participant au vote et un utilisateur entre au moins une réponse à la au moins une question de vote c'est-à-dire qu'il vote conformément à la question de vote. De plus, un message de réponse de vote est codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, avec lequel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé, une information qui identifie la au moins une réponse de vote à la au moins une question de vote étant adjointe au message de réponse de vote. Selon un autre aspect de l'invention, on fournit une unité de protocole de commande de protocole de transport, par exemple une unité de protocole de commande de protocole de transport à temps réel, qui est conçue pour créer un message de vote dans une conférence entre plusieurs terminaux de communication, le message de vote étant codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé, une information qui identifie au moins une question de vote et/ou au moins une réponse de vote étant adjointe au message de vote. Selon un autre aspect de l'invention, il est prévu une unité d'évaluation de vote de conférence avec une unité de protocole de commande de protocole de transport, par exemple une unité de protocole de commande de protocole de transport à temps réel, pour décoder au moins un message de réponse de vote qui est codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé. Il est aussi prévu une unité de détermination pour déterminer au moins une réponse à au moins une information identifiant une question de vote à partir du message de réponse de vote décodé ainsi qu'une unité d'évaluation de vote pour déterminer un résultat de vote en utilisant la au moins une information identifiant la réponse à au moins une question de vote. Une unité formant serveur de conférence comporte une unité d'évaluation de vote de conférence décrite ci-dessus. Par ailleurs, il est prévu une unité de protocole de commande de protocole de transport, par exemple une unité de protocole de commande de protocole de transport à temps réel, pour créer un message de réponse de vote dans une conférence entre plusieurs terminaux de communication, le message de réponse de vote étant codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé, une information qui identifie au moins une réponse de vote à au moins une question de vote étant adjointe au message de réponse de vote. Un terminal de communication comporte une unité de conférence qui est conçue pour mettre en place une conférence ou participer à une conférence avec au moins un autre terminal de communication. Il est aussi prévu une première unité de protocole de commande de protocole de transport, par exemple une unité de protocole de commande de protocole de transport à temps réel, pour mettre en place une conférence ou décoder au moins un message de vote qui est codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé. De plus, le terminal de communication comporte une unité de détermination pour déterminer au moins une information identifiant une question de vote et/ou au moins une réponse de vote à partir du message de vote décodé et une unité de présentation pour présenter à un utilisateur l'information déterminée ou la au moins une question de vote et/ou réponse de vote déterminée à partir de là. Il est prévu une unité d'entrée pour entrer au moins une réponse à la au moins une question de vote. Il est aussi prévu une deuxième unité de protocole de commande de protocole de transport, par exemple une deuxième unité de protocole de commande de protocole de transport à temps réel, pour créer un message de réponse de vote dans une conférence entre plusieurs terminaux de communication, le message de réponse de vote étant codé selon un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, au moyen duquel un protocole de transport, par exemple un protocole de transport à temps réel, est commandé, une information qui identifie la au moins une réponse à la au moins une question de vote étant adjointe au message de réponse de vote. Un aspect de l'invention est qu'une possibilité de vote est proposée comme service de communication dans le cadre d'une conférence de communication entre plusieurs terminaux de communication dans un système de communication, l'information déterminante dans le cadre du vote, par exemple la question de vote et/ou de possibles réponses prédéterminées ou définies librement par un utilisateur d'un appareil de communication participant, étant transmise en utilisant un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel. Comparé à l'état de la technique, on arrive ainsi pour la première fois à ne pas avoir à prévoir un protocole propriétaire comme selon [4] mais à pouvoir utiliser un protocole de commande de protocole de transport, ce qui apporte des améliorations considérables du point de vue des performances de l'ensemble de l'échange de données. En d'autres termes, selon un aspect de l'invention, dans un système de communication qui utilise un protocole de commande de protocole de transport, par exemple un protocole de commande de protocole de transport à temps réel, un message ou des messages de vote sont envoyés comme messages selon le protocole de commande de protocole de transport, par exemple le protocole de commande de protocole de transport à temps réel. Un message de vote peut contenir une ou plusieurs questions de vote ou une ou plusieurs réponses de vote que peut sélectionner un utilisateur qui participe au vote. Le message de réponse de vote peut contenir une ou plusieurs réponses à la question de vote, par exemple une réponse librement formulable par l'utilisateur, selon une variante une information de sélection via une réponse qui est prédéterminée pour l'utilisateur en vue d'une sélection et qui a été sélectionnée. L'information qui identifie la question de vote ou la réponse de vote peut être un renvoi à une question de vote ou à une réponse de vote mémorisée dans une autre unité formant serveur, un adressage univoque de la question ou de la réponse étant par exemple prévu dans ce cas, par exemple en utilisant un Unique Resource Identifier (URI), mais l'information peut aussi être la question ou la réponse de vote elle-même qui peut être contenue dans le message de vote respectif ou dans le message de réponse de vote respectif. Des formes de réalisation de l'invention sont décrites dans la suite du document. Comme protocole de commande de protocole de transport 10 à temps réel, on peut utiliser le Real-Time Transport Control Protocol (RTCP). Comme protocole de transport à temps réel, on peut utiliser le Real-Time Transport Protocol (RTP). Le vote peut s'effectuer dans le cadre d'une conférence en semi-duplex, par exemple dans le cadre d'une conférence Push-to-Talk, par exemple une conférence "Direct Connect" ou une conférence Push-to-Talk over Cellular (conférence PoC). Selon une variante, le vote peut s'effectuer dans le cadre d'une conférence basée sur l'Internet Protocol ou en utilisant l'Internet Conferencing Frameworks, comme décrit par exemple dans [1]. Le au moins un message de réponse de vote peut être reçu par une unité formant serveur de conférence dans le cadre du procédé pour la détermination assistée par. ordinateur d'au moins un résultat de vote et/ou le au moins un résultat de vote peut être déterminé par une unité formant serveur de conférence. Dans une autre forme de réalisation du procédé pour la détermination assistée par ordinateur d'au moins un résultat de vote, il est prévu que le au moins un résultat de vote déterminé est transmis à au moins un terminal de communication participant à la conférence, par exemple au terminal de communication qui a déclenché le au moins un vote. Cette forme de réalisation de l'invention peut être telle que l'unité formant serveur de conférence ou une autre unité qui détermine le résultat de vote retransmet celui-ci à un ou plusieurs autres terminaux de communication, sachant qu'il peut être prévu que seul le terminal de communication qui a déclenché le au moins un vote a le droit de recevoir le résultat du vote. Selon une variante, il peut toutefois être prévu que tous les terminaux de communication participant au vote reçoivent le résultat du vote. Les autorisations respectives peuvent être données par le terminal de communication déclenchant le vote et, selon une variante, l'unité formant serveur de conférence ou l'unité déterminant le résultat du vote peut donner ces autorisations. Selon une autre forme de réalisation du procédé pour la détermination assistée par ordinateur d'au moins un résultat de vote, le au moins un message de réponse de vote est reçu par une unité formant serveur de conférence et le message de réponse de vote et/ou une information de réponse de vote contenue dans le message de réponse de vote sont transmis à au moins un terminal de communication participant à la conférence, par exemple au terminal de communication qui a déclenché le vote. Selon une forme de réalisation de l'invention pour le traitement d'un message de vote, il est prévu que le message de réponse de vote est envoyé à une unité formant serveur de conférence. Les unités de protocole de commande de protocole de transport à temps réel peuvent être mises en uvre conformément au Real-Time Transport Control Protocol (RTCP). D'autres caractéristiques et avantages de la présente 30 invention ressortiront plus clairement à la lecture de la description qui va suivre à titre d'exemple, lorsque prise en relation avec les dessins annexés, sur lesquels: Figure 1: une architecture d'un système de communication Push-to-Talk selon un exemple de réalisation de l'invention; et Figure 2: un diagramme de flux de messages dans lequel est représenté le flux de messages dans le cadre d'un processus de vote selon un exemple de réalisation de l'invention. On décrit maintenant comme exemple de réalisation un système de communication Push-to-Talk over Cellular (système de communication PoC) 100 (cf. figure 1) tout en attirant l'attention sur le fait que, dans une variante de réalisation, on peut aussi utiliser un autre système de communication Push-to-Talk ou un autre système de communication, par exemple un autre système de communication en semi-duplex, ou le système de conférence de communication selon l'IETF Conferencing Framework comme décrit dans [1]. Le système de communication Push-to-Talk over Cellular 100 est conçu tel qu'il est décrit dans [2]. On suppose ci-dessous que, dans une conférence Push- to-Talk qui est proposée par une unité centrale formant serveur Push-to-Talk 101, quatre terminaux de radiocommunication mobile qui contiennent chacun un client Push-to-Talk over Cellular et qui sont conçus pour la communication selon [2] ont établi entre eux une conférence Push-to-Talk. Il faut comprendre par conférence en semi-duplex une conférence dans laquelle au plus un terminal de communication participant, et non plusieurs terminaux de communication, a une autorisation de parler à un moment donné. À un moment donné, un seul terminal de communication a donc par exemple le droit de parler c'est-à-dire plus généralement le droit d'apporter des données dans la conférence de communication et de les transmettre aux autres terminaux de communication participants. Les autres terminaux de communication peuvent simplement recevoir les données apportées et, sans droit de parole particulier c'est-à-dire sans droit de communication particulier, ils ne peuvent apporter aucune donnée, notamment aucun message vocal dans la conférence de communication, par exemple une conférence de télécommunication. Dans la conférence proposée par l'unité formant serveur de conférence Push-to-Talk over Cellular 101, quatre terminaux de radiocommunication mobile 102, 103, 104, 105, à savoir un premier terminal de radiocommunication mobile 102, un deuxième terminal de radiocommunication mobile 103, un troisième terminal de radiocommunication mobile 104 et un quatrième terminal de radiocommunication mobile 105, prennent part à la conférence. Chaque terminal de radiocommunication mobile 102, 103, 104, 105 est relié au moyen d'une liaison de radiocommunication mobile bidirectionnelle respective 106, 107, 108, 109 à l'unité formant serveur de conférence 101 et peut donc recevoir des données d'autres terminaux de radiocommunication mobile dans le cadre de la conférence ou, lorsque le terminal de radiocommunication mobile respective s'est vu attribuer le droit de communiquer, envoyer des données aux autres terminaux de radiocommunication mobile. Selon cet exemple de réalisation de l'invention, des messages vocaux ou audio sont transmis entre les terminaux de radiocommunication mobile 102, 103, 104, 105, d'autres données multimédia pouvant être transmises dans un autre type de conférence, par exemple des données vidéo et/ou des données d'images et/ou des données de textes. Les données audio sont transmises en utilisant le 25 Real-Time Transport Protocol (RTP) comme protocole de transport à temps réel entre les terminaux de radiocommunication mobile 102, 103, 104, 105. Les flux de données c'est-à-dire les données audio dans cet exemple de réalisation de l'invention sont contrôlés en utilisant le Real-Time Transport Control Protocol (RTCP) comme protocole de commande de protocole de transport à temps réel. Selon cet exemple de réalisation de l'invention, un premier abonné Ti, c'est-à-dire l'utilisateur du premier terminal de radiocommunication mobile 102, déclenche un vote parmi les abonnés participant à la session de communication Push-to-Talk c'est-à-dire à une conférence Push-to-Talk en envoyant une question de vote (cf. diagramme de flux de messages 200 à la figure 2). La question de vote est insérée dans un message de vote 201 qui est produit par le premier utilisateur Tl en utilisant le premier terminal de radiocommunication mobile 102. Le message de vote 201 a le format représenté dans le tableau 1 cidessous et il est codé selon RTCP. Le message de vote 201 contient une question de vote sous forme de texte et des indications sur des réponses de vote possibles. En outre, il est indiqué dans le message de vote 201 dans quel intervalle de temps des réponses à la question de vote peuvent être acceptées dans le cadre du vote déclenché. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ IV=21P11 0 1 0 01 PT=APP=204 1 length 1 ±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±±+ I SSRC of voting initiator 1 ±±±±±±±±±±+±±±±±±±±±±±±±±±±±±±±±+ 1 name=PoCl 1 ±±±±±±±+±±±±±±±±±±±±±±±±±±±±±±±±+ I SDES CNAME item followed by SDES NAME item 1 ±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±+ I voting question length I voting question text= I I Quel est le plus haut sommet du monde ?;123456789;123458470; I I Type_ sélection;1;Mont Blanc;Mount Everest;Brocken I padding I ±±±±±±±±+ -±±±±±±±±±±±±±±±±±±±±±±±+ Tableau 1: format du message RTCP pour le déclenchement d'un vote Les champs du message RTCP représenté dans le tableau 1 signifient: É V=2: numéro de version RTP; P: indicateur pour Padding; É 10100: sous-type du message, 10100 signifie "Voting Question" ; la valeur indiquée n'est qu'un exemple et peut être choisie différente; É PT=APP=204: indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 10 bits) ; É SSRC: source de synchronisation de l'abonné PoC qui déclenche le vote; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoC1: nom de message défini par l'application (PoC1 = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui déclenche le vote; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3] ; É voting question length: longueur du champ "voting question text" en octets; le champ "voting question length" comprend 16 bits; É voting question text: texte pour spécifier le déclenchement du vote; 5 É Padding: zéros pour remplir les champs "voting question length" et "voting question text" jusqu'à des multiples entiers de 32 bits. Le champ "voting question text" du message de vote 201 10 a par exemple le contenu suivant: Quel est le plus haut sommet du monde ?;123456789; 123458470; Type_sélection; 1; Mont Blanc; Mount Everest; Brocken Le contenu signifie: É question du vote = Quel est le plus haut sommet du monde ? É intervalle de temps du vote = de 123456789 à 123458470 (les indications temporelles sont des indications temporelles absolues dans le format Time-Stamp du Network Time Protocol (NTP) tel qu'il est défini dans [7], sachant qu'il faut noter qu'il peut aussi s'agir dans une variante de réalisation d'une indication temporelle relative, par exemple une indication temporelle relative à partir de l'instant de l'émission du message de vote ou de la création du message de vote 201; É type des réponses à la question = type sélection (c'est-à-dire qu'il faut choisir entre plusieurs réponses possibles) ; É nombre des réponses à sélectionner = 1; É réponses possibles = Mont Blanc; Mount Everest; Brocken Le message de vote 201 est codé par le premier terminal de radiocommunication mobile 102 selon le format RTCP au moyen d'une unité RTCP prévue dans chacun des terminaux de radiocommunication mobile 102, 103, 104, 105. De plus, chaque terminal de radiocommunication mobile 102, 103, 104, 105 comporte une deuxième unité RTCP pour décoder un message reçu codé selon le format RTCP. Les deux unités peuvent être prévues intégrées dans une unité RTCP. Le message de vote 201 est transmis à l'unité formant serveur de conférence 101 qui produit suite à la réception du message de vote 201 d'autres messages de vote, à nouveau au format RTCP, au moyen d'une unité RTCP prévue dans l'unité formant serveur de conférence 101 et qui les transmet aux autres terminaux de radiocommunication mobile 103, 104, 105 participant à la conférence. Comme le montre la figure 2, l'unité formant serveur de conférence 101 produit donc un deuxième message de vote 202 et l'envoie au deuxième terminal de radiocommunication mobile 103 et donc au deuxième abonné T2. De plus, l'unité formant serveur de conférence 101 produit un troisième message de vote 203 et l'envoie au troisième terminal de radiocommunication mobile 104 et donc au troisième abonné T3. Enfin, l'unité formant serveur de conférence 101 produit un quatrième message de vote 204 et l'envoie au quatrième terminal de radiocommunication mobile 105 et donc au quatrième abonné T4. Dans cet exemple de réalisation de l'invention, les messages de vote produits 202, 203 et 204 sont identiques 25 au message de vote reçu 201. Après la réception du message de vote respectif 202, 203 ou 204, les unités RTCP décodent le message de vote respectivement reçu 202, 203, 204, elles déterminent à partir du message de vote décodé à chaque fois la question de vote et elles la présentent à l'abonné respectif T2, T3, T4 au moyen d'une unité de présentation, par exemple un écran (pour une information visuelle) ou un haut-parleur (pour des informations audio). Dans le cas le plus simple, la question de vote est affichée sous la forme d'un texte de question pour les abonnés T2, T3, T4 sur l'écran respectif du terminal de radiocommunication mobile 103, 104, 105. En outre, les réponses de vote possibles, qui sont également contenues dans les messages de vote 202, 203, 204 et qui sont déterminées par les unités RTCP des terminaux de radiocommunication mobile 103, 104, 105, sont présentées aux abonnés T2, T3, T4. Dans cet exemple de réalisation de l'invention, les trois réponses possibles (c'est-à-dire "Mont Blanc", "Mount Everest", "Brocken") sont présentées sous forme de texte avec la possibilité de sélectionner l'un des textes en utilisant des "boutons radio", c'est-àdire au moyen d'un élément de sélection, un seul élément pouvant être sélectionné à chaque fois parmi plusieurs éléments à sélectionner possibles. Dans des variantes de réalisation, il est prévu de sélectionner aussi plusieurs réponses possibles, dans ce cas en utilisant d'autres éléments de sélection qui sont présentés à l'abonné respectif T2, T3, T4 sur leur écran respectif de leur terminal de radiocommunication mobile respectif 103, 104, 105. Chaque terminal de radiocommunication mobile 103, 104, détermine à partir du message de vote respectif 202, 203, 204 le temps dans les limites duquel une réponse peut encore être sélectionnée et donc si une réponse peut même encore être sélectionnée. Si une réponse peut encore être sélectionnée c'est-à-dire si le délai de réponse n'est pas encore expiré, les terminaux de radiocommunication mobile 103, 104, 105 indiquent ceci en option à l'abonné respectif T2, T3, T4 sur l'écran, par exemple par une icône particulière, en faisant ressortir une certaine zone d'affichage ou en faisant ressortir une certaine partie du texte qui est présenté à l'abonné respectif T2, T3, T4. Il est par exemple prévu qu'un terminal de radiocommunication mobile 103, 104, 105 indique à l'abonné T2, T3, T4, au moyen d'un texte clignotant dans le cadre de la présentation, qu'il peut (encore) répondre. Pendant la phase de réponse c'est-à-dire tant que le délai de réponse, tel qu'il est présenté par exemple dans le message de vote ci-dessus dans le tableau 1, n'est pas encore expiré, il est prévu en option d'indiquer en continu à l'abonné T2, T3, T4 le temps encore restant pour la sélection de la réponse. Dans cet exemple de réalisation, on suppose que le deuxième abonné T2 sélectionne la deuxième des réponses possibles au moyen d'une entrée appropriée dans le deuxième terminal de radiocommunication mobile 103. Ensuite, le deuxième terminal de radiocommunication mobile 103 produit un premier message de réponse de vote 205 au format RTCP et envoie celui-ci à l'unité formant serveur de conférence 101. Un exemple de format pour le premier message de réponse de vote 205 est représenté dans le tableau 2 ci-dessous: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±+±±±±±±±±±±±±±±±+ V=21P11 0 1 0 11 PT=APP=204 I length ±±+ -±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ SSRC of responding participant ±±±±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±+ I name=PoCl I ±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±+ SDES CNAME item followed by SDES NAME item ±±±±+±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I voting answer length Type sélection;1;2 1 voting answer text= padding ±±±±±±±±+±±±±±±±±±±±±±±±±±±±±±±±+ Tableau 2: format du message RTCP pour répondre à une 30 question de vote Les champs du message RTCP représenté dans le tableau 2 signifient: É V=2: numéro de version RTP; É P: indicateur pour Padding; É 10101: sous-type du message, 10101 signifie "Voting_ Answer" ; la valeur indiquée n'est qu'un exemple et peut être choisie différente; É PT=APP=204: 5 indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 bits) ; É SSRC: source de synchronisation de l'abonné PoC qui répond; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoCl: nom de message défini par l'application (PoCl = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui répond; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3] ; É voting answer length: longueur du champ "voting answer text" en octets; le champ "voting answer length" comprend 16 bits; É voting answer text: texte pour spécifier la réponse au vote; É Padding: zéros pour remplir les champs "voting answer length" et "voting answer text" jusqu'à des multiples entiers de 32 bits. Dans cet exemple de réalisation et sans restreindre pour autant la généralité de l'invention, on suppose en plus que, peu de temps après, le deuxième abonné change d'avis pour la sélection de la réponse, qu'il revoit sa réponse en choisissant la troisième réponse possible et qu'il sélectionne la réponse "Brocken". L'option de la correction d'une réponse, en d'autres termes une nouvelle sélection d'une autre réponse de vote et la transmission correspondante de cette information à l'unité formant serveur de conférence 101, est possible tant que le délai de réponse n'est pas encore expiré. L'information qui identifie la question de vote ou la réponse de vote peut être un renvoi à une question de vote ou à une réponse de vote mémorisée dans une autre unité formant serveur, un adressage sans équivoque de la question ou de la réponse étant par exemple prévu dans ce cas, par exemple en utilisant un Unique Resource Identifier (URI), ou selon une variante la question de vote ou la réponse de vote elle-même est contenue dans le message de vote respectif ou dans le message de réponse de vote respectif. Selon une variante, il est prévu dans le message de réponse de vote d'utiliser simplement un unique identificateur, qui est déjà connu en raison d'une association prédéterminée dans l'unité formant serveur de conférence, pour identifier la réponse de vote respective qui a été sélectionnée par l'abonné. Après la sélection de la nouvelle réponse par le deuxième abonné T2, le deuxième terminal de radiocommunication mobile 102 produit un deuxième message de réponse de vote 206 et le transmet également à l'unité formant serveur de conférence 101. Le champ "Voting Answer Text" du premier message de réponse de vote 205 comporte par exemple le contenu suivant: type_sélection; 1; 2 Le contenu signifie: É type des réponses = type_sélection (c'est-à-dire qu'une sélection a été effectué entre plusieurs réponses possibles) ; É nombre des réponses sélectionnées = 1; É numéro des réponses sélectionnées = 2 (le numéro se rapporte à l'ordre des réponses possibles indiqué dans la question de vote c'est-à-dire dans le message de vote (c'est-à-dire des réponses de vote dans le message de vote respectif 201, 202, 203, 204), la réponse de vote "Mount Everest" ayant été choisie dans cet exemple de réalisation de l'invention). On suppose aussi dans cet exemple de réalisation que le troisième abonné T3 sélectionne d'abord la première réponse de vote possible (c'est-à-dire la réponse de vote "Mont-Blanc"). Suite à la sélection effectuée par le troisième abonné T3, le troisième terminal de radiocommunication mobile 104 produit un troisième message de réponse de vote 207 selon RTCP et transmet ce paquet de données RTCP à l'unité formant serveur de conférence 101. Dans cet exemple de réalisation, le troisième utilisateur T3 n'est pas sûr non plus et retire sa réponse, c'est-à-dire sa sélection précédemment effectuée, en déclenchant un message de retrait de réponse qui est produit par le troisième terminal de radiocommunication mobile 104 comme message de retrait de réponse de vote 208 et qui est transmis à l'unité formant serveur de conférence 101. Le message de retrait de réponse de vote 208 est également codé selon RTCP et transmis à l'unité formant serveur de conférence 101. Un exemple de structure du format du message de retrait de réponse de vote 208 est présenté dans le tableau 3 ci-dessous. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ IV=21P11 0 1 1 11 PT=APP=204 I length 1 ±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±±+ I SSRC of responding participant 1 ±±±±±±±+±±±±±±±±±±±±±±±±±±±±±±±±+ 1 name=PoCl I ±±±±+±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I SDES CNAME item followed by SDES NAME item 1 ±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±+ Tableau 3: format du message RTCP pour retirer une réponse de vote Les champs du message RTCP représenté dans le tableau 3 signifient: É V=2: numéro de version RTP; É P: indicateur pour Padding; É 10110: sous-type du message, 10110 signifie "Voting_ Answer_ Delete" ; la valeur indiquée n'est qu'un exemple et peut être choisie différente; É PT=APP=204: indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 bits) ; É SSRC: source de synchronisation de l'abonné PoC qui retire sa réponse; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoC1: nom de message défini par l'application (PoC1 = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui retire sa réponse; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné 15 typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3]. Dans l'exemple de réalisation, on suppose en plus que le troisième abonné T3 n'envoie pas d'autre message de réponse de vote. On suppose encore que le quatrième abonné T4 n'est pas sûr et qu'il ne sélectionne sa réponse qu'après la période de réponse prévue et ne déclenche qu'alors un quatrième message de réponse de vote 209 correspondant qui est produit par le quatrième terminal de radiocommunication mobile 105 et transmis à l'unité formant serveur de conférence 101. La réponse c'est-à-dire les messages de réponse de vote 205, 206, 207, 208, 209 sont collectés par l'unité formant serveur de conférence 101 pendant le temps de réponse prévu. Lorsque tous les messages de réponse sont arrivés à l'unité formant serveur de conférence 101 ou lorsque le délai de réponse est écoulé, l'unité formant serveur de conférence 101 réunit les réponses arrivées pendant la période de réponse pour former un message de vote, aussi appelé ci-dessous message récapitulatif de vote 210, elle code celui-ci et elle le transmet selon RTCP au terminal de radiocommunication mobile déclencheur du vote, à savoir le premier terminal de radiocommunication mobile 102 dans cette forme de réalisation de l'invention. Un exemple du format du message récapitulatif de vote 210 est présenté à titre d'exemple dans le tableau 4 ci-dessous. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ IV=21P11 0 1 0 11 PT=APP=204 I length ±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±+ SSRC of PTT server 1 ±±±±±±±±±±±±±±±+±±±±±±±±±±±±±±±±+ name=PoCl I ±±±±±±±±±±±±±+±±±±±±±±±±±±±±±±±±+ I SDES CNAME item followed by SDES NAME item ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±++ 1 voting answer length 1 voting answer text= Type_sélection;1;2 I padding I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±++ ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ SDES CNAME item followed by SDES NAME item ±±±±±±±±±±±±±±±±±+±±±±±±±±±±±±±±+ 1 voting answer length 1 voting answer text= Type_sélection;1;2 I padding I ±±±±±±±±±±±±±±±±±±+ -±±±±±±±±±±±±±+ Tableau 4: format du message RTCP pour réunir plusieurs réponses de vote Les champs du message RTCP représenté dans le tableau 4 signifient: É V=2: numéro de version RTP; É P: indicateur pour Padding; É 10101: sous-type du message, 10101 signifie "Voting Answer" ; la valeur indiquée n'est qu'un exemple et peut être 35 choisie différente; É PT=APP=204: indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 bits) ; É SSRC: source de synchronisation du serveur PTT qui envoie le message récapitulatif; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoC1: nom de message défini par l'application (PoCl = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui a répondu; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3] ; É voting answer length: longueur du champ "voting answer text" en octets; le champ "voting answer length" comprend 16 bits; É voting answer text: texte pour spécifier la réponse au vote; É Padding: zéros pour remplir les champs "voting answer length" et "voting answer text" jusqu'à des multiples entiers de 32 bits. Pour chaque réponse d'abonné sont transmis: un champ "SDES item", un champ "voting answer length", un champ 5 "voting answer text" et éventuellement un champ de remplissage dit padding. Les messages de réponse de vote qui sont arrivés à l'unité formant serveur de conférence 101 en dehors de la période de réponse prévue, par exemple le quatrième message de réponse de vote 209 du quatrième terminal de radiocommunication mobile 105, ne sont pas pris en compte dans le message récapitulatif de vote 210. L'unité formant serveur de conférence 101 envoie le message récapitulatif de vote 210 selon RTCP au premier terminal de radiocommunication mobile 102 et donc au premier abonné Ti car celui-ci a déclenché le vote. Le premier terminal de radiocommunication mobile 102 décode le message récapitulatif de vote reçu, détermine à partir de celui-ci la réunion des réponses, évalue automatiquement à la machine les réponses reçues et envoie le résultat par exemple comme messages SMS, en utilisant le Short Message Service (SMS), aux abonnés T2, T3, T4 qui ont participé au vote (non représenté à la figure 2). Il faut noter ici que des messages de vote peuvent aussi utiliser d'autres types de réponses que le "type_ sélection" indiqué dans l'exemple ci-dessus. On peut prévoir comme types de réponse possibles: É ensemble de textes ("type sélection"), É nombre entier de... à ..., É nombre réel de... à ..., É texte quelconque, É etc. Un message de vote a généralement le format préféré représenté dans le tableau 1 ci-dessus. Dans cet exemple, le champ "voting question text" contient les détails de la question sous forme de texte. La syntaxe générale du champ "voting question text" est décrite ci-dessous conformément à la Backus Naur Form (BNF) définie dans [8]. Le signe "=" définit des éléments; "[", "]" signifient des éléments optionnels; "*" définit des répétitions; "/" sépare des variantes d'éléments. question_vote = texte_question ";" réponses ["É" ' temps_réponse] texte_question = texte texte = *ALPHANUM réponses = type réponse ";" nombre_ réponses ["/É" paramètre] type_réponse = "type_ sélection" / "type_nb_entier" / "type_nb_réel" / "type_texte" nombre_ réponses = nb_entier_pos paramètre = (texte * (";" texte)) / limites limites = (nb entier nb entier) / (nb réel nb réel) temps_réponse = temps_début ";" temps_fin temps_début = nb_entier_pos temps_fin = nb_entier_pos nb entier pos = 1*NUM nb entier = ["+" / "-ni 1*NUM nb réel = ["+" / "-"] 1*NUM [". " 1*NUM] "ALPHANUM" correspond à un caractère alphanumérique et 25 NUM à un chiffre. Dans une variante de réalisation de l'invention, l'indication du temps de réponse n'est pas prévue. Dans ce cas, on suppose comme période de réponse une durée illimitée à partir de l'instant actuel ou la durée de la session de communication Push-to-Talk c'est-à-dire la durée de la conférence. C'est une solution intéressante notamment lorsque l'évaluation demande les réponses de tous les abonnés ou lorsque l'instant d'évaluation n'est pas encore fixé au moment de la question. Lorsqu'une période inconsistante est indiquée comme période de réponse c'est-à-dire par exemple lorsque l'instant de début est postérieur à l'instant de fin (instant de début >_ instant de fin), on suppose également comme période de réponse une durée illimitée à partir de l'instant actuel ou la durée de la session de communication Push-to-Talk. Selon les types de réponse possibles dans un message de question de vote, on peut aussi utiliser différents types de réponse dans un message de réponse de vote. Le tableau 2 ci-dessus montre le format général d'un message de réponse de vote selon ces exemples de réalisation de l'invention. La syntaxe générale du champ "voting answer" est donnée par la Backus Naur Form ci- dessous: réponse = type réponse ";" nb réponse ";" valeurs type réponse = "type sélection" / "type nb entier" / 15 "type nb réel" / "type texte" nombre réponses = nb entier pos valeurs = valeur * (";" valeur) valeur nb entier pos / nb entier / nb réel / texte nb entier pos = 1*NUM L'unité formant serveur de conférence (unité formant serveur PTT) 101 réunit plusieurs réponses des abonnés dans le message récapitulatif de vote selon le tableau 4. Le message récapitulatif de vote 210 est envoyé au déclencheur du vote c'est-à-dire à l'abonné qui a posé la question. Dans le message récapitulatif de vote 210, les réponses des abonnés sont énumérées dans l'ordre de leur arrivée à l'unité formant serveur de conférence 101. Ceci permet de prendre aussi en compte l'ordre des réponses pour l'évaluation du vote. C'est important par exemple pour la réalisation de jeux réactifs. Dans une variante de réalisation de l'invention, il peut être prévu d'associer une indication temporelle à la réponse respective et de la transmettre conjointement avec le message récapitulatif de vote, cette indication temporelle permettant de dire quand le message de réponse de vote respectif est arrivé à l'unité formant serveur de conférence 101 ou à quel instant le message de réponse de vote a été envoyé par le terminal de radiocommunication mobile respectif. Des questions peuvent aussi être retirées par le déclencheur de vote. Pour ce faire, le terminal de radiocommunication mobile du déclencheur de vote produit le message représenté dans le tableau 5 ci-dessous et il l'envoie à l'unité formant serveur de conférence 101. L'unité formant serveur de conférence 101 distribue alors ce message aux abonnés c'est-àdire aux terminaux de radiocommunication mobile de ceux-ci. Le retrait d'un vote met fin au vote. Le tableau 5 ci-dessous montre le format du message de retrait de vote selon un exemple de réalisation de l'invention: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±+±±±±±±±±±±±±±±±±±±+ IV=21P11 0 1 1 11 PT=APP=204 I length 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ 1 SSRC of voting initiator 1 ±±±±±±±±±±±±±±±±±±±±±+±±±±±±±±±±+ 1 name=PoC1 I ±±±±±±±±±±±±±±±±±±+±±±±±±±±±±±±±+ 1 SDES CNAME item followed by SDES NAME item 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ Tableau 5: format du message RTCP pour le retrait d'une question de vote Les champs du message RTCP représenté dans le tableau signifient: É V=2: numéro de version RTP; É P: indicateur pour Padding; É 10111: sous-type du message, 10111 signifie "Voting Question Delete" ; la valeur indiquée n'est qu'un exemple et peut être choisie différente; É PT=APP=204: indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 bits) ; É SSRC: source de synchronisation de l'abonné PoC qui retire sa question; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoC1: nom de message défini par l'application (PoCl = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui retire sa question; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3]. Le retrait d'un vote peut être intéressant par exemple lorsque suffisamment de réponses ont déjà été données par les abonnés au vote bien que la période de réponse ne soit pas encore expirée et que tous les abonnés n'aient pas encore répondu. Le nombre de réponses c'est-à-dire le nombre de messages de réponse de vote déjà arrivés peut être déterminé par le déclencheur de vote avec le message défini et décrit en détail cidessous en vue de la demande de résultats intermédiaires. Une question peut aussi être retirée pour d'autres raisons, par exemple parce que la question ne semble plus judicieuse ou intéressante. Une réponse déjà envoyée peut être retirée de deux manières différentes par l'abonné qui a envoyé la réponse. Primo, l'abonné c'est-à-dire son terminal de radiocommunication mobile peut envoyer un nouveau message de réponse de vote. L'ancienne réponse est ainsi annulée. C'est toujours le dernier message de réponse de vote qui est valide. Secundo, l'abonné c'est-à-dire son terminal de radiocommunication mobile peut envoyer le message représenté dans le tableau 3 à l'unité formant serveur de conférence 101. L'abonné c'est-à-dire son terminal de radiocommunication mobile retire ainsi sa réponse sans la remplacer par une autre. L'état de réponse de l'abonné correspond à l'état de réponse d'un abonné qui n'a donné aucune réponse. Le déclencheur de vote c'est-à-dire son terminal de radiocommunication mobile n'a pas à attendre jusqu'à ce que tous les abonnés aient répondu ou jusqu'à ce que la phase de réponse soit terminée pour obtenir un résultat de vote. Au contraire, le déclencheur de vote peut demander un résultat intermédiaire du vote pendant la phase de réponse en envoyant le message représenté dans le tableau 6 selon RTCP à l'unité formant serveur de conférence 101. Le tableau 6 ci-dessous montre le format d'un message de demande de résultat intermédiaire selon RTCP dans un exemple de réalisation de l'invention: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+±+ IV=21P11 1 0 0 01 PT=APP=204 I length 1 ±±±±±±±±±±±±±±+±±±±±±±±±±±±±±±±±+ 1 SSRC of requesting participant I ±+ -±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ 1 name=PoCl I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±± ±+ 1 SDES CNAME item followed by SDES NAME item 1 ±±±±±±±±±±±+ -±±±±±±±±±±±±±±±±±±±±+ Tableau 6: format du message RTCP pour la demande d'un résultat intermédiaire de vote É V=2: numéro de version RTP; É P: indicateur pour Padding; É 11000: sous-type du message, 11000 signifie "Voting Answers Request" ; la valeur indiquée n'est qu'un exemple et peut être choisie différente; É PT=APP=204: par indicateur pour message RTCP défini l'application; É length: longueur du message selon lechamp length en mots (32 bits) ; É SSRC: Les champs du message RTCP représenté dans le tableau 15 6 signifient: 25 source de synchronisation de l'abonné PoC qui demande les réponses données jusqu'ici; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoC1: nom de message défini par l'application (PoCl = PTT 34 over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui demande les réponses données jusqu'ici; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3]. À la réception du message de demande de résultat intermédiaire, l'unité formant serveur de conférence 101 vérifie d'abord si l'abonné demandeur est autorisé à demander des résultats ou des résultats intermédiaires du vote. Si l'abonné c'est-à-dire son terminal de radiocommunication mobile a cette autorisation par exemple, comme on le suppose ici, parce qu'il est le déclencheur du vote, l'unité formant serveur de conférence 101 répond avec un message récapitulatif de vote qui est conçu comme celui représenté ci-dessus dans le tableau 4 et qui contient toutes les réponses données avant l'instant du message de demande. La présentation des réponses possibles d'un vote est laissée au terminal de communication. En particulier, les réponses de type de sélection de l'exemple ci-dessus peuvent aussi être sélectionnées par d'autres moyens que les boutons radio, par exemple à l'aide de menus déroulants ou d'une entrée libre d'information textuelle. Selon une autre forme de réalisation de l'invention, il est prévu que les réponses d'un vote sont évaluées dans un autre terminal de communication et non dans un terminal de communication d'abonné. Selon une variante, elles peuvent aussi être évaluées dans un élément de réseau. À cet effet, l'élément de réseau peut faire office d'abonné participant à la session de communication Push-to-Talk et il déclenche le vote et l'envoi de la question de vote aux abonnés participant à la session de communication Push-to-Talk. Au lieu d'évaluer le vote, comme dans l'exemple ci-dessus, au moyen du déclencheur de vote c'est-à-dire de son terminal de radiocommunication mobile et de distribuer le résultat aux abonnés au moyen de SMS, le déclencheur de vote peut retransmettre directement aux abonnés le message récapitulatif de vote. Selon une variante, la question d'un vote peut aussi être présentée à un abonné sous la forme d'un flux de données audio. Ceci peut s'effectuer de différentes manières: 1. Primo, une question reçue sous forme de texte peut être transformée par le terminal de communication d'abonné en données audio qui sont ensuite fournies en sortie. 2. Secundo, un flux de données audio dont le contenu représente la question de vote peut être transmis dans le message de vote à la place d'une question de vote sous forme de texte. Dans ce cas, le format du message de vote est à compléter en conséquence de telle sorte que d'autres formats de données par exemple d'autres flux de données multimédia peuvent être transmis. De même, la question de vote peut aussi être présentée sous d'autres formes multimédia, par exemple sous forme d'images ou de films. 3. La question de vote peut aussi être envoyée sous forme de salves Pushto-Talk. C'est le message de question de vote décrit dans l'exemple qui est envoyé, le message de question de vote contenant en plus une indication précisant que la question de vote est envoyée (seulement ou aussi) sous la forme de la salve Talk actuelle. Selon une variante, il peut être prévu non seulement de réunir dans le message récapitulatif de vote de l'unité formant serveur de conférence Push-to-Talk les réponses données jusqu'ici mais aussi d'y indiquer quels abonnés de session de communication n'ont pas encore répondu. Le format, représenté dans le tableau 4 ci-dessus, d'un message récapitulatif de vote peut être utilisé pour la transmission de cette information. Pour les abonnés qui n'ont pas encore répondu, on a également des enregistrements, à savoir avec les valeurs: champ "Voting Answer Length" = 0 et champ "Voting Answer Text" = vide. Souvent, le déclencheur d'un vote ne va pas lui-même voter ou répondre. En principe, le déclencheur du vote peut toutefois aussi prendre part à son propre vote. L'application de gestion de vote du terminal de communication d'abonné du déclencheur de vote ne devrait alors fournir au déclencheur de vote pendant la période de vote aucune information sur les réponses de vote déjà données. Au lieu d'indiquer la durée d'un vote dans le message de question de vote avec des temps absolus, la durée peut aussi être indiquée par rapport au temps actuel. Selon une variante, des événements peuvent aussi être indiqués comme limite temporelle du vote, la fin du vote peut par exemple être définie par la fourniture de réponses d'au moins n abonnés. Un autre format que le NTP-Time Stamp Format tel qu'il est décrit dans [7] peut aussi être utilisé pour les indications temporelles. L'unité formant serveur de conférence 101 peut aussi transmettre dans le message récapitulatif de vote les instants des différentes réponses d'abonnés. Le format du message récapitulatif de vote peut alors être complété selon le tableau 7 ci-dessous: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±+±±±±±±±±±±±±±±+ IV=21P11 1 0 0 11 PT=APP=204 1 length ±±+±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I SSRC of responding participant ±±±±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±+ 1 name=PoC1 ±±±±±±±±±±±±±±±±±±±±±±±+ -±±±±±±±±+ I SDES CNAME item followed by SDES NAME item 1 ±±±+±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I voting answer time 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ 1 voting answer length 1 voting answer text= I I Type_sélection;1;2 1 padding ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ Tableau 7: format du message RTCP pour répondre à une question de vote avec indication temporelle 20 Les champs du message RTCP représenté dans le tableau 7 signifient: É V=2: numéro de version RTP; É P: indicateur pour Padding; É 11001: sous-type du message, 11001 signifie "Voting Answer" ; la valeur indiquée n'est qu'un exemple et peut être 30 choisie différente; É PT=APP=204: indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 bits) ; É SSRC: source de synchronisation de l'abonné PoC qui répond; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoC1: nom de message défini par l'application (PoC1 = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME du terminal d'abonné qui répond; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3] ; É voting answer time: instant de la réponse dans le NTP Time Stamp Format; É voting answer length: longueur du champ "voting answer text" en octets; le champ "voting answer length" comprend 16 bits; 30 É voting answer text: texte pour spécifier la réponse au vote; É Padding: zéros pour remplir les champs "voting answer length" et "voting answer text" jusqu'à des multiples entiers 35 de 32 bits. L'indication d'instants de réponse permet une évaluation plus précise des temps de réaction des abonnés, par exemple pour des jeux. À l'intérieur d'une session de communication Push-to-Talk, plusieurs votes peuvent être effectués simultanément. Pour pouvoir différencier les messages RTCP des différents votes, ils sont munis de champs supplémentaires qui identifient les votes. Le tableau 8 ci-dessous montre une extension correspondante du format des messages de vote: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±+±±±+ V=2IPIX X X X XI PT=APP=204 I length I 5 ±±±±±±±±±±±±+ -±±±±±±±±±±±±±±±±±±±+ SSRC 1 ±±±±±±±±±±±±+±±±±±±±±±±±±±±±±±±±+ name=PoC1 ±±±±±±±±±±±+±±±±±±±±±±±±±±±±±±±±+ I SDES CNAME item followed by SDES NAME item ±±±±±±±±±±±±±±±+ -±±±±±±±±±±±±±±±±+ I SSRC of voting initiator I ±±±±+±±±±±±±±±±±±±±±±±±±±±±±±±±±+ voting ID I ±±+±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ additional data I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ Tableau 8: extension des messages de vote avec un identificateur de vote Les champs du message RTCP représenté dans le tableau 25 8 signifient: É V=2: numéro de version RTP; É P: indicateur pour Padding; É XXXXX: soustype du message, valeur selon message de vote; É PT=APP=204: indicateur pour message RTCP défini par l'application; É length: longueur du message selon le champ length en mots (32 bits) ; É SSRC: source de synchronisation de l'émetteur (terminal d'abonné ou serveur PTT) ; la SSRC identifie sans équivoque l'émetteur de flux multimédia; elle est définie dans les paquets RTP appartenant au message RTCP; É Name=PoCl: nom de message défini par l'application (PoCl = PTT over Cellular Version 1) ; É SDES CNAME item followed by SDES NAME item: CNAME et NAME de l'émetteur (terminal d'abonné ou serveur PTT) ; CNAME et NAME sont ce qu'on appelle des SDES items qui sont définis dans des paquets RTCP SDES pour décrire un abonné RTP; CNAME est un nom unique de l'abonné qui est aussi valable en dehors de la session RTP spécifique (composé par exemple de user name et host IP address) ; NAME est un nom quelconque de l'abonné qui est donné typiquement par l'abonné lui-même; NAME n'a pas à identifier sans équivoque l'abonné ; comme dans le cas des paquets RTCP SDES, la liste des SDES items CNAME et NAME est terminée sans équivoque par un SDES item du type 00000000; la liste est ensuite complétée avec des zéros jusqu'à des multiples de 32 bits, comme décrit dans [3] ; É SSRC of voting initiator: SSRC de l'abonné qui a déclenché le vote; É Voting ID: un nombre pour l'identification sans équivoque du vote parmi les votes de l'abonné déclencheur; É Additional data: d'autres informations du message de vote; les informations dépendent du sous-type du message; elles correspondent aux informations supplémentaires qui sont indiquées dans les messages de vote définis ci-dessus (sans identificateur de vote). L'identification des votes se compose du SSRC du déclencheur de vote respectif et d'un numéro de vote supplémentaire. Lorsqu'un abonné utilise pour la deuxième fois le numéro d'un vote déjà en cours dans une question de vote, le premier des deux votes est terminé et le deuxième vote est déclenché. Selon une variante, la réponse à une question de sélection peut aussi être donnée sous forme de texte. Le champ "Voting Answer Text" correspondant à l'exemple ci- dessus est alors: type texte;l;Mount Everest. Comme réponses possibles, on peut aussi définir d'autres types de réponses que les types de réponses indiqués ci-dessus, par exemple la réception d'un message vocal. Comme réponses possibles, on peut aussi utiliser d'autres média que le texte, par exemple des images ou des messages vocaux. Le champ "voting question text" et le champ "voting answer text" d'un message de question de vote RTCP ou d'une réponse de vote RTCP peuvent aussi avoir un format différent de ceux donnés dans les exemples cidessus. Dans des variantes de réalisation de l'invention, il est prévu non seulement une application dans un système de communication Push-to-Talk pour la transmission de données audio mais aussi une utilisation dans un système de communication Push-to-Talk pour la transmission d'autres données, notamment pour la transmission d'autres données multimédia. Selon une variante, le système de communication, par exemple le système de conférence, n'est pas conçu comme un système de communication Push-toTalk mais comme un autre système de conférence qui utilise le RTCP, plus généralement un protocole de commande de protocole de transport à temps réel, notamment comme un système de communication avec un système de conférence selon IETF, par exemple tel qu'il est décrit dans [1]. On peut aussi utiliser des votes au moyen de RTCP pour voter c'est-à-dire décider quel abonné est le prochain à recevoir le droit de parler (Floor Control). À cet effet, un abonné mécanique participe à la communication en tant que déclencheur de vote. Il déclenche le vote pour savoir quel abonné doit recevoir prochainement le droit de parler et il évalue les réponses données. L'abonné mécanique devrait être autorisé à donner le droit de parler c'est-à-dire que, en d'autres termes, il joue le rôle de ce qu'on appelle une "Floor Chair". L'abonné mécanique donne le droit de parler en fonction du résultat de l'évaluation. Un aspect de l'invention consiste, dans un système de communication qui utilise le Real-Time Control Protocol (RTCP), à envoyer des messages de vote sous forme de paquets de données RTCP spéciaux. Des systèmes de communication basés sur l'Internet Protocol (par exemple des systèmes de communication Pushto-Talk ou des systèmes de conférence basés sur l'Internet Protocol (IP)) utilisent la plupart du temps le RealTime Transport Protocol (RTP) pour transmettre des données multimédia. Les liaisons de communication RTP sont contrôlées à l'aide du RTCP. Selon un aspect de l'invention, les liaisons de communication RTCP sont utilisées pour la transmission de messages RTCP spéciaux pour des fonctionnalités de vote. Selon un autre aspect de l'invention, des messages RTCP spéciaux sont spécifiés pour la transmission de la question de vote, pour celle des réponses de vote et pour le retrait de questions et de réponses de vote. L'avantage de la spécification des messages de vote spéciaux est que le vote peut être évalué par une machine. Si les réponses pouvant être sélectionnées ne sont pas spécifiées, il peut être prévu que l'unité d'évaluation contienne une unité d'analyse syntaxique qui analyse automatiquement les réponses données en texte libre et qui détermine à partir de là le résultat de vote. Les messages de vote ont un format simple et sont basés sur du texte, ce qui a l'avantage que les messages 5 sont facilement lisibles et courts. L'unité centrale formant serveur de conférence du système de communication réunit les réponses de vote dans un message RTCP. L'unité formant serveur de conférence informe du résultat du vote le déclencheur du vote en envoyant un message récapitulatif de vote. L'avantage de cette solution est que l'unité formant serveur de conférence ne doit envoyer qu'un message pour informer du résultat du vote le déclencheur du vote. Comme les résultats de vote sont collectés et mémorisés centralement, des résultats (intermédiaires) de vote peuvent aussi être avantageusement demandés par un terminal de communication d'abonné demandeur. Les résultats de vote peuvent être évalués par un terminal de communication d'abonné ou par un élément dans le réseau de communication. L'avantage est que la spécification de l'architecture du système de communication de vote peut être flexible. Bien que l'invention ait été particulièrement montrée et décrite en se référant à un mode de réalisation préféré de celle-ci, il sera compris aisément par les personnes expérimentées dans cette technique que des modifications dans la forme et dans des détails peuvent être effectuées sans sortir de l'esprit ni du domaine de l'invention. Suivant un mode de réalisation préféré de l'invention, une unité d'évaluation de vote de conférence, caractérisée par le fait qu'elle comprend: une unité de protocole de commande de protocole de transport, conçue pour décoder au moins un message de réponse de vote qui est codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, É une unité de détermination pour déterminer à partir du message de réponse de vote décodé au moins une information identifiant une réponse à au moins une question de vote, É une unité d'évaluation de vote qui est conçue pour déterminer un résultat de vote en utilisant la au moins une information identifiant la réponse à au moins une question de vote. Le présent document cite les publications suivantes: [1] J. Rosenberg, IETF Internet-Draft, A Framework for Conferencing with the Session Initiation Protocol, draft-ietf-sipping-conferencing-framework-00.txt, mai 2003; [2] Open Mobile Alliance: "Push-to-talk over Cellular (PoC) Architecture", Candidate Version 1.0, avril 2005; [3] H. Schulzrinne et al., IETF Request For Comments RFC 3550, RTP A Transport Protocol for Real-Time Applications, juillet 2003; [4] J. Vogel, RTP/I Payload Type Definition for Feedback Tools, Universitat Mannheim, 2001; [5] R. Parviainen, Multicast Interactive Radio, Centre for Distance-spanning Technology, Department of Computer Science, Lulea University of Technology, 971 87 Lulea, Sweden, sur Internet à l'adresse: http://www. cdt.luth.se/-rolle/docs/pajava/mir.html [6] Wen-Tsuen Chen et al., On the Design of a High-Speed Network Environment for Multimedia Applications, Proc. Natl. Sci. Counc. ROC (A), Vol. 23, n 1, pages 111 à 124, 1999, sur Internet à l'adresse: http://nr.stic.gov. tw/ejournal/ProceedingA/v23n1/lll- 124.pdf [7] D. Mills, IETF Request For Comments RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis, mars 1992; [8] D. Crocker et al., IETF Request For Comments RFC 2234, Augmented BNF for Syntax Specifications: ABNF, novembre 1997; [9] US 2004/0033478 Al; [10] US 2004/0249884 Al. REVENDICATIONS 1. Procédé pour la création assistée par ordinateur d'un message de vote dans une conférence entre plusieurs 5 terminaux de communication (102, 103, 104, 105), caractérisé par le fait que on code le message de vote (201, 202, 203, 204) selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, une information identifiant au moins une question de vote et/ou au moins une réponse de vote étant adjointe au message de vote (201, 202, 203, 204). 2. Procédé pour la détermination assistée par 15 ordinateur d'au moins un résultat d'au moins un vote dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105), caractérisé par le fait que É on décode au moins un message de réponse de vote reçu (205, 206, 207, 208, 209) qui est codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, le message de réponse de vote contenant au moins une réponse à au moins une question du vote, É on détermine la au moins une réponse à partir du message de réponse de vote (205, 206, 207, 208, 209) décodé, É on détermine le au moins un résultat de vote en utilisant la au moins une réponse. 3. Procédé selon la revendication 1 ou 2, caractérisé par le fait qu'on utilise comme protocole de commande de protocole de transport un protocole de commande de protocole de transport au moyen duquel un protocole de transport à temps réel est commandé. 25 4. Procédé selon la revendication 3, caractérisé par le fait qu'on utilise comme protocole de commande de protocole de transport à temps réel le Real-Time Transport Control Protocol. 5. Procédé selon la revendication 3 ou 4, caractérisé par le fait qu'on utilise comme protocole de transport à temps réel le Real-Time Transport Protocol. 6. Procédé selon l'une des revendications 1 à 5, caractérisé par le fait qu'on réalise le au moins un vote dans une conférence en semi-duplex. 7. Procédé selon la revendication 6, caractérisé par 15 le fait qu'on réalise le au moins un vote dans une conférence Push-to-Talk. 8. Procédé selon la revendication 7, caractérisé par le fait qu'on réalise le au moins un vote dans une 20 conférence Push-to-Talk over Cellular. 9. Procédé selon l'une des revendications 1 à 6, caractérisé par le fait qu'on réalise le au moins un vote dans une conférence basée sur l'Internet Protocol. 10. Procédé selon l'une des revendications 2 à 9, caractérisé par le fait que É le au moins un message de réponse de vote (205, 206, 207, 208, 209) est reçu par une unité formant serveur de conférence (101), et/ou É le au moins un résultat de vote est déterminé par une unité formant serveur de conférence. 11. Procédé selon l'une des revendications 2 à 10, caractérisé par le fait que le au moins un résultat de vote déterminé est transmis à au moins un terminal de communication (102, 103, 104, 105) participant à la conférence. 12. Procédé selon la revendication 11, caractérisé par le fait que le au moins un résultat de vote déterminé est transmis au terminal de communication (102) qui a déclenché le vote. 13. Procédé selon l'une des revendications 2 à 9, caractérisé par le fait que É le au moins un message de réponse de vote (205, 206, 207, 208, 209) est reçu par une unité formant serveur de conférence (101), et É le message de réponse de vote (205, 206, 207, 208, 209) et/ou au moins une information de réponse de vote contenue dans le message de réponse de vote (205, 206, 207, 208, 209) est transmis à au moins un terminal de communication (102, 103, 104, 105) participant à la conférence. 14. Procédé selon la revendication 13, caractérisé par le fait que le message de réponse de vote déterminé et/ou au moins une information de réponse de vote contenue dans le message de réponse de vote (205, 206, 207, 208, 209) est transmis au terminal de communication (102) qui a déclenché le vote. 15. Procédé pour le traitement assisté par ordinateur d'un message de vote dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105), caractérisé par le fait que É on reçoit un message de vote (201, 202, 203, 204) codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, É on détermine à partir du message de vote (201, 202, 203, 204) une information qui identifie au moins une question de vote et/ou au moins une réponse de vote et qui est contenue dans le message de vote (201, 202, 203, 204), É la au moins une question de vote et/ou la au moins une réponse de vote est présentée à un utilisateur d'un terminal de communication (102, 103, 104, 105) participant au vote, É un utilisateur entre au moins une réponse à la au moins une question de vote, É on code un message de réponse de vote (205, 206, 207, 208, 209) selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, une information qui identifie la au moins une réponse à la au moins une question de vote étant adjointe au message de réponse de vote (205, 206, 207, 208, 209). 16. Procédé selon la revendication 15, caractérisé par le fait qu'on utilise comme protocole de commande de protocole de transport un protocole de commande de protocole de transport à temps réel au moyen duquel un protocole de transport à temps réel est commandé. 17. Procédé selon la revendication 15 ou 16, caractérisé par le fait qu'on envoie le message de réponse de vote (205, 206, 207, 208, 209) à une unité formant serveur de conférence (101). 18. Procédé selon la revendication 16 ou 17, 30 caractérisé par le fait qu'on utilise comme protocole de commande de protocole de transport à temps réel le Real- Time Transport Control Protocol. 19. Procédé selon l'une des revendications 16 à 18, 35 caractérisé par le fait qu'on utilise comme protocole de transport à temps réel le Real-Time Transport Protocol. 20. Procédé selon l'une des revendications 15 à 19, caractérisé par le fait qu'on réalise le au moins un vote dans une conférence en semi-duplex. 21. Procédé selon la revendication 20, caractérisé par le fait qu'on réalise le au moins un vote dans une conférence Push-to-Talk. 22. Procédé selon la revendication 21, caractérisé 10 par le fait qu'on réalise le au moins un vote dans une conférence Push-to-Talk over Cellular. 23. Procédé selon l'une des revendications 15 à 20, caractérisé par le fait qu'on réalise le au moins un vote 15 dans une conférence basée sur l'Internet Protocol. 24. Unité de protocole de commande de protocole de transport, caractérisée par le fait qu'elle est conçue pour créer un message de vote (201, 202, 203, 204) dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105), le message de vote (201, 202, 203, 204) étant codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé et une information qui identifie au moins une question de vote et/ou au moins une réponse de vote étant adjointe au message de vote (201, 202, 203, 204). 25. Unité de protocole de commande de protocole de transport selon la revendication 24, caractérisée par le fait qu'elle est conçue comme unité de protocole de commande de protocole de transport à temps réel pour créer un message de vote dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105), le message de vote (201, 202, 203, 204) étant codé selon un protocole de commande de protocole de transport à temps réel au moyen duquel un protocole de transport à temps réel est commandé. 26. Unité de protocole de commande de protocole de transport selon la revendication 25, caractérisée par le fait qu'elle est conçue selon le Real-Time Transport Control Protocol. 27. Unité d'évaluation de vote de conférence, caractérisée par le fait qu'elle comprend: É une unité de protocole de commande de protocole de transport, conçue pour décoder au moins un message de réponse de vote (205, 206, 207, 208, 209) qui est codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, É une unité de détermination pour déterminer à partir du message de réponse de vote (205, 206, 207, 208, 209) décodé au moins une information identifiant une réponse à au moins une question de vote, É une unité d'évaluation de vote qui est conçue pour déterminer un résultat de vote en utilisant la au moins une information identifiant la réponse à au moins une question de vote. 28. Unité d'évaluation de vote de conférence selon la revendication 27, caractérisée par le fait que l'unité de protocole de commande de protocole de transport est conçue comme une unité de protocole de commande de protocole de transport à temps réel. 29. Unité d'évaluation de vote de conférence selon la revendication 28, caractérisée par le fait que l'unité de protocole de commande de protocole de transport à temps réel est conçue selon le Real-Time Transport Control Protocol. 30. Unité formant serveur de conférence caractérisée par le fait qu'elle comporte une unité d'évaluation de vote 15 20 de conférence selon l'une des revendications 27 à 29. 31. Unité de protocole de commande de protocole de transport, caractérisée par le fait qu'elle est conçue pour créer un message de réponse de vote (205, 206, 207, 208, 209) dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105), le message de réponse de vote (205, 206, 207, 208, 209) étant codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé et une information qui identifie au moins une réponse de vote à au moins une question de vote étant adjointe au message de réponse de vote (205, 206, 207, 208, 209). 32. Unité de protocole de commande de protocole de transport selon la revendication 31, caractérisée par le fait qu'elle est conçue comme unité de protocole de commande de protocole de transport à temps réel, pour créer un message de réponse de vote (205, 206, 207, 208, 209) dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105) , le message de réponse de vote (205, 206, 207, 208, 209) étant codé selon un protocole de commande de protocole de transport à temps réel au moyen duquel un protocole de transport à temps réel est commandé. 33. Unité de protocole de commande de protocole de transport selon la revendication 31 ou 32, caractérisée par le fait qu'elle est conçue selon le Real-Time Tranport Control Protocol. 34. Terminal de communication (102, 103, 104, 105), caractérisé par le fait qu'il comprend: É une unité de conférence qui est conçue pour mettre en place une conférence avec au moins un autre terminal de communication (102, 103, 104, 105), É une première unité de protocole de commande de protocole de transport, conçue pour décoder au moins un message de vote (201, 202, 203, 204) qui est codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé, É une unité de détermination pour déterminer à partir du message de vote (201, 202, 203, 204) décodé au moins une information identifiant une question de vote et/ou au moins une information identifiant une réponse de vote, É une unité de présentation pour présenter à un utilisateur l'information déterminée ou la au moins une question de vote déterminée à partir de là et/ou la au moins une réponse de vote déterminée à partir de là, É une unité d'entrée pour entrer au moins une réponse à la au moins une question de vote, É une deuxième unité de protocole de commande de protocole de transport, qui est conçue pour créer un message de réponse de vote (205, 206, 207, 208, 209) dans une conférence entre plusieurs terminaux de communication (102, 103, 104, 105), le message de réponse de vote (205, 206, 207, 208, 209) étant codé selon un protocole de commande de protocole de transport au moyen duquel un protocole de transport est commandé et une information identifiant la au moins une réponse à la au moins une question de vote étant adjointe au message de réponse de vote (205, 206, 207, 208, 209).