Backstory ---

During mid-naughts, Jeff Pulver's rallying cry was "Be your own phone company". But most of the attendees and exhibitors at VON conferences were focused on centralized service providers. During Spring 2008 VON, we demonstrated an early version of this app that individuals can host so their friends and family can initiate communication sessions with them. Recent advances in technologies like Websocket and WebRTC as well as availability of inexpensive cloud instances have made it possible for this app to be widely adopted.

Early on we had to settle on certain architectural design issues. For example, the app has to handle "Day 1 issue": on the first day an owner deploys the app, it is very likely her friends and family may not already have deployed their own version of this app. So as a practical matter, friends and family must be able to access the app using a browser, instead of a native client running on their computing devices. We were adding features incrementally. Updating the native client and requiring early adopters to constantly update native client would not have been feasible. So we felt that even the owners must be able to access the app from their browsers, instead of a native client.

But browsers were designed to initiate a communication with a server. But this app requires the server be able to asynchronously notify the browser of incoming requests. At that time, widely used technique was long polling. But we felt that will either place a heavier load on the server or the notification will not be delivered in real-time. So we ended up developing something similar to Websocket that was developed subsequently. We used this proto-Websocket connection to carry call control messages as well as text chat messages. We packaged this proto-Websocket as a Java applet that was dynamically downloaded to the browser. For voice communication, we packaged Jspeex, a Java version of Speex codec and speech engine. No such video codec were available and so we did not include video chat capability in the 2008 version. That version even had a rudimentary ICE functionality, including a relay server. Our implemented version of ICE was limited in the sense, it did not handle the case of multiple network interfaces. The Java applet could be downloaded to any browsers on a regular computer but could not be run on mobile devices that became prominent subsequently.

Subsequently Websocket became widely available in many modern browsers and WebRTC is available in a few browsers with glaring omission of Internet Explorer and Safari (including iOS devices). WebRTC gave us video codec and a more complete implementation of ICE. Additionally WebRTC-enabled browsers are available for Android devices. But we lost these two major browsers and iOS devices. Since we feel this is a temporary situation, we moved away from Java applet construct and decided to use Websocket and WebRTC.

After the initial development of this app, we began our search for a platform to run this app. Our initial approach was to explore partnership opportunities with ISPs or WiFi vendors. Both of them have presence in consumer homes. The app has a small footprint that it can run on these devices. But we were not successful in elicit interest from both the groups. Fortunately, now many cloud providers make available a low-end instances very inexpensively. Our current plan is to approach the consumer market directly by offering this app in conjunction with such low-end cloud instances.

In parallel, we have developed features that will be useful for enterprises, both for their internal communication as well as interactions with their customers. The app is cloud-ready and scales nicely with additional cloud instances.

Terms & Conditions | Privacy Policy | Getting Started | User Manual | Blog | Forum