FR2985135A1 - METHOD FOR PROPAGATION OF ASSOCIATIONS BETWEEN CONTACT ADDRESSES AND PRIVATE IDENTITLES IN AN IP NETWORK - Google Patents

Abstract

The present invention relates to a telecommunication data processing method comprising signaling data on a telecommunication IP network, said method comprising a step in which a given set of terminals connects to said IP network. A set of matches is recorded within a core network equipment, each correspondence of the set of matches mapping the private identifier of a terminal of said set of terminals with a contact address of the terminal. The method is characterized in that it further comprises a step of sending a signaling message by the core network equipment to a destination equipment item, said signaling message indicating at least one of said set of correspondences .

Description

The present invention relates to IP (Internet Protocol) type networks that are capable of implementing advanced session control protocols. It is recalled that IP networks allow the broadcasting of conversational data, such as "Voice over IP", "Content Sharing", "Presence", or "Instant Messaging". In these networks, the communication services can identify physical or virtual resources by means of character strings, for example "URIs" (initials of the English words "Uniform Resource Identifier" meaning "Uniform Resource Identifier"). The URI syntax is defined in the Internet Engineering Task Force (IETF) RFC 3986; the knowledge of the URI of a resource makes it possible to obtain the IP address of a device of the network of the operator managing this resource. This equipment may for example be a fixed or mobile terminal, or a home or residential gateway ("Residential Gateway" in English), or a network operator gateway 20 ("Voice Gateway") in English. typically connects a large number of analogue or ISDN lines, such as a DSLAM-SIP (DSLAM are the initials of the words "Digital Subscriber Line Access Multiplexer" meaning "digital subscriber line access multiplexer"; is a device that collects DSL data traffic that travels over a number of telephone lines). For the sake of brevity, the generic term "user terminal" or "terminal" will be used frequently below to designate these various devices. It is also recalled that conventional advanced session control protocols, such as the H.323 and SIP protocols, use so-called "signaling" messages, which are messages enabling a terminal to request a connection with another terminal, or also messages indicating that a telephone line is busy, or signaling that the called telephone is ringing, or signaling that such phone is connected to the network and can be joined in this or that way. When a client registered on a network using an advanced session control protocol wishes to benefit from a multimedia service offered by the network, it sends a signaling message to the network specifying its request. The SIP protocol (initials of the words "Session Initiation Protocol" meaning "Session Initialization Protocol") has been defined by the IETF in RFC 3261. This protocol allows the establishment, modification and termination of sessions. multimedia in a network using the IP protocol. The SIP identifiers may be of the form "SIPURI" as defined in RFC 3261, or of the form "tel-URI" as defined in RFC 3966. A SIP-URI is of the form "user @ host" (for example, alice @ domainel), where the "host" part identifies the network on which the user represented by the "user" part has an account. Such a URI is of the form "tel: telephone number" (for example, tel: +336123456789). This SIP protocol is used in particular in IMS-type infrastructures (initials of the words "IP Multimedia Subsystem" meaning "Multimedia Subsystem over IP"). IMS is defined by the 3rd Generation Partnership Project (3GPP). This is a network architecture originally introduced for mobile networks, and then extended to other accesses, including fixed access xDSL technology. This architecture enables the dynamic establishment and control of multimedia sessions between two clients, as well as the reservation of resources at the level of the network for transporting multimedia streams. With this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate billings to customers. The IMS currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages. Each user of an IMS network can be identified by various identifiers, including IMPI (initials of the words "IP Multimedia Private Identity" meaning "Private Identity for IP Multimedia") and IMPU (initials of English words "IP Multimedia PUblic identity" means "Public Identity for IP Multimedia"). The IMPI is defined in 3GPP specification TS 23.228. The IMPI is an identifier permanently assigned by the operator of a network to a subscription to this operator, and is used, for example, for registration, access authorization, administration of services offered to the user, and billing (it should be noted that a user can have several IMPI within the same subscription, so it is possible to associate each IMPI with a different terminal). The IMPI is in the form of an NAI (initials 15 of the English "Network Access Identifier" meaning "Network Access Identifier"), as defined in the IETF RFC 4282. A user uses his IMPU to communicate with other users. The IMPU is in the form of a URI or short number, or any alias. For a given IMPI, there may be several IMPUs (often, such-URI and SIP-URI). An IMPU can be shared with another phone, so that these phones can both be joined with the same ID (for example, a single phone number for a whole family of users). These identifiers are configured by the operator during the creation by a user of an account with this operator, and exploited during the registration of the user's terminal on the network. When a user wishes to benefit from the services offered by an IMS network, his terminal must, with some exceptions (in the case of certain emergency calls), register on the network. In order to register the 30 users, the IMS networks comprise one or more servers, generally referred to as "S-CSCF" (initials of the words "Serving - Cali Session Control Function" meaning "Server Call Session Control Function") or "Registrar", capable (among other functions) of managing the registration procedure of devices connected to the network. In addition, these networks include one or more servers, generally referred to as "I-CSCFs" (Initials of the English words "Interrogating - Call Session Control Function" meaning "Interrogating Call Session Control Function") which, at the time of registering a user terminal, queries a server called "HSS" (Home Subscriber Service) to select an S-CSCF server having the characteristics required to reach the level of service underwritten by that user. The aforementioned S-CSCF servers contribute to the implementation of these various services by managing signaling routing, on the one hand, between each user terminal and the servers of the network specialized in the implementation of these services. implementation of a particular service subscribed by the user, and secondly towards other users managed by the same network or a network that is connected to it. In order to be able to route these various requests within the network, the 20 servers of the type I-CSCF or of the type S-CSCF (moreover often combined in the same server, denoted I / S-CSCF) exchange information with one or more HSS server (s) mentioned above. The HSS servers each contain a client database, and are therefore the equivalent in IP networks of the "HLR" servers (initials of the English words "Home Location Register" meaning "Nominal Location Register") used in the networks. GSM. Each HSS server contains the profile of a number of network users, this profile including their registration status, authentication and location data, and subscribed services. In the process of creating a user account on an IMS network, the network operator first creates in the HSS an IMS subscription (denoted "IMS Subscription" in the accompanying figures), which will serve as the basis for billing. The operator then notes, with reference to this subscription, the IMPI and public IMPU private identifiers of the users sharing this subscription, declares their service profiles and the IFCs (Initial Filter Criteria) corresponding to , as well as many other user information. The data of the IMS subscription can only be modified by the "Service Delivery" process of the operator (i.e. Information System, inaccessible to users). ro Or, depending on the services that the network operator wishes to offer, he may wish to give the IMS network equipment (user terminals, core network server, etc.) new functionalities making more intensive use of the data. only in the prior art. The present invention improves the situation. The present invention thus aims at a telecommunication data processing method comprising signaling data on a telecommunication IP network, said method comprising a step during which a given set of terminals connects to said IP network. A same public identifier is assigned to all the terminals of said set, and a private identifier is assigned to each terminal of the set. Each terminal of the set also has a specific contact address to said terminal for contacting the terminal on the telecommunications network. A set of matches is recorded within a core network equipment, each correspondence of the set of matches mapping the private identifier of a terminal of said set of terminals to a contact address of the terminal. The method is characterized in that it further comprises a step 30 of sending a signaling message by the core network equipment to a destination equipment, said signaling message indicating at least one of said set of matches. The terminals of the set of terminals all share the same public identifier (for example, IMPU1). Of course, other terminals can be connected to this network without being part of the set and therefore without sharing the public identifier of the set (i.e IMPU1). For example, they may have the public identifiers IMPU2, IMPU3, and so on. The terminals of said set each have a private identifier, advantageously different from each other (for example, IMPI1, IMPI2, etc.), but some terminals may also share the same private identifier. In addition, each of these terminals also has a contact address (including, for example, the IP address of the terminal on the network). When registering a terminal on the network (for example, with an S-CSCF server), the terminal makes the correspondence between its contact address and its private identifier register with a heart device. network (for example, the S-CSCF server or the HSS server described above). Nevertheless, this correspondence is known only to a limited number of telecommunication network equipment. The indication of the correspondence by the signaling message may allow multiple network devices to know the private identifiers of the connected terminals, to supervise their connection and their disconnection independently of their contact address (which may vary over time) and to offer new services, such as a call forwarding to a specific terminal. In addition, the signaling message may be a message sent in response to a request for registration or re-registration of a terminal of the set of terminals. In this case, the recipient equipment of the message is this terminal. Thus, as soon as a terminal is registered on the network, it can have the list of private identifiers of the connected terminals and using the same public identifier as itself, without the need to make a new request separate from the request of 'recording. Alternatively, the signaling message may be a message sent in response to a request from a core network equipment. In this case, the recipient equipment of the message is therefore this network core equipment. As explained in detail below, this variant can in particular facilitate the supervision of the presence on the network of a group of users. Advantageously, the private identifiers of said terminals of the set 15 may be included in a header of said message. The contact addresses (terminals connected and using the same public identifier) being likely to be included in the header of messages sent over the network, it may be advantageous to position the private identifiers of these terminals also in the header of messages. This positioning may make it possible to simplify the indication of the correspondence between these two sets (set of private identifiers and set of contact addresses). In addition or alternatively, the private identifiers of said terminals 25 of the set may be included in an XML content of said message. In a particular embodiment, the method may further comprise a prior determination of the address data for which a match is indicated by the signaling message, this determination being a function of at least one filtering rule. Indeed, it may be desirable not to transmit all the private identifiers of the terminals connected to the network and sharing the same public identifier, in particular to protect the privacy of users. Some private identifiers can be hidden under a filter rule. Advantageously, the filtering rule can be a function of the recipient Io of the message sent. For example, it may be useful to allow certain terminals of the group to know only a restricted list of private identifiers of the terminals connected on the network and sharing the same public identifier, while other terminals (administrator terminals, by example) 15 may be allowed to know all unrestricted private identifiers. The distinction between the two preceding situations can therefore be based on the identifier of the destination terminal of the message containing these private identifiers. In another particular embodiment, the signaling message may indicate said matches within the core network equipment for each terminal contact address data included in said set of terminals. Thus, a correspondence with a private terminal identifier can be indicated for all the contact addresses of the terminals connected on the network and sharing the same public identifier. This mapping indication can therefore be exhaustive.

