Project: Internet Telephony

Title: Project Report

Group and team number: G1, Team 3 (Gateway)

Team members: Char Shing Wilson Ng (cwn1@cornell.edu), Hubert Siu (hys2@cornell.edu)

Date: 12/17/1998

1. What did you set out to do? (1-2 pages) Use a figure and accompanying text to describe what you set out to do. You can reuse part of your first report if you wish. You should have sufficient detail so that someone who is not familiar with the project would still be able to understand the scope of your work. For instance, imagine giving this to a friend who is not in the class--write something that this person would be able to understand without having to ask you for help.

The first thing that we set out to do was to familiarize with the task we need to accomplish as a gateway team. From the big picture, we understand that our primary job is to transfer voice data from the telephone network to the Internet network, and vice versa. To make this two different networks communicate with each other, certain things need to happen on the signaling plane and data plane in order to set up a proper environment for them to "talk" to each other. For example, on the signaling plane, the gateway needs to be notified when a call is initiated, from where it is initiated, when the call is established successfully or not, when a user presses the numbers on the telephone, when the established call is later hung up, etc. On the data plane, once the call is established successfully, the gateway needs to begin voice data transfer between the two end points, which means receiving voice samples from the telephone side and sending them out as IP packets to the internet side, and vice versa.

After understanding from the high level, big picture, we first developed our project schedule (attached as Appendix A), and started to do research. The first thing we need to get familiar with is the Dialogic card, the main gateway hardware interface to the telephone side. This card basically handles all sort of defined events happening on the telephone side such as picking up analog signal from the telephone line (and generates events such as ringing, dialing, key press, hang up phone, pick up phone, silence tone, non-silence tone, record and play, etc.), voice compression and depression, buffering digitized voice samples to user memory, etc. Therefore, we consulted through dialogic card documentation manuals to understand its functionality. Particularly, we emphasized on understanding the API library, which provides interfaces to control and drive the card. The online help on Vada, the three .pdf files provided on the cs519 homepage (srlapint.pdf, voxapint.pdf, voxftgnt.pdf) were the main resources.

With this preliminary understanding in mind, we worked out our 1^st draft pseudo interface for the gateway, and planned to start interacting with other teams. In this initial stage, we were planning to generate solutions to problems that we might encounter. For example, format of the signaling packets being send and receive between signaling team and us, and also audio format and sampling frequency between data team and us. Also, we needed to discuss with signaling team on defining interface, handshaking protocols between us.

The next step that we planned to take was to start working on the design of our gateway module. We need to work on the interface that we will be providing to signaling team, and we planned to start listing different events caught from the Dialogic card that we might be interested. There are a few basic events that we planned to work on first: (1) to detect whether the channel has been called (ring); (2) to detect whether that channel is busy; (3) to detect the numbers that the user on the phone has punched; (4) to detect whether the current state is recording (for transferring voice samples from the phone to PC) or playing (for transferring voice samples from PC to phone); (5) to detect whether the user on the telephone has hung up. In order to carry out experiment of those interested events, we decided to write a simple Gateway testing prototype (extended from the given sample program) to tried implementing them. Afterwards, we moved on to experiment functionality provided by Dialogic API (for example, setting the channel to off hook when it received ring event; setting the channel to on hook when it received hung up event; dialing out to a phone number and wait for connect event, transmitting/receiving voice samples in connection state, etc.). We understood that it is useful if we can have programs for testing our code, so we planned writing some dummy program for testing our gateway module, just to make sure that our code works according to the specifications that our group has agreed on before we later on integrate with other teams, so as to reduce time to debugging during integration stage.

With the clear understanding of point-to-point connection design being experimented and worked out, we planned to move on to handle multi-conferencing. We need to design interface of how to setup, join, leave, and tear down conference call. We also need to figure out how to average voice samples coming from several sources and multicast them to the destinations. We also planned to do testing with other teams involved in audio conferencing while we are writing the code, so that we can make sure our code works with all the other teams. We have planned to finish implementation before November 22.

After we have finished with our conferencing interface, we planned to do our integration with the rest of Group 1. In particular, the priority is given to data and signal team first because we are in lower protocol layers to support all other application layers. This will be the time that we planned to fine-tune our code to make sure that it works with the rest of the group.

2. What did you actually accomplish? (2-3 pages) Write down exactly what you managed to get done by the time of the demo. Did you achieve all the goals you set out to do? Did you do something that you didn't expect to be doing when you started?

