EP1514396A1 - Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap - Google Patents

Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap

Info

Publication number
EP1514396A1
EP1514396A1 EP03760001A EP03760001A EP1514396A1 EP 1514396 A1 EP1514396 A1 EP 1514396A1 EP 03760001 A EP03760001 A EP 03760001A EP 03760001 A EP03760001 A EP 03760001A EP 1514396 A1 EP1514396 A1 EP 1514396A1
Authority
EP
European Patent Office
Prior art keywords
request
enum
server
dns
module
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
EP03760001A
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
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP1514396A1 publication Critical patent/EP1514396A1/fr
Withdrawn legal-status Critical Current

Links

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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système de consultation et/ou de mise à jour d'un enregistrement stocké dans une première base de données (33, 36), ledit enregistrement comprenant un ou une pluralité d'enregistrements de ressources (RR), ladite première base de données étant hébergée par un serveur de noms de domaine, dit serveur DNS, Domaine Name System, ou un serveur d'annuaire, dit serveur LDAP, Lightweight Directory Access Protocol, pouvant être accédé par indirection à partir d'un serveur DNS. Le système comprend: - des moyens de communication (1150, 53-59, 61, 63) permettant audit système de recevoir d'un terminal de télécommunication une demande de consultation et/ou de modification dudit enregistrement ou une programmation d'une telle demande; - des moyens de contrôle (1175, 74, 75) adaptés à déterminer à partir de ladite demande de consultation et/ou de modification transmise audit système ou préalablement programmée dans ledit système, un nom de domaine et une opération à effectuer sur ledit enregistrement; - des moyens de gestion de protocole (1162, 62, 64) adaptés à rechercher à partir dudit nom de domaine, l'adresse IP dudit serveur hébergeant ladite première base de données et, en fonction de ladite opération , à transmettre audit serveur une requête de lecture ou de mise à jour dudit enregistrement. Le module protocole DNS joue le rôle classique d'un logiciel RESOLVER. L'invention est utilisable dans le cadre du service ENUM permettant à tout abonnée d'associer son numéro de téléphone au format E.164 à d'autres services. Les RR (Resource Record) contiennent à cet effect plusieurs champs NAPTR (Naming Authority PoinTer) faisant référence à une adresse eMail, un URL de site web, un numéro de fax ou de téléphone VoIP ou mobile.

Description

