Author: Nathan Willis
Jingle Signaling is Jabber Extension Proposal 0166, and makes it possible to initiate and manage peer-to-peer sessions from within an XMPP client, and to interface with SIP and H.323 services. Jingle replaces the session management functions of the older Transport for Initiating and Negotiating Sessions (TINS) protocol (JEP-0111), and implements Network Address Translation (NAT) traversal.
Jingle’s NAT traversal mode closely follows the behavior of the Interactive Connectivity Establishment (ICE) protocol, an in-progress IETF draft. ICE attempts to negotiate the best possible connection between peers by trying all of the available permutations and gauging which one results in the best performance. This approach is highly successful, despite how trial-and-error it may sound. Jingle can also attempt to negotiate a connection with the older Simple Traversal of User Datagram Protocol (UDP) Through NAT (STUN) protocol, RFC 3489.
The Jingle Signaling protocol can negotiate any type of session, and its release was accompanied by Jingle Audio (JEP 0167), an audio chat session format. Jingle Audio sessions can specify any type of audio encoding stream, though it is designed with RTP transport in mind, since that is the most common.
In fact, both Jingle Signaling and Jingle Audio grew out of Google’s in-house protocol designs for their free Google Talk chat service. The JSF was in the initial stages of designing a replacement for TINS when they discovered that Google Talk was doing similar work. Jingle is the result of their cooperation.
Googling
When the JSF published its Jingle specifications, Google simultaneously released the Google Talk API based on those specifications. In addition, though other proprietary products (including some owned by Google itself) stop at publishing their APIs, Google released a library implementation of Google Talk’s underlying API under an open source license. The Libjingle package contains libjingle — which implements Jingle Signaling and Jingle Audio — and several other low-level components implementing perr-to-peer connections, socket and thread creation, XMPP, and streaming media.
Since Jingle is built upon XMPP, support may find its way into other XMPP-capable applications as well. Psi quickly announced its intention to add Jingle support to its client, and Gaim developer Sean Egan is himself a Google employee. Without mentioning libjingle by name, Egan posted a message on the Gaim news page indicating that its next revision will support Google Talk features — including voice chat. We have seen no official announcements from other IM projects, though speculation is rampant — particularly about those apps that already support XMPP.
Competing
Proprietary IM clients can make use of libjingle as well, since it was released under a Berkeley-style license. Of course, as with XMPP and other standards, the odds are small that large-network players like AOL or Skype will adopt the new protocol. But Google’s release of the code certainly puts greater pressure on them.
Contrast Google’s move with Skype’s API program. Developers can use the Skype API only to extend the Skype app’s functionality, while the libjingle release allows developers to create independent, interoperable software that works well with Google Talk. Google already permits other XMPP clients to connect to the Google Talk network for traditional XMPP messaging; those clients can now do so with voice chat as well.
Since the infrastructure for setting up, negotiating, and managing multimedia and text-only chats are so similar, applications that can do one but not the other are rapidly becoming a thing of the past.
Already we have seen Google Talk open up one proprietary IM client to XMPP (Apple’s iChat); Jingle could have the same effect for voice chat.
