We set out to connect telephones to the Internet. A problem we initially had no idea how to implement. So we sat down with signaling and the data exchange group, and hashed out details. The data exchange part seemed simple – once we had the appropriately formatted data, we would put a little RTP header (of which we made use of the time stamp, a source identifier, and a sequence number). We would then send this packet out to the computer, using UDP transmission. The intricate part of designing was the signaling part. We needed to communicate with an entity that could then speak to the outside word – people such as directory services, and PC’s running applications. We wrote an interface with signaling that used socket communication. We would send packets of status transitions and requests to each other (even if the program with which we were communicating was on the same executing program). We did this to have a logical distinction between the signaling group’s code and ours. What would happen is that if they received a message from a PC application that wished to dial a number, they would send us a message saying, effectively, dial this number. We would, and would respond with a connection status. Similarly, if we got a message, we would pass the necessary information (user ID, password, extension the user wished to reach) to the signaling part of our program. Signaling would then do everything it needed to do to connect us, and then send us a message to start the data transfer, or give a busy signal. Also, they would be able to send us messages to add an address to the list of addresses to which we send data, so that we could then implement multicasting.

For phone call events, we decided to use event handlers. These would signal us as certain events occurred (end of a play/record, a phone ring, a phone becoming on or off hook, etc.), and each would have a handler, a small piece of code that would take the next appropriate action. For data transfer, we originally decided that we would record (or play) a certain segment of data, copy the data from or to a send/receive buffer, and do it over again. Figure 1. shows event handler operation.

We anticipated that each channel on the board would be able to handle one full-duplex conversation. A user would then dial into one number, and the PBX controller would route that person to an available line if there were one. We were planning on recording samples at 30ms clips, so that a queue of three packets would introduce less than 100ms of delay. We were planning on re-arranging these packets so that if they arrived in the wrong order, we would re-order them based on sequence number. We would also eventually set a queue length not based on number of packets, but on time in milliseconds, and we would determine how much we would need to buffer from the time-stamp on the RTP header.

We were also going to implement a system to update the management team about the status of each line as we learned new information. In other words, if we placed a call, or hung one up, we would notify management. We would not offer real time service, i.e., we would not periodically update the management team with the status of each line.  

We completed the simple data transfer part of our code. We were able to exchange packets with the data entities on other computers, and have a full-duplex conversation via the internet. We were only able to have two full-duplex conversations using the dialogic card, due to the fact each channel was duplex, yet single task. We did not however implement packet re-ordering, or time based queue length, for lack of time (again, more on this in the problems section). We tested this only between computers in the CSUG lab and the systems lab, which gave us great reliability of packet delivery and very little propagation delay, and under these ideal settings, our conversations had good sound quality. We were unable to get less than approximately 250 ms of latency between endpoints (not very acceptable, our coding generated almost all of this). This is in part due to our input queue length, which was four packets each of 1024 bytes (at 8kHz this equals 128 ms). We were forced to deal with such large queues as a result of the dialogic drivers (again, see the Problems section). We also had echo on the PC end. This, we believe, comes from the coupling of the speaker to the microphone of the telephone handset (so that one can hear oneself when speaking). We were able to multicast unintelligently, i.e., if we set up a list of addresses, we were able to send packets to all of them. This system was implemented because we could not get internet addresses from signaling. It was set up solely for testing purposes.

We were also able to play greeting messages to request appropriate information from a phone user. It would ask him for his user ID, password, and the extension he wished to contact. It could then detect the digits entered from a touch tone phone, and send the data to signaling. We were also able to detect digits if entered in the middle of the conversation, and send them on a socket to the signaling team to notify an application (say, voice e-mail). We could also dial a phone number if given one by signaling, and make a connection to that phone number, and start transferring data to and from it. We could also stop data transferring, and tear down phone connections (set the line on hook).

We completed our signaling design, save for multicasting. It was very different than initially planned however – instead of sharing code on the same computer, the signaling team code was moved to another. We communicated through a TCP connection to the signaling team for call setup. Communication was separated into signaling concerning a phone-to-internet call, and an internet-to-phone call. Each side of signaling was given a dedicated socket. Communication at a very high level then remained similar to what had been originally designed. We communicated user-entered (through the phone keypad) information, before set up and during the conversation. We also listened to requests from signaling to contact a phone number.

Our goals were close to being met. The signaling did most of everything we had hoped it would (save for multicasting), we believe – the last revision was never tested, because we never had a signaling entity to test it against. On the data plane, we got basic functionality down, and it sounded clear, even the echo.

One of the reasons we were not able to accomplish what we set out to do was that we made a change in design with the signaling group very late in the project (the night before). This required overhauling of both ours and signaling’s code, which never again really worked well. With the crunch of time against us, and with the late redesign, we also never implemented the sending of data to our management group, nor the packet re-ordering. Finally, for both the above listed reasons, we never completed the multicasting feature of our gateway controller.

