FR2998127A1 - Procede de resolution d'un numero de telephone porte en un identifiant de ressource reseau - Google Patents

Abstract

L'invention concerne un procédé de résolution par un réseau/domaine, dit domaine d'origine (A), du numéro de téléphone d'un utilisateur, dit appelé, appartenant à un réseau/domaine, dit domaine destinataire (B), comprenant les étapes suivantes : a) un utilisateur, dit appelant, appartenant audit domaine d'origine (A) envoie un message utilisant ledit numéro de téléphone de l'appelé comme identifiant de routage ; b) un serveur du domaine d'origine (A) en charge de router ledit message, ou un serveur DNS (RootA0), engendre une clé d'interrogation fonction du numéro de téléphone et d'un nom de domaine, dit domaine pénultième ; c) une requête DNS est émise vers un serveur DNS (RootA) associé audit domaine pénultième ; d) ledit serveur DNS (RootA) associé au domaine pénultième effectue, au moyen de ladite clé d'interrogation, une recherche dans une base de données ENUM qui lui est associée ; e) ladite recherche fournit au moins un enregistrement CNAME ou DNAME contenant une représentation d'un réseau/domaine, dit domaine de renvoi ; et f) une requête DNS est émise vers ledit domaine de renvoi. Ledit procédé est remarquable en ce que ledit domaine de renvoi comprend ledit domaine destinataire (B), et en ce que ledit numéro de téléphone a été, antérieurement à l'envoi dudit message, porté en relation avec un changement de réseau/domaine de l'appelé.

Description

PROCÉDÉ DE RÉSOLUTION D'UN NUMÉRO DE TÉLÉPHONE PORTÉ EN UN IDENTIFIANT DE RESSOURCE RESEAU La présente invention concerne les réseaux de 5 télécommunications, notamment les réseaux de type IF (« Internet Protocol »). Plus particulièrement, la présente invention concerne l'identification du réseau ou du domaine auquel appartient un utilisateur, sur la base du numéro de téléphone public de cet utilisateur. On dira qu'un utilisateur 10 « appartient » à un certain domaine du réseau d'un opérateur donné lorsque cet utilisateur possède un compte auprès de cet opérateur, et ce, quel que soit le réseau d'accès ou le(s) dispositif(s) utilisés par cet utilisateur pour se connecter au réseau de l'opérateur. On rappelle que le format des numéros de téléphone publics à 15 l'échelle internationale est défini par la recommandation E.164 de l'ITU-T ; l'ITU-T est une partie de FUIT (« Union Internationale des Télécommunications ») chargée de la mise au point de normes internationales. On rappelle également que les réseaux IF permettent le support de 20 services conversationnels, tels que « Voix sur IF » (VolP), « Partage de Contenu », ou « Messagerie Instantanée ». De nos jours, les réseaux IF sont généralement aptes à mettre en oeuvre des protocoles de contrôle de session évolués, tels que H. 323 ou SIP. Le sigle H.323 regroupe un certain ensemble de protocoles de 25 communications audiovisuelles dans un réseau IF, qui ont été mis au point par l'ITU-T. Ils concernent la signalisation, la négociation des paramètres de codage de données, et le transport des données. Ils sont largement utilisés dans la Voix sur IF et dans les conférences vidéo, ainsi 2 9 9 812 7 2 que dans plusieurs applications Internet en temps-réel telles que « NetMeeting ». Le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session ») a été défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS est défini par l'organisme de normalisation 3GPP (« 3rd Generation Partnership Project »). Cette architecture réseau, applicable tant aux réseaux d'accès mobiles que fixes, permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction. Les services de communication sur réseau IP peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères, par exemple un alias H.323 ou une « URI » (initiales des mots anglais « Uniform Resource Identifier» signifiant « Identifiant Uniforme de Ressource »). La syntaxe des URIs est définie dans le document RFC 3986 de l'IETF ; la connaissance de l'URI d'une ressource permet d'obtenir l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource.

