Brevet FR2830150A1 — publié le 20030328

La présente invention concerne de façon générale des systèmes de télécommunication et, plus spécifiquement, un commutateur qui utilise un pare-feu réparti pour procurer un partage de charge du trafic en mode "voix sur IP" (VoIP) . Des fournisseurs de télécommunication tentent continuellement de créer de nouveaux marchés et de développer des marchés existants pour des services et des équipements de télécommunication. Une manière importante de réaliser ceci est d'améliorer les performances d'équipements de réseaux de télécommunication, tout en rendant les équipements moins coûteux et plus fiables. Ceci permet aux fournisseurs de télécommunication de réduire les coûts d'infrastructure et d'exploitation tout en maintenant ou même en augmentant la capacité de leurs réseaux. En même temps, les fournisseurs de services de télécommunication travaillent à améliorer la qualité de service et à augmenter la quantité de services disponibles pour l'utilisateur final. Un type de service de télécommunication qui est de plus en plus répandu est la voix sur IP (VoIP). La voix sur IP est une application qui permet à des utilisateurs d'acheminer du trafic vocal (par exemple des appels téléphoniques, des télécopies et d'autres données) sur un réseau fonctionnant selon le protocole Internet (IP pour "Internet Protocol"). Une application VoIP segmente en trames le trafic de signaux vocaux et stocke celles-ci dans des paquets vocaux. Les paquets vocaux sont transportés par le réseau en utilisant n'importe quel protocole multimédia (c'est-à-dire voix, vidéo, télécopie et données) classique. Les protocoles comprennent les suivants : H.323, IPDC, Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), Megaco, Session Description Protocol (SDP), et Skinny, entre autres. SIP et H.323 sont particulièrement importants pour des téléphones Internet. Session Initiation Protocol (SIP) est un protocole de signalisation de commande de couche d'application pour des formes de réalisation de VoIP utilisant un mode de réacheminement appelé Redirect Mode. SIP est un protocole de base client-serveur textuel qui fournit les mécanismes de protocole nécessaires pour que le système d'utilisateur final et les serveurs mandataires puissent fournir différents services, incluant le renvoi d'appel, l'identification du numéro demandé et demandeur, des invitations pour un mode de conférence en multidiffusion, et la répartition automatique d'appels (ACD pour "automatic call distribution") de base. Des adresses SIP (c'est-à-dire des URL) peuvent être incorporées dans des pages Web pour procurer un service simple "cliquer pour parler". H.323 est une norme de l'organisme International Telephone Union (ITU-T) qui comprend un ensemble de normes définissant des communications multimédias en temps réel pour des réseaux basés sur la transmission de paquets. H.323 définit un ensemble de spécifications de commande d'appel, d'établissement de canal et de codec pour transmettre de la voix et de la vidéo en temps réel sur des réseaux qui n'offrent pas un service ou une qualité de service garanti. Les réseaux peuvent inclure des réseaux de transmission de paquets, en particulier l'Internet, des réseaux locaux (ou LAN), des réseaux étendus (ou WAN), et des intranets. Les principaux avantages du mode VoIP sont des économies pour les raisons suivantes : 1) La voix et les données sont transmises sur une seule ligne jusqu'aux abonnés résidentiels, ou sur un seul réseau IP jusqu'aux entreprises; 2) La voix est transformée en paquets numériques et envoyée directement sur l'Internet, en contournant complètement les commutateurs de circuits ou les sociétés téléphoniques et leurs taxes ; 3) Les réseaux IP utilisent des commutateurs "logiciels" souples qui peuvent être mis à niveau beaucoup plus aisément par logiciel. Une passerelle de téléphonie sur IP prend beaucoup moins de place qu'un commutateur de circuits et a des exigences de puissance et de refroidissement considérablement inférieures. Les commutateurs logiciels de télécommunication emploient de façon caractéristique un noeud de traduction d'adresse de réseau (ou NAT pour "Network Address Translation")/ noeud pare-feu (ou FN pour "firewall node") pour protéger les opérations internes d'un commutateur logiciel. Le NAT/ Pare-feu remplit une fonction de traduction d'adresse de réseau qui fournit une adresse IP publique qui est exposée à des réseaux de paquets externes. La fonction de NAT traduit les adresses IP privées provenant du réseau interne en adresse publique et inversement. Les fonctions de pare-feu peuvent être de l'un de plusieurs types, incluant un filtre de paquets, une passerelle de circuits, une passerelle d'applications ou une passerelle de confiance. Un pare-feu classique est réalisé au moyen d'une combinaison d'hôtes et de routeurs. Un routeur peut commander le trafic au niveau des paquets, en admettant ou en refusant des paquets sur la base de l'adresse de source ou de destination du numéro de port. Cette technique est appelée filtrage de paquets. Un hôte peut commander le trafic au niveau application, en permettant une commande d'accès basée sur un examen du trafic plus détaillé et dépendant du protocole. Le processus qui examine et achemine du trafic de paquets est appelé un mandataire. Malheureusement, des systèmes de pare-feu classiques procurent ces possibilités sur la base d'une répartition de travail pré-assignée. Celle-ci est basée sur une répartition statique de la charge pour des appels provenant du réseau IP. En outre, des systèmes de pare-feu classiques sont limités lorsque le commutateur logiciel est redimensionné pour lui donner de plus grandes ou de plus petites tailles. Dans les procédés antérieurs, le redimensionnement a souvent occasionné un changement statique de configuration et exigé un arrêt de fonctionnement. Il existe donc un besoin portant sur des systèmes de pare-feu perfectionnés pour l'utilisation dans des systèmes de télécommunication. En particulier, il existe un besoin portant sur des systèmes de pare-feu qui puissent être redimensionnés aisément pour leur donner de plus grandes ou de plus petites tailles. Plus particulièrement, il existe un besoin portant sur des pare-feux de réseaux qui ne reposent pas sur une répartition statique de la charge de trafic pour des appels provenant du réseau IP. Pour répondre aux déficiences de l'art antérieur envisagées ci-dessus, un but principal de la présente invention est de procurer un commutateur capable de prendre en charge du trafic de voix sur IP (VoIP) entre des dispositifs appelants et des dispositifs appelés. Conformément à un mode de réalisation avantageux de la présente invention, le commutateur comprend : (1) une pluralité de noeuds d'applications d'appel capables d'exécuter des applications de serveur de processus d'appel, dans lesquelles une première application de serveur de processus d'appel est exécutée sur un premier de la pluralité de noeuds d'applications d'appel, et est associée à une seconde application de serveur de processus d'appel similaire, exécutée sur un second de la pluralité de noeuds d'applications d'appel séparé du premier noeud d'application d'appel, les première et seconde applications de serveur de processus d'appel formant ainsi une première application de serveur de groupe de partage de charge; et (2) une pluralité de noeuds de traduction d'adresse de réseau capables d'exécuter des applications de serveur de pare-feu, dans lesquelles une première application de serveur de pare-feu est exécutée sur un premier de la pluralité de noeuds de traduction d'adresse de réseau et est associée à une seconde application de serveur de parefeu similaire exécutée sur un second de la pluralité de noeuds de traduction d'adresse de réseau, séparé du premier noeud de traduction d'adresse de réseau, les première et seconde applications de serveur de pare-feu formant ainsi une seconde application de serveur de groupe de partage de charge, dans lequel le trafic VoIP associé à des appels VoIP est reçu par la seconde application de serveur de groupe de partage de charge et la seconde application de serveur de groupe de partage de charge sélectionne l'une des première et seconde applications de serveur de pare-feu pour vérifier que le trafic VoIP est autorisé à accéder à l'une au moins des applications de serveur de processus d'appel dans les noeuds d'applications d'appel, conformément à un algorithme de répartition de charge. Conformément à un mode de réalisation de la présente invention, l'algorithme de répartition de charge répartit le trafic VoIP d'une manière alternée entre les première et seconde applications de serveur de pare-feu. Conformément à un autre mode de réalisation de la présente invention, l'algorithme de répartition de charge répartit le trafic VoIP en fonction d'une charge de trafic présente de la première application de serveur de pare-feu et d'une charge de trafic présente de la seconde application de serveur de pare-feu. Conformément à encore un autre mode de réalisation de la présente invention, l'algorithme de répartition de charge répartit le trafic VoIP de manière à maintenir la charge de trafic présente de la première application de serveur de pare-feu à un niveau pratiquement égal à la charge de trafic présente de la seconde application de serveur de pare-feu. Conformément à encore un autre mode de réalisation de la présente invention, la première application de serveur de pare-feu comprend une première application de serveur de groupe primaire/réserve, la première application de serveur de groupe primaire/réserve comprenant un premier processus de pare-feu primaire exécuté sur le premier noeud de traduction d'adresse de réseau, et un premier processus de pare-feu de réserve associé au premier processus de pare-feu primaire. Conformément à un mode de réalisation supplémentaire de l'invention, l'information d'état associée au premier processus de pare-feu primaire est reproduite à l'identique dans le premier processus de pare-feu de réserve associé au premier processus de pare-feu primaire. Conformément à un autre mode de réalisation supplémentaire de la présente invention, le premier processus de pare-feu de réserve réside sur le premier noeud de traduction d'adresse de réseau. Conformément à encore un autre mode de réalisation supplémentaire de la présente invention, le premier processus de pare-feu de réserve réside sur un noeud de traduction d'adresse séparé du premier noeud de traduction d'adresse de réseau. Dans un mode de réalisation de la présente invention, la seconde application de serveur de pare-feu comprend une seconde applicateur de serveur de groupe primaire/réserve, la seconde application de serveur de groupe primaire/réserve comprenant un second processus de pare-feu primaire exécuté sur le second noeud de traduction d'adresse de réseau et un second processus de pare-feu de réserve associé au second processus de pare-feu primaire. Dans un autre mode de réalisation de la présente invention, l'information d'état associée au second processus de pare-feu primaire est reproduite à l'identique dans le second processus de pare-feu de réserve associé au second processus de pare-feu primaire. Dans encore un autre mode de réalisation de la présente invention, le second processus de pare-feu de réserve réside sur le second noeud de traduction d'adresse de réseau. Dans encore un autre mode de réalisation de la présente invention, le second processus de pare-feu de réserve réside sur un noeud d'application d'appel séparé du second noeud de traduction d'adresse de réseau. Ce qui précède a donné un aperçu assez général des caractéristiques et des avantages techniques de la présente invention, de façon que l'homme de l'art puisse mieux comprendre la description détaillée de l'invention qui suit. Des caractéristiques et avantages supplémentaires de l'invention qui forment le sujet des revendications seront décrits ci-après. L'homme de l'art appréciera qu'il peut aisément utiliser la conception et le mode de réalisation spécifique exposés, à titre de base pour modifier ou concevoir d'autres structures pour atteindre des buts identiques à ceux de la présente invention. L'homme de l'art notera également que de telles structures équivalentes ne sortent pas de l'esprit et du cadre de l'invention, dans sa forme la plus large. Avant d'entreprendre la description détaillée de l'invention ci-dessous, il peut être avantageux de donner des définitions de certains mots et expressions utilisés dans tout ce document de brevet : les termes "inclure" et "comprendre", ainsi que leurs dérivés, signifient l'inclusion sans limitation ; terme "ou" est inclusif et signifie et/ou; les expressions "associé à" et "associé avec", ainsi que leurs dérivés, peuvent signifier inclure, être inclus dans, interconnecter avec, contenir, être contenu dans, connecter à ou avec, coupler à ou avec, pouvoir communiquer avec, coopérer avec, entrelacer, juxtaposer, être proche de, être lié à ou avec, avoir, avoir une propriété de, etc.; et le terme "unité de commande" désigne n'importe quel dispositif, système ou partie de celui-ci qui commande au moins une opération, un tel dispositif pouvant être réalisé par matériel, microprogramme ou logiciel, ou une certaine combinaison d'au moins deux de ceux-ci. Il faut noter que la fonctionnalité associée à une unité de commande particulière quelconque peut être centralisée ou répartie, localement ou à distance. Des définitions pour certains mots et expressions sont données dans l'ensemble de ce document de brevet, et l'homme de l'art doit comprendre que dans de nombreux cas, sinon dans la plupart, de telles définitions s'appliquent à des utilisations antérieures, aussi bien que futures, de tels mots et expressions définis. D'autres caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description qui va suivre de modes de réalisation se référant aux dessins annexés, dans lesquels des numéros semblables désignent des éléments semblables, et dans lesquels : La figure 1 illustre un exemple de réseau de télécommunication capable de mettre en oeuvre des applications VoIP conformément à un mode de réalisation de la présente invention; La figure 2 illustre un exemple de réseau de télécommunication capable de mettre en oeuvre des applications VoIP conformément à un second mode de réalisation de la présente invention; et La figure 3 illustre des parties sélectionnées d'un exemple de commutateur logiciel dans le réseau de télécommunication, capable de remplir des fonctions de traduction d'adresse de réseau et des fonctions de pare-feu en relation avec des groupes de partage de charge en mode réparti, dans un mode de réalisation de la présente invention. Les figures 1 à 3, envisagées ci-dessous, et les divers modes de réalisation utilisés pour décrire les principes de la présente invention dans ce document de brevet sont présentés seulement à titre d'illustration et ne doivent pas être considérés comme limitant d'une manière quelconque le cadre de l'invention. L'homme de l'art comprendra que les principes de la présente invention peuvent être mis en oeuvre dans n'importe quel réseau de télécommunication organisé de façon appropriée. La figure 1 illustre un exemple de réseau de télécommunication 100 capable de mettre en oeuvre des applications VoIP conformément à un mode de réalisation de la présente invention. Le réseau de télécommunication 100 comprend un ou plusieurs commutateurs logiciels 105, un routeur 150, un réseau de paquets utilisant le protocole IP (Internet Protocol) 160, un ou plusieurs téléphones utilisant le protocole SIP ("Session Initiatioin Protocol") / H.323, 170, une passerelle de médias 176, un sous-système d'émetteur-récepteur de base (BTS) pour réseau sans fil (WN) 180 et un serveur de facturation 185. Le commutateur logiciel 105 comprend des noeuds d'applications de traitement d'appel (CAN pour "Call Processing Application Nodes") 115A, 115B et 115C (portant respectivement les désignations CAN1, CAN2 et CAN3), des noeuds de serveurs de communication (CSN pour "Communication Server Nodes") 120A et 120B (portant respectivement les désignations CSN1 et CSN2), des noeuds d'exploitation, d'administration, de maintenance et d'approvisionnement (OAMP pour "Opération Administration, Maintenance and Provisioning") 125A et 125B (portant respectivement les désignations OAMP1 et OAMP2), et des noeuds de traduction d'adresse de réseau (NAT pour "Network Address Translation") et de pare-feu 110A, 110B, 110C, 110D et 110E (portant respectivement les désignations NAT1, NAT2, NAT3, NAT4 et NAT5). CAN1-CAN3, CSN1 et CSN2, OAMP1 et OAMP2 et NAT1-NAT5 sont couplés par un réseau Ethernet interne 130, et communiquent sur ce dernier. Le commutateur logiciel 105 et d'autres commutateurs logiciels similaires (non représentés) fournissent des services de commutation et autres aux téléphones SIP/H. 323 170, à la passerelle de médias 175, au BTS de réseau sans fil 180 et au serveur de facturation 185. Ces services peuvent comprendre des applications de téléphone à téléphone, de téléphone à ordinateur personnel, de télécopieur à courrier électronique, de courrier électronique à télécopieur, de télécopieur à télécopieur, de centre d'appels, les réseaux privés virtuels, le téléphone sur IP, et autres. La passerelle de médias 175 convertit un média (c'est-à-dire voix, vidéo, audio, télécopie) fourni dans un type de réseau (c'est-à-dire le réseau téléphonique commuté public (RTCP)) au format exigé pour le réseau VoIP dans le commutateur 105. Par exemple, la passerelle de médias 175 peut constituer la terminaison pour des canaux porteurs provenant d'un réseau à commutation de circuits (par exemple SS7) et des transmissions de médias en continu provenant d'un réseau de paquets. Des téléphones SIP/H. 323 170 sont capables d'émettre des appels vers d'autres téléphones SIP/H. 323, et de recevoir des appels provenant de ces derniers, par l'intermédiaire du commutateur logiciel 105. De plus, des téléphones SIP/H. 323 170 sont capables d'émettre des appels et de recevoir des appels en relation avec des téléphones connectés au réseau téléphonique commuté public (RTCP) (non représenté) couplé à la passerelle de médias 175 par l'intermédiaire du commutateur logiciel 105. En outre, des téléphones SIP/H. 323 170 sont capables d'émettre des appels et de recevoir des appels en relation avec des téléphones sans fil et d'autres terminaux d'accès sans fil communiquant avec le BTS de réseau sans fil 180, par l'intermédiaire du commutateur logiciel 105. Des noeuds d'applications d'appel 115A, 115B et 115C (CAN1-CAN3) exécutent un certain nombre d'applications de serveur de processus d'appel (CP pour "Call Process") organisées comme des processus primaire et de réserve qui sont disponibles sous la forme de services de groupes répartis pour un ou plusieurs téléphones SIP/H. 323 170, la passerelle de médias 175, le sous-système d'émetteursrécepteurs de base de réseau sans fil 180 et le serveur de facturation 185. Les noeuds d'application d'appel sont des noeuds de calcul séparés comprenant un processeur et une mémoire qui procurent la possibilité de redimensionnement et la redondance par le simple ajout de noeuds d'application d'appels supplémentaires, jusqu'à un maximum de N noeuds. Chacun des processus d'appel exécutés sur CAN1-CAN3 prend en charge les signaux de commande et les messages émis ou reçus en relation avec les téléphones SIP/H.323 170, la passerelle de médias 175, le BTS de réseau sans fil 180 et le serveur de facturation 185. Chacun des éléments comprenant les téléphones SIP/H.323 170, la passerelle de médias 175, le BTS de réseau sans fil 180 et le serveur de facturation 185 établit une session avec un groupe de partage de charge, qui assigne chaque appel à l'une particulière des applications de serveur de processus d'appel de groupe primaire/réserve exécutées sur les noeuds CAN1-CAN3. L'application de serveur de processus d'appel sélectionnée accomplit réellement les services/fonctions de processus d'appel demandés par l'application de client de processus d'appel. De façon similaire, NAT1-NAT5 exécutent un certain nombre d'applications de traduction d'adresse de réseau et de pare-feu organisées comme des processus primaires et de réserve qui sont disponibles sous la forme de services de groupes répartis (c'est-à-dire de partage de charge) pour le ou les téléphones SIP/H. 323 170, la passerelle de médias 175, le sous-système d'émetteur-récepteur de base de réseau sans fil 180 et le serveur de facturation 185. Les noeuds de serveur de communication 120A et 120B (CSN1 et CSN2) constituent la terminaison de liaisons SS7 et prennent en charge les couches MTP 1-3. CSN1 et CSN2 peuvent également être organisés comme des processus primaires et de réserve qui sont disponibles comme des services de groupes répartis (c'est-à-dire de partage de charge). La figure 3 illustre des parties sélectionnées de l'exemple de commutateur logiciel 105 dans le réseau de télécommunication 100 capable d'accomplir des fonctions de traduction d'adresse de réseau et des fonctions de pare-feu sous la forme de groupes de partage de charge répartis utilisant des services de groupes conformément aux principes de la présente invention. Dans le mode de réalisation illustré, trois exemples d'applications de serveur de processus d'appel, c'est-à-dire CP1, CP2 et CP3, sont en cours d'exécution. Chacun de ces processus existe sous la forme d'un groupe primaire/réserve. Ainsi, CP1 existe sous la forme d'un processus primaire, CP1(P), et d'un processus de réserve, CP1(B). De façon similaire, CP2 existe sous la forme d'un processus primaire, CP2(P), et d'un processus de réserve, CP2(B), et CP3 existe sous la forme d'un processus primaire, CP3(P), et d'un processus de réserve CP3(B). Dans le mode de réalisation illustré, CP1(P) et CP1(B) résident sur des noeuds d'application d'appel différents (c'est-à-dire CAN1 et CAN2). Ceci n'est pas une exigence stricte : CP1(P) et CP1(B) peuvent résider sur le même noeud d'application d'appel (par exemple CAN1) et procurer néanmoins la fiabilité et la redondance pour des défauts de logiciel sur le processus primaire, CP1(P). Cependant, dans un mode de réalisation préféré de la présente invention, le processus primaire et le processus de réserve résident sur des noeuds d'application d'appels différents, pour procurer ainsi une redondance matérielle aussi bien qu'une redondance logicielle. Ainsi, CP1(P) et CP1(B) résident sur CAN1 et CAN2, CP2(P et CP2(B) résident sur CAN2 et CAN3 , et CP3 (P) et CP3 (B) résident sur CAN3 et CAN1. Ensemble, CP1, CP2 et CP3 forment un super-groupe pour le partage de charge. Par conséquent, CP1(P) et CP1(B), CP2(P) et CP2 (B) , et CP3(P) et CP3(B) font partie d'un premier groupe de partage de charge (LSG1), indiqué par la limite en pointillés. De façon similaire, cinq applications de serveur de processus de traduction d'adresse de réseau (NATP) prises à titre d'exemple, c'est-à-dire NATP1, NATP2, NATP3, NATP4 et NATP5, sont en cours d'exécution. Chacun de ces processus existe sous la forme d'un groupe primaire/réserve. Ainsi, NATP1 existe sous la forme d'un processus primaire, NATP1(P), et d'un processus de réserve, NATP1(B). De façon similaire, NATP2 existe sous la forme d'un processus primaire, NATP2 (P) , et d'un processus de réserve NATP2 (B) , NATP3 existe sous la forme d'un processus primaire, NATP3(P) et d'un processus de réserve, NATP3(B), NATP4 existe sous la forme d'un processus primaire, NATP4(P), et d'un processus de réserve, NATP4(B), et NATP5 existe sous la forme d'un processus primaire, NATP5(P), et d'un processus de réserve, NATP5(B). A nouveau, dans un mode de réalisation préféré de la présente invention, le processus NAT primaire et le processus NAT de réserve résident sur des noeuds de traduction d'adresse de réseau différents (c'est-à-dire NAT1-NAT5), ce qui procure une redondance matérielle en même temps qu'une redondance logicielle. NATP1(P) et NATP1(B) résident sur NAT1 et NAT2, NATP2(P) et NATP2(B) résident sur NAT2 et NAT3, NATP3(P) et NATP3(B) résident sur NAT3 et NAT4, NATP4(P) et NATP4(B) résident sur NAT4 et NAT5, et NATP5(P) et NATP5(B) résident sur NAT5 et NAT1. Ensemble, NATP1, NATP2, NATP3, NATP4 et NATP5 forment un super-groupe pour le partage de charge. Par conséquent, NATP1(P) et NATP1 (B) , NATP2 (P) et NATP2 (B) , NATP3 (P) et NATP3(B), NATP4(P) et NATP4(B) et NATP5(P) et NATP5(B) font partie d'un second groupe de partage de charge (LSG2), indiqué par la limite en pointillés. Enfin, quatre applications de serveur de processus de pare-feu (FWP) prises à titre d'exemples, c'est-à-dire FWP1, FWP2, FWP3, FWP4 et FWP5, sont en cours d'exécution. Chacun de ces processus existe sous la forme d'un groupe primaire/réserve. Ainsi, FWP1 existe sous la forme d'un processus primaire, FWP1(P), et d'un processus de réserve, FWP1(B). De façon similaire, FWP2 existe sous la forme d'un processus primaire, FWP2(P), et d'un processus de réserve FWP2(B), FWP3 existe sous la forme d'un processus primaire, FWP3 (P) et d'un processus de réserve, FWP3 (B) , FWP4 existe sous la forme d'un processus primaire, FWP4(P), et d'un processus de réserve, FWP4(B), et FWP5 existe sous la forme d'un processus primaire, FWP5(P), et d'un processus de réserve, FWP5(B). FWP1 (P) et FWP1(B) résident sur NAT1 et NAT2, FWP2(P) et FWP2(B) résident sur NAT2 et NAT3, FWP3(P) et FWP3(B) résident sur NAT3 et NAT4, FWP4(P) et FWP4(B) résident sur NAT4 et NAT5, et FWP5(P) et FWP5(B) résident sur NAT5 et NAT1. Ensemble, FWP1, FWP2, FWP3, FWP4 et FWP5 forment un super-groupe pour le partage de charge. Par conséquent, FWP1(P) et FWP1(B), FWP2 (P) et FWP2 (B) , FWP3(P) et FWP3(B), FWP4(P) et FWP4(B) et FWP5(P) et FWP5(B) font partie d'un troisième groupe de partage de charge (LSG3), comme indiqué par la limite en pointillés. Un service de groupe procure un canevas pour organiser un groupe d'objets logiciels répartis dans un réseau de calcul. Chaque objet logiciel procure un service (par exemple une traduction d'adresse de réseau ou une protection par pare-feu). De plus, le canevas de service de groupe procure un comportement amélioré pour déterminer l'appartenance au groupe, décider quelles actions il faut entreprendre en présence de défauts, commander des communications en monodiffusion, multidiffusion et diffusion de groupe entre des membres et des clients pour le groupe. Un groupe utilise une politique pour améliorer le comportement des services fournis par le groupe. Certaines de ces politiques comprennent une configuration primaire/réserve pour une haute disponibilité de service et le partage de charge pour répartir la charge de service à l'intérieur d'un réseau. Des applications de serveur, telles que CP1-CP3, NATP1-NATP5 et FWP1-FWP5, fournissent des services qui sont appelés par des applications de client, telles que les téléphones SIP/H. 323 (170), la passerelle de médias 175, le BTS de réseau sans fil 180 et le serveur de facturation 185. Comme représenté sur la figure 3, les applications de serveur sont organisées en groupes primaire/réserve, configurés comme un groupe primaire/réserve du type 1+1. Il y a de multiples nombres de ces groupes primaire/réserve et le nombre exact peut être changé conformément au nombre de processus et/ou de noeuds de calcul (CAN) et de noeuds de traduction d'adresse de réseau (NAT1-NAT5) qui sont utilisés. Tous les groupes primaire/réserve sont eux-mêmes un membre d'un seul groupe de partage de charge (par exemple LSG1, LSG2, LSG3). Il est important de noter qu'alors que les applications de client, telles que les téléphones SIP/H.323 (170) et la passerelle de médias 175, sont des clients vis- à-vis des applications de serveur, CP1-CP3, NATP1-NATP5 et FWP1-FWP5, une application de serveur peut être un client vis-à-vis d'une autre application de serveur. En particulier, les applications de serveur de processus d'appel CP1-CP3 peuvent être des clients vis-à-vis des applications de serveur de traduction d'adresse de réseau NATP1-NATP5, et des applications de serveur de pare-feu, FWP1-FWP5. Une application de client établit une interface avec le groupe de partage de charge. Lorsqu'une indication de nouvel appel est reçue par l'application de client, l'application de client établit une session avec le groupe de partage de charge conformément à une politique de partage de charge du côté du client. La politique initiale est la répartition à tour de rôle (c'est-à-dire la répartition de nouveaux appels provenant du routeur 160 en ordre séquentiel à chacun des noeuds NATl-NAT5), mais on peut utiliser d'autres politiques qui tiennent compte de la charge réelle des différents groupes du type primaire/réserve. L'application de client associe la session au nouvel appel et envoie des messages associés à l'appel sur l'objet de session. L'application de client reçoit également des messages provenant du groupe primaire/réserve par l'intermédiaire de la session établie avec le groupe primaire/réserve. Seul le processus primaire (par exemple NATP1 (P)) du groupe primaire/réserve se joint au groupe de partage de charge (par exemple LSG2). Pour une variété de raisons, l'application contenant le processus primaire peut être retirée du service. L'application de serveur peut choisir de ne pas accepter de nouveaux appels en quittant le groupe de partage de charge. Cependant, les applications de client peuvent encore maintenir leur session avec le groupe primaire/réserve pour des appels existants. Cette action est accomplie du fait que du nouveau trafic d'appel peut être perdu si le processus primaire isolé manifeste également un défaut. De nouveaux appels ne sont pas distribués au groupe primaire/réserve s'il quitte le groupe de partage de charge. Si le processus primaire du groupe primaire/réserve qui est un membre du groupe de partage de charge devient défectueux, le membre de réserve est informé du fait que le membre primaire est devenu défectueux (ou est parti) et il prend alors le rôle du membre primaire. La responsabilité de ces actions doit être endossée par l'applicateur de serveur. Il est de la responsabilité du Service de Groupe d'informer le membre de réserve du fait que le membre primaire est devenu défectueux ou est parti. La figure 1 montre l'architecture de partage de charge pour des appels provenant du réseau de paquets IP 160, ou provenant par exemple d'un réseau SS7 connecté à la passerelle de médias 175. Des appels provenant du réseau de paquets IP 160 sont des appels de SIP/H. 323 et des appels provenant de la passerelle de médias 175 peuvent être des messages de notification MEGACO/MGCP. On notera que CAN1CAN3, CSN1 et CSN2, OAMP1 et OAMP2 et NAT1-NAT5 ont tous des adresses internes spécifiques sur le réseau Ethernet interne 130. OAMP1 et OAMP2 ont respectivement des adresses IP internes 10. 1.1.1 et 10.1.1.2. CAN1-CAN3 ont respectivement des adresses IP internes 10. 1.1.3, 10.1.1.4 et 10.1.1.5. CSN1 et CSN2 ont respectivement des adresses IP internes 10. 1.1.6 et 10. 1.1.7. Enfin, NAT1-NAT5 ont respectivement des adresses IP internes 10.1.1.50, 10. 1.1.51, 10. 1.1.52, 10. 1.1.53, 10. 1.1.54. De plus, chacun de NAT1-NAT5 a une adresse IP externe qui est vue par le routeur 150. NAT1-NAT5 ont respectivement des adresses IP externes 123.62.8.1, 123.62.8.2, 123.62.8.3, 123.62.8.4, et 123.62.8.5. Les applications de serveur NAT (NATP1-NATP5) dans NAT1-NAT5 procurent des fonctions de traduction d'adresse de réseau (NAT) et de partage de charge pour tous les protocoles liés à des appels IP qui sont pris en charge par le commutateur logiciel 105, comme MGCP, SIP, H323, MEGACO. Les fonctions de traduction d'adresse de réseau fournissent des adresses IP publiques qui sont exposées au réseau de paquets IP externe 160 et elles effectuent la traduction des adresses IP internes provenant du réseau Ethernet 130vers l'adresse publique, et inversement. Les applications de serveur de pare-feu (FWP1-FWP2) dans NAT1-NAT5 commandent l'accès au commutateur logiciel 105 pour des protocoles tels que TCP, UDP, FTP, HTTP, Telnet, et autres. Mécanisme de Répartition d'Appels IP 1) Appels de paquets - Les noeuds NAT/pare-feu procurent une adresse IP publique utilisée par des dispositifs externes pour adresser le commutateur logiciel 105. 2) Appels SIP - Toute la messagerie SIP est adressée aux adresses IP externes de NAT1-NAT5. Dans le NAT, il existe une application de mandataire de SIP mince. Le but du mandataire mince est de cacher la structure IP interne du commutateur logiciel 105 et de parvenir à une répartition de charge efficace parmi les CAN traitant des appels. Lorsqu'un message d'Invite est reçu au NAT sur le port 5060, la pile de SIP sur le NAT transmet le message au mandataire de SIP mince. La tâche du mandataire de SIP sur chacun des NAT1NAT5 est d'utiliser des services de groupe pour créer un identificateur (ID) de session corrélé à l'identificateur d'appel reçu par le message d'Invite. L'identificateur de session est un marqueur interne qui identifie sans ambiguïté un appel à l'intérieur du commutateur logiciel 105. Il permet au mandataire de diriger des messages concernant l'appel vers le processus principal dans l'un des CAN1-CAN3 traitant l'appel, en obtenant l'identificateur de session. En utilisant le gestionnaire d'interface, le mandataire de SIP peut ensuite relayer le message vers le processus d'appel principal sous la forme d'un message de SIP encapsulé dans une enveloppe de DTN. Des réponses au message de SIP sont renvoyées vers le mandataire dans le NAT qui a émis initialement le message, de façon que l'adresse IP externe puisse être présentée dans la réponse sortante. Tous les messages d'Invite provenant du commutateur logiciel 105 traversent le mandataire mince de façon à cacher l'information d'adressage interne. Les mandataires minces sur le noeud de pare-feu font également partie d'un groupe de partage de charge, de façon que lorsque le processus primaire émetteur envoie le message d'Invite, il consulte tout d'abord le client de partage de charge pour savoir quel mandataire a la capacité de prendre en charge l'appel sortant. Le mandataire effectue le remplacement d'adresse nécessaire dans le message sortant et achemine le message vers la destination. Le même mandataire peut ensuite prendre en charge tous les messages entrants. 3) Appels H.323 - Similaires à des appels SIP, les appels H.323 sont adressés à NAT1-NAT5 à partir des clients externes. Le client H.323 dans le commutateur logiciel 105 fait connaître seulement un nombre fixé de ports sur lesquels il recevra des messages Q.931, et un autre ensemble de ports sur lesquels il recevra les messages H.245. Le fournisseur de service établit les ports H.323 au moment de l'abonnement. Les ports peuvent être établis dans un contrôleur d'accès, si on en utilise un, ou par défaut pour chaque abonné. Chaque processus d'appel dans un groupe de partage de charge pour la norme H.323 supporte un sousensemble prédéterminé des ports sur lesquels il reçoit des messages H.245. Lorsqu'un message ETABLISSEMENT arrive à un noeud NAT, le mandataire mince H.323 détermine l'emplacement du membre de groupe primaire pour prendre en charge l'appel, après le LSC qui a déterminé la disponibilité des groupes de CP. La transaction est référencée par le numéro de référence d'appel dans les messages Q.931. Les messages suivants dirigés vers le groupe sont déterminés par la valeur de référence d'appel (CRV pour "call référence value"). Une fois que l'appel a établi l'appel Q.931, le groupe utilise l'un de ses ports H.245 prédéterminés pour ouvrir le canal logique vers le client externe. Le mandataire mince achemine ce message en utilisant l'adresse IP externe. Des messages H.245 suivants sur ce port sont acheminés vers le processus d'appel qui traite cet appel. 4) Messagerie MGCP - MGCP suit une stratégie similaire à celle des appels sortants SIP. Lorsqu'un message de notification est reçu à partir de la passerelle de médias 175, le message peut être dirigé vers n'importe lequel des processus du type primaire/réserve disponibles. Le processus primaire peut ensuite produire le CRCX et l'envoyer au mandataire disponible d'une manière similaire à celle décrite dans la section de SIP. La corrélation de l'identificateur de session dans ce cas est effectuée avec le numéro de connexion et la combinaison point d'extrémité / MG. Sur une réponse retournant de la passerelle de médias 175, le message est dirigé vers le groupe primaire/réserve qui commande le point d'extrémité. Des messages Notification suivants quelconques pour un point d'extrémité qui est déjà en utilisation, font tout d'abord l'objet d'une répartition de charge vers les processus de type primaire/réserve, et s'il est déterminé qu'il est en cours d'utilisation, le message Notification est dirigé vers le groupe primaire/réserve qui commande ce point d'extrémité. Conformément à un exemple de mode de réalisation de la présente invention, un nom de domaine pour le commutateur logiciel 105 est publié pour chacun des types de traitement d'appel. Par exemple, les traitements d'appel SIP, MGCP et H.323 peuvent être adressés respectivement par "sip.nomdedomaine. com" et "mgcp.nomdedomaine.com" et "h323.nomdedomaine.com". Un serveur de DNS résout ces noms en adresses IP et procure une répartition de charge primitive, normalement à tour de rôle. Une variante à l'utilisation du nom de domaine consisterait à publier une seule adresse IP du routeur 150, qui se trouve entre les NAT/pare-feu et le réseau de paquets IP externe 160. Le routeur 160 est alors configuré pour répartir les messages à tour de rôle entre les NAT1-NAT5. Les processus de mandataire de pare-feu et de NAT sur les NAT1-NAT5 fonctionnent comme un groupe de partage de charge. Les processus de CP, pour des segments sortants d'un appel, utilisent un client de partage de charge pour déterminer vers quel pare-feu il faut aller. Si le pare-feu reçoit un message provenant du réseau externe et ne peut pas le corréler à un identificateur de session quelconque dans son client de partage de charge, il utilise alors la possibilité de multidiffusion à partir du DTN pour effectuer une multidiffusion vers le reste des pare-feux. Le pare-feu qui a pris en charge cet appel traite ensuite ce message. Si aucun pare-feu n'est au courant de l'appel, le message est abandonné. La figure 1 montre la connexion du commutateur logiciel 105, dont le nom de domaine est publié, vers un réseau IP natif. Au moment de l'adressage avec le nom de domaine par des entités externes, comme des téléphones SIP, des passerelles de médias, et autres, le nom de domaine est traduit en une adresse IP externe enregistrée par les NAT/pare-feu (c'est-à-dire NAT1-NAT5). L'équilibrage des charges pour les NAT1-NAT5 est effectué au serveur DNS en utilisant un algorithme de répartition à tour de rôle. Le nombre de NAT exigés peut être changé en fonction des charges de trafic de messages prévues. La figure 2 illustre un exemple de réseau de télécommunication 200 capable de mettre en oeuvre des applications de VoIP conformément à un second mode de réalisation de la présente invention. Le réseau de télécommunication 200 est similaire au réseau de télécommunication 100sur la plupart des points. Cependant, la figure 2 montre la connexion du commutateur logiciel 101, dont le nom de domaine est publié, au réseau de paquets IP externe 160 sur un réseau à mode de transfert asynchrone (ATM) 255. Le routeur avec la possibilité de DNS est le point de sortie du réseau ATM 255 où l'information IP est acheminée sur la couche d'Adaptation ATM de type 5 (AAL5). Dans cette représentation, les NAT/ pare-feu ont seulement des connexions IP. Au moment de l'adressage avec un nom de domaine par des entités externes telles que des téléphones SIP, des passerelles de médias, et autres, le nom de domaine est traduit en une adresse IP externe enregistrée par les NAT/pare-feu. L'équilibrage de la charge vers les NAT1-NAT5 est effectué au serveur DNS en utilisant un algorithme de répartition à tour de rôle. Le nombre de NAT exigés peut être changé en fonction des charges de trafic de messages prévues. Dans d'autres modes de réalisation de la présente invention, NAT1-NAT5 peuvent être directement connectés au réseau ATM 255. Le service de DNS est effectué soit au point d'entrée, soit quelque part à l'intérieur du réseau ATM 255. Détails du mandataire d'application SIP Caractéristiques d'architecture de base : 1) Le routeur 150 est adressé comme un nom de domaine du commutateur logiciel 105 et une adresse IP qui sera considérée comme étant l'adresse IP du commutateur logiciel 105. 2) La maintenance et la configuration du routeur 150 sont effectuées séparément des fonctions OAMP du commutateur logiciel 105. 3) Le routeur 150 peut employer d'autres procédés de répartition de charge, en plus de la répartition à tour de rôle. L'algorithme de partage (ou de répartition) de charge peut être configuré par l'intermédiaire de l'interface de maintenance du routeur 150. 4) Chacun des NAT1-NAT5 contient un processus de mandataire qui est capable de regarder dans un message SIP et d'extraire de celui-ci un identificateur d'appel. 5) Le processus de mandataire sur NAT1-NAT5 est exécuté comme un groupe primaire/réserve, avec la réserve sur un autre noeud. 6) NAT1-NAT5 utilisent l'identificateur d'appel sur les messages INVITE entrants pour créer un identificateur de session et associer cette session à un groupe de processus du type processus d'appel (CP) primaire/réserve, choisi par l'intermédiaire d'un algorithme de répartition. 7) Tout message SIP reçu à partir du réseau de paquets IP externe 160 aux NAT1-NAT5 est extrait du transport IP et est reconditionné dans le transport DTN pour être relayé vers l'application de serveur de processus d'appel primaire/réserve. 8) Le processus primaire de CP utilise une pile interne pour décoder le message SIP. 9) Le processus primaire de CP formate les messages Invite SIP sortants et utilise un LSG pour choisir par lequel des NAT1-NAT5 les messages doivent être envoyés. 10) Le processus primaire de CP relaie tous les messages SIP sortants vers le noeud approprié parmi NAT1- NAT5, en utilisant un transport de Services de Groupe. 11) NAT1-NAT5 peuvent manipuler l'information d'entête pour pointer vers eux-mêmes pour le point d'extrémité, avant d'envoyer le message à l'extérieur vers le réseau de paquets IP externe 160. 12) Tous les groupes de partage de charge (LSG) qui sont exécutés dans CAN1-CAN3 et NAT1-NAT5 reçoivent une notification lorsque les processus de type primaire/réserve appropriés entrent dans les groupes de partage de charge respectifs ou sortent de ceux-ci. 13) Le LSG supprime les sessions une fois que l'appel s'est terminé, de façon normale ou anormale. Manipulation d'adresse IP au Pare-feu Lorsqu'un message SIP INVITE est reçu à partir du réseau externe, il ajoute le champ d'en-tête de contact aux réponses qu'il envoie en retour, et lorsqu'il envoie un message INVITE, il ajoute également un champ d'en-tête de contact au message, ainsi que l'acquittement ACK à la réponse finale. Il ajoute également un champ VIA pour indiquer sa propre adresse IP, en plus du nom de domaine du commutateur logiciel 105. Lorsqu'un message de requête est reçu à l'un des NAT1-NAT5, l'application de serveur de pare-feu trouve le groupe primaire/réserve disponible qui est capable de traiter les messages, et achemine le message vers ce groupe primaire/réserve par l'intermédiaire des Services de Groupe. Dans la réponse, chacun des NAT1-NAT5 ajoute son adresse IP au champ VIA et à l'En-tête de Contact. Pour des requêtes sortantes, le groupe primaire/ réserve sélectionne l'un des NAT1-NAT5 qui doit être la destination, sur la base du client de partage de charge mandataire, et il envoie la requête à ce noeud dans un message de Services de Groupe. Chacun des NAT1-NAT5 ajoute ensuite son adresse IP aux champs VIA et d'En-tête de Contact, de façon que toutes les réponses puissent être dirigées en retour vers le noeud correct parmi NAT1-NAT5. Défaillance Primaire/Réserve du Mandataire au Pare-feu Comme noté ci-dessus, chaque processus de mandataire fonctionne comme un groupe primaire/réserve. Le processus de réserve doit toujours fonctionner dans un processeur qui n'exécute pas son propre processus primaire. Bien qu'une double défaillance de processeur soit possible, elle est hautement improbable et dans le cas où elle se produit elle indiquerait un problème dans le réseau plus important que celui qui pourrait être résolu par une technique de redondance. Par conséquent, dans le cas d'une double défaillance de mandataire, le pare-feu qui reçoit les messages provenant du réseau effectuera une multidiffusion du message vers tous les CAN. De façon similaire, si le CAN détecte une double défaillance du mandataire de pare-feu, il établira à nouveau un identificateur de session pour l'un des autres groupes primaire/réserve et il continuera son traitement. Il peut devoir envoyer à nouveau certains des messages. Pour des messages sortants, dirigés du CAN vers le réseau externe, sous l'effet d'une défaillance de mandataire primaire les messages seront dirigés de façon à passer par le processus en réserve. Le processus en réserve effectuera la manipulation d'en-tête SIP comme décrit cidessus. Pour des messages entrants, une défaillance du processus de mandataire primaire conduira le processus de réserve à envoyer un message à toutes les sessions dans le LSG pour envoyer à nouveau tous les messages pour lesquels le processus de CP attend une réponse. Ceci permet au processus de réserve de manipuler l'information d'en-tête et d'envoyer à nouveau le message vers l'extrémité éloignée. Selon une variante, si une défaillance de processeur se produit dans l'un des NAT1-NAT5, le routeur externe peut être informé pour dévier le trafic vers l'adresse IP suivante sur la liste. Lorsqu'un message arrive à ce NAT, s'il ne trouve pas une association entre l'identificateur d'appel et les sessions dans la table LSC, il effectuera une multidiffusion du message vers le reste des mandataires sur le reste des NAT, et le processus primaire qui connaît l'identificateur de session prend en charge le message. Une fois que le processus primaire s'est arrêté et que la commande est transmise à un processus de réserve dans un autre processeur qui accueille déjà un processus primaire, le processus de réserve se fera sortir du groupe de partage de charge pour recevoir de nouveaux appels et il se chargera seulement des appels qu'il est en train de traiter, avant de passer dans un état dormant ou de sortir. Une fois qu'un nouveau mandataire de processus primaire est rétabli comme un seul processus sur un NAT, il peut ensuite rejoindre le groupe pour recevoir des appels. Défaillance Primaire/Réserve des Processus CP au CAN Tous les processus CP dans les CAN fonctionnent comme une partie d'une paire primaire/réserve et également une partie du groupe de partage de charge. Lorsqu'un processus primaire meurt, son processus de réserve devient le primaire. Les Services de Groupe dévient tous les messages destinés à cette paire primaire/réserve vers le nouveau primaire (ancien processus en réserve). Par conséquent, dans le mandataire de pare-feu / NAT, tous les messages concernant une session pour un groupe primaire/réserve particulier sont dirigés vers le processus correct. Ajout/Retrait de CAN/NAT sur la même Charge Comme décrit ci-dessus, chaque fois qu'un nouveau CAN est ajouté au commutateur logiciel 105 et le processus de traitement d'appel est commencé sur ce CAN, le processus primaire de traitement d'appel se joint au groupe de partage de charge de traitement d'appel. Chaque client de partage de charge est informé de l'ajout au groupe de partage de charge, et il ajuste de façon correspondante son algorithme de répartition de charge pour inclure le nouveau processus. Ceci pourrait occasionner un déséquilibre initial dans la répartition si une configuration de tour de rôle est employée. Cependant, cette condition sera temporaire du fait que des appels disparaissent et de nouveaux appels arrivent. Il va de soi que de nombreuses modifications peuvent être apportées au dispositif et au procédé décrits et représentés, sans sortir du cadre de l'invention. REVENDICATIONS 1. Commutateur (105) capable de prendre en charge du trafic de voix sur IP (VoIP) entre des dispositifs appelants et des dispositifs appelés, ce commutateur étant caractérisé en ce qu'il comprend : une pluralité de noeuds d'applications d'appel (115A-115C) capables d'exécuter des applications de serveur de processus d'appel, dans lesquels une première application de serveur de processus d'appel est exécutée sur un premier de ladite pluralité de noeuds d'applications d'appel (115A-115C) et est associée à une seconde application de serveur de processus d'appel similaire exécutée sur un second de ladite pluralité de noeuds d'applications d'appel (115A-115C) séparé dudit premier noeud d'application d'appel, lesdites première et seconde applications de serveur de processus d'appel formant ainsi une première application de serveur de groupe de partage de charge; et une pluralité de noeuds de traduction d'adresses de réseau (110A-110E) capables d'exécuter des applications de serveur de pare-feu, dans lesquels une première application de serveur de pare-feu est exécutée sur un premier de ladite pluralité de noeuds de traduction d'adresses de réseau (110A-110E) et est associée à une seconde application de serveur de pare-feu similaire, exécutée sur un second de ladite pluralité de noeuds de traduction d'adresses de réseau (110A-110E) séparé dudit premier noeud de traduction d'adresses de réseau, lesdites première et seconde applications de serveur de pare-feu formant ainsi une seconde application de serveur de groupe de partage de charge, dans lequel le trafic de VoIP associé à des appels de VoIP est reçu par ladite seconde application de serveur de groupe de partage de charge, et ladite seconde application de serveur de groupe de partage de charge sélectionne l'une desdites première et seconde applications de serveur de pare-feu pour vérifier que le trafic de VoIP est autorisé à accéder à l'une au moins desdites applications de serveur de processus d'appel dans les noeuds d'applications d'appel (115A-115C), conformément à un algorithme de répartition de charge. 2. Commutateur (105) selon la revendication 1, caractérisé en ce que ledit algorithme de répartition de charge répartit ledit trafic de VoIP d'une manière alternée entre lesdites première et seconde applications de serveur de pare-feu. 3. Commutateur (105) selon la revendication 1, caractérisé en ce que ledit algorithme de répartition de charge répartit le trafic de VoIP conformément à une charge de trafic présente de ladite première application de serveur de pare-feu et une charge de trafic présente de ladite seconde application de serveur de pare-feu. 4. Commutateur (105) selon la revendication 3, caractérisé en ce que ledit algorithme de répartition de charge répartit ledit trafic de VoIP de façon à maintenir ladite charge de trafic présente de ladite première application de serveur de pare-feu à un niveau pratiquement égal à ladite charge de trafic présente de ladite seconde application de serveur de pare-feu. 5. Commutateur (105) selon la revendication 1, caractérisé en ce que ladite première application de serveur de pare-feu comprend une première application de serveur de groupe primaire/réserve, et ladite première application de serveur de groupe primaire/réserve comprend un premier processus de pare-feu primaire exécuté sur ledit premier noeud de traduction d'adresses de réseau (110A- 110E), et un premier processus de pare-feu de réserve associé audit premier processus de pare-feu primaire. 6. Commutateur (105) selon la revendication 5, caractérisé en ce qu'une information d'état associée audit premier processus de pare-feu primaire est reproduite à l'identique dans ledit premier processus de pare-feu de réserve associé audit premier processus de pare-feu primaire. 7. Commutateur (105) selon la revendication 6, caractérisé en ce que ledit premier processus de pare-feu de réserve réside sur ledit premier noeud de traduction d'adresses de réseau (110A-110E). 8.Commutateur (105) selon la revendication 6, caractérisé en ce que le premier processus de pare-feu de réserve réside sur un noeud de traduction d'adresses de réseau (110A-110E) séparé dudit premier noeud de traduction d'adresses de réseau. 9. Commutateur (105) selon la revendication 1, caractérisé en ce que ladite seconde application de serveur de pare-feu comprend une seconde application de serveur de groupe primaire/réserve, et ladite seconde application de serveur de groupe primaire/réserve comprend un second processus de pare-feu primaire exécuté sur ledit second noeud de traduction d'adresses de réseau (110A-110E), et un second processus de pare-feu de réserve associé audit second processus de pare-feu primaire. 10. Commutateur (105) selon la revendication 9, caractérisé en ce qu'une information d'état associée audit second processus de pare-feu primaire est reproduite à l'identique dans ledit second processus de pare-feu de réserve associé audit second processus de pare-feu primaire. 11. Commutateur (105) selon la revendication 10, caractérisé en ce que ledit second processus de pare-feu de réserve réside sur ledit second noeud de traduction d'adresses de réseau (110A-110E). 12. Commutateur (105) selon la revendication 10, caractérisé en ce que ledit second processus de pare-feu de réserve réside sur un noeud d'application d'appel (115A- 115C) séparé dudit second noeud de traduction d'adresses de réseau (110A-110E). 13. Réseau de télécommunication, caractérisé en ce qu'il comprend : une pluralité de commutateurs (105) capable de prendre en charge du trafic de voix sur IP (VoIP) entre des dispositifs appelants et des dispositifs appelés, chacun de cette pluralité de commutateurs (105) comprenant : une pluralité de noeuds d'applications d'appel (115A-115C) capables d'exécuter des applications de serveur de processus d'appel, dans lesquels une première application de serveur de processus d'appel est exécutée sur un premier de ladite pluralité de noeuds d'applications d'appel (115A-115C) et est associée à une seconde application de serveur de processus d'appel similaire exécutée sur un second de ladite pluralité de noeuds d'applications d'appel (115A-115C) séparé du premier noeud d'application d'appel, lesdites première et seconde applications de serveur de processus d'appel formant ainsi une première application de serveur de groupe de partage de charge ; une pluralité de noeuds de traduction d'adresses de réseau (110A-110E) capables d'exécuter des applications de serveur de pare-feu, dans lesquels une première application de serveur de pare-feu est exécutée sur un premier de ladite pluralité de noeuds de traduction d'adresses de réseau (110A-110E) et est associée à une seconde application de serveur de pare-feu similaire, exécutée sur un second de ladite pluralité de noeuds de traduction d'adresses de réseau (110A-110E) séparé dudit premier noeud de traduction d'adresses de réseau, lesdites première et seconde applications de serveur de pare-feu formant ainsi une seconde application de serveur de groupe de partage de charge, dans lequel le trafic de VoIP associé à des appels de VoIP est reçu par ladite seconde application de serveur de groupe de partage de charge, et ladite seconde application de serveur de groupe de partage de charge sélectionne l'une desdites première et seconde applications de serveur de pare-feu pour vérifier que ledit trafic de VoIP est autorisé à accéder à l'une au moins desdites applications de serveur de processus d'appel dans les noeuds d'applications d'appel (115A-115C), conformément à un algorithme de répartition de charge ; un réseau de paquets (160) utilisant le protocole Internet (IP) pour interconnecter ladite pluralité de commutateurs (105); et au moins une passerelle de médias (175) couplée au réseau de paquets IP (160). 14. Réseau de télécommunication selon la revendication 13, caractérisé en ce que ledit algorithme de répartition de charge répartit ledit trafic de VoIP d'une manière alternée entre les première et seconde applications de serveur de pare-feu. 15. Réseau de télécommunication selon la revendication 13, caractérisé en ce que ledit algorithme de répartition de charge répartit ledit trafic de VoIP conformément à une charge de trafic présente de ladite première application de serveur de pare-feu et une charge de trafic présente de ladite seconde application de serveur de pare-feu. 16. Réseau de télécommunication selon la revendication 15, caractérisé en ce que ledit algorithme de répartition de charge répartit ledit trafic de VoIP de façon à maintenir ladite charge de trafic présente de ladite première application de serveur de pare-feu à un niveau pratiquement égal à ladite charge de trafic présente de ladite seconde application de serveur de pare-feu. 17. Réseau de télécommunication selon la revendication 13, caractérisé en ce que ladite première application de serveur de pare-feu comprend une première application de serveur de groupe primaire/réserve, et ladite première application de serveur de groupe primaire/réserve comprend un premier processus de pare-feu primaire exécuté sur ledit premier noeud de traduction d'adresses de réseau (110A-110E), et un premier processus de pare-feu de réserve associé audit premier processus de pare-feu primaire. 18. Réseau de télécommunication selon la revendication 17, caractérisé en ce qu'une information d'état associée audit premier processus de pare-feu primaire est reproduite à l'identique dans ledit premier processus de pare-feu de réserve associé audit premier processus de pare-feu primaire. 19. Réseau de télécommunication selon la revendication 18, caractérisé en ce que ledit premier processus de pare-feu de réserve réside sur ledit premier noeud de traduction d'adresses de réseau (110A-110E). 20. Réseau de télécommunication selon la revendication 18, caractérisé en ce que ledit premier processus de pare-feu de réserve réside sur un noeud de traduction d'adresses de réseau (110A-110E) séparé dudit premier noeud de traduction d'adresses de réseau. 21. Réseau de télécommunication selon la revendication 13, caractérisé en ce que ladite seconde application de serveur de pare-feu comprend une seconde application de serveur de groupe primaire/réserve, et ladite seconde application de serveur de groupe primaire/réserve comprend un second processus de pare-feu primaire exécuté sur ledit second noeud de traduction d'adresses de réseau (110A-110E), et un second processus de pare-feu de réserve associé audit second processus de parefeu primaire. 22. Réseau de télécommunication selon la revendication 21, caractérisé en ce qu'une information d'état associée audit second processus de pare-feu primaire est reproduite à l'identique dans ledit second processus de pare-feu de réserve associé au second processus de pare-feu primaire. 23. Réseau de télécommunication selon la revendication 22, caractérisé en ce que ledit second processus de pare-feu de réserve réside sur ledit second noeud de traduction d'adresses de réseau (110A-110E). 24. Réseau de télécommunication selon la revendication 22, caractérisé en ce que ledit second processus de pare-feu de réserve réside sur un noeud d'application d'appel (115A-115C) séparé dudit second noeud de traduction d'adresses de réseau (110A-110E).