FR 2983375 A1 20130531 FR 1160957 A 20111130 Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement la gestion de requêtes émises par des dispositifs tels qu'un terminal ou une passerelle domestique en vue d'un enregistrement de ces dispositifs sur un coeur de réseau de voix sur IP (Internet Protocol). L'invention s'applique notamment de façon privilégiée mais non limitative à un coeur de réseau IMS (IP Multimedia Subsystem) tel que défini par le standard 3GPP (Third Generation Partnership Project), mettant en oeuvre le protocole SIP (Session Initiation Protocol). Toutefois l'invention s'applique également à d'autres architectures de coeur de réseau de voix sur IP (ou VoIP pour Voice over IP) telle que par exemple un coeur de réseau H323 ou REGISTRAR SIP, ainsi qu'à des coeurs de réseau mettant en oeuvre d'autres protocoles applicatifs de voix sur IP tels que le protocole XMPP (eXtensible Messaging and Presence Protocol) ou des protocoles propriétaires. Quel que soit le protocole applicatif de voix sur IP considéré, le fonctionnement du coeur de réseau est globalement le même. Suite à son démarrage, un dispositif VoIP s'enregistre auprès du coeur de réseau en lui envoyant une requête d'enregistrement, qui comprend notamment un identifiant (ou identité) public(que) et une adresse de contact du dispositif. L'identifiant public du dispositif est par exemple un numéro de téléphone VoIP, une adresse électronique ou une adresse SIP (URI, Uniform Request Identifier), utilisé(e) par le public pour joindre le dispositif. Il peut s'agir notamment de l'identité publique IMPU (IP Multimedia PUblic identity) pour un coeur de réseau IMS. Cet identifiant public peut être partagé par plusieurs dispositifs ; ceux-ci disposent en outre d'un identifiant (ou identité) privé(e) (ex. IMPI (IP Multimedia Private Identity) pour un coeur de réseau IMS), qui peut être le même pour chacun de ces dispositifs ou un groupe de dispositifs, ou en variante distinct pour chaque dispositif. L'adresse de contact du dispositif correspond à son adresse de joignabilité dans le domaine IP, et comprend notamment de façon connue, l'adresse IP du dispositif, un numéro de port associé à sa pile Vo:P ainsi que le protocole de transport r,eee UDP (User Data Protocc), TCP (Transport Centroi Protoco!), - (Tranr,eorl Layer Security., utlis p dispositif pour comniuniquer, Lo corre;:91dance entre Vicientn el son adresse de contaet35 détermine à l'aide de l'identifiant public l'adresse de contact du dispositif. Le coeur de réseau VoIP renvoie alors la communication vers cette adresse de contact. Généralement, le dispositif VoIP s'enregistre auprès du coeur de réseau avec son adresse de contact une première fois lors de son démarrage (on parle alors d'enregistrement initial), puis se réenregistre avec cette même adresse de contact (on parle alors d'enregistrement subséquent), par exemple périodiquement avec une période d'une heure. Il est par ailleurs prévu qu'une requête de désenregistrement soit envoyée par le dispositif au coeur de réseau, lorsqu'il est éteint proprement. Toutefois, différents types d'incidents peuvent amener un dispositif VoIP à changer d'adresse de contact courante, sans pour autant qu'il puisse auparavant se désenregistrer proprement auprès du coeur de réseau (i.e. via l'envoi d'une requête de désenregistrement au coeur de réseau). C'est le cas par exemple : - après un redémarrage automatique du dispositif suite à une anomalie de fonctionnement de celui-ci ou à l'échec d'un processus dans le dispositif ; après une déconnexion de la ligne physique reliant le dispositif au réseau ; pour un accès IP de type ADSL (Asynchronous Digital Subscriber Line), après une perte de synchronisation ADSL ; suite à un changement de réseau ou dans une situation de roaming pour des dispositifs conformes au standard LTE (Long Term Evolution) ; etc. Suite au changement de son adresse de contact courante, le dispositif doit informer le coeur de réseau VoIP de sa nouvelle adresse, et ce, afin de rester joignable. A cette fin, il transmet au coeur de réseau une requête d'enregistrement contenant son identifiant public et sa nouvelle adresse de contact courante. Diverses politiques peuvent être mises en oeuvre par l'exploitant du coeur de réseau de voix sur IP pour gérer les requêtes d'enregistrement reçues, comme par exemple : aucun contrôle, c'est-à-dire que toutes les requêtes d'enregistrement sont acceptées (jamais utilisé en pratique) ; un contrôle basé sur l'utilisation d'une (ou de plusieurs) file(s) d'attente associée(s) à la t,:ti)le l'enregistrement et fonctionnant selon un mode de type FIFO (ex. une file d'attente par _titrlfrant pu t_tir une file d'attente associée à un couple (identifiant public, identifiant priv Hus précisémeut : o pour une 'Re de Lut nouve e reçut-35 s'ajouter aux adresses de contact présentes dans la table d'enregistrement associée à l'identifiant public contenu dans la requête. Si la file est pleine (autrement dit si la capacité maximale d'enregistrement pour l'identifiant public ou pour le couple formé par l'identifiant public et l'identifiant privé est atteinte), le coeur de réseau accepte la requête et enregistre la nouvelle adresse de contact dans la table d'enregistrement en remplacement de l'adresse de contact la plus ancienne enregistrée ou ayant la durée d'expiration d'enregistrement courante la plus faible ; un blocage : dès que la capacité maximale d'enregistrement pour un identifiant public donné est atteinte, le coeur de réseau rejette toute requête d'enregistrement arrivant pour cet identifiant 10 public. Un contrôle des requêtes d'enregistrement basé sur une configuration de la table d'enregistrement en une ou plusieurs files d'attente en mode FIFO de taille 1 est généralement adopté par les opérateurs de cceurs de réseau VoIP. Toutefois, ce type de contrôle présente des limites et ne peut pas être envisagé 15 notamment lorsque l'opérateur du coeur de réseau souhaite mettre en place des mécanismes visant à préserver l'enregistrement de certains dispositifs considérés comme prioritaires (par exemple parce que le désenregistrement de ces dispositifs pourrait entrainer un dysfonctionnement gênant pour l'utilisateur telle qu'une perte de ses services VoIP). Pour illustrer ce cas de figure, considérons par exemple une passerelle domestique GW 20 associée à une adresse de contact AoC1, et qui partage un même identifiant public IMPU avec un terminal P (ex. mobile ou tablette équipé(e) d'un logiciel applicatif VoIP aussi connu sous le nom de « softphone »), le coeur de réseau étant configuré pour accepter au maximum deux enregistrements simultanés associés à ce même identifiant public IMPU (c'est-à-dire a priori un enregistrement pour la passerelle et un enregistrement pour le terminal). On suppose par ailleurs 25 d'une part, que la table d'enregistrement (i.e. la file d'attente) maintenue par le coeur de réseau pour l'identifiant public IMPU contient dans un premier temps uniquement l'adresse de contact AoC1 de la passerelle GW, et que d'autre part, le coeur de réseau est configuré de sorte à éviter l'éjection de la passerelle GW de la file d'attente lorsqu'un dispositif (par exemple le terminal P) émet une requête d'enregistrement aupK?s du coeur de réseau avec ce renie identifiant public 30 IMPU et une adresse de contact non encore enreciisinn.2 et que In file cVnrtU2n,te est pleine. Supposons maintenant qu'un redémarrage do passerelle domestique GW a lieu avant même ile-d n'ait pu 7Pprenient du coeur de réseau, et qu'a (J5_11E--rage, |a dOrlle---;tECILIC: / ne nOliv(2re adri.:ESSe (le contact courante , rr;»11'-.:tr, 35 Autrement dit, suite au redémarrage brutal de la passerelle, la file d'attente associée à l'identifiant public IMPU contient l'ancienne adresse de contact AoC1 (maintenant inactive, c'est-à-dire qui n'est plus utilisée pour la passerelle GVV) et la nouvelle adresse de contact AoC1' de la passerelle GVV. La capacité maximale d'enregistrement pour l'identifiant public IMPU est donc atteint. Dans l'état actuel de la technique, lorsque le coeur de réseau reçoit une requête d'enregistrement correspondant à un identifiant public déjà enregistré dans ses tables d'enregistrement, il n'est pas capable de distinguer si cette requête provient d'un dispositif déjà enregistré dans ses tables mais sous une adresse de contact différente ou si elle provient d'un 10 autre dispositif (potentiellement interdit) cherchant à s'enregistrer auprès du coeur de réseau et partageant cet identifiant public. On comprend bien dès lors que compte tenu de la configuration de la table d'enregistrement et de la file d'attente associée, le coeur de réseau va refuser toute nouvelle requête d'enregistrement (typiquement une requête provenant du terminal P) contenant une 15 adresse de contact non encore enregistrée et l'identifiant public IMPU, de sorte à éviter l'éjection de la passerelle GVV. Le terminal P n'aura donc pas d'autre solution pour pouvoir s'enregistrer auprès du coeur de réseau que d'attendre l'expiration « automatique » de l'enregistrement rémanent (ex. une heure maximum si les dispositifs se réenregistrent toutes les heures auprès du coeur de réseau) et la suppression en découlant de l'adresse de contact AoC1 inactive de la 20 passerelle GVV de la file d'attente. En d'autres mots, le coeur de réseau refusera à tort l'enregistrement du terminal P afin de ne pas prendre le risque d'éjecter la passerelle GW de la table d'enregistrement. On comprend bien dès lors qu'une telle situation n'est pas satisfaisante pour l'utilisateur du terminal P car elle peut notamment entraîner une indisponibilité du service de voix sur IP assez longue. 25 Objet et résumé de l'invention L'invention permet notamment d'améliorer cette situation en proposant un procédé de gestion d'une requête émise par un dispositif associé à un identifiant public, en vue d'un enregistrement sur un coeur de réseau de voix sur IP d'une adresse de contact courante de ce 30 d/sposihfpcxric coeL:r de réseau, ce procecle de gestion comprenant : une , dbiD:iention, er réception de la ;Jeté, d'un nombre cracii.esses de contact enregistrées sni- le coeui: de réseau en association l'Hentifiant une on-i comnaraison de ce domiprc ( une étape d'envoi d'un message d'interrogation aux adresses de contact enregistrées sur le coeur de réseau en association avec l'identifiant public ; - si, à l'issue d'une période de temps prédéterminée, au moins une adresse de contact parmi ces adresses n'a pas répondu à ce message d'interrogation ou a été déclarée inactive en réponse audit message d'interrogation, une étape d'acceptation de la requête du dispositif ; et une étape de rejet de la requête sinon. Corrélativement, l'invention vise également un serveur de gestion d'une requête émise par un dispositif associé à un identifiant public en vue d'un enregistrement sur un coeur de réseau de voix sur IP d'une adresse de contact courante de ce dispositif sur ce coeur de réseau de voix sur IP, le serveur de gestion comprenant : - des moyens, activés sur réception de la requête, pour obtenir un nombre d'adresses de contact enregistrées sur le coeur de réseau en association avec l'identifiant public ; et - des moyens de comparaison de ce nombre avec une capacité maximale d'enregistrement définie pour cet identifiant public. Le serveur de gestion selon l'invention est remarquable en ce qu'il comprend en outre des moyens, activés lorsque le nombre d'adresses de contact enregistrées sur le coeur de réseau en association avec l'identifiant public a atteint cette capacité maximale : pour envoyer un message d'interrogation auxdites adresses de contact enregistrées en association avec ledit identifiant public ; pour accepter la requête si, à l'issue d'une période prédéterminée, au moins une adresse de contact parmi ces adresses de contact n'a pas répondu au message d'interrogation ou a été déclarée inactive en réponse audit message d'interrogation ; et pour rejeter la requête sinon. Au sens de l'invention, un enregistrement d'une adresse de contact courante d'un dispositif sur un coeur de réseau fait référence à un enregistrement initial de ce dispositif avec son adresse de contact courante sur le coeur de réseau. L'invention ne s'intéresse pas à proprement parler à la gestion des réenregistrements des dispositifs. Différents types de requêtes émises en vue d'un enregistrement (i.e. nécessaires pour un enregstrement) du dispositif auprès du coeur de réseau peuvent être gérées conformément à l'invention. Ainsi au sens de Privent parlei_e émise par un dispositif en vue d'un ...nrts!!!!!;tremert - !é coeur =seau. oo entend noldinident une requête d'enregistrement émise ;.)1. ce cspositif , pa exemp message prevu p r protocoLt mis en dispositif en préliminaire de l'enregistrement de son adresse de contact courante sur le coeur de réseau, afin notamment d'obtenir ou d'échanger des informations nécessaires à cet enregistrement. Une telle requête est par exemple un message HTTP (HyperText Transfer Protocol) Get Parameter visant à l'obtention d'un fichier de configuration VoIP par le dispositif requis pour permettre son enregistrement sur le coeur de réseau. Par ailleurs, on gérera préférentiellement à l'aide de l'invention des requêtes en vue d'un enregistrement sur le coeur de réseau d'une adresse de contact d'un dispositif qui n'est pas déjà enregistrée auprès du coeur de réseau pour l'identifiant public associé à ce dispositif (autrement dit, des requêtes émises en relation avec l'enregistrement d'une nouvelle adresse de contact associée à l'identifiant public pour le coeur de réseau). En effet, l'enregistrement d'une adresse de contact déjà enregistrée auprès du coeur de réseau alors qu'il s'agit d'un enregistrement initial du dispositif et non d'un réenregistrement, reflète la présence d'un dysfonctionnement du réseau qui sort du cadre de l'invention et que l'homme du métier saura aisément détecter et gérer de façon connue en soi. Par message d'interrogation au sens de l'invention, on entend un message qui appelle une réponse de la part de son destinataire, autrement dit, auquel le destinataire identifié dans le message répond en temps normal lorsqu'il reçoit ce message. Préférentiellement, on choisira comme message d'interrogation un message qui ne perturbe pas le déroulement des communications ou des échanges auxquels participe le cas échéant le dispositif destinataire du message d'interrogation, c'est-à-dire un message qui est transparent pour les sessions en cours du dispositif destinataire (car il s'agit par exemple d'un message géré par les couches basses protocolaires du dispositif). Un tel message est par exemple un message d'interrogation des capacités du distant, tel que notamment un message SIP OPTIONS pour un coeur de réseau mettant en oeuvre le protocole SIP ou un message AUDITENDPOINT pour un coeur de réseau mettant en oeuvre le protocole MGCP (Media Gateway Control Protocol). Ces messages sont traités par les couches basses de la pile de protocoles du dispositif destinataire et leur traitement n'a pas d'impact à proprement parler sur le déroulement des sessions en cours associées à ce dispositif, contrairerrcni à d'autres massages qui sont gérés au niveau des couches applicatives de la pile tels que par e,ernple un message SIP INVITE dont Larrivee peut se traduire notamment par une sonnerie dri cispositif. mieddes ffintelTodation peuven entendu être en', que r message SI P r,1 S un ê auciue ; ;esdnataire reperden35 adresse de contact aux dispositifs précédemment enregistrés pour ces adresses de contact. Elle permet d'éviter le rejet non justifié de requêtes d'enregistrement du fait de la présence dans les tables d'enregistrement du coeur de réseau d'adresses de contact inactives et qui n'ont pas été proprement désenregistrées. Il n'est pas nécessaire grâce à l'invention de devoir attendre l'expiration des durées d'enregistrement pour pouvoir enregistrer une nouvelle adresse de contact. L'invention permet donc de limiter la période d'indisponibilité des services VoIP offerts par un dispositif qui cherche à s'enregistrer après un changement d'adresse de contact, par exemple suite à un redémarrage inopiné. En outre, l'invention ne génère que très peu de trafic sur le réseau. En effet, un message d'interrogation n'est envoyé aux adresses de contact de la table d'enregistrement que si la capacité maximale a été atteinte. L'invention permet donc d'optimiser les ressources du coeur de réseau, en offrant une meilleure disponibilité de service de voix sur IP moyennant peu de ressources (messages échangés réduits). Elle est d'autant plus pertinente que de nombreuses situations de changement d'adresses de contact existent aujourd'hui (ex. suite au redémarrage des dispositifs) et/ou sont à prévoir dans les futurs réseaux de télécommunication (ex. en cas de basculement d'un réseau d'accès à un autre, dans des situations de nomadisme, etc.). Par ailleurs, conformément à l'invention, si l'ensemble des adresses enregistrées auprès du coeur de réseau sont actives, c'est-à-dire si avant l'expiration de la période de temps prédéterminée, l'ensemble des adresses enregistrées correspondent à des adresses de contact « courantes » de dispositifs et que toutes de ce fait répondent au message d'interrogation ou sont déclarées actives en réponse au message d'interrogation (par exemple par un équipement intermédiaire tel qu'un serveur de bordure (ou SBC pour Session Border Controller) placé en coupure de flux pour l'enregistrement au coeur de réseau entre les dispositifs et le coeur de réseau), la requête est rejetée. Il résulte du rejet de cette requête que l'enregistrement du dispositif auprès du coeur de réseau avec son adresse de contact courante n'est pas possible. L'invention permet ainsi dans une ce-l_aine mesure d'éviter qu'un dispositif qui n'a pas lieu de 30.-;'enreciistrer atipne-, du coeur do ompte-tenu la capacite d'enregistrement :permise pour un ident:f ant Pubk donné, pui.sse s'enregistre .1 prendre la place d un dispositif autc:-ise. On noiera que le procecle de Cle.;LiOil se:on l'invention )eut mis en oeuvre à divers en.dro .esea par un equipement du coeur de rdHo::»i 1u voh«: sur IP ou par un REGISTRAR pour un coeur de réseau SIP non IMS), apte à mettre à jour les tables d'enregistrement associées aux identifiants publics. En variante, il peut également être mis en oeuvre par un équipement externe au coeur de réseau (ex. un système d'information de l'opérateur VoIP) qui serait en charge par exemple de faire une présélection des dispositifs pouvant présenter une requête d'enregistrement auprès du coeur de réseau compte tenu du nombre d'adresses de contact déjà enregistrées pour un identifiant public donné, cet équipement étant apte à interroger le coeur de réseau pour obtenir ce nombre. Dans un mode particulier de réalisation de l'invention, au cours de l'étape 10 d'acceptation, l'adresse de contact courante du dispositif est enregistrée sur le coeur de réseau en association avec l'identifiant public en remplacement d'une adresse de contact n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse au message d'interrogation. Corrélativement, dans ce mode de réalisation, les moyens pour accepter la requête du serveur de gestion sont aptes à enregistrer l'adresse de contact courante du dispositif sur le coeur 15 de réseau en association avec l'identifiant public en remplacement d'une adresse de contact n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse au message d'interrogation. Ce mode de réalisation permet une mise à jour de la table d'enregistrement associée à l'identifiant public du dispositif avec son adresse de contact courante, de sorte à finaliser 20 l'enregistrement du dispositif auprès du coeur de réseau. Il a une application privilégiée notamment lorsque le procédé de gestion selon l'invention est mis en oeuvre pour la gestion de requêtes d'enregistrement par un serveur d'enregistrement du coeur de réseau apte à modifier la table d'enregistrement associée à l'identifiant public contenu dans la requête (ex. par un serveur S-CSCF dans le cas d'un coeur de 25 réseau IMS). Ainsi, par exemple, lorsque plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation, l'adresse de contact courante du dispositif peut être enregistrée en remplacement de l'adresse de contact qui correspond à la durée d'expiation d'enregistrement la plus faible parmi lesdites 30 plusieurs adresses de contact oui n'ont rf`pondu au messacie d'interrooation ou qui ont été déclarées.naci t ves en rebons(_" au messaoe d'interrogation. Il s'niolt par ce suppritiMr. de la table d'enregistrement l'adresse de. contact plus ancienne panni i.e. inactives). 35 Pour un coeur de réseau VOIP mettant en oeuvre le protocole SIP, cette priorité peut être par exemple déterminée à l'aide du champ q de l'adresse de contact défini par le document RFC3261 intitulé « SIP: Session Initiation Protocol » édité par l'IETF, et contenu dans la requête d'enregistrement ayant permis l'enregistrement de cette adresse de contact sur le coeur de réseau. Dans un autre mode de réalisation de l'invention, le procédé de gestion comprend en outre une étape de vérification, avant d'accepter la requête, qu'au moins une adresse qui n'a pas répondu au message d'interrogation ou qui a été déclarée inactive en réponse au message d'interrogation correspond à la durée d'expiration d'enregistrement la plus faible parmi les adresses de contact enregistrées auprès du coeur de réseau en association avec l'identifiant public, la 10 requête émise par le dispositif étant rejetée dans le cas contraire. Ce mode de réalisation a une application privilégiée lorsque le procédé de gestion est mis en oeuvre par un équipement distinct du serveur d'enregistrement du coeur de réseau, et que le coeur de réseau applique une politique de type « FIFO » pour gérer l'enregistrement des adresses de contact qui consiste à éjecter le cas échéant l'adresse de contact qui correspond à la 15 durée d'expiration d'enregistrement la plus faible. Dans un autre mode de réalisation de l'invention, le procédé de gestion comprend en outre si plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation à l'issue de ladite période de temps prédéterminée, une étape de désenregistrement de ces adresses dans ledit coeur de réseau. 20 Au cours de cette étape de désenregistrement, on supprime ainsi avantageusement de la table d'enregistrement correspondant à l'identifiant public maintenue par le coeur de réseau toutes les adresses de contact non pertinentes car inactives et non correctement désenregistrées. De cette façon, les procédures d'enregistrement ultérieures entreprises par des dispositifs auprès du coeur de réseau seront plus rapides. 25 L'étape de désenregistrement peut en outre comprendre la notification d'au moins un serveur du coeur de réseau VoIP tel que par exemple un serveur P-CSCF (Proxy Call Session Control Function) ou un serveur d'application, du désenregistrement de ces adresses. Dans un mode de réalisation, le message d'interrociation peut être réémis plusieurs fois durant la période de temps prédéterminée vers au moins une des adresses de contact. 30 Ceci permet de parer à d'éventuels probiemes de transmission etiou de réception des d interrooati t.:tiou de leur, Par ailietin-: 'équipement auquel est envoyé le - l'int.:yepc.iiati occ.:15Hn ciie à ce message ',notamment s'il et xc peut repondre premiere ern,ssien,. Autrement dit, l'invention propose un procédé de gestion des requêtes qui peut être facilement configuré de sorte à prendre en compte - soit toutes les adresses de contact enregistrées pour un même identifiant public indépendamment de l'identifiant privé du dispositif cherchant à s'enregistrer ; soit uniquement les adresses de contact enregistrées pour un même identifiant public qui correspondent à l'identifiant privé du dispositif cherchant à s'enregistrer ou à des identifiants privés déterminés (ex. tous les identifiants privés associés à un même identifiant public à l'exception d'un ou de plusieurs identifiants privés prédéfinis (correspondant par exemple à des dispositifs prioritaires), ou tous les identifiants privés en liaison avec le dispositif cherchant à s'enregistrer (correspondant par exemple à des dispositifs du même type que le dispositif cherchant à s'enregistrer), etc.). Ainsi l'invention peut avantageusement s'appliquer dans différents modes de fonctionnement du coeur de réseau, c'est-à-dire aussi bien : - dans un mode de fonctionnement où plusieurs équipements ou dispositifs partagent à la fois la même identité publique et la même identité privée, que dans un mode de fonctionnement où ils partagent la même identité publique mais disposent d'identités privées distinctes (ex. mode de fonctionnement normalisé sous le nom de « Shared IMPU » dans le standard 3GPP pour les coeurs de réseau IMS), ou que - dans un mode de fonctionnement hybride entre ces deux modes de fonctionnement. Dans une variante de réalisation de l'invention, le message d'interrogation est également envoyé aux adresses de contact enregistrées sur le coeur de réseau en association avec l'identifiant public du dispositif lorsque la capacité maximale n'est pas atteinte. Ceci peut être réalisé systématiquement, par exemple à chaque réception d'une requête d'enregistrement d'une adresse de contact courante d'un dispositif, ou à des intervalles de temps prédéterminés (ex. périodiquement). Ceci permet, en analysant les réponses reçues à ce message d'interrogation (ou de façon équivalente les réponses non reçues), de nettoyer la table d'enregistrement correspondant à l'identifiant pubHc, indépendamment du fait que la capacité maximale soit atteinte. On limite ainsi phénornésies induis de blocage, des enregistrements, et les procédures d'enregistrement à propreno,sot parier sont accélérées. Dam-, mode particulier de réalisation, les différentes étapes du procédé de gestion 'invention son!, deterrninees pa!- inçtrnctions ,do 5drammes c ordmateuts. r 1 , ceu un serveu Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, 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. Selon un autre aspect, l'invention vise également un système d'un coeur de réseau de voix sur IP, comprenant : un serveur de gestion conforme à l'invention, apte à gérer une requête émise par un dispositif associé à un identifiant public, en vue d'un enregistrement sur le coeur de réseau d'une adresse de contact courante de ce dispositif ; et au moins une table d'enregistrement pour cet identifiant public, contenant au moins une adresse de contact distincte de l'adresse courante, enregistrée sur le coeur de réseau en association avec ledit identifiant public, ladite au moins une table d'enregistrement étant consultée par ledit serveur lors de la réception de la requête pour obtenir le nombre d'adresses de contact enregistrées sur le coeur de réseau en association avec cet identifiant public. Le système selon l'invention dispose des mêmes avantages que le procédé et le serveur de gestion selon l'invention décrits précédemment. On peut également envisager, clans d'autres modes dc réalisation, que le procédé de !e serveur de gestion et le système selon l'invention pré,i'rténi en combinison LoUtVu imrtie des caractéristiques pi éci LLt L la figure 2 illustre un exemple de table d'enregistrement maintenue par le serveur de gestion illustré à la figure 1 ; la figure 3 représente, de façon schématique, l'architecture matérielle du serveur de gestion dans le mode de réalisation de la figure 1 ; la figure 4 représente sous forme d'ordinogramme, les principales étapes d'un procédé de gestion selon l'invention lorsqu'il est mis en oeuvre dans un mode de réalisation de l'invention par le serveur représenté sur la figure 1 ; les figures 5A et 5B illustrent différents états de la table d'enregistrement maintenue par le serveur de gestion représenté sur la figure 1 ; 10 la figure 6 illustre une table d'enregistrement associée à un couple (identifiant public, identifiant privé) ; et la figure 7 illustre sous forme d'ordinogramme, les principales étapes d'un procédé de gestion selon l'invention lorsqu'il est mis en oeuvre dans un autre mode de réalisation de l'invention, par un serveur de gestion externe au coeur de réseau. 15 Description détaillée de l'invention La figure 1 représente, dans son environnement, un système 1 d'un coeur de réseau CN de voix sur IP, conforme à l'invention, dans un mode particulier de réalisation. Le système 1 permet la gestion des requêtes émises à destination du coeur de réseau 20 CN en vue de l'enregistrement d'une adresse de contact courante d'un dispositif sur ce coeur de réseau. Dans le mode de réalisation décrit ici, le coeur de réseau CN de voix sur IP est un coeur de réseau IMS mettant en oeuvre le protocole SIP. Ces hypothèses ne sont toutefois pas limitatives, l'invention s'appliquant également, comme mentionné précédemment, à d'autres 25 architectures de coeur de réseau VoIP (ex. H323, MGCP, Peer2Peer, REGISTRAR), ainsi qu'a d'autres protocoles applicatifs VoIP tels que par exemple XMPP, ainsi qu'a d'autres protocoles propriétaires. Dans l'exemple décrit ici, on envisage plus particulièrement la gestion de requêtes ernises par cies dispositifs A et partageant une même identité (ou identifiant) publique IMPU1. 30 L'identifiant IMPU cri, ici une identité IMPU, connue en soi et telle que der,nie par le standard 3GPP notamnleiit dans °current 3GPP TS 23,22S iiuitule -IP Multimedia Subsystem », Release 35 un terminai ,'e[)11,311e, tab:ette adresse de joignabilité du dispositif dans le domaine IP, et comprend notamment l'adresse IP du dispositif, un numéro de port associé à sa pile VoIP ainsi que le protocole de transport (ex. UDP, TCP, TLS) utilisé par le dispositif pour communiquer dans le domaine IP. Conformément à l'invention, le système 1 comprend un serveur de gestion 2 conforme à l'invention et des tables (ou contextes) d'enregistrement T associées respectivement à chaque identifiant public (ou à chaque couple (identifiant public,identifiant privé)) en relation avec lequel une requête d'enregistrement a été émise à destination du coeur de réseau. Par table d'enregistrement associée à un identifiant public donné ou à un couple (identifiant public,identifiant privé) donné, on entend ici une structure de données quelconque qui 10 permet de stocker des informations relatives à des enregistrements réalisés pour cet identifiant public donné ou pour ce couple (identifiant public,identifiant privé) donné. Une telle table est connue en soi et ne sera pas décrite en détail ici. Chaque table d'enregistrement associée à un identifiant public (respectivement à un couple (identifiant public,identifiant privé)) contient notamment les adresses de contact des 15 dispositifs qui se sont enregistrés en association avec cet identifiant public (respectivement en association avec ce couple (identifiant public,identifiant privé)), ainsi que la durée d'expiration de leurs enregistrements (valeur du paramètre Expires dans le protocole SIP). On notera qu'une table d'enregistrement associée à un identifiant public donné peut elle-même être constituée de plusieurs « sous-tables » distinctes, chaque sous-table étant associée 20 à un couple formé de cet identifiant public donné et d'un identifiant privé distinct et contenant les adresses enregistrées en association avec ce couple. Le nombre maximal d'adresses de contact pouvant être enregistrées dans la table est fixé par exemple par l'opérateur du coeur de réseau et dépend de la politique envisagée pour le contrôle des enregistrements associés à un même identifiant public (respectivement à un même 25 couple (identifiant public,identifiant privé)). Ce nombre constitue une capacité maximale Cmax d'enregistrement pour un identifiant public (respectivement pour un couple (identifiant public,identifiant privé))) au sens de l'invention. Il peut varier en fonction des identifiants, des types de dispositifs que l'on souhaite enregistrer (ex. si l'on fait une distinction entre les dispositifs au moment de l'enregistrement dans !a politique de contrôle), etc. 30 Dans l'exemp!e envisagé à la figure 2, la table T(IMPU1) associée à l'identifiE3nt public coriiTuenc.1 à une capacité miuxiniale Cmax=2 et con-luron:d ies a I rf.7i OL.: contact ,tri-fflteS et AoLi3 des dispositifs A et B, ainsi que les: durées d'expiration iespectives EXPA EXPE ce:, enregistrements, Il dispose ici de l'architecture matérielle d'un ordinateur telle que représentée schématiquement sur la figure 3. Il comporte notamment un processeur 3, une mémoire vive 4, une mémoire morte 5, une mémoire réinscriptible non volatile 6 (dans laquelle sont stockées par exemple les tables d'enregistrement maintenues par le serveur 2), ainsi que des moyens de communication 7 mettant en oeuvre notamment le protocole SIP connus en soi. La mémoire morte 5 du serveur 2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 3 et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de gestion d'une requête conforme à l'invention, décrites maintenant en référence à la figure 4, dans un mode particulier de réalisation. Pour illustrer ce mode de réalisation, on envisage ici le traitement par le serveur 2 d'une requête d'enregistrement émise par le terminal A à destination du coeur de réseau CN. Cette requête est ici un message SIP REGISTER contenant notamment l'identifiant public IMPU1 du terminal A ainsi que son adresse de contact courante AoCA. Sur réception de cette requête (étape E10), le serveur de gestion 2 détermine si l'adresse de contact AoCA est une nouvelle adresse de contact non encore enregistrée pour l'identifiant IMPLJ1 ou si la requête est en fait une requête de réengistrement du terminal AoCA (étape E20). Dans le mode de réalisation SIP décrit ici, le serveur de gestion 2 extrait à cette fin l'identifiant de dialogue présent de façon connue en soi dans la requête SIP REGISTER, et détermine si cet identifiant de dialogue correspond à un dialogue déjà établi avec le coeur de réseau. Si tel est le cas, la requête reçue est une requête de réenregistrement, autrement dit, l'adresse de contact courante AoCA est déjà enregistrée dans la table T(IMPU1) (réponse non au test de l'étape E20) : le serveur 2 met alors à jour dans la table T(IMPU1) la durée d'expiration d'enregistrement EXPA associée au terminal A (étape E30). Par exemple, EXPA=1heure. Il envoie ensuite un message de réponse au terminal A, contenant la valeur de la durte. EXPA (étape E40). Ce message de réponse est ici un message SIP 2000K contenant un Si cciuHire, |e scriveti- gostion 2 qetermii e que la ru:pète reçue n'est pas une requete de réenregrii.:-cment 1.1fle. Ufke lregistrerniiTlt niha| (\réponse oui au test de l'étape E20), il recherche nfturroi, 7curit:ble non volatile 6 si une table d'enregistrement Ti(7.1PLI1) iissocci H:r ;Ste. , un dysfonctionnement du réseau qu'il peut signaler de façon connue en soi, notamment par un message d'erreur envoyé au terminal A. On suppose ici qu'une telle table existe déjà dans la mémoire 6 du serveur de gestion 2 (cette table a par exemple été créée lors d'un enregistrement précédent avec l'identifiant public IMPU1). Le serveur de gestion 2 obtient en consultant cette table d'enregistrement le nombre Nb-AoC d'adresses de contact déjà enregistrées en association avec l'identifiant public IMPU1, selon des moyens connus en soi non détaillés ici (étape E50). Puis il compare ce nombre Nb-AoC avec la capacité maximale Cmax d'enregistrement 10 associée à l'identifiant IMPU1, afin de déterminer si la capacité maximale d'enregistrement est déjà atteinte (étape E60). Si Nb-AoC est inférieur à Cmax (réponse non au test de l'étape E60), le serveur de gestion 2 accepte la requête d'enregistrement du terminal A (étape E70). Dans l'exemple décrit ici, le serveur de gestion 2 met alors à jour la table 15 d'enregistrement T(IMPU1) en ajoutant l'adresse de contact AoCA courante du terminal A ainsi qu'une durée d'expiration d'enregistrement EXPA égale à 1 heure (étape E80), et envoie un message 200 OK contenant la durée EXPA au terminal A (étape E90). La figure 5A illustre un exemple d'une telle mise à jour lorsque la table T(IMPU1) contient initialement une seule adresse de contact (état (a) sur la figure 5A), à savoir l'adresse de 20 contact AoCB de la passerelle B. A l'issue de la mise à jour (état (b) sur la figure 5A), la table T(IMPU1) contient l'adresse de contact AoCB de la passerelle B ainsi que l'adresse de contact AoCA du terminal A. La capacité maximale d'enregistrement associée à l'identifiant public IMPU1 est alors atteinte. Si au contraire, à l'issue de l'étape E60 de comparaison, le serveur de gestion 2 25 détecte que la capacité maximale d'enregistrement est déjà atteinte (réponse oui au test de l'étape E60), il déclenche dans le mode de réalisation décrit ici un temporisateur t pour une période de temps prédéterminée notée d (étape E100). Cette période est choisie ici de sorte à permettre au serveur de gestion 2 de répondre à la requête d'enregistrement du terminal A dans les limites du temps de réponse prévu 30 par le coeur de if.:seau E'.ul_remélii_ dit ici conformément au temps de réponse défini par le standard 3GPP pou:- de reseau IMS qui est. es), afin que les étapes supplémentaires pur de gestionr doter -,Y1 accepte ou non la requête ,.:istrement soient transpàrente5 pou- figure 5B 'I .t: ',Huel la capacité Puis, conformément à l'invention, le serveur de gestion 2 envoie à toutes les adresses de contact enregistrées dans la table T(IMPU1) en association avec l'identifiant public IMPU1, un message d'interrogation afin de déterminer si ces adresses de contact sont toujours actives, c'est-à-dire utilisées comme adresses de contact courantes par les dispositifs qui ont requis leur enregistrement (étape E110). Comme mentionné précédemment, un message d'interrogation au sens de l'invention désigne un message qui appelle une réponse de la part de son destinataire, autrement dit, auquel le destinataire identifié dans le message répond en temps normal lorsqu'il reçoit ce message. Ce message d'interrogation est choisi préférentiellement de sorte à ne pas perturber les sessions en cours (ex. communications) au niveau des dispositifs auxquels il est envoyé. Dans le mode de réalisation décrit ici, ce message d'interrogation est un message SIP OP1IONS, qui contient dans la RURI du message (ou Request URI en anglais), l'adresse de contact à laquelle le message est destiné, et dans le champ FROM, l'identifiant du serveur de gestion 2. Dans l'exemple envisagé à la figure 5B, le serveur de gestion 2 envoie donc un message SIP OPTIONS à l'adresse de contact AoCB et un message SIP OP I IONS à l'adresse de contact AoCB'. Puis le serveur de gestion 2 se place en attente des réponses aux messages d'interrogation envoyés, jusqu'à l'expiration du temporisateur t (étape E120). Dans une variante de réalisation, si le serveur de gestion 2 n'a pas reçu de réponse d'une (ou de plusieurs) adresse de contact à laquelle il a envoyé un message d'interrogation à des intervalles de temps déterminés précédant l'expiration du temporisateur t, il retransmet le message d'interrogation une ou plusieurs fois (par exemple deux fois) à cette adresse de contact avant l'expiration du temporisateur t, afin de pallier à d'éventuels problèmes de transmission entre le serveur de gestion 2 et le dispositif associé à cette adresse de contact. A l'issue de la période d (Le. à l'expiration du temporisateur t), le serveur de gestion 2 détermine si toutes les adresses de contact auxquelles il a envoyé un message d'interrogation sont actives. Dans le mode de réalisation décrit ici et pour une configuration de réseau semblable à celle représentée sur la figure 1, le serveur de gestion 2 détermine à cette fin s'il a reçu des réponses au message d'interrogation de toutes les adresses de contact rLpertoriées dans la table ,' 5E, - adresses de contact AcCE, AeCB' (étape réponse :ire par eAeiripit? '31.P 2n00K en cas. de (lisp:Di-11'El dispositif, ou Here si le cours de commi e =.4 T(IMPUI,), c'est-a-dire, dans l'exemple envis: Si en revanche, au moins une adresse de contact n'a pas répondu à l'issue de la période de temps d au message d'interrogation envoyé par le serveur de gestion 2 (réponse non au test de l'étape E130), le serveur de gestion 2 en déduit que cette adresse de contact n'est plus active (par exemple parce que le dispositif qui s'était enregistré avec cette adresse de contact a changé d'adresse de contact courante ou est éteint) et n'a pas lieu de rester enregistrée dans la table T(IMPU1). Conformément à l'invention, le serveur de gestion 2 accepte donc la requête d'enregistrement émise par le terminal A. Par ailleurs, dans le mode de réalisation décrit ici, le serveur de gestion 2 met à jour la table d'enregistrement T(IMPU1) avec l'adresse de contact courante AoCA du terminal A et la durée d'expiration EXPA (étape E160), puis envoie au terminal A un message SIP 2000K associé à une durée d'expiration d'enregistrement EXPA=1 heure pour lui signifier l'acceptation de sa requête d'enregistrement (étape E170). Plusieurs cas de figure peuvent se présenter lors de la mise à jour de la table T(IMPU1) à l'étape E160 : (1) une seule adresse de contact n'a pas répondu au message d'interrogation envoyé par le serveur de gestion 2 ; ou (2) plusieurs adresses de contact n'ont pas répondu au message d'interrogation envoyé par le serveur de gestion 2 (ce cas de figure suppose une capacité maximale d'enregistrement supérieure à 1). Dans le cas de figure (1), le serveur de gestion 2 désenregistre l'adresse de contact n'ayant pas répondu (autrement dit il la supprime de la table d'enregistrement T(IMPU1)), et enregistre dans la table T(IMPU1) en remplacement de cette adresse, l'adresse de contact courante AoCA du terminal A et la durée d'expiration EXPA. La figure 5B illustre une telle mise à jour, Dans l'exemple envisagé à la figure 5B, on suppose par exemple que la passerelle Ba redémarré de façon brusque alors qu'elle utilisait l'adresse de contact AoCB' et n'a pas pu se désenregistrer avant son redémarrage auprès du coeur de réseau CN. Suite à son redémarrage, on suppose que la passerelle B a maintenant pour adresse de contact courante l'adresse AoCB, l'adresse AoCB' étant inactive: de sorte que la table T(IMPU1) contient les deux adresses de contact ii.(aCB' et AoCB associées rcs ,j',./ement aux durecb 'dxpiration EXPB' et EXPB (,état (a) de TUMPU1) sur la figute 55) 'adrPsse de contact AoCB', le serveu dj,:--;ton 2 ne La B reç ssace epon-,4 cette adres,e messacit interrociatiun envoye d l'eta.pe35 enregistrer l'adresse de contact courante du terminal A, et d'autre part pour traiter les autres adresses de contact qui n'ont pas répondu au message d'interrogation. Dans le mode de réalisation décrit ici, le serveur de gestion 2 éjecte (i.e. désenregistre du coeur de réseau CN) l'adresse de contact n'ayant pas répondu au message d'interrogation qui correspond à la durée d'expiration la plus faible, et enregistre dans la table T(IMPU1) en remplacement de cette adresse, l'adresse de contact AoCA et la durée d'expiration EXPA. On notera que dans l'hypothèse où l'ensemble des dispositifs est configuré pour envoyer des messages de réenregistrement au coeur de réseau selon une même période de temps, ce mode de réalisation est équivalent à enregistrer l'adresse de contact du terminal A en remplacement de l'adresse de contact correspondant à l'enregistrement le plus ancien. Par ailleurs, dans le mode de réalisation décrit ici, le serveur de gestion 2 éjecte également de la table T(IMPU1) (i.e. désenregistre du coeur de réseau) les autres adresses de contact qui n'ont pas répondu au message d'interrogation à l'issue de la durée d. Il s'agit par ce biais de nettoyer la table d'enregistrement des adresses de contact inactives afin de simplifier et d'accélérer les enregistrements ultérieurs. Cette mise à jour de la table d'enregistrement permet également d'éviter l'envoi de messages inutiles sur le réseau, notamment lorsqu'un appel entrant (message SIP INVITE) destiné à un identifiant public enregistré auprès du coeur de réseau arrive. En effet, conformément au standard 3GPP, lorsque plusieurs adresses de contact sont associées à un même identifiant public dans le coeur de réseau, le message SIP INVITE est présenté à chacune de ces adresses de contact. L'invention permet ainsi de limiter les retransmissions inutiles du message SIP INVITE aux adresses de contact qui ne sont plus actives. Dans une variante de réalisation, ces autres adresses de contact ne sont pas supprimées de la table. Dans une autre variante encore de réalisation l'étape de désenregistrement de l'adresse ou des adresses de contact inactives du coeur de réseau peuvent en outre s'accompagner de la notification d'au moins un serveur du coeur de réseau VoIP tel que par exemple un serveur PCSCF (Proxy Call Session Control Function) ou un serveur d'application, de la suppression de cette ou de ces adresses de la table d'enregistrement. D'autres [politiques de mise à jour de la table pourraient être envisagées pour fil' contact va être supprimee de la table afin d'enreciistter l'adresse de '7n'l:act courant(' du terminal A. Ainsi, par exemple, unê peut consister à éjecter l'arlree de contact qui est ,,ociée la riorite la plus faible parmi ['dru -` ondu au message la valeur 1 désignant un dispositif de priorité maximale, tandis que la valeur 0 désigne la priorité la plus faible (l'absence de valeur q est équivalent à une valeur q=0). Ce champ est présent notamment dans chaque requête d'enregistrement d'une adresse de contact envoyée au coeur de réseau. Pour mettre en oeuvre cette alternative, la table d'enregistrement associera en outre à chaque adresse de contact stockée, la valeur correspondante du champ « q » (valeur contenue dans la requête d'enregistrement ayant permis l'enregistrement de cette adresse de contact sur le coeur de réseau). En variante, la priorité d'un dispositif peut être associée à une plage d'adresses IP dans laquelle se trouve son adresse de contact. Par exemple, on peut envisager d'associer à diverses plages d'adresses de contact différents types de dispositifs en fonction de leur priorité : ainsi, une première plage d'adresses pourrait être associée aux dispositifs prioritaires tels que des passerelles, une deuxième plage d'adresses aux terminaux connectés derrière la passerelle, et une troisième plage d'adresses aux terminaux connectés à des points d'accès accessibles en situation de nomadisme, cette troisième plage d'adresses définissant une catégorie de dispositifs moins prioritaires au sens « usage du coeur de réseau » du terme. Dans le mode de réalisation décrit ici en référence à la configuration de réseau illustrée à la figure 1, le serveur de gestion 2 détermine si les adresses de contact sont actives en détectant la présence (ou l'absence) de réponses reçues de ces adresses de contact aux messages d'interrogation envoyés. Dans cette configuration en effet, les messages de réponse sont transmis jusqu'au serveur de gestion 2. Toutefois, l'invention s'applique également à d'autres configurations de réseau, et en particulier, à une configuration de réseau dans laquelle des équipements intermédiaires tels que des serveurs de bordure SBC sont prévus dans la gestion des enregistrements entre le coeur de réseau CN et les dispositifs auxquels le serveur de gestion 2 envoie les messages d'interrogation, afin par exemple de diminuer la charge du serveur de gestion 2 et d'assurer un trafic régulier à l'accès. Dans une telle configuration, les messages de réponse des dispositifs sont reçus par les équipements intermédiaires ; de même l'absence de messages de réponse à l'issue de la période d est détectée par ces équipements intermédiaires. Les équipements intermédiaires envoient ensuite leur tour un message déclarant l'activité ou l'inactivite de l'adresse de contact au serveur de ,i],:r:;tion 2. Ainsi, dans une telle cofigusnt nb cours de retape E13O, pour déterminer si a ;lie de la période d toutc. e )(quelles il a envoyé un egation jeStiOr 2 iltlélly5t.: ies messages reçus du -.,rrogation infognent d'une35 Si en revanche, à l'issue de la période de temps d, il a reçu pour au moins une adresse de contact, un message d'un équipement intermédiaire déclarant en réponse au message d'interrogation l'inactivité du dispositif associé à cette adresse de contact (par exemple un message 480 No Route Found), il en déduit que cette adresse de contact n'est plus active (réponse non au test de l'étape E130). Conformément à l'invention, le serveur de gestion 2 accepte donc la requête d'enregistrement émise par le terminal A. Corrélativement, la sélection de l'adresse (ou des adresses) de contact à éjecter de la table d'enregistrement, notamment pour permettre l'enregistrement de l'adresse de contact du terminal A, est effectuée parmi les adresses de contact qui ont été déclarées inactives par l'un des équipements intermédiaires en réponse aux messages d'interrogation envoyés par le serveur de gestion 2. Bien entendu, l'invention s'applique également avec des configurations hybrides du réseau dans lesquels des équipements intermédiaires sont présents pour seulement une partie des dispositifs aptes à s'enregistrer auprès du coeur de réseau CN. Dans un tel cas de figure, le serveur de gestion 2 vérifie, avant d'accepter la requête d'enregistrement émise par le terminal A si, à l'issue de la période de temps d, au moins une adresse de contact n'a pas répondu au message d'interrogation ou a été déclarée comme inactive par l'un des équipements intermédiaires en réponse au message d'interrogation (par exemple via un message 480 No Route Found). Corrélativement, la sélection de l'adresse (ou des adresses) de contact à éjecter de la table d'enregistrement est effectuée parmi les adresses de contact qui n'ont pas répondu aux messages d'interrogation envoyés par le serveur de gestion 2 ou qui ont été déclarées inactives par l'un des équipements intermédiaires en réponse à ces messages d'interrogation. Dans les exemples considérés pour illustrer l'invention, on a envisagé la gestion d'une requête d'enregistrement émise par le terminal A et une table d'enregistrement contenant deux adresses de contact de la passerelle B, l'une d'elle étant inactive. L'invention s'applique bien entendu à d'autres situations, comme par exemple lorsque la table d'enregistrement T(IMPU1) contient une adresse de contact de la passerelle B et une adresse de contact inactive du terminal A distincte de son adresse de contact courante qu'il n'a pas désenregistrée auprès du coeur de reseau. Dans ie mode de realisatb' décrit ici, la gestion de Io recp, creni-egistrement est realLs. pour un identifiant public in,',1c.b,endaminent de la politique eiT...,soge,. Gons le coeur de ncernant l'attribution de, -rtirianb ivt2s dispesitiis ortageont cet identifiant identifiant ive ;DO tons les CliSpOSitl morne identifiant public, icts >2'S mts MiPt en mode de réalisation, les étapes du procédé selon l'invention décrites précédemment en référence à la figure 4 sont alors mises en oeuvre à partir d'une table d'enregistrement T(IMPU1,IMPIA) associée au couple formé par l'identifiant public IMPU1 et l'identifiant privé IMPIA du terminal, et en considérant les adresses de contact enregistrées dans cette table (ex. Nb-AoC correspond au nombre d'enregistrements de la table associée au couple (identifiant public, identifiant privé) du terminal A, Cmax correspond à la capacité maximale d'enregistrements associée à ce couple, et l'adresse de contact AoCA est enregistrée le cas échéant en remplacement d'une adresse de contact de la table T(IMPU1,IMPIA)). La figure 6 illustre un exemple d'une table d'enregistrement T(IMPU1,IMPIA) associée 10 au couple T(IMPUUMPIA) du terminal A et intégrée dans la table T(IMPU1) associée à l'identifiant public IMPU1. Dans cet exemple, l'identifiant privé IMPIA est partagé par le terminal A et un autre dispositif C, tandis que la passerelle Ba un identifiant privé distinct IMPIB. Les dispositifs A, B et C partagent le même identifiant public IMPUl. La gestion des requêtes d'enregistrement par le coeur de réseau est réalisée à l'aide de files d'attente associées à chaque couple identifiant public- 15 identifiant privé. Ainsi, l'invention permet, dans les différents modes de réalisation décrits, de gérer les enregistrements soit en prenant en compte uniquement l'identifiant public contenu dans la requête (indépendamment de la politique d'attribution d'identifiants privés mise en oeuvre par le coeur de réseau, ex. même identifiant privé partagé par plusieurs dispositifs ou un identifiant privé distinct 20 pour chaque dispositif), soit en prenant en compte l'identifiant public et l'identifiant privé contenus dans la requête. Dans le mode de réalisation décrit ici, le serveur de gestion 2 n'envoie de message d'interrogation que lorsque la capacité maximale d'enregistrement est atteinte dans la table d'enregistrement associée à l'identifiant public IMPU1 ou dans la table d'enregistrement associée 25 au couple formé par l'identifiant public IMPU et l'identifiant privé IMPI. En variante, un message d'interrogation similaire peut être envoyé aux adresses de contact de la table indépendamment du fait que la capacité maximale ait été atteinte, par exemple de façon périodique, afin de nettoyer régulièrement la table d'enregistrement des adresses de contact inactives. Les adresses de contact n'ayant pas'.'2pondu à ce iliessacyp d'interrogation à l'expiration d'une durée prédéterminée (qui 30 peul iPentPclue ou non la durée sont a ors supprirnée(, taUe 'PU 1 ) ou LPIA) par le serveur de destion Par aillc,i dans ',ecrit P2meorde ai"5tinn Pur d'en! -ii iL. ...au! assoc ...L. VPflan Pi'. 35 1PIA). Par exemple, dans un autre mode de réalisation, le serveur de gestion 2 peut être un serveur externe au coeur de réseau CN (ex. localisé dans le système d'information du réseau), apte à réaliser une présélection des dispositifs pouvant émettre des requêtes d'enregistrement auprès du coeur de réseau CN compte tenu du nombre d'adresses de contact déjà enregistrées pour un identifiant public donné (ou un couple (identifiant public,identifiant privé) donné), et plus précisément des requêtes destinées au serveur d'enregistrement du coeur de réseau CN qui lui est apte à mettre à jour les tables d'enregistrement et à accepter ou rejeter les requêtes d'enregistrement en fonction de la politique mise en oeuvre dans le coeur de réseau CN. Les étapes mises en oeuvre au cours du procédé de gestion selon l'invention par le serveur de gestion dans cet autre mode de réalisation sont illustrées à la figure 7. Dans l'exemple envisagé sur cette figure, la gestion conformément à l'invention d'une requête émise en vue d'un enregistrement sur le coeur de réseau CN est réalisée en prenant en compte uniquement l'identifiant public contenu dans la requête. Bien entendu, ce mode de réalisation s'applique également lorsque l'on prend en compte également l'identifiant privé contenu dans la requête. Dans ce mode de réalisation, les étapes E10', E20', E40' à E70', E90', E100' à E150', E170' mises en oeuvre par le serveur de gestion (ainsi que les variantes associées) sont semblables aux étapes E10, E20, E40 à E70, E90, E100 à E150, E170 décrites précédemment en référence à la figure 4 (les étapes E30, E80 et E160 de mise à jour de la table d'enregistrement ne sont en revanche pas implémentées par le serveur de gestion). Les informations requises pour mettre en oeuvre l'invention (ex. nombre d'adresses de contact et adresses de contact enregistrées dans la table d'enregistrement) sont toutefois obtenues par le serveur de gestion en interrogeant à l'aide de l'identifiant public par exemple le serveur d'enregistrement du coeur de réseau CN en utilisant la procédure SIP standard décrite dans le document IETF RFC3261 mentionné précédemment (i.e. envoi d'un message SIP REGISTER contenant l'identifiant public IMPU1 mais sans spécifier d'adresse de contact)). Par ailleurs, compte-tenu du fait que dans ce mode de réalisation, la politique de suppression et de remplacement des adresses de contact dans la table d'enregistrement ne dépend pas du serveur de gestion, celui-ci doit s'assurer, avant de transmettre une requête d'enregistrement au coeur e. réseau CN (autrement dit avant d'accepter une requête .l'enreçp1rerlICrt d'Un dispositif), qu'elie ne va pas déciencher l'éviction d'une adresse de contact de la table, d1eni-gistrement qui ne serait paç souhaitable, enipk, cm cette adresse de contact est , une nler -sque l coeur de ruree,, d'expiration !innle'Flii..e une litique flou la pas répondu au message d'interrogation, l'une d'elles correspond à la durée d'expiration la plus faible enregistrée dans la table d'enregistrement (étape E145'). Cette étape peut être mise en oeuvre par exemple en interrogeant le serveur d'enregistrement du coeur de réseau CN. Si tel est le cas, alors le serveur de gestion accepte la requête d'enregistrement du terminal A (étape E150') et lui envoie un message SIP 2000K (étape E170'). En revanche, si aucune des adresses de contact qui n'a pas répondu au message d'interrogation ne correspond à la durée d'expiration d'enregistrement la plus faible enregistrée en association avec l'identifiant public IMPU1, le serveur de gestion refuse la requête d'enregistrement du terminal A (étape E140'). 10 Dans l'exemple envisagé à la figure 7, l'étape E10' est identique à l'étape El0 et consiste en la réception d'une requête d'enregistrement SIP REGISTER émise par le terminal A à destination du coeur de réseau CN. En variante, la requête reçue à l'étape E10' peut être une requête distincte d'un message SIP REGISTER ou plus généralement une requête distincte d'un message spécifique prévu par le protocole mis en oeuvre par le coeur de réseau pour 15 l'enregistrement d'un dispositif. Il peut s'agir de façon générale d'une requête quelconque nécessaire à l'enregistrement du dispositif. Ainsi par exemple, cette requête peut être un message envoyé par le terminal Avisant à obtenir un fichier de configuration VoIP nécessaire à son enregistrement sur le coeur de réseau. Un tel message est par exemple un message HI 1P Get Parameter contenant l'adresse IP du 20 terminal A. On notera que l'obtention du fichier de configuration VoIP par le terminal A est indissociable de l'enregistrement du terminal A sur le coeur de réseau (et plus particulièrement de son adresse de contact courante),et fait partie de la procédure d'enregistrement mise en place par le terminal A dans le sens où d'une part l'obtention d'un tel fichier de configuration est un pré-requis pour l'enregistrement de l'adresse de contact courante du terminal sur le coeur de réseau et 25 d'autre part l'obtention de ce fichier n'a de sens que parce que le terminal A souhaite enregistrer son adresse de contact courante sur le coeur de réseau VoIP pour pouvoir communiquer sur ce coeur de réseau. Un message requérant l'obtention de ce fichier constitue donc une requête en vue d'un enregistrement sur le coeur de réseau d'une adresse de contact courante d'un dispositif au sens de l'invention. 30 On notera que lorsque lote aérée par le procédé selon l'invention est un tel essage, l'identifiant pub c associé terminal A. I non:imment pour obtenir le ornly-e rib-AGC la Cmax, peut etre serveur ce a(P terirlri-i 'tenue caris la requete, po' point d'entrée du coeur de réseau VoIP, le nom du domaine du réseau VoIP, ainsi que d'autres champs liés à l'activation de services sur le coeur de réseau VoIP). En revanche, lorsque la requête est refusée au cours de l'étape E140', le fichier de configuration VoIP requis n'est pas envoyé au terminal A. On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le serveur de gestion et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques décrites précédemment en référence aux figures 1 à 7. REVENDICATIONS1. Procédé de gestion d'une requête émise par un dispositif (A) associé à un identifiant public (IMPU1), en vue d'un enregistrement sur un coeur de réseau de voix sur IP (CN) d'une adresse de contact courante (AoCA) dudit dispositif pour ce coeur de réseau, ledit procédé de gestion comprenant : une étape d'obtention (E50,E50'), sur d'adresses de contact (Nb-A0C) enregistrées sur le coeur de identifiant public ; et 10 une étape de comparaison (E60,E601 de ce nombre d'enregistrement (Cmax) définie pour cet identifiant public ; ledit procédé de gestion étant caractérisé en ce qu'il comprend en outre, lorsque ledit nombre a atteint ladite capacité maximale : - une étape (E110,E110') d'envoi d'un message d'interrogation auxdites adresses de contact 15 enregistrées sur le coeur de réseau en association avec l'identifiant public ; si, à l'issue d'une période de temps prédéterminée, au moins une adresse de contact parmi ces adresses n'a pas répondu audit message d'interrogation ou est déclarée inactive en réponse audit message d'interrogation, une étape d'acceptation (E150,E150') de la requête du dispositif ; et une étape de rejet (E140, E140') de la requête sinon. 20 2. Procédé de gestion selon la revendication 1 caractérisé en ce que, au cours de l'étape d'acceptation (E150), l'adresse de contact courante (AoCA) du dispositif (A) est enregistrée (E160) sur le coeur de réseau en association avec l'identifiant public (IMPU1) en remplacement d'une adresse de contact (AoCB') n'ayant pas répondu au message d'interrogation ou déclarée 25 inactive en réponse audit message d'interrogation. 3. Procédé de gestion selon la revendication 2 caractérisé en ce que, lorsque plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation, l'adresse de contact courante du dispositif est 30 enregist ri.--2n-iplaceeent de Hadresse de contact qui correspond à la duree d'expiration reoistrement la plus 'ul.)re i2e1111 lesdites plusieurs adresses de contact, cet ion 2 ddelte que, lorsque gntei - été déc.:, réception (E10,E10') de ladite requête, d'un nombre réseau en association avec ledit avec une capacité maximale 4. 35 . Procédé de gestion selon la revendication 4 caractérisé en ce que la priorité de l'adresse de contact est déterminée par le champ q défini dans le document IETF RFC3261. 6. Procédé de gestion selon la revendication 1 caractérisé en ce qu'il comprend en outre une étape de vérification (E145'), avant d'accepter ladite requête (E150'), qu'au moins une adresse qui n'a pas répondu au message d'interrogation ou qui a été déclarée inactive en réponse au message d'interrogation correspond à la durée d'expiration d'enregistrement la plus faible parmi les adresses de contact enregistrées auprès du coeur de réseau en association avec l'identifiant public, ladite requête étant rejetée (E140') dans le cas contraire. 7. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comprend en outre, si plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation à l'issue de ladite période de temps prédéterminée, une étape de désenregistrement (E160) de ces adresses dans le coeur de réseau. 8. Procédé de gestion selon la revendication 1, caractérisé en ce que ledit message d'interrogation est réémis plusieurs fois durant ladite période de temps prédéterminée vers au moins une desdites adresses de contact. 20 9. Procédé de gestion selon la revendication 1, caractérisé en ce que, lorsque ledit coeur de réseau de voix sur IP (CN) met en oeuvre le protocole SIP, ledit message d'interrogation est un message SIP OP 'IONS. 10. Procédé de gestion selon la revendication 1, caractérisé en ce que ledit dispositif 25 (A) est en outre associé à un identifiant privé (IMPIA), et ledit procédé de gestion est mis en oeuvre en considérant les adresses de contact enregistrées sur le coeur de réseau en association avec le couple formé par l'identifiant public et l'identifiant privé associés au dispositif (A). 11. Procédé de gestion selon la revendication 1, caractérise en ce que le message 30 d'interrogation est également envoyé aux adresses de contact enreoistrees sur le coeur de réseau en association avec l'identifiant public du dispositi` ia capacite n'eSt paS atteinte. 15 12. Pi-ci:ru:uni_ ordinal.eur l'une quelcono ctions poui ns 1 à 11 3Fd'une adresse de contact courante (AoCA) dudit dispositif pour ce coeur de réseau, ledit serveur de gestion comprenant : des moyens, activés sur réception de ladite requête, pour obtenir un nombre d'adresses de contact (Nb-AoC) enregistrées sur le coeur de réseau en association avec ledit identifiant public; et des moyens de comparaison de ce nombre avec une capacité maximale (Cmax) d'enregistrement définie pour cet identifiant public ; ledit serveur de gestion étant caractérisé en ce qu'il comprend en outre des moyens, activés lorsque ledit nombre a atteint ladite capacité maximale 10 - pour envoyer un message d'interrogation auxdites adresses de contact enregistrées en association avec ledit identifiant public ; - pour accepter la requête si à l'issue d'une période de temps prédéterminée, au moins une adresse de contact parmi ces adresses de contact n'a pas répondu au message d'interrogationou est déclarée inactive en réponse audit message d'interrogation ; et 15 - pour rejeter la requête sinon. 14. Serveur de gestion (2) selon la revendication 13 caractérisé en ce que les moyens pour accepter la requête sont aptes à enregistrer l'adresse de contact courante du dispositif sur le coeur de réseau en association avec l'identifiant public en remplacement d'une adresse de contact 20 n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse audit message d'interrogation. 15. Serveur de gestion (2) selon la revendication 13 caractérisé en ce qu'il est intégré dans un serveur S-CSCF lorsque le coeur de réseau (CN) est un coeur de réseau IMS.