En particulier, dans les réseaux mettant en oeuvre le protocole SIP, on distingue deux types d'identifiants de ressource : ceux de la forme « SIP-URI » telle que définie dans la RFC 3261, ou ceux de la forme « telURI » telle que définie dans la RFC 3966. Une SIP-URI est de la forme « sip:user@host » (par exemple, sip:alice@domaine1), où la partie « hast » identifie le domaine de l'opérateur responsable de l'identité représentée par la partie « user ». Une tel-URI est de la forme « tel:numéro_detéléphone » (par exemple, tel:+33123456789) en référence aux numéros de téléphone publics internationaux, ou de la forme « tel:numéro_detéléphone;phone-context=... » (par exemple, te1:0623456789;phone-context=+33) en référence aux numéros de téléphone dont le format n'est valable que dans un contexte plus restreint (dans cet exemple, le format de numéro à dix chiffres 0623456789 n'est valable que dans le plan de numérotation français).

Par souci de brièveté, dans le reste de la présente description, nous appellerons « URI » tout type d'identifiant de ressource applicative physique ou virtuelle accessible sur un réseau. On rappelle également que le système DNS (initiales des mots anglais « Domain Name System » signifiant « Système de Noms de Domaine ») est un service permettant de trouver une information à partir d'un nom de domaine. Les serveurs DNS mettent à la disposition de tout ordinateur-client (« DNS resolver » en anglais) ayant émis une requête DNS des associations nom-de-domaine/information-d'un-certain-type, appelées « enregistrements de ressources » (« resource records » en anglais). En particulier, les enregistrements NAPTR (initiales des mots anglais « Naming Authority Pointer Resource Records » signifiant « Enregistrements de Pointeurs d'Autorité de Nommage »), décrits dans la RFC 3403, spécifient des règles de substitution destinées à être appliquées à une chaîne de caractères dans le but de produire un certain 30 résultat, tel que, notamment, un autre nom de domaine ou une URI. Le système DNS, via les enregistrements NAPTR, permet ainsi de faire correspondre une chaîne de caractères à une autre par le biais d'une recherche de nom de domaine : il suffit, en appliquant une règle propre à l'application concernée, de transformer la chaîne de caractères d'origine en un nom de domaine, auquel sera associée une règle de substitution à appliquer à la chaîne d'origine pour produire le résultat recherché. Pour pouvoir établir une communication via un (ou plusieurs) réseau(x), le réseau/domaine, dénommé « domaine d'origine » ci-après, auquel appartient l'appelant doit donc connaître l'identité du réseau/domaine, dénommé « domaine destinataire » ci-après, permettant de joindre l'utilisateur appelé. Or l'appelant ne connaît bien souvent que le numéro de téléphone de l'utilisateur appelé, ledit numéro de téléphone étant au format public selon la recommandation E.164 ou à un format privé. Malheureusement, ce numéro de téléphone ne permet pas de déterminer facilement l'identité du domaine destinataire ; autrement dit, il n'existe pas d'association automatique entre l'identifiant E.164 et l'URI (ou les URIs) d'entrée du domaine destinataire. On notera à cet égard qu'un domaine peut posséder plusieurs URIs d'entrée, lesquelles peuvent d'ailleurs éventuellement être fonction de l'identité du domaine de l'appelant ; par souci de brièveté, dans le présent document, on désigne occasionnellement par « l'URI du domaine destinataire » le, ou les URI(s) d'entrée de ce domaine. De plus, il est généralement impossible d'identifier le domaine destinataire par la structure du numéro de téléphone (ses premiers chiffres par exemple), car on ne sait pas a priori si ce numéro de téléphone a fait ou non l'objet d'une portabilité. On rappelle à cet égard que l'on appelle « portabilité d'un numéro » (« number portability » en anglais) un changement de l'opérateur ou du domaine hébergeant l'utilisateur associé à ce numéro de téléphone. 2 99 812 7 5 Pour résoudre ce problème, selon une première technique connue, le domaine d'origine route les appels sur la base de tranches de numéros de téléphone, de manière analogue au routage effectué dans le Réseau Téléphonique Commuté (RTC) Public (« Public Switched Telephone 5 Network », ou PSTN, en anglais) ou dans les réseaux commutés mobiles tels que le Réseau Terrestre Mobile Public (« Public Land Mobile Network », ou PLMN en anglais). Mais un tel routage est coûteux en gestion opérationnelle (configuration initiale, plus modifications éventuelles). De plus, notamment dans le cas d'appels internationaux, le 10 domaine d'origine n'a qu'une connaissance partielle de la gestion du plan de numérotage du pays destinataire, ce qui peut imposer des intermédiaires et empêcher d'établir une relation directe entre le domaine d'origine et le domaine destinataire. Ce type de solution nécessite des traitements dédiés, non mutualisables avec les traitements mis en oeuvre 15 pour le routage des URIs alphanumériques, c'est-à-dire des URIs dont la composante « user » (comme « alice » dans sip:alice@domain1) n'est pas un numéro de téléphone, ledit routage utilisant la composante « hast » de l'URI (comme « domain1 » dans sip:alice@domain1). Selon une deuxième technique connue, le domaine d'origine met 20 en oeuvre une application ENUM. L'application ENUM utilise une base de données propre au réseau auquel appartient ce domaine d'origine et qui contient des enregistrements NAPTR particuliers définis dans la RFC 3761. L'application ENUM permet, par requête DNS au moyen d'une clé d'interrogation (telle que décrite ci-dessus) représentative d'un numéro de 25 téléphone au format E.164, de connaître les URIs utilisables pour joindre un correspondant. Ces URIs pointent sur des ressources ou des services associés au numéro E.164 du correspondant comme, par exemple, une adresse e-mail, une page Web, un service d'annuaire, des numéros de renvoi fixes ou mobiles, ou un alias de Voix sur IP, de visiophonie ou de messagerie instantanée pour les protocoles SIP ou H.323.

En pratique, deux cas peuvent se présenter lors de l'interrogation d'une base ENUM. Dans le premier cas, la clé d'interrogation figure bien dans cette base ENUM et l'enregistrement NAPTR correspondant confère la valeur « u » à un paramètre appelé « Flags » (prévu dans la RFC 3761). Cette valeur « u » indique que cette requête ENUM est finale (« terminal » en anglais), en ce sens que la réponse à la requête fournit directement une ou plusieurs URI(s) de l'appelé (en cas de pluralité d'URIs, la réponse fournit d'ailleurs en outre une recommandation quant à leur ordre de traitement). Dans le second cas, la clé d'interrogation ne figure pas dans cette base ENUM. Dans ce cas, le routage ne peut être effectué conformément au mécanisme qui vient d'être décrit, mais nécessite, de manière peu commode, que l'opérateur de ce réseau mette en place un mécanisme ad hoc dédié aux numéros de téléphone inconnus. Ce mécanisme ad hoc, variable d'un opérateur à un autre, peut consister à complexifier les méthodes d'analyse des numéros au niveau des serveurs d'appel, ou à définir une route par défaut, imposant par exemple le transit par le réseau commuté RTC.

