WO2013156727A1 - Procede de traitement d'un message, entite et cœur de reseau - Google Patents

Procede de traitement d'un message, entite et cœur de reseau Download PDF

Info

Publication number
WO2013156727A1
WO2013156727A1 PCT/FR2013/050830 FR2013050830W WO2013156727A1 WO 2013156727 A1 WO2013156727 A1 WO 2013156727A1 FR 2013050830 W FR2013050830 W FR 2013050830W WO 2013156727 A1 WO2013156727 A1 WO 2013156727A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
identifier
multimedia
sip
field
Prior art date
Application number
PCT/FR2013/050830
Other languages
English (en)
Inventor
Bertrand Bouvet
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2013156727A1 publication Critical patent/WO2013156727A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • 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).
  • IP Internet Protocol
  • It relates more particularly to the processing, by a so-called processing entity, of a message received in relation to a message sent by a first device registered with a first multimedia IP core network, to a second device associated with a second core IP multimedia network, in the context of a multimedia communication service based on a mechanism for self-discovery capabilities and / or the state of the remote (ie here, the second device).
  • 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.
  • 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.
  • 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 stubbornly carried out 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 may be operated by the same operator or by separate operators.
  • the invention thus has a preferred but nonlimiting application in the context of multimedia IP core networks 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.
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • the invention applies in particular to multimedia IP network cores based on an IP Multimedia Subsystem (IMS) as proposed by the 3GPP standard (Third Generation Partnership Project).
  • IMS IP Multimedia Subsystem
  • multimedia IP core network architectures such as for example proprietary architectures, implementing or not the SIP protocol for establishing multimedia sessions (voice, text, video). , data, etc.).
  • the SIP signaling protocol relies on a certain number of methods or SIP messages, such as, for example, the SIP REGISTER, INVITE methods, SUBSCRIBE, NOTIFY or OPTIONS.
  • 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
  • enhanced-RCS Rich Communication Services
  • any receiving device of a SIP OPTIONS message is required to respond to it.
  • SIP OPTIONS 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.
  • 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.
  • this identifier can, for various reasons, not be present in the message
  • the sending device may have masked its identity by activating the Originating Identity Restriction (OIR) service provided for voice over IP backbones by the 3GPP standard (Third Generation Partnership Project), or still, the user of the receiving device may not have subscribed or activated the presentation service of the identity of the transmitting device offered by the 3GPP standard, also known as Originating Identity Presentation (OIP) service.
  • OIR Originating Identity Restriction
  • 3GPP Third Generation Partnership Project
  • OIP Originating Identity Presentation
  • OIP and OIR services are defined in detail in 3GPP TS24.607 entitled "Technical Specification Group Core Network and Terminals; Originating Identification Overview (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.
  • these masking services of the identifier of the transmitting device on the multimedia IP core network 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.
  • the invention aims 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 multimedia IP core network to a second device associated with a second core IP multimedia network, this processing method being implemented by an entity of the second IP multimedia core network and comprising: If the message received is a message discovering the capabilities and / or a state of the second device, a step of analyzing at least one field of this message received in order to detect whether a masking of an identifier of the first device is enabled for the second device; and
  • 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.
  • the invention also relates to a processing entity adapted to process a received message 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 capacity discovery message and / or a state of the second device
  • Analysis means 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 a 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
  • 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 in the sense 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.
  • 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 total transparency to the user of the receiving device and perfect traceability of discovery messages received without his knowledge, such as SIP OPTIONS messages for SIP multimedia IP backbones.
  • 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).
  • the invention is implemented in the network core of the second device, receiver of the discovery message. This advantageously makes it possible to counter the various cases of masking of the identifier of the first device that can be implemented in the first and / or second core of multimedia IP 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;
  • a masking by an entity of the first core network or else
  • the processing entity according to the invention can 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).
  • the integration of the processing entity in a device downstream of the call termination application server rather than in the call termination application server furthermore makes it possible to optimize the performance of the second call center.
  • network it does not actually 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 a core network IMS architecture, are indeed decreasing in a known manner when multiple application servers are triggered).
  • S-CSCF Serving Call State Control Function
  • the processing entity can notably be integrated into any device of the second multimedia IP core network from:
  • a P-CSCF server (Proxy-Call State Control Function); or
  • SBC Session Session Controller
  • the processing entity according to the invention is integrated in a SIP proxy server of the second IP core network. multimedia.
  • 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.
  • Said at least one field analyzed during the analysis step is a FROM field or a SIP PRIVACY field of the SIP OPTIONS message.
  • the verification means of the processing entity according to the invention are able to check whether the received message is a SIP OPTIONS message
  • 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.
  • 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.
  • 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.
  • 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 state of the second device than sending a discovery message (they can not refer to a dialogue already established between the two devices or consult other applications already having this information).
  • 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. second network core processing entity.
  • the invention provides different embodiments to consider these different scenarios.
  • 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 can 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.
  • 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 that 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.
  • 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.
  • 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:
  • 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 an invalid identifier of the first device; device; and During the step of deactivating the masking, the anonymous identifier is replaced by an identifier contained in a SIP P-Asserted-Identity field of the SIP OPTIONS message.
  • a field containing a level of confidentiality required for the received message is analyzed.
  • 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.
  • 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.
  • 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.
  • the value of the confidentiality level of the SIP PRIVACY field is replaced by the value "none".
  • the various steps of the processing method are determined by instructions of computer programs.
  • 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.
  • 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.
  • 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 floppy disk or a disk. hard.
  • 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.
  • 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 provides a multimedia IP core network comprising a processing entity according to the invention.
  • processing method, the entity and the core network according to the invention present in combination all or part of the aforementioned characteristics.
  • FIG. 1 shows, schematically, a telecommunications environment including a processing entity according to the invention, in a particular embodiment
  • FIG. 2 shows schematically the hardware architecture of the processing entity shown in Figure 1;
  • 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. .
  • 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. .
  • FIG. 1 represents a telecommunications environment including a processing entity according to the invention, in a particular embodiment.
  • a multimedia communication service such as for example the RCS-e service.
  • 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 relating 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.
  • 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.
  • the devices T1 and T2 are here terminals, managed by (or associated with) separate multimedia IP network cores, CN1 and CN2 respectively.
  • the CN1 and CN2 network cores are network cores using "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.
  • the invention also applies when the network cores CN1 and CN2 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 core network 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.
  • T2 may be a proxy server
  • other IP multimedia core network architectures such as for example proprietary core network 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.
  • the IMS CN1 network core comprises several functional entities.
  • it comprises in particular:
  • a CSCF entity (Call Session Control Function), itself composed of several equipment or logical servers including:
  • a P-CSCF server 1 Provides a Call Session Control Function
  • a S-CSCF server 2 Server Call Session Control Function in charge of the Tl terminal registration on the CN1 core network and the triggering of the application servers
  • I-CSCF 3 server Interrogating Call Session Control Function
  • HSS database Home Subscriber Server, not shown in FIG. 1
  • routing of messages for the initialization of connections to CN1 core network and
  • One or more Application Servers hosting and providing services such as a Originating Application Server.
  • the IMS CN2 core network comprises several functional entities, including in particular here:
  • a CSCF entity composed of several equipment or logical servers, including:
  • One or more Application Servers hosting and providing services such as a Terminating Application Server.
  • 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 hardware architecture of a computer shown schematically in Figure 2.
  • the server S-CSCF 6 comprises in particular 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 terminal T2, these means of 6D communication 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 treatment method according to the invention described later with reference to FIG.
  • the S-CSCF server 6 is able to process a message received in connection with a message of discovery of the capabilities and / or the state of the remote transmitted by the terminal T1 to the terminal T2, to guarantee that an identifier of the terminal T1 is supplied to the terminal T2 in the discovery message reaching it. This ensures that the terminal T2 can enter, in the traceability file, the identifier of the terminal Tl 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. So, this masking can be because of the terminal T1 itself (via the insertion of an anonymous identifier in the message for example), or a core network CNl element (for example following the activation of a CLIR or OIR service by the user of the terminal T1), or else 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 ).
  • 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 network core CN1.
  • This identifier can be provided by the terminal T1 and present in the field FROM of the SIP OPTIONS message, and / or provided by a core network entity CN1 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 CN2 network core, this identifier will then be removed from the message by a CN2 heart network before it is provided to the terminal T2.
  • 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 core network 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 Tl to the additions and deletions of fields and / or stubborn elements of the network or networks via which this message has passed between the terminal T1 and the S-CSCF server 6.
  • the network core CN1 may have modified the PRIVACY field of the message M transmitted by the terminal T1 so as to activate a masking of the identifier of the terminal T1 for the terminal T2.
  • a core network element CN1 may have inserted into the message M a certified identifier of the terminal T1.
  • 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 field P-Asserted-Identity.
  • the server S-CSCF 6 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).
  • 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).
  • 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 the terminals T1 and T2 (test step E40).
  • 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, CallID).
  • 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 are embodied in this embodiment according to the invention by the S-CSCF server 6.
  • the S-CSCF server 6 transmits it without additional processing other than the processes conventionally provided by an S-CSCF server to the terminal T2 (step E30).
  • the server S-CSCF 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 masking of an identifier of the terminal T1 is activated for the terminal T2.
  • the S-CSCF server 6 analyzes the SIP fields FROM and PRIVACY of the SIP OPTIONS message to detect whether a masking of the identifier of the terminal T1 is activated for the terminal T2. 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 provided by the latter during the transmission of the message M.
  • the S-CSCF server 6 examines, during this analysis step, whether the FROM field contains an anonymous identifier (test step E50).
  • anonymous identifier here means an identifier provided by the terminal T1 and intended to preserve the anonymity of the terminal T1. Examples of such anonymous identifier are described in the document RFC 3323 cited above: these identifiers contain the character string " anonymous Colour For example: "sip: a0017@anonymous-sip.com” or "sip: anonymous@anonymous.invalid" are anonymous identifiers that can be inserted into the FROM field by the Tl terminal if it wants to hide its identifier at terminal T2.
  • the S-CSCF server 6 searches, during the analysis step, whether the content of the FROM field comprises the string of characters. "Anonymous".
  • the S-CSCF server 6 leaves the FROM field unchanged and goes to the SIP PRIVACY field analysis step of the SIP OPTIONS message.
  • the S-CSCF server 6 detects that the FROM field contains an anonymous identifier (answer yes to the test E50), it disables the masking of the identifier of the terminal Tl by inserting, instead of the anonymous identifier, an identifier of the terminal T1 certified by a CN1 core network entity (step E60).
  • 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 core network CN1.
  • 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 a terminal identifier Tl (typically this identifier does not contain the string "anonymous"), but is not consistent with the actual identity of the terminal Tl.
  • the S-CSCF server 6 can detect the presence of such an invalid identifier by comparing, for example, the certified identifier of the terminal Tl 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 would have its first 5 digits different from 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 If 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.
  • 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 CN1 core network 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 T1 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).
  • the S-CSCF server 6 deactivates the masking of the Tl terminal identifier for the T2 terminal by inserting instead of this value, the value "none" in the PRIVACY field (step E80).
  • the S-CSCF server 6 leaves it unchanged.
  • step E80 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 T1.
  • the S-CSCF server 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.
  • the terminal T2 On receipt of the message SIP OPTIONS M "(or a message derived from the message M" depending on the elements of the network core CN2 traversed by the message M "to the terminal T2), the terminal T2 has an identifier of the Tl terminal in the FROM field of the SIP OPTIONS message.
  • the multimedia IP network cores CN1 and CN2 are separate network cores.
  • 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.
  • the processing entity according to the invention is integrated in the S-CSCF server 6 of the network core CN2 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 call termination application server. This advantageous position of the processing entity according to the invention in the S-CSCF server 6 thus makes it possible to cope with different situations that may occur:
  • the SIP OPTIONS messages are exchanged between the terminals T1 and T2 by borrowing the IMS CNl and CN2 network cores but do not pass through the application servers implementing the CLIR / OIR and CLIP / OIP services (ie by the servers application 4 and 8);
  • the SIP OPTIONS messages are exchanged between the terminals T1 and T2 by taking the IMS network cores CN1 and CN2 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 cores CN1 and CN2, 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 CNl and CN2 network cores are managed by different operators); or
  • the SIP OPTIONS messages are exchanged between the terminals T1 and T2 by borrowing the IMS network cores CN1 and CN2, do not transit through the application server 4 implementing the CLIR / OIR services but pass through the application server 8 implementing CLIP / OIP services (eg such a case may arise if CNl and CN2 network cores are managed by different operators).
  • 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 '.
  • IMPU IP Multimedia Public Identity
  • 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.
  • a replication function or "forking" in English
  • 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.
  • the message processing entity M 'according to the invention can be integrated into another device or another element of the core network CN2, preferably located downstream of the termination application server. call, as per example in the P-CSCF server 7 or in an SBC session controller CN2 core network (not shown in Figure 1).
  • each replica constitutes a message in relation to a discovery message sent by the terminal T1 in the sense of the invention.
  • 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).
  • the network core CN2 implements an architecture different from an IMS architecture.
  • the processing entity according to the invention is then integrated in any SIP proxy server CN2 core network.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Le procédé de traitement selon l'invention d'un message reçu (M1) en relation avec un message (M) émis par un premier dispositif (T1) enregistré auprès d'un premier cœur de réseau (CN1) IP multimédia à destination d'un second dispositif (T2) associé à un second cœur de réseau (CN2) IP multimédia, est mis en œuvre par une entité (6) du second cœur 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.

