FR 2989548 A1 20131018 FR 1253529 A 20120417 Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications et des architectures de réseau IP (Internet Protocol) multimédia, telles que des architectures de réseau utilisant notamment la technologie désignée par "voix sur IP" (ou VoIP pour Voice over IP). Elle concerne plus particulièrement le traitement, par une entité dite de traitement, d'un message reçu en relation avec un message émis par un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia, à destination d'un second dispositif associé à un second coeur de réseau IP multimédia, dans le cadre d'un service de communication multimédia s'appuyant sur un mécanisme d'auto-découverte des capacités et/ou de l'état du distant (autrement dit ici, du second dispositif). Un tel mécanisme d'auto-découverte comprend, de façon connue en soi, l'envoi d'un message spécifique à un dispositif distant l'invitant à déclarer, en réponse à ce message, ses capacités, c'est-à-dire les services qu'il supporte, et/ou son état, le dispositif distant étant tenu de répondre à ce message. Ainsi, au sens de l'invention, un message de découverte des capacités et/ou de l'état du distant désigne un message envoyé par un dispositif à un dispositif distant, l'invitant à déclarer, en réponse à ce message, ses capacités, c'est-à-dire les services qu'il supporte, et/ou son état. Par ailleurs, un message reçu par une entité de traitement « en relation avec un message émis par un premier dispositif » désigne, au sens de l'invention, un message identique ou similaire au message émis par le premier dispositif aux ajouts et suppressions de champs et/ou d'entêtes près effectués par les éléments du ou des réseaux via lesquels a transité ce message entre le premier dispositif et l'entité de traitement du second coeur de réseau. Le premier coeur de réseau et le second coeur de réseau peuvent être opérés par le même opérateur ou par des opérateurs distincts. L'invention a ainsi une application privilégiée mais non limitative dans le contexte de coeurs de réseau IP multimédia mettant en oeuvre le protocole d'initiation de sessions multimédia SIP (Session Initiation Protocol), défini par le standard IETF (Internet Engineering Task Force) et décrit notamment dans le document RFC 3261 intitulé « SIP: Session Initiation Protocol », Juin 2002, édité par l'IETF. L'invention 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, elle 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.). De façon connue, le protocole de signalisation SIP s'appuie sur un certain nombre de méthodes ou messages SIP, telles que par exemple les méthodes SIP REGISTER, INVITE, SUBSCRIBE, NOTIFY ou OPTIONS. Parmi ces méthodes, la méthode SIP OPTIONS permet à un dispositif dit émetteur, tel que par exemple un terminal, de connaître les capacités (i.e. services supportés, ressources disponibles, etc.) et/ou l'état (ex. existant, non existant, enregistré, libre, occupé, etc.) d'un autre dispositif « distant » dit récepteur, ce dispositif récepteur pouvant être par exemple un terminal ou un serveur SIP (ex. un serveur proxy). Un message SIP OPTIONS est donc un message de découverte des capacités et/ou de l'état du distant au sens de l'invention. Ce type de message est avantageusement mis à profit aujourd'hui dans de nombreux services de communication multimédia proposés par les opérateurs de télécommunications pour améliorer leurs offres de service ainsi que l'expérience ressentie par les utilisateurs de ces services, comme par exemple dans des services de messagerie instantanée (IM pour Instant Messaging en anglais), ou dans des services dits RCS-e (Rich Communication Services - enhanced) tels que décrits dans le document intitulé « RCS-e Advanced Communications: Services and client spécification », version 1.1, Avril 8, 2011. Conformément à la norme SIP, tout dispositif récepteur d'un message SIP OPTIONS est tenu d'y répondre. Il convient de noter que la réception d'un message SIP OPTIONS se fait à l'insu de l'utilisateur du dispositif récepteur, autrement dit, elle n'est pas signalée spécifiquement à cet utilisateur (pas de sonnerie du dispositif récepteur ou de notification de la réception du message SIP OPTIONS). La norme SIP offre donc aujourd'hui la possibilité à tout dispositif émetteur d'un message SIP OPTIONS de découvrir en toute discrétion l'état et/ou les capacités d'un dispositif récepteur, sans que l'utilisateur de ce dispositif récepteur ne soit informé de la mise en oeuvre de ce mécanisme de découverte. Pour se prémunir des abus pouvant résulter d'un tel mode de fonctionnement, on peut envisager la mise en oeuvre de mécanismes de protection au niveau des dispositifs récepteurs. Un tel mécanisme de protection peut consister par exemple à prévoir, au niveau du dispositif récepteur, l'établissement et le maintien à jour d'un fichier de traçabilité recensant les différents messages SIP OPTIONS reçus par le dispositif récepteur à l'insu de son utilisateur, et identifiant les dispositifs émetteurs à l'origine de ces messages SIP OPTIONS. Ce fichier de traçabilité pourrait être consulté, en cas de besoin, par l'utilisateur du dispositif récepteur, et garantirait à l'utilisateur du dispositif récepteur une certaine transparence quant aux messages reçus à son insu. On comprend bien dès lors, que l'efficacité d'un tel mécanisme de protection dépend étroitement de la présence d'un identifiant du dispositif émetteur dans le message SIP OPTIONS reçu par le dispositif récepteur. Or, cet identifiant peut, pour diverses raisons, ne pas être présent dans le message SIP OPTIONS reçu par le dispositif récepteur. Ainsi par exemple, le dispositif émetteur peut avoir masqué son identité en activant le service OIR (Originating Identity Restriction) prévu pour les coeurs de réseau de voix sur IP par le standard 3GPP (Third Generation Partnership Project)), ou encore, l'utilisateur du dispositif récepteur peut ne pas avoir souscrit ou activé le service de présentation de l'identité du dispositif émetteur offert par le standard 3GPP, aussi connu sous le nom de service OIP (Originating Identity Presentation). Le fonctionnement des services OIP et OIR est défini en détails dans le document 3GPP TS24.607 intitulé « Technical Specification Group Core Network and Terminals; Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification », Release 10. Ce document prévoit notamment qu'une fois activés ou désactivés, ces services OIR et OIP de masquage de l'identité du dispositif émetteur s'appliquent de facto à tous les messages SIP émis par le dispositif émetteur et/ou reçus par le dispositif récepteur. Il convient de noter que la plupart des réseaux de télécommunications actuels s'appuient sur un découplage des appels téléphoniques et des services de communication multimédia, qui sont gérés respectivement via un réseau à commutation de circuit (CS pour Circuit Switch) pour les appels téléphoniques, et via un réseau à commutation de paquets (PS pour Packet Switch) s'appuyant sur une architecture de coeur de réseau IP multimédia pour les services de données. Dans un tel contexte, les utilisateurs qui activent les services de masquage de l'identifiant pour leurs appels téléphoniques via les services OIP et OIR ou des services équivalents définis pour les réseaux CS (ex. services CLIP (Calling Line Identification Presentation) ou CLIR (Calling Line Identification Restriction)), maitrisent les effets de ce masquage dans la mesure où celui-ci se limite à leurs appels téléphoniques. Toutefois, lorsque les réseaux de télécommunications migreront prochainement vers des réseaux « tout IP », l'activation d'un tel service de masquage de l'identifiant aura des impacts sur l'ensemble des services souscrits par l'utilisateur, c'est-à-dire à la fois sur ses appels téléphoniques et sur les services de données multimédia auxquels il a souscrits, puisque conformément aux recommandations du document 3GPP TS 24.607, le masquage de l'identifiant s'appliquera indifféremment à tous les messages SIP émis et/ou reçus. Par conséquent, la mise en oeuvre de ces services de masquage de l'identifiant du dispositif émetteur sur les coeurs de réseau IP multimédia risque de se traduire par une dégradation de certains services offerts par les opérateurs (tels que par exemple le mécanisme de protection cité précédemment), et donc a fortiori, par une dégradation de l'expérience ressentie par les utilisateurs de ces services. Objet et résumé de l'invention L'invention vise notamment à remédier aux inconvénients précités en proposant un procédé de traitement d'un message reçu, en relation avec un message émis par un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia à destination d'un second dispositif associé à un second coeur de réseau IP multimédia, ce procédé de traitement étant mis en oeuvre par une entité du second coeur de réseau IP multimédia et comprenant : si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif, une étape d'analyse d'au moins un champ de ce message reçu afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ; et le cas échéant, une étape de désactivation du masquage dans ledit au moins un champ du message reçu, avant de le transmettre vers le second dispositif de sorte qu'un identifiant du premier dispositif soit disponible dans le message transmis pour le second dispositif. Corrélativement, l'invention vise également une entité de traitement apte à traiter un message reçu en relation avec un message émis par un premier dispositif enregistré auprès d'un premier coeur de réseau IP multimédia, à destination d'un second dispositif associé à un second coeur de réseau IP multimédia, cette entité étant une entité du second coeur de réseau IP multimédia comprenant : des moyens de vérification pour vérifier si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif ; des moyens d'analyse, déclenchés le cas échéant, pour analyser au moins un champ du message reçu afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ; des moyens de désactivation, déclenchés si un masquage est détecté, pour désactiver ce masquage dans ledit au moins un champ du message reçu avant de le transmettre vers le second dispositif, de sorte qu'un identifiant du premier dispositif soit disponible dans le message transmis pour le second dispositif ; et des moyens de transmission du message dans lequel le masquage a été désactivé vers le second dispositif. L'invention propose ainsi de détecter, au niveau d'une entité du coeur de réseau du dispositif récepteur d'un message de découverte des capacités et/ou de l'état du distant (second dispositif au sens de l'invention), si un masquage de l'identifiant du dispositif émetteur de ce message (premier dispositif au sens de l'invention) est activé pour le dispositif récepteur, et le cas échéant, de désactiver ce masquage de sorte qu'un identifiant du dispositif émetteur soit disponible dans le message de découverte des capacités et/ou de l'état du distant, reçu par le dispositif récepteur. On évite ainsi une dégradation des services utilisant un identifiant du dispositif émetteur du message de découverte, puisque conformément à l'invention, un identifiant du dispositif émetteur est toujours fourni au dispositif récepteur dans le message de découverte. L'invention garantit donc, lorsque le dispositif récepteur implémente un mécanisme de protection tel que celui décrit précédemment, qu'un identifiant des dispositifs émetteurs à l'origine des messages de découverte reçus par le dispositif récepteur, soit toujours inclus dans le fichier de traçabilité recensant les messages de découverte reçus par le dispositif récepteur. L'invention permet par conséquent de garantir une totale transparence à l'utilisateur du dispositif récepteur et une parfaite traçabilité des messages de découverte reçus à son insu, tels que les messages SIP OPTIONS pour les coeurs de réseau IP multimédia SIP. Avantageusement, l'invention s'applique de façon ciblée aux messages de découverte des capacités et/ou de l'état du distant, et non à l'ensemble des messages destinés au second dispositif. L'invention ne vise pas en effet à désactiver totalement le masquage de l'identifiant du premier dispositif voulu par l'utilisateur de ce premier dispositif (par exemple en activant le service OIR) ou par celui du second dispositif (par exemple en ne souscrivant pas au service OIP). Au contraire, elle permet d'assurer une transparence à l'utilisateur du second dispositif uniquement par rapport aux messages reçus à l'insu de celui-ci et auxquels le second dispositif est tenu de répondre, du fait de contraintes imposées par la norme. La fourniture de cet identifiant n'est donc réalisée, conformément à l'invention, qu'à titre exceptionnel dans le cadre de l'émission d'un message de découverte des capacités et/ou de l'état du distant. Par ailleurs, l'invention est mise en oeuvre dans le coeur de réseau du second dispositif, récepteur du message de découverte. Ceci permet avantageusement de parer aux différents cas de masquage de l'identifiant du premier dispositif qui peuvent être mis en place dans les premier et/ou second coeurs de réseau IP multimédia, à savoir notamment : - un masquage de l'identifiant par le premier dispositif, par exemple via l'insertion d'un identifiant anonyme ou non valide dans un champ du message de découverte ; un masquage par une entité du premier coeur de réseau, ou encore, - un masquage par une entité du second coeur de réseau telle que le serveur d'application de terminaison d'appel. A cette fin, l'entité de traitement selon l'invention pourra être intégrée dans le serveur d'application de terminaison d'appel (aussi connu sous le nom anglais de « terminating application server ») du second coeur de réseau IP multimédia, ou préférentiellement dans un dispositif situé en aval de ce serveur d'application de terminaison d'appel. L'invention permet ainsi de fournir un identifiant du premier dispositif au second dispositif y compris lorsque le masquage de l'identifiant est mis en oeuvre par le serveur d'application de terminaison d'appel (par exemple, en cas de désactivation ou de non-souscription au service OIP). L'intégration de l'entité de traitement dans un dispositif situé en aval du serveur d'application de terminaison d'appel plutôt que dans le serveur d'application de terminaison d'appel permet en outre d'optimiser les performances du second coeur de réseau : elle ne nécessite pas en effet le déclenchement du serveur d'application de terminaison d'appel sur réception du message de découverte, un tel déclenchement pouvant s'avérer coûteux en termes de ressources (les performances de certaines entités du coeur de réseau, comme par exemple des serveurs S-CSCF (Serving Call State Control Function) pour une architecture IMS de coeur de réseau, diminuent en effet de façon connue lorsque l'on déclenche de multiples serveurs d'application). Pour un second coeur de réseau IP multimédia implémentant une architecture IMS mettant en oeuvre le protocole d'initiation de session multimédia SIP, l'entité de traitement peut notamment être intégrée dans un dispositif quelconque du second coeur de réseau IP multimédia parmi : un serveur S-CSCF ; un serveur P-CSCF (Proxy-Cali State Control Function) ; ou un contrôleur de session SBC (Session Border Controler). En variante, lorsque le second coeur de réseau IP multimédia implémente une architecture mettant en oeuvre le protocole SIP mais différente d'une architecture IMS, l'entité de traitement selon l'invention est intégrée dans un serveur proxy SIP du second coeur de réseau IP multimédia. Ainsi, l'invention s'applique de façon privilégiée mais non limitative lorsque : le premier coeur de réseau IP multimédia et le second coeur de réseau IP multimédia mettent en oeuvre le protocole SIP ; - le message de découverte des capacités et/ou d'un état du second dispositif est un message SIP OPTIONS ; et - ledit au moins un champ analysé au cours de l'étape d'analyse est un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS. Corrélativement, lorsque le premier coeur de réseau IP multimédia et le second coeur de réseau IP multimédia mettent en oeuvre le protocole SIP : les moyens de vérification de l'entité de traitement selon l'invention sont aptes à vérifier si le message reçu est un message SIP OPTIONS ; et les moyens d'analyse de l'entité de traitement selon l'invention sont aptes à analyser un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS. Dans un mode particulier de réalisation de l'invention, le procédé de traitement comprend en outre une étape de détermination, conditionnant la mise en oeuvre des étapes d'analyse et de désactivation, au cours de laquelle on détermine si le message reçu est en relation avec un message émis par le premier dispositif dans le cadre d'un échange autonome entre le premier dispositif et le second dispositif. Autrement dit, dans ce mode de réalisation, on ne désactive le masquage de l'identifiant du premier dispositif que si le message de découverte des capacités et/ou de l'état du distant est émis dans le cadre d'une transaction autonome ou transaction « standalone » entre le premier dispositif et le second dispositif, c'est-à-dire, qui n'est pas réalisée dans le cadre d'un dialogue établi entre le premier dispositif et le second dispositif ou qui n'initie pas un tel dialogue. L'invention présente en effet un avantage supplémentaire dans un tel contexte, car le second dispositif ne dispose pas d'autres moyens d'accéder à un identifiant du premier dispositif et de façon similaire, le premier dispositif ne dispose pas d'autres moyens d'accéder aux capacités et/ou à l'état du second dispositif que l'envoi d'un message de découverte (ils ne peuvent pas se référer à un dialogue déjà établi entre les deux dispositifs ou consulter d'autres applications disposant déjà de ces informations). On notera en revanche que lorsqu'un dialogue est déjà établi entre les deux dispositifs, cela signifie d'une part que le second dispositif a accepté une communication du premier dispositif en dépit du masquage de son identifiant, et d'autre part, que l'état du second dispositif est occupé. Comme mentionné précédemment, le masquage d'un identifiant du premier dispositif pour le second dispositif peut être activé à différents niveaux du réseau, et se traduire dans différents champs du message de découverte des capacités et/ou de l'état du distant reçu par l'entité de traitement du second coeur de réseau. L'invention prévoit différentes variantes de réalisation permettant d'envisager ces différents cas de figure. Ainsi, selon une première variante de réalisation, au cours de l'étape d'analyse, on analyse un champ du message reçu destiné à contenir un identifiant du premier dispositif fourni par le premier dispositif. L'étape de désactivation peut alors comprendre l'insertion, dans le champ destiné à contenir un identifiant du premier dispositif fourni par le premier dispositif, d'un identifiant du premier dispositif certifié par un élément du premier coeur de réseau IP multimédia et contenu dans le message reçu. De façon connue en soi, un tel identifiant certifié est inséré systématiquement par le coeur du réseau du premier dispositif (premier coeur de réseau au sens de l'invention) dans les messages gérés par celui-ci, notamment aux fins de procédures mises en oeuvre par le premier coeur de réseau qui nécessitent la présence d'un tel identifiant certifié, ou lorsque ces messages sont transférés vers le coeur du réseau du second dispositif, pour permettre par exemple la facturation du service dans le cadre duquel ce message est échangé. Cet identifiant certifié est habituellement supprimé par le second coeur de réseau avant de délivrer le message au second dispositif. Au contraire, conformément à la première variante de réalisation de l'invention, cet identifiant certifié est utilisé pour fournir au second dispositif un identifiant du premier dispositif dans le message de découverte, lorsque le champ du message de découverte destiné à contenir un identifiant du premier dispositif ne contient pas d'identifiant du premier dispositif ou de façon équivalente contient un identifiant anonyme ou non valide. Selon un aspect de cette première variante de réalisation, lorsque le premier coeur de réseau IP multimédia et le second coeur de réseau IP multimédia mettent en oeuvre le protocole SIP et le message de découverte des capacités et/ou d'un état du second dispositif est un message SIP OPTIONS au cours de l'étape d'analyse, on détecte qu'un masquage est activé pour le second dispositif si le champ FROM du message SIP OPTIONS contient un identifiant dit anonyme préservant l'anonymat du premier dispositif ou un identifiant non valide du premier dispositif ; et au cours de l'étape de désactivation du masquage, on remplace l'identifiant anonyme par un identifiant contenu dans un champ SIP P-Asserted-Identity du message SIP OPTIONS. Dans une seconde variante de réalisation de l'invention, au cours de l'étape d'analyse, on analyse un champ contenant un niveau de confidentialité requis pour le message reçu. Un tel champ est par exemple le champ SIP PRIVACY du message SIP OPTIONS tel que défini dans le document RFC 3323 édité par l'IETF et intitulé « A privacy mechanism for the Session Initiation Protocol (SIP) », Novembre 2002. Ce champ peut prendre différentes valeurs, à savoir les valeurs « none » (pas de confidentialité), « header » (le premier dispositif souhaite masquer l'identité présente dans le champ « FROM » du message SIP OPTIONS), ou « id » (le premier dispositif souhaite masquer l'identité certifiée par le réseau présente dans le champ SIP P- Asserted-Identity du message SIP OPTIONS). Cette valeur est fixée par le premier coeur de réseau ou par le second coeur de réseau (ex. via une application web ou un portail), en fonction de la façon dont le masquage de l'identifiant du premier dispositif est activé. Dans l'état actuel de la technique, lorsque cette valeur est représentative d'un masquage de l'identifiant du premier dispositif pour le second dispositif, autrement dit lorsqu'elle est égale à une valeur différente de la valeur « none », l'identifiant du premier dispositif présent dans le message de découverte est supprimé de ce message de découverte avant son transfert vers le second dispositif. Au contraire, dans la seconde variante de réalisation de l'invention, l'étape de désactivation du masquage comprend le positionnement dans ce champ d'une valeur reflétant un niveau de confidentialité nul, de sorte qu'un identifiant du premier dispositif est disponible dans le message de découverte reçu par le second dispositif. Ainsi, à titre d'exemple pour un message SIP OPTIONS - au cours de l'étape d'analyse, on détecte qu'un masquage est activé pour le second dispositif si le champ SIP PRIVACY du message SIP OPTIONS contient un niveau de confidentialité positionné à une valeur différente de la valeur « none » ; et - au cours de l'étape de désactivation du masquage, on remplace la valeur du niveau de confidentialité du champ SIP PRIVACY par la valeur « none ». 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. 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 une entité de traitement selon l'invention 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 forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L'invention vise également un coeur de réseau IP multimédia comprenant une entité de traitement selon l'invention. On peut également envisager, dans d'autres modes de réalisation, que le procédé de traitement, l'entité et le coeur de réseau selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. 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 : la figure 1 représente, de façon schématique, un environnement de télécommunications incluant une entité de traitement selon l'invention, dans un mode particulier de réalisation ; la figure 2 représente, de façon schématique, l'architecture matérielle de l'entité de traitement représentée sur la figure 1 ; et la figure 3 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de traitement selon l'invention, lorsqu'elles sont mise en oeuvre par l'entité de traitement de la figure 1, dans un mode particulier de réalisation. Description détaillée d'un mode de réalisation La figure 1 représente un environnement de télécommunications incluant une entité de traitement selon l'invention, dans un mode particulier de réalisation. Dans l'exemple décrit ici, on envisage le traitement par cette entité d'un message reçu M' en relation avec un message M de découverte des capacités et/ou de l'état du distant émis par un premier dispositif T1 à destination d'un second dispositif T2, dans le cadre d'un service de communication multimédia, tel que par exemple le service RCS-e. On suppose qu'un mécanisme de protection tel que décrit précédemment est mis en place au niveau du dispositif T2, de sorte que sur réception d'un message de découverte des capacités et/ou de l'état du distant, celui-ci mémorise, dans un fichier de traçabilité, différentes informations en relation avec ce message, telles que notamment un identifiant du dispositif T1 à l'origine du message M, le moment (ex. heure et jour) auquel ce message a été reçu, etc. Il convient toutefois de noter qu'aucune limitation n'est attachée au mécanisme de protection à proprement parler mis en oeuvre par le dispositif T2 à partir de l'identifiant du dispositif T1 à l'origine du message M. L'invention s'applique également, bien entendu, lorsque d'autres mécanismes de protection ou même d'autres types de mécanismes utilisant un identifiant du dispositif T1 à l'origine du message M sont mis en oeuvre au niveau du dispositif T2. Conformément à l'invention, on s'assure qu'un identifiant du dispositif T1 à l'origine du message M est toujours disponible dans le message parvenant au dispositif T2, y compris lorsqu'un masquage de l'identifiant du dispositif Tl est activé par le dispositif T1 ou par un élément du ou des réseaux de télécommunications participant à l'acheminement du message jusqu'au dispositif T2. Les dispositifs T1 et T2 sont ici des terminaux, gérés par (ou associés à) des coeurs de réseau IP multimédia distincts, CN1 et CN2 respectivement. Les coeurs de réseau CN1 et CN2 sont ici des coeurs de réseau utilisant la technologie « voix sur IP », et implémentent une architecture IMS, telle que définie notamment dans le document 3GPP TS 22.228 « Service requirements for the IP Multimedia Core Network Subsystem (Stage 1) », et mettant en oeuvre le protocole d'initiation de session SIP. Ces hypothèses ne sont toutefois pas limitatives, et l'invention s'applique également lorsque les coeurs de réseau CN1 et CN2 ne forment qu'un seul coeur de réseau IP multimédia, ainsi qu'à d'autres types de dispositifs (par exemple T2 peut être un serveur proxy), à d'autres architectures de coeur de réseau IP multimédia, et à d'autres protocoles d'initiation de session, tels que par exemple à des architectures de coeurs de réseau propriétaires utilisant le protocole SIP ou un autre protocole d'initiation de session propriétaire prévoyant un message de découverte des capacités et/ou de l'état du distant. De façon connue en soi, le coeur de réseau IMS CN1 comprend plusieurs entités fonctionnelles. Ainsi, dans le mode de réalisation décrit ici, il comprend notamment : une entité CSCF (Cali Session Control Function), elle-même composée de plusieurs équipements ou serveurs logiques dont : o un serveur P-CSCF 1 (Proxy Call Session Control Function), point de contact du terminal T1 avec le coeur de réseau CN1 ; o un serveur S-CSCF 2 (Serving Call Session Control Function) en charge de l'enregistrement du terminal T1 sur le coeur de réseau CN1 et du déclenchement des serveurs d'applications ; et o un serveur I-CSCF 3 (Interrogating Call Session Control Function), en charge de l'interrogation d'une base de données HSS (Home Subscriber Server, non représentée sur la figure 1) et de l'aiguillage de messages pour l'initialisation des connexions au coeur de réseau CN1 ; et un ou plusieurs serveurs d'applications (Application Servers) hébergeant et fournissant des services, tels qu'un serveur d'application 4 d'initiation d'appel (Originating Application Server). De façon similaire, le coeur de réseau IMS CN2 comprend plusieurs entités fonctionnelles, dont notamment ici : une entité CSCF composée de plusieurs équipements ou serveurs logiques dont : o un serveur I-CSCF 5 ; o un serveur S-CSCF 6 ; o un serveur P-CSCF 7 ; et un ou plusieurs serveurs d'applications (Application Servers) hébergeant et fournissant des services, tels qu'un serveur d'application 8 de terminaison d'appel (Terminating Application Server). Dans le mode de réalisation envisagé ici, le serveur S-CSCF 6 intègre les fonctionnalités d'une entité de traitement conforme à l'invention (i.e. le serveur S-CSCF 6 est une entité de traitement conforme à l'invention), et dispose de l'architecture matérielle d'un ordinateur représentée schématiquement sur la figure 2. Le serveur S-CSCF 6 comporte notamment un processeur 6A, une mémoire vive 6B, une mémoire morte 6C, et des moyens de communication 6D avec, en particulier, les entités des coeurs de réseau CN1 et CN2 et le terminal T2, ces moyens de communication 6D mettant en oeuvre le protocole SIP. La mémoire morte 6C du serveur S-CSCF 6 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 6A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de traitement selon l'invention décrites ultérieurement en référence à la figure 3. Ainsi, conformément à l'invention, le serveur S-CSCF 6 est apte à traiter un message reçu en relation avec un message de découverte des capacités et/ou de l'état du distant émis par le terminal T1 à destination du terminal T2, pour garantir qu'un identifiant du terminal T1 est fourni au terminal T2 dans le message de découverte lui parvenant. On s'assure ainsi que le terminal T2 puisse renseigner, dans le fichier de traçabilité, l'identifiant du terminal T1 émetteur du message de découverte des capacités et/ou de l'état du terminal T2. Différentes causes peuvent être à l'origine d'un masquage de l'identifiant du terminal T1 dans le message de découverte reçu par le serveur S-CSCF 6 et destiné au terminal T2. Ainsi, ce masquage peut être du fait du terminal T1 lui-même (via l'insertion d'un identifiant anonyme dans le message par exemple), ou d'un élément du coeur de réseau CN1 (par exemple suite à l'activation d'un service CLIR ou OIR par l'utilisateur du terminal T1), ou encore d'un élément du coeur de réseau CN2 (par exemple suite à la non souscription ou à la désactivation d'un service CLIP ou OIP par l'utilisateur du terminal T2). Il convient de noter que dans le mode de réalisation décrit ici dans lequel les coeurs de réseau IP multimédia CN1 et CN2 mettent en oeuvre le protocole SIP, un masquage de l'identifiant du terminal T1 pour le terminal T2 peut se traduire au niveau de deux champs du message de découverte SIP OPTIONS, à savoir : au niveau du champ FROM reflétant l'origine du message, et/ou au niveau du champ PRIVACY reflétant le niveau de confidentialité requis pour le message SIP OPTIONS. Par ailleurs, il convient également de noter que, de façon connue en soi, dans l'état actuel de la technique, pour permettre l'acheminement du message émis par le terminal T1 jusqu'au terminal T2, le message M' reçu par le serveur S-CSCF 6 contient toujours un identifiant valide du terminal T1, qu'un masquage ait été activé ou non par le terminal T1 ou par le coeur de réseau CN1. Cet identifiant peut être fourni par le terminal T1 et présent dans le champ FROM du message SIP OPTIONS, et/ou fourni par une entité du coeur de réseau CN1 sous la forme d'un identifiant certifié présent dans le champ P-Asserted-Identity du message SIP OPTIONS. Si un masquage est activé au niveau du coeur de réseau CN1 ou au niveau du coeur de réseau CN2, cet identifiant sera alors supprimé du message par un élément du coeur de réseau CN2 avant que celui-ci soit fourni au terminal T2. Nous allons maintenant décrire en référence à la figure 3, les principales étapes d'un procédé de traitement selon l'invention mises en oeuvre par le serveur S-CSCF 6 pour le traitement du message reçu M' en relation avec le message M émis par le terminal T1 à destination du terminal T2, dans une variante particulière de réalisation. Dans l'exemple envisagé ici, on suppose que le message M émis par le terminal T1 à destination du terminal T2 est un message SIP OPTIONS de découverte des capacités et/ou de l'état du distant, à savoir ici du terminal T2, émis dans le cadre du service de communications multimédia RCS-e. T1 et T2 sont supposés ici enregistrés auprès de leurs coeurs de réseau respectifs CN1 et CN2. Le message M transite, de façon connue en soi par les éléments du coeur de réseau CN1, puis par les éléments du coeur de réseau CN2 jusqu'au serveur S-CSCF 6. Il est reçu sous la forme d'un message reçu M' par le serveur S-CSCF 6 (étape E10). Le message M' reçu par le serveur S-CSCF 6 est un message reçu en relation avec le message M au sens de l'invention, c'est-à-dire qu'il est identique ou similaire au message M émis par le terminal T1 aux ajouts et suppressions de champs et/ou d'entêtes près, effectués par les éléments du ou des réseaux via lesquels a transité ce message entre le terminal T1 et le serveur S- CSCF 6. Ainsi, par exemple, le coeur de réseau CN1 peut avoir modifié le champ PRIVACY du message M émis par le terminal Ti de sorte à activer un masquage de l'identifiant du terminal Tl pour le terminal T2. De même, un élément du coeur de réseau CN1 peut avoir inséré dans le message M un identifiant certifié du terminal Ti. Le message M' est donc également un message SIP OPTIONS contenant le même champ FROM que le message M et dont le champ PRIVACY a éventuellement été modifié par le coeur de réseau CN1. Le message M' contient par ailleurs un identifiant certifié du terminal T1 inséré par un élément du coeur de réseau CN1 dans le champ P-Asserted-Identity. Sur réception du message M', le serveur S-CSCF 6 détermine dans un premier temps s'il s'agit d'un message de découverte des capacités et/ou d'un état du distant, autrement dit d'un message SIP OPTIONS (étape test E20). Si le message M' n'est pas un message SIP OPTIONS (réponse non au test E20), le serveur S-CSCF 6 le transmet sans traitement supplémentaire autre que les traitements prévus classiquement par un serveur S-CSCF vers le terminal T2 (étape E30). Si le message M' est un message SIP OPTIONS (réponse oui au test E20), le serveur S- CSCF 6 détermine ici dans un second temps si ce message M' est en relation avec un message émis dans le cadre d'un échange ou d'une transaction autonome entre les terminaux T1 et T2 (étape test E40). A cette fin, le serveur S-CSCF 6 identifie si le message M' contient un identifiant d'un dialogue SIP établi entre T1 et T2 formé, de façon connue en soi, par les champs (FromTag, ToTag, CaIIID). Dans le mode de réalisation décrit ici, on envisage en effet un traitement différencié des messages SIP OPTIONS échangés dans le cadre d'une transaction autonome et dans le cadre d'un dialogue SIP établi : seuls les messages SIP OPTIONS échangés dans le cadre de transaction autonome sont traités dans ce mode de réalisation conformément à l'invention par le serveur SCSCF 6. Ainsi, si le message M' contient un identifiant de dialogue SIP établi (réponse non au test E40), le serveur S-CSCF 6 le transmet sans traitement supplémentaire autre que les traitements prévus classiquement par un serveur S-CSCF vers le terminal T2 (étape E30). Si le serveur S-CSCF 6 détermine que le message M' est en relation avec un message M échangé dans le cadre d'une transaction autonome entre Tl et T2, autrement dit, si le message M' ne contient pas d'identifiant de dialogue (réponse oui au test E40), le serveur S-CSCF 6 analyse alors au moins un champ de ce message afin de détecter si un masquage d'un identifiant du terminal T1 est activé pour le terminal T2. Dans le mode de réalisation décrit ici, le serveur S-CSCF 6 analyse les champs SIP FROM et PRIVACY du message SIP OPTIONS pour détecter si un masquage de l'identifiant du terminal T1 est activé pour le terminal T2. Plus précisément, le serveur S-CSCF 6 analyse tout d'abord le champ FROM du message SIP OPTIONS. Ce champ FROM, de façon connue en soi, est destiné à contenir un identifiant du terminal T1 fourni par celui-ci lors de l'émission du message M. Afin de détecter si un masquage est activé, le serveur S-CSCF 6 examine, au cours de cette étape d'analyse, si le champ FROM contient un identifiant dit anonyme (étape test E50). Par identifiant anonyme on entend ici un identifiant fourni par le terminal T1 et destiné à préserver l'anonymat du terminal Tl. Des exemples d'un tel identifiant anonyme sont décrits dans le document RFC 3323 cité précédemment : ces identifiants contiennent la chaîne de caractères « anonymous ». Ainsi par exemple : « sip:a0017@anonymous-sip.com » ou « sip :anonymous@anonymous.invalid » sont des identifiants anonymes qui peuvent être insérés dans le champ FROM par le terminal Ti si celui-ci désire masquer son identifiant au terminal T2. Ainsi, dans le mode de réalisation décrit ici, pour détecter si le champ FROM contient un identifiant anonyme, le serveur S-CSCF 6 recherche, au cours de l'étape d'analyse, si le contenu du champ FROM comprend la chaîne de caractères « anonymous ». En variante, d'autres chaînes de caractères peuvent être recherchées pour parer à des configurations différentes du terminal pouvant être utilisées pour préserver son anonymat. Si le champ FROM ne contient pas d'identifiant anonyme (réponse non au test E50) mais un identifiant ayant un format valide au regard des formats d'identifiants classiquement utilisés pour identifier un dispositif conformément au protocole SIP (ex. sip :+33296053859@operator.multimedia.fr), le serveur S-CSCF 6 laisse le champ FROM inchangé et passe à l'étape d'analyse du champ SIP PRIVACY du message SIP OPTIONS. Si en revanche, le serveur S-CSCF 6 détecte que le champ FROM contient un identifiant anonyme (réponse oui au test E50), il désactive le masquage de l'identifiant du terminal T1 en insérant, à la place de l'identifiant anonyme, un identifiant du terminal T1 certifié par une entité du coeur de réseau CN1 (étape E60). Comme mentionné précédemment cet identifiant certifié est inclus dans le message M' et contenu dans le champ SIP P-Asserted-Identity du message SIP OPTIONS. Il a été inséré, de par une entité du coeur de réseau CN1 lors du transit du message M via le coeur de réseau CN1. Dans une variante de réalisation, au cours de l'étape d'analyse, le serveur S-CSCF 6 examine également si le champ FROM contient un identifiant non valide, c'est-à-dire, un identifiant qui de par sa forme, ressemble à un identifiant du terminal T1 (typiquement cet identifiant ne contient pas la chaîne de caractères « anonymous »), mais qui n'est pas cohérent avec l'identité réelle du terminal T1. Le serveur S-CSCF 6 peut détecter la présence d'un tel identifiant non valide en comparant par exemple l'identifiant certifié du terminal T1 présent dans le champ SIP P-Asserted- Identity du message SIP OPTIONS et l'identifiant du terminal T1 présent dans le champ FROM. En effet, de façon connue en soi, ces identifiants sont censés être identiques au moins sur leurs 5 ou 6 premiers digits. Un identifiant présent dans le champ FROM qui auraient ses 5 premiers digits différents de ceux de l'identifiant certifié spécifié dans le champ SIP P-Asserted-Identity du message SIP OPTIONS serait alors considéré comme non valide par le serveur S-CSCF 6. Si le serveur S-CSCF 6 détecte que le champ FROM contient un tel identifiant non valide, il remplace cet identifiant par l'identifiant certifié présent dans le champ SIP P-Asserted- Identity du message SIP OPTIONS. Ainsi, à l'issue de l'étape E60, un identifiant du terminal T1 est présent dans le champ FROM du message traité par le serveur S-CSCF 6 : il s'agit soit de l'identifiant (valide) fourni par le terminal T1, soit d'un identifiant certifié fourni par un élément du coeur de réseau CN1. Le serveur S-CSCF 6 examine ensuite le champ SIP PRIVACY du message SIP OPTIONS M' afin de détecter si un masquage de l'identifiant du terminal Ti est activé pour le terminal T2 via ce champ (étape test E70). Un tel masquage se traduit au niveau du champ SIP PRIVACY par une valeur du champ distincte de la valeur « none » (la valeur « none » selon le protocole SIP reflète un niveau de confidentialité nul). Si le champ SIP PRIVACY n'est pas positionné à la valeur « none » (réponse oui au test E70), mais par exemple à la valeur « header » ou « id », le serveur S-CSCF 6 désactive le masquage de l'identifiant du terminal T1 pour le terminal T2 en insérant à la place de cette valeur, la valeur « none » dans le champ PRIVACY (étape E80). Si le champ SIP PRIVACY est au contraire déjà positionné à la valeur « none » (réponse non au test E70), le serveur S-CSCF 6 le laisse inchangé. On désigne par M" le message obtenu à l'issue de l'étape E80, et qui contient les champs FROM et PRIVACY éventuellement modifiés par le serveur S-CSCF 6 pour désactiver le masquage de l'identifiant du terminal Ti. Le serveur S-CSCF 6 transmet alors le message M" vers le terminal T2 (étape E90). Les modifications des champs FROM et/ou PRIVACY conformément à l'invention permettent ainsi de désactiver le masquage de l'identifiant du terminal Tl pour le terminal T2 de sorte qu'un identifiant du terminal T1 est disponible pour le second terminal T2 dans le champ FROM du message SIP OPTIONS lui parvenant. Cet identifiant est soit l'identifiant fourni par le terminal T1 lui-même, soit un identifiant certifié par le coeur de réseau CN1. Sur réception du message SIP OPTIONS M" (ou d'un message dérivé du message M" en fonction des éléments du coeur de réseau CN2 traversés par le message M" jusqu'au terminal T2), le terminal T2 dispose d'un identifiant du terminal Tl dans le champ FROM du message SIP OPTIONS. Il peut alors renseigner le fichier de traçabilité recensant les différents messages SIP OPTIONS reçus par le terminal T2 en incluant dans ce fichier le moment auquel le message SIP OPTIONS en provenance du terminal T1 a été reçu et l'identifiant du terminal T1 compris dans le champ FROM. Dans le mode de réalisation décrit en détail ici, les coeurs de réseau IP multimédia CN1 et CN2 sont des coeurs de réseau distincts. En variante, l'invention s'applique également lorsque les terminaux T1 et T2 sont gérés par le même coeur de réseau, auquel cas l'entité de traitement est intégrée dans le serveur S-CSCF gérant le terminal T2. Dans le mode de réalisation décrit ici, l'entité de traitement selon l'invention est intégrée dans le serveur S-CSCF 6 du coeur de réseau CN2 de destination du message M. Le serveur S-CSCF 6 est placé dans le coeur de réseau CN2, de façon connue en soi, en aval du serveur d'application de terminaison d'appel. Cette position avantageuse de l'entité de traitement selon l'invention dans le serveur S-CSCF 6 permet ainsi de parer à différents cas de figure pouvant se présenter : - les messages SIP OPTIONS sont échangés entre les terminaux Ti et T2 en empruntant les coeurs de réseau IMS CN1 et CN2 mais ne transitent pas par les serveurs d'application mettant en oeuvre les services CLIR/OIR et CLIP/OIP (i.e. par les serveurs d'application 4 et 8) ; les messages SIP OPTIONS sont échangés entre les terminaux T1 et T2 en empruntant les coeurs de réseau IMS CN1 et CN2 et transitent par les serveurs d'application 4 et 8 mettant en oeuvre respectivement les services CLIR/OIR et CLIP/OIP ; - les messages SIP OPTIONS sont échangés entre les terminaux Tl et T2 en empruntant les coeurs de réseau IMS CN1 et CN2, transitent par le serveur d'application 4 mettant en oeuvre les services CLIR/OIR mais ne transitent pas par le serveur d'application 8 mettant en oeuvre les services CLIP/OIP (ex. un tel cas de figure peut se présenter si les coeurs de réseau CN1 et CN2 sont gérés par des opérateurs différents) ; ou - les messages SIP OPTIONS sont échangés entre les terminaux Ti et T2 en empruntant les coeurs de réseau IMS CN1 et CN2, ne transitent pas par le serveur d'application 4 mettant en oeuvre les services CLIR/OIR mais transitent par le serveur d'application 8 mettant en oeuvre les services CLIP/OIP (ex. un tel cas de figure peut se présenter si les coeurs de réseau CN1 et CN2 sont gérés par des opérateurs différents). Ce mode de réalisation présente également un autre avantage lorsqu'une pluralité de terminaux T2 portent la même identité publique ou IMPU (IP Multimedia Public Identity), qui est de ne nécessiter l'application du traitement conformément à l'invention que sur un seul message M'. Le standard 3GPP prévoit en effet la possibilité pour une pluralité de terminaux de partager la même identité publique IMPU, auquel cas une fonction de réplication (ou de « forking » en anglais) des messages destinés à l'identité publique IMPU est mise en oeuvre au niveau du S- CSCF afin que chaque terminal associé à l'identité publique IMPU reçoive une réplique de ces messages. L'intégration des fonctionnalités de l'entité de traitement selon l'invention au niveau du S-CSCF 6 permet d'appliquer le traitement pour désactiver le masquage de l'identifiant du terminal T1 avant la fonction de forking : la fonction de forking est alors appliquée sur le message M" contenant l'identifiant du terminal T1, afin d'optimiser les ressources. Dans un autre mode de réalisation, l'entité de traitement du message M' selon l'invention peut être intégrée dans un autre dispositif ou un autre élément du coeur de réseau CN2, préférentiellement situé en aval du serveur d'application de terminaison d'appel, comme par exemple dans le serveur P-CSCF 7 ou dans un contrôleur de session SBC du coeur de réseau CN2 (non représenté sur la figure 1). Il convient toutefois de noter que dans ce mode de réalisation, si plusieurs terminaux T2 partagent la même identité publique IMPU, la fonction de forking étant mise en oeuvre dans le serveur S-CSCF 6 en amont du traitement selon l'invention, celui-ci devra être appliqué à chaque réplique du message SIP OPTIONS associée à chaque terminal T2. Chaque réplique constitue un message en relation avec un message de découverte émis par le terminal T1 au sens de l'invention. Dans un autre mode de réalisation encore, l'entité de traitement du message M' selon l'invention peut être intégrée dans le serveur d'application 8 de terminaison d'appel, moyennant la mise en place d'un critère de déclenchement du serveur d'application 8 sur réception d'un message de découverte SIP OPTIONS (ou d'un message SIP OPTIONS dans le cadre d'une transaction autonome). Dans un autre mode de réalisation, le coeur de réseau CN2 implémente une architecture différente d'une architecture IMS. L'entité de traitement selon l'invention est alors intégrée dans un serveur proxy SIP quelconque du coeur de réseau CN2. Dans ces différents modes de réalisation de l'invention dans lesquels l'entité de traitement est intégrée soit dans le serveur P-CSCF 7, soit dans le serveur d'application 8, soit dans un contrôler de session SBC ou dans un serveur proxy SIP, le traitement réalisé sur le message M' conformément à l'invention se déroule de façon identique à celui décrit en référence à la figure 3 lorsque l'entité de traitement est intégrée dans le serveur S-CSCF 6. REVENDICATIONS1. Procédé de traitement d'un message reçu (M'), en relation avec un message (M) émis par un premier dispositif (T1) enregistré auprès d'un premier coeur de réseau (CN1) IP multimédia à destination d'un second dispositif (T2) associé à un second coeur de réseau (CN2) IP multimédia, ledit procédé de traitement étant mis en oeuvre par une entité (6) du second coeur de réseau IP multimédia et comprenant : - si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif (E20), une étape d'analyse (E50, E70) d'au moins un champ de ce message reçu afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ; et le cas échéant, une étape de désactivation (E60, E80) dudit masquage dans ledit au moins un champ dudit message reçu, avant de le transmettre (E90) vers le second dispositif (T2) de sorte qu'un identifiant du premier dispositif est disponible dans le message transmis pour le second dispositif. 2. Procédé de traitement selon la revendication 1 comprenant en outre, une étape de détermination (E40), conditionnant la mise en oeuvre des étapes d'analyse (E50, E70) et de désactivation (E60, E80), au cours de laquelle on détermine si le message reçu est en relation avec un message émis par le premier dispositif dans le cadre d'un échange autonome entre le premier dispositif et le second dispositif. 3. Procédé de traitement selon la revendication 1 dans lequel, au cours de l'étape d'analyse (E50), on analyse un champ du message reçu destiné à contenir un identifiant du premier dispositif fourni par le premier dispositif. 4. Procédé de traitement selon la revendication 3 dans lequel l'étape de désactivation (E60) comprend l'insertion, dans un champ destiné à contenir un identifiant du premier dispositif fourni par le premier dispositif, d'un identifiant du premier dispositif certifié par une entité du premier coeur de réseau IP multimédia et contenu dans le message reçu. 5. Procédé de traitement selon la revendication 1, dans lequel au cours de l'étape d'analyse (E70), on analyse un champ contenant un niveau de confidentialité requis pour le message reçu. 6. Procédé de traitement selon la revendication 5, dans lequel l'étape de désactivation du masquage (E80) comprend l'insertion dans ce champ d'une valeur reflétant un niveau de confidentialité nul. 7. Procédé de traitement selon la revendication 1 dans lequel : le premier coeur de réseau (CN1) IP multimédia et le second coeur de réseau (CN2) IP multimédia mettent en oeuvre le protocole SIP ; le message (M') de découverte des capacités et/ou d'un état du second dispositif est un message SIP OPTIONS ; et - ledit au moins un champ analysé au cours de l'étape d'analyse est un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS. 8. Procédé de traitement selon la revendication 7, dans lequel : au cours de l'étape d'analyse (E50), on détecte qu'un masquage est activé pour le second dispositif si le champ FROM du message SIP OPTIONS contient un identifiant dit anonyme préservant l'anonymat du premier dispositif ; et au cours de l'étape de désactivation du masquage (E60), on remplace l'identifiant anonyme par un identifiant contenu dans un champ SIP P-Asserted-Identity du message SIP OPTIONS. 9. Procédé de traitement selon la revendication 7, dans lequel : au cours de l'étape d'analyse (E70), on détecte qu'un masquage est activé pour le second dispositif si le champ SIP PRIVACY du message SIP OPTIONS contient un niveau de confidentialité positionné à une valeur différente de la valeur « none » ; et au cours de l'étape de désactivation du masquage (E80), on remplace ladite valeur du niveau de confidentialité du champ SIP PRIVACY par la valeur « none ». 10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de traitement selon la revendication 1 ledit programme est exécuté par un ordinateur. 11. Entité de traitement (6) apte à traiter un message (M') reçu en relation avec un message (M) émis par un premier dispositif (T1) enregistré auprès d'un premier coeur de réseau (CN1) IP multimédia, à destination d'un second dispositif (T2) associé à un second coeur de réseau (CN2) IP multimédia, cette entité (6) étant une entité du second coeur de réseau IP multimédia comprenant : - des moyens de vérification (6A) pour vérifier si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif ; des moyens d'analyse (6A), déclenchés le cas échéant, pour analyser au moins un champ du message reçu afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ; des moyens de désactivation (6A), déclenchés si un masquage est détecté, pour désactiver ce masquage dans ledit au moins un champ du message reçu avant de le transmettre vers lesecond dispositif de sorte qu'un identifiant du premier dispositif soit disponible dans le message transmis pour le second dispositif ; et des moyens de transmission (6D) du message dans lequel le masquage a été désactivé vers le second dispositif. 12. Entité de traitement selon la revendication 11 intégrée dans un serveur d'application (8) de terminaison d'appel du second coeur de réseau (CN2) ou dans un dispositif (6) situé en aval d'un serveur d'application (8) de terminaison d'appel du second coeur de réseau. 13. Entité de traitement selon la revendication 12 intégrée, lorsque le second coeur de réseau (CN2) IP multimédia implémente une architecture IMS, dans un dispositif quelconque du second coeur de réseau IP multimédia parmi : un serveur S-CSCF (6) ; un serveur P-CSCF (7) ; ou - un contrôleur de session SBC. 14. Entité de traitement selon la revendication 12 intégrée, lorsque le second coeur de réseau IP multimédia implémente une architecture mettant en oeuvre le protocole SIP, dans un serveur proxy SIP. 15. Entité de traitement (6) selon la revendication 11 dans laquelle, lorsque le premier coeur de réseau IP multimédia et le second coeur de réseau IP multimédia mettent en oeuvre le protocole SIP : les moyens de vérification sont aptes à vérifier si le message reçu est un message SIP OPTIONS ; et - les moyens d'analyse sont aptes à analyser un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS. 16. Coeur de réseau (CN2) IP multimédia comprenant une entité de traitement (6) selon la revendication 11.