OpenZoep: An Open Source VoIP Engine
Pages: 1, 2, 3
Multiple PSTN Providers
OpenZoep believes that its technology can only proliferate when it is reliable, secure, and open for others to innovate. Part of this mission involves opening up OpenZoep for multiple service providers.
OpenZoep has outlined the following roadmap (still in flux!):
Provider independence: When an OpenZoep user wants to access premium services like making PSTN calls to a regular (mobile) phone, this obviously costs money. Providers of PSTN-in, out, voicemail, etc., can make their services available through OpenZoep.
Soon, OpenZoep will document how providers can integrate their services with OpenZoep. The documentation will outline the following details:
- OpenZoep has defined an API that providers should implement when providing premium services. In OpenZoep parlance this server is called the Account Management Server (AMS). Typically the AMS will handle (or delegate) the processing of user registrations, account debiting and crediting, and payments. The AMS should also manage the creation, updating, and deleting of OpenZoep accounts inside of the Jabber and SIP servers. This allows providers to exercise control over who is accessing their premium services.
- OpenZoep has defined a protocol for exchanging data between the SIP server and the AMS to authorize and capture transactions. Most open source and commercial SIP servers can be extended with this protocol in just a few programmer man hours.
Global phone book: OpenZoep will strive for a global, federated phone book that enables users to find other users who wish to be found. OpenZoep will pursue a cooperation with the IM Federation.
Codec independence: OpenZoep has a pluggable codec architecture. New and emerging codecs will be added as soon as they are available. Service providers are free to offer commercial codecs to their customers as long as they also provide the standard codecs included with OpenZoep. Calls should gracefully degrade to a codec available on both sides.
Secure calls: OpenZoep strives to be the most secure phone on the planet. A possible avenue would be to integrate PGP crypto into OpenZoep.
Device independence: the OpenZoep client engine should be available for a broad range of computers, PDAs, and mobile phones.
Use Cases
OpenZoep can be used for almost any type of application. Here are some ideas that are either in development by OpenZoep users or licensees or that might spark your imagination. (Note that we don't claim that all of these ideas are original; most, if not all, have been implemented before using different technologies):
The OpenZoep Firefox plugin
Web browser: On January 30, 2006, Voipster announced an OpenZoep-based phone and IM client for Firefox. See Zoep: Firefox Extension for details.
Productivity software: Office suites like OpenOffice can be outfitted with a call button. The same applies to email clients and CRM applications. (Call to action: OpenZoep will actively assist developers who wish to help make an OpenOffice plugin!)
Games: OpenZoep offers game developers the means to integrate VoIP into their games. OpenZoep is written in C++, so it can be ported to any imaginable runtime platform.
Google Libjingle
OK, we'll give a full disclosure here. OpenZoep does not use Google's Libjingle. The reason, quite simply, is that Libjingle was not available when OpenZoep was developed during the course of 2005.
This is not say OpenZoep won't consider implementing Libjingle--provided some issues are resolved with Libjingle. The biggest issue we currently see with Libjingle is the translation from the Jingle protocol to SIP. The Jabber mailing list contains a thread on this topic.
OpenZoep is in the process of writing a Jabber Enhancement Proposal (JEP) that addresses the issues we see with Libjingle. This JEP addresses the following topics:
- Enable an XMPP entity to negotiate an out-of-band multimedia session with another XMPP entity or with a non-XMPP entity through a gateway.
- Maximize interoperability with existing gateways and devices by using standard internet protocols.
- Maximize code reuse by wrapping SIP messages in an XMPP transport layer.
The JEP draft is available at www.openzoep.org/docs/jabber/jep-0xxx.html.
Resources
- OpenZoep Foundation website (documentation, code, downloads)
- OpenZoep forum
- OpenZoep wiki
- OpenZoep blog
- Firefox plugin
- Commercial OpenZoep implementation
- JEP-0167: Jingle Audio
- JEP-0166: Jingle Signalling
- The author wishes to thank to Dirk Griffioen and Indrek Juhani, both from Voipster, for their advice.
Erik van Eykelen is a senior technology advisor for Voipster BV, a VoIP technology and service provider based in Amsterdam, The Netherlands.
Return to O'Reilly Emerging Telephony
Showing messages 1 through 4 of 4.
-
Dependant on the protocol
2006-02-08 03:15:46 tanguy_k [View]
-
Dependant on the protocol
2006-02-08 07:03:26 mllarster [View]
Zoep uses a SIP protocol for voice signaling, and XMPP used only as a transport for signaling. So you can call it “SIP over XMPP”. For payload transmission RTP is used, in this sense Zoep API is equivalent to any other SIP based phone. From my point it is one of the advantages of the solution as it is uses all benefits of XMPP protocols while it is trivial to connect/integrate it with any existing SIP based system.
IAX protocol uses one channel for both signaling and payload and not very well fits existing conception by several reasons. So far I did not met any requirement or request on integrating AIX protocol. We can discus it when real necessity appears.
Good candidate for “other voip protocol” implementation is a Jingle. And it implementation I believe is just matter of a time.
Currently multiple protocols are not yet supported, but in future it can be done as following: protocol to be used for calling particular user will be selected base on party’s capabilities (using JEP-0030) and user preferences. For example “juliet@capulet.com” can be done using either “SIP over XMPP” or Jingle base on preferences and capabilities of the clients. If there is a wish to make a call using specific protocol then “sip:juliet@capulet.com” will force to use “SIP over XMPP” and “jingle:juliet@capulet.com” will force to use jingle protocol for signaling.
But there is a problem:
how can you be compatible with SIP, IAX and other voip protocols? there is no abstraction layer like
int makeCall(string phoneNumber)
rejectCall(int callId)
that will be implemented using whatever voip protocol you like.
For the moment nobody knows if XMPP will be the voip protocol that everybody will use and for now I prefer to bet on SIP.