Titre de l'invention : Gestion d’une audioconférence audio et/ou vidéo Domaine Technique

L'invention se rapporte au domaine de l’audioconférence et de la visioconférence, et concerne plus particulièrement la capacité d’un utilisateur à être entendu ou non par un autre utilisateur lors d’audioconférence ou visioconférence.

Technique antérieure

Les systèmes de visioconférence ou audioconférence ont connu un essor important ces dernières années et cette tendance s’est encore amplifiée dans le contexte sanitaire actuel. Une audioconférence (ou conférence audio) permet à des participants de communiquer par audio de façon instantanée tandis qu’une visioconférence (ou conférence vidéo) permet non seulement de communiquer par audio mais aussi par image de façon instantanée. Autrement dit, lors d’une visioconférence, des flux vidéo sont échangés entre les terminaux des participants afin que chacun puisse voir et entendre ses interlocuteurs. Lors d’une conférence audio, des flux audio sont échangés sans qu’il n’y ait de flux image.

Les conférences de communication, de type audioconférence et vidéoconférence, sont des solutions permettant à plusieurs participants de communiquer ensemble de façon efficace au moyen de terminaux clients. Cependant, ces outils sont parfois délicats à utiliser pour les non-initiés et des problèmes techniques empêchent régulièrement les participants de profiter d’une bonne expérience utilisateur. En particulier, un problème récurrent se pose en ce qu’il n’est pas toujours possible pour un participant de savoir s’il est, ou va être, bien entendu par d’autres participants au cours d’une conférence audio ou vidéo. Cette incertitude pousse souvent les participants à demander auprès de leurs interlocuteurs s’ils sont bien entendu de tous, ce qui peut apporter de la confusion, une gêne pour les participants (perte de temps, etc.), et cette méthode n’apporte pas l’assurance que tous les participants entendent effectivement bien le locuteur en question, en particulier quand un nombre important d’utilisateurs participe à la conférence.

Ces problèmes de bonne réception audio posent un défi dans la mesure où de nombreux problèmes techniques sont susceptibles d’empêcher un participant d’être bien entendu par ses interlocuteurs (problèmes de configuration, problèmes matériels, mauvaises utilisations des outils...).

Les contraintes et limites techniques évoquées ci-dessus peuvent par conséquent dégrader l’expérience utilisateur et limiter l’intérêt de ces outils de communication pour certains utilisateurs ou dans certains contextes.

Exposé de l’invention

A cet effet, la présente invention concerne un premier procédé mis en œuvre par un premier terminal client lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre le premier terminal client et au moins un deuxième terminal client au cours d’une conférence audio et/ou vidéo.

Selon la présente demande, le premier procédé comprend : - envoi au serveur de conférence audio et/ou vidéo , d’un flux de données audio marquées par intégration d’un code attribué audit premier terminal dans un premier flux de données audio;

- réception, de données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code attribué audit premier terminal dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et

- déclenchement d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : o restitution, par une interface utilisateur du premier terminal client, d’informations fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.

Selon au moins un mode de réalisation, le premier procédé comprend une réception, depuis un serveur de médiation (SV2) du code attribué au premier terminal client.

Selon au moins un mode de réalisation, ledit code attribué audit premier terminal client est reçu en réponse à une requête audit serveur de médiation comprenant un identifiant du premier terminal client.

Selon au moins un mode de réalisation, le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone couplé au premier terminal client.

Selon au moins un mode de réalisation, les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité.

Selon au moins un mode de réalisation, le premier procédé comprend le premier flux de données audio est généré par émulation d’un bruit aléatoire.

Selon au moins un mode de réalisation, le premier procédé comprend, avant l’envoi du flux de données audio marquées au serveur conférence audio et/ou vidéo : activation du premier microphone du premier terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut-parleur couplé audit au moins un premier terminal client ; génération d’un signal acoustique de test au moyen du premier haut-parleur ; acquisition acoustique, au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination, à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations restituées par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client. Selon au moins un mode de réalisation, le premier procédé comprend : a) obtention d’un flux de données audio marquées par intégration d’un code de marquage numérique dans un premier flux de données audio par tatouage numérique; b) envoi du flux de données audio marquées au serveur de conférence audio et/ou vidéo ; c) réception, en provenance d’un serveur de médiation, de données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et d) déclenchement d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : restitution, par une interface utilisateur du premier terminal client, d’informations, fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.

Comme déjà indiqué, il n’est pas toujours aisé pour un utilisateur participant à une conférence audio et/ou vidéo de savoir s’il est, ou s’il va être, bien entendu des autres participants lorsqu’il parle ou qu’il s’apprête à parler lors d’une conférence audio et/ vidéo. Divers problèmes matériels, logiciels ou autres sont susceptibles de faire obstacle à une bonne transmission d’un flux audio depuis le terminal client du locuteur considéré vers les terminaux clients d’autres participants. L’usage, dans certains modes de réalisation de l’invention, d‘une technique de marquage numérique (dit « watermarking ») peut aider à tester de façon fiable et robuste la capacité de terminaux clients à recevoir des flux de données audio en provenance d’un terminal client donné au cours d’une conférence audio et/ou vidéo. L’invention peut aider ainsi de limiter les risques qu’un utilisateur parle sans être entendu par un autre participant à la conférence audio et/ou vidéo.

Selon au moins un mode de réalisation, l’obtention a) comprend : e) envoi à un serveur de médiation d’une requête de code de marquage numérique, ladite requête comprenant un identifiant du premier terminal client; f) réception, en réponse à ladite requête, du code de marquage numérique attribué au premier terminal client.

Selon au moins un mode de réalisation, le premier procédé comprend : détermination, lors d’un établissement de la session de communication, d’un identifiant de la conférence audio et/ou vidéo ; et insertion dans la requête de code de marquage numérique de l’identifiant de la conférence audio avant envoi au serveur de médiation, de sorte à permettre audit serveur de médiation d’enregistrer le code de marquage numérique en association avec l’identifiant du premier terminal client et l’identifiant de la conférence audio et/ou vidéo.

L’usage d’un identifiant de la conférence audio et/ou vidéo peut permettre notamment au serveur de médiation de reconnaître une requête associée à la conférence audio et/ou vidéo en cours, et ainsi d’obtenir ou générer un code (comme un code de marquage numérique par exemple) unique pour le premier terminal client. Le serveur de médiation peut en particulier superviser un test de réception de flux audio pour une pluralité de conférence audio et/ou vidéo distinctes, y compris lorsque le premier terminal client T1 participe à plusieurs conférences simultanément ou successivement sur une période donnée.

Selon au moins un mode de réalisation, le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone couplé au premier terminal client. Il est ainsi possible de réaliser un test audio tout en transmettant des sons depuis le premier terminal client vers le deuxième terminal client lors de la conférence audio et/ou vidéo.

Selon un mode de réalisation particulier, les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité. Il est ainsi possible de réaliser un test audio alors que l’utilisateur du premier terminal client est silencieux (ne parle pas) pendant la conférence en cours.

Selon au moins un mode de réalisation, l’envoi de la requête de code de marquage numérique est déclenché sur détection, au moyen du premier microphone du premier terminal client, d’une période de silence d’une durée au moins égale à une première durée, au cours de laquelle un bruit de fond d’une intensité inférieure à ladite première valeur d’intensité est détecté. Il est ainsi possible de déclencher automatiquement un test audio lorsque l’utilisateur du premier terminal client est silencieux (ne parle pas) lors de la conférence en cours.

Selon au moins un mode de réalisation, l’envoi de la requête de code de marquage numérique est déclenché sur détection que le premier microphone est désactivé pendant au moins une deuxième durée.

Selon au moins un mode de réalisation, le premier flux de données audio est généré par émulation d’un bruit aléatoire. Il est ainsi possible, au moins dans certains modes de réalisation, de réaliser un test audio de façon fiable et robuste, indépendamment de tout flux de données audio susceptibles d’être émis par le premier terminal client lors la conférence en cours.

Selon au moins un mode de réalisation, aux moins certaines des étapes a)-d) du procédé mis en œuvre sur le premier terminal client peuvent être réitérées pendant ladite session de communication, de façon à vérifier plusieurs fois (par exemple périodiquement) si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio émises par le premier terminal client. Il est ainsi possible de vérifier sur une période donnée, de façon répétée (périodiquement ou régulièrement) ou continue, si le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client lors de la conférence en cours.

Selon au moins un mode de réalisation, si les données de capacité audio reçues représentent que ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues en provenance du serveur d’audioconférence, alors les informations restituées par l’interface utilisateur indiquent que ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio émises par le premier terminal client. L’utilisateur du premier terminal client peut ainsi s’assurer qu’il est ou sera bien entendu lors de la conférence en cours.

Selon au moins un mode de réalisation, le premier terminal client envoie au serveur de médiation une notification informant de l’envoi du flux de données marquées au serveur de conférence audio et/ou vidéo. Il est ainsi possible pour le serveur de médiation d’être informé lorsqu’un test audio est initié par le premier terminal client. A partir de cette notification, le serveur de médiation peut en particulier déterminer s’il reçoit une notification depuis le deuxième terminal client, indiquant que ce dernier a détecté le code de marquage numérique.

Selon au moins un mode de réalisation, ladite au moins une action de gestion comprend : si les données de capacité audio reçues représentent que ledit au moins un deuxième terminal client n’a pas détecté le code de marquage numérique dans le flux de données audio mixées reçu en provenance du serveur d’audioconférence, changement d’une configuration audio du premier terminal client.

Il est ainsi possible par exemple pour le premier terminal client d’adapter sa configuration lorsqu’un problème de réception de flux audio est détecté, et donc améliorer les chances que l’utilisateur du premier terminal client soit entendu par le deuxième terminal client lors de la conférence.

Selon un mode de réalisation particulier, le premier procédé comprend, successivement pour chacune parmi une pluralité de configurations audio, tant qu’une première condition audio n’est pas satisfaite : configuration du premier terminal client selon ladite configuration audio; et réitération d’au moins certaines des étapes a)-d).

Selon au moins un mode de réalisation, le premier procédé comprend, avant l’envoi du flux de données audio marquées au serveur conférence audio et/ou vidéo : activation du premier microphone du premier terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut- parleur couplé audit au moins un premier terminal client ; génération d’un signal acoustique de test au moyen du premier haut-parleur ; acquisition acoustique, au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination, à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations restituées en d) par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client.

Il est ainsi possible de tester la chaîne de traitement acoustique au niveau du premier terminal client. Selon au moins un mode de réalisation, le premier procédé comprend en outre : réception, en provenance du serveur de médiation, de données de capacité acoustique représentatives de capacités acoustiques d’un deuxième haut-parleur couplé audit au moins un deuxième terminal client à produire une sortie acoustique ; les informations restituées en d) par l’interface utilisateur étant en outre représentatives des capacités acoustiques du deuxième haut-parleur du deuxième terminal client.

L’utilisateur du premier terminal client peut ainsi être informé de la capacité de la chaîne de traitement acoustique du premier terminal client à produire une émission (sortie) acoustique.

L’invention concerne également un deuxième procédé mis en œuvre par un deuxième terminal client lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre un premier terminal client et le deuxième terminal client au cours d’une conférence audio et/ou vidéo.

Selon la présente demande, le deuxième procédé comprend : réception, en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio; et envoi d’une notification comprenant un code intégré dans ledit flux de données audio reçu, en association avec un identifiant du deuxième terminal client.

Selon au moins un mode de réalisation, le deuxième procédé comprend en outre, sur une détection dudit code dans ledit flux de données audio reçu : activation (C100) d’un deuxième microphone (MIC2) couplé au deuxième terminal client ; désactivation (C102) d’une fonction d’annulation d’écho (F2) de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur (HP2) couplé audit deuxième terminal client ; génération (C104) d’un signal acoustique de test (SA2) au moyen du deuxième haut- parleur ; acquisition acoustique (C106), au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination (C108), à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques (DTB2) du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation (SV2) des capacités acoustiques du deuxième haut- parleur.

Selon au moins un mode de réalisation, le deuxième procédé comprend : g) réception, en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio marquées ; h) détection, dans le flux audio marquées, d’un code de marquage numérique intégré dans le flux de données audio marquées par tatouage numérique ; et i) envoi, à un serveur de médiation, d’une notification indiquant la détection du code de marquage numérique, ladite notification comprenant le code de marquage numérique en association avec un identifiant du deuxième terminal client.

