Give me a Jingle (It's a Multi-Protocol World)

The great thing about standards is that there are so many to choose from. That old joke certainly rings true in the unified communications space.

Whether the system is VoIP, IM, presence, or collaboration features like wikis, screen sharing, and whiteboarding, the sheer pace of change often leads cutting-edge developers to build their own technologies rather than use existing standards or take the long road of working through standards development organizations. And the services those developers build often become de facto standards, leading to fragmentation rather than federation. Even open standards such as SIP, email, and calendaring can be interpreted or extended in different ways, making interoperability an ongoing challenge.

For voice and other media sessions over the Internet, H.323 still garners a large percentage of the traffic. At the same time, SIP-based technologies are steadily seeing greater deployment, many small-to-midsize organizations use the opensource Asterisk VoIP server, and Skype and other services continue to "roll their own." A relatively recent entrant into the same space is Jingle, a set of extensions to the Extensible Messaging and Presence Protocol (XMPP) for media session management. XMPP grew out of the open-source Jabber IM projects in 1999 and was formalized by the IETF in 2004. Because XMPP provides a firewallfriendly way to exchange any structured XML data over TCP, the Google Talk team and others saw the potential to use XMPP as a signaling channel for session negotiation, where typically the media itself would be transferred via RTP over UDP.

The Jingle model resembles SIP: signaling and media are separated (unlike in H.323 or Asterisk) and RTP media flows over UDP. The differences lie in the signaling channel: Jingle uses XML over TCP, whereas SIP devices send textual headers and Session Description Protocol (SDP) payloads over UDP. Thankfully, Jingle was carefully designed so that the relevant SIP headers and SDP data can be mapped one-to-one into XMPP elements and attributes, resulting in seamless gatewaying at the signaling layer and a smooth handoff to common media technologies at the data layer. Jingle also reuses existing NAT traversal techniques such as STUN, TURN, and ICE, so it has quite a bit in common with SIP technologies.

Given these commonalities and the fact that we already have SIP, why was Jingle developed? There are many reasons: a bit of "not invented here" within the Jabber developer community, the inherent difficulties of building a dual-stack SIP+XMPP client, the advantages of strong security identity, authentication, federation, and firewall traversal in XMPP, and a large deployed base of XMPP users who have been clamoring for basic voice and video support since 1999.

Until Jingle appeared, various XMPP client development teams and service providers had tried to meet that demand by designing their own private XMPP extensions for voice and video, but the resulting software could not interoperate. In the summer of 2005, a small team of XMPP developers went to work on defining a general solution; when the Google Talk team launched its XMPPbased IM and VoIP service in August 2005, these two groups pooled their efforts. The resulting protocol was published by the XMPP Standards Foundation and implemented in software and devices as diverse as Nokia Nseries smartphones, the One Laptop Per Child project, popular IM clients, and call managers such as FreeSWITCH and Yate. As with SIP and H.323, Jingle is also being extended to handle application types other than voice and video, including file transfer, whiteboarding, and screen sharing. However, to date Jingle has been deliberately limited to the most common use cases, such as one-to-one voice chat; although more advanced scenarios such as call forwarding could be defined through future extensions, the goal so far has been simplicity over completeness.

The intent behind Jingle is to connect the millions of XMPP users with the broader VoIP network emerging on the Internet, not to build yet another communications silo - we have enough of those already!

The emergence of Jingle highlights something we already know: it's a multiprotocol world. Sometimes that's a bad thing, as when protocols and technologies are defined in a competitive manner without sensitivity to the context of different developer communities and the need for interoperability. Sometimes that's a good thing, as when careful protocol design enables the reuse of existing building blocks (such as UDP, RTP, STUN, and ICE) and therefore broader adoption of interoperable technologies. In the case of SIP and Jingle, it really is great that there are so many standards to choose from, because connecting user communities is the purpose of communication technologies in the first place. And when you think about it, that's just another form of UC in action.

Peter Saint-Andre is Director of Standards at Jabber, Inc. (www.jabber. com) a company recently acquired by Cisco.