EP2786546A1 - ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP - Google Patents

ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP

Info

Publication number
EP2786546A1
EP2786546A1 EP12806584.4A EP12806584A EP2786546A1 EP 2786546 A1 EP2786546 A1 EP 2786546A1 EP 12806584 A EP12806584 A EP 12806584A EP 2786546 A1 EP2786546 A1 EP 2786546A1
Authority
EP
European Patent Office
Prior art keywords
core network
request
public identifier
message
contact
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP12806584.4A
Other languages
German (de)
English (en)
Inventor
Bertrand Bouvet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of EP2786546A1 publication Critical patent/EP2786546A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/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/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/1053—IP private branch exchange [PBX] functionality entities or arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • the invention relates to the general field of telecommunications.
  • VoIP Internet Protocol
  • the invention applies particularly preferably but not limited to an IP Multimedia Subsystem (IMS) as defined by the 3GPP standard (Third Generation Partnership Project), implementing the Session Initiation Protocol (SIP).
  • IMS IP Multimedia Subsystem
  • SIP Session Initiation Protocol
  • VoIP Voice over IP
  • VoIP Voice over IP
  • H323 or REGISTRAR SIP core network implementing other VoIP application protocols such as Extensible Messaging and Presence Protocol (XMPP) or proprietary protocols.
  • XMPP Extensible Messaging and Presence Protocol
  • a VoIP device registers with the core network by sending a registration request, which includes a public identifier (or identity) and a contact address of the device.
  • the public identifier of the device is for example a VoIP telephone number, an electronic address or a SIP address (URI, Uniform Request Identifier), used by the public to join the device.
  • This may include the public IPU identity (IP Multimedia PUblic identity) for an IMS backbone.
  • IP Multimedia PUblic identity IP Multimedia PUblic identity
  • This public identifier can be shared by several devices; these also have a private identifier (or identity) (eg IP Multimedia Private Identity (IMPI) for an IMS backbone), which may be the same for each of these devices or a group of devices, or as a separate variant for each device.
  • IP Multimedia Private Identity eg IP Multimedia Private Identity (IMPI) for an IMS backbone
  • the contact address of the device corresponds to its reachability address in the IP domain, and notably includes in a known manner, the IP address of the device, a port number associated with its VoIP stack and the transport protocol (ex. User Data Protocol (UDP), Transport Control Protocol (TLS), and Transport Layer Security (TLS) used by the device to communicate.
  • UDP User Data Protocol
  • TLS Transport Control Protocol
  • TLS Transport Layer Security
  • the correspondence between the device's public identifier and its contact address is stored in a registration table also known as the registration context, maintained by the VoIP core network.
  • a caller transmits a call to the public identifier of the device
  • this call is routed to the VoIP core network, which determines with the help of the public identifier the contact address of the device. .
  • the VoIP core network then sends the call back to this contact address.
  • the VoIP device registers with the network core with its contact address a first time during its startup (we speak then initial registration), then re-register with the same contact address (we speak then of subsequent registration), for example periodically with a period of one hour. It is furthermore provided that a deregistration request is sent by the device to the network core, when it is properly shut down.
  • ADSL Asynchronous Digital Subscriber Line
  • LTE-compliant devices Long Term Evolution
  • the device Following the change of its current contact address, the device must inform the VoIP core network of its new address, in order to remain reachable. To this end, it transmits to the network core a registration request containing its public identifier and its new current contact address.
  • policies may be implemented by the operator of the VoIP core network to handle the received registration requests, such as:
  • a control based on the use of one (or more) queue (s) associated with the registration table and operating in a FIFO mode (eg a queue by public identifier or a queue associated with a couple (public identifier, private identifier)). More precisely :
  • the backbone accepts the new contact address received in the registration request, and saves it in the registration table associated with the public identifier contained in the request replacing the case the previously registered contact address for this public identifier; and o for a file of size greater than 1: if the queue (ie the registration table) is not full, the request is accepted and the new contact address is added to the addresses in the registration table associated with the public identifier contained in the request. If the queue is full (that is, if the maximum registration capacity for the public identifier or for the pair formed by the public identifier and the private identifier is reached), the core network accepts the request and saves the new contact address in the registration table in replacing the oldest registered contact address or the lowest current record expiration time;
  • a blocking as soon as the maximum recording capacity for a given public identifier is reached, the core network rejects any registration request arriving for this public identifier.
  • a record request check based on a configuration of the registration table into one or more FIFO size 1 queues is generally adopted by VoIP core network operators.
  • a home gateway GW associated with an AoCl contact address, and which shares the same public identifier IMPU with a terminal P (eg mobile or tablet equipped with a software application VoIP also known as "softphone")
  • the backbone being configured to accept a maximum of two simultaneous recordings associated with the same public identifier IMPU (that is, a priori a record for the gateway and a record for the terminal).
  • the registration table ie the queue
  • the network core for the public identifier IMPU initially contains only the gateway's AoCl contact address.
  • the backbone is configured to avoid the ejection of the gateway GW from the queue when a device (eg the terminal P) issues a registration request to the network core with this same public identifier IMPU and a contact address not yet registered and that the queue is full.
  • a device eg the terminal P
  • the home gateway GW therefore presents a registration request to the core VoIP network comprising the public identifier IMPU and the new contact address AoCl '. Since the queue is not full, the new AoCl 'contact address is registered in the registration table associated with the public identifier IMPU.
  • the queue associated with the public identifier IMPU contains the old contact address AoCl (now inactive, that is to say which is no longer used for the gateway GW) and the new contact address AoCl 'of the GW gateway.
  • the maximum registration capacity for the public identifier IMPU is therefore reached.
  • the core network will refuse any new registration request (typically a request from the terminal P) containing an address contact not yet registered and the public identifier IMPU, so as to avoid the ejection of the gateway GW.
  • the terminal P will therefore have no other solution to be able to register with the core network than to wait for the "automatic" expiration of the residual record (eg a maximum hour if the devices re-register every hours from the backbone) and the resulting deletion of the inactive AoCl contact address of the GW gateway of the queue.
  • the backbone will incorrectly refuse to register the terminal P in order not to take the risk of ejecting the GW gateway from the registration table. It is therefore clear that such a situation is unsatisfactory for the user of the terminal P because it can in particular cause unavailability of the service voice over IP long enough.
  • the invention makes it possible in particular to improve this situation by proposing a method of managing a request sent by a device associated with a public identifier, with a view to recording on a voice over IP core network an address of current contact of this device for the core network, this management method comprising:
  • the management method according to the invention is remarkable in that it furthermore comprises, when said number of contact addresses registered on the core network in association with the public identifier has reached this maximum capacity:
  • the invention also relates to a management server of a request sent by a device associated with a public identifier for recording on a voice over IP network core of a current contact address of this device on this VoIP network core, the management server comprising:
  • Means activated upon receipt of the request, for obtaining a number of contact addresses registered on the core network in association with the public identifier;
  • the management server according to the invention is remarkable in that it further comprises means, activated when the number of contact addresses registered on the core network in association with the public identifier has reached this maximum capacity:
  • a record of a current contact address of a device on a core network refers to an initial registration of this device with its current contact address on the core network.
  • the invention is not strictly speaking concerned with the management of re-recordings of devices.
  • a request sent by a device for a recording on the core network is meant in particular a registration request issued by this device and consisting for example of a specific message provided by the protocol implemented by the backbone for the registration of a device, such as a SIP REGISTER message for the SIP protocol.
  • a registration request contains, in a manner known per se, the current contact address of the device as well as its public identifier.
  • the invention is not limited to the management of recording requests strictly speaking devices. It also relates to a request sent by the device in preliminary to the registration of its current contact address on the core network, in particular to obtain or exchange information necessary for this purpose. recording.
  • a request is for example a HTTP (HyperText Transfer Protocol) Get Parameter message aiming to obtain a VoIP configuration file by the required device to enable its recording on the core network.
  • HTTP HyperText Transfer Protocol
  • the term "interrogation message” means a message that calls for a response from its recipient, in other words, to which the recipient identified in the message responds in normal time when he receives this message.
  • a message will be chosen as the interrogation message which does not disturb the progress of the communications or exchanges in which, if appropriate, the device receiving the interrogation message, that is to say a message that is transparent to the interrogation messages, is used. current sessions of the recipient device (because it is for example a message managed by the protocol's lower protocol layers).
  • Such a message is, for example, an interrogation message of the capabilities of the remote, such as, in particular, a SIP OPTIONS message for a core network implementing the SIP protocol or an AUDITENDPOINT message for a core network implementing the MGCP protocol ( Media Gateway Control Protocol).
  • SIP OPTIONS for a core network implementing the SIP protocol
  • AUDITENDPOINT for a core network implementing the MGCP protocol ( Media Gateway Control Protocol).
  • MGCP protocol Media Gateway Control Protocol
  • interrogation messages may of course be envisaged, such as in particular a MESSAGE SIP message containing a text to which its recipient responds in normal operation by a message 200OK after displaying this text.
  • the invention thus makes it possible, by analyzing the responses and / or the non-responses to the sent interrogation messages, to easily and quickly identify the contact addresses that are registered with the backbone in association with the public identifier of the device. and which are no longer used (ie which are inactive), for example due to the assignment of a new contact address to previously registered devices for these contact addresses. It avoids the unjustified rejection of registration requests because of the presence in Invalid contact address network registration tables that have not been properly unregistered.
  • the invention therefore makes it possible to limit the period of unavailability of VoIP services offered by a device that seeks to register after a change of contact address, for example following an unexpected restart.
  • the invention generates very little traffic on the network. Indeed, an interrogation message is sent to the contact addresses of the registration table only if the maximum capacity has been reached.
  • the invention thus makes it possible to optimize the resources of the core network, by offering a better availability of voice over IP service with few resources (reduced exchanged messages).
  • all the addresses registered with the core network are active, that is to say if before the expiration of the predetermined period of time, all the registered addresses correspond to contact addresses
  • “Current” devices and all of them respond to the interrogation message or are declared active in response to the interrogation message (for example by an intermediate device such as an edge server (or SBC Session Border Controller) placed in a flow cutoff for registration at the heart of network between the devices and the backbone), the request is rejected. It follows from the rejection of this request that the registration of the device with the heart network with its current contact address is not possible.
  • an intermediate device such as an edge server (or SBC Session Border Controller) placed in a flow cutoff for registration at the heart of network between the devices and the backbone
  • the invention thus makes it possible to a certain extent to avoid that a device which does not have to register with the backbone given the registration capacity allowed for a given public identifier, can be used. register and take the place of an authorized device.
  • the management method according to the invention can be implemented at various points of the IP network, i.e. by a VoIP network core equipment or by a device located outside the core network.
  • a core network registration server such as a Serving-Call State Control Function (S-CSCF) server.
  • S-CSCF Serving-Call State Control Function
  • IMS SIP backbone or a PROXY server
  • REGISTRAR for a core non-IMS SIP network able to update the registration tables associated with public identifiers.
  • it can also be implemented by an external equipment at the heart of the network (eg a VoIP operator information system) which would be in charge, for example, of making a pre-selection of the devices that can present a request for a connection. registering at the heart of the network in view of the number of contact addresses already registered for a given public identifier, this equipment being able to interrogate the core network to obtain this number.
  • the current contact address of the device is registered on the backbone in association with the public identifier instead of a forwarding address. contact that did not respond to the polling message or was inactive in response to the polling message.
  • the means for accepting the request from the management server are able to record the current contact address of the device on the backbone in association with the public identifier instead of a contact address. not responding to the polling message or declared inactive in response to the polling message.
  • This embodiment makes it possible to update the registration table associated with the public identifier of the device with its current contact address, so as to finalize the registration of the device with the core network.
  • the current contact address of the device can be registered instead of the address. of contact which corresponds to the lowest record expiration time among said plurality of contact addresses that did not respond to the polling message or were declared inactive in response to the polling message.
  • the current contact address of the device is recorded instead of the address of the interrogation message. contact which is associated with a lowest priority among said multiple contact addresses.
  • this priority can for example be determined using the field q of the contact address defined by the document.
  • RFC3261 entitled “SIP: Session Initiation Protocol” published by the IETF, and contained in the registration request that allowed the registration of this contact address on the core network.
  • the management method further comprises a verification step, before accepting the request, that at least one address that has not responded to the interrogation message or that has has been declared inactive in response to the polling message is the lowest record expiration time among the contact addresses registered with the backbone in association with the public identifier, the request sent by the device being rejected on the other hand.
  • This embodiment has a preferred application when the management method is implemented by an equipment separate from the registration server of the core network, and that the core network applies a "FIFO" type policy to manage the registration. contact addresses which consists of ejecting as appropriate the contact address which corresponds to the lowest recording expiration time.
  • the management method furthermore comprises if several contact addresses have not answered the interrogation message or have been declared inactive in response to the interrogation message at the end of the interrogation message. said predetermined period of time, a step of deregistering these addresses in said core network.
  • the registration table corresponding to the public identifier maintained by the core of the network is thus advantageously suppressed all the irrelevant contact addresses that are inactive and not correctly de-registered. In this way, subsequent registration procedures by devices at the backbone will be faster.
  • the de-registration step may further include notifying at least one VoIP core network server such as, for example, a Proxy Call Session Control Function (P-CSCF) server or an application server, the deregistration of these addresses.
  • VoIP core network server such as, for example, a Proxy Call Session Control Function (P-CSCF) server or an application server, the deregistration of these addresses.
  • P-CSCF Proxy Call Session Control Function
  • the polling message may be reissued several times during the predetermined period of time to at least one of the contact addresses.
  • the equipment to which the interrogation message is sent has several opportunities to respond to this message (especially if it is busy and can not respond at the first broadcast).
  • the device is also associated with a private identifier
  • the management method is implemented by considering the contact addresses recorded on the network core in association with the pair formed by the device. public identifier and the private identifier associated with the device.
  • the invention proposes a request management method that can be easily configured to take into account: Or all the contact addresses registered for the same public identifier independently of the private identifier of the device seeking to register;
  • the interrogation message is also sent to the contact addresses registered on the core network in association with the public identifier of the device when the maximum capacity is not reached. This can be done systematically, for example at each receipt of a request to record a current contact address of a device, or at predetermined time intervals (eg periodically).
  • the various steps of the management method according to the invention are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a management server or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a management method as described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also provides a system of a VoIP core network, comprising:
  • a management server in accordance with the invention able to manage a request sent by a device associated with a public identifier, with a view to recording on the network core of a current contact address of this device;
  • At least one registration table for this public identifier containing at least one contact address distinct from the current address, registered on the core network in association with said public identifier, said at least one registration table being consulted by said server upon receipt of the request to obtain the number of contact addresses registered on the core network in association with this public identifier.
  • the system according to the invention has the same advantages as the method and the management server according to the invention described above.
  • FIG. 1 shows schematically a system and a management server according to the invention in a particular embodiment
  • FIG. 2 illustrates an example of a registration table maintained by the management server illustrated in FIG. 1;
  • - Figure 3 shows schematically the hardware architecture of the management server in the embodiment of Figure 1;
  • FIG. 4 represents in the form of a flow chart the main steps of a management method according to the invention when it is implemented in one embodiment of the invention by the server represented in FIG. 1;
  • FIGS. 5A and 5B illustrate different states of the registration table maintained by the management server shown in FIG. 1;
  • FIG. 6 illustrates a registration table associated with a pair (public identifier, private identifier).
  • FIG. 7 illustrates, in the form of a flow chart, the main steps of a management method according to the invention when it is implemented in another embodiment of the invention, by an external management server at the heart network.
  • FIG. 1 represents, in its environment, a system 1 of a backbone
  • Voice over IP CN according to the invention, in a particular embodiment.
  • the system 1 makes it possible to manage requests sent to the CN core network for the purpose of registering a current contact address of a device on this core network.
  • the voice over IP core network is an IMS core network implementing the SIP protocol.
  • VoIP core network architectures eg H323, MGCP, Peer2Peer, REGISTRAR
  • VoIP applications such as for example XMPP, as well as other proprietary protocols.
  • identifier IMPU1 is here an identity IMPU, known per se and such that defined by the 3GPP standard, in particular in document 3GPP TS 23.228 entitled "IP Multimedia Subsystem", Release 9, September 2010.
  • Devices A and B are respectively a terminal (eg telephone, digital tablet, etc.) and a home gateway, equipped with a VoIP stack.
  • a terminal eg telephone, digital tablet, etc.
  • a home gateway equipped with a VoIP stack.
  • the invention also applies to other types of devices equipped with a VoIP stack such as for example servers, etc.
  • Each device A and B is respectively equipped with a current contact address, denoted AoCA and AoCB: as previously specified, this contact address represents a reachability address of the device in the IP domain, and notably comprises the IP address of the device.
  • this contact address represents a reachability address of the device in the IP domain, and notably comprises the IP address of the device.
  • device a port number associated with its VoIP stack and the transport protocol (eg UDP, TCP, TLS) used by the device to communicate in the IP domain.
  • the system 1 comprises a management server 2 according to the invention and T recording tables (or contexts) respectively associated with each public identifier (or with each pair (public identifier, private identifier)) in connection with which a registration request has been sent to the backbone.
  • registration table associated with a given public identifier or a given pair here is meant any data structure that makes it possible to store information relating to recordings made for this given public identifier or for this couple (public identifier, private identifier) given.
  • Such a table is known per se and will not be described in detail here.
  • Each registration table associated with a public identifier contains in particular the contact addresses of the devices that have registered in association with this public identifier (respectively in association with this couple (identifier public, private identifier)), as well as the expiration time of their records (value of the Expires parameter in the SIP protocol).
  • a registration table associated with a given public identifier may itself consist of several distinct "sub-tables", each sub-table being associated with a pair formed of this given public identifier and an identifier. private and containing the addresses registered in association with this couple.
  • the maximum number of contact addresses that can be recorded in the table is set for example by the operator of the core network and depends on the policy envisaged for the control of the records associated with the same public identifier (respectively with the same pair ( public identifier, private identifier)).
  • This number constitutes a maximum capacity Cmax of registration for a public identifier (respectively for a couple (public identifier, private identifier))) within the meaning of the invention. It may vary depending on the identifiers, the types of devices that you want to record (eg if you distinguish between devices at the time of registration in the control policy), etc.
  • Management server 2 is in the embodiment described herein integrated with the S-CSCF registration server of the core network CN.
  • the S-CSCF server of a VoIP core network is in charge of the recordings on this core network, and is in particular able to manage and modify the registration tables associated with the various public identifiers.
  • FIG. 3 It has here the hardware architecture of a computer as shown schematically in FIG. 3. It notably comprises a processor 3, a random access memory 4, a read-only memory 5, a non-volatile rewritable memory 6 (in which are stored for example the recording tables maintained by the server 2), as well as communication means 7 implementing in particular the SIP protocol known per se.
  • the read-only memory 5 of the server 2 constitutes a recording medium in accordance with the invention, readable by the processor 3 and on which is recorded a computer program according to the invention, comprising instructions for executing the steps of FIG. a method of managing a request according to the invention, now described with reference to FIG. 4, in a particular embodiment.
  • This request is here a SIP REGISTER message containing in particular the public identifier IMPU1 of the terminal A as well as its current contact address AoCA.
  • the management server 2 determines whether the contact address AoCA is a new contact address not yet registered for the identifier IMPU1 or if the request is in fact a request to re-register the terminal AoCA (step E20).
  • the management server 2 extracts for this purpose the dialogue identifier present in a manner known per se in the SIP REGISTER request, and determines whether this dialogue identifier corresponds to a dialogue already established with the core network.
  • the management server 2 determines that the request received is not a re-registration request but an initial registration request (yes response to the test of step E20), it looks in its non-volatile rewritable memory 6 if a registration table T (IMPUL) associated with the public identifier IMPU1 exists.
  • IMPUL registration table
  • the management server 2 consults this registration table and preliminary checks here that the contact address AoCA is not yet registered in association with the public identifier IMPU1 in this table. As mentioned above, if the contact address AoCA is already registered in the table T (IMPUl), then the management server 2 deduces a network malfunction that can signal in a manner known per se, including a message d error sent to terminal A. It is assumed here that such a table already exists in the memory 6 of the management server 2 (this table has for example been created in a previous record with the public identifier IMPU1).
  • the management server 2 obtains by consulting this registration table the number Nb-AoC of contact addresses already registered in association with the public identifier IMPU1, according to means known per se not detailed here (step E50).
  • step E60 compares this number Nb-AoC with the maximum recording capacity Cmax associated with the identifier IMPU1, in order to determine if the maximum recording capacity has already been reached.
  • the management server 2 accepts the registration request of the terminal A (step E70).
  • the management server 2 then updates the registration table T (IMPU I) by adding the current AoCA contact address of the terminal A and an EXPA registration expiry time. equal to 1 hour (step E80), and sends a message 200 OK containing the duration EXPA to the terminal A (step E90).
  • FIG. 5A illustrates an example of such an update when the table T (IMPU1) initially contains a single contact address (state (a) in FIG. 5A), namely the contact address AoCB of the gateway B At the end of the update (state (b) in FIG. 5A), the table T (IMPU 1) contains the contact address AoCB of the gateway B as well as the contact address AoCA of the terminal A. The maximum recording capacity associated with the public identifier IMPU1 is then reached.
  • the management server 2 detects that the maximum recording capacity has already been reached (yes answer to the test of the step E60), it triggers in the mode of embodiment described here a timer t for a predetermined period of time denoted d (step E100).
  • This period d is chosen here so as to allow the management server 2 to respond to the registration request of the terminal A within the limits of the response time provided by the core network (ie here according to the response time defined by the 3GPP standard for the IMS core network is 32 seconds), so that the additional steps implemented by the management server 2 to determine whether or not to accept the registration request are transparent for the terminal A.
  • FIG. 5B illustrates an example for the table T (IMPU1) in which the maximum recording capacity has been reached: in this example, the gateway B is registered via two contact addresses AoCB and AoCB 'respectively associated with recording times EXPB and EXPB '(state (a) in Fig. 5B).
  • the management server 2 sends to all the contact addresses registered in the table T (IMPU1) in association with the public identifier IMPU1, an interrogation message to determine whether these contact addresses are still active, that is that is, used as current contact addresses by the devices that required their registration (step E110).
  • an interrogation message within the meaning of the invention designates a message that calls a response from its recipient, in other words, to which the recipient identified in the message responds normally when he receives this message.
  • This interrogation message is chosen preferentially so as not to disturb the sessions in progress (eg communications) at the level of the devices to which it is sent.
  • this interrogation message is a SIP OPTIONS message, which contains in the RURI of the message (or Request URI in English), the contact address to which the message is intended, and in the field FROM, the identifier of the management server 2.
  • the management server 2 sends a SIP OPTIONS message to the AoCB contact address and a SIP OPTIONS message to the AoCB 'contact address.
  • step E120 the management server 2 is waiting for replies to the polled messages sent until the expiry of the timer t (step E120).
  • the management server 2 if it has not received a response from one (or more) contact address to which it has sent an interrogation message at predetermined time intervals preceding the expiration of the timer t, it retransmits the interrogation message one or more times (for example twice) to this contact address before the expiry of the timer t, in order to overcome any transmission problems between the management server 2 and the device associated with this contact address.
  • the management server 2 determines whether all the contact addresses to which it has sent a polling message are active.
  • the management server 2 determines for this purpose whether it has received replies to the interrogation message of all the listed contact addresses. in the table T (IMPUl), that is to say, in the example envisaged in FIG. 5B, contact addresses AoCB and AoCB '(step El 30).
  • These response messages can be, for example, SIP messages 200OK if the device is available, or 486 Busy Here if the device is in communication mode.
  • the management server 2 deduces that all the contact addresses registered in the table T (IMPUl) are active and then rejects the registration request of the terminal A (step E140). For example, it sends to the terminal A a SIP message 403 Forbidden.
  • the management server 2 If, on the other hand, at least one contact address has not answered at the end of the period of time of the interrogation message sent by the management server 2 (answer not to the test of the step E130), the management server 2 deduces that this contact address is no longer active (for example because the device that registered with this contact address has changed the current contact address or is turned off) and does not need to be stored in the table T (IMPUL). According to the invention, the management server 2 therefore accepts the registration request sent by the terminal A.
  • the management server 2 unregisters the unresponsed contact address (that is, it deletes it from the registration table T (IMPUL)), and records in the table T ( IMPUl) replacing this address, the current contact address AoCA of the terminal A and the expiry time EXPA.
  • FIG. 5B illustrates such an update.
  • the gateway B restarted abruptly while it was using the contact address AoCB 'and could not unregister before restarting with the heart of CN network. Following its restart, it is assumed that the gateway B now has the current contact address AoCB address, the address AoCB 'being inactive, so that the table T (IMPUl) contains the two contact addresses AoCB' and AoCB associated respectively with expiry times EXPB 'and EXPB (state (a) of the table T (IMPUl) in Figure 5B).
  • the management server 2 Since the gateway B no longer uses the contact address AoCB ', the management server 2 does not receive a response message from this address to the interrogation message sent to the step El 10. Also during the step update E160, it deletes the inactive contact address AoCB '(and the duration EXPB of the table T (IMPUl) and replaces it with the contact address AoCA of the terminal A (and the expiry time EXPA) (state (b) of the table T (IMPUL) in FIG. 5B).
  • the management server 2 also ejects from the table T (IMPU1) (ie de-register from the core network) the other contact addresses that did not respond to the interrogation message at the end of the term d. This is to clean the inactive contact address registration table to simplify and speed up subsequent registrations.
  • This update of the registration table also makes it possible to avoid the sending of unnecessary messages on the network, especially when an incoming call (SIP INVITE message) intended for a public identifier registered with the core network arrives.
  • SIP INVITE message incoming call
  • the SIP INVITE message is presented to each of these contact addresses. The invention thus makes it possible to limit unnecessary retransmissions of the SIP INVITE message to contact addresses that are no longer active.
  • these other contact addresses are not deleted from the table.
  • the step of de-registering the inactive address or contact addresses of the core network may also be accompanied by the notification of at least one server of the VoIP core network such as, for example a Proxy Call Session Control Function (P-CSCF) server or application server, the deletion of this or these addresses from the registration table.
  • P-CSCF Proxy Call Session Control Function
  • an alternative may be to eject the contact address that is associated with the lowest priority among the contact addresses that did not respond to the polling message.
  • This priority can be determined by the management server 2 by consulting the value of the field "q" provided at the contact address by the Internet Engineering Task Force (IETF) standard for the SIP protocol, and described in the document RFC3261 previously mentioned.
  • This field is present in particular in each request for registration of a contact address sent to the core network.
  • the registration table will also associate with each stored contact address, the corresponding value of the field "q" (value contained in the registration request that allowed the registration of this contact address on the core network).
  • the priority of a device may be associated with a range of IP addresses in which its contact address is located.
  • a first address range could be associated with the priority devices such as gateways, a second range of addresses. addresses to the terminals connected behind the gateway, and a third range of addresses to the terminals connected to access points accessible in a nomadic situation, this third address range defining a category of less priority devices in the sense of "use of the heart" network "of the term.
  • the management server 2 determines whether the contact addresses are active by detecting the presence (or absence) of responses received from these addresses. contact to the polled messages sent. In this configuration, in fact, the response messages are transmitted to the management server 2.
  • the invention also applies to other network configurations, and in particular, to a network configuration in which intermediate equipment such as SBC edge servers are provided in the management of the records between the core network.
  • intermediate equipment such as SBC edge servers are provided in the management of the records between the core network.
  • CN and the devices to which the management server 2 sends the polling messages for example to reduce the load of the management server 2 and ensure regular traffic access.
  • the response messages of the devices are received by the intermediate equipment; likewise, the absence of response messages at the end of the period d is detected by these intermediate equipments.
  • the intermediate equipment then sends a message declaring the activity or inactivity of the contact address to the management server 2.
  • step E130 to determine whether at the end of the period of all the contact addresses to which it has sent a polling message are active, the management server 2 analyzing whether all the messages received from the intermediate equipment (s) in response to these interrogation messages inform it of an activity of the devices associated with these contact addresses.
  • the management server 2 deduces that all the contact addresses registered in the table T (IMPUl) are active and rejects the registration request of the terminal A (step E140).
  • the management server 2 therefore accepts the registration request sent by the terminal A.
  • the selection of the contact address (or addresses) to be ejected from the registration table, in particular to enable the registration of the contact address of the terminal A, is carried out among the contact addresses which have been declared inactive by one of the intermediate devices in response to the polling messages sent by the management server 2.
  • the invention also applies to hybrid configurations of the network in which intermediate equipment is present for only part of the devices able to register with the core network CN.
  • the management server 2 checks, before accepting the registration request sent by the terminal A if, at the end of the period of time d, at least one contact address has has not responded to the interrogation message or has been declared as inactive by one of the intermediate equipment in response to the interrogation message (for example via a 480 No Route Found message).
  • the selection of the contact address (or addresses) to be ejected from the registration table is carried out among the contact addresses that have not responded to the interrogation messages sent by the management server 2 or which have been declared inactive by one of the intermediate equipment in response to these interrogation messages.
  • the management of the registration request is carried out for a public identifier independently of the policy envisaged in the core network concerning the allocation of private identifiers to devices sharing this public identifier (eg same identifier private for all devices sharing the same public identifier, or separate private identifiers for each device, or hybrid mechanism in which separate private identifiers are assigned to distinct groups of devices).
  • a public identifier independently of the policy envisaged in the core network concerning the allocation of private identifiers to devices sharing this public identifier (eg same identifier private for all devices sharing the same public identifier, or separate private identifiers for each device, or hybrid mechanism in which separate private identifiers are assigned to distinct groups of devices).
  • the management server 2 implements the invention by also taking into account the private identifiers of the devices, also contained in the registration requests issued by these devices. More precisely in this embodiment, the steps of the method according to the invention described previously with reference to FIG. 4 are then implemented from a registration table T (IMPU1, IMPIA).
  • Nb-AoC corresponds to the number of records of the table associated with the pair ( public identifier, private identifier) of the terminal A
  • Cmax corresponds to the maximum capacity of records associated with this pair
  • the contact address AoCA is recorded if necessary in place of a contact address of the table ⁇ ( ⁇ ⁇ , ⁇ )).
  • FIG. 6 illustrates an example of a registration table T (IMPU 1, IMPIA) associated with the pair T (IMPU 1, IMPIA) of the terminal A and integrated in the table T (IMPU 1) associated with the public identifier IMPU 1.
  • the private identifier IMPIA is shared by the terminal A and another device C, while the gateway B has a distinct private identifier IMPIB.
  • the devices A, B and C share the same public identifier IMPU 1.
  • the management of the registration requests by the core network is performed using queues associated with each couple identifier public- private identifier.
  • the invention makes it possible, in the various embodiments described, to manage the recordings either by taking into account only the public identifier contained in the request (independently of the private identifier assignment policy implemented by the user).
  • core network eg same private identifier shared by several devices or a separate private identifier for each device, either by taking into account the public identifier and the private identifier contained in the request.
  • the management server 2 sends an interrogation message only when the maximum registration capacity is reached in the registration table associated with the public identifier IMPU 1 or in the table d. record associated with the pair formed by the public identifier IMPU and the private identifier IMPI.
  • a similar interrogation message may be sent to the contact addresses of the table regardless of whether the maximum capacity has been reached, for example periodically, in order to regularly clean the registration table of the inactive contact addresses. .
  • Contact addresses which have not answered this interrogation message at the expiration of a predetermined duration (which may or may not be identical to the duration d) are then deleted from the table T (IMPU 1) or ⁇ ( ⁇ ⁇ , ⁇ ) by the management server 2.
  • the management server 2 is integrated in the registration server of the core network CN.
  • the management server 2 is able to modify the registration table associated with the public identifier IMPU 1 or the pair (public identifier IMPU 1, private identifier IMPIA).
  • this assumption is not limiting and the invention also applies when the management server 2 does not have such a capacity.
  • the management server 2 may be an external server at the heart of the CN network (eg located in the network information system), able to perform a preselection of the devices that can issue requests. registration with the heart of the CN network given the number of contact addresses already registered for a given public identifier (or a couple (public identifier, private identifier) given), and more specifically requests for the registration server of the backbone network CN which is able to update the registration tables and to accept or reject the registration requests according to the policy implemented in the core network CN.
  • the CN network eg located in the network information system
  • FIG. 7 The steps implemented during the management method according to the invention by the management server in this other embodiment are illustrated in FIG. 7.
  • the management according to the invention of FIG. a request sent for a record on the core network CN is performed taking into account only the public identifier contained in the request.
  • this embodiment also applies when one also takes into account the private identifier contained in the request.
  • the steps ⁇ ', ⁇ 20', E40 'to E70', E90 ', E100' to E150 ', E170' implemented by the management server are similar to the steps E10, E20, E40 to E70, E90, E100 to E150, E170 previously described with reference to FIG. 4 (the steps E30, E80 and E160 for updating the recording table, on the other hand, are not implemented by the server Management).
  • the information required to implement the invention is however obtained by the management server by querying with the public identifier for example the CN network core registration server using the standard SIP procedure described in the aforementioned IETF RFC3261 document (ie sending a SIP REGISTER message containing the public identifier IMPU1 but without specifying a contact address) ).
  • the policy of deleting and replacing the contact addresses in the registration table does not depend on the management server, the latter must ensure, before send a registration request to the heart of the CN network (in other words before accepting a request to register a device), that it will not trigger the eviction of a contact address from the table of recording that would not be desirable, for example because this contact address is still active.
  • Such a situation may arise for example when the backbone implements a FIFO type policy based on the expiration periods of the records, which consists of replacing with a new contact address the contact address corresponding to the duration of the registration. the lowest recording expiration.
  • the server of determines whether among the contact addresses that did not respond to the polling message, one of them corresponds to the lowest expiration time recorded in the registration table (step E145 - This step may be implemented for example by querying the registration server of the core network CN. If this is the case, then the management server accepts the registration request from the terminal A (step E150 ') and sends it a SIP message 200OK (step E170 -
  • the management server denies the request for registration of the terminal A (step E140 -
  • the step E10 ' is identical to the step E10 and consists in receiving a SIP REGISTER registration request sent by the terminal A to the core network CN.
  • the request received in step E10 ' may be a request separate from a SIP REGISTER message or, more generally, a separate request from a specific message provided by the protocol implemented by the core network for the registration. of a device. It can be generally a query that is needed to register the device.
  • this request may be a message sent by the terminal A to obtain a VoIP configuration file necessary for its registration on the core network.
  • a message is, for example, an HTTP Get Parameter message containing the IP address of the terminal A.
  • the obtaining of the VoIP configuration file by the terminal A is inseparable from the recording of the terminal A on the core network ( and more particularly its current contact address), and is part of the registration procedure set up by the terminal A in the sense that on the one hand obtaining such a configuration file is a prerequisite for the registering the current contact address of the terminal on the core network and secondly obtaining this file only makes sense because the terminal A wishes to register its current contact address on the network core VoIP to communicate on this core network.
  • a message requesting the obtaining of this file therefore constitutes a request for a registration on the backbone of a current contact address of a device within the meaning of the invention.
  • the public identifier IMPU1 associated with the terminal A used in particular to obtain the number of Nb-AoC contact addresses and the maximum recording capacity.
  • Cmax can be retrieved by the management server using the IP address of the terminal A contained in the request, for example by querying an information system of the VoIP operator.
  • the steps ⁇ 40 ', E90' and E170 'of acceptance of the request can then furthermore comprise the sending of the required VoIP configuration file to the terminal A (this file comprises, in a manner known per se, the identifier the terminal's public, its private identifier, the VoIP core network entry point address, the VoIP network domain name, and other fields related to the activation of services on the VoIP core network) .
  • the management method, the management server and the system according to the invention present in combination all or some of the characteristics described above with reference to FIGS. 1 to 7.

Landscapes

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

Abstract

Procédé et serveur de gestion d'une requête émise par un dispositif sur un cœur de réseau Vo IP en vue d'un enregistrement d'une adresse de contact courante de ce dispositif Le procédé de gestion comprend : une étape d'obtention, sur réception de la requête, d'un nombre d'adresses de contact enregistrées sur le cœur de réseau en association avec un identifiant public du dispositif; lorsque ce nombre a atteint une capacité maximale d'enregistrement définie pour cet identifiant public : une étape d'envoi d'un message d'interrogation aux adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public; si, à l'issue d'une période de temps prédéterminée, au moins une adresse n'a pas répondu au message d'interrogation ou est déclarée inactive en réponse au message d'interrogation, une étape d'acceptation de la requête; et une étape de rejet de la requête sinon.

Description

Enregistrement d'un dispositif auprès d'un cœur de réseau VoIP
Arrière-plan de l'invention
L'invention se rapporte au domaine général des télécommunications.
Elle concerne plus particulièrement la gestion de requêtes émises par des dispositifs tels qu'un terminal ou une passerelle domestique en vue d'un enregistrement de ces dispositifs sur un cœur de réseau de voix sur IP (Internet Protocol).
L'invention s'applique notamment de façon privilégiée mais non limitative à un cœur de réseau IMS (IP Multimedia Subsystem) tel que défini par le standard 3GPP (Third Génération Partnership Project), mettant en œuvre le protocole SIP (Session Initiation Protocol). Toutefois l'invention s'applique également à d'autres architectures de cœur de réseau de voix sur IP (ou VoIP pour Voice over IP) telle que par exemple un cœur de réseau H323 ou REGISTRAR SIP, ainsi qu'à des cœurs de réseau mettant en œuvre d'autres protocoles applicatifs de voix sur IP tels que le protocole XMPP (extensible Messaging and Présence Protocol) ou des protocoles propriétaires.
Quel que soit le protocole applicatif de voix sur IP considéré, le fonctionnement du cœur de réseau est globalement le même. Suite à son démarrage, un dispositif VoIP s'enregistre auprès du cœur de réseau en lui envoyant une requête d'enregistrement, qui comprend notamment un identifiant (ou identité) public(que) et une adresse de contact du dispositif.
L'identifiant public du dispositif est par exemple un numéro de téléphone VoIP, une adresse électronique ou une adresse SIP (URI, Uniform Request Identifier), utilisé(e) par le public pour joindre le dispositif. Il peut s'agir notamment de l'identité publique IMPU (IP Multimedia PUblic identity) pour un cœur de réseau IMS. Cet identifiant public peut être partagé par plusieurs dispositifs ; ceux-ci disposent en outre d'un identifiant (ou identité) privé(e) (ex. IMPI (IP Multimedia Private Identity) pour un cœur de réseau IMS), qui peut être le même pour chacun de ces dispositifs ou un groupe de dispositifs, ou en variante distinct pour chaque dispositif.
L'adresse de contact du dispositif correspond à son adresse de joignabilité dans le domaine IP, et comprend notamment de façon connue, l'adresse IP du dispositif, un numéro de port associé à sa pile VoIP ainsi que le protocole de transport (ex. UDP (User Data Protocol), TCP (Transport Control Protocol), TLS (Transport Layer Security)) utilisé par le dispositif pour communiquer.
La correspondance entre l'identifiant public du dispositif et son adresse de contact est stockée dans une table d'enregistrement aussi connue sous le nom de contexte d'enregistrement, maintenue par le cœur de réseau VoIP.
De cette sorte, lorsqu'un appelant émet une communication à destination de l'identifiant public du dispositif, cette communication est routée vers le cœur de réseau VoIP, qui détermine à l'aide de l'identifiant public l'adresse de contact du dispositif. Le cœur de réseau VoIP renvoie alors la communication vers cette adresse de contact. Généralement, le dispositif VoIP s'enregistre auprès du cœur de réseau avec son adresse de contact une première fois lors de son démarrage (on parle alors d'enregistrement initial), puis se réenregistre avec cette même adresse de contact (on parle alors d'enregistrement subséquent), par exemple périodiquement avec une période d'une heure. Il est par ailleurs prévu qu'une requête de désenregistrement soit envoyée par le dispositif au cœur de réseau, lorsqu'il est éteint proprement.
Toutefois, différents types d'incidents peuvent amener un dispositif VoIP à changer d'adresse de contact courante, sans pour autant qu'il puisse auparavant se désenregistrer proprement auprès du cœur de réseau (i.e. via l'envoi d'une requête de désenregistrement au cœur de réseau). C'est le cas par exemple :
— après un redémarrage automatique du dispositif suite à une anomalie de fonctionnement de celui-ci ou à l'échec d'un processus dans le dispositif ;
— après une déconnexion de la ligne physique reliant le dispositif au réseau ;
— pour un accès IP de type ADSL (Asynchronous Digital Subscriber Line), après une perte de synchronisation ADSL ;
— suite à un changement de réseau ou dans une situation de roaming pour des dispositifs conformes au standard LTE (Long Term Evolution) ;
— etc.
Suite au changement de son adresse de contact courante, le dispositif doit informer le cœur de réseau VoIP de sa nouvelle adresse, et ce, afin de rester joignable. A cette fin, il transmet au cœur de réseau une requête d'enregistrement contenant son identifiant public et sa nouvelle adresse de contact courante.
Diverses politiques peuvent être mises en œuvre par l'exploitant du cœur de réseau de voix sur IP pour gérer les requêtes d'enregistrement reçues, comme par exemple :
— aucun contrôle, c'est-à-dire que toutes les requêtes d'enregistrement sont acceptées (jamais utilisé en pratique) ;
— un contrôle basé sur l'utilisation d'une (ou de plusieurs) file(s) d'attente associée(s) à la table d'enregistrement et fonctionnant selon un mode de type FIFO (ex. une file d'attente par identifiant public ou une file d'attente associée à un couple (identifiant public, identifiant privé)). Plus précisément :
o pour une file de taille 1 : le cœur de réseau accepte la nouvelle adresse de contact reçue dans la requête d'enregistrement, et l'enregistre dans la table d'enregistrement associée à l'identifiant public contenu dans la requête en remplacement le cas échéant de l'adresse de contact précédemment enregistrée pour cet identifiant public ; et o pour une file de taille supérieure à 1 : si la file (c'est-à-dire la table d'enregistrement) n'est pas pleine, la requête est acceptée et la nouvelle adresse de contact vient s'ajouter aux adresses de contact présentes dans la table d'enregistrement associée à l'identifiant public contenu dans la requête. Si la file est pleine (autrement dit si la capacité maximale d'enregistrement pour l'identifiant public ou pour le couple formé par l'identifiant public et l'identifiant privé est atteinte), le cœur de réseau accepte la requête et enregistre la nouvelle adresse de contact dans la table d'enregistrement en remplacement de l'adresse de contact la plus ancienne enregistrée ou ayant la durée d'expiration d'enregistrement courante la plus faible ;
— un blocage : dès que la capacité maximale d'enregistrement pour un identifiant public donné est atteinte, le cœur de réseau rejette toute requête d'enregistrement arrivant pour cet identifiant public.
Un contrôle des requêtes d'enregistrement basé sur une configuration de la table d'enregistrement en une ou plusieurs files d'attente en mode FIFO de taille 1 est généralement adopté par les opérateurs de cœurs de réseau VoIP.
Toutefois, ce type de contrôle présente des limites et ne peut pas être envisagé notamment lorsque l'opérateur du cœur de réseau souhaite mettre en place des mécanismes visant à préserver l'enregistrement de certains dispositifs considérés comme prioritaires (par exemple parce que le désenregistrement de ces dispositifs pourrait entraîner un dysfonctionnement gênant pour l'utilisateur telle qu'une perte de ses services VoIP).
Pour illustrer ce cas de figure, considérons par exemple une passerelle domestique GW associée à une adresse de contact AoCl, et qui partage un même identifiant public IMPU avec un terminal P (ex. mobile ou tablette équipé(e) d'un logiciel applicatif VoIP aussi connu sous le nom de « softphone »), le cœur de réseau étant configuré pour accepter au maximum deux enregistrements simultanés associés à ce même identifiant public IMPU (c'est-à-dire a priori un enregistrement pour la passerelle et un enregistrement pour le terminal). On suppose par ailleurs d'une part, que la table d'enregistrement (i.e. la file d'attente) maintenue par le cœur de réseau pour l'identifiant public IMPU contient dans un premier temps uniquement l'adresse de contact AoCl de la passerelle GW, et que d'autre part, le cœur de réseau est configuré de sorte à éviter l'éjection de la passerelle GW de la file d'attente lorsqu'un dispositif (par exemple le terminal P) émet une requête d'enregistrement auprès du cœur de réseau avec ce même identifiant public IMPU et une adresse de contact non encore enregistrée et que la file d'attente est pleine.
Supposons maintenant qu'un redémarrage de la passerelle domestique GW a lieu avant même que celle-ci n'ait pu se désenregistrer proprement du cœur de réseau, et qu'à l'occasion de ce redémarrage, la passerelle domestique a une nouvelle adresse de contact courante AoCl'. La passerelle GW présente donc une requête d'enregistrement au cœur de réseau VoIP comprenant l'identifiant public IMPU et la nouvelle adresse de contact AoCl'. La file d'attente n'étant pas pleine, la nouvelle adresse de contact AoCl' est enregistrée dans la table d'enregistrement associée à l'identifiant public IMPU.
Autrement dit, suite au redémarrage brutal de la passerelle, la file d'attente associée à l'identifiant public IMPU contient l'ancienne adresse de contact AoCl (maintenant inactive, c'est-à- dire qui n'est plus utilisée pour la passerelle GW) et la nouvelle adresse de contact AoCl' de la passerelle GW. La capacité maximale d'enregistrement pour l'identifiant public IMPU est donc atteint.
Dans l'état actuel de la technique, lorsque le cœur de réseau reçoit une requête d'enregistrement correspondant à un identifiant public déjà enregistré dans ses tables d'enregistrement, il n'est pas capable de distinguer si cette requête provient d'un dispositif déjà enregistré dans ses tables mais sous une adresse de contact différente ou si elle provient d'un autre dispositif (potentiellement interdit) cherchant à s'enregistrer auprès du cœur de réseau et partageant cet identifiant public.
On comprend bien dès lors que compte tenu de la configuration de la table d'enregistrement et de la file d'attente associée, le cœur de réseau va refuser toute nouvelle requête d'enregistrement (typiquement une requête provenant du terminal P) contenant une adresse de contact non encore enregistrée et l'identifiant public IMPU, de sorte à éviter l'éjection de la passerelle GW. Le terminal P n'aura donc pas d'autre solution pour pouvoir s'enregistrer auprès du cœur de réseau que d'attendre l'expiration « automatique » de l'enregistrement rémanent (ex. une heure maximum si les dispositifs se réenregistrent toutes les heures auprès du cœur de réseau) et la suppression en découlant de l'adresse de contact AoCl inactive de la passerelle GW de la file d'attente.
En d'autres mots, le cœur de réseau refusera à tort l'enregistrement du terminal P afin de ne pas prendre le risque d'éjecter la passerelle GW de la table d'enregistrement. On comprend bien dès lors qu'une telle situation n'est pas satisfaisante pour l'utilisateur du terminal P car elle peut notamment entraîner une indisponibilité du service de voix sur IP assez longue.
Objet et résumé de l'invention
L'invention permet notamment d'améliorer cette situation en proposant un procédé de gestion d'une requête émise par un dispositif associé à un identifiant public, en vue d'un enregistrement sur un cœur de réseau de voix sur IP d'une adresse de contact courante de ce dispositif pour le cœur de réseau, ce procédé de gestion comprenant :
— une étape d'obtention, sur réception de la requête, d'un nombre d'adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public ; et
— une étape de comparaison de ce nombre avec une capacité maximale d'enregistrement définie pour cet identifiant public.
Le procédé de gestion selon l'invention est remarquable en ce qu'il comprend en outre, lorsque ledit nombre d'adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public a atteint cette capacité maximale :
— une étape d'envoi d'un message d'interrogation aux adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public ; — si, à l'issue d'une période de temps prédéterminée, au moins une adresse de contact parmi ces adresses n'a pas répondu à ce message d'interrogation ou a été déclarée inactive en réponse audit message d'interrogation, une étape d'acceptation de la requête du dispositif ; et
— une étape de rejet de la requête sinon.
Corrélativement, l'invention vise également un serveur de gestion d'une requête émise par un dispositif associé à un identifiant public en vue d'un enregistrement sur un cœur de réseau de voix sur IP d'une adresse de contact courante de ce dispositif sur ce cœur de réseau de voix sur IP, le serveur de gestion comprenant :
— des moyens, activés sur réception de la requête, pour obtenir un nombre d'adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public ; et
— des moyens de comparaison de ce nombre avec une capacité maximale d'enregistrement définie pour cet identifiant public.
Le serveur de gestion selon l'invention est remarquable en ce qu'il comprend en outre des moyens, activés lorsque le nombre d'adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public a atteint cette capacité maximale :
— pour envoyer un message d'interrogation auxdites adresses de contact enregistrées en association avec ledit identifiant public ;
— pour accepter la requête si, à l'issue d'une période prédéterminée, au moins une adresse de contact parmi ces adresses de contact n'a pas répondu au message d'interrogation ou a été déclarée inactive en réponse audit message d'interrogation ; et
— pour rejeter la requête sinon.
Au sens de l'invention, un enregistrement d'une adresse de contact courante d'un dispositif sur un cœur de réseau fait référence à un enregistrement initial de ce dispositif avec son adresse de contact courante sur le cœur de réseau. L'invention ne s'intéresse pas à proprement parler à la gestion des réenregistrements des dispositifs.
Différents types de requêtes émises en vue d'un enregistrement (i.e. nécessaires pour un enregistrement) du dispositif auprès du cœur de réseau peuvent être gérées conformément à l'invention.
Ainsi au sens de l'invention, par requête émise par un dispositif en vue d'un enregistrement sur le cœur de réseau, on entend notamment une requête d'enregistrement émise par ce dispositif et constituée par exemple d'un message spécifique prévu par le protocole mis en œuvre par le cœur de réseau pour l'enregistrement d'un dispositif, tel qu'un message SIP REGISTER pour le protocole SIP. Une telle requête d'enregistrement contient, de façon connue en soi, l'adresse de contact courante du dispositif ainsi que son identifiant public.
Mais l'invention ne se limite pas à la gestion de requêtes d'enregistrement à proprement parler émises par des dispositifs. Elle concerne également une requête envoyée par le dispositif en préliminaire de l'enregistrement de son adresse de contact courante sur le cœur de réseau, afin notamment d'obtenir ou d'échanger des informations nécessaires à cet enregistrement. Une telle requête est par exemple un message HTTP (HyperText Transfer Protocol) Get Parameter visant à l'obtention d'un fichier de configuration VoIP par le dispositif requis pour permettre son enregistrement sur le cœur de réseau.
Par ailleurs, on gérera préférentiellement à l'aide de l'invention des requêtes en vue d'un enregistrement sur le cœur de réseau d'une adresse de contact d'un dispositif qui n'est pas déjà enregistrée auprès du cœur de réseau pour l'identifiant public associé à ce dispositif (autrement dit, des requêtes émises en relation avec l'enregistrement d'une nouvelle adresse de contact associée à l'identifiant public pour le cœur de réseau). En effet, l'enregistrement d'une adresse de contact déjà enregistrée auprès du cœur de réseau alors qu'il s'agit d'un enregistrement initial du dispositif et non d'un réenregistrement, reflète la présence d'un dysfonctionnement du réseau qui sort du cadre de l'invention et que l'homme du métier saura aisément détecter et gérer de façon connue en soi.
Par message d'interrogation au sens de l'invention, on entend un message qui appelle une réponse de la part de son destinataire, autrement dit, auquel le destinataire identifié dans le message répond en temps normal lorsqu'il reçoit ce message.
Préférentiellement, on choisira comme message d'interrogation un message qui ne perturbe pas le déroulement des communications ou des échanges auxquels participe le cas échéant le dispositif destinataire du message d'interrogation, c'est-à-dire un message qui est transparent pour les sessions en cours du dispositif destinataire (car il s'agit par exemple d'un message géré par les couches basses protocolaires du dispositif).
Un tel message est par exemple un message d'interrogation des capacités du distant, tel que notamment un message SIP OPTIONS pour un cœur de réseau mettant en œuvre le protocole SIP ou un message AUDITENDPOINT pour un cœur de réseau mettant en œuvre le protocole MGCP (Media Gateway Control Protocol). Ces messages sont traités par les couches basses de la pile de protocoles du dispositif destinataire et leur traitement n'a pas d'impact à proprement parler sur le déroulement des sessions en cours associées à ce dispositif, contrairement à d'autres messages qui sont gérés au niveau des couches applicatives de la pile tels que par exemple un message SIP INVITE dont l'arrivée peut se traduire notamment par une sonnerie du dispositif.
D'autres messages d'interrogation peuvent bien entendu être envisagés, tels que notamment un message SIP MESSAGE contenant un texte auquel son destinataire répond en fonctionnement normal par un message 200OK après avoir affiché ce texte.
L'invention permet ainsi, en analysant les réponses et/ou les non réponses aux messages d'interrogation envoyés, d'identifier facilement et rapidement les adresses de contact qui sont enregistrées auprès du cœur de réseau en association avec l'identifiant public du dispositif et qui ne sont plus utilisées (i.e. qui sont inactives), par exemple du fait de l'attribution d'une nouvelle adresse de contact aux dispositifs précédemment enregistrés pour ces adresses de contact. Elle permet d'éviter le rejet non justifié de requêtes d'enregistrement du fait de la présence dans les tables d'enregistrement du cœur de réseau d'adresses de contact inactives et qui n'ont pas été proprement désenregistrées.
Il n'est pas nécessaire grâce à l'invention de devoir attendre l'expiration des durées d'enregistrement pour pouvoir enregistrer une nouvelle adresse de contact. L'invention permet donc de limiter la période d'indisponibilité des services VoIP offerts par un dispositif qui cherche à s'enregistrer après un changement d'adresse de contact, par exemple suite à un redémarrage inopiné.
En outre, l'invention ne génère que très peu de trafic sur le réseau. En effet, un message d'interrogation n'est envoyé aux adresses de contact de la table d'enregistrement que si la capacité maximale a été atteinte.
L'invention permet donc d'optimiser les ressources du cœur de réseau, en offrant une meilleure disponibilité de service de voix sur IP moyennant peu de ressources (messages échangés réduits).
Elle est d'autant plus pertinente que de nombreuses situations de changement d'adresses de contact existent aujourd'hui (ex. suite au redémarrage des dispositifs) et/ou sont à prévoir dans les futurs réseaux de télécommunication (ex. en cas de basculement d'un réseau d'accès à un autre, dans des situations de nomadisme, etc.).
Par ailleurs, conformément à l'invention, si l'ensemble des adresses enregistrées auprès du cœur de réseau sont actives, c'est-à-dire si avant l'expiration de la période de temps prédéterminée, l'ensemble des adresses enregistrées correspondent à des adresses de contact
« courantes » de dispositifs et que toutes de ce fait répondent au message d'interrogation ou sont déclarées actives en réponse au message d'interrogation (par exemple par un équipement intermédiaire tel qu'un serveur de bordure (ou SBC pour Session Border Controller) placé en coupure de flux pour l'enregistrement au cœur de réseau entre les dispositifs et le cœur de réseau), la requête est rejetée. Il résulte du rejet de cette requête que l'enregistrement du dispositif auprès du cœur de réseau avec son adresse de contact courante n'est pas possible.
L'invention permet ainsi dans une certaine mesure d'éviter qu'un dispositif qui n'a pas lieu de s'enregistrer auprès du cœur de réseau compte-tenu de la capacité d'enregistrement permise pour un identifiant public donné, puisse s'enregistrer et prendre la place d'un dispositif autorisé.
On notera que le procédé de gestion selon l'invention peut être mis en œuvre à divers endroits du réseau IP, i.e. par un équipement du cœur de réseau de voix sur IP ou par un équipement situé à l'extérieur du cœur de réseau.
Ainsi, par exemple, il peut être mis en œuvre, notamment pour la gestion de requêtes d'enregistrement, par un serveur d'enregistrement du cœur de réseau, tel qu'un serveur S-CSCF (Serving-Call State Control Function) pour un cœur de réseau SIP IMS, ou un serveur PROXY
REGISTRAR pour un cœur de réseau SIP non IMS), apte à mettre à jour les tables d'enregistrement associées aux identifiants publics. En variante, il peut également être mis en œuvre par un équipement externe au cœur de réseau (ex. un système d'information de l'opérateur VoIP) qui serait en charge par exemple de faire une présélection des dispositifs pouvant présenter une requête d'enregistrement auprès du cœur de réseau compte tenu du nombre d'adresses de contact déjà enregistrées pour un identifiant public donné, cet équipement étant apte à interroger le cœur de réseau pour obtenir ce nombre.
Dans un mode particulier de réalisation de l'invention, au cours de l'étape d'acceptation, l'adresse de contact courante du dispositif est enregistrée sur le cœur de réseau en association avec l'identifiant public en remplacement d'une adresse de contact n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse au message d'interrogation.
Corrélativement, dans ce mode de réalisation, les moyens pour accepter la requête du serveur de gestion sont aptes à enregistrer l'adresse de contact courante du dispositif sur le cœur de réseau en association avec l'identifiant public en remplacement d'une adresse de contact n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse au message d'interrogation.
Ce mode de réalisation permet une mise à jour de la table d'enregistrement associée à l'identifiant public du dispositif avec son adresse de contact courante, de sorte à finaliser l'enregistrement du dispositif auprès du cœur de réseau.
Il a une application privilégiée notamment lorsque le procédé de gestion selon l'invention est mis en œuvre pour la gestion de requêtes d'enregistrement par un serveur d'enregistrement du cœur de réseau apte à modifier la table d'enregistrement associée à l'identifiant public contenu dans la requête (ex. par un serveur S-CSCF dans le cas d'un cœur de réseau IMS).
Ainsi, par exemple, lorsque plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation, l'adresse de contact courante du dispositif peut être enregistrée en remplacement de l'adresse de contact qui correspond à la durée d'expiration d'enregistrement la plus faible parmi lesdites plusieurs adresses de contact qui n'ont pas répondu au message d'interrogation ou qui ont été déclarées inactives en réponse au message d'interrogation.
II s'agit par ce biais de supprimer de la table d'enregistrement l'adresse de contact enregistrée (ou réenregistrée) la plus ancienne parmi les adresses non utilisées (i.e. inactives).
Selon un autre exemple, lorsque plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation, l'adresse de contact courante du dispositif est enregistrée en remplacement de l'adresse de contact qui est associée à une priorité la plus faible parmi lesdites plusieurs adresses de contact.
Pour un cœur de réseau VOIP mettant en œuvre le protocole SIP, cette priorité peut être par exemple déterminée à l'aide du champ q de l'adresse de contact défini par le document RFC3261 intitulé « SIP: Session Initiation Protocol » édité par l'IETF, et contenu dans la requête d'enregistrement ayant permis l'enregistrement de cette adresse de contact sur le cœur de réseau.
Dans un autre mode de réalisation de l'invention, le procédé de gestion comprend en outre une étape de vérification, avant d'accepter la requête, qu'au moins une adresse qui n'a pas répondu au message d'interrogation ou qui a été déclarée inactive en réponse au message d'interrogation correspond à la durée d'expiration d'enregistrement la plus faible parmi les adresses de contact enregistrées auprès du cœur de réseau en association avec l'identifiant public, la requête émise par le dispositif étant rejetée dans le cas contraire.
Ce mode de réalisation a une application privilégiée lorsque le procédé de gestion est mis en œuvre par un équipement distinct du serveur d'enregistrement du cœur de réseau, et que le cœur de réseau applique une politique de type « FIFO » pour gérer l'enregistrement des adresses de contact qui consiste à éjecter le cas échéant l'adresse de contact qui correspond à la durée d'expiration d'enregistrement la plus faible.
Dans un autre mode de réalisation de l'invention, le procédé de gestion comprend en outre si plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation à l'issue de ladite période de temps prédéterminée, une étape de désenregistrement de ces adresses dans ledit cœur de réseau.
Au cours de cette étape de désenregistrement, on supprime ainsi avantageusement de la table d'enregistrement correspondant à l'identifiant public maintenue par le cœur de réseau toutes les adresses de contact non pertinentes car inactives et non correctement désenregistrées. De cette façon, les procédures d'enregistrement ultérieures entreprises par des dispositifs auprès du cœur de réseau seront plus rapides.
L'étape de désenregistrement peut en outre comprendre la notification d'au moins un serveur du cœur de réseau VoIP tel que par exemple un serveur P-CSCF (Proxy Call Session Control Function) ou un serveur d'application, du désenregistrement de ces adresses.
Dans un mode de réalisation, le message d'interrogation peut être réémis plusieurs fois durant la période de temps prédéterminée vers au moins une des adresses de contact.
Ceci permet de parer à d'éventuels problèmes de transmission et/ou de réception des messages d'interrogation et/ou de leurs réponses. Par ailleurs, l'équipement auquel est envoyé le message d'interrogation dispose de plusieurs occasions de répondre à ce message (notamment s'il est occupé et ne peut répondre dès la première émission).
Dans un mode de réalisation de l'invention, le dispositif est en outre associé à un identifiant privé, et le procédé de gestion est mis en œuvre en considérant les adresses de contact enregistrées sur le cœur de réseau en association avec le couple formé par l'identifiant public et l'identifiant privé associés au dispositif.
Autrement dit, l'invention propose un procédé de gestion des requêtes qui peut être facilement configuré de sorte à prendre en compte : — soit toutes les adresses de contact enregistrées pour un même identifiant public indépendamment de l'identifiant privé du dispositif cherchant à s'enregistrer ;
— soit uniquement les adresses de contact enregistrées pour un même identifiant public qui correspondent à l'identifiant privé du dispositif cherchant à s'enregistrer ou à des identifiants privés déterminés (ex. tous les identifiants privés associés à un même identifiant public à l'exception d'un ou de plusieurs identifiants privés prédéfinis (correspondant par exemple à des dispositifs prioritaires), ou tous les identifiants privés en liaison avec le dispositif cherchant à s'enregistrer (correspondant par exemple à des dispositifs du même type que le dispositif cherchant à s'enregistrer), etc.).
Ainsi l'invention peut avantageusement s'appliquer dans différents modes de fonctionnement du cœur de réseau, c'est-à-dire aussi bien :
— dans un mode de fonctionnement où plusieurs équipements ou dispositifs partagent à la fois la même identité publique et la même identité privée, que
— dans un mode de fonctionnement où ils partagent la même identité publique mais disposent d'identités privées distinctes (ex. mode de fonctionnement normalisé sous le nom de « Shared
IMPU » dans le standard 3GPP pour les cœurs de réseau IMS), ou que
— dans un mode de fonctionnement hybride entre ces deux modes de fonctionnement.
Dans une variante de réalisation de l'invention, le message d'interrogation est également envoyé aux adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public du dispositif lorsque la capacité maximale n'est pas atteinte. Ceci peut être réalisé systématiquement, par exemple à chaque réception d'une requête d'enregistrement d'une adresse de contact courante d'un dispositif, ou à des intervalles de temps prédéterminés (ex. périodiquement).
Ceci permet, en analysant les réponses reçues à ce message d'interrogation (ou de façon équivalente les réponses non reçues), de nettoyer la table d'enregistrement correspondant à l'identifiant public, indépendamment du fait que la capacité maximale soit atteinte. On limite ainsi les phénomènes induis de blocage des enregistrements, et les procédures d'enregistrement à proprement parler sont accélérées.
Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur de gestion ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de gestion tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un autre aspect, l'invention vise également un système d'un cœur de réseau de voix sur IP, comprenant :
— un serveur de gestion conforme à l'invention, apte à gérer une requête émise par un dispositif associé à un identifiant public, en vue d'un enregistrement sur le cœur de réseau d'une adresse de contact courante de ce dispositif ; et
— au moins une table d'enregistrement pour cet identifiant public, contenant au moins une adresse de contact distincte de l'adresse courante, enregistrée sur le cœur de réseau en association avec ledit identifiant public, ladite au moins une table d'enregistrement étant consultée par ledit serveur lors de la réception de la requête pour obtenir le nombre d'adresses de contact enregistrées sur le cœur de réseau en association avec cet identifiant public.
Le système selon l'invention dispose des mêmes avantages que le procédé et le serveur de gestion selon l'invention décrits précédemment.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le serveur de gestion et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures :
— la figure 1 représente, de façon schématique, un système et un serveur de gestion conformes à l'invention dans un mode particulier de réalisation ;
— la figure 2 illustre un exemple de table d'enregistrement maintenue par le serveur de gestion illustré à la figure 1 ; — la figure 3 représente, de façon schématique, l'architecture matérielle du serveur de gestion dans le mode de réalisation de la figure 1 ;
— la figure 4 représente sous forme d'ordinogramme, les principales étapes d'un procédé de gestion selon l'invention lorsqu'il est mis en œuvre dans un mode de réalisation de l'invention par le serveur représenté sur la figure 1 ;
— les figures 5A et 5B illustrent différents états de la table d'enregistrement maintenue par le serveur de gestion représenté sur la figure 1 ;
— la figure 6 illustre une table d'enregistrement associée à un couple (identifiant public, identifiant privé) ; et
— la figure 7 illustre sous forme d'ordinogramme, les principales étapes d'un procédé de gestion selon l'invention lorsqu'il est mis en œuvre dans un autre mode de réalisation de l'invention, par un serveur de gestion externe au cœur de réseau.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système 1 d'un cœur de réseau
CN de voix sur IP, conforme à l'invention, dans un mode particulier de réalisation.
Le système 1 permet la gestion des requêtes émises à destination du cœur de réseau CN en vue de l'enregistrement d'une adresse de contact courante d'un dispositif sur ce cœur de réseau.
Dans le mode de réalisation décrit ici, le cœur de réseau CN de voix sur IP est un cœur de réseau IMS mettant en œuvre le protocole SIP. Ces hypothèses ne sont toutefois pas limitatives, l'invention s'appliquant également, comme mentionné précédemment, à d'autres architectures de cœur de réseau VoIP (ex. H323, MGCP, Peer2Peer, REGISTRAR), ainsi qu'à d'autres protocoles applicatifs VoIP tels que par exemple XMPP, ainsi qu'à d'autres protocoles propriétaires.
Dans l'exemple décrit ici, on envisage plus particulièrement la gestion de requêtes émises par des dispositifs A et B partageant une même identité (ou identifiant) publique IMPU 1. L'identifiant IMPU1 est ici une identité IMPU, connue en soi et telle que définie par le standard 3GPP notamment dans le document 3GPP TS 23.228 intitulé «IP Multimedia Subsystem », Release 9, Septembre 2010.
Les dispositifs A et B sont respectivement ici un terminal (ex. téléphone, tablette numérique, etc.) et une passerelle domestique, équipés d'une pile VoIP. Toutefois l'invention s'applique également à d'autres types de dispositifs équipés d'une pile VoIP tels que par exemple à des serveurs, etc.
Chaque dispositif A et B est doté respectivement d'une adresse de contact courante, notée AoCA et AoCB : comme précisé précédemment, cette adresse de contact représente une adresse de joignabilité du dispositif dans le domaine IP, et comprend notamment l'adresse IP du dispositif, un numéro de port associé à sa pile VoIP ainsi que le protocole de transport (ex. UDP, TCP, TLS) utilisé par le dispositif pour communiquer dans le domaine IP.
Conformément à l'invention, le système 1 comprend un serveur de gestion 2 conforme à l'invention et des tables (ou contextes) d'enregistrement T associées respectivement à chaque identifiant public (ou à chaque couple (identifiant public,identifiant privé)) en relation avec lequel une requête d'enregistrement a été émise à destination du cœur de réseau.
Par table d'enregistrement associée à un identifiant public donné ou à un couple (identifiant public,identifiant privé) donné, on entend ici une structure de données quelconque qui permet de stocker des informations relatives à des enregistrements réalisés pour cet identifiant public donné ou pour ce couple (identifiant public,identifiant privé) donné. Une telle table est connue en soi et ne sera pas décrite en détail ici.
Chaque table d'enregistrement associée à un identifiant public (respectivement à un couple (identifiant public,identifiant privé)) contient notamment les adresses de contact des dispositifs qui se sont enregistrés en association avec cet identifiant public (respectivement en association avec ce couple (identifiant public,identifiant privé)), ainsi que la durée d'expiration de leurs enregistrements (valeur du paramètre Expires dans le protocole SIP).
On notera qu'une table d'enregistrement associée à un identifiant public donné peut elle-même être constituée de plusieurs « sous-tables » distinctes, chaque sous-table étant associée à un couple formé de cet identifiant public donné et d'un identifiant privé distinct et contenant les adresses enregistrées en association avec ce couple.
Le nombre maximal d'adresses de contact pouvant être enregistrées dans la table est fixé par exemple par l'opérateur du cœur de réseau et dépend de la politique envisagée pour le contrôle des enregistrements associés à un même identifiant public (respectivement à un même couple (identifiant public,identifiant privé)). Ce nombre constitue une capacité maximale Cmax d'enregistrement pour un identifiant public (respectivement pour un couple (identifiant public,identifiant privé))) au sens de l'invention. Il peut varier en fonction des identifiants, des types de dispositifs que l'on souhaite enregistrer (ex. si l'on fait une distinction entre les dispositifs au moment de l'enregistrement dans la politique de contrôle), etc.
Dans l'exemple envisagé à la figure 2, la table T(IMPUl) associée à l'identifiant public IMPU1 correspond à une capacité maximale Cmax=2 et comprend les adresses de contact courantes AoCA et AoCB des dispositifs A et B, ainsi que les durées d'expiration respectives EXPA et EXPB de ces enregistrements.
Le serveur de gestion 2 est dans le mode de réalisation décrit ici intégré au serveur d'enregistrement S-CSCF du cœur de réseau CN. De façon connue, le serveur S-CSCF d'un cœur de réseau VoIP est en charge des enregistrements sur ce cœur de réseau, et est notamment apte à gérer et à modifier les tables d'enregistrement associées aux différents identifiants publics.
Il dispose ici de l'architecture matérielle d'un ordinateur telle que représentée schématiquement sur la figure 3. Il comporte notamment un processeur 3, une mémoire vive 4, une mémoire morte 5, une mémoire réinscriptible non volatile 6 (dans laquelle sont stockées par exemple les tables d'enregistrement maintenues par le serveur 2), ainsi que des moyens de communication 7 mettant en œuvre notamment le protocole SIP connus en soi.
La mémoire morte 5 du serveur 2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 3 et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de gestion d'une requête conforme à l'invention, décrites maintenant en référence à la figure 4, dans un mode particulier de réalisation.
Pour illustrer ce mode de réalisation, on envisage ici le traitement par le serveur 2 d'une requête d'enregistrement émise par le terminal A à destination du cœur de réseau CN. Cette requête est ici un message SIP REGISTER contenant notamment l'identifiant public IMPU1 du terminal A ainsi que son adresse de contact courante AoCA.
Sur réception de cette requête (étape E10), le serveur de gestion 2 détermine si l'adresse de contact AoCA est une nouvelle adresse de contact non encore enregistrée pour l'identifiant IMPU1 ou si la requête est en fait une requête de réengistrement du terminal AoCA (étape E20).
Dans le mode de réalisation SIP décrit ici, le serveur de gestion 2 extrait à cette fin l'identifiant de dialogue présent de façon connue en soi dans la requête SIP REGISTER, et détermine si cet identifiant de dialogue correspond à un dialogue déjà établi avec le cœur de réseau.
Si tel est le cas, la requête reçue est une requête de réenregistrement, autrement dit, l'adresse de contact courante AoCA est déjà enregistrée dans la table T(IMPUl) (réponse non au test de l'étape E20) : le serveur 2 met alors à jour dans la table T(IMPUl) la durée d'expiration d'enregistrement EXPA associée au terminal A (étape E30). Par exemple, EXPA=lheure.
II envoie ensuite un message de réponse au terminal A, contenant la valeur de la durée EXPA (étape E40). Ce message de réponse est ici un message SIP 200OK contenant un paramètre EXPIRES=lheure.
Si au contraire, le serveur de gestion 2 détermine que la requête reçue n'est pas une requête de réenregistrement mais une requête d'enregistrement initial (réponse oui au test de l'étape E20), il recherche dans sa mémoire réinscriptible non volatile 6 si une table d'enregistrement T(IMPUl) associée à l'identifiant public IMPU1 existe.
Le cas échéant, le serveur de gestion 2 consulte cette table d'enregistrement et vérifie en préliminaire ici que l'adresse de contact AoCA n'est pas encore enregistrée en association avec l'identifiant public IMPU1 dans cette table. Comme mentionné précédemment, si l'adresse de contact AoCA est déjà enregistrée dans la table T(IMPUl), alors le serveur de gestion 2 en déduit un dysfonctionnement du réseau qu'il peut signaler de façon connue en soi, notamment par un message d'erreur envoyé au terminal A. On suppose ici qu'une telle table existe déjà dans la mémoire 6 du serveur de gestion 2 (cette table a par exemple été créée lors d'un enregistrement précédent avec l'identifiant public IMPU1).
Le serveur de gestion 2 obtient en consultant cette table d'enregistrement le nombre Nb-AoC d'adresses de contact déjà enregistrées en association avec l'identifiant public IMPU1, selon des moyens connus en soi non détaillés ici (étape E50).
Puis il compare ce nombre Nb-AoC avec la capacité maximale Cmax d'enregistrement associée à l'identifiant IMPU1, afin de déterminer si la capacité maximale d'enregistrement est déjà atteinte (étape E60).
Si Nb-AoC est inférieur à Cmax (réponse non au test de l'étape E60), le serveur de gestion 2 accepte la requête d'enregistrement du terminal A (étape E70).
Dans l'exemple décrit ici, le serveur de gestion 2 met alors à jour la table d'enregistrement T(IMPU l) en ajoutant l'adresse de contact AoCA courante du terminal A ainsi qu'une durée d'expiration d'enregistrement EXPA égale à 1 heure (étape E80), et envoie un message 200 OK contenant la durée EXPA au terminal A (étape E90).
La figure 5A illustre un exemple d'une telle mise à jour lorsque la table T(IMPUl) contient initialement une seule adresse de contact (état (a) sur la figure 5A), à savoir l'adresse de contact AoCB de la passerelle B. A l'issue de la mise à jour (état (b) sur la figure 5A), la table T(IMPU l) contient l'adresse de contact AoCB de la passerelle B ainsi que l'adresse de contact AoCA du terminal A. La capacité maximale d'enregistrement associée à l'identifiant public IMPU1 est alors atteinte.
Si au contraire, à l'issue de l'étape E60 de comparaison, le serveur de gestion 2 détecte que la capacité maximale d'enregistrement est déjà atteinte (réponse oui au test de l'étape E60), il déclenche dans le mode de réalisation décrit ici un temporisateur t pour une période de temps prédéterminée notée d(étape E100).
Cette période d est choisie ici de sorte à permettre au serveur de gestion 2 de répondre à la requête d'enregistrement du terminal A dans les limites du temps de réponse prévu par le cœur de réseau (autrement dit ici conformément au temps de réponse défini par le standard 3GPP pour les cœurs de réseau IMS qui est de 32 secondes), afin que les étapes supplémentaires mises en œuvre par le serveur de gestion 2 pour déterminer s'il accepte ou non la requête d'enregistrement soient transparentes pour le terminal A.
La figure 5B illustre un exemple pour la table T(IMPUl) dans lequel la capacité maximale d'enregistrement a été atteinte : dans cet exemple, la passerelle B est enregistrée par l'intermédiaire de deux adresses de contact AoCB et AoCB' associées respectivement à des durées d'enregistrement EXPB et EXPB' (état (a) sur la figure 5B).
Puis, conformément à l'invention, le serveur de gestion 2 envoie à toutes les adresses de contact enregistrées dans la table T(IMPUl) en association avec l'identifiant public IMPU1, un message d'interrogation afin de déterminer si ces adresses de contact sont toujours actives, c'est- à-dire utilisées comme adresses de contact courantes par les dispositifs qui ont requis leur enregistrement (étape E110).
Comme mentionné précédemment, un message d'interrogation au sens de l'invention désigne un message qui appelle une réponse de la part de son destinataire, autrement dit, auquel le destinataire identifié dans le message répond en temps normal lorsqu'il reçoit ce message.
Ce message d'interrogation est choisi préférentiellement de sorte à ne pas perturber les sessions en cours (ex. communications) au niveau des dispositifs auxquels il est envoyé. Dans le mode de réalisation décrit ici, ce message d'interrogation est un message SIP OPTIONS, qui contient dans la RURI du message (ou Request URI en anglais), l'adresse de contact à laquelle le message est destiné, et dans le champ FROM, l'identifiant du serveur de gestion 2.
Dans l'exemple envisagé à la figure 5B, le serveur de gestion 2 envoie donc un message SIP OPTIONS à l'adresse de contact AoCB et un message SIP OPTIONS à l'adresse de contact AoCB'.
Puis le serveur de gestion 2 se place en attente des réponses aux messages d'interrogation envoyés, jusqu'à l'expiration du temporisateur t (étape E120).
Dans une variante de réalisation, si le serveur de gestion 2 n'a pas reçu de réponse d'une (ou de plusieurs) adresse de contact à laquelle il a envoyé un message d'interrogation à des intervalles de temps déterminés précédant l'expiration du temporisateur t, il retransmet le message d'interrogation une ou plusieurs fois (par exemple deux fois) à cette adresse de contact avant l'expiration du temporisateur t, afin de pallier à d'éventuels problèmes de transmission entre le serveur de gestion 2 et le dispositif associé à cette adresse de contact.
A l'issue de la période d(\.e. à l'expiration du temporisateur t), le serveur de gestion 2 détermine si toutes les adresses de contact auxquelles il a envoyé un message d'interrogation sont actives.
Dans le mode de réalisation décrit ici et pour une configuration de réseau semblable à celle représentée sur la figure 1, le serveur de gestion 2 détermine à cette fin s'il a reçu des réponses au message d'interrogation de toutes les adresses de contact répertoriées dans la table T(IMPUl), c'est-à-dire, dans l'exemple envisagé à la figure 5B, des adresses de contact AoCB et AoCB' (étape El 30). Ces messages de réponse peuvent être par exemple des messages SIP 200OK en cas de disponibilité du dispositif, ou 486 Busy Here si le dispositif est en cours de communication.
Si tel est le cas (réponse oui au test de l'étape E130), le serveur de gestion 2 en déduit que toutes les adresses de contact enregistrées dans la table T(IMPUl) sont actives et rejette alors la requête d'enregistrement du terminal A (étape E140). Par exemple, il envoie au terminal A un message SIP 403 Forbidden.
Si en revanche, au moins une adresse de contact n'a pas répondu à l'issue de la période de temps d au message d'interrogation envoyé par le serveur de gestion 2 (réponse non au test de l'étape E130), le serveur de gestion 2 en déduit que cette adresse de contact n'est plus active (par exemple parce que le dispositif qui s'était enregistré avec cette adresse de contact a changé d'adresse de contact courante ou est éteint) et n'a pas lieu de rester enregistrée dans la table T(IMPUl). Conformément à l'invention, le serveur de gestion 2 accepte donc la requête d'enregistrement émise par le terminal A.
Par ailleurs, dans le mode de réalisation décrit ici, le serveur de gestion 2 met à jour la table d'enregistrement T(IMPUl) avec l'adresse de contact courante AoCA du terminal A et la durée d'expiration EXPA (étape E160), puis envoie au terminal A un message SIP 200OK associé à une durée d'expiration d'enregistrement EXPA= 1 heure pour lui signifier l'acceptation de sa requête d'enregistrement (étape E170).
Plusieurs cas de figure peuvent se présenter lors de la mise à jour de la table
T(IMPUl) à l'étape E160 :
(1) une seule adresse de contact n'a pas répondu au message d'interrogation envoyé par le serveur de gestion 2 ; ou
(2) plusieurs adresses de contact n'ont pas répondu au message d'interrogation envoyé par le serveur de gestion 2 (ce cas de figure suppose une capacité maximale d'enregistrement supérieure à 1).
Dans le cas de figure (1), le serveur de gestion 2 désenregistre l'adresse de contact n'ayant pas répondu (autrement dit il la supprime de la table d'enregistrement T(IMPUl)), et enregistre dans la table T(IMPUl) en remplacement de cette adresse, l'adresse de contact courante AoCA du terminal A et la durée d'expiration EXPA.
La figure 5B illustre une telle mise à jour.
Dans l'exemple envisagé à la figure 5B, on suppose par exemple que la passerelle B a redémarré de façon brusque alors qu'elle utilisait l'adresse de contact AoCB' et n'a pas pu se désenregistrer avant son redémarrage auprès du cœur de réseau CN. Suite à son redémarrage, on suppose que la passerelle B a maintenant pour adresse de contact courante l'adresse AoCB, l'adresse AoCB' étant inactive, de sorte que la table T(IMPUl) contient les deux adresses de contact AoCB' et AoCB associées respectivement aux durées d'expiration EXPB' et EXPB (état (a) de la table T(IMPUl) sur la figure 5B).
La passerelle B n'utilisant plus l'adresse de contact AoCB', le serveur de gestion 2 ne reçoit pas de message de réponse de cette adresse au message d'interrogation envoyé à l'étape El 10. Aussi au cours de l'étape de mise à jour E160, il supprime l'adresse de contact inactive AoCB' (et la durée EXPB de la table T(IMPUl) et la remplace par l'adresse de contact AoCA du terminal A (et la durée d'expiration EXPA) (état (b) de la table T(IMPUl) sur la figure 5B).
Dans le cas de figure (2), différentes politiques de mise à jour peuvent être envisagées, d'une part pour identifier quelle adresse de contact va être supprimée de la table pour enregistrer l'adresse de contact courante du terminal A, et d'autre part pour traiter les autres adresses de contact qui n'ont pas répondu au message d'interrogation. Dans le mode de réalisation décrit ici, le serveur de gestion 2 éjecte (i.e. désenregistre du cœur de réseau CN) l'adresse de contact n'ayant pas répondu au message d'interrogation qui correspond à la durée d'expiration la plus faible, et enregistre dans la table T(IMPUl) en remplacement de cette adresse, l'adresse de contact AoCA et la durée d'expiration EXPA. On notera que dans l'hypothèse où l'ensemble des dispositifs est configuré pour envoyer des messages de réenregistrement au cœur de réseau selon une même période de temps, ce mode de réalisation est équivalent à enregistrer l'adresse de contact du terminal A en remplacement de l'adresse de contact correspondant à l'enregistrement le plus ancien.
Par ailleurs, dans le mode de réalisation décrit ici, le serveur de gestion 2 éjecte également de la table T(IMPUl) (i.e. désenregistre du cœur de réseau) les autres adresses de contact qui n'ont pas répondu au message d'interrogation à l'issue de la durée d. Il s'agit par ce biais de nettoyer la table d'enregistrement des adresses de contact inactives afin de simplifier et d'accélérer les enregistrements ultérieurs. Cette mise à jour de la table d'enregistrement permet également d'éviter l'envoi de messages inutiles sur le réseau, notamment lorsqu'un appel entrant (message SIP INVITE) destiné à un identifiant public enregistré auprès du cœur de réseau arrive. En effet, conformément au standard 3GPP, lorsque plusieurs adresses de contact sont associées à un même identifiant public dans le cœur de réseau, le message SIP INVITE est présenté à chacune de ces adresses de contact. L'invention permet ainsi de limiter les retransmissions inutiles du message SIP INVITE aux adresses de contact qui ne sont plus actives.
Dans une variante de réalisation, ces autres adresses de contact ne sont pas supprimées de la table.
Dans une autre variante encore de réalisation l'étape de désenregistrement de l'adresse ou des adresses de contact inactives du cœur de réseau peuvent en outre s'accompagner de la notification d'au moins un serveur du cœur de réseau VoIP tel que par exemple un serveur P- CSCF (Proxy Call Session Control Function) ou un serveur d'application, de la suppression de cette ou de ces adresses de la table d'enregistrement.
D'autres politiques de mise à jour de la table pourraient être envisagées pour déterminer quelle adresse de contact va être supprimée de la table afin d'enregistrer l'adresse de contact courante du terminal A.
Ainsi, par exemple, une alternative peut consister à éjecter l'adresse de contact qui est associée à la priorité la plus faible parmi les adresses de contact qui n'ont pas répondu au message d'interrogation.
Cette priorité peut être déterminée par le serveur de gestion 2 en consultant la valeur du champ « q » prévu au niveau de l'adresse de contact par le standard IETF (Internet Engineering Task Force) pour le protocole SIP, et décrit dans le document RFC3261 mentionné précédemment. Conformément à ce document, le champ « q » est un réel compris entre 0 et 1, la valeur 1 désignant un dispositif de priorité maximale, tandis que la valeur 0 désigne la priorité la plus faible (l'absence de valeur q est équivalent à une valeur q=0). Ce champ est présent notamment dans chaque requête d'enregistrement d'une adresse de contact envoyée au cœur de réseau. Pour mettre en œuvre cette alternative, la table d'enregistrement associera en outre à chaque adresse de contact stockée, la valeur correspondante du champ « q » (valeur contenue dans la requête d'enregistrement ayant permis l'enregistrement de cette adresse de contact sur le cœur de réseau).
En variante, la priorité d'un dispositif peut être associée à une plage d'adresses IP dans laquelle se trouve son adresse de contact. Par exemple, on peut envisager d'associer à diverses plages d'adresses de contact différents types de dispositifs en fonction de leur priorité : ainsi, une première plage d'adresses pourrait être associée aux dispositifs prioritaires tels que des passerelles, une deuxième plage d'adresses aux terminaux connectés derrière la passerelle, et une troisième plage d'adresses aux terminaux connectés à des points d'accès accessibles en situation de nomadisme, cette troisième plage d'adresses définissant une catégorie de dispositifs moins prioritaires au sens « usage du cœur de réseau » du terme.
Dans le mode de réalisation décrit ici en référence à la configuration de réseau illustrée à la figure 1, le serveur de gestion 2 détermine si les adresses de contact sont actives en détectant la présence (ou l'absence) de réponses reçues de ces adresses de contact aux messages d'interrogation envoyés. Dans cette configuration en effet, les messages de réponse sont transmis jusqu'au serveur de gestion 2.
Toutefois, l'invention s'applique également à d'autres configurations de réseau, et en particulier, à une configuration de réseau dans laquelle des équipements intermédiaires tels que des serveurs de bordure SBC sont prévus dans la gestion des enregistrements entre le cœur de réseau CN et les dispositifs auxquels le serveur de gestion 2 envoie les messages d'interrogation, afin par exemple de diminuer la charge du serveur de gestion 2 et d'assurer un trafic régulier à l'accès. Dans une telle configuration, les messages de réponse des dispositifs sont reçus par les équipements intermédiaires ; de même l'absence de messages de réponse à l'issue de la période d est détectée par ces équipements intermédiaires. Les équipements intermédiaires envoient ensuite à leur tour un message déclarant l'activité ou l'inactivité de l'adresse de contact au serveur de gestion 2.
Ainsi, dans une telle configuration de réseau, au cours de l'étape E130, pour déterminer si à l'issue de la période d toutes les adresses de contact auxquelles il a envoyé un message d'interrogation sont actives, le serveur de gestion 2 analyse si tous les messages reçus du ou des équipements intermédiaires en réponse à ces messages d'interrogation l'informent d'une activité des dispositifs associés à ces adresses de contact.
Si tel est le cas (réponse oui au test de l'étape E130), le serveur de gestion 2 en déduit que toutes les adresses de contact enregistrées dans la table T(IMPUl) sont actives et rejette la requête d'enregistrement du terminal A (étape E140).
Si en revanche, à l'issue de la période de temps d, il a reçu pour au moins une adresse de contact, un message d'un équipement intermédiaire déclarant en réponse au message d'interrogation l'inactivité du dispositif associé à cette adresse de contact (par exemple un message 480 No Route Found), il en déduit que cette adresse de contact n'est plus active (réponse non au test de l'étape E130). Conformément à l'invention, le serveur de gestion 2 accepte donc la requête d'enregistrement émise par le terminal A.
Corrélativement, la sélection de l'adresse (ou des adresses) de contact à éjecter de la table d'enregistrement, notamment pour permettre l'enregistrement de l'adresse de contact du terminal A, est effectuée parmi les adresses de contact qui ont été déclarées inactives par l'un des équipements intermédiaires en réponse aux messages d'interrogation envoyés par le serveur de gestion 2.
Bien entendu, l'invention s'applique également avec des configurations hybrides du réseau dans lesquels des équipements intermédiaires sont présents pour seulement une partie des dispositifs aptes à s'enregistrer auprès du cœur de réseau CN. Dans un tel cas de figure, le serveur de gestion 2 vérifie, avant d'accepter la requête d'enregistrement émise par le terminal A si, à l'issue de la période de temps d, au moins une adresse de contact n'a pas répondu au message d'interrogation ou a été déclarée comme inactive par l'un des équipements intermédiaires en réponse au message d'interrogation (par exemple via un message 480 No Route Found). Corrélativement, la sélection de l'adresse (ou des adresses) de contact à éjecter de la table d'enregistrement est effectuée parmi les adresses de contact qui n'ont pas répondu aux messages d'interrogation envoyés par le serveur de gestion 2 ou qui ont été déclarées inactives par l'un des équipements intermédiaires en réponse à ces messages d'interrogation.
Dans les exemples considérés pour illustrer l'invention, on a envisagé la gestion d'une requête d'enregistrement émise par le terminal A et une table d'enregistrement contenant deux adresses de contact de la passerelle B, l'une d'elle étant inactive. L'invention s'applique bien entendu à d'autres situations, comme par exemple lorsque la table d'enregistrement T(IMPUl) contient une adresse de contact de la passerelle B et une adresse de contact inactive du terminal A distincte de son adresse de contact courante qu'il n'a pas désenregistrée auprès du cœur de réseau.
Dans le mode de réalisation décrit ici, la gestion de la requête d'enregistrement est réalisée pour un identifiant public indépendamment de la politique envisagée dans le cœur de réseau concernant l'attribution des identifiants privés aux dispositifs partageant cet identifiant public (ex. même identifiant privé pour tous les dispositifs partageant un même identifiant public, ou identifiants privés distincts pour chaque dispositif, ou mécanisme hybride dans lequel des identifiants privés distincts sont attribués à des groupes distincts de dispositifs).
Dans un autre mode de réalisation de l'invention, le serveur de gestion 2 met en œuvre l'invention en prenant en outre en compte les identifiants privés des dispositifs, également contenus dans les requêtes d'enregistrement émis par ces dispositifs. Plus précisément dans ce mode de réalisation, les étapes du procédé selon l'invention décrites précédemment en référence à la figure 4 sont alors mises en œuvre à partir d'une table d'enregistrement T(IMPU1,IMPIA) associée au couple formé par l'identifiant public IMPU 1 et l'identifiant privé IMPIA du terminal, et en considérant les adresses de contact enregistrées dans cette table (ex. Nb-AoC correspond au nombre d'enregistrements de la table associée au couple (identifiant public, identifiant privé) du terminal A, Cmax correspond à la capacité maximale d'enregistrements associée à ce couple, et l'adresse de contact AoCA est enregistrée le cas échéant en remplacement d'une adresse de contact de la table Τ(ΙΜΡΙΙ Ι,ΙΜΡΙΑ)).
La figure 6 illustre un exemple d'une table d'enregistrement T(IMPU 1, IMPIA) associée au couple T(IMPU 1,IMPIA) du terminal A et intégrée dans la table T(IMPU l) associée à l'identifiant public IMPU 1. Dans cet exemple, l'identifiant privé IMPIA est partagé par le terminal A et un autre dispositif C, tandis que la passerelle B a un identifiant privé distinct IMPIB. Les dispositifs A, B et C partagent le même identifiant public IMPU 1. La gestion des requêtes d'enregistrement par le cœur de réseau est réalisée à l'aide de files d'attente associées à chaque couple identifiant public- identifiant privé.
Ainsi, l'invention permet, dans les différents modes de réalisation décrits, de gérer les enregistrements soit en prenant en compte uniquement l'identifiant public contenu dans la requête (indépendamment de la politique d'attribution d'identifiants privés mise en œuvre par le cœur de réseau, ex. même identifiant privé partagé par plusieurs dispositifs ou un identifiant privé distinct pour chaque dispositif), soit en prenant en compte l'identifiant public et l'identifiant privé contenus dans la requête.
Dans le mode de réalisation décrit ici, le serveur de gestion 2 n'envoie de message d'interrogation que lorsque la capacité maximale d'enregistrement est atteinte dans la table d'enregistrement associée à l'identifiant public IMPU 1 ou dans la table d'enregistrement associée au couple formé par l'identifiant public IMPU et l'identifiant privé IMPI. En variante, un message d'interrogation similaire peut être envoyé aux adresses de contact de la table indépendamment du fait que la capacité maximale ait été atteinte, par exemple de façon périodique, afin de nettoyer régulièrement la table d'enregistrement des adresses de contact inactives. Les adresses de contact n'ayant pas répondu à ce message d'interrogation à l'expiration d'une durée prédéterminée (qui peut être identique ou non à la durée d) sont alors supprimées de la table T(IMPU l) ou Τ(ΙΜΡΙΙ Ι,ΙΜΡΙΑ) par le serveur de gestion 2.
Par ailleurs, dans le mode de réalisation décrit ici, le serveur de gestion 2 est intégré dans le serveur d'enregistrement du cœur de réseau CN. Autrement dit, le serveur de gestion 2 est apte à modifier la table d'enregistrement associée à l'identifiant public IMPU 1 ou au couple (identifiant public IMPU 1, identifiant privé IMPIA). Toutefois cette hypothèse n'est pas limitative et l'invention s'applique également lorsque le serveur de gestion 2 ne dispose pas d'une telle capacité.
Par exemple, dans un autre mode de réalisation, le serveur de gestion 2 peut être un serveur externe au cœur de réseau CN (ex. localisé dans le système d'information du réseau), apte à réaliser une présélection des dispositifs pouvant émettre des requêtes d'enregistrement auprès du cœur de réseau CN compte tenu du nombre d'adresses de contact déjà enregistrées pour un identifiant public donné (ou un couple (identifiant public, identifiant privé) donné), et plus précisément des requêtes destinées au serveur d'enregistrement du cœur de réseau CN qui lui est apte à mettre à jour les tables d'enregistrement et à accepter ou rejeter les requêtes d'enregistrement en fonction de la politique mise en œuvre dans le cœur de réseau CN.
Les étapes mises en œuvre au cours du procédé de gestion selon l'invention par le serveur de gestion dans cet autre mode de réalisation sont illustrées à la figure 7. Dans l'exemple envisagé sur cette figure, la gestion conformément à l'invention d'une requête émise en vue d'un enregistrement sur le cœur de réseau CN est réalisée en prenant en compte uniquement l'identifiant public contenu dans la requête. Bien entendu, ce mode de réalisation s'applique également lorsque l'on prend en compte également l'identifiant privé contenu dans la requête.
Dans ce mode de réalisation, les étapes ΕΙΟ', Ε20', E40' à E70', E90', E100' à E150', E170' mises en œuvre par le serveur de gestion (ainsi que les variantes associées) sont semblables aux étapes E10, E20, E40 à E70, E90, E100 à E150, E170 décrites précédemment en référence à la figure 4 (les étapes E30, E80 et E160 de mise à jour de la table d'enregistrement ne sont en revanche pas implémentées par le serveur de gestion). Les informations requises pour mettre en œuvre l'invention (ex. nombre d'adresses de contact et adresses de contact enregistrées dans la table d'enregistrement) sont toutefois obtenues par le serveur de gestion en interrogeant à l'aide de l'identifiant public par exemple le serveur d'enregistrement du cœur de réseau CN en utilisant la procédure SIP standard décrite dans le document IETF RFC3261 mentionné précédemment (i.e. envoi d'un message SIP REGISTER contenant l'identifiant public IMPU1 mais sans spécifier d'adresse de contact)).
Par ailleurs, compte-tenu du fait que dans ce mode de réalisation, la politique de suppression et de remplacement des adresses de contact dans la table d'enregistrement ne dépend pas du serveur de gestion, celui-ci doit s'assurer, avant de transmettre une requête d'enregistrement au cœur de réseau CN (autrement dit avant d'accepter une requête d'enregistrement d'un dispositif), qu'elle ne va pas déclencher l'éviction d'une adresse de contact de la table d'enregistrement qui ne serait pas souhaitable, par exemple parce que cette adresse de contact est toujours active. Une telle situation peut se présenter par exemple lorsque le cœur de réseau implémente une politique de type FIFO basée sur les durées d'expiration des enregistrements, qui consiste à remplacer par une nouvelle adresse de contact l'adresse de contact correspondant à la durée d'expiration d'enregistrement la plus faible.
Pour éviter une telle situation, avant d'accepter la requête d'enregistrement émise par le terminal A (autrement dit suite à une réponse non au test de l'étape E130' et avant de mettre en œuvre l'étape Ε150 , le serveur de gestion détermine si parmi les adresses de contact qui n'ont pas répondu au message d'interrogation, l'une d'elles correspond à la durée d'expiration la plus faible enregistrée dans la table d'enregistrement (étape E145 - Cette étape peut être mise en œuvre par exemple en interrogeant le serveur d'enregistrement du cœur de réseau CN. Si tel est le cas, alors le serveur de gestion accepte la requête d'enregistrement du terminal A (étape E150') et lui envoie un message SIP 200OK (étape E170 -
En revanche, si aucune des adresses de contact qui n'a pas répondu au message d'interrogation ne correspond à la durée d'expiration d'enregistrement la plus faible enregistrée en association avec l'identifiant public IMPU1, le serveur de gestion refuse la requête d'enregistrement du terminal A (étape E140 -
Dans l'exemple envisagé à la figure 7, l'étape E10' est identique à l'étape E10 et consiste en la réception d'une requête d'enregistrement SIP REGISTER émise par le terminal A à destination du cœur de réseau CN. En variante, la requête reçue à l'étape E10' peut être une requête distincte d'un message SIP REGISTER ou plus généralement une requête distincte d'un message spécifique prévu par le protocole mis en œuvre par le cœur de réseau pour l'enregistrement d'un dispositif. Il peut s'agir de façon générale d'une requête quelconque nécessaire à l'enregistrement du dispositif.
Ainsi par exemple, cette requête peut être un message envoyé par le terminal A visant à obtenir un fichier de configuration VoIP nécessaire à son enregistrement sur le cœur de réseau. Un tel message est par exemple un message HTTP Get Parameter contenant l'adresse IP du terminal A. On notera que l'obtention du fichier de configuration VoIP par le terminal A est indissociable de l'enregistrement du terminal A sur le cœur de réseau (et plus particulièrement de son adresse de contact courante),et fait partie de la procédure d'enregistrement mise en place par le terminal A dans le sens où d'une part l'obtention d'un tel fichier de configuration est un prérequis pour l'enregistrement de l'adresse de contact courante du terminal sur le cœur de réseau et d'autre part l'obtention de ce fichier n'a de sens que parce que le terminal A souhaite enregistrer son adresse de contact courante sur le cœur de réseau VoIP pour pouvoir communiquer sur ce cœur de réseau. Un message requérant l'obtention de ce fichier constitue donc une requête en vue d'un enregistrement sur le cœur de réseau d'une adresse de contact courante d'un dispositif au sens de l'invention.
On notera que lorsque la requête gérée par le procédé selon l'invention est un tel message, l'identifiant public IMPU1 associé au terminal A, utilisé notamment pour obtenir le nombre d'adresses de contact Nb-AoC et la capacité maximale d'enregistrement Cmax, peut être récupéré par le serveur de gestion à l'aide de l'adresse IP du terminal A contenue dans la requête, par exemple en interrogeant un système d'information de l'opérateur VoIP.
Par ailleurs, les étapes Ε40', E90' et E170' d'acception de la requête peuvent alors comprendre en outre l'envoi du fichier de configuration VoIP requis vers le terminal A (ce fichier comprend de façon connue en soi, l'identifiant public du terminal, son identifiant privé, l'adresse du point d'entrée du cœur de réseau VoIP, le nom du domaine du réseau VoIP, ainsi que d'autres champs liés à l'activation de services sur le cœur de réseau VoIP).
En revanche, lorsque la requête est refusée au cours de l'étape E140', le fichier de configuration VoIP requis n'est pas envoyé au terminal A. On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le serveur de gestion et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques décrites précédemment en référence aux figures 1 à 7.

Claims

REVENDICATIONS
1. Procédé de gestion d'une requête émise par un dispositif (A) associé à un identifiant public (IMPU1), en vue d'un enregistrement sur un cœur de réseau de voix sur IP (CN) d'une adresse de contact courante (AoCA) dudit dispositif pour ce cœur de réseau, ledit procédé de gestion comprenant :
— une étape d'obtention (Ε50,Ε50 , sur réception (ΕΙΟ,ΕΙΟ') de ladite requête, d'un nombre d'adresses de contact (Nb-AOC) enregistrées sur le cœur de réseau en association avec ledit identifiant public ; et
— une étape de comparaison (Ε60,Ε60') de ce nombre avec une capacité maximale d'enregistrement (Cmax) définie pour cet identifiant public ;
ledit procédé de gestion étant caractérisé en ce qu'il comprend en outre, lorsque ledit nombre a atteint ladite capacité maximale :
— une étape (ΕΙΙΟ,ΕΙΙΟ') d'envoi d'un message d'interrogation auxdites adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public ;
— si, à l'issue d'une période de temps prédéterminée, au moins une adresse de contact parmi ces adresses n'a pas répondu audit message d'interrogation ou est déclarée inactive en réponse audit message d'interrogation, une étape d'acceptation (ΕΙδΟ,ΕΙδΟ de la requête du dispositif ; et
— une étape de rejet (E140, E140 de la requête sinon.
2. Procédé de gestion selon la revendication 1 caractérisé en ce que, au cours de l'étape d'acceptation (E150), l'adresse de contact courante (AoCA) du dispositif (A) est enregistrée (E160) sur le cœur de réseau en association avec l'identifiant public (IMPU1) en remplacement d'une adresse de contact (AoCB') n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse audit message d'interrogation.
3. Procédé de gestion selon la revendication 2 caractérisé en ce que, lorsque plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation, l'adresse de contact courante du dispositif est enregistrée en remplacement de l'adresse de contact qui correspond à la durée d'expiration d'enregistrement la plus faible parmi lesdites plusieurs adresses de contact.
4. Procédé de gestion selon la revendication 2 caractérisé en ce que, lorsque plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation, l'adresse de contact courante du dispositif est enregistrée en remplacement de l'adresse de contact qui est associée à une priorité la plus faible parmi lesdites plusieurs adresses de contact.
5. Procédé de gestion selon la revendication 4 caractérisé en ce que la priorité de l'adresse de contact est déterminée par le champ q défini dans le document IETF RFC3261.
6. Procédé de gestion selon la revendication 1 caractérisé en ce qu'il comprend en outre une étape de vérification (E145 , avant d'accepter ladite requête (E150'), qu'au moins une adresse qui n'a pas répondu au message d'interrogation ou qui a été déclarée inactive en réponse au message d'interrogation correspond à la durée d'expiration d'enregistrement la plus faible parmi les adresses de contact enregistrées auprès du cœur de réseau en association avec l'identifiant public, ladite requête étant rejetée (E140 dans le cas contraire.
7. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comprend en outre, si plusieurs adresses de contact n'ont pas répondu au message d'interrogation ou ont été déclarées inactives en réponse au message d'interrogation à l'issue de ladite période de temps prédéterminée, une étape de désenregistrement (E160) de ces adresses dans le cœur de réseau.
8. Procédé de gestion selon la revendication 1, caractérisé en ce que ledit message d'interrogation est réémis plusieurs fois durant ladite période de temps prédéterminée vers au moins une desdites adresses de contact.
9. Procédé de gestion selon la revendication 1, caractérisé en ce que, lorsque ledit cœur de réseau de voix sur IP (CN) met en œuvre le protocole SIP, ledit message d'interrogation est un message SIP OPTIONS.
10. Procédé de gestion selon la revendication 1, caractérisé en ce que ledit dispositif (A) est en outre associé à un identifiant privé (IMPIA), et ledit procédé de gestion est mis en œuvre en considérant les adresses de contact enregistrées sur le cœur de réseau en association avec le couple formé par l'identifiant public et l'identifiant privé associés au dispositif (A).
11. Procédé de gestion selon la revendication 1, caractérisé en ce que le message d'interrogation est également envoyé aux adresses de contact enregistrées sur le cœur de réseau en association avec l'identifiant public du dispositif lorsque la capacité maximale n'est pas atteinte.
12. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté par un ordinateur.
13. Serveur de gestion (2) d'une requête émise par un dispositif (A) associé à un identifiant public (IMPU1) en vue d'un enregistrement sur un cœur de réseau de voix sur IP (CN), d'une adresse de contact courante (AoCA) dudit dispositif pour ce cœur de réseau, ledit serveur de gestion comprenant :
— des moyens, activés sur réception de ladite requête, pour obtenir un nombre d'adresses de contact (Nb-AoC) enregistrées sur le cœur de réseau en association avec ledit identifiant public ; et
— des moyens de comparaison de ce nombre avec une capacité maximale (Cmax) d'enregistrement définie pour cet identifiant public ;
ledit serveur de gestion étant caractérisé en ce qu'il comprend en outre des moyens, activés lorsque ledit nombre a atteint ladite capacité maximale :
— pour envoyer un message d'interrogation auxdites adresses de contact enregistrées en association avec ledit identifiant public ;
— pour accepter la requête si à l'issue d'une période de temps prédéterminée, au moins une adresse de contact parmi ces adresses de contact n'a pas répondu au message d'interrogationou est déclarée inactive en réponse audit message d'interrogation ; et
— pour rejeter la requête sinon.
14. Serveur de gestion (2) selon la revendication 13 caractérisé en ce que les moyens pour accepter la requête sont aptes à enregistrer l'adresse de contact courante du dispositif sur le cœur de réseau en association avec l'identifiant public en remplacement d'une adresse de contact n'ayant pas répondu au message d'interrogation ou déclarée inactive en réponse audit message d'interrogation.
15. Serveur de gestion (2) selon la revendication 13 caractérisé en ce qu'il est intégré dans un serveur S-CSCF lorsque le cœur de réseau (CN) est un cœur de réseau IMS.
EP12806584.4A 2011-11-30 2012-11-28 ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP Withdrawn EP2786546A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1160957A FR2983375A1 (fr) 2011-11-30 2011-11-30 Procede et serveur de gestion d'une requete emise par un dispositif sur un coeur de reseau voip en vu d'un enregistrement d'une adresse de contact courante de ce dispositif
PCT/FR2012/052734 WO2013079865A1 (fr) 2011-11-30 2012-11-28 ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP

Publications (1)

Publication Number Publication Date
EP2786546A1 true EP2786546A1 (fr) 2014-10-08

Family

ID=47436081

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12806584.4A Withdrawn EP2786546A1 (fr) 2011-11-30 2012-11-28 ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP

Country Status (4)

Country Link
US (1) US20150085856A1 (fr)
EP (1) EP2786546A1 (fr)
FR (1) FR2983375A1 (fr)
WO (1) WO2013079865A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6307746B2 (ja) * 2014-03-18 2018-04-11 株式会社リコー 宛先管理システム、通信システム、宛先管理方法、及びプログラム
WO2015185088A1 (fr) * 2014-06-02 2015-12-10 Nokia Solutions And Networks Oy Support de restauration d'ims pour gruu temporaire
US10567593B1 (en) 2018-05-30 2020-02-18 Scott Morrison Integrated VoIP and RoIP communication network

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3576906B2 (ja) * 1999-12-21 2004-10-13 Ｎｅｃインフロンティア株式会社 インターネット網に接続可能な電話通信装置と主電話制御装置とｉｐアドレスを管理する方法
US20020097674A1 (en) * 2000-09-22 2002-07-25 Narad Networks, Inc. System and method for call admission control
US7088677B1 (en) * 2002-03-01 2006-08-08 Bellsouth Intellectual Property Corporation System and method for delay-based congestion detection and connection admission control
AU2003271739A1 (en) * 2003-05-16 2004-12-03 Telefonaktiebolaget Lm Ericsson (Publ) Call admission control in voip systems
US8339963B2 (en) * 2003-08-27 2012-12-25 Rockstar Consortium Us Lp Technique for end-to-end admission control of real-time packet flows
US7684322B2 (en) * 2004-07-01 2010-03-23 Nortel Networks Limited Flow admission control in an IP network
US7660243B2 (en) * 2004-09-28 2010-02-09 Alcatel-Lucent Usa Inc. Method for management of voice-over IP communications
US20060072522A1 (en) * 2004-09-29 2006-04-06 Praphul Chandra Call parameter selection and self-enforced admission control for optimizing voice over internet protocol performance in wireless networks
US8194640B2 (en) * 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US20070286202A1 (en) * 2006-06-08 2007-12-13 Latitude Broadband Global, Inc. Methods and Systems for Call Admission Control and Providing Quality of Service in Broadband Wireless Access Packet-Based Networks
JP4834595B2 (ja) * 2007-04-03 2011-12-14 株式会社東芝 電話システムおよびゲートウェイ装置
US8018848B2 (en) * 2008-03-26 2011-09-13 Avaya Inc. Survivable phone behavior using SIP signaling in a SIP network configuration
US9001730B2 (en) * 2008-05-23 2015-04-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for message routing in IMS and circuit switched networks
US8984067B2 (en) * 2009-10-19 2015-03-17 Verizon Patent And Licensing Inc. Session initiation protocol (SIP) signaling to keep a voice over internet protocol (VoIP) session active during a call hold
US9231785B2 (en) * 2009-12-18 2016-01-05 At&T Intellectual Property I, L.P. Method and apparatus for clearing hang calls
EP2550776B1 (fr) * 2010-03-23 2020-04-29 Orange Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP2604067A1 (fr) * 2010-08-09 2013-06-19 Nokia Siemens Networks Oy Augmentation de l'efficacité de contrôle d'admission dans un réseau
US8995259B2 (en) * 2011-07-26 2015-03-31 Telefonaktiebolaget L M Ericsson (Publ) Systems and methods for resource booking for admission control and scheduling using DRX
US8988997B2 (en) * 2012-06-08 2015-03-24 Telefonaktiebolaget L M Ericsson (Publ) Communication network congestion control using allocation and retention priority

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2013079865A1 *

Also Published As

Publication number Publication date
US20150085856A1 (en) 2015-03-26
FR2983375A1 (fr) 2013-05-31
WO2013079865A1 (fr) 2013-06-06

Similar Documents

Publication Publication Date Title
EP2772035B1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
WO2013079865A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
EP2856732B1 (fr) Procédé et entité de traitement d'un message
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP3646554B1 (fr) Procédé de traitement d'une requête et serveur d'un coeur de réseau ip multimédia
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
WO2017203118A1 (fr) Procédé de repli dans un réseau de télécommunication
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP2859704B1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
EP2458813B1 (fr) Procédé de détection d'une situation de nomadisme d'un terminal SIP et terminal mettant en oeuvre ce procédé
WO2007077349A2 (fr) Procede, appareils et programme d'ordinateur de gestion de flux entre equipements fonctionnant selon le protocole sip sur un reseau de telecommunications
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP3632078B1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
WO2014114871A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
EP2429145B1 (fr) Procédé de présentation d'appel dans un réseau IMS et serveur d'application apte à mettre en oeuvre ce procédé
WO2012072920A1 (fr) Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims
FR3009468A1 (fr) Technique de mise en relation de deux entites clientes
WO2011151572A1 (fr) Procede et dispositif de presentation d'un appel entrant dans un reseau ims
FR2991540A1 (fr) Procede et dispositif de selection d'une entite communicante pour recevoir une signalisation d'un appel entrant
WO2009030869A2 (fr) Procede et dispositif pour gerer le desenregistrement d'un terminal aupres d'une entite dans un reseau de telecommunications
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
FR2905816A1 (fr) Procede et serveur de notification d'un appel dans un reseau
WO2012117178A1 (fr) Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140620

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20150702

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20151113