Problems

We have successfully overcome most of the problems that we faced in this project. And those we could not overcome, we worked around.

As we suspected, the hardest part of working on a large project is communicating. Not between phones and computers, but between different people.

• Within the group, there are many different working styles, from do-it-all-at-the-last-moment, to ok-fine-I'll-do-it-now-but-I-have-fifteen-other-projects-due-as-well. It took some effort and more importantly, time, to get reports, interfaces, and actual implementations from some of the teams.
• The various documentation writers did not do a very good job of imparting an understanding to us.

Between groups, sharing Vada had its frustrations. Although a single group could not reserve two consecutive slots, two groups could reserve the entire day between them. We had enough time, but sometimes we had to work at odd hours, when we would rather sleep.

Restrictions on the use of Vada actually caused us to spend a lot more time in the lab than we could actually use to test the system. But perhaps spending 2 hours staring at the code for every 2 hours of testing is a good idea. However, we'd like to note that it is somewhat strange to know that another group is napping on the couches in the lab, waiting for us to finish.

Once Vada was moved outside of the firewall, we lost access to most of the MSDN documentation, as it was all stored inside the firewall.

The D/41E hardware was not designed for this specific functionality, and the Dialogic SDK seems to be written and designed for answering machine style applications. The IPLink card runs the alpha version of the operating system, and, as we were told, does not work.

J/Direct seems really easy at first, but when we started doing callbacks, it turned out that it is really easy to get it wrong and virtually impossible to debug once you've got it wrong.

It turned out that when we generate DTMF on a Dialogic card, often an echo comes back and we detect false "incoming" DTMF. Our solution for this problem was to ignore DTMFs on a line during first second after DTMF was generated on that line.

In terms of integration, we encountered several days worth of problems. It turns out that Data Exchange expects a particular behavior from the applications, and that the gateway behaves quite differently from what they expected:

• The buffer size we need is unusually big for them.
• The connection is asymmetric, so the buffer size in one direction is twice as big as the buffer size in the other direction. The data exchange network latency calculations were based on the assumption that reads are evenly spaced in time. As a result, they were not giving the correct results on the gateway, where reads are done two at a time.
• If the data is not available, the usual application blocks on read until the data arrives. Dialogic does not tolerate blocking, so Data Exchange had to write a special version of the read function that does not block.

During the integration, we discovered that something was corrupting the data slightly. We spent a lot of time trying to determine whether the error was in Data Exchange or Gateway. Each team was pretty confident that they were not at fault. As it turned out, both teams were correct. Which brings us back to (the monstrously evil) J/Direct. Apparently, the J/Direct garbage collector was moving the arrays in Java. As a result, Java was putting the data in a different place from where the C code was looking for it. To make things more difficult, the garbage collector was only moving arrays slightly, so the C side was getting most of the data correctly. We were able to come up with some more or less reasonable solution, but finding this problems was a real challenge.