Jingling the MUC

I discussed previously how the XEP-0045 specification already contains all the management features to handle Multi User Communication (MUC), beyond simple text chat rooms. At the same time, I was interested to see that discussions are taking place at the Jabber Software Foundation about ways to integrate screen sharing and remote control into XMPP, as well as performing shared XML editing or SVG based white boarding.

MUC provides a very appropriate framework where these different applications can be aggregated. I have already explained how MUC exposes the required components of a generic conversation spaces management. One of the most important characteristics of conversation spaces is the possibility to host public and private conversation in the same space. In essence, conversation spaces simultaneously allow:

• point-to-point exchanges between participants,
• client-server exchanges, the conversation space being the server.

I believe people have finally come to realize the utopia of considering XMPP as an universal multi-media transport, although there are still bursts of "can I do VoIP over XMPP" here and there… When it comes to multi-media, Jingle is obviously the appropriate answer in the XMPP world.

I nonetheless feel there are still some misunderstandings with Jingle’s concept of separating sessions' establishment operations (signalling) from communication (transport) when a conversation involves more than two parties. In fact this is rather simple. In a Jingle enabled MUC, in addition to the existing XEP-0045 specification the service will only need to implement:

• Jingle support for each multi-media conversation spaces in order to answer session requests made to the space JID.
• Jingle stanzas' forwarding for session requests made to a space's participant JID.

It is easy to understand that private Jingle session requests made though a MUC are strictly equivalent to session requests between two clients made through a standard XMPP IM server. It is equally easy to understand that the point-to-point media transport between the two participants' clients will take place out of band using the appropriate negotiated binary protocol.

The same scenario applies in a conversation space, when several participants share the same media during the conversation. The difference with the above case lies in the type of end points involved in the point-to-point communication. In order to share a particular media, a mediator system has to combine each individual media flows produced by the various participants into a single media flow. This mixer role is usually played by specialized bridges, or even IPBX, when it comes to voice and video. In the particular case of VNC, I am under the impression this protocol has always been used as a pure point-to-point communications between workstations. As the typical use in the context of a MUC would mostly involve a one-to-many communication (one master screen shown to many participants' clients), adapting VNC screen sharing would require implementing some sort of repeater system.
This same one-to-many communication also applies to streaming media servers that could be used to broadcast inside the conversation space.

In the end, I believe the MUC protocol bears much more than its current limited usage for text chat rooms. I have just tried to illustrate some of the extended possibilities. I am not saying it will be all done in one day, but the proper bricks are already in place.

Technorati Tags: XMPP, Jabber, Jingle, Conversation space, Presence, Antecipate