WO2014072665A1 - Procédé de résolution d'un numéro de téléphone porté en un identifiant de ressource réseau - Google Patents

Procédé de résolution d'un numéro de téléphone porté en un identifiant de ressource réseau Download PDF

Info

Publication number
WO2014072665A1
WO2014072665A1 PCT/FR2013/052703 FR2013052703W WO2014072665A1 WO 2014072665 A1 WO2014072665 A1 WO 2014072665A1 FR 2013052703 W FR2013052703 W FR 2013052703W WO 2014072665 A1 WO2014072665 A1 WO 2014072665A1
Authority
WO
WIPO (PCT)
Prior art keywords
domain
network
telephone number
server
dns
Prior art date
Application number
PCT/FR2013/052703
Other languages
English (en)
Inventor
Goar Haspekian
Philippe Fouquart
Olivier Cleuziou
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Priority to US14/442,337 priority Critical patent/US9591142B2/en
Priority to EP13801646.4A priority patent/EP2918064A1/fr
Publication of WO2014072665A1 publication Critical patent/WO2014072665A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/128—Details of addressing, directories or routing tables
    • 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
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/65—Telephone numbers

Definitions

  • the present invention relates to telecommunications networks, in particular networks of the IP ("Internet Protocol”) type.
  • the present invention relates to the identification of the network or domain to which a user belongs, based on the user's public telephone number. It will be said that a user "belongs" to a certain domain of the network of a given operator when this user has an account with this operator, and this, regardless of the access network or the device (s) ) used by this user to connect to the operator network.
  • ITU-T Recommendation E.164 the format of international public telephone numbers is defined by ITU-T Recommendation E.164; the ITU-T is a part of the ITU ("International Telecommunication Union") responsible for the development of international standards.
  • IP networks support conversational services, such as “VoIP” (VoIP), “Content Sharing”, or “Instant Messaging”.
  • VoIP Voice over IP
  • VoIP Voice over IP
  • Content Sharing Voice over IP
  • IP networks are generally able to implement advanced session control protocols, such as H. 323 or SIP.
  • H.323 is a combination of a set of audiovisual communication protocols in an IP network developed by the ITU-T. They concern signaling, negotiation of data encoding parameters, and data transport. They are widely used in Voice over IP and in video conferencing as well as only in several real-time Internet applications such as "NetMeeting".
  • the SIP protocol (initials of the words “Session Initiation Protocol” meaning “Session Initiation Protocol”) was defined by the Internet Engineering Task Force (IETF) in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • IETF Internet Engineering Task Force
  • the SIP protocol is used in particular in infrastructure type IMS (initials of the words "IP Multimedia Subsystem” meaning “Multimedia subsystem over IP”).
  • the IMS is defined by the 3rd Generation Partnership Project (3GPP).
  • 3GPP 3rd Generation Partnership Project
  • This network architecture applicable to both mobile and fixed access networks, enables the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the network for transporting multimedia streams. Through this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • the IMS currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages.
  • IP network communication services can identify physical or virtual resources by means of strings, for example an H.323 alias or a "URI" (initials of the English words “Uniform Resource Identifier” meaning “Uniform Resource Identifier”). ).
  • the syntax of URIs is defined in RFC 3986 of the IETF; the knowledge of the URI of a resource makes it possible to obtain the IP address of a device of the network of the operator managing this resource.
  • two types of resource identifiers are distinguished: those of the form "SIP-URI” as defined in RFC 3261, or those of the form "tel-URI” as defined in RFC 3966.
  • a SIP-URI is of the form "sip: user @ host” (for example, sip: alice @ domain1), where the "host” part identifies the domain of the operator responsible for the identity represented by the "user” part.
  • URI any type of physical or virtual application resource identifier accessible on a network.
  • DNS system (initials of the words "Domain Name System” meaning “System of Domain Names”) is a service for finding information from a domain name.
  • DNS servers make available to any computer-client ("DNS resolver") that has issued a DNS query domain-name / information-of-certain-type associations, called “resource records” ( “Resource records”).
  • DNS resolver any computer-client
  • resource records “Resource records”
  • NAPTR Natural Authority Pointer Resource Records
  • RFC 3403 specify substitution rules to be applied to a string of NAMS. characters in order to produce a certain result, such as, for example, another domain name or a URI.
  • the DNS system via NAPTR records, allows to match one character string to another by means of a domain name search: it suffices, by applying a rule specific to the application concerned, to transform the chain from original characters to a domain name, which will be associated with a substitution rule to apply to the original string to produce the desired result.
  • the network / domain hereinafter referred to as the "originating domain”, to which the caller belongs must therefore know the identity of the network / domain, referred to as " recipient domain "below, to reach the called user.
  • the caller knows very often only the telephone number of the called user, said phone number being in public format according to recommendation E.164 or in a private format.
  • this phone number does not easily determine the identity of the recipient domain; in other words, there is no automatic association between the identifier E.164 and the URI (or URIs) of the destination domain.
  • a domain may have several input URIs, which may also possibly be a function of the identity of the domain of the caller; for the sake of brevity, in this document, the "URI of the destination domain” is sometimes referred to as the input URI (s) of this domain.
  • the original domain route calls on the basis of slices of telephone numbers, similar to the routing performed in the Public Switched Telephone Network (PSTN) Public Or PSTN, in English) or in mobile switched networks such as the Public Land Mobile Network (PLMN). But such a routing is expensive in operational management (initial configuration, plus any modifications).
  • PSTN Public Switched Telephone Network
  • PLMN Public Land Mobile Network
  • the originating domain has only partial knowledge of the management of the numbering plan of the country of destination, which may impose intermediaries and prevent the establishment of a direct relationship. between the origin domain and the destination domain.
  • This type of solution requires dedicated, non-mutualizable processing with the processing implemented for the routing of alphanumeric URIs, that is to say URIs whose component "user” (as “alice” in sip: alice @ domain1 ) is not a telephone number, said routing using the "host” component of the URI (as "domainl” in sip: alice @ domain1).
  • the original domain implements an ENUM application.
  • the ENUM application uses a database specific to the network to which this original domain belongs and which contains particular NAPTR records defined in RFC 3761.
  • the ENUM application makes it possible, by DNS query by means of an interrogation key (as described above) representative of a telephone number in E.164 format, to know the URIs that can be used to reach a correspondent.
  • These URIs point to resources or services associated with the correspondent's E.164 number such as, for example, an e-mail address, a web page, a directory service, fixed or mobile forwarding numbers, or an alias of Voice over IP, video telephony or instant messaging for SIP or H.323 protocols.
  • two cases may arise when querying an ENUM database.
  • the query key appears in this ENUM database and the corresponding NAPTR record configures the value "u” to a parameter called “Flags” (provided in RFC 3761).
  • This value "u” indicates that this request ENUM is final ("terminal” in English), in that the response to the request directly provides one or more URI (s) of the called (in case of plurality of URIs , the answer also provides a recommendation as to their order of treatment).
  • the interrogation key does not appear in this ENUM database.
  • the routing can not be performed in accordance with the mechanism just described, but requires, inconveniently, that the operator of this network set up an ad hoc mechanism dedicated to unknown telephone numbers.
  • This ad hoc mechanism which varies from one operator to another, may consist of complicating the methods for analyzing numbers at the call server level, or defining a default route, for example imposing the transit via the switched network. RTC.
  • This problem of portability concerns any type of telephone call, that is to say any operation intended to establish a network session (Voice over IP, videoconference, instant messaging, and so on) using for this purpose a number of calls. called phone. More generally, this problem concerns any message of a session control protocol (for example, SIP or H.323) using a telephone number as a routing identifier, whatever the purpose of this message, for example the establishment of a phone call, logging in, subscribing to the status of a resource (SIP SUBSCRIBE message), or requesting the capacity of a resource (SIP OPTIONS message).
  • a session control protocol for example, SIP or H.323
  • the "user" associated with a telephone number serving as a routing identifier may be a human person or a machine (for example, an answering machine), but also a service, said service having been initially hosted. by a first operator domain, then ported to a second operator domain.
  • One solution to this problem could be to record in each ENUM database all the portability data (for example, the current network / domain to which the user associated with the telephone number belongs), or at least those concerning outgoing numbers of the network considered; but such a solution would have big impacts on the management processes of the data of portability (power supply, update, control of coherence, and so on), in particular due to the fact that the infrastructures DNS managed by distinct operators are of made separate and waterproof; this solution is therefore very difficult to implement in practice.
  • a second solution would be to upgrade the existing ENUM servers to include a query interface of the historical number portability database. But such a solution is contrary to DNS logic; moreover, it assumes as many developments as separate ENUM servers deployed, which would make the network operator highly dependent on its ENUM server providers.
  • a first drawback of this "NS records" solution is that the operators involved must agree on a common ENUM root.
  • a second disadvantage is that it multiplies by three the amount of records stored at the taker operator; the licenses of ENUM server manufacturers can be proportional to the volume, this solution would be extremely expensive.
  • the present invention therefore relates to an ENUM database, containing at least one CNAME or DNAME record providing a return domain in response to an interrogation key function of the telephone number of a called called user.
  • Said ENUM database is remarkable in that said called party belongs to said return domain and in that said telephone number has been ported in relation to a network / domain change of the called party.
  • a redirection of DNS queries is implemented by means of DNS records of particular types, called CNAME and DNAME (the definition of which will be recalled below).
  • DNS records of particular types, called CNAME and DNAME (the definition of which will be recalled below).
  • These records which are generally known, make it possible to substitute for the domain name to which the DNS request relates a new domain name, referred to as the "return domain", which will serve as a search key for a subsequent interrogation of an ENUM application. It is thus known to which domain, and with which interrogation key, a DNS request can be redirected in order to obtain information concerning the current URI associated with a telephone number which has previously been ported.
  • the name of this return domain was in fact entered into said ENUM database during the procedure of portability of the telephone number, that is to say when the user of this telephone number has changed domain.
  • the invention does not require any naming convention between operators.
  • the supply of an ENUM database required to implement the invention is very simple, and does not require frequent updating of the data, because it does not manipulate the portability data themselves. , by nature variable in time, but data configurations, which are essentially static.
  • the present invention makes it possible to have separate DNS roots and to simply switch from one tree to another. It does not therefore require managing a common root in a dedicated server; it does not require delegation of zones to the assignor operator and therefore does not oblige to create multiple zones in the operator's server.
  • the present invention thus makes it possible:
  • the ENUM database according to the invention can be advantageously associated with a fixed or mobile circuit switched telephone network. This may be, for example, the "historical" database conventionally used by the RTC.
  • said ENUM database is entirely dedicated to ported phone numbers.
  • the manager of the ENUM database includes CNAME or DNAME records relating to a set of respective telephone numbers coming out of various respective networks / domains and for which this manager knows the respective return domain, in order to be able to answer (possibly for a fee) a request for information regarding the portability of a particular telephone number.
  • the invention relates to a DNS server associated with an ENUM database as briefly described above.
  • the invention relates to the use of an ENUM database as briefly described above.
  • the invention relates to a method of resolution by a network / domain, said domain of origin, the telephone number of a user, called called, belonging to a network / domain, said destination domain, comprising the following steps:
  • a server of the domain of origin in charge of routing said message or a DNS server, generates a key of interrogation function of the telephone number and a domain name, said domain penultimate, c) a request DNS is sent to a DNS server associated with the penultimate domain,
  • said DNS server associated with the penultimate domain performs, by means of said interrogation key, a search in an associated ENUM database,
  • said search provides at least one CNAME or DNAME record containing a representation of a network / domain, referred to as the return domain, and
  • Said method is remarkable in that said return domain comprises said destination domain, and in that said telephone number was, prior to sending said message, related to a network / domain change of the called party.
  • said message may be a telephone call
  • said server of the original domain in charge of routing the message be a call server.
  • a URI may optionally identify a user of a non-IP network (for example, a URI of type "tel:" according to RFC 3966 may identify a user of a PSTN or GSM network)
  • the method according to the invention applies to messages using as a routing identifier a telephone number which has been ported from an IP or non-IP network to another IP or non-IP network.
  • the term "penultimate domain” refers to the domain associated with an ENUM database as briefly described above, that is to say containing a type registration.
  • the term "penultimate domain” refers to the domain associated with the last DNS server consulted before consulting a DNS server associated with the destination domain.
  • the DNS server of the origin domain first queried by the origin domain server in charge of routing the message will return directly to the destination domain: the penultimate domain will then be identical to the original domain.
  • the penultimate domain will then not necessarily be identical to the domain of origin; for example, said penultimate domain could be a third party network separate from said origin domain and said destination domain, and in this case the called party's telephone number could belong to a slot whose use has been delegated to the operator of said third party network.
  • a database comprising a record associating a representation of said telephone number with a representation of a user identifier. current resource (URI) of the called party.
  • URI current resource
  • the "resolver" DNS that is to say the server of the network issuing a new DNS query can be, recursively, the DNS server that has just been interrogated, or, iteratively, the server of the original domain in charge of routing the message.
  • the advantages offered by these methods are essentially the same as those offered by the ENUM databases succinctly described above.
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for performing the steps of the method of resolving a telephone number succinctly set forth above, when executed on a computer.
  • FIG. 1 shows examples of conventional NAPTR recordings
  • FIG. 2 schematically illustrates the successive steps of a method for resolving a ported telephone number, according to one embodiment of the invention
  • FIG. 3a shows a first record obtained during the implementation of this embodiment
  • FIG. 3b shows a second record obtained during the implementation of this embodiment
  • NAPTR records specify how to produce a URI from an original string from which a query key in the form of a name is derived. domain, on which the DNS request is. This original string is called AUS (initials of the words “Application Unique String” meaning “Character String for Single Application”). Equally, NAPTR records are also said to represent "rewrite” rules to be applied to an AUS.
  • the parameters of the NAPTR records are:
  • Order indicates the order in which to evaluate NAPTR records; as long as there are still records of the same Order value to review, the records of the following "Order" values are irrelevant;
  • Flags indicates, for example, whether the record describes a transient rewrite (the result of which is a domain name pointing to another record) or a final rewrite; the precise semantics of the "Flags” parameter depends on the DDDS application used (DDDS are the initials of the words “Dynamic Delegation Discovery System” meaning “Dynamic System of Delegation Discovery", this system is described in RFC 3401);
  • the ENUM function is precisely a special DDDS application in which the AUS consists of a telephone number.
  • the AUS consists of a telephone number.
  • the value of "Services" specifies the type of the resulting URI (for example, SIP-URI, or tel-URI, or email address).
  • a domain name identifies a network node, including an IP network.
  • Each node has a set (possibly empty) of resource information.
  • the set of resource information associated with a given name is composed of "Resource Records" (RR).
  • RR Resource Records
  • a DNAME non-terminal DNS name redirection
  • a PTR which is a pointer to other data in the DNS system
  • hosts and other resources often use multiple names to identify the same resource. For example, the names orange.com and orange-ftgroup.arpa could identify the same host. Similarly, in the case of mailboxes, many organizations provide multiple names that actually relate to the same mailbox.
  • a CNAME / DNAME type RR identifies its owner name as a nickname, and specifies the corresponding canonical name in a section of the RR called RDATA.
  • the CNAME and DNAME RRs share the fact that a query of such RR returns data corresponding to a domain name different from the domain name being queried.
  • the difference between these two types of resource records is that a CNAME RR redirects presented DNS queries to the owner of the record to another (unique) name, while a DNAME RR redirects DNS queries presented to a descendant. from the owner of the record to corresponding names under another (unique) node of the tree.
  • a DNAME RR redirects a query from one part of the DNS name tree to another part of the DNS name tree.
  • a DNS server When a DNS server fails to find the desired RR in the resource set associated with the domain name, it checks whether the resource set consists of a CNAME or DNAME record with a corresponding "class". If this is the case, the DNS server includes this record in its response, and resumes the search at the domain name specified in the RDATA field of the CNAME / DNAME record.
  • DNS servers must be well-designed to respond properly when presented with a CNAME / DNAME string, or a loop: they are expected to follow the CNAME / DNAME string, and report CNAME / DNAME loops as errors.
  • domain of origin belonging to an IP domain
  • Boernardo the "Bernardo”
  • the routing of this call requires knowledge of the input URI of the IP domain, called "recipient domain” B, to which Bernardo belongs.
  • the call sent by Alice is received by a call server of the operator A managing the origin domain A.
  • a call server of the operator A managing the origin domain A.
  • the origin domain A is, or is included in, an IMS type network - in which case the call server is generally constituted by an S-CSCF server; it is recalled in this respect that the IMS networks comprise one or more servers called "S-CSCF" (initials of the words "Serving-Call Session Control Function” meaning “Function of Session Call Control Session”), which are apt (among other functions) to manage the procedure for registering users on the network.
  • S-CSCF server
  • this S-CSCF server having determined that the called number complies with the E.164 standard, performs a conversion of this number into an expression constituting a domain name, and which will allow, as a that interrogation key, a search of the URI attached to the called Bernardo in an ENUM database of a DNS server of the original domain A. Then, the S-CSCF server sends a request containing this key d query to this DNS server.
  • the S-CSCF server constructs the expression "98765432133” by inverting the order of digits, then inserting dots between each pair of digits. successively, the expression "9.8.7.6.5.4.3.2.1 .3.3”. Then, this last expression is concatenated to a predefined domain name, let's call it "root”, to obtain the expression "9.8.7.6.5.4.3.2.1 .3.3. root ".
  • RFC 3761 defines the value of "root” as "e164.arpa. For public DNS servers; For private DNS servers, it is allowed to define its own root.
  • the ENUM function searches its database by means of the interrogation key "9.8.7.6.5.4.3.2.1 .3.3. root ". In the case where "root” is "e164.arpa.
  • These records may be, for example, those shown in Figure 1.
  • the second record makes it possible to obtain the URI "h323: bernardo @ example1 .corn" associated with an H.323 network, and
  • the third record provides the email address "mailto: bernie@example2.com”.
  • these URIs are sent to the call server (here, S-CSCF server) of the original domain A, in response to the DNS request.
  • the call establishment request is routed, preferably (taking into account the values of the "Order” and "Preferences” parameters), to another SIP server associated with the "b.com” domain.
  • This SIP server which is the entry point to the network associated with the domain name "b.com" is generally an l-CSCF server (initials of the words “Interrogating-Call Session Control Function” meaning “Command Function Interrogator Call Session ”) in the case of an IMS network.
  • Steps ⁇ , E'2 and E'3 are then implemented, which are respectively analogous to steps E1, E2 and E3 above.
  • the (private) value of "root” is "e164.RootA0".
  • step E'4-a the ENUM function of the root server performs a search in its database by means of the interrogation key "9.8.7.6.5.4.3.2.1 .3.3.e164. RootA0 ", and there is the record of Figure 3a.
  • This figure 3a shows an example of a DNAME record for a French telephone number, the effect of which is that any DNS request for a domain name under 3.3.e164.RootA0 is redirected to a DNS server (or an application emulating the functionality of a DNS server) - let's call it RootA - associated with the original domain A and loaded with phone numbers starting with "+33".
  • the ENUM function deduces that the search must continue using a return domain, namely "3.3. e164.RootA.fr republic
  • ENUM database containing a DNAME record is considered here, whereas conventional ENUM databases usually contain only NAPTR records.
  • l-ENUM ENUM Infrastructure
  • said record type DNAME allow, pending the completion of this construction, to send DNS queries concerning the domain "e164.arpa" to a DNS server belonging to this unique tree; such a DNAME type record could then be associated with an iterative string of CNAME records.
  • this information is sent to the call server (here, S-CSCF server) of the original domain A, in response to the DNS request.
  • the call server here, S-CSCF server
  • the call server sends a new DNS request to the DNS server RootA, by means of the interrogation key "9.8.7.6.5.4.3.2.1 .3.3. e164.RootA.fr Farm
  • This DNS server finds in its ENUM database a CNAME record, illustrated in FIG. 3b, containing, in its RDATA field, the expression "9.8.7.6.5.4.3.2.1 .3.3. RootB.fr ", which provides a return domain" RootB.fr "managed by an operator B.
  • an ENUM database containing a CNAME record is considered here, whereas, as noted above, conventional ENUM databases usually contain only NAPTR records.
  • this new information is sent to the call server (here, S-CSCF server) of the original domain A.
  • the call server performs, by means of the interrogation key "9.8.7.6.5.4.3.2.1 .3.3. RootB.fr ", a search in the records of the DNS server of the operator B, and there finds the recording illustrated in figure 3c.
  • This record, NAPTR type provides a current SIP-URI Bernardo, namely "sip: bernardo@b.com", similar to step E4 described above.
  • the ENUM database of the RootA DNS server is an ENUM database according to the invention since it contains a record of CNAME type returning to the destination domain B.
  • this server is associated to domain of origin A, this domain of origin A is here a "penultimate domain" within the meaning of the invention.
  • this URI is sent to the call server (here, S-CSCF server) of the original domain A, in a similar manner to the step E5 described above.
  • step E'6 is implemented, which is similar to step E6 described above.
  • the slice for example, "+3312345”
  • a third party network for example, "lambda.fr”
  • the consultation in step E'4- a of the root server of the original domain A discovers a DNAME record returning to this third party network, and is interrogated at the step E'4-b an ENUM base associated with this third party network by means of an appropriate interrogation key (for example, "9.8.7.6.5.4.3.2.1 .3.3.lambda.fr-operator").
  • this third network may be a "penultimate domain" within the meaning of the invention.
  • the example of a caller connected to an IMS network, and hence of an S-CSCF server as a call server issuing a DNS request was considered. More generally, the invention obviously applies to any call server capable of sending a DNS request, for example a Border Gateway ("Border Gateway" in English), or an interworking gateway with the RTC, or still a service platform with routing functions.
  • the invention can be implemented within a node of a network or domain, in particular within a DNS server, by means of software and / or hardware components.
  • the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit.
  • this computer system may be used to execute a computer program comprising instructions for implementing any of the methods for resolving a telephone number according to the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing the steps of a method for resolving a telephone number according to the invention, when it is executed. on a computer.
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form.
  • the invention also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the support can include storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means such as a hard disk, or a USB flash drive (“USB flash drive”) in English).
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is embedded, the circuit being adapted to execute or to be used in the performance of any of the methods of resolving a telephone number according to the invention.

