3. Problems
Technical problems
-
We initially wanted to use bind as our backend database, using the
protocol described in rfc2136 to manage changes. Due to its size and
complexity, however, we decided against it.
-
Since strtok() isn't threadsafe, interleaving calls of it produced
undesired results; had to switch to strtok_r().
-
strtok_r() isn't part of the g++ libc, so we had to switch to the Solaris compiler.
-
Minor memory leaks. We suspect that these were caused by bugs in the
way the class constructors allocate memory.
-
Invalid pointer dereferencing. Class constructors sometimes died on
unexpected nulls, ill-formed strings, etc. Assumed that strings would
be well-formed, but a malicious user could probably cause the server
to crash by sending it bogus data.
Coordination problems
-
Username poorly defined
-
We initially thought that the purpose of the directory service was to provide a level
of indirection, resolving user names (in the form of a SIP id / email address) to telephone
numbers and/or IP addresses. Based on this assumption, we chose to use a database that
only supports a single index.
Since the SIP style addresses are difficult to enter on a DTMF
keypad, however, it was decided that a numeric ID be assigned to each user. Furthermore,
since telephone numbers may resolve to IP addresses.
Our (hackish) solution is to have duplicate database entries for each of the
necessary keys.
-
Conference support
-
Had to modify the client API and database's record structure to allow for multiparty
conference support. Support was also implemented for allowing public conferences, open to all, and private conferences, which require a password. These
changes affected the client, server, and interface, and should have been brought to our attention earlier than it was.
Things that weren't fully implemented
-
Roaming addresses - expiration times are not generated dynamically (current
implementation assigns a static time in the future),
and expiration time is not verified on lookup()s.