In addition, the telecommunication IP network may comprise an IMS network. In this case, the core network equipment may include an S-CSCF server.

The present invention also relates to a device for the processing of telecommunication data comprising signaling data on a telecommunication IP network to which a set of terminals is connected. One and the same public identifier is assigned to all terminals of said set, and a private identifier is assigned to each terminal of the set. Each terminal of the set is furthermore a contact address specific to said terminal for contacting the terminal on the telecommunication network. A set of correspondences is recorded within a core network equipment, each correspondence of the set of correspondences mapping the private identifier of a terminal of said set with a contact address of the terminal. The device is characterized in that it comprises a transmitter for sending a signaling message to a destination equipment, said signaling message indicating at least one of said set of matches. The present invention further provides a terminal for the processing of telecommunication data comprising signaling data on a telecommunication IP network to which a set of terminals is connected, the terminal being part of said set. One and the same public identifier is assigned to all the terminals of said set, and a private identifier is assigned to each terminal of the set. Each terminal of the set is furthermore a contact address specific to said terminal for contacting the terminal on the telecommunication network. A set of correspondences is recorded within a core network equipment, each correspondence of the set of correspondences matching the private identifier of a terminal of said set with a contact address of the terminal. The terminal is characterized in that it comprises: a receiver for receiving a signaling message transmitted by a core network equipment, said signaling message indicating at least one of said set of correspondences, and display means to display data associated with the private identifiers of the message. The data associated with the private identifiers of the message may be, for example, a surname whose prior association with a private identifier has been made by the user in the memory of the terminal. The present invention also relates to a computer program comprising instructions for implementing the method described above, when this program is executed by a processor. Figures 5 and 6 described in detail below, can form the flow chart of the general algorithm of such a computer program. Other features and advantages of the invention will become apparent upon reading the following description. This is purely illustrative and should be read in conjunction with the accompanying drawings in which: FIG. 1 illustrates the concepts of contact address, private identifier and public identifier; FIG. 2 illustrates the data related to the IMS subscription in a particular embodiment of the invention; - Figure 3 illustrates a more complex data organization related to IMS subscription; FIG. 4 is an illustration of a "knowledge zone" of a private identifier; FIG. 5 is a flowchart of an exemplary method in the sense of the invention executed by a central server (or core network server), such as an S-CSCF server; FIG. 6 is a flowchart of an exemplary method in the sense of the invention executed by a terminal; FIG. 7 is a representation of an S-CSCF server able to execute a method in the sense of the invention; FIG. 8 is a representation of a terminal capable of executing a method within the meaning of the invention.

