FR 3063407 A1 20180831 FR 1751510 A 20170224 1 Arrière-plan de l'invention L'invention se rapporte au domaine des télécommunications et porte plus particulièrement sur le test d'une liaison de communication d'un terminal IP. Une technique permet aujourd'hui de tester à distance une ligne téléphonique d'un réseau téléphonique commuté (RTC) connu comme étant le réseau historique des téléphones fixes. Cette technique de test consiste à utiliser les propriétés de propagation des ondes électriques dans un support en cuivre, type de support dont est équipé le réseau RTC. En exploitant notamment le phénomène d'écho bien connu des ondes électriques dans ce type de support, il est ainsi possible pour un opérateur téléphonique de tester à distance une ligne téléphonique du réseau RTC. Ces mécanismes de test sont par exemple mis en oeuvre lorsqu'un client abonné appelle le service après-vente (SAV) d'un opérateur. Un technicien est alors capable d'exécuter un test à distance pour mesurer la qualité de la ligne téléphonique du client et détecter d'éventuels problèmes de connexion. Cependant, il existe aujourd'hui une offre croissante pour des services de communication de type IP, c'est-à-dire utilisant le protocole Internet pour transporter des données multimédia sur des réseaux IP, que ce soit des réseaux privés ou Internet. Parmi les services de communication IP possibles, on compte notamment les services de téléphonie VoIP (pour « Voix sur IP ») permettant de communiquer par la voix sur des réseaux compatibles IP. Or, lorsqu'un client souscrit à une offre de communication IP, par exemple un service VoIP, il n'est pas possible pour l'opérateur du service de tester la qualité de la ligne utilisée par le client. Ceci résulte du fait qu'une liaison de communication IP ne fait pas intervenir de supports en cuivre comme dans le réseau RTC et qu'il n'est pas aujourd'hui possible pour l'opérateur de maîtriser avec précision la manière dont les paquets de données IP sont routés lors d'une communication de l'un de ses abonnés. Il existe donc aujourd'hui un besoin pour une solution permettant de tester efficacement, à distance, le fonctionnement d'une liaison de communication IP d'un terminal IP. 3063407 2 Objet et résumé de l'invention A cet effet, la présente invention concerne un procédé de test d'une liaison de communication entre un serveur de test et un terminal IP, le procédé étant mis en oeuvre 5 par le serveur de test, ledit procédé comprenant les étapes suivantes : déclenchement d'un envoi, via un réseau de communication IP, d'une requête d'initiation d'une communication IP à destination du terminal IP, ladite requête d'initiation comportant un paramètre commandant au terminal IP d'accepter automatiquement la communication initiée par le serveur de test ; 10 en cas de réception, via le réseau de communication IP, d'un message d'acceptation de la communication IP en provenance du terminal IP, établissement d'un canal de transmission de données multimédia, au travers du réseau de communication IP, entre le serveur de test et le terminal IP ; et test pour évaluer une qualité de communication entre le serveur de test et le 15 terminal IP au travers du canal de transmission. L'invention permet de tester à distance le fonctionnement d'une liaison de communication IP utilisée par un terminal IP et ainsi d'en déduire si le terminal IP est opérationnel. L'invention permet plus particulièrement d'évaluer à distance la qualité de la communication IP entre le terminal IP en question et un serveur de test. Grâce à 20 l'invention, on peut vérifier le bon fonctionnement de la signalisation entre le serveur de test et le terminal IP et on peut en outre évaluer la qualité de service lorsque des données multimédia sont échangées via un canal de données entre le serveur de test et le terminal IP. Il est ainsi possible pour un opérateur de tester une ligne de communication IP sans intervention humaine sur site, en particulier sans intervention chez l'utilisateur du terminal 25 IP concerné. Il est possible de tester rapidement et efficacement la ligne de communication IP d'un ou d'une pluralité de terminaux IP distants, bien que les lignes de communication ne soient pas en cuivre et sans maîtriser précisément le routage des données. Selon un mode de réalisation particulier, le serveur de test est situé à l'extérieur du 30 réseau de communication IP, l'étape de déclenchement comprenant un envoi de la requête d'initiation à un deuxième serveur dans le réseau de communication IP de sorte que ledit deuxième serveur insère ledit paramètre dans la requête d'initiation avant son envoi audit terminal IP. Il est ainsi possible pour le serveur de test de forcer le terminal IP à répondre 35 automatiquement à la communication initiée par ledit serveur de test, et ce grâce au paramètre d'auto-réponse inséré par le deuxième serveur dans la requête d'initiation. Ce mode de réalisation est notamment avantageux lorsqu'un serveur d'applications présent 3063407 3 dans le réseau de communication IP supprime le paramètre d'auto-réponse lorsqu'un tel paramètre est inséré directement par le serveur de test dans la requête d'initiation avant son envoi vers le terminal IP. Selon un mode de réalisation particulier, l'étape de déclenchement comprend une 5 insertion dudit paramètre par le serveur de test dans la requête d'initiation avant envoi de ladite requête, via le réseau de communication IP, au terminal IP. Le procédé de traitement est ainsi simplifié dans la mesure où c'est le serveur de test qui insère lui-même le paramètre d'auto-réponse dans la requête d'initiation destiné au terminal IP qui fait l'objet du test. Il n'est pas nécessaire de configuré pour un serveur du 10 réseau de communication IP pour réaliser cette insertion. Le serveur de test peut être situé dans ou hors du serveur de communication IP. Selon un mode de réalisation particulier, si au lieu du message d'acceptation, le serveur de test reçoit un message du réseau de communication IP indiquant que le routage de la requête d'initiation vers le terminal IP a échoué, le serveur de test 15 détermine que la liaison de communication entre le serveur de test et le terminal IP est défaillante. L'invention permet ainsi de déterminer à distance si la liaison de communication IP est opérationnelle ou non. Selon un mode de réalisation particulier, l'étape de test comprend : 20 une réception, via le canal de transmission, d'une pluralité de premiers paquets de données IP provenant du terminal IP; et une détermination, à partir de la pluralité de premiers paquets de données IP reçus, d'un degré de qualité de la communication depuis le terminal IP vers le serveur de test dans le canal de transmission. 25 Le serveur de test peut ainsi évaluer la qualité de la communication montante depuis le terminal IP vers le serveur de test. Selon un mode de réalisation particulier, l'étape de test comprend : un envoi d'une pluralité de deuxièmes paquets de données IP au terminal IP de sorte à ce que ledit terminal IP puisse tester la qualité de communication du canal 30 de transmission ; et une réception, en provenance du terminal IP, via le canal de transmission, d'un degré de qualité de la communication depuis le serveur de test vers le terminal IP dans le canal de transmission. Le serveur de test peut ainsi évaluer la qualité de la communication descendante 35 depuis le serveur de test vers le terminal IP. Selon un mode de réalisation particulier, le procédé de test comprend une étape de détermination, à partir d'une donnée insérée par le terminal IP dans le message 3063407 4 d'acceptation reçu, que c'est effectivement le terminal IP qui a accepté la communication IP initiée par le serveur de test. De cette manière, le serveur de test peut ainsi déterminer si le message d'acceptation reçu provient bien du terminal IP faisant l'objet du test, et non d'une autre entité telle 5 qu'un service de messagerie vocale (ou autre) configure pour traiter la communication initiée par le serveur de test lorsque le terminal IP n'est pas en mesure de répondre. Selon un mode de réalisation particulier, l'étape de test comprend : une tentative de clôture dudit canal de transmission de données multimédia et d'un canal de signalisation établi entre le serveur de test et le terminal IP suite au 10 message d'acceptation reçu ; et une détermination de la réussite ou non de la tentative de clôture de chacun des canaux. Il est ainsi possible pour le serveur de test de tester la phase de clôture du canal de signalisation et du canal de transmission de données multimédia. 15 Dans un mode particulier de réalisation, les différentes étapes du procédé de test sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif tel qu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant des 20 instructions adaptées à la mise en oeuvre des étapes d'un procédé de test tel que défini ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 25 L'invention concerne également un procédé de traitement destiné à permettre un test d'une liaison de communication IP entre un serveur de test et un terminal IP, le procédé étant mis en oeuvre par un système de réseau situé dans un réseau de communication IP de sorte à faire l'interface entre le serveur de test et le terminal IP, le procédé comprenant les étapes suivantes : 30 réception, en provenance du serveur de test, d'une requête d'initiation d'une communication IP à destination du terminal IP ; insertion d'un paramètre dans la requête d'initiation ; envoi de la requête d'initiation comportant ledit paramètre prédéterminé au terminal IP, ledit paramètre commandant au terminal IP d'accepter 35 automatiquement la communication initiée par le serveur de test ; réception, en réponse à la requête d'initiation, d'un message d'acceptation de la communication IP en provenance du terminal IP ; et 3063407 5 transmission du message d'acceptation au serveur de test de sorte à déclencher l'établissement d'un canal de transmission de données multimédia entre le serveur de test et le terminal IP via ledit système de réseau ; et transmission de paquets de données IP entre le serveur de test et le terminal IP 5 via le canal de transmission, de sorte à permettre une évaluation par le serveur de test d'une qualité de communication entre ledit serveur de test et le terminal IP au travers du canal de transmission. Le système de réseau selon l'invention permet ainsi à un serveur de test de tester à distance une ligne de communication IP d'un terminal IP et donc de vérifier le bon 10 fonctionnement du terminal IP lui-même. Selon un mode de réalisation particulier, le réseau de communication IP est un réseau IMS, le système de réseau comprenant : o un serveur P-CSCF configure pour réaliser les étapes de réception, l'étape d'insertion, l'étape d'envoi et l'étape de transmission du message 15 d'acceptation ; et o un serveur C-BGF configuré pour réaliser l'étape de transmission des paquets de données IP, ledit canal de transmission étant établi par l'intermédiaire dudit serveur C-BGF. Selon un mode de réalisation particulier, le procédé de traitement comprend une étape 20 de détermination de l'enregistrement ou non du terminal IP auprès du réseau de communication IP ; et dans lequel : - le système de réseau réalise l'étape d'insertion du paramètre dans la requête d'initiation et l'étape d'envoi de ladite requête d'initiation comportant le paramètre seulement si le terminal IP est enregistré auprès du réseau de communication IP ; 25 - si le terminal IP n'est pas enregistré auprès du réseau de communication IP, le système de réseau envoie au serveur de test un message indiquant que le routage de la requête d'initiation vers le terminal IP a échoué. De cette manière, le serveur de test peut détecter que le terminal IP faisant l'objet du test n'est pas accessible pour initier une communication IP. 30 Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un système de réseau tel qu'un serveur ou un groupe de serveurs, ou plus généralement dans un 35 ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de traitement tel que défini ci-dessus. 3063407 6 L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. A noter que les programmes mentionnés dans le présent exposé peuvent utiliser 5 n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. De plus, les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut 10 comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble 15 électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 20 L'invention vise également un serveur de test d'une liaison de communication IP entre ledit serveur de test et un terminal IP, comprenant : un module d'envoi configuré pour déclencher un envoi, via un réseau de communication IP, d'une requête d'initiation d'une communication IP à destination du terminal IP, ladite requête d'initiation comportant un paramètre commandant 25 au terminal IP d'accepter automatiquement la communication initiée par le serveur de test ; module de connexion configuré, en cas de réception via le réseau de communication IP d'un message d'acceptation de la communication IP en provenance du terminal IP, pour établir un canal de transmission de données 30 multimédia, au travers du réseau de communication IP, entre le serveur de test et le terminal IP; et un module de test pour évaluer une qualité de communication entre le serveur de test et le terminal IP au travers du canal de transmission. L'invention vise en outre un système de réseau situé dans un réseau de 35 communication IP de sorte à faire l'interface entre un serveur de test et un terminal IP, ledit serveur de test étant destiné à tester une liaison de communication IP entre le serveur de test et le terminal IP, ledit système de réseau comprenant : 3063407 7 un premier module de réception configuré pour recevoir, en provenance du serveur de test, une requête d'initiation d'une communication IP à destination du terminal IP; un module d'insertion configuré pour insérer un paramètre dans la requête 5 d'initiation, ledit paramètre commandant au terminal IP d'accepter automatiquement la communication initiée par le serveur de test ; un module d'envoi configuré pour envoyer la requête d'initiation comportant ledit paramètre au terminal IP; un deuxième module de réception configuré pour recevoir, en réponse à la requête 10 d'initiation, un message d'acceptation de la communication IP en provenance du terminal IP; un premier module de transmission configuré pour transmettre le message d'acceptation au serveur de test de sorte à déclencher l'établissement d'un canal de transmission de données multimédia entre le serveur de test et le terminal IP 15 via ledit système de réseau ; et un deuxième module de transmission configuré pour transmettre des paquets de données IP entre le serveur de test et le terminal IP via le canal de transmission, de sorte à permettre une évaluation par le serveur de test d'une qualité de communication entre ledit serveur de test et le terminal IP au travers du canal de 20 transmission. Comme décrit par la suite, le système de réseau peut être un serveur ou un ensemble de serveurs. A noter que les différents modes de réalisation définis ci-avant en relation avec le procédé de test, d'une part, et avec le procédé de traitement, d'autre part, ainsi que les 25 avantages associés, s'appliquent par analogie au serveur de test et au système de réseau définis ci-dessus. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant 30 matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. De la même 35 manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. 3063407 8 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des 5 exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: - la figure 1 représente schématiquement un environnement E comprenant un réseau 2 et un serveur de test 5V; - la figure 2 représente schématiquement des blocs fonctionnels mis en oeuvre par un serveur de test selon un mode de réalisation particulier de l'invention ; 10 - la figure 3 représente schématiquement des blocs fonctionnels mis en oeuvre par un système de réseau selon un mode de réalisation particulier de l'invention ; - la figure 4 représente, sous forme d'un ordinogramme, les étapes d'un procédé de test réalisé par un serveur de test et les étapes d'un procédé de traitement 15 réalisé par un système de réseau, selon un mode de réalisation particulier de l'invention ; - la figure 5 représente, sous forme d'un ordinogramme, les étapes d'un procédé de test réalisé par un serveur de test et les étapes d'un procédé de traitement réalisé par un système de réseau, selon un mode de réalisation particulier de 20 l'invention ; - la figure 6 représente, sous forme d'un ordinogramme, les étapes d'un procédé de test réalisé par un serveur de test et les étapes d'un procédé de traitement réalisé par un système de réseau, selon un mode de réalisation particulier de l'invention ; 25 - La figure 7 représente une variante des modes de réalisation illustrés dans les figures ci-dessus ; et - La figure 8 représente une variante des modes de réalisation illustrés dans les figures ci-dessus. 30 Description détaillée de plusieurs modes de réalisation Comme indiqué précédemment, l'invention porte sur le test d'une liaison de communication IP d'un terminal IP. L'invention se propose d'utiliser un serveur de test pour tester à distance une liaison de communication IP entre le serveur de test et un terminal IP distant, un réseau de 35 communication IP faisant l'interface entre le serveur de test et le terminal IP distant. Selon divers modes de réalisation, l'invention concerne plus particulièrement le serveur de test qui envoie, ou cause l'envoi, d'une requête d'initiation d'une communication IP au 3063407 9 terminal IP en question, cette requête comportant un paramètre commandant au terminal IP d'accepter automatiquement la communication initiée par le serveur de test. Dans le cas où le serveur de test reçoit en retour un message d'acceptation du terminal IP, il établit alors un canal de transmission de données multimédia avec le terminal IP et réalise 5 un test de la qualité de communication entre le serveur de test et le terminal IP dans le canal de transmission. Il est ainsi possible de tester à distance le bon fonctionnement d'une liaison de communication IP et, le cas échéant, de détecter une défaillance ou un problème dans la liaison de communication IP. L'invention concerne également, selon certains modes de réalisation, un système de 10 réseau situé dans le réseau de communication IP, le système de réseau étant configuré pour insérer le paramètre mentionné ci-avant dans la requête d'initiation du serveur de test avant l'envoi de ladite requête d'initiation au terminal IP. Ce système de réseau permet alors la réalisation d'un test, par le serveur de test, du canal de transmission de données multimédia, une fois ce dernier établi entre le serveur de test et le terminal IP 15 par l'intermédiaire dudit système de réseau. L'invention concerne en outre les procédés mis en oeuvre par le serveur de test et le système de réseau mentionnés ci-dessus. D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. 20 Dans ce document, des modes de réalisation de l'invention sont décrits en référence à un réseau de communication IP de type IMS (pour « IP Multimedia Subsystem » en langue anglaise). On comprendra cependant que l'invention s'applique plus généralement au test d'une liaison de communication IP dans un quelconque réseau de communication IP, tels que des réseaux SIP non-conformes IMS ou des réseaux H.323 tels que définis 25 par l'UIT (l'Union Internationale des Télécommunications). De même, l'invention est décrite ici en référence au protocole standardisé SIP. On comprendra cependant que l'invention s'applique également à d'autres types de protocole, tels que le protocole H.323 défini par l'UIT. Dans ce document, un « terminal IP » désigne un quelconque terminal de 30 communication configuré pour communiquer avec une entité distante selon le protocole IP. Des modes de réalisation de l'invention sont décrits ci-après en référence à des terminaux (des téléphones ou ordinateurs par exemple) mettant en oeuvre un logiciel de téléphonie VoIP. Cependant, comme le comprend l'homme du métier, l'invention s'applique également à d'autres types de terminaux IP tels que des terminaux 35 téléphoniques SIP, des téléviseurs IPTV, un PBX (Private Branch Exchange)... Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou 3063407 10 analogues, de sorte que ces éléments communs ou analogues ne sont généralement pas à nouveau décrits par souci de simplicité. La figure 1 représente schématiquement la structure d'un environnement E comprenant un serveur de test SV, un terminal Ti configure pour contrôler le serveur de 5 test SV, des terminaux IP notés T2, T3 et T4, et un réseau de communication IP noté 2. Le réseau 2 est ici un réseau IMS, tel que défini par le groupe 3GPP (pour « 3rd Generation Partnership Project »). L'architecture standardisée IMS permet la fourniture de services multimédias fixes et mobiles selon le protocole SIP. Le réseau IMS 2 comprend dans cet exemple un serveur d'applications 8 et un 10 système de réseau 4 (ou sous-système). Le système de réseau 4 constitue par exemple le coeur de réseau du réseau IMS 2 ou une sous-partie de ce coeur de réseau. Dans cet exemple, le système de réseau 4 comprend un serveur 6 de type P-CSCF (pour « ProxyCall Session Control Function ») et un serveur 7 de type C-BGF (pour « Core Border Gateway Function »), comme définis par le groupe 3GGP. D'autres éléments d'un réseau 15 IMS, non représentés en figure 1, peuvent éventuellement être présents dans le système de réseau 4 (tels qu'un serveur S-CSCF ou encore un serveur I-CSCF, par exemple). Dans cet exemple, le serveur de test SV et le système de réseau 4 forment ensemble un système noté 5. Le serveur P-CSCF 6 du système de réseau 4 est ici notamment chargé de gérer 20 l'échange de données de signalisation entre le serveur de test SV et les terminaux IP T2- T4 qui sont susceptible de faire l'objet d'un test. Le serveur C-BGF 7 est ici chargé de gérer l'échange de données multimédia lorsqu'un canal de transmission C2 est ouvert entre le serveur de test SV et l'un des terminaux IP T2-T4. Le système de réseau 4 est disposé en coupure de flux de sorte à faire l'interface 25 entre le serveur de test SV, d'une part, et les terminaux IP distants T2-T4, d'autre part. Comme indiqué par la suite, un canal de signalisation Cl peut être établi entre le serveur de test SV et l'un des terminaux IP T2-T4 via le serveur 6. De plus, un canal de transmission C2 de données multimédia (aussi appelé « canal de transmission » ou « canal de données ») peut être établi entre le serveur de test SV et l'un des terminaux IP 30 T2-T4 via le serveur 7. A noter toutefois que d'autres mises en oeuvre sont possibles. En particulier, on peut envisager qu'un même serveur réalise à la fois les fonctions des serveurs 6 et 7 tels que représentés en figure 1. Selon une variante, les serveurs 6 et 7 forment un seul et même serveur ou équipement, par exemple de type SBC (pour « Session Border Controller »). 35 Les éléments constituant un réseau de type IMS ainsi que leurs principes de fonctionnement sont connus de l'homme du métier et ne seront pas détaillés davantage ici. On notera par ailleurs que certains constituants faisant généralement partie d'un 3063407 11 réseau IMS ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. Dans l'exemple considéré ici, les serveurs 6 et 7 comportent chacun au moins un processeur (non représenté) et une mémoire non volatile notée respectivement 25 et 30. 5 Ces mémoires 25 et 30 peuvent chacune être une mémoire non volatile réinscriptible (Flash, EEPROM...) ou une mémoire morte ROM. Les mémoires 25 et 30 constituent chacune un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible respectivement par les serveurs 6 et 7 et plus généralement par le système de réseau 4. Sur ces mémoires 25 et 30 est enregistré respectivement un 10 programme d'ordinateur PG2 et PG3, conformément à un mode de réalisation particulier. Ces programmes d'ordinateur PG2 et PG3 comportent des instructions pour l'exécution des étapes d'un procédé de traitement selon un mode de réalisation particulier, comme expliqué ultérieurement. Comme représenté en figure 1, le serveur de test SV est configure pour tester une 15 liaison de communication IP, notée CM, entre ledit serveur de test SV et l'un au moins des terminaux IP T2-T4. Dans cet exemple, la liaison de communication CM comprend un canal de signalisation Cl et un canal de transmission de données multimédia C2 comme déjà mentionnés ci-avant. Dans l'exemple représenté en figure 1, le canal de signalisation Cl passe également 20 par le serveur d'application 8 placé en coupure de flux, bien que des variantes soient possibles sans faire intervenir le serveur d'applications 8 comme expliqué ultérieurement. Dans l'environnement E représenté en figure 4, le serveur 6 est le premier point d'accès du serveur de test SV et des terminaux IP T2-T4 au réseau IMS 2. Chaque donnée de signalisation reçue par le serveur 6 via le canal de signalisation Cl est transmise au 25 serveur d'application 8 avant d'être renvoyée (après éventuel traitement) au serveur 6 afin d'être routée vers sa destination. Le serveur de test SV présente par exemple la structure d'un ordinateur. Dans cet exemple, le serveur de test comprend au moins un processeur (non représenté) et une mémoire non volatile 20, par exemple une mémoire non volatile réinscriptible (Flash, 30 EEPROM...) ou une mémoire morte ROM. La mémoire 20 constitue un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le serveur de test SV, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de 35 test selon un mode de réalisation particulier. Les étapes de ce procédé seront décrites ultérieurement. 3063407 12 Dans cet exemple, le serveur de test SV peut être contrôlé à distance par un terminal Ti (figure 1). Plus particulièrement, le terminal Ti est ici configuré pour envoyer au serveur de test SV l'identifiant respectif 1D2-1D4 d'au moins l'un des terminaux IP T2-T4 dont on souhaite tester la liaison de communication CM au travers du réseau IMS 2. Pour 5 ce faire, le terminal Ti est par exemple configuré pour permettre à un utilisateur (ou opérateur) 10 d'accéder à une page web 12 (ou site web) hébergée par le serveur de test SV. L'utilisateur 10 peut ainsi indiquer sur cette page web 12 le ou les terminaux IP T2-T4 dont il souhaite tester la ligne de communication IP à l'aide du serveur de test SV. D'autres interfaces homme/machine sont toutefois possibles. Dans un exemple particulier, 10 le serveur SV détermine lui-même le ou les terminaux IP T2-T4 dont la liaison de communication IP CM doit être testée, à partir par exemple de critères prédéfinis. Le serveur de test SV assure donc ici une fonction de serveur web, bien que d'autres mises en oeuvre soient possibles sans cette fonction comme indiqué ci-dessus. Toujours dans cet exemple, le serveur de test SV est en outre configuré pour 15 exécuter une fonction de serveur d'injection d'appel. Autrement dit, le serveur de test SV est configuré pour déclencher une communication IP, via le réseau IMS 2, avec l'un des terminaux IP T2-T4. L'établissement d'une communication IP avec un terminal IP T2-T4 permet de tester la liaison de communication IP CM susceptible d'être établie entre le serveur de test SV et un terminal IP T2-T4. Plus particulièrement, le serveur de test SV 20 est apte à tester le canal de signalisation Cl et le canal de transmission de données multimédia C2 susceptibles d'être établis, via respectivement les serveurs 6 et 7, entre le serveur de test SV et l'un des terminaux IP T2-T4. On comprendra que l'environnement E représenté en figure 1 n'est qu'un exemple de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. 25 Par ailleurs, selon un exemple de réalisation représenté en figure 2, le processeur du serveur de test SV piloté par le programme d'ordinateur PG1 met en oeuvre un certain nombre de modules, à savoir : un module d'envoi MD2, un module de connexion MD4, un module de test MD6 et un module d'interface MD8. Le module d'envoi MD2 est configuré pour déclencher un envoi, via le réseau de 30 communication IP 2 (et plus particulièrement via le serveur 6 dans cet exemple), d'une requête d'initiation d'une communication IP à destination du terminal IP (le terminal T2 par exemple), cette requête d'initiation comportant un paramètre (noté par la suite PR), dit paramètre d'auto-réponse, commandant au terminal IP T2 d'accepter automatiquement la communication initiée par le serveur de test SV. 35 On suppose par exemple ici que c'est le terminal IP T2 qui fait l'objet d'un test de sa ligne de communication IP. 3063407 13 Le module de connexion MD4 est configuré, en cas de réception via le réseau de communication IP 2 d'un message d'acceptation de la communication IP en provenance du terminal IP T2, pour établir un canal de transmission C2 de données multimédia, au travers du réseau de communication IP 2, entre le serveur de test et le terminal IP T2 5 (comme représenté en figure 1). Le module de test MD6 est configuré pour évaluer une qualité de communication entre le serveur de test SV et le terminal IP T2 au travers du canal de transmission C2 établi par le module de connexion MD4. D'autre part, selon un exemple de réalisation représenté en figure 3, le système de 10 réseau 4 piloté par les programmes d'ordinateur PG2 et PG3 met en oeuvre un certain nombre de modules, à savoir : un premier module de réception MD20, un module d'insertion MD22, un module d'envoi MD24, un deuxième module de réception MD26, un premier module de transmission MD28 et un deuxième module de transmission MD30. Le premier module de réception MD20 est configuré pour recevoir, en provenance du 15 serveur de test SV, la requête d'initiation d'une communication IP émise par le module d'envoi MD2 (figure 2) à destination d'un terminal IP, à savoir le terminal T2 dans cet exemple. Le module d'insertion MD22 est configuré pour insérer un paramètre (noté par la suite PR), dit paramètre d'auto-réponse, dans la requête d'initiation, le paramètre d'auto- 20 réponse commandant au terminal IP T2 d'accepter (ou de répondre) automatiquement la communication initiée par le serveur de test SV. Le module d'envoi MD24 est configuré pour envoyer la requête d'initiation comportant ledit paramètre au terminal IP T2. Le deuxième module de réception MD26 est configuré pour recevoir, en réponse à la 25 requête d'initiation, un message d'acceptation de la communication IP en provenance du terminal IP T2. Le premier module de transmission MD28 est configuré pour transmettre le message d'acceptation au serveur de test SV de sorte à déclencher l'établissement d'un canal de transmission C2 de données multimédia entre le serveur de test SV et le terminal IP T2 30 via le système de réseau 4, comme représenté en figure 1. Le deuxième module de transmission MD30 est configuré pour transmettre des paquets de données IP entre le serveur de test SV et le terminal IP T2 via le canal de transmission C2 de sorte à permettre une évaluation, par le serveur de test SV, d'une qualité de communication entre le serveur de test SV et le terminal IP T2 au travers du 35 canal de transmission C2. Selon l'exemple représenté en figure 1, le serveur 6 met en oeuvre les modules MD20 à MD26 tandis que le serveur 8 met en oeuvre les modules MD28 et MD30. 3063407 14 Le fonctionnement des modules MD2-MD8 du serveur de test SV et des modules MD20-MD30 du système de réseau 4 apparaîtra plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 4-8. On comprendra que les modules MD2-MD8 et MD20-MD30 tels que représentés sur 5 les figures 2 et 3 ne constituent qu'un exemple de mise en oeuvre non limitatif de l'invention. Un mode de réalisation de l'invention est à présent décrit en référence à la figure 4. Plus précisément, le serveur de test SV (figures 1-2) met en oeuvre un procédé de test de l'invention en exécutant le programme PG1. De même, le système de réseau 4 10 (figures 1 et 3) met en oeuvre un procédé de traitement en exécutant les programmes PG2 et PG3. On suppose à présent que l'utilisateur 10 souhaite tester la liaison de communication IP notée CM entre le serveur de test SV et le terminal IP T2. Pour ce faire, l'utilisateur 10 sélectionne par exemple l'identifiant ID2 du terminal IP T2 sur la page web 12 à l'aide de 15 son terminal Ti. En réponse à cette sélection, le terminal Ti envoie (A2) l'identifiant ID2 au serveur de test SV via tout moyen de communication approprié. Dans cet exemple, l'envoi A2 se fait sous la forme d'une commande CMD comportant l'identifiant ID2. Dans cet exemple, le terminal IP T2 est un téléphone VoIP apte à échanger de la donnée voix selon le protocole IP via le réseau IMS 2. 20 L'identifiant ID2 peut être, par exemple, un numéro de téléphone de l'utilisateur du terminal IP T2, ou encore une adresse SIP du terminal IP T2. Le serveur de test SV reçoit l'identifiant ID2 lors d'une étape de réception B2. Le serveur de test SV détermine (B4), à partir de l'identifiant ID2 reçu, que la liaison (ou ligne) de communication IP du terminal T2 doit être testée. 25 Aussi, le serveur de test SV envoie (B6) une requête M5G1 d'initiation d'une communication IP destinée au terminal IP T2. Cette requête d'initiation M5G1 comporte ici l'identifiant ID1 de la source, à savoir le serveur SV, et l'identifiant ID2 de la destination, à savoir le terminal IP T2. Il s'agit par exemple d'une requête SIP de type « INVITE ». La requête d'initiation MSG1 est reçue par le serveur 6 en C6. 30 Le serveur 6 détecte, à partir de l'identifiant ID1 du serveur de test SV présent dans la requête d'initiation MSG1, que la source est un serveur de test et en déduit que le terminal IP doit faire l'objet d'un test de ligne IP. Par conséquent, le serveur 6 insert (C8) un paramètre PR dans la requête d'initiation MSG1 avant de la transmettre (C10) au terminal IP T2. Ce paramètre PR, appelé aussi paramètre d'auto-réponse, commande au 35 terminal IP T2 d'accepter automatiquement la (ou de répondre automatiquement à la) communication qui est initiée par le serveur de test SV. Autrement dit, le paramètre PR est une demande d'auto-réponse à destination du terminal IP T2 à tester. Ce paramètre 3063407 15 PR vise à forcer le terminal destinataire T2 à accepter systématiquement la mise en communication requise par le serveur de test SV. Dans un exemple particulier, l'insertion C8 consiste à fixer un paramètre de la requête d'initiation MSG1 à une valeur prédéterminée. En variante, un paramètre PR peut être 5 ajouté dans la requête d'initiation MSG1, par exemple dans un champ prévu cet effet. Selon un exemple particulier, le paramètre d'auto-réponse PR ajouté par le serveur 6 est « Call-Info : answer-after = 0 ». Le terminal IP T2 reçoit la requête d'initiation MSG1 lors d'une étape de réception D10. On suppose ici, qu'en réponse à la requête d'initiation MSG1, le terminal IP T2 10 accepte (D12) la communication sur détection du paramètre PR. On suppose ici que la communication initiée par le serveur de test SV est un appel téléphonique en VoIP. Le terminal IP T2 décroche donc automatiquement afin d'accepter l'appel VoIP. La nature de la communication IP initiée par le serveur de test SV peut toutefois varier en fonction notamment du type du terminal IP destinataire. En variante, la 15 communication initiée par le serveur de test SV peut être une communication IP de es données multimédia quelconques, par exemples des données audio, vidéo et/ou texte. Le terminal IP T2 peut par exemple être un terminal configuré pour recevoir des données multimédia dans le cadre d'un service dit de « streaming » ou de visioconférence. Au cours d'une étape d'envoi D14, le terminal IP T2 envoie, via le réseau IMS 2, un 20 message MSG2 à destination du serveur de test SV pour indiquer qu'il accepte la communication initiée par le serveur de test SV. Dans cet exemple, le message d'acceptation MSG2 est un message SIP bien connu de type « 200 OK ». Ce message d'acceptation MSG2 comprend l'identifiant ID2 de la source dudit message MSG2, à savoir le terminal IP T2, et l'identifiant ID1 de la destination, à savoir le serveur de test SV. 25 Le serveur 6 reçoit le message d'acceptation MSG2 en C14 et transmet celui-ci au serveur de test SV en C16. Une fois le message d'acceptation MSG2 reçu en B18, le serveur de test SV établit ainsi un canal de signalisation Cl entre le serveur de test SV et le terminal IP T2, ce canal Cl passant par le serveur 6 chargé de la signalisation (figures 1). En outre, le serveur de 30 test SV établit un canal de transmission de données multimédia C2 (dit aussi « canal de transmission » ou « canal de données ») entre le serveur de test SV et le terminal IP T2, ce canal C2 passant par le serveur 7 chargé de l'échange des données multimédia. Un flux RTP (pour « Real-Time Transport Protocol » en langue anglaise) de données IP multimédia peut par exemple être échangé de façon bidirectionnelle dans le canal de 35 transmission C2. Le canal de signalisation Cl et le canal de transmission C2 forment ensemble une liaison de données IP notée CM. 3063407 16 L'acceptation de la communication par le terminal IP fournit déjà un premier résultat sur la liaison de communication IP CM, à savoir que le terminal IP T2 est détectable (ou accessible) via le réseau IMS 2 dans la mesure où l'échange des données de signalisation est possible. Ce résultat lié à la signalisation peut être transmis par le serveur de test SV 5 au terminal Ti dès réception B16 du message d'acceptation MSG2 ou ultérieurement (par exemple dans le résultat RES ou RES3 comme décrit ci-après en référence à l'étape d'envoi B22). Le serveur de test SV réalise ensuite une étape de test B18 pour évaluer une qualité de communication entre le serveur de test SV et le terminal IP T2 au travers du canal de 10 transmission C2. La nature et la manière dont le test est réalisé en B18 peut varier selon le cas. Comme expliqué plus en détail ci-après en référence à la figure 5, le serveur de test SV peut tester au moins l'une parmi : - la communication montante dans le canal de transmission C2 depuis le terminal 15 IP T2 vers le serveur de test 5V; - la communication descendante dans le canal de transmission C2 depuis le serveur de test SV vers le terminal IP T2. Comme représenté en figure 4, la réalisation B18 du test permet au serveur de test SV d'obtenir un résultat RES indicatif de la qualité de communication entre le serveur de 20 test SV et le terminal IP T2 au travers du canal de transmission C2. Au cours d'une étape d'envoi B22, le serveur de test SV envoie ensuite le résultat RES du test au terminal Ti afin d'en informer l'utilisateur 10. Le terminal Ti reçoit le résultat RES en A22. Selon un exemple particulier représenté en figure 5, lors de l'étape de test B18 (figure 4), le serveur de test SV reçoit (B30), via le canal de transmission C2, une 25 pluralité de premiers paquets PQ1 de données IP (correspondant par exemple à un premier flux RTP) provenant du terminal IP T2. Le système de réseau 4 (et plus particulièrement le serveur 7), disposé en coupure de flux, transmet (C30) au serveur de test SV les paquets PQ1 de données IP envoyés (D30) par le terminal IP T2. Le serveur de test SV détermine (B32) alors, à partir de ces premiers paquets PQ1 reçus, un degré 30 de qualité RES1 de la communication dite « montante » depuis le terminal IP T2 vers le serveur de test SV dans le canal de transmission C2. De la même manière, toujours lors de l'étape de test B18 (figure 4), le serveur de test SV envoie (B34), via le canal de transmission C2, une pluralité de deuxièmes paquets PQ2 de données IP (correspondant par exemple à un deuxième flux RTP) au terminal IP T2. Le 35 système de réseau 4 (et plus particulièrement le serveur 7), disposé en coupure de flux, transmet (C34) les paquets PQ2 de données IP que le terminal IP T2 reçoit en D34. Le terminal IP T2 détermine (D36) alors, à partir de ces deuxièmes paquets PQ2 reçus, un 3063407 17 degré de qualité RES2 de la communication dite « descendante » depuis le serveur de test SV vers le terminal IP T2 dans le canal de transmission C2. Au cours d'une étape d'envoi D38, le terminal IP T2 envoie ensuite le degré de qualité RES2 via le canal de transmission C2 au serveur de test SV qui le reçoit en B38. Le degré de qualité RES2 est 5 ici envoyé sous la forme d'un flux RTCP (pour « Real-time Transport Control Protocol » en langue anglaise). Le système de réseau 4 (et plus particulièrement le serveur 7), disposé en coupure de flux, transmet en C38 ce résultat RES2 depuis le terminal IP T2 au serveur de test SV. Le serveur de test SV et le terminal IP T2 évaluent respectivement les niveaux de 10 qualité RES1 et RES2 en B32 et D36 selon une méthode appropriée, en analysant les paquets PQ1 et PQ2 reçus au cours de la période de test. Pour ce faire, le serveur de test SV et le terminal IP T2 exécutent par exemple l'algorithme de test G.107 défini par l'UIT. L'évaluation des niveaux de qualité RES1 et RES2 prend par exemple en compte la perte de paquets parmi les paquets PQ1 et PQ2 ou le retard de paquets parmi les paquets PQ1 15 et PQ2. Selon un exemple particulier, les degrés de qualité RES1 et RES2 se présentent chacun sous la forme d'une valeur MOS (pour « Mean Opinion Score » en langue anglaise) qui représente une note sur la qualité d'une restitution sonore, par exemple la qualité de restitution de donnée voix. Une notation MOS, défini par l'UIT, peut varier entre les 20 valeurs 0 (très mauvaise qualité) et 5 (excellente qualité). A partir de cette note, on peut évaluer dans quelle mesure la transmission de données sonores est dégradée. Dans l'exemple représenté en figure 5, le serveur de test SV envoie ensuite à l'étape d'envoi B22, en tant que résultat RES, les degrés de qualité RES1 et RES2 précédemment obtenus au terminal Ti. Au cours de l'étape de réception A22, le terminal Ti reçoit le 25 résultat de test RES comportant les degrés de qualité RES1 et RES2. Comme déjà indiqué, on peut envisager que le serveur de test SV soit configuré pour tester seulement l'une parmi la qualité de communication montante et la qualité de communication descendante. Le résultat de test RES obtenu en B18 et envoyé au terminal Ti en B22 peut 30 également comprendre des informations additionnelles relatives au test réalisé (B18) par le serveur de test SV, telles que le ratio des paquets reçus lors du test par rapport aux paquets perdus (pour les paquets PQ1 et/ou PQ2), la durée du test, la date du test et/ou l'identifiant (numéro ou autre) du terminal IP ayant fait l'objet du test. L'invention permet de tester à distance le fonctionnement d'une liaison de 35 communication IP utilisée par un terminal IP et ainsi d'en déduire que le terminal IP est opérationnel ou non. L'invention permet plus particulièrement d'évaluer à distance la qualité de la communication IP entre le terminal IP en question et un serveur de test. 3063407 18 Grâce à l'invention, on peut vérifier le bon fonctionnement de la signalisation entre le serveur de test et le terminal IP et on peut en outre évaluer la qualité de service lorsque des données multimédia sont échangées via un canal de données entre le serveur de test et le terminal IP. Il est ainsi possible pour un opérateur de tester une ligne de 5 communication IP sans intervention humaine sur site, en particulier sans intervention chez l'utilisateur du terminal IP concerné. Il est possible de tester rapidement et efficacement la ligne de communication IP d'un ou d'une pluralité de terminaux IP distants, bien que les lignes de communication ne soient pas en cuivre et sans maîtriser précisément le routage des données. 10 Grâce à l'invention, il est possible d'évaluer la qualité de transmission de données audio (voix ou autre), vidéo et/ou texte. On peut par exemple vérifier à distance si un dispositif fax IP fonctionne en émission et en réception. A noter toutefois que, dans l'exemple représenté en figure 4, il est possible que le terminal IP T2 ne soit pas disponible pour recevoir un appel au moment de la réception 15 D10 de la requête d'initiation MSG2, par exemple parce que l'utilisateur concerné est déjà en communication. Dans ce cas, le terminal IP T2 n'accepte pas la communication initiée par le serveur de test SV et le serveur de test SV est par exemple redirigé vers le service de messagerie vocal du terminal IP T2. Afin que le serveur de test SV soit capable de déterminer que c'est effectivement le 20 terminal T2 qui répond à la requête d'initiation MSG1 (et non, par exemple, un service de messagerie mis en oeuvre par l'opérateur du service IP concerné), le terminal IP T2 peut insérer dans le message d'acceptation MSG2 au moins une donnée additionnelle, avant d'envoyer en D14 le message d'acceptation MSG2 vers le serveur de test SV. Cette donnée additionnelle indique par exemple le type (et éventuellement la version) du 25 terminal IP T2. A partir de cette donnée, le serveur de test SV est capable de détecter que c'est le service de messagerie de l'utilisateur destinataire et non son terminal IP T2 qui répond à l'appel initié par le serveur de test SV. Par ailleurs, de manière connue, pour pouvoir communiquer en utilisant un service IP tel qu'un service de VoIP par exemple, le terminal IP T2 doit au préalable s'enregistrer 30 auprès du réseau IMS 2. Pour ce faire, le terminal IP T2 réalise une procédure d'enregistrement bien connue de l'homme du métier comportant en particulier l'envoi par le terminal IP T2 d'une requête d'enregistrement comportant des informations d'enregistrement (adresse IP, numéro de téléphone...) à un serveur S-CSCF (non représenté) du réseau IMS 2. 35 Un mode de réalisation de l'invention est à présent décrit en référence à la figure 6, dans lequel on envisage le cas où le terminal IP T2 n'est pas enregistré auprès du réseau IMS 2 lorsque le serveur de test SV met en oeuvre le procédé de test. 3063407 19 Plus précisément, le terminal Ti envoie (A2) l'identifiant ID2 du terminal IP T2 au serveur de test SV comme déjà expliqué en référence à la figure 4. Le serveur de test SV réalise alors les étapes B2, B4 et B6 comme déjà décrit en référence à la figure 4, de sorte que le système de réseau 4 (et plus particulièrement le serveur 6) reçoit la requête 5 d'initiation MSG1 en C6. Puis, au cours d'une étape de vérification C50, le serveur 6 détermine si le terminal IP T2 est bien enregistré auprès du réseau IMS 2. Dans le cas où il est détecté que le terminal IP T2 est bien enregistré, le serveur 6 procède à l'étape d'insertion C8 et aux étapes suivantes comme déjà décrit précédemment en référence aux figures 4 et 5. 10 Si, en revanche, le terminal T2 n'est pas enregistré auprès du réseau IMS 2, le serveur 6 envoie (C52) au serveur de test SV un message d'erreur MSG3 indiquant que la requête d'initiation MSG1 n'a pas pu être routée au terminal IP T2. A noter que des situations autres qu'un problème d'enregistrement peut conduire le serveur 6 à envoyer un message d'erreur identique ou analogue lorsqu'il n'arrive pas à acheminer la requête 15 d'initiation MSG1 jusqu'au terminal IP T2. A partir du message d'erreur MSG3, le serveur de test SV en déduit (B54) le résultat de test RES3, à savoir que le terminal IP T2 n'est pas accessible (ou qu'il n'est pas enregistré). Le serveur de test SV envoie (B56) alors le résultat RES3 au terminal Ti qui le reçoit en A56. 20 Plus généralement, selon un exemple particulier, si au lieu du message d'acceptation MSG2 (figures 1 et 4), le serveur de test SV reçoit un message MSG3 du réseau IMS 2 indiquant que le routage de la requête d'initiation MSG1 vers le terminal IP T2 a échoué, le serveur de test SV détermine que la liaison de communication CM entre le serveur de test SV et le terminal IP T2 est défaillante. 25 Comme indiqué ci-avant, des variantes de réalisation de l'environnement E sont possibles. Selon une variante représentée en figure 7, le serveur de test SV insère lui-même le paramètre d'auto-réponse PR dans la requête d'initiation MSG1 d'une communication IP destinée au terminal IP T2. Plus précisément, le terminal Ti envoie (A2) l'identifiant ID2 du terminal IP T2 au 30 serveur SV comme déjà expliqué en référence à la figure 4. Le serveur de test SV réalise alors les étapes B2 et B4 comme déjà décrit en référence à la figure 4. Lors d'une étape d'insertion B70, le serveur de test SV insère le paramètre d'auto-réponse PR de façon analogue à l'étape d'insertion C8 décrite précédemment. Le serveur de test SV envoie (B72) ensuite la requête d'initiation MSG1 comportant le paramètre PR au serveur 6 du 35 système de réseau 4. Le serveur 6 reçoit (C72) cette requête d'initiation MSG1 qu'elle transmet (C74) ensuite au terminal IP T2. 3063407 20 Le terminal IP T2 reçoit la requête d'initiation MSG2 lors d'une étape de réception D74. Le serveur de test SV, le serveur 6 et le terminal IP T2 poursuivent ensuite le traitement de façon identique à ce qui a été décrit précédemment en référence aux figures 4-5. 5 La variante représentée en figure 7 est notamment possible lorsque le serveur d'applications 8 est configure pour laisser (c'est-à-dire ne pas supprimer) le paramètre PR dans la requête d'initiation MSG1 lorsque cette dernière est transmise par le serveur d'applications 8 depuis le serveur de test SV vers le terminal IP T2. Il est aussi possible de mettre en oeuvre la variante représentée en figure 7 sans 10 faire intervenir un serveur d'applications 8 tel que représenté en figure 4. Dans ce cas, le serveur de test SV peut éventuellement être situé dans le réseau IMS 2. Par ailleurs, selon une variante représentée en figure 8, lors de l'étape de test B18 (figure 4), le serveur de test SV tente de clôturer (B90) le canal de signalisation Cl et le canal C2 de transmission de données multimédia. Le serveur de test SV détermine (B92) 15 ensuite si la tentative de clôture de chacun des canaux a réussi. Le serveur de test SV inclut (B94) alors le résultat obtenu en B92 dans le résultat RES fourni par le serveur de test SV lors de l'étape d'envoi B22. Il est ainsi possible pour le serveur de test SV de tester la phase de clôture des canaux de signalisation et de données et d'ajouter le résultat de ce test au résultat final 20 RES fourni à l'utilisateur 10 sur son terminal Ti. Les résultats du test réalisé par le serveur de test s'en trouvent ainsi enrichis. Un homme du métier comprendra que les modes de réalisation et variantes décrits ci- avant ne constituent que des exemples non limitatifs de mise en oeuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou 25 combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin spécifique. REVENDICATIONS1. Procédé de test d'une liaison de communication (CM) entre un serveur de test (SV) et un terminal IP (T2), le procédé étant mis en oeuvre par le serveur de test, ledit procédé comprenant les étapes suivantes : déclenchement d'un envoi, via un réseau de communication IP (2), d'une requête d'initiation (MSG1 ; MSG4) d'une communication IP à destination du terminal IP, ladite requête d'initiation comportant un paramètre (PR) commandant au terminal IP (T2) d'accepter automatiquement la communication initiée par le serveur de test, en cas de réception, via le réseau de communication, d'un message d'acceptation (MSG2) de la communication IP en provenance du terminal IP, établissement d'un canal de transmission (C2) de données multimédia, au travers du réseau de communication IP (2), entre le serveur de test et le terminal IP; et test pour évaluer une qualité de communication entre le serveur de test (SV) et le terminal IP (T2) au travers du canal de transmission (C2). 2. Procédé selon la revendication 1, dans lequel le serveur de test (SV) est situé à l'extérieur du réseau de communication IP, l'étape de déclenchement comprenant un envoi de la requête d'initiation (MSG1) à un deuxième serveur (6) dans le réseau de communication IP de sorte que ledit deuxième serveur insère ledit paramètre (PR) dans la requête d'initiation avant son envoi audit terminal IP (T2). 3. Procédé selon la revendication 1, l'étape de déclenchement comprenant une insertion dudit paramètre (PR) par le serveur de test (SV) dans la requête d'initiation avant envoi de ladite requête, via le réseau de communication IP (2), au terminal IP. 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel si, au lieu du message d'acceptation (MSG2), le serveur de test (SV) reçoit un message du réseau de communication IP indiquant que le routage de la requête d'initiation (MSG1) vers le terminal IP a échoué, le serveur de test détermine que la liaison de communication entre le serveur de test et le terminal IP est défaillante. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel l'étape de test comprend : - une réception, via le canal de transmission (C2), d'une pluralité de premiers paquets (PQ1) de données IP provenant du terminal IP; et 3063407 22 une détermination, à partir de la pluralité de premiers paquets (PQ1) de données IP reçus, d'un degré de qualité de la communication depuis le terminal IP (T2) vers le serveur de test (SV) dans le canal de transmission (C2). 5 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel l'étape de test comprend : un envoi d'une pluralité de deuxièmes paquets (PQ2) de données IP au terminal IP (T2) de sorte à ce que ledit terminal IP puisse tester la qualité de communication du canal de transmission ; et 10 une réception, en provenance du terminal IP, via le canal de transmission (C2), d'un degré de qualité de la communication depuis le serveur de test (SV) vers le terminal IP (T2) dans le canal de transmission. 7. Procédé selon l'une quelconque des revendications 1 à 6, comprenant une étape 15 de détermination, à partir d'une donnée insérée par le terminal IP dans le message d'acceptation reçu, que c'est effectivement le terminal IP qui a accepté la communication IP initiée par le serveur de test. 8. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel l'étape de 20 test comprend : une tentative de clôture dudit canal de transmission (C2) de données multimédia et d'un canal de signalisation (Cl) établi entre le serveur de test (SV) et le terminal IP (T2) suite au message d'acceptation (MSG2) reçu ; et une détermination de la réussite ou non de la tentative de clôture de chacun des 25 canaux. 9. Procédé de traitement destiné à permettre un test d'une liaison de communication IP (CM) entre un serveur de test (SV) et un terminal IP (T2), ledit procédé étant mis en oeuvre par un système de réseau (4) situé dans un réseau de communication IP (2) de 30 sorte à faire l'interface entre le serveur de test et le terminal IP, le procédé comprenant les étapes suivantes : réception, en provenance du serveur de test, d'une requête d'initiation (MSG1) d'une communication IP à destination du terminal IP; insertion d'un paramètre (PR) dans la requête d'initiation (MSG1) ; 35 envoi de la requête d'initiation (MSG1) comportant ledit paramètre prédéterminé au terminal IP, ledit paramètre commandant au terminal IP d'accepter automatiquement la communication initiée par le serveur de test (SV) ; 3063407 23 réception, en réponse à la requête d'initiation (MSG1), d'un message d'acceptation (MSG2) de la communication IP en provenance du terminal IP; et transmission du message d'acceptation (MSG2) au serveur de test de sorte à déclencher l'établissement d'un canal de transmission (C2) de données multimédia 5 entre le serveur de test (SV) et le terminal IP (T2) via ledit système de réseau (4) ; et transmission de paquets de données IP (PQ1 ; PQ2) entre le serveur de test (SV) et le terminal IP (T2) via le canal de transmission (C2) de sorte à permettre une évaluation par le serveur de test (SV) d'une qualité de communication entre ledit 10 serveur de test et le terminal IP (T2) au travers du canal de transmission. 10. Procédé selon la revendication 9, dans lequel le réseau de communication IP est un réseau IMS, le système de réseau comprenant : o un serveur P-CSCF configuré pour réaliser les étapes de réception, l'étape 15 d'insertion, l'étape d'envoi et l'étape de transmission du message d'acceptation ; et o un serveur C-BGF configuré pour réaliser l'étape de transmission des paquets de données IP, ledit canal de transmission (C2) étant établi par l'intermédiaire dudit serveur C-BGF. 20 11. Procédé selon la revendication 9 ou 10, comprenant une étape de détermination que le terminal IP est enregistré ou non auprès du réseau de communication IP ; et dans lequel : - le système de réseau (4) réalise l'étape d'insertion du paramètre dans la requête 25 d'initiation (MSG1) et l'étape d'envoi de ladite requête d'initiation (MSG1) comportant le paramètre (PR) seulement si le terminal IP (T2) est enregistré auprès du réseau de communication IP (2) ; - si le terminal IP (T2) n'est pas enregistré auprès du réseau de communication IP (2), le système de réseau (4) envoie au serveur de test (SV) un message (MSG3) indiquant 30 que le routage de la requête d'initiation (MSG1) vers le terminal IP a échoué. 12. Programme d'ordinateur (PG1 ; PG2) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté par un ordinateur. 35 3063407 24 13. Support d'enregistrement (20; 30) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1 ; PG2) comprenant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 11. 5 14. Serveur de test (SV) d'une liaison de communication IP (CM) entre ledit serveur de test et un terminal IP (T2), comprenant : un module d'envoi (MD2) configuré pour déclencher un envoi, via un réseau de communication IP (2), d'une requête d'initiation (MSG1 ; MSG4) d'une communication IP à destination du terminal IP, ladite requête d'initiation 10 comportant un paramètre (PR) commandant au terminal IP (T2) d'accepter automatiquement la communication initiée par le serveur de test ; module de connexion (MD4) configuré, en cas de réception via le réseau de communication IP d'un message d'acceptation (MSG2) de la communication IP en provenance du terminal IP, pour établir un canal de transmission (C2) de données 15 multimédia, au travers du réseau de communication IP (2), entre le serveur de test et le terminal IP; et un module de test (MD6) pour évaluer une qualité de communication entre le serveur de test (SV) et le terminal IP (T2) au travers du canal de transmission (C2). 20 15. Système de réseau (4) situé dans un réseau de communication IP (2) de sorte à faire l'interface entre un serveur de test (SV) et un terminal IP, ledit serveur de test étant destiné à tester une liaison de communication IP (CM) entre le serveur de test et le terminal IP, ledit système de réseau comprenant : 25 un premier module de réception (MD20) configuré pour recevoir, en provenance du serveur de test, une requête d'initiation (MSG1) d'une communication IP à destination du terminal IP ; un module d'insertion (MD22) configuré pour insérer un paramètre (PR) dans la requête d'initiation, ledit paramètre commandant au terminal IP d'accepter 30 automatiquement la communication initiée par le serveur de test (SV) ; un module d'envoi (MD24) configuré pour envoyer la requête d'initiation (MSG1) comportant ledit paramètre au terminal IP; un deuxième module de réception (MD26) configuré pour recevoir, en réponse à la requête d'initiation (MSG1), un message d'acceptation (MSG2) de la 35 communication IP en provenance du terminal IP; un premier module de transmission (MD28) configuré pour transmettre le message d'acceptation (MSG2) au serveur de test de sorte à déclencher 3063407 25 l'établissement d'un canal de transmission (C2) de données multimédia entre le serveur de test (SV) et le terminal IP (T2) via ledit système de réseau (4) ; et un deuxième module de transmission (MD30) configuré pour transmettre des paquets de données IP (PQ1 ; PQ2) entre le serveur de test (SV) et le terminal IP (T2) via le canal de transmission (C2) de sorte à permettre une évaluation par le serveur de test (SV) d'une qualité de communication entre ledit serveur de test et le terminal IP (T2) au travers du canal de transmission.