WO2013178909A1 - Procédé et entité de traitement d'un message - Google Patents

Procédé et entité de traitement d'un message Download PDF

Info

Publication number
WO2013178909A1
WO2013178909A1 PCT/FR2013/051086 FR2013051086W WO2013178909A1 WO 2013178909 A1 WO2013178909 A1 WO 2013178909A1 FR 2013051086 W FR2013051086 W FR 2013051086W WO 2013178909 A1 WO2013178909 A1 WO 2013178909A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
mopt
response
identifier
discovery
Prior art date
Application number
PCT/FR2013/051086
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
Priority to ES13729982T priority Critical patent/ES2880477T3/es
Priority to BR112014029410-0A priority patent/BR112014029410B1/pt
Priority to CN201380034252.XA priority patent/CN104396213B/zh
Priority to EP13729982.2A priority patent/EP2856732B1/fr
Priority to JP2015514553A priority patent/JP6293740B2/ja
Priority to RU2014153554A priority patent/RU2643498C2/ru
Priority to US14/403,131 priority patent/US10091708B2/en
Priority to KR1020147036750A priority patent/KR102109099B1/ko
Publication of WO2013178909A1 publication Critical patent/WO2013178909A1/fr
Priority to ZA2014/08555A priority patent/ZA201408555B/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/14—Access restriction or access information delivery, e.g. discovery data delivery using user query or user detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

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
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • 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 invention relates more particularly to the processing, by a so-called processing entity, of a message received from a first device, and intended for a second device (such as a terminal or a server) managed by a heart of a multimedia IP network, in the context of a multimedia communication service based on a mechanism for self-discovery of the capabilities and state of the remote (in other words, the second device here) -
  • such a self-discovery mechanism provides for the sending by the first device to the second "remote" device, of a specific message inviting it to declare in response to this message, on the one hand, its state ( available, in communication, out of coverage, not registered, etc.), and on the other hand its capabilities, ie the services, protocols, and / or applications that it supports or implements. artwork.
  • This specific message is designated by "message of discovery of the capabilities and state of the remote” or “message of discovery of the capabilities and the state of the second device” in the following description.
  • An example of such a message for the SIP protocol is a message based on the SIP OPTIONS method.
  • the RCS-e standard allows two terminals registered with an IMS core network to establish a communication via a circuit switched network not connected to the IMS core network (eg via a GSM network ( Global System for Mobile Communications)), then in parallel or in the margins of this communication, to use multimedia services via a packet-switched network connected to the IMS (IP Multimedia Subsystem) core network.
  • additional so-called enhanced communication such as for example a photo transfer service, an instant messaging service, a file sharing service, etc.
  • the RCS-e standard provides, in particular for the creation of a contact in the directory of a first terminal or the establishment of a communication between a first terminal and a second terminal, the implementation a mechanism for automatic discovery of the state and capabilities RCS-e of the second terminal by the first terminal (and vice versa), based on the use of a Session Initiation Protocol (SIP) OPTIONS.
  • SIP Session Initiation Protocol
  • the use of a mechanism for self-discovery of the state and capabilities of the remote may also be considered in the context of an after-sales service (SAV) provided by a telecom operator or a service provider, to obtain relevant information regarding the state and capabilities of a device on which a maintenance operation is planned or desired.
  • SAV after-sales service
  • any receiving device of a SIP OPTIONS discovery message is required to respond transparently by sending the sending device the discovery message, an appropriate response message reflecting its state and containing its capabilities.
  • the second device if it is available and compatible with the RCS-e service, it sends a 200 OK response message to the first device, containing in a "feature tag” field the identifier of the RCS-e service, and as the identifiers of the other services supported by the second device (via other features tag and / or Session Description Protocol (SDP) sessions).
  • the response message 200 OK also contains the SIP methods supported by the second device, etc.
  • receipt of a SIP OPTIONS message by the second device is unbeknownst to the user of the second device. It is not signaled specifically to the user and does not trigger any ringing of the second device or notification of receipt of the SIP OPTIONS message.
  • the SIP standard now offers the possibility to any device, via the sending of a SIP OPTIONS message, to discreetly discover the status and / or the capabilities of a remote device, without the user of this remote device is not informed of the implementation of this discovery mechanism nor has any trace of this implementation.
  • the invention responds to this need by proposing a method of processing a message received from a first device and intended for a second device managed by a multimedia IP core network, this method being intended to be implemented. by a processing entity when this received message is a message of discovery of the capabilities and the state of the second device.
  • the treatment method according to the invention is remarkable in that it comprises:
  • the invention also proposes a processing entity of a message received from a first device and intended for a second device managed by a multimedia IP core network, including means activated if the message received is a message from discovering the capabilities and condition of the second device and comprising:
  • Means adapted to select, according to this identifier, a response mode to the received discovery message from a predefined set containing at least two response modes.
  • the invention thus proposes, in order to guard against the abuses mentioned above, to filter the messages of discovery of the capabilities and the state of the remote intended for a second device according to the origin of these messages.
  • This filtering is performed, according to the invention, taking into account the identity of the first device at the origin of the discovery message to decide a mode (that is to say, a strategy) response to this message of discovery (eg no answer or transparent answer).
  • a mode that is to say, a strategy
  • the invention introduces an additional degree of freedom in the way of answering a message of discovery of the capabilities and state of the remote: it offers the possibility to the processing entity to control the response to the message discovery according to the identifier of the first device.
  • the processing entity can be configured to respond to the discovery message transparently (i.e. by sending a response message containing the status and "real" capabilities of the second device) than authorized or selected devices, for example by the user of the second device or the operator of the IP multimedia core network.
  • the invention makes it possible to counterbalance the opportunity given to the first device, by the current SIP standard, to know the state and the capabilities of the second device without the knowledge of the user of the second device.
  • the fact that, according to the invention, several possible modes of response to the discovery message are available makes it possible to adapt in these response modes the quantity and the information supplied to the first device according to the identity of the device. first device.
  • response modes can be envisaged in the predefined set among which is made the selection of the processing entity to counter the abuses mentioned above.
  • These response modes can advantageously be parameterized by the user of the second device itself, via a user interface (eg web interface or application developed for this purpose), or by the operator of the IP multimedia core network.
  • this predefined set of response modes contains at least:
  • a response mode comprising sending the first device a partial, predefined or erroneous response to the discovery message
  • a response mode comprising sending the first device a transparent response to the discovery message containing the capabilities and the state of the second device.
  • a response is always sent to the first device, which is consistent with the response obligation provided in particular in the SIP protocol.
  • the actual content of this response is adapted according to the identifier of the first device.
  • the processing entity via appropriate selection rules, to send to the first device:
  • a transparent response that is to say which reflects and / or contains all the capabilities and the actual state of the second device, when for example this identifier satisfies a predetermined criterion
  • a partial response (that is to say incomplete in the sense that it identifies only a part of the capabilities of the second device or it reflects only its state), predefined or containing erroneous information, when the identifier does not verify this criterion
  • the systematic sending of a response to the first device avoids the transmission by the first retransmission message device, due to the non-receipt of a message response message of discovery. This preserves the network load, while controlling the information sent to the first device on the state and capabilities of the second device.
  • the predefined set contains at least:
  • a response mode comprising sending the first device a transparent response to the discovery message containing the capabilities and the state of the second device;
  • a response mode comprising the absence of a response to the discovery message.
  • Predicting a response mode in which no response is sent to the first device may have a billing benefit for the user of the second device. Indeed, besides the disclosure of "private" information concerning the second device, the auto-discovery mechanism provided for today by the SIP standard also raises the problem of the billing of the sending of a response message to the SIP standard. first device, and the cost that it can represent globally for the second device to respond to all SIP OPTIONS messages it receives.
  • the cost associated with sending a response message to a SIP OPTIONS message naturally falls on the second device (at least it is counted in the uplink rate at which the user of the second device can claim an account. subscription to the network operator).
  • the invention therefore allows the user of the second device to select the devices to which he wishes to respond and thereby limit the associated costs.
  • the invention applies in a targeted manner to the messages of discovery of the capabilities and the state of the remote, and not to all the messages for the second device.
  • the purpose of the invention is to protect the user of the second device against an attack on private information concerning the second device required via messages received without the knowledge of the user, and to which the second device is required to respond in accordance with Standard.
  • the invention does not deal strictly with the processing of other types of messages that messages of discovery of the state and capabilities of the remote.
  • the discovery message processed by the processing entity is a SIP OPTIONS message and the field of this message containing the identifier of the first device is a FROM field or a P-Asserted-Identity field (in particular case of masking the identifier of the first device) -
  • the choice of the response mode to the discovery message can be made according to different criteria relating to all or part of the identifier of the first device (typically all or part of the contents of the field FROM or P- Asserted- Identity for a SIP OPTIONS message) and according to different predetermined selection rules.
  • the processing entity can select a response mode from the predefined set according to the presence or absence of the identifier of the first device in at least one predefined list of identifiers associated with the second device.
  • This list may be defined in particular by the user of the second device, depending on the devices to which he agrees to send information about the state and capabilities of his device.
  • this predefined list of identifiers associated with the second device may take the form of a directory associated with the second device, stored locally on the second device or, on the contrary, on a remote device, in the core network.
  • Multimedia IP on an application server or in a backbone operator's information system
  • another network eg on an access gateway to the multimedia IP core network, or on a piece of equipment such as a terminal connected to a local area network to which the second device is also connected, etc.
  • the processing entity selects a response mode from the predefined set based on whether the identifier of the first device belongs to a network domain identical to the network domain of the second device. or to an authorized network domain.
  • This embodiment makes it possible to take into account network parameters for the filtering of the discovery messages.
  • the processing entity selects a response mode from the predefined set according to whether or not the identifier of the first device comprises a predetermined user portion or a predetermined type (such as a prefix of international number or a particular URI for example).
  • user part is meant that part of the identifier which is specific to the user of the first device, that is to say which identifies the user of the first device and does not correspond to the domain or network managing the one -this. For example, for an identifier in the form of an address of type "user_name @ domain_name”, this user part corresponds to the "user_name” element located to the left of the "@” symbol.
  • the user part of the identifier corresponds to the "User-Part" part of the contents of the FROM or P-Asserted-Identity field.
  • the invention is not limited to a filter criterion or a selection rule in particular, and several filtering criteria can be applied simultaneously or successively to select the response mode.
  • other filtering criteria than those mentioned above, covering all or part of the identifier of the first device can be envisaged, in combination or independently of each other.
  • this response depends on a number and / or a type. current sessions for the second device when receiving the message.
  • the first device may be useful to indicate to the first device the state of the sessions in progress at the second device so that the first device can adapt where appropriate its exchanges with the second device.
  • the processing of the discovery messages according to the invention can be implemented at different levels.
  • the processing entity can be integrated in particular in the second device. This facilitates the configuration of the filtering allowed by the invention (filtering criteria and selection rules in particular) by the user of the second device.
  • the processing entity may be integrated into an application server of the multimedia IP core network managing the second device.
  • This application server may for example be triggered by the multimedia IP core network on receipt of a discovery message for the second device.
  • the invention therefore also relates to a terminal managed by a multimedia IP core network and comprising a processing entity according to the invention of a message received from a device and intended for the terminal.
  • the invention also relates to a server associated with a multimedia IP core network managing a device, this server comprising a processing entity according to the invention, a message received for the device.
  • This server is for example an application server of the IP multimedia core network.
  • 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 medium, this program being capable of being implemented in a processing entity or more generally in a computer, this program comprising instructions adapted to the implementing the steps of a method of treatment 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 communication system comprising:
  • a first device and a second device managed by a multimedia IP core network the first device being adapted to send, to the second device, a message for discovering the capabilities and status of the second device;
  • a processing entity adapted to receive and process the discovery message sent by the first device to the second device.
  • FIG. 1 illustrates schematically a communication system and a processing entity according to the invention in a first embodiment
  • FIG. 2 shows schematically the hardware architecture of the processing entity shown in Figure 1;
  • FIG. 3 represents the main steps of a processing method according to the invention implemented by the processing entity of FIG. 1 in the first embodiment
  • FIG. 4 illustrates schematically a communication system and a processing entity according to the invention in a second embodiment
  • FIG. 5 shows the main steps of a processing method according to the invention implemented by the processing entity of Figure 4 in the second embodiment.
  • FIG. 1 represents, in its environment, a communication system 1 according to the invention, including two devices D1 and D2, and a processing entity 2 according to the invention, in a first embodiment.
  • the devices D1 and D2 are, for example, multimedia terminals, such as smart mobile phones (or “smartphones” in English), able to communicate with each other via multimedia IP core networks CN1 and CN2. They each have a local directory (or "address book"), denoted respectively RL1 and RL2, containing different identifiers (eg phone numbers, SIP addresses, etc.) of equipment known and referenced by the respective users. devices D1 and D2 (and / or by network core operators CN1 and CN2).
  • multimedia terminals such as smart mobile phones (or “smartphones” in English
  • RL1 and RL2 containing different identifiers (eg phone numbers, SIP addresses, etc.) of equipment known and referenced by the respective users.
  • identifiers eg phone numbers, SIP addresses, etc.
  • the network cores CN1 and CN2 are network cores using "voice over IP” technology and managing the devices D1 and D2, respectively. They implement an IMS architecture, as defined in particular in 3GPP TS 22.228 "Service requirements for the IP Multimedia Core Network Subsystem (Stage 1)", and implementing the SIP session initiation protocol.
  • IMS architecture as defined in particular in 3GPP TS 22.228 "Service requirements for the IP Multimedia Core Network Subsystem (Stage 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. It also applies to other types of devices (for example D1 can be a terminal and D2 a server), to other IP multimedia core network architectures, as well as to other protocols for initiating session, such as proprietary core network architectures using the SIP protocol or another proprietary session initiation protocol providing a message to discover the capabilities and status of the remote.
  • D1 can be a terminal and D2 a server
  • other IP multimedia core network architectures as well as to other protocols for initiating session, such as proprietary core network architectures using the SIP protocol or another proprietary session initiation protocol providing a message to discover the capabilities and status of the remote.
  • the MOPT message sent by the device D1 is a SIP OPTIONS message, as described in detail in the document RFC 3261 cited above. It contains in a FROM field, an identifier ID1 of the device D1 at the origin of the message, and in a Request-URI field and in a field TO, an identifier ID2 of the device D2 recipient of the message.
  • the activation of the SIP message filtering service OPTIONS for the device D2 is stored in a user profile of the device D2 stored at the home subscriber server (HSS) of the multimedia core network CN2 (no shown in Figure 1).
  • HSS home subscriber server
  • the processing entity 2 of the SIP OPTIONS messages according to the invention is integrated in an application server (or AS for "Application Server” in English) of the CN2 core network. , triggered on detection of a SIP OPTIONS message to the device D2.
  • the application server 2 is a processing entity within the meaning of the invention.
  • the triggering of the application server 2 is activated in accordance with the information (and in particular the iFC or Initial Filter Criteria) contained in the user profile of the user of the device D2 stored in the HSS server CN2 heart network, provided during the subscription for use upon activation of the filtering service.
  • the application server 2 may be a server dedicated to the implementation of the method of processing SIP messages OPTIONS according to the invention or an existing application server and triggered during the implementation of other applications.
  • the application server 2 is triggered by a Serving Call Session Control Function (S-CSCF) server of the CN2 network core or by another server located downstream of this S-CSCF server, after having detected that the message MOPT received from the device D1 is a SIP OPTIONS message intended for a device D2 (identified in particular by means of the "Request URI" or "To" field of the received message MOPT), having activated the filtering service according to the invention of the SIP messages OPTIONS for it.
  • S-CSCF Serving Call Session Control Function
  • the application server 2 here has the hardware architecture of a computer as schematically illustrated in FIG. 2.
  • a processor 2A it comprises in particular a processor 2A, a random access memory 2B, a read-only memory 2C, a non-volatile flash memory 2D as well as communication means 2E implementing in particular the SIP protocol.
  • These communication means allow it to communicate with the entities of the network core CN2 and with the device D2.
  • the read-only memory 2C of the application server 2 constitutes a recording medium in accordance with the invention, readable by the processor 2A and on which is recorded a computer program according to the invention, comprising instructions for execution. steps of a processing method according to the first embodiment of the invention, now described with reference to FIG.
  • FIG. 3 illustrates the main steps of a processing method according to the invention, implemented by the application server 2 of FIG. 1 according to the first embodiment, after it has been triggered following reception by the heart of CN2 network SIP message MOPT OPTIONS issued by the device Dl to the device D2.
  • the processing proposed by the invention consists in filtering the discovery messages (such as the OPTIONS messages for the SIP protocol) according to the identifiers of the devices at the origin of these messages, and in selecting a response mode. among a predefined set of response modes containing at least two response modes based on these identifiers.
  • the discovery messages such as the OPTIONS messages for the SIP protocol
  • Sending a partial response to the discovery message constituted for example by a message reflecting a state of the interrogated device without including its capabilities, a message reflecting a state of the interrogated device and only part of its capabilities, or a predefined message containing only its capabilities;
  • This list may be in particular a local directory (or "address book") stored on the interrogated device or stored on a remote device in a network (for example, in the CN2 multimedia IP backbone, at the server of application 2 or in a network operator information system the device
  • D2 may be, in a variant, a list of identifiers of devices authorized to receive the state and real capacities of the interrogated device, stored for example at the level of the application server 2 or in an information system the network operator of the device D2 which can be consulted by the application server 2, and configured by the user of the interrogated device. It may be, in another variant, a list configured by the user of "forbidden" identifiers to which the user refuses to communicate the state and capabilities of his device, stored for example at the server level application 2 or in an information system of the network operator of the device D2 can be consulted by the application server 2;
  • the interrogated device Whether or not the identifier of the device causing the discovery message to a network domain identical to the network domain of the interrogated device or to an authorized domain (by the operator of the core network or by the user) the interrogated device);
  • a predetermined user part ie part "User Part” of the identifier for a SIP OPTIONS message
  • a predetermined type ex. containing an international number other than the prefix "+33”, or a specific prefix such as "+331” - “+335", “+338” or "+339”, or corresponding to a type of URI (Uniform Request Identifier ) such as a SIP URI or TEL URI);
  • the response mode "no response to the discovery message" is selected; If the identifier of the device at the origin of the discovery message is present in the local directory of the interrogated device, the response mode "sending a transparent response to the discovery message" is selected;
  • selection rules based on a plurality of criteria (eg if the identifier of the device at the origin of the discovery message is in the same network domain as the identifier of the interrogated device and in the local directory of the interrogated device, then we select the response mode of sending a transparent response to the device at the origin of the discovery message).
  • the content of the response depends on parameters such as the state of the device D2 and in particular the number of sessions already in progress at the device D2 and / or the type sessions already in progress (depending, for example, on the services available or otherwise used).
  • the set of response modes contains two response modes, namely:
  • o M2 mode "partial response to the discovery message containing only the state of the interrogated device"
  • the set C of the criteria contains a single criterion, namely: presence or absence of the identifier in the local directory of the interrogated device;
  • the set S of the selection rules contains two rules, namely:
  • sets ⁇ , S and C are stored in the 2D flash memory of the application server 2 during a preliminary configuration step (step EO). It should be noted that the choice of sets ⁇ , S and C can be made by the user of the device D2 itself, for example via a web interface, voice or text, etc.
  • the triggering of the application server 2 results in the application server 2 receiving the message MOPT (step E10).
  • the application server 2 extracts from the FROM field of the received MOPT message an identifier of the device D1 (step E20).
  • the identifier of the device D1 contained in the FROM field is here the identifier ID1.
  • the application server 2 determines whether the MOPT message contains a SIP PRIVACY field.
  • the MOPT message determines whether there exists in the MOPT message a P-Asserted-Identity field containing a certified identifier of the device D1 and likely to have been introduced and / or entered by the network core CN1 traversed by the message MOPT following transmission by the device Dl.
  • the networks through which a message sent by a device to another device transits can be inserted, to meet different needs (eg billing, routing of the message, legal interceptions, etc.).
  • a certified identifier of the device at the origin of the message is inserted here by the network core CN1 in the P-Asserted-Identity field of the message.
  • the application server 2 extracts the identifier of the device D1 contained in this P-Asserted-Identity field.
  • step E30 determines whether the identifier ID1 of the device D1 extracted from the message MOPT verifies the filter criteria or criteria defined in the set C, stored in the 2D memory (step E30).
  • a single criterion is stored in the 2D memory, namely the criterion "presence or absence of the identifier of the device at the origin of the SIP OPTIONS message in the local directory of the interrogated device".
  • the application server 2 examines whether the identifier ID1 of the device D1 is present (i.e. referenced) in the local directory RL2 of the device D2.
  • the application server 2 selects the response mode M1 (step E50).
  • step E60 it sends to the device D1 a transparent response to the SIP OPTIONS message containing the state of the device D2 and its capabilities (step E60).
  • the state of the device D2 and its capabilities are obtained by the application server 2 directly from the device D2.
  • the application server 2 extends (i.e. relays) the SIP OPTIONS MOPT message to the second device D2, without changing its content.
  • the device D2 then responds to the SIP OPTIONS message transparently, in accordance with the SIP protocol, that is to say by providing its state and its capabilities.
  • the answer of the device D2 takes the inverse path of the message MOPT, in accordance with the operating mode of the SIP protocol. This response therefore passes through the application server 2.
  • the one intercepts the response message from the device D2 and elaborates, with the aid of this message, its transparent response to the device D1 containing the state of the device D2 and its capabilities according to the selected response mode Ml.
  • the transparent response sent by the application server 2 to the device D1 is similar or identical to the response message to the SIP OPTIONS message provided in the document RFC 3261 of the SIP standard (same format and same content regarding the state and capabilities of device D2).
  • the application server 2 selects, in accordance with the selection rules defined in the set S, the response mode M2 (step E70).
  • step E80 it sends to the device D1 a partial response to the device D1 containing only a state of the device D2 (step E80).
  • This partial response does not contain information about the capabilities of device D2.
  • step E60 the information concerning the state of the device D2 is obtained by the application server 2 by interrogating the device D2, by transmitting here the received SIP OPTIONS MOPT message.
  • the application server 2 can refrain from consulting the device D2 to obtain its status and capabilities, and respond directly to the device Dl.
  • the application server 2 transmits to the device D2 the SIP OPTIONS MOPT message received from the device D1, transparently (ie without changing the content), and then filters and / or adjusts the response received from the device D2 to the SIP OPTIONS message according to the response rules configured for the selected answer mode.
  • the application server 2 determines that the device D2 is in a busy state, it sends a response message "486 BUSY HERE" to the device D1 in which no information on the capabilities of the device D2 is present. .
  • the processing in accordance with the invention of the SIP OPTIONS MOPT message intended for the device D2 is implemented by an application server 2 of the multimedia IP network core CN2.
  • the processing entity of the invention is the application server 2.
  • FIG. 4 represents, in its environment, a communication system according to the invention in a second embodiment.
  • the communication system includes two devices D1 'and D2' managed respectively by a multimedia IP core network CN1 'and a multimedia IP core network CN2'.
  • the devices D1 'and D2' are here terminals provided with local directories, respectively denoted RL1 'and RL2'.
  • the processing according to the invention of a MOPT discovery message 'sent by the device D1' to the device D2 ' is implemented by the device D2' itself.
  • the device D2 ' is a processing entity within the meaning of the invention.
  • the devices D1 ', and the multimedia IP network cores CN1' and CN2 ' are similar or identical to the devices D1 and to the network cores CN1 and CN2 described with reference to FIG. 1, and are not described again in detail here. .
  • the device D2 ' is similar to the device D2 of FIG. 1. However, it differs from the device D2 in that it comprises a read-only memory 3 on which is recorded a computer program according to the invention, comprising instructions for the performing the steps of a processing method according to the second embodiment of the invention.
  • This read-only memory 3 constitutes a recording medium in accordance with the invention, readable by a processor of the device D2 '.
  • the message MOPT ' is here a SIP OPTIONS message, as described in detail in the document RFC 3261. It contains in a FROM field, an identifier ID1' of the device D1 'at the origin of the message, and in a Request field. -URI and in a TO field, an identifier ID2 'of the device D2' recipient of the message.
  • the set ⁇ of response modes contains two response modes, namely:
  • o M2 mode "partial response to the discovery message containing only the state of the interrogated device"
  • the set C of the criteria contains a single criterion, namely: presence or absence of the identifier in the local directory of the interrogated device;
  • the set S of the selection rules contains two rules, namely: o if the identifier is present in the local directory, then one responds according to the mode Ml; o If not, answer in M2 mode.
  • a non-volatile flash memory device D2 'during a preliminary configuration step (step F0). It should be noted that the configuration of the device D2 'and more precisely the choice of the sets ⁇ , S and C can be carried out by the user of the device D2' itself, for example via a web interface , voice or text, etc.
  • the message MOPT 'sent by the device D1' to the device D2 ' is received by the device D2' after passing through the network cores CN1 'and CN2' (step F10).
  • the device D2' Upon receipt of the message MOPT ', the device D2' determines at first whether it is a message of discovery of its state and its capabilities, ie here if it is a SIP message OPTIONS that it must treat according to the invention (step F20).
  • step F20 If it is not a SIP OPTIONS message (answer no in step F20), the device D2 'processes this message conventionally, as provided by the SIP protocol, depending on the type of this message (step F30 ).
  • the device D2' processes this message according to the invention.
  • step F50 It determines whether this identifier ID1 'checks the filtering criterion or criteria defined in the set C, stored in its non-volatile flash memory (step F50): in other words here, it checks here whether the identifier ID1' is present or not in the local directory RL2 'of the device D2';
  • step F80 It selects, if necessary (answer yes to the test step F60), the response mode M1 (step F70), and sends the device D1 a transparent response to the SIP message MOPT OPTIONS containing its state and its capabilities. real "(step F80);
  • step F60 selects the response mode M2 (step F90) and sends the device D1 'a partial response to the message SIP OPTIONS MOPT' containing only its state but not identifying its capabilities (step F100).
  • the steps F40, F50, F60, F70 and F90 being identical to the steps E20, E30, E40, E50 and E70, they will not be described in more detail here.
  • the steps F80 and F100 differ from the steps E60 and E80 respectively, in that the device D2 'prepares the response to the SIP OPTIONS MOPT' message directly from its state and / or its capabilities.
  • the processing of the SIP OPTIONS message according to the invention is carried out independently of the existence or not of a dialogue between the devices D1 and D2, respectively between the devices D1 'and D2'.
  • SIP OPTIONS messages it is conceivable to process SIP OPTIONS messages according to the invention only when they are issued in the context of an autonomous transaction or "standalone" transaction between devices, that is to say, which is not carried out within the framework of a dialogue established between the devices or which does not initiate such a dialogue.
  • the invention has indeed an additional advantage in such a context, because the device recipient of the discovery message has not already agreed to a communication with the device at the origin of the discovery message.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention vise un procédé de traitement d'un message reçu (MOPT) en provenance d'un premier dispositif et destiné à un second dispositif géré par un cœur de réseau IP multimédia, ce procédé étant destiné à être mis en œuvre par une entité de traitement (2) lorsque le message reçu (MOPT) est un message de découverte des capacités et de l'état du second dispositif (D2), et comprenant : — une étape d'obtention (E20) d'un identifiant (ID1) du premier dispositif à partir d'un champ du message de découverte reçu (MOPT); et — une étape de sélection (E50, E70), en fonction de cet identifiant (ID1), d'un mode de réponse (Ml, M2) au message de découverte reçu parmi un ensemble prédéfini (Ω) contenant au moins deux modes de réponse (M1, M2).

Description

Procédé et entité de traitement d'un message
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 a 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.).
L'invention concerne plus particulièrement le traitement, par une entité dite de traitement, d'un message reçu en provenance d'un premier dispositif, et destiné à un second dispositif (tel qu'un terminal ou un serveur) géré par un 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 de l'état du distant (autrement dit ici, du second dispositif)-
De façon connue, un tel mécanisme d'auto-découverte prévoit l'envoi par le premier dispositif au second dispositif « distant », d'un message spécifique l'invitant à déclarer en réponse à ce message, d'une part son état (ex. disponible, en communication, hors couverture, non enregistré, etc.), et d'autre part ses capacités, c'est-à-dire les services, les protocoles, et/ou les applications qu'il supporte ou met en œuvre.
Ce message spécifique est désigné par « message de découverte des capacités et de l'état du distant » ou « message de découverte des capacités et de l'état du second dispositif » dans la suite de la description. Un exemple d'un tel message pour le protocole SIP est un message s'appuyant sur la méthode SIP OPTIONS.
Ce mécanisme d'auto-découverte est utilisé notamment par le service multimédia RCS- e (Rich Communication Suite - Enhanced), décrit dans le document intitulé « RCS-e Advanced Communications: Services and client spécification », version 1.1, Avril 8, 2011.
De façon connue, le standard RCS-e permet à deux terminaux enregistrés auprès d'un cœur de réseau IMS, d'établir une communication via un réseau à commutation de circuits non relié au cœur de réseau IMS (ex. via un réseau GSM (Global System for Mobile Communications)), puis en parallèle ou en marge de cette communication, d'utiliser via un réseau à commutation de paquets connecté au cœur de réseau IMS (IP Multimedia Subsystem), des services multimédia additionnels dits de communication enrichie, tels que par exemple un service de transfert de photos, un service de messagerie instantanée, un service de partage de fichiers, etc.
A cette fin, le standard RCS-e prévoit, lors notamment de la création d'un contact dans le répertoire d'un premier terminal ou de l'établissement d'une communication entre un premier terminal et un deuxième terminal, la mise en œuvre d'un mécanisme de découverte automatique de l'état et des capacités RCS-e du deuxième terminal par le premier terminal (et inversement), basé sur l'utilisation d'un message SIP (Session Initiation Protocol) OPTIONS.
L'utilisation d'un mécanisme d'auto-découverte de l'état et des capacités du distant peut également être envisagée dans le cadre d'un service après-vente (SAV) fourni par un opérateur télécom ou par un fournisseur de service, afin d'obtenir des informations pertinentes concernant l'état et les capacités d'un dispositif sur lequel une opération de maintenance est prévue ou souhaitée.
Conformément au protocole SIP, tout dispositif récepteur d'un message de découverte SIP OPTIONS est tenu d'y répondre de manière transparente, en envoyant au dispositif émetteur du message de découverte, un message de réponse approprié traduisant son état et contenant ses capacités.
Ainsi, par exemple, si le second dispositif est disponible et compatible avec le service RCS-e, il envoie un message de réponse 200 OK au premier dispositif, contenant dans un champ « feature tag » l'identifiant du service RCS-e, ainsi que les identifiants des autres services supportés par le second dispositif (via d'autres features tag et/ou des sessions SDP (Session Description Protocol)). Le message de réponse 200 OK contient également les méthodes SIP supportées par le second dispositif, etc.
Il convient de noter que, conformément à la norme, la réception d'un message SIP OPTIONS par le second dispositif se fait à l'insu de l'utilisateur du second dispositif. Elle n'est pas signalée spécifiquement à l'utilisateur et ne déclenche aucune sonnerie du second dispositif ou notification de la réception du message SIP OPTIONS.
La norme SIP offre donc aujourd'hui la possibilité à tout dispositif, via l'envoi d'un message SIP OPTIONS, de découvrir en toute discrétion l'état et/ou les capacités d'un dispositif distant, sans que l'utilisateur de ce dispositif distant ne soit informé de la mise en œuvre de ce mécanisme de découverte ni n'ait trace de cette mise en œuvre.
On comprend bien dès lors que des abus peuvent résulter d'un tel mode de fonctionnement. On peut redouter notamment l'envoi intempestif de messages SIP OPTIONS par des acteurs économiques peu scrupuleux, en vue d'obtenir des informations concernant les terminaux des utilisateurs, et d'exploiter ces informations à des fins purement commerciales (ex. revente de ces informations à des sociétés de commerce).
Il existe donc un besoin d'un mécanisme de protection contre de tels abus. Objet et résumé de rinvention
L'invention répond notamment à ce besoin en proposant un procédé de traitement d'un message reçu en provenance d'un premier dispositif et destiné à un second dispositif géré par un cœur de réseau IP multimédia, ce procédé étant destiné à être mis en œuvre par une entité de traitement lorsque ce message reçu est un message de découverte des capacités et de l'état du second dispositif. Le procédé de traitement selon l'invention est remarquable en ce qu'il comprend :
— une étape d'obtention d'un identifiant du premier dispositif à partir d'un champ du message de découverte reçu ; et
— une étape de sélection, en fonction de cet identifiant, d'un mode de réponse au message de découverte reçu parmi un ensemble prédéfini contenant au moins deux modes de réponse.
Corrélativement, l'invention propose également une entité de traitement d'un message reçu en provenance d'un premier dispositif et destiné à un second dispositif géré par un cœur de réseau IP multimédia, comprenant des moyens activés si le message reçu est un message de découverte des capacités et de l'état du second dispositif et comprenant :
— des moyens d'obtention d'un identifiant du premier dispositif à partir d'un champ du message de découverte reçu ; et
— des moyens aptes à sélectionner, en fonction de cet identifiant, un mode de réponse au message de découverte reçu parmi un ensemble prédéfini contenant au moins deux modes de réponse.
L'invention propose ainsi, pour se prémunir contre les abus évoqués précédemment, de filtrer les messages de découverte des capacités et de l'état du distant destinés à un second dispositif en fonction de l'origine de ces messages.
Ce filtrage est réalisé, conformément à l'invention, en prenant en compte l'identité du premier dispositif à l'origine du message de découverte pour décider d'un mode (c'est-à-dire d'une stratégie) de réponse à ce message de découverte (ex. absence de réponse ou réponse transparente).
Autrement dit, l'invention introduit un degré de liberté supplémentaire dans la façon dont on répond à un message de découverte des capacités et de l'état du distant : elle offre la possibilité à l'entité de traitement de contrôler la réponse faite au message de découverte en fonction de l'identifiant du premier dispositif.
En corollaire, grâce à l'invention, on peut configurer l'entité de traitement pour qu'il soit répondu au message de découverte de façon transparente (c'est-à-dire en envoyant un message de réponse contenant l'état et les capacités « réels » du second dispositif) qu'à des dispositifs autorisés ou choisis, par exemple par l'utilisateur du second dispositif ou par l'opérateur du cœur de réseau IP multimédia.
Ainsi, l'invention permet de contrebalancer l'opportunité donnée au premier dispositif, par la norme SIP actuelle, de connaître l'état et les capacités du second dispositif à l'insu de l'utilisateur du second dispositif. Le fait en effet de disposer, conformément à l'invention, de plusieurs modes de réponse possibles au message de découverte offre la possibilité d'adapter dans ces modes de réponse la quantité et les informations fournies au premier dispositif en fonction de l'identité du premier dispositif.
Différents modes de réponse peuvent être envisagés dans l'ensemble prédéfini parmi lequel est opérée la sélection de l'entité de traitement pour parer aux abus évoqués précédemment. Ces modes de réponse peuvent avantageusement être paramétrés par l'utilisateur du second dispositif lui-même, via une interface utilisateur (ex. interface web ou application développée à cette effet), ou par l'opérateur du cœur de réseau IP multimédia.
Préférentiellement, cet ensemble prédéfini de modes de réponses contient au moins :
— un mode de réponse comprenant un envoi au premier dispositif d'une réponse partielle, prédéfinie ou erronée au message de découverte ; et
— un mode de réponse comprenant un envoi au premier dispositif d'une réponse transparente au message de découverte contenant les capacités et l'état du second dispositif.
Selon ces deux modes de réponse, une réponse est toujours envoyée au premier dispositif, ce qui est en accord avec l'obligation de réponse prévue notamment dans le protocole SIP.
En revanche, le contenu à proprement parler de cette réponse est adapté en fonction de l'identifiant du premier dispositif. Ainsi, on peut configurer l'entité de traitement, via des règles de sélection appropriées, pour envoyer au premier dispositif :
— une réponse transparente, c'est-à-dire qui reflète et/ou contient l'ensemble des capacités et l'état réel du second dispositif, lorsque par exemple cet identifiant vérifie un critère prédéterminé ; et
— une réponse partielle (c'est-à-dire incomplète dans le sens où elle n'identifie qu'une partie seulement des capacités du second dispositif ou elle ne reflète que son état), prédéfinie ou contenant des informations erronées, lorsque l'identifiant ne vérifie pas ce critère
L'envoi systématique d'une réponse au premier dispositif, qu'elle soit transparente ou non, permet d'éviter l'émission par le premier dispositif de messages de retransmission, du fait de la non réception d'un message de réponse au message de découverte. On préserve ainsi la charge du réseau, tout en contrôlant les informations envoyées au premier dispositif sur l'état et les capacités du second dispositif.
En variante, on peut envisager que l'ensemble prédéfini contienne au moins :
— un mode de réponse comprenant un envoi au premier dispositif d'une réponse transparente au message de découverte contenant les capacités et l'état du second dispositif ; et
— un mode de réponse comprenant l'absence de réponse au message de découverte.
La prévision d'un mode de réponse dans lequel aucune réponse n'est envoyée au premier dispositif peut présenter un avantage en termes de facturation pour l'utilisateur du second dispositif. En effet, outre la divulgation d'informations « privées » concernant le second dispositif, le mécanisme d'auto-découverte prévu aujourd'hui par la norme SIP pose également le problème de la facturation de l'envoi d'un message de réponse au premier dispositif, et du coût que cela peut représenter au global pour le second dispositif de répondre à l'ensemble des messages SIP OPTIONS qu'il reçoit.
Plus précisément, le coût associé à l'envoi d'un message de réponse à un message SIP OPTIONS incombe naturellement au second dispositif (tout du moins, il est comptabilisé dans le débit en liaison montante auquel l'utilisateur du second dispositif peut prétendre compte tenu de son abonnement auprès de l'opérateur du réseau). L'invention permet donc à l'utilisateur du second dispositif de sélectionner les dispositifs auxquels il souhaite répondre et de limiter par ce biais, les coûts associés.
Il convient de noter que l'invention s'applique de façon ciblée aux messages de découverte des capacités et de l'état du distant, et non à l'ensemble des messages destinés au second dispositif. L'invention vise en effet à protéger l'utilisateur du second dispositif contre une atteinte à des informations privées concernant le second dispositif requises via des messages reçus à l'insu de l'utilisateur, et auxquels le second dispositif est tenu de répondre conformément à la norme. L'invention ne s'intéresse pas à proprement parler au traitement d'autres types de messages que des messages de découverte de l'état et des capacités du distant.
Dans un mode particulier de réalisation, le message de découverte traité par l'entité de traitement est un message SIP OPTIONS et le champ de ce message contenant l'identifiant du premier dispositif est un champ FROM ou un champ P-Asserted-Identity (en cas notamment de masquage de l'identifiant du premier dispositif)-
Comme évoqué précédemment, le choix du mode de réponse au message de découverte peut être réalisé en fonction de différents critères portant sur tout ou partie de l'identifiant du premier dispositif (typiquement sur tout ou partie du contenu du champ FROM ou P- Asserted-Identity pour un message SIP OPTIONS) et en fonction de différentes règles de sélection prédéterminés.
Ainsi, par exemple, l'entité de traitement peut sélectionner un mode de réponse parmi l'ensemble prédéfini en fonction de la présence ou non de l'identifiant du premier dispositif dans au moins une liste prédéfinie d'identifiants associée au second dispositif.
Cette liste peut être définie notamment par l'utilisateur du second dispositif, en fonction des dispositifs auquel il accepte d'envoyer des informations concernant l'état et les capacités de son dispositif.
Il peut s'agir aussi bien d'une liste contenant les identifiants des dispositifs admis par l'utilisateur, qu'au contraire d'une liste « noire » contenant les identifiants des dispositifs auxquels l'utilisateur ne souhaite pas communiquer l'état et les capacités de son dispositif.
On peut également envisager de définir une liste d'identifiants de dispositifs auxquels l'utilisateur ne souhaite communiquer qu'une partie de ses capacités ou son état seulement. Dans un mode particulier de réalisation, cette liste prédéfinie d'identifiants associée au second dispositif peut prendre la forme d'un répertoire associé au second dispositif, stocké en local sur le second dispositif ou au contraire sur un équipement distant, dans le cœur de réseau IP multimédia (sur un serveur d'application ou dans un système d'information de l'opérateur du cœur de réseau) ou dans un autre réseau (ex. sur une passerelle d'accès au cœur de réseau IP multimédia, ou sur un équipement tel un terminal connecté à un réseau local auquel est connecté également le second dispositif, etc.).
Cette variante permet de simplifier la mise en œuvre de l'invention en utilisant une liste déjà disponible pour d'autres applications (pas de configuration préalable de la liste requise).
En outre, elle se base sur des identifiants déjà connus du second dispositif correspondant à des dispositifs avec lesquels a priori l'utilisateur du second dispositif a, à un moment ou à un autre, accepté de communiquer.
Dans un autre mode de réalisation, l'entité de traitement sélectionne un mode de réponse parmi l'ensemble prédéfini en fonction de l'appartenance ou non de l'identifiant du premier dispositif à un domaine de réseau identique au domaine de réseau du second dispositif ou à un domaine de réseau autorisé.
Ce mode de réalisation permet de prendre en compte des paramètres réseau pour le filtrage des messages de découverte.
Il présente une application privilégiée pour filtrer par exemple les messages de découverte en provenance de pays étrangers (ex. en filtrant tous les identifiants ayant une extension différente de l'extension « .fr » relative aux domaines de réseau français) ou de réseaux opérés par d'autres opérateurs que celui du cœur de réseau IP multimédia gérant le second dispositif, pour des raisons de facturation notamment.
Dans un autre mode de réalisation, l'entité de traitement sélectionne un mode de réponse parmi l'ensemble prédéfini selon si l'identifiant du premier dispositif comprend ou non une partie utilisateur prédéterminée ou d'un type prédéterminé (tel qu'un préfixe de numéro international ou une URI particulière par exemple).
Par « partie utilisateur » on entend la partie de l'identifiant qui est propre à l'utilisateur du premier dispositif, c'est-à-dire qui identifie l'utilisateur du premier dispositif et ne correspond pas au domaine ou au réseau gérant celui-ci. Par exemple, pour un identifiant sous la forme d'une adresse de type « nom_user@nom_de_domaine », cette partie utilisateur correspond à l'élément « nom_user » situé à gauche du symbole « @ ».
Pour un message SIP OPTIONS, la partie utilisateur de l'identifiant correspond à la partie « User-Part » du contenu du champ FROM ou P-Asserted-Identity.
Bien entendu, l'invention ne se limite pas à un critère de filtrage ou à une règle de sélection en particulier, et plusieurs critères de filtrage peuvent être appliqués simultanément ou successivement pour sélectionner le mode de réponse. En outre, d'autres critères de filtrage que ceux évoqués précédemment, portant sur tout ou partie de l'identifiant du premier dispositif peuvent être envisagés, en combinaison ou indépendamment les uns des autres.
Dans un mode de réalisation dans lequel l'ensemble prédéfini contient au moins un mode de réponse où une réponse au message de découverte est envoyée au premier dispositif, cette réponse (i.e. son contenu) dépend d'un nombre et/ou d'un type de sessions en cours pour le second dispositif lors de la réception du message.
On peut ainsi adapter la réponse envoyée au premier dispositif en fonction de l'existence par exemple d'un dialogue en cours avec le premier dispositif. Dans un tel contexte, il est en effet moins gênant d'envoyer une réponse transparente au premier dispositif puisque celui- ci entretient déjà une communication avec le second dispositif. Ceci peut au contraire faciliter l'accès au service multimédia dans le cadre duquel le message de découverte a été envoyé par le premier dispositif.
Par ailleurs, il peut s'avérer utile d'indiquer au premier dispositif l'état des sessions en cours au niveau du second dispositif pour que le premier dispositif puisse adapter le cas échéant ses échanges avec le second dispositif.
Le traitement des messages de découverte conformément à l'invention peut être mis en œuvre à différents niveaux.
Ainsi, l'entité de traitement peut être intégrée notamment dans le second dispositif. Ceci facilite la configuration du filtrage permis par l'invention (des critères de filtrage et de règles de sélection notamment) par l'utilisateur du second dispositif.
En variante, l'entité de traitement peut être intégrée dans un serveur d'application du cœur de réseau IP multimédia gérant le second dispositif. Ce serveur d'application peut par exemple être déclenché par le cœur de réseau IP multimédia sur réception d'un message de découverte destiné au second dispositif.
Ceci facilite la configuration du filtrage par l'opérateur du cœur de réseau IP multimédia.
Par ailleurs, selon cette variante, il n'est pas nécessaire de modifier le mode de fonctionnement actuel des dispositifs recevant les messages de découverte, qui peuvent continuer, conformément à la norme, à répondre de façon transparente aux messages de découverte. Le filtrage est alors réalisé par le serveur d'application du cœur de réseau IP multimédia sur réception des réponses de ces dispositifs.
L'invention vise donc également un terminal géré par un cœur de réseau IP multimédia et comprenant une entité de traitement selon l'invention d'un message reçu en provenance d'un dispositif et destiné au terminal.
L'invention vise aussi un serveur associé à un cœur de réseau IP multimédia gérant un dispositif, ce serveur comprenant une entité de traitement selon l'invention, d'un message reçu destiné au dispositif. Ce serveur est par exemple un serveur d'application du cœur de réseau IP multimédia.
Il peut s'agir en variante du dispositif auquel est destiné le message reçu.
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 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.
Selon un autre aspect, l'invention vise également un système de communication comprenant :
— un premier dispositif et un second dispositif géré par un cœur de réseau IP multimédia, le premier dispositif étant adapté à émettre, à destination du second dispositif, un message de découverte des capacités et de l'état du second dispositif ; et
— une entité de traitement selon l'invention apte à recevoir et à traiter le message de découverte émis par le premier dispositif à destination du second dispositif.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de traitement, l'entité de traitement et le système de communication 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 des exemples de réalisation dépourvus de tout caractère limitatif :
— la figure 1 illustre, de façon schématique, un système de communication et une entité de traitement conformes à l'invention dans un premier mode 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 ;
— la figure 3 représente les principales étapes d'un procédé de traitement conforme à l'invention mises en œuvre par l'entité de traitement de la figure 1 dans le premier mode de réalisation ;
— la figure 4 illustre, de façon schématique, un système de communication et une entité de traitement conformes à l'invention dans un second mode de réalisation ; et
— la figure 5 représente les principales étapes d'un procédé de traitement conforme à l'invention mises en œuvre par l'entité de traitement de la figure 4 dans le second mode de réalisation.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système de communication 1 conforme à l'invention, incluant deux dispositifs Dl et D2, et une entité de traitement 2 selon l'invention, dans un premier mode de réalisation.
Les dispositifs Dl et D2 sont par exemple des terminaux multimédia, tels que des téléphones mobiles intelligents (ou « smartphones » en anglais), aptes à communiquer entre eux par l'intermédiaire de cœurs de réseau IP multimédia CNl et CN2. Ils disposent chacun d'un répertoire (ou « carnet d'adresse ») local, noté respectivement RL1 et RL2, contenant différents identifiants (ex. numéros de téléphones, adresses SIP, etc.) d'équipements connus et référencés par les utilisateurs respectifs des dispositifs Dl et D2 (et/ou par les opérateurs des cœurs de réseau CNl et CN2).
Les cœurs de réseau CNl et CN2 sont ici des cœurs de réseau utilisant la technologie « voix sur IP » et gérant respectivement les dispositifs Dl et D2. Ils 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.
Toutefois, en variante, l'invention s'applique également lorsque les cœurs de réseau CNl et CN2 ne forment qu'un seul cœur de réseau IP multimédia. Elle s'applique aussi à d'autres types de dispositifs (par exemple Dl peut être un terminal et D2 un serveur), à d'autres architectures de cœur de réseau IP multimédia, ainsi qu'à 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 de l'état du distant. Dans l'exemple décrit ici, on envisage le traitement par l'entité de traitement 2 d'un message reçu MOPT de découverte des capacités et de l'état du distant émis par le premier dispositif Dl à destination du second dispositif D2, dans le cadre d'un service de communication multimédia tel que par exemple un service RCS-e. On suppose que les dispositifs Dl et D2 sont enregistrés auprès de leurs cœurs de réseau respectifs CN1 et CN2.
Le message MOPT émis par le dispositif Dl est un message SIP OPTIONS, tel que décrit de façon détaillée dans le document RFC 3261 cité précédemment. Il contient dans un champ FROM, un identifiant ID1 du dispositif Dl à l'origine du message, et dans un champ Request-URI et dans un champ TO, un identifiant ID2 du dispositif D2 destinataire du message.
On suppose que l'utilisateur du dispositif D2 a souscrit, auprès de l'opérateur du cœur de réseau CN2, à l'activation d'un service de filtrage des messages SIP OPTIONS lui étant destinés en fonction des identifiants des dispositifs à l'origine de ces messages et reposant sur la mise en œuvre du procédé de traitement selon l'invention.
L'activation du service de filtrage des messages SIP OPTIONS pour le dispositif D2 est mémorisée dans un profil de l'utilisateur du dispositif D2 stocké au niveau du serveur d'abonnés HSS (Home Subscriber Server)) du cœur de réseau multimédia CN2 (non représenté sur la figure 1).
Dans le premier mode de réalisation illustré à la figure 1, l'entité de traitement 2 des messages SIP OPTIONS selon l'invention est intégrée dans un serveur d'application (ou AS pour « Application Server » en anglais) du cœur de réseau CN2, déclenché sur détection d'un message SIP OPTIONS à destination du dispositif D2. Autrement dit, le serveur d'application 2 est une entité de traitement au sens de l'invention.
Le déclenchement du serveur d'application 2 est activé conformément aux informations (et notamment aux iFC ou Initial Filter Criteria) contenues dans le profil utilisateur de l'utilisateur du dispositif D2 stocké dans le serveur HSS du cœur de réseau CN2, renseignées lors de la souscription de l'utilisation à l'activation du service de filtrage. Le serveur d'application 2 peut être un serveur dédié à la mise en œuvre du procédé de traitement des messages SIP OPTIONS selon l'invention ou un serveur d'application déjà existant et déclenché lors de la mise en œuvre d'autres applications.
Les mécanismes mis en œuvre pour la détection des messages SIP OPTIONS à destination du dispositif D2 et pour le déclenchement du serveur d'application 2 sont connus de l'homme du métier ; ils ne seront donc pas décrits plus en détail ici.
Le serveur d'application 2 est par exemple déclenché par un serveur S-CSCF (Serving Call Session Control Function) du cœur de réseau CN2 ou par un autre serveur situé en aval de ce serveur S-CSCF, après avoir détecté que le message MOPT reçu en provenance du dispositif Dl est un message SIP OPTIONS destiné à un dispositif D2 (identifié notamment grâce au champ « Request URI » ou « To » du message reçu MOPT), ayant activé le service de filtrage conformément à l'invention des messages SIP OPTIONS lui étant destinés. Le serveur d'application 2 dispose ici de l'architecture matérielle d'un ordinateur telle qu'illustrée schématiquement à la figure 2.
Il comporte notamment un processeur 2A, une mémoire vive 2B, une mémoire morte 2C, une mémoire flash non volatile 2D ainsi que des moyens de communication 2E mettant en œuvre notamment le protocole SIP. Ces moyens de communication lui permettent de communiquer avec les entités du cœur de réseau CN2 et avec le dispositif D2.
La mémoire morte 2C du serveur d'application 2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 2A 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 le premier mode de réalisation de l'invention, décrites maintenant en référence à la figure 3.
La figure 3 illustre les principales étapes d'un procédé de traitement selon l'invention, mises en œuvre par le serveur d'application 2 de la figure 1 conformément au premier mode de réalisation, après son déclenchement suite à la réception par le cœur de réseau CN2 du message SIP OPTIONS MOPT émis par le dispositif Dl à destination du dispositif D2.
Comme décrit précédemment, le traitement proposé par l'invention consiste à filtrer les messages de découverte (tels que les messages OPTIONS pour le protocole SIP) en fonction des identifiants des dispositifs à l'origine de ces messages, et à sélectionner un mode de réponse parmi un ensemble prédéfini de modes de réponse contenant au moins deux modes de réponse en fonction de ces identifiants.
La mise en œuvre de ce traitement s'appuie ici sur une définition préalable de trois ensembles, à savoir :
(1) d'un ensemble de modes de réponse possibles aux messages de découverte reçus, noté Ω ;
(2) d'un ensemble, noté C, composé d'un ou de plusieurs critères avec lesquels vont être comparés les identifiants des dispositifs à l'origine de ces messages de découverte (ces critères peuvent porter sur tout ou partie des identifiants) ; et
(3) d'un ensemble, noté S, de règles de sélection destinées à associer à un identifiant d'un dispositif à l'origine d'un message de découverte, un mode de réponse de l'ensemble Ω, lorsque l'identifiant vérifie un ou plusieurs critères déterminés de l'ensemble C.
Ainsi à titre illustratif, les modes de réponse suivants peuvent être envisagés dans l'ensemble Ω :
— absence de réponse au message de découverte ;
— envoi d'une réponse transparente au message de découverte, c'est-à-dire, contenant l'état et les capacités du dispositif interrogé (i.e. D2 ici), comme défini actuellement dans la norme SIP ;
— envoi d'une réponse partielle au message de découverte, constituée par exemple d'un message reflétant un état du dispositif interrogé sans inclure ses capacités, d'un message reflétant un état du dispositif interrogé et seulement une partie de ses capacités, ou encore d'un message prédéfini ne contenant que ses capacités ;
— envoi d'une réponse prédéfinie au message de découverte, constituée par exemple pour le protocole SIP, d'un message « 404 NOT FOUND », « 480 TEMPORARILY UNAVAILABLE », « 408 TIME OUT », « 200 OK » ou « 486 BUSY HERE » ;
— envoi d'une réponse erronée au message de découverte, reflétant par exemple un état distinct de l'état réel du dispositif interrogé et/ou des capacités ne correspondant pas aux capacités du dispositif interrogé.
De façon similaire, les critères suivants, portant sur tout ou partie de l'identifiant du dispositif à l'origine du message de découverte, peuvent être envisagés dans l'ensemble C :
— présence ou non de l'identifiant du dispositif à l'origine du message de découverte dans une liste prédéfinie associée au dispositif interrogé. Cette liste peut être notamment un répertoire (ou « carnet d'adresses ») local stocké sur le dispositif interrogé ou stocké sur un équipement distant dans un réseau (par exemple, dans le cœur de réseau IP multimédia CN2, au niveau du serveur d'application 2 ou dans un système d'information de l'opérateur réseau du dispositif
D2, etc.). Il peut s'agir, en variante, d'une liste d'identifiants de dispositifs autorisés à recevoir l'état et les capacités réels du dispositif interrogé, stockée par exemple au niveau du serveur d'application 2 ou dans un système d'information de l'opérateur réseau du dispositif D2 pouvant être consultée par le serveur d'application 2, et configurée par l'utilisateur du dispositif interrogé. Il peut s'agir, dans une autre variante, d'une liste configurée par l'utilisateur d'identifiants « interdits » auxquels l'utilisateur refuse de communiquer l'état et les capacités de son dispositif, stockée par exemple au niveau du serveur d'application 2 ou dans un système d'information de l'opérateur réseau du dispositif D2 pouvant être consultée par le serveur d'application 2 ;
— appartenance ou non de l'identifiant du dispositif à l'origine du message de découverte à un domaine de réseau identique au domaine de réseau du dispositif interrogé ou à un domaine autorisé (par l'opérateur du cœur de réseau ou par l'utilisateur du dispositif interrogé) ;
— présence ou non dans l'identifiant du dispositif à l'origine du message de découverte d'une partie utilisateur prédéterminée (i.e. partie « User Part » de l'identifiant pour un message SIP OPTIONS) ou d'un type prédéterminé (ex. contenant un numéro international différent du préfixe « +33 », ou un préfixe spécifique tels que « +331 »-« +335 », « +338 » ou « +339 », ou correspondant à un type d'URI (Uniform Request Identifier) particulier tel qu'une SIP URI ou une TEL URI) ;
— etc.
Enfin, on peut envisager les règles de sélection suivantes dans l'ensemble S :
— si l'identifiant du dispositif à l'origine du message de découverte n'est pas présent dans le répertoire local du dispositif interrogé, on sélectionne le mode de réponse « absence de réponse au message de découverte » ; — si l'identifiant du dispositif à l'origine du message de découverte est présent dans le répertoire local du dispositif interrogé, on sélectionne le mode de réponse « envoi d'une réponse transparente au message de découverte » ;
— etc.
Bien entendu, ces exemples ne sont donnés qu'à titre illustratif et d'autres modes de réponse, d'autres critères portant sur tout ou partie des identifiants ainsi que d'autres règles de sélection peuvent être envisagés dans le cadre de l'invention.
Notamment on peut également définir des règles de sélection s'appuyant sur une pluralité de critères (ex. si l'identifiant du dispositif à l'origine du message de découverte est dans le même domaine réseau que l'identifiant du dispositif interrogé et dans le répertoire local du dispositif interrogé, alors on sélectionne le mode de réponse consistant à envoyer une réponse transparente au dispositif à l'origine du message de découverte).
Par ailleurs, on peut envisager également d'autres modes de réponse dans lesquels le contenu de la réponse dépend de paramètres tels que l'état du dispositif D2 et notamment le nombre de sessions déjà en cours au niveau du dispositif D2 et/ou du type de sessions déjà en cours (en fonction par exemple des services disponibles ou au contraire utilisés).
Pour illustrer les étapes mises en œuvre par le serveur d'application 2 lors du traitement du message MOPT, on suppose que les ensembles Ω, S et C suivants ont été définis :
— l'ensemble Ω de modes de réponse contient deux modes de réponse à savoir :
o Mode Ml : « réponse transparente au message de découverte »
o Mode M2 : « réponse partielle au message de découverte ne contenant que l'état du dispositif interrogé »
— l'ensemble C des critères contient un seul critère, à savoir : présence ou non de l'identifiant dans le répertoire local du dispositif interrogé ; et
— l'ensemble S des règles de sélection contient deux règles, à savoir :
o si l'identifiant est présent dans le répertoire local, alors on répond selon le mode Ml ; o sinon on répond selon le mode M2.
Ces ensembles sont stockés dans la mémoire flash 2D du serveur d'application 2 lors d'une étape préalable de configuration (étape EO). Il convient de noter que le choix des ensembles Ω, S et C, peut être réalisé par l'utilisateur du dispositif D2 lui-même, par exemple par l'intermédiaire d'une interface web, vocale ou textuelle, etc.
Nous allons maintenant décrire le traitement du message MOPT réalisé conformément à l'invention par le serveur d'application 2, suite à son déclenchement sur détection d'un message SIP OPTIONS à destination du dispositif D2.
Le déclenchement du serveur d'application 2 se traduit par la réception par le serveur d'application 2, du message MOPT (étape E10). Le serveur d'application 2 extrait du champ FROM du message MOPT reçu, un identifiant du dispositif Dl (étape E20). L'identifiant du dispositif Dl contenu dans le champ FROM est ici l'identifiant ID1.
Si le champ FROM ne contient pas d'identifiant du dispositif Dl ou reflète un anonymat du dispositif Dl (par exemple parce que l'identifiant du dispositif Dl a été masqué à l'émission par le dispositif Dl), le serveur d'application 2 détermine si le message MOPT contient un champ SIP PRIVACY.
Le cas échéant, il détermine ensuite, s'il existe dans le message MOPT un champ P- Asserted-Identity contenant un identifiant certifié du dispositif Dl et susceptible d'avoir été introduit et/ou renseigné par le cœur de réseau CN1 traversé par le message MOPT suite à émission par le dispositif Dl.
En effet, de façon connue en soi, les réseaux par lesquels transite un message émis par un dispositif à destination d'un autre dispositif, peuvent insérer, pour répondre à différents besoins (ex. facturation, routage du message, interceptions légales, etc.), un identifiant certifié du dispositif à l'origine du message. Cet identifiant est inséré ici par le cœur de réseau CN1 dans le champ P-Asserted-Identity du message.
Le cas échéant, le serveur d'application 2 extrait l'identifiant du dispositif Dl contenu dans ce champ P-Asserted-Identity.
Puis il détermine si l'identifiant ID1 du dispositif Dl extrait du message MOPT vérifie le ou les critères de filtrage définis dans l'ensemble C, stocké(s) dans la mémoire 2D (étape E30).
Dans l'exemple envisagé ici, un seul critère est stocké dans la mémoire 2D, à savoir le critère « présence ou non de l'identifiant du dispositif à l'origine du message SIP OPTIONS dans le répertoire local du dispositif interrogé ».
Ainsi, au cours de l'étape E30, le serveur d'application 2 examine si l'identifiant ID1 du dispositif Dl est présent (i.e. référencé) dans le répertoire local RL2 du dispositif D2.
Le cas échéant (réponse oui au test E40), conformément aux règles de sélection définies dans l'ensemble S, le serveur d'application 2 sélectionne le mode de réponse Ml (étape E50).
Autrement dit, il envoie au dispositif Dl une réponse transparente au message SIP OPTIONS contenant l'état du dispositif D2 ainsi que ses capacités (étape E60).
Dans le mode de réalisation décrit ici, l'état du dispositif D2 et ses capacités sont obtenues par le serveur d'application 2 directement du dispositif D2.
Plus précisément, en cas de réponse oui au test E40, le serveur d'application 2 prolonge (i.e. relaie) le message SIP OPTIONS MOPT vers le second dispositif D2, sans en changer son contenu.
Le dispositif D2 répond alors au message SIP OPTIONS de manière transparente, conformément au protocole SIP, c'est-à-dire en fournissant son état et ses capacités. La réponse du dispositif D2 emprunte le chemin inverse du message MOPT, conformément au mode de fonctionnement du protocole SIP. Cette réponse transite donc par le serveur d'application 2.
Celui intercepte le message de réponse provenant du dispositif D2 et élabore, à l'aide de ce message, sa réponse transparente au dispositif Dl contenant l'état du dispositif D2 et ses capacités conformément au mode de réponse Ml sélectionné.
Dans le mode de réalisation décrit ici, la réponse transparente envoyée par le serveur d'application 2 au dispositif Dl est similaire ou identique au message de réponse au message SIP OPTIONS prévu dans le document RFC 3261 de la norme SIP (même format et même contenu en ce qui concerne l'état et les capacités du dispositif D2).
En revanche, si l'identifiant ID1 n'est pas contenu dans le répertoire local RL2 du dispositif D2 (réponse non au test E40), le serveur d'application 2 sélectionne, conformément aux règles de sélection définies dans l'ensemble S, le mode de réponse M2 (étape E70).
Autrement dit, il envoie au dispositif Dl une réponse partielle au dispositif Dl contenant seulement un état du dispositif D2 (étape E80). Cette réponse partielle ne contient pas d'informations sur les capacités du dispositif D2.
Comme mentionné précédemment pour l'étape E60, l'information concernant l'état du dispositif D2 est obtenue par le serveur d'application 2 en interrogeant le dispositif D2, en lui transmettant ici le message SIP OPTIONS MOPT reçu.
Il convient de noter que si l'on envisage (et sélectionne) un mode de réponse selon lequel le serveur d'application 2 répond de façon erronée au dispositif Dl ou selon un message prédéterminé tel qu'un message « 404 NOT FOUND » ou « 480 TEMPORARILY UNAVAILABLE » ou encore « 408 TIME OUT », le serveur d'application 2 peut s'abstenir de consulter le dispositif D2 pour obtenir son état et ses capacités, et répondre directement au dispositif Dl.
En revanche, dès lors qu'un mode de réponse incluant un état réel du dispositif D2 et/ou ses capacités réelles est sélectionné, le serveur d'application 2 transmet au dispositif D2 le message SIP OPTIONS MOPT reçu en provenance du dispositif Dl, de façon transparente (i.e. sans en changer le contenu), puis il filtre et/ou adapte la réponse reçu du dispositif D2 au message SIP OPTIONS en fonction des règles de réponse configurées pour le mode de réponse sélectionné.
Ainsi, par exemple si le serveur d'application 2 détermine que le dispositif D2 est dans un état occupé, il envoie un message de réponse « 486 BUSY HERE » au dispositif Dl dans lequel aucune information sur les capacités du dispositif D2 n'est présente.
Dans le premier mode de réalisation précédemment décrit, le traitement conformément à l'invention du message SIP OPTIONS MOPT destiné au dispositif D2 est mis en œuvre par un serveur d'application 2 du cœur de réseau IP multimédia CN2. Autrement dit, l'entité de traitement de l'invention est le serveur d'application 2.
Toutefois, cette hypothèse n'est pas limitative, et l'entité de traitement des messages de découverte de l'état et des capacités du distant conformément à l'invention peut être intégrée dans d'autres équipements, comme notamment dans le dispositif destinataire du message de découverte.
La figure 4 représente, dans son environnement, un système de communication conforme à l'invention dans un second mode de réalisation.
Le système de communication inclut deux dispositifs Dl' et D2' gérés respectivement par un cœur de réseau IP multimédia CN1' et par un cœur de réseau IP multimédia CN2'. Les dispositifs Dl' et D2' sont ici des terminaux munis de répertoires locaux, notés respectivement RL1' et RL2'.
Dans ce second mode de réalisation, le traitement conformément à l'invention d'un message de découverte MOPT' envoyé par le dispositif Dl' à destination du dispositif D2' est mis en œuvre par le dispositif D2' lui-même. Autrement dit, le dispositif D2' est une entité de traitement au sens de l'invention.
Les dispositifs Dl', et les cœurs de réseau IP multimédia CN1' et CN2' sont similaires ou identiques aux dispositifs Dl et aux cœurs de réseau CN1 et CN2 décrits en référence à la figure 1, et ne sont pas décrits de nouveau en détails ici.
Le dispositif D2' est similaire au dispositif D2 de la figure 1. Il diffère toutefois du dispositif D2 en ce qu'il comporte une mémoire morte 3 sur laquelle est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de traitement conformément au second mode de réalisation de l'invention. Cette mémoire morte 3 constitue un support d'enregistrement conforme à l'invention, lisible par un processeur du dispositif D2'.
Nous allons maintenant décrire, en référence à la figure 5, les principales étapes mises en œuvre par le dispositif D2' dans ce second mode de réalisation pour le traitement d'un message MOPT' de découverte de l'état et des capacités du distant, émis par le dispositif Dl' à destination du dispositif D2'.
Le message MOPT' est ici un message SIP OPTIONS, tel que décrit de façon détaillée dans le document RFC 3261. Il contient dans un champ FROM, un identifiant ID1' du dispositif Dl' à l'origine du message, et dans un champ Request-URI et dans un champ TO, un identifiant ID2' du dispositif D2' destinataire du message.
Pour illustrer les étapes mises en œuvre par le dispositif D2' lors du traitement du message MOPT', on se base sur les ensembles Ω, S et C précédemment définis. Ainsi :
— l'ensemble Ω de modes de réponse contient deux modes de réponse, à savoir :
o Mode Ml : « réponse transparente au message de découverte »
o Mode M2 : « réponse partielle au message de découverte ne contenant que l'état du dispositif interrogé »
— l'ensemble C des critères contient un seul critère, à savoir : présence ou non de l'identifiant dans le répertoire local du dispositif interrogé ; et
— l'ensemble S des règles de sélection contient deux règles, à savoir : o si l'identifiant est présent dans le répertoire local, alors on répond selon le mode Ml ; o sinon on répond selon le mode M2.
Ces ensembles sont stockés dans une mémoire flash non volatile du dispositif D2' lors d'une étape préalable de configuration (étape F0). Il convient de noter que la configuration du dispositif D2' et plus précisément le choix des ensembles Ω, S et C, peuvent être réalisés par l'utilisateur du dispositif D2' lui-même, par exemple par l'intermédiaire d'une interface web, vocale ou textuelle, etc.
Le message MOPT' émis par le dispositif Dl' à destination du dispositif D2' est reçu par le dispositif D2' après avoir transité par les cœurs de réseau CN1' et CN2' (étape F10).
Sur réception du message MOPT', le dispositif D2' détermine dans un premier temps s'il s'agit d'un message de découverte de son état et de ses capacités, autrement dit ici s'il s'agit d'un message SIP OPTIONS qu'il doit traiter conformément à l'invention (étape F20).
S'il ne s'agit pas d'un message SIP OPTIONS (réponse non à l'étape F20), le dispositif D2' traite ce message classiquement, comme prévu par le protocole SIP, en fonction du type de ce message (étape F30).
Si le message reçu MOPT' est un message SIP OPTIONS (réponse oui à l'étape F20), le dispositif D2' traite ce message conformément à l'invention.
Ainsi :
— il extrait du champ FROM ou du champ P-Asserted-ID du message MOPT' reçu l'identifiant ID1' du dispositif Dl' (étape F40) ;
— il détermine si cet identifiant ID1' vérifie le ou les critères de filtrage définis dans l'ensemble C, stocké(s) dans sa mémoire flash non volatile (étape F50) : autrement dit ici, il vérifie ici si l'identifiant ID1' est présent ou non dans le répertoire local RL2' du dispositif D2' ;
— il sélectionne, le cas échéant (réponse oui à l'étape test F60), le mode de réponse Ml (étape F70), et envoie au dispositif Dl' une réponse transparente au message SIP OPTIONS MOPT' contenant son état et ses capacités « réels » (étape F80) ;
— sinon (réponse non à l'étape test F60), il sélectionne le mode de réponse M2 (étape F90) et envoie au dispositif Dl' une réponse partielle au message SIP OPTIONS MOPT' contenant uniquement son état mais n'identifiant pas ses capacités (étape F100).
Les étapes F40, F50, F60, F70 et F90 étant identiques aux étapes E20, E30, E40, E50 et E70, elles ne seront pas décrites plus en détails ici. Les étapes F80 et F100 diffèrent des étapes E60 et E80 respectivement, en ce que le dispositif D2' élabore directement la réponse au message SIP OPTIONS MOPT' à partir de son état et/ou de ses capacités.
Dans les deux modes de réalisation décrits ici, le traitement du message SIP OPTIONS conformément à l'invention est réalisé indépendamment de l'existence ou non d'un dialogue entre les dispositifs Dl et D2, respectivement entre les dispositifs Dl' et D2'.
En variante, on peut envisager de ne traiter les messages SIP OPTIONS conformément à l'invention que lorsque ceux-ci sont émis dans le cadre d'une transaction autonome ou transaction « standalone » entre les dispositifs, c'est-à-dire, qui n'est pas réalisée dans le cadre d'un dialogue établi entre les dispositifs ou qui n'initie pas un tel dialogue. L'invention présente en effet un avantage supplémentaire dans un tel contexte, car le dispositif destinataire du message de découverte n'a pas déjà donné son accord pour une communication avec le dispositif à l'origine du message de découverte.

Claims

REVENDICATIONS
1. Procédé de traitement d'un message reçu (MOPT, MOPT') en provenance d'un premier dispositif (Dl, Dl') et destiné à un second dispositif (D2, D2') géré par un cœur de réseau (CN2,CN2') IP multimédia, ledit procédé étant destiné à être mis en œuvre par une entité de traitement (2, D2') lorsque ledit message reçu (MOPT, MOPT') est un message de découverte des capacités et de l'état du second dispositif (D2, D2'), et comprenant :
— une étape d'obtention (E20, F40) d'un identifiant (ID1, ID1') du premier dispositif (Dl, Dl') à partir d'un champ du message de découverte reçu (MOPT, MOPT') ; et
— une étape de sélection (E50, E70, F70, F90), en fonction de cet identifiant (ID1, ID1'), d'un mode de réponse (Ml, M2) au message de découverte reçu parmi un ensemble prédéfini (Ω) contenant au moins deux modes de réponse (Ml, M2).
2. Procédé de traitement selon la revendication 1 dans lequel ledit ensemble prédéfini (Ω) contient au moins :
— un mode de réponse (M2) comprenant un envoi au premier dispositif d'une réponse partielle, prédéfinie ou erronée au message de découverte ; et
— un mode de réponse (Ml) comprenant un envoi au premier dispositif d'une réponse transparente au message de découverte contenant les capacités et l'état du second dispositif.
3. Procédé de traitement selon la revendication 1 dans lequel ledit ensemble prédéfini (Ω) contient au moins :
— un mode de réponse comprenant un envoi au premier dispositif d'une réponse transparente au message de découverte contenant les capacités et l'état du second dispositif ; et
— un mode de réponse comprenant l'absence de réponse au message de découverte.
4. Procédé de traitement selon la revendication 1 dans lequel le message de découverte (MOPT, MOPT') est un message SIP OPTIONS et le champ de ce message contenant l'identifiant du premier dispositif est un champ FROM ou un champ P-Asserted-Identity.
5. Procédé de traitement selon la revendication 1 dans lequel l'entité de traitement (2, D2') sélectionne un mode de réponse parmi l'ensemble prédéfini (Ω) en fonction de la présence ou non de l'identifiant du premier dispositif dans au moins une liste prédéfinie d'identifiants associée au second dispositif.
6. Procédé de traitement selon la revendication 5 dans lequel ladite liste prédéfinie est un répertoire (RL2, RL2') stocké sur le second dispositif (D2, D2') ou sur un équipement distant.
7. Procédé de traitement selon la revendication 1 dans lequel l'entité de traitement (2, D2') sélectionne un mode de réponse parmi l'ensemble prédéfini (Ω) en fonction de l'appartenance ou non de l'identifiant du premier dispositif à un domaine de réseau identique au domaine de réseau du second dispositif ou à un domaine de réseau autorisé.
8. Procédé de traitement selon la revendication 1 dans lequel l'entité de traitement (2, D2') sélectionne un mode de réponse parmi l'ensemble prédéfini (Ω) selon si l'identifiant du premier dispositif comprend ou non une partie utilisateur prédéterminée ou d'un type prédéterminé.
9. Procédé de traitement selon la revendication 2 dans lequel la réponse envoyée au premier dispositif (Dl) dépend en outre d'un nombre et/ou d'un type de sessions en cours pour le second dispositif lors de la réception du message.
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de traitement selon la revendication 1 lorsque ledit programme est exécuté par un ordinateur.
11. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de traitement selon la revendication 1.
12. Entité de traitement (2, D2') d'un message reçu (MOPT, MOPT') en provenance d'un premier dispositif (Dl, Dl') et destiné à un second dispositif (D2, D2') géré par un cœur de réseau (CN2) IP multimédia, comprenant des moyens, activés si le message reçu (MOPT, MOPT') est un message de découverte des capacités et de l'état du second dispositif, comprenant :
— des moyens d'obtention d'un identifiant (ID1, ID1') du premier dispositif (Dl, Dl') à partir d'un champ du message de découverte reçu ; et
— des moyens aptes à sélectionner, en fonction de cet identifiant (ID1, ID1'), un mode de réponse (Ml, M2) audit message de découverte reçu (MOPT, MOPT') parmi un ensemble prédéfini (Ω) contenant au moins deux modes de réponse (Ml, M2).
13. Terminal (D2') géré par un cœur de réseau IP multimédia (CN2') et comprenant une entité de traitement selon la revendication 12, d'un message reçu en provenance d'un dispositif et destiné audit terminal.
14. Serveur (2) associé à un cœur de réseau (CN2) IP multimédia gérant un dispositif (D2), ledit serveur comprenant une entité de traitement selon la revendication 12, d'un message reçu destiné audit dispositif (D2).
15. Système de communication (1, ) comprenant :
— un premier dispositif (Dl, Dl') et un second dispositif (D2, D2') géré par un cœur de réseau (CN2) IP multimédia, le premier dispositif (Dl, Dl') étant adapté à émettre un message (MOPT, MOPT') de découverte des capacités et de l'état du second dispositif ; et
— une entité de traitement (2, D2') selon la revendication 12 apte à recevoir et à traiter ledit message de découverte (MOPT, MOPT').
PCT/FR2013/051086 2012-05-29 2013-05-17 Procédé et entité de traitement d'un message WO2013178909A1 (fr)

Priority Applications (9)

Application Number Priority Date Filing Date Title
ES13729982T ES2880477T3 (es) 2012-05-29 2013-05-17 Procedimiento y entidad de procesamiento de un mensaje
BR112014029410-0A BR112014029410B1 (pt) 2012-05-29 2013-05-17 Processo e entidade de tratamento de uma mensagem, suporte de registro legível por um computador, terminal, servidor e sistema de comunicação
CN201380034252.XA CN104396213B (zh) 2012-05-29 2013-05-17 用于处理消息的方法和实体
EP13729982.2A EP2856732B1 (fr) 2012-05-29 2013-05-17 Procédé et entité de traitement d'un message
JP2015514553A JP6293740B2 (ja) 2012-05-29 2013-05-17 メッセージを処理するための方法およびエンティティ
RU2014153554A RU2643498C2 (ru) 2012-05-29 2013-05-17 Способ и объект для обработки сообщения
US14/403,131 US10091708B2 (en) 2012-05-29 2013-05-17 Method and an entity for processing a message
KR1020147036750A KR102109099B1 (ko) 2012-05-29 2013-05-17 메시지를 프로세싱하기 위한 방법 및 엔티티
ZA2014/08555A ZA201408555B (en) 2012-05-29 2014-11-20 Method and entity for processing a message

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1254919 2012-05-29
FR1254919A FR2991530A1 (fr) 2012-05-29 2012-05-29 Procede et entite de traitement d'un message

Publications (1)

Publication Number Publication Date
WO2013178909A1 true WO2013178909A1 (fr) 2013-12-05

Family

ID=48656224

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/051086 WO2013178909A1 (fr) 2012-05-29 2013-05-17 Procédé et entité de traitement d'un message

Country Status (11)

Country Link
US (1) US10091708B2 (fr)
EP (1) EP2856732B1 (fr)
JP (1) JP6293740B2 (fr)
KR (1) KR102109099B1 (fr)
CN (1) CN104396213B (fr)
BR (1) BR112014029410B1 (fr)
ES (1) ES2880477T3 (fr)
FR (1) FR2991530A1 (fr)
RU (1) RU2643498C2 (fr)
WO (1) WO2013178909A1 (fr)
ZA (1) ZA201408555B (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160295390A1 (en) * 2013-11-22 2016-10-06 Telefonaktiebolaget L M Ericsson (Publ) Centralised capabiity discovery
EP2975865A1 (fr) * 2014-07-18 2016-01-20 Alcatel Lucent Procédé et serveur pour la mise en oeuvre de découverte de capacité
FR3052006A1 (fr) * 2016-05-31 2017-12-01 Orange Procede de qualification de l'identite d'un terminal appelant
US11902890B2 (en) * 2018-02-03 2024-02-13 Nokia Technologies Oy Application based routing of data packets in multi-access communication networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2205020A1 (fr) * 2008-12-31 2010-07-07 TeliaSonera AB Service de capacité dans un système de communications
WO2010099829A1 (fr) * 2009-03-06 2010-09-10 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'interrogations de capacités dans un réseau de communication

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0110542D0 (en) * 2001-04-30 2001-06-20 Nokia Corp Messaging system
CN100544371C (zh) * 2004-10-11 2009-09-23 华为技术有限公司 在综合业务中实现能力协商的方法
US20060252444A1 (en) * 2005-05-03 2006-11-09 Timucin Ozugur Presence enabled call hunting group
KR100700607B1 (ko) 2005-06-21 2007-03-28 엘지전자 주식회사 단말 능력 버전을 이용한 컴비네이션 서비스 수행 방법 및시스템
WO2006137646A1 (fr) 2005-06-21 2006-12-28 Lg Electronics Inc. Terminal, procede et systeme permettant d'offrir des service combines sur la base d'une version de capacite de terminal
DE602005012608D1 (de) 2005-10-13 2009-03-19 Ericsson Telefon Ab L M Verfahren und vorrichtung zum handhaben von einladungen zu einer mehrbenutzer-kommunikationssitzung
JP4795027B2 (ja) 2006-01-17 2011-10-19 三菱電機株式会社 通信装置及び通信システム
US7805425B2 (en) * 2006-04-28 2010-09-28 Microsoft Corporation Efficient database lookup operations
JP2009033299A (ja) 2007-07-25 2009-02-12 Panasonic Corp 通信の途切れを回避する通信装置、通信方法、及び通信プログラム
CN101217503B (zh) * 2007-12-27 2011-01-26 腾讯科技（深圳）有限公司 即时通讯音视频的能力交换方法、系统和即时通讯系统
US8364145B2 (en) * 2008-01-09 2013-01-29 Mediatek Inc. Methods and devices for dynamic menu update
JP5003961B2 (ja) 2008-01-24 2012-08-22 日本電気株式会社 携帯電話端末の状態通知システム
EP2291963B1 (fr) * 2008-06-23 2016-04-27 BlackBerry Limited Procédé pour fournir des capacités de dispositifs et de serveurs
JP5316164B2 (ja) 2009-03-30 2013-10-16 日本電気株式会社 電子メール配信システム、該システムに用いられる電子メール配信方法及び電子メール配信制御プログラム
CN107070849B (zh) * 2009-05-04 2020-09-22 黑莓有限公司 用于使用sip协议来实现协作会话的控制转移的系统和方法
US20110019650A1 (en) * 2009-07-21 2011-01-27 Sabine Van Niekerk Methods and apparatus for optimization of device capability exchange in a network
EP2323332A1 (fr) 2009-11-06 2011-05-18 Koninklijke KPN N.V. Contrôle d'une session dans un système de fourniture de services
ES2813430T3 (es) * 2011-02-11 2021-03-23 Vodafone Ip Licensing Ltd Método de comunicaciones basado en la capacidad de servicio y la presencia social

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2205020A1 (fr) * 2008-12-31 2010-07-07 TeliaSonera AB Service de capacité dans un système de communications
WO2010099829A1 (fr) * 2009-03-06 2010-09-10 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'interrogations de capacités dans un réseau de communication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"RFC 3261 intitulé", June 2002, IETF, article "SIP: Session Initiation Protocol"
GALLEGO GÓMEZ O. ET AL: "RCS-e - Advanced Communications: Services and Client Specification Version 1.1", 8 April 2011 (2011-04-08), pages 1 - 171, XP002685665, Retrieved from the Internet <URL:http://www.gsma.com/rcs/wp-content/uploads/2012/03/rcsespecv11final.zip> [retrieved on 20121022] *
RCS-E ADVANCED COMMUNICATIONS: SERVICES AND CLIENT SPÉCIFICATION, 8 April 2011 (2011-04-08)

Also Published As

Publication number Publication date
JP2015521011A (ja) 2015-07-23
KR102109099B1 (ko) 2020-05-11
CN104396213A (zh) 2015-03-04
ES2880477T3 (es) 2021-11-24
BR112014029410A2 (pt) 2017-06-27
KR20150023519A (ko) 2015-03-05
ZA201408555B (en) 2016-01-27
US20150131478A1 (en) 2015-05-14
EP2856732A1 (fr) 2015-04-08
RU2643498C2 (ru) 2018-02-01
US10091708B2 (en) 2018-10-02
EP2856732B1 (fr) 2021-04-28
FR2991530A1 (fr) 2013-12-06
CN104396213B (zh) 2018-10-02
BR112014029410B1 (pt) 2023-01-03
JP6293740B2 (ja) 2018-03-14
RU2014153554A (ru) 2016-07-20

Similar Documents

Publication Publication Date Title
EP1560368A1 (fr) Procédé d&#39;établissement d&#39;une session multimédia entre un équipement appelant et un équipement appelé d&#39;un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé
EP3639541B1 (fr) Configuration d&#39;un terminal dans un réseau ims avec une stratégie de resélection d&#39;un type réseau
EP2708002B1 (fr) Procédé de traitement d&#39;une requête de basculement d&#39;une communication entre deux réseaux d&#39;accès
EP2856732B1 (fr) Procédé et entité de traitement d&#39;un message
EP2926524B1 (fr) Routage d&#39;une requête de service visant un abonné ims
WO2016083751A1 (fr) Procede de communication entre un terminal equipe d&#39;un client webrtc et un terminal accessible via un cœur de reseau ims
EP3646554B1 (fr) Procédé de traitement d&#39;une requête et serveur d&#39;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
EP2266279B1 (fr) Partage de contenu multi supports a partir d&#39;une communication audio-video
WO2017203118A1 (fr) Procédé de repli dans un réseau de télécommunication
EP2859704B1 (fr) Serveur d&#39;application et procede de traitement d&#39;un message destine a une identite publique partagee par une pluralite de dispositifs
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP2538704B1 (fr) Indexation d&#39;un message court réalisée par le coeur du réseau
WO2017220883A1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
EP2458813B1 (fr) Procédé de détection d&#39;une situation de nomadisme d&#39;un terminal SIP et terminal mettant en oeuvre ce procédé
WO2013121158A1 (fr) Procédé d&#39;enregistrement d&#39;un serveur d&#39;application et serveur d&#39;application
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d&#39;un terminal additionnel dans un reseau de coeur sip
WO2013156727A1 (fr) Procede de traitement d&#39;un message, entite et cœur de reseau
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2238727B1 (fr) Procédé de communication pour gérer des sessions de communication au niveau d&#39;une passerelle domestique
FR2988951A1 (fr) Procede d&#39;enregistrement d&#39;un serveur aupres d&#39;une pluralite de coeurs de reseau, et serveur.
WO2013001213A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé.
WO2009112760A1 (fr) Procede de gestion d&#39;une session de communication au niveau d&#39;une passerelle domestique

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: 13729982

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2013729982

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14403131

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2015514553

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20147036750

Country of ref document: KR

Kind code of ref document: A

Ref document number: 2014153554

Country of ref document: RU

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112014029410

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112014029410

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20141125