L’envoi au serveur de médiation de ladite notification permet audit serveur de générer des données de capacité audio indiquant si le deuxième terminal client a détecté le code intégré au flux reçu.. Le serveur de médiation peut notamment transmettre ces données de capacité audio au premier terminal client afin de lui indiquer si le deuxième terminal client est apte ou non à recevoir un flux audio émis par le premier terminal client lors de la conférence.

Selon au moins un mode de réalisation, le deuxième procédé comprend en outre, en réponse à la détection h) : activation d’un deuxième microphone couplé au deuxième terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur couplé audit deuxième terminal client ; génération d’un signal acoustique de test au moyen du deuxième haut-parleur ; acquisition acoustique, au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination, à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation des capacités acoustiques du deuxième haut-parleur.

Il est ainsi possible de tester la chaîne de traitement acoustique au niveau du deuxième terminal client. L’invention vise également un troisième procédé mis en œuvre par un système, comprenant un premier terminal client et un deuxième terminal client exécutant respectivement les premier et deuxième procédés définis ci-avant, dans au moins certains de leurs modes de réalisation, et décrits dans des exemples particuliers ci-après.

Plus particulièrement, l’invention vise un troisième procédé mis en œuvre par un système client, comprenant un premier terminal client et un deuxième terminal client, lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre le premier terminal client et le deuxième terminal client au cours d’une conférence audio et/ou vidéo, dans lequel le premier terminal exécute un premier procédé tel que défini ci-avant ; dans lequel le deuxième terminal exécute un deuxième procédé tel que défini ci-avant ; les informations restituées en d) par le premier terminal client indiquant que le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client.

Selon au moins un mode de réalisation, le troisième procédé comprend en outre (par exemple en réponse à la détection h), les étapes suivantes mises en œuvre par ledit deuxième terminal client : activation d’un deuxième microphone couplé au deuxième terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur couplé audit deuxième terminal client ; génération d’un signal acoustique de test au moyen du deuxième haut-parleur ; acquisition acoustique, au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination, à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques du deuxième haut-parleur du deuxième terminal client à produire une sortie acoustique ; et envoi au serveur de médiation des capacités acoustiques du deuxième haut-parleur ; le procédé comprenant en outre l’étape suivante mise en œuvre par le premier terminal client : réception, en provenance du serveur de médiation, de données de capacité acoustique représentatives desdites capacités acoustiques du deuxième haut-parleur du deuxième terminal client ; les informations restituées en d) par le premier terminal client étant en outre représentatives des capacités acoustiques du deuxième haut-parleur du deuxième terminal client.

L’invention vise également un quatrième procédé mis en œuvre par un serveur de médiation en coopération avec une pluralité de terminaux clients (comprenant un premier terminal client et un deuxième terminal client) participant à une conférence audio et/ou vidéo au cours de laquelle des flux de données audio sont échangés via un serveur de conférence audio et/ou vidéo.

Selon la présente demande, le quatrième procédé comprend : envoi à un premier terminal client d’un code attribué au premier terminal client et enregistré, en association avec un identifiant (ID1) du premier terminal client ; sur réception, en provenance d’un deuxième terminal client, d’une notification comprenant le code attribué audit premier terminal client en association avec un identifiant du deuxième terminal client ; détermination de données de capacité audio indiquant si le deuxième terminal client est apte à recevoir un flux de données audio en provenance du premier terminal client; et envoi au premier terminal client desdites données de capacité audio.

Selon au moins un mode de réalisation, il est déterminé une absence de réception de ladite notification si aucune dite notification, indiquant que le deuxième terminal client (T2) a détecté le code attribué audit premier terminal, n’est reçue dans un premier délai à compter d’un instant de référence.

Plus précisément, selon au moins un mode de réalisation, le quatrième procédé comprend : j) envoi à un premier terminal client d’un code de marquage numérique attribué au premier terminal client et enregistré, dans des données de marquage dudit serveur de médiation, en association avec un identifiant du premier terminal client ; k) détermination, à partir des données de marquage, de si une notification indiquant qu’un deuxième terminal client a détecté le code de marquage numérique est reçue en provenance dudit deuxième terminal client, ladite notification comprenant le code de marquage numérique en association avec un identifiant du deuxième terminal client ;

L) détermination, à partir d’un résultat de la détermination k), de données de capacité audio indiquant si le deuxième terminal client est apte à recevoir un flux de données audio en provenance du premier terminal client ; et m) envoi au premier terminal client des données de capacité audio.

Le serveur de médiation est ainsi capable de superviser le test audio initié par le premier terminal client pour évaluer si le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client lors de la conférence.

Selon au moins un mode de réalisation, il est déterminé en k) une absence de réception de ladite notification si aucune dite notification, indiquant que le deuxième terminal client a détecté le code de marquage numérique, n’est reçue dans un premier délai à compter d’un instant de référence. Le serveur de médiation est ainsi en mesure de déterminer que le deuxième terminal client n’a pas détecté le code de marquage numérique si ledit serveur de médiation ne reçoit pas de notification en ce sens du deuxième terminal client. Selon un mode de réalisation particulier, le serveur de médiation exécute les étapes j) à m) pour une pluralité de deuxièmes terminaux clients, de sorte à envoyer en m) au premier terminal client des données de capacité audio de chacun de la pluralité de deuxièmes terminaux clients.

Le serveur de médiation peut ainsi superviser des tests audio initiés par le premier terminal client de sorte à évaluer si une pluralité de deuxièmes terminaux client participant à la conférence sont aptes à recevoir un flux de données audio émis par le premier terminal client.

Selon un mode particulier de réalisation, les différentes étapes des premier, deuxième procédé, troisième et quatrième procédés tels que définis ci-avant, et tels décrits ci-après dans des exemples particuliers, sont déterminées par des instructions de programmes d’ordinateurs.

En conséquence, l’invention vise aussi des programmes d’ordinateur sur des supports d’informations (ou support d’enregistrement), ces programmes étant susceptibles d’être mis en œuvre dans des terminaux ou dans des serveurs, ou plus généralement dans des ordinateurs, ces programmes comportant des instructions adaptées à la mise en œuvre respectivement des étapes des premier, deuxième, troisième et quatrième procédés. Ainsi, chacun des procédés de l’invention peut être implémenté au moyen d’une mémoire non volatile stockant des instructions de programmes d’ordinateur et d’un processeur exécutant ces instructions.

Selon un mode de réalisation, les différents procédés de l'invention sont mis en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous- programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné. Un tel composant logiciel peut être exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).

De la même manière, un composant matériel peut correspondre à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.

La présente invention vise également un premier terminal client (et respectivement un deuxième terminal client) configuré pour mettre en œuvre le premier procédé (et respectivement le deuxième procédé) de l’invention tel que défini ci-avant et décrit ci-après dans des exemples particuliers.

La présente invention vise également un système comprenant les premier et deuxième terminaux clients de l’invention, configuré pour mettre en œuvre le troisième procédé de l’invention.

La présente invention vise également un serveur de médiation configuré pour mettre en œuvre le quatrième procédé de l’invention tel que défini ci-avant et décrit ci-après dans des exemples particuliers. A noter que les différents modes de réalisation mentionnés ci-avant (ainsi que ceux décrits ci-après) en relation avec les différents procédés de l’invention ainsi que les avantages associés s’appliquent de façon analogue aux terminaux clients, système et serveur de médiation de l’invention.

Pour chaque étape des procédés de l’invention, le dispositif (ou entité physique) associé de l’invention (premier terminal client ; second terminal client, système, serveur de médiation) peut comprendre un module correspondant configuré pour réaliser ladite étape.

Brève description des dessins

D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:

[Fig. 1] La figure 1 représente schématiquement un environnement comprenant des terminaux clients et un serveur de médiation, selon un mode de réalisation particulier de l’invention ;

[Fig. 2] La figure 2 représente schématiquement un premier terminal client selon au moins un mode de réalisation de l’invention ;

[Fig. 3] La figure 3 représente schématiquement un deuxième terminal client selon au moins un mode de réalisation de l’invention ;

[Fig. 4] La figure 4 représente schématiquement un serveur de médiation selon au moins un mode de réalisation de l’invention ;

[Fig. 5] La figure 5 représente, sous forme d'un diagramme, les étapes de procédés mis en œuvre par des terminaux clients et par un serveur de médiation, selon certains modes de réalisation de l'invention ; [Fig. 6] La figure 6 représente, sous forme d'un diagramme, les étapes de procédés mis en œuvre par des terminaux clients et par un serveur de médiation, selon certains modes de réalisation de l'invention ; [Fig. 7] La figure 7 représente, sous forme d'un diagramme, les étapes d’un procédé mis en œuvre par un premier terminal client, selon au moins un mode de réalisation de l'invention ; et [Fig. 8] La figure 8 représente, sous forme d'un diagramme, les étapes d’un procédé mis en œuvre par un deuxième terminal client, selon au moins un mode de réalisation de l'invention.

Description des modes de réalisation

Comme indiqué ci-avant, la présente demande concerne la communication d’utilisateurs lors d’une audioconférence (dit aussi conférence audio) ou visioconférence (dit aussi conférence vidéo). Par définition, les conférences audio et/ou vidéo impliquent l’échange de données au moins de type audio. Ainsi, les conférences audio impliquent des échanges de flux audio tandis que les conférences vidéo impliquent des échanges de flux image et de flux audio (flux vidéo).

L’invention se propose en particulier de permettre à un utilisateur participant à une conférence audio et/ou vidéo (dit aussi plus simplement « conférence ») de vérifier qu’il est ou sera bien entendu par au moins un autre participant donné. Pour ce faire, l’invention utilise, selon ses différents modes de réalisation, un code, attribué à un premier terminal client, comme un code de marquage numérique, qui est intégré dans un flux de données audio pour déterminer si au moins un deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client.

Ainsi, selon au moins certains modes de réalisation , un premier terminal client peut être configuré pour envoyer un flux de données audio marquées à un serveur de conférence audio et/ou vidéo (dit aussi « serveur de conférence ») gérant des échanges de flux de données audio entre le premier terminal client et au moins un deuxième terminal client au cours d’une conférence audio et/ou vidéo. Ce flux de données audio marquées peut comprendre un code, comme un code de marquage numérique, intégré par exemple par tatouage numérique dans un flux de données audio. Le premier terminal client peut recevoir en outre, en provenance d’un serveur de médiation, des données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçu du serveur de conférence audio et/ou vidéo. Il est ainsi possible pour le premier terminal client de déterminer si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client.

En outre, l’invention vise notamment un deuxième terminal client configuré pour traiter un flux de données audio marquées comme indiqué ci-avant, un serveur de médiation correspondant, ainsi que des procédés et programme d’ordinateur correspondants. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux figures mentionnées ci-avant.

Dans ce document, des exemples de mise en œuvre de l’invention sont décrits dans le cadre de la gestion d’une conférence audio et/ou, où seul le traitement des flux de données audio est pris en compte. On comprend toutefois que l’invention s’applique aussi bien dans le cadre d’une conférence audio que dans celui d’une conférence vidéo. De manière générale, l’invention permet notamment de tester la transmission/réception de flux de données audio dans une conférence de communication, de type audioconférence ou vidéoconférence.

Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.

Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc. sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des terminaux, procédé) mis en œuvre dans les modes de réalisation décrits ci-après.

La figure 1 représente schématiquement, à titre d’exemple non limitatif, un environnement comprenant un premier terminal client T1 , un deuxième terminal client T2, un serveur de conférence audio et/ou vidéo SV1 et un serveur de médiation SV2 (dit aussi serveur de contrôle). Dans cet exemple, les terminaux clients T1 et T2 sont utilisés respectivement par des utilisateurs UR1 et UR2 pour communiquer par audio au cours d’une conférence audio et/ou vidéo. Pour ce faire, le serveur de conférence SV1 gère des échanges de flux de données audio FX entre les terminaux clients participant à la conférence.

