Design and Implementation of Enum-Based Services

Abstract: ENUM is a technology based on a procedure that assigns a sequence of traditional telephone numbers to Internet domain names. It specifies a rule that makes it possible to relate a domain to a telephone number without any risk of ambiguity. This domain can then be used to identify various communication services like fax, mobile phone numbers, voice-mail systems, e-mail addresses, IP telephone addresses, web pages, GPS coordinates, call diverts or unified messaging. In our paper we deal with three main problem areas in connection with the business model of the ENUM service and with the introduction of new services, i.e. the questions of tariffs, legal regulations and financial return. For the ENUM procedure to spread out in use specific services have to be implemented that can exploit the advantages of the ENUM and efficient methods have to be elaborated to base existing services on ENUM. We will outline the two new services invented by our group and that we have implemented in our project.

Keywords: ENUM, ENUM procedure, ENUM client, Domain Name System (DNS), E.164 telephone number, ENUM-based service

Categories: H.4.3, C.2.2, C.3

1 Introduction

The ENUM (Telephone Number Mapping) is an Internet technology that allows users to combine the resources of the Internet with the traditional telephone system, uniting these two worlds of communication and enabling a whole new range of communication applications. The technology uses the Internet domain name system as a worldwide database to assign identifiers needed for the use of traditional services to telephone numbers. These services then can be accessed with the help of the telephone number. The ENUM system effectively enables individuals, businesses and other organizations to maximize the use of both the public Internet and the Public Switched Telephone Network (PSTN). The core of the technology is the procedure itself associating ITU E.164 standard telephone numbers with Internet domain names.

The significance of the ENUM procedure is that a database can be created that connects a user's different identifiers used when accessing communication or other data interchange services (telephone, e-mail, fax etc.), and this database can be easily and quickly queried. Such a database creates the possibility of working out new applications that offer either new services or existing services in better quality or at a lower price to the users by combining the different communication possibilities.

The basic problems of implementing the ENUM procedure have already been solved, and they are presented in technical recommendations [1,2,3,4,6]. At the moment the main task is the design and implementation of services and applications based on the ENUM technology.

To implement such a service many problems have to be solved:

• the necessary and suitable business models describing the use of the service have to be worked out
• the application accomplishing the new service have to be designed and implemented
• the ENUM procedure has to be amended and made suitable to provide the service.

In our paper we shortly present the ENUM procedure, the operation of the applications using the ENUM procedure, and we present two new ENUM-based services designed by our group. The work is carried out in the project called GVOP AKF 2005-05/4008.

2 ENUM technology

2.1 The ENUM procedure

ENUM is the short name for a protocol for connecting resources of telecommunication and of the Internet to one another. It specifies a rule that makes it possible to relate an Internet domain to a telephone number without any risk of ambiguity. This domain can then be used to identify various communication services like fax, mobile radio, voice-mail systems, e-mail addresses, IP telephony addresses, web pages, GPS coordinates, call diverts or unified messaging. The domain name system (DNS) is used like a database to assign different communication service identifiers to E.164 telephone numbers.

The use of the ENUM procedure can be logically divided into two main steps [7]. The first is to find the data file (zone file) belonging to the E.164 telephone number and stored in the DNS system with the help of a registered pointer (domain name registration) and a procedure that generates domain names. This zone file contains the data needed to use the different services belonging to a certain E.164 telephone number. The tool of the search is the DNS system, a traditional basic service of the Internet that assigns a data file (zone file) to a character sequence, which can be found at the place registered by its owner on the Internet.

The other part of the operation is that by interpreting the data in the zone file different applications can be started or services provided. For example the zone file can reveal e-mail address(es), further telephone number(s), fax number(s), Internet address(es) etc. belonging to the user identified by the given telephone number. These data can be used to send messages, e-mails to the owner of the telephone number, or even start a telephone call through the Internet instead of the traditional PSTN system. In the zone file more that one protocol or address can be listed for a service, and even a hierarchy can be set among these. For example we can specify that we prefer receiving phone calls on A Internet address, but if it does not work then the B traditional phone number will be preferred. The basis of the ENUM procedure is described in the RFC 3761 ("The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)"), which was accepted in April 2004.

