Group number and name: Group 2 - Phonedation

Team members: Min-Sik Jun (mj23) and Jangyoon Johnny Kim (jjk15)

Task number and name: Task 3 – Data Flow in Gateway

• Design a gateway to be used in the Internet Telephony Project with Dialogic D41/ESC Card. The gateway should work as a bridge that allows the applications developed by the rest of the group in the computers accessible to a customer from the phone side. Furthermore, the gateway would allow the computer to access the existing phone system.

• The gateway is connected to four telephone lines and an Ethernet. It is controlled from the computer (vada-x.cs.cornell.edu) that physically connects the phone lines and the ethernet line.
• The gateway has to operate in two planes, the data plane and the control plane. In the data plane, the gateway takes voice samples arriving from the telephone network using the Dialogic Card, and then converts them into IP packets by working with the
• DatExchange team, and send it over the ethernet. The vice versa should be supported as well.
• In the control plane, the gateway works with the signaling team to control the network transactions. The user uses touch tones from the phone side and the keyboards from the computer side.
• Transmission both of voice samples and of IP packets should be carefully scheduled to reduce the latency so that desire latency would under the threshold .
• The normal connections through the gateway are bi-directional connections with one phone line on one end and an IP address at the other. The connection should be full duplex – Telephones and Computers should be able to speak while they listen.
• Data flow for multi-point telephone calls also has to be implemented, with multi computers and/or multi telephones.
• If possible, use IPLink card to implement hardware packet transmission. (not required)

• We have implemented asynchronous handlers for all four channels.
• We have agreed, after extensive testing with Dialogic card, that the Phonedation network will support 11kHz, 8-bit mono-linear PCM format for voice samples.

• We have implemented full-duplex asynchronous handlers for all four channels in case of DTMF entry. We can detect up to 32 digits of entries. It is finished, tested, and functional. Component 1 has agreed to support a function that would send and receive the information entered by DTMF tone.
• We can detect the touch tone inputs from the phone side, and now can send them over to the applications as strings of ASCII characters rather than tones. This was essential for the groups such as stock and voice-mail because they wanted to implement voice menu during their application. We can also support the computer using sending ASCII characters so that they can produce touch tones to the phone side. This is what has been used to let the computer user to call out to a phone, which also has been implemented
• After finishing the above, we have starting implementing full duplex communication on one channel. Our first approach was to use asynchronous dx_play and dx_rec simultaneously since we thought asynchronous nature of the function should handle it. It did not work! Our second approach was to switch back and forth between dx_play and dx_rec so rapidly that the user would not realized the switching. We have tested numerous size of buffer (from 8 bits to 1024). This did not work either because of the tremendous hardware and software overhead that D41/ESC has when switching its state to another function.
• At this point we have called the help line of Dialogic Company and found out that it is not possible to do full duplex using one channel. We came to a conclusion that we need to have a phone to be connected to two channels for the communication to take place. Our alternate solution was to have the signaling connect the phone line on another channel to the connection already established, which would resemble three way conference call with only two users effectively using the connections. There were two reason that we thought this was not a good solution. First, it would put more burden on signaling team because of the problem that gateway has. Second it would be a horrible waste of resource, since we can consider phone numbers to be resources, as much as we consider IP addresses as resources.
• We have contacted course staff (Christian and Donna Bergmark) to let them know of this fact, and asked changes in connection between phone numbers and channels. We have obtained permission to support 2 incoming phone lines rather than 4 that was originally suggested in the "Big Picture Diagram"
• During this, we have finished implementing two versions of full duplex communication. One involves using small buffers and one involves files. We believe that if two channels were present in communication, the delay caused by using file would be minimal. We have finished writing both codes. Both are functional by themselves. However, the important aspect is how it works together with EstablishConnection() that component 1 has written. After extensive testing, we were in dilemma – we had to choose between short latency time and better sound quality. After consideration, we decided to go for the quality, meaning we would be using file for recording and large memory buffer for playing, instead of repeating small memory buffer. The explanation for this choice is provided in the section of what we have not accomplished.
• We have decided that all fax calls will be redirected to 45526, which is the fax/modem number of cs519pdt@csuglab.cornell.edu. The reason we have made this decision is that since vada-x.cs.cornell.edu does not have a fax modem, and we thought it would be pointless to have fax audio stream be digitized, transported in IP domain and reconstructed before being converted to fax format.
• After we implemented regular transmission, we tried to optimize our code. Until then, our implementation was to off-hook two channels on a phone call, and make them listen for digits coming in. Only then we could synchronize the timing of two channels, making them start playing and recording at the same time. However, this method had a big disadvantage. Because we are listening to a dialtone from two channels, we needed to put some gaps between pressing the buttons, or we may end up losing some information. Also, because the splitter mixes up sounds, echo was intolerable. What was being played went directly into what was being recorded.
• We then tried to use nr-scroute, a dialogic function that combines channels. The documentation of the function was very poor, and we ended up spending lots of time trying to get this function work. Whenever we failed, because this function changes SCBus settings, we had to restart the computer and pull out all the plugs. (We figured out ways to go around it later on.) We did get the function to work, and successfully combined two channels to make full-duplex connections. The magic was behind realizing that the SC_LSI and SC_VOX have the same device handlers that can only be differentiated by specifically name them the type.
• After implementing the nr-scroute version we tried to make multi-conferencing work with nr-scroute, only to find it impossible to do so. Dialogic Card did not let us connect two analog lines to listen to same channel.

