Method of resolution of a telephone number

PROCESS FOR RESOLUTION OF A PHONE NUMBER

The present invention relates to IP-based telecommunications networks ( "Internet Protocol"). More particularly, the present invention relates to the identification of the IP domain that a certain resource, on the basis of public or private phone number of that resource.

We say that a resource reachable via an IP network "belongs" to a certain area of ​​the network of a given operator when the owner of that resource has an account with the operator, and this, regardless of the access network used by the owner to connect to the operator network. In the context of this document, all resources of this type will, for brevity, referred to as "client device" ( "User Equipment" in English). These customers-devices may for example be a fixed or mobile terminal or a home gateway ( "Residential Gateway" in English) or within a company or a network gateway operator ( "Voice Gateway" in English) such that a DSLAM (DSLAM are the initials of the words "digital subscriber line access multiplexer" meaning "Multiplexer Lines Access Digital Subscriber" and it is a collecting device DSL data traffic passing on a number of telephone lines).

Remember that the Public Switched Telephone Network (PSTN)

( "Switched Telephone Network", or STN, in English), and in particular the public switched telephone network (PSTN in English), is a fixed telephony network in which an analog terminal or a digital installation are connected to a telephone exchange one or more pairs of twisted copper son mains powered, all constituting what is called the "local loop". Analog or digital telephone terminals can be of various kinds, eg individual telephone (subscriber unit), a payphone, or a PBX (initials of the words "Private Automatic Branch eXchange" meaning "private branch exchange") which serves primarily to connect telephone sets an establishment (lines "internal") to the public telephone network ( "external" lines).

The format of public telephone numbers internationally defined by the E.164 Recommendation ITU-T (ITU-T is the part of the ITU (International Telecommunications Union) responsible for the development of international standards).

It also recalls that the Public Land Mobile Network ( "Public Land Mobile Network" PLMN or English), commonly known simply as "mobile network" means a telecommunications network that allows authorized users to access various services (such as telephony, messaging, data communications, and audiovisual content broadcast) in situations of mobility from portable terminals. Depending on country and operator, a PLMN may be based on different standard architectures such as GSM, CDMA, or UMTS in particular. In most countries, there are now actually more PLMNs which are operated by different operators; These networks are typically interconnected, thereby to establish communications between terminals registered on different mobile networks. They are also interconnected with the PSTN, thereby to establish communications between mobile terminals and fixed terminals.

In the context of the present invention will be designated "system network" any kind of switched network, fixed (PSTN) or mobile (PLMN), using a public address to E.164 or private addressing. It is also recalled that IP networks enable the distribution of conversational data, such as "voice over IP" (VoIP), "Content Sharing" or "Instant Messaging". Today, IP networks are typically able to implement advanced session control protocols such as H.323 or SIP.

The H.323 protocol was developed by ITU-T. It specifies procedures for the signaling, negotiation of coder-decoder, and transport information. It is widely used by manufacturers of equipment voice and video conferences, as well as several Internet applications in real-time such as "NetMeeting".

SIP (initials of the words "Session Initiation Protocol" meaning "Session Initiation Protocol") has been defined by the IETF in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.

SIP is used in particular in the type of IMS infrastructure (initials of the words "IP Multimedia Subsystem" meaning "Multimedia Subsystem IP"). The IMS has been defined by standards bodies 3GPP ( "3rd Generation Partnership Project") and TISPAN ( "Telecommunications and Internet Converged Services and Protocols for Advanced Networking"). It is a network architecture introduced by 3GPP for mobile networks and then taken by TISPAN for fixed networks. This architecture allows the dynamic establishment and control multimedia sessions between clients and reservation of resources in transport media streams network. With this architecture, network operators can conveniently implement a management policy, providing a predetermined service quality, and calculate how much to charge customers. IMS currently provides access to type services telephony, video telephony, presence and Instant Messaging, which also manages the interaction.

