Procédé et dispositif de synchronisation de flux de données
La présente invention concerne un procédé et un dispositif de synchronisation de flux de données.
Plus précisément, l'invention concerne le domaine de la synchronisation d'au moins deux flux, par exemple et de manière non limitative un flux de données audio et un flux de données vidéo. Un des flux est véhiculé sur un réseau de télécommunication asynchrone de paquets, au moins un autre des flux est véhiculé sur un réseau de télécommunication synchrone.
Sont connus les dispositifs de transfert de données audio et vidéo sur un même réseau de télécommunication. L'échange de flux de données entre des visiophones sur un réseau de télécommunication de type RTC permet aux possesseurs de tels visiophones de pouvoir communiquer par la voix et l'image avec leur correspondant si celui-ci bien sûr possède un terminal équivalent.
Le transfert de l'image sur un réseau commuté nécessite néanmoins une forte réduction de la qualité de l'image transmise. Ceci pénalise l'utilisation de tels services.
CQPΕ DE €OWFMATtûi
Beaucoup de personnes à travers le monde possèdent des ordinateurs reliés à un réseau tel que le réseau Internet, d'où l'intérêt croissant d'utiliser le réseau Internet comme médium de transmission de flux de données audio vidéo pour des applications de visioconférence. La nature même du réseau Internet fait que celui-ci n'est pas adapté à la transmission de données temps réel. Ce réseau ne garantissant pas une qualité de service, la qualité de transmission reste imparfaite.
Des protocoles tels que le protocole de transmission temps réel de type RTP (Real Time Protocol) et le protocole de contrôle de transmission temps réel RTCP (Real Time Transfert Control Protocol) tentent de résoudre les problèmes liés à l'utilisation du réseau Internet comme médium de transmission.
Le protocole RTP fournit un moyen uniforme de transmission de données soumises à des contraintes temps réel. Il permet d'identifier le type de l'information transportée, d'ajouter des marqueurs temporels ainsi que des numéros de séquences aux informations qu'il transporte. Lorsque des données multimédia sont transmises selon le protocole RTP, un canal RTP est établi pour chacun des flux vidéo et audio pour chaque sens de transmission entre les correspondants. En effet, le protocole RTP est destiné à ne transporter qu'un seul type d'information à la fois.
Le multiplexage, le démultiplexage et la synchronisation des flux audio et vidéo est quant à lui effectué au niveau de l'application destinataire des flux audio et vidéo.
Le protocole RTCP permet de contrôler les flux de données échangés selon le protocole RTP. Il permet aussi de véhiculer des informations sur la qualité de service des flux de données échangés avec le protocole RTP.
Ces protocoles RTP et RTCP ne garantissent néanmoins pas la qualité de service.
Sont connus les procédés de transfert de données audio et vidéo dans lesquels le signal audio est transmis sur un réseau téléphonique tandis que la vidéo est transmise par l'intermédiaire du réseau Internet. Ceci est particulièrement le cas lorsque deux correspondants sont en communication téléphonique et échangent en même temps des informations vidéo capturées par leurs caméras vidéo (webcam) de leurs ordinateurs.
Le problème lié à ces transferts de données utilisant différents médiums de transmission est un manque de synchronisation à la réception des données.
Ce problème est d'autant plus important si les abonnées utilisent deux dispositifs différents indépendants l'un de l'autre pour recevoir les flux de données vidéo et les flux de données audio.
L'invention a pour but de résoudre les inconvénients de l'art antérieur en proposant un dispositif de synchronisation d'un flux multimédia constitué de deux flux multimédia distincts dans un réseau de télécommunication constitué d'un réseau de télécommunication synchrone et d'un réseau de télécommunication asynchrone, un desdits flux transitant sur le réseau de télécommunication asynchrone, l'autre flux transitant sur le réseau de télécommunication synchrone, caractérisé en ce que le dispositif comporte :
- des moyens pour obtenir des informations de délai représentatives du délai de transmission du flux transitant sur le réseau asynchrone,
- des moyens pour modifier le délai de transmission du flux multimédia transitant sur le réseau synchrone à partir des informations de délai obtenues. Corrélativement, l'invention propose un procédé de synchronisation d'un flux multimédia constitué de deux flux multimédia distincts dans un réseau de télécommunication constitué d'un réseau de télécommunication synchrone et d'un réseau de télécommunication asynchrone (160, 260), un desdits flux transitant sur le réseau de télécommunication asynchrone, l'autre flux transitant sur le réseau de télécommunication synchrone, caractérisé en ce que le procédé comporte les étapes de :
- obtention d'informations de délai représentatives du délai de transmission du flux transitant sur le réseau asynchrone,
- modification du délai de transmission du flux multimédia transitant sur le réseau synchrone à partir des informations de délai obtenues.
Ainsi, l'invention en utilisant deux réseaux différents et leurs spécificités respectives permet de transférer un flux multimédia tout en garantissant par la synchronisation une qualité de réception optimale.
Nous entendons par réseau de télécommunication synchrone, un réseau qui garantit le délai de transmission des données transmises sur ce réseau. Une partie de ce réseau de télécommunication synchrone peut être constituée d'un réseau de télécommunication asynchrone auquel sont associés des moyens de contrôle du délai de réception des données. Ceci est par exemple le cas d'un réseau téléphonique fixe de la société France Télécom.
Plus précisément, le réseau de télécommunication asynchrone est relié à un dispositif informatique comportant au moins une application client-client recevant un flux de données vidéo et le réseau de télécommunication synchrone est relié à un combiné téléphonique recevant un flux de données audio. Ainsi, une personne habituée à utiliser son combiné téléphonique pour communiquer n'a pas à modifier ses habitudes. En effet, il est difficile pour un individu de parler en face d'un dispositif informatique, le même individu est par contre habitué à se placer devant un dispositif informatique pour visualiser des informations telles que des flux vidéo. De plus, les personnes utilisant des systèmes tels que les visiophones préfèrent en premier lieu établir une communication téléphonique avant de doubler la communication par un flux vidéo.
Le dispositif selon l'invention permet aussi de synchroniser des flux audio et vidéo reçus par différents dispositifs sans que ces mêmes dispositifs soient reliés entre eux ou échangent des informations. Les dispositifs informatiques ainsi que les combinés téléphoniques n'ont pas besoin d'être modifiés pour permettre la réalisation de l'invention.
Plus particulièrement, les informations représentatives du délai de transmission du flux transitant sur le réseau asynchrone sont obtenues à partir de paquets de contrôle du flux de données vidéo transitant sur le réseau asynchrone.
Ainsi, la synchronisation est effectuée de façon simple, seuls les paquets de contrôle sont utilisés pour la synchronisation et ainsi le dispositif de synchronisation est simplifié.
Plus précisément, on obtient les informations représentatives du délai de transmission du flux transitant sur le réseau asynchrone en mémorisant les instants de réception des paquets de contrôle du flux de données vidéo transitant sur le réseau asynchrone, en lisant au moins un champ prédéterminé des paquets de contrôle du flux de données vidéo et en calculant le délai à partir des instants mémorisés et du au moins un champ prédéterminé lu. Ainsi, la synchronisation est effectuée de façon simple.
Avantageusement, on modifie le délai de transmission du flux transitant sur le réseau synchrone en mémorisant les données du flux audio transitant sur le réseau synchrone, en déterminant l'adresse de lecture des données à partir des informations
obtenues et en transférant, à partir de l'adresse déterminée, les données mémorisées sur le réseau synchrone à destination du combiné téléphonique.
Ainsi, la synchronisation du flux audio est réalisée de façon simple par une détermination d'adresse de lecture mémoire des données du flux audio mémorisées. Avantageusement, on reçoit des paquets de contrôle du flux de données vidéo transitant sur le réseau asynchrone et on génère des paquets de contrôle du flux de données vidéo transitant sur le réseau asynchrone.
Plus précisément, le dispositif de synchronisation comporte des moyens de réception d'au moins un appel issu d'un combiné téléphonique, des moyens d'obtention d'au moins un identifiant d'un combiné téléphonique avec lequel le combiné téléphonique appelant désire établir une communication téléphonique et des moyens de mise en correspondance du dispositif informatique associé à l'utilisateur associé au combiné téléphonique appelant avec le dispositif informatique associé à l'utilisateur au combiné téléphonique avec lequel le combiné téléphonique appelant désire établir une communication téléphonique.
Ainsi, l'utilisateur n'a pas besoin de connaître l'adresse électronique du dispositif informatique de son correspondant, seul le numéro de téléphone de celui-ci a besoin d'être connu.
Les avantages des procédés étant identiques à ceux mentionnés pour les dispositifs, ceux-ci ne seront pas rappelés.
L'invention concerne aussi le programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant de mettre en œuvre le procédé de traitement précédemment décrit, lorsqu'il est chargé et exécuté par un système informatique. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels: la Fig. 1 représente un premier mode de réalisation de l'invention dans un réseau de télécommunication comportant une architecture nœud de service ; la Fig. 2 représente l'algorithme d'enregistrement au service tel que fourni par l'invention dans le réseau de télécommunication ; la Fig. 3 représente un algorithme décrivant la cinématique d'activation d'une application de type client-client en parallèle d'une communication téléphonique ;
la Fig. 4 représente un paquet de rapport émetteur RTCP SR conforme au protocole RTCP ; la Fig. 5a représente un algorithme décrivant la détermination du retard sur le réseau de télécommunication par paquet selon le premier mode de réalisation de l'invention ; la Fig. 5b représente un algorithme décrivant l'application du retard sur les flux vocaux téléphoniques effectué par le module de gestion vocale et retard ; la Fig. 6 représente un second mode de réalisation de l'invention dans un réseau de télécommunication comportant une architecture nœud de service dans le cadre d'un service de mise en relation d'abonnés en conférence ; la Fig. 7 représente un algorithme décrivant la cinématique d'activation d'une conférence téléphonique entre trois abonnés, couplée avec une application de type client-client gérée dans le cadre d'une architecture de type nœud de service ; la Fig. 8 représente un algorithme décrivant la détermination du retard sur le réseau de télécommunication par paquets selon le second mode de réalisation de l'invention.
La Fig. 1 représente un premier mode de réalisation de l'invention dans un réseau de télécommunication comportant une architecture service node. Dans une architecture service node (nœud de service), le serveur se connecte au réseau de la même manière qu'un terminal d'un abonné.
Le réseau de télécommunication comprend un fournisseur de services d'applications ASP noté 190 qui est par exemple associé à un opérateur de télécommunication 140, un réseau téléphonique commuté 141, un réseau de téléphones mobiles 148, de type GSM acronyme de Global System Mobile ou de type UMTS acronyme de Universal Mobile Télécommunication System, un réseau ISP 150 (fournisseur de services Internet) et un réseau Internet public 160.
Le réseau téléphonique commuté 141, le réseau de téléphones mobiles 148, de type GSM acronyme de Global System Mobile ou de type UMTS acronyme de Universal Mobile Télécommunication System constituent le réseau de télécommunication synchrone.
Le réseau Internet public 160 est ici le réseau de télécommunication asynchrone.
Le réseau téléphonique commuté 141 est associé à un commutateur à autonomie d'acheminement CAA noté 142 permettant la fourniture du service téléphonique classique à un abonné 100.
Le réseau téléphonique commuté 141 est relié au réseau de téléphones mobiles 148.
Le fournisseur de services d'applications ASP 190 comprend un réseau local 184.
Le réseau local 184 est aussi relié au réseau public Internet 160 au travers d'un routeur Firewall 185 assurant aussi la sécurité des échanges d'informations entre les réseaux 184 et 160 tout en veillant à ce qu'aucune intrusion ne puisse être effectuée dans le réseau 184.
A ce réseau local 184, est connecté un serveur 170. Le serveur 170 est aussi connecté au réseau téléphonique 141 via le commutateur à autonomie d'acheminement 142. Le serveur 170 est soit centralisé sur un seul dispositif, soit réparti sur différents dispositifs placés ou non sur un même site.
Le serveur 170 est constitué d'une base de données du service 171 dans laquelle sont mémorisées des informations nécessaires à l'exécution des services selon l'invention. Ces informations sont, par exemple et de manière non limitative, des informations mémorisées de manière permanente telles que les profils d'abonnement des abonnés aux services selon l'invention.
La base de données 171 comporte aussi des informations temporaires liées aux sessions des abonnés. Ces informations sont, par exemple et de manière non limitative, le/les numéros de téléphone associés au service, l'adresse Internet des ordinateurs des abonnés, les numéros de port des applications client-client dont les ordinateurs des abonnés disposent.
Le serveur 170 comporte aussi un module d'enregistrement 172 des logiciels clients des abonnés au service. Ces logiciels clients seront décrits ultérieurement.
Le serveur 170 comporte aussi un module 173 de notification d'événements réseaux et d'informations des logiciels clients 107 et 124.
Le serveur 170 comporte aussi une interface IP 178 de type Ethernet permettant au serveur 170 de se connecter avec le réseau local 184.
Le serveur 170 comporte un module automate d'appels 179 qui traite la signalisation des appels téléphoniques entrants et sortants.
Le serveur 170 comporte une interface téléphonique RTC 180 de type ISUP (protocole de signalisation utilisateur RNIS), RNIS étant l'acronyme de Réseau Numérique à Intégration de Services qui permet la connexion du serveur 170 avec le réseau téléphonique 141 via le CAA 142 de l'opérateur de télécommunication 140.
Il est à remarquer que l'interface 180 peut être aussi une interface conforme à la norme SS7 (code de signalisation 7).
Le serveur 170 comporte aussi un module 181 de gestion des flux vocaux téléphoniques RTC permettant une mise en correspondance des canaux média de la communication téléphonique entrante et de la communication téléphonique sortante. Le module 181 permet aussi la génération de retard entre les flux vocaux entrants et les flux vocaux sortants, ces retards pouvant être différents selon le sens de la communication. Le serveur 170 comporte aussi un module 183 appelé proxy utilisé par les applications de type client-client (voire de type client-serveur).
De manière générale, un proxy est un serveur qui fait office d'interface entre un abonné et un autre abonné distant. Le proxy fait suivre les messages générés par l'abonné au destinataire. Le destinataire répond au proxy comme si celui-ci était générateur du message. Le proxy fait alors suivre la réponse à l'abonné.
Les flux de signalisation ainsi que les flux de contrôle des médias selon le protocole Internet vont transiter par ce module. Selon un mode particulier, et pour des aspects de performance, les flux média IP selon le protocole Internet peuvent ne pas emprunter le module 183. Par exemple, le module 183 peut traiter plusieurs types d'applications telles que des flux vidéo codés selon les formats H323 ou SIP.
Le serveur 170 comporte aussi un module 182 d'analyse des paquets de contrôle des flux média IP transitant à travers le module 183.
A titre d'exemple, si la communication de données est de type vidéo sur IP, les paquets média vidéo transportés selon le protocole RTP (protocole de transport en temps réel) peuvent ou non transiter par le proxy IP 183.
Les paquets de contrôle des paquets média vidéo conformes au protocole RTCP (protocole de contrôle de transport en temps réel) transitent par le proxy 183 adapté à cette application vidéo.
Le module d'analyse des paquets de contrôle des flux média extrait les paquets de contrôle RTCP et analyse leur contenu.
Parmi les informations, on peut trouver pour chaque sens de la communication, le délai de transmission, le taux de perte de paquets, le débit et la gigue. Avec ces informations, le retard généré par le module de retard vocal 181 est adapté.
L'abonné 100 dispose d'équipements tels qu'un combiné téléphonique 103, fixe ou mobile, connecté directement ou par l'intermédiaire d'un autocommutateur 102 au réseau téléphonique commuté 141 par l'intermédiaire d'un CAA 142. II est à remarquer que le numéro de téléphone peut être le numéro de téléphone d'un combiné téléphonique 103 placé sur le même site que le dispositif informatique ou sur un site différent.
L'abonné 100 dispose en outre d'un ordinateur 104 connecté à un réseau local 105. Le réseau local 105 est relié à un réseau de type Internet 160 par l'intermédiaire d'une passerelle 106 ou routeur Firewall apte à assurer le routage des données dans le réseau 105 et à assurer la fonction de passerelle entre le réseau 105 et le réseau Internet 160. Il est à remarquer que le routeur Firewall 106 peut assurer la sécurité des échanges d'informations entre les réseaux 105 et 160 en veillant à ce qu'aucune intrusion ne puisse être effectuée dans le réseau 105. L'ordinateur 104 dispose dans sa mémoire des programmes aptes à mettre en œuvre l'invention. Il comporte des logiciels 107, et 110.
Les logiciels 110 sont des applications de type client-client qui dialoguent avec un ordinateur 123 par l'intermédiaire du réseau local 105, du routeur Firewall 106, du réseau Internet 160, du routeur 151, du réseau ISP 150 et d'un modem 121. Le logiciel 107 dit logiciel client est le logiciel qui dialogue avec le serveur 170 selon l'invention et propose l'activation d'une ou plusieurs applications client-client 110 à l'abonné 100 ou active automatiquement une application client-client.
L'abonné 120 dispose d'équipements tels qu'un combiné téléphonique mobile 122 connecté au réseau mobile 148. L'abonné 120 dispose en outre d'un ordinateur 123 connecté par l'intermédiaire d'un modem 121, au réseau Internet 160 par l'intermédiaire du réseau 150 de son fournisseur de services Internet, et d'un routeur 151.
Le modem 121 est un modem classique de type RTC ou RNIS. Le modem 121 peut aussi être un modem de type ADSL (Asynchronous Digital Subscriber Line) ou
un dispositif de télécommunication permettant le transfert d'informations sur le câble ou réseau de diffusion par satellite voire un réseau Wifi (réseau local sans fils à haut débit).
L'ordinateur 123 dispose dans sa mémoire des programmes 124 et 127 aptes à mettre en œuvre l'invention et offrant les mêmes fonctionnalités que les logiciels respectifs 107 et 110 présents sur l'ordinateur 104 de l'abonné 100.
La Fig. 2 représente l'algorithme d'enregistrement au service tel que fourni par l'invention dans le réseau de télécommunication.
Un abonné au service, par exemple l'abonné 100 de la Fig. 1, souhaite établir le couplage téléphonique/données selon 1 ' invention.
Pour cela, l'ordinateur 104 de l'abonné 100 exécute le programme logiciel client 107.
L'ordinateur 104 se connecte par l'intermédiaire du réseau local 105, du routeur Firewall 106, du réseau Internet public 160, du routeur Firewall 185 et du réseau local 184 au module d'enregistrement client 172 du serveur 170 de l'ASP 190.
Le programme logiciel client 107 demande à l'étape E100 son enregistrement auprès du module d'enregistrement logiciel client 172.
Pour se faire, le logiciel client 107 fournit au module d'enregistrement client 172, son nom d'utilisateur, le mot de passe associé au nom de l'utilisateur précédemment attribué lorsque l'abonné 100 s'est inscrit au service. Le logiciel client 107 fournit aussi l'adresse IP (adresse protocole Internet) de l'ordinateur 104, le ou les numéros de téléphone du ou des combinés téléphoniques utilisés pour accéder au service.
Il est à remarquer que le numéro de téléphone peut être le numéro de téléphone d'un combiné téléphonique 103 placé sur le même site que le dispositif informatique ou sur un site différent.
Le logiciel client 107 fournit aussi son profil d'utilisateur, c'est-à-dire le numéro de ports des applications de type client-client 10 dont il dispose.
Il est à remarquer que, en variante, le profil de l'utilisateur peut aussi être réalisé de façon prédéterminée par l'ASP 190 fournissant le service. Le logiciel client 107, dans cette variante, n'a plus à fournir le profil d'utilisateur, celui-ci étant créé par l'ASP 190 et mémorisé dans la base de données 171 du serveur 170.
Le module enregistrement logiciel client 172 du serveur 170 interroge la base de données 171 du serveur 170 à l'étape E101 afin de l'authentifier. Cette authentification
est effectuée en vérifiant si le nom de l'utilisateur est reconnu comme client et si son mot de passe est correct. Dans la négative, la connexion est rejetée, le programme s'arrête.
Dans l'affirmative, le module enregistrement logiciel client 172 confirme au logiciel client 107 l'enregistrement à l'étape El 02.
A la confirmation de l'enregistrement, le serveur 170 active une procédure de vérification périodique du maintien de la connexion de l'ordinateur 104 au réseau Internet public 160.
Périodiquement, le module de notification d'événements réseaux et d'informations des logiciels clients 173 transmet une requête à l'étape E103 au logiciel client 107. Tant que l'ordinateur 104 est toujours connecté au réseau 160 et le logiciel client 107 est toujours actif, le logiciel client 107 répond à la requête en envoyant au module de notification d'événements réseaux et d'informations des logiciels clients 173, à l'étape El 04, un message de confirmation d'activité. Le module de notification d'événements réseaux et d'informations des logiciels clients 173 vérifie, après avoir attendu un délai prédéterminé, la réception du message à l'étape El 05, et en cas de confirmation, retourne à l'étape El 03.
A la non-réception d'une réponse à une requête transmise à l'étape El 03, le module de notification d'événements réseaux et d'informations des logiciels clients 173 arrête la session en cours.
Selon un mode particulier, la connexion entre le logiciel client 107 et le serveur de l'invention 170 n'est pas permanente. Une connexion de type TCP (protocole de contrôle transport) est établie à l'initiative du logiciel client 107 lors de la phase d'enregistrement et est libérée de manière à partager au mieux les ressources entre l'ensemble des abonnés.
Ainsi, lorsqu'une notification par le serveur 170 doit être transmise au logiciel client 107, le serveur 170 établit une connexion TCP vers le logiciel client 107.
Selon une autre variante, le procédé utilise le protocole UDP (User Data Protocol) plus rapide que le protocole TCP. Dans ce cas, afin de pallier aux problèmes de fiabilité du protocole UDP, le logiciel client 107 et le serveur 170 doivent garantir cette fiabilité en générant des messages de confirmation.
La Fig. 3 représente un algorithme décrivant la cinématique d'activation d'une application de type client-client en parallèle d'une communication téléphonique.
Selon cette application, l'activation de l'application client-client est gérée par une architecture de type service node, avec passage de la signalisation, des flux média et des flux de contrôle des flux média de l'application client-client au travers d'un module proxy 183. Dans cet exemple, l'application IP est synchronisée avec l'application vocale téléphonique en effectuant une mesure du retard sur le réseau IP et en appliquant un retard similaire sur le flux vocal véhiculé par le réseau RTC.
Préalablement à un appel téléphonique, l'abonné 100 s'enregistre au service tel que fourni par l'invention dans le réseau conforme au premier mode de réalisation.
Pour cela, l'ordinateur 104 de l'abonné 100 exécute le programme logiciel client 107.
L'ordinateur 104 se connecte par l'intermédiaire du réseau local 105, du routeur Firewall 106, du réseau Internet public 160, du routeur 185 et du réseau local 184 au module d'enregistrement client 172 du serveur 170 de l'ASP 190.
Le programme logiciel client 107, le module enregistrement logiciel client 172 du serveur 170 exécutent l'algorithme d'enregistrement tel que décrit précédemment en référence à la Fig. 2.
L'enregistrement effectué, l'abonné 100 décroche, à l'étape E300, son terminal téléphonique 103 et compose le numéro de téléphone du service permettant le couplage téléphonie-application de données. Ce numéro de téléphone est associé à l'interface téléphonique 180.
Un message de demande d'établissement d'appel téléphonique est transmis à l'étape E301 vers le module automate d'appel 179.
Le module automate d'appel 179 accepte automatiquement l'appel téléphonique entrant à l'étape E302. En variante, le module automate d'appel 179 génère un message "Alerte", voire un message préalablement au message "Connexion" à destination du terminal téléphonique 103.
Le module automate d'appel 179, afin de vérifier si le logiciel client 107 de l'abonné 100 est enregistré au niveau du serveur 170, génère une requête à l'étape E303 à la base de données 171 utilisant le numéro de téléphone appelant en tant que clé de recherche.
Le logiciel client 107 étant enregistré, l'automate d'appel 179 demande l'activation du module gestion vocale et retard 181 à l'étape E304.
Le module de gestion vocale et retard 181 étant activé à l'étape E305, l'automate d'appel 179 demande la diffusion, par le module gestion vocale et retard 181, d'une annonce vocale à l'étape E306 lui demandant de saisir le numéro de téléphone 122 de son correspondant 120 en utilisant la numérotation à fréquence vocale de son combiné 103.
Il est à remarquer que si le logiciel client 107 n'a pas été enregistré au préalable, l'annonce vocale demande d'abord à l'appelant d'activer son logiciel client 107, et ensuite de saisir le numéro de téléphone 122 de son correspondant 120.
Suite à la saisie du numéro de téléphone de l'abonné 120, par l'abonné 100 à l'étape E307, le numéro est communiqué au module automate d'appel 179.
Le module automate d'appel 179 demande, à l'étape E308, au module gestion vocale et retard 181 de diffuser à l'étape E309 un message d'attente vers l'appelant 100.
Le module automate d'appel 179 interroge, à l'étape E310, la base de données 171, en lui fournissant comme clé primaire le numéro de téléphone de l'appelé 120, afin de vérifier si le logiciel client 124 est enregistré.
Après confirmation, à l'étape E311, le module automate d'appel 179, établit un appel téléphonique sortant à destination de l'abonné 120 sur son téléphone 122 par l'intermédiaire du CAA 142 et des réseaux 141 et 148. Lorsque l'abonné 120 prend la communication à l'étape E312, le module automate d'appel 179 notifie, à l'étape E313, le module de gestion vocale et retard 181 afin que celui-ci diffuse, à la même étape, une annonce vocale à l'abonné 120.
Cette annonce vocale indique à l'appelé 120 que l'appelant 100 souhaite le joindre par téléphone avec une mise en oeuvre d'une application client-client en parallèle.
Si l'appelé 120 accepte la communication, et si le logiciel client 124 de l'abonné 120 n'est pas enregistré avec le serveur 170, le message vocal demande également lors de l'étape E313 à l'appelé 120 d'activer son logiciel client 124.
L'abonné 120 active, à l'étape E314, son logiciel 124 de la même manière que celle décrite pour l'abonné 100 à la seule différence que l'opération est effectuée par l'intermédiaire de son ISP 150 et du routeur 151.
Une fois le message diffusé vers l'appelé 120, le message d'attente côté abonné 100 est arrêté et les flux vocaux sont mis en correspondance sans application de retard à l'étape E315.
Le module de notification logiciel client 173 transfère à l'étape E316 au logiciel client 124 les notifications suivantes : numéro de téléphone de l'abonné 100, numéro de téléphone de l'abonné 120, adresse IP de l'ordinateur 104, le ou les numéros de ports des applications client-client 110 de l'abonné 100 compatibles avec celles de l'abonné 120 et/ou l'adresse IP du proxy 183, le ou les numéros de ses ports compatibles avec les applications.
En variante, le module de notification d'événements réseaux et d'informations des logiciels clients 173 transfère à l'étape E316 au logiciel client 124 les numéros de ports des applications client-client 110 présentes sur l'ordinateur 104 de l'abonné 100.
Après réception de la notification d'événements émise par le module de notification logiciel client 173 à l'étape E316, le logiciel client 124 vérifie à l'étape E317 en utilisant sa configuration locale stockée sur l'ordinateur 123 la liste des actions à effectuer. Le logiciel client 124 affiche sur l'écran de l'ordinateur 123 à la même étape
E317 la liste des actions possibles, par exemple affiche une invitation à activer une application de type client client "Activer Microsoft Netmeeting H323", et/ ou activer " FTR&D eConf SIP".
Si conformément à la variante précédemment mentionnée, le module de notification d'événements réseaux et d'informations des logiciels clients 173 a transféré à l'étape E316 au logiciel client 124 les numéros de ports des applications client-client présentes sur l'ordinateur 104 de l'abonné 100, le logiciel client 124 vérifie en outre si les numéros de ports des applications client-client 127 sont compatibles avec les numéros de ports des applications client-client 110 présentes sur l'ordinateur 104 de l'abonné 100. Lorsqu'une compatibilité existe, le logiciel client 124 effectue par exemple des actions conditionnelles aux numéros de ports compatibles.
Bien entendu, les applications client-client 127 compatibles avec les applications client-client 110 peuvent être activées automatiquement. Cette opération effectuée, l'application client-client 127 se met en attente d'appel sur le/les ports TCP/UDP de l'ordinateur 123 attribué(s) à ce type d'application. C'est par exemple le port TCP 1720 pour les applications conformes au format H323 ou le port TCP/UDP 5060 pour les applications de type SIP.
Il est à remarquer que l'adresse IP de l'ordinateur 104 et/ou l'adresse IP du proxy 183 précédemment reçue permet de filtrer les appels entrants d'autres ordinateurs que l'ordinateur 104.
Parallèlement à la confirmation d'enregistrement côté appelé 120, le module d'enregistrement logiciel client 172 informe le module de notification logiciel client 173 de la confirmation à l'étape E318. Ce dernier transmet à l'étape E319 au logiciel client 107 les informations suivantes : événements téléphoniques "Connexion" avec les arguments numéro de téléphone de l'appelant, numéro de téléphone de l'appelé, le/les numéros de ports des applications client-client compatible(s) entre l'appelant et l'appelé et la/les adresses IP du/des proxy IP 183 compatible(s) avec la/les applications client-client et ou l'adresse IP de l'ordinateur 123.
A la réception de ces informations, le logiciel client 107 vérifie, en utilisant sa configuration locale stockée sur l'ordinateur 104, la liste des actions à effectuer.
A l'étape E320, le logiciel client 107 affiche sur l'écran de l'ordinateur 104 la liste des actions possibles, par exemple affiche une invitation à activer une application de type client-client "Activer Microsoft Netmeeting H323", et/ ou activer " FTR&D eConf SIP". Il est à remarquer aussi que l'activation de l'application peut être automatique.
L'application logiciel client-client 110 activée, celle-ci émet à l'étape E321 une requête dépendant du protocole de l'application client-client 110 (par exemple envoi d'un message SETUP H323) vers le proxy compatible 183.
A la réception de cette requête, le proxy 183 interroge, à l'étape E322, la base de données 171 afin d'obtenir le contexte lié à la session IP entre les abonnés 100 et 120. Le proxy 183 obtient ainsi l'adresse IP de l'ordinateur 123.
Pour se faire, le proxy 183 utilise comme clé de recherche l'adresse IP de l'ordinateur 104.
Le proxy 183 adapté aux applications client-client 110 et 127 crée un contexte comprenant l'adresse IP de l'ordinateur 104, le ou les numéros de ports origine TCP/UDP utilisé(s), l'adresse IP de l'ordinateur 123, le ou les numéros de ports TCP/UDP origine du proxy IP 183 utilisé(s).
Le proxy 183 prolonge ensuite, à l'étape E323, la requête vers l'abonné 120 en utilisant le ou les numéros de ports TCP/UDP lié(s) à l'application client-client.
A la réception de cette requête, l'application client-client 127 envoie un message de confirmation, à l'étape E324, à destination du proxy 183, qui prolonge cette confirmation à l'étape E325, vers l'application client-client 110, en utilisant les informations présentes dans le contexte précédemment créé. Le ou les flux média peuvent alors transiter entre les applications client-client
127 et 110 à l'étape E326, en passant ou non par le proxy 183. Il est néanmoins à remarquer que le ou les flux de contrôle des flux média doivent transiter nécessairement à l'étape E326 par le proxy 183. Les flux de contrôle, plus précisément les paquets de contrôle de flux, sont reçus par le proxy IP 183. A la réception de ces flux de contrôle, le proxy 183 interroge à l'étape E327, en utilisant l'adresse IP des ordinateurs 104 ou 123, la base de données 171 pour récupérer le contexte de la session téléphonie-données ainsi que l'identifiant de la communication téléphonique et des ressources vocales.
Ces informations obtenues, les informations de contrôle des flux média et de contexte de session téléphonie-données sont transmises, à l'étape E328, par le proxy 183 au module d'analyse de paquets 182.
Le module d'analyse de paquets 182, à l'étape E329, analyse les paquets de contrôle des flux média, obtient des informations représentatives du retard du flux de média, et en fonction des informations de retard obtenues, génère une requête à destination du module de gestion vocale et retard 181, pour que celui-ci applique le même retard précédemment obtenu sur les flux vocaux téléphoniques.
Le module de gestion vocale et retard 181 applique le retard sur les flux vocaux à l'étape E330.
Ce système d'analyse des paquets de contrôle des flux média IP et d'applications de retard sur les flux vocaux est périodique. Les retards sont calculés par le module d'analyse de paquets 182 de la manière suivante dans le cas d'une transmission de vidéo H323 ou SIP avec un protocole de type RTCP: on détermine le retard TA des paquets RTCP entre l'ordinateur 104 et le proxy 183, on détermine le retard TB des paquets RTCP entre le proxy 183 et l'ordinateur 123, on additionne les retards TA et TB et on génère une requête à destination du module de gestion vocale et retard 181 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 103 transmis vers le téléphone 122.
on détermine le retard RB des paquets RTCP entre l'ordinateur 123 et le proxy 183, on détermine le retard RA des paquets RTCP entre le proxy 183 et l'ordinateur 104, on additionne les retards RA et RB et on génère une requête à destination du module de gestion vocale et retard 181 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 122 transmis vers le téléphone 103.
Il est à remarquer que le module gestion vocale et retard 181 prend en compte dans l'application du retard, le délai standard d'une communication téléphonique RTC entre le combiné 103 et le module gestion vocale et retard 181 et aussi du délai standard d'une communication téléphonique RTC entre le module gestion vocale et retard 181 et le combiné 122.
La Fig. 4 représente un paquet de rapport émetteur SR conforme au protocole RTCP . Selon l'invention, le flux de données transmis entre les abonnés 100 et 120 à travers le réseau Internet public 160 est conforme au protocole H323.
Le protocole H323 utilise le protocole RTP (Real time Transport Protocol) pour transporter le flux de données.
Le protocole RTP est un protocole de transport de données multimédia, il ne fournit aucune garantie quant à la qualité de service et se place au dessus du protocole
UDP ou TCP. Le protocole RTP permet à une application de reconstruire une séquence de données multimédia, en l'occurrence les signaux vidéo reçus par les logiciels d'application client-client 110 et 127.
Le protocole RTCP (Real Time Control Protocol) est un protocole qui permet d'obtenir des informations diverses sur une session RTP en cours. Le protocole RTCP fournit des informations sur la qualité du transfert des données.
Plus particulièrement, les paquets de rapport SR acronyme de Sender Report du protocole RTCP comportent des informations telles que les statistiques de réception et d'émission des participants à une session qui transfèrent des données sur le réseau Internet public 160.
Les paquets RTCP SR selon l'invention permettent au serveur de déterminer les retards sur les flux de données circulant sur le réseau Internet 160.
Les paquets RTCP SR sont constitués de plusieurs champs, le champ 600 définit le numéro de version du protocole RTCP.
Le champ 601 est un champ permettant de spécifier si les octets de données ont une partie de bourrage.
Le champ 602 est un champ destiné à contenir le nombre de rapports contenus dans le paquet. Il est à noter qu'un rapport est normalement destiné à chaque dispositif informatique émettant et/ou recevant le flux de données.
Le champ 603 identifie le type de paquet. Il est à remarquer que selon le protocole RTCP il existe cinq types différents de paquets. Les paquets SR, RR (Receiver Report) qui sont utilisés par le serveur 170 de l'invention pour déterminer le délai sur le réseau public Internet 160, les paquets SDES (Source Description) qui contiennent une liste d'informations identifiant une source RTP, BYE qui indique qu'un participant quitte la communication et APP (spécifique à une application). Les trois derniers types de paquets ne sont pas utilisés pour la synchronisation selon l'invention.
Le champ 604 indique la longueur totale du paquet RTCP. Le champ 605 identifie la source, c'est-à-dire l'émetteur du paquet RTCP en question. Selon l'invention, ce champ permet au serveur 170 selon l'invention de déterminer l'origine du paquet RTCP.
Les champs 606 et 607 contiennent la date et l'heure de l'envoi du message au format NTP (Network Time Protocol). Ce protocole NTP fournit le nombre de secondes écoulées depuis le 1er Janvier 1900 OOHOO. Le champ 606 contient les bits de poids fort sur 32 bits et représentatifs de la partie entière de secondes écoulées, le champ 607 contient les bits de poids faible sur 32 bits et représentatifs de la partie décimale de secondes écoulées.
Ces champs 606 et 607 peuvent être utilisés selon l'invention pour déterminer le retard des flux échangés par les ordinateurs 104 et 123 sur le réseau Internet 160.
Le champ 608 contient l'horloge de l'émetteur pour les paquets RTP envoyés par l'émetteur.
Le champ 609 comprend le nombre total de paquets de données utiles (payload) émis par l'émetteur depuis le début de la session et jusqu'à l'émission du paquet RTCP.
Le champ 610 comprend le nombre total d'octets de données utiles (payload) émis par l'émetteur depuis le début de la session et jusqu'à l'émission du paquet RTCP.
Les informations contenues dans ce champ 610 permettent au serveur 170 de l'invention de déterminer le débit moyen de cette source.
Le champ 611 identifie la source objet de ce rapport, c'est-à-dire l'émetteur des données RTP relatives au paquet RTCP en question. Selon l'invention, ce champ permet au serveur 170 selon l'invention de déterminer l'émetteur des paquets RTP considérés.
Le champ 612 contient des statistiques sur le pourcentage de paquets perdus depuis l'envoi du dernier paquet RTCP SR.
Le champ 613 contient le nombre cumulé, depuis le début de la session, de paquets perdus provenant de la source ayant émis les paquets en question. Il est à remarquer que les paquets arrivés en retard ne sont pas considérés comme des paquets perdus tandis que les paquets dupliqués sont comptés à chaque duplication.
Le champ 614 contient le dernier numéro de séquence reçue. Celui-ci est constitué de 32 bits, les 16 bits de poids faible contiennent le numéro de séquence le plus grand reçu tandis que les 16 bits de poids fort contiennent le nombre de cycles de numéros de séquences passées.
Le champ 615 comporte une estimation de la variance du temps passé entre l'arrivée des paquets RTP. Ce calcul est effectué par l'émetteur du paquet RTCP SR à partir des informations contenues dans le champ 608 et de son horloge interne. Le champ 616 LSR (Last Sender Report timestamp) contient la valeur du champ
607 du dernier paquet RTCP SR émis par le destinataire du paquet RTCP SR en question.
Le champ 617 DLSR (Delay Since Last Sender Report) contient le délai entre la réception du dernier paquet SR provenant du destinataire du paquet RTCP SR en question et l'émission du paquet RTCP SR en question.
Le serveur 170 selon l'invention utilise le champ 617 pour déterminer le délai de propagation dans le réseau ou RTT (Round Trip Time).
Il est à remarquer que les paquets RTCP SR sont diffusés à l'ensemble des ordinateurs de la session. Un paquet RTCP SR peut contenir des informations pour plusieurs sources. Pour chaque autre source, les champs 611 à 617 sont alors dupliqués dans le paquet RTCP SR.
Le paquet RTCP RR comporte des informations similaires à celles contenues dans un paquet RTCP SR, il ne sera donc pas décrit en détail.
Dans la suite de la description, nous ne décrirons l'invention qu'avec des paquets RTCP SR, il est bien entendu que l'invention utilise aussi en variante des paquets RTCP RR de la même façon que celle qui sera décrite avec les paquets RTCP
SR par la suite. La Fig. 5a représente un algorithme décrivant la détermination du retard sur le réseau Internet public 160 selon le premier mode de réalisation de l'invention.
Selon ce premier mode de réalisation, le flux média transmis par un ordinateur ainsi que le flux de contrôle du flux média, plus particulièrement les paquets RTCP, sont transmis au proxy 183 du serveur 170 qui prolonge ensuite le flux média à destination de l'autre ordinateur.
A titre d'exemple, l'ordinateur 104 de l'abonné 100 émet un flux de données à destination du proxy 183, le proxy 183 prolonge ensuite ce flux de données à destination de l'ordinateur 123 de l'abonné 120.
Aussi l'ordinateur 123 de l'abonné 120 émet un flux de données à destination du proxy 183, le proxy 183 prolonge ensuite ce flux de données à destination de l'ordinateur 104 de l'abonné 100.
L'algorithme de la Fig. 5a décrit un échange de paquets RTCP SR entre l'abonné 100 et le proxy 183. A partir de cet échange de paquets le serveur 170 selon l'invention détermine le retard RA des paquets entre le proxy 183 et l'ordinateur 104. Le retard TA des paquets entre l'ordinateur 104 et le proxy 183 est ici considéré comme identique au retard RA.
La détermination du retard RB des paquets entre le proxy 183 et l'ordinateur 123 est effectuée de façon similaire, elle ne sera donc pas décrite plus en détail. De la même façon, le retard TB des paquets entre l'ordinateur 123 et le proxy 183 est ici considéré comme identique au retard RB.
A l'étape E501, le proxy 183 génère un paquet RTCP SR à destination de l'ordinateur 104 de l'abonné 100.
Le proxy 183 insère dans le paquet RTCP SR entre autres son identifiant dans le champ 605, la date et l'heure notée Hl de l'envoi du message RTCP SR dans les champs 606 et 607, l'identifiant de l'ordinateur 104 de l'abonné 100 dans le champ 611.
A l'étape E502 suivante, le proxy 183 transmet ce paquet à l'ordinateur 104 par l'intermédiaire du réseau local 184, du routeur Firewall 185, du réseau public Internet 160, du routeur 106 et du réseau local 105.
L'ordinateur 104 reçoit le paquet RTCP SR à l'étape E503. A la réception du paquet RTCP SR, l'ordinateur 104 mémorise à l'étape E504 l'heure de son horloge interne de réception du paquet notée H2.
Cette opération effectuée, l'ordinateur 104 mémorise en autres le contenu des champs 606 et 607 du paquet RTCP SR reçu à l'étape E505.
L'étape E506 consiste en une boucle d'attente pour l'ordinateur 104 pour générer un paquet RTCP SR de contrôle du flux de données reçu du proxy 183.
Lorsque l'ordinateur 104 désire transmettre un paquet RTCP SR, celui-ci mémorise à l'étape E507, l'heure de son horloge interne.
L'ordinateur 104 insère à l'étape E508 le contenu du champ 607 mémorisé à l'étape E505 dans le champ 616 du paquet RTCP SR à transmettre. L'ordinateur 104 insère à l'étape E509 la différence des heures H3-H2 mémorisées aux étapes E504 et E507 dans le champ 617 du paquet RTCP SR à transmettre.
Bien entendu, l'ordinateur insère d'autres informations dans les différents champs du paquets RTCP SR, celle-ci ne sont par décrites. Le paquet ainsi formé est transmis à l'étape E510 par l'ordinateur 104 de l'abonné 100 au proxy 183 du serveur 170 par l'intermédiaire du réseau local 105, du routeur Firewall 106, du réseau public Internet 160, du routeur Firewall 185 et du réseau local 184.
Le proxy 183 du serveur 170 reçoit le paquet RTCP SR à l'étape E511. A la réception du paquet RTCP SR, le proxy 183 interroge la base de données
171 pour récupérer le contexte de la session téléphonie-données ainsi que l'identifiant de la communication téléphonique et des ressources vocales associés au flux de données.
Ces informations obtenues, les informations de contrôle des flux média et de contexte de session téléphonie-données sont transmises par le proxy 183 au module d'analyse de paquets 182 conformément à l'étape E328 de la Fig. 3 précédemment décrite.
Le module d'analyse de paquets 182 mémorise à l'étape E512 l'heure notée H4 de son horloge interne de réception du paquet.
Cette opération effectuée, le module d'analyse de paquets 182, à l'étape E513, mémorise le contenu du champ 617 du paquet RTCP SR reçu à l'étape E511.
Le module d'analyse de paquets 182 mémorise aussi à l'étape E514 le contenu du champ 616 du paquet RTCP SR reçu. Le module d'analyse de paquets 182 du serveur 170 obtient à l'étape E515 le retard des paquets RTCP entre le proxy 183 et l'ordinateur 104 en soustrayant de l'heure H4 mémorisée à l'étape E512 les contenus des champs 617 et 616 mémorisés précédemment aux étapes respectives E513 et E514.
Le retard des paquets ainsi calculé, par exemple 200ms, est égal à la somme des retards TA et RA précédemment mentionnés en référence à la Fig. 3.
Par souci de simplicité ceux-ci sont considérés comme égaux. Ainsi TA=RA=100ms.
La détermination du retard RB des paquets RTCP entre le proxy 183 et l'ordinateur 123 est effectuée de façon similaire à celle décrite en référence aux étapes E501 à E516, les paquets de contrôle RTCP SR sont envoyés par le proxy 183 à l'ordinateur 123 de l'abonné 120 à l'étape E502 et les paquets de contrôle RTCP SR sont envoyés par l'ordinateur 123 de l'abonné 120 au proxy 183 à l'étape E510.
Le retard des paquets ainsi calculé, ici de 240ms, est égal à la somme des retards TB et RB précédemment mentionnés en référence à la Fig. 3. Par souci de simplicité ceux-ci sont considérés comme égaux. Ainsi
TB=RB= 120ms.
Le module d'analyse de paquets 182 génère à l'étape E516 une requête à destination du module de gestion vocale et retard 181, pour que celui-ci applique les retards TA+TB précédemment obtenus sur le flux vocal émis du téléphone 103 vers le téléphone 122.
Le module d'analyse de paquets 182 génère de la même façon à l'étape E516 une requête à destination du module de gestion vocale et retard 181, pour que celui-ci applique les retards RA+RB précédemment obtenus sur le flux vocal émis du téléphone 122 vers le téléphone 103. La Fig. 5b représente un algorithme décrivant l'application du retard sur les flux vocaux téléphoniques effectué par le module de gestion vocale et retard.
Le module de gestion vocale et retard 181 contrôle une ou plusieurs cartes interfaces téléphoniques par exemple de type DTI300SC-E1 fabriquées par la société Dialogic-intel ou de type AGS-1000 de la société Natural Micro System. Ces cartes
disposent d'une interface RNIS de type B à un débit de 64Kbit/s et un canal de signalisation D à un débit de 64Kbit/s. Des cartes comportant des interfaces T0/S0 qui comportent deux canaux B à un débit de 64Kbit/s et un canal de signalisation D à un débit de 16Kbit/s peuvent aussi être utilisées. Ces cartes comportent des mémoires tampon, pour chaque flux vocal et selon chaque direction du flux vocal, qui mémorisent les flux audio reçus et/ou à transmettre.
Chaque flux vocal obtenu du réseau RTC 141 est par exemple mémorisé dans une mémoire circulaire respective ayant une capacité de stockage de l'ordre de 500 millisecondes (ms) voire 1 seconde de flux vocal. Par exemple, le débit synchrone d'une communication téléphonique de type G711 loi A étant de 64 Kbit/s, les données sont écrites et lues dans la mémoire circulaire toutes les 20ms.
Nous allons maintenant décrire l'application du retard vocal sur un seul flux vocal, lorsque plusieurs flux vocaux sont simultanément à retarder, le module de gestion vocal 181 effectue l'algorithme de la Fig. 5b pour chacun des flux vocaux à traiter.
Le module de gestion vocale et retard 181 reçoit à l'étape E520 du module d'analyse de paquets 182 le retard à appliquer sur un flux vocal. Ce retard est à titre d'exemple égal à 220ms. Le module de gestion vocale et retard 181 obtient à l'étape E521 l'adresse
Ptr_ec du pointeur d'écriture de la mémoire circulaire contenant le flux vocal entrant.
Le pointeur d'écriture mémorisant les données toutes les 20ms, le module de gestion vocale et retard 181 détermine à l'étape E522 la durée de flux vocal mémorisé dans la mémoire circulaire en multipliant l'adresse Ptr_ec par 20 ms. Par exemple, le pointeur d'écriture Ptr_ec étant à l'adresse 14, la durée de flux vocal mémorisé dans la mémoire circulaire est de 280ms.
Le module de gestion vocale et retard 181, à l'étape E523, fait la différence entre le retard RA reçu à l'étape E520 et la durée de flux vocal mémorisé dans la mémoire circulaire déterminée à l'étape E522. Selon notre exemple la différence Dvx est égale à 60 ms.
Le module de gestion vocale et retard 181, à l'étape E524, détermine l'adresse du pointeur de lecture de la mémoire circulaire Ptr_lec en déterminant la partie entière de la division de la différence Dvx par le rythme de lecture de la mémoire circulaire qui est de 20 ms selon notre exemple.
Selon notre exemple l'adresse du pointeur de lecture de la mémoire circulaire Ptr_lec est égale à 60ms/20ms soit 3.
Le module de gestion vocale et retard 181, à l'étape E525 transfère la valeur du pointeur de lecture Ptr_lec à la carte interface téléphonique gérant le flux audio sur le réseau RTC 141.
Ainsi, les flux vocaux transmis sur le réseau commuté 141 sont retardés de la même façon que les flux média sont retardés par le réseau public Internet 160.
La Fig. 6 représente un second mode de réalisation de l'invention dans un réseau de télécommunication comportant une architecture service node ou nœud de services dans le cadre d'un service de mise en relation d'abonnés en conférence.
Le réseau de télécommunication comprend un fournisseur de services d'applications ASP noté 290 qui peut être par exemple associé à un opérateur de télécommunication 240. Le réseau de télécommunication comporte aussi un réseau téléphonique commuté 241 et un réseau Internet public 260. Le réseau téléphonique commuté est ici considéré comme un réseau de télécommunication synchrone, le réseau Internet public 260 étant le réseau de télécommunication asynchrone.
Le réseau téléphonique commuté 241 est associé à un commutateur à autonomie d'acheminement CAA noté 242 permettant la fourniture du service téléphonique classique à un abonné 200 et à un abonné 291. Le réseau RTC 241 est aussi associé à un commutateur à autonomie d'acheminement CAA noté 245 permettant la fourniture du service téléphonique classique à un abonné 220.
Le fournisseur de services d'applications ASP 290 comprend un réseau local 284. Le réseau local 284 est aussi relié au réseau public Internet 260 au travers d'un routeur Firewall 285 assurant aussi la sécurité des échanges d'informations entre les réseaux 284 et 260 en veillant à ce qu'aucune intrusion ne puisse être effectuée dans le réseau 284.
A ce réseau local 284, est connecté un serveur 270. Le serveur 270 ou pont de conférence est aussi connecté au réseau téléphonique 241 via le commutateur à autonomie d'acheminement 242.
Le serveur 270 est soit centralisé sur un seul dispositif soit réparti sur différents dispositifs placés ou non sur un même site.
Le serveur 270 est constitué d'une base de données du service 271 identique à la base de données 171 de la Fig.l
Le serveur 270 comporte aussi un module d'enregistrement 272 des logiciels clients des abonnés au service identique au module d'enregistrement 172 des logiciels clients des abonnés de la Fig. 1.
Le serveur 270 comporte aussi un module 273 de notification d'événements réseaux et d'informations des logiciels clients identique au module 173 de notification d'événements réseaux et d'informations des logiciels clients de la Fig. 1.
Le serveur 270 comporte aussi une interface IP 278 de type Ethernet qui permet au serveur 270 de se connecter avec le réseau local 284.
Le serveur 270 comporte un module répondeur téléphonique 279 qui traite la signalisation des appels téléphoniques entrants et sortants et l'acceptation de ceux-ci.
Le serveur 270 comporte une interface téléphonique RTC 280 de type ISUP ou de type SS7 qui permet la connexion du serveur 270 avec le réseau téléphonique 241 via le CAA 242 de l'opérateur de télécommunication 240.
Le serveur 270 comporte aussi un module 281 de mixage des flux vocaux téléphoniques RTC et retard permettant la génération de retard entre les flux vocaux entrants actifs et les flux vocaux sortants. Les retards peuvent être différents selon le sens de la communication. Nous entendons ici comme flux vocal entrant actif, le flux vocal qui comporte des informations représentatives d'une activité supérieure par rapport aux autres flux. C'est par exemple le flux vocal qui comporte le plus haut niveau sonore. Le flux vocal de l'initiateur de la conférence ou le flux vocal du maître de conférence peut aussi être considéré comme le flux vocal entrant actif de manière prédéterminée. Ce flux vocal actif peut aussi être défini en fonction de période d'activité ou d'inactivité du flux. La détermination du flux vocal actif est effectuée par le module 281 de mixage des flux vocaux téléphoniques RTC et retard.
Le serveur 270 comporte aussi un module 282 de mixage analyse des flux média IP, par exemple de type de paquets de type RTP vidéo gérés par les protocoles H323/SIP. Le mixage est dépendant des applications supportées. Le module de mixage 282 extrait et analyse les paquets de contrôle des flux média IP, par exemple de paquets RTCP vidéo de type H323/SIP. Parmi les informations analysées, on peut trouver pour chaque sens de transmission, le délai, le taux de perte de paquets, la gigue et le débit. Les informations obtenues au niveau du
module de mixage 282 vont permettre d'appliquer des retards sur les flux vocaux RTC via le module 281 de mixage des flux vocaux téléphoniques RTC et retard.
Le serveur 270 comporte aussi un module répondeur applications IP 283 qui traite les signaux de signalisation des communications. Le module répondeur applications IP 283 comporte une pluralité de modules aptes chacun à traiter des signalisations (H323 ou SIP) par type d'application.
L'abonné 200 dispose d'équipements tels qu'un terminal téléphonique 203 connecté au réseau téléphonique commuté 241 par l'intermédiaire du CAA 242.
L'abonné 200 dispose en outre d'un ordinateur 204 connecté au réseau Internet 260.
L'ordinateur 204 dispose dans sa mémoire des programmes aptes à mettre en œuvre l'invention. Il comporte des logiciels 207 et 210 offrant les mêmes fonctionnalités que les logiciels respectifs 107 et 110 de la Fig.l.
L'abonné 220 dispose d'équipements tels qu'un terminal téléphonique 222 connecté au réseau téléphonique commuté 241 par l'intermédiaire d'un CAA 245.
L'abonné 220 dispose en outre d'un ordinateur 223 connecté au réseau Internet 260.
L'ordinateur 223 dispose dans sa mémoire des programmes aptes à mettre en œuvre l'invention. Il comporte des logiciels 224 et 227 offrant les mêmes fonctionnalités que les logiciels respectifs 124 et 127 de la Fig.1.
L'abonné 291 dispose d'équipements tels qu'un terminal téléphonique 292 connecté au réseau téléphonique commuté 241 par l'intermédiaire du CAA 242.
L'abonné 291 dispose en outre d'un ordinateur 295 connecté au réseau de type Internet 260. L'ordinateur 295 dispose dans sa mémoire des programmes aptes à mettre en œuvre l'invention. Il comporte des logiciels 294 et 293 offrant les mêmes fonctionnalités que les logiciels respectifs 107 et 110 de la Fig.l .
La Fig. 7 représente un algorithme décrivant la cinématique d'activation d'une conférence téléphonique entre trois abonnés, couplée avec une application de type client-client gérée dans le cadre d'une architecture de type service node dans le réseau de la Fig. 6.
Préalablement à un appel téléphonique, l'abonné 200 s'enregistre au service tel que fourni par l'invention dans le réseau conforme au second mode de réalisation.
Pour cela, l'ordinateur 204 de l'abonné 200 exécute le programme logiciel client 207.
L'ordinateur 204 se connecte par l'intermédiaire du réseau Internet public 260 au module d'enregistrement client 272 du serveur 270 de l'ASP 290. Le programme logiciel client 207, le module enregistrement logiciel client 272 du serveur 270 exécutent l'algorithme d'enregistrement tel que décrit précédemment en référence à la Fig. 2.
L'enregistrement effectué, l'abonné 200 décroche son terminal téléphonique 203 et compose, à l'étape E700, le numéro de téléphone du service permettant le couplage téléphonie-application de données. Ce numéro de téléphone est associé à l'interface téléphonique 280.
Un message de demande d'établissement d'appel téléphonique est transmis, à l'étape E701, vers le module répondeur téléphonique 279.
Le module répondeur téléphonique 279 accepte automatiquement l'appel téléphonique entrant à l'étape E702.
En variante, le module répondeur téléphonique 279 génère un message "Alerte", préalablement au message "Connexion" à destination du combiné téléphonique 203.
Le module répondeur téléphonique 279, afin d'obtenir le contexte de la session, génère une requête, à l'étape E703, à la base de données 271 qui utilise le numéro de téléphone appelant en tant que clé de recherche. Il est à remarquer que le contexte de la session comprend le numéro de canal vocal disponible pour l'application ainsi que l'adresse IP de l'ordinateur 204.
Ce contexte étant obtenu, le module répondeur téléphonique 279 génère une requête d'activation du module mixeur et retard 281 à l'étape E704. Le module de mixeur et retard 281 étant activé, le module répondeur téléphonique 279 demande la diffusion, par le mixeur et retard 281, d'une annonce vocale, à destination de l'abonné 200, sur le canal vocal du contexte sélectionné.
Cette annonce vocale est une annonce vocale de bienvenue et d'attente. Elle est diffusée à l'étape E705. Parallèlement à l'appel téléphonique, le module répondeur téléphonique 279 informe le module de notification logiciel client 273 de l'appel. Ce dernier transmet, à l'étape E706, au logiciel client 207, les informations suivantes : événements téléphoniques "Connexion" avec les arguments numéro de téléphone de l'appelant, numéro de téléphone du répondeur téléphonique 279, la ou les adresses IP des
répondeurs IP 283 et le ou les numéros de ports des répondeurs IP283 compatible(s) avec la ou les applications client-client de l'abonné 200.
Par exemple, le module de notification logiciel client 273 transmet au logiciel client les numéros de ports suivants 194.254.161.225 :1720, 194.254.161.226 :5060 et 194.254.161.227 :1503.
Ces numéros de ports permettent de signifier au logiciel client 207 le fait que le serveur 270 est apte à supporter une application répondeur H323 si le logiciel client utilise l'adresse IP 194.254.161.225 , que le serveur 270 est apte à supporter une application SIP si le logiciel client utilise l'adresse IP 194.254.161.226 et le serveur 270 est apte à supporter une application répondeur de partage d'application du type conforme au standard T120 si le logiciel client utilise l'adresse IP 194.254.161.227.
A la réception de ces informations, à l'étape E707, le logiciel client 207 vérifie, en utilisant sa configuration locale stockée sur l'ordinateur 204, la liste des actions à effectuer. Le logiciel client 207 affiche sur l'écran de l'ordinateur 204 la liste des applications client-client compatibles avec celles gérées par le pont de conférence ou serveur 270, par exemple affiche une invitation à activer une application de type client-client "Activer Microsoft Netmeeting H323", et/ ou activer " FTR&D eConf SIP". Il est à remarquer que l'activation de l'application peut être automatique. L'application logiciel client-client 210 activée, celle-ci émet à l'étape E708 une requête dépendante du protocole de l'application client-client 210 (exemple envoi d'un message SETUP H323) vers le module répondeur IP 283 compatible.
A la réception de cette requête, le module répondeur IP 283 interroge, à l'étape E709, la base de données 271 afin d'obtenir le contexte lié à la session IP entre l'abonné 200 et le serveur ou pont de conférence serveur 270.
Pour se faire, le module répondeur IP utilise comme clé de recherche l'adresse IP de l'ordinateur 204.
De plus, on vérifie en particulier que la communication téléphonique entre l'abonné 200 et le serveur de l'invention 270 est toujours active et que des ressources média IP sont disponibles.
Dans l'affirmative, le module répondeur IP 283 confirme, à l'étape E710, la requête IP générée à l'étape E708 et transmet la ou les adresses IP du module mixeur analyse des flux média IP 282 ainsi que le ou les ports TCP/UDP à utiliser.
Le module répondeur IP 283 demande, à l'étape E711, au module mixeur analyse de média IP 282 de se mettre en attente d'appel.
L'application client-client 210 établit alors, à l'étape E712, le ou les canaux média et de contrôle de média IP avec le module mixeur analyse des flux média IP 282.
Il est à remarquer que l'appel de l'abonné 200 correspond au premier appel sur le pont de conférence 270, des informations de type annonce d'accueil, de type vidéo d'attente peuvent être diffusées vers l'abonné 200 si l'application est de type client-client vidéo H323/SIP. Régulièrement, le module mixeur analyse des flux média IP 282 obtient des informations de contrôle des flux média IP échangées avec l'application client-client 210 et interroge la base de données 271 à l'étape E713.
Le module mixeur analyse des flux média IP 282 obtient ainsi, en utilisant l'adresse IP de l'ordinateur 204 comme clé primaire, le contexte de la session comprenant les références des canaux téléphoniques entrants et sortants.
Ces informations obtenues, le module mixeur analyse des flux média IP 282 analyse les paquets de contrôle des flux média, obtient des informations représentatives du retard, de gigue, de perte de paquets du flux de média et en fonction de ces informations, contrôle, à l'étape E714, le module mixeur et retard vocal 281.
Ainsi, le flux vocal téléphonique, qui est par exemple une musique d'attente, synchronisée avec la vidéo H323/SIP émise par le serveur de l'invention 270 vers l'abonné 200, est plus ou moins retardée. Ce retard est appliqué à l'étape E715.
Lorsque l'abonné 220 décroche son terminal téléphonique 222 et compose le numéro de téléphone du service permettant le couplage téléphonie-application de données, ce numéro de téléphone étant associé à l'interface téléphonique 280, un message de demande d'établissement d'appel téléphonique est transmis, à l'étape
E716, au module répondeur téléphonique 279.
Le module répondeur téléphonique 279 accepte l'appel téléphonique entrant à l'étape E717.
Ensuite, le module répondeur téléphonique 279 consulte, à l'étape E718, la base de données 271 avec la clé primaire numéro de téléphone appelant afin d'obtenir le contexte de la session comprenant le numéro d'un canal vocal disponible, et l'adresse IP de l'ordinateur 223 si le logiciel client 224 est activé.
Si le logiciel client 224 n'est pas activé, l'adresse IP de l'ordinateur 223 de l'abonné 220 ne sera pas fournie. Dans ce cas, à l'étape E719, le répondeur téléphonique 279 génère un message, à destination du module mixeur et retard vocal 281 pour que celui-ci diffuse à l'étape E720, à destination de l'abonné 220, une annonce vocale de bienvenue ainsi qu'un message d'annonce vocal invitant l'abonné 220 à activer son logiciel client 224. La connexion vocale en mode conférence entre les abonnés 200 et 220 est alors activée sur le canal vocal sélectionné.
Si le logiciel client 224 de l'abonné 220 n'est pas activé et enregistré, celui-ci s'active, s'enregistre. Le logiciel client 224 est activé manuellement ou automatiquement. La signalisation d'appel IP est échangée avec le module répondeur IP 283 compatible. Le ou les canaux média, ainsi que le ou les canaux de contrôle de média IP sont établis avec le module mixeur analyse des flux média IP 282 de la même façon que celle décrite précédemment pour l'abonné 200.
L'abonné 220 étant le second abonné à avoir appelé le service, les applications client-client 210 et 227 des abonnés 200 et 220 se retrouvent en connexion au travers du pont de conférence ou serveur IP 270. Le module mixeur analyse des flux média
IP 282 obtient les informations de contrôle des flux média échangées par les applications client-client 210 et 227.
Le module mixeur analyse des flux média IP 282 interroge la base de données 271 à l'étape E721 afin d'obtenir les deux contextes de sessions et plus particulièrement les références des canaux téléphoniques des communications entre l'abonné 200 et le serveur de l'invention 270 et entre l'abonné 220 et le serveur de l'invention 270.
Ces informations obtenues, le module mixeur analyse des flux média IP 282 analyse les paquets de contrôle des flux média, obtient des informations représentatives du retard, de gigue, de perte de paquets du flux de média, et en fonction de ces informations, contrôle à l'étape E722 le module mixeur et retard vocal
281.
Ainsi à cette même étape, le flux vocal téléphonique émis par le serveur 270 vers l'abonné 200 est plus ou moins retardé. De la même façon, le flux vocal téléphonique émis par le serveur 270 vers l'abonné 220 est aussi plus ou moins retardé. Plus précisément, le retard est appliqué sur le flux vocal considéré comme flux vocal esclave, le flux vocal maître étant le flux vocal considéré comme actif.
Les retards sont calculés de la manière suivante dans le cas d'une transmission de vidéo H323 ou SIP avec un protocole de type RTCP: on détermine le retard TA issu des paquets RTCP entre l'ordinateur 204 et le module mixeur analyse des flux média IP 282, on détermine le retard TB issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 223, on additionne les retards TA et TB et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis au téléphone 222. on détermine le retard RB issu des paquets RTCP entre l'ordinateur 223 et le module mixeur analyse des flux média IP 282, on détermine le retard RA issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 204, on additionne les retards RA et RB et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 222 et transmis au téléphone 203.
Il est à remarquer que le module mixeur vocal et retard 281 prend en compte dans l'application du retard, le délai standard d'une communication téléphonique
RTC entre le combiné 203 et le module mixeur vocal et retard 281 et aussi du délai standard d'une communication téléphonique RTC entre le module mixeur vocal et retard 281 et le combiné 222.
Lorsqu'un troisième abonné compose, par l'intermédiaire de son combiné téléphonique 292, le numéro de téléphone associé à l'interface téléphonique 280, le module téléphonique effectue les mêmes opérations que celles décrites pour l'appel de l'abonné 220 au numéro associé à l'interface téléphonique 280.
Le troisième abonné 291 active son logiciel client 294 qui s'enregistre avec le module d'enregistrement 272. Le logiciel client-client 293 est alors activé manuellement ou automatiquement, la signalisation d'appel IP est échangée avec le module répondeur IP 283 compatible, le ou les canaux média, le ou les canaux de contrôle de média IP sont établis avec le module mixeur analyse des flux média IP 282 de la même façon que celle décrite précédemment pour l'abonné 200. Ces procédures ne seront donc pas décrites plus en détail.
Alors, la connexion en mode conférence vocale est établie pour les abonnés 200, 220 et 291.
S 'agissant du troisième appel sur le pont de conférence IP 270, les applications client-client 210, 227 et 293 compatibles des abonnés 200, 220 et 291 se retrouvent en connexion au travers du serveur ou pont de conférence IP 270.
Le module mixeur analyse des flux média IP 282 obtient périodiquement des informations de contrôle des flux média échangées avec les applications client-client 210, 227 et 293.
Le module mixeur analyse des flux média IP 282 interroge la base de données 271 afin d'obtenir les trois contextes de sessions en utilisant les adresses IP de l'ordinateur 204, de l'ordinateur 223 et de l'ordinateur 295 comme clé primaire et plus particulièrement les références des canaux téléphoniques entrants et sortants des communications entre l'abonné 200 et le serveur 270, entre l'abonné 220 et le serveur 270 et entre l'abonné 291 et le serveur 270.
Le module mixeur analyse des flux média IP 282 analyse les paquets de contrôle des flux média, obtient des informations représentatives de retard, de gigue, de perte de paquets du flux de média, et en fonction de ces informations, contrôle à l'étape E723, le module mixeur et retard vocal 281.
Ainsi, le flux vocal téléphonique émis par le serveur 270 vers l'abonné 200 est plus ou moins retardé à l'étape E724.
De la même façon, le flux vocal téléphonique émis par le serveur 270 vers l'abonné 220 est plus ou moins retardé à l'étape E725 et le flux vocal téléphonique émis par le serveur 270 vers l'abonné 291 est plus ou moins retardé à l'étape E726.
Trois abonnés étant en conférence, seulement un des trois abonnés à un instant donné parle. Les deux autres abonnés quant à eux écoutent le flux vocal diffusé par cet abonné. Les retards sont calculés de la manière suivante dans le cas d'une transmission de vidéo H323 ou SIP avec un protocole de type RTCP :
Si l'abonné 200 émet un flux vocal : on détermine le retard RAM issu des paquets RTCP entre l'ordinateur 204 et le module mixeur analyse des flux média IP 282, on détermine le retard RMB issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 223, on additionne les retards RAM et RMB et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 222,
on détermine le retard RMC issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 295, on additionne les retards RAM et RMC et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 292,
Si l'abonné 220 émet un flux vocal : on détermine le retard RBM issu des paquets RTCP entre l'ordinateur 223 et le module mixeur analyse des flux média IP 282, on détermine le retard RMA issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 204, on additionne les retards RBM et RMA et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 222 et transmis vers le téléphone 203. on détermine le retard RMC issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 295, on additionne les retards RBM et RMC et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 222 et transmis vers le téléphone 292,
Si l'abonné 291 émet un flux vocal : on détermine le retard RCM issu des paquets RTCP entre l'ordinateur 295 et le module mixeur analyse des flux média IP 282, on détermine le retard RMA issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 204, on additionne les retards RCM et RMA et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 292 et transmis vers le téléphone 203, on détermine le retard RMB issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 223, on additionne les retards RCM et RMB et on génère une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 292 et transmis vers le téléphone 222,
La Fig. 8 représente un algorithme décrivant la détermination du retard sur le réseau de télécommunication par paquets selon le second mode de réalisation de l'invention.
Les applications client-client 210 et 227 compatibles des abonnés 200 et 220 étant en connexion au travers du serveur ou pont de conférence IP 270, le module mixeur analyse des flux média IP 282 obtient périodiquement des informations de contrôle des flux média des applications client-client 210 et 227. Le flux média transmis par un ordinateur ainsi que le flux de contrôle du flux média, plus particulièrement les paquets RTCP, sont transmis au module mixeur analyse des flux média IP 282 du serveur 270 qui prolonge ensuite le flux média à destination du ou des autres ordinateurs.
A titre d'exemple, l'ordinateur 204 de l'abonné 200 émet un flux de données à destination du mixeur analyse des flux média IP 282, le module mixeur analyse média IP 282 interroge la base de données 271 afin d'obtenir les deux contextes de sessions en utilisant les adresses IP de l'ordinateur 204 et de l'ordinateur 223 comme clé primaire et plus particulièrement les références des canaux téléphoniques entrants et sortants des communications entre l'abonné 200 et le serveur 270 et entre l'abonné 220 et le serveur 270, le mixeur analyse des flux média IP 282 prolonge ensuite ce flux de données à destination de l'ordinateur 223 de l'abonné 220.
A l'étape E801, le module mixeur analyse des flux média IP 282 reçoit un paquet de contrôle de flux média, par exemple un paquet RTCP SR envoyé par l'application client-client 210 relatif à un transfert de flux de données entre l'application client-client 210 et le module mixeur analyse des flux média IP 282.
Le module mixeur analyse des flux média IP 282 détermine à l'étape E802 l'émetteur de ce message en lisant l'identifiant contenu dans le champ 605 du paquet RTCP SR représenté en Fig. 4. Cet identifiant correspond par exemple à celui de l'application client-client 210. Le module mixeur analyse de flux média IP 282 vérifie à l'étape suivante E803 s'il a préalablement transmis un paquet RTCP SR à l'application client-client 210.
Dans la négative, le module mixeur analyse de flux média IP 282 passe à l'étape E804. A cette étape, le module mixeur analyse de flux média IP 282 attend si nécessaire un temps prédéterminé avant de passer aux étapes E805 à E806. En effet, afin de ne pas avoir un rapport trop important entre les paquets de contrôle et les paquets du flux RTP, le module mixeur analyse de flux média IP 282 peut être amené à attendre un temps plus ou moins important avant de lui-même générer un paquet RTCP.
A l'étape E805, le module mixeur analyse de flux média IP 282 génère un paquet RTCP SR à destination de l'application client-client 210.
Le module mixeur analyse de flux média IP 282 insère dans le paquet RTCP SR entre autres son identifiant dans le champ 605, la date et l'heure notée Hi de l'envoi du message RTCP SR dans les champs 606 et 607, l'identifiant de l'ordinateur 204 de l'abonné 200 dans le champ 611. Il est à remarquer que i est un indice associé à l'ordinateur 204 et/ou à l'application client-client 210.
A l'étape suivante E806, le module mixeur analyse de flux média IP 282 mémorise l'heure notée Hi et procède à l'étape E807 au transfert du paquet RTCP SR précédemment généré à l'étape E805 par l'intermédiaire de l'interface IP 278, du réseau local 284, du routeur Firewall 285 et du réseau public Internet 260.
Le transfert effectué, le module mixeur analyse de flux média IP 282 retourne à l'étape E801 et reçoit à cette étape un nouveau paquet RTCP SR.
Le module mixeur analyse de flux média IP 282 détermine à l'étape E802 l'émetteur de ce message en lisant l'identifiant contenu dans le champ 605 du paquet RTCP SR, celui-ci est par exemple l'identifiant de l'application client-client 227.
Le module mixeur analyse de flux média IP 282 vérifie à l'étape suivante E803 s'il a préalablement transmis un paquet RTCP SR à l'application client-client 227. Dans notre exemple, la vérification est négative, le module mixeur analyse de flux média IP 282 effectue les étapes E805 à E807 de la même manière que celle précédemment décrite, il mémorise alors l'heure Hi correspondante où i est l'indice associé à l'ordinateur 220 ou à l'application client-client 227.
Ces opérations effectuées le module mixeur analyse de flux média IP 282 retourne à l'étape E801 et reçoit à cette étape un nouveau paquet RTCP SR. Le module mixeur analyse de flux média IP 282 détermine à l'étape E802 l'émetteur de ce message, celui-ci est par exemple l'identifiant de l'application client- client 210.
Le module mixeur analyse de flux média IP 282 vérifie à l'étape suivante E803 s'il a préalablement transmis un paquet RTCP SR à l'application client-client 210. Dans notre exemple, ceci est le cas, une heure Hi, avec i indice de l'ordinateur 204, a été précédemment mémorisée.
Le module mixeur analyse des flux média IP 282 passe alors à l'étape E808 et mémorise l'heure Ti à laquelle le paquet a été reçu. Il est à remarquer que i est ici un indice associé à l'ordinateur 204 et/ou à l'application client-client 210.
Le module mixeur analyse des flux média IP 282 lit et mémorise, à l'étape suivante E809, le contenu du champ 617 du paquet RTCP SR représenté en Fig. 4. Celui-ci correspond dans notre exemple au délai passé entre l'instant auquel l'application client-client 210 a reçu un paquet RTCP SR du module mixeur analyse des flux média IP 282 et l'instant auquel l'application client-client 210 a émis le paquet RTCP SR en cours de traitement.
Cette opération effectuée, le module mixeur analyse des flux média IP 282 calcule à l'étape E810 le délai de propagation noté DIP existant entre l'application client-client en question, en l'occurrence l'application client-client 210 et le module mixeur analyse des flux média IP 282.
Le module mixeur analyse des flux média IP 282 calcule le délai de propagation DIP en soustrayant du temps Ti mémorisé à l'étape E808 le temps Hi mémorisé à l'étape E806 ainsi que le contenu du champ 617 mémorisé à l'étape E809.
Le délai DIP ainsi obtenu est ainsi représentatif d'un trajet aller retour d'un paquet entre l'application client-client 210 et le module mixeur analyse des flux média IP 282 à travers le réseau Internet 260, le routeur 285 et le réseau local 284.
Il est à remarquer que le délai DIP est égal à la somme des retards RMA issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 204 et RAM issu des paquets RTCP entre l'ordinateur 204 et le module mixeur analyse des flux média IP 282.
Par souci de simplification, chacun des retards RMA et RAM est considéré égal à la moitié du délai DIP.
Cette opération effectuée, le module mixeur analyse des flux média IP 282 passe ensuite à l'étape E811 qui consiste à interroger la base de données 271 afin d'obtenir les contextes de sessions en utilisant les adresses IP de l'ordinateur 204, de l'ordinateur 223 comme clé primaire et plus particulièrement les références des canaux téléphoniques entrants et sortants des communications entre l'abonné 200 et le serveur 270 et entre l'abonné 220 et le serveur 270.
Le module mixeur analyse des flux média IP 282 connaissant les références des canaux téléphoniques entrants et sortants des communications entre l'abonné 200 et le serveur 270 et entre l'abonné 220 et le serveur 270, additionne les retards RAM et RMB et génère à l'étape E812 une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 222.
Le module mixeur analyse des flux média IP 282 additionne les retards RBM et RMB et génère à la même étape E812 une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 222 et transmis vers le téléphone 203. II est à remarquer ici qu'en variante, le module mixeur analyse des flux média
IP 282 interroge le module mixeur vocal et retard 281 de manière à déterminer le flux vocal actif, c'est-à-dire quel abonné est en train d'émettre le flux vocal. En fonction de la réponse, si par exemple l'abonné 200 est en train de parler, le module mixeur analyse des flux média IP 282 ne génère qu'une seule requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 222.
Il est à remarquer que selon notre exemple, les retards RBM et RMB n'ont pas encore été calculés, ils sont donc considérés comme nuls. En variante ils peuvent être fixés à une valeur prédéterminée représentative de retards moyens évalués lors de sessions précédentes.
Cette opération effectuée, le module mixeur analyse des flux média IP 282 retourne à l'étape E804 précédemment décrite et effectue les étapes E805 à E807 pour enfin retourner à l'étape E801 pour recevoir un nouveau paquet.
Il est à remarquer que lorsque le module mixeur analyse des flux média IP 282 reçoit un paquet RTCP SR de l'application 227 de l'ordinateur 223, celui-ci effectue de la même façon les étapes E801 à E803 et E808 à E812 et détermine ainsi à l'étape E810 le retard égal à la somme des retards RMB issu des paquets RTCP entre le module mixeur analyse des flux média IP 282 et l'ordinateur 223 et RBM issu des paquets RTCP entre l'ordinateur 223 et le module mixeur analyse des flux média IP 282. Ces retards RMB et RBM sont considérés égaux à la moitié du délai DIP.
Le module mixeur analyse des flux média IP 282 additionne les retards RAM et RMB et génère à l'étape E812 une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 222. II additionne les retards RBM et RMB et génère à la même étape E812 une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 222 et transmis vers le téléphone 203.
Il est à remarquer ici que, si l'application client-client 227 de l'abonné 220 est une application non active en ce sens qu'elle ne transfère pas un flux vidéo, celle-ci au lieu de générer des paquets RTCP SR génère des paquets RTCP RR (receiver report) qui sont similaires au paquets RTCP SR et traités par le module mixeur analyse des flux média IP 282 de la même manière que les paquets RTCP SR.
Si l'abonné 291 se joint au pont de conférence entre temps, le module mixeur analyse des flux média IP 282 additionne les retards RAM et RMC et génère à l'étape E812 une requête à destination du module mixeur vocal et retard 281 pour que celui- ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 292.
Le module mixeur analyse des flux média IP 282 additionne les retards RBM et RMC et génère à l'étape E812 une requête à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 222 et transmis vers le téléphone 292. Les retards entre RCM et RMC sont déterminés de la même façon que celle précédemment décrite. Ils ne seront pas plus décrits.
Il est à remarquer ici que, en variante, le module mixeur analyse des flux média IP 282 interroge le module mixeur vocal et retard 281 de manière à déterminer le flux vocal actif, c'est-à-dire quel abonné est en train d'émettre le flux vocal. En fonction de la réponse, si par exemple l'abonné 200 est en train de parler, le module mixeur analyse des flux média IP 282 ne génère que deux requêtes à destination du module mixeur vocal et retard 281 pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 222 et pour que celui-ci applique la somme des retards sur le flux vocal émis par le téléphone 203 et transmis vers le téléphone 292
Le module mixeur vocal et retard 281 applique chaque retard sur les flux vocaux téléphoniques de la même façon que celle décrite par le module de gestion vocale et retard 181 en référence à la Fig. 5b.
Le module mixeur vocal et retard 281 applique les retards correspondant aux retards transmis par le module mixeur analyse des flux média IP 282 si ces retards sont à appliquer sur les flux vocaux actifs, ou en variante le module mixeur vocal et retard 281 applique les retards correspondant aux retards transmis par le module mixeur analyse des flux média IP 282.
En variante le module de mixage de flux média 282 lit dans les paquets RTCP SR reçus le champ 615 comprenant des informations sur la variance du temps passé entre l'arrivée des paquets RTP. Si la variance est relativement importante, par exemple de l'ordre d'une centaine de millisecondes, le module mixage de flux média 282 corrige les retards à appliquer en fonction de celle-ci. En effet, les ordinateurs 204, 223 et 295 ajustent la taille de leurs buffer de réception respectifs pour pallier à ce problème de variance ou gigue ce qui retarde bien entendu la restitution du flux vidéo.
Le module de mixage de flux média 282 à partir de ces informations de variance augmente alors le retard sur le flux audio correspondant par exemple d'un retard supplémentaire de l'ordre de 40 millisecondes.
Selon une autre variante, le flux de données audio est transmis sur le réseau asynchrone tandis que le flux de données vidéo est transmis sur le réseau synchrone. Le flux vidéo est alors retardé de la même façon que celle décrite précédemment. La synchronisation telle que décrite précédemment est effectuée à partir de paquets conformes au protocole RTCP. Bien entendu, d'autres types de paquets conformes à d'autres protocoles peuvent être utilisés pour déterminer le retard sur le réseau asynchrone.
A titre d'exemple, le serveur selon l'invention peut aussi fonctionner avec des applications client-client propriétaires différentes des applications "Microsoft Netmeeting H323", ou " FTR&D eConf SIP".
Le serveur selon l'invention peut aussi utiliser des paquets de type ICMP (Internet Control and Error Message Protocole). Pour cela, périodiquement, par exemple toutes les secondes, le serveur génère des paquets ICMP aux ordinateurs des abonnés et mémorise l'heure à laquelle ils sont envoyés. Le serveur mémorise aussi l'heure à laquelle chaque réponse émise par l'ordinateur est reçue et calcule ainsi le délai aller retour de transfert entre le serveur et chaque ordinateur. Il est à remarquer que dans ce cas, les ordinateurs doivent répondre immédiatement à la réception des paquets ICMP. L'invention telle que décrite peut aussi synchroniser deux flux audio, un des flux étant véhiculé sur un réseau de télécommunication asynchrone et l'autre étant véhiculé sur un réseau de télécommunication synchrone. L'invention peut aussi synchroniser de la même manière deux flux vidéo ou tout type de flux transitant sur des réseaux de télécommunication différents.
Bien entendu, la présente invention n'est nullement limitée aux modes de réalisation décrits ici, mais englobe, bien au contraire, toute variante à la portée de l'homme du métier.