The code is large, among the largest of all the components within VOCAL. It is approximately 10 times larger than the MGCP translator, including the MGCP stack. A lot of the size has to do with having a large number of templates, each with its own debugging information. The translator starts as a 15MB process that grows as more calls are processed.
The translator is one of the more complicated components of VOCAL because there are two stacks, a large number of H.323 state machines, a translation state machine, an H.323 translator, and the SIP stack. We tried to write the translator and the gatekeeper so that it could be reused and understandable, and it appears that we were successful. The gatekeeper and router are modular and could be reused for other H.323 projects. The translator and proxy are specific implementations and cannot be reused.
As we started planning our project, it occurred to us that the translator could be divided into several subprojects.
We decided to use a certain type of transport, asynchronous I/O, with the potential to poll a large number of sockets. That approach was completely different from any of the code that was in VOCAL’s base. We essentially had to write a different type of socket infrastructure.
This piece uses the VOCAL base proxy code.
This portion of the code does the registration translation.
The call-signaling framework includes all of the H.323 state machines, ...