FIG. 1 illustrates the notions of contact address, private identifier and public identifier in the context of a telecommunications network 100 of the SIP type. The telecommunication network 100 comprises three connected devices: a portable computer 101 and two mobile terminals 102 and 103. These devices 101, 102 and 103 are respectively configured with three private identifiers IMPI1, IMPI2 and IMPI3. These private identifiers make it possible in particular to identify (for the operator of the SIP network) the customer account to be billed for the services provided. On the communication network 100, these devices each have a contact address, these contact addresses to contact them on the network. For example, these contact addresses include an IP address (for "Internet Protocol" in English) or a domain name (for example "hosttdomain.com"). In FIG. 1, the devices 101, 102 and 103 respectively have the contact addresses @ 1, en and @ 3. These contact addresses can evolve rapidly over time, especially in the event of a change by a home subnet terminal (also called "roaming" in English). In addition, these devices can use one or more public identifiers. The public identifiers make it possible to be put in contact with one or more pieces of equipment, without knowing either their private identifier or their contact address. For example, the devices 102 and 103 may share the same public identifier IMPU5 while the device 101 has the public identifier IMPU4. If a person requests (104) to be put in contact with a terminal 10 using the public identifier IMPU5, the telecommunication network 100 identifies the private identifiers and the terminal contact addresses assigned to this public identifier IMPU5, that is, that is, in the case of FIG. 1, the terminals 102 and 103. FIG. 2 illustrates the data declared in the HSS and related to the IMS subscription 201 of a user having a private identifier IMPI 202 (or "Private" User Identity ") and three public identifiers IMPU1 203 (or" Public User Identity 1 "), IMPU2 204 (or" Public User Identity 2 "), IMPU3 205 (or" Public User Identity 3 "). Two of these public identifiers are grouped into an IRS 206 (initials of the English words "Implicit Registration ID Set" meaning "Implicit Identity Registration Set"), which is represented in Figure 1 by a dashed rectangle. This notion of IRS makes it possible to use a public identifier to record another implicitly as well. For example, when registering an IPBX, namely a PABX (initials of the words "Private Automatic Branch eXchange" meaning "Private Telephone Switch", which is used primarily to connect the telephones of an establishment with the public telephone network), it may be convenient to automatically register one of the multiple public identifiers attached to the IPBX to declare the presence on the network of all the identifiers. The IRS 206 then contains all the identifiers of the IPBX. It would be the same for the registration of a gateway offering multiple accesses. Sometimes a specific public identifier is used when registering an IRS. This identifier typically represents a user such as an IPBX or a gateway as a whole, and can not be used as such for routing purposes. We then speak of "barred identity" (English words meaning "useless identity"). FIG. 3 illustrates, with the same conventions as FIG. 1, the data related to the IMS subscription 301 of a user having two private identifiers (IMPI1 302 and IMPI2 303) and six public identifiers (IMPU1 304, IMPU2 305, IMPU3 306, IMPU4,307, IMPU5,308, and IMPU6,309), grouped into three IRSs (IRS1,310, IRS2,311, and IRS3,312). The public identifiers IMPU3 and IMPU4 are common to the two private identifiers IMPI1 and IMPI2. Figure 3 also shows the service profiles associated with each of the public identifiers. If, for example, a user registers a terminal configured with the private identifier IMPI2 and the public identifier IMPU5, then the public identifier 20 IMPU6 will also, implicitly, be registered. Indeed, these two public identifiers IMPU5 and IMPU6 belong to the same IRS (IRS3). The user can therefore be reached on his terminal at once via his public identifier IMPU5 and via his public identifier IMPU6. This dataset declared in the HSS is then downloaded by the S-CSCF in charge of the user. This S-CSCF can thus know all the identifiers declared in the IMS subscription, know which ones are registered implicitly, and make the link between the public identifiers and the contact address of the terminal in order to route the incoming calls. . In addition, the S-CSCF knows the registration status of each public identifier. This state can be "registered", "not registered", or "unregistered" (unregistered identifier, but having nevertheless benefited from an IMS service, for example the processing of a call intended for this public identifier).

Figure 4 is an illustration of a "zone of knowledge" of a private identifier. In FIG. 4, three pieces of equipment 402, 403 and 404 are connected to the "registrar" 400 (S-CSCF server). The latter server 400 is also interconnected via a signaling protocol to the HSS 401 home subscriber server and the AS 406 application server. In addition, a BGCF 405 SIP proxy server is connected to the registrar server 400 to route certain SIP messages to an external network for example. In a typical configuration, when the terminal 404 registers with the S-CSCF server 400, it issues a request of the following form to the S-CSCF server 400: REGISTER sip: domain SIP / 2.0 TB: <sip: IMPU1 @domain> 20 From: <sip: IMPU1 @ domain>; tag = regtagxx Call-Id: diagxx CSeq: 1 REGISTER WWW-Authenticate: username = + IMPI3gdomain3, ... Contact: <sip: AoC1>; expires = 3600 25 It is considered that the terminal 404 has a private identifier IMPI3 and is associated with the public identifier IMPU1.

In addition, the S-CSCF server 400 informs the HSS server 401 of this record so that an update of its database can be performed. According to the state of the art, other network equipment (ie equipment 402, 403, 405 and 406) are not subsequently informed that identifier IMPI3 is connected to the communication network. In the SIP protocol as defined in the document RFC 3261, the network equipment associated with a public identifier can be informed of the contact addresses of the other devices associated with the same public identifier (for example, contained in the response to a message of registration or re-registration of a terminal). Indeed, the responses to the registration messages are of the form: SIP / 2.0 200 OK 15 TB: <sip: IMPU1 @ domain> From: <sip: IMPU1 @ domain>; tag = regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: <sip: AoC1>; expires = 3600 20 Contact: <sip: AoC2>; expires = 2349 P-Associated-URI: <sip: IMPU1 @ domain> P-Associated-URI: <tel: IMPUl> P -Associated-URI: <sip: IMPU2 @ domain> The header fields titled "Contact" contain the contact addresses (AoC1, AoC2) of the terminals associated with the same public identifier IMPU1. However it is not possible, on the basis of this simple information, to know which private identifier and therefore which terminal or user corresponds to this or that contact address, and this, especially as the contact address is likely to evolve over time. For example, the terminal 403 using "registration" registration requests (REGISTER requests without Contact header) to know which other terminals connected to the network obtains at a time to the list of contact addresses of the terminals connected to the network and sharing the same public identifier as him. This list includes two contact addresses: AoC1 and AoC2. The terminal 403 also obtains at a time ti the list of the contact addresses of the terminals connected to the network and sharing the same public identifier as it. This list then includes at time t1 a single contact address: AoC3. The terminal 403 is unable to determine if the contact address AoC3 corresponds to a new terminal connected to the network, the two previous terminals having disconnected or if the contact address AoC3 corresponds to one of the terminals previously connected with one of the two contact addresses AoC1 and AoC2, the other terminal having disconnected. In particular, this can be inconvenient in a multisite business context or even in a family context if one wishes to know all the terminals connected to the network at a given moment.

For example, a family member receiving a call via the public identifier of the family may wish to redirect the call to the specific terminal of the father. Thus, he needs to know if the father's terminal is connected to the network and, if necessary, to indicate that the call must be redirected specifically to this terminal.

Similarly, and in the context of a call center, a team leader may want to supervise the tele-counselors and supervise the presence of each one using his / her mobile terminal at any time (including in the context of a call center). a virtual call center where different tele-counselors are not in the same physical location). This supervision, or, more generally, the reception of a signaling message containing a correspondence within the meaning of the invention, can also be carried out using equipment other than user terminals, such as core network servers (or central servers) used for supervisory purposes. Thus, such equipment may, for example, regularly issue listing registration messages to the S-CSCF server 400 (see above) and analyze the responses of this server to establish the presence or absence of equipment sharing the same. public identifier. This supervision can be provided by an AS 406 application server. Thus, a summary of this supervision can be provided via a web interface to the authorized users connecting to the AS application server. 406. In the example of FIG. 4, the presence of the terminal IMPI3 404 on the network is known only from the group (or "knowledge zone") represented by the dotted set 408, that is, ie, the terminal itself 404, the registrar server 400 receiving, for example, the registration request, and the HSS 401. An embodiment of the invention will now be described. In this embodiment, the responses to the registration or re-registration requests indicate a correspondence between the address data contained in the standard response described above and the private identifiers of the terminals. Thus, the new responses to the registration messages can be of the form: SIP / 2.0 200 OK To: <sip: IMPU1 @ domain> 25 From: <sip: IMPU1 @ domain>; tag = regtagxx Call-Id: diagxx CSeq : 1 REGISTER Contact: <sip: AoC1>; expires = 3600; username = + IMPI1 @ domain Contact: <sip: AoC2>; expires = 2349; username = + IMPI2 @ domain Contact: <sip: AoC3>; expires = 1254 ; username = + IMPI2 @ domain P-Associated-URI: <sip: IMPUl @ domain> P-Associated-URI: <tel: IMPUl> P-Associated-URI: <sip: IMPU2 @ domain> Thus, the fields of the 'Contact' header are enriched with the private identifiers of the terminals. The terminal having the contact address AoC1 has a private identifier IMP11. The terminal having the contact address AoC2 has the private identifier IMPI2. It should be noted that the terminal having the contact address AoC3 also has the same private identifier as the previous terminal, namely IMPI2. In the end, the terminals associated with a given public identifier can know all the private identifiers of the terminals connected on the network and also sharing the same public identifier. The messages exchanged between the registrar server and the AS 406 application server can also be enriched in this way. Thus, with reference to FIG. 4, the presence of the IMPI3 terminal 404 on the network can be known from the new group (or "knowledge zone") represented by the dotted set 409, that is to say, the terminal 404, the "registrar" server 400 receiving, for example, the registration request, the HSS 401, but also the other terminals (402 and 403) and the application server 406. Therefore, it is possible to deport a large number of functionalities (supervision of connections, call forwarding to a specific terminal, etc.) to terminal equipments and central servers other than the "regisear". The terminal equipment may then be advanced terminals that can record a correspondence between private identifiers and surname (for example), this recorded correspondence allowing, on the basis of the correspondence indication of the message, to view the list of the 30 users connected to the network via their associated terminals.