IP network communication services can identify physical or virtual resources using strings, for example, H.323 or alias of "URI" (initials of the words "Uniform Resource Identifier" meaning "Uniform Resource Identifier" ). The URI syntax is defined in RFC 3986 of the IETF (Internet Engineering Task Force); knowledge of the URI of a resource permits (for example, using a DNS query) to obtain the IP address of a network device to the operator managing this resource.

In particular, in networks implementing the SIP protocol, there are two types of resource identifiers: 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 "user @ host" (eg, alice @ domain1), where the "host" part identifies the domain of the operator responsible for the identity represented by the party "user". Such a URI is of the form "as: numéro_de_téléphone" (eg, tel: 33123456789) in reference to international public telephone numbers, or form "as: numéro_de_téléphone; phone-context = ..." (para example, tel: 0623456789; phone-context = + 33) in reference to telephone numbers assigned by an operator to its private network.

For brevity, the rest of this description, we will call "URI" any type of physical application resource identifier or virtual reachable via an IP network.

To establish communication via one (or several) network (s) IP, the IP domain that the caller (called "original domain" below) must know an identifier of the recipient field (for brevity, confused herein any subscriber to an IP network with the client device of said subscriber; Furthermore, the term "receiving area" the IP domain to which the called party). Or the caller often knows that the called telephone number, said telephone number being publicly format according to the recommendation E.164 or private format (for brevity, hereinafter be referred to this issue by phone "E.164 identifier" whatever its size, public or private). Unfortunately, this phone number can not easily determine the identity of the recipient domain. In other words, there is no automatic association between E.164 ID and the URI (or URI) Input recipient field.

To solve this problem, according to a first known technique, the original domain route calls based on phone number ranges, similarly to the routing done in the PSTN or mobile networks. But such routing is costly in operational management (initial setup, plus any amendments), and do not establish a direct relationship between the original area and the recipient area.

According to a second known technique, the original domain queries an ENUM database, as defined in RFC 3761. An ENUM database provides a mapping between an identifier E.164 and URI type information. In the particular case where the original domain is a network using the SIP protocol, the interrogation of the database can be performed by the network of heart, and more particularly by the S-CSCF in the case of a network IMS. But this technique requires that ENUM E.164 / URI correspondence recipient area is known area of ​​origin; sharing presupposes a relationship of trust between the entities providing this association. This technique also requires an effort of publication and maintenance of information database. If the database is publicly accessible, it presupposes a common governance of the bases used. Moreover, its use would be risky as any VoIP user becomes reachable from any entity connected to the Internet, and would be exposed to unwanted calls ( "Spam over IP Telephony," or SPIT English). Therefore, even if the ENUM technology is deployed to date by a number of operators, it is so only in private - restricted to its own domain or a limited number of trusted domains; the deployment of ENUM on a national scale, or, a fortiori, global, still seems utopian.

A third known technique, finally, is the technical VIPR ( "Verification Involving PSTN Reachability") proposed by Cisco company (see draft-lnternet http://tools.ietf.org/html/draft-rosenberg-dispatch- vipr- overview-02, 7 March 2010), which is intended to be implemented within a network of peers ( "peer-to-peer" or P2P in English). When the URI of the destination domain is not known, this VIPR technique includes the following phases:

1) a first phone call is carried over the PSTN and, if successful, the caller and callee keep track of information related to the call ( "Call Detail Record" or CDR in English), such as telephone number of the caller, the called number, the start time of the call, and the end time of the call;

2) the appellant research called the phone number to E.164 format, in a published database by the peer network, said database associating each phone number (in E.164 format) it contains an identifier, in the peer network, a resource intended to be responsible for this issue;

3) If the called phone number is in the database, the caller and the called authenticate each other on the basis of shared knowledge of this recorded CDR in the above first step; and

4) if the CDR is valid, said node provides the caller the recipient field input URI for the telephone number called in question; this URI, as well as the domain name of the caller and other information validity, are encapsulated in a "ticket" associated with the called number and container, to ensure data integrity, a MAC ( "Message Authentication code ") of the data obtained by means of a secret key of the destination domain.