On doit notamment recourir à un tel mécanisme ad hoc dans le cas de la portabilité d'un numéro de téléphone, évoquée ci-dessus. Des fonctions ad hoc doivent alors être développées pour intégrer dans les mécanismes de routage standard la détection de la portabilité du numéro d'un réseau/domaine à un autre. Sans cela, un appel vers un numéro antérieurement porté depuis un réseau/domaine vers un autre réseau/domaine aboutirait à un échec. Ce problème de la portabilité concerne tout type d'appel téléphonique, c'est-à-dire toute opération destinée à établir une session réseau (Voix sur IP, vidéoconférence, messagerie instantanée, et ainsi de suite) utilisant à cet effet un numéro de téléphone « appelé ». Plus généralement, ce problème concerne tout message d'un protocole de commande de session (par exemple, SIP ou H.323) utilisant un numéro de téléphone comme identifiant de routage, quelle que soit la finalité de ce message, par exemple l'établissement d'un appel téléphonique, l'ouverture d'une session, la souscription à l'état d'une ressource (message SIP SUBSCRIBE), ou la demande de capacité d'une ressource (message SIP OPTIONS). En effet, « l'utilisateur » associé à un numéro de téléphone servant d'identifiant de routage peut être une personne humaine ou une machine (par exemple, un répondeur téléphonique), mais également un service, ledit service ayant été d'abord hébergé par un premier domaine d'opérateur, puis porté vers un second domaine d'opérateur. Une solution à ce problème pourrait consister à enregistrer dans chaque base de données ENUM l'ensemble des données de portabilité (par exemple, le réseau/domaine actuel auquel appartient l'utilisateur associé au numéro de téléphone), ou tout au moins celles concernant les numéros sortant du réseau considéré ; mais une telle solution aurait de gros impacts sur les processus de gestion des données de portabilité (alimentation, mise à jour, contrôle de cohérence, et ainsi de suite), notamment en raison du fait que les infrastructures DNS gérées par des opérateurs distincts sont de fait séparées et étanches ; cette solution est donc très difficile à mettre en oeuvre en pratique. Une deuxième solution consisterait à faire évoluer les serveurs ENUM en place pour leur intégrer une interface d'interrogation de la base historique de portabilité du numéro. Mais une telle solution est contraire à la logique DNS ; en outre, elle suppose autant de développements que de serveurs ENUM distincts déployés, ce qui rendrait l'opérateur de réseau très dépendant de ses fournisseurs de serveurs ENUM. Le document intitulé « IR.67-DNS/ENUM Guidelines for Service 30 Providers & GRX/IPX Providers », publié le 13 août 2010 par la « GSM Association », propose (cf. notamment l'Annexe C) de considérer chaque numéro porté comme une zone de l'espace de nommage déléguée à l'opérateur preneur. Cela nécessite, pour chaque numéro porté, de stocker des enregistrements d'un type particulier dénommé NS (initiales des mots anglais « Name Server », et qui désigne le serveur de noms faisant autorité dans un domaine) dans le serveur de redirection ainsi que dans le serveur de destination, et des enregistrements supplémentaires de définition de zone du type SOA (initiales des mots anglais « Start Of Authority » signifiant « Début d'Autorité ») dans le serveur de destination.

Un premier inconvénient de cette solution « NS records » est que les opérateurs concernés doivent convenir d'une racine ENUM commune. Un deuxième inconvénient est qu'elle multiplie par trois la quantité d'enregistrements stockés chez l'opérateur preneur ; les licences des industriels de serveurs ENUM pouvant être proportionnelles au volume, cette solution serait extrêmement coûteuse. La présente invention concerne donc une base de données ENUM, contenant au moins un enregistrement CNAME ou DNAME fournissant un domaine de renvoi en réponse à une clé d'interrogation fonction du numéro de téléphone d'un utilisateur, dit appelé. Ladite base de données ENUM est remarquable en ce que ledit appelé appartient audit domaine de renvoi et en ce que ledit numéro de téléphone a été porté en relation avec un changement de réseau/domaine de l'appelé. Ainsi, selon la présente invention, on met en oeuvre une redirection de requêtes DNS au moyen d'enregistrements DNS de types particuliers, appelés CNAME et DNAME (dont la définition sera rappelée ci-dessous). Ces enregistrements, connus de manière générale, permettent de substituer au nom de domaine sur lequel porte la requête DNS un nouveau nom de domaine, dit « domaine de renvoi », qui servira de clé de recherche pour une interrogation subséquente d'une application ENUM.