Before we looked into the API, we spent sometime understanding the whole system. The gateway meeting with Professor Keshav was very helpful. We then looked into API documentation and some available sample codes provided on the course homepage before the hardware was available. Since the dialogic card was not available then, it was difficult to completely understand the API until we can see some demos with the hardware and wrote some testing code. During this time, we also looked at the Dialogic homepage for sample code before we could find the link available on the CS519 homepage.

We spent a lot of time going through all the documentation before the hardware has arrived, and we had some problems trying to nail down procedure calls that are necessary and relevant to our gateway module. By the end of October, we collected all dx* procedure calls and sr* procedure calls relevant to our module. After the dialogic card has been installed on Vada, on the next day we spent a few hours on the machine, running all the demonstration programs and trying to understand how the software interfaces with the hardware to perform different kinds of operations. We found that the help files and the sample codes that came along with the hardware available on Vada to be very useful. We have also gone through some sample codes, and also a few help documents from the sample programs.

We have discussed with the signaling team. Before we started writing our interface, signaling team and we have decided that we will provide the gateway main module and the gateway class module in C++ controlling the gateway. Our first goal for the main program was to achieve an end-to-end communication between a telephone and a host machine. Since signaling team is the only team that will use our interface, providing them a main program means that we do not need to provide an interface to any other teams. This gives us a little more flexibility in designing our gateway module. On the other hand, gateway module needs to perform certain handshaking protocol with the signaling controller on the signaling plane (such as call setup, call teardown, etc.), we have decided to establish a TCP live-permanent connection between our gateway and signaling controller, and the port numbers the gateway and the signaling controller communicates are port 5000 and 6000 respectively. We are responsible to initiate the connection.

On the other hand, we have also discussed with the data team. To carry out data transfer on the data plane from the telephone to the Internet, they suggested having 4 TCP live-permanent sockets connecting to our gateway module to their data server, each mapping a device channel to the telephone side. For an established connection, there are associated outgoing and incoming circular queues for data scheduling and buffering from the telephone side via the chosen device channel to the Internet side via the mapped data socket, and vice versa. We are responsible to initiate 4 TCP connections with the data server. The 4 port numbers used for data transfer are from 9000 to 9003 between our gateway and the data server.

We also made a decision about the voice data format with the data team. Since we do not want the delay of the voice sample to be too large, we decided to use 256 bytes as the packet size for the voice sample. We are using 8KHz sampling rate (8000 samples per second), and Pulse Code Modulation encoding algorithm (8 bits per sample) for the data format. From this format, we calculated the sampling delay is (256 byte)/(8000sample/sec * 1 byte/sample) = 0.032 seconds, or 32 milliseconds. In fact, we have collected timing statistics on the rate at which the read UIO function is called after initiating dx_play to send out 256-byte voice sample. The range is between 30 to 33.75 milliseconds.

After we are clear on interfaces between other teams and our module, we started out in two stages in design and implementation. The first stage is functional unit design and testing. By having a testing program to implement and experiment each particular function block, we divided a large complex problem into sub problems, and in this way we get a better scope of each of their individual operations and behavior. The second stage is functional unit integration and testing, in which after each function has been designed, implemented, and tested to achieve the expected result, we integrate each function into our gateway module and perform integration testing within our gateway module. Also, we realized we need to interface with the signaling controller and the data server, we decided to write a dummy signaling controller program and a data server program to simulate the environment, so that we can fully test our module before we later do system integration.

The followings are different handshaking operations performed on the signaling plane between our gateway module and the signaling controller module for point-to-point connection:

Handshaking packet size: 9 bytes

To setup point-to-point call initiated from the telephone side:

1. Send [data socket port] (4 bytes) + [user ID] (5 digits) to the signaling controller.
2. Waiting for ACK to indication success (connection established) or failure. For success, the handshaking packet format is: [data socket port] + "SSSSS". For failure, the handshaking packet format is: [data socket port] + "FFFFF".

To setup point-to-point call initiated from the host side:

1. Receive "0000" + [phone number] (5 digits) from the signaling controller.
2. Send ACK to indication success (connection established) or failure. For success, the handshaking packet format is: [data socket port] + "SSSSS". For failure, the handshaking packet format is: [data socket port] + "FFFFF".

When disconnected from the telephone side:

1. Send [data socket port] + "DDDDD" to the signaling controller.

When disconnected from the host:

1. Receive [data socket port] + "DDDDD" from the signaling controller.

The gateway main module captures the following events invoked from the Dialogic board:

1. ringing (on and off) event
2. hang up and pick up event
3. digit press event (also to support voice/email gateway)
4. silence on and off event

Originally, we planned to support full-duplex mode, but we found out in November that the Dialogic card does not support full duplex unless using two channels for 1 phone connection. Since the group agreed (especially the data and signaling teams) that there can be a maximum of 4 connections at a time, we chose to support half-duplex. In half duplex mode, we designed a flow control scheduling decision between data transfer from both sides: The user on the telephone side has a higher priority than the user on a host machine. When the user on the phone starts speaking, data from the host machine is cut off, and the user cannot listen to the voice from the host machine until s/he stops speaking. When the user on the phone stops speaking, data from the host machine is resumed, and the user on the phone can listen to the voice from the host machine until s/he starts speaking.

For audio conferencing, there is nothing extra that we need to do. During a meeting in November, the gateway team, signaling, management, directory service, and conferencing team had a group meeting. We have decided that to have a conference server to manage multicast group on the Internet side and perform multicast to the conference group on the Internet side. The only thing we need to do is to provide functionality to setup, join,, and leave conference group, and to transfer voice samples to and from the gateway and the data server, which also send and receive IP packets from the conference server.

The followings are different handshaking operations performed on the signaling plane between our gateway module and the signaling controller module for multi-point connection (similar to point-to-point connection):

Handshaking packet size: 9 bytes

To setup conference (multicast) group from the telephone side:

1. Send [data socket port] (4 bytes) + "0#" + [new group ID] (3 digits) to the signaling controller.
2. Waiting for ACK to indication success (connection established) or failure. For success, the handshaking packet format is: [data socket port] + "SSSSS". For failure, the handshaking packet format is: [data socket port] + "FFFFF".

To join a current conference group from the telephone side:

1. Send [data socket port] (4 bytes) + "1#" + [new group ID] (3 digits) to the signaling controller.
2. Waiting for ACK to indication success (connection established) or failure. For success, the handshaking packet format is: [data socket port] + "SSSSS". For failure, the handshaking packet format is: [data socket port] + "FFFFF".

When leave the current conference group from the telephone side:

1. Send [data socket port] + "DDDDD" to the signaling controller.

The big picture of the system is shown in figure 1.

Figure 1, The big picture showing the gateway module interacting with other teams' modules.

For our system integration, we put top priority on doing system integration with data, signal, directory service and us. We ran into a number of problems which are expected. For example, data format was used inconsistently between the data team and us. Strange hardware malfunctions sometimes make our system integration time consuming. But finally, at the time of our group demo, Data, signaling. directory service, and we integrated successfully.

There were a lot of problems that we ran into. First of all is communication problem. We realized that we don’t have enough meetings as a big group. With conflicting schedules, communication with other teams was sometimes difficult. This results in less chance to understand other groups' needs. The only way to work this out is to actively look for teams that we need to work with and schedule meetings through exchanging emails. Although we did have good communication with data team, signaling team, and the management team, we do run into problems with other teams. One of the bigger problems was with team 10—fax team. We did not know at the beginning that we had to support fax. We had a couple of discussion with the fax team who asked for the gateway to support fax, we started looking into sample fax programs and API for faxing. Since the sample programs available on Vada did not work, we decided to consult Donna Bergmark, and we realized that the dialogic card on Vada does not have the daughter board that supports fax. So we did extra work without any results.

At the beginning, we set out to write the interface for multi-user audio conferencing. During a meeting with signaling, management, directory, and conferencing team, we have concluded to have a separate conferencing server to handle audio conferencing such as tracking multicast group and doing data multicast, so that data transfer from the gateway is no different than in the context of point-to-point connection. And since we are also responsible for writing the gateway main module for the signaling team, we only provide an interface to support setting up conference group, joining the conference group, and leaving the conference group.

We ran into minor Windows socket programming at the beginning. After running into all the errors related to windows socket, we realized that we need to call WSAStartup() to initialize winsock and to call WSACleanup() to free process resources. After that, we also encountered minor problem setting the sockets to non-blocking since select() was not encouraged to be used from looking at the reference help. After trying a few other options, we decided to stick with select() call, and it did not seem to have created any problem onwards.