A noter que le nombre et la nature des terminaux clients participant à la session de communication au cours de la conférence peut varier selon le cas. En particulier, le nombre de deuxièmes terminaux clients au sens de l’invention, dont le premier terminal client T1 teste la réception audio, peut varier selon le cas. A titre d’exemple, des deuxièmes terminaux clients T3 et T4 peuvent aussi coopérer avec le serveur de conférence SV1 et avec le serveur de médiation SV2, bien que des mises en œuvre de l’invention soient également possible avec seulement deux terminaux clients, à savoir le premier terminal client T1 et le deuxième terminal client T2 dans cet exemple. Aussi, le principe de l’invention est décrit ci-après dans des exemples particuliers mettant en jeu principalement le terminal T1 en tant que premier terminal client et le terminaux T2 en tant que deuxième terminal client au sens de l’invention. L’invention peut toutefois s’appliquer de manière analogue à une pluralité de deuxièmes terminaux clients (T2, T3 et/ou T4 par exemple) opérant en tant que deuxièmes terminaux au sens de l’invention. A noter également que chacun des terminaux clients T1-T4 peut en outre être configuré pour agir à la fois en tant que premier terminal et en tant que deuxième terminal au sens de l’invention. On suppose que les terminaux clients sont chacun aptes à coopérer avec le serveur de conférence SV1 via un réseau de communication quelconque, tel qu’internet, ou un réseau Intranet ou un quelconque autre réseau approprié. Les terminaux clients T1-T4 peuvent être des ordinateurs (PC, ordinateurs portables, etc.), des tablettes, téléphones intelligents ou « smartphones », ou tous autres types de terminaux aptes à échanger des flux de données audio lors d’une conférence audio et/ou vidéo avec au moins un autre participant.

Le serveur de conférence SV1 est configuré pour gérer des communications audio lors d’une session de communication établie avec les terminaux clients T1-T4 lors d’une conférence audio et/ou vidéo. Pour ce faire, le serveur de conférence SV1 est apte à établir la session de communication avec chacun des terminaux clients, puis de recevoir les flux de données audio FX émis ou générés par les terminaux clients T1-T4. Le serveur de conférence SV1 traite alors ces flux de données audio afin de les redistribuer aux autres participants. Plus particulièrement, le serveur de conférence SV1 peut par exemple décoder les flux de données audio FX reçus selon des codées appropriés (ceux utilisés par les terminaux clients correspondants), réaliser un mixage de ces données audio et générer un flux de données audio mixées par un ré-encodage des données audio mixées. Ce flux de données audio mixées peut ensuite être envoyé aux différents terminaux clients afin que leurs utilisateurs puissent entendre toutes les communications audio échangées par les participants.

Comme représenté en figure 1 , les terminaux clients T1-T4 peuvent également être aptes à coopérer avec le serveur de médiation SV2 au travers d’un quelconque réseau de communication approprié. Comme décrit en détail par la suite, le serveur de médiation SV2 peut être configuré par exemple pour évaluer les capacités audio d’au moins certains des terminaux clients et pour transmettre à au moins certains aux terminaux clients des données de capacité audio DTA représentatives de capacités audio d’au moins certains des terminaux clients T1-T4. Pour ce faire, le serveur de médiation SV2 peut transmettre à d’au moins certains des terminaux clients (par exemple à chacun) un code WT, comme un code de marquage numérique, qui lui est attribué. Ces codes de marquage numérique sont destinés par exemple à être intégrés par tatouage numérique dans un flux de données audio pour réaliser des tests audio, comme décrit par la suite. A titre d’exemple, le serveur de médiation SV2 peut envoyer des codes de marquages numériques WT 1 et WT2 aux terminaux clients T 1 et T2, respectivement. Comme décrit ultérieurement, ces codes de marquage numérique peuvent être utilisés par la suite pour tester l’aptitude de terminaux clients à recevoir un flux de données audio émis par notamment du premier terminal client T1 dans cet exemple.

Selon un exemple particulier, le serveur de médiation SV2 peut également envoyer aux terminaux clients des données de capacité acoustique DTB (figure 1) représentatives des capacités acoustiques de terminaux clients, comme décrit ultérieurement. Les structures des terminaux clients et du serveur de médiation SV2 sont à présent décrites en référence à la figure 1, selon des modes de réalisation particuliers.

Ainsi, selon un exemple particulier représenté en figure 1 , le terminal client T 1 comprend un processeur 2, une mémoire volatile (RAM) 4, une mémoire non volatile 6, une interface de communication INT 1 , une interface utilisateur IU1 et une mémoire non volatile réinscriptible MR1.

La mémoire 6 est par exemple une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le terminal client T1 , et sur lequel est enregistré un premier programme d’ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG1 comporte des instructions pour l’exécution des étapes d’un premier procédé (dit aussi premier procédé de gestion) selon un mode de réalisation particulier, comme décrit plus en détail ultérieurement.

Le terminal client T1 est apte à utiliser son interface de communication INT1 pour communiquer avec le serveur de conférence SV1 et avec le serveur de médiation SV2. La nature de cette interface est fonction du type de réseau de communication utilisé.

La mémoire non volatile réinscriptible MR1 (par exemple de type flash ou EEPROM) est apte à stocker un identifiant ID1 du terminal client T1 , un code, comme un code de marquage numérique, WT 1 et des données de capacité audio DTA. Le cas échéant, la mémoire MR1 peut également être utilisée pour stocker des données de capacité acoustique DTB.

Dans cet exemple on considère qu’un premier haut-parleur HP1 et un premier microphone MIC1 sont couplés au premier terminal client T 1 de sorte à ce que l’utilisateur UR1 puisse entendre et émettre des communications audio lors d’une conférence audio et/ou vidéo. Des variantes de réalisation sans l’un au moins parmi le haut-parleur HP1 et le microphone MIC1 sont toutefois possibles. Le haut-parleur HP1 permet la génération de sons (dits signaux acoustiques) à partir de données audio tandis que le microphone MIC1 permet de générer des données audio par acquisition acoustique de sons (ou signaux acoustiques). Le haut-parleur HP1 et le microphone MIC1 constituent des moyens audio qui peuvent être utilisés par le processeur 2 au moyen d’une carte audio et/ou de tous autres moyens matériels et/ou logiciels qui sont configurés selon une configuration audio particulière.

Comme décrit par la suite dans des exemples particuliers, le haut-parleur HP1 peut être configuré pour émettre notamment un signal acoustique de test noté SA1 dont le microphone MIC1 peut faire l’acquisition acoustique.

Le processeur 2 utilise par exemple la mémoire volatile 4 pour contrôler les différents composants (mémoires, interface de communication,...) et pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du terminal client T1 , y compris pour exécuter le programme d’ordinateur PG1 lors de la mise en œuvre du premier procédé de l’invention.

Bien que d’autres mises en œuvre soient possibles, on suppose dans cet exemple que le deuxième terminal client T2 présente une structure identique à celle du premier terminal T1 , de sorte que ces deux terminaux peuvent être utilisés de manière interchangeable pour exécuter les premier et deuxième procédés au sens de l’invention. Selon un exemple particulier représenté en figure 1, le deuxième terminal client T2 comprend un processeur 10, une mémoire volatile (RAM) 12, une mémoire non volatile 14, une interface de communication INT2, une interface utilisateur IU2 et une mémoire non volatile réinscriptible MR2.

La mémoire 12 est par exemple une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le terminal client T2, et sur lequel est enregistré un deuxième programme d’ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG2 comporte des instructions pour l’exécution des étapes d’un deuxième procédé (dit aussi deuxième procédé de gestion) selon un mode de réalisation particulier, comme décrit plus en détail ultérieurement.

Le terminal client T2 est apte à utiliser son interface de communication INT2 pour communiquer avec le serveur de conférence SV1 et avec le serveur de médiation SV2. Comme déjà indiqué, la nature de cette interface est fonction du type de réseau de communication utilisé.

La mémoire non volatile réinscriptible MR2 (par exemple de type flash ou EEPROM) est apte à stocker un identifiant ID2 du terminal client T2, un code de marquage numérique WT2 et des données de capacité audio DTA. Le cas échéant, la mémoire MR2 peut également être utilisée pour stocker des données de capacité acoustique DTB.

Dans cet exemple on considère qu’un deuxième haut-parleur HP2 et un deuxième microphone MIC2 sont couplés au deuxième terminal client T2 de sorte à ce que l’utilisateur UR2 puisse entendre et émettre des communications audio lors d’une conférence audio et/ou vidéo. Des variantes de réalisation sans l’un au moins parmi le haut-parleur HP2 et le microphone MIC2 sont toutefois possibles. Le haut-parleur HP2 permet la génération signaux acoustiques à partir de données audio tandis que le microphone MIC2 permet de générer des données audio par l’acquisition acoustique de signaux acoustiques. Le haut-parleur HP2 et le microphone MIC2 constituent des moyens audio qui peuvent être utilisés par le processeur 10 au moyen d’une carte audio et/ou de tous autres moyens matériels et/ou logiciels qui sont configurés selon une configuration audio particulière.

Comme décrit par la suite dans des exemples particuliers, le haut-parleur HP2 peut être configuré pour émettre notamment un signal acoustique de test noté SA2 dont le microphone MIC2 peut faire l’acquisition acoustique.

Le processeur 10 utilise par exemple la mémoire volatile 12 pour contrôler les différents composants (mémoires, interface de communication,...) et pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du terminal client T2, y compris pour exécuter le programme d’ordinateur PG2 lors de la mise en œuvre du deuxième procédé de l’invention.

Dans cet exemple, le premier terminal client T1 et le deuxième terminal client T2 forment ensemble un système client SY1 , ce dernier pouvant éventuellement comprendre aussi un ou d’autres terminaux clients, tels que les terminaux T3 et/ou T4 par exemple. Le système client SY1 est configuré pour mettre en œuvre un troisième procédé au sens de l’invention en exécutant les instructions des programmes d’ordinateur PG1 et PG2 par les terminaux clients T1 et T2. Selon un exemple particulier représenté en figure 1, le serveur de médiation SV2 comprend un processeur 20, une mémoire volatile (RAM) 22, une mémoire non volatile 24, une interface de communication INT3 et une mémoire non volatile réinscriptible MR3.

La mémoire 24 est par exemple une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le serveur de médiation SV2, et sur lequel est enregistré un troisième programme d’ordinateur PG3 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG3 comporte des instructions pour l’exécution des étapes d’un quatrième procédé selon un mode de réalisation particulier, comme décrit plus en détail ultérieurement.

Le serveur de médiation SV2 est apte à utiliser son interface de communication INT3 pour communiquer avec les terminaux clients T 1 et T2. Comme déjà indiqué, la nature de cette interface est fonction du type de réseau de communication utilisé. Dans cet exemple, le serveur de médiation SV2 est également apte à communiquer au moyen de son interface de communication INT3 avec les terminaux clients T3 et/ou T4, bien que des mises en œuvre sans ces terminaux clients supplémentaires soient possibles comme déjà indiqué.

La mémoire non volatile réinscriptible MR3 (par exemple de type flash ou EEPROM) est apte à stocker des données de marquage DM et des données de capacité audio DTA. Les données de marquage DM comprennent au moins un code de marquage numérique WT en association avec un identifiant ID d’un terminal client respectif auquel a été attribué ledit code de marquage numérique WT. Les données de marquage DM peuvent ainsi comprendre une pluralité de couples (ID, WT), un code de marquage numérique WT distinct étant attribué à chaque terminal client.

Le processeur 20 utilise par exemple la mémoire volatile 22 pour contrôler les différents composants (mémoires, interface de communication,...) et pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du serveur de médiation SV2, y compris pour exécuter le programme d’ordinateur PG3 lors de la mise en œuvre du quatrième procédé de l’invention.

La nature et la configuration des différents éléments (composants, données, etc.) mentionnés ci-avant en relation avec les terminaux clients et le serveur de médiation SV2 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 2-8. A noter que les éléments représentés en figure 1 ne constituent que des exemples de réalisation particuliers, d’autres mises en œuvre étant possibles dans le cadre de l’invention. L’homme du métier comprend en particulier que certains éléments de l’environnement considéré ne sont décrits ici que pour faciliter la compréhension de l’invention, ces éléments n’étant pas nécessaires pour mettre en œuvre l’invention. Comme représenté en figure 2 selon un mode de réalisation particulier, le processeur 2 piloté par le programme d’ordinateur PG1 met ici en œuvre un certain nombre de modules dans le premier terminal client T1 , à savoir : un module d’obtention MD2, un module d’envoi MD4, un module de réception MD6, un module de contrôle MD8, et éventuellement aussi un module de test acoustique MD10.

