OpenZoep: An Open Source VoIP Engine
by Erik van Eykelen02/03/2006
Telephony, IM, and the OpenZoep Foundation
OpenZoep (pronounced "open soup") is a client-side telephony and instant messaging (IM) communications engine. It supports computer-to-computer (peer-to-peer) VoIP calls, instant messaging, and outbound PSTN and SIP calls to free and premium SIP providers. OpenZoep is available under the GPL license, as well as a commercial license for companies that do not wish to publish the source code of their commercial products based on OpenZoep.
OpenZoep was developed by Voipster, a technology and VoIP service provider based in Amsterdam. In late 2005, Voipster donated its client-side technology assets to the OpenZoep Foundation. A team of enthusiastic developers in Estonia and the Netherlands is continually adding new features. Like any new open source project, OpenZoep is actively seeking the support from software developers and people with writing and testing skills to improve OpenZoep.
OpenZoep is completely "open for business" to any service provider, and hopes to attract multiple providers of PSTN and voicemail services. Having multiple competing providers offers users a choice, and competition sparks innovation and quality improvements.
By using open VoIP technology, users can rest assured that they will be able to make VoIP calls to any other user. The services available may not be the same to all users (some users may purchase additional services like voicemail, SMS, or conferencing) but at least there are no artificial walls like the ones that plague interoperability in the instant messaging world. Unfortunately, the VoIP market knows walled gardens, too, but OpenZoep thinks it's not too late to turn the tide.
What Does It Do?
|
Related Reading 
VoIP Hacks |
What can you do with OpenZoep? Well, for one, it allows anyone to embed telephony functions into their desktop applications. The OpenZoep API makes it really easy to pick a sound-in device (microphone or handset) and a sound-out device (speaker or headset), dial a phone number or "dial by username" (more on this later), and presto, a phone call is made.
Another interesting feature is OpenZoep's instant messaging (IM, or chat) capability. OpenZoep uses Jabber to perform its IM tricks. Moreover, the XMPP protocol is used throughout OpenZoep, so when you've mastered XMPP to make a phone call, you'll also then know how to obtain the server-side phonebook, initiate a chat, or answer a call.
The OpenZoep Application Programming Interface
To quote Ben Stein, let's "jump into the middle, get your hands dirty, fall flat on your face, and then reach for the stars."
Because you have to speak XMPP to the OpenZoep API, the API itself is very simple. It has only four methods:
unsigned int api_register_account()void api_unregister_account( unsigned int session_id )void api_send_buf( unsigned int session_id, const char* buf, int buflen )int api_get_response( unsigned int session_id, char* buf, int buflen )
Note the C-language-style notation. This is not a coincidence; OpenZoep itself is entirely written in C++. The C/C++ API enables easy binding to other languages like Perl, Ruby, C#, or Visual Basic. As of January 2006, it is available for the Windows OS. Porting to OS X and Linux is underway, but OpenZoep can use your help here. There is also an XPCOM wrapper available that allows you to access the OpenZoep API from Mozilla applications such as Firefox and Thunderbird.
The api_register_account() method returns a session ID that must be passed to subsequent function calls. Once a session is opened, it must be closed using api_unregister_account() to free up system resources and internal data structures.
The api_send_buf() and api_get_response() methods work in an asynchronous request/response fashion, meaning you can fire multiple, different requests using api_send_buf() and you should be prepared to get back and process responses in random order.
The data you send to api_send_buf() and retrieve using api_get_response() must be valid XML and be UTF-8-encoded. In Jabber parlance, the XML stream consists entirely of "stanzas." Don't let this term fool you; a stanza is nothing more than a snippet of XML that is properly structured and encoded and ready to be injected into the Jabber stream, or (when it returns to you) be picked up from the stream, ready for parsing. As a rule of thumb, you should call api_get_response() every 1000 milliseconds. Every call can return zero, one, or more responses. Note that the api_get_response() function returns the number of bytes actually read, so if this number matches the size of your buffer, more data is waiting.
