Brevet FR3157756A1 — publié le 20250627

Procédé de gestion de l’attribution à un serveur de traitement de requêtes de téléphonie sur IP L’invention se rapporte à un procédé de gestion par une entité de gestion de l’attribution à un serveur de traitement, appartenant à un groupe de serveurs, de requêtes de téléphonie sur IP, dites requêtes à traiter, appartenant à une même session de téléphonie sur IP, caractérisé en ce qu’au cours de la session de téléphonie IP, une réception d’une requête à traiter déclenche une sélection d’un serveur de traitement dans le groupe de serveurs, et en ce que la requête à traiter est transmise au serveur sélectionné, dit serveur attribué, pour traitement. Figure 1 Procédé de gestion de l’attribution à un serveur de traitement de requêtes de téléphonie sur IP Le domaine technique est celui de la téléphonie sur IP. Plus précisément, l’invention se rapporte à un procédé de gestion de l’attribution à un serveur de traitement de requêtes de téléphonie sur IP appartenant à une session de téléphonie sur IP ainsi qu’à des procédés associés de traitement d’une requête de téléphonie sur IP par un serveur de traitement et de gestion d’une session de téléphonie sur IP par un système de téléphonie sur IP. L’invention se rapporte également à une entité de gestion, à un serveur de traitement, et à un système de téléphonie sur IP comprenant une entité de gestion et un groupe de serveurs de traitement. La mise en place de services téléphoniques vise à ce que des communications téléphoniques, également appelées liaisons, soient ouvertes entre deux ou plus terminaux téléphoniques. Un terminal appelant demande l’ouverture d’une liaison téléphonique avec un autre terminal, le terminal appelé, en adressant une demande d’ouverture à un serveur de traitement. Ce dernier traite la demande et établit une liaison point à point entre le terminal appelant et le terminal appelé, en collaborant avec d’autres serveurs pour établir la liaison. Une fois la liaison établie, une communication multimédia entre au moins le terminal appelant et le terminal appelé va permettre à la communication téléphonique de prendre place. La communication téléphonique nécessite donc d’une part des échanges suivant un protocole donné pour établir la liaison, et d’autre part un échange de données multimédia selon un autre protocole pour porter la voix et éventuellement l’image des interlocuteurs. Le ou les protocoles permettant d’établir la liaison sont traditionnellement appelés protocoles de signalisation. Ces concepts sont apparus d’abord en téléphonie classique, par exemple celle utilisant le réseau téléphonique commuté (RTC, dénommé Plain Old Telephone System en anglais, ou POTS) ou, plus récemment, avec le réseau numérique à intégration de services (RNIS, dénommé Integrated Services Digital Network en anglais, ou ISDN). Les terminaux téléphoniques sont alors tout simplement dénommés téléphones et les serveurs qui établissent les liaisons téléphoniques sont des commutateurs, et en particulier des autocommutateurs à partir du développement de la téléphonie numérique. L’accès des terminaux aux serveurs se faisait classiquement par un réseau filaire et utilise depuis la fin du vingtième siècle des ondes électromagnétiques pour la téléphonie sans fil. Ces concepts se retrouvent toujours dans la téléphonie moderne qui utilise le protocole IP (acronyme de l’anglais Internet Protocol ) pour transmettre à la fois les données nécessaires pour établir les liaisons téléphoniques lors des étapes de signalisation, et, une fois la liaison établie, pour transférer les données multimédia (sons et image) entre terminaux. L’établissement de la liaison téléphonique va souvent utiliser le protocole SIP (acronyme de l’anglais Session Initiation Protocol ) comme protocole de signalisation, alors que le transport de données multimédia entre les deux terminaux, une fois la liaison établie, utilise souvent le protocole RTP (acronyme de l’anglais Real-time Transport Protocol ). Le protocole H.323 est également utilisé. H.323 peut être décrit aussi comme une association de plusieurs protocoles différents qui peuvent être regroupés en trois catégories : la signalisation, la négociation de codecs (abrégé pour codeurs-décodeurs) qui vont encoder et décoder le signal vocal analogique émis par les utilisateurs en données numériques pour le transporter et enfin le transport des données multimédia dont, principalement, le signal vocal émis par les utilisateurs. On parle alors de téléphonie sur IP, qui comprend en particulier les communications téléphoniques vocales ou VoIP (acronyme de l’anglais Voice over IP ) mais comprend aussi le transfert de données multimédia ainsi que la signalisation. On peut noter que le ou les protocoles de signalisation permettent d’établir les communications mais rendent aussi des services plus élaborés que le simple établissement de connexions point-à-point, comme l’établissement d’appels à trois, de conférences, le signal d’appel, le transfert d’appel, l’identification de l’appelant, le blocage d’appel ou tout autre service de téléphonie. En téléphonie sur IP, les terminaux téléphoniques sont classiquement appelés téléphones IP. Etat de la technique La téléphonie, qu’il s’agisse de téléphonie classique ou de téléphonie sur IP, nécessite de mettre en place un protocole de communication avec état (traduction de l’anglais stateful protocol ), c’est-à-dire que l’établissement des communications téléphoniques se fait en prenant en compte un état des terminaux téléphoniques qui va évoluer tout au long de la communication téléphonique. De façon évidente, un terminal qui a déjà établi une communication téléphonique, qui est donc occupé, ne va pas accepter une demande supplémentaire de communication. Quand la communication initiale est coupée, le terminal passe à l’état libre, et pourra donc répondre positivement à une nouvelle demande de communication téléphonique et passera alors de nouveau à l’état occupé. Cette notion de protocole avec état s’oppose à celle de protocole de communication sans état (traduction de l’anglais stateless protocol ) dans lequel les participants au protocole ne font qu’échanger des questions et des réponses sans avoir de changement d’état. Une particularité de la téléphonie sur IP est qu’il s’agit d’un protocole avec état, comme tout protocole téléphonique, réalisé en utilisant un protocole sans état, à savoir le protocole IP. La mise en place d’un système de téléphonie sur IP implique également qu’un grand nombre de terminaux téléphoniques vont solliciter des serveurs en nombre forcément plus réduits. Ces serveurs peuvent être séparés en deux grandes catégories : Des serveurs de traitement des requêtes ayant trait à la signalisation, qui permettent d’établir les communications téléphoniques et qui rendent des services de téléphonie, tels que le signal d’appel, les communications à trois ou autres. Des serveurs multimédia qui assurent le transport des données multimédia entre les postes téléphoniques. De même, les serveurs de traitement des requêtes comprennent d’une part des serveurs d’application (traduction de l’anglais application servers ), souvent désignés par l’acronyme AS, qui rendent les différents types de service téléphoniques prévus en téléphonie sur IP et d’autre part des contrôleurs de session frontalière (traduction de l’anglais session border controllers ), souvent désignés par l’acronyme SBC. Les serveurs SBC sont situés en frontière des réseaux de téléphonie sur IP et c’est eux qui assurent les communications avec des éléments à l’extérieur de ces réseaux, ou d’un réseau de téléphonie sur IP vers un autre. En particulier, les serveurs SBC sont ceux qui assurent les communications avec les terminaux, c’est-à-dire avec les téléphones IP, qui sont considérés être en dehors du réseau de téléphonie IP proprement dit. Les serveurs SBC peuvent être vus comme comprenant d’une part un composant qui gère les aspects de signalisation, nommé élément de session frontalière, souvent dénommé SBE (acronyme de l’anglais session border element ) et d’autre part un composant qui gère les aspects média, à savoir une passerelle multimédia, souvent dénommée MGW (acronyme de l’anglais media gateway ). Dans le domaine de la téléphonie sur IP, la répartition des requêtes depuis les terminaux téléphoniques vers les serveurs de traitement des requêtes de téléphonie sur IP se passe traditionnellement de la manière suivante : à chaque terminal est affecté un serveur dédié qui va gérer l’ensemble des communications pour ce terminal. Ce serveur est le plus souvent un serveur SBC. En cas de panne du serveur SBC, celui-ci dispose d’un serveur de secours qui va reprendre les liaisons téléphoniques en cours gérées par le serveur avant sa panne. De cette manière, la gestion du protocole de téléphonie avec état et des sessions de téléphonie auxquelles participent les téléphones IP est assuré par le serveur de traitement qui est associé à un parc donné de téléphones IP. Cette situation présente des inconvénients. Tout d’abord, elle nécessite de réserver une grande quantité de ressources matérielles et de calcul. Si un serveur d’une taille donnée est dimensionné pour gérer les communications téléphoniques d’un parc de terminaux d’une certaine taille, il faut en fait doubler le nombre de serveurs pour rendre le service téléphonique. En général, un serveur SBC est dimensionné pour s’occuper d’un parc d’environ 100 000 terminaux. Quand un réseau de téléphonie IP traite un peu plus que 100 000 téléphones IP, il faudra à un moment rajouter un nouveau serveur SBC (et son serveur de secours), ce qui va doubler le nombre de serveurs SBC déployés. Cette solution ne permet pas de moduler le nombre de serveurs selon les besoins alors que ceux-ci varient dans le temps ; par exemple, les besoins en communications téléphoniques sont bien plus élevés dans un contexte professionnel en journée que la nuit, mais le nombre de serveurs SBC déployé pour un parc de téléphones IP donné ne va pas changer pour autant. De plus, cette situation ne permet pas de rajouter facilement de nouveaux terminaux. Il faut à chaque fois ajouter un serveur et son double pour prendre en compte de nouveaux serveurs. Il faut également redéfinir le plan d’affectation des téléphones IP aux serveurs SBC pour éviter qu’un nouveau serveur SBC ne prenne en charge que quelques terminaux à son lancement, ce qui ne soulagerait pas la charge des serveurs SBC déjà déployés. Ensuite, cette situation nécessite de faire des hypothèses sur le taux d’utilisation que les téléphones IP feront du service téléphonique afin de déterminer combien de serveurs doivent être prévus pour un parc donné. Ces hypothèses peuvent être erronées et l’adaptation du nombre de serveurs sera alors assez difficile car elle nécessitera d’affecter à des terminaux de nouveaux serveurs quand on ajustera leur nombre à la baisse ou à la hausse. Enfin, les serveurs SBC dans cette situation sont des serveurs à état, qui doivent prendre en compte l’état des sessions téléphoniques qu’ils gèrent. Cela rajoute de la complexité au développement de ces serveurs, ce qui les rend davantage susceptibles de tomber en panne logicielle. Une solution possible qui a été utilisée est d’affecter un groupe de serveurs SBC à un parc de téléphones IP donné et d’utiliser des outils d’équilibrage de charge pour mieux répartir la charge entre les serveurs SBC déployés pour un parc donné. Cependant, dans cette solution, c’est toujours un serveur unique qui sera chargé de traiter une session de téléphonie sur IP donnée de bout en bout. En cas de panne d’un serveur, les communications en cours traitées par ce serveur sont alors interrompues. Et les serveurs, qui traitent toutes les requêtes d’une session donnée, sont toujours des serveurs à état, donc compliqués à développer d’un point de vue logiciel. L’invention vient améliorer la situation. Selon un premier aspect fonctionnel, l’invention a trait à un procédé de gestion par une entité de gestion de l’attribution à un serveur de traitement, appartenant à un groupe de serveurs, de requêtes de téléphonie sur IP, dites requêtes à traiter, appartenant à une même session de téléphonie sur IP, dite session en cours, caractérisé en ce que, durant la session en cours, une réception d’une requête à traiter déclenche une sélection d’un serveur de traitement dans le groupe de serveurs, et en ce que la requête à traiter est transmise au serveur sélectionné, dit serveur attribué, pour traitement. Grâce à l’invention, les terminaux téléphoniques en téléphonie sur IP ne sont plus affectés à un serveur de téléphonie sur IP défini à l’avance. Pour cela, les requêtes de téléphonie sur IP émises par les terminaux sont attribuées au cours d’une session à des serveurs de traitement au cas par cas, requête par requête, après avoir été reçue par une entité de gestion. De cette manière, il n’est plus nécessaire de réserver des ressources à l’avance en affectant un serveur et son serveur de secours à un nombre déterminé à l’avance de téléphones IP. De plus, un serveur de traitement est affecté à une requête de la session, et non pas pour traiter toute une session de bout en bout. Grâce à l’invention, un groupe de serveurs de traitement de requêtes va traiter les requêtes à la demande. En cas de panne d’un serveur de traitement dans le groupe, les autres serveurs du groupe pourront le remplacer. Il n’est donc plus nécessaire de prévoir un serveur de secours pour tous les serveurs de traitement de téléphonie IP affectés à un parc de terminaux défini à l’avance. Et en cas de panne d’un serveur du groupe, cela n’empêche pas les sessions en cours pour lesquelles ce serveur était intervenu de continuer malgré tout. Autrement dit, alors que, dans la situation actuelle, une panne de serveur de traitement va compromettre la mise en place et la poursuite des communications téléphoniques gérées par ce serveur, ce n’est pas le cas grâce à l’invention puisque les serveurs ne gèrent que des requêtes individuelles des sessions et non pas une session de bout en bout. Selon un mode de mise en œuvre particulier de ce premier aspect de l’invention, la requête à traiter inclut un champ qui prend une valeur, dite valeur clé, qui est égale à la valeur prise par le même champ d’une précédente requête à traiter appartenant à la session en cours, et la requête à traiter transmise au serveur attribué inclut la valeur clé. Grâce à ce mode de réalisation, le traitement tout du long d’une session de téléphonie sur IP par des serveurs différents est facilité. Les serveurs de traitement pourront retrouver des informations quant aux requêtes précédentes de la session grâce à une valeur clé qui est identique dans au moins une requête précédente. En récupérant des informations de proche en proche, un serveur de traitement pourra disposer des informations quant aux traitements réalisés par d’autres serveurs. La transmission de la valeur clé dans la requête au serveur attribué aide à réaliser cet objectif. D’autres modes de réalisation sont possibles. Par exemple, la base de sessions peut enregistrer l’ensemble des requêtes de téléphonie traitées par le système de téléphonie, et restituer à la demande d’un serveur de traitement cet ensemble de requêtes. Le serveur de traitement analyse alors cet ensemble pour déterminer les informations utiles au traitement de la requête attribuée au serveur. Ce mode de réalisation implique le traitement d’un plus grand nombre de données mais a l’avantage de simplifier le fonctionnement de la base de sessions qui n’a plus qu’à enregistrer l’ensemble des requêtes traitées et à les fournir à la demande. Selon un autre mode de mise en œuvre particulier de ce premier aspect de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le mode précédent, le serveur attribué pour traiter la requête à traiter est différent du serveur de traitement qui a été attribué par l’entité de gestion pour traiter la précédente requête à traiter appartenant à la même session de téléphonie sur IP. Grâce à ce mode, les différentes requêtes d’une même session de téléphonie sur IP sont a priori traitées par des serveurs différents du groupe de serveurs. De cette manière, contrairement à la situation de l’état de la technique, un serveur de traitement n’a pas la charge d’une session de bout en bout, ce qui implique que, quand un serveur tombe en panne, toutes les sessions traitées par ce serveur sont impactées. Ici, grâce à l’invention, quand un serveur tombe en panne, les communications téléphoniques que ce serveur a contribué à mettre en place ne sont pas impactées. De plus, dans l’invention, un serveur de traitement est un serveur sans état (traduction de l’anglais stateless ), qui n’a pas à mémoriser l’état d’une session de téléphonie sur IP. En effet, l’entité de gestion attribue les requêtes une par une aux serveurs de traitement, sans attribuer toutes les requêtes d’une même session à un seul serveur. Le serveur attribué ne traite donc qu’une requête, de manière individuelle et indépendante des autres requêtes de la session de téléphonie sur IP. Un tel serveur de traitement est donc bien sans état, sans nécessité de mémoriser l’état de la session à laquelle appartient la requête traitée. Un tel serveur est plus facile à développer qu’un serveur de traitement qui doit mémoriser l’état des session qu’il traite comme dans l’état de la technique. Un tel serveur plus simple est plus robuste, ce qui améliore la qualité du service de téléphonie sur IP en général. Selon un autre mode de mise en œuvre particulier de ce premier aspect de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la requête à traiter est la requête initiale de la session de téléphonie sur IP et il n’y a pas de précédente requête à traiter dans la session en cours. Dans le cas général, un serveur différent sera attribué à la requête à traiter que celui qui a été attribué à la requête précédente dans la session de téléphonie. Mais, cela ne peut pas être le cas pour la requête initiale de la session de téléphonie. Grâce à cet aspect de l’invention, ce cas particulier est traité. Selon un autre mode de mise en œuvre particulier de ce premier aspect de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le nombre de serveurs de traitement appartenant au groupe de serveurs varie dans le temps. Grâce à ce mode, le groupe de serveurs de traitement qui vont réaliser les traitements de requêtes de téléphonie sur IP n’est pas figé, selon le nombre de téléphones IP traités par les serveurs de traitement, mais va grandir ou diminuer dans le temps. De cette manière, l’adaptation du nombre de serveurs de traitement à la demande est beaucoup plus souple. Par exemple, le nombre de serveurs actifs va diminuer la nuit quand les besoins en téléphonie IP diminuent. Ainsi, les ressources énergétiques et matérielles mobilisées par les serveurs de traitement sont économisées. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la requête à traiter est issue d’un téléphone IP et le serveur attribué est sélectionné par l’entité de gestion indépendamment dudit téléphone IP. Les requêtes de téléphonie IP sont en général émises par des téléphones IP. Dans ce mode de réalisation, il est précisé que les serveurs de traitement ne sont pas attribués en utilisant l’identité du téléphone IP émetteur, car cela reviendrait à attribuer un serveur de traitement à un parc de téléphones IP donné. Ici, un téléphone IP qui émettra une requête de téléphonie IP la verra reçue d’abord par l’entité de gestion qui va ensuite l’attribuer à un serveur de traitement. Une requête suivante du même téléphone IP pourra alors être attribuée à un autre serveur de traitement. De cette manière, l’invention permet bien d’éviter d’affecter à l’avance un serveur de traitement à un parc de téléphones IP. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents modes, les requêtes à traiter incluent des champs qui prennent un ensemble de valeurs et le serveur attribué est sélectionné par l’entité de gestion indépendamment des dites valeurs. Grâce à ce mode de mise en œuvre particulier de l’invention, l’entité de gestion attribue le traitement de la requête à un serveur sans prendre en compte les valeurs des champs inclus dans la requête. De cette manière, l’attribution est accélérée car l’entité de gestion n’a pas à consulter les champs de la requête avant d’attribuer celle-ci. De plus, le fait d’attribuer le serveur de traitement indépendamment des valeurs prises par les champs de la requête garantit que, dans le cas général, le serveur attribué sera bien différent. Autrement dit, plusieurs serveurs de traitement différents seront attribués aux différentes requêtes tout au long de la session de téléphonie IP. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’entité de gestion accède à une base de données, dite base de sessions, et le serveur attribué est choisi par l’entité de gestion après lecture par l’entité de gestion d’une information enregistrée dans la base de sessions accessible grâce à la valeur clé. Ici, contrairement au mode précédent, l’entité de gestion utilise des valeurs de champs présents dans la requête pour attribuer la requête à traiter à un serveur de traitement, et en particulier une valeur clé, qui se retrouve d’une requête à l’autre. Ce mode prend plus de temps au moment de l’attribution car l’entité de gestion doit récupérer les valeurs en question et consulter des informations relatives à la session sauvegardées dans une base de données dite base de sessions. Mais ce mode peut être plus efficace finalement, par exemple en attribuant les requêtes d’une session donnée, ou d’une partie d’une session donnée, à un seul serveur de traitement. Dans ce cas, on gagne quand même en efficacité par rapport au mode où les serveurs sont attribués en avance à des terminaux, car il n’est pas besoin de réserver un nombre donné de serveurs en fonction du nombre de terminaux mais simplement un nombre de serveurs adapté au nombre de sessions à traiter qui est attendu. De plus des modes de réalisation mixtes peuvent être déployés dans lesquels certaines requêtes seront attribuées sans prendre en compte les valeurs des champs, et pour d’autres catégories de requêtes, il faudra attribuer les requêtes successives de la même catégorie d’une même session à un même serveur et dans ce cas là consulter une information présente dans une base de sessions séparée de l’entité de gestion. Une telle information sera accessible grâce à la valeur clé. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le serveur attribué est sélectionné par l’entité de gestion de manière à répartir la charge de traitement entre les différents serveurs du groupe et l’entité de gestion est un équilibreur de charge. L’entité de gestion peut être un équilibreur de charge (traduction de l’anglais load balancer ) qui va assurer que les requêtes de téléphonie IP sont bien réparties entre les différents serveurs de traitement du groupe. Grâce à ce mode de réalisation, les ressources de calcul utilisées par les serveurs de traitement sont optimisées puisqu’il n’y a pas de déséquilibre entre des serveurs sous-utilisés et des serveurs trop utilisés. Ce mode a aussi l’avantage d’améliorer la fiabilité des serveurs de traitement en évitant des surcharges possibles en répartissant la charge au mieux. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le serveur attribué est choisi par l’entité de gestion de manière aléatoire. Grâce à ce mode de réalisation, une manière simple de réaliser l’équilibrage de charge (traduction de l’anglais load balancing ) est proposée. Pour cela, l’attribution d’un serveur de traitement à une requête se fait par un tirage aléatoire. Cette technique est facile à mettre en œuvre et réalise une répartition appropriée des requêtes entre serveurs. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le serveur attribué est choisi en utilisant un algorithme dit de tourniquet. Un algorithme de tourniquet (traduction de l’anglais round robin ) est un algorithme classique d’équilibrage de charge. Grâce à ce mode de réalisation, un algorithme connu d’équilibrage de charge est utilisé dans le domaine de la téléphonie sur IP. Un avantage est de pouvoir bénéficier de technologies connues par ailleurs dans ce domaine, et donc de réutiliser des logiciels déjà existants. L’algorithme de tourniquet permet une répartition efficace et va donc là aussi améliorer l’utilisation des ressources par les serveurs de traitement. Une telle répartition se fait sans prise en compte des éléments de la requête relatifs à la session de téléphonie IP en cours, tels que les valeurs prises par les champs de la requête par exemple. Plusieurs requêtes d’une même session seront donc attribuées à des serveurs de traitement différents. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’entité de gestion utilise un serveur de nom de domaine qui va attribuer la requête à traiter en remplaçant un nom de domaine utilisé par la requête par une adresse IP qui sera celle du serveur attribué. Pour réaliser un équilibrage de charge, une manière possible est d’utiliser un serveur de nom de domaine qui va mettre en œuvre le protocole DNS (acronyme de l’anglais Domain Name Service ). Dans ce mode de réalisation, un téléphone IP va adresser une requête à un nom de domaine en utilisant le protocole IP, et c’est le serveur de nom de domaine qui oriente la requête vers une adresse IP possible pour ce nom de domaine. L’adresse IP sera alors celle du serveur de traitement qui traitera la requête de téléphonie IP. Ce mode de réalisation permet donc d’obtenir une alternative de réalisation de l’invention. Les différentes techniques d’équilibrage de charge peuvent être intégrées dans le serveur de nom de domaine afin d’optimiser la répartition du traitement des requêtes entre serveurs. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’entité de gestion utilise un mécanisme d’adresse IP virtuelle. Grâce à ce mode de réalisation, une alternative est proposée pour l’attribution des requêtes. Le mécanisme d’adresse IP virtuelle est plus léger que le déploiement d’un serveur de nom de domaine et permet là aussi d’orienter une requête vers un serveur parmi un groupe de serveurs, requête qui utilise initialement une adresse IP virtuelle. Là encore, une telle répartition se fait sans prise en compte des éléments de la requête relatifs à la session de téléphonie IP en cours, tels que les valeurs prises par les champs de la requête par exemple. Plusieurs requêtes d’une même session seront donc attribuées à des serveurs de traitement différents. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, les requêtes à traiter comprennent un champ dont la valeur prise est identique pour toutes les requêtes à traiter appartenant à la même session de téléphonie IP. Selon un autre mode de mise en œuvre de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la valeur clé est identique pour toutes les requêtes à traiter appartenant à la même session de téléphonie IP. Grâce à ces modes de réalisation, une information présente dans les requêtes à traiter permet de retrouver toutes les requêtes appartenant à une même session de téléphonie. Cette information n’est pas utilisée pour l’attribution, et les différentes requêtes d’une même session sont toujours dans ce mode attribuées à différents serveurs du groupe. Mais la présence d’une telle information, qui constitue un identifiant de session, permet de faciliter le traitement ultérieur des requêtes par les différents serveurs. Selon un deuxième aspect fonctionnel, l’invention a trait à un procédé de traitement d’une requête de téléphonie sur IP, dite requête à traiter, appartenant à une session de téléphonie sur IP, dite session en cours, par un serveur de traitement, dit serveur attribué, appartenant à un groupe de serveurs, caractérisé en ce que le procédé comprend les étapes suivantes : Réception de la requête à traiter transmise par une entité de gestion en charge de l’attribution des requêtes à traiter de la session en cours ; Lecture dans une base de données, dite base de sessions, d’une information relative à la session en cours ; Traitement de la requête à traiter en utilisant l’information lue. Grâce à ce deuxième aspect de l’invention, le traitement proprement dit des requêtes de téléphonie sur IP est réalisé. Une fois la requête attribuée à un serveur de traitement par l’entité de gestion en charge de cet aspect de l’invention, la requête est transmise par l’entité de gestion et reçue par le serveur de traitement. Celui-ci va alors lire dans une base de données dénommée base de sessions une ou des informations relatives à la session en cours. La base de sessions peut être accédée par les serveurs appartenant au groupe de serveurs. De cette manière, le serveur de traitement peut récupérer toutes les informations utiles au traitement de la requête qui prend en compte les traitements des requêtes précédentes qui ont pris place dans la même session. C’est cette fonctionnalité qui permet de réaliser le traitement d’un protocole de téléphonie IP qui est par nature un protocole avec état en utilisant un procédé sans état dans lequel une requête de téléphonie est attribuée, y compris dans certains modes de façon aléatoire, à un serveur parmi un groupe de serveurs. Le traitement de la requête se fait alors selon les fonctionnalités classiques d’un serveur de traitement de téléphonie IP, une fois que les informations relatives à la session ont bien été obtenues par le serveur. En téléphonie sur IP classique, les serveurs de traitement sont affectés à des téléphones IP et ils conservent les informations utiles de session de façon locale. Grâce à l’invention, les serveurs n’ont plus à être affectés à des téléphones IP de façon statique ; les requêtes leur sont attribuées à la volée et ils récupèrent les informations de session nécessaires dans une base qui peut être accessible aux serveurs de traitement du groupe afin qu’un serveur à qui la requête est attribuée puisse récupérer les informations nécessaires. L’avantage de l’invention est alors l’économie de ressources énergétiques, matérielles, de calcul et de mémoire puisqu’il n’est plus nécessaire de réserver un grand nombre de serveurs pour un parc donné de téléphones IP. Un autre avantage de l’invention est la robustesse de la solution. Si un serveur tombe en panne dans le groupe de serveurs de traitement, les autres serveurs du groupe vont prendre son relais dans le traitement des requêtes à traiter. C’est également vrai si un deuxième serveur vient à tomber en panne alors que, dans le fonctionnement classique de la téléphonie sur IP, il suffit qu’un serveur tombe en panne, puis son serveur de secours, pour que tout un parc de téléphones IP se trouve privé du service de téléphonie. De plus, la panne d’un serveur de traitement ne va pas impliquer la coupure des sessions de téléphonie sur IP gérées par ce serveur puisque, dans une même session de téléphonie, les différentes requêtes sont traitées, une par une, par différents serveurs. Selon un mode de mise en œuvre particulier de ce deuxième aspect de l’invention, la requête à traiter inclut un champ qui prend une valeur, dite valeur clé, qui est égale à la valeur prise par le même champ d’une précédente requête à traiter appartenant à la session en cours et l’information lue dans la base de sessions est accessible grâce à la valeur clé. Grâce à ce premier mode du deuxième aspect fonctionnel de l’invention, une méthode permettant de retrouver les informations relatives à la session est donnée. Pour cela, une valeur clé est identifiée qui va se retrouver depuis la requête à traiter dans une requête précédente de la session en cours. De proche en proche, il est possible de retrouver les informations nécessaires au traitement d’une requête à traiter. Ces valeurs se retrouvent par exemple dans les champs d’en-têtes des requêtes selon le protocole SIP. La programmation de la base de sessions permet d’extraire la ou les informations pertinentes au traitement d’une requête donnée à partir de la valeur clé en remontant de proche en proche dans les requêtes précédentes de la session en cours. Les liens entre différentes valeurs clés inscrits dans la base de sessions peuvent permettre de réaliser cette remontée d’informations de proche en proche. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent mode, la requête à traiter est la requête initiale de la session de téléphonie sur IP et la lecture dans la base de sessions ne fournit aucune information. De manière similaire au fonctionnement du procédé de gestion de l’attribution d’une requête, la récupération d’information à partir d’une valeur clé n’apportera aucune information dans le cas du traitement de la requête initiale d’une session de téléphonie sur IP. La base de sessions pourra quand même, dans ce mode de réalisation, interrogée, mais ne fournira aucune information relative à la session en cours puisque la requête traitée est la requête initiale de celle-ci. Selon un autre mode de mise en œuvre particulier de ce deuxième aspect de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le mode précédent, le nombre de serveurs de traitement appartenant au groupe de serveurs varie dans le temps. Grâce à ce mode de réalisation du second aspect fonctionnel de l’invention, le groupe de serveurs de traitement qui vont réaliser les traitements de requêtes de téléphonie sur IP n’est pas figé, selon le nombre de téléphones IP traités par les serveurs de traitement, mais va grandir ou diminuer dans le temps. De cette manière, l’adaptation du nombre de serveurs de traitement à la demande est beaucoup plus souple. Par exemple, le nombre de serveurs actifs va diminuer la nuit quand les besoins en téléphonie IP diminuent. Ainsi, les ressources énergétiques et matérielles mobilisées par les serveurs de traitement sont économisées. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents modes, le procédé comprend de surcroît une étape d’enregistrement dans la base de sessions d’une information relative au traitement par le serveur attribué de la requête à traiter, ladite information étant accessible grâce à la valeur clé. Une fois le traitement réalisé, il est utile, dans le cas général, que le serveur de traitement qui vient de réaliser le traitement d’une requête de téléphonie sur IP aille inscrire dans la base de sessions des informations utiles aux traitements ultérieurs de requêtes qui auront trait à la même session. De cette manière, la suite des traitements nécessaires pour compléter la session pourront être réalisés par d’autres serveurs de traitement que celui qui vient de réaliser la requête. L’information utile aux traitements ultérieurs sera alors accessible grâce à la valeur clé qui sera retrouvée par exemple par la requête suivante de la même session. Cette opération n’est cependant pas une opération nécessaire dans tous les cas et peut être omise selon la nature de la requête de téléphonie sur IP. Par exemple, une fois une liaison téléphonique IP établie, il existe un canal de transfert de données multimédia entre deux téléphones IP (au moins), c’est-à-dire une liaison de données gérée par des serveurs multimédia. Supposons qu’une requête de téléphonie sur IP consiste à changer un paramètre de cette liaison, par exemple un paramètre ayant trait à l’échantillonnage, ou à la latence des données ou à tout autre aspect géré par les serveurs multimédia. Le traitement de la requête va alors consister à envoyer aux serveurs multimédia une instruction de changement de paramètre. Mais s’il n’est pas utile de conserver cette information pour des traitements ultérieurs, parce que ce sont les serveurs multimédia seulement qui ont besoin de cette information par exemple, le fait de ne pas enregistrer d’information relative au traitement dans la base de sessions va permettre d’économiser les ressources mémoires et temporelles qui auraient été gaspillées en réalisant cet enregistrement. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’étape de lecture est omise selon la nature de la requête à traiter. Grâce à ce mode de réalisation, le traitement de la requête de téléphonie IP est accéléré puisque la lecture d’information dans la base de sessions est omise. Cette étape peut être omise par exemple quand la nature de la requête permet de déduire que cette requête crée la session et qu’il n’y a pas eu de requête précédente qui a pu laisser une information nécessaire au traitement de la requête présente. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la base de sessions est une grappe de bases de données à haute disponibilité. Grâce à ce mode de réalisation, l’efficacité de l’invention est améliorée et en particulier la disponibilité du service. On a vu que l’invention permet de résister à des pannes de serveurs puisque les téléphones IP ne sont plus attribués à un serveur donné mais adressent leurs requêtes de téléphonie à un groupe de serveurs dont chacun peut potentiellement assurer le traitement. Cependant, l’invention utilise une base de données accessible à tous les serveurs du groupe qui peut devenir un point de défaillance unique (traduction de l’anglais single point of failure ). Si la base de sessions ne fonctionne plus, les serveurs de traitement ne peuvent plus récupérer les informations relatives aux sessions et ne peuvent plus traiter les requêtes. Pour diminuer fortement la probabilité de survenue de ce risque, la fonctionnalité de la base de sessions est réalisée, dans ce mode, non pas par une base de données unique, mais par une grappe (traduction de l’anglais cluster ) de base de données à haute disponibilité. Ce mode de réalisation réduit donc fortement la probabilité d’indisponibilité du service de téléphonie sur IP causé par une indisponibilité de la base de sessions. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la requête à traiter comprend un champ dont la valeur prise est identique pour toutes les requêtes à traiter appartenant à la même session de téléphonie sur IP. Selon un autre mode de mise en œuvre de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la valeur clé est identique pour toutes les requêtes à traiter appartenant à la même session de téléphonie IP. Grâce à ces modes de réalisation, une information présente dans les requêtes à traiter permet de retrouver toutes les requêtes appartenant à une même session de téléphonie. Les différentes requêtes d’une même session sont toujours dans ce mode attribuées à différents serveurs du groupe. Mais la présence d’une telle information, qui constitue un identifiant de session, permet de faciliter le traitement des requêtes par les différents serveurs. Selon un troisième aspect fonctionnel, l’invention a trait à un procédé de gestion d’une session de téléphonie sur IP, dite session en cours, par un système de téléphonie sur IP, ledit système comprenant une entité de gestion en charge de l’attribution d’une requête de téléphonie sur IP, un groupe de serveurs de traitement, et une base de données, dite base de sessions, la session en cours comprenant des requêtes de téléphonie sur IP, dites requêtes à traiter, caractérisé en ce que, durant la session en cours, une réception d’une requête à traiter par l’entité de gestion déclenche une sélection d’un serveur de traitement dans le groupe de serveurs, et en ce que la requête à traiter est transmise par l’entité de gestion au serveur sélectionné, dit serveur attribué, pour traitement et en ce qu’un serveur attribué traite une requête à traiter en réalisant les étapes suivantes : Réception de la requête à traiter transmise par l’entité de gestion ; Lecture dans la base de sessions d’une information relative à la session en cours ; Traitement de la requête à traiter en utilisant l’information lue. Grâce à ce troisième aspect fonctionnel de l’invention, le traitement complet d’une session de téléphonie sur IP est réalisé par un système de téléphonie sur IP selon l’invention. Une requête appartenant à une session de téléphonie sur IP est attribuée par une entité de gestion comprise dans le système à un serveur appartenant à un groupe de serveurs compris dans le système. Ces serveurs sont attribués par l’entité de gestion pour équilibrer la charge, sans prendre en compte a priori l’état de la session de téléphonie en cours. De plus, les serveurs de traitement sont également des serveurs sans état. Un serveur donné ne va pas traiter une session de téléphonie dans son intégralité mais une ou plusieurs requêtes de la session, selon l’attribution réalisée par l’entité de gestion, par exemple selon les besoins d’équilibrage de charge. Les informations relatives à la session, nécessaires au traitement de la requête, sont alors récupérées par le serveur de traitement dans la base de sessions. Grâce à l’invention, une gestion souple d’une session de téléphonie sur IP est rendue possible, sans affectation préalable des serveurs de traitement à un parc de téléphones donné ni même à une session donnée, puisque les différentes requêtes d’une même session seront en général attribuées à des serveurs différents. Selon un mode de mise en œuvre particulier de ce troisième aspect de l’invention, une requête de la session en cours inclut un champ qui prend une valeur, dite valeur clé, qui est égale à la valeur prise par le même champ d’une précédente requête à traiter appartenant à la session en cours et l’information lue dans la base de sessions est accessible grâce à la valeur clé. Grâce à ce premier mode du troisième aspect fonctionnel de l’invention, la récupération dans la base de sessions des informations relatives à la session est facilitée. Une requête dispose d’une valeur clé qui permet de retrouver, dans la base de sessions, de proche en proche, les informations relatives aux traitements réalisés sur les requêtes précédentes d’une même session. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le mode précédent, le procédé comprend de surcroît une étape d’enregistrement par le serveur attribué dans la base de sessions d’une information relative au traitement par le serveur attribué de la requête à traiter, ladite information étant accessible grâce à la valeur clé. Une fois le traitement réalisé, il est utile, dans le cas général, que le serveur de traitement qui vient de réaliser le traitement d’une requête de téléphonie sur IP aille inscrire dans la base de sessions des informations utiles aux traitements ultérieurs de requêtes qui auront trait à la même session. De cette manière, la suite des traitements nécessaires pour compléter la session pourront être réalisés par d’autres serveurs de traitement que celui qui vient de réaliser la requête. L’information utile aux traitements ultérieurs sera alors accessible grâce à la valeur clé qui sera retrouvée par exemple par la requête suivante de la même session. Selon un autre mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, les requêtes à traiter comprennent un champ dont la valeur prise est identique pour toutes les requêtes à traiter appartenant à la session en cours. Selon un autre mode de mise en œuvre de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la valeur clé est identique pour toutes les requêtes à traiter appartenant à la même session de téléphonie IP. Grâce à ces modes de réalisation, une valeur se retrouve à l’identique dans toutes les requêtes de la session qui est gérée par le système de téléphonie sur IP. Une telle valeur sert d’identifiant de session et permet de simplifier les traitements réalisés par la base de sessions pour fournir les informations utiles au traitement des requêtes de la session. Selon un premier aspect matériel, l’invention a trait à une entité de gestion apte à réaliser un procédé de gestion de l’attribution à un serveur de traitement, appartenant à un groupe de serveurs, de requêtes de téléphonie sur IP, dites requêtes à traiter, appartenant à une même session de téléphonie sur IP, dite session en cours, caractérisé en ce que l’entité de gestion comprend : Un module de réception d’une requête à traiter ; Un module de sélection d’un serveur de traitement dans le groupe de serveurs ; Un module de transmission d’une requête à traiter ; et en ce que, durant la session en cours, une réception par le module de réception d’une requête à traiter déclenche une sélection par le module de sélection d’un serveur de traitement dans le groupe de serveurs, et en ce que la requête à traiter est transmise par le module de transmission au serveur sélectionné, dit serveur attribué, pour traitement. Selon un deuxième aspect matériel, l’invention a trait à un serveur de traitement d’une requête de téléphonie sur IP, dite requête à traiter, appartenant à une session de téléphonie sur IP, dite session en cours, ledit serveur de traitement appartenant à un groupe de serveurs, caractérisé en ce que le serveur comprend les modules suivants : Un module de réception de la requête à traiter transmise par une entité de gestion en charge de l’attribution des requêtes à traiter de la session en cours ; Un module de lecture dans une base de données, dite base de sessions, d’une information relative à la session en cours ; Un module de traitement de la requête à traiter en utilisant l’information lue. Selon un mode de mise en œuvre particulier de ce deuxième aspect matériel de l’invention, la requête à traiter inclut un champ qui prend une valeur, dite valeur clé, qui est égale à la valeur prise par le même champ d’une précédente requête à traiter appartenant à la session en cours et l’information lue dans la base de sessions est accessible grâce à la valeur clé. Selon un autre mode de mise en œuvre particulier de ce deuxième aspect matériel, l’invention a trait à un serveur de traitement comprenant de surcroît un module d’enregistrement dans la base de sessions d’une information relative au traitement par le serveur de traitement de la requête à traiter, ladite information étant accessible grâce à la valeur clé. Selon un autre aspect matériel, l’invention a trait à un système de téléphonie sur IP comprenant une entité de gestion selon l’invention, un groupe de serveurs de traitement selon l’invention et une base de données, dite base de sessions. Selon un autre aspect matériel, l’invention a trait à un programme d’ordinateur apte à être mis en œuvre par une entité de gestion, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion défini ci-dessus. Selon un autre aspect matériel, l’invention a trait à un programme d’ordinateur apte à être mis en œuvre par un serveur de traitement d’une requête de téléphonie sur IP, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de traitement défini ci-dessus. Enfin, selon un autre aspect matériel, l’invention a trait à des supports de données sur lesquels sont enregistrés des programmes d’ordinateurs comprenant des séquences d’instructions pour la mise en œuvre des procédés de gestion et de traitement définis ci-dessus. Les supports de données peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique tel qu’un un disque dur. D'autre part, les supports peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peuvent être acheminés via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple, et faite en référence aux dessins annexées sur lesquels : FIG. 1 représente un système de téléphonie sur IP comprenant une entité de gestion selon l’invention, un groupe de serveurs de traitement selon l’invention et une base de données, dite base de sessions. FIG. 2 illustre un exemple d’échanges de messages réalisés lors d’une session de téléphonie sur IP établie en utilisant les procédés selon l’invention. FIG. 3 représente un autre exemple d’architecture d’un système de téléphonie sur IP selon l’invention. Description détaillée La FIG. 1 représente un système SYS de téléphonie sur IP comprenant une entité de gestion 100 apte à réaliser un procédé de gestion de l’attribution d’une requête de téléphonie sur IP à un serveur de traitement ; un groupe GP de serveurs de traitement SBE, SBE’, SBE’’ ; une base de données SDB, dite base de sessions ; et d’autres serveurs AS, AS’, AS’’, MGW, MGW’ et MGW’’. La FIG. 1 représente un exemple de réalisation de l’invention parmi d’autres modes de réalisation possibles. La FIG. 1 représente également des téléphones IP, dont un dénommé TEL1, et un réseau de communication NWK. Le réseau NWK est un réseau IP (de l’anglais Internet Protocol ), public ou privé, qui relie entre eux le système SYS de téléphonie sur IP et d’autres systèmes similaires ainsi que les téléphones IP, dont le téléphone TEL1, géré par le système SYS. Il peut s’agir d’un réseau filaire ou sans fil selon technologie physique utilisée, ou d’un mélange de réseaux filaires et sans fil. Le réseau NWK peut être un réseau local ou bien un réseau métropolitain ou international, ou bien une combinaison de réseaux locaux reliés entre eux par un réseau de transport entre plusieurs sites. Le réseau NWK peut également être un réseau d’entreprise reliant les différents sites d’une même compagnie. Le réseau NWK peut comprendre plusieurs réseaux privés virtuels déployés sur un réseau public tel que le réseau Internet. Le réseau NWK peut également être une combinaison de ces différents types de réseaux. L’entité de gestion 100 comprend les modules suivants : Un module 101 de réception d’une requête à traiter RQ(V) ; Un module 102 de sélection d’un serveur de traitement SBE dans le groupe GP de serveurs ; Un module 103 de transmission d’une requête à traiter RQ(V) au serveur de traitement SBE. Le serveur de traitement SBE comprend les modules suivants : Un module 201 de réception de la requête à traiter RQ(V) transmise par l’entité de gestion 100 ; Un module 202 de lecture dans la base de sessions SDB d’une information INF relative à la session en cours ; Un module 203 de traitement de la requête à traiter RQ(V) en utilisant l’information INF lue. L’entité de gestion 100 présente l’architecture matérielle d’un ordinateur conventionnel. Elle comporte notamment un processeur, une mémoire vive de type RAM et une mémoire morte telle qu’une mémoire de type Flash, ROM, (non représentés sur la figure) ainsi que des dispositifs d’entrée-sortie tels que, dans certains cas, des claviers et/ou écrans (non représentés sur la figure), et des ports réseaux permettant de communiquer avec d’autres entités et serveurs grâce au réseau de communication NWK. En particulier, l’entité de gestion 100 peut communiquer avec des téléphones IP tels que le téléphone TEL1. L’entité de gestion 100 peut être par exemple un routeur en charge des communications d’un parc de téléphones IP. L’entité de gestion 100 se situe alors en entrée des requêtes de téléphonie sur IP émises par les téléphones IP vers le système SYS. L’entité de gestion 100 peut alors comprendre un serveur d’équilibrage de charge, ou bien un serveur DNS, ou tout autre serveur permettant de recevoir et orienter des requêtes de téléphonie sur IP. Le serveur de traitement SBE présente également l’architecture matérielle d’un ordinateur conventionnel. Il comporte notamment un processeur, une mémoire vive de type RAM et une mémoire morte telle qu’une mémoire de type Flash, ROM, (non représentés sur la figure) ainsi que des dispositifs d’entrée-sortie tels que, dans certains cas, claviers et/ou écrans (non représentés sur la figure), et des ports réseaux permettant de communiquer avec d’autres entités et serveurs grâce au réseau de communication NWK. La base de sessions SDB est une base de données qui s’exécute sur un serveur de bases de données qui présente également l’architecture matérielle d’un ordinateur conventionnel. La base de sessions SDB est également accessible par l’intermédiaire du réseau NWK à l’ensemble des entités et serveurs du système SYS ayant besoin d’y accéder pour les besoins de l’invention. La base de sessions SDB peut être réalisée par une base de données unique, ou bien par un duo de base de données, ou par une plus grande quantité de bases de données, afin d’être disponible en lecture ou en écriture aux différentes entités et serveurs du système SYS qui en ont besoin. La base de sessions SDB peut être une grappe de bases de données à haute disponibilité. La base de sessions SDB peut utiliser des algorithmes de réplication de données entre bases de données afin d’assurer une haute disponibilité même en présence de pannes de bases de données individuelles comprises dans la grappe comprise dans la base de sessions SDB. Les serveurs sous-jacents à l’exécution de l’entité de gestion 100, de la base de sessions SDB et des différents serveurs SBE, SBE’, SBE’’, AS, AS’, AS’’, MGW, MGW’, MGW’’ du système SYS peuvent être des serveurs matériels du système SYS reliés entre eux par le réseau NWK ou bien, si le système SYS est déployé dans une architecture informatique en nuage (traduction de l’anglais cloud computing ), il peut s’agir de machines virtuelles (traduction de l’anglais virtual machines ) déployées à la demande sur des serveurs matériels fournis par une infrastructure en nuage (traduction de l’anglais cloud infrastructure ) ne faisant pas partie du système SYS en tant que tel. Des conteneurs (traduction de l’anglais containers ) peuvent être utilisés pour faciliter le déploiement sur une infrastructure en nuage des entités, bases de données et serveurs du système SYS de téléphonie. Des architectures mixtes du système SYS peuvent être déployées comprenant d’une part des serveurs matériels appartenant au système SYS et d’autre part des ressources d’infrastructure en dehors du système SYS, mais commandées par celui-ci pour exécuter d’autres serveurs du système SYS. Le système SYS de téléphonie sur IP comprend plusieurs types de serveurs permettant de rendre un service complet de téléphonie sur IP. Par exemple, un système de téléphonie sur IP comprend des serveurs de type annuaire (traduction de l’anglais registrar ) qui permettent d’enregistrer de nouveaux téléphones IP se connectant au système SYS ainsi que de savoir vers quels autres systèmes adresser des requêtes de téléphonie IP qui sortent du système SYS. Ces serveurs de type annuaire ne sont pas représentés sur la FIG. 1 . Un système de téléphonie sur IP va aussi comprendre des serveurs qui sont des contrôleurs de session frontalière (traduction de l’anglais session border controllers ), souvent désignés par l’acronyme SBC. Les serveurs SBC sont situés en frontière des réseaux de téléphonie sur IP et c’est eux qui assurent les communications avec des éléments à l’extérieur de ces réseaux, ou d’un réseau de téléphonie sur IP vers un autre. En particulier, les serveurs SBC sont ceux qui assurent les communications avec les terminaux, c’est-à-dire avec les téléphones IP, qui sont considérés être en dehors du réseau de téléphonie IP proprement dit. Les serveurs SBC peuvent être vus comme comprenant d’une part un composant qui gère les aspects de signalisation, nommé élément de session frontalière, souvent dénommé SBE (acronyme de l’anglais session border element ) et d’autre part un composant qui gère les aspects média, à savoir une passerelle multimédia, souvent dénommée MGW (acronyme de l’anglais media gateway ). Le système SYS de téléphonie sur IP représenté dans la FIG. 1 comprend dans notre exemple trois serveurs SBE, SBE’, SBE’’ qui sont des éléments de session frontalière du système SYS et trois serveurs MGW, MGW’, MGW’’ qui sont des passerelles multimédia. Un système de téléphonie sur IP va aussi comprendre des serveurs qui sont des serveurs d’application (traduction de l’anglais application servers ), souvent désignés par l’acronyme AS, qui rendent les différents types de service téléphoniques prévus en téléphonie sur IP. Par exemple, les serveurs AS interviennent pour gérer les services tels que le transfert d’appel, le signal d’appel, la conférence à trois, la diffusion d’une musique lors d’une sonnerie ou tout autre service de téléphonie. Le système SYS de téléphonie sur IP représenté dans la FIG. 1 comprend dans notre exemple trois serveurs AS, AS’, AS’’ qui sont des serveurs applicatifs. Le groupe GP de serveurs de traitement comprend, dans l’exemple d’architecture du système SYS représenté dans la FIG. 1 , les serveurs qui sont des éléments de session frontalière, à savoir les serveurs SBE, SBE’, SBE’’ mais cette répartition n’est qu’un exemple de réalisation et n’est pas systématique dans tous les exemples de réalisation de l’invention. Ici, dans l’exemple de la FIG. 1 , tous les serveurs SBE appartiennent au groupe GP parmi lequel les requêtes RQ(V) de téléphonie sur IP vont être attribuées. Comme les serveurs SBE sont ceux qui sont en charge des requêtes qui entrent dans le système SYS de téléphonie sur IP, en provenance des téléphones IP tels que TEL1 ou bien en provenance d’autres réseaux de téléphonie IP, cela veut dire que, pour toutes les requêtes entrant dans le système SYS, l’invention va être mise en œuvre et une attribution va être faite requête par requête aux serveurs SBE, même à l’intérieur d’une seule session de téléphonie sur IP, alors que ce ne sera pas le cas pour les requêtes à destination des serveurs applicatifs AS ou des passerelles multimédia MGW. Cependant, ce mode de réalisation n’est qu’un mode de réalisation possible parmi d’autres. Par exemple, l’invention peut être réalisée uniquement pour les requêtes au sein du système SYS à destination des serveurs d’application AS, ou bien pour un groupe GP regroupant les serveurs frontaliers SBE et les serveurs d’application AS. De même, l’invention peut aussi s’appliquer à un groupe regroupant les passerelles multimédia MGW. Le fonctionnement de l’invention, dans l’exemple de réalisation représenté dans la FIG. 1 , est le suivant. Le téléphone IP TEL1 émet, à destination du système SYS de téléphonie sur IP, une requête de téléphonie sur IP RQ(V). Cette requête sera, en général, une requête selon le protocole SIP qui est très largement utilisé dans le domaine de la téléphonie IP. Cependant, il peut s’agir d’une requête selon le protocole H.323, qui est également utilisé en téléphonie IP, ou bien il peut s’agir d’une requête selon un autre protocole, qui peut être par exemple une évolution future du protocole SIP, ou un autre protocole remplaçant de SIP à terme. Comme il est de coutume pour les requêtes de protocoles de communication, le contenu de la requête RQ(V) peut être séparé entre un en-tête, traduction de l’anglais header , qui comprend des données utilisées par le protocole de communication et une charge utile, traduction de l’anglais payload , qui comprend les données transmises à d’autres participants au protocole. Ces notions d’en-tête et de charge sont communes dans le domaine des protocoles de communication et pas limitées au domaine de la téléphonie sur IP. La requête RQ(V) comprend une valeur V prise par un champ donné de l’en-tête de la requête. La requête RQ(V) est émise par le téléphone IP TEL1 à destination du système SYS de téléphonie sur IP en utilisant le réseau de communication NWK. La requête RQ(V) est reçue par l’entité de gestion 100 au niveau du module 101 de réception. L’entité de gestion 100 peut être par exemple un routeur qui a la charge de router les communications IP en entrée du système SYS de téléphonie sur IP. L’entité de gestion 100 peut comprendre un système d’équilibrage de charge, un serveur de nom de domaine DNS, ou bien un mécanisme d’adresse IP virtuelle. Les téléphones IP traités par le système SYS, plutôt que d’être affectés à un serveur SBE fixe, ont la connaissance d’une adresse IP ou d’un nom de domaine qui orientera leurs requêtes RQ (V) vers le module de réception 101 de l’entité de gestion 100. L’utilisation du serveur DNS ou le mécanisme d’adressage virtuel IP va alors sélectionner, à partir de l’adresse IP ou du nom de domaine initial de la requête RQ(V), un serveur SBE appartenant au groupe GP de serveurs de traitement. Le serveur SBE est alors le serveur attribué pour traitement de la requête RQ(V). Cette sélection est réalisée par le module de sélection 102 de l’entité de gestion 100. Cette sélection cherchera à réaliser un équilibrage de charge afin que les serveurs du groupe GP ne soient pas surchargés par un trop-plein de requêtes à traiter à un moment donné. L’équilibrage de charge pourra être réalisé par un tirage aléatoire, ou en utilisant un algorithme du tourniquet (traduction de l’anglais round-robin ), ou toute autre technique appropriée. Une fois la sélection réalisée, l’entité de gestion 100 transmet, grâce au module de transmission 103, la requête à traiter RQ(V), pour traitement, au serveur attribué SBE. Le serveur attribué SBE reçoit la requête RQ(V) grâce au module 201 de réception. Le serveur attribué SBE va alors lire dans la base de sessions SDB une information INF. Cette lecture est réalisée par le module 202 de lecture. Cette information INF sera utilisée pour le traitement de la requête RQ(V) par le module 203 de traitement. Dans l’exemple de réalisation représenté dans la FIG. 1 , le traitement consiste dans la transmission de la requête RQ(V) au serveur applicatif AS’. L’adresse du serveur applicatif AS’, qui permet au serveur SBE de réaliser cette transmission peut être par exemple l’information INF lue précédemment. Dans des exemples de réalisation, la requête RQ(V) comprend un champ, par exemple un champ d’en-tête, qui prend une valeur V donnée telle que cette valeur V est la même pour la requête à traiter RQ(V) et pour une requête précédente qui a eu lieu dans la même session de téléphonie sur IP. Cette valeur V est utilisée comme clé pour retrouver l’information INF utile au traitement de la requête RQ(V) dans la base de sessions SDB. Par exemple, dans le protocole SIP, une requête SIP va comprendre dans son en-tête des champs From: et To: qui prennent pour valeurs les adresses des émetteurs et destinataires des requêtes. Ces valeurs vont être les mêmes dans une session donnée de téléphonie sur IP. Cependant, ces valeurs ne suffisent pas à retrouver une session en cours puisque des mêmes émetteurs et destinataires peuvent avoir réalisé plusieurs sessions successives et même avoir des sessions de téléphonie en parallèle. Le champ Call-ID: va quant à lui identifier un dialogue SIP. Cette notion de dialogue permet de retrouver des requêtes précédentes à la requête à traiter dans une session de téléphonie IP en cours, mais pas la totalité des requêtes de la session en cours. En effet, en SIP, les serveurs de traitement sont en général des serveurs dits B2BUA, acronyme anglais pour back to back user agent . Cela veut dire qu’un serveur de traitement, quand il reçoit une requête depuis un premier terminal, va créer un nouveau dialogue avec un autre terminal et adosser ce nouveau dialogue créé avec le dialogue déjà existant entre le premier terminal et le serveur de traitement. Une session de téléphonie IP en SIP se trouve alors comprendre au moins deux dialogues, les requêtes appartenant à un même dialogue ayant la même valeur pour le champ Call-ID: . Quand la valeur V est celle prise par le champ Call-ID: , elle permet de retrouver les informations INF des requêtes d’une session donnée appartenant à un même dialogue, par exemple celles entre le serveur de traitement SBE et un téléphone IP TEL1 donné. Mais les requêtes correspondant aux autres dialogues de la même session n’ont pas la même valeur de champ Call-ID: . L’information INF peut cependant être retrouvée dans la base de sessions SDB si, lorsqu’un nouveau dialogue appartenant à une session donnée est créé, la correspondance entre l’identifiant Call-ID: du premier dialogue et celui du dialogue créé est enregistrée dans la base de sessions SDB. Dans la majorité des modes de réalisation, le serveur de traitement SBE comprend un module 204 (non représenté dans la FIG. 1 ) d’enregistrement dans la base de sessions SDB d’une information INF’ (non représentée dans la FIG. 1 ) relative au traitement que vient de réaliser le serveur de traitement SBE. Cette information peut être par exemple l’adresse du serveur AS’ auquel la requête RQ(V) vient d’être transféré pour traitement ultérieur, afin de pouvoir contacter de nouveau le même serveur AS’ lors du traitement d’une requête ultérieure. Cela peut être un identifiant de dialogue Call-ID: qui vient d’être créé afin que la base de sessions SDB puisse faire le lien entre tous les dialogues appartenant à une session de téléphonie IP en cours et puisse fournir toutes les informations utiles à partir d’une seule valeur V prise par un champ Call-ID: . Dans d’autres modes de réalisation, le protocole utilisé par le système SYS de téléphonie sur IP n’est pas le protocole SIP ou bien est une évolution du protocole SIP. Dans une telle évolution, il est possible de définir un champ qui correspondrait à l’identification d’une session de téléphonie et non plus seulement d’un dialogue entre un serveur et un terminal ou entre deux serveurs. Par exemple, il est possible de définir des champs ad hoc dans certaines implémentations de SIP, en utilisant un intitulé de champ dont ‘X’ est la lettre initiale. Un tel champ ad hoc peut être un identifiant de session. L’utilisation d’un identifiant de session simplifierait la mise en œuvre des procédés selon l’invention en permettant de retrouver l’ensemble des informations INF pertinentes dans la base de sessions SDB en utilisant la valeur V prise par ce champ comme clé d’interrogation dans la base de sessions SDB. Dans l’exemple présenté dans la FIG. 1 , seuls des serveurs SBE appartiennent au groupe GP de serveurs de traitement pour lesquels les requêtes RQ sont attribuées de façon dynamique par l’entité de gestion 100. Il est possible d’imaginer une réalisation dans laquelle une autre entité de gestion attribuerait les requêtes à destination des serveurs d’application AS ou des passerelles multimédia MGW selon le même principe. La FIG. 2 , quant à elle, représente un exemple d’échanges de messages réalisés lors d’une session de téléphonie sur IP établie en utilisant les procédés selon l’invention. L’exemple représenté dans la FIG. 2 est une version simplifiée d’échange de messages en utilisant le protocole SIP. Dans cet exemple, le téléphone IP TEL1 émet une requête SIP Invite INV pour initier une session de communication en téléphonie sur IP. En l’occurrence, le téléphone IP TEL1 souhaite appeler le téléphone IP TEL2. Le téléphone TEL1 adresse la requête INV à l’entité de gestion 100 qui est par exemple un routeur en entrée du système SYS de téléphonie IP. Le téléphone TEL1 n’a donc pas à connaître un serveur frontalier qui lui serait dédié, mais simplement une adresse IP correspondant au routeur en entrée du système SYS. Comme vu précédemment, l’entité de gestion 100 va attribuer la requête INV à un des trois serveurs de traitement SBE, SBE’, SBE’’ qui appartiennent au groupe GP de serveurs de traitement. En l’occurrence, l’entité de gestion 100 transmet la requête INV au serveur de traitement SBE. Le serveur de traitement SBE va alors réaliser une opération de lecture RD d’information dans la base de sessions SDB qui appartient au système SYS, en plus du groupe GP des serveurs de traitement SBE, SBE’, SBE’’. En l’occurrence, comme la requête INV est la requête initiale d’une session de téléphonie IP, il n’y aura pas d’information à lire dans la base de sessions SDB correspondant à cette session. Le serveur SBE va alors procéder au traitement proprement dit de la requête INV. Ce traitement comprend d’une part le transfert de la requête INV vers le téléphone IP TEL2, qui est le téléphone IP que le téléphone IP TEL1 souhaite appeler et d’autre part le transfert de la requête INV vers la passerelle multimédia MGW. Cette dernière appartient elle aussi au système SYS de téléphonie IP, sans appartenir au groupe GD des serveurs SBE, SBE’, SBE’’. La passerelle MGW va alors procéder à la création d’une partie d’un canal multimédia, attachée au téléphone IP TEL1, représenté dans la FIG. 2 par deux traits épais. Cette partie, attachée au téléphone IP TEL1, sera complétée par une partie attachée au téléphone IP TEL2 pour former la liaison téléphonique proprement dite entre les deux téléphones IP TEL1 et TEL2. L’établissement final de la liaison téléphonique, en dehors de la signalisation proprement dite, et le transport de données à l’intérieur de la liaison se fait classiquement en utilisant le protocole RTP. Après avoir procédé à ce traitement de la requête INV, le serveur SBE va procéder à l’enregistrement WT dans la base de sessions SDB d’informations relatives à la session en cours afin de faciliter les traitements ultérieurs. Les informations enregistrées WT vont par exemple comprendre les adresses et identités des serveurs (ici SBE et MGW) qui participent au traitement de la requête INV. Les identités et adresses des téléphones concernés par la requête (ici TEL1 et TEL2) peuvent être également enregistrées. De plus, la valeur prise par le champ Call-ID sera également enregistré, et même servira de clé dans la base de données SDB, dans plusieurs modes de réalisation, pour retrouver les informations pertinentes enregistrées. Si le serveur SBE, pour traiter la requête INV, est emmené à créer un nouveau dialogue, ce qui est usuel quand le serveur SBE est utilisé dans un mode B2BUA (mode dos à dos, ou back to back user agent ), il pourra enregistrer WT dans la base de sessions SDB une association entre la valeur du champ Call-ID de la requête initiale et celle du champ Call-ID du nouveau dialogue créé. De cette manière, quand un autre serveur traitera une nouvelle requête qui a trait à ce dialogue créé, la consultation de l’association enregistrée dans la base de sessions SDB lui permettra de récupérer la valeur du champ Call-ID du premier dialogue et donc également les informations pertinentes des requêtes de ce premier dialogue. Ces informations sont utiles car le premier dialogue et les dialogues suivants font bien partie de la même session de téléphonie sur IP. Le téléphone IP TEL2, de son côté, reçoit la requête INV transmise par le serveur SBE. Le téléphone IP TEL2 va alors procéder à des actions non représentées sur la FIG. 2 . Par exemple, il va émettre une sonnerie à destination de son utilisateur. Si celui-ci décroche et accepte la communication, le téléphone IP TEL2 va émettre une requête OK. Cette requête est adressée à l’entité de gestion 100. Celle-ci va attribuer cette requête OK pour traitement à un serveur de traitement dans le groupe GP, en l’occurrence le serveur de traitement SBE’. On vient que, pour une même session de téléphonie IP, deux serveurs de traitement distincts sont sollicités. Le serveur de traitement SBE’ va alors lire RD dans la base de sessions SDB les informations pertinentes pour réaliser le traitement de la requête OK. Une telle information peut être par exemple une adresse lui permettant de contacter la passerelle multimédia MGW qui a été sollicitée précédemment dans la session. Le traitement par le serveur SBE’ va alors comprendre le transfert de la requête OK d’une part au téléphone IP TEL1 et d’autre part à la passerelle multimédia MGW. Cette dernière va procéder au traitement attendu qui consiste à compléter la liaison téléphonique proprement dite, dont une partie avait déjà été construite, attachée au téléphone IP TEL1. La passerelle multimédia MGW construit ici la partie attachée au téléphone IP TEL2 et connecte ces deux parties de liaison. La liaison téléphonique ainsi construite peut porter le signal de parole entre les téléphones IP TEL1 et TEL2, signal représenté par la courbe sinusoïde entre les deux traits épais. Autrement dit, à ce stade, un appel téléphonique prend place entre les téléphones IP TEL1 et TEL2, appel dont la mise en place a nécessité l’intervention de deux serveurs distincts de traitement SBE et SBE’ alors qu’en téléphonie IP standard, un seul serveur de traitement interviendrait pour une session donnée. Le serveur de traitement SBE’ va alors enregistrer WT dans la base de sessions SDB les informations pertinentes pour les traitements ultérieurs de la session de téléphonie IP en cours. Le téléphone IP TEL1 va alors adresser une requête BYE. Cette requête correspond à une action de raccrochement de la part de l’utilisateur du téléphone IP TEL1. La requête BYE est adressée par le téléphone TEL1 à l’entité de gestion 100. Celle-ci va attribuer la requête BYE à un serveur de traitement appartenant au groupe GP, en l’occurrence le serveur de traitement SBE’’. Finalement, trois serveurs de traitement distincts appartenant au groupe GP auront été sollicités pour réaliser le traitement des requêtes de la session de téléphonie décrite ici. Le serveur de traitement SBE’’ va lire RD dans la base de sessions SDB les informations nécessaires au traitement de la requête BYE. Ce traitement consiste dans le transfert de la requête BYE vers le téléphone IP TEL2 d’une part et vers la passerelle multimédia MGW d’autre part. Celle-ci va détruire la liaison téléphonique établie entre TEL1 et TEL2, ce qui est représenté par une croix sur le symbole de la liaison construit précédemment. La passerelle MGW va ainsi récupérer les ressources matérielles, mémoire ou énergétiques qui étaient mobilisées par la mise en place de la liaison téléphonique IP entre les téléphones TEL1 et TEL2. Le serveur SBE’’, après son traitement, réalise un enregistrement WT d’informations pertinentes dans la base de sessions SDB. La session de téléphonie IP entre les deux téléphones TEL1 et TEL2 est ainsi achevée et a vu intervenir trois serveurs différents de traitement SBE, SBE’ et SBE’’ pour le traitement de la signalisation, au lieu d’un serveur unique en charge de la session. Ces serveurs SBE, SBE’ et SBE’’ sont des serveurs sans état qui utilisent des informations présentes dans la base de sessions SDB pour effectuer les traitements demandés. La FIG. 3 , quant à elle, représente un autre exemple d’architecture d’un système SYS de téléphonie sur IP selon l’invention. Dans cet exemple d’architecture du système SYS, les serveurs de traitement du système SYS sont répartis dans trois groupes GP, GP’ et GP’’, à l’exclusion des passerelles multimédia MGW, MGW’, MGW’’ ainsi que d’un serveur d’annuaire RGR. Le premier groupe GP comprend un nombre variable de serveurs SBE, SBE’, SBE’’. La présence de trois points symbolise la variation dans le temps du nombre de serveurs de ce groupe. Les serveurs de ce groupe GP sont des éléments de session frontalière. Ce sont, dans cet exemple, les serveurs qui ont la charge de traiter les requêtes issues des téléphones IP d’un parc traité par le système SYS, et également de leur adresser des requêtes. Le groupe GP de serveurs de traitement dispose d’une base de sessions SDB ainsi que d’un routeur RTR. Le routeur RTR, dans cet exemple d’architecture, remplit le rôle d’une entité de gestion qui va attribuer les requêtes une par une aux serveurs du groupe GP. La base de sessions SDB est, dans cet exemple d’architecture, dédiée aux demandes d’information de la part des serveurs SBE, SBE’, SBE’’. Le nombre de serveurs SBE, SBE’, SBE’’ est variable dans le temps. Comme les serveurs ont la charge de traiter les requêtes issues des téléphones IP du parc géré par le système SYS, les besoins sont moins élevés en période nocturne par exemple. Dans ce cas, la variation dans le temps du nombre de serveurs SBE, SBE’, SBE’’ permet de réaliser des économies de ressources. Le deuxième groupe GP’ comprend également des serveurs SBE’’’, SBE’’’’, SBE’’’’’, à savoir des éléments de session frontalières, mais ces serveurs, dans cet exemple, sont chargés de recevoir et transmettre des requêtes de téléphonie vers d’autres systèmes de téléphonie. Par exemple, une requête d’appel issue depuis un téléphone TEL1 (non représenté dans la figure) du parc géré par le système SYS vers un téléphone TEL2 (non représenté) en dehors de ce parc pourra être traitée de la manière suivante : Une requête issue du parc de téléphones IP géré par le système SYS, comme toutes les requêtes issue du parc de téléphones, est adressée au routeur RTR qui l’attribue à un serveur SBE, SBE’, SBE’’ du groupe GP ; La requête est attribuée par le routeur RTR au serveur SBE du groupe GP ; Celui-ci consulte le serveur d’annuaire RGR qui lui indique que le téléphone TEL2 n’est pas géré par le système SYS ; Il adresse alors la requête au groupe GP’, regroupant les serveurs SBE en charge de communiquer avec les autres systèmes de téléphonie sur IP ; A la fin du traitement par le serveur SBE, celui-ci inscrit dans la base de sessions SDB des informations pertinentes pour les traitements ultérieurs, par exemple l’association entre le dialogue SIP initié par le téléphone TEL1 et le dialogue SIP initié par le serveur SBE pour transmettre la requête vers un téléphone TEL2 externe ; Le routeur RTR’, en entrée du groupe GP’, attribuera alors la requête à un serveur, par exemple SBE’’’, du groupe GP’, qui la traitera en l’adressant à l’extérieur du système SYS ; Le serveur SBE’’’ inscrira dans la base de sessions SDB’ les informations qui permettront, quand un autre serveur du groupe GP’ recevra la réponse à sa requête transmise, de la retransmettre vers le routeur RTR du groupe GP et en général de retrouver dans la base SDB’ les informations nécessaires au traitement de la réponse ; Quand le routeur RTR recevra une requête en retour, il l’attribuera à un serveur du groupe GP, qui n’a aucune raison a priori d’être le serveur SBE qui a traité la requête initiale ; si ce serveur est par exemple SBE’, il interrogera la base de sessions SDB afin de retrouver les informations pertinentes, par exemple l’association entre dialogues créée par le serveur SBE dans le traitement de la requête initiale. Les serveurs du groupe GP’ sont également en nombre variable afin d’économiser des ressources quand il est probable que le nombre de requêtes va diminuer ou augmenter. Le troisième groupe GP’’, quant à lui, comprend les serveurs d’application AS, AS’, AS’’, là aussi en nombre variable. Les serveurs d’application AS, AS’, AS’’ regroupés dans le groupe GP’’ ont la charge de traiter les requêtes ayant trait aux services de téléphonie, par exemple les appels à trois, conférences téléphoniques, transferts d’appel ou autres. Traditionnellement, ces serveurs sont différenciés et dédiés chacun à un service donné. Cette organisation réserve donc des ressources par avance puisque, pour chaque service, il faut disposer d’au moins un serveur dédié. Avec dans notre exemple des serveurs indifférenciés pour traiter les services de téléphonie, en nombre variable, regroupés dans le groupe GP’’, il est possible de réaliser des économies fortes en ressources énergétiques et matérielles. Lorsque, dans le traitement d’une requête, il est nécessaire de solliciter un des serveurs AS, celle-ci est adressée au routeur RTR’’ en entrée du groupe GP’’ qui va réaliser l’attribution de la requête à un serveur AS, AS’ ou AS’’ parmi le groupe GP’’. Le serveur attribué utilisera alors, dans notre exemple, la base de sessions SDB’’ pour lire les informations pertinentes au traitement de la requête et enregistrer si nécessaire des informations pertinentes au traitement de requêtes ultérieures dans la session. Dans notre exemple, les passerelles multimédia MGW, MGW’, MGW’’ ne sont pas regroupées dans un groupe dédié. Elles sont donc affectées à la création de liaisons téléphoniques pour un parc donné. Ce mode de fonctionnement, proche du mode actuel, peut se justifier par la nature des traitements réalisés par les passerelles multimédia qui sont davantage attachées aux équipements matériels du parc que ne le sont les autres serveurs de traitement. Il en est de même pour le serveur d’annuaire RGR. L‘invention permet donc de construire des architectures mixtes d’un système SYS de téléphonie sur IP où des serveurs peuvent être regroupés dans des groupes GP, GP’, GP’’ et organisés en ensembles de taille variable afin de s’adapter au mieux aux variations de la demande et où d’autres serveurs seront conservés en nombre fixe, affectés à des éléments matériels, et ceci selon la nature des tâches réalisées par les serveurs de traitement. On peut cependant aussi utiliser l’invention dans une architecture dans laquelle tous les serveurs de traitement sont regroupés ensemble, sont indifférenciés, et réalisent des traitements différenciés en appelant des programmes spécialisés à des traitements donnés. Une telle architecture, rendue possible par l’invention, a l’intérêt d’utiliser un matériel indifférencié pour tous les serveurs et des techniques de déploiement et de variation des serveurs selon la charge non spécifiques au domaine de la téléphonie sur IP. D’autres architectures intermédiaires sont possibles où, par exemple, les serveurs de session frontalière SBE sont regroupés en un seul groupe et ne sont pas différenciés, comme dans notre exemple, entre serveurs dédiés aux relations avec les téléphones du parc d’une part et aux relations avec les autres systèmes de téléphonie d’autre part. Signalons enfin ici que, dans le présent texte, le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Procédé de gestion par une entité de gestion (100) de l’attribution à un serveur de traitement, appartenant à un groupe (GP) de serveurs, de requêtes (RQ) de téléphonie sur IP, dites requêtes à traiter, appartenant à une même session de téléphonie sur IP, dite session en cours, caractérisé en ce que, durant la session en cours, une réception d’une requête à traiter (RQ) déclenche une sélection d’un serveur de traitement (SBE) dans le groupe (GP) de serveurs, et en ce que la requête à traiter (RQ) est transmise au serveur sélectionné (SBE), dit serveur attribué, pour traitement. Procédé de gestion selon la revendication 1 caractérisé en ce que la requête à traiter (RQ) inclut un champ qui prend une valeur (V), dite valeur clé, qui est égale à la valeur prise par le même champ d’une précédente requête à traiter appartenant à la session en cours, et en ce que la requête à traiter (RQ) transmise au serveur attribué (SBE) inclut la valeur clé (V). Procédé de gestion selon la revendication 1 caractérisé en ce que le nombre de serveurs de traitement appartenant au groupe (GP) de serveurs varie dans le temps. Procédé de gestion selon la revendication 1 caractérisé en ce que la requête à traiter (RQ) est issue d’un téléphone IP (TEL1) et le serveur attribué (SBE) est sélectionné par l’entité de gestion (100) indépendamment dudit téléphone IP (TEL1). Procédé de gestion selon la revendication 1 caractérisé en ce que les requêtes à traiter (RQ) incluent des champs qui prennent un ensemble de valeurs (V) et en ce que le serveur attribué (SBE) est sélectionné par l’entité de gestion (100) indépendamment des dites valeurs (V). Procédé de gestion selon la revendication 1 caractérisé en ce que le serveur attribué (SBE) est sélectionné par l’entité de gestion (100) de manière à répartir la charge de traitement entre les différents serveurs du groupe (GP) et en ce que l’entité de gestion (100) est un équilibreur de charge. Procédé de gestion selon la revendication 2 caractérisé en ce que la valeur clé (V) est identique pour toutes les requêtes à traiter (RQ) appartenant à la même session de téléphonie IP. Procédé de traitement d’une requête (RQ) de téléphonie sur IP, dite requête à traiter, appartenant à une session de téléphonie sur IP, dite session en cours, par un serveur de traitement (SBE), dit serveur attribué, appartenant à un groupe (GP) de serveurs, caractérisé en ce que le procédé comprend les étapes suivantes : Réception de la requête à traiter (RQ) transmise par une entité de gestion (100) en charge de l’attribution des requêtes à traiter de la session en cours ; Lecture dans une base de données (SDB), dite base de sessions, d’une information (INF) relative à la session en cours ; Traitement de la requête à traiter (RQ) en utilisant l’information (INF) lue. Procédé de traitement selon la revendication 8 caractérisé en ce que la requête à traiter (RQ) inclut un champ qui prend une valeur (V), dite valeur clé, qui est égale à la valeur prise par le même champ d’une précédente requête à traiter appartenant à la session en cours et en ce que l’information (INF) lue dans la base de sessions (SDB) est accessible grâce à la valeur clé (V). Procédé de traitement selon la revendication 8 caractérisé en ce que le nombre de serveurs de traitement appartenant au groupe (GP) de serveurs varie dans le temps. Procédé de traitement selon la revendication 9 caractérisé en ce que le procédé comprend de surcroît une étape d’enregistrement dans la base de sessions (SDB) d’une information (INF) relative au traitement par le serveur attribué (SBE) de la requête à traiter (RQ), ladite information (INF) étant accessible grâce à la valeur clé (V). Entité de gestion (100) apte à réaliser un procédé de gestion de l’attribution à un serveur de traitement (SBE), appartenant à un groupe (GP) de serveurs, de requêtes (RQ) de téléphonie sur IP, dites requêtes à traiter, appartenant à une même session de téléphonie sur IP, dite session en cours, caractérisé en ce que l’entité de gestion (100) comprend : Un module (101) de réception d’une requête à traiter (RQ) ; Un module (102) de sélection d’un serveur de traitement (SBE) dans le groupe (GP) de serveurs ; Un module (103) de transmission d’une requête à traiter (RQ) ; et en ce que, durant la session en cours, une réception par le module (101) de réception d’une requête à traiter (RQ) déclenche une sélection par le module (102) de sélection d’un serveur de traitement (SBE) dans le groupe (GP) de serveurs, et en ce que la requête à traiter est transmise par le module (103) de transmission au serveur sélectionné (SBE), dit serveur attribué, pour traitement. Serveur de traitement (SBE) d’une requête (RQ) de téléphonie sur IP, dite requête à traiter, appartenant à une session de téléphonie sur IP, dite session en cours, ledit serveur de traitement (SBE) appartenant à un groupe (GP) de serveurs, caractérisé en ce que le serveur (SBE) comprend les modules suivants : Un module (201) de réception de la requête à traiter (RQ) transmise par une entité de gestion (100) en charge de l’attribution des requêtes à traiter de la session en cours ; Un module (202) de lecture dans une base de données (SDB), dite base de sessions, d’une information (INF) relative à la session en cours ; Un module (203) de traitement de la requête à traiter (RQ) en utilisant l’information (INF) lue. Programme d’ordinateur apte à être mis en œuvre par une entité de gestion (100), le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion selon la revendication 1. Programme d’ordinateur apte à être mis en œuvre par un serveur de traitement (SBE) d’une requête (RQ) de téléphonie sur IP, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de traitement selon la revendication 9.