Remote participation is a hot topic in the Internet Engineering Task Force (IETF). Many participants attend IETF meetings remotely if the venue is either too far away or too expensive for them to attend in person. Many regularly only attend remotely in the first place.
To make remote attendance possible, the IETF makes available the following solutions:
- A Jabber chatroom associated with each session, in which participants, both local and remote, can join using any compliant client in order to discuss the presentations
- An MP3 audio feed to listen to what is being discussed in the physical rooms
In addition, the Jabber room typically is used to give remote participants hints about ongoing presentations, e.g., the name of the slide deck being projected, slide numbers, and so on. It is expected that remote participants download the slides and open them in a compliant viewer to follow the presentation.
While this is an easy and often effective means for remote participation, it does not afford an optimal user experience. Users must download and install various applications (e.g., an extensible messaging and presence protocol (XMPP) client, a multimedia player, a slide viewer/editor), and use them at the same time. While the audio feed has a good quality, it also can have up to a 10-second delay, making seamless interaction (e.g., questions and answers) harder to achieve.
A Brief History
A few years ago, while considering our efforts to build a standards-compliant conferencing architecture, mostly based on IETF protocols, and our regular attendance at IETF meetings as active contributors, we asked ourselves: why can’t we eat our own dog food? In fact, the IETF had already devised several protocols and architectures that could be leveraged for a better remote participation experience. We had already tested some remote participation using Meetecho at IETF 76 in Hiroshima, where Lorenzo Miniero had a presentation scheduled at the MEDIACTRL session but couldn’t make it to Japan. In particular, a desktop application implementing XMPP, (session initiation protocol) SIP, and (real-time transport protocol) RTP, and providing slide sharing functionality was effectively used for a bidirectional interaction between Lorenzo and the local MEDIACTRL attendees.
IETF 80, Prague
This motivated us to propose a wider remote-participation experiment at IETF 80. Specifically, considering that a desktop application would have been more of an obstacle than an asset, we devised a web-based, front-end to our platform, thereby providing an integrated view of the Jabber room, the slides being projected, and an audio/video feed from the room. We focused on real-time delivery of the streams by extending our platform, which was already based on modified versions of open source components such as Asterisk, Openfire, and Tomcat, to better interact and seamlessly merge with the available IETF remote participation tools.
We discussed the possibility of exploiting this new interface with IETF management, particularly with respect to the interaction with local equipment (e.g., room mixers) and supported seven sessions. The experiment proved quite successful—remote participants tested our platform and we received useful feedback that we used to further develop and strengthen our prototype experiment. While the presence of a video feed (a webcam in the sessions) confused some of the local participants, it was a very welcome feature by remote participants, who praised the possibility of looking at the mic line queues. Not all feedback was positive, but it was constructive and helpful. For example, all the sessions were recorded and made available a few days later, initially by means of a Java playback application. Several users complained about relying on an untrusted Java application, despite the fact that the source code had been made available. During the week we developed a completely web-based HTML5 player for the same recordings. That Web application was the first version of the one we use today to provide all the IETF recordings.
IETF 81, Quebec City
The success of the Prague experiment motivated us to improve our platform, improve the user interface, and propose another round at IETF 81. At the meeting, the number of supported sessions increased to 12, including two plenaries, resulting in a couple of parallel sessions.
IETF 82, Taipei
The experience we gained in Prague led us to new improvements that we applied at IETF 82, an important meeting in terms of remote participation—28 sessions were supported with up to three sessions in parallel; and for the first time, we used the tool for active remote participation.
IETF 83, Paris
By IETF 83, Meetecho wasn’t news anymore. We prepared a tutorial session on it, focusing on the so-called Meetecho Scribe, a role that can be played by any local participant in order to help remote attendees. Approximately 30 sessions were supported.
IETF 83 also represented a milestone with respect to realization of a system for the automated management of floor control and the moderation of both local and remote participants (http://ietf83.conf.meetecho.com/index.php/UMPIRE_Project). This system is called UMPIRE (Universal Moderator for the Participation in IETF Remote Events) and is built around the Binary Floor Control Protocol (BFCP) that represents the IETF standard protocol for moderation. At the time of this writing, UMPIRE has not yet been used to moderate actual meeting sessions. Although at the 83, 84, and 85 meetings it was demonstrated in a tutorial. Today we are awaiting completion of the Remote Participation Services document in order to further fine-tune UMPIRE and propose it for official adoption within the IETF.
IETF 84, Vancouver
With regard to the main functionality of the platform, we started work on WEBRTC/RTCWEB, the joint standardization of the W3C and the IETF to enable native, real-time multimedia communications within browsers. We implemented the missing bricks and added a way to make use of WebRTC to join the audio/video conference. We made the completed feature available for the RTCWEB session at IETF 84 (a possibility that was praised by the active contributors in the same working group). Vancouver also saw our platform used, for the first time, to stream and record both meeting sessions and some of the tutorials, which were recorded and converted to video files now available on the IETF education pages.
IETF 85, Atlanta
Intrigued by the possibilities offered by WebRTC, we started working with the Opus codec. At IETF 85 we made available an additional stream for remote participants—an HTTP-based Opus stream, which could be played in either HTML5 or an external player. We also added a Flash-based video stream.
IETF 86, Orlando
A decisive improvement was made for IETF 86: we changed the audio backend of our platform and got rid of the narrowband audio constraint by moving to a higher quality, wideband audio mix. Participants were now able to get a real-time audio feed as good as the official MP3 stream. The improved audio quality was a welcome addition to recordings and enabled us to better integrate the Opus codec into our platform and to take advantage of its novel features.
IETF 87, Berlin
The Opus integration motivated us to organize a high-quality, remote participation experiment based on Opus for the technical plenary at IETF 87, whose topic was Opus itself. We envisioned a completely Web-based attendance to the plenary, involving a high-quality VP8 video feed and a 48kHz mixed audio feed based on Opus. Our efforts were briefly discussed during the plenary.
IETF 87 was also a training ground for experiments in recording tutorials, including a brief presentation of the MILE WG by Kathleen Moriarty. By that time, session recordings had become a fundamental asset for the community. IETF chairs rely on them when editing meeting minutes. WG participants, in turn, count on such synchronized multimedia assets for ex-post fruition of one or more recorded sessions.
Next Steps
We recently obtained a formal agreement with IETF management for support of an increasing number of sessions at upcoming meetings. (We supported nearly 40 sessions at IETF 88.)
Future meetings will be both challenging and stimulating as we simultaneously cover more and more sessions. The plan is to cover all of them in Honolulu at IETF 91. With that goal in mind, we’re working on new features, including ways to automate the scribe role (instead of relying on a local participant for videos and slides) and obtain detailed participation statistics. We’re also seeking a more seamless integration with the community’s tools (meeting agenda, materials page, meeting minutes, etc.).
We’re proud to be working with the community and for the community—whether you attend in person or not, we look forward to seeing you in London.