Introduction
Jabber has a maturing protocol for audio/video calling, Jingle. It has advantages over other protocols, notably support for the IETF draft 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 for this.
Muji is sponsered by NLNet and Collabora.
Talks
During the 2009 linux.conf.au a talk talk about the status of the Multi-User Jingle protocol. Slides are available.
Status
Currently we have a simple client based on twisted and farsight2. This client is able to make normal jingle calls (both using ICE and raw udp) and multiparty-calls using the Muji XEP.
Downloads
The test client is available in git. The most simple way to use it to run python multi-jingle-client <jid> <password> muji@conference.jabber.org. Which will join the Muji conference on muji@conference.jabber.org. By default it will stream video from a videotestsrc, to use a webcam set VIDEO_DEVICE=<path to webcam> in the environment (e.g. VIDEO_DEVICE=/dev/video0). For more information see the README.
Requirements
nice >= 0.0.4 (for ICE support)
farsight 2 >= 0.0.7 and gst-plugins-farsight >= 0.12.9
Recent version of gstreamer, gstreamer-plugins-base, gstreamer-plugins-good and gstreamer-plugins-bad
twisted, twisted words and twisted names
- pygtk and pygobject
When running Debian most things are available in either sid or experimental. Specifically install python-gobject and the various gsteamer packages (gstreamer0.10-plugins-base,gstreamer0.10-plugins-good, gstreamer0.10-plugins-bad) from experimental (Note, gstreamer0.10-ffmpeg << 0.10.5-1 will cause crashes).
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 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. 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 stream 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.