[go: up one dir, main page]

WO2014114871A1 - Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication - Google Patents

Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication Download PDF

Info

Publication number
WO2014114871A1
WO2014114871A1 PCT/FR2014/050110 FR2014050110W WO2014114871A1 WO 2014114871 A1 WO2014114871 A1 WO 2014114871A1 FR 2014050110 W FR2014050110 W FR 2014050110W WO 2014114871 A1 WO2014114871 A1 WO 2014114871A1
Authority
WO
WIPO (PCT)
Prior art keywords
client equipment
network
registration
server
communication network
Prior art date
Application number
PCT/FR2014/050110
Other languages
English (en)
Inventor
Antoine Mouquet
Laurent Renard
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2014114871A1 publication Critical patent/WO2014114871A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • the present invention relates to the recording of client equipment within a communication network, and more particularly to the recording of IP-PBX type equipment in an IP network comprising a core network having an IMS architecture (for IP Multimedia System).
  • IMS architecture for IP Multimedia System
  • the communication network is an IP network (ie a network using the IP protocol) comprising an access network (of the ADSL, xDSL, WiFi, WiMAX, GSM, UMTS or LTE type, for example ) associated with an IMS backbone, ie a backbone with an IMS network architecture as introduced by the 3GPP ("J d Generation Partnership Project") for mobile networks , then taken over by TISPAN ("Telecommunications and Internet Converged Services and Protocols for Advanced Networking”) for fixed networks.
  • the IMS network architecture notably 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.
  • the IMS architecture currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages.
  • Such an IMS network architecture comprises in particular:
  • S-CSCF Server- ⁇ all Server ⁇ ontrol Function
  • I-CSCF Interrogating- ⁇ all Server ⁇ ontrol Function
  • HSS Home Subscriber Server
  • Each HSS server contains the "profile" of a number of client devices in the network, this profile including their registration status, authentication and location data, and subscribed services;
  • proxy servers also called “proxy” servers
  • P-CSCF Proxy- ⁇ all Server ⁇ ontrol Function
  • P-CSCF Proxy- ⁇ all Server ⁇ ontrol Function
  • the client equipment wishing to register with such an IP network usually sends a "SIP REGISTER" message containing identification information to a P-CSCF server, which relays this message to an I-CSCF server which, after checking with an HSS server, retransmits this registration message to the appropriate S-CSCF server so that it can register the client equipment.
  • IP PBX IP PBX
  • IP-PBX IP PBX
  • IP PBX equipment is then considered by the operator as being a third party network and connected to an IBCF (Interconnection Border Control Functions) gateway.
  • IBCF Interconnection Border Control Functions
  • the "Subscription-based" mode the IP PBX equipment is then considered by the network as an IMS terminal.
  • This second connection mode is certainly easier to manage for the operator, especially for small IP PBX equipment.
  • this second connection mode implies that the IP PBX equipment must register with the IMS network as a normal terminal.
  • many IP PBX devices available on the market do not support recording because they are in compliance with an option of the "SIPconnect" recommendation of the SIP Forum, called "Static mode".
  • a major disadvantage of this solution is that it requires that the data of each IP PBX equipment (in particular the public and private IMS addresses of these IP PBXs) are preconfigured in a P-CSCF server, before this P-CSCF server can initiate any IMS registration procedure on behalf of these IP PBX devices.
  • the object of the present invention is to remedy the aforementioned drawbacks by proposing a management of the recording of a client equipment at the level of a proxy equipment of the network that does not require any particular configuration related to this client equipment at the level of the equipment. representative.
  • a method of preparing a request for registration of a client equipment in a communication network implemented by at least one proxy server of said network, comprising obtaining at least one data item.
  • identification of the client equipment in the network from authentication data of this client equipment received during an authentication phase of this client equipment, and the preparation of the registration request of the client equipment, in which is inserted the at least one identification data of the client equipment in the network.
  • This allows the proxy server to trigger the registration of the client equipment in the network, on behalf of this client equipment, without the need to preconfigure locally the proxy server with identification data of this client equipment, and that of transparent way for both the client equipment and the network registration server. Also avoids mass registrations when starting the proxy server, which is the case when the latter is preconfigured locally.
  • the method furthermore comprises the prior configuration of said at least one proxy server, this prior configuration comprising storing, in said at least one proxy server, a derivation rule making it possible to deduce the at least one data item.
  • the authentication data of the client equipment comprise a domain identifier associated with the client equipment, said at least one identification data item comprising at least one of a public identifier of the equipment. client in the communication network and a private identifier of the client equipment in the communication network, generated from said domain identifier.
  • a unique instance identification data is advantageously obtained further from the authentication data received from said client equipment. , this unique instance identification data being inserted into the registration requests developed by the proxy servers.
  • Using multiple proxy servers to register the client device provides increased resiliency: If a primary proxy server, the physical path connecting that primary proxy server to the client device or the access network connecting that proxy server primary to the client equipment becomes defective, another proxy server can then be used by the client equipment.
  • the method may further comprise, for each of the proxy servers, the generation of a unique identification data of this server. proxy in the communication network and the insertion of this unique identification data of this proxy server in the registration request developed by said proxy server. It is thus possible to distinguish the different recordings of the same client equipment, according to the initiating proxy server of the recording, to prevent the recording made by the second proxy server, in chronological order, overwriting the recording. made by the first proxy server.
  • the authentication data is in the form of an authentication certificate transmitted by the client equipment in response to an authentication request sent by the at least one proxy server during the authentication process. an authentication phase.
  • the communication network is an IP network comprising a core network having an IMS type architecture and using the SIP protocol
  • the registration message is a message of the "SIP REGISTER" type
  • the server proxy is a P-CSCF server
  • the registration entity is an S-CSCF server.
  • the present invention further proposes a method for preparing a request for de-registration of a client equipment in a communication network comprising the following steps, implemented by at least one proxy server of this network when this proxy server receives no message maintaining a secure connection established with the client equipment for a specified period of time or when this proxy receives a disconnection message from said connection secure:
  • the present invention also proposes a method of recording a client equipment in a communication network comprising the following steps, implemented by at least one proxy server following the receipt of authentication data from the client equipment when an authentication phase of this client equipment:
  • this registration request to a registration server of the communication network, this registration request being used by the registration server to register the client equipment in the communication network.
  • the proxy server recording method comprises developing a request for de-registration of the client equipment by the above method and sending this de-registration request to the registration server, this de-registration request being used by the server register to unregister the client equipment in the communication network.
  • the present invention also proposes a proxy server of a communication network, able to prepare a request for registration of a client equipment in the communication network, intended to be transmitted to a recording server of the communication network, comprising a module of treatment of data configured for, following receipt of authentication data transmitted by the client equipment during an authentication phase of this client equipment, obtaining at least one identification data of the client equipment in the communication network , from the authentication data received from said client equipment, and develop the registration request of the client equipment, inserting this at least one piece of identification data of the client equipment in the network.
  • the present invention further provides a communication network, comprising a core network and able to register a client equipment to provide a service, the core network comprising at least one proxy server as described above and a server d recording configured to register the client equipment, following the receipt of a request for registration of this client equipment developed by the proxy server.
  • the various steps of the above methods are implemented by a software or computer program, this software comprising software instructions intended to be executed by a data processor of a proxy server of a network. and being adapted to control the execution of the different steps of this process.
  • the invention is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned 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 form what other form is desirable.
  • the invention also relates to a data carrier readable by a computer or data processor, and comprising instructions of a program as mentioned above.
  • This information carrier can 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 means, for example a diskette or a hard disk.
  • this 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.
  • this 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.
  • FIG. 1 illustrates a communication system in which the present invention is implemented
  • FIG. 2 illustrates the steps of a recording method according to a particular embodiment of the invention, in which the generation of the registration request of the client equipment is entrusted to a single proxy server of the network of communication;
  • FIG. 3 illustrates the steps of a recording method according to another particular embodiment of the invention, in which the generation of the request for registration of the client equipment is carried out by several proxy servers of the network of communication;
  • FIG. 4 illustrates a particular example of the recording method according to a particular embodiment of the invention using a single proxy server, as described above.
  • FIG. 1 illustrates a communication system in which the present invention is implemented.
  • the client equipment 1 is connected to the IP_NET network of a telecommunications operator, consisting of an ACC_NET access network and an IMS_CN core network.
  • the client equipment 1 is a client equipment to be registered in the heart of the network IMS_CN, in order to allow it to access certain services offered by the IP_NET network (telephony, voice over IP, internet ...), and which does not it is not possible to make such a recording because it does not have such a recording feature, or does not use this feature itself if it has one.
  • this client equipment 1 may be IP PBX equipment as discussed above.
  • the ACC_NET access network may be a radio network, whether or not compliant with the specifications defined by the 3GPP standardization organization, or a wired, optical or xDSL network.
  • the network core IMS_CN it comprises in particular a proxy device 2 connected to an interrogation server 3 and a registration server 4, which are themselves connected together and to a subscriber server 5.
  • the proxy equipment 2 serves in particular to relay the signaling messages between the client equipment 1 and the other servers of the core network IMS_CN, and has a data processing module, typically in the form of a processor associated with a device. memory, to implement the method described below.
  • the proxy server 2 is a P-CSCF server
  • the interrogation server 3 is an I-CSCF server
  • the registration server 4 is an S-CSCF server
  • the subscriber server 5 is an HSS server
  • FIG. 2 illustrates the steps of a recording method according to a particular embodiment of the invention, wherein the generation of the registration request of the client equipment is performed by a single proxy server of the communication network.
  • the server Proxy 2 is advantageously configured beforehand (step 10) in order to be able to implement the method of the present invention, this configuration including including the storage of one or more rules making it possible to use all or part of the authentication data received from the client equipment 1 to deduce identification information for recording this client equipment 1, in a manner transparent to the latter, as will be seen later.
  • Such prior configuration typically takes place at the time of commissioning the proxy server, is not specific to a particular type of client equipment and is the same for all the servers to which it applies.
  • the proxy server 2 uses AUTH authentication data received from the client equipment 1 (step 23) during an authentication phase (phase 20), triggered by the connection from the client equipment 1 to the IP_NET network, which is for example an authentication phase with TLS protocol-compliant client authentication (for Transport Laver Security), prior to any exchange of information between the client equipment 1 and the IP_NET network.
  • phase 20 an authentication phase with TLS protocol-compliant client authentication (for Transport Laver Security), prior to any exchange of information between the client equipment 1 and the IP_NET network.
  • This authentication data AUTH of the client equipment 1 is typically stored in the client equipment 1 (either manually beforehand or during an automatic preconfiguration) and included in an authentication certificate (designated by CERT (AUTH ) in Figure 2) returned by the client equipment 1, following the reception (step 21) of an authentication request sent by the proxy server 2 when it detects the connection of the client equipment 1 to the IP_NET network and that he starts the authentication phase.
  • CERT AUTH
  • these AUTH authentication data can correspond to a domain name assigned to the IP PBX equipment, identified by a SIP URI or an FQDN, and inserted in the authentication certificate returned by the client equipment 1 during the authentication phase.
  • the AUTH authentication data can take the following form:
  • the proxy server 2 can extract the certificate the AUTH authentication data of the client equipment 1 to deduce therefrom (step 31), by means of a bypass rule R stored during the aforementioned preliminary configuration of the proxy server 2, one or more identification data ID of the client equipment 1 in the communication network, this identification datum (s) ID used to register this equipment in the IMS core network, and therefore in the IP_NET network.
  • the ID identification data or data thus obtained, from these authentication data and by means of this derivation rule R, are advantageously also stored, beforehand, at a subscriber server (eg a server HSS in the case of an IMS core network) when subscribing the user of the client equipment 1, to allow the subsequent validation of the registration.
  • a subscriber server eg a server HSS in the case of an IMS core network
  • a first ID1 identification data can thus be a public identifier of the client equipment 1 in the communication network, this public identifier ID1 being constructed from the authentication data, for example by means of a rule R of derivation taking the form of an injective function associating a public identifier ID1 to the authentication data AUTH.
  • Such a rule R may for example consist of adding to the AUTH authentication data an EXT extension linked to the IMS_CN network:
  • this public identifier is the public IMS identifier ("IMS Public User Identity" in English or IMPU) and may take the following form:
  • ID1 "sip: (IP PBX domain name) @ (Domain name in the IMS network)"
  • a second identification data ID2 also deduced from the authentication data AUTH received from the client equipment 1, may be a private identifier of the client equipment 1 (ie a private address used by the operator of the IP_NET network), this private identifier ID2 being constructed from the AUTH authentication data, for example by means of a derivation rule R 'taking the form of an injective function associating a private identifier ID2 with the authentication data AUTH, for example by adding to a part of the AUTH authentication data the EXT extension linked to the IMS_CN network.
  • a private identifier of the client equipment 1 ie a private address used by the operator of the IP_NET network
  • this private identifier ID2 being constructed from the AUTH authentication data, for example by means of a derivation rule R 'taking the form of an injective function associating a private identifier ID2 with the authentication data AUTH, for example by adding to a part of the AUTH authentication data the EXT extension linked to the
  • this private identifier is then the private IMS identifier ("IMS Private User Identity" in English or IMPI), typically taking the form of an access identifier. to the network (NAI), and can take the following form:
  • ID2 "(IP PBX Domain Name) @ (Domain Name in the IMS Network)"
  • the proxy server 2 stores on the one hand these identification data and develops (step 33) a request for recording (REG_REQ) of the client equipment, according to the signaling protocol used in the IMS_CN core network (for example a "SIP REGISTER" request when this core network is of IMS type using the SIP protocol) in which this or these data (s) of identification.
  • the signaling protocol used in the IMS_CN core network for example a "SIP REGISTER" request when this core network is of IMS type using the SIP protocol
  • This registration request REG_REQ is then sent (step 35) to the registration server 4, possibly via the interrogation server 3, so that this registration server 4 proceeds to the registration (step 37).
  • client equipment 1 in the core network IMS_CN therefore in the IP_NET network, using the identification data of this client equipment 1 in the network.
  • This last recording step at the recording server is conventional and will not be described in detail.
  • the life cycle of the recording of the client equipment 1 is managed during the secure connection 30, not by the client equipment 1 itself, but by the proxy server 2, on behalf of the equipment client 1, and this on the basis of events taking place during the authentication phase 20 of the client equipment 1 to the IP_NET network.
  • the initial connection of the client equipment 1 to the IP_NET network resulting in the triggering of the authentication phase 20 of the client equipment 1, also triggers, indirectly and transparently for the client equipment 1, the registration of the latter in the network core IMS_CN of the IP_NET network.
  • the authenticated connection 30 established following the authentication phase 10 is maintained by sending (step 38) "keep-alive" type messages to the proxy server 2.
  • Such messages can be used here by the server agent 2 to maintain, or delete, the registration of the client equipment 1.
  • the proxy server 2 receives "keep-alive” type messages from the client equipment 1 (for example at least a certain number of "keep-alive” during a determined period of time), meaning that the authenticated connection is active, the recording of the client equipment 1 is maintained to the extent that the proxy server 2 refreshes this record with the recording server 4 (for example according to a recording duration fixed by this server 4) by regularly returning the request REG_REQ (step 39) after receiving one or more messages of "keep-alive” type, reusing the identification data stored during the development of the request REG_REQ initial.
  • the proxy server 2 may decide to interrupt the registration of the client equipment 1 during a de-registration phase 40.
  • This de-registration phase comprises the recovery of ID identification data (s) inserted previously in the initial registration request REG_REQ, as stored by the proxy server 2, and the elaboration (step 41) by the proxy server 2, a UNREG_REQ unregistering request (eg when the SIP protocol is used, a SIP request "REGISTER” with a header “expires: 0"), containing in particular this (these) data (s) of ID, and sending (step 43) this request UNREG_REQ to the recording server 4, so that it removes (step 45) the recording of the client equipment 1 in the network, using ID data (s) ID of this client equipment.
  • the proxy server 2 can terminate the authenticated connection with the client equipment 1, by sending a message closing this connection (step 47). If this message reaches the client device 1, the latter will be prompted to initiate a new secure connection, which will result in a new record via the proxy server 2, and so on.
  • the recording time of the client equipment 1 in the network thus corresponds to the duration of the secure connection 30 between this client equipment 1 and the proxy server 2.
  • the authentication of the client equipment having been carried out since the establishment of this secure connection 30, it is no longer necessary to perform additional authentication as long as this secure connection is maintained (eg for each SIP request of the "SUBSCRIBE" or "INVITE" type sent by the client device 1 during the secure connection 30).
  • FIG. 3 illustrates the steps of a recording method according to another particular embodiment of the invention, in which several requests for registration of the client equipment are constructed by a plurality of servers. representatives of the communication network.
  • proxy servers 2 X and 2 2 are illustrated, without this number being limiting.
  • each of the proxy servers 2 X and 2 2 is advantageously pre-configured (step 10), identically and similarly to what has been described with reference to FIG. 2.
  • the client equipment 1 initiates the establishment of a secure connection with each of the proxy servers 2i and 2 2 (secure connection establishment phases 50 and 60) by sending (steps 51 and 61) to each of the proxy servers 2i and 2 2 , during an initial authentication phase of this equipment, an authentication response message containing AUTH authentication data as previously described.
  • each of the proxy servers 2 1 and 2 2 proceeds, independently and identically, as follows:
  • one or more identification data ID of the client device 1 in the communication network are deduced from the received authentication data AUTH (steps 52, respectively 62), similarly to the step 31 previously described;
  • UUID Unique instance identification data
  • This unique identifier can be constructed from the AUTH authentication data by means of a bypass rule stored during the prior configuration of the proxy servers, so that for given authentication data, it is always the same. same unique UUID instance credential that is returned.
  • this derivation rule necessarily returns different unique instance identifiers.
  • this unique identifier ID3 can be a universal unique instance identifier (UUID URN in English), obtained by means of a derivation rule using the algorithm described. in clause 4.3 of RFC 4122;
  • a unique identification data of said proxy in the communication network (REG-ID1 for the proxy server 2 and X REG-ID2 to the proxy server 2 2 of FIG 3) is also preferably generated (steps 54, 64 respectively ) by each proxy server, to allow the identification of these proxy servers in the registration process and to identify the registration path.
  • These data REG-ID1 and REG-ID2 uniquely designating their respective proxy servers (ie there must not be several proxy servers associated with the same data REG-ID), they can for example take the form of a chosen integer randomly between 1 and 2 31 associated with the proxy server during its prior configuration. Alternatively, they can be automatically generated by each proxy server from a distinctive feature of these servers.
  • the value REG-ID1, respectively REG-ID2 is thus used by the proxy server 2i, respectively 2 2 , for all recordings made on behalf of client equipment to which it proceeds.
  • each proxy server prepares (steps 55 and 65 respectively) a registration request on behalf of the client device 1 (REG_REQ1 for the proxy server 2i and REG_REQ2 for the proxy server 2 ) in which it inserts the aforementioned respective data, and transmits this registration request (steps 56, respectively 66) to the registration server 4 in order to proceed to the recording (steps 57, 67 respectively) of the client equipment 1.
  • FIG. 4 illustrates a particular example of the recording method according to a particular embodiment of the invention using a single proxy server, as described previously with reference to FIG. 2.
  • the client equipment 1 is an IP PBX telephone routing equipment, designated here by "IP-PBX", whose registration is carried out with an IMS network during the establishment of a secure connection in accordance with the TLS protocol, as follows:
  • this IP-PBX equipment proceeds to establish a TCP session with a P-CSCF server of the IMS network (step 110), either using the IP address of the P-CSCF if it is configured in the IP-PBX equipment, or by determining it by means of a DNS server (using the principle described in RFC 3263);
  • the establishment of a secure TLS connection (phase 120) between the IP-PBX equipment and the P-CSCF server can start with an authentication phase (phase 121).
  • the IP-PBX equipment first signals that it has just connected (step 122) to the P-CSCF server, which then returns a certain amount of information (step 123), including an authentication request to obtain a digital certificate ("CertificateRequest" in Figure 3) to perform mutual authentication.
  • the IP-PBX client equipment sends back to the P-CSCF server (step 124) the authentication certificate assigned to it ("Certificate (subjectAltName: sip: site.enterprise.com)" In Figure 3), which contains authentication data in the form of a SIP URI "sip: site.73.com” designating the domain name associated with the IP-PBX client equipment.
  • the IP-PBX client equipment also returns a proof associated with this certificate, generated through its own private key, in order to allow the P-CSCF server to authenticate the identity of this client equipment.
  • the P-CSCF server extracts the SIP URI "sip: site.grown.com" designating the domain name associated with the client equipment IP-PBX and derives the following identification data:
  • IP-PBX client equipment in the form of the following NAI identifier "site.7%.com@busti.operator.com”;
  • the P-CSCF server can also deduce a UUID URN universal unique identifier from the SIP URI "sip: site.
  • the P-CSCF server then generates a "SIP REGISTER" request with header fields filled in as follows:
  • the "Request URI" field is completed with the domain name of the IMS network as configured in the P-CSCF (ie the same domain name for all client devices connected to the IMS network);
  • each P-CSCF server can additionally insert in this "Contact" field the universal single instance identifier URN UUID obtained from the SIP URI of the IP-PBX client device, as well as the P-CSCF server-specific "reg-id" value (not the IP-PBX client device);
  • the other header fields are supplemented in a conventional manner, according to the specification 3GPP TS 24.229.
  • the "SIP REGISTER" request is then transmitted (step 131) by the P-CSCF server to the S-CSCF server, via the I-CSCF server, so that the S-CSCF server applies the recording procedure according to TS 24.229, using the aforementioned IMPU and ⁇ , as well as optionally the URN UUID instance unique identifier and the aforementioned reg-id value.
  • the S-CSCF server returns (step 133) a SIP-type acknowledgment message "200 OK" to the P-CSCF server, via the server I- CSCF. This acknowledgment message is not forwarded to the IP-PBX equipment, so that this record is completely transparent to the latter.
  • the use of registration requests according to the SIP protocol has been described.
  • the invention is not limited to this single protocol, and can be extended to any other signaling protocol of a core network presenting registration requests, such as the H.323 protocol for example.
  • IP PBX equipment has been cited as a particular example of customer equipment registering according to the method of the present invention.
  • other equipment may be considered, such as a voice server, a call center or an interactive gaming platform.
  • the mutual authentication phase exemplified uses the TLS protocol.
  • the invention is however not limited to this single authentication protocol, and can be applied to any other authentication protocol in which the client equipment, seeking to authenticate with the network, returns to a proxy server.
  • the network in charge of validating this authentication an authentication certificate may contain authentication data for the deduction of identification data in the communication network of this client equipment.
  • SSL, SSH or IPsec protocols can be used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé d'enregistrement d'un équipement client (1) auprès d'un serveur d'enregistrement (4) d'un réseau de communication (IP_NET), au moyen d'au moins une requête d'enregistrement (REG_REQ) transmise (17) par au moins un serveur mandataire (2) du réseau de communication à un serveur d'enregistrement (4) du réseau de communication, le procédé comprenant les étapes suivantes, réalisées par ledit au moins un serveur mandataire (2) du réseau: obtention (13) d'au moins une donnée d'identification (ID) de l'équipement client dans le réseau, à partir de données d'authentification reçues (12) dudit équipement client lors d'une phase d'authentification dudit équipement client; et élaboration (15) de la requête d'enregistrement (REG_REQ) de l'équipement client, dans laquelle est insérée ladite au moins une donnée d'identification de l'équipement client dans le réseau. L'invention concerne également un serveur mandataire (2) mettant en œuvre le procédé d'enregistrement susmentionné et trouve une application particulière dans le cadre de l'enregistrement d'un équipement d'acheminement téléphonique (PABX IP) dans un réseau IMS, lorsque cet équipement n'a pas la capacité de s'enregistrer lui-même ou n'utilise pas cette fonctionnalité d'enregistrement quand il en dispose.