SYSTEME DE CONSULTATION ET/OU MISE A JOUR DE SERVEURS DNS ET/OU D ' ANNUAIRES LDA P
La présente invention concerne un système de consultation et /ou mise à jour de serveurs DNS (Domain Name System) et/ou d'annuaires LDAP (Lightweight Directory Access Protocol) à partir d'un terminal. La présente invention permet notamment à un abonné, à partir d'un terminal quelconque, de consulter et de mettre 5 à jour un enregistrement de ressources de télécommunication stocké dans un serveur DNS ou LDAP.
Les serveurs DNS (et LDAP) sont utilisés dans le monde informatique pour nommer des machines (par exemple: association d'une URL web à une adresse IP correspondant au serveur web hébergeant ce site web). Ces serveurs sont
10 habituellement consultés par des machines informatiques au moyen d'un logiciel communément appelé RESOLVER, disponible dans la plupart des terminaux ou serveurs informatiques. Ce logiciel permet d'extraire une information d'un serveur DNS en réponse à la requête d'un client. Cette information peut être disponible directement auprès du premier serveur DNS consulté ou bien auprès d'un serveur
15 DNS référencé par le premier, et ainsi de suite si nécessaire par indirections successives. Les contenus des serveurs DNS sont mis à jour par des spécialistes "administrateur" et de manière peu fréquente (mise à jour de fichiers à plat sous plateforme UNIX ou application dédiée via IHM sous les plate-formes serveurs Windows). Le format des contenus des serveurs et des requêtes sont définis dans un protocole, dit protocole DNS décrit dans les documents RFC 1034 et RFC 1035, disponibles sur le site web de l'IETF (www.ietf.org).
D'autre part, les serveurs DNS sont désormais appelés à jouer un rôle dans le cadre du service ENUM visant à offrir aux abonnés une portabilité généralisée de numéro de téléphone. Ce service ENUM utilise le système de numérotation téléphonique international défini par l'UIT sous la recommandation E.164. Plus précisément, le service ENUM permet à tout abonné disposant d'une numéro téléphonique unique E.164 (numéro de téléphone de type +33296053859) d'être joint par différents moyens en fonction de ses préférences configurées dans un profil hébergé dans le réseau par un serveur DNS. Par exemple, le numéro de téléphone unique E.164 de l'abonné ENUM peut être associé à un numéro de téléphone mobile (+33686166924), à un numéro de téléphone fixe (+33296916404), à une adresse eMail (bertrand.dupont@rd.francetelecom.com . à une URL de site web fhttp ://www.bertrand.dupont.corri), à un numéro de téléphone VoIP (sip:bertrand.dupont@sip.francetelecom.com), à un numéro de fax, etc.
L'ensemble de ces informations peuvent être stockées dans un serveur DNS standard et accédées selon le modèle de délégation hiérarchique représenté en Fig. 1.
L'accès se fait par un serveur DNS racine (E164.ARPA). Chaque pays dispose ensuite d'un code téléphonique unique (33 pour la France) et un serveur DNS est géré au niveau 1 par chaque pays (3.3.E164.ARPA pour la France). Des opérateurs de télécommunications ou des fournisseurs de services ENUM gèrent enfin des serveurs DNS (indiqué en Fig. 1 par DNS 1 à DNS 6) en fonction des ressources téléphoniques (tranche de numéros téléphoniques E.164) qui leur sont attribuées. Le modèle retenu est un découpage par tranches: 5 tranches de numéros de téléphone fixes RTC avec des préfixes allant de 1 à 5 et une tranche de numéros de téléphone mobile identifiée par le préfixe 6. A un numéro de téléphone au format E.164, est associé un chemin dans l'arborescence des serveurs DNS. Plus précisément, chaque numéro de téléphone au format international E.164 est inversé, le code "+" est supprimé, un point est ajouté entre chaque chiffre et le résultat obtenu est accolé au domaine el64.arpa de manière à transformer le numéro de téléphone en un nom de domaine Internet unique. Par exemple, le numéro de téléphone +33686166924 donne après transformation, le nom de domaine Internet 4.2.9.6.6.1.6.8.6.3.3.el64.arpa.
D'autre part, à chaque numéro de téléphone au format E.164 est associé un enregistrement comprenant un ou des enregistrements de ressources (Resource Record ou RR), stockés dans le serveur de niveau 2 correspondant, chaque enregistrement de ressource pouvant comprendre un ou plusieurs champs. Par exemple, à un numéro de téléphone au format E.164 peuvent être associés des enregistrements de ressource
NAPTR (Naming Authority PoinTeR), tels que définis dans les documents RFC 2915 et RFC 2916, disponibles sur le site de PIETF. De manière schématique, un enregistrement de ressource NAPTR indique un service de télécommunication (n° de tel, fax, adresse eMail, site web etc.) associé à un niveau de priorité. On appellera par la suite enregistrement ENUM (ou profil ENUM) un ensemble d'enregistrements
NAPTR associés à un nom de domaine Internet. Par exemple, si le profil ENUM suivant est stocké dans un serveur DNS de niveau 2 :
$ORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa.
IN NAPTR 100 10 "u" "tel+E2U" "!Λ.*$!tel:+33296053859!" IN NAPTR 100 11 "u" "tel+E2U" "!Λ.*$!tel:+33296916404!" IN NAPTR 100 12 "u" "tel+E2U" "!Λ.*$!tel:+33686166924! IN NAPTR 100 13 "u" "sip+E2U" "!Λ.*$!sip:bdupont@sip.ftrd.ιr!"
IN NAPTR 120 10 "u" "mailto+E2U" "!Λ.*$!mail2:bdupont@rd.ftrd.fr!" IN NAPTR 130 10 "u" "http+E2U" "!Λ.*$!http://www.bdupont.fr!"
La ligne d' en-tête indique un nom de domaine Internet correspondant au numéro de téléphone E.164. Le logiciel RESOLVER permet à partir du nom de domaine d'accéder à l'enregistrement. A chaque enregistrement NAPTR de l'exemple ci- dessus correspond une ressource ou service de télécommunication. Deux champs numériques suivent le terme « NAPTR », il s'agit respectivement des priorités de service: "Ordre" et "Préférence". Plus la valeur du champ "Ordre" est faible, plus le service est prioritaire et si plusieurs services ont un niveau d'ordre identique, plus la valeur de Préférence associée est faible, plus le service est prioritaire. Ainsi, les lignes de l'enregistrement ci-dessus correspondent à des priorités décroissantes.
La lère ligne correspond au service téléphonique fixe 0296053859 avec un ordre=100 et une préférence =10. La 2èrae ligne correspond au service téléphonique fixe 0296916404 avec un ordre=100 et une préférence=l 1 .
La 3ème ligne correspond au service téléphonique mobile 0686166924 avec un ordre=100 et une préférence=12 . La 4ème ligne correspond au service téléphonique IP via SIP vers l'adresse SIP bdupont@sip.ftrd.fr avec un ordre=T00 et une préférence=13 .
La 5eme ligne correspond au service de courrier électronique eMail dont l'adresse de destination est bdupont@rd.ftrd.fr avec un ordre=120 et une préférence=10 .
Enfin, la 6ème ligne correspond au service web dont l'URL d'accès est http://www.bdupont.fr avec un ordre= 130 et une préférence^ 10 .
La signification de cet enregistrement est la suivante. Si l'on cherche à joindre le numéro de téléphone E.164 (+33296053859), le logiciel RESOLVER transmet une requête au serveur DNS niveau 2 avec le nom de domaine Internet correspondant (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). En retour, le serveur DNS niveau 2 (DNS2) fournira dans la réponse la liste des ressources de télécommunication (également dénommés ci-après services) associés au numéro de téléphone +33296053859, telle que donné par l'enregistrement. Le logiciel RESOLVER et le service ENUM pourront alors exploiter tout ou partie de ces ressources en mode séquentiel (le système tentera de joindre le service le plus prioritaire puis, en l'absence de réponse ou en cas d'occupation, le système essaiera de joindre le service de moindre priorité, etc.) ou en mode diffusion (le service ENUM tentera alors de joindre simultanément l'ensemble des services).
La modification des profils ENUM dans un serveur DNS s'accommode mal du procédé de mise à jour par administrateur tel que connu de l'état de la technique. En effet, au contraire des noms de domaines Internet, les services classiques de télécommunication tels que le téléphone ou la télécopie sont susceptibles de modification fréquente. Qui plus est, il est quelquefois nécessaire de programmer ces modifications de manière automatique sur une base quotidienne voire horaire. Il est alors extrêmement difficile pour des raisons de disponibilité et de flexibilité de faire supporter la modification de configuration d'un profil ENUM à son propre opérateur de télécommunications ou à son fournisseur de service ENUM.
Un problème particulier à la base de l'invention est de permettre à un abonné une consultation et/ou une modification simple et rapide de son profil ENUM stocké dans un serveur DNS ou un annuaire LDAP. De manière plus générale, le problème à la base de l'invention est de permettre une consultation et/ou modification simple et rapide d'un ou de plusieurs enregistrement(s) de ressource stocké(s) dans un serveur DNS ou LDAP et ce, à partir d'un terminal conventionnel quelconque. Le problème à la base de l'invention est résolu par un système de consultation et/ou de mise à jour d'un enregistrement stocké dans une première base de données, ledit enregistrement comprenant un ou une pluralité d'enregistrements de ressources, ladite première base de données étant hébergée par un serveur de noms de domaine, dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant être accédé par indirection à partir d'un serveur DNS, ledit système comprenant:
- des moyens de communication permettant audit système de recevoir d'un terminal de télécommunication une demande de consultation et/ou de modification dudit enregistrement ou une programmation d'une telle demande ;
- des moyens de contrôle adaptés à déterminer à partir de ladite demande de consultation et/ou de modification transmise au dit système ou préalablement programmée dans ledit système, un nom de domaine et une opération à effectuer sur ledit enregistrement ;
- des moyens de gestion de protocole adaptés à rechercher à partir dudit nom de domaine, l'adresse IP dudit serveur hébergeant ladite première base de données et, en fonction de ladite opération, à transmettre au dit serveur une requête de lecture ou de mise à jour dudit enregistrement.
Avantageusement, ledit système comprend des moyens d'authentification adaptés à authentifier au niveau applicatif l'émetteur de ladite demande à partir d'informations d'authentification stockées dans une seconde base de données locale ou distante.
Lorsque l'émetteur de ladite demande a été authentifié, lesdits moyens de gestion de protocole permettent de transmettre une requête en consultation selon le protocole DNS (DNS Query) audit serveur DNS, la requête ayant pour argument ledit nom de domaine, et à recevoir une première réponse dudit serveur. Selon un mode de réalisation, les moyens de contrôle sont adaptés à déterminer ledit nom de domaine à partir d'un identifiant d'abonné qui pourra être le numéro téléphonique E.164 dudit abonné. Les moyens de contrôle sont alors adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un enregistrement de ressource de type NAPTR.
Selon d'autres modes de réalisation les moyens de contrôle sont adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un ou plusieurs enregistrements de ressource de type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO,MX, TXT.
Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : la Fig. 1 illustre schématiquement le modèle de délégation utilisé dans le service ENUM; la Fig. 2 A illustre schématiquement un exemple d'environnement du système selon l'invention; la Fig. 2B illustre schématiquement l'environnement de la Fig. 2A dans le contexte du service ENUM ; la Fig. 3A représente le schéma de principe du système de consultation mise à jour selon l'invention ; la Fig. 3B représente un exemple de système de consultation/ mise à jour selon l'invention ; la Fig. 4 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM avec accès en mode vocal ; la Fig. 5 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par envoi de messages SMS ; la Fig. 6 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par le Web ; la Fig. 7 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM à partir d'un Minitel; la Fig. 8 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par eMail; la Fig. 9 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par IUU à partir d'un terminal RNIS; la Fig. 10 représente schématiquement une procédure de programmation de mise automatique de profil ENUM ; la Fig. 11 représente schématiquement une procédure de mise à jour automatique de profil ENUM; la Fig. 12 représente schématiquement une procédure de consultation de profil
ENUM lorsque ce dernier est stocké dans un annuaire LDAP ; la Fig. 13 représente schématiquement une procédure de mise à jour de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP.
La Figure 2 A illustre un exemple d'environnement du système selon l'invention.
Des fournisseurs de service de gestion de ressources de télécommunication, ci- après dénommés fournisseurs de service, ont été schématiquement représentés en 30I,...,30N- Chaque fournisseur de service dispose d'un serveur DNS (3L) ou LDAP (34j) hébergeant une base de données et plus généralement de plusieurs serveurs redondants de manière à augmenter la fiabilité de l'accès au service. La base de données contient un enregistrement des ressources de télécommunication pour tous les abonnés du fournisseur de service en question.
Le système (50) selon l'invention peut être connecté d'une part au réseau téléphonique public via une interface standard de type analogique ou numérique T0 ou T2 et, d'autre part, au réseau IP via une interface standard de type Ethernet.
Plus précisément, le système (50) est connecté au réseau Internet si la présente invention est accessible à tout abonné, quel que soit son fournisseur de service, et pourra être connecté à un réseau Intranet si la présente invention est accessible aux seuls abonnés d'un fournisseur de service. Le système (50) pourra être accédé par un terminal téléphonique RNIS (2) connecté soit directement soit a travers un PABX (3) au réseau RNIS (10). On rappelle que le réseau RNIS est interconnecté nativement au réseau RTC.
Le système (50) pourra aussi être accédé par un terminal téléphonique classique (4) ou un terminal Minitel (5) connecté au réseau RTC (11). Le système (50) pourra encore être accédé par un terminal mobile GSM (6) ou encore un terminal UMTS non représenté (les réseaux GSM et UTRAN sont interconnectés nativement au réseau RTC).
Le système (50) pourra être accédé au moyen d'un terminal téléphonique IP (7) connecté au réseau IP (13). Le système (50) pourra enfin être accédé au moyen d'un micro-ordinateur (8) relié au réseau IP soit au travers une interface Ethernet (réseau local d'entreprise) soit par modem (RTC/RNIS/ADSL/câble/satellite etc.)
L'abonné pourra en outre recevoir des notifications du système (50) grâce à l'un des terminaux envisagés ci-dessus ou bien encore à l'aide d'un terminal fax (9).
La Figure 2B illustre un exemple d'environnement du système selon l'invention, dans le contexte d'un service ENUM. Les éléments portant les mêmes numéros de référence sont identiques à ceux de la Fig. 2A. On a indiqué en 40 le serveur DNS ENUM de niveau 0 (racine). Ce serveur dispose de l'ensemble des adresses IP référençant l'ensemble des serveurs DNS ENUM de niveau 1, correspondant aux codes des différents pays (33 pour la France, 34 pour l'Espagne, 44 pour l'Angleterre, etc.). Par exemple, on a fait figurer en 41 le serveur DNS ENUM de niveau 1 correspondant à la France. Chaque opérateur ou fournisseur de service ENUM dispose d'au moins un premier serveur DNS ENUM de niveau 2 (31;), dit serveur primaire, redondé par au moins un second serveur DNS ENUM de niveau 2 (31 'j), dit serveur secondaire, ce afin d'assurer une bonne fiabilité de service. Le serveur primaire (resp. secondaire) héberge une base de données 33j (resp. 33'i). Dans chaque serveur de niveau 2, est stocké, pour chaque numéro de téléphone E.164 d'abonné au service ENUM, un profil composé des différentes ressources de télécommunication de l'abonné, chaque ressource correspondant à un moyen d'accès (par ex. téléphone fixe bureau, téléphone fixe domicile, téléphone mobile, téléphone IP, adresse eMail du bureau, adresse eMail du mobile, N° de fax professionnel, etc.) ainsi que les priorités afférentes à chacun de ces moyens d'accès. Chaque ressource de télécommunication est déclarée au moyen d'un enregistrement de ressource NAPTR comme on l'a vu plus haut. La priorité d'une ressource est déterminée par le contenu des champs Ordre et Préférence de l'enregistrement de ressource NAPTR, tels que définis dans le document RFC 2915 de 1TETF et exemplifiés dans la partie introductive.
Un fournisseur A de service ENUM (30j) peut également disposer d'un serveur LDAP (34j) hébergeant un annuaire dynamique LDAP (360 tel Que défini dans le document RFC 1959 de 1TETF. L'intérêt de cette configuration est de permettre de gérer les profils ENUM par indirection non plus dans le DNS ENUM niveau 2 mais dans l'annuaire dynamique LDAP. L'avantage procuré consiste à ne plus modifier le profil du client ENUM au niveau du serveur DNS ENUM niveau 2 mais directement dans l'annuaire LDAP qui, lui, est conçu pour stocker des profils dynamiques. Dans ce cas, le DNS ENUM niveau 2 (31,) contient par exemple le profil suivant pour l'ensemble des numéros de téléphone E.164 commençant par le préfixe "+332":
$ORIGIN 2.3.3.el64.arpa.
IN NAPTR 100 10 "u" "ldap+E2U"
"!Λ.+332(.*)$!ldap://ldap.fournisseurA.fr/cn=01 !"
L'annuaire LDAP (36,) est accédé par indirection à partir du serveur DNS ENUM de niveau 2 et contient les enregistrements de ressource pour les différents abonnés du fournisseur A.
Un serveur ou une passerelle ENUM (80) peut consulter un fournisseur de service ENUM (30,) pour connaître la liste des ressources de télécommunication d'un abonné ENUM. Pour ce faire, le logiciel RESOLVER transforme le numéro unique E.164 de l'abonné en nom de domaine comme on l'a vu plus haut et accède par indirections successives au serveur DNS ENUM niveau 2 (31,) et, le cas échéant, après indirection supplémentaire au serveur LDAP (34,). Le fournisseur de service retourne la liste des ressources de l'abonné en question avec les priorités associées. Le serveur ou la passerelle ENUM (80) peut alors, selon le cas, tenter de joindre l'abonné en utilisant successivement les ressources, par ordre décroissant de priorité ou joindre l'abonné au moyen de l'ensemble de ses ressources.
La Fig. 3A représente le schéma de principe du système (50) de mise à jour selon l'invention .
Le système comprend des moyens de communication (1 150) permettant à un abonné de dialoguer avec ledit système et notamment : de transmettre à l'abonné une requête en authentification ; de recevoir dudit abonné des informations permettant son authentification ; de recevoir dudit abonné une demande de modification d'un enregistrement (dite demande manuelle) ou une demande de modification automatique (dite demande programmée) en fonction d'un critère temporel ou géographique ; - de transmettre le contenu d'un enregistrement préalablement ou postérieurement à la demande de modification ; de transmettre au dit abonné une notification de confirmation de mise à jour lorsque la modification demandée a bien été effectuée et d'infirmation de mise à jour lorsque cette dernière n'a pu être effectuée; - de transmettre au dit abonné, à fin de consultation ou révision, une demande de modification automatique préalablement enregistrée dans ledit système ; de transmettre au dit abonné un historique des modifications effectuées.
Le système comprend également des moyens d'interface (1160) permettant de connecter lesdits moyens de communication au réseau RTC/RNIS et ou à un réseau IP (Internet ou Intranet).
Le système comprend encore des moyens d'authentification (1173) coopérant avec les moyens de communication pour authentifier au niveau applicatif un émetteur de demande de consultation et/ou mise à jour. L' authentification au niveau applicatif présente l'avantage de permettre à un abonné d'opérer à partir de n'importe quel terminal. Les moyens d'authentification utilisent pour ce faire des informations d'authentification stockées dans une base de données (1170) locale ou distante .
Outre les informations susmentionnées, la base de données (1170) peut notamment contenir des programmes de modification automatique relatifs à différents abonnés, les adresses IP des serveurs des différents fournisseurs de gestion de ressources de télécommunication, les historiques de modifications manuelles ou automatiques des enregistrements, les adresses auxquelles les notifications de confirmation/infirmation de mise à jour doivent être transmises.
Le système (50) comprend encore des moyens de gestion de protocole (1162) assurant entres autres la fonction RESOLVER. En particulier les moyens de gestion de protocole sont adaptés à rechercher, le cas échéant par indirections successives, le contenu d'un enregistrement de ressource (RR) à l'aide d'un nom de domaine. Les moyens de gestion de protocole peuvent transmettre à cette fin des requêtes de consultation selon le protocole DNS (DNS Query). En outre, les moyens de gestion de protocole peuvent mettre à jour des enregistrements de ressources à partir de requêtes de mise à jour (DNS Update). Selon un mode de réalisation, si des enregistrements de ressources sont stockées dans un annuaire LDAP, les moyens de gestion de protocole permettront également la consultation d'un enregistrement dans un annuaire LDAP (émission d'une requête LDAP Search) ainsi que la mise à jour de cet enregistrement (émission d'une requête LDAP Modify). Lorsque la mise à jour a été réalisée, les moyens de protocole reçoivent un acquittement du serveur du fournisseur de gestion de ressources de télécommunication.
Les moyens de contrôle 1175 coordonnent les moyens précités et notamment :
- ordonnent aux moyens de communication la transmission d'une requête en authentification ; après authentification de l'abonné par les moyens d'authentification (1173) demandent aux moyens de protocole (1162) de transmettre une requête en consultation, formatent la réponse et la retransmettent sous forme intelligible à l'abonné via les moyens de communication; à partir d'une demande en modification d'un enregistrement de ressource par un abonné, déterminent une opération à effectuer sur ledit enregistrement et un identifant de l'abonné sur réception de confirmation/infirmation de mise à jour par les moyens de protocole, notifient la confirmation infirmation à l'abonné via les moyens de communication.
La Fig. 3B illustre un exemple de réalisation de l'invention dans le contexte d'un service ENUM. Les éléments portant les mêmes numéros de référence sont identiques à ceux de la Fig. 2A. En particulier, l'abonné pourra contacter le système de mise à jour (50) au moyen de l'un des terminaux envisagés plus haut. En (30) a été représenté un fournisseur de service de gestion de ressources de télécommunication comprenant un serveur DNS de niveau 2 (31), dit serveur primaire, redondé par un serveur secondaire (non représenté). Le serveur (31) comporte une base de données (33) et une pile de protocole DNS (32) intégrant les protocoles DNS décrits dans les documents RFC 1034 et RFC 1035. La pile de protocole intègre également les protocoles DNS décrits dans les documents RFC 2136 et RFC 2137 destinés à permettre la mise à jour (DNS Update) d'un enregistrement de ressource (RR). De manière optionelle, le fournisseur de service de gestion de ressources comprend aussi un serveur d'annuaire LDAP (34) hébergeant une base de données (36). Le serveur d'annuaire LDAP comporte une pile de protocole LDAP (35).
Les moyens de communication du système (50) sont constitués des modules suivants : o un module ayant en charge le traitement des appels téléphoniques entrants et sortants (52). Ce module gère l'établissement et la libération de la communication ; o un module (53) de gestion d'Information d'Usager à Usager (IUU) permettant d'extraire et de transmettre des informations IUU ; o un module (54) de traitement des codes DTMF. Ce module a en charge la récupération des DTMF saisis par l'abonné ; o un module (55) de synthèse vocale ; o un module (56) de diffusion de fichiers vocaux pré-enregistrés et concaténés pour former des phrases ; o un serveur vidéotex (57) ; o un module de réception et d'envoi de SMS (58) ; o un module d'envoi de fax (59) ; o un serveur SMTP (61) permettant l'émission et la réception d'eMail ; o un serveur Web dynamique (63).
Il convient de noter que le système peut comprendre également un module de reconnaissance vocale (non représenté) adapté à reconnaître une information prononcée par l'abonné.
Les moyens de communication sont reliés à l'extérieur au moyen d'une interface RTC et/ou RNIS (51) et une interface IP (60). La première est basée soit sur une carte analogique RTC multi-port soit sur une carte RNIS TO (2 canaux) ou T2 (30 canaux). La seconde est une interface Ethernet. La passerelle indiquée par (14) rappelle que les réseaux RTC/RNIS et IP sont nativement interconnectés en protocole VOIP (H323/SIP). Le système (50) comporte, comme précédemment, des moyens d'authentification (73) autorisant l' authentification applicative des abonnés du service à partir d'informations d'authentification, par exemple des couples de pseudonymes (Login_Id) et de mots de passe stockés dans une base de données (70) locale ou distante. En outre, la base de données comprend les identifiants des différents fournisseurs de service ENUM (tel que 30), les adresses IP ou les noms de machine des DNS tiers 2, des demandes de modification automatique de profil ENUM, les historiques de modification manuelle ou automatique de profils ENUM, les adresses de notification de modification du profil ENUM (N° de fax, SMS, eMail).
Le système comprend encore un module de gestion de protocole DNS (62), de préférence dans sa forme sécurisée (DNSSec). Ce module joue en particulier le rôle de RESOLVER pour la lecture des enregistrements de ressource.
Le cas échéant, un module de gestion de protocole LDAP (64) y est adjoint pour permettre la lecture et la modification d'enregistrements dans un annuaire LDAP.
Le système comprend également un module (72) permettant la configuration des adresses des serveurs DNS de niveau 2 ainsi qu'un module (71) chargé de tenir à jour les modifications manuelles ou automatiques des profils ENUM et d'élaborer, le cas échéant, des statistiques pour l'exploitant du système.
Les moyens de contrôle sont constitués, d'une part, d'un module (74) chargé de la configuration automatique de profils ENUM à partir de demandes de modification automatique programmées par des abonnés et stockées dans la base de données (70) et, d'autre part, d'un module (75) chargé de la configuration « manuelle » des profils ENUM. Ce dernier gère des scripts ENUM, notamment un script de lecture de profil ENUM (on rappelle qu'un profil ENUM est constitué d'une liste d'enregistrements de ressource NAPTR), des scripts de modification des champs des enregistrements de ressource NAPTR et notamment des champs ordre, préférence, service (adresse eMail, numéro de téléphone, adresse eMail etc.). Si l'on souhaite prévoir la consultation et/ou la mise à jour d'enregistrements de ressource DNS autres que NAPTR, des scripts supplémentaires doivent être prévus pour leur modification.
La Fig. 4 illustre schématiquement une procédure de consultation et de modification manuelle d'un profil ENUM en mode vocal via un téléphone fixe ou mobile de type RTC, RNIS, GSM ou IP.
L'abonné ENUM émet à l'étape 100 un appel téléphonique gratuit (type numéro vert) ou payant selon un mode de rémunération géographique ou forfaitaire de type audiotel ou numéros colorés depuis un terminal fixe RTC (4) ou RNIS (2) connecté sur le réseau public ou derrière un PABX (3) ou un terminal mobile (6) de type GSM, ou depuis un terminal IP (7) à destination de l'interface RTC/RNIS (51) du système (50). L'automate de traitement d'appel (52) accepte automatiquement l'appel entrant à l'étape 101. Le module script ENUM (75) donne à l'étape 102 l'ordre au module de synthèse vocale (55) ou au module de diffusion de fichiers vocaux (56) de diffuser à l'étape 103 vers l'abonné ENUM une annonce vocale invitant l'abonné ENUM à saisir son numéro ENUM E.164 ainsi que son pseudonyme et son mot de passe . L'abonné ENUM saisit à l'étape 104 via son clavier ces informations qui sont véhiculées dans la bande sous forme de DTMF et qui sont interceptées par le module de traitement des DTMF (54). Ces informations sont fournies à l'étape 105 au module d'authentification (73) qui interroge la base de données locale ou distante (via par exemple une interface de type ODBC (pour Open DataBase Connectivity)) en opérant une recherche sur le Numéro ENUM E.164. Celle-ci fournit à l'étape 107 les informations d'authentification correspondantes au module d'authentification (73). Ce dernier compare le pseudonyme et le mot de passe saisis par le client ENUM avec les informations d'authentification contenues dans la base de données (70). En cas de concordance, le module d'authentification (73) ordonne à l'étape 108 au module de synthèse vocale (55) ou au module de diffusion de fichiers vocaux de diffuser à l'étape 109 vers l'abonné ENUM une annonce du type "Pour consulter votre profil ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 2, pour configurer de manière automatique votre profil tapez sur 3, pour modifier votre pseudonyme-mot de passe tapez sur 4, pour accéder à votre journal de modification de votre profil tapez 5, etc. Si l'abonné ENUM tape sur la touche 1 de son clavier téléphonique à l'étape 110, le code DTMF correpondant est intercepté par le module de traitement des DTMF (54) et est retransmis à l'étape 111 vers le module script ENUM (75). Le script ENUM (75) détecte alors qu'il s'agit d'une commande de lecture du profil ENUM. Le script ENUM (75) émet alors à l'étape 112 une demande d'interrogation au module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM mise sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arρa). Le module de gestion de protocole DNS (62) qui joue le rôle classique d'un RESOLVER peut d'abord vérifier si les informations ne sont pas présentes dans son cache suite à une consultation précédente ou interroger (à l'étape 113) selon le protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). Pour gagner en efficacité, les données d'un enregistrement NAPTR sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30) alors la pile de protocole DNS (32) retourne (à l'étape 114) au module protocole DNS (62) la liste des enregistrements NAPTR correspondants. Le module de protocole DNS (62) se charge ensuite de les retransmettre vers le module Script ENUM (75) à l'étape 115. Le module (75) analyse et interprète les enregistrements NAPTR et génère un texte compréhensible par l'abonné ENUM du type "Service N° 1 : téléphone vers le 0296053859, service N°2: téléphone vers le 0686166924, service N°3: eMail vers bertrand . dupont@rd . francetelecom.com . etc.). Ce texte est envoyé vers le module de synthèse vocale (55) à l'étape 116 qui se charge de diffuser cette information à l'abonné ENUM à l'étape 117. Dans le cas ou le module de diffusion de fichiers vocaux (56) est utilisé, le module (75) génère l'enchaînement des fichiers vocaux à jouer. Après diffusion de cette information, le module de synthèse vocale (55) ou le module de diffusion de fichiers vocaux (56) diffuse à nouveau à l'étape 118 la liste des opérations d'administration possibles sur le profil ENUM "Pour consulter votre profil ENUM taper sur la touche 1 , pour modifier les attributs de votre profil taper sur 2, pour configurer de manière automatique votre profil tapez sur 3, pour modifier votre pseudonyme-mot de passe, tapez sur 4, pour accéder à votre journal de modification de votre profil tapez sur 5, etc.).
Si l'abonné ENUM choisit la modification de son profil ENUM à l'étape 150, cette commande est interceptée par le module script ENUM (75) à l'étape 151, suite à la détection du code DTMF par le module de traitement DTMF (54). Le système (50) entre alors dans un dialogue itératif basé sur la diffusion de messages vocaux vers l'abonné ENUM à partir d'un texte généré par le module script ENUM (75) (à l'étape 152) en fonction du contexte et diffusés (à l'étape 153) sous forme vocale par le module de synthèse vocale (55) ou par le module de diffusion de fichiers vocaux concaténés (56). Ce dernier valide les choix proposés en utilisant son clavier DTMF à l'étape 154 et les commandes sont transmises à l'étape 155 vers le script ENUM (75). Par exemple, le dialogue vocal peut être le suivant:
o -> pour modifier l'ordre/préférence de vos services tapez sur 1 , pour modifier les attributs d'un service tapez 2, pour ajouter un service tapez 3, pour supprimer un service tapez 4,etc. o -» 4 o - pour supprimer le numéro de téléphone 0296053859 tapez 1, pour supprimer le numéro de téléphone 0686166924 tapez 2, pour supprimer l'adresse eMail bertrand.dupont@rd.francetelecom.com tapez 3 ,etc. o - 2 o -> Pour valider votre choix tapez 1 , sinon tapez 2 o -» 1 o -> Pour supprimer un service tapez 1 , pour enregistrer vos modifications tapez 2, pour revenir au menu principal tapez sur 0 o -* 2
Lorsque l'abonné ENUM demande la prise en compte des modifications du profil ENUM, le module script ENUM (75) émet une requête de demande de modification à l'étape 156 vers le module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 157 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les DNS secondaire(s) puisse(nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 159, ce qui se traduit par une réponse à la requête de demande de l'étape 160. Le script ENUM (75) intercepte à l'étape 161 le code retour de cette réponse puis génère à l'étape 162 le message de confirmation/infirmation de prise en compte de la modification. Le module de synthèse vocale (55) ou le module de diffusion de fichiers vocaux diffuse cette information vers l'abonné ENUM à l'étape 163. Ce dernier peut alors libérer la communication.
Selon une variante de cette procédure, en réponse aux messages vocaux, l'abonné peut fournir directement une réponse de manière vocale. C'est alors le module de reconnaissance vocale qui détermine le choix ou l'information contenue dans la réponse.
La Fig. 5 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM via l'envoi de SMS depuis des terminaux téléphoniques mobile ou fixe de type GSM, RTC, RNIS ou IP. L'abonné ENUM émet à l'étape 200 un SMS formaté (ex: NΕ.164 + pseudonyme + mot de passe + requête) comme spécifié par le fournisseur de service ENUM (30) depuis un terminal fixe RTC (4) ou RNIS (2) connecté sur le réseau public ou derrière le PABX (3) ou un terminal mobile (6) de type GSM, ou depuis un terminal IP (7), à destination du module SMS (58) de la présente invention. Ce dernier transmet le SMS à l'étape 201 vers le module script ENUM (75). Ces informations sont fournies à l'étape 202 au module d'authentification (73) qui interroge à l'étape 203 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 204 les informations correspondantes au module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans le SMS avec les informations d'authentification contenues dans la base de données. En cas de concordance, le module d'authentification (73) ordonne à l'étape 205 au module script ENUM (75) de traiter la requête contenue dans le SMS. Le script ENUM (75) détecte qu'il s'agit d'une commande de lecture du profil ENUM. Par conséquent, le script ENUM (75) émet une demande d'interrogation à l'étape 206 au module de gestion protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (étape 207) à l'aide d'une requête (DNS Query) le serveur DNS de niveau 0, puis le serveur DNS de niveau 1, à moins que les informations ne soient déjà dans son cache suite à une consultation précédente de ces serveurs. Pour gagner en efficacité, les données d'un serveur DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30) alors le module protocole DNS (32) retourne à l'étape 208 les enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) se charge ensuite de les retransmettre vers le module script ENUM (75) à l'étape 209. Ce dernier analyse et interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type "PI : Tel= 0296053859, P2: Tel=0686166924, P3: eMail= bertrand.dupont@rd.francetelecom.com, P4: url=www.bertranddupont.fr, etc.). Ce texte est envoyé à l'étape 210 vers le module d'envoi de SMS (58) qui envoie le SMS (à l'étape 211) vers le terminal téléphonique à l'origine de la requête (utilisation du Numéro de l'appelant).
L'abonné ENUM émet à l'étape 250 un message SMS formaté (ex: N° E.164 + pseudonyme + mot de passe + type de requête= ECR: PI :tel=0686166924, P2:email=bertrand.dupont@rd.francetelecom.com) comme spécifié par le fournisseur de service ENUM (30) depuis un terminal fixe RTC (4) ou RNIS (2) connecté sur le réseau public ou derrière le PABX (3) ou un terminal mobile (6) de type GSM, ou depuis un terminal IP (7) à destination du module SMS (58) de la présente invention. Ce dernier transmet le message SMS à l'étape 251 vers le module script ENUM (75). Ces informations sont fournies à l'étape 252 au module d'authentification (73) qui interroge à l'étape 253 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 254 les informations correspondantes au module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans le message SMS avec les informations d'authentification contenues dans la base de données. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) qui traite alors la requête contenue dans le SMS. Le script ENUM (75) détecte qu'il s'agit d'une commande de mise à jour du profil ENUM avec des arguments. Le script ENUM (75) vérifie la syntaxe de la commande et, si elle est correcte, émet une demande de mise à jour à l'étape 256 au module de gestion de protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 257 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. Le serveur (31) confirme la mise à jour à l'étape 259, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 260. Le script ENUM (75) intercepte à l'étape 261 le code retour de cette réponse puis génère à l'étape 262 le message de confirmation/infirmation de prise en compte de la modification avant de l'envoyer au module d'envoi de SMS (58) qui se charge d'envoyer le SMS à l'étape 263 vers le terminal téléphonique à l'origine de la requête (utilisation du numéro de l'appelant).
La Fig. 6 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM par le web à partir d'un terminal disposant d'un navigateur web (8).
L'abonné ENUM demande à l'étape 300 le téléchargement de la page web d'accueil du service de gestion du profil ENUM. Celle-ci est retournée à l'étape 301 par le serveur web (63) de la présente invention. Cette page web affiche un formulaire d'authentification à l'abonné ENUM. Celui ci saisit son numéro E.164 puis son pseudonyme et son mot de passe. Ces informations sont transmises à l'étape 302 au serveur web (63) qui lui même les transmet à l'étape 303 au module d'authentification (73). Le module d'authentification (73) interroge à l'étape 304 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 305 les informations correspondantes au module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire web et les informations d'authentification contenues dans la base de données. En cas de concordance, le module d'authentification (73) notifie à l'étape 306 le module serveur web (63) que l'authentification est réussie. Celui-ci émet à l'étape 307, à destination du module script ENUM (75), une requête de lecture du profil ENUM. Par conséquent, le script ENUM (75) émet une demande d'interrogation à l'étape 308 au module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (à l'étape 309) après avoir vérifié si les informations ne sont pas présentes dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2. Pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30), le module protocole DNS (32) retourne à l'étape 310 les enregistrements NAPTR correspondants au module protocole DNS (62). Ce dernier les retransmet vers le module script ENUM (75) à l'étape 311 qui interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type:
Service de priorité 1 Tel: 0296053859 Service de priorité 2 Tel: 0686166924
Service de priorité 3 Mail: b .dupont@rd. ft.com
Service de priorité 4 Web : www.bertranddupont.fr.
Ce texte est envoyé à l'étape 312 vers le module serveur web (63) qui télécharge une page web munie de ces informations à l'étape 313 vers le terminal Web (8) de l'abonné ENUM.
La page web présentée à l'abonné ENUM permet via une interface graphique adaptée d'opérer des modifications de profil ENUM courant: modification des priorités, ajout de service, suppression de service, modification des attributs d'un service, etc. La demande en modification est émise à l'étape 350 à destination du serveur web (63). Ce dernier transmet à l'étape 351 la requête vers le module script ENUM (75) qui se charge de formater la requête conformément aux entrées NAPTR décrites par le protocole ENUM. Le script ENUM (75) émet alors une demande de mise à jour à l'étape 352 au module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 353 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 355, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 356. Le script ENUM (75) intercepte à l'étape 357 le code retour de cette réponse puis génère à l'étape 358 le message de confirmation/infirmation de prise en compte de la modification avant de l'envoyer au serveur web (63) qui se charge de formater la page web de résultat avant de la télécharger à l'étape 359 vers le terminal web (8).
La Fig. 7 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM à partir d'un Minitel. L'abonné ENUM se connecte au service Minitel en utilisant la fonction PAVI
(Point d'Accès Vidéotex) du réseau de France Telecom (appel par exemple du 3615 code ENUM-FT). Le terminal minitel (5) entre alors en session avec le serveur minitel (57) à l'étape 400. Ce dernier active à l'étape 401 le module script ENUM (75) de la présente invention qui génère alors la page d'accueil du service à l'étape 402 et qui est téléchargée à l'étape 403 sur le terminal Minitel (5) de l'abonné ENUM . Cette page Minitel affiche un formulaire d'authentification à l'abonné ENUM. Celui-ci saisit son numéro ENUM E.164 puis son pseudonyme et son mot de passe. Ces informations sont transmises à l'étape 404 au serveur Minitel (57) qui lui même les transmet à l'étape 405 au module script ENUM (75). Ce dernier redirige la requête à l'étape 406 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 407 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. A l'étape 408 les informations d'authentification de la base de données sont transmises au module d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis dans le formulaire Minitel. En cas de concordance, le module d'authentification (73) notifie à l'étape 409 le module script ENUM (75) que l'authentification est réussie. Le module script ENUM (75) émet alors une demande d'interrogation à l'étape 410 au module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (étape 411), après avoir vérifié si les informations ne sont pas présentes dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1 , puis le serveur DNS de niveau 2. De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30), le module protocole DNS (32) retourne (à l'étape 412) les enregistrements NAPTR correspondants. Le module de protocole DNS (62) se charge de les retransmettre vers le module script ENUM (75) à l'étape 413. Ce dernier analyse et interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type:
Service de priorité 1 Tel: 0296053859
Service de priorité 2 Tel : 0686166924
Service de priorité 3 Mail: b.dupont@rd.ft.com
Service de priorité 4 Web www.bertranddupont.fr,
Ce texte est envoyé à l'étape 414 vers le module serveur vidéotex (57) qui se charge de télécharger à l'étape 415 vers le terminal Minitel (5) de l'abonné ENUM .
La page vidéotex présentée à l'abonné ENUM permet via une interface adaptée d'opérer des modifications sur le profil ENUM courant: modification des priorités, ajout de service, suppression de service, modification des attributs d'un service, etc. La requête de mise à jour du profil ENUM est émise à l'étape 450 à destination du serveur vidéotex (57). Ce dernier transmet à l'étape 451 la requête vers le module script ENUM (75) qui se charge de formater la requête conformément aux entrées NAPTR décrites par le protocole ENUM. Le script ENUM (75) émet alors une demande de mise à jour à l'étape 452 au module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 453 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 455, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 456. Le script ENUM (75) intercepte à l'étape 457 le code retour de cette réponse puis génère à l'étape 458 le message de confirmation/infirmation de prise en compte de la modification avant de l'envoyer au serveur vidéotex (57) qui se charge de formater la page vidéotex de résultat avant de la télécharger à l'étape 459 vers le terminal Minitel (5).
La Fig. 8 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM par eMail à partir d'un terminal disposant d'un client eMail (8).
L'abonné ENUM émet un eMail formaté à l'étape 500 à destination du serveur eMail (61). La commande ENUM est par exemple passée dans l'adresse eMail destinataire:
el64-33296053859-login-dupont-password-1234-requete lire@gestion.enum.francetelecom.com
Le module script ENUM (75) dispose d'un client eMail qui vient régulièrement scruter le serveur eMail (61). Lorsque le module script ENUM (75) reçoit à l'étape 501 un eMail comme indiqué ci-dessus, il récupère, soit dans l'entête, soit dans le corps de l' eMail, les arguments fournis puis les transmet à l'étape 502 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 503 la base de données locale ou distante (via une interface ODBC par exemple) en effectuant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 504 les informations d'authentification correspondantes au module d'authentification (73) qui les compare au pseudonyme (login id) et au mot de passe (password) fournis par le client ENUM dans l'eMail. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 505. Par conséquent, le script ENUM (75) émet une demande d'interrogation à l'étape 506 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée en nom de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (étape 507), si toutefois les informations ne sont pas déjà présentes dans son cache suite à une consultation précédente, selon le protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30) alors le module de gestion de protocole DNS (32) retourne à l'étape 508 les enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) se charge de les retransmettre vers le module script ENUM (75) à l'étape 509. Ce dernier analyse et interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type:
Service de priorité 1 Tel: 0296053859
Service de priorité 2 Tel: 0686166924
Service de priorité 3 Mail: b.dupont@rd.ft.com
Service de priorité 4 Web www.bertranddupont.fr.
Ce texte est expédié (étape 510) sous forme d'eMail par le logiciel client eMail intégré dans le module script ENUM vers le module serveur eMail (61) qui se charge de l'envoyer vers l'abonné ENUM.
L'abonné ENUM qui souhaite modifier son Profil ENUM envoie un eMail formaté à l'étape 550 à destination du serveur eMail (61). La commande ENUM est par exemple passée dans l'adresse eMail destinataire, par exemple: el64-33296053859-login-dupont-password-1234-requete-ecrire-Pl-tel-0296053859- P2-tel-0686166924-P3-fax-0296050242@gestion.enum.francetelecom.com
Le client eMail du module script ENUM scrute le serveur eMail (61). Lorsque le module script ENUM reçoit (en 551) un eMail comme indiqué ci-dessus, il récupère, soit dans l'entête, soit dans le corps de l'eMail, les arguments fournis puis les transmet à l'étape 552 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 553 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 554 les informations d'authentification correspondantes et le module d'authentification (73) les compare au pseudonyme et au mot de passe fournis dans l'eMail. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 555. Ce dernier formate la requête conformément aux entrées NAPTR décrites par le protocole ENUM. Le script ENUM (75) transmet alors une demande de mise à jour à l'étape 556 au module de gestion de protocole DNS (62) qui émet une commande DNS UPDATE à l'étape 557 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux- même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 559, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 560. Le module script ENUM (75) intercepte à l'étape 561 le code retour de cette réponse puis génère le message de confirmation/infirmation de prise en compte de la modification. Ce message est expédié (à l'étape 562) sous forme d'eMail par le logiciel client intégré dans le module script ENUM au serveur eMail (61). Ce dernier envoie à l'étape 563 l'eMail en question à l'abonné ENUM qui peut le consulter sur son terminal (8). La Fig. 9 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM par IUU (Information d'Usager à Usager) à partir d'un terminal RNIS (2).
L'abonné ENUM émet à l'étape 600 depuis son terminal RNIS (2) un appel téléphonique contenant l'élément d'information IUU vers l'interface RNIS (51). Il faut rappeler que le champ IUU est actuellement limité à une taille de 32 caractères. La commande ENUM qui est insérée dans le champ IUU ne pourra donc agir que sur un service ENUM à la fois. Par exemple: GetPl-33296053859*dupont#123456: cette requête permet de récupérer les attributs du service ENUM de priorité 1. L'automate d'appel (52) transmet à l'étape 601 le message de demande d'établissement d'appel au module IUU (53) qui va extraire la commande IUU. L'automate d'appel (52) émet à l'étape 652 le message Alerte à destination de l'abonné ENUM de manière à s'autoriser un minimum de temps (temporisation du protocole RNIS avant d'envoyer un message de déconnexion). Le module IUU (53) transmet la commande ENUM à l'étape 603 vers le module script ENUM (75). Ce dernier récupère les arguments ENUM fournis puis les transmet à l'étape 604 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 605 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 606 les informations d'authentification correspondantes au module d'authentification (73) qui les compare avec le pseudonyme et le mot de passe fournis par le client ENUM dans l'IUU. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 607. Par suite, le module script ENUM (75) émet une demande d'interrogation à l'étape 608 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle classique d'un RESOLVER peut interroger (à l'étape 609), après avoir vérifié si les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) le DNS niveau 0 puis le DNS niveau 1, puis le DNS niveau 2 via son module de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un serveur DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30), la pile de protocole DNS (32) retourne à l'étape 610 les enregistrements NAPTR correspondants au module de gestion protocole DNS (62) qui se charge de les retransmettre vers le module script ENUM (75) à l'étape 611. Ce dernier analyse et interprète les enregistrements NAPTR et en fonction du service demandé dans la commande IUU génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type:
Service PI : Tel:0296053859
Ce texte est envoyé à l'étape 612 vers le module IUU (53) qui se charge de formater un message de déconnexion avant de l'envoyer à l'étape 613 au module automate d'appel (52). Ce dernier génère le message de déconnexion RNIS qui contient l'élément d'information IUU et qui est donc transmis à l'étape 614 via le réseau RNIS au terminal (2) de l'abonné ENUM. Ce dernier peut visualiser l'IUU sur l'afficheur de son terminal RNIS (2). L'abonné ENUM qui souhaite modifier son profil ENUM émet à l'étape 650 depuis son terminal RNIS (2) un appel téléphonique contenant l'élément d'information IUU vers l'interface RNIS (51). Par exemple: DelP3-33296053859*dupont# 123456: cette requête permet de supprimer le service ENUM de priorité 3.
L'automate d'appel (52) transmet à l'étape 651 un message de demande d'établissement d'appel au module IUU (53) qui extrait la commande IUU. L'automate d'appel (52) émet à l'étape 652 le message Alerte à destination de l'abonné ENUM de manière à s'autoriser un minimum de temps (temporisation du protocole RNIS avant d'envoyer un message de déconnexion). Le module IUU (53) transmet la commande ENUM à l'étape 653 vers le module script ENUM (75). Ce dernier récupère les arguments fournis puis les transmet à l'étape 654 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 655 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 656 les informations d'authentification correspondantes au module d'authentification (73) qui les compare au pseudonyme et au mot de passe fournis par le client ENUM dans l'IUU. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 657. Etant donné que la modification ne porte pas sur l'ensemble du profil, le script ENUM (75) émet d'abord une demande d'interrogation (à l'étape 658) au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62), qui joue le rôle de RESOLVER, peut interroger (à l'étape 659), après avoir vérifié si les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) le DNS niveau 0, le DNS niveau 1 puis le DNS niveau 2 via son module de protocole DNS (32). Pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30), le module protocole DNS (32) retourne à l'étape 660 les enregistrements NAPTR correspondants au module de gestion de protocole DNS (62). Ce dernier se charge de les retransmettre vers le module script ENUM (75) à l'étape 661. Le script ENUM (75) émet alors une demande de mise à jour en tenant compte de la modification demandée dans le champ IUU à l'étape 662 au module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 663 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 665, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 666. Le script ENUM (75) intercepte à l'étape 667 le code retour de cette réponse puis génère à l'étape 668 le message de confirmation/infirmation de prise en compte de la modification. Ce message est envoyé à l'étape 668 vers le module IUU (53) qui se charge de formater un message de déconnexion avant de l'envoyer à l'étape 669 au module automate d'appel (52). Ce dernier génère à l'étape 670 le message de déconnexion RNIS qui contient l'élément d'information IUU et qui est donc transmis via le réseau RNIS vers le terminal (2) de l'abonné ENUM. Ce dernier peut visualiser l'IUU sur l'afficheur de son terminal RNIS (2). La Fig. 10 illustre schématiquement la procédure d'accès au service de consultation et de modification automatique d'un profil ENUM à partir d'une session web. La tâche consistant à modifier manuellement un profil ENUM peut vite devenir délicate et répétitive. Un automate (dit automate de configuration) est alors utilisé pour effectuer une modification automatique du profil ENUM en fonction du temps et/ou d'autres paramètres. Parmi ces autres paramètres, la localisation de l'abonné peut être retenue si elle est connue du système (50).
L'abonné ENUM demande à l'étape 700 le téléchargement de la page web d'accueil du service de gestion du profil ENUM. Celle-ci est retournée à l'étape 701 par le serveur web (63) de la présente invention. Cette page web affiche un formulaire d'authentification à l'abonné ENUM. Celui-ci saisit son numéro ENUM E.164 puis son login et mot de passe. Ces informations sont transmises à l'étape 702 au serveur web (63) qui lui même les transmet (à l'étape 703) au module d'authentification (73). Le module d'authentification (73) interroge (à l'étape 704) la base de données locale ou distante (70) (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 705 les informations d'authentification correspondantes au module d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire web. En cas de concordance, le module d'authentification (73) notifie à l'étape 706 le module serveur web (63) que l'authentification est réussie. Celui-ci émet à l'étape 707 à destination du module script ENUM (75) une requête en lecture de la configuration automatique pour ce profil ENUM. Le module script ENUM (75) interroge à l'étape 708 la base de données (70) en fournissant en arguments le numéro E.164 de l'abonné ENUM. La base de données (70) retourne à l'étape 709 le programme de gestion automatique du profil au module script ENUM(75). Ce dernier met en forme les informations, par exemple:
Lundi au Vendredi: de 08:30 à 19:00 PI Tel 0296053859 P2 Tel 0686166924
P3 eMail bertrand.dupont@rd.francetelecom.com
P4 fax 0296050242
Lundi au Vendredi: de 19:00 à 08:30 PI Tel 0296916404
P2 eMail bertrand.dupont@rd.francetelecom.com
Samedi et Dimanche: de 00:00 à 23:59 PI Tel 0296916404
P2 Tel 0686166924
P3 eMail b . dupont@ wanadoo . fr
Le module script ENUM (75) transmet les informations formatées à l'étape 710 au serveur web (63) qui se charge de télécharger la page web contenant les informations en clair du programme de configuration du profil ENUM sur le terminal web (8) de l'abonné ENUM.
Cette page web permet la modification du programme de configuration automatique du profil ENUM: modification des horaires, gestion des jours fériés, ajout-suppression de service, modifications des attributs des services, etc. L'abonné ENUM valide la modification du programme à l'étape 750. Le serveur Web (63) transmet ces informations à l'étape 751 vers le module script ENUM (75). Ce dernier extrait les informations, les met en forme selon un format défini avant de les écrire dans la base de données (70), à l'étape 752. Celle-ci prend en compte l'enregistrement du programme et le confirme à l'étape 753 au module script ENUM (75). Ce dernier notifie au serveur web (63) à l'étape 754 la prise en compte de la modification de l'automate de configuration du profil ENUM. Le serveur télécharge à l'étape 755 la page web de confirmation de la modification sur le terminal web (8) de l'abonné ENUM.
La Fig. 11 illustre la procédure de mise à jour automatique par l'automate de configuration des profils ENUM ainsi que la procédure optionnelle de notification de changement de profil vers l'abonné ENUM.
L'automate de configuration (74) scrute régulièrement à l'étape 800 la base de données (70) pour vérifier s'il y a une modification programmée à réaliser (en fonction du jour et de l'heure courants). Si une modification est programmée alors les paramètres de configuration sont retournés à l'étape 801. L'automate de configuration (74) émet une demande d'interrogation à l'étape 802 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM dont le profil est à modifier, transformée sous forme de nom de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle d'un RESOLVER peut interroger (à l'étape 803), si toutefois les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query), le serveur DNS niveau 0, le serveur DNS niveau 1, puis le serveur DNS niveau 2 via son module de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30) alors le module protocole DNS (32) retourne à l'étape 804 les enregistrements NAPTR correspondants au module protocole DNS (62). Ce dernier les retransmet vers l'automate de configuration (74) qui consulte alors (étape 806) la base de données (70) afin de récupérer les modifications à opérer sur le profil ENUM. La base de données retourne (étape 807) le profil à appliquer au module automate de configuration (74). Si une modification est effectivement nécessaire (le profil a pu entre temps être modifié manuellement), l'automate de configuration détermine les modifications à apporter aux enregistrements NAPTR et émet une demande de mise à jour à l'étape 808 au module de gestion de protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 809 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux -même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 811, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 812. Le module automate de configuration (74) intercepte à l'étape 813 le code retour de cette réponse puis génère à l'étape 814 une demande d'écriture dans la base de données (70) pour alimenter le journal des modifications. La base de données (70) confirme l'écriture de l'événement de modification automatique du profil à l'étape 815. Si le service de mise à jour automatique a été configuré pour notifier les modifications automatiques de profil ENUM, l'automate de configuration notifie la mise à jour selon un ou plusieurs des modes suivants :
o dans le cas ou la notification est en mode vocal, l'automate de configuration
(74) notifie l'automate d'appel (52) à l'étape 820, ce qui se traduit par un appel téléphonique vers un téléphone fixe RTC (4), ou RNIS (2), ou IP (7) ou vers un téléphone mobile (6). Les informations et adresses de notification sont stockées dans la base de données (70). L'abonné ENUM répond à cet appel téléphonique à l'étape 822 ou l'appel est aiguillé vers sa messagerie vocale. Le module de synthèse vocale (55) ou le module de diffusion de fichiers vocaux (56) diffuse à l'étape 823 la notification de la modification de profil ENUM, par exemple: "bonjour, votre profil ENUM 33296053859 a été mis à jour aujourd'hui à 19:00 comme suit: service téléphonique vers 0296053859 puis service téléphonique vers 0686166924 puis service eMail vers bertrand.dupont@wanadoo.fr";
o dans le cas ou la notification est en mode SMS, l'automate de configuration (74) avertit le module SMS (58) à l'étape 830 en fournissant le texte du SMS par exemple du type: "Modification de votre profil ENUM 33296053859 le
21/03/2002 à 09:00: tél:0296053859, tél:0686166924,fax:0296050242". Le module SMS (58) transmet à l'étape 840 ce message SMS à destination du terminal téléphonique mobile ou fixe, tel que configuré dans la base de données (70) ;
o dans le cas ou la notification est en mode eMail, l'automate de configuration (74) notifie la mise à jour au serveur eMail (61) (étape 850) à l'aide d'un eMail contenant un texte du type: "Modification de votre profil ENUM 33296053859 le 21/03/2002 à 09:00: tél:0296053859, tél:06861'66924, fax:0296050242". A cette fin, l'automate de configuration dispose d'un client eMail. Le serveur eMail (61) transmet ensuite à l'étape 860 l'eMail en question à l'adresse eMail stockée dans la base de données (70) ; o dans le cas ou la notification est en mode fax, l'automate de configuration (74) notifie au module fax (59) à l'étape 870 en fournissant le texte du fax qui pourrait être de type: "Modification de votre profil ENUM 33296053859 le 21/03/2002 à 09:00: tél:0296053859, tél:0686166924,fax:0296050242". Le module fax (59) transmet à l'étape 880 ce fax à destination du terminal fax
(9) configuré dans la base de données (70).
La Fig. 12 illustre un exemple de procédure de consultation de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP. L'exemple donné en Fig. 12 illustre une consultation via un ordinateur individuel mais il est clair que la consultation peut être réalisée au moyen des autres types de terminaux précédemment envisagés. Ce type de service pourrait notamment être proposé par des entreprises qui souhaiteraient offrir l'accès à un service ENUM à toute ou partie de leurs employés.
L'abonné ENUM demande à l'étape 900 le téléchargement de la page web d'accueil du service de gestion du profil ENUM. Celle-ci est retournée à l'étape 901 par le serveur web (63) du système (50). Cette page web affiche un formulaire d'authentification à l'abonné ENUM. Celui-ci saisit son numéro ENUM E.164 puis son pseudonyme et son mot de passe. Ces informations sont transmises à l'étape 902 au serveur web (63) qui lui même les transmet (étape 903) au module d'authentification (73). Le module d'authentification (73) interroge (étape 904) la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 905 les informations d'authentification correspondantes au module d'authentification (73) qui se charge de les comparer avec le pseudonyme et mot de passe saisis par le client ENUM. En cas de concordance, le module d'authentification (73) notifie à l'étape 906 le module serveur web (63) que l'authentification est réussie. Celui-ci émet à l'étape 907 à destination du module script ENUM (75) une requête de lecture du profil ENUM. Le script ENUM (75) émet une demande d'interrogation à l'étape 908 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle d'un RESOLVER interroge (étape 909), si les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query), le serveur DNS de niveau 0, le serveur DNS de niveau 1, puis le serveur DNS de niveau 2 via son module de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30), le module de gestion de protocole DNS (32) retourne à l'étape 910 le/les enregistrement(s) NAPTR correspondant(s) . Le module de gestion de protocole DNS (62) se charge de les retransmettre vers le module script ENUM (75) à l'étape 911. Ce dernier analyse et interprète le/les enregistrement(s) NAPTR, par exemple:
$ORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. IN NAPTR 100 10 "u"
"ldap+E2U""!Λ.+33296053859$!ldap://ldap.foumisseurA.fr/cn=33296053859!"
Le script ENUM détecte qu'il s'agit d'un service LDAP. Par conséquent, le module script ENUM (75) émet à l'étape 912 à destination du module de gestion protocole LDAP (64) une requête LDAP de demande de connexion vers le serveur LDAP référencé par l'URI "ldap://ldap.fournisseurA.fr". Ce dernier émet à l'étape 913 une requête "Bind" à destination du module protocole LDAP (35) du serveur annuaire LDAP (34) du fournisseur ENUM A (30). Le module protocole LDAP(35) accepte la connexion à l'étape 914. Le module de gestion de protocole LDAP (64) émet alors à l'étape 915 à destination du module protocole LDAP (35) la requête LDAP "Search" en fournissant le numéro E.164 de l'abonné ENUM en argument. Le module protocole LDAP (35) interroge la base de données LDAP (36) à l'étape 916 puis retourne (à l'étape 917) l'ensemble des informations concernant l'abonné ENUM au module protocole LDAP (35) qui lui-même les retourne (étape 918) au module de gestion de protocole LDAP (64). Ce dernier retourne les informations à l'étape 919 au script ENUM (75) qui se charge de les mettre sous une forme compréhensible pour l'abonné ENUM avant de les transmettre (à l'étape 922) vers le serveur web (63). Le serveur télécharge ensuite la page web générée dynamiquement à l'étape 923 sur le terminal web (8) de l'abonné ENUM. En parallèle, le module de gestion de protocole LDAP (64) envoie à l'étape 920 une demande de déconnexion au serveur LDAP (34) via une requête "Unbind". Le module de protocole LDAP (35) confirme la déconnexion à l'étape 921. La Fig. 13 décrit la procédure de modification manuelle de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP. Là encore, une modification de profil ENUM par un terminal autre qu'un PC peut bien entendu être envisagée.
L'abonné ENUM ayant précédemment consulté le contenu de son profil ENUM au moyen de la procédure décrite ci-dessus, peut décider de le modifier. Pour ce faire, il modifie localement dans la page web affichée sur son terminal web (8) les attributs de ses services ENUM, les priorités, ajoute des services ou en supprime. Il valide ses modifications de profil à l'étape 1000 et les informations sont fournies au serveur web (63). Ce dernier transmet l'ensemble de ces informations à l'étape 1001 au module script ENUM (75). Ce dernier émet une demande d'interrogation à l'étape 1002 au module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle d'un RESOLVER peut interroger, si les informations ne sont pas déjà dans son cache suite à une consultation précédente (à l'étape 1003) avec le protocole standard DNS (requête DNS Query) le DNS niveau 0, puis le DNS niveau 1, avant d'interroger le DNS niveau 2 via son module de protocole DNS (32). Pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30) le module protocole DNS (32) retourne à l'étape 1004 le/les enregistrements NAPTR correspondant(s). Le module de gestion de protocole DNS (62) les retransmet alors vers le module script ENUM (75) à l'étape 1005. Ce dernier analyse et interprète le/les enregistrement(s) NAPTR, par exemple :
$ORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. IN NAPTR 100 10 "u"
"ldap+E2U""!Λ.+33296053859$!ldap://ldap.foumisseurA.fr/cn=33296053859!"
Le module script ENUM (75) détecte qu'il s'agit d'un service LDAP. Le module script ENUM (75) émet alors (étape 1006) à destination du module protocole LDAP (64) une requête LDAP de demande de connexion au serveur LDAP référencé par l'URI "ldap://ldap.fournisseurA.fr". Ce dernier émet à l'étape 1007 une requête "Bind" à destination du module protocole LDAP (35) du serveur annuaire LDAP (34) du fournisseur ENUM A (30). Le module protocole LDAP(35) accepte la connexion à l'étape 1008. Le module protocole LDAP(64) émet alors à l'étape 1009 à destination du module protocole LDAP (35) une requête LDAP "Search" en fournissant le numéro E.164 de l'abonné ENUM en argument. Le module protocole LDAP (35) interroge la base de données LDAP (36) à l'étape 1010 puis retourne à l'étape 101 1 l'ensemble des informations concernant l'abonné ENUM au module de gestion de protocole LDAP (35). Ce dernier les retourne à l'étape 1012 vers le module de gestion de protocole LDAP (64) qui lui-même les retourne (étape 1013) au module de script ENUM (75). Celui-ci les compare avec les informations fournies via le web par l'abonné ENUM et détermine l'opération à effectuer au format LDAP et transmet une demande de modification à l'étape 1014 à destination du module de gestion de protocole LDAP (64). Ce dernier envoie une requête LDAP "Modify" à l'étape 1015 à destination du module protocole LDAP (35) qui lui-même émet à l'étape 1016 une demande d'écriture dans la base de données (36). Celle-ci accepte la mise à jour et la confirme (étape 1017) au module protocole LDAP (35). Ce dernier transmet (étape 1018) la confirmation/infirmation de mise à jour au module de gestion de protocole LDAP (64) qui la retourne (étape 1019) au module script ENUM (75). Celui-ci génère alors la page web de confirmation de modification avant de la transmettre au serveur web (63). Le serveur télécharge cette page (étape 1023) au terminal web (8) de l'abonné ENUM. En parallèle, le module protocole LDAP (64) envoie (étape 1020) une demande de déconnexion au serveur LDAP (34) via une requête "Unbind". Le module de protocole LDAP (35) confirme la déconnexion à l'étape 1021.
Bien que la procédure de mise à jour d'annuaire LDAP ait été illustrée pour une procédure « manuelle », il va de soi qu'une mise à jour automatique de l'annuaire LDAP au moyen de l'automate de configuration (74) peut également être envisagée.
Bien que l'invention ait été essentiellement décrite dans le cadre de l'application
« ENUM » et de la mise à jour d'un profil ENUM , il est clair pour l'homme du métier qu'elle peut s'étendre à la mise à jour d'un ou plusieurs enregistrement(s) de ressource(s) (RR) dans un serveur DNS (ou LDAP), tels que définis au paragraphe
3.2.2 du document RFC 1035 précité et repris dans la table ci-après :
Pour un enregistrement de ressource donné, la mise à jour pourra porter sur un ou plusieurs champs de cet enregistrement, tels que définis dans le document RFC 1035 précité.
Il faut noter que si la mise à jour d'enregistrement(s) de ressources autre(s) que NAPTR est envisagée, de nouveaux modules similaires au module « Script ENUM » (75) et « automate de configuration ENUM » (74) doivent être ajoutés pour traiter chacun de ces enregistrements.

