FR2974472A1 - Procede de resolution d'un numero de telephone porte en un identifiant de ressource ip - Google Patents

Abstract

L'invention concerne un procédé de résolution par un domaine IP, dit domaine origine (A), du numéro de téléphone d'un utilisateur, dit appelé, appartenant à un domaine IP, dit domaine destinataire (B), comprenant les étapes suivantes : a) un utilisateur, dit appelant, appartenant audit domaine origine (A) place un appel téléphonique vers ledit numéro de téléphone, b) un serveur d'appels dudit domaine origine (A) émet, après avoir converti ledit numéro de téléphone en une clé d'interrogation appropriée, une requête vers un serveur DNS (NS1) associé au domaine origine (A), c) ledit serveur DNS (NS1) effectue une recherche dans une base ENUM au moyen de ladite clé d'interrogation, d) ladite recherche fournit au moins un enregistrement NAPTR dans lequel : - le champ « Flags » est vide, et - le champ « Replacement », ou le champ « Regexp », contient une représentation d'un domaine IP, dit domaine de renvoi, et e) le serveur DNS (NS1), ou ledit serveur d'appels, émet une requête DNS en direction dudit domaine de renvoi, ledit procédé étant caractérisé en ce que le numéro de téléphone a été, antérieurement audit appel téléphonique, porté lors d'un changement de domaine dudit appelé.

Description

PROCÉDÉ DE RÉSOLUTION D'UN NUMÉRO DE TÉLÉPHONE PORTÉ EN UN IDENTIFIANT DE RESSOURCE IP La présente invention concerne les réseaux de télécommunications de type IP (« Internet Protocol »). Plus particulièrement, la présente invention concerne l'identification du domaine IP auquel appartient un utilisateur, sur la base du numéro de téléphone public de cet utilisateur. On dira qu'un utilisateur joignable via un réseau IP « 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. Le format des numéros de téléphone publics à l'échelle internationale est défini par la recommandation E.164 de l'ITU-T (l'ITU-T est la partie de l'ITU (International Telecommunication Union) chargée de la mise au point de normes internationales). On rappelle également que les réseaux IP permettent le support de services conversationnels, tels que « Voix sur IP » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ». De nos jours, les réseaux IP sont généralement aptes à mettre en oeuvre des protocoles de contrôle de session évolués, tels que H. 323 ou SI P. Le protocole H.323 a été mis au point par l'ITU-T. Il spécifie des procédures concernant la signalisation, la négociation de codeur-décodeur, et le transport de l'information. Il est largement utilisé par les fabricants d'équipements vocaux et de conférences vidéo, ainsi 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 « tel-URI » telle que définie dans la RFC 3966. Une SIP-URI est de la forme « sip:user@host » (par exemple, sip:alice@domainel), 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_de_té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_de_téléphone;phone-context=... » (par exemple, tel: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, 10 nous appellerons « URI » tout type d'identifiant de ressource applicative physique ou virtuelle joignable via un réseau IP. On rappelle à cet égard 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 15 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 » (« resource records » en anglais). En particulier, les enregistrements NAPTR (initiales des mots anglais 20 « 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 (« substitution rule » en anglais) destinées à être appliquées à une chaîne de caractères dans le but de produire un certain résultat, tel que notamment un autre nom de 25 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) IP, le domaine IP auquel appartient l'appelant (dénommé « domaine origine » ci-après) doit donc connaître l'identité du domaine IP permettant de joindre l'utilisateur appelé (dénommé « domaine destinataire » ci-après) ; on notera à cet égard que, dans le cadre de la présente invention, l'utilisateur appelé n'appartient pas nécessairement à un domaine IP. 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. De plus, il est généralement impossible de déterminer ce domaine 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 ce numéro de téléphone. On notera 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. Pour résoudre ce problème, selon une première technique connue, le domaine 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 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 5 éventuelles). De plus, notamment dans le cas d'appels internationaux, le 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 origine et le domaine destinataire. Ce type de solution nécessite des traitements dédiés, non mutualisables avec les traitements mis en oeuvre pour le routage des URIs alphanumériques, c'est-à-dire des URIs dont la composante « user » (comme « alice » dans sip:alice@domainl) n'est pas un numéro de téléphone, traitements qui utilisent la composante « host » de l'URI (comme « domainl » dans sip:alice@domainl).