Le module d’obtention MD2 est configuré pour obtenir un flux de données audio FX1 marquées par intégration d’un code de marquage numérique WT1 dans un premier flux de données audio par tatouage numérique. Comme décrit par la suite, ce flux de données audio marquées FX1 peut être obtenu de diverses manières par le premier terminal client T1. Le module d’envoi MD4 est configuré pour envoyer le flux de données audio marquées FX1 au serveur de conférence audio et/ou vidéo SV1.

Le module de réception MD6 est configuré pour recevoir, en provenance du serveur de médiation SV1 , des données de capacité audio DTA représentatives de si ledit au moins un deuxième terminal client T2 a détecté le code de marquage numérique WT 1 dans un flux de données audio FX reçu du serveur de conférence audio et/ou vidéo SV1.

Le module de contrôle MD8 est configuré pour déclencher au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio DTA reçues. Comme expliqué par la suite, la ou les actions réalisées peuvent être de diverses natures et peuvent être adaptées selon le cas. Ladite au moins une action de gestion peut comprendre, par exemple, la restitution, par l’interface utilisateur IU1 du premier terminal client T1 , d’informations qui sont fonction des données de capacité audio DTA reçues et qui indiquent si ledit au moins un deuxième terminal client T2 est apte à recevoir un flux de données audio FX du premier terminal client T 1.

Le module de test acoustique MD10 peut en outre être configuré pour réaliser un test acoustique de l’équipement audio du premier terminal client T1 , en particulier pour réaliser un test acoustique du microphone MIC1 et/ou du haut-parleur HP1.

Comme représenté en figure 3 selon un mode de réalisation particulier, le processeur 10 piloté par le programme d’ordinateur PG2 met ici en œuvre un certain nombre de modules dans le deuxième terminal client T2, à savoir : un module de réception MD20, un module de détection MD22, un module d’envoi MD24, et éventuellement aussi un module de test acoustique MD26.

Le module de réception MD20 est configuré pour recevoir, en provenance du serveur de conférence audio et/ou vidéo, un flux de données audio marquées notées FX2.

Le module de détection MD22 est configuré pour détecter, dans le flux audio marquées FX2, un code de marquage numérique WT (WT 1 par exemple), ce dernier étant intégré dans le flux de données audio FX2 par tatouage numérique.

Le module d’envoi MD24 est configuré pour envoyer, au serveur de médiation SV2, une notification indiquant la détection du code de marquage numérique WT (WT1 par exemple), ladite notification comprenant le code de marquage numérique en association avec l’identifiant ID2 du deuxième terminal client T2.

Le module de test acoustique MD26 peut en outre être configuré pour réaliser un test acoustique de l’équipement audio du deuxième terminal client T2, en particulier pour réaliser un test acoustique du microphone MIC2 et/ou du haut-parleur HP2.

Comme représenté en figure 4 selon un mode de réalisation particulier, le processeur 20 piloté par le programme d’ordinateur PG3 met ici en œuvre un certain nombre de modules dans le serveur de médiation SV2, à savoir : un module d’envoi MD40, un premier module de détermination MD42, un deuxième module de détermination MD44 et un module d’envoi MD46.

Le module d’envoi MD40 est configuré pour envoyer au premier terminal client T1 un code de marquage numérique WT1 attribué au premier terminal client T1 et enregistrer, dans des données de marquage DM du serveur de médiation SV2, en association avec l’identifiant ID1 du premier terminal client T1. Dans l’exemple considéré ici, les données de marquage DM sont stockées dans la mémoire non volatile MR3.

Le premier module de détermination MD42 est configuré pour déterminer, à partir des données de marquage DM enregistrées, si une notification indiquant que le deuxième terminal client T2 a détecté le code de marquage W1 est reçue en provenance du deuxième terminal client T2, cette notification comprenant le code de marquage numérique W1 en association avec l’identifiant ID2 du deuxième terminal client T2.

Le deuxième module de détermination MD44 est configuré pour déterminer, à partir d’un résultat de la détermination réalisée par le premier module de détermina MD42, des données de capacité audio DTA2 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX en provenance du premier terminal client T 1.

Le module d’envoi MD46 est configuré pour envoyer au premier terminal client T1 les données de capacité audio DTA2 déterminées par le deuxième module de détermination MD44.

Selon un exemple particulier, le module d’envoi MD46 est en outre configuré pour envoyer au premier terminal client T1 des données de capacité acoustique DTB2 du deuxième terminal audio T2, ces données de capacité acoustique DTB2 pouvant caractériser l’équipement acoustique du deuxième terminal client T2, et en particulier son microphone MIC2 et/ou son hautparleur HP2.

La configuration et le fonctionnement des modules MD2-MD10 du premier terminal client T1 , des modules MD20-MD26 du deuxième terminal client T2 et des modules MD40-MD46 du serveur de médiation SV2 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 5-8. A noter que les modules MD2-MD10, MD20-MD26 et MD40-MD46 tels que représentés dans les figures 2-4 ne constituent que des exemples de mise en œuvre non limitatifs de l’invention.

Un mode de réalisation particulier est à présent décrit en référence à la figure 5. Plus précisément, le premier terminal client T1 et le deuxième terminal client T2 tels que précédemment décrits en référence aux figures 1-3 mettent en œuvre respectivement un premier procédé et un deuxième procédé en exécutant les programmes d’ordinateur PG1 et PG2. Ces premier et deuxième procédés forment collectivement un troisième procédé mis en œuvre par le système SY 1 représenté en figure 1. De plus, le serveur de médiation SV2 tels que précédemment décrit en référence aux figures 1 et 4 met en œuvre un quatrième procédé en exécutant le programme d’ordinateur PG3.

Les utilisateurs UR1 et UR2 utilisent respectivement les terminaux clients T1 et T2 pour communiquer ensemble, au moins par audio, au cours d’une conférence audio et/ou vidéo. Pour ce faire, on considère qu’une session de communication est établie par les terminaux clients T1 et T2 en coopération avec le serveur de conférence audio et/ou vidéo SV1 qui gère les flux de données audio FX entre le premier terminal client T1 et le deuxième terminal client T2 au cours d’une conférence audio et/ou vidéo.

Selon un exemple particulier, au cours d’une étape D2 d’envoi (figure 5), le serveur de médiation SV2 envoie un code de marquage numérique WT1 qui est reçu par le premier terminal client T1 en B2. Ce code de marquage numérique WT 1 , qui peut se présenter sous diverses formes, est attribué au premier terminal client T1. Ce code de marquage numérique WT1 est un code (ou marqueur) qui peut être intégré par tatouage numérique (dit aussi « watermarking » en anglais) dans un flux de données audio. Au cours d’une étape B4 d’obtention, le premier terminal T 1 obtient un flux de données audio FX1 , ces données audio étant marquées par intégration du code de marquage numérique (appelées aussi « marque ») WT1 dans un flux de données audio, par exemple par tatouage numérique. La technique de tatouage numérique permet d’insérer des informations de marquage dans des données hôtes, en l’espèce des données audio, de sorte par exemple que ces informations de marquage ne soient pas perceptibles (audibles) pour un utilisateur. Pour ce faire, les bits du code de marquage numérique sont encodés dans le flux de données audio qui sert de signal porteur.

Selon un exemple particulier, le premier terminal client T 1 détermine ou génère (B4) le flux de données audio marquées FX1 à partir du code de marquage numérique WT1 reçu en B2, en intégrant par tatouage numérique le code de marquage numérique WT 1 dans un premier flux de données audio par tatouage numérique.

A noter que des variantes sont toutefois possibles selon lesquelles le premier terminal client T1 obtient en B4 le flux de données audio marquées FX1 d’une autre manière. Selon un exemple particulier, le premier terminal client T1 ne reçoit pas le code de marquage numérique WT1 depuis le serveur de médiation DV2 mais obtient ce code en B2 d’une autre manière, par exemple en consultant sa mémoire MR1 dans laquelle est préenregistré ledit code WT 1 . Le premier terminal client T 1 peut alors insérer le code de marquage numérique WT1 , par exemple par tatouage numérique, dans un flux de données audio FX pour obtenir le flux de données audio marquées FX1. Selon encore une autre variante, le flux de données audio marquées FX1 est préenregistré dans une mémoire (par exemple MR1) du premier terminal client T1 et ce dernier consulte sa mémoire pour obtenir en B4 le flux de données audio marquées FX1 , de sorte que l’étape B2 de réception n’est non plus nécessaire.

Quelle que soit la manière dont le premier terminal client T1 obtient (B4) le flux de données audio marquées FX1 , on suppose que le serveur de médiation SV2 enregistre dans sa mémoire (ici la mémoire MR2), au cours d’une étape D3 d’enregistrement (figure 5), des données de marquage DM associant l’identifiant ID1 du premier terminal client T1 avec le code de marquage numérique WT1 attribué audit premier terminal client T 1 .

Au cours d’une étape B6 d’envoi, le premier terminal client T1 envoie le flux de données audio marquées FX1 au serveur de conférence SV2. Le serveur de conférence SV2 reçoit le flux de données audio marquées FX1 au cours d’une étape A6 de réception.

Le serveur de conférence SV1 envoie ensuite (étape A8, figure 5) au deuxième terminal client T2 un deuxième flux de données audio marquées FX2 comportant le code de marquage numérique WT1 intégré par exemple par tatouage numérique. Pour ce faire, le serveur de conférence SV1 détermine au préalable le flux de données audio marquées FX2 à partir d’un traitement du flux de données audio marquées FX1 reçues en A6. Dans l’exemple considéré ici, le flux de données audio marquées FX2 comprend le flux de données audio marquées FX1. En particulier, le flux de données audio marquées FX2 peut être un flux de données audio mixées généré par le serveur de conférence SV1 en mixant (ou combinant) le flux de données audio marquées FX1 reçu en A6 avec au moins un autre flux de données audio émis par un autre terminal client, par exemple par le deuxième terminal client T2. Le serveur de médiation SV2 peut ainsi mixer les flux audio provenant des différents terminaux clients lorsque les utilisateurs parlent ou émettent des sons de sorte à redistribuer les flux audio à l’ensemble des participants.

Selon un exemple particulier, le serveur de conférence SV1 décode (à partir de codées) chaque flux de données audio qu’il reçoit en provenance des terminaux clients (y compris le flux de données audio marquées FX1), puis mixe les données audio ainsi décodées pour générer un flux de données audio mixées qui sont marquées puisqu’elles intègrent le code de marquage numérique WT 1. Le serveur de conférence SV1 génère ensuite (à partir de codées) le flux de données audio marquées FX2 en réencodant ces données audio mixées.

On considère à présent que le deuxième terminal client T2 reçoit, au cours d’une étape C8 de réception, le flux de données audio marquées FX2 provenant du serveur de conférence SV1.

Au cours d’une étape C10 de détection, le deuxième terminal client T2 détecte alors le code de marquage numérique WT1 intégré dans le flux de données audio marquées FX2, par exemple par tatouage numérique. Pour ce faire, le deuxième terminal client T2 analyse le flux de données audio entrant et vérifie si ce flux contient un code de marquage numérique (ou une marque). On suppose dans cet exemple que le deuxième terminal client T2 est capable de reconnaître un code de marquage numérique WT mais ne connaît pas le terminal client associé à chaque code de marquage numérique WT (bien que d’autres exemples soient possibles).

A noter qu’il n’est pas nécessaire que le deuxième terminal client T2 restitue le flux de données audio marquées FX2 sous forme acoustique au moyen dans cet exemple du haut-parleur HP2, bien que cela soit possible. La restitution sonore du flux audio FX2 peut toutefois être utile lorsque au moins l’un des participants à la conférence audio et/ vidéo est en train d’émettre des sons.

Au cours d’une étape C12 d’envoi, le deuxième terminal client T2 envoie au serveur de médiation SV2 une notification NF1 indiquant la détection du code de marquage numérique WT1 , cette notification NF1 comprenant le code de marquage numérique WT1 en association avec l’identifiant ID2 du deuxième terminal client T1. Le serveur de médiation SV2 reçoit la notification NF1 au cours d’une étape D12 (figure 5) de réception.

