Brevet FR3067539A1 — publié le 20181214

Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement les coeurs de réseaux IP multimédia. L'invention a une application privilégiée mais non limitative dans le contexte des coeurs de réseau IP multimédia mettant en oeuvre le protocole d'initiation de session SIP (Session Initiation Protocol) défini par le standard IETF (Internet Engineering Task Force) et décrit dans le document RFC 3261 intitulé « SIP: Session Initiation Protocol », Juin 2002, édité par l'IETF. Elle s'applique notamment aux coeurs de réseau IP multimédia s'appuyant sur une architecture IMS (IP Multimedia Subsystem) telle que proposée par le standard 3GPP (Third Generation Partnership Project). Toutefois, l'invention peut également être utilisée en association avec d'autres architectures de coeurs de réseau IP multimédia, telles que par exemple des architectures propriétaires, mettant en oeuvre ou non le protocole SIP pour l'établissement de sessions multimédia (voix, texte, vidéo, données, etc.), ou des architectures basées sur le standard web de communication en temps réel WebRTC (Web Real Time Communication). Les coeurs de réseau IP multimédia, et notamment les coeurs de réseaux IMS, sont prévus pour supporter de multiples services de communication, comme par exemple des services de téléphonie (ex. voix sur IP ou VoIP pour « Voice over IP »), de télévision et vidéo à la demande, de communication enrichie (aussi appelés RCS pour Rich Communication Suite). Ces multiples services de communication s'appuient avantageusement sur l'utilisation d'une même identité publique allouée au client, qui est typiquement le numéro MSISDN (Mobile Station Integrated Services Digital Network) pour un réseau mobile et le numéro de téléphone fixe pour un réseau fixe. Cette identité publique peut être partagée par plusieurs terminaux ou plus généralement dispositifs de communication distincts du client. Pour gérer ces multiples services de communication, un coeur de réseau IMS implémente une pluralité de fonctions, intégrées au sein d'un ou de plusieurs équipements du réseau, et comprenant notamment : - une fonction ou serveur de gestion d'abonnés ou HSS (pour Home Service Subscriber), qui contient la liste des clients du coeur de réseau ainsi que leur profil ; une fonction ou serveur P-CSCF (Proxy Call State Control Function), qui joue le rôle de point d'entrée sur le coeur de réseau des terminaux des clients ; une fonction ou serveur S-CSCF (Session Call State Control Function), en charge de l'enregistrement des terminaux et du routage des messages SIP entrants émis par ces terminaux ou des messages SIP sortants destinés à ces terminaux ; une fonction ou serveur I-CSCF (Interrogating Call Control Function), apte à déterminer pour chaque terminal enregistré auprès du coeur de réseau l'adresse du serveur S-CSCF gérant ce terminal ; 2 - un ou plusieurs serveurs d'application AS (Application Server) en charge du traitement des différents services proposés par le coeur de réseau ; et - des équipements d'interconnexion avec d'autres (coeurs de) réseaux. Le routage, via ces différentes fonctions, des communications relatives aux multiples 5 services proposés par un coeur de réseau IMS est normalisé et défini dans le document 3GPP 24.229. Il se déroule de la façon suivante. Un terminal émetteur ou appelant s'enregistre auprès de son coeur de réseau IMS (désigné dans la suite par coeur de réseau appelant) et émet une requête SIP à destination d'une identité publique d'un terminal récepteur ou appelé, contenue dans un champ SIP Request URI 10 (Uniform Resource Identifier) de la requête. La requête SIP est présentée au serveur S-CSCF du coeur de réseau appelant gérant l'utilisateur du terminal émetteur. Le serveur S-CSCF extrait le contenu du champ Request URI de la requête, et le normalise selon le format E164 International ; par exemple, si le contenu de la Request URI est un numéro de téléphone mobile 0686166924, le format E164 correspondant est composé du préfixe 15 +33 suivi du numéro de téléphone mobile sans le « 0 », soit +33686166924. Le format E164 est ensuite inversé et transformé en un nom de domaine (dans l'exemple du numéro de téléphone mobile précédent, ce nom de domaine est 4.2.9.6.6.1.6.8.6.3.3.arpa.net). Puis le serveur S-CSCF interroge un serveur DNS (Domain Name Server) géré par le coeur de réseau appelant implémentant par exemple le mécanisme ENUM. 20 Si le serveur DNS ENUM interrogé contient un identifiant SIP ou URI SIP (pour Uniform Resource Identifier) correspondant au nom de domaine qui lui a été fourni par le serveur S-CSCF (par exemple, URI SIP = +3368166924@ims.mnc001.mcc208.3gppnetwork.org), il retourne cet identifiant SIP au serveur S-CSCF. Cela signifie que le terminal appelé appartient au même domaine IMS que le terminal appelant, autrement dit, est rattaché au même coeur de réseau IMS 25 (i.e. coeur de réseau appelé identique au coeur de réseau appelant). Dans ce cas, le serveur S-CSCF route la requête SIP vers le serveur I-CSCF (qui peut être co-localisé avec le serveur S-CSCF), après avoir modifié préalablement son champ Request URI pour y insérer l'identifiant SIP qui lui a été envoyé par le serveur DNS. Le serveur I-CSCF interroge le serveur de gestion d'abonnés HSS du coeur de réseau appelant en utilisant l'identifiant 30 SIP contenu dans le champ Request URI, et obtient en réponse l'adresse du serveur S-CSCF gérant le terminal appelé (qui peut être ou non le même que le serveur S-CSCF gérant le terminal appelant). Le serveur I-CSCF route ensuite la requête SIP vers le serveur S-CSCF gérant le terminal appelé. Deux cas de figure se présentent alors : 35 soit un unique terminal est enregistré auprès du coeur de réseau appelant avec l'identité publique : la requête SIP est alors transmise à cet unique terminal, qui y répond. La réponse SIP est retournée au terminal appelant via le chemin inverse de celui emprunté par la requête ; 3 soit l'identité publique est partagée au sein du coeur de réseau appelant par plusieurs terminaux (i.e. plusieurs adresses de contact associées respectivement à plusieurs terminaux sont enregistrées au niveau du serveur S-CSCF pour l'identité publique) : le serveur S-CSCF ou un serveur d'application du coeur de réseau appelant, via une fonction de réplication (ou 5 « forking » en anglais), réplique la requête SIP en autant de requêtes que de terminaux enregistrés et transmet vers les terminaux enregistrés les répliques de la requête SIP. Il reçoit une ou plusieurs réponses en retour et élabore une ou plusieurs réponses à partir des réponses reçues qu'il transmet à destination du terminal appelant. La ou les réponses SIP sont retournées au terminal appelant via le chemin inverse de celui emprunté par la requête. 10 Si au contraire le serveur DNS interrogé par le serveur S-CSCF du terminal appelant ne contient pas d'identifiant SIP correspondant au nom de domaine qui lui a été fourni, cela signifie que le terminal appelé n'appartient pas au même domaine IMS que le terminal appelant, autrement dit, il n'est pas rattaché au même coeur de réseau (i.e. coeur de réseau appelé distinct du coeur de réseau appelant). 15 Dans ce cas, le serveur S-CSCF route la requête SIP vers une fonction interne appelée BGCF (Breakout Gateway Control Function) qui applique un routage défini par défaut à la requête SIP vers le coeur de réseau appelé. Ce routage par défaut s'appuie sur une route sélectionnée parmi un ensemble de routes préconfigurées, en fonction par exemple du préfixe de l'identité publique incluse dans la requête et/ou d'un préfixe de portabilité de numéro et/ou d'un préfixe dit 20 de routage technique (ou RN pour Routable Number). Ainsi, à titre d'exemple, s'il existe des accords d'interconnexion en voix sur IP entre l'opérateur du coeur de réseau appelant et l'opérateur du coeur de réseau appelé (ex. les deux coeurs de réseau implémentent une architecture IMS et utilisent le protocole SIP) ou si les routes préconfigurées prévoient l'envoi de la requête vers un hub utilisant le protocole SIP, alors la 25 fonction BGCF route la requête SIP vers un serveur d'interconnexion IBCF (Interconnect Border Control Function) du coeur de réseau appelant assurant l'interconnexion avec le coeur de réseau appelé. Le flux média est quant à lui routé vers un serveur d'interconnexion IBGF (Interconnect Border Gateway Function). Selon un autre exemple, s'il existe des accords d'interconnexion en mode circuit et 30 utilisant le protocole ISUP (ISDN Signalling User Part) entre l'opérateur du coeur de réseau (IMS) appelant et l'opérateur du coeur de réseau (circuit) appelé ou si les routes préconfigurées prévoient l'envoi de la requête vers un hub fonctionnant en mode circuit et utilisant le protocole ISUP, alors la fonction BGCF route la requête SIP vers un serveur d'interconnexion MGCF (Media Gateway Control Function) du coeur de réseau appelant assurant une fonction de passerelle protocolaire 35 entre le protocole SIP utilisé par le coeur de réseau IMS appelant et le protocole ISUP utilisé par le coeur de réseau circuit appelé pour l'interconnexion entre les deux coeurs de réseau. Le flux média est quant à lui routé vers un serveur d'interconnexion MGW (Media GateVVay) assurant une fonction de passerelle entre le protocole RTP (Real Time Protocol) et le mode circuit. 4 L'architecture IMS, et les mécanismes qui ont été normalisés pour cette architecture dont notamment le mécanisme de routage rappelé ci-dessus, ont été initialement conçus dans l'idée de porter tous les services de communication auxquels est susceptible de souscrire un même client au sein d'un même coeur de réseau IMS, ce client pouvant utiliser, pour bénéficier de ces 5 services, un ou de plusieurs dispositifs de communication partageant son identité publique. Or la multiplicité et la diversité des services de communication proposés aujourd'hui (ex. voix sur IP, voix sur LTE (VoLTE) ou sur WiFi (VoWiFi), services RCS (Rich Communication Suite) de messagerie, de partage de vidéo, etc.) par qui plus est, une pluralité de fournisseurs de service, font qu'il est difficile voire inconcevable à court terme pour les opérateurs de 10 télécommunications de déployer des coeurs de réseau supportant simultanément tous ces services. On s'oriente donc vers le déploiement de plusieurs coeurs de réseau « concurrents », supportant potentiellement chacun des services différents et complémentaires, et qui nécessitent l'installation au niveau des terminaux d'autant de piles de protocoles IMS distinctes, chaque pile de protocole IMS étant paramétrée pour communiquer sur un domaine IMS différent (et donc avec un coeur de 15 réseau IMS différent). Ainsi, un coeur de réseau IMS A géré par un opérateur OPA sera en mesure de supporter et de proposer à un client des services de type VoLTE ou VoWiFi, tandis qu'un autre coeur de réseau IMS B géré par un opérateur OPB pourra supporter et proposer à ce même client des services de type RCS. Si le client veut pouvoir accéder à la fois à des services de type VoLTE 20 ou VoWiFi et à des services de type RCS avec un même dispositif de communication, celui-ci devra être équipé de deux piles de protocoles IMS distinctes lui permettant de s'enregistrer et de communiquer respectivement sur les coeurs de réseau A et B. L'enregistrement des deux piles IMS distinctes du dispositif de communication auprès des deux coeurs de réseau A et B basé sur une identité publique allouée au client ne pose pas en 25 soi de difficulté avec le protocole SIP (même si un regain de la consommation de la batterie du dispositif de communication peut être à déploré). En revanche, des problèmes peuvent se poser dans ce contexte « bi-coeur IMS » quant au routage des communications, en raison notamment du mécanisme de routage standardisé rappelé ci-dessus et de la possibilité offerte par l'architecture IMS à un client de pouvoir en outre disposer de plusieurs terminaux partageant son identité 30 publique au sein d'un même coeur de réseau IMS. De tels problèmes apparaissent notamment dans le cadre de communications vidéo. En effet, plusieurs services vidéo sont aujourd'hui proposés et destinés à inter-fonctionner : vidéo sur LTE (ViLTE) ou sur WiFi (ViWiFi), service RCS de partage de vidéo, service RCS d'appel Vidéo IP, service WebRTC d'appel vidéo, etc. 35 Considérons à titre illustratif dans ce contexte de services vidéo, un utilisateur UA disposant d'un terminal UEA équipé d'une première pile de protocole IMS permettant d'accéder à des services de ViLTE et ViWiFI et enregistré sur le coeur de réseau A de l'opérateur OPA en utilisant une identité publique IMPUA allouée à l'utilisateur UA. Ce même terminal UEA est par 5 ailleurs équipé d'une deuxième pile de protocole IMS permettant d'accéder à des services vidéo RCS proposés par le coeur de réseau B mais qui est temporairement désactivée (en raison par exemple de problème d'accès au coeur de réseau B). Bien que le terminal UEA soit connu du coeur de réseau B, il n'est pas enregistré auprès de celui-ci en raison de cette désactivation temporaire 5 de sa deuxième pile IMS. On considère en outre un terminal UEB d'un utilisateur UB, équipé d'une pile de protocole IMS permettant d'accéder aux services vidéo RCS proposés par l'opérateur OPB, et enregistré auprès du coeur de réseau B de l'opérateur OPB en utilisant l'identité publique IMPUB de l'utilisateur UB. 10 Lorsque l'utilisateur UB compose l'identité publique IMPUA de l'utilisateur UA pour établir une communication vidéo RCS avec celui-ci, un message SIP OPTIONS est transmis par le terminal UEB à destination de l'identité publique IMPUA de sorte à détecter les capacités de communication du ou des terminaux de l'utilisateur UA utilisant cette identité publique. Conformément au mécanisme de routage normalisé rappelé précédemment, lorsque le 15 message SIP OPTIONS arrive au serveur S-CSCF du coeur de réseau B gérant l'utilisateur UEB, comme l'identité publique IMPUA est connue du coeur de réseau B, le message SIP OPTIONS devrait être routé au sein du coeur de réseau B et plus particulièrement vers un serveur S-CSCF du coeur de réseau B gérant l'identité publique IMPUA. Or, comme le terminal UEA n'est pas enregistré auprès du coeur de réseau B, le 20 serveur S-CSCF du coeur de réseau B est dans l'incapacité de lui transmettre le message SIP OPTIONS et répond à celui-ci par un message SIP 480 Temporarily Unavailable. L'utilisateur UB n'est donc pas en mesure d'établir un service de communication vidéo avec l'utilisateur UA. Il en résulte une mauvaise expérience client pour l'utilisateur UB. Selon un deuxième exemple illustratif, considérons maintenant un utilisateur UC 25 disposant de deux terminaux UEC1 et UEC2. Le terminal UEC1 est équipé d'une pile IMS supportant les services ViLTE/ViWiFI et enregistré avec l'identité publique IMPUC de l'utilisateur UC auprès du coeur de réseau A de l'opérateur OPA. Le terminal UEC2 dispose d'une pile IMS supportant les services vidéo RCS et est enregistré avec l'identité publique IMPUC auprès du coeur de réseau B de l'opérateur OPB. 30 Un autre utilisateur UD dispose d'un unique terminal UED équipé d'une pile IMS supportant les services vidéo RCS et enregistré auprès du coeur de réseau B de l'opérateur OPB. Conformément au mécanisme de routage normalisé précité, si le terminal UED envoie via son coeur de réseau B un message SIP OPTIONS de découverte des capacités de communication des terminaux utilisant l'identité publique IMPUC de l'utilisateur UC, seules les 35 capacités du terminal UEC2 lui seront retournées puisque seul le terminal UEC2 est connu et enregistré auprès du coeur de réseau B. De façon similaire, si le terminal UED envoie un message SIP INVITE d'établissement d'une session visiophonique vers l'identité publique IMPUC, seul le terminal UEC2 de l'utilisateur UC recevra ce message et sonnera pour notifier l'utilisateur UC. 6 L'utilisateur UC n'est donc pas en mesure d'exploiter les capacités de visiophonie le cas échéant de son autre terminal UEC1. Il convient de noter que les problèmes identifiés ci-dessus, bien qu'ayant été décrits dans un contexte de terminaux IMS, peuvent également se présenter lorsque l'utilisateur appelé 5 dispose en plus d'un ou de plusieurs terminaux IMS, d'autres terminaux utilisant la même identité publique communiquant par exemple via des infrastructures de coeurs de réseau en mode circuit. En outre, des problèmes similaires se posent pour d'autres architectures de coeurs de réseau IP multimédia que des architectures IMS, typiquement pour des architectures basées sur le standard WebRTC. 10 Objet et résumé de l'invention L'invention propose un mécanisme permettant de remédier notamment aux problèmes précités. Plus particulièrement, elle propose un procédé de traitement d'une requête émise par un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia à destination d'une 15 identité publique allouée à au moins un deuxième dispositif, ledit procédé étant destiné à être mis en oeuvre par un serveur du premier coeur de réseau IP multimédia et comprenant : une étape de vérification si l'identité publique est connue du premier coeur de réseau IP multimédia ; si l'identité publique est connue du premier coeur de réseau IP multimédia : 20 o une étape de réplication de la requête en une première requête et en au moins une seconde requête ; o une étape de déclenchement d'un routage de la première requête au sein du premier coeur de réseau IP multimédia ; et o une étape de déclenchement d'un routage de ladite au moins une deuxième requête 25 selon au moins une route prédéterminée à destination d'au moins une entité d'interconnexion du premier coeur de réseau IP multimédia avec au moins un deuxième coeur de réseau distinct du premier coeur de réseau IP multimédia. Corrélativement, l'invention vise également un serveur apte à traiter une requête émise par un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia à 30 destination d'une identité publique allouée à au moins un deuxième dispositif, ledit serveur comprenant : - un module de vérification configuré pour vérifier si ladite identité publique est connue auprès du premier coeur de réseau IP multimédia ; des modules, activés si ladite identité publique est connue du premier coeur de réseau IP 35 multimédia, et comprenant : o un module de réplication, configuré pour répliquer ladite requête en une première requête et en au moins une deuxième requête ; 7 o un premier module de routage, configuré pour déclencher un routage de la première requête au sein du premier coeur de réseau IP multimédia ; et o un second module de routage, configuré pour déclencher un routage de ladite au moins deuxième requête selon au moins une route prédéterminée à destination d'au 5 moins une entité d'interconnexion du premier coeur de réseau IP multimédia avec au moins un deuxième coeur de réseau distinct du premier coeur de réseau IP multimédia. Autrement dit, l'invention propose, pour exploiter pleinement le contexte multi-coeurs de réseau IP multimédia et multi-dispositifs décrit précédemment, de répliquer la requête envoyée par le dispositif appelant (premier dispositif au sens de l'invention) via le coeur de réseau appelant 10 (premier coeur de réseau au sens de l'invention), uniquement dans le cas où l'identité publique appelée (c'est-à-dire à laquelle la requête est destinée) est connue du coeur de réseau appelant. Les répliques obtenues sont alors routées d'une part, au sein du coeur de réseau appelant, et d'autre part, vers un ou plusieurs autres coeurs de réseau (deuxième(s) coeur(s) de réseau au sens de l'invention) avec lequel le coeur de réseau appelant a des accords d'interconnexion (et plus 15 particulièrement, avec lequel il dispose de moyens d'interconnexion). De cette sorte, il est possible de transmettre la requête du dispositif appelant aux dispositifs de communication partageant l'identité publique rattachés au coeur de réseau appelant et aux dispositifs de communication partageant l'identité publique rattachés à un coeur de réseau distinct du coeur de réseau appelant. Il en résulte que si un utilisateur dispose d'un ou de plusieurs dispositifs de 20 communication équipés de piles de protocoles différentes lui permettant de communiquer sur différents coeurs de réseau, il peut être joignable via ces différentes piles dès lors qu'il est enregistré auprès des coeurs de réseau correspondants. Le traitement de la requête de l'utilisateur est donc optimisé et l'expérience de l'utilisateur s'en voit améliorée. 25 En effet, dans le premier exemple illustratif envisagé précédent, l'invention prévoit l'envoi d'une réplique du message SIP OPTIONS à la pile de protocole IMS permettant d'accéder aux services ViLTE et ViWIFI proposés par le coeur de réseau A, de sorte que le terminal UEB est informé des capacités du terminal UEA concernant ces services ViLTE et ViWIFI même si la pile de protocole IMS permettant d'accéder aux services vidéo RCS proposés par le coeur de réseau B est 30 désactivée. Une communication vidéo entre les terminaux UEA et UEB sera donc quand même possible. Dans le deuxième exemple illustratif, grâce à la réplication du message SIP OPTIONS et aux routages des répliques au sein du coeur de réseau B et vers un serveur d'interconnexion avec le coeur de réseau A, le terminal UED peut être informé des capacités des terminaux UEC1 et 35 UEC2 de l'utilisateur. De même, la réplication du message SIP INVITE et le routage conformément à l'invention, permet aux deux terminaux UEC1 et UEC2 de signaler la session visiophonique entrante à l'utilisateur UC qui peut dès lors choisir l'un ou l'autre de ses terminaux pour établir 8 cette session avec le terminal UED, en fonction de ses préférences ou des capacités de ces derniers. L'invention permet donc de traiter des cas de figure dans lesquels des dispositifs de communication partagent une même identité publique allouée à un utilisateur et sont connus sur 5 une pluralité de coeurs de réseau distincts, tout en tenant compte des spécificités des mécanismes de routage normalisés existants comme celui rappelé précédemment et défini pour l'architecture IMS. L'invention peut de ce fait être intégrée de façon simple dans l'effort de normalisation réalisé dans le cadre de l'architecture IMS de coeurs de réseau IP multimédia. Toutefois, si l'invention a une application privilégiée lorsque le premier coeur de réseau 10 et le deuxième coeur de réseau sont tous les deux des coeurs de réseau IP multimédia (typiquement des coeurs de réseau IMS), elle peut également s'appliquer dans un contexte où l'un des coeurs de réseau avec lequel le coeur de réseau IP multimédia de l'appelant est interconnecté est un coeur de réseau utilisant une autre technologie telle qu'une technologie circuit (qu'il s'agisse d'un coeur de réseau de transit se situant entre le coeur de réseau IP multimédia de l'appelant et le 15 coeur de réseau IP multimédia de l'appelé, ou du coeur de réseau de l'appelé à proprement parler). L'invention permet en outre d'optimiser, dans les cas de figure précités, l'expérience utilisateur et d'offrir à l'utilisateur divers services de communication sur ses dispositifs de communication comme si tous ces dispositifs étaient gérés par un seul et unique coeur de réseau. L'invention offre également la possibilité à des clients de plusieurs coeurs de réseau 20 distincts de bénéficier de tous les services offerts par ces coeurs de réseau et supportés par leurs dispositifs de communication dès lors que des accords d'interconnexion existent entre ces coeurs de réseau distinct. Les opérateurs des coeurs de réseau peuvent ainsi plus aisément mutualiser leurs efforts pour offrir des services complémentaires et attractifs à leurs clients, et accroitre leur satisfaction. 25 En outre, l'invention permet d'assurer une position de repli pour certains services lorsqu'un dispositif de communication d'un utilisateur appelé est injoignable sur le coeur de réseau appelant et ne lui permet pas d'accéder à ce service, en exploitant les capacités d'un deuxième coeur de réseau auprès duquel est enregistré le dispositif de communication de l'utilisateur ou d'un autre dispositif de communication de l'utilisateur enregistré auprès du coeur de réseau appelant ou 30 du deuxième coeur de réseau. Dans un mode particulier de réalisation, le procédé de traitement comprend en outre : une étape de réception d'au moins une réponse en provenance d'au moins un dit deuxième dispositif ; une étape de transmission vers le premier dispositif d'au moins une réponse à ladite requête 35 élaborée à partir d'au moins une dite réponse reçue en fonction d'un type de ladite au moins une réponse reçue. Ladite au moins une réponse reçue lors de l'étape de réception comprend par exemple au moins une réponse reçue via un dit deuxième coeur de réseau IP multimédia. 9 De cette sorte, le premier dispositif peut bénéficier d'une vision d'ensemble des réponses qui ont émises par les différents dispositifs de communication partageant l'identité publique destinataire de la requête, quel que soit le(s) coeur(s) de réseau sur le(s)quel(s) ces dispositifs sont enregistrés le cas échéant (premier ou deuxième(s) coeur(s) de réseau). 5 Différentes stratégies peuvent être adoptées par le serveur du premier coeur de réseau pour élaborer la réponse transmise au premier dispositif. Ainsi, dans un mode particulier de réalisation, ladite au moins une réponse élaborée comprend : toutes les réponses reçues lors de ladite étape de réception ; ou 10 la réponse reçue en premier lors de ladite étape de réception ; ou la meilleure réponse reçue au regard d'un critère prédéfini parmi des réponses reçues lors de ladite étape de réception au cours d'une première période de temps prédéterminée ; une agrégation de contenus extraits des réponses reçues lors de ladite étape de réception au cours d'une deuxième période de temps prédéterminée. 15 Le choix de l'une ou l'autre de ces stratégies peut dépendre, comme mentionné précédemment du type de réponses reçues, mais également d'un type de la requête émise par le premier dispositif. Par exemple, si la requête émise est une requête de découverte des capacités des dispositifs de communication utilisant l'identité publique, la stratégie consistant à agréger les 20 contenus extraits des réponses reçues lors de l'étape de réception au cours de la deuxième période de temps prédéterminée permet au premier dispositif d'avoir une vue quasiment exhaustive des capacités de tous les dispositifs de communication utilisant l'identité publique, qu'ils soient rattachés ou non au même coeur de réseau IP multimédia. Si la requête émise est une requête d'établissement d'une session de communication, 25 la deuxième stratégie permet d'informer le premier dispositif de la réponse du dispositif de communication qui a été sélectionné par l'utilisateur appelé. Dans un mode particulier de réalisation, l'étape de réplication et les étapes de déclenchement des routages sont mises en oeuvre après vérification que ces étapes sont autorisées pour le premier dispositif et/ou pour ledit au moins un deuxième dispositif. 30 Ce mode de réalisation permet d'avoir un traitement différencié des requêtes émises par différents dispositifs sur le premier coeur de réseau. Dans un mode particulier de réalisation, l'étape de déclenchement du routage de la première requête et l'étape de déclenchement du routage de ladite au moins une deuxième requête sont mises en oeuvre simultanément. 35 Ce déclenchement simultané des deux routages permet d'accélérer le traitement de la requête par les deux coeurs de réseau. Comme mentionné précédemment, l'invention a une application privilégiée mais non limitative dans le cadre de coeurs de réseau IP multimédia se basant sur une architecture IMS et 10 utilisant le protocole SIP. Ainsi, dans un mode particulier de réalisation, le premier coeur de réseau IP multimédia met en oeuvre le protocole SIP (Session Initiation Protocol) et l'étape de vérification comprend : - la dérivation d'un nom de domaine à partir de l'identité publique ; et 5 - l'interrogation d'un serveur DNS (Domain Name Server) en utilisant le nom de domaine dérivé ; l'identité publique étant considérée lors de l'étape de vérification comme connue du premier coeur de réseau IP multimédia si un identifiant SIP est reçu du serveur DNS en réponse à son interrogation. 10 Ce mode de réalisation offre une façon simple de contrôler si une identité publique est connue ou non d'un coeur de réseau IMS, et qui s'appuie sur une procédure couramment déployée dans un tel coeur de réseau. En variante, l'étape de vérification peut comprendre la vérification qu'une partie utilisateur de l'identité publique est contenue dans une base de données du premier coeur de 15 réseau IP multimédia. Ce mode de réalisation alternatif a une application privilégiée pour les architectures de coeurs de réseau IP multimédia s'appuyant sur le standard WebRTC, dans lesquelles les serveurs WebRTC des coeurs de réseau maintiennent déjà une telle base de données. Dans un mode particulier de réalisation : 20 le premier coeur de réseau IP multimédia met en oeuvre le protocole SIP et l'étape de déclenchement du routage de ladite au moins une deuxième requête n'est activée que si l'interconnexion entre le premier coeur de réseau IP multimédia et ledit au moins un deuxième coeur de réseau est réalisée en utilisant le protocole SIP ; ou le premier coeur de réseau IP multimédia met en oeuvre au moins un protocole web et l'étape 25 de déclenchement du routage de ladite au moins une deuxième requête n'est activée que si l'interconnexion entre le premier coeur de réseau IP multimédia et ledit au moins un deuxième coeur de réseau est réalisée en utilisant ledit au moins un protocole web. Autrement dit, dans ce mode de réalisation, on privilégie un routage vers un coeur de réseau qui implémente les mêmes protocoles de communication que le coeur de réseau appelant. 30 Ceci permet de s'affranchir de la présence de passerelles protocolaires au niveau du serveur d'interconnexion. L'invention peut être avantageusement mise en oeuvre au niveau de diverses entités du premier coeur de réseau. Par exemple : - si le premier coeur de réseau IP multimédia implémente une architecture IMS (IP Multimedia 35 Subsystem), les étapes de vérification, de réplication et de déclenchement des routages peuvent être mises en oeuvre par un serveur S-CSCF ou par un serveur d'application du premier coeur de réseau IP multimédia ; 11 - si le premier coeur de réseau IP multimédia implémente une architecture WebRTC (Web Real Time Communication), les étapes de vérification, de réplication et de déclenchement des routages peuvent être mises en oeuvre par un serveur WebRTC du premier coeur de réseau IP multimédia. 5 L'invention peut donc être implémentée aisément dans les architectures de coeur de réseau existantes (ex. IMS, WebRTC, etc.), moyennant une adaptation de serveurs déjà présents dans ces architectures. Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs. 10 En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de traitement tel que décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la 15 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 ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 20 Le support d'informations ou d'enregistrement 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. 25 D'autre part, le support d'informations ou d'enregistrement 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 ou d'enregistrement peut être un circuit 30 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. L'invention vise également un système de communication comprenant : un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia, apte à émettre une requête à destination d'une identité publique allouée à au moins un deuxième 35 dispositif ; et un serveur du premier coeur de réseau IP multimédia conforme à l'invention et gérant le premier dispositif. 12 Le système de communication bénéficie des mêmes avantages que ceux cités précédemment pour le procédé de traitement et le serveur selon l'invention. Dans un mode particulier de réalisation, le système de communication comprend en outre : 5 - lorsque l'identité publique est partagée par une pluralité de deuxièmes dispositifs dans le premier coeur de réseau IP multimédia, au moins un serveur du premier coeur de réseau IP multimédia gérant la pluralité de deuxièmes dispositifs et configuré pour répliquer la première requête et transmettre les répliques de la première requête à ladite pluralité de deuxièmes dispositifs ; et/ou 10 - lorsque l'identité publique est partagée par une pluralité de deuxièmes dispositifs dans un dit deuxième coeur de réseau, au moins un serveur dudit deuxième coeur de réseau gérant la pluralité de deuxièmes dispositifs et configuré pour répliquer une dite deuxième requête et transmettre les répliques de ladite deuxième requête à ladite pluralité de deuxièmes dispositifs. 15 Autrement dit, l'invention se combine aisément à une réplication de la requête dans le coeur de réseau « appelé », dans le cas où une pluralité de dispositifs dans ce coeur de réseau « appelé » partagent l'identité publique à laquelle la requête est destinée. De cette sorte, la requête émise par le premier dispositif est transmise à l'ensemble des deuxièmes dispositifs partageant l'identité publique, quel que soit le coeur de réseau auprès duquel ils sont enregistrés. 20 On exploite de la sorte pleinement les possibilités multi-coeurs et multi-terminaux offertes par les coeurs de réseau IP multimédia. On peut également envisager, dans d'autres modes de réalisation, que le procédé de traitement, le serveur et le système de communication selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. 25 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : 30 - la figure 1 représente, dans son environnement, un système de communication conforme à l'invention dans un premier mode de réalisation ; la figure 2 représente l'architecture matérielle d'un serveur du système de communication de la figure 1, conforme à l'invention ; - la figure 3 illustre sous forme d'ordinogramme les principales étapes d'un procédé de 35 traitement selon l'invention tel qu'il est mis en oeuvre par le serveur de la figure 2 dans le premier mode de réalisation ; la figure 4 représente, dans son environnement, un système de communication conforme à l'invention dans un deuxième mode de réalisation ; et 13 - la figure 5 illustre sous forme de diagramme de flux les principales étapes d'un procédé de traitement selon l'invention tel qu'il est mis en oeuvre par un serveur du système de communication représenté à la figure 4, conforme à l'invention, dans le deuxième mode de réalisation. 5 Description détaillée de l'invention La figure 1 représente, dans son environnement, un système de communication 1 conforme à l'invention, dans un premier mode particulier de réalisation. A titre illustratif, on se place sur la figure 1 et dans ce premier mode de réalisation, 10 dans un contexte où un utilisateur U2 possède un ou plusieurs dispositifs de communication tels que des terminaux (ex. smartphones, tablettes numériques, ordinateurs, application logicielle, etc.), référencés de manière générale par T2. Au moins l'un des dispositifs T2 est équipé de deux piles de protocoles IMS distinctes lui permettant de s'enregistrer auprès de et de communiquer sur deux coeurs de réseau IMS distincts CN1 et CN2 (i.e. correspondant à des noms de domaines 15 différenciés), et ce, en utilisant une même identité publique IMPU2 allouée à l'utilisateur U2. Le cas échéant, les autres dispositifs 12 de l'utilisateur U2 disposent ici d'une unique pile de protocole IMS leur permettant de s'enregistrer et de communiquer soit sur le coeur de réseau IMS CN1 soit sur le coeur de réseau CN2. A titre illustratif sur la figure 1, on suppose que l'utilisateur U2 possède un dispositif 12-1 comprenant deux piles de protocoles IMS P-CN1 et P-CN2 lui permettant de 20 s'enregistrer sur les coeurs de réseau CN1 et CN2, un dispositif 12-2 comprenant une unique pile de protocole IMS P-CN1 lui permettant de s'enregistrer sur le coeur de réseau IMS CN1 uniquement et un dispositif T2-3 comprenant une unique pile de protocole IMS P-CN2 lui permettant de s'enregistrer sur le coeur de réseau IMS CN2 uniquement. Les trois dispositifs T2-1, T2-2 et 12-3 partagent la même identité publique IMPU2. Cet exemple n'est bien entendu donné qu'à titre 25 illustratif. Ces hypothèses ne sont toutefois pas limitatives en soi. Ainsi notamment, les dispositifs de l'utilisateur U2 peuvent être tout type de dispositif apte à communiquer sur un réseau (terminal, serveur, etc.), chaque dispositif pouvant être équipé d'une, deux ou de plus de deux piles de protocoles distinctes lui permettant de s'enregistrer et de communiquer sur autant de 30 coeurs de réseau différents ; en outre, les coeurs de réseau en question peuvent s'appuyer sur une autre architecture de coeur de réseau IP multimédia qu'une architecture IMS telle qu'une architecture WebRTC, une architecture propriétaire, etc. Il est également possible d'envisager un nombre de coeurs de réseau supérieur à 2, l'un de ces coeurs de réseau pouvant s'appuyer sur une autre technologie que la technologie IP comme par exemple sur une technologie circuit, ce coeur 35 de réseau pouvant être par exemple un coeur de réseau de transit situé entre deux coeurs de réseau multimédia. L'identité publique IMPU2 de l'utilisateur U2 est par exemple un numéro de téléphone fixe ou mobile (ex. IMPU2-0123456789) allouée à l'utilisateur U2 lors de sa souscription à l'un des 14 coeurs de réseau. On note que de façon connue, l'architecture IMS permet à un utilisateur d'avoir plusieurs dispositifs distincts enregistrés, via chacun une identité privée ou IMPI (pour IP Multimedia Private identity) distincte (correspondant à une adresse de contact distincte), auprès d'un coeur de réseau basé sur cette architecture, en association avec une même identité publique 5 d'usager ou IMPU (IP Multimedia Public User identity) connue du coeur de réseau, c'est-à-dire provisionnée ou encore identifiée dans une base de données maintenue par celui-ci comme par exemple dans un serveur d'abonnés. Dans le contexte envisagé à la figure 1, l'utilisateur U2 est donc connu via son identité publique IMPU2 des deux coeurs de réseau CN1 et CN2, et peut avoir simultanément un ou plusieurs dispositifs 12 enregistrés auprès du coeur de réseau CN1 (dans 10 l'exemple, les dispositifs T2-1 et 12-2) et/ou un ou plusieurs dispositifs T2 enregistrés auprès du coeur de réseau CN2 (dans l'exemple les dispositifs T2-1 et T2-3) en association avec son identité publique IMPU2. Lors de la souscription de l'utilisateur U2 auprès de chacun des coeurs de réseau CN1 et CN2, un identifiant SIP ou URI (pour Uniform Ressource Identifier) lui a été attribué 15 respectivement sur chacun de ces coeurs de réseau. Cette URI SIP est dérivée de l'identité publique IMPU2 de l'utilisateur U2 et du nom de domaine IMS du coeur de réseau considéré (identique pour tous les utilisateurs d'un même coeur de réseau). Ainsi par exemple, pour un coeur de réseau IP multimédia fixe, l'URI SIP allouée à un utilisateur est constituée d'une partie utilisateur (« user part ») correspondant à son identité 20 publique (traduite dans le format international normalisé E164, c'est-à-dire pour un numéro français, sans le 0 au début et avec l'indicatif +33) et du nom de domaine IMS du coeur de réseau. Par exemple, une telle URI est +33123456789(aorange-multimedia.fr où « +33123456789 » correspond à la partie utilisateur et « orange-multimedia.fr » correspond au nom de domaine IMS. Pour un coeur de réseau IP multimédia mobile, l'URI SIP est normalisée : la partie 25 utilisateur correspond au numéro de téléphone mobile de l'utilisateur (dans le format international normalisé E164), et le nom de domaine est dérivé des codes réseau MNC (pour Mobile Network Code) et pays MCC (pour Mobile Country Code) présents dans la carte SIM (Subscriber Identity Module) de l'utilisateur. Par exemple, pour la France (MCC=208) et l'opérateur Orange (MNC=001), une telle URI SIP est +33123456789@ims.mnc001.mcc208.3gppnetwork.org. 30 Dans la suite de la description, on note : URI2-CN1, l'URI allouée à l'utilisateur U2 par le coeur de réseau CN1. Par exemple : URI2-CN1= +33123456789@nomdomCN1, où « 33123456789 » désigne l'identité publique IMPU2 au format E164 et « nomdomCN1 » le nom de domaine associé au coeur de réseau CN1 ; et 35 - URI2-CN2, l'URI allouée à l'utilisateur U2 par le coeur de réseau CN2. Par exemple : URI2-CN2=+33123456789@nomdomCN2, où « 33123456789 » désigne l'identité publique IMPU2 au format E164 et « nomdonnCN2 » le nom de domaine associé au coeur de réseau CN2. 15 Il convient de noter que, dans le contexte de l'invention, il existe une différence entre un dispositif associé à une identité publique qui se trouve dans un état « enregistré » auprès du coeur de réseau et un dispositif associé à une identité publique qui se trouve simplement dans un état « connu » du coeur de réseau. 5 En effet, un dispositif ou une identité publique utilisée par ce dispositif est dit(e) enregistré(e) auprès du coeur de réseau si le dispositif a réalisé une action positive d'enregistrement auprès du coeur de réseau, typiquement dans le cadre du protocole SIP, s'il a envoyé un message d'enregistrement dédié SIP REGISTER pour s'enregistrer auprès du coeur de réseau et que ce message a été acquitté par le coeur de réseau par un message 200 OK. Cet état 10 enregistré est requis pour que le dispositif puisse communiquer via le coeur de réseau. Au contraire, un dispositif ou une identité publique utilisée par ce dispositif est dit(e) simplement « connu(e) » du coeur de réseau, si l'identité publique en question est uniquement provisionnée dans une base de données du coeur de réseau (par exemple dans un serveur d'abonnés), suite notamment à la souscription de l'utilisateur du dispositif aux services offerts par 15 le coeur de réseau. Cet état ne présuppose pas qu'un dispositif utilisant l'identité publique ait fait une démarche explicite d'enregistrement auprès du coeur de réseau via l'envoi d'un message d'enregistrement dédié de type SIP REGISTER. On note qu'il suffit qu'une identité publique allouée à un utilisateur soit connue du coeur de réseau pour qu'il lui soit attribué une URI SIP. Ainsi, au vu de cette distinction, l'utilisateur U2 peut donc disposer de plusieurs 20 dispositifs de communication T2 aptes à utiliser (i.e. à partager) son identité publique IMPU2 connue des coeurs de réseau CN1 et CN2, et avoir à un instant donné seulement une partie voire aucun de ses dispositifs T2 enregistrés auprès des coeurs de réseau CN1 et/ou CN2. Si aucun dispositif T2 n'est enregistré auprès de l'un ou l'autre des coeurs de réseau CN1 et CN2, l'identité publique IMPU2 est considérée ici comme simplement connue de ces coeurs de réseau. Dans la 25 suite de la description, on qualifie indifféremment conformément à cette interprétation de « connu(e)s » ou d'« enregistré(e)s » les utilisateurs des coeurs de réseau, les identités publiques allouées à ces utilisateurs (et en corollaire, à leurs dispositifs) ou aux dispositifs des utilisateurs utilisant ces identités publiques. Conformément à l'invention, le système de communication 1 comprend un dispositif de 30 communication Ti d'un utilisateur U1 comprenant une pile de protocole IMS lui permettant de s'enregistrer et de communiquer sur le coeur de réseau IMS CN1. Dans l'exemple envisagé ici, le dispositif Ti est connu et enregistré auprès du coeur de réseau IMS CN1 en association avec une identité publique IMPU1 allouée à l'utilisateur U1 (ex. numéro de téléphone ou MSISDN). Aucune limitation n'est attachée à la nature du dispositif de communication Ti qui peut être aussi bien un 35 terminal, un serveur, qu'une application logicielle, etc. L'utilisateur U1 est identifié sur le coeur de réseau CN1 par son URI SIP, notée URI1, dérivée de son identité publique IMPU1 et du nom de domaine IMS « nomdomCN1 » du coeur de réseau CN1, comme décrit précédemment pour les URI SIP attribuées à l'utilisateur U2. 16 Le système de communication 1 comprend également un serveur 2 conforme à l'invention. Dans le premier mode de réalisation décrit ici, le serveur 2 est un serveur S-CSCF du coeur de réseau IMS CN1, gérant le dispositif Ti de l'utilisateur Ul, autrement dit gérant les communications émises et/ou reçues par le dispositif Ti sur le coeur de réseau CN1. 5 Comme mentionné précédemment, le coeur de réseau CN1 comme le coeur de réseau CN2 s'appuient ici sur une architecture IMS. De façon connue, une telle architecture IMS se base sur une pluralité d'entités pouvant être hébergées par des équipements distincts et comprenant notamment : un semeur d'abonnés HSS (référencé par 3 pour le coeur de réseau CN1 et par 4 pour le coeur 10 de réseau CN2) contenant la liste des utilisateurs du coeur de réseau, les droits et les autorisations dont ceux-ci bénéficient, ainsi que l'état d'enregistrement du/des dispositifs. Dans le premier mode de réalisation, on suppose par exemple que le serveur d'abonnés HSS 3 contient les utilisateurs Ul et U2 en association avec leurs identités publiques respectives IMPU1 et IMPU2, et que le serveur d'abonnés HSS 4 contient l'utilisateur U2 en association 15 avec son identité publique IMPU2; un serveur DNS (référencé par 5 pour le coeur de réseau CN1 et par 6 pour le coeur de réseau CN2), capable de résoudre (i.e. traduire) des noms de domaine en différentes informations, et notamment en URI SIP. Ce serveur met en oeuvre ici le mécanisme ENUM et contient l'ensemble des URI SIP des utilisateurs connus du coeur de réseau considéré ; 20 plusieurs serveurs regroupés sous l'appellation CSCF (pour Call Session Control Function), implémentant le protocole SIP et utilisés pour traiter la signalisation SIP dans le coeur de réseau IMS. Ces serveurs incluent en particulier : o un ou plusieurs serveurs P-CSCF, points d'entrée des terminaux (dispositifs au sens de l'invention) sur le coeur de réseau IMS ; 25 o un ou plusieurs serveurs I-CSCF, jouant le rôle de proxy(s) SIP; o un ou plusieurs serveurs S-CSCF (incluant pour le coeur de réseau CN1, le serveur SCSCF 2 gérant l'identité publique IMPU1 et donc le dispositif Ti et un serveur S-CSCF 7 gérant l'identité publique IMPU2 et donc les dispositifs T2-1 et T2-2 de l'utilisateur U2, et pour le coeur de réseau CN2, un serveur S-CSCF 8 gérant l'identité publique IMPU2 30 et donc les dispositifs T2-1 et T2-3), en charge de l'enregistrement des terminaux et du routage des messages SIP émis ou destinés à ces terminaux ; - un ou plusieurs serveurs d'application AS (Application Server) en charge du traitement des différents services proposés par le coeur de réseau, et qui peuvent être déclenchés (ou instanciés) par les serveurs S-CSCF ; et 35 divers équipements d'interconnexion avec d'autres coeurs de réseaux ou réseaux. Ces équipements d'interconnexion (référencés par 9 pour l'interconnexion entre le coeur de réseau CN1 et le coeur de réseau CN2) incluent en particulier : 17 o pour l'interconnexion avec un réseau circuit fixe ou mobile, des équipements de type MGCF (pour la signalisation) et MGW (pour les flux média) qui permettent d'assurer l'interfonctionnement protocolaire SIP/RTP (Real -rime Protocol) (qui sont les protocoles mis en oeuvre côté coeur de réseau IP multimédia pour la signalisation et 5 les flux média) et ISUP/circuit (qui correspondent aux protocoles mis en oeuvre côté réseau circuit fixe ou mobile), et o pour l'interconnexion avec d'autres réseaux IP multimédia, des équipements de type IBCF et IBGF. Ces différentes entités sont définies par la norme 3GPP et ne sont pas décrites en 10 détail ici. En outre, par souci de simplification, seuls les serveurs HSS 3 et 4, les serveurs DNS 5 et 6, les serveurs S-CSCF 2, 7 et 8 et les équipements d'interconnexion 9 des coeurs de réseau IP multimédia CN1 et CN2 sont représentés sur la figure 1. Le serveur S-CSCF 2 selon l'invention se distingue des serveurs S-CSCF connus de la norme 3GPP en ce qu'il est configuré pour mettre en oeuvre les différentes étapes d'un procédé de 15 traitement selon l'invention. Il dispose ici à cet effet de l'architecture matérielle d'un ordinateur, telle que représentée schématiquement à la figure 2. Plus particulièrement, le serveur S-CSCF 2 comprend un processeur 10, une mémoire morte 11, une mémoire vive 12, une mémoire non volatile 13 et des moyens de communication 14 lui permettant de communiquer notamment avec les autres entités du coeur de réseau CN1 et 20 intégrant une pile de protocole SIP. La mémoire morte 11 du serveur S-CSCF 2 constitue un support d'enregistrement ou d'informations conforme à l'invention, lisible par le processeur 10 et sur lequel est enregistré un programme d'ordinateur PROG conforme à l'invention. Le programme d'ordinateur PROG comporte des instructions pour l'exécution d'un 25 procédé de traitement selon l'invention, appliqué par le serveur S-CSCF 2 notamment à des requêtes émises par le dispositif Ti et plus particulièrement, dans l'exemple envisagé ici, à une requête émise par le dispositif T1 à destination de l'identité publique IMPU2 allouée à l'utilisateur U2 et utilisée par son ou ses dispositifs T2. Ce programme PROG définit, par le biais de ses instructions, des modules fonctionnels du serveur S-CSCF 2 qui s'appuient sur et/ou commandent 30 les éléments matériels 10-14 décrits précédemment. Ces modules comprennent notamment ici, comme illustré à la figure 1 : un module de vérification 2A, configuré (i.e. programmé) pour vérifier si l'identité publique à laquelle est destinée la requête considérée (dans l'exemple envisagé ci-dessus, l'identité publique IMPU2), est connue du premier coeur de réseau IP multimédia CN1; 35 des modules, activés le cas échéant, et comprenant : 0 un module de réplication 2B, configuré pour répliquer la requête en une première requête et une seconde requête ; 18 o un premier module de routage 2C, configuré pour déclencher un routage de la première requête au sein du premier coeur de réseau CN1, typiquement à destination d'un serveur du premier coeur de réseau IP multimédia gérant l'identité publique. On note que ce serveur peut être le même que le serveur S-CSCF 2; et 5 o un second module de routage 2D, configuré pour déclencher un routage de la seconde requête selon une route prédéterminée à destination d'une entité d'interconnexion du premier coeur de réseau CN1 avec un second coeur de réseau IP multimédia distinct du premier coeur de réseau IP multimédia, ce second coeur de réseau étant en l'occurrence ici le coeur de réseau CN2. 10 Dans le premier mode de réalisation décrit ici, le programme PROG définit également un module d'élaboration 2E d'une réponse à la requête à partir de la ou ou des réponses reçues aux répliques de cette requête (première et deuxième requêtes au sens de l'invention). Les fonctions de ces différents modules sont expliquées plus en détail maintenant en référence aux étapes du procédé de traitement selon l'invention. 15 La figure 3 représente les principales étapes du procédé de traitement selon l'invention telles qu'elles sont mises en oeuvre dans le premier mode de réalisation par le serveur S-CSCF 2. On suppose ici que par défaut, ce traitement est appliqué de manière inconditionnelle à toutes les requêtes traitées par le serveur S-CSCF 2 émanant de dispositifs enregistrés auprès du coeur de réseau CN1 et gérés par le serveur S-CSCF 2. 20 En variante, le traitement peut être activé seulement pour certains dispositifs prédéterminés, ou plus particulièrement pour certaines identités publiques, à l'origine des requêtes ou auxquelles les requêtes sont destinées. Pour permettre ce traitement différencié, on peut envisager d'associer, dans le serveur HSS 3 du coeur de réseau CN1, aux identités publiques provisionnées, une information d'autorisation (et d'activation) ou non du traitement. 25 Pour illustrer les étapes du procédé de traitement selon l'invention, on s'intéresse ici à une requête SIP R, par exemple une requête SIP INVITE, émise par le dispositif T1 de l'utilisateur Ul à destination de l'identité publique IMPU2 de l'utilisateur U2. On suppose que pour pouvoir envoyer cette requête et communiquer sur le coeur de réseau CN1, le dispositif Ti s'est préalablement enregistré auprès du coeur de réseau CN1, en lui envoyant une requête SIP 30 REGISTER pour laquelle il a reçu un acquittement 200 OK. L'identité publique IMPU1 utilisée par le dispositif Ti est donc non seulement connue du coeur de réseau CN1 mais également enregistrée auprès de celui-ci, notamment auprès du serveur S-CSCF 2 qui gère cette identité publique et les dispositifs de l'utilisateur Ul utilisant cette identité publique pour communiquer. La requête SIP R émise par le dispositif Ti transite par le serveur P-CSCF du coeur de 35 réseau CN1 et est reçue par le serveur S-CSCF 2, via ses moyens de communications 14 (étape E10). Elle comprend dans son entête Request URI l'identité publique IMPU2. Conformément à l'invention, le serveur S-CSCF 2, via son module de vérification 2A, vérifie si l'identité publique IMPU2 est connue du coeur de réseau CN1 (étape E20). 19 A cet effet, dans le premier mode de réalisation décrit ici, le module de vérification 2A interroge le serveur DNS ENUM 5 du coeur de réseau CN1. Plus précisément, il extrait l'identité publique IMPU2 de l'entête Request URI de la requête R et la transforme dans le format international normalisé E164. Cette transformation, pour 5 une identité publique IMPU2 de type numéro de téléphone à 10 chiffres commençant par 0, consiste à supprimer le 0 et à lui adjoindre le préfixe +33 pour la France : ainsi, si l'IMPU2 est, comme dans l'exemple illustratif fourni précédemment, 0123456789, le module de vérification 2A obtient +33123456789. Puis le module de vérification 2A transforme le numéro dans le format E164 en un 10 nom de domaine : à cette fin, il inverse le numéro E164 et lui adjoint le suffixe arpa.net. On obtient dans l'exemple envisagé ci-dessus 9.8.7.6.5.4.3.2.1.3.3.arpa.net. Le module de vérification 2A interroge ensuite le serveur DNS ENUM 5 en utilisant le nom de domaine ainsi obtenu. Si le serveur DNS ENUM 5 contient une URI SIP en association avec ce nom de domaine, cela signifie que l'identité publique IMPU2 est connue du coeur de réseau CN1 (réponse 15 oui à l'étape test E20), et le serveur DNS ENUM 5 retourne au serveur S-CSCF 2 l'URI correspondante (à savoir ici l'URI URI2-CN1) (étape E40). Sinon, l'identité publique IMPU2 n'est pas connue du réseau CN1 (réponse non à l'étape test E20), et le procédé de traitement selon l'invention s'arrête (étape E30). La requête R est traitée conformément au mécanisme de routage connu de l'état de la technique, autrement dit, 20 elle est routée vers une route préconfigurée, déterminée en fonction d'un ou de plusieurs paramètres, comme par exemple du préfixe de l'identité publique IMPU2 (ex. « +33 ») et/ou d'un préfixe de portabilité de numéro retourné par un serveur de portabilité interrogé à partir de l'identité publique IMPU2 (ce serveur pouvant être le serveur DNS ENUM 5 ou un serveur interconnecté au serveur DNS ENUM 5) et que le serveur S-CSCF rapproche d'une table de routage 25 contenant des routes préconfigurées et/ou d'un préfixe de routage technique (RN). La réception de l'URI URI2-CN1 par le module de vérification 2A du serveur S-CSCF 2 déclenche la réplication de la requête R (i.e. duplication ici, deux coeurs de réseau CN1 et CN2 distincts étant considérés), par le module de réplication 2B, en une première requête R1 et en une deuxième requête R2 (étape E50). Cette réplication (ou « forking » en anglais) peut être réalisée 30 de façon similaire ou identique à ce qui est mis en oeuvre aujourd'hui dans les architectures IMS côté appelé pour tenir compte du partage d'une même IMPU par plusieurs dispositifs d'un utilisateur (et décrit dans le document IETF RFC3261). Puis, le premier module de routage 2C du serveur S-CSCF 2 déclenche le routage de la première requête R1 en « local », c'est-à-dire au sein du domaine IMS correspondant au coeur de 35 réseau CN1 (étape E60). Il procède à cet effet comme défini dans la norme 3GPP 24.229 et rappelé précédemment en routant la première requête R1 vers un serveur I-CSCF du coeur de réseau CN1 (qui peut être colocalisé avec le serveur S-CSCF 2). 20 Le serveur I-CSCF interroge le serveur HSS 3 du coeur de réseau CN1 via le protocole Diameter, en lui fournissant l'URI URI2-CN1 reçue à l'étape E40 et contenue dans la réplique R1. Le serveur HSS 3 retourne au serveur I-CSCF l'adresse de joignabilité du serveur S-CSCF du coeur de réseau CN1 en charge de l'utilisateur U2. Il s'agit, dans l'exemple illustré à la figure 1 du 5 serveur S-CSCF 7. Le serveur I-CSCF route la requête R1 vers le serveur S-CSCF 7. On note que dans l'exemple envisagé, le serveur S-CSCF 7 est différent du serveur SCSCF 2. Toutefois, ceci n'est pas une obligation et l'invention s'applique également dans le cas où un même serveur S-CSCF est en charge de l'utilisateur U1 (et de ses dispositifs) et de l'utilisateur U2 (et de ses dispositifs). Auquel cas l'étape de déclenchement du routage consiste à router par le 10 serveur S-CSCF 2 la requête R1 vers les dispositifs T2 enregistrés auprès de lui. Le serveur S-CSCF 7 route ensuite à son tour la requête R1 vers le ou les dispositifs T2 de l'utilisateur U2 enregistrés le cas échéant auprès du coeur de réseau CN1. Comme mentionné précédemment, plusieurs cas de figure peuvent se présenter lorsque le serveur S-CSCF 7 reçoit la requête Ri: 15 - aucun dispositif de l'utilisateur U2 n'est enregistré auprès du coeur de réseau CN1 en association avec l'identité publique IMPU2 : dans ce cas, le serveur S-CSCF 7 envoie un message de réponse REP1 à la requête Ri à destination du dispositif Ti pour signaler l'absence de dispositif enregistré pour l'identité publique IMPU2. Il s'agit par exemple d'un message de réponse SIP 480 Temporarily Unavailable ; 20 - un seul dispositif T2 de l'utilisateur U2 est enregistré auprès du coeur de réseau CN1 en association avec l'identité publique IMPU2 (par exemple 12-1 ou 12-2) : la requête R1 est routée par le serveur S-CSCF 7 vers cet unique dispositif T2 qui y répond en fonction de son état et des circonstances par un message de réponse REP1 tel que prévu par la norme RFC 3261. Le message de réponse REP1 est un message SIP ayant un code de statut 1>c x, 3xx, 25 4)(x, Sxx, 6xx comme indiqué à la section 7.2 du document RFC 3261. Pour rappel : o un message SIP 1xx indique une réponse provisoire (requête toujours en cours de traitement) ; o un message SIP 2)oc indique un succès de la requête ; o un message SIP 3)o( indique une redirection de la requête ; 30 o un message SIP 4>o( traduit une erreur liée au client (mauvaise syntaxe de la requête ou incapacité à traiter la requête) ; o un message SIP 5xx traduit une erreur liée au serveur (incapacité à traiter une requête apparemment valide) ; et o un message 6xx traduit un échec global à traiter la requête au sein du coeur de 35 réseau. Il convient de noter que le dispositif 12 peut être encore enregistré auprès du coeur de réseau CN1 mais n'être plus joignable, par exemple du fait d'une perte de connectivité ou autre, auquel cas il n'est pas en mesure de répondre. En l'absence de réponse reçue par le serveur S- 21 CSCF 7 à l'issue d'une période de temps prédéterminé, le serveur S-CSCF 7 répond comme indiqué précédemment dans le premier cas de figure où aucun terminal n'est enregistré ; plusieurs (N, N désignant un entier supérieur à 1) dispositifs T2 de l'utilisateur U2 sont enregistrés simultanément avec plusieurs identités privées et adresses de contact auprès du 5 coeur de réseau CN1 et du serveur S-CSCF 7 (dans l'exemple de la figure 1, les terminaux T2-1. et T2-2) : dans ce cas, le serveur S-CSCF 7, ou un serveur d'application du coeur de réseau CN1 instancié par le serveur S-CSCF 7 ou en standalone, réplique la requête Ri en autant de répliques R1-1, R1-2,..., R1-N que de dispositifs T2 enregistrés. Les répliques R1-1,...,R1-N sont ensuite transmises par le serveur S-CSCF 7 ou par le serveur d'application aux dispositifs 10 12 enregistrés. Le serveur S-CSCF 7 ou le serveur d'application traite la ou les réponses REP1- 1,...,REP1-N reçues des N dispositifs T2 enregistrés comme décrit dans le document RFC 3261, et renvoie la ou les réponses obtenues à destination du dispositif Ti. On note que dans le cas où les répliques sont des répliques d'un message SIP OPTIONS, et que les réponses REP1- 1,...REP1-N reçues contiennent les capacités (i.e. services supportés) et/ou état des N 15 dispositifs 12 enregistrés auprès du serveur S-CSCF 7, le serveur S-CSCF 7 ou le serveur d'application peut élaborer une réponse REP1 à la requête R1 et destinée au terminal Ti comprenant l'agrégation des capacités et/ou état contenus dans les réponses REP1-1,...,REP1- N. Quel que soit le cas de figure envisagé, la ou les réponses renvoyées par le serveur S- 20 CSCF 7 emprunte(nt) le chemin inverse à la requête R1, et est ou sont reçues par le serveur S- CSCF 2 (étape E70). Dans la suite de la description, par souci de simplification, on désigne de façon générale par réponse REP1 la réponse simple ou les réponses multiples renvoyée par le serveur S-CSCF 7 via le coeur de réseau CN1. Dans le premier mode de réalisation décrit ici, simultanément au déclenchement par le 25 premier module de routage 2C du serveur S-CSCF 2 du routage de la première requête R1 au sein du domaine IMS « local » correspondant au coeur de réseau CN1, le deuxième module de routage 2D du serveur S-CSCF 2 déclenche le routage de la deuxième requête R2 en dehors du domaine IMS correspondant au coeur de réseau CN1 (étape E80). Il procède à cet effet comme défini dans la norme et rappelé précédemment, en 30 routant la deuxième requête R2 vers la fonction interne BGCF du serveur S-CSCF 2. Cette fonction BGCF applique à la requête R2 un routage défini par défaut et choisi parmi un ensemble de routes préconfigurées (i.e. prédéterminées) au niveau du serveur S-CSCF 2, en fonction de divers paramètres comme par exemple du préfixe de l'identité publique IMPU2 et/ou d'un préfixe de portabilité retourné par un serveur de portabilité interrogé à partir de l'identité publique IMPU2 (ce 35 serveur pouvant être le serveur DNS ENUM 5 ou un serveur interconnecté au serveur DNS ENUM 5) et que le serveur S-CSCF rapproche d'une table de routage contenant des routes préconfigurées permettant de s'interconnecter avec d'autres coeurs de réseaux (i.e. d'autres domaines) et/ou d'un préfixe de routage technique. 22 Le serveur S-CSCF 2 peut être configure préalablement avec diverses routes prédéterminées en fonction des accords d'interconnexion existants entre l'opérateur du coeur de réseau CN1 et les opérateurs d'autres coeurs de réseau. En particulier, si l'opérateur du coeur de réseau CN1 sait à l'avance que son utilisateur U2 est susceptible d'utiliser également le coeur de 5 réseau CN2 pour communiquer via ses dispositifs T2 en utilisant l'identité publique IMPU2, il peut configurer à l'avance le serveur S-CSCF 2 en charge de cet utilisateur avec une route conduisant au coeur de réseau CN2. L'information de rattachement de l'utilisateur U2 à plusieurs coeurs de réseau IMS peut être stockée dans le serveur HSS 3 du coeur de réseau CN1. En outre, les routes prédéterminées par défaut avec lesquelles le serveur S-CSCF 2 est 10 configuré dépendent de la nature des interconnexions réalisées entre le coeur de réseau CN1 et les autres coeurs de réseau considérés. Par exemple, si comme supposé ici, des accords d'interconnexion existent avec l'opérateur en charge du coeur de réseau CN2 en mode SIP ou si un routage par défaut vers un hub SIP est préconfiguré au niveau du serveur S-CSCF 2, la fonction BGCF du serveur S-CSCF 2 15 route la requête R2 vers un serveur d'interconnexion 9 du coeur de réseau CN1 assurant l'interconnexion avec le coeur de réseau CN2 en mode SIP. Ce serveur d'interconnexion 9 comprend une fonction IBCF pour assurer l'interconnexion au niveau de la signalisation SIP et une fonction IBGF pour assurer l'interconnexion au niveau du flux média. Ces fonctions sont connues en soi pour une architecture IMS et non décrites ici. 20 On note qu'une fonction de réplication peut être appliquée le cas échéant au sein du coeur de réseau CN2 si plusieurs dispositifs 12 sont enregistrés pour l'utilisateur U2, par le serveur S-CSCF 8 gérant ces dispositifs T2 ou par un serveur d'application instancié par celui-ci ou non. La fonction de réplication renvoie à destination du dispositif Ti une ou plusieurs réponses à la requête R2, désignée(s) de façon générale par réponse REP2 par souci de simplification (REP2 pouvant 25 être simple ou multiple), et élaborée(s) comme décrit dans le document RFC 3261. Cette réponse REP2 emprunte le chemin inverse à la requête R2, et est reçue par le serveur S-CSCF 2 (étape E90). Selon un autre exemple, si des accords d'interconnexion existent avec l'opérateur en charge du coeur de réseau CN2 selon un mode circuit (ex. le coeur de réseau CN2 est un coeur de 30 réseau utilisant une technologie circuit ou est accessible via un coeur de réseau de transit utilisant la technologie circuit) ou si un routage par défaut vers un hub circuit ISUP est préconfiguré au niveau du serveur S-CSCF 2, la fonction BGCF du serveur S-CSCF 2 route la requête R2 vers un serveur d'interconnexion 9 du coeur de réseau CN1 assurant l'interconnexion avec le coeur de réseau CN2 en mode circuit. Ce serveur d'interconnexion 9 comprend une fonction MGCF de 35 passerelle protocolaire SIP-ISUP/BICC pour assurer l'interconnexion au niveau de la signalisation, et une fonction MGW de passerelle protocolaire RTP - circuit pour assurer l'interconnexion au niveau du flux média. Ces fonctions sont connues en soi pour une architecture IMS et non décrites ici. En outre, dans ce cas, soit aucune réponse n'est renvoyée, soit une unique réponse REP2 à la 23 requête R2 est renvoyée par un dispositif T2 de l'utilisateur U2 (la technologie circuit n'offrant pas la possibilité de gérer plusieurs dispositifs partageant la même identique publique contrairement aux architectures IP multimédia IMS, il n'y a pas de réplication côté appelé). La réponse REP2 emprunte le cas échéant le chemin inverse à la requête R2, et est reçue par le serveur S-CSCF 2 5 (étape E90). Dans une variante de réalisation, on peut envisager que le serveur S-CSCF 2 ne déclenche le routage de la requête R2 vers le serveur d'interconnexion 9 que si l'interconnexion assurée avec le coeur de réseau CN2 est assurée en utilisant le protocole SIP (autrement dit, que si le coeur de réseau CN2 est un coeur de réseau IP multimédia et qu'aucune passerelle protocolaire 10 n'est requise pour la signalisation). Ainsi, grâce à l'invention, les piles IMS de tous les dispositifs T2 de l'utilisateur U2 enregistrés auprès d'un coeur de réseau sont contactées lorsque le dispositif Ti émet une requête à destination de l'IMPU de l'utilisateur U2, que les dispositifs soient enregistrés sur le coeur de réseau CN1 et/ou sur le coeur de réseau CN2. 15 A titre illustratif, dans l'exemple envisagé ici d'une requête R SIP INVITE, les dispositifs T2-1, T2-2, et T2-3, s'ils sont enregistrés sur leurs coeurs de réseaux respectifs, sonnent et alertent l'utilisateur U2 sur réception des répliques de la requête R qui leur sont adressées. Ils envoient chacun, durant cette phase de sonnerie, une réponse SIP provisoire à destination du dispositif Ti de type 180 Ringing, qui emprunte le chemin inverse de la réplique de la requête R à laquelle elle 20 répond. L'utilisateur U2 peut alors prendre la communication sur n'importe lequel de ses dispositifs 12 indifféremment. On suppose ici qu'il prend la communication sur le dispositif T2-3. Celui-ci émet alors via le coeur de réseau CN2 un message de réponse SIP 200 OK en réponse à la réplique R2, qui emprunte le chemin inverse de la réplique R2 jusqu'au serveur S-CSCF 2. On note 25 que cette réponse transite par le serveur S-CSCF 8 qui, ayant détecté qu'un dispositif a accepté la communication, envoie alors un message SIP CANCEL d'annulation de la requête R2 au dispositif 12-1 auquel le dispositif 12-1 répond par un message 200(0K) après avoir arrêté de sonner. Puis le dispositif 12-1 envoie un message SIP 487 Request Ternninated vers le serveur S-CSCF 8 qui acquitte cette réponse SIP finale via un acquittement SIP ACK. 30 De manière similaire, sur réception de la réponse 200 OK du dispositif 12-3, le serveur S-CSCF 2 envoie un message SIP CANCEL d'annulation de la requête R1 aux dispositifs 12-1 et 122 enregistrés le cas échéant sur le coeur de réseau CN1. Les dispositifs T2-1 et T2-2 arrêtent de sonner, répondent à ce message SIP CANCEL par un message 200(0K), puis envoient un message SIP 487 Request Terminated vers le serveur S-CSCF 2 qui acquitte cette réponse SIP finale via un 35 message SIP ACK d'acquittement. De manière générale, suite aux routages des répliques R1 et R2 de la requête R, le serveur S-CSCF 2 a donc reçu au moins une réponse REP1 simple ou multiple via le coeur de réseau CN1 (i.e. en provenance du coeur de réseau CN1, étape E70), que l'utilisateur U2 ait ou non 24 des dispositifs enregistrés auprès du coeur de réseau CN1, et aucune réponse ou une réponse simple ou multiple REP2 reçue via le coeur de réseau CN2 (i.e. en provenance du coeur de réseau CN2, étape E90). Le module d'élaboration 2E du serveur S-CSCF 2 élabore ensuite une ou plusieurs 5 réponses à la requête R, désignée(s) dans la suite de la description de façon générale par « réponse REP » que celle-ci soit simple ou multiple, à partir des réponses REP1 et REP2 qu'il a reçues le cas échéant aux répliques R1 et R2 (étape E100). Dans le premier mode de réalisation décrit ici, le module d'élaboration 2E procède, pour élaborer sa réponse REP de façon similaire à ce qui a été appliqué par le serveur S-CSCF 7 10 lorsque plusieurs dispositifs T2 sont enregistrés auprès du coeur de réseau CN1 pour la même identité publique IMPU2. Plus précisément, la réponse REP peut être élaborée par le module d'élaboration 2E selon l'une ou l'autre des stratégies suivantes : première stratégie : la réponse REP comprend toutes les réponses REP1 et REP2 reçues le cas échéant aux répliques R1 et R2 de la requête R lors des étapes de réception E70 et E90; ou 15 deuxième stratégie : la réponse REP comprend la réponse REP1 ou REP2 reçue en premier par le serveur S-CSCF 2 ou la réponse REP1 ou REP2 reçue en premier d'un type prédéterminé (ex. première réponse finale de type 2xx) ; ou troisième stratégie : la réponse REP comprend la meilleure réponse reçue parmi les réponses REP1 et REP2 reçues le cas échéant au cours d'une première période de temps Ti 20 prédéterminée. Par « meilleure », on entend ici la plus favorable du point de vue du traitement de la requête R, c'est-à-dire celle qui favorise son traitement ; ou quatrième stratégie : la réponse REP comprend une agrégation de contenus extraits de toutes les réponses REP1 et REP2 reçues le cas échéant au cours d'une deuxième période de temps prédéterminée 12 (ex. T2=2s) pouvant être différente de la période de temps Ti. 25 Ces stratégies d'élaboration de la réponse REP ne sont données qu'à titre illustratif, et d'autres stratégies encore peuvent être envisagées. Le choix de l'une et/ou l'autre de ces stratégies pour élaborer la réponse REP peut dépendre de différents paramètres. Il peut dépendre notamment du type de réponses reçues par le serveur S-CSCF 2 aux répliques R1 et R2 et contenues dans les réponses REP1 et REP2 (c'est-à- 30 dire ici des codes de statut sur lesquels se basent les contenus de ces réponses) et/ou du type de requête R émise par le terminal Ti. Ainsi, pour une requête R s'appuyant sur la méthode SIP INVITE comme dans le cas envisagé à titre illustratif ici, le module d'élaboration 2E peut appliquer : - la première stratégie lorsque les réponses REP1 et REP2 reçues comprennent des réponses 35 provisoires s'appuyant sur un code de statut ou d'état 1xx ; - la deuxième stratégie lorsque les réponses REP1 et REP2 reçues comprennent des réponses s'appuyant sur un code de statut ou d'état 2xx ou 3xx ; et 25 - la troisième stratégie lorsque les réponses REP1 et REP2 reçues comprennent des réponses s'appuyant sur un code de statut 4xx, 5xx ou 6xx. Dans l'exemple illustratif considéré précédemment où le dispositif T2-3 accepte la requête et établit une communication avec le dispositif Ti, le serveur S-CSCF 2 transmet toutes les 5 réponses provisoires 180 Ringing reçues via les coeurs de réseau CN1 et CN2, puis ne transmet que la réponse définitive 200 OK émise par le dispositif 12-3 lorsqu'il accepte la requête. Pour tout autre type de requêtes SIP à l'exception d'une requête s'appuyant sur la méthode SIP OPTIONS, le module d'élaboration 2E peut appliquer : - la deuxième stratégie en transmettant la première réponse finale reçue parmi les réponses 10 REP1 et REP2 s'appuyant sur un code de statut 2)oc ; et - la troisième stratégie lorsque les réponses reçues REP1 et REP2 comprennent des réponses s'appuyant sur un code de statut loc, 4>o 1 peut être envisagée, auquel cas conformément à l'invention N+1 répliques de la requête sont générées et routées au sein du coeur de réseau CN1 et vers les entités d'interconnexion avec les N coeurs de réseau) ; d'autre part, l'un au moins de ces coeurs de réseau peut implémenter une autre technologie qu'une REVENDICATIONS1. Procédé de traitement d'une requête (R,R100) émise par un premier dispositif (T1,T101) enregistré auprès d'un premier coeur de réseau IP multimédia (CN1,CN101) à destination d'une identité publique allouée à au moins un deuxième dispositif (T2-1,T2-2,T2- 3,T102-1,T102-2), ledit procédé étant destiné à être mis en oeuvre par un serveur (2,102) du premier coeur de réseau IP multimédia et comprenant : - une étape de vérification (E20, F90) si ladite identité publique est connue du premier coeur de réseau IP multimédia ; si ladite identité publique est connue du premier coeur de réseau IP multimédia : o une étape de réplication (E50, F110) de ladite requête en une première requête (R1,R101) et en au moins une deuxième requête (R2,R102) ; o une étape de déclenchement (E60,F120) d'un routage de la première requête au sein du premier coeur de réseau IP multimédia ; et o une étape de déclenchement (E80,F130) d'un routage de ladite au moins une deuxième requête selon au moins une route prédéterminée à destination d'au moins une entité d'interconnexion (9,109) du premier coeur de réseau IP multimédia avec au moins un deuxième coeur de réseau distinct du premier coeur de réseau IP multimédia. 2. Procédé de traitement selon la revendication 1 dans lequel ledit au moins un deuxième coeur de réseau est un coeur de réseau IP multimédia. 3. Procédé de traitement selon la revendication 1 ou 2 comprenant en outre : une étape de réception (E70, E90, F190, F230) d'au moins une réponse en provenance d'au moins un dit deuxième dispositif ; une étape de transmission (E110,F200, F240) vers le premier dispositif d'au moins une réponse à ladite requête élaborée (E100) à partir d'au moins une dite réponse reçue en fonction d'un type de ladite au moins une réponse reçue. 4. Procédé de traitement selon la revendication 3 dans lequel ladite au moins une réponse reçue lors de l'étape de réception comprend au moins une réponse reçue via un dit deuxième coeur de réseau. 5. Procédé de traitement selon la revendication 3 ou 4 dans lequel ladite au moins une réponse élaborée comprend : - toutes les réponses reçues lors de ladite étape de réception ; ou - la réponse reçue en premier lors de ladite étape de réception ; ou 32 la meilleure réponse reçue au regard d'un critère prédéfini parmi des réponses reçues lors de ladite étape de réception au cours d'une première période de temps prédéterminée ; - une agrégation de contenus extraits des réponses reçues lors de ladite étape de réception au cours d'une deuxième période de temps prédéterminée. 5 6. Procédé de traitement selon l'une quelconque des revendications 3 à 5 dans lequel ladite au moins une réponse est élaborée en fonction en outre d'un type de la requête émise par le premier dispositif. 10 7. Procédé de traitement selon l'une quelconque des revendications 1 à 6 dans lequel l'étape de réplication et les étapes de déclenchement des routages sont mises en oeuvre après vérification que ces étapes sont autorisées pour le premier dispositif et/ou pour ledit au moins un deuxième dispositif. 15 8. Procédé de traitement selon l'une quelconque des revendications 1 à 7 dans lequel l'étape de déclenchement du routage de la première requête et l'étape de déclenchement du routage de ladite au moins une deuxième requête sont mises en oeuvre simultanément. 9. Procédé de traitement selon l'une quelconque des revendications 1 à 8 dans lequel 20 l'étape de vérification comprend la vérification (F100) qu'une partie utilisateur de l'identité publique est contenue dans une base de données du premier coeur de réseau IP multimédia. 10. Procédé de traitement selon l'une quelconque des revendications 1 à 8 dans lequel le premier coeur de réseau IP multimédia met en oeuvre le protocole SIP (Session Initiation 25 Protocol) et l'étape de vérification comprend : - la dérivation d'un nom de domaine à partir de l'identité publique ; et - l'interrogation d'un serveur DNS (Domain Name Server) en utilisant le nom de domaine dérivé ; l'identité publique étant considérée lors de l'étape de vérification comme connue du premier coeur 30 de réseau IP multimédia si un identifiant SIP est reçu du serveur DNS en réponse à son interrogation. 11. Procédé de traitement selon l'une quelconque des revendications 1 à 10 dans lequel : 35 - le premier coeur de réseau IP multimédia met en oeuvre le protocole SIP et l'étape de déclenchement du routage de ladite au moins une deuxième requête n'est activée que si l'interconnexion entre le premier coeur de réseau IP multimédia et ledit au moins un deuxième coeur de réseau est réalisée en utilisant le protocole SIP; ou 33 - le premier coeur de réseau IP multimédia met en oeuvre au moins un protocole web et l'étape de déclenchement du routage de ladite au moins une deuxième requête n'est activée que si l'interconnexion entre le premier coeur de réseau IP multimédia et ledit au moins un deuxième coeur de réseau est réalisée en utilisant ledit au moins un protocole web. 5 12. Procédé de traitement selon l'une quelconque des revendications 1 à 8 ou 10 dans lequel : - le premier coeur de réseau IP multimédia implémente une architecture IMS (IP Multimedia Subsystem) et les étapes de vérification, de réplication et de déclenchement des routages sont 10 mises en oeuvre par un serveur S-CSCF ou par un serveur d'application du premier coeur de réseau IP multimédia ; ou - le premier coeur de réseau IP multimédia implémente une architecture WebRTC (Web Real lime Communication), et les étapes de vérification, de réplication et de déclenchement des routages sont mises en oeuvre par un serveur WebRTC du premier coeur de réseau IP 15 multimédia. 13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de traitement selon l'une quelconque des revendications 1 à 12. 20 14. Serveur (2,102) apte à traiter une requête émise par un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia à destination d'une identité publique allouée à au moins un deuxième dispositif, ledit serveur comprenant : un module de vérification (2A) configuré pour vérifier si ladite identité publique est connue 25 auprès du premier coeur de réseau IP multimédia ; des modules, activés si ladite identité publique est connue du premier coeur de réseau IP multimédia, et comprenant : o un module de réplication (2B), configuré pour répliquer ladite requête en une première requête et en au moins une deuxième requête ; 30 o un premier module de routage (2C), configuré pour déclencher un routage de la première requête au sein du premier coeur de réseau IP multimédia ; et o un deuxième module de routage (2D), configuré pour déclencher un routage de ladite au moins une deuxième requête selon une route prédéterminée à destination d'une entité d'interconnexion du premier coeur de réseau IP multimédia avec au moins un 35 deuxième coeur de réseau distinct du premier coeur de réseau IP multimédia. 15. Système de communication (1,101) comprenant : 34 - un premier dispositif (T1,T101) enregistré auprès d'un premier coeur de réseau IP multimédia, apte à émettre une requête à destination d'une identité publique allouée à au moins un second dispositif ; et un serveur (2,102) du premier coeur de réseau IP multimédia conforme à la revendication 14 5 et gérant le premier dispositif.