We have encountered a problem with sending smooth voice data from one end of the phone to another end. Since the length of a phone conversation is not limited, we cannot use the same technique that was provided in the given sample code—save the whole message in an array of buffers. The method that we used to provide smooth voice sample is as follow: We have constructed two data voice queues, one is an outgoing circular queue (source is from the telephone end to data server and final destination is host) and the other is an incoming circular queue (source is from the data server and destination to the telephone end). A small, fixed-sized voice sample is defined for each UIO transfer to be 256 bytes. For example, when a voice sample is being recorded, it is copied into the buffer to be waiting in the outgoing queue for sending to the data server. When playing voice sample to the telephone, we received chunks of voice samples from the data server, and we buffered received voice samples into the incoming queue waiting to be playing over to the telephone. The tricky thing is the make sure both queues have voice sample available to be played out, so as to give a smooth, non-chunky voice output. When we tested our code with signaling team and data team, we realized that the queue could be empty once in a while due to network traffic. In order to solve this, we introduced a delay so that there are always 4KB of voice data ready in the incoming queue; this corresponds to approximately a delay of 0.5 second long (4KB / (8000samples/second * 8bits/sample)).

Sometime in late November, we realized that in order to support full-duplex mode, we need to combine two channels for each telephone line. That means instead of having at most 4 phone lines supported at any time, only at most 2 will be available. Since we had reached group agreement, especially with data and signaling teams, that there will be 4 channels available, we could only support half-duplex. This introduces a problem because contention arises when users from both the telephone and the host machine are talking at the same time. This implies scheduling decision needs to be made between scheduling data transfer between two end users. We realized that there is a function that can detect silence on/off on the Dialogic card, so we decided to give the user on the telephone a higher priority, as described in part 2.

We also experienced a lot of hardware failure. The only options that we have are to restart the machine, check the telephone jacks’ connection to Vada, run sample program to test if all channels function properly, and consult Donna Bergmark when necessary.

• We gain practical experience of how the telephone and Internet network function, and how to make them communicate with each other through programming Dialogic card and socket programming. This is a valuable experience, in particularly gaining hands-on experience in addition to learning through theory. Moreover, based on the size and resource needed for this project under the tight schedule and competition from other groups, we felt as if we were working on a product competing with other competitors.
• We learned how to schedule and manage our time regularly for doing the project. Since there is only one Dialogic card available in the system, and we have a tight schedule doing this project, it is very important to allocate our time on a consistent basis. At the first beginning, we were not been able to commit well into our project because we were trying to define the functionality of gateway module and interfaces between the gateway module and other related team's module. But once the dialogic card arrived, and after we tried out a few experimental prototypes using provided samples and on-line help, we got a better and more concrete idea of how gateway should be function. Afterwards, we were able to allocate our time weekly on a regularly basis, with more time allocated towards the end of the semester to do our comprehensive testing and integration our code with data and signaling teams.
• We learned how to communicate and coordinate with other teammates to do such a fairly big project. During the first two months of the course, since we have not felt any pressure given by this project, we were not as eager in communicating with other groups as it should be. There were only a few meetings in which problems and solutions were being discussed. Not until November, when we realized that the deadline is approaching, we started to seek other teams actively and discuss problems and find solutions to them. Even though a lot of the problems were solved, the quality of the work is definitely not as good as giving us enough time to work on the project.
• We learned how to apply our lecture materials into the project. For example, we need to make scheduling design between the telephone end and the host end on data transfer. We also learnt from lecture which things/events should happen on the signaling plane and on the data plane. We also made flow control decision on determining the source rate and the service rate on the gateway from the telephone to the host and vice versa.

The first thing that we think we should do differently next time is to start early. Since gateway is the part of the core of the whole system, other group members’ code depends greatly on our code. If we cannot provide our code to other team members early enough, they will have less time for testing. Starting early and finishing early can ensure the rest of the group will have enough time to work on their code and integrate smoothly.

Another thing that we will do differently next time is to understand early the capability of the card. We have faced two different problems because we did not have a clear understanding of the dialogic card. First, we did not know that the card does not support fax. Second, we did not know early that the card is half-duplex by channel. To support full duplex, two channels are needed for one telephone line. With a better understanding of the hardware, we can minimize problems for ourselves and for discussing with other group members depending on us.

