Brevet FR2916924A1 — publié le 20081205

DISPOSITIF ET PROCÉDÉ DE RÉCUPÉRATION DE DONNÉES D'ÉTAT POUR DES ÉQUIPEMENTS D'UN RÉSEAU DE COMMUNICATION L'invention concerne les réseaux de communication, et plus précisément la restauration (ou le rétablissement) des états en cours d'applications qui sont utilisées (ou hébergées) par des équipements appartenant à de tels réseaux, en cas de problème survenu dans l'un de ces équipements. On entend ici par état d'une application des données discriminantes d'un contexte d'appel impliquant un ensemble de participants, dites statiques dans le cadre de l'invention, ainsi qu'éventuellement des données dites dynamiques, comme par exemple l'état d'une ou plusieurs temporisations (ou timers ) devant déclencher des tâches spécifiques, par exemple consécutivement à la réception d'un message ou bien pour envoyer périodiquement des requêtes par exemple pour maintenir ou rafraîchir un contexte de serveur de présence ou pour effectuer une synchronisation dans un système dit convergent. Comme le sait l'homme de l'art, certains réseaux de communication, dits tolérants aux erreurs (ou fault tolerant ), sont agencés pour récupérer les états en cours d'applications qui sont utilisées par un équipement objet d'un problème (ou crash ) afin de les communiquer à un ou plusieurs autres équipements fonctionnant correctement pour qu'ils puissent utiliser ces applications à la place de celui qui est tombé (défaillant). C'est ce que l'on appelle la restauration (ou le rétablissement) d'application(s) ou plus précisément de contexte(s) d'appel. On comprendra que ces restaurations doivent se faire aussi vite que possible tout en minimisant l'impact sur la réactivité générale. Pour permettre ces restaurations, un réseau de (télé)communication 30 peut redonder ses ressources selon l'un ou l'autre des mécanismes de gestion suivants : - une gestion de la redondance dite N+N dans laquelle un noeud actif est 2 2916924 redondé par un noeud passif. En théorie, ce mécanisme supporte que N noeuds soient simultanément en panne, une gestion de la redondance dite N+M (avec M La récupération des données d'état peut se faire d'au moins deux façons. Une première façon consiste, chaque fois que l'on détecte un problème dans un équipement de réseau (concerné), à charger un 3 2916924 équipement choisi de récupérer séquentiellement dans un moyen de stockage de données d'état toutes les données d'état qui sont relatives à chaque application dont il a désormais la charge, puis à sélectionner parmi les données d'état récupérées celles qui doivent être effectivement restaurées du 5 fait qu'elles ont été signalées par un message spécifique désignant leur(s) application(s). L'inconvénient de cette première façon réside dans le fait qu'elle induit des restaurations assez lentes en particulier lorsque des données d'état à restaurer sont dynamiques. En effet, il faut alors redémarrer certaines tâches d'arrière plan selon une fréquence prédéfinie, ce qui peut io avoir un impact sur la réactivité générale, en particulier pendant les heures de pointe. Ceci est évident lorsque le système de secours est déjà actif, typiquement dans une architecture redondée de type N+M. Ceci peut être également vrai dans une architecture redondée de type N+N où le temps dit de basculement vers le système de secours peut se trouver retardé. Cette 15 première façon s'avère donc difficilement compatible avec un fonctionnement en temps réel de certaines applications, en particulier lorsqu'elles mettent en oeuvre des traitements asynchrones et/ou pendant les heures de pointe. Une seconde façon consiste à attendre que l'équipement, qui a été choisi pour se substituer à un équipement tombé, reçoive un message relatif à 20 une application, qu'il sait considérer comme étant hors contexte, pour récupérer dans le moyen de stockage de données d'état concerné les données d'état qui sont relatives à cette application. C'est notamment ce qui est préconisé dans le chapitre 12.2.2 de la RFC 3261 de l'IETF (accessible à l'adresse http ://www.ietf.org/rfc3261.txt ). Cette seconde façon est 25 avantageuse pour les équipements car elle permet une récupération à la demande. Mais, du fait qu'elle dépend de l'arrivée des messages, elle n'est pas bien adaptée aux applications dont les états sont définis par des données d'état dynamiques dont l'exécution peut être contrainte temporellement. Aucune solution connue n'apportant une entière satisfaction, 30 l'invention a donc pour but d'améliorer la situation. Elle propose à cet effet un procédé, dédié à la récupération de données d'état définissant les états en cours d'applications utilisées dans des équipements d'un réseau de communication, et consistant : 4 2916924 - à associer un identifiant unique, dit identifiant d'application , à chacun des contextes d'appel traités par une même application (ou une même (entité) logique applicative ) d'un équipement de réseau, - à stocker dans au moins un moyen de stockage du réseau les données 5 d'état des applications en correspondance de leurs identifiants d'application, et en cas de détection d'un problème survenu dans au moins un équipement, à récupérer séquentiellement dans le moyen de stockage concerné les données d'état relatives à chaque application utilisée par cet 10 équipement et les identifiants d'application correspondants, et, en cas de réception d'un message relatif à une application utilisée par cet équipement, à déterminer l'identifiant d'application qu'il désigne puis les données d'état correspondantes parmi les données d'état récupérées et parmi les données d'état stockées dans le moyen de stockage concerné si 15 elles n'ont pas encore été récupérées. Le procédé selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - on peut adjoindre un identifiant d'application à un message relatif à l'application correspondante ; 20 en variante, on peut déterminer un identifiant d'application à partir d'informations qui sont contenues dans un message relatif à l'application correspondante ; on peut mettre à jour (éventuellement périodiquement) les données d'état qui sont stockées dans le moyen de stockage concerné ; 25 on peut transmettre (éventuellement périodiquement) des messages d'interrogation aux équipements, et en l'absence de réponse d'un équipement on considère qu'il fait l'objet d'un problème détecté ; en présence d'au moins deux équipements de réseau et en cas de détection d'un problème au niveau d'un équipement, on peut avertir l'un 30 au moins des autres équipements de réseau de l'existence d'un problème dans cet équipement, de sorte qu'il procède à la récupération des données d'application des applications qui sont utilisées par l'équipement tombé ; 5 2916924 lorsque l'on reçoit un message désignant un identifiant d'application, mais que les données d'état correspondant à cet identifiant d'application n'ont pas encore été récupérées séquentiellement, on peut poursuivre la récupération séquentielle pour les autres identifiants d'application et 5 récupérer en parallèle les données d'état recherchées (de l'identifiant d'application concerné) directement dans le moyen de stockage concerné ; - on peut récupérer en parallèle les données d'état recherchées directement dans le moyen de stockage après avoir verrouillé les lo données d'état, de manière à prévenir (éviter) une restauration parallèle des données identifiées au moyen de l'identifiant d'application par la récupération séquentielle ; - en variante, après avoir récupéré en parallèle les données d'état recherchées directement dans le moyen de stockage, on peut vérifier 15 que l'on n'active pas le contexte restauré deux fois de suite ; les données d'état sont choisies parmi des données, dites statiques, discriminantes d'un contexte d'appel impliquant un ensemble de participants, et des données, dites dynamiques, variables dans le temps. L'invention propose également un dispositif, dédié à la récupération 20 de données d'état définissant les états en cours d'applications utilisées dans des équipements d'un réseau de communication, et comprenant des moyens de traitement chargés, en cas de détection d'un problème survenu dans au moins un équipement du réseau, de récupérer séquentiellement dans un moyen de stockage des données d'état relatives à chaque application utilisée 25 par cet équipement et stockées en correspondance d'identifiants d'application associés à chaque contexte d'appel traité par chaque application, et, en cas de réception d'un message relatif à une application utilisée par cet équipement, de déterminer l'identifiant d'application qui est désigné par ce message puis les données d'état correspondantes parmi les données d'état 30 récupérées et parmi les données d'état qui sont stockées dans le moyen de stockage concerné si elles n'ont pas encore été récupérées. Le dispositif selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : 6 2916924 il peut comprendre des moyens de détection chargés de générer (éventuellement périodiquement) des messages d'interrogation destinés aux équipements, et en l'absence de réponse d'un équipement de signaler aux moyens de traitement que cet équipement est tombé ; 5 - en cas de réception d'un message désignant un identifiant d'application, si les données d'état correspondant à cet identifiant d'application n'ont pas encore été récupérées séquentiellement, les moyens de traitement peuvent être chargés de poursuivre la récupération séquentielle pour les autres identifiants d'application et de récupérer en parallèle les données io d'état recherchées directement dans le moyen de stockage concerné ; - les moyens de traitement peuvent être chargés de récupérer en parallèle les données d'état recherchées directement dans le moyen de stockage après avoir verrouillé les données d'état, afin de prévenir (éviter) une restauration parallèle des données identifiées au moyen de l'identifiant 15 d'application par la récupération séquentielle ; > en variante, les moyens de traitement peuvent être chargés de vérifier que l'on n'active pas le contexte restauré deux fois de suite, après avoir récupéré en parallèle les données d'état recherchées directement dans le moyen de stockage. 20 L'invention propose également un équipement de réseau (par exemple un serveur) équipé d'une partie au moins d'un dispositif de récupération de données d'état du type de celui présenté ci-avant. L'invention est particulièrement bien adaptée, bien que de façon non exclusive, aux réseaux de communication utilisant un protocole de 25 signalisation asynchrone, par exemple de type HTTP ou de type SIP (pour Session Initiation Protocol - défini par la RFC 3261 de l'IETF) ou l'une de ses extensions ou variantes. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et du dessin annexé, sur lequel 30 l'unique figure illustre de façon très schématique et fonctionnelle un réseau de communication comprenant des serveurs équipés d'un exemple de réalisation d'un dispositif de récupération de données d'état selon l'invention. Le dessin annexé pourra non seulement servir à compléter 7 2916924 l'invention, mais aussi contribuer à sa définition, le cas échéant. L'invention a pour objet de permettre une récupération optimisée de données d'état définissant les états en cours d'applications utilisées par des équipements d'un réseau de communication tolérant aux erreurs, en vue du 5 rétablissement (ou de la restauration) rapide de leurs contextes d'appel tout en minimisant l'impact sur la réactivité générale du réseau. Dans ce qui suit, on considère à titre d'exemple non limitatif que les équipements de réseau font partie d'un (coeur de) réseau de communication de type IMS ( Internet Multimedia (core network) Subsystem ). Mais, io l'invention n'est pas limitée à ce type de coeur de réseau de communication. Elle concerne en effet tout type de coeur de réseau de communication tolérant aux erreurs et permettant à des équipements de réseau d'utiliser des applications dont les états respectifs sont définis par des données d'état. Par conséquent, le réseau de communication pourra être un réseau fixe, comme 15 par exemple un réseau xDSL, ou encore un domaine d'un réseau local sans fil (standards WLAN ( Wireless Local Area Network -IEEE 802.11, Wi-Fi, ETSI HiperLAN/2), Bluetooth (IEEE 802.15), WiMAX (IEEE 802.16, ETSI HiperMAN) et Zigbee). Par ailleurs, on considère dans ce qui suit, à titre d'exemple non 20 limitatif, que les équipements de réseau sont des serveurs utilisant un protocole de signalisation asynchrone de type SIP (ou l'une de ses extensions ou variantes). Mais, l'invention n'est limitée ni à ce type d'équipement de réseau ni à ce type de protocole de signalisation. Ainsi, les équipements de réseau peuvent être, également et notamment, des passerelles, des relais 25 (par exemple de type B2BUA ( Back-to-Back User Agent )) ou des serveurs de redirection ou intermédiaires (par exemple de type proxy ). Sur l'unique figure se trouve schématiquement illustré un coeur de réseau IMS R auquel sont connectés trois serveurs (ou noeuds) S1 à S3 (i=1 à 3) capables d'utiliser (ou mettre en oeuvre) des applications dont les états 30 respectifs sont définis par des données d'état dites statiques, comme par exemple des identifiants d'appel, ainsi qu'éventuellement des données d'état dites dynamiques, comme par exemple les états de temporisations (ou timers ) devant déclencher des tâches (ou traitements) spécifiques 8 2916924 (éventuellement asynchrones), par exemple consécutivement à la réception d'un message ou bien pour envoyer périodiquement des requêtes, par exemple pour maintenir ou rafraîchir un contexte de serveur de présence ou pour effectuer une synchronisation dans un système dit convergent. 5 On notera que dans le cas d'un protocole de signalisation de type SIP, les états SIP des applications sont définis par un contexte pouvant impliquer un ensemble de dialogues et un jeu de temporisations. Afin de rendre le réseau tolérant aux erreurs constituées par les problèmes (ou crashes ) rencontrés par ses équipements Si, l'invention lo propose tout d'abord d'associer un identifiant unique, dit identifiant d'application , à chacun des contextes d'appel qui sont traités par une même application (ou par une même (entité) logique applicative ) d'un équipement de réseau Si, et de stocker dans au moins un moyen de stockage RS du réseau les données d'état en cours des applications en 15 correspondance de leurs identifiants d'application respectifs. En d'autres termes, à chaque contexte d'appel traité par une application est associé un identifiant d'application propre. On notera que les données d'état des applications et les identifiants d'application correspondants, qui sont utilisés dans le réseau, peuvent être 20 stockés dans un seul moyen de stockage RS (comme illustré de façon non limitative sur l'unique figure) ou bien dans plusieurs moyens de stockage RS (éventuellement séparés physiquement), de façon redondante ou de façon répartie. Par exemple, chaque équipement (ou noeud) Si peut comporter un moyen de stockage RS. 25 Chaque moyen de stockage RS se présente par exemple sous la forme d'un registre ou d'une base de données ou encore d'un système réparti, par exemple de type pair à pair (ou peer-to-peer ) dont la clé de répartition peut servir à identifier un noeud de stockage. On notera que l'on peut stocker dans au moins un équipement du 30 réseau (éventuellement les équipements Si) une table de correspondance entre chaque identifiant d'application et un identifiant de communication de l'équipement Si qui a la charge de l'application correspondante ainsi qu'un identifiant de communication de l'équipement Si' qui a été choisi par le réseau 9 2916924 pour se charger de cette application à la place de l'équipement Si au cas où il tomberait. Dans ce cas, chaque équipement Si doit comporter un moyen de stockage RS stockant les données d'état des applications dont il a la charge, et lorsqu'une application est désignée par son identifiant d'application on 5 détermine dans la table de correspondance l'identifiant de communication qui lui correspond et qui est celui de l'équipement Si dans lequel sont stockées ses données d'état. Toute méthode peut être envisagée pour alimenter le(s) moyen(s) de stockage RS. Ainsi, les équipements Si peuvent par exemple être chargés de lo communiquer à un (des ou leur) moyen(s) de stockage RS, éventuellement périodiquement, les données d'état des applications dont ils ont la charge, afin de mettre à jour (éventuellement périodiquement) son (leur) contenu. Dans une variante, le réseau pourrait comporter un équipement dédié, d'une part, à la collection (éventuellement périodique) auprès des équipements Si 15 des données d'état des applications dont ils ont respectivement la charge, et d'autre part, à la mise à jour (éventuellement périodique) du contenu de chaque moyen de stockage RS compte tenu des données d'état collectées. L'invention propose également, chaque fois que l'on détecte au sein du réseau qu'au moins un équipement Si' est tombé (c'est-à-dire fait l'objet 20 d'un problème) et donc qu'il n'est plus en mesure de servir à au moins une application, de récupérer séquentiellement dans le moyen de stockage RS concerné les données d'état, qui sont relatives à chaque application dont cet équipement Si' avait jusqu'alors la charge, et les identifiants d'application correspondants, et, en cas de réception d'un message (ici SIP) relatif à une 25 application dont cet équipement Si' avait jusqu'alors la charge, à déterminer l'identifiant d'application qui est désigné par ce message puis les données d'état correspondantes parmi les données d'état récupérées et parmi les données d'état qui sont stockées dans le moyen de stockage RS concerné si elles n'ont pas encore été récupérées. 30 On notera que l'on appelle ici méthode proactive la méthode de récupération séquentielle de toutes les données d'état de toutes les applications qui étaient prises en charge par un équipement tombé Si', tandis que l'on appelle ici méthode réactive la méthode de récupération directe i o 2916924 des données d'état d'une application dont l'identifiant d'application est contenu dans un message SIP reçu et qui était prise en charge par un équipement tombé Si'. On notera par ailleurs que le message qui est relatif à une application 5 peut désigner l'identifiant d'application correspondant soit directement, soit indirectement. Plus précisément, on peut adjoindre un identifiant d'application à un message relatif à l'application correspondante, ou bien on peut déterminer un identifiant d'application à partir d'informations qui sont contenues dans un message relatif à l'application correspondante. 10 Dans le cas d'une adjonction d'identifiant d'application c'est de préférence l'équipement Si qui génère un message relatif à une application qui est chargé de lui adjoindre l'identifiant d'application associé. Mais, cette adjonction pourrait être également effectuée par un équipement dédié du réseau. 15 Un identifiant d'application peut par exemple être adjoint dans un entête spécifique d'un message SIP. A cet effet, on peut par exemple utiliser une méthode du type de celle qui est décrite dans le document brevet FR 0654035 (déposé le 2 octobre 2006). Le message (ici SIP) relatif à une application est généralement 20 transmis à l'équipement Si qui a été choisi par le réseau pour se charger de cette application à la place de l'équipement Si' (i' Fi) tombé. C'est en effet vers cet équipement Si choisi que doivent être désormais transmis les messages SIP relatifs à cette application et les trafics occasionnés par cette dernière. Mais, si ce n'est pas le cas, l'équipement récepteur procède à la récupération 25 des données d'état en verrouillant à distance les ressources par exemple au moyen d'un gestionnaire de transactions partagées (ou shared transaction manager ), puis, il communique à l'équipement Si choisi (ou active dans son propre moyen de stockage RS (dans le cas d'un système réparti dans lequel chaque noeud de réseau Si a la charge d'une réplication d'une partie des 30 états du système global)) les données d'état récupérées de l'application dont il a nouvellement la charge afin qu'il les restaure. Le choix d'un ou des équipements de remplacement est par exemple effectué par un module de répartition de charge (ou load balancing ) MRC 11 2916924 du réseau. On notera que lorsqu'un équipement Si' tombé (ou défaillant) a en charge plusieurs applications, le module MRC peut ordonner à un seul équipement Si de se charger de toutes ces applications, ou bien à plusieurs équipements Si de se charger respectivement d'une ou plusieurs applications. 5 Cela dépend en effet, notamment, des trafics que peuvent encore supporter les autres équipements Si (non défaillants) à l'instant du choix et des trafics occasionnés par les applications à prendre en charge. La récupération des données d'état, d'une application prise en charge par un équipement Si' tombé, peut se faire comme indiqué ci-dessous. lo Lorsque l'on reçoit un message désignant (directement ou indirectement) un identifiant d'application, on commence par déterminer si les données d'état correspondant à cet identifiant d'application ont déjà été récupérées séquentiellement auprès du moyen de stockage RS concerné par la méthode proactive. 15 Dans l'affirmative, on transmet les données d'état à la logique de l'application dans le contexte ainsi restauré et identifié par l'identifiant d'application. Dans la négative, on poursuit la récupération séquentielle des données d'état (par la méthode proactive) pour les autres identifiants 20 d'application et on récupère en parallèle les données d'état recherchées directement dans le moyen de stockage RS concerné (par la méthode réactive) pour l'identifiant concerné. Les deux méthodes proactive et réactive fonctionnant en parallèle elles peuvent toutes les deux permettre de déterminer en parallèle les mêmes 25 données d'état et donc provoquer deux restaurations décalées dans le temps. Or, il faut garantir l'intégrité des traitements (temporisations ou traitement spécifique de l'application après une panne), c'est-à-dire qu'ils ne sont exécutés qu'une seule fois. Pour ce faire, on peut procéder de deux façons. 30 Une première façon consiste à récupérer en parallèle les données d'état recherchées directement dans le moyen de stockage RS après avoir verrouillé les données d'état. On évite ainsi de restaurer en parallèle des données identifiées au moyen de l'identifiant d'application par la récupération 12 2916924 séquentielle. Une seconde façon consiste à vérifier que l'on n'active pas le contexte restauré deux fois de suite après avoir récupéré en parallèle les données d'état recherchées directement dans le moyen de stockage RS. En 5 d'autres termes, on vérifie que les données d'état récupérées par l'une ou l'autre des deux méthodes n'ont pas encore été utilisées pour effectuer la restauration de contexte. Cette vérification peut se faire facilement étant donné que les deux méthodes utilisent le même identifiant d'application pour effectuer leur recherche de données d'état, et donc qu'elles peuvent s'exclure 10 mutuellement, typiquement via un mécanisme de verrouillage qui dépendra de la granularité choisie pour le verrou. Si la vérification indique que l'on peut effectuer la restauration, alors on effectue celle-ci, puis on signale qu'elle a été effectuée afin qu'elle ne soit pas de nouveau effectuée avec les mêmes données d'état récupérées par 15 l'autre méthode. On notera que la récupération des données d'état se fait au moyen d'un dispositif D. Ce dernier peut être implanté dans un équipement du réseau dédié à la récupération. Mais, et comme illustré sur l'unique figure, il est avantageux d'implanter un dispositif de récupération D dans chaque 20 équipement Si susceptible de prendre en charge au moins une application à la place d'un autre équipement tombé Si'. La finalité de ce dispositif D est l'activation en mémoire d'un équipement tombé Si' du contexte équivalent opéré par un équipement Si. Un dispositif de récupération D comprend au moins un module de 25 traitement MT qui est chargé de procéder à une récupération de données d'état, selon les modalités présentées ci-avant, chaque fois qu'un problème de connexion a été détecté dans un équipement Si du réseau. Par conséquent, le module de traitement MT récupère séquentiellement dans un moyen de stockage RS les données d'état qui sont relatives à chaque 30 application qui est utilisée par un équipement tombé Si' (méthode proactive), et consécutivement à la réception d'un message relatif à une application utilisée par l'équipement tombé Si, il détermine l'identifiant d'application qui est désigné par ce message puis les données d'état correspondantes parmi 13 2916924 les données d'état récupérées (méthode proactive) et parmi les données d'état qui sont stockées dans le moyen de stockage RS concerné si elles n'ont pas encore été récupérées (méthode réactive). Par ailleurs, le dispositif D peut être également chargé de la mise à s jour, périodique ou suite à un événement déclenché par la logique de l'application, dans au moins un moyen de stockage RS soit des données d'état qui concernent plusieurs applications, lorsqu'il agit pour plusieurs équipements Si, soit des données d'état qui concernent les applications qui sont à la charge de son équipement Si, lorsqu'il est implanté dans ce dernier. lo De plus, etcomme illustré, le dispositif D peut éventuellement comprendre un module de détection MD chargé de générer (éventuellement périodiquement) des messages d'interrogation destinés aux équipements Si afin de déterminer s'ils peuvent être joints. Dans ce cas, lorsque le module de détection MD ne reçoit pas de réponse d'un équipement Si', il peut le signaler 15 à son module de traitement MT afin qu'il initie la récupération des données d'état des applications prises en charge par l'équipement tombé Si' selon la méthode proactive. Lorsque le dispositif D n'est pas implanté dans un équipement Si, on peut envisager qu'il assure la détection des équipements tombés Si' pour un 20 ensemble d'équipements Si (voire même tous) et qu'il signale au module de traitement MT de l'un au moins de ces équipements Si qu'un autre équipement Si' est tombé afin qu'il initie la récupération des données d'état des applications prises en charge par cet équipement tombé Si' selon la méthode proactive. 25 Le dispositif de récupération de données d'état D selon l'invention, et notamment son module de traitement MT et son éventuel module de détection MD, peuvent être réalisés sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. 30 L'invention permet de restaurer de nombreuses applications (et plus précisément leurs contextes d'appel), notamment dans le domaine des télécommunications, tout en maintenant un niveau de réactivité sensiblement constant au sein du réseau. Par ailleurs, l'invention est particulièrement bien 14 2916924 adaptée, bien que non limitativement, aux applications manipulant des contextes d'appels de durées relativement longues et qui requièrent des traitements asynchrones de message durant la vie de ces contextes. L'invention ne se limite pas aux modes de réalisation de dispositif et 5 de procédé de récupération de données d'état et d'équipement de réseau décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. Ainsi, dans ce qui précède on a décrit un exemple de mise en oeuvre lo de l'invention dans lequel chaque équipement de réseau (pouvant se charger d'au moins une application) est équipé d'un dispositif de récupération de données d'état. Mais, l'invention peut être également mise en oeuvre au moyen d'un seul dispositif de récupération de données d'état agissant pour plusieurs équipements de réseau. 15 15 REVENDICATIONS 1. Procédé de récupération de données d'état définissant les états en cours d'applications utilisées dans des équipements (Si) d'un réseau de communication, caractérisé en ce qu'il consiste i) à associer un identifiant unique, dit identifiant d'application , à chacun des contextes d'appel traités par une même application utilisée par des équipements (Si) dudit réseau, ii) à stocker dans au moins un moyen de stockage (RS) dudit réseau les données d'état des applications en correspondance de leurs identifiants d'application, lo et iii) en cas de détection d'un problème survenu dans au moins un équipement (Si'), à récupérer séquentiellement dans le moyen de stockage (RS) concerné les données d'état relatives à chaque application utilisée par cet équipement (Si') et les identifiants d'application correspondants, et, en cas de réception d'un message relatif à une application utilisée par cet 15 équipement (Si'), à déterminer l'identifiant d'application qu'il désigne puis les données d'état correspondantes parmi lesdites données d'état récupérées et parmi lesdites données d'état stockées dans ledit moyen de stockage (RS) concerné si elles n'ont pas encore été récupérées. 2. Procédé selon la revendication 1, caractérisé en ce que l'on adjoint 20 un identifiant d'application à un message relatif à l'application correspondante. 3. Procédé selon la revendication 1, caractérisé en ce que l'on détermine un identifiant d'application à partir d'informations contenues dans un message relatif à l'application correspondante. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que 25 l'on met à jour les données d'état stockées dans ledit moyen de stockage (RS) concerné. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que l'on transmet des messages d'interrogation auxdits équipements (Si), et en l'absence de réponse d'un équipement (Si) on considère qu'il fait l'objet d'un 30 problème détecté. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'en présence d'au moins deux équipements de réseau (Si) et en cas de détection d'un problème au niveau d'un équipement (Si') on avertit l'un au 16 2916924 moins des autres équipements de réseau (Si, i d) de l'existence d'un problème dans cet équipement (Si'), de sorte qu'il procède à la récupération des données d'application des applications qui sont utilisées par l'équipement (Si') ayant un problème. 5 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'en cas de réception d'un message désignant un identifiant d'application, si les données d'état correspondant à cet identifiant d'application n'ont pas encore été récupérées séquentiellement, on poursuit la récupération séquentielle pour les autres identifiants d'application et on récupère en parallèle les données d'état recherchées directement dans ledit moyen de stockage (RS). 8. Procédé selon la revendication 7, caractérisé en ce que l'on récupère en parallèle les données d'état recherchées directement dans ledit moyen de stockage (RS) après avoir verrouillé les données d'état, de manière à prévenir une restauration parallèle des données identifiées au moyen de l'identifiant d'application par la récupération séquentielle. 9. Procédé selon la revendication 7, caractérisé en ce qu'après avoir récupéré en parallèle les données d'état recherchées directement dans ledit moyen de stockage (RS), on vérifie que l'on n'active pas le contexte restauré deux fois de suite. 10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce que lesdites données d'état sont choisies dans un groupe comprenant des données, dites statiques, discriminantes d'un contexte d'appel impliquant un ensemble de participants, et des données, dites dynamiques, variables dans le temps. 11. Dispositif de récupération de données d'état définissant les états en cours d'applications utilisées dans des équipements (Si) d'un réseau de communication, caractérisé en ce qu'il comprend des moyens de traitement (MT) agencés, en cas de détection d'un problème survenu dans au moins un équipement (Si') dudit réseau, pour récupérer séquentiellement dans un moyen de stockage (RS) des données d'état relatives à chaque application utilisée par cet équipement (Si') et stockées en correspondance d'identifiants d'application associés à chaque contexte d'appel traité par chaque 17 2916924 application, et, en cas de réception d'un message relatif à une application utilisée par cet équipement (Si'), pour déterminer l'identifiant d'application désigné par ce message puis les données d'état correspondantes parmi lesdites données d'état récupérées et parmi les données d'état stockées dans 5 ledit moyen de stockage (RS) si elles n'ont pas encore été récupérées. 12. Dispositif selon la revendication 11, caractérisé en ce qu'il comprend des moyens de détection (MD) agencés pour générer des messages d'interrogation destinés auxdits équipements (Si), et en l'absence de réponse d'un équipement (Si') pour signaler auxdits moyens de traitement (MT) que 10 cet équipement (Si') fait l'objet d'un problème. 13. Dispositif selon l'une des revendications 11 et 12, caractérisé en ce qu'en cas de réception d'un message désignant un identifiant d'application, si les données d'état correspondant à cet identifiant d'application n'ont pas encore été récupérées séquentiellement, lesdits moyens de traitement (MT) 15 sont agencés pour poursuivre la récupération séquentielle pour les autres identifiants d'application et pour récupérer en parallèle les données d'état recherchées directement dans ledit moyen de stockage (RS). 14. Dispositif selon la revendication 13, caractérisé en ce que lesdits moyens de traitement (MT) sont agencés pour récupérer en parallèle les 20 données d'état recherchées directement dans ledit moyen de stockage (RS) après avoir verrouillé les données d'état, de manière à prévenir une restauration parallèle des données identifiées au moyen de l'identifiant d'application par la récupération séquentielle. 15. Dispositif selon la revendication 13, caractérisé en ce que lesdits 25 moyens de traitement (MT) sont agencés pour vérifier que l'on n'active pas le contexte restauré deux fois de suite, après avoir récupéré en parallèle les données d'état recherchées directement dans ledit moyen de stockage (RS). 16. Equipement (Si) pour un réseau de communication, caractérisé en ce qu'il comprend une partie au moins d'un dispositif de récupération de 30 données d'état (D) selon l'une des revendications 11 à 15.