2.2 Determining the DNS root belonging to the ENUM procedure

The uniqueness of a domain name in the DNS is guaranteed by the fact that the naming system is a reversed tree. To search in the DNS according to E.164 numbers, first we have to place the name generated from the E.164 number in the hierarchy at a place where this name will be unique in the whole DNS. The standard designates the .e164.arpa name space for this purpose. The topmost .arpa domain is reserved for the addresses and routing parameters (Address and Routing Parameter Area). Under this domain the e164 domain was created for ENUM use [8]. The place of the ENUM in the DNS hierarchy is shown in Figure 1.

2.3 Converting telephone numbers into domain names

In order to be able to create an unambiguous domain name from an E.164 telephone number anywhere in the world, the algorithm for converting the numbers has to be precisely determined. The algorithm is the following:

• The initial format is the complete E.164 number, including the country code (e.g. +36 1 234 5678).
• In the first step only the numbers are kept, and a dot is placed between them (e.g. 3.6.1.2.3.4.5.6.7.8).
• In the second step the previous string is placed under the ENUM root in the DNS hierarchy. For this the sequenced is given in a reverse order, and the .e164.arpa string is placed at the end (e.g. 8.7.6.5.4.3.2.1.6.3.e164.arpa).

2.4 The general working scheme of the ENUM applications

Let us examine the model of ENUM applications. Figure 2 shows the model of a typical ENUM application.

• The application (i.e. the ENUM client) generates the domain name from the E.164 format telephone number (e.g. +36 1 234 5678 -> 8.7.6.5.4.3.2.1.6.3.e164.arpa).
• Then the ENUM client software initiates a DNS query to the generated domain name.
• The data referring to the resources belonging to the given domain name and stored in the zone file on the DNS server are received in the form of so-called NAPTR records (Naming Authority PoinTeR).
• The application looks for the information referring to the requested service from the NAPTR records.
• By the content of the records the client initiates other, domain name -> IP address queries if needed.

For the different services different type of information has to be stored in the NAPTR records [5]. The information about the services in a given NAPTR record is identified by the NAPTR record's Service field as described in the 'RFC 3401-3405' (Dynamic Delegation Discovery System). The general syntax of the NAPTR records is defined by the RFC 3761 standard.

There are several trials all around the world in connection with ENUM services. There are services whose NAPTR syntax have recommendations that seem to be final, but others are still provisional. Nevertheless, we cannot speak of officially accepted standard in any of the cases.

3 Business aspects

When defining the ENUM-based services and applications, only a part of the problems are technology-related. In order to implement the services it is very important to work out the necessary and suitable business models and processes, as well as the tariff or rating schemes belonging to these models [8, 16].

3.1 Tariffs

The fields of telecommunication connected by ENUM use different rating models. While Internet usage has to be paid by flat rate, the use of the traditional telephone network is measured either in minutes or in the amount of transferred information. These different tariff solutions have to be analyzed and determined through the introductory trials. Problematic situations can occur when an ENUM service generates a redirection to a number belonging to a different rating system. These problems have to be solved. For example, if a call to a traditional number is redirected to a mobile phone, the initiator of the call presumes the tariffs belonging to the geographical number, while the operator of the end service will demand the tariffs belonging to the mobile services. In other words, the operator redirecting the call should make sure that the caller will take on the possible extra costs of the call. The other solution is that the ENUM provider compensates the end operator at the expenses of the ENUM registrant.

3.2 Regulations

When planning ENUM services questions of legal regulations have to be profoundly studied. While the traditional telecommunication world is very thoroughly regulated, exactly the opposite is true for the world of the Internet. The use of telephone numbers as telecommunication identifiers for other purposes than making phone calls is not always allowed according to present rules. The different countries of the European Union regulate this area differently [9, 14].

When introducing new services it is very important to define if they will mean telecommunication services or technological solutions for communication for the user. The world of telecommunication draws a very sharp line between these two notions. In the first case the provider is obliged to provide some availability and to guarantee emergency calls, but in the second case this is not compulsory.

3.3 Financial return

