The Java subject has been discussed before on this blog, so I’m not going to repeat why it’s not a good idea to use pure Java for building a VoIP application; let’s just say it’s going to be a challenge for those who try. But if someone has got a Java based architecture and wants to enable or improve VoIP, will they have to throw their existing code away? Of course not – Java can utilize native, capable C++ libraries through the Java Native Interface (JNI) as long as this is supported by the JVM in the target environment. I wanted to ballpark the effort this would require, so I started hacking with the goal to make a VoIP call using a Java application.

I started out by downloading and installing the latest Java SDK for Windows from Sun. I then used a C++ VoIP library that I happen to have access to and chose the API functions I thought I was going to need to reach my goal (information hiding comes as a bonus – you don’t bring stuff into your Java class until you need and fully understand it). After copy/pasting these API functions into a new Java class, making some small adjustments to parameter types and adding the “public native” keywords in front of function declarations, I could use the “javah” tool to generate a C++ header for the glue code.

Some design decisions needed to be made, for example deciding where object specific information should be stored – I for one wanted to keep the data stored in the C++ glue code to a minimum and chose to retrieve member variables from the Java object when needed (JNI provides special C++ functions to do this). Callbacks, i.e. letting the C++ library call into the Java object, also required some thought (I won’t go any deeper here, but I tried it and it worked great). Basically, when all functions in the header file had been implemented by just making the corresponding call into the C++ library we started out with, the C++ glue code could be compiled/linked into a dll and used from the Java class we just wrote through the System.loadLibrary() call. And we’re done!

To conclude, it was only a matter of hours after downloading the JDK before I had made a (very) basic Java based integration of a VoIP library. This is not rocket science and a successful result was expected, but I still got a kick out of being able to type

 
 java MyVoipApp 192.168.200.41

from a command line to get a high quality VoIP call going on the local network. And now that we are in a Java environment, adding a nice GUI should take like 5 minutes, right?

After watching the BCS Championship game I am in a good mood for a short post. On that topic I start with:

Congratulations Gators!             

Every time there is news about a new Java based VoIP client for mobile phones I get questions about what this really means. This happened again today after it was revealed in recent news that Skype are about to release Skype Lite for Android and other Java enabled phones.

If you read the information closely you will notice that Skype Lite actually doesn’t support VoIP calls at all. For calls even between Skype users it is using the regular cellular voice network. The same is true for other similar offerings by e.g. fring (minifring). This is because it is far from a trivial task to design a generic Java based VoIP client.

Before addressing this topic I will comment on what I wrote in a recent blog entry where I talked about how to create a download free VoIP solution:

“Building a solution that doesn’t require a download is actually practically impossible because of the limitations that a Java Script cannot access audio and video captured on the PC. I.e., only one way streaming is possible for a Java Script based solution. “

It is easy to confuse the Java Script based solution with a plain Java solution, which is what we are talking about here. A Java client can utilize the full Java stack that is supported on the device and hence is not limited to streaming applications only, as the Java Script based client would be.

In theory Java, using the Java Media Framework (JMF) can be used to write a VoIP application but codec support is very limited and significant latency issues do exist, even on powerful PC platforms. This is due to the inefficiency of the Java model (running a virtual machine) as well as the fact that JMF has been developed with focus on streaming applications.

So to answer the question why is it so hard to build a generic Java based client for VoIP several factors have to be mentioned.  Maybe the three most important ones are:

1.   A fully Java based solution will be too slow to run in real time or take up all available CPU on the mobile device. It is possible to circumvent this issue by using a native library in C or C++ but that requires a library for each platform.

2.   Different devices are so different that any attempt to make a generic solution will still need device specific optimization for optimal performance

3.   Lack of support in the Java stack for certain important voice related features or poor implementations of the same. These issues are typically related to the sound drivers and network socket drivers and will be device dependent