The technique VI PR has the disadvantage of being relatively complex, especially regarding the management of the publication of phone numbers in the P2P network, and validation of the association telephone number / IP address of the responsible resource ( the case in particular where several areas declare host the same number). In addition, it raises scalability problems (in the case of a large number of networks or users), and imposes very strong security constraints on the secret keys used to authenticate tickets, and this, especially as these tickets have a period of validity (in theory). Conversely, reducing the duration of validity of tickets leads to renew more often and therefore generates operational constraints.

The present invention relates to a resolution process by IP domain, said domain origin, public or private phone number of a client device, said called belonging to an IP domain, said recipient domain. Said method is characterized in that it comprises the following steps:

a) any client device, said caller belonging to the domain origin Place a call to said telephone number, b) said telephone call is transmitted to said recipient domain via a switched telephone network based on said telephone number, and

c) unless otherwise recipient field and / or called, the recipient domain sends audit field originally a stream of said switched telephone network containing at least one identifier to reach the recipient domain via an IP network.

This produces the desired association between a telephone number and the URI input field of the recipient of the call (or URIs that recipient domain, which are possibly based on the identity of the domain of the caller; for brevity, we refer to "the recipient field URI" it, or the URI (s) of entry of this area).

Through these arrangements, dispense with any publication of phone numbers, or couples telephone number / IP address associated with resources. In addition, the invention easily achieves global coverage because it does not require the establishment of new infrastructure and the scalability is easy to manage. Finally, it may, if desired, reinforce various ways the method of the invention on the security level using standard cryptographic protocols, so that the called URI is received, e.g. without alteration and only after authentication of the caller. It should be noted in this regard that the system networks offer nowadays a relatively high security.

According to particular features, said flux is a call response signal, and said identifier is inserted in a UUI (User to User Information) and / or in the shell of access information said call response signal .

This embodiment is advantageously simple to implement insofar as the only elements of the system requiring non-conventional configuration are the interconnection device between the originating domain and the PSTN / PLMN, and the interconnection device between the PSTN / PLMN and the recipient field.

According to other particular characteristics, said identifier is inserted into a modulated stream by PCM (Pulse Code Modulation).

This second embodiment is also advantageously simple to implement, for the same reasons as the first mode.

Correspondingly, the invention relates to various devices.

It concerns as well, first, an interconnection device between an IP domain, said domain origin, and a fixed or mobile switched telephone network, comprising means for receiving a telephone call placed by a first client device belonging to the domain to the original public or private phone number from a second client device belonging to an IP domain, said receiving area, and means for transmitting said recipient domain phone call via said switched telephone network based on said telephone number. The device is notable in that it further includes means for receiving from the recipient domain flux switched telephone network containing at least one identifier to reach the recipient domain via said IP network.

The invention also relates, secondly, an interconnection device between a fixed or mobile switched telephone network and an IP domain, said recipient field, comprising means for receiving, via said switched telephone network, a telephone call placed by a first device -client belonging to an IP domain, said domain origin, to the public or private phone number from a second client device belonging to the recipient field. The device is notable in that it further includes means for sending said domain originally a stream of PSTN containing at least one identifier to reach the recipient domain via said IP network.

According to particular features, said flux is a call response signal, and said identifier is inserted in a UUI (User to User Information) and / or in the shell of access information said call response signal .

According to other particular characteristics, said identifier is inserted into a modulated stream by PCM (Pulse Code Modulation).

The advantages offered by these interconnection devices are essentially the same as those offered by correlative methods described above.

Note that it is possible to produce these devices in the context of software instructions and / or in the context of electronic circuits.

The invention also provides a computer program downloadable from a communications network and / or stored on a computer readable medium and / or executable by a microprocessor. This computer program is noteworthy in that it includes instructions for executing the steps of the method of resolution of a phone number briefly described above, when run on a computer.

