Miscellaneous

With support for audio and video calls, Jitsi has long had one of the richest Jingle implementations. Now the project has added even more on top of that: Multiparty Video Conferencing. One of the most prominent new features in the 2.0 release is Multiparty Video Conferencing. Such conferences can work in an ad-hoc mode where one of the clients relays video to everyone else, or in cases that require scalability, Jitsi can use the Jitsi Videobridge: an RTP relaying server controlled over XMPP. That control happens through COLIBRI, a new XMPP extension that the Jitsi community developed for the purpose and that we hope to see submitted as a XEP in the following weeks. [Read More]

Some implementations of the XMPP Server Dialback protocol have not been checking dialback responses to ensure that validated results are correlated with requests. Please see https://xmpp.org/resources/security-notices/server-dialback/ for detailed information about this important security notice.

Identity and Privacy are a growing concern on the Internet nowadays, and there have been different attempts to solve this. One of the most recent ones is BrowserID. The XSF believes however, that building upon the strengths of XMPP would be a great way forward for the BrowserID concept, due to its inherent federation, proven Internet-wide scalability, and decentralised architecture. This is why the XSF has decided to support projects that demonstrate the use of XMPP for BrowserID purposes. In order to do this, the first step is to get a Request for Proposals designed, so that the XSF can establish criteria to decide which projects to support financially. [Read More]

Microsoft has announced that it is adding support for XMPP to its Windows Live APIs, enabling any application or IM network to interoperate with Windows Live Messenger.

Details are available at liveside.net and dev.live.com.

Skype has added support for XMPP to its latest Windows beta, according to Phil Wolff of Skype Journal. Janko Roettgers provides further analysis at GigaOM.

This is yet another demonstration of the power of open standards.

Jingle (XEP-0166 and XEP-0167) is the voice and media signalling protocol developed by Google, Collabora, Yate, Tandberg and Jabber Inc (the latter two now part of Cisco), and standardized within the XSF. Seen by many as key for an open-standard consumer VOIP system to compete with Skype and others, the specifications moved from Experimental to Draft status two years ago, and have been implemented in a large number of clients, including desktop and mobile handset environments. [Read More]

The XSF has issued a Last Call on XEP-0262, which describes implementation considerations related to audio codecs for use in Jingle RTP sessions, and recommends PCMU and PCMA (G.711) as mandatory-to-implement technologies to provide a baseline for interoperability.

If you have feedback, please post to the jingle@xmpp.org or standards@xmpp.org discussion list before July 8, 2011.

Earlier today, the XSF advanced XEP-0262 from Experimental to Draft in our standards process. This specification defines how to use ZRTP with Jingle for end-to-end encryption of audio and video sessions, thus supplementing the existing SRTP method defined in XEP-0167.

Special thanks to the Jitsi team for providing implementation feedback.

FYI, if you’re a fan of Strophe.js and/or libstrophe then you need to make sure to update your bookmarks as the site has moved. You can now find all of the Strophe goodness at strophe.im.

UPDATE: The hsxmpp project has moved too, the new site is http://חנוך.se/hsxmpp/.

As you might recall from our Brussels trip report a few months ago, the XMPP community has a bit of work to do on internationalization. It’s not that XMPP messages or addresses can’t include non-ASCII characters, because we’ve had that capability since 1999. The problem comes from our dependence on a technology called stringprep (RFC 3454), which we use to compare JabberIDs for tasks like authentication and authorization of users and servers. Because stringprep is being deprecated by the IETF for internationalized domain names, various application technologies that use stringprep for identifiers other than domain names (e.g., usernames and passwords) need to develop a new approach to comparing protocol strings. [Read More]