FR 3004612 A1 20141017 FR 1353436 A 20130416 PROCEDE DE RESTAURATION DE SERVICE DANS UN RESEAU IMS La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en oeuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent notamment la transmission de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VolP), « Partage de Contenu », ou « Messagerie Instantanée ». Plus particulièrement, la présente invention concerne le routage d'une requête de service, par exemple un appel de VoIP, vers un dispositif-client appartenant à un réseau IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). On notera à cet égard que, dans le cadre de la présente invention, un dispositif-client (« User Equipment » en anglais) est dit « appartenir » au réseau d'un opérateur donné lorsque l'utilisateur de ce dispositif-client possède un compte auprès de cet opérateur, et ce, quel que soit le réseau d'accès utilisé par le dispositif-client pour se connecter au réseau de l'opérateur. Ces dispositifs-clients peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, ou encore une passerelle d'opérateur réseau (« Voice Gateway » en anglais) telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « Multiplexeur d'Accès de Lignes d'Abonnés Numériques » ; il s'agit d'un dispositif collectant le trafic de données DSL qui transite sur un certain nombre de lignes téléphoniques). Les protocoles de contrôle de session évolués classiques, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension permet des procédures de notification d'événements. Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS, mentionné ci-dessus. L'IMS a été défini par l'organisme de normalisation 3GPP (« eti Generation Partnership Project ») et TISPAN (« Telecommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services tels que la téléphonie, la visiophonie, et la Messagerie Instantanée, dont elle gère aussi l'interaction. On rappelle par exemple que la Messagerie Instantanée (« Instant Messaging », ou IM, en anglais), également appelée « tchat » (appellation dérivée du mot anglais « chat » signifiant « bavardage »), permet l'échange quasi-instantané de messages textuels et de fichiers, ce qui permet un dialogue interactif entre deux utilisateurs connectés au même réseau (tel qu'Internet). Lorsqu'un utilisateur souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes. Tout d'abord, le dispositif-client de l'utilisateur doit, sauf exceptions (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du dispositif-client pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le dispositif-client de l'utilisateur doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement. Pour pouvoir donc enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs d'enregistrement, appelés serveurs « S-CSCF » (initiales des mots anglais « Serving-Gall Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau. En outre, ces réseaux comprennent un ou plusieurs serveurs, appelés serveurs « I-CSCF » (initiales des mots anglais « InterrogatingCali Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») - d'ailleurs souvent combinés physiquement avec les serveurs de type S-CSCF pour constituer des serveurs dénotés « I/S-CSCF » - qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d'Abonné de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les capacités requises pour pouvoir fournir tous les services autorisés pour l'utilisateur du dispositif-client. Ces « capacités » sont définies de manière précise dans le Chapitre 6.7 de la spécification TS 29.228 du 3GPP (cf. notamment la Table 6.7). Les serveurs HSS sont l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation de Rattachement ») utilisés dans les réseaux GSM. Chaque serveur HSS peut accéder à une base de données-clients, définie dans la spécification TS 23.008 du 3GPP (cf. notamment la Section 3) : ces données-client concernent par exemple, pour chaque utilisateur du réseau IMS, l'état d'enregistrement du dispositif-client associé, ainsi que des données d'authentification et de localisation. Dans le cadre de la présente invention, une telle base de données (qu'elle obéisse ou non à la spécification TS 23.008) sera désignée par « profil de l'utilisateur ». Après qu'un serveur S-CSCF lui a été ainsi attribué, chaque utilisateur peut faire usage d'un certain nombre de services pendant la connexion en cours. Il peut par exemple s'agir de services offerts automatiquement à tous les utilisateurs du réseau IMS. Il peut aussi s'agir de services auxquels cet utilisateur a souscrit auprès de l'opérateur du réseau, et qui sont mis automatiquement à sa disposition. Enfin, il peut s'agir de services dont l'utilisateur peut faire usage après avoir émis une requête appropriée (SIP SUBSCRIBE). Ces services comprennent des applications audiovisuelles telles que mentionnées ci-dessus. Il peut s'agir également d'une souscription à l'état d'une ressource, auquel cas des notifications d'évènement (SIP NOTIFY) sont envoyées au dispositif-client dès lors que l'état de la ressource change ; par exemple, lorsque l'utilisateur d'un dispositif-client dispose d'une boîte vocale sur le réseau, il pourra être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; un utilisateur peut, 3 0046 12 5 de même, demander à être notifié de l'état d'enregistrement de son propre dispositif-client. Le 3GPP a défini dans la spécification TS 23.380 une procédure de restauration du service IMS en cas de panne d'un serveur S-CSCF. En 5 particulier, cette spécification propose dans sa Section 4.3.3 la sélection par un serveur I-CSCF d'un nouveau serveur S-CSCF pour le traitement des appels arrivés, de telle sorte qu'un utilisateur dont le serveur S-CSCF nominal est tombé en panne ne s'aperçoive pas de la panne et que les appels qui lui sont destinés continuent à lui être délivrés (la notion de 10 serveur S-CSCF « nominal » est définie dans la Section 3.2.2 de la spécification TS 23.008 mentionnée ci-dessus). Or les auteurs de la présente invention ont réalisé que, si cette procédure de restauration est adéquate dans le cas d'un réseau IMS comprenant un serveur I-CSCF unique et apte à sélectionner toujours le 15 même serveur S-CSCF de remplacement, elle est inadéquate dans le cas d'un réseau IMS usuel, lequel comprend, soit plusieurs serveurs I-CSCF (cas le plus fréquent, pour des raisons de capacité du réseau), soit un unique serveur I-CSCF (du type « proxy stateless ») pouvant a priori sélectionner des serveurs S-CSCF de remplacement différents d'une 20 requête de service à l'autre. Par exemple, lorsque le réseau comprend plusieurs serveurs ICSCF, ces serveurs I-CSCF se trouvent en concurrence mutuelle sur les procédures de restauration. Ce problème est illustré ci-dessous par un exemple, en référence à la figure 1. 25 Lors d'une étape El, une requête de service (N° 1) visant un certain utilisateur d'un réseau IMS est reçue par un serveur I-CSCF (N° 1) de ce réseau. Lors d'une étape E2, ce serveur I-CSCF N° 1 initie une procédure dite « première procédure de localisation » (message « Diameter LIR ») vers le serveur HSS en charge dudit utilisateur, pour connaître l'identité du serveur S-CSCF (N° 1) nominal associé à cet utilisateur. Lors d'une étape E3, le serveur HSS répond au serveur I-CSCF N° 1 (message « Diameter LIA ») en fournissant un identifiant du serveur S- CSCF nominal ; il s'agit par exemple d'un serveur S-CSCF appelé « S3 ». Cette « première » procédure de localisation, mise en oeuvre aux étapes E2 et E3, est décrite dans la spécification TS 29.228 (mentionnée ci-dessus) au Chapitre 6.1.4 (cf. notamment la Table 6.1.4.1). Dans les échanges « Diameter » entre un serveur I-CSCF et un serveur HSS, l'utilisateur est identifié au moyen de son IMPU (initiales des mots anglais « IP Multimedia PUblic identity » signifiant « Identité Publique pour IP Multimédia »). Lors d'une étape E4, le serveur I-CSCF N° 1 tente de joindre le serveur S-CSCF S3 pour lui transmettre la requête N° 1, mais la tentative 15 échoue ; cela peut être dû à une panne du serveur S-CSCF S3, ou à une panne du lien entre le serveur I-CSCF N° 1 et le serveur S-CSCF S3. Lors d'une étape E5, le serveur I-CSCF N° 1 initie donc une procédure de restauration conformément à la spécification TS 23.380 mentionnée ci-dessus. Pour ce faire, le serveur I-CSCF N° 1 initie une 20 « deuxième procédure de localisation », dans laquelle le serveur I-CSCF N° 1 envoie une « requête de capacités » (deuxième message « Diameter LIR ») au serveur HSS, afin de savoir quelles capacités un serveur SCSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour cet utilisateur. 25 Lors d'une étape E6, le serveur HSS répond au serveur I-CSCF N° 1 (deuxième message « Diameter LIA ») en indiquant quelles sont lesdites capacités. Lors d'une étape E7, le serveur I-CSCF N° 1 sélectionne un nouveau serveur S-CSCF (S-CSCF N° 2) ayant les capacités requises 30 pour fournir l'ensemble des services autorisés pour cet utilisateur ; supposons par exemple que le serveur S-CSCF sélectionné porte l'identifiant « S2 ». Le serveur I-CSCF N° 1 fait ensuite suivre la requête N° 1 vers ce serveur S-CSCF N° 2 (i.e., S2). Lors d'une étape E8, une nouvelle requête de service (N° 2), visant le même utilisateur que la requête de service N° 1, est reçue par un serveur I-CSCF (N° 2) du réseau IMS ; on notera que ce serveur I-CSCF N° 2 peut éventuellement être identique au serveur I-CSCF N 01. Lors d'une étape E9, analogue à l'étape E2 ci-dessus, le serveur ICSCF N° 2 initie une « première » procédure de localisation (message « Diameter LIR ») vers le serveur HSS en charge dudit utilisateur pour connaître l'identité du serveur S-CSCF (N° 1) nominal associé à cet utilisateur. Lors d'une étape E10, analogue à l'étape E3 ci-dessus, le serveur HSS répond au serveur I-CSCF N° 2 (message « Diameter LIA ») en fournissant un identifiant du serveur S-CSCF nominal, i.e. S3. Lors d'une étape El 1, analogue à l'étape E4 ci-dessus, le serveur I-CSCF N° 2 tente de joindre le serveur S-CSCF S3 pour lui transmettre la requête N° 2, et la tentative échoue. Parallèlement, lors d'une étape E12, le serveur S-CSCF N° 2 met à 20 jour le serveur HSS avec sa propre référence (i.e., S2) (message « Diameter SAR »), puisque, suite à l'étape E7 ci-dessus, ce serveur SCSCF S2 considère qu'il est dorénavant le serveur S-CSCF nominal pour ledit utilisateur. Le serveur HSS confirme cette mise à jour (message « Diameter SAA »). 25 Lors d'une étape E13, analogue à l'étape E5 ci-dessus, le serveur I- CSCF N° 2 envoie une requête de capacités (deuxième message « Diameter LIR ») au serveur HSS, afin de savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour cet utilisateur. Lors d'une étape E14, analogue à l'étape E6 ci-dessus, le serveur HSS répond au serveur I-CSCF N° 2 (deuxième message « Diameter LIA ») en indiquant quelles sont lesdites capacités. Lors d'une étape E15, analogue à l'étape E7 ci-dessus, le serveur I- CSCF N° 2 sélectionne un nouveau serveur S-CSCF (N° 3) ayant les capacités requises pour pouvoir fournir l'ensemble des services autorisés pour cet utilisateur ; il s'agit par exemple d'un serveur S-CSCF appelé « S4 ». En effet, selon l'état de l'art, le serveur S-CSCF N° 3 sélectionné par le serveur I-CSCF N° 2 peut, le cas échéant, être identique au serveur S-CSCF N° 2, mais peut aussi bien en être distinct. Le serveur I-CSCF N° 2 fait ensuite suivre la requête N° 2 vers ce serveur S-CSCF N° 3 (i.e., S4). Lors d'une étape E16, analogue à l'étape E12 ci-dessus, le serveur S-CSCF N° 3 met alors à jour le serveur HSS avec sa propre référence (i.e., S4) (message « Diameter SAR »), puisque, suite à l'étape E15 précédente, ce serveur S-CSCF S4 considère qu'il est dorénavant le serveur S-CSCF nominal pour ledit utilisateur. Le serveur HSS confirme cette mise à jour (message « Diameter SAA »). Mais, lors d'une étape E17, les appels initiés sur le serveur S-CSCF N° 2 (i.e., S2) sont cassés lorsque le serveur HSS informe ce dernier qu'un nouveau serveur S-CSCF (i.e., S4) est désormais nominalement en charge de l'utilisateur. En effet, dans un réseau IMS, il ne peut y avoir du point de vue du serveur HSS qu'un seul serveur S-CSCF nominal associé à un utilisateur donné. Cet utilisateur risque donc de voir certains de ses appels en arrivée libérés, ce qui peut être très fâcheux, notamment si le trafic à son intention est important (par exemple si ledit utilisateur est une entreprise et son dispositif-client est un PABX). La présente invention concerne donc un procédé de restauration de service dans un réseau IMS, comprenant les étapes suivantes : une requête de service visant un utilisateur dudit réseau IMS est reçue par un serveur I-CSCF de ce réseau IMS, ledit serveur I-CSCF envoie au serveur HSS du réseau IMS en charge dudit utilisateur une requête visant à connaître l'identité du serveur S-CSCF nominal associé audit utilisateur, ledit serveur HSS répond au serveur I-CSCF en fournissant un identifiant dudit serveur S-CSCF nominal, le serveur I-CSCF tente de joindre ce serveur S-CSCF nominal, mais la tentative échoue, et le serveur I-CSCF envoie au serveur HSS une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur. Ledit procédé est remarquable en ce qu'il comprend également les étapes suivantes : le serveur HSS sélectionne un nouveau serveur S-CSCF apte à fournir l'ensemble des services autorisés pour l'utilisateur, enregistre l'assignation à l'utilisateur dudit nouveau serveur SCSCF, et fournit au serveur I-CSCF un identifiant du nouveau serveur S-CSCF assigné à l'utilisateur, et le serveur I-CSCF prend en compte ledit identifiant du nouveau serveur S-CSCF, et fait suivre la requête de service vers ce nouveau serveur S-CSCF. Grâce à l'invention, on peut indiquer à tout serveur I-CSCF ayant reçu une requête de service visant un certain utilisateur, non seulement (de manière classique) l'identité du serveur S-CSCF nominal pour cet utilisateur, mais aussi, suite à une panne de ce serveur S-CSCF nominal, l'identité d'un unique serveur S-CSCF pour traiter les requêtes de service concernant cet utilisateur, à la place du serveur S-CSCF en panne. On évite ainsi les resélections contradictoires selon l'état de l'art, et les pertes d'appels qui en résultent. Selon des caractéristiques particulières, pour enregistrer l'assignation à l'utilisateur dudit nouveau serveur S-CSCF, le serveur HSS inscrit un identifiant de ce nouveau serveur S-CSCF dans un élément d'information dédié du profil de l'utilisateur. Grâce à ces dispositions, si une autre requête de service visant le même utilisateur est ensuite reçue par un deuxième serveur I-CSCF (différent ou non du premier serveur I-CSCF susmentionné), et que ledit deuxième serveur I-CSCF interroge le serveur HSS pour connaître l'identité du serveur S-CSCF nominal associé à cet utilisateur, le serveur HSS pourra avantageusement lire ledit élément d'information, et répondre au deuxième serveur I-CSCF en lui fournissant un identifiant dudit (unique) serveur S-CSCF assigné à l'utilisateur. Corrélativement, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, un serveur HSS d'un réseau IMS, comprenant des moyens pour : recevoir, de la part d'un serveur I-CSCF, une requête visant à connaître l'identité du serveur S-CSCF nominal associé à un utilisateur, dont ledit serveur HSS a la charge, dudit réseau IMS, répondre audit serveur I-CSCF en fournissant un identifiant dudit serveur S-CSCF nominal, et recevoir, de la part du serveur I-CSCF, une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur. Ledit serveur HSS est remarquable en ce qu'il comprend en outre des moyens pour, en réponse à ladite requête de capacités : - sélectionner un nouveau serveur S-CSCF apte à fournir l'ensemble des services autorisés pour l'utilisateur, enregistrer l'assignation à l'utilisateur dudit nouveau serveur SCSCF, et fournir au serveur I-CSCF un identifiant du nouveau serveur SCSCF assigné à l'utilisateur. Les avantages offerts par ce serveur HSS sont essentiellement les mêmes que ceux offerts par le procédé corrélatif succinctement exposé ci-dessus. Selon des caractéristiques particulières, ledit serveur HSS peut accéder à une table d'équivalences dont chaque élément est un couple de serveurs S-CSCF dudit réseau IMS tels que le deuxième (respectivement, premier) serveur S-CSCF de ce couple possède au moins toutes les capacités du premier (respectivement, deuxième) serveur S-CSCF de ce couple. Grâce à ces dispositions, le serveur HSS peut commodément sélectionner un nouveau serveur S-CSCF apte à fournir l'ensemble des services autorisés pour l'utilisateur. L'invention concerne aussi, deuxièmement, un serveur I-CSCF d'un réseau IMS, comprenant des moyens pour : recevoir une requête de service visant un utilisateur dudit réseau IMS, interroger le serveur HSS du réseau IMS en charge dudit utilisateur, pour connaître l'identité du serveur S-CSCF nominal associé audit utilisateur, et envoyer audit serveur HSS une requête de capacités pour savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur. Ledit serveur I-CSCF est remarquable en ce qu'il comprend en outre des moyens pour : recevoir de la part du serveur HSS, en réponse à ladite requête de capacités, un identifiant d'un nouveau serveur S-CSCF assigné à l'utilisateur, et faire suivre ladite requête de service vers ledit nouveau serveur S- CSCF assigné à l'utilisateur. Les avantages offerts par ce serveur I-CSCF sont essentiellement les mêmes que ceux offerts par le procédé corrélatif succinctement exposé ci-dessus. Selon des caractéristiques particulières, ledit serveur I-CSCF peut accéder à une table d'équivalences dont chaque élément est un couple de serveurs S-CSCF dudit réseau I MS tels que le deuxième (respectivement, premier) serveur S-CSCF de ce couple possède au moins toutes les capacités du premier (respectivement, deuxième) serveur S-CSCF de ce couple. Grâce à ces dispositions, le serveur HSS pourra commodément fournir au serveur I-CSCF ledit identifiant d'un nouveau serveur S-CSCF assigné à l'utilisateur, sous la forme d'un index pointant vers un élément de ladite table d'équivalences. On notera qu'il est possible de réaliser les dispositifs succinctement décrits ci-dessus dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de restauration de service succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1, décrite ci-dessus, illustre schématiquement les étapes successives d'un procédé classique de restauration de service en cas de panne d'un serveur S-CSCF, - la figure 2 représente schématiquement, à titre d'exemple, un système pour la fourniture de services multimédia apte à mettre en oeuvre l'invention, et - la figure 3 illustre schématiquement les étapes successives d'un procédé de restauration de service en cas de panne d'un serveur SCSCF, selon un mode de réalisation de l'invention. Le système illustré sur la figure 2 met en oeuvre une architecture de réseau de type IMS 1, tel que présenté succinctement ci-dessus. Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un dispositif-client (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1, qui permet à l'UE 10 d'échanger des flux multimédias et des signaux de contrôle de session conformes au protocole SIP, par exemple avec un UE 11. Cet UE 10 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel. Comme le montre la figure 2, ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) : - au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés - - 15 - 20 - 25 - au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la signalisation entre l'UE 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 ; au moins un serveur I-CSCF ; le serveur I-CSCF 22 gère notamment le routage en direction d'autres dispositifs-clients gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux ; au moins un serveur P-CSCF (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Mandataire ») ; le serveur P-CSCF 21 sert d'entité de raccordement entre le réseau 1 et le réseau d'accès utilisé par l'UE 10 ; le serveur P-CSCF 28 sert d'entité de raccordement entre le réseau 1 d'une part, et l'UE 11 ou un réseau d'accès utilisé par l'UE 11 d'autre part ; toute la signalisation SIP échangée entre l'UE 10 (respectivement 11) et le serveur S-CSCF 27 passe par le serveur PCSCF 21 (respectivement 28) ; au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l'utilisateur de l'UE 10 en termes de données d'authentification, de localisation et de services souscrits ; au moins un serveur VM 25 de messagerie vocale (« messagesummary » en anglais) ; le serveur VM 25 gère une éventuelle souscription de l'UE 10 aux événements de dépôt/consultation des messages à l'intention de l'utilisateur de l'UE 10, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ; au moins un serveur de Messagerie Instantanée IM 26 (mentionné ci-dessus) ; en cas de souscription de l'utilisateur de l'UE 10 au service de Messagerie Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d'autres utilisateurs de ce service ; et - au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les éventuels services téléphoniques auxquels l'utilisateur de l'UE 10 a souscrits auprès de l'opérateur du réseau 1, tels que la présentation du numéro ou le renvoi d'appel. Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de ce que l'on appelle des AS (initiales des mots anglais « Application Servers » signifiant « Serveurs d'Applications »). Selon la norme TS 24.229 du 3GPP (cf. notamment, dans la version 11.5.0 de cette norme, la clause 5.4.3.3, items 3C and 3D, ainsi que l'Annexe I), lorsque le S-CSCF 27 reçoit du serveur I-CSCF 22 une requête de service visant l'utilisateur qui a préalablement enregistré l'UE 10: le S-CSCF 27 vérifie que ce service est conforme à la souscription de cet utilisateur auprès de l'opérateur du réseau 1, et en cas de conformité, le S-CSCF 27 fait suivre la requête vers une adresse de contact adéquate de l'UE 10 ; par exemple, si l'UE 10 est un téléphone de VoIP, et si le service requis est un appel téléphonique vers le numéro de téléphone de l'utilisateur de l'UE 10, ladite adresse de contact est habituellement une adresse IP associée audit numéro de téléphone. Afin, notamment, de remédier aux problèmes exposés ci-dessus en référence à la figure 1, l'invention propose un nouveau procédé de restauration de service pour la gestion des requêtes en arrivée. La figure 3 illustre un mode de réalisation de ce procédé selon l'invention. Les étapes El à E'5 sont analogues aux étapes El à E5 décrites ci-dessus en référence à la figure 1. Lors d'une étape E'6, contrairement à l'état de l'art, c'est le serveur HSS qui sélectionne le nouveau serveur S-CSCF à assigner à l'utilisateur 30 pour remplacer le serveur S-CSCF nominal en panne. Pour ce faire, le serveur HSS exploite une table d'équivalences selon l'invention, à laquelle il a accès. Cette table contient des équivalences en termes de « capacités » Cl, où i = 1,2, ..., telles que mentionnées ci-dessus, de l'ensemble des serveurs S-CSCF ou d'une partie d'entre eux (en fait, la spécification TS 29.228 distingue des capacités obligatoires et des capacités optionnelles, mais la présente invention ne vise que les capacités obligatoires). La table d'équivalences peut être construite de la manière suivante. La première colonne de cette table représente une liste de serveurs S- CSCF. Une deuxième colonne indique, sur la même ligne qu'un serveur S-CSCF donné de la première colonne, un serveur S-CSCF « équivalent », c'est-à-dire un serveur S-CSCF possédant au moins les capacités dudit serveur S-CSCF donné, et qui donc pourra remplacer ce serveur S-CSCF donné en cas de panne. Selon une première variante, la table d'équivalences comprend en outre une troisième colonne contenant un index référençant chaque couple S-CSCF/S-CSCF-équivalent. Dans cette première variante, le contenu de la table d'équivalences est connu, non seulement du serveur HSS, mais aussi de l'ensemble des serveurs I-CSCF du réseau I MS. Selon une deuxième variante, la table d'équivalences ne comprend pas cette troisième colonne. Dans cette deuxième variante, le contenu de la table d'équivalences est connu du serveur HSS, mais n'est pas partagé avec les serveurs I-CSCF. Prenons par exemple un ensemble de quatre serveurs S-CSCF ayant les capacités suivantes : Si [C1, C2, C3], S2 [C1, C2, C3], S3 [C1], et S4 [C1, C2]. Si l'on choisit par exemple la première variante mentionnée ci-dessus, la table d'équivalences se présente alors ainsi : 51 S2 1 S2 51 2 S3 51 3 S3 S2 4 S3 S4 5 S4 51 6 S4 S2 7 On voit par exemple que S4 possède un équivalent en 51 (index 6), mais que 51 quant à lui ne possède pas d'équivalent en S4 puisqu'il manque à S4 la capacité C3 pour retrouver l'ensemble des capacités de 51. Dans l'exemple de réalisation considéré, c'est le serveur S-CSCF S3 qui avait été nominalement associé à l'utilisateur. Le serveur HSS peut donc sélectionner le serveur S-CSCF 51 (index 3), ou le serveur S-CSCF S2 (index 4), ou encore le serveur S-CSCF S4 (index 5) en remplacement du serveur S-CSCF S3. Supposons que le serveur HSS sélectionne le serveur S-CSCF 51. Le serveur HSS met alors à jour le profil de l'utilisateur en conséquence, par exemple en inscrivant un identifiant du serveur S-CSCF 51 dans un champ « S-CSCF-Restoration-lnfo », tel que défini dans la spécification TS 29.229 du 3GPP ; plus précisément, ce champ « S-CSCF-RestorationInfo » devra, pour la mise en oeuvre de la présente invention, comporter un élément d'information dédié, dans lequel le serveur HSS inscrira ledit identifiant. On notera au passage que si, ultérieurement, le serveur HSS reçoit une requête de capacités concernant un autre utilisateur auquel était également associé le serveur S-CSCF S3 en tant que serveur S-CSCF nominal, le serveur HSS pourra avantageusement sélectionner (par exemple) le serveur S-CSCF S2 pour cet autre utilisateur, cela afin de réaliser un partage de charge vers l'ensemble des serveurs S-CSCF équivalents à S3. Le HSS répond alors au serveur I-CSCF N° 1 (deuxième message « Diameter LIA ») en lui fournissant un identifiant du nouveau serveur S- CSCF (i.e., S1) assigné à l'utilisateur. Plus précisément, dans le cadre de la première variante mentionnée ci-dessus, le serveur HSS recherche le serveur S-CSCF S3 dans la table d'équivalences, y trouve l'information d'équivalence avec S1, lit l'index correspondant (à savoir, « 3 ») et envoie cet index « 3 » au serveur I-CSCF N° 1 pour lui indiquer la sélection du serveur S-CSCF S1. Dans le cadre de la deuxième variante mentionnée ci-dessus, le serveur HSS envoie au serveur I-CSCF N°1, sous une autre forme que ledit index, un identifiant dudit serveur S-CSCF (i.e., S1) que le serveur HSS a sélectionné ; l'avantage de cette deuxième variante réside dans le fait qu'il n'est pas nécessaire de partager la table d'équivalences avec les serveurs I-CSCF, d'où une économie en termes de stockage et de coûts d'exploitation par rapport à la première variante. Lors d'une étape E'7, contrairement à l'état de l'art, le serveur ICSCF N° 1 reçoit cet identifiant de la part du serveur HSS et le prend en 20 compte. Le serveur I-CSCF N° 1 fait donc suivre la requête de service N°1 vers le serveur S1 en tant que serveur S-CSCF N°2. Lors d'une étape E'8, analogue à l'étape E8 décrite ci-dessus en référence à la figure 1, une nouvelle requête de service (N° 2) visant le même utilisateur que la requête de service (N° 1) est reçue par un 25 deuxième serveur I-CSCF (N° 2) du réseau IMS (ce deuxième serveur ICSCF (N° 2) pouvant être différent ou non du premier serveur I-CSCF (N°1)). Lors d'une étape E'9, analogue à l'étape E9 décrite ci-dessus en référence à la figure 1, le serveur I-CSCF N° 2 initie une « première » procédure de localisation (message « Diameter LIR ») vers le serveur HSS. Lors d'une étape El 0, analogue à l'étape E10 décrite ci-dessus en référence à la figure 1, le serveur HSS répond au serveur I-CSCF N° 2 en lui fournissant un identifiant du nouveau serveur S-CSCF assigné à l'utilisateur (i.e., S1). Lors d'une étape E' 11, le serveur I-CSCF N° 2 reçoit cet identifiant de la part du serveur HSS et le prend en compte. Il fait donc suivre la requête N° 2 vers le serveur S-CSCF S1, c'est-à-dire vers le même serveur S-CSCF que celui à qui le serveur I-CSCF N° 1 a fait suivre la requête N° 1. Parallèlement, lors d'une étape E'12, analogue à l'étape E12 décrite ci-dessus en référence à la figure 1, le serveur S-CSCF N° 2 met alors à jour le serveur HSS avec sa propre référence (i.e., S1) (message « Diameter SAR »), de sorte que le serveur S-CSCF N° 2 est désormais le serveur S-CSCF nominal en charge dudit utilisateur. Le serveur HSS confirme cette mise à jour (message « Diameter SAA »). On voit donc que, grâce à l'invention, les risques de sélection de serveurs S-CSCF de restauration multiples sont évités ; les libérations précoces ou les pertes d'appels sont donc également évitées. La mise en oeuvre de l'invention au sein de noeuds d'un réseau IMS, notamment au sein de serveurs HSS et I-CSCF, peut être réalisée au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de restauration de service selon l'invention. En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de restauration de service selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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, inamovible, ou 15 partiellement ou totalement amovible, 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 20 comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). D'autre part, le support d'informations peut être un support 25 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 d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré 30 dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de restauration de service selon l'invention. REVENDICATIONS1. Procédé de restauration de service dans un réseau IMS, comprenant les étapes suivantes : une requête de service (N° 1) visant un utilisateur dudit réseau IMS (1) est reçue (E'1) par un serveur I-CSCF (N ° 1) de ce réseau IMS (1), ledit serveur I-CSCF (N° 1) envoie (E'2) au serveur HSS du réseau IMS (1) en charge dudit utilisateur une requête visant à connaître l'identité du serveur S-CSCF (N° 1) nominal associé audit utilisateur, - ledit serveur HSS répond (E'3) au serveur I-CSCF (N° 1) en fournissant un identifiant dudit serveur S-CSCF (N° 1) nominal, - le serveur I-CSCF (N° 1) tente (E'4) de joindre ce serveur S-CSCF nominal (N ° 1), mais la tentative échoue, et le serveur I-CSCF (N° 1) envoie (E'5) au serveur HSS une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur, caractérisé en ce qu'il comprend également les étapes suivantes : le serveur HSS sélectionne (E'6) un nouveau serveur S-CSCF (N° 2) apte à fournir l'ensemble des services autorisés pour l'utilisateur, enregistre l'assignation à l'utilisateur dudit nouveau serveur SCSCF (N° 2), et fournit au serveur I-CSCF (N° 1) un identifiant du nouveau serveur S-CSCF (N ° 2) assigné à l'utilisateur, et le serveur I-CSCF (N° 1) prend en compte (E'7) ledit identifiant du nouveau serveur S-CSCF (N ° 2), et fait suivre la requête de service (N ° 1) vers ce nouveau serveur S-CSCF (N ° 2). 2. Procédé de restauration de service selon la revendication 1, caractérisé en ce que, pour enregistrer l'assignation à l'utilisateur duditnouveau serveur S-CSCF (N° 2), le serveur HSS inscrit un identifiant de ce nouveau serveur S-CSCF (N° 2) dans un élément d'information dédié du profil de l'utilisateur. 3. Serveur HSS d'un réseau IMS, comprenant des moyens pour : recevoir, de la part d'un serveur I-CSCF (N° 1), une requête visant à connaître l'identité du serveur S-CSCF (N° 1) nominal associé à un utilisateur, dont ledit serveur HSS a la charge, dudit réseau IMS (1), - répondre audit serveur I-CSCF (N° 1) en fournissant un identifiant dudit serveur S-CSCF (N° 1) nominal, et - recevoir, de la part du serveur I-CSCF (N ° 1), une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur, caractérisé en ce qu'il comprend en outre des moyens pour, en réponse à ladite requête de capacités : sélectionner un nouveau serveur S-CSCF (N° 2) apte à fournir l'ensemble des services autorisés pour l'utilisateur, enregistrer l'assignation à l'utilisateur dudit nouveau serveur S- CSCF (N° 2), et fournir au serveur I-CSCF (N° 1) un identifiant du nouveau serveur S-CSCF (N° 2) assigné à l'utilisateur. 4. Serveur HSS selon la revendication 3, caractérisé en ce qu'il peut accéder à une table d'équivalences dont chaque élément est un couple de serveurs S-CSCF dudit réseau IMS (1) tels que le deuxième (respectivement, premier) serveur S-CSCF de ce couple possède au moins toutes les capacités du premier (respectivement, deuxième) serveur S-CSCF de ce couple. 5. Serveur I-CSCF d'un réseau IMS, comprenant des moyens pour : recevoir une requête de service visant un utilisateur dudit réseau IMS (1), interroger le serveur HSS du réseau IMS (1) en charge dudit utilisateur, pour connaître l'identité du serveur S-CSCF (N ° 1) nominal associé audit utilisateur, et envoyer audit serveur HSS une requête de capacités pour savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur, caractérisé en ce qu'il comprend en outre des moyens pour : recevoir de la part du serveur HSS, en réponse à ladite requête de capacités, un identifiant d'un nouveau serveur S-CSCF (N ° 2) assigné à l'utilisateur, et faire suivre ladite requête de service vers ledit nouveau serveur S- CSCF (N ° 2) assigné à l'utilisateur. 6. Serveur I-CSCF selon la revendication 5, caractérisé en ce qu'il peut accéder à une table d'équivalences dont chaque élément est un couple de serveurs S-CSCF dudit réseau IMS (1) tels que le deuxième (respectivement, premier) serveur S-CSCF de ce couple possède au moins toutes les capacités du premier (respectivement, deuxième) serveur S-CSCF de ce couple. 7. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de restauration de service selon la revendication 1 ou la revendication 2. 8. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend desinstructions pour l'exécution des étapes d'un procédé de restauration de service selon la revendication 1 ou la revendication 2, lorsqu'il est exécuté sur un ordinateur.