What Libjingle means for Google Talk

Colleague Richard MacManus blogs TechCrunch reports that Google has released a set of components called Libjingle, which will allow third party applications to interoperate with Google Talk's peer-to-peer and voice calling capabilities.

He wonders how this will square away with Skype's own third-party developer community. I'm interested in this too, but I thought of digging in a bit and finding out about this thing called Libjingle.

I went to the Google Talk LibJingle Code and API Page where I read the following:

Libjingle is a set of components provided by Google to interoperate with Google Talk's peer-to-peer and voice calling capabilities. The package includes source code for Google's implementation of Jingle and Jingle-Audio, two proposed extensions to the XMPP standard that are currently available in experimental draft form. 

First, XMPP stands for Extensible Messaging and Presence Protocol, an open, XML-based protocol for near-real-time, extensible instant messaging and presence information. It is the core protocol of Jabber Instant Messaging and Presence, which is a common technology that makes IM run.

My interest was in Jingle Audio. Essentially, what is being talked about is Jingle Signalling, a signalling formula for managing IM-spawned voice conversations and conferencing not only over direct IM to IM connections, but IM to the public switched phone network.

The fact that Google is seeking to integrate third-party, Jingle builds into Google Talk is a monumentally obvious indicator of how they hope to use third-party applications to bulk up their existing Google Talk and make it PSTN compatible.

The key to understanding this claim is by a careful read of Jabber.org's Jingle Signalling Notes. The Notes begin with this defining overview/raison d'etre:

There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) multimedia interactions (such as voice and video exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or emerging SIP-based Internet voice networks. By contrast, the only existing open protocol has been A Transport for Initiating and Negotiating Sessions (TINS), which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients.
The result has been an unfortunate fragmentation within the XMPP community regarding signalling protocols. There are, essentially, two approaches to solving the problem:
Recommend that all client developers implement a dual-stack (XMPP + SIP) solution.

Define a full-featured protocol for XMPP signalling.

Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible.  Therefore, it seems reasonable to define an XMPP signalling protocol that can provide the necessary signalling semantics while also making it possible to interoperate with existing Internet standards.
As a result of feedback received on JEP-0111, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.

This is going to get real interesting. I shall report.