FIG. 5 is a flow diagram of an exemplary method in the sense of the invention executed by a central server such as an S-CSCF server. An S-CSCF server capable of executing a method according to the invention is described in FIG. 7. When receiving a registration message 700 from a terminal via an interface 702 of the S-CSCF server 701, this message is transmitted to a response module 704. This module 704 notably extracts the public identifier 500 from the terminal of this message 700. o Once extracted, it is possible to search in a memory 703 (for example, via a request from of the HSS central server of the IMS network) the list of all the contact addresses (step 501) of the terminals connected to the network at the time of the search. Moreover, in parallel or asynchronously, it is possible to search all 15 private identifiers of the terminals connected to the network at the time of the search and to match them with the previously sought contact addresses (step 502). In most cases, the mapping corresponds to a contact address a unique private identifier and to a private identifier a unique contact address.

On the basis of the contact addresses corresponding to the private identifiers of the terminals, it is possible to prepare a response to the received message (step 506) with, for example, a field in the message header prepared to indicate the correspondence between the contact address AoCn and the private identifier IMPIn @ domain: 25 Contact: <sip: AoCn>; expires = 3600; username = + IMPIn @ domain Moreover, it is also possible to filter certain matches to avoid that the identifiers some equipment is transmitted to a large number of other equipment. For example, it is undesirable that the private identifiers of the senior managers of a company are known to employees of the company, even though a common public identifier would be shared for the entire company. 'business. Similarly, in the context of a call center in which a hundred tele-advisers are reachable via the same public identifier, it is not desirable to communicate a hundred private identifiers to a terminal if the need is to transfer a call to an available person. Thus, a prior selection of private identifiers can be performed by applying previously configured filtering rules. For example, and in a nonlimiting manner, these rules may be: - not to transmit the private identifiers of the terminals of the team managers; - transmit only a selection of ten randomly selected private identifiers in the list of non-communicating terminals; - not to transmit after 20:00 a given private identifier; 15 - transmit only the list of private identifiers of the terminals assigned to the persons of the same team. These rules are extracted from the memory 703 (step 503) and a masking of the identifiers not to be transmitted (in accordance with the rules extracted) is carried out (step 504). This masking may consist in removing from the prepared response the private identifiers to be masked or even in replacing the private identifiers to be masked by stars (ie "username: + ******* ** ", for example). Finally, the prepared response may be transmitted to the terminal having sent the message 700 (step 505), the response module then transmitting this response to the sending interface 705 to allow its transmission (message 600). FIG. 6 is a flowchart of an exemplary method performed by a terminal (or core network equipment used, for example, for supervisory purposes) upon receipt of a response as described in FIG. 5. An example of a terminal capable of executing such a method is described in FIG. 8. Upon reception by an interface 802 of a terminal 801 of a response 600 as described above, this response 600 is transmitted to a processing module 803 to allow its analysis. For example, this module 803 can be used to extract the private identifiers corresponding to the contact addresses (step 601). The user of the terminal 801 may have previously registered an association between surnames and private identifiers of terminals within a memory (604 or 804) of the terminal. For example, he may have registered the association between: - the private identifier "IMPI6544" and the name "M. DUPOND", - the private identifier "IMPI7673" and the name "M. SMITH", - the identifier private "IMPI8753" and the name "Mrs. GOD". On the basis of this association between, on the one hand, a surname and a private identifier and, on the other hand, the content of the message 600, it is possible to relate surnames with the private identifiers contained in this message (step 602). Thus, if, for example, the message comprises the private identifiers IMPI6544, IMPI8753, "*********" and IMPI1286, the processing module can control the screen 805 of the terminal 801 so that it indicates the name people connected to the network (step 603). The private identifier "*********" corresponds to a private identifier that has been hidden when sent by the registrar. For example, the following textual indication may be displayed on screen 805 "Mr. DUPOND and Mrs. GOD are connected to the network. Two other people are also connected to the network, but they are not known. On the other hand, the block diagram shown in FIG. 5 or 6 is a typical example of a program, some of whose instructions may be performed on core network equipment and others on a user terminal. . As such, FIG. 5 or 6 may correspond to the flowchart of the general algorithm of a computer program within the meaning of the invention. Of course, the present invention is not limited to the embodiments described above as examples; it extends to other variants. For example, the registration messages are not the only messages that can be used to indicate this correspondence. Thus, regular re-registration messages or "listing registration" messages (messages without a "Contact" header whose purpose is to retrieve all the connected terminals at the time of the request and sharing the same public identifier) can allow the indication of this correspondence. Moreover, the indication of the correspondence mentioned above can be contained in a message header as described above but can also be transmitted in the body of the message, for example in an XML content (for "eXtensible Markup Language" in English) of a notification message relating to the subscription of the registration state package "reg event" as described in RFC 3680.

