FR2989548A1

FR2989548A1 - METHOD OF PROCESSING A MESSAGE, ENTITY AND HEART OF NETWORK

Info

Publication number: FR2989548A1
Application number: FR1253529A
Authority: FR
Inventors: Bertrand Bouvet
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2012-04-17
Filing date: 2012-04-17
Publication date: 2013-10-18
Also published as: WO2013156727A1

Abstract

Le procédé de traitement selon l'invention 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, est mis en oeuvre par une entité (6) du second coeur de réseau et comprend : - si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif, l'analyse d'au moins un champ de ce message afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ; - le cas échéant, la désactivation du masquage dans ledit au moins un champ du message, avant de le transmettre vers le second dispositif de sorte qu'un identifiant du premier dispositif est disponible dans le message transmis pour le second dispositif.The method of processing according to the invention of a received message (M ') in relation with a message (M) transmitted by a first device (T1) registered with a first network core (CN1) IP multimedia destined to a second device (T2) associated with a second network core (CN2) IP multimedia, is implemented by an entity (6) of the second core network and comprises: - if the received message is a message of discovery of the capabilities and / or a state of the second device, analyzing at least one field of this message to detect whether a masking of an identifier of the first device is enabled for the second device; where appropriate, deactivating the masking in said at least one field of the message, before transmitting it to the second device so that an identifier of the first device is available in the message transmitted for the second device.

Description

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. BACKGROUND OF THE INVENTION The invention relates to the general field of telecommunications and multimedia Internet Protocol (IP) network architectures, such as network architectures using in particular the technology designated by "voice over IP" (or VoIP for Voice over IP). It relates more particularly to the processing, by a so-called processing entity, of a message received in connection with a message sent by a first device registered with a first core IP multimedia network, to a second device associated with a second multimedia IP core network, as part of a multimedia communication service based on a mechanism for self-discovery of the capabilities and / or the state of the remote (ie here, the second device). Such a self-discovery mechanism comprises, in a manner known per se, the sending of a specific message to a remote device inviting it to declare, in response to this message, its capabilities, that is to say the services it supports, and / or its state, the remote device being required to respond to this 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. Thus, within the meaning of the invention, a message of discovery of the capabilities and / or the state of the remote designates a message sent by a device to a remote device, inviting it to declare, in response to this message, its capabilities. , that is, the services it supports, and / or its state. Furthermore, a message received by a processing entity "in relation to a message sent by a first device" designates, within the meaning of the invention, a message identical or similar to the message sent by the first device to the additions and deletions of fields and / or headers made by the elements of the network or networks via which this message has passed between the first device and the processing entity of the second core network. The first core network and the second network core can be operated by the same operator or by separate operators.

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. The invention thus has a preferred but non-limiting application in the context of multimedia IP network cores implementing the Session Initiation Protocol (SIP) multimedia session initiation protocol, defined by the Internet Engineering Task Force (IETF) standard and described in particular in RFC 3261 entitled "SIP: Session Initiation Protocol", June 2002, published by the IETF. The invention applies in particular to the multimedia IP network core based on an IP Multimedia Subsystem (IMS) as proposed by the 3GPP standard (Third Generation Partnership Project). However, it can also be used in combination with other architectures of multimedia IP network cores, such as for example proprietary architectures, whether or not implementing the SIP protocol for establishing multimedia sessions (voice, text, video). , data, etc.). In a known manner, the SIP signaling protocol relies on a certain number of SIP methods or messages, such as, for example, the SIP REGISTER, INVITE, SUBSCRIBE, NOTIFY or OPTIONS methods. Among these methods, the SIP OPTIONS method allows a so-called sender device, such as for example a terminal, to know the capabilities (ie services supported, resources available, etc.) and / or the state (eg existing, non-existent , registered, free, busy, etc.) of another "remote" device said receiver, this receiving device can be for example a terminal or a SIP server (eg a proxy server). A SIP OPTIONS message is therefore a message of discovery of the capabilities and / or the state of the remote within the meaning of the invention. This type of message is advantageously used today in many multimedia communication services offered by telecommunications operators to improve their service offerings as well as the experience felt by the users of these services, for example in services. instant messaging (IM), or in so-called Rich Communication Services (enhanced-RCS) services as described in the document entitled "RCS-e Advanced Communications: Services and Client Specification", version 1.1, April 8, 2011. In accordance with the SIP standard, any device receiving a SIP OPTIONS message is required to respond to it.

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. It should be noted that receipt of a SIP OPTIONS message is unbeknownst to the user of the receiving device, ie, it is not signaled specifically to that user (no ringing of the receiving device or notification receiving the SIP OPTIONS message). The SIP standard now offers the possibility to any device issuing a SIP OPTIONS message to discreetly discover the state and / or the capabilities of a receiving device, without the user of this receiving device being informed of the implementation of this discovery mechanism. To guard against the abuses that may result from such a mode of operation, it is possible to envisage the implementation of protection mechanisms at the level of the receiving devices. Such a protection mechanism may for example consist in providing, at the level of the receiving device, the establishment and maintenance of a traceability file listing the various SIP OPTIONS messages received by the receiving device without the knowledge of its user. , and identifying the sending devices causing these SIP OPTIONS messages. This traceability file could be consulted, if necessary, by the user of the receiving device, and guarantee the user of the receiving device a certain transparency as to the messages received without his knowledge. It is therefore clear that the effectiveness of such a protection mechanism depends closely on the presence of an identifier of the transmitting device in the SIP OPTIONS message received by the receiving device. However, this identifier can, for various reasons, not be present in the SIP OPTIONS message received by the receiving device. For example, the sending device may have masked its identity by activating the Originating Identity Restriction (OIR) service provided for voice over IP network cores by the 3GPP standard (Third Generation Partnership Project), or the user the receiving device may not have subscribed or activated the service of presenting the identity of the transmitting device offered by the 3GPP standard, also known as Originating Identity Presentation (OIP) service. The operation of the OIP and OIR services is defined in detail in 3GPP TS24.607 entitled "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. This document notably provides that, once activated or deactivated, these OIR and OIP services for masking the identity of the sending device apply de facto to all the SIP messages transmitted by the sending device and / or received by the receiving device.

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. It should be noted that most of today's telecommunications networks rely on decoupling of telephone calls and multimedia communication services, which are managed via a circuit-switched network (CS) for telephone calls respectively. and via a packet-switched network (PS for Packet Switch) based on a multimedia IP core network architecture for data services. In such a context, the users who activate the identifier masking services for their telephone calls via the OIP and OIR services or equivalent services defined for the CS networks (eg CLIP services (Calling Line Identification Presentation) or CLIR services ( Calling Line Identification Restriction)), master the effects of this masking to the extent that it is limited to their phone calls.

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. However, when telecommunications networks will soon migrate to "all-IP" networks, the activation of such an identifier masking service will have an impact on all the services subscribed by the user, ie that is to say both on his telephone calls and on the multimedia data services to which he has subscribed, since in accordance with the recommendations of the document 3GPP TS 24.607, the masking of the identifier will apply equally to all SIP messages sent and / or received. Consequently, the implementation of these masking services of the identifier of the transmitting device on the multimedia IP network core may result in a degradation of certain services offered by the operators (such as, for example, the protection mechanism cited above). previously), and therefore a fortiori, by a degradation of the experience felt by the users of these services. OBJECT AND SUMMARY OF THE INVENTION The object of the invention is in particular to remedy the aforementioned drawbacks by proposing a method of processing a received message, in relation with a message sent by a first device registered with a first IP multimedia core network. to a second device associated with a second core of multimedia IP network, this processing method being implemented by an entity of the second multimedia IP core network and comprising: if the message received is a message of discovery of the capabilities and or a state of the second device, a step of analyzing at least one field of this received message in order to detect whether a masking of an identifier of the first device is activated for the second device; and if necessary, a step of deactivating the masking in said at least one field of the received message, before transmitting it to the second device so that an identifier of the first device is available in the message transmitted for the second device. Correlatively, the invention also relates to a processing entity adapted to process a message received in relation to a message sent by a first device registered with a first core IP multimedia network, to a second device associated with a second multimedia IP core network, this entity being an entity of the second multimedia IP core network comprising: verification means for verifying whether the received message is a capability discovery message and / or a state of the second device; analysis means, triggered if necessary, for analyzing at least one field of the received message in order to detect whether a masking of an identifier of the first device is activated for the second device; deactivation means, triggered if masking is detected, for disabling this masking in said at least one field of the received message before transmitting it to the second device, so that an identifier of the first device is available in the message transmitted for the second device; and means for transmitting the message in which the masking has been disabled to the second device. The invention thus proposes to detect, at the level of an entity of the network core of the receiver device, a message of discovery of the capabilities and / or the state of the remote (second device within the meaning of the invention), if a masking of the identifier of the device transmitting this message (first device within the meaning of the invention) is activated for the receiving device, and if necessary, to disable this masking so that an identifier of the transmitting device is available in the message of discovery of the capabilities and / or the state of the remote, received by the receiving device.

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). Thus, a degradation of the services using an identifier of the device issuing the discovery message is avoided, since according to the invention, an identifier of the transmitting device is always provided to the receiving device in the discovery message. The invention thus guarantees, when the receiver device implements a protection mechanism such as that described above, that an identifier of the sending devices at the origin of the discovery messages received by the receiving device, is always included in the traceability file. listing the discovery messages received by the receiving device. The invention therefore makes it possible to guarantee complete transparency to the user of the receiving device and perfect traceability of discovery messages received without his knowledge, such as the SIP OPTIONS messages for SIP multimedia IP network cores. Advantageously, the invention applies in a targeted manner to the messages of discovery of the capabilities and / or the state of the remote, and not to all the messages intended for the second device. The invention is not intended to completely disable the masking of the identifier of the first device desired by the user of this first device (for example by activating the service OIR) or by that of the second device (for example by not subscribing not to the OIP service). On the contrary, it makes it possible to ensure transparency for the user of the second device only with respect to messages received without the latter's knowledge and to which the second device is required to respond, due to constraints imposed by the standard. The provision of this identifier is therefore performed, in accordance with the invention, only exceptionally in the context of the transmission of a message of discovery of the capabilities and / or the state of the remote. Furthermore, the invention is implemented in the core network of the second device, receiver of the discovery message. This advantageously makes it possible to counter the different cases of masking of the identifier of the first device that can be set up in the first and / or second core IP multimedia network, namely: - a masking of the identifier by the first device, for example via the insertion of an anonymous or invalid identifier into a field of the discovery message; masking by an entity of the first core network, or else - masking by an entity of the second core network such as the call termination application server. For this purpose, the processing entity according to the invention may be integrated in the call termination application server (also known as the "terminating application server") of the second multimedia IP core network, or preferentially in a device located downstream of this call termination application server. The invention thus makes it possible to provide an identifier of the first device to the second device, including when the masking of the identifier is implemented by the call termination application server (for example, in the case of deactivation or non-activation). -subscription to the OIP service).

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). The integration of the processing entity into a device downstream of the call termination application server rather than the call termination application server furthermore makes it possible to optimize the performance of the second call center. network: it does not indeed require the triggering of the call termination application server on receipt of the discovery message, such a trigger can prove to be expensive in terms of resources (the performance of certain entities of the core network, for example, Serving Call State Control Function (S-CSCF) servers for an IMS core network architecture, in fact decrease in a known manner when multiple application servers are triggered).

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. For a second core of multimedia IP network implementing an IMS architecture implementing the SIP multimedia session initiation protocol, the processing entity can notably be integrated into any device of the second core IP multimedia network among: a server S -CSCF; a P-CSCF server (Proxy-Cali State Control Function); or Session Border Controler (SBC). In a variant, when the second multimedia IP core implements an architecture implementing the SIP protocol but different from an IMS architecture, the processing entity according to the invention is integrated in a SIP proxy server of the second IP core network. multimedia. Thus, the invention applies in a privileged but nonlimiting manner when: the first multimedia IP core network and the second multimedia IP core network implement the SIP protocol; the message discovering the capabilities and / or a state of the second device is a SIP OPTIONS message; and said at least one field analyzed during the analysis step is a FROM field or a SIP PRIVACY field of the SIP OPTIONS message. Correlatively, when the first multimedia IP core network and the second multimedia IP core network implement the SIP protocol: the verification means of the processing entity according to the invention are able to verify whether the message received is a message SIP OPTIONS; and the analysis means of the processing entity according to the invention are able to analyze a FROM field or a SIP PRIVACY field of the SIP OPTIONS message.

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. In a particular embodiment of the invention, the processing method further comprises a determination step, conditioning the implementation of the analysis and deactivation steps, during which it is determined whether the received message is in relation with a message sent by the first device in the context of an autonomous exchange between the first device and the second device.

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. In other words, in this embodiment, the masking of the identifier of the first device is deactivated only if the message of discovery of the capabilities and / or the state of the remote is sent as part of an autonomous transaction or transaction. "Standalone" between the first device and the second device, that is to say, that is not performed in the context of a dialogue established between the first device and the second device or that does not initiate such a device 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. The invention has indeed an additional advantage in such a context, because the second device does not have other means to access an identifier of the first device and similarly, the first device does not have other means of access to the capabilities and / or the state of the second device that the sending of a discovery message (they can not refer to a dialogue already established between the two devices or consult other applications already having these information). Note however that when a dialogue is already established between the two devices, it means firstly that the second device has accepted a communication of the first device despite the masking of its identifier, and secondly that state of the second device is busy. As mentioned above, the masking of an identifier of the first device for the second device can be activated at different levels of the network, and can be translated into different fields of the message of discovery of the capabilities and / or the state of the remote received by the device. processing entity of the second core network. The invention provides different embodiments to consider these different scenarios. Thus, according to a first variant embodiment, during the analysis step, a field of the received message intended to contain an identifier of the first device provided by the first device is analyzed. The deactivation step may then include inserting, in the field intended to contain an identifier of the first device provided by the first device, an identifier of the first device certified by an element of the first multimedia IP core network and contained in the message received. In a manner known per se, such a certified identifier is systematically inserted by the core of the network of the first device (first core network within the meaning of the invention) in the messages managed by it, in particular for the purposes of procedures implemented. by the first core network which require the presence of such a certified identifier, or when these messages are transferred to the core of the network of the second device, to allow for example the billing of the service in which this message is exchanged. This certified identifier is usually deleted by the second core network before delivering the message to the second device. In contrast, according to the first embodiment of the invention, this certified identifier is used to provide the second device with an identifier of the first device in the discovery message, when the field of the discovery message intended to contain an identifier of the first device. device does not contain an identifier of the first device or equivalently contains an anonymous or invalid identifier. According to one aspect of this first embodiment, when the first multimedia IP core network and the second multimedia IP core network implement the SIP protocol and the capability discovery message and / or a state of the second device is a SIP OPTIONS message during the analysis step, it is detected that a masking is activated for the second device if the FROM field of the SIP OPTIONS message contains an anonymous identifier preserving the anonymity of the first device or a non-identifying identifier. valid first device; and during the disabling step of masking, replacing the anonymous identifier with an identifier contained in a SIP P-Asserted-Identity field of the SIP OPTIONS message. In a second variant embodiment of the invention, during the analysis step, a field containing a level of confidentiality required for the received message is analyzed.

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é. Such a field is for example the SIP PRIVACY field of the SIP OPTIONS message as defined in the document RFC 3323 published by the IETF entitled "A privacy mechanism for the Session Initiation Protocol (SIP)", November 2002. This field may take different values, namely the values "none", "header" (the first device wishes to hide the identity present in the "FROM" field of the SIP OPTIONS message), or "id" (the first device wishes hide the identity certified by the network present in the SIP P-Asserted-Identity field of the SIP OPTIONS message). This value is set by the first network core or the second network core (eg via a web application or portal), depending on how the masking of the identifier of the first device is activated.

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. In the current state of the art, when this value is representative of a masking of the identifier of the first device for the second device, in other words when it is equal to a value different from the value "none", the identifier of the first device present in the discovery message is removed from this discovery message before it is transferred to the second device.

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 ». On the contrary, in the second embodiment of the invention, the step of deactivating the masking comprises the positioning in this field of a value reflecting a zero level of confidentiality, so that an identifier of the first device is available in the discovery message received by the second device. Thus, as an example for a SIP OPTIONS message - during the analysis step, it is detected that a masking is enabled for the second device if the SIP PRIVACY field of the SIP OPTIONS message contains a set confidentiality level. at a value different from the value "none"; and - during the step of deactivating the masking, the value of the confidentiality level of the SIP PRIVACY field is replaced by the value "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. In a particular embodiment, the various steps of the processing method are determined by instructions of computer programs. Consequently, the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a processing entity according to the invention or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a treatment method as described above.

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. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape. The invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a diskette (floppy disc) or a disk hard.

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. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention can be downloaded in particular on an Internet type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. The invention also relates to a multimedia IP core network comprising a processing entity according to the invention. It may also be envisaged, in other embodiments, that the processing method, the entity and the core network according to the invention present in combination all or part of the aforementioned characteristics. BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate an embodiment having no limiting character. In the figures: FIG. 1 represents, schematically, a telecommunications environment including a processing entity according to the invention, in a particular embodiment; Figure 2 schematically shows the hardware architecture of the processing entity shown in Figure 1; and FIG. 3 represents, in the form of a flow chart, the main steps of a processing method according to the invention, when they are implemented by the processing entity of FIG. 1, in a particular embodiment. .

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. DETAILED DESCRIPTION OF THE EMBODIMENT FIG. 1 represents a telecommunications environment including a processing entity according to the invention, in a particular embodiment.

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. In the example described here, the processing by this entity of a received message M 'in relation with a message M of the discovery of the capabilities and / or the state of the remote transmitted by a first device T1 destined for a second device T2, in the context of a multimedia communication service, such as for example the RCS-e service.

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. It is assumed that a protection mechanism as described above is set up at the level of the device T2, so that on reception of a message of discovery of the capabilities and / or the state of the remote, it remembers, in a traceability file, various information related to this message, such as in particular an identifier of the device T1 at the origin of the message M, the time (eg time and day) at which this message was received, 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. However, it should be noted that no limitation is attached to the actual protection mechanism implemented by the device T2 from the identifier of the device T1 at the origin of the message M. The invention applies also, of course, when other protection mechanisms or even other types of mechanisms using an identifier of the device T1 at the origin of the message M are implemented at the device 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. According to the invention, it is ensured that an identifier of the device T1 at the origin of the message M is always available in the message reaching the device T2, including when a masking of the identifier of the device T1 is activated. by the device T1 or by an element of the telecommunications network or networks participating in the routing of the message to the device 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). The T1 and T2 devices are here terminals, managed by (or associated with) separate multimedia IP network cores, CN1 and CN2 respectively. The CN1 and CN2 network cores are here network cores using the "voice over IP" technology, and implement an IMS architecture, as defined in particular in the document 3GPP TS 22.228 "Service requirements for the IP Multimedia Core Network Subsystem (Internship 1) ", and implementing the SIP session initiation protocol. These hypotheses are however not limiting, and the invention also applies when the CN1 and CN2 network cores form only one multimedia IP core network, as well as to other types of devices (for example T2 may be a proxy server), other IP multimedia core network architectures, and other session initiation protocols, such as for example proprietary network core architectures using the SIP protocol or another proprietary session initiation protocol providing a message to discover the capabilities and / or the state of the remote. In a manner known per se, the IMS CN1 core network comprises several functional entities. Thus, in the embodiment described here, it comprises in particular: a CSCF entity (Cali Session Control Function), itself composed of several equipment or logical servers including: o a P-CSCF 1 server (Proxy Call Session Control Function) point of contact of the terminal T1 with the core network CN1; o an S-CSCF 2 server (Serving Call Session Control Function) in charge of the T1 terminal recording on the CN1 core network and the triggering of the application servers; and o an I-CSCF 3 server (Interrogating Call Session Control Function), in charge of the interrogation of a HSS database (Home Subscriber Server, not shown in FIG. 1) and the routing of messages for the initialization of connections to the CN1 core network; and one or more Application Servers that host and provide services, such as a 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. Similarly, the IMS CN2 core network comprises several functional entities, including in particular here: a CSCF entity composed of several equipment or logical servers including: o an I-CSCF 5 server; o an S-CSCF server 6; o a P-CSCF 7 server; and one or more Application Servers that host and provide services, such as a Terminating Application Server (8). In the embodiment envisaged here, the S-CSCF server 6 integrates the functionalities of a processing entity according to the invention (ie the S-CSCF server 6 is a processing entity according to the invention), and has the hardware architecture of a computer shown schematically in FIG. 2. The server S-CSCF 6 notably comprises a processor 6A, a random access memory 6B, a read-only memory 6C, and 6D communication means with, in particular, the CN1 and CN2 network core entities and the T2 terminal, these 6D communication means implementing the SIP protocol. The read-only memory 6C of the S-CSCF server 6 constitutes a recording medium in accordance with the invention, readable by the processor 6A and on which is recorded a computer program according to the invention, comprising instructions for execution. steps of a method of processing according to the invention described later with reference to FIG. 3. Thus, in accordance with the invention, the S-CSCF server 6 is able to process a message received in connection with a message of discovery of capabilities and / or the state of the remote issued by the terminal T1 to the terminal T2, to ensure that an identifier of the terminal T1 is provided to the terminal T2 in the discovery message reaching it. It is thus ensured that the terminal T2 can enter, in the traceability file, the identifier of the terminal T1 transmitting the capacity discovery message and / or the state of the terminal T2. Various causes may be at the origin of a masking of the identifier of the terminal T1 in the discovery message received by the server S-CSCF 6 and destined for the terminal T2. Thus, this masking can be because of the terminal T1 itself (via the insertion of an anonymous identifier in the message for example), or of an element of the network core CN1 (for example following the activation of a CLIR or OIR service by the user of the terminal T1), or of a CN2 core network element (for example following the non-subscription or deactivation of a CLIP or OIP service by the user of the terminal T2). It should be noted that in the embodiment described here in which the multimedia IP network cores CN1 and CN2 implement the SIP protocol, a masking of the identifier of the terminal T1 for the terminal T2 can be translated at the level of two. SIP OPTIONS discovery message fields, namely: at the level of the FROM field reflecting the origin of the message, and / or at the PRIVACY field reflecting the level of confidentiality required for the SIP OPTIONS message. Furthermore, it should also be noted that, in a manner known per se, in the current state of the art, to allow the message sent by the terminal T1 to be conveyed to the terminal T2, the message M 'received by the S-CSCF server 6 always contains a valid identifier of the terminal T1, whether a masking has been activated or not by the terminal T1 or by the core network CN1. This identifier can be provided by the terminal T1 and present in the FROM field of the SIP OPTIONS message, and / or provided by an entity of the CN1 core network in the form of a certified identifier present in the P-Asserted-Identity field of the SIP OPTIONS message. If a masking is activated at the core network CN1 or at the core network CN2, this identifier will then be removed from the message by a CN2 heart network before it is provided to the terminal T2. We will now describe with reference to FIG. 3, the main steps of a processing method according to the invention implemented by the S-CSCF server 6 for processing the received message M 'in relation with the message M transmitted by the terminal T1 to the terminal T2, in a particular embodiment. In the example envisaged here, it is assumed that the message M sent by the terminal T1 to the terminal T2 is a SIP message OPTIONS for discovering the capabilities and / or the state of the remote, namely here the terminal T2, issued as part of the RCS-e multimedia communications service. T1 and T2 are assumed here registered with their respective network cores CN1 and CN2. The message M passes, in a manner known per se, by the elements of the network core CN1, then by the elements of the core network CN2 to the server S-CSCF 6. It is received in the form of a received message M ' by the server S-CSCF 6 (step E10). The message M 'received by the server S-CSCF 6 is a message received in relation with the message M within the meaning of the invention, that is to say that it is identical or similar to the message M sent by the terminal T1 to the additions and deletions of fields and / or headers, carried out by the elements of the network or networks through which this message has passed between the terminal T1 and the S-CSCF server 6. Thus, for example, the core network CN1 may have modified the PRIVACY field of the message M sent by the terminal Ti so as to activate a masking of the identifier of the terminal T1 for the terminal T2. Similarly, a core network element CN1 may have inserted into the message M a certified identifier of the terminal Ti. The message M 'is therefore also a SIP OPTIONS message containing the same field FROM as the message M and whose PRIVACY field has possibly been modified by the core network CN1. The message M 'also contains a certified identifier of the terminal T1 inserted by an element of the core network CN1 in the P-Asserted-Identity field.

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). Upon receipt of the message M ', the server S-CSCF 6 determines at first whether it is a message of discovery capabilities and / or a state of the remote, ie a SIP OPTIONS message (test step E20). If the message M 'is not a SIP OPTIONS message (non-response to the test E20), the S-CSCF server 6 transmits it without additional processing other than the processing conventionally provided by an S-CSCF server to the terminal T2 (step E30). If the message M 'is a SIP OPTIONS message (answer yes to the test E20), the server S-CSCF 6 determines here in a second time whether this message M' is in relation with a message sent as part of an exchange or an autonomous transaction between terminals T1 and T2 (test step 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. For this purpose, the S-CSCF server 6 identifies whether the message M 'contains an identifier of a SIP dialogue established between T1 and T2 formed, in a manner known per se, by the fields (FromTag, ToTag, CaIIID). In the embodiment described here, a differentiated treatment of the SIP OPTIONS messages exchanged as part of a stand-alone transaction and in the context of an established SIP dialogue is envisaged: only the SIP OPTIONS messages exchanged in the context of a transaction In this embodiment, according to the invention, the SCSCF server 6 processes the stand-alone mode. Thus, if the message M 'contains an established SIP dialogue identifier (non-test response E40), the S-CSCF server 6 transmits it without additional processing other than the treatments conventionally provided by an S-CSCF server to the terminal T2 (step E30). If the S-CSCF server 6 determines that the message M 'is in relation with a message M exchanged as part of a stand-alone transaction between T1 and T2, that is, if the message M' does not contain a dialogue identifier (yes answer to the test E40), the server S-CSCF 6 then analyzes at least one field of this message in order to detect if a mask of an identifier of the terminal T1 is activated for the terminal T2. In the embodiment described here, the S-CSCF server 6 analyzes the SIP fields FROM and PRIVACY of the SIP OPTIONS message to detect whether a mask of the identifier of the terminal T1 is activated for the 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 ». Specifically, the S-CSCF server 6 first analyzes the FROM field of the SIP OPTIONS message. This field FROM, in a manner known per se, is intended to contain an identifier of the terminal T1 supplied by it during the transmission of the message M. In order to detect if a masking is activated, the S-CSCF server 6 examines, during this analysis step, if the FROM field contains an anonymous identifier (test step E50). By anonymous identifier here means an identifier provided by the terminal T1 and intended to preserve the anonymity of the terminal T1. Examples of such an anonymous identifier are described in the document RFC 3323 cited above: these identifiers contain the string " anonymous ». For example: "sip: a0017@anonymous-sip.com" or "sip: anonymous@anonymous.invalid" are anonymous identifiers that can be inserted in the FROM field by the terminal Ti if it wants to hide its identifier at terminal T2. Thus, in the embodiment described here, to detect whether the FROM field contains an anonymous identifier, the S-CSCF server 6 searches, during the analysis step, whether the content of the FROM field comprises the string of characters. "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é. Alternatively, other character strings may be searched for different configurations of the terminal that can be used to preserve its anonymity. If the FROM field does not contain an anonymous identifier (answer not to the E50 test) but an identifier having a valid format with regard to the formats of identifiers conventionally used to identify a device according to the SIP protocol (eg sip: + 33296053859 @ operator.multimedia.fr), the S-CSCF server 6 leaves the field FROM unchanged and goes to the analysis step of the SIP PRIVACY field of the SIP OPTIONS message. If, on the other hand, the S-CSCF server 6 detects that the FROM field contains an anonymous identifier (answer yes to the test E50), it deactivates the masking of the identifier of the terminal T1 by inserting, instead of the anonymous identifier, an identifier of the terminal T1 certified by a CN1 core network entity (step E60). As previously mentioned, this certified identifier is included in the message M 'and contained in the SIP P-Asserted-Identity field of the SIP OPTIONS message. It has been inserted, by a CN1 core network entity during the transit of the message M via the network core CN1. In an alternative embodiment, during the analysis step, the S-CSCF server 6 also examines whether the FROM field contains an invalid identifier, that is to say, an identifier which by its form, looks like an identifier of the terminal T1 (typically this identifier does not contain the string "anonymous"), but which is not consistent with the real identity of the terminal T1. The S-CSCF server 6 can detect the presence of such an invalid identifier by comparing, for example, the certified identifier of the terminal T1 present in the SIP P-Asserted-Identity field of the SIP OPTIONS message and the identifier of the terminal T1 present. in the FROM field. Indeed, in a manner known per se, these identifiers are supposed to be identical at least on their first 5 or 6 digits. An identifier present in the FROM field that has its first 5 digits different from those of the certified identifier specified in the SIP P-Asserted-Identity field of the SIP OPTIONS message would then be considered invalid by the S-CSCF 6 server. the S-CSCF server 6 detects that the FROM field contains such an invalid identifier, it replaces this identifier with the certified identifier present in the SIP P-Asserted-Identity field of the SIP OPTIONS message. Thus, at the end of step E60, an identifier of the terminal T1 is present in the field FROM of the message processed by the server S-CSCF 6: it is either the (valid) identifier provided by the terminal T1, or a certified identifier provided by a core CN1 element. The S-CSCF server 6 then examines the SIP PRIVACY field of the SIP OPTIONS M 'message in order to detect whether a masking of the identifier of the terminal Ti is activated for the terminal T2 via this field (test step E70). Such masking is reflected in the SIP PRIVACY field by a value of the field distinct from the value "none" (the value "none" according to the SIP protocol reflects a zero level of confidentiality). If the SIP PRIVACY field is not set to the value "none" (yes answer to the E70 test), but for example to the value "header" or "id", the S-CSCF server 6 deactivates the masking of the T1 terminal identifier for the T2 terminal by inserting instead of this value, the value "none" in the PRIVACY field (step E80). If the SIP PRIVACY field is instead already set to "none" (response not to the E70 test), the S-CSCF server 6 leaves it unchanged.

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). M "denotes the message obtained at the end of step E80, which contains the fields FROM and PRIVACY possibly modified by the server S-CSCF 6 to disable the masking of the identifier of the terminal Ti. -CSCF 6 then transmits the message M "to the terminal T2 (step E90). The modifications of the fields FROM and / or PRIVACY according to the invention thus make it possible to disable the masking of the identifier of the terminal T1 for the terminal T2 so that an identifier of the terminal T1 is available for the second terminal T2 in the field FROM SIP message OPTIONS reaching it. This identifier is either the identifier provided by the terminal T1 itself, or an identifier certified by the core network CN1. On receipt of the message SIP OPTIONS M "(or of a message derived from the message M" as a function of the elements of the network core CN2 traversed by the message M "to the terminal T2), the terminal T2 has an identifier of the terminal Tl in the FROM field of the SIP OPTIONS message, it can then fill in the traceability file listing the various SIP OPTIONS messages received by the terminal T2 by including in this file the time at which the SIP OPTIONS message from the terminal T1 has been received. and the identifier of the terminal T1 included in the field FROM.In the embodiment described in detail here, the multimedia IP network cores CN1 and CN2 are distinct network cores.In a variant, the invention also applies when the terminals T1 and T2 are managed by the same core network, in which case the processing entity is integrated in the server S-CSCF managing the terminal T2 In the embodiment described here, the processing entity nt according to the invention is integrated in the server S-CSCF 6 CN2 heart of destination of the message M. The S-CSCF server 6 is placed in the network core CN2, in a manner known per se, downstream of the server call termination application. This advantageous position of the processing entity according to the invention in the S-CSCF server 6 thus makes it possible to deal with different scenarios that may arise: the SIP OPTION messages are exchanged between the terminals T 1 and T 2 by borrowing the cores IMS network CN1 and CN2 but do not pass through the application servers implementing the CLIR / OIR and CLIP / OIP services (ie by the application servers 4 and 8); the SIP OPTIONS messages are exchanged between the terminals T1 and T2 by borrowing the IMS network CN1 and CN2 cores and pass through the application servers 4 and 8 respectively implementing the CLIR / OIR and CLIP / OIP services; the SIP OPTIONS messages are exchanged between the terminals T1 and T2 by borrowing the IMS network CN1 and CN2 cores, pass through the application server 4 implementing the CLIR / OIR services but do not pass through the application server 8 implementing CLIP / OIP services (eg such a case may arise if CN1 and CN2 network cores are managed by different operators); or - the SIP OPTIONS messages are exchanged between the terminals Ti and T2 by borrowing the IMS network CN1 and CN2 cores, do not pass through the application server 4 implementing the CLIR / OIR services but pass through the server of application 8 implementing the CLIP / OIP services (eg such a case may arise if CN1 and CN2 network cores are managed by different operators).

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. This embodiment also has another advantage when a plurality of terminals T2 bear the same public identity or IP Multimedia Public Identity (IMPU), which is to require the application of the processing according to the invention only on a single message M '. The 3GPP standard provides for the possibility for a plurality of terminals to share the same public identity IMPU, in which case a replication function (or "forking" in English) messages for the public identity IMPU is implemented at S-CSCF level so that each terminal associated with the public identity IMPU receives a replica of these messages. The integration of the functionalities of the processing entity according to the invention at the level of the S-CSCF 6 makes it possible to apply the processing to disable the masking of the identifier of the terminal T1 before the forking function: the forking function is then applied to the message M "containing the identifier of the terminal T1, in order to optimize the resources In another embodiment, the message processing entity M 'according to the invention can be integrated into another device or another element of the network core CN2, preferably located downstream of the call termination application server, for example in the P-CSCF server 7 or in an SBC session controller of the core network CN2 (not shown in FIG. However, it should be noted that in this embodiment, if several terminals T2 share the same public identity IMPU, the forking function is implemented in the server S-CSCF 6 upstream of the process. nt according to the invention, it should be applied to each replica SIP OPTIONS message associated with each terminal T2. Each replica constitutes a message in relation to a discovery message sent by the terminal T1 within the meaning of the invention. In yet another embodiment, the message processing entity M 'according to the invention can be integrated in the application server 8 of call termination, by setting up a server triggering criterion. 8 on receiving an SIP OPTIONS discovery message (or a SIP OPTIONS message as part of a standalone transaction). In another embodiment, the core network CN2 implements a different architecture of an IMS architecture. The processing entity according to the invention is then integrated into an arbitrary SIP proxy server CN2 network core. In these various embodiments of the invention in which the processing entity is integrated either in the P-CSCF server 7 or in the application server 8, or in an SBC session control or in a SIP proxy server , the processing carried out on the message M 'according to the invention proceeds identically to that described with reference to FIG. 3 when the processing entity is integrated in the server S-CSCF 6.

Claims

REVENDICATIONS1. Method for processing a received message (M '), in relation with a message (M) sent by a first device (T1) registered with a first multimedia network core (CN1) to a second device (T2) associated with a second network core (CN2) multimedia IP, said processing method being implemented by an entity (6) of the second core IP multimedia network and comprising: - if the received message is a discovery message capabilities and / or a state of the second device (E20), a step of analyzing (E50, E70) at least one field of this received message to detect whether a masking of an identifier of the first device is activated for the second device; and where appropriate, a step of deactivating (E60, E80) said masking in said at least one field of said received message, before transmitting it (E90) to the second device (T2) so that an identifier of the first device is available in the message transmitted for the second device.

2. Treatment method according to claim 1 further comprising a determination step (E40), conditioning the implementation of the analysis steps (E50, E70) and deactivation steps (E60, E80), during which one determines whether the received message is related to a message sent by the first device in the context of an autonomous exchange between the first device and the second device.

3. Processing method according to claim 1 wherein, during the analysis step (E50), a field of the received message is analyzed to contain an identifier of the first device provided by the first device.

4. Processing method according to claim 3 wherein the deactivation step (E60) comprises inserting, in a field intended to contain an identifier of the first device provided by the first device, an identifier of the first device certified by an entity of the first multimedia IP core network and contained in the received message.

The processing method according to claim 1, wherein during the analyzing step (E70), a field containing a level of confidentiality required for the received message is analyzed.

The method of processing of claim 5, wherein the step of disabling the masking (E80) includes inserting in this field a value reflecting a zero level of confidentiality.

7. Processing method according to claim 1 wherein: the first network core (CN1) multimedia IP and the second network core (CN2) multimedia IP implement the SIP protocol; the message (M ') for discovering the capabilities and / or a state of the second device is a SIP OPTIONS message; and said at least one field analyzed during the analysis step is a FROM field or a SIP PRIVACY field of the SIP OPTIONS message.

8. Processing method according to claim 7, wherein: during the analysis step (E50), it is detected that a masking is activated for the second device if the FROM field of the SIP OPTIONS message contains an identifier said anonymously preserving the anonymity of the first device; and during the masking deactivation step (E60), the anonymous identifier is replaced by an identifier contained in a SIP P-Asserted-Identity field of the SIP OPTIONS message.

The processing method according to claim 7, wherein: during the analyzing step (E70), it is detected that a masking is activated for the second device if the SIP PRIVACY field of the SIP OPTIONS message contains a level confidentiality set to a value other than the value "none"; and during the step of disabling the masking (E80), replacing said value of the confidentiality level of the SIP PRIVACY field with the value "none".

A computer program comprising instructions for performing the steps of the processing method according to claim 1, said program being executed by a computer.

11. Processing entity (6) able to process a message (M ') received in connection with a message (M) sent by a first device (T1) registered with a first network core (CN1) multimedia IP, to destination of a second device (T2) associated with a second network core (CN2) multimedia IP, this entity (6) being an entity of the second multimedia IP core network comprising: - verification means (6A) for checking whether the received message is a capacity discovery message and / or a state of the second device; analysis means (6A), triggered if necessary, for analyzing at least one field of the received message in order to detect whether a masking of an identifier of the first device is activated for the second device; deactivation means (6A), triggered if masking is detected, to disable this masking in said at least one field of the received message before transmitting it to the second device so that an identifier of the first device is available in the transmitted message for the second device; and transmission means (6D) of the message in which the masking has been disabled to the second device.

12. Processing entity according to claim 11 integrated in a call termination application (8) server of the second core network (CN2) or in a device (6) located downstream of an application server ( 8) call termination of the second core network.

13. Processing entity according to claim 12 integrated, when the second network core (CN2) multimedia IP implements an IMS architecture, in any device of the second multimedia IP core network among: an S-CSCF server (6); a P-CSCF server (7); or - an SBC session controller.

14. Processing entity according to claim 12 integrated, when the second multimedia IP core network implements an architecture implementing the SIP protocol, in a SIP proxy server.

15. Processing entity (6) according to claim 11 wherein, when the first multimedia IP core network and the second multimedia IP core network implement the SIP protocol: the verification means are able to verify if the received message is a SIP OPTIONS message; and the analysis means are able to analyze a FROM field or a SIP PRIVACY field of the SIP OPTIONS message.

16. Network core (CN2) multimedia IP comprising a processing entity (6) according to claim 11.