• We did not have a proper management team for initial part of the project. This caused a lot of confusion for us, in terms of dividing the workload, and deciding on the system configuration. For example, we believed that we were responsible to packetizing the voice sample. We have spent significant amount time researching and implementing this aspect of the component (RTP, segmentation etc). Only after component 1 has started to formally take on the duties of management, did we realize that there were some inconsistencies between us and component 1 and 2.
• The Dialogic card went down very frequently. Sometimes, rebooting has made the card functional again, but a few times, assistance by Donna Bergmark was necessary. (Our sincere thanks to her, since she gave many assistance whenever we needed help.) This caused complete stoppage in testing in the busiest part of the schedule
• The Voice Programmer’s Guide that was available in .pdf format was specifically written for C. The sample program that we had was in C++. This caused a lot of debugging and grammar checks for our code.
• Vada-x.cs.cornell.edu does not have a fax modem on it. This caused us to treat fax in complete different way than we treat any of other application. If a fax modem was available in vada we probably would have streamlined the entire process including fax.
• Various limitations make the conference calls to be quite restricted. Firstly, multicast was not supported in the uglab, therefore, the conference call was to only involved on computer. Secondly, because the gateway was implementing full-duplex conversation, only 2 phones can join the conference calls. Thus the very definition of conference call meant 2 phones talking to a user in computer. This meant the gateway has to mix to two voice samples into one file so that team 1 can packetize this mixed samples and send it through the ethernet. From the computer side, team 1 would write the voice samples from the computer and place them in the memory. Our approach was to have this voice samples in the memory to be played in one of the SC_VOX channels and have two SC_LSI channels to listen to it. Near the very end of the project, we realized that neither was possible. Firstly, we could the mix the sound because, we have already used the combination of SC_VOX and SC_LSI that is needed to make conference calls when we have implemented full-duplex conversation. So our subsequent decision was to have the user from computer to be able to speak and the user from the phone to be able to listen. This we believed would still be of interest since, some form of lecture could take place using this system. However, finding out about limitation of SC_LSI allowed us to make the final decision. The decision was that conference call cannot be support by the dialogic hardware.
• We were not able to reduce the latency and delay to the level that we wanted. It involved the design that we have explained in the earlier section. We decided that since this is Internet Telephony Project, a reliable, clear communication over Internet would be the most ideal solution, even if some latency would be involved. If a person wants a conversation that is as real-time as a phone, a user (or a potential customer to our company Phonedation) would rather use a real phone. It is the other products and application that would be a strong point of the product that is produced by Phonedation. Applications such as Stock and Voice-Mail do not require the system to have comparable latency to the phone conversation.