We should also have weekly meetings with all other group members. This is necessary because we can then know about each team's progress, their concerns, issues, etc. We can also learn more about the work that the other teams do. A weekly group meeting can also give group members a chance to talk to other group members about their problems and needs, and to resolve solutions to the problems based on consensus.

We also realize that we need to test our code with other teams earlier (in our case, the signaling team and the data team). In order for us to do some early testing, we should work together to plan out our integration and testing schedule for the later half of the semester. For example, with the data team, we should settle down at the beginning which port numbers we should use for a TCP connection and what format and packet size we should use for voice samples. While we worked on capturing voice samples, data team can work on the similar part of their code so that we can test out both of our code at an early stage.

Moreover, we should have asked the staff to make sure if our architectural design coincide with the project requirement set forth in the project page. Since data team suggested to provide us a data server connecting with our gateway through TCP live-permanent sockets to send and receive voice samples, and the data server assembles voice samples into IP packets and vice versa. We all thought this is doable, but didn't realize from the requirement that gateway should handle converting voice samples to IP packets and vice versa.

We do not need to provide any interface to other teams since we are responsible for the gateway class module and the gateway main module.

In the gateway main module, there are basically two main functions to handle events processing:

void process_sock_event (fd_set *readfds);

void process_dev_event(unsigned long ehandle);

Whenever there are events coming from the telephone side or the internet side, the corresponding process event function will be invoked. Process_sock_event will handles signals and data coming from the data server and the signaling server. Process_dev_event will handles events and data coming from the dialogic card.

Below shows our gateway class module definition:

class CGateway {

public:

// Constructor

CGateway();

// Destructor

~CGateway();

// Setup point-to-point connection from a given channel device and data socket pair

int SetupConnection(CH_INFO *chdevInfo);

// Tear down a point-to-point connection from a given channel device and data socket pair

int TearDownConnection(CH_INFO *chdevInfo);

// Setup multi-point connection

int SetupMultipointConnection(CH_INFO *chdevInfo);

// Join multi-point connection

int JoinMultipointConnection(CH_INFO *chdevInfo);

// Leave multi-point connection

int LeaveMultipointConnection(CH_INFO *chdevInfo);

// Send data via a given signal socket

void SendToPort(SOCKET sockfd, int dataPortNum, char *pstrVal, int

nLength=LEN_SENDTOSIGNAL);

// Send data via a given data socket

void SendDataToPort(SOCKET sockfd, char *pVoiceData, int

nLength=TRANSFER_BLOCK_SIZE);

// Get error

static void GetError(int sockfd);

// Reset I/O queue structure for the channel device

void ResetIOQueue(CH_INFO *chdevInfo);

void ResetOutgoingQueue(CH_INFO *chdevInfo);

void ResetIncomingQueue(CH_INFO *chdevInfo);

// sockfd_signal data member access

socketTCP& GetSignalChannel();

// Get the type of connection from digits received from user input

connectionType GetConnectionType(char *digits);

// Get multi-point service type from digits received from user input

Multi_PT_ServiceType GetMultiPTServiceType(char *digits);

// arr_chinfo data member access

CH_INFO *GetCHINFObyIndex(int index);

CH_INFO *GetCHINFObyDevNum(int devnum);

CH_INFO *GetCHINFObyPortNum(int portnum);

CH_INFO *GetCHINFObyFHandle(int fhandle);

private:

// Array of 4 DX_INFOs, mapping 4 channels

CH_INFO arr_chinfo[MAXCHANS];

// signal TCP channel assoicated with the gateway to the signalling server

socketTCP signalChannel;

};

We would also like to have more accurate information for our hardware. Originally, we were told that there will be 8 channels available, but it has always been 4. Some other teams within our group have asked us about this question, but we were not sure whether there would be another card installed in the future. It turns out that four channels are only available.

We have experienced a lot of hardware failure at the beginning of the semester. When the Dialogic card has failed to function properly, or when other groups are using the card, other teams cannot work on the gateway. It would be very useful if more than 1 Dialogic card can be provided. This will be easier for us to find an available time slot, and also there is another card to use if one card has failed.

More hardware support is also necessary. Donna Bergmark has been a great help to us, but it would be better if she also holds office hours also.

We would also prefer to have another meeting with Professor Keshav a month later after the first meeting. The second meeting should be a question/answer session, so that we can see what problems we might be running into. This would definitely help us in better understanding our part of the project.

APPENDIX A - Project Schedule