On sait ainsi vers quel domaine, et avec quelle clé d'interrogation, on peut rediriger une requête DNS afin d'obtenir des informations concernant l'URI actuelle associée à un numéro de téléphone qui a fait antérieurement l'objet d'une portabilité. Le nom de ce domaine de renvoi a été en effet saisi dans ladite base ENUM lors de la procédure de portabilité du numéro de téléphone, c'est-à-dire lorsque l'utilisateur de ce numéro de téléphone a changé de domaine. Grâce à ces dispositions, on peut récupérer, via une interface DNS standard et sans déformer la logique de service DNS ni l'organisation hiérarchique des données qu'elle implique, l'association recherchée entre un numéro de téléphone porté et l'URI d'entrée du domaine (par exemple, le domaine destinataire d'un appel VolP) auquel appartient actuellement l'utilisateur de ce numéro de téléphone porté. Avantageusement, l'invention ne nécessite aucune convention de nommage entre opérateurs. De plus, l'alimentation d'une base de données ENUM requise pour pouvoir mettre en oeuvre l'invention est très simple, et ne nécessite pas de mise à jour fréquente des données, car elle ne manipule pas les données de portabilité elles-mêmes, par nature variables dans le temps, mais des configurations de données, qui sont essentiellement statiques. On notera enfin que, par comparaison avec la solution « NS records » décrite succinctement ci-dessus, la présente invention permet d'avoir des racines DNS séparées et de passer simplement d'un arbre à l'autre. Elle ne requiert donc pas de gérer une racine commune dans un serveur dédié ; elle n'impose pas de délégation de zones chez l'opérateur cédant et n'oblige donc pas à créer de multiples zones dans le serveur de l'opérateur preneur. La présente invention permet ainsi : - une plus grande étanchéité des données car, du point de vue de la cohérence des données, les serveurs DNS entre opérateurs dépendent moins les uns des autres, et - une migration plus facile depuis des serveurs DNS existants déployés de manière autonome par chaque opérateur. La base de données ENUM selon l'invention peut être avantageusement associée à un réseau téléphonique à commutation de circuits fixe ou mobile. Il peut s'agir, par exemple, de la base de données « historique » classiquement utilisée par le RTC. Selon des caractéristiques particulières, ladite base de données ENUM est entièrement dédiée à des numéros de téléphone portés. Grâce à ces dispositions, un opérateur peut commodément, à chaque fois qu'un numéro sortant de son réseau/domaine est porté vers un autre réseau/domaine, enregistrer le nom de cet autre réseau/domaine dans une base de données ENUM dédiée. Selon une autre application avantageuse, le gérant de la base données ENUM y insère des enregistrements CNAME ou DNAME concernant un ensemble de numéros de téléphone respectifs sortant de divers réseaux/domaines respectifs et pour lesquels ce gérant connaît le domaine de renvoi respectif, afin de pouvoir répondre (éventuellement, moyennant finances) à une demande d'information concernant la portabilité d'un numéro de téléphone particulier.

Selon un autre aspect, l'invention concerne un serveur DNS associé à une base de données ENUM telle que décrite succinctement ci-dessus. On notera qu'il est possible de réaliser ces bases de données ENUM et ce serveur DNS dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. Selon encore un autre aspect, l'invention concerne l'utilisation d'une base de données ENUM telle que décrite succinctement ci-dessus. Plus précisément, l'invention concerne un procédé de résolution par un réseau/domaine, dit domaine d'origine, du numéro de téléphone d'un utilisateur, dit appelé, appartenant à un réseau/domaine, dit domaine destinataire, comprenant les étapes suivantes : a) un utilisateur, dit appelant, appartenant audit domaine d'origine envoie un message utilisant ledit numéro de téléphone de l'appelé comme identifiant de routage, b) un serveur du domaine d'origine en charge de router ledit message, ou un serveur DNS, engendre une clé d'interrogation fonction du numéro de téléphone et d'un nom de domaine, dit domaine pénultième, c) une requête DNS est émise vers un serveur DNS associé audit 10 domaine pénultième, d) ledit serveur DNS associé au domaine pénultième effectue, au moyen de ladite clé d'interrogation, une recherche dans une base de données ENUM qui lui est associée, e) ladite recherche fournit au moins un enregistrement CNAME ou 15 DNAME contenant une représentation d'un réseau/domaine, dit domaine de renvoi, et f) une requête DNS est émise vers ledit domaine de renvoi. Ledit procédé est remarquable en ce que ledit domaine de renvoi comprend ledit domaine destinataire, et en ce que ledit numéro de 20 téléphone a été, antérieurement à l'envoi dudit message, porté en relation avec un changement de réseau/domaine de l'appelé. En particulier, ledit message peut être un appel téléphonique, et ledit serveur du domaine d'origine en charge de router le message être un serveur d'appels. 25 On notera que, puisqu'une URI peut le cas échéant identifier un utilisateur d'un réseau non-IF (par exemple, une URI de type « tel: » selon la RFC 3966 peut identifier un utilisateur d'un réseau RTC ou GSM), le procédé selon l'invention s'applique aux messages utilisant comme identifiant de routage un numéro de téléphone qui a été porté depuis un 30 réseau IF ou non-IF, vers un autre réseau IF ou non-IF.

On notera également que, dans le cadre de la présente invention, on désigne par « domaine pénultième », le domaine associé à une base de données ENUM telle que décrite succinctement ci-dessus, c'est-à-dire contenant un enregistrement de type CNAME ou DNAME renvoyant vers le domaine destinataire ; autrement dit, on désigne par « domaine pénultième », le domaine associé au dernier serveur DNS consulté avant la consultation d'un serveur DNS associé au domaine destinataire. Dans certains cas, le serveur DNS du domaine d'origine interrogé en premier lieu par ledit serveur du domaine d'origine en charge de router le message renverra directement vers le domaine destinataire : le domaine pénultième sera alors identique au domaine d'origine. Mais dans d'autres cas (comme illustré ci-dessous dans un exemple de réalisation), plusieurs renvois seront nécessaires, c'est-à-dire que l'on interrogera successivement un ou plusieurs serveurs DNS supplémentaires avant d'interroger (à l'étape c) ci- dessus) le serveur DNS du domaine pénultième : le domaine pénultième ne sera alors pas nécessairement identique au domaine d'origine ; par exemple, ledit domaine pénultième pourrait être un réseau tiers distinct dudit domaine d'origine et dudit domaine destinataire, et dans ce cas le numéro de téléphone de l'appelé pourrait appartenir à une tranche dont l'usage a été délégué à l'opérateur dudit réseau tiers. En tout état de cause, si ces renvois sont corrects, alors il existe, dans un certain domaine de renvoi (le domaine destinataire), une base de données comprenant un enregistrement associant une représentation dudit numéro de téléphone avec une représentation d'un identifiant de ressource (URI) actuel de l'appelé. De manière connue, le « resolver » DNS, c'est-à-dire le serveur du réseau émettant une nouvelle requête DNS peut être, de manière récursive, le serveur DNS qui vient d'être interrogé, ou, de manière itérative, le serveur du domaine d'origine en charge de router le message.

