Introduction

The new conferencing protocol replaces the old "groupchat" protocol, and has been in discussion and development by many of the jabber.org developers for quite some time. It is a framework in which messages are broadcast to multiple recipients via a third party, and that third party manages the list of recipients, traffic, and identities of all the participants. There may be numerous different types of conferencing services, private ones created on the fly by any user with their friends, IRC rooms, shared-location (URL), topic, whiteboard, or content based, and so on. This is a generic framework for managing the entrance and participation in any live multi-user conferencing. The design of the this new protocol makes use of the new browsing functionality.

Sequencing

The old style conferencing simply consisted of sending presence to a special address to gain entrance into the room, and the participants were based on the presence that was broadcast from that room address. This new style works in a similiar fashion, but makes use of a new namespace jabber:iq:conference to negotiate entrance to the room, as well as jabber:iq:browse to broadcast the list of participants.

There are a number of things that can be done prior to entering the room. By browsing to the room@host address, it will return the type of room it is as well as the name assigned to it, if any. It may also optionally return the list of current participants within the browse result (type="private" wouldn't, but type="public" would), which if available should only be used for temporary purposes as you will not be notified if/when that list changes since you are not in the room. Importantly, you can send an jabber:iq:conference get request to determine any requirements for entrance in the room or the current topic.

To join the room, the new sequence starts the same as the old one, by sending presence to the room address. Instead of sending it to room@host/nick, the presence is simply sent to room@host. This serves as the flag that the conferencing software can use to determine which style conferencing the client will use. After presence is sent to the room@host address, you will still not be in the room, it is simply a requirement so that the room will be notified if you become unavailable unexpectedly. To actually enter the room, you must submit a jabber:iq:conference set request, including any requirements listed in the get. If there are any problems processing the set request, it will be returned with an appropriate error, otherwise the result will contain the id and nick assigned to you in the room. Immediately following the valid set result, live browsing request(s) will be sent pushing the list of participants, followed by presence from the participants and normal message traffic from the room.

Namespace jabber:iq:conference

The conference namespace is a simple mechanism for obtaining the characteristics of a conference and negotiating participation.

The iq get will allow anyone to view a list of required fields and the current topic.

Getting List:
  <iq type='get' to='grp@gserv'><query xmlns='jabber:iq:conference'/></iq>
  <iq type='result' from='grp@gserv'><query xmlns='jabber:iq:conference'><nick/><secret/><privacy/><name>Demo Room</name></query></iq>

The iq set is used to enter or join a conference, and contains the required fields.

  <presence to="grp@gserv"/>
  <iq type='set' to='grp@gserv'><query xmlns='jabber:iq:conference'><secret>foo</secret><nick>dude</nick><nick>dude_</nick><privacy/></query></iq>
  <iq type='result' from='grp@gserv'><query xmlns='jabber:iq:conference'><id>grp@gserv/a32d...</id><nick>dude</nick></query></iq>

The iq set can also be used to create a new room. When the iq get returns a 404 (not found), the iq set can send any of the flags that are used to create the room. (If the conferencing service does not support creating dynamic rooms, it should return a 405 instead). The secret will set the secret for the room, nick will set your nick since your the first participant, privacy will instruct the server to allow privacy mode, and name will set the name for the room.

Participants

The participants in a room are sent in a browse set request following entrance to the room. A room will create temporary identities for all participants such as "grp@gserv/1c38...", and use that as the sending jid for that participant. The current nickname is the name attribute on the browse result. The real jid of the participant may be accessible by browsing to their temporary room jid (if not protected when they joined). Normal traffic sent specifically to a participant's jid is relayed on to that participant (may be restricted to message-only, depending on privacy settings). Any changes in the browsed participant list will be pushed to the participants as they occur.

<iq type='set' from='grp@gserv'>
  <conference type='private' xmlns='jabber:iq:browse' name='Demo Room'>
    <user jid="grp@gserv/d351..." name="jer"/>
    <user jid="grp@gserv/a32d..." name="dude"/>
  </conference>
</iq>

Messages and Presence sent to a conference will be broadcast out to all participants, and the from="" will be rewritten as the local jid assigned to that participant. Recipients should translate that sender to the appropriate node in the browse data, and use that name="" for display purposes.

Invites

For sending and receiving invitations to join a conference, clients can use the jabber:x:conference namespace inside of a normal message.

<message to="buzz@disney" from="woody@disney">
  <body>Come join the rest of the gang, talking about our next adventure</body>
  <x xmlns="jabber:x:conference" jid="toystory3@conference.disney"/>
</message>