Claims

REVENDICATIONS
1) Système de consultation et/ou de mise à jour d'un enregistrement stocké dans une première base de données (33, 36), ledit enregistrement comprenant un ou une pluralité d'enregistrements de ressources (RR), ladite première base de données étant hébergée par un serveur de noms de domaine, dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant être accédé par indirection à partir d'un serveur DNS, caractérisé en ce qu'il comprend : - des moyens de communication (1150, 53-59, 61,63) permettant audit système de recevoir d'un terminal de télécommunication une demande de consultation et/ou de modification dudit enregistrement ou une programmation d'une telle demande ;
- des moyens de contrôle (1175, 74, 75) adaptés à déterminer à partir de ladite demande de consultation et/ou de modification transmise au dit système ou préalablement programmée dans ledit système, un nom de domaine et une opération à effectuer sur ledit enregistrement ;
- des moyens de gestion de protocole (1 162, 62, 64) adaptés à rechercher à partir dudit nom de domaine, l'adresse IP dudit serveur hébergeant ladite première base de données et, en fonction de ladite opération, à transmettre au dit serveur une requête de lecture ou de mise à jour dudit enregistrement.
2) Système selon la revendication 1, caractérisé en ce qu'il comprend des moyens d'authentification (1173, 73) adaptés à authentifier au niveau applicatif l'émetteur de ladite demande à partir d'informations d'authentification stockées dans une seconde base de données (1170,70) locale ou distante.
3) Système selon la revendication 2, caractérisé en ce que, l'émetteur de ladite demande ayant été authentifié, lesdits moyens de gestion de protocole sont adaptés à transmettre une requête en consultation selon le protocole DNS (DNS Query) audit serveur DNS, la requête ayant pour argument ledit nom de domaine, et à recevoir une première réponse dudit serveur.
4) Système selon la revendication 3, caractérisé en ce que la première base de données étant hébergée par ledit serveur DNS, les moyens de contrôle sont adaptés à extraire de ladite première réponse une information contenue dans ledit enregistrement et à la formater pour la transmettre au dit terminal via lesdits moyens de communication.
5) Système selon la revendication 3, caractérisé en ce que, la première base de données étant hébergée par ledit serveur LDAP, les moyens de contrôle sont adaptés à extraire de ladite première réponse l'adresse du serveur LDAP.
6) Système selon la revendication 5, caractérisé en ce que, lesdits moyens de gestion de protocole sont adaptés à transmettre une requête en consultation selon le protocole LDAP (LDAP Search) audit serveur LDAP et à recevoir de celui-ci une seconde réponse.
7) Système selon la revendication 6, caractérisé en ce que les moyens de contrôle sont adaptés à extraire de ladite seconde réponse une information contenue dans ledit enregistrement et à la formater pour la transmettre au dit terminal via lesdits moyens de communication.
8) Système selon la revendication 4, caractérisé en ce que, les moyens de contrôle ayant déterminé une opération de mise à jour, les moyens de gestion de protocole sont adaptés, sur instruction desdits moyens de contrôle, à transmettre une requête en mise à jour selon le protocole DNS (DNS Update).
9) Système selon la revendication 8, caractérisé en ce que les moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur DNS et les moyens de contrôle sont adaptés à formater cette réponse de confirmation infirmation avant d'en ordonner la transmission au dit terminal via lesdits moyens de communication .
10) Système selon la revendication 7, les moyens de contrôle ayant déterminé une opération de mise à jour, les moyens de gestion de protocole sont adaptés, sur instruction desdits moyens de contrôle, à transmettre une requête en mise à jour selon le protocole LDAP (LDAP Modify). 1 1) Système selon la revendication 10, caractérisé en ce que les moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur LDAP et les moyens de contrôle sont adaptés à formater cette réponse de confirmation/infirmation avant d'en ordonner la transmission au dit terminal via lesdits moyens de communication .
12) Système selon la revendication 2, caractérisé en ce que les moyens de contrôle sont adaptés à stocker dans la seconde base de données un profil de configuration transmis via lesdits moyens de communication, ledit profil étant constitué d'une ou plusieurs demandes de modification programmée, chaque demande de modification programmée étant associée à au moins une plage temporelle et/ou une zone géographique.
13) Système selon la revendication 12, caractérisé en ce que lesdits moyens de contrôle comprennent un automate de configuration (74) adapté à scruter ladite seconde base de données et à tester si une mesure de temps appartient à ladite plage et/ou une localisation du terminal appartient à ladite zone, et en cas de résultat positif, à extraire la demande de modification programmée associée et à transmettre aux dits moyens de gestion de protocole une demande de consultation de la première base de données.
14) Système selon la revendication 13, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à formuler ladite requête en consultation selon le protocole DNS (DNS Query) ou LDAP (LDAP Search) et à recevoir, du serveur hébergeant la base de données, le contenu dudit enregistrement.
15) Système selon la revendication 14, caractérisé en ce que si le contenu dudit enregistrement n'est pas conforme à ladite demande de modification programmée, lesdits moyens de contrôle déterminent une opération à effectuer sur ledit enregistrement pour le rendre conforme à ladite demande de modification programmée et lesdits moyens de gestion de protocole formulent, en fonction de ladite opération, une requête de mise à jour de ladite première base de données selon le protocole DNS ou LDAP et l'acheminent vers le serveur hébergeant ladite première base de données. 16) Système selon la revendication 15, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation infirmation de mise à jour du serveur hébergeant la première base de données et que les moyens de contrôle sont adaptés à détecter ladite réponse de confirmation/infirmation et à la stocker sous forme d'historique dans la seconde base de données.
17) Système selon la revendication 16, caractérisé en ce que lesdits moyens de contrôle sont adaptés à recevoir une demande de lecture dudit historique, et après authentification de l'émetteur de ladite demande par lesdits moyens d'authentification, à lui transmettre le contenu dudit historique via lesdits moyens de communication.
18) Système selon la revendication 17, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur hébergeant la première base de données et que les moyens de contrôle sont adaptés à détecter ladite réponse de confirmation/infirmation et à transmettre un compte-rendu de ladite opération à un terminal de notification.
19) Système selon l'une des revendications précédentes, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à utiliser un protocole DNS de type sécurisé (DNSSec).
20) Système selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une interface RTC et/ou RNIS (51) connectant lesdits moyens de communication au réseau RTC/ RNIS.
21) Système selon la revendication 20, caractérisé en ce que lesdits moyens de communication comprennent un module de synthèse vocale (55) ou un module de reproduction de fichiers vocaux (56) permettant de générer un menu vocal, de reproduire une ou des informations dudit enregistrement sous forme vocale, ainsi qu'un module de reconnaissance de signaux DTMF (54) et/ou un module de reconnaissance vocale permettant de reconnaître un choix dans ledit menu vocal. 22) Système selon la revendication 20, caractérisé en ce que lesdits moyens de communication comprennent un serveur vidéotex (57) permettant de générer un menu, de saisir une demande de consultation ou de modification dudit enregistrement et de reproduire une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour sous forme de séquences vidéotex.
23) Système selon la revendication 20, caractérisé en ce que lesdits moyens de communication comprennent un module d'émission/réception de messages SMS (58) permettant de recevoir sous forme de message une demande en consultation ou de modification dudit enregistrement et de transmettre sous forme de message une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour.
24) Système selon la revendication 20 comportant une interface RNIS (51), caractérisé en ce que les moyens de communication comprennent un module d'émission/ réception (53) d'information usager à usager IUU, permettant de recevoir sous forme d'une dite information IUU, une demande en consultation ou de modification dudit enregistrement et de transmettre sous forme d'une dite information IUU une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour.
25) Système selon la revendication 20, caractérisé en ce qu'il comprend un module fax (59) permettant de transmettre une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour.
26) Système selon l'une des revendications 1 à 19, caractérisé en ce qu'il comprend une interface IP (60).
27) Système selon la revendication 26, caractérisé en ce que les moyens de communication comprennent un serveur Web adapté à transmettre un formulaire d'authentification, un formulaire de saisie d'une demande de consultation ou de modification dudit enregistrement, de présenter une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour sous forme de pages Web. 28) Système selon la revendication 26, caractérisé en ce que les moyens de communication comprennent un serveur SMTP adapté à recevoir sous forme d'emails une demande de consultation ou de modification dudit enregistrement et de transmettre sous forme d'emails une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour.
29) Système selon l'une des revendications précédentes, caractérisé en ce que les moyens de contrôle sont adaptés à déterminer ledit nom de domaine à partir d'un identifiant d'abonné.
30) Système selon la revendication 29, caractérisé en ce que ledit identifiant d'abonné est le numéro téléphonique E.164 dudit abonné.
31) Système selon la revendication 29 ou 30, caractérisé en ce que lesdits moyens de contrôle sont adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un enregistrement de ressource de type NAPTR.
32) Système selon l'une des revendications précédentes caractérisé en ce que lesdits moyens de contrôle sont adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un ou plusieurs enregistrements de ressource de type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO,MX, TXT.
EP03760001A 2002-06-14 2003-06-05 Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap Withdrawn EP1514396A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0207510A FR2841072A1 (fr) 2002-06-14 2002-06-14 Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap
FR0207510 2002-06-14
PCT/FR2003/001691 WO2003107627A1 (fr) 2002-06-14 2003-06-05 Systeme de consultation et/ou mise a jour de serveurs dns et/ou d’annuaires ldap