Au cours d’une étape D14 de détermination, le serveur de médiation SV2 détermine, à partir des données de marquage DM enregistrées dans sa mémoire MR3, si une notification NF1 - indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 - est reçue en provenance du deuxième terminal client T2, cette notification NF1 comprenant le code de marquage numérique WT1 en association avec l’identifiant ID2 du deuxième terminal client T2.

Comme décrit par la suite, l’exécution du quatrième procédé par le serveur de médiation SV2 peut varier à ce stade en fonction du résultat de l’étape D14 de détermination. Le résultat de cette étape D14 peut être positif (le serveur de médiation SV2 détecte la notification NF1) ou négatif (le serveur de médiation SV2 ne détecte pas la notification NF1). Pour ce faire, si le serveur de médiation SV2 reçoit en provenance du deuxième terminal client T2 une notification indiquant la détection d’un code de marquage numérique, il consulte ses données de marquage DM pour déterminer si cette notification comprend le code de marquage numérique WT1 associée à l’identifiant ID1 dans ses données de marquage DM. Dans l’affirmative, le serveur de médiation SV2 détermine que le deuxième terminal client T2, identifié par l’identifiant ID2 compris dans la notification NF1 reçue, a détecté le code de marquage numérique WT1 associé au premier terminal client T1.

Selon un exemple particulier, le serveur de médiation SV2 détermine en D14 une absence de réception de la notification NF1 en D12 si aucune dite notification, indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 , n’est reçue dans un premier délai DL1 à compter d’un instant de référence tO. Autrement dit, si le premier délai DL1 expire sans que la notification NF1 n’ait été reçue par le serveur de médiation SV2, ce dernier détecte qu’aucune notification NF1 indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 n’a été reçue. Comme décrit plus en détail ultérieurement, cet instant de référence peut varier selon le cas, et peut correspondre par exemple à un instant au cours duquel l’envoi D2 est réalisé.

Au cours d’une étape D16 de détermination, le serveur de médiation SV2 détermine ensuite, à partir d’un résultat de la détermination D14, des données de capacité audio DTA2 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX en provenance du premier terminal client T1. Autrement dit, les données de capacité audio DTA2 caractérisent la capacité du deuxième terminal client T2 à recevoir un flux de données audio FX émis par le premier terminal client T1 au cours de la conférence audio et/ou vidéo.

En effet, la détection par le deuxième terminal client T2 du code de marquage numérique WT1 indique que le deuxième terminal client T2 a été en mesure de recevoir le flux de données audio marquées FX2 comprenant le flux de données audio marquées FX1 émis en B6 par le premier terminal client T 1. En cas de détermination en D14 que la notification NF1 a été reçue, les données de capacité audio DTA2 générées en D16 indiquent par conséquent que le deuxième terminal client T2 est apte à recevoir un flux de données audio émis par le premier terminal client T 1 .

Si le deuxième terminal client T2 n’a pas détecté le code de marquage numérique WT2, cela signifie qu’il n’a pas pu recevoir le flux de données audio marquées FX2 transmis par le serveur de conférence SV1. Autrement dit, un résultat négatif de la détermination D14 signifie que le test de réception d’un flux audio depuis le premier terminal client T1 vers le deuxième terminal client T2 a échoué. Aussi, s’il est déterminé en D14 qu’aucune notification NF1 - indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 - n’a été reçue, les données de capacité audio DTA2 générées en D16 par le serveur de médiation SV2 indiquent que le deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio en provenance du premier terminal client T 1.

Au cours de cette étape D16 de détermination, le serveur de médiation SV2 peut éventuellement mettre à jour des précédentes données de capacité audio DTA2 déjà stockées dans sa mémoire MR3.

Lors d’une étape D18 d’envoi, le serveur de médiation SV2 envoie alors au premier terminal client T1 les données de capacité audio DTA2 déterminées en D16. Selon un exemple particulier, le serveur de médiation SV2 envoie (D18) également au premier terminal client T1 des données de capacité acoustique DTB représentatives de capacités acoustiques du deuxième haut-parleur HP2 couplé au deuxième terminal client T2 à produire une émission (ou sortie) acoustique. Ces données de capacité acoustique DTB peuvent être obtenues de diverses manières par le serveur de médiation SV2, des exemples de réalisation particuliers étant décrits ci-après. Le premier terminal client T 1 reçoit les données de capacité audio DTA2, et le cas échéant les données de capacité acoustique DTB2, au cours d’une étape B20 de réception. Les données reçues peuvent éventuellement être associées à l’identifiant ID2 du deuxième terminal client T2 pour permettre au premier terminal client T 1 de déterminer qu’il s’agit de données caractérisant le deuxième terminal client T2.

Lors d’une étape B22 de gestion, le premier terminal client T 1 déclenche ensuite, à partir des données de capacité DTA2 (et éventuellement des données de capacité acoustique DTB2) reçues, au moins une action de gestion de la conférence audio et/ou vidéo en cours. La ou les actions de gestion exécutées par le premier terminal client T1 peuvent varier selon le cas et consistent à adapter le fonctionnement du premier terminal client T1 en fonction de l’aptitude ou non-aptitude du deuxième terminal client T2 à recevoir un flux de données audio émis par le premier terminal client T1 (et éventuellement l’aptitude à restituer les sons correspondants) lors de la conférence audio et/ou vidéo. Selon un exemple particulier, lors de l’étape B22 de gestion, le premier terminal client T1 restitue (ou rend), au moyen de son interface utilisateur IU1 , des informations IF1 qui sont fonction des données de capacité audio DTA2 reçues (et aussi éventuellement des données de capacité acoustique DTB2 reçues), ces informations IF1 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX (et éventuellement s’il est apte à restituer les sons correspondants). Cette restitution, qui peut pendre diverses formes (restitution visuelle, auditive, etc.) peut aider, au moins dans certains modes de réalisation, l’utilisateur UR1 è déterminer s’il est, ou va être, bien entendu lorsqu’il parle ou émet des sons au cours de la conférence audio et/vidéo.

Selon un exemple particulier, lors de l’étape B22 de gestion, le premier terminal client T1 modifie au moins un paramètre de fonctionnement ou une configuration audio selon laquelle il fonctionne pour échanger des flux de données audio en coopération avec le serveur de conférence SV1 au cours de la conférence.

Selon un exemple particulier, lors de l’étape B22 de gestion, le premier terminal client T1 réalise un basculement depuis la conférence audio et/ou vidéo en cours vers une deuxième conférence audio et/ou vidéo (conférence de secours ou de remplacement) dans laquelle coopèrent également au moins les terminaux T1 et T2 pour s’échanger des flux audio. Le premier terminal T1 peut par exemple coopérer avec au moins le deuxième terminal client T2 dans plusieurs conférences simultanément, ou encore dans plusieurs conférences successives sur une période donnée. Dans ces deux cas, un basculement vers une nouvelle conférence peut permettre au premier terminal client T1 de résoudre un problème de réception audio identifié à partir des données DTA2 (et éventuellement DTB2) reçues en B20 (figure 5).

Selon un exemple particulier, le serveur de conférence SV1 peut envoyer le flux de données audio mixées FX2 à une pluralité de deuxièmes terminaux clients, par exemple à T2, T3 et T4. Dans ce cas, les terminaux clients T3 et T4 peuvent traiter le flux de données audio marquées FX2 en exécutant les étapes C8-C12 de la même manière que le deuxième terminal client T2. Le serveur de médiation SV2 peut exécuter alors par exemple les étapes D12, D14 et D16 pour au moins un (par exemple chacun) des deuxièmes terminaux clients T2-T4 de sorte à générer en D16 des données de capacité audio DTA2, DTA3 et/ou DTA4 indiquant respectivement si ledit deuxième terminal client a détecté le code de marquage numérique WT1 dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo SV1. Le serveur de médiation SV2 peut ainsi envoyer en D18, au premier terminal client T1 , les données de capacité audio DTA2, DTA3 et/ou DTA4 (ainsi qu’éventuellement des données de capacité acoustique DTB2, DTB3 et DTB4 associées respectivement aux terminaux T2, T3 et T4). De cette manière, la ou les actions de gestion exécutées en B22 par le premier terminal client T1 peuvent être fonction des différentes données reçues.

Comme déjà indiqué, il n’est pas toujours aisé pour un utilisateur participant à une conférence audio et/ou vidéo de savoir s’il est, ou s’il va être, bien entendu des autres participants lorsqu’il parle ou qu’il s’apprête à parler lors d’une conférence audio et/ vidéo. Divers problèmes matériels, logiciels ou autres sont susceptibles de faire obstacle à une bonne transmission d’un flux audio depuis le terminal client du locuteur considéré vers les terminaux clients d’autres participants. L’usage dans au moins certains modes de réalisation de l’invention de la technique de marquage numérique (dit « watermarking ») peut aider à tester de façon fiable et robuste la capacité de terminaux clients à recevoir des flux de données audio en provenance d’un terminal client donné au cours d’une conférence audio et/ou vidéo. L’invention permet donc de limiter les risques qu’un utilisateur parle sans être entendu par un autre participant à la conférence audio et/ou vidéo.

Comme décrit ci-avant, l’invention implique l’envoi par un premier terminal client d’un flux de données audio intégrant un code de marquage numérique. Un deuxième terminal tiers ne peut détecter le code de marquage que s’il a la capacité de recevoir et traiter correctement le flux de données audio provenant du premier terminal client. Si le deuxième terminal client détecte le code de marquage numérique, il en informe alors le serveur de médiation SV2 qui met à jour ses données de capacité audio, afin qu’elles indiquent que le deuxième terminal client est capable de recevoir les flux de données audio émis par le premier terminal.

La technique de marquage numérique peut impliquer l’usage d’un flux de données audio pour porter le code de marquage numérique. Ce code, qui peut être inaudible pour un utilisateur du deuxième terminal client, sert à marquer le flux de données audio de façon fiable et sécurisée pour vérifier que la transmission du flux audio depuis le premier terminal client vers le deuxième terminal client est opérationnelle.

Comme indiqué ci-avant, le serveur de conférence SV1 est par exemple en charge de la gestion des échanges de flux de données audio entre le premier terminal client T1 et les deuxièmes terminaux clients T2-T4. En particulier, le serveur de conférence SV1 peut être configuré pour traiter tous les flux de données audio émis par les terminaux clients de sorte à produire un flux de données audio mixées FX2 qui est distribué à l’ensemble des terminaux clients (ou au moins au deuxième terminal client T2). Le traitement réalisé par le serveur de conférence SV1 peut comprendre en particulier un décodage des flux de données audio FX reçus (dont le flux FX1 ) et un mixage de ces flux de sorte à produire un flux de données audio mixées qui est ré-encodé avant envoi aux terminaux clients. La technique de marquage par tatouage numérique peut offrir, au moins dans certains modes de réalisation, une bonne robustesse dans la mesure où le code de marquage numérique WT1 présent dans le flux de données audio marquées FX1 reçu (A6, figure 5) en provenance du premier terminal client T 1 résiste par nature aux différents traitements de décodage, mixage encodage etc. réalisés par le serveur de médiation SV1. Ainsi, le flux de données audio mixées FX2 envoyé en A8 au deuxième terminal client T2 comprend le même code de marquage numérique WT 1 que celui présent dans le flux de données audio marquées FX1 reçu en A6 en provenance du premier terminal client T 1.

Des exemples particuliers de mise en œuvre des procédés décrits ci-avant en référence à la figure 5 sont à présent décrits en relation avec les figures 6-8. Pour ce faire, le premier terminal client T1 et le deuxième terminal client T2 (figures 1-3) exécutent respectivement les programmes d’ordinateur PG1 et PG2 pour mettre en œuvre un premier procédé et un deuxième procédé. Comme déjà décrit, ces premier et deuxième procédés forment collectivement un troisième procédé mis en œuvre par le système SY1 représenté en figure 1. De plus, le serveur de médiation SV2 (figures 1 et 4) met en œuvre un quatrième procédé en exécutant le programme d’ordinateur PG3.

