Speaking of Standards

The big news out of Google this week was their support of XMPP-Jingle as the “primary signaling” protocol for Google Talk calls to and from Google, iGoogle and Orkut. From the announcement by Peter Thatcher (my emphasis added):

We are pleased to announce that we have launched support for Jingle XEP-166 and XEP-167 for Google Talk calls to and from Gmail, iGoogle, and Orkut. We have also added the same level of support to libjingle (http://code.google.com/p/libjingle), which is used by many native clients. From this point on, it will be our primary signalling protocol, and the old protocol will only remain for backwards compatibility.

and further down:

But the future is Jingle, and the old protocol will eventually go away.

This is obviously a huge endorsement for XMPP – and the XMPP Standards Foundation (XSF) naturally had a post up on the topic.

Now, this is not a “surprising” move because Google has been very involved in the development of Jingle and, as noted by the XSF, Google’s original Google Talk VoIP protocol was a precursor to Jingle. Still, it’s great for Jingle to have the formal endorsement – and perhaps more importantly, the deployment – of Google. The XSF note also points out how this usage by Google can lead to improved interop and more developers using Jingle.

Of course, the obviously question asked by some out there, including in the Hacker News discussion thread, was: why not use SIP?

The truth is that while SIP is an excellent protocol for so many use cases, there are some situations where it’s not the best… and where in this case XMPP-Jingle is a better choice.

We’ve seen that choice here within Voxeo. While we are a HUGE user of SIP – and have our giant SIP cloud sitting out there hosting applications – when we created our Phono SDK to let people easily build voice and IM clients directly in a web browser, we chose to use XMPP-Jingle for part of the path. You can see that in our Phono architecture post:

Why did we use XMPP? Low latency, firewall-friendly… and also with the necessary IM and presence support. It was a lot easier to implement that inside a browser versus a full-blown SIP stack.

It’s great to see Jingle getting this kind of support from Google … and we’re looking forward to seeing increased Jingle usage out there.

By the way, if you want to learn more about Jingle, check out XEP-0166 and XEP-0167.

Posts by others:

• XMPP Foundation: Google: “The Future is Jingle”
• Hacker News discussion thread on this topic
• Tom Keating: Google Talk Adopts Jingle As Default VoIP Protocol
• Digitizor: Jingle Becomes The Default Protocol For Google Talk’s VoIP

Interested in SIP softphones? XMPP chat servers? Building a multi-party group chat like Skype provides but based on open standards? If so, join the VoIP Users Conference crew TODAY, February 18, 2011, at 12 noonto learn about the Blink SIP client and the new SylkServer project. From the VUC notes:

Adrian Georgescu, AG Projects founder and CEO, calls Blink “the new kid on the block” among SIP clients. Launched just one year ago, it managed to become for many in a short period of time their favorite SIP client on the Mac and now effort is underway to provide the same cool experience on Windows and Linux. Blink differentiates itself from its competitors by a generous feature set: g722 wide-band Audio from day one, File Transfer, Instant Messaging and Desktop Sharing, all those cool things SIP was all about, yet everyone stopped at VoIP. The lack of dial-pad also stirred some waters, it was the first soft phone to say goodbye to the classic dial-pad, a telephony oriented interface and offer instead a productivity oriented contacts driven interface.

AG Projects has launched this month SylkServer, an open source product that complements all Blink features on the server side, and the two of them can provide now a Skype like multi-party conference experience by using pure SIP. With an impressive roadmap, proven capabilities and real customers behind, can AG Projects now make a difference in the crowded space of SIP and VoIP

More info about the call is at:

http://www.voipusersconference.org/2011/blink-sylkserver/

Info about how to join the conference call is available on the VUC site, but can be summarized as:

• SIP: sip:200901@login.zipdx.com
• Skype: vuc.me
• PSTN: +1 567 252 2286
• iNum: +883 5100 123 94882

There is also an active IRC backchannel during the call (#vuc on freenode).

Of course, logically, the best way to participate in today’s call would be to download Blink and join in via SIP!

We were pleased to see the venerable BBC covering the Extensible Messaging and Presence Protocol (XMPP) in an article:

How to make the web work in real-time

The well-done piece provides a nice overview of XMPP and its role in the evolving “real-time” web. Here’s the intro:

That ask-and-you-will-receive mechanism breaks down when too many people want data from a server at the same time. Everyone knows the frustration of websites that will not respond because they are overwhelmed.

A change is under way to help the web cope with this growth and help some parts of it cope better in a real-time age.

Despite the complicated name, XMPP does a very simple thing. Whereas the web, via HTTP, asks for information on behalf of an individual, XMPP makes sure everyone is told.

If HTTP is a performance for one, XMPP is a stadium gig.

The article goes on to talk about use cases, companies using XMPP, how XMPP impacts search and much more.

It’s great to see this coverage of XMPP by the BBC and the article is quite right. We are in a time of transition.

Since the early days of the web in the early 1990′s, the dominant communication model has been one of “polling”. You had to check a website to know if there was a change. You had to refresh/reload your browser. The emergence of RSS feeds certainly helped with this… now a RSS reader (or your web browser) could “subscribe” to a RSS feed … but still, your RSS reader had to check whether there were new items in a feed.

While this approach has worked, it doesn’t scale terribly well as anyone who has tried to visit a congested website can attest. We’re in the midst of a transition from the “polling” model to a “publish/subscribe” model. In the new model, content providers publish information and consumers subscribe to that information… but in an important change:

the consumers are notified when there is new content.

That is the critical difference.

The XMPP protocol plays an important role in this change, and understanding XMPP and how it works is critical for anyone looking to understand the technologies underlying the “real-time web”. Here at Voxeo, we’re big fans of XMPP and it is a major component of our IMified service as well as our ClackPoint and Tropo services. Great to see the coverage by the BBC and we look forward to seeing where XMPP and other realtime protocols will take us all in the time ahead…