Les avantages offerts par ces procédés sont essentiellement les mêmes que ceux offerts par les bases de données ENUM succinctement décrites ci-dessus. L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de résolution d'un numéro de téléphone succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1 montre des exemples d'enregistrements NAPTR classiques, - la figure 2 illustre schématiquement les étapes successives d'un 20 procédé de résolution d'un numéro de téléphone porté, selon un mode de réalisation de l'invention, - la figure 3a montre un premier enregistrement obtenu lors de la mise en oeuvre de ce mode de réalisation, - la figure 3b montre un deuxième enregistrement obtenu lors de la 25 mise en oeuvre de ce mode de réalisation, et - la figure 3c montre un troisième enregistrement obtenu lors de la mise en oeuvre de ce mode de réalisation. Comme mentionné ci-dessus, les enregistrements NAPTR spécifient comment produire une URI à partir d'une chaîne de caractères 30 d'origine dont est dérivée une clé d'interrogation ayant la forme d'un nom de domaine, sur lequel porte la requête DNS. Cette chaîne de caractères d'origine est appelée AUS (initiales des mots anglais « Application Unique String » signifiant « Chaîne de caractères pour Application Unique »). On dit aussi, de manière équivalente, que les enregistrements NAPTR représentent des règles de « réécriture » à appliquer à une AUS. Les paramètres des enregistrements NAPTR sont : 1. « Order » : indique dans quel ordre évaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une même valeur de « Order » à examiner, les enregistrements des valeurs suivantes de « Order » n'entrent pas en considération ; 2. « Preference » : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même valeur de « Order » ; 3. « Flags » : indique par exemple si l'enregistrement décrit une réécriture transitoire (dont le résultat est un nom de domaine pointant sur un autre enregistrement) ou une réécriture finale ; la sémantique précise du paramètre « Flags » dépend de l'application DDDS employée (DDDS sont les initiales des mots anglais « Dynamic Delegation Discovery System » signifiant « Système Dynamique de Découverte de Délégation » ; ce système est décrit dans la RFC 3401) ; 4. « Services » : décrit le service de réécriture ; la sémantique précise de ce paramètre dépend également de l'application DDDS employée ; 5. « Regexp » : l'opération de réécriture elle-même, formalisée en une expression régulière ; cette expression régulière est à appliquer à l'AUS ; ce paramètre ne peut être fourni en même temps que le paramètre « Replacement » ; 6. « Replacement » : nom de domaine devant faire l'objet d'une prochaine requête DNS, et permettant par exemple une réécriture transitoire par délégation ; ce paramètre ne peut être fourni en même temps que le paramètre « Regexp ». La fonction ENUM constitue, justement, une application DDDS particulière, dans laquelle l'AUS est constituée par un numéro de téléphone. Il est notamment prévu, dans le cas de l'application ENUM, que : - le paramètre « Flags » ne peut prendre que les valeurs « u » ou « » (vide), et - la valeur de « Services » spécifie le type de l'URI résultante (par exemple, SIP-URI, ou tel-URI, ou encore adresse email). On va rappeler à présent quelques généralités sur la notion de nom de domaine. Un nom de domaine identifie un noeud de réseau, notamment un réseau IF. Chaque noeud possède un ensemble (éventuellement vide) d'informations de ressources. L'ensemble d'informations de ressources associé à un nom donné est composé « d'enregistrements de ressources » (« Resource Records », ou RR, en anglais). Chaque RR contient notamment : - le « propriétaire » de ce RR, qui est le nom du domaine dans lequel se trouve le RR, - le « type » de ce RR, qui est un champ d'informations complémentaires composé de chaînes de caractères binaires et de noms de domaines, par exemple : - une adresse IF, ou - un CNAME (acronyme des mots anglais « canonicat name » signifiant « nom canonique »), décrit plus en détail ci-dessous, ou - un DNAME (acronyme des mots anglais « non-terminal DNS name redirection », signifiant « redirection transitoire de nom DNS »), également décrit plus en détail ci-dessous, ou - un PTR, qui est un pointeur vers d'autres données dans le système DNS, ou encore - un serveur NS ou une zone SOA, mentionnés ci-dessus, et - une « classe », qui spécifie un protocole particulier, par exemple l'Internet (désigné par IN). Dans les systèmes IF existants, les hôtes ainsi que d'autres ressources utilisent souvent plusieurs noms pour identifier la même ressource. Par exemple, les noms orange.com et orange-ftgroup.arpa pourraient identifier le même hôte. De même, dans le cas des boîtes aux lettres électroniques, beaucoup d'organisations fournissent plusieurs noms qui se rapportent en fait à la même boîte aux lettres. La plupart de ces systèmes ont pour principe que l'un de ces noms équivalents est le nom canonique ou primaire, et que tous les autres sont des pseudonymes. Le système DNS met en oeuvre ce principe, comme expliqué dans les documents RFC 1034 et 1035 de l'IETF pour le CNAME, et dans le document RFC 6672 de l'IETF pour le DNAME. Un RR de type CNAME/DNAME identifie le nom de son propriétaire comme un pseudonyme, et spécifie le nom canonique correspondant dans une section du RR appelé RDATA.

Les RR CNAME et DNAME ont en commun le fait qu'une interrogation d'un tel RR renvoie des données correspondant à un nom de domaine différent du nom de domaine faisant l'objet de l'interrogation. La différence entre ces deux types d'enregistrements de ressources est qu'un RR CNAME redirige des requêtes DNS présentées au propriétaire de l'enregistrement vers un autre nom (unique), tandis qu'un RR DNAME redirige des requêtes DNS présentées à un descendant du propriétaire de l'enregistrement vers des noms correspondants sous un autre noeud (unique) de l'arbre. Autrement dit, un RR DNAME redirige une interrogation d'une partie de l'arbre de noms du système DNS vers une autre partie de l'arbre de noms du système DNS.