On suppose à nouveau que les utilisateurs UR1 et UR2 utilisant respectivement les terminaux clients T1 et T2 souhaitent communiquer ensemble, au moins par audio, au cours d’une conférence audio et/ou vidéo. Pour ce faire, au cours d’une étape S2 d’établissement de session, les terminaux clients T1 et T2 établissent chacune une session de communication en coopération avec le serveur de conférence SV1 gérant des échanges de flux de données audio entre le premier terminal client T1 et le deuxième terminal client T2.

A noter que dans les exemples de réalisation qui suivent, le premier terminal client T 1 teste la réception audio d’un seul deuxième terminal client T2, bien que d’autres exemples soient possibles où la réception audio d’au moins deux deuxième terminaux client T2 est testée. Dans ce cas, chaque deuxième terminal client exécute le deuxième procédé de la même manière que le deuxième terminal client T2.

Lors de l’établissement S2 des sessions de communication (ou après), un identifiant unique ID est attribué à chaque terminal client participant à la conférence audio et/ou vidéo. Ainsi, lors d’étapes B40 et C40 d’obtention, les premier et deuxième terminaux clients obtiennent respectivement leur identifiant respectif ID1 et ID2. La manière dont ces terminaux obtiennent leur identifiant unique peut varier selon le cas. Selon un exemple particulier, c’est le serveur de conférence SV1 qui transmet aux terminaux clients T1 et T2 leur identifiant respectif. Selon un autre exemple, ce sont les utilisateurs UR1 et UR2 qui définissent respectivement les identifiants ID1 et ID2 (ou ceux-ci sont défini par défaut par leur terminal client).

Comme déjà indiqué, le premier terminal client T1 peut obtenir (B4, figure 5) le flux de données audio marquées FX1 de diverses manières selon l’implémentation considérée. Dans cet exemple, le premier terminal client T1 envoie (B42, figure 6) au serveur de médiation SV2 une requête RQ1 de code de marquage numérique (ou requête de demande de code), cette requête RQ1 comprenant l’identifiant ID1 du premier terminal client T1. Le serveur de médiation SV2 reçoit cette requête RQ1 au cours d’une étape D42 de réception.

Le serveur de médiation SV2 obtient (D44) ensuite un code de marquage numérique WT1 attribué au premier terminal client T1. Pour ce faire, le serveur de médiation SV2 peut déterminer ou générer le code de marquage numérique WT 1 d’une quelconque manière appropriée. Ce code de marquage WT 1 peut prendre diverses formes et peut par exemple être une série de bits. Le serveur de médiation SV2 envoie (D46) ensuite le code de marquage numérique WT 1 au premier terminal client T 1. En réponse à la requête RQ1 , le premier terminal client T1 reçoit ainsi en B46 le code de marquage numérique WT 1 qui lui est attribué. Selon un exemple particulier, un code de marquage numérique WT distinct est attribué par le serveur de médiation SV2 à chaque deuxième terminal client T2-T4.

Lors d’une étape D48 d’enregistrement, le serveur de médiation SV2 enregistre, dans des données de marquage DM, le code de marquage numérique WT1 en association avec l’identifiant ID1 du premier terminal client T1 . A noter que cette étape D48 d’enregistrement peut être réalisée à divers moments, par exemple avant ou après l’étape D46 d’envoi, voire même avant l’étape D4 de réception de la requête RQ1 (dans ce dernier cas, le serveur de médiation SV2 a défini l’association ID1/WT 1 avant la réception de la requête RQ1).

Selon un exemple particulier, le premier terminal client T1 détermine, lors de l’établissement S2 de la session de communication (ou tout du moins avant l’envoi B42 de la requête RQ1 ), un identifiant IDC de la conférence audio. Le premier terminal client T1 peut alors insérer dans la requête RQ1 cet identifiant IDC de la conférence audio et/ou vidéo avant l’envoi B42 au serveur de médiation SV2, de sorte à permettre par exemple au serveur de médiation SV2 d’enregistrer le code de marquage numérique WT 1 en association avec l’identifiant ID1 du premier terminal client T 1 et l’identifiant IDC de la conférence audio et/ou vidéo.

L’identifiant IDC de la conférence permet au serveur de médiation SV2 de reconnaître les requêtes associées à la conférence audio et/ou vidéo en cours, de générer un code de marquage numérique WT unique pour au moins un terminal client (voire pour chacun d’entre eux) participant à ladite conférence. De cette manière, le serveur de médiation SV2 peut par exemple superviser le test de réception de flux audio pour une pluralité de conférences audio et/ vidéo distinctes, y compris lorsque le premier terminal client T1 participe à plusieurs conférences simultanément ou successivement sur une période donnée.

Selon des variantes, le serveur de médiation SV2 réalise les étapes D44, D46 et D48 sans que cela soit sollicité par le premier terminal client T1 , c’est-à-dire indépendamment d’une quelconque requête RQ1 émise par le premier terminal client T 1.

Par ailleurs, comme déjà indiqué, le premier terminal client T1 peut obtenir le flux de données audio marquées FX1 de diverses manières. Selon l’exemple représenté en figure 6, le premier terminal client T1 génère ou détermine (B50) un flux de données audio marquées FX1 en intégrant (ou insérant) par tatouage numérique le code de marquage numérique WT 1 dans un premier flux de données audio FXO qui sert de flux porteur. Ce premier flux de données audio FXO peut être un flux de données audio de test, c’est-à-dire un flux dont les données audio sont destinées uniquement à tester la réception audio du deuxième terminal client T2 et qui n’ont pas vocation à être restituées par le deuxième terminal client T2 à son utilisateur UR2.

Selon un exemple particulier, le premier terminal client T 1 génère le premier flux de données audio FXO par émulation d’un bruit aléatoire. Dans cet exemple, cette émulation peut être réalisée tandis que le microphone MIC1 du premier terminal client T 1 est désactivé. Il est ainsi possible de produire un signal porteur pour le code de marquage numérique WT 1 , même si aucun signal acoustique n’est acquis par le microphone MIC1 (par exemple lorsqu’une fonction sourdine, ou « mute » est activée). Selon un exemple particulier, le premier terminal client T 1 génère le premier flux de données audio FXO à partir de données audio utiles, c’est-à-dire à partir de données audio émises par le premier terminal client T1 au cours de la conférence audio et/ou vidéo et destinées à être restituées par le deuxième terminal client T2 à l’utilisateur UR2. Ainsi, le premier flux de données audio FXO peut par exemple être généré à partir de signaux acoustiques (ou sons) acquis par le premier microphone MIC1 couplé au premier terminal client T1. Cette variante permet de tester la réception audio du deuxième terminal client T2 alors que le premier terminal client T1 est en train de capter des sons (par exemple pendant que l’utilisateur UR1 est en train de parler lors de la conférence audio et/ou vidéo).

Selon un exemple particulier, les signaux acoustiques à partir desquels est généré le premier flux de données audio FXO représentent un (ou résultent d’un) bruit de fond acquis par le premier microphone MIC1 , l’intensité de ce bruit de fond étant inférieure à une première valeur d’intensité 11. Le flux de données audio marquées FX1 peut alors être généré en B50 à partir de ce bruit de fond, par exemple lorsque l’utilisateur UR1 du premier terminal client T1 ne parle pas. Cette valeur 11 peut être adaptée par l’homme du métier selon le cas.

Selon un exemple particulier, le premier terminal client T1 déclenche l’envoi B40 de la requête RQ1 de code de marquage numérique sur détection, au moyen de son microphone MIC1 , d’une période de silence d’une durée au moins égale à une première durée D1 , au cours de laquelle un bruit de fond d’une intensité inférieure à ladite première valeur d’intensité 11 est détecté. Une période de silence est par exemple détectée lorsqu’une fonction sourdine (dite « mute ») est activée, cette fonction ayant pour effet de désactiver le microphone MIC1 (blocage de l’acquisition acoustique). Ainsi, le terminal client T1 ne demande un code de marquage numérique WT1 que si l’utilisateur UR1 ne parle pas lors de la conférence audio et/ou vidéo. Il est ainsi possible par exemple d’assister l’utilisateur UR1 lors de la conférence en lui indiquant à l’avance s’il va être bien entendu par le deuxième terminal client T2 dans le cas où il décide de parler. Cette variante peut aider à économiser les ressources de traitement et de réseau en ne réalisant un test de réception audio que pour prédire l’aptitude ou inaptitude du deuxième terminal client T2 à recevoir un flux de données audio avant même que le premier terminal client T1 n’émettre un flux de données audio.

Lors d’une étape B52 d’envoi, le premier terminal client T1 envoie ensuite le flux de données audio marquées FX1 au serveur de conférence SV1. Comme décrit par la suite, cet envoi B52 cause un envoi par le serveur de conférence SV1 , au deuxième terminal client T2, d’un flux de données audio marquées FX2 comprenant le flux de données audio marquées FX1. Le serveur de conférence SV1 reçoit le flux de données audio marquées FX1 au cours d’une étape A52 de réception.

Selon un exemple particulier, le premier terminal client T1 envoie également en B53 une notification NF2 informant de l’envoi B52 du flux de données audio marquées FX1 au serveur de conférence SV1 pour réaliser un test audio. Cette notification NF2, pouvant comprendre l’identifiant ID1 du premier terminal client T1 , est alors reçue au cours d’une étape D53 de réception. Comme décrit par la suite, la réception D53 de la notification NF2 peut marquer le cas échéant un instant de référence tO utilisé par la suite par le serveur de médiation SV2 lors du quatrième procédé.

Le serveur de conférence SV1 réalise ensuite un traitement (A54) à partir du flux de données audio marquées FX1 reçu en A52, et éventuellement à partir d’au moins un autre flux de données audio FX émis par un terminal client autre que le premier terminal client T1 , de sorte à produire un flux de données audio marquées FX2 comprenant le code de marquage numérique WT1. Dans cet exemple, on considère que le serveur de conférence SV1 décode chaque flux de données audio reçu (dont le flux FX1), mixe ou combine les données audio décodées et encode les données audio mixées de sorte à obtenir un flux de données audio marquées FX2 comprenant le code de marquage numérique WT1. Lors d’une étape A56 d’envoi, le serveur de médiation SV1 envoie le flux de données audio marquées FX2 au deuxième terminal client T2. Le deuxième terminal client T2 reçoit le flux de données audio marquées FX2 en C56 et détecte dans ce flux FX2 le code de marquage numérique WT1 en C58, de façon identique respectivement aux étapes C8 et C10 précédemment décrites (figure 5).

Comme déjà indiqué, le deuxième terminal client T2 peut restituer le flux de données audio marquées FX2 sous forme acoustique au moyen dans cet exemple du haut-parleur HP2, bien que des variantes soient possibles sans une telle restitution sonore. Si le deuxième terminal client T2 génère des signaux acoustiques à partir du flux audio FX2, alors le code de marquage numérique WT2 peut ne pas être perceptible pour l’utilisateur UR2 (le code WT2 n’est pas converti en son), de sorte que cela ne gêne pas l’écoute au cours de la conférence.

Lors d’une étape C60 d’envoi, le deuxième terminal client T2 envoie (de façon identique à l’envoi C12, figure 5) une notification NF1 indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1 , cette notification NF1 comprenant le code de marquage numérique WT1 en association avec l’identifiant ID2 du deuxième terminal client T2.

Le serveur de médiation SV2 reçoit la notification NF1 au cours d’une étape D62 de réception.

De façon identique à l’étape D14 (figure 5), le serveur de médiation SV2 détermine (D64) alors s’il a reçu une notification NF1 indiquant que le deuxième terminal client T2 a détecté le code de marquage numérique WT1. Comme déjà décrit, le serveur de médiation SV2 peut à cette fin consulter ses données de marquage DM et déterminer en D64 si la notification NF1 reçue comprend le code de marquage numérique WT1 associé à l’identifiant ID1 du premier terminal client T1 dans les données de marquage DM. Le deuxième terminal client T2 n’a donc pas besoin de connaître à quel autre terminal client est associé le code de marquage numérique WT1.

Dans certains modes de réalisation, comme dans cet exemple particulier, le serveur de médiation SV2 utilise un instant de référence tO pour déterminer en D64 si ladite notification NF1 est reçue dans un premier délai DL1 à compter de cet instant de référence tO. Cet instant de référence tO peut, par exemple, correspondre à la réception D53 de la notification NF2 envoyée le cas échéant par le premier terminal client T1 pour prévenir qu’un test audio est réalisé. Il est ainsi possible pour le serveur de médiation SV2 d’être informé lorsque (par exemple à chaque fois) que le premier terminal client T1 effectue un test audio. De multiples tests audio peuvent ainsi être réalisés au cours du temps par le premier terminal client T1 pour tester si l’utilisateur UR1 est, ou va être, bien entendu par le deuxième terminal client T2.

