jVoiceBridge is a Java-based software conference bridge. It uses the SIP and RTP protocols to send signaling and audio data, respectively. It is designed to be highly reliable and scalable, while still providing advanced features such as high-fidelity, stereo audio and individual mixes. jVoiceBridge is currently used in a variety of applications, including conference calling and 3D virtual worlds. Since the voice bridge is based on the SIP standard, it interoperates with existing SIP components such as software phones, and VoIP to PSTN gateways. The jVoiceBridge package also includes a Java-based software phone which is optimized to work with the bridge. Our school is using Open Wonderland. The problem is, that the audio communication does not work well. The target is, to make the 3 scenarios work, which are currently not working. The problems are, that in some environment, the audio communication does not work. The establishment of the communication over SIP was in the tests never a problem. Only that the RTP packets can not be received on the client side. Scenario 1 problem: The RTP communication does not work from home to the OpenWonderland-Server in our School. The server is on virtual.enterpriselab.ch or 188.8.131.52 Scenario 2 problem: The RTP communication does not work in a test environment in which the client is behind a NAT and the Server has a public IP. Scenario 3 problem: The RTP communication does not work in the school network because the the network communication is a little bit complicated, but i do not have the rights to explain the school architecture here. These 3 Scenarios are given at this moment and i will try to solve this. 🙂
This Bachelor thesis in its present form is the result of the analysed and reverse engineered audio communication of the jVoiceBridge, which is used in the Open Wonderland framework. The initial idea was to determine where the problem in the audio communication is, how the problem can be solved and to implement the solution in an FCS (First Customer Shipment). The main analysis, including the reverse engineering of the jVoiceBridge was created in a self-installed test environment. The test environment was installed in a VM. It consisted of an Ubuntu OS for the Wonderland Server, a simulated Internet and a NAT-Router on the client side of the network. First, every package of the jVoiceBridge was moved to a new, inde- pendent project for comprehensible analysis with the help of the debugger and Wireshark. After the first few iterations, the complete jVoiceBridge was used again for further and wider tests in different environments. Some major and minor changes were made in the code to see if the behaviour changed likewise and if the problem could be solved this way. Unfortunately, these changes did not bring about the desired improvements. The different environments make simple changes impossible. These require a larger and more complex implementation. The best scenario would be if a new one were to replace the current STUN implementation. Additionally, the ICE protocol and TURN protocol must be integrated. An alternative would also be to change the jVoiceBridge communication to the IAX protocol. This would, however, need a complete re-implementation of the audio communication. Finally, only small, temporary changes were left in the code. These make it possible to find the public IP address in an alternate way and increase the chances for working audio com- munication. The need for this function can be activated manually.
Download my Bachelor work.