Publications (1)

Publication Number Publication Date
EP1514396A1 true EP1514396A1 (fr) 2005-03-16

Family

ID=29595361

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03760001A Withdrawn EP1514396A1 (fr) 2002-06-14 2003-06-05 Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap

Country Status (7)

Country Link
US (1) US20050182781A1 (fr)
EP (1) EP1514396A1 (fr)
JP (1) JP4336647B2 (fr)
CN (1) CN1663222B (fr)
AU (1) AU2003260575A1 (fr)
FR (1) FR2841072A1 (fr)
WO (1) WO2003107627A1 (fr)

Families Citing this family (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL166717A0 (en) * 2002-08-26 2006-01-15 Computer Ass Think Inc Web services apparatus and methods
JP4384529B2 (ja) * 2004-03-22 2009-12-16 パナソニック株式会社 インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム
JP4469209B2 (ja) 2004-04-12 2010-05-26 パナソニック株式会社 Ｉｐ電話システム、ｉｐ電話装置及び通話方法
JP4377741B2 (ja) * 2004-04-30 2009-12-02 パナソニック株式会社 Ｉｐ電話システム、ｉｐ電話装置及び通話方法
EP1601146A1 (fr) * 2004-05-28 2005-11-30 France Telecom Procédé et dispositif de transfert d'un courrier électronique à un destinataire identifié par un numéro de téléphone
JP4507725B2 (ja) * 2004-07-01 2010-07-21 富士ゼロックス株式会社 情報通信装置
JP4336263B2 (ja) * 2004-07-23 2009-09-30 パナソニック株式会社 Ｉｐ電話システム、ｉｐ電話装置及び通話方法
JP4383280B2 (ja) * 2004-07-28 2009-12-16 パナソニック株式会社 Ｉｐ電話システム、ｉｐ電話装置及び宛先ユーザ識別方法
JP4426920B2 (ja) * 2004-08-04 2010-03-03 パナソニック株式会社 Ｉｐ電話システム、ｉｐ電話装置及び宛先ユーザ識別方法
JP4603914B2 (ja) * 2004-08-06 2010-12-22 パナソニック株式会社 Ｉｐ電話装置及びｉｐ電話システム
JP4516375B2 (ja) * 2004-08-06 2010-08-04 パナソニック株式会社 呼接続制御装置及びｉｐ電話システム
JP4603913B2 (ja) * 2004-08-06 2010-12-22 パナソニック株式会社 Ｉｐ電話装置及びｉｐ電話システム
JP4445421B2 (ja) * 2004-08-26 2010-04-07 パナソニック株式会社 Ｉｐ電話装置、ｅｎｕｍサーバ及びｉｐ電話システム
US20060064397A1 (en) * 2004-09-17 2006-03-23 Yohko Ohtani Network device, service using method, service using program product, and computer-readable recording medium recorded with a service using program
JP4511901B2 (ja) * 2004-10-05 2010-07-28 パナソニック株式会社 Ｉｐ端末装置および通信機能表示方法
JP4516398B2 (ja) 2004-10-05 2010-08-04 パナソニック株式会社 Ｉｐ通信装置および通信サービス選択方法
JP4995416B2 (ja) * 2004-10-05 2012-08-08 パナソニック株式会社 Ｉｐ通信装置およびｉｐ通信方法
JP4535829B2 (ja) * 2004-10-08 2010-09-01 パナソニック株式会社 Ｉｐ通信方法、ｉｐ端末装置、ｅｎｕｍサーバ及びｉｐ通信システム
JP4542872B2 (ja) * 2004-11-02 2010-09-15 パナソニック株式会社 Ｉｐ電話装置及びｉｐ電話システム
CN100556029C (zh) * 2004-12-20 2009-10-28 上海贝尔阿尔卡特股份有限公司 IPv6无状态地址配置中主机的DNS更新方法和装置
CN1805450A (zh) * 2005-01-10 2006-07-19 华为技术有限公司 在域名系统dns机制中实现服务器与客户端数据同步的方法
EP1932330A4 (fr) * 2005-04-12 2011-05-04 Telecomm Systems Inc Passerelle enum temporaire
US7386633B2 (en) * 2005-04-21 2008-06-10 International Business Machines Corporation Priority based differentiated DNS processing
CN1878164A (zh) * 2005-06-08 2006-12-13 华为技术有限公司 E.164号码域名存储和查询方法
JP4683209B2 (ja) * 2005-09-27 2011-05-18 日本電気株式会社 データ提供システム、データ提供方法、サーバ、ネットワークシステムおよびプログラム
FI20051137A0 (fi) * 2005-11-09 2005-11-09 Nokia Corp Menetelmä hajautetun asiankäsittelyn muodostamiseksi ja suorittamiseksi viestintäjärjestelmässä
US7843911B2 (en) * 2005-11-15 2010-11-30 Nominum, Inc. Data grouping approach to telephone number management in domain name systems
US7673336B2 (en) * 2005-11-17 2010-03-02 Cisco Technology, Inc. Method and system for controlling access to data communication applications
US7529231B2 (en) * 2006-01-13 2009-05-05 At&T Intellectual Property L.L.P. Routing methods and systems using ENUM servers internal and external to a service provider network
ATE411696T1 (de) * 2006-03-15 2008-10-15 Nero Ag System zur eindeutigen identifizierung und erreichen von voip nutzern
DE102006012310A1 (de) * 2006-03-17 2007-09-20 Deutsche Telekom Ag Verfahren und Vorrichtung zur Policy basierten multiplen ENUM Domain Auflösung mittels modifizierten DNS Resolver
WO2007132108A2 (fr) * 2006-05-15 2007-11-22 France Telecom Procede de routage pour numeros non standard dans un mecanisme de routage pour numeros standard
US9130990B2 (en) * 2006-05-17 2015-09-08 Orange Server and method for managing domain names in a network using a zone file with a rule partitioning subdomains into subzones
US20070283028A1 (en) * 2006-06-01 2007-12-06 Microsoft Corporation Name Challenge Enabled Zones
US8184798B2 (en) * 2006-06-13 2012-05-22 Tekelec Methods, systems and computer program products for accessing number portability (NP) and E.164 number (ENUM) data using a common NP/ENUM data locator structure
US20080046580A1 (en) * 2006-06-29 2008-02-21 Nokia Corporation Account creation system and call processing system
US8400947B2 (en) * 2006-07-20 2013-03-19 Tekelec, Inc. Methods, systems, and computer program products for specifying a particular ENUM service type in a communications network that utilizes a plurality of different ENUM service types
US7656817B2 (en) * 2006-07-28 2010-02-02 Sbc Knowledge Ventures, L.P. Methods and apparatus to provision name-servers
US8036366B2 (en) * 2006-08-04 2011-10-11 Microsoft Corporation Intelligent formatting of VoIP telephone numbers
US8831201B2 (en) * 2006-08-10 2014-09-09 At&T Intellectual Property I, Lp Method and apparatus for managing ENUM records
CN101535990B (zh) * 2006-08-23 2013-05-29 创新解决方案公司 高效的搜索结果更新机制
US8239930B2 (en) * 2006-10-25 2012-08-07 Nokia Corporation Method for controlling access to a network in a communication system
US8862735B1 (en) * 2006-12-05 2014-10-14 Aol Inc. IP address management of multiple DHCP and DNS servers
US8254551B2 (en) * 2006-12-07 2012-08-28 Tekelec, Inc. Methods, systems, and computer program products for providing quality of service using E.164 number mapping (ENUM) data in a communications network
FR2911032B1 (fr) * 2006-12-31 2009-05-22 Radiotelephone Sfr Systeme et procede de gestion de joignabilite via ou moins un reseau de communication
FR2911034B1 (fr) * 2006-12-31 2009-08-21 Radiotelephone Sfr Systeme et procede de gestion de joignabilite via au moins un reseau de communication
FR2911033B1 (fr) * 2006-12-31 2009-08-14 Radiotelephone Sfr Systeme et procede de gestion de joignabilite via au moins un reseau de communication
US20080263389A1 (en) * 2007-04-20 2008-10-23 At&T Knowledge Ventures, L.P. System for monitoring enum performance
US20080270596A1 (en) * 2007-04-25 2008-10-30 Mark Frederick Wahl System and method for validating directory replication
US7996541B2 (en) 2007-06-15 2011-08-09 Tekelec Methods, systems, and computer program products for identifying a serving home subscriber server (HSS) in a communications network
US8538000B2 (en) 2007-08-10 2013-09-17 Tekelec, Inc. Methods, systems, and computer program products for performing message deposit transaction screening
US9258268B2 (en) * 2007-08-27 2016-02-09 At&T Intellectual Property, I., L.P. Methods and apparatus to dynamically select a peered voice over internet protocol (VoIP) border element
US8239422B2 (en) 2007-10-18 2012-08-07 At&T Intellectual Property I, Lp Methods and apparatus to provision network resource records
EP2258128B1 (fr) 2008-03-07 2017-01-11 Tekelec Global, Inc. Procédés, systèmes et supports lisibles sur ordinateur permettant d acheminer un message de service de messagerie dans un réseau de télécommunication
WO2010060087A2 (fr) 2008-11-24 2010-05-27 Tekelec Systèmes, procédés et supports lisibles par ordinateur pour traduction sensible au lieu du numéro de la partie appelée dans un réseau de télécommunications
CN101820351B (zh) * 2009-02-27 2013-08-07 华为技术有限公司 一种用于发现p2p流量优化服务的方法、装置和系统
US20100242037A1 (en) * 2009-03-17 2010-09-23 Microsoft Corporation Software Deployment over a Network
WO2010132436A2 (fr) 2009-05-11 2010-11-18 Tekelec Procédés, systèmes et supports lisibles par ordinateur pour fournir un enregistreur de localisation nominal (hlr) à portabilité du numéro (np) extensible
US9313085B2 (en) 2010-12-16 2016-04-12 Microsoft Technology Licensing, Llc DNS-based determining whether a device is inside a network
US8949411B2 (en) 2010-12-16 2015-02-03 Microsoft Corporation Determining whether a device is inside a network
US8831016B2 (en) 2011-03-18 2014-09-09 Tekelec, Inc. Methods, systems, and computer readable media for configurable diameter address resolution
US8984030B2 (en) * 2011-05-04 2015-03-17 International Business Machines Corporation Journaling and integrity in mobile clouded collaborative spaces
CN102904858B (zh) * 2011-07-26 2017-04-19 中兴通讯股份有限公司 一种ims网络中的数据存储、查询方法
EP2658218A1 (fr) 2012-04-27 2013-10-30 Verisign, Inc. Gestion d'objets de registre en vrac
US8935430B2 (en) 2012-06-29 2015-01-13 Verisign, Inc. Secondary service updates into DNS system
US8976784B2 (en) * 2012-11-29 2015-03-10 At&T Intellectual Property I, Lp Method and apparatus for provisioning a scalable communications network
US9635526B2 (en) 2013-03-15 2017-04-25 Tekelec, Inc. Methods, systems, and computer readable media for utilizing a diameter proxy agent to communicate short message service (SMS) messages
CN103491075B (zh) * 2013-09-09 2016-07-06 中国科学院计算机网络信息中心 动态调整dns递归服务器缓存资源记录的方法和系统
US9203936B2 (en) 2013-10-07 2015-12-01 At&T Intellectual Property I, Lp Method and apparatus for initiating communication sessions
US9191264B2 (en) 2013-10-08 2015-11-17 At&T Intellectual Property I, Lp Method and apparatus for initiating communication sessions
CN103701954B (zh) * 2014-01-03 2017-05-24 中国联合网络通信集团有限公司 一种域名寻址方法及装置
CN104778206A (zh) * 2015-03-10 2015-07-15 小米科技有限责任公司 服务资源的url获取方法及装置
US10404864B2 (en) 2016-06-15 2019-09-03 At&T Intellectual Property I, L.P. Method and apparatus for inter-carrier communications
US10057214B2 (en) * 2016-07-09 2018-08-21 Richard Lamb DNSSEC lightweight database access protocol gateway
US10771453B2 (en) * 2017-01-04 2020-09-08 Cisco Technology, Inc. User-to-user information (UUI) carrying security token in pre-call authentication
US10855647B2 (en) 2017-12-05 2020-12-01 At&T Intellectual Property I, L.P. Systems and methods for providing ENUM service activations
US10819805B2 (en) 2017-12-05 2020-10-27 At&T Intellectual Property I, L.P. Systems and methods for providing ENUM service activations
CN110753044A (zh) * 2019-10-12 2020-02-04 山东英信计算机技术有限公司 一种身份认证方法、系统、电子设备及存储介质
CN110677514A (zh) * 2019-10-21 2020-01-10 怀来斯达铭数据有限公司 一种ip备案信息管理方法及装置
CN112291207B (zh) * 2020-10-16 2022-11-25 武汉中科通达高新技术股份有限公司 一种前端设备目录获取方法及装置
CN113037885B (zh) * 2021-03-02 2022-10-28 牙木科技股份有限公司 视图匹配方法、dns服务器及计算机可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US6154738A (en) * 1998-03-27 2000-11-28 Call; Charles Gainor Methods and apparatus for disseminating product information via the internet using universal product codes

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590274A (en) * 1995-01-23 1996-12-31 Tandem Computers Incorporated Multi-volume audit trails for fault tolerant computers
US5812776A (en) * 1995-06-07 1998-09-22 Open Market, Inc. Method of providing internet pages by mapping telephone number provided by client to URL and returning the same in a redirect command by server
US5878212A (en) * 1995-07-31 1999-03-02 At&T Corp. System for updating mapping or virtual host names to layer-3 address when multimedia server changes its usage state to busy or not busy
US6275490B1 (en) * 1996-08-21 2001-08-14 Netspeak Corporation Method and apparatus for establishing communications from browser application
US6169734B1 (en) * 1996-12-31 2001-01-02 Mci Communications Corporation Internet phone set
US6209036B1 (en) * 1997-06-06 2001-03-27 International Business Machines Corporation Management of and access to information and other material via the world wide web in an LDAP environment
US5968121A (en) * 1997-08-13 1999-10-19 Microsoft Corporation Method and apparatus for representing and applying network topological data
US6052724A (en) * 1997-09-02 2000-04-18 Novell Inc Method and system for managing a directory service
US5974453A (en) * 1997-10-08 1999-10-26 Intel Corporation Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
US6131120A (en) * 1997-10-24 2000-10-10 Directory Logic, Inc. Enterprise network management directory containing network addresses of users and devices providing access lists to routers and servers
US6192362B1 (en) * 1997-12-15 2001-02-20 International Business Machines Corporation System and method for creating a search form for accessing directory information
US6009103A (en) * 1997-12-23 1999-12-28 Mediaone Group, Inc. Method and system for automatic allocation of resources in a network
US6230190B1 (en) * 1998-10-09 2001-05-08 Openwave Systems Inc. Shared-everything file storage for clustered system
US6338082B1 (en) * 1999-03-22 2002-01-08 Eric Schneider Method, product, and apparatus for requesting a network resource
FI107215B (fi) * 1999-08-18 2001-06-15 Elisa Comm Oyj Menetelmä nimiresoluutiopalveluihin liittyvien viiveiden minimoimiseksi
EP1267528A4 (fr) * 2000-03-24 2004-11-17 World Axle Corp Systeme de fourniture d'informations
AU2001259826A1 (en) * 2000-05-03 2001-11-12 Daniel Schoeffler Method of enabling transmission and reception of communication when current destination for recipient is unknown to sender
WO2002015051A1 (fr) * 2000-08-16 2002-02-21 Verisign, Inc. Architecture d'acces a l'internet par nom numerique et/ou nom vocal et methode afferente
US6917612B2 (en) * 2000-09-01 2005-07-12 Telefonaktiebolaged L M Ericsson System and method for address resolution in internet protocol (IP)-based networks
US20020147845A1 (en) * 2001-03-06 2002-10-10 Juan-Antonio Sanchez-Herrero Flexible user distribution between user's serving entities
US8200577B2 (en) * 2001-03-20 2012-06-12 Verizon Business Global Llc Systems and methods for retrieving and modifying data records for rating and billing purposes
US7274683B2 (en) * 2002-01-07 2007-09-25 Motorola, Inc. Method and apparatus for a telecommunications network to communicate using an internet protocol
US7277421B1 (en) * 2002-01-16 2007-10-02 Verizon Services Corp. Telephone call processing using SIP and/or ENUM

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US6154738A (en) * 1998-03-27 2000-11-28 Call; Charles Gainor Methods and apparatus for disseminating product information via the internet using universal product codes

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
AU2003260575A1 (en) 2003-12-31
US20050182781A1 (en) 2005-08-18
CN1663222A (zh) 2005-08-31
WO2003107627A1 (fr) 2003-12-24
CN1663222B (zh) 2012-07-18
FR2841072A1 (fr) 2003-12-19
JP4336647B2 (ja) 2009-09-30
JP2005530252A (ja) 2005-10-06

Similar Documents

Publication Publication Date Title
EP1514396A1 (fr) Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap
US6430174B1 (en) Communication system supporting simultaneous voice and multimedia communications and method of operation therefore
US7962575B2 (en) System and method for data synchronization between devices
EP1590931B1 (fr) Procede de presentation d'etat d'un utilisateur utilisant plusieurs equipements de communication
US20050243993A1 (en) Multi-modal address book
EP1469660B1 (fr) Procédé pour contrôler l'établissement de communications entre terminaux choisis par un utilisateur
BR9715383A2 (pt) Sistema para acessar caixas de correio multimída e mensagens através da internet e via telefone
EP1941705A1 (fr) Procede et systeme de protection d'un lien d'acces a un serveur
US6510455B1 (en) Electronic mail message checking system
US20060215632A1 (en) System and method for migrating messaging services between service platforms
EP1443727A1 (fr) Dispositif de traitement de données pour l'établissement de communications par sélection de terminaux d'utilisateurs en fonction de leur accessibilité
CA2362644A1 (fr) Passerelle de telecommunication entre un reseau prive et un reseau mobile
EP1940133B1 (fr) Système et procédé de gestion de joignabilité via au moins un réseau de communication
EP1378099B1 (fr) Systeme de transmission d'informations a une liste de destinataires
EP1940132B1 (fr) Système et procédé de gestion de joignabilité via au moins un réseau de communication
US20060159237A1 (en) Systems and methods for rendering voice mail contact information available to a called party
EP1820328B1 (fr) Procédé et système de journal unifié des appels
EP2146494B1 (fr) Procédé de gestion de données personnelles multimédia dans un réseau de télécommunications et installation correspondante
EP1135922A1 (fr) Procede d'etablissement d'une communication entre deux terminaux + travers l'internet par un serveur d'appel, terminal et serveur associes
FR2911033A1 (fr) Systeme et procede de gestion de joignabilite via au moins un reseau de communication
WO2006069430A1 (fr) Systemes et procedes permettant de rendre des informations de contact de messagerie vocale disponibles pour un abonne appele
FR2871011A1 (fr) Procede et systeme d'etablissement et de mise a jour d'une base de donnees, utilisation de cette base et terminal de telecommunication
FR2771874A1 (fr) Equipement de liaison multimedia d'acces potentiel a un sous-ensemble de terminaux
WO2006072687A1 (fr) Procede d’acces direct a un service privatif
FR2783993A1 (fr) Systeme et procede de communication entre serveur et telephone vocal

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

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110928

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

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