Selon une variante, le serveur de médiation SV2 est configuré pour connaître à l’avance un instant de référence tO au cours duquel le premier terminal client T1 réalise l’envoi B52 du flux de données audio marquées FX1. Selon une variante, le serveur de médiation SV2 utilise en tant qu’instant de référence tO un instant au cours duquel est réalisée l’une quelconque des étapes D42, D44, D46 et D48.

Le serveur de médiation SV2 détermine ainsi que le résultat de la détermination D64 est positif s’il détecte que la notification NF1 émise par le deuxième terminal client T2 est reçue avant expiration d’un premier délai DL1 à compter de cet instant de référence tO. Dans le cas contraire, le serveur de médiation SV2 détermine que le résultat de la détermination D64 est négatif.

Comme déjà décrit en référence à l’étape D16 (figure 5), le serveur de médiation SV2 peut déterminer (D66) ensuite, à partir d’un résultat de la détermination D64, des données de capacité audio DTA2 indiquant si le deuxième terminal client T2 est apte à recevoir un flux de données audio FX en provenance du premier terminal client T1. Plus précisément, si le résultat de la détermination D64 est positif, le quatrième procédé se poursuit à l’étape D66a, sinon le quatrième procédé se poursuit à l’étape D66b.

Lors de l’étape D66a, le serveur de médiation SV2 détermine, à partir du résultat positif de la détermination D64, des données de capacité audio DTA2 indiquant que le deuxième terminal client T2 est apte à recevoir un flux de données audio en provenance du premier terminal client T 1.

Lors de l’étape D66b, le serveur de médiation SV2 détermine, à partir du résultat négatif de la détermination D64, des données de capacité audio DTA2 indiquant que le deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio en provenance du premier terminal client T 1.

Le serveur de médiation SV2 envoie (D68) ensuite les données de capacité audio DTA2 au premier terminal client T1 comme déjà décrit en référence à l’étape D18 (figure 5). Le premier terminal client T 1 reçoit ainsi en B68 les données de capacité audio DTA2 envoyées par le serveur de médiation SV2. Le premier terminal client T1 peut alors réaliser les étapes D22 et D24 de façon identique aux étapes B20 et B22 comme précédemment décrit en référence à la figure 5.

Selon un exemple particulier, en cas de résultat négatif de la détermination D64 (pas de réception par le serveur de médiation SV2 de la notification NF1 ), le serveur de médiation SV2 peut en outre envoyer (D70) les données de capacité audio DTA2 au deuxième terminal T2 pour lui indiquer que son test de réception audio depuis le terminal client T1 vers le deuxième terminal client T2 a échoué. Le deuxième terminal client T2 reçoit alors les données de capacités audio DTA2 lors d’une étape C70 de réception. En réponse aux données de capacité audio DTA2, le deuxième terminal client T2 peut ainsi réaliser au moins une action de gestion, telle que par exemple restituer (C72a) au moyen de son interface utilisateur IU2 des informations IF2 indiquant l’échec du test de réception audio et/ou modifier (C72b) une configuration audio du deuxième terminal client T2 en vue si possible de résoudre le problème de réception audio. Ce changement de configuration audio peut comprendre par exemple une reconfiguration d’un équipement audio quelconque du deuxième terminal client T2. Un changement de configuration audio peut comprendre par exemple un changement d’une entrée audio utilisée par le deuxième terminal T2 pour recevoir des flux de données audio au cours de la conférence audio et/ou vidéo.

Selon un exemple particulier, le serveur de médiation SV2 exécute le quatrième procédé selon les étapes D2-D18 (figure 5) ou D42-D70 (figure 6) pour une pluralité de deuxièmes terminaux clients, par exemple en coopération avec chacun parmi les terminaux T2, T3 et T4, de sorte à envoyer en D68 au premier terminal client T1 des données de capacité audio DTA2, DTA3 et DTA4 caractérisant respectivement les deuxièmes terminaux clients T2, T3 et T4. En particulier, le serveur de médiation SV2 peut générer, et transmettre en D68 au premier terminal client T 1 , une matrice de capacité audio indiquant pour chaque deuxième terminal client T2-T4 s’il a détecté le code de marquage numérique WT 1 et donc s’il est apte à recevoir un flux de données audio FX émis par le premier terminal client T 1 au cours de la conférence audio et/ou vidéo.

Le premier terminal client T1 peut ainsi réaliser l’étape B22 (figures 5-6) en prenant en compte les données de capacité audio DTA2, DTA3 et DTA4. En particulier, le premier terminal client T1 peut restituer des informations IF1 indiquant si au moins un (par exemple chacun) des deuxièmes terminaux clients T2, T3 et T4 est apte à recevoir un flux de données audio émis par le premier terminal client T 1 durant de la conférence audio et/ou vidéo en cours. De cette manière, l’utilisateur UR1 peut savoir aisément si il est, ou sera, entendu par chacun des participants à la conférence audio et/ou vidéo. Comme déjà décrit précédemment, l’invention permet de tester la capacité d’un ou plusieurs deuxièmes terminaux clients à recevoir un flux de données audio émis par le premier terminal client lors d’une conférence audio et/ou vidéo. L’invention permet donc de limiter les risques que l’utilisateur UR1 ne parle sans être entendu par un autre participant à la conférence audio et/ou vidéo.

Toutefois, même si par exemple le deuxième terminal client T2 est effectivement capable de recevoir un flux de données audio FX émis par le premier terminal client T 1 , des problèmes liés aux équipements acoustiques du premier terminal client et/ou du deuxième terminal client peuvent faire obstacle dans la chaîne de transmission de communications audio depuis le microphone MIC1 du premier terminal client T 1 jusqu’au haut-parleur HP2 du deuxième terminal client T2. Dans ce cas, l’utilisateur UR1 n’a pas la garantie que l’utilisateur UR2 peut ou pourra l’entendre même si le deuxième terminal client T2 est capable de recevoir un flux de données audio émis par le premier terminal client T 1.

Aussi, selon un exemple, l’invention peut aussi comprendre un test acoustique d’au moins l’un parmi le premier terminal client T1 et le ou les deuxièmes terminaux clients T2-T4, afin de compléter les données de capacité audio DTA2 générées par le serveur de médiation SV2 (étapes D16 et D66, figures 5-6) avec des données de capacité acoustique DTB.

Selon un exemple représenté en figure 7, le premier terminal client T1 réalise un test acoustique du microphone MIC1 auquel il est couplé (et plus généralement un test de l’équipement acoustique du premier terminal client T1 ), en exécutant les étapes B80-B88 au cours du premier procédé tel que décrit en référence aux étapes B2-B24 (figure 5) ou aux étapes B40-B68 (figure 6). Ce test permet plus généralement de tester l’ensemble de la chaîne acoustique (incluant le haut-parleur HP1 et le microphone MIC1 ) du premier terminal client T 1 .

Plus particulièrement, le premier terminal client T 1 active (B80) son microphone MIC1 s’il n’est pas déjà actif, et peut éventuellement désactiver (B82) une fonction F1 d’annulation d’écho dans le cas où une telle fonction est active. Une fonction d’annulation d’écho est en effet susceptible de faire obstacle au bon déroulement du test acoustique du microphone MIC1. En particulier, l’annulation le cas échéant d’une fonction F1 d’annulation d’écho permet une bonne acquisition acoustique par le microphone MIC1 d’une émission (ou sortie) acoustique du haut-parleur HP1 couplé au premier terminal client T 1 . Lors d’une étape B84 de génération, le premier terminal client T1 génère un signal acoustique de test noté SA1 (figure 1) au moyen du haut-parleur HP1 . Pour cela, le premier terminal client T1 peut fournir en entrée du haut-parleur un quelconque flux de données audio de test, de sorte à produire un signal acoustique de test SA1 en sortie du haut-parleur HP1.

Le signal acoustique de test SA1 est de préférence un signal (émission sonore) inaudible à l’oreille humaine (par exemple dans les hautes fréquences) afin de ne pas gêner l’utilisateur UR1 lors de la conférence audible et/ou vidéo, mais peut éventuellement être un signal audible. Selon un exemple particulier, le signal acoustique de test SA1 est émis à une fréquence d’au moins 20 KHz. Il peut s’agir d’un signal mono-fréquence ou d’un signal sinusoïdal, bien que d’autres implémentations soient possibles. A titre d’exemple, le signal acoustique de test SA1 ainsi généré présente une fréquence d’échantillonnage d’au moins 44,1 KHz.

Le signal acoustique de test SA1 est également émis de préférence pendant un temps court (par exemple pendant une durée maximum de 250 ms), afin d’éviter de déranger éventuellement l’utilisateur UR1 et de sorte à économiser les ressources et accélérer autant que possible le processus de test acoustique tout en s’assurant que ce signal acoustique de test SA1 est détectable par le microphone MIC1.

Au cours d’une étape B86 d’acquisition d’acoustique, le premier terminal client T1 fait une acquisition acoustique au moyen du microphone MIC1 tandis que le haut-parleur HP1 émet le signal acoustique de test SA1 , de sorte à tenter de capter ce signal acoustique de test SA1. Le premier terminal client T 1 détermine (B88) alors, à partir d’un résultat de l’acquisition acoustique B86, des données de capacité acoustique DTB1 caractérisant des capacités acoustiques du microphone MIC1 (et plus généralement de l’équipement acoustique du premier terminal client T 1 ).

Plus particulièrement, selon un exemple, le premier terminal client T1 acquière en B86 un flux de données audio de test DA1 produit par le microphone MIC1 à partir d’un signal acoustique capté par ledit microphone. Le premier terminal client T 1 analyse (B86) ensuite, à partir du flux de données audio de test DA1 , un signal acoustique capté par le microphone MIC1. Le premier terminal client T1 peut en particulier comparer le signal acoustique capté d’une part, avec le signal acoustique de test SA1 généré en B84 d’autre part. A partir d’un résultat de cette comparaison, le premier terminal client T 1 évalue s’il y a correspondance entre le signal acoustique capté et le signal acoustique de test SA1. Les données de capacité acoustique DTB1 peuvent alors être fonction d’un degré de correspondance entre ces deux signaux. S’il y a correspondance, cela signifie que le microphone MIC1 (et plus généralement l’équipement acoustique du premier terminal client T1) est fonctionnel. Dans le cas contraire, cela signifie que le microphone MIC1 est susceptible d’être défectueux, ou tout du moins que l’équipement acoustique du premier terminal client T1 n’est pas fonctionnel.

Le premier terminal client T1 peut ainsi réaliser l’étape B22 de gestion (figures 5-6) en fonction également des données de capacité acoustique DTB1 obtenues en B88. Comme déjà indiqué, les informations IF1 restituées le cas échéant par le premier terminal client T1 lors de l’étape B24 de restitution peuvent être représentatives non seulement des données de capacité audio DTA2 reçues mais également des données de capacité acoustiques DTB1 du premier terminal client T 1. Selon un exemple, lors de l’étape B22 de gestion, le premier terminal client T1 peut transmettre au serveur de médiation SV2 les données de capacité acoustique DTB1 obtenues en B88. Le serveur de médiation SV2 peut alors transmettre également ces données de capacité acoustique DTB1 au deuxième terminal client T2, ou plus généralement à chaque deuxième terminal client T2-T4.

Le test acoustique (B80-B88, figure 7) peut être réalisé à divers stades du premier procédé mis en œuvre par le premier terminal client T1 (figures 5-6). Selon un exemple particulier, le premier terminal client T1 déclenche ce test acoustique sur détection de la réception B2 (figure 5) ou B46 (figure 6) du code de marquage numérique WT1 transmis par le serveur de médiation SV2, ou tout du moins avant l’étape B4 d’obtention (figure 5) ou l’étape B50 de génération (figure 6) du flux de données audio marquées FX1.

Une fois le test acoustique du premier terminal client T1 achevé, le terminal T1 peut réactiver le cas échéant la fonction F1 d’annulation d’écho, afin d’éviter d’éventuelles perturbations de l’acquisition acoustique du microphone MIC1 lors de la conférence audio et/ou vidéo.

