On building an Internet gateway for Internet telephony

(1)

ON BUILDING AN INTERNET GATEWAY FOR INTERNET TELEPHONY

Cheng- Yue Chang and Ming-Syan Chen

Electrical Engineering Department

National Taiwan University

Taipei, Taiwan, ROC

In recent years, the Intemet has emerged as an important collaborative platform. Many applications utilize the Inter- net to provide new kinds of services. Among others, In- ternet telephony is attracting an increasing amount of attention for the reason that it has the potential to significantly reduce the cost of long distance voice communication. In view of this trend, it is very important to construct a PSTN/Internet gateway for further experiments and developments. In this paper, we explore several methodologies for the implementation of a PSTN/Intemet gateway. Based on these methodologies, we devise the corresponding architecture and implement a PSTN/Intemet gateway. Following the ITU H.323 recommendation, the gateway built is interoperable with other H.323 compatible terminals. We also validate the gateway built by having fluent two-way communication between a PSTN phone and an H.323 terminal.

A performance study on the sensitivity of the buffer size is also conducted. It is noted that the gateway devised is very versatile and can be easily extended to support various applications.

1. INTRODUCTION

Recent technology advances have brought revolutionary im- pacts to our life. The Intemet emerges as a collaborative platform nowadays and it is envisioned to be even more important for years to come. Lots of applications utilize the In- ternet to provide new kinds of services, such as information services, entertainment, and communication services [ 1][2]. Search engines, for instance, provide information-searching services over the Intemet. Distance education, as another example, makes it possible that the instructor and the students do not need to be physically present in the same lo- cation, allowing rural students to have the same opportunity for education as urban students.

Among others, real-time transmission of voice over the Internet, also known as Intemet telephony, is attracting an increasing amount of attention [3][4][5]. Many archi- tectures and signaling protocols are proposed in [6][7][8]

to provide the Internet telephony service. The reason for the importance of Internet telephony is that Intemet telephony has the potential to significantly reduce the cost of long distance voice communication. Additionally, Inter- net telephony introduces entirely new and enhanced ways of communicating. Video conferencing, application shar- ing, and white-boarding are some typical applications that exploit real-time voice communication over the Intemet. Note that, in addition to phone-to-phone communication, PSTNlIntemet gateways can be used to provide phone-to- PC and PC-to-phone communication.

In view of the huge benefits the PSTNhtemet gateway can bring, it is of both theoretical and practical importance to construct one for further experiments and developments. The goal of the paper is thus to design and implement a PSTNIIntemet gateway for Intemet telephony. Through this gateway, the PSTN user can connect to any Intemet user who uses an H.323 [9][10][11][12] compatible terminal (such as Microsoft NetMeeting or Intel Intemet Video Phone), and vice versa. In this paper, we explore several methodologies for the implementation of a PSTNhtemet gateway. Based on these methodologies, we devise the corresponding architecture and implement a PSTN/Intemet gateway. As will be explained in detail later, the host ap- plication of our implementation can be fkrther divided into three major components, i.e., PSTN Event Retriever, State Machine Manager and Audio Channel Manager. We have successfully implemented the PSTNLntemet gateway and validated the system built by having fluent two-way communication between a PSTN phone and a Microsoft Net- Meeting terminal. A performance study on the sensitivity of the buffer size has also been conducted.

It is worth mentioning that the gateway we devised is very versatile and can be easily extended to support various applications. Specifically, we extended our gateway to a call center providing voice-mail services over the Intemet. The user may take advantage of this service to leave a message for the called party if the line is busy or there is no one answering the call. As a matter of fact, many other appli- cations are conceivable. With the PSTNhtemet gateway prototype, we are able to do proper modifications to cer-

(2)

tain software components and obtain the customized applications we need very efficiently. This is the very advantage we have by implementing this PSTNAnternet gateway by ourselves.