The benefits of this computer program are essentially the same as those offered by the method.

Other aspects and advantages of the invention appear on reading the detailed description below of particular embodiments, given as nonlimiting examples. The description refers to the single figure which accompanies and represents, for example, a network architecture adapted to the implementation of the invention. Figure 1 shows an IP domain, called "original domain" A, in connection with which we want to find an IP input field URI, called "domain recipient" B, a subscriber - call it "Bernardo" belonging to this recipient domain B and identified by an E.164 number (or, more generally, by a routable identifier by a circuit network).

To do this, we do place by any subscriber - let's call it "Alix" in the domain origin A, a telephone call to Bernardo, via a 10 any access network.

This call is received by a field of the routing device A (e.g., implementing the BGCF function in the case of an IMS network). The routing device sends the call to an interconnection device 100 (which will be called "first interconnecting device") of the A domain with a network circuit 2. For example, in the case where the network circuit 2 is a network PLMN, the interconnection device is designated by the GMSC. Also for example, when the area A is an IMS network, the interworking function provided by the interconnection device is designated by MGCF.

The interconnection device 100 then passes the call via said circuit network 2 on the basis of the requested phone number.

This call is received by an interconnection device 200 (hereinafter called "second interconnector") between said circuit network 2 and the field B, and transmitted to the subscriber Bernardo, 20 via any access network.

Unless otherwise domain B and / or Bernardo, a device domain B (preferably, said second interconnection device 200 itself), include at least one URI domain B in a circuit network stream 2 in response the call received.

Domain A, after receiving this URI domain B, stores the association called number / URI (in a private ENUM database, for example) for use for possible future signals, or phone calls or messages to Bernardo, who can be routed entirely on one (or several) network (s) 1 IP conventionally (if resolving the URI - or URIs in order of preference - via mechanisms provided by conventional protocols such as DNS or DNSSEC).

It will now be described various embodiments.

According to a first embodiment, using the UUI information element of signaling messages using the ISUP or BICC.

The ISUP protocol (initials of the words "ISDN User Part" meaning "User Part of the ISDN"), defined in Recommendations Q.761 -4 ITU-T, is a message format as part of the Signaling system # 7 (SS7 noted), which is used to make telephone calls to the PSTN. When a call is established between two subscribers, many call centers will be involved, possibly through international borders. To help in the PSTN using ISUP messages, a call to be established properly, provides a switch with these messages call information such as the number of the called or calling at next switch in the network. Telephone exchanges are interconnected by links broadband which convey the ISUP signaling data at a rate of 64 kbit / s. Each ISUP message includes a Circuit Identification Code (CIC) which identifies this message. The telephone system uses the signaling information received (particularly the number called) to determine which CIC incoming and outgoing CIC which must be connected to route end to end voice data. If no outgoing CIC is available on a particular exchange, a release message is sent to the switches earlier in the chain, so that we can try another route.

The BICC protocol (initials of the words "Bearer Independent Call Control" means "Support Independent Call Control") is a signaling protocol based on ISUP and is designed to inter-operate with existing transportation technology . BICC is specified in Q.1901 recommendations of the ITU-T. BICC signaling messages are almost identical to those ISUP; however they differ in that the headers of BICC messages do not include Circuit Identification Code. The BICC architecture consists of interconnected service nodes, which provide the function of Call Service and Support Control function; Call the service function uses BICC signaling for call setup and can inter-operate with ISUP; Support the control function receives direction from the function of the Call for Service Support via the Control BICC protocol (Q.1950 recommendation ITU-T), and is responsible for establishing and removal of support roads on a set of physical transport links such as the Internet. The BICC protocols are suitable for multimedia switched broadband and broadband communications. They are also used for mobile communications; For example, the 3GPP has included BICC in the UMTS standard (initials of the words "Universal Mobile Telecommunications Service" means "Universal Mobile Telecommunications Service") from version 4 of this standard.