The question of financial return and value has to be very seriously considered.

In the process of introducing any kind of new communication service we have to calculate on the resistance of the other companies on the market. A currently successful provider will not support an alternative but competitive service.

We either have to implement novel solutions that offer services so far unknown to the users, or services that are able to provide already existing services for a much more favorable price. In both cases the users will force the spreading of the service on the other participants on the market.

3.4 Other aspects

When designing original ENUM services the novelty of the service is the most important aspect. Another important aspect is that the ENUM entries in the DNS are public. Since this information can be easily queried, the malicious or not proper use of the data cannot be prevented [12, 13,15, 17]. Thus only information should be stored on the DNS that can be accessed otherwise, or information that can be interpreted only by the given application, i.e. coded in some way.

There have been several ENUM trials all over the world. Some of them have already been closed and some have become commercial applications (e.g. in Austria). These ENUM trials provide useful information for all the ENUM developers [10, 13, 16].

4 New ENUM services

4.1 Query of state or presence belonging to a telephone number

A general problem is that the initiator or sender in a communication situation does not know whether the partner is accessible, or able to or willing to receive communication request. The success of building up the connection or the use of possible alternative communication channels can depend on the actual state of the partner.

This problem can be solved by using the ENUM technology because the NAPTR records can store the state referring to the availability of the partner (flag). The prerequisite of using the technology is that it has to be possible to store DNS entries that change faster than traditional DNS entries. This question has been examined, and it has been proved that by creating the suitable infrastructure the dynamic storage and changing of the DNS entries can be done.

The IT environment suitable for storing the state flags in the ENUM system has been implemented, as well as the applications to query and display the flags both on mobile and traditional platforms. The main use cases of the system using the state information are shown in Figure 3.

The main services of the implemented software are:

1. set the current state of the user
2. make an ENUM query and display the actual state of the connection.

We have worked out the final syntax of the NAPTR records that make it possible to store the flags, through the trial of the applications in an experimental environment. We are going to publish this syntax description in the form of a technical recommendation (RFC) after closing the trial test phase of the project.

During the implementation we bore it in mind that the state query application will work in a distributed environment, thus the main functions accomplishing the business logic belonging to the most important roles of the software are available through a web-service. This web-service contains web-methods through which the ENUM query and ENUM state information extraction can be easily realized. The advantage of the solution is not only that this way the graphic user interface (GUI) and the other functions of the software can be separated, but that the application has become portable by having implemented the GUI for various platforms (eg. traditional and different mobile environments). Different screens of the GUI are shown in Figure 4.

Figure 4: Screens of PocketENUM mobile application: (from left to right) Changing the actual state, Displaying the state, Making a query The icon on the left hand side of the name of the ENUM user shows the actual state of the user. The user can make query in order to request the state of other users or can change her/his own state which can be seen by others.

4.2 Storing and querying organizational hierarchy

When we are trying to get in touch with someone on the telephone, it happens many times that our partner is not available. If our partner is a member of a company or organization, it can be a solution to try to call the central phone of his/her department, where we can leave him/her a message and get information about his future availability. The problem is that how can we get hold of the central phone number?

The ENUM technology offers a solution to this problem. An ENUM entry can be stored for each telephone number that contains the phone number of the central number of the department. In this way the organizational hierarchy can be built up.

With the help of this information an application can be made that offers calling the secretary or the central number of the original partner in the case of an unsuccessful call.

A scheme of the data describing organizational hierarchy has been worked out. This scheme makes the creation of ENUM entries possible. The syntax of the suitable NAPTR records have been defined, and the IT environment capable of creating and maintaining the DNS entries storing the hierarchical data. The applications querying and displaying the hierarchy have been designed, and implemented. The general process of using organizational information for communication services is described in Figure 5.

Similarly to the previous application, web-services have been implemented for the hierarchy query software, so that hierarchy information can be easily queried with other applications as well. With the help of the web-services the hierarchy query function is embedded into the mobile

5 Summary

In our paper we have introduced the results of our applied research project aiming the development of ENUM based applications.

