Last month, OnSIP employee Leo blogged about a webphone design in our Unified Communications app, My.OnSIP. We call it a "webphone" because it's literally a phone that OnSIP users can access in their browser— it runs as a Java applet. Well, just as we recently released the phone, Apple made a few changes in a Mac OS update that have put a thorn in our side. Here is the story of what happened and how Software Engineer Oren is handling it.
We currently support the webphone on Windows and Mac. A Windows user who attempts to use the webphone will be prompted to go to the Oracle website and download Java—Thanks to a JavaScript detection script, deployJava, provided by Oracle to detect the presence of a Java plugin. Over a year ago, in earlier versions of the Mac OS (10.5, and 10.6), Java came pre-installed with the plugin technology. That was the case when we were first looking into offering the webphone; so the end user experience was really nice on the Mac and a bit less obvious on Windows.
Then, things started going sour when Apple did 2 things:
Then things got worse on Mac.
In October, Apple deployed an update (Java for OS X 2012-006), where it effectively removed all plugin libraries, but it didn't actually remove the Java runtime environment if you installed it. This was confusing to people who thought they had Java, but they couldn't run the webphone because they didn't have the Java plugin. (You can check to see if you have the Java plugin at Java Tester Web Page.) The update that removes the plugin technology (Java for OS X 2012-006) went out to Lion and Mountain Lion users, but not to Snow Leopard users who still had the plugin technology and could run the webphone just fine if they had plugins enabled.
So, Apple is still supporting Java on Snow Leopard (10.6), but it randomly disables plugins when running a system update. And now Oracle has taken the reigns and is providing Java plugin support for Lion and Mountain Lion (10.7 and 10.8), but with a caveat. There is no support for the Chrome browser. Chrome is supported, however, on Snow Leopard .
So here's a recap on where we are: The Windows and Java relationship hasn't changed all that much. To get the latest Java plugin technology, you can go to Oracle. The java plugin works on most browsers on Windows.
On the Mac: If you have Snow Leopard, you need to make sure the plugin is enabled. Once you have the plugin enabled on Snow Leopard, the applet will run on all browsers including Chrome. On Lion and Mountain Lion, you can get the latest Java plugin technology through Oracle, but it will not run in Chrome.
So, let's now assume that you have the Java plugin installed correctly and you're ready to use the webphone.
Once Java starts and loads the applet, things tend to run pretty smoothly. On the initial load, Java feels like you've woken up a sleeping giant. Once running, the webphone will need to download its required libraries which will take a couple of minutes, but then the libs will be cached by Java, so subsequent reloads of the webphone will take only a few seconds and the experience will feel a lot snappier.
The webphone is really neat once it's running, it's a great user agent (phone) integrated in My.OnSIP and we have a JavaScript API called Osprey.js, which developers can use to build their own SIP-enabled webphone that supports transfers (blind and attended), mute, hold, volume control, multiple calls, and multiple user agent registrations. However, Oracle and Apple have done such a tremendous job bastardizing the Java install and management that if people run into one of the above described problems, they tend to just give up on the experience altogether.
In my humble opinion, the future of SIP enabled user agents will ultimately live in the browser with the standards that surround WebRTC. However, Java applets (and Flash, for that matter) provide a great way to fast track a proof of concept for what could ultimately be a web standard. As a matter of fact, the webphone (aka Jitsi) is built on those very same IETF standards that are used in WebRTC.