Selon une deuxième technique connue, le domaine origine met en oeuvre une application ENUM. L'application ENUM utilise une base de données propre au réseau auquel appartient ce domaine origine et qui contient des enregistrements NAPTR particuliers définis dans la RFC 3761. L'application ENUM permet, par interrogation DNS à partir d'une clé d'interrogation (telle que décrite ci-dessus) représentative d'un numéro de 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 indique la valeur « u » pour un paramètre appelé « Flags » (prévu dans la RFC 3761). La 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é, accompagnées d'ailleurs d'une recommandation quant à leur ordre de traitement. La RFC 3761 prévoit en fait que le champ contenant le paramètre « Flags » peut, en variante, être vide (autrement dit, le paramètre « Flags » prend la valeur « »), auquel cas la requête ENUM doit être considérée comme transitoire (« non terminal » en anglais) en ce sens que le client DNS doit théoriquement utiliser le résultat de la requête (constitué par un nom de domaine) comme clé d'interrogation pour une nouvelle requête ENUM ; on notera toutefois que cette option d'un champ « Flags » vide n'est pas utilisée en pratique. 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 de l'IMS la détection de la portabilité du numéro d'un réseau/domaine à un autre. Sans cela, un appel vers un numéro porté depuis un réseau IP vers un autre réseau IP aboutirait à un échec. Une solution à ce problème pourrait consister à enregistrer dans 30 chaque base ENUM l'ensemble des données de portabilité, ou tout au moins celles concernant les numéros sortants 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. La présente invention concerne donc un procédé de résolution par un domaine IP, dit domaine origine, du numéro de téléphone d'un utilisateur, dit appelé, appartenant à un domaine I P, dit domaine destinataire, comprenant les étapes suivantes : a) un utilisateur, dit appelant, appartenant audit domaine origine place un appel téléphonique vers ledit numéro de téléphone, b) un serveur d'appels dudit domaine origine émet, après avoir converti ledit numéro de téléphone en une clé d'interrogation appropriée, une requête vers un serveur DNS associé au domaine origine, c) ledit serveur DNS effectue une recherche dans une base ENUM au moyen de ladite clé d'interrogation, d) ladite recherche fournit au moins un enregistrement NAPTR dans lequel : - le champ « Flags » est vide, et - le champ « Replacement », ou le champ « Regexp », contient une représentation d'un domaine IP, dit domaine de renvoi, et e) le serveur DNS, ou ledit serveur d'appels, émet une requête DNS en direction dudit domaine de renvoi. Ledit procédé est remarquable en ce que le numéro de téléphone a été, antérieurement audit appel téléphonique, porté lors d'un changement de domaine dudit appelé.

