Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/45—Network directories; Name-to-address mapping
  • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/45—Network directories; Name-to-address mapping
  • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
  • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/45—Network directories; Name-to-address mapping
  • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
  • H04L61/4523—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using lightweight directory access protocol [LDAP]

Definitions

• the present invention relates to a system for consulting and / or updating DNS servers (Domain Name System) and / or LDAP directories (Lightweight Directory Access Protocol) from a terminal.
• DNS servers Domain Name System
• LDAP directories Lightweight Directory Access Protocol
• the present invention allows in particular a subscriber, from any terminal, to consult and update a record of telecommunications resources stored in a DNS or LDAP server.
• DNS and LDAP servers are used in the IT world to name machines (for example: association of a web URL with an IP address corresponding to the web server hosting this website). These servers are
• RESOLVER software commonly called RESOLVER, available in most computer terminals or servers.
• This software makes it possible to extract information from a DNS server in response to a client's request. This information may be available directly from the first DNS server consulted or from a server
• DNS 15 DNS referenced by the first, and so on if necessary by successive indirections.
• the contents of the DNS servers are updated by specialists "administrator” and infrequently (updating flat files on UNIX platform or dedicated application via HMI on Windows server platforms).
• the format of the contents of the servers and of the requests is defined in a protocol, known as the DNS protocol described in documents RFC 1034 and RFC 1035, available on the IETF website (www.ietf.org).
• DNS servers are now called upon to play a role within the framework of the ENUM service aimed at offering subscribers generalized portability of telephone numbers.
• This ENUM service uses the international telephone numbering system defined by the ITU under recommendation E.164. More specifically, the ENUM service allows any subscriber with a unique E.164 telephone number (telephone number +33296053859) to be reached by various means according to their preferences configured in a profile hosted in the network by a DNS server.
• the E.164 unique telephone number of the ENUM subscriber can be associated with a mobile telephone number (+33686166924), a fixed telephone number (+33296916404), an eMail address (bertrand.dupont @ rd.francetelecom.com. to a website URL fhttp: //www.bertrand.dupont.corri), to a VoIP phone number (sip: bertrand.dupont@sip.francetelecom.com) , etc.
• a root DNS server (E164.ARPA).
• Each country then has a unique telephone code (33 for France) and a DNS server is managed at level 1 by each country (3.3.E164.ARPA for France).
• Telecommunications operators or ENUM service providers finally manage DNS servers (indicated in Fig. 1 by DNS 1 to DNS 6) according to the telephone resources (range of E.164 telephone numbers) allocated to them.
• the selected model is a slicing: 5 slices of PSTN fixed telephone numbers with prefixes ranging from 1 to 5 and a slice of mobile telephone numbers identified by the prefix 6.
• Has a telephone number in E.164 format is associated with a path in the tree of DNS servers.
• each telephone number in international E.164 format is reversed, the code "+” is deleted, a point is added between each digit and the result obtained is attached to the el64.arpa domain so as to transform the telephone number into a unique Internet domain name.
• the telephone number +33686166924 gives after transformation, the Internet domain name 4.2.9.6.6.1.6.8.6.3.3.el64.arpa.
• each telephone number in E.164 format is associated with a record comprising one or more resource records (Resource Record or RR), stored in the corresponding level 2 server, each resource record being able to include one or more several fields.
• resource records Resource Record or RR
• an E.164 format telephone number can be associated with resource records
• NAPTR Noise Authority PoinTeR
• a NAPTR resource record indicates a telecommunications service (telephone number, fax, e-mail address, website, etc.) associated with a priority level.
• ENUM record or ENUM profile
• NAPTR associated with an Internet domain name. For example, if the following ENUM profile is stored in a Level 2 DNS server:
• the header line indicates an Internet domain name corresponding to the E.164 telephone number.
• the RESOLVER software allows you to access the registration from the domain name.
• Each NAPTR record in the above example corresponds to a telecommunication resource or service.
• Two numeric fields follow the term "NAPTR", these are respectively the service priorities: "Order” and "Preference". The lower the value of the "Order” field, the more priority the service and if several services have the same order level, the lower the associated Preference value, the higher the service.
• the lines of the above record correspond to decreasing priorities.
• the RESOLVER software transmits a request to the level 2 DNS server with the corresponding Internet domain name (9.5.8.3.5.0.6.9.2.3.3. el64.arpa).
• the DNS server level 2 (DNS2) will provide in the response the list of telecommunication resources (also called services below) associated with the telephone number +33296053859, as given by the registration.
• the RESOLVER software and the ENUM service can then exploit all or part of these resources in sequential mode (the system will try to reach the highest priority service then, in the absence of a response or in the event of busy, the system will try to reach the service of lower priority, etc.) or in broadcast mode (the ENUM service will then attempt to reach all of the services simultaneously).
• the modification of the ENUM profiles in a DNS server is ill-suited to the update process by administrator as known from the state of the art. Indeed, unlike Internet domain names, traditional telecommunications services such as the telephone or fax are subject to frequent modification. In addition, it is sometimes necessary to schedule these changes automatically on a daily or even hourly basis. It is therefore extremely difficult for reasons of availability and flexibility to have your own telecommunications operator or ENUM service provider support the configuration change of an ENUM profile.
• a particular problem underlying the invention is to allow a subscriber to consult and / or modify quickly and easily his ENUM profile stored in a DNS server or an LDAP directory. More generally, the problem underlying the invention is to allow a simple and rapid consultation and / or modification of one or more resource record (s) stored in a DNS or LDAP server and this , from any conventional terminal.
• the problem underlying the invention is solved by a system for consulting and / or updating a record stored in a first database, said record comprising one or a plurality of resource records, said first database being hosted by a domain name server, called DNS server, or a directory server, said LDAP server, which can be accessed by indirection from a DNS server, said system comprising:
• communication means enabling said system to receive from a telecommunication terminal a request for consultation and / or modification of said recording or a programming of such a request;
• control means adapted to determine from said request for consultation and / or modification transmitted to said system or previously programmed in said system, a domain name and an operation to be performed on said recording;
• - protocol management means adapted to search from said domain name, the IP address of said server hosting said first database and, depending on said operation, to transmit to said server a request for reading or updating day of said recording.
• said system comprises authentication means adapted to authenticate at the application level the sender of said request from authentication information stored in a second local or remote database.
• said protocol management means make it possible to transmit a consultation request according to the DNS protocol (DNS Query) to said DNS server, the request having as argument said domain name, and to receive a first response from said server.
• the control means are adapted to determine said domain name from a subscriber identifier which may be the E.164 telephone number of said subscriber.
• the control means are then adapted to extract information and to determine, as a function of said request, an operation to be performed on a resource record of NAPTR type.
• control means are adapted to extract information and to determine according to said request an operation to be performed on one or more resource records of type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO, MX, TXT.
• FIG. . 1 schematically illustrates the delegation model used in the ENUM service
• Fig. 2 A schematically illustrates an example of the environment of the system according to the invention
• Fig. 2B schematically illustrates the environment of FIG. 2A in the context of the ENUM service
• Fig. 3A shows the block diagram of the updated consultation system according to the invention
• Fig. 3B shows an example of a consultation / update system according to the invention
• Fig. 4 schematically shows a manual consultation and update procedure for an ENUM profile with access in voice mode
• Fig. . 1 schematically illustrates the delegation model used in the ENUM service
• Fig. 2 A schematically illustrates an example of the environment of the system according to the invention
• Fig. 2B schematically illustrates the environment of FIG. 2A in the context of the ENUM service
• Fig. 3A shows the block diagram of the updated consultation system according to the invention
• Fig. 3B shows an example of a consultation / update system according to the invention
• Fig. 4 schematic
• FIG. 5 schematically shows a manual consultation and update procedure for an ENUM profile by sending SMS messages
• Fig. 6 schematically represents a procedure for consulting and manually updating an ENUM profile via the Web
• Fig. 7 schematically represents a procedure for consultation and manual updating of an ENUM profile from a Minitel
• Fig. 8 schematically represents a procedure for consultation and manual updating of an ENUM profile by eMail
• Fig. 9 schematically shows a manual consultation and update procedure of an ENUM profile by IUU from an ISDN terminal
• Fig. 10 schematically represents an ENUM profile automatic setting programming procedure
• Fig. 11 schematically shows an automatic update procedure for the ENUM profile
• Fig. 12 schematically represents a profile consultation procedure
• FIG. 13 schematically shows a procedure for updating the ENUM profile when the latter is stored in an LDAP directory.
• FIG. 2A illustrates an example of the system environment according to the invention.
• Telecommunication resource management service providers hereinafter called service providers, have been schematically represented in 30 I , ..., 30 N -
• Each service provider has a DNS (3L) or LDAP server ( 34j) hosting a database and more generally of several redundant servers so as to increase the reliability of access to the service.
• the database contains a record of telecommunications resources for all subscribers of the service provider in question.
• the system (50) according to the invention can be connected on the one hand to the public telephone network via a standard interface of analog or digital type T0 or T2 and, on the other hand, to the IP network via a standard interface of Ethernet type.
• the system (50) is connected to the Internet if the present invention is accessible to any subscriber, regardless of its service provider, and can be connected to an intranet if the present invention is accessible to subscribers only. a service provider.
• the system (50) can be accessed by an ISDN telephone terminal (2) connected either directly or through a PABX (3) to the ISDN network (10).
• the ISDN network is natively interconnected to the PSTN network.
• the system (50) can also be accessed by a conventional telephone terminal (4) or a Minitel terminal (5) connected to the PSTN network (11).
• the system (50) can also be accessed by a GSM mobile terminal (6) or even a UMTS terminal not shown (the GSM and UTRAN networks are natively interconnected to the PSTN network).
• the system (50) can be accessed by means of an IP telephone terminal (7) connected to the IP network (13).
• the system (50) can finally be accessed by means of a microcomputer (8) connected to the IP network either through an Ethernet interface (local business network) or by modem (PSTN / ISDN / ADSL / cable / satellite etc.)
• the subscriber can also receive notifications from the system (50) using one of the terminals envisaged above or even using a fax terminal (9).
• FIG. 2B illustrates an example of the environment of the system according to the invention, in the context of an ENUM service.
• the elements bearing the same reference numbers are identical to those in FIG. 2A.
• the ENUM DNS server level 0 root
• This server has all the IP addresses referencing all the ENUM DNS servers of level 1, corresponding to the codes of the different countries (33 for France, 34 for Spain, 44 for England, etc.).
• the ENUM DNS server level 1 corresponding to France has been included in 41.
• Each operator or ENUM service provider has at least a first level 2 ENUM DNS server (31;), called primary server, redundant by at least a second level 2 ENUM DNS server (31 'j), said secondary server in order to ensure good service reliability.
• the primary server (resp.
• each level 2 server there is stored, for each E.164 telephone number of a subscriber to the ENUM service, a profile composed of the different telecommunication resources of the subscriber, each resource corresponding to an access means (e.g. office desk phone, home desk phone, mobile phone, IP phone, office email address, mobile email address, professional fax number, etc.) as well as the priorities relating to each of these means of access.
• Each telecommunication resource is declared by means of a NAPTR resource record as seen above. The priority of a resource is determined by the content of the Order and Preference fields of the NAPTR resource record, as defined in document RFC 2915 of 1TETF and exemplified in the introductory part.
• An ENUM service provider A (30d) can also have an LDAP server (34d) hosting a dynamic LDAP directory (360 te l Q ue defined in document RFC 1959 of 1TETF.
• the advantage of this configuration is to allow manage ENUM profiles by indirection no longer in ENUM level 2 DNS but in the LDAP dynamic directory.
• the advantage provided consists in no longer modifying the profile of the ENUM client at the level of the ENUM level 2 DNS server but directly in the LDAP directory, which is designed to store dynamic profiles.
• the DNS ENUM level 2 (31,) contains for example the following profile for all the E.164 telephone numbers starting with the prefix "+332":
• the LDAP directory (36,) is accessed by indirection from the level 2 ENUM DNS server and contains the resource records for the various subscribers of supplier A.
• An ENUM server or gateway (80) can consult an ENUM service provider (30,) for the list of telecommunications resources of an ENUM subscriber. To do this, the RESOLVER software transforms the subscriber's unique E.164 number into a domain name as we saw above and accesses successively the ENUM level 2 DNS server (31,) and, if necessary , after additional indirection to the LDAP server (34,). The service provider returns the list of resources for the subscriber in question with the associated priorities. The ENUM server or gateway (80) can then, as the case may be, attempt to reach the subscriber by successively using the resources, in decreasing order of priority, or join the subscriber using all of its resources.
• Fig. 3A shows the block diagram of the updating system (50) according to the invention.
• the system comprises communication means (1,150) allowing a subscriber to dialogue with said system and in particular: to transmit to the subscriber an authentication request; to receive from said subscriber information allowing his authentication; to receive from said subscriber a request to modify a recording (known as a manual request) or a request for automatic modification (known as a scheduled request) according to a temporal or geographical criterion; - to transmit the content of a recording before or after the request for modification; to transmit to said subscriber a notification of confirmation of update when the requested modification has been made and of cancellation of update when the latter could not be made; - to transmit to said subscriber, at the end of consultation or revision, an automatic modification request previously registered in said system; to transmit to said subscriber a history of the modifications made.
• communication means (1,150) allowing a subscriber to dialogue with said system and in particular: to transmit to the subscriber an authentication request; to receive from said subscriber information allowing his authentication; to receive from said subscriber a request to modify a recording (known as a manual request
• the system also includes interface means (1160) for connecting said communication means to the PSTN / ISDN network and or to an IP network (Internet or Intranet).
• interface means (1160) for connecting said communication means to the PSTN / ISDN network and or to an IP network (Internet or Intranet).
• the system also includes authentication means (1173) cooperating with the communication means to authenticate at the application level a transmitter of request for consultation and / or update. Authentication at the application level has the advantage of allowing a subscriber to operate from any terminal.
• the authentication means use for this purpose authentication information stored in a local or remote database (1170).
• the database (1170) may in particular contain automatic modification programs relating to different subscribers, the IP addresses of the servers of the various telecommunications resource management providers, the history of manual or automatic modification of the records, the addresses to which update confirmation / invalidation notifications must be sent.
• the system (50) further comprises protocol management means (1162) ensuring inter alia the RESOLVER function.
• the protocol management means are adapted to seek, where appropriate by successive indirections, the content of a resource record (RR) using a domain name.
• the protocol management means can transmit consultation requests for this purpose according to the DNS protocol (DNS Query).
• the protocol management means can update resource records based on update requests (DNS Update).
• DNS Update if resource records are stored in an LDAP directory, the protocol management means will also allow the consultation of a record in an LDAP directory (transmission of an LDAP Search request) as well as the updating day of this registration (issuance of a Modify LDAP request).
• the protocol means receive an acknowledgment from the server of the telecommunications resource management supplier.
• the 1175 control means coordinate the aforementioned means and in particular:
• the means of communication to transmit a request for authentication; after authentication of the subscriber by the authentication means (1173) ask the protocol means (1162) to transmit a request for consultation, format the response and retransmit it in intelligible form to the subscriber via the communication means; on the basis of a request for modification of a resource record by a subscriber, determine an operation to be carried out on said record and an identifier of the subscriber upon receipt of confirmation / cancellation of update by the protocol means, notify confirmation of cancellation to the subscriber via the means of communication.
• Fig. 3B illustrates an exemplary embodiment of the invention in the context of an ENUM service.
• the elements bearing the same reference numbers are identical to those in FIG. 2A.
• the subscriber can contact the update system (50) by means of one of the terminals envisaged above.
• (30) is represented a telecommunications resource management service provider comprising a level 2 DNS server (31), said primary server, redundant by a secondary server (not shown).
• the server (31) comprises a database (33) and a DNS protocol stack (32) integrating the DNS protocols described in documents RFC 1034 and RFC 1035.
• the protocol stack also integrates the DNS protocols described in documents RFC 2136 and RFC 2137 intended to allow updating (DNS Update) of a resource record (RR).
• the resource management service provider also includes an LDAP directory server (34) hosting a database (36).
• the LDAP directory server has an LDAP protocol stack (35).
• the system communication means (50) consist of the following modules: o a module responsible for processing incoming and outgoing telephone calls (52). This module manages the establishment and release of communication; a module (53) for User-to-User Information management (IUU) making it possible to extract and transmit IUU information; o a module (54) for processing DTMF codes.
• This module is in charge of recovering the DTMFs entered by the subscriber; o a voice synthesis module (55); o a module (56) for broadcasting pre-recorded and concatenated voice files to form sentences; o a videotex server (57); o an SMS reception and sending module (58); o a fax sending module (59); o an SMTP server (61) for sending and receiving eMail; o a dynamic Web server (63).
• system may also include a voice recognition module (not shown) adapted to recognize information spoken by the subscriber.
• the communication means are connected to the outside by means of a PSTN and / or ISDN interface (51) and an IP interface (60).
• the first is based on either a card analog multi-port PSTN either on an ISDN TO card (2 channels) or T2 (30 channels).
• the second is an Ethernet interface.
• the gateway indicated by (14) recalls that the PSTN / ISDN and IP networks are natively interconnected in VOIP protocol (H323 / SIP).
• the system (50) comprises, as before, authentication means (73) authorizing the application authentication of the service subscribers from authentication information, for example pairs of pseudonyms (Login_Id) and passwords stored in a local or remote database (70).
• the database includes the identifiers of the various ENUM service providers (such as 30), the IP addresses or the machine names of third-party DNS 2, requests for automatic modification of the ENUM profile, the history of manual modification or of ENUM profiles, the addresses for notification of modification of the ENUM profile (fax, SMS, eMail number).
• ENUM service providers such as 30
• IP addresses or the machine names of third-party DNS 2 requests for automatic modification of the ENUM profile
• the history of manual modification or of ENUM profiles the addresses for notification of modification of the ENUM profile (fax, SMS, eMail number).
• the system also includes a DNS protocol management module (62), preferably in its secure form (DNSSec). This module plays in particular the role of RESOLVER for reading resource records.
• DNS protocol management module preferably in its secure form (DNSSec). This module plays in particular the role of RESOLVER for reading resource records.
• an LDAP protocol management module (64) is added to it to allow the reading and modification of records in an LDAP directory.
• the system also includes a module (72) allowing the configuration of the addresses of the level 2 DNS servers as well as a module (71) responsible for keeping the manual or automatic modifications of the ENUM profiles up to date and for developing, if necessary, statistics for the system operator.
• the control means consist, on the one hand, of a module (74) responsible for the automatic configuration of ENUM profiles from automatic modification requests programmed by subscribers and stored in the database (70) and, on the other hand, a module (75) responsible for the "manual" configuration of the ENUM profiles.
• the latter manages ENUM scripts, in particular an ENUM profile reading script (it is recalled that an ENUM profile consists of a list of NAPTR resource records), scripts for modifying the fields of NAPTR resource records and in particular order, preference, service fields (eMail address, telephone number, eMail address, etc.). If you wish to schedule the consultation and / or updating DNS resource records other than NAPTR, additional scripts must be provided for their modification.
• Fig. 4 schematically illustrates a procedure for consultation and manual modification of an ENUM profile in voice mode via a fixed or mobile telephone of PSTN, ISDN, GSM or IP type.
• the ENUM subscriber makes in step 100 a free telephone call (toll-free number type) or a paid call according to a geographical or fixed rate payment type of audiotel type or colored numbers from a fixed PSTN (4) or ISDN (2) terminal connected to the public network or behind a PABX (3) or a mobile terminal (6) of GSM type, or from an IP terminal (7) intended for the PSTN / ISDN interface (51) of the system (50).
• the call processing automaton (52) automatically accepts the incoming call in step 101.
• the ENUM script module (75) gives in step 102 the order to the text-to-speech module (55) or to the module broadcasting voice files (56) broadcasting in step 103 to the ENUM subscriber a voice announcement inviting the ENUM subscriber to enter his ENUM E.164 number as well as his pseudonym and his password.
• the ENUM subscriber enters in step 104 via his keyboard this information which is conveyed in the band in the form of DTMF and which is intercepted by the DTMF processing module (54).
• This information is supplied in step 105 to the authentication module (73) which queries the local or remote database (for example via an interface of ODBC type (for Open DataBase Connectivity)) by performing a search on the ENUM number E.164.
• step 107 the authentication information corresponding to the authentication module (73).
• the latter compares the pseudonym and password entered by the ENUM client with the authentication information contained in the database (70).
• the authentication module (73) orders in step 108 the voice synthesis module (55) or the voice file broadcasting module to broadcast in step 109 to the ENUM subscriber an announcement of the type "To consult your ENUM profile, press the key 1, to modify the attributes of your profile, press 2, to configure your profile automatically, press 3, to modify your pseudonym and password, press 4, to access your profile modification log type 5, etc.
• the ENUM subscriber presses the key 1 on his telephone keypad in step 110 the corresponding DTMF code is intercepted by the DTMF processing module (54) and is retransmitted in step 111 to the script module ENUM (75).
• the ENUM script (75) detects that it is a command to read the ENUM profile.
• the ENUM script (75) then sends in step 112 a request for interrogation to the DNS protocol module (62) by supplying as argument the E.164 address of the ENUM subscriber put in the form of a domain (transformation of E.164 telephone type 33296053859 in (9.5.8.3.5.0.6.9.2.3.3.el64.ar ⁇ a)
• the DNS protocol management module (62) which plays the classic role of a RESOLVER can first check if the information is not present in its cache following a previous consultation or interrogate (in step 113) according to the standard DNS protocol (DNS Query request) successively the level 0 DNS server, the level 1 DNS server, then the level 2 DNS server via the DNS protocol stack (32).
• the data of a NAPTR record are loaded into the RAM of the DNS server (31). If the ENUM subscriber is actually registered in the DNS server (31) of the ENUM service provider (30) then the DNS protocol stack (32) returns (at step 114) to the DNS protocol module (62) the list of corresponding NAPTR records. The DNS protocol module (62) is then responsible for retransmitting them to the Script ENUM module (75) in step 115.
• the module (75) analyzes and interprets the NAPTR records and generates a text understandable by the ENUM subscriber of the type "Service N ° 1: phone to 0296053859, service N ° 2: phone to 0686166924, service N ° 3: e-mail to bertrand.
• This text is sent to the module voice synthesis (55) in step 116 which is responsible for broadcasting this information to the ENUM subscriber in step 117.
• the module (75 ) generates the sequence of voice files to be played.
• the voice synthesis module (55) or the voice file broadcast module (56) again broadcasts in step 118 the list of operations of administration possible on the ENUM profile "To consult your ENUM profile tap on the che 1, to modify the attributes of your profile tap on 2, to configure your profile automatically tap on 3, to modify your pseudonym-password, tap on 4, to access your log for modifying your profile tap on 5, etc.).
• the ENUM script module (75) If the ENUM subscriber chooses to modify their ENUM profile in step 150, this command is intercepted by the ENUM script module (75) in step 151, following the detection of the DTMF code by the DTMF processing module ( 54).
• the system (50) then enters an iterative dialogue based on the broadcast of voice messages to the ENUM subscriber from a text generated by the ENUM script module (75) (in step 152) according to the context and broadcast (at step 153) in voice form by the voice synthesis module (55) or by the concatenated voice file broadcasting module (56).
• the latter validates the choices proposed using his DTMF keyboard in step 154 and the commands are transmitted in step 155 to the ENUM script (75).
• the voice dialogue can be as follows:
• the ENUM script module (75) sends a request for modification request in step 156 to the DNS protocol module (62).
• the latter issues a DNS UPDATE command in step 157 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). It is recalled that the latter's IP address is stored in the database (70) and that it is found from the E.164 number of the ENUM subscriber.
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the modification number in this file so that the secondary DNS (s) can (themselves) reload this modification (s) themselves at predefined time intervals.
• the database (33) confirms the update at step 159, which results in a response to the request for request from step 160.
• the ENUM script (75) intercepts in step 161 the return code of this response and then generates in step 162 the message confirmation / cancellation of taking into account the modification.
• the voice synthesis module (55) or the voice file broadcasting module broadcasts this information to the ENUM subscriber in step 163. The latter can then release the call.
• the subscriber in response to voice messages, can directly provide a response by voice. It is then the voice recognition module which determines the choice or the information contained in the response.
• Fig. 5 schematically illustrates the procedure for manual consultation and modification of an ENUM profile via the sending of SMS from mobile or fixed telephone terminals of the GSM, PSTN, ISDN or IP type.
• the ENUM subscriber sends in step 200 a formatted SMS (ex: N ⁇ .164 + pseudonym + password + request) as specified by the ENUM service provider (30) from a fixed PSTN (4) or ISDN terminal ( 2) connected to the public network or behind the PABX (3) or a mobile terminal (6) of GSM type, or from an IP terminal (7), intended for the SMS module (58) of the present invention.
• the latter transmits the SMS in step 201 to the ENUM script module (75).
• This information is supplied in step 202 to the authentication module (73) which interrogates in step 203 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number. .
• This provides at step 204 the information corresponding to the authentication module (73) which is responsible for comparing the pseudonym and the password entered by the ENUM client in the SMS with the authentication information contained in the database. of data.
• the authentication module (73) instructs step 205 of the ENUM script module (75) to process the request contained in the SMS.
• the ENUM script (75) detects that it is a command to read the ENUM profile.
• the ENUM script (75) emits a request for interrogation in step 206 to the DNS protocol management module (62) by supplying as argument the E.164 address of the ENUM subscriber transformed into a domain ( transformation of the E.164 telephone number of type 33296053859 into (9.5.8.3.5.0.6.9.2.3.3.el64.arpa)
• the protocol management module DNS (62) which plays the classic role of a RESOLVER interrogates (step 207) using a query (DNS Query) the DNS server level 0, then the DNS server level 1, unless the information are not already in its cache following a previous consultation of these servers. To gain efficiency, the data from a DNS server are loaded into the RAM of the server (31).
• the DNS protocol module (32) returns to step 208 the corresponding NAPTR records.
• the DNS protocol management module (62) is then responsible for retransmitting them to the ENUM script module (75) in step 209.
• the latter analyzes and interprets the NAPTR records and generates a relatively synthetic text which can be understood by the subscriber.
• This text is sent to l step 210 to the SMS sending module (58) which sends the SMS (in step 211) to the telephone terminal at the origin of the request (use of the caller's number).
• the latter transmits the SMS message in step 251 to the ENUM script module (75).
• This information is supplied in step 252 to the authentication module (73) which interrogates in step 253 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number .
• This provides at step 254 the information corresponding to the authentication module (73) which is responsible for comparing the pseudonym and the password entered by the client ENUM in the SMS message with the authentication information contained in the database. If there is a match, the authentication module (73) notifies the ENUM script module (75) which then processes the request contained in the SMS.
• the ENUM script (75) detects that it is a command to update the ENUM profile with arguments.
• the ENUM (75) script checks the syntax of the command and, if it is correct, issues an update request in step 256 to the management module.
• DNS protocol (62) issues a DNS UPDATE command in step 257 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). It is recalled that the latter's IP address is stored in the database (70) and that it is found from the E.164 number of the ENUM subscriber.
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the modification number in this file so that the secondary DNS server (s) can (s) reload this modification themselves at predefined time intervals.
• the server (31) confirms the update in step 259, which results in a response to the request for update request in step 260.
• the ENUM script (75) intercepts in step 261 the return code of this response then generates in step 262 the confirmation / invalidation message for taking the modification into account before sending it to the SMS sending module (58) which is responsible for sending the SMS to step 263 to the telephone terminal at the origin of the request (use of the caller's number).
• Fig. 6 schematically illustrates the procedure for manual consultation and modification of an ENUM profile by the web from a terminal having a web browser (8).
• the ENUM subscriber requests in step 300 the download of the home page of the ENUM profile management service. This is returned to step 301 by the web server (63) of the present invention.
• This web page displays an authentication form for the ENUM subscriber. They enter their E.164 number, then their pseudonym and password.
• This information is transmitted in step 302 to the web server (63) which itself transmits it in step 303 to the authentication module (73).
• the authentication module (73) interrogates in step 304 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number. This provides in step 305 the information corresponding to the authentication module (73) which is responsible for comparing the pseudonym and the password entered by the client ENUM in the web form and the authentication information contained in the database.
• the authentication module (73) notifies in step 306 the web server module (63) that the authentication has been successful. This transmits in step 307, to destination of the ENUM script module (75), a request to read the ENUM profile. Consequently, the ENUM script (75) emits an interrogation request in step 308 to the DNS protocol module (62) by supplying as argument the E.164 address of the ENUM subscriber transformed into a domain (transformation of the E.164 telephone number, type 33296053859 in 9.5.8.3.5.0.6.9.2.3.3.el64.arpa).
• the DNS protocol module (62) which plays the classic role of a RESOLVER interrogates (at step 309) after having checked if the information is not present in its cache following a previous consultation, using the standard protocol DNS (DNS Query query) successively the level 0 DNS server, the level 1 DNS server, then the level 2 DNS server.
• DNS DNS Query query
• the data from a DNS is loaded into the RAM of the DNS server (31).
• the DNS protocol module (32) returns to step 310 the NAPTR records corresponding to the DNS protocol module (62). The latter retransmits them to the ENUM script module (75) in step 311 which interprets the NAPTR records and generates a relatively synthetic text which the ENUM subscriber can understand:
• Priority 1 service Tel 0296053859
• Priority 2 service Tel 0686166924
• This text is sent in step 312 to the web server module (63) which downloads a web page provided with this information in step 313 to the web terminal (8) of the ENUM subscriber.
• the web page presented to the ENUM subscriber allows changes to the current ENUM profile via a suitable graphical interface: modification of priorities, addition of service, deletion of service, modification of attributes of a service, etc.
• the modification request is sent in step 350 to the web server (63).
• the latter transmits at step 351 the request to the ENUM script module (75) which is responsible for formatting the request in accordance with the NAPTR inputs described by the ENUM protocol.
• the ENUM script (75) then issues a request for updated in step 352 to the DNS protocol module (62).
• the latter issues a DNS UPDATE command in step 353 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30).
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the modification number in this file so that the secondary DNS server (s) can (s) reload this modification themselves at predefined time intervals.
• the database (33) confirms the update in step 355, which results in a response to the update request request in step 356.
• the ENUM script (75) intercepts at step 357 the return code of this response then generates in step 358 the confirmation / invalidation message for taking the modification into account before sending it to the web server (63) which is responsible for formatting the result web page before to download it in step 359 to the web terminal (8).
• Fig. 7 schematically illustrates the procedure for consultation and manual modification of an ENUM profile from a Minitel.
• the ENUM subscriber connects to the Minitel service using the PAVI function
• the minitel terminal (5) then enters into session with the minitel server (57) in step 400.
• the latter activates in step 401 the ENUM script module (75) of the present invention which then generates the home page of the service in step 402 and which is downloaded in step 403 to the Minitel terminal (5) of the ENUM subscriber.
• This Minitel page displays an authentication form for the ENUM subscriber. They enter their ENUM E.164 number, then their pseudonym and password.
• This information is transmitted in step 404 to the Minitel server (57) which itself transmits it in step 405 to the ENUM script module (75). The latter redirects the request in step 406 to the authentication module (73).
• the authentication module (73) interrogates in step 407 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number.
• the authentication information of the database is transmitted to the authentication module (73) which compares it with the entered pseudonym and password in the Minitel form. In the event of a match, the authentication module (73) notifies in step 409 the ENUM script module (75) that the authentication has been successful.
• the ENUM script module (75) then sends an interrogation request in step 410 to the DNS protocol module (62) by supplying as argument the E.164 address of the ENUM subscriber transformed in the form of a domain (transformation of the number E.164 type 33296053859 in 9.5.8.3.5.0.6.9.2.3.3.el64.arpa).
• the DNS protocol module (62) which plays the classic role of a RESOLVER interrogates (step 411), after having checked whether the information is not present in its cache following a previous consultation, using the standard DNS protocol ( DNS Query) successively the level 0 DNS server, the level 1 DNS server, then the level 2 DNS server.
• the data from a DNS is loaded into the server's RAM DNS (31).
• the DNS protocol module (32) returns (at step 412) the corresponding NAPTR records.
• the DNS protocol module (62) is responsible for retransmitting them to the ENUM script module (75) in step 413. The latter analyzes and interprets the NAPTR records and generates a relatively synthetic text which can be understood by the ENUM subscriber of the type :
• This text is sent in step 414 to the videotex server module (57) which downloads in step 415 to the Minitel terminal (5) of the ENUM subscriber.
• the videotex page presented to the ENUM subscriber allows, via a suitable interface, to make modifications to the current ENUM profile: modification of priorities, addition of service, deletion of service, modification of attributes of a service, etc.
• the ENUM profile update request is sent in step 450 to the videotex server (57).
• the latter transmits in step 451 the request to the ENUM script module (75) which is responsible for formatting the request in accordance with the NAPTR inputs described by the ENUM protocol.
• the ENUM (75) script then issues a update request in step 452 to the DNS protocol module (62).
• the latter issues a DNS UPDATE command in step 453 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30).
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the change number in this file so that the secondary DNS server (s) can reload this change themselves at predefined time intervals.
• the database (33) confirms the update in step 455, which results in a response to the update request request in step 456.
• the ENUM script (75) intercepts at step 457 the return code of this response and then generates in step 458 the confirmation / invalidation message for taking the modification into account before sending it to the videotex server (57) which is responsible for formatting the result videotex page before download it in step 459 to the Minitel terminal (5).
• Fig. 8 schematically illustrates the procedure for consultation and manual modification of an ENUM profile by eMail from a terminal having an eMail client (8).
• the ENUM subscriber sends an eMail formatted in step 500 to the eMail server (61).
• the ENUM command is for example passed to the recipient eMail address:
• the ENUM script module (75) has an eMail client which regularly checks the eMail server (61).
• the ENUM script module (75) retrieves, either in the header or in the body of the eMail, the arguments supplied and then transmits them to the step 502 to the authentication module (73).
• the authentication module (73) interrogates in step 503 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number. This provides in step 504 the authentication information corresponding to the authentication module (73) which compares it to the pseudonym (login id) and the password (password) provided by the ENUM client in the eMail.
• the authentication module (73) notifies the ENUM script module (75) in step 505. Consequently, the ENUM script (75) sends a request for interrogation in step 506 to the module DNS protocol management (62) by supplying as argument the E.164 address of the ENUM subscriber transformed into a domain name (transformation of the E.164 telephone number of type 33296053859 into 9.5.8.3.5.0.6.9.2.3 .3.el64.arpa).
• the DNS protocol management module (62) which plays the classic role of a RESOLVER interrogates (step 507), if however the information is not already present in its cache following a previous consultation, according to the standard DNS protocol (request DNS Query) successively the level 0 DNS server, the level 1 DNS server, then the level 2 DNS server via the DNS protocol stack (32).
• the data from a DNS is loaded into the RAM of the DNS server (31).
• the DNS protocol management module (32) returns to step 508 the corresponding NAPTR records.
• the DNS protocol management module (62) is responsible for retransmitting them to the ENUM script module (75) in step 509. The latter analyzes and interprets the NAPTR records and generates a relatively synthetic text which can be understood by the ENUM subscriber. like:
• This text is sent (step 510) in the form of eMail by the eMail client software integrated in the ENUM script module to the eMail server module (61) which is responsible for sending it to the ENUM subscriber.
• the ENUM subscriber who wishes to modify his ENUM Profile sends an eMail formatted in step 550 to the eMail server (61).
• the ENUM command is for example passed to the recipient eMail address, for example: el64-33296053859-login-dupont-password-1234-requete-ecrire-Pl-tel-0296053859- P2-tel-0686166924-P3-fax-0296050242@gestion.enum.francetelecom.com
• the ENUM script module eMail client scans the eMail server (61).
• the ENUM script module receives (at 551) an eMail as indicated above, it retrieves, either in the header or in the body of the eMail, the arguments supplied and then transmits them in step 552 to the module authentication (73).
• the authentication module (73) interrogates in step 553 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number. This provides at step 554 the corresponding authentication information and the authentication module (73) compares them to the pseudonym and the password provided in the eMail. If there is a match, the authentication module (73) notifies the ENUM script module (75) in step 555.
• the latter formats the request in accordance with the NAPTR entries described by the ENUM protocol.
• the ENUM script (75) then transmits an update request in step 556 to the DNS protocol management module (62) which issues a DNS UPDATE command in step 557 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). It is recalled that the latter's IP address is stored in the database (70) and that it is found from the E.164 number of the ENUM subscriber.
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the change number in this file so that the secondary DNS server (s) can reload this change themselves at predefined time intervals.
• the database (33) confirms the update in step 559, which results in a response to the update request request in step 560.
• the ENUM script module (75) intercepts at the 'step 561 the return code of this response then generates the confirmation / invalidation message for taking the modification into account.
• This message is sent (at step 562) in the form of eMail by the client software integrated in the ENUM script module to the eMail server (61).
• the latter sends in step 563 the eMail in question to the ENUM subscriber who can consult it on his terminal (8).
• Fig. 9 schematically illustrates the procedure for manual consultation and modification of an ENUM profile by IUU (User to User Information) from an ISDN terminal (2).
• the ENUM subscriber sends in step 600 from his ISDN terminal (2) a telephone call containing the IUU information element to the ISDN interface (51).
• the IUU field is currently limited to a size of 32 characters.
• the ENUM command which is inserted in the IUU field can therefore only act on one ENUM service at a time. For example: GetPl-33296053859 * dupont # 123456: this request makes it possible to retrieve the attributes of the priority ENUM service 1.
• the call controller (52) transmits in step 601 the call establishment request message to the IUU module (53) which will extract the IUU command.
• the call controller (52) transmits in step 652 the Alert message to the ENUM subscriber so as to allow a minimum of time (timing of the ISDN protocol before sending a disconnection message).
• the IUU module (53) transmits the ENUM command in step 603 to the ENUM script module (75). The latter retrieves the ENUM arguments supplied and then transmits them in step 604 to the authentication module (73).
• the authentication module (73) interrogates in step 605 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number. This provides in step 606 the authentication information corresponding to the authentication module (73) which compares it with the pseudonym and the password supplied by the client ENUM in the IUU.
• the authentication module (73) notifies the ENUM script module (75) in step 607.
• the ENUM script module (75) sends an interrogation request in step 608 to DNS protocol management module (62) by providing as argument the E.164 address of the ENUM subscriber transformed into a domain (transformation of the E.164 telephone number of type 33296053859 into 9.5.8.3.5.0.6.9. 2.3.3.el64.arpa).
• the DNS protocol management module (62) which plays the classic role of a RESOLVER can interrogate (at step 609), after having checked whether the information is not already in its cache following a previous consultation, at the using the standard DNS protocol (DNS Query request), DNS level 0 then DNS level 1, then DNS level 2 via its DNS protocol module (32).
• DNS protocol DNS Query request
• the data from a DNS server are loaded into the RAM of the server (31).
• the DNS protocol stack (32) returns to step 610 the NAPTR records corresponding to the DNS protocol management module (62) which is responsible for retransmitting them to the ENUM script module (75) in step 611.
• the latter analyzes and interprets the NAPTR records and as a function of the service requested in the IUU command generates a relatively synthetic text that can be understood by the ENUM subscriber of the type:
• This text is sent in step 612 to the IUU module (53) which is responsible for formatting a disconnection message before sending it in step 613 to the call automaton module (52).
• the latter generates the ISDN disconnection message which contains the IUU information element and which is therefore transmitted in step 614 via the ISDN network to the terminal (2) of the ENUM subscriber.
• the latter can view the IUU on the display of its ISDN terminal (2).
• the ENUM subscriber who wishes to modify his ENUM profile sends in step 650 from his ISDN terminal (2) a telephone call containing the IUU information element to the ISDN interface (51). For example: DelP3-33296053859 * dupont # 123456: this request is used to delete the ENUM service with priority 3.
• the call controller (52) transmits in step 651 a call establishment request message to the IUU module (53) which extracts the IUU command.
• the call controller (52) transmits in step 652 the Alert message to the ENUM subscriber so as to allow a minimum of time (timing of the ISDN protocol before sending a disconnection message).
• the IUU module (53) transmits the ENUM command in step 653 to the ENUM script module (75). The latter retrieves the arguments supplied and then transmits them in step 654 to the authentication module (73).
• the authentication module (73) interrogates in step 655 the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number.
• step 656 the authentication information corresponding to the authentication module (73) which compares them to the pseudonym and the password supplied by the client ENUM in the IUU. If there is a match, the authentication module (73) notifies the ENUM script module (75) in step 657. Since the modification does not relate to the entire profile, the ENUM script (75) transmits first a request for interrogation (at step 658) to the DNS protocol management module (62) by supplying the E.164 address as an argument of the ENUM subscriber transformed into a domain (transformation of the E.164 telephone number of type 33296053859 into 9.5.8.3.5.0.6.9.2.3.3.el64.arpa).
• the DNS protocol management module (62) which plays the role of RESOLVER, can interrogate (at step 659), after having checked whether the information is not already in its cache following a previous consultation, at the using the standard DNS protocol (DNS Query request), DNS level 0, DNS level 1 and then DNS level 2 via its DNS protocol module (32). To gain efficiency, the data from a DNS is loaded into the RAM of the server (31). If the ENUM subscriber is actually registered in the DNS (31) of the ENUM service provider (30), the DNS protocol module (32) returns to step 660 the NAPTR records corresponding to the DNS protocol management module (62) . The latter is responsible for retransmitting them to the ENUM script module (75) in step 661.
• DNS protocol management module which plays the role of RESOLVER
• the ENUM script (75) then issues an update request taking into account the modification requested in the IUU field in step 662 to the DNS protocol module (62).
• the latter issues a DNS UPDATE command in step 663 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). It is recalled that the latter's IP address is stored in the database (70) and that it is found from the E.164 number of the ENUM subscriber.
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the change number in this file so that the secondary DNS server (s) can reload this change themselves at predefined time intervals.
• the database (33) confirms the update at step 665, which results in a response to the request for update request at step 666.
• the ENUM script (75) intercepts at step 667 the return code of this response and then generates in step 668 the confirmation / invalidation message for taking the modification into account.
• This message is sent in step 668 to the IUU module (53) which is responsible for formatting a disconnection message before sending it in step 669 to the PLC module (52).
• the latter generates in step 670 the ISDN disconnection message which contains the IUU information element and which is therefore transmitted via the ISDN network to the terminal (2) of the ENUM subscriber.
• the latter can view the IUU on the display of its ISDN terminal (2).
• FIG. 10 schematically illustrates the procedure for accessing the consultation and automatic modification service of an ENUM profile from a web session.
• the task of manually editing an ENUM profile can quickly become tricky and repetitive.
• An automaton (called configuration automaton) is then used to perform an automatic modification of the ENUM profile as a function of time and / or other parameters. Among these other parameters, the location of the subscriber can be retained if it is known to the system (50).
• the ENUM subscriber requests in step 700 the download of the home web page of the ENUM profile management service. This is returned to step 701 by the web server (63) of the present invention.
• This web page displays an authentication form for the ENUM subscriber. They enter their ENUM E.164 number, then their login and password.
• This information is transmitted in step 702 to the web server (63) which itself transmits it (in step 703) to the authentication module (73).
• the authentication module (73) interrogates (in step 704) the local or remote database (70) (via an ODBC interface for example) by performing a search on the ENUM E.164 number. This provides at step 705 the authentication information corresponding to the authentication module (73) which compares them with the pseudonym and the password entered by the client ENUM in the web form.
• the authentication module (73) notifies in step 706 the web server module (63) that the authentication has been successful.
• This sends in step 707 to the ENUM script module (75) a request to read the automatic configuration for this ENUM profile.
• the ENUM script module (75) interrogates in step 708 the database (70) by supplying as arguments the E.164 number of the ENUM subscriber.
• the database (70) returns to step 709 the automatic profile management program to the ENUM script module (75).
• the latter formats the information, for example:
• the ENUM script module (75) transmits the information formatted in step 710 to the web server (63) which is responsible for downloading the web page containing the information in clear text of the configuration program for the ENUM profile on the web terminal (8) of the ENUM subscriber.
• This web page allows the modification of the automatic configuration program of the ENUM profile: modification of timetables, management of public holidays, addition / deletion of service, modification of service attributes, etc.
• the ENUM subscriber validates the modification of the program in step 750.
• the web server (63) transmits this information in step 751 to the ENUM script module (75).
• the latter extracts the information, formats it according to a defined format before writing it to the database (70), in step 752. This takes account of the recording of the program and confirms it with the step 753 to the ENUM script module (75).
• the latter notifies the web server (63) in step 754 of taking into account the modification of the configuration automaton of the ENUM profile.
• the server downloads in step 755 the web page of confirmation of the modification to the web terminal (8) of the ENUM subscriber.
• Fig. 11 illustrates the automatic update procedure by the ENUM profile configuration automaton as well as the optional profile change notification procedure towards the ENUM subscriber.
• the configuration automaton (74) regularly scans at step 800 the database (70) to check whether there is a programmed modification to be carried out (as a function of the current day and time). If a modification is programmed then the configuration parameters are returned to step 801.
• the configuration automaton (74) sends a request for interrogation in step 802 to the DNS protocol management module (62) by supplying argument the E.164 address of the ENUM subscriber whose profile is to be modified, transformed into a domain name (transformation of the E.164 telephone number of type 33296053859 into 9.5.8.3.5.0.6.9.2.3.3.el64.arpa).
• the DNS protocol management module (62) which plays the role of a RESOLVER can interrogate (at step 803), if however the information is not already in its cache following a previous consultation, using the standard DNS protocol (DNS Query query), the DNS server level 0, the DNS server level 1, then the DNS server level 2 via its DNS protocol module (32).
• DNS protocol DNS Query query
• the data from a DNS is loaded into the RAM of the DNS server (31). If the ENUM subscriber is actually registered in the DNS (31) of the ENUM service provider (30) then the DNS protocol module (32) returns to step 804 the NAPTR records corresponding to the DNS protocol module (62).
• the latter retransmits them to the configuration automaton (74) which then consults (step 806) the database (70) in order to recover the modifications to be made on the ENUM profile.
• the database returns (step 807) the profile to be applied to the automatic configuration module (74). If a modification is actually necessary (the profile could have been modified manually in the meantime), the configuration controller determines the modifications to be made to the NAPTR records and sends an update request to step 808 to the protocol management module.
• DNS (62) issues a DNS UPDATE command in step 809 to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). It is recalled that the latter's IP address is stored in the database (70) and that it is found from the E.164 number of the ENUM subscriber.
• the DNS protocol module (32) updates the information in the RAM of the server (31) and requests the update of the database (33) which is generally a flat text file.
• the DNS protocol manages the change number in this file so that the secondary DNS server (s) can reload this change themselves at predefined time intervals.
• the database (33) confirms the update in step 811, which results in a response to the update request request in step 812.
• the automatic configuration module (74) intercepts at step 813 the return code of this response and then generates in step 814 a request to write to the database (70) to feed the modification log.
• the database (70) confirms the writing of the automatic profile modification event in step 815. If the automatic update service has been configured to notify automatic changes to the ENUM profile, the configuration automaton notifies the update in one or more of the following modes:
• step 74) notifies the call controller (52) at step 820, which results in a telephone call to a PSTN (4), or ISDN (2), or IP (7) fixed telephone or to a mobile phone (6).
• the information and notification addresses are stored in the database (70).
• the ENUM subscriber answers this telephone call in step 822 or the call is routed to his voice mail.
• the voice synthesis module (55) or the voice file broadcasting module (56) broadcasts in step 823 the notification of the modification of the ENUM profile, for example: "hello, your ENUM profile 33296053859 has been updated today 'at 7:00 p.m. as follows: telephone service towards 0296053859 then telephone service towards 0686166924 then eMail service towards bertrand.dupont@wanadoo.fr ";
• the configuration automaton (74) notifies the SMS module (58) in step 830 by providing the text of the SMS, for example of the type: "Modification of your ENUM profile 33296053859 the
• the SMS module (58) transmits in step 840 this SMS message to the mobile or landline telephone terminal, as configured in the database (70);
• the configuration automaton (74) notifies the update to the eMail server (61) (step 850) using an eMail containing a text of the type: Modification of your ENUM profile 33296053859 on 21/03/2002 at 09:00: tel: 0296053859, tel: 06861'66924, fax: 0296050242 ".
• the configuration automaton has an eMail client.
• the eMail server (61) then transmits in step 860 the eMail in question to the eMail address stored in the database (70); o in the case where the notification is in fax mode, the configuration automaton (74) notifies the fax module (59) in step 870 by providing the text of the fax which could be of the type: "Modification of your ENUM profile 33296053859 on 03/21/2002 at 9:00 AM: tel: 0296053859, tel: 0686166924, fax: 0296050242 ".
• the fax module (59) transmits in step 880 this fax to the fax terminal
• Fig. 12 illustrates an example of an ENUM profile consultation procedure when the latter is stored in an LDAP directory.
• the example given in Fig. 12 illustrates a consultation via a personal computer but it is clear that the consultation can be carried out by means of the other types of terminals previously envisaged.
• This type of service could in particular be offered by companies wishing to offer access to an ENUM service to all or some of their employees.
• the ENUM subscriber requests in step 900 the download of the home page of the ENUM profile management service. This is returned to step 901 by the web server (63) of the system (50).
• This web page displays an authentication form for the ENUM subscriber. They enter their ENUM E.164 number, then their pseudonym and password.
• This information is transmitted in step 902 to the web server (63) which itself transmits it (step 903) to the authentication module (73).
• the authentication module (73) interrogates (step 904) the local or remote database (via an ODBC interface for example) by performing a search on the ENUM E.164 number. This provides in step 905 the authentication information corresponding to the authentication module (73) which is responsible for comparing them with the pseudonym and password entered by the ENUM client.
• the authentication module (73) notifies in step 906 the web server module (63) that the authentication has been successful.
• This sends in step 907 to the ENUM script module (75) a request to read the ENUM profile.
• the ENUM script (75) sends an interrogation request in step 908 to the DNS protocol management module (62) by supplying as argument the E.164 address of the ENUM subscriber transformed into a domain (transformation of the E.164 telephone number, type 33296053859 in 9.5.8.3.5.0.6.9.2.3.3.el64.arpa).
• the DNS protocol management module (62) which plays the role of a RESOLVER interrogates (step 909), if the information is not already in its cache following a previous consultation, using the standard DNS protocol (request DNS Query), the level 0 DNS server, the level 1 DNS server, then the level 2 DNS server via its DNS protocol module (32).
• the data from a DNS is loaded into the RAM of the server (31).
• the DNS protocol management module (32) returns to step 910 the corresponding NAPTR record (s) ( s).
• the DNS protocol management module (62) is responsible for retransmitting them to the ENUM script module (75) in step 911. The latter analyzes and interprets the NAPTR record (s), for example:
• the ENUM script detects that it is an LDAP service. Consequently, the ENUM script module (75) sends in step 912 to the LDAP protocol management module (64) an LDAP request for connection request to the LDAP server referenced by the URI "ldap: // ldap. precedeA.fr ". The latter sends in step 913 a "Bind” request intended for the LDAP protocol module (35) of the LDAP directory server (34) of the supplier ENUM A (30). The LDAP protocol module (35) accepts the connection in step 914. The LDAP protocol management module (64) then sends in step 915 to the LDAP protocol module (35) the LDAP "Search" request by providing the E.164 number of the ENUM subscriber as an argument.
• the LDAP protocol module (35) interrogates the LDAP database (36) in step 916 then returns (in step 917) all of the information concerning the ENUM subscriber to the LDAP protocol module (35) which itself even returns them (step 918) to the LDAP protocol management module (64).
• the latter returns the information in step 919 to the ENUM script (75) which is responsible for putting it in a form understandable for the ENUM subscriber before transmitting it (in step 922) to the web server (63).
• the server downloads the dynamically generated web page in step 923 to the web terminal (8) of the ENUM subscriber.
• the LDAP protocol management module (64) sends in step 920 a disconnection request to the LDAP server (34) via an "Unbind" request.
• the LDAP protocol module (35) confirms the disconnection at step 921.
• Fig. 13 describes the procedure for manual modification of an ENUM profile when it is stored in an LDAP directory. Again, a modification of the ENUM profile by a terminal other than a PC can of course be envisaged.
• the DNS protocol management module (62) which plays the role of a RESOLVER can interrogate, if the information is not already in its cache following a previous consultation (in step 1003) with the standard DNS protocol (request DNS Query) DNS level 0, then DNS level 1, before querying DNS level 2 via its DNS protocol module (32). To gain efficiency, the data from a DNS is loaded into the RAM of the DNS server (31). If the ENUM subscriber is actually registered in the DNS (31) of the ENUM service provider (30), the DNS protocol module (32) returns to step 1004 the corresponding NAPTR record (s). The DNS protocol management module (62) then retransmits them to the ENUM script module (75) in step 1005. The latter analyzes and interprets the NAPTR record (s), for example:
• the ENUM script module (75) detects that it is an LDAP service.
• the ENUM script module (75) then sends (step 1006) to the LDAP protocol module (64) an LDAP request for connection request to the LDAP server referenced by the URI "ldap: //ldap.fournisseurA.fr".
• the latter sends at step 1007 a "Bind” request to the LDAP protocol module (35) of the LDAP directory server (34) from the supplier ENUM A (30).
• the LDAP protocol module (35) accepts the connection in step 1008.
• the LDAP protocol module (64) then sends in step 1009 to the LDAP protocol module (35) an LDAP "Search" request by providing the number E .164 of the ENUM subscriber as an argument.
• the LDAP protocol module (35) interrogates the LDAP database (36) in step 1010 then returns to step 101 1 all of the information concerning the ENUM subscriber to the LDAP protocol management module (35). The latter returns them to step 1012 to the LDAP protocol management module (64) which itself returns them (step 1013) to the ENUM script module (75). This compares them with the information provided via the web by the ENUM subscriber and determines the operation to be performed in LDAP format and transmits a modification request in step 1014 to the LDAP protocol management module (64) . The latter sends an LDAP "Modify" request in step 1015 to the LDAP protocol module (35) which itself sends in step 1016 a request to write to the database (36).
• the LDAP protocol module (35).
• the latter transmits (step 1018) the update confirmation / invalidation to the LDAP protocol management module (64) which returns it (step 1019) to the ENUM script module (75).
• This then generates the modification confirmation web page before transmitting it to the web server (63).
• the server downloads this page (step 1023) to the web terminal (8) of the ENUM subscriber.
• the LDAP protocol module (64) sends (step 1020) a disconnection request to the LDAP server (34) via an "Unbind" request.
• the LDAP protocol module (35) confirms the disconnection at step 1021.
• ENUM and the updating of an ENUM profile, it is clear to those skilled in the art that it can extend to the updating of one or more resource record (s) (RR) in a DNS (or LDAP) server, as defined in the paragraph
• the update may relate to one or more fields of this record, as defined in the above-mentioned document RFC 1035.

Applications Claiming Priority (3)

Publications (1)

Family

ID=29595361

Family Applications (1)

Country Status (7)

Families Citing this family (81)

Citations (2)

Family Cites Families (23)

• 2002
  • 2002-06-14 FR FR0207510A patent/FR2841072A1/fr active Pending
• 2003
  • 2003-06-05 EP EP03760001A patent/EP1514396A1/fr not_active Withdrawn
  • 2003-06-05 WO PCT/FR2003/001691 patent/WO2003107627A1/fr active Application Filing
  • 2003-06-05 CN CN03813859.XA patent/CN1663222B/zh not_active Expired - Fee Related
  • 2003-06-05 AU AU2003260575A patent/AU2003260575A1/en not_active Abandoned
  • 2003-06-05 US US10/517,813 patent/US20050182781A1/en not_active Abandoned
  • 2003-06-05 JP JP2004514305A patent/JP4336647B2/ja not_active Expired - Fee Related

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events