A big problem we learned of more than halfway through the semester was that each channel on the dialogic card was single task. This meant that we could not play and record at the same time on a single channel. We would have to use two duplex channels per conversation. This squandered half of our resources, and made us rethink our design of the project. We ended up learning how to use the nr_scroute() function to accomplish this – we connected one dialogic channel, which we would then dedicate to recording, to the incoming analog data from another phone line. In this way, we were able to record and play using two different dialogic channels.

We wanted unnoticeable delay in latency between endpoints of our telephony system. This was unachievable with our original design, because switching to play and record handlers after every block of data was expensive time-wise. It turned out using this system that we could not do more than six or seven different records per second, and during the time it took the processor to switch contexts to handle the events, nothing was recording. We ended up changing this design to using UIO’s (user-defined input/outputs) for data transfer, which were quicker, and more seamless. In Figure 1, that representing the play/record event handler. If this event occurred it would signal the end of a conversation (we set the play/record lengths to –1, which meant until no data was remaining to play or record.). Because we used two dialogic channels per conversation, we would only set up a play handler to signal the end of a conversation, and then we would in this handler turn off the recording, and then set the lines on hook.

We also had considerable echo for the PC user of our system. We believe this is because of the coupling between the speaker and the receiver, as said before. We tried many different approaches to eliminate this. At first, we used a splitter to instead of re-routing to us two channels for each conversation. However, this just added full coupling of the two channels, and the echo made the conversation unbearable. This problem occupied a lot of our time, and we never ended up solving the problem (we suppose we could not, save for using different hardware). This time could have more valuably spend doing other tasks.

Our most annoying problems have been with the Dialgoic hardware. Often when we have arrived in the systems lab, the board is unusable. We then have to spend nearly an hour each day (which is half of our allotted time) reseating the CT bus, restarting the computer, tracking down gurus, etc. until it works.

At first, another major problem we had was a lack of communication between us and our signaling group. Once our interface was (more or less) ironed out, we were given an dummy API to play with, and progress sped up considerably. At first we were unsure about socket programming in windows (using winsock), which we use communicating both internally (to get messages to the gateway signaling entity) and for externally (to send and receive data). Another problem is that we share a common code base with the gateway signaling entity, so progress was incremental, based on what the other group had accomplished. Then we found out about the last minute redesign, which would have been fine, with our use of sockets for separation of tasks, but we had still been irrevocably married in global variables. So we had to rewrite a good part of our code.

Because we were initially more concerned with signaling problems, our data transfer progress has suffered. At first we had been formatting our data incorrectly (using the default 6ksamp/second, 4-bit/sample as opposed to 8ksamp/sec, 8-bit/sample), so when transmitted and listened to it, it sounded like static. That, once diagnosed, was easily fixed. The biggest problem we had with our data transfer plane was that we had no application to test it against. We were not given an application that could be a source for voice data until the day of the demo, and we were never given an application that could both record and play data using the internet.

 4. What did you learn by working on the project? Include details on technical things

We have learned that integration always seems easy, but it is a painstaking task to do it well. On the gateway, the code between signaling and us were bridged (for very core functionality) with the addition of a single line. Of course, this just lead to more and more lines which had to be added to take care of the details. As far as the data transfer is concerned, we have learned not to put off an issue – unforeseen technical constraints can lead to expensive redesign.

We also should not have agreed to reprogram a lot of our code the night before our project was due.

Next time, we would code to interface with other groups earlier. Only through their code have we been able to find many problems with our own.

We interface with signaling in a very simple manner. They will tell us a number to dial, with a source identifier corresponding to what the remote source will put in its RTP headers. The packet would be 2863:45544 if we were to dial 254-5544 (25 ignored because we are on campus), and signaling would choose 2863 so that both parties can agree on a source identifier beforehand. The source identifier is mostly important for our application – we receive packets from many conversations, most applications receive oly from one (us). If we wanted to contact a PC, we would send a message like the

following:

The 123 would be the user entered ID, the 456 his password, 789 the extension he’d wish to reach, and the 3245 would be the source identifier we expect to see in packets we receive. We transfer data to (and from) remote data entities using RTP/UDP/IP packets. The Data Transfer team provided the format of this header for us. Lastly, we provide statistics about the data flowing through the gateway to the management stub running on the gateway. All other groups use the gateway through their own signaling and data interfaces.

I do not think that anyone knew about the single task dialogic channel issue. Learning about the hardware when we didn’t really have a hold on it yet made it rough – we know our single channel, full duplex solution wasn’t working, but we thought we were implementing it incorrectly.

The most important reference we have come upon was for the Dialogic hardware problems, and it is Dan Spoonhower. He showed us how to reseat the CT bus, and sat with us for about an hour helping us getting the card up and running again. Also, he taught us enough so that we have been able to deal with each subsequent problem, with a little (or a lot of) patience. His example code was also led to the UIO breakthrough.

We also used a lot of Dialogic documents that we got from the web. Here are the URL’s:

http://www.cs.cornell.edu/cs519/srlapint.pdf

http://www.cs.cornell.edu/cs519/voxapint.pdf

http://www.cs.cornell.edu/cs519/voxftgnt.pdf

http://support.dialogic.com/applets/winnt/i_phone/iphone_c.htm