Claims (13)

REVENDICATIONS1. A telecommunication data processing method comprising signaling data on a telecommunication IP network, said method comprising a step in which a given set of terminals connects to said IP network, the same public identifier being assigned to all the terminals of said set, and a private identifier being assigned to each terminal of the set, each terminal of the set having in addition a contact address 10 specific to said terminal for contacting the terminal on the telecommunication network, a set of correspondences is stored in a core network equipment, each correspondence of the set of matches mapping the private identifier of a terminal 15 of said set with a contact address of the terminal, characterized in that it comprises in in addition to a step of sending a signaling message by the core network equipment to a recipient equipment, said signaling message indicating at least one of said set of correspondences. 20 2. The method of claim 1, wherein the signaling message is a message sent in response to a request for registration or re-registration of a terminal of said set of terminals. 25 3. Method according to claim 1, wherein the signaling message is a message sent in response to a request from a core network equipment. 4. Method according to one of the preceding claims, wherein the private identifiers of said terminals of the set are included in a header of said message. 5. Method according to one of the preceding claims, wherein the private identifiers of said terminals of the set are included in an XML content of said message. 10 The method according to one of the preceding claims, wherein the method further comprises: - a prior determination of the address data for which a match is indicated by the signaling message, this determination being a function of at least one rule filtering. The method of one of the preceding claims, wherein the signaling message indicates said matches within the core network equipment for each terminal contact address data included in said set of terminals. 8. The method of claim 6, wherein the filtering rule is a function of the recipient of the message sent. 25 9. Method according to one of the preceding claims, wherein the telecommunications IP network comprises an IMS network. The method of claim 9, wherein the core network equipment comprises an S-CSCF server. 11. A core network device for the processing of telecommunication data comprising signaling data on a telecommunication IP network to which a set of terminals is connected, the same public identifier being assigned to all the terminals of said set, and an identifier Each terminal of the set having, in addition, a personal contact address of said terminal for contacting the terminal on the telecommunication network, a set of correspondences being recorded within a terminal. core network equipment, each correspondence of the set of 15 matches mapping the private identifier of a terminal of said set with a contact address of the terminal, characterized in that it comprises a transmitter for the transmission of a signaling message to a destination equipment, said signaling message indicating at least one signal orrespondance among said set of matches. Terminal for the processing of telecommunication data comprising signaling data on a telecommunication IP network to which a set of terminals is connected, the terminal forming part of said set, the same public identifier being assigned to all the terminals of said set, and a private identifier being assigned to each terminal of the set, each terminal of the set having in addition a contact address specific to said terminal for contacting the terminal on the telecommunication network, a set of correspondences being recorded within a core network equipment, each correspondence of the set of correspondences mapping the private identifier of a terminal of said set with a contact address of the terminal, characterized in that it comprises: a receiver for receiving a signaling message transmitted by a core network equipment, said message of signaling indicating at least one of said correspondence set, and - display means for displaying data associated with the private identifiers of the message. 15 13. Computer program product comprising instructions for implementing the method according to one of claims 1 to 10, when the program is executed by a processor.