Le premier terminal client T1 est par exemple configuré pour déclencher l’envoi B6 ou B52 du flux de données audio marquées FX1 que si le test acoustique B80-B88 est passé avec succès, c’est-à-dire s’il indique que le microphone MIC1 est fonctionnel. Ainsi, si le test acoustique du microphone MIC1 du premier terminal client T1 échoue, ce dernier ne poursuit pas le test audio, ou éventuellement sélectionne la technique d’émulation d’un bruit aléatoire telle que décrite précédemment pour générer en B50 (figure 6) le flux de données audio marquées FX1. Il est ainsi possible d’économiser les ressources des terminaux clients T 1 et T2, du réseau ainsi que celles du serveur de médiation SV2 en évitant d’exécuter inutilement un test audio à partir du premier terminal client T1 alors que même que son microphone MIC1 est susceptible d’être défectueux. Le recours à la technique de l’émulation peut aider en outre de s’assurer que le test audio est réalisé correctement alors même que le microphone MIC1 est susceptible d’être défectueux.

Selon un exemple représenté en figure 8, le premier terminal client T1 réalise un test acoustique du haut-parleur HP2 auquel il est couplé (et plus généralement un test de l’équipement acoustique du deuxième terminal client T2), en exécutant les étapes C100-C108 au cours du deuxième procédé tel que décrit en référence aux étapes C8-C12 (figure 5) ou aux étapes C40-C72 (figure 6). Ce test acoustique C100-C108 s’effectue de façon analogue au test acoustique B80-B88 du premier terminal client T1 tel que décrit précédemment. Ce test permet plus généralement de tester l’ensemble de la chaîne acoustique (incluant le haut-parleur HP2 et le microphone MIC2) du deuxième terminal client T2.

Plus particulièrement, le deuxième terminal client T2 active (C100) son microphone MIC2 s’il n’est pas déjà actif, et peut éventuellement désactiver (C102) une fonction F2 d’annulation d’écho dans le cas où une telle fonction est active. Une fonction d’annulation d’écho est en effet susceptible de faire obstacle au bon déroulement du test acoustique du haut-parleur HP2. En particulier, l’annulation le cas échéant d’une fonction F2 d’annulation d’écho permet une bonne acquisition acoustique par le microphone MIC2 d’une émission (ou sortie) acoustique du haut-parleur HP2 couplé au deuxième terminal client T2. Lors d’une étape C104 de génération, le deuxième terminal client T2 génère un signal acoustique de test noté SA2 (figure 1) au moyen du haut-parleur HP2. Pour cela, le deuxième terminal client T2 peut fournir en entrée du haut-parleur HP2 un quelconque flux de données audio de test, de sorte à produire un signal acoustique de test SA2 en sortie du haut-parleur HP2.

Le signal acoustique de test SA2 est de préférence un signal inaudible à l’oreille humaine (par exemple dans les hautes fréquences) afin de ne pas gêner l’utilisateur UR2 lors de la conférence audible et/ou vidéo, mais peut éventuellement être un signal audible. Selon un exemple particulier, le si signal acoustique de test SA2 est émis à une fréquence d’au moins 20 KHz. Il peut s’agir d’un signal monofréquence ou d’un signal sinusoïdal, bien que d’autres implémentations soient possibles. A titre d’exemple, le signal acoustique de test SA2 ainsi généré présente une fréquence d’échantillonnage d’au moins 44,1 KHz.

Le signal acoustique de test SA2 est également émis de préférence pendant un temps court (par exemple pendant une durée maximum de 250 ms), afin d’éviter de déranger éventuellement l’utilisateur UR1 et de sorte à économiser les ressources et accélérer autant que possible le processus de test acoustique, tout en s’assurant que ce signal acoustique de test SA2 est détectable par le microphone MIC2.

Lors d’une étape C106 d’acquisition acoustique, le deuxième terminal client T2 fait une acquisition acoustique au moyen du microphone MIC2 tandis que le haut-parleur HP2 émet le signal acoustique de test SA2, de sorte à tenter de capter ce signal acoustique de test SA2. Le deuxième terminal client T2 détermine (C108) alors, à partir d’un résultat de l’acquisition acoustique C106, des données de capacité acoustique DTB2 caractérisant des capacités acoustiques du haut-parleur HP2 (et plus généralement de l’équipement acoustique du deuxième terminal client T2).

Plus particulièrement, selon un exemple, le deuxième terminal client T2 acquière en C106 un flux de données audio de test DA2 produit par le microphone MIC2 à partir d’un signal acoustique capté par ledit microphone. Le deuxième terminal client T2 analyse (C106) ensuite, à partir du flux de données audio de test DA2, un signal acoustique capté par le microphone MIC2. Le deuxième terminal client T2 peut en particulier comparer le signal acoustique capté d’une part, avec le signal acoustique de test SA2 généré en C104 d’autre part. A partir d’un résultat de cette comparaison, le deuxième terminal client T2 évalue s’il y a correspondance entre le signal acoustique capté et le signal acoustique de test SA2. Les données de capacité acoustique DTB2 peuvent alors être fonction d’un degré de correspondance entre ces deux signaux. S’il y a correspondance, cela signifie que le haut-parleur HP2 (et plus généralement l’équipement acoustique du premier terminal client T1 ) est fonctionnel. Dans le cas contraire, cela signifie que le haut-parleur HP2 est susceptible d’être défectueux, ou tout du moins que l’équipement acoustique du deuxième terminal client T2 n’est pas fonctionnel.

Selon un exemple, le deuxième terminal client T1 peut transmettre au serveur de médiation SV2 les données de capacité acoustique DTB2 obtenues en C108. Le serveur de médiation SV2 peut alors transmettre également ces données de capacité acoustique DTB1 au premier terminal client T1 , ou plus généralement à chaque autre terminal client T1 , T3 et T4 participant à la conférence audio et/ou vidéo. Le premier terminal client T1 peut ainsi réaliser l’étape B22 de gestion (figures 5-6) en fonction également des données de capacité acoustique DTB2 reçues du serveur de médiation SV2. Comme déjà indiqué, les informations IF1 restituées le cas échéant par le premier terminal client T1 lors de l’étape B24 de restitution peuvent être représentatives également des données de capacité acoustiques DTB2 du deuxième terminal client T2.

Le test acoustique (C100-C108, figure 8) peut être réalisé à divers stades du deuxième procédé mis en œuvre par le deuxième terminal client T2 (figures 5-6). Une fois le test acoustique du deuxième terminal client T2 achevé, le terminal T2 peut réactiver le cas échéant la fonction F2 d’annulation d’écho, afin d’éviter d’éventuelles perturbations de l’acquisition acoustique du microphone MIC1 lors de la conférence audio et/ou vidéo.

Selon un exemple, chaque terminal client participant à la conférence audio et/ou vidéo peut déclencher un test acoustique de son propre équipement acoustique (dont son microphone et haut-parleur), par exemple lors de (ou en réponse à) l’établissement S2 (figure 6) de la session de communication auprès du serveur de conférence SV1. Dans ce cas, chaque terminal client envoie au serveur de médiation SV2 des données de capacités acoustiques DTB représentatives de ses propres capacités acoustiques. Les données de capacité acoustique obtenues par chaque terminal client peuvent ainsi être indicatives de la capacité dudit terminal client à : produire une émission (ou sortie) acoustique au moyen d’un microphone couplé audit terminal client, à partir d’un flux de données audio reçu en provenance du serveur de conférence audio et/ou vidéo SV1 ; et faire l’acquisition acoustique, au moyen d’un haut-parleur couplé audit terminal client, d’un signal acoustique.

Par ailleurs, tout ou partie du premier procédé tel que décrit ci-avant en référence notamment aux figures 5-6 peut être réitéré une pluralité de fois par le premier terminal client T1. Selon un exemple particulier, aux moins certaines des étapes B4-B22 (voire B2-B24) sont réitérées pendant la session de communication, de façon à vérifier plusieurs fois (par exemple périodiquement) si ledit au moins un deuxième terminal client T2-T4 est apte à recevoir un flux de données audio FX émis par le premier terminal client T1. Il est ainsi possible de monitorer au cours du temps les capacités audio d’un ou plusieurs deuxièmes terminaux T2-T4, notamment pendant que l’utilisateur UR1 du terminal client T1 parle ou qu’il est silencieux. La réitération périodique ou régulière du premier procédé peut permettre en particulier de surveiller de façon continue ou répétée la capacité d’un ou plusieurs deuxième terminaux à recevoir un flux de données audio émis par le premier terminal client T 1 .

A noter qu’il est possible de réitérer plusieurs fois le premier procédé de l’invention tout en utilisant le même code de marquage numérique WT1 , voire même en utilisant le même flux de données audio marquées FX1 (dans le cas par exemple d’un signal porteur émulé). On peut ainsi réaliser une pluralité de test audio tout en économisant les ressources nécessaires. En variante, le terminal client T1 utilise au moins deux codes de marquage numérique WT1 distincts pour mettre en œuvre une pluralité d’itérations du premier procédé. Le changement du code de marquage numérique WT1 au cours de plusieurs itérations du premier procédé peut aider à permettre d’assurer une meilleure robustesse du test audio (par exemple une meilleure sécurité du processus de test en cas d’interception et utilisation non autorisée d’un code de marquage numérique par un tiers, une possibilité d’utiliser plusieurs types de code de marquage différents pour plus de flexibilité, etc.).

Comme déjà indiqué en référence à la figure 5, le deuxième terminal client T2 peut notamment modifier sa configuration audio sur réception de données de capacité audio DTA2 indiquant que ledit deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio émis par le premier terminal client T 1. Selon un exemple particulier, le premier terminal client T 1 réalise les étapes suivantes pour chacune parmi une pluralité de configurations audio, tant qu’une première condition audio n’est pas satisfaite : configuration du premier terminal client T 1 selon ladite configuration audio; et réitération d’au moins un partie du premier procédé tel que précédemment décrit (étapes B2-B24).

De même, comme déjà indiqué en référence à la figure 6, le deuxième terminal client T2 peut notamment modifier sa configuration audio sur réception de données de capacité audio DTA2 indiquant que ledit deuxième terminal client T2 n’est pas apte à recevoir un flux de données audio émis par le premier terminal client T1. Selon un exemple particulier, le deuxième terminal client T2 réalise les étapes suivantes pour chacune parmi une pluralité de configurations audio, tant qu’une deuxième condition audio n’est pas satisfaite : configuration du deuxième terminal client T2 selon ladite configuration audio; et réitération d’au moins une partie des étapes C56-C72 du deuxième procédé (figure 6).

Les premier et/ou deuxième terminaux clients peuvent ainsi tester chaque configuration audio possible jusqu’à obtenir un test audio positif.

Selon un exemple particulier, chaque terminal client T1-T4 (agissant en tant que premier terminal client) peut ainsi mettre en œuvre le premier procédé tel que précédemment décrit en référence aux figures 5-8 de sorte à tester la capacité de chaque autre terminal client (agissant en tant que deuxième terminal client) à recevoir un flux de données audio émis par ledit terminal client. Le serveur de médiation SV2 peut par exemple générer une matrice de capacité comprenant des données de capacité audio DTA associées à chaque terminal client, ces données indiquant si un flux audio émis par ledit terminal client est apte à être reçu par chaque autre terminal client. Cette matrice de capacité peut éventuellement aussi comprendre des données de capacité acoustique DTB caractérisant des capacités acoustiques de chaque terminal client. Autrement dit, cette matrice de capacité peut être obtenue en complétant la matrice de capacité audio précédemment décrite avec les données de capacité acoustique DTB des terminaux clients.

Le serveur de médiation SV2 peut en outre transmettre cette matrice de capacité à au moins un (par exemple chaque) terminal client T1-T4 afin que celui-ci gère la conférence audio et/ou vidéo en adaptant son fonctionnement en conséquence.

A noter d’autre part que l’ordre dans lequel s’enchaînent les étapes des différents procédés décrits ci- avant ne constitue que des exemples de réalisation non limitatifs, des variantes étant possibles.

Un homme du métier comprend que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l’invention. En particulier, l’homme du métier peut envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci- avant, afin de répondre à un besoin bien particulier conformément aux revendications présentées ci- après.