A dynamic IP addressing system for Internet telephony
applications
Siu-Cheung Hui and Schubert Foo
School of Applied Science, Nanyang Technological University, Nanyang Avenue, Singapore
email: {asschui, assfoo}@ntu.edu.sg fax: (65) 792-6559
Abstract
For Internet telephony systems, it is necessary to establish a connection between a caller and recipient using the Internet Protocol (IP) address before actual voice communication can take place. A problem of dynamic IP addressing arises when the connection to the Internet is made through an Internet Service Provider (ISP) since the IP address is dynamically allocated only at connection time. This paper discusses a dynamic IP addressing system to support the establishment of connections between users. A number of dynamic IP addressing methods that are classified as on-line methods, namely, World-Wide-Web approach, Exchange Server and Dynamic Domain Name System, or off-line methods, namely, Electronic Mail and Directory Service Lookup, are proposed, implemented and contrasted.
1. Introduction
Recently, as a result of declining costs of computer hardware, advances in computer technology and phenomenal growth in Internet, a number of research prototypes and commercial products of Internet telephony systems have been developed [1] to offer real-time voice communications and other value added services over the Internet. The growing enthusiasm stems mainly from huge potential cost savings by making it possible to make transcontinental telephone calls at the prices of local telephone calls plus nominal standard Internet connectivity charges.
Internet telephony systems use the standard Internet Transmission Control Protocol/Internet Protocol (TCP/IP) suite [2] for real-time voice communications. Each host computer is identified by a unique IP address that is permanently fixed in the case of a direct connection to Internet. However, if the connection to Internet is through an Internet Service Provider (ISP), the IP address is dynamically allocated only upon connection and remains fixed during the duration of the session. The same IP address is subsequently reused and assigned to another new user. This dynamic allocation of IP addresses poses a problem for connection establishment for Internet telephony systems. Therefore, there is a need to resolve this problem before a connection between users can take place.
To resolve this dynamic IP addressing problem, most of the Internet telephony systems have adopted an Exchange Server approach [3-11]. However, the techniques implemented in these exchange servers are proprietary. Users who wish to communicate through Internet telephony system must log onto the same exchange server. The user base is limited as users are restricted within the domain of the specific telephony system. With the emergence of standards such as H.323 [12] for interoperability, a global approach is needed so that users of different products can communicate with each other.
This paper focuses on discussing a dynamic IP addressing system that supports the establishment of connections between users of Internet telephony systems. An overview
discussed. A comparison of these methods is analysed and presented. The paper then describes the architecture and implementation of the addressing system. Finally, conclusions are given.
2. Internet telephony environment
Internet
Local Area Network Host computer with audio capability
Host computer with audio capability router modem modem Internet Service Provider
Local Area Network
router
(a) Direct Connection (b) Connection via ISP
Fig. 1. Internet telephony environment.
Fig. 1 shows the basic components of an Internet telephony environment. Two host computers acting as caller and recipient are required. In using the standard TCP/IP, each host computer is identified by a unique IP address. Two possible modes of connection to the Internet are possible. Users can connect to the Internet either directly or via an Internet Service Provider. The host computer can either be a workstation or a personal computer with sufficient computation power and audio capabilities. The telephony system that resides on each host computer facilitates the real-time voice communication across the Internet.
In the basic communication process, the caller’s telephony system will acquire the real-time voice data through an audio input device and convert the analogue signals into
digitised form which is then compressed and optionally encrypted before being transmitted to the recipient through the Internet using the TCP/IP protocol. Compression is necessary to reduce the bandwidth requirement of the voice data. At the recipient’s end, the Internet telephony system carries out the reverse process. Incoming data is first decrypted, decompressed and played back in real-time on the audio device of recipient’s computer. Communication can either be half or full duplex although the second form is desired since it emulates the conventional telephone system.
The TCP/IP protocol provides two kinds of network services to application processes. Transport Control Protocol (TCP) which is a connection-oriented protocol with guaranteed delivery of data and User Datagram Protocol (UDP) which is a connectionless-oriented protocol with no guarantee of arrival of data. The protocol applies well for non-temporal data transmission but does not have any provisions to support the real-time nature of the audio. The Internet telephony system is thus constrained by this major limitation in delivering real-time service. To solve this problem, almost all Internet telephony systems use new mechanisms and descriptors to extend the TCP/IP protocol to deliver real-time service. This approach will at best simulate real-time but does not guarantee real-time delivery due to the underlying nature of the existing protocol.
3. Methods for dynamic IP addressing
The existing methods for dynamic IP addressing can be classified as on-line and off-line methods. On-line methods are different from off-line methods in that the latter provides an option for the caller to make use of off-line communication means (such as electronic or voice mail) to leave a message in cases where the recipient is not connected to the Internet.
3.1. On-line methods
connection establishment. On-line methods that include the World-Wide-Web approach, Exchange Server and Dynamic Domain Name System are differentiated in the structure and role of the server depository and the mechanism used to register and retrieve IP addresses.
3.1.1. World-Wide-Web Approach
This approach uses the World-Wide-Web (WWW or Web) and its associated HyperText Transfer Protocol (HTTP) [13] servers for resolving IP addresses. HTTP connections over the Internet are implemented using the standard TCP/IP protocol. Each WWW document or resource has a unique address known as the Uniform Resource Locator (URL) [14]. Users who are connected to the Internet and having access to HTTP servers would usually have home page directories assigned to them for putting up home pages on the Web. Information put up on such home page directories is accessible by anyone on the Internet. This in turn will allow a current user’s IP address to be published and retrieved by other users through the knowledge of the current user’s URL that is unique and fixed through the HTTP server. The URL is analogous to an electronic mail (email) address of an Internet user that is permanent and unique.
Update IP.txt periodically Internet Recipient FTP Server Retrieve IP.txt Caller HTTP Server Provide recipient’s URL 1 2 3 Send IP.txt Initiate Connection 4
Fig. 2. IP address resolution using World-Wide Web approach.
The method used for IP address resolution using the WWW approach is shown in Fig. 2. An agent (alternatively known as a process) on the user’s host computer will write the user’s information into a special file (say ‘IP.txt’) and use the File Transfer Protocol (ftp) to transfer the file to the user’s home page directory. This information stored in the file is
valid within a specified time-out period, and therefore, must be updated regularly while the application is on-line. This is necessary to overcome the problem of an abnormal disconnection (such as a power failure on the host computer) which will result in out-dated and thus invalid data left in the file. For example, the IP address of the disconnected user may be re-assigned to another user who makes a connection to the Internet following the disconnection so that the IP address defined in the file is no longer valid. This regular update of information only applies to users with dynamic IP addresses since for the case of fixed IP addresses, the information in the file needs to be defined once only.
By knowing the URL of the recipient, the caller may retrieve the information directly from the IP.txt file and initiate a connection to the recipient by using the IP address defined in the file. When the user exits from the application, the agent will correspondingly remove the IP.txt file from the user home directory. This action although desirable is not critical due to the presence of the time-out mechanism which will automatically render this file invalid after being timed-out.
3.1.2. Exchange Server
Users List + IP Addresses/ Specific User IP address User Registration Request List of Active Users/ Specific User Recipient 1 Exchange Server 1 2 Recipient 2 Recipient n Initiate Connection 3 4 Caller . . . . . . . . Internet
An Exchange Server (ES) is a dedicated server to support an application for resolving IP addresses. The main responsibility of the ES is to maintain and manage the information of active registered users running the application. It acts as an exchange to facilitate finding and connecting users together as shown in Fig. 3.
In order to support the possibility of a large number of active users at any one time, a database is usually used for storing users’ information. Basic information stored by the ES include a unique user ID, user name and current IP address. This unique ID can be special ID defined by the server, an email address, an URL or any unique identifier defined by the application.
In using the ES, an agent must first register the user’s own information with the exchange. When a connection request to a recipient is desired, a query is sent to the exchange. Two modes of queries can be supported by the ES. In the first case, the user knows the identity of the recipient and issues a specific query to the exchange to return the corresponding IP address of the recipient. In the second case, the user does not know the intended recipient and issues a general query to the exchange to return a list of active users and corresponding IP addresses and selects one for connection. The ES is basically modeled around the Internet Relay Chat (IRC) [15] server, running software designed solely to help callers using a particular program find one another. When the user exits from the Internet telephony application, the agent will de-register the user from the ES.
In order to ensure that the list of registered users is current and up-to-date, the ES will periodically ‘ping’ [16] each registered user (i.e. user’s IP port) to ensure that he or she is still on-line. This is necessary to cater for any abnormal termination of the Internet telephony application that is not being communicated to the ES. Furthermore, authentication during the ‘ping’ process is required to ensure that the ‘correct’ user is registered since the IP address could be already assigned to another user who is also registered with the ES. Users failing the ‘ping’ process will automatically be removed from the list of active users.
Variations to the basic ES architecture are possible. The agent can be replaced to accept direct user logins to the ES. Users are supplied with the same functionality to
search and retrieve other users’ information. Depending on the structure of the ES, information in the server can be partitioned and organised in some particular manner. For example, information may be organised by location, language, subject and interest so that users can register in various interest-group rooms. This will in turn support a chat-line facility to allow the user find and communicate with any other registered user in the ES. Anonymity can be supported by allowing users to use nicknames in place of their real names although a unique ID must still exist between users. Despite these variations, the basic method of using the ES to resolve dynamic IP addresses remains the same.
3.1.3. Dynamic Domain Name System
The concept of domain name was introduced in Internet to provide a mechanism to organise the large number of IP addresses into logical groups based on the organisations from which these systems belong. The Domain Name System (DNS) [17], which consists of networks of resolvers and name servers, is an architecture built to support the use of domain name as an alternative to an IP address. Resolvers are used by Internet clients for retrieving information (the IP address in particular) pertaining to the domain name from name servers. Name servers are used to manage databases for storing domain name information. Domain Name System Internet Client Internet Host 1 2 3 Internet Host Domain Name
Return IP address or Indicate Failure Initiate Connection
Fig. 4 shows the simple mechanism used for Internet connection when domain names are used in place of IP addresses. As most of the networks of Internet have access to at least one resolver, the use of domain name in place of IP address become very convenient and practical. This process eliminates the need to remember awkward IP addresses and the resolution from domain name to IP address is transparent to the user. Name servers manage two kinds of data. The first set of data is held in sets called zones; each zone is the complete database for a particular “pruned” subtree of the domain space. The second kind of data is cached data that is acquired by a local resolver. Such caching helps improve the performance of queries on domain name. Regular updates are required to keep an up-to-date information of the cached data. However, this implies that domain name changes will not be reflected immediately with the use of cached data. This does not pose much problems since the information stored in these name server databases are generally static and seldom change.
Dynamic Domain Name Daemon 1 2 Internet Client Domain Name System Name Server Internet Provide current IP address
and Personal Domain Name
Update IP address and Domain Name on Name Server Database
Fig. 5. IP address resolution using Dynamic Domain Name System.
An extension to this existing DNS architecture can be made to allow dynamic update of domain names as shown in Fig. 5. This extension, termed as Dynamic Domain Name System, provides another approach for resolving dynamic IP addressing. In this system, all changes to the domain name information can be reflected in the DNS immediately provided there is no caching done for that information. Every new connection to the
Internet is communicated to a dynamic domain name daemon whose role is to update the user’s information to the name server database. In doing so, it becomes possible to use a fixed domain name to identify an Internet host that may have a dynamic address. The normal DNS is subsequently used to resolve the IP address given a known domain name. This daemon together with the name server will be managed by an organisation that has a registered domain in the DNS.
The fixed domain name is assigned to the user by the organisation responsible for the domain. This name can take the form of <user’s domain name>.<registered domain>. In the example ‘user1.sas.ntu.edu.sg’, ‘user1’ is the user’s domain name and ‘sas.ntu.ac.sg’ is the registered domain. As in the previous Exchange Server approach, some form of ‘ping’ mechanism is used to maintain an up-to-date list of current users and cater for any abnormal disconnection.
3.2. Off-Line Methods
The off-line method basically functions similarly to the on-line method with the exception that it can still be used even though the recipient is not on-line at the time at the connection request. The method provides an answering machine facility to allow the user to leave a message for the recipient. Two methods, namely, Electronic Mail and Directory Service Lookup, offer distinct approaches to resolve the problem of dynamic IP addressing.
P o lls P O P S e rv e r fo r su c h S p e c ia l E m a il S e n d s S p e c ia l E m a il to R e c ip ie n t v ia S M T P In te rn e t P O P S e rv e r R e q u e ste r R e c ip ie n t In itia te C o n n e c tio n 1 2 3 S M T P S e rv e r E m a il
Fig. 6. IP address resolution using Electronic Mail approach.
This method utilises the concept of fixed email addresses and uses electronic mailing as a means to resolve dynamic IP addressing as shown in Fig. 6. In this design, the requester will only need to know the email address of the recipient. The Simple Mail Transport Protocol (SMTP) [18] is used to transfer a special email consisting of the requester’s IP address and other information to a SMTP server machine which in turn uses SMTP to send the mail to the world at large. The Multipurpose Internet Mail Extension (MIME) [19] format that supports multimedia and multi-part mail has been chosen for mail representation. Mail from the world at large arrives at the recipient’s Post Office Protocol (POP) [20] server where it awaits to be downloaded and processed.
At the recipient’s end, an agent will poll the POP server periodically to check for such requests for connection. Upon receiving a connection request, the agent will retrieve and delete the call request from the POP server and inform the recipient of the request. If the request is accepted, the agent will act as the caller and initiate the connection through TCP/IP using the requester’s IP addresses supplied in the email. The requester will subsequently authenticate the call and allow the connection to take place.
In this approach, a time-out period is defined in the special email to indicate the period of validity of the call request. As such systems are meant to be synchronous in nature, a connection request is terminated after being timed out. Thus, the agent will
automatically discard all outdated requests. If desired, the agent can be optionally set to inform the recipient of the existence of such requests subsequently. In addition, the requester’s end could also have an agent whose role is to monitor the same time-out period. Upon the expiry of the time-out period, the requester is correspondingly informed of the failure of the connection request and invited to submit a voice, video or electronic mail instead. This feature effectively emulates an answering machine for the requester to leave a mail for the recipient.
In addition to polling the POP server, the agent also polls the recipient’s default mail inbox since there is a possibility that during the polling interval, the default email system could have been activated, downloaded and deleted all existing messages from the POP server to the default mail inbox. This result in a drawback in this approach since there is the need for the agent to cater for various default mail systems used by different users which will exhibit different characteristics and formats for mail storage and processing. In this instance, multiple agents will be required unless some form of standardisation exists. However, this can be overcome if there is some way for the default mail system to identify and leave all such special email on the server for subsequent processing by the agent.
3.2.2. Directory Service Lookup
Directory Server Other Service Server Client 1 Client n Network of Directory Servers Telephone Lookup Server . . . . . . . . . . . . . . . . Service Layer Register IP address Assign Information to Directory Server 1 2 3 Return IP address 5 Request IP address 4 Extract Information from Directory Server
Other Service
Server
A complete profile of users’ information can be stored in the Internet by using a network of databases known as Directory Servers. From this network of databases (or clusters), the information of any user on the Internet can be retrieved. Various servers with different purposes and support can be built as a service layer between Internet users (clients) and these directory service clusters as shown in Fig. 7.
An example of a service server would be a telephone lookup server that functions similarly to a telephone exchange server. Additional functions and superior facilities can be added to these servers depending on the level of services offered and the amount of information stored in the directory servers. For example, the telephone lookup server may support a query requesting for a list of IP addresses of users of a particular age group with a particular set of interests and living within a certain area of the country.
The mode of usage of the service server is similar to the exchange server. Users with dynamic IP addresses will register this information (plus other temporary information that are set at connection time) to the appropriate directory server. In order to make a connection to the recipient, a query for an IP address is sent to the service server which will in turn retrieve this information from the directory server a nd channel it back to the requester. An initiate connection request is subsequently issued by the caller to the recipient.
A possible architecture for these directory servers is to use a geographic approach and organize them in clusters according to the country which they serve. Each cluster will consist of directory servers in a hierarchical manner to serve st ates, which in turn serve areas which serve users. This structure results in a hierarchical tree with the world as the root of the tree. Each sub-tree pertains to individual countries. The depth of the sub-tree will be dependent on the number of users that it serves. The architecture must be able to support the dynamic addition, removal and modification of directory servers and user information to the directory service as well as support simple and complex query and retrieval of information.
The motivation of using such a directory service is to provide a global White Pages service to facilitate global communications over computer networks in an efficient manner. Although the Directory Service Lookup approach was originally conceived to handle IP addressing problems, it nonetheless has resulted in many similar ideas and characteristics with the existing X.500 directory service [21]. Since the focus of this paper is on techniques for resolving dynamic IP addressing, the differences between these directory services are of secondary importance and therefore would not be addressed.
3.3. Analysis and Comparison of Methods
All the proposed methods require some form of server depository for stori ng IP addresses that can be retrieved by the user. Depending on the method adopted, these servers are either stand-alone dedicated servers (Dynamic DNS, Directory Servers), or dedicated servers (Exchange Servers) that are part of the application, or general servers (such as Email or Web Servers) which are an integral part of the Internet environment.
A number of factors have been used as a comparison between methods to gauge the efficiency and effectiveness to resolve dynamic IP addressing. These factors include:
• Efficiency or Speed of Resolution. This factor refers to the time taken to resolve the IP
address and allow a connection between users to take place. Users would obviously prefer the method that exhibits the shortest time.
• Ease of Use and Acceptability. This factor relates to the ease-of-use of the method
and the potential of users’ buy-in. Users would prefer to use a simple and transparent method without the need to acquire new skills or change their current practices.
• User Base Scope and Accessibility. This factor refers to the numbers of users that can
be maintained by a particular method and the accessibility of this information by anyone on the Internet.
• Set-Up Parameters Required. This factor pertains to the number and complexity of
the set-up parameters that are required in order to use the method. Obviously the least number of parameters are desired.
• Visibility of Available Users. This factor indicates the provision of the method to
support a query for an active list of users, or more specifically, to support a chat-line facility where the intended recipient is not identified beforehand.
• Robustness and Resilience. This factor considers the robustness and resilience of the
method and the circumstances in which it will fail to work. To some extent, this factor will depend on the resources under control. For instance, if a mail server serving the intended recipient is down, then it becomes impossible for the Electronic Mail method to proceed since the mail will not arrive at the server. In this case, the mail server is an external but necessary entity outside the control of the method.
• Ease of Implementation and Associated Overheads. This factor examines the ease at
which the method can be implemented and the overheads required to maintain it.
World-Wide-Web Approach Exchange Server Dynamic Domain Name System
Efficiency or Speed of Resolution slow medium fast
(Average time, t(s)) (3 < t < 300) (1 < t < 180) (1 < t < 4)
Ease of Use and Acceptability poor moderate good
User Base Scope and Accessibility high low high
Set-Up Parameters Required moderate few few
(Number of Parameters) (3) (2) (2)
Visibility of Available Users poor good poor
Robustness and Resilience good not bad not bad
Ease of Implementation easy most difficult difficult
Table 1. Comparison of on-line methods.
These factors have been used to rate each of the method under comparison. The results for the comparison of on-line and off-line methods are shown in Tables 1 and 2 respectively. These factors are ranked relative to each other. Whenever possible, quantitative data has been provided. However, absolute data may not be realisable due to
the possible variations in implementing these methods. For example, the exchange server may be implemented as a query and retrieval model or an IRC model thereby resulting in significantly different speeds of IP address resolution. In such instances, a range of values is provided. In addition, average times are measured and used to cater for fluctuations in network conditions.
In the on-line method, the Dynamic DNS is the preferred method for IP address resolution. It is fast, easy-to-use and transparent to the user. Upon connection to the Internet, the dynamic domain name daemon will register the required information to the DNS system. Subsequently, the standard DNS will be used to resolve the address. Furthermore, this method is general and allows any Internet application to make use of it directly without any additional overheads. The method is suitable for resolving the IP address of a known recipient. Such a service can be offered by an individual or organisation who has a registered domain in the DNS. However, it is likely that it will be offered by ISPs as part of a standard service in future.
The Exchange Server is probably the first and most common method currently in use for resolving IP addresses. It has been adopted by many Internet telephony applications due to its simple concept and its ability to provide an early solution to the dynamic IP addressing problem. This approach has been widely adopted by almost all existing Internet telephony systems. Systems using this approach can either use a global server (e.g. FreeTel [3], CoolTalk 1.0 [5]) or a set of distributed servers (e.g. Internet Phone 3.2 [4], Internet Connection Phone [11]) to implement the exchange. From the developers’ point of view, the exchange allows them to keep track of their customer base, monitor volume and usage patterns, and provide support and services (e.g. advertisers) for their customers.
The World-Wide-Web approach uses a novel way to resolve dynamic IP addressing. The method requires the knowledge of the intended recipient’s URL in order to be able to extract the desired information prior to connection. The method is not so elegant compared with the rest due to the overhead of having to update the information on the HTTP server to ensure that it is kept up-to-date. However, this method eliminates the
use of standard Internet facilities and services that are likely to be more robust and reliable.
Electronic Mail Approach Directory Server Look-Up
Efficiency or Speed of Resolution slow fast
(Average time, t(s)) (10 < t < 3600 (timeout)) (1 < t < 30))
Ease of Use and Acceptability good moderate
User Base Scope and Accessibility low high
Set-Up Parameters Required many few
(Number of Parameters) (7) (2)
Visibility of Available Users poor good
Robustness and Resilience good not bad
Ease of Implementation difficult most difficult
Table 2. Comparison of off-line methods.
Between the two off-line methods, the Directory Service Lookup offers a better solution for dynamic IP addressing. The approach basically mirrors the Exchange Server approach in that it relies on the existence of servers, user registration and query support. Although it is arguable that the method is the same, the intended concept of using the directory service is different and should be viewed as one of the services provided by the directory service clusters. Like the Dynamic DNS, the directory service is general and designed to service all Internet users and not any particular application. Depending on the services offered by the service layer, a total integrated communication system becomes possible to allow cross-media exchange of information. In addition, due to the flexibility and scope of information that it can support, it will invariably be able to exhibit superior functions over the exchange server.
The Electronic Mail approach uses a fixed email address concept to deliver a special email to the intended recipient who will in turn act as caller to establish the communication process. Although it is a workable solution, the main concern is the possible unacceptable time latency before communication can take place. The method relies on SMTP servers to transmit the mail to its destination. In some of our tests, it was found that the mail took longer than the time-out period to reach its destination, thereby immediately rendering the method inapplicable! Even when acceptable times are attained for mail transmission, there is a need to carefully define the polling time period to attain a
compromise so that the CPU is not swamped with frequent periodic polling and yet able to deliver an acceptable level of service.
4. Dynamic IP addressing system
U s e r I n t e r f a c e Mail Service Accept Voice Mail Graphical Viewer WWW Approach Exchange Server Dynamic DNS Directory Service Lookup Auto Mode SMTP Server HTTP Server FTP Server POP3 Server Directory Servers Telephone Exchange Daemon Domain Name System
Dynamic IP Addressing System Call Management Addressing Methods Internet User Electronic Mail Utility
Reject Call End
Authentication
Fig. 8. System architecture.
A dynamic IP addressing system is developed at the School of Applied Science, Singapore. The system provides support for making a call request, establishing or tearing down of connections and waiting for incoming calls. Fig. 8 shows the system architecture of the dynamic IP addressing system. The various servers including the FTP Server, HTTP Server, POP3 Server, SMTP Server, Domain Name System, Telephone Exchange Daemon and Directory Servers are located on the Internet. The system consists of five major components, namely, Call Management, Utility, Addressing Methods,
Authentication and User Interface. Call Management is responsible for initiating,
accepting, rejecting and terminating calls. Utility provides functions such as mail services, voice mail and graphical viewer for users. Addressing Methods supports
supports an auto-mode that executes the on-line methods in a pre-defined sequence in an automatic and efficient manner. Authentication is carried out to ensure that the recipient is the intended party that the caller intends to reach. Finally, the User Interface provides a user-friendly environment for using the system.
4.1. User registration
Fig. 9. Logging onto the interface system.
When a user logs onto the system, the system will list out all the users’ names that are registered. This facilitates sharing of the system by multiple users. Fig. 9 shows the interface for logging onto the system. The user can simply double click the name and the system will automatically load his system configuration information. If the user has not registered previously, a click on the Add New button will pop up a set-up parameter property sheet and allow the user to enter the system configuration information. Fig. 10 shows an example of set-up parameters property sheet for the Electronic Mail approach. In this property sheet, the user is required to specify the domain names (or IP addresses) for the SMTP and POP3 servers, the user name and password for accessing the SMTP server and the user's real name, and if applicable, the default mailbox path. Similarly, the user needs to specify the set-up parameters for other addressing methods if these are to be supported.
[USER]
NumberOfUsers=2 USER1= <user1’s name> USER2= <user2’s name> [<user1’s name>]
SMTP Server = <Host name or IP address of SMTP server> POP3 Server = <Host name or IP address of POP server> Userid = <User’s ID for logging into the mail server>
Password= <User’s password for logging into the mail server> Username= <User’s real name>
InboxPath= <Path of the default mail inbox> CallerID= <User’s ID for Daemon> CallerName= <User’s name used by Daemon>
DaemonHost= <Host name or IP address of the Daemon> FtpSite= <Host name or IP address of FTP server>
FtpUser= <User’s ID for logging into the FTP server> FtpPasswd = <User’s password for logging into the FTP server> DirServHost= <Host name or IP address of the Directory Server>
IPphoneNum= <User’s Internet Phone Number assigned by Directory Server> EmailAddr= <User’s e-mail address>
URLLoc= <User’s URL location> [<user2’s name>]
………
Fig. 11. User profile.
Currently, users’ information including set-up parameters are maintained in a user profile. The format of the profile is shown in Fig. 11. Eventually, a database system will
4.2. User interface
Fig. 12. User interface.
Fig. 12 shows the user interface of the system. The user interface is divided into three major areas, namely, Receive/Place Call, Utility and Mode Selection. The Receive/Place
Call area supports the call management functions. The user clicks the Accept or Reject
button for an incoming call, and the Call button to place a call after obtaining the recipient’s IP address. The End button is used to terminate a call. The picture box in the left upper corner optionally displays the user's own face image for placing a call and the other party’s face image when answering a call.
The Utility area provides additional utilities to the user apart from calls management. These include a Mail Service which acts as a normal mail system, a Voice Mail that allows the user to leave a voice message if the recipient is off-line and a Graphical Viewer for viewing an image file prior to use. Fig. 13 shows the user interface for the Voice Mail utility.
Fig. 13. User interface for Voice Mail utility.
The last area, Mode Selection, defines the different on-line and off-line methods to resolve the dynamic IP addressing problem. In order to give the user the flexibility in establishing connections, the system allows users to choose one of the on-line or off-line addressing methods to find the recipient’s IP address. In addition, the user can also choose the Auto Mode option. If this is chosen, the sequence of invoking the three different on-line methods becomes important. From the previous discussion in section 3.3, the execution of the three on-line methods in the sequence, Dynamic Domain Name Service, WWW approach and Exchange Server will give the best possible way in setting up the connection. The algorithm for the auto mode operation is illustrated in Fig. 14.
O n -l in e M et h o d s Start Retrieve IP address from recipient’s URL
Successful ? Retrieve IP address from Telephone Exchange Daemon
N
Y
Inform user the failure of the auto mode
N End Set up connection through TCP/IP Y Entry Found ? Scan user list for
desired party
World-Wide-Web Approach Telephone Exchange Approach
Resolve IP address by giving recipient’s domain name
Successful ? N Y Dynamic Domain Name Services Approach
Fig. 14. Algorithm for auto mode operation.
In addition to the three major areas, there is an icon on the right of the Utility area that can be activated to view the other party’s personal information when the conversation is in progress. Moreover, there are two message boxes that are used to display communication messages for both caller and recipient to keep them informed of the status of the connection.
Upon connection establishment, authentication is carried out to ensure the recipient is the right person that the caller intends to reach. This is necessary because it is possible that the IP address of the intended recipient has been assigned to another user in the event of an abnormal disconnection (such as a power failure, system crash, etc.). To do this, information such as the recipient’s name, e-mail address and user ID are sent to the recipient site. This is used to uniquely identify a user. The recipient will check and verify the information and returns the authentication result to the caller. Once confirmed, the caller may proceed to communicate with the recipient.
5. Conclusions
In this paper, a dynamic IP addressing system for establishing connections between users is discussed. The system is developed under Microsoft Windows environment. In the system, a number of dynamic IP addressing methods have been implemented. On-line addressing methods that include the World-Wide-Web approach, Exchange Server and Dynamic Domain Name System can only be used when both caller and recipient are connected to the Internet. On the other hand, off-line methods that include Electronic Mailing and Directory Service Lookup can still be used even though the recipient is not on-line. This is achieved by having a provision for an answering machine facility for the caller to leave a message for the recipient. In addition, an automatic mode of addressing which uses the three on-line methods in a pre-defined sequence is also implemented. Currently, the system has been successfully incorporated into an Internet telephony system known as Internet Heterogeneous Phone (IHPhone) [22] developed at the School of Applied Science, Singapore. Apart from Internet telephony applications, the system can also be applied to other synchronous distributed applications such as video-conferencing applications for dynamic IP address resolution.
6. Acknowledgements
We wish to acknowledge the contributions of Yip See Wai and He Yulan to the work in this project.
[1] Internet Telephony Consortium, Internet Telephony Software and Services, <URL: http://rpcp.mit.edu/~itel/software.html>.
[2] D. Comer and D. Stevens, ‘Internetworking with TCP/IP’, Prentice Hall, Englewood Cliffs, NJ (1991).
[3] FreeTel Communications Inc, FreeTel 1.00 <URL: http://www.freetel.inter.net/>. [4] VocalTec Inc, Internet Phone 3.2, <URL: http://www.vocaltec.com/>.
[5] Netscape Communications Corp, CoolTalk 1.0, <URL: http://www.netscape.com/>. [6] NetPhone Inc, NetPhone, <URL: http://www.emagic.com/>.
[7] Netspeak Corp, WebPhone 1.04, <URL: http://www.netspeak.com/>.
[8] Third Plant Publishing, DigiPhone 1.03, <URL: http//www.planeteers.com/>. [9] J. Walker, Speek Freely for Windows, <URL:
http://www.fourmilab.ch/netfone/windows/doc/sfunix.html>.
[10] Voxware Inc, TeleVox 0.3 (beta), <URL: http://www.voxware.com/>.
[11] IBM Corporation, Internet Connection Phone, <URL: http://www.ibm.com/>. [12] Internet Telecommunication Union (ITU), Draft ITUT Recommendation H.323
-Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service, May (1996).
[13] World Wide Web Consortium, HyperText Transfer Protocol. <URL: http://www.w3.org/hypertext/WWW/Protocols> (1993).
[14] World Wide Web Consortium, Uniform Resource Locators. <URL: http://www.w3.org/hypertext/Addressing/URL> (1993).
[15] Prospero Systems Research Inc, IRC - Internet Relay Chat, <URL: http://he.net/~prospero/globalchat/help/irc/irc.html> (1995).
[16] G. Mark, Ping using ICMP, <URL:http://users.redrose.net/~markg/ieping.html>, 1996.
[17] P. Mockapetris, Domain Names - Concepts and Facilities, RFC 1034, November 1987.
[18] B.J. Postel, Simple Mail Transfer Protocol, RFC 821 (1982).
[19] N.S. Borenstein and N. Freed, MIME - Multipurpose Internet Mail Extensions: Part
1: Mechanism for Specifying and Describing the Format of Internet Message Bodies, RFC 1521 (1993).
[21] CCITT, X.500 Directory Service, Blue Book, Volume VIII - Fascicle VIII.8, Data Communication Networks Directory, Recommendations X.500-X.521 (1988). [22] S.C. Hui and S. Foo, ’Towards a standards-based Internet telephony system,’