• More than anything else, we learned how to program a card. It was a unique and fun experience to control hardware using regular C++ code. We got the first hand experience (or the frustration) of trying a use a hardware. We also realized that many times the manual provided by the manufacturer have bugs in them. We also learned that though not too knowledgeable, the tech support line of the manufacturer were occasionally helpful.
• We learned that communication with other group was the most important thing that has be agreed upon as soon as possible. For example we had difficulty deciding the method that we would use to communicate with the signaling team. At first we were going to learn in same machine(vada-x.cs.cornell.edu). We discussed the issue of exactly whose program would be the main function that would call the functions that will be provided by the other team. However, after further work on this issue, we have agreed after Thanksgiving that we were going to use socket to communicate. Had we agreed on this earlier, we would have cut down the amount of code that we had to change after agreeing on socket.
• We learned that sometimes, the interaction between people can cause problem not from the technical side from the personal side. We had members of other group shouting and being angry at us for not supplying the function when infact it was the limitation of the hardware that didn’t allow us to support. However, in the end, we managed to reach an agreement by numbers of discussions and explanations.

1. First of all, we would definitely have started earlier, had we known the amount of work needed to pull this off. After getting back the second report, we have practically lived in the Systems Lab(including our Thanksgiving Break) till the final demo, yet still there wee many parts of the project that we wished to improve upon.
2. Components 1,2 and 3 were the central part of the project. In other words, if our parts didn’t work, the entire system would not become a project that allows it to be marketable and operating. From the gateway, point of view, the boundary between gateway and the other two components because very unclear as time went on. There were a lot of overlap in the requirements for the three components. For example, simple detection of phone coming in was possible by both sides. The decision of who will do it made grave changes in our implementation of the project. If we had done the project again, we would worked more closely with the components 1 and 2, rather than just trying to integrate at the end.
3. We have assumed the integration of the components to be a very smooth ending to our semester long hard work. However, the reality was vastly different from our fantasy. It seems that to fully integrate all the application to a level that we want including all the error control and all the human interface, we would have to devote significant amount of time. Our team has concentrated on interface with the two components above(especially the team 1) to allow the basic functionality of making the voice sample to travel back and forth between phone and computer to work. We were able to accomplish this, but that left little or no time to integrate with the application teams.

Upon called on the phone numbers assigned to us, 4-5522 and 4-5523, we will play voice menu. The user will be guided through as he/she enter numbers in voice menus

VM1 Please enter user ID and password

VM2 choice of application

1. phone

2. join conference call

3. listen to e-mail

4. leave voice mail

5. leave personalized greetings

6. stock

7. fax

VM3 Please enter your destination ID

VM4 The conference call that you wish to join is private. Please enter the password.

VM5 Your phone connection will be terminated

VM6 Please call 254-5526 to send fax/Your call is being transferred to 254-5526 for fax

1. Gateway send USERID and Password and whether 5522/5523 to signaling

Message: N USERID Password 45522/45523

2. If password is correct, signaling will tell gateway to play VM2

Message: (VM2 45522/45523)

3. If password is incorrect signaling will tell gateway to play VM5 – Call terminated.

Message: (VM5 45522/45523)

4. Gateway receives user’s choice, ask for destination id if choice are Phone, conference or Fax and tells signaling which application the user has chosen

Choice of application 1,2,7 = D:

Choice of application 3,4,5,6 = C:

5. Signaling tells gateway to setup connection from 45522/45523 to (IP, port) for choices 1,3,4,5,6.

Message: (S IPnum portNum 45522/45523)

