FR 2965998 A1 20120413 FR 1058234 A 20101011 -1- Dispositif et procédé de mise en communication de terminaux reliés par un réseau de communication IP. Domaine de l'invention L'invention se situe dans le domaine des réseaux de télécommunication. Elle concerne un dispositif et un procédé de mise en communication de terminaux reliés par un réseau de communication IP (pour Internet Protocol en anglais). Art antérieur Les premiers services de mise en communication téléphonique ont été mis en ceuvre en reliant des 10 terminaux téléphoniques analogiques à un réseau téléphonique commuté (communément appelé RTC). Une installation téléphonique privée reliée à un réseau RTC est composée d'un circuit câblé reliant plusieurs terminaux téléphoniques analogiques branchés sur des prises en T/RJ45. II est possible de raccorder sur cette installation téléphonique privée une borne DECT (pour Digital Enhanced 15 Cordless Telephone en anglais, téléphone numérique sans fil amélioré en français) à laquelle N terminaux DECT peuvent être raccordés. Lorsqu'un appel téléphonique est envoyé vers cette installation téléphonique privée, il est transféré sur tous les terminaux reliés à l'installation. Il en est de même lorsqu'un appel est émis par un des terminaux de l'installation. Ainsi, si un terminal de l'installation privée est en communication active avec un terminal distant, c'est-à-dire un appel est 20 reçu ou émis par le terminal de l'installation privée vers le terminal distant, tous les autres terminaux de l'installation privée peuvent être mis en communication avec le terminal de l'installation privée et avec le terminal distant. Une telle installation téléphonique permet d'émettre des appels depuis n'importe quel terminal raccordé à l'installation, de recevoir des appels sur n'importe quel terminal raccordé à l'installation, et de transférer un appel reçu ou émis par un 25 terminal raccordé à l'installation vers un autre terminal de l'installation. Les clients d'un service téléphonique servis par un réseau commuté migrent de plus en plus vers un service téléphonique servis par un réseau IP. Le service téléphonique servis par un réseau IP utilise la technologie VoIP (pour Voice over IP en anglais, voix sur IP en français) pour transmettre les communications téléphoniques entre terminaux distants. Le service VoIP offre plusieurs 30 avantages aux clients qui y souscrivent notamment un coût plus faible des communications téléphoniques. La figure 1 illustre une installation téléphonique privée abonnée à un service de téléphonie VoIP sur un réseau de communication IP (100). Le service téléphonique VoIP est mis en oeuvre à l'aide d'une passerelle résidentielle (103) et d'un filtre ADSL (pour Asymetric Digital Subscriber Line) 35 (102). Le filtre ADSL (102) est branché à la ligne de cuivre du client à l'entrée de l'installation téléphonique privée, puis la passerelle résidentielle (103) est raccordée à ce filtre ADSL (102). La passerelle résidentielle (103) est ainsi raccordée au réseau IP (100). Une pluralité de terminaux analogique ou DECT (104) peuvent être connectés à l'installation téléphonique privée via la -2- passerelle résidentielle (103). La passerelle résidentielle (103) intègre une pile VoIP qui s'interface avec les terminaux de l'installation. La pile VoIP permet à la passerelle de gérer les appels vers ou en provenance de ces terminaux. Les services de téléphonie de type VoIP sont principalement mis en ceuvre sur des réseaux de communication de type IMS (pour IP Multimedia Subsystem en anglais) en utilisant le protocole SIP (pour Session Initiation Protocol en anglais). Pour pouvoir émettre ou recevoir des communications à partir de l'installation téléphonique privée, la passerelle résidentielle s'enregistre dans le coeur de réseau IMS par l'envoi régulier de messages SIP REGISTER. Le message SIP REGISTER comprend en particulier des informations d'enregistrement (ou informations de contexte), comme par exemple l'adresse IP de la passerelle résidentielle et le numéro de téléphone de la ligne téléphonique de l'installation correspondant à son identité publique, aussi appelée IMPU (pour IP Multimedia Public Identity). Il est également possible d'ajouter des terminaux (105, 107) de type softphone (téléphone logiciel) à l'installation téléphonique privée. Un terminal de type softphone peut être par exemple un ordinateur de type PC (pour Personal Computer en anglais), un PDA (pour Personal Digital Assistant en anglais), ou un téléphone mobile intelligent, appelé smartphone en anglais, ou bien une IPTV (Television connectée en IP). Ces terminaux nécessitent l'installation d'un logiciel de téléphonie VoIP pour pouvoir assurer la fonctionnalité de téléphonie. Pour qu'un client bénéficie du service de téléphonie VoIP de son installation téléphonique privée sur ces terminaux, les terminaux doivent être enregistrés en coeur de réseau IMS avec la même identité publique IMPU que l'installation téléphonique du client. Ces terminaux peuvent être soit connectés directement à l'installation téléphonique privée, soit utilisés en usage nomade. En connexion directe à l'installation téléphonique privée, le terminal de type softphone (105) est connecté au réseau IP (100) par l'intermédiaire d'une prise Ethernet de la passerelle résidentielle ou par l'intermédiaire d'une connexion sans fil (108) sur le réseau WiFi de la passerelle. En usage nomade, le terminal (107) se connecte au réseau IP (100) par l'intermédiaire d'un point d'accès (106) et d'une connexion sans fil WiFi (109). Plus généralement, cette connexion sans fil peut également être une connexion data sur un réseau mobile tels que par exemple: 3G, HSDPA (pour High Speed Downlink Packet Access en anglais), HSUPA (pour High Speed Uplink Packet Access en anglais), HSPA+ (pour High Speed Packet Access en anglais), WiMax (pour Worldwide Interoperability for Microwave Access en anglais) ou LTE (pour Long Term Evolution en anglais). Le terminal en usage nomade peut aussi être connecté à travers une connexion filaire (Ethernet par exemple) à un point d'accès du réseau IP.. Ainsi, un utilisateur d'une installation téléphonique privée peut disposer d'une pluralité de terminaux de différents types pour émettre ou recevoir des communications depuis son installation privée ou en dehors de cette installation tout en utilisant un unique numéro de téléphone (une unique identité publique dans le réseau IMS). Cependant, la technologie VoIP ne permet pas d'assurer des fonctionnalités qui étaient offertes par le réseau RTC, notamment le transfert d'appels entre des terminaux connectés à une même -3- installation privée et ayant la même identité publique IMPU. Par exemple, si un terminal distant émet un appel vers l'installation privée et que l'appel est décroché par un premier terminal de l'installation, par exemple un terminal mobile, mais que le propriétaire du terminal mobile n'était pas le destinataire de l'appel, il n'est pas possible de transférer l'appel sur un second terminal de l'installation privée. En effet, chaque terminal relié à l'installation est considéré par la passerelle résidentielle de manière indépendante. Lorsqu'un premier terminal de l'installation téléphonique (105) est en communication avec un terminal distant (101), le signal de communication est transmis entre le premier terminal de l'installation (105) et le terminal distant (101) via le réseau de communication IP (100) mais le signal de communication n'est pas répliqué pour être transmis vers les autres terminaux de l'installation (104). De même, lorsque le premier terminal de l'installation est en usage nomade (107) et qu'il est en communication avec un terminal distant (101), le signal de communication n'est pas répliqué vers les autres terminaux de l'installation (104, 105). Une solution est proposée dans la demande de brevet GB2386286. Dans cette demande, un convertisseur est intégré dans la passerelle résidentielle afin de convertir les signaux numériques ADSL d'une communication VoIP en signaux analogiques. Les signaux analogiques sont ensuite envoyés par la passerelle résidentielle vers les terminaux reliés à l'installation téléphonique. Un filtre passe-bas est intercalé entre chaque terminal de l'installation et la prise qui le relie à l'installation. Le filtre passe-bas bloque tout passage de signaux numériques vers le terminal. Cette solution reproduit le fonctionnement du RTC sur une installation téléphonique privée servie par un service de téléphonie VoIP. Inconvénient de l'art antérieur Cependant, cette solution s'applique à une installation téléphonique ne comprenant que des terminaux de type analogique RTC ou DECT. Elle ne s'applique pas à une installation téléphonique comprenant des terminaux de type softphone. Elle ne s'applique pas non plus pour des terminaux en mode nomade. Il existe donc un besoin dans l'art de la technique actuel pour reproduire le fonctionnement du RTC, notamment le transfert de communication entre terminaux, sur une installation téléphonique privée servie par un service de téléphonie VoIP et comprenant des terminaux de type softphone reliés directement à cette installation ou en mode nomadisme, chacun des terminaux partageant la même identité publique IMPU. Exposé de l'invention Un des buts de l'invention est d'apporter des améliorations par rapport à l'état de la technique. Elle propose à cet effet un dispositif de mise en communication dans un réseau de communication IP entre plusieurs utilisateurs, un utilisateur possédant une pluralité de terminaux ayant une unique identité publique dans le réseau de communication, au moins un terminal d'un premier utilisateur -4- étant en communication avec au moins un terminal d'un second utilisateur, caractérisé en ce qu'il comporte: des moyens de réception d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication, des moyens de réservation d'une ressource de pont de conférence, des moyens d'utilisation de la ressource réservée pour introduire le second terminal dans la communication Par communication, on entend ici tout type de communication multimédia: audio, vidéo, données. Le dispositif selon l'invention permet ainsi d'introduire un second terminal d'un premier utilisateur dans une communication établie entre un premier terminal du premier utilisateur et un terminal d'un deuxième utilisateur distant, les premier et second terminaux du premier utilisateur ayant la même identité publique. Pour cela, le dispositif réserve une ressource de type pont de conférence à la communication. Le pont de conférence est ensuite utilisé pour mettre en communication le au moins premier terminal du premier utilisateur, le au moins premier terminal du second utilisateur et le second terminal du premier utilisateur. Le dispositif selon l'invention permet ainsi de transférer entre des terminaux ayant la même identité publique, des communications reçues ou émises par un de ces terminaux. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux caractéristiques du dispositif défini ci-dessus. Selon un mode particulier de réalisation de l'invention, le dispositif de l'invention comporte des moyens d'adaptation du flux de communication vers un terminal du premier ou du second utilisateur en fonction des capacités de ce terminal et/ou d'une requête provenant d'un des terminaux participant à la communication. Ainsi par exemple, si le second terminal d'un premier utilisateur ne supportant que les communications en mode audio est introduit dans une communication établie en mode audio et vidéo, le dispositif adapte les flux de communication vers ce second terminal en fonction de ses capacités afin qu'il ne reçoive que les flux audio de la communication multimédia. Les deux premiers terminaux peuvent poursuivre la communication en mode audio et vidéo sans être bridés par la capacité plus faible du second terminal du premier utilisateur introduit dans la communication. A l'inverse, si une communication en mode audio est établie entre un premier terminal d'un premier utilisateur et un terminal d'un second utilisateur, le terminal du second utilisateur ayant la capacité de supporter une communication en mode audio et vidéo et qu'un second terminal du premier utilisateur ayant aussi la capacité de supporter une communication en mode audio et vidéo est introduit dans la communication, une requête d'adaptation de la communication établie peut être envoyée par le second terminal du premier utilisateur afin que ce dernier et le terminal du second utilisateur bascule en mode audio et vidéo alors que le premier terminal du premier utilisateur reste -5- en mode audio. Le dispositif adapte alors les flux de communication vers tous les terminaux afin qu'ils reçoivent chacun les flux de communication qu'ils sont capables de décoder. Le dispositif procure ainsi l'avantage d'adapter les flux de communication en fonction des capacités des terminaux sans limiter le mode de la communication établie au mode du terminal ayant les plus faibles capacités. Selon un mode particulier de réalisation de l'invention, le dispositif comporte des moyens de réception d'un message de déconnexion d'un premier terminal du premier utilisateur et des moyens de libération de la ressource pont de conférence après vérification qu'un seul terminal par utilisateur participe à la communication. Ainsi, lorsque le dispositif reçoit un message de déconnexion d'un premier terminal du premier utilisateur, par exemple lorsque l'usager du premier terminal raccroche, le dispositif libère la ressource pont de conférence réservée pour la communication après avoir vérifié que chaque utilisateur n'a qu'un seul terminal en communication. Selon ce mode particulier de l'invention, le dispositif procure l'avantage de libérer une ressource lorsque celle-ci n'est plus nécessaire à la communication et ainsi d'optimiser l'utilisation des ressources. La ressource pont de conférence peut alors être réutilisée pour une nouvelle communication entre de nouveaux utilisateurs. L'invention concerne également un procédé de mise en communication dans un réseau de communication IP entre plusieurs utilisateurs, un utilisateur possédant une pluralité de terminaux ayant une unique identité publique dans le réseau de communication, au moins un terminal d'un premier utilisateur étant en communication avec au moins un terminal d'un second utilisateur, caractérisé en ce qu'il comporte les étapes suivantes: réception d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication, réservation d'une ressource de pont de conférence, utilisation de la ressource réservée pour introduire le second terminal dans la communication. Le procédé selon l'invention permet d'introduire un second terminal d'un premier utilisateur dans une communication déjà établie entre un premier terminal du premier utilisateur et un terminal d'un second utilisateur, les premier et second terminaux du premier utilisateur ayant une unique identité publique. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé défini ci-dessus. Selon un mode particulier de réalisation de l'invention, le procédé selon l'invention comporte une étape d'adaptation du flux de communication vers un terminal du premier ou du second utilisateur en fonction des capacités de ce terminal et/ou d'une requête provenant d'un des terminaux participant à la communication. Le procédé selon l'invention procure l'avantage d'adapter les flux -6- de communication multimédia entre les terminaux participant à la communication en fonction de leurs capacités et à la demande éventuelle d'un des terminaux de la communication. Selon un mode particulier de réalisation de l'invention, le procédé selon l'invention comporte une étape de réception d'un message de déconnexion d'un premier terminal du premier utilisateur, et une étape de libération de la ressource de pont de conférence après vérification qu'un seul terminal par utilisateur participe à la communication. Ce mode particulier de l'invention offre l'avantage d'optimiser les ressources utilisées pour la mise en communication des terminaux. Selon un mode particulier de réalisation de l'invention, l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le second terminal du premier utilisateur après un temps prédéterminé de temporisation. Selon ce mode particulier de l'invention, un usager accède facilement au service décrit dans la présente invention simplement en décrochant le terminal et en attendant un temps de temporisation prédéterminé. Selon un autre mode particulier de réalisation de l'invention, l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le second terminal du premier utilisateur, le message comportant dans son champ destinataire un numéro de service prédéterminé. Selon ce mode particulier de l'invention, la requête de participation à la communication est envoyée à l'initiative de l'usager du second terminal du premier utilisateur qui a composé un numéro de service prédéterminé sur le terminal afin d'accéder au service de mise en communication proposée par l'invention. Ainsi un usager accède facilement au service décrit dans la présente invention sans avoir à attendre un temps de temporisation prédéterminé, en composant un numéro de service prédéterminé. Selon un mode particulier de réalisation de l'invention, l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le premier terminal du premier utilisateur, le message comportant dans son champ destinataire un numéro de service prédéterminé. Selon ce mode particulier de l'invention, la requête de participation à la communication est envoyée à l'initiative de l'usager du premier terminal du premier utilisateur. Ce mode de réalisation est particulièrement avantageux dans le cas d'un usage du premier terminal en mode nomade. Dans ce cas, le premier terminal n'est pas physiquement dans le même lieu que les autres terminaux de la même installation téléphonique, les usagers des autres terminaux ne peuvent alors pas savoir que la communication décrochée par le premier terminal ne lui était pas destiné. L'usager du premier terminal peut alors facilement demander le transfert de la communication vers les autres terminaux de la même installation téléphonique en composant un numéro de service prédéterminé.40 -7- Selon un autre mode particulier de réalisation de l'invention, l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le premier terminal du premier utilisateur après un temps prédéterminé de temporisation. L'usager en mode nomade peut facilement demander le transfert de la communication vers les autres terminaux de l'installation téléphonique en mettant son terminal en double appel et en attendant un temps de temporisation prédéterminé. L'invention a également pour objet un serveur dans un réseau de communication IP qui comprend le dispositif décrit précédemment et qui présente les mêmes avantages. L'invention concerne également une passerelle reliée à un réseau de communication IP qui comprend le dispositif décrit précédemment. Le dispositif compris dans cette passerelle permet une mise en ceuvre plus simple de l'invention mais cette solution n'offre pas la possibilité de transfert de communications par le premier terminal lorsqu'il est en mode nomade. Selon un mode particulier de réalisation de l'invention, le dispositif comprend au moins un serveur d'application et au moins un serveur de pont de conférence. Ce mode particulier permet l'utilisation de serveurs de pont conférence existants pour la mise en oeuvre de la présente invention. 20 Enfin, l'invention a pour objet un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de mise en communication décrit précédemment lorsque ledit programme est exécuté par un ordinateur. L'invention concerne également un support d'information lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 25 Liste des figures D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels: 30 - La figure 1, commentée précédemment, présente une installation téléphonique reliée à un réseau de communication IP et servie par un service de téléphonie VoIP. - La figure 2 présente l'installation téléphonique servie par un service de téléphonie VoIP et reliée à un réseau de communication IP dans lequel est intégré le dispositif de l'invention. La figure 3 présente un schéma des principales étapes du procédé de mise en 35 communication selon un mode particulier de réalisation de l'invention. - La figure 4 présente un schéma des principales étapes du procédé de mise en communication selon un mode particulier de réalisation de l'invention. - La figure 5 présente un schéma des principales étapes du procédé de libération de ressource selon l'invention. 15 -8- - La figure 6 illustre de manière schématique les messages échangés entre les terminaux de communication et le serveur d'application de conférence lors de la mise en communication selon un mode de réalisation de l'invention. - La figure 7 illustre de manière schématique les messages échangés entre les terminaux de la communication et le serveur d'application de conférence lors de la mise en communication selon un mode de réalisation de l'invention. La figure 8 illustre de manière schématique les messages échangés entre les terminaux de la communication et le serveur d'application de conférence lors de l'étape de libération de la ressource selon l'invention La figure 9 présente la structure d'un dispositif de mise en communication selon un mode de réalisation de l'invention. Description d'un mode particulier de réalisation de l'invention La figure 2 présente une installation téléphonique d'un premier utilisateur servie par un service de téléphonie VoIP et reliée à un réseau de communication IP (200) dans lequel est intégré le dispositif de l'invention (207) que l'on nommera par la suite serveur d'application de conférence. On considère ici un réseau de communication IP intégrant un cceur de réseau basé sur une plate-forme IMS SIP, l'invention s'applique aussi à d'autres types de réseau. L'installation téléphonique comprend une passerelle résidentielle (203) reliée au réseau par un filtre ADSL (202). Un premier terminal (205) de type softphone est relié à l'installation téléphonique par l'intermédiaire de la passerelle résidentielle (203) via une connexion WiFi (211) du réseau local de la passerelle résidentielle. Un second terminal (204) est connecté à la passerelle résidentielle via une liaison filaire. Le premier terminal (205) et le second terminal (204) possède la même identité publique pour le cceur de réseau IMS. Deux serveurs d'application sont connectés sur la plate-forme IMS du coeur de réseau: un serveur d'application de conférence (207) comprenant le dispositif de l'invention, un serveur d'application téléphonique (206). Les deux serveurs d'applications sont pilotés ici à l'aide du protocole SIP. Le fonctionnement du serveur d'application téléphonique est connu, il gère les services téléphoniques classiques associés aux appels entrants ou sortants des installations téléphoniques. De tels services sont par exemple: le secret d'appel, le filtrage d'appel sortant, le renvoi d'appel, l'affichage du numéro appelant, ... Le serveur d'application de conférence (207) s'interface avec le serveur d'application téléphonique (206) lorsqu'un appel est émis ou reçu par l'installation téléphonique d'un utilisateur qui bénéficie du service de transfert d'appels lié à l'invention. Pour un utilisateur qui bénéficie du service de transfert d'appels lié à l'invention, lorsqu'un appel est émis depuis un terminal de cet utilisateur, les services du serveur d'application de conférence sont -9- déclenchés en premier, puis ceux du serveur d'application téléphonique. Les messages SIP de communication issus des terminaux de l'utilisateur seront d'abord envoyés au serveur d'application de conférence puis au serveur d'application téléphonique. Lorsqu'un appel est reçu par un terminal du même utilisateur, les services du serveur d'application téléphonique sont déclenchés en premier, puis ceux du serveur d'application de conférence. Les messages SIP de communication reçus par le terminal de l'utilisateur passeront d'abord par le serveur d'application téléphonique, puis par le serveur d'application de conférence. Il est à noter que les deux serveurs d'application peuvent être intégrés dans un unique serveur d'application. Un terminal d'un deuxième utilisateur distant (201) est connecté au réseau de communication (200). Le terminal du deuxième utilisateur (201) émet une communication vers l'installation téléphonique du premier utilisateur. Comme tous les terminaux du premier utilisateur sont enregistrés avec la même identité publique par le cceur de réseau IMS, tous les terminaux du premier utilisateur sonnent en parallèle jusqu'à ce qu'un des terminaux décroche l'appel. L'appel est décroché par le premier terminal du premier utilisateur (205). Le coeur de réseau IMS annule alors la présentation de l'appel vers les autres terminaux. L'appel n'étant pas destiné à l'usager du premier terminal du premier utilisateur, l'usager du second terminal (204) intercepte l'appel en décrochant le second terminal. Il attend alors n secondes. Au bout des n secondes de temporisation, le terminal envoie une requête au serveur d'application de conférence (207). Le serveur d'application de conférence ne relaie pas cette demande d'appel vers le serveur d'application téléphonique mais traite localement cet appel en mettant en communication les trois terminaux (201, 204 et 205) à travers une ressource de pont de conférence. Le serveur d'application de conférence comprend des moyens (207a) de réception et d'émission de messages depuis ou vers le réseau IP ainsi qu'un ensemble de ressources de pont de conférence (207b). Une ressource de pont conférence est constituée notamment par une adresse IP et un ensemble de ports de connexion alloués chacun à un terminal de la communication en cours. Chaque terminal communique à travers le pont de conférence en envoyant des flux de communication à l'adresse IP du pont de conférence et sur le port qui lui a été attribué. Le pont de conférence collecte les flux de communication reçus de chaque terminaux, effectue un transcodage des flux de communication si besoin, multiplexe les flux de communication et les renvoie à chaque terminal de la communication par son port. Selon un autre mode de réalisation de l'invention, l'usager décroche le terminal et compose un numéro de service. Le terminal envoie alors la requête au serveur d'application de conférence (207). Ce mode de réalisation a l'avantage de gagner du temps par rapport à la temporisation, mais présente la contrainte de devoir composer un numéro de service. Cependant, ce numéro de service peut être associé à une touche dédiée sur le terminal pour faciliter l'expérience de l'usager. Selon un autre mode de réalisation de l'invention, l'appel est initialement décroché par le premier terminal du premier utilisateur, ce premier terminal pouvant par exemple être en mode nomade -10- (209). Il est alors relié à l'installation téléphonique du premier utilisateur, via le réseau de communication IP (200), par l'intermédiaire d'un point d'accès (208) et d'une connexion WiFi (210). Selon ce mode de réalisation, l'usager du premier terminal (209) n'étant pas dans le même lieu que les autres usagers de l'installation téléphonique, les autres usagers de l'installation téléphonique ne peuvent pas savoir que l'appel ne lui est pas destiné. L'usager du premier terminal demande donc le transfert de l'appel vers les autres terminaux de l'installation en mettant l'appel reçu en attente et en composant un numéro de service sur le terminal. Le terminal envoie alors une requête au serveur d'application de conférence (207). Le serveur d'application de conférence transfère l'appel en le renvoyant sur tous les terminaux de l'installation téléphonique, sauf le premier terminal. Selon un autre mode particulier de l'invention, l'usager du premier terminal ne compose pas de numéro de service mais attend n secondes de temporisation. La requête de transfert est alors envoyée par le premier terminal après le temps de temporisation vers le serveur d'application de conférence. Le procédé de mise en communication selon un mode de réalisation est décrit ci-après à l'aide de la figure 3. On considère qu'une communication est déjà établie entre un premier terminal d'un premier utilisateur (par exemple 205 ou 209 sur la figure 2) et un terminal d'un second utilisateur (201 sur la figure 2). Le procédé comporte une première étape (300) de réception d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur (par exemple 204, sur la figure 2) à la communication. Le premier terminal et le second terminal faisant partie de la même installation téléphonique, ils possèdent la même identité publique. Comme une communication est déjà établie avec un des terminaux de l'installation téléphonique, le serveur d'application de conférence va utiliser une ressource de pont de conférence pour introduire dans la communication existante le second terminal. Pour cela, le serveur d'application de conférence réserve une ressource de pont de conférence (310) pour cette communication, puis il met en communication (311) les trois terminaux avec le pont de conférence. La figure 6 illustre les messages échangés entre les terminaux et le serveur d'application de conférence lors de la mise en communication des trois terminaux. On considère qu'une communication (606) est déjà établie entre un premier terminal d'un premier utilisateur, par exemple un terminal de type softphone (600) et un terminal d'un second utilisateur (605). Une requête de participation d'un second terminal du premier utilisateur (601) à la communication est envoyée par ce terminal au serveur d'application de conférence. Cette requête est un message SIP INVITE (610) envoyé par le terminal (601) vers le cceur de réseau IMS (602) qui l'envoie à son tour (611) vers le serveur d'application de conférence (603). Ce message comporte dans son champ SDP (pour Session Description Protocol en anglais) la description des capacités multimédia tels que les codecs supportés du terminal (601) dont est issu le message, dans son champ émetteur l'identité publique de l'installation et dans son champ destinataire soit une valeur vide, soit un numéro de service, selon que l'usager du terminal a attendu une temporisation après avoir décroché ou a composé un numéro de service. Pour introduire le second terminal du premier utilisateur dans la communication, le serveur d'application de conférence envoie en réponse un message SIP 200OK (612) au second terminal du premier utilisateur relayé par le réseau IMS (613), le message comportant dans son champ SDP la description des capacités multimédia du pont de conférence. Le serveur d'application de conférence reçoit ensuite un message d'acquittement SIP ACK (614) par le second terminal, relayé par le réseau IMS (615). Le second terminal (601) peut alors communiquer avec le pont de conférence du serveur d'application de conférence (603) par un flux (616) de communication RTP (pour Real-time Transport Protocol en anglais). Ce protocole est utilisé pour les flux de communication multimédia sur les réseaux IP. Le serveur d'application de conférence invite ensuite le premier terminal du premier utilisateur (600) à participer à la communication via le pont de conférence en envoyant un message SIP Re-INVITE (620) au premier terminal relayé par le réseau IMS (621). Ce message Re-INVITE comporte dans son champ SDP la description des capacités multimédia du pont de conférence. Le serveur d'application de conférence reçoit alors un message SIP 200OK (622) du premier terminal, relayé par le réseau IMS (623), le message comportant dans son champ SDP la description des capacités multimédia du premier terminal. Le serveur d'application de conférence acquitte enfin la réception du message 200OK par l'envoi d'un message SIP ACK (624) vers le premier terminal relayé par le réseau IMS (625). Le premier terminal (600) peut alors communiquer avec le pont de conférence du serveur d'application de conférence (603) par un flux (626) de communication RTP. De la même manière, le serveur d'application de conférence invite le terminal du second utilisateur (605) à participer à la communication via le pont de conférence en envoyant un message SIP Re-INVITE (630) au terminal du second utilisateur relayé par le réseau IMS (631), le serveur d'application téléphonique (632), et encore le réseau IMS (633). Ce message Re-INVITE comporte dans son champ SDP la description des capacités multimédia du pont de conférence. Le serveur d'application de conférence reçoit alors un message SIP 200OK (634) du terminal du second utilisateur, le message ayant pris le chemin inverse du message Re-INVITE précédent (635, 636, 637), et comportant dans son champ SDP la description des capacités multimédia du terminal. Le serveur d'application de conférence acquitte enfin la réception du message 200OK par l'envoi d'un message SIP ACK (638, 639, 640, 641) vers le terminal du second utilisateur. Le terminal du second utilisateur (605) peut alors communiquer avec le pont de conférence du serveur d'application de conférence (603) par un flux (642) de communication RTP. Les trois terminaux sont ainsi en communication à travers le pont de conférence du serveur d'application de conférence. Selon un autre mode de réalisation de l'invention, l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur (601) à la communication existante (606) correspond à la réception d'un message INVITE envoyé par le premier terminal du premier utilisateur. L'usager du premier terminal du premier utilisateur est par exemple en mode nomade, il demande le transfert de l'appel reçu vers les autres terminaux de l'installation téléphonique. Pour cela, le terminal du second utilisateur est mis en attente, puis le serveur d'application de conférence reçoit un message SIP INVITE du premier terminal du premier utilisateur. Comme une communication -12- est déjà établie entre un terminal de l'installation téléphonique du premier utilisateur et un terminal du second utilisateur, le serveur d'application de conférence ne relaie pas la demande d'appel du premier terminal du premier utilisateur, il va transférer la communication existante vers les autres terminaux de l'installation. Pour cela, le serveur d'application de conférence invite le premier terminal du premier utilisateur sur le pont de conférence à l'aide d'un message SIP 200OK, comportant le SDP du pont de conférence, en réponse au message INVITE reçu. Ensuite, le serveur d'application de conférence envoie un message SIP REGISTER au coeur de réseau IMS, le message comportant l'identité publique de l'installation téléphonique du premier utilisateur et ne contenant pas d'adresse de contact AoC (Address Of Record). Le serveur d'application de conférence reçoit en réponse un message SIP 200OK comportant la liste de contact des terminaux de l'installation téléphonique. Le serveur d'application de conférence peut alors envoyer un message SIP INVITE à tous les terminaux de l'installation téléphonique, sauf au premier terminal, le message comportant le SDP du pont de conférence. Lorsque le serveur d'application de conférence reçoit un message SIP 200OK d'un des terminaux de l'installation téléphonique, il annule la présentation de l'appel vers les autres terminaux de l'installation. Enfin le serveur d'application de conférence invite le terminal du second utilisateur à communiquer avec les deux autres terminaux à travers le pont de conférence en lui envoyant un message SIP INVITE comportant le SDP du pont de conférence. Selon un mode particulier de réalisation de l'invention, le serveur d'application de conférence procède à une étape d'adaptation du flux de communication RTP envoyé à un terminal. Cette adaptation est faite soit parce que le terminal n'a pas les capacités suffisantes de recevoir le flux de communication multimédia, soit parce que l'usager du terminal souhaite changer le mode de la communication, par exemple d'une communication en mode audio, il souhaite passer en mode audio et vidéo ou l'inverse. La figure 4 illustre le procédé de mise en communication selon ce mode de réalisation de l'invention. On considère ici qu'une communication multimédia audio et vidéo est déjà établie entre un premier terminal d'un premier utilisateur et un terminal d'un second utilisateur. Dans une première étape (400), le serveur d'application de conférence reçoit une requête de participation d'un second terminal du premier utilisateur à la communication. Le second terminal du premier utilisateur possède la même identité publique que le premier terminal du premier utilisateur car ils font partie de la même installation téléphonique. De plus, le second terminal du premier utilisateur ne supporte que les communications en mode audio. Le serveur d'application de conférence utilise une ressource de pont de conférence pour introduire dans la communication existante le second terminal. Pour cela, le serveur d'application de conférence réserve une ressource pont de conférence (410) pour cette communication, puis introduit (411) en mode audio le second terminal du premier utilisateur dans la communication. Le serveur d'application de conférence vérifie ensuite (412) si le pont de conférence réservé supporte le mode audio et vidéo de la communication établie initialement. -13- Si le pont de conférence a la capacité (413) de supporter le mode audio et vidéo, il met en communication (415) le premier terminal du premier utilisateur et le terminal du second utilisateur avec le pont de conférence en mode audio et vidéo. Si le pont de conférence n'a pas la capacité (414) de supporter le mode audio et vidéo, le serveur d'application de conférence peut selon l'offre de service soit (416) déconnecter le second terminal du premier utilisateur du pont de conférence et lui envoyer un message vocal lui indiquant que la ressource pour le mettre en communication n'est pas disponible, soit mettre en communication (416) le premier terminal du premier utilisateur et le terminal du second utilisateur avec le pont de conférence en mode audio. Ainsi selon l'offre proposée par l'opérateur de service, si le pont de conférence n'a pas la capacité suffisante de supporter le mode de la communication, il est possible soit de ne pas connecter le second terminal du premier utilisateur afin de ne pas impacter la communication déjà établie, soit de diminuer la qualité de la communication déjà établie et d'introduire le second terminal du premier utilisateur. Les messages SIP échangés entre les terminaux et le serveur d'application de conférence lors de la mise en communication selon ce mode de réalisation de l'invention sont présentés sur la figure 7. Pour plus de clarté dans la figure et les messages échangés, le dispositif comprenant le serveur d'application de conférence (702) et le serveur de pont de conférence (703) ont été représentés comme deux entités distinctes. Selon le mode de réalisation de l'invention, la ressource de pont de conférence peut être une ressource interne au serveur d'application de conférence ou une ressource externe au serveur d'application de conférence. Dans le cas d'une ressource externe au serveur d'application de conférence, la ressource de pont de conférence correspond à un serveur de pont de conférence dont le fonctionnement est connu. De même pour plus de clarté dans la figure, le passage des messages par le coeur de réseau IMS et par le serveur d'application téléphonique ont été omis. On considère ici une communication en mode audio et vidéo déjà établie (705) entre un premier terminal d'un premier utilisateur (700) et un terminal d'un second utilisateur (704). L'usager d'un second terminal du premier utilisateur (701) souhaite participer à la communication, il décroche alors le terminal et compose un numéro de service ou attend n secondes. Le serveur d'application de conférence reçoit alors un message (706) INVITE venant du second terminal du premier utilisateur (701) et comportant dans son champ SDP la description des capacités multimédia du second terminal. Le second terminal ne supporte que le mode de communication audio. Comme une communication est déjà établie avec un terminal du premier utilisateur, le serveur d'application de conférence envoie un message (707) SIP INVITE au serveur de pont de conférence (703) comportant un champ SDP vide, afin de réserver une ressource pont de conférence pour la communication. L'envoi du message comportant un champ SDP vide permet de réserver une ressource pont de conférence ayant le maximum de capacités. Le serveur d'application de conférence reçoit alors un message (708) SIP 200OK venant du serveur de pont de conférence et comportant dans son champ SDP la description des capacités multimédia du -14- pont de conférence, ces paramètres correspondant ici à ses plus hautes capacités pour les modes audio, vidéo et données. Le serveur d'application de conférence mémorise le champ SDP complet du pont de conférence et renvoie un message (709) SIP ACK au serveur de pont de conférence, le message comportant dans son champ SDP la description des capacités multimédia du second terminal du premier utilisateur, ces paramètres indiquant que ce terminal ne supporte que le mode de communication audio. Le serveur d'application de conférence envoie ensuite un message (710) SIP 2000K vers le second terminal du premier utilisateur, le message comportant dans son champ SDP la description des capacités multimédia du pont de conférence en mode audio. Le serveur d'application de conférence reçoit enfin un message (711) d'acquittement du second terminal. Le second terminal (701) peut alors communiquer avec le pont de conférence (703) par un flux (712) de communication RTP audio. Le serveur d'application de conférence va ensuite mettre en communication les terminaux de la communication initiale avec le pont de conférence. Le serveur d'application de conférence a mémorisé la description des paramètres du pont de conférence qui lui avait été envoyée. Cette description indiquant que le pont de conférence supporte les communications en mode audio, vidéo et données, le serveur d'application de conférence va pouvoir mettre en communication audio et vidéo les terminaux de la communication initiale avec le pont de conférence. Le serveur d'application de conférence envoie alors un message (713) SIP INVITE vers le serveur de pont de conférence, sans préciser le champ SDP mais en indiquant dans le champ Request URI l'adresse de contact retournée par le serveur de pont de conférence dans le message SIP 2000K (708) lors de l'établissement de la première connexion entre le serveur d'application de conférence et le serveur de pont de conférence. Ceci pour que le serveur d'application de conférence utilise la même ressource de pont de conférence que pour la communication audio avec le second terminal (701). Le serveur d'application de conférence reçoit en réponse un message (714) SIP 2000K du serveur de pont de conférence comportant la description des capacités multimédia audio, vidéo et données du pont de conférence. L'envoi du message SIP INVITE et la réception du message SIP 2000K est nécessaire pour l'introduction d'un nouveau terminal dans la communication avec le pont de conférence. En effet, le message SIP 2000K envoyé par le serveur de pont de conférence contient les informations nécessaires à la connexion du terminal sur la communication, ces informations sont par exemple l'adresse de contact du pont de conférence réservé pour la communication et le numéro de port que devra utiliser le terminal pour communiquer. Chaque terminal participant à la communication utilisant un numéro de port différent. Le serveur d'application de conférence envoie ensuite un message (715) SIP Re-INVITE au premier terminal du premier utilisateur (700), le message comportant le SDP du pont de conférence en mode audio et vidéo. Le serveur d'application de conférence a supprimé du SDP le paramètre concernant le mode "données" du pont de conférence car la communication initialement établie ne comportait pas de flux de mode "données". Le serveur d'application de conférence reçoit alors un message (716) SIP 2000K du premier terminal du premier utilisateur, le message -15- comportant le SDP audio et vidéo de ce terminal. Le serveur d'application de conférence envoie un message (717) SIP ACK d'acquittement au premier terminal. Enfin, le serveur d'application de conférence envoie un message (718) SIP ACK au serveur de pont de conférence, le message comportant le SDP audio et vidéo du premier terminal. Le premier terminal (700) peut alors communiquer avec le pont de conférence (703) par des flux (719) de communication RTP audio et vidéo. De la même manière, le premier terminal du second utilisateur (704) est mis en communication avec le pont de conférence (703) par des flux (726) de communication RTP audio et vidéo. L'envoi des messages (720-725) est similaire à ce qui a été fait pour le premier terminal du premier utilisateur. Ainsi chaque terminal est en communication avec les autres terminaux à travers le pont de conférence, chaque terminal ne recevant que les flux de communication multimédia qu'il est capable de décoder. Le serveur d'application de conférence peut aussi adapter les flux de communication RTP au cours de la communication à travers le pont de conférence. Par exemple, pour une communication en mode audio et vidéo, un des usagers des terminaux de la communication peut demander à passer en mode audio uniquement. Le serveur d'application de conférence invite alors tous les terminaux de la communication en cours à passer en mode audio en leur envoyant des messages SIP Re-INVITE comportant le SDP du pont de conférence et indiquant le mode audio. La figure 5 illustre un autre mode particulier de l'invention. Ce procédé s'applique à une communication existante entre plusieurs terminaux à travers une ressource de pont de conférence réservée par le dispositif de l'invention. La première étape (500) de la figure 5 correspond à la réception par le dispositif de l'invention d'un message de déconnexion d'un premier terminal du premier utilisateur. Dans cette étape, l'usager du premier terminal ne souhaitant plus participer à la communication en cours, il raccroche le terminal. Le dispositif de l'invention reçoit alors un message de déconnexion envoyé par le premier terminal. Le dispositif de l'invention vérifie (510) si seulement deux terminaux participent à la communication en comptant le nombre de terminaux toujours en communication à travers le pont de conférence. Si plus de deux terminaux participent à la communication (512), il ne fait rien. Si seulement deux terminaux participent à la communication (511), le dispositif libère alors la ressource pont de conférence (513) et met les deux terminaux en communication directe, sans passer par le pont de conférence. La figure 8 illustre les messages SIP échangés entre les terminaux et le dispositif de l'invention lors des étapes de ce procédé. Un premier (800) et un deuxième terminal (801) d'un premier utilisateur ainsi qu'un terminal (805) d'un deuxième utilisateur sont en communication à travers un pont de conférence réservé par un serveur d'application de conférence (803). Le premier et le deuxième terminal du premier utilisateur possèdent la même identité publique. Le premier terminal du premier utilisateur, par -16- exemple un terminal de type softphone, est en communication (807) avec les autres terminaux via le pont de conférence. De même le deuxième terminal du même utilisateur, par exemple un terminal relié à la passerelle résidentielle de l'installation téléphonique, est en communication (806) via le pont de conférence, ainsi que pour le terminal du deuxième utilisateur (808). L'usager du premier terminal du premier utilisateur ne souhaite plus participer à la communication, il raccroche alors son terminal. Le serveur d'application de conférence reçoit alors un message SIP BYE (809) relayé (810) par le réseau IMS ((802). Le message SIP BYE indique au serveur d'application de conférence que le premier terminal du premier utilisateur s'est déconnecté. Le serveur d'application de conférence envoie alors un message SIP 200OK (811) relayé (812) par le réseau IMS au premier terminal du premier utilisateur. Le serveur d'application de conférence constate qu'il n'y a plus que deux terminaux en communication à travers le pont de conférence, il va alors libérer la ressource pont de conférence et mettre en communication les deux terminaux restants en communication directe. Pour cela, il envoie un message SIP Re-INVITE (813), relayé par le réseau IMS (814) au deuxième terminal du premier utilisateur. Ce message SIP Re-INVITE ne contient pas de SDP. En réponse, le serveur d'application de conférence reçoit un message SIP 200OK (815), relayé (816) par le réseau IMS, du deuxième terminal du premier utilisateur comportant dans son champ SDP la description des capacités multimédia du deuxième terminal du premier utilisateur. Le serveur d'application de conférence envoie ensuite un message (817) SIP Re-INVITE, relayé successivement (818) par le réseau IMS (802), (819) le serveur d'application téléphonique (804), (820) le réseau IMS (802), jusqu'au terminal du deuxième utilisateur. Ce message SIP Re-INVITE comporte dans son champ SDP la description des capacités multimédia du deuxième terminal du premier utilisateur. Le serveur d'application de conférence reçoit en réponse un message (821) 200OK venant du terminal du deuxième utilisateur, ce message prenant le chemin inverse du précédent (822, 823, 824). Ce message comporte dans son champ SDP la description des capacités multimédia du terminal du deuxième utilisateur. Le serveur d'application de conférence peut ainsi acquitter le message SIP 200OK reçu du deuxième terminal du premier utilisateur en envoyant un message (825) SIP ACK, relayé par le réseau IMS (826), au deuxième terminal du premier utilisateur. Ce message SIP ACK comporte dans son champ SDP la description des capacités multimédia du terminal du deuxième utilisateur. Enfin, le serveur d'application de conférence acquitte le message SIP 200OK du terminal du deuxième utilisateur par l'envoi d'un message (827) SIP ACK au terminal du deuxième utilisateur, ce message étant relayé par le réseau IMS (828), le serveur d'application téléphonique (829), le réseau IMS (830). Le deuxième terminal du premier utilisateur (801) et le terminal du deuxième utilisateur (805) sont alors en communication directe (831). Le serveur d'application de conférence a libéré la ressource pont de conférence qui va pouvoir être réservée pour d'autres communications -17- Comme illustré en figure 9, le dispositif selon l'invention comprend une mémoire (90) comprenant une mémoire tampon, une unité de traitement (91), équipée par exemple d'un microprocesseur NP, et pilotée par le programme d'ordinateur (92), mettant en ceuvre le procédé selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur (92) sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement (91). Le microprocesseur de l'unité de traitement (91) met en oeuvre les étapes du procédé selon l'invention décrit précédemment et notamment les étapes de réception d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication, réservation d'une ressource de pont de conférence et utilisation de la ressource réservée pour introduire le second terminal dans la communication, selon les instructions du programme d'ordinateur (92). Pour cela, le dispositif comprend, outre la mémoire tampon (91), des moyens de réception d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication existante entre un premier terminal d'un premier utilisateur et un terminal d'un second utilisateur, les premier et second terminaux du premier utilisateur possédant la même identité publique, des moyens de réservation d'une ressource de type pont de conférence et des moyens d'utilisation de cette ressource pour introduire le second terminal dans la communication. Le dispositif comporte également une ressource pont de conférence apte à mettre en communication plusieurs terminaux. Selon un autre mode de réalisation de l'invention, le dispositif comprend également des moyens d'adaptation du flux de communication vers un terminal du premier ou du second utilisateur en fonction des capacités de ce terminal et/ou d'une requête provenant d'un des terminaux participant à la communication. Selon un autre mode de réalisation de l'invention, le dispositif comprend aussi des moyens de réception d'un message de déconnexion d'un premier terminal du premier utilisateur, et des moyens de libération de la ressource réservée après vérification qu'un seul terminal par utilisateur participe à la communication. Ces moyens sont pilotés par le microprocesseur de l'unité de traitement (91). REVENDICATIONS1. Dispositif dans un réseau de communication IP entre plusieurs utilisateurs, un utilisateur possédant une pluralité de terminaux ayant une unique identité publique dans le réseau de communication, au moins un terminal d'un premier utilisateur étant en communication avec au moins un terminal d'un second utilisateur, caractérisé en ce qu'il comporte: des moyens de réception (207a) d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication, des moyens de réservation d'une ressource de pont de conférence (207b), des moyens d'utilisation de la ressource réservée pour introduire le second terminal dans la communication. 2. Dispositif selon la revendication 1 caractérisé en ce qu'il comporte: des moyens d'adaptation du flux de communication vers un terminal du premier ou du second utilisateur en fonction des capacités de ce terminal et/ou d'une requête provenant d'un des terminaux participant à la communication. 3. Dispositif selon la revendication 1 caractérisé en ce qu'il comporte: des moyens de réception d'un message de déconnexion d'un premier terminal du premier utilisateur, des moyens de libération de la ressource de pont de conférence après vérification qu'un seul terminal par utilisateur participe à la communication. 4. Procédé de mise en communication dans un réseau de communication IP entre plusieurs utilisateurs, un utilisateur possédant une pluralité de terminaux ayant une unique identité publique dans le réseau de communication, au moins un terminal d'un premier utilisateur étant en communication avec au moins un terminal d'un second utilisateur, caractérisé en ce qu'il comporte les étapes suivantes: - Réception (300) d'un évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication, - Réservation (310) d'une ressource de pont de conférence, Utilisation (311) de la ressource réservée pour introduire le second terminal dans la communication. 5. Procédé selon la revendication 4 caractérisé en ce qu'il comporte une étape d' adaptation du flux de communication vers un terminal du premier ou du second utilisateur en fonction des capacités de ce terminal et/ou d'une requête provenant d'un des terminaux participant à la communication.-19- 6. Procédé selon la revendication 4 caractérisé en ce que suite à la réception d'un message de déconnexion d'un premier terminal du premier utilisateur, il comporte une étape de libération de la ressource de pont de conférence après vérification qu'un seul terminal par utilisateur participe à la communication. 7. Procédé selon la revendication 4 caractérisé en ce que l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le second terminal du premier utilisateur après un temps prédéterminé de temporisation. 8. Procédé selon la revendication 4 caractérisé en ce que l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le second terminal du premier utilisateur, le message comportant dans son champ destinataire un numéro de service prédéterminé. 9. Procédé selon la revendication 4 caractérisé en ce que l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le premier terminal du premier utilisateur, le message comportant un numéro de service prédéterminé dans son champ destinataire. 10. Procédé selon la revendication 4 caractérisé en ce que l'évènement relatif à une requête de participation d'un second terminal du premier utilisateur à la communication correspond à la réception d'un message envoyé par le premier terminal du premier utilisateur après un temps prédéterminé de temporisation. 11. Serveur dans un réseau de communication IP caractérisé en ce qu'il comprend un dispositif selon l'une des revendications 1 à 3. 12. Passerelle reliée à un réseau de communication IP caractérisée en ce qu'elle comprend un 30 dispositif selon l'une des revendications 1 à 3. 13. Dispositif selon l'une des revendications 1 à 3 caractérisé en ce qu'il comprend au moins un serveur d'application et au moins un serveur de pont de conférence. 35 14. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de mise en communication selon l'une quelconque des revendications 4 à 10 lorsque ledit programme est exécuté par un ordinateur. 10 15 20 25