Landscapes

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

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 (RootAO), 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 télécommunications, notamment les réseaux de type IP (« 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 « 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 à l'échelle internationale est défini par la recommandation E.164 de l'ITU-T ; l'ITU-T est une partie de l'UlT (« Union Internationale des Télécommunications ») 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 œuvre 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 communications audiovisuelles dans un réseau IP, 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 IP et dans les 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 Génération 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 œuvre 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 œuvre 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@domaine1 ), où la partie « host » 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, 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 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. 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 Téléphone 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 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 œuvre 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 « host » de l'URI (comme « domainl » dans sip:alice@domain1 ).
Selon une deuxième technique connue, le domaine d'origine met en œuvre 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 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 œuvre 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 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 œuvre 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 VoIP) 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 œuvre 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 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 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 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.
On notera que, puisqu'une URI peut le cas échéant identifier un utilisateur d'un réseau non-IP (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 réseau IP ou non-IP, vers un autre réseau IP ou non-IP. 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 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 œuvre de ce mode de réalisation,
- la figure 3b montre un deuxième enregistrement obtenu lors de la mise en œuvre de ce mode de réalisation, et
- la figure 3c montre un troisième enregistrement obtenu lors de la mise en œuvre 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 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. « Préférence » : 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 Délégation 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 nœud de réseau, notamment un réseau IP. Chaque nœud 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 IP, ou
• un CNAME (acronyme des mots anglais « canonical 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 IP 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 œuvre 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 nœud (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 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 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 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 enregistré dans une base ENUM d'un réseau contenant un domaine IP auquel appartient l'appelant.
Lors d'une étape E1 , un abonné - appelons-le « Alice », appartenant à un domaine IP, dit « domaine d'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 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-Call 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 .corn » 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 « Préférence »), 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 l-CSCF (initiales des mots anglais « Interrogating-Call 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, 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 œuvre) n'aient été prises à cet égard par l'opérateur du domaine d'origine A.
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 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 « Subscriber Number » signifiant « Numéro d'Abonné »).
Lors d'une étape E'O, 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- dessous en référence à la figure 3b.
On met alors en œuvre des étapes ΕΊ , E'2 et E'3, qui sont respectivement analogues aux étapes E1 , 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 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 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 VoIP se mettraient à construire une arborescence unique, appelée l-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. 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.
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 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 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.
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 œuvre une étape E'6, qui est analogue à l'étape E6 décrite 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 d'origine.
Dans l'exemple de réalisation que l'on vient de décrire, il a été 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. operateur- lambda.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 œuvre au sein d'un nœud 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 nœud 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 œuvre 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 tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais).
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

R E V E N D I C A T I O N S
1 . 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. Base de données ENUM selon la revendication 1 , caractérisée en ce qu'elle est associée à un réseau téléphonique à commutation de circuits fixe ou mobile.
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.
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. 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 (RootAO), 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. 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. 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. 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. 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 5 à 8.
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.
PCT/FR2013/052703 2012-11-12 2013-11-12 Procédé de résolution d'un numéro de téléphone porté en un identifiant de ressource réseau WO2014072665A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/442,337 US9591142B2 (en) 2012-11-12 2013-11-12 Method of resolving a ported telephone number into a network resource identifier
EP13801646.4A EP2918064A1 (fr) 2012-11-12 2013-11-12 Procédé de résolution d'un numéro de téléphone porté en un identifiant de ressource réseau

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1260742A FR2998127A1 (fr) 2012-11-12 2012-11-12 Procede de resolution d'un numero de telephone porte en un identifiant de ressource reseau
FR1260742 2012-11-12

Publications (1)

Publication Number Publication Date
WO2014072665A1 true WO2014072665A1 (fr) 2014-05-15

Family

ID=47428738

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/052703 WO2014072665A1 (fr) 2012-11-12 2013-11-12 Procédé de résolution d'un numéro de téléphone porté en un identifiant de ressource réseau

Country Status (4)

Country Link
US (1) US9591142B2 (fr)
EP (1) EP2918064A1 (fr)
FR (1) FR2998127A1 (fr)
WO (1) WO2014072665A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150350153A1 (en) * 2014-05-30 2015-12-03 Vonage Business Solutions, Inc. System and method for account-based dns routing
JP6738362B2 (ja) * 2018-02-20 2020-08-12 日本電信電話株式会社 Ｅｎｕｍ／ｄｎｓサーバ、ｅｎｕｍ／ｄｎｓシステム、及びｅｎｕｍ／ｄｎｓシステムの制御方法
US11962585B2 (en) 2019-08-20 2024-04-16 Cisco Technology, Inc. Guest onboarding of devices onto 3GPP-based networks with use of realm-based discovery of identity providers and mutual authentication of identity federation peers
US11956628B2 (en) 2020-11-23 2024-04-09 Cisco Technology, Inc. Openroaming for private communication systems

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1278382A1 (fr) * 2001-07-19 2003-01-22 Telefonaktiebolaget L M Ericsson (Publ) Méthode et appareil pour résoudre la portabilité des numéros à l'origine

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6882838B1 (en) * 1999-11-04 2005-04-19 Lucent Technologies Inc. System and method for providing dynamic call disposition service to wireless terminals
US6718021B2 (en) * 2002-02-19 2004-04-06 Sbc Properties, L.P. Method and system for presenting customized call alerts in a service for internet caller identification
US8756341B1 (en) * 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
US11265383B2 (en) * 2012-04-27 2022-03-01 Interdigital Patent Holdings, Inc. Systems and methods for personalizing and/or tailoring a service interface
US20150080128A1 (en) * 2013-09-18 2015-03-19 Zynga Inc. Content management system
US9560074B2 (en) * 2014-10-07 2017-01-31 Cloudmark, Inc. Systems and methods of identifying suspicious hostnames

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1278382A1 (fr) * 2001-07-19 2003-01-22 Telefonaktiebolaget L M Ericsson (Publ) Méthode et appareil pour résoudre la portabilité des numéros à l'origine

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"IR.67-DNS/ENUM Guidelines for Service Providers & GRXIIPX Providers", 13 August 2010, GSM ASSOCIATION
BROWN NORTEL NETWORKS GREG VAUDREUIL LUCENT TECHNOLOGIES A: "ENUM Service Specific Provisioning: Principles of Operation; draft-ietf-enum-operation-01.txt", 20001027, vol. enum, no. 1, 27 October 2000 (2000-10-27), XP015018187, ISSN: 0000-0004 *
NIKLAS BEIJAR: "IP telephony protocols, architectures and issues TRIP, ENUM and Number Portability", 1 January 2001, PROCEEDINGS (REPORT / HELSINKI UNIVERSITY OF TECHNOLOGY,NETWORKING LABORATORY, XX, XX, PAGE(S) 105 - 115, XP007906752 *
See also references of EP2918064A1

Also Published As

Publication number Publication date
US9591142B2 (en) 2017-03-07
EP2918064A1 (fr) 2015-09-16
US20160065747A1 (en) 2016-03-03
FR2998127A1 (fr) 2014-05-16

Similar Documents

Publication Publication Date Title
EP3085065A1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
EP2918064A1 (fr) Procédé de résolution d'un numéro de téléphone porté en un identifiant de ressource réseau
EP2080345B1 (fr) Procede de gestion d'identites publiques dans un reseau de transmission d'informations, serveur de gestion d'enregistrements d'identites publiques, equipement de gestion d'une identite publique de groupe et programmes d'ordinateur correspondants
EP3646554B1 (fr) Procédé de traitement d'une requête et serveur d'un coeur de réseau ip multimédia
WO2011095522A1 (fr) Procede de generation d'une adresse sip publique permanente associee a une identite privee sur un reseau ims
EP2873211A1 (fr) Procede d'enregistrement d'au moins une adresse publique dans un reseau ims et application correspondante
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
FR2974472A1 (fr) Procede de resolution d'un numero de telephone porte en un identifiant de ressource ip
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
FR2980328A1 (fr) Procede de traitement d'une requete d'un service dependant de la localisation d'un terminal mobile
EP1940133B1 (fr) Système et procédé de gestion de joignabilité via au moins un réseau de communication
EP3337208B1 (fr) Procédé et dispositif de transmission d'un message
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2013121158A1 (fr) Procédé d'enregistrement d'un serveur d'application et serveur d'application
FR3121808A1 (fr) Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
WO2007132108A2 (fr) Procede de routage pour numeros non standard dans un mecanisme de routage pour numeros standard
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
WO2015086460A1 (fr) Procede de gestion d'un identifiant public, systeme, serveur et element de securite correspondant
EP1940131A1 (fr) Système et procédé de gestion de joignabilité via au moins un réseau de communication
FR2911034A1 (fr) Systeme et procede de gestion de joignabilite via au moins un reseau de communication
WO2010112740A2 (fr) Procede de routage d'une demande d'etablissement d'appel
FR2958820A1 (fr) Routage de requetes sip
WO2012117178A1 (fr) Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13801646

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14442337

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2013801646

Country of ref document: EP