In the second chapter — after the introductory chapter — we have presented the ENUM procedure and the main problems in implementing the ENUM-based communication services. The technological details of the ENUM procedure are described in the technical recommendations (RFCs).

In the third chapter we have given information about the three main problem areas in connection with the business model of the ENUM service and with the introduction of new services, i.e. the questions of tariffs, legal regulations and financial return.

Chapter four describes the results of the project. Two applications based on ENUM technology have been implemented: one to query state information about the other user, and one to return hierarchy information about the partner. Both the server and the client component of the applications have been designed an implemented. The applications run in a strongly distributed environment thus we have used web-services for the implementation. This is a novel technical solution on this field. The syntax of the NAPTR records required for these applications has been developed; we are going to publish this syntax description in the form of a technical recommendation (RFC). The ongoing trial phase of our project gives us possibility to test and refine the results. Further information about the project is available on the following web-site: http://enum.sze.hu.

Acknowledgements

The research has been supported by the Hungarian Scientific Research Fund (OTKA-F046726) and the Ministry of Economy and Transport GVOP-AKF-05-0408.

References

[1] ITU-T Recommendation E.164.1: Criteria and procedures for the reservation, assignment and reclamation of E.164 country codes and associated Identification Codes (IC)

[2] ENUM Service registration for Session Initiation Protocol (SIP) Addresses-of-Record, J. Peterson, Network Working Group, http://www.ietf.org/rfc/rfc3764.txt, 2004

[3] ENUM Service Registration for H.323 URL, O. Levin, Network Working Group, http://www.ietf.org/rfc/rfc3762.txt

[4] The "ENUM" URI scheme, http://www.ietf.org/internet-drafts/draft-brandner-ENUM-uri-01.txt

[5] The tel URI for Telephone Calls (RFC 3966), (H. Schulzrinne),2004 http://rfc3966.x42.com/

[6] ETSI TS 102 172 Services and Protocols for Advanced Networks (SPAN); Minimum requirements for interoperability of European ENUM trials

[7] Global Implementation of ENUM: A Tutorial Paper, ITU - Telecommunication Standardization Sector, http://www.itu.int/itudoc/itu-t/workshop/enum/004_ww9.doc, 2002.

[8] M. Bernardi: ENUM principles and administration aspects, Presentation made at the ETNO ENUM workshop, 2002.

[9] ETSI TS 102 051: ENUM Administration in Europe, European Telecommunications Standards Institute, 2002.

[10] Dutch ENUM Group (NLEG): ENUM in the Netherlands, 2002., Researh report, p 146. www.ero.dk/381BE454-ED5B-44E6-86F5-230EE9E0E7E0?frames=no&

[11] S. Cheung, and K.N. Levitt, "A Formal-Specification Based Approach for Protecting the Domain Name System", Proceedings of the International Conference on Dependable Systems and Networks, New York City, New York, June 25-28, 2000. seclab.cs.ucdavis.edu/papers/Cheung_LevittDNS.pdf

[12] G. Ateniese, S. Mangard: A New Approach to DNS Security (DNSSEC), Proc. of the Eighth ACM Conference on Computer and Communications Security, Philadelphia, Pennsylvania, USA, November 5-8, 2001. www.cs.jhu.edu/~ateniese/papers/dnssec.pdf

[13] S. Hagnell: ENUM 2 Description of Administrative Routines for ENUM and Prestudy for the Trial, Research report, p 29. 2002. www.ero.dk/6E79E948-D20C-41DF-B4A9-F3C8C92CAF32?frames=no&

[14] P.A. Nooren: ENUM in the Netherlands — An operator's view of the current status and next steps, Presentation on the ETNO ENUM workshop, 2002.

[15] NetNumber Inc: ENUM Securiy Policy and Procedure Overwiew, Internal report, 2002.

[16] K. Reichinger: An update on situation in Austria, Presentation on the ETNO ENUM workshop, 2002. enum.nic.at/documents/AETP/Presentations/Austria/0009-2002 11_BAKOM_ENUM_Workshop.ppt

[17] P. V. Mockapetris: Telephony's Next Act, IEEE Spectrum, Volume 43, Issue 4, April 2006 Page(s):28 - 32.