Description

Procédé de traitement d'un message, entité et cœur de réseau
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 cœur de réseau IP multimédia, à destination d'un second dispositif associé à un second cœur de réseau IP multimédia, dans le cadre d'un service de communication multimédia s'appuyant sur un mécanisme d'auto-découverte des capacités et/ou de l'état du distant (autrement dit ici, du second dispositif). Un tel mécanisme d'auto-découverte comprend, de façon connue en soi, l'envoi d'un message spécifique à un dispositif distant l'invitant à déclarer, en réponse à ce message, ses capacités, c'est-à-dire les services qu'il supporte, et/ou son état, le dispositif distant étant tenu de répondre à ce message.
Ainsi, au sens de l'invention, un message de découverte des capacités et/ou de l'état du distant désigne un message envoyé par un dispositif à un dispositif distant, l'invitant à déclarer, en réponse à ce message, ses capacités, c'est-à-dire les services qu'il supporte, et/ou son état.
Par ailleurs, un message reçu par une entité de traitement « en relation avec un message émis par un premier dispositif » désigne, au sens de l'invention, un message identique ou similaire au message émis par le premier dispositif aux ajouts et suppressions de champs et/ou d'entêtés 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 cœur de réseau.
Le premier cœur de réseau et le second cœur de réseau peuvent être opérés par le même opérateur ou par des opérateurs distincts.
L'invention a ainsi une application privilégiée mais non limitative dans le contexte de cœurs de réseau IP multimédia mettant en œuvre 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 cœurs de réseau IP multimédia s'appuyant sur une architecture IMS (IP Multimedia Subsystem) telle que proposée par le standard 3GPP (Third Génération Partnership Project).
Toutefois, elle peut également être utilisée en association avec d'autres architectures de cœurs de réseau IP multimédia, telles que par exemple des architectures propriétaires, mettant en œuvre ou non le protocole SIP pour l'établissement de sessions multimédia (voix, texte, vidéo, données, etc.).
De façon connue, le protocole de signalisation SIP s'appuie sur un certain nombre de méthodes ou messages SIP, telles que par exemple les méthodes SIP REGISTER, INVITE, SUBSCRIBE, NOTIFY ou OPTIONS. Parmi ces méthodes, la méthode SIP OPTIONS permet à un dispositif dit émetteur, tel que par exemple un terminal, de connaître les capacités (i.e. services supportés, ressources disponibles, etc.) et/ou l'état (ex. existant, non existant, enregistré, libre, occupé, etc.) d'un autre dispositif « distant » dit récepteur, ce dispositif récepteur pouvant être par exemple un terminal ou un serveur SIP (ex. un serveur proxy). Un message SIP OPTIONS est donc un message de découverte des capacités et/ou de l'état du distant au sens de l'invention.
Ce type de message est avantageusement mis à profit aujourd'hui dans de nombreux services de communication multimédia proposés par les opérateurs de télécommunications pour améliorer leurs offres de service ainsi que l'expérience ressentie par les utilisateurs de ces services, comme par exemple dans des services de messagerie instantanée (IM pour Instant Messaging en anglais), ou dans des services dits RCS-e (Rich Communication Services - enhanced) tels que décrits dans le document intitulé « RCS-e Advanced Communications: Services and client spécification », version 1.1, Avril 8, 2011.
Conformément à la norme SIP, tout dispositif récepteur d'un message SIP OPTIONS est tenu d'y répondre.
Il convient de noter que la réception d'un message SIP OPTIONS se fait à l'insu de l'utilisateur du dispositif récepteur, autrement dit, elle n'est pas signalée spécifiquement à cet utilisateur (pas de sonnerie du dispositif récepteur ou de notification de la réception du message SIP OPTIONS). La norme SIP offre donc aujourd'hui la possibilité à tout dispositif émetteur d'un message SIP OPTIONS de découvrir en toute discrétion l'état et/ou les capacités d'un dispositif récepteur, sans que l'utilisateur de ce dispositif récepteur ne soit informé de la mise en oeuvre de ce mécanisme de découverte.
Pour se prémunir des abus pouvant résulter d'un tel mode de fonctionnement, on peut envisager la mise en oeuvre de mécanismes de protection au niveau des dispositifs récepteurs.
Un tel mécanisme de protection peut consister par exemple à prévoir, au niveau du dispositif récepteur, l'établissement et le maintien à jour d'un fichier de traçabilité recensant les différents messages SIP OPTIONS reçus par le dispositif récepteur à l'insu de son utilisateur, et identifiant les dispositifs émetteurs à l'origine de ces messages SIP OPTIONS. Ce fichier de traçabilité pourrait être consulté, en cas de besoin, par l'utilisateur du dispositif récepteur, et garantirait à l'utilisateur du dispositif récepteur une certaine transparence quant aux messages reçus à son insu.
On comprend bien dès lors, que l'efficacité d'un tel mécanisme de protection dépend étroitement de la présence d'un identifiant du dispositif émetteur dans le message SIP OPTIONS reçu par le dispositif récepteur.
Or, cet identifiant peut, pour diverses raisons, ne pas être présent dans le message
SIP OPTIONS reçu par le dispositif récepteur. Ainsi par exemple, le dispositif émetteur peut avoir masqué son identité en activant le service OIR (Originating Identity Restriction) prévu pour les cœurs de réseau de voix sur IP par le standard 3GPP (Third Génération 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 Présentation).
Le fonctionnement des services OIP et OIR est défini en détails dans le document 3GPP TS24.607 intitulé « Technical Spécification Group Core Network and Terminais; Originating Identification Présentation (OIP) and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Spécification », Release 10. Ce document prévoit notamment qu'une fois activés ou désactivés, ces services OIR et OIP de masquage de l'identité du dispositif émetteur s'appliquent de facto à tous les messages SIP émis par le dispositif émetteur et/ou reçus par le dispositif récepteur.
Il convient de noter que la plupart des réseaux de télécommunications actuels s'appuient sur un découplage des appels téléphoniques et des services de communication multimédia, qui sont gérés respectivement via un réseau à commutation de circuit (CS pour Circuit Switch) pour les appels téléphoniques, et via un réseau à commutation de paquets (PS pour Packet Switch) s'appuyant sur une architecture de cœur 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 Présentation) ou CLIR (Calling Line Identification Restriction)), maîtrisent les effets de ce masquage dans la mesure où celui-ci se limite à leurs appels téléphoniques.
Toutefois, lorsque les réseaux de télécommunications migreront prochainement vers des réseaux « tout IP », l'activation d'un tel service de masquage de l'identifiant aura des impacts sur l'ensemble des services souscrits par l'utilisateur, c'est-à-dire à la fois sur ses appels téléphoniques et sur les services de données multimédia auxquels il a souscrits, puisque conformément aux recommandations du document 3GPP TS 24.607, le masquage de l'identifiant s'appliquera indifféremment à tous les messages SIP émis et/ou reçus.
Par conséquent, la mise en oeuvre de ces services de masquage de l'identifiant du dispositif émetteur sur les cœurs 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 cœur de réseau IP multimédia à destination d'un second dispositif associé à un second cœur de réseau IP multimédia, ce procédé de traitement étant mis en œuvre par une entité du second cœur 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 cœur de réseau IP multimédia, à destination d'un second dispositif associé à un second cœur de réseau IP multimédia, cette entité étant une entité du second cœur 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 cœur de réseau du dispositif récepteur d'un message de découverte des capacités et/ou de l'état du distant (second dispositif au sens de l'invention), si un masquage de l'identifiant du dispositif émetteur de ce message (premier dispositif au sens de l'invention) est activé pour le dispositif récepteur, et le cas échéant, de désactiver ce masquage de sorte qu'un identifiant du dispositif émetteur soit disponible dans le message de découverte des capacités et/ou de l'état du distant, reçu par le dispositif récepteur.
On évite ainsi une dégradation des services utilisant un identifiant du dispositif émetteur du message de découverte, puisque conformément à l'invention, un identifiant du dispositif émetteur est toujours fourni au dispositif récepteur dans le message de découverte.
L'invention garantit donc, lorsque le dispositif récepteur implémente un mécanisme de protection tel que celui décrit précédemment, qu'un identifiant des dispositifs émetteurs à l'origine des messages de découverte reçus par le dispositif récepteur, soit toujours inclus dans le fichier de traçabilité recensant les messages de découverte reçus par le dispositif récepteur. L'invention permet par conséquent de garantir une totale transparence à l'utilisateur du dispositif récepteur et une parfaite traçabilité des messages de découverte reçus à son insu, tels que les messages SIP OPTIONS pour les cœurs 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 cœur 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 cœurs 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 cœur de réseau, ou encore,
— un masquage par une entité du second cœur 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 cœur 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 œuvre par le serveur d'application de terminaison d'appel (par exemple, en cas de désactivation ou de non-souscription au service OIP).
L'intégration de l'entité de traitement dans un dispositif situé en aval du serveur d'application de terminaison d'appel plutôt que dans le serveur d'application de terminaison d'appel permet en outre d'optimiser les performances du second cœur 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 cœur de réseau, comme par exemple des serveurs S-CSCF (Serving Call State Control Function) pour une architecture IMS de cœur de réseau, diminuent en effet de façon connue lorsque l'on déclenche de multiples serveurs d'application). Pour un second cœur de réseau IP multimédia implémentant une architecture IMS mettant en œuvre 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 cœur de réseau IP multimédia parmi :
— un serveur S-CSCF ;
— un serveur P-CSCF (Proxy-Call State Control Function) ; ou
— un contrôleur de session SBC (Session Border Contrôler).
En variante, lorsque le second cœur de réseau IP multimédia implémente une architecture mettant en œuvre 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 cœur de réseau IP multimédia.
Ainsi, l'invention s'applique de façon privilégiée mais non limitative lorsque :
— le premier cœur de réseau IP multimédia et le second cœur de réseau IP multimédia mettent en œuvre 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 cœur de réseau IP multimédia et le second cœur de réseau IP multimédia mettent en œuvre le protocole SIP :
— les moyens de vérification de l'entité de traitement selon l'invention sont aptes à vérifier si le message reçu est un message SIP OPTIONS ; et
— les moyens d'analyse de l'entité de traitement selon l'invention sont aptes à analyser un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS.
Dans un mode particulier de réalisation de l'invention, le procédé de traitement comprend en outre une étape de détermination, conditionnant la mise en œuvre des étapes d'analyse et de désactivation, au cours de laquelle on détermine si le message reçu est en relation avec un message émis par le premier dispositif dans le cadre d'un échange autonome entre le premier dispositif et le second dispositif.
Autrement dit, dans ce mode de réalisation, on ne désactive le masquage de l'identifiant du premier dispositif que si le message de découverte des capacités et/ou de l'état du distant est émis dans le cadre d'une transaction autonome ou transaction « standalone » entre le premier dispositif et le second dispositif, c'est-à-dire, qui n'est pas réalisée dans le cadre d'un dialogue établi entre le premier dispositif et le second dispositif ou qui n'initie pas un tel dialogue.
L'invention présente en effet un avantage supplémentaire dans un tel contexte, car le second dispositif ne dispose pas d'autres moyens d'accéder à un identifiant du premier dispositif et de façon similaire, le premier dispositif ne dispose pas d'autres moyens d'accéder aux capacités et/ou à l'état du second dispositif que l'envoi d'un message de découverte (ils ne peuvent pas se référer à un dialogue déjà établi entre les deux dispositifs ou consulter d'autres applications disposant déjà de ces informations).
On notera en revanche que lorsqu'un dialogue est déjà établi entre les deux dispositifs, cela signifie d'une part que le second dispositif a accepté une communication du premier dispositif en dépit du masquage de son identifiant, et d'autre part, que l'état du second dispositif est occupé.
Comme mentionné précédemment, le masquage d'un identifiant du premier dispositif pour le second dispositif peut être activé à différents niveaux du réseau, et se traduire dans différents champs du message de découverte des capacités et/ou de l'état du distant reçu par l'entité de traitement du second cœur 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 cœur 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 cœur du réseau du premier dispositif (premier cœur 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 œuvre par le premier cœur de réseau qui nécessitent la présence d'un tel identifiant certifié, ou lorsque ces messages sont transférés vers le cœur 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 cœur 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 cœur de réseau IP multimédia et le second cœur de réseau IP multimédia mettent en œuvre le protocole SIP et le message de découverte des capacités et/ou d'un état du second dispositif est un message SIP OPTIONS :
— au cours de l'étape d'analyse, on détecte qu'un masquage est activé pour le second dispositif si le champ FROM du message SIP OPTIONS contient un identifiant dit anonyme préservant l'anonymat du premier dispositif ou un identifiant non valide du premier dispositif ; et — au cours de l'étape de désactivation du masquage, on remplace l'identifiant anonyme par un identifiant contenu dans un champ SIP P-Asserted-Identity du message SIP OPTIONS.
Dans une seconde variante de réalisation de l'invention, au cours de l'étape d'analyse, on analyse un champ contenant un niveau de confidentialité requis pour le message reçu.
Un tel champ est par exemple le champ SIP PRIVACY du message SIP OPTIONS tel que défini dans le document RFC 3323 édité par l'IETF et intitulé « A privacy mechanism for the Session Initiation Protocol (SIP) », Novembre 2002. Ce champ peut prendre différentes valeurs, à savoir les valeurs « none » (pas de confidentialité), « header » (le premier dispositif souhaite masquer l'identité présente dans le champ « FROM » du message SIP OPTIONS), ou « id » (le premier dispositif souhaite masquer l'identité certifiée par le réseau présente dans le champ SIP P- Asserted-Identity du message SIP OPTIONS).
Cette valeur est fixée par le premier cœur de réseau ou par le second cœur de réseau (ex. via une application web ou un portail), en fonction de la façon dont le masquage de l'identifiant du premier dispositif est activé.
Dans l'état actuel de la technique, lorsque cette valeur est représentative d'un masquage de l'identifiant du premier dispositif pour le second dispositif, autrement dit lorsqu'elle est égale à une valeur différente de la valeur « none », l'identifiant du premier dispositif présent dans le message de découverte est supprimé de ce message de découverte avant son transfert vers le second dispositif.
Au contraire, dans la seconde variante de réalisation de l'invention, l'étape de désactivation du masquage comprend le positionnement dans ce champ d'une valeur reflétant un niveau de confidentialité nul, de sorte qu'un identifiant du premier dispositif est disponible dans le message de découverte reçu par le second dispositif.
Ainsi, à titre d'exemple pour un message SIP OPTIONS :
— au cours de l'étape d'analyse, on détecte qu'un masquage est activé pour le second dispositif si le champ SIP PRIVACY du message SIP OPTIONS contient un niveau de confidentialité positionné à une valeur différente de la valeur « none » ; et
— au cours de l'étape de désactivation du masquage, on remplace la valeur du niveau de confidentialité du champ SIP PRIVACY par la valeur « none ».
Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre 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 œuvre des étapes d'un procédé de traitement tel que décrit ci- dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise également un cœur 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 cœur 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 œuvre par l'entité de traitement de la figure 1, dans un mode particulier de réalisation. Description détaillée d'un mode de réalisation
La figure 1 représente un environnement de télécommunications incluant une entité de traitement selon l'invention, dans un mode particulier de réalisation. Dans l'exemple décrit ici, on envisage le traitement par cette entité d'un message reçu M' en relation avec un message M de découverte des capacités et/ou de l'état du distant émis par un premier dispositif Tl à destination d'un second dispositif T2, dans le cadre d'un service de communication multimédia, tel que par exemple le service RCS-e.
On suppose qu'un mécanisme de protection tel que décrit précédemment est mis en place au niveau du dispositif T2, de sorte que sur réception d'un message de découverte des capacités et/ou de l'état du distant, celui-ci mémorise, dans un fichier de traçabilité, différentes informations en relation avec ce message, telles que notamment un identifiant du dispositif Tl à l'origine du message M, le moment (ex. heure et jour) auquel ce message a été reçu, etc.
II 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 Tl à 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 Tl à l'origine du message M sont mis en oeuvre au niveau du dispositif T2.
Conformément à l'invention, on s'assure qu'un identifiant du dispositif Tl à 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 Tl ou par un élément du ou des réseaux de télécommunications participant à l'acheminement du message jusqu'au dispositif T2.
Les dispositifs Tl et T2 sont ici des terminaux, gérés par (ou associés à) des cœurs de réseau IP multimédia distincts, CN1 et CN2 respectivement. Les cœurs de réseau CN1 et CN2 sont ici des cœurs 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 œuvre le protocole d'initiation de session SIP.
Ces hypothèses ne sont toutefois pas limitatives, et l'invention s'applique également lorsque les cœurs de réseau CN1 et CN2 ne forment qu'un seul cœur 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 cœur de réseau IP multimédia, et à d'autres protocoles d'initiation de session, tels que par exemple à des architectures de cœurs 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 cœur 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 (Call 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 Tl avec le cœur de réseau CN1 ; o un serveur S-CSCF 2 (Serving Call Session Control Function) en charge de l'enregistrement du terminal Tl sur le cœur 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 cœur de réseau CN1 ; et
— un ou plusieurs serveurs d'applications (Application Servers) hébergeant et fournissant des services, tels qu'un serveur d'application 4 d'initiation d'appel (Originating Application Server).
De façon similaire, le cœur 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 cœurs de réseau CN1 et CN2 et le terminal T2, ces moyens de communication 6D mettant en œuvre 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 Tl à destination du terminal T2, pour garantir qu'un identifiant du terminal Tl 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 Tl é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 Tl 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 Tl lui-même (via l'insertion d'un identifiant anonyme dans le message par exemple), ou d'un élément du cœur de réseau CNl (par exemple suite à l'activation d'un service CLIR ou OIR par l'utilisateur du terminal Tl), ou encore d'un élément du cœur 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 cœurs de réseau IP multimédia CNl et CN2 mettent en œuvre le protocole SIP, un masquage de l'identifiant du terminal Tl 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 Tl jusqu'au terminal T2, le message M' reçu par le serveur S-CSCF 6 contient toujours un identifiant valide du terminal Tl, qu'un masquage ait été activé ou non par le terminal Tl ou par le cœur de réseau CNl. Cet identifiant peut être fourni par le terminal Tl et présent dans le champ FROM du message SIP OPTIONS, et/ou fourni par une entité du cœur de réseau CNl 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 cœur de réseau CNl ou au niveau du cœur de réseau CN2, cet identifiant sera alors supprimé du message par un élément du cœur 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 œuvre par le serveur S-CSCF 6 pour le traitement du message reçu M' en relation avec le message M émis par le terminal Tl à 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 Tl à 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.
Tl et T2 sont supposés ici enregistrés auprès de leurs cœurs de réseau respectifs CNl et CN2.
Le message M transite, de façon connue en soi par les éléments du cœur de réseau CNl, puis par les éléments du cœur 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 Tl aux ajouts et suppressions de champs et/ou d'entêtés près, effectués par les éléments du ou des réseaux via lesquels a transité ce message entre le terminal Tl et le serveur S- CSCF 6. Ainsi, par exemple, le cœur de réseau CN1 peut avoir modifié le champ PRIVACY du message M émis par le terminal Tl de sorte à activer un masquage de l'identifiant du terminal Tl pour le terminal T2. De même, un élément du cœur de réseau CN1 peut avoir inséré dans le message M un identifiant certifié du terminal Tl.
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 cœur de réseau CN1. Le message M' contient par ailleurs un identifiant certifié du terminal Tl inséré par un élément du cœur de réseau CN1 dans le champ P-Asserted-Identity.
Sur réception du message M', le serveur S-CSCF 6 détermine dans un premier temps s'il s'agit d'un message de découverte des capacités et/ou d'un état du distant, autrement dit d'un message SIP OPTIONS (étape test E20).
Si le message M' n'est pas un message SIP OPTIONS (réponse non au test E20), le serveur S-CSCF 6 le transmet sans traitement supplémentaire autre que les traitements prévus classiquement par un serveur S-CSCF vers le terminal T2 (étape E30).
Si le message M' est un message SIP OPTIONS (réponse oui au test E20), le serveur S- CSCF 6 détermine ici dans un second temps si ce message M' est en relation avec un message émis dans le cadre d'un échange ou d'une transaction autonome entre les terminaux Tl et T2 (étape test E40).
A cette fin, le serveur S-CSCF 6 identifie si le message M' contient un identifiant d'un dialogue SIP établi entre Tl et T2 formé, de façon connue en soi, par les champs (FromTag, ToTag, CallID).
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 S- CSCF 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 Tl 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 Tl est activé pour le terminal T2. Plus précisément, le serveur S-CSCF 6 analyse tout d'abord le champ FROM du message SIP OPTIONS. Ce champ FROM, de façon connue en soi, est destiné à contenir un identifiant du terminal Tl 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 Tl 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 Tl si celui-ci désire masquer son identifiant au terminal T2.
Ainsi, dans le mode de réalisation décrit ici, pour détecter si le champ FROM contient un identifiant anonyme, le serveur S-CSCF 6 recherche, au cours de l'étape d'analyse, si le contenu du champ FROM comprend la chaîne de caractères « anonymous ».
En variante, d'autres chaînes de caractères peuvent être recherchées pour parer à des configurations différentes du terminal pouvant être utilisées pour préserver son anonymat.
Si le champ FROM ne contient pas d'identifiant anonyme (réponse non au test E50) mais un identifiant ayant un format valide au regard des formats d'identifiants classiquement utilisés pour identifier un dispositif conformément au protocole SIP (ex. sip : -i-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 Tl en insérant, à la place de l'identifiant anonyme, un identifiant du terminal Tl certifié par une entité du cœur 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 cœur de réseau CN1 lors du transit du message M via le cœur 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 Tl (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 Tl.
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 Tl présent dans le champ SIP P-Asserted- Identity du message SIP OPTIONS et l'identifiant du terminal Tl 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 Tl 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 Tl, soit d'un identifiant certifié fourni par un élément du cœur 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 Tl 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 Tl pour le terminal T2 en insérant à la place de cette valeur, la valeur « none » dans le champ PRIVACY (étape E80).
Si le champ SIP PRIVACY est au contraire déjà positionné à la valeur « none » (réponse non au test E70), le serveur S-CSCF 6 le laisse inchangé.
On désigne par M" le message obtenu à l'issue de l'étape E80, et qui contient les champs FROM et PRIVACY éventuellement modifiés par le serveur S-CSCF 6 pour désactiver le masquage de l'identifiant du terminal Tl.
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 Tl 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 Tl lui-même, soit un identifiant certifié par le cœur 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 cœur 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 Tl a été reçu et l'identifiant du terminal Tl compris dans le champ FROM.
Dans le mode de réalisation décrit en détail ici, les cœurs de réseau IP multimédia CN1 et CN2 sont des cœurs de réseau distincts. En variante, l'invention s'applique également lorsque les terminaux Tl et T2 sont gérés par le même cœur 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 cœur de réseau CN2 de destination du message M. Le serveur S-CSCF 6 est placé dans le cœur 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 Tl et T2 en empruntant les cœurs de réseau IMS CNl et CN2 mais ne transitent pas par les serveurs d'application mettant en œuvre 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 Tl et T2 en empruntant les cœurs de réseau IMS CNl et CN2 et transitent par les serveurs d'application 4 et 8 mettant en œuvre respectivement les services CLIR/OIR et CLIP/OIP ;
— les messages SIP OPTIONS sont échangés entre les terminaux Tl et T2 en empruntant les cœurs de réseau IMS CNl et CN2, transitent par le serveur d'application 4 mettant en œuvre les services CLIR/OIR mais ne transitent pas par le serveur d'application 8 mettant en œuvre les services CLIP/OIP (ex. un tel cas de figure peut se présenter si les cœurs de réseau CNl et CN2 sont gérés par des opérateurs différents) ; ou
— les messages SIP OPTIONS sont échangés entre les terminaux Tl et T2 en empruntant les cœurs de réseau IMS CNl et CN2, ne transitent pas par le serveur d'application 4 mettant en œuvre les services CLIR/OIR mais transitent par le serveur d'application 8 mettant en œuvre les services CLIP/OIP (ex. un tel cas de figure peut se présenter si les cœurs de réseau CNl et CN2 sont gérés par des opérateurs différents).
Ce mode de réalisation présente également un autre avantage lorsqu'une pluralité de terminaux T2 portent la même identité publique ou IMPU (IP Multimedia Public Identity), qui est de ne nécessiter l'application du traitement conformément à l'invention que sur un seul message M'.
Le standard 3GPP prévoit en effet la possibilité pour une pluralité de terminaux de partager la même identité publique IMPU, auquel cas une fonction de réplication (ou de « forking » en anglais) des messages destinés à l'identité publique IMPU est mise en œuvre 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 Tl avant la fonction de forking : la fonction de forking est alors appliquée sur le message M" contenant l'identifiant du terminal Tl, 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 cœur 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 cœur 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 Tl 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 cœur 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 cœur 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.

Claims

REVENDICATIONS
1. Procédé de traitement d'un message reçu (M1 , en relation avec un message (M) émis par un premier dispositif (Tl) enregistré auprès d'un premier cœur de réseau (CNl) IP multimédia à destination d'un second dispositif (T2) associé à un second cœur de réseau (CN2) IP multimédia, ledit procédé de traitement étant mis en œuvre par une entité (6) du second cœur de réseau IP multimédia et comprenant :
— si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif (E20), une étape d'analyse (E50, E70) d'au moins un champ de ce message reçu afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ; et
— le cas échéant, une étape de désactivation (E60, E80) dudit masquage dans ledit au moins un champ dudit message reçu, avant de le transmettre (E90) vers le second dispositif (T2) de sorte qu'un identifiant du premier dispositif est disponible dans le message transmis pour le second dispositif.
2. Procédé de traitement selon la revendication 1 comprenant en outre, une étape de détermination (E40), conditionnant la mise en œuvre des étapes d'analyse (E50, E70) et de désactivation (E60, E80), au cours de laquelle on détermine si le message reçu est en relation avec un message émis par le premier dispositif dans le cadre d'un échange autonome entre le premier dispositif et le second dispositif.
3. Procédé de traitement selon la revendication 1 dans lequel, au cours de l'étape d'analyse (E50), on analyse un champ du message reçu destiné à contenir un identifiant du premier dispositif fourni par le premier dispositif.
4. Procédé de traitement selon la revendication 3 dans lequel l'étape de désactivation (E60) comprend l'insertion, dans un champ destiné à contenir un identifiant du premier dispositif fourni par le premier dispositif, d'un identifiant du premier dispositif certifié par une entité du premier cœur de réseau IP multimédia et contenu dans le message reçu.
5. Procédé de traitement selon la revendication 1, dans lequel au cours de l'étape d'analyse (E70), on analyse un champ contenant un niveau de confidentialité requis pour le message reçu.
6. Procédé de traitement selon la revendication 5, dans lequel l'étape de désactivation du masquage (E80) comprend l'insertion dans ce champ d'une valeur reflétant un niveau de confidentialité nul.
7. Procédé de traitement selon la revendication 1 dans lequel :
— le premier cœur de réseau (CN1) IP multimédia et le second cœur de réseau (CN2) IP multimédia mettent en œuvre le protocole SIP ;
— le message (M1 de découverte des capacités et/ou d'un état du second dispositif est un message SIP OPTIONS ; et
— ledit au moins un champ analysé au cours de l'étape d'analyse est un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS.
8. Procédé de traitement selon la revendication 7, dans lequel :
— au cours de l'étape d'analyse (E50), on détecte qu'un masquage est activé pour le second dispositif si le champ FROM du message SIP OPTIONS contient un identifiant dit anonyme préservant l'anonymat du premier dispositif ; et
— au cours de l'étape de désactivation du masquage (E60), on remplace l'identifiant anonyme par un identifiant contenu dans un champ SIP P-Asserted-Identity du message SIP OPTIONS.
9. Procédé de traitement selon la revendication 7, dans lequel :
— au cours de l'étape d'analyse (E70), on détecte qu'un masquage est activé pour le second dispositif si le champ SIP PRIVACY du message SIP OPTIONS contient un niveau de confidentialité positionné à une valeur différente de la valeur « none » ; et
— au cours de l'étape de désactivation du masquage (E80), on remplace ladite valeur du niveau de confidentialité du champ SIP PRIVACY par la valeur « none ».
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de traitement selon la revendication 1 ledit programme est exécuté par un ordinateur.
11. Entité de traitement (6) apte à traiter un message (M1 reçu en relation avec un message (M) émis par un premier dispositif (Tl) enregistré auprès d'un premier cœur de réseau (CN1) IP multimédia, à destination d'un second dispositif (T2) associé à un second cœur de réseau (CN2) IP multimédia, cette entité (6) étant une entité du second cœur de réseau IP multimédia comprenant :
— des moyens de vérification (6A) pour vérifier si le message reçu est un message de découverte des capacités et/ou d'un état du second dispositif ;
— des moyens d'analyse (6A), déclenchés le cas échéant, pour analyser au moins un champ du message reçu afin de détecter si un masquage d'un identifiant du premier dispositif est activé pour le second dispositif ;
— des moyens de désactivation (6A), déclenchés si un masquage est détecté, pour désactiver ce masquage dans ledit au moins un champ du message reçu avant de le transmettre vers 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 (6D) du message dans lequel le masquage a été désactivé vers le second dispositif.
12. Entité de traitement selon la revendication 11 intégrée dans un serveur d'application (8) de terminaison d'appel du second cœur de réseau (CN2) ou dans un dispositif (6) situé en aval d'un serveur d'application (8) de terminaison d'appel du second cœur de réseau.
13. Entité de traitement selon la revendication 12 intégrée, lorsque le second cœur de réseau (CN2) IP multimédia implémente une architecture IMS, dans un dispositif quelconque du second cœur de réseau IP multimédia parmi :
— un serveur S-CSCF (6) ;
— un serveur P-CSCF (7) ; ou
— un contrôleur de session SBC.
14. Entité de traitement selon la revendication 12 intégrée, lorsque le second cœur de réseau IP multimédia implémente une architecture mettant en œuvre le protocole SIP, dans un serveur proxy SIP.
15. Entité de traitement (6) selon la revendication 11 dans laquelle, lorsque le premier cœur de réseau IP multimédia et le second cœur de réseau IP multimédia mettent en œuvre le protocole SIP :
— les moyens de vérification sont aptes à vérifier si le message reçu est un message SIP OPTIONS ; et
— les moyens d'analyse sont aptes à analyser un champ FROM ou un champ SIP PRIVACY du message SIP OPTIONS.
16. Cœur de réseau (CN2) IP multimédia comprenant une entité de traitement (6) selon la revendication 11.
PCT/FR2013/050830 2012-04-17 2013-04-16 Procede de traitement d'un message, entite et cœur de reseau WO2013156727A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1253529 2012-04-17
FR1253529A FR2989548A1 (fr) 2012-04-17 2012-04-17 Procede de traitement d'un message, entite et coeur de reseau

Publications (1)

Publication Number Publication Date
WO2013156727A1 true WO2013156727A1 (fr) 2013-10-24

Family

ID=48906435

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/050830 WO2013156727A1 (fr) 2012-04-17 2013-04-16 Procede de traitement d'un message, entite et cœur de reseau

Country Status (2)

Country Link
FR (1) FR2989548A1 (fr)
WO (1) WO2013156727A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070153990A1 (en) * 2005-12-29 2007-07-05 Daigle Brian K User selected caller ID override

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070153990A1 (en) * 2005-12-29 2007-07-05 Daigle Brian K User selected caller ID override

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; 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)", 3GPP STANDARD; 3GPP TS 24.607, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V10.0.0, 14 June 2010 (2010-06-14), pages 1 - 20, XP050441664 *
"A privacy mechanism for the Session Initiation Protocol (SIP", November 2002, IETF, article "RFC 3323"
"RFC 3261", June 2002, IETF, article "SIP: Session Initiation Protocol"
"Technical Specification Group Core Network and Terminais; Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification", 3GPP TS24.607
RCS-E ADVANCED COMMUNICATIONS: SERVICES AND CLIENT SPÉCIFICATION, 8 April 2011 (2011-04-08)

Also Published As

Publication number Publication date
FR2989548A1 (fr) 2013-10-18

Similar Documents

Publication Publication Date Title
EP2772035B1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2856732B1 (fr) Procédé et entité de traitement d'un message
WO2009125149A1 (fr) Procede de terminaison d'un appel et terminal de voix sur ip
EP2898715A1 (fr) Procedes de verification et de controle dans un c ur de reseau ip multimedia, et serveurs
EP3646554B1 (fr) Procédé de traitement d'une requête et serveur d'un coeur de réseau ip multimédia
EP2550776A1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
WO2017212172A1 (fr) Procédé d'enrichissement d'une signalisation d'une communication et dispositif
EP2786546A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
EP3560168B1 (fr) Classification et aiguillage de messages de contrôle d'une infrastructure de communications
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
FR3037464A1 (fr) Procede et dispositif de mise a jour d'une liste de filtrage des communications destinees a un terminal destinataire
WO2019239029A1 (fr) Procédé de traitement de messages par un dispositif d'un réseau de voix sur ip
EP2859704B1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
WO2013121158A1 (fr) Procédé d'enregistrement d'un serveur d'application et serveur d'application
FR3001351A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
WO2019234325A1 (fr) Procédé de mise à jour d'une base de données d'un réseau de voix sur ip
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
FR2909501A1 (fr) Procede et systeme de telecommunication permettant a au moins deux utilisateurs distinct d'acceder a un meme ensemble d'informations
WO2009112760A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
WO2013001213A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé.
WO2012072920A1 (fr) Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims
FR2985404A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13742670

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13742670

Country of ref document: EP

Kind code of ref document: A1