The paper is organized as follows. The architecture of the PSTN/Intemet gateway proposed is introduced in Section 2. In Section3, we explain the implementation of the gateway, and develop a customized application for illustration. Per- formance analysis of the gateway buffer size is included in Section 4. Finally, we conclude this paper with Section 5.

2. METHODOLOGY FOR BUILDING A PSTNDNTERNET GATEWAY

In this section, we will present methodologies for building a PSTNAntemet gateway. We design state machines for the gateway to maintain existing calls in Section 2.A. The architecture of our gateway is described in Section 2.B. 2.1. State Machine Design

A call is a point-to-point multimedia communication between two endpoints. The call begins with the call setup procedure and ends with the call termination procedure. Since each call has its own progression, i.e., Idle, Offer- ing, Connected, Disconnected, etc, we can utilize a state machine to manage the call. The key elements of a state machine are initial state, final state, intermediate states and transitions between states. We will define the call-states, call transitions and state diagram for our PSTN/Internet gateway in this section.

A call-state is a stage of a call progression. A call is created in one of the following two conditions:

-

The H.323 Protocol Stack notifies that a call from the Internet arrives.

-

The PSTN interface card notifies that a call from the PSTN arrives.

For a newly created call, the initial state is set to Idle. Then, each call moves from state to state as the call con- nection is established, connected, and concluded. The particular state of a call is in determining what commands and actions can be performed. Such states are called valid states for a particular command. If a command is issued when the

call is not in a valid state for that command, an error occurs. Each call maintains a current state. The transition from the current state to a new state is triggered by messages or events relating to the call. Note that the determination of the occurrence of an event is important. We can divide this issue into two parts. The first one is how the events from the PSTN side are detected. Using the Dialogic API, we implement a module, PSTN event retriever, to detect the occurrence of the events. The Dialogic PSTN interface card adds a message to its own event queue while its status is changed. Hence, we can detect the events from the PSTN

0-7803-6536-4/00/$10.00 (c) 2000 IEEE

by using the call status transition event h c t i o n s of Dialogic API to keep retrieving events from the event queue.

The second part is how the events from the Internet side are detected. To detect the events from the Internet side or H.323 system side, we.first set up the event handlers by calling the library functions of the H.323 Protocol Stack, and then receive the stack callbacks.

Figure 1 shows a constructing element of a state diagram. Each state is represented by an ellipse that contains the state name. The states are connected with arrows indicat- ing the valid call-state transitions. Each call-state transition includes two parts. The upper one is the message used to cause that state changed and the initiator of the message. The lower one is the responding actions of the host application. According to the principle we can construct the state machines for a call form the PSTN to the Internet and a call from the Internet to the PSTN.

Message Initiator Event \

-

PLAYWAVEO

k,

Wait-For-Digits

U

Responkng actions

of host application Figure 1 : State Diagram Explanation

2.2. Architecture of Our Internet Telephony Gateway Next, we construct the architecture for our PSTN/Intemet gateway. The gateway consists of four layers and is depicted in Figure 2. The four layers are composed of a network interface layer, an operating system layer, an application pro-

gram interface (API) layer and a host application layer. The network interface layer is the bottom of the architecture, and is the physical layer of the architecture. It consists of two network interface cards, Ethernet interface card and PSTN interface card.

PSTN Internet

(3)

Figure 2: The architecture of our Intemet telephony gateway

The operating system layer manages the network interface layer, and provides the upper layer with the common operating system services. These services include network operations, dynamic memory allocations, run-time libraries, system timer, and print. We adopt Microsoft Windows NT Server as our operating system because of the interoperabil- ity between API and the NT operating system layer and also the ability of the NT operating system to execute programs in the multi-thread mode.