ISUP messages and BICC messages may include an information item noted UUI (initials of the words "User to User Information" means "user in User Information"). This information element is used to insert in the call signaling information related to the call. This information is interpreted semantically by the end of the network elements and are transported transparently in the heart of the network. They do not directly affect the processing of the call, such as its routing. UUI for example used in the PBX to share proprietary information.

The first embodiment works as follows.

The first interconnection device 100 sends a call setup message, namely AMI (initials of the words "Initial Address Message" meaning "Message Addressing Initial"), to which he added, preferably, a UUI (if absent) containing information, allowing the second interconnection device 200 to retrieve a public key or a cryptographic certificate or an identifier of the origin domain a, or a caller ID Alix, or a pointer to a secure domain certificates of origin manager A. If UUI is already filled, the first interconnecting device 100 preferably provides this information, for example by concatenating with the user information to existing user.

If the origin of the call and provided information allowing the recipient field of identification, the second interconnection device 200 can then determine (depending on the policy of the operator of the called network) if the origin is authorized to receive the URI of the destination domain. If the origin of the call did not provide information enabling the recipient field to identify the recipient area may nevertheless (depending on the policy of the operator of the called network) allow this origin to receive its URI. In the two previous cases, unless otherwise specified recipient domain B and / or second customer dispositif-, the second interconnection device 200 inserts (if absent) or concatenates (if already present), in response to a stream, a UUI containing the recipient input field URI B, preferably encrypted with a public key of the original area a; if the size of the information is greater than the maximum size of UUI (usually limited to 128 bytes), it is possible to include a secure pointer (e.g. a URL https :) to allow recovery of this information.

It will be noted that said flow response can be:

- An ISUP ACM signal type (initials of the words "Address

Complete Message "meaning" Message Addressing Completed "), or ISUP CPG type (initials of the words" Call Progress "meaning" Call Progress ") issued before the called party answers, or

- A signal of ISUP ANM (initials of the words "Answer

Message "meaning" Message Response ") issued after the called party answers, or

- A type of signal REL (initials of the English word "Release" means "Liberation") or RLC (initials of the words "Release Complete" means "Liberation Completed") issued when the call is released.

Alternatively, the areas A and B can exchange information mentioned above via other information elements ISUP / BICC; can for example be used for this purpose the access information envelope ( "Access Transport" in English), which provides information generated at network access circuit 2 and transported transparently by the circuit network 2 switch between the starting and end switch in either direction. It is also possible to simultaneously use all these pieces of information (possibly at the expense of a fragmentation of the ISUP / BICC).

In a second embodiment, using PCM streams established between the areas A and B. It is recalled in this regard that the PCM initials (initials of the words "Pulse Code Modulation" meaning "Modulation Pulse Code") means the digital sampling technique of an analog signal wherein the signal amplitude is sampled periodically. The PCM modulation is particularly used to encode voice over PSTN and VoIP networks (among other possible modulations) and in the heart of some PLMN networks, and to encode the sound in audio compact discs (CDs), tapes DAT and MiniDisc, high capacity optical discs (Blu-ray and HD-DVD) as well as WAV files.

Note that it is possible to insert a non-multimedia information in a PCM stream, as has been shown (in a different technical context) by the procedure TFO (Tandem-Free Operation) described in Recommendation TS 28062 3GPP . To do this, you can for example use the least significant bit of a PCM sample every 16 samples (ie a bit all 16x8 bits, so 100 bytes are exchanged in 1, 6 seconds).

This second embodiment operates as follows.

Preferably, this embodiment comprises an initialization phase during which the first interconnecting device 100 sends, in a PCM flow and at a predetermined coding (e.g., UTF-8), a protocol message to suit with the second interconnection device 200 modalities of implementation of this embodiment (eg an original domain initialization a message to the recipient domain B followed by an acknowledgment message to the domain B A domain).

If the agreement between the areas A and B is validated, or if the initialization is not required, the first interconnection device 100 preferably sends said recipient field (B), with the call for Alix , a public key or a cryptographic certificate or an identifier of the origin domain a, or a caller ID Alix, or secure pointer to an area of ​​origin certificate manager A. one can also add a good control transmission of data by means of a checksum on the transmitted bits. If the origin of the call and provided information allowing the recipient field of identification, the second interconnection device 200 can then determine (depending on the policy of the operator of the called network) if the origin is authorized to receive the URI of the destination domain. If the origin of the call did not provide information enabling the recipient field to identify the recipient area may nevertheless (depending on the policy of the operator of the called network) allow this origin to receive its URI. In the two previous cases, unless otherwise specified recipient domain B and / or second customer dispositif-, the second interconnection device 200 inserts, into a PCM stream in response, the input URI of the destination domain B of preferably encrypted with a public key of the original area A.

In a first embodiment, said flow response may be issued a preliminary media stream before the called party answers. It recalls in this respect that the preliminary media stream ( "early-media" in English) are multimedia streams that can be exchanged between a calling terminal and a called terminal during the call establishment phase, ie before call establishment; for example, preliminary media stream can be used to convey a ringback signal selected by the called party, for example of CRBT (Color Ring Back Tone), or to the announcement message 'appellant. This first variant renders impossible the original field of identification for the media flows are not bidirectional at this stage of the call.

In a second variant, said stream in response may be an ordinary multimedia stream emitted after the call is answered, in which case the flows are bi-directional and identification of the origin area is possible.

The security of the embodiments described above can be enhanced by means of measurements (not mutually exclusive) below: - Public key infrastructure can be used (PKI) to guarantee the origin of the call and the integrity of the data sent from the field A, and / or to enable the field B, for example by signing the URI of input, to guarantee the origin of the flow in response and integrity of its data;

- The data encryption key provided by the second interconnection device 200 may result from a Diffie-Hellman type of exchange that take place during an initialization phase between the two interconnect devices; This key can also be used to protect integrity in the data flow in response.

In addition, the field B can add the data passed to a domain A ticket depending on a secret known only to the domain B and containing information for the domain B to validate any future signal, or call or message sent to the field B by domain A via said IP network 1. Can secure or facilitate use of such a ticket in the following variants:

- The ticket is unique for each couple field A / called number;

- The ticket is unique for an area A for all numbers hosted by domain B; this prevents an excessive storage of tickets for the domain A;

- The ticket is recovered securely from an entity dedicated to the generation of tickets; This entity can be managed by the field B or a third field with a secret shared with the areas A and B; In this variant, the second interconnection device 200 also provides, in the flow in response, how to contact that entity; This variant has the advantage of avoiding the exchange of the ticket via the flow in response, but requires the establishment of an entity dedicated to the generation of tickets.

Note that the invention can be implemented within an IP domain node, especially in an equipment interconnection with a fixed or mobile switched network, using software components and / or hardware.

The software components can be integrated into a conventional network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system. This computer system conventionally includes a central processing unit commander by signals a memory, and an input and an output unit. In addition, this computer system may be used to execute a computer program comprising instructions for implementing any of the methods of resolution of a telephone number according to the invention.

Indeed, the invention also provides a computer program downloadable from a communications network comprising instructions for executing the steps of a resolution of a telephone number method according to the invention when executed on a computer. This computer program can be stored on a computer readable medium and can be executed by a microprocessor.

This program can use any programming language and be in the form of source code, object code or a code intermediate between source code and object code, such as a partially compiled form, or in any other desirable form.

The invention also provides an information carrier, removable, or partially or totally removable, readable by a computer, and comprising instructions of a computer program as mentioned above.

The medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage medium such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or indeed magnetic recording means, eg a USB ( "USB flash drive" in English) or hard disk.

On the other hand, the information carrier may be a transmissible carrier 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 of the invention may be particularly downloaded over an Internet type network.

Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in performing any of the methods of resolution of a telephone number according to the invention.