Description

Enregistrement d'un équipement client par l'intermédiaire d'un serveur mandataire dans un réseau de communication
La présente invention concerne l'enregistrement d'équipements clients au sein d'un réseau de communication, et plus particulièrement l'enregistrement d'équipements de type IP-PBX dans un réseau IP comprenant un cœur de réseau disposant d'une architecture IMS (pour IP Multimedia System).
Lorsque l'on souhaite qu'un équipement client bénéficie des services offerts par un réseau de communication, il est habituellement nécessaire que cet équipement client s'enregistre auprès de ce réseau.
C'est en particulier la cas lorsque le réseau de communication est un réseau IP (i.e. un réseau utilisant le protocole IP) comprenant un réseau d'accès (de type ADSL, xDSL, WiFi, WiMAX, GSM, UMTS ou LTE, par exemple) associé à un cœur de réseau IMS, c'est- à-dire un cœur de réseau présentant une architecture de réseau IMS telle qu'introduite par l'organisme de normalisation 3GPP (« Jd Génération Partnership Project») pour les réseaux mobiles, puis reprise par l'organisme TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking ») pour les réseaux fixes. L'architecture de réseau IMS permet notamment l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'architecture IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.
Une telle architecture de réseau IMS comprend notamment :
- un ou plusieurs serveurs d'enregistrement, appelés « S-CSCF » (pour Serving-Çall Server Çontrol Function) aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau ;
- un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (pour Interrogating- Çall Server Çontrol Function) et d'ailleurs souvent combinés physiquement avec les serveurs de type S-CSCF pour constituer des serveurs dénotés « I/S-CSCF », qui, au moment de l'enregistrement d'un équipement client, interrogent un serveur d'abonnés appelé « HSS » (pour Home Subscriber Server), afin de pouvoir sélectionner un serveur S- CSCF possédant les caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateur ;
- un ou plusieurs serveurs HSS, contenant chacun une base de données-clients. Chaque serveur HSS contient le « profil » d'un certain nombre d'équipements clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits ;
- un ou plusieurs serveurs mandataires (aussi appelés serveurs « proxy »), désignés par « P-CSCF » (pour Proxy-Çall Server Çontrol Function), servant d'entité de raccordement entre le cœur de réseau IMS et le réseau d'accès utilisé par les équipements clients, et qui sont donc aptes à retransmettre tous les messages de signalisation entre les équipements clients d'une part et les serveurs S-CSCF ou I-CSCF d'autre part. Ces messages de signalisation sont notamment des messages selon le protocole SIP, tel que défini par l'IETF {Internet Engineering Task Force) dans le document RFC 3261, lequel permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP.
Ainsi, l'équipement client souhaitant s'enregistrer auprès d'un tel réseau IP envoie habituellement un message « SIP REGISTER » contenant des informations d'identification vers un serveur P-CSCF, lequel relaie ce message vers un serveur I-CSCF qui, après vérification auprès d'un serveur HSS, retransmet ce message d'enregistrement vers le serveur S-CSCF approprié afin que ce dernier procède à l'enregistrement de l'équipement client.
Il existe cependant des cas où des équipements clients n'ont pas la capacité de s'enregistrer (par exemple parce qu'ils supportent le protocole SIP mais pas l'architecture IMS) ou, s'ils ont cette capacité, ne l'utilisent pas. C'est notamment le cas de certains équipements d'acheminement téléphonique privés, désignés par « PABX IP » (« IP-PBX » en anglais), utilisés par des entreprises pour raccorder un ensemble de terminaux internes au réseau téléphonique.
Actuellement, deux modes de raccordement d'un équipement PABX IP à un réseau IMS sont normalisés par l'organisme TISPAN :
1) Le mode "Peering-based business trunking" : l'équipement PABX IP est alors considéré par l'opérateur comme étant un réseau tiers et raccordé à une passerelle IBCF (Interconnection Border Control Functions). Ce premier mode de raccordement pose cependant des problèmes pour raccorder un grand nombre de petits équipements PABX IP (c'est-à-dire les PABX IP gérant un faible nombre d'extensions), car la passerelle IBCF n'a pas été prévue pour raccorder des clients mais des gros réseaux, et la configuration est fastidieuse.
2) Le mode "Subscription-based" : l'équipement PABX IP est alors considéré par le réseau comme un terminal IMS. Ce deuxième mode de raccordement est certes plus facile à gérer pour l'opérateur, notamment pour les petits équipements PABX IP. Cependant, ce deuxième mode de raccordement implique que l'équipement PABX IP doit s'enregistrer auprès du réseau IMS comme un terminal normal. Or de nombreux équipements PABX IP disponibles sur le marché ne supportent pas l'enregistrement, car ils sont en conformité avec une option de la recommandation « SIPconnect » du SIP Forum, appelée « Static mode ».
Des travaux sont actuellement en cours au 3GPP, sous le thème de travail "Feasibility study on IMS Business Trunking for IP-PBX in Static Mode of Opération", pour faire évoluer l'architecture IMS de façon à permettre le raccordement d'équipements PABX IP ne supportant pas l'enregistrement, tout en minimisant l'effort de configuration (« provisioning » en anglais). Dans le cadre de ces travaux, le rapport technique TR 23.897 vO.4.0 décrit, dans la clause 6.4 du TR 23.897, une solution basée sur une évolution du serveur P-CSCF pour raccorder à ce dernier des équipements PABX IP ne supportant pas l'enregistrement.
Un inconvénient majeur de cette solution est qu'elle requiert que les données de chaque équipement PABX IP (en particulier les adresses IMS publique et privée de ces PABX IP) soient préconfigurées dans un serveur P-CSCF, avant que ce serveur P-CSCF puisse initier une quelconque procédure d'enregistrement IMS pour le compte de ces équipements PABX IP. Ceci implique un effort important de configuration, puisqu'il faut intervenir (éventuellement manuellement) au niveau du serveur P-CSCF pour chaque ajout d'un nouveau client. Cette situation est problématique notamment quand il faut fournir un service de type "business trunking" à un nombre important de petits équipements PABX IP, puisque l'ajout d'un nouvel équipement PABX IP est fréquent dans ce cas.
De plus, pour permettre une plus haute disponibilité de service, il est recommandé de mettre en place une redondance au niveau du serveur P-CSCF, afin qu'en cas de défaillance d'un serveur P-CSCF, un autre serveur P-CSCF puisse prendre le relai. Ceci nécessite alors que les données des équipements PABX IP soient préconfigurées dans deux serveurs P-CSCF (voire plus), ce qui multiplie d'autant plus l'effort de configuration de ces serveurs. La présente invention a pour objet de remédier aux inconvénients susmentionnés, en proposant une gestion de l'enregistrement d'un équipement client au niveau d'un équipement mandataire du réseau ne nécessitant aucune configuration particulière liée à cet équipement client au niveau de l'équipement mandataire.
Elle propose à cet effet un procédé d'élaboration d'une requête d'enregistrement d'un équipement client dans un réseau de communication, mis en œuvre par au moins un serveur mandataire dudit réseau, comprenant l'obtention d'au moins une donnée d'identification de l'équipement client dans le réseau, à partir de données d'authentification de cet équipement client reçues lors d'une phase d'authentification de cet équipement client, et l'élaboration de la requête d'enregistrement de l'équipement client, dans laquelle est insérée la au moins une donnée d'identification de l'équipement client dans le réseau. Ceci permet au serveur mandataire de déclencher l'enregistrement de l'équipement client dans le réseau, pour le compte de cet équipement client, sans avoir besoin de préconfigurer localement le serveur mandataire avec des données d'identification de cet équipement client, et ce de manière transparente aussi bien pour l'équipement client que pour le serveur d'enregistrement du réseau. Permet d'éviter également des enregistrements en masse lors du démarrage du serveur mandataire, ce qui est le cas lorsque ce dernier est préconfiguré localement.
Selon une caractéristique particulière, le procédé comprend en outre la configuration préalable dudit au moins un serveur mandataire, cette configuration préalable comprenant la mémorisation, dans ledit au moins un serveur mandataire, d'une règle de dérivation permettant de déduire la au moins une donnée d'identification de l'équipement client à partir d'au moins une partie des données d'authentification de cet équipement client, cette règle étant utilisée pour obtenir la au moins une donnée d'identification. Il est ainsi possible de configurer certains serveur mandataires du cœur de réseau pour la mise en œuvre de l'invention, et ce une fois pour toute. N'importe quel serveur mandataire du cœur de réseau peut être ainsi configuré, ce qui offre un gain en termes de flexibilité et de résilience.
Selon un mode de réalisation particulier, les données d'authentification de l'équipement client comprennent un identifiant de domaine associé à l'équipement client, ladite au moins une donnée d'identification comprenant au moins un identifiant parmi un identifiant public de l'équipement client dans le réseau de communication et un identifiant privé de l'équipement client dans le réseau de communication, généré à partir dudit identifiant de domaine. Dans un autre mode de réalisation particulier dans lequel les étapes d'obtention et d'élaboration sont réalisées par plusieurs serveurs mandataires, une donnée d'identification unique d'instance est avantageusement obtenue en outre à partir des données d'authentification reçues dudit équipement client, cette donnée d'identification unique d'instance étant insérée dans les requêtes d'enregistrement élaborées par les serveurs mandataires. L'utilisation de plusieurs serveurs mandataires pour l'enregistrement de l'équipement client offre une résilience accrue : si un serveur mandataire principal, le chemin physique connectant ce serveur mandataire principal à l'équipement client ou le réseau d'accès connectant ce serveur mandataire principal à l'équipement client devenait défaillant, un autre serveur mandataire peut alors être utilisé par l'équipement client.
Dans cet autre mode de réalisation dans lequel les étapes d'obtention et d'élaboration sont réalisées par plusieurs serveurs mandataires, le procédé peut comprendre en outre, pour chacun des serveurs mandataires, la génération d'une donnée d'identification unique de ce serveur mandataire dans le réseau de communication et l'insertion de cette donnée d'identification unique de ce serveur mandataire dans la requête d'enregistrement élaborée par ledit serveur mandataire. Il est ainsi possible de distinguer les différents enregistrements d'un même équipement client, en fonction du serveur mandataire initiateur de l'enregistrement, pour éviter que l'enregistrement réalisé par le deuxième serveur mandataire, dans l'ordre chronologique, écrase l'enregistrement réalisé par le premier serveur mandataire.
Selon un mode de réalisation particulier, les données d'authentification sont sous forme d'un certificat d'authentification transmis, par l'équipement client, en réponse à une requête d'authentification émise par le au moins un serveur mandataire au cours d'une phase d'authentification. Dans un autre mode particulier de réalisation, le réseau de communication est un réseau IP comprenant un cœur de réseau présentant une architecture de type IMS et utilisant le protocole SIP, le message d'enregistrement est un message de type « SIP REGISTER », le serveur mandataire est un serveur P-CSCF et l'entité d'enregistrement est un serveur S-CSCF.
La présente invention propose en outre un procédé d'élaboration d'une requête de désenregistrement d'un équipement client dans un réseau de communication comprenant les étapes suivantes, mises en œuvre par au moins un serveur mandataire de ce réseau lorsque ce serveur mandataire ne reçoit aucun message de maintien en vie d'une connexion sécurisée établie avec l'équipement client pendant une durée déterminée ou lorsque ce serveur mandataire reçoit un message de déconnexion de ladite connexion sécurisée :
récupération d'au moins une donnée d'identification de l'équipement client dans le réseau, cette au moins une donnée d'identification étant obtenue par le serveur mandataire à partir de données d'authentification de l'équipement client reçues lors d'une phase d'authentification dudit équipement client ; et
élaboration de la requête de désenregistrement de l'équipement client, dans laquelle est insérée ladite au moins une donnée d'identification de l'équipement client dans le réseau.
Il est ainsi possible de désenregistrer l'équipement client afin d'éviter de maintenir inutilement l'enregistrement de cet équipement dans le réseau après que la connexion sécurisée avec cet équipement client ait été interrompue, et ce de manière transparente aussi bien pour l'équipement client que pour le serveur d'enregistrement.
La présente invention propose par ailleurs un procédé d'enregistrement d'un équipement client dans un réseau de communication comprenant les étapes suivantes, mises en œuvre par au moins un serveur mandataire suite à la réception de données d'authentification de l'équipement client lors d'une phase d'authentification de cet équipement client :
élaboration d'une requête d'enregistrement de l'équipement client au moyen du procédé ci-avant ; et
envoi de cette requête d'enregistrement à un serveur d'enregistrement du réseau de communication, cette requête d'enregistrement étant utilisée par le serveur d'enregistrement pour enregistrer l'équipement client dans le réseau de communication.
Selon un mode de réalisation particulier, lorsque le serveur mandataire ne reçoit aucun message de maintien en vie d'une connexion sécurisée établie avec l'équipement client pendant une durée déterminée ou lorsque le serveur mandataire reçoit un message de déconnexion de ladite connexion sécurisée, le procédé d'enregistrement comprend l'élaboration d'une requête de désenregistrement de l'équipement client au moyen du procédé ci-avant et l'envoi de cette requête de désenregistrement au serveur d'enregistrement, cette requête de désenregistrement étant utilisée par le serveur d'enregistrement pour désenregistrer l'équipement client dans le réseau de communication.
La présente invention propose également un serveur mandataire d'un réseau de communication, apte à élaborer une requête d'enregistrement d'un équipement client dans le réseau de communication, destinée à être transmise à un serveur d'enregistrement du réseau de communication, comprenant un module de traitement de données configuré pour, suite à la réception de données d'authentification émises par l'équipement client lors d'une phase d'authentification de cet équipement client, obtenir au moins une donnée d'identification de l'équipement client dans le réseau de communication, à partir des données d'authentification reçues dudit équipement client, et élaborer la requête d'enregistrement de l'équipement client, en y insérant cette au moins une donnée d'identification de l'équipement client dans le réseau.
La présente invention propose en outre un réseau de communication, comprenant un cœur de réseau et apte à enregistrer un équipement client afin de lui offrir un service, le cœur de réseau comprenant au moins un serveur mandataire tel que décrit ci-avant et un serveur d'enregistrement configuré pour enregistrer l'équipement client, suite à la réception d'une requête d'enregistrement de cet équipement client élaborée par le serveur mandataire.
Selon une implémentation particulière, les différentes étapes des procédés ci-avant sont mises en œuvre par un logiciel ou programme d'ordinateur, ce logiciel comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un serveur mandataire d'un réseau et étant conçu pour commander l'exécution des différentes étapes de ce procédé. En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme d'un 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 ou processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Ce 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 ou un disque dur. D'autre part, ce 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, ce 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.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture dans la description détaillée ci-après de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs, et des figures annexées dans lesquelles :
- la figure 1 illustre un système de communication dans lequel est mise en œuvre la présente invention ;
- la figure 2 illustre les étapes d'un procédé d'enregistrement selon un mode de réalisation particulier de l'invention, dans lequel la génération de la requête d'enregistrement de l'équipement client est confiée à un unique serveur mandataire du réseau de communication ;
- la figure 3 illustre les étapes d'un procédé d'enregistrement selon un autre mode de réalisation particulier de l'invention, dans lequel la génération de la requête d'enregistrement de l'équipement client est réalisée par plusieurs serveurs mandataires du réseau de communication ; et
- la figure 4 illustre un exemple particulier du procédé d'enregistrement selon un mode de réalisation particulier de l'invention utilisant un seul serveur mandataire, tel que décrit précédemment.
On se réfère tout d'abord à la figure 1 qui illustre un système de communication dans lequel est mise en œuvre la présente invention.
Dans ce système, l'équipement client 1 est connecté au réseau IP_NET d'un opérateur de télécommunications, constitué d'un réseau d'accès ACC_NET et d'un cœur de réseau IMS_CN.
L'équipement client 1 est un équipement client à enregistrer dans le cœur de réseau IMS_CN, afin de lui permettre d'accéder à certains services offerts par le réseau IP_NET (téléphonie, voix sur IP, internet...), et qui n'a soit pas la possibilité d'effectuer un tel enregistrement parce qu'il ne dispose pas d'une telle fonctionnalité d'enregistrement, soit qui n'utilise pas lui-même cette fonctionnalité s'il en dispose. A titre d'exemple non limitatif, cet équipement client 1 peut être un équipement PABX IP tel que discuté précédemment.
Le réseau d'accès ACC_NET peut être un réseau radio, conforme ou non aux spécifications définies par l'organisme de normalisation 3GPP, ou bien un réseau filaire, optique ou xDSL. Quant à cœur de réseau IMS_CN, il comprend notamment un équipement mandataire 2 connecté à un serveur d'interrogation 3 et un serveur d'enregistrement 4, lesquels sont eux-mêmes connectés entre eux ainsi qu'à un serveur d'abonnés 5.
L'équipement mandataire 2 sert notamment à relayer les messages de signalisation entre l'équipement client 1 et les autres serveurs du cœur de réseau IMS_CN, et dispose d'un module de traitement de données, typiquement sous forme d'un processeur associé à une mémoire, permettant de mettre en œuvre le procédé décrit par la suite.
Ainsi, dans le cas particulier où ce cœur de réseau IMS_CN présente une architecture de type IMS, le serveur mandataire 2 est un serveur P-CSCF, le serveur d'interrogation 3 est un serveur I-CSCF, le serveur d'enregistrement 4 est un serveur S- CSCF et le serveur d'abonnés 5 est un serveur HSS, certains de ces différents serveurs pouvant être rassemblés au sein d'une même entité, le cas échéant. Dans le cas d'une telle architecture IMS, le protocole de signalisation SIP est alors utilisé pour les échanges avec l'équipement client 1.
On se réfère maintenant à la figure 2 qui illustre les étapes d'un procédé d'enregistrement selon un mode de réalisation particulier de l'invention, dans lequel la génération de la requête d'enregistrement de l'équipement client est effectuée par un unique serveur mandataire du réseau de communication.
Dans ce mode de réalisation, ce n'est pas l'équipement client 1 lui-même qui génère le message de requête d'enregistrement, pour s'enregistrer dans le réseau IMS_CN, mais le serveur mandataire 2. Pour ce faire, le serveur mandataire 2 est avantageusement configuré au préalable (étape 10) afin de pouvoir mettre en œuvre le procédé de la présente invention, cette configuration comprenant notamment la mémorisation d'une ou plusieurs règles permettant d'utiliser tout ou partie des données d'authentification reçues de l'équipement client 1 pour en déduire des informations d'identification permettant d'enregistrer cet équipement client 1, de manière transparente pour ce dernier, comme il sera vu plus loin. Une telle configuration préalable a typiquement lieu au moment de la mise en service du serveur mandataire, n'est pas spécifique à un type d'équipement client particulier et est la même pour tous les serveurs à laquelle elle s'applique.
Pour déduire ces informations d'identification de l'équipement client, le serveur mandataire 2 utilise des données d'authentification AUTH reçues de l'équipement client 1 (étape 23) durant une phase d'authentification (phase 20), déclenchée par la connexion de l'équipement client 1 au réseau IP_NET, qui est par exemple une phase d'authentification avec authentification client conforme au protocole TLS (pour Transport Laver Security), préalable à tout échange d'informations entre l'équipement client 1 et le réseau IP_NET.
Ces données d'authentification AUTH de l'équipement client 1 sont typiquement mémorisées dans l'équipement client 1 (soit manuellement au préalable, soit au cours d'une préconfiguration automatique) et incluses dans un certificat d'authentification (désigné par CERT(AUTH) sur la figure 2) retourné par l'équipement client 1, suite à la réception (étape 21) d'une requête d'authentification émise par le serveur mandataire 2 lorsqu'il détecte la connexion de l'équipement client 1 au réseau IP_NET et qu'il lance la phase d'authentification.
Ainsi, dans le cas particulier d'un cœur de réseau IMS utilisant le protocole SIP, ces données d'authentification AUTH peuvent correspondre à un nom de domaine attribué à l'équipement PABX IP, identifié par une URI SIP ou un FQDN, et inséré dans le certificat d'authentification retourné par l'équipement client 1 lors de la phase d'authentification. En d'autres termes, les données d'authentification AUTH peuvent prendre la forme suivante :
AUTH= « sip : (Nom de domaine du PABX IP) »
Après avoir reçu un tel certificat d'authentification et authentifié l'équipement client 1, ce qui déclenche l'établissement d'une connexion sécurisée (phase 30) entre l'équipement client 1 et le réseau IP_NET, le serveur mandataire 2 peut extraire du certificat les données d'authentification AUTH de l'équipement client 1 pour en déduire (étape 31), au moyen d'une règle R de dérivation mémorisée lors de la configuration préalable susmentionnée du serveur mandataire 2, une ou plusieurs données d'identification ID de l'équipement client 1 dans le réseau de communication, cette/ces donnée(s) d'identification ID servant à enregistrer cet équipement dans le cœur de réseau IMS, et donc dans le réseau IP_NET.
La ou les données d'identification ID ainsi obtenues, à partir de ces données d'authentification et au moyen de cette règle R de dérivation, sont avantageusement également mémorisées, au préalable, au niveau d'un serveur d'abonnés (e.g. un serveur HSS dans le cas d'un cœur de réseau IMS) lors de la souscription de l'utilisateur de l'équipement client 1, afin de permettre la validation ultérieure de l'enregistrement.
Parmi ce(s) donnée(s) d'identification ID déduite(s) des données d'authentification AUTH reçues de l'équipement client 1, une première donnée d'identification ID1 peut ainsi être un identifiant public de l'équipement client 1 dans le réseau de communication, cet identifiant public ID1 étant construit à partir des données d'authentification, par exemple au moyen d'une règle R de dérivation prenant la forme d'une fonction injective associant un identifiant public ID1 aux données d'authentification AUTH.
Une telle règle R peut par exemple consister à ajouter aux données d'authentification AUTH une extension EXT liée au réseau IMS_CN :
AUTH -> ID1=AUTH@EXT
Ainsi, dans le cas particulier d'un réseau cœur IMS utilisant le protocole SIP, cet identifiant public est l'identifiant public IMS (« IMS Public User Identity » en anglais ou IMPU) et peut prendre la forme suivante :
ID1 = « sip : (Nom de domaine du PABX IP)@(Nom de domaine dans le réseau IMS) »
Une deuxième donnée d'identification ID2, déduite également des données d'authentification AUTH reçues de l'équipement client 1, peut être un identifiant privé de l'équipement client 1 (i.e. une adresse privée utilisée par l'opérateur du réseau IP_NET), cet identifiant privé ID2 étant construit à partir des données d'authentification AUTH, par exemple au moyen d'une règle R' de dérivation prenant la forme d'une fonction injective associant un identifiant privé ID2 aux données d'authentification AUTH, par exemple en ajoutant à une partie des données d'authentification AUTH l'extension EXT liée au réseau IMS_CN.
Pour reprendre l'exemple d'un réseau cœur IMS utilisant le protocole SIP, cet identifiant privé est alors l'identifiant privé IMS (« IMS Private User Identity » en anglais ou IMPI), prenant typiquement la forme d'un identifiant d'accès au réseau (NAI en anglais), et peut prendre la forme suivante :
ID2 = « (Nom de domaine du PABX IP)@(Nom de domaine dans le réseau IMS) »
Une fois obtenue(s) la ou les donnée(s) d'identification de l'équipement client 1 dans le réseau, le serveur mandataire 2 mémorise d'une part ces données d'identification et élabore (étape 33) une requête d'enregistrement (REG_REQ) de l'équipement client, selon le protocole de signalisation utilisé dans le cœur de réseau IMS_CN (par exemple une requête « SIP REGISTER » lorsque ce réseau cœur est de type IMS utilisant le protocole SIP) dans laquelle est insérée cette ou ces donnée(s) d'identification.
Cette requête d'enregistrement REG_REQ est ensuite envoyée (étape 35) vers le serveur d'enregistrement 4, éventuellement par l'intermédiaire du serveur d'interrogation 3, afin que ce serveur d'enregistrement 4 procède à l'enregistrement (étape 37) de l'équipement client 1 dans le cœur de réseau IMS_CN, donc dans le réseau IP_NET, en utilisant les données d'identification de cet équipement client 1 dans le réseau. Cette dernière étape d'enregistrement, au niveau du serveur d'enregistrement, est classique et ne sera pas décrite en détail. Ainsi, le cycle de vie de l'enregistrement de l'équipement client 1 est géré durant la connexion sécurisée 30, non pas par l'équipement client 1 lui-même, mais par le serveur mandataire 2, pour le compte de l'équipement client 1, et ce sur la base d'événements ayant lieu durant la phase d'authentification 20 de l'équipement client 1 auprès du réseau IP_NET. La connexion initiale de l'équipement client 1 au réseau IP_NET, entraînant le déclenchement de la phase d'authentification 20 de l'équipement client 1, déclenche également ainsi, indirectement et de manière transparente pour l'équipement client 1, l'enregistrement de ce dernier dans le cœur de réseau IMS_CN du réseau IP_NET.
Habituellement, la connexion authentifiée 30 établie suite à la phase d'authentification 10 est maintenue grâce à l'envoi (étape 38) de messages de type « keep-alive » au serveur mandataire 2. De tels messages peuvent être utilisés ici par le serveur mandataire 2 pour maintenir, ou supprimer, l'enregistrement de l'équipement client 1.
En particulier, tant que le serveur mandataire 2 reçoit des messages de type « keep-alive » de l'équipement client 1 (par exemple au moins un certain nombre de « keep-alive » durant une période de temps déterminée), signifiant que la connexion authentifiée est active, l'enregistrement de l'équipement client 1 est maintenu dans la mesure où le serveur mandataire 2 rafraîchit cet enregistrement auprès du serveur d'enregistrement 4 (par exemple en fonction d'une durée d'enregistrement fixée par ce serveur d'enregistrement 4) en lui renvoyant régulièrement la requête REG_REQ (étape 39) après la réception d'un ou plusieurs messages de type « keep-alive », en réutilisant les données d'identification mémorisées lors de l'élaboration de la requête REG_REQ initiale.
Par contre, si le serveur mandataire 2 ne reçoit plus de messages de type « keep- alive » de l'équipement client 1 durant une période de temps déterminée T0 (par ex. quelques minutes), ou encore s'il reçoit un message explicite de déconnexion de la connexion authentifiée, le serveur mandataire 2 peut décider d'interrompre l'enregistrement de l'équipement client 1 lors d'une phase de désenregistrement 40.
Cette phase de désenregistrement comprend la récupération de(s) donnée(s) d'identification ID insérées précédemment dans la requête d'enregistrement REG_REQ initiale, telles que mémorisées par le serveur mandataire 2, et l'élaboration (étape 41), par le serveur mandataire 2, d'une requête de désenregistrement UNREG_REQ (e.g. lorsque le protocole SIP est employé, une requête SIP « REGISTER » avec un en-tête « expires : 0 »), contenant notamment ce(s) donnée(s) d'identification ID, et l'envoi (étape 43) de cette requête UNREG_REQ vers le serveur d'enregistrement 4, afin que celui-ci supprime (étape 45) l'enregistrement de l'équipement client 1 dans le réseau, au moyen de(s) donnée(s) d'identification ID de cet équipement client.
En même temps que le serveur mandataire 2 désenregistre l'équipement client auprès du serveur d'enregistrement 4, le serveur mandataire 2 peut mettre fin à la connexion authentifiée avec l'équipement client 1, en lui envoyant un message de fermeture de cette connexion (étape 47). Si ce message parvient à l'équipement client 1, ce dernier sera ainsi incité à initier une nouvelle connexion sécurisée, ce qui donnera lieu à un nouvel enregistrement par l'intermédiaire du serveur mandataire 2, et ainsi de suite.
La durée d'enregistrement de l'équipement client 1 dans le réseau correspond ainsi à la durée de la connexion sécurisée 30 entre cet équipement client 1 et le serveur mandataire 2. L'authentification de l'équipement client ayant été effectuée dès l'établissement de cette connexion sécurisée 30, il n'est plus nécessaire d'effectuer d'authentification supplémentaire tant que cette connexion sécurisée est maintenue (e.g. pour chaque requête SIP de type « SUBSCRIBE » ou « INVITE » émise par l'équipement client 1 pendant la connexion sécurisée 30).
On se réfère maintenant à la figure 3 qui illustre les étapes d'un procédé d'enregistrement selon un autre mode de réalisation particulier de l'invention, dans lequel plusieurs requêtes d'enregistrement de l'équipement client sont construites par une pluralité de serveurs mandataires du réseau de communication.
En effet, il existe des situations dans lesquelles il convient de connecter l'équipement client au cœur de réseau IMS_CN par l'intermédiaire non pas d'un, mais de plusieurs serveurs mandataires. Ceci peut être le cas, par exemple, lorsqu'on souhaite se prémunir d'une éventuelle défaillance d'un unique serveur mandataire qui mettrait en œuvre le procédé tel que décrit précédemment en figure 2, et donc créer une redondance de serveurs mandataires capables de mettre en œuvre la présente invention. Ceci peut aussi être le cas notamment lorsque le volume de communications avec l'équipement client justifie une répartition de la charge entre plusieurs serveurs mandataires. Ainsi, sur la figure 3, deux serveurs mandataires 2X et 22 sont illustrés, sans que ce nombre soit limitatif.
Dans cet autre mode de réalisation, chacun des serveurs mandataires 2X et 22 est avantageusement configuré au préalable (étape 10), de manière identique et similairement à ce qui a été décrit en relation avec la figure 2.
Par la suite, l'équipement client 1 lance l'établissement d'une connexion sécurisée avec chacun des serveurs mandataires 2i et 22 (phases d'établissement de connexion sécurisée 50 et 60) en envoyant (étapes 51 et 61) à chacun des serveurs mandataires 2i et 22, lors d'une phase initiale d'authentification de cet équipement, un message de réponse d'authentification contenant des données d'authentification AUTH telles que décrites précédemment.
Suite à la réception de ce message de réponse d'authentification, chacun des serveurs mandataires 2i et 22 procède, indépendamment et de manière identique, de la manière suivante :
- une ou plusieurs données d'identification ID de l'équipement client 1 dans le réseau de communication sont déduites des données d'authentification AUTH reçues (étapes 52, respectivement 62), similairement à l'étape 31 décrite précédemment ;
- une donnée d'identification unique d'instance, désignée par UUID sur la figure 3, est avantageusement obtenue en outre (étapes 53, respectivement 63) à partir des données d'authentification reçues dudit équipement client. Cet identifiant unique peut être construit à partir des données d'authentification AUTH au moyen d'une règle de dérivation mémorisée lors de la configuration préalable des serveurs mandataires, de manière à ce que, pour des données d'authentification données, ce soit toujours la même donnée d'identification unique d'instance UUID qui soit retournée. De plus, pour des données d'authentification distinctes, cette règle de dérivation retourne nécessairement des identifiants uniques d'instance différents. Pour reprendre l'exemple d'un réseau cœur IMS utilisant le protocole SIP, cet identifiant unique ID3 peut être un identifiant unique universel d'instance (UUID URN en anglais), obtenu au moyen d'une règle de dérivation utilisant l'algorithme décrit dans la clause 4.3 du document RFC 4122 ;
- une donnée d'identification unique dudit serveur mandataire dans le réseau de communication (REG-ID1 pour le serveur mandataire 2X et REG-ID2 pour le serveur mandataire 22 sur la figure 3) est avantageusement également générée (étapes 54, respectivement 64) par chaque serveur mandataire, afin de permettre l'identification de ces serveurs mandataires dans le processus d'enregistrement et identifier le chemin d'enregistrement. Ces données REG-ID1 et REG-ID2 désignant de manière unique leurs serveurs mandataires respectifs (i.e. il ne doit pas y avoir plusieurs serveurs mandataires associés à une même donnée REG-ID), elles peuvent par exemple prendre la forme d'un entier choisi aléatoirement entre 1 et 231 associé au serveur mandataire lors de sa configuration préalable. Alternativement, elles peuvent être générées automatiquement par chaque serveur mandataire à partir d'une caractéristique distinctive de ces serveurs. La valeur REG-ID1, respectivement REG-ID2, est ainsi utilisée par le serveur mandataire 2i, respectivement 22, pour tous les enregistrements effectués pour le compte d'équipements clients auxquels il procède.
Une fois les différentes données susmentionnées obtenues ou générées, chaque serveur mandataire élabore (étapes 55, respectivement 65) une requête d'enregistrement pour le compte de l'équipement client 1 (REG_REQ1 pour le serveur mandataire 2i et REG_REQ2 pour le serveur mandataire 22) dans laquelle il insère les données respectives susmentionnées, et transmet cette requête d'enregistrement (étapes 56, respectivement 66) vers le serveur d'enregistrement 4 afin de procéder à l'enregistrement (étapes 57, respectivement 67) de l'équipement client 1.
On se réfère maintenant à la figure 4 qui illustre un exemple particulier du procédé d'enregistrement selon un mode de réalisation particulier de l'invention utilisant un seul serveur mandataire, tel que décrit précédemment en relation avec la figure 2.
Dans cet exemple particulier, l'équipement client 1 est un équipement d'acheminement téléphonique de type PABX IP, désigné ici par « IP-PBX », dont l'enregistrement est effectué auprès d'un réseau IMS lors de l'établissement d'une connexion sécurisée conforme au protocole TLS, de la manière suivante :
- dans un premier temps, typiquement lors de l'activation de l'équipement IP-PBX, cet équipement IP-PBX procède à l'établissement d'une session TCP avec un serveur P- CSCF du réseau IMS (étape 110), soit en utilisant l'adresse IP du P-CSCF si celle-ci est configurée dans l'équipement IP-PBX, soit en la déterminant au moyen d'un serveur DNS (en utilisant le principe décrit dans RFC 3263) ;
- une fois la session TCP établie, l'établissement d'une connexion sécurisée de type TLS (phase 120) entre l'équipement IP-PBX et le serveur P-CSCF peut démarrer par une phase d'authentification (phase 121). Au cours de cette phase d'authentification TLS, l'équipement IP-PBX signale tout d'abord qu'il vient de se connecter (étape 122) au serveur P-CSCF, lequel lui retourne alors un certain nombre d'informations (étape 123), notamment une requête d'authentification visant à obtenir un certificat numérique (« CertificateRequest » sur la figure 3) afin d'effectuer une authentification mutuelle.
- en réponse à cette requête d'authentification, l'équipement client IP-PBX renvoie au serveur P-CSCF (étape 124) le certificat d'authentification qui lui est assigné (« Certificate (subjectAltName : sip:site.enterprise.com) » sur la figure 3), lequel contient des données d'authentification sous la forme d'une URI SIP « sip:site.entreprise.com » désignant le nom de domaine associé à l'équipement client IP-PBX. L'équipement client IP-PBX retourne également une preuve associée à ce certificat, générée grâce à sa propre clé privée, afin de permettre au serveur P-CSCF d'authentifier l'identité de cet équipement client.
- après avoir reçu le certificat d'authentification émis par l'équipement client IP-PBX, le serveur P-CSCF en extrait l'URI SIP « sip:site.entreprise.com » désignant le nom de domaine associé à l'équipement client IP-PBX et en déduit les données d'identification suivantes :
- l'IMPU de l'équipement client IP-PBX, sous la forme de l'URI SIP suivante : « sip:site.entreprise.com@busti. operator.com » ;
- ΙΊΜΡΙ de l'équipement client IP-PBX, sous la forme de l'identifiant NAI suivant « site.entreprise.com@busti.operator.com » ;
De manière optionnelle, dans le cas où l'enregistrement par un autre serveur P- CSCF est envisagé, le serveur P-CSCF peut également déduire un identifiant unique universel d'instance UUID URN à partir de l'URI SIP « sip:site.entreprise.com » et générer en outre un identifiant unique spécifique au serveur P-CSCF dans le réseau (ici la valeur « reg-id=l »).
A partir des données susmentionnées, le serveur P-CSCF élabore alors une requête « SIP REGISTER » avec des champs d'en-tête remplis de la manière suivante :
- le champ « Request URI » est complété avec le nom de domaine du réseau IMS tel que configuré dans le P-CSCF (i.e. le même nom de domaine pour tous les équipements clients connectés au réseau IMS) ;
- les champs d'en-tête « From » et « To » sont complétés avec l'IMPU de l'équipement client IP-PBX, soit « sip:site.entreprise.com@busti. operator.com » ;
- le champ d'en-tête « Contact » est complété avec l'adresse IP source et le port de la connexion TLS. Dans le cas où plusieurs P-CSCF sont utilisés pour enregistrer l'équipement IP-PBX, chaque serveur P-CSCF peut insérer en outre dans ce champ « Contact » l'identifiant unique universel d'instance URN UUID obtenu à partir de l'URI SIP de l'équipement client IP-PBX, ainsi que la valeur « reg-id » spécifique au serveur P-CSCF (et non à l'équipement client IP-PBX) ;
- les autres champs d'en-tête sont complétés de manière classique, selon la spécification 3GPP TS 24.229.
Une fois la requête « SIP REGISTER » construite, elle est alors transmise (étape 131) par le serveur P-CSCF vers le serveur S-CSCF, par l'intermédiaire du serveur I-CSCF, afin que le serveur S-CSCF applique la procédure d'enregistrement selon la spécification TS 24.229, en utilisant l'IMPU et ΙΜΡΙ susmentionnés, ainsi qu'éventuellement l'identifiant unique d'instance URN UUID et la valeur reg-id susmentionnés. Une fois l'enregistrement de l'équipement IP-PBX effectué, le serveur S-CSCF renvoie (étape 133) un message d'acquittement de type SIP « 200 OK » au serveur P- CSCF, par l'intermédiaire du serveur I-CSCF. Ce message d'acquittement n'est pas retransmis à l'équipement IP-PBX, de sorte à ce que cet enregistrement soit totalement transparent pour ce dernier.
Bien entendu, l'invention n'est pas limitée aux exemples de réalisation ci-dessus décrits et représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans pour autant sortir du cadre de l'invention.
Ainsi, dans le cas d'un réseau IMS, l'utilisation de requêtes d'enregistrement selon le protocole SIP a été décrite. L'invention ne se limite cependant pas à ce seul protocole, et peut s'étendre à tout autre protocole de signalisation d'un cœur de réseau présentant des requêtes d'enregistrement, tel que le protocole H.323 par exemple.
Par ailleurs, un équipement PABX IP a été cité comme exemple particulier d'équipement client s'enregistrant selon le procédé de la présente invention. Cependant, d'autres équipements peuvent être considérés, tels qu'un serveur vocal, un centre d'appels ou une plateforme de jeux interactifs.
En outre, la phase d'authentification mutuelle citée en exemple utilise le protocole TLS. L'invention ne se limite cependant pas à ce seul protocole d'authentification, et peut s'appliquer à tout autre protocole d'authentification dans lequel l'équipement client, cherchant à s'authentifier auprès du réseau, retourne, à un serveur mandataire du réseau en charge de valider cette authentification, un certificat d'authentification pouvant contenir des données d'authentification permettant la déduction de données d'identification, dans le réseau de communication, de cet équipement client. Ainsi, les protocoles SSL, SSH ou IPsec peuvent être employés.

Claims

Revendications
1. Procédé d'élaboration d'une requête d'enregistrement (REQ_REG) d'un équipement client (1) dans un réseau de communication (IP_NET), mis en œuvre par au moins un serveur mandataire (2) dudit réseau, comprenant les étapes suivantes :
obtention (13) d'au moins une donnée d'identification (ID) de l'équipement client dans le réseau, à partir de données d'authentification dudit équipement client reçues (12) lors d'une phase d'authentification dudit équipement client ; et
élaboration (15) de la requête d'enregistrement (REQ_REG) de l'équipement client, dans laquelle est insérée ladite au moins une donnée d'identification de l'équipement client dans le réseau.
2. Procédé selon la revendication 1, comprenant en outre la configuration préalable (11) dudit au moins un serveur mandataire, ladite configuration préalable comprenant la mémorisation, dans ledit au moins un serveur mandataire, d'au moins une règle (R) de dérivation permettant de déduire la au moins une donnée d'identification à partir d'au moins une partie des données d'authentification, ladite règle étant utilisée pour obtenir la au moins une donnée d'identification.
3. Procédé selon la revendication 1 ou 2, dans lequel les données d'authentification de l'équipement client comprennent un identifiant de domaine associé à l'équipement client, ladite au moins une donnée d'identification (ID) comprenant au moins un identifiant parmi un identifiant public de l'équipement client dans le réseau de communication et un identifiant privé de l'équipement client dans le réseau de communication, généré à partir dudit identifiant de domaine.
4. Procédé selon l'une des revendications 1 à 3, dans lequel les étapes d'obtention et d'élaboration sont réalisées par plusieurs serveurs mandataires (21;22), et où une donnée d'identification unique d'instance (UUID) est obtenue (53,63) en outre à partir des données d'authentification reçues dudit équipement client, ladite donnée d'identification unique d'instance étant insérée (55,65) dans les requêtes d'enregistrement (REG_REQ) élaborées par les serveurs mandataires.
5. Procédé selon l'une des revendications 1 à 4, dans lequel les étapes d'obtention et d'élaboration sont réalisées par plusieurs serveurs mandataires, comprenant en outre, pour chacun des serveurs mandataires :
génération (54,64) d'une donnée d'identification unique (REG-ID1,REG-ID2) dudit serveur mandataire dans le réseau de communication ;
insertion (55,65) de ladite donnée d'identification unique dudit serveur mandataire dans la requête d'enregistrement (REQ_REG) élaborée par ledit serveur mandataire.
6. Procédé selon l'une des revendications précédentes, dans lequel les données d'authentification sont sous forme d'un certificat d'authentification (CERT(AUTH)) transmis (23), par l'équipement client, en réponse à une requête d'authentification émise (21) par le au moins un serveur mandataire au cours d'une phase d'authentification.
7. Procédé selon l'une des revendications précédentes, dans lequel le réseau de communication est un réseau IP comprenant un cœur de réseau présentant une architecture de type IMS et utilisant le protocole SIP, le message d'enregistrement est un message de type « SIP REGISTER », le serveur mandataire est un serveur P-CSCF et l'entité d'enregistrement est un serveur S-CSCF.
8. Procédé d'élaboration d'une requête de désenregistrement (UNREG_REQ) d'un équipement client (1) dans un réseau (IP_NET) comprenant les étapes suivantes, mises en œuvre par au moins un serveur mandataire (2) dudit réseau lorsque ledit serveur mandataire ne reçoit aucun message de maintien en vie d'une connexion sécurisée établie avec l'équipement client pendant une durée déterminée (T0) ou lorsque ledit serveur mandataire reçoit un message de déconnexion de ladite connexion sécurisée :
récupération d'au moins une donnée d'identification (ID) de l'équipement client dans le réseau, obtenue (31) par ledit serveur mandataire à partir de données d'authentification dudit équipement client reçues (23) lors d'une phase d'authentification dudit équipement client ; et
élaboration (41) de la requête de désenregistrement de l'équipement client, dans laquelle est insérée ladite au moins une donnée d'identification de l'équipement client dans le réseau.
9. Procédé d'enregistrement d'un équipement client (1) dans un réseau de communication (IP_NET) comprenant les étapes suivantes, mises en œuvre par au moins un serveur mandataire (2) suite à la réception (23) de données d'authentification dudit équipement client lors d'une phase d'authentification dudit équipement client :
élaboration (33) d'une requête d'enregistrement (REG_REQ) de l'équipement client au moyen du procédé selon l'une des revendications 1 à 8 ; et
envoi (35) de ladite requête d'enregistrement à un serveur d'enregistrement (4) du réseau de communication, ladite requête d'enregistrement étant utilisée par le serveur d'enregistrement pour enregistrer (37) l'équipement client dans le réseau de communication.
10. Procédé d'enregistrement selon la revendication 9, comprenant en outre les étapes suivantes, lorsque ledit serveur mandataire ne reçoit aucun message de maintien en vie d'une connexion sécurisée établie avec l'équipement client pendant une durée déterminée ou lorsque ledit serveur mandataire reçoit un message de déconnexion de ladite connexion sécurisée :
élaboration (41) d'une requête de désenregistrement (UNREG_REQ) de l'équipement client au moyen du procédé selon la revendication 8 ; et
envoi (43) de ladite requête de désenregistrement au serveur d'enregistrement (4), ladite requête de désenregistrement étant utilisée par le serveur d'enregistrement pour désenregistrer (45) l'équipement client dans le réseau de communication.
11. Serveur mandataire (2) d'un réseau de communication, apte à élaborer une requête d'enregistrement d'un équipement client (1) dans le réseau de communication, destinée à être transmise à un serveur d'enregistrement (4) du réseau de communication, comprenant un module de traitement de données configuré pour, suite à la réception de données d'authentification (AUTH) émises (23) par ledit équipement client lors d'une phase d'authentification dudit équipement client :
obtenir (31) au moins une donnée d'identification (ID) de l'équipement client dans le réseau de communication, à partir des données d'authentification reçues dudit équipement client ;
élaborer (33) la requête d'enregistrement (REQ_REG) de l'équipement client, en y insérant ladite au moins une donnée d'identification de l'équipement client dans le réseau.
12. Réseau de communication (IP_NET), comprenant un cœur de réseau (IMS_CN) et apte à enregistrer un équipement client (1) afin de lui offrir un service, le cœur de réseau comprenant au moins un serveur mandataire (2) selon la revendication 11 et un serveur d'enregistrement (4) configuré pour enregistrer l'équipement client (1) suite à la réception d'une requête d'enregistrement (REG_REQ) dudit équipement client élaborée par ledit serveur mandataire.
13. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'enregistrement d'un équipement client (1) dans un réseau de communication (IP_NET) selon l'une des revendications 1 à 8, lorsque ce programme est exécuté par le module de traitement de données d'un serveur mandataire (2) dudit réseau de communication.
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de désenregistrement d'un équipement client (1) dans un réseau de communication (IP_NET) selon la revendication 9, lorsque ce programme est exécuté par le module de traitement de données d'un serveur mandataire (2) dudit réseau de communication.
15. Support d'informations, lisible par un ordinateur ou un processeur de données, comportant des instructions d'un programme d'ordinateur selon l'une des revendications 13 ou 14.
PCT/FR2014/050110 2013-01-22 2014-01-21 Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication WO2014114871A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1350560A FR3001351A1 (fr) 2013-01-22 2013-01-22 Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
FR1350560 2013-01-22

Publications (1)

Publication Number Publication Date
WO2014114871A1 true WO2014114871A1 (fr) 2014-07-31

Family

ID=48224971

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/050110 WO2014114871A1 (fr) 2013-01-22 2014-01-21 Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication

Country Status (2)

Country Link
FR (1) FR3001351A1 (fr)
WO (1) WO2014114871A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106851692A (zh) * 2017-03-10 2017-06-13 广东电网有限责任公司东莞供电局 一种基于异构网络的自适应无线通信传输方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080014939A1 (en) * 2006-06-30 2008-01-17 Samsung Electronics Co., Ltd. Method for providing service in a communication system based on IP multimedia subsystem
EP2009934A1 (fr) * 2006-04-20 2008-12-31 Huawei Technologies Co., Ltd. Système, dispositif et procédé pour un équipement utilisateur mobile dans des réseaux de commutation de circuits pour accéder au sous-système multimédia

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2009934A1 (fr) * 2006-04-20 2008-12-31 Huawei Technologies Co., Ltd. Système, dispositif et procédé pour un équipement utilisateur mobile dans des réseaux de commutation de circuits pour accéder au sous-système multimédia
US20080014939A1 (en) * 2006-06-30 2008-01-17 Samsung Electronics Co., Ltd. Method for providing service in a communication system based on IP multimedia subsystem

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106851692A (zh) * 2017-03-10 2017-06-13 广东电网有限责任公司东莞供电局 一种基于异构网络的自适应无线通信传输方法及系统

Also Published As

Publication number Publication date
FR3001351A1 (fr) 2014-07-25

Similar Documents

Publication Publication Date Title
EP3417591B1 (fr) Procédé et serveur de sélection d'un serveur d'entrée d'un réseau de communication ims
EP3639541B1 (fr) Configuration d'un terminal dans un réseau ims avec une stratégie de resélection d'un type réseau
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP2873211B1 (fr) Procédé d'enregistrement d'au moins une adresse publique dans un réseau ims et application correspondante
EP3053321A1 (fr) Technique de restauration d'un service dans un réseau
EP2396950A1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP3646554B1 (fr) Procédé de traitement d'une requête et serveur d'un coeur de réseau ip multimédia
WO2013079865A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
WO2014114871A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
EP3583757B1 (fr) Procédé de changement de réseau mobile
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
EP2365686A2 (fr) Procédé et dispositif de traitement d'appels dans un réseau de communication comprenant des terminaux nomades tels que des terminaux de téléphonie de type softphone
WO2013121158A1 (fr) Procédé d'enregistrement d'un serveur d'application et serveur d'application
WO2015086460A1 (fr) Procede de gestion d'un identifiant public, systeme, serveur et element de securite correspondant
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
EP2651093A1 (fr) Procédé d'appairage d'un élément de sécurité à un terminal de télécommunications et système correspondant
WO2012072920A1 (fr) Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims
WO2011039450A1 (fr) Systeme et procede de controle de session de communication dans un terminal d'un reseau local

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14704841

Country of ref document: EP

Kind code of ref document: A1