The application program interface layer consists of Dia- logic API [ 131 and the H.323 Protocol Stack API. Dialogic API provides programmers with a set of libraries to make use of the PSTN interface card while H.323 Protocol Stack API implements the mandatory elements of H.323 as function libraries.

The host application consists of three major modules: State Machine Manager (SMM), PSTN Event Retriever (PER) and Audio Channel Manager (ACM). The function blocks of the host program are shown in Figure 3. For existing calls, the host application maintains independent state diagrams in the system. Hence, we design a module, State Machine Manager, to manage these state diagrams. The SMM keeps track of the call-state for each call, and trig- gers the call-state transitions by retrieving events from the PSTN interface card and the callback from the H.323 Proto- col Stack. The responsibility of the PSTN Event Retriever is hence to keep retrieving events from the event queue of the PSTN interface card.

F

k

Initiate/End

c

Figure 3: The function blocks of host program we devised Audio Channel Manager (ACM) is designed to conduct the buffering between PSTN interface card and the H.323 protocol stack. ACM is created for each call after the audio channels have been opened. For each call from PSTN to Intemet (explicitly, NetMeeting in this very case), it uses the VO functions of Dialogic API to retrieve the audio data

from the PSTN interface card and buffers the data with our buffering mechanism. Then it packetizes and transmits the

audio data to the called party by the library functions of the H.323 Protocol Stack. For the data flow toward the other direction, ACM receives and unpacketizes the audio packet by the library functions of the H.323 Protocol Stack. Then, it buffers the audio data, and finally uses the I/O functions of Dialogic MI to play it out.

3. DEVELOPING CUSTOMIZED APPLICATIONS It is worth mentioning that the gateway we devised is very versatile and can be easily extended to support various applications. For illustrative purposes, we extended our gateway to a call center providing voice-mail services over the Internet. Consider the following example. A PSTN user wants to make a call to his fiend on the Intemet. However, the line is busy or there is no one answering the call. In this case he would like to leave a message for his friend. Using our gateway, a call center is designed to support this service. The call center asks the caller to leave a message whenever he fails to make a call. If the user would like to leave the message, the call center asks for the receiver’s E- mail address and begins to record his message to a WAVE file. Then it encodes the file according to MIME [ 141 format and sends the file as an email to the receiver.

To provide this service, we insert two new states, Wait-ForAddress and Wait-ForMessage to the state machine for a call form PSTN to the Internet. The host application is notified that one call is disconnected, and then it prompts the PSTN user to enter the receiver’s E-mail address (i.e., by calling dx-play() and dx-getdig()). The state then transits to Wait-For-Address. Once the user has fin- ished entering the receiver’s E-mail address, the host application is notified by the message, TDX-GETDIG, retrieved by PSTN Event Retriever. It then begins to record the message (i.e., by calling dxl-ecord()), and the state transits to WaitJorMessage. Wait-For-Message waits for the com- pletion of recording the message until the host application is notified by the message, TDX-RECORD, retrieved by PSTN Event Retriever. It then saves the recorded file for later encoding and sending. The state transits to Idle. Note that within the above two states, the PSTN user may hang up the call, and the state transits to Idle directly. As a matter of fact, many other applications are conceivable. With the PSTN/Intemet gateway prototype, we are able to do proper modifications to certain software and obtain the customized applications we need very efficiently. This is the very advantage we have by implementing this PSTNAntemet gateway by ourselves.

4. PERFORMANCE ANALYSIS

The performance of our PSTNIIntemet gateway is defined as the continuity of the speech from the remote party. The primary effective variable of the continuity is related to

(4)

inter-arrival jitters between received audio packets. In or- der to improve the performance of our gateway, we shall minimize the number of the occurrences of inter-arrival jitters. The approach we employed is to pre-buffer some audio packets in the Audio channel Manager. As a result, when an inter-arrival jitter is long, Audio Channel Manager can still consume the pre-buffered data to keep the playback speed over the active voice channel on the PSTN interface card. The more data pre-buffered, the less likelihood the system buffer will become empty. However, having more data pre- buffered means a longer delay between the speaking party and the receiving party. Therefore, we have to make a trade- off between pre-buffered data size and the number of times which the buffer is consumed to be empty.

To choose an optimal pre-buffered data size for our gateway, we measure the number of times when the buffer becomes empty under various pre-buffered data sizes. Two

_{_ _}

experiments, for

are conducted.

the duration- of 3 minutes and 5 minutes,

0 256 512 768 1024 12@ 1536

prebuffered

data

size

Figure 4: Experimental Result

As shown in Figure 4, the experimental result indicates that when the pre-buffered data size is set to be 1024 bytes, the number of times when the buffer becomes empty is al- most 0, implying that a pre-buffered data size of 1024 bytes is proper for this experiment.

5. CONCLUSIONS

In this paper, we designed and implemented a PSTNhtemet gateway for Intemet telephony. The gateway is designed to follow the ITU H.323 Recom- mendation, and is hence interoperable with other H.323 compatible endpoints on the Intemet. By this gateway, we not only interconnect the PSTN and the Intemet, but also exploit the advantages of the two wide-area-networks. We proposed the architecture of a PSTNhtemet gateway. Based on the architecture, we implemented the PSTN/Intemet gateway, and conducted several experiments in this prototype. We have validated the gateway built by having fluent two-way communication between a PSTN

phone and an H.323 terminal. A performance study on the sensitivity of the buffer size has also been conducted. It is noted that the gateway devised is very versatile and can be easily extended to support various applications.

6. ACKNOWLEDGMENT

The authors are supported in part by the Ministry of Educa- tion Project No. 89-E-FA06-2-4-7 and the National Science Council, Project No. NSC 89-2219-E-002-007 and NSC 89-221 3-E-002-032, Taiwan, Republic of China.

7. REFERENCES

1774

B. Braden, D. Clark, and S. Shenker, “RFC 1633: Integrated Services in the Intemet Architecture: An Overview,” F. Fluckiger, Understanding Network Multimedia Applica- tion and Technology. Prentice Hall, 1995.

M. Am, J. F. Kurose, D. S . Reeves, and H. Schulzrinne, “Real-time Communications in Packet-switched Networks,”

Proceedings of the IEEE, vol. 82, pp. 122-139, January 1994.

C. A. Polyzois, K. H. Purdy, P. F. Yang, D. Shader, H. Sin- nreich, F. Mard, and H. Schulzrinne, “From POTS to PANS

-

A Commentary on the Evolution to Intemet Telephony,”

IEEE Network, vol. 3, MayIJune 1999.

C. Reyes-Aldasoro and F. Kuhlmann, “Telecommunications and Intemet in the Future Society: Myths and Realities,” in

Computers and Communications, 1999. Proceedings. IEEE

International Symposium on, July 1999.

C. Huitema, J. Cameron, P. Mouchtaris, and D. Smyk, “An Architecture for Residential Intemet Telephony Service,”

IEEE Network Vol.13, pp. 50-56, May-June 1999.

H. Schulzrinne and J. Rosenberg, “Intemet Telephony: Ar- chitecture and Protocols

-

an IETF Perspective,” Computer

Networks and ISDNSystems vo1.31, pp. 237-255, Feb. 1999,

G . A. Thom, “H.323: The Multimedia Communications Standard for Local Area Networks,” IEEE Communications

Magazine, pp. 52-56, December 1996.

CCITTIITU-T, “Recommendation G.711: Pulse Code Mod- ulation of Voice Frequencies.”

ITU-T, “Recommendation H.225: Media Stream Packetiza- tion and Synchronization on Non-guaranteed Quality of Ser- vice LANs.”

ITU-T, “Recommendation H.323: Visual Telephone Systems and Equipment for Local Area Networks which Provide a Non-guaranteed Quality of Services.”

ITU-T, “Recommendation Q.93 1 : ISDN User-network Inter- face Layer 3 Specification for Basic Call Control.”

User S Manual: Voice Programmer S Guide for Mndows NT.

Dialogic Corporation, 1996.

N. Borenstein and N. Freed, “RFC 1521: MIME (Multi- purpose Intemet Mail Extensions) Part 1

-

Mechanisms for Specifying and Describing the Format of Intemet Message Bodies.”

On building an Internet gateway for Internet telephony