Quand un serveur DNS ne réussit pas à trouver le RR souhaité dans l'ensemble de ressources associé au nom de domaine, il vérifie si l'ensemble de ressources consiste en un enregistrement CNAME ou DNAME avec une « classe » correspondante. Si c'est le cas, le serveur DNS inclut cet enregistrement dans sa réponse, et reprend la recherche au niveau du nom de domaine indiqué dans le champ RDATA de l'enregistrement de CNAME/DNAME. Par exemple, supposons que l'on effectue une recherche dans une zone pour le nom de domaine « foo.example.com », et que l'on trouve un 10 enregistrement de ressources de type DNAME concernant « example.com », cet enregistrement indiquant que toutes les interrogations concernant « example.com » doivent être redirigées vers « example.net ». Le processus de requête DNS retournera à son point de départ, mais avec la nouvelle clé d'interrogation « foo.example.net » ; si la 15 clé d'interrogation initiale avait été par exemple « www.foo.example.com », la nouvelle clé d'interrogation aurait été « www.foo.example.net ». Les serveurs DNS doivent être suffisamment bien conçus pour réagir correctement quand on leur présente une chaîne de 20 CNAME/DNAME, ou bien une boucle : ils sont censés pouvoir suivre les CNAME/DNAME en chaîne, et signaler les boucles de CNAME/DNAME comme étant des erreurs. On va décrire à présent, à titre d'exemple, les étapes classiques d'un procédé d'appel téléphonique vers un numéro de téléphone 25 enregistré dans une base ENUM d'un réseau contenant un domaine IF auquel appartient l'appelant. Lors d'une étape El, un abonné - appelons-le « Alice », appartenant à un domaine IF, dit « domaine d'origine » A, place (via un réseau d'accès quelconque) un appel téléphonique vers un abonné - 30 appelons-le « Bernardo », identifié par un numéro E.164. En vertu des protocoles de commande de session utilisés dans les réseaux IP, le routage de cet appel requiert la connaissance de l'URI d'entrée du domaine IP, dit « domaine destinataire » B, auquel appartient Bernardo. Lors d'une étape E2, l'appel émis par Alice est reçu par un serveur d'appels de l'opérateur A gérant le domaine d'origine A. Prenons par exemple le cas où le domaine d'origine A est, ou est inclus dans, un réseau de type IMS - auquel cas le serveur d'appels est généralement constitué par un serveur S-CSCF ; on rappelle à cet égard que les réseaux IMS comprennent un ou plusieurs serveurs appelés « S-CSCF » (initiales des mots anglais « Serving-Cali Session Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), qui sont aptes (entre autres fonctions) à gérer la procédure d'enregistrement des utilisateurs sur le réseau Lors d'une étape E3, ce serveur S-CSCF, ayant déterminé que le numéro appelé est conforme à la norme E.164, effectue une conversion de ce numéro en une expression constituant un nom de domaine, et qui va permettre, en tant que clé d'interrogation, une recherche de l'URI attachée à l'appelé Bernardo dans une base de données ENUM d'un serveur DNS du domaine d'origine A. Ensuite, le serveur S-CSCF émet une requête contenant cette clé d'interrogation vers ce serveur DNS. Par exemple, à partir du numéro E.164 « +33123456789 » de Bernardo, le serveur S-CSCF construit, en inversant l'ordre des chiffres, l'expression « 98765432133 », puis, en insérant des points entre chaque paire de chiffres successifs, l'expression « 9.8.7.6.5.4.3.2.1.3.3 ». Ensuite, cette dernière expression est concaténée à un nom de domaine prédéfini - appelons-le « racine », pour obtenir l'expression « 9.8.7.6.5.4.3.2.1.3.3.racine ». La RFC 3761 définit la valeur de « racine » comme étant « e164.arpa. » pour les serveurs DNS à usage public ; il est permis, pour les serveurs DNS à usage privé, de définir sa propre racine.

Lors d'une étape E4, après réception de la requête par le serveur DNS, la fonction ENUM effectue une recherche dans sa base de données au moyen de la clé d'interrogation «9.8.7.6.5.4.3.2.1.3.3.racine ». Dans le cas où « racine » est « e164.arpa. », ces enregistrements peuvent être, par exemple, ceux illustrés sur la figure 1. Dans chacun de ces trois enregistrements, la valeur « u » du paramètre « Flags » indique que l'on sait substituer une URI à la clé d'enregistrement. Ainsi, pour ce numéro de téléphone « +33123456789 » : le premier enregistrement permet d'obtenir la SIP-URI « sip:bernardo@b.com », le deuxième enregistrement permet d'obtenir l'URI « h323:bernardo@example1.com » associée à un réseau H.323, et le troisième enregistrement permet d'obtenir l'adresse email « mailto:bernie@example2.com ». Lors d'une étape E5, ces URIs sont envoyées au serveur d'appels (ici, serveur S-CSCF) du domaine d'origine A, en réponse à la requête DNS. Enfin, lors d'une étape E6, la demande d'établissement d'appel est routée, de préférence (compte tenu des valeurs des paramètres « Order » et « Preference »), vers un autre serveur SIP associé au domaine « b.com ». Ce serveur SIP, qui constitue le point d'entrée vers le réseau associé au nom de domaine « b.com », est généralement un serveur I-CSCF (initiales des mots anglais « Interrogating-Cali Session Control Function » signifiant « Fonction de Commande de Session d'Appels Interrogatrice ») dans le cas d'un réseau IMS. Dans le procédé que l'on vient de décrire, il a été supposé que le numéro de téléphone « +33123456789 » figurait dans la base de données ENUM du serveur racine. En revanche, si ce numéro était un numéro porté, il serait, selon l'état de l'art, absent de la base de données ENUM, 2 99812 7 20 et par conséquent le serveur d'appels ne recevrait aucune URI en réponse à sa requête DNS, à moins que, comme expliqué ci-dessus, des dispositions particulières (éminemment complexes à mettre en oeuvre) n'aient été prises à cet égard par l'opérateur du domaine d'origine A. 5 On va décrire à présent, selon un mode de réalisation de la présente invention illustré schématiquement sur la figure 2, les étapes d'un procédé d'appel téléphonique, dans le cas où le numéro de téléphone « +33123456789 » appelé est un numéro porté. A titre d'exemple, on suppose ici que, dans ce numéro de téléphone, la série de 10 chiffres « +3312345» correspond à une tranche de numéros attribuée à l'opérateur A en tant que NDC (initiales des mots anglais « National Destination Code » signifiant « Code de Destination National »), et que les chiffres « 6789 » de ce numéro de téléphone sont associés spécifiquement à Bernardo en tant que SN (initiales des mots anglais 15 « Subscriber Number » signifiant « Numéro d'Abonné »). Lors d'une étape E'0, Bernardo ayant quitté le domaine auquel il appartenait (qui n'est pas nécessairement le domaine d'origine A) avec portabilité du numéro, et l'opérateur du domaine d'origine A en ayant été informé, cet opérateur a créé un enregistrement correspondant, décrit ci- 20 dessous en référence à la figure 3b. On met alors en oeuvre des étapes El , E'2 et E'3, qui sont respectivement analogues aux étapes El, E2 et E3 ci-dessus. Dans l'exemple considéré, la valeur (privée) de « racine » est « e164.RootA0 ». Ensuite, lors d'une étape E'4-a, la fonction ENUM du serveur racine 25 effectue une recherche dans sa base de données au moyen de la clé d'interrogation « 9.8.7.6.5.4.3.2.1.3.3.e164.RootA0 », et y trouve l'enregistrement de la figure 3a. Cette figure 3a montre un exemple d'enregistrement DNAME pour un numéro de téléphone français, dont l'effet est que toute requête DNS 30 concernant un nom de domaine sous 3.3.e164.RootA0 est redirigée vers un serveur DNS (ou une application émulant les fonctionnalités d'un serveur DNS) - appelons-le RootA - associé au domaine d'origine A et chargé des numéros de téléphone commençant par « +33 ». Autrement dit, au vu de l'indication « DNAME » en tant que type du RR et grâce au champ RDATA du RR, la fonction ENUM en déduit que la recherche doit se poursuivre en utilisant un domaine de renvoi, à savoir « 3.3.e164.RootA.fr ». Il importe de noter que l'on considère en l'occurrence une base de données ENUM contenant un enregistrement de type DNAME, alors que les bases de données ENUM classiques ne contiennent généralement que des enregistrements de type NAPTR. On connaît toutefois, d'après la RFC 5527 de l'IETF, une proposition visant un cas particulier d'enregistrement de type DNAME dans une base ENUM : dans l'hypothèse où les opérateurs de VolP se mettraient à construire une arborescence unique, appelée 1-ENUM (« Infrastructure ENUM »), ledit enregistrement de type DNAME permettrait, en attendant la fin de cette construction, de renvoyer les requêtes DNS concernant le domaine « e164.arpa » vers un serveur DNS appartenant à cette arborescence unique ; un tel enregistrement de type DNAME pourrait alors être associé à une chaîne itérative d'enregistrements de type CNAME. Lors d'une étape E'5-a, ces informations sont envoyées au serveur d'appels (ici, serveur S-CSCF) du domaine d'origine A, en réponse à la requête DNS. Lors d'une étape E'4-b, le serveur d'appels émet une nouvelle requête DNS auprès du serveur DNS RootA, au moyen de la clé d'interrogation « 9.8.7.6.5.4.3.2.1.3.3.e164.RootA.fr ». Ce serveur DNS trouve alors dans sa base de données ENUM un enregistrement de type CNAME, illustré sur la figure 3b, contenant, dans son champ RDATA, l'expression « 9.8.7.6.5.4.3.2.1.3.3.RootB.fr », qui fournit un domaine de renvoi « RootB.fr » géré par un opérateur B. 2 99 812 7 22 Il importe de noter que l'on considère en l'occurrence une base de données ENUM contenant un enregistrement de type CNAME, alors que, comme rappelé ci-dessus, les bases de données ENUM classiques ne contiennent généralement que des enregistrements de type NAPTR. 5 Lors d'une étape E'5-b, ces nouvelles informations sont envoyées au serveur d'appels (ici, serveur S-CSCF) du domaine d'origine A. Lors d'une étape E'4-c, le serveur d'appels effectue, au moyen de la clé d'interrogation «9.8.7.6.5.4.3.2.1.3.3.RootB.fr », une recherche dans les enregistrements du serveur DNS de l'opérateur B, et y trouve 10 l'enregistrement illustré sur la figure 3c. Cet enregistrement, de type NAPTR, fournit une SIP-URI actuelle de Bernardo, à savoir « sip:bernardo@b.com », de manière analogue à l'étape E4 décrite ci-dessus. On notera que, dans cet exemple de réalisation, la base de 15 données ENUM du serveur DNS RootA est une base de données ENUM selon l'invention puisqu'elle contient un enregistrement de type CNAME renvoyant vers le domaine destinataire B. Comme ce serveur est associé au domaine d'origine A, ce domaine d'origine A est ici un « domaine pénultième » au sens de l'invention. 20 Lors d'une étape E'5-c, cette URI est envoyée au serveur d'appels (ici, serveur S-CSCF) du domaine d'origine A, de manière analogue à l'étape E5 décrite ci-dessus. On met enfin en oeuvre une étape E'6, qui est analogue à l'étape E6 décrite ci-dessus. 25 Ainsi, grâce à l'invention, Alice a pu, de manière transparente pour elle, joindre Bernardo, qui avait pourtant changé de domaine avec portabilité du numéro. De plus, ce résultat est obtenu avec des moyens très simples à mettre en place pour l'opérateur du domaine d'origine. Dans l'exemple de réalisation que l'on vient de décrire, il a été 30 supposé que, dans le numéro de téléphone « +33123456789» appelé, la série de chiffres « +3312345 » correspond à une tranche de numéros attribuée à l'opérateur A, et qu'à l'étape E'4-b on interroge le serveur DNS RootA du domaine d'origine A chargé des numéros commençant par « +33 ».