On notera que, par souci de brièveté, on désigne dans le présent document au moyen de l'expression « appel téléphonique » 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é ». Au-delà, l'invention s'applique à tout message du protocole de commande de session (par exemple, SIP ou H.323) utilisant comme identifiant de routage un numéro de téléphone, quelle que soit la finalité de ce message, par exemple l'ouverture d'une session ou l'établissement d'un appel téléphonique au sens défini ci- dessus, la souscription à l'état d'une ressource (message SIP SUBSCRIBE), la demande de capacité d'une ressource (message SIP OPTION), et ainsi de suite. On notera également que, puisqu'une URI peut le cas échéant identifier un utilisateur d'un réseau non-IP (par exemple, une URI tel: selon la RFC 3966 peut identifier un utilisateur d'un réseau RTC ou GSM), l'invention s'applique plus généralement aux appels vers un numéro de téléphone qui a été porté depuis un réseau IP ou non-IP, vers un autre réseau I P ou non-IP. On notera enfin que ce procédé est également applicable au cas où le numéro de téléphone appelé est utilisé pour identifier et adresser non plus un utilisateur, mais un service antérieurement hébergé par un premier domaine d'opérateur, puis porté vers un second domaine d'opérateur. Grâce à ces dispositions, on sait vers quel domaine, et avec quelle clé d'interrogation, on peut envoyer une requête DNS afin d'obtenir des informations concernant l'URI actuelle associée à un numéro de téléphone appelé qui a fait l'objet d'une portabilité. Le nom de ce domaine de renvoi a été en effet saisi dans ladite base ENUM lors de la portabilité du numéro de téléphone, c'est-à-dire lorsque l'utilisateur associé à ce numéro de téléphone a changé de domaine.

On notera que, le cas échéant, plusieurs renvois selon l'invention peuvent s'avérer nécessaires pour obtenir l'URI de l'appelé. En tout état de cause, si ce ou ces renvois sont corrects, alors il existe, dans un domaine de renvoi, 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 IP (URI) actuel de l'utilisateur appelé. Ainsi, l'invention propose un moyen simple pour permettre à un serveur ENUM de 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 IP (par exemple, le domaine destinataire d'un appel VoIP) auquel appartient l'utilisateur associé à ce numéro de téléphone.

Avantageusement, l'alimentation de la base ENUM requise pour cet usage est très limitée, et ne nécessite pas de mise à jour fréquente des données, car elle ne manipule pas les données de portabilité du numéro elles-mêmes, par nature variables dans le temps, mais des configurations de données, qui sont essentiellement statiques.

Corrélativement, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, une base de données ENUM, contenant au moins un enregistrement NAPTR dans lequel : - le champ « Flags » est vide, et - le champ « Replacement », ou le champ « Regexp », contient une 25 représentation d'un domaine IP, dit domaine de renvoi. Ladite base de données ENUM est remarquable en ce qu'elle fournit ledit enregistrement NAPTR en réponse à une clé d'interrogation représentant un numéro de téléphone qui a été porté lors d'un changement de domaine de l'utilisateur associé audit numéro de téléphone.

L'invention concerne aussi, deuxièmement, un serveur DNS associé à une base ENUM telle que décrite succinctement ci-dessus. Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. 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 un exemple d'enregistrement NAPTR classique, et - la figure 2 montre un exemple d'enregistrement NAPTR selon un mode de réalisation de l'invention. Comme mentionné ci-dessus, les enregistrements NAPTR spécifient comment produire une URI à partir d'une chaîne de caractères 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 ». 12 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 les étapes classiques d'un procédé d'appel téléphonique vers un numéro de téléphone enregistré dans une base ENUM du réseau contenant le domaine IP auquel appartient l'appelant. Supposons que, lors d'une étape El, un abonné - appelons-le « Alice », appartenant à un domaine IP, dit « domaine origine » A, place (via un réseau d'accès quelconque) un appel téléphonique vers un abonné - 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. Prenons par exemple le cas où le domaine 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'Appels de Service »), 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 (clé d'interrogation) constituant un nom de domaine et qui va permettre une recherche de l'URI attachée à l'appelé Bernardo dans une base de données ENUM d'un serveur DNS, que nous appellerons NS1, du domaine origine A. Ensuite, le serveur S-CSCF émet une requête contenant cette clé d'interrogation vers ce serveur NS1. Par exemple, à partir du numéro E.164 « +33123456789 » de Bernardo, le serveur S-CSCF construit, en inversant l'ordre des chiffres, l'expression « 84306946133 », 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 NS1, la fonction ENUM effectue une recherche dans les enregistrements de la base de données ENUM 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, par exemple, être 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@examplel.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 appelant A, en réponse à sa requête 5 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 10 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 d'Interrogation ») dans le cas d'un réseau IMS. Dans le procédé ci-dessus, il a été supposé que le numéro de 15 téléphone « +33123456789 » figurait dans la base de données ENUM. 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, 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 (d'ailleurs 20 complexes à mettre en oeuvre) n'aient été prises à cet égard par l'opérateur du domaine origine. On va décrire à présent, selon un mode de réalisation de l'invention, 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é. 25 Lors d'une étape E'0, Bernardo ayant quitté le domaine auquel il appartenait (qui n'est pas nécessairement le domaine A) avec portabilité du numéro, et l'opérateur du domaine A en ayant été informé, cet opérateur a créé (au moins) un enregistrement correspondant dans sa base ENUM. Dans le cas, par exemple, où « racine » est « e164.arpa. », 30 cet enregistrement pourrait être celui illustré sur la figure 2.

Ensuite, on met en oeuvre des étapes E'1, E'2 et E'3, qui sont respectivement analogues aux étapes El, E2 et E3 ci-dessus. Lors d'une étape E'4-1, la fonction ENUM du serveur NS1 effectue une recherche dans les enregistrements de la base de données ENUM au moyen de la clé d'interrogation « 9.8.7.6.5.4.3.2.1.3.3.e164.arpa.», et trouve l'enregistrement de la figure 2. On notera que, conformément à l'invention, le champ du paramètre « Flags » y est vide (valeur " "). La fonction ENUM en déduit que la clé d'interrogation doit être remplacée, de manière transitoire, par l'expression indiquée dans le champ « Replacement » ou dans le champ « Regexp », à savoir « 9.8.7.6.5.4.3.2.1.3.3.npdb.orange.fr », dans laquelle « npdb.orange.fr » représente un domaine de renvoi (et non plus une URI). Ce domaine « npdb.orange.fr » est une zone déléguée à un autre serveur DNS (ou une application émulant les fonctionnalités d'un serveur DNS), appelons-le NS2, associé à une base de données dudit domaine de renvoi comprenant - comme l'opérateur du domaine A en a été informé lors de l'étape E'0, des informations concernant le numéro porté « +33123456789 ». Lors d'une étape E'4-2, le resolver DNS (qui peut être, conformément à la norme DNS, le serveur d'appels, de manière itérative, ou le serveur NS1, de manière récursive) du domaine origine A émet une nouvelle requête DNS portant sur le domaine « 9.8.7.6.5.4.3.2.1.3.3.npdb.orange.fr ». La requête parvient de manière itérative ou récursive au serveur DNS NS2.

Lors d'une étape E'4-3, le serveur NS2 effectue, au moyen de la clé d'interrogation «9.8.7.6.5.4.3.2.1.3.3.npdb.orange.fr », une recherche dans les enregistrements de ladite base de données associée, et (supposons) trouve une URI correspondante, de manière analogue à l'étape E4 décrite ci-dessus.

On met enfin en oeuvre des étapes E'5 et E'6, qui sont respectivement analogues aux étapes E5 et E6 décrites ci-dessus. 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 origine. Selon un mode de réalisation, la base de données ENUM selon l'invention fournit un domaine de renvoi prédéterminé en réponse à des clés d'interrogation représentant les numéros de téléphone appartenant à une tranche de numéros prédéterminée. En effet, si l'on utilise des enregistrements de type « wildcard » (c'est-à-dire comprenant un « caractère joker » *, par exemple *.3.3.e164.orange.fr), on pourra n'alimenter que les tranches « initiales » dans la base ENUM, afin de réorienter tout numéro de téléphone (par exemple, « +33123456789 ») faisant partie de la tranche et n'ayant pas d'enregistrement correspondant plus pertinent, vers un serveur DNS de renvoi au moyen d'une nouvelle clé d'interrogation (par exemple, « 33123456789.npdb.orange.fr »). Par ailleurs, concernant ladite base de données du domaine de renvoi, on peut envisager au moins deux variantes.

Selon une première variante, cette base de données est une base de données de portabilité utilisée par les réseaux téléphoniques à commutation de circuit fixes ou mobiles. Cela peut être, par exemple, la base de données « historique » utilisée par le RTC. Selon une deuxième variante, pour tout numéro de téléphone (par exemple, « +33123456789 ») appartenant à une tranche (par exemple, « +3312345 ») dont l'usage a été délégué à un réseau tiers (par exemple, « lambda.fr »), c'est-à-dire un réseau autre que ceux des domaines origine A et destinataire B, on interroge, au moyen de la nouvelle clé d'interrogation (par exemple, « 33123456789.operateur-lambda.fr ») une base de routage de ce réseau tiers. Ainsi, dans le cas où l'on ne connaît pas les données de portabilité des numéros dans des tranches de numéro attribuées à d'autres, plutôt que de rediriger la requête DNS vers le serveur autoritaire de la zone (par exemple, « 5.4.3.2.1.3.3.e164.arpa »), on peut néanmoins par cette redirection et ce changement de nom de domaine récupérer l'URI associée au numéro de téléphone, 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. On notera que cette variante requiert une convention avec le réseau tiers (puisque la clé d'interrogation commence par 33123456789 et non par 9.8.7.6.5.4.3.2.1.3.3). La description ci-dessus a pris l'exemple d'un appelant raccordé à un réseau IMS et par suite d'un S-CSCF comme serveur d'appel émettant la requête DNS vers le serveur ENUM. Plus généralement, l'invention s'applique évidemment à tout serveur d'appel susceptible d'émettre une requête DNS vers un serveur ENUM, 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 20 domaine IP, 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 25 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. Procédé de résolution par un domaine IP, dit domaine origine (A), du numéro de téléphone d'un utilisateur, dit appelé, appartenant à un domaine IP, dit domaine destinataire (B), comprenant les étapes suivantes : a) un utilisateur, dit appelant, appartenant audit domaine origine (A) place un appel téléphonique vers ledit numéro de téléphone, b) un serveur d'appels dudit domaine origine (A) émet, après avoir converti ledit numéro de téléphone en une clé d'interrogation appropriée, une requête vers un serveur DNS (NS1) associé au domaine origine (A), c) ledit serveur DNS (NS1) effectue une recherche dans une base ENUM au moyen de ladite clé d'interrogation, d) ladite recherche fournit au moins un enregistrement NAPTR dans lequel : - le champ « Flags » est vide, et - le champ « Replacement », ou le champ « Regexp », contient une représentation d'un domaine IP, dit domaine de renvoi, et e) le serveur DNS (NS1), ou ledit serveur d'appels, émet une requête DNS en direction dudit domaine de renvoi, ledit procédé étant caractérisé en ce que le numéro de téléphone a été, antérieurement audit appel téléphonique, porté lors d'un changement de domaine dudit appelé.
2. 2. Procédé de résolution d'un numéro de téléphone selon la revendication 1, caractérisé en ce que ladite base de données du domaine 21 de renvoi est dédiée aux numéros de téléphone ayant fait l'objet d'une portabilité.
3. 3. Procédé de résolution d'un numéro de téléphone selon la revendication 2, caractérisé en ce que ladite base de données du domaine de renvoi est une base de données de portabilité utilisée par les réseaux téléphoniques à commutation de circuits fixes ou mobiles.
4. 4. Procédé de résolution d'un numéro de téléphone selon la revendication 1, caractérisé en ce que ladite base de données du domaine de renvoi est une base de routage d'un réseau tiers autre que ceux desdits domaines origine (A) et destinataire (B), et en ce que ledit numéro de téléphone appartient à une tranche dont l'usage a été délégué audit opérateur tiers.
5. 5. Procédé de résolution d'un numéro de téléphone selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit domaine origine (A) est, ou est inclus dans, un réseau de type IMS.
6. 6. Base de données ENUM, contenant au moins un enregistrement NAPTR dans lequel : - le champ « Flags » est vide, et - le champ « Replacement », ou le champ « Regexp », contient une représentation d'un domaine IP, dit domaine de renvoi, caractérisée en ce qu'elle fournit ledit enregistrement NAPTR en réponse à une clé d'interrogation représentant un numéro de téléphone qui a été porté lors d'un changement de domaine de l'utilisateur associé audit numéro de téléphone.
7. 7. Base de données ENUM selon la revendication 6, caractérisée en ce qu'elle fournit un domaine de renvoi prédéterminé en réponse aux clés d'interrogation représentant les numéros de téléphone appartenant à une tranche de numéros prédéterminée.
8. 8. Serveur DNS (NS1), caractérisé en ce qu'il est associé à une base de données ENUM selon la revendication 6 ou la revendication 7.
9. 9. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique 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 1 à 5.
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 1 à 5, lorsqu'il est exécuté sur un ordinateur.