Introduction
Jabber has a maturing protocol for audio/video calling, Jingle. It has advantages over other protocols, notably support for the IETF standard for NAT penetration, ICE. This allows audio/video data to go peer-to-peer in the majority of cases, reducing bandwidth costs. It also has the desirable property that Jabber servers do not need to have support for Jingle in order for clients using those servers to be able to begin using it. These features combined have eased adoption of Jingle as a protocol.
One feature XMPP is still missing is the ability to do multiparty calls. The Muji project aims to create an XMPP XEP which combines MUCs and jingle to add support multi-user voip support and to implement this extension in the Telepathy framework.
Muji is sponsered by and .
Status
Muji is currently defined by an experimental XEP. A Telepathy specification has been defined. Both of which are implemented in the Telepathy Component for XMPP (telepathy-gabble). Also there is a MujiDemoClient using Telepathy and Farsight 2 available for testing.
Talks
During the 2009 linux.conf.au a talk about the Multi-User Jingle protocol was given. Slides are available.
Software
See MujiDemoClient
How does it work
The XMPP extension is defined in detail by XEP-0272. A normal XMPP MUC is used to signal the fact that there is a Muji call and is also used to agree on the payload-type mapping for the various streams (audio/video) in the call. A payload-type mapping describes both the codecs and their parameters which can be used in the Call. This mapping is created centrally in the muc such that all clients share the same mapping, which allows clients to send the same media to everyone instead of potentially having to re-encode and re-payload for every peer. It also will make it easier in the future to add support for Multicast topologies and Mixer/Relay setups.
After all the initial setup in the MUC has been done the client currently uses normal Jingle to setup one-to-one connections between itself and all its peers, using the payload mapping as defined in the muc itself. The Muji protocol describes an ordering to ensure that only one jingle connection between any two clients is setup.
Muji protocol Goals
- Avoid re-encoding data for different participants where possible.
- This requires having a single list of codecs for all participants. Farsight supports this within one media session.
- Don't require any Jabber server modifications.
Possible Network topologies
- Multi Unicast, each participant in the conference directly sends and receives media from all others. Currently supported by the demo client and the protocol. Simplest form, upon joining a conference each client just starts a p2p jingle session with some extra info to indicate it's part of the conference.
Multicast media is unlikely to work on the Internet, but might be useful on local networks in conjunction with xep-0174
- One or more Mixers, a mixer mixes the stream of all/some of the participants into one media stream. Has as an advantage that low cpu/low bandwith clients would only have to receive and decode one stream. Mixer can either be a centralised mixer or one of the participants that has enough cpu/bandwith power.
- Relay, a relay would relay the rtp stream of a participant to other participants. Most internet connections are asymmetric, so while a participant might have the cpu power and downstream bandwidth to receive all streams, it might not have the necessary bandwith to send multiple streams. Hence a relay might be used to distribute its data. Again the relay can be either centralised or one of the other participants that's willing to act as a relay.
FAQ
How many people can be in a Conference
Neither the demonstration client nor the protocol limit the number of people that can be in one conference. Currently only the Multi Unicast topology has been implemented, which means the number of people is limited purely by CPU power and bandwidth.
For bandwidth the main limitation is upstream bandwidth as that's usually much lower then downstream bandwidth. For example ADSL with a downstream bandwidth of 8Mbit/s is quite common, but the upstream bandwidth of such connections is usually only 1Mbit/s. As each client needs to send out the media to all others there is a per client bandwidth cost. Rate control for our RTP stack is being worked on (which allows changing the amount of bandwidth used based on network conditions), but currently there is basically a fixed cost of between 150 and 200 kbits/s for each client when doing video calls using the demo client (depending on codecs used). We've successfully tested a video call with five participants with most of them using normal consumer ADSL lines.
For CPU time, the main cost is encoding the media. Luckily the protocol ensures that a client only has to encode the media it sends out once. The cost for decoding an audio and video stream is reasonably low. To give some kind of reference: On a ThinkPad X200s with an 1.86Ghz cpu (L9400) a conference with 4 people costs about 40% to 50% cpu, the cost per participant on this CPU seems to be in the range of 5%.
So what's next
The next step to do in the muji protocol is to improve its scalability, when focussing purely on the protocol the main way of doing this is to allow for relays and mixers to be introduced in the conference. And ofcourse integrate the functionality in a nice end-user UI.
This is awesome/rubbish, who can I contact with my feedback/help/fanmail
There are various ways to contact us, either using the main Telepathy mailing list or by contacting me personally on sjoerd.simons@collabora.co.uk (both for e-mail and jabber). On IRC we're contactable at #telepathy on FreeNode.