6. If conference call (2), Signaling tells Gateway if the destination ID for the conference already exist or not. If it does not exist, the user is starting a new conference.

New Conference = Q

Message: (Q IPnum portNum 45522/45523)

7. If it does exist, user is joining to the conference. Signaling detects if the conference is private or not. If private, Signaling tells Gateway to play VM4 and send password. If conference in public, Signaling tells Gateway to make calls join the conference.

Play VM4 (Password): VM4

Message: (VM4 45522/45523)

Joining Conference = M

Message: (M 45522/45523)

8. If VM4 was played, Gateway sends Password to Signaling. If Signaling verifies the password, M in step 7 will be sent. Else, VM5 of step 3 will be sent. (call termination)

Message: P passwd 45522/45523

9. If fax (7), after user enters destination ID, (after state 4) signaling would tell gateway to play VM6

Message: (VM6 45522/45523)

10. Gateway tells signaling that the connection has been made

connection = R if successful 1 or if not 0

Message: R 1/0 45522/45523

1. Signaling tells gateway to setup connection to a user in computer

Message: (O IPnum portNum phoneNum 45522/45523)

2. Gateway tells that connection has been made to signaling while no phone connection has been made yet

Message: F 1/0

Using the Key words and placement of parameters, we have used the code below to actually send and receive them.

Only teams we communicate with are Data exchange team and Signaling Team. We do not use interfaces of Signaling because all communication between Signaling and Gateway are done through sockets. We do use Data Exchange Team’s interface. Because Data Exchange Team Coded in C, (speed consideration) we included their code in our own program. By connecting to same machine and port, we are able to transfer data back and forth.

Team 1’s Functions

Following is the function prototype of the functions provided by team 1

Connection EstablishConnection(ConnectionParameters p, char **error);

int DestroyConnection(Connection c);

int ModifyConnection(Connection c, ConnectionParamenter p);

int UDP_SendMessage(Connection c, char *buf, int buf_size);

long UDP_RecvMessage(Connection c, char *buf, long buf_size, long msec, long *sender_ip_addr);

Here is how we have used them in our code.

• It would be really helpful if more than one Dialogic Card was available. With five teams, it was rather difficult to get enough time to finish up the project in time. We ended up pulling many all-nighters in the Systems Lab because it was the only time available.
• Since it is difficult to go back and forth between pdf manuals on computer and the Visual C++, it would be better to provide all gateway teams a printed copy of Programmer’s Guide. The manual is to long for us to print by ourselves.
• We definitely need sound card on vada-x.cs.cornell.edu when we were testing our program. Without the sound card, we were only able to test by reconfiguring the program.
• Description of what the sample programs do would help the gateway teams. For example were did not know that the program called Asynchronous Callback would allow us to examine with channels are functional. To our surprise this program also reconfigured all the SC buses.
• Though the first sample code provided to us was very helpful, we would have like more sample codes that are in a manageable list, not the one provided by dialogic. For example, pointers and sample code to nr-scroute would have been very helpful to us.

Meeting with Prof. Keshav on Sept. 25th, 1998

C. Wu and J. Irwin, "Emerging Multimedia Computer Communication"

H. Schulzrinne and J. Rosenberg, "Internet Telephony: Architecture and Protocols an IETF Perspective"

H. Schulzrinne and J. Rosenberg, "Internet Telephony Gateway Location," in Proceedings of the Conference on Computer

Communications (IEEE Infocom), (San Francisco, California) March/April 1998.

Sample C++ Code,

http://www.cs.cornell.edu/cs519/project/examples/gateway/dialog_example.cpp.txt

D/41ESC Manual, http://www.cs.cornell.edu/cs519/project/Doc/Dialogic/

D/41ESC description, http://www.dialogic.com/products/d_sheets/2550web.htm

D/41ESC description, (PDF) ftp://ftp.dialogic.com/www/pdf/2550fn05.pdf

D/41ESC documentation http://www.dialogic.com/products/d_sheets/2550web.htm