En variante, supposons que la tranche (par exemple, « +3312345 ») ait été déléguée à un réseau tiers (par exemple, « lambda.fr »), c'est-à-dire un réseau autre que ceux des domaines d'origine A et destinataire B. Dans un tel cas, la consultation à l'étape E'4- a du serveur racine du domaine d'origine A découvre un enregistrement DNAME renvoyant vers ce réseau tiers, et l'on interroge à l'étape E'4-b une base ENUM associée à ce réseau tiers au moyen d'une clé d'interrogation appropriée (par exemple, « 9.8.7.6.5.4.3.2.1.3.3.operateurlambda.fr »). Ainsi, dans le cas où l'on ne connaît pas, pour des numéros de téléphone appartenant à des tranches attribuées à un réseau tiers (par exemple dans le cas d'un appel international), quels numéros ont été portés et, le cas échéant, vers quels domaines, on peut avantageusement, par cette redirection et ce changement de nom de domaine, résoudre un numéro de téléphone porté, sans se préoccuper de la façon dont le réseau tiers gère ses données (base de type ENUM ou non, avec une même racine ou non), et ce, malgré une arborescence non partagée. Le cas échéant, ce réseau tiers pourra être un « domaine pénultième » au sens de l'invention. Dans la description ci-dessus, on a considéré l'exemple d'un appelant raccordé à un réseau IMS, et par conséquent d'un serveur S- CSCF comme serveur d'appel émettant une requête DNS. Plus généralement, l'invention s'applique évidemment à tout serveur d'appel susceptible d'émettre une requête DNS, par exemple une passerelle de bordure (« Border Gateway » en anglais), ou une passerelle d'interfonctionnement avec le RTC, ou encore une plate-forme de service disposant de fonctions de routage.

