FR3063407A1 - Test de liaison de communication ip - Google Patents

Test de liaison de communication ip Download PDF

Info

Publication number
FR3063407A1
FR3063407A1 FR1751510A FR1751510A FR3063407A1 FR 3063407 A1 FR3063407 A1 FR 3063407A1 FR 1751510 A FR1751510 A FR 1751510A FR 1751510 A FR1751510 A FR 1751510A FR 3063407 A1 FR3063407 A1 FR 3063407A1
Authority
FR
France
Prior art keywords
terminal
test server
communication
test
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1751510A
Other languages
English (en)
Other versions
FR3063407B1 (fr
Inventor
Miguel Labranche
Juan Pascual
Laurent Pose
Laurent Borderie
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1751510A priority Critical patent/FR3063407B1/fr
Publication of FR3063407A1 publication Critical patent/FR3063407A1/fr
Application granted granted Critical
Publication of FR3063407B1 publication Critical patent/FR3063407B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H04L43/55—Testing of service level quality, e.g. simulating service usage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Quality & Reliability (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention propose un procédé de test d'une liaison de communication (CM) entre un serveur de test (SV) et un terminal IP (T2), comprenant : déclenchement d'un envoi, via un réseau de communication IP (2), d'une requête d'initiation d'une communication IP à destination du terminal IP, cette requête d'initiation comportant un paramètre commandant au terminal IP (T2) d'accepter automatiquement la communication IP ; en cas de réception d'un message d'acceptation 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).

Description

(54) TEST DE LIAISON DE COMMUNICATION IP.
FR 3 063 407 - A1 _ L'invention propose un procédé de test d'une liaison de communication (CM) entre un serveur de test (SV) et un terminal IP (T2), comprenant: déclenchement d'un envoi, via un réseau de communication IP (2), d'une requête d'initiation d'une communication IP à destination du terminal IP, cette requête d'initiation comportant un paramètre commandant au terminal IP (T2) d'accepter automatiquement la communication IP; en cas de réception d'un message d'acceptation 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).
Figure FR3063407A1_D0001
Figure FR3063407A1_D0002
Figure FR3063407A1_D0003
Figure FR3063407A1_D0004
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 œuvre 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.
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 œuvre 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 ;
- 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 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 à 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 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 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 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 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 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 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 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 :
- 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.
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 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 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 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 qu'un service de messagerie vocale (ou autre) configuré 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 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.
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 œuvre dans un dispositif tel qu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre 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.
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 œuvre 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 :
- 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 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
- 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 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 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 configuré pour réaliser les étapes de réception, l'étape 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 é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 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 ;
- 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.
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 œuvre dans un système de réseau tel qu'un serveur ou un groupe de serveurs, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d’un procédé de traitement 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.
A noter que les programmes mentionnés dans le présent exposé peuvent utiliser 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 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 dise) 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 é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.
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 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 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 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 :
- 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 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 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 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 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 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 œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu’à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d’ordinateur, un ou plusieurs sous-programmes d’un programme, ou de manière plus générale à tout élément d’un programme ou d’un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
- la figure 1 représente schématiquement un environnement E comprenant un réseau 2 et un serveur de test SV ;
- la figure 2 représente schématiquement des blocs fonctionnels mis en œuvre par un serveur de test selon un mode de réalisation particulier de l’invention ;
- la figure 3 représente schématiquement des blocs fonctionnels mis en œuvre 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 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 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 ;
- 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.
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 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 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 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 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 par l'intermédiaire dudit système de réseau.
L'invention concerne en outre les procédés mis en œuvre 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.
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 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 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 œuvre 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 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 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 Tl configuré pour contrôler le serveur de 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 Génération 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 système de réseau 4 (ou sous-système). Le système de réseau 4 constitue par exemple le cœur de réseau du réseau IMS 2 ou une sous-partie de ce cœur de réseau. Dans cet exemple, le système de réseau 4 comprend un serveur 6 de type P-CSCF (pour « ProxyCall Session Contrai 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 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 l'échange de données de signalisation entre le serveur de test SV et les terminaux IP T2T4 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 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 T2-T4 via le serveur 7.
A noter toutefois que d'autres mises en œuvre 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 »).
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 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. 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 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 configuré pour tester une 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 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 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, 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 test selon un mode de réalisation particulier. Les étapes de ce procédé seront décrites ultérieurement.
Dans cet exemple, le serveur de test SV peut être contrôlé à distance par un terminal Tl (figure 1). Plus particulièrement, le terminal Tl est ici configuré pour envoyer au serveur de test SV l'identifiant respectif ID2-ID4 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 ce faire, le terminal Tl 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, 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 œuvre soient possibles sans cette fonction comme indiqué ci-dessus.
Toujours dans cet exemple, le serveur de test SV est en outre configuré pour 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 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 œuvre étant possibles dans le cadre de l'invention.
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 œuvre 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 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.
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.
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 (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 réseau 4 piloté par les programmes d'ordinateur PG2 et PG3 met en œuvre 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 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'autoré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 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 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 canal de transmission C2.
Selon l'exemple représenté en figure 1, le serveur 6 met en œuvre les modules MD20 à MD26 tandis que le serveur 8 met en œuvre les modules MD28 et MD30.
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 les figures 2 et 3 ne constituent qu'un exemple de mise en œuvre 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 œuvre un procédé de test de l'invention en exécutant le programme PG1. De même, le système de réseau 4 (figures 1 et 3) met en œuvre 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 son terminal Tl. En réponse à cette sélection, le terminal Tl 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.
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.
Aussi, le serveur de test SV envoie (B6) une requête MSG1 d'initiation d'une communication IP destinée au terminal IP T2. Cette requête d'initiation MSG1 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.
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 (CIO) au terminal IP T2. Ce paramètre PR, appelé aussi paramètre d'auto-réponse, commande au 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
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 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 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 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 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.
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 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 transmission C2. Le canal de signalisation Cl et le canal de transmission C2 forment ensemble une liaison de données IP notée CM.
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 au terminal Tl 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 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 IP T2 vers le serveur de test SV ;
- 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 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 Tl afin d'en informer l'utilisateur 10. Le terminal Tl 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 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é 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 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 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 ici envoyé sous la forme d'un flux RTCP (pour « Real-time Transport Contrai 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 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 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 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 Tl. Au cours de l'étape de réception A22, le terminal Tl reçoit le 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 Tl en B22 peut é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 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.
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 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.
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 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 terminal T2 qui répond à la requête d'initiation MSG1 (et non, par exemple, un service de messagerie mis en œuvre 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 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 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.
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 œuvre le procédé de test.
Plus précisément, le terminal Tl 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 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.
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 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 Tl qui le reçoit en A56.
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.
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 luimê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 Tl envoie (A2) l'identifiant ID2 du terminal IP T2 au 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 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.
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.
La variante représentée en figure 7 est notamment possible lorsque le serveur d'applications 8 est configuré 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 œuvre la variante représentée en figure 7 sans 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) 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 RES fourni à l'utilisateur 10 sur son terminal Tl. 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 ciavant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin spécifique.

Claims (15)

  1. REVENDICATIONS
    1. 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 œuvre 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. 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. 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. 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. 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
    - 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).
  6. 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
    - 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. 7. Procédé selon l'une quelconque des revendications 1 à 6, comprenant une étape 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. 8. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel l'étape de 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 canaux.
  9. 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 œuvre par un système de réseau (4) situé dans un réseau de communication IP (2) de 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) ;
    - 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) ;
    - 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 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 serveur de test et le terminal IP (T2) au travers du canal de transmission.
  10. 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 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.
  11. 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 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 que le routage de la requête d'initiation (MSG1) vers le terminal IP a échoué.
  12. 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.
  13. 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.
  14. 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 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 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).
  15. 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 :
    - 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 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 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 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
    5 (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.
    1/4
    2/4 sv
FR1751510A 2017-02-24 2017-02-24 Test de liaison de communication ip Active FR3063407B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1751510A FR3063407B1 (fr) 2017-02-24 2017-02-24 Test de liaison de communication ip

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1751510 2017-02-24
FR1751510A FR3063407B1 (fr) 2017-02-24 2017-02-24 Test de liaison de communication ip

Publications (2)

Publication Number Publication Date
FR3063407A1 true FR3063407A1 (fr) 2018-08-31
FR3063407B1 FR3063407B1 (fr) 2021-09-10

Family

ID=58739132

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1751510A Active FR3063407B1 (fr) 2017-02-24 2017-02-24 Test de liaison de communication ip

Country Status (1)

Country Link
FR (1) FR3063407B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3145456A1 (fr) * 2023-01-31 2024-08-02 Orange Procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030231741A1 (en) * 2002-06-14 2003-12-18 G3 Nova Technology, Inc. Multi-protocol, multi-interface communications device testing system
US20100083045A1 (en) * 2008-09-29 2010-04-01 Chaoxin Qiu Methods and apparatus to perform quality testing in internet protocol multimedia subsystem based communication systems
KR100954593B1 (ko) * 2009-09-18 2010-04-26 보라시스(주) 음성패킷망 품질측정 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030231741A1 (en) * 2002-06-14 2003-12-18 G3 Nova Technology, Inc. Multi-protocol, multi-interface communications device testing system
US20100083045A1 (en) * 2008-09-29 2010-04-01 Chaoxin Qiu Methods and apparatus to perform quality testing in internet protocol multimedia subsystem based communication systems
KR100954593B1 (ko) * 2009-09-18 2010-04-26 보라시스(주) 음성패킷망 품질측정 방법

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3145456A1 (fr) * 2023-01-31 2024-08-02 Orange Procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique
WO2024160564A1 (fr) 2023-01-31 2024-08-08 Orange Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique

Also Published As

Publication number Publication date
FR3063407B1 (fr) 2021-09-10

Similar Documents

Publication Publication Date Title
WO2007010163A2 (fr) Dispotif de gestion de ressources de serveurs media pour l'interfacage entre serveurs d'applications et serveurs media au sein d'un reseau de communication
EP3777081B1 (fr) Procédé de gestion d'une pluralité de flux média, et dispositif associé
EP3053303A1 (fr) Procede d'abonnement a des flux en provenance de clients multicast
WO2012022909A1 (fr) Traitement de transfert de communication en mode sip
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
FR3063407A1 (fr) Test de liaison de communication ip
WO2014083289A1 (fr) Routage d'une requete de service visant un abonne ims
WO2012042150A1 (fr) Procédé de gestion de la priorité de flux média préliminaires
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
EP2266279B1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
WO2020136315A1 (fr) Procédé de traitement de messages vocaux, procédé de désactivation d'un codage dtmf et procédé de traitement d'une demande de désactivation d'un codage dtmf
EP3808060A1 (fr) Procédé de traitement de messages par un dispositif d'un réseau de voix sur ip
FR2970137A1 (fr) Gestion des equipements utilisateurs ayant la meme identite publique par un serveur d'application dans un reseau ims
EP3472993B1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
EP3225006B1 (fr) Procédé de négociation de codecs dans les réseaux ip
WO2018002469A1 (fr) Procédé et dispositif de gestion d'une session de transmission d'un flux vidéo
EP2801178A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip
FR3145456A1 (fr) Procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique
EP2238727B1 (fr) Procédé de communication pour gérer des sessions de communication au niveau d'une passerelle domestique
WO2004100492A1 (fr) Procede et dispositif de synchronisation de flux de donnees
WO2017103486A1 (fr) Procede de communication entre un terminal appelant et une pluralite de terminaux appeles
WO2013001211A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé
FR2979505A1 (fr) Procede d'insertion d'un equipement intermediaire permettant le controle a distance de la qualite d'une communication
FR2988885A1 (fr) Base de donnees, serveur hss, et serveurs de controle d'un reseau ims
FR2963182A1 (fr) Procede de mise en oeuvre de services dans un reseau de telecommunications

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180831

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10