UMPIRE, as the name itself suggests, is a brand new system we realized during the last months, aimed at providing a real-world demonstration of the seamless interaction among remote and local participants at regular IETF meetings.
UMPIRE is built around BFCP (Binary Floor Control Protocol), the IETF standard protocol for moderation. In a nutshell, BFCP introduces floor control functions in a centralized conferencing environment. Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conference and is used between floor participants and floor control servers, as well as between floor chairs (i.e., moderators) and floor control servers.
Background, rationale and motivation
As depicted in the picture above, BFCP envisages the presence of floor participants who ask for access to conference floors (e.g., audio and/or video) by sending messages to a central entity called floor control server. The server itself does not take decisions on its own, but rather forwards requests to the floor chair, who acts as a moderator and is in charge of taking decisions.
The sample call flow illustrates what happens when a conference participant asks for a floor. Basically, it sends a floor request message to the floor control server (top left), which forwards it to the floor chair (top right). Once the chair has taken a decision, it informs the floor control server (bottom left), which in turn notifies both the requesting participant (bottom right) and all other participants potentially interested in receiving floor control notifications.
Given the above background on BFCP, it should now be easy to understand that UMPIRE has been built as an entity playing the role of the floor chair in a conference. More precisely, when the conference starts, the UMPIRE user will log into it and set himself as floor chair (this obviously requires that the conference server is a BFCP-enabled one).
This operation guarantees that all subsequent floor requests coming from conference participants will be:
- stored (in a PENDING state) in the FCFS queue at the centralized floor control server;
forwarded to the UMPIRE, who will take decisions by assigning the floor to one or more users, hence triggering state changes at the server side:
as an example, if the floor control policy has been configured in such a way as to grant the floor to one user at a time and the UMPIRE accepts, in sequence, three requests coming from three different users, the following will happen:
- the first accepted request will move from a PENDING state to a GRANTED state;
- the second and third requests will move from a PENDING state to an ACCEPTED state, indicating that they are ready to be served as soon as the currently GRANTED request has terminated (through either a floor release action from the client or a revoke action from the UMPIRE himself);
- when the GRANTED request is over, the first ACCEPTED request in the queue is granted the floor, while the second one becomes the ready-to-be-granted request in the floor control server queue;
- clearly, if the server policy allows for a maximum of n requests to be granted the floor at the same time, up to n clients will reach the GRANTED state and will hence share the floor in question (e.g., in an audio conference, they will be all allowed to talk at the same time by contributing to the audio mix produced at the conference server).
- as an example, if the floor control policy has been configured in such a way as to grant the floor to one user at a time and the UMPIRE accepts, in sequence, three requests coming from three different users, the following will happen:
- acknowledged to the clients through BFCP notifications (which allow participants to be kept up to date with respect to the state of their floor transactions).
Hence, stated in a nutshell, the above described scenario relies on the presence of a centralized floor control server with a queue managed by the chair and containing all floor requests coming from conference participants. This simple yet powerful approach allows for the introduction of advanced moderation functionality in a conference.
The interesting thing about the mentioned approach resides in the consideration that the BFCP queue can be populated with requests coming both from remote participants (equipped with BFCP-enabled clients) and local participants, thanks to the utilization of an agreed-upon procedure for requesting access to the conference floors when one is physically present in the conference room. If you think of the usual way of gaining the audio floor at regular IETF meetings, what local participants have to do is to politely wait (in a FCFS queue) at one of the conference room microphones in order to either ask for questions or provide their own view on the topic being discussed. If the microphones themselves were equipped with some simple means for:
- recording the presence of users;
- sending a trigger (i.e., a floor request) to the floor control server every time a new user lines up at the microphone
it would become really easy, by simply looking at the floor control server queue, to transparently (and democratically) moderate a conference which envisages the contemporary presence of both local and remote particicpants.
That's it! And this is what we actually implemented in view of the upcoming IETF meeting in Paris. With respect to the above illustrated point concerning the simple-yet-powerful means for recognizing the presence of users lining up at the mic, we decided to rely on the RFID technology. We opted for the following policy:
- we put an RFID reader close to each of the conference room microphones;
- we then assign an RFID tag to each local participant willing to actively participate in the conference.
With this approach, when a local participant wants to contribute to the ongoing discussion, all he has to do is let his RFID tag be read by the RFID reader associated with the microphone at which he is lining up: as soon as the participant's tag has been read, the reader will send a BFCP floor request to the conference chair and let the participant be inserted in the centralized BFCP queue.
An image of the BFCP queue, updated in real-time, will always be projected on a screen available in the room, in such a way as to allow all meeting participants to have a clear view on what is going on in the conference from the floor control perspective. The chair of the conference (i.e., the UMPIRE user) will be allowed to manage the BFCP queue, by taking decisions on who (and when) can be granted the floor, thus realizing the moderation functionality in a straightforward way, in a conference which involves both remote and local participants.
UMPIRE and the IETF standardization process
The UMPIRE project has been motivated by the ongoing efforts within the IETF, concerning the standardization of the requirements for remote participation at IETF meetings. Work is currently in full swing and is being formalized in an Internet draft specifically devoted to this task. The draft in question is actually being produced at the request of the IAOC. The request for proposals that led to it can be found here. If you go and look at the mentioned draft, you'll find a section (namely, section 220.127.116.11) which is entirely dedicated to moderation. The title of the mentioned section is "Floor Control for Chairs for Audio from Remote Attendees" and it contains the following list od requirements:
**Requirement 02-28**: Remote attendee's requests MUST be part of the floor control tool, not in the instant messaging system. **Requirement 02-29**: The chair MUST be able to see all requests from remote attendees to speak at any time during the entire meeting (not just during presentations) in the floor control system. **Requirement 02-30**: The floor control system MUST allow a chair to easily turn off and on an individual's ability to speak over the audio at any time. **Requirement 02-31**: The floor control system MUST allow a chair to easily mute all remote attendees. **Requirement 02-32**: The floor control system MUST allow a chair to easily allow all remote attendees to speak without requesting permission; that is, the chair MUST be able to easily turn on all remote attendees mics at once. It is common for a chair to leave the room, to have a side discussion with an AD, or to become a presenter. They should be able to do so without having to do a handoff of the floor control capability. **Requirement 02-33**: The floor control system for the chair MUST be able to be run by at least two users at the same time. **Requirement 02-34**: The RPS MUST authenticate users who can use the floor control system in a particular meeting using simple passwords. **Requirement 02-35**: The IETF Secretariat MUST be able to easily set up the individuals allowed to use the floor control system for a particular meeting and to change the settings at any time, including during the meeting. [[[ TODO: Should those who are given floor control be allowed to augment that list to meet changing needs without going back to the Secretariat? ]]] [[[ TODO: Is it possible to tell if a remote attendee who is speaking loses network connectivity? If so, maybe this can be shown to the chair. ]]] **Requirement 02-36**: The chair SHOULD be able to monitor the sound levels of the audio being delivered to remote attendees to be sure that they can hear what is going on in the room.
Well, UMPIRE has taken such list as its requirements specification and is currently capable to meet most of them.
Indeed, apart from the formal document discussed above, we took inspiration from mailing list discussions. To get an idea of such discussions, you can have a look at the following thread on the working group chairs mailing list: "Getting Taipei remote participants' input". If you browse such thread, you'll easily find a message of mine (spromano[at]unina.it), where I proposed the following:
What I'm thinking of is RFIDs triggering BFCP (Binary Floor Control Protocol)requests, in much the same way as the floor requests generated by remote participants. The same tool should then provide session chairs with a chance to give potential "business class" requests (i.e., in the case of cut and thrust debates, or in the presence of an AD intervention) higher priority (which basically means putting such requests on top of the queue). It would be nice to test such a system at an upcoming IETF.
In answer to my message, Dave Crocker wisely stated the following:
Suggestions like the above sound appealing. Unfortunately, they are far beyond current products and making them useful is considerably more difficult than the suggestions imply. That doesn't mean they should be ignored, but we need to be careful about slipping into the assumption that merely citing a bit of technology means that an issue is resolved. We had an experiment with RFIDs. It was awkward, at best. In addition, it was extremely limited. Only the person standing right next to the microphone could be identified. For example, this means that it would not have been useful for identifying when someone /enters/ the queue. Too far away. So if folks are going to attempt to define the technical solution, at least please try to indicate how it would work throughout the requirement. In the case of queue management, we have at least entering the queue, position in the queue, and the chair's control of the queue. No doubt, there's even more complexity than that. For example, there's "noise" such as someone walking by the queue but not entering it..
A further fundamental contribution to the discussion was also provided by Brian Rosen, who asserted the following:
People worry about RFID, but I like it because it's a faster read. Bar code is less controversial (and already there). Tablet+wifi means it's only a battery lifetime issue. If we could have aggressive enough battery management, perhaps we could get through the day. All I think you want is a reader and a visible queue. The queue just tells you that the reader read correctly and has you in the queue. The chair gets to change the queue, but that ought to be rare and probably just pick the next person in queue. Remote participants simply imitate the reader action. For extra credit, monitor the jabber room. Look for <mic> and put them in queue.
All in all, we tried to take into account all of the precious considerations mentioned above and apply our usual IETF-mutuated approach based on running code prototypes which help clarify open issues at the same time fostering discussion. The system we designed and implemented is no more than this, a proof of concept implementation of a moderation framework built on top of a BFCP-enabled, XCON-compliant, conferencing architecture which is currently used at IETF meetings to offer support for remote partcipation.
UMPIRE has been implemented as a Web2.0 application. It is based on a bidirectional HTTP (relying on a COMET Server Push approach, as made available by the ZK framework) communication between the UMPIRE participant, acting as the floor chair in a conference, and the floor control server. Notifications from the server asynchronously arrive at the UMPIRE client and get represented on a simple web page which basically provides an always up-to-date snapshot of the BFCP queue (with client requests and related BFCP states). On the other hand, proactive actions undertaken by the UMPIRE (e.g., accepting or denying a PENDING request, or revoking a floor currently GRANTED to one of the participants), are immediately communicated to the floor control server and provoke effects on the BFCP queue, as well as trigger floor notifications which are sent to clients.
UMPIRE sample call flow
As usual, we follow a learn-by-example approach when trying to describe the way our systems work. In the following, we make a guided tour through the UMPIRE functionality, by taking the simple scenario described below:
Three users participate in a conference room:
two local users, equipped with RFID tags:
- User1: 4d004b05d6
- User2: 4d004a5c07
- a remote user (whose nickname is 'spromano'), who enters the conference from the Meetecho WebLite client.
- two local users, equipped with RFID tags:
The order with which the three users ask for the audio floor is the following:
- User1 --> spromano --> User2
The situation described above is illustrated in the following four snapshots, which show, respectively, the intially empty queue (top left), the first request arriving from 'User1' (top right), the request from the remote participant 'spromano' (bottom left), and the final request from local user 'User2' (bottom right). The final state of the BFCP queue, after all these actions have been performed, shows the three users (in order of arrival) in a PENDING state, i.e., waiting for the chair to take actions.
NOTE WELL: To zoom on the pictures, just click on them!
- The UMPIRE decides to first grant the floor to 'spromano'
This is shown in the two snapshots below, which clearly indicate that the decision taken by the chair ('Accept', left snapshot) translates into the following actions:
- The BFCP queue is modified: 'spromano' becomes first;
- The state of the BFCP queue is modified: the audio floor is GRANTED to 'spromano' (right snapshot)
- remote user 'spromano' is unmuted.
Accepting the request coming from the remote partcicipant
- The UMPIRE now decides to grant the floor also to 'User2'
This is illustrated below. We can observe from the pictures that the following things have happened:
- The UMPIRE has accepted the request issued by 'User2' (left snapshot);
- The state of the BFCP queue changes: 'User2' passes from PENDING to ACCEPTED (middle snapshot) and eventually to GRANTED (right snapshot). This is in line with how BFCP works and lets us understand that the conference in question has been configured in such a way as to allow for multiple users to be granted the audio floor at the same time. Were this not the case, 'User2' would have moved from PENDING to ACCEPTED and would have stayed in such state as long as the floor was held by 'spromano'.
Accepting the request coming from the 'second' local participant
- The UMPIRE now decides to revoke the floor previously assigned to 'spromano', since such user has started to say bad things about the IETF!
This is shown in the snaphots below, associated, respectively, with the action undertaken by the chair (left frame) and the effect it entails on both the BFCP queue at the server and the web interface (right frame), which now reports 'spromano' in red, with the related REVOKED status.
- The UMPIRE eventually decides to grant the floor to 'User1', too.
The flow of information now follows exactly the same scheme as illustarted above for 'User2'.
That's all folks!