L'invention peut être mise en oeuvre au sein d'un noeud d'un réseau ou domaine, notamment au sein d'un serveur DNS, au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre de l'un quelconque des procédés de résolution d'un numéro de téléphone selon l'invention. En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de résolution d'un numéro de téléphone selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.

Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB (« USB flash drive » en anglais) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés de résolution d'un numéro de téléphone selon l'invention.

Claims (10)

1. REVENDICATIONS1. Base de données ENUM, contenant au moins un enregistrement CNAME ou DNAME fournissant un domaine de renvoi en réponse à une clé d'interrogation fonction du numéro de téléphone d'un utilisateur, dit appelé, caractérisée en ce que ledit appelé appartient audit domaine de renvoi et en ce que ledit numéro de téléphone a été porté en relation avec un changement de réseau/domaine de l'appelé.
2. 2. Base de données ENUM selon la revendication 1, caractérisée 10 en ce qu'elle est associée à un réseau téléphonique à commutation de circuits fixe ou mobile.
3. 3. Base de données ENUM selon la revendication 1 ou la revendication 2, caractérisée en ce qu'elle est entièrement dédiée à des numéros de téléphone portés. 15
4. 4. Serveur DNS, caractérisé en ce qu'il est associé à une base de données ENUM selon l'une quelconque des revendications 1 à 3.
5. 5. Procédé de résolution par un réseau/domaine, dit domaine d'origine (A), du numéro de téléphone d'un utilisateur, dit appelé, appartenant à un réseau/domaine, dit domaine destinataire (B), 20 comprenant les étapes suivantes : a) un utilisateur, dit appelant, appartenant audit domaine d'origine (A) envoie un message utilisant ledit numéro de téléphone de l'appelé comme identifiant de routage, b) un serveur du domaine d'origine (A) en charge de router ledit 25 message, ou un serveur DNS (RootA0), engendre une clé d'interrogation fonction du numéro de téléphone et d'un nom de domaine, dit domaine pénultième,C) une requête DNS est émise vers un serveur DNS (RootA) associé audit domaine pénultième, d) ledit serveur DNS (RootA) associé au domaine pénultième effectue, au moyen de ladite clé d'interrogation, une recherche dans une base de données ENUM qui lui est associée, e) ladite recherche fournit au moins un enregistrement CNAME ou DNAME contenant une représentation d'un réseau/domaine, dit domaine de renvoi, et f) une requête DNS est émise vers ledit domaine de renvoi, ledit procédé étant caractérisé en ce que ledit domaine de renvoi comprend ledit domaine destinataire (B), et en ce que ledit numéro de téléphone a été, antérieurement à l'envoi dudit message, porté en relation avec un changement de réseau/domaine de l'appelé.
6. 6. Procédé de résolution d'un numéro de téléphone selon la revendication 5, caractérisé en ce que ledit message est un appel téléphonique, et ledit serveur du domaine d'origine (A) en charge de router le message est un serveur d'appels.
7. 7. Procédé de résolution d'un numéro de téléphone selon la revendication 5 ou la revendication 6, caractérisé en ce que ledit domaine pénultième est un réseau tiers distinct dudit domaine d'origine (A) et dudit domaine destinataire (B), et en ce que ledit numéro de téléphone appartient à une tranche dont l'usage a été délégué à l'opérateur dudit réseau tiers.
8. 8. Procédé de résolution d'un numéro de téléphone selon l'une quelconque des revendications 5 à 7, caractérisé en ce que ledit domaine d'origine (A) est, ou est inclus dans, un réseau de type IP (« Internet Protocol »).
9. 9. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programmeinformatique pour l'exécution des étapes d'un procédé de résolution d'un numéro de téléphone selon l'une quelconque des revendications 5 à 8.
10. 10. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de résolution d'un numéro de téléphone selon l'une quelconque des revendications